Dear Ivan, all,
I started to do work on the PCU and didn't compile C++ for a long time.
I was surprised how long it takes to compile the code. From my point
of view we are taking the hit of g++ without really using any of the
features that C++ vould provide (e.g. no stack variables with automatic
cleanup..).
osmo_timer_del is an idempotent operation. There is no requirement
to check if it is running. If you don't want a timer to run, delete
it. Maybe one should have called the method _unschedule, _cancel to
make this more clear.
---
src/gprs_bssgp_pcu.cpp | 6 ++----
src/sysmo_sock.cpp | 3 +--
2 files changed, 3 insertions(+), 6 deletions(-)
diff --git a/src/gprs_bssgp_pcu.cpp b/src/gprs_bssgp_pcu.cpp
index 54753b8..c791913 100644
--- a/src/gprs_bssgp_pcu.cpp
+++ b/src/gprs_bssgp_pcu.cpp
@@ -515,8 +515,7 @@ static int nsvc_signal_cb(unsigned int subsys, unsigned int signal,
case S_NS_BLOCK:
if (nsvc_unblocked) {
nsvc_unblocked = 0;
- if (osmo_timer_pending(&bvc_timer))
- osmo_timer_del(&bvc_timer);
+ osmo_timer_del(&bvc_timer);
bvc_sig_reset = 0;
bvc_reset = 0;
bvc_unblocked = 0;
@@ -646,8 +645,7 @@ void gprs_bssgp_destroy(void)
if (!bssgp_nsi)
return;
- if (osmo_timer_pending(&bvc_timer))
- osmo_timer_del(&bvc_timer);
+ osmo_timer_del(&bvc_timer);
osmo_signal_unregister_handler(SS_L_NS, nsvc_signal_cb, NULL);
diff --git a/src/sysmo_sock.cpp b/src/sysmo_sock.cpp
index a4cc6de..d4fb5a6 100644
--- a/src/sysmo_sock.cpp
+++ b/src/sysmo_sock.cpp
@@ -304,8 +304,7 @@ void pcu_l1if_close(void)
if (!state)
return;
- if (osmo_timer_pending(&state->timer))
- osmo_timer_del(&state->timer);
+ osmo_timer_del(&state->timer);
bfd = &state->conn_bfd;
if (bfd->fd > 0)
--
1.8.3.2
Dear Andreas, Ivan,
when trying to understand the CPU usage of the PCU without having
any subscribers I noticed the following backtrace:
#0 _int_malloc (av=0x402fe4d4, bytes=52) at malloc.c:3241
#1 0x4023a3b8 in __GI___libc_malloc (bytes=52) at malloc.c:2859
#2 0x4929b6e8 in _talloc_zero () from /usr/lib/libosmocore.so.4
#3 0x49422e44 in vector_init () from /usr/lib/libosmovty.so.0
#4 0x4941f1f8 in install_element () from /usr/lib/libosmovty.so.0
#5 0x492e602c in gprs_ns_vty_init () from /usr/lib/libosmogb.so.2
#6 0x0001b670 in gprs_bssgp_create (local_port=<optimized out>, sgsn_ip=184194049,
sgsn_port=<optimized out>, nsei=<optimized out>, nsvci=2, bvci=2, mcc=<optimized out>,
mnc=<optimized out>, lac=1, rac=0, cell_id=0) at gprs_bssgp_pcu.cpp:585
#7 0x00016990 in pcu_rx_info_ind (info_ind=0x7) at pcu_l1_if.cpp:431
#8 pcu_rx (msg_type=<optimized out>, pcu_prim=0x3) at pcu_l1_if.cpp:577
#9 0x00017914 in pcu_sock_read (bfd=0x6a3f0) at sysmo_sock.cpp:151
#10 pcu_sock_cb (bfd=0x6a3f0, flags=1) at sysmo_sock.cpp:218
#11 0x49294ff4 in osmo_select_main () from /usr/lib/libosmocore.so.4
#12 0x0000a668 in main (argc=<optimized out>, argv=0xbee40b04) at pcu_main.cpp:219
This means when a info indication is received gprs_bssgp_create will
be called which will re-initialize the VTY commands but more important
re-set vty_nsi inside the VTY code of libosmogb. But it also means that
vty_nsi will be a dangling pointer in case of
1.) gprs_ns_nsip_connect, btsctx_alloc, gprs_ns_nsip_listen fail
2.) Between the sysmobts software exiting and re-starting and bringing
OML back up
3.) More cases that I might not understand.
The dangling pointer will lead to a crash when the VTY of the PCU is
used in such situation/window.
does any of you care to fix that race? I think the easiest would be
to just close/open/bind/listen/connect on the NS once we get a new
config.
holger
--
- Holger Freyther <hfreyther(a)sysmocom.de> http://www.sysmocom.de/
=======================================================================
* sysmocom - systems for mobile communications GmbH
* Schivelbeiner Str. 5
* 10439 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B
* Geschaeftsfuehrer / Managing Directors: Holger Freyther, Harald Welte
hi ivan,
there is still one patch left in my jolly/meas branch that has not been
mergen:
commit 890ae7e4fcf7d74c238ed2ce0e3f090f1af492c2
and the fixup:
commit 784f9004ba3576ede57dada63876451f32d2d852
it keeps the timing advance from a TBF and uses it for new TBFs, so the
mobile can be at any distance. this was tested up to 4 km (with sysmobts).
if it is ok, i will combine these patches and push the result to master.
regards,
andreas
Dear Ivan,
it appears to that starting from your configure.ac change the vty tests
can not be eanbled anymore. E.g. compare this with the build results on
the jenkins after your change.
do you have time to fix that today?
holger
--
- Holger Freyther <hfreyther(a)sysmocom.de> http://www.sysmocom.de/
=======================================================================
* sysmocom - systems for mobile communications GmbH
* Schivelbeiner Str. 5
* 10439 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B
* Geschaeftsfuehrer / Managing Directors: Holger Freyther, Harald Welte
From: Holger Hans Peter Freyther <zecke(a)selfish.org>
Make the code handle SIGTERM. This way the pcu can be easily stopped
with a sysvinit script.
---
src/pcu_main.cpp | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/pcu_main.cpp b/src/pcu_main.cpp
index f135cfd..4fae14b 100644
--- a/src/pcu_main.cpp
+++ b/src/pcu_main.cpp
@@ -114,6 +114,7 @@ void sighandler(int sigset)
switch (sigset) {
case SIGINT:
+ case SIGTERM:
/* If another signal is received afterwards, the program
* is terminated without finishing shutdown process.
*/
--
1.7.10.4
hi,
steve and me experienced a problem with dissecting a "packet resource
request" at pcu. the patch i attached will show the following output:
$ make && src/osmo-pcu
PayloadType = 1 | spare = 0 | R = 0 | MESSAGE_TYPE = 5 |
Exist_ACCESS_TYPE = 1 | ACCESS_TYPE = 3 | : ID | Choice
PacketResourceRequestID = 1 | u.TLLI = 0x7ee0e8fd | : End ID |
Exist_MS_Radio_Access_capability = 1 | : MS_Radio_Access_capability |
MS_RA_capability_value { | Choice MS_RA_capability_value_Choice = 1 |
u.Content length = 34 | RF_Power_Capability = 4 | Exist_A5_bits = 1 |
A5_bits = 96 | ES_IND = 1 | PS = 0 | VGCS = 0 | VBS = 0 |
Exist_Multislot_capability = 1 | : Multislot_capability |
Exist_HSCSD_multislot_class = 0 | Exist_GPRS_multislot_class = 1 |
GPRS_multislot_class = 10 ....
this is all correct, but then i patched the get_ms_class_by_capability()
function at grps_rlcmac_data.c:
...
printf("we have = %d\n", cap->Count_MS_RA_capability_value);
for (i = 0; i < cap->Count_MS_RA_capability_value; i++) {
printf("index=%d\n", cap->MS_RA_capability_value[i].IndexOfAccTech);
printf("exists multislot capability %d\n",
cap->MS_RA_capability_value[i].u.Content.Exist_Multislot_capability);
printf("exists class %d\n",
cap->MS_RA_capability_value[i].u.Content.Multislot_capability.Exist_GPRS_multislot_class);
printf("class %d\n",
cap->MS_RA_capability_value[i].u.Content.Multislot_capability.GPRS_multislot_class);
...
the output continues as this:
we have = 2
index=2
exists multislot capability 0
exists class 1
class 10
index=0
exists multislot capability 0
exists class 0
class 0
the "class 10" is correct, also it is correct that the class only exists
in the first entry of the capability array. the output of the dissector
states that multislot capability exists (Exist_Multislot_capability =
1), but if i look at the structure, this field is not set.
i looked at the dissector code, but don't really understand why
CSN_NEXT_EXIST works for some elements and not for others.
any ideas?
regards,
andreas
Dear fellow Osmcoom developers,
it is my pleasure to finally announce the date + venue of OsmoDevCon
2013:
Date: April 04 through April 07, 2013
Place: IN-Berlin, Lehrter Str. 53, Berlin
Like last year, this is an event for developers of the various Osmocom
proejects. Reservation and confirmation of reservation is required.
The event is free of charge. The Room is made available by IN-Berlin
e.V., an Internet related non-profit organization. Lunch catering will
be sponsored (so far by sysmocom GmbH, but if any other sponsors come
up, we are happy to share the cost).
So all you have to cover is your own travel + accomodation costs, as
well as breakfast and dinner. If you are an active developer and cannot
afford travel/accomodation, please let me know and I'll see if we can do
something about it.
If you would like to attend, please send a message to
laforge(a)gnumonks.org applying for registration of the event. The
registration deadline is March 5, i.e. one week from now.
There is no detailed schedule of talks yet. I will start a separate
discussion suggesting / collecting topics in the next couple of days.
More information is (and will be made) available at
http://openbsc.osmocom.org/trac/wiki/OsmoDevCon2013
Further discussion regarding the event should be directed at the
osmocom-event-orga(a)lists.osmocom.org mailing list, to avoid
cross-posting over the various project-specific lists.
Best regards and happy hacking,
Harald
--
- Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)