libata: Simulate REPORT LUNS for ATAPI devices when not supported

The Quantum GoVault SATAPI removable disk device returns ATA_ERR in response to a REPORT LUNS packet. If this happens to an ATAPI device that is attached to a SAS controller (this is the case with sas_ata), the device does not load because SCSI won't touch a "SCSI device" that won't report its LUNs. If we see this command fail, we should simulate a response that indicates the presence of LUN 0.

Signed-off-by Darrick J. Wong <[email protected]>

The Quantum GoVault SATAPI removable disk device returns ATA_ERR in response to a REPORT LUNS packet. If this happens to an ATAPI device that is attached to a SAS controller (this is the case with sas_ata), the device does not load because SCSI won't touch a "SCSI device" that won't report its LUNs. Since most ATAPI devices don't support multiple LUNs anyway, we might as well fake a response like we do for ATA devices.

Signed-off-by Darrick J. Wong <[email protected]>

Quoted 8 lines · Darrick J. Wong

The Quantum GoVault SATAPI removable disk device returns ATA_ERR in response to a REPORT LUNS packet. If this happens to an ATAPI device that is attached to a SAS controller (this is the case with sas_ata), the device does not load because SCSI won't touch a "SCSI device" that won't report its LUNs. Since most ATAPI devices don't support multiple LUNs anyway, we might as well fake a response like we do for ATA devices.

Quoted 1 line

Signed-off-by Darrick J. Wong <[email protected]>

Seems sane to me, but I would like additional comment/testing/etc. before applying...

The Quantum GoVault SATAPI removable disk device returns ATA_ERR in response to a REPORT LUNS packet. If this happens to an ATAPI device that is attached to a SAS controller (this is the case with sas_ata), the device does not load because SCSI won't touch a "SCSI device" that won't report its LUNs. Since most ATAPI devices don't support multiple LUNs anyway, we might as well fake a response like we do for ATA devices.

Quoted 7 lines · Darrick J. Wong

The Quantum GoVault SATAPI removable disk device returns ATA_ERR in response to a REPORT LUNS packet. If this happens to an ATAPI device that is attached to a SAS controller (this is the case with sas_ata), the device does not load because SCSI won't touch a "SCSI device" that won't report its LUNs. Since most ATAPI devices don't support multiple LUNs anyway, we might as well fake a response like we do for ATA devices.

Actually, there may be a standards conflict here. SPC says that all devices reporting compliance with this standard (as the inquiry data for this device claims) shall support REPORT LUNS. On the other hand, MMC doesn't list REPORT LUNS in its table of mandatory commands.

I'm starting to think that even if they report a SCSI compliance level of 3 or greater, we still shouldn't send REPORT LUNS to devices that return MMC type unless we have a white list override.

The Quantum GoVault SATAPI removable disk device returns ATA_ERR in response to a REPORT LUNS packet. If this happens to an ATAPI device that is attached to a SAS controller (this is the case with sas_ata), the device does not load because SCSI won't touch a "SCSI device" that won't report its LUNs. Since most ATAPI devices don't support multiple LUNs anyway, we might as well fake a response like we do for ATA devices.

Signed-off-by Darrick J. Wong <[email protected]>

Quoted 8 lines · Darrick J. Wong

The Quantum GoVault SATAPI removable disk device returns ATA_ERR in response to a REPORT LUNS packet. If this happens to an ATAPI device that is attached to a SAS controller (this is the case with sas_ata), the device does not load because SCSI won't touch a "SCSI device" that won't report its LUNs. Since most ATAPI devices don't support multiple LUNs anyway, we might as well fake a response like we do for ATA devices.

Quoted 1 line

Signed-off-by Darrick J. Wong <[email protected]>

I'm leaning towards applying this, perhaps with a module option that allows experimenters to revert back to the older behavior.

Any chance you could be talked into tackling some of the SAT translation-related items Doug G mentioned? I'm almost certain there are some info pages we should be returning, but are not, at the very least.

