> Date: Fri, 5 Nov 2010 17:52:23 +0100
> From: Mike Belopuhov <[email protected]>
Mike, you might want to take a look at PR 6508. I think the
"sched_lock" panic:
> ddb{0}> show panic
> kernel diagnostic assertion "__mp_lock_held(&sched_lock) == 0" failed:
is actually a side effect of trapping in the middle of a context
switch when we're doing the sched_lock/kernel_lock dance. In PR 6508
it is almost certainly a page fault that happened because we
overflowed the stack. That also might be the cause of your panic. At
least judging from the traceback, your stack is seriously hosed:
> ddb{0}> tr
> Debugger(d08cc9e6,e08b7e34,d08aaf94,e08b7e34,d0a44e28) at Debugger+0x4
> panic(d08aaf94,d08346ee,d08a80e0,d08a83ed,16a) at panic+0x5d
> __assert(d08346ee,d08a83ed,16a,d08a80e0,0) at __assert+0x2e
> _kernel_lock(1,0,d09d15cc,7a120,0) at _kernel_lock+0x48
> trap() at trap+0x5fb
> --- trap (number -547639296) ---
> Bad frame pointer: 0xd0ad48a0
> 0:
