freebsd stable - Feb 2009 - 7.1-STABLE does not boot after recent superpage support MFC

Is anyone able to boot kernel with recently merged superpage support ?
I have csup'd world to
*default date=2009.02.26.23.59.59
then rebuild world and kernel does not boot:

FreeBSD 7.1-STABLE #4: Fri Feb 27 11:59:13 MSK 2009
    XXXXXXXXXXXXXXXXXXXXX
kernel trap 12 with interrupts disabled


Fatal trap 12: page fault while in kernel mode
cpuid = 0; apic id = 00
fault virtual address   = 0x0
fault code              = supervisor read data, page not present
instruction pointer     = 0x8:0xffffffff803b1d80
stack pointer           = 0x10:0xffffffff80686ce0
frame pointer           = 0x10:0xffffffff80686d00
code segment            = base 0x0, limit 0xfffff, type 0x1b
                        = DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags        = resume, IOPL = 0
current process         = 0 ()
trap number             = 12
panic: page fault
cpuid = 0

And the message is cycled. The kernel does not boot despite
vm.pmap.pg_ps_enabled value.


-- 
Igor Sysoev
http://sysoev.ru/en/

Igor Sysoev wrote:
> Is anyone able to boot kernel with recently merged superpage support ?
> I have csup'd world to
> *default date=2009.02.26.23.59.59
> then rebuild world and kernel does not boot:
>
> FreeBSD 7.1-STABLE #4: Fri Feb 27 11:59:13 MSK 2009
>     XXXXXXXXXXXXXXXXXXXXX
> kernel trap 12 with interrupts disabled
>   
+1. Attempting to set the tunable at boot time doesn't work for me either.

On Friday 27 February 2009 8:08:30 am Igor Sysoev wrote:
> Is anyone able to boot kernel with recently merged superpage support ?
> I have csup'd world to
> *default date=2009.02.26.23.59.59
> then rebuild world and kernel does not boot:
> 
> FreeBSD 7.1-STABLE #4: Fri Feb 27 11:59:13 MSK 2009
>     XXXXXXXXXXXXXXXXXXXXX
> kernel trap 12 with interrupts disabled
> 
> 
> Fatal trap 12: page fault while in kernel mode
> cpuid = 0; apic id = 00
> fault virtual address   = 0x0
> fault code              = supervisor read data, page not present
> instruction pointer     = 0x8:0xffffffff803b1d80
> stack pointer           = 0x10:0xffffffff80686ce0
> frame pointer           = 0x10:0xffffffff80686d00
> code segment            = base 0x0, limit 0xfffff, type 0x1b
>                         = DPL 0, pres 1, long 1, def32 0, gran 1
> processor eflags        = resume, IOPL = 0
> current process         = 0 ()
> trap number             = 12
> panic: page fault
> cpuid = 0
> 
> And the message is cycled. The kernel does not boot despite
> vm.pmap.pg_ps_enabled value.
This should now be fixed, apologies for the breakage. :(

-- 
John Baldwin

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

John Baldwin wrote:
> On Friday 27 February 2009 8:08:30 am Igor Sysoev wrote:
>
>> And the message is cycled. The kernel does not boot despite
>> vm.pmap.pg_ps_enabled value.
> 
> This should now be fixed, apologies for the breakage. :(
What are the benefits and/or impacts of enabling this?

Is there anything to be gained with respect to cache and/or TLB
utilization in allowing entry promotion through a reduced "footprint"
or
similar? How much does this depend on architecture, say, e.g. Core-2 Duo
vs. Pentium?

I note that it is not enabled by default in -current either - just curious,

	Michael



-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (FreeBSD)

iEYEARECAAYFAkmoEuwACgkQQv9rrgRC1JKTcQCfQwKq1MuiwSJcNEaVWsJJZb+D
3oQAoJdM7WxgBi3YOUuV45D72sGcm/YX
=0Osn
-----END PGP SIGNATURE-----

John Baldwin wrote:
> This should now be fixed, apologies for the breakage. :
+1, appears to be fixed. thank you for the prompt fix!

On Friday 27 February 2009 11:21:00 am Michael Butler
wrote:
> John Baldwin wrote:
> > On Friday 27 February 2009 8:08:30 am Igor Sysoev wrote:
> >
> >> And the message is cycled. The kernel does not boot despite
> >> vm.pmap.pg_ps_enabled value.
> >
> > This should now be fixed, apologies for the breakage. :(
> 
> What are the benefits and/or impacts of enabling this?
> 
> Is there anything to be gained with respect to cache and/or TLB
> utilization in allowing entry promotion through a reduced
"footprint" or
> similar? How much does this depend on architecture, say, e.g. Core-2 Duo
> vs. Pentium?
Yes there are gains due to what you mention, but it does depend on the 
specific processor and specifically the how it manages entries for large 
pages in its TLB (some processsors have separate TLB entries for large pages 
and have very few of them, others can store either a small or lage page in a 
single TLB slot, etc.).  Alan knows far more of the details of this than I 
do.
> I note that it is not enabled by default in -current either - just curious,
Actually, it is enabled by default on amd64 in current.

-- 
John Baldwin