From owner-freebsd-ia64@FreeBSD.ORG Thu Mar 21 14:14:55 2013 Return-Path: Delivered-To: freebsd-ia64@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id E9154289 for ; Thu, 21 Mar 2013 14:14:55 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id C72D6CFE for ; Thu, 21 Mar 2013 14:14:55 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 335FCB94A; Thu, 21 Mar 2013 10:14:55 -0400 (EDT) From: John Baldwin To: freebsd-ia64@freebsd.org Subject: Re: panic: mutex sched lock 0 not owned at /usr/src/sys/kern/sched_ule.c:2341 Date: Thu, 21 Mar 2013 10:00:18 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p25; KDE/4.5.5; amd64; ; ) References: In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201303211000.18526.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Thu, 21 Mar 2013 10:14:55 -0400 (EDT) Cc: Jerome Ibanes X-BeenThere: freebsd-ia64@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the IA-64 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Mar 2013 14:14:56 -0000 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