From owner-freebsd-hackers Sun Feb 10 19: 3:18 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from avocet.prod.itd.earthlink.net (avocet.mail.pas.earthlink.net [207.217.120.50]) by hub.freebsd.org (Postfix) with ESMTP id 22FCE37B402 for ; Sun, 10 Feb 2002 19:03:15 -0800 (PST) Received: from pool0316.cvx21-bradley.dialup.earthlink.net ([209.179.193.61] helo=mindspring.com) by avocet.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16a6kL-0005tq-00; Sun, 10 Feb 2002 19:03:14 -0800 Message-ID: <3C673469.EC159823@mindspring.com> Date: Sun, 10 Feb 2002 19:03:05 -0800 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Bill Kish Cc: hackers Subject: Re: Debugging double page fault References: <3C6478BE.BE6F5A70@coyotepoint.com> <3C6497EA.73CDEC64@mindspring.com> <3C668925.EFF8FA34@coyotepoint.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG 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