Matthew Dillon wrote:
>:I thought this was just a problem with the oct 16 copy I had, since I
>:knew that was when the VFS layer was in severe flux, but I've reproduced
>:it several times afterwards with an dec 5 copy as well.
>:
>:The following appears to semi-reliably trigger the abovementioned error
>:message:
>:
>:make buildworld/quickworld
>:make buildkernel KERNCONF=DOOM
>:make installkernel KERNCONF=DOOM
>:make installworld
>:
>:It appears to most commonly happen during buildkernel, but I'm not
>:entirely sure.
>:
>:The message in the subject pops up regularly, everything related to disk
>:seems to grind to a halt, and I'm unable to shut down the box in a
>:normal fashion. This is on a playbox, so if you're unable to reproduce
>:this, I'll be happy to assist in trying to find the bug, given good
>:enough instructions for how to proceed.
>
> Jan, see if you can get kernel core out of it. You may have to
> set sysctl kern.sync_on_panic=0, but then ctl-alt-esc'ing into
> the debugger (when the machine is in this locked up state) and
> typing 'panic' <return> (probably <return> a second time) should
> do it if you have the dumpdev set.
>
>
Looks like I've been fortunate enough to think this far ahead,
ctrl-alt-esc worked. However, it isn't coring properly, it just says
"syncing disks...", and that's about it.
Actually, that isn't quite true. The following is displayed (not sure if
this'll help at ALL, but better too much information than too little
(this is after performing the two steps you specified):
<quote>
vnlru_proc: vnode recycler stopped working!
Debugger("manual escape to debugger")
Stopped at Debugger+0x34: movb $0,in_Debugger.357
db> panic
panic: from debugger
panic(0,c03c4c88,c03c4c8c,ca9a0b40,c0137d75) at panic+0x84
panic(c035de6a,ca9a0bec,c0137d13,c033149,0) at panic+0x84
db_panic(c033149c,0,ffffffff,ca9a0b74,3) at db_panic+0xd
db_command(c03ca2c4,c03ca0e4,c03c4c88,c03c4c8c,c035de7a) at db_command+0x1f3
db_command_loop(0,ca9a0c34,c0331166,3,0) at db_command_loop+0x67
db_trap(3,0,1,0,0) at db_trap+0xb5
kdb_trap(3,0,ca9a0c6c) at kdb_trap+0x10a
trap(18,c0340010,10,0,c0435060) at trap+0x4a0
calltrap() at calltrap+0x18
---trap 0x3, eip = 0xc033149c, esp = 0xca9a0cac, ebp = 0xca9a0cb4 ---
Debugger(c03b5fc9) at Debugger+0x34
scgetc(c043ac60,2,c0ac1500,c0433760,c0416240) at scgetc+0x406
sckbdevent(c0433760,0,c043ac60,c0ac1500,0) at sckbdevent+0x1c9
atkbd_intr(c0433760,0,ca9a0d50,c034b6e1,c0433760) at atkdb_intr+0x22
atkbd_isa_intr(c0433760,63001a,0,4,ca9a0d84) at atkbd_isa_intr+0x18
intr_mux(c043a924) at intr_mux+0x21
ithread_handler(1,0,0,0,0) at ithread_handler+0x7a
lwkt_exit() at lwkt_exit
syncing disks...
</quote>
The machine itself is utterly non-responding beyond this. I hope this
output helps (I've doublechecked that I typed it in correctly, I'm
hoping I haven't missed anything). I'm going to leave it running
overnight, to see if it'll eventually dump core.