Date: Wed, 27 Oct 2004 13:07:13 -0700 From: Peter Wemm <peter@wemm.org> To: freebsd-amd64@freebsd.org, David Gilbert <dgilbert@dclg.ca> Subject: Re: amd64/73211: FAST_IPSEC broken on amd64 Message-ID: <200410271307.13660.peter@wemm.org> In-Reply-To: <200410271900.i9RJ0pfA099288@freefall.freebsd.org> References: <200410271900.i9RJ0pfA099288@freefall.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wednesday 27 October 2004 12:00 pm, David Gilbert wrote: > The following reply was made to PR amd64/73211; it has been noted by > GNATS. > > From: David Gilbert <dgilbert@dclg.ca> > To: obrien@FreeBSD.org > Cc: David Gilbert <dgilbert@dclg.ca>, > FreeBSD-gnats-submit@FreeBSD.org, freebsd-amd64@FreeBSD.org > Subject: Re: amd64/73211: FAST_IPSEC broken on amd64 > Date: Wed, 27 Oct 2004 14:51:47 -0400 > > >>>>> "David" == David O'Brien <obrien@FreeBSD.org> writes: > > David> On Wed, Oct 27, 2004 at 02:14:04PM -0400, David Gilbert wrote: > >> After attempting to obtain a dump, it would appear that this > >> crash won't produce a dump. It might be memory corruption as the > >> tech reported this crash to be a General Protection Fault in > >> kernel mode. > > David> Download the latest memtest86+ ISO image from > www.memtest.org, David> burn it to CDROM, and see if all your RAM > passes. > > Since we've stresstested this box with packets and compiling and > other chores, I strongly suspect the memory is not at fault. The > memory is also registered ECC. > > I'll have them run memory tests, but I'm at least the second > independant person to report that FAST_IPSEC and amd64 are broken. > > The difference between the divide error and the GPF error was > recompiling the kernel to dump --- so it's possible (I'm not in > front of the machine) that the GPF is a second panic when it tries to > dump. AMD did some really silly things in the design of this cpu. One is that trying to access an invalid address causes a GPF with no clues as to what the invalid address was. Normally you'd get a segmentation or page trap which includes the faulting address. When you get a GPF, you have to disassemble the code and figure out what the heck caused it. Usually it'll be a memory reference and if you look at the register or address it is trying to use for the address, it'll be in non-canonical form. For example, dereferencing 0xdeadc0dedeadc0de will cause an anonymous GPF with no other clues available to the trap handler. This is a real PITA to say the least. If I ever find the !^@#$!^@#!# AMD engineer who came up with the bright idea signalling this with a GPF instead of the regular trap types that include a virtual address.... well, lets not go there in case there are children reading this list. -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com "All of this is for nothing if we don't go to the stars" - JMS/B5
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200410271307.13660.peter>