Re: cdc-wdm: unable to connect after suspend

[Florian Klink <flokli@flokli.de>]

[-- Attachment #1: Type: text/plain, Size: 5929 bytes --]

Am 10.06.2014 14:09, schrieb BjÞrn Mork:
> Florian Klink <flokli@flokli.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...
.
> 
> 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







[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]