home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / unix / amiga / 2031 < prev    next >
Encoding:
Text File  |  1992-08-26  |  2.2 KB  |  51 lines
  1. Newsgroups: comp.unix.amiga
  2. Path: sparky!uunet!sun-barr!cs.utexas.edu!usc!sol.ctr.columbia.edu!The-Star.honeywell.com!umn.edu!kksys.com!quest!digibd!kas!rhealey
  3. From: rhealey@kas.helios.mn.org (Rob Healey)
  4. Subject: Re: Kernel Panics
  5. Message-ID: <1992Aug26.145201.18842@kas.helios.mn.org>
  6. Date: Wed, 26 Aug 1992 14:52:01 GMT
  7. References: <DON.92Aug25011100@blkhole.resun.com>
  8. Organization: Rob's home system, Hopkins, MN
  9. Lines: 40
  10.  
  11. In article <DON.92Aug25011100@blkhole.resun.com> don@blkhole.resun.com (Don Phillips) writes:
  12. =I guess I really shouldn't read this news group.  No sooner did I read
  13. =the article about kernel panics, than I had the pleasure of having
  14. =three occur.
  15. =
  16.  
  17.     Looks like you've hit the STREAMS "feature"... From my experience
  18.     it was a ql serial port getting flooded with serial data but
  19.     hardware flow control was held low and no program could consume
  20.     the data coming into the port. When I hardwired RTS<->CTS and
  21.     had a program running on the port to suck up the data the panics
  22.     stopped.
  23.  
  24.     All I can suggest is to make VERY sure peripherals attached to serial
  25.     ports PROPERLY obey full duplex hardware flow control and stop
  26.     sending data when RTS goes low.
  27.  
  28.     There appears to be a STREAMS bottleneck in buffer
  29.     allocation/deallocation that can degenerate into a deadlock and
  30.     either silent death of all STREAMS I/O, serial ports, network
  31.     ports and console screens, or a panic. The first routines after
  32.     the 5 panic rountines in your dump seem to point to the STREAMS
  33.     subsystem.
  34.  
  35.     The only way to avoid the STREAMS problems is to make sure you
  36.     don't create excessive amounts of data sitting in STREAMS buffers
  37.     and not being processed. The modem situation triggers this because
  38.     the incoming data keeps causing new buffers to be needed and
  39.     the system seems to assume that if it lowers RTS as a warning to
  40.     please stop the peripheral will stop. If the peripheral keeps
  41.     going it exhausts STREAMS resources and bad things happen. When
  42.     the peripheral obeys the flow control, buffers aren't used excessively
  43.     and when programs suck off the data again, the buffers aren't
  44.     used excessively.
  45.  
  46.     This is all observation, reality maybe an entirely different reason...
  47.  
  48.         Hope this helps find a workaround for you,
  49.  
  50.               -Rob
  51.