https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=231659
--- Comment #34 from Lev A. Serebryakov <l...@freebsd.org> ---
Ok, I have new data.
Softcrypto or IPsec is only symptom, not cause.
Cause is igb/em driver (different files, logically same place).
I can reproduce driver KASSERT on kernel with INVARIANTS without any crypto at
all.
Conditions are: low-power hardware, high load, receive data as fast as
possible.
On Celeron J3160 + igb(8) it requires to load system with IPSec with soft
crypto to trigger bug. I was not able to trigger it without crypto or AESNI.
On Atom D2500 + em(8) it requires either soft crypto (easy!) or multitude of
plain connections without crypto. For example, 32 iperf3 streams for 2+ minutes
is enough. With IPsec it triggers with 1 stream for 5 seconds.
So, I can reproduce this on Atom D2500 + em(8) with simple "iperf3 -c <server>
-R -t 3600 --nstreams 32
Without INVARIANTS, it is very hard to catch this bug without IPsec. I think,
it is because this memory corruption is hard to notice without additional
traffic processing. I think, IPsec is only way to deiscover that memory is
corrupted, not a way to corrupt memory.
Here is stack trace with INVARIANTS and without any crypto. It is virutally the
same as with crypto. As usual, I can provide kernel file and full crash dump
and can re-run tests with any patches and settings.
I'm sure now, it is bug in Intel driver. Race condition, maybe?
panic: Assertion (staterr & E1000_RXD_STAT_DD) != 0 failed at
/data/src/sys/dev/e1000/em_txrx.c:698
cpuid = 1
time = 1539169364
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe000043f900
vpanic() at vpanic+0x1a3/frame 0xfffffe000043f960
panic() at panic+0x43/frame 0xfffffe000043f9c0
em_isc_rxd_pkt_get() at em_isc_rxd_pkt_get+0x1d4/frame 0xfffffe000043fa10
iflib_rxeof() at iflib_rxeof+0x128/frame 0xfffffe000043fb00
_task_fn_rx() at _task_fn_rx+0x49/frame 0xfffffe000043fb30
gtaskqueue_run_locked() at gtaskqueue_run_locked+0xf9/frame 0xfffffe000043fb80
gtaskqueue_thread_loop() at gtaskqueue_thread_loop+0x88/frame
0xfffffe000043fbb0
fork_exit() at fork_exit+0x84/frame 0xfffffe000043fbf0
fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe000043fbf0
--- trap 0, rip = 0, rsp = 0, rbp = 0 ---
Uptime: 17m24s
Dumping 477 out of 4060 MB:..4%..11%..21%..31%..41%..51%..61%..71%..81%..91%
#0 doadump (textdump=1) at pcpu.h:230
230 pcpu.h: No such file or directory.
in pcpu.h
(kgdb)
#0 doadump (textdump=1) at pcpu.h:230
#1 0xffffffff80565c60 in kern_reboot (howto=260) at
/data/src/sys/kern/kern_shutdown.c:446
#2 0xffffffff805660b3 in vpanic (fmt=<value optimized out>, ap=<value
optimized out>) at /data/src/sys/kern/kern_shutdown.c:872
#3 0xffffffff80565e13 in panic (fmt=<value optimized out>) at
/data/src/sys/kern/kern_shutdown.c:799
#4 0xffffffff803f1d94 in em_isc_rxd_pkt_get (arg=<value optimized out>,
ri=<value optimized out>) at /data/src/sys/dev/e1000/em_txrx.c:698
#5 0xffffffff80668b28 in iflib_rxeof (rxq=0xfffff80002295ac0, budget=<value
optimized out>) at /data/src/sys/net/iflib.c:2684
#6 0xffffffff80664f69 in _task_fn_rx (context=0xfffff80002295ac0) at
/data/src/sys/net/iflib.c:3820
#7 0xffffffff805a6039 in gtaskqueue_run_locked (queue=0xfffff800021dc500) at
/data/src/sys/kern/subr_gtaskqueue.c:332
#8 0xffffffff805a5df8 in gtaskqueue_thread_loop (arg=<value optimized out>) at
/data/src/sys/kern/subr_gtaskqueue.c:507
#9 0xffffffff8052f7e4 in fork_exit (callout=0xffffffff805a5d70
<gtaskqueue_thread_loop>, arg=0xfffffe00017f8020, frame=0xfffffe000043fc00) at
/data/src/sys/kern/kern_fork.c:1057
#10 0xffffffff8081ce2e in fork_trampoline () at
/data/src/sys/amd64/amd64/exception.S:993
#11 0x0000000000000000 in ?? ()
Current language: auto; currently minimal
(kgdb)
--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
