| 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
| ||
|
Message-ID: <4AF21678.5020107@gmail.com> Date: Wed, 04 Nov 2009 18:04:08 -0600 From: Robert Hancock <hancockrwd@...il.com> To: Valdis.Kletnieks@...edu CC: Justin Piszcz <jpiszcz@...idpixels.com>, linux-kernel@...r.kernel.org Subject: Re: Kernel Options: To use MSI-X or not? On 11/04/2009 11:36 AM, Valdis.Kletnieks@...edu wrote: > On Wed, 04 Nov 2009 11:53:18 EST, Justin Piszcz said: > >> Example, 3ware cards/Intel Audio Drivers you can use MSI-X instead of >> having several devices use/share an interrupt. >> >> What are the pros/cons to using MSI-X vs. having devices share an IRQ? > > Cons: Sometimes, you'll find a device that claims to support MSI but in fact is > to some extent borked... > > I'm the proud owner of a Dell Latitude D820, which includes this PCI: > > 00:1b.0 Audio device: Intel Corporation 82801G (ICH7 Family) High Definition Audio Controller (rev 01) > Subsystem: Dell Device 01cc > Flags: bus master, fast devsel, latency 0, IRQ 30 > Memory at efffc000 (64-bit, non-prefetchable) [size=16K] > Capabilities: [50] Power Management version 2 > Capabilities: [60] MSI: Enable+ Count=1/1 Maskable- 64bit+ > Capabilities: [70] Express Root Complex Integrated Endpoint, MSI 00 > Capabilities: [100] Virtual Channel<?> > Capabilities: [130] Root Complex Link<?> > Kernel driver in use: HDA Intel > > However, actually trying to enable MSI gets me this at some pseudo-random > time after booting (one for each of 7 boots): > > [ 4.519264] ALSA sound/pci/hda/hda_intel.c:683: No response from codec, disabling MSI: last cmd=0x00df0900 > [ 22.788015] ALSA sound/pci/hda/hda_intel.c:683: No response from codec, disabling MSI: last cmd=0x008f0c00 > [ 4.719263] ALSA sound/pci/hda/hda_intel.c:683: No response from codec, disabling MSI: last cmd=0x00df0900 > [ 12.497263] ALSA sound/pci/hda/hda_intel.c:683: No response from codec, disabling MSI: last cmd=0x00df0900 > [ 815.350265] ALSA sound/pci/hda/hda_intel.c:683: No response from codec, disabling MSI: last cmd=0x00df0900 > [ 595.171267] ALSA sound/pci/hda/hda_intel.c:683: No response from codec, disabling MSI: last cmd=0x00171700 > [ 4.968263] ALSA sound/pci/hda/hda_intel.c:683: No response from codec, disabling MSI: last cmd=0x00df0900 > > (Am slightly mystified about the resets at 4 and 12 seconds - at that point, > we're not up far enough to actually try to use the audio. I suspect udev trying > to initialize the card - except sometimes it works and runs just fine with > MSI for quite some time: > > [14267.701267] ALSA sound/pci/hda/hda_intel.c:683: No response from codec, disabling MSI: last cmd=0x00df0900 > [12841.892050] ALSA sound/pci/hda/hda_intel.c:683: No response from codec, disabling MSI: last cmd=0x00df0900 > [10647.783274] ALSA sound/pci/hda/hda_intel.c:683: No response from codec, disabling MSI: last cmd=0x001f1500 > [15091.102034] ALSA sound/pci/hda/hda_intel.c:683: No response from codec, disabling MSI: last cmd=0x00171700 > [20085.955293] ALSA sound/pci/hda/hda_intel.c:683: No response from codec, disabling MSI: last cmd=0x00df0700 This may not be an actual MSI problem (in fact I'd say it's probably not). Currently hda_intel disables MSI after any codec response timeout, so it could be it would have worked if it retried while still using MSI. I believe Takashi was going to change the driver to be less sensitive about this. -- 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