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