For the case when the watchdog is triggering a timeout we did not
correctly reset the GPIO_SDIO_D0.
Without this fix, the SD card can become inaccessible.
It turns out there is no difference in these two files as well as the
reference manual for the registers between the two parts, so it probably
makes sense to unify them
1.fix crash casued by closing the handle during the reading.
2.fix set_interval fail sometime:When fakesensor was activated, csv file is not opened timely, so
the sensor->interval that set_interval() seted will be coverd by
interval form csv file.
Signed-off-by: buyuer <dingddding@163.com>
Documentation/reference/os/wqueue.rst:
* CONFIG_SIG_SIGWORK: Fix sentence that was cut off in the
middle.
include/signal.h:
* SIGWORK: Fix grammar in comment.
sched/Kconfig:
* config SIG_SIGWORK: Fix ---help--- text to indicate that
this user-configured signal number may be used by various
internal worker threads.
since the unwinder not only work with arm but also other arch(e.g. riscv)
Signed-off-by: Xiang Xiao <xiaoxiang@xiaomi.com>
Change-Id: I56cc54f2c99560c858362ab2dfba524097385716
This fixes connection closing issues with CONFIG_NET_TCP_WRITE_BUFFERS.
Because TCP_CLOSE is used for both of input and output for tcp_callback,
the close callback and the send callback confuses each other as
the following. As it effectively disposes the connection immediately,
we end up with responding to the consequent ACK and FIN/ACK from the peer
with RSTs.
tcp_timer
-> tcp_close_eventhandler
returns TCP_CLOSE (meaning an active close)
-> psock_send_eventhandler
called with TCP_CLOSE from tcp_close_eventhandler, misinterpet as
a passive close.
-> tcp_lost_connection
-> tcp_shutdown_monitor
-> tcp_callback
-> tcp_close_eventhandler
misinterpret TCP_CLOSE from itself as
a passive close
The current code just leave the window value from the segment
from the peer. It doesn't make sense.
Instead, always use 0.
This matches what NetBSD and Linux do.
(As far as I read their code correctly.)
* It doesn't make sense to have this conditional on our own
SO_KEEPALIVE support. (CONFIG_NET_TCP_KEEPALIVE)
Actually we don't have a control on the peer tcp stack,
who decides to send us keep-alive probes.
* We should respond them for non ESTABLISHED states. eg. FIN_WAIT_2
See also:
https://github.com/apache/incubator-nuttx/pull/3919#issuecomment-868248576
Do not bother to preserve segment boundaries in the tcp
readahead queues.
* Avoid wasting the tail IOB space for each segments.
Instead, pack the newly received data into the tail space
of the last IOB. Also, advertise the tail space as
a part of the window.
* Use IOB chain directly. Eliminate IOB queue overhead.
* Allow to accept only a part of a segment.
* This change improves the memory efficiency.
And probably more importantly, allows less-confusing
recv window advertisement behavior.
Previously, even when we advertise N bytes window,
we often couldn't actually accept N bytes. Depending on
the segment sizes and IOB configurations, it was causing
segment drops.
Also, the previous code was moving the right edge of the
window back and forth too often, even when nothing in
the system was competing on the IOBs. Shrinking the
window that way is a kinda well known recipe to confuse
the peer stack.
I plan to use a simple IOB chain w/o IOB queue for tcp recv buffers.
for large configurations, uint16_t is not large enough to represent
the entire socket buffer.
* Move the code to advance rcvseq for user data from tcp_input
to receive handlers.
Motivation: allow partial ack.
* If we drop a segment, ignore FIN as well. Note than tcp FIN bit is
logically after the user data in the same segment.
Summary:
- I noticed that NFS over TCP does not work correctly when
it tried to reconnect to the NFS server.
- This commit fixes this issue
Impact:
- gs2200m only
Testing:
- Tested with spresense:wifi_smp
- NOTE: need to update gs2200m_main.c
Signed-off-by: Masayuki Ishikawa <Masayuki.Ishikawa@jp.sony.com>
Summary:
- I noticed that an NFS connection is automatically dropped.
- Actually, this happens in TCP mode if no traffic happens
for 600 seconds.
- I confirmed that the NFS client on Ubuntu automatically
reconnects to the NFS server when an RPC call failed.
- This commit adds the same behavior to fix the issue.
Impact:
- NFS client in TCP mode
Testing:
- Tested with spresense:rndis_smp
Signed-off-by: Masayuki Ishikawa <Masayuki.Ishikawa@jp.sony.com>
* it wasn't intended.
* it doesn't always work:
(gdb) source tools/esp32/backtrace.gdbscript
(gdb) esp32_bt 0x40139706 0x80139811 0x3ffafd40
Attempt to assign to an unmodifiable value.
(gdb)
