Buggy Firewire bridge 'Prolific PL3507'

Buggy Firewire bridge 'Prolific PL3507'

[Hannes Reinecke]

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

Re: Buggy Firewire bridge 'Prolific PL3507'

[Matthew Wilcox]

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

Re: Buggy Firewire bridge 'Prolific PL3507'

[Stefan Richter]

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/

Re: Buggy Firewire bridge 'Prolific PL3507'

[James Bottomley]

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

Re: Buggy Firewire bridge 'Prolific PL3507'

[Matthew Wilcox]

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

Re: Buggy Firewire bridge 'Prolific PL3507'

[Stefan Richter]

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/

Re: Buggy Firewire bridge 'Prolific PL3507'

[maximilian attems]

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

Re: Buggy Firewire bridge 'Prolific PL3507'

[David Zeuthen]

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

Re: Buggy Firewire bridge 'Prolific PL3507'

[David Zeuthen]

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