USB device suddenly works. But why?

[comsyspro]

Here is a USB device that has about 7 USB devices in it. This USB device was causing a few problems (with version v.0.9.6.3) and I would like to ask if there have been any changes to the code recently. I compiled usbip manually with the current code (v.0.9.6.4) and the device now works. I also compiled the current code on the server side and it could also be due to the server code that this USB device suddenly works. Can you say whether you have made any changes to the code recently to better support such USB devices?

[vadimgrn]

Use git to find out the difference between releases. I can only guess what exactly affected this.

P S. The only change was that the deadlock had been fixed in receive thread. I think that something has fixed on server side.

[comsyspro]

In this case I also have to guess. I can tell you that with version v.0.9.6.3 attaching this USB device is firstly detected and displayed in the device manager. However after detaching and unbinding it was still there in the device manager and instead of removing it from the device manager another unkown device showed up with an error mark. Also in the registry the keys in the USB enum devices persist. When you attach a second time then you will get displayed 2 of these devices in the device manager and after detaching you also get 2 unkown devices showed up with an error mark - and so on ... Because of that I wrote a powershell script which manually deleted the affected registry keys of these USB enum devices to "clear" the status as it should be after detaching. But this was only a fix and didn't go down to the main reason of this issue. So it seems that you changed something in your code since v.0.9.6.3 which also affects this issue.

[vadimgrn]

There are four commits since the latest release and only one really was for the driver.

[comsyspro]

Thank you. Perhaps this issue has something to do with this here d1155ff. Also the title "Fix detach deadlock" could suggest this.

[comsyspro]

I come back to this issue. I went back to version v.0.9.6.3 and here the device have troubles like I described it here. So with v.0.9.6.4 the device works and can be attached and properly detached. But with some little troubles. When the device is in the attached state it takes about 10 seconds then it is shortly disconnected for about 3 seconds and then it is connected again for about 10 seconds and so on ... So can you tell if there is likely a loop function with an interval somwhere in the code which causes these connects and disconnects? At the moment only these kind of devices behaves like that and I guess that it could also be an issue with the handling of many sub devices like here sub device number from 0 to 5.

Here is also a screenshot of the attached device with sub devices:

[vadimgrn]

There are no such loops in the driver. It can be issues with virtual device power management, for example see #72. I don't have such devices and can't investigate what is going on.

[comsyspro]

Now I have noticed by further investigation that the device stays connected as long as you use the device (moving sliders, rotating controls, pressing buttons). Then when you do nothing on the device it takes about 1 second and the device diconnects and reconnects. So it seems that if you don't give input signals to the device it disconnects and reconnects. Do you think that probably here in this fix d1155ff is another little bug (here is also a function called wait_detach_timeout)? Or how can I support you here finding the bug?

[vadimgrn]

Please pay attention to power management stuff
UDECX_USB_DEVICE_CALLBACKS_INIT
WdfDeviceInitSetPnpPowerEventCallbacks
WDF_DEVICE_POWER_POLICY_IDLE_SETTINGS_INIT
GUID_USB_CAPABILITY_SELECTIVE_SUSPEND

[vadimgrn]

https://learn.microsoft.com/en-us/windows-hardware/drivers/usbcon/selective-suspend-in-usb-drivers-wdf

[vadimgrn]

https://learn.microsoft.com/en-us/windows-hardware/drivers/wdf/power-management-for-i-o-queues

[comsyspro]

Thank you. Can you give a hint where these functions should be included. At the moment I have no overview and don't know how to start here. I just tested this device with another USBIP software and there the device is working normal.

The device reboots when you stop giving input signals. You can see it here if you stop rotating the controller the device reboots. As long as you rotate or do something the device stays on. The device should stay stable without rebooting.

Or is it possible to add a code line to not go into such a suspend mode and stay in power mode all the time?

[vadimgrn]

I don't know, I have no such devices. You don't need to include something, you could modify existing code. For example, make all WDFQUEUEs not power managed

[comsyspro]

I tried now to set all entries from cfg.PowerManaged = WdfFalse; to cfg.PowerManaged = WdfTrue; and recompiled but this is not the solution. So what could I do to find the reason. Can I create logs which you could look into?

[vadimgrn]

Set all to cfg.PowerManaged = WdfFalse

[comsyspro]

The cfg.PowerManaged = WdfFalse; is your normal code and I went back to this. Here are also the logs. First the device is attached. Then I rotated the controller. Then I stopped rotating and the device reboots. Then again I rotated the controller and pressed any button. Then I stopped doing anything and the device reboots again.

Here are the logs and zipped etl files (start capture - attaching the device - rotating knob - stopped rotating and device reboots - again rotation knob pressing a button - stopped doing anything and the device reboots again - stop capture)::
usbip-flt.txt
usbip-ude.txt
usbip-flt.zip
usbip-ude.zip

Can it be that this part of code can lead to the described issue?

usbip-win2/drivers/ude/device.cpp

Line 177 in fcb8232

while (auto request = device::remove_request(dev, endpoint)) {

The code seems to unlink and cancel all devices in a while loop. Perhaps this also unlinks devices which should't be unlinked. So it could be that after a controller was rotated it goes into this while loop and unlinks all devices. It should instead only unlink the device which was triggered before. Can this be the problem?

Update:
I just did a test from Windows to Linux and here the USB device is working fine (USB device is connected on Linux and forwarded to Windows). But it should also work from Windows to Windows. Perhaps it's also an issue in the Windows usbipd server.

Here are PCAP captures of usbipd server (start capture - attaching the device - 3 reboots - detaching - stop capture):
FILE.zip

[vadimgrn]

I do not get what is working and what isn't. If Linux is a server and usbip2 is a client, that's enough. Windows usbipd server is not a canonical implementation, I do not care about it. I'm going to implement server part for usbip2 this year (at least start development).

[comsyspro]

This would be a good combitnation to also have your usbipd server for windows. Perhaps such issues will then be history. At the moment we try to get it done with usbipd-win.