amd64/73211: FAST_IPSEC broken on amd64
peter at wemm.org
Wed Oct 27 13:07:20 PDT 2004
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
> From: David Gilbert <dgilbert at dclg.ca>
> To: obrien at FreeBSD.org
> Cc: David Gilbert <dgilbert at dclg.ca>,
> FreeBSD-gnats-submit at FreeBSD.org, freebsd-amd64 at 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 at 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
> 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
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
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 at wemm.org; peter at FreeBSD.org; peter at yahoo-inc.com
"All of this is for nothing if we don't go to the stars" - JMS/B5
More information about the freebsd-amd64