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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
