-
Notifications
You must be signed in to change notification settings - Fork 7.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[CRASH][v4.4][ESP32-S3] USB root_port_handle_events() aborts when USB device unplugged (IDFGH-7145) #8748
Comments
I'm hitting this pretty often... But not every time, so might be a race condition. |
I logged every call I make to USBH. In these logs I hit the case where it does not crash, but instead usb_host_uninstall() fails. (Not sure why usb_host_uninstall() is failing. maybe related) Detailed Logs. Plug in midi USB device, then unplug.
|
I just tried not unintializing, leaving USBH fully "up", and doing a few unplugs & replugs. I still hit the same crash after a few tries. |
This was caused by me accidentally modifying and submitting the same It seems worthwhile to guard against improper API usage. Maybe make a copy of the transfer object when we submit. Or keep track of which transfer objects are "live" in some separate array, and throw an error if we try to submit the same object while already "in-flight". Aborting at a "random" place is never very easy to debug. If not worthwhile, feel free to close this. thoughts? |
@chipweinberger I'm hesitant to make a copy of the
IMO the following changes below. Please let me know these look OK.
|
That sounds like a good and easy solution. Btw, after fixing the above issue I mentioned, I recently managed to hit the same abort() again after making some other changes to my shutdown code & inserting and removing the USB device many times. It's on my todo list to debug it further and give you something more actionable. |
@Dazza0, I still sometimes abort in
The abort happens because we are in Do you know why?
|
@chipweinberger Seems like a double HCD Port event. The hub only goes into the However, while hub driver is recovering the root port, there's another
Do you know if this is happening every time you unplug the USB device? Usually, when you first unblock the USB device, a So maybe there's an edge case missing where an @chipweinberger BTW, could you also open a separate Github issue to track this. I want to current issue to track the |
New Issue: #9707 I Answered the questions in that new thread. |
This issue is reserved for tracking the |
This commit adds a simple flag/check in the USB Host Library that prevents users from submitting a transfer that is already inflight. - A transfer is considered inflight as soon as it is submitted by calling usb_host_transfer_submit() or usb_host_transfer_submit_control() - An inflight transfer remains inflight up until right before its callback is called by one of the USB Host Library handler functions. Closes #8748
commit: e17e066 |
This commit adds a simple flag/check in the USB Host Library that prevents users from submitting a transfer that is already inflight. - A transfer is considered inflight as soon as it is submitted by calling usb_host_transfer_submit() or usb_host_transfer_submit_control() - An inflight transfer remains inflight up until right before its callback is called by one of the USB Host Library handler functions. Closes #8748
ESP32-S3
ESP-IDF release/v4.4 (c29343e) from a few days ago.
Edit: this issue is now tracking a new
usb_transfer_t
feature. See #9707 to track the abort.Logs + Backtrace:
Aborts here, in hub.c (in the default case)
The text was updated successfully, but these errors were encountered: