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 11:04:22 -0800 (PST)
From:	Linus Torvalds <torvalds@...l.org>
To:	Jeff Garzik <jeff@...zik.org>
cc:	Krzysztof Halasa <khc@...waw.pl>,
	David Miller <davem@...emloft.net>,
	linux-kernel@...r.kernel.org, tiwai@...e.de,
	Olivier Nicolas <olivn@...llprod.org>
Subject: Re: [PATCH] ALSA: hda-intel - Disable MSI support by default



On Wed, 15 Nov 2006, Jeff Garzik wrote:
>
> Though OTOH, the driver wasn't calling pci_intx() nor setting irq flags
> correctly, so who knows.

The thing is, if the HDA driver happened to be alone on its legacy INTx 
vector, and it is now empty, then the kernel won't ever care about the 
fact that INTx may be still being generated. The legacy vector won't be 
enabled unless somebody else is on that vector.

So yes, this NV HDA sound breakage could easily be because of the 
interrupt being sent both over legacy INTx _and_ MSI. It would only break 
for people who happened to have another device sharing the INTx pin (like 
the report that caused us to disable it by default).

However, I really think that this should be a generic PCI layer thing. If 
some device asks for MSI interrupts, the PCI layer should try to turn off 
a INTx routing on its own. Asking drivers to do both is just silly, 
especially since driver writers really shouldn't be expected to know about 
all these issues (sure, the best ones do, but a lot of driver writers will 
just say "it works for me").

So I don't think the HDA driver should need disable INTx on its own 
explicitly.

If somebody were to write up such a patch and send it to Olivier (and 
others - I think there was another report of this) for testing (he'd now 
need to ask for msi irqs explicitly), that might be interesting. Hint, 
hint.

(See the original http://lkml.org/lkml/2006/11/8/98 report for one broken 
case, although it does seem different: we literally have a

	hda_intel: No response from codec, disabling MSI...

indicating that the MSI case simply didn't work at _all_ rather than 
duplicating interrupts).

		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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