Re: Double panics with g_up

I have yet to see any information from you I can use to do debugging.

See our handbook if you are in doubt what we need.

Poul-Henning

In message <20030911090848.GA919_at_nagual.pp.ru>, Andrey Chernov writes:
>I saw this already 5 times. It is _always_ double panic. Second panic may 
>vary (f.e. clock, etc) but first one _always_ in g_up. Since second panic 
>is on the way, there is no usable stack trace remains.
>
>My suggestion: can we add sysctl to NOT sync disk after panic but reboot 
>immediately to preserve stack frame (for remote machine)?
>
>Fatal trap 12: page fault while in kernel mode
>fault virtual address = 0x24
>fault code            = supervisor read, page not present
>instruction pointer   = 0x8:0xc017fd3b
>stack pointer         = 0x10:0xcd36bb70
>frame pointer         = 0x10:0xcd36bb84
>code segment          = base 0x0, limit 0xfffff, type 0x1b
>= DPL 0, pres 1, def32 1, gran 1
>processor eflags      = interrupt enabled, resume, IOPL = 0
>current process               = 3 (g_up)
>trap number           = 12
>panic: page fault
>
>syncing disks, buffers remaining...
>
>Fatal trap 12: page fault while in kernel mode
>fault virtual address = 0x24
>fault code            = supervisor read, page not present
>instruction pointer   = 0x8:0xc017fd3b
>stack pointer         = 0x10:0xcd377c84
>frame pointer         = 0x10:0xcd377c98
>code segment          = base 0x0, limit 0xfffff, type 0x1b
>= DPL 0, pres 1, def32 1, gran 1
>processor eflags      = interrupt enabled, resume, IOPL = 0
>current process               = 24 (irq15: ahc0)
>trap number           = 12
>panic: page fault
>Uptime: 2d3h22m53s
>

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk_at_FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.