From owner-freebsd-stable@FreeBSD.ORG Fri Oct 24 16:10:24 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 69289365 for ; Fri, 24 Oct 2014 16:10:24 +0000 (UTC) Received: from mail.madpilot.net (grunt.madpilot.net [78.47.145.38]) (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 2876F926 for ; Fri, 24 Oct 2014 16:10:23 +0000 (UTC) Received: from mail (mail [192.168.254.3]) by mail.madpilot.net (Postfix) with ESMTP id 3jPVlP4dBMzb37 for ; Fri, 24 Oct 2014 18:10:09 +0200 (CEST) Received: from mail.madpilot.net ([192.168.254.3]) by mail (mail.madpilot.net [192.168.254.3]) (amavisd-new, port 10024) with ESMTP id fUzlWvftRzoM for ; Fri, 24 Oct 2014 18:09:59 +0200 (CEST) Received: from marvin.madpilot.net (micro.madpilot.net [88.149.173.206]) by mail.madpilot.net (Postfix) with ESMTPSA for ; Fri, 24 Oct 2014 18:09:54 +0200 (CEST) Message-ID: <544A79D1.3090909@FreeBSD.org> Date: Fri, 24 Oct 2014 18:09:53 +0200 From: Guido Falsi User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Subject: panic: detach with active requests on 10.1-RC3 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Oct 2014 16:10:24 -0000 Hi, I already sent this to freebsd-fs@. I'm making some experiments with 10.1-RC3 on alix boards as hardware using NanoBSD. By mounting and umounting UFS filesystems I have seen umount constantly hanging hard in a deadlock. I have tested on two boards with two distinct compactflash disks with same results. This was not happening with 10.0-RELEASE. I have build a 10.1-RC3 kernel with full debugging and caused the problem to happen, I got this: root@qtest:~ [0]# umount /cfg panic: detach with active requests KDB: stack backtrace: db_trace_self_wrapper(c0968053,c08ea7f0,c2d48800,c23d6bc8,c0536a16,...) at db_trace_self_wrapper+0x2d/frame 0xc23d6b98 kdb_backtrace(c09639e1,c09fa7e8,c095761d,c23d6c54,c095761d,...) at kdb_backtrace+0x30/frame 0xc23d6c00 vpanic(c09fa682,100,c095761d,c23d6c54,c23d6c54,...) at vpanic+0x80/frame 0xc23d6c24 kassert_panic(c095761d,c09575b3,c2d7acc0,4c7,c2d7acc0,...) at kassert_panic+0xe9/frame 0xc23d6c48 g_detach(c2d7acc0,4,c095725c,1c2,c09c8d5c,...) at g_detach+0x1d3/frame 0xc23d6c64 g_wither_washer(c09f7df4,0,c0956544,124,0,...) at g_wither_washer+0x109/frame 0xc23d6c90 g_run_events(0,c23d6d08,c095d42a,3dc,0,...) at g_run_events+0x40/frame 0xc23d6ccc fork_exit(c05c4e60,0,c23d6d08) at fork_exit+0x7f/frame 0xc23d6cf4 fork_trampoline() at fork_trampoline+0x8/frame 0xc23d6cf4 --- trap 0, eip = 0, esp = 0xc23d6d40, ebp = 0 --- KDB: enter: panic [ thread pid 12 tid 100006 ] Stopped at kdb_enter+0x3d: movl $0,kdb_why db> The machine is sitting there, I am connected with serial console, anyone willing to help me debug this further? I really know very little about kernel debugging. If necessary I can also make myself available via IRC or Jabber. It looks like this has some similarities with what was reported here: https://lists.freebsd.org/pipermail/freebsd-fs/2014-September/020035.html I also tested with head (including r272130) and it does deadlock the same. Maybe the slower media is exposing some problem which does not show up with faster disks? Thanks in advance! -- Guido Falsi