In the last change, the assert behavior test was not considered. Therefore, in this change, sync will be performed only when SYS_RESTART/SYS_DOWN situation occurs, avoiding unpredictable results caused by handling locks or semaphores in interrupts.
Calling syslog to print logs in clock_gettime will cause the system to have recursive output, i.e., clock_gettime->sinfo->syslog->clock_gettime, with the consequences of stack overflow or non-stop log output.
Some targets, such as qemu-rv support multiple architectures. The required flags need to passed to the linker when built "out-of-tree" in the application directory.
usbdev/usbmsc.c:1758:5: error: conflicting types for 'usbmsc_classobject'; have 'int(void *, struct usbdev_devinfo_s *, struct usbdevclass_driver_s **)'
1758 | int usbmsc_classobject(FAR void *handle,
| ^~~~~~~~~~~~~~~~~~
In file included from /home/raiden00/git/RTOS/nuttx/nuttx/include/nuttx/usb/usbdev.h:36,
from usbdev/usbmsc.c:68:
/home/raiden00/git/RTOS/nuttx/nuttx/include/nuttx/usb/usbmsc.h:173:5: note: previous declaration of 'usbmsc_classobject' with type 'int(void *, struct usbdev_devinfo_s *, struct usbdevclass_driver_s **)'
173 | int usbmsc_classobject(FAR void *handle,
There are number problems with the implementation of realtime signals in NuttX as discussed in Issue #8869. A first step to correcting any of these is to correct the definitions of SIGRTMIN, SIGRTMAX, and RTSIG_SIX.
SIGRTMIN is the first real-time signals. Real-time signal numbers must not overlap the standard signal numbers. Before this fix, it was set equal to the first standard signal. Real-time signals differ from standard signals in that (1) they have no default actions, and (2) real time signal actions are prioritized whereas standard signal actions are processed FIFO.
SIGRTMAX is the last real-time signal.
RTSIG_MAX must be set equal to maximum number of realtime signals reserved for application use
The change corrects the definitons but has not impact at all becasuse none of there definitions are currently used in the OS. But they will be when prioritized real time signal handling is implemented.
arm-none-eabi-gcc 12.2.0 gives the following warnings:
error: 'primask' is used uninitialized
error: 'primask' may be used uninitialized
We use Werror and the file is indirectly included in different
places. I suggest telling the compiler to ignore these warnings
since primask is initialized on the first assembly line.
This is the only problem I encountered so far when upgrading the compiler.
SPI transfers are dynamically determined to use DMA or not.
The flag to judge is removed in a previous simple refactoring commit.
Revert the logic and fix an issue that SPI transfer fails.
1. Enable CONFIG_MMCSD_SDIOWAIT_WRCOMPLETE to use D0 Busy to detect Write Complete
2. Increase bcmf frame pool to 16
3. Increase NET_ETH_PKTSIZE to 1518 to compatible with net MTU
Signed-off-by: chao an <anchao@xiaomi.com>
Choose a divider value that matches the description provided within
the same header file.
Include stddef.h to fix compiler errors because NULL is not defined.
Make logs print protocol, vid and pid consistently, (decimal hex hex).
Decouple the semcount and the work queue length.
Previous Problem:
If a work is queued and cancelled in high priority threads (or queued
by timer and cancelled by another high priority thread) before
work_thread runs, the queue operation will mark work_thread as ready to
run, but the cancel operation minus the semcount back to -1 and makes
wqueue->q empty. Then the work_thread still runs, found empty queue,
and wait sem again, then semcount becomes -2 (being minused by 1)
This can be done multiple times, then semcount can become very small
value. Test case to produce incorrect semcount:
high_priority_task()
{
for (int i = 0; i < 10000; i++)
{
work_queue(LPWORK, &work, worker, NULL, 0);
work_cancel(LPWORK, &work);
usleep(1);
}
/* Now the g_lpwork.sem.semcount is a value near -10000 */
}
With incorrect semcount, any queue operation when the work_thread is
busy, will only increase semcount and push work into queue, but cannot
trigger work_thread (semcount is negative but work_thread is not
waiting), then there will be more and more works left in queue while
the work_thread is waiting sem and cannot call them.
Signed-off-by: Zhe Weng <wengzhe@xiaomi.com>
