Closed 519790441 closed 4 years ago
@519790441 : Please check a new v0.3.0 in the release page. And I have marked v0.2.0 as obsolete.
obsolete
The v0.3.0 still fails. I can get "usbip_stub: get_desc: Unknown descriptor type code: 22" in dbgview before deadlock.
In 0.3.0, I can get bsod when detach from stub manually. 0: kd> !analyze -v
DRIVER_IRQL_NOT_LESS_OR_EQUAL (d1) An attempt was made to access a pageable (or completely invalid) address at an interrupt request level (IRQL) that is too high. This is usually caused by drivers using improper addresses. If kernel debugger is available get stack backtrace. Arguments: Arg1: fffff80728c24b60, memory referenced Arg2: 0000000000000002, IRQL Arg3: 0000000000000008, value 0 = read operation, 1 = write operation Arg4: fffff80728c24b60, address which referenced memory
I can get "usbip_vhci:(WW) process_irp_urb_req: unhandled function: URB_FUNCTION_GET_MS_FEATURE_DESCRIPTOR: len: 136" on vhci endpoint. @cezanne
I used the new vhci_ude mode and currently solve the problem I mentioned in the post. @cezanne
@519790441 : Thanks for your report. I'll close this issue. Please reopen if you need.
I have a usb composite device. When mapping via usbip, the device ID seen from "usbip attach" and the device ID seen after "attach" are not equal. Through the "dbgview" window, you can see that after the bulk request reaches the "stub" endpoint, it will deadlock until the peer manually performs the "detach" operation.
When mapping through the "usb over remote desktop" software, the local device ID and the remote device ID are equal, and the device can work normally on the remote computer.