On Sat, 14 Apr 2007, Andrew Doran wrote:

> Hi,
>
> On Thu, Apr 12, 2007 at 12:29:56AM +0200, Anders Lindgren wrote:
>
>> I get this error (trivially reproducible) on port-evbarm/TS7200 kernels,
>> both 4.99.16 from a couple of days ago and 4.99.17 built ~24h ago.
>
> What kind of workload triggers the problem?

It happens as soon as I pick /bin/sh for shell when multiuser boot is 
interrupted due to rc_configured being false, or (if rc_configured=YES) at 
the same point when multiuser boot is initiated. For some weird reason it 
doesn't happen if I type /bin/ksh at the single user prompt instead of 
just pressing return(!) Smells timing. Most of the details are in my last 
couple of posts on port-arm.

>> The lock in question is no other than sched_mutex in kern_synch.o, which
>> seems pretty bad. :-)
>
> Can you see if the panic is occuring from an interrupt handler?

Nope, happens down in a pipe_read from a syscall_plain from /bin/sh

>> Interestingly enough, the problem disappears if the kernel is compiled
>> with options LOCKDEBUG. It seems evbarm usage of this option is isolated
>> to arm32/pmap.c, so I guess I'll continue looking there...
>
> One possibility is that the arm32 cpu_switch is not correct, and LOCKDEBUG
> is changing the timing of events just enough that the problem does not occur

Yes, Chris Gilbert suggested this on port-arm as well. I haven't been home 
since thursday so I haven't been able to look closer at it.

> with it. The yamt-idlelwp removes a lot of MD code in this area - would you
> be willing to try a kernel from the branch if I build one for you?

Sure -- I am going to try some of the diagnostic options in regular 
-current as well when I get home tomorrow, see if I am able to narrow it 
down at all, so just let me know what tag I should check out and I can 
track that branch in parallell. If you've already got a kernel just drop 
me a link or something. :)

Thanks!
ali:)