Though I have no clue for the solution at this moment, I point that
the parallel existence of SR(IE) master interrupt enable bit (0x1) and
SR(IM) interrupt enable bits (0xff00) has been a trouble source so
far.  I think it'd be better to have splraise()/spllower() premitives
just for SR(IM) control assuming SR(IE) bit turned on all the time,
while additional local (== MIPS peculiar) routines manipulate SR(IE)
bit in limited fashion. 

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

Tohru Nishimura

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?
--