-
Notifications
You must be signed in to change notification settings - Fork 5k
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
USB webcam device disconnects don't trigger the associated kernel disconnect processing #3546
Comments
It's related to suspend processing. If I disable global autosuspend, the webcam gadget is correctly detected as disconnected when unplugged. Downstream USB2.0 hubs can also trigger this issue, as they are automatically put in suspend by Linux if there are no attached devices. Unable to replicate the same behaviour on a Pi 2. I am also unable to replicate this issue if I force a device (e.g. a mouse) to be suspended by unbinding the driver and changing the associated bus power control to "auto" - verified that the device was in suspend, then unplugged it - disconnect was detected. |
Git bisect on firmware and this is the first bad commit:
Last good commit;
|
The downstream patches look harmless. |
This upstream commit doesn't:
And lo, reverting it results in a suspended hub being properly detected as disconnected when unplugged. |
Given that this is code common to all USB2 hubs, and we've not had much downstream fiddling done to this part of the Linux stack, I wonder if this is an issue on x86 as well. |
…sume" This reverts commit e5d078a. On Pi 4, an upstream kernel change resulted in disconnect events not being registered by the kernel when a suspended device was unplugged. Devices that get autosuspended by default (hubs and webcams) would remain "stuck" in the kernel's list of attached devices, leading to a nonresponsive port. Reverting this commit fixes the issue. See raspberrypi#3546 Signed-off-by: Jonathan Bell <[email protected]>
…sume" This reverts commit e5d078a. On Pi 4, an upstream kernel change resulted in disconnect events not being registered by the kernel when a suspended device was unplugged. Devices that get autosuspended by default (hubs and webcams) would remain "stuck" in the kernel's list of attached devices, leading to a nonresponsive port. Reverting this commit fixes the issue. See #3546 Signed-off-by: Jonathan Bell <[email protected]>
…sume" This reverts commit e5d078a. On Pi 4, an upstream kernel change resulted in disconnect events not being registered by the kernel when a suspended device was unplugged. Devices that get autosuspended by default (hubs and webcams) would remain "stuck" in the kernel's list of attached devices, leading to a nonresponsive port. Reverting this commit fixes the issue. See #3546 Signed-off-by: Jonathan Bell <[email protected]>
…sume" This reverts commit e5d078a. On Pi 4, an upstream kernel change resulted in disconnect events not being registered by the kernel when a suspended device was unplugged. Devices that get autosuspended by default (hubs and webcams) would remain "stuck" in the kernel's list of attached devices, leading to a nonresponsive port. Reverting this commit fixes the issue. See #3546 Signed-off-by: Jonathan Bell <[email protected]>
…sume" This reverts commit e5d078a. On Pi 4, an upstream kernel change resulted in disconnect events not being registered by the kernel when a suspended device was unplugged. Devices that get autosuspended by default (hubs and webcams) would remain "stuck" in the kernel's list of attached devices, leading to a nonresponsive port. Reverting this commit fixes the issue. See #3546 Signed-off-by: Jonathan Bell <[email protected]>
kernel: Revert USB: hub: Don't record a connect-change event during reset-resume See: raspberrypi/linux#3546 firmware: arm_loader: Make 4GB available if arm_peri_high firmware: arm_loader: Complete arm_peri_high support See: #1374 firmware: board_info: Split Model B into rev1 and rev2 See: raspberrypi/linux#3537
kernel: Revert USB: hub: Don't record a connect-change event during reset-resume See: raspberrypi/linux#3546 firmware: arm_loader: Make 4GB available if arm_peri_high firmware: arm_loader: Complete arm_peri_high support See: raspberrypi/firmware#1374 firmware: board_info: Split Model B into rev1 and rev2 See: raspberrypi/linux#3537
…sume" This reverts commit e5d078a. On Pi 4, an upstream kernel change resulted in disconnect events not being registered by the kernel when a suspended device was unplugged. Devices that get autosuspended by default (hubs and webcams) would remain "stuck" in the kernel's list of attached devices, leading to a nonresponsive port. Reverting this commit fixes the issue. See #3546 Signed-off-by: Jonathan Bell <[email protected]>
kernel: Revert USB: hub: Don't record a connect-change event during reset-resume See: raspberrypi/linux#3546 firmware: arm_loader: Make 4GB available if arm_peri_high firmware: arm_loader: Complete arm_peri_high support See: raspberrypi/firmware#1374 firmware: board_info: Split Model B into rev1 and rev2 See: raspberrypi/linux#3537
Did the commit you made solve the issue, I see it's still an open issue? |
The commit reverts an upstream change. The upstream regression was eventually noticed (and fixed properly), making the downstream fix redundant. |
Seen on latest 4.19 and rpi-update 5.4 on a Pi 4B.
Steps to reproduce: Configure a Pi Zero as a USB gadget webcam (legacy g_webcam was used). Plug the device in to any hub port while running the uvc-video script.
Disconnect the Pi Zero
Swap g_webcam for g_ether -> disconnect is registered correctly.
Swap g_webcam for g_cdc -> disconnect is registered correctly.
I can provoke a disconnect when using g_webcam if it is unplugged before this uvcvideo trace message appears about suspending the interface:
So there is a critical window in which the device behaves normally.
If I have a port in the "dead" state, i.e. one which previously had a g_webcam Pi Zero attached, and was unplugged outside of the critical window, then unplugging a Pi Zero webcam from a different port results in two disconnect messages - one for the dead port and one for the webcam.
The text was updated successfully, but these errors were encountered: