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
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