Date: Sat, 28 Aug 1999 01:37:39 -0600 (MDT) From: "Kenneth D. Merry" <ken@kdm.org> To: groudier@club-internet.fr (Gerard Roudier) Cc: dkelly@hiwaay.net, syssgm@detir.qld.gov.au, freebsd-scsi@FreeBSD.ORG Subject: Re: Seagate vs Quantum.. opinions? Message-ID: <199908280737.BAA94296@panzer.kdm.org> In-Reply-To: <Pine.LNX.3.95.990828091117.564A-100000@localhost> from Gerard Roudier at "Aug 28, 1999 09:25:33 am"
next in thread | previous in thread | raw e-mail | index | archive | help
Gerard Roudier wrote... > On Fri, 27 Aug 1999, Kenneth D. Merry wrote: > > David Kelly wrote... > > > None of these work for me, 3 systems, all with different 3.2-STABLE: > > > > > > IBM DCAS (4.3G) on early 2940 (7860 based?) > > > IBM DCHS (? I forgot, but its 9G) on Symbios '875 > > > IBM DDRS (9G) on 7890 (Asus P2S MB) > > > > > > I've typed up what little I know into send-pr. > > > > It works for me with a DDRS drive on a 2940UW (7880-based) board: [ ... ] > > I'd like to see you try the physical defect format with one of your drives > > on an Adaptec controller. In your PR, you specified block format, which > > I've only seen work for Quantum disks. (Not saying it doesn't work on > > others, but I know it usually doesn't work for IBM or Seagate disks.) > > > > Physical sector format usually works, though. > > > > You also didn't specify the PLIST or GLIST. You should at least try > > specifying the PLIST. You should also use the -v switch to camcontrol so > > you'll hopefully get sense information if the command fails. > > > > The NCR driver is known to be a little flaky around the edges sometimes, so > > I'm not surprised it might complain. Unfortunately, complaints from the > > NCR driver don't help much, because the only people who know how to > > decipher them are Stefan and Gerard, and they only pop up occasionally. > > > > I'll respond to the PR in a minute, so this stuff gets in the database. > > The bottom line is you'll have to provide more info before the problem can > > be fixed. > Hi guys, > > The problem that has been reported about read defect failure using > SYM53C8XX chips is due to the device reporting more data than expected. > Call it a data overrun condition detected by the SIM, if you did prefer > so. Thanks for the description! > The reason can be one of the following: > > - SCSI device that does not follow the transfer size field specified in > the SCSI command. > - Application that provide a too small data buffer. > > So, the error condition should not depend on the controller/driver being > used. At most, it may be reported differently. > > If you have the source of the application (camcontrol), you may try the > following: > > - Check that it provides a right sized data buffer and fix it if it does > not so. > - Make it use a LARGE data buffer since modern LARGE disks may have LONG > defect lists. camcontrol uses a 65000 byte buffer for the defect list data. With the 10-byte read defect data command, it can be increased to at most 65536 bytes, because the transfer length field is only two bytes long. In any case, with 65000 bytes you can hold 8124 defects, which is probably far more than are on his disks. There is a 12 byte read defect data command in the SCSI-3 spec, but who knows whether this drive will support it? 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. - If that doesn't work, try increasing the dlist_length parameter in readdefects() in src/sbin/camcontrol/camcontrol.c to 65536. - If that doesn't work, you can try using the 12 byte read defect data command. There are definitions for it in /usr/include/cam/scsi/scsi_da.h. On second thought, you won't gain anything by doing that. Right now, we limit transfers to and from the kernel via the passthrough interface to 64K. (It could be increased to 128K, but the aha driver/cards don't support it, and we haven't yet implemented buffer chaining or a way to dynamically figure out the maximum transfer size of a given command path.) 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. 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?199908280737.BAA94296>