1

First, regular lscpi

lspci | grep Non-Volatile
03:00.0 Non-Volatile memory controller ...

Which is interpreted as (Domain 0), bus 03, device 00, function 0.

The relevant section of dmidecode:

dmidecode -t slot
Handle 0x0026, DMI type 9, 17 bytes
System Slot Information
        Designation: PCIE3
        Type: x16 PCI Express 3 x16
        Current Usage: In Use
        Length: Long
        Characteristics:
                3.3 V is provided
                Opening is shared
                PME signal is supported
        Bus Address: 0000:03:02.0

Shows domain 0, bus 3, device 2, function 0.

Now, there is a bridge in there as seen with lspci tree view:

lspci -tv | grep -C 3 Non-Volatile
\-[0000:00]-+-00.0  Intel Corporation Xeon E5/Core i7 DMI2
            +-01.0-[01]--
            +-01.1-[02]--
            +-02.0-[03]----00.0  Non-Volatile memory controller ...

And the bridge is device 2 on bus 0, but its a little weird that dmidecode thinks that slot is device 2 on bus 3.

sheridp
  • 111
  • 5

1 Answers1

1

man dmidecode says

...
dmidecode  is  a tool for dumping a computer's DMI (some say
SMBIOS) table contents in a human-readable format.
...
While this is a good point in terms of report speed and safeness,
this also makes the presented information possibly unreliable.
...

The Linux kernel knows the addresses it uses. So I would rely on sysfs and lspci.

aventurin
  • 346
  • 1
  • 4
  • 11
  • Example of lies firmware authors write in DMI: apparently my motherboard manufacturer, product name, and version are all `OEM`. https://bugzilla.kernel.org/show_bug.cgi?id=11237#c79 – sourcejedi Aug 30 '16 at 20:48
  • Unfortunately, I have to rely on dmidecode because I am trying to get the actual PCI slot # that is visibly printed on the mobo. – sheridp Aug 31 '16 at 17:38