Summary:
- This commit fixes global IRQ control logic
- In previous implementation, g_cpu_irqset for a remote CPU was
set in sched_add_readytorun(), sched_remove_readytorun() and
up_schedule_sigaction()
- In this implementation, they are removed.
- Instead, in the pause handler, call enter_critical_setion()
which will call up_cpu_paused() then acquire g_cpu_irqlock
- So if a new task with irqcount > 1 restarts on the remote CPU,
the CPU will only hold a critical section. Thus, the issue such as
'POSSIBLE FOR TWO CPUs TO HOLD A CRITICAL SECTION' could be resolved.
- Fix nxsched_resume_scheduler() so that it does not call spin_clrbit()
if a CPU does not hold a g_cpu_irqset
- Fix nxtask_exit() so that it acquires g_cpu_irqlock
- Update TODO
Impact:
- All SMP implementations
Testing:
- Tested with smp, ostest with the following configurations
- Tested with spresense:wifi_smp (NCPUS=2,4)
- Tested with sabre-6quad:smp (QEMU, dev board)
- Tested with maix-bit:smp (QEMU)
- Tested with esp32-core:smp (QEMU)
- Tested with lc823450-xgevk:rndis
Signed-off-by: Masayuki Ishikawa <Masayuki.Ishikawa@jp.sony.com>
Request the TCP ACK to estimate the receive window after handle
any data already buffered in a read-ahead buffer.
Change-Id: Id998a1125dd2991d73ba4bef081ddcb7adea4f0d
Signed-off-by: chao.an <anchao@xiaomi.com>
Urgent data preceded "normal" data in the TCP payload. If the urgent data is larger than the size of the TCP payload, this indicates that the entire payload is urgent data and that urgent data continues in the next packet.
This case was handled correctly for the case where urgent data was present but was not being handled correctly in the case where the urgent data was NOT present.
Previously only 4 MHz and 8 MHz were allowed. Given the tolerance
allowed in the WS2812 timing spec, frequency ranges around those
two can be used too which is useful for boards in which it is
difficult to generate those specific frequencies.
The following errors are intentionally left.
They are a part of tables which are not trivial to fix.
libs/libc/machine/arm/armv6-m/arch_elf.c:228:94: error: Long line found
libs/libc/machine/arm/armv6-m/arch_elf.c:230:89: error: Long line found
libs/libc/machine/arm/armv6-m/arch_elf.c:238:94: error: Long line found
libs/libc/machine/arm/armv6-m/arch_elf.c:240:89: error: Long line found
libs/libc/machine/arm/armv6-m/arch_elf.c:401:94: error: Long line found
libs/libc/machine/arm/armv6-m/arch_elf.c:403:91: error: Long line found
libs/libc/machine/arm/armv6-m/arch_elf.c:411:94: error: Long line found
libs/libc/machine/arm/armv6-m/arch_elf.c:413:91: error: Long line found
Right now, same as printflike.
Introduce a separate macro because syslog takes
a bit different format from printf. (ie. %m)
If it turns out that a compiler is not happy with
the difference, we can disable this selectively.
