amd64/73211: FAST_IPSEC broken on amd64

[Peter Wemm]

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 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
> 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 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