Return to BSD News archive
Path: euryale.cc.adfa.oz.au!newshost.carno.net.au!harbinger.cc.monash.edu.au!munnari.OZ.AU!news.ecn.uoknor.edu!news.eng.convex.com!newshost.convex.com!newsgate.duke.edu!news.mathworks.com!fu-berlin.de!irz401!orion.sax.de!uriah.heep!news From: j@uriah.heep.sax.de (J Wunsch) Newsgroups: comp.unix.bsd.freebsd.misc Subject: Re: Trouble w/ UUCP: ``Timed out when setting MIN to 1; retrying'' Date: 8 Sep 1996 01:37:54 GMT Organization: Private BSD site, Dresden Lines: 28 Message-ID: <50t81i$kf1@uriah.heep.sax.de> References: <87u3tc2h45.fsf@pippin.jblhome.ping.dk> <50r1b4$ja1@symiserver2.symantec.com> Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) NNTP-Posting-Host: localhost.heep.sax.de Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Newsreader: knews 0.9.6 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E tedm@agora.rdrop.com wrote: > First, Taylor UUCP seems to do a "speed mode set" or some such practically > between every byte, and this upsets some cloney buffered serial port chips. This is a side effect of some tcsetattr() call. > Popular wisdom is that the SMC serial port chipsets, while buggy, > have bugs that are at least known about and workarounds are in place > in the sio driver. Confirmation. My ASUS board uses the SMC chip, and i can't blame it for weird behaviour (neither SLIP/PPP/UUCP). > The UMC chipsets are supposed to be the ones to avoid. ...and the biggest problem with them is that their bugs cannot be worked around in software. They totally lose sync if being reprogrammed while data are flowing in. Naturally, you cannot stop the external data source :), nor can you obtain the status of incoming bits until the first full byte went in (so the Rx Ready bit is set). -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-)