On Sun, Feb 20, 2005 at 10:47:09PM -0800, Matthew Dharm wrote: > On Sun, Feb 20, 2005 at 10:44:21PM -0500, Alan Stern wrote:
> > Matt, it looks like the best way to solve this problem is to go back to > > the old strategy of always setting the SCSI revision to 2 (no matter what > > it might actually be), at least for Direct Access devices. That would > > suppress the REPORT_LUNS command. Would we lose anything by doing this? > > Besides the use of REPORT_LUNS on devices which actually support it? I > don't think so... It would only matter if the device had sparse luns (multiple luns/disks that are not consecutively numbered). You can always dynamically add it to the black list to force REPORT LUN usage (for SCSI_2 devices) via BLIST_REPORTLUN2, and if it did not support REPORT LUNS add it as sparse lun via BLIST_SPARSELUN. Samuel or other owners of the hardware: did you check for firmware updates? You should make sure the hardware vendor at least knows about the problem. The bridge hardware (USB/firewire to ide) should probably mark it as SCSI 2, and it should be fixed to handle and fail the REPORT LUN in a sane way. > I wonder if printing a warning if sdev->scsi_level > SCSI_2 would be > useful... Probably not. -- Patrick Mansfield - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
