From owner-freebsd-alpha Mon Jan 21 6:13:37 2002 Delivered-To: freebsd-alpha@freebsd.org Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by hub.freebsd.org (Postfix) with ESMTP id 8CFAC37B419 for ; Mon, 21 Jan 2002 06:13:33 -0800 (PST) Received: from grasshopper.cs.duke.edu (grasshopper.cs.duke.edu [152.3.145.30]) by duke.cs.duke.edu (8.9.3/8.9.3) with ESMTP id JAA07853; Mon, 21 Jan 2002 09:13:32 -0500 (EST) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.11.6/8.9.1) id g0LED2U33751; Mon, 21 Jan 2002 09:13:02 -0500 (EST) (envelope-from gallatin@cs.duke.edu) From: Andrew Gallatin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15436.8686.765933.505738@grasshopper.cs.duke.edu> Date: Mon, 21 Jan 2002 09:13:02 -0500 (EST) To: Bernd Walter Cc: freebsd-alpha@FreeBSD.ORG Subject: Re: 4.5-RC panic In-Reply-To: <20020121035556.D58301@cicely8.cicely.de> References: <20020121035556.D58301@cicely8.cicely.de> X-Mailer: VM 6.75 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Bernd Walter writes: > (kgdb) bt > #0 0xfffffc000037fdc0 in dumpsys () at ../../kern/kern_shutdown.c:472 > #1 0xfffffc000037f988 in boot (howto=256) at ../../kern/kern_shutdown.c:313 > #2 0xfffffc00003801d0 in panic (fmt=0xfffffc000051c3dc "trap") at ../../kern/kern_shutdown.c:581 > #3 0xfffffc00004dba60 in trap (a0=4833124384, a1=4832532772, a2=0, entry=2, framep=0xfffffe00071d3a40) > at ../../alpha/alpha/trap.c:551 > #4 0xfffffc00004cd97c in XentMM () > #5 0xfffffc00004dbcc4 in syscall (code=344, framep=0xfffffe00071d3ee0) at ../../alpha/alpha/trap.c:655 > > dmesg: <...> > fatal kernel trap: > > trap entry = 0x2 (memory management fault) > a0 = 0x12013a020 > a1 = 0x1 > a2 = 0x0 > pc = 0xfffffc00004d035c > ra = 0xfffffc00004dbcc4 > curproc = 0xfffffe0005c6efc0 > pid = 268, comm = tcsh Truly bizzare. Its trap'ping on what looks like user-space address somewhere in the user proc's heap. a2 is 0, so its a load. What pointer had this value? The syscall in question (344) is sigreturn. I haven't been keeping up with committers in the last few months. Has anything changed lately wrt. signal delivery? Can you disassemble this and see if its faulting on the call or the return? Drew To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message