From: ☎ <Max...@fa...> - 2012-10-09 11:36:37
|
Hello. I'm using usrp1 with 2 cards (rfx 900).Way too frequently I see following error: EMERG 140686663538432 OpenBTS.cpp:131:startTransceiver: Transceiver quit with status 139. Exiting. Is it a known bug? What could be causing it? -- best regards, Max, http://fairwaves.ru |
From: Kurtis H. <khe...@cs...> - 2012-10-09 16:17:09
|
I see something similar the first time I try to start OpenBTS, but then not again for a long time. Is this always on boot? On Tue, Oct 9, 2012 at 8:36 PM, ☎ <Max...@fa...> wrote: > Hello. > > I'm using usrp1 with 2 cards (rfx 900).Way too frequently I see following error: > > EMERG 140686663538432 OpenBTS.cpp:131:startTransceiver: Transceiver quit with status > 139. Exiting. > > Is it a known bug? What could be causing it? > > -- > best regards, > Max, http://fairwaves.ru > > ------------------------------------------------------------------------------ > Don't let slow site performance ruin your business. Deploy New Relic APM > Deploy New Relic app performance management and know exactly > what is happening inside your Ruby, Python, PHP, Java, and .NET app > Try New Relic at no cost today and get our sweet Data Nerd shirt too! > http://p.sf.net/sfu/newrelic-dev2dev > _______________________________________________ > Openbts-discuss mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/openbts-discuss |
From: ☎ <Max...@fa...> - 2012-10-09 18:08:54
|
09.10.2012 18:16, Kurtis Heimerl пишет: > I see something similar the first time I try to start OpenBTS, but > then not again for a long time. Is this always on boot? > Never saw it on boot or during phones registration but it appear very often if I'm trying to place a call from one mobile phone to another. -- best regards, Max, http://fairwaves.ru |
From: ☎ <Max...@fa...> - 2012-10-09 18:33:58
|
09.10.2012 18:16, Kurtis Heimerl пишет: > I see something similar the first time I try to start OpenBTS, but > then not again for a long time. Is this always on boot? > I've found a way to reliably reproduce this bug (in my environment at least): - start OpenBTS, no phones active, no commands typed into CLI - start RSSI from osmocom project: http://bb.osmocom.org/trac/wiki/rssi.bin and tune it to OpenBTS arfcn (just type arfcn number and press right softbutton) - press green button on mobile so rssi tool will sync to OpenBTS arfcn - press green button again so rssi will fire single RACH request This immediately kills Transceiver with status 139 Can somebody with usrp1 and osmocom-compatible motorola phone reproduce it? -- best regards, Max, http://fairwaves.ru |
From: Kurtis H. <khe...@cs...> - 2012-10-09 18:37:33
|
This is happening in mainline OpenBTS, not one of the fairwaves branches? If so, I'll file a bug ticket and see if I have time in the near future to figure it out. As always, patches are welcome. On Tue, Oct 9, 2012 at 11:33 AM, ☎ <Max...@fa...> wrote: > 09.10.2012 18:16, Kurtis Heimerl пишет: >> I see something similar the first time I try to start OpenBTS, but >> then not again for a long time. Is this always on boot? >> > I've found a way to reliably reproduce this bug (in my environment at least): > - start OpenBTS, no phones active, no commands typed into CLI > - start RSSI from osmocom project: http://bb.osmocom.org/trac/wiki/rssi.bin and tune > it to OpenBTS arfcn (just type arfcn number and press right softbutton) > - press green button on mobile so rssi tool will sync to OpenBTS arfcn > - press green button again so rssi will fire single RACH request > > This immediately kills Transceiver with status 139 > > Can somebody with usrp1 and osmocom-compatible motorola phone reproduce it? > > -- > best regards, > Max, http://fairwaves.ru > |
From: ☎ <Max...@fa...> - 2012-10-09 19:28:50
|
09.10.2012 20:36, Kurtis Heimerl пишет: > This is happening in mainline OpenBTS, not one of the fairwaves branches? > > If so, I'll file a bug ticket and see if I have time in the near > future to figure it out. As always, patches are welcome. > I'm pretty sure that I hadn't touched Transceiver code but I'll re-test with latest mainline tomorrow. -- best regards, Max, http://fairwaves.ru |
From: Alexander C. <ale...@gm...> - 2012-10-09 22:55:06
|
Max, you should provide log for the Transceiver. What you've posted is just the fact that transceiver is dead. And this may have numerous reasons. Sent from my Android device. -- Regards, Alexander Chemeris CEO, Fairwaves LLC http://fairwaves.ru 09.10.2012 13:38 пользователь "☎" <Max...@fa...> написал: > Hello. > > I'm using usrp1 with 2 cards (rfx 900).Way too frequently I see following > error: > > EMERG 140686663538432 OpenBTS.cpp:131:startTransceiver: Transceiver quit > with status > 139. Exiting. > > Is it a known bug? What could be causing it? > > -- > best regards, > Max, http://fairwaves.ru > > > ------------------------------------------------------------------------------ > Don't let slow site performance ruin your business. Deploy New Relic APM > Deploy New Relic app performance management and know exactly > what is happening inside your Ruby, Python, PHP, Java, and .NET app > Try New Relic at no cost today and get our sweet Data Nerd shirt too! > http://p.sf.net/sfu/newrelic-dev2dev > _______________________________________________ > Openbts-discuss mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/openbts-discuss > |
From: ☎ <Max...@fa...> - 2012-10-10 10:12:33
|
09.10.2012 20:36, Kurtis Heimerl пишет: > This is happening in mainline OpenBTS, not one of the fairwaves branches? Just tested with https://github.com/ttsou/openbts-p2.8 - the bug is in there too. Logs do not shed light as well: ... Oct 10 12:07:31 transceiver: DEBUG 139720966653696 Transceiver.cpp:295:pullRadioVector: receiveFIFO: read radio vector at time: 3:1379484, new size: 8 Oct 10 12:07:31 transceiver: DEBUG 139720966653696 Transceiver.cpp:312:pullRadioVector: Estimated Energy: 8.99444, at time 3:1379484 Oct 10 12:07:31 transceiver: DEBUG 139720966653696 Transceiver.cpp:723:driveTransmitFIFO: radio clock 7:1379485 Oct 10 12:07:31 transceiver: DEBUG 139720966653696 Transceiver.cpp:295:pullRadioVector: receiveFIFO: read radio vector at time: 4:1379484, new size: 11 Oct 10 12:07:31 transceiver: DEBUG 139720966653696 Transceiver.cpp:312:pullRadioVector: Estimated Energy: 7.87718, at time 4:1379484 Oct 10 12:07:31 transceiver: DEBUG 139720966653696 Transceiver.cpp:723:driveTransmitFIFO: radio clock 3:1379486 Oct 10 12:07:31 transceiver: DEBUG 139720966653696 Transceiver.cpp:174:pushRadioVector: transmitFIFO: wrote burst 0x7f13480032c0 at time: 0:1379488 Oct 10 12:07:31 transceiver: DEBUG 139720966653696 Transceiver.cpp:295:pullRadioVector: receiveFIFO: read radio vector at time: 5:1379484, new size: 10 Oct 10 12:07:35 openbts: EMERG 140464193931008 OpenBTS.cpp:125:startTransceiver: Transceiver quit with status 139. Exiting. Would be great if somebody with osmocom-compatible phones could reproduce it. -- best regards, Max, http://fairwaves.ru |
From: Kurtis H. <khe...@cs...> - 2012-10-21 07:06:46
|
I'm not sure what to day, they're running the same code base I am and I haven't seen this. Could be hardware? On Wed, Oct 10, 2012 at 3:12 AM, ☎ <Max...@fa...> wrote: > 09.10.2012 20:36, Kurtis Heimerl пишет: >> This is happening in mainline OpenBTS, not one of the fairwaves branches? > Just tested with https://github.com/ttsou/openbts-p2.8 - the bug is in there too. > > Logs do not shed light as well: > > ... > Oct 10 12:07:31 transceiver: DEBUG 139720966653696 > Transceiver.cpp:295:pullRadioVector: receiveFIFO: read radio vector at time: > 3:1379484, new size: 8 > Oct 10 12:07:31 transceiver: DEBUG 139720966653696 > Transceiver.cpp:312:pullRadioVector: Estimated Energy: 8.99444, at time > 3:1379484 > Oct 10 12:07:31 transceiver: DEBUG 139720966653696 > Transceiver.cpp:723:driveTransmitFIFO: radio clock > 7:1379485 > Oct 10 12:07:31 transceiver: DEBUG 139720966653696 > Transceiver.cpp:295:pullRadioVector: receiveFIFO: read radio vector at time: > 4:1379484, new size: 11 > Oct 10 12:07:31 transceiver: DEBUG 139720966653696 > Transceiver.cpp:312:pullRadioVector: Estimated Energy: 7.87718, at time > 4:1379484 > Oct 10 12:07:31 transceiver: DEBUG 139720966653696 > Transceiver.cpp:723:driveTransmitFIFO: radio clock > 3:1379486 > Oct 10 12:07:31 transceiver: DEBUG 139720966653696 > Transceiver.cpp:174:pushRadioVector: transmitFIFO: wrote burst 0x7f13480032c0 at > time: 0:1379488 > Oct 10 12:07:31 transceiver: DEBUG 139720966653696 > Transceiver.cpp:295:pullRadioVector: receiveFIFO: read radio vector at time: > 5:1379484, new size: 10 > Oct 10 12:07:35 openbts: EMERG 140464193931008 OpenBTS.cpp:125:startTransceiver: > Transceiver quit with status 139. Exiting. > > Would be great if somebody with osmocom-compatible phones could reproduce it. > > -- > best regards, > Max, http://fairwaves.ru > |
From: Thomas T. <tt...@vt...> - 2012-10-21 17:50:36
|
On Wed, Oct 10, 2012 at 6:12 AM, ☎ <Max...@fa...> wrote: > Oct 10 12:07:35 openbts: EMERG 140464193931008 OpenBTS.cpp:125:startTransceiver: > Transceiver quit with status 139. Exiting. Try starting the transceiver separately with gdb attached. First, disable the transceiver executable start. Then start the transceiver independently with 'gdb ./transceiver' before running OpenBTS. Thomas diff --git a/apps/OpenBTS.cpp b/apps/OpenBTS.cpp index cd138eb..301b433 100644 --- a/apps/OpenBTS.cpp +++ b/apps/OpenBTS.cpp @@ -157,8 +157,8 @@ int main(int argc, char *argv[]) COUT("\nStarting the system..."); - Thread transceiverThread; - transceiverThread.start((void*(*)(void*)) startTransceiver, NULL); +// Thread transceiverThread; +// transceiverThread.start((void*(*)(void*)) startTransceiver, NULL); // Start the SIP interface. gSIPInterface.start(); -- |
From: Thomas T. <tt...@vt...> - 2012-10-21 17:43:40
|
On Tue, Oct 9, 2012 at 12:16 PM, Kurtis Heimerl <khe...@cs...> wrote: > I see something similar the first time I try to start OpenBTS, but > then not again for a long time. Is this always on boot? This is likely caused by the firmware load, which only happens on the first run. It might also happen if the firmware is changed between two different OpenBTS starts (e.g. if UHD or standard GNU Radio applications are used in between). The firmware load takes a few seconds and somewhere a timeout is occurring. Thomas |
From: ☎ <Max...@fa...> - 2012-10-26 10:59:44
|
21.10.2012 19:43, Thomas Tsou пишет: > On Tue, Oct 9, 2012 at 12:16 PM, Kurtis Heimerl > <khe...@cs...> wrote: >> I see something similar the first time I try to start OpenBTS, but >> then not again for a long time. Is this always on boot? > This is likely caused by the firmware load, which only happens on the > first run. It might also happen if the firmware is changed between two > different OpenBTS starts (e.g. if UHD or standard GNU Radio > applications are used in between). The firmware load takes a few > seconds and somewhere a timeout is occurring. > Weirdly enough rebuilding everything (openbts+gnuradio) with gcc 4.7 made this issue to disappear. -- best regards, Max, http://fairwaves.ru |
From: Kurtis H. <khe...@cs...> - 2012-10-26 15:45:38
|
Thanks for the tip Thomas, I just pushed a patch fixing it into mainline. On Sun, Oct 21, 2012 at 10:43 AM, Thomas Tsou <tt...@vt...> wrote: > On Tue, Oct 9, 2012 at 12:16 PM, Kurtis Heimerl > <khe...@cs...> wrote: >> I see something similar the first time I try to start OpenBTS, but >> then not again for a long time. Is this always on boot? > > This is likely caused by the firmware load, which only happens on the > first run. It might also happen if the firmware is changed between two > different OpenBTS starts (e.g. if UHD or standard GNU Radio > applications are used in between). The firmware load takes a few > seconds and somewhere a timeout is occurring. > > Thomas |