Path: utzoo!utgpu!water!watmath!clyde!cbosgd!mandrill!neoucom!wtm
From: wtm@neoucom.UUCP (Bill Mayhew)
Newsgroups: comp.sys.att
Subject: Re: Query about the quality of UNIX/PCs and 3b1's (really 3b1 unix)
Summary: Even more info about the slowdown
	 bug entered in serial driver in 3.51, perhaps
Message-ID: <912@neoucom.UUCP>
Date: 6 Jan 88 05:32:34 GMT
References: <9691@shemp.UCLA.EDU> <18017@clyde.ATT.COM> <997@bakerst.UUCP> <909@neoucom.UUCP>
Organization: Northeastern Ohio Universities College of Medicine
Lines: 55


I'd like to thank the people who are helping out at AT&T.  Here is
a little more information I've gotten.

The PC=1FC0  (that number is from my memory, so you better not
quote me) that was in the kernel addr fault panic register dump I
got probably really was due to a motherboard oddity not directly
related to the crash.  I called the hotline on Monday and had the
new motherboard Tuesday morning.  Nice job!!  I could have had the
new board Monday, but I didn't want to take time off from work to
go home and let the guy in to fix the 3b.  By the way, I got a good
chance to look over the hardware carefully while the machine was
apart.  The construction is pretty good.  There are two jumpers on
the motherboard- that's all.  The power supply looks decent.  I'd
have to give at least a B+ on the quality of the electronics.  The
loser is the plastic case, which is made pretty chintzy.  I'll give
it a C-.

By the way, doing a motherboard swap to replace the clock battery
is reasonable, since the old motherboard will go back for bench
service and get a new battery.  Since board is good, it'll go back
in the field the next time a battery fails somewhere else.  At
least, you'll be receiving a thoroughly tested board :-).  Since
the board has to come out to swap the battery, it might as well go
in for a bench going-over.  What would have been smarter would be
to make the battery s plug-in type to save some work.  There sure
are a lot of screws holding the motherboard in!

But-- it appears that hardware was not [the only] reson for the
crashing.

The last crash left uucico hung on ph1.  In fact I logged in with
the intent of seeing who was on my machine at 8:00 AM when nobody
should have been on.  It turned out that a uucp transfer had
completed normally at about 2:50 AM and left the port hung since
then.  AT&T told me that they are beginning to suspect that there
are some bugs in the serial/phone port driver(s) in the kernel.
Apparently, the driver starts generating interrupts like mad if it
receives a longbreak signal just at the end of a conversation.
This apparently has something to do with the fact that the internal
modem and serial port share some functions on the same chip.  Since
the serial port and modem interrupts are higher priority than the
window stuff, the output locks up.  Hitting a key does let windows
get control for an instant and it will get a few characters out
while it services the keyboard.  Eventaully the line input buffer
overflows or something like that, and the system goes out to lunch.

The got-cha is that there is a good chance that the disconnect from
another system that has called you is somewhat likely to generate a
few trash characters that are perfect for inciting the lock-up.

Looks like a temporary work-around would be to never let anybody
call *in to* your 3b1.  (If you are using 3.51)

--Bill