Subject: Re: more funky stuff with kthreads and interrupts
To: Toru Nishimura <nisimura@itc.aist-nara.ac.jp>
From: Michael L. Hitch <mhitch@lightning.msu.montana.edu>
List: port-mips
Date: 05/01/2001 11:14:14
On Tue, 1 May 2001, Toru Nishimura wrote:

> It's worthwhile of printf()ing SR value when kthread gets assigned the
> very first timeslice.

  My memory must be failing - I did this a while back and thought the
problem didn't exist on the pmax.  I forgot that the SR bits have to be
1 to enable the interrupt (too much time on the m68k systems thinking
that a level 0 means all interrupts enabled).  I printed out the results
of an spl0() in the reaper and ioflush threads when they started:

root file system type: ffs
Reaper started with SPL 00000001
Ioflush started with IPL 00000001
init: copying out path `/sbin/init' 11

  I had been attempting to determine exactly how the kthread processes
get started and exactly where their SR value came from.  I seem to recall
thinking at the time that perhaps proc0 was raising the SPL at some
point before forking the kthread processes, and the current SR value was
being saved and overwriting the value initialized in mach_init().

> chuq@chuq.com wrote
> 
> > there's still something funny going on with interrupts being masked
> > in kthreads.  in my profiling runs I was seeing that preempt() and
> > ltsleep() were showing up as taking a lot of time, even though they
> > were only called a few times.  I tried printing the ipl info returned
> > by calling splhigh() in uvm_aio_aiodone() (which is only every called
> > in the aiodoned kthread), and it was 0x1.  putting a call to spl0()
> > at the top of uvm_aiodone_daemon() changed that value to 0xff01
> > (which is what I would expect it to be when interrupts are fully
> > enabled), and the time reported for preempt() and ltsleep() went
> > way down.  so even though the status register for process 0 is
> > initialized to the right value in mach_init() (at least in the pmax
> > port, which is what I've been testing), something is going wrong later.
> > could someone more familiar with this code take a look?
> --
> 
> 

--
Michael L. Hitch			mhitch@montana.edu
Computer Consultant
Information Technology Center
Montana State University	Bozeman, MT	USA