2.4 [PATCH REQUEST] for scsi_scan.c (scan_scsis_single)

2.4 [PATCH REQUEST] for scsi_scan.c (scan_scsis_single)

[Scott O'Connor]

Hello,

I don't know if this has been proposed before, I just joined this mailing list.

I'm seeing a problem with a USB -> IDE device (SMSC USB97c202) with a DVD
R/W drive connected.  The INQUIRY command with a 255 byte request size is
causing the DVD to go out to lunch.  No data is sent back and the SCSI
subsystem is using what ever data is in the inquiry buffer.

I've noticed in Linux 2.6 that the scsi_scan.c stuff has changed the INQUIRY
data request size to 36.  When I make that change in 2.4, everything works
properly with my device.

Normally, it might be best to change the 36 to a #define, but I didn't know how
much change is allowed in a patch.  I also added memset(.., 0, ..) to the
inq buffer.  When the INQUIRY failed before, the device may have worked
depending on what garbage data was in the scsi_device_types[] field.

Any feedback would be welcomed, I would like to get this included in
the next available 2.4 kernel release.  I've never done Linux patching before,
so any help would be greatly appreciated.

Thanks,
-Scott.


--- linux-2.4.26/drivers/scsi/scsi_scan.c       2004-04-14 09:05:31.000000000 -0400
+++ linux-2.4.26-new/drivers/scsi/scsi_scan.c   2004-04-21 12:00:15.000000000 -0400
@@ -350,7 +350,7 @@
        unsigned int lun;
        unsigned int max_dev_lun;
        unsigned char *scsi_result;
-       unsigned char scsi_result0[256];
+       unsigned char scsi_result0[36];
        Scsi_Device *SDpnt;
        Scsi_Device *SDtail;
        unsigned int sparse_lun;
@@ -380,6 +380,8 @@
                printk("Unable to obtain scsi_result buffer\n");
                goto leave;
        }
+       memset(scsi_result, 0, 36);
+
        /*
         * We must chain ourself in the host_queue, so commands can time out
         */
@@ -616,14 +618,14 @@
                scsi_cmd[1] = 0;        /* SCSI_3 and higher, don't touch */
        scsi_cmd[2] = 0;
        scsi_cmd[3] = 0;
-       scsi_cmd[4] = 255;
+       scsi_cmd[4] = 36;
        scsi_cmd[5] = 0;
        SRpnt->sr_cmd_len = 0;
        SRpnt->sr_data_direction = SCSI_DATA_READ;
  
        scsi_wait_req (SRpnt, (void *) scsi_cmd,
                  (void *) scsi_result,
-                 256, SCSI_TIMEOUT+4*HZ, 3);
+                 36, SCSI_TIMEOUT+4*HZ, 3);
  
        SCSI_LOG_SCAN_BUS(3, printk("scsi: INQUIRY %s with code 0x%x\n",
                SRpnt->sr_result ? "failed" : "successful", SRpnt->sr_result));

Re: 2.4 [PATCH REQUEST] for scsi_scan.c (scan_scsis_single)

[Kurt Garloff]

[-- Attachment #1: Type: text/plain, Size: 1231 bytes --]

Hi Scott,

On Thu, Apr 22, 2004 at 11:28:41AM -0400, Scott O'Connor wrote:
> I don't know if this has been proposed before, I just joined this mailing list.
> 
> I'm seeing a problem with a USB -> IDE device (SMSC USB97c202) with a DVD
> R/W drive connected.  The INQUIRY command with a 255 byte request size is
> causing the DVD to go out to lunch.  No data is sent back and the SCSI
> subsystem is using what ever data is in the inquiry buffer.
> 
> I've noticed in Linux 2.6 that the scsi_scan.c stuff has changed the INQUIRY
> data request size to 36.  When I make that change in 2.4, everything works
> properly with my device.

Have a look at
http://www.suse.de/~garloff/linux/scsi-scan/scsi-scanning.html
for a better patch.
It does pretty much what 2.6 does: First do a 36byte inquiry and do
another one with a longer buffer if the device claims to support longer
INQUIRYs.
Your patch will break U80/160/320 support as the needed flags are needed
from byte 56 and some host adapters snoop this data to determine maximum
allowable speeds.

Regards,
-- 
Kurt Garloff  <garloff@suse.de>                            Cologne, DE 
SUSE LINUX AG, Nuernberg, DE                          SUSE Labs (Head)

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]