Hi Jacob, it really might be that but the biggest problem is that the system just does a reset. There is no dump, no panic or something, it just does a full reset of the system. I doubt netconsole will help when console didn't catch anything but I'll give it a try after having tried Marks's earlyprintk hint. Btw. there is no watchdog running that might do the reset.
On 2015-06-26 18:10, Keller, Jacob E wrote: > 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 >> -- Regards, Christian Ruppert ------------------------------------------------------------------------------ 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
