Return to BSD News archive
Path: sserve!newshost.anu.edu.au!harbinger.cc.monash.edu.au!yarrina.connect.com.au!warrane.connect.com.au!kralizec.zeta.org.au!not-for-mail From: bde@kralizec.zeta.org.au (Bruce Evans) Newsgroups: comp.os.386bsd.questions Subject: Re: SIO/COM driver 16550A limitations? Date: 8 Jul 1994 20:35:18 +1000 Organization: Kralizec Dialup Unix Sydney - +61-2-837-1183, v.32bis v.42bis Lines: 36 Message-ID: <2vja56$2k3@kralizec.zeta.org.au> References: <1994Jul4.130216.19263@bruce.cs.monash.edu.au> <PHILS.94Jul7114917@satori.tv.tek.com> NNTP-Posting-Host: kralizec.zeta.org.au In article <PHILS.94Jul7114917@satori.tv.tek.com>, Phil Staub <phils@tv.tek.com> wrote: >In article <1994Jul4.130216.19263@bruce.cs.monash.edu.au> maurice@bruce.cs.monash.edu.au writes: > >> From article <2v1kdv$qal@lastactionhero.rs.itd.umich.edu>, by pha@umich.edu (Paul Anderson): >> > I just installed FreeBSD 1.1.5R (what a phenomenal job, folks). >> > >> > The man pages for SIO and COM both allude to problems with cheap >> > clone 16550A serial boards (which I have). What is the failure >> > mode for these? ... I think the gripe in the old man pages is about the original buggy 16550 chips. It's probably hard to buy those now even if you try. I don't know of any relevant problems caused by cheap _boards_. However, recently and not so recently, more buggy not-quite-16550 chips have been released. There's one in a standard PCI chipset, and some in modem chipsets. >I am having the same problem. In fact any attempt to access /dev/tty0* >in any way (even the "stty -f /dev/tty00 clocal" suggested above) >results in the frozen console that Paul reported. Accessing >/dev/ttyi00 seems to work ok (i.e., I can successfully do the stty), >but it doesn't prevent the hanging when I then try to touch tty00. This sounds like the PCI bug. It causes hangs if the FIFO is enabled while there is data in the input buffer. Resetting the FIFO after enabled it does not work. The 1.1 version of sio attempted to reset the FIFO at the same time as enabling it so has more chance of working. The easiest workaround is to not use the FIFO (use flags 0x02 for the broken sio devices in the kernel config file). I know less about the bug in modem chipsets. In one instance it seemed to have to do with abnormal transmitter status bits causing an infinite loop when the device speed is programmed. This loop can be interrupted so the problem is not as critical. -- Bruce Evans bde@kralizec.zeta.org.au