Date: Thu, 21 Mar 2013 10:00:18 -0400 From: John Baldwin <jhb@freebsd.org> To: freebsd-ia64@freebsd.org Cc: Jerome Ibanes <jibanes@gmail.com> Subject: Re: panic: mutex sched lock 0 not owned at /usr/src/sys/kern/sched_ule.c:2341 Message-ID: <201303211000.18526.jhb@freebsd.org> In-Reply-To: <CAB%2B41mFJh0kBNJYBwPGedSe7Gy9PhjGDHcNARSV78tBj2zRVUQ@mail.gmail.com> References: <CAB%2B41mFJh0kBNJYBwPGedSe7Gy9PhjGDHcNARSV78tBj2zRVUQ@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wednesday, March 20, 2013 4:58:25 pm Jerome Ibanes wrote: > List, > > The following crash happened when booting: > > FreeBSD-10.0-projects_altix2-r245399-JPSNAP-ia64-ia64-bootonly.iso > > on SGI Altix 350 dual cpu. The backtrace appears in the enclosed file and at the > end of this message. > > ---[snip]--- > panic: mutex sched lock 0 not owned at /usr/src/sys/kern/sched_ule.c:2341 > cpuid = 1 > KDB: enter: panic > [ thread pid 11 tid 100004 ] > Stopped at kdb_enter+0x92: [I2] addl r14=0xffffffffffe3aaa8,gp ;; > db> where > Tracing pid 11 tid 100004 td 0xe0000030114371c0 > kdb_enter(0x9ffc000000faa808, 0x9ffc000000faa808, 0x9ffc0000008ba8f0, > 0x40c) at kdb_enter+0x92 > vpanic(0x9ffc000000fa8168, 0xa00000000022dbb8) at vpanic+0x2b0 > panic(0x9ffc000000fa8168, 0x9ffc00000118ee38, 0x9ffc000000fad080, > 0x925) at panic+0x80 > __mtx_assert(0x9ffc00000118e180, 0x4, 0x9ffc000000fad080, 0x925) at > __mtx_assert+0x110 > sched_add(0xe00000301174a470, 0x4, 0x9ffc00000118ee80, 0x1, > 0x9ffc000000862f40) at sched_add+0x260 > intr_event_schedule_thread(0xe00000301144b200, 0xe000003010dfeb80, > 0xe00000301174a470, 0xe000003011433240) at > intr_event_schedule_thread+0x1e0 > intr_event_handle(0xe00000301144b200, 0xa00000000022dc00, 0x0) at > intr_event_handle+0x330 > ia64_ih_irq(0xe0000030114371c0, 0x41, 0xa00000000022dc00) at ia64_ih_irq+0xf0 > ia64_handle_intr(0xa00000000022dc00) at ia64_handle_intr+0x110 > ivt_External_Interrupt() at ivt_External_Interrupt+0x30 > --- trapframe at 0xa00000000022dc00 > ia64_ap_startup() at ia64_ap_startup+0x2a0 > os_boot_rendez() at os_boot_rendez+0x240 > ia64_ap_startup(0x30b5ffe947b2cf7f, 0xcabac28abdbdf21c, > 0x24b4a3a653b39330, 0xcdd70693bad03605) at ia64_ap_startup+0x280 > (null)(0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0) at 0xcabac28abdbdf21c > db> On most platforms the APs don't enable interrupts until their first context switch into their idle thread completes. It seems they are enabled by accident here? -- John Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201303211000.18526.jhb>