usb.reset fails on Google Pixel
Reported by
k...@karelbilek.com,
Mar 8 2018
|
||||||
Issue descriptionSteps to reproduce the problem: 1. Connect webusb device (trezor in my case) to Pixel phone 2. run device.open and device.reset() 3. device.reset always returns a rejecting promise on Google Pixel See the attached file. Everything from line 55 forward is related to Trezor; however, the bug happens before, on line 46. (And then again on line 81, if the line 46 is commented out.) However, it doesn't seem to be related to trezor; we tried trezor 1 with webusb support and trezor t and both behave identically despite having different codebase. (And only on Pixel.) I have not tried the arduino experiments because I don't currently have Adruino board; if necessary, I will buy one and try to replicate it there. What is the expected behavior? device.reset resets the device What went wrong? See steps Did this work before? N/A Does this work in other browsers? N/A Chrome version: 65.0.3321.144 Channel: beta OS Version: 8.1.0 Flash Version: This happens only on Google Pixel phone. All the details I can find: * Chrome Beta 65.0.3325.144 (stable has webusb turned off) * model Pixel, hw version PVT * android version 8.1.0 * kernel version 3.18.70-g674349727b4e (gcc version 4.9.x-google 20140827 (prerelease) (GCC) ) android-build@wpef28.hot.corp.google.com The same does not happen on Nexus 5, and Xiaomi A1 Android One, which both should have "pure" android. Webusb also has further more serious issues on the device - device that should be connected often show up as disconnected with NotFound error - however, I have not been able to reliably replicate them and reduce them to a small testable case. I hope fixing the reset will also fix the other issues, because they seem to be connected.
,
Mar 8 2018
Yes, the device.reset both fails, and disconnects for a few milliseconds the device, which is then showing as a new device.
,
Mar 8 2018
The kernel is supposed to block and wait for the device to reappear on the bus, assigning it the same ID however it is possible that on this hardware this either takes too long or there is another bug in the HCD driver causing this matching to fail. Can you capture an Android bug report on this device? I believe this will contain the system kernel log.
,
Mar 8 2018
I am currently not an admin on the device, so I will have to wait until I have access to allow developer options :( Anyway when I turned on "Debug" level in the device-log, I noticed those two messages > Failed to reset the device: No such device > Failed to reap urbs: No such device Which happen before the disconnect and reconnect.
,
Mar 8 2018
Chrome uses the USBDEVFS_RESET ioctl to reset the device: https://chromium.googlesource.com/chromium/src/+/865c49d682a30aa8b88e6b18a2a8359d4a537a17/device/usb/usb_device_handle_usbfs.cc#291
,
Mar 8 2018
Unfortunately I will not have the Pixel phone again until monday, so I cannot run the debugger now. I am trying on all other Android phones I have, but it works on all of them except for the Pixel.
,
Mar 14 2018
Karel, have you had an opportunity to collect a bug report from the Pixel phone?
,
Mar 15 2018
I will need a little help here, since I am not an Android dev. I have tried to replicate the bug and then I ran `adb bugreport here.log` with the connected device, and it made something in the here.log.zip file. I am not sure which of the archive is relevant to this and which is not (I don't want to send any private info publicly, since it is a phone that is actively used by a user)
,
Mar 15 2018
Thank you for providing more feedback. Adding the requester to the cc list. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Mar 15 2018
Oh, I found the kernel log. I am pasting a snip that is relevant to the USB You can see the device being connected at line 2, on line 24 I try reset, and on line 34 you see the device is re-connected (it seems though that it is with the same ID)
,
Mar 15 2018
Oh about that ID, I confused id in the chrome debug log that gets bumped after reset and productId of the device. productId is still one, but the id gets bumped after the reset in Chrome
,
Mar 21 2018
,
Apr 5 2018
According to the kernel source this appears to be working as intended. When the kernel detects that the USB device descriptor has changed it treats it as a new device and returns -ENODEV from the reset call and does a full re-enumeration. Does your device change idVendor, idProduct or bcdDevice when resetting into DFU mode? Reference: https://github.com/torvalds/linux/blob/v4.12/drivers/usb/core/hub.c#L5480 |
||||||
►
Sign in to add a comment |
||||||
Comment 1 by k...@karelbilek.com
, Mar 8 2018