Bug #4916
open
USB unplug / replug renders e1d unusable
Added by laforge over 3 years ago.
Updated 5 months ago.
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
- 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 ?
- 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
- 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.
- Status changed from New to Stalled
- % Done changed from 0 to 30
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.
- Priority changed from Normal to High
- Related to Feature #5983: Exit if osmo-e1d goes down or is restarted added
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.
Also available in: Atom
PDF
