Re: Re: Kernel 6.9 fails to boot with "can't boot dump kernel from OF"

> Could you verify that this change actually fixes the problem? This would save me some work.

Verified with PPC qemu. I fail to boot with "You can’t boot a kdump kernel from OF" with CONFIG_CRASH_DUMP on, and I boot fine with it disabled.

Details:

* Tested against the Debian 6.10.4-1 kernel as unpacked with `dget https://deb.debian.org/debian/pool/main/l/linux/linux_6.10.4-1.dsc`

* Built with the GCC 14.2.0 powerpc toolchain from kernel.org

* Using the exact kernel config from a stock sid powerpc system: https://gist.github.com/vasi/be13936e9de9b5a6db8a71897c731aef. Tested building both without any change, and with the change to CONFIG_CRASH_DUMP.

* Built with `PATH=... ARCH=powerpc CROSS_COMPILE=powerpc-linux-gnu- make bindeb-pkg`

* Tested with a Debian sid powerpc VM in qemu 6.2.

Do you need me to try this kernel against real hardware? I can dig an old iBook out of the closet to see if it works.

In terms of where this is coming from, I did some investigation:

* The value of CONFIG_CRASH_DUMP does change from n to y between 6.1 and 6.10. So it is indeed a problem with the config, not the kernel crashing under the same config as before.

* The value of CONFIG_PROC_VMCORE also changes between 6.1 and 6.10, and it depends on CRASH_DUMP. But PROC_VMCORE seems to be enabled in Debian for years, so it's not immediately obvious why it's not in my config: https://salsa.debian.org/kernel-team/linux/-/commit/432666d44950ff603d69537f5ea7c5843fac04d8

* Looking at upstream, CRASH_DUMP changed to `default y` in 6.9! There's our problem: https://github.com/torvalds/linux/commit/75bc255a7444801d64c7a7bd09e3f452f86b3585

* Easiest would be to simply change this downstream in Debian, since Open Firmware is by far the most common way of starting Debian powerpc. I don't know whether upstream should change or not--is there any real constituency that runs PPC Linux without OF, and is also interested in crash dumps? Maybe some embedded folks? Up to you whether you'd like us to try to change this upstream as well, I'm happy to chip in if so.

Hope this helps,

Dave