From owner-freebsd-stable@FreeBSD.ORG Wed Jun 27 19:11:19 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 925A81065673 for ; Wed, 27 Jun 2012 19:11:19 +0000 (UTC) (envelope-from josh@hewbert.com) Received: from mail.signalboxes.net (hewbert.com [69.164.207.85]) by mx1.freebsd.org (Postfix) with ESMTP id 751CB8FC19 for ; Wed, 27 Jun 2012 19:11:19 +0000 (UTC) Received: from [172.30.119.43] (firewall.dsdk12.net [24.111.1.182]) (Authenticated sender: josh) by mail.signalboxes.net (Postfix) with ESMTPSA id 935286017 for ; Wed, 27 Jun 2012 13:04:26 -0600 (MDT) Message-ID: <4FEB5939.6080704@hewbert.com> Date: Wed, 27 Jun 2012 13:04:25 -0600 From: Josh Beard User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Panic when deleting data on ZFS pool X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2012 19:11:19 -0000 Hello, I have a FreeBSD 9-STABLE box (world built today) that panics whenever I try to delete data using rm on my ZFS pool. This occurred on the same system with a world that was about a month old. Generic kernel and pretty vanilla system. I can consistently reproduce this. I can't see that there's anything "funny" about the data. I run a zpool scrub weekly and it ran two days ago without errors. This issue was present before and after this. Additionally, I haven't seen anything in my logs that indicate failing drives, but I haven't ran a long smartctl test for a while. The system has 16 GB of RAM and I'm not doing anything special for tuning ZFS. The ZFS pool does use compression. I do have crash dumps enabled, if that helps, and would be happy to provide any further detail and information. Redoing the filesystem is an option, as the data is just duplicate backup data and can easily be restored. Any insight on this? I did see a similar posting to -questions from a while ago, but it wasn't conclusive. Thanks, Josh Here's the relevant panic log: Fatal trap 12: page fault while in kernel mode cpuid = 3; apic id = 05 fault virtual address = 0x160 fault code = supervisor read data, page not present instruction pointer = 0x20:0xffffffff816bbbe6 stack pointer = 0x28:0xffffff8465f22870 frame pointer = 0x28:0xffffff8465f22930 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 1646 (rm) trap number = 12 panic: page fault cpuid = 3 KDB: stack backtrace: #0 0xffffffff8091c836 at kdb_backtrace+0x66 #1 0xffffffff808e67ee at panic+0x1ce #2 0xffffffff80bd39c0 at trap_fatal+0x290 #3 0xffffffff80bd3cfd at trap_pfault+0x1ed #4 0xffffffff80bd431e at trap+0x3ce #5 0xffffffff80bbef1f at calltrap+0x8 #6 0xffffffff80c637e4 at VOP_REMOVE_APV+0x34 #7 0xffffffff8098300d at kern_unlinkat+0x32d #8 0xffffffff80bd3270 at amd64_syscall+0x590 #9 0xffffffff80bbf207 at Xfast_syscall+0xf7 Uptime: 4m50s