Re: b_to_q to a clist with no reserved cblocks
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. Debugger(panic) Stopped at Debugger+0x40: xorl%eax,%eax db t 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 = 0xbfbfe9cc --- I have a dump, if it'd help. Bill To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: b_to_q to a clist with no reserved cblocks
On Sun, 10 Mar 2002, Robert Watson wrote: Just noticed the following for the first time today? (a) b_to_q console message, and (b), the truncated 'Mar' which presumably has to do with syslogd getting killed, some buffer getting flushed, or the like. The b_to_q thing is what I'm wondering about. # reboot Mar 10 18:36:39 reboot: rebooted by root Mar 10 18:36:39 reboot: rebooted by root Mar 10 18:36:39 reboot: rebooted by root b_to_q to a clist with no reserved cblocks. MarWaiting (max 60 seconds) for system process `vnlru' to stop...stopped Waiting (max 60 seconds) for system process `bufdaemon' to stop...stopped Waiting (max 60 seconds) for system process `syncer' to stop...stopped syncing disks... done Uptime: 16m12s Truncation at Mar is caused by ttymsg() not caring that its messages actually get written. Many messages may be truncated. I normally saw several N's in a row when I debug this last November. That meant that several messages starting with November were truncated to N. ttymsg() checks the result of writev() and is more careful if writev() returns EWOULDBLOCK, but for non-synchronous ttys like serial ttys, writev() normally just buffers the data and it takes a tcdrain() to ensure that the data has at least been transmitted. Unfortunately, there is no way to determine if the data has been transmitted without blocking, and ttymsg() doesn't want to block. ttymsg() compounds the error by using non-blocking mode in most cases. When non-blocking mode is in effect at last-close time, it tells close() to discard the data instead of blocking. The last-close sometimes occurs in exit() when blocking in it is very inconvenient because it gives an unkillable (half dead already) process. When writev() returns EWOULDBLOCK, ttymsg() switches to blocking mode and can generate a horde of blocked or unkillable children. 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. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