Quoted 9 lines · Jeff Garzik

Quoted 8 lines · Darrick J. Wong

The Quantum GoVault SATAPI removable disk device returns ATA_ERR in response to a REPORT LUNS packet. If this happens to an ATAPI device that is attached to a SAS controller (this is the case with sas_ata), the device does not load because SCSI won't touch a "SCSI device" that won't report its LUNs. Since most ATAPI devices don't support multiple LUNs anyway, we might as well fake a response like we do for ATA devices.

Quoted 4 lines

Quoted 1 line

Signed-off-by Darrick J. Wong <[email protected]>

I'm leaning towards applying this, perhaps with a module option that allows experimenters to revert back to the older behavior.

Any chance you could be talked into tackling some of the SAT translation-related items Doug G mentioned? I'm almost certain there are some info pages we should be returning, but are not, at the very least.

I thought we were closing in on agreeing that the SPC/MMC inconsistencies made this the correct candidate fix.

I thought we were closing in on agreeing that the SPC/MMC inconsistencies made this the correct candidate fix.

drivers/scsi/scsi_devinfo.c +0 -0

I tried out the patch below, but with it applied, SCSI still issues REPORT LUNS to the device. It seems that sdev->type = -1 and bflags = 0

when scsi_get_device_flags is called because the type code is not set up until scsi_add_lun, which is called later. In any case, the check doesn't work for me because the SATAPI GoVault reports itself as a Direct Access device, not a CD-ROM.

Er, if it's really a CD-ROM, doesn't it need a blacklist entry with BLIST_ROM then? Regardless, MMC is the only standard that seems to be inconsistent in this regard. Anything claiming to conform to SBC will need to be explicitly blacklisted if it claims SCSI-3 or higher and doesn't support REPORT LUNS.

Sorry, I should have clarified this earlier--the Quantum GoVault is a removable disk drive, not a CD-ROM. The device is reminiscent of Zip disks, but the cartridge is a sealed unit and contains a 2.5" SATA disk inside; hence it's not a CD-ROM. So the patch below won't work for me, because sdev->type == TYPE_DISK.

I wonder if the same sort of REPORT LUNS screw-up might apply to other ATAPI devices too, such as tape drives. Since we've seen that manufacturers of CD-ROMs and removable disks don't implement it, it would not surprise me if the other ATAPI devices don't either. But, that's speculation on my part.

The Quantum GoVault SATAPI removable disk device returns ATA_ERR in response to a REPORT LUNS packet. If this happens to an ATAPI device that is attached to a SAS controller (this is the case with sas_ata), the device does not load because SCSI won't touch a "SCSI device" that won't report its LUNs. Since most ATAPI devices don't support multiple LUNs anyway, we might as well fake a response like we do for ATA devices.

Signed-off-by Darrick J. Wong <[email protected]>

---

 drivers/ata/libata-scsi.c |    9 +++++++--
 1 files changed, 7 insertions(+), 2 deletions(-)

drivers/ata/libata-scsi.c +0 -2

index 47ea111..5ecf260 100644
@@ -2833,8 +2833,13 @@ static inline int __ata_scsi_queuecmd(st
 			rc = ata_scsi_translate(dev, cmd, done, xlat_func);
 		else
 			ata_scsi_simulate(dev, cmd, done);
-	} else
-		rc = ata_scsi_translate(dev, cmd, done, atapi_xlat);

Quoted 7 lines · Darrick J. Wong

The Quantum GoVault SATAPI removable disk device returns ATA_ERR in response to a REPORT LUNS packet. If this happens to an ATAPI device that is attached to a SAS controller (this is the case with sas_ata), the device does not load because SCSI won't touch a "SCSI device" that won't report its LUNs. Since most ATAPI devices don't support multiple LUNs anyway, we might as well fake a response like we do for ATA devices.

If the REPORT LUNS fails, we should fall back to a sequential scan.

Is (or why isn't) the error propagated back to scsi?