On Sat, 15 Feb 2014, Phil Dibowitz wrote: > Scrolling up, you can see that hid_report_callback never queued more than 3 > packets:
OK, so we're not dropping packets due to over-running the HIDAPI buffer. > Now, if I run a bunch more times, eventually I get: > > DEBUG (ReadFlash): Expected seq EF > DEBUG (ReadFlash): Next expected seq 00 > PHIL: hid_read_timeout: no data. > PHIL: hid_read_timeout: non-blocking 60 > PHIL: hid_read_timeout: unlocking... > PHIL: hid_read_timeout: returning 0 > DEBUG (HID_ReadReport): USB read timed out > Failed to dump config: Error while reading from the remote > Failed with error 3 > > > Note the USB timeout! That's with the timeout bumped to 1s, from 500ms. Hmmm. > If I bring it up to 5s it's VERY rare (I can sometimes trigger it, but only > after lots of times in a loop). Either way, the next time: So, I suspect this isn't really a different problem. I suspect this is just another instance of a lost packet, but in this case, we lost the last one in the series, and the remote won't send any more until we request the next set. > What's really strange is, in theory we queue 5 packets, and then read 6 > packets when we hit the missing ones: > > PHIL: hid_report_callback: 5th pckt > PHIL: hid_report_callback: sending pthread signal > PHIL: hid_report_callback: unlocking > PHIL: hid_report_callback: returning > PHIL: hid_read_timeout: calling return_data(). > PHIL: hid_read_timeout: unlocking... > PHIL: hid_read_timeout: returning 64 > DEBUG (ReadFlash): Expected seq 34 > DEBUG (ReadFlash): Next expected seq 45 > PHIL: hid_read_timeout: calling return_data(). > PHIL: hid_read_timeout: unlocking... > PHIL: hid_read_timeout: returning 64 > DEBUG (ReadFlash): Expected seq 45 > DEBUG (ReadFlash): Next expected seq 56 > PHIL: hid_read_timeout: calling return_data(). > PHIL: hid_read_timeout: unlocking... > PHIL: hid_read_timeout: returning 64 > DEBUG (ReadFlash): Expected seq 56 > DEBUG (ReadFlash): Next expected seq 67 > PHIL: hid_read_timeout: calling return_data(). > PHIL: hid_read_timeout: unlocking... > PHIL: hid_read_timeout: returning 64 > DEBUG (ReadFlash): Expected seq 67 > DEBUG (ReadFlash): Next expected seq 78 > PHIL: hid_read_timeout: calling return_data(). > PHIL: hid_read_timeout: unlocking... > PHIL: hid_read_timeout: returning 64 > DEBUG (ReadFlash): Expected seq 78 > DEBUG (ReadFlash): Next expected seq 89 > PHIL: hid_read_timeout: calling return_data(). > PHIL: hid_read_timeout: unlocking... > PHIL: hid_read_timeout: returning 64 > DEBUG (ReadFlash): Expected seq 89 > DEBUG (ReadFlash): Next expected seq 9A > PHIL: hid_read_timeout: calling return_data(). > PHIL: hid_read_timeout: unlocking... > PHIL: hid_read_timeout: returning 64 > DEBUG (ReadFlash): Expected seq 9A > DEBUG (ReadFlash): Invalid sequence want: 9A got: cd > Failed to dump config: Error while reading from the remote > Failed with error 3 > > > I'm lost. I don't think that is strange. I think what happened in this case was - we got busy and queued up five packets. Then we read all of them and got caught up. So, at that point we're caught up and now blocking, waiting on the read thread to wake us up. The next few packets are received while we're waiting for them. But for some reason we still lost some. I did a little bit of looking around and it looks like the cause may be the HID driver only allowing one pending read to be in progress. If the run loop gets busy and doesn't return quickly, packets may still get lost. See this: https://groups.google.com/forum/#!msg/darwin-usb/k4AraqqCRfg/5qG0P9Tx6NwJ ------------------------------------------------------------------------------ Android apps run on BlackBerry 10 Introducing the new BlackBerry 10.2.1 Runtime for Android apps. Now with support for Jelly Bean, Bluetooth, Mapview and more. Get your Android app in front of a whole new audience. Start now. http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk _______________________________________________ concordance-devel mailing list concordance-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/concordance-devel
