Cellular Network Infrastructure » Radio Access Network » OsmoBSC

Hi Keith,

as usual, the more context provided in a bug report, the more likely it is fixed.

As you describe it, this is actually at least two if not more bugs. Please file them separately.

1. icE1usb hardware becomes unresponsive (separate issue, likely root cause/trigger)
2. osmo-e1d starts but has no interface
   • does this imply the unresponsive hardware makes osmo-e1d crash or stop and it is restarted e.g. by systemd?
   • If the hardware is gone from USB (see your lsusb), it's obvious that it has no interface :)
3. osmo-bsc crashes. That is the actual issue here in the osmo-bsc project

The segfault appears in line 370, which is the LOGPITS statement below:

                if (e1i_ts->type != E1INP_TS_TYPE_NONE && ts >= num_ts_info) {
                        LOGPITS(e1i_ts, DLINP, LOGL_ERROR, "Timeslot configured, but not existent " 
                                "on E1D side; skipping\n");

So the code correctly detects that osmo-bsc has configuration for a timeslto that does not exist on the e1d side. But somehow it crashes during logging :/

That macro is defined as:

#define LOGPITS(e1ts, ss, level, fmt, args ...) \
       LOGP(ss, level, "E1TS(%u:%u) " fmt, (e1ts)->line->num, (e1ts)->num, ## args)

So we are de-referencing e1ts->line and e1ts->num. As e1i_ts exists (we just checked for e1i_ts->type successfully, and it is a static member of 'line'), the e1i_ts->line might be NULL or an invalid pointer, resulting in the line->num deref to go wrong.

The 'line' member is set at e1inp_ts_config_{trau,i460,sign,raw,hdlc}() so it shouldn't be NULL.

I guess we should simply introduce a NULL chekc in the logging macro...

Actually, the 'line' back-pointer of every timeslot is also set in e1inp_line_create(), so I'm having a hard time understanding how it should be NULL or pointing to invalid memory.

In any case, we can try to make osmo-bsc not crash in this case, but it still wouldn't help you with your actual problem: the icE1usb gone from USB.

You could make sure to use a USB hub (on mainboard or external) that provides 'per-port power switching'. In those cases, you can use tools like 'uhubctl' to actually physically power-cycle the USB port, which would be a power-cycle of the icE1usb. Most cheap hubs either don't have power switching at all, or they have 'ganged' power switching, where you must disable all downstream ports (and not just one) to actually make the power go off.

Of course it shouldn't just disappear from the bus like it does, but debugging this can be hard. Meanwhile, a quick work-around is this kind of problem is the usb power cycling.

• Did 'dmesg' show anything ?
• If you have a debug uart, connect it to the ice1usb debug port and log that.

Oh and if you have a uart console (1Mbaud), you can also use some of the commands :

'd' Forces a USB disconnect
'c' To reconnect after the disconnect.
'b' will force boot to bootloader (and you can then use 'b' again in the bootloader to boot application image or use `dfu-util -e` for that).

laforge wrote:

Hi Keith,

as usual, the more context provided in a bug report, the more likely it is fixed.

As you describe it, this is actually at least two if not more bugs. Please file them separately.

Hey Harald.. While working under some considerable pressure in the field, it's not always possible to file the optimal bug report, but rather I considered to quickly note something that was observed, so as not to let it pass by.

I should have assigned the ticket to myself to make that more clear.

laforge wrote:

Of course it shouldn't just disappear from the bus like it does, but debugging this can be hard. Meanwhile, a quick work-around is this kind of problem is the usb power cycling.

Yep. Thanks for the attention to it. I'm quite aware that TIC needs to implement some method to be able to remote power reset the e1 usb in order to fix a situation like this, without having somebody physically go to the tower.

It actually hasn't happened much and I cannot reproduce it on demand. Anyway, I really didn't want to give the impression that this is urgent by making an issue, I just thought that at the very least, we shouldn't crash, hence I filed the ticket. There are a considerable amount or more urgent issues I am facing in relation to the RBS.

Thanks.