While using nanobsd.sh and swap based md the kernel deadlocks. In my case I have a VM with just 2GB of RAM and then added a swap file by making an entry in fstab as of the FreeBSD handbook. When the swap file starts being used the system deadlocks. No new applications can be started, console switching and ddb is still working fine.

Re-produce:

0.) Have kernel with DDB and enable break with CTRL+ALT+ESC
1.) Create VM with 2GB of RAM
2.) add "md99	none	swap	sw,file=/usr/swap0	0	0"
3.) cd /usr/src/tools/tools/nanobsd/pcengines
4.) ./build.sh alix_dsk.conf
... wait
5.) until the disk image is being created.


What happens:

* the "dd" process seems to continue to exist.
* "show alllocks" shows (access is through vnc so manual copy and paste by me)
Process 27312 (dd) ...
exclusive lockmgr bufwait (bufwait) r = 0 (0xff...2e8) locked @ vm_pager.c:308
Process 725 (md99)
exclusive lockmgr bufwait (bufwait) r = 0 (0xff..68) locked @ vfs_bio.c:2325
exclusive lockmgr bufwait (bufwait) r = 0 (0xff..08) locked @ vfs_bio.c:2325
exclusive lockmgr ufs (ufs) r= 0 (0xff..98) locked @ md.c:783
exclusive lockmgr bufwait (bufwait) r = 0 (0xff..4e8) locked @ vm_pager.c:308
Process 7 (bufdaemon)
exclusive lockmgr bufwait (bufwait) r = 0 (0xff..48) locked @ vfs_bio.c:2325
Process 12 (intr)..
Giant lock.. probably due using DDB..

tr 725
goes to sched_switch and sleeps there.. from vm_wait/vm_page_grab/allocbuf/getblk/ufs_bmaparray/ufs_strategy../VOP_WRITE_APV

tr 27312
.. sched_switch from bwait/physio/devfs_read_f/dofileread/kern_readv/sys_readv


tr 100077
sched_switch ... vm_wait/allocbuf/getblk/softdep_process_journal/softdep_process_worklist..


Given my limited knowledge it might not be a deadlock but somehow the "waiting" never stops. So the "md99" sleeping in vm_wait is certainly bad as no free pages will become available until something is written to md99.