Date: Sat, 25 Oct 2014 17:06:15 +0000 From: bugzilla-noreply@freebsd.org To: freebsd-bugs@FreeBSD.org Subject: [Bug 194598] New: Deadlock with swap file on nanobsd.sh Message-ID: <bug-194598-8@https.bugs.freebsd.org/bugzilla/>
next in thread | raw e-mail | index | archive | help
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: freebsd-bugs@FreeBSD.org Reporter: holger@freyther.de 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-194598-8>