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?

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

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

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.

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.

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.

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" ?

[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

Could you please attach full dmesg output?

Created attachment 403119 [details]
dmesg output

Here is the dmesg output... sorry for the late response.

*** Bug 512347 has been marked as a duplicate of this bug. ***

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.

Hi

Could you please test below kernel (when it finish to build, it now compile):
http://koji.fedoraproject.org/koji/taskinfo?taskID=2090973

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.

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"

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.

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?

(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.

Created attachment 408207 [details]
syslog with debugging info from new kernel

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 :-)

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.