rpms/kernel/devel kernel.spec, 1.581, 1.582 linux-2.6-firewire-git-pending.patch, 1.24, 1.25
Jarod Wilson (jwilson)
fedora-extras-commits at redhat.com
Fri Apr 4 21:08:11 UTC 2008
Author: jwilson
Update of /cvs/pkgs/rpms/kernel/devel
In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv31588
Modified Files:
kernel.spec linux-2.6-firewire-git-pending.patch
Log Message:
* Fri Apr 04 2008 Jarod Wilson <jwilson at redhat.com>
- firewire: add logging of register access failures to debug spew
- firewire: don't append AT packets to halted contexts (because certain
crappy controllers lock up if you do).
Index: kernel.spec
===================================================================
RCS file: /cvs/pkgs/rpms/kernel/devel/kernel.spec,v
retrieving revision 1.581
retrieving revision 1.582
diff -u -r1.581 -r1.582
--- kernel.spec 4 Apr 2008 19:58:34 -0000 1.581
+++ kernel.spec 4 Apr 2008 21:07:22 -0000 1.582
@@ -1153,9 +1153,9 @@
# linux1394 git patches
ApplyPatch linux-2.6-firewire-git-update.patch
C=$(wc -l $RPM_SOURCE_DIR/linux-2.6-firewire-git-pending.patch | awk '{print $1}')
-#if [ "$C" -gt 10 ]; then
-#ApplyPatch linux-2.6-firewire-git-pending.patch
-#fi
+if [ "$C" -gt 10 ]; then
+ApplyPatch linux-2.6-firewire-git-pending.patch
+fi
# usb video
ApplyPatch linux-2.6-uvcvideo.patch
@@ -1758,6 +1758,11 @@
%kernel_variant_files -a /%{image_install_path}/xen*-%{KVERREL}.xen -e /etc/ld.so.conf.d/kernelcap-%{KVERREL}.xen.conf %{with_xen} xen
%changelog
+* Fri Apr 04 2008 Jarod Wilson <jwilson at redhat.com>
+- firewire: add logging of register access failures to debug spew
+- firewire: don't append AT packets to halted contexts (because certain
+ crappy controllers lock up if you do).
+
* Fri Apr 04 2008 Dave Jones <davej at redhat.com>
- 2.6.25-rc8-git3
linux-2.6-firewire-git-pending.patch:
Index: linux-2.6-firewire-git-pending.patch
===================================================================
RCS file: /cvs/pkgs/rpms/kernel/devel/linux-2.6-firewire-git-pending.patch,v
retrieving revision 1.24
retrieving revision 1.25
diff -u -r1.24 -r1.25
--- linux-2.6-firewire-git-pending.patch 2 Apr 2008 14:49:30 -0000 1.24
+++ linux-2.6-firewire-git-pending.patch 4 Apr 2008 21:07:22 -0000 1.25
@@ -53,4 +53,180 @@
init_completion(&orb->done);
+--
+Jarod Wilson
+jwilson at redhat.com
+
+While trying to debug this piece of crap JMicron PCI-e controller in my
+possession, one thought was that perhaps I was encountering register access
+failures. I'm not, but logging them would be good, so we can see if they
+are a real problem we should be taking into account anywhere in the code.
+
+Signed-off-by: Jarod Wilson <jwilson at redhat.com>
+
+---
+
+ drivers/firewire/fw-ohci.c | 12 +++++++++---
+ drivers/firewire/fw-ohci.h | 1 +
+ 2 files changed, 10 insertions(+), 3 deletions(-)
+
+diff --git a/drivers/firewire/fw-ohci.c b/drivers/firewire/fw-ohci.c
+index 3d4ef3f..26befb7 100644
+--- a/drivers/firewire/fw-ohci.c
++++ b/drivers/firewire/fw-ohci.c
+@@ -257,7 +257,7 @@ static void log_irqs(u32 evt)
+ if (likely(!(param_debug & OHCI_PARAM_DEBUG_IRQS)))
+ return;
+
+- printk(KERN_DEBUG KBUILD_MODNAME ": IRQ %08x%s%s%s%s%s%s%s%s%s%s%s\n",
++ printk(KERN_DEBUG KBUILD_MODNAME ": IRQ %08x%s%s%s%s%s%s%s%s%s%s%s%s\n",
+ evt,
+ evt & OHCI1394_selfIDComplete ? " selfID" : "",
+ evt & OHCI1394_RQPkt ? " AR_req" : "",
+@@ -269,11 +269,13 @@ static void log_irqs(u32 evt)
+ evt & OHCI1394_postedWriteErr ? " postedWriteErr" : "",
+ evt & OHCI1394_cycleTooLong ? " cycleTooLong" : "",
+ evt & OHCI1394_cycle64Seconds ? " cycle64Seconds" : "",
++ evt & OHCI1394_regAccessFail ? " regAccessFail" : "",
+ evt & ~(OHCI1394_selfIDComplete | OHCI1394_RQPkt |
+ OHCI1394_RSPkt | OHCI1394_reqTxComplete |
+ OHCI1394_respTxComplete | OHCI1394_isochRx |
+ OHCI1394_isochTx | OHCI1394_postedWriteErr |
+- OHCI1394_cycleTooLong | OHCI1394_cycle64Seconds)
++ OHCI1394_cycleTooLong | OHCI1394_cycle64Seconds |
++ OHCI1394_regAccessFail)
+ ? " ?" : "");
+ }
+
+@@ -1351,6 +1353,9 @@ static irqreturn_t irq_handler(int irq, void *data)
+ iso_event &= ~(1 << i);
+ }
+
++ if (unlikely(event & OHCI1394_regAccessFail))
++ fw_error("Register access failure\n");
++
+ if (unlikely(event & OHCI1394_postedWriteErr))
+ fw_error("PCI posted write error\n");
+
+@@ -1448,7 +1453,8 @@ static int ohci_enable(struct fw_card *card, u32 *config_rom, size_t length)
+ OHCI1394_reqTxComplete | OHCI1394_respTxComplete |
+ OHCI1394_isochRx | OHCI1394_isochTx |
+ OHCI1394_postedWriteErr | OHCI1394_cycleTooLong |
+- OHCI1394_cycle64Seconds | OHCI1394_masterIntEnable);
++ OHCI1394_cycle64Seconds | OHCI1394_regAccessFail |
++ OHCI1394_masterIntEnable);
+
+ /* Activate link_on bit and contender bit in our self ID packets.*/
+ if (ohci_update_phy_reg(card, 4, 0,
+diff --git a/drivers/firewire/fw-ohci.h b/drivers/firewire/fw-ohci.h
+index 5754c6e..a2fbb62 100644
+--- a/drivers/firewire/fw-ohci.h
++++ b/drivers/firewire/fw-ohci.h
+@@ -125,6 +125,7 @@
+ #define OHCI1394_lockRespErr 0x00000200
+ #define OHCI1394_selfIDComplete 0x00010000
+ #define OHCI1394_busReset 0x00020000
++#define OHCI1394_regAccessFail 0x00040000
+ #define OHCI1394_phy 0x00080000
+ #define OHCI1394_cycleSynch 0x00100000
+ #define OHCI1394_cycle64Seconds 0x00200000
+
+--
+Jarod Wilson
+jwilson at redhat.com
+
+
+firewire: fw-ohci: don't append to AT context when not active
+
+I finally tracked down the issues with this JMicron PCI-e card in my
+possession to a failure to comply with section 7.2.3.2 of the OHCI 1.1
+specification (thanks to Kristian for the pointer to illustrate that it is
+indeed a flaw in this card, not the driver). The controller should simply
+flush the packets we've appended to its AT queue if a bus reset occurs
+before they've been transmitted and we'll try again, but something goes wrong
+and the controller winds up hung.
+
+However, we can avoid the problem by simply checking if the IntEvent.busReset
+register had been set before we try appending to the AT context. When
+busReset is set, the AT context is completely halted until busReset is
+cleared, so there's no point in appending AT packets until the register
+is cleared. So at_context_queue_packet() now checks for busReset
+being set, and bails with an RCODE_GENERATION packet ack, which results in
+us trying to append the packet again after recognizing the fact there has
+been a bus reset, and clearing busReset.
+
+To go along with this change and to make it more obvious when this condition
+triggers, I've set the busReset bit in the IntMask and enabled logging it, but
+we still only actually take action and do our full bus reset handling
+routine triggered off of selfIDComplete.
+
+Signed-off-by: Jarod Wilson <jwilson at redhat.com>
+
+---
+
+ drivers/firewire/fw-ohci.c | 25 ++++++++++++++++++++++---
+ 1 files changed, 22 insertions(+), 3 deletions(-)
+
+diff --git a/drivers/firewire/fw-ohci.c b/drivers/firewire/fw-ohci.c
+index ad5accd..4bbc0a2 100644
+--- a/drivers/firewire/fw-ohci.c
++++ b/drivers/firewire/fw-ohci.c
+@@ -257,7 +257,8 @@ static void log_irqs(u32 evt)
+ if (likely(!(param_debug & OHCI_PARAM_DEBUG_IRQS)))
+ return;
+
+- printk(KERN_DEBUG KBUILD_MODNAME ": IRQ %08x%s%s%s%s%s%s%s%s%s%s%s%s\n",
++ printk(KERN_DEBUG KBUILD_MODNAME ": IRQ "
++ "%08x%s%s%s%s%s%s%s%s%s%s%s%s%s\n",
+ evt,
+ evt & OHCI1394_selfIDComplete ? " selfID" : "",
+ evt & OHCI1394_RQPkt ? " AR_req" : "",
+@@ -270,12 +271,13 @@ static void log_irqs(u32 evt)
+ evt & OHCI1394_cycleTooLong ? " cycleTooLong" : "",
+ evt & OHCI1394_cycle64Seconds ? " cycle64Seconds" : "",
+ evt & OHCI1394_regAccessFail ? " regAccessFail" : "",
++ evt & OHCI1394_busReset ? " busReset" : "",
+ evt & ~(OHCI1394_selfIDComplete | OHCI1394_RQPkt |
+ OHCI1394_RSPkt | OHCI1394_reqTxComplete |
+ OHCI1394_respTxComplete | OHCI1394_isochRx |
+ OHCI1394_isochTx | OHCI1394_postedWriteErr |
+ OHCI1394_cycleTooLong | OHCI1394_cycle64Seconds |
+- OHCI1394_regAccessFail)
++ OHCI1394_regAccessFail | OHCI1394_busReset)
+ ? " ?" : "");
+ }
+
+@@ -959,6 +961,23 @@ at_context_queue_packet(struct context *ctx, struct fw_packet *packet)
+ return -1;
+ }
+
++ /*
++ * If IntEvent.busReset is set, the AT context is halted, so appending
++ * to the context and trying to run it is futile. Most controllers do
++ * the right thing and just flush the AT queue (per section 7.2.3.2 of
++ * the OHCI 1.1 specification), but some controllers (like a JMicron
++ * PCI-e) misbehave and wind up stalling out. So we just bail out
++ * in software and try again later, and everyone is happy.
++ */
++ reg = reg_read(ohci, OHCI1394_IntEventClear);
++ if (reg & OHCI1394_busReset) {
++ if (packet->payload_length > 0)
++ dma_unmap_single(ohci->card.device, payload_bus,
++ packet->payload_length, DMA_TO_DEVICE);
++ packet->ack = RCODE_GENERATION;
++ return -1;
++ }
++
+ context_append(ctx, d, z, 4 - z);
+
+ /* If the context isn't already running, start it up. */
+@@ -1455,7 +1474,7 @@ static int ohci_enable(struct fw_card *card, u32 *config_rom, size_t length)
+ OHCI1394_isochRx | OHCI1394_isochTx |
+ OHCI1394_postedWriteErr | OHCI1394_cycleTooLong |
+ OHCI1394_cycle64Seconds | OHCI1394_regAccessFail |
+- OHCI1394_masterIntEnable);
++ OHCI1394_busReset | OHCI1394_masterIntEnable);
+
+ /* Activate link_on bit and contender bit in our self ID packets.*/
+ if (ohci_update_phy_reg(card, 4, 0,
More information about the scm-commits
mailing list