Subject: Re: port-alpha/35195: "fpsave ipi didn't" PR #26383 - still happening
To: None <port-alpha-maintainer@netbsd.org, gnats-admin@netbsd.org,>
From: Michael L. Hitch <mhitch@lightning.msu.montana.edu>
List: netbsd-bugs
Date: 01/29/2007 21:50:03
The following reply was made to PR port-alpha/35195; it has been noted by GNATS.

From: "Michael L. Hitch" <mhitch@lightning.msu.montana.edu>
To: gnats-bugs@NetBSD.org
Cc: port-alpha-maintainer@netbsd.org, gnats-admin@netbsd.org,
	netbsd-bugs@netbsd.org
Subject: Re: port-alpha/35195: "fpsave ipi didn't" PR #26383 - still happening
 on netbsd/alpha 3.1 smp kernel
Date: Mon, 29 Jan 2007 14:46:48 -0700 (MST)

 On Wed, 6 Dec 2006, salparadiso@autistici.org wrote:
 
   I'm experiencing random panics on my dual processor AS4000.
 > sometimes the machine just hangs (always after days, weeks or months of smooth uptime) and there is nothing to do except a hard reboot...
 >
 > the problem seems identical to PR #26383.
 >
 > can anybody confirm this?
 
    I've not seen the "fpsave ipip didn't" panic since PR 26383 was closed.
 
 >> Fix:
 > none. (downgrading to a 2.1 kernel does not look like a good idea)
 >
 > i've seen this problem before using the 2.0 kernel.
 > after upgrading to 2.1 it disappeared (maybe was fixed?).
 
    The fix was pulled up to 2.1, and should be in the 2.1 release.  It was 
 also pulled up to the netbsd-3 branch at the time, and should be all the 
 3.x releases.  I've downloaded the netbsd-GENERIC.MP.gz kernel from the 
 3.1 release, and verified with ident that it has the correct versions of 
 trap.c and machdep.c (the files affected by PR 26383).
 
 > Now I've upgraded to 3.1 and
 > I'm stuck on a debugger screen with a
 > "fpsave ipi didn't" message again!
 
    As I remember, this was a tricky one to debug.  It takes some digging 
 around in the debugger to figure out where the current CPU came from 
 (stack traceback is the starting point), and as I remember, I wasn't able 
 to get a stack traceback on the other CPU.  I can't remember at the moment 
 just how I tracked the problem in PR 26383 down.
 
    A good, clean kernel dump and a netbsd.gdb kernel might be helpful, but
 again, I can't remember if I was able to get a good dump file.
 
 --
 Michael L. Hitch			mhitch@montana.edu
 Computer Consultant
 Information Technology Center
 Montana State University	Bozeman, MT	USA