From owner-freebsd-hackers@FreeBSD.ORG Thu Dec 6 15:43:39 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8126C1E9; Thu, 6 Dec 2012 15:43:39 +0000 (UTC) (envelope-from davide.italiano@gmail.com) Received: from mail-vb0-f45.google.com (mail-vb0-f45.google.com [209.85.212.45]) by mx1.freebsd.org (Postfix) with ESMTP id 0DE288FC08; Thu, 6 Dec 2012 15:43:38 +0000 (UTC) Received: by mail-vb0-f45.google.com with SMTP id p1so6579483vbi.18 for ; Thu, 06 Dec 2012 07:43:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=r2AlEqiEgz/EZUmxzFTzh9MW8dPGwk5ABCSWKcNYI4g=; b=Q7ChwIlm7Si8WudTTxf+iepJ0uUA54ICPMK2jZ5WUgUk9GS+XifainE6hcEwhu581a rHSAducgqcebB6dMP38tqjUhvCgth5Z+ZRfoLxx0FcNVWuFIMDP2uoh5JNutSO+AIPUo couyb9J5zn8YiwDUI8fRjuAv/2QaXg0YMf9opcJtOhKvxOYzDdAPjbXlvhXCZenmUBah 69cxKmlJCsZCCNyFLtmPj7T6J7RQoAuPR+tPKAlc0tAsAwY6TB0HG4ZU28VtO/9/z/gD EivLpIM9IzkeJc2Crwl6WTV8umaTfwEYLDYgHKxUKfSz7JLx6Wojh8JDpXDLz3G0u3/z zARQ== MIME-Version: 1.0 Received: by 10.52.27.138 with SMTP id t10mr1227299vdg.81.1354808618362; Thu, 06 Dec 2012 07:43:38 -0800 (PST) Sender: davide.italiano@gmail.com Received: by 10.58.245.130 with HTTP; Thu, 6 Dec 2012 07:43:38 -0800 (PST) In-Reply-To: <50C0B763.8000004@FreeBSD.org> References: <50C0B763.8000004@FreeBSD.org> Date: Thu, 6 Dec 2012 16:43:38 +0100 X-Google-Sender-Auth: Y1auB49ZZ8ANa9HiOvQIzllNogI Message-ID: Subject: Re: huge ktr buffer From: Davide Italiano To: Andriy Gapon Content-Type: text/plain; charset=ISO-8859-1 Cc: alc@freebsd.org, FreeBSD Hackers X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Dec 2012 15:43:39 -0000 On Thu, Dec 6, 2012 at 4:18 PM, Andriy Gapon wrote: > > So I configured a kernel with the following option: > options KTR_ENTRIES="(1024UL*1024)" > then booted the kernel and did > $ sysctl debug.ktr.clear=1 > and got an insta-reboot. > > No panic, nothing, just a reset. > > I suspect that the huge static buffer resulting from the above option could be a > cause. But I would like to understand the details, if possible. > > Also, perhaps ktr could be a little bit more sophisticated with its buffer than > just using a static array. > > -- > Andriy Gapon > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" It was a while ago, but running r238886 built using the following kernel configuration file: http://people.freebsd.org/~davide/DEBUG I found a similar issue. The machine paniced: fatal trap 12 with interrupt disable in early boot (even before the appareance of the Berkley logo). Basically, my configuration file is just GENERIC with slight modifications, in particular debugging options (WITNESS, INVARIANTS, etc..) turned on and the following KTR options enabled: options KTR options KTR_COMPILE=(KTR_CALLOUT|KTR_PROC) options KTR_MASK=(KTR_CALLOUT|KTR_PROC) options KTR_ENTRIES=524288 It seems the issue is related to KTR itself, and in particular to the value of KTR_ENTRIES. As long as this value is little (e.g. 2048) everything works fine and the boot sequence ends. If I choose 524288 (the value you can also see from the kernel conf file) the fatal trap occurs. Even though it was really difficult to me to get some informations because the fail happens too early, I put some printf() within the code and I isolated the point in which the kernel dies: (sys/amd64/amd64/machdep.c, in getmemsize()) 1540 /* 1541 * map page into kernel: valid, read/write,non-cacheable 1542 */ 1543 *pte = pa | PG_V | PG_RW | PG_N; As also Alan suggested, a way to workaround the problem is to increase NKPT value (e.g. from 32 to 64). Obviously, this is not a proper fix. For a proper fix the kernel needs to be able to dynamically set the size of NKPT. In this particular case, this wouldn't be too hard, but there is a different case, where people preload a large memory disk image at boot time that isn't so easy to fix. Thanks, Davide