Project

General

Profile

Bug #26135

10GB intel X520/540 port issue

Added by Wayne Garrison over 3 years ago. Updated over 3 years ago.

Status:
Closed: Duplicate
Priority:
No priority
Assignee:
Alexander Motin
Category:
OS
Target version:
Seen in:
Severity:
New
Reason for Closing:
Reason for Blocked:
Needs QA:
Yes
Needs Doc:
Yes
Needs Merging:
Yes
Needs Automation:
No
Support Suite Ticket:
n/a
Hardware Configuration:

Intel(R) Xeon(R) CPU E5-2680 v2 @ 2.80GHz
Supermicro X9-DAi

ChangeLog Required:
No

Description

Hi,

Since the latest update, we appear to have lost the second port on our X520-DA2 (ix1) SFP+ port.

Any ideas as to what to do?

{
root@nas:~ # ifconfig
ix0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 9000
options=e407bb<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,TSO4,TSO6,LRO,VLAN_HWTSO,RXCSUM_IPV6,TXCSUM_IPV6>
ether a0:36:9f:72:37:9a
inet 192.168.240.1 netmask 0xffffff00 broadcast 192.168.240.255
nd6 options=9<PERFORMNUD,IFDISABLED>
media: Ethernet autoselect (10Gbase-Twinax <full-duplex,rxpause,txpause>)
status: active
igb0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 9000
options=6403bb<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,TSO4,TSO6,VLAN_HWTSO,RXCSUM_IPV6,TXCSUM_IPV6>
ether 14:dd:a9:d5:e1:6a
inet 192.168.0.206 netmask 0xffffff00 broadcast 192.168.0.255
nd6 options=9<PERFORMNUD,IFDISABLED>
media: Ethernet autoselect (1000baseT <full-duplex>)
status: active
igb1: flags=8c02<BROADCAST,OACTIVE,SIMPLEX,MULTICAST> metric 0 mtu 1500
options=6403bb<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,TSO4,TSO6,VLAN_HWTSO,RXCSUM_IPV6,TXCSUM_IPV6>
ether 14:dd:a9:d5:e1:6b
nd6 options=9<PERFORMNUD,IFDISABLED>
media: Ethernet autoselect
status: no carrier
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384
options=600003<RXCSUM,TXCSUM,RXCSUM_IPV6,TXCSUM_IPV6>
inet6 ::1 prefixlen 128
inet6 fe80::1%lo0 prefixlen 64 scopeid 0x4
inet 127.0.0.1 netmask 0xff000000
nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
groups: lo
}

{root@nas:~ # netstat -i
Name Mtu Network Address Ipkts Ierrs Idrop Opkts Oerrs Coll
ix0 9000 <Link#1> a0:36:9f:72:37:9a 21963973 0 0 29166542 0 0
ix0 - 192.168.240.0 192.168.240.1 13562496 - - 28140763 - -
igb0 9000 <Link#2> 14:dd:a9:d5:e1:6a 300947600 0 0 306025759 0 0
igb0 - 192.168.0.0/2 nas 300561657 - - 305999496 - -
igb1* 1500 <Link#3> 14:dd:a9:d5:e1:6b 0 0 0 0 0 0
lo0 16384 <Link#4> lo0 223345 0 0 223345 0 0
lo0 - localhost localhost 18 - - 18 - -
lo0 - fe80::%lo0/64 fe80::1%lo0 0 - - 0 - -
lo0 - your-net localhost 223065 - - 223121 - -
}


Related issues

Related to FreeNAS - Bug #24820: Update ixl(4) driverResolved2017-06-26

History

#1 Updated by Wayne Garrison over 3 years ago

  • File debug-nas-20171010105427.txz added

#2 Updated by Wayne Garrison over 3 years ago

  • Seen in changed from Unspecified to 11.0-U4
  • Hardware Configuration updated (diff)

#3 Updated by Dru Lavigne over 3 years ago

  • Assignee changed from Release Council to Alexander Motin

#4 Updated by Alexander Motin over 3 years ago

  • Status changed from Unscreened to Closed: User Config Issue

As I see, you really lost the first port, it is just second one now become ix0. In your debug info I see:

ix0: <Intel(R) PRO/10GbE PCI-Express Network Driver, Version - 3.1.13-k> port 0xd020-0xd03f mem 0xdb300000-0xdb3fffff,0xdb504000-0xdb507
ix0: Using MSIX interrupts with 9 vectors
ix0: Unsupported SFP+ Module
device_attach: ix0 attach returned 5

You may try to add loader tunable `hw.ix.unsupported_sfp=1` to workaround that on your risk, but you should first check what SFP+ module you are using there and whether it was certified by Intel for use with this NIC.

#5 Updated by Dru Lavigne over 3 years ago

  • File deleted (debug-nas-20171010105427.txz)

#6 Updated by Dru Lavigne over 3 years ago

  • Target version set to N/A
  • Private changed from Yes to No

#7 Updated by Wayne Garrison over 3 years ago

Alexander Motin wrote:

As I see, you really lost the first port, it is just second one now become ix0. In your debug info I see:
[...]

You may try to add loader tunable `hw.ix.unsupported_sfp=1` to workaround that on your risk, but you should first check what SFP+ module you are using there and whether it was certified by Intel for use with this NIC.

Yes absolutely, this is a genuine Intel X520-DA2 (I have this in 2 machines and another with an X710-DA2.

I'll try this workaround to see if the issue is resolved, and report back.

Thanks for your update.

#8 Updated by Alexander Motin over 3 years ago

Wayne Garrison wrote:

Yes absolutely, this is a genuine Intel X520-DA2 (I have this in 2 machines and another with an X710-DA2.

The card may be genuine, but what about SFP+ transceiver or twinax cable plugged into it?

#9 Updated by Wayne Garrison over 3 years ago

Alexander Motin wrote:

Wayne Garrison wrote:

Yes absolutely, this is a genuine Intel X520-DA2 (I have this in 2 machines and another with an X710-DA2.

The card may be genuine, but what about SFP+ transceiver or twinax cable plugged into it?

Yes all cables are genuine, using Cisco or other main brand genuine cables.

Issue only started after updating to the latest version.

Apologies for late response.

#10 Updated by Dru Lavigne over 3 years ago

  • Status changed from Closed: User Config Issue to Investigation
  • Target version deleted (N/A)

#11 Updated by Alexander Motin over 3 years ago

  • Status changed from Investigation to 15

Have you tried to set the tunable?

Also you may try nightly builds, which are going to become 11.1 release some time soon, since the ixl(4) driver there updated from version 1.6.6 to 1.7.12. May be it change something.

#12 Updated by Wayne Garrison over 3 years ago

Alexander Motin wrote:

Have you tried to set the tunable?

Also you may try nightly builds, which are going to become 11.1 release some time soon, since the ixl(4) driver there updated from version 1.6.6 to 1.7.12. May be it change something.

I'll try the nightly build and get back to you.

I did set the tunable to no effect.

Were there any driver changes in U4 over U3 that could explain this at all? It's literally since that update...

#13 Updated by Wayne Garrison over 3 years ago

Wayne Garrison wrote:

Alexander Motin wrote:

Have you tried to set the tunable?

Also you may try nightly builds, which are going to become 11.1 release some time soon, since the ixl(4) driver there updated from version 1.6.6 to 1.7.12. May be it change something.

I'll try the nightly build and get back to you.

I did set the tunable to no effect.

Were there any driver changes in U4 over U3 that could explain this at all? It's literally since that update...

Issue resolved with alpha release.

Thanks for your help!

#14 Updated by Alexander Motin over 3 years ago

Wayne Garrison wrote:

Were there any driver changes in U4 over U3 that could explain this at all? It's literally since that update...

No, there wasn't any changes in ixl(4) driver. It must be coincidence.

#15 Updated by Alexander Motin over 3 years ago

  • Status changed from 15 to Ready For Release
  • Target version set to 11.1-RC1

Wayne Garrison wrote:

Issue resolved with alpha release.

OK.

#16 Updated by Dru Lavigne over 3 years ago

  • Related to Bug #24820: Update ixl(4) driver added

#17 Updated by Dru Lavigne over 3 years ago

  • Status changed from Ready For Release to Closed: Duplicate
  • Target version changed from 11.1-RC1 to N/A

I'll mark this one as a duplicate of #24820.

Also available in: Atom PDF