<div dir="ltr"><div dir="ltr"><div>I did some more tests. I upgraded the OS on my Odroid XU4 to Ubuntu 18.04, and this has libusb 1.0.21 in the repo's (the previous one I was using had libusb 1.0.20). Now I get the same continuous lost sample bytes problem on the XU4 as on the Tinkerboard - a huge amount of dropped samples with zerocopy enabled. </div><div><br></div><div>However, on the latest Raspbian on the Rpi3, I don't see the problem. On the Pi3 rtl_test returns only one line of dropped samples, then no more. </div><div><br></div><div>Allocating 15 zero-copy buffers</div><div>lost at least 156 bytes</div><div><br></div><div>On the Odroid and Tinkerboard it's more like:</div><div><br></div><div><div>Allocating 15 zero-copy buffers</div><div>lost at least 13617588 bytes</div></div><div><div><div>lost at least 12326518 bytes</div></div><div><div>lost at least 13208366 bytes</div></div></div><div><div><div>lost at least 13301044 bytes</div></div>...and so on forever</div><div><br></div><div>No other error messages are seen, and disabling the usbfs_memory_mb limit by setting it to zero doesn't get rid of the problem.</div><div><br></div><div>I'm not too sure about the CMA stuff, i'm just using the default OS images provided for the Tinkerboard and XU4, and standard Ubuntu 18.04 on my laptop.</div><div> </div><div><div><div><div dir="ltr" class="m_-5329574286388314093gmail-m_-1358753148507062051gmail_signature"><div dir="ltr"><div><div dir="ltr">Regards,<div><div>Carl Laufer</div></div></div></div></div></div></div></div></div></div></div><br><div class="gmail_quote"><div dir="ltr">On Tue, Oct 2, 2018 at 10:28 AM Steve Markgraf <<a href="mailto:steve@steve-m.de" target="_blank">steve@steve-m.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Carl,<br>
<br>
On 01.10.2018 05:42, Carl Laufer wrote:<br>
> I did a diff against Keenerds and discovered the new zerocopy buffer<br>
> code in the Osmocom drivers. After commenting that out, the Osmocom<br>
> drivers work fine on the Tinkerboard with Armbian and there is no sample<br>
> loss.<br>
<br>
That's very strange, because from an rtl-sdr point of view it is just<br>
regular memory that was allocated by the Kernel (and happens to be<br>
DMA-able) and mapped into userspace. So my first guess is that something<br>
must be going wrong either inside the Kernel or libusb.<br>
<br>
> Strangely, on TinkerOS and Ubuntu OS for Tinkerboard, all of which run<br>
> Kernel 4.4, I do not get sample loss with the Osmocom drivers and the<br>
> zerocopy code enabled. <br>
<br>
Yes, as 4.4 doesn't support usbfs zerocopy.<br>
<br>
> I'm also running the Osmocom drivers on an Odroid XU4 with Ubuntu which<br>
> is also running Kernel 4.14, and on Raspbian, and on those there is no<br>
> sample loss. So it seems to be something specific to the Tinkerboard and<br>
> Armbian with Kernel 4.14y.<br>
> <br>
> Not sure if the zerocopy code is just not getting activated on those<br>
> other OSes or what. How do I check if the installed libusb API version<br>
> is >= 0x01000105?<br>
<br>
I've put that information into the commit message:<br>
<br>
> Requires Linux >= 4.6 and libusb >= 1.0.21.<br>
<br>
(<a href="https://cgit.osmocom.org/rtl-sdr/commit/?id=a854ae8b48d42e8dad514c75d3a4c6cfb62707da" rel="noreferrer" target="_blank">https://cgit.osmocom.org/rtl-sdr/commit/?id=a854ae8b48d42e8dad514c75d3a4c6cfb62707da</a>)<br>
<br>
So it's enabled if both versions are there.<br>
<br>
> Any ideas what could cause the zero copy code to result in the lost samples?<br>
<br>
Do you get any error messages when the library is loaded? What is the<br>
value of /sys/module/usbcore/parameters/usbfs_memory_mb, and can you try<br>
to increase it or set it to 0 to disable the limit?<br>
<br>
Was the Kernel built with CONFIG_CMA=y, and what is the value of<br>
CONFIG_CMA_SIZE_MBYTES?<br>
<br>
If any of this isn't right, there normally should appear a warning and<br>
"falling back to buffers in userspace" when starting the application,<br>
but maybe there is something going wrong...<br>
<br>
Regards,<br>
Steve<br>
</blockquote></div>