Re: Buggy Firewire bridge 'Prolific PL3507'

[James Bottomley <James.Bottomley@HansenPartnership.com>]

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