Hi Aleksander,
Do you still need me to retest with the latest
libmbim from git master for new log ?
I have no idea why the modem received the messages
out of sequence.
But this issue will not happen without using
mbim-proxy.
Do you need the log without using mbim-proxy ?
Thanks,
Edward
On Thu, Sep 17, 2020 at 4:58 PM Aleksander Morgado <aleksan...@aleksander.es>
wrote:
> Hey
>
> >
> > >> You may have hitted a bug in the proxy! I don't think anyone ever
> > >> tried to send MBIM requests that wouldn't fit in a single fragment.
> > >> Could you send us a full mbim-proxy verbose log while this command is
> > >> being run? You'll need to run the proxy manually with --verbose
> > >> *before* MM is started.
> >
> > Yes, I can see how only the first fragment has valid contents. The 2nd
> > fragment and following ones are invalid.
> >
> >
> > [17 九 2020, 08:22:52] -Error ** mbim_cid_get_printable: assertion
> > 'cid > 0' failed
> > [17 九 2020, 08:22:52] [Debug] [/dev/cdc-wdm_pcie] Sent message
> (translated)...
> > <<<<<< Header:
> > <<<<<< length = 4096
> > <<<<<< type = command (0x00000003)
> > <<<<<< transaction = 5
> > <<<<<< Fragment header:
> > <<<<<< total = 65
> > <<<<<< current = 1
> > <<<<<< Contents:
> > <<<<<< service = 'invalid' (00000000-0000-0000-0000-000000000000)
> > <<<<<< cid = '(null)' (0x00000000)
> > <<<<<< type = 'query' (0x00000000)
> >
>
> Wait, that issue above with the invalid contents in the 2nd fragment
> is not an issue; that problem with the invalid prints is in
> libmbim-glib because we shouldn't expect service/cid/type in any other
> fragment than the 1st one.
>
> > Would you be able to retest but using libmbim from git master, that
> > has improved debug logs?
>
> This retest with the newest debug logs wouldn't harm really.
>
> >
> > At this point, and looking at your specific setup (with MBIM over PCIe
> > I'm assuming?) I don't know at which point the message splitting into
> > fragments is being done (if at your app level or at proxy level)
> >
>
> I no longer think the data splitting is the problem.
>
> Looking down in the logs I can see how the proxy ends up sending all
> fragments one after the other very quickly, before even the modem has
> a chance to reply back. We send the first 15 out of 65 fragments one
> after the other, in sequence. But it looks like the modem receives
> them in the wrong order?
>
> The modem complains about transaction 5 giving a fragment out of sequence:
> [17 九 2020, 08:22:52] [Debug] [/dev/cdc-wdm_pcie] Received message
> (translated)...
> >>>>>> Header:
> >>>>>> length = 16
> >>>>>> type = function-error (0x80000004)
> >>>>>> transaction = 5
> >>>>>> Contents:
> >>>>>> error = 'FragmentOutOfSequence' (0x00000002)
>
> And AFTER that we receive transaction 4 also reporting out of sequence:
> [17 九 2020, 08:22:52] [Debug] [/dev/cdc-wdm_pcie] Received message
> (translated)...
> >>>>>> Header:
> >>>>>> length = 16
> >>>>>> type = function-error (0x80000004)
> >>>>>> transaction = 4
> >>>>>> Contents:
> >>>>>> error = 'FragmentOutOfSequence' (0x00000002)
>
> Why does the modem receive the messages out of sequence? Our logs show
> that they are being sent in the correct order.
>
> --
> Aleksander
> https://aleksander.es
>
_______________________________________________
ModemManager-devel mailing list
ModemManager-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
