My laptop running -stable from late June panic'd overnight in
softclock:
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0x410
fault code = supervisor read data, page not present
instruction pointer = 0x8:0xffffffff80278619
stack pointer = 0x10:0xffffffffa3543b80
frame pointer = 0x10:0xffffffffa3543bd0
code segment = base 0x0, limit 0xfffff, type 0x1b
= DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags = resume, IOPL = 0
current process = 12 (swi4: clock)
trap number = 12
panic: page fault
KDB: stack backtrace:
panic() at panic+0x1c1
trap_fatal() at trap_fatal+0x298
trap() at trap+0x1a8
calltrap() at calltrap+0x5
--- trap 0xc, rip = 0xffffffff80278619, rsp = 0xffffffffa3543b80, rbp =
0xffffffffa3543bd0 ---
softclock() at softclock+0xa9
ithread_loop() at ithread_loop+0x132
WHen I went looking, I found 3 adjacent callwheel entries had
tqh_first set to 0x400. A single-bit glitch I might write off but the
same 'glitch' in 3 entries seems odd. The 3 cases had tqh_last
pointing at the callwheel slot so they were supposed to be empty.
Does anyone have any ideas?
(kgdb) p softticks
$2 = 0x64f5ebe
(kgdb) p callwheelmask
$3 = 0x7fff
(kgdb) p callwheelsize
$4 = 0x8000
(kgdb) p callwheel[0x5ebe]
$5 = {
tqh_first = 0x400,
tqh_last = 0xffffffff98d6ac80
}
(kgdb) p callwheel[0x5ebd]
$6 = {
tqh_first = 0x0,
tqh_last = 0xffffffff98d6ac70
}
(kgdb) p callwheel[0x5ebf]
$7 = {
tqh_first = 0x400,
tqh_last = 0xffffffff98d6ac90
}
(kgdb) p callwheel[0x5ec0]
$8 = {
tqh_first = 0x400,
tqh_last = 0xffffffff98d6aca0
}
(kgdb) p callwheel[0x5ec1]
$9 = {
tqh_first = 0xffffff00287cdb20,
tqh_last = 0xffffff00287cdb20
}
(kgdb)
--
Peter Jeremy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url :
http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20070804/7c51ebc9/attachment.pgp