Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

arch/arm: optimize context switch speed #5645

Merged
merged 2 commits into from
Mar 15, 2022
Merged

Conversation

anchao
Copy link
Contributor

@anchao anchao commented Feb 28, 2022

Summary

arch/arm: optimize context switch speed

The current context save implementation saves registers of each task
to xcp context, which is unnecessary because most of the arm registers are
already saved in the task stack, this commit replace the xcp context with
stack context to improve context switching performance and reduce the tcb
space occupation of tcb instance.

Signed-off-by: chao.an anchao@xiaomi.com

Impact

arm context switch

Testing

Qemu:
sabre-6quad/smp, sabre-6quad/netknsh

Cortex-m33: cycle count test

#define DWT_CYCCNT (DWT_BASE + 0x0004) /* Cycle Count Register */

thread 1: (priority 100)

start = getreg32(DWT_CYCCNT);
sem_post(&g_exclsem);

thread 2: (priority 200)

sem_wait(&g_exclsem);
end = getreg32(DWT_CYCCNT);

Before:
semaphore wait test: 797
After:
semaphore wait test: 604 + ~24%

@masayuki2009
Copy link
Contributor

masayuki2009 commented Mar 1, 2022

@anchao

I tried this PR with my latest imx6-netknsh branches (https://github.com/masayuki2009/incubator-nuttx/tree/imx6-netknsh https://github.com/masayuki2009/incubator-nuttx-apps/tree/imx6-netknsh) and found that init and hello work but getprime fails when it exits.

nsh> /mnt/nfs/bin/getprime
..
[   18.690000] exec_module: Executing /mnt/nfs/bin/getprime
[   18.690000] binfmt_copyargv: args=1 argsize=22
[   18.690000] up_addrenv_select: addrenv=0x10843da4 oldenv=0x10847330
[   18.690000] up_addrenv_select: text: set l1 entry (paddr=1811d000 vaddr=80000000)
[   18.690000] up_addrenv_select: data: set l1 entry (paddr=18122000 vaddr=80100000)
[   18.690000] up_addrenv_select: heap: set l1 entry (paddr=18124000 vaddr=80200000)
[   18.690000] exec_module: Initialize the user heap (heapsize=1048576)
[   18.690000] up_addrenv_kstackalloc: tcb=0x10843dd0 stacksize=3072
[   18.690000] up_addrenv_clone: src=0x10843da4 dest=0x10843f18
[   18.690000] up_addrenv_restore: oldenv=0x10847330
[   18.700000] up_addrenv_select: addrenv=0x10843f18 oldenv=0
[   18.700000] up_addrenv_select: text: set l1 entry (paddr=1811d000 vaddr=80000000)
[   18.700000] up_addrenv_select: data: set l1 entry (paddr=18122000 vaddr=80100000)
[   18.700000] up_addrenv_select: heap: set l1 entry (paddr=18124000 vaddr=80200000)
Set thread priority to 10
Set thread policy to SCHED_RR
Start thread #0
[   18.710000] up_addrenv_attach: group=0x10843ed0 tcb=0x10843dd0
[   18.710000] up_addrenv_kstackalloc: tcb=0x10845430 stacksize=3072
thread #0 started, looking for primes < 10000, doing 10 run(s)
[   20.560000] arm_dataabort: Data abort. PC: 80001bb8 DFAR: 1084349c DFSR: 0000000d
[   20.560000] up_assert: Assertion failed at file:armv7-a/arm_dataabort.c line: 161 task: lpwork
[   20.560000] arm_registerdump: R0: 80204690 R1: 1084348c R2: 80204690  R3: 1084348c
[   20.560000] arm_registerdump: R4: 00000000 R5: 00000000 R6: 00000000  FP: 80204670
[   20.560000] arm_registerdump: R8: 00000000 SB: 00000000 SL: 00000000 R11: 00000000
[   20.560000] arm_registerdump: IP: 10807707 SP: 80204670 LR: 8000172b  PC: 80001bb8
[   20.560000] arm_registerdump: CPSR: 20000070
[   20.560000] arm_dump_stack: IRQ Stack:
[   20.560000] arm_dump_stack: sp:     80204560
[   20.560000] arm_dump_stack:   base: 1083a8c0
[   20.560000] arm_dump_stack:   size: 00000800
[   20.560000] arm_dump_stack: ERROR: IRQ Stack pointer is not within the stack
[   20.560000] arm_stackdump: 1083a8c0: deadbeef deadbeef deadbeef deadbeef deadbeef deadbeef deadbeef deadbeef
[   20.560000] arm_stackdump: 1083a8e0: deadbeef deadbeef deadbeef deadbeef deadbeef deadbeef deadbeef deadbeef
[   20.560000] arm_stackdump: 1083a900: deadbeef deadbeef deadbeef deadbeef deadbeef deadbeef deadbeef deadbeef
[   20.560000] arm_stackdump: 1083a920: deadbeef deadbeef deadbeef deadbeef deadbeef deadbeef deadbeef deadbeef
[   20.560000] arm_stackdump: 1083a940: deadbeef deadbeef deadbeef deadbeef deadbeef deadbeef deadbeef deadbeef
[   20.560000] arm_stackdump: 1083a960: deadbeef deadbeef deadbeef deadbeef deadbeef deadbeef deadbeef deadbeef
[   20.560000] arm_stackdump: 1083a980: deadbeef deadbeef deadbeef deadbeef deadbeef deadbeef deadbeef deadbeef
[   20.560000] arm_stackdump: 1083a9a0: deadbeef deadbeef deadbeef deadbeef deadbeef deadbeef deadbeef deadbeef
[   20.560000] arm_stackdump: 1083a9c0: deadbeef deadbeef deadbeef deadbeef deadbeef deadbeef deadbeef deadbeef
[   20.560000] arm_stackdump: 1083a9e0: deadbeef deadbeef deadbeef deadbeef deadbeef deadbeef deadbeef deadbeef
[   20.560000] arm_stackdump: 1083aa00: deadbeef deadbeef deadbeef deadbeef deadbeef deadbeef deadbeef deadbeef
[   20.560000] arm_stackdump: 1083aa20: deadbeef deadbeef deadbeef deadbeef deadbeef deadbeef deadbeef deadbeef
[   20.560000] arm_stackdump: 1083aa40: deadbeef deadbeef deadbeef deadbeef deadbeef deadbeef deadbeef deadbeef
[   20.560000] arm_stackdump: 1083aa60: deadbeef deadbeef deadbeef deadbeef deadbeef deadbeef deadbeef deadbeef
[   20.560000] arm_stackdump: 1083aa80: deadbeef deadbeef deadbeef deadbeef deadbeef deadbeef deadbeef deadbeef
[   20.560000] arm_stackdump: 1083aaa0: deadbeef deadbeef deadbeef deadbeef deadbeef deadbeef deadbeef deadbeef
[   20.560000] arm_stackdump: 1083aac0: deadbeef deadbeef deadbeef deadbeef deadbeef deadbeef deadbeef deadbeef
[   20.560000] arm_stackdump: 1083aae0: deadbeef deadbeef deadbeef deadbeef deadbeef deadbeef deadbeef deadbeef
[   20.560000] arm_stackdump: 1083ab00: deadbeef deadbeef deadbeef deadbeef deadbeef deadbeef deadbeef deadbeef
[   20.560000] arm_stackdump: 1083ab20: deadbeef deadbeef deadbeef deadbeef deadbeef deadbeef deadbeef deadbeef
[   20.560000] arm_stackdump: 1083ab40: deadbeef deadbeef deadbeef deadbeef deadbeef deadbeef deadbeef deadbeef
[   20.560000] arm_stackdump: 1083ab60: deadbeef deadbeef deadbeef deadbeef deadbeef deadbeef deadbeef deadbeef
[   20.560000] arm_stackdump: 1083ab80: deadbeef deadbeef deadbeef deadbeef deadbeef deadbeef deadbeef deadbeef
[   20.560000] arm_stackdump: 1083aba0: deadbeef deadbeef deadbeef deadbeef deadbeef deadbeef deadbeef deadbeef
[   20.560000] arm_stackdump: 1083abc0: deadbeef deadbeef deadbeef deadbeef deadbeef deadbeef deadbeef deadbeef
[   20.560000] arm_stackdump: 1083abe0: deadbeef deadbeef deadbeef deadbeef deadbeef deadbeef deadbeef deadbeef
[   20.560000] arm_stackdump: 1083ac00: deadbeef deadbeef deadbeef deadbeef deadbeef deadbeef deadbeef deadbeef
[   20.560000] arm_stackdump: 1083ac20: deadbeef deadbeef deadbeef deadbeef deadbeef deadbeef deadbeef deadbeef
[   20.560000] arm_stackdump: 1083ac40: deadbeef deadbeef deadbeef deadbeef deadbeef deadbeef deadbeef deadbeef
[   20.560000] arm_stackdump: 1083ac60: deadbeef deadbeef deadbeef deadbeef deadbeef deadbeef deadbeef deadbeef
[   20.560000] arm_stackdump: 1083ac80: deadbeef deadbeef deadbeef deadbeef deadbeef deadbeef deadbeef deadbeef
[   20.560000] arm_stackdump: 1083aca0: deadbeef deadbeef deadbeef deadbeef deadbeef deadbeef deadbeef deadbeef
[   20.560000] arm_stackdump: 1083acc0: deadbeef deadbeef deadbeef deadbeef deadbeef deadbeef deadbeef deadbeef
[   20.560000] arm_stackdump: 1083ace0: deadbeef deadbeef deadbeef deadbeef deadbeef deadbeef deadbeef deadbeef
[   20.560000] arm_stackdump: 1083ad00: deadbeef deadbeef deadbeef deadbeef deadbeef deadbeef deadbeef deadbeef
[   20.560000] arm_stackdump: 1083ad20: deadbeef deadbeef deadbeef deadbeef deadbeef deadbeef deadbeef deadbeef
[   20.560000] arm_stackdump: 1083ad40: deadbeef deadbeef deadbeef deadbeef deadbeef deadbeef deadbeef deadbeef
[   20.560000] arm_stackdump: 1083ad60: deadbeef deadbeef deadbeef deadbeef deadbeef deadbeef deadbeef deadbeef
[   20.560000] arm_stackdump: 1083ad80: deadbeef deadbeef deadbeef deadbeef deadbeef deadbeef deadbeef deadbeef
[   20.560000] arm_stackdump: 1083ada0: deadbeef deadbeef deadbeef deadbeef deadbeef deadbeef deadbeef deadbeef
[   20.560000] arm_stackdump: 1083adc0: deadbeef deadbeef deadbeef deadbeef deadbeef deadbeef deadbeef deadbeef
[   20.560000] arm_stackdump: 1083ade0: deadbeef deadbeef deadbeef deadbeef deadbeef deadbeef deadbeef deadbeef
[   20.560000] arm_stackdump: 1083ae00: deadbeef deadbeef deadbeef deadbeef deadbeef deadbeef deadbeef deadbeef
[   20.560000] arm_stackdump: 1083ae20: deadbeef deadbeef deadbeef deadbeef deadbeef deadbeef deadbeef deadbeef
[   20.560000] arm_stackdump: 1083ae40: deadbeef deadbeef deadbeef deadbeef deadbeef deadbeef deadbeef 00000201
[   20.560000] arm_stackdump: 1083ae60: 00000080 1083a7b8 deadbeef 1083ae70 00000200 1083a7b8 1083ae80 10800a77
[   20.560000] arm_stackdump: 1083ae80: deadbeef 00000201 00000080 1083a7b8 1083ae98 1083ae98 00000200 1083a7b8
[   20.560000] arm_stackdump: 1083aea0: 1083aea8 10800a77 1083aeb0 0000000a 00000200 1083a7b8 1083aec0 1082da21
[   20.560000] arm_stackdump: 1083aec0: 0000000a 1083a8a0 1083aed0 1082d7cd 1083aed8 0000000a 00000008 00000001
[   20.560000] arm_stackdump: 1083aee0: 1083aee8 1082d6eb 0000000a 1083afdc 00000038 0000000a 1083af08 10809ab9
[   20.560000] arm_stackdump: 1083af00: deadbeef deadbeef 10836d78 00000000 00000000 1083afdc 0093c000 00000000
[   20.560000] arm_stackdump: 1083af20: 30303030 38303230 00000000 00000000 0004baf0 00000000 1083af40 108060b3
[   20.560000] arm_stackdump: 1083af40: 00000136 00000000 80200000 00000000 06adbeef 00000010 127a3980 00000006
[   20.560000] arm_stackdump: 1083af60: 00000000 00000281 1083af78 1080aa19 1083bac4 108432f0 1083bad8 00000000
[   20.560000] arm_stackdump: 1083af80: 01640000 10845430 1083af90 1082a513 1083afa0 108432f0 10845430 108432f0
[   20.560000] arm_stackdump: 1083afa0: 1083afa8 1083afa8 0193bad8 108432f0 016432f0 019332f0 1083afc0 1083afc0
[   20.560000] arm_stackdump: 1083afc0: 0193bad8 1083bbe8 1083afd0 0193d171 00000000 019332f0 1083afe0 1083afe0
[   20.560000] arm_stackdump: 1083afe0: 1083d5c4 10810b7b 1083d604 00000001 0193beef 00000000 1083b008 00810bf3
[   20.560000] arm_stackdump: 1083b000: 00000001 108432f0 00000001 0000000a 1083b018 1082b1af 1083b020 00000000
[   20.560000] arm_stackdump: 1083b020: 10810bcd 108432f0 1083b030 1082b1c1 1083b038 1082b1e1 1083b040 00d300d3
[   20.560000] arm_stackdump: 1083b040: 00000004 1083b048 1083b050 00d300d3 00000000 1083b058 00d333c0 108432f0
[   20.560000] arm_stackdump: 1083b060: 1083b068 10802db1 00000000 10802a2b 108465c0 108432f0 00000000 1083b0bc
[   20.560000] arm_stackdump: 1083b080: 1083b088 10801531 1083b090 802045d0 108465c0 00000003 1083b0a0 00000000
[   20.560000] arm_stackdump: 1083b0a0: 108432f0 20000060 00000000 108432f0 80204698 108002dc deadbeef 802045d0
[   20.560000] arm_dump_stack: User Stack:
[   20.560000] arm_dump_stack: sp:     80204670
[   20.560000] arm_dump_stack:   base: 10846038
[   20.560000] arm_dump_stack:   size: 000007e0
[   20.560000] arm_dump_stack: ERROR: User Stack pointer is not within the stack
[   20.560000] arm_dump_stack: Kernel Stack:
[   20.560000] arm_dump_stack: sp:     80204670
[   20.560000] arm_dump_stack:   base: 00000000
[   20.560000] arm_dump_stack:   size: 00000c00
[   20.560000] arm_dump_stack: ERROR: Kernel Stack pointer is not within the stack
[   20.560000] arm_showtasks:    PID    PRI      USED     STACK   FILLED    COMMAND
[   20.560000] arm_showtasks:   ----   ----       612      2048    29.8%    irq
[   20.560000] arm_dump_task:      0      0       624      2024    30.8%    Idle Task
[   20.560000] arm_dump_task:      1    224       600      2016    29.7%    hpwork
[   20.560000] arm_dump_task:      2    100       820      2016    40.6%    lpwork
[   20.560000] arm_dump_task:      3    100      2160      3056    70.6%    nfsroot
[   20.560000] arm_dump_task:      4    100       876      2016    43.4%    /mnt/nfs/bin/init
[   20.560000] arm_dump_task:      6    100       876      2016    43.4%    /mnt/nfs/bin/getprime
[   20.560000] arm_dump_task:      7     10      1300      2048    63.4%    pt-0x800012e7

@anchao
Copy link
Contributor Author

anchao commented Mar 1, 2022

I tried this PR with my latest imx6-netknsh branches (https://github.com/masayuki2009/incubator-nuttx/tree/imx6-netknsh https://github.com/masayuki2009/incubator-nuttx-apps/tree/imx6-netknsh) and found that init and hello work but getprime fails when it exits.

@masayuki2009 san,

I can reproduce this issue on your branch but without this PR, seems some wrong with syscall clock_gettime:

apps$ git diff .
diff --git a/testing/getprime/getprime_main.c b/testing/getprime/getprime_main.c
index 7d6b730aa..d0cbd7e10 100644
--- a/testing/getprime/getprime_main.c
+++ b/testing/getprime/getprime_main.c
@@ -181,9 +181,9 @@ int main(int argc, FAR char *argv[])
       ASSERT(0 < n && n <= MAX_THREADS);
     }
 
-  (void)clock_gettime(CLOCK_REALTIME, &ts0);
+  //(void)clock_gettime(CLOCK_REALTIME, &ts0);
   get_prime_in_parallel(n);
-  (void)clock_gettime(CLOCK_REALTIME, &ts1);
+  //(void)clock_gettime(CLOCK_REALTIME, &ts1);
 
   elapsed  = (((uint64_t)ts1.tv_sec * NSEC_PER_SEC) + ts1.tv_nsec);
   elapsed -= (((uint64_t)ts0.tv_sec * NSEC_PER_SEC) + ts0.tv_nsec);

@masayuki2009
Copy link
Contributor

I can reproduce this issue on your branch but without this PR, seems some wrong with syscall clock_gettime:

@anchao
Did you try my branches without your PR?
I think it should work.

@anchao
Copy link
Contributor Author

anchao commented Mar 1, 2022

Did you try my branches without your PR?
I think it should work.

Yes, could you try your latest branch? it seems does not work as expected

incubator-nuttx$ git log  --oneline -5
0689aed6f8 (HEAD, origin/imx6-netknsh) [DO NOT MERGE] sched: Add nfsroot
08d704b888 [DO NOT MERGE] boards: sabre-6quad: Add netknsh
d4c97078c3 arch: imx6: Add the pgheap for imx6
d0356bb9ba (tag: nuttx-20220228-182150) arch/risc-v/qemu-rv: Set FS bits in mstatus
dcafd95971 sched: group: Fix dataabort when exiting task or pthread if ARCH_ADDRENV=y
incubator-nuttx$ qemu-system-arm -net nic -net user,hostfwd=tcp:127.0.0.1:10023-10.0.2.15:23,hostfwd=tcp:127.0.0.1:10021-10.0.2.15:21,hostfwd=tcp:127.0.0.1:15001-10.0.2.15:5001 -M sabrelite -smp 4 -kernel ./nuttx -nographic -m 102
4  
ABDGHIJKNOPQ

NuttShell (NSH) NuttX-10.2.0
nsh> /mnt/nfs/bin/getprime
[   13.750000] arm_undefinedinsn: Undefined instruction at 0x80202750
[   13.750000] up_assert: Assertion failed at file:armv7-a/arm_undefinedinsn.c line: 47 task: /mnt/nfs/bin/getprime
[   13.750000] arm_registerdump: R0: 00000000 R1: 00000000 R2: 00000000  R3: 00000000
[   13.750000] arm_registerdump: R4: 00000000 R5: 00000000 R6: 00000000  FP: 00000000
[   13.750000] arm_registerdump: R8: 00000000 SB: 00000000 SL: 00000000 R11: 00000000
[   13.750000] arm_registerdump: IP: 00000000 SP: 80202728 LR: 10801448  PC: 80202750
[   13.750000] arm_registerdump: CPSR: 80000050
[   13.750000] arm_dump_stack: IRQ Stack:
[   13.750000] arm_dump_stack: sp:     108472f8
[   13.750000] arm_dump_stack:   base: 108395a0
[   13.750000] arm_dump_stack:   size: 00000800
[   13.750000] arm_dump_stack: ERROR: IRQ Stack pointer is not within the stack

@masayuki2009
Copy link
Contributor

Yes, could you try your latest branch? it seems does not work as expected

@anchao

Are you using the latest my apps branch as well?
https://github.com/masayuki2009/incubator-nuttx-apps/tree/imx6-netknsh

It seems that you are using the old version (i.e. non thumb build version).

@anchao
Copy link
Contributor Author

anchao commented Mar 1, 2022

Yes, could you try your latest branch? it seems does not work as expected

@anchao

Are you using the latest my apps branch as well? https://github.com/masayuki2009/incubator-nuttx-apps/tree/imx6-netknsh

It seems that you are using the old version (i.e. non thumb build version).

Yes, apps branch is latest, I reinitialized another repository, but crash still happen.


apps$ git remote -v
origin	https://github.com/masayuki2009/incubator-nuttx-apps/ (fetch)
origin	https://github.com/masayuki2009/incubator-nuttx-apps/ (push)

apps$ git branch -av
* (HEAD detached at origin/imx6-netknsh) 7ef856532 [DO NOT MERGE] hello + malloc test
  av                                     0426c8c09 Fix error: 'strncpy' specified bound 16 equals destination size
  master                                 0426c8c09 [behind 40] Fix error: 'strncpy' specified bound 16 equals destination size
  remotes/origin/HEAD                    -> origin/master
  remotes/origin/cs_test                 06bf57a2f [DO NOT MEGE] testing: Add cstest
  remotes/origin/dev                     0536c5b52 apps/nshlib/nsh_parse.c:  Correct an error found in build testing.  Commit 2a462c78aa5f4ea6dc374eedd86bc85f9f79a0c4 was insufficient.  It was a mistake to revert Xiang's change of commit 9defae8af641752506d92b72ea68c8f94d24d580.  But we are on a different vector now.
  remotes/origin/imx6-netknsh            7ef856532 [DO NOT MERGE] hello + malloc test
  remotes/origin/lc823450-bt             75ac145ea [DO NOT MERGE] Add examples/tinyplay
  remotes/origin/master                  cc156b908 ostest: Introduce basic setjmp/longjmp test
  remotes/origin/workaround              5cf2902ca import: Make.defs: Do not link thumb-based libraries for BUILD_KERNEL

apps$ git log --oneline -5
7ef856532 (HEAD, origin/imx6-netknsh) [DO NOT MERGE] hello + malloc test
aa2c9e7c3 (tag: nuttx-20220228-182150, tag: nuttx-20220228-172202, tag: nuttx-20220228-072218, tag: nuttx-20220228-032219, tag: nuttx-20220228-002322, tag: nuttx-20220227-182149, tag: nuttx-20220227-162159, tag: nuttx-20220227-005222, tag: nuttx-20220226-232302, tag: nuttx-20220226-165129, tag: nuttx-20220226-155126, tag: nuttx-20220226-142200, tag: nuttx-20220226-052231, tag: nuttx-20220226-012258) hello_rust: changes for target support
0baf524de (tag: nuttx-20220226-002251, tag: nuttx-20220225-222151, tag: nuttx-20220225-132214) apps: Modify oneshot example to let users see it working
18609ab1d (tag: nuttx-20220225-122152, tag: nuttx-20220225-112135, tag: nuttx-20220225-045117, tag: nuttx-20220225-032220, tag: nuttx-20220225-022303, tag: nuttx-20220225-002220) mlearning: cmsis: enable FPU support
18b5902a3 (tag: nuttx-20220224-232300) apps/trace: add switch and dump instrumentation

@masayuki2009
Copy link
Contributor

Yes, apps branch is latest, I reinitialized another repository, but crash still happen.

@anchao

Hmm, it's very strange to me.
Can you attach the getprime binary to this PR?

@anchao
Copy link
Contributor Author

anchao commented Mar 1, 2022

Hmm, it's very strange to me.
Can you attach the getprime binary to this PR?

Please check the attachment
bin.zip

@masayuki2009
Copy link
Contributor

Please check the attachment

@anchao

I confirmed that the binaries are slightly different from mine.
Could you tell me the toolchain version?

@anchao
Copy link
Contributor Author

anchao commented Mar 1, 2022

Please check the attachment

@anchao

I confirmed that the binaries are slightly different from mine. Could you tell me the toolchain version?

incubator-nuttx$ arm-none-eabi-gcc -v
Using built-in specs.
COLLECT_GCC=arm-none-eabi-gcc
COLLECT_LTO_WRAPPER=/home/archer/code/l61/ap/prebuilts/gcc/linux/arm/bin/../lib/gcc/arm-none-eabi/10.3.1/lto-wrapper
Target: arm-none-eabi
Configured with: /mnt/workspace/workspace/GCC-10-pipeline/jenkins-GCC-10-pipeline-260_20210727_1627371386/src/gcc/configure --target=arm-none-eabi --prefix=/mnt/workspace/workspace/GCC-10-pipeline/jenkins-GCC-10-pipeline-260_20210727_1627371386/install-native --libexecdir=/mnt/workspace/workspace/GCC-10-pipeline/jenkins-GCC-10-pipeline-260_20210727_1627371386/install-native/lib --infodir=/mnt/workspace/workspace/GCC-10-pipeline/jenkins-GCC-10-pipeline-260_20210727_1627371386/install-native/share/doc/gcc-arm-none-eabi/info --mandir=/mnt/workspace/workspace/GCC-10-pipeline/jenkins-GCC-10-pipeline-260_20210727_1627371386/install-native/share/doc/gcc-arm-none-eabi/man --htmldir=/mnt/workspace/workspace/GCC-10-pipeline/jenkins-GCC-10-pipeline-260_20210727_1627371386/install-native/share/doc/gcc-arm-none-eabi/html --pdfdir=/mnt/workspace/workspace/GCC-10-pipeline/jenkins-GCC-10-pipeline-260_20210727_1627371386/install-native/share/doc/gcc-arm-none-eabi/pdf --enable-languages=c,c++ --enable-plugins --disable-decimal-float --disable-libffi --disable-libgomp --disable-libmudflap --disable-libquadmath --disable-libssp --disable-libstdcxx-pch --disable-nls --disable-shared --disable-threads --disable-tls --with-gnu-as --with-gnu-ld --with-newlib --with-headers=yes --with-python-dir=share/gcc-arm-none-eabi --with-sysroot=/mnt/workspace/workspace/GCC-10-pipeline/jenkins-GCC-10-pipeline-260_20210727_1627371386/install-native/arm-none-eabi --build=x86_64-linux-gnu --host=x86_64-linux-gnu --with-gmp=/mnt/workspace/workspace/GCC-10-pipeline/jenkins-GCC-10-pipeline-260_20210727_1627371386/build-native/host-libs/usr --with-mpfr=/mnt/workspace/workspace/GCC-10-pipeline/jenkins-GCC-10-pipeline-260_20210727_1627371386/build-native/host-libs/usr --with-mpc=/mnt/workspace/workspace/GCC-10-pipeline/jenkins-GCC-10-pipeline-260_20210727_1627371386/build-native/host-libs/usr --with-isl=/mnt/workspace/workspace/GCC-10-pipeline/jenkins-GCC-10-pipeline-260_20210727_1627371386/build-native/host-libs/usr --with-libelf=/mnt/workspace/workspace/GCC-10-pipeline/jenkins-GCC-10-pipeline-260_20210727_1627371386/build-native/host-libs/usr --with-host-libstdcxx='-static-libgcc -Wl,-Bstatic,-lstdc++,-Bdynamic -lm' --with-pkgversion='GNU Arm Embedded Toolchain 10.3-2021.07' --with-multilib-list=rmprofile,aprofile
Thread model: single
Supported LTO compression algorithms: zlib
gcc version 10.3.1 20210621 (release) (GNU Arm Embedded Toolchain 10.3-2021.07)

@masayuki2009
Copy link
Contributor

@anchao

I notice that my toolchain is a little bit old.

 arm-none-eabi-gcc -v
Using built-in specs.
COLLECT_GCC=arm-none-eabi-gcc
COLLECT_LTO_WRAPPER=/opt/gcc-arm-none-eabi-9-2020-q2-update/bin/../lib/gcc/arm-none-eabi/9.3.1/lto-wrapper
Target: arm-none-eabi
Configured with: /mnt/workspace/workspace/GCC-9-pipeline/jenkins-GCC-9-pipeline-200_20200521_1590053374/src/gcc/configure --target=arm-none-eabi --prefix=/mnt/workspace/workspace/GCC-9-pipeline/jenkins-GCC-9-pipeline-200_20200521_1590053374/install-native --libexecdir=/mnt/workspace/workspace/GCC-9-pipeline/jenkins-GCC-9-pipeline-200_20200521_1590053374/install-native/lib --infodir=/mnt/workspace/workspace/GCC-9-pipeline/jenkins-GCC-9-pipeline-200_20200521_1590053374/install-native/share/doc/gcc-arm-none-eabi/info --mandir=/mnt/workspace/workspace/GCC-9-pipeline/jenkins-GCC-9-pipeline-200_20200521_1590053374/install-native/share/doc/gcc-arm-none-eabi/man --htmldir=/mnt/workspace/workspace/GCC-9-pipeline/jenkins-GCC-9-pipeline-200_20200521_1590053374/install-native/share/doc/gcc-arm-none-eabi/html --pdfdir=/mnt/workspace/workspace/GCC-9-pipeline/jenkins-GCC-9-pipeline-200_20200521_1590053374/install-native/share/doc/gcc-arm-none-eabi/pdf --enable-languages=c,c++ --enable-plugins --disable-decimal-float --disable-libffi --disable-libgomp --disable-libmudflap --disable-libquadmath --disable-libssp --disable-libstdcxx-pch --disable-nls --disable-shared --disable-threads --disable-tls --with-gnu-as --with-gnu-ld --with-newlib --with-headers=yes --with-python-dir=share/gcc-arm-none-eabi --with-sysroot=/mnt/workspace/workspace/GCC-9-pipeline/jenkins-GCC-9-pipeline-200_20200521_1590053374/install-native/arm-none-eabi --build=x86_64-linux-gnu --host=x86_64-linux-gnu --with-gmp=/mnt/workspace/workspace/GCC-9-pipeline/jenkins-GCC-9-pipeline-200_20200521_1590053374/build-native/host-libs/usr --with-mpfr=/mnt/workspace/workspace/GCC-9-pipeline/jenkins-GCC-9-pipeline-200_20200521_1590053374/build-native/host-libs/usr --with-mpc=/mnt/workspace/workspace/GCC-9-pipeline/jenkins-GCC-9-pipeline-200_20200521_1590053374/build-native/host-libs/usr --with-isl=/mnt/workspace/workspace/GCC-9-pipeline/jenkins-GCC-9-pipeline-200_20200521_1590053374/build-native/host-libs/usr --with-libelf=/mnt/workspace/workspace/GCC-9-pipeline/jenkins-GCC-9-pipeline-200_20200521_1590053374/build-native/host-libs/usr --with-host-libstdcxx='-static-libgcc -Wl,-Bstatic,-lstdc++,-Bdynamic -lm' --with-pkgversion='GNU Arm Embedded Toolchain 9-2020-q2-update' --with-multilib-list=rmprofile,aprofile
Thread model: single
gcc version 9.3.1 20200408 (release) (GNU Arm Embedded Toolchain 9-2020-q2-update) 

So let me confirm the latest toolchain.

@masayuki2009
Copy link
Contributor

@anchao

I tried the latest toolchain

$ arm-none-eabi-gcc -v
Using built-in specs.
COLLECT_GCC=arm-none-eabi-gcc
COLLECT_LTO_WRAPPER=/opt/gcc-arm-none-eabi-10.3-2021.10/bin/../lib/gcc/arm-none-eabi/10.3.1/lto-wrapper
Target: arm-none-eabi
Configured with: /mnt/workspace/workspace/GCC-10-pipeline/jenkins-GCC-10-pipeline-338_20211018_1634516203/src/gcc/configure --target=arm-none-eabi --prefix=/mnt/workspace/workspace/GCC-10-pipeline/jenkins-GCC-10-pipeline-338_20211018_1634516203/install-native --libexecdir=/mnt/workspace/workspace/GCC-10-pipeline/jenkins-GCC-10-pipeline-338_20211018_1634516203/install-native/lib --infodir=/mnt/workspace/workspace/GCC-10-pipeline/jenkins-GCC-10-pipeline-338_20211018_1634516203/install-native/share/doc/gcc-arm-none-eabi/info --mandir=/mnt/workspace/workspace/GCC-10-pipeline/jenkins-GCC-10-pipeline-338_20211018_1634516203/install-native/share/doc/gcc-arm-none-eabi/man --htmldir=/mnt/workspace/workspace/GCC-10-pipeline/jenkins-GCC-10-pipeline-338_20211018_1634516203/install-native/share/doc/gcc-arm-none-eabi/html --pdfdir=/mnt/workspace/workspace/GCC-10-pipeline/jenkins-GCC-10-pipeline-338_20211018_1634516203/install-native/share/doc/gcc-arm-none-eabi/pdf --enable-languages=c,c++ --enable-plugins --disable-decimal-float --disable-libffi --disable-libgomp --disable-libmudflap --disable-libquadmath --disable-libssp --disable-libstdcxx-pch --disable-nls --disable-shared --disable-threads --disable-tls --with-gnu-as --with-gnu-ld --with-newlib --with-headers=yes --with-python-dir=share/gcc-arm-none-eabi --with-sysroot=/mnt/workspace/workspace/GCC-10-pipeline/jenkins-GCC-10-pipeline-338_20211018_1634516203/install-native/arm-none-eabi --build=x86_64-linux-gnu --host=x86_64-linux-gnu --with-gmp=/mnt/workspace/workspace/GCC-10-pipeline/jenkins-GCC-10-pipeline-338_20211018_1634516203/build-native/host-libs/usr --with-mpfr=/mnt/workspace/workspace/GCC-10-pipeline/jenkins-GCC-10-pipeline-338_20211018_1634516203/build-native/host-libs/usr --with-mpc=/mnt/workspace/workspace/GCC-10-pipeline/jenkins-GCC-10-pipeline-338_20211018_1634516203/build-native/host-libs/usr --with-isl=/mnt/workspace/workspace/GCC-10-pipeline/jenkins-GCC-10-pipeline-338_20211018_1634516203/build-native/host-libs/usr --with-libelf=/mnt/workspace/workspace/GCC-10-pipeline/jenkins-GCC-10-pipeline-338_20211018_1634516203/build-native/host-libs/usr --with-host-libstdcxx='-static-libgcc -Wl,-Bstatic,-lstdc++,-Bdynamic -lm' --with-pkgversion='GNU Arm Embedded Toolchain 10.3-2021.10' --with-multilib-list=rmprofile,aprofile
Thread model: single
Supported LTO compression algorithms: zlib
gcc version 10.3.1 20210824 (release) (GNU Arm Embedded Toolchain 10.3-2021.10) 

Now I can reproduce the crash which you are facing now.
I need to investigate what is happening with gcc 10.3.

[   19.770000] exec_module: Executing /mnt/nfs/bin/getprime
[   19.770000] binfmt_copyargv: args=1 argsize=22
[   19.770000] up_addrenv_select: addrenv=0x10845c94 oldenv=0x10845b50
[   19.770000] up_addrenv_select: text: set l1 entry (paddr=1811e000 vaddr=80000000)
[   19.770000] up_addrenv_select: data: set l1 entry (paddr=18123000 vaddr=80100000)
[   19.770000] up_addrenv_select: heap: set l1 entry (paddr=18125000 vaddr=80200000)
[   19.770000] exec_module: Initialize the user heap (heapsize=1048576)
[   19.770000] up_addrenv_kstackalloc: tcb=0x10845cc0 stacksize=3072
[   19.770000] up_addrenv_clone: src=0x10845c94 dest=0x10845ec8
[   19.770000] up_addrenv_restore: oldenv=0x10845b50
[   19.780000] up_addrenv_select: addrenv=0x10845ec8 oldenv=0
[   19.780000] up_addrenv_select: text: set l1 entry (paddr=1811e000 vaddr=80000000)
[   19.780000] up_addrenv_select: data: set l1 entry (paddr=18123000 vaddr=80100000)
[   19.780000] up_addrenv_select: heap: set l1 entry (paddr=18125000 vaddr=80200000)
[   19.790000] arm_undefinedinsn: Undefined instruction at 0x80202750
[   19.790000] up_assert: Assertion failed at file:armv7-a/arm_undefinedinsn.c line: 47 task: /mnt/nfs/bin/getprime
[   19.790000] arm_registerdump: R0: 00000000 R1: 00000000 R2: 00000000  R3: 00000000
[   19.790000] arm_registerdump: R4: 00000000 R5: 00000000 R6: 00000000  FP: 00000000
[   19.790000] arm_registerdump: R8: 00000000 SB: 00000000 SL: 00000000 R11: 00000000
[   19.790000] arm_registerdump: IP: 00000000 SP: 80202728 LR: 10801448  PC: 80202750

@anchao
Copy link
Contributor Author

anchao commented Mar 1, 2022

Now I can reproduce the crash which you are facing now.
I need to investigate what is happening with gcc 10.3.

That's great! thanks for your time, I will do more test on kernel mode.

@anchao anchao force-pushed the 22022802 branch 3 times, most recently from 09a9999 to 2659327 Compare March 3, 2022 08:11
@anchao anchao force-pushed the 22022802 branch 2 times, most recently from 4fd5645 to 9405df4 Compare March 4, 2022 08:43
@xiaoxiang781216
Copy link
Contributor

@masayuki2009 could you try the update?

@masayuki2009
Copy link
Contributor

@xiaoxiang781216 @anchao

I noticed that lm3s6965-ek:qemu-kostest (QEMU) failed with this PR.

user_main: condition variable test
cond_test: Initializing mutex
cond_test: Initializing cond
cond_test: Starting waiter
cond_test: Set thread 1 priority to 128
waiter_thread: Started
cond_test: Starting signaler
cond_test: Set thread 2 priority to 64
thread_signaler: Started
thread_signaler: Terminating
cond_test: signaler terminated, now cancel the waiter
cond_test: 	Waiter	Signaler
cond_test: Loops	32	32
cond_test: Errors	0	0
cond_test:
cond_test: 0 times, waiter did not have to wait for data
cond_test: 0 times, data was already available when the signaler run
cond_test: 0 times, the waiter was in an unexpected state when the signaler ran

End of test memory usage:
VARIABLE  BEFORE   AFTER
======== ======== ========
arena        7eb0     7eb0
ordblks         1        2
mxordblk     6320     5b00
uordblks     1b90     1b90
fordblks     6320     6320

user_main: pthread_rwlock test
pthread_rwlock: Initializing rwlock
ABCDEF
up_assert: Assertion failed at file:semaphore/sem_wait.c line: 154 task: Idle Task
irq_unexpected_isr: ERROR irq: 3
up_assert: Assertion failed at file:irq/irq_unexpectedisr.c line: 51 task: Idle Task
arm_registerdump: R0: 000004d9 R1: 000004d9 R2: 000004d9  R3: 000004d9
arm_registerdump: R4: 000004d9 R5: 000004d9 R6: 000004d9  FP: 000004d9
arm_registerdump: R8: 000004d9 SB: 000004d9 SL: 000004d9 R11: 000004d9
arm_registerdump: IP: 000004d9 SP: 20000b78 LR: 000004d9  PC: 000004d9
arm_registerdump: xPSR: 000004d9 PRIMASK: 0000011d CONTROL: 00000000
arm_registerdump: EXC_RETURN: 000004d9
arm_dump_stack: User Stack:
arm_dump_stack: sp:     2000a260
arm_dump_stack:   base: 20000790
arm_dump_stack:   size: 000003e8
arm_dump_stack: ERROR: User Stack pointer is not within the stack

@masayuki2009
Copy link
Contributor

@anchao

The original issue with sabre-6quad:netknsh (QEMU) still happens.
You can try the latest my branches with your patches.
Please note that gcc-arm-none-eabi-9-2020-q2-update must be used, because I'm still not sure why the gcc-arm-none-eabi-10.3-2021.10 causes the undefined instruction issue.

[   15.740000] up_addrenv_select: addrenv=0x10843f24 oldenv=0x10847330
[   15.740000] up_addrenv_select: text: set l1 entry (paddr=1811d000 vaddr=80000000)
[   15.740000] up_addrenv_select: data: set l1 entry (paddr=18122000 vaddr=80100000)
[   15.750000] up_addrenv_select: heap: set l1 entry (paddr=18124000 vaddr=80200000)
[   15.750000] exec_module: Initialize the user heap (heapsize=1048576)
[   15.760000] up_addrenv_kstackalloc: tcb=0x10847430 stacksize=3072
[   15.760000] up_addrenv_clone: src=0x10843f24 dest=0x10843fc8
[   15.760000] up_addrenv_restore: oldenv=0x10847330
[   15.770000] up_addrenv_select: addrenv=0x10843fc8 oldenv=0
[   15.770000] up_addrenv_select: text: set l1 entry (paddr=1811d000 vaddr=80000000)
[   15.770000] up_addrenv_select: data: set l1 entry (paddr=18122000 vaddr=80100000)
[   15.770000] up_addrenv_select: heap: set l1 entry (paddr=18124000 vaddr=80200000)
Set thread priority to 10
Set thread policy to SCHED_RR
Start thread #0
[   15.780000] up_addrenv_attach: group=0x10843f80 tcb=0x10847430
[   15.780000] up_addrenv_kstackalloc: tcb=0x108475d0 stacksize=3072
thread #0 started, looking for primes < 10000, doing 10 run(s)
[   17.600000] arm_dataabort: Data abort. PC: 80001bb2 DFAR: 1084361c DFSR: 0000000d
[   17.600000] up_assert: Assertion failed at file:armv7-a/arm_dataabort.c line: 161 task: lpwork
[   17.600000] arm_registerdump: R0: 80204698 R1: 1084360c R2: 80204698  R3: 1084360c
[   17.600000] arm_registerdump: R4: 00000000 R5: 00000000 R6: 00000000  FP: 80204678
[   17.600000] arm_registerdump: R8: 00000000 SB: 00000000 SL: 00000000 R11: 00000000
[   17.600000] arm_registerdump: IP: 10807693 SP: 80204678 LR: 80001725  PC: 80001bb2
...

The text region of the getprime (elf) starts at 0x8000:0000,
So, the PC: 80001bb2 means the offset is 0x1bb2.
It seems that the exception happened in lib_stdoutstream() which is linked with getprime.
As you can see from the register dump, R3: 1084360c shows the address in the kernel area.
That's why the dataabort happened.

Here, r3 is loaded from [r7, #0] and r7 FP: 80204678 shows the address is in the userland heap (i.e. user stack), so this might be correct but its content (i.e. the variable stream) is corrupted.

void lib_stdoutstream(FAR struct lib_stdoutstream_s *outstream,
                      FAR FILE *stream)
{
    1b9a:       b480            push    {r7}
    1b9c:       b083            sub     sp, #12
    1b9e:       af00            add     r7, sp, #0
    1ba0:       6078            str     r0, [r7, #4]
    1ba2:       6039            str     r1, [r7, #0]
  /* Select the put operation */

  outstream->public.put = stdoutstream_putc;
    1ba4:       687a            ldr     r2, [r7, #4]
    1ba6:       f240 0300       movw    r3, #0
                        1ba6: R_ARM_THM_MOVW_ABS_NC     stdoutstream_putc
    1baa:       f2c0 0300       movt    r3, #0
                        1baa: R_ARM_THM_MOVT_ABS        stdoutstream_putc
    1bae:       6013            str     r3, [r2, #0]
   * opened in binary mode.  In binary mode, the newline has no special
   * meaning.
   */

#ifndef CONFIG_STDIO_DISABLE_BUFFERING
  if (stream->fs_bufstart != NULL && (stream->fs_oflags & O_BINARY) == 0)
    1bb0:       683b            ldr     r3, [r7, #0]
    1bb2:       691b            ldr     r3, [r3, #16] <== here
    1bb4:       2b00            cmp     r3, #0
    1bb6:       d00d            beq.n   1bd4 <lib_stdoutstream+0x3a>
    1bb8:       683b            ldr     r3, [r7, #0]
    1bba:       f8b3 3060       ldrh.w  r3, [r3, #96]   ; 0x60
    1bbe:       f403 7380       and.w   r3, r3, #256    ; 0x100
    1bc2:       2b00            cmp     r3, #0
    1bc4:       d106            bne.n   1bd4 <lib_stdoutstream+0x3a>
    {
      outstream->public.flush = stdoutstream_flush;
    1bc6:       687a            ldr     r2, [r7, #4]
    1bc8:       f240 0300       movw    r3, #0
                        1bc8: R_ARM_THM_MOVW_ABS_NC     stdoutstream_flush
    1bcc:       f2c0 0300       movt    r3, #0
                        1bcc: R_ARM_THM_MOVT_ABS        stdoutstream_flush
    1bd0:       6093            str     r3, [r2, #8]
    1bd2:       e005            b.n     1be0 <lib_stdoutstream+0x46>
    }
  else

@anchao
Copy link
Contributor Author

anchao commented Mar 14, 2022

I noticed that lm3s6965-ek:qemu-kostest (QEMU) failed with this PR.

@masayuki2009 san,

There is a issue with the consistency of banked registers in SVC and USR mode. I submitted an separate PR, Please review.

#5734

@anchao
Copy link
Contributor Author

anchao commented Mar 14, 2022

Hi @anchao is it possible to add this test inside apps/testing/ ? So we can compare context switching time between different architectures

Great idea, I'll add the corresponding performance tests later

@anchao anchao force-pushed the 22022802 branch 2 times, most recently from 754e332 to faa86d3 Compare March 14, 2022 18:04
@pkarashchenko
Copy link
Contributor

@masayuki2009 please merge this PR as soon as you confirm that everything is ok on your side.

@masayuki2009
Copy link
Contributor

masayuki2009 commented Mar 15, 2022

@anchao

Did you fix the issue with lm3s6965-ek:qemu-kostest (QEMU) ?
The issue still happens.

$ ~/opensource/QEMU/qemu-5.2/build/arm-softmmu/qemu-system-arm -M lm3s6965evb -nographic -device loader,file=./nuttx.bin,addr=0x00000000 -device loader,file=./nuttx_user.bin,addr=0x00020000
ABCDEF
stdio_test: write fd=1
stdio_test: Standard I/O Check: printf
stdio_test: write fd=2
stdio_test: Standard I/O Check: fprintf to stderr
ostest_main: Started user_main at PID=2
...
End of test memory usage:
VARIABLE  BEFORE   AFTER
======== ======== ========
arena        7eb0     7eb0
ordblks         1        2
mxordblk     6320     5b00
uordblks     1b90     1b90
fordblks     6320     6320

user_main: pthread_rwlock test
pthread_rwlock: Initializing rwlock
ABCDEF
up_assert: Assertion failed at file:semaphore/sem_wait.c line: 154 task: Idle Task
irq_unexpected_isr: ERROR irq: 3
up_assert: Assertion failed at file:irq/irq_unexpectedisr.c line: 51 task: Idle Task
arm_registerdump: R0: 000004c9 R1: 000004c9 R2: 000004c9  R3: 000004c9
arm_registerdump: R4: 000004c9 R5: 000004c9 R6: 000004c9  FP: 000004c9
arm_registerdump: R8: 000004c9 SB: 000004c9 SL: 000004c9 R11: 000004c9
arm_registerdump: IP: 000004c9 SP: 20000b78 LR: 000004c9  PC: 000004c9
arm_registerdump: xPSR: 000004c9 PRIMASK: 0000011d CONTROL: 00000000
arm_registerdump: EXC_RETURN: 000004c9
arm_dump_stack: User Stack:
arm_dump_stack: sp:     2000a260
arm_dump_stack:   base: 20000790
arm_dump_stack:   size: 000003e8
arm_dump_stack: ERROR: User Stack pointer is not within the stack

@anchao
Copy link
Contributor Author

anchao commented Mar 15, 2022

Did you fix the issue with lm3s6965-ek:qemu-kostest (QEMU) ?

No, I am still investigating this issue, update will be later if I have any progress.

The current context save implementation saves registers of each task
to xcp context, which is unnecessary because most of the arm registers are
already saved in the task stack, this commit replace the xcp context with
stack context to improve context switching performance and reduce the tcb
space occupation of tcb instance.

Signed-off-by: chao.an <anchao@xiaomi.com>
Signed-off-by: chao.an <anchao@xiaomi.com>
@anchao
Copy link
Contributor Author

anchao commented Mar 15, 2022

Did you fix the issue with lm3s6965-ek:qemu-kostest (QEMU) ? The issue still happens.

@masayuki2009 san,

In the previous implementation, I did not consider the signal delivery in the interrupt context without interrupt stack,
If signal processing occurs in the interrupt context, we will reserve an area of XCPCONTEXT_SIZE from the current stack as the signal context. However, if the interrupt stack is not enabled, the reserved area on the stack will be overlapped with the interrupt area, which leads to the current issue of lm3s6965-ek:qemu-kostest (CONFIG_ARCH_INTERRUPTSTACK=0)

Therefore, the solution is that if the interrupt stack is disabled, reserve an signal xcpcontext to ensure signal processing can have a separate xcpcontext to handle signal context.

dffd8f6#diff-31f02252f0714ae3f268b632eebec6f1dff7369c6caaa8625fcf597612ecd694R203-R230

	/* If the interrupt stack is disabled, reserve xcpcontext to ensure
	 * that signal processing can have a separate xcpcontext to handle
	 * signal context (reference: arm_schedulesigaction.c):
	 *      ----------------------
	 *     |    IRQ XCP context   |
	 *      -------------------
	 *     |  Signal XCP context  |
	 *      ----------------------   <- SP
	 */

@masayuki2009
Copy link
Contributor

@anchao

In the previous implementation, I did not consider the signal delivery in the interrupt context without interrupt stack,
If signal processing occurs in the interrupt context, we will reserve an area of XCPCONTEXT_SIZE from the current stack as the signal context. However, if the interrupt stack is not enabled, the reserved area on the stack will be overlapped with the interrupt area, which leads to the current issue of lm3s6965-ek:qemu-kostest (CONFIG_ARCH_INTERRUPTSTACK=0)

Thanks for your investigation.
I added +CONFIG_ARCH_INTERRUPTSTACK=2048 to qemu-kostest/defconfig and confirmed it works.

@anchao
Copy link
Contributor Author

anchao commented Mar 15, 2022

Thanks for your investigation. I added +CONFIG_ARCH_INTERRUPTSTACK=2048 to qemu-kostest/defconfig and confirmed it works.

@masayuki2009 san,

In the latest commit set, I also added the signal handling if CONFIG_ARCH_INTERRUPTSTACK=0,
you can verify this PR without lm3s6965-ek:qemu-kostest (CONFIG_ARCH_INTERRUPTSTACK=2048 ) change :)

The following 3 configs works fine with this PR:
sabre-6quad/netknsh (/mnt/nfs/bin/getprime) (CONFIG_ARCH_INTERRUPTSTACK 0 / 2048)
sabre-6quad:smp (ostest) (CONFIG_ARCH_INTERRUPTSTACK 0 / 2048)
lm3s6965-ek:qemu-kostest (ostest) (CONFIG_ARCH_INTERRUPTSTACK 0 / 2048)

@masayuki2009
Copy link
Contributor

@anchao

you can verify this PR without lm3s6965-ek:qemu-kostest (CONFIG_ARCH_INTERRUPTSTACK=2048 ) change :)

Thanks for your comments.
I confirmed that the latest PR works without my commit. :)
So, let me remove the commit.

@masayuki2009
Copy link
Contributor

masayuki2009 commented Mar 17, 2022

@anchao

I noticed that applications such as NTP daemon now consume more stack with this PR.
Is this an intended behaiviour?

The following results are from spresense:wifi_smp.

Without this PR.

   24    24 --- 100 RR       Task    --- Waiting  Signal    00000000 001976 001724  87.2%! NTP daemon 0.pool.ntp.org;1.pool.ntp.org;2.pool.ntp.org

With this PR.

   24    24 --- 100 RR       Task    --- Waiting  Signal    00000000 001976 001940  98.1%! NTP daemon 0.pool.ntp.org;1.pool.ntp.org;2.pool.ntp.org

Please note that spresense:wifi_smp assigns the interrupt stack as follows.

CONFIG_ARCH_INTERRUPTSTACK=2048

@anchao
Copy link
Contributor Author

anchao commented Mar 17, 2022

I noticed that applications such as NTP daemon now consume more stack with this PR. Is this an intended behaiviour?

No, this is not expected behavior, SP is set to the incorrect during up_initial_state():

https://github.com/apache/incubator-nuttx/blob/master/arch/arm/src/armv7-a/arm_initialstate.c#L96

I will raise the fix PR after finish the test case.

@anchao
Copy link
Contributor Author

anchao commented Mar 17, 2022

I noticed that applications such as NTP daemon now consume more stack with this PR. Is this an intended behaiviour?

@masayuki2009 san, please review this PR:
#5774

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants