Date: Wed, 27 Mar 1996 15:25:57 +0100 (MET) From: "Georg-W. Koltermann" <gwk@racer.dkrz.de> To: rgrimes@GndRsh.aac.dev.com Cc: jas@flyingfox.COM, hardware@FreeBSD.org Subject: Re: motherboard and Ethernet card recommendations Message-ID: <199603271425.PAA03923@racer.dkrz.de> In-Reply-To: <199603270504.VAA07861@GndRsh.aac.dev.com> (rgrimes@GndRsh.aac.dev.com)
next in thread | previous in thread | raw e-mail | index | archive | help
> > > I hope this is not so frequently asked a question that I'm being > > annoying, but I would appreciate any words of wisdom regarding > > Pentium motherboard and Ethernet card selection for a FreeBSD machine. > > > > The criteria for the motherboard are: > > > > * rock solid stable; > > * no buggy chipsets or goofy cache coherency problems; > > * no weird hardware limitations. > > XX. ASI ASUS-PCI/I-P55TP4N Motherboard w/256K 8nS PBurst SRAM cache $ 210.00 > ... > > -- > Rod Grimes rgrimes@gndrsh.aac.dev.com > Accurate Automation Company Reliable computers for FreeBSD > Wasn't there some talking about buggy UMC chips on that board? Or does the ...TP4N board use different chips than the ...TP4XE? And, BTW, does anyone know if their just-to-be released Motherboards with the 430HX (aka Triton-2) use any buggy chips? I'm about to buy one of those when they've arrived the local dealers. I checked http://192.72.126.1/Products/spec.html and found nothing apparent. Nice pictures, though! Regards, Georg-W. Koltermann, gwk@cray.com > Date: Sat, 24 Feb 1996 08:01:17 +1100 > From: Bruce Evans <bde@zeta.org.au> > Cc: freebsd-bugs@FreeBSD.ORG > Sender: owner-bugs@FreeBSD.ORG > Precedence: bulk > > > >> 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?199603271425.PAA03923>