DRUN Patch Is Good For WD1010's Too

Craig Johnson vince at tc.fluke.COM
Tue Mar 26 09:15:40 AEST 1991


Thad Floryan graciously posted detailed instructions on how to rework a
7300/3B1 to add the "DRUN Patch" back in January.  At the time, it was
advertised to fix up your system if you were having trouble getting it to
work with a WD2020 disk controller chip.  This was a fix apparently
engineered by Convergent and applied to later production boards prior to
the product's demise.  Convergent's reason for making the change may not
have had anything to do with using WD2020's, but rather to make the hard
disk system more reliable with the WD1010.  I've been repairing a 20M
Miniscribe hard disk that went south on a 7300, and in the process have
found that indeed "normal" systems with WD1010 disk controllers can
benefit from the DRUN patch too.

I have a two-disk system that I was using to implement repairs on the bad
disk.  The bad disk was hooked up as the second disk.  After recovering
all I could of the filesystem on that disk, I undertook reformatting and
running surface checks.  Interestingly, if you use iv to run surface
checks, soft errors get logged to /usr/adm/unix.log.  This is an
advantage over using the diagnostic disk's surface check.  Each time I
would run a surface check, I would get a dozen or so soft errors logged.
They were mostly repeatable as long as you ran surface checks without
reformatting, but much to my frustration, as soon as you were to reformat
and perform another surface test, you would get a whole new set of soft
errors.

After several cycles like this, it occurred to me that maybe my system
didn't yet have the DRUN patch and perhaps that was contributing to the
changing soft errors.  And voila!  After installing the DRUN patch *all*
the mysterious soft errors disappeared.  The result of an "iv -swl"
(surface test, with write pass, repeated 10 times) was not a single
soft error logged!

One word of warning about the DRUN patch.  If you have upgraded to a
two-disk system, you may need to need to connect the wire from 13N pin 2
somewhere different than 13K pin 3 as described in Thad's instructions.
Depending on how you modified your system, you may want to pick up the
data signal from either the input or output side of the Data Separator
PAL (let's see, that should be IC 14L, or close to it; it's the only PAL
near there).  For my system, which uses the unused Drive 1 feature of the
PAL, it was necessary to connect to the PAL's MUX output, pin 19.  I
won't guarantee the timing margins are as good as the fix engineered by
Convergent Technologies, but the fix seems to be working perfectly for
me.

Stayed tuned for another posting regarding tricks to use when repairing
a disk drive from a two-drive system.

---
	Craig V. Johnson		...!fluke!vince
	John Fluke Mfg. Co.			or
	Everett, WA			vince at tc.fluke.com



More information about the Comp.sys.3b1 mailing list