Date: Thu, 17 Jun 1999 21:54:35 -0500 From: David Kelly <dkelly@hiwaay.net> To: "Kenneth D. Merry" <ken@plutotech.com> Cc: freebsd-scsi@FreeBSD.ORG Subject: Re: suspected bad block Message-ID: <199906180254.VAA43859@nospam.hiwaay.net> In-Reply-To: Message from "Kenneth D. Merry" <ken@plutotech.com> of "Thu, 17 Jun 1999 20:37:11 MDT." <199906180237.UAA92294@panzer.plutotech.com>
next in thread | previous in thread | raw e-mail | index | archive | help
"Kenneth D. Merry" writes: > David Kelly wrote... > > Am running "dd if=/dev/rda0c ibs=64k of=/dev/null" on the device right > > now to see if I can prompt the problem again. Or if the drive has > > already remapped it. > > You'll probably see the error again. The drive can generally only remap a > block if it has good data to put in place of the data it can't retrieve. > Sometimes it can use ECC data to reconstruct the block, but if it can't, it > probably won't be able to remap it. (There are rules the drive follows, > which can be adjusted in mode page 1. Read the SCSI spec for details.) Well, it make a complete pass of dd without complaining. Maybe it got remapped later. If the drive remaps a block, will it be reported and appear in /var/log/messages? In any case I now know where the block is. So might be able to script dd to give the area a good workout with reads. > > Have mentioned in the past, camcontrol isn't quite > > happy with the above HD and Asus SC875 SCSI card: [...] > Yeah, I think I remember your saying something about it. I will say that > IBM drives typically don't like the block defect format. The physical > sector format usually works for most drives. Quantum disks often work with > the block format, but Seagate and IBM don't. > > It would help if I could figure out what the error above from the NCR > driver means. Maybe if Stefan or Gerard are reading this, they might be > able to help. > > If I get time this weekend (and if I can remember) I may hook up a disk to > an NCR controller and see if I can reproduce this. None of the reporting formats work: # camcontrol defects -f bfi -G error reading defect list: Input/output error # camcontrol defects -f phys -G error reading defect list: Input/output error This one was a little different. It takes longer so I timed it: # time camcontrol defects -f phys -P error reading defect list: Input/output error 0.002u 0.000s 0:03.87 0.0% 0+0k 0+0io 0pf+0w # time camcontrol defects -f bfi -P error reading defect list: Input/output error 0.000u 0.003s 0:03.88 0.0% 0+0k 0+0io 0pf+0w # time camcontrol defects -f block -P error reading defect list: Input/output error 0.000u 0.003s 0:03.94 0.0% 0+0k 0+0io 0pf+0w for comparison's sake: # time camcontrol defects -f phys -G error reading defect list: Input/output error 0.000u 0.003s 0:00.01 0.0% 0+0k 0+0io 0pf+0w Messages in /var/log/messages are identical for all of the above. > Assuming you've got AWRE turned on, you can force the drive to remap the > block, probably like this: > > camcontrol cmd -n da -u 0 -v -c "2a 0 1 09 b6 03 0 0 1 0" -o 512 - < /dev/null > > Use the above command at your own risk. It should write one block worth of > nulls to the bad sector in question, but I might have gotten it wrong. Its late. I'm tired. For some reason the above tickled my funny bone. I believe I will pass on trying the above. At least unless things get worse. -- David Kelly N4HHE, dkelly@nospam.hiwaay.net ===================================================================== The human mind ordinarily operates at only ten percent of its capacity -- the rest is overhead for the operating system. 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?199906180254.VAA43859>