Re: sharing interrupt between PCI device - Kernel

This is a discussion on Re: sharing interrupt between PCI device - Kernel ; Nobin Mathew wrote: > Hi, > > I think this question is already asked in this mailing list and Sorry > for asking this again. > > My problem is this: > > I have two PCI devices ( also ...

+ Reply to Thread
Page 1 of 2 1 2 LastLast
Results 1 to 20 of 27

Thread: Re: sharing interrupt between PCI device

  1. Re: sharing interrupt between PCI device

    Nobin Mathew wrote:
    > Hi,
    >
    > I think this question is already asked in this mailing list and Sorry
    > for asking this again.
    >
    > My problem is this:
    >
    > I have two PCI devices ( also two kernel drivers for those) which
    > shares the interupt. When I remove one driver other device stops
    > working, which is happening due to pci_disable_device () in removed
    > driver. This call is disabling the shared interrupt.


    pci_disable_device shouldn't be disabling the interrupt line, at least
    not in this case. Without more details on the platform or drivers, it's
    difficult to say why this would happen.

    >
    > We can avoid this by just removing the pci_disable_device () in the
    > driver, but i dont think this is a good way (correct me if I am
    > wrong).
    >
    > Can you suggest some ways to overcome this issue.


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

  2. Re: sharing interrupt between PCI device

    Hi

    This is the system information X86_64 platform Xeon dual core processor.

    I saw the pci_disable_device () it is calling pcibios_disable_device
    () and this is is defined as

    void pcibios_disable_device (struct pci_dev *dev)
    {
    pcibios_disable_resources(dev);
    if (pcibios_disable_irq)
    pcibios_disable_irq(dev);
    }

    In i386 platform, I could not find a definition for these calls in
    x86_64 platform, i think it is using i386 platform code.

    Thanks
    Nobin Mathew





    On Wed, Nov 5, 2008 at 5:58 AM, Robert Han**** wrote:
    > Nobin Mathew wrote:
    >>
    >> Hi,
    >>
    >> I think this question is already asked in this mailing list and Sorry
    >> for asking this again.
    >>
    >> My problem is this:
    >>
    >> I have two PCI devices ( also two kernel drivers for those) which
    >> shares the interupt. When I remove one driver other device stops
    >> working, which is happening due to pci_disable_device () in removed
    >> driver. This call is disabling the shared interrupt.

    >
    > pci_disable_device shouldn't be disabling the interrupt line, at least not
    > in this case. Without more details on the platform or drivers, it's
    > difficult to say why this would happen.
    >
    >>
    >> We can avoid this by just removing the pci_disable_device () in the
    >> driver, but i dont think this is a good way (correct me if I am
    >> wrong).
    >>
    >> Can you suggest some ways to overcome this issue.

    >
    >

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

  3. Re: sharing interrupt between PCI device

    On 11/05/2008 08:49 AM, Nobin Mathew wrote:
    > Hi
    >
    > This is the system information X86_64 platform Xeon dual core processor.
    >
    > I saw the pci_disable_device () it is calling pcibios_disable_device
    > () and this is is defined as
    >
    > void pcibios_disable_device (struct pci_dev *dev)
    > {
    > pcibios_disable_resources(dev);
    > if (pcibios_disable_irq)
    > pcibios_disable_irq(dev);
    > }
    >
    > In i386 platform, I could not find a definition for these calls in
    > x86_64 platform, i think it is using i386 platform code.


    Well, will you show us the code, so that we needn't to crystal gaze? It's pretty
    hard to say what happens, if we don't see what you do in the driver...
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  4. Re: sharing interrupt between PCI device

    Hi


    Code is here
    first one USB Virual input devices

    http://lxr.linux.no/linux+v2.6.27.4/...core/hcd-pci.c

    Second one is hp-ilo driver

    http://lxr.linux.no/linux+v2.6.27.4/...s/misc/hpilo.c


    Thanks
    Nobin Mathew.


    On Wed, Nov 5, 2008 at 2:06 PM, Jiri Slaby wrote:
    > On 11/05/2008 08:49 AM, Nobin Mathew wrote:
    >> Hi
    >>
    >> This is the system information X86_64 platform Xeon dual core processor.
    >>
    >> I saw the pci_disable_device () it is calling pcibios_disable_device
    >> () and this is is defined as
    >>
    >> void pcibios_disable_device (struct pci_dev *dev)
    >> {
    >> pcibios_disable_resources(dev);
    >> if (pcibios_disable_irq)
    >> pcibios_disable_irq(dev);
    >> }
    >>
    >> In i386 platform, I could not find a definition for these calls in
    >> x86_64 platform, i think it is using i386 platform code.

    >
    > Well, will you show us the code, so that we needn't to crystal gaze? It's pretty
    > hard to say what happens, if we don't see what you do in the driver...
    >

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

  5. Re: sharing interrupt between PCI device

    Hi

    Can somebody tell me what is going wrong in the driver. If you need
    any further information please tell me

    Thanks
    Nobin Mathew

    On Wed, Nov 5, 2008 at 2:50 PM, Nobin Mathew wrote:
    > Hi
    >
    >
    > Code is here
    > first one USB Virual input devices
    >
    > http://lxr.linux.no/linux+v2.6.27.4/...core/hcd-pci.c
    >
    > Second one is hp-ilo driver
    >
    > http://lxr.linux.no/linux+v2.6.27.4/...s/misc/hpilo.c
    >
    >
    > Thanks
    > Nobin Mathew.
    >
    >
    > On Wed, Nov 5, 2008 at 2:06 PM, Jiri Slaby wrote:
    >> On 11/05/2008 08:49 AM, Nobin Mathew wrote:
    >>> Hi
    >>>
    >>> This is the system information X86_64 platform Xeon dual core processor.
    >>>
    >>> I saw the pci_disable_device () it is calling pcibios_disable_device
    >>> () and this is is defined as
    >>>
    >>> void pcibios_disable_device (struct pci_dev *dev)
    >>> {
    >>> pcibios_disable_resources(dev);
    >>> if (pcibios_disable_irq)
    >>> pcibios_disable_irq(dev);
    >>> }
    >>>
    >>> In i386 platform, I could not find a definition for these calls in
    >>> x86_64 platform, i think it is using i386 platform code.

    >>
    >> Well, will you show us the code, so that we needn't to crystal gaze? It's pretty
    >> hard to say what happens, if we don't see what you do in the driver...
    >>

    >

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

  6. Re: sharing interrupt between PCI device

    Hi

    can anybody point to some reference device drivers where PCI interrupt
    sharing is implemented properly.

    Thanks
    Nobin Mathew

    On Thu, Nov 6, 2008 at 11:41 AM, Nobin Mathew wrote:
    > Hi
    >
    > Can somebody tell me what is going wrong in the driver. If you need
    > any further information please tell me
    >
    > Thanks
    > Nobin Mathew
    >
    > On Wed, Nov 5, 2008 at 2:50 PM, Nobin Mathew wrote:
    >> Hi
    >>
    >>
    >> Code is here
    >> first one USB Virual input devices
    >>
    >> http://lxr.linux.no/linux+v2.6.27.4/...core/hcd-pci.c
    >>
    >> Second one is hp-ilo driver
    >>
    >> http://lxr.linux.no/linux+v2.6.27.4/...s/misc/hpilo.c
    >>
    >>
    >> Thanks
    >> Nobin Mathew.
    >>
    >>
    >> On Wed, Nov 5, 2008 at 2:06 PM, Jiri Slaby wrote:
    >>> On 11/05/2008 08:49 AM, Nobin Mathew wrote:
    >>>> Hi
    >>>>
    >>>> This is the system information X86_64 platform Xeon dual core processor.
    >>>>
    >>>> I saw the pci_disable_device () it is calling pcibios_disable_device
    >>>> () and this is is defined as
    >>>>
    >>>> void pcibios_disable_device (struct pci_dev *dev)
    >>>> {
    >>>> pcibios_disable_resources(dev);
    >>>> if (pcibios_disable_irq)
    >>>> pcibios_disable_irq(dev);
    >>>> }
    >>>>
    >>>> In i386 platform, I could not find a definition for these calls in
    >>>> x86_64 platform, i think it is using i386 platform code.
    >>>
    >>> Well, will you show us the code, so that we needn't to crystal gaze? It's pretty
    >>> hard to say what happens, if we don't see what you do in the driver...
    >>>

    >>

    >

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

  7. Re: sharing interrupt between PCI device

    On 11/06/2008 08:44 AM, Nobin Mathew wrote:
    > Hi
    >
    > can anybody point to some reference device drivers where PCI interrupt
    > sharing is implemented properly.


    Sorry, I still don't understand the setup. You have two separate pci devices,
    both with the same irq number and pci_disable_device on one of them stops irqs
    on the second?
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  8. Re: sharing interrupt between PCI device

    Exactly

    On Fri, Nov 7, 2008 at 2:54 AM, Jiri Slaby wrote:
    > On 11/06/2008 08:44 AM, Nobin Mathew wrote:
    >> Hi
    >>
    >> can anybody point to some reference device drivers where PCI interrupt
    >> sharing is implemented properly.

    >
    > Sorry, I still don't understand the setup. You have two separate pci devices,
    > both with the same irq number and pci_disable_device on one of them stops irqs
    > on the second?
    >

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

  9. Re: sharing interrupt between PCI device

    On Wed, Nov 05, 2008 at 02:50:01PM +0530, Nobin Mathew wrote:
    > Hi
    >
    >
    > Code is here
    > first one USB Virual input devices
    >
    > http://lxr.linux.no/linux+v2.6.27.4/...core/hcd-pci.c
    >
    > Second one is hp-ilo driver
    >
    > http://lxr.linux.no/linux+v2.6.27.4/...s/misc/hpilo.c


    I looked for usage of request_irq() and didn't see it in either driver.

    I was looking for the parameters passed to the request_irq() call.
    If the IRQ and the "dev_id" parameter are the same for both drivers,
    I'm not sure how the generic IRQ management code could tell them apart
    and then might disable the wrong instance when free_irq() is called.
    Perhaps you already know where the respective request_irq() calls are
    and can easily determine that both are passing in a NULL for
    the "dev_id" parameter?


    If that's not the case, I would be looking for bugs in the generic
    shared IRQ code. But given shared IRQ experience with older kernels,
    I'm not inclined to believe there is a problem in the generic IRQ code
    on newer kernels unless presented with contrary evidence.

    hth,
    grant



    >
    > Thanks
    > Nobin Mathew.
    >
    >
    > On Wed, Nov 5, 2008 at 2:06 PM, Jiri Slaby wrote:
    > > On 11/05/2008 08:49 AM, Nobin Mathew wrote:
    > >> Hi
    > >>
    > >> This is the system information X86_64 platform Xeon dual core processor.
    > >>
    > >> I saw the pci_disable_device () it is calling pcibios_disable_device
    > >> () and this is is defined as
    > >>
    > >> void pcibios_disable_device (struct pci_dev *dev)
    > >> {
    > >> pcibios_disable_resources(dev);
    > >> if (pcibios_disable_irq)
    > >> pcibios_disable_irq(dev);
    > >> }
    > >>
    > >> In i386 platform, I could not find a definition for these calls in
    > >> x86_64 platform, i think it is using i386 platform code.

    > >
    > > Well, will you show us the code, so that we needn't to crystal gaze? It's pretty
    > > hard to say what happens, if we don't see what you do in the driver...
    > >

    > --
    > To unsubscribe from this list: send the line "unsubscribe linux-pci" in
    > the body of a message to majordomo@vger.kernel.org
    > More majordomo info at http://vger.kernel.org/majordomo-info.html

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

  10. Re: sharing interrupt between PCI device

    On 11/08/2008 08:57 AM, Grant Grundler wrote:
    > On Wed, Nov 05, 2008 at 02:50:01PM +0530, Nobin Mathew wrote:
    >> Hi
    >>
    >>
    >> Code is here
    >> first one USB Virual input devices
    >>
    >> http://lxr.linux.no/linux+v2.6.27.4/...core/hcd-pci.c
    >>
    >> Second one is hp-ilo driver
    >>
    >> http://lxr.linux.no/linux+v2.6.27.4/...s/misc/hpilo.c

    >
    > I looked for usage of request_irq() and didn't see it in either driver.


    The second one doesn't use interrupts at all. How can this be listed in
    /proc/interrupts on any line?

    The first one obviously uses irq by registering it in common *hci layer.
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  11. Re: sharing interrupt between PCI device

    This is what happens when we insert and remove the hp-ilo driver (dmesg logs).

    for remove
    ACPI: PCI interrupt for device 0000:01:04.2 disabled


    when inserted
    PCI: Enabling device 0000:01:04.2 (0114 -> 0117)
    ACPI: PCI Interrupt 0000:01:04.2[B] -> GSI 23 (level, low) -> IRQ 225

    Thanks

    On Sat, Nov 8, 2008 at 3:19 PM, Jiri Slaby wrote:
    > On 11/08/2008 08:57 AM, Grant Grundler wrote:
    >> On Wed, Nov 05, 2008 at 02:50:01PM +0530, Nobin Mathew wrote:
    >>> Hi
    >>>
    >>>
    >>> Code is here
    >>> first one USB Virual input devices
    >>>
    >>> http://lxr.linux.no/linux+v2.6.27.4/...core/hcd-pci.c
    >>>
    >>> Second one is hp-ilo driver
    >>>
    >>> http://lxr.linux.no/linux+v2.6.27.4/...s/misc/hpilo.c

    >>
    >> I looked for usage of request_irq() and didn't see it in either driver.

    >
    > The second one doesn't use interrupts at all. How can this be listed in
    > /proc/interrupts on any line?
    >
    > The first one obviously uses irq by registering it in common *hci layer.
    >

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

  12. Re: sharing interrupt between PCI device

    On 11/08/2008 12:53 PM, Nobin Mathew wrote:
    > This is what happens when we insert and remove the hp-ilo driver (dmesg logs).
    >
    > for remove
    > ACPI: PCI interrupt for device 0000:01:04.2 disabled
    >
    >
    > when inserted
    > PCI: Enabling device 0000:01:04.2 (0114 -> 0117)
    > ACPI: PCI Interrupt 0000:01:04.2[B] -> GSI 23 (level, low) -> IRQ 225


    Please provide lspci -nnvvxxx and full dmesg with this use case.
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  13. Re: sharing interrupt between PCI device

    On Wed, Nov 05, 2008 at 01:19:29PM +0530, Nobin Mathew wrote:
    > Hi
    >
    > This is the system information X86_64 platform Xeon dual core processor.
    >
    > I saw the pci_disable_device () it is calling pcibios_disable_device
    > () and this is is defined as
    >
    > void pcibios_disable_device (struct pci_dev *dev)
    > {
    > pcibios_disable_resources(dev);
    > if (pcibios_disable_irq)
    > pcibios_disable_irq(dev);
    > }
    >
    > In i386 platform, I could not find a definition for these calls in
    > x86_64 platform, i think it is using i386 platform code.


    cscope would have helped you out here.
    See arch/x86/pci/acpi.c:

    int __init pci_acpi_init(void)
    {
    ....
    pcibios_enable_irq = acpi_pci_irq_enable;
    pcibios_disable_irq = acpi_pci_irq_disable;
    ....
    }

    So I see how the IRQ is enabled and disabled. I still don't see where
    an interrupt handler is bound to IRQ 225 (output you posted today in
    another email). Nobin, can you dump /proc/interrupts when both drivers
    are loaded and also send the dmesg output after both are loaded?

    The "lspci" output Jiri asked for would be very helpful too.

    thanks,
    grant

    >
    > Thanks
    > Nobin Mathew
    >
    >
    >
    >
    >
    > On Wed, Nov 5, 2008 at 5:58 AM, Robert Han**** wrote:
    > > Nobin Mathew wrote:
    > >>
    > >> Hi,
    > >>
    > >> I think this question is already asked in this mailing list and Sorry
    > >> for asking this again.
    > >>
    > >> My problem is this:
    > >>
    > >> I have two PCI devices ( also two kernel drivers for those) which
    > >> shares the interupt. When I remove one driver other device stops
    > >> working, which is happening due to pci_disable_device () in removed
    > >> driver. This call is disabling the shared interrupt.

    > >
    > > pci_disable_device shouldn't be disabling the interrupt line, at least not
    > > in this case. Without more details on the platform or drivers, it's
    > > difficult to say why this would happen.
    > >
    > >>
    > >> We can avoid this by just removing the pci_disable_device () in the
    > >> driver, but i dont think this is a good way (correct me if I am
    > >> wrong).
    > >>
    > >> Can you suggest some ways to overcome this issue.

    > >
    > >

    > --
    > To unsubscribe from this list: send the line "unsubscribe linux-pci" in
    > the body of a message to majordomo@vger.kernel.org
    > More majordomo info at http://vger.kernel.org/majordomo-info.html

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

  14. Re: sharing interrupt between PCI device

    On Sat, Nov 08, 2008 at 08:10:54PM +0100, Jiri Slaby wrote:
    > Grant Grundler napsal(a):
    > > So I see how the IRQ is enabled and disabled. I still don't see where
    > > an interrupt handler is bound to IRQ 225 (output you posted today in
    > > another email).

    >
    > This irq setup is done during pci_enable_device.


    Sorry, I wasn't quite correct: pci_enable_device() should only assign IRQs,
    not enable them. request_irq() would enable them.

    > > Nobin, can you dump /proc/interrupts when both drivers
    > > are loaded and also send the dmesg output after both are loaded?

    >
    > This won't show the hp driver as it doesn't request_irq.


    Yup - that's what I expect too. But I was afraid something else might
    be calling request_irq() and I'm just not seeing it.

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

  15. Re: sharing interrupt between PCI device

    Grant Grundler napsal(a):
    > So I see how the IRQ is enabled and disabled. I still don't see where
    > an interrupt handler is bound to IRQ 225 (output you posted today in
    > another email).


    This irq setup is done during pci_enable_device.

    > Nobin, can you dump /proc/interrupts when both drivers
    > are loaded and also send the dmesg output after both are loaded?


    This won't show the hp driver as it doesn't request_irq.
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  16. Re: sharing interrupt between PCI device

    lspci -vs 1:4 is taken before inserting the drivers.

    Thanks

    On Mon, Nov 10, 2008 at 12:05 PM, Nobin Mathew wrote:
    > lspci output
    >
    > [root@localhost ~]# lspci -vs 1:4
    > 01:04.0 System peripheral: Compaq Computer Corporation Integrated
    > Lights Out Controller (rev 03)
    > Subsystem: Hewlett-Packard Company Unknown device 3305
    > Flags: medium devsel, IRQ 11
    > I/O ports at 2800 [size=256]
    > Memory at fdee0000 (32-bit, non-prefetchable) [size=512]
    > Capabilities: [f0] Power Management version 3
    >
    > 01:04.2 System peripheral: Compaq Computer Corporation Integrated
    > Lights Out Processor (rev 03)
    > Subsystem: Hewlett-Packard Company Unknown device 3305
    > Flags: medium devsel, IRQ 225
    > BIST result: 00
    > I/O ports at 1400 [disabled] [size=256]
    > Memory at fded0000 (32-bit, non-prefetchable) [disabled] [size=2K]
    > Memory at fdec0000 (32-bit, non-prefetchable) [disabled] [size=8K]
    > Memory at fde00000 (32-bit, non-prefetchable) [disabled] [size=512K]
    > [virtual] Expansion ROM at fdd20000 [disabled] [size=64K]
    > Capabilities: [f0] Power Management version 3
    >
    > 01:04.4 USB Controller: Hewlett-Packard Company Proliant iLO2 virtual
    > USB controller (prog-if 00 [UHCI])
    > Subsystem: Hewlett-Packard Company Unknown device 3305
    > Flags: medium devsel, IRQ 225
    > I/O ports at 1800 [disabled] [size=32]
    > Capabilities: [f0] Power Management version 3
    >
    > 01:04.6 IPMI SMIC interface: Hewlett-Packard Company Proliant iLO2
    > virtual UART (prog-if 01)
    > Subsystem: Hewlett-Packard Company Unknown device 3305
    > Flags: medium devsel, IRQ 50
    > Memory at fddf0000 (32-bit, non-prefetchable) [size=256]
    > Capabilities: [f0] Power Management version 3
    >
    > dmesg messages and /proc/interupts are attached.
    >
    >
    > command sequence just for reference
    >
    > insmod hpilo
    > insmod uhci_hcd
    > cat /proc/interrupts
    > dmesg
    > rmmod hpilo
    > rmmod uhci_hcd
    > dmesg
    >
    > Thanks
    > Nobin Mathew
    >
    > On Sun, Nov 9, 2008 at 12:45 AM, Grant Grundler
    > wrote:
    >> On Sat, Nov 08, 2008 at 08:10:54PM +0100, Jiri Slaby wrote:
    >>> Grant Grundler napsal(a):
    >>> > So I see how the IRQ is enabled and disabled. I still don't see where
    >>> > an interrupt handler is bound to IRQ 225 (output you posted today in
    >>> > another email).
    >>>
    >>> This irq setup is done during pci_enable_device.

    >>
    >> Sorry, I wasn't quite correct: pci_enable_device() should only assign IRQs,
    >> not enable them. request_irq() would enable them.
    >>
    >>> > Nobin, can you dump /proc/interrupts when both drivers
    >>> > are loaded and also send the dmesg output after both are loaded?
    >>>
    >>> This won't show the hp driver as it doesn't request_irq.

    >>
    >> Yup - that's what I expect too. But I was afraid something else might
    >> be calling request_irq() and I'm just not seeing it.
    >>
    >> grant
    >>

    >

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

  17. Re: sharing interrupt between PCI device

    lspci output

    [root@localhost ~]# lspci -vs 1:4
    01:04.0 System peripheral: Compaq Computer Corporation Integrated
    Lights Out Controller (rev 03)
    Subsystem: Hewlett-Packard Company Unknown device 3305
    Flags: medium devsel, IRQ 11
    I/O ports at 2800 [size=256]
    Memory at fdee0000 (32-bit, non-prefetchable) [size=512]
    Capabilities: [f0] Power Management version 3

    01:04.2 System peripheral: Compaq Computer Corporation Integrated
    Lights Out Processor (rev 03)
    Subsystem: Hewlett-Packard Company Unknown device 3305
    Flags: medium devsel, IRQ 225
    BIST result: 00
    I/O ports at 1400 [disabled] [size=256]
    Memory at fded0000 (32-bit, non-prefetchable) [disabled] [size=2K]
    Memory at fdec0000 (32-bit, non-prefetchable) [disabled] [size=8K]
    Memory at fde00000 (32-bit, non-prefetchable) [disabled] [size=512K]
    [virtual] Expansion ROM at fdd20000 [disabled] [size=64K]
    Capabilities: [f0] Power Management version 3

    01:04.4 USB Controller: Hewlett-Packard Company Proliant iLO2 virtual
    USB controller (prog-if 00 [UHCI])
    Subsystem: Hewlett-Packard Company Unknown device 3305
    Flags: medium devsel, IRQ 225
    I/O ports at 1800 [disabled] [size=32]
    Capabilities: [f0] Power Management version 3

    01:04.6 IPMI SMIC interface: Hewlett-Packard Company Proliant iLO2
    virtual UART (prog-if 01)
    Subsystem: Hewlett-Packard Company Unknown device 3305
    Flags: medium devsel, IRQ 50
    Memory at fddf0000 (32-bit, non-prefetchable) [size=256]
    Capabilities: [f0] Power Management version 3

    dmesg messages and /proc/interupts are attached.


    command sequence just for reference

    insmod hpilo
    insmod uhci_hcd
    cat /proc/interrupts
    dmesg
    rmmod hpilo
    rmmod uhci_hcd
    dmesg

    Thanks
    Nobin Mathew

    On Sun, Nov 9, 2008 at 12:45 AM, Grant Grundler
    wrote:
    > On Sat, Nov 08, 2008 at 08:10:54PM +0100, Jiri Slaby wrote:
    >> Grant Grundler napsal(a):
    >> > So I see how the IRQ is enabled and disabled. I still don't see where
    >> > an interrupt handler is bound to IRQ 225 (output you posted today in
    >> > another email).

    >>
    >> This irq setup is done during pci_enable_device.

    >
    > Sorry, I wasn't quite correct: pci_enable_device() should only assign IRQs,
    > not enable them. request_irq() would enable them.
    >
    >> > Nobin, can you dump /proc/interrupts when both drivers
    >> > are loaded and also send the dmesg output after both are loaded?

    >>
    >> This won't show the hp driver as it doesn't request_irq.

    >
    > Yup - that's what I expect too. But I was afraid something else might
    > be calling request_irq() and I'm just not seeing it.
    >
    > grant
    >



  18. Re: sharing interrupt between PCI device

    Version of the running kernel 2.6.18-92.el5.

    Thanks

    On Mon, Nov 10, 2008 at 12:09 PM, Nobin Mathew wrote:
    > lspci -vs 1:4 is taken before inserting the drivers.
    >
    > Thanks
    >
    > On Mon, Nov 10, 2008 at 12:05 PM, Nobin Mathew wrote:
    >> lspci output
    >>
    >> [root@localhost ~]# lspci -vs 1:4
    >> 01:04.0 System peripheral: Compaq Computer Corporation Integrated
    >> Lights Out Controller (rev 03)
    >> Subsystem: Hewlett-Packard Company Unknown device 3305
    >> Flags: medium devsel, IRQ 11
    >> I/O ports at 2800 [size=256]
    >> Memory at fdee0000 (32-bit, non-prefetchable) [size=512]
    >> Capabilities: [f0] Power Management version 3
    >>
    >> 01:04.2 System peripheral: Compaq Computer Corporation Integrated
    >> Lights Out Processor (rev 03)
    >> Subsystem: Hewlett-Packard Company Unknown device 3305
    >> Flags: medium devsel, IRQ 225
    >> BIST result: 00
    >> I/O ports at 1400 [disabled] [size=256]
    >> Memory at fded0000 (32-bit, non-prefetchable) [disabled] [size=2K]
    >> Memory at fdec0000 (32-bit, non-prefetchable) [disabled] [size=8K]
    >> Memory at fde00000 (32-bit, non-prefetchable) [disabled] [size=512K]
    >> [virtual] Expansion ROM at fdd20000 [disabled] [size=64K]
    >> Capabilities: [f0] Power Management version 3
    >>
    >> 01:04.4 USB Controller: Hewlett-Packard Company Proliant iLO2 virtual
    >> USB controller (prog-if 00 [UHCI])
    >> Subsystem: Hewlett-Packard Company Unknown device 3305
    >> Flags: medium devsel, IRQ 225
    >> I/O ports at 1800 [disabled] [size=32]
    >> Capabilities: [f0] Power Management version 3
    >>
    >> 01:04.6 IPMI SMIC interface: Hewlett-Packard Company Proliant iLO2
    >> virtual UART (prog-if 01)
    >> Subsystem: Hewlett-Packard Company Unknown device 3305
    >> Flags: medium devsel, IRQ 50
    >> Memory at fddf0000 (32-bit, non-prefetchable) [size=256]
    >> Capabilities: [f0] Power Management version 3
    >>
    >> dmesg messages and /proc/interupts are attached.
    >>
    >>
    >> command sequence just for reference
    >>
    >> insmod hpilo
    >> insmod uhci_hcd
    >> cat /proc/interrupts
    >> dmesg
    >> rmmod hpilo
    >> rmmod uhci_hcd
    >> dmesg
    >>
    >> Thanks
    >> Nobin Mathew
    >>
    >> On Sun, Nov 9, 2008 at 12:45 AM, Grant Grundler
    >> wrote:
    >>> On Sat, Nov 08, 2008 at 08:10:54PM +0100, Jiri Slaby wrote:
    >>>> Grant Grundler napsal(a):
    >>>> > So I see how the IRQ is enabled and disabled. I still don't see where
    >>>> > an interrupt handler is bound to IRQ 225 (output you posted today in
    >>>> > another email).
    >>>>
    >>>> This irq setup is done during pci_enable_device.
    >>>
    >>> Sorry, I wasn't quite correct: pci_enable_device() should only assign IRQs,
    >>> not enable them. request_irq() would enable them.
    >>>
    >>>> > Nobin, can you dump /proc/interrupts when both drivers
    >>>> > are loaded and also send the dmesg output after both are loaded?
    >>>>
    >>>> This won't show the hp driver as it doesn't request_irq.
    >>>
    >>> Yup - that's what I expect too. But I was afraid something else might
    >>> be calling request_irq() and I'm just not seeing it.
    >>>
    >>> grant
    >>>

    >>

    >

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

  19. Re: sharing interrupt between PCI device


    * Grant Grundler wrote:

    > [+ingo - question for you about disable_irq() below]


    > The same problem exists with disable_irq() : only takes a global
    > IRQ# and no additional identifying information to prevent disabling
    > a shared IRQ. So I'm not sure if this is a bug with ACPI or design
    > flaw in generic IRQ APIs. Ingo?


    that's how disable_irq() always worked: it disables all handlers on
    that IRQ#. If the IRQ# is shared, it disables all handlers.

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

  20. Re: sharing interrupt between PCI device

    [+ingo - question for you about disable_irq() below]

    On Mon, Nov 10, 2008 at 12:05:59PM +0530, Nobin Mathew wrote:
    > lspci output
    >
    > [root@localhost ~]# lspci -vs 1:4
    > 01:04.0 System peripheral: Compaq Computer Corporation Integrated
    > Lights Out Controller (rev 03)
    > Subsystem: Hewlett-Packard Company Unknown device 3305
    > Flags: medium devsel, IRQ 11
    > I/O ports at 2800 [size=256]
    > Memory at fdee0000 (32-bit, non-prefetchable) [size=512]
    > Capabilities: [f0] Power Management version 3
    >
    > 01:04.2 System peripheral: Compaq Computer Corporation Integrated
    > Lights Out Processor (rev 03)
    > Subsystem: Hewlett-Packard Company Unknown device 3305
    > Flags: medium devsel, IRQ 225
    > BIST result: 00
    > I/O ports at 1400 [disabled] [size=256]
    > Memory at fded0000 (32-bit, non-prefetchable) [disabled] [size=2K]
    > Memory at fdec0000 (32-bit, non-prefetchable) [disabled] [size=8K]
    > Memory at fde00000 (32-bit, non-prefetchable) [disabled] [size=512K]
    > [virtual] Expansion ROM at fdd20000 [disabled] [size=64K]
    > Capabilities: [f0] Power Management version 3
    >
    > 01:04.4 USB Controller: Hewlett-Packard Company Proliant iLO2 virtual
    > USB controller (prog-if 00 [UHCI])
    > Subsystem: Hewlett-Packard Company Unknown device 3305
    > Flags: medium devsel, IRQ 225
    > I/O ports at 1800 [disabled] [size=32]
    > Capabilities: [f0] Power Management version 3


    Is this the USB controller that stops working?

    The multi-function device makes me suspicious even if it's not the problem.
    If rmmod of the "virtual USB" controller driver happens to disable
    the IRQ for the entire device, I would consider this a bug in either the
    device design or device firmware. But this probably isn't the case.

    Interesting part of dmesg_all_in (name was typo'd in original attachment):
    PCI: Enabling device 0000:01:04.2 (0114 -> 0117)
    ACPI: PCI Interrupt 0000:01:04.2[B] -> GSI 23 (level, low) -> IRQ 225
    USB Universal Host Controller Interface driver v3.0
    ....
    PCI: Enabling device 0000:01:04.4 (0140 -> 0141)
    ACPI: PCI Interrupt 0000:01:04.4[B] -> GSI 23 (level, low) -> IRQ 225
    uhci_hcd 0000:01:04.4: UHCI Host Controller
    uhci_hcd 0000:01:04.4: new USB bus registered, assigned bus number 6
    uhci_hcd 0000:01:04.4: port count misdetected? forcing to 2 ports
    uhci_hcd 0000:01:04.4: irq 225, io base 0x00001800
    ....

    So it was enabled twice.
    And /proc/interrupts shows only on ISR registered:
    225: 99 102 IO-APIC-level uhci_hcd:usb6

    Ie this IRQ isn't really shared. At least the shared device hasn't
    registered an interrupt handler.

    And as expected, after the rmmod, dmesg shows:
    ACPI: PCI interrupt for device 0000:01:04.2 disabled
    ....


    So I think your original statement is probably right.
    Since the hpilo driver never registered an interrupt handler, it's
    probably polling the device (maybe via user space) and would not
    be affected by rmmod'ing the USB driver. But the converse is not true.

    This initially seems to be an ACPI bug. It's calling acpi_unregister_gsi()
    without checking if this GSI is shared with another device.
    Which then calls iosapic_unregister_intr(gsi) and we can no longer determine
    which device asked for the IRQ to be disabled.

    The same problem exists with disable_irq() : only takes a global
    IRQ# and no additional identifying information to prevent disabling
    a shared IRQ. So I'm not sure if this is a bug with ACPI or design
    flaw in generic IRQ APIs. Ingo?

    hth,
    grant

    > 01:04.6 IPMI SMIC interface: Hewlett-Packard Company Proliant iLO2
    > virtual UART (prog-if 01)
    > Subsystem: Hewlett-Packard Company Unknown device 3305
    > Flags: medium devsel, IRQ 50
    > Memory at fddf0000 (32-bit, non-prefetchable) [size=256]
    > Capabilities: [f0] Power Management version 3
    >


    > dmesg messages and /proc/interupts are attached.
    >
    >
    > command sequence just for reference
    >
    > insmod hpilo
    > insmod uhci_hcd
    > cat /proc/interrupts
    > dmesg
    > rmmod hpilo
    > rmmod uhci_hcd
    > dmesg
    >
    > Thanks
    > Nobin Mathew
    >
    > On Sun, Nov 9, 2008 at 12:45 AM, Grant Grundler
    > wrote:
    > > On Sat, Nov 08, 2008 at 08:10:54PM +0100, Jiri Slaby wrote:
    > >> Grant Grundler napsal(a):
    > >> > So I see how the IRQ is enabled and disabled. I still don't see where
    > >> > an interrupt handler is bound to IRQ 225 (output you posted today in
    > >> > another email).
    > >>
    > >> This irq setup is done during pci_enable_device.

    > >
    > > Sorry, I wasn't quite correct: pci_enable_device() should only assign IRQs,
    > > not enable them. request_irq() would enable them.
    > >
    > >> > Nobin, can you dump /proc/interrupts when both drivers
    > >> > are loaded and also send the dmesg output after both are loaded?
    > >>
    > >> This won't show the hp driver as it doesn't request_irq.

    > >
    > > Yup - that's what I expect too. But I was afraid something else might
    > > be calling request_irq() and I'm just not seeing it.
    > >
    > > grant
    > >


    > PCI: Enabling device 0000:01:04.2 (0114 -> 0117)
    > ACPI: PCI Interrupt 0000:01:04.2[B] -> GSI 23 (level, low) -> IRQ 225
    > USB Universal Host Controller Interface driver v3.0
    > PCI: Enabling device 0000:00:1d.0 (0000 -> 0001)
    > ACPI: PCI Interrupt 0000:00:1d.0[A] -> GSI 21 (level, low) -> IRQ 217
    > PCI: Setting latency timer of device 0000:00:1d.0 to 64
    > uhci_hcd 0000:00:1d.0: UHCI Host Controller
    > uhci_hcd 0000:00:1d.0: new USB bus registered, assigned bus number 2
    > uhci_hcd 0000:00:1d.0: irq 217, io base 0x00003000
    > usb usb2: configuration #1 chosen from 1 choice
    > hub 2-0:1.0: USB hub found
    > hub 2-0:1.0: 2 ports detected
    > PCI: Enabling device 0000:00:1d.1 (0000 -> 0001)
    > ACPI: PCI Interrupt 0000:00:1d.1[B] -> GSI 21 (level, low) -> IRQ 217
    > PCI: Setting latency timer of device 0000:00:1d.1 to 64
    > uhci_hcd 0000:00:1d.1: UHCI Host Controller
    > uhci_hcd 0000:00:1d.1: new USB bus registered, assigned bus number 3
    > uhci_hcd 0000:00:1d.1: irq 217, io base 0x00003020
    > usb usb3: configuration #1 chosen from 1 choice
    > hub 3-0:1.0: USB hub found
    > hub 3-0:1.0: 2 ports detected
    > PCI: Enabling device 0000:00:1d.2 (0000 -> 0001)
    > ACPI: PCI Interrupt 0000:00:1d.2[C] -> GSI 21 (level, low) -> IRQ 217
    > PCI: Setting latency timer of device 0000:00:1d.2 to 64
    > uhci_hcd 0000:00:1d.2: UHCI Host Controller
    > uhci_hcd 0000:00:1d.2: new USB bus registered, assigned bus number 4
    > uhci_hcd 0000:00:1d.2: irq 217, io base 0x00003040
    > usb usb4: configuration #1 chosen from 1 choice
    > hub 4-0:1.0: USB hub found
    > hub 4-0:1.0: 2 ports detected
    > PCI: Enabling device 0000:00:1d.3 (0000 -> 0001)
    > ACPI: PCI Interrupt 0000:00:1d.3[D] -> GSI 21 (level, low) -> IRQ 217
    > PCI: Setting latency timer of device 0000:00:1d.3 to 64
    > uhci_hcd 0000:00:1d.3: UHCI Host Controller
    > uhci_hcd 0000:00:1d.3: new USB bus registered, assigned bus number 5
    > uhci_hcd 0000:00:1d.3: irq 217, io base 0x00003060
    > usb usb5: configuration #1 chosen from 1 choice
    > hub 5-0:1.0: USB hub found
    > hub 5-0:1.0: 2 ports detected
    > PCI: Enabling device 0000:01:04.4 (0140 -> 0141)
    > ACPI: PCI Interrupt 0000:01:04.4[B] -> GSI 23 (level, low) -> IRQ 225
    > uhci_hcd 0000:01:04.4: UHCI Host Controller
    > uhci_hcd 0000:01:04.4: new USB bus registered, assigned bus number 6
    > uhci_hcd 0000:01:04.4: port count misdetected? forcing to 2 ports
    > uhci_hcd 0000:01:04.4: irq 225, io base 0x00001800
    > usb usb6: configuration #1 chosen from 1 choice
    > hub 6-0:1.0: USB hub found
    > hub 6-0:1.0: 2 ports detected
    > usb 6-1: new full speed USB device using uhci_hcd and address 2
    > usb 6-1: configuration #1 chosen from 1 choice
    > input: HP Virtual Keyboard as /class/input/input5
    > input: USB HID v1.01 Keyboard [HP Virtual Keyboard] on usb-0000:01:04.4-1
    > input: HP Virtual Keyboard as /class/input/input6
    > input: USB HID v1.01 Mouse [HP Virtual Keyboard] on usb-0000:01:04.4-1
    > usb 6-2: new full speed USB device using uhci_hcd and address 3
    > usb 6-2: configuration #1 chosen from 1 choice
    > hub 6-2:1.0: USB hub found
    > hub 6-2:1.0: 7 ports detected


    > CPU0 CPU1
    > 0: 237187 0 IO-APIC-edge timer
    > 1: 695 0 IO-APIC-edge i8042
    > 7: 0 0 IO-APIC-edge parport0
    > 8: 1 0 IO-APIC-edge rtc
    > 9: 0 0 IO-APIC-level acpi
    > 12: 115 3923 IO-APIC-edge i8042
    > 14: 92 1636 IO-APIC-edge ide0
    > 50: 431 1339 IO-APIC-level ipmi_si
    > 169: 434 6421 IO-APIC-level eth0
    > 217: 0 0 IO-APIC-level ehci_hcd:usb1, uhci_hcd:usb2, uhci_hcd:usb3, uhci_hcd:usb4, uhci_hcd:usb5
    > 225: 99 102 IO-APIC-level uhci_hcd:usb6
    > 233: 5633 15459 IO-APIC-level libata
    > NMI: 0 0
    > LOC: 237016 236962
    > ERR: 0
    > MIS: 0


    > PCI: Enabling device 0000:01:04.2 (0114 -> 0117)
    > ACPI: PCI Interrupt 0000:01:04.2[B] -> GSI 23 (level, low) -> IRQ 225
    > USB Universal Host Controller Interface driver v3.0
    > PCI: Enabling device 0000:00:1d.0 (0000 -> 0001)
    > ACPI: PCI Interrupt 0000:00:1d.0[A] -> GSI 21 (level, low) -> IRQ 217
    > PCI: Setting latency timer of device 0000:00:1d.0 to 64
    > uhci_hcd 0000:00:1d.0: UHCI Host Controller
    > uhci_hcd 0000:00:1d.0: new USB bus registered, assigned bus number 2
    > uhci_hcd 0000:00:1d.0: irq 217, io base 0x00003000
    > usb usb2: configuration #1 chosen from 1 choice
    > hub 2-0:1.0: USB hub found
    > hub 2-0:1.0: 2 ports detected
    > PCI: Enabling device 0000:00:1d.1 (0000 -> 0001)
    > ACPI: PCI Interrupt 0000:00:1d.1[B] -> GSI 21 (level, low) -> IRQ 217
    > PCI: Setting latency timer of device 0000:00:1d.1 to 64
    > uhci_hcd 0000:00:1d.1: UHCI Host Controller
    > uhci_hcd 0000:00:1d.1: new USB bus registered, assigned bus number 3
    > uhci_hcd 0000:00:1d.1: irq 217, io base 0x00003020
    > usb usb3: configuration #1 chosen from 1 choice
    > hub 3-0:1.0: USB hub found
    > hub 3-0:1.0: 2 ports detected
    > PCI: Enabling device 0000:00:1d.2 (0000 -> 0001)
    > ACPI: PCI Interrupt 0000:00:1d.2[C] -> GSI 21 (level, low) -> IRQ 217
    > PCI: Setting latency timer of device 0000:00:1d.2 to 64
    > uhci_hcd 0000:00:1d.2: UHCI Host Controller
    > uhci_hcd 0000:00:1d.2: new USB bus registered, assigned bus number 4
    > uhci_hcd 0000:00:1d.2: irq 217, io base 0x00003040
    > usb usb4: configuration #1 chosen from 1 choice
    > hub 4-0:1.0: USB hub found
    > hub 4-0:1.0: 2 ports detected
    > PCI: Enabling device 0000:00:1d.3 (0000 -> 0001)
    > ACPI: PCI Interrupt 0000:00:1d.3[D] -> GSI 21 (level, low) -> IRQ 217
    > PCI: Setting latency timer of device 0000:00:1d.3 to 64
    > uhci_hcd 0000:00:1d.3: UHCI Host Controller
    > uhci_hcd 0000:00:1d.3: new USB bus registered, assigned bus number 5
    > uhci_hcd 0000:00:1d.3: irq 217, io base 0x00003060
    > usb usb5: configuration #1 chosen from 1 choice
    > hub 5-0:1.0: USB hub found
    > hub 5-0:1.0: 2 ports detected
    > PCI: Enabling device 0000:01:04.4 (0140 -> 0141)
    > ACPI: PCI Interrupt 0000:01:04.4[B] -> GSI 23 (level, low) -> IRQ 225
    > uhci_hcd 0000:01:04.4: UHCI Host Controller
    > uhci_hcd 0000:01:04.4: new USB bus registered, assigned bus number 6
    > uhci_hcd 0000:01:04.4: port count misdetected? forcing to 2 ports
    > uhci_hcd 0000:01:04.4: irq 225, io base 0x00001800
    > usb usb6: configuration #1 chosen from 1 choice
    > hub 6-0:1.0: USB hub found
    > hub 6-0:1.0: 2 ports detected
    > usb 6-1: new full speed USB device using uhci_hcd and address 2
    > usb 6-1: configuration #1 chosen from 1 choice
    > input: HP Virtual Keyboard as /class/input/input5
    > input: USB HID v1.01 Keyboard [HP Virtual Keyboard] on usb-0000:01:04.4-1
    > input: HP Virtual Keyboard as /class/input/input6
    > input: USB HID v1.01 Mouse [HP Virtual Keyboard] on usb-0000:01:04.4-1
    > usb 6-2: new full speed USB device using uhci_hcd and address 3
    > usb 6-2: configuration #1 chosen from 1 choice
    > hub 6-2:1.0: USB hub found
    > hub 6-2:1.0: 7 ports detected
    > ACPI: PCI interrupt for device 0000:01:04.2 disabled
    > uhci_hcd 0000:01:04.4: remove, state 1
    > usb usb6: USB disconnect, address 1
    > usb 6-1: USB disconnect, address 2
    > usb 6-2: USB disconnect, address 3
    > uhci_hcd 0000:01:04.4: USB bus 6 deregistered
    > ACPI: PCI interrupt for device 0000:01:04.4 disabled
    > uhci_hcd 0000:00:1d.3: remove, state 1
    > usb usb5: USB disconnect, address 1
    > uhci_hcd 0000:00:1d.3: USB bus 5 deregistered
    > ACPI: PCI interrupt for device 0000:00:1d.3 disabled
    > uhci_hcd 0000:00:1d.2: remove, state 1
    > usb usb4: USB disconnect, address 1
    > uhci_hcd 0000:00:1d.2: USB bus 4 deregistered
    > ACPI: PCI interrupt for device 0000:00:1d.2 disabled
    > uhci_hcd 0000:00:1d.1: remove, state 1
    > usb usb3: USB disconnect, address 1
    > uhci_hcd 0000:00:1d.1: USB bus 3 deregistered
    > ACPI: PCI interrupt for device 0000:00:1d.1 disabled
    > uhci_hcd 0000:00:1d.0: remove, state 1
    > usb usb2: USB disconnect, address 1
    > uhci_hcd 0000:00:1d.0: USB bus 2 deregistered
    > ACPI: PCI interrupt for device 0000:00:1d.0 disabled


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

+ Reply to Thread
Page 1 of 2 1 2 LastLast