Message-ID: <87lht350y0.fsf@nemi.mork.no>
Date:	Wed, 11 Jun 2014 10:01:59 +0200
From:	Bjørn Mork <bjorn@...k.no>
To:	Florian Klink <flokli@...kli.de>
Cc:	netdev@...r.kernel.org, modemmanager-devel@...ts.freedesktop.org
Subject: Re: cdc-wdm: unable to connect after suspend

Florian Klink <flokli@...kli.de> writes:
> Am 10.06.2014 16:08, schrieb Florian Klink:
>> Am 10.06.2014 14:09, schrieb BjÞrn Mork:
>>> Florian Klink <flokli@...kli.de> writes:
>>>
>>>> Hi,
>>>>
>>>> I recently bought a notebook (Fujitsu Lifebook T904) with integrated
>>>> 3G/4G modem (Sierra Wireless EM7305) thats powered by the cdc-wdm driver.
>>>>
>>>> It works without any problems on a fresh bootup using Networkmanager.
>>>>
>>>> However, after putting the notebook into standby and waking up again,
>>>> I'm unable to get a connection (always reproducible, not signal quality
>>>> related).
>>>
>>> Does it work again if you restart NetworkManager and ModemManager at
>>> this point?
>> 
>> Nope. ModemManager gets confused completely and drops the modem out of
>> the list of connections:
>> 
>> ModemManager[3067]: <warn>  Couldn't find support for device at
>> '/sys/devices/pci0000:00/0000:00:19.0': not supported by any plugin
>> ModemManager[3067]: <warn>  Couldn't find support for device at
>> '/sys/devices/pci0000:00/0000:00:1c.3/0000:03:00.0': not supported by
>> any plugin
>> ModemManager[3067]: [/dev/cdc-wdm1] Queried max control message size: 4096
>> ModemManager[3067]: [/dev/cdc-wdm1] No transaction matched in received
>> message

Ah, OK.  Then I obviously guessed wrong.  MM and the firmware does not
agree on the current transaction sequence. I'm not sure why. The modem
is sending unexpected messages, and I assume MM doesn't get the answers
it is looking for.  This could be caused by the driver cancelling the
interrupt URB at an "inconvenient time" for the firmware.  But I haven't
seen issues like that with the Qualcomm based Sierra modems before.

And you get into this state consistently on every suspend+resume? 

It would be useful to know which unexpeced messages we receive (errors?
same message all over? older queued up messages being played back with
unexpected delay?)  Any chance you can enable libmbim + ModemManager
debugging to get the MBIM message dumps?


>>> Does it help to do
>>>
>>>  echo  0 >/sys/bus/usb/devices/x-y/power/persist
>>>
>>> prior to suspending the notebook?  You'll have to replace "x-y" with the
>>> correct USB bus and port number.  You can find this in e.g. the dmesg
>>> output.  For example, if your log shows:
>>>
>>>   qmi_wwan 2-4:1.8: cdc-wdm0: USB WDM device
>>>
>>> then x-y = 2-4.
>> 
>> dmesg shows "cdc_mbim 1-6:2.12: cdc-wdm1: USB WDM device", so I did echo
>> 0 > /sys/bus/usb/devices/1-6/power/persist.
>> 
>> However, after a suspend/resume cycle, connecting didnt work either.
>> Errors were the same as without persist = 0.

Yes, my initial guess was wrong, so this is not the problem.

>> dmesg doesn't really show an error message from the modem. Seems like it
>> also has an issue resuming "Bus 001 Device 006: ID 0483:91d1
>> STMicroelectronics", but this shouldn't cause the problems with the modem...
>
> I attached the dmesg output, probably there's till something interesting
> inside ;-)

Thanks.  I wasn't expecting any errors there (I still don't think there
is any real error here from the drivers point of view), but I wanted to
see whether the modem is disconnected and rediscovered or just plainly
suspended.

But???  I cannot find anything related to the modem device in that log?
Not even anything mentioning the "1-6" USB port.



Bjørn
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists