Bug 449302 - __report_bad_irq during boot
__report_bad_irq during boot
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
12
i686 Linux
low Severity high
: ---
: ---
Assigned To: Stanislaw Gruszka
Fedora Extras Quality Assurance
: Reopened
: 512347 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-06-01 20:45 EDT by William Lovaton
Modified: 2010-04-27 16:44 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 512347 (view as bug list)
Environment:
Last Closed: 2010-04-27 16:32:26 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 output (45.11 KB, text/plain)
2010-03-28 14:02 EDT, William Lovaton
no flags Details
syslog with debugging info from new kernel (72.68 KB, text/plain)
2010-04-21 21:35 EDT, William Lovaton
no flags Details

  None (edit)
Description William Lovaton 2008-06-01 20:45:35 EDT
Description of problem:
I'm not really sure if this is kernel related but it gets logged in syslog
during boot as a kernel thing:

localhost kernel: SCSI subsystem initialized
localhost kernel: Driver 'sd' needs updating - please use bus_type methods
localhost kernel: ACPI: PCI Interrupt 0000:00:1f.2[C] -> GSI 20 (level, low) ->
IRQ 20
localhost kernel: hub 2-0:1.0: unable to enumerate USB device on port 3
localhost kernel: hub 2-0:1.0: unable to enumerate USB device on port 4
localhost kernel: irq 18: nobody cared (try booting with the "irqpoll" option)
localhost kernel: Pid: 425, comm: nash-hotplug Not tainted 2.6.25.3-18.fc9.i686 #1
localhost kernel:  [__report_bad_irq+46/111] __report_bad_irq+0x2e/0x6f
localhost kernel:  [note_interrupt+450/539] note_interrupt+0x1c2/0x21b
localhost kernel:  [handle_IRQ_event+42/90] ? handle_IRQ_event+0x2a/0x5a
localhost kernel:  [handle_fasteoi_irq+143/175] handle_fasteoi_irq+0x8f/0xaf
localhost kernel:  [handle_fasteoi_irq+0/175] ? handle_fasteoi_irq+0x0/0xaf
localhost kernel:  [do_IRQ+152/196] do_IRQ+0x98/0xc4
localhost kernel:  [common_interrupt+35/40] common_interrupt+0x23/0x28
localhost kernel:  [system_call+0/59] ? system_call+0x0/0x3b
localhost kernel:  =======================
localhost kernel: handlers:
localhost kernel: [usb_hcd_irq+0/87] (usb_hcd_irq+0x0/0x57)
localhost kernel: Disabling IRQ #18
localhost kernel: usb 2-5: new high speed USB device using ehci_hcd and address 5

This is from a Dell XPS 420 system with an Intel Core 2 Quad CPU at 2.4 GHz.

The system seems to runs fine afterwards and I don't see any anomaly AFAICT.  I
was just wondering what was it? is it a known problem?

I see nash-hotplug as the one triggering this bug.  What is that? I see it on my
laptop as the worst offender waking up the CPU according to powertop.  Can
someone explain to me what it does and why it is needed?

I am running a Fedora 9 system with the latest updates.


Version-Release number of selected component (if applicable):
kernel-2.6.25.3-18.fc9.i686


Additional info:
[root@localhost ~]# lspci 
00:00.0 Host bridge: Intel Corporation 82X38/X48 Express DRAM Controller
00:01.0 PCI bridge: Intel Corporation 82X38/X48 Express Host-Primary PCI Express
Bridge
00:06.0 PCI bridge: Intel Corporation 82X38/X48 Express Host-Secondary PCI
Express Bridge
00:19.0 Ethernet controller: Intel Corporation 82566DC-2 Gigabit Network
Connection (rev 02)
00:1a.0 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI
Controller #4 (rev 02)
00:1a.1 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI
Controller #5 (rev 02)
00:1a.2 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI
Controller #6 (rev 02)
00:1a.7 USB Controller: Intel Corporation 82801I (ICH9 Family) USB2 EHCI
Controller #2 (rev 02)
00:1b.0 Audio device: Intel Corporation 82801I (ICH9 Family) HD Audio Controller
(rev 02)
00:1c.0 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express Port 1
(rev 02)
00:1d.0 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI
Controller #1 (rev 02)
00:1d.1 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI
Controller #2 (rev 02)
00:1d.2 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI
Controller #3 (rev 02)
00:1d.7 USB Controller: Intel Corporation 82801I (ICH9 Family) USB2 EHCI
Controller #1 (rev 02)
00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev 92)
00:1f.0 ISA bridge: Intel Corporation 82801IR (ICH9R) LPC Interface Controller
(rev 02)
00:1f.2 RAID bus controller: Intel Corporation 82801 SATA RAID Controller (rev 02)
00:1f.3 SMBus: Intel Corporation 82801I (ICH9 Family) SMBus Controller (rev 02)
01:00.0 VGA compatible controller: ATI Technologies Inc RV630 [Radeon HD 2600XT]
01:00.1 Audio device: ATI Technologies Inc RV630/M76 audio device [Radeon HD
2600 Series]
04:05.0 Communication controller: Conexant HSF 56k Data/Fax Modem
04:0a.0 FireWire (IEEE 1394): Texas Instruments TSB43AB22/A IEEE-1394a-2000
Controller (PHY/Link)
Comment 1 William Lovaton 2008-07-19 18:04:44 EDT
I just upgraded the kernel to 2.6.25.10-86.fc9.i686 and it seems to be getting
worse: I get that message every time I boot.

Now I got two different messages in 3 reboots in a row.

Trace #1:

localhost kernel: SCSI subsystem initialized
localhost kernel: Driver 'sd' needs updating - please use bus_type methods
localhost kernel: ACPI: PCI Interrupt 0000:00:1f.2[C] -> GSI 20 (level, low) ->
IRQ 20
localhost kernel: hub 2-0:1.0: unable to enumerate USB device on port 3
localhost kernel: hub 2-0:1.0: unable to enumerate USB device on port 4
localhost kernel: irq 18: nobody cared (try booting with the "irqpoll" option)
localhost kernel: Pid: 425, comm: nash-hotplug Not tainted 2.6.25.10-86.fc9.i686 #1
localhost kernel:  [<c045c0e8>] __report_bad_irq+0x2e/0x6f
localhost kernel:  [<c045c2eb>] note_interrupt+0x1c2/0x21b
localhost kernel:  [<c045b984>] ? handle_IRQ_event+0x2a/0x5a
localhost kernel:  [<c045c89e>] handle_fasteoi_irq+0x8f/0xaf
localhost kernel:  [<c045c80f>] ? handle_fasteoi_irq+0x0/0xaf
localhost kernel:  [<c0407ea4>] do_IRQ+0x98/0xc4
localhost kernel:  [<c04065d7>] common_interrupt+0x23/0x28
localhost kernel:  [<c048007b>] ? xip_file_write+0x1be/0x2f5
localhost kernel:  [<c048d145>] ? sys_ppoll+0x1/0x1ea
localhost kernel:  [<c0405bf2>] ? syscall_call+0x7/0xb
localhost kernel:  =======================
localhost kernel: handlers:
localhost kernel: [<c05747b3>] (usb_hcd_irq+0x0/0x7d)
localhost kernel: Disabling IRQ #18


Trace #2:

localhost kernel: SCSI subsystem initialized
localhost kernel: Driver 'sd' needs updating - please use bus_type methods
localhost kernel: ACPI: PCI Interrupt 0000:00:1f.2[C] -> GSI 20 (level, low) ->
IRQ 20
localhost kernel: hub 2-0:1.0: unable to enumerate USB device on port 3
localhost kernel: irq 18: nobody cared (try booting with the "irqpoll" option)
localhost kernel: Pid: 0, comm: swapper Not tainted 2.6.25.10-86.fc9.i686 #1
localhost kernel:  [<c045c0e8>] __report_bad_irq+0x2e/0x6f
localhost kernel:  [<c045c2eb>] note_interrupt+0x1c2/0x21b
localhost kernel:  [<c045b984>] ? handle_IRQ_event+0x2a/0x5a
localhost kernel:  [<c045c89e>] handle_fasteoi_irq+0x8f/0xaf
localhost kernel:  [<c045c80f>] ? handle_fasteoi_irq+0x0/0xaf
localhost kernel:  [<c0407ea4>] do_IRQ+0x98/0xc4
localhost kernel:  [<c040406d>] ? mwait_idle+0x0/0x3d
localhost kernel:  [<c04065d7>] common_interrupt+0x23/0x28
localhost kernel:  [<c040406d>] ? mwait_idle+0x0/0x3d
localhost kernel:  [<c04040a8>] ? mwait_idle+0x3b/0x3d
localhost kernel:  [<c0404b90>] cpu_idle+0xa1/0xc1
localhost kernel:  [<c061c169>] rest_init+0x49/0x4b
localhost kernel:  =======================
localhost kernel: handlers:
localhost kernel: [<c05747b3>] (usb_hcd_irq+0x0/0x7d)
localhost kernel: Disabling IRQ #18


What can I do about it?  has anyone seen this?
Comment 2 William Lovaton 2008-11-15 11:50:11 EST
The problem is still present after updating my Fedora 9 system to kernel 2.6.27.5-37.fc9.i686 with yum.

The trace in the kernel log is the following:

kernel: usb usb7: configuration #1 chosen from 1 choice
kernel: hub 7-0:1.0: USB hub found
kernel: hub 7-0:1.0: 2 ports detected
kernel: usb 2-5: configuration #1 chosen from 1 choice
kernel: hub 2-5:1.0: USB hub found
kernel: hub 2-5:1.0: 2 ports detected
kernel: usb usb7: New USB device found, idVendor=1d6b, idProduct=0001
kernel: usb usb7: New USB device strings: Mfr=3, Product=2, SerialNumber=1
kernel: usb usb7: Product: UHCI Host Controller
kernel: usb usb7: Manufacturer: Linux 2.6.27.5-37.fc9.i686 uhci_hcd
kernel: usb usb7: SerialNumber: 0000:00:1d.1
kernel: uhci_hcd 0000:00:1d.2: PCI INT C -> GSI 18 (level, low) -> IRQ 18
kernel: uhci_hcd 0000:00:1d.2: UHCI Host Controller
kernel: uhci_hcd 0000:00:1d.2: new USB bus registered, assigned bus number 8
kernel: uhci_hcd 0000:00:1d.2: irq 18, io base 0x0000ff40

[snip...]

kernel: usb 7-1: configuration #1 chosen from 1 choice
kernel: hub 7-1:1.0: USB hub found
kernel: hub 7-1:1.0: 3 ports detected
kernel: usb 7-1: New USB device found, idVendor=413c, idProduct=1003
kernel: usb 7-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
kernel: usb 7-1: Product: Dell USB Keyboard Hub
kernel: usb 7-1: Manufacturer: Dell
kernel: usb 7-2: new low speed USB device using uhci_hcd and address 3
kernel: irq 18: nobody cared (try booting with the "irqpoll" option)
kernel: Pid: 0, comm: swapper Not tainted 2.6.27.5-37.fc9.i686 #1
kernel: [<c0461fd0>] __report_bad_irq+0x2e/0x6f
kernel: [<c04621df>] note_interrupt+0x1ce/0x223
kernel: [<c0461750>] ? handle_IRQ_event+0x5c/0x64
kernel: [<c04627a0>] handle_fasteoi_irq+0x99/0xc0
kernel: [<c0462707>] ? handle_fasteoi_irq+0x0/0xc0
kernel: [<c0405ede>] do_IRQ+0xf7/0x12e
kernel: [<c04046a8>] common_interrupt+0x28/0x30
kernel: [<c040917a>] ? mwait_idle+0x38/0x4b
kernel: [<c0402ca2>] cpu_idle+0x101/0x133
kernel: [<c06418bb>] start_secondary+0x197/0x19f
kernel: =======================
kernel: handlers:
kernel: [<c058e1b6>] (usb_hcd_irq+0x0/0xa3)
kernel: Disabling IRQ #18
Comment 3 Bug Zapper 2009-06-09 21:20:45 EDT
This message is a reminder that Fedora 9 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 9.  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 '9'.

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 9'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 9 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 please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

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
Comment 4 William Lovaton 2009-06-14 09:44:11 EDT
This bug seems to be fixed in Fedora 11, I'll give it a few days more to see if it happens again.  If not then I'll close this bug report.
Comment 5 Bug Zapper 2009-07-14 11:49:20 EDT
Fedora 9 changed to end-of-life (EOL) status on 2009-07-10. Fedora 9 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.
Comment 6 William Lovaton 2010-02-01 08:55:52 EST
Hi, I'm reopening this bug from Fedora 9.

I still get this problem in Fedora 12 while booting with the latest package kernel-PAE-2.6.31.12-174.2.3.fc12.i686.

This time the call trace in the logs is this:

