Re: Debugging double page fault
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 [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Debugging double page fault
Hi Terry, Nothing's changed hardware or configuration wise. 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. -=BK Terry Lambert wrote: > Bill Kish wrote: > > I've recently started seeing "double fault" panics on a formerly FreeBSD > > 2.2.8 based system (It's running 2.2.8 as a somewhat embedded OS, so please > > don't flame me about being back rev!) > [ ... ] > > My rough understanding is that double faults are usually the result of > > running out of stack, and that the underlying cause of the panic can probably > > be uncovered if I can find the previous stack . > > > > Can anyone point me towards some hints for debugging this sort of crash. Any > > advice greatly appreciated. > > It's very old. > > This makes me think that it used to work, and now it > doesn't. > > What did you change just before it stopped working? > > If nothing, then it's likely a hardware problem. > > -- Terry -- --- Bill Kish Ph: 650.969.6000 Chief Engineer,12 S. First Street, Suite 616 Coyote Point Systems Inc. San Jose, CA 95113 Email: [EMAIL PROTECTED] http://www.coyotepoint.com/ --- For support call: 1-888-891-8150 Email: <[EMAIL PROTECTED]> --- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Debugging double page fault
Bill Kish wrote: > I've recently started seeing "double fault" panics on a formerly FreeBSD > 2.2.8 based system (It's running 2.2.8 as a somewhat embedded OS, so please > don't flame me about being back rev!) [ ... ] > My rough understanding is that double faults are usually the result of > running out of stack, and that the underlying cause of the panic can probably > be uncovered if I can find the previous stack . > > Can anyone point me towards some hints for debugging this sort of crash. Any > advice greatly appreciated. It's very old. This makes me think that it used to work, and now it doesn't. What did you change just before it stopped working? If nothing, then it's likely a hardware problem. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Debugging double page fault
Hi All, I've recently started seeing "double fault" panics on a formerly FreeBSD 2.2.8 based system (It's running 2.2.8 as a somewhat embedded OS, so please don't flame me about being back rev!) The stack trace looks like: $ gdb -k kernel.0 vmcore.0 GDB is free software and you are welcome to distribute copies of it under certain conditions; type "show copying" to see the conditions. There is absolutely no warranty for GDB; type "show warranty" for details. GDB 4.16 (i386-unknown-freebsd), Copyright 1996 Free Software Foundation, Inc...(no debugging symbols found)... IdlePTD 1aa000 current pcb at 1967a0 panic: double fault #0 0xf010cf63 in boot () (kgdb) bt #0 0xf010cf63 in boot () #1 0xf010d232 in panic () #2 0xf0176f5a in trap_fatal () #3 0xf0176a1c in trap_pfault () #4 0xf01766df in trap () #5 0xf012baae in vget () #6 0xf01558dc in ffs_sync () #7 0xf012cf7b in sync () #8 0xf010ce2d in boot () #9 0xf010d232 in panic () #10 0xf0176ff0 in trapwrite () (kgdb) My rough understanding is that double faults are usually the result of running out of stack, and that the underlying cause of the panic can probably be uncovered if I can find the previous stack . Can anyone point me towards some hints for debugging this sort of crash. Any advice greatly appreciated. -=BK To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
