Problems with modemmanager and Sierra EM7345 on resume

[Bjørn Mork]

Ernst Lehmann <lehmann at acheron.franken.de> writes:

> The problem is, after resume the network-manager can not connect to 4G.
> Device not found.
>
>
> nmcli dev list shows me an incrementing GENERAL.UDI for the 4G Modem.
>
> It startet with /org/freedesktop/ModemManger1/Modem/0
>
> and after two cycles of suspend/resume I am on
>
> /org/freedesktop/ModemManager1/Modem2

Yes, I have the exact same problem myself on suspend-to-ram.  I believe
it is due to bad interaction with the system firmware ("BIOS"), which
seems to unconditionally cut power to the m.2 (or mini-PCIe on older
Thinkpads) slot on suspend. This means that the modem is powered down no
matter what you do.  Booting up the modem firmware takes some time to
complete, and you end up with the modem being "discovered" as a
completely new USB device on resume from suspend-to-ram. So ModemManager
is gives it a new number etc.

The symptoms are slightly different when waking up from hibernate (at
least on my old and slow Thinkpad): The modem firmware finishes booting
before the USB subsystem resumes, which makes the USB device persistence
feature kick in and magically replace the "old modem" with the "newly
discovered" one.  The only problem is that the modem has been silently
reset because of the power loss, and therefore appears to userspace as
suffering from amnesia.  I believe ModemManager recently got a
workaround for this problem, so it should sort of work now.  But it
would of course have been much better if we had power control for the
slot and could decide to keep the IP session alive over hibernate (this
is possible with externally connected modems on my Thinkpad as the USB
ports can be kept powered while the system is powered off).

I don't know what to do about the suspend-to-ram problem though.  I
don't think there is any way we can eliminate the effects of the power
loss in the kernel/drivers.  The modem is enumerated as a new USB device
when it is finished booting and that's that. We could maybe delay the
USB persistence detection long enough to allow the modem to boot, but I
don't think we want to do that after the system is alive (dangerous).
And we certainly don't want to delay system resume for this.  So any
further delay is probably not feasible.

But maybe there is some magic we could do in ModemManager to
automatically correct the situation when a modem disappears after resume
and then reappears (with the same IMEI) a few seconds later?

At least NM should allow reconnecting using the "newly discovered"
modem instead of the "old modem".  Doesn't it?


Bjørn