You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@nuttx.apache.org by gn...@apache.org on 2020/04/20 02:02:58 UTC
[incubator-nuttx] 03/04: TODO: Remove simulator SMP bug
This is an automated email from the ASF dual-hosted git repository.
gnutt pushed a commit to branch releases/9.0
in repository https://gitbox.apache.org/repos/asf/incubator-nuttx.git
commit 4817a71d40c127193b12ba8c58299d06cd445ed4
Author: Gregory Nutt <gn...@nuttx.org>
AuthorDate: Sat Apr 18 13:43:36 2020 -0600
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 03b2b7f..5daf843 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/)
^^^^^^^^^^^^^^^