On Sun, Dec 05, 2004 at 10:29:41PM +0100, Pavel Cahyna wrote:
> > CPU 0:
> > acquire
> > spinlock_aquire_count
> > mi_switch
> > ltsleep
> > sbwait
> > soreceive
> > soo_read
> > dofileread
> > sys_read
> > syscall_plain
> > 	
> > 	CPU0 is trying to aquire again kernel_lock, while CPU1 has it, and tries
> > 	to send an IPI to CPU0.
> > 	But I don't know how this would prevent CPU0 from receiving an IPI.
> 
> Because during whole execution of spinlock_acquire_count, CPU 0 is at
> spllock (INTERLOCK_ACQUIRE does spllock) and spllock is defined as
> splhigh, which probably blocks IPIs.

On x86, splhigh() doens't block IPIs:
#define IPL_HIGH        0xd     /* everything */
#define IPL_SERIAL      0xd     /* serial */
#define IPL_IPI         0xe     /* inter-processor interrupts */

If this was the problem, we could run into this each time the 2 CPU competes
for the kernel_lock. I've only seen it with mi_swicth() in the path, so
I think mi_switch() is doing something special here ...

-- 
Manuel Bouyer <bouyer@antioche.eu.org>
     NetBSD: 26 ans d'experience feront toujours la difference
--