Date: Tue, 13 Aug 1996 23:07:20 -0400 From: Thomas David Rivers <ponds!rivers@dg-rtp.dg.com> To: sag.space.lockheed.com!handy@dg-rtp.dg.com, ponds!rivers Cc: freebsd-hackers@freefall.freebsd.org Subject: Re: sio issues (silo overflows on a pentium, locked in ttywait, etc...) Message-ID: <199608140307.XAA03390@lakes>
next in thread | raw e-mail | index | archive | help
> > >However, I'm rather distressed to see: > > > > sio0: 1 more silo overflow (total n) > > > > I get this sort of stuff all the time, though it doesn't (in my case) (as > far as I can tell) seem to affect anything. I've got it on a 486 with a > MOUSE on the serial port and a 586 w/ mouse and modem on the two ports. I > don't have the brainpower to understand what it all means though. > > Brian > Basically, it means that your machine was not able to service "interrupts" at some level, so that bits were overrun on the serial port. The bits from the 232 hardware come "screaming" into your computer, and if the software doesn't handle them fast enough, you get a "silo overflow" [I have interrupts in quotes there because the sio driver uses two queues for handling hardware interrupts vs. deliverying bytes to the system... The idea is that the driver can take the hardware interrupt and place the bits into the secondary queue without having to handle anything else, making it respond faster to the UART hardware.] Most of the time, with say, kermit/PPP or SL/IP - higher-level protocols detect the transmission error and take the necessary steps to see that the packet is retransmitted. If your packet size is appropriate, and your baud rate is high enough, you don't even notice the retransmissions. With the mouse, I believe, you would notice things like your pointer bouncing madly around, or, if the bit(s) were dropped in just the right way, not moving around at all, then suddenly working again. Your problem is likely that crtscts isn't set on the serial line your mouse are attached to, or can't/shouldn't be set because the mice don't support it. For serial mice, you should be able to set the baud rate way down (e.g. 1200), which should completely avoid the problem. See your XF86Config file (the XF86Config.eg will help) for where to set the baud rate. My issue is that I shouldn't be seeing these at all on a P75. Furthermore, I'm seeing lockups in ttywait on a 386, which shouldn't happen.... after the lockup is resolved (drainwait expires?), I can re-open the serial line, but that doesn't help a SL/IP session, I have to kill the slattach and start a new one. So, I have to be around when this happens (usually very soon...) [Hmmm... I'm seeing these silo overflows during install time, and if crtscts is off by default, then perhaps the -h on the slattach isn't effective? If so, maybe we want to change the install to lock -crtscts on the dialout devices?... just a thought...] - Dave Rivers -
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199608140307.XAA03390>