Xref: utzoo unix-pc.general:7219 comp.sys.att:11472
Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!nwnexus!cjsa!jeff
From: jeff@cjsa.wa.com (Jeffery Small)
Newsgroups: unix-pc.general,comp.sys.att
Subject: The 3B1 and the Bad Block
Summary: How do you add the "correct" bad block to the Bad Block Table?
Keywords: unix-pc 3b1 bad block help
Message-ID: <1991Jan12.014524.300@cjsa.wa.com>
Date: 12 Jan 91 01:45:24 GMT
Organization: C. Jeffery Small and Associates
Lines: 73

I guess I need the help of some of you experts!

Environment:	3B1, 2Mb RAM, (1) 67-Mb internal disk,
		(2) RS232 expansion cards, unix-3.51m, WD2010

I have been getting a number of the following HDERR reports in
/usr/adm/unix.log (long lines have been wrapped for readability):


    HDERR ST:51 EF:40 CL:E3 CH:3 SN:7 SC:1 SDH:22 DMACNT:FFFF DCRREG:9A
    MCRREG:8F00 Thu Dec 27 11:11:00 1990

    WD2010 ST=/Sekg/Err/ EF=/CRC/ cy=995. sc=7. hd=2. dr#=0. MCR2:0x0
    Thu Dec 27 11:11:04 1990
    
    drv:0 part:2 blk:58635 rpts:1 Fri Jan 11 07:19:14 1991


So, I used Brant Cheikes' great "bf" program to determine that block number
58635 was allocated to inode #2583.  ncheck then told me that this was
currently assigned to my 1Mb-sized Cnews "history" file.  Next, I tried to
make a copy of this file and after about 8 attempts I had a successful read
of this data block.  I renamed the bad file and installed the good copy as
the "history" file.

Although I have three of these machines (one dating back to 1985) I have
never had a repeatable HD error before (just lucky I guess) so I was now
ready to add my first block to the Bad Block Table.  I booted the revised
(WD2010) s4diag diskette, selected test 3 "Enter Bad Blocks" and when
prompted, selected option #3 to specify by logical block number.  At the
prompt for the block number I entered:  58635.  The diagnostic routine then
responded with [approximately]:

    Added bad block: Cylinder 916, Track 1, Sector 6.
    Used Track 7329 as the alternative.

Cylinder 916?  Shouldn't this be 995?  At the next prompt to
(Add, Delete or Ignore) I entered an "I" and then thought I would try
this procedure again.  I re-ran the test and re-entered block #58635 and
everything occurred as described above but now the report read:

    Added bad block: Cylinder 916, Track 1, Sector 7.
    Used Track 7329 as the alternative.

Running the expert subtest #6,12 to display the BBT, I now saw that I had
16 BBT entries with the last two being the 916,1,6 and 916,1,7 as reported
above.

Not sure what to do next, I rebooted the machine.  As you might expect, the 
problem was not resolved.  The bad file still contained the bad block and
"cat file" yielded additional error reports to unix.log.

So my questions are:

1:  Why didn't the block number in the error report (58635) work?  What
    (probably obvious) idea am I missing and how should I properly fix this
    problem?

2:  Did I just (potentially) hose some disk files by entering the two good
    sectors into the BBT or did the contents of these sectors get copied to
    the alternate track by the diagnostic routine?  If the data was not
    copied, is there a way that I could determine the files (if any) which
    were damaged?

3:  Can I use the same diagnostic routine to recover the use of these two
    sectors by "Deleting" them from the BBT?  If not, what is the "Delete"
    option for?


Any help would be greatly appreciated.  Thanks.
--
Jeff Small                     C. Jeffery Small & Associates    (206) 232-3338
uunet!nwnexus!cjsa!jeff        7000 E Mercer Way,  Mercer Island, WA     98040