Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uwm.edu!bionet!agate!ucbvax!ucsd!pacbell.com!att!cbfsb!cbnewsc!cmv
From: cmv@cbnewsc.cb.att.com (C M Votava)
Newsgroups: comp.sys.3b1
Subject: Fun with the Bad Block Table
Message-ID: <1991Feb15.231011.19453@cbnewsc.att.com>
Date: 15 Feb 91 23:10:11 GMT
Sender: cmv@cbnewsc.att.com (C M Votava)
Organization: AT&T Bell Laboratories
Lines: 35

Helpful hint:

	Use "iv -tv /dev/rfp000" to get a printout of your bad block table

I don't know how many people knew that, but it was a pleasant suprise
for me! Anyway, I've spent the last few days going through that age-old
exercise that most of you have probably gone through... mapping the unix.log
output to a bad block.

Following in the time worn footsteps of many of you out there, I dutifully
got a copy of John Milton's hardware notes, and painfully figured out what
mathamagic was needed to turn the goofball output in the unix.log file to
physical block number that I could enter into the bad block table.

The device driver was complaining about Cyl:873 Trk:2 Sec:10, so I turned
this into a physical block number, entered it via the diagnostic disk,
rebooted the machine and checked it out --- still got the error! Well, I
must have goofed in the math... re-checked everything... same answer!
Had my wife (the math wiz) check it out... same answer. This was getting
annoying!

OK, maybe sector 10 really means sector 11, so I un-bad-block sec 10 and
bad-block sec 11. Still no good...rats! Well, after diddling around for a
couple of days with this garbage, I finally did something that bad-blocked
BOTH sectors 10 and 11... THAT WORKED! Just to double-check, I took each
out one at a time and re-verified... they BOTH have to be marked as bad
blocks to get rid of that nasty HDERR message.

Anybody know why??? I don't.

Thanks

-Craig Votava

cmv@ihlpf.att.com