Description of problem: The second port of a "Chelsio Communications Inc S320-LP-CR 10GbE Dual Port Adapter" is not getting a shiny new name from biosdevname. Version-Release number of selected component (if applicable): biosdevname-0.3.11-5.fc16.x86_64 How reproducible: Always Steps to Reproduce: This host is currently booted with biosdevname=0, hence the eth* kernel names. # /sbin/biosdevname --policy physical -d Actual results (embedded ethernet devices trimmed): BIOS device: p1p1 Kernel name: eth3 Permanent MAC: 00:07:43:06:4F:C6 Assigned MAC : 00:07:43:06:4F:C6 Driver: cxgb3 Driver version: 1.1.4-ko Firmware version: T 7.10.0 TP 1.1.0 Bus Info: 0000:0a:00.0 PCI name : 0000:0a:00.0 PCI Slot : 1 SMBIOS Label: PCI1 Index in slot: 1 BIOS device: Kernel name: eth4 Permanent MAC: 00:07:43:06:4F:C7 Assigned MAC : 00:07:43:06:4F:C7 Driver: cxgb3 Driver version: 1.1.4-ko Firmware version: T 7.10.0 TP 1.1.0 Bus Info: 0000:0a:00.0 Expected results: Same as above, except the one at the bottom marked as eth4 should be p1p2. Additional info: I didn't know if this was a biosdevname 'finding' issue, or a cxgb3 'presenting' issue. Feel free to move it as necessary.
Any traction on this? Is it that biosdevname doesn't handle cards that put a single entry in the PCI tree but handle 2 ports?
Hi Robert. That's exactly the problem. I had anticipated we might find ethernet cards that behaved as such, but had not actually run into one in practice. Thanks to my friends at Mellanox for creating a unique device in this respect. :-( It's also non-trivial for biosdevname to fix directly - it would be best if we could get that kind of info out of the kernel or driver. Arguably, it's there, but biosdevname has only a single pci_dev->eth pointer to store.
Your friends at Mellanox created the other problem (https://bugzilla.redhat.com/show_bug.cgi?id=757743) by making an infiniband device that creates ethernet interfaces. This is a Chelsio T3 card. We might have a spare one lying around if it would help.
Can you send output of lspci -vvvxxx, dmidecode, ethtool -i xxxx , etc
Created attachment 549242 [details] lspci -vvvxxxx from a host with a Chelsio T3 card in it
Created attachment 549243 [details] dmidecode from a host with a Chelsio T3 card in it
Created attachment 549244 [details] biosdecode from a host with a Chelsio T3 card in it
I added lspci, dmidecode, and biosdecode attachments. Here's the output of ethtool for the interface: driver: cxgb3 version: 1.1.4-ko firmware-version: T 7.10.0 TP 1.1.0 bus-info: 0000:0a:00.0 supports-statistics: yes supports-test: no supports-eeprom-access: yes supports-register-dump: yes
Also can you attach the output of the following: ls -l /sys/class/net/* cat /sys/class/net/*/ifindex
make that ls -Hl /sys/class/net/*
Created attachment 551141 [details] ls -lH of /sys/class/net/*
Created attachment 551142 [details] grep . /sys/class/net/*/ifindex
And in case it's not obvious from assembling all of the attachments: eth0-1 are onboard Broadcoms (since I currently have biosdevname=0). eth2-3 are the Chelsio T3, and eth4/ib0 is a Mellanox.
Any progress on this 1:many issue with biosdevname?
Hi, could you please give the biosdevname from here a try and share the results - https://bugzilla.redhat.com/show_bug.cgi?id=816536#c2
biosdevname-0.4.1-1.fc17 has been submitted as an update for Fedora 17. https://admin.fedoraproject.org/updates/biosdevname-0.4.1-1.fc17
Package biosdevname-0.4.1-1.fc17: * should fix your issue, * was pushed to the Fedora 17 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing biosdevname-0.4.1-1.fc17' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2012-10778/biosdevname-0.4.1-1.fc17 then log in and leave karma (feedback).
biosdevname-0.4.1-1.fc17 has been pushed to the Fedora 17 stable repository. If problems still persist, please make note of it in this bug report.