Re: Buggy Firewire bridge 'Prolific PL3507'

[David Zeuthen <david@fubar.dk>]

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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html