Matthew Wilcox wrote: > On Tue, Jan 08, 2008 at 02:43:34PM +0100, Hannes Reinecke wrote: >> I have here a buggy firewire bridge (Prolific PL3507) which requires >> that each 'INQUIRY' command is followed by a 'READ CAPACITY' command. >> Otherwise any read will return invalid data (the payload is preceded >> by 36 empty bytes). >> >> How to fix this? Sure one could add a hack to sbp2.c to always issue >> a READ CAPACITY after INQUIRY, but this somehow feels wrong ... > > There's only one place in the scsi stack that issues INQUIRY -- > scsi_scan.c [1]. sd is going to issue READ CAPACITY before it issues > any READ commands, so I don't see where you're having this problem. > Is it with some program issuing INQUIRY through SG_IO or something? It's hald or something like that. > I have a hard time thinking this needs to be handled generically > because READ CAPACITY isn't in the Primary Command Set, unlike INQUIRY. > It's mandatory for SBC devices to implement it, but other devices > shouldn't even implement it. It is also mandatory in RBC, which most SBP-2 to IDE or SBP-2 to SATA bridges implement (besides MMC, if a CD/DVD-ROM/R/W is attached). > My opinion is that it needs to be handled either in the application > issuing sg commands or in sbp2. > > [1] yes, there are others, such as drivers and scsi_transport_spi, but > none relevant to sbp2. > Hannes, first check whether the PL3507 is of a variant which can be fixed by firmware upload. You need a Windows PC with USB to check whether firmware can be uploaded, and if yes, to upload a firmware image. Have a look at http://wiki.linux1394.org/FirmwareDownload . If this is not possible, ask the vendor of the device for replacement. It is defective after all. That said, maybe you can convince the maintainers of whatever userspace program issues the second INQUIRY to be extra careful with buggy PL3507 firmwares. Or deactivate that program. I would not at all like to see a respective workaround added to the sbp2 driver. Sbp2 is a transport layer which does not touch commands. Maybe an in-kernel workaround would be considered by whoever maintains the point where that extra INQUIRY is injected (via sd or sg, I don't know which). -- Stefan Richter -=====-==--- ---= -=--- http://arcgraph.de/sr/ - To unsubscribe from this list: 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
