Bug 170923

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.