summaryrefslogtreecommitdiff
path: root/nuttx/ChangeLog
diff options
context:
space:
mode:
authorpatacongo <patacongo@42af7a65-404d-4744-a932-0658087f49c3>2013-01-13 00:35:47 +0000
committerpatacongo <patacongo@42af7a65-404d-4744-a932-0658087f49c3>2013-01-13 00:35:47 +0000
commit0d8a269d4bbb18fa509e642ae2eaec8a8c80a1c3 (patch)
treef74938699bd760dbbba52578827f5e100d7b3700 /nuttx/ChangeLog
parent499c8c86de6757b39eaaf0f2b96a5b070f085b9b (diff)
downloadnuttx-0d8a269d4bbb18fa509e642ae2eaec8a8c80a1c3.tar.gz
nuttx-0d8a269d4bbb18fa509e642ae2eaec8a8c80a1c3.tar.bz2
nuttx-0d8a269d4bbb18fa509e642ae2eaec8a8c80a1c3.zip
Cosmetic cleanup from SIGCHLD changes
git-svn-id: svn://svn.code.sf.net/p/nuttx/code/trunk@5514 42af7a65-404d-4744-a932-0658087f49c3
Diffstat (limited to 'nuttx/ChangeLog')
-rw-r--r--nuttx/ChangeLog2
1 files changed, 1 insertions, 1 deletions
diff --git a/nuttx/ChangeLog b/nuttx/ChangeLog
index 921b7014b..7deb9fa94 100644
--- a/nuttx/ChangeLog
+++ b/nuttx/ChangeLog
@@ -3918,7 +3918,7 @@
the scenario: (1) sched_lock() is called increments the lockcount
on the current TCB (i.e., the one at the head of the ready to run
list), (2) sched_mergepending is called which may change the task
- at the head of the readytorun list, then (2) sched_lock() is called
+ at the head of the readytorun list, then (2) sched_unlock() is called
which decrements the lockcount on the wrong TCB. The failure case
that I saw was that pre-emption got disabled in the IDLE thread,
locking up the whole system.