CVS commit: src/sys/arch/sun68k/stand/libsa

Module Name:	src
Committed By:	tsutsui
Date:		Wed Aug 19 18:14:08 UTC 2026

Modified Files:
	src/sys/arch/sun68k/stand/libsa: sun3.c version

Log Message:
sun68k: avoid PROM DVMA map aliasing in sun3 bootloader

NetBSD/sun3 11.0 GENERIC fails to boot from a SCSI disk on
my Sun 3/60 with at least PROM revisions 2.8.3 and 3.0.1.

It looks sun3 PROM SCSI driver allocates internal resources
in DVMA space starting at 0xfff00000. The sun3 standalone
DVMA setup currently aliases its local address range starting
at 0x200000 to that same address.

Since the alias is created by sharing PMEGs, PTE changes made by
the PROM in its DVMA space also change the corresponding standalone
mappings. These mappings are inherited by the loaded kernel.

On Sun3, pmap_bootstrap() derives the first available PA from
(nextva - KERNBASE3), assuming that the kernel bootstrap VA range
is backed by the corresponding contiguous physical addresses.

A leaked alias can instead map part of that range to an unrelated
physical page, leaving that use unaccounted for. Then the page can
be registered as available memory by uvm_page_physload() (via
machine_init_common() in HEAD) even though it is already used for
kernel bootstrap data such as the symbol table and kernel stack etc.
Maybe this is the real reason that also caused PR/54876.

Move the lower end of the standalone alias from 0x200000/0xfff00000
to 0x240000/0xfff40000 to avoid aliasing the PROM DVMA mappings.
Keep the upper limit unchanged, so existing local-to-DVMA address
translations for the remaining range are preserved.

Bump version to denote this fix.

Should be pulled up to netbsd-11 and netbsd-10.


To generate a diff of this commit:
cvs rdiff -u -r1.12 -r1.13 src/sys/arch/sun68k/stand/libsa/sun3.c
cvs rdiff -u -r1.6 -r1.7 src/sys/arch/sun68k/stand/libsa/version

Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.