Bug 797369
| Summary: | [abrt] kernel: WARNING: at lib/dma-debug.c:930 check_for_stack+0xb3/0xf0() | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Michael J. Ayers <ayersmj> | ||||||
| Component: | kernel | Assignee: | Stanislaw Gruszka <sgruszka> | ||||||
| Status: | CLOSED UPSTREAM | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||
| Severity: | unspecified | Docs Contact: | |||||||
| Priority: | unspecified | ||||||||
| Version: | 18 | CC: | contact, danstiner, dcharlespyle, gansalmon, gokcen.eraslan, itamar, jonathan, kernel-maint, korsnick, madhu.chinakonda, michele, sgruszka | ||||||
| Target Milestone: | --- | Keywords: | Reopened | ||||||
| Target Release: | --- | ||||||||
| Hardware: | x86_64 | ||||||||
| OS: | Unspecified | ||||||||
| Whiteboard: | abrt_hash:333e2a0985cb3a590febc8916c2b1b7120c46633 | ||||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||||
| Doc Text: | Story Points: | --- | |||||||
| Clone Of: | Environment: | ||||||||
| Last Closed: | 2013-04-30 11:11:59 UTC | Type: | --- | ||||||
| Regression: | --- | Mount Type: | --- | ||||||
| Documentation: | --- | CRM: | |||||||
| Verified Versions: | Category: | --- | |||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||
| Embargoed: | |||||||||
| Attachments: |
|
||||||||
|
Description
Michael J. Ayers
2012-02-25 08:32:05 UTC
This is not a bug, just false positive warning form DMA API checker. it might be a false positive, but we afaik have no way of annotating it so that the checker doesn't trigger. We're going to keep getting reports of this until something is changed. Ok, so let's open it for now. I'm not sure how to fix that. Changing driver seems to be odd since this is false positive. Perhaps some DMA checker changed should be done. Installed from Fedora 17 Aplha DVD. Ran yum update, and rebooted. Also got the saem error on the kernel installed from the alpha DVD. Package: kernel OS Release: Fedora release 17 (Beefy Miracle) *** Bug 799731 has been marked as a duplicate of this bug. *** I have connected Logitech Wireless Touchpad (using 046d:c52b Logitech, Inc. Unifying Receiver) and restarted the machine. Touchpad isn't working but hid_logitech_dj module is loaded. This bug may be a duplicate of bug #797319. Package: kernel OS Release: Fedora release 17 (Beefy Miracle) Aaah, ignore my comment. Touchpad started working now :) I don't know why it didn't work a while ago. I have been having those same issues. Sometimes when I boot, my logitech mouse isn't working, sometimes it is. However, after the update to kernel 3.3.0-0.rc6.git0.2.fc17.x86_64, I no longer see the error on this bug, but it is now replaced by something worse :( First part of boot process goes ok until this: Mar 7 14:54:49 tower20 kernel: [ 0.653512] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver Mar 7 14:54:49 tower20 kernel: [ 0.653611] ehci_hcd 0000:00:1d.7: EHCI Host Controller Mar 7 14:54:49 tower20 kernel: [ 0.653714] ehci_hcd 0000:00:1d.7: new USB bus registered, assigned bus number 1 Mar 7 14:54:49 tower20 kernel: [ 0.653820] ehci_hcd 0000:00:1d.7: using broken periodic workaround Mar 7 14:54:49 tower20 kernel: [ 0.653886] ehci_hcd 0000:00:1d.7: debug port 1 Mar 7 14:54:49 tower20 kernel: [ 0.657828] ehci_hcd 0000:00:1d.7: irq 23, io mem 0xfea77c00 Mar 7 14:54:49 tower20 kernel: [ 0.663028] ehci_hcd 0000:00:1d.7: USB 2.0 started, EHCI 1.00 Mar 7 14:54:49 tower20 kernel: [ 0.663143] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002 Mar 7 14:54:49 tower20 kernel: [ 0.663218] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1 Mar 7 14:54:49 tower20 kernel: [ 0.663223] Disabling IRQ 23 Mar 7 14:54:49 tower20 kernel: [ 0.663364] usb usb1: Product: EHCI Host Controller Mar 7 14:54:49 tower20 kernel: [ 0.663421] usb usb1: Manufacturer: Linux 3.3.0-0.rc6.git0.2.fc17.x86_64 ehci_hcd Mar 7 14:54:49 tower20 kernel: [ 0.663510] usb usb1: SerialNumber: 0000:00:1d.7 Then constantly, I get errors thrown to the logfile: Mar 7 15:13:06 tower20 kernel: [ 1123.005161] Disabling IRQ 23 Mar 7 15:13:06 tower20 kernel: [ 1123.015037] Polling IRQ 23 Mar 7 15:13:07 tower20 kernel: [ 1124.015040] Reenabling IRQ 23 Mar 7 15:13:07 tower20 kernel: [ 1124.025672] Disabling IRQ 23 Mar 7 15:13:07 tower20 kernel: [ 1124.035070] Polling IRQ 23 Mar 7 15:13:08 tower20 kernel: [ 1125.035042] Reenabling IRQ 23 Mar 7 15:13:08 tower20 kernel: [ 1125.089627] Disabling IRQ 23 Mar 7 15:13:08 tower20 kernel: [ 1125.099037] Polling IRQ 23 Mar 7 15:13:09 tower20 kernel: [ 1126.099024] Reenabling IRQ 23 Mar 7 15:13:09 tower20 kernel: [ 1126.143586] Disabling IRQ 23 Mar 7 15:13:09 tower20 kernel: [ 1126.153038] Polling IRQ 23 Mar 7 15:13:10 tower20 kernel: [ 1127.153058] Reenabling IRQ 23 Mar 7 15:13:10 tower20 kernel: [ 1127.159553] Disabling IRQ 23 Mar 7 15:13:10 tower20 kernel: [ 1127.169022] Polling IRQ 23 Mar 7 15:13:11 tower20 kernel: [ 1128.169026] Reenabling IRQ 23 Mar 7 15:13:12 tower20 kernel: [ 1128.183501] Disabling IRQ 23 Mar 7 15:13:12 tower20 kernel: [ 1128.193036] Polling IRQ 23 That amounts to 3 messages per second written to the logfile for however long the system is running. Won't take very long to eat up a lot of disk space. I got no error like this on the previous kernel. Tried to hibernate and got a kernel panic. After a hard shutdown I booted the system and had to repair the root filesystem : fsck.ext4 -y /dev/vg_thinkpad/lv_root Then Logged in on my usual desktop and get that ABRT warning. Package: kernel OS Release: Fedora release 16 (Verne) Got error upon boot. Happens on every boot. Package: kernel OS Release: Fedora release 17 (Beefy Miracle) Still occurring on the 3.3.0-0.rc7.git0.3.fc17.x86_64 kernel. WARNING: at lib/dma-debug.c:930 check_for_stack+0xa9/0xf0() Hardware name: MS-7529 uhci_hcd 0000:00:1d.0: DMA-API: device driver maps memory fromstack [addr=ffff880121b1bc01] Modules linked in: hid_logitech_dj(+) Pid: 107, comm: udevd Not tainted 3.3.0-0.rc5.git3.1.fc17.x86_64 #1 Call Trace: [<ffffffff81060d6f>] warn_slowpath_common+0x7f/0xc0 [<ffffffff81060e66>] warn_slowpath_fmt+0x46/0x50 [<ffffffff8133ef89>] check_for_stack+0xa9/0xf0 [<ffffffff8133f6da>] debug_dma_map_page+0xea/0x150 [<ffffffff8148754b>] usb_hcd_map_urb_for_dma+0x54b/0x5d0 [<ffffffff810285df>] ? save_stack_trace+0x2f/0x50 [<ffffffff8148785d>] usb_hcd_submit_urb+0x28d/0x870 [<ffffffff81488ad0>] usb_submit_urb+0xf0/0x3b0 [<ffffffff81489dd2>] usb_start_wait_urb+0x82/0x1a0 [<ffffffff81488efe>] ? usb_alloc_urb+0x1e/0x50 [<ffffffff8148a15e>] usb_control_msg+0xde/0x140 [<ffffffff81235712>] ? sysfs_add_file+0x12/0x20 [<ffffffff8152c712>] usbhid_output_raw_report+0xd2/0x100 [<ffffffffa0000661>] logi_dj_recv_send_report.isra.7+0x21/0x50 [hid_logitech_dj] [<ffffffffa00006e1>] logi_dj_recv_switch_to_dj_mode.constprop.13+0x51/0x70 [hid_logitech_dj] [<ffffffffa0001268>] logi_dj_probe+0x238/0x3dc [hid_logitech_dj] [<ffffffff8169dc9b>] ? _raw_spin_unlock+0x2b/0x50 [<ffffffff81522b8d>] hid_device_probe+0xbd/0x140 [<ffffffff81412236>] driver_probe_device+0x96/0x2f0 [<ffffffff8141253b>] __driver_attach+0xab/0xb0 [<ffffffff81412490>] ? driver_probe_device+0x2f0/0x2f0 [<ffffffff81410435>] bus_for_each_dev+0x55/0x90 [<ffffffffa0006000>] ? 0xffffffffa0005fff [<ffffffff81411d1e>] driver_attach+0x1e/0x20 [<ffffffff81411a28>] bus_add_driver+0x1b8/0x2b0 [<ffffffffa0006000>] ? 0xffffffffa0005fff [<ffffffff81412d17>] driver_register+0x77/0x160 [<ffffffffa0006000>] ? 0xffffffffa0005fff [<ffffffff8151ff56>] __hid_register_driver+0x66/0xa0 [<ffffffffa0006047>] logi_dj_init+0x47/0x1000 [hid_logitech_dj] [<ffffffff8100212a>] do_one_initcall+0x12a/0x180 [<ffffffff810dad26>] sys_init_module+0x1146/0x2260 [<ffffffff816a68e9>] system_call_fastpath+0x16/0x1b PLUS: I get the constant messages thrown to /var/log/messages Mar 14 03:59:55 tower20 kernel: [ 430.220025] Reenabling IRQ 23 Mar 14 04:00:13 tower20 kernel: [ 448.409026] Disabling IRQ 23 Mar 14 04:00:13 tower20 kernel: [ 448.419029] Polling IRQ 23 Mar 14 04:00:14 tower20 kernel: [ 449.493020] Reenabling IRQ 23 Mar 14 04:01:02 tower20 kernel: [ 497.333591] Disabling IRQ 23 Mar 14 04:01:02 tower20 kernel: [ 497.343030] Polling IRQ 23 Mar 14 04:01:03 tower20 kernel: [ 498.413018] Reenabling IRQ 23 Mar 14 04:01:11 tower20 kernel: [ 506.317263] Disabling IRQ 23 Mar 14 04:01:11 tower20 kernel: [ 506.327035] Polling IRQ 23 Mar 14 04:01:12 tower20 kernel: [ 507.376038] Reenabling IRQ 23 Mar 14 04:01:17 tower20 kernel: [ 512.202094] Disabling IRQ 23 Mar 14 04:01:17 tower20 kernel: [ 512.212027] Polling IRQ 23 Mar 14 04:01:18 tower20 kernel: [ 513.232027] Reenabling IRQ 23 Mar 14 04:01:34 tower20 kernel: [ 529.454944] Disabling IRQ 23 Mar 14 04:01:34 tower20 kernel: [ 529.464038] Polling IRQ 23 Mar 14 04:01:35 tower20 kernel: [ 530.465030] Reenabling IRQ 23 Mar 14 04:02:16 tower20 kernel: [ 571.205184] Disabling IRQ 23 Mar 14 04:02:16 tower20 kernel: [ 571.215025] Polling IRQ 23 Mar 14 04:02:17 tower20 kernel: [ 572.274021] Reenabling IRQ 23 Mar 14 04:02:22 tower20 kernel: [ 577.204604] Disabling IRQ 23 Mar 14 04:02:22 tower20 kernel: [ 577.214033] Polling IRQ 23 This is making the 3.3 kernels newer than rc5 completely unusable for me. backtrace above was for the wrong kernel version. backtrace for 3.3.0-0.rc7.git0.3.fc17.x86_64: WARNING: at lib/dma-debug.c:930 check_for_stack+0xa9/0xf0() Hardware name: MS-7529 uhci_hcd 0000:00:1d.0: DMA-API: device driver maps memory fromstack [addr=ffff8801215fdc01] Modules linked in: hid_logitech_dj(+) i915(+) video i2c_algo_bit drm_kms_helper drm i2c_core Pid: 113, comm: udevd Not tainted 3.3.0-0.rc7.git0.3.fc17.x86_64 #1 Call Trace: [<ffffffff81060dff>] warn_slowpath_common+0x7f/0xc0 [<ffffffff81060ef6>] warn_slowpath_fmt+0x46/0x50 [<ffffffff8133efa9>] check_for_stack+0xa9/0xf0 [<ffffffff8133f6fa>] debug_dma_map_page+0xea/0x150 [<ffffffff8148758b>] usb_hcd_map_urb_for_dma+0x54b/0x5d0 [<ffffffff810284ff>] ? save_stack_trace+0x2f/0x50 [<ffffffff8148789d>] usb_hcd_submit_urb+0x28d/0x870 [<ffffffff81488b10>] usb_submit_urb+0xf0/0x3b0 [<ffffffff81489e12>] usb_start_wait_urb+0x82/0x1a0 [<ffffffff81488f3e>] ? usb_alloc_urb+0x1e/0x50 [<ffffffff8148a19e>] usb_control_msg+0xde/0x140 [<ffffffff812357f2>] ? sysfs_add_file+0x12/0x20 [<ffffffff8152c7d2>] usbhid_output_raw_report+0xd2/0x100 [<ffffffffa0054661>] logi_dj_recv_send_report.isra.7+0x21/0x50 [hid_logitech_dj] [<ffffffffa00546e1>] logi_dj_recv_switch_to_dj_mode.constprop.13+0x51/0x70 [hid_logitech_dj] [<ffffffffa0055268>] logi_dj_probe+0x238/0x3dc [hid_logitech_dj] [<ffffffff8169df1b>] ? _raw_spin_unlock+0x2b/0x50 [<ffffffff81522c4d>] hid_device_probe+0xbd/0x140 [<ffffffff81412236>] driver_probe_device+0x96/0x2f0 [<ffffffff8141253b>] __driver_attach+0xab/0xb0 [<ffffffff81412490>] ? driver_probe_device+0x2f0/0x2f0 [<ffffffff81410435>] bus_for_each_dev+0x55/0x90 [<ffffffffa005a000>] ? 0xffffffffa0059fff [<ffffffff81411d1e>] driver_attach+0x1e/0x20 [<ffffffff81411a28>] bus_add_driver+0x1b8/0x2b0 [<ffffffffa005a000>] ? 0xffffffffa0059fff [<ffffffff81412d17>] driver_register+0x77/0x160 [<ffffffffa005a000>] ? 0xffffffffa0059fff [<ffffffff81520016>] __hid_register_driver+0x66/0xa0 [<ffffffffa005a047>] logi_dj_init+0x47/0x1000 [hid_logitech_dj] [<ffffffff8100212a>] do_one_initcall+0x12a/0x180 [<ffffffff810dabd6>] sys_init_module+0x1146/0x2260 [<ffffffff816a6b69>] system_call_fastpath+0x16/0x1b Updated to the 3.3.0-1.fc17.x86_64 kernel and so far it appears that it fixes my issues :) (In reply to comment #13) > Updated to the 3.3.0-1.fc17.x86_64 kernel and so far it appears that it fixes > my issues :) Not really. It just masks it because we turned off the debugging options that printk the backtrace. Unless you meant the IRQ thing in comment #11. That should indeed be fixed. yes, I did mean the IRQ thing in comment 11 (sorry, I should have been specific since there were 2 issues here), that was what was making it unusable for me here. [mass update] kernel-3.3.0-4.fc16 has been pushed to the Fedora 16 stable repository. Please retest with this update. [mass update] kernel-3.3.0-4.fc16 has been pushed to the Fedora 16 stable repository. Please retest with this update. [mass update] kernel-3.3.0-4.fc16 has been pushed to the Fedora 16 stable repository. Please retest with this update. Created attachment 915497 [details]
Comment
(This comment was longer than 65,535 characters and has been moved to an attachment by Red Hat Bugzilla).
Created attachment 915498 [details]
Comment
(This comment was longer than 65,535 characters and has been moved to an attachment by Red Hat Bugzilla).
Still occurring on 3.7.0-2 kernel. Still occurring on 3.7.0-6 kernel on Fedora 18. This message is a reminder that Fedora 16 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 16. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '16'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 16's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 16 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged to click on "Clone This Bug" and open it against that version of Fedora. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping logi_dj_recv_send_report issue originally reported here is fixed by:
commit d8dc3494f77a5cc3b274bae36f7e74e85cf8a407
Author: Marc Dionne <marc.c.dionne>
Date: Fri Jun 1 18:12:14 2012 -0400
HID: logitech: don't use stack based dj_report structures
Issue from comment 19 is a different problem, to solve it require good usb storage knowledge, which we (fedora maintainers) do not have. Please retest with current upstream and fill bug there (linux-usb.org,
usb-storage.net) if problem still occurs.
|