tmedicci commented on PR #8926:
URL: https://github.com/apache/nuttx/pull/8926#issuecomment-1490132654
Hi @masayuki2009 ,
Thanks for testing it on other architectures!
On Xtensa, specifically, the crash occurs only when the task is executing on
the other core. Possibly this is not the situation `ostest` tests because the
`waiter_main` will be waiting for a semaphore. Although it's important to
assure that `ostest` run properly.
I'd suggest you apply this patch on `nuttx-apps`:
```
diff --git a/examples/alarm/alarm_main.c b/examples/alarm/alarm_main.c
index 74c5e8fc60..fa8abf04cf 100644
--- a/examples/alarm/alarm_main.c
+++ b/examples/alarm/alarm_main.c
@@ -125,12 +125,6 @@ static int alarm_daemon(int argc, FAR char *argv[])
g_alarm_received[i] = false;
}
}
-
- /* Now wait a little while and poll again. If a signal is received
- * this should cause us to awken earlier.
- */
-
- usleep(500 * 1000L);
}
errout:
```
That will force a core to run the task in an infinite loop and the signal
handler would need to interrupt this task to deliver the singal. Build & run
the `EXAMPLES_ALARM` app:
```
nsh> alarm 2
alarm_daemon started
alarm_daemon: Running
Opening /dev/rtc0
Alarm 0 set in 2 seconds
nsh> alarm_daemon: alarm 0 received
```
This is the result on xtensa/esp32 after applying the patch on this MR.
Prior to this, it was crashing while executing `up_irq_restore(flags)` on
[`leave_critical_section`](https://github.com/apache/nuttx/blob/632d87ee71a6e7a6dd1ac768690cf481313befc4/sched/irq/irq_csection.c#L588)
That makes sense for Xtensa: the original context (included would need to be
restored only after all signal handling.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscr...@nuttx.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
