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

From: Jean Delvare
Date: Sat Nov 28 2015 - 03:47:43 EST


Hi Jordan,

Once again: please keep the list included in your replies. Others may
be able to help. Also the list is archived for later reference.

On Fri, 27 Nov 2015 20:45:21 -0600, Jordan Hargrave wrote:
> On Fri, Nov 27, 2015 at 6:04 AM, Jean Delvare <jdelvare@xxxxxxx> wrote:
> > When sending a new version of a patch, please start a new thread, and
> > tag it with [PATCH v2] instead of [PATCH]. A changelog before the
> > diffstat is also appreciated.
>
> Hmm, not sure how to do that, it always generates N diffs for me whenever I
> do a new commit.

I can't parse this, sorry.

> > As discussed before, this is questionable, as you may filter out valid
> > entries (especially as you do not check the segment value.) It's
> > probably better to record invalid entries than to take the risk of
> > filtering out valid ones?
>
> Segment is even more broken. it's either 0 or ffff, and bus maybe 0 or ff
> on top of that.
> And are there even any machines that use segments anyway? The last one I
> know of was 10+ years ago, and didn't support SMBIOS 2.6

We have a few machines in the SUSE Labs network which use PCI segments.
SGI UV3000 uses segments 0000, 0001, 1000, 1001, 1002 and 1003, and it
implements SMBIOS 2.7. SGI UV100 uses segments 0000, 0001, 1000 and
1001. Fujitsu PrimeQuest 2800E uses segments 0000 and 0001, and it
implements SMBIOS 2.7.

Also SGI Altix 450 (ia64) uses PCI segments 0001, 0002, 0011, 0012 and
0021. It doesn't seem to have a valid DMI table though.

So yes, PCI bus segments are used, although not often.

> > Also I said before that 00:00.0 could be considered invalid for slots
> > because it was always an on-board device, but now
> > dmi_save_dev_pciaddr() will also handle on-board devices. I'm not sure
> > why someone would want to record the root host bridge in the DMI table,
> > but the specification allows it.
>
> Never seen 00:00.0 as a valid value. Yeah according to spec it's not
> invalid.... but real world BIOS is different.

It is the PCI root bridge on almost every x86 system I've seen, and
a few ia64 and arm64 systems too:

00:00.0 Host bridge [0600]: Intel Corporation 5520/5500/X58 I/O Hub to ESI Port [8086:3407] (rev 22)
00:00.0 Host bridge [0600]: Intel Corporation 5400 Chipset Memory Controller Hub [8086:4003] (rev 20)
00:00.0 Host bridge: Intel Corporation 5500 I/O Hub to ESI Port (rev 13)
00:00.0 Host bridge [0600]: Intel Corporation Xeon E7 v2/Xeon E5 v2/Core i7 DMI2 [8086:0e00] (rev 07)
00:00.0 Host bridge: ATI Technologies Inc RS690 Host Bridge
00:00.0 Host bridge [0600]: Advanced Micro Devices [AMD] nee ATI RD890 PCI to PCI bridge (external gfx0 port A) [1002:5a13] (rev 02)
00:00.0 Host bridge [0600]: ATI Technologies Inc RD890 Northbridge only dual slot (2x16) PCI-e GFX Hydra part [1002:5a10] (rev 02)
00:00.0 Host bridge: ATI Technologies Inc RD890 Northbridge only dual slot (2x16) PCI-e GFX Hydra part (rev 02)
00:00.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Device [1022:1a00]

--
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/