26 Jan
2020
26 Jan
'20
6:25 p.m.
Dear all,
I just subscribed to this list since I encountered an issue after
pulling the latest git commits.
lib: use interface 0 altsetting 1 instead of interface
1 ...
This makes osmo-fl2k work again with Linux 5.5.0-rc6 or later,
On my system (Debian stable, kernel 4.19) this change results in
"Error enabling IF 0 altsetting 1". Reverting to the
previous version (with Interface 1) solved the problem for me.
I will investigate a bit more whether it is related to kernel or
libusb versions. Or have I missed some other required configuration?
Best regards,
Carl-Fredrik SM2YHP
--
------------------
Carl-Fredrik Enell
Föraregatan 26B
SE-98139 Kiruna
+46705508256
-----------------
26 Jan
26 Jan
9:03 p.m.
Hi,
On 26.01.20 18:25, Carl-Fredrik Enell wrote:
On my system (Debian stable, kernel 4.19) this change
results in
"Error enabling IF 0 altsetting 1". Reverting to the
previous version (with Interface 1) solved the problem for me.
Thanks for reporting this issue, you are not the first one to encounter
it as it seems.
I will investigate a bit more whether it is related to
kernel or
libusb versions. Or have I missed some other required configuration?
Do you see any reason in the kernel log (like "not enough bandwidth")?
Some googling showed that the FX3 of the bladeRF has the same issue when
setting the altsetting. It seems to only happen for them if the device
wasn't properly released, and they added a libusb_reset_device() as a
workaround. But in our case this happens always on some machines as far
as I understand.
I've just pushed a workaround for now that falls back to the old
behavior (claiming interface 1) in case switching interface 0 to
altsetting 1. This will of course only work for Kernels < 5.5.0-rc6,
but so far nobody with a Kernel >= 5.5.0-rc6 reported the altsetting
issue.
Thanks for further investigating, so far I cannot reproduce this issue
here, maybe I should set up a machine with Kernel 4.19.
What USB 3.0 host controller and version of libusb are you using?
Regards,
Steve
10:06 p.m.
Hi,
Thanks for your fast reply!
Steve> Do you see any reason in the kernel log (like "not enough
Steve> bandwidth")? /... /What USB 3.0 host controller and version of
Steve> libusb are you using?
The Debian machine is a Thinkpad X240, ie Intel Haswell architecture
I tried libusb 1.0.22 and 1.0.23 with same result.
For information, I compiled a fresh git clone on my Archlinux box
(kernel 5.4.14) which worked without problem. Thus it could be either
a hardware or version issue, I will look into the logs later.
Best regards,
--
------------------
Carl-Fredrik Enell
Föraregatan 26B
SE-98139 Kiruna
+46705508256
-----------------
27 Jan
27 Jan
10:51 p.m.
Hi,
I have posted some notes from my tests on two different systems at
https://kyla.kiruna.se/nextcloud/index.php/s/SBc8jH4nS3FnoAZ
A short summary: libusb is the same version, kernel and hardware are
different. Only the Arch Linux system with kernel 5.4.15 on AMD
hardware detects altsettings.
I have also listed lsmod output in case conflicting modules would be loaded.
>>>> "Steve" == Steve Markgraf
<steve(a)steve-m.de> writes
Steve> I've just pushed a workaround for
now that falls back to
Steve> the old behavior (claiming interface 1) in case switching
Steve> interface 0 to altsetting 1.
As you can see in the notes this works on the laptop, thanks!
Best regards
SM2YHP
--
------------------
Carl-Fredrik Enell
Föraregatan 26B
SE-98139 Kiruna
+46705508256
-----------------
1559
days inactive
1560
days old
3 comments
2 participants
participants (2)
-
Carl-Fredrik Enell -
Steve Markgraf