Just to clarify, I did not say anything negative about systemd or Oracle. In fact, I also worked on systemd source for many years and have noticed issues with various versions (from time to time). I don't mind testing the kernel patch and will focus on creating my build environment. Only mentioned not ruling out systemd because the panic seems to happen shortly after systemd-udev.
I also informed others about the Solaris CBE issue on the S7-2, in an attempt to help get it resolved. Didn’t say anything negative about Oracle. I understand Adrian’s points which are valid (especially regarding the kernel). I also understand some dislike systemd (understandable as well). I am only trying to help resolve these issues, we should all focus on doing that without pointing a finger/judgement (so to speak). Once again, I don't work for Oracle anymore and anything said on my end are my own thoughts and experiencences. Really hoping we can all work together to help get this fixed :-) Best regards, Tony Rodriguez > On Aug 29, 2025, at 5:45 AM, John Paul Adrian Glaubitz > <[email protected]> wrote: > > On Fri, 2025-08-29 at 08:35 -0400, Dennis Clarke wrote: >>> On 8/29/25 03:45, Tony Rodriguez wrote: >>> 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). >>> >> >> I see the word "panic" and then stop. Feels like a real problem in the >> Linux kernel these days for the top of the line SPARC hardware. > > Not really. Just a kernel bug that got introduced in 2017 and didn't see a fix > until since Oracle stopped working on Linux for SPARC in 2017. > >>> 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. >>> >> >> Which may or may not be patched. Furthermore those patches are not in >> the mainline Linux kernel ... or are they ? > > They will be upstreamed soonish. Andreas Larsson (the current kernel > maintainer > for Linux on SPARC) is aware of them. They just need some more testing, > especially > on UltraSPARC I + II, SPARC T1 and SPARC M7/S7/M8. > > Do you happen to have a SPARC T1? > >>> 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. >> >> Right. You have a whole layer of unwanted complexity layered on top of >> this kernel problem. Get away from SystemD entirely. Just use a trivial >> OpenRC or sysvinit type of system. You really need Gentoo here. For any >> trivial testing of a kernel issue it is a disaster to use SystemD. > > systemd isn't the problem, kernel bugs are. You cannot expect anything to work > reliably if the kernel is corrupting more and more memory while the machine > is running. > >>> *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. >>> >> >> Remove SystemD from the equation entirely. > > Please don't turn this into a systemd circlejerk. That discussion is long > settled > and there is no need to open this can of worms again. It's a kernel bug which > is > present no matter what init system you're using, so bashing systemd is just > moot. > >>> >>> 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. >>> >> >> Do not hold your breath for anything to ever be released by Oracle that >> will work on this hardware. There is no business process to justify the >> expense. > > It's hardware that is still officially supported and I'm pretty confident that > the problem has already been fixed in one of the commercial SRUs. The fix will > eventually be released to the CBE version of Solaris. > >>> 8) 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. >>> >> >> Remove that SystemD from the problem. Here we need to create a custom >> Gentoo bootable ( or similar ) trivial ISO with the bare minimum of >> kernel adjustments and modules. Anything else will just be noise on >> top of a very limited signal. > > Non-sense. > > Adrian > > -- > .''`. John Paul Adrian Glaubitz > : :' : Debian Developer > `. `' Physicist > `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 >
