Date: Wed, 27 Mar 1996 09:18:25 -0800 (PST) From: "Rodney W. Grimes" <rgrimes@GndRsh.aac.dev.com> To: gwk@cray.com Cc: jas@flyingfox.COM, hardware@FreeBSD.org Subject: Re: motherboard and Ethernet card recommendations Message-ID: <199603271718.JAA08614@GndRsh.aac.dev.com> In-Reply-To: <199603271425.PAA03923@racer.dkrz.de> from "Georg-W. Koltermann" at "Mar 27, 96 03:25:57 pm"
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? Some of the TP4XE's used UMC floppy/sio chips that had some annoying timeout problems, but I have not had a real problem with them. I see some stuff below from Bruce that indicates some problem, but not a clear solution. :-(. All the TP5N's that I have seen are using a winbond chip for this function. > 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! Yea, right, how can anyone possibly know if there are buggy chips on it before you can even get your hands on a board :-( :-(. > 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 > > > -- Rod Grimes rgrimes@gndrsh.aac.dev.com Accurate Automation Company Reliable computers for FreeBSD
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199603271718.JAA08614>