Linux kernel regressions
 help / color / mirror / Atom feed
From: Tony Rodriguez <unixpro1970@gmail.com>
To: Stian Halseth <stian@itx.no>,
	andreas@gaisler.com, davem@davemloft.net,
	sparclinux@vger.kernel.org
Cc: linux-kernel@vger.kernel.org, david.laight.linux@gmail.com,
	glaubitz@physik.fu-berlin.de, thuth@redhat.com,
	regressions@lists.linux.dev, nroach44@nroach44.id.au
Subject: Re: [PATCH v2] sparc64: increase kernel thread stack size to 32K
Date: Mon, 31 Aug 2026 13:18:07 -0700	[thread overview]
Message-ID: <b46209d5-e518-4289-9b3a-5854a2512278@gmail.com> (raw)
In-Reply-To: <680606d594645568c21afcc552558882c4f59a96.camel@itx.no>

Hi Stian,

No problem at all, and I appreciate your honesty and for reaching out. 
It’s best to get this addressed as soon as possible if you have the time 
to work on it—I’m currently swamped with other tasks. Overall, I don’t 
mind if you take over these patches, and truly appreciate your 
assistance to the sparc64 community. 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.

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. 
I’m not sure if others have reported similar problems on T4 or T5 systems.

Regarding:

STACKTRACE: hub_event():entry: 31856 bytes used
STACKTRACE: hub_activate():entry: 31680 bytes used
STACKTRACE: usb_control_msg():entry: 30768 bytes used

This was a set of debugging code inserted into function hot spots and 
scripts to measure stack usage at runtime. It helped me identify trouble 
spots and gave me a better idea of where stack consumption was highest. 
At the time, I wondered whether it might be possible to reduce the stack 
size of usbcore and the Nvidia mlx5 functions on sparc64, but that would 
be a significantly more time‑consuming task. I may have updated my stack 
monitoring script since then as well.  It’s also been a few months, so 
I’d need to refresh my memory on the details.

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.

Best regards,
Tony

On 8/31/26 11:54 AM, Stian Halseth wrote:
> Hi Tony,
>
> You're welcome.
>
> I saw it was stuck, and wanted to push it along. Looks to me like a
> proper fix that should be included.
>
> PS: Don't want to take any credit, this is 100% your fix. If you rather
> want to handle it yourself, let me know :)
>

  reply	other threads:[~2026-08-31 20:18 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-05-19  7:57 [PATCH 0/1] sparc64: unify thread stack sizing and add explicit 32KB stack Tony Rodriguez
2026-05-19  7:57 ` [PATCH 1/1] " Tony Rodriguez
2026-05-19  8:56   ` Nathaniel Roach
2026-06-16 14:18   ` Andreas Larsson
2026-06-16 19:58     ` David Laight
2026-06-18  5:53       ` Andreas Larsson
2026-06-18  7:29         ` Tony Rodriguez
2026-06-18  8:57           ` David Laight
2026-06-18 10:32         ` David Laight
2026-05-19 10:02 ` [PATCH 0/1] " David Laight
2026-05-19 23:57   ` Tony Rodriguez
2026-05-20 13:41     ` David Laight
2026-08-31 17:27       ` Stian Halseth
2026-08-31 17:29 ` [PATCH v2] sparc64: increase kernel thread stack size to 32K Stian Halseth
2026-08-31 18:25   ` Tony Rodriguez
2026-08-31 18:54     ` Stian Halseth
2026-08-31 20:18       ` Tony Rodriguez [this message]
2026-08-31 21:05         ` Stian Halseth
2026-09-02  3:30           ` Tony Rodriguez
     [not found] <f3719bb0-e892-49cc-af82-79e2569a8a90@gmail.com>
2026-08-31 19:04 ` Tony Rodriguez

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=b46209d5-e518-4289-9b3a-5854a2512278@gmail.com \
    --to=unixpro1970@gmail.com \
    --cc=andreas@gaisler.com \
    --cc=davem@davemloft.net \
    --cc=david.laight.linux@gmail.com \
    --cc=glaubitz@physik.fu-berlin.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=nroach44@nroach44.id.au \
    --cc=regressions@lists.linux.dev \
    --cc=sparclinux@vger.kernel.org \
    --cc=stian@itx.no \
    --cc=thuth@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox