From owner-freebsd-current@FreeBSD.ORG Sun Apr 21 11:54:32 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id A8793982 for ; Sun, 21 Apr 2013 11:54:32 +0000 (UTC) (envelope-from ganbold@gmail.com) Received: from mail-ie0-x234.google.com (mail-ie0-x234.google.com [IPv6:2607:f8b0:4001:c03::234]) by mx1.freebsd.org (Postfix) with ESMTP id 7D30310A7 for ; Sun, 21 Apr 2013 11:54:32 +0000 (UTC) Received: by mail-ie0-f180.google.com with SMTP id to1so1455210ieb.39 for ; Sun, 21 Apr 2013 04:54:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=dPqVPexSxdMw6q3ENxdaTgUmC2jngpbsWV15QpsQpgY=; b=V0CvfRdnvO9aKW+2frGXlCvbHWmrL22pt0kZuKfichAa0FziWW9+itUdOpGQKWdsnd LNFb7e1TAozd3d+5I3P1WXyVDGWFxwR65vh4tkmL1Xcn+8PqrBjVoWh7+K/Q6cKTJ6tX mI0Gtrvsyi3X0u6sucOk8WAfMFgA44ezxOi9Hi4UuA4nj/3QPN9rctuodilJh+3ZBoCe 5H6yqisjfm+3cQ1tkStOqqNBIum6ZnUTvakhoFvU/M15doMVynVEruHhhXyzIqz7St/X +7AsXfq2HS9UdylrSeFR9d85bu8ke7124bnWcg+Lgzdu++zW1AoVu06Du0i1Yk0CmigQ cQnA== MIME-Version: 1.0 X-Received: by 10.50.127.242 with SMTP id nj18mr274366igb.47.1366545271524; Sun, 21 Apr 2013 04:54:31 -0700 (PDT) Received: by 10.64.23.167 with HTTP; Sun, 21 Apr 2013 04:54:31 -0700 (PDT) In-Reply-To: <20130421112749.GF67273@kib.kiev.ua> References: <20130420152102.GC67273@kib.kiev.ua> <20130421112749.GF67273@kib.kiev.ua> Date: Sun, 21 Apr 2013 19:54:31 +0800 Message-ID: Subject: Re: panic when booting HEAD on i386 From: Ganbold Tsagaankhuu To: Konstantin Belousov Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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: Sun, 21 Apr 2013 11:54:32 -0000 On Sun, Apr 21, 2013 at 7:27 PM, Konstantin Belousov wrote: > On Sun, Apr 21, 2013 at 01:57:03PM +0800, Ganbold Tsagaankhuu wrote: > > On Sat, Apr 20, 2013 at 11:21 PM, Konstantin Belousov > > wrote: > > > > > On Sat, Apr 20, 2013 at 10:52:35PM +0800, Ganbold Tsagaankhuu wrote: > > > > Hi, > > > > > > > > I'm trying to boot HEAD after updating, but unfortunately it panics > with > > > > following message: > > > > > > > > panic: kmem_suballoc: bad status return of 3. > > > > > > > > I was only able to get image of the panic. > > > > > > > > http://www.mnbsd.org/ganbold/IMG_20130420_222353-2.jpg > > > > > > > > Does anybody see same panic booting on i386 lately? > > > > Tried clang, and it panics also. > > > > > > How much memory do you have ? > > > Do you have any tunables in the loader.conf ? > > > > > > > Following settings caused the panic: > > > > vm.kmem_size="999M" > > vm.kmem_size_max="999M" > I cannot imagine how this could work earlier as well, except by chance. > Right, probably by chance it didn't cause panic in previous version. > > > > > Whether it is regression or not in previous version of kernel (r244046) > it > > didn't panic on boot. > > Seems no information on UPDATING either. > Do you propose to enumerate all non-working or panic-provoking settings in > loader.conf ? > Not really. > > Why did you set this value at all ? > These are the settings that I did for zfs, since my machine has zfs and probably it is not even worth to run zfs on 2GB system. It is my fault. > > KVA on i386 is limited to slightly less then 1GB, where all the kernel > maps must be instantiated. Kernel uses the value of the tunable > vm.kmem_size literally, except it makes a mild attempt to prevent > foot-shooting by capping kmem_size to 2 * physical memory size. > > You neglected to answer how much memory is installed on your machine, > As mentioned in one of my previous email I have 2GB machine which is probably not worth to have zfs on such system. Sorry for the noise. thanks, Ganbold > but I suspect you have enough so that overblown kmem_map cannot coexists > with other kernel VA consumers. >