* [Intel-wired-lan] i40e: Deadly GRE packet
@ 2016-04-21 12:45 =?unknown-8bit?q?Micha=C5=82_Miros=C5=82aw?=
2016-04-21 14:51 ` [Intel-wired-lan] [E1000-devel] " Wyborny, Carolyn
` (2 more replies)
0 siblings, 3 replies; 13+ messages in thread
From: =?unknown-8bit?q?Micha=C5=82_Miros=C5=82aw?= @ 2016-04-21 12:45 UTC (permalink / raw)
To: intel-wired-lan
Dear Developers,
I have a setup of a pair of SuperMicro-branded XL710s connected with
passive crossover cable, one (eth4) is using firmware 5.0, the other (eth7)
is using fw 4.33. When I send couple of packets with no payload in GRE over
IP over ETH from eth7 to eth4, the receiving card stops processing further
packets. It seems that 4 empty-GRE packets in succession are enough to kill
the card's receivers (all ports stop working), more if there are other
packets inbetween. Transmit direction is not affected. After reboot, the
card comes back, reloading the driver (or unbind/bind) is not enough to fix
the problem.
14:31:24.299203 00:00:00:00:00:00 > ff:ff:ff:ff:ff:ff, ethertype IPv4
(0x0800), length 60: (tos 0x0, ttl 64, id 1, offset 0, flags [none], proto
GRE (47), length 24)
127.0.0.1 > 127.0.0.1: GREv0, Flags [none], proto unknown (0x0000),
length 4
gre-proto-0x0
0x0000: 4500 0018 0001 0000 402f 7cb4 7f00 0001 E.......@/|.....
0x0010: 7f00 0001 0000 0000 0000 0000 0000 0000 ................
0x0020: 0000 0000 0000 0000 0000 0000 0000 ..............
scapy 2.2.0 generates this packet from: Ether()/IP()/GRE()
Tested on stock Debian kernel, with in-kernel driver and one from DPDK-2.2.
Linux lab1 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt25-2 (2016-04-08) x86_64
GNU/Linux
Best Regards,
Micha? Miros?aw
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osuosl.org/pipermail/intel-wired-lan/attachments/20160421/904d2af4/attachment-0001.html>
-------------- next part --------------
# ethtool -i eth4
driver: i40e
version: 0.4.10-k
firmware-version: f5.0 a1.5 n05.02 e80002283
bus-info: 0000:01:00.2
supports-statistics: yes
supports-test: yes
supports-eeprom-access: yes
supports-register-dump: yes
supports-priv-flags: no
# lspci -vvvs 0000:01:00.2
01:00.2 Ethernet controller: Intel Corporation Ethernet Controller X710 for 10GbE SFP+ (rev 01)
Subsystem: Intel Corporation Ethernet Converged Network Adapter X710
Physical Slot: 0
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0, Cache Line Size: 64 bytes
Interrupt: pin A routed to IRQ 26
Region 0: Memory at 91800000 (64-bit, prefetchable) [size=8M]
Region 3: Memory at 92c10000 (64-bit, prefetchable) [size=32K]
Expansion ROM at fb380000 [disabled] [size=512K]
Capabilities: [40] Power Management version 3
Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold-)
Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=1 PME-
Capabilities: [50] MSI: Enable- Count=1/1 Maskable+ 64bit+
Address: 0000000000000000 Data: 0000
Masking: 00000000 Pending: 00000000
Capabilities: [70] MSI-X: Enable+ Count=129 Masked-
Vector table: BAR=3 offset=00000000
PBA: BAR=3 offset=00001000
Capabilities: [a0] Express (v2) Endpoint, MSI 00
DevCap: MaxPayload 2048 bytes, PhantFunc 0, Latency L0s <512ns, L1 <64us
ExtTag+ AttnBtn- AttnInd- PwrInd- RBE+ FLReset+
DevCtl: Report errors: Correctable+ Non-Fatal+ Fatal+ Unsupported+
RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop- FLReset-
MaxPayload 256 bytes, MaxReadReq 512 bytes
DevSta: CorrErr+ UncorrErr- FatalErr- UnsuppReq+ AuxPwr- TransPend-
LnkCap: Port #0, Speed 8GT/s, Width x8, ASPM L1, Exit Latency L0s <2us, L1 <16us
ClockPM- Surprise- LLActRep- BwNot-
LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- CommClk+
ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
LnkSta: Speed 8GT/s, Width x8, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
DevCap2: Completion Timeout: Range ABCD, TimeoutDis+, LTR-, OBFF Not Supported
DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis-, LTR-, OBFF Disabled
LnkSta2: Current De-emphasis Level: -6dB, EqualizationComplete-, EqualizationPhase1-
EqualizationPhase2-, EqualizationPhase3-, LinkEqualizationRequest-
Capabilities: [e0] Vital Product Data
Product Name: Supermicro Network Adapter
Read-only fields:
[PN] Part number: AOC-STG-i4S\x00\x00\x00\x00
[V0] Vendor specific: 0100
[V1] Vendor specific: 1.01\x00
[SN] Serial number: VA158S014437\x00\x00\x00\x00\x00\x00\x00
[VA] Vendor specific: 4
[V2] Vendor specific: 0CC47ABCA188
[V3] Vendor specific: 0CC47ABCA189
[V4] Vendor specific: 0CC47ABCA18A
[V5] Vendor specific: 0CC47ABCA18B
[RV] Reserved: checksum good, 0 byte(s) reserved
Read/write fields:
[VB] Vendor specific: \x00
End
Capabilities: [100 v2] Advanced Error Reporting
UESta: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
UEMsk: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
UESvrt: DLP+ SDES+ TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol-
CESta: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr+
CEMsk: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr+
AERCap: First Error Pointer: 00, GenCap+ CGenEn- ChkCap+ ChkEn-
Capabilities: [140 v1] Device Serial Number 88-a1-bc-ff-ff-7a-c4-0c
Capabilities: [150 v1] Alternative Routing-ID Interpretation (ARI)
ARICap: MFVC- ACS-, Next Function: 3
ARICtl: MFVC- ACS-, Function Group: 0
Capabilities: [160 v1] Single Root I/O Virtualization (SR-IOV)
IOVCap: Migration-, Interrupt Message Number: 000
IOVCtl: Enable- Migration- Interrupt- MSE- ARIHierarchy-
IOVSta: Migration-
Initial VFs: 32, Total VFs: 32, Number of VFs: 0, Function Dependency Link: 02
VF offset: 78, stride: 1, Device ID: 154c
Supported Page Size: 00000553, System Page Size: 00000001
Region 0: Memory at 0000000092800000 (64-bit, prefetchable)
Region 3: Memory@0000000092d20000 (64-bit, prefetchable)
VF Migration: offset: 00000000, BIR: 0
Capabilities: [1a0 v1] Transaction Processing Hints
Device specific mode supported
No steering table available
Capabilities: [1b0 v1] Access Control Services
ACSCap: SrcValid- TransBlk- ReqRedir- CmpltRedir- UpstreamFwd- EgressCtrl- DirectTrans-
ACSCtl: SrcValid- TransBlk- ReqRedir- CmpltRedir- UpstreamFwd- EgressCtrl- DirectTrans-
Kernel driver in use: i40e
[ 0.955651] pci 0000:01:00.2: reg 0x190: [mem 0x00000000-0x00003fff 64bit pref]
[ 0.955653] pci 0000:01:00.2: BAR 10: can't assign mem pref (size 0x80000)
[ 0.956500] pci 0000:01:00.2: reg 0x184: [mem 0x00000000-0x0000ffff 64bit pref]
[ 0.956507] pci 0000:01:00.2: reg 0x190: [mem 0x00000000-0x00003fff 64bit pref]
[ 0.956775] pci 0000:01:00.2: reg 0x184: [mem 0x00000000-0x0000ffff 64bit pref]
[ 0.956797] pci 0000:01:00.2: reg 0x190: [mem 0x00000000-0x00003fff 64bit pref]
[ 0.956818] pci 0000:01:00.2: reg 0x184: [mem 0x00000000-0x0000ffff 64bit pref]
[ 0.956861] pci 0000:01:00.2: reg 0x184: [mem 0x00000000-0x0000ffff 64bit pref]
[ 0.956896] pci 0000:01:00.2: reg 0x184: [mem 0x00000000-0x0000ffff 64bit pref]
[ 0.956924] pci 0000:01:00.2: reg 0x184: [mem 0x00000000-0x0000ffff 64bit pref]
[ 0.956952] pci 0000:01:00.2: reg 0x190: [mem 0x00000000-0x00003fff 64bit pref]
[ 0.956967] pci 0000:01:00.2: BAR 0: assigned [mem 0x91800000-0x91ffffff 64bit pref]
[ 0.957011] pci 0000:01:00.2: reg 0x184: [mem 0x00000000-0x0000ffff 64bit pref]
[ 0.957013] pci 0000:01:00.2: BAR 7: assigned [mem 0x92800000-0x929fffff 64bit pref]
[ 0.957044] pci 0000:01:00.2: BAR 3: assigned [mem 0x92c10000-0x92c17fff 64bit pref]
[ 0.957087] pci 0000:01:00.2: reg 0x190: [mem 0x00000000-0x00003fff 64bit pref]
[ 0.957089] pci 0000:01:00.2: BAR 10: assigned [mem 0x92d20000-0x92d9ffff 64bit pref]
[ 3.085343] i40e 0000:01:00.2: f5.0 a1.5 n05.02 e80002283
[ 3.309611] i40e 0000:01:00.2: MAC address: 0c:c4:7a:bc:a1:8a
[ 3.309925] i40e 0000:01:00.2: irq 167 for MSI/MSI-X
[ 3.309933] i40e 0000:01:00.2: irq 168 for MSI/MSI-X
[ 3.309939] i40e 0000:01:00.2: irq 169 for MSI/MSI-X
[ 3.309946] i40e 0000:01:00.2: irq 170 for MSI/MSI-X
[ 3.309952] i40e 0000:01:00.2: irq 171 for MSI/MSI-X
[ 3.309959] i40e 0000:01:00.2: irq 172 for MSI/MSI-X
[ 3.309965] i40e 0000:01:00.2: irq 173 for MSI/MSI-X
[ 3.309971] i40e 0000:01:00.2: irq 174 for MSI/MSI-X
[ 3.309978] i40e 0000:01:00.2: irq 175 for MSI/MSI-X
[ 3.309984] i40e 0000:01:00.2: irq 176 for MSI/MSI-X
[ 3.309990] i40e 0000:01:00.2: irq 177 for MSI/MSI-X
[ 3.309997] i40e 0000:01:00.2: irq 178 for MSI/MSI-X
[ 3.310003] i40e 0000:01:00.2: irq 179 for MSI/MSI-X
[ 3.310010] i40e 0000:01:00.2: irq 180 for MSI/MSI-X
[ 3.310016] i40e 0000:01:00.2: irq 181 for MSI/MSI-X
[ 3.310023] i40e 0000:01:00.2: irq 182 for MSI/MSI-X
[ 3.310029] i40e 0000:01:00.2: irq 183 for MSI/MSI-X
[ 3.310035] i40e 0000:01:00.2: irq 184 for MSI/MSI-X
[ 3.310042] i40e 0000:01:00.2: irq 185 for MSI/MSI-X
[ 3.310048] i40e 0000:01:00.2: irq 186 for MSI/MSI-X
[ 3.310054] i40e 0000:01:00.2: irq 187 for MSI/MSI-X
[ 3.310061] i40e 0000:01:00.2: irq 188 for MSI/MSI-X
[ 3.310068] i40e 0000:01:00.2: irq 189 for MSI/MSI-X
[ 3.310074] i40e 0000:01:00.2: irq 190 for MSI/MSI-X
[ 3.310081] i40e 0000:01:00.2: irq 191 for MSI/MSI-X
[ 3.310087] i40e 0000:01:00.2: irq 192 for MSI/MSI-X
[ 3.310094] i40e 0000:01:00.2: irq 193 for MSI/MSI-X
[ 3.310100] i40e 0000:01:00.2: irq 194 for MSI/MSI-X
[ 3.310107] i40e 0000:01:00.2: irq 195 for MSI/MSI-X
[ 3.310113] i40e 0000:01:00.2: irq 196 for MSI/MSI-X
[ 3.310120] i40e 0000:01:00.2: irq 197 for MSI/MSI-X
[ 3.310126] i40e 0000:01:00.2: irq 198 for MSI/MSI-X
[ 3.310132] i40e 0000:01:00.2: irq 199 for MSI/MSI-X
[ 3.310138] i40e 0000:01:00.2: irq 200 for MSI/MSI-X
[ 3.310145] i40e 0000:01:00.2: irq 201 for MSI/MSI-X
[ 3.310151] i40e 0000:01:00.2: irq 202 for MSI/MSI-X
[ 3.310158] i40e 0000:01:00.2: irq 203 for MSI/MSI-X
[ 3.310164] i40e 0000:01:00.2: irq 204 for MSI/MSI-X
[ 3.310170] i40e 0000:01:00.2: irq 205 for MSI/MSI-X
[ 3.310177] i40e 0000:01:00.2: irq 206 for MSI/MSI-X
[ 3.310183] i40e 0000:01:00.2: irq 207 for MSI/MSI-X
[ 3.310189] i40e 0000:01:00.2: irq 208 for MSI/MSI-X
[ 3.310195] i40e 0000:01:00.2: irq 209 for MSI/MSI-X
[ 3.310202] i40e 0000:01:00.2: irq 210 for MSI/MSI-X
[ 3.310209] i40e 0000:01:00.2: irq 211 for MSI/MSI-X
[ 3.310215] i40e 0000:01:00.2: irq 212 for MSI/MSI-X
[ 3.310221] i40e 0000:01:00.2: irq 213 for MSI/MSI-X
[ 3.310228] i40e 0000:01:00.2: irq 214 for MSI/MSI-X
[ 3.310234] i40e 0000:01:00.2: irq 215 for MSI/MSI-X
[ 3.310240] i40e 0000:01:00.2: irq 216 for MSI/MSI-X
[ 3.311109] i40e 0000:01:00.2: Could not remove default MAC-VLAN
[ 3.313200] i40e 0000:01:00.2: i40e_ptp_init: added PHC on eth2
[ 3.313450] i40e 0000:01:00.2: PCI-Express: Speed 8.0GT/s Width x8
[ 3.313454] i40e 0000:01:00.2: Features: PF-id[2] VFs: 32 VSIs: 34 QP: 32 RSS FD_ATR FD_SB NTUPLE DCB PTP
[ 4.864531] i40e 0000:01:00.2: add filter failed, err -53, aq_err 14
[ 494.232980] i40e 0000:01:00.2 eth4: NIC Link is Up 10 Gbps Full Duplex, Flow Control: None
# ethtool -i eth7
driver: i40e
version: 0.4.10-k
firmware-version: f4.33 a1.2 n04.42 e8000191c
bus-info: 0000:02:00.1
supports-statistics: yes
supports-test: yes
supports-eeprom-access: yes
supports-register-dump: yes
supports-priv-flags: no
# lspci -vvvs 0000:02:00.1
02:00.1 Ethernet controller: Intel Corporation Ethernet Controller X710 for 10GbE SFP+ (rev 01)
Subsystem: Super Micro Computer Inc Device 0000
Physical Slot: 2
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0, Cache Line Size: 64 bytes
Interrupt: pin A routed to IRQ 32
Region 0: Memory at 93800000 (64-bit, prefetchable) [size=8M]
Region 3: Memory at 95808000 (64-bit, prefetchable) [size=32K]
Expansion ROM at fb200000 [disabled] [size=512K]
Capabilities: [40] Power Management version 3
Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold-)
Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=1 PME-
Capabilities: [50] MSI: Enable- Count=1/1 Maskable+ 64bit+
Address: 0000000000000000 Data: 0000
Masking: 00000000 Pending: 00000000
Capabilities: [70] MSI-X: Enable+ Count=129 Masked-
Vector table: BAR=3 offset=00000000
PBA: BAR=3 offset=00001000
Capabilities: [a0] Express (v2) Endpoint, MSI 00
DevCap: MaxPayload 2048 bytes, PhantFunc 0, Latency L0s <512ns, L1 <64us
ExtTag+ AttnBtn- AttnInd- PwrInd- RBE+ FLReset+
DevCtl: Report errors: Correctable+ Non-Fatal+ Fatal+ Unsupported+
RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop- FLReset-
MaxPayload 256 bytes, MaxReadReq 512 bytes
DevSta: CorrErr+ UncorrErr- FatalErr- UnsuppReq+ AuxPwr- TransPend-
LnkCap: Port #0, Speed 8GT/s, Width x8, ASPM L1, Exit Latency L0s <2us, L1 <16us
ClockPM- Surprise- LLActRep- BwNot-
LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- CommClk+
ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
LnkSta: Speed 8GT/s, Width x8, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
DevCap2: Completion Timeout: Range ABCD, TimeoutDis+, LTR-, OBFF Not Supported
DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis-, LTR-, OBFF Disabled
LnkSta2: Current De-emphasis Level: -6dB, EqualizationComplete-, EqualizationPhase1-
EqualizationPhase2-, EqualizationPhase3-, LinkEqualizationRequest-
Capabilities: [e0] Vital Product Data
Product Name: Supermicro Network Adapter
Read-only fields:
[PN] Part number: AOC-STG-i4S\x00\x00\x00\x00
[V0] Vendor specific: 0100
[V1] Vendor specific: 1.01\x00
[SN] Serial number: VA157S008336\x00\x00\x00\x00\x00\x00\x00
[VA] Vendor specific: 4
[V2] Vendor specific: 0CC47ABC4138
[V3] Vendor specific: 0CC47ABC4139
[V4] Vendor specific: 0CC47ABC413A
[V5] Vendor specific: 0CC47ABC413B
[RV] Reserved: checksum good, 0 byte(s) reserved
Read/write fields:
[VB] Vendor specific: \x00
End
Capabilities: [100 v2] Advanced Error Reporting
UESta: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
UEMsk: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
UESvrt: DLP+ SDES+ TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol-
CESta: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr+
CEMsk: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr+
AERCap: First Error Pointer: 00, GenCap+ CGenEn- ChkCap+ ChkEn-
Capabilities: [140 v1] Device Serial Number 38-41-bc-ff-ff-7a-c4-0c
Capabilities: [150 v1] Alternative Routing-ID Interpretation (ARI)
ARICap: MFVC- ACS-, Next Function: 2
ARICtl: MFVC- ACS-, Function Group: 0
Capabilities: [160 v1] Single Root I/O Virtualization (SR-IOV)
IOVCap: Migration-, Interrupt Message Number: 000
IOVCtl: Enable- Migration- Interrupt- MSE- ARIHierarchy-
IOVSta: Migration-
Initial VFs: 32, Total VFs: 32, Number of VFs: 0, Function Dependency Link: 01
VF offset: 47, stride: 1, Device ID: 154c
Supported Page Size: 00000553, System Page Size: 00000001
Region 0: Memory at 0000000095200000 (64-bit, prefetchable)
Region 3: Memory@00000000958a0000 (64-bit, prefetchable)
VF Migration: offset: 00000000, BIR: 0
Capabilities: [1a0 v1] Transaction Processing Hints
Device specific mode supported
No steering table available
Capabilities: [1b0 v1] Access Control Services
ACSCap: SrcValid- TransBlk- ReqRedir- CmpltRedir- UpstreamFwd- EgressCtrl- DirectTrans-
ACSCtl: SrcValid- TransBlk- ReqRedir- CmpltRedir- UpstreamFwd- EgressCtrl- DirectTrans-
Kernel driver in use: i40e
[ 0.955700] pci 0000:02:00.1: reg 0x184: [mem 0x00000000-0x0000ffff 64bit pref]
[ 0.955721] pci 0000:02:00.1: reg 0x190: [mem 0x00000000-0x00003fff 64bit pref]
[ 0.955735] pci 0000:02:00.1: reg 0x184: [mem 0x00000000-0x0000ffff 64bit pref]
[ 0.955763] pci 0000:02:00.1: reg 0x184: [mem 0x00000000-0x0000ffff 64bit pref]
[ 0.955791] pci 0000:02:00.1: reg 0x184: [mem 0x00000000-0x0000ffff 64bit pref]
[ 0.955811] pci 0000:02:00.1: reg 0x190: [mem 0x00000000-0x00003fff 64bit pref]
[ 0.955833] pci 0000:02:00.1: reg 0x184: [mem 0x00000000-0x0000ffff 64bit pref]
[ 0.955868] pci 0000:02:00.1: reg 0x184: [mem 0x00000000-0x0000ffff 64bit pref]
[ 0.955896] pci 0000:02:00.1: reg 0x190: [mem 0x00000000-0x00003fff 64bit pref]
[ 0.955919] pci 0000:02:00.1: reg 0x184: [mem 0x00000000-0x0000ffff 64bit pref]
[ 0.955922] pci 0000:02:00.1: BAR 7: can't assign mem pref (size 0x200000)
[ 0.955978] pci 0000:02:00.1: reg 0x190: [mem 0x00000000-0x00003fff 64bit pref]
[ 0.955980] pci 0000:02:00.1: BAR 10: can't assign mem pref (size 0x80000)
[ 0.956545] pci 0000:02:00.1: reg 0x184: [mem 0x00000000-0x0000ffff 64bit pref]
[ 0.956552] pci 0000:02:00.1: reg 0x190: [mem 0x00000000-0x00003fff 64bit pref]
[ 0.957163] pci 0000:02:00.1: reg 0x184: [mem 0x00000000-0x0000ffff 64bit pref]
[ 0.957177] pci 0000:02:00.1: reg 0x190: [mem 0x00000000-0x00003fff 64bit pref]
[ 0.957191] pci 0000:02:00.1: reg 0x184: [mem 0x00000000-0x0000ffff 64bit pref]
[ 0.957219] pci 0000:02:00.1: reg 0x184: [mem 0x00000000-0x0000ffff 64bit pref]
[ 0.957247] pci 0000:02:00.1: reg 0x184: [mem 0x00000000-0x0000ffff 64bit pref]
[ 0.957268] pci 0000:02:00.1: reg 0x184: [mem 0x00000000-0x0000ffff 64bit pref]
[ 0.957289] pci 0000:02:00.1: reg 0x190: [mem 0x00000000-0x00003fff 64bit pref]
[ 0.957310] pci 0000:02:00.1: reg 0x184: [mem 0x00000000-0x0000ffff 64bit pref]
[ 0.957345] pci 0000:02:00.1: reg 0x184: [mem 0x00000000-0x0000ffff 64bit pref]
[ 0.957373] pci 0000:02:00.1: reg 0x184: [mem 0x00000000-0x0000ffff 64bit pref]
[ 0.957401] pci 0000:02:00.1: reg 0x190: [mem 0x00000000-0x00003fff 64bit pref]
[ 0.957416] pci 0000:02:00.1: BAR 0: assigned [mem 0x93800000-0x93ffffff 64bit pref]
[ 0.957453] pci 0000:02:00.1: reg 0x184: [mem 0x00000000-0x0000ffff 64bit pref]
[ 0.957455] pci 0000:02:00.1: BAR 7: assigned [mem 0x95200000-0x953fffff 64bit pref]
[ 0.957492] pci 0000:02:00.1: BAR 3: assigned [mem 0x95808000-0x9580ffff 64bit pref]
[ 0.957529] pci 0000:02:00.1: reg 0x190: [mem 0x00000000-0x00003fff 64bit pref]
[ 0.957531] pci 0000:02:00.1: BAR 10: assigned [mem 0x958a0000-0x9591ffff 64bit pref]
[ 3.832996] i40e 0000:02:00.1: f4.33 a1.2 n04.42 e8000191c
[ 4.054413] i40e 0000:02:00.1: MAC address: 0c:c4:7a:bc:41:39
[ 4.054674] i40e 0000:02:00.1: irq 368 for MSI/MSI-X
[ 4.054691] i40e 0000:02:00.1: irq 369 for MSI/MSI-X
[ 4.054707] i40e 0000:02:00.1: irq 370 for MSI/MSI-X
[ 4.054723] i40e 0000:02:00.1: irq 371 for MSI/MSI-X
[ 4.054740] i40e 0000:02:00.1: irq 372 for MSI/MSI-X
[ 4.054756] i40e 0000:02:00.1: irq 373 for MSI/MSI-X
[ 4.054772] i40e 0000:02:00.1: irq 374 for MSI/MSI-X
[ 4.054789] i40e 0000:02:00.1: irq 375 for MSI/MSI-X
[ 4.054805] i40e 0000:02:00.1: irq 376 for MSI/MSI-X
[ 4.054821] i40e 0000:02:00.1: irq 377 for MSI/MSI-X
[ 4.054838] i40e 0000:02:00.1: irq 378 for MSI/MSI-X
[ 4.054854] i40e 0000:02:00.1: irq 379 for MSI/MSI-X
[ 4.054871] i40e 0000:02:00.1: irq 380 for MSI/MSI-X
[ 4.054887] i40e 0000:02:00.1: irq 381 for MSI/MSI-X
[ 4.054904] i40e 0000:02:00.1: irq 382 for MSI/MSI-X
[ 4.054920] i40e 0000:02:00.1: irq 383 for MSI/MSI-X
[ 4.054937] i40e 0000:02:00.1: irq 384 for MSI/MSI-X
[ 4.054953] i40e 0000:02:00.1: irq 385 for MSI/MSI-X
[ 4.054969] i40e 0000:02:00.1: irq 386 for MSI/MSI-X
[ 4.054986] i40e 0000:02:00.1: irq 387 for MSI/MSI-X
[ 4.055002] i40e 0000:02:00.1: irq 388 for MSI/MSI-X
[ 4.055017] i40e 0000:02:00.1: irq 389 for MSI/MSI-X
[ 4.055033] i40e 0000:02:00.1: irq 390 for MSI/MSI-X
[ 4.055049] i40e 0000:02:00.1: irq 391 for MSI/MSI-X
[ 4.055065] i40e 0000:02:00.1: irq 392 for MSI/MSI-X
[ 4.055081] i40e 0000:02:00.1: irq 393 for MSI/MSI-X
[ 4.055097] i40e 0000:02:00.1: irq 394 for MSI/MSI-X
[ 4.055114] i40e 0000:02:00.1: irq 395 for MSI/MSI-X
[ 4.055130] i40e 0000:02:00.1: irq 396 for MSI/MSI-X
[ 4.055147] i40e 0000:02:00.1: irq 397 for MSI/MSI-X
[ 4.055163] i40e 0000:02:00.1: irq 398 for MSI/MSI-X
[ 4.055179] i40e 0000:02:00.1: irq 399 for MSI/MSI-X
[ 4.055195] i40e 0000:02:00.1: irq 400 for MSI/MSI-X
[ 4.055211] i40e 0000:02:00.1: irq 401 for MSI/MSI-X
[ 4.055227] i40e 0000:02:00.1: irq 402 for MSI/MSI-X
[ 4.055244] i40e 0000:02:00.1: irq 403 for MSI/MSI-X
[ 4.055260] i40e 0000:02:00.1: irq 404 for MSI/MSI-X
[ 4.055275] i40e 0000:02:00.1: irq 405 for MSI/MSI-X
[ 4.055292] i40e 0000:02:00.1: irq 406 for MSI/MSI-X
[ 4.055308] i40e 0000:02:00.1: irq 407 for MSI/MSI-X
[ 4.055323] i40e 0000:02:00.1: irq 408 for MSI/MSI-X
[ 4.055340] i40e 0000:02:00.1: irq 409 for MSI/MSI-X
[ 4.055355] i40e 0000:02:00.1: irq 410 for MSI/MSI-X
[ 4.055372] i40e 0000:02:00.1: irq 411 for MSI/MSI-X
[ 4.055387] i40e 0000:02:00.1: irq 412 for MSI/MSI-X
[ 4.055403] i40e 0000:02:00.1: irq 413 for MSI/MSI-X
[ 4.055419] i40e 0000:02:00.1: irq 414 for MSI/MSI-X
[ 4.055435] i40e 0000:02:00.1: irq 415 for MSI/MSI-X
[ 4.055451] i40e 0000:02:00.1: irq 416 for MSI/MSI-X
[ 4.055467] i40e 0000:02:00.1: irq 417 for MSI/MSI-X
[ 4.056329] i40e 0000:02:00.1: Could not remove default MAC-VLAN
[ 4.069671] i40e 0000:02:00.1: i40e_ptp_init: added PHC on eth8
[ 4.081099] i40e 0000:02:00.1: PCI-Express: Speed 8.0GT/s Width x8
[ 4.081104] i40e 0000:02:00.1: Features: PF-id[1] VFs: 32 VSIs: 34 QP: 32 RSS FD_ATR FD_SB NTUPLE DCB PTP
[ 495.752345] i40e 0000:02:00.1 eth7: NIC Link is Up 10 Gbps Full Duplex, Flow Control: None
^ permalink raw reply [flat|nested] 13+ messages in thread
* [Intel-wired-lan] [E1000-devel] i40e: Deadly GRE packet
2016-04-21 12:45 [Intel-wired-lan] i40e: Deadly GRE packet =?unknown-8bit?q?Micha=C5=82_Miros=C5=82aw?=
@ 2016-04-21 14:51 ` Wyborny, Carolyn
2016-04-21 14:54 ` Ronciak, John
2016-04-21 14:57 ` Wyborny, Carolyn
2 siblings, 0 replies; 13+ messages in thread
From: Wyborny, Carolyn @ 2016-04-21 14:51 UTC (permalink / raw)
To: intel-wired-lan
> -----Original Message-----
> From: Micha? Miros?aw [mailto:michal.miroslaw at atendesoftware.pl]
> Sent: Thursday, April 21, 2016 5:45 AM
> To: e1000-devel at lists.sourceforge.net; intel-wired-lan at lists.osuosl.org
> Cc: Pawe? Ma?achowski <pawel.malachowski@atendesoftware.pl>; mirq-
> linux at rere.qmqm.pl
> Subject: [E1000-devel] i40e: Deadly GRE packet
>
> Dear Developers,
>
> I have a setup of a pair of SuperMicro-branded XL710s connected with
> passive crossover cable, one (eth4) is using firmware 5.0, the other (eth7)
> is using fw 4.33. When I send couple of packets with no payload in GRE over
> IP over ETH from eth7 to eth4, the receiving card stops processing further
> packets. It seems that 4 empty-GRE packets in succession are enough to kill
> the card's receivers (all ports stop working), more if there are other
> packets inbetween. Transmit direction is not affected. After reboot, the
> card comes back, reloading the driver (or unbind/bind) is not enough to fix
> the problem.
>
> 14:31:24.299203 00:00:00:00:00:00 > ff:ff:ff:ff:ff:ff, ethertype IPv4
> (0x0800), length 60: (tos 0x0, ttl 64, id 1, offset 0, flags [none], proto
> GRE (47), length 24)
> 127.0.0.1 > 127.0.0.1: GREv0, Flags [none], proto unknown (0x0000),
> length 4
> gre-proto-0x0
> 0x0000: 4500 0018 0001 0000 402f 7cb4 7f00 0001 E.......@/|.....
> 0x0010: 7f00 0001 0000 0000 0000 0000 0000 0000 ................
> 0x0020: 0000 0000 0000 0000 0000 0000 0000 ..............
>
> scapy 2.2.0 generates this packet from: Ether()/IP()/GRE()
>
> Tested on stock Debian kernel, with in-kernel driver and one from DPDK-2.2.
> Linux lab1 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt25-2 (2016-04-08)
> x86_64
> GNU/Linux
>
> Best Regards,
> Micha? Miros?aw
Thanks for this Michal, we'll take a look and get back to you.
Carolyn
^ permalink raw reply [flat|nested] 13+ messages in thread
* [Intel-wired-lan] [E1000-devel] i40e: Deadly GRE packet
2016-04-21 12:45 [Intel-wired-lan] i40e: Deadly GRE packet =?unknown-8bit?q?Micha=C5=82_Miros=C5=82aw?=
2016-04-21 14:51 ` [Intel-wired-lan] [E1000-devel] " Wyborny, Carolyn
@ 2016-04-21 14:54 ` Ronciak, John
2016-04-21 15:04 ` =?unknown-8bit?q?Micha=C5=82_Miros=C5=82aw?=
2016-04-21 14:57 ` Wyborny, Carolyn
2 siblings, 1 reply; 13+ messages in thread
From: Ronciak, John @ 2016-04-21 14:54 UTC (permalink / raw)
To: intel-wired-lan
> -----Original Message-----
> From: Micha? Miros?aw [mailto:michal.miroslaw at atendesoftware.pl]
> Sent: Thursday, April 21, 2016 5:45 AM
> To: e1000-devel at lists.sourceforge.net; intel-wired-lan at lists.osuosl.org
> Cc: Pawe? Ma?achowski <pawel.malachowski@atendesoftware.pl>; mirq-
> linux at rere.qmqm.pl
> Subject: [E1000-devel] i40e: Deadly GRE packet
>
> Dear Developers,
>
> I have a setup of a pair of SuperMicro-branded XL710s connected with
> passive crossover cable, one (eth4) is using firmware 5.0, the other (eth7) is
> using fw 4.33. When I send couple of packets with no payload in GRE over IP
> over ETH from eth7 to eth4, the receiving card stops processing further
> packets. It seems that 4 empty-GRE packets in succession are enough to kill
> the card's receivers (all ports stop working), more if there are other packets
> inbetween. Transmit direction is not affected. After reboot, the card comes
> back, reloading the driver (or unbind/bind) is not enough to fix the problem.
>
> 14:31:24.299203 00:00:00:00:00:00 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800),
> length 60: (tos 0x0, ttl 64, id 1, offset 0, flags [none], proto GRE (47), length
> 24)
> 127.0.0.1 > 127.0.0.1: GREv0, Flags [none], proto unknown (0x0000), length
> 4
> gre-proto-0x0
> 0x0000: 4500 0018 0001 0000 402f 7cb4 7f00 0001 E.......@/|.....
> 0x0010: 7f00 0001 0000 0000 0000 0000 0000 0000 ................
> 0x0020: 0000 0000 0000 0000 0000 0000 0000 ..............
>
> scapy 2.2.0 generates this packet from: Ether()/IP()/GRE()
>
> Tested on stock Debian kernel, with in-kernel driver and one from DPDK-2.2.
> Linux lab1 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt25-2 (2016-04-08) x86_64
> GNU/Linux
>
> Best Regards,
> Micha? Miros?aw
How exactly is DPDK involved? Is it running in all instances where the issue is seen? Have you tried the latest i40e driver from our Sourceforge site (http://e1000.sf.net)?
Cheers,
John
^ permalink raw reply [flat|nested] 13+ messages in thread
* [Intel-wired-lan] [E1000-devel] i40e: Deadly GRE packet
2016-04-21 12:45 [Intel-wired-lan] i40e: Deadly GRE packet =?unknown-8bit?q?Micha=C5=82_Miros=C5=82aw?=
2016-04-21 14:51 ` [Intel-wired-lan] [E1000-devel] " Wyborny, Carolyn
2016-04-21 14:54 ` Ronciak, John
@ 2016-04-21 14:57 ` Wyborny, Carolyn
2016-04-21 15:06 ` =?unknown-8bit?q?Micha=C5=82_Miros=C5=82aw?=
2 siblings, 1 reply; 13+ messages in thread
From: Wyborny, Carolyn @ 2016-04-21 14:57 UTC (permalink / raw)
To: intel-wired-lan
> -----Original Message-----
> From: Micha? Miros?aw [mailto:michal.miroslaw at atendesoftware.pl]
> Sent: Thursday, April 21, 2016 5:45 AM
> To: e1000-devel at lists.sourceforge.net; intel-wired-lan at lists.osuosl.org
> Cc: Pawe? Ma?achowski <pawel.malachowski@atendesoftware.pl>; mirq-
> linux at rere.qmqm.pl
> Subject: [E1000-devel] i40e: Deadly GRE packet
>
> Dear Developers,
>
> I have a setup of a pair of SuperMicro-branded XL710s connected with
> passive crossover cable, one (eth4) is using firmware 5.0, the other (eth7)
> is using fw 4.33. When I send couple of packets with no payload in GRE over
> IP over ETH from eth7 to eth4, the receiving card stops processing further
> packets. It seems that 4 empty-GRE packets in succession are enough to kill
> the card's receivers (all ports stop working), more if there are other
> packets inbetween. Transmit direction is not affected. After reboot, the
> card comes back, reloading the driver (or unbind/bind) is not enough to fix
> the problem.
>
Can you also provide the version of the driver you are using? Ethtool -i
Thanks,
Carolyn
^ permalink raw reply [flat|nested] 13+ messages in thread
* [Intel-wired-lan] [E1000-devel] i40e: Deadly GRE packet
2016-04-21 14:54 ` Ronciak, John
@ 2016-04-21 15:04 ` =?unknown-8bit?q?Micha=C5=82_Miros=C5=82aw?=
2016-04-21 15:19 ` Ronciak, John
2016-04-21 18:03 ` Wyborny, Carolyn
0 siblings, 2 replies; 13+ messages in thread
From: =?unknown-8bit?q?Micha=C5=82_Miros=C5=82aw?= @ 2016-04-21 15:04 UTC (permalink / raw)
To: intel-wired-lan
Dear John,
We found the problem using our DPDK application, but later on we reproduced
the same issue using in-kernel drivers (even after fresh reboot).
Best Regards,
Micha? Miros?aw
2016-04-21 16:54 GMT+02:00 Ronciak, John <john.ronciak@intel.com>:
> > -----Original Message-----
> > From: Micha? Miros?aw [mailto:michal.miroslaw at atendesoftware.pl]
> > Sent: Thursday, April 21, 2016 5:45 AM
> > To: e1000-devel at lists.sourceforge.net; intel-wired-lan at lists.osuosl.org
> > Cc: Pawe? Ma?achowski <pawel.malachowski@atendesoftware.pl>; mirq-
> > linux at rere.qmqm.pl
> > Subject: [E1000-devel] i40e: Deadly GRE packet
> >
> > Dear Developers,
> >
> > I have a setup of a pair of SuperMicro-branded XL710s connected with
> > passive crossover cable, one (eth4) is using firmware 5.0, the other
> (eth7) is
> > using fw 4.33. When I send couple of packets with no payload in GRE over
> IP
> > over ETH from eth7 to eth4, the receiving card stops processing further
> > packets. It seems that 4 empty-GRE packets in succession are enough to
> kill
> > the card's receivers (all ports stop working), more if there are other
> packets
> > inbetween. Transmit direction is not affected. After reboot, the card
> comes
> > back, reloading the driver (or unbind/bind) is not enough to fix the
> problem.
> >
> > 14:31:24.299203 00:00:00:00:00:00 > ff:ff:ff:ff:ff:ff, ethertype IPv4
> (0x0800),
> > length 60: (tos 0x0, ttl 64, id 1, offset 0, flags [none], proto GRE
> (47), length
> > 24)
> > 127.0.0.1 > 127.0.0.1: GREv0, Flags [none], proto unknown (0x0000),
> length
> > 4
> > gre-proto-0x0
> > 0x0000: 4500 0018 0001 0000 402f 7cb4 7f00 0001 E.......@
> /|.....
> > 0x0010: 7f00 0001 0000 0000 0000 0000 0000 0000
> ................
> > 0x0020: 0000 0000 0000 0000 0000 0000 0000 ..............
> >
> > scapy 2.2.0 generates this packet from: Ether()/IP()/GRE()
> >
> > Tested on stock Debian kernel, with in-kernel driver and one from
> DPDK-2.2.
> > Linux lab1 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt25-2 (2016-04-08)
> x86_64
> > GNU/Linux
> >
> > Best Regards,
> > Micha? Miros?aw
> How exactly is DPDK involved? Is it running in all instances where the
> issue is seen? Have you tried the latest i40e driver from our Sourceforge
> site (http://e1000.sf.net)?
>
> Cheers,
> John
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osuosl.org/pipermail/intel-wired-lan/attachments/20160421/91834b1c/attachment-0001.html>
^ permalink raw reply [flat|nested] 13+ messages in thread
* [Intel-wired-lan] [E1000-devel] i40e: Deadly GRE packet
2016-04-21 14:57 ` Wyborny, Carolyn
@ 2016-04-21 15:06 ` =?unknown-8bit?q?Micha=C5=82_Miros=C5=82aw?=
0 siblings, 0 replies; 13+ messages in thread
From: =?unknown-8bit?q?Micha=C5=82_Miros=C5=82aw?= @ 2016-04-21 15:06 UTC (permalink / raw)
To: intel-wired-lan
Dear Carolyn,
The ethtool info was attached to my original mail. Here it is inline in
case the attachment was stripped:
# ethtool -i eth4
driver: i40e
version: 0.4.10-k
firmware-version: f5.0 a1.5 n05.02 e80002283
bus-info: 0000:01:00.2
supports-statistics: yes
supports-test: yes
supports-eeprom-access: yes
supports-register-dump: yes
supports-priv-flags: no
# ethtool -i eth7
driver: i40e
version: 0.4.10-k
firmware-version: f4.33 a1.2 n04.42 e8000191c
bus-info: 0000:02:00.1
supports-statistics: yes
supports-test: yes
supports-eeprom-access: yes
supports-register-dump: yes
supports-priv-flags: no
Best Regards,
Micha? Miros?aw
2016-04-21 16:57 GMT+02:00 Wyborny, Carolyn <carolyn.wyborny@intel.com>:
> > -----Original Message-----
> > From: Micha? Miros?aw [mailto:michal.miroslaw at atendesoftware.pl]
> > Sent: Thursday, April 21, 2016 5:45 AM
> > To: e1000-devel at lists.sourceforge.net; intel-wired-lan at lists.osuosl.org
> > Cc: Pawe? Ma?achowski <pawel.malachowski@atendesoftware.pl>; mirq-
> > linux at rere.qmqm.pl
> > Subject: [E1000-devel] i40e: Deadly GRE packet
> >
> > Dear Developers,
> >
> > I have a setup of a pair of SuperMicro-branded XL710s connected with
> > passive crossover cable, one (eth4) is using firmware 5.0, the other
> (eth7)
> > is using fw 4.33. When I send couple of packets with no payload in GRE
> over
> > IP over ETH from eth7 to eth4, the receiving card stops processing
> further
> > packets. It seems that 4 empty-GRE packets in succession are enough to
> kill
> > the card's receivers (all ports stop working), more if there are other
> > packets inbetween. Transmit direction is not affected. After reboot, the
> > card comes back, reloading the driver (or unbind/bind) is not enough to
> fix
> > the problem.
> >
> Can you also provide the version of the driver you are using? Ethtool -i
>
> Thanks,
>
> Carolyn
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osuosl.org/pipermail/intel-wired-lan/attachments/20160421/e5b7434e/attachment-0001.html>
^ permalink raw reply [flat|nested] 13+ messages in thread
* [Intel-wired-lan] [E1000-devel] i40e: Deadly GRE packet
2016-04-21 15:04 ` =?unknown-8bit?q?Micha=C5=82_Miros=C5=82aw?=
@ 2016-04-21 15:19 ` Ronciak, John
2016-04-21 15:29 ` =?unknown-8bit?q?Micha=C5=82_Miros=C5=82aw?=
2016-04-21 18:03 ` Wyborny, Carolyn
1 sibling, 1 reply; 13+ messages in thread
From: Ronciak, John @ 2016-04-21 15:19 UTC (permalink / raw)
To: intel-wired-lan
Thanks, Please get us the other information we have asked for.
Cheers,
John
From: Micha? Miros?aw [mailto:michal.miroslaw at atendesoftware.pl]
Sent: Thursday, April 21, 2016 8:04 AM
To: Ronciak, John <john.ronciak@intel.com>
Cc: e1000-devel at lists.sourceforge.net; intel-wired-lan at lists.osuosl.org; Pawel Malachowski <pawel.malachowski@atendesoftware.pl>; mirq-linux at rere.qmqm.pl
Subject: Re: [E1000-devel] i40e: Deadly GRE packet
Dear John,
We found the problem using our DPDK application, but later on we reproduced the same issue using in-kernel drivers (even after fresh reboot).
Best Regards,
Micha? Miros?aw
2016-04-21 16:54 GMT+02:00 Ronciak, John <john.ronciak at intel.com<mailto:john.ronciak@intel.com>>:
> -----Original Message-----
> From: Micha? Miros?aw [mailto:michal.miroslaw at atendesoftware.pl<mailto:michal.miroslaw@atendesoftware.pl>]
> Sent: Thursday, April 21, 2016 5:45 AM
> To: e1000-devel at lists.sourceforge.net<mailto:e1000-devel@lists.sourceforge.net>; intel-wired-lan at lists.osuosl.org<mailto:intel-wired-lan@lists.osuosl.org>
> Cc: Pawe? Ma?achowski <pawel.malachowski at atendesoftware.pl<mailto:pawel.malachowski@atendesoftware.pl>>; mirq-
> linux at rere.qmqm.pl<mailto:linux@rere.qmqm.pl>
> Subject: [E1000-devel] i40e: Deadly GRE packet
>
> Dear Developers,
>
> I have a setup of a pair of SuperMicro-branded XL710s connected with
> passive crossover cable, one (eth4) is using firmware 5.0, the other (eth7) is
> using fw 4.33. When I send couple of packets with no payload in GRE over IP
> over ETH from eth7 to eth4, the receiving card stops processing further
> packets. It seems that 4 empty-GRE packets in succession are enough to kill
> the card's receivers (all ports stop working), more if there are other packets
> inbetween. Transmit direction is not affected. After reboot, the card comes
> back, reloading the driver (or unbind/bind) is not enough to fix the problem.
>
> 14:31:24.299203 00:00:00:00:00:00 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800),
> length 60: (tos 0x0, ttl 64, id 1, offset 0, flags [none], proto GRE (47), length
> 24)
> 127.0.0.1 > 127.0.0.1<http://127.0.0.1>: GREv0, Flags [none], proto unknown (0x0000), length
> 4
> gre-proto-0x0
> 0x0000: 4500 0018 0001 0000 402f 7cb4 7f00 0001 E.......@/|<mailto:E.......@/|>.....
> 0x0010: 7f00 0001 0000 0000 0000 0000 0000 0000 ................
> 0x0020: 0000 0000 0000 0000 0000 0000 0000 ..............
>
> scapy 2.2.0 generates this packet from: Ether()/IP()/GRE()
>
> Tested on stock Debian kernel, with in-kernel driver and one from DPDK-2.2.
> Linux lab1 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt25-2 (2016-04-08) x86_64
> GNU/Linux
>
> Best Regards,
> Micha? Miros?aw
How exactly is DPDK involved? Is it running in all instances where the issue is seen? Have you tried the latest i40e driver from our Sourceforge site (http://e1000.sf.net)?
Cheers,
John
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osuosl.org/pipermail/intel-wired-lan/attachments/20160421/da56552b/attachment.html>
^ permalink raw reply [flat|nested] 13+ messages in thread
* [Intel-wired-lan] [E1000-devel] i40e: Deadly GRE packet
2016-04-21 15:19 ` Ronciak, John
@ 2016-04-21 15:29 ` =?unknown-8bit?q?Micha=C5=82_Miros=C5=82aw?=
0 siblings, 0 replies; 13+ messages in thread
From: =?unknown-8bit?q?Micha=C5=82_Miros=C5=82aw?= @ 2016-04-21 15:29 UTC (permalink / raw)
To: intel-wired-lan
Dear John,
The issue also manifests itself with the Sourceforge driver.
# ethtool -i eth4
driver: i40e
version: 1.5.18
firmware-version: 5.02 0x80002283 0.0.0
bus-info: 0000:01:00.2
supports-statistics: yes
supports-test: yes
supports-eeprom-access: yes
supports-register-dump: yes
supports-priv-flags: yes
Best Regards,
Micha? Miros?aw
2016-04-21 17:19 GMT+02:00 Ronciak, John <john.ronciak@intel.com>:
> Thanks, Please get us the other information we have asked for.
>
>
>
> Cheers,
>
> John
>
>
>
> *From:* Micha? Miros?aw [mailto:michal.miroslaw at atendesoftware.pl]
> *Sent:* Thursday, April 21, 2016 8:04 AM
> *To:* Ronciak, John <john.ronciak@intel.com>
> *Cc:* e1000-devel at lists.sourceforge.net; intel-wired-lan at lists.osuosl.org;
> Pawel Malachowski <pawel.malachowski@atendesoftware.pl>;
> mirq-linux at rere.qmqm.pl
> *Subject:* Re: [E1000-devel] i40e: Deadly GRE packet
>
>
>
> Dear John,
>
>
>
> We found the problem using our DPDK application, but later on we
> reproduced the same issue using in-kernel drivers (even after fresh reboot).
>
>
>
> Best Regards,
>
> Micha? Miros?aw
>
>
>
> 2016-04-21 16:54 GMT+02:00 Ronciak, John <john.ronciak@intel.com>:
>
> > -----Original Message-----
> > From: Micha? Miros?aw [mailto:michal.miroslaw at atendesoftware.pl]
> > Sent: Thursday, April 21, 2016 5:45 AM
> > To: e1000-devel at lists.sourceforge.net; intel-wired-lan at lists.osuosl.org
> > Cc: Pawe? Ma?achowski <pawel.malachowski@atendesoftware.pl>; mirq-
> > linux at rere.qmqm.pl
> > Subject: [E1000-devel] i40e: Deadly GRE packet
> >
>
> > Dear Developers,
> >
> > I have a setup of a pair of SuperMicro-branded XL710s connected with
> > passive crossover cable, one (eth4) is using firmware 5.0, the other
> (eth7) is
> > using fw 4.33. When I send couple of packets with no payload in GRE over
> IP
> > over ETH from eth7 to eth4, the receiving card stops processing further
> > packets. It seems that 4 empty-GRE packets in succession are enough to
> kill
> > the card's receivers (all ports stop working), more if there are other
> packets
> > inbetween. Transmit direction is not affected. After reboot, the card
> comes
> > back, reloading the driver (or unbind/bind) is not enough to fix the
> problem.
> >
> > 14:31:24.299203 00:00:00:00:00:00 > ff:ff:ff:ff:ff:ff, ethertype IPv4
> (0x0800),
> > length 60: (tos 0x0, ttl 64, id 1, offset 0, flags [none], proto GRE
> (47), length
> > 24)
> > 127.0.0.1 > 127.0.0.1: GREv0, Flags [none], proto unknown (0x0000),
> length
> > 4
> > gre-proto-0x0
> > 0x0000: 4500 0018 0001 0000 402f 7cb4 7f00 0001 E.......@/|
> .....
> > 0x0010: 7f00 0001 0000 0000 0000 0000 0000 0000
> ................
> > 0x0020: 0000 0000 0000 0000 0000 0000 0000 ..............
> >
> > scapy 2.2.0 generates this packet from: Ether()/IP()/GRE()
> >
> > Tested on stock Debian kernel, with in-kernel driver and one from
> DPDK-2.2.
> > Linux lab1 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt25-2 (2016-04-08)
> x86_64
> > GNU/Linux
> >
> > Best Regards,
> > Micha? Miros?aw
>
> How exactly is DPDK involved? Is it running in all instances where the
> issue is seen? Have you tried the latest i40e driver from our Sourceforge
> site (http://e1000.sf.net)?
>
> Cheers,
> John
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osuosl.org/pipermail/intel-wired-lan/attachments/20160421/0d5c822c/attachment-0001.html>
^ permalink raw reply [flat|nested] 13+ messages in thread
* [Intel-wired-lan] [E1000-devel] i40e: Deadly GRE packet
2016-04-21 15:04 ` =?unknown-8bit?q?Micha=C5=82_Miros=C5=82aw?=
2016-04-21 15:19 ` Ronciak, John
@ 2016-04-21 18:03 ` Wyborny, Carolyn
2016-04-22 8:29 ` =?unknown-8bit?q?Micha=C5=82_Miros=C5=82aw?=
1 sibling, 1 reply; 13+ messages in thread
From: Wyborny, Carolyn @ 2016-04-21 18:03 UTC (permalink / raw)
To: intel-wired-lan
Thanks Michal,
Can we also get a full dmesg log from the receiving side during a repro?
Carolyn
> -----Original Message-----
> From: Micha? Miros?aw [mailto:michal.miroslaw at atendesoftware.pl]
> Sent: Thursday, April 21, 2016 8:04 AM
> To: Ronciak, John <john.ronciak@intel.com>
> Cc: e1000-devel at lists.sourceforge.net; mirq-linux at rere.qmqm.pl; intel-wired-
> lan at lists.osuosl.org; Pawel Malachowski
> <pawel.malachowski@atendesoftware.pl>
> Subject: Re: [E1000-devel] i40e: Deadly GRE packet
>
> Dear John,
>
> We found the problem using our DPDK application, but later on we reproduced
> the same issue using in-kernel drivers (even after fresh reboot).
>
> Best Regards,
> Micha? Miros?aw
>
> 2016-04-21 16:54 GMT+02:00 Ronciak, John <john.ronciak@intel.com>:
>
> > > -----Original Message-----
> > > From: Micha? Miros?aw [mailto:michal.miroslaw at atendesoftware.pl]
> > > Sent: Thursday, April 21, 2016 5:45 AM
> > > To: e1000-devel at lists.sourceforge.net; intel-wired-lan at lists.osuosl.org
> > > Cc: Pawe? Ma?achowski <pawel.malachowski@atendesoftware.pl>; mirq-
> > > linux at rere.qmqm.pl
> > > Subject: [E1000-devel] i40e: Deadly GRE packet
> > >
> > > Dear Developers,
> > >
> > > I have a setup of a pair of SuperMicro-branded XL710s connected with
> > > passive crossover cable, one (eth4) is using firmware 5.0, the other
> > (eth7) is
> > > using fw 4.33. When I send couple of packets with no payload in GRE over
> > IP
> > > over ETH from eth7 to eth4, the receiving card stops processing further
> > > packets. It seems that 4 empty-GRE packets in succession are enough to
> > kill
> > > the card's receivers (all ports stop working), more if there are other
> > packets
> > > inbetween. Transmit direction is not affected. After reboot, the card
> > comes
> > > back, reloading the driver (or unbind/bind) is not enough to fix the
> > problem.
> > >
> > > 14:31:24.299203 00:00:00:00:00:00 > ff:ff:ff:ff:ff:ff, ethertype IPv4
> > (0x0800),
> > > length 60: (tos 0x0, ttl 64, id 1, offset 0, flags [none], proto GRE
> > (47), length
> > > 24)
> > > 127.0.0.1 > 127.0.0.1: GREv0, Flags [none], proto unknown (0x0000),
> > length
> > > 4
> > > gre-proto-0x0
> > > 0x0000: 4500 0018 0001 0000 402f 7cb4 7f00 0001 E.......@
> > /|.....
> > > 0x0010: 7f00 0001 0000 0000 0000 0000 0000 0000
> > ................
> > > 0x0020: 0000 0000 0000 0000 0000 0000 0000 ..............
> > >
> > > scapy 2.2.0 generates this packet from: Ether()/IP()/GRE()
> > >
> > > Tested on stock Debian kernel, with in-kernel driver and one from
> > DPDK-2.2.
> > > Linux lab1 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt25-2 (2016-04-08)
> > x86_64
> > > GNU/Linux
> > >
> > > Best Regards,
> > > Micha? Miros?aw
> > How exactly is DPDK involved? Is it running in all instances where the
> > issue is seen? Have you tried the latest i40e driver from our Sourceforge
> > site (http://e1000.sf.net)?
> >
> > Cheers,
> > John
> >
> >
> >
^ permalink raw reply [flat|nested] 13+ messages in thread
* [Intel-wired-lan] [E1000-devel] i40e: Deadly GRE packet
2016-04-21 18:03 ` Wyborny, Carolyn
@ 2016-04-22 8:29 ` =?unknown-8bit?q?Micha=C5=82_Miros=C5=82aw?=
2016-04-29 8:12 ` =?unknown-8bit?q?Micha=C5=82_Miros=C5=82aw?=
0 siblings, 1 reply; 13+ messages in thread
From: =?unknown-8bit?q?Micha=C5=82_Miros=C5=82aw?= @ 2016-04-22 8:29 UTC (permalink / raw)
To: intel-wired-lan
There are no messages besides link up when the receiver is failing.
Best Regards,
Micha? Miros?aw
[60757.845623] i40e: Intel(R) 40-10 Gigabit Ethernet Connection Network
Driver - version 1.5.18
[60757.845629] i40e: Copyright(c) 2013 - 2016 Intel Corporation.
[...]
[60758.316280] i40e 0000:01:00.1: fw 5.0.40043 api 1.5 nvm 5.02 0x80002283
0.0.0
[60758.389654] i40e 0000:01:00.1: MAC address: 0c:c4:7a:bc:a1:89
[60758.399911] i40e 0000:01:00.1: Query for DCB configuration failed, err
I40E_ERR_ADMIN_QUEUE_ERROR aq_err I40E_AQ_RC_EPERM
[60758.399917] i40e 0000:01:00.1: DCB init failed -53, disabled
[60758.399975] i40e 0000:01:00.1: irq 107 for MSI/MSI-X
[60758.399987] i40e 0000:01:00.1: irq 108 for MSI/MSI-X
[60758.399998] i40e 0000:01:00.1: irq 109 for MSI/MSI-X
[60758.400009] i40e 0000:01:00.1: irq 110 for MSI/MSI-X
[60758.400020] i40e 0000:01:00.1: irq 111 for MSI/MSI-X
[60758.400031] i40e 0000:01:00.1: irq 112 for MSI/MSI-X
[60758.400042] i40e 0000:01:00.1: irq 113 for MSI/MSI-X
[60758.400052] i40e 0000:01:00.1: irq 114 for MSI/MSI-X
[60758.400064] i40e 0000:01:00.1: irq 116 for MSI/MSI-X
[60758.400075] i40e 0000:01:00.1: irq 117 for MSI/MSI-X
[60758.400086] i40e 0000:01:00.1: irq 118 for MSI/MSI-X
[60758.400097] i40e 0000:01:00.1: irq 119 for MSI/MSI-X
[60758.400108] i40e 0000:01:00.1: irq 120 for MSI/MSI-X
[60758.400119] i40e 0000:01:00.1: irq 121 for MSI/MSI-X
[60758.400130] i40e 0000:01:00.1: irq 122 for MSI/MSI-X
[60758.400141] i40e 0000:01:00.1: irq 123 for MSI/MSI-X
[60758.400151] i40e 0000:01:00.1: irq 124 for MSI/MSI-X
[60758.400162] i40e 0000:01:00.1: irq 125 for MSI/MSI-X
[60758.400173] i40e 0000:01:00.1: irq 126 for MSI/MSI-X
[60758.400184] i40e 0000:01:00.1: irq 127 for MSI/MSI-X
[60758.400195] i40e 0000:01:00.1: irq 128 for MSI/MSI-X
[60758.400206] i40e 0000:01:00.1: irq 129 for MSI/MSI-X
[60758.400217] i40e 0000:01:00.1: irq 130 for MSI/MSI-X
[60758.400228] i40e 0000:01:00.1: irq 131 for MSI/MSI-X
[60758.400238] i40e 0000:01:00.1: irq 132 for MSI/MSI-X
[60758.400250] i40e 0000:01:00.1: irq 133 for MSI/MSI-X
[60758.400260] i40e 0000:01:00.1: irq 134 for MSI/MSI-X
[60758.400271] i40e 0000:01:00.1: irq 135 for MSI/MSI-X
[60758.400293] i40e 0000:01:00.1: irq 136 for MSI/MSI-X
[60758.400303] i40e 0000:01:00.1: irq 137 for MSI/MSI-X
[60758.400313] i40e 0000:01:00.1: irq 138 for MSI/MSI-X
[60758.400322] i40e 0000:01:00.1: irq 139 for MSI/MSI-X
[60758.400331] i40e 0000:01:00.1: irq 140 for MSI/MSI-X
[60758.400341] i40e 0000:01:00.1: irq 141 for MSI/MSI-X
[60758.400351] i40e 0000:01:00.1: irq 142 for MSI/MSI-X
[60758.400360] i40e 0000:01:00.1: irq 143 for MSI/MSI-X
[60758.400370] i40e 0000:01:00.1: irq 144 for MSI/MSI-X
[60758.400379] i40e 0000:01:00.1: irq 145 for MSI/MSI-X
[60758.400388] i40e 0000:01:00.1: irq 146 for MSI/MSI-X
[60758.400398] i40e 0000:01:00.1: irq 147 for MSI/MSI-X
[60758.400408] i40e 0000:01:00.1: irq 148 for MSI/MSI-X
[60758.400418] i40e 0000:01:00.1: irq 149 for MSI/MSI-X
[60758.600290] i40e 0000:01:00.1: PCI-Express: Speed 8.0GT/s Width x8
[60758.629802] i40e 0000:01:00.1: Features: PF-id[1] VFs: 32 VSIs: 34 QP:
32 RSS FD_ATR FD_SB NTUPLE CloudF VxLAN NVGRE PTP VEPA
[...]
[60769.222107] i40e 0000:01:00.2 eth4: NIC Link is Up 10 Gbps Full Duplex,
Flow Control: None
[60771.217551] device eth4 entered promiscuous mode
[...] test runs here, no messages during that time
[60816.884307] device eth4 left promiscuous mode
2016-04-21 20:03 GMT+02:00 Wyborny, Carolyn <carolyn.wyborny@intel.com>:
> Thanks Michal,
>
> Can we also get a full dmesg log from the receiving side during a repro?
>
> Carolyn
>
> > -----Original Message-----
> > From: Micha? Miros?aw [mailto:michal.miroslaw at atendesoftware.pl]
> > Sent: Thursday, April 21, 2016 8:04 AM
> > To: Ronciak, John <john.ronciak@intel.com>
> > Cc: e1000-devel at lists.sourceforge.net; mirq-linux at rere.qmqm.pl;
> intel-wired-
> > lan at lists.osuosl.org; Pawel Malachowski
> > <pawel.malachowski@atendesoftware.pl>
> > Subject: Re: [E1000-devel] i40e: Deadly GRE packet
> >
> > Dear John,
> >
> > We found the problem using our DPDK application, but later on we
> reproduced
> > the same issue using in-kernel drivers (even after fresh reboot).
> >
> > Best Regards,
> > Micha? Miros?aw
> >
> > 2016-04-21 16:54 GMT+02:00 Ronciak, John <john.ronciak@intel.com>:
> >
> > > > -----Original Message-----
> > > > From: Micha? Miros?aw [mailto:michal.miroslaw at atendesoftware.pl]
> > > > Sent: Thursday, April 21, 2016 5:45 AM
> > > > To: e1000-devel at lists.sourceforge.net;
> intel-wired-lan at lists.osuosl.org
> > > > Cc: Pawe? Ma?achowski <pawel.malachowski@atendesoftware.pl>; mirq-
> > > > linux at rere.qmqm.pl
> > > > Subject: [E1000-devel] i40e: Deadly GRE packet
> > > >
> > > > Dear Developers,
> > > >
> > > > I have a setup of a pair of SuperMicro-branded XL710s connected with
> > > > passive crossover cable, one (eth4) is using firmware 5.0, the other
> > > (eth7) is
> > > > using fw 4.33. When I send couple of packets with no payload in GRE
> over
> > > IP
> > > > over ETH from eth7 to eth4, the receiving card stops processing
> further
> > > > packets. It seems that 4 empty-GRE packets in succession are enough
> to
> > > kill
> > > > the card's receivers (all ports stop working), more if there are
> other
> > > packets
> > > > inbetween. Transmit direction is not affected. After reboot, the card
> > > comes
> > > > back, reloading the driver (or unbind/bind) is not enough to fix the
> > > problem.
> > > >
> > > > 14:31:24.299203 00:00:00:00:00:00 > ff:ff:ff:ff:ff:ff, ethertype IPv4
> > > (0x0800),
> > > > length 60: (tos 0x0, ttl 64, id 1, offset 0, flags [none], proto GRE
> > > (47), length
> > > > 24)
> > > > 127.0.0.1 > 127.0.0.1: GREv0, Flags [none], proto unknown
> (0x0000),
> > > length
> > > > 4
> > > > gre-proto-0x0
> > > > 0x0000: 4500 0018 0001 0000 402f 7cb4 7f00 0001 E.......@
> > > /|.....
> > > > 0x0010: 7f00 0001 0000 0000 0000 0000 0000 0000
> > > ................
> > > > 0x0020: 0000 0000 0000 0000 0000 0000 0000
> ..............
> > > >
> > > > scapy 2.2.0 generates this packet from: Ether()/IP()/GRE()
> > > >
> > > > Tested on stock Debian kernel, with in-kernel driver and one from
> > > DPDK-2.2.
> > > > Linux lab1 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt25-2 (2016-04-08)
> > > x86_64
> > > > GNU/Linux
> > > >
> > > > Best Regards,
> > > > Micha? Miros?aw
> > > How exactly is DPDK involved? Is it running in all instances where the
> > > issue is seen? Have you tried the latest i40e driver from our
> Sourceforge
> > > site (http://e1000.sf.net)?
> > >
> > > Cheers,
> > > John
> > >
> > >
> > >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osuosl.org/pipermail/intel-wired-lan/attachments/20160422/84bd113e/attachment-0001.html>
^ permalink raw reply [flat|nested] 13+ messages in thread
* [Intel-wired-lan] [E1000-devel] i40e: Deadly GRE packet
2016-04-22 8:29 ` =?unknown-8bit?q?Micha=C5=82_Miros=C5=82aw?=
@ 2016-04-29 8:12 ` =?unknown-8bit?q?Micha=C5=82_Miros=C5=82aw?=
2016-04-29 9:24 ` Pavel Odintsov
0 siblings, 1 reply; 13+ messages in thread
From: =?unknown-8bit?q?Micha=C5=82_Miros=C5=82aw?= @ 2016-04-29 8:12 UTC (permalink / raw)
To: intel-wired-lan
Hi,
Were you able to reproduce the issue? Is there anything we can do to help
to a fix?
Best Regards,
Micha? Miros?aw
2016-04-22 10:29 GMT+02:00 Micha? Miros?aw <
michal.miroslaw@atendesoftware.pl>:
> There are no messages besides link up when the receiver is failing.
>
> Best Regards,
> Micha? Miros?aw
>
> [60757.845623] i40e: Intel(R) 40-10 Gigabit Ethernet Connection Network
> Driver - version 1.5.18
> [60757.845629] i40e: Copyright(c) 2013 - 2016 Intel Corporation.
> [...]
> [60758.316280] i40e 0000:01:00.1: fw 5.0.40043 api 1.5 nvm 5.02 0x80002283
> 0.0.0
> [60758.389654] i40e 0000:01:00.1: MAC address: 0c:c4:7a:bc:a1:89
> [60758.399911] i40e 0000:01:00.1: Query for DCB configuration failed, err
> I40E_ERR_ADMIN_QUEUE_ERROR aq_err I40E_AQ_RC_EPERM
> [60758.399917] i40e 0000:01:00.1: DCB init failed -53, disabled
> [60758.399975] i40e 0000:01:00.1: irq 107 for MSI/MSI-X
> [60758.399987] i40e 0000:01:00.1: irq 108 for MSI/MSI-X
> [60758.399998] i40e 0000:01:00.1: irq 109 for MSI/MSI-X
> [60758.400009] i40e 0000:01:00.1: irq 110 for MSI/MSI-X
> [60758.400020] i40e 0000:01:00.1: irq 111 for MSI/MSI-X
> [60758.400031] i40e 0000:01:00.1: irq 112 for MSI/MSI-X
> [60758.400042] i40e 0000:01:00.1: irq 113 for MSI/MSI-X
> [60758.400052] i40e 0000:01:00.1: irq 114 for MSI/MSI-X
> [60758.400064] i40e 0000:01:00.1: irq 116 for MSI/MSI-X
> [60758.400075] i40e 0000:01:00.1: irq 117 for MSI/MSI-X
> [60758.400086] i40e 0000:01:00.1: irq 118 for MSI/MSI-X
> [60758.400097] i40e 0000:01:00.1: irq 119 for MSI/MSI-X
> [60758.400108] i40e 0000:01:00.1: irq 120 for MSI/MSI-X
> [60758.400119] i40e 0000:01:00.1: irq 121 for MSI/MSI-X
> [60758.400130] i40e 0000:01:00.1: irq 122 for MSI/MSI-X
> [60758.400141] i40e 0000:01:00.1: irq 123 for MSI/MSI-X
> [60758.400151] i40e 0000:01:00.1: irq 124 for MSI/MSI-X
> [60758.400162] i40e 0000:01:00.1: irq 125 for MSI/MSI-X
> [60758.400173] i40e 0000:01:00.1: irq 126 for MSI/MSI-X
> [60758.400184] i40e 0000:01:00.1: irq 127 for MSI/MSI-X
> [60758.400195] i40e 0000:01:00.1: irq 128 for MSI/MSI-X
> [60758.400206] i40e 0000:01:00.1: irq 129 for MSI/MSI-X
> [60758.400217] i40e 0000:01:00.1: irq 130 for MSI/MSI-X
> [60758.400228] i40e 0000:01:00.1: irq 131 for MSI/MSI-X
> [60758.400238] i40e 0000:01:00.1: irq 132 for MSI/MSI-X
> [60758.400250] i40e 0000:01:00.1: irq 133 for MSI/MSI-X
> [60758.400260] i40e 0000:01:00.1: irq 134 for MSI/MSI-X
> [60758.400271] i40e 0000:01:00.1: irq 135 for MSI/MSI-X
> [60758.400293] i40e 0000:01:00.1: irq 136 for MSI/MSI-X
> [60758.400303] i40e 0000:01:00.1: irq 137 for MSI/MSI-X
> [60758.400313] i40e 0000:01:00.1: irq 138 for MSI/MSI-X
> [60758.400322] i40e 0000:01:00.1: irq 139 for MSI/MSI-X
> [60758.400331] i40e 0000:01:00.1: irq 140 for MSI/MSI-X
> [60758.400341] i40e 0000:01:00.1: irq 141 for MSI/MSI-X
> [60758.400351] i40e 0000:01:00.1: irq 142 for MSI/MSI-X
> [60758.400360] i40e 0000:01:00.1: irq 143 for MSI/MSI-X
> [60758.400370] i40e 0000:01:00.1: irq 144 for MSI/MSI-X
> [60758.400379] i40e 0000:01:00.1: irq 145 for MSI/MSI-X
> [60758.400388] i40e 0000:01:00.1: irq 146 for MSI/MSI-X
> [60758.400398] i40e 0000:01:00.1: irq 147 for MSI/MSI-X
> [60758.400408] i40e 0000:01:00.1: irq 148 for MSI/MSI-X
> [60758.400418] i40e 0000:01:00.1: irq 149 for MSI/MSI-X
> [60758.600290] i40e 0000:01:00.1: PCI-Express: Speed 8.0GT/s Width x8
> [60758.629802] i40e 0000:01:00.1: Features: PF-id[1] VFs: 32 VSIs: 34 QP:
> 32 RSS FD_ATR FD_SB NTUPLE CloudF VxLAN NVGRE PTP VEPA
> [...]
> [60769.222107] i40e 0000:01:00.2 eth4: NIC Link is Up 10 Gbps Full Duplex,
> Flow Control: None
> [60771.217551] device eth4 entered promiscuous mode
> [...] test runs here, no messages during that time
> [60816.884307] device eth4 left promiscuous mode
>
>
>
> 2016-04-21 20:03 GMT+02:00 Wyborny, Carolyn <carolyn.wyborny@intel.com>:
>
>> Thanks Michal,
>>
>> Can we also get a full dmesg log from the receiving side during a repro?
>>
>> Carolyn
>>
>> > -----Original Message-----
>> > From: Micha? Miros?aw [mailto:michal.miroslaw at atendesoftware.pl]
>> > Sent: Thursday, April 21, 2016 8:04 AM
>> > To: Ronciak, John <john.ronciak@intel.com>
>> > Cc: e1000-devel at lists.sourceforge.net; mirq-linux at rere.qmqm.pl;
>> intel-wired-
>> > lan at lists.osuosl.org; Pawel Malachowski
>> > <pawel.malachowski@atendesoftware.pl>
>> > Subject: Re: [E1000-devel] i40e: Deadly GRE packet
>> >
>> > Dear John,
>> >
>> > We found the problem using our DPDK application, but later on we
>> reproduced
>> > the same issue using in-kernel drivers (even after fresh reboot).
>> >
>> > Best Regards,
>> > Micha? Miros?aw
>> >
>> > 2016-04-21 16:54 GMT+02:00 Ronciak, John <john.ronciak@intel.com>:
>> >
>> > > > -----Original Message-----
>> > > > From: Micha? Miros?aw [mailto:michal.miroslaw at atendesoftware.pl]
>> > > > Sent: Thursday, April 21, 2016 5:45 AM
>> > > > To: e1000-devel at lists.sourceforge.net;
>> intel-wired-lan at lists.osuosl.org
>> > > > Cc: Pawe? Ma?achowski <pawel.malachowski@atendesoftware.pl>; mirq-
>> > > > linux at rere.qmqm.pl
>> > > > Subject: [E1000-devel] i40e: Deadly GRE packet
>> > > >
>> > > > Dear Developers,
>> > > >
>> > > > I have a setup of a pair of SuperMicro-branded XL710s connected with
>> > > > passive crossover cable, one (eth4) is using firmware 5.0, the other
>> > > (eth7) is
>> > > > using fw 4.33. When I send couple of packets with no payload in GRE
>> over
>> > > IP
>> > > > over ETH from eth7 to eth4, the receiving card stops processing
>> further
>> > > > packets. It seems that 4 empty-GRE packets in succession are enough
>> to
>> > > kill
>> > > > the card's receivers (all ports stop working), more if there are
>> other
>> > > packets
>> > > > inbetween. Transmit direction is not affected. After reboot, the
>> card
>> > > comes
>> > > > back, reloading the driver (or unbind/bind) is not enough to fix the
>> > > problem.
>> > > >
>> > > > 14:31:24.299203 00:00:00:00:00:00 > ff:ff:ff:ff:ff:ff, ethertype
>> IPv4
>> > > (0x0800),
>> > > > length 60: (tos 0x0, ttl 64, id 1, offset 0, flags [none], proto GRE
>> > > (47), length
>> > > > 24)
>> > > > 127.0.0.1 > 127.0.0.1: GREv0, Flags [none], proto unknown
>> (0x0000),
>> > > length
>> > > > 4
>> > > > gre-proto-0x0
>> > > > 0x0000: 4500 0018 0001 0000 402f 7cb4 7f00 0001 E.......@
>> > > /|.....
>> > > > 0x0010: 7f00 0001 0000 0000 0000 0000 0000 0000
>> > > ................
>> > > > 0x0020: 0000 0000 0000 0000 0000 0000 0000
>> ..............
>> > > >
>> > > > scapy 2.2.0 generates this packet from: Ether()/IP()/GRE()
>> > > >
>> > > > Tested on stock Debian kernel, with in-kernel driver and one from
>> > > DPDK-2.2.
>> > > > Linux lab1 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt25-2 (2016-04-08)
>> > > x86_64
>> > > > GNU/Linux
>> > > >
>> > > > Best Regards,
>> > > > Micha? Miros?aw
>> > > How exactly is DPDK involved? Is it running in all instances where
>> the
>> > > issue is seen? Have you tried the latest i40e driver from our
>> Sourceforge
>> > > site (http://e1000.sf.net)?
>> > >
>> > > Cheers,
>> > > John
>> > >
>> > >
>> > >
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osuosl.org/pipermail/intel-wired-lan/attachments/20160429/34595129/attachment-0001.html>
^ permalink raw reply [flat|nested] 13+ messages in thread
* [Intel-wired-lan] [E1000-devel] i40e: Deadly GRE packet
2016-04-29 8:12 ` =?unknown-8bit?q?Micha=C5=82_Miros=C5=82aw?=
@ 2016-04-29 9:24 ` Pavel Odintsov
2016-04-29 12:25 ` =?unknown-8bit?q?Micha=C5=82_Miros=C5=82aw?=
0 siblings, 1 reply; 13+ messages in thread
From: Pavel Odintsov @ 2016-04-29 9:24 UTC (permalink / raw)
To: intel-wired-lan
Hello!
I'm not sure that's a right place for discussing zero-day
vulnerabilities. But actually, I do not know other ways how to reach
Intel engineers with this sort of issues.
On Fri, Apr 29, 2016 at 11:12 AM, Micha? Miros?aw
<michal.miroslaw@atendesoftware.pl> wrote:
> Hi,
>
> Were you able to reproduce the issue? Is there anything we can do to help
> to a fix?
>
> Best Regards,
> Micha? Miros?aw
>
> 2016-04-22 10:29 GMT+02:00 Micha? Miros?aw <
> michal.miroslaw at atendesoftware.pl>:
>
>> There are no messages besides link up when the receiver is failing.
>>
>> Best Regards,
>> Micha? Miros?aw
>>
>> [60757.845623] i40e: Intel(R) 40-10 Gigabit Ethernet Connection Network
>> Driver - version 1.5.18
>> [60757.845629] i40e: Copyright(c) 2013 - 2016 Intel Corporation.
>> [...]
>> [60758.316280] i40e 0000:01:00.1: fw 5.0.40043 api 1.5 nvm 5.02 0x80002283
>> 0.0.0
>> [60758.389654] i40e 0000:01:00.1: MAC address: 0c:c4:7a:bc:a1:89
>> [60758.399911] i40e 0000:01:00.1: Query for DCB configuration failed, err
>> I40E_ERR_ADMIN_QUEUE_ERROR aq_err I40E_AQ_RC_EPERM
>> [60758.399917] i40e 0000:01:00.1: DCB init failed -53, disabled
>> [60758.399975] i40e 0000:01:00.1: irq 107 for MSI/MSI-X
>> [60758.399987] i40e 0000:01:00.1: irq 108 for MSI/MSI-X
>> [60758.399998] i40e 0000:01:00.1: irq 109 for MSI/MSI-X
>> [60758.400009] i40e 0000:01:00.1: irq 110 for MSI/MSI-X
>> [60758.400020] i40e 0000:01:00.1: irq 111 for MSI/MSI-X
>> [60758.400031] i40e 0000:01:00.1: irq 112 for MSI/MSI-X
>> [60758.400042] i40e 0000:01:00.1: irq 113 for MSI/MSI-X
>> [60758.400052] i40e 0000:01:00.1: irq 114 for MSI/MSI-X
>> [60758.400064] i40e 0000:01:00.1: irq 116 for MSI/MSI-X
>> [60758.400075] i40e 0000:01:00.1: irq 117 for MSI/MSI-X
>> [60758.400086] i40e 0000:01:00.1: irq 118 for MSI/MSI-X
>> [60758.400097] i40e 0000:01:00.1: irq 119 for MSI/MSI-X
>> [60758.400108] i40e 0000:01:00.1: irq 120 for MSI/MSI-X
>> [60758.400119] i40e 0000:01:00.1: irq 121 for MSI/MSI-X
>> [60758.400130] i40e 0000:01:00.1: irq 122 for MSI/MSI-X
>> [60758.400141] i40e 0000:01:00.1: irq 123 for MSI/MSI-X
>> [60758.400151] i40e 0000:01:00.1: irq 124 for MSI/MSI-X
>> [60758.400162] i40e 0000:01:00.1: irq 125 for MSI/MSI-X
>> [60758.400173] i40e 0000:01:00.1: irq 126 for MSI/MSI-X
>> [60758.400184] i40e 0000:01:00.1: irq 127 for MSI/MSI-X
>> [60758.400195] i40e 0000:01:00.1: irq 128 for MSI/MSI-X
>> [60758.400206] i40e 0000:01:00.1: irq 129 for MSI/MSI-X
>> [60758.400217] i40e 0000:01:00.1: irq 130 for MSI/MSI-X
>> [60758.400228] i40e 0000:01:00.1: irq 131 for MSI/MSI-X
>> [60758.400238] i40e 0000:01:00.1: irq 132 for MSI/MSI-X
>> [60758.400250] i40e 0000:01:00.1: irq 133 for MSI/MSI-X
>> [60758.400260] i40e 0000:01:00.1: irq 134 for MSI/MSI-X
>> [60758.400271] i40e 0000:01:00.1: irq 135 for MSI/MSI-X
>> [60758.400293] i40e 0000:01:00.1: irq 136 for MSI/MSI-X
>> [60758.400303] i40e 0000:01:00.1: irq 137 for MSI/MSI-X
>> [60758.400313] i40e 0000:01:00.1: irq 138 for MSI/MSI-X
>> [60758.400322] i40e 0000:01:00.1: irq 139 for MSI/MSI-X
>> [60758.400331] i40e 0000:01:00.1: irq 140 for MSI/MSI-X
>> [60758.400341] i40e 0000:01:00.1: irq 141 for MSI/MSI-X
>> [60758.400351] i40e 0000:01:00.1: irq 142 for MSI/MSI-X
>> [60758.400360] i40e 0000:01:00.1: irq 143 for MSI/MSI-X
>> [60758.400370] i40e 0000:01:00.1: irq 144 for MSI/MSI-X
>> [60758.400379] i40e 0000:01:00.1: irq 145 for MSI/MSI-X
>> [60758.400388] i40e 0000:01:00.1: irq 146 for MSI/MSI-X
>> [60758.400398] i40e 0000:01:00.1: irq 147 for MSI/MSI-X
>> [60758.400408] i40e 0000:01:00.1: irq 148 for MSI/MSI-X
>> [60758.400418] i40e 0000:01:00.1: irq 149 for MSI/MSI-X
>> [60758.600290] i40e 0000:01:00.1: PCI-Express: Speed 8.0GT/s Width x8
>> [60758.629802] i40e 0000:01:00.1: Features: PF-id[1] VFs: 32 VSIs: 34 QP:
>> 32 RSS FD_ATR FD_SB NTUPLE CloudF VxLAN NVGRE PTP VEPA
>> [...]
>> [60769.222107] i40e 0000:01:00.2 eth4: NIC Link is Up 10 Gbps Full Duplex,
>> Flow Control: None
>> [60771.217551] device eth4 entered promiscuous mode
>> [...] test runs here, no messages during that time
>> [60816.884307] device eth4 left promiscuous mode
>>
>>
>>
>> 2016-04-21 20:03 GMT+02:00 Wyborny, Carolyn <carolyn.wyborny@intel.com>:
>>
>>> Thanks Michal,
>>>
>>> Can we also get a full dmesg log from the receiving side during a repro?
>>>
>>> Carolyn
>>>
>>> > -----Original Message-----
>>> > From: Micha? Miros?aw [mailto:michal.miroslaw at atendesoftware.pl]
>>> > Sent: Thursday, April 21, 2016 8:04 AM
>>> > To: Ronciak, John <john.ronciak@intel.com>
>>> > Cc: e1000-devel at lists.sourceforge.net; mirq-linux at rere.qmqm.pl;
>>> intel-wired-
>>> > lan at lists.osuosl.org; Pawel Malachowski
>>> > <pawel.malachowski@atendesoftware.pl>
>>> > Subject: Re: [E1000-devel] i40e: Deadly GRE packet
>>> >
>>> > Dear John,
>>> >
>>> > We found the problem using our DPDK application, but later on we
>>> reproduced
>>> > the same issue using in-kernel drivers (even after fresh reboot).
>>> >
>>> > Best Regards,
>>> > Micha? Miros?aw
>>> >
>>> > 2016-04-21 16:54 GMT+02:00 Ronciak, John <john.ronciak@intel.com>:
>>> >
>>> > > > -----Original Message-----
>>> > > > From: Micha? Miros?aw [mailto:michal.miroslaw at atendesoftware.pl]
>>> > > > Sent: Thursday, April 21, 2016 5:45 AM
>>> > > > To: e1000-devel at lists.sourceforge.net;
>>> intel-wired-lan at lists.osuosl.org
>>> > > > Cc: Pawe? Ma?achowski <pawel.malachowski@atendesoftware.pl>; mirq-
>>> > > > linux at rere.qmqm.pl
>>> > > > Subject: [E1000-devel] i40e: Deadly GRE packet
>>> > > >
>>> > > > Dear Developers,
>>> > > >
>>> > > > I have a setup of a pair of SuperMicro-branded XL710s connected with
>>> > > > passive crossover cable, one (eth4) is using firmware 5.0, the other
>>> > > (eth7) is
>>> > > > using fw 4.33. When I send couple of packets with no payload in GRE
>>> over
>>> > > IP
>>> > > > over ETH from eth7 to eth4, the receiving card stops processing
>>> further
>>> > > > packets. It seems that 4 empty-GRE packets in succession are enough
>>> to
>>> > > kill
>>> > > > the card's receivers (all ports stop working), more if there are
>>> other
>>> > > packets
>>> > > > inbetween. Transmit direction is not affected. After reboot, the
>>> card
>>> > > comes
>>> > > > back, reloading the driver (or unbind/bind) is not enough to fix the
>>> > > problem.
>>> > > >
>>> > > > 14:31:24.299203 00:00:00:00:00:00 > ff:ff:ff:ff:ff:ff, ethertype
>>> IPv4
>>> > > (0x0800),
>>> > > > length 60: (tos 0x0, ttl 64, id 1, offset 0, flags [none], proto GRE
>>> > > (47), length
>>> > > > 24)
>>> > > > 127.0.0.1 > 127.0.0.1: GREv0, Flags [none], proto unknown
>>> (0x0000),
>>> > > length
>>> > > > 4
>>> > > > gre-proto-0x0
>>> > > > 0x0000: 4500 0018 0001 0000 402f 7cb4 7f00 0001 E.......@
>>> > > /|.....
>>> > > > 0x0010: 7f00 0001 0000 0000 0000 0000 0000 0000
>>> > > ................
>>> > > > 0x0020: 0000 0000 0000 0000 0000 0000 0000
>>> ..............
>>> > > >
>>> > > > scapy 2.2.0 generates this packet from: Ether()/IP()/GRE()
>>> > > >
>>> > > > Tested on stock Debian kernel, with in-kernel driver and one from
>>> > > DPDK-2.2.
>>> > > > Linux lab1 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt25-2 (2016-04-08)
>>> > > x86_64
>>> > > > GNU/Linux
>>> > > >
>>> > > > Best Regards,
>>> > > > Micha? Miros?aw
>>> > > How exactly is DPDK involved? Is it running in all instances where
>>> the
>>> > > issue is seen? Have you tried the latest i40e driver from our
>>> Sourceforge
>>> > > site (http://e1000.sf.net)?
>>> > >
>>> > > Cheers,
>>> > > John
>>> > >
>>> > >
>>> > >
>>>
>>
>>
>
> ------------------------------------------------------------------------------
> Find and fix application performance issues faster with Applications Manager
> Applications Manager provides deep performance insights into multiple tiers of
> your business applications. It resolves application problems quickly and
> reduces your MTTR. Get your free trial!
> https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
> _______________________________________________
> E1000-devel mailing list
> E1000-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/e1000-devel
> To learn more about Intel® Ethernet, visit http://communities.intel.com/community/wired
>
--
Sincerely yours, Pavel Odintsov
^ permalink raw reply [flat|nested] 13+ messages in thread
* [Intel-wired-lan] [E1000-devel] i40e: Deadly GRE packet
2016-04-29 9:24 ` Pavel Odintsov
@ 2016-04-29 12:25 ` =?unknown-8bit?q?Micha=C5=82_Miros=C5=82aw?=
0 siblings, 0 replies; 13+ messages in thread
From: =?unknown-8bit?q?Micha=C5=82_Miros=C5=82aw?= @ 2016-04-29 12:25 UTC (permalink / raw)
To: intel-wired-lan
And I tried so hard to avoid including such scary Google keywords in my
report... ;-)
But point taken - I should have not sent all the details publicly at once.
Sorry about that.
Best Regards,
Micha? Miros?aw
2016-04-29 11:24 GMT+02:00 Pavel Odintsov <pavel.odintsov@gmail.com>:
> Hello!
>
> I'm not sure that's a right place for discussing zero-day
> vulnerabilities. But actually, I do not know other ways how to reach
> Intel engineers with this sort of issues.
>
>
>
>
>
> On Fri, Apr 29, 2016 at 11:12 AM, Micha? Miros?aw
> <michal.miroslaw@atendesoftware.pl> wrote:
> > Hi,
> >
> > Were you able to reproduce the issue? Is there anything we can do to help
> > to a fix?
> >
> > Best Regards,
> > Micha? Miros?aw
> >
> > 2016-04-22 10:29 GMT+02:00 Micha? Miros?aw <
> > michal.miroslaw at atendesoftware.pl>:
> >
> >> There are no messages besides link up when the receiver is failing.
> >>
> >> Best Regards,
> >> Micha? Miros?aw
> >>
> >> [60757.845623] i40e: Intel(R) 40-10 Gigabit Ethernet Connection Network
> >> Driver - version 1.5.18
> >> [60757.845629] i40e: Copyright(c) 2013 - 2016 Intel Corporation.
> >> [...]
> >> [60758.316280] i40e 0000:01:00.1: fw 5.0.40043 api 1.5 nvm 5.02
> 0x80002283
> >> 0.0.0
> >> [60758.389654] i40e 0000:01:00.1: MAC address: 0c:c4:7a:bc:a1:89
> >> [60758.399911] i40e 0000:01:00.1: Query for DCB configuration failed,
> err
> >> I40E_ERR_ADMIN_QUEUE_ERROR aq_err I40E_AQ_RC_EPERM
> >> [60758.399917] i40e 0000:01:00.1: DCB init failed -53, disabled
> >> [60758.399975] i40e 0000:01:00.1: irq 107 for MSI/MSI-X
> >> [60758.399987] i40e 0000:01:00.1: irq 108 for MSI/MSI-X
> >> [60758.399998] i40e 0000:01:00.1: irq 109 for MSI/MSI-X
> >> [60758.400009] i40e 0000:01:00.1: irq 110 for MSI/MSI-X
> >> [60758.400020] i40e 0000:01:00.1: irq 111 for MSI/MSI-X
> >> [60758.400031] i40e 0000:01:00.1: irq 112 for MSI/MSI-X
> >> [60758.400042] i40e 0000:01:00.1: irq 113 for MSI/MSI-X
> >> [60758.400052] i40e 0000:01:00.1: irq 114 for MSI/MSI-X
> >> [60758.400064] i40e 0000:01:00.1: irq 116 for MSI/MSI-X
> >> [60758.400075] i40e 0000:01:00.1: irq 117 for MSI/MSI-X
> >> [60758.400086] i40e 0000:01:00.1: irq 118 for MSI/MSI-X
> >> [60758.400097] i40e 0000:01:00.1: irq 119 for MSI/MSI-X
> >> [60758.400108] i40e 0000:01:00.1: irq 120 for MSI/MSI-X
> >> [60758.400119] i40e 0000:01:00.1: irq 121 for MSI/MSI-X
> >> [60758.400130] i40e 0000:01:00.1: irq 122 for MSI/MSI-X
> >> [60758.400141] i40e 0000:01:00.1: irq 123 for MSI/MSI-X
> >> [60758.400151] i40e 0000:01:00.1: irq 124 for MSI/MSI-X
> >> [60758.400162] i40e 0000:01:00.1: irq 125 for MSI/MSI-X
> >> [60758.400173] i40e 0000:01:00.1: irq 126 for MSI/MSI-X
> >> [60758.400184] i40e 0000:01:00.1: irq 127 for MSI/MSI-X
> >> [60758.400195] i40e 0000:01:00.1: irq 128 for MSI/MSI-X
> >> [60758.400206] i40e 0000:01:00.1: irq 129 for MSI/MSI-X
> >> [60758.400217] i40e 0000:01:00.1: irq 130 for MSI/MSI-X
> >> [60758.400228] i40e 0000:01:00.1: irq 131 for MSI/MSI-X
> >> [60758.400238] i40e 0000:01:00.1: irq 132 for MSI/MSI-X
> >> [60758.400250] i40e 0000:01:00.1: irq 133 for MSI/MSI-X
> >> [60758.400260] i40e 0000:01:00.1: irq 134 for MSI/MSI-X
> >> [60758.400271] i40e 0000:01:00.1: irq 135 for MSI/MSI-X
> >> [60758.400293] i40e 0000:01:00.1: irq 136 for MSI/MSI-X
> >> [60758.400303] i40e 0000:01:00.1: irq 137 for MSI/MSI-X
> >> [60758.400313] i40e 0000:01:00.1: irq 138 for MSI/MSI-X
> >> [60758.400322] i40e 0000:01:00.1: irq 139 for MSI/MSI-X
> >> [60758.400331] i40e 0000:01:00.1: irq 140 for MSI/MSI-X
> >> [60758.400341] i40e 0000:01:00.1: irq 141 for MSI/MSI-X
> >> [60758.400351] i40e 0000:01:00.1: irq 142 for MSI/MSI-X
> >> [60758.400360] i40e 0000:01:00.1: irq 143 for MSI/MSI-X
> >> [60758.400370] i40e 0000:01:00.1: irq 144 for MSI/MSI-X
> >> [60758.400379] i40e 0000:01:00.1: irq 145 for MSI/MSI-X
> >> [60758.400388] i40e 0000:01:00.1: irq 146 for MSI/MSI-X
> >> [60758.400398] i40e 0000:01:00.1: irq 147 for MSI/MSI-X
> >> [60758.400408] i40e 0000:01:00.1: irq 148 for MSI/MSI-X
> >> [60758.400418] i40e 0000:01:00.1: irq 149 for MSI/MSI-X
> >> [60758.600290] i40e 0000:01:00.1: PCI-Express: Speed 8.0GT/s Width x8
> >> [60758.629802] i40e 0000:01:00.1: Features: PF-id[1] VFs: 32 VSIs: 34
> QP:
> >> 32 RSS FD_ATR FD_SB NTUPLE CloudF VxLAN NVGRE PTP VEPA
> >> [...]
> >> [60769.222107] i40e 0000:01:00.2 eth4: NIC Link is Up 10 Gbps Full
> Duplex,
> >> Flow Control: None
> >> [60771.217551] device eth4 entered promiscuous mode
> >> [...] test runs here, no messages during that time
> >> [60816.884307] device eth4 left promiscuous mode
> >>
> >>
> >>
> >> 2016-04-21 20:03 GMT+02:00 Wyborny, Carolyn <carolyn.wyborny@intel.com
> >:
> >>
> >>> Thanks Michal,
> >>>
> >>> Can we also get a full dmesg log from the receiving side during a
> repro?
> >>>
> >>> Carolyn
> >>>
> >>> > -----Original Message-----
> >>> > From: Micha? Miros?aw [mailto:michal.miroslaw at atendesoftware.pl]
> >>> > Sent: Thursday, April 21, 2016 8:04 AM
> >>> > To: Ronciak, John <john.ronciak@intel.com>
> >>> > Cc: e1000-devel at lists.sourceforge.net; mirq-linux at rere.qmqm.pl;
> >>> intel-wired-
> >>> > lan at lists.osuosl.org; Pawel Malachowski
> >>> > <pawel.malachowski@atendesoftware.pl>
> >>> > Subject: Re: [E1000-devel] i40e: Deadly GRE packet
> >>> >
> >>> > Dear John,
> >>> >
> >>> > We found the problem using our DPDK application, but later on we
> >>> reproduced
> >>> > the same issue using in-kernel drivers (even after fresh reboot).
> >>> >
> >>> > Best Regards,
> >>> > Micha? Miros?aw
> >>> >
> >>> > 2016-04-21 16:54 GMT+02:00 Ronciak, John <john.ronciak@intel.com>:
> >>> >
> >>> > > > -----Original Message-----
> >>> > > > From: Micha? Miros?aw [mailto:michal.miroslaw at atendesoftware.pl]
> >>> > > > Sent: Thursday, April 21, 2016 5:45 AM
> >>> > > > To: e1000-devel at lists.sourceforge.net;
> >>> intel-wired-lan at lists.osuosl.org
> >>> > > > Cc: Pawe? Ma?achowski <pawel.malachowski@atendesoftware.pl>;
> mirq-
> >>> > > > linux at rere.qmqm.pl
> >>> > > > Subject: [E1000-devel] i40e: Deadly GRE packet
> >>> > > >
> >>> > > > Dear Developers,
> >>> > > >
> >>> > > > I have a setup of a pair of SuperMicro-branded XL710s connected
> with
> >>> > > > passive crossover cable, one (eth4) is using firmware 5.0, the
> other
> >>> > > (eth7) is
> >>> > > > using fw 4.33. When I send couple of packets with no payload in
> GRE
> >>> over
> >>> > > IP
> >>> > > > over ETH from eth7 to eth4, the receiving card stops processing
> >>> further
> >>> > > > packets. It seems that 4 empty-GRE packets in succession are
> enough
> >>> to
> >>> > > kill
> >>> > > > the card's receivers (all ports stop working), more if there are
> >>> other
> >>> > > packets
> >>> > > > inbetween. Transmit direction is not affected. After reboot, the
> >>> card
> >>> > > comes
> >>> > > > back, reloading the driver (or unbind/bind) is not enough to fix
> the
> >>> > > problem.
> >>> > > >
> >>> > > > 14:31:24.299203 00:00:00:00:00:00 > ff:ff:ff:ff:ff:ff, ethertype
> >>> IPv4
> >>> > > (0x0800),
> >>> > > > length 60: (tos 0x0, ttl 64, id 1, offset 0, flags [none], proto
> GRE
> >>> > > (47), length
> >>> > > > 24)
> >>> > > > 127.0.0.1 > 127.0.0.1: GREv0, Flags [none], proto unknown
> >>> (0x0000),
> >>> > > length
> >>> > > > 4
> >>> > > > gre-proto-0x0
> >>> > > > 0x0000: 4500 0018 0001 0000 402f 7cb4 7f00 0001
> E.......@
> >>> > > /|.....
> >>> > > > 0x0010: 7f00 0001 0000 0000 0000 0000 0000 0000
> >>> > > ................
> >>> > > > 0x0020: 0000 0000 0000 0000 0000 0000 0000
> >>> ..............
> >>> > > >
> >>> > > > scapy 2.2.0 generates this packet from: Ether()/IP()/GRE()
> >>> > > >
> >>> > > > Tested on stock Debian kernel, with in-kernel driver and one from
> >>> > > DPDK-2.2.
> >>> > > > Linux lab1 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt25-2
> (2016-04-08)
> >>> > > x86_64
> >>> > > > GNU/Linux
> >>> > > >
> >>> > > > Best Regards,
> >>> > > > Micha? Miros?aw
> >>> > > How exactly is DPDK involved? Is it running in all instances where
> >>> the
> >>> > > issue is seen? Have you tried the latest i40e driver from our
> >>> Sourceforge
> >>> > > site (http://e1000.sf.net)?
> >>> > >
> >>> > > Cheers,
> >>> > > John
> >>> > >
> >>> > >
> >>> > >
> >>>
> >>
> >>
> >
> >
> ------------------------------------------------------------------------------
> > Find and fix application performance issues faster with Applications
> Manager
> > Applications Manager provides deep performance insights into multiple
> tiers of
> > your business applications. It resolves application problems quickly and
> > reduces your MTTR. Get your free trial!
> > https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
> > _______________________________________________
> > E1000-devel mailing list
> > E1000-devel at lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/e1000-devel
> > To learn more about Intel® Ethernet, visit
> http://communities.intel.com/community/wired
> >
>
>
>
> --
> Sincerely yours, Pavel Odintsov
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osuosl.org/pipermail/intel-wired-lan/attachments/20160429/454330ea/attachment.html>
^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2016-04-29 12:25 UTC | newest]
Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-04-21 12:45 [Intel-wired-lan] i40e: Deadly GRE packet =?unknown-8bit?q?Micha=C5=82_Miros=C5=82aw?=
2016-04-21 14:51 ` [Intel-wired-lan] [E1000-devel] " Wyborny, Carolyn
2016-04-21 14:54 ` Ronciak, John
2016-04-21 15:04 ` =?unknown-8bit?q?Micha=C5=82_Miros=C5=82aw?=
2016-04-21 15:19 ` Ronciak, John
2016-04-21 15:29 ` =?unknown-8bit?q?Micha=C5=82_Miros=C5=82aw?=
2016-04-21 18:03 ` Wyborny, Carolyn
2016-04-22 8:29 ` =?unknown-8bit?q?Micha=C5=82_Miros=C5=82aw?=
2016-04-29 8:12 ` =?unknown-8bit?q?Micha=C5=82_Miros=C5=82aw?=
2016-04-29 9:24 ` Pavel Odintsov
2016-04-29 12:25 ` =?unknown-8bit?q?Micha=C5=82_Miros=C5=82aw?=
2016-04-21 14:57 ` Wyborny, Carolyn
2016-04-21 15:06 ` =?unknown-8bit?q?Micha=C5=82_Miros=C5=82aw?=
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.