Date: Mon, 26 Jun 1995 05:18:32 +1000 From: Bruce Evans <bde@zeta.org.au> To: bde@freefall.cdrom.com, pete@puffin.pelican.com Cc: current@freebsd.org Subject: Re: cvs commit: src/sys/i386/isa sio.c Message-ID: <199506251918.FAA05169@godzilla.zeta.org.au>
next in thread | raw e-mail | index | archive | help
>> 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 I haven't seen the problem for any part later than 1988 but I don't think I have any "real NS" parts (I may have a couple of Intel ones). >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. Try it and see. >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 sio uses several methods to reduce the problem so it may not occur very often. In particular, it is recovered from on the next input interrupt, so streaming protocols recover within a few character times. >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. I've been complaining about this for a year or two. I think it is because tcp/ip wasn't designed for bidirectional interface. My standard benchmark is: time rcp machine1:/kernel machine2:/tmp/kernel & \ time rcp machine2:/kernel machine1:/tmp/kernel & This takes about twice as long as would separate rcp's because acks get queued behind large amounts of data and arrive too late to keep the data streaming. >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. sio tries to avoid this problem by reading the interrupt id register as little as possible. Unfortunately it has to read it at the start of the (loop in the) interrupt handler for the COM_MULTIPORT case. Otherwise, it only reads it at the end of the (loop in the) interrupt handler. It only has to do this to handle edge triggering braindamage. Also, sio doesn't rely on the interrupt id register for anything except the end-of-interrupt condition. Output-possible is checked for directly after checking (directly) for input. This should completely fix the above bug - if a higher priority event is seen, then output will be checked for a little later (later enough for races not to be a problem). So perhaps LOSESOUTINTS is never necessary. But there may be other chip bugs. I think there is a similar problem with lost modem status interrupts. Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199506251918.FAA05169>