diff --git a/TODO b/TODO index 5d24888828..54fb00ef5b 100644 --- a/TODO +++ b/TODO @@ -1609,26 +1609,19 @@ o Linux/Cywgin simulation (arch/sim) Status: Open Priority: Low - Title: SMP SIMULATION INCOMPLETE + Title: SMP SIMULATION ISSUES Description: The configuration has basic support SMP testing. The simulation supports the emulation of multiple CPUs by creating multiple pthreads, each run a copy of the simulation in the same process address space. - The simulation SMP implemention is incomplete, however. Two - critical SMP functions are not implemented: + At present, the SMP simulation is not fully functional: It does + operate on the simulated CPU threads for a few context switches + then fails during a setjmp() operation. I suspect that this is + not an issue with the NuttX SMP logic but more likely some chaos + in the pthread controls. - - int up_cpu_pause(void) - - int up_cpu_resume(void) - - These are used to start a new task on a different CPU: (1) - the other CPU is stopped or paused, (2) the OS datastructures - for that CPU are modified, then (2) the other CPU is resumed. - Unfortunately, I have not yet thought of a way to implement - them in the simulation. - - Currently, for example, you can enable SMP for ostest - configuration by enabling: + You can enable SMP for ostest configuration by enabling: -# CONFIG_EXPERIMENTAL is not set +CONFIG_EXPERIMENTAL=y @@ -1638,6 +1631,13 @@ o Linux/Cywgin simulation (arch/sim) +CONFIG_SMP_NCPUS=2 +CONFIG_SMP_IDLETHREAD_STACKSIZE=2048 + You also must enable near-realtime-performance otherwise even long + timeouts will expire before a CPU thread even has a chance to + execute. + + -# CONFIG_SIM_WALLTIME is not set + +CONFIG_SIM_WALLTIME=y + And you can enable some additional debug output with: -# CONFIG_DEBUG_SCHED is not set @@ -1646,73 +1646,24 @@ o Linux/Cywgin simulation (arch/sim) -# CONFIG_SCHED_INSTRUMENTATION is not set +CONFIG_SCHED_INSTRUMENTATION=y - The result should be as follows: + The NSH configuration can also be forced to run SMP, but + suffers from the same quirky behavior. I can be made + reliable if you modify arch/sim/src/up_idle.c so that + the IDLE loop only runs for CPU0. Otherwise, often + simuart_post() will be called from CPU1 and it will try + to restart NSH on CPU0 and, again, the same quirkiness + occurs. - - CPU0 initializes and starts CPU1. CPU1 is running an - executing the IDLE task. + But for example, this command: - os_start: Entry - os_idletask: CPU1: Beginning Idle Loop + nsh> sleep 1 & - - CPU0 brings up the the OS test application on CPU0 + will execute the sleep command on CPU1 which has worked + every time that I have tried it (which is not too many + times). - os_do_appstart: Starting init thread - CPU0: Start init, TCB@42f490, state=5 - up_unblock_task: Unblocking TCB=42f490 - CPU0: Suspend CPU0 IDLE, TCB@42c180, state=4 - CPU0: Resume init, TCB@42f490, state=0 - up_unblock_task: New Active Task TCB=42f490 - - - OS test runs and performs some basic checks. - - 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: putenv(Variable1=BadValue3) - - up_block_task: Blocking TCB=42f490 - CPU0: Suspend init, TCB@42f490, state=4 - CPU0: Resume CPU0 IDLE, TCB@42c180, state=3 - up_block_task: New Active Task TCB=42c180 - up_unblock_task: Unblocking TCB=42f490 - CPU0: Suspend CPU0 IDLE, TCB@42c180, state=4 - CPU0: Resume init, TCB@42f490, state=0 - up_unblock_task: New Active Task TCB=42f490 - - ostest_main: setenv(Variable1, GoodValue1, TRUE) - ostest_main: setenv(Variable2, BadValue1, FALSE) - ostest_main: setenv(Variable2, GoodValue2, TRUE) - ostest_main: setenv(Variable3, Variable3, FALSE) - ostest_main: setenv(Variable3, Variable3, FALSE) - show_variable: Variable=Variable1 has value=GoodValue1 - show_variable: Variable=Variable2 has value=GoodValue2 - show_variable: Variable=Variable3 has value=GoodValue3 - - - Then OS test tries to start the task ostest on CPU1 - - CPU0: Start ostest, TCB@430e90, state=5 - up_unblock_task: Unblocking TCB=430e90 - CPU1: Suspend CPU1 IDLE, TCB@42c2c0, state=4 - CPU0: Resume ostest, TCB@430e90, state=0 - ostest_main: Started user_main at PID=4 - - There is no failure but, of course, the task on CPU1 does not - run, i.e., it does not replace the IDLE task running on CPU1. - - 2016-02-16: The NSH configuration can be forced to run, but - only if (1) You don't try to execute built-in commands or to - execute commands in the background. Those thoses cases, it - will try to start the command on CPU1 and the same problem - as for the ostest case occurs. - - Also, for NSH you have to modify arch/sim/src/up_idle.c so - that the IDLE loop only runfs for CPU0. Otherwise, often - simuart_post() will be called from CPU1 and it will try to - restart NSH on CPU0 and, again, the same problem occurs. - - 2016-02-18: There is an initial implementation based on - signals and signal handling, but this is not yet functional. + Status: Open + Priority: Low, SMP is important, but SMP on the simulator is not o ARM (arch/arm/) ^^^^^^^^^^^^^^^ diff --git a/arch b/arch index 689e18739d..6586d3eb74 160000 --- a/arch +++ b/arch @@ -1 +1 @@ -Subproject commit 689e18739d4dc9d5238dd4b74e88792cfc1ec2e1 +Subproject commit 6586d3eb74044666941bb29d1fd3eceee8d57483 diff --git a/configs b/configs index 7b89b3ddfa..4127469e4f 160000 --- a/configs +++ b/configs @@ -1 +1 @@ -Subproject commit 7b89b3ddfab4fc733a81bca8db5f0277e72535de +Subproject commit 4127469e4f06fcfc21610df669337a9552165ca7