Project

General

Profile

Actions

Bug #4916

open

USB unplug / replug renders e1d unusable

Added by laforge about 3 years ago. Updated 3 months ago.

Status:
Stalled
Priority:
High
Assignee:
Category:
icE1usb
Target version:
-
Start date:
12/18/2020
Due date:
% Done:

30%

Spec Reference:

Description

right now the behavior on USB unplug (or - god forbid - a firmware crash) is not very user friendly:
  • e1d keeps running
  • e1d does not re-open the device when it comes back
IMHO, we have the following options
  1. fail fast - simply exit when the device is lost, assume systemd or some other management instance will keep respawning us until the device is back
    • but what about client programs like osmo-bsc / osmo-mgw ?
  2. implement re-opening of a single icE1usb device, knowing our blocking control transfers would corrupt any other ongoing communication
    • is it worth the effort, assuming this is only an interim solution
  3. go for a full-blown hot-plug capable architecture lined out in #4915
    • will probably take significant effort

I think right now we mostly have to worry about situations with a single icE1usb, so I'm tempted to go for the fail-fast approach, assuming osmo-bsc/osmo-mgw recover in some way.


Related issues

Related to OsmoBSC - Feature #5983: Exit if osmo-e1d goes down or is restartedResolveddexter03/29/2023

Actions
Actions #1

Updated by laforge almost 2 years ago

  • Status changed from New to Stalled
  • % Done changed from 0 to 30

I did some work on this in the laforge/hotplug branch - which uncovered quite a bit of libosmousb bugs, e.g. https://gerrit.osmocom.org/c/libosmocore/+/27038

Actions #2

Updated by laforge almost 2 years ago

For the record: The main problem with the code in that branch is that we have the following flow of events:

  • we register call-backs for hotplug insert/remove
  • libusb calls the insert call-back function once a device is detected
  • once a device is found, we want to obtain the iSerial string to match against config

the existing code does that using a synchronous/blocking call. That's bad as it causes the process to hang/stall for all other devices osmo-e1d might already be serving. But even worse than that: libusb doesn't permit such calls from the "call-back context".

So we have to introduce some kind of stae machine which then sends a non-blocking/asynchronous read of iSerial from the hotplug notifiation context. Only once that read completes, we can proceed with enabling the interfaces of the device.

Actions #3

Updated by laforge almost 2 years ago

  • Category set to icE1usb
Actions #4

Updated by laforge over 1 year ago

  • Priority changed from Normal to High
Actions #5

Updated by laforge 11 months ago

  • Related to Feature #5983: Exit if osmo-e1d goes down or is restarted added
Actions #6

Updated by laforge 3 months ago

laforge wrote in #note-2:

For the record: The main problem with the code in that branch is that we have the following flow of events:

  • we register call-backs for hotplug insert/remove
  • libusb calls the insert call-back function once a device is detected
  • once a device is found, we want to obtain the iSerial string to match against config

the existing code does that using a synchronous/blocking call. That's bad as it causes the process to hang/stall for all other devices osmo-e1d might already be serving. But even worse than that: libusb doesn't permit such calls from the "call-back context".

So we have to introduce some kind of stae machine which then sends a non-blocking/asynchronous read of iSerial from the hotplug notifiation context. Only once that read completes, we can proceed with enabling the interfaces of the device.

An alternative would be to have a separate "hotplug thread" which we register with libusb to receive the hotplug call-back. It can then do as many blocking calls as it needs to do (there are actually more than just the iSerial string) and once it's done, pass the device over to the main thread to do its usual non-blocking processing.

Actions

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)