> > >
> > > 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
_______________________________________________
ModemManager-devel mailing list
ModemManager-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel

Reply via email to