Date: Sat, 27 Oct 2001 22:35:19 -0600 From: "Kenneth D. Merry" <ken@kdm.org> To: Cyrille Lefevre <clefevre@citeweb.net> Cc: Alexander Leidinger <Alexander@Leidinger.net>, scsi@FreeBSD.ORG Subject: Re: repeating medium errors and error from "camcontrol defects" Message-ID: <20011027223519.A67823@panzer.kdm.org> In-Reply-To: <200110272235.f9RMZRQ77062@gits.dyndns.org>; from clefevre@citeweb.net on Sun, Oct 28, 2001 at 12:35:27AM %2B0200 References: <20011026111106.A52864@panzer.kdm.org> <200110272235.f9RMZRQ77062@gits.dyndns.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, Oct 28, 2001 at 00:35:27 +0200, Cyrille Lefevre wrote: > Kenneth D. Merry wrote: > > On Fri, Oct 26, 2001 at 12:21:56 +0200, Alexander Leidinger wrote: > [snip] > > Then, write zeroes to the bad block to force the drive to remap it. > > I'm not really sure this always work. the way I use to remap bad > block is to make a read check using the SCSI BIOS controller (TEKRAM > and probably ADAPTEC allow this at boot time), when errors are > encountered, the BIOS asks you whether or not you want to remap the > defective block. so, I'm sure that bad blocks are remapped since it > asks me to do something. That'll work as well, but it takes a while to do a verify on an entire disk. I think that in most cases, writing to the bad block, if you have AWRE turned on, will cause the block to get remapped. That is, unless, the drive is somehow able to write to the block but can't read it. You can detect that case by just trying to read the block once you've written it. If you can read it, it has likely been remapped. (Unless the drive can just "magically" read that block again.) The "right" solution to this would probably be to implement something in camcontrol similar to the BIOS verify routines that would then give the user the option of remapping a bad block, writing zeroes to it, etc. An adjunct to this command would be a separate camcontrol command to allow the user to remap a specific block. Ken -- Kenneth Merry ken@kdm.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20011027223519.A67823>