Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 alpha 4/15/85; site munnari.OZ Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!think!harvard!seismo!munnari!kre From: kre@munnari.OZ (Robert Elz) Newsgroups: net.unix-wizards Subject: Re: A very strange 4.2 looping problem (rather long) Message-ID: <993@munnari.OZ> Date: Sun, 27-Oct-85 08:57:49 EST Article-I.D.: munnari.993 Posted: Sun Oct 27 08:57:49 1985 Date-Received: Tue, 29-Oct-85 01:20:30 EST References: <1504.phil.Dione@Rice> Organization: Comp Sci, Melbourne Uni, Australia Lines: 24 Summary: That is an old (well known?) DZ problem In article <1504.phil.Dione@Rice>, phil@RICE.EDU (William LeFebvre) described a problem that he found to be a broken DZ. This is a fairly old problem - the original 32V dz driver had a special hack in it to work around this (though when it occurs its not usually as serious as you describe - it usually goes away after a reboot, for a while). Some dz's seem to like to give transmit interrupts when the transmit clock is off. The 4.x bsd driver when it gets a transmit interrupt when there is no data to send simply disables the transmit clock, if you have one of these broken dz's that doesn't do a lot of good. Fortunately, all that's needed is to give it a character to send, with the clock still off, and the dz generally happily goes back to sleep for a while. That's what the 32v driver did. I'm not sure why Berkeley deleted this hack, but I guess there aren't that many broken dz's about. I have one (of 7) that does this, sometimes a dozen times a day, sometimes not for weeks, I guess I should have DEC replace it, but with the driver hack installed it doesn't do a lot of harm. It certainly helped when it first occurred here that I knew of the couple of lines of code in the 32v dz driver. Robert Elz seismo!munnari!kre kre%munnari.oz@seismo.css.gov