From owner-freebsd-ppc@FreeBSD.ORG Thu Jun 27 05:03:56 2013 Return-Path: Delivered-To: freebsd-ppc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 7B59AE56; Thu, 27 Jun 2013 05:03:56 +0000 (UTC) (envelope-from chmeeedalf@gmail.com) Received: from mail-bk0-x234.google.com (mail-bk0-x234.google.com [IPv6:2a00:1450:4008:c01::234]) by mx1.freebsd.org (Postfix) with ESMTP id D2E211792; Thu, 27 Jun 2013 05:03:55 +0000 (UTC) Received: by mail-bk0-f52.google.com with SMTP id d7so77868bkh.39 for ; Wed, 26 Jun 2013 22:03:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=0GKx/aIbBnMk6tZz74hiLzqnbRipPyGgsv+iv2fkoRw=; b=q0JufHuClFymas5UHxn+o+kGRFiz8/BpXTFVr2dKRVbzrj1a0InNYDPu2A+dy84R/q qy2FJKVSK7ckeIb6g9BU3SMSs6BxxMPa0OBCgHLdOLTcVUkZ9nuYQEwdtIaiMPrINo1p kHIqYYCpY64fhzT2xlLCAoqxS8scB7phiIyjCQd96UrMGPd1I0UNJz/gWOHLblsMKI6Y yvg7FLJ9SL6MJnEa4WCuxmq0acwuNvbo+gGwKRiwodwm4IYJAzeAry4KO4nhETwHevr7 XRd12ijJihLZ6x8G4CDVqbkk0j3uCPzWvA13dVql7oPD41Oi+nBr43pao510FA1G0Xvs /q+w== MIME-Version: 1.0 X-Received: by 10.204.65.69 with SMTP id h5mr925286bki.59.1372309434798; Wed, 26 Jun 2013 22:03:54 -0700 (PDT) Sender: chmeeedalf@gmail.com Received: by 10.204.236.132 with HTTP; Wed, 26 Jun 2013 22:03:54 -0700 (PDT) In-Reply-To: References: <51AF6661.3060007@freebsd.org> <51B345BE.5030905@freebsd.org> <51B4A389.4020607@freebsd.org> <51B5D28C.505@freebsd.org> <51B5D539.8050102@freebsd.org> Date: Wed, 26 Jun 2013 22:03:54 -0700 X-Google-Sender-Auth: r1i8XFsXErXkCgSygO_iqwfXhDE Message-ID: Subject: Re: Strange panic on ppc64 From: Justin Hibbits To: Adam Martin Content-Type: multipart/mixed; boundary=001a11c383686255a504e01bb0c1 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: Thu, 27 Jun 2013 05:03:56 -0000 --001a11c383686255a504e01bb0c1 Content-Type: text/plain; charset=UTF-8 > > On Jun 12, 2013 11:31 PM, "Justin Hibbits" wrote: >> >>> On Mon, Jun 10, 2013 at 9:20 PM, Justin Hibbits >> >wrote: >>> >>> > On Mon, Jun 10, 2013 at 6:31 AM, Nathan Whitehorn < >>> nwhitehorn@freebsd.org>wrote: >>> > >>> >> On 06/10/13 08:20, Nathan Whitehorn wrote: >>> >> > This is now getting interesting. Reading the tea leaves, what has >>> >> > happened is that the kernel has called into Open Firmware. Open >>> Firmware >>> >> > has then crashed early on, before setting up its own trap handlers, >>> >> > which has then flung you back into FreeBSD's handlers with a totally >>> >> > bogus environment, causing a second panic, which then causes a >>> *third* >>> >> > panic when trying to acquire a lock. It would be interesting to know >>> >> > what the OF environment looked like and what commands it was trying >>> to >>> >> > execute (in r3), but that may be tricky to get... >>> >> > -Nathan >>> >> > _______________________________________________ >>> >> >>> >> One other point: you can trace this pretty easily by just putting >>> >> something like: >>> >> >>> >> if (pmap_bootstrapped) printf("Open Firmware call %p\n", args); >>> >> >>> >> in the top of openfirmware(). If I understood the debugger output >>> >> correctly, something should be making a firmware call immediately >>> before >>> >> the crash. >>> >> >>> >> As a random guess about what is happening, it is possible OF is trying >>> >> to allocate memory for itself. We just ignore the possibility that it >>> >> might want to do that at present, but that is not necessarily a good >>> >> assumption. >>> >> -Nathan >>> >> Here's where I stand on the panic: The panic was actually caused within a bad return from Open Firmware, or something like that. I eliminated the runtime panic by removing the necessity of Open Firmware to retrieve CPU ivars and instead caching them. Now, after discussing with Nathan a bit, I added a trace and register dump to the db_main() function, so that every entry into DDB, even at the very beginning which is one place I see this problem, it would dump the needed information. I ran this twice, and go the exact same register dump, which is attached. Any further insights are welcome. Oh, the actual entry is on an illegal instruction 0 at address 0, or so it claims. - Justin --001a11c383686255a504e01bb0c1 Content-Type: application/octet-stream; name="zhabar.panic" Content-Disposition: attachment; filename="zhabar.panic" Content-Transfer-Encoding: base64 X-Attachment-Id: f_hifhhxvx0 MHgwMDAwMDAwMDAwYTdhYzAwOiBhdCAua2RiX3RyYXArMHgxMDgKMHgwMDAwMDAwMDAwYTdhY2Iw OiBhdCAuZGJfdHJhcF9nbHVlKzB4NmMKMHgwMDAwMDAwMDAwYTdhZDMwOiBhdCBkYnRyYXArMHgx MjgKcjAJMApyMQkwCnIyCTB4YzBkNDgwIG1hY19wb2xpY3lfbGlzdApyMwkweGJiMTg0MApyNAkw eDc0MWE1OCAub2Z3Y2FsbCsweGE4CnI1CTAKcjYJICAweGMwZDRmMCBtYWNfbGFiZWxlZApyNwkw eGMwMDAwMDAwMDAwNDc3MApyOAkweDEKcjkJMHhjMTEyODAgX19wY3B1CnIxMAkweDFjMzVlYzAK cjExCTAKcjEyCTB4MjQwMDAwMjIKcjEzCTB4YmRiNzEwIHRocmVhZDAKcjE0CTAKcjE1CTAKcjE2 CTAKcjE3CTAKcjE4CTAKcjE5CTAKcjIwCTB4ZjBkMDAwCnIyMQkweDQKcjIyCTB4MTgwMWI0NApy MjMJMHgxODAzNjk4CnIyNAkweGMwMDAwMDAwMDAwNDc3MApyMjUJMHhiNjMxMzAgc21wX25vX3Jl bmRlenZvdXNfYmFycmllcgpyMjYJMHhiODM4NDggb2Z3X3JlbmRlenZvdXNfZGlzcGF0Y2gKcjI3 CTB4NzQxYTU4IC5vZndjYWxsKzB4YTgKcjI4CTB4NzQxYTU4IC5vZndjYWxsKzB4YTgKcjI5CTB4 MjQwMDAwMjIKcjMwCTB4OTAwMDAwMDAwMDAxMDMyCnIzMQkweGMwZDQ3OCBtYWNfc3RhdGljX3Bv bGljeV9saXN0CnNycjAJMHgxMDJjYTQga190cmFwKzB4MjgKc3JyMQkweDkwMDAwMDAwMDAwMTAz MgpscgkweDEwMmM3NCB1X3RyYXArMTAKY3RyCTB4ZmY4NDZkNzgKY3IJMHgyMDAwZDRiMAp4ZXIJ MApkYXIJMHhmZmZmZmZmZmZmZmZmZDYwCmRzaXNyCTB4NDIwMDAwMDAKCg== --001a11c383686255a504e01bb0c1--