From: Greg Kroah-Hartman Date: Sun, 8 Feb 2009 20:44:32 +0000 (-0800) Subject: firewire .27 patches X-Git-Tag: v2.6.27.16~18 X-Git-Url: http://git.ipfire.org/gitweb.cgi?a=commitdiff_plain;h=763eb262cb0e2ef57d2c534b911e1e9eb72694f3;p=thirdparty%2Fkernel%2Fstable-queue.git firewire .27 patches --- diff --git a/queue-2.6.27/firewire-ohci-increase-at-req.-retries-fix-ack_busy_x-from-panasonic-camcorders-and-others.patch b/queue-2.6.27/firewire-ohci-increase-at-req.-retries-fix-ack_busy_x-from-panasonic-camcorders-and-others.patch new file mode 100644 index 00000000000..68c71e04d4e --- /dev/null +++ b/queue-2.6.27/firewire-ohci-increase-at-req.-retries-fix-ack_busy_x-from-panasonic-camcorders-and-others.patch @@ -0,0 +1,54 @@ +From stefanr@s5r6.in-berlin.de Sun Feb 8 12:42:41 2009 +From: Stefan Richter +Date: Sat, 7 Feb 2009 13:08:41 +0100 (CET) +Subject: firewire: ohci: increase AT req. retries, fix ack_busy_X from Panasonic camcorders and others +To: stable@kernel.org +Message-ID: +Content-Disposition: INLINE + +From: Stefan Richter + +Commit 8b7b6afaa84708d08139daa08538ca3e56c351f1 upstream. + +Camcorders have a tendency to fail read requests to their config ROM and +write request to their FCP command register with ack_busy_X. This has +become a problem with newer kernels and especially Panasonic camcorders, +causing AV/C in dvgrab and kino to fail. Dvgrab for example frequently +logs "send oops"; kino reports loss of AV/C control. I suspect that +lower CPU scheduling latencies in newer kernels made this issue more +prominent now. + +According to +https://sourceforge.net/tracker/?func=detail&atid=114103&aid=2492640&group_id=14103 +this can be fixed by configuring the FireWire controller for more +hardware retries for request transmission; these retries are evidently +more successful than libavc1394's own retry loop (typically 3 tries on +top of hardware retries). + +Presumably the same issue has been reported at +https://bugzilla.redhat.com/show_bug.cgi?id=449252 and +https://bugzilla.redhat.com/show_bug.cgi?id=477279 . + +In a quick test with a JVC camcorder (which didn't malfunction like the +reported camcorders), this change decreased the number of ack_busy_X +from 16 in three runs of dvgrab to 4 in three runs of the same capture +duration. + +Signed-off-by: Stefan Richter +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/firewire/fw-ohci.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/firewire/fw-ohci.c ++++ b/drivers/firewire/fw-ohci.c +@@ -226,7 +226,7 @@ static inline struct fw_ohci *fw_ohci(st + #define CONTEXT_DEAD 0x0800 + #define CONTEXT_ACTIVE 0x0400 + +-#define OHCI1394_MAX_AT_REQ_RETRIES 0x2 ++#define OHCI1394_MAX_AT_REQ_RETRIES 0xf + #define OHCI1394_MAX_AT_RESP_RETRIES 0x2 + #define OHCI1394_MAX_PHYS_RESP_RETRIES 0x8 + diff --git a/queue-2.6.27/firewire-sbp2-add-workarounds-for-2nd-and-3rd-generation-ipods.patch b/queue-2.6.27/firewire-sbp2-add-workarounds-for-2nd-and-3rd-generation-ipods.patch new file mode 100644 index 00000000000..1eae538373c --- /dev/null +++ b/queue-2.6.27/firewire-sbp2-add-workarounds-for-2nd-and-3rd-generation-ipods.patch @@ -0,0 +1,62 @@ +From stefanr@s5r6.in-berlin.de Sun Feb 8 12:43:24 2009 +From: Stefan Richter +Date: Sat, 7 Feb 2009 13:10:00 +0100 (CET) +Subject: firewire: sbp2: add workarounds for 2nd and 3rd generation iPods +To: stable@kernel.org +Message-ID: + +From: Stefan Richter + +Commit c8c4707cf7ca8ff7dcc1653447e48cb3de0bf114 upstream. + +According to https://bugs.launchpad.net/bugs/294391 + - 3rd generation iPods need the "fix capacity" workaround after all + (apparently they crash after the last sector was accessed), + - 2nd generation iPods need the "128 kB maximum request size" + workaround. + +Alas both iPod generations feature the same model ID in the config ROM, +hence we can only define a shared quirks list entry for them. Luckily +the fix capacity workaround did not show a negative effect in Jarod's +tests with 2nd gen. iPod. + +A side note: Apple computers in target mode (or at least an x86 Mac +mini) don't have firmware_version and model_id, hence none of the iPod +quirks list entries is active for them. + +Tested-by: Jarod Wilson +Acked-by: Jarod Wilson +Signed-off-by: Stefan Richter +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/firewire/fw-sbp2.c | 16 +++++++++------- + 1 file changed, 9 insertions(+), 7 deletions(-) + +--- a/drivers/firewire/fw-sbp2.c ++++ b/drivers/firewire/fw-sbp2.c +@@ -350,15 +350,17 @@ static const struct { + .model = ~0, + .workarounds = SBP2_WORKAROUND_128K_MAX_TRANS, + }, +- + /* +- * There are iPods (2nd gen, 3rd gen) with model_id == 0, but +- * these iPods do not feature the read_capacity bug according +- * to one report. Read_capacity behaviour as well as model_id +- * could change due to Apple-supplied firmware updates though. ++ * iPod 2nd generation: needs 128k max transfer size workaround ++ * iPod 3rd generation: needs fix capacity workaround + */ +- +- /* iPod 4th generation. */ { ++ { ++ .firmware_revision = 0x0a2700, ++ .model = 0x000000, ++ .workarounds = SBP2_WORKAROUND_128K_MAX_TRANS | ++ SBP2_WORKAROUND_FIX_CAPACITY, ++ }, ++ /* iPod 4th generation */ { + .firmware_revision = 0x0a2700, + .model = 0x000021, + .workarounds = SBP2_WORKAROUND_FIX_CAPACITY, diff --git a/queue-2.6.27/firewire-sbp2-fix-dma-mapping-leak-on-the-failure-path.patch b/queue-2.6.27/firewire-sbp2-fix-dma-mapping-leak-on-the-failure-path.patch new file mode 100644 index 00000000000..37f9f662801 --- /dev/null +++ b/queue-2.6.27/firewire-sbp2-fix-dma-mapping-leak-on-the-failure-path.patch @@ -0,0 +1,72 @@ +From stefanr@s5r6.in-berlin.de Sun Feb 8 12:43:01 2009 +From: Stefan Richter +Date: Sat, 7 Feb 2009 13:09:15 +0100 (CET) +Subject: firewire: sbp2: fix DMA mapping leak on the failure path +To: stable@kernel.org +Message-ID: + +From: Stefan Richter + +Commit 5e2125677fd72d36396cc537466e07ffcbbd4b2b upstream. + +Reported-by: FUJITA Tomonori +who also provided a first version of the fix. + +Signed-off-by: Stefan Richter +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/firewire/fw-sbp2.c | 27 +++++++++++++++++---------- + 1 file changed, 17 insertions(+), 10 deletions(-) + +--- a/drivers/firewire/fw-sbp2.c ++++ b/drivers/firewire/fw-sbp2.c +@@ -1293,6 +1293,19 @@ static struct fw_driver sbp2_driver = { + .id_table = sbp2_id_table, + }; + ++static void sbp2_unmap_scatterlist(struct device *card_device, ++ struct sbp2_command_orb *orb) ++{ ++ if (scsi_sg_count(orb->cmd)) ++ dma_unmap_sg(card_device, scsi_sglist(orb->cmd), ++ scsi_sg_count(orb->cmd), ++ orb->cmd->sc_data_direction); ++ ++ if (orb->request.misc & cpu_to_be32(COMMAND_ORB_PAGE_TABLE_PRESENT)) ++ dma_unmap_single(card_device, orb->page_table_bus, ++ sizeof(orb->page_table), DMA_TO_DEVICE); ++} ++ + static unsigned int + sbp2_status_to_sense_data(u8 *sbp2_status, u8 *sense_data) + { +@@ -1372,15 +1385,7 @@ complete_command_orb(struct sbp2_orb *ba + + dma_unmap_single(device->card->device, orb->base.request_bus, + sizeof(orb->request), DMA_TO_DEVICE); +- +- if (scsi_sg_count(orb->cmd) > 0) +- dma_unmap_sg(device->card->device, scsi_sglist(orb->cmd), +- scsi_sg_count(orb->cmd), +- orb->cmd->sc_data_direction); +- +- if (orb->page_table_bus != 0) +- dma_unmap_single(device->card->device, orb->page_table_bus, +- sizeof(orb->page_table), DMA_TO_DEVICE); ++ sbp2_unmap_scatterlist(device->card->device, orb); + + orb->cmd->result = result; + orb->done(orb->cmd); +@@ -1530,8 +1535,10 @@ static int sbp2_scsi_queuecommand(struct + orb->base.request_bus = + dma_map_single(device->card->device, &orb->request, + sizeof(orb->request), DMA_TO_DEVICE); +- if (dma_mapping_error(device->card->device, orb->base.request_bus)) ++ if (dma_mapping_error(device->card->device, orb->base.request_bus)) { ++ sbp2_unmap_scatterlist(device->card->device, orb); + goto out; ++ } + + sbp2_send_orb(&orb->base, lu, lu->tgt->node_id, lu->generation, + lu->command_block_agent_address + SBP2_ORB_POINTER); diff --git a/queue-2.6.27/ieee1394-ohci1394-increase-at-req.-retries-fix-ack_busy_x-from-panasonic-camcorders-and-others.patch b/queue-2.6.27/ieee1394-ohci1394-increase-at-req.-retries-fix-ack_busy_x-from-panasonic-camcorders-and-others.patch new file mode 100644 index 00000000000..ad975afff2b --- /dev/null +++ b/queue-2.6.27/ieee1394-ohci1394-increase-at-req.-retries-fix-ack_busy_x-from-panasonic-camcorders-and-others.patch @@ -0,0 +1,50 @@ +From stefanr@s5r6.in-berlin.de Sun Feb 8 12:42:14 2009 +From: Stefan Richter +Date: Sat, 7 Feb 2009 13:08:01 +0100 (CET) +Subject: ieee1394: ohci1394: increase AT req. retries, fix ack_busy_X from Panasonic camcorders and others +To: stable@kernel.org +Message-ID: +Content-Disposition: INLINE + +From: Stefan Richter + +Commit 64c634ef83991b390ec0503e61f16efb0ba3c60b upstream. + +Camcorders have a tendency to fail read requests to their config ROM and +write request to their FCP command register with ack_busy_X. This has +become a problem with newer kernels and especially Panasonic camcorders, +causing AV/C in dvgrab and kino to fail. Dvgrab for example frequently +logs "send oops"; kino reports loss of AV/C control. I suspect that +lower CPU scheduling latencies in newer kernels made this issue more +prominent now. + +According to +https://sourceforge.net/tracker/?func=detail&atid=114103&aid=2492640&group_id=14103 +this can be fixed by configuring the FireWire controller for more +hardware retries for request transmission; these retries are evidently +more successful than libavc1394's own retry loop (typically 3 tries on +top of hardware retries). + +Presumably the same issue has been reported at +https://bugzilla.redhat.com/show_bug.cgi?id=449252 and +https://bugzilla.redhat.com/show_bug.cgi?id=477279 . + +Tested-by: Mathias Beilstein +Signed-off-by: Stefan Richter +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/ieee1394/ohci1394.h | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/ieee1394/ohci1394.h ++++ b/drivers/ieee1394/ohci1394.h +@@ -26,7 +26,7 @@ + + #define OHCI1394_DRIVER_NAME "ohci1394" + +-#define OHCI1394_MAX_AT_REQ_RETRIES 0x2 ++#define OHCI1394_MAX_AT_REQ_RETRIES 0xf + #define OHCI1394_MAX_AT_RESP_RETRIES 0x2 + #define OHCI1394_MAX_PHYS_RESP_RETRIES 0x8 + #define OHCI1394_MAX_SELF_ID_ERRORS 16 diff --git a/queue-2.6.27/ieee1394-sbp2-add-workarounds-for-2nd-and-3rd-generation-ipods.patch b/queue-2.6.27/ieee1394-sbp2-add-workarounds-for-2nd-and-3rd-generation-ipods.patch new file mode 100644 index 00000000000..0826385c097 --- /dev/null +++ b/queue-2.6.27/ieee1394-sbp2-add-workarounds-for-2nd-and-3rd-generation-ipods.patch @@ -0,0 +1,43 @@ +From stefanr@s5r6.in-berlin.de Sun Feb 8 12:43:44 2009 +From: Stefan Richter +Date: Sat, 7 Feb 2009 13:10:36 +0100 (CET) +Subject: ieee1394: sbp2: add workarounds for 2nd and 3rd generation iPods +To: stable@kernel.org +Message-ID: + +From: Stefan Richter + +Commit 1448d7c6a2ff96d3b52ecae49e2d0f046a097fe0 upstream. + +As per https://bugs.launchpad.net/bugs/294391. These got one sample of +each iPod generation going. However there still occurred I/O stalls +with the 3rd generation iPod which remain undiagnosed at the time of +this writing. + +Acked-by: Jarod Wilson +Signed-off-by: Stefan Richter +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/ieee1394/sbp2.c | 10 ++++++++++ + 1 file changed, 10 insertions(+) + +--- a/drivers/ieee1394/sbp2.c ++++ b/drivers/ieee1394/sbp2.c +@@ -395,6 +395,16 @@ static const struct { + .model_id = SBP2_ROM_VALUE_WILDCARD, + .workarounds = SBP2_WORKAROUND_128K_MAX_TRANS, + }, ++ /* ++ * iPod 2nd generation: needs 128k max transfer size workaround ++ * iPod 3rd generation: needs fix capacity workaround ++ */ ++ { ++ .firmware_revision = 0x0a2700, ++ .model_id = 0x000000, ++ .workarounds = SBP2_WORKAROUND_128K_MAX_TRANS | ++ SBP2_WORKAROUND_FIX_CAPACITY, ++ }, + /* iPod 4th generation */ { + .firmware_revision = 0x0a2700, + .model_id = 0x000021, diff --git a/queue-2.6.27/series b/queue-2.6.27/series index e762970d0ef..fdb119ad883 100644 --- a/queue-2.6.27/series +++ b/queue-2.6.27/series @@ -14,3 +14,8 @@ shm-fix-shmctl-lockup-with-config_shmem.patch sound-usb-audio-handle-wmaxpacketsize-for-fixed_endpoint-devices.patch wait-prevent-exclusive-waiter-starvation.patch x86-apic-enable-workaround-on-amd-fam10h-cpus.patch +ieee1394-ohci1394-increase-at-req.-retries-fix-ack_busy_x-from-panasonic-camcorders-and-others.patch +firewire-ohci-increase-at-req.-retries-fix-ack_busy_x-from-panasonic-camcorders-and-others.patch +firewire-sbp2-fix-dma-mapping-leak-on-the-failure-path.patch +firewire-sbp2-add-workarounds-for-2nd-and-3rd-generation-ipods.patch +ieee1394-sbp2-add-workarounds-for-2nd-and-3rd-generation-ipods.patch