Date: Mon, 11 Mar 2002 18:46:54 +1100 (EST) From: Bruce Evans <bde@zeta.org.au> To: Robert Watson <rwatson@FreeBSD.ORG> Cc: <current@FreeBSD.ORG> Subject: Re: b_to_q to a clist with no reserved cblocks Message-ID: <20020311182801.A5653-100000@gamplex.bde.org> In-Reply-To: <Pine.NEB.3.96L.1020310133913.61696U-100000@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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 majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020311182801.A5653-100000>