From owner-freebsd-bugs@FreeBSD.ORG Sat Oct 25 17:06:15 2014 Return-Path: Delivered-To: freebsd-bugs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D3F772CA for ; Sat, 25 Oct 2014 17:06:15 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A15E2E84 for ; Sat, 25 Oct 2014 17:06:15 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id s9PH6F3h003500 for ; Sat, 25 Oct 2014 17:06:15 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-bugs@FreeBSD.org Subject: [Bug 194598] New: Deadlock with swap file on nanobsd.sh Date: Sat, 25 Oct 2014 17:06:15 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.0-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: holger@freyther.de X-Bugzilla-Status: Needs Triage X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-bugs@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version rep_platform op_sys bug_status bug_severity priority component assigned_to reporter Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Oct 2014 17:06:15 -0000 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.