DragonFlyBSD

Is that master or release? Can you try with latest code?

This should be fixed by c5030460c6 in master.

Oops, I gave swildner bad info. It isn't fixed in c503.

Make sure that machdep.pmap_mmu_optimize is turned off (it should be off by default). We've gotten sporatic reports of this particular panic and have not yet tracked down the reason for it. Nobody can reproduce it reliably which makes tracking the problem down difficult. So if you can find a reproduction case for it, we definitely want to know!

(Also tell as per swildner's first comment whether you are doing this on master or release).

-Matt

I'm on master. Hadn't faced that one another time.

machdep.pmap_mmu_optimize: 0

I just remember the system was extra slow (probably due to hammer2 and low space situation) and that I was overusing swap a lot. Will try to reproduce.

No more cores so far. I think I found a possible trigger for it but that's a sad story. I'm an Enlightement user and I'm still using it (despite it had been removed from dports). When everything starts failing last time I traced that down to /usr/local/lib/ecore/system/upower/v-1.18/module.so. When that file was present Terminology was crashing on start almost each time (except when started before E17, still crashing but not that fast). And a core was happening when I was switching to another window. Since E17 is modular the only thing I had to do is to remove the file and everything was magically fixed!

Happened again a few times when trying to build ports, probably during package compression. Dump was too huge to fit into the swap partition. Would try a few more times - this time it's surely not bound to hammer2.

I tried removing all tmpfs usage from my host and it looks like that helped. System is not crashing or hanging any more, one week without reboot is normal. Getting tmpfs back make system unstable under huge loads, when I'm trying to push something huge there.