Re: Current state of the Linux kernel on SPARC
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 <glaubitz@physik.fu-berlin.de> 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
>
Reply to: