Date: Sat, 24 Feb 1996 08:01:17 +1100 From: Bruce Evans <bde@zeta.org.au> To: bde@zeta.org.au, chris@awawak.gna.org Cc: freebsd-bugs@FreeBSD.ORG Subject: Re: problems with serials ports Message-ID: <199602232101.IAA30150@godzilla.zeta.org.au>
next in thread | raw e-mail | index | archive | help
> >> I have problems with my serials ports. My hardware is an ASUS > >> P/I-P55TP4XE(2.4 Rev) with an on-board 'Multi-I/O' using the > >> UMC 8669F Super multi-I/O chip (16550 Fast UART compatible), > >> and P120, 24Mo, NCR810. > >> When I'm using uucp, the chat connexion is well, but the > >> transfert is very slow (200bps) and it fail. I try 2.0.5R, > >> 2.1.0R, 2.2-960130-SNAP, it's the same thing. I try the second > >> serial port at address COM2, COM4 without any more success > Bruce> I have the same motherboard and the same problems in > Bruce> -current. The chat connection often fails too. This seems > Bruce> to be a hardware bug. The bytes received in siointr1() > Bruce> when /etc/rc is sent are: The bug is that the UART loses sync if it is in the middle of receiving data when either the fifo enable bit is toggled or the divisor is written (or perhaps if the divisor latch is toggled). The UART then delivers garbage until data stops arriving or the UART is reprogrammed at a more fortunate time. This happens even at 300 bps with the fifo disabled. I can almost work around the bug by attempting to only write to the critical UART registers immediately after data has arrived. This works best if data is arriving at a high rate. At 300 bps, it requires busy- waiting with interrupts off for 33msec and if data isn't arriving then it requires busy-waiting with interrupts off until data arrives :-(. While testing this, I found that the Startech (?) 16550's on my other system are also buggy. If data is being transmitted and received at full speed (even 300 bps), then some characters are received twice. I can work around this bug by delaying for 3.75 usec between reading the line status register that says that data is available and reading the data. A delay of 2.5 usec isn't quite enough :-(. Using a fifo trigger level of 8 instead of 14 may work too. > >> I try 'ppp' and it works well. > Bruce> zmodem seems to work well too. This might be because the > Bruce> receiver does less output for acks. > >> I try uucp with the same machine on Linux, it works well. Apparently ppp, zmodem and Linux don't stress the UART enough :-). `cat' under Linux-1.2.13 doesn't work well for a stream of data transmitted by a FreeBSD-current system. -current streams the data better than 2.1 and maybe Linux. The problem may be more visible at low speeds since it is easier for the transmitter to avoid dead spots that would allow the receiver to resynchronize. >I got this message on news : >) From: peter@citylink.dinoex.sub.org (System Administration) >) Subject: Taylor-UUCP not running with 16550 SIO (UMC Custom Chip) I saw it in news too. >) When i got angry about that, i started to change values in the uucp-source. >) I succeded in libunix/serial.c by disactivating the "setmin" code (it >) says: "if we can tell the terminal not to return after we have a certain >) number of characters, do so."). uucico consumes some more CPU power now, >) but runs with good performance. >) >) Explanations, anybody? >I comment lines in src/gnu/libexec/uucp/libunix/serial.c (lines 2163-2212) and I have compiled uucico. >UUCP works well now with the on-board serials ports. >But I tell so do you have explanations... >I thinks this help anybody else. This might work be intoducing dead spots. The problem may be more noticeable with uucp because it may do more TIOCSET* ioctls. (The driver only changes the settings for first-open, TIOCSET* ioctls, and last-close.) Other news suggested fixing slave mode to set CRTSCTS. This also might work by introducing dead spots. Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199602232101.IAA30150>