Hide Forgot
Created attachment 503136 [details] dmidecode.txt Description of problem: I have ECS H67H2-M motheboard, with two built-in Realtek gigabit interfaces. They receive names p19p1 and p20p1 instead of em1 and em2. Version-Release number of selected component (if applicable): biosdevname-0.3.8-1.fc15.i686 04:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 06) Subsystem: Elitegroup Computer Systems Device 811e Flags: bus master, fast devsel, latency 0, IRQ 47 I/O ports at e000 [size=256] Memory at d0104000 (64-bit, prefetchable) [size=4K] Memory at d0100000 (64-bit, prefetchable) [size=16K] Capabilities: [40] Power Management version 3 Capabilities: [50] MSI: Enable+ Count=1/1 Maskable- 64bit+ Capabilities: [70] Express Endpoint, MSI 01 Capabilities: [b0] MSI-X: Enable- Count=4 Masked- Capabilities: [d0] Vital Product Data Capabilities: [100] Advanced Error Reporting Capabilities: [140] Virtual Channel Capabilities: [160] Device Serial Number f8-0a-00-00-68-4c-e0-00 Kernel driver in use: r8169 Kernel modules: r8169 05:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 06) Subsystem: Elitegroup Computer Systems Device 811e Flags: bus master, fast devsel, latency 0, IRQ 48 I/O ports at d000 [size=256] Memory at d0004000 (64-bit, prefetchable) [size=4K] Memory at d0000000 (64-bit, prefetchable) [size=16K] Capabilities: [40] Power Management version 3 Capabilities: [50] MSI: Enable+ Count=1/1 Maskable- 64bit+ Capabilities: [70] Express Endpoint, MSI 01 Capabilities: [b0] MSI-X: Enable- Count=4 Masked- Capabilities: [d0] Vital Product Data Capabilities: [100] Advanced Error Reporting Capabilities: [140] Virtual Channel Capabilities: [160] Device Serial Number f9-0a-00-00-68-4c-e0-00 Kernel driver in use: r8169 Kernel modules: r8169 # biosdevname -d | grep -v MAC BIOS device: p19p1 Kernel name: p19p1 Driver: r8169 Driver version: 2.3LK-NAPI Firmware version: Bus Info: 0000:04:00.0 PCI name : 0000:04:00.0 PCI Slot : 19 Index in slot: 1 BIOS device: p20p1 Kernel name: p20p1 Driver: r8169 Driver version: 2.3LK-NAPI Firmware version: Bus Info: 0000:05:00.0 PCI name : 0000:05:00.0 PCI Slot : 20 Index in slot: 1
Hi, please attach dmidecode output and biosdecode output from your system ?
dmidecode already attached, bios decode: # biosdecode 2.11 ACPI 2.0 present. OEM Identifier: ALASKA RSD Table 32-bit Address: 0xB6DCC028 XSD Table 64-bit Address: 0x00000000B6DCC078 SMBIOS 2.6 present. Structure Table Length: 3780 bytes Structure Table Address: 0x000EB070 Number Of Structures: 107 Maximum Structure Size: 184 bytes PNP BIOS 1.0 present. Event Notification: Not Supported Real Mode 16-bit Code Address: F000:BC86 Real Mode 16-bit Data Address: F000:0000 16-bit Protected Mode Code Address: 0x000FBCAE 16-bit Protected Mode Data Address: 0x000F0000 PCI Interrupt Routing 1.0 present. Router ID: 00:1f.0 Exclusive IRQs: None Compatible Router: 8086:27b8 Slot Entry 1: ID 00:1f, on-board Slot Entry 2: ID 00:1b, on-board Slot Entry 3: ID 00:16, on-board Slot Entry 4: ID 00:1c, on-board Slot Entry 5: ID 01:00, slot number 17 Slot Entry 6: ID 02:00, slot number 18 Slot Entry 7: ID 04:00, slot number 19 Slot Entry 8: ID 05:00, slot number 20 Slot Entry 9: ID 06:00, slot number 23 Slot Entry 10: ID 00:01, on-board Slot Entry 11: ID 00:06, on-board Slot Entry 12: ID 00:1d, on-board Slot Entry 13: ID 00:1a, on-board Slot Entry 14: ID 00:02, on-board Slot Entry 15: ID 00:00, on-board I see the problem here, PIRQ talks about slot numbers. I understand that ECS need to fix that in BIOS. What would be the message to send them?
Hi, thank you. Biosdevname looks for SMBIOS type 41 records for the Onboard NICs to name them em1 and em2. If there is no type 41 records available, biosdevname falls back on PIR table. Here the bus address of onboard NICs is not matching with what is listed in type 41 records, so biodevname is falling back on PIR table (where the onboard NICs are listed as add-on). *From the attached dmidecode output it looks like the type 41 records for the onboard NICs are wrong. Handle 0x0064, DMI type 41, 11 bytes Onboard Device Reference Designation: Onboard LAN Type: Ethernet Status: Enabled Type Instance: 1 Bus Address: 0000:00:19.0-------------->1 Handle 0x0065, DMI type 41, 11 bytes Onboard Device Reference Designation: Onboard 1394 Type: Other Status: Enabled Type Instance: 1----------------------->2 Bus Address: 0000:03:1c.2-------------->3 Observe 1 and 2 and 3. The 'Bus Address: 0000:00:19.0' for the first NIC is different than what you have noted in issue description (lspci shows 04:00.0). Same is the case for NIC 2 Bus Address: 0000:03:1c.2 (lspci shows 05:00.0). The type 41 records Bus Address should be same as reported by lspci. The 'Type Instance' for the second NIC is 1. I think it has to be 2. * The PIR Table seems to be listing the onboard NICs as add-on. I think they have to be listed as 'on-board'. Slot Entry 7: ID 04:00, slot number 19 Slot Entry 8: ID 05:00, slot number 20
Looking closer, the second DMI entry is designated as 1394 (Firewire). It is not LAN card. Furthermore, this motherboard do not have IEEE1394 connectors. So looks like BIOS tables are screwed up. What can be done?
Please raise it with the system manufacturer. Until then, you can disable biosdevname (either remove the package, or use biosdevname=0 on the kernel command line) to revert to ethX naming convention.
For the record. With 3.1.0-0.rc9.git0.0.fc16.i686.PAE cards get named p2p1 and p3p1.
This seems to be fixed in the kernel of the current release. So closing this bug.
No, those interface are on board, should be em1 and em2. But if DMI is incorrect, what could kernel do?
Sorry my misunderstanding. This is not a kernel/biosdevname issue. Would you like to keep this bug open until it is fixed by your manufacturer? We were trying to close some of the biosdevname issues and this one seems like a good one to close. Yes, I understand the above reason is wrong. Praveen
Well, I reported it to manufacturer, but as always, bugs only seen in Linux are lowest possible priority. This bug may be closed, but as CANTFIX. Thanks.