Bug 757743
Description
Robert Kennedy
2011-11-28 15:20:19 UTC
Hi Robert, could you please attach the output of the following - dmidecode biosdecode lspci -tv lspci -vvvxxxx Created attachment 538159 [details]
dmidecode from a host with a Mellanox card in it
Created attachment 538160 [details]
biosdecode from a host with a Mellanox card in it
Created attachment 538161 [details]
lspci -tv from a host with a Mellanox card in it
Created attachment 538162 [details]
lspci -vvvxxxx from a host with a Mellanox card in it
The attached lspci -vvv shows that the ConnectX card is at '0c:00.0' 0c:00.0 InfiniBand: Mellanox Technologies MT26428 [ConnectX VPI PCIe 2.0 5GT/s - IB QDR / 10GigE] (rev b0) The 'Bus info' shown by biosdevname -d is '0000:04:00.0' and lspci shows that '0000:04:00.0' it a PCI bridge 04:00.0 PCI bridge: Intel Corporation 6311ESB/6321ESB PCI Express Upstream Port (rev 01) (prog-if 00 [Normal decode]) So biosdevname returns without suggesting any name as '04:00.0' is not a 'network class' device. It seems like the mlx4_en is returning incorrect information for ethtool 'getdriverinfo' command. Hi Robert, Could you please post the output from 'ethtool -i eth4' ? Hmmm. I'm wondering if I didn't accidentally give you info from 2 different hosts between the initial bug report and the attachments. When I went to check, this is what I found on the same host: ethtool -i: driver: mlx4_en version: 1.5.4.1 (March 2011) firmware-version: 2.9.1000 bus-info: 0000:0c:00.0 supports-statistics: yes supports-test: yes supports-eeprom-access: no supports-register-dump: no biosdevname -d: BIOS device: Kernel name: eth4 Permanent MAC: 00:02:C9:0D:74:6D Assigned MAC : 00:02:C9:0D:74:6D Driver: mlx4_en Driver version: 1.5.4.1 (March 2011) Firmware version: 2.9.1000 Bus Info: 0000:0c:00.0 and lspci: 0c:00.0 InfiniBand: Mellanox Technologies MT26428 [ConnectX VPI PCIe 2.0 5GT/s - IB QDR / 10GigE] (rev b0) So the bus info matches up but no still no "BIOS device". Sorry for the confusion. Ok. Thanks. Could you please post the output from cat /sys/class/net/eth4/device/class It could be that the class of the device is not "network" (0x020000),so biosdevname is not considering it as a network device. /sys/class/net/eth4/device/class is 0x0c0600. Sooo. I guess this combo card thinks of itself as a Serial device (Infiniband) first. It seems like this adapter is not being added to the 'bios devices list' because In file "src/bios_device.c", function 'match_all' 1.the following check fails, as it is not PCI class network. if (!is_pci_network(p)) continue; 2. if (!is_ethernet(n)) /* for virtual interfaces */ continue; I will try to see if i can find this adapter and reproduce this issue. Created attachment 546719 [details]
Patch to consider serial/infiniband PCI devices for biosdevname ethernet devices
Well, the most straightforward thing to do is to consider 0x0c06 devices...
It looks like there is further probing to determine if such a thing is actually an ethernet device, so hopefully this won't break the world for the IB folks. It doesn't seem to affect the ib0 interface of the Mellanox card in our environment.
BIOS device: p2p1
Kernel name: eth4
Permanent MAC: 00:02:C9:4B:E3:AF
Assigned MAC : 00:02:C9:4B:E3:AF
Driver: mlx4_en (MT_0DD0120009)
Driver version: 1.5.3 (Jan 2011)
Firmware version: 2.9.1000
Bus Info: 0000:0c:00.0
PCI name : 0000:0c:00.0
PCI Slot : 2
SMBIOS Label: PCI2
Index in slot: 1
can you attach output of : ls -Hl /sys/class/net/* cat /sys/class/net/*/ifindex Created attachment 551144 [details]
ls -lh /sys/class/net/* from a host with a Mellanox in it
Created attachment 551145 [details]
grep . /sys/class/net/*/ifindex from a host with a Mellanox in it
Yes, these are the same files from case 756164, both troublesome cards are in the same host.
Has there been any discussion in the last month over whether or not Serial/Infiniband devices should be considered for biosdevnaming? I can certainly maintain a locally patched copy but I'd like to know the general consensus, or if there is a better place to put the lever. 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. |