Re: [PATCH 7/8] don't mangle INQUIRY if cmddt or evpd bits are set

[Al Viro <viro@ftp.linux.org.uk>]

On Mon, Feb 13, 2006 at 09:28:17PM +0100, Stefan Richter wrote:
> Al Viro wrote:
> >On Mon, Feb 13, 2006 at 05:19:55PM +0100, Stefan Richter wrote:
> >>BTW, a Prolific based enclosure indeed seems to be unable to handle
> >>CD-ROMs after scsiinfo treatment. An enclosure based on an old
> >>revision of TI StorageLynx apparently causes mode_sense -> check
> >>condition/ unit attention loops when scsiinfo tries to access some
> >>mode page.
> >
> >The former is best treated by using the hardware in question as a pissuary,
> >to make sure that its contents matches the quality of design.
> 
> I have got the impression that most of IEEE 1394a/ USB 2.0 combo bridges 
> on the market are now based on Prolific chips.

Unfortunately.  Finding OXFW911-based ones for about the same price is still
not hard...

> Some more findings:
>  - The TI StorageLynx based bridge reports device type 0 (TYPE_DISK).
>    The problem occurs apparently with page 4 and page 8. Sbp2 has a
>    fix since yesterday which sets the skip_ms_page_8 flag.

That's going to cause fun problems on reboot if it actually has write-behind
cache...

>    http://marc.theaimsgroup.com/?l=linux1394-devel&m=113969287630893
>  - Another bridge made by the same manufacturer but based on TI
>    StorageLynx revision A features the same MODE SENSE bug. This bridge
>    reports type 14 (TYPE_RBC).

Pardon?  If it's type 14, we won't issue MODE SENSE for page 8 and will
go for page 6 instead...

>  - I tested a tenth bridge now, based on Initio INIC-2430F. The bridge
>    reports TYPE_DISK and seems to support all pages which scsiinfo is
>    interested in. Sd_mod is a different story: After sd_mod accesses
>    page 8, the kernel panics. (This is discussed in another thread. The
>    mentioned sbp2 patch catches this bridge as a skip_ms_page_8
>    candidate too, thus avoids the panic. I will eventually check what
>    sd_mod is doing; the sbp2 patch is not the real fix.)

sd_mod issues MODE SENSE from sd_read_cache_size() and does that twice -
once for minimal length to get the length device wants to give and then
for actual length.

> Of course sg does not care for any black list flags (like sd_mod and 
> sr_mod do), but considering the nature of the bugs and anticipated usage 
> of affected devices, there is hardly a reason for further safeguards in 
> sbp2, let alone sg.

Maybe, maybe not.  Note that e.g. aforementioned INQUIRY bug in pl3507 is
triggered by dmraid, which works via SG_IO, just as scsiinfo.  And unlike
scsiinfo it's run from /etc/rc.sysinit on current FC4...
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/