Disable INTx when enabling MSI

Disable INTx when enabling MSI

[Daniel Barkalow]

Some device manufacturers seem to think it's the OS's responsibility to 
disable legacy interrupt delivery when using MSI. If the driver doesn't 
handle it (which they generally don't), and the device isn't PCI-Express, 
a steady stream of legacy interrupts will be delivered in addition to the 
MSI ones, eventually leading to the legacy IRQ getting disabled, which 
kills any device that shares it.

Jeff proposed a patch in http://lkml.org/lkml/2006/11/21/332 when Linus 
wanted to do it in the PCI layer, but nobody seems to have told the actual 
PCI maintainer.

I'm trying to get a patch into -stable to do pci_intx in exactly the same 
situations, but only for forcedeth (which is the device that's causing 
problems for me), but that requires that the real solution be merged in 
the mainline.

	-Daniel
*This .sig left intentionally blank*

Re: Disable INTx when enabling MSI

[Greg KH]

On Thu, Dec 07, 2006 at 05:31:33PM -0500, Daniel Barkalow wrote:
> Some device manufacturers seem to think it's the OS's responsibility to 
> disable legacy interrupt delivery when using MSI. If the driver doesn't 
> handle it (which they generally don't), and the device isn't PCI-Express, 
> a steady stream of legacy interrupts will be delivered in addition to the 
> MSI ones, eventually leading to the legacy IRQ getting disabled, which 
> kills any device that shares it.
> 
> Jeff proposed a patch in http://lkml.org/lkml/2006/11/21/332 when Linus 
> wanted to do it in the PCI layer, but nobody seems to have told the actual 
> PCI maintainer.

Care to take Jeff's proposed patch, verify that it works and forward it
on to me?

thanks,

greg k-h

Re: Disable INTx when enabling MSI

[Linus Torvalds]

On Thu, 7 Dec 2006, Daniel Barkalow wrote:
>
> Jeff proposed a patch in http://lkml.org/lkml/2006/11/21/332 when Linus 
> wanted to do it in the PCI layer, but nobody seems to have told the actual 
> PCI maintainer.

I got a patch from Jeff, but it was marked as totally untested, and wasn't 
even signed-off, so I asked for that to be fixed, and never heard back.

If somebody sends me the patch that disables INTx when MSI is enabled, 
with testing, and saying "I verified that this fixed it for me", I will 
happily apply it.

NOTE: _I_ want the one that is PCI-wide. No per-driver stuff, please. I'm 
of the opinion that any hardware that supports MSI but doesn't support 
INTx_DISABLE from PCI-2.3 (or at least do it automatically and ignore the 
bit in the config word) should just not use MSI at all. Such hardware is 
simply broken (and nobody has actually pointed to an example of that 
existing in the real world, so we really most likely will never care about 
the theoretical situation about something that might react badly to 
having MSI enable automatically disable INTx).

		Linus

Re: Disable INTx when enabling MSI

[Jeff Garzik]

Linus Torvalds wrote:
> 
> On Thu, 7 Dec 2006, Daniel Barkalow wrote:
>> Jeff proposed a patch in http://lkml.org/lkml/2006/11/21/332 when Linus 
>> wanted to do it in the PCI layer, but nobody seems to have told the actual 
>> PCI maintainer.
> 
> I got a patch from Jeff, but it was marked as totally untested, and wasn't 
> even signed-off, so I asked for that to be fixed, and never heard back.
> 
> If somebody sends me the patch that disables INTx when MSI is enabled, 
> with testing, and saying "I verified that this fixed it for me", I will 
> happily apply it.

Making it now...

	Jeff

Re: Disable INTx when enabling MSI

[Daniel Barkalow]

On Thu, 7 Dec 2006, Greg KH wrote:

> Care to take Jeff's proposed patch, verify that it works and forward it
> on to me?

I'll test it tomorrow. Testing disables my network, and making sure the 
problem exists without the patch kills my disk controller, so I need to 
sit at the computer for a while. I assume that I've got the only known 
device that demonstrates the need for this?

Off topic: would it be wise as a general rule to somehow shut down devices 
whose interrupts get disabled by the "nobody cared!" code? Or maybe call 
their interrupt handlers periodically to keep them alive?

	-Daniel
*This .sig left intentionally blank*