Date: Tue, 12 Dec 2006 17:40:48 -0400 From: "Marc G. Fournier" <scrappy@hub.org> To: John Baldwin <jhb@freebsd.org> Cc: freebsd-stable@freebsd.org Subject: Re: panic: sleeping thread Message-ID: <84206EFB24C58B8D26245B4C@ganymede.hub.org> In-Reply-To: <200612121612.50942.jhb@freebsd.org> References: <624054998B7DEF7D446796E1@ganymede.hub.org> <200612111740.23259.jhb@freebsd.org> <ED7F549771CCB4F17AAFF791@ganymede.hub.org> <200612121612.50942.jhb@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 - --On Tuesday, December 12, 2006 16:12:50 -0500 John Baldwin <jhb@freebsd.org> wrote: > On Tuesday 12 December 2006 15:47, Marc G. Fournier wrote: >> >> --On Monday, December 11, 2006 17:40:22 -0500 John Baldwin <jhb@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. That woudl take being able to get into DDB from an SSH session ;) I'll try the -e none the next time it crashes, unless someone else has another idea for doing it? Actually, I'll try the -e none after its up again, instead of waiting ... - ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email . scrappy@hub.org MSN . scrappy@hub.org Yahoo . yscrappy Skype: hub.org ICQ . 7615664 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFFfyHg4QvfyHIvDvMRApAqAJ4pnw5nZK+kvyy/9z0TrTmTlu9OCgCg2TIp naCXTEeA+EljNnWoVcD/1PU= =kYAM -----END PGP SIGNATURE-----
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?84206EFB24C58B8D26245B4C>