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.seAt 3 am the trx stopped again. This time it exited (itself) after
logging large amounts of packet loss,
within 1 second or so....(as far back as the terminal history displays).
Restarting it signal came back within a few seconds.
UHD used: UHD_003.009.005-0-unknown installed with apt.
trx: osmo-trx-uhd_0.4.0.124.42c1_armhf.deb
It seems the interaction beween UHD and TRX is the problem, ( or the TRX
itself ) since just rerunning
trx fixes everything, and the rest of the BTS components seem
functionally intact.
Gullik
On 2018-12-21 13:21, Gullik Webjorn wrote:
>
> Hmm, is the event code actually generated by the uhd driver? It looks like
>
> the definition of EVENT_CODE_SEQ_ERROR that generates this log item comes
>
> from include/uhd/types/metadata.hpp
> <https://files.ettus.com/manual/metadata_8hpp_source.html>
>
> Gullik
>
>
> |
> bool uhd_device::recv_async_msg()
> {
> uhd::async_metadata_t md;
>
> thread_enable_cancel(false);
> bool rc = usrp_dev->get_device()->recv_async_msg(md);
> thread_enable_cancel(true);
> if (!rc)
> return false;
>
> // Assume that any error requires resynchronization
> if (md.event_code != uhd::async_metadata_t::EVENT_CODE_BURST_ACK) {
> aligned = false;
>
> if ((md.event_code != uhd::async_metadata_t::EVENT_CODE_UNDERFLOW) &&
> (md.event_code != uhd::async_metadata_t::EVENT_CODE_TIME_ERROR)) {
> LOGC(DDEV, ERR) << str_code(md);
> }
> }
>
> return true;
> }|
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20181222/cd46e9e2/attachment.htm>