DragonFlyBSD

Did it get to the 'CAM: Configuring N busses' and 'CAM: finished configuring all busses' before hanging? If not then it will stop there waiting for CAM to finish configuring.

There is a possible deadlock somewhere in CAM from changes made in Feb to fix some other holes in CAM's locking. The fact that a verbose boot worked makes that all the more likely to be the issue. Kind of a chicken and egg issue. What I really need is a backtrace of the offending kernel threads but that might be difficult at that point in the boot. you might be able to ctl-alt-esc into the debugger, but it would take some messing around to get a decent trace of the offending threads (basically you have to find the stack addresses which is typically listed in the thread list and x/a <addr> then hit return a ton of times to dump the stack for each thread). I don't know if the symbol table will be available at that point in the boot sequence.

-Matt

Apologies, it now seems to me that the problem for my machine may be
with:

commit f240042b9f9bcfdacd70499659fcc5f55d5e49ab
Date: Sun Mar 26 23:35:55 2017 -0700

kernel - Spread IPIs out to more priority levels

Could you re-test with and without that commit? Be sure to do a full kernel rebuild for that one (world rebuild not necessary). If that is breaking you then I missed something in that commit and I will back it out.

-Matt