Return to BSD News archive
Newsgroups: comp.os.386bsd.bugs
Path: sserve!newshost.anu.edu.au!munnari.oz.au!bunyip.cc.uq.oz.au!s1.elec.uq.oz.au!raboczi
From: raboczi@s1.elec.uq.oz.au (Simon Raboczi)
Subject: Re: Peculiar SLIP/serial line hang
Message-ID: <raboczi.747126324@s1.elec.uq.oz.au>
Sender: news@bunyip.cc.uq.oz.au (USENET News System)
Nntp-Posting-Host: s3.elec.uq.oz.au
Organization: Prentice Centre, University of Queensland
References: <CCqqxG.3Cs@bernina.ethz.ch>
Date: Sat, 4 Sep 1993 07:05:24 GMT
Lines: 37
torda@igc.ethz.ch (Andrew Torda) writes:
>...
>If I send a boatload of data over the slip line (like an ftp
>transfer) eventually I will get a com0 silo overflow. No
>surprise.
>Some time afterwards, packets will stop moving between my
>machine and the other end. This is quite clear from the lack
>of activity and the lack of flashing lights on the modem.
>Now, the interesting and reproducible part.
>If I then, open the serial port with another process (like
>tip directly to the port), there is a flurry of activity and
>slip packets move again.
>I am so baffled, I don't even know where to start looking
>for an explanation for this behaviour.
Hee hee hee hee! :)
I used to have this trouble myself, or something very similar.
When my SLIP-link `clogged' this way, I executed the slattach
again (which would block, but wake up the serial line) and
killed the extra slattach. I even had a script named `flog'
for this, which I was wont to apply frequently during large
FTP transfers.
Okay, it doesn't help much, but it's kind of amusing... ;)
Incidentally, the serial line became a great deal more reliable
after I switched the 16450 UART for a '550, and became totally
reliable after switching to the sio driver instead of com.
--
,-_|\ Simon Raboczi (raboczi@s1.elec.uq.oz.au)
/ * Department of Electrical & Computer Engineering
\_.--_/ University of Queensland, St Lucia, Brisbane, Australia
v [Sebkha says, "We live to serve."]