On 5/16/2005 10:33 AM, othermark wrote: > I have an application that uses shared memory/threads and is linked with > libpthread, running on May 10 -current. Every time I run it, after a few > minutes *poof* hard lock on a SMP box. All debug options are enabled in > the kernel, but it won't break to debugger. Here's what appears on the > console, and addr2line output follows: > > > kernel trap 12 with interrupts disabled > > > Fatal trap 12: page fault while in kernel mode > cpuid = 0; apic id = 01 > fault virtual address = 0x4 > fault code = supervisor read, page not present > instruction pointer = 0x20:0xc06b5dd9 > stack pointer = 0x28:0xe76eeb4c > frame pointer = 0x28:0xe76eeb74 > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, def32 1, gran 1 > processor eflags = resume, IOPL = 0 > current process = 640 (tgen) > > > # addr2line -e kernel.debug 0xc06b5dd9 > /usr/src/sys/kern/subr_turnstile.c:226 > # ls -l /boot/kernel > total 13920 > -r-xr-xr-x 1 root wheel 7102901 May 10 17:15 kernel > > 215 #ifndef SMP > 216 /* > 217 * For UP, we check to see if td is curthread (this shou > 217 ldn't > 218 * ever happen however as it would mean we are in a dead > 218 lock.) > 219 */ > 220 KASSERT(td != curthread, ("Deadlock detected")); > 221 #endif > 222 > 223 /* > 224 * If we aren't blocked on a lock, we should be. > 225 */ > 226 KASSERT(TD_ON_LOCK(td), ( > 227 "thread %d(%s):%d holds %s but isn't blocked on a lo > 227 ck\n", > 228 td->td_tid, td->td_proc->p_comm, td->td_state, > 229 ts->ts_lockobj->lo_name)); I reported the same fatal trap last night, except for me it was an instant reboot from X while running Firefox. -- Jonathan Noack | noackjr_at_alumni.rice.edu | OpenPGP: 0x991D8195
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:34 UTC