a bug?

[Aleksander Morgado]

On Wed, Apr 29, 2015 at 11:19 PM, Dan Williams <dcbw at redhat.com> wrote:
>> On Ubuntu 14.04
>>
>> mmcli -L says 8after many sleeps)
>>
>> /org/freedesktop/ModemManager1/Modem/57 [Generic] MBIM [1199:A001]
>>
>> but
>>
>> tcsh>mmcli --pin=1213 --sim=57
>> error: couldn't find sim at '/org/freedesktop/ModemManager1/SIM/57'
>>
>> where actually
>>
>>
>> mmcli --pin=1213 --sim=53
>> successfully sent PIN code to the SIM
>>
>>
>> what is wrong here?
>

Well, it may be nothing wrong here. The index of the modem doesn't
have to be exactly equal to the sim index. You can list the modem
indexes available when doing mmcli -L; then for each of the modems you
can do e.g. mmcli -m 0 and you'll see listed among other things the
sim object index. These indexes are usualy equal, though, if there is
a single modem in the system always and if the modem always has a SIM.

A mismatch of the indexes may happen if you end up e.g. connecting at
the same time a modem with sim and a modem without sim. This happens a
lot to me as I don't really never use the modem built-in my laptop and
that always gets a modem index but never a sim index.

Does any of this make any sense to your use case? If you only used
always a modem and that modem always had a valid sim card, then we'd
need to see why they ended up getting mismatched, which is what Dan
was already discussing below.

> I think ModemManager is not compiled with suspend/resume support, and
> that the version of MM in 14.04 is probably too old to have that support
> in the code.
>
> What's going on is that when the machine goes to sleep, ModemManager has
> no idea about this, and because of that it holds the control port open
> over the suspend/resume.  But since the modem's other ports are not held
> open by MM, they can disappear when power is cut to the modem and it
> disconnects from the USB bus.
>

But even if MM holds the ports open and is not removed/recreated by
the kernel, we would get a HUP right away from the kernel in that
case, right? MM treats HUPs in the ports as port removes; if the
control port gets a HUP the modem gets flagged as invalid right away.

> Then when a resume happens, the modem comes back and the control port is
> brought back up again, but the other ports are re-created by the kernel
> and MM goes through the normal probing cycle, which creates a new modem
> object (57) in addition to the old one, but since this new one doesn't
> have control port it's useless.
>

I don't think the problem here is having 2 modems with different
indexes. There is just one modem (modem index #57) which has a sim
card (sim index #53).

> It looks like the suspend/resume support is only present on git master;
> I think we should probably backport it to MM 1.4 too.  Aleksander, does
> that sound reasonable?

I'd definitely prefer to go forward and start thinking in a new 1.6
stable series... maybe in the next few months?

-- 
Aleksander
https://aleksander.es