From: Jarod Wilson <jarod@redhat.com>
To: linux1394-devel@lists.sourceforge.net
Cc: "Stefan Richter" <stefanr@s5r6.in-berlin.de>,
"Kristian Høgsberg" <krh@bitplanet.net>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH RFT 7/7] firewire: sbp2: add workarounds for 2nd and 3rd generation iPods
Date: Wed, 28 Jan 2009 17:25:25 -0500 [thread overview]
Message-ID: <200901281725.25750.jarod@redhat.com> (raw)
In-Reply-To: <200901281718.41873.jarod@redhat.com>
On Wednesday 28 January 2009 17:18:41 Jarod Wilson wrote:
> > - Is the "no page tables" workaround really necessary for 2nd gen.
> > iPods, or is the 128k limit sufficient as reported for the Ubuntu
> > 8.10 kernel?
>
> Looks to me like the no page tables workaround isn't needed. I could
> have sworn the defaults w/this patch (workarounds 0x48) was actually
> causing dd to fail last night, but I haven't been able to reproduce
> that failure, now that I'm trying (maybe I this ipod mixed up with one
> of the others in the pile...).
Yep, I'm a dummy. The failure I was thinking of was w/the completely
flaky 3rd-gen iPod, just went back and looked at logs.
So far as I can tell, I'm thinking 128k limit + fix capacity should be
okay for both the 2nd and 3rd-gen iPods, and if someone comes up with
evidence that the 2nd-gen does something badly w/the fix capacity
workaround enabled, then we revisit trying to apply the workarounds
more narrowly somehow.
--
Jarod Wilson
jarod@redhat.com
next prev parent reply other threads:[~2009-01-28 22:25 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 [this message]
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
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=200901281725.25750.jarod@redhat.com \
--to=jarod@redhat.com \
--cc=krh@bitplanet.net \
--cc=linux-kernel@vger.kernel.org \
--cc=linux1394-devel@lists.sourceforge.net \
--cc=stefanr@s5r6.in-berlin.de \
/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.