i can reproduce this daily using flowtable on a wifi enabled PC on -HEAD.
-adrian On 12 January 2017 at 06:13, Jakub Palider <j...@semihalf.com> wrote: > An update: eventually, FLOWTABLE option also resulted in crash with > __rw_lock_hard on FreeBSD release/11.0.0 (also on VM). > This time, however, the backtrace was different, instead of > tcp_output->ip_output->ether_output() chain, it happened in > flowtable_clean_vnet() > > On Wed, Jan 11, 2017 at 10:42 AM, Jakub Palider <j...@semihalf.com> wrote: > >> On Tue, 29 Nov 2016 11:05:09 -0800 >> Gleb Smirnoff <gleb...@freebsd.org> wrote: >> >> > On Mon, Nov 28, 2016 at 02:10:33PM -0800, hiren panchasara wrote: >> > h> > Hi, >> > h> > I have found that last month (19 Oct) the problem appeared on this >> list, >> > h> > and to my experience it persists, both on VM and bare metal >> installation >> > h> > (HEAD from yesterday). I looks that enabling FLOWTABLE option is >> the only >> > h> > source of this fault happening. It appears on our setup in 80% >> cases within >> > h> > one hour from boot up. >> > h> > From our debugging, it is caused by lock on DESTROYED lock. Did you >> find a >> > h> > solution to this problem? >> > >> > Not yet. >> > >> > I'm pretty sure that reverting my r307234 will fix your crashes. >> However, I still >> > believe that r307234 is a proper way of fixing things, not r300854 which >> just >> > plugged the problem in the nearest place to the crash. But as we all see >> r307234 >> > is definitely missing some code path, which still allows for stale route >> to be >> > referenced. >> > >> > -- >> > Totus tuus, Glebius. >> >> Thank you for your pointer, in helped at some point. The problem >> however returned, especially when under heavy, continuous load. We are >> running 4 iperf3 processes, each having 4 threads, and the machine >> dies after 30-60 minutes of TCP traffic. I am running rS30911112 from >> Nov 24. >> On FreeBSD 11.0-RELEASE this problem (1 full day of testing) was not >> noticed. Could you point to related commits that might also influence >> this behaviour? >> Thanks, >> Jakub >> > _______________________________________________ > 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" _______________________________________________ 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"
