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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 15 Nov 2006 10:51:37 -0800 (PST)
From:	Linus Torvalds <torvalds@...l.org>
To:	Jeff Garzik <jeff@...zik.org>
cc:	Arjan van de Ven <arjan@...radead.org>,
	Takashi Iwai <tiwai@...e.de>,
	David Miller <davem@...emloft.net>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] ALSA: hda-intel - Disable MSI support by default

On Wed, 15 Nov 2006, Jeff Garzik wrote:
> 
> > And btw, I say this as a person whose new main machine used to have HDA
> > routed over MSI, and the decision to default to it off meant that it went
> > back to the regular INTx thing.
> 
> Yeah, but you don't care if that happens, so this is an ineffective 'btw'
> It's not like you went to sleep crying over the loss, like I did [just
> kidding!]

Heh. I'm really hoping that nobody will cry themselves to sleep over MSI 
not being enabled..

> > (Btw, MSI interrupts also seem to not participate in CPU balancing:
> > 
> >  22:      41556      43005   IO-APIC-fasteoi   HDA Intel
> > 506:     110417          0   PCI-MSI-edge      eth0
> > 
> > which is another semantic change introduced by using MSI)
> 
> No, that's most likely because ethernet is always intentionally locked to a
> single CPU by irqbalance.

Nope, the same thing happened to "HDA Intel" when it was an MSI interrupt 
(ie before I applied the change that made it not use MSI by default).

So I think it's either: (a) irqbalance doesn't balance MSI interrupts at 
all or (b) the MSI interrupt code doesn't honor balancing requests even if 
it does.

I didn't look any closer. It's not like it's a huge problem for me (or 
likely for anybody else), but it was interesting to see another 
"unintended consequence" of the "use MSI or not" choice.

The suspend problem reported by Stephen is another such thing - where MSI 
itself wasn't a problem, but stupid (probably broken) firmware code at 
wakeup broke it by an unforseen interaction. Again, that is probably 
related to the fact that nobody has ever really tested it (ie firmware 
"engineers" obviously didn't actually ever test anything with MSI enabled 
and in use, and there really is no excuse for firmware messing with the 
MSI setting - other than the usual "firmware is inevitably buggy" thing).

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