Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 25 Jul 2019 18:51:41 +0000
From:      bugzilla-noreply@freebsd.org
To:        bugs@FreeBSD.org
Subject:   [Bug 239351] [panic] spin lock held too long under heavy load (net/wireguard affected)
Message-ID:  <bug-239351-227-hwuC5JlDjC@https.bugs.freebsd.org/bugzilla/>
In-Reply-To: <bug-239351-227@https.bugs.freebsd.org/bugzilla/>
References:  <bug-239351-227@https.bugs.freebsd.org/bugzilla/>

next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D239351

--- Comment #17 from Evilham <contact@evilham.com> ---
Created attachment 206063
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=3D206063&action=
=3Dedit
D20327_VOP_UNSET_TEXT_spin_lock_held_too_long

Hello, recapitulating:

now I'm running r350327 + D20327 + the VOP_UNSET_TEXT patch in comment 14.
(r350327 already includes the patch in comment 5 that Mark had proposed
earlier).

Commented out the relevant line in /boot/loader.conf and after booting syst=
em
reports:
# sysctl hw.pci.mcfg
hw.pci.mcfg: 1

With this setup I can still use my "WireGuard trick" (50-100 parallel downl=
oads
of big files) to produce the panic, it looks like it's not *just* a duplica=
te
of #231760, at least nothing that would also be solved with D20327.

Notice that compiling world and kernel with all CPUs does not trigger it, s=
till
haven't found a way to make it happen without WireGuard, but it has happene=
d at
some point without it during daily work.

Attached are the public bits of the dump, I'm sending Mark this coredump
privately.

I'll be using this setup without WireGuard daily and see if the problem
triggers during normal usage, with all the kernel compiling these days I
haven't kept it up long enough to test that.

--=20
You are receiving this mail because:
You are the assignee for the bug.=



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-239351-227-hwuC5JlDjC>