25 Aug
2011
25 Aug
'11
6:03 p.m.
I've pulled everything fresh from trunk in my quest to get multiple BTS's
working on one E1 card. :) However, I'm seeing a core dump when I start
osmo-nitb in the box now.
A BT is available here:
http://pastebin.com/KAaxt5d3
This is in a configuration where I only have one BTS configured. Though I
get the same issue if I have more than one configured too.
Thanks,
Gus
26 Aug
26 Aug
8:02 a.m.
hi Gus,
On Thu, Aug 25, 2011 at 09:03:48AM -0700, Gus Bourg wrote:
I've pulled everything fresh from trunk in my
quest to get multiple BTS's
working on one E1 card. :) However, I'm seeing a core dump when I start
osmo-nitb in the box now.
A BT is available here:
http://pastebin.com/KAaxt5d3
the backtrace clearly looks as if the experimental and untested
laforge/lapd branch of openbsc.git was used.
The suggested configuration is 'master' from libosmocore, libosmo-abis
and openbsc.git
Regards,
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)
5:22 p.m.
On Thu, Aug 25, 2011 at 11:02 PM, Harald Welte <laforge(a)gnumonks.org> wrote:
the backtrace clearly looks as if the experimental and
untested
laforge/lapd branch of openbsc.git was used.
Sorry about that, you're right - I got my branches mixed up.
The suggested configuration is 'master' from
libosmocore, libosmo-abis
and openbsc.git
I've been having troubles getting master to compile since the move to
osmo-abis. I have the latest version of osmo-abis (and osmocore) installed,
but for some reason I'm getting this:
bts_ericsson_rbs2000.c: In function ‘start_sabm_in_line’:
bts_ericsson_rbs2000.c:73:36: error: ‘struct <anonymous>’ has no member
named ‘lapd’
bts_ericsson_rbs2000.c:75:35: error: ‘struct <anonymous>’ has no member
named ‘lapd’
If I comment out these lines, I run into the same problem with the Nokias
(which I need) as they're trying to send sabms too.
I'm confused why it says its anonymous - when it should be an e1inp_ts. The
offending line is:
lapd_sap_start(ts->driver.dahdi.lapd, link->tei, link->sapi);
Looking at e1_input.h from libosmo-abis:
struct e1inp_ts {
...
struct e1inp_line *line;
struct lapd_instance *lapd;
...
union {
...
struct {
/* DAHDI driver has one fd for each ts */
struct osmo_fd fd;
} dahdi;
...
} driver;
};
Is this correct? I don't think I'm including an old non libosmo-abis
e1_input.h.
Thanks,
Gus
7:16 p.m.
Hi Gus,
On Fri, Aug 26, 2011 at 08:22:50AM -0700, Gus Bourg wrote:
I've been having troubles getting master to
compile since the move to
osmo-abis. I have the latest version of osmo-abis (and osmocore) installed,
but for some reason I'm getting this:
bts_ericsson_rbs2000.c: In function ‘start_sabm_in_line’:
bts_ericsson_rbs2000.c:73:36: error: ‘struct <anonymous>’ has no member
named ‘lapd’
bts_ericsson_rbs2000.c:75:35: error: ‘struct <anonymous>’ has no member
named ‘lapd’
For some strange reason I didn't run into this bug so far. I've now
built from a 'make distclean' and could clearly reproduce it.
git commit b4d913d336d7a52dff840378726b1d3dc5f81268 of current master
should fix it.
Sorry for the inconvenience.
--
- 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)
27 Aug
27 Aug
1:03 a.m.
Hi Harald,
On Fri, Aug 26, 2011 at 10:16 AM, Harald Welte <laforge(a)gnumonks.org> wrote:
Hi Gus,
For some strange reason I didn't run into this bug so far. I've now
built from a 'make distclean' and could clearly reproduce it.
git commit b4d913d336d7a52dff840378726b1d3dc5f81268 of current master
should fix it.
Thanks for fixing this! I can confirm that it compiles now - and my BTS
comes up with trunk. However, when I configure two BTS's, I get a core dump
(for real this time : -)
Here's the startup:
http://pastebin.com/2ER4CgyX
And here's the backtrace:
http://pastebin.com/vHK5cZmV
Thanks,
Gus
1:54 p.m.
Hi Gus,
On Fri, Aug 26, 2011 at 04:03:52PM -0700, Gus Bourg wrote:
Thanks for fixing this! I can confirm that it
compiles now - and my BTS
comes up with trunk. However, when I configure two BTS's, I get a core dump
(for real this time : -)
feel free to debug this further by yourself. It's a bit hard without
access to the equipment. For some reason, ts->lapd is NULL, i.e. there
was no LAPD instance allocated for this timeslot.
The allocation happens at line 434 of libosmo-abis/src/input/dahdi.c
So the first step would be to add some LOGP messages about which LAPD
instances are allocated (or released). This can be used to see if the
expected LAPD instances (one on each signalling timeslot) are created
or not.
--
- 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)
28 Aug
28 Aug
11:36 p.m.
On Sat, Aug 27, 2011 at 01:54:45PM +0200, Harald Welte wrote:
Hi Gus,
On Fri, Aug 26, 2011 at 04:03:52PM -0700, Gus Bourg wrote:
I introduced refcounting in the ->line_update() update path in
libosmo-abis, which calls the setup function only once (I needed this
to avoid binding the A-bis over IP socket twice).
Before, the line_update() function was called once per BTS. I'm
traveling back home, so I didn't have too much time to look in depth,
but my guess is that this can be related to the problem that Gus is
reporting.
Thanks for fixing this! I can confirm that it
compiles now - and my BTS
comes up with trunk. However, when I configure two BTS's, I get a core dump
(for real this time : -)
feel free to debug this further by yourself. It's a bit hard without
access to the equipment. For some reason, ts->lapd is NULL, i.e. there
was no LAPD instance allocated for this timeslot.
The allocation happens at line 434 of libosmo-abis/src/input/dahdi.c
So the first step would be to add some LOGP messages about which LAPD
instances are allocated (or released). This can be used to see if the
expected LAPD instances (one on each signalling timeslot) are created
or not.
29 Aug
29 Aug
9:15 a.m.
Hi Pablo,
On Sun, Aug 28, 2011 at 11:36:47PM +0200, Pablo Neira Ayuso wrote:
I see. But I believe this is the wrong path to "solve" the problem.
The function is called "update" since it is supposed to be called
multiple times, every time something has changed about the line (e.g.
timeslot configuration).
So the first
step would be to add some LOGP messages about which LAPD
instances are allocated (or released). This can be used to see if the
expected LAPD instances (one on each signalling timeslot) are created
or not.
I introduced refcounting in the ->line_update() update path in
libosmo-abis, which calls the setup function only once (I needed this
to avoid binding the A-bis over IP socket twice). Before, the line_update() function was called once per
BTS. I'm
traveling back home, so I didn't have too much time to look in depth,
but my guess is that this can be related to the problem that Gus is
reporting.
With multiple BTS attached to a signle line, there is no other way but
to call the function multiple times. It has to be written with that in
mind.
Regards,
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)
30 Aug
30 Aug
12:44 p.m.
Hi Harald!
On Mon, Aug 29, 2011 at 09:15:23AM +0200, Harald Welte wrote:
I missed the multiple-BTS-to-single-line setup, I'll send you a patch
to fix this situation.
Cheers,
Pablo
Hi Pablo,
On Sun, Aug 28, 2011 at 11:36:47PM +0200, Pablo Neira Ayuso wrote:
I see. But I believe this is the wrong path to "solve" the problem.
The function is called "update" since it is supposed to be called
multiple times, every time something has changed about the line (e.g.
timeslot configuration).
I can recover the ->start() callback that would be called once for
A-bis over IP drivers, so I don't need to use line_update() for this.
Or add some flag to the lines, so we can know which ones can be
updated several times or not.
So the
first step would be to add some LOGP messages about which LAPD
instances are allocated (or released). This can be used to see if the
expected LAPD instances (one on each signalling timeslot) are created
or not.
I introduced refcounting in the ->line_update() update path in
libosmo-abis, which calls the setup function only once (I needed this
to avoid binding the A-bis over IP socket twice). Before, the
line_update() function was called once per BTS. I'm
traveling back home, so I didn't have too much time to look in depth,
but my guess is that this can be related to the problem that Gus is
reporting.
With multiple BTS attached to a signle line, there is no other way but
to call the function multiple times. It has to be written with that in
mind.
1:38 p.m.
Hi Pablo,
On Tue, Aug 30, 2011 at 12:44:38PM +0200, Pablo Neira Ayuso wrote:
I can recover the ->start() callback that would be called once for
A-bis over IP drivers, so I don't need to use line_update() for this.
Or add some flag to the lines, so we can know which ones can be
updated several times or not.
I think having one 'update' callback is fine, no need for an extra
'start' callback.
The abis/ip line driver simlpy would have to use some privat per-line
data structure to keep the state if it has already been 'updated' once
and skip further update calls.
Regards,
Harald
no problem, looking forward to your patch.
--
- 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)
I introduced refcounting in the ->line_update()
update path in
libosmo-abis, which calls the setup function only once (I needed this
to avoid binding the A-bis over IP socket twice).
I see. But I believe this is the wrong path to "solve" the problem.
The function is called "update" since it is supposed to be called
multiple times, every time something has changed about the line (e.g.
timeslot configuration). With multiple
BTS attached to a signle line, there is no other way but
to call the function multiple times. It has to be written with that in
mind.
I missed the multiple-BTS-to-single-line setup, I'll send you a patch
to fix this situation.
5044
days inactive
5049
days old
9 comments
3 participants
participants (3)
-
Gus Bourg -
Harald Welte -
Pablo Neira Ayuso