On Tue, 28 Jul 2009, Martin K. Petersen wrote: > While looking into this problem Boaz directed my attention towards this > piece of code in scsiglue.c: > > /* Some devices report a SCSI revision level above 2 but are > * unable to handle the REPORT LUNS command (for which > * support is mandatory at level 3). Since we already have > * a Get-Max-LUN request, we won't lose much by setting the > * revision level down to 2. The only devices that would be > * affected are those with sparse LUNs. */ > if (sdev->scsi_level > SCSI_2) > sdev->sdev_target->scsi_level = > sdev->scsi_level = SCSI_2; > > Can you shed some light on these devices and maybe an alternate way of > working around this issue? Drives with 4KB physical blocks are coming > out soon so dumbing down the SCSI level is not going to cut it for much > longer... We won't get into trouble until there are USB interfaces for those drives. Of course, that's just postponing the inevitable... The problem we faced was that several devices would simply crash when they received a REPORT LUNS command. More than just one type from a single vendor; there were several different models that all failed the same way. In theory we could blacklist the bad drives, but I don't know if that would work in practice -- there might be too many of them. Not to mention that people would get upset because their drives would stop working until the blacklist entries were added. Or we could add yet another flag telling scsi_report_lun_scan() to give up, and set this flag for all USB mass-storage devices. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
