[PATCH 0/1] sparc64: unify thread stack sizing and add explicit 32KB stack

[PATCH 0/1] sparc64: unify thread stack sizing and add explicit 32KB stack

[Tony Rodriguez]

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.

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

[PATCH 1/1] sparc64: unify thread stack sizing and add explicit 32KB stack

[Tony Rodriguez]

This patch restructures the thread‑stack sizing logic into a single
if / elif / else chain and introduces an explicit 32KB kernel stack
for SPARC64. The previous implementation relied on nested conditionals
and PAGE_SHIFT‑dependent behavior, which produced 8KB or 16KB stacks
depending on configuration. SPARC64 requires a larger,
architecture‑specific stack due to its trapframe size, register‑window
behavior, and deeper call paths.

A reproducible failure case occurs when usbcore is enabled: USB hub
enumeration (usb_new_device(), hub_port_connect(), PM/QoS helpers)
allocates large on‑stack structures and recurses through several
layers of device‑model code. Combined with SPARC64’s trapframe and
register‑window overhead, this reliably exhausts a 16KB stack and
results in early‑boot panics.  A 32KB stack eliminates these failures.

The new logic is:
    SPARC64:
        THREAD_SIZE = 4 * PAGE_SIZE (32KB)
        THREAD_SHIFT = PAGE_SHIFT + 2 (log₂(32KB))
        THREAD_SIZE_ORDER = 2 (4 contiguous pages)
    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>
---
 arch/sparc/include/asm/thread_info_64.h | 28 ++++++++++++-------------
 1 file changed, 14 insertions(+), 14 deletions(-)

