Re: kern/46885: NetBSD 6.0_RC1 spontaneously reboots as kernel starts to load

["Valeriy E. Ushakov" <uwe%stderr.spb.ru@localhost>]

The following reply was made to PR kern/46885; it has been noted by GNATS.

From: "Valeriy E. Ushakov" <uwe%stderr.spb.ru@localhost>
To: gnats-bugs%NetBSD.org@localhost
Cc: 
Subject: Re: kern/46885: NetBSD 6.0_RC1 spontaneously reboots as kernel starts 
to load
Date: Mon, 3 Sep 2012 06:56:59 +0400

 On Mon, Sep 03, 2012 at 01:12:55 +0400, Valeriy E. Ushakov wrote:
 
 > On Sun, Sep 02, 2012 at 15:25:02 +0000, Valeriy E. Ushakov wrote:
 > 
 > >  This and port-i386/46061 look (at least at the first glance) similar
 > >  to what I see with VBox.  I have a bit out of date current tree, from
 > >  mid-July or so.  A GENERIC kernel with some more stuff added to it
 > >  (PCIVERBOSE and some more) would not boot, getting stuck in an endless
 > >  trap loop pretty early in uvm init.  Trimming the kernel size a bit
 > >  would make it boot.  Now, this well may be a VBox bug, but I wonder if
 > >  you can try to boot a trimmed kernel config on your machine to see if
 > >  it boots (unfortunately I will only be able to test this myself on
 > >  real hardware in a few days from now).
 > 
 > I did a few more experiments under vbox --recompile-supervisor
 > (i.e. ~= qemu interpreter) and it looks sensitive to size.
 > 
 > Playing with the following config:
 > 
 > 
 >   include     "arch/i386/conf/GENERIC"
 >   options     PCIVERBOSE
 > 
 >   # this line has 64 bytes ######################################
 >   ###############################################################
 >   ###############################################################
 >   ...
 > 
 > I do get bootable kernel without those comment lines added to beef up
 > the kernel size.  With 12KB worth of comments I get unbootable kernel.
 > With 16KB it's bootable again.  Current current will probably have
 > different numbers, but you get the idea.
 
 After poking around with vbox debugger I think I see what the problem
 is, though the exact details are to be worked out by someone with a
 clue.
 
 uvm_page_init calls uvm_pageboot_alloc that calls pmap_growkernel.
 pmap_growkernel rounds up the requested number with x86_round_pdr,
 arranges for pmap to have necessary PTP pages and returns the rounded
 number that uvm_pageboot_alloc assigns to uvm_maxkaddr.
 
 What i think happens is that uvm_page_init miscalculates its argument
 to uvm_pageboot_alloc, asking for slighly less memory.  The problem
 happens when requested (wrong) number is just below 4MB boundary.
 
 If we ask pmap_growkernel e.g. for 0xc1401000, it will round it up to
 0xc1800000, so when later we come asking for a page at, say,
 0xc1402000, everything is ok.  But if the kernel size is just right,
 we will ask pmap_growkernel for exactly 0xc1400000.  Later we will
 come asking for a page at 0xc1401000 and we don't have a PTP that maps
 [0xc14000000, 0xc1800000) range in the pmap.
 
 To trigger this bug your kernel has to be just the right size.  To try
 to reproduce this problem, check the value passed to pmap_growkernel
 from uvm_pageboot_alloc.  If necessary, trim your kernel to have a
 number just below 0xc1400000 (or 0xc1800000, etc).  Pad the kernel
 with an array (for small padding you can add to your config as I
 mentioned in previous comment).
 
 -uwe