Date: Sun, 25 Jun 1995 17:55:47 GMT From: Pete Carah <pete@puffin.pelican.com> To: bde@freefall.cdrom.com Cc: current@freebsd.org Subject: Re: cvs commit: src/sys/i386/isa sio.c Message-ID: <199506251755.RAA14968@puffin.pelican.com> In-Reply-To: <199506250451.VAA08729@freefall.cdrom.com>
next in thread | previous in thread | raw e-mail | index | archive | help
In article <199506250451.VAA08729@freefall.cdrom.com> you write: >bde 95/06/24 21:51:02 > Modified: sys/i386/isa sio.c ..... > specified (as before). `LOSESOUTINTS' ports are ones with 0x08 set in > their config flags. Unless this flag is set, it will now take up to one > second to recover from lost output interrupts, if any. Some 8250s and > 16450s lose output interrupts. *ALL* real NS parts (prior to 1993, anyhow) lose output ints, as do the C&T ones then too. This *does* include 16550AFN and may or may not include 16550D (I can test; I just got a set). Don't know about Taiwanese ones. This is per both experience and the NS app notes (they finally admitted it in 1991...) I don't know if NS has ever published a set of mask steps and/or date codes that have/don't have this bug. Because of this, loses-out-ints should be the default and a flag set if a person *knows* that they don't have the bug; more chips have it than don't, and it breaks 'g' protocol pretty badly with a 1-second recovery. The lose-out-int case looks obscure but on a fast bidir conversation it tends to attack every few seconds. (ppp and Taylor 'i' should show it; very little else that most people do would.) My slip connection (to a Cisco term server) tends to not be truly bidirectional; I don't know why; likely has to do with interrupting the modem's compression stream. For those not in-the-know, the loses-out-ints comes about because a read of the interrupt id register resets a pending transmit interrupt whether or not it was the id that was read (read and read-error are higher priority). Some 8259 clones suffered from a similar problem; that is why AUTO_EOI often isn't a good idea. All else in this commit looks fine here; the slow of poll when nothing is open won't hurt LOSESOUTINTS ports either... (one might include open-wait in non-open since getty doesn't depend on output ints until woken up.) -- Pete
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199506251755.RAA14968>