From owner-freebsd-hackers Wed Aug 14 06:20:36 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id GAA28903 for hackers-outgoing; Wed, 14 Aug 1996 06:20:36 -0700 (PDT) Received: from dg-rtp.dg.com (dg-rtp.rtp.dg.com [128.222.1.2]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id GAA28898 for ; Wed, 14 Aug 1996 06:20:33 -0700 (PDT) Received: by dg-rtp.dg.com (5.4R3.10/dg-rtp-v02) id AA19206; Wed, 14 Aug 1996 09:20:01 -0400 Received: from ponds by dg-rtp.dg.com.rtp.dg.com; Wed, 14 Aug 1996 09:20 EDT Received: from lakes (lakes [10.0.0.3]) by ponds.UUCP (8.6.12/8.6.5) with ESMTP id IAA04480 for ; Wed, 14 Aug 1996 08:51:44 -0400 Received: (from rivers@localhost) by lakes (8.6.12/8.6.9) id IAA04184; Wed, 14 Aug 1996 08:58:18 -0400 Date: Wed, 14 Aug 1996 08:58:18 -0400 From: Thomas David Rivers Message-Id: <199608141258.IAA04184@lakes> To: freebsd-hackers@freefall.freebsd.org, lakes!rivers Subject: Re: Recap of sio weirdness, where to go from here... Content-Type: text Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > Thomas David Rivers stands accused of saying: > > > > Mike Smith has made several good points - notably that most "modern" > > 16550s, are, in fact, not 16550s - but some clone chip. That could > > be the situation in my P75 laptop (actually, kinda likely since it > > is a laptop...) However, the 386 and 486 I have which demonstrate > > the problem have *actual* 16550s in them. I know because I replaced > > the 8250s in the serial cards myself... > > Unless these parts are marked "PC16550DN" they are _not_ *actual* > 16550's. They may be a clone produced by another manufacturer, but as > has also been discussed here at great length (Where's Frank D. these > days?), this is _no_ guarantee that the part doesn't do something > funny. Really good point... ummm... let's see here... boy, who ever thought of putting computers on the floor must be.... OK - I'm staring at the part number now... it's a PC16550CN (not DN) - I've had it in service now for almost 5 years... Looks like it's the "real thing". [I'm only looking at the 386dx that locks up... not the other machines, that get silo overflows, I'll get to taking one of those apart today for a memory upgrade...] The total markings on the chip (well, there are two actually) are: 8921B PC16550CN NS16550AFN PATENTED > > Have you tried using 'lptest' and a loopback cable to ascertain whether > these FIFO overflows are real or imaginary? Nope - sounds like a good idea... "lptest"? Are you suggesting that as just something that can generate some data... I usually just cat /etc/passwd :-) I don't have a loopback cable lying around, I'll run out and buy one today. > > > [My point being that while it's certainly possible I have faulty hardware > > on one machine; the likelyhood of that decreases when you consider that > > I can reproduce this symptom on two other, disparit, machines...] > > If you installed the same part in these machines, then the problem may well > still be hardware-related. Please note that I am not trying to suggest > that the fix to your solution cannot possibly lie with a change to the > sio driver, merely that there are a plethora of systems out there using > the sio driver that do _not_ exhibit the problem that you are seeing. That would certainly seem to be the case. I'm wondering if there are also a lot of systems seeing the problem, with just very few reports of it. Also, I'd lay dollars (US ones) to donuts that the lock-up is timing related, and is affected by the fact that the 386 in question also has a 1542B, which could be hogging the bus just a little too long... Maybe I can adjust the 1542B bus timings down a little and solve this problem... - Dave Rivers -