Date: Thu, 5 Sep 2002 10:16:18 -0700 (PDT) From: Julian Elischer <julian@elischer.org> To: Christian Zander <zander@minion.de> Cc: freebsd-hackers@freebsd.org Subject: Re: double page fault(s) Message-ID: <Pine.BSF.4.21.0209051010290.36697-100000@InterJet.elischer.org> In-Reply-To: <20020905190420.H649@chronos>
next in thread | previous in thread | raw e-mail | index | archive | help
if you know which process stack was operational at the first page fault, then you can dump THAT stack with 'tr PID' the error messages MIGHT give thatinfo.. failing that you MAY have to try all the active pids (ps in ddb should give you a hint as to which to try.. it will not be sleeping) until you find one which has a stack that is in the right neighborhood. It MAY not work however.. it all depends on a number of factors, such as teh last time the process run and how much damage has occured. Also the previos stack pointer is savevd among the stuff saved on the double fault.. you MAY be able to find it.... (check an x86 manual) Then you can dump it using x/xxxxxxxxxxxxxxxxx and maybe you can back track it by hand.. just some ideas... On Thu, 5 Sep 2002, Christian Zander wrote: > Hi all, > > I've been experiencing double page faults on several FreeBSD 4.x > systems with a custom device driver, which I believe is somehow > responsible. Searching the freebsd-hackers mailing list archives > I found several mentions of problems similar to mine; it seemed > that the consensus is that this problem is almost always caused > by kernel stack mistreatment. > > I spent quite a bit of time trying to approach the problem with > DDB and KGDB, but while I'm able to break into the debugger when > the second fault occurs, I have not yet been able to investigate > the offending stack. One approach I've looked at was suggested > in response to the "Debugging double page fault" thread; it was > (if I understand it correctly) suggested that if one can find a > way to break on the second handler, then by saving a copy of or > a reference to the first trap frame in the first fault handler, > one would be able to investigate that frame (from said second). > > Unfortunately, my knowledge of the FreeBSD kernel is still poor, > I'm unsure about the appropriate places to catch the first trap > and where to save the fault frame. I'm hoping that you can point > me at additional sources of information or have other hints. > > Thanks, > > -- > christian zander > zander@minion.de > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > 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?Pine.BSF.4.21.0209051010290.36697-100000>