Re: [Bug] PCI: Enable INTx if BIOS left them disabled - triggers during rescan

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Sat, Mar 8, 2014 at 2:55 AM, Andreas Noever <andreas.noever@xxxxxxxxx> wrote:
> On Sat, Mar 8, 2014 at 2:04 AM, Bjorn Helgaas <bhelgaas@xxxxxxxxxx> wrote:

>> If we did that, INTX_DISABLE would be cleared by the first
>> pci_enable_device() and pci_reenable_device() wouldn't do anything,
>> leaving it cleared.  The resulting state (cleared) would be the same,
>> but the transitions would be gone, and maybe those are important.
> Just a quick note: With pci_intx_for_msi removed no hotplug events are
> ever delivered. Everything else still works though. So it is either a
> problem specific to Thunderbolt bridges or maybe it just affects
> hotplug (and PME?) interrupts.

Interesting.  This is on a MacBook, isn't it?  If you have Mac OS on
it, is there a way you can do the equivalent of lspci on it?  I'm
curious about whether it sets INTx_DISABLE when it enables MSI.

I still haven't found any indication that INTx_DISABLE is intended or
required as part of enabling MSI/MSI-X, so I'm quite dubious about
Linux using it that way.  The references I've seen, e.g.,
http://www.pcisig.com/reflector/msg05301.html,
http://www.pcisig.com/reflector/msg05302.html, say the purpose is to
better manage shared IRQs.

> I also attempted booting with pcie_hp=nomsi and now everything works.
> Interestingly pciehp now also  gets an interrupt from 09 (event though
> that card has just been removed). I suspect this is just pciehp not
> noticing that it itself is gone.
> pciehp 0000:06:03.0:pcie24: Card not present on Slot(3-1)
> pciehp 0000:09:00.0:pcie24: Latch open on Slot(9)
> pciehp 0000:09:00.0:pcie24: Button pressed on Slot(9)
> pciehp 0000:09:00.0:pcie24: Card present on Slot(9)
> pciehp 0000:09:00.0:pcie24: Power fault on slot 9
> pciehp 0000:09:00.0:pcie24: Power fault bit 0 set
> pciehp 0000:09:00.0:pcie24: PCI slot #9 - powering on due to button press.
> pciehp 0000:09:00.0:pcie24: unloading service driver pciehp
> pciehp 0000:09:00.0:pcie24: Link Training Error occurs
> pciehp 0000:09:00.0:pcie24: Failed to check link status

This is a good clue.  I think the portdrv registration thing is a bit
more confusing than necessary.  I'll poke around in there a bit.

Unfortunately, I don't think this is going to lead to a quick easy fix
suitable for -rc7, so we'll probably have to do something simple like
skipping the INTx enable if MSI is already enabled.

Bjorn
--
To unsubscribe from this list: send the line "unsubscribe linux-pci" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [DMA Engine]     [Linux Coverity]     [Linux USB]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Greybus]

  Powered by Linux