Regarding my tests:1) Running non-SMP mode with 6.16.3-1 kernel makes no difference (it still panics in the same fashion using nosmp keyword via grub). Confirmed it was truly running in non-smp mode as well with kernel 6.12.38/6.16.3-1 (which cat /proc/cpuinfo shows).
2) Believe the ISO installer is using kernel 6.12.38 during the initial bootup (which at least boots).
Note: After ISO installation, if toggled via grub to use 6.12.38 the s7-2 boots practically every time, but there are still plenty of tainted kernel messages during boot-up.
3) Sometimes 6.16.3-1 will boot successful (still plenty of tainted kernel messages), but is still random/rare regarding successful boots. Typically, only does so when previously booted using a 6.12.38 kernel then rebooted using 6.16.3-1. For kernel 6.16.3-1, often have to select rescue mode or use systemd.unit=multi-user.target via grub as well. As mentioned, it is still random with successful boots with kernel 6.16.3-1, kernel 6.12.38 is better regarding successful booting on the s7-2.
*4) Also, not ruling out a possible systemd issue, noticed systemd-udevd is launched shortly before 6.16.3-1 panic(s). Seems latest Debian 12 for sparc64 is using systemd-258-rc3-1. There certainly may be systemd related bugs as well.
4.1) https://newreleases.io/project/github/systemd/systemd/release/v258-rc3 4.2) Also note: "Migration Blockers in Debian TestingIssue: systemd 258~rc3-1 was blocked from migrating to Debian 13 due to regressions."
*4.3) Do we have older systemd packages (repo) built for Debian 12 sparc64 that I can test with? If so, please provide a link. Would like to see if downgrading systemd will make a difference?
5) Regarding the question: "Thought the current Solaris 11.4 CBE doesn't work on the S7, does it?
I reset the S7-2 LDOM/Service Processor back to factory defaults using ILOM CLI/web and an older Solaris 11.4 (11.4.42.113.1), without using the latest Oracle Solaris CBE (11.4.81) version (since it doesn't work on the S7-2). Hopefully, Oracle will resolve this S7-2 Solaris CBE problem soon in a future update.
6) Debian 12 and s7-2 hanging/panic issue is definitely not due to anything LDOM settings related on my end. Just want to rule that out before attempting to troubleshoot/test Debian 12.
*7) Regarding the following: Thanks, this is good to know."As for Linux, Michael Karcher also actually found a bug in the M7 copy_{to,from}_user code which might cause the crashes on S7, see:"
https://github.com/karcherm/sparc-cfu-bug-reproducer/commit/62d36f0353bd523c143131b99bd9231116c1e0548) Regarding "please test Michael's patch series on your Linux distribution of choice, be it Gentoo or T2DE and report back!".
Understood, want to rule out systemd first and then will try to allocate additional time to research this.
Regards, Tony Rodriguez On 8/27/25 3:13 PM, John Paul Adrian Glaubitz wrote:
Hi Tony, On Wed, 2025-08-27 at 06:29 -0700, Tony Rodriguez wrote:After an initial glance at the Debian S7-2 panic message, I will try resetting my LDOM settings to factory default via Solaris. Then try to boot Debian again. Wondering if something about my LDOM configuration is causing a problem?I don't really know what the reason for the current crashes in Debian are. In particular, the patches by Michael Karcher make the Debian kernel crash on the Sun Netra 240 while a vanilla upstream kernel runs very stable with those patches. This just needs more investigation. I can therefore just repeat my previous request, please test Michael's patch series on your Linux distribution of choice, be it Gentoo or T2DE and report back!FYI, Solaris has no problem with it.I thought the current Solaris 11.4 CBE doesn't work on the S7, does it?If Debian still panics after the LDOM reset then I will try the non-smp kernel as suggested. Will reply and let you know the result.Thanks. I will do some more systematic testing in the next days. There might also be a toolchain bug lingering as the working kernels were built with older GCC versions.PS - Can’t do this today, have other plans, but will do so tomorrow.No worries. Adrian