Release plans (How are You ?)

[Aleksander Morgado]

Hey Stacy
>
> This is a direct followup of the issue 387 "How are you ? :3"
> Sorry to create the issue. I was not aware of this mailing list :D
>

No worries :)

> So to recapt the topic :
>
> We still have a very annoying issue in sxmo but probably in other pmOses
> in the last releases with SMS that are dropped and not fetched after
> crust. I'm pretty much sure the issue #356 find it source from this
> issue.
>

See https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/issues/356#note_919010

Some months ago we merged into git master a patch that would enable
messaging related AT URCs even in QMI modems:
https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/commit/8bc90b713159fe8a2415f272bbe9224ab3fd68e9

This was done because it was seen that QMI indications were not being
properly emitted after suspend/resume, or at least that was the
original thought. There was some discussion about the issue in the
corresponding merge request:
https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/merge_requests/433

Later on, after debugging with Carl and Dylan, it was found that this
was really not truly necessary. In the usbmon traces debugged we did
see the QMI indications, and MM was processing them without further
changes needed. Thanks to how messaging events are processed, having
new SMS messages reported both via QMI and AT was not an issue,
duplicated notification events were discarded properly.

That change was left in git master, though, and in my mind, my
suggestion is to remove it, as it was not truly needed.

Then your report from sxmo came, and so the question still is open,
are you really not receiving the QMI indications? are they being
emitted and not processed? are they not emitted at all? We need a full
usbmon trace to see what's happening and to see how to best solve
this, as we may be hiding a different problem if we just apply the URC
enabling workaround.

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?

> I got a builded version of mm in my device based on a master ref from
> some months ago and I dont have the issue anymore. I still dunno which
> patch is needed but I think that any release would eventually solve the
> issue for all of us.
>

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.

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.

> We'd like to know when you expect or hope to release again. It would
> help us to plan for futures releases too.
>

The next 1.18 stable release should happen sometime in July, likely
end of July, it depends on how much free time I can find for testing.
What I cannot promise is what will happen with the AT URC workaround
in that release, I still think we should remove it... but that's
really open to discussion.

If you can help debugging your system by providing a full usbmon trace
during the suspend/resume cycle, we can help analyzing that in order
to decide what to do.

Cheers!