home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #20 / NN_1992_20.iso / spool / comp / unix / bsd / 5251 < prev    next >
Encoding:
Text File  |  1992-09-08  |  1.9 KB  |  38 lines
  1. Newsgroups: comp.unix.bsd
  2. Path: sparky!uunet!munnari.oz.au!spool.mu.edu!umn.edu!umeecs!quip.eecs.umich.edu!dmuntz
  3. From: dmuntz@quip.eecs.umich.edu (Daniel A Muntz)
  4. Subject: Re: more about 386BSD SLIP
  5. Message-ID: <1992Sep7.193547.6231@zip.eecs.umich.edu>
  6. Sender: news@zip.eecs.umich.edu (Mr. News)
  7. Organization: University of Michigan EECS Dept., Ann Arbor
  8. References: <Sep.7.14.41.53.1992.602@athos.rutgers.edu>
  9. Date: Mon, 7 Sep 1992 19:35:47 GMT
  10. Lines: 26
  11.  
  12. In article <Sep.7.14.41.53.1992.602@athos.rutgers.edu> hedrick@athos.rutgers.edu (Charles Hedrick) writes:
  13. >Aside from the well-known silo overflow problem, I think there's
  14. >another problem in the serial driver.  I just had output hang in SLIP.
  15. >There's a well-known problem that causes output interrupts not to
  16. >happen sometimes.  I've heard people who really know the serial
  17.  
  18. The interrupt occurs, but is lost.
  19.  
  20. >devices claim that with correct interrupt handling code this won't
  21. >happen, but in every piece of device-level code I've seen, it has.
  22. >The problem showed up in SLIP8250 (the MSDOS packet driver -- I have a
  23. >fixed version), in the FTP Inc SLIP implementation (they fixed it a
  24. >couple of years ago), and Linux (until it was fixed several releases
  25. >ago).  The obvious solution is to time out serial writes.  If you send
  26. >a character and don't get output done within a reasonable time, just
  27. >assume the output worked and go ahead with the next.
  28.  
  29. The RT BSD serial driver, which is extremely similar to the 386bsd one, had
  30. a similar problem.  Our first solution was a timeout, but eventually
  31. the problem was found (interrupts were not disabled in a certain place) and
  32. SLIP has worked correctly since with the timeout code removed.  It
  33. is much better to solve the actual problem than to put in a timeout.
  34. Depending on how often you have to fall back on the timeout, throughput can
  35. suffer, especially at speeds >= 57600.
  36.  
  37.   -Dan
  38.