Date: Thu, 6 Dec 2012 16:43:38 +0100 From: Davide Italiano <davide@freebsd.org> To: Andriy Gapon <avg@freebsd.org> Cc: alc@freebsd.org, FreeBSD Hackers <freebsd-hackers@freebsd.org> Subject: Re: huge ktr buffer Message-ID: <CACYV=-HhQcPx4nM=Ytc3wKS-oZqvtZCquJZSL6BooDHvRpuvGA@mail.gmail.com> In-Reply-To: <50C0B763.8000004@FreeBSD.org> References: <50C0B763.8000004@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Dec 6, 2012 at 4:18 PM, Andriy Gapon <avg@freebsd.org> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CACYV=-HhQcPx4nM=Ytc3wKS-oZqvtZCquJZSL6BooDHvRpuvGA>