Wandering Thoughts archives

Why I say Fedora 15 could get my machine's Ethernet's name right

Fedora 15's consistent network device naming is done by biosdevname; its documentation implies that this is done using information that you can also see directly with dmidecode and biosdecode. Today I'm going to walk through why I think there's enough information in my machine's BIOS information to get it right (as I mentioned yesterday when I complained about this).

SMBIOS/DMI information comes in several different types. The biosdevname manpage implies that what it pays attention to are information on actual physical slots (DMI type 9) and onboard devices (specifically DMI type 41). Both of these report information that includes a 'bus address' for each thing they are reporting on. On my machine what I see is:

# dmidecode -t 41
[...]
Handle 0x0063, DMI type 41, 11 bytes
Onboard Device
        Reference Designation:  Onboard LAN
        Type: Ethernet
        Status: Enabled
        Type Instance: 1
        Bus Address: 0000:00:19.0

# dmidecode -t 9 | fgrep 'Bus Address'
        Bus Address: 0000:00:01.0
        Bus Address: 0000:00:1c.3
        Bus Address: 0000:00:1c.4
        Bus Address: 0000:00:1c.6
        Bus Address: 0000:00:1c.7
        Bus Address: 0000:00:1d.0
        Bus Address: 0000:00:01.0

(The two slots with the same bus address have the designations PCIEX16_1 and PCIEX16_2.)

So the DMI information believes that there is an onboard Ethernet and as we expect there's nothing with that 'bus address' in the list of physical slots.

DMI bus addresses for PCI(E) devices appear to be in the form of 'segment group:PCI bus:device.function'. To relate this to lspci output, you drop the segment group; my uninformed impression is that only complicated large server machines have complex enough PCI bus topologies to have non-zero segment group numbers. lspci says that the sole Ethernet device is in slot 07:00.0, sitting behind a PCI bridge at 00:1c.5 (according to 'lspci -t', although I don't know how it determines that), and there is no slot 00:19.

The most informative thing biosdecode can tell us is the PCI interrupt routing table (aka PIR). This table doesn't have anything for 00:19, but it does mention 07:00:

# biosdecode | fgrep 07:00
         Slot Entry 14: ID 07:00, on-board

So in summary: the SMBIOS claims that this machine has an onboard Ethernet at an otherwise unknown PCI slot name, the only actual PCI-visible Ethernet is not on or behind a SMBIOS-listed physical slot, and the BIOS's interrupt routing claims that the Ethernet is onboard.

A program that trusts the SMBIOS (or requires that its claims validate) will not declare the Ethernet to be an onboard one, because it can't prove that. But proof is the wrong standard for consistent device naming in the face of the contradictory evidence we have here; what you want is the most likely and most consistent interpretation. I maintain that the preponderance of evidence from all of this is that there is indeed an onboard Ethernet and it is at 07:00.0.

(If you had multiple Ethernet devices you might want to be more cautious, depending on what you could determine about the other ones, but we don't here.)

On a side note, I looked at the dmidecode and biosdecode output on a SunFire X2100 (which has four onboard Ethernet ports). None of them were listed in dmidecode but all four of them were correctly identified as onboard devices in the PCI interrupt routing table from biosdecode. My overall conclusion from this is that the PIR is much more reliable than the DMI information, probably because things actually care about the PIR's information and malfunction if it isn't sufficiently correct.

Sidebar: sources of more information

The SMBIOS specification is reasonably readable, although it naturally assumes you understand things like PCI (which I don't really). DMI is the older standard which was apparently replaced by SMI (per here).

The problem with Fedora 15's consistent network device naming

Lately I've been doing a bunch of things with a real installed Fedora 15 machine (previous experimentation has mostly been with a Live USB stick used temporarily on various machines). One result of this is that I've actually noticed the name that Fedora 15 chose to give my ethernet as a result of its switch to consistent network device naming.

As it happens, my Fedora machine's Ethernet is now called p5p1. There are at least two problems with this name.

The first one is that it's wrong. Since this is an onboard Ethernet port, it should have an emN name (either em0 or em1 depending on which bit of documentation I read). It doesn't get the right name because biosdevname trusts the BIOS's information about what things are and aren't onboard devices. Yes, really, despite plenty of experience that trusting PC BIOSes for anything (or at least anything not required to boot Windows) mostly serves as a source of comedy gold (as long as you're at a safe distance).

The second problem is that this is a terrible name. Practically its sole virtue is that it's unique. It's not predictable (not without detailed information about the machine's bus topology and a good understanding of PCI), it's not very meaningful, and it's certainly not memorable. It's the kind of name that can only be sensibly used by programs that get it directly from the system's configuration in one way or another.

(There are a number of problems with slot based names, but one of them is that another machine with a different motherboard (but also onboard Ethernet) might well have a completely different name because its Ethernet controller is hooked up to the PCI(E) bus in a different 'slot' and a machine with a real network card (and no onboard network) will have yet another name.)

What this means is that while the idea of consistent network device naming may in theory be good, the tools for achieving it are not yet mature. Right now it certainly looks as if biosdevname is terminally naive and will frequently give wrong answers (I would guess that it gets things wrong more often than it gets them right).

(As it happens I think that there is enough information present in the output of biosdecode to deduce that the machine's Ethernet must be an onboard device, so it's clear that biosdevname should be able to do better. Possibly it needs to be taught about all of the common ways that BIOS creators get this information wrong and given heuristics for figuring out what the real situation is likely to be.)