Hi Manuel,

This is quick update.  The kernel (11/21) with your patch
was crashed.  I'll atatch the trace log at the bottom.

   On Dec 10,  6:44, Kazushi (Jam) Marukawa wrote:
   > Subject: Re: mutex fault
   >    On Dec 9, 15:05, Manuel Bouyer wrote:
   >    > Subject: Re: mutex fault
   >    > 
   >    > If the problem is from softint_schedule(), the attached patch avoids calling
   >    > it, and should be safe even when the current IPL is IPL_HIGH.
   >    > 
   >    > Kazushi, can you try it too ? I see the panic only once in 2 days on my
   >    > systems ...
   > 
   > Thanks.  I'm trying this now with -O0 and -g but without
   > LOCKDEBUG.

Now, I'm going to try the similar kernel (11/27) with
additional LOCKDEBUG option and your patch.  I needed to
change the date of kernel source since 11/21 kernel aborted
at the booting time with LOCKDEBUG option.  11/27 kernel is
still aborting at the rebooting time, but I'm hoping this is
a minor problem.

On the other hand, I may need to try the latest kernel to
avoid these glitches.  Manuel, if you have your xenevt.c
patch for 1.17 xenevt.c, please send it to me.  Thanks.


Here is the log.  No LOCKDEBUG option yet, though.

----
Mutex error: mutex_vector_exit: exiting unheld spin mutex

lock address : 0x00000000c0b4ed80
current cpu  :                  0
current lwp  : 0x00000000ca965e00
owner field  : 0x0000000000000b00 wait/spin:                0/1

panic: lock error
fatal breakpoint trap in supervisor mode
trap type 1 code 0 eip c05ce919 cs 9 eflags 286 cr2 0 ilevel b
Stopped in pid 0.2 (system) at  netbsd:breakpoint+0x1:  ret
db> trace
breakpoint(c08d6562,cb192e34,0,0,cb192e34) at netbsd:breakpoint+0x1
panic(c08d586b,c08d1888,c08d19f1,c08d1a03,c0b4ed80) at netbsd:panic+0xcc
lockdebug_abort(c0b4ed80,c0aa530c,c08d19f1,c08d1a03,c0b4df06) at netbsd:lockdebug_abort+0x6a
mutex_abort(c0b4ed80,c08d19f1,c08d1a03,0,c0cc4000) at netbsd:mutex_abort+0x42
mutex_vector_exit(c0b4ed80,b380,cb192ed8,c04fd6f2,cd5761c0) at netbsd:mutex_vector_exit+0x43
lwp_unlock(cd5761c0,ca003b9a,989680,c0aeb380,c0aeb380) at 0xc04fd72b
sleepq_timeout(cd5761c0,0,64,c0617c80,1) at netbsd:sleepq_timeout+0x2f
callout_softclock(0,0,cb192fa8,c0b52d00,c180dcc0) at netbsd:callout_softclock+0x537
softintr_dispatch(0,cb192f78,f,0,c04e35d4) at netbsd:softintr_dispatch+0x9a
DDB lost frame for netbsd:Xsoftclock+0x3c, trying 0xcb192f70
Xsoftclock() at netbsd:Xsoftclock+0x3c
--- interrupt ---
--- switch to interrupt stack ---
?(346000,0,0,0,0) at 0
db> 
----

Regards,
-- Kazushi
However, never daunted, I will cope with adversity in my traditional
manner ... sulking and nausea.
		-- Tom K. Ryan