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:

quoted

Florian Klink [off-list ref] writes:

quoted

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

quoted

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.

quoted

quoted

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 ;-)

.

quoted

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.

quoted

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 :-)

quoted

Bjørn

Florian