huge ktr buffer

[Davide Italiano]

On Thu, Dec 6, 2012 at 4:18 PM, Andriy Gapon <avg at 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 at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe at 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