Hi,

Any chance you have more than just the one line of that one time crash
dump? I assume that you do not, but that would be the most helpful
information. My guess is that null pointer deref is the real issue
going on here...

Maybe try setting up netconsole through a different device and see if
you can get a copy of the crash that way? If you setup netconsole to
log to a separate machine and then wait for it to happen you should get
much more details about the issue.

Regards,
Jake

On Fri, 2015-06-26 at 17:42 +0200, Christian Ruppert wrote:
> Hi,
> 
> we have a setup of some E3's with X520 10GE NICs (more details below) 
> 
> and we also use the iptables SYNPROXY[1][2] extension.
> Details:
> CPU: Different E3 Models
> NICs: 8086:10fb Ethernet controller: Intel Corporation 82599EB 
> 10-Gigabit SFI/SFP+ Network Connection (rev 01) (X520-2 8086:0003)
> Kernel: Currently a Debian Backports 3.16.0-4-amd64
> ixgbe: 3.19.1-k
> iptables: 1.4.21-2+b1 also from backports
> 
> The SYNPROXY setup:
> sysctl -w net.netfilter.nf_conntrack_tcp_loose=0
> 
> iptables -t raw -I PREROUTING -p tcp -m tcp --syn -j CT --notrack
> iptables -I INPUT -p tcp -m tcp -m conntrack --ctstate 
> INVALID,UNTRACKED 
> -j SYNPROXY --sack-perm --timestamp --wscale 7 --mss 1460
> iptables -A INPUT -m conntrack --ctstate INVALID -j DROP
> 
> So those systems act as a loadbalancer. In some cases (we're not able 
> to 
> reproduce it by hand) the system (we tried different mainboards, CPUs 
> 
> etc.) just resets. It is not possible to capture anything. Neither 
> via 
> kexec/kdump nor via serial console. We were able to record the VGA 
> output via IPMI and we just saw "BUG: Unable to handle NULL pointer 
> deref" and that's it. That might or might not be related as we were 
> not 
> able to capture it again.
> There is nothing in the logs. We tried tcpreplay and whatnot but we 
> have 
> not much details about it and as I said, we have to wait until it 
> happens. It might take minutes, hours or even several days. The 
> traffic 
> in the specific timeframe looks pretty common so far. There's one 
> thing 
> we now know for sure:
> It only happens in combination of those X520 NICs and the SYNPROXY 
> iptables extension.
> It works fine since several days and even weeks on systems with X520 
> NICs but without the SYNPROXY extension and it works also fine on 
> systems with SYNPROXY but without X520 NICs (we tried 1GE card 
> though).
> The traffic is almost only TCP (the SYNPROXY gets just TCP anyway). 
> HTTP(S) and some streaming stuff.
> 
> Has anybody any ideas how to debug that or even better, is anybody 
> able 
> to reproduce it and/or has have similar issues?
> 
> 
> [1] https://lwn.net/Articles/563151/
> [2] 
> https://r00t-services.net/knowledgebase/14/Homemade-DDoS-Protection
> -Using-IPTables-SYNPROXY.html
> 
------------------------------------------------------------------------------
Monitor 25 network devices or servers for free with OpManager!
OpManager is web-based network management software that monitors 
network devices and physical & virtual servers, alerts via email & sms 
for fault. Monitor 25 devices for free with no restriction. Download now
http://ad.doubleclick.net/ddm/clk/292181274;119417398;o
_______________________________________________
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel® Ethernet, visit 
http://communities.intel.com/community/wired

Reply via email to