avgoor commented on issue #16133:
URL: https://github.com/apache/nuttx/issues/16133#issuecomment-5367730405
Hi @shtirlic , sorry for late reply, somehow missed the notification.
I've tested several configurations built from `0cbde9ebe` and I'd say it's
now harder to reproduce.
On RISC-V in SMP config with USB NSH or Serial NSH using both `-O0` and
`-O2` the issue is not reproducible after ~30 retries.
On ARM in SMP config with USB NSH or Serial NSH it's not reproduced at
`-O2`, but with `-O0` on some occasions it can be triggered. The trace is a bit
different now:
```
>>> bt
#0 pause_cpu_handler (arg=0x0) at misc/assert.c:632
#1 0x10004b4e in nxsched_smp_call_handler (irq=41, context=0x0, arg=0x0) at
sched/sched_smp.c:131
#2 0x1000163e in rp23xx_smp_call_handler (irq=41, c=0x0, arg=0x0) at
chip/rp23xx_smpcall.c:102
#3 0x10002a34 in irq_dispatch (irq=41, context=0x0) at
irq/irq_dispatch.c:143
#4 0x10001bce in exception_direct () at armv8-m/arm_doirq.c:63
#5 <signal handler called>
#6 0x10001eda in setbasepri (basepri=0) at
nuttx/include/arch/armv8-m/irq.h:344
#7 0x10001f04 in up_irq_enable () at nuttx/include/arch/armv8-m/irq.h:374
#8 0x10001fce in arm_sigdeliver () at armv8-m/arm_sigdeliver.c:105
#9 0x10022968 in up_interrupt_context () at
nuttx/include/arch/armv8-m/irq.h:500
#10 0x00000080 in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
>>> info threads
Index Tid Pid Cpu Thread Info
Frame
0 0 0 0 '\000' Thread 0x200014d0 (Name: CPU0 IDLE, State:
Assigned, Priority: 0, Stack: 1000) 0x10010862 up_idle() at
chip/rp23xx_idle.c:94
1 1 0 1 '\001' Thread 0x200015a8 (Name: CPU1 IDLE, State:
Assigned, Priority: 0, Stack: 1000) 0x10010862 up_idle() at
chip/rp23xx_idle.c:94
3 3 3 0 '\000' Thread 0x20005270 (Name: nsh_main, State:
Waiting,Semaphore, Priority: 100, Stack: 2000) 0x10022c34
nxsem_wait_slow() at semaphore/sem_wait.c:290
10 10 10 0 '\000' Thread 0x200048b8 (Name: ostest, State:
Waiting,Semaphore, Priority: 100, Stack: 2008) 0x10022c34 nxsem_wait_slow() at
semaphore/sem_wait.c:290
11 11 11 0 '\000' Thread 0x20004cc8 (Name: ostest, State:
Waiting,Semaphore, Priority: 100, Stack: 8112) 0x10022c34 nxsem_wait_slow() at
semaphore/sem_wait.c:290
*14 14 11 1 '\001' Thread 0x20008b48 (Name: ostest, State:
Running, Priority: 101, Stack: 8168) 0x1000359c pause_cpu_handler() at
misc/assert.c:632
*15 15 11 0 '\000' Thread 0x2000ac38 (Name: ostest, State:
Running, Priority: 102, Stack: 8168) 0x1000359c pause_cpu_handler() at
misc/assert.c:632
```
Don't really know what a conclusion can be made here. For me it seems there
is still some window when something can get deadlocked during handling of
nested signals and serial I/O the same time, and `-O0` makes this window bigger.
--
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: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
