https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=200319
Oleg Sharoyko <osharo...@gmail.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |osharo...@gmail.com
--- Comment #15 from Oleg Sharoyko <osharo...@gmail.com> ---
Hello,
I can reliably reproduce this problem on three systems running 12.0 and 11.2.
To reproduce it one needs to send a non negligible amount of traffic towards
the system under test so I cannot provide the exact script but I hope my
instructions are clear and I’m happy to provide as much details as I can.
To reproduce a problem configure the system in the following way:
ifconfig ue0 up # Or any other ethernet interface that you have in the system
ifconfig bridge0 create
ifconfig bridge0 addm ue0
ifconfig bridge0 inet 192.168.0.111/24 vhid 1 advskew 100 pass mekmitasdigoat
pkg install iperf3
iperf3 -s
From some other machine send traffic towards system under test:
iperf3 -c 192.168.0.111 -u -t 120 -Z -b 100m
In all of my tests this resulted in immediate (within 2 seconds) lockup of the
network stack on the target system. Excluding bridge interface from the picture
and configuring CARP directly on top of ue0 (also tested with rl0) eliminates
the problem.
I will try to look more into this problem but I'm not familiar with locking in
the kernel. Are there any documents/exmaples/kernel options which can help find
where deadlock happens?
Also, https://reviews.freebsd.org/D3133 had no attention for over a year. But
looks like it has been applied in pfSense and works there
(https://redmine.pfsense.org/issues/8056) is that something woth looking into?
Kind regards,
Oleg
--
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"
