On Mon, 22 Oct 2007, Jeff Garzik wrote:
> 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.
I have a device that supports MSI and INTX-disable, and, with MSI on (and
delivering interrupts successfully) also sends legacy interrupts (on
the IRQ that is no longer associated with the device) unless INTX is
disabled. Without the intx_disable(), the kernel disables the IRQ
entirely and breaks a random other device in my system.
It's:
00:07.0 Bridge: nVidia Corporation MCP61 Ethernet (rev a2)
I haven't tried MSI with the other devices in the system, but I expect
that this:
00:05.0 Audio device: nVidia Corporation MCP61 High Definition Audio (rev a2)
will have the same issue, and use a multi-vendor driver.
> 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.
It's likewise documented (although maybe arguable in wording) that the
device shouldn't send legacy interrupts if MSI is in use, regardless of
INTX_DISABLE, but this also happens in the field.
I think that the current Linux behavior with respect to INTX_DISABLE is
simply due to which hardware bug was present in the device whose driver
first got Linux support, but one or the other or both needs a quirk, since
there's no behavior that works with everything. And it's still impossible
to tell which bug is more common, since MSI isn't used most of the time,
even if the hardware supports it, so it's pretty arbitrary which way Linux
goes in the non-quirk case.
-Daniel
*This .sig left intentionally blank*
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
