Hi Tony,

This email got lost on me, so a bit late reply.

Thanks for testing and validating 32K.

As far as I'm concerned no need to retest. Your results from the 32K
stack test answers the question. I've been testing on 7.2.

Timer patch is just changelog and description changes.

Best regards
Stian
 

On Tue, 2026-09-01 at 20:30 -0700, Tony Rodriguez wrote:
> 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!
> >