|
From: Alan S. <st...@ro...> - 2015-09-02 14:16:10
|
On Tue, 1 Sep 2015, Matthew Giassa wrote: > > Matthew Giassa wrote: > >> Second, addressing your question: yes, transfers using the old device handle succeed. This includes flashing and verifying the bootrom. > > > > This is impossible to believe. The device number is the physical > > addressing mechanism on the bus. If the device is now known as device > > 11, then requests to device 10 will be ignored. > > > > You did say you are working with two cameras. Isn't it possible you are > > getting confused between the two cameras here? Do both cameras use the > > same serial number? (Windows, for what it's worth, will not allow that > > situation VID/PID/Serial must be unique system-wide.) > > I should clarify the details. I'm working with a single camera. During > normal operation, let's assume it has a serial number of "ABCDEFGH". > When I trigger it to enter the firmware update mode, I see two cameras > for a short while, with serial numbers of: > Device 0: > Serial: 1234ABCD Is this supposed to be different from the "ABCDEFGH" you mentioned above? > Bus: 6 > Addr: 10 > Device 1: > Serial: DEADBEEF > Bus: 6 > Addr: 11 > > A short while later, the first device disappears, and my list becomes: > Device 0: > Serial: DEADBEEF > Bus: 6 > Addr: 11 > > I know it sounds strange, but I re-tested and confirmed today: I am > still able to write to the "old" device with serial number "1234ABCD" by > using the (now-stale) libusb_device handle to it. > > I can communicate with the "new" device (serial "DEADBEEF") as well (ie: > query value from bootrom, etc), but I can't seem to tell the firmware > updater to talk to the "new" device: it seems intent on using the > "stale" device handle until all operations complete. > > Would it be reasonable to expect this behavior won't work in future > releases of libusb? It would be reasonable to expect this behavior won't work in _any_ release of libusb! :-) Please try the following experiment. Before running the test, do (as root): dmesg -c >/dev/null echo 'module usbcore =p' >/sys/kernel/debug/dynamic_debug/control echo 1 >/sys/module/usbcore/parameters/usbfs_snoop This will cause a bunch of debugging output to be added to the kernel log whenever libusb talks to the kernel or other interesting events happen. Then after the test, run the "dmesg" command and post the output for us to look at. Alan Stern |