From: David Laight <david.laight.linux@gmail.com>
To: Tony Rodriguez <unixpro1970@gmail.com>
Cc: davem@davemloft.net, sparclinux@vger.kernel.org,
linux-kernel@vger.kernel.org, andreas@gaisler.com,
thuth@redhat.com, regressions@lists.linux.dev,
glaubitz@physik.fu-berlin.de
Subject: Re: [PATCH 0/1] sparc64: unify thread stack sizing and add explicit 32KB stack
Date: Wed, 20 May 2026 14:41:04 +0100 [thread overview]
Message-ID: <20260520144104.618c75ca@pumpkin> (raw)
In-Reply-To: <05e0e7a5-107b-410b-853b-883810b1be3e@gmail.com>
On Tue, 19 May 2026 16:57:04 -0700
Tony Rodriguez <unixpro1970@gmail.com> wrote:
> On 5/19/26 3:02 AM, David Laight wrote:
> > On Tue, 19 May 2026 00:57:54 -0700
> > Tony Rodriguez <unixpro1970@gmail.com> wrote:
> >
> >> This patch fixes a reproducible stack exhaustion issue on SPARC64
> >> that occurs during USB hub enumeration. This regression may have
> >> started sometime after kernel v6.12. With the default 16KB kernel
> >> stack, the following panic is triggered early in boot:
> >>
> >> [ 25.528399] Call Trace:
> >> [ 25.528403] [<0000000000433cd4>] dump_stack+0x8/0x18
> >> [ 25.528419] [<00000000004297ac>] vpanic+0xdc/0x318
> >> [ 25.528429] [<0000000000429a0c>] panic+0x24/0x30
> >> [ 25.528436] [<0000000000be2280>] __schedule+0xa8/0x7bc
> >> [ 25.528445] [<0000000000be2b60>] schedule+0x24/0x4c
> >> [ 25.528452] [<0000000000be6970>] schedule_timeout+0xc8/0xe4
> >> [ 25.528459] [<0000000000be3318>] __wait_for_common+0x78/0xf0
> >> [ 25.528466] [<0000000000be3550>] wait_for_completion_timeout+0x1c/0x2c
> >> [ 25.528473] [<000000001005e2f4>] usb_start_wait_urb+0x68/0x128 [usbcore]
> >> [ 25.528502] [<000000001005e468>] usb_control_msg+0xb4/0xf8 [usbcore]
> >> [ 25.528518] [<0000000010051180>] set_port_feature+0x44/0x54 [usbcore]
> >> [ 25.528530] [<00000000100530f0>] hub_power_on+0xc8/0xe8 [usbcore]
> >> [ 25.528543] [<0000000010054fd8>] hub_activate+0x12c/0x644 [usbcore]
> >> [ 25.528557] [<0000000010059438>] hub_probe+0xdd4/0xeb0 [usbcore]
> >> [ 25.528570] [<0000000010062360>] usb_probe_interface+0x234/0x26c [usbcore]
> >> [ 25.528585] [<0000000000a10a40>] really_probe+0x1ac/0x3b0
> >>
> >> This is caused by large SPARC64 trapframes, register-window spills,
> >> and deep call paths in usbcore. A 16KB stack is insufficient for
> >> this workload.
> > Increasing the stack size for all threads seems overkill.
> > That stack doesn't even look deep.
> > I suspect there are large on-stack buffers in there.
> >
> > Unfortunately the traceback doesn't print the stack pointers making
> > debugging hard.
> >
> > -- David
>
> Hi David. Any specific grub command line keywords and values, and
> functions you recommend for debugging this? I would be happy to share
> Trace Calls, etc. so it is easier to reconfirm and zero in on the issue.
Without the stack offsets from the dump, look at the stack frame sizes
for the functions in that traceback.
I suspect there are too many that get near the compile-time threshold.
-- David
> -- Tony
>
> >> The new logic is:
> >>
> >> SPARC64:
> >> THREAD_SIZE = 4 * PAGE_SIZE (32KB)
> >> THREAD_SHIFT = PAGE_SHIFT + 2
> >> THREAD_SIZE_ORDER = 2
> >>
> >> Non‑SPARC64 with PAGE_SHIFT == 13:
> >> Retains the existing 16KB stack behavior
> >>
> >> Fallback:
> >> Retains the existing 8KB stack behavior
> >>
> >> Signed-off-by: Tony Rodriguez <unixpro1970@gmail.com>
> >>
> >>
> >> Tony Rodriguez (1):
> >> sparc64: unify thread stack sizing and add explicit 32KB stack
> >>
> >> arch/sparc/include/asm/thread_info_64.h | 28 ++++++++++++-------------
> >> 1 file changed, 14 insertions(+), 14 deletions(-)
> >>
> >> --
> >> 2.53.0
> >>
> >>
>
prev parent reply other threads:[~2026-05-20 13:41 UTC|newest]
Thread overview: 6+ 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-05-19 10:02 ` [PATCH 0/1] " David Laight
2026-05-19 23:57 ` Tony Rodriguez
2026-05-20 13:41 ` David Laight [this message]
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=20260520144104.618c75ca@pumpkin \
--to=david.laight.linux@gmail.com \
--cc=andreas@gaisler.com \
--cc=davem@davemloft.net \
--cc=glaubitz@physik.fu-berlin.de \
--cc=linux-kernel@vger.kernel.org \
--cc=regressions@lists.linux.dev \
--cc=sparclinux@vger.kernel.org \
--cc=thuth@redhat.com \
--cc=unixpro1970@gmail.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.