Date:	Tue, 10 Jun 2014 16:14:18 +0200
From:	Florian Klink <flokli@...kli.de>
To:	Bjørn Mork <bjorn@...k.no>
CC:	netdev@...r.kernel.org, modemmanager-devel@...ts.freedesktop.org
Subject: Re: cdc-wdm: unable to connect after suspend

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
> ModemManager[3067]: [/dev/cdc-wdm1] No transaction matched in received
> message
> ModemManager[3067]: [/dev/cdc-wdm1] No transaction matched in received
> message
> ModemManager[3067]: [/dev/cdc-wdm1] No transaction matched in received
> message
> ModemManager[3067]: [/dev/cdc-wdm1] No transaction matched in received
> message
> ModemManager[3067]: [/dev/cdc-wdm1] No transaction matched in received
> message
> ModemManager[3067]: [/dev/cdc-wdm1] No transaction matched in received
> message
> ModemManager[3067]: [/dev/cdc-wdm1] No transaction matched in received
> message
> ModemManager[3067]: [/dev/cdc-wdm1] No transaction matched in received
> message
> ModemManager[3067]: [/dev/cdc-wdm1] No transaction matched in received
> message
> ModemManager[3067]: <info>  Creating modem with plugin 'Generic' and '2'
> ports
> ModemManager[3067]: <warn>  Could not grab port (usbmisc/cdc-wdm1):
> 'Cannot add port 'usbmisc/cdc-wdm1', unsupported'
> ModemManager[3067]: <warn>  Couldn't create modem for device at
> '/sys/devices/pci0000:00/0000:00:14.0/usb1/1-6': Failed to find primary
> AT port
> ModemManager[3067]: <info>  Creating modem with plugin 'Generic' and '1'
> ports
> ModemManager[3067]: <warn>  Could not grab port (tty/ttyS0): 'Cannot add
> port 'tty/ttyS0', unhandled serial type'
> ModemManager[3067]: <warn>  Couldn't create modem for device at
> '/sys/devices/pci0000:00/0000:00:16.3': Failed to find primary AT port
> 
>>
>> 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.
> 
>>
>>
>>> I see the following error messages:
>>>
>>>
>>> Couldn't reload current power state: Transaction timed out
>>> [/dev/cdc-wdm1] No transaction matched in received message
>>> <warn> (cdc-wdm1) failed to connect modem: Transaction timed out
>>> <info> (cdc-wdm1): device state change: prepare -> failed (reason
>>> 'unknown') [40 120 1]
>>> modem_prepare_result: assertion 'state == NM_DEVICE_STATE_PREPARE' failed
>>>
>>>
>>> It looks like a driver bug for me, like the device not woken up
>>> correctly. I attached the syslog.
>>
>> It is certainly bad interaction between userspace and the driver.  We'll
>> have to fight about where the bug is :-)
>>
>> I believe the problem is that the modem is powered down when the
>> notebook is suspended, combined with the "USB device persistence"
>> feature and bad handling of "unexpected" states in ModemManager.
>> The result is that MM and the device/driver ends up with different views
>> of the current modem state. But I might be completely wrong here.
>> Seeing kernel logs would have helped.
> 
> 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 ;-)
> .
>>
>> Initially I'd like to claim that this is a userspace problem.  But I'm
>> open to reconsider that view, given convincing arguments. It's not my
>> intention to reject this as "someone elses problem".
>>
>> A short explanation of what's going on: The "USB device persistence"
>> feature just cannot work with 3G/LTE modem devices because they lose
>> necessary internal state on any power loss.  The persist feature makes
>> the modem reappear as exact the same device after resume, but with a
>> case of severe amnesia.  So why don't we just disable the feature when
>> it cannot work? The reason is that modems often are composite devices,
>> and many of them include card reader functions. USB device persistences
>> is critical for such devices. Consider suspending a card reader with a
>> mounted file system...
>>
>> For this reason I really do not want to disable the persist feature,
>> even if it is pointless from a standalone modem point of view.  Instead
>> userspace should be able to cope with modems "suddendly" entering
>> unexpected states.
>>
>>> I'm running Arch Linux amd64 with an 3.15.0-rc8 kernel, and
>>> NetworkManager 0.9.8.10.
>>>
>>> Is there anybody else who observed this behaviour?
>>
>> Yes, I must admit I've seen similar behaviour.  The interaction between
>> system suspend and drivers/MM/NM is not good.
>>
>> Could you please bring this up on the ModemManager list?
> 
> I added modemmanager-devel to CC as suggested :-)
>>
>>
>> Bjørn
>>
> Florian
> 
> 
> 
> 
> 
> 


View attachment "cdc-wdm_dmesg.txt" of type "text/plain" (11119 bytes)

Download attachment "signature.asc" of type "application/pgp-signature" (820 bytes)

Powered by blists - more mailing lists