Hi Thomas,
Could you look into this crash dump of the OpenBTS transceiver? We're trying to run the version from the umtrx_dual_test branch with OsmoBTS.
---------- Forwarded message ---------- From: Andreas Eversberg andreas@eversberg.eu Date: Mon, Jul 8, 2013 at 12:05 PM Subject: Crash of UmTRX transceiver with dual TRX To: Alexander Chemeris alexander.chemeris@gmail.com
using umtrx_dual_test will cause this crash. even when only using a single trx as usual.
openbsc osmo-trx # sh /root/run.umtrx net.core.rmem_max = 50000000 net.core.wmem_max = 524288 linux; GNU C++ version 4.5.4; Boost_104900; UHD_003.004.000-unknown
transceiver: radioInterface.cpp:329: virtual void RadioInterface::pullBuffer(): Assertion `num_rd == (625)' failed. /root/run.umtrx: line 4: 15668 Aborted (core dumped) /files/projects/gsm/osmo-trx/Transceiver52M/transceiver
(gdb) bt full #0 0xb77b1424 in __kernel_vsyscall () No symbol table info available. #1 0xb71a92b1 in raise () from /lib/libc.so.6 No symbol table info available. #2 0xb71aaa8e in abort () from /lib/libc.so.6 No symbol table info available. #3 0xb71a213b in ?? () from /lib/libc.so.6 No symbol table info available. #4 0xb71a21f6 in __assert_fail () from /lib/libc.so.6 No symbol table info available. #5 0x08050562 in RadioInterface::pullBuffer (this=0x85bd3c8) at radioInterface.cpp:329 num_rd = 135212791 __FUNCTION__ = "pullBuffer" __PRETTY_FUNCTION__ = "virtual void RadioInterface::pullBuffer()" #6 0x08050ba3 in RadioInterface::driveReceiveRadio (this=0x85bd3c8) at radioInterface.cpp:254 tN = <optimized out> symbolsPerSlot = <optimized out> rcvSz = <optimized out> readSz = <optimized out> samplesPerBurst = <optimized out> #7 0x08051d63 in DriveLoop::driveReceiveFIFO (this=0x85bdc38) at DriveLoop.cpp:245 No locals. #8 0x08052f60 in RadioDriveLoopAdapter (drive=0x85bdc38) at DriveLoop.cpp:291 No locals. #9 0xb7795f07 in start_thread () from /lib/libpthread.so.0 No symbol table info available. #10 0xb726864e in clone () from /lib/libc.so.6 No symbol table info available.
-- Regards, Alexander Chemeris. CEO, Fairwaves LLC / ООО УмРадио http://fairwaves.ru
On Mon, Jul 8, 2013 at 10:25 AM, Alexander Chemeris alexander.chemeris@gmail.com wrote:
---------- Forwarded message ---------- From: Andreas Eversberg andreas@eversberg.eu Date: Mon, Jul 8, 2013 at 12:05 PM Subject: Crash of UmTRX transceiver with dual TRX To: Alexander Chemeris alexander.chemeris@gmail.com
using umtrx_dual_test will cause this crash. even when only using a single trx as usual.
openbsc osmo-trx # sh /root/run.umtrx net.core.rmem_max = 50000000 net.core.wmem_max = 524288 linux; GNU C++ version 4.5.4; Boost_104900; UHD_003.004.000-unknown
transceiver: radioInterface.cpp:329: virtual void RadioInterface::pullBuffer(): Assertion `num_rd == (625)' failed.
Can you post the error log? This almost certainly a zero return condition related to timestamps on the write/read with the ring buffer. The error should report buffer state.
Thomas
On Mon, Jul 8, 2013 at 12:06 PM, Andreas Eversberg andreas@eversberg.eu wrote:
i never cared about error logging. where is it stored? do i need to enable it somewhere? are there options for deeper debugging?
There are syslog instructions here.
http://wush.net/trac/rangepublic/wiki/DebuggingCode
Alternatively, if you don't like the OpenBTS logging mechanism, you might consider just changing the LOG macros here.
CommonLibs/Logger.h
Thomas
Thomas Tsou wrote:
Alternatively, if you don't like the OpenBTS logging mechanism, you might consider just changing the LOG macros here.
CommonLibs/Logger.h
hi thomas,
this is the output from start to crash:
Jul 8 14:30:13 openbsc transceiver: opening configuration table from path /etc/OpenBTS/OpenBTS.db Jul 8 14:30:14 openbsc transceiver: INFO 3069425408 14:30:14.8 UHDDevice.cpp:563:open: Using discovered UHD device type=umtrx,addr=192.168.10.2,name=UmTRX,serial=14 Jul 8 14:30:15 openbsc transceiver: INFO 3069425408 14:30:15.0 UHDDevice.cpp:335:uhd_msg_handler: Opening a UmTRX device... Jul 8 14:30:15 openbsc transceiver: INFO 3069425408 14:30:15.1 UHDDevice.cpp:335:uhd_msg_handler: Current recv frame size: 1472 bytes Jul 8 14:30:15 openbsc transceiver: INFO 3069425408 14:30:15.1 UHDDevice.cpp:335:uhd_msg_handler: Current send frame size: 1472 bytes Jul 8 14:30:16 openbsc transceiver: INFO 3069425408 14:30:16.4 UHDDevice.cpp:544:parse_dev_type: Using fixed transmit window for UmTRX Device UMTRX-REV0 Jul 8 14:30:16 openbsc transceiver: INFO 3069425408 14:30:16.4 UHDDevice.cpp:618:open: Jul 8 14:30:16 openbsc Single USRP: Jul 8 14:30:16 openbsc Device: UmTRX Device Jul 8 14:30:16 openbsc Mboard 0: UMTRX-REV0 Jul 8 14:30:16 openbsc RX Channel: 0 Jul 8 14:30:16 openbsc RX DSP: 0 Jul 8 14:30:16 openbsc RX Dboard: A Jul 8 14:30:16 openbsc RX Subdev: LMS6002D (0xfa07) - 0 Jul 8 14:30:16 openbsc RX Channel: 1 Jul 8 14:30:16 openbsc RX DSP: 1 Jul 8 14:30:16 openbsc RX Dboard: B Jul 8 14:30:16 openbsc RX Subdev: LMS6002D (0xfa07) - 0 Jul 8 14:30:16 openbsc TX Channel: 0 Jul 8 14:30:16 openbsc TX DSP: 0 Jul 8 14:30:16 openbsc TX Dboard: A Jul 8 14:30:16 openbsc TX Subdev: LMS6002D (0xfa09) - 0 Jul 8 14:30:16 openbsc TX Channel: 1 Jul 8 14:30:16 openbsc TX DSP: 1 Jul 8 14:30:16 openbsc TX Dboard: B Jul 8 14:30:16 openbsc TX Subdev: LMS6002D (0xfa09) - 0 Jul 8 14:30:16 openbsc transceiver: DEBUG 3069425408 14:30:16.4 DriveLoop.cpp:52:DriveLoop: gsmPulse: 0.182762 0j 0.966021 0j 0.182762 0j Jul 8 14:30:16 openbsc transceiver: DEBUG 3069425408 14:30:16.4 Transceiver.cpp:67:Transceiver: gsmPulse: 0.182762 0j 0.966021 0j 0.182762 0j Jul 8 14:30:16 openbsc transceiver: INFO 3051350848 14:30:16.5 DriveLoop.cpp:279:writeClockInterface: ClockInterface: sending IND CLOCK 2 Jul 8 14:30:16 openbsc transceiver: INFO 3051350848 14:30:16.5 Transceiver.cpp:369:driveControl: command is CMD POWEROFF Jul 8 14:30:16 openbsc transceiver: INFO 3051350848 14:30:16.5 DriveLoop.cpp:279:writeClockInterface: ClockInterface: sending IND CLOCK 2 Jul 8 14:30:16 openbsc transceiver: INFO 3051350848 14:30:16.6 Transceiver.cpp:369:driveControl: command is CMD RXTUNE 1781600 Jul 8 14:30:16 openbsc transceiver: INFO 3051350848 14:30:16.8 UHDDevice.cpp:927:setRxFreq: Jul 8 14:30:16 openbsc Tune Result: Jul 8 14:30:16 openbsc Target RF Freq: 1781.600000 (MHz) Jul 8 14:30:16 openbsc Actual RF Freq: 1781.600000 (MHz) Jul 8 14:30:16 openbsc Target DSP Freq: -0.000000 (MHz) Jul 8 14:30:16 openbsc Actual DSP Freq: -0.000000 (MHz) Jul 8 14:30:16 openbsc transceiver: INFO 3051350848 14:30:16.8 DriveLoop.cpp:279:writeClockInterface: ClockInterface: sending IND CLOCK 2 Jul 8 14:30:16 openbsc transceiver: INFO 3051350848 14:30:16.8 Transceiver.cpp:369:driveControl: command is CMD TXTUNE 1876600 Jul 8 14:30:17 openbsc transceiver: INFO 3051350848 14:30:17.0 UHDDevice.cpp:913:setTxFreq: Jul 8 14:30:17 openbsc Tune Result: Jul 8 14:30:17 openbsc Target RF Freq: 1876.600000 (MHz) Jul 8 14:30:17 openbsc Actual RF Freq: 1876.599999 (MHz) Jul 8 14:30:17 openbsc Target DSP Freq: 0.000001 (MHz) Jul 8 14:30:17 openbsc Actual DSP Freq: 0.000001 (MHz) Jul 8 14:30:17 openbsc transceiver: INFO 3051350848 14:30:17.0 DriveLoop.cpp:279:writeClockInterface: ClockInterface: sending IND CLOCK 2 Jul 8 14:30:17 openbsc transceiver: INFO 3051350848 14:30:17.0 Transceiver.cpp:369:driveControl: command is CMD SETTSC 7 Jul 8 14:30:17 openbsc transceiver: DEBUG 3051350848 14:30:17.0 sigProcLib.cpp:885:generateMidamble: midamble autocorr: 0.182759 1.34932e-06j 0.966021 -0.182756j -0.18276 7.19389e-07j -0.966021 -0.182765j -2.01039 7.0521e-08j -10.6262 -0.182759j -2.01038 9.81044e-07j -0.966021 0.182763j -0.182762 1.55789e-07j 3.22465e-08 -4.63739e-07j -3.39939e-07 -7.24713e-07j -1.10399e-06 -2.67657e-06j 2.92419 2.28714e-06j 15.4563 1.35901e-05j 2.9242 1.58791e-06j 2.43788e-06 -4.25888e-06j 7.91297e-06 7.79799e-07j 8.01918e-07 8.40149e-06j -0.182766 -8.68613e-07j -0.966024 0.548273j -1.64487 1.93203j -8.69419 0.182726j -1.27933 -3.94435e-06j 0.966019 -0.182755j 0.548286 -1.93204j 0.966024 -0.913802j Jul 8 14:30:17 openbsc transceiver: DEBUG 3051350848 14:30:17.0 sigProcLib.cpp:887:generateMidamble: TOA: 13.002 Jul 8 14:30:17 openbsc transceiver: INFO 3051350848 14:30:17.0 DriveLoop.cpp:279:writeClockInterface: ClockInterface: sending IND CLOCK 2 Jul 8 14:30:17 openbsc transceiver: INFO 3051350848 14:30:17.0 Transceiver.cpp:369:driveControl: command is CMD POWERON Jul 8 14:30:17 openbsc transceiver: INFO 3051350848 14:30:17.0 UHDDevice.cpp:672:start: Starting USRP... Jul 8 14:30:17 openbsc transceiver: INFO 3051350848 14:30:17.1 UHDDevice.cpp:691:start: The current time is 0.0100679 seconds Jul 8 14:30:17 openbsc transceiver: DEBUG 3051350848 14:30:17.1 radioInterface.cpp:174:start: Radio started Jul 8 14:30:17 openbsc transceiver: INFO 3051350848 14:30:17.1 DriveLoop.cpp:279:writeClockInterface: ClockInterface: sending IND CLOCK 2 Jul 8 14:30:17 openbsc transceiver: ERR 3051318080 14:30:17.1 UHDDevice.cpp:774:readSamples: Number of requested channels does not match build Jul 8 14:30:17 openbsc transceiver: DEBUG 3051318080 14:30:17.1 radioInterface.cpp:328:pullBuffer: Rx read -1 samples from device
regards,
andreas
Andreas Eversberg wrote:
Jul 8 14:30:17 openbsc transceiver: ERR 3051318080 14:30:17.1 UHDDevice.cpp:774:readSamples: Number of requested channels does not match build
got it working. just started transceiver with option "2".
now i got the following problem while provisioning second trx: (debug output of osmo-bts)
trx_if.c:362 transceiver rejected TRX command with response: 'RSP SETTSC 1 7' (trx 1)
Andreas Eversberg wrote:
trx_if.c:362 transceiver rejected TRX command with response: 'RSP SETTSC 1 7' (trx 1)
just made osmo-bts ignore that. now i can provision both trx with similar setting, except slot type and and ARFCN. it seems to work now, but i get no rf power on second trx. i use ARFCN and 869 and 877.
Andreas Eversberg wrote:
just made osmo-bts ignore that. now i can provision both trx with similar setting, except slot type and and ARFCN. it seems to work now, but i get no rf power on second trx. i use ARFCN and 869 and 877.
i do also get no reception from the phone at second trx (late assignment, my tester showed me power on TS0 uplink). seems that rx and tx does not work for some reason.
also i found that the transceiver leaks about 2 megabytes every second. after some minutes my test machine runs out of mem space.
On Mon, Jul 8, 2013 at 3:33 PM, Andreas Eversberg andreas@eversberg.eu wrote:
Andreas Eversberg wrote:
just made osmo-bts ignore that. now i can provision both trx with similar setting, except slot type and and ARFCN. it seems to work now, but i get no rf power on second trx. i use ARFCN and 869 and 877.
i do also get no reception from the phone at second trx (late assignment, my tester showed me power on TS0 uplink). seems that rx and tx does not work for some reason.
If the slots aren't enabled, then both uplink and downlink will be disabled. This patch should cause Tx slot setting to be ignored and will send whatever core submits. We need the slot setting to set the TSC / RACH correlation, so Rx is not as simple.
also i found that the transceiver leaks about 2 megabytes every second. after some minutes my test machine runs out of mem space.
Should be resolved in the same patch.
Thomas
Thomas Tsou wrote:
also i found that the transceiver leaks about 2 megabytes every second.
after some minutes my test machine runs out of mem space.
Should be resolved in the same patch.
yes, it is gone.
i managed to make it work. i had a bug, so second TRX was ARFCN 0.
thanx allot, i will do more testings.
On Mon, Jul 8, 2013 at 5:58 PM, Thomas Tsou tom@tsou.cc wrote:
On Mon, Jul 8, 2013 at 3:33 PM, Andreas Eversberg andreas@eversberg.eu wrote:
Andreas Eversberg wrote:
just made osmo-bts ignore that. now i can provision both trx with similar setting, except slot type and and ARFCN. it seems to work now, but i get no rf power on second trx. i use ARFCN and 869 and 877.
i do also get no reception from the phone at second trx (late assignment, my tester showed me power on TS0 uplink). seems that rx and tx does not work for some reason.
If the slots aren't enabled, then both uplink and downlink will be disabled. This patch should cause Tx slot setting to be ignored and will send whatever core submits. We need the slot setting to set the TSC / RACH correlation, so Rx is not as simple.
also i found that the transceiver leaks about 2 megabytes every second. after some minutes my test machine runs out of mem space.
Should be resolved in the same patch.
Could you please push this to the osmo-trx repository? https://github.com/fairwaves/osmo-trx
-- Regards, Alexander Chemeris. CEO, Fairwaves LLC / ООО УмРадио http://fairwaves.ru
On Mon, Jul 8, 2013 at 5:24 PM, Alexander Chemeris alexander.chemeris@gmail.com wrote:
On Mon, Jul 8, 2013 at 5:58 PM, Thomas Tsou tom@tsou.cc wrote:
i do also get no reception from the phone at second trx (late assignment, my tester showed me power on TS0 uplink). seems that rx and tx does not work for some reason.
If the slots aren't enabled, then both uplink and downlink will be disabled. This patch should cause Tx slot setting to be ignored and will send whatever core submits. We need the slot setting to set the TSC / RACH correlation, so Rx is not as simple.
also i found that the transceiver leaks about 2 megabytes every second. after some minutes my test machine runs out of mem space.
Should be resolved in the same patch.
Could you please push this to the osmo-trx repository? https://github.com/fairwaves/osmo-trx
Do we want to permanently disable the filler table? This is a breaking change for OpenBTS. Or do you just mean the memory leak fix.
Thomas
On Mon, Jul 8, 2013 at 7:53 PM, Thomas Tsou tom@tsou.cc wrote:
On Mon, Jul 8, 2013 at 5:24 PM, Alexander Chemeris alexander.chemeris@gmail.com wrote:
On Mon, Jul 8, 2013 at 5:58 PM, Thomas Tsou tom@tsou.cc wrote:
i do also get no reception from the phone at second trx (late assignment, my tester showed me power on TS0 uplink). seems that rx and tx does not work for some reason.
If the slots aren't enabled, then both uplink and downlink will be disabled. This patch should cause Tx slot setting to be ignored and will send whatever core submits. We need the slot setting to set the TSC / RACH correlation, so Rx is not as simple.
also i found that the transceiver leaks about 2 megabytes every second. after some minutes my test machine runs out of mem space.
Should be resolved in the same patch.
Could you please push this to the osmo-trx repository? https://github.com/fairwaves/osmo-trx
Do we want to permanently disable the filler table? This is a breaking change for OpenBTS. Or do you just mean the memory leak fix.
Memory leak is a must.
Constant Rx on disabled slots is only useful for testing. It would be nice if this could be configurable (e.g. over the transceiver API), but that's not a hard requirement.
-- Regards, Alexander Chemeris. CEO, Fairwaves LLC / ООО УмРадио http://fairwaves.ru
On Mon, Jul 8, 2013 at 3:07 PM, Andreas Eversberg andreas@eversberg.eu wrote:
Andreas Eversberg wrote:
trx_if.c:362 transceiver rejected TRX command with response: 'RSP SETTSC 1 7' (trx 1)
just made osmo-bts ignore that. now i can provision both trx with similar setting, except slot type and and ARFCN. it seems to work now, but i get no rf power on second trx. i use ARFCN and 869 and 877.
If the slot isn't set then the burst will be zero'd at the output of the filler table. There is an assumption of the order of commands.
Global Settings
1. SETTSC 2. POWERON
TRX Specific
3. SETSLOT
Thomas
On Mon, Jul 8, 2013 at 2:58 PM, Andreas Eversberg andreas@eversberg.eu wrote:
Andreas Eversberg wrote:
Jul 8 14:30:17 openbsc transceiver: ERR 3051318080 14:30:17.1 UHDDevice.cpp:774:readSamples: Number of requested channels does not match build
got it working. just started transceiver with option "2".
Great. I will create a patch to dynamically handle the single channel case. Currently it's hard coded at build time.
now i got the following problem while provisioning second trx: (debug output of osmo-bts)
trx_if.c:362 transceiver rejected TRX command with response: 'RSP SETTSC 1 7' (trx 1)
The transceiver control portion is setup for OpenBTS, which expects that the TSC value is set statically for all TRX's. It's rejecting because the TSC value is being set twice; more specifically, the OpenBTS assumption is that these are set once before power on. This needs to be changed.
Should we now assume that each TRX is setup an independent manner?
Thomas
Thomas Tsou wrote:
The transceiver control portion is setup for OpenBTS, which expects that the TSC value is set statically for all TRX's. It's rejecting because the TSC value is being set twice; more specifically, the OpenBTS assumption is that these are set once before power on. This needs to be changed.
Should we now assume that each TRX is setup an independent manner?
i see no problem with that reject. i think it makes sense to reject TSC, if it does not match the TSC of first TRX. since trx manager interface seems to be designed to handle each TRX individually (even might be possible to run on different transceivers for one BTS), i would think it is a good idea to set TSC for every TRX.
On Mon, Jul 8, 2013 at 3:27 PM, Andreas Eversberg andreas@eversberg.eu wrote:
Thomas Tsou wrote:
Should we now assume that each TRX is setup an independent manner?
i see no problem with that reject. i think it makes sense to reject TSC, if it does not match the TSC of first TRX. since trx manager interface seems to be designed to handle each TRX individually (even might be possible to run on different transceivers for one BTS), i would think it is a good idea to set TSC for every TRX.
We can easily move to separate TSC settings be removing the static identifier. The only issue then is that OpenBTS will no longer work. Perhaps the larger limitation is that we can't set TSC dynamically after POWERON. This is because the midamble correlation sequence is regenerated and is not thread safe.
In summary, we can easily have separate TSC, but they need to be set before the POWERON command is received.
Thomas
On Mon, Jul 8, 2013 at 6:34 PM, Thomas Tsou tom@tsou.cc wrote:
On Mon, Jul 8, 2013 at 3:27 PM, Andreas Eversberg andreas@eversberg.eu wrote:
Thomas Tsou wrote:
Should we now assume that each TRX is setup an independent manner?
i see no problem with that reject. i think it makes sense to reject TSC, if it does not match the TSC of first TRX. since trx manager interface seems to be designed to handle each TRX individually (even might be possible to run on different transceivers for one BTS), i would think it is a good idea to set TSC for every TRX.
We can easily move to separate TSC settings be removing the static identifier. The only issue then is that OpenBTS will no longer work. Perhaps the larger limitation is that we can't set TSC dynamically after POWERON. This is because the midamble correlation sequence is regenerated and is not thread safe.
There could be two command sets - one for OpenBTS compatibility, one for more advanced systems.
-- Regards, Alexander Chemeris. CEO, Fairwaves LLC / ООО УмРадио http://fairwaves.ru
i see no problem with that reject. i think it makes sense to reject TSC, if it does not match the TSC of first TRX. since trx manager interface seems to be designed to handle each TRX individually (even might be possible to run on different transceivers for one BTS), i would think it is a good idea to set TSC for every TRX.
We can easily move to separate TSC settings be removing the static identifier. The only issue then is that OpenBTS will no longer work. Perhaps the larger limitation is that we can't set TSC dynamically after POWERON. This is because the midamble correlation sequence is regenerated and is not thread safe.
There could be two command sets - one for OpenBTS compatibility, one for more advanced systems.
i think that is not requited. TSC at openbsc is a global setting. by the specs, it can be set for every timeslot individualy. i think it would be good to keep it global, so the transceiver remains compatible to openbsc. i can remove the TSC command from osmo-bts. alternatively, as stated above, setting the same TSC, which is already running at TRX 0 could be just acknowledged, different TSC rejected.
Andreas Eversberg wrote:
i see no problem with that reject. i think it makes sense to reject TSC, if it does not match the TSC of first TRX. since trx manager interface seems to be designed to handle each TRX individually (even might be possible to run on different transceivers for one BTS), i would think it is a good idea to set TSC for every TRX.
We can easily move to separate TSC settings be removing the static identifier. The only issue then is that OpenBTS will no longer work. Perhaps the larger limitation is that we can't set TSC dynamically after POWERON. This is because the midamble correlation sequence is regenerated and is not thread safe.
There could be two command sets - one for OpenBTS compatibility, one for more advanced systems.
i think that is not requited. TSC at openbsc is a global setting. by the specs, it can be set for every timeslot individualy. i think it would be good to keep it global, so the transceiver remains compatible to openbsc. i can remove the TSC command from osmo-bts. alternatively, as stated above, setting the same TSC, which is already running at TRX 0 could be just acknowledged, different TSC rejected.
once TSC is set, it cannot be changed, even after poweroff. i must restart transceiver before every new start of osmo-bts. before osmo-bts start provisioning transceiver, it sends poweroff to all trx. also if bsc fails, transceiver is turned off and provisioned after bsc link is restored. with the single trx version of transceiver it worked all the time. i think there should be a solution for that problem.
On Mon, Jul 8, 2013 at 11:12 PM, Andreas Eversberg andreas@eversberg.eu wrote:
i see no problem with that reject. i think it makes sense to reject TSC, if it does not match the TSC of first TRX. since trx manager interface seems to be designed to handle each TRX individually (even might be possible to run on different transceivers for one BTS), i would think it is a good idea to set TSC for every TRX.
We can easily move to separate TSC settings be removing the static identifier. The only issue then is that OpenBTS will no longer work. Perhaps the larger limitation is that we can't set TSC dynamically after POWERON. This is because the midamble correlation sequence is regenerated and is not thread safe.
There could be two command sets - one for OpenBTS compatibility, one for more advanced systems.
i think that is not requited. TSC at openbsc is a global setting. by the specs, it can be set for every timeslot individualy. i think it would be good to keep it global, so the transceiver remains compatible to openbsc. i can remove the TSC command from osmo-bts. alternatively, as stated above, setting the same TSC, which is already running at TRX 0 could be just acknowledged, different TSC rejected.
once TSC is set, it cannot be changed, even after poweroff. i must restart transceiver before every new start of osmo-bts. before osmo-bts start provisioning transceiver, it sends poweroff to all trx. also if bsc fails, transceiver is turned off and provisioned after bsc link is restored. with the single trx version of transceiver it worked all the time. i think there should be a solution for that problem.
And this leads us to the question that POWEROFF in the umtrx_dual_test is not implemented at all.
Thomas, could you please rebase the umtrx_dual_test onto the recent "fairwaves/master" branch? The DriveLoop/Transceiver split breaks a number of patches and it would be better if you do it yourself.
-- Regards, Alexander Chemeris. CEO, Fairwaves LLC / ООО УмРадио http://fairwaves.ru
Alexander Chemeris wrote:
And this leads us to the question that POWEROFF in the umtrx_dual_test is not implemented at all.
Thomas, could you please rebase the umtrx_dual_test onto the recent "fairwaves/master" branch? The DriveLoop/Transceiver split breaks a number of patches and it would be better if you do it yourself.
oops, i did a mistake. even single trx support never supported poweroff. the reason why it worked for me is that i send "SETTSC" and "SETBSIC" commands to the transceiver. (calypso-bts requires "SETBSIC" because it generates SCH itself). because one of these commands will fail, osmo-bts ignores the response, so it does for "SETTSC".
i think it is not a clean solution to send both commands and ignore the result. the "POWEROFF" should shutdown transmitter, stop receiving and allow "SETTSC" (even with different value) again.
On Mon, Jul 8, 2013 at 4:01 PM, Andreas Eversberg andreas@eversberg.eu wrote:
oops, i did a mistake. even single trx support never supported poweroff. the reason why it worked for me is that i send "SETTSC" and "SETBSIC" commands to the transceiver. (calypso-bts requires "SETBSIC" because it generates SCH itself). because one of these commands will fail, osmo-bts ignores the response, so it does for "SETTSC".
i think it is not a clean solution to send both commands and ignore the result. the "POWEROFF" should shutdown transmitter, stop receiving and allow "SETTSC" (even with different value) again.
Agreed. The larger issue isn't that the POWEROFF command isn't implemented, it's that the transceiver was written without explicit state management. Thread deallocation is the most annoying issue. We can't shutdown threads right now because we don't know what threads are running.
https://github.com/ttsou/openbts-multi-arfcn/commit/0cbdb59b61 https://github.com/ttsou/openbts-multi-arfcn/commit/8f2d863485
IMO, the preferred solution is to replace thread abstraction or make the signals work. I think the latter was the original intention with shutdown triggering on pthread_cancel(), but for whatever reason that was never implemented.
Thomas
On Tue, Jul 9, 2013 at 12:35 AM, Thomas Tsou tom@tsou.cc wrote:
IMO, the preferred solution is to replace thread abstraction or make the signals work. I think the latter was the original intention with shutdown triggering on pthread_cancel(), but for whatever reason that was never implemented.
I've posted a big patchset for this to the OpenBSC mailing list. A bit more effort and it'll be working.
-- Regards, Alexander Chemeris. CEO, Fairwaves LLC / ООО УмРадио http://fairwaves.ru
On Mon, Jul 8, 2013 at 3:54 PM, Alexander Chemeris alexander.chemeris@gmail.com wrote:
And this leads us to the question that POWEROFF in the umtrx_dual_test is not implemented at all.
This is not a problem caused by the dual_trx branch. POWEROFF has never been implemented in _any_ branch. It has been always been dummy command since the first OpenBTS release. The dual_trx branch does maintain slightly stricter state variables in order to manage shared resource control, and may return more error conditions (instead of ignoring them). That's the likely the cause of different behaviour.
Yes, as you know, it's a major problem and the transceiver code doesn't release resources in a sane way. Shutdown is broken, and it always has been.
Thomas, could you please rebase the umtrx_dual_test onto the recent "fairwaves/master" branch? The DriveLoop/Transceiver split breaks a number of patches and it would be better if you do it yourself.
I will do that.
Thomas
-
Alexander Chemeris -
Andreas Eversberg -
Thomas Tsou