Menu
▾
▴
Re: [Libusb-win32-devel] libusbK 3.0.6.15 Released
|
From: Travis <lib...@gm...> - 2014-04-14 22:15:31
|
On 4/14/2014 2:38 PM, Matt Liberty wrote: > Travis, > > I spent several hours today testing 3.0.6.15, and I can confirm that I > no longer see the BSoD / WDF_Violation during the call to > SetCurrentAltSetting. I also ran my custom application stress test > across a variety of platforms. All tests pass, so I see no > regressions with libusbk 3.0.6.15. I also took a look through the > KMDF documentation, and I see no reason why the previous libusbk code > should have been able to cause a BSoD with the calls that were removed > in libusbk 3.0.6.15. Not a satisfactory explanation, but it works > well enough now. I use WdfIoTargetStart/Stop in other functions (FlushPipe for instance) and I could not reproduce the same problem so I think it is a special case related to changing the alternate setting. I think the current fix is solid but I may look into this some more when I have more time.. hmm it seems fishy! > > I still see a wide variation across PCs (18 ms to 800 ms) in the > duration of the SetCurrentAltSetting call. I also see a variety of > error return codes when the device is removed during > the SetCurrentAltSetting call including: > > ERROR_FILE_NOT_FOUND: 2 (0x2) > ERROR_GEN_FAILURE: 31 (0x1F) > *ERROR_SEM_TIMEOUT*: 121 (0x79) > ERROR_BUSY: 170 (0xAA) > ERROR_OPERATION_ABORTED: 995 (0x3E3) > ERROR_DEVICE_NOT_CONNECTED: 1167 (0x48F) > > The variety of errors is not an issue, but the ERROR_SEM_TIMEOUT which > means "The semaphore timeout period has expired." is disconcerting. > In my experience, having a semaphore timeout is often indicative of a > deeper issue and should likely go on the list of libusbk items to > investigate. I only saw this error on a Win 7 x64 PC that completes > the SetCurrentAltSetting in approximately 18 ms. My other machines > all take far longer, so this error could possibly indicate a race > condition in the user-space libusbk library. > ERROR_SEM_TIMOEUT is nothing to worry about. The driver will translate STATUS_TIMEOUT to this value. Synchronous pipe read/write functions in the library code can return this as well. It would be great if the error codes were more consistent but most likely these aren't even coming from libusbK. It depends on where the transfer is at at the moment the device is disconnected. There exists a "WdfUsbTargetDeviceIsConnectedSynchronous" function that I believe asks the hub if a device is really still connected but other than simply adding another API for it, I haven't found a good way to work it in. Regards, Travis > Thanks again for your excellent support! > > - Matt > > On Sun, Apr 13, 2014 at 9:43 PM, Travis <lib...@gm... > <mailto:lib...@gm...>> wrote: > > Greetings, > > A new libusbK release candidate is available here: > https://sourceforge.net/projects/libusbk/files/libusbK-beta/3.0.6.15/ > > Please test and report any problems. I would like to push an official > release sometime before the 20th (4/20/14). > > Regards, > Travis > > V3.0.6.15 RC15 (04/13/2014) > ============================================== > - Fixed hot-plug init issue which caused a failure after re-loading > libusbK.dll dynamically. (Reported By Stefan Battmer) > > - Fixed BSOD if a device is removed while changing an interfaces > alternate > Setting. (Reported By Matt Liberty) > > - Fixed GetCurrentAlternateSetting issues which caused the device > to close > upon return. > > Regards, > Travis > > > > ------------------------------------------------------------------------------ > Learn Graph Databases - Download FREE O'Reilly Book > "Graph Databases" is the definitive new guide to graph databases and their > applications. Written by three acclaimed leaders in the field, > this first edition is now available. Download your free book today! > http://p.sf.net/sfu/NeoTech > > > _______________________________________________ > Libusb-win32-devel mailing list > Lib...@li... > https://lists.sourceforge.net/lists/listinfo/libusb-win32-devel |