From: Stefan Richter <stefanr@s5r6.in-berlin.de>
To: Al Viro <viro@ftp.linux.org.uk>
Cc: Chris Wright <chrisw@sous-sol.org>,
stable@kernel.org, Linus Torvalds <torvalds@osdl.org>,
Jody McIntyre <scjody@modernduck.com>,
linux-kernel@vger.kernel.org, linux-scsi@vger.kernel.org
Subject: Re: [stable] [PATCH 1/2] sd: fix memory corruption by sd_read_cache_type
Date: Sun, 26 Feb 2006 10:11:48 +0100 [thread overview]
Message-ID: <440170D4.4040103@s5r6.in-berlin.de> (raw)
In-Reply-To: <20060226082206.GN27946@ftp.linux.org.uk>
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/
next prev parent reply other threads:[~2006-02-26 9:13 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-02-23 1:02 [PATCH 1/2] sd: fix memory corruption by sd_read_cache_type Stefan Richter
2006-02-25 2:10 ` [stable] " Chris Wright
2006-02-25 23:07 ` Stefan Richter
2006-02-25 23:22 ` Al Viro
2006-02-26 8:11 ` Stefan Richter
2006-02-26 8:22 ` Al Viro
2006-02-26 9:11 ` Stefan Richter [this message]
2006-02-26 0:01 ` Linus Torvalds
2006-02-26 0:17 ` Al Viro
2006-02-26 0:39 ` Linus Torvalds
2006-02-26 8:39 ` Jeff Garzik
2006-02-26 9:00 ` Al Viro
2006-02-26 10:45 ` Jeff Garzik
2006-02-26 11:47 ` Al Viro
2006-02-26 5:14 ` James Bottomley
2006-02-26 5:31 ` Al Viro
2006-02-26 8:29 ` Stefan Richter
2006-02-26 14:34 ` James Bottomley
2006-02-26 14:57 ` Al Viro
2006-02-26 16:21 ` Stefan Richter
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=440170D4.4040103@s5r6.in-berlin.de \
--to=stefanr@s5r6.in-berlin.de \
--cc=chrisw@sous-sol.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
--cc=scjody@modernduck.com \
--cc=stable@kernel.org \
--cc=torvalds@osdl.org \
--cc=viro@ftp.linux.org.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox