Bug 201144 - [ixgbe] [xl] 82599es-based card Supermicro AOC-STGN-i2S is not working
Summary: [ixgbe] [xl] 82599es-based card Supermicro AOC-STGN-i2S is not working
Status: Closed Not A Bug
Alias: None
Product: Base System
Classification: Unclassified
Component: kern (show other bugs)
Version: CURRENT
Hardware: amd64 Any
: --- Affects Some People
Assignee: freebsd-net (Nobody)
Keywords: IntelNetworking, patch
Depends on:
Reported: 2015-06-27 09:22 UTC by Denis V. Meltsaykin
Modified: 2015-07-03 18:57 UTC (History)
2 users (show)

See Also:

patch to support 0x0001 product_id (1.05 KB, patch)
2015-06-27 09:22 UTC, Denis V. Meltsaykin
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Denis V. Meltsaykin 2015-06-27 09:22:25 UTC
Created attachment 158093 [details]
patch to support 0x0001 product_id

I have 3 NICs marked as Supermicro AOC-STGN-i2S, these are actually 82599es-based cards with two SFP+ onboard. Driver `xgbe` doesn't recognise them, although it should. I've made a small patch to the driver and those card are working now. Please review the change and if it makes sence please add the corresponding product_id to the driver.


ix0@pci0:2:0:0: class=0x020000 card=0x10fb1b52 chip=0x00018086 rev=0x01 hdr=0x00
    vendor     = 'Intel Corporation'
    class      = network
    subclass   = ethernet
Comment 1 Denis V. Meltsaykin 2015-06-27 09:35:59 UTC
The tests with iperf were successful, but in dmesg there is a strange message:

lock order reversal:
 1st 0xfffff80004a16320 ix0:rx(3) (ix0:rx(3)) @ /usr/src/sys/dev/ixgbe/ix_txrx.c:1759
 2nd 0xfffff8002345ef08 vlan (vlan) @ /usr/src/sys/net/if_vlan.c:1155
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe03e4b2c5d0
kdb_backtrace() at kdb_backtrace+0x39/frame 0xfffffe03e4b2c680
witness_checkorder() at witness_checkorder+0xea5/frame 0xfffffe03e4b2c710
_rm_rlock_debug() at _rm_rlock_debug+0x114/frame 0xfffffe03e4b2c750
vlan_input() at vlan_input+0xc8/frame 0xfffffe03e4b2c7d0
ether_demux() at ether_demux+0xb3/frame 0xfffffe03e4b2c800
ether_nh_input() at ether_nh_input+0x340/frame 0xfffffe03e4b2c830
netisr_dispatch_src() at netisr_dispatch_src+0x86/frame 0xfffffe03e4b2c8a0
ether_input() at ether_input+0x4f/frame 0xfffffe03e4b2c8d0
tcp_lro_flush() at tcp_lro_flush+0x198/frame 0xfffffe03e4b2c8f0
ixgbe_rxeof() at ixgbe_rxeof+0x732/frame 0xfffffe03e4b2c9a0
ixgbe_msix_que() at ixgbe_msix_que+0xb6/frame 0xfffffe03e4b2c9f0
intr_event_execute_handlers() at intr_event_execute_handlers+0x93/frame 0xfffffe03e4b2ca30
ithread_loop() at ithread_loop+0xa6/frame 0xfffffe03e4b2ca70
fork_exit() at fork_exit+0x84/frame 0xfffffe03e4b2cab0
fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe03e4b2cab0
--- trap 0, rip = 0, rsp = 0xfffffe03e4b2cb70, rbp = 0 ---
Comment 2 Eric Joyner freebsd_committer 2015-07-03 18:57:12 UTC
Hi Denis,

I'm closing this because this isn't a driver problem. No Intel 10G device has a device ID of "0x0001", so this is a problem with your cards. You need to go back to whoever you purchased the cards from and either return it or work with them to get a correct EEPROM for your cards.

However, if you get that resolved and the lock order reversal still occurs, that would be a valid bug to put in a new ticket.