Bug 728185 - [abrt] WARNING: at lib/dma-debug.c:800 check_unmap+0x9c/0x67f() [firewire_ohci]
[abrt] WARNING: at lib/dma-debug.c:800 check_unmap+0x9c/0x67f() [firewire_ohci]
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
16
i686 Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Jay Fenlason
Fedora Extras Quality Assurance
abrt_hash:6cd385267229bbc9c902542d221...
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2011-08-04 06:19 EDT by Mads Kiilerich
Modified: 2014-08-31 19:30 EDT (History)
8 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2011-08-17 01:51:21 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
dmesg (54.86 KB, text/plain)
2011-08-04 06:54 EDT, Mads Kiilerich
no flags Details

  None (edit)
Description Mads Kiilerich 2011-08-04 06:19:58 EDT
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
Comment 1 Mads Kiilerich 2011-08-04 06:54:53 EDT
Created attachment 516684 [details]
dmesg
Comment 2 Mads Kiilerich 2011-08-04 06:55:45 EDT
http://www.smolts.org/client/show/pub_866c4689-bf0e-4508-a518-6d90d7cc5486 (slightly hacked to work around smolt client dmi bugs)
Comment 3 Mads Kiilerich 2011-08-10 10:11:00 EDT
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 .
Comment 4 Stefan Richter 2011-08-11 14:51:44 EDT
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.
Comment 5 Mads Kiilerich 2011-08-11 15:01:58 EDT
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"?
Comment 6 Stefan Richter 2011-08-11 17:10:45 EDT
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.
Comment 7 Stefan Richter 2011-08-11 17:23:39 EDT
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.
Comment 8 Mads Kiilerich 2011-08-11 17:38:01 EDT
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!
Comment 9 Chuck Ebbert 2011-08-17 01:51:21 EDT
It's only generating this when it fails to get an interrupt when initializing firewire. This is fixed upstream and probably not worth backporting.
Comment 10 Mads Kiilerich 2011-08-17 03:37:41 EDT
Is this interrupt fix in 3.1?
Comment 11 Stefan Richter 2011-08-17 14:25:51 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.