Bug 73211
| Summary: | FAST_IPSEC broken on amd64 | ||
|---|---|---|---|
| Product: | Base System | Reporter: | David Gilbert <dgilbert> |
| Component: | amd64 | Assignee: | Bjoern A. Zeeb <bz> |
| Status: | Closed FIXED | ||
| Severity: | Affects Only Me | ||
| Priority: | Normal | ||
| Version: | Unspecified | ||
| Hardware: | Any | ||
| OS: | Any | ||
|
Description
David Gilbert
2004-10-27 18:40:29 UTC
Additional information. I'm debugging remotely through a person ... so that's why I missed this. The error (which is easily reproducable anyways) is fatal trap 18: integer divide fault while in kernel mode Dave. -- ============================================================================ |David Gilbert, Independent Contractor. | Two things can only be | |Mail: dave@daveg.ca | equal if and only if they | |http://daveg.ca | are precisely opposite. | =========================================================GLO================ 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. Dave. -- ============================================================================ |David Gilbert, Independent Contractor. | Two things can only be | |Mail: dave@daveg.ca | equal if and only if they | |http://daveg.ca | are precisely opposite. | =========================================================GLO================ 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.
Download the latest memtest86+ ISO image from www.memtest.org, burn it to
CDROM, and see if all your RAM passes.
>>>>> "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. Dave. -- ============================================================================ |David Gilbert, Independent Contractor. | Two things can only be | |Mail: dave@daveg.ca | equal if and only if they | |http://daveg.ca | are precisely opposite. | =========================================================GLO================ Responsible Changed From-To: freebsd-amd64->bz gnn and me will work on fast_ipsec so take this PR. I have an amd64 machine here and could reproduce a panic even w/o a policy loaded. y2k# setkey -D [thread pid 471 tid 100057 ] Stopped at kdebug_sockaddr+0xb0: decl 0xffffffffffffff8d(%rax) db> where Tracing pid 471 tid 100057 td 0xffffff010bfc7750 kdebug_sockaddr() at kdebug_sockaddr+0xb0 raw_usend() at raw_usend+0x74 key_send() at key_send+0xa sosend() at sosend+0x726 kern_sendit() at kern_sendit+0x12f sendit() at sendit+0x1d3 sendto() at sendto+0x52 syscall() at syscall+0x350 Xfast_syscall() at Xfast_syscall+0xa8 --- syscall (133, FreeBSD ELF64, sendto), rip = 0x8007e9a6c, rsp = 0x7fffffff6b98, rbp = 0x2 --- db> show alllocks db> State Changed From-To: open->closed PR amd64/89261 addresses the same problem and the solution is there. Please follow PR 89261 instead. Thanks for reporting. |
