3.51a keeps dying; even HDB is a mess; any ideas out there?

[Robert J. Granvin]

In article <531 at rbdc.UUCP> andy at rbdc.UUCP (Andy Pitts) writes:
>This has all been said before but I'll post it again for any new people
>who may have missed it.  The standard things that screw up uucp are:
>
>1) The inittab entry.  There MUST be a space preceding the entry for
>the tty line in inittab. example:
> ph1:2:respawn:....
>^ must have leading space.  If the space is missing setgetty will lock.
>
>2) There is a bug on some versions of the eia/ram cards that causes the
>system to crash.  The fix is simple, you just replace a chip.  If you are
>using an eia card call the hotline and ask about it.  This bug only affected
>V3.50 and later if my memory serves.
>
>3) Also I seem to remember reading that the device driver for tty000 was
>brain damaged.  As I recall it will not pass a null (so break won't change
>speed) and hardware flow control did not work.  Some or all of this may
>have been fixed with the fixdisk, but I don't know.  Perhaps someone else
>out there can tell us.  The drivers for the eia cards seem to work however
>(if you change the chip).

The tty000 driver is broken in at least version 3.51.  It is also
broken in 3.5, if I recall correctly.  The inability for it to pass a
NUL (BREAK) is correct.  This also has the additional added benefit
that if you pass (or attempt to pass) a BREAK through the OBM, you
will, or may, hang any device on tty000.  The device on tty000 will
sometimes, though not always, recover itself later.  3.51a resolves
this problem.

The chip relacement for the EIA/RAM boards work like a charm, but if
you've still got an old one, it's in your best interest to get a
replacement chip NOW.  It's not unlikely that these things will become
very scarce in a short time (much like clock replacement batteries are
today).

Re: other messages about uucico crashing systems, etc:

Hardware Flow Control works, but is broken.  HFC will consistantly
repeat a block of data in an entirely predictable way.  The problem
has been reported to ATT, and has also been sent up a level.  This
escalation in priority (which matches that given to the 3.51a kernel
problems) means that it's very likely (though not guaranteed) that
this bug will be resolved either in the next fixdisk, or a future
one.

3.51 has a broken uucico and ph.  These are repaired by the 3.51a
fixdisk.  3.5 is also broken.

The result is that on completion of _some_ connections (there is
little consistency of which connection will be affected) will cause a
system hang, and often a panic.  You are forced to go for the little
black reset button.

ATT claims that ph is the primary culprit, but experience says that
uucico is really the primary blame, although both is broken.
Primarily based on the number of calls and demands they were getting,
the released the 3.51a uucico on an unannounced request-only basis
several months before the 3.51a fixdisks were released.  In (nearly)
every case, replacing the old uucico with this one completely solved
all panic/crash problems.

Now a step further.  When the 3.51a fixdisk was released, all these
problems were resolved, but a new one was introduced.  If you use the
OBM for UUCP connections, you will _still_ get occasional system
panics with a kernel fault.  If you do _not_ use the OBM, this problem
goes away.  The problem has been directly identified to be in the
3.51a unix kernel.  The bug has been identified as well as verified
that it does not exist in previous kernels.  The problem is caused by
the OBM not correctly closing it's last "physical buffer".  It has
been fixed, and the new kernel (3.51b) is currently in testing.  The
fixdisk does not yet exist, so don't call and ask for it.  I'll post a
note when I know it's available.

The 3.51b fixdisk may also resolve several other issues as well.  The
exact contents are not known.

By the way, re: the OBM.  As some have noticed, the OBM firmware will
handshake very happily as an MNP modem.  While it's fully capable of
handshaking MNP, it certainly does not communicate MNP.  If you're
using a Telebit or other MNP capable modem, you must be sure to turn
off MNP abilities for any connection to a 3b1, or your connection will
fail.  By the way, the OBM dialing _out_ will _not_ handshake MNP, so
it looks like someone originally designed it to be an MNP modem, then
that capability was removed.  Unfortunately, it wasn't removed enough.
ATT was surprised.

-- 
"I've been trying for some time to                           Robert J. Granvin
 develop a life-style that doesn't          National Information Systems, Inc.
 require my presence."                                       rjg at sialis.mn.org
    -Garry Trudeau                ...{{amdahl,hpda}!bungia,rosevax}!sialis!rjg