I've had this problem a while, and the history is documented in Fedora bug 471708. When I try to download digital video from my DV camera using FireWire I get dropped data. Not long after I get kernel oops or my computer locks up (its normally very stable).
I'm running Fedora 64 bit on a quad Core 2 machine. However another machine running 32 bit Ubuntu (dual P4) works fine. Both machines are using the same TSB43AB23 chip, so I suspect the problem is in the 64 bit compilation of the driver for that chip. Hence I'm posting the bug report here.
> Not long after I get kernel oops or my computer locks up
Acquire the panic message and attach it here.
> I'm running Fedora 64 bit on a quad Core 2 machine. However another machine
> running 32 bit Ubuntu (dual P4) works fine. Both machines are using the same
> TSB43AB23 chip,
Is ohci1394 or firewire-ohci running on the Ubuntu box?
Created attachment 22471 [details]
lsmod output from working Ubuntu box
This shows the Ubuntu box is running ohci1394.
Created attachment 22472 [details]
lspci output from the working Ubuntu box
Created attachment 22473 [details]
lsmod output from failing Fedora box
This shows that the Fedora box is running firewire-ohci.
Created attachment 22474 [details]
lspci output from the failing Fedora box
Sorry for catching up on this so late.
Would you be able to rebuild the Fedora kernel from source, and before that, patch it or edit the source code? We have a patch pending for mainline kernel 2.6.33-rc* which may get you rid of the crash as a side effect:
In somewhat older kernels, the affected source file is named drivers/firewire/fw-ohci.c instead of drivers/firewire/ohci.c and the surrounding code may differ. In any case, just remove the line
ohci->use_dualbuffer = version >= OHCI_VERSION_1_1;
which is unique in the driver source.
There is a guide how to customize Fedora kernels:
Another reporter of this issue found out for me that TSB43AB23 is affected by the same issue as TSB43AB22/A. We already have a workaround implemented for the latter. I am now waiting for either that reporter testing a 2.6.33 kernel, or for Paul to respond. (Paul, instead of my comment 6, you can also test a current kernel package from Rawhide which is now at a 2.6.33 pre-release version.)
The other report:
And the corresponding confirmation of the type of hardware bug:
Likely another report of this issue:
Another report, against Arch Linux 2.6.32 x86-64:
Reporter confirmed that mem=2G works around the issue:
Proposed patch: http://lkml.org/lkml/2010/1/26/284
Patch was merged in 220.127.116.11. Kernel 2.6.33 should have been immune already since 2.6.33-rc1. Please re-open the bug if I was wrong and the problem still exists in either 18.104.22.168 or later or 2.6.33-rc6 or later.