limesdr-usb does CW instead of tdma bursts after "lsusb -d 1d50:6108 -v" when using usb2

[rohlan]

when running recent osmo-trx-lms with limesuite1810 and limesdr-usb forced down to usb2 by using a usb2 only cable the device stops working and starts emitting a continuous wave (cw) carrier as soon as "lsusb -d 1d50:6108 -v" is run in another terminal.
"lsusb -d 1d50:6108" does not interrupt the service.

this is not reproducible when using only usb3 cabling

see also https://osmocom.org/issues/3341

[laf0rge]

The difference between "lsusb" and "lsusb -v" is that the former just uses cached descriptors from the kernel (i.e. no transaction with the device happens), while the latter is actually using control transfers on the control endpoint to retrieve the string descriptors.

So the suspicion is that something is broken in the handling of control transfers if attached to/via USB 2.0 only.

It is perfectly normal for the OS or any other application to send USB control transfers to a device, even while the device is in use.

[ztamosevicius]

Can not reproduce this on Gigabyte Brix computer. Running Ubuntu 16.04 LTS. LimeSDR-USB forced to USB2 via USB hub. LimeSuiteGUI transmitting and receiving at the same time, command "lsusb -d 1d50:6108 -v" makes no impact.

[ztamosevicius]

The reason device stops working and starts emitting a continuous wave (cw) carrier as soon as "lsusb -d 1d50:6108 -v" is run is as follows: after command "lsusb -d 1d50:6108 -v" is run, there is a packet loss. While there is no re-synchronization (check https://osmocom.org/issues/3339#note-11), everything stops and carrier is visible only, while there are no data to send.

[laf0rge]

Thanks for your feedback. The question is: Why would a very small control endpoint transfer result in packet loss? We're talking about very small transfers fetching a couple of string descriptors. Surely, this shouldn'r result in packet loss on the completely unrelated bulk endpoints?

[rohlan]

any news why there is a packet loss on usb3 when requesting descriptors? is this a bug in the ftdi firmware or rather in the fpga?

[ztamosevicius]

@rohlan - This issue was reported for LimeSDR-USB board when it is forced to USB2 communication. From your last message I understand, that the same issue is for LimeSDR-Mini board, connected via USB3. Could you confirm please that you are talking about LimeSDR-Mini board and USB3 communication.

[laf0rge]

Hi @ztamosevicius - could you please confirm the long-standing bug has been resolved? It would be good to add a reference to the specific commit that fixed it here. Thanks!

[ztamosevicius]

Hi @laf0rge, Apparently I closed this issue by accident. Reopening it, sorry for confusion!