Re: cvs commit: src/sys/cam cam_ccb.h src/sys/cam/scsi scsi_cd.c scsi_da.c src/sys/dev/ata atapi-cam.c src/sys/dev/usb umass.c src/sys/dev/firewire sbp.c

From: Nate Lawson <nate_at_root.org>
Date: Sun, 27 Jul 2003 23:23:33 -0700 (PDT)
On Sun, 27 Jul 2003, Nate Lawson wrote:
>   Modified files:
>     sys/cam              cam_ccb.h
>     sys/cam/scsi         scsi_da.c scsi_cd.c
>     sys/dev/ata          atapi-cam.c
>     sys/dev/usb          umass.c
>     sys/dev/firewire     sbp.c
>   Log:
>   Add a PATH_INQ flag, PIM_NO_6_BYTE, which indicates the SIM never wishes to
>   receive 6 byte commands.  Add a check for this flag to da(4) and cd(4) so
>   that they honor it.  This is a quick workaround for many devices (especially
>   USB) that require da(4) quirks to operate.  The more complete approach is
>   to finish the new transport code which will be aware of the SCSI version a
>   transport implements.
>
>   MFC after:      1 day
>
>   Revision  Changes    Path
>   1.26      +2 -1      src/sys/cam/cam_ccb.h
>   1.80      +8 -0      src/sys/cam/scsi/scsi_cd.c
>   1.147     +8 -0      src/sys/cam/scsi/scsi_da.c
>   1.18      +1 -1      src/sys/dev/ata/atapi-cam.c
>   1.58      +1 -1      src/sys/dev/firewire/sbp.c
>   1.88      +1 -1      src/sys/dev/usb/umass.c

This is the first step to removing many of the da(4) quirks that have
accumulated for USB devices.  This code should remove the message:
"READ(6)/WRITE(6) not supported, increasing minimum_cmd_size to 10." It
should also fix USB devices which fail when receiving 6 byte commands but
do not yet have a quirk.

After this code is in both stable and current, current USB quirks will be
deprecated but can be re-enabled in a pinch with a kernel option.
Unfortunately, I only have contact information for the more recent quirks
that were committed and so the only way to find devices that have other
problems (i.e. NO_SYNC_CACHE) is to disable the quirks and re-enable them
for devices that still fail.  I'm doing this as early as possible before
5.2 to get things sorted out and if your device fails at that point, it
can be returned to ordinary behavior with a kernel option until I remove
it from the deprecated section.

-Nate
Received on Sun Jul 27 2003 - 21:23:31 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:37:16 UTC