This is merely a historical archive of years 2008-2021, before the migration to mailman3.
A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/OpenBSC@lists.osmocom.org/.
Gullik Webjorn gullik.webjorn at corevalue.seI was getting this error on Orange Pi Zero w. Limesdr Mini. After trying desperately to debug this, my solution was to make sure all cpu was available by keeping the temperature low, since the OPI Z was throttling down from 960 Mhz to 240 Mhz when the temperature want up. The cause was simply not enough CPU during certain conditions, causing an overrun *within* the Limesdr mini. Once triggered, this problem persists until LimeSDR is restarted, whether this is a bug is up for discussion....perhaps debugging error handling ?? Failiure to read correct number of bytes ONCE causes all subsequent reads to fail, until driver AND limesdr are restarted. Once a fan was installed, the problem went away... Gullik On 2019-04-15 16:14, Rafael Diniz wrote: > Btw, before any bug report (as I need to upgrade the limesuite and > rebuild stuff), after some time running osmo-trx-lms (from osmocom > nightly builds), I get: > > (...) > <0002> LMSDevice.cpp:600 [tid=140623704246016] chan 0 recv buffer of len > 2500 expect 3f19c154 got 3f19e134 (3f19e134) diff=1fe0 > <0002> LMSDevice.cpp:600 [tid=140623704246016] chan 0 recv buffer of len > 2500 expect 3f19cb18 got 3f19eaf8 (3f19eaf8) diff=1fe0 > <0002> LMSDevice.cpp:600 [tid=140623704246016] chan 0 recv buffer of len > 2500 expect 3f19d4dc got 3f19f4bc (3f19f4bc) diff=1fe0 > <0002> LMSDevice.cpp:600 [tid=140623704246016] chan 0 recv buffer of len > 2500 expect 3f19dea0 got 3f19fe80 (3f19fe80) diff=1fe0 > <0002> LMSDevice.cpp:600 [tid=140623704246016] chan 0 recv buffer of len > 2500 expect 3f19e864 got 3f1a0844 (3f1a0844) diff=1fe0 > <0002> LMSDevice.cpp:600 [tid=140623704246016] chan 0 recv buffer of len > 2500 expect 3f19f228 got 3f1a1208 (3f1a1208) diff=1fe0 > <0002> LMSDevice.cpp:600 [tid=140623704246016] chan 0 recv buffer of len > 2500 expect 3f19fbec got 3f1a1bcc (3f1a1bcc) diff=1fe0 > <0002> LMSDevice.cpp:600 [tid=140623704246016] chan 0 recv buffer of len > 2500 expect 3f1a05b0 got 3f1a2590 (3f1a2590) diff=1fe0 > (...) > > Rafael Diniz > > On 4/15/19 9:12 AM, Rafael Diniz wrote: >> Hi Joachim, >> >> This is all very encouraging! I did not even know the Lime could work >> with USB 2 - thanks! >> >> I just realized I have limesuite18.06 (from debian repo) and >> limesuite18.10 (osmocom repo), but I'll upgrade it to git, re-compile >> everything and re-run all previous tests I did here. >> >> Kind regards, >> Rafael Diniz >> >> On 4/12/19 1:02 PM, Joachim Steiger wrote: >>> >>> On 4/12/19 4:05 PM, Rafael Diniz wrote: >>> >>>> It is a SDR hardware, but conceived, as far as I understand, with GSM >>>> usage in mind, considering the integrated GPSDO and so on. As soon as I >>>> put my hands on it I'd like to evaluate if it's worth invest some time >>>> to develop a housing for it and appropriate connections for a very low >>>> power and low cost BTS. >>> i have gotten it to work quite fast with help of the patchset i am >>> working on. >>> it behaves mostly like a limesdr mini with a few addons and proper clock. >>> you currently also need limesuite git master, the tagged 19.01 is too old. >>> >>>>>> With the USB3 LimeSDR, after a few hours I _always_ get a broken trx, >>>>>> with lots of failure messages... >>> i have the same problem. >>> i usually i only use usb2 due to it being much more solid that way. >>> it should not matter anyhow, since we only need low bandwith for gsm. >>> >>>>> I'm sorry to hear this. We're trying to address various problems >>>>> related to LimeSDR devices for quite some time, but progress is >>>>> unfortunately not as quick as one would hope, particularly as LimeSuite >>>>> also evolves and every major version seems to behave quite differently, >>>>> at least in the way how OsmoTRX is using the API. >>> well.. there are a couple of things coming together: >>> limesuite did indeed change its behaviour when it comes to a few things. >>> * it got more streamlined and with it the default settings. e.g. >>> channel0 isnt enabled by default anymore. >>> * some not defined behaviours changed, on which we relied. >>> * i have reordered some of the function calls we do: >>> limesuite doesn't like if you do your filtersetup, frequency, gain, >>> streaming setup and calibration setup in the wrong order. sadly, neither >>> our code nor lms has enough asserts to have anybody notice this soon enough. >>> the good news is: the crew of lime is completely on mission helping us >>> get this sorted. >>> >>>>> In recent weeks, Joachim has been making very good progress with help >>>>> from Lime to resolve some of the most long-standing issues related to >>>>> RF compliance of OsmoTRX on LimeSDR (phase noise, burst shape, ...). >>>>> There should be a patchset pushed to gerrit soon which will address this >>>>> one class of problems. However, this does not adress any USB stability >>>>> related problems, which is a separate class of issues. We have to look >>>>> at them once as a time >>> ack, also see below >>> >>>> This is great, thanks for the report! I hope to have USB problems put >>>> aside with the LimeNET Micro, this is one of the reasons of my question. >>> not really. there IS a spi (or rather 2) connection(s) inbetween the >>> fpga and the rpi according to the documentation, but there is also the >>> ftdi601 bridge like used on the lime mini on the board. >>> this is afaik due to the spi link not achieving high enough bandwidth to >>> satisfy all involved. >>> since the rpi is only usb2, this is also limited.... but i dont see any >>> major issues for using it as a gsm trx. >>> >>>>> One thing I'm a bit missing here is: Where are your comprehensive bug >>>>> reports about this in the osmocom issue tracker? Particularly with >>>>> problems that manifest themselves only every few hours and hence are >>>>> not quick to reproduce, we have to collect those issues and related >>>>> log files, backtraces, ... in the issue tracker. >>>> I'll do this in the next couple of days, sorry for sending the email in >>>> advance of the actual bug report. >>> ps: what would help me out a lot, would be if every bugreport not only >>> references 'limesdr' but also has detail of: >>> * which model (mini, usb, net-micro?...) and revision? >>> * which gateware and firmware release was installed? >>> * which limesuite release or git version? >>> >>> kind regards >>>