Xref: utzoo unix-pc.general:1025 unix-pc.uucp:40 Path: utzoo!utgpu!water!watmath!uunet!labrea!bloom-beacon!tut.cis.ohio-state.edu!mailrus!uwmcsd1!nic!umn-cs!bungia!sialis!rjg From: rjg@sialis.mn.org (Robert J. Granvin) Newsgroups: unix-pc.general,unix-pc.uucp Subject: Re: 3.51a keeps dying; even HDB is a mess; any ideas out there? Summary: This, and other bug stuff. Keywords: 3.5, 3.51, 3.51a, uucico, ph, HFC, EIA/RAM, tty000, stuff Message-ID: <635@sialis.mn.org> Date: 7 Jul 88 23:02:40 GMT References: <422@kosman.UUCP> <1041@flatline.UUCP> <531@rbdc.UUCP> Reply-To: rjg@sialis.mn.org (Robert J. Granvin) Organization: Dr. Ho Laboratory and Day Care Center Lines: 91 In article <531@rbdc.UUCP> andy@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@sialis.mn.org -Garry Trudeau ...{{amdahl,hpda}!bungia,rosevax}!sialis!rjg