Re: [stable] [PATCH 1/2] sd: fix memory corruption by sd_read_cache_type

[Stefan Richter <stefanr@s5r6.in-berlin.de>]

Al Viro wrote:
> On Sun, Feb 26, 2006 at 09:11:08AM +0100, Stefan Richter wrote:
> > Al Viro wrote:
> > > Speaking of sbp2 problems...  Why the _hell_ are we blacklisting on
> > > firmware revision alone?  Especially with entries like "all firmware
> > > with 2.<whatever> as version is broken"...
> > The firmware_revision CSR key value has so far been a good method to 
> > guesstimate the bridge chip. I don't know a better one.
> Umm...  What about ->vendor_name_kv (plus firmware_revision, obviously)?
Not a single one of the devices in my collection features vendor_name_kv 
in the ROM's unit directory. The vendor_name_kv in the ROM's root 
directory more often reflects the vendor of the enclosure or bridge 
board than the vendor of the bridge chip. (Most vendors of enclosures or 
boards seem to put only their name into a firmware although they have 
the opportunity for market differentiation by an own firmware full of 
their very own bugs...)
> > I posted an improved blacklisting patch a few days ago. Among other 
> > small cleanups, I removed skip_ms_page_8 from the Initio blacklist entry.
> > http://marc.theaimsgroup.com/?l=linux1394-devel&m=114065678722190
> FWIW, that puppy appears to live just fine without forcing 36byte
> inquiry here...
A few older Initio based enclosures needed it. Newer don't, including 
the one I have here. AFAIK the 36byte inquiry workaround does not break 
anything if forced onto non-broken devices.
--
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/