From owner-freebsd-scsi Sat Aug 28 14:38:47 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from panzer.kdm.org (panzer.kdm.org [216.160.178.169]) by hub.freebsd.org (Postfix) with ESMTP id D81A414FDB for ; Sat, 28 Aug 1999 14:38:40 -0700 (PDT) (envelope-from ken@panzer.kdm.org) Received: (from ken@localhost) by panzer.kdm.org (8.9.3/8.9.1) id PAA01880; Sat, 28 Aug 1999 15:38:21 -0600 (MDT) (envelope-from ken) Message-Id: <199908282138.PAA01880@panzer.kdm.org> Subject: Re: Seagate vs Quantum.. opinions? In-Reply-To: <47459.935875973@verdi.nethelp.no> from "sthaug@nethelp.no" at "Aug 28, 1999 11:32:53 pm" To: sthaug@nethelp.no Date: Sat, 28 Aug 1999 15:38:21 -0600 (MDT) Cc: groudier@club-internet.fr, dkelly@hiwaay.net, syssgm@detir.qld.gov.au, freebsd-scsi@FreeBSD.ORG From: "Kenneth D. Merry" X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org sthaug@nethelp.no wrote... > > In any case, David, I'd say try the following things, in light of what > > Gerard said: > > > > - first, try using the -v switch, -f phys (instead of block format, since > > only Quantum disks seem to support it, and the SCSI-2 spec says: "NOTE > > 110 The use of the block format is not recommended. There is no universal > > model that sensibly defines the meaning of the logical block address of > > a defect. In the usual case, a defect that has been reassigned no longer > > has a logical block address.") and -PG. > > Using -v results in "CAM status is 0" here. Hmm, so there isn't a SCSI error, and the controller driver didn't pass an error back either. > > - If that doesn't work, try increasing the dlist_length parameter in > > readdefects() in src/sbin/camcontrol/camcontrol.c to 65536. > > Are you sure you mean 65536? If I try 65536, it *seems* to work (no error > message), but all I get is "Got 0 defects". But I'm wondering if 65536 is > being interpreted as 0 (because this is a 2 byte field). I tried a slightly > smaller number (65532), and got the expected error messages. Oops, it is a 2-byte field. So increasing it to 65536 would probably cause problems. > I don't believe this is a result of a defect larger than 65536, since it > happens with several disks here, some of them pretty new. I think you're probably right. > > It would also be helpful to see what happens on an Adaptec controller, as > > this could be the result of a bug in the NCR driver. > > It works just fine on an Adaptec controller, no problem retrieving defect > list from IBM disks using "camcontrol defects -f phys -P". With an NCR > based controller, the kernel logs > > (pass0:ncr0:0:2:0): extraneous data discarded. > (pass0:ncr0:0:2:0): COMMAND FAILED (9 0) @0xc086c200. > > and camcontrol says "error reading defect list: Input/output error". > > I think we need the NCR driver experts. I agree. This looks like an NCR driver issue. (The fact that the Adaptec driver works okay seems to point in that direction.) Ken -- Kenneth Merry ken@kdm.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message