From: Stefan Richter <stefanr@s5r6.in-berlin.de>
To: Jarod Wilson <jarod@redhat.com>
Cc: linux1394-devel@lists.sourceforge.net,
linux-kernel@vger.kernel.org,
"Kristian Høgsberg" <krh@bitplanet.net>,
"Alan Stern" <stern@rowland.harvard.edu>
Subject: Re: [PATCH RFT 7/7] firewire: sbp2: add workarounds for 2nd and 3rd generation iPods
Date: Thu, 29 Jan 2009 21:09:29 +0100 [thread overview]
Message-ID: <49820CF9.3000706@s5r6.in-berlin.de> (raw)
In-Reply-To: <200901282218.42604.jarod@redhat.com>
(adding Cc: Alan Stern just in case, because he knows much more about
all this)
Jarod Wilson wrote:
> On a related note... The fix capacity workaround... I think I need to
> observe this failure myself... My own 4th-gen ipod, when connected to a
> Mac OS X system, reports the exact capacity I get if the fix capacity
> workaround is disabled. Do they just know not to try to access that
> last block, or is the need for this workaround a myth? :)
Well, before the report [1] from the Ubuntu of a what appeared to be a
regression of Ubuntu 8.10 vs. its parent or grandparent release, we
thought we knew that iPod 2nd + 3rd gen were _not_ affected, because
long ago an owner of these iPods told us so.
Obviously they changed something in Ubuntu 8.10 which suddenly made 3rd
gen iPods vulnerable too. If the report is accurate, then this is /not/
the READ CAPACITY 10 issue where device's capacity report is off by one.
(The reported capacity without workaround is an even number and thus
possibly correct.) Rather, this is apparently the kind of the bug where
an access which includes the last sector corrupts some state in the
firmware, causing the firmware to error out on subsequent accesses. The
actual IO errors in the reporter's log happen at low LBAs, not at LBAs
at the end.
Anyway; to our moderate surprise after years of successful usage of
these devices under Linux, we learn that a current Linux suddenly needs
a quirk fix for them. IMO they always needed it but they just weren't
exposed to the dangerous access patterns, until userland or the kernel
was changed in an as yet unidentified respect.
Back to the question whether the 4th gen iPod really needs it. Well,
I'm quite sure that we added it because it was proven to be necessary.
At least that's what I remember about it; if we really wanted to we
could probably find evidence in list archives. I don't remember which
particular type of last sector bug it was in case of these newer iPod
models. Coincidentally, those dual interface iPods also need the
workaround when used through usb-storage; see
drivers/usb/storage/unusual_devs.h.
Now, what does OS X do with those iPods? I don't know. Maybe they have
quirks lists like we do. There could be something to be found in the
Darwin sources. But I consider it more likely that OS X simply does not
do the kind of accesses that Linux does which tend to crash all those
crap firmwares left and right.
Evidently, at least popular Windows incarnations don't do such accesses,
at least not in normal usage. Otherwise this class of firmware bugs
could simply not exist in mass market devices.
[1] https://bugs.launchpad.net/bugs/294391
--
Stefan Richter
-=====-==--= ---= ===-=
http://arcgraph.de/sr/
next prev parent reply other threads:[~2009-01-29 20:10 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-01-24 18:41 [PATCH 0/7] ieee1394 + firewire: misc sbp2 updates Stefan Richter
2009-01-24 18:42 ` [PATCH 1/7] firewire: sbp2: fix payload limit at S1600 and S3200 Stefan Richter
2009-01-24 18:42 ` [PATCH 2/7] firewire: sbp2: define some magic numbers as macros Stefan Richter
2009-01-24 18:43 ` [PATCH 3/7] ieee1394: sbp2: fix payload limit at S1600 and S3200 Stefan Richter
2009-01-24 18:44 ` [PATCH 4/7] ieee1394: sbp2: don't assume zero model_id or firmware_revision if there is none Stefan Richter
2009-01-24 18:45 ` [PATCH 5/7] ieee1394: sbp2: follow up on "ieee1394: inherit ud vendor_id from node vendor_id" Stefan Richter
2009-01-24 18:45 ` [PATCH RFT 6/7] ieee1394: sbp2: add workarounds for 2nd and 3rd generation iPods Stefan Richter
2009-01-24 22:29 ` Stefan Richter
2009-01-24 18:46 ` [PATCH RFT 7/7] firewire: " Stefan Richter
2009-01-28 22:18 ` Jarod Wilson
2009-01-28 22:25 ` Jarod Wilson
2009-01-28 23:11 ` [PATCH revised] " Stefan Richter
2009-01-28 23:13 ` [PATCH revised] ieee1394: " Stefan Richter
2009-01-29 3:21 ` Jarod Wilson
2009-01-29 3:20 ` [PATCH revised] firewire: " Jarod Wilson
2009-01-28 23:11 ` [PATCH RFT 7/7] " Stefan Richter
2009-01-29 3:18 ` Jarod Wilson
2009-01-29 20:09 ` Stefan Richter [this message]
2009-01-29 20:40 ` Alan Stern
2009-01-29 21:28 ` Stefan Richter
2009-01-29 22:38 ` Alan Stern
2009-01-30 15:16 ` Jarod Wilson
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=49820CF9.3000706@s5r6.in-berlin.de \
--to=stefanr@s5r6.in-berlin.de \
--cc=jarod@redhat.com \
--cc=krh@bitplanet.net \
--cc=linux-kernel@vger.kernel.org \
--cc=linux1394-devel@lists.sourceforge.net \
--cc=stern@rowland.harvard.edu \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.