Thanks for the information. 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.
I will try to get a device in this failed state and diagnose why it is not being released. On Wed, Oct 28, 2020 at 3:24 AM Aleksander Morgado <aleksan...@aleksander.es> wrote: > Hey Jessy > > > 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). > > > > 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. > > > > 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). > > > > ModemManager already should detect stale AT ports, and after 10 > consecutive AT commands timing out, it flags the port as unusable and > trigger a device re-probe. > > https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/blob/master/src/mm-base-modem.c#L134 > > In your setup, when the problem with the stale AT port happens, are > you waiting for MM to send 10 AT commands and get 10 timeouts? > > > 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. > > ModemManager should flag the modem as unusable and attempts to > re-probe the ports right away, and if that doesn't work, the modem > won't be exported in DBus. I don't think MM should do any kind of > attempt to recover the modem; as that is very system specific and > would require quite some user configuration. If you're building your > own system, you should probably detect that the modem is suddenly no > longer exposed in DBus, and act accordingly (e.g. attempt forcing the > USB re-enumeration, or fully power off and on the device externally > via GPIO, or whatever other thing your system could do). > > -- > Aleksander > https://aleksander.es >
_______________________________________________ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
