From: Bjorn Helgaas <bhelgaas@google.com>
To: Federico Vaga <federico.vaga@gmail.com>
Cc: "linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Michel Arruat <michel.arruat@gmail.com>
Subject: Re: PCIe bus enumeration
Date: Fri, 4 Jul 2014 15:26:12 -0600 [thread overview]
Message-ID: <20140704212612.GA15618@google.com> (raw)
In-Reply-To: <1807045.P44aWKLMe6@pcbe13110.cern.ch>
On Fri, Jul 04, 2014 at 09:55:20AM +0200, Federico Vaga wrote:
> > I assume these ports don't support hotplug. If they *did* support
> > hotplug, those ports would have to exist because they handle the
> > hotplug events (presence detect, etc.)
>
> I asked: yes, they do not support hotplug
>
> > If you can collect the complete "lspci -vv" output from your machine
> > (with a device plugged in, so we can see the port leading to it),
> > that will help make this more concrete. And maybe one with no
> > devices plugged in, so we can see exactly what changes.
>
> I attached two files with the output. I putted a card in slot 10 and
> took the output, then moved the card on slot 11 and took the output.
>
> As you can see with diff the bridge behind the slot disappear when it
> is empty.
Perfect, thanks! For some reason, it really helps me to be able to stare
at the actual data. Here's the situation with slot 10 occupied:
00:01.0 82Q35 Root Port to [bus 05] PCIe SltCap slot #21
05:00.0 CERN/ECP/EDU Device slot 10
00:1c.0 82801I Express Port 1 to [bus 04] PCIe SltCap slot #22
00:1c.3 (not present at all)
00:1c.4 82801I Express Port 5 to [bus 03] PCIe SltCap slot #0
03:00.0 Realtek NIC
and here it is with slot 11 occupied:
00:01.0 (not present at all)
00:1c.0 82801I Express Port 1 to [bus 05] PCIe SltCap slot #22
00:1c.3 82801I Express Port 4 to [bus 04] PCIe SltCap slot #25
04:00.0 CERN/ECP/EDU Device slot 11
00:1c.4 82801I Express Port 5 to [bus 03] PCIe SltCap slot #0
03:00.0 Realtek NIC
I'm pretty sure this is a function of your BIOS. There are often
device-specific ways to enable or disable individual devices (like the root
ports here), and the BIOS is likely disabling these ports when there is
nothing below them. I don't know why it would turn off 00:1c.3 when its
slot is empty, but it doesn't turn off 00:1c.0, which also leads to an
empty slot. But I don't think Linux is involved in this, and if the BIOS
disables devices, there really isn't anything Linux can do about it.
If you can get to an EFI shell on this box, you might be able to confirm
this with the "pci" command. Booting Linux with "pci=earlydump" is similar
in that it dumps PCI config space before we change anything.
To solve this problem, I think you need slot information even when there's
no hotplug. This has been raised before [1, 2], and I think it's a good
idea, but nobody has implemented it yet.
Another curious thing is that you refer to "slot 10", but there's no
obvious connection between that and the "slot 21" in the PCIe capability of
the Root Port leading to that slot. But I guess you said the slots are in
a backplane (they're not an integral part of the motherboard). In that
case, there's no way for the motherboard to know what the labels on the
backplane are.
Bjorn
[1] http://lkml.kernel.org/r/CAErSpo45sDNPt6=Yw-qgqdojYL8+_JNOVNEnVxRLatga+bY+2A@mail.gmail.com
[2] https://bugzilla.kernel.org/show_bug.cgi?id=72681
next prev parent reply other threads:[~2014-07-04 21:26 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-07-03 16:45 PCIe bus enumeration Federico Vaga
2014-07-03 19:43 ` Bjorn Helgaas
2014-07-03 20:40 ` Federico Vaga
2014-07-03 22:04 ` Bjorn Helgaas
2014-07-04 7:55 ` Federico Vaga
2014-07-04 21:26 ` Bjorn Helgaas [this message]
2014-07-07 7:29 ` Federico Vaga
2014-07-07 17:34 ` Bjorn Helgaas
2014-07-08 7:15 ` Federico Vaga
2014-07-08 18:23 ` Bjorn Helgaas
2014-07-08 19:20 ` Federico Vaga
2014-07-08 20:27 ` Bjorn Helgaas
2014-08-07 14:59 ` Federico Vaga
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=20140704212612.GA15618@google.com \
--to=bhelgaas@google.com \
--cc=federico.vaga@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=michel.arruat@gmail.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).