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  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:	Mon, 10 Mar 2014 14:43:44 -0600
From:	Bjorn Helgaas <>
To:	Andreas Noever <>
Cc:	Yinghai Lu <>,
	"" <>,
	"" <>,
	Rajat Jain <>,
	"Rafael J. Wysocki" <>
Subject: Re: [Bug] PCI: Enable INTx if BIOS left them disabled - triggers
 during rescan

On Sat, Mar 8, 2014 at 2:55 AM, Andreas Noever <> wrote:
> On Sat, Mar 8, 2014 at 2:04 AM, Bjorn Helgaas <> 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.,,, 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.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

Powered by blists - more mailing lists