Date: Sun, 29 Aug 1999 22:30:04 -0700 (PDT) From: "Kenneth D. Merry" <ken@kdm.org> To: freebsd-bugs@FreeBSD.org Subject: Re: kern/13433: 'camcontrol defects' SCSI error Message-ID: <199908300530.WAA69304@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR kern/13433; it has been noted by GNATS. From: "Kenneth D. Merry" <ken@kdm.org> To: dkelly@hiwaay.net (David Kelly) Cc: FreeBSD-gnats-submit@FreeBSD.ORG Subject: Re: kern/13433: 'camcontrol defects' SCSI error Date: Sun, 29 Aug 1999 23:28:48 -0600 (MDT) David Kelly wrote... > "Kenneth D. Merry" writes: > > You can read the defects list on an IBM drive. Here's an example: [ .... ] > > There are several things to mention here: > > > > - The NCR driver, at this point, is known to be a little flaky sometimes, > > and it's difficult to interpret the error messages from it. It would be > > helpful if you show the output from one of your Adaptec controllers. The > > IBM disk on in the above example is on an Adaptec 2940UW (7880) board. > > The DCAS and DDRS drives which are connected to Adaptec controllers are > at work, beyond my reach at the moment. I'll try the exact example you > provide... tomorrow. > > Meanwhile here is what I get when attempting the slightly different > command lines provided (Symbios/NCR '875, DCHS): > > # camcontrol inquiry > pass2: <IBM OEM DCHS09W 2222> Fixed Direct Access SCSI-2 device > pass2: Serial Number 68210913 > pass2: 20.000MB/s transfers (10.000MHz, offset 15, 16bit), Tagged Queueing Enabled > # camcontrol defects -f bfi > error reading defect list: Input/output error > # camcontrol defects -f phys > error reading defect list: Input/output error One thing to keep in mind with the above two commands is that at best, it will only return the number of defects. It doesn't work on some drives. > # camcontrol defects da0 -v -PG -f phys > error reading defect list: Input/output error > CAM status is 0 > > tail -4 /var/log/messages says: > Aug 29 13:23:25 nospam /kernel: (pass2:ncr0:0:0:0): extraneous data discarded. > Aug 29 13:23:27 nospam /kernel: (pass2:ncr0:0:0:0): COMMAND FAILED (9 0) @0xc0a84400. > Aug 29 13:23:27 nospam /kernel: (pass2:ncr0:0:0:0): extraneous data discarded. > Aug 29 13:23:27 nospam /kernel: (pass2:ncr0:0:0:0): COMMAND FAILED (9 0) @0xc0a84400. > > The "camcontrol defects da0 -v -PG -f phys" is notable because there > was a 2 second delay not present in other attempts. > > Further experiments suggest -P causes the delay. > > > - The only disks I've seen that will return defects in block format are > > Quantum disks. IBM and Seagate disks generally will not. They will, > > however, return defects in physical sector format, as I demonstrated above. > > I used "block" in my earlier example simply because 1) there was no > default format, and 2) "block" was listed first in camcontrol(1). Hmm, maybe I should put stronger wording in the man page to warn people that many drives don't support block format. > > - In your example command above, you did not specify either the GLIST or > > PLIST. That can cause problems with some disks. You may want to specify > > both the GLIST and PLIST (-PG). I have a Seagate disk that doesn't seem > > to want to return any defects unless both are specified. > > > > - You should specify the -v switch to camcontrol so you have a chance of > > getting SCSI sense information when the command fails. > > "CAM status is 0" appears to be all -v does in this case. Okay, that means we're not getting any error codes back. > > I won't deny that there may be a problem with getting the defect lists off > > drives in some cases, but I will say that I haven't seen many problems > > personally. > > > > I'll need some more information (as outlined above) to get an idea of what > > may be wrong here. > > Used to have a spare '875 card that I could carry to work to try there. > But the way things are now I believe I'll be carrying some of my HD's > at work (they are mine, not work's) home to try. Got a great deal on > DDRS drives a while back and bought two where only one was called for. It would be better if you could give me results from an Adaptec controller, not more results from an NCR controller. I have reason to suspect the NCR driver may be the problem here. > I do have an old narrow 2940 here at home. Its driving my tape drives. > The DCHS is wide. Not sure how it would behave on a narrow controller > if I had cables to connect it. It should behave just fine, if you connect it up properly. Based on what other folks have said, I think there may be something with the NCR driver that's causing the problem. Other folks have been able to read defect lists just fine with various drives (IBMs included) with Adaptec, BusLogic and Advansys controllers. Steinar Haug reports that reading defects with an Adaptec controller works fine, but it doesn't work with an NCR controller. Ken -- Kenneth Merry ken@kdm.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199908300530.WAA69304>