./qemu-system-sparc64 -M niagara -L /git/md/bin/tlb_fix/2048 -nographic -m 2048 -drive if=pflash,readonly=on,file=/zroot/iso/sol-11-exp-201011-ai-sparc.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, 0x10dc5ff] data at 0x1800000
module /platform/sun4v/kernel/sparcv9/genunix: text at [0x10dc600, 0x12e79f7] data at 0x1937440
module /platform/sun4v/kernel/misc/sparcv9/platmod: text at [0x12e79f8, 0x12e79ff] data at 0x198dcf0
module /platform/sun4v/kernel/cpu/sparcv9/SUNW,UltraSPARC-T1: text at [0x12e7a00, 0x12ebb7f] data at 0x198e3c0
Loading kmdb...
module /platform/sun4v/kernel/misc/sparcv9/kmdbmod: text at [0x12ebb80, 0x1368657] data at 0x19a4f50
module /kernel/misc/sparcv9/ctf: text at [0x1368658, 0x137003f] data at 0x19c2860
\
Welcome to kmdb
kmdb: unable to determine terminal type: assuming `vt100'
Loaded modules: [ unix krtld genunix ]
[0]> :c
(hard hang; no further console output. Broke in via serial break
(Ctrl-A b in the QEMU -nographic console) instead of just recording a
black-box hang.)
kmdb: single-step stop on miscellaneous trap
kmdb: target stopped at:
alloc_page_freelists+0x54:      stx       %i0, [%l6 + %l7]
[0]> :c
(continued past the break point; hang resumed as before with no
further output)

CONFIRMED (via serial-break): stuck inside alloc_page_freelists, exact
same offset (+0x54) and same stuck store instruction as
tlb_fix-2048__snv_134-ai-iso.txt. This is now the THIRD OS image
(alongside Solaris 10u10 at +0x44 and snv_134 ai ISO at +0x54) found
stuck in this same function on tlb_fix/2048 -- strong confirmation this
is a systemic bug in this build tied to the 2048M memory size, not
anything specific to a particular guest OS. Supersedes the earlier
"retested twice, 30min/20min wait, not related to the memsize bug" note
on this file -- that conclusion predates this trace and needs
revisiting; the hang itself may well be memsize-related after all, even
if the earlier blind waits didn't reveal that.