kernel: ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
kernel: ata1.00: ATA-7: ST3500630AS, 3.ADG, max UDMA/133
kernel: ata1.00: 976773168 sectors, multi 0: LBA48 NCQ (depth 31/32)
kernel: irq 18: nobody cared (try booting with the "irqpoll" option)
kernel: Pid: 0, comm: swapper Not tainted 2.6.31.12-174.2.3.fc12.i686.PAE #1
kernel: Call Trace:
kernel: [<c047c3b1>] __report_bad_irq+0x33/0x74
kernel: [<c047c4ec>] note_interrupt+0xfa/0x152
kernel: [<c047ca64>] handle_fasteoi_irq+0x83/0xa2
kernel: [<c040b1d5>] handle_irq+0x40/0x4b
kernel: [<c040a999>] do_IRQ+0x46/0x9a
kernel: [<c04096b0>] common_interrupt+0x30/0x38
kernel: [<c040f38b>] ? mwait_idle+0x67/0x85
kernel: [<c040813f>] cpu_idle+0x96/0xaf
kernel: [<c0775e89>] start_secondary+0x1f5/0x233
kernel: handlers:
kernel: [<c06819b2>] (usb_hcd_irq+0x0/0x6f)
kernel: Disabling IRQ #18
kernel: usb 1-6: New USB device found, idVendor=beef, idProduct=0006
kernel: usb 1-6: New USB device strings: Mfr=1, Product=2, SerialNumber=3
kernel: usb 1-6: Product: XPS MiniView

What is this about?

The system is a Dell XPS 420 system with an Intel Core 2 Quad CPU at 2.4 GHz.  The lspci output is in the first comment.
Comment 7 Stanislaw Gruszka 2010-02-14 16:19:09 EST
Some device generate interrupt before driver can handle it or there is no driver for it. This can be driver or kernel bug or some H/W malfunction. What shows "cat /proc/interrupts" ?
Comment 8 William Lovaton 2010-02-14 17:47:01 EST
[root@xps420 ~]# cat /proc/interrupts 
            CPU0       CPU1       CPU2       CPU3       
   0:        339          1          0         27   IO-APIC-edge      timer
   1:          0          1          1          1   IO-APIC-edge      i8042
   8:          1          0          0          0   IO-APIC-edge      rtc0
   9:          0          0          0          0   IO-APIC-fasteoi   acpi
  12:          1          0          2          1   IO-APIC-edge      i8042
  16:       8207       1298      18276      10909   IO-APIC-fasteoi   uhci_hcd:usb3, HDA Intel
  17:          5          6         91         41   IO-APIC-fasteoi   uhci_hcd:usb4, uhci_hcd:usb7, HDA Intel
  18:      84412      11791     276622     164894   IO-APIC-fasteoi   uhci_hcd:usb8, firewire_ohci
  22:          5          4          4          7   IO-APIC-fasteoi   ehci_hcd:usb1, uhci_hcd:usb5
  23:       6921       6292    1527503    1313790   IO-APIC-fasteoi   ehci_hcd:usb2, uhci_hcd:usb6
  27:       1594       1590     747586     614531   PCI-MSI-edge      ahci
  28:          5         11          5    6756968   PCI-MSI-edge      eth0
 NMI:          0          0          0          0   Non-maskable interrupts
 LOC:   31012741   28015535   28726203   40721585   Local timer interrupts
 SPU:          0          0          0          0   Spurious interrupts
 CNT:          0          0          0          0   Performance counter interrupts
 PND:          0          0          0          0   Performance pending work
 RES:     666208     641300     877901     780495   Rescheduling interrupts
 CAL:     457048     841663     352932     692711   Function call interrupts
 TLB:    1320123    1669328    1168506    1676315   TLB shootdowns
 TRM:          0          0          0          0   Thermal event interrupts
 THR:          0          0          0          0   Threshold APIC interrupts
 MCE:          0          0          0          0   Machine check exceptions
 MCP:        109        109        109        109   Machine check polls
 ERR:          3
 MIS:          0
Comment 9 Stanislaw Gruszka 2010-02-15 11:07:05 EST
Could you please attach full dmesg output?
Comment 10 William Lovaton 2010-03-28 14:02:37 EDT
Created attachment 403119 [details]
dmesg output

Here is the dmesg output... sorry for the late response.
Comment 11 Stanislaw Gruszka 2010-04-01 05:11:09 EDT
*** Bug 512347 has been marked as a duplicate of this bug. ***
Comment 12 Stanislaw Gruszka 2010-04-01 05:42:10 EDT
This device is some kind of weird (serial number, idVendor, Manufacturer :):

> usb 1-6: New USB device found, idVendor=beef, idProduct=0006
> usb 1-6: New USB device strings: Mfr=1, Product=2, SerialNumber=3
> usb 1-6: Product: XPS MiniView
> usb 1-6: Manufacturer: Microsoft Co
> usb 1-6: SerialNumber: AAAAAAAAAAAAAAAAAAAA
> usb 1-6: configuration #128 chosen from 1 choice

It generates interrupt, or do something that make uhci chip generates interrupt, that uhci_hcd driver not handle.

