Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 28 Aug 1999 15:38:21 -0600 (MDT)
From:      "Kenneth D. Merry" <ken@kdm.org>
To:        sthaug@nethelp.no
Cc:        groudier@club-internet.fr, dkelly@hiwaay.net, syssgm@detir.qld.gov.au, freebsd-scsi@FreeBSD.ORG
Subject:   Re: Seagate vs Quantum.. opinions?
Message-ID:  <199908282138.PAA01880@panzer.kdm.org>
In-Reply-To: <47459.935875973@verdi.nethelp.no> from "sthaug@nethelp.no" at "Aug 28, 1999 11:32:53 pm"

next in thread | previous in thread | raw e-mail | index | archive | help
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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199908282138.PAA01880>