*BSD News Article 3601


Return to BSD News archive

Newsgroups: comp.unix.bsd
Path: sserve!manuel!munnari.oz.au!uunet!zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!ucselx!crash!fpm
From: fpm@crash.cts.com (Frank Maclachlan)
Subject: 386BSD-0.1 bad144 bad sector handling
Organization: CTS Network Services (crash, ctsnet), El Cajon, CA
Date: 13 Aug 92 10:22:22 PDT
Message-ID: <1992Aug13.102222.20793@crash>
Followup-To: fpm@crash.cts.com (Frank P. MacLachlan)
Summary: It works w/ explanation
Keywords: bad144, defects, ESDI
Sender: fpm@crash.cts.com (Frank P. MacLachlan)
Lines: 34

Greetings:

Bad144 bad sector handling in the 386BSD-0.1 wd driver is not
broken if you take certain precautions.  My experience is with
a Western Digital WD1007v-se2 ESDI controller and an Imprimus
(aka CDC) 94166-182 drive.

When you format the drive, make sure that you mark the defects.
This guarantees that any attempt to read or write a sector
containing a defect will return an error.  The WD1007v on-board
format utility allows defects to be automatically marked from
the the drive's defect list.

The wd driver, as noted by others here, checks only if the first
sector in a transfer is in the bad144 table.  If it is, a replace-
ment sector is used.  But what about sectors 2 and beyond in a
mult-sector transfer?  Consider a multi-sector transfer where
one of the sectors other than the first sector is in the bad144
table and has been properly marked as bad.  The driver scans the
bad144 table, doesn't find the sector and a multi-sector transfer
with no sector replacement is started.  The driver transfers the
sectors up to the sector containing the defect and then gets an 
error on the sector containing the defect (note that the sector
has been marked and will *always* return an error).  The driver
sees the error in wdintr and, as part of its error recovery logic,
restarts the transfer at the sector containing the error by calling
wdstart with a single sector transfer request.  The bad sector is
the first (and only) sector in the transfer and is correctly replaced
by the bad144 table lookup code.

--
UUCP: {hplabs!hp-sdd ucsd nosc}!crash!fpm
ARPA: crash!fpm@nosc.mil
INET: fpm@crash.cts.com