[RFC] nanoBTS startup sequence (problems on coldstart)
Hi Harald, I have one problem with the BTS on cold start. OpenBSC is sending the RSL connect, Radio Carrier/Baseband attributes too early and we are receiving NACKs from the BTS and the RSL link is never established. The first question is if others have seen this problem? I have solved the problem my moving the OP start/set attributes/RSL connect of the RC and Baseband out of the state change code into the "Software Activated Report". Doing a quick check it seems to still work and solve my cold start problem. Do you think this is a legitimate workaround for the problem right now? In the future we probably should attempt to have a better state machine, report errors, retry and such things... regards holger
Me2. Need to restart bsc_hack the first time after nanobts coldboot. Best Regards Björn Heller Am 17.11.2009 um 21:11 schrieb Holger Freyther <zecke@selfish.org>:
Hi Harald,
I have one problem with the BTS on cold start. OpenBSC is sending the RSL connect, Radio Carrier/Baseband attributes too early and we are receiving NACKs from the BTS and the RSL link is never established.
The first question is if others have seen this problem? I have solved the problem my moving the OP start/set attributes/RSL connect of the RC and Baseband out of the state change code into the "Software Activated Report".
Doing a quick check it seems to still work and solve my cold start problem. Do you think this is a legitimate workaround for the problem right now?
In the future we probably should attempt to have a better state machine, report errors, retry and such things...
regards holger
Ill try later on today when Im at home. Best Regards Björn Heller Am 19.11.2009 um 09:51 schrieb Holger Freyther <zecke@selfish.org>:
On Wednesday 18 November 2009 12:21:39 Bjoern Heller wrote:
Me2. Need to restart bsc_hack the first time after nanobts coldboot.
could you please attempt to test the following patch?
<bsc_start_hack.diff>
On Thu, Nov 19, 2009 at 9:51 AM, Holger Freyther <zecke@selfish.org> wrote:
On Wednesday 18 November 2009 12:21:39 Bjoern Heller wrote:
Me2. Need to restart bsc_hack the first time after nanobts coldboot.
could you please attempt to test the following patch?
I have a nanoBTS at home and it takes two restart for it to work. I just got a another nanoBTS with a different SW version today and without the patch, it would not even start, even when trying multiple times (it seems to reset all OML stuff on disconnect ...), with it, it start reliably. Sylvain
I just got a another nanoBTS with a different SW version today and without the patch, it would not even start, even when trying multiple times (it seems to reset all OML stuff on disconnect ...), with it, it start reliably.
i have mispoken. I also needed to add an SITE MANAGER OPSTART in case I get a "Disabled / Offline" status report for it. Sylvain
On Tue, Nov 17, 2009 at 09:11:36PM +0100, Holger Freyther wrote:
Hi Harald,
I have one problem with the BTS on cold start. OpenBSC is sending the RSL connect, Radio Carrier/Baseband attributes too early and we are receiving NACKs from the BTS and the RSL link is never established.
The first question is if others have seen this problem? I have solved the problem my moving the OP start/set attributes/RSL connect of the RC and Baseband out of the state change code into the "Software Activated Report".
Yes, this is what we had before. If you look at the revision log, it used to be this way and worked more reliably. I already spent way too much time trying to find out the correct state machine but failed.
Doing a quick check it seems to still work and solve my cold start problem. Do you think this is a legitimate workaround for the problem right now?
In the future we probably should attempt to have a better state machine, report errors, retry and such things...
Meanwhile I think it should be sufficient to return to the old code, as it was working quite reliably for many months. -- - Harald Welte <laforge@gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
On Fri, Nov 20, 2009 at 02:54:11PM +0100, Holger Freyther wrote:
On Friday 20 November 2009 14:09:46 Harald Welte wrote:
Meanwhile I think it should be sufficient to return to the old code, as it was working quite reliably for many months.
Should I revert the whole patch or just parts of it?
simply use that new patch that you posted. The old change that I introduced changes multiple things in one patch, as far as I remember... so reverting it might not be a good idea. But at least the decision what to initialize when should be the same as it was before my changes. -- - Harald Welte <laforge@gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
participants (5)
-
246tnt＠gmail.com -
Bjoern Heller -
Harald Welte -
Holger Freyther -
Sylvain Munaut