Re: Buggy Firewire bridge 'Prolific PL3507'
On Tue, Jan 08, 2008 at 02:43:34PM +0100, Hannes Reinecke wrote: Hi all, 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? 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. 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. -- Intel are signing my paycheques ... these opinions are still mine Bill, look, we understand that you're interested in selling us this operating system, but compare it to ours. We can't possibly take such a retrograde step. - 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
Re: Buggy Firewire bridge 'Prolific PL3507'
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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Buggy Firewire bridge 'Prolific PL3507'
On Tue, 2008-01-08 at 18:56 +0100, Stefan Richter wrote: 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. Not to hijack the thread, but this is getting to be a broken record. I was dealing only a few days ago with a camera presenting as a mass storage device that was then crashing and going offline. I looked at the dmesg trace which showed that the SCSI layer completes its probing successfully, and said it was some other extraneous command issued from user level causing the crash. Sure enough, stopping hald fixed the camera so it functioned as a mass storage device properly. The bug report is here: https://bugs.launchpad.net/ubuntu/+source/hal/+bug/180472 What is the point of having SCSI be so careful in its probing and setup so as not to annoy these devices, and then have hald or another standard component blithely go and wreck the device by issuing unwarranted SCSI commands? Can we please stop hald from issuing SCSI commands ... we should have the infrastructure in place now that renders this unnecessary ... unless there's still some information it needs that we're not providing? James - 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
Re: Buggy Firewire bridge 'Prolific PL3507'
On Tue, Jan 08, 2008 at 06:56:11PM +0100, Stefan Richter wrote: It's hald or something like that. Can't we get hald to look at the cached results of the inquiry command, handily available through sysfs? Matthew Wilcox wrote: 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). According to SPC4r05a, READ CAPACITY(10) (opcode 25) is Mandatory for D, W and O. READ CAPACITY (opcode 25) is Optional for R. READ CARD CAPACITY (also opcode 25) is Mandatory for K. D - DIRECT ACCESS BLOCK DEVICE (SBC-3) W - WRITE ONCE BLOCK DEVICE (SBC) O - OPTICAL MEMORY BLOCK DEVICE (SBC) R - CD/DVD DEVICE (MMC-6) K - OPTICAL CARD READER/WRITER DEVICE (OCRW) According to this table (D.2 for anyone following along at home), RBC devices are not supposed to implement it. 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). It would be thoroughly inappropriate to put this workaround in the midlayer. sbp2 isn't a good place either, but it's better than sg/sd/scsi_ioctl/... -- Intel are signing my paycheques ... these opinions are still mine Bill, look, we understand that you're interested in selling us this operating system, but compare it to ours. We can't possibly take such a retrograde step. - 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
Re: Buggy Firewire bridge 'Prolific PL3507'
Matthew Wilcox wrote: According to SPC4r05a, READ CAPACITY(10) (opcode 25) is Mandatory for D, W and O. READ CAPACITY (opcode 25) is Optional for R. READ CARD CAPACITY (also opcode 25) is Mandatory for K. [...] According to this table (D.2 for anyone following along at home), RBC devices are not supposed to implement it. RBC (last draft in 1999, last amendment in 2003) and SPC4 (last draft in 2007) are in contradiction in this regard. It looks like an error in SPC4 to me. [...] It would be thoroughly inappropriate to put this workaround in the midlayer. sbp2 isn't a good place either, but it's better than sg/sd/scsi_ioctl/... Three workarounds are possible, all of them work at the command set level: - Inject READ CAPACITY after INQUIRY. - Don't let INQUIRY through to the device (except the kernel's initial one) and return synthesized inquiry data to the application. - Don't issue INQUIRY at all (except the kernel's initial one). *None* of these workarounds belongs into SCSI midlayer nor into anything below it. Most certainly not into the SBP-2 transport layer. If at all, the SBP-2 layer could contain a detection of affected firmwares, but not the workaround itself. Since userspace is issuing the problematic commands, one /might/ think about implementing the workaround directly at the kernel's userspace interface. You could think of it as a filter then. If you don't like such a filtering, leave the workaround to userspace. And the latter is IMO most preferrable, like James already wrote: Don't let hald issue INQUIRY in the first place. -- Stefan Richter -=-==--- ---= -=--- http://arcgraph.de/sr/ - 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
Re: Buggy Firewire bridge 'Prolific PL3507'
On Tue, Jan 08, 2008 at 12:10:47PM -0600, James Bottomley wrote: Not to hijack the thread, but this is getting to be a broken record. I was dealing only a few days ago with a camera presenting as a mass storage device that was then crashing and going offline. I looked at the dmesg trace which showed that the SCSI layer completes its probing successfully, and said it was some other extraneous command issued from user level causing the crash. Sure enough, stopping hald fixed the camera so it functioned as a mass storage device properly. The bug report is here: https://bugs.launchpad.net/ubuntu/+source/hal/+bug/180472 What is the point of having SCSI be so careful in its probing and setup so as not to annoy these devices, and then have hald or another standard component blithely go and wreck the device by issuing unwarranted SCSI commands? Can we please stop hald from issuing SCSI commands ... we should have the infrastructure in place now that renders this unnecessary ... unless there's still some information it needs that we're not providing? James full ack, writing over a stupid hsdpa usb modem that stops working with hald crap. hald keeps resetting the thingy. -- maks - 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
Re: Buggy Firewire bridge 'Prolific PL3507'
On Tue, 2008-01-08 at 15:10 -0500, David Zeuthen wrote: Perhaps if you can point to what SCSI commands hald are sending it would be easier to debug. Any other ideas? Also, if you can identify the name of the process image doing this it would be helpful. I know both libipoddevice and libgpod both install code that is executed by hald that sends SCSI commands to iPod's to get the system info from recent iPod's (no longer available as a file). FWIW, I've never seen any bugs like this on Fedora or maybe the Fedora kernel maintainers never forwarded / reassigned them to me (and they normally do this). If there's anything I can do to reproduce this or otherwise help, please let me know. David - 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
