On Tuesday 12 December 2006 15:47, Marc G. Fournier wrote: > > --On Monday, December 11, 2006 17:40:22 -0500 John Baldwin <[EMAIL PROTECTED]> > 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 _______________________________________________ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
