From owner-freebsd-scsi Thu Jun 17 19:54:42 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from mail.HiWAAY.net (fly.HiWAAY.net [208.147.154.56]) by hub.freebsd.org (Postfix) with ESMTP id A25E114E14 for ; Thu, 17 Jun 1999 19:54:39 -0700 (PDT) (envelope-from dkelly@nospam.hiwaay.net) Received: from nospam.hiwaay.net (tnt4-208-166-127-117.dialup.HiWAAY.net [208.166.127.117]) by mail.HiWAAY.net (8.9.1a/8.9.0) with ESMTP id VAA27273; Thu, 17 Jun 1999 21:54:37 -0500 (CDT) Received: from localhost (localhost [127.0.0.1]) by nospam.hiwaay.net (8.9.3/8.9.3) with ESMTP id VAA43859; Thu, 17 Jun 1999 21:54:35 -0500 (CDT) (envelope-from dkelly@nospam.hiwaay.net) Message-Id: <199906180254.VAA43859@nospam.hiwaay.net> X-Mailer: exmh version 2.0.2 2/24/98 To: "Kenneth D. Merry" Cc: freebsd-scsi@FreeBSD.ORG From: David Kelly Subject: Re: suspected bad block In-reply-to: Message from "Kenneth D. Merry" of "Thu, 17 Jun 1999 20:37:11 MDT." <199906180237.UAA92294@panzer.plutotech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 17 Jun 1999 21:54:35 -0500 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org "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