NI USB Device Updater does not working when Google Chrome is running
Reported by
samuel.p...@native-instruments.de,
May 29 2017
|
|||||||||||||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:53.0) Gecko/20100101 Firefox/53.0 Steps to reproduce the problem: 1. Open Google Chrome v55.0.2883.95 (also the latest 58.0.3029.110 (64-bit)) 2. Open USB NI Device Updater. 3. Update. What is the expected behavior? The firmware must be written without any errors. What went wrong? Actual Results: -> sending DFU_DETACH... -> done. -> Waiting for device to re-enumerate... -> done. Writing firmware image 'Builds/TKX1_130701_v10.dfu' to device ... -> ERROR: Status: OK (No error condition is present) State: appIDLE Poll Timeout: 0 ms -> Rebooting device. Did this work before? N/A Chrome version: v55.0.2883.95 Channel: n/a OS Version: OS X 10.12 Flash Version: Shockwave Flash 25.0 r0 We already open a bug report to Apple. It is attached. The final recommendation was: "Chrome opens a user client on every usb device in the system. You can try using kIOServiceSeize when calling open on the device. If this doesn’t work the only thing you can do is close chrome." We do not want to use this call because there is many side-effects. We believe that Chrome does not gracefully free the device on request. This is critical bug for us, we have been return of devices because of that. Follow our Support Info about that bug: "Yes, tech support has reports (glad that we have found the culprit). Some of the affected costumers contact us directly (we have 4-8 tickets per month, phone calls not included), and further this is certainly also causing customers somewhere in the world to bring back their device to their dealer without contacting us before, and the dealer just accepts the return. This issue is causing unnecessary hardware returns and thus unnecessary cost and effort - for us and for the customers."
,
May 30 2017
Adding respective component for someone from USB team to help in further triaging this issue. Please feel free to change the component if it is not proper. Thanks!
,
May 31 2017
Does closing Chrome immediately restore access to the device or do you have to reinsert it? Having a UserClient attached to the device does not necessarily mean that Chrome has the device open however Chrome does make requests to a device when it detects that it is connected and those requests could be interfering with other applications attempting to use the device or even put the device in a bad state if it triggers a firmware bug. While investigating issue 668921 I noticed that we are unconditionally calling USBDeviceOpenSeize to open a device to make control transfers which may be overly aggressive, at least during the enumeration process. If we move away from libusb (issue 422562) then we can avoid even opening the device in many enumeration cases by reading the necessary properties out of the IORegistry.
,
Jun 1 2017
Hello, thanks for the feedback. Yes, closing Chrome immediately restore the ability to flash a FW in the unit. It is deterministic. When chrome is open (even with just a blank page loaded), for some products, the flash process fails, otherwise it passes. I did not see the same issue associated with other browsers.
,
Jun 1 2017
Thank you for providing more feedback. Adding requester "reillyg@chromium.org" to the cc list and removing "Needs-Feedback" label. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Jun 7 2017
Hi, We are seeing the exact problem at BlackmagicDesign when updating USB firmware on our products under MAC OS. Tests have shown us that we fail to get exclusive access to our blackmagic USB device if chrome is running in the background, and as soon as if we close chrome, firmware update succeeds! IORegistryExplorer showed that chrome maintains access to all USB devices on the iMac used for testing.
,
Jun 12 2017
Hi, I would like to inform that no reprodution of this issue was seen on MacOS 10.13 beta (17A264c). It seems Apple makes some changes on their APIs, I guess. This issue still persists on macOS 10.12 or older version. Browsers in test: Google Chrome 59.0.3071.86 Opera 45.0.2552.888
,
Jun 13 2017
Assigning to take this out of the Mac queue :).
,
Jul 19 2017
Hi guys, any idea when are you going to see this? We are still receiving complaints about it :( |
|||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||
Comment 1 by samuel.p...@native-instruments.de
, May 29 2017