Date: Thu, 17 Jun 1999 21:02:25 -0600 (MDT) From: "Kenneth D. Merry" <ken@plutotech.com> To: dkelly@hiwaay.net (David Kelly) Cc: freebsd-scsi@FreeBSD.ORG Subject: Re: suspected bad block Message-ID: <199906180302.VAA92490@panzer.plutotech.com> In-Reply-To: <199906180254.VAA43859@nospam.hiwaay.net> from David Kelly at "Jun 17, 1999 09:54:35 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
David Kelly wrote... > "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? Generally, recovered errors (as successfully remapped blocks are) won't be reported. > 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 Well, the PLIST is generally larger than the GLIST. Although the 4 seconds that is taking is sorta close to the 5 second timeout. You might try bumping the timeout (with -t) just for grins, but I don't think it'll help. > 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. Ken -- Kenneth Merry ken@plutotech.com 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?199906180302.VAA92490>