From: Florian Klink <flokli@flokli•de>
To: "Bjørn Mork" <bjorn@mork•no>
Cc: netdev@vger•kernel.org, modemmanager-devel@lists•freedesktop.org
Subject: Re: cdc-wdm: unable to connect after suspend
Date: Tue, 10 Jun 2014 16:08:49 +0200 [thread overview]
Message-ID: <53971171.5070001@flokli.de> (raw)
In-Reply-To: <874mzt55kz.fsf@nemi.mork.no>
[-- 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 --]
next prev parent reply other threads:[~2014-06-10 14:16 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-06-10 10:20 cdc-wdm: unable to connect after suspend Florian Klink
2014-06-10 12:09 ` Bjørn Mork
2014-06-10 14:08 ` Florian Klink [this message]
2014-06-10 14:14 ` Florian Klink
2014-06-11 8:01 ` Bjørn Mork
2014-06-11 10:08 ` Florian Klink
2014-06-11 10:17 ` Aleksander Morgado
2014-06-11 11:23 ` Florian Klink
2014-06-11 11:53 ` Bjørn Mork
2014-06-11 15:05 ` Aleksander Morgado
2014-06-12 20:10 ` Florian Klink
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=53971171.5070001@flokli.de \
--to=flokli@flokli$(echo .)de \
--cc=bjorn@mork$(echo .)no \
--cc=modemmanager-devel@lists$(echo .)freedesktop.org \
--cc=netdev@vger$(echo .)kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox