Hi Carl,
On 01.10.2018 05:42, Carl Laufer wrote:
I did a diff against Keenerds and discovered the new
zerocopy buffer
code in the Osmocom drivers. After commenting that out, the Osmocom
drivers work fine on the Tinkerboard with Armbian and there is no sample
loss.
That's very strange, because from an rtl-sdr point of view it is just
regular memory that was allocated by the Kernel (and happens to be
DMA-able) and mapped into userspace. So my first guess is that something
must be going wrong either inside the Kernel or libusb.
Strangely, on TinkerOS and Ubuntu OS for Tinkerboard,
all of which run
Kernel 4.4, I do not get sample loss with the Osmocom drivers and the
zerocopy code enabled.
Yes, as 4.4 doesn't support usbfs zerocopy.
I'm also running the Osmocom drivers on an Odroid
XU4 with Ubuntu which
is also running Kernel 4.14, and on Raspbian, and on those there is no
sample loss. So it seems to be something specific to the Tinkerboard and
Armbian with Kernel 4.14y.
Not sure if the zerocopy code is just not getting activated on those
other OSes or what. How do I check if the installed libusb API version
is >= 0x01000105?
I've put that information into the commit message:
Requires Linux >= 4.6 and libusb >= 1.0.21.
(
https://cgit.osmocom.org/rtl-sdr/commit/?id=a854ae8b48d42e8dad514c75d3a4c6c…)
So it's enabled if both versions are there.
Any ideas what could cause the zero copy code to
result in the lost samples?
Do you get any error messages when the library is loaded? What is the
value of /sys/module/usbcore/parameters/usbfs_memory_mb, and can you try
to increase it or set it to 0 to disable the limit?
Was the Kernel built with CONFIG_CMA=y, and what is the value of
CONFIG_CMA_SIZE_MBYTES?
If any of this isn't right, there normally should appear a warning and
"falling back to buffers in userspace" when starting the application,
but maybe there is something going wrong...
Regards,
Steve