*BSD News Article 19242


Return to BSD News archive

Path: sserve!newshost.anu.edu.au!munnari.oz.au!constellation!osuunx.ucc.okstate.edu!moe.ksu.ksu.edu!hobbes.physics.uiowa.edu!math.ohio-state.edu!cs.utexas.edu!natinst.com!hrd769.brooks.af.mil!hrd769.brooks.af.mil!not-for-mail
From: burgess@hrd769.brooks.af.mil (Dave Burgess)
Newsgroups: comp.os.386bsd.questions
Subject: Re: Hard Disk Errors
Date: 6 Aug 1993 15:10:12 -0500
Organization: Armstrong Laboratory, Brooks AFB, TX
Lines: 88
Message-ID: <23udri$495@hrd769.brooks.af.mil>
References: <23ho68$3ms@stimpy.css.itd.umich.edu> <1993Aug05.175822.1082@crash> <31oq030bd8jL00@amdahl.uts.amdahl.com>
NNTP-Posting-Host: hrd769.brooks.af.mil

In article <31oq030bd8jL00@amdahl.uts.amdahl.com> agc@uts.amdahl.com (Alistair G. Crooks) writes:
>> Alex Tang (altitude@css.itd.umich.edu) wrote:
>> : hard error writing wd0e
>> : fsbn 2352 of 2352-2359 (bn 39343 cn 154 bn 4 sn 5)
>
>OK, from what I've found out so far, Chris Demetriou told me that an
>IDE disk is just an st506 with bad sector forwarding.  Reasoning that

Well, there is probably a lot more to it than that, but I guess for this
discussion it is close enough.

>my IDE drive (an st2383a) was very old, and therefore was not doing
>bad sector forwarding properly, (hence finding bad blocks where the
>BIOS media analysis had found them, and remembering that low-level
>formatting of IDE disks won't work), I tried installing NetBSD with
>the disk labbelled as st506, and telling it to use bad144 (the DEC
>standard) to forward bad sectors.

This is probably an excellent alternative to trying to fight crippled
hardware.

>
>It went away, correctly left a bad sector cylinder at the end of the
>disk, and it said that it had correctly written the bad sector table. 
>However, when I had installed the kernel on the disk (at the end of
>the install procedure), it tried to boot from the kernel, and then
>said "Bad badsect table".  This is because it does a BIOS read of the
>last disk cylinder, and finds no bad sector table there.  Now this
 ^^^^^^^^^^^^^^^^^^
 	            Change that to "the last disk sector within the limits 
 	            of the BIOS's ability to read these cylinders 
 	            (limited from 0 to 1023).

>could be for 3 reasons:
>
>1. the table wasn't written correctly in the first place.

Probably not, but a possibility nontheless, I suppose.

>2. Using the BIOS means that translation may take place during the read,
>and I've got a 1747 cylinder IDE disk, way above the 1024 cylinder limit
>set by the BIOS (thanks, IBM/Microsoft).

This would be my first ! choice.  If the BIOS translation occurs, it is
almost certainly not going to be able to find the physical BOC, and that
is absolutely essential for this to work.


>3. the badsect table was being overwritten during the disklabel.
>

You should be able to prevent this with a directive in the disklabel
(sf).  If this is in your table, then the bad sector table should exist
correctly.  If it is not, then the badsector table would logically be
disappearing...

>The bad144 code needs sorting out anyway.  In the NetBSD kernel, there
>are 4 places where the DKBAD_MAGIC number is defined - it should be in
>.../sys/dkbad.h (this is mentioned in an "XXX" comment - I've not
>looked in the NetBSD current sources yet, so I don't know if it's been
>done). And I haven't checked out the source to /sbin/bad144 yet.
>

/sys/sys/dkbad.h is in the current tree, and it defines DKBAD_MAGIC like
this:

	Search string not found...

I guess that tells us that, huh?

I found it defined in /sys/arch/i386/boot/disk.c, 
/sys/arch/i386/i386/disksubr.c, /sys/arch/i386/stand/wd.c, and 
/usr/src/usr.sbin/bad144/bad144.c.

/sys/arch/i386/boot/disk.c:#include <sys/dkbad.h>
/sys/arch/i386/boot/disk.c:/* XXX why is this not in <sys/dkbad.h> ??? */
/sys/arch/i386/i386/disksubr.c:#include "dkbad.h"
/sys/arch/i386/stand/wd.c:#include "dkbad.h"
/usr/src/usr.sbin/bad144/bad144.c:#include <sys/dkbad.h>

I found these in these files when I grepped for dkbad.h.  I guess the
author of disk.c was right.  Sounds like it ought to be an easy fix.

-- 
------
TSgt Dave Burgess
NCOIC AL/Management Information Systems Office
Brooks AFB, TX