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>