diff --git a/arch/sparc/include/asm/thread_info_64.h b/arch/sparc/include/asm/thread_info_64.h
index c8a73dff27f8..6b12a2b66385 100644
--- a/arch/sparc/include/asm/thread_info_64.h
+++ b/arch/sparc/include/asm/thread_info_64.h
@@ -99,13 +99,20 @@ struct thread_info {
 #define FAULT_CODE_BLKCOMMIT	0x10	/* Use blk-commit ASI in copy_page */
 #define	FAULT_CODE_BAD_RA	0x20	/* Bad RA for sun4v		   */

-#if PAGE_SHIFT == 13
-#define THREAD_SIZE (2*PAGE_SIZE)
-#define THREAD_SHIFT (PAGE_SHIFT + 1)
-#else /* PAGE_SHIFT == 13 */
-#define THREAD_SIZE PAGE_SIZE
-#define THREAD_SHIFT PAGE_SHIFT
-#endif /* PAGE_SHIFT == 13 */
+/* thread information allocation */
+#ifdef CONFIG_SPARC64
+	#define THREAD_SIZE (4 * PAGE_SIZE)
+	#define THREAD_SHIFT (PAGE_SHIFT + 2)
+	#define THREAD_SIZE_ORDER 2
+#elif PAGE_SHIFT == 13
+	#define THREAD_SIZE (2 * PAGE_SIZE)
+	#define THREAD_SHIFT (PAGE_SHIFT + 1)
+	#define THREAD_SIZE_ORDER 1
+#else
+	#define THREAD_SIZE PAGE_SIZE
+	#define THREAD_SHIFT PAGE_SHIFT
+	#define THREAD_SIZE_ORDER 0
+#endif

 /*
  * macros/functions for gaining access to the thread information structure
@@ -127,13 +134,6 @@ register struct thread_info *current_thread_info_reg asm("g6");
 extern struct thread_info *current_thread_info(void);
 #endif

-/* thread information allocation */
-#if PAGE_SHIFT == 13
-#define THREAD_SIZE_ORDER	1
-#else /* PAGE_SHIFT == 13 */
-#define THREAD_SIZE_ORDER	0
-#endif /* PAGE_SHIFT == 13 */
-
 #define __thread_flag_byte_ptr(ti)	\
 	((unsigned char *)(&((ti)->flags)))
 #define __cur_thread_flag_byte_ptr	__thread_flag_byte_ptr(current_thread_info())
--
2.53.0

Re: [PATCH 1/1] sparc64: unify thread stack sizing and add explicit 32KB stack

[Nathaniel Roach]

On 19/5/26 15:57, Tony Rodriguez wrote:
> This patch restructures the thread‑stack sizing logic into a single
> if / elif / else chain and introduces an explicit 32KB kernel stack
> for SPARC64. The previous implementation relied on nested conditionals
> and PAGE_SHIFT‑dependent behavior, which produced 8KB or 16KB stacks
> depending on configuration. SPARC64 requires a larger,
> architecture‑specific stack due to its trapframe size, register‑window
> behavior, and deeper call paths.
>
> A reproducible failure case occurs when usbcore is enabled: USB hub
> enumeration (usb_new_device(), hub_port_connect(), PM/QoS helpers)
> allocates large on‑stack structures and recurses through several
> layers of device‑model code. Combined with SPARC64’s trapframe and
> register‑window overhead, this reliably exhausts a 16KB stack and
> results in early‑boot panics.  A 32KB stack eliminates these failures.
>
> The new logic is:
>      SPARC64:
>          THREAD_SIZE = 4 * PAGE_SIZE (32KB)
>          THREAD_SHIFT = PAGE_SHIFT + 2 (log₂(32KB))
>          THREAD_SIZE_ORDER = 2 (4 contiguous pages)
>      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>
Tested-by: Nathaniel Roach <nroach44@nroach44.id.au> # SPARC T5-2
> ---
>   arch/sparc/include/asm/thread_info_64.h | 28 ++++++++++++-------------
>   1 file changed, 14 insertions(+), 14 deletions(-)
>
> diff --git a/arch/sparc/include/asm/thread_info_64.h b/arch/sparc/include/asm/thread_info_64.h
> index c8a73dff27f8..6b12a2b66385 100644
> --- a/arch/sparc/include/asm/thread_info_64.h
> +++ b/arch/sparc/include/asm/thread_info_64.h
> @@ -99,13 +99,20 @@ struct thread_info {
>   #define FAULT_CODE_BLKCOMMIT	0x10	/* Use blk-commit ASI in copy_page */
>   #define	FAULT_CODE_BAD_RA	0x20	/* Bad RA for sun4v		   */
>
> -#if PAGE_SHIFT == 13
> -#define THREAD_SIZE (2*PAGE_SIZE)
> -#define THREAD_SHIFT (PAGE_SHIFT + 1)
> -#else /* PAGE_SHIFT == 13 */
> -#define THREAD_SIZE PAGE_SIZE
> -#define THREAD_SHIFT PAGE_SHIFT
> -#endif /* PAGE_SHIFT == 13 */
> +/* thread information allocation */
> +#ifdef CONFIG_SPARC64
> +	#define THREAD_SIZE (4 * PAGE_SIZE)
> +	#define THREAD_SHIFT (PAGE_SHIFT + 2)
> +	#define THREAD_SIZE_ORDER 2
> +#elif PAGE_SHIFT == 13
> +	#define THREAD_SIZE (2 * PAGE_SIZE)
> +	#define THREAD_SHIFT (PAGE_SHIFT + 1)
> +	#define THREAD_SIZE_ORDER 1
> +#else
> +	#define THREAD_SIZE PAGE_SIZE
> +	#define THREAD_SHIFT PAGE_SHIFT
> +	#define THREAD_SIZE_ORDER 0
> +#endif
>
>   /*
>    * macros/functions for gaining access to the thread information structure
> @@ -127,13 +134,6 @@ register struct thread_info *current_thread_info_reg asm("g6");
>   extern struct thread_info *current_thread_info(void);
>   #endif
>
> -/* thread information allocation */
> -#if PAGE_SHIFT == 13
> -#define THREAD_SIZE_ORDER	1
> -#else /* PAGE_SHIFT == 13 */
> -#define THREAD_SIZE_ORDER	0
> -#endif /* PAGE_SHIFT == 13 */
> -
>   #define __thread_flag_byte_ptr(ti)	\
>   	((unsigned char *)(&((ti)->flags)))
>   #define __cur_thread_flag_byte_ptr	__thread_flag_byte_ptr(current_thread_info())
> --
> 2.53.0
>
>

Re: [PATCH 1/1] sparc64: unify thread stack sizing and add explicit 32KB stack

[Andreas Larsson]

On 2026-05-19 09:57, Tony Rodriguez wrote:
> This patch restructures the thread‑stack sizing logic into a single
> if / elif / else chain and introduces an explicit 32KB kernel stack
> for SPARC64. The previous implementation relied on nested conditionals
> and PAGE_SHIFT‑dependent behavior, which produced 8KB or 16KB stacks
> depending on configuration. SPARC64 requires a larger,
> architecture‑specific stack due to its trapframe size, register‑window
> behavior, and deeper call paths.
> 
> A reproducible failure case occurs when usbcore is enabled: USB hub
> enumeration (usb_new_device(), hub_port_connect(), PM/QoS helpers)
> allocates large on‑stack structures and recurses through several
> layers of device‑model code. Combined with SPARC64’s trapframe and
> register‑window overhead, this reliably exhausts a 16KB stack and
> results in early‑boot panics.  A 32KB stack eliminates these failures.
> 
> The new logic is:
>     SPARC64:
>         THREAD_SIZE = 4 * PAGE_SIZE (32KB)
>         THREAD_SHIFT = PAGE_SHIFT + 2 (log₂(32KB))
>         THREAD_SIZE_ORDER = 2 (4 contiguous pages)

Yes

>     Non‑SPARC64 with PAGE_SHIFT == 13:
>         Retains the existing 16KB stack behavior
>     Fallback:
>         Retains the existing 8KB stack behavior

No, not to my understanding, see comments below.

> 
> Signed-off-by: Tony Rodriguez <unixpro1970@gmail.com>
> ---
>  arch/sparc/include/asm/thread_info_64.h | 28 ++++++++++++-------------
>  1 file changed, 14 insertions(+), 14 deletions(-)
> 
> diff --git a/arch/sparc/include/asm/thread_info_64.h b/arch/sparc/include/asm/thread_info_64.h
> index c8a73dff27f8..6b12a2b66385 100644
> --- a/arch/sparc/include/asm/thread_info_64.h
> +++ b/arch/sparc/include/asm/thread_info_64.h
> @@ -99,13 +99,20 @@ struct thread_info {
>  #define FAULT_CODE_BLKCOMMIT	0x10	/* Use blk-commit ASI in copy_page */
>  #define	FAULT_CODE_BAD_RA	0x20	/* Bad RA for sun4v		   */
> 
> -#if PAGE_SHIFT == 13
> -#define THREAD_SIZE (2*PAGE_SIZE)
> -#define THREAD_SHIFT (PAGE_SHIFT + 1)
> -#else /* PAGE_SHIFT == 13 */
> -#define THREAD_SIZE PAGE_SIZE
> -#define THREAD_SHIFT PAGE_SHIFT
> -#endif /* PAGE_SHIFT == 13 */
> +/* thread information allocation */
> +#ifdef CONFIG_SPARC64
> +	#define THREAD_SIZE (4 * PAGE_SIZE)
> +	#define THREAD_SHIFT (PAGE_SHIFT + 2)
> +	#define THREAD_SIZE_ORDER 2

As far as I can see, given that this header is included by

#if defined(__sparc__) && defined(__arch64__)
#include <asm/thread_info_64.h>
#else
#include <asm/thread_info_32.h>
#endif

the code above is the only code that will ever be compiled, while leaving...

> +#elif PAGE_SHIFT == 13
> +	#define THREAD_SIZE (2 * PAGE_SIZE)
> +	#define THREAD_SHIFT (PAGE_SHIFT + 1)
> +	#define THREAD_SIZE_ORDER 1
> +#else
> +	#define THREAD_SIZE PAGE_SIZE
> +	#define THREAD_SHIFT PAGE_SHIFT
> +	#define THREAD_SIZE_ORDER 0
> +#endif

...this code dead, where the else branch code already was dead (but then
in two separate else braches).

I'd rather see the else branch here and the else branch below cleaned up
by a separate patch with a fixup tag for commit 15b9350a177b ("sparc64:
Only support 4MB huge pages and 8KB base pages.") that as far as I can
see should have removed the else branch. The else branches was to use
only one page when the page size was _larger_ than 8 KiB when that was
an option.

> 
>  /*
>   * macros/functions for gaining access to the thread information structure
> @@ -127,13 +134,6 @@ register struct thread_info *current_thread_info_reg asm("g6");
>  extern struct thread_info *current_thread_info(void);
>  #endif
> 
> -/* thread information allocation */
> -#if PAGE_SHIFT == 13
> -#define THREAD_SIZE_ORDER	1
> -#else /* PAGE_SHIFT == 13 */
> -#define THREAD_SIZE_ORDER	0
> -#endif /* PAGE_SHIFT == 13 */
> -
>  #define __thread_flag_byte_ptr(ti)	\
>  	((unsigned char *)(&((ti)->flags)))
>  #define __cur_thread_flag_byte_ptr	__thread_flag_byte_ptr(current_thread_info())
> --
> 2.53.0
> 

Apart from the above I agree with David Laight that more investigation
of the situation that leads to this problem would be good. Granted,
sparc and sparc64 in particular is a bit special with its stack frames,
but among other arches it seems to be uncommon with 32 KiB of thread
stack unless KASAN is enabled.

Cheers,
Andreas

Re: [PATCH 1/1] sparc64: unify thread stack sizing and add explicit 32KB stack

[David Laight]

On Tue, 16 Jun 2026 16:18:33 +0200
Andreas Larsson <andreas.larsson@gaisler.com> wrote:

> On 2026-05-19 09:57, Tony Rodriguez wrote:
> > This patch restructures the thread‑stack sizing logic into a single
> > if / elif / else chain and introduces an explicit 32KB kernel stack
> > for SPARC64. The previous implementation relied on nested conditionals
> > and PAGE_SHIFT‑dependent behavior, which produced 8KB or 16KB stacks
> > depending on configuration. SPARC64 requires a larger,
> > architecture‑specific stack due to its trapframe size, register‑window
> > behavior, and deeper call paths.
> > 
> > A reproducible failure case occurs when usbcore is enabled: USB hub
> > enumeration (usb_new_device(), hub_port_connect(), PM/QoS helpers)
> > allocates large on‑stack structures and recurses through several
> > layers of device‑model code. Combined with SPARC64’s trapframe and
> > register‑window overhead, this reliably exhausts a 16KB stack and
> > results in early‑boot panics.  A 32KB stack eliminates these failures.
> > 
> > The new logic is:
> >     SPARC64:
> >         THREAD_SIZE = 4 * PAGE_SIZE (32KB)
> >         THREAD_SHIFT = PAGE_SHIFT + 2 (log₂(32KB))
> >         THREAD_SIZE_ORDER = 2 (4 contiguous pages)  
> 
> Yes
> 
> >     Non‑SPARC64 with PAGE_SHIFT == 13:
> >         Retains the existing 16KB stack behavior
> >     Fallback:
> >         Retains the existing 8KB stack behavior  
> 
> No, not to my understanding, see comments below.
> 
> > 
> > Signed-off-by: Tony Rodriguez <unixpro1970@gmail.com>
> > ---
> >  arch/sparc/include/asm/thread_info_64.h | 28 ++++++++++++-------------
> >  1 file changed, 14 insertions(+), 14 deletions(-)
> > 
> > diff --git a/arch/sparc/include/asm/thread_info_64.h b/arch/sparc/include/asm/thread_info_64.h
> > index c8a73dff27f8..6b12a2b66385 100644
> > --- a/arch/sparc/include/asm/thread_info_64.h
> > +++ b/arch/sparc/include/asm/thread_info_64.h
> > @@ -99,13 +99,20 @@ struct thread_info {
> >  #define FAULT_CODE_BLKCOMMIT	0x10	/* Use blk-commit ASI in copy_page */
> >  #define	FAULT_CODE_BAD_RA	0x20	/* Bad RA for sun4v		   */
> > 
> > -#if PAGE_SHIFT == 13
> > -#define THREAD_SIZE (2*PAGE_SIZE)
> > -#define THREAD_SHIFT (PAGE_SHIFT + 1)
> > -#else /* PAGE_SHIFT == 13 */
> > -#define THREAD_SIZE PAGE_SIZE
> > -#define THREAD_SHIFT PAGE_SHIFT
> > -#endif /* PAGE_SHIFT == 13 */
> > +/* thread information allocation */
> > +#ifdef CONFIG_SPARC64
> > +	#define THREAD_SIZE (4 * PAGE_SIZE)
> > +	#define THREAD_SHIFT (PAGE_SHIFT + 2)
> > +	#define THREAD_SIZE_ORDER 2  
> 
> As far as I can see, given that this header is included by
> 
> #if defined(__sparc__) && defined(__arch64__)
> #include <asm/thread_info_64.h>
> #else
> #include <asm/thread_info_32.h>
> #endif
> 
> the code above is the only code that will ever be compiled, while leaving...
> 
> > +#elif PAGE_SHIFT == 13
> > +	#define THREAD_SIZE (2 * PAGE_SIZE)
> > +	#define THREAD_SHIFT (PAGE_SHIFT + 1)
> > +	#define THREAD_SIZE_ORDER 1
> > +#else
> > +	#define THREAD_SIZE PAGE_SIZE
> > +	#define THREAD_SHIFT PAGE_SHIFT
> > +	#define THREAD_SIZE_ORDER 0
> > +#endif  
> 
> ...this code dead, where the else branch code already was dead (but then
> in two separate else braches).
> 
> I'd rather see the else branch here and the else branch below cleaned up
> by a separate patch with a fixup tag for commit 15b9350a177b ("sparc64:
> Only support 4MB huge pages and 8KB base pages.") that as far as I can
> see should have removed the else branch. The else branches was to use
> only one page when the page size was _larger_ than 8 KiB when that was
> an option.

That whole logic is impenetrable.
Why not set the 'desired thread size' in kB, then work out how many
pages that ends up being based on the page size, and finally get the actual
stack size.
I'm not sure, but with vmalloc()ed stacks and 8k pages can't you have 24kB?

	David


> 
> > 
> >  /*
> >   * macros/functions for gaining access to the thread information structure
> > @@ -127,13 +134,6 @@ register struct thread_info *current_thread_info_reg asm("g6");
> >  extern struct thread_info *current_thread_info(void);
> >  #endif
> > 
> > -/* thread information allocation */
> > -#if PAGE_SHIFT == 13
> > -#define THREAD_SIZE_ORDER	1
> > -#else /* PAGE_SHIFT == 13 */
> > -#define THREAD_SIZE_ORDER	0
> > -#endif /* PAGE_SHIFT == 13 */
> > -
> >  #define __thread_flag_byte_ptr(ti)	\
> >  	((unsigned char *)(&((ti)->flags)))
> >  #define __cur_thread_flag_byte_ptr	__thread_flag_byte_ptr(current_thread_info())
> > --
> > 2.53.0
> >   
> 
> Apart from the above I agree with David Laight that more investigation
> of the situation that leads to this problem would be good. Granted,
> sparc and sparc64 in particular is a bit special with its stack frames,
> but among other arches it seems to be uncommon with 32 KiB of thread
> stack unless KASAN is enabled.
> 
> Cheers,
> Andreas
> 

Re: [PATCH 1/1] sparc64: unify thread stack sizing and add explicit 32KB stack

[Andreas Larsson]

On 2026-06-16 21:58, David Laight wrote:
> On Tue, 16 Jun 2026 16:18:33 +0200
> Andreas Larsson <andreas.larsson@gaisler.com> wrote:
> 
>> On 2026-05-19 09:57, Tony Rodriguez wrote:
>>> This patch restructures the thread‑stack sizing logic into a single
>>> if / elif / else chain and introduces an explicit 32KB kernel stack
>>> for SPARC64. The previous implementation relied on nested conditionals
>>> and PAGE_SHIFT‑dependent behavior, which produced 8KB or 16KB stacks
>>> depending on configuration. SPARC64 requires a larger,
>>> architecture‑specific stack due to its trapframe size, register‑window
>>> behavior, and deeper call paths.
>>>
>>> A reproducible failure case occurs when usbcore is enabled: USB hub
>>> enumeration (usb_new_device(), hub_port_connect(), PM/QoS helpers)
>>> allocates large on‑stack structures and recurses through several
>>> layers of device‑model code. Combined with SPARC64’s trapframe and
>>> register‑window overhead, this reliably exhausts a 16KB stack and
>>> results in early‑boot panics.  A 32KB stack eliminates these failures.
>>>
>>> The new logic is:
>>>     SPARC64:
>>>         THREAD_SIZE = 4 * PAGE_SIZE (32KB)
>>>         THREAD_SHIFT = PAGE_SHIFT + 2 (log₂(32KB))
>>>         THREAD_SIZE_ORDER = 2 (4 contiguous pages)  
>>
>> Yes
>>
>>>     Non‑SPARC64 with PAGE_SHIFT == 13:
>>>         Retains the existing 16KB stack behavior
>>>     Fallback:
>>>         Retains the existing 8KB stack behavior  
>>
>> No, not to my understanding, see comments below.
>>
>>>
>>> Signed-off-by: Tony Rodriguez <unixpro1970@gmail.com>
>>> ---
>>>  arch/sparc/include/asm/thread_info_64.h | 28 ++++++++++++-------------
>>>  1 file changed, 14 insertions(+), 14 deletions(-)
>>>
>>> diff --git a/arch/sparc/include/asm/thread_info_64.h b/arch/sparc/include/asm/thread_info_64.h
>>> index c8a73dff27f8..6b12a2b66385 100644
>>> --- a/arch/sparc/include/asm/thread_info_64.h
>>> +++ b/arch/sparc/include/asm/thread_info_64.h
>>> @@ -99,13 +99,20 @@ struct thread_info {
>>>  #define FAULT_CODE_BLKCOMMIT	0x10	/* Use blk-commit ASI in copy_page */
>>>  #define	FAULT_CODE_BAD_RA	0x20	/* Bad RA for sun4v		   */
>>>
>>> -#if PAGE_SHIFT == 13
>>> -#define THREAD_SIZE (2*PAGE_SIZE)
>>> -#define THREAD_SHIFT (PAGE_SHIFT + 1)
>>> -#else /* PAGE_SHIFT == 13 */
>>> -#define THREAD_SIZE PAGE_SIZE
>>> -#define THREAD_SHIFT PAGE_SHIFT
>>> -#endif /* PAGE_SHIFT == 13 */
>>> +/* thread information allocation */
>>> +#ifdef CONFIG_SPARC64
>>> +	#define THREAD_SIZE (4 * PAGE_SIZE)
>>> +	#define THREAD_SHIFT (PAGE_SHIFT + 2)
>>> +	#define THREAD_SIZE_ORDER 2  
>>
>> As far as I can see, given that this header is included by
>>
>> #if defined(__sparc__) && defined(__arch64__)
>> #include <asm/thread_info_64.h>
>> #else
>> #include <asm/thread_info_32.h>
>> #endif
>>
>> the code above is the only code that will ever be compiled, while leaving...
>>
>>> +#elif PAGE_SHIFT == 13
>>> +	#define THREAD_SIZE (2 * PAGE_SIZE)
>>> +	#define THREAD_SHIFT (PAGE_SHIFT + 1)
>>> +	#define THREAD_SIZE_ORDER 1
>>> +#else
>>> +	#define THREAD_SIZE PAGE_SIZE
>>> +	#define THREAD_SHIFT PAGE_SHIFT
>>> +	#define THREAD_SIZE_ORDER 0
>>> +#endif  
>>
>> ...this code dead, where the else branch code already was dead (but then
>> in two separate else braches).
>>
>> I'd rather see the else branch here and the else branch below cleaned up
>> by a separate patch with a fixup tag for commit 15b9350a177b ("sparc64:
>> Only support 4MB huge pages and 8KB base pages.") that as far as I can
>> see should have removed the else branch. The else branches was to use
>> only one page when the page size was _larger_ than 8 KiB when that was
>> an option.
> 
> That whole logic is impenetrable.
> Why not set the 'desired thread size' in kB, then work out how many
> pages that ends up being based on the page size, and finally get the actual
> stack size.
> I'm not sure, but with vmalloc()ed stacks and 8k pages can't you have 24kB?

No, the next step up is 32 KiB as the stack allocation is sized by
THREAD_SIZE_ORDER.

Cheers,
Andreas

Re: [PATCH 1/1] sparc64: unify thread stack sizing and add explicit 32KB stack

[Tony Rodriguez]

On 6/17/26 10:53 PM, Andreas Larsson wrote:
> On 2026-06-16 21:58, David Laight wrote:
>> On Tue, 16 Jun 2026 16:18:33 +0200
>> Andreas Larsson <andreas.larsson@gaisler.com> wrote:
>>
>>> On 2026-05-19 09:57, Tony Rodriguez wrote:
>>>> This patch restructures the thread‑stack sizing logic into a single
>>>> if / elif / else chain and introduces an explicit 32KB kernel stack
>>>> for SPARC64. The previous implementation relied on nested conditionals
>>>> and PAGE_SHIFT‑dependent behavior, which produced 8KB or 16KB stacks
>>>> depending on configuration. SPARC64 requires a larger,
>>>> architecture‑specific stack due to its trapframe size, register‑window
>>>> behavior, and deeper call paths.
>>>>
>>>> A reproducible failure case occurs when usbcore is enabled: USB hub
>>>> enumeration (usb_new_device(), hub_port_connect(), PM/QoS helpers)
>>>> allocates large on‑stack structures and recurses through several
>>>> layers of device‑model code. Combined with SPARC64’s trapframe and
>>>> register‑window overhead, this reliably exhausts a 16KB stack and
>>>> results in early‑boot panics.  A 32KB stack eliminates these failures.
>>>>
>>>> The new logic is:
>>>>      SPARC64:
>>>>          THREAD_SIZE = 4 * PAGE_SIZE (32KB)
>>>>          THREAD_SHIFT = PAGE_SHIFT + 2 (log₂(32KB))
>>>>          THREAD_SIZE_ORDER = 2 (4 contiguous pages)
>>> Yes
>>>
>>>>      Non‑SPARC64 with PAGE_SHIFT == 13:
>>>>          Retains the existing 16KB stack behavior
>>>>      Fallback:
>>>>          Retains the existing 8KB stack behavior
>>> No, not to my understanding, see comments below.
>>>
>>>> Signed-off-by: Tony Rodriguez <unixpro1970@gmail.com>
>>>> ---
>>>>   arch/sparc/include/asm/thread_info_64.h | 28 ++++++++++++-------------
>>>>   1 file changed, 14 insertions(+), 14 deletions(-)
>>>>
>>>> diff --git a/arch/sparc/include/asm/thread_info_64.h b/arch/sparc/include/asm/thread_info_64.h
>>>> index c8a73dff27f8..6b12a2b66385 100644
>>>> --- a/arch/sparc/include/asm/thread_info_64.h
>>>> +++ b/arch/sparc/include/asm/thread_info_64.h
>>>> @@ -99,13 +99,20 @@ struct thread_info {
>>>>   #define FAULT_CODE_BLKCOMMIT	0x10	/* Use blk-commit ASI in copy_page */
>>>>   #define	FAULT_CODE_BAD_RA	0x20	/* Bad RA for sun4v		   */
>>>>
>>>> -#if PAGE_SHIFT == 13
>>>> -#define THREAD_SIZE (2*PAGE_SIZE)
>>>> -#define THREAD_SHIFT (PAGE_SHIFT + 1)
>>>> -#else /* PAGE_SHIFT == 13 */
>>>> -#define THREAD_SIZE PAGE_SIZE
>>>> -#define THREAD_SHIFT PAGE_SHIFT
>>>> -#endif /* PAGE_SHIFT == 13 */
>>>> +/* thread information allocation */
>>>> +#ifdef CONFIG_SPARC64
>>>> +	#define THREAD_SIZE (4 * PAGE_SIZE)
>>>> +	#define THREAD_SHIFT (PAGE_SHIFT + 2)
>>>> +	#define THREAD_SIZE_ORDER 2
>>> As far as I can see, given that this header is included by
>>>
>>> #if defined(__sparc__) && defined(__arch64__)
>>> #include <asm/thread_info_64.h>
>>> #else
>>> #include <asm/thread_info_32.h>
>>> #endif
>>>
>>> the code above is the only code that will ever be compiled, while leaving...
>>>
>>>> +#elif PAGE_SHIFT == 13
>>>> +	#define THREAD_SIZE (2 * PAGE_SIZE)
>>>> +	#define THREAD_SHIFT (PAGE_SHIFT + 1)
>>>> +	#define THREAD_SIZE_ORDER 1
>>>> +#else
>>>> +	#define THREAD_SIZE PAGE_SIZE
>>>> +	#define THREAD_SHIFT PAGE_SHIFT
>>>> +	#define THREAD_SIZE_ORDER 0
>>>> +#endif
>>> ...this code dead, where the else branch code already was dead (but then
>>> in two separate else braches).
>>>
>>> I'd rather see the else branch here and the else branch below cleaned up
>>> by a separate patch with a fixup tag for commit 15b9350a177b ("sparc64:
>>> Only support 4MB huge pages and 8KB base pages.") that as far as I can
>>> see should have removed the else branch. The else branches was to use
>>> only one page when the page size was _larger_ than 8 KiB when that was
>>> an option.
>> That whole logic is impenetrable.
>> Why not set the 'desired thread size' in kB, then work out how many
>> pages that ends up being based on the page size, and finally get the actual
>> stack size.
>> I'm not sure, but with vmalloc()ed stacks and 8k pages can't you have 24kB?
> No, the next step up is 32 KiB as the stack allocation is sized by
> THREAD_SIZE_ORDER.
>
> Cheers,
> Andreas
>

After additional testing and debugging on a SPARC64 S7-2 system running 
kernel v7.1-mainline, I've made several important observations regarding 
the USB core stack overflow issue.

1. The Stack Overflow is Real and Consistent

My initial patch (increasing kernel stack to 32KB) appears to work with 
v7.1-mainline as well. However, the underlying problem remains: the USB 
core's stack usage consistently exceeds the default 16KB limit during 
hub enumeration.

2. The "Static Analysis vs. Runtime Reality" Contradiction

When I compile the kernel with -fstack-usage to generate .su files, the 
static analysis shows small stack frames for all USB core functions.

  For example:

hub_event:      2457 bytes  (static)
hub_activate:   1892 bytes  (static)
usb_control_msg: 1248 bytes (static)

However, my runtime stack tracing shows a dramatically different picture:

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

Please see:

https://github.com/unixpro1970/Sparc64-Kernel-Debugging-Dumps/blob/main/usbcore-stacktrace.txt

Perhaps the issue is the accumulation of register window spills across 
multiple nested function calls?

3. The 32KB Limit is Also at Risk

I've observed that stack usage can approach the 32K limit as well.

4. Testing:

TO DO: I will try adding a stack flush at the entry and exit of 
hub_event() .  Hopefully it will prevent the accumulation of register 
windows. The theory is that flushing register windows between work items 
may prevent the stack growth from carrying over from one event to the next.

If the flush helps, I may also look into "stack_trace_flush" David 
Miller's stack_trace_flush() implementation. Unsure if stack_trace_flush 
is supported with v7.1.


Regards,

Tony

Re: [PATCH 1/1] sparc64: unify thread stack sizing and add explicit 32KB stack

[David Laight]

On Thu, 18 Jun 2026 00:29:59 -0700
Tony Rodriguez <unixpro1970@gmail.com> wrote:

> On 6/17/26 10:53 PM, Andreas Larsson wrote:
> > On 2026-06-16 21:58, David Laight wrote:  
> >> On Tue, 16 Jun 2026 16:18:33 +0200
> >> Andreas Larsson <andreas.larsson@gaisler.com> wrote:
> >>  
> >>> On 2026-05-19 09:57, Tony Rodriguez wrote:  
> >>>> This patch restructures the thread‑stack sizing logic into a single
> >>>> if / elif / else chain and introduces an explicit 32KB kernel stack
> >>>> for SPARC64. The previous implementation relied on nested conditionals
> >>>> and PAGE_SHIFT‑dependent behavior, which produced 8KB or 16KB stacks
> >>>> depending on configuration. SPARC64 requires a larger,
> >>>> architecture‑specific stack due to its trapframe size, register‑window
> >>>> behavior, and deeper call paths.
> >>>>
> >>>> A reproducible failure case occurs when usbcore is enabled: USB hub
> >>>> enumeration (usb_new_device(), hub_port_connect(), PM/QoS helpers)
> >>>> allocates large on‑stack structures and recurses through several
> >>>> layers of device‑model code. Combined with SPARC64’s trapframe and
> >>>> register‑window overhead, this reliably exhausts a 16KB stack and
> >>>> results in early‑boot panics.  A 32KB stack eliminates these failures.
> >>>>
> >>>> The new logic is:
> >>>>      SPARC64:
> >>>>          THREAD_SIZE = 4 * PAGE_SIZE (32KB)
> >>>>          THREAD_SHIFT = PAGE_SHIFT + 2 (log₂(32KB))
> >>>>          THREAD_SIZE_ORDER = 2 (4 contiguous pages)  
> >>> Yes
> >>>  
> >>>>      Non‑SPARC64 with PAGE_SHIFT == 13:
> >>>>          Retains the existing 16KB stack behavior
> >>>>      Fallback:
> >>>>          Retains the existing 8KB stack behavior  
> >>> No, not to my understanding, see comments below.
> >>>  
> >>>> Signed-off-by: Tony Rodriguez <unixpro1970@gmail.com>
> >>>> ---
> >>>>   arch/sparc/include/asm/thread_info_64.h | 28 ++++++++++++-------------
> >>>>   1 file changed, 14 insertions(+), 14 deletions(-)
> >>>>
> >>>> diff --git a/arch/sparc/include/asm/thread_info_64.h b/arch/sparc/include/asm/thread_info_64.h
> >>>> index c8a73dff27f8..6b12a2b66385 100644
> >>>> --- a/arch/sparc/include/asm/thread_info_64.h
> >>>> +++ b/arch/sparc/include/asm/thread_info_64.h
> >>>> @@ -99,13 +99,20 @@ struct thread_info {
> >>>>   #define FAULT_CODE_BLKCOMMIT	0x10	/* Use blk-commit ASI in copy_page */
> >>>>   #define	FAULT_CODE_BAD_RA	0x20	/* Bad RA for sun4v		   */
> >>>>
> >>>> -#if PAGE_SHIFT == 13
> >>>> -#define THREAD_SIZE (2*PAGE_SIZE)
> >>>> -#define THREAD_SHIFT (PAGE_SHIFT + 1)
> >>>> -#else /* PAGE_SHIFT == 13 */
> >>>> -#define THREAD_SIZE PAGE_SIZE
> >>>> -#define THREAD_SHIFT PAGE_SHIFT
> >>>> -#endif /* PAGE_SHIFT == 13 */
> >>>> +/* thread information allocation */
> >>>> +#ifdef CONFIG_SPARC64
> >>>> +	#define THREAD_SIZE (4 * PAGE_SIZE)
> >>>> +	#define THREAD_SHIFT (PAGE_SHIFT + 2)
> >>>> +	#define THREAD_SIZE_ORDER 2  
> >>> As far as I can see, given that this header is included by
> >>>
> >>> #if defined(__sparc__) && defined(__arch64__)
> >>> #include <asm/thread_info_64.h>
> >>> #else
> >>> #include <asm/thread_info_32.h>
> >>> #endif
> >>>
> >>> the code above is the only code that will ever be compiled, while leaving...
> >>>  
> >>>> +#elif PAGE_SHIFT == 13
> >>>> +	#define THREAD_SIZE (2 * PAGE_SIZE)
> >>>> +	#define THREAD_SHIFT (PAGE_SHIFT + 1)
> >>>> +	#define THREAD_SIZE_ORDER 1
> >>>> +#else
> >>>> +	#define THREAD_SIZE PAGE_SIZE
> >>>> +	#define THREAD_SHIFT PAGE_SHIFT
> >>>> +	#define THREAD_SIZE_ORDER 0
> >>>> +#endif  
> >>> ...this code dead, where the else branch code already was dead (but then
> >>> in two separate else braches).
> >>>
> >>> I'd rather see the else branch here and the else branch below cleaned up
> >>> by a separate patch with a fixup tag for commit 15b9350a177b ("sparc64:
> >>> Only support 4MB huge pages and 8KB base pages.") that as far as I can
> >>> see should have removed the else branch. The else branches was to use
> >>> only one page when the page size was _larger_ than 8 KiB when that was
> >>> an option.  
> >> That whole logic is impenetrable.
> >> Why not set the 'desired thread size' in kB, then work out how many
> >> pages that ends up being based on the page size, and finally get the actual
> >> stack size.
> >> I'm not sure, but with vmalloc()ed stacks and 8k pages can't you have 24kB?  
> > No, the next step up is 32 KiB as the stack allocation is sized by
> > THREAD_SIZE_ORDER.
> >
> > Cheers,
> > Andreas
> >  
> 
> After additional testing and debugging on a SPARC64 S7-2 system running 
> kernel v7.1-mainline, I've made several important observations regarding 
> the USB core stack overflow issue.
> 
> 1. The Stack Overflow is Real and Consistent
> 
> My initial patch (increasing kernel stack to 32KB) appears to work with 
> v7.1-mainline as well. However, the underlying problem remains: the USB 
> core's stack usage consistently exceeds the default 16KB limit during 
> hub enumeration.
> 
> 2. The "Static Analysis vs. Runtime Reality" Contradiction
> 
> When I compile the kernel with -fstack-usage to generate .su files, the 
> static analysis shows small stack frames for all USB core functions.
> 
>   For example:
> 
> hub_event:      2457 bytes  (static)
> hub_activate:   1892 bytes  (static)
> usb_control_msg: 1248 bytes (static)

Those aren't that small.
The stack frame for a minimal function seems to be 176 bytes.

While there might be other places that allocate stack, most will be
allocated by the 'save %sp, -nnn, %sp' instruction that rotates the
register window (so the %sp it writes to is different from the one
it reads from).
Should be easy so find in the output of 'objdump -d vmlinux.o'.
(search for function_name.: to find the start of a function)

> 
> However, my runtime stack tracing shows a dramatically different picture:
> 
> STACKTRACE: hub_event():entry: 31856 bytes used
> STACKTRACE: hub_activate():entry: 31680 bytes used
> STACKTRACE: usb_control_msg():entry: 30768 bytes used

31856 - 31680 = 176
31680 - 30768 = 912
Those might match the code being run.

That makes it look like a lot of the problem is much earlier in the call stack.

	David

Re: [PATCH 1/1] sparc64: unify thread stack sizing and add explicit 32KB stack

[David Laight]

On Thu, 18 Jun 2026 07:53:02 +0200
Andreas Larsson <andreas@gaisler.com> wrote:

> On 2026-06-16 21:58, David Laight wrote:
...
> > That whole logic is impenetrable.
> > Why not set the 'desired thread size' in kB, then work out how many
> > pages that ends up being based on the page size, and finally get the actual
> > stack size.
> > I'm not sure, but with vmalloc()ed stacks and 8k pages can't you have 24kB?  
> 
> No, the next step up is 32 KiB as the stack allocation is sized by
> THREAD_SIZE_ORDER.

Maybe, but there is probably no reason why that has to be the case.
I'm sure I've seem other architectures increasing the stack size by 4k.

	David

> 
> Cheers,
> Andreas
> 

Re: [PATCH 0/1] sparc64: unify thread stack sizing and add explicit 32KB stack

[David Laight]

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

> 
> 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
> 
> 

Re: [PATCH 0/1] sparc64: unify thread stack sizing and add explicit 32KB stack

[Tony Rodriguez]

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. 
-- 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
>>
>>

Re: [PATCH 0/1] sparc64: unify thread stack sizing and add explicit 32KB stack

[David Laight]

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
> >>
> >>  
>