Re: sharing interrupt between PCI device

Re: sharing interrupt between PCI device

[Robert Hancock]

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.

Re: sharing interrupt between PCI device

[Nobin Mathew]

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 Hancock <hancockr@shaw.ca> 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.
>
>

Re: sharing interrupt between PCI device

[Jiri Slaby]

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

Re: sharing interrupt between PCI device

[Nobin Mathew]

Hi


Code is here
first one USB Virual input devices

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

Second one is hp-ilo driver

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


Thanks
Nobin Mathew.


On Wed, Nov 5, 2008 at 2:06 PM, Jiri Slaby <jirislaby@gmail.com> 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...
>

Re: sharing interrupt between PCI device

[Nobin Mathew]

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 <nobin.mathew@gmail.com> wrote:
> Hi
>
>
> Code is here
> first one USB Virual input devices
>
> http://lxr.linux.no/linux+v2.6.27.4/drivers/usb/core/hcd-pci.c
>
> Second one is hp-ilo driver
>
> http://lxr.linux.no/linux+v2.6.27.4/drivers/misc/hpilo.c
>
>
> Thanks
> Nobin Mathew.
>
>
> On Wed, Nov 5, 2008 at 2:06 PM, Jiri Slaby <jirislaby@gmail.com> 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...
>>
>

Re: sharing interrupt between PCI device

[Nobin Mathew]

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 <nobin.mathew@gmail.com> 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 <nobin.mathew@gmail.com> wrote:
>> Hi
>>
>>
>> Code is here
>> first one USB Virual input devices
>>
>> http://lxr.linux.no/linux+v2.6.27.4/drivers/usb/core/hcd-pci.c
>>
>> Second one is hp-ilo driver
>>
>> http://lxr.linux.no/linux+v2.6.27.4/drivers/misc/hpilo.c
>>
>>
>> Thanks
>> Nobin Mathew.
>>
>>
>> On Wed, Nov 5, 2008 at 2:06 PM, Jiri Slaby <jirislaby@gmail.com> 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...
>>>
>>
>

Re: sharing interrupt between PCI device

[Jiri Slaby]

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?

Re: sharing interrupt between PCI device

[Nobin Mathew]

Exactly

On Fri, Nov 7, 2008 at 2:54 AM, Jiri Slaby <jirislaby@gmail.com> 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?
>

Re: sharing interrupt between PCI device

[Grant Grundler]

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/drivers/usb/core/hcd-pci.c
> 
> Second one is hp-ilo driver
> 
> http://lxr.linux.no/linux+v2.6.27.4/drivers/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 <jirislaby@gmail.com> 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

Re: sharing interrupt between PCI device

[Jiri Slaby]

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/drivers/usb/core/hcd-pci.c
>>
>> Second one is hp-ilo driver
>>
>> http://lxr.linux.no/linux+v2.6.27.4/drivers/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.

Re: sharing interrupt between PCI device

[Nobin Mathew]

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 <jirislaby@gmail.com> 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/drivers/usb/core/hcd-pci.c
>>>
>>> Second one is hp-ilo driver
>>>
>>> http://lxr.linux.no/linux+v2.6.27.4/drivers/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.
>

Re: sharing interrupt between PCI device

[Jiri Slaby]

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.

Re: sharing interrupt between PCI device

[Grant Grundler]

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 Hancock <hancockr@shaw.ca> 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

Re: sharing interrupt between PCI device

[Jiri Slaby]

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.

Re: sharing interrupt between PCI device

[Grant Grundler]

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

Re: sharing interrupt between PCI device

[Nobin Mathew]

