Re: Proliferating quirk table entries
On Tue, 20 Aug 2002, Terry Lambert wrote: I think everyone in this thread needs to read the last instance of this same thread, the first time it came up. I believe the general consensus was to send the 6, and if it failed, retry with the 10, and set a flag so that subsequent requests were 10 (this instead of a static quirk table that could find itself out of date). As someone mentioned, some devices choke on the first 6-byte command and then just don't work anymore even if you start sending the 10-byte commands from then on. I have a USB multi-flash (CF/MD, MMC, SD, etc) card reader that does exactly that. I have to enable kern.cam.da.no_6_byte=1 before try to use the device and everything works fine. I also don't have any problems with any of my other SCSI devices (various SCSI CD-ROMs, a SCSI CD-RW, a SCSI ZIP drive, and SCSI DDS2 and DDS3 tape drives) when using only 10-byte commands. What problems would occur if you try 10 first and then 6 if that fails? Will the devices that only take 6-byte commands choke permanently on the first 10-byte command as some of the non-SCSI stuff does on the 6-byte commands, or would they truncate 4 bytes and treat it as the wrong command? I believe someone already proposed this, but since only some very old SCSI devices won't handle 10-byte commands correctly (correct me if I'm wrong there) and should affect very few people, how about just enabling 10-byte commands by default and offering a sysctl to turn on the 6-byte-then-10-byte method when it is needed? The benefit of that should greatly outweigh the drawbacks with the state of the hardware as it is today. -- Chris Dillon - cdillon(at)wolves.k12.mo.us FreeBSD: The fastest and most stable server OS on the planet - Available for IA32 (Intel x86) and Alpha architectures - IA64, PowerPC, UltraSPARC, ARM, and S/390 under development - http://www.freebsd.org No trees were harmed in the composition of this message, although some electrons were mildly inconvenienced. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Proliferating quirk table entries
Le 2002-08-17, Nate Lawson écrivait :
I'm working on cleaning up quirk entries in scsi_da.c, especially ones
related to READ/WRITE 6-10 escalation. For those just joining in, there
is a function (cmd6workaround) that handles a R/W6 error by translating
the cdb to 10 bytes and restarting it.
It might be worthwhile moving this to some generic part in the CAM
framework, instead of having it in the da driver. Similar promotion
is performed for some commands (MODE_{SELECT,SENSE}_6 as well as
{READ,WRITE}_6) in a rather ad hoc fashion in atapi-cam. At least
the cmd6workaround function should be factored in some way; as for the
try 6 - fail - retry 10 process, however, I am not sure this can
be readily generalised to ATAPI devices (which are explicitly specified
to only support the _10 variants) as these tend to have very strange
reactions to CDBs they cannot handle properly.
Thomas.
--
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: Proliferating quirk table entries
On Wed, Aug 21, 2002 at 02:46:14 +0200, Thomas Quinot wrote:
Le 2002-08-17, Nate Lawson écrivait :
I'm working on cleaning up quirk entries in scsi_da.c, especially ones
related to READ/WRITE 6-10 escalation. For those just joining in, there
is a function (cmd6workaround) that handles a R/W6 error by translating
the cdb to 10 bytes and restarting it.
It might be worthwhile moving this to some generic part in the CAM
framework, instead of having it in the da driver. Similar promotion
is performed for some commands (MODE_{SELECT,SENSE}_6 as well as
{READ,WRITE}_6) in a rather ad hoc fashion in atapi-cam. At least
the cmd6workaround function should be factored in some way; as for the
try 6 - fail - retry 10 process, however, I am not sure this can
be readily generalised to ATAPI devices (which are explicitly specified
to only support the _10 variants) as these tend to have very strange
reactions to CDBs they cannot handle properly.
The right way to handle the 6/10 byte stuff is to have it be a function of
the transport type (see the CAM_NEW_TRAN_CODE stuff). The peripheral
drivers and userland applications can query the transport type and send
6 or 10 byte commands as appropriate.
If we're going to come up with a generic solution, that's probably the
direction we need to be heading.
Ken
--
Kenneth Merry
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: Proliferating quirk table entries
Kenneth D. Merry wrote: The right way to handle the 6/10 byte stuff is to have it be a function of the transport type (see the CAM_NEW_TRAN_CODE stuff). The peripheral drivers and userland applications can query the transport type and send 6 or 10 byte commands as appropriate. If we're going to come up with a generic solution, that's probably the direction we need to be heading. I think everyone in this thread needs to read the last instance of this same thread, the first time it came up. I believe the general consensus was to send the 6, and if it failed, retry with the 10, and set a flag so that subsequent requests were 10 (this instead of a static quirk table that could find itself out of date). -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Proliferating quirk table entries
I'm working on cleaning up quirk entries in scsi_da.c, especially ones related to READ/WRITE 6-10 escalation. For those just joining in, there is a function (cmd6workaround) that handles a R/W6 error by translating the cdb to 10 bytes and restarting it. It also increases the command size that will be used to 10 so future R/W requests automatically work. This is obviously preferable to entering quirk entries for every USB device. This function has been tested for a while but it's still possible some equipment won't correctly handle the workaround. I am preparing to add a kernel option (DISABLE_CDB6_QUIRKS) that will default to off. It will disable the use of DA_Q_NO_6_BYTE to allow cmd6workaround to do its stuff. Users of equipment listed in the quirk table would be solicited to enable this kernel option and try their equipment again. If problems are found in the workaround code, I will attempt to fix them. If things work, that quirk can be removed. If you have alternative suggestions, let me know. NO_SYNC_CACHE will be next on my list. -Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
