Date: Fri, 01 Sep 2000 18:49:20 -0400 From: Allen Landsidel <all@biosys.net> To: freebsd-stable@FreeBSD.ORG Subject: Re: bad 16550A maybe? Message-ID: <4.3.2.7.2.20000901181508.00b0ecb8@mail.megapathdsl.net> In-Reply-To: <Pine.BSF.3.96.1000902074531.8872A-100000@gaia.nimnet.asn.a u> References: <200009011832.MAA37168@harmony.village.org>
next in thread | previous in thread | raw e-mail | index | archive | help
At 08:09 09/02/2000 +1000, Ian Smith wrote: >On Fri, 1 Sep 2000, Warner Losh wrote: > > > In message <200009010501.WAA54972@tao.thought.org> Gary Kline writes: > > : This just showed up on my console (and dmesg) from my new 4.1 system: > > : sio0: 1 more silo overflow (total 1) > > : Could this be why moused is having trouble with recognizing my > > : COM1 mouse? Bad 16550A? > > > > Maybe. silo overflows happen because the machine is too slow to > > service the interrupt before the buffer overflows (but unless it is a > > 386SX25 you should have enough CPU power). It can also be caused by > > baud rate mismatches, but that's fairly rare and unusual (you usually > > get framing errors from a 16550A in this case). This can also be > > caused by other hardware misbehaving and blocking interrupts. It seems a lot of people have forgotten, but the UARTs in x86 machines (and others I suppose) went through various revisions in the old days, the most important of these being the following.. 8250 - Unbuffered, original serial UART. Maximum speed of 9600. Had a bug that generated spurious interrupts when accessed. 8250A - Fixed version of the 8250 8250B - Un-Fixed version of the 8250A, since the XT BIOS was expecting these spurious interrupts and now wouldn't function correctly. 16450 - 115,200 baud, but maximum reliable with no buffer was about 38.4kbaud. 16550 - 115,200 baud, with a 16byte FIFO buffer. These UARTs also had a bug, which rendered the FIFO useless. 16550A - Revision of 16550 with a working FIFO. 16550AF - 16550A capable of higher speed operation, up to 256kbaud. This UART has a bug which can cause character loss when the TX buffer is enabled if the last byte in the buffer has not been completely sent (i.e. still in the shift register). It is entirely possible that the bug exists also in the 16550A, although I am unsure of this. 16550AFN - 16550AF created with new ceramic process. (Unbuffered is sort of a misnomer on the 8250/16450. They both had a 2byte buffer, but for programming purposes, they are unbuffered.) There are many UARTs other than those I have mentioned here, but these are by far the most common to find in any given system. I think special attention should be paid though to the bugs present in the different models, and check to see if code has been implemented to work around these bugs. You may want to try just lowering the trigger level of the buffer one or two bytes. I'd say somewhere around 8-10 is a happy medium between buffer usage and overhead. The lower the level, the more interrupts will be generated, but the less likely a buffer overrun is going to be. Down at zero, you'll generate an interrupt for every byte going over the port, but the chances of a buffer overflow occuring are about nonexistant. Any reasonable machine should be able to handle serial communications with one of these UARTs with no problem whatsoever. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4.3.2.7.2.20000901181508.00b0ecb8>