From uhci_hcd interrupt handler routine:

static irqreturn_t uhci_irq(struct usb_hcd *hcd)
{
        struct uhci_hcd *uhci = hcd_to_uhci(hcd);
        unsigned short status;

        /*
         * Read the interrupt status, and write it back to clear the
         * interrupt cause.  Contrary to the UHCI specification, the
         * "HC Halted" status bit is persistent: it is RO, not R/WC.
         */
        status = inw(uhci->io_addr + USBSTS);
        if (!(status & ~USBSTS_HCH))    /* shared interrupt, not mine */
                return IRQ_NONE;
        outw(status, uhci->io_addr + USBSTS);           /* Clear it */

        otherwise return IRQ_HANDLED.

Seems we get status == 0 or status == USBSTS_HCH (Host Controller Halted) . Perhaps we should return IRQ_HANDLED if status is USBSTS_HCH, should look at UHCI spec. 

I going to prepare test/debug kernel which will print status value, and return IRQ_HANDLED if status == USBSTS_HCH.
Comment 13 Stanislaw Gruszka 2010-04-02 08:57:51 EDT
Hi

Could you please test below kernel (when it finish to build, it now compile):
http://koji.fedoraproject.org/koji/taskinfo?taskID=2090973
Comment 14 William Lovaton 2010-04-05 00:50:23 EDT
Strange, I downloaded kernel-PAE-2.6.32.10-94.sg_uhci.fc12.i686.rpm from here:
http://koji.fedoraproject.org/koji/getfile?taskID=2090976&name=kernel-PAE-2.6.32.10-94.sg_uhci.fc12.i686.rpm

But I got this when I tried to install it (or update it) with rpm:
error: Failed dependencies:
	kernel-firmware >= 2.6.32.10-94.sg_uhci.fc12 is needed by kernel-PAE-2.6.32.10-94.sg_uhci.fc12.i686

How can I install this kernel? I have done this before but I never got this error so I don't really know what to do now.
Comment 15 Stanislaw Gruszka 2010-04-06 04:28:46 EDT
You have to install kernel-firmware package, it is in "
buildArch (kernel-2.6.32.10-94.sg_uhci.fc12.src.rpm, noarch)" subfolder.

Alternatively, because you have already firmware installed on you system from other kernel, you can install new kernel with "rpm -ivh --force --nodeps kernel.rpm"
Comment 16 Stanislaw Gruszka 2010-04-15 10:11:27 EDT
I'm doing "unofficial" koji builds, that's mean packages are removed after a week or two (I'm not sure). Here is new build:
http://koji.fedoraproject.org/koji/taskinfo?taskID=2117092
please test before it expire. Thanks.
Comment 17 William Lovaton 2010-04-17 22:07:23 EDT
I installed that kernel and it logs lots of "uhci_irq status 0020" in syslog.  The problem is that the backtrace is not generated every time I boot, just sometimes.

Do you want me to attach the /var/log/messages file from this kernel?
Comment 18 Stanislaw Gruszka 2010-04-19 07:03:20 EDT
(In reply to comment #17)
> I installed that kernel and it logs lots of "uhci_irq status 0020" in syslog.

Ahh, debug is enabled by default. To get rid of that messages add
uhci_hcd.debug=0 kernel parameter on proper line in /boot/grub/grub.conf

This show us the status is USBSTS_HCH == Host Controler Halted, that looks ok.
 
> The problem is that the backtrace is not generated every time I boot, just
> sometimes.
>
> Do you want me to attach the /var/log/messages file from this kernel?    

Yes.
Comment 19 William Lovaton 2010-04-21 21:35:55 EDT
Created attachment 408207 [details]
syslog with debugging info from new kernel
Comment 20 Stanislaw Gruszka 2010-04-27 16:32:26 EDT
I will close this bug with WONTFIX resolution.

Problem here is that XPS MiniView special device make something wrong on USB bus and uhci generate strange interrupts that uhci driver not handle. Disabling interrupts is probably the best what we can do in that situation, and kernel do this. The only problem, except ugly message in dmesg, is that interrupt is shared with firewire_ohci, so firewire will not work. If you want to use firewire, some BIOS settings may help, however 100 % certain method will be physical disconnect of XPS MiniView from usb internal connector on motherboard in your computer (this will help with ugly calltrace in dmesg as well :-)
Comment 21 William Lovaton 2010-04-27 16:44:14 EDT
Fair enough, that XPS MiniView thing is close to useless to me.  Maybe some day Linux and userspace will be avable to do something really useful with it.

Thanks for your help.

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