[-- Attachment #1: Type: text/plain, Size: 2710 bytes --]

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
<grundler@parisc-linux.org> 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
>

[-- Attachment #2: demsg_all_in --]
[-- Type: text/plain, Size: 2925 bytes --]

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

[-- Attachment #3: interrupts_out --]
[-- Type: text/plain, Size: 799 bytes --]

           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

[-- Attachment #4: demsg_all_out --]
[-- Type: text/plain, Size: 3918 bytes --]

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

Re: sharing interrupt between PCI device

[Nobin Mathew]

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

Thanks

On Mon, Nov 10, 2008 at 12:05 PM, Nobin Mathew <nobin.mathew@gmail.com> 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
> <grundler@parisc-linux.org> 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
>>
>

Re: sharing interrupt between PCI device

[Nobin Mathew]

Version of the running kernel 2.6.18-92.el5.

Thanks

On Mon, Nov 10, 2008 at 12:09 PM, Nobin Mathew <nobin.mathew@gmail.com> wrote:
> lspci -vs 1:4 is taken before inserting the drivers.
>
> Thanks
>
> On Mon, Nov 10, 2008 at 12:05 PM, Nobin Mathew <nobin.mathew@gmail.com> 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
>> <grundler@parisc-linux.org> 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
>>>
>>
>

Re: sharing interrupt between PCI device

[Grant Grundler]

[+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
> <grundler@parisc-linux.org> 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

Re: sharing interrupt between PCI device

[Ingo Molnar]

* Grant Grundler <grundler@parisc-linux.org> 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

Re: sharing interrupt between PCI device

[Nobin Mathew]

Yes USB Virtual Controller has input devices like keyboard and mouse
(routed through hpilo card (remote console)), so those things stops
working when we remove hpilo driver.

Thanks
Nobin Mathew

On Mon, Nov 10, 2008 at 1:28 PM, Ingo Molnar <mingo@elte.hu> wrote:
>
> * Grant Grundler <grundler@parisc-linux.org> 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
>

Re: sharing interrupt between PCI device

[Nobin Mathew]

I could not find the definition of acpi_unregister_gsi in i386/x86_64
code, it is defined only for ia64.

Since it is defined as a weak symbol, I feel it is not getting called
(correct if I am wrong, I searched in google for this).

/* FIXME: implement x86/x86_64 version */
void __attribute__ ((weak)) acpi_unregister_gsi(u32 i)
{
}

How this weak symbols work, is it something like
acpi_pci_irq_disable() will not call acpi_unregister_gsi() in some
platforms.

Thanks
Nobin Mathew.

On Mon, Nov 10, 2008 at 4:01 PM, Nobin Mathew <nobin.mathew@gmail.com> wrote:
> Yes USB Virtual Controller has input devices like keyboard and mouse
> (routed through hpilo card (remote console)), so those things stops
> working when we remove hpilo driver.
>
> Thanks
> Nobin Mathew
>
> On Mon, Nov 10, 2008 at 1:28 PM, Ingo Molnar <mingo@elte.hu> wrote:
>>
>> * Grant Grundler <grundler@parisc-linux.org> 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
>>
>

Re: sharing interrupt between PCI device

[Grant Grundler]

On Mon, Nov 10, 2008 at 08:58:27AM +0100, Ingo Molnar wrote:
> 
> * Grant Grundler <grundler@parisc-linux.org> 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,
Sorry - my question really was: given the above, should
pcibios_disable_device() be calling pcibios_disable_irq()?

Right now, I think not.

thanks,
grant

> 
> 	Ingo
> --
> 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

Re: sharing interrupt between PCI device

[Grant Grundler]

On Mon, Nov 10, 2008 at 09:12:05PM +0530, Nobin Mathew wrote:
> I could not find the definition of acpi_unregister_gsi in i386/x86_64
> code, it is defined only for ia64.

Sorry - I was looking at the ia64 branch by mistake.

> 
> Since it is defined as a weak symbol, I feel it is not getting called
> (correct if I am wrong, I searched in google for this).

You are right.

sorry,
grant

> /* FIXME: implement x86/x86_64 version */
> void __attribute__ ((weak)) acpi_unregister_gsi(u32 i)
> {
> }
> 
> How this weak symbols work, is it something like
> acpi_pci_irq_disable() will not call acpi_unregister_gsi() in some
> platforms.
> 
> Thanks
> Nobin Mathew.
> 
> On Mon, Nov 10, 2008 at 4:01 PM, Nobin Mathew <nobin.mathew@gmail.com> wrote:
> > Yes USB Virtual Controller has input devices like keyboard and mouse
> > (routed through hpilo card (remote console)), so those things stops
> > working when we remove hpilo driver.
> >
> > Thanks
> > Nobin Mathew
> >
> > On Mon, Nov 10, 2008 at 1:28 PM, Ingo Molnar <mingo@elte.hu> wrote:
> >>
> >> * Grant Grundler <grundler@parisc-linux.org> 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
> >>
> >

Re: sharing interrupt between PCI device

[Nobin Mathew]

Adding david to CC

On Tue, Nov 11, 2008 at 2:04 AM, Grant Grundler
<grundler@parisc-linux.org> wrote:
> On Mon, Nov 10, 2008 at 09:12:05PM +0530, Nobin Mathew wrote:
>> I could not find the definition of acpi_unregister_gsi in i386/x86_64
>> code, it is defined only for ia64.
>
> Sorry - I was looking at the ia64 branch by mistake.
>
>>
>> Since it is defined as a weak symbol, I feel it is not getting called
>> (correct if I am wrong, I searched in google for this).
>
> You are right.
>
> sorry,
> grant
>
>> /* FIXME: implement x86/x86_64 version */
>> void __attribute__ ((weak)) acpi_unregister_gsi(u32 i)
>> {
>> }
>>
>> How this weak symbols work, is it something like
>> acpi_pci_irq_disable() will not call acpi_unregister_gsi() in some
>> platforms.
>>
>> Thanks
>> Nobin Mathew.
>>
>> On Mon, Nov 10, 2008 at 4:01 PM, Nobin Mathew <nobin.mathew@gmail.com> wrote:
>> > Yes USB Virtual Controller has input devices like keyboard and mouse
>> > (routed through hpilo card (remote console)), so those things stops
>> > working when we remove hpilo driver.
>> >
>> > Thanks
>> > Nobin Mathew
>> >
>> > On Mon, Nov 10, 2008 at 1:28 PM, Ingo Molnar <mingo@elte.hu> wrote:
>> >>
>> >> * Grant Grundler <grundler@parisc-linux.org> 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
>> >>
>> >
>

RE: sharing interrupt between PCI device

[Altobelli, David]

>> On Mon, Nov 10, 2008 at 4:01 PM, Nobin Mathew <nobin.mathew@gmail.com> wrote:
>> > Yes USB Virtual Controller has input devices like keyboard and mouse
>> > (routed through hpilo card (remote console)), so those things stops
>> > working when we remove hpilo driver.
>> >

That is not quite correct.  Nothing is routed through hpilo.

The problem is that there is a shared hardware resource in iLO function 2 (hpilo),
and it is used by iLO function 4 (uhci_hcd kdb/mouse).  When hpilo is unloaded,
the pci_device_disable() call removes the ability for this function to act as a
busmaster, which stops the uhci_hcd from functioning correctly.

Reloading hpilo will enable the remote console again.

Removing the pci_disable_device() "fixes" the problem, but doing that worries me.

Re: sharing interrupt between PCI device

[Robert Hancock]

Altobelli, David wrote:
>>> On Mon, Nov 10, 2008 at 4:01 PM, Nobin Mathew <nobin.mathew@gmail.com> wrote:
>>>> Yes USB Virtual Controller has input devices like keyboard and mouse
>>>> (routed through hpilo card (remote console)), so those things stops
>>>> working when we remove hpilo driver.
>>>>
> 
> That is not quite correct.  Nothing is routed through hpilo.
> 
> The problem is that there is a shared hardware resource in iLO function 2 (hpilo),
> and it is used by iLO function 4 (uhci_hcd kdb/mouse).  When hpilo is unloaded,
> the pci_device_disable() call removes the ability for this function to act as a
> busmaster, which stops the uhci_hcd from functioning correctly.
> 
> Reloading hpilo will enable the remote console again.
> 
> Removing the pci_disable_device() "fixes" the problem, but doing that worries me.

I suspect that removing the pci_disable_device in that driver is 
probably the best solution. It's not really mandatory to disable the 
device in all cases, we have other devices that have similar issues and 
so can't be disabled. As long as it can't generate interrupts or 
otherwise affect the system after the module is unloaded (but it sounds 
like it doesn't use interrupts anyway).

It's not really a good hardware design (mucking with one PCI function on 
the device shouldn't disable functionality on other functions), but what 
can you do..

Re: sharing interrupt between PCI device

[Jiri Slaby]

On 11/03/2008 02:32 PM, 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.
> 
> 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.

-ENOCODE

Without seeing the code, we can't help you much.

sharing interrupt between PCI device

[Nobin Mathew]

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.

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.

Thanks
Nobin Mathew.