binfmt_execmodule() calls to sched_releasttcb() was not updated to use the second, thread type parameter
git-svn-id: svn://svn.code.sf.net/p/nuttx/code/trunk@5779 42af7a65-404d-4744-a932-0658087f49c3
This commit is contained in:
parent
a1344d8a44
commit
82b86f9c4a
|
@ -4434,4 +4434,10 @@
|
|||
in the kernel build. The original implementation was C-based
|
||||
and simpler. However, the C code intermixed with SVC calls was
|
||||
not properly preserving registers. The more complex, assembly
|
||||
language version does not suffer from these issues (2013-03-23).
|
||||
language version does not suffer from these issues. I believe
|
||||
the the kernel build can not be called "feature complete"
|
||||
(2013-03-23).
|
||||
* binfmt/binfmt_execmodule.c: Here is a place where I forget
|
||||
to update the call to sched_releasetcb() to pass the thread
|
||||
type as the second parameter (2013-03-23).
|
||||
|
||||
|
|
|
@ -245,10 +245,10 @@ int exec_module(FAR const struct binary_s *binp)
|
|||
errout_with_stack:
|
||||
#ifndef CONFIG_CUSTOM_STACK
|
||||
tcb->cmn.stack_alloc_ptr = NULL;
|
||||
sched_releasetcb(&tcb->cmn);
|
||||
sched_releasetcb(&tcb->cmn, TCB_FLAG_TTYPE_TASK);
|
||||
kufree(stack);
|
||||
#else
|
||||
sched_releasetcb(&tcb->cmn);
|
||||
sched_releasetcb(&tcb->cmn, TCB_FLAG_TTYPE_TASK);
|
||||
#endif
|
||||
goto errout;
|
||||
|
||||
|
|
|
@ -191,8 +191,7 @@ CONFIG_LPC17_GPDMA=y
|
|||
#
|
||||
# SDIO Configuration
|
||||
#
|
||||
# CONFIG_SDIO_DMA=y
|
||||
CONFIG_SDIO_DMAPRIO=0x0
|
||||
# CONFIG_SDIO_DMA is not defined
|
||||
# CONFIG_SDIO_WIDTH_D1_ONLY is not set
|
||||
|
||||
#
|
||||
|
|
|
@ -185,8 +185,7 @@ CONFIG_LPC17_GPDMA=y
|
|||
#
|
||||
# SDIO Configuration
|
||||
#
|
||||
# CONFIG_SDIO_DMA=y
|
||||
CONFIG_SDIO_DMAPRIO=0x0
|
||||
# CONFIG_SDIO_DMA is not defined
|
||||
# CONFIG_SDIO_WIDTH_D1_ONLY is not set
|
||||
|
||||
#
|
||||
|
|
|
@ -57,7 +57,8 @@
|
|||
*
|
||||
* For the same reasons, the maximum size of the SRAM mapping is limited to
|
||||
* 4KB. Both of these alignment limitations could be reduced by using
|
||||
* multiple regions to map the FLASH/SDRAM range.
|
||||
* multiple regions to map the FLASH/SDRAM range or perhaps with some
|
||||
* clever use of subregions.
|
||||
*
|
||||
* A detailed memory map for the 64KB CPU SRAM region is as follows:
|
||||
*
|
||||
|
|
|
@ -58,7 +58,8 @@
|
|||
*
|
||||
* For the same reasons, the maximum size of the SRAM mapping is limited to
|
||||
* 4KB. Both of these alignment limitations could be reduced by using
|
||||
* multiple regions to map the FLASH/SDRAM range.
|
||||
* multiple regions to map the FLASH/SDRAM range or perhaps with some
|
||||
* clever use of subregions.
|
||||
*
|
||||
* A detailed memory map for the 16Kb SRAM region is as follows:
|
||||
*
|
||||
|
|
|
@ -65,7 +65,8 @@
|
|||
*
|
||||
* For the same reasons, the maximum size of the SRAM mapping is limited to
|
||||
* 4KB. Both of these alignment limitations could be reduced by using
|
||||
* multiple regions to map the FLASH/SDRAM range.
|
||||
* multiple regions to map the FLASH/SDRAM range or perhaps with some
|
||||
* clever use of subregions.
|
||||
*
|
||||
* A detailed memory map for the 112KB SRAM region is as follows:
|
||||
*
|
||||
|
|
Loading…
Reference in New Issue