https://osmocom.org/https://osmocom.org/favicon.ico?16647414092021-07-02T08:15:44ZOpen Source Mobile CommunicationsOsmoBSC - Bug #5190: segfault with osmo-e1dhttps://osmocom.org/issues/5190?journal_id=223112021-07-02T08:15:44Zlaforge
<ul><li><strong>Status</strong> changed from <i>New</i> to <i>In Progress</i></li><li><strong>Assignee</strong> set to <i>laforge</i></li></ul><p>Hi Keith,</p>
<p>as usual, the more context provided in a bug report, the more likely it is fixed.</p>
<p>As you describe it, this is actually at least two if not more bugs. Please file them separately.</p>
<ol>
<li>icE1usb hardware becomes unresponsive (separate issue, likely root cause/trigger)</li>
<li>osmo-e1d starts but has no interface
<ul>
<li>does this imply the unresponsive hardware makes osmo-e1d crash or stop and it is restarted e.g. by systemd? </li>
<li>If the hardware is gone from USB (see your lsusb), it's obvious that it has no interface :)</li>
</ul>
</li>
<li>osmo-bsc crashes. That is the actual issue here in the osmo-bsc project</li>
</ol> OsmoBSC - Bug #5190: segfault with osmo-e1dhttps://osmocom.org/issues/5190?journal_id=223122021-07-02T08:16:53Zlaforge
<ul><li><strong>Description</strong> updated (<a title="View differences" href="/journals/22312/diff?detail_id=37390">diff</a>)</li></ul> OsmoBSC - Bug #5190: segfault with osmo-e1dhttps://osmocom.org/issues/5190?journal_id=223132021-07-02T08:24:13Zlaforge
<ul></ul><p>The segfault appears in line 370, which is the LOGPITS statement below:<br /><pre>
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");
</pre></p>
<p>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 :/</p>
<p>That macro is defined as:<br /><pre>
#define LOGPITS(e1ts, ss, level, fmt, args ...) \
LOGP(ss, level, "E1TS(%u:%u) " fmt, (e1ts)->line->num, (e1ts)->num, ## args)
</pre></p>
<p>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.</p>
<p>The 'line' member is set at <code>e1inp_ts_config_{trau,i460,sign,raw,hdlc}()</code> so it shouldn't be NULL.</p>
<p>I guess we should simply introduce a NULL chekc in the logging macro...</p> OsmoBSC - Bug #5190: segfault with osmo-e1dhttps://osmocom.org/issues/5190?journal_id=223152021-07-02T08:26:55Zlaforge
<ul></ul><p>Actually, the 'line' back-pointer of every timeslot is also set in <code>e1inp_line_create()</code>, so I'm having a hard time understanding how it should be NULL or pointing to invalid memory.</p> OsmoBSC - Bug #5190: segfault with osmo-e1dhttps://osmocom.org/issues/5190?journal_id=223162021-07-02T08:33:04Zlaforge
<ul></ul><p>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.</p>
<p>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 <em>all</em> downstream ports (and not just one) to actually make the power go off.</p>
<p>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.</p> OsmoBSC - Bug #5190: segfault with osmo-e1dhttps://osmocom.org/issues/5190?journal_id=223172021-07-02T08:40:39Ztnt
<ul></ul><ul>
<li>Did 'dmesg' show anything ?</li>
<li>If you have a debug uart, connect it to the ice1usb debug port and log that.</li>
</ul> OsmoBSC - Bug #5190: segfault with osmo-e1dhttps://osmocom.org/issues/5190?journal_id=223182021-07-02T09:00:54Ztnt
<ul></ul><p>Oh and if you have a uart console (1Mbaud), you can also use some of the commands :</p>
<p>'d' Forces a USB disconnect<br />'c' To reconnect after the disconnect.<br />'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).</p> OsmoBSC - Bug #5190: segfault with osmo-e1dhttps://osmocom.org/issues/5190?journal_id=223392021-07-02T17:50:35Zkeith
<ul></ul><p>laforge wrote:</p>
<blockquote>
<p>Hi Keith,</p>
<p>as usual, the more context provided in a bug report, the more likely it is fixed.</p>
<p>As you describe it, this is actually at least two if not more bugs. Please file them separately.</p>
</blockquote>
<p>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.</p>
<p>I should have assigned the ticket to myself to make that more clear.</p> OsmoBSC - Bug #5190: segfault with osmo-e1dhttps://osmocom.org/issues/5190?journal_id=223402021-07-02T17:56:14Zkeith
<ul></ul><p>laforge wrote:</p>
<blockquote>
<p>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.</p>
</blockquote>
<p>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.</p>
<p>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.</p>
<p>Thanks.</p> OsmoBSC - Bug #5190: segfault with osmo-e1dhttps://osmocom.org/issues/5190?journal_id=225422021-09-15T09:34:39Zlaforge
<ul><li><strong>Status</strong> changed from <i>In Progress</i> to <i>New</i></li><li><strong>Assignee</strong> deleted (<del><i>laforge</i></del>)</li><li><strong>Priority</strong> changed from <i>Normal</i> to <i>Low</i></li></ul>