On 11/14/2017 01:36 PM, Shuah Khan wrote:
> On 11/14/2017 09:25 AM, Juan Zea wrote:
>> Hi,
>>
>> I've been working on the issue. This is what I found about multi-controller setup:
>>
>> The problem comes from the usbip tool trying to connect usb2 devices to usb3 ports, like this:
>>
>> - usbip tool asks vhci driver for free port.
>> - If the first port (usb2) is already occupied, vhci answers with usb3 port (instead of next controller's usb2 port)
>> - usbip tool tries to connect usb2 device to usb3 port and fails
>
> It would be interesting to see how this fails. Can you send me complete
> dmesg from client and server for this.
>
>> - usbip tool asks for the next free port, which is still the same usb3 port.
>> - Loop the above forever
>
> That doesn't sound right.
>>
>> the code at tools/usb/usbip/libsrc/vhci_driver.c :
>> 329 int usbip_vhci_get_free_port(uint32_t speed)
>> 330 {
>> 331 for (int i = 0; i < vhci_driver->nports; i++) {
>> 332 if (speed == USB_SPEED_SUPER &&
>> 333 vhci_driver->idev[i].hub != HUB_SPEED_SUPER)
>> 334 continue;
>> 335
>> 336 if (vhci_driver->idev[i].status == VDEV_ST_NULL)
>> 337 return vhci_driver->idev[i].port;
>> 338 }
>> 339
>> 340 return -1;
>> 341 }
>>
>> prevents usb3 devices connecting to usb2 ports, but not the other way around.
>
> Connecting usb2 device to usb3 port should work. It would make sense
> to prevent usb3 devices connecting to usb2 ports, and not the other
> way round.
>
>>
>> I've patched this preventing the opposite, and multi-controller starts working the way I think it should:
>> - usb2 devices connect exclusively to usb2 ports
>> - The above is also true for usb3 devices and ports
>> - When there is no compatible port for the device in the present controller, go for the next>
>> At least, for connecting devices this seems to work, and I can get several usb2 and usb3 connected to the same machine in different orders.
>> The question is... is this the way it is supposed to work?
>
> Unless there is some exception in the usb3 support in the usbip driver
> that prevent usb2 ports from connecting to
>>
>>
>> Another problem is... some of my test devices don't work. They detonate a kernel BUG line in the vhci controller:
>> Nov 14 14:35:29 kernel-tester kernel: [ 229.636543] kernel BUG at drivers/usb/usbip/vhci_hcd.c:683!
There appears to be a race condition in
[PATCH] usbip: vhci extension: modifications to vhci driver
0775a9cbc694e8c7276688be3bbd2f386167ab54
between urb enqueue and disconnect. There is another commit
that attempted to fix it - but I don't believe it does:
[PATCH] usbip: fix possibility of dereference by NULLL pointer in
vhci_hcd.c
d79cda045e3bacb7e754a5324cd3d4ce80708eb1
>>
>> This is happening even using the vhci module as it is downloaded from Ubuntu (no intervention on my behalf in this experiment), so it seems they just stopped working some kernels ago.
>
> It will be harder to debug that way unless you know which kernel release the
> Ubuntu module is coming from. What's the kernel release on Ubuntu?
>
>> I'm still bisecting the kernel for this, but for now I have filed a bug at bugzilla with the specific device and kernel versions: https://bugzilla.kernel.org/show_bug.cgi?id=197867
>
> Will you be able to send me complete dmesg for this. I see excerpts but not the
> full dmesg.
>
> Also, will you be able to revert the usb3 commit
> 1c9de5bf428612458427943b724bea51abde520a
>
Hi Yuyang Du,
I am looking at the USB3 support patch and not finding where
USB_SPEED_LOW is handled. Any reason why dropping support for
that?
thanks,
-- Shuah
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
