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>