> The only possibility for a problem might be that the code you quote
> massages the MODE_SENSE data for every device, whereas the SCSI changes
> only do it for RBC devices ... are the devices reporting difficulties
> non-RBC?
Ah, this function wasn't in the patch:
static __inline__ int sbp2_command_conversion_device_type(u8 device_type)
{
return (((device_type == TYPE_DISK) ||
(device_type == TYPE_SDAD) ||
(device_type == TYPE_ROM)) ? 1:0);
}
I didn't see that the scsi code made a distinction here. I thought it did
the conversion for all devices if use_10_for_{rw,ms} was set, and did the
fallback when it got ILLEGAL_REQUEST. Is there something in there that
will disable use_10_for_{rw,ms} if it's not TYPE_RBC?
Ok, I see something different in the MODE_SENSE:
drivers/scsi/scsi_lib.c(__scsi_mode_sense):1579
memset(data, 0, sizeof(*data));
memset(&cmd[0], 0, 12);
cmd[1] = dbd & 0x18; /* allows DBD and LLBA bits */
cmd[2] = modepage;
For TYPE_RBC, scsi sets modepage to 6 (drivers/scsi/sd.c:1384), which is
normally 8 for all other devices. However, the sbp2 translation did not
change the modepage:
SBP2_DEBUG("Convert MODE_SENSE_6 to MODE_SENSE_10");
new_cmd[0] = 0x5a;
new_cmd[1] = cmd[1];
new_cmd[2] = cmd[2];
...
Looking the pre TYPE_RBC code, I can see that the modepage change wasn't
there, so sure enough we were using 8. Could this cause an
ILLEGAL_REQUEST, and thus disable use_10_for_{rw,ms}?
I'm starting to understand some of the code paths here. So before all of
this, TYPE_RBC was not recognized by the scsi layer as a "disk" type
device (which is why sbp2 forced TYPE_DISK for TYPE_RDC devices when
commands passed into the scsi layer).
--
Debian - http://www.debian.org/
Linux 1394 - http://www.linux1394.org/
Subversion - http://subversion.tigris.org/
SwissDisk - http://www.swissdisk.com/
-
: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
