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.
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?)
Thanks,
Rob
