Re: [PATCH] ALSA: hda-intel - Disable MSI support by default

[Mws <mws@twisted-brains.org>]

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

On Wednesday 15 November 2006 20:35, Linus Torvalds wrote:
> 
> On Wed, 15 Nov 2006, Jeff Garzik wrote:
> > 
> > The reason we cannot do this in the generic layer for non-PCI-Ex is only the
> > driver knows whether that PCI 2.2 bit was actually implemented in the device
> > or mapped to some other weird behavior we don't want to touch.  DISABLE-INTX
> > is a new bit not present in PCI 2.1 (alas!!).
> 
> Ok, I would have a few suggestions, then:
> 
>  - devices that don't support INTx disable should basically be considered 
>    to not support MSI at all (ie a driver simply shouldn't even try to 
>    enable MSI, since enabling MSI includes the implicit DISABLE-INTX)
> 
>    This is likely ok, since MSI wasn't in PCI 2.1 _either_ afaik. So if 
>    your hardware has MSI, it probably _does_ have DISABLE-INTX (or at 
>    least that bit doesn't do anything bad, which is the other case)
> 
>  - add a flag to "pci_enable_msi()". There really aren't that many users, 
>    and they basically _all_ want this functionality. Making them call 
>    another function is just a recipe for disaster, since somebody will 
>    forget. Having to just say "do I support INTx disable" is much better, 
>    since it makes the driver writer aware of having to _explicitly_ make 
>    that choice.
> 
> > Maybe a better solution is letting the driver say "pci_dev->intx_ok = 1" right
> > before it calls pci_enable_device().
> 
> I hate that, for exactly the same reason I hate "pci_intx()". It just 
> means that most drivers won't do it, because it's not even part of the 
> normal sequence, and most people don't care. So again, it would actually 
> be better in that case to just add a "flags" field to pci_enable_device(), 
> although that's a _hell_ of a lot more painful than it would be to do the 
> same to "pci_enable_msi()".
> 
> > And if we do this, we can follow through on another suggestion I made:
> > disabling INTx on driver exit, to help eliminate any possibility of screaming
> > interrupts after driver unload.
> 
> The thing is, I think that's a bad idea for the same reason it's a bad 
> idea to disable the BAR's (which we tried and then reverted). It's just 
> going to cause problems for soft rebooting etc with firmware that doesn't 
> expect it.
> 
> A driver should obviously quiesce the device on shutdown, and if it leaves 
> a device in a state where it may still generate interrupts, that's a 
> _bug_, so disabling INTx is just papering over a much more serious issue.
> 
> 		Linus
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 
i just recognised this thread, and i found a solution for some weird stuff
also reported days ago on alsa-users list.

short summary for your information:

asus m2n32 ws professional 
amd x2 5000+
everything compiled as 64 bit.

i recognised strange behaviour from 2.6.19-rc1 on.
sound got crappy and if i tried to use snd_hda_intel as modules
rmmod & afterwards modprobe froze the machine completely.
even the kernel sys req key combination didn't work anymore.

after some small discussions on alsa-user ml i recognised this
thread today. 
i thought my problem could also exist on this msi stuff.
i disabled msi in kernel config, reboot, and, after starting x & kde
i got immediately a freeze.
last and maybe important last try has been to
enable msi support _but_ boot kernel with cmdline pci=nomsi
this finally did work out. i got a working sound environment again.

if i should supply more information on that, please contact me.

i find it a bit abnormal that the disabling msi in kernel config behaviour
is different from kernel cmdline pci=nomsi option.

best regards
marcel

ps. i don't want to break this thread up into something different, but maybe my 
     report works out as usefull.



[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]