From: Stefan Richter <stefanr@s5r6.in-berlin.de>
To: stable@kernel.org
Cc: linux-kernel@vger.kernel.org
Subject: [PATCH 2.6.16.18 0/4] sbp2: workaround for buggy iPods
Date: Sat, 27 May 2006 14:58:57 +0200 (CEST) [thread overview]
Message-ID: <tkrat.b9bf60697156ef7b@s5r6.in-berlin.de> (raw)
There is a firmware bug in several Apple iPods which prevents access to
these iPods under certain conditions. The disk size reported by the iPod
is one sector too big. Once access to the end of the disk is attempted,
the iPod becomes inaccessible. This problem has been known for USB iPods
for some time and has recently been discovered to exist with
FireWire/USB combo iPods too.
The following patchset is the fix as it exists in Linux 2.6.17-rc. Alas
it is rather large, therefore it may be unfit for -stable as it is. If
there are objections, I would appreciate suggestions how to better adapt
this fix for -stable.
The necessary workaround is added this way:
patch 1/4: sbp2: consolidate workarounds, part one
patch 2/4: sbp2: consolidate workarounds, part two
Infrastructure for existing *unrelated* workarounds is refactored.
This concerns (a) module load parameters to activate workarounds,
(b) a hardwired blacklist of known buggy devices, (c) detection of
known buggy devices, (d) activation of the various workarounds.
Benefits of the refactoring are better readability, extensibility,
and finer-grained control.
This is a single patch in 2.6.17-rc; I split it into two due to its
size (the essential part and a part affecting comments, log messages
etc.).
patch 3/4: add read_capacity workaround for iPod
Extends blacklist and device detection, and adds the actual
workaround.
patch 4/4: sbp2: add ability to override hardwired blacklist
As we add more workarounds, potential to adversely affect other
devices increases. This patch adds a simple feature as a safety
belt: A new flag for the module load parameter from patch 1/4
tells sbp2 not to use its hardwired blacklist.
Combined diffstat of patches 1/4...4/4:
Documentation/feature-removal-schedule.txt | 9 +
drivers/ieee1394/sbp2.c | 206 +++++++++++++++++++----------
drivers/ieee1394/sbp2.h | 18 +-
3 files changed, 159 insertions(+), 74 deletions(-)
So this is much more than is usually acceptable for -stable. Keeping it
this big has the benefit of minimal deviation from 2.6.17+, concerning
the code as well as sbp2's module load parameters. As I said, I could
try to rework this for minimum patch size if so desired by the -stable
team. But I suppose I would still end up with a rather big patch.
The impact of leaving this iPod workaround out of -stable is limited
because there are a few alternatives:
- Experienced users of affected hardware may compile 2.6.16 and older
without support for EFI GUID partition tables. This should make
access to the end of the disk rather unlikely.
- Experienced users of affected hardware may switch to 2.6.17+.
- Experienced users or distributors may apply this patchset or a more
extensive patchset for the 1394 subsystem on their own. (I am
maintaining a bunch of rediffs of current 1394 patches for released
kernels.)
--
Stefan Richter
-=====-=-==- -=-= ==-==
http://arcgraph.de/sr/
next reply other threads:[~2006-05-27 12:59 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-05-27 12:58 Stefan Richter [this message]
2006-05-27 13:00 ` [PATCH 2.6.16.18 1/4] sbp2: consolidate workarounds, part one Stefan Richter
2006-05-27 13:01 ` [PATCH 2.6.16.18 2/4] sbp2: consolidate workarounds, part two Stefan Richter
2006-05-27 13:04 ` [PATCH 2.6.16.18 3/4] sbp2: add read_capacity workaround for iPod Stefan Richter
2006-05-27 13:06 ` [PATCH 2.6.16.18 4/4] sbp2: add ability to override hardwired blacklist Stefan Richter
2006-05-30 23:19 ` [stable] [PATCH 2.6.16.18 0/4] sbp2: workaround for buggy iPods Chris Wright
2006-05-31 16:45 ` Stefan Richter
2006-06-02 17:34 ` [PATCH 2.6.16.19] sbp2: backport read_capacity workaround for iPod Stefan Richter
2006-06-02 17:46 ` [stable] " Chris Wright
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=tkrat.b9bf60697156ef7b@s5r6.in-berlin.de \
--to=stefanr@s5r6.in-berlin.de \
--cc=linux-kernel@vger.kernel.org \
--cc=stable@kernel.org \
/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
all inboxes | Powered by JetHome®