5 devices sharing one irq - Hardware

This is a discussion on 5 devices sharing one irq - Hardware ; 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 ...

+ Reply to Thread
Results 1 to 5 of 5

Thread: 5 devices sharing one irq

  1. 5 devices sharing one irq

    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


  2. Re: 5 devices sharing one irq

    dolcepa@gmail.com 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?


    There's probably no need to worry (unless you're having problems with
    USB).

    It appears that you have a single 5-port USB 2.0 controller on that IRQ,
    judging by the usb1-usb5 designations after uhci_hcd (a USB host
    controller driver) and the ehci_hcd module (USB 2.0 support module). It
    may not even be possible to have the different ports of the USB
    controller on different IRQs, if they really are 5 ports on one chip (as
    is my guess).

    Also note that these are almost certainly PCI devices, even if they're
    on-board USB ports. The PCI interface isn't limited to PCI slots! If
    'lspci | grep -i uhci' shows your USB controller, then you can be sure
    that it is a PCI device...meaning IRQ sharing is much less of a concern.

  3. Re: 5 devices sharing one irq

    dolcepa@gmail.com 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.



    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

  4. Re: 5 devices sharing one irq

    with usb devices I not having problems, I'm having them with my
    monitor, and as I didn't find the problem yet, I thought if this could
    be interfering.....

    > Also note that these are almost certainly PCI devices, even if they're
    > on-board USB ports. The PCI interface isn't limited to PCI slots! If
    > 'lspci | grep -i uhci' shows your USB controller, then you can be sure
    > that it is a PCI device...meaning IRQ sharing is much less of a concern.


    yes, by doing that order shows me this:


    0000:00:10.0 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB
    1.1 Controller (rev 81)
    0000:00:10.1 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB
    1.1 Controller (rev 81)
    0000:00:10.2 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB
    1.1 Controller (rev 81)
    0000:00:10.3 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB
    1.1 Controller (rev 81)

    So maybe this is not the cause my monitor is working wrong, then,

    Thanks and greetins


    On 21 mayo, 21:08, John-Paul Stewart
    wrote:
    > dolc...@gmail.com 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?

    >
    > There's probably no need to worry (unless you're having problems with
    > USB).
    >
    > It appears that you have a single 5-port USB 2.0 controller on that IRQ,
    > judging by the usb1-usb5 designations after uhci_hcd (a USB host
    > controller driver) and the ehci_hcd module (USB 2.0 support module). It
    > may not even be possible to have the different ports of the USB
    > controller on different IRQs, if they really are 5 ports on one chip (as
    > is my guess).
    >
    > Also note that these are almost certainly PCI devices, even if they're
    > on-board USB ports. The PCI interface isn't limited to PCI slots! If
    > 'lspci | grep -i uhci' shows your USB controller, then you can be sure
    > that it is a PCI device...meaning IRQ sharing is much less of a concern.




  5. Re: 5 devices sharing one irq

    hi and thank you for answering, I have 4 usb slots in the back of my
    cpu, and 2 in the front pane,

    And the usb devices I use are a external hard disk, a modem-router
    (although in that moment I was not using this usb modem, but a router,
    which one don use any usb slot, also a printer, but I was using it
    either nor I have installed,

    Then I assume that although I am not using this usb slots, they could
    cause a high interrupt load? The main reason I'm worried about it itÅ›
    for the malfunctioning of my monitor. So maybe these irq shares are
    not the cause?

    Cheers

    On 21 mayo, 21:47, Tim S wrote:
    > 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.
    >
    >
    >
    > 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




+ Reply to Thread