Description of problem: Yesterday, I updated biosdevname from 0.3.8-1.fc15.x86_64 to 0.3.11-1.fc15.x86_64. Today, I noticed the onboard wired NIC changed its name from em1 (which it had since F15 was installed) to p5p1. The correct name should be em1, since it is the first (and only) onboard Ethernet port on this laptop. The logs show this change happened today (yesterday and before it was still em1). Version-Release number of selected component (if applicable): biosdevname-0.3.11-1.fc15.x86_64 udev-167-6.fc15.x86_64 kernel-2.6.40.6-0.fc15.x86_64 How reproducible: Tried only once so far. Steps to Reproduce: 1. Reboot after updating biosdevname Actual results: [ 24.193527] atl1c 0000:04:00.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17 [ 24.193545] atl1c 0000:04:00.0: setting latency timer to 64 [ 24.294511] atl1c 0000:04:00.0: version 1.0.1.0-NAPI [ 27.789475] atl1c 0000:04:00.0: vpd r/w failed. This is likely a firmware bug on this device. Contact the card vendor for a firmware update. [ 27.829810] udev[549]: renamed network interface eth0 to p5p1 [ 74.944000] atl1c 0000:04:00.0: irq 44 for MSI/MSI-X Expected results: (These are from a dmesg from 2.6.40.4-5.fc15.x86_64 I had lying around, but it was the same with 2.6.40.6-0.fc15.x86_64 before the biosdevname update.) [ 28.386194] atl1c 0000:04:00.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17 [ 28.386211] atl1c 0000:04:00.0: setting latency timer to 64 [ 28.487174] atl1c 0000:04:00.0: version 1.0.1.0-NAPI [ 32.921753] atl1c 0000:04:00.0: vpd r/w failed. This is likely a firmware bug on this device. Contact the card vendor for a firmware update. [ 32.960065] udev[554]: renamed network interface eth0 to em1 [ 93.828466] atl1c 0000:04:00.0: irq 44 for MSI/MSI-X Additional info: dmidecode and biosdecode output will follow as attachments.
Created attachment 527941 [details] dmidecode
Created attachment 527942 [details] biosdecode
Hi, could you please attach the output of 1. biosdevname -d 2. lspci -tv from this system ?
Created attachment 528118 [details] biosdevname -d
Created attachment 528119 [details] lspci -tv
We have a lab of 50 machines, most of which picked up biosdevname-0.3.11 in updates yesterday. Today none of the updated machines has a network connection because they changed their interface names from em1 to p6p1. Sadface. # biosdevname -d BIOS device: p6p1 Kernel name: p6p1 Permanent MAC: 00:1B:78:3C:B4:F2 Assigned MAC : 00:1B:78:3C:B4:F2 Driver: tg3 Driver version: 3.119 Firmware version: 5755-v3.17 Bus Info: 0000:3f:00.0 PCI name : 0000:3f:00.0 PCI Slot : 6 Index in slot: 1
biosdevname 0.3.11 uses the PCIE slot number (correct #) to determine which slot the card is in. Older versions of biosdevname used the $PIR table only, which was incorrect on many BIOS. The slot numbering scheme in the $PIR table is also inconsistent between vendors.. some have slot 1,2,3, etc others had hex value 34 = decimal '4'. So you may see p3X... change to the correct PCI slot. can you provide output of lspci -vvvxxxx
Created attachment 528648 [details] lspci -vvvxxxx This command also prints the following to stderr: pcilib: sysfs_read_vpd: read failed: Connection timed out Additionally, it prints the following to dmesg: atl1c 0000:04:00.0: vpd r/w failed. This is likely a firmware bug on this device. Contact the card vendor for a firmware update.
(In reply to comment #7) > So you may see p3X... change to the correct PCI slot. Note that I am not seeing p3X... change to the correct PCI slot, I am seeing em1 (which was correct, since it is an onboard wired Ethernet NIC) change to a PCI slot (p5p1).
Looks like the same root cause though. According to lspci, the parent bridge of the Ethernet controller (00:1c.5) lists Slot Capabilities field as valid, with Slot#5 listed... so your system is not following the PCI specification properly if that is really an embedded device.
(In reply to comment #10) > Looks like the same root cause though. According to lspci, the parent bridge > of the Ethernet controller (00:1c.5) lists Slot Capabilities field as valid, > with Slot#5 listed... so your system is not following the PCI specification > properly if that is really an embedded device. Will it stay as p5p1 on this Dell laptop then? If so, I will hand-edit the relevant files on /etc (changing em1 to p5p1) so everything keeps working the same. If not, I will keep them as em1 and wait a bit more. Even if p5p1 is wrong, it is just a name, and as long as it does not keep changing, it is no big deal.
Created attachment 528772 [details] lspci -vvvxxxx Same here; attached is what lspci says, and following is what biosdecode says about the PIR table: Router ID: 00:14.3 Exclusive IRQs: None Slot Entry 1: ID 07:04, slot number 1 Slot Entry 2: ID 07:09, slot number 2 Slot Entry 3: ID 00:01, on-board Slot Entry 4: ID 01:05, on-board Slot Entry 5: ID 00:02, on-board Slot Entry 6: ID 02:00, slot number 1 Slot Entry 7: ID 00:06, on-board Slot Entry 8: ID 20:00, slot number 1 Slot Entry 9: ID 00:07, on-board Slot Entry 10: ID 3f:00, on-board Slot Entry 11: ID 00:12, on-board Slot Entry 12: ID 00:13, on-board Slot Entry 13: ID 00:14, on-board PIR is right here - it's on-board. (Opinion warning:) Regardless of whether the old way was "wrong" I think a change of this nature should have been delayed until the next Fedora release, because it's potentially disruptive to suddenly find your ethernet adaptor changed its name. I've uninstalled biosdevname from our machines now as it's of limited use when the machine only has one ethernet port anyway. Oh well.
Yeah.. it's definitely an unintended consequence of adding the PCIE slot calculation. :( We didn't see any slot numbering changes though on the systems we tested. Unfortunately it looks like the $PIR on other systems is usually incorrect and doesn't match.
*** This bug has been marked as a duplicate of bug 746422 ***