dmicheck Type 41 result doesn't reflect real condition

[cktenn]

https://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/

There are packages like systemd relies on SMBIOS type 41 information to determine the onboard network interface renaming mechanism. However, manufacturers don't always offer the correct information, so the expected ifname enoX becomes enpXsX.

In the case
----------
# dmidecode 3.1
Getting SMBIOS data from sysfs.
SMBIOS 3.1 present.

Handle 0x2900, DMI type 41, 11 bytes
Onboard Device
        Reference Designation: To Be Filled by O.E.M.
        Type: Video
        Status: Enabled
        Type Instance: 0
        Bus Address: 0000:00:02.0

Handle 0x2901, DMI type 41, 11 bytes
Onboard Device
        Reference Designation: To Be Filled by O.E.M.
        Type: Ethernet
        Status: Disabled
        Type Instance: 0
        Bus Address: 0000:00:1f.6

Handle 0x2902, DMI type 41, 11 bytes
Onboard Device
        Reference Designation: To Be Filled by O.E.M.
        Type: Sound
        Status: Disabled
        Type Instance: 0
        Bus Address: 0000:00:1f.3

Handle 0x2903, DMI type 41, 11 bytes
Onboard Device
        Reference Designation: To Be Filled by O.E.M.
        Type: SATA Controller
        Status: Disabled
        Type Instance: 0
        Bus Address: 0000:00:17.0
-------
According to the SMBIOS specification section 7.42.3, "Type Instance" should be unique, and all devices mentioned are enabled, but the test result of fwts dmicheck type 41 item still passed.

Description: Ubuntu 18.04.2 LTS
Release: 18.04
fwts: 18.03.00-0ubuntu5
---
ProblemType: Bug
ApportVersion: 2.20.9-0ubuntu7.6
Architecture: amd64
CurrentDesktop: ubuntu:GNOME
DistributionChannelDescriptor:
 # This is the distribution channel descriptor for the OEM CDs
 # For more information see http://wiki.ubuntu.com/DistributionChannelDescriptor
 canonical-oem-somerville-bionic-amd64-20190418-59+beaver-osp1-loras+X22
DistroRelease: Ubuntu 18.04
InstallationDate: Installed on 2019-12-05 (1 days ago)
InstallationMedia: Ubuntu 18.04 "Bionic" - Build amd64 LIVE Binary 20190418-12:10
Package: fwts 18.03.00-0ubuntu5
PackageArchitecture: amd64
ProcVersionSignature: Ubuntu 5.0.0-1028.32-oem-osp1 5.0.21
Tags: bionic
Uname: Linux 5.0.0-1028-oem-osp1 x86_64
UpgradeStatus: No upgrade log present (probably fresh install)
UserGroups: adm cdrom dip lpadmin plugdev sambashare sudo
_MarkForUpload: True

[cktenn (cktenn)]

apport information

[cktenn (cktenn)]

apport information

[cktenn (cktenn)]

apport information

[Alex Hung (alexhung)]

It seems that SMBIOS doesn't ask type instance to start from 1 - it was only an example.

======================================
Device Type Instance is a unique value (within a given onboard device type) used to indicate the order the device is designated by the system. For example, a system with two identical Ethernet NICs may designate one NIC (with higher Bus/Device/Function=15/0/0) as the first onboard NIC (instance 1) and the other NIC (with lower Bus/Device/Function =3/0/0) as the second onboard NIC (instance 2).
======================================

The "Status" field is probably match to real hardware - in this case, the ethernet @ 00:1f.6, and therefore "disabled" should be fine.

The missing one, however, is "r8169 0000:02:00.0". As this is also an onboard device, it deserves a type 41 itself. An example is also below:

Handle 0x2901, DMI type 41, 11 bytes
Onboard Device
        Reference Designation: Realtek R8169
        Type: Ethernet
        Status: Enabled
        Type Instance: 1
        Bus Address: 0000:02:00.0

Note the type instance must be unique (and therefore 1, not 0) and "Bus Address" should match to actual address 2:00.0.

Finally, OEM/ODM should modify "To Be Filled by O.E.M." to something real; however, this is minor.

[Alex Hung (alexhung)]

There are no ways to get from 2:00.0 to SMBIOS type 41, as it is not possible to know whether 2:00.0 is a onboard from software's viewpoint. From the output type 41, it seems nothing wrong.

[cktenn (cktenn)]

From the lscpi out, the ethernet is on PCi 02:00.0. It is not in DMI type 41 table.

[Alex Hung (alexhung)]

@cktenn,

fwts has no way to know it is an onboard device unless it is reported to be so. A computer can has a PCIe inserted without having a antry in table 41. From fwts's (or spec's) viewpoint, there is nothing wrong here.

[Alex Hung (alexhung)]

There are a few things can be checked to type 41 in fwts. I am looking into it. It may not be solve this bug but it is still worthwhile to add more sanity checks.

[Shih-Yuan Lee (fourdollars)]

https://www.dmtf.org/sites/default/files/standards/documents/DSP0134_2.7.1.pdf

7.42 Onboard Devices Extended Information (Type 41)

The information in this structure defines the attributes of devices that are onboard (soldered onto) a system element, usually the baseboard. Table 114 provides details.

In general, an entry in this table implies that the BIOS has some level of control over the enabling of the associated device for use by the system.

NOTE: This structure replaces Onboard Device Information (Type 10) starting with version 2.6 of this specification. BIOS providers can choose to implement both types to allow existing SMBIOS browsers to properly display the system’s onboard devices information.

[Shih-Yuan Lee (fourdollars)]

Please help to provide the output of `sudo dmidecode -t 10`.

[Alex Hung (alexhung)]

There is only one other check can be done for type 41 - Device Type Instance must be unique for a device type.

However, it's going to be ugly code to support this in the current fwts dmicheck implementation. I am not sure whether this is worthwhile as it is a small feature and there aren't any failing cases yet...