When ModemManager is started on boot we may end up with hotplug events
reported directly to the daemon, plus some others already cached in
the cache file before the daemon was started.
If the cached events correspond to the same device that is still
notifying ports directly, we may end up with a modem object created
before the cached events have been emitted, so the modem may not
handle all control/data ports it should.
E.g.:
- modem detected
- hotplug event for wwan0 port, cached as MM not running
- hotplug event for cdc-wdm0 port, cached as MM not running
- hotplug event for ttyUSB0, cached as MM not running
- MM starts
- hotplug event for ttyUSB1, directly processed as MM is running
- hotplug event for ttyUSB2, directly processed as MM is running
- modem object created with ttyUSB1 and ttyUSB2
- 2s after MM starts, cached events for wwan0, cdc-wdm0 and ttyUSB0
happen, but are ignored because the modem object has already been
created
MM expects that ports of the same device are reported with less than
1500ms in between ports. In other words, if ports are reported more
than 1500ms after the last reported port, they may get ignored.
If we remove the 2s timeout, the report of the cached events will
happen as soon as MM starts, which makes it much more likely to happen
in the timeslot that MM expects for ports of the same device reported.
The logic is still not perfect, and we may also need to increase that
1500ms timeout inside MM, but removing the 2s timeout right away here
makes sense.
This 2s timeout was introduced along with the new wrapper launcher for
the daemon, it didn't exist before.
Signed-off-by: Aleksander Morgado <aleksander@aleksander.es>
/usr/sbin/ModemManager "$@" 1>/dev/null 2>/dev/null &
CHILD="$!"
- sleep 2
+
mm_report_events_from_cache
wait "$CHILD"
projects / feed / packages.git / commitdiff