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
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
On Thu, Aug 25, 2011 at 11:02 PM, Harald Welte laforge@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
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.
Hi Harald,
On Fri, Aug 26, 2011 at 10:16 AM, Harald Welte laforge@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
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.
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:
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.
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.
Hi Pablo,
On Sun, Aug 28, 2011 at 11:36:47PM +0200, Pablo Neira Ayuso wrote:
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).
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).
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
Hi Harald!
On Mon, Aug 29, 2011 at 09:15:23AM +0200, Harald Welte wrote:
Hi Pablo,
On Sun, Aug 28, 2011 at 11:36:47PM +0200, Pablo Neira Ayuso wrote:
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).
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.
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.
I missed the multiple-BTS-to-single-line setup, I'll send you a patch to fix this situation.
Cheers, Pablo
Hi Pablo,
On Tue, Aug 30, 2011 at 12:44:38PM +0200, Pablo Neira Ayuso 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).
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.
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
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.
no problem, looking forward to your patch.