tinyusb
tinyusb copied to clipboard
hathach
Panic on host usb device connect/disconnect
Operating System
Linux
Board
pimoroni_tiny2040
Firmware
Simple host example using printf to show "attach / "detach message on callbacks.
The single additional difference was using tuh_vid_pid_get() to also print the VID:PID on attach (but nothing else on detach).
The tinyUSB library version in use was unmodified "0.13.0" source tag.
What happened ?
In certain situations it is possible to make the TinyUSB library to panic with:
Device attached, address = 1
Device VID: 10C4h PID: EA60h
Device removed, address = 1
*** PANIC ***
Invalid speed
The call stack can be seen here:
How to reproduce ?
Can be reproduced by slowly insert and remove the USB device until the panic occurs.
In my view it seems to be a race condition between the handling of the new device and being disconnected (or not having a stable connection) when reading the SIE_STATUS register.
As this happens in real life it needs to be handled. Panic should only be used for critical internal errors where there is no chance of recovery, not normal behavior where we also break the user task.
Debug Log as txt file
No response
Screenshots
No response
Just to add I may attempt to create a fix tomorrow, but today is already too late in the night for me.
make sure you use the latest on github since issue may be fixed already since 0.13.0
make sure you use the latest on github since issue may be fixed already since 0.13.0
I did notice the panic is still present on the latest code, but the return value was removed as the panic function does not return. Did not have time today to continue on this. Too much real work...
look like a race condition, can you provide link to compilable project, similar to the example one for reproducing.
My mistake when I checked head. Was looking at the head of a more recent branch, not master HEAD.
With current HEAD (d23c9b7) the panic does not happen anymore. It seems it was fixed. On the other hand, a race condition seems to be still happening if you try to slowly detach and attach a device several times. Eventually an ASSERT is raised on each new attach:
Device attached, address = 1
Device removed, address = 1
Device attached, address = 1
Device removed, address = 1
Device attached, address = 1
Device removed, address = 1
Device attached, address = 1
Device removed, address = 1
Device attached, address = 1
Device removed, address = 1
Device attached, address = 1
Device removed, address = 1
Device attached, address = 1
Device removed, address = 1
Device attached, address = 1
Device removed, address = 1
Device attached, address = 1
Device removed, address = 1
Device attached, address = 1
Device removed, address = 1
Device attached, address = 1
Device removed, address = 1
process_enumeration 1271: ASSERT FAILED
process_enumeration 1271: ASSERT FAILED
process_enumeration 1271: ASSERT FAILED
My guess is that the internal logic is not checking on attach if there are devices where the setup process was not finished before being forcibly removed and resources are not deallocated after such an event.
Not sure if this issue should be closed and another one opened as it is a different case. I'll create a minimum test program to check again.
With a clean project [1] I got a panic on a different place when slowly inserting and removing the same device:
...
Device attached, address = 1
Device removed, address = 1
Device attached, address = 1
Device removed, address = 1
Device removed, address = 1
*** PANIC ***
ep 0 in was already available
But I lost the call stack on this attempt, which seems to be a new problem as we have the umount callback called twice in a row.
Repeating the test, got the same assert:
...
Device attached, address = 1
Device removed, address = 1
process_enumeration 1271: ASSERT FAILED
This seems to be a bit too much for me to step in with a fix as I don't have that much time and don't know my way around the code, but I'll do what I can when I can.
I get this error, even with current git HEAD. For some devices (including hub) consistently each time the device is disconnected, for other occasionally, but still often. And the PANIC makes whole device inoperable – a library should behave much more robust, even in unexpected conditions.
