Red Hat Bugzilla – Bug 170923
ohci1394 causes unhandled interrupts
Last modified: 2015-01-04 17:22:38 EST
If I include a firewire driver in my initrd (in my case ohci1394), the kernel will boot up but then disable IRQ 11 due to unhandled interrupts. Unfortunately, IRQ 11 is shared between my USB, wireless, and firewire controllers (ohci1394 omitted for above stated reasons): [jbarnes@nietzche drivers]$ cat /proc/interrupts CPU0 0: 1709789 XT-PIC timer 1: 15205 XT-PIC i8042 2: 0 XT-PIC cascade 5: 0 XT-PIC Intel ICH6 Modem 8: 1 XT-PIC rtc 9: 47 XT-PIC acpi 10: 0 XT-PIC Intel ICH6, ehci_hcd:usb1, uhci_hcd:usb2 11: 200838 XT-PIC yenta, ipw2200, uhci_hcd:usb3, uhci_hcd:usb4, uhci_hcd:usb5, i915@pci:0000:00:02.0 12: 306053 XT-PIC i8042 14: 267688 XT-PIC ide0 15: 60415 XT-PIC ide1 which means that if I boot with an ohci1394 driver at all, nothing useful works. My guess is that this is an upstream problem as well, but I haven't tested yet (I'll do that now). My guess is that ohci1394 is somehow causing the firewire device to raise an interrupt line, but then never ack and disable it again, causing the kernel's irq debug feature to disable it. Thanks, Jesse
Confirmed that this also occurs with 2.6.14-rc2. I'm looking at the linux ieee1394 lists now to see if the problem has already been reported. If not, I'll report it to lkml and the ieee1394 list. Jesse
Tested a possible fix: http://marc.theaimsgroup.com/?t=112940299600001&r=1&w=2 The patch in the thread does seem to fix the problem, but doesn't seem like the ideal fix (adding driver options for specific machine models). I'll bring the patch to the attention of the PCI list.
did this get fixed upstream ?
My fix made it upstream, but it doesn't seem to work anymore. The rawhide kernel from yesterday still has the symptom I described in comment #1. I'm in the process of debugging it (I think I'm going crazy too, because the other patches that used to fix the problem don't seem to work anymore either). Hopefully I'll be able to get the fix upstream this weekend. Jesse
kernel-2.6.14-1.1642_FC5 still causes IRQ 11 to be disabled, as does 2.6.14-git2. However, the latest git (0bbacc402e67abca8794a8401c1621dc0c0202e9 is what I tested) works fine. I'll test again with rawhide later, maybe there was another PCI bug that prevented my PCI quirk from working (all the kernels listed here had my PCI quirk that *should* have fixed the problem). Jesse
kernel-2.6.14-1.1644_FC5 doesn't work either. I retested the git tree I have (same as comment #5) and things really do work under that kernel even with the ohci1394 driver loaded. Not sure what's going on... Jesse
Oops, forgot to mention in comment #6 that my git kernel was built with the config from kernel-2.6.14-1.1642_FC5.
Kernel 2.6.15 should contain the final fix.
(In reply to comment #8) > Kernel 2.6.15 should contain the final fix. I'm still having this problem, when trying to install FC5 test 2 from the DVD (kernel 2.6.15-1.1826.2.10_FC5), on a celeron+915 system. The firewire controller is an "Agere Sytems FW323 (rev 61)" (pci id 6010:1100). I can attach lspci/dmesg output if needed.
Sebastian, is your system a Toshiba laptop? What is the output of dmidecode?
Created attachment 124820 [details] dmidecode output for sumicom s630
It's not a laptop, it's a small-form-factor desktop PC - the Sumicom S630 (http://www.sumicom.com.tw/ - they don't have this model on their website yet).
Well, I don't know at all how it could be fixed for the Sumicon board. However if you are adventurous, you could try the same workaround like for Toshibas. You need at least Linux 2.6.15. Edit linux/arch/i386/pci/fixup.c. Add lines like { .ident = "Sumicon S630", /* small-form-factor PC */ .matches = { DMI_MATCH(DMI_BIOS_VENDOR, "Phoenix"), DMI_MATCH(DMI_BOARD_NAME, "Grantsdale"), }, }, to the toshiba_ohci1394_dmi_table and recompile the kernel. (Do this only if you already built kernels from source before.)
(In reply to comment #13) I didn't get a chance to try the patch, but with FC5-test3 (kernel 2.6.15-1.1955_FC5), the unhandled interrupts problem went away. I was able to install successfully, and connect a firewire disk. Thanks!
A new kernel update has been released (Version: 2.6.18-1.2200.fc5) based upon a new upstream kernel release. Please retest against this new kernel, as a large number of patches go into each upstream release, possibly including changes that may address this problem. This bug has been placed in NEEDINFO state. Due to the large volume of inactive bugs in bugzilla, if this bug is still in this state in two weeks time, it will be closed. Should this bug still be relevant after this period, the reporter can reopen the bug at any time. Any other users on the Cc: list of this bug can request that the bug be reopened by adding a comment to the bug. In the last few updates, some users upgrading from FC4->FC5 have reported that installing a kernel update has left their systems unbootable. If you have been affected by this problem please check you only have one version of device-mapper & lvm2 installed. See bug 207474 for further details. If this bug is a problem preventing you from installing the release this version is filed against, please see bug 169613. If this bug has been fixed, but you are now experiencing a different problem, please file a separate bug for the new problem. Thank you.
I still see my OHCI interrupt getting disabled occasionally (probably a race between the quirk being run, the number of interrupts coming in, and the driver being loaded) but things are working much better than when I initially reported this bug, and strictly speaking I think this bug is fixed though others remain.