>I don't know exactly what causes the b_to_q message. It is most likely
>a race in close. You can first-open tty's that are blocked in last-close,
>and having this open succeed is very important for unblocking the close
>usi9ng "comcontrol /dev/foo drainwait <small>", but the tty system doesn't
>seem to do nearly enough to handle races here.
It happened to me on shutdown, with a serial console.
Mar 15 00:58:10 stash reboot: rebooted by fenner
panic: b_to_q to a clist with no reserved cblocks.
Stopped at Debugger+0x40: xorl %eax,%eax
Debugger(c03ebb5b) at Debugger+0x40
panic(c03f18c0) at panic+0x70
b_to_q(c7f9bb14,35,c1361a38,0,c7f9bcc8) at b_to_q+0x35
ttwrite(c1361a00,c7f9bcc8,20011,c04b5e80,c7f9bbb4) at ttwrite+0x34c
siowrite(c04b5e80,c7f9bcc8,20011,c04b5e80,c7f9bb80) at siowrite+0x78
cnwrite(c04b63d0,c7f9bcc8,20011,c04b63d0,35) at cnwrite+0x74
spec_write(c7f9bc20,c7f9bc34,c02b0c23,c7f9bc20,35) at spec_write+0x5d
spec_vnoperate(c7f9bc20,35,c7615500,0,11) at spec_vnoperate+0x15
vn_write(c1392b40,c7f9bcc8,c0a8c980,0,c7615500) at vn_write+0x19f
writev(c7615500,c7f9bd20,8054000,bfbfef64,bfbfef34) at writev+0x19a
syscall(2f,2f,bfbf002f,bfbfef34,bfbfef64) at syscall+0x278
syscall_with_err_pushed() at syscall_with_err_pushed+0x1b
--- syscall (121, FreeBSD ELF, writev), eip = 0x280aae73, esp = 0xbfbfe960, ebp =
I have a dump, if it'd help.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message