Bug 728194 - abrt doesn't recognize some kernel 'Call Trace's
Summary: abrt doesn't recognize some kernel 'Call Trace's
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: abrt
Version: 16
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Denys Vlasenko
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: 745436
TreeView+ depends on / blocked
 
Reported: 2011-08-04 10:59 UTC by Mads Kiilerich
Modified: 2011-11-21 22:51 UTC (History)
7 users (show)

Fixed In Version: abrt-2.0.6-1.fc16
Clone Of:
: 745436 (view as bug list)
Environment:
Last Closed: 2011-11-21 22:51:16 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
dmesg (54.86 KB, text/plain)
2011-08-04 11:39 UTC, Mads Kiilerich
no flags Details
another dmesg (100.12 KB, text/plain)
2011-08-08 11:32 UTC, Mads Kiilerich
no flags Details

Description Mads Kiilerich 2011-08-04 10:59:07 UTC
abrt doesn't offer to report some of stack traces in the attacked dmesg. That is probably because they don't have the expected 'cut here' headers.

abrt-addon-kerneloops-2.0.4-1.fc16.i686

Comment 1 Jiri Moskovcak 2011-08-04 11:26:22 UTC
Can you please attach the dmesg output with the not-detected oops?

Comment 2 Mads Kiilerich 2011-08-04 11:39:59 UTC
Created attachment 516689 [details]
dmesg

Comment 3 Mads Kiilerich 2011-08-08 11:32:36 UTC
Created attachment 517180 [details]
another dmesg

Another one:

[    7.966658] irq 17: nobody cared (try booting with the "irqpoll" option)
[    7.966699] Pid: 151, comm: usb-storage Not tainted 3.0.0-3.fc16.x86_64 #1
[    7.966735] Call Trace:
[    7.966749]  <IRQ>  [<ffffffff810bef8a>] __report_bad_irq+0x37/0xc4
[    7.966790]  [<ffffffff810bf22d>] note_interrupt+0x179/0x1fc
[    7.966820]  [<ffffffff810bd736>] handle_irq_event_percpu+0x15d/0x1bc
[    7.966854]  [<ffffffff810bd7dc>] handle_irq_event+0x47/0x67
[    7.968321]  [<ffffffff814ddc74>] ? _raw_spin_lock+0x62/0x6a
[    7.969769]  [<ffffffff810bf9a3>] ? handle_fasteoi_irq+0x1e/0xad
[    7.971212]  [<ffffffff810bfa0c>] handle_fasteoi_irq+0x87/0xad
[    7.972651]  [<ffffffff8100ab60>] handle_irq+0x8b/0x91
[    7.974078]  [<ffffffff814e6b3d>] do_IRQ+0x4d/0xa5
[    7.975493]  [<ffffffff814de7d3>] common_interrupt+0x13/0x13
[    7.976897]  [<ffffffff81091106>] ? arch_local_irq_restore+0x6/0xd
[    7.978296]  [<ffffffff814de490>] ? _raw_spin_unlock_irqrestore+0x4d/0x52
[    7.979698]  [<ffffffff813222af>] ? scsi_run_queue+0x25d/0x274
[    7.981095]  [<ffffffff813233e5>] ? scsi_next_command+0x38/0x48
[    7.982473]  [<ffffffff813238a6>] ? scsi_io_completion+0x45d/0x4d7
[    7.983842]  [<ffffffff8131ba58>] ? scsi_finish_command+0xe4/0xed
[    7.985206]  [<ffffffff8132338d>] ? scsi_softirq_done+0x109/0x112
[    7.986566]  [<ffffffff8122be8f>] ? blk_done_softirq+0x79/0x8d
[    7.987915]  [<ffffffff8105f1a8>] ? __do_softirq+0xdb/0x1ec
[    7.989285]  [<ffffffff8108aafa>] ? lock_release+0x173/0x19c
[    7.989288]  [<ffffffff8100e9fd>] ? paravirt_read_tsc+0x9/0xd
[    7.989290]  [<ffffffff814e62dc>] ? call_softirq+0x1c/0x30
[    7.989292]  [<ffffffff8100abb1>] ? do_softirq+0x4b/0xa2
[    7.989305]  [<ffffffff8105f4c9>] ? irq_exit+0x5d/0xc0
[    7.989307]  [<ffffffff814e6b7e>] ? do_IRQ+0x8e/0xa5
[    7.989309]  [<ffffffff814de7d3>] ? common_interrupt+0x13/0x13
[    7.989310]  <EOI>  [<ffffffff81091122>] ? arch_local_irq_enable+0x8/0xd
[    7.989314]  [<ffffffff814de43f>] ? _raw_spin_unlock_irq+0x32/0x36
[    7.989320]  [<ffffffffa0052e96>] ? usb_stor_control_thread+0x1cd/0x237 [usb_storage]
[    7.989323]  [<ffffffffa0052cc9>] ? fill_inquiry_response+0xf3/0xf3 [usb_storage]
[    7.989326]  [<ffffffff81075e19>] ? kthread+0xa8/0xb0
[    7.989328]  [<ffffffff814e61e4>] ? kernel_thread_helper+0x4/0x10
[    7.989331]  [<ffffffff814de894>] ? retint_restore_args+0x13/0x13
[    7.989333]  [<ffffffff81075d71>] ? __init_kthread_worker+0x5a/0x5a
[    7.989335]  [<ffffffff814e61e0>] ? gs_change+0x13/0x13
[    7.989337] handlers:
[    7.989339] [<ffffffffa00ce036>] sdhci_irq
[    7.989341] Disabling IRQ #17

Comment 4 Denys Vlasenko 2011-10-11 19:43:56 UTC
Fixed in git:

commit 29b3f9e23f90ea3ea92b2d845864d60052ca4081
Author: Denys Vlasenko <dvlasenk>
Date:   Tue Oct 11 21:41:30 2011 +0200

    abrt-dump-oops: add checks for "irq NN: nobody cared" and "IRQ handler type mismatch"

    This closes rhbz#728194.
    Also, increase oops size limit from 60 to 80 lines - closes rhbz#728314

Comment 5 Mads Kiilerich 2011-10-11 19:54:04 UTC
Thanks for posting the reference to the fix. That helps to educate the bug reporter and will hopefully improve the qualities of the reports you receive.

For better or worse, it also makes it possible for me to add an additional comment:

Wouldn't it be possible for you to push the kernel team towards consistently using some kind of more structured reporting of "Call Traces" with begin/end markers? That would ensure that you are ready for the rare and unexpected bug too.

Comment 6 Fedora Update System 2011-11-05 18:57:51 UTC
abrt-2.0.6-1.fc16 has been submitted as an update for Fedora 16.
https://admin.fedoraproject.org/updates/abrt-2.0.6-1.fc16

Comment 7 Fedora Update System 2011-11-06 23:55:22 UTC
Package abrt-2.0.6-1.fc16:
* should fix your issue,
* was pushed to the Fedora 16 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing abrt-2.0.6-1.fc16'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2011-15513
then log in and leave karma (feedback).

Comment 8 Fedora Update System 2011-11-21 22:51:16 UTC
abrt-2.0.6-1.fc16 has been pushed to the Fedora 16 stable repository.  If problems still persist, please make note of it in this bug report.


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