-
Notifications
You must be signed in to change notification settings - Fork 8k
Labels
area: RISCVRISCV Architecture (32-bit & 64-bit)RISCV Architecture (32-bit & 64-bit)bugThe issue is a bug, or the PR is fixing a bugThe issue is a bug, or the PR is fixing a bugpriority: lowLow impact/importance bugLow impact/importance bug
Description
Describe the bug
Currently, the IRQ stacks of secondary cores are not initialized to 0xAA
when CONFIG_INIT_STACKS=y
, this results in the watermark not being correctly computed by Zephyr, which can be seen by doing kernel thread stacks
. This issue also exists in at least v3.5.0 and earlier.
Not sure if this has any other implications, other that the kernel thread stacks
not displaying the watermark correctly.
*** Booting Zephyr OS build zephyr-v3.5.0-80-gd47129f0f7d5 ***
Hello World! qemu_riscv64_smp
uart:~$ kernel stacks
0x80010870 idle 01 (real size 1024): unused 612 usage 412 / 1024 (40 %)
0x80010c00 sysworkq (real size 1024): unused 668 usage 356 / 1024 (34 %)
0x800100f0 shell_uart (real size 3072): unused 1268 usage 1804 / 3072 (58 %)
0x80010710 idle 00 (real size 1024): unused 612 usage 412 / 1024 (40 %)
0x800119b0 IRQ 00 (real size 2048): unused 1236 usage 812 / 2048 (39 %)
0x800121b0 IRQ 01 (real size 2048): unused 0 usage 2048 / 2048 (100 %)
To Reproduce
- Check out current
main
branch west build -b qemu_riscv64_smp -p auto -t run zephyr/samples/hello_world -- -DCONFIG_SHELL=y
- Run shell command:
kernel thread stacks
- Check the
IRQ 01
++ stacks, the usage is always at 100%
Expected behavior
The usage should reflect the real watermark of the IRQ stack, which should be much lesser than 100%
Impact
z_stack_space_get
will return the actual usage of secondary cores' IRQ stack
Additional context
Metadata
Metadata
Assignees
Labels
area: RISCVRISCV Architecture (32-bit & 64-bit)RISCV Architecture (32-bit & 64-bit)bugThe issue is a bug, or the PR is fixing a bugThe issue is a bug, or the PR is fixing a bugpriority: lowLow impact/importance bugLow impact/importance bug