Re: [PATCH 1/2] Save SMBIOS Type 9 System Slots during DMI Scan

[Jean Delvare]

Hi Jordan,

Please leave the list in Cc and avoid HTML formatting.

Le Thursday 26 November 2015 Ã 16:00 -0600, Jordan Hargrave a Ãcrit :
> 
> 
> On Thu, Nov 26, 2015 at 2:26 AM, Jean Delvare <jdelvare@xxxxxxx>
> wrote:
>         I'm curious how the BIOS can assign a device number and
>         function when there is no card in the slot. I'm also curious
>         how multi-function cards are handled. I suppose that only the
>         first function has a DMI record?


> BIOS can leave holes in PCI bridge numbers during PCI enumeration for
> hotplug slots.  
> 
> 
> From what I've seen of dmidecode/lspci dumps, there's basically 4
> cases that can occur.
> 
> a) Inuse, Bus Address correct
> 
> b) Inuse, Bus Address invalid
> 
> c) Not Inuse, Bus Address correct
> 
> d) Not Inuse, Bus Address invalid

Just checked how it looks like on my Lenovo laptop. Two slots are
listed, both with "Current Usage: Available" (which BTW is probably
wrong for one of them which holds the wireless card as far as I know)
and both have Bus Address: 0000:00:00.0. This is case d) above. However
both also say "Hot-plug devices are supported". I suppose that in theory
you should check this flag and treat unused slots with hot-plug
supported as "In use".

> 
> If the BIOS is functioning correctly, you should only see cases a or
> d.  That assumes BIOS gets it right of course (which non-Dell systems
> usually don't).

Well if I read you correctly, c) would be valid too for hot-plug
scenarios? In the DMI table dumps I checked, lots have "Not Inuse, Bus
Address correct" entries, without hot-plug support declared. I don't
think it is much of a problem anyway, worse case we record an entry
which will never be used?

> The Bus Address invalid follow three different cases:
> 00:00.0
> 
> ff:1f.7
> 
> Some random value :/  (where there isn't a PCI device at that
> address).  This is the worst case. It could be BIOS has reserved a bus
> address for an empty slot, or it could just be bad BIOS data.
> 
> 
> I can put the check in for ff:1f.7 or 00:00.0 at least.

I don't think you can reject ff:1f.7 as it is potentially valid (as a
matter of fact I have on Dell PowerEdge 300 DMI dump with a "RAC" PCIe
device declared at bus address 0000:ff:1f.7, I can share it with you if
needed.) OTOH I don't know if bus segment ffff is valid.

00:00.0 is also valid but at least you know it will never be assigned to
a slot (at least I think it is always the host bridge, which is on-board
by definition? but I could be wrong...)

Remember, what really matters is that the code works with systems which
stick to the specification. If the behavior is suboptimal on systems
which do not follow the specification, they deserve it.

Also note that the SMBIOS specification says that the segment/bus/devfn
fields should be ffs for non-PCI-like slots. dmidecode decodes these
fields regardless of the type, but that is incorrect (although not much
of an issue in practice I suppose as PCI rules the world.) I suppose you
don't want to check this in the kernel anyway because 1* the list of
slot types gets new values every now and then and that would be a pain
to maintain and 2* I suppose it doesn't matter if you add other devices
to the list as nobody will ever look them up.

>    That will eliminate most of cases b, d.  Hotplugged cards won't get
> the right slot number though.  Not a problem on Dell servers as we
> don't support PCIe hotplug.
> 
> 
> 
> Multi-function cards will only have an entry for function 0.  The
> other patch that uses this code will lookup func 0 if there isn't an
> exact match and it's not a PCIE root port.

OK, makes sense (although it is regrettable that the SMBIOS spec did not
provide a way to handle this case gracefully.)


-- 
Jean Delvare
SUSE L3 Support

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/