linux-ide.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jeff Garzik <jeff@garzik.org>
To: Daniel Barkalow <barkalow@iabervon.org>
Cc: Linas Vepstas <linas@austin.ibm.com>,
	Shane Huang <chunhao.huang@hotmail.com>,
	davem@davemloft.net, gregkh@suse.de, htejun@gmail.com,
	brice.goglin@gmail.com, david.gaarenstroom@gmail.com,
	linux-kernel@vger.kernel.org, linux-pci@atrey.karlin.mff.cuni.cz,
	shane.huang@amd.com, linux-ide@vger.kernel.org,
	Brice Goglin <brice@myri.com>
Subject: Re: [patch] PCI: disable MSI on more ATI NorthBridges
Date: Mon, 22 Oct 2007 16:41:00 -0400	[thread overview]
Message-ID: <471D0ADC.7000005@garzik.org> (raw)
In-Reply-To: <Pine.LNX.4.64.0710221555190.32497@iabervon.org>

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

  reply	other threads:[~2007-10-22 20:41 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <BLU112-W5125F6D8BEB3DF6359D53E29F0@phx.gbl>
2007-10-19 19:57 ` [patch] PCI: disable MSI on more ATI NorthBridges Linas Vepstas
2007-10-19 20:21   ` Jeff Garzik
2007-10-20 22:03     ` Benjamin Herrenschmidt
2007-10-22 20:26     ` Daniel Barkalow
2007-10-22 20:41       ` Jeff Garzik [this message]
2007-10-22 21:31         ` Daniel Barkalow
2007-10-22 23:48           ` Krzysztof Halasa
2007-10-23  0:13           ` David Miller
2007-10-23  5:52             ` Daniel Barkalow
2007-10-23  9:39             ` Shane Huang
2007-10-23 10:01             ` Jeff Garzik
2007-10-23 10:06               ` David Miller
2007-10-24  2:46                 ` David Miller
2007-10-23 10:15           ` Jeff Garzik
2007-10-22 23:40         ` Krzysztof Halasa
2007-10-22 23:58           ` David Miller
2007-10-23 10:13           ` Jeff Garzik
2007-10-20 14:50   ` Shane Huang

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=471D0ADC.7000005@garzik.org \
    --to=jeff@garzik.org \
    --cc=barkalow@iabervon.org \
    --cc=brice.goglin@gmail.com \
    --cc=brice@myri.com \
    --cc=chunhao.huang@hotmail.com \
    --cc=davem@davemloft.net \
    --cc=david.gaarenstroom@gmail.com \
    --cc=gregkh@suse.de \
    --cc=htejun@gmail.com \
    --cc=linas@austin.ibm.com \
    --cc=linux-ide@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@atrey.karlin.mff.cuni.cz \
    --cc=shane.huang@amd.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).