Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1030837AbWKOSyS (ORCPT ); Wed, 15 Nov 2006 13:54:18 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1030868AbWKOSyS (ORCPT ); Wed, 15 Nov 2006 13:54:18 -0500 Received: from smtp.osdl.org ([65.172.181.4]:44980 "EHLO smtp.osdl.org") by vger.kernel.org with ESMTP id S1030837AbWKOSyR (ORCPT ); Wed, 15 Nov 2006 13:54:17 -0500 Date: Wed, 15 Nov 2006 10:51:37 -0800 (PST) From: Linus Torvalds To: Jeff Garzik cc: Arjan van de Ven , Takashi Iwai , David Miller , linux-kernel@vger.kernel.org Subject: Re: [PATCH] ALSA: hda-intel - Disable MSI support by default In-Reply-To: <455B5F01.7020601@garzik.org> Message-ID: References: <20061114.190036.30187059.davem@davemloft.net> <20061114.192117.112621278.davem@davemloft.net> <1163607889.31358.132.camel@laptopd505.fenrus.org> <455B5F01.7020601@garzik.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2132 Lines: 50 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/