From owner-freebsd-stable@FreeBSD.ORG Fri Sep 24 12:46:56 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 80A77106566C for ; Fri, 24 Sep 2010 12:46:56 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id C34988FC08 for ; Fri, 24 Sep 2010 12:46:55 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id PAA16691; Fri, 24 Sep 2010 15:46:50 +0300 (EEST) (envelope-from avg@icyb.net.ua) Message-ID: <4C9C9DB9.6060106@icyb.net.ua> Date: Fri, 24 Sep 2010 15:46:49 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.9) Gecko/20100920 Lightning/1.0b2 Thunderbird/3.1.4 MIME-Version: 1.0 To: Jeremy Chadwick References: <20100924123331.GA62762@icarus.home.lan> In-Reply-To: <20100924123331.GA62762@icarus.home.lan> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org, Leroy van Logchem Subject: Re: 8.1-RELEASE: [zfs] [kmem] zfs destroy snapshot results in panic: kmem_map too small 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: Fri, 24 Sep 2010 12:46:56 -0000 on 24/09/2010 15:33 Jeremy Chadwick said the following: > On Fri, Sep 24, 2010 at 01:24:46PM +0200, Leroy van Logchem wrote: >> ----------------------------------------------------------------------------- >> Problem : Kernel panic "kmem_malloc(114688): kmem_map too small >> Trigger : Destroy ZFS snapshots (each bigger >80GB) >> Version : FreeBSD 8.1-RELEASE (GENERIC AMD64 but with DDB) >> ... >> panic: kmem_malloc(114688): kmem_map too small: 3307884544 total allocated >> cpuid = 2 >> KDB: stack backtrace: >> db_trace_self_wrapper() at db_trace_self_wrapper+0x2a >> panic() at panic+0x182 >> kmem_malloc() at kmem_malloc+0x5b5 >> uma_large_malloc() at uma_large_malloc+0x4a >> malloc() at malloc+0x14b >> zio_compress_data() at zio_compress_data+0xa2 >> zio_write_bp_init() at zio_write_bp_init+0xc2 >> zio_exectute() at zio_execute+0x77 >> taskq_run_safe() at taskq_run_safe+0x13 >> taskqueue_run() at taskqueue_run+0x91 >> taskqueue_thread_loop() at taskqueue_thread_loop+0x3f >> fork_exit() at fork_exit+0x12a >> fork_trampoline() at fork_trampoline+0xe >> --- trap 0, rip = 0, rsp = 0xffffff81261edd30, rbp = 0 --- >> panic: kmem_malloc(118784): kmem_map too small: 3307884544 total allocated >> cpuid = 2 > > Can you please provide uname -a output? The built date of your kernel > matters in this case. The panic looks like uma(9) is in use No, it doesn't. -- Andriy Gapon