gwbuhl opened a new issue, #20216: URL: https://github.com/apache/nuttx/issues/20216
### Description / Steps to reproduce the issue My apologies if this is not helpful, it my first bug report. Yes, it is AI generated, I've been playing around with adc using ChatGPT. I'm not in anyway a developer, just a guy trying to learn electronics. I hope this is helpful in some way. ## Description On ESP32-C3, repeatedly creating/using/destroying a GDMA-backed ADC interrupt reliably causes a kernel panic on the second cycle. Instrumentation indicates that the NuttX Espressif IRQ handle map retains the previous interrupt handle after teardown. On the next interrupt setup, `esp_set_handle()` returns `-EINVAL` because the old handle is still mapped, but setup continues and the stale handle is returned to the caller. ## Environment - NuttX 13.0.1-RC0 - Revision: `f5df0fcb18-dirty` - ESP32-C3 / RISC-V - Continuous ADC using GDMA - Dirty tree includes ADC development and diagnostic instrumentation ## Reproducer ```text nsh> time "dd if=/dev/adc0 of=/dev/null bs=1024 count=1575" # succeeds nsh> time "dd if=/dev/adc0 of=/dev/null bs=1024 count=1575" # kernel panic ``` ## Key evidence First interrupt allocation: ```text INTR IRQ MAPSET irq=61 ret=0 old/new=0x3fc89d60 INTR IRQ SETUP source=44 irq=61 cpuint=5 ... handle=0x3fc89d60 INTR OS ALLOC source=44 irq=61 cpuint=5 ... handle=0x3fc89d60 ``` Teardown: ```text INTR OS FREE irq=61 cpuint=5 handle=0x3fc89d60 INTR OS BEFORE teardown irq=61 map=0x3fc89d60 INTR OS AFTER teardown irq=61 map=0x3fc89d60 ``` The old handle remains mapped after teardown. Second allocation: ```text INTR IRQ MAPSET irq=61 ret=-22 old/new=0x3fc89d60 INTR IRQ SETUP source=44 irq=61 cpuint=5 ... handle=0x3fc89c88 INTR OS ALLOC source=44 irq=61 cpuint=5 ... handle=0x3fc89d60 ``` A new interrupt handle (`0x3fc89c88`) was allocated, but `esp_set_handle()` returned `-EINVAL` because the old mapping (`0x3fc89d60`) remained. The failure is not propagated, and `esp_os_intr_alloc_intrstatus()` subsequently returns the old mapped handle. I also instrumented the GDMA RX ISR and directly observed an ISR from the previous channel allocation executing during the second allocation: ```text GDMA DBG install rx=0x3fc89d70 ... GDMA DBG install rx=0x3fc89c98 ... GDMA CORRUPTION rx expected=0x3fc89c98 actual=0x3fc89d70 ``` Without the diagnostic guard this results in a load access fault in the GDMA RX interrupt path. ## Relevant code `arch/risc-v/src/common/espressif/esp_irq.c`: - `esp_setup_irq_with_flags_intrstatus()` - `esp_set_handle()` - `esp_teardown_irq()` `arch/risc-v/src/esp32c3/esp-hal-3rdparty/nuttx/src/platform/os.c`: - `esp_os_intr_alloc_intrstatus()` - `esp_os_intr_free()` In particular, the return value from `esp_set_handle()` is currently ignored. ## Expected behavior After interrupt teardown, the old IRQ mapping and ISR context should no longer be usable. A subsequent allocation of the same interrupt should successfully install and return the newly allocated handle. I can test patches on ESP32-C3 and provide the full panic/instrumentation log if useful. ### On which OS does this issue occur? [OS: Mac] ### What is the version of your OS? Mac OS 14.5 ### NuttX Version NuttX 13.0.1-RC0 ### Issue Architecture [Arch: risc-v] ### Issue Area [Area: Memory Management], [Area: Drivers] ### Host information _No response_ ### Verification - [x] I have verified before submitting the report. -- 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]
