Date: Sun, 10 Feb 2002 19:03:05 -0800 From: Terry Lambert <tlambert2@mindspring.com> To: Bill Kish <kish@coyotepoint.com> Cc: hackers <freebsd-hackers@FreeBSD.ORG> Subject: Re: Debugging double page fault Message-ID: <3C673469.EC159823@mindspring.com> References: <3C6478BE.BE6F5A70@coyotepoint.com> <3C6497EA.73CDEC64@mindspring.com> <3C668925.EFF8FA34@coyotepoint.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Bill Kish wrote: > Nothing's changed hardware or configuration wise. You will not believe how many times I've seen this, and it comes down to "well, there was one thing, but it can't _possibley_ have been that!". > Since this system handles alot of network traffic, I was > thinking it might be some kind of martian packet causing > the crash. I'd seen that happen before with RR pings from > Linux systems, but at least had a reasonable dump to work > with. > > I'll try swapping out the hardware and see what happens. > But I'm still curious about a methodology for analyzing > such dumps. Normally, you cause a break to the debugger. If you can stop in the second fault, then adding a record of the previous fault "frame" to the first time fault handler will let you look at the information in the second case. Normally, if you are getting this kind of fault, then you are trying to execute on the stack. If it were a stack overflow, then you can increase the number of stack pages by rebuilding the kernel with a larger number. This is unlikely to be the problem, since you aren't running the newer ATA code with a kernel that old. You might also want to work on replaying traffic, if you think it's a killer packet. You need to capture the trace as a first step towards that. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3C673469.EC159823>