panic: sleeping thread

[John Baldwin]

On Tuesday 12 December 2006 15:47, Marc G. Fournier wrote:
> 
> --On Monday, December 11, 2006 17:40:22 -0500 John Baldwin <jhb at freebsd.org>
> wrote:
> 
> > Maybe use ssh -e none?  You don't need to break into ddb though, when it
> > panics it will print out more useful info on its own.
> 
> Ah, like:
> 
> Sleeping thread (tid 101409, pid 78573) owns a non-sleepable lock
> sched_switch() at sched_switch+0x11f
> mi_switch() at mi_switch+0x14c
> sleepq_wait() at sleepq_wait+0x5b
> cv_wait() at cv_wait+0xed
> _sx_xlock() at _sx_xlock+0x51
> vm_map_lookup() at vm_map_lookup+0x3c
> vm_fault() at vm_fault+0xba
> trap_pfault() at trap_pfault+0x127
> trap() at trap+0x1bd
> calltrap() at calltrap+0x5
> --- trap 0xc, rip = 0xffffffff801f8c91, rsp = 0xffffffffb908a930, rbp =
> 0xffffff
> ffb908a970 ---
> _mtx_trylock() at _mtx_trylock+0x1
> unlock_and_deallocate() at unlock_and_deallocate+0x10e
> vm_fault() at vm_fault+0x1ca0
> trap_pfault() at trap_pfault+0x127
> trap() at trap+0x3e6
> calltrap() at calltrap+0x5
> --- trap 0xc, rip = 0x8028d9bf7, rsp = 0x7fffffffe900, rbp = 
0x7fffffffe900 ---
> panic: sleeping thread
> cpuid = 1

Yeah.  The LOR is bogus though, it's a secondary effect.  The real problem is 
the fault in _mtx_trylock(), and that's probably due to a bug in the previous 
frame in unlock_and_deallocate().  If you can get a core dump that would be 
most helpful.

-- 
John Baldwin