Re: [PATCH v2] sparc64: increase kernel thread stack size to 32K

[Tony Rodriguez]

Thanks again for the details, but I already had those CONFIG and 
stacktrace options defined based on previous debugging sessions.

32K should be fine based on the output (see the link below), and I have 
not noticed any crashes with a 32K stack).  These results are against 
kernel v7.1.0-rc3 using my original patches on the S7-2.

https://github.com/unixpro1970/Sparc64-Kernel-Debugging-Dumps/blob/main/kernel-v7.1.0-rc3-depth-stack-trace-sparc64-s7-2.txt


Should I try your revised 32k stack and timer patches on the S7-2 and 
T7-1?  If so, which kernel version did you validate against 7.2 or 7.3?


Regards,

Tony

On 8/31/26 2:05 PM, Stian Halseth wrote:
> Hi Tony,
>
> On Mon, 2026-08-31 at 13:18 -0700, Tony Rodriguez wrote:
> > Hi Stian,
> >
> > Just please continue to give me a
> > mention in any patches related to this work, since I spent a
> > considerable amount of time debugging, researching, and validating
> > the fixes.
> Sure. For now, no real changes have been made to your patches, so as
> far as I'm concerned, this is entirely your work.
> Will try help with the last mile, alongside some other patches I've
> submitted.
> And yes, the debugging, researching and validation is the hard part.
> Writing a fix is often _relatively_ easy, when you have all the facts.
> > When I last tested on 7.0 and 7.1, both of my patches worked:
> >
> > A)    sparc64: increase kernel thread stack size to 32K
> >
> > B)    sparc64: Fix comparator problem with timer interrupts
> >
> > I was able to debug and validate these issues on S7‑2 and T7‑1
> > hardware.
> Yes, and that's a very important data point. My analyzis is based on
> the change itself, _and_ your validation/testing.
> > I’m not sure if others have reported similar problems on T4 or T5
> > systems.
> Not that I'm aware of, and I haven't seen it on my T4-1.
> > If you have a quicker or better methodology for reviewing stack
> > usage—or
> > any general suggestions—I’m definitely open to seeing them, along
> > with
> > your config and exact procedure. And if you need help validating
> > against
> > S7‑2 and T7‑1 hardware, I can try to allocate some time to assist.
> I think that would be very helpful. Let's try to settle the 32K-vs-64K
> question with more data.
>
> The kernel has stack measurement built in.
>
> The in-kernel method:
>    CONFIG_STACK_TRACER=y
>    CONFIG_DEBUG_STACK_USAGE=y
>    CONFIG_SCHED_STACK_END_CHECK=y
>
> Boot with "stacktrace" on the kernel command line (arms the tracer
> before built-in drivers probe). Then:
>
>    cat /sys/kernel/tracing/stack_max_size   # worst case seen, bytes
>    cat /sys/kernel/tracing/stack_trace      # that path, frame by frame
>
> Reset with "echo 0 > stack_max_size" before a workload to isolate it.
>
> For the 32K-vs-64K question, the most valuable data you could gather
> is a stack_trace snapshot on the S7-2/T7-1 under your real workload
> with mlx5 active, on a 32K kernel.
>
> On our T4-1 the worst case is 12616 bytes, but doesn't have mlx5. If
> your machines stay well under 32K, we have comfortable margin. But if
> something approaches the limit, the trace will name the exact frames,
> and we can judge whether the right answer is 64K or a targeted fix in
> that driver.
> Thanks!