On 3/3/24 05:30, Steve Wahl wrote:
The machines I work on are large, though. Can you give specifics on exactly how you are performing your kexec, and what hardware you are using when you hit this (especially memory size)? Have you made any special arrangements for the size of memory reserved for kexec on your system?
Hi Steve, I'm using a mainstream Lenovo laptop with an AMD APU (Ryzen 3 5300U), this is my secondary/testing machine using which I've built the kernels and performed the git bisection. I've attached the relevant journal logs and inxi output.
My primary laptop which I'm typing this from is of the same build but with a slightly better APU (Ryzen 5 5500U) in which I have replicated the problem using kernels from OpenSuse repos, both patched and vanilla but not ones I've built myself.
The only peculiarity with these machines I can think of is that its onboard graphics reserves/uses a portion of the normal RAM as its VRAM.
I have reproduced the issue by calling kexec directly using "kexec -l" & "kexec -e", systemctl kexec, and also using the default systemd service/script provided by OpenSuse. The exact command it uses is as follows.
Kexec call: kexec --kexec-syscall-auto --load '/usr/lib/modules/6.7.4-1-default/vmlinuz' --initrd='/boot/initrd-6.7.4-1-default' --append='root=/dev/mapper/suse-system splash=silent mitigations=auto quiet crashkernel=421M,high crashkernel=72M,low security=apparmor'
Note: when I used "kexec -l", I only included the root fs path in append and none of the other options to rule any side effects.
The problem can be reliably reproduced when kexec'ing from the faulty kernel into the same kernel. This why there are two boot entries for each kernel (6.7.7 and 6.7.5) in the attached journal logs.
Let me know if you need any further clarifications.
Kind regards, Pavin Joseph.