Re: 5 devices sharing one irq

dolcepa@xxxxxxxxx wrote:

Hello everyone,

I have read an article, which tells that if you type on a shell this
order: cat /proc/interrupts
and then you see more than one device sharing one irq, and these
devices are not pci or agp, then you may be having a conflict. I did
that and I have 5 devices sharing the same irq, these ones:

17: 0 IO-APIC-level ehci_hcd:usb1, uhci_hcd:usb2, uhci_hcd:usb3,
uhci_hcd:usb4, uhci_hcd:usb5

is there something I can do to these devices have their own irq?

Thank you and regards

I would assume on your hardware that they are all PCI devices, in which
case, there is unlikely to be a problem. Never seen USB on an ISA bus,
though that doesn't mean it was never done, just very unlikely.

A well written device driver has a "top half" and a "bottom half" handler.

<quick google to check my terminolgy>

Ah... OK - my *basic* understanding is:

The top half typically is what is wired to the interrupt and should complete
quickly.

First, each registered top half handler for that interrupt is called in turn
(these are what you are seeing in /proc/interrupts) and each driver handler
decides if the interrupt was generated by *their* hardware (check a
register or somesuch).

If so:

If there is much and/or slow or work with an indeterminate time to complete,
then the top half handler will schedule a tasklet to run later at the
kernel's earliest convenience (in practice that should be "real soon now,
but not in this interrupt routine"). Else the routine might just do its
simple and quick job in place.

Then onto the next top half handler (two IRQs may have been fired
simultaneously, so 2 or more devices might be waiting for service).

Meanwhile, outside of the interrupt handlers, the queued bottom half
tasklets get scheduled in some sort of orderly manner.

In short, the linux kernel is designed to handle it gracefully for PCI/AGP -
ISA is another story.

In practice, some suspect motherboards, bad hardware or either with dodgey
timings (like an overclocked mobo) can go weird under high interrupt load
if the interrupts are shared. I've had a fair bit of trouble with Abit
boards, aggressive timings and high disk+network load where the IE and NIC
share the same interrupt. Result - instability upon high NFS load, then
freeze. Jiggling the BIOS timings fixed it. Never had a problem on decent
boards though.

As to your USB devices, they are probably all on the same type of hardware
or even the same chip, so it would be expected to see them share an
interrupt. I've never seen a problem with usb + couple of other random
things on an IRQ, though I bet someone somewhere has.

As to re-assigning IRQs - either it's impossible, or the bIOS may have a way
to reset PCI config data or even allocate IRQ - depends bery much on the
BIOS and board.

HTH

Tim
.

Relevant Pages

  • Re: [patch 2/9] LTTng instrumentation - irq
    ... Those tracepoints are used by LTTng. ... The IRQ instrumentation instruments the IRQ handler entry and exit. ... From an interrupt latency analysis POV, ...
    (Linux-Kernel)
  • Re: Threaded interrupts for synaptic touchscreen in HTC dream
    ... them to schedule the main IRQ handler outside hardirq context so ... looks more like it's intended to be called from within the IRQ ... All it needs is to set handle_level_oneshot_irq for the interrupt line ... controller on them and would like to expose that interrupt controller ...
    (Linux-Kernel)
  • Re: [GIT PATCH] more Driver core patches for 2.6.19
    ... Rather than IRQ_HANDLED, it should have been: ... That just means that the _handler_ won't be called. ... FOR THAT INTERRUPT will be called. ...
    (Linux-Kernel)
  • [Fwd: 2.6.20-14.23 pauses on ThinkPad X32]
    ... Latency: 96 ... Subsystem: 1014:052d ... Interrupt: pin A routed to IRQ 11 ...
    (Ubuntu)
  • Re: hardware interrupt mechanism
    ... when any h/w interrupt occurs and from here the appropriate handler ... handler is installed. ... then calls any handler hooked for the corresponding IRQ line. ... the effect of a system freeze. ...
    (comp.os.linux.development.system)