Date: Tue, 08 Dec 2015 09:46:22 +0000 From: bugzilla-noreply@freebsd.org To: freebsd-threads@FreeBSD.org Subject: [Bug 200992] proccess won't die in thread_suspend_switch Message-ID: <bug-200992-16-WgR8bEQnLv@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-200992-16@https.bugs.freebsd.org/bugzilla/> References: <bug-200992-16@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=200992 --- Comment #24 from johans <johan@300.nl> --- I'm suspecting that the patch (patch 1) attached here doesn't fully fix the problem, but only greatly reduces when it happens. I've encountered two issues since yesterday on different machines: (1) This one is pretty straightforward related: I've had one puppet process get stuck in STOP state, unfortunately my colleague didn't to a procstat to see the exact trace but rather rebooted the machine. (2) This one I'm unsure: I'm now debugging a hang in unmount which traces to a wait in zfs: dp->dp_spaceavail_cv Running dtrace on txg group syncing shows that there is no dirty data left, or at least that it's below the max. 2015 Dec 8 10:39:21 : 0KB of 8MB used 2015 Dec 8 10:39:26 : 0KB of 8MB used 2015 Dec 8 10:39:31 : 0KB of 8MB used Wake-up should be done by 'dsl_pool_dirty_delta': if (dp->dp_dirty_total <= zfs_dirty_data_max) cv_signal(&dp->dp_spaceavail_cv); This condition has been clearly met. Having this bug in the back of my head it seemed this might be related. -- 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-200992-16-WgR8bEQnLv>