From 87dbd7d52d833a91bd55cd3e24d3ebc9be89455f Mon Sep 17 00:00:00 2001 From: Gregory Nutt Date: Sat, 18 Apr 2020 13:43:36 -0600 Subject: [PATCH] TODO: Remove simulator SMP bug My understanding is the Xiao Xiang has corrected this problem so it should no longer be carried as a bug --- TODO | 67 ++---------------------------------------------------------- 1 file changed, 2 insertions(+), 65 deletions(-) diff --git a/TODO b/TODO index 03b2b7fa60..5daf8438fe 100644 --- a/TODO +++ b/TODO @@ -1,4 +1,4 @@ -NuttX TODO List (Last updated January 3, 2019) +NuttX TODO List (Last updated April 18, 2020) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ This file summarizes known NuttX bugs, limitations, inconsistencies with @@ -27,7 +27,7 @@ nuttx/: (12) File system/Generic drivers (fs/, drivers/) (10) Graphics Subsystem (graphics/) (1) Build system / Toolchains - (3) Linux/Cygwin simulation (arch/sim) + (2) Linux/Cygwin simulation (arch/sim) (5) ARM (arch/arm/) apps/ and other Add-Ons: @@ -2556,69 +2556,6 @@ o Linux/Cygwin simulation (arch/sim) Status: Open Priority: Low - 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. - - 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. I have seen similar such strange behavior - other times that I have tried to use setjmp/longmp from a signal - handler! Like when I tried to implement simulated interrupts - using signals. - - Apparently, if longjmp is invoked from the context of a signal - handler, the result is undefined: - http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1318.htm - - You can enable SMP for ostest configuration by enabling: - - -# CONFIG_EXPERIMENTAL is not set - +CONFIG_EXPERIMENTAL=y - - +CONFIG_SPINLOCK=y - +CONFIG_SMP=y - +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 - +CONFIG_DEBUG_SCHED=y - - -# CONFIG_SCHED_INSTRUMENTATION is not set - +CONFIG_SCHED_INSTRUMENTATION=y - - 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. - - But for example, this command: - - nsh> sleep 1 & - - will execute the sleep command on CPU1 which has worked - every time that I have tried it (which is not too many - times). - - Status: Open - Priority: Low, SMP is important, but SMP on the simulator is not - o ARM (arch/arm/) ^^^^^^^^^^^^^^^