On Fri, Jul 07, 2017 at 12:51:05PM +0200, Martin Pieuchot wrote: > On 06/07/17(Thu) 21:18, Juan Francisco Cantero Hurtado wrote: > > On Thu, Jul 06, 2017 at 08:29:39AM -0600, Aaron Bieber wrote: > > > Hola, > > > > > > For roughly a week I have been able to reliably produce panics on > > > amd64 (virtual machine and physical machine) using disk IO heavy > > > applications (gitea, syncthing). > > > > > > Unfortunately on the physical machine - the one I can reliably panic > > > within < 1 minute - I don't have a serial console, so here are links > > > to photos: > > > > > > https://goo.gl/photos/Z8g225UXXpCXQpGcA > > > mirror/google averse: https://deftly.net/panic-2017-07-06/ > > > > > > Also with machdep.forceukbd=1, once I ran `mach ddbcpu 0`, every > > > subsequent key press puked out an "splassert" line, I attempted to run > > > a "trace" again, but things seemed to be completely locked up after that. > > > > I'm seeing the same panic but I can't run ddb. Also with syncthing. > > Here's a fix. The problem certainly comes from a contented NET_LOCK() > which means that we now have a sleeping point where we're not allowed > to sleep. > > Diff below revert the solock()/sounlock() dances in the kqueue filters, > let me know if it works for you. >
Seems to have fixed it for me as well. -- PGP: 0x1F81112D62A9ADCE / 3586 3350 BFEA C101 DB1A 4AF0 1F81 112D 62A9 ADCE
