Re: VIA KT400 + Kernel 2.6.12 + IO-APIC + uhci_hcd = IRQ trouble

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Michel Bouissou a écrit :

Hi there,

Natalie Protasevich and Alan Stern have worked a lot on helping me out with a VIA KT400 chipset / kernel 2.6.12 / IO-APIC / IRQ problem "irq 21: nobody cared!", which so far hasn't found its solution.

Research done with Alan shows that, on my system, the USB 2.0 controller seems to generate interrupts on the IRQ line attributed to the USB 1.1 controller, which isn't supposed to happen, and puzzles the system, when IO-APIC is enabled.

However, this didn't cause problems with 2.4 series kernels.

For the time being, there is no solution (Natalie is still investigating this), and it boils down to the following:

- If I boot with USB 2.0 enabled in BIOS, AND IO-APIC enabled in the kernel, then it badly breaks.

- If I either disable USB 2.0 in BIOS, or IO-APIC in the kernel, then it's OK.

I found today the thread between Bjorn Helgaas and Mathieu Bérard on LKML, where Mathieu reported the same problem, and Bjorn advised him to reverse a kernel patch (http://lkml.org/lkml/2005/6/21/243 ).

Mathieu (I don't have his email address, Bjorn, could you be so kind to forward this message to him) reports that it apparently solved this problem, so I tried to do the same, and reversed the same patch.




Hi,
yes I've encountered the same problem but my system
is a little bit different: It's a MSI mainboard with a VIA KT266A chipset
and no USB 2.0 controller (just 3 uhci).
IO-APIC is enabled.

With a 2.6.13-rc1-mm1 kernel, for example,
I got those error messages just after
the integrated sound card detection:

Jul 2 21:04:12 perenold kernel: irq 21: nobody cared (try booting with the "irqpoll" option)
Jul  2 21:04:12 perenold kernel: [<c0133c24>] __report_bad_irq+0x24/0x80
Jul  2 21:04:12 perenold kernel: [<c0133d22>] note_interrupt+0x72/0xc0
Jul  2 21:04:12 perenold kernel: [<c0133710>] __do_IRQ+0xe0/0xf0
Jul  2 21:04:12 perenold kernel: [<c0104f8e>] do_IRQ+0x3e/0x60
Jul  2 21:04:12 perenold kernel: =======================
Jul  2 21:04:12 perenold kernel: [<c0103502>] common_interrupt+0x1a/0x20
Jul  2 21:04:12 perenold kernel: [<c0142102>] zap_pte_range+0x82/0x1c0
Jul  2 21:04:12 perenold kernel: [<c01422bf>] unmap_page_range+0x7f/0xb0
Jul  2 21:04:12 perenold kernel: [<c01423f6>] unmap_vmas+0x106/0x210
Jul  2 21:04:12 perenold kernel: [<c01469c1>] exit_mmap+0x71/0x140
Jul  2 21:04:12 perenold kernel: [<c011547e>] mmput+0x2e/0xe0
Jul  2 21:04:12 perenold kernel: [<c015af3c>] exec_mmap+0xac/0x160
Jul  2 21:04:12 perenold kernel: [<c015b0a0>] flush_old_exec+0x70/0x700
Jul  2 21:04:12 perenold kernel: [<c0151475>] vfs_read+0xf5/0x160
Jul  2 21:04:12 perenold kernel: [<c015ae70>] kernel_read+0x40/0x60
Jul  2 21:04:12 perenold kernel: [<c0178f32>] load_elf_binary+0x252/0xd20
Jul  2 21:04:12 perenold kernel: [<c0138bf7>] buffered_rmqueue+0xb7/0x210
Jul  2 21:04:12 perenold kernel: [<c0138eeb>] __alloc_pages+0xdb/0x400
Jul  2 21:04:12 perenold kernel: [<c0104f95>] do_IRQ+0x45/0x60
Jul  2 21:04:12 perenold kernel: [<c01c2c6e>] __copy_from_user_ll+0x3e/0x70
Jul 2 21:04:12 perenold kernel: [<c015b92f>] search_binary_handler+0x4f/0x1d0
Jul  2 21:04:12 perenold kernel: [<c015bbfe>] do_execve+0x14e/0x200
Jul  2 21:04:12 perenold kernel: [<c010181f>] sys_execve+0x2f/0x70
Jul  2 21:04:12 perenold kernel: [<c0102aeb>] sysenter_past_esp+0x54/0x75
Jul  2 21:04:12 perenold kernel: handlers:
Jul 2 21:04:12 perenold kernel: [<e0c59450>] (snd_via82xx_interrupt+0x0/0xc0 [snd_via82xx])
Jul  2 21:04:12 perenold kernel: Disabling IRQ #21

and later:

Jul 2 21:04:37 perenold kernel: uhci_hcd 0000:00:11.3: Unlink after no-IRQ? Controller is probably using the wrong IRQ.

IRQ 21 is then crazy with a rate of increasing of around 200000 per second in /proc/interrupts

All those error messages disappear if I revert the patch as I was advised to.

I have that in /proc/interrupts: (with an healthy kernel)
          CPU0
 0:  201893429    IO-APIC-edge  timer
 1:         21    IO-APIC-edge  i8042
 7:          2    IO-APIC-edge  parport0
 8:          0    IO-APIC-edge  rtc
 9:          0   IO-APIC-level  acpi
14:    5448524    IO-APIC-edge  ide0
15:   14583934    IO-APIC-edge  ide1
16:     172543   IO-APIC-level  ide3
17:     299810   IO-APIC-level  saa7134[0]
18:   24973124   IO-APIC-level  eth0
19:    5233000   IO-APIC-level  eth1
20:         82   IO-APIC-level  uhci_hcd:usb1, uhci_hcd:usb2, uhci_hcd:usb3
21:          0   IO-APIC-level  VIA8233
NMI:          0
LOC:  201897508
ERR:          0
MIS:          0


So maybe, in my case, it's a mess between the IRQ of the uhci controllers
and the one of the integrated AC'97 sound ship.

But as it is mainly a server box nor the usb controllers nor the sound card are used very often,
so I don't know if those devices are actually working now. I am currently on
vacation 300 km away from that box so I can't really plug an USB key to
do some tests. But I will as soon as a can if that can help.
I will also try to reboot the box several times to see if the "IRQ 21 nobody cared" error
reappears.

--
Mathieu









-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]
  Powered by Linux