From owner-freebsd-current Sun Mar 18 14:57:12 2001 Delivered-To: freebsd-current@freebsd.org Received: from salmon.maths.tcd.ie (salmon.maths.tcd.ie [134.226.81.11]) by hub.freebsd.org (Postfix) with SMTP id EDA6437B718; Sun, 18 Mar 2001 14:57:08 -0800 (PST) (envelope-from dwmalone@maths.tcd.ie) Received: from walton.maths.tcd.ie by salmon.maths.tcd.ie with SMTP id ; 18 Mar 2001 22:57:08 +0000 (GMT) Date: Sun, 18 Mar 2001 22:57:07 +0000 From: David Malone To: Dag-Erling Smorgrav Cc: current@freebsd.org, jhb@freebsd.org, jake@freebsd.org, Ian Dowse Subject: Re: Interesting backtrace... Message-ID: <20010318225707.A2140@walton.maths.tcd.ie> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from des@ofug.org on Sun, Mar 18, 2001 at 04:41:03PM +0100 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, Mar 18, 2001 at 04:41:03PM +0100, Dag-Erling Smorgrav wrote: > I finally caught a backtrace from one of those recurring stack smash > panics. I've been getting a few of these every day for a couple of > weeks now but never caught a dump; I caught this one by typing 'panic' > immediately instead of trying to get a trace at the ddb prompt first. I have a suggestion for what is happening, but I'm not sure exactly what could cause it. From looking at the stack from the core I have found where the esp and eip in the second trap frame are comming, from: 0xffff0000, 0xffffffff, ... another 100 bytes 0xc0293748, return address in pmap_zero_page (calling bzero) 0xc0801000, CADDR2 0x1000, PAGESIZE 0xc86dff38, pushed ebp 0xc0266b53 return address in vm_fault (calling pmap_zero_page) Now, 108 bytes is exactly the amount that the i586_bzero shifts the stack by if it uses the floating point registers and it needs to preserve them. At the end it checks "PCPU(NPXPROC)" again and if it is zero it doesn't bother popping the 108 bytes off the stack. Presumably what is happening is i586_bzero begins and finds that PCPU(NPXPROC) is not zero, so it decides to preserve the fpu registers. Then something interrupts it, but doesn't restore PCPU(NPXPROC). When i586_bzero returns it uses the first 8 bytes of the fpu registers for its intstruction pointer and stack pointer and goes boom. I haven't tried to find out what is supposed to save and restore PCPU(NPXPROC). In my trace the process in question had recently been interrupted by the ata interrupt. David. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message