Random MM and/or qmi-proxy hang?

Aleksander Morgado aleksander at aleksander.es
Wed Mar 27 10:40:10 UTC 2019


> > >
> > > This is RHEL7 so I’m using the 1.6 branch of MM and 1.18.0 libqmi; for MM I
> > tried building our own 1.16.4 when we suspected MM being the core issue,
> > with no change in behavior.
> > >
> >
> > Hard to say what the issue is, but you're really using somewhat old versions.
> > Any chance you can upgrade them to MM 1.10.0 and libqmi 1.22.2? They
> > should be totally compatible.
>
> Upgraded to MM 1.10, libqmi 1.22.2. Definitely helped; not getting the qmi-proxy lock-ups anymore. But I think it ended up exposing what our actual problem is: we're now seeing ClientIdsExhausted errors. The timing would suggest this is happening where we were locking up before.
>
> At this point I should mention we have a custom app also speaking direct libqmi to both modems to extract detailed per-chain RF data every minute or so (qmi_message_nas_get_tx_rx_info_output_get_rx_chain_0_info and the same on chain_1). It follows a process of connect to qmi-proxy with QMI_CID_NONE set (to allocate a new CID), register to DMS and NAS services, gather data, then unregister/deallocate. After doing this enough times we're apparently running out of CIDs even though we’re deallocating each time. Tried the qmicli 'sync' function to flush out the modem and that very much confused MM, the modem disconnects and gets stuck in an 'unavailable' state. Mmcli modem rescan doesn't help at that point, have to power cycle the modem, which now that we've lost QMI access can only be done via AT console or whole machine power-cycle.
>

The "sync" will definitely confuse MM, as it would silently release
all the clients that were allocated by MM :D

> Any way to get these per-chain signal values via MM so we don't have to talk to the modems directly?

If the data is generic enough, this could be integrated in
ModemManager's own interfaces, and so the polling could be done by MM
directly and exposed in DBus.

> If not, any idea what we might be doing wrong with our QMI interactions? We're already looking into keeping one QMI client per modem up front and reusing it until the modem disappears, but that will take a major refactor of the code so hoping we don't have to go that far.

If you're triggering ClientIdsExhausted, then it looks like there may
be some part of your code that isn't releasing the clients properly...
If you're using libqmi, I would definitely suggest you use a single
QMI Client and reuse it over and over...


-- 
Aleksander
https://aleksander.es


More information about the ModemManager-devel mailing list