Buggy Firewire bridge 'Prolific PL3507'

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 ...

Cheers,

Hannes

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."

It's hald or something like that.

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).

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/

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

Huh, AFAIK, we only send SCSI commands to optical drives [1] and not anything else. For optical drives, we issue these commands to

- figure out what discs the drive supports
- the kernel knows this and used to export it in a flat file in /proc that wasn't really helpful
- get read/write speeds (depends on the media currently inserted IIRC)
- figure out if a disc is appendable
- figure out if a disc is rewritable
- get the capacity of a disc

and perhaps others (don't have the code handy right here but can give you a definite list).

(I admit this is a big mess and it would be ideal if the kernel can export this information - some of it is somewhat expensive to figure out so perhaps should only be invoked when reading a sysfs file? I don't know).

So it seems like people are experiencing this problem on non-optical drives, right?. So, my knee-jerk reaction would be to say that the assumption that hald is to blame is wrong since I'm pretty sure we only issue SCSI commands for optical drives.

Also, keep in mind that we do a lot of IO to probe for the file system on the actual disc including trying to get e.g. the iso9660 file system label of the latest session. Maybe this trivial IO is what is causing the hiccups?

(Notably udev doesn't do this for optical discs [2] but it does it for everything else (e.g. runs /lib/udev/vol_id - the exactly same code hald is using.).

Perhaps if you can point to what SCSI commands hald are sending it would be easier to debug. Any other ideas?

Thanks,
David

[1] : the way we determine a drive is an optical drive on SCSI is by checking if

/sys/devices/pci0000:00/0000:00:1f.2/host1/target1:0:0/1:0:0:0/type

has the value 5.

[2] : udev doesn't probe optical discs just yet because for some reason sessions/partitions isn't exported by the kernel for this kind of media (annoying, but understandable).

-
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

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

Can't we get hald to look at the cached results of the inquiry command, handily available through sysfs?

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.

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."

[...]

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.

[...]

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/