Will modem inhibition truly release MBIM port ?

[Aleksander Morgado]

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