abrt version: 2.0.5 cmdline: BOOT_IMAGE=/vmlinuz-3.0.0-3.fc16.i686.PAE root=/dev/mapper/VolGroup-lv_root32 ro nomodeset kernel: undefined kernel_tainted: 512 kernel_tainted_long: Taint on warning. reason: WARNING: at lib/dma-debug.c:800 check_unmap+0x9c/0x67f() time: Thu Aug 4 11:51:49 2011 backtrace: :WARNING: at lib/dma-debug.c:800 check_unmap+0x9c/0x67f() :firewire_ohci 0000:05:00.0: DMA-API: device driver tries to free an invalid DMA memory address :Modules linked in: firewire_ohci(+) firewire_core crc_itu_t radeon ttm drm_kms_helper drm i2c_algo_bit i2c_core :Pid: 211, comm: modprobe Not tainted 3.0.0-1.fc16.i686.PAE #1 :Call Trace: : [<c04463d4>] warn_slowpath_common+0x7c/0x91 : [<c05fcc3a>] ? check_unmap+0x9c/0x67f : [<c05fcc3a>] ? check_unmap+0x9c/0x67f : [<c0446474>] warn_slowpath_fmt+0x33/0x35 : [<c05fcc3a>] check_unmap+0x9c/0x67f : [<c05eeb64>] ? trace_hardirqs_on_thunk+0xc/0x10 : [<c05eeb74>] ? trace_hardirqs_off_thunk+0xc/0x10 : [<c084f37d>] ? restore_all+0xf/0xf : [<c04400d8>] ? rt_mutex_setprio+0xb2/0xf6 : [<c04464a1>] ? arch_local_irq_restore+0x5/0xb : [<c05fd279>] debug_dma_free_coherent+0x5c/0x64 : [<f7a755ee>] dma_free_coherent+0x6a/0x8f [firewire_ohci] : [<f7a77c9e>] ohci_enable+0x3c2/0x439 [firewire_ohci] : [<f7a4d7c4>] fw_card_add+0x45/0x71 [firewire_core] : [<f7a78e8d>] pci_probe+0x377/0x4a1 [firewire_ohci] : [<c084f0b5>] ? _raw_spin_unlock_irqrestore+0x44/0x48 : [<c0605d78>] pci_device_probe+0x62/0xab : [<c06a834e>] driver_probe_device+0x129/0x208 : [<c084dc14>] ? mutex_lock_nested+0x43/0x49 : [<c06a847c>] __driver_attach+0x4f/0x6b : [<c06a753f>] bus_for_each_dev+0x42/0x6b : [<c06a7f81>] driver_attach+0x1f/0x23 : [<c06a842d>] ? driver_probe_device+0x208/0x208 : [<c06a7c07>] bus_add_driver+0xcd/0x214 : [<c06a88c2>] driver_register+0x84/0xe3 : [<c05f2deb>] ? __raw_spin_lock_init+0x2d/0x4e : [<c06064f0>] __pci_register_driver+0x4f/0xab : [<f7a39000>] ? 0xf7a38fff : [<f7a39000>] ? 0xf7a38fff : [<f7a39017>] fw_ohci_init+0x17/0x1000 [firewire_ohci] : [<c04030a2>] do_one_initcall+0x8c/0x146 : [<c04296cf>] ? set_memory_nx+0x38/0x3a : [<f7a39000>] ? 0xf7a38fff : [<f7a39000>] ? 0xf7a38fff : [<c047cea1>] sys_init_module+0x14b9/0x16dd : [<c085521f>] sysenter_do_call+0x12/0x38 comment: :Booting an iMac from 64 bit EFI to 32 bit kernel 3.0.0-3.fc16.i686.PAE : :This happens while booting. : :(Machine is working through ssh, graphic works with nomodeset and fbdev, USB is completely dead.) smolt_data: :Traceback (most recent call last): : File "/usr/bin/smoltSendProfile", line 152, in <module> : profile = smolt.get_profile() : File "/usr/share/smolt/client/smolt.py", line 1415, in get_profile : return Hardware() : File "/usr/share/smolt/client/smolt.py", line 1004, in Hardware : _hardware_instance = _Hardware() : File "/usr/share/smolt/client/smolt.py", line 591, in __init__ : self.host = Host() : File "/usr/share/smolt/client/smolt.py", line 283, in __init__ : self.systemMemory = Gate().process('ram_size', memory['ram'], 0) :TypeError: 'NoneType' object is not subscriptable
Created attachment 516684 [details] dmesg
http://www.smolts.org/client/show/pub_866c4689-bf0e-4508-a518-6d90d7cc5486 (slightly hacked to work around smolt client dmi bugs)
I don't know how much you can/will support systems running 32 bit kernel from 64 bit EFI, but if it isn't supported it should issue a huge warning and perhaps halt. There is however also indications of memory issues in pure 32 bit EFI on bug 728531 .
The attached dmesg shows a much more complete picture than the bug description. The failure begins with: [ 3.749072] firewire_ohci 0000:05:00.0: can't find IRQ for PCI INT A; please try using pci=biosirq ... [ 3.906311] firewire_ohci: Failed to allocate interrupt 0. Yes indeed, interrupt line 0 is not for device drivers. After that comes the dma-debug check_unmap warning, which is due to wrang call arguments in an error handling path. (Evidently that path was never executed on my own PCs on which I always have dma-debug enabled). I posted a fix for this secondary issue: http://marc.info/?l=linux1394-devel&m=131308808508858 After that, there is an IRQ binding failure in ath9k in your dmesg. And before it are several IRQ binding failures in ehci_hcd, which explains why your USB does not work. ("Found HC with no IRQ.") I have not scrolled further up in the dmesg to check whether the early initialization messages reveal something interesting about your machine. As a FireWire guy I don't understand those anyway.
Stefan: Would it be relevant to try pci=biosirq? Would that be a way to get some useful information or would it be an acceptable "solution"?
I don't know about these things. Here http://www.rodsbooks.com/ubuntu-efi/index.html someone says that 32 bit OSs may be unable to access EFI runtime services of a 64 bit EFI. So if that's right, you have to do whatever is necessary to run without needing to rely on EFI runtime services. Whatever that is.
There is a kernel command line option, noefi, "Disable EFI runtime services support." I don't know if that is in any way related to your IRQ routing (?) issues.
Ok, taking one step back and reading what you said again and summing it up: The topic for this bug is the Call Trace. You say it was caused by a bug in the error handling. You have fixed it and eventually it will show up in "my" kernel. Another interesting question (for me) is why I ended up with an error that needed handling. Thanks for the hints even though it is out of scope. If there are any kernel bugs involved in that then it would be a different issue. So I guess that's it. Thanks!
It's only generating this when it fails to get an interrupt when initializing firewire. This is fixed upstream and probably not worth backporting.
Is this interrupt fix in 3.1?
The "secondary" issue (DMA unmapping bug in firewire-ohci in a failure path, i.e. the issue in the title of this bug tracker entry) is fixed in Linus' current tree: http://git.kernel.org/linus/a01e836087881dd9d824417190994c9b2b0f1dbb The first tagged release which will contain this commit is going to be 3.1-rc3. The "primary" issue (no interrupt lines associated with your USB, FireWire, and WLAN chips) is not addressed by that fix. The two issues are totally separate, apart from the circumstance that the occurrence of the primary one made the secondary one visible to us.