Date: Sun, 19 May 2002 17:28:41 -0600 From: "Kenneth D. Merry" <ken@kdm.org> To: Matthew Dillon <dillon@apollo.backplane.com> Cc: cvs-committers@FreeBSD.ORG, cvs-all@FreeBSD.ORG Subject: Re: cvs commit: src/sys/cam/scsi scsi_da.c Message-ID: <20020519172841.A51662@panzer.kdm.org> In-Reply-To: <200205192312.g4JNCsKs098352@apollo.backplane.com>; from dillon@apollo.backplane.com on Sun, May 19, 2002 at 04:12:54PM -0700 References: <200205192159.g4JLxSx22676@freefall.freebsd.org> <20020519170221.A51589@panzer.kdm.org> <200205192312.g4JNCsKs098352@apollo.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, May 19, 2002 at 16:12:54 -0700, Matthew Dillon wrote: > > :We have code to detect devices that don't work with 6 byte commands; a > :quirk shouldn't be necessary. > : > :What error does this device return when you issue a 6 byte command? > : > :Ken > :-- > :Kenneth Merry > :ken@kdm.org > > It returns a general I/O error, but the CAM debug code does not > report any errors. If you boot with -v, you may see some errors. CAMDEBUG is more of a trace facility than verbose logging facility, so while you'll see CDBs and various functions go by, depending on what debug options you set, you'll probably get more errors if you boot verbose. > I was not able to test the USB device under -current at all... none > of my current machines are running a USB chipset that either -current > or -stable is happy with, so I cannot refute your assertion on -current. > Still, -current has the NO_6 quirks for all the other USB card readers > so presumably it is still required. > > On -stable it is definitely required. -stable and -current both have the code to handle devices that don't like 6 byte commands. The reason all those quirks are still in there is that we would need to contact everyone to see if the code we've got to detect devices with this issue actually works for their device. If the device returns a non-standard error code, it won't get flagged as a device that doesn't support 6 byte commands. > The real issue here is not so much the SCSI spec... these are not > actual SCSI devices, they are pseudo-SCSI devices and there are a lot > of things missing or hacked or just plain broken in regards to their > adherence to either the SCSI or ATA specs. I'm certain the reason > CAM/SCSI cannot figure out that a 10 byte command is required for > these devices is simply due to that fact. Well, they're more ATAPI than anything else. The better fix in -current at least would be to use the new transport settings code to determine that devices on transport X don't support 6 byte commands. What we've got now works reasonably well, except when a device doesn't return a reasonable error in resposne to a 6 byte command. Ken -- Kenneth Merry ken@kdm.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020519172841.A51662>