On Tue, 2008-01-08 at 12:10 -0600, James Bottomley wrote: > 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? 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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
