./qemu-system-sparc64 -M niagara -L /git/md/bin/tlb_fix/2048 -nographic -m 2048 -drive if=pflash,readonly=on,file=/zroot/iso/sol-10-u10-ga2-sparc-dvd.iso
cpu Probing I/O buses


Sun Fire T2000, No Keyboard
Copyright 2005 Sun Microsystems, Inc.  All rights reserved.
OpenBoot 4.20.0, 2048 MB memory available, Serial #1122867.
[mo23723 obp4.20.0 #0]
Ethernet address 0:80:3:de:ad:3, Host ID: 80112233.



ok boot -kdv
Boot device: /virtual-devices/disk@0  File and args: -kdv
hsfs-file-system
Loading: /platform/sun4v/boot_archive
ramdisk-root ufs-file-system
Loading: /platform/sun4v/kernel/sparcv9/unix
module /platform/sun4v/kernel/sparcv9/unix: text at [0x1000000, 0x10c1c1d] data at 0x1800000
module /platform/sun4v/kernel/sparcv9/genunix: text at [0x10c1c20, 0x12a6b77] data at 0x1935f40
module /platform/sun4v/kernel/misc/sparcv9/platmod: text at [0x12a6b78, 0x12a6b8f] data at 0x198d598
module /platform/sun4v/kernel/cpu/sparcv9/SUNW,UltraSPARC-T1: text at [0x12a6ba0, 0x12aad2f] data at 0x198dd00
Loading kmdb...
module /platform/sun4v/kernel/misc/sparcv9/kmdbmod: text at [0x12aad80, 0x131a397] data at 0x19a4f50
module /kernel/misc/sparcv9/ctf: text at [0x131a398, 0x13221f7] data at 0x19c9558

Welcome to kmdb
kmdb: unable to determine terminal type: assuming `vt100'
[0]> :c
(hard hang; no further console output. Broke in via serial break
(Ctrl-A b in the QEMU -nographic console) to confirm live rather than
just recording a black-box hang.)
kmdb: 1 dmod load/unload pending
kmdb: single-step stop on miscellaneous trap
kmdb: target stopped at:
alloc_page_freelists+0x44:      stx       %i0, [%g3 + %l7]
[0]> :c
(broke in a second time to confirm -- landed at the EXACT SAME
instruction again, strong evidence this is a genuine stuck loop at
this precise point, not a random freeze)
kmdb: 1 dmod load/unload pending
kmdb: single-step stop on miscellaneous trap
kmdb: target stopped at:
alloc_page_freelists+0x44:      stx       %i0, [%g3 + %l7]
[0]> $c
alloc_page_freelists+0x44(70002c3f488, 18ab800, 0, 0, 0, 18a9558)
startup_memlist+0x6a0(1914800, 7000243f480, 3f, 1930400, 18ef400, 40)
startup+0x20(2, 1, 1, 1, 1070000, 1042800)
main+0x1c(0, 180c000, 18a6840, 10b9400, 1846050, 1999000)
_start+0x100(0, 0, 0, 0, 0, 0)
[0]>

CONFIRMED (via serial-break + $c, not just a placeholder "hang" note):
stuck inside alloc_page_freelists, called from startup_memlist during
very early kernel bootstrap (physical memory free-list construction,
well before device attach or anything we traced in the sfmmu_cpu_init/
bop_alloc_chunk investigations). Two independent breaks landed at the
identical PC, ruling out a random freeze. Given this only reproduces
at 2048M (not seen on tlb_fix/1024), this is plausibly the same class
of memory-size-sensitivity as the Solaris 10u11 regression and the
Solaris 10u8/11-11/11-text failure-mode changes recorded elsewhere on
this build -- worth full kmdb tracing (::dis on alloc_page_freelists,
same methodology as sfmmu_cpu_init/bop_alloc_chunk) to find the actual
root cause.