Bug 710952

Summary: bultin interfaces named p19p1 and p20p1 on ECS H67H2-M
Product: [Fedora] Fedora Reporter: Tomasz Torcz <tomek>
Component: biosdevnameAssignee: Praveen K Paladugu <praveen_paladugu>
Status: CLOSED CANTFIX QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 15CC: harald, matt_domsch, mebrown, narendra_k, praveen_paladugu
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2011-11-15 14:08:46 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Attachments:
Description Flags
dmidecode.txt none

Description Tomasz Torcz 2011-06-05 23:29:34 UTC
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

Comment 1 Narendra K 2011-06-06 07:43:26 UTC
Hi, please attach dmidecode output and biosdecode output from your system ?

Comment 2 Tomasz Torcz 2011-06-06 07:52:13 UTC
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?

Comment 3 Narendra K 2011-06-06 12:37:58 UTC
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

Comment 4 Tomasz Torcz 2011-06-06 19:58:04 UTC
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?

Comment 5 Matt Domsch 2011-06-07 02:10:39 UTC
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.

Comment 6 Tomasz Torcz 2011-10-07 14:23:28 UTC
For the record. With 3.1.0-0.rc9.git0.0.fc16.i686.PAE cards get named p2p1 and p3p1.

Comment 7 Praveen K Paladugu 2011-11-15 14:08:46 UTC
This seems to be fixed in the kernel of the current release. So closing this bug.

Comment 8 Tomasz Torcz 2011-11-15 14:12:43 UTC
No, those interface are on board, should be em1 and em2. But if DMI is incorrect, what could kernel do?

Comment 9 Praveen K Paladugu 2011-11-15 14:48:24 UTC
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

Comment 10 Tomasz Torcz 2011-11-15 14:56:57 UTC
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.