From owner-freebsd-current@FreeBSD.ORG Wed Aug 6 03:56:38 2014 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A3A2F5D3 for ; Wed, 6 Aug 2014 03:56:38 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 75DE3259E for ; Wed, 6 Aug 2014 03:56:38 +0000 (UTC) Received: from bdrewery (uid 1298) (envelope-from bdrewery@freebsd.org) id d0e by freefall.freebsd.org (DragonFly Mail Agent v0.9+); Wed, 06 Aug 2014 03:56:38 +0000 Received: (qmail 19330 invoked from network); 5 Aug 2014 22:56:33 -0500 Received: from unknown (HELO ?10.10.0.24?) (freebsd@shatow.net@10.10.0.24) by sweb.xzibition.com with ESMTPA; 5 Aug 2014 22:56:33 -0500 Message-ID: <53E1A76A.1070400@FreeBSD.org> Date: Tue, 05 Aug 2014 22:56:26 -0500 From: Bryan Drewery Organization: FreeBSD User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: current@FreeBSD.org Subject: Re: r269147: NULL mp in getnewvnode() via kern_proc_filedesc_out() References: <53E1975D.4010703@FreeBSD.org> <20140806031932.GE93733@kib.kiev.ua> In-Reply-To: <20140806031932.GE93733@kib.kiev.ua> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Aug 2014 03:56:38 -0000 On 8/5/2014 10:19 PM, Konstantin Belousov wrote: > On Tue, Aug 05, 2014 at 09:47:57PM -0500, Bryan Drewery wrote: >> Has anyone else encountered this? Got it while running poudriere. >> >>> NULL mp in getnewvnode() >>> [...] >>> vn_fullpath1() at vn_fullpath1+0x19d/frame 0xfffffe1247d8e540 >>> vn_fullpath() at vn_fullpath+0xc1/frame 0xfffffe1247d8e590 >>> export_fd_to_sb() at export_fd_to_sb+0x489/frame 0xfffffe1247d8e7c0 >>> kern_proc_filedesc_out() at kern_proc_filedesc_out+0x234/frame 0xfffffe1247d8e840 >>> sysctl_kern_proc_filedesc() at sysctl_kern_proc_filedesc+0x84/frame 0xfffffe1247d8e900 >>> sysctl_root_handler_locked() at sysctl_root_handler_locked+0x68/frame 0xfffffe1247d8e940 >>> sysctl_root() at sysctl_root+0x18e/frame 0xfffffe1247d8e990 >>> userland_sysctl() at userland_sysctl+0x192/frame 0xfffffe1247d8ea30 >>> sys___sysctl() at sys___sysctl+0x74/frame 0xfffffe1247d8eae0 >>> amd64_syscall() at amd64_syscall+0x25a/frame 0xfffffe1247d8ebf0 >>> Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfffffe1247d8ebf0 >> >> Unfortunately I have no dump as the kmem was too large compared to my >> swap, and I didn't get to the console before some of the text was >> overwritten. Perhaps it will hit it again soon after reboot and I'll get >> a core. > > "NULL mp in getnewvnode()" is only the printf(), it is not a panic or > KASSERT. The event does not stop the machine, nor it prints the > backtrace. > > You mentioned that you was unable to dump, so did the system paniced ? > Without full log of the panic messages and backtrace, it is impossible > to start guessing what the problem is. > > That said, the printf seemingly outlived its usefulness. > Got it. I've set debug.debugger_on_panic=1 to not auto reboot on panic next time this happens. I had it at 0 which was causing the lack of information in these. Off-topic, this system has 72gb of ram, 16gb swap. I suspect ZFS ARC is typically filling up kmem too much to create a dump. I've limited it to 50gb but am not fond of limiting it, or kmem, to under 16gb. I see that if a page is allocated with VM_ALLOC_NODUMP -> PG_NODUMP then it will be excluded from minidumps. It looks like ZFS allocates all of its kmem via malloc(9) (zfs_kmem_alloc) though which has no means to pass these flags down to the vm system. I am guessing ZFS would need dedicated vm pages for this to even make sense though. I suppose I am stuck in this situation unless I limit kmem or raise my swap size. -- Regards, Bryan Drewery