On Wed, 31 Dec 2025, Rob Landley wrote:
On 12/31/25 01:32, Rob Landley wrote:
I fixed it up by hand for testing in the meantime, and it loaded the kernel
with -m 192 but then initramfs couldn't find init. Without the patch series
the same git version (942b0d378a1d) booted to a shell prompt. I can try to
track down what happened in the morning...
Ah, it boots with the full patch stack applied for -m 64 but not -m 128. It's
mapping in the extra memory that breaks it.
The initramfs doesn't seem to be extracting with the second memory block
enabled? What's the diff in the output...
--- out.txt 2025-12-31 01:42:33.487421358 -0600
+++ out2.txt 2025-12-31 01:42:47.359676340 -0600
@@ -105,7 +105,6 @@
NET: Registered PF_UNIX/PF_LOCAL protocol family
PCI: CLS 0 bytes, default 32
Unpacking initramfs...
-Freeing initrd memory: 528K
workingset: timestamp_bits=30 max_order=14 bucket_order=0
squashfs: version 4.0 (2009/01/31) Phillip Lougher
SuperH (H)SCI(F) driver initialized
@@ -121,50 +120,14 @@
Segment Routing with IPv6
In-situ OAM (IOAM) with IPv6
NET: Registered PF_PACKET protocol family
+Freeing initrd memory: 528K
netconsole: network logging started
-check access for rdinit=/init failed: -2, ignoring
-/dev/root: Can't open blockdev
-VFS: Cannot open root device "" or unknown-block(1,0): error -6
... [filesystem list and panic dump elided]
- [<8c3d0e24>] kernel_init+0x0/0x104
-
-Rebooting in 1 seconds..
+devtmpfs: mounted
+Freeing unused kernel image (initmem) memory: 132K
+This architecture does not have kernel memory protection.
+Run /init as init process
+8139cp 0000:00:02.0 eth0: link up, 100Mbps, full-duplex, lpa 0x05E1
+ESC[?7hType exit when done.
+$ exit
+reboot: Restarting system
Why on earth did the "freeing initrd memory" move? (Interrupts shouldn't be
enabled until right before it spawns PID 1, unless they rewrote that part
when I wasn't looking...)
Ah, the - is the fail and the + is the success, I'm guessing the extract
failed and the error path freed it early. Possibly the new memory block is
either overwriting the cpio.gz or changing where it lives in a way the kernel
isn't finding it.
I don't know anything about this but have you tried comparing 'info mtree'
output from QEMU Monitor to see what changed? That may show if some memory
block moved or overlaps something now.
Anyway, you've got the tarball if you want to smoketest it yourself. Unless
this is expected and we need kernel tweaks just to boot even when not using
the new memory, in which case -m 256 warning and dropping down to 192 would
_still_ lose backwards compatibility. (If there's an address range conflict,
could the -initrd loaded contents be IN the new memory block, as if it had
been loaded rather than a mapped in ROM?)
The SH in QEMU is not much maintained and maybe there aren't many people
to look at it so don't expect much help with it.
Regards,
BALATON Zoltan
