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 14:34:09 -0500
From:	Stephen Clark <Stephen.Clark@...lark.us>
To:	Linus Torvalds <torvalds@...l.org>
CC:	Arjan van de Ven <arjan@...radead.org>,
	Takashi Iwai <tiwai@...e.de>,
	David Miller <davem@...emloft.net>, jeff@...zik.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] ALSA: hda-intel - Disable MSI support by default

Linus Torvalds wrote:

>On Wed, 15 Nov 2006, Arjan van de Ven wrote:
>  
>
>>well we could cheat some. And have the generic code for this just
>>register the irq handler for both somehow.
>>    
>>
>
>Well, not generic code. It would have to be the driver itself that does 
>it, since generic code doesn't even know (at irq request time - and when 
>they are generated - it just gets the irq number).
>
>And the thing is, once you do that, all the advantages of MSI totally go 
>away - both the "nice" ones and the "really good ones" (the latter being 
>the hopeful eventual removal of irq routing confusions). So if you do 
>that, the better solution is for the driver to say "I won't use MSI at 
>all".
>
>Really.
>
>It all boils down to the same thing: either we have to know that MSI works 
>(where "know" is obviously relative - it's not like you can avoid _all_ 
>bugs, but dammit, even a single report of "not working" means that there 
>are probably a ton of machines like that, and we did something wrong), or 
>we shouldn't use it. There is no middle ground. You can't really safely 
>"test" for it, and while you _can_ say "just do both", it doesn't really 
>help anything (and potentially exposes you to just more bugs: if enablign 
>MSI actually _does_ disable INTx, but then doesn't work, at a minimum you 
>end up with a device that doesn't work, even if the rest of the kernel 
>might be ok).
>
>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.
>
>(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
>
>  
>
mine do:$ cat /proc/interrupts
           CPU0       CPU1
  0:    7986702    7971263   IO-APIC-edge      timer
...
 20:      90626      95073   IO-APIC-fasteoi   uhci_hcd:usb2
220:       1722       1415   PCI-MSI-edge      HDA Intel
NMI:          0          0
LOC:   15957069   15957071
ERR:          0
MIS:          0

Also, I find it disturbing that we are forcing users to have know about 
all these
magic options that have to be put on the kernel boot line. My hard drive 
on my
new laptop would only run at 1.2mbs until I found out I had to use 
combined_mode=libata
and build a new ramdisk that included ata_piix.

My $.02
Steve

>which is another semantic change introduced by using MSI)
>
>			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/
>
>  
>


-- 

"They that give up essential liberty to obtain temporary safety, 
deserve neither liberty nor safety."  (Ben Franklin)

"The course of history shows that as a government grows, liberty 
decreases."  (Thomas Jefferson)



-
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