linux-kernel - Re: [Bug] PCI: Enable INTx if BIOS left them disabled

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] [day] [month] [year] [list]

Message-ID: <CAErSpo4MQsAer7FM0kU5mMOGRok0oFMWX1FqFijmswutjyNoRg@mail.gmail.com>
Date:	Mon, 10 Mar 2014 14:43:44 -0600
From:	Bjorn Helgaas <bhelgaas@...gle.com>
To:	Andreas Noever <andreas.noever@...il.com>
Cc:	Yinghai Lu <yinghai@...nel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-pci@...r.kernel.org" <linux-pci@...r.kernel.org>,
	Rajat Jain <rajatxjain@...il.com>,
	"Rafael J. Wysocki" <rjw@...ysocki.net>
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 <andreas.noever@...il.com> wrote:
> On Sat, Mar 8, 2014 at 2:04 AM, Bjorn Helgaas <bhelgaas@...gle.com> 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-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/