lkml.org 
[lkml]   [2006]   [Feb]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 7/8] don't mangle INQUIRY if cmddt or evpd bits are set
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.

> The latter
> might be more interesting - RBC devices are only required to implement
> MODE SENSE/SELECT page 6; they shouldn't get messed by the rest, but at
> least some of them blindly respond with page 6 to _every_ MODE SENSE.
> So that might be a good reason to blacklist.

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

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.
--
Stefan Richter
-=====-=-==- --=- -==-=
http://arcgraph.de/sr/
-
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/

\
 
 \ /
  Last update: 2006-02-13 21:31    [W:0.095 / U:0.252 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site