https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194598
Bug ID: 194598
Summary: Deadlock with swap file on nanobsd.sh
Product: Base System
Version: 10.0-STABLE
Hardware: Any
OS: Any
Status: Needs Triage
Severity: Affects Only Me
Priority: ---
Component: kern
Assignee: [email protected]
Reporter: [email protected]
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.
--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "[email protected]"
