Return to BSD News archive
Newsgroups: comp.unix.bsd Path: sserve!manuel!munnari.oz.au!spool.mu.edu!umn.edu!umeecs!quip.eecs.umich.edu!dmuntz From: dmuntz@quip.eecs.umich.edu (Daniel A Muntz) Subject: Re: more about 386BSD SLIP Message-ID: <1992Sep7.193547.6231@zip.eecs.umich.edu> Sender: news@zip.eecs.umich.edu (Mr. News) Organization: University of Michigan EECS Dept., Ann Arbor References: <Sep.7.14.41.53.1992.602@athos.rutgers.edu> Date: Mon, 7 Sep 1992 19:35:47 GMT Lines: 26 In article <Sep.7.14.41.53.1992.602@athos.rutgers.edu> hedrick@athos.rutgers.edu (Charles Hedrick) writes: >Aside from the well-known silo overflow problem, I think there's >another problem in the serial driver. I just had output hang in SLIP. >There's a well-known problem that causes output interrupts not to >happen sometimes. I've heard people who really know the serial The interrupt occurs, but is lost. >devices claim that with correct interrupt handling code this won't >happen, but in every piece of device-level code I've seen, it has. >The problem showed up in SLIP8250 (the MSDOS packet driver -- I have a >fixed version), in the FTP Inc SLIP implementation (they fixed it a >couple of years ago), and Linux (until it was fixed several releases >ago). The obvious solution is to time out serial writes. If you send >a character and don't get output done within a reasonable time, just >assume the output worked and go ahead with the next. The RT BSD serial driver, which is extremely similar to the 386bsd one, had a similar problem. Our first solution was a timeout, but eventually the problem was found (interrupts were not disabled in a certain place) and SLIP has worked correctly since with the timeout code removed. It is much better to solve the actual problem than to put in a timeout. Depending on how often you have to fall back on the timeout, throughput can suffer, especially at speeds >= 57600. -Dan