From owner-freebsd-fs@FreeBSD.ORG Fri Oct 24 13:27:13 2014 Return-Path: Delivered-To: freebsd-fs@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 3FB28DAC; Fri, 24 Oct 2014 13:27:13 +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 F3EE426E; Fri, 24 Oct 2014 13:27:12 +0000 (UTC) Received: from mail (mail [192.168.254.3]) by mail.madpilot.net (Postfix) with ESMTP id 3jPR785M82zb3H; Fri, 24 Oct 2014 15:27:00 +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 gP5xM9MWieP9; Fri, 24 Oct 2014 15:26:45 +0200 (CEST) Received: from marvin.madpilot.net (micro.madpilot.net [88.149.173.206]) by mail.madpilot.net (Postfix) with ESMTPSA; Fri, 24 Oct 2014 15:26:40 +0200 (CEST) Message-ID: <544A538F.6060202@FreeBSD.org> Date: Fri, 24 Oct 2014 15:26:39 +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 FS Subject: panic: detach with active requests on 10.1-RC3 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Cc: Glen Barber X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Oct 2014 13:27:13 -0000 Hi, 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