<div dir="ltr">Thanks for the information.<div><br><div>It is good to know that this has been considered in the core design. I agree that there should be no modem specific behavior for this.</div><div><br></div><div>I will try to get a device in this failed state and diagnose why it is not being released.</div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Oct 28, 2020 at 3:24 AM Aleksander Morgado <<a href="mailto:aleksander@aleksander.es">aleksander@aleksander.es</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hey Jessy<br>
<br>
> I am working with some Cinterion modems (PLAS9) and have seen them lock up completely (requiring a hard reset as the AT channel does not even accept commands anymore).<br>
><br>
> The reason I am posting about this here is that ModemManager doesn't realize the modem is gone. Every message sent to the modem will fail to send or timeout, but ModemManager will continue showing the last state of the modem before it stopped responding.<br>
><br>
> I am happy to do the work to make ModemManager respond more sanely to this situation, but I want to make sure that whatever I do follows agreed upon best practices, and that I don't introduce too strange behavior for a single family of modems. If the agreed upon fix can be done to some of the modem base classes, that would be even better (consistency).<br>
><br>
<br>
ModemManager already should detect stale AT ports, and after 10<br>
consecutive AT commands timing out, it flags the port as unusable and<br>
trigger a device re-probe.<br>
<a href="https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/blob/master/src/mm-base-modem.c#L134" rel="noreferrer" target="_blank">https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/blob/master/src/mm-base-modem.c#L134</a><br>
<br>
In your setup, when the problem with the stale AT port happens, are<br>
you waiting for MM to send 10 AT commands and get 10 timeouts?<br>
<br>
> My initial thought is detecting if the AT Channel is unreachable for a time, to drop and re-enumerate the device. If there is a failure to reenumerate, that at least shows that the modem is not just sitting there in a connected state, or whatever it was before the crash.<br>
<br>
ModemManager should flag the modem as unusable and attempts to<br>
re-probe the ports right away, and if that doesn't work, the modem<br>
won't be exported in DBus. I don't think MM should do any kind of<br>
attempt to recover the modem; as that is very system specific and<br>
would require quite some user configuration. If you're building your<br>
own system, you should probably detect that the modem is suddenly no<br>
longer exposed in DBus, and act accordingly (e.g. attempt forcing the<br>
USB re-enumeration, or fully power off and on the device externally<br>
via GPIO, or whatever other thing your system could do).<br>
<br>
-- <br>
Aleksander<br>
<a href="https://aleksander.es" rel="noreferrer" target="_blank">https://aleksander.es</a><br>
</blockquote></div>