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:	Mon, 22 Oct 2007 16:41:00 -0400
From:	Jeff Garzik <jeff@...zik.org>
To:	Daniel Barkalow <barkalow@...ervon.org>
CC:	Linas Vepstas <linas@...tin.ibm.com>,
	Shane Huang <chunhao.huang@...mail.com>, davem@...emloft.net,
	gregkh@...e.de, htejun@...il.com, brice.goglin@...il.com,
	david.gaarenstroom@...il.com, linux-kernel@...r.kernel.org,
	linux-pci@...ey.karlin.mff.cuni.cz, shane.huang@....com,
	linux-ide@...r.kernel.org, Brice Goglin <brice@...i.com>
Subject: Re: [patch] PCI: disable MSI on more ATI NorthBridges

Daniel Barkalow wrote:
> On Fri, 19 Oct 2007, Jeff Garzik wrote:
> 
>> Linas Vepstas wrote:
>>> On Fri, Oct 19, 2007 at 09:17:23PM +0800, Shane Huang wrote:
>>>> Since we have little experience on PCI and MSI here, we had to try to
>>> As someone else pointed out, AMD should have *lots* of people with
>>> pci and msi experience on the payroll.  (Folks here buy AMD-designed pci
>>> chips ...)
>>>
>>>> ONLY
>>>> comment out the pci_intx() call in drivers/ata/ahci.c
>>>> My system can boot up too with MSI enabled!
>>>>
>>>> So does it mean that the root cause is our SB700 SATA controller
>>>> has a hardware bug where setting INTX_DISABLE in the PCI COMMAND
>>>> register masks MSI interrupts too? 
>>> That's what it sounds like, to me.
>>>
>>>> And what is the software solution or workaround?
>>> Not sure. Sounds like the device driver needs a quirk for this part.
>>
>> Take a look at tg3.c net driver change
>> 2fbe43f6f631dd7ce19fb1499d6164a5bdb34568 which is a similar situation.
>>
>> However, it may turn out that removing the pci_intx() stuff as a general rule
>> is easier than quirking these devices, if enough of them turn out to have this
>> hardware bug.
> 
> At a first approximation, ATI/AMD devices don't send any interrupts if 
> intx is disabled, nVidia devices send legacy interrupts in addition to MSI 
> ones if intx isn't disabled, and Intel devices actually work correctly. So 
> we need at least one kind of device quirk for intx and msi. (And doing it 
> in the drivers doesn't work, since everybody is making things driven by 
> snd_hda_intel and would like msi, afaict)

Note that INTX_DISABLE is a recent addition to PCI.  Older PCI devices 
support neither MSI nor INTX-disable, so make sure such devices don't 
creep into your sample.

In general it is documented that INTX_DISABLE should apply only to INTx# 
so devices that disable MSI based on that bit are out of spec.  But 
unfortunately that is rather irrelevant, since we see these out-of-spec 
devices in the field today.

	Jeff



-
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