From owner-freebsd-ppc@FreeBSD.ORG Sun Jun 9 15:47:31 2013 Return-Path: Delivered-To: freebsd-ppc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 313FE53B; Sun, 9 Jun 2013 15:47:31 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from smtpauth4.wiscmail.wisc.edu (wmauth4.doit.wisc.edu [144.92.197.145]) by mx1.freebsd.org (Postfix) with ESMTP id F23191E6A; Sun, 9 Jun 2013 15:47:30 +0000 (UTC) MIME-version: 1.0 Received: from avs-daemon.smtpauth4.wiscmail.wisc.edu by smtpauth4.wiscmail.wisc.edu (Oracle Communications Messaging Server 7u4-27.01(7.0.4.27.0) 64bit (built Aug 30 2012)) id <0MO400A00TOA3S00@smtpauth4.wiscmail.wisc.edu>; Sun, 09 Jun 2013 10:47:24 -0500 (CDT) X-Spam-PmxInfo: Server=avs-4, Version=6.0.2.2308539, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2013.6.9.153918, SenderIP=0.0.0.0 X-Spam-Report: AuthenticatedSender=yes, SenderIP=0.0.0.0 Received: from wanderer.tachypleus.net (adsl-76-208-69-84.dsl.mdsnwi.sbcglobal.net [76.208.69.84]) by smtpauth4.wiscmail.wisc.edu (Oracle Communications Messaging Server 7u4-27.01(7.0.4.27.0) 64bit (built Aug 30 2012)) with ESMTPSA id <0MO400H4OUIX1230@smtpauth4.wiscmail.wisc.edu>; Sun, 09 Jun 2013 10:47:24 -0500 (CDT) Date: Sun, 09 Jun 2013 10:47:21 -0500 From: Nathan Whitehorn Subject: Re: Strange panic on ppc64 In-reply-to: To: Justin Hibbits Message-id: <51B4A389.4020607@freebsd.org> References: <51AF6661.3060007@freebsd.org> <51B345BE.5030905@freebsd.org> User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130420 Thunderbird/17.0.5 Content-Type: text/plain; CHARSET=US-ASCII Content-Transfer-Encoding: 7BIT X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: FreeBSD PowerPC ML X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Jun 2013 15:47:31 -0000 On 06/08/13 17:33, Justin Hibbits wrote: > > > > On Sat, Jun 8, 2013 at 7:54 AM, Nathan Whitehorn > > wrote: > > On 06/08/13 09:21, Justin Hibbits wrote: >> >> >> >> On Wed, Jun 5, 2013 at 9:47 AM, Justin Hibbits >> > wrote: >> >> Will do, when I get it panicking again. >> >> - Justin >> >> On Jun 5, 2013 9:46 AM, "Nathan Whitehorn" >> > wrote: >> >> On 06/04/13 22:35, Justin Hibbits wrote: >> >> After a string of seemingly random hangs, I added >> invariants (but not >> witness) to my custom kernel config, and I get the >> following panic, >> recreated from a fuzzy cell phone picture: >> >> >> [thread pid -1 tid 1006665719 ] >> Stopped at 0: illegal instruction 0 >> db> panic: mutex ohci1 owned at >> /usr/home/chmeee/freebsd/head/sys/dev/usb/usb_transfer.c:2280 >> cpuid = 0 >> Uptime: 9h8m1s >> >> ... >> panic: msleep1 >> cpu = 0 >> KDB: enter: panic >> [ thread pid -1 tid 100665719 ] >> .... >> >> The first question I have is how the hell it got such >> a strange PID/TID, >> memory corruption my guess, something is stomping on >> the pcpu or something, >> and I think these hangs have only happened since I >> added a lot more memory >> (up to 12G from 4G, Andreas Tobler was seeing hangs >> as well), so it might >> be something in the moea64 pmap code, but that's pure >> speculation on my >> part. Then the other panic messages, owned mutex and >> panic in msleep1. I >> enabled more trace code, so hopefully the next time >> it panics I can collect >> better data. >> >> - Justin >> _______________________________________________ >> freebsd-ppc@freebsd.org >> mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-ppc >> To unsubscribe, send any mail to >> "freebsd-ppc-unsubscribe@freebsd.org >> " >> >> >> Could you post the output from show reg? It looks like it >> tried to jump to a null pointer there. >> -Nathan >> >> >> Well, it's hard to do get that output, because I just hit that >> 'mutex owned' panic, and here's the backtrace: > > > The mutex thing is spurious -- it was already panicing and then > paniced again trying to panic. Can you get the backtrace for the > original panic (it should be different) and the values of the > registers? > -Nathan > > > Here you go: > > [ thread pid -1 tid 1006665719 ] > Stopped at 0: illegal instruction 0 > db:0:kdb.enter.default> show reg > r0 0 > r1 0 > r2 0xab63d0 M_MACTEMP > r3 0xbb12e0 > r4 0x741f18 .ofwcall+0xa8 > r5 0 > r6 0xa4f1a8 > r7 0x1 > r8 0x1 > r9 0xc10500 __pcpu > r10 0x1c35ec0 > r11 0 > r12 0x2000d032 > r13 0x342eb000 > r14 0x10014200 > r15 0xffffffffffffcb58 > r16 0x2 > r17 0x2 > r18 0xffffffffffffcb50 > r19 0 > r20 0xc000000013231478 > r21 0xc00000014c0ce200 > r22 0 > r23 0x64 dbsize+0x10 > r24 0xc00000014c0cdf70 > r25 0xb62cb8 smp_no_rendevous_barrier > r26 0 > r27 0x741f18 .ofwcall+0xa8 > r28 0x741f18 .ofwcall+0xa8 > r29 0x2000d032 > r30 0x9000000000001032 > r31 0xc0cad8 mac_labeled > srr0 0x102ca4 k_trap+0x28 > srr1 0x9000000000001032 > lr 0x102c74 u_trap+0x10 > ctr 0xff846d78 > cr 0x2000f1b0 > xer 0 > dar 0xfffffffffffffd60 > dsisr 0x42000000 > 0: illegal instruction 0 > db:0:kdb.enter.default> bt > Tracing pid -1 tid 1006665719 td 0 > (nothing) Well, that is all kinds of messed up. It appears to have halted while handling a userland trap due to an implicit branch caused by bad translations when it restores the kernel SRs. Could you see what 'show pcpu' does? Does that information look valid at all? I suspect it has become corrupted somehow. -Nathan