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.
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.
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.
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 <[email protected]> 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.
>
>
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...
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 <[email protected]> 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...
>
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 <[email protected]> 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 <[email protected]> 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...
>>
>
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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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...
>>>
>>
>
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?
Exactly
On Fri, Nov 7, 2008 at 2:54 AM, Jiri Slaby <[email protected]> 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?
>
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 <[email protected]> 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 [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
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.
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 <[email protected]> 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.
>
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.
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 <[email protected]> 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 [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
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.
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
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
<[email protected]> 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
>
lspci -vs 1:4 is taken before inserting the drivers.
Thanks
On Mon, Nov 10, 2008 at 12:05 PM, Nobin Mathew <[email protected]> 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
> <[email protected]> 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
>>
>
Version of the running kernel 2.6.18-92.el5.
Thanks
On Mon, Nov 10, 2008 at 12:09 PM, Nobin Mathew <[email protected]> wrote:
> lspci -vs 1:4 is taken before inserting the drivers.
>
> Thanks
>
> On Mon, Nov 10, 2008 at 12:05 PM, Nobin Mathew <[email protected]> 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
>> <[email protected]> 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
>>>
>>
>
[+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
> <[email protected]> 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
* Grant Grundler <[email protected]> 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
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 <[email protected]> wrote:
>
> * Grant Grundler <[email protected]> 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
>
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 <[email protected]> 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 <[email protected]> wrote:
>>
>> * Grant Grundler <[email protected]> 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
>>
>
On Mon, Nov 10, 2008 at 08:58:27AM +0100, Ingo Molnar wrote:
>
> * Grant Grundler <[email protected]> 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 [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
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 <[email protected]> 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 <[email protected]> wrote:
> >>
> >> * Grant Grundler <[email protected]> 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
> >>
> >
Adding david to CC
On Tue, Nov 11, 2008 at 2:04 AM, Grant Grundler
<[email protected]> 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 <[email protected]> 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 <[email protected]> wrote:
>> >>
>> >> * Grant Grundler <[email protected]> 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
>> >>
>> >
>
>> On Mon, Nov 10, 2008 at 4:01 PM, Nobin Mathew <[email protected]> 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.
Altobelli, David wrote:
>>> On Mon, Nov 10, 2008 at 4:01 PM, Nobin Mathew <[email protected]> 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..