Bug 756164

Summary: second port of cxgb3 card not being named by biosdevname
Product: [Fedora] Fedora Reporter: Robert Kennedy <rt>
Component: biosdevnameAssignee: Narendra K <narendra_k>
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: unspecified    
Version: 16CC: harald, jordan_hargrave, matt_domsch, mebrown, narendra_k, praveen_paladugu, the.ridikulus.rat
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2012-07-26 22:32:51 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
lspci -vvvxxxx from a host with a Chelsio T3 card in it
none
dmidecode from a host with a Chelsio T3 card in it
none
biosdecode from a host with a Chelsio T3 card in it
none
ls -lH of /sys/class/net/*
none
grep . /sys/class/net/*/ifindex none

Description Robert Kennedy 2011-11-22 20:59:54 UTC
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.

Comment 1 Robert Kennedy 2011-12-09 16:11:07 UTC
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?

Comment 2 Matt Domsch 2011-12-10 15:15:15 UTC
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.

Comment 3 Robert Kennedy 2011-12-14 13:16:11 UTC
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.

Comment 4 jordan hargrave 2011-12-22 20:08:02 UTC
Can you send output of lspci -vvvxxx, dmidecode, ethtool -i xxxx , etc

Comment 5 Robert Kennedy 2011-12-22 21:12:13 UTC
Created attachment 549242 [details]
lspci -vvvxxxx from a host with a Chelsio T3 card in it

Comment 6 Robert Kennedy 2011-12-22 21:12:56 UTC
Created attachment 549243 [details]
dmidecode from a host with a Chelsio T3 card in it

Comment 7 Robert Kennedy 2011-12-22 21:13:31 UTC
Created attachment 549244 [details]
biosdecode from a host with a Chelsio T3 card in it

Comment 8 Robert Kennedy 2011-12-22 21:14:09 UTC
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

Comment 9 jordan hargrave 2012-01-03 19:49:30 UTC
Also can you attach the output of the following:

ls -l /sys/class/net/*
cat /sys/class/net/*/ifindex

Comment 10 jordan hargrave 2012-01-03 19:58:56 UTC
make that ls -Hl /sys/class/net/*

Comment 11 Robert Kennedy 2012-01-06 12:52:56 UTC
Created attachment 551141 [details]
ls -lH of /sys/class/net/*

Comment 12 Robert Kennedy 2012-01-06 12:53:52 UTC
Created attachment 551142 [details]
grep . /sys/class/net/*/ifindex

Comment 13 Robert Kennedy 2012-01-06 12:57:52 UTC
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.

Comment 14 Robert Kennedy 2012-02-14 20:53:41 UTC
Any progress on this 1:many issue with biosdevname?

Comment 15 Narendra K 2012-05-02 14:41:07 UTC
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

Comment 16 Fedora Update System 2012-07-18 13:36:33 UTC
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

Comment 17 Fedora Update System 2012-07-19 09:02:30 UTC
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).

Comment 18 Fedora Update System 2012-07-26 22:32:51 UTC
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.