Release plans (How are You ?)

[Dylan Van Assche]

Hi everyone,

> All this was also related to the "URC cache" that was being enabled
> by
> the eg25-manager in postmarketos, right Dylan? That URC cache was
> also
> not needed, and I believe that was already disabled in the
> eg25-manager. Can you all make sure you're configuring the module in
> the same way in sxmo and postmarketos?
> 

SXMO uses postmarketOS as base, we don't ship any URC cache stuff
anymore for a long time.

We really need an usbmon trace to see if it is any different.

> 
> That patch I referenced above is probably the one solving your
> problem. Still, as said, I think we should understand the problem
> fully before continuing with the AT URC workaround, especially since
> we're applying the workaround only for messaging events, and
> therefore
> it's not a complete solution.
> 

I haven't seen this on recent kernels with Phosh as UI. I did with
older kernels. SXMO uses the same kernels as the base is equally, just
the UI is different.

> And related to all this, I believe Dylan also recently found that if
> the module is kept awake while the host is suspended, it would queue
> all kinds of indications (QMI, AT) to send to the host, and if the
> queue gets too long, the module firmware would crash, something that
> we've also seen in other scenarios with other modules and protocols.
> The way to play "nicely" with that kind of issues could be to request
> to disable all indications (be it AT or QMI or MBIM) when the host is
> going to be suspended, but that would then introduce different issues
> on resume, and the issue we're talking about here would probably
> behave completely differently.
> 

AT URCs are totally fine, UART is not very smart in this regard as it
just dumps the data from the modem to the host over UART. However, QMI
and MBIM require some more work from both sides. This 'ping pong' thing
for QMI/MBIM cannot be fully completed when the host suspends suddenly
in the middle of processing a QMI/MBIM event.
I haven't noticed the problem yet of crashing, but other users did by
using a lot of mobile data just at the same time when the device
suspend.

Disabling QMI/MBIM indications before suspending and enabling when
resuming could be a solution, but the calls/texts indications may not
break by doing this. In that case, we need to synchronize the
calls/texts storages as well, that's not the case right now.

I was wondering if the problem is not the queue but rather a half-
processed QMI indication? The indication is seen, but not fully
processed by libqmi, would a sleep inhibitor delay work like MM does
already for this? This would ensure that libqmi can fully process a QMI
indication before the userspace is frozen.
AFAIK, MM is responsible for acting on events, but libqmi is
responsible for talking 'QMI' and transforming the indications in a
readable format, ready for MM to consume.

Kind regards,
Dylan Van Assche