Changes to major headers should be temporarily suspended until this problem is resolved, because I have observed that even

make quickworld

can fail to complete without lockup. Someone using UFS as their filesystem may experience quite substantial filesystem corruption after a lockup. By limiting changes to major headers, this gives the greatest chance of a successful make quickworld when this problem is finally resolved.

History

Hmm. The 5d920ec commit fixed the issues on the three build machines we've tested on (4-core/8-thread pkgbox64, 16-core/32-thread 2xXeon box, and the 4-socket 48-core opteron box). If you are still getting lockups I need your machine configuration to try to reproduce it. cpu's cores/threads, amount of memory, configured swap if any, and filesystems being used (UFS?).

Also, are you running the build from a console or from X? If from X, try running from a console and see if it still reproduces (that will tell us whether there's an X interaction or not). And see if you can break into the debugger when it locks up and get a kernel dump.

If you are running on UFS, the only thing I see is the possibility that it is related to vfs.ffs.ffsrawbufcnt. Try disabling the use of raw buffers with a sysctl vfs.ffs.allowrawread=0 and sysctl vfs.ffs.rawreadahead=0 and see if the lockup still occurs.

I previously was able to reproduce lockups with hammer2 by transferring large (1G, 4G) to filesystem fairly reliably in 5 minutes or so. After last patch I was able at least once transfer files completely. After transferring files I tried to remove them thus causing a core: