Sierra Wireless EM7305 (Fujitsu Lifebook S904) does not work after suspend/hibernate

[Alex Yurchenko]

Ubuntu 14.04, x86_64, ModemManager-1.0.0-2ubuntu1

Card: Sierra Wireless EM7305 (PCI Express M.2 form factor)

Expected: Sierra plugin is used
Happens: Generic plugin is used instead

After cold start the card seems to work almost fine, but does not come back after suspend or hibernate. At least after hibernate MM may go into a tight loop consuming 100% CPU.

MM debug log output (full log attached):

<debug> [1401992536.121631] [mm-plugin-manager.c:576] build_plugins_list(): (Plugin Manager) [wwan0] Found '1' plugins to try...
<debug> [1401992536.125236] [mm-plugin-manager.c:580] build_plugins_list(): (Plugin Manager) [wwan0] Will try with plugin 'Generic'
<debug> [1401992536.128923] [mm-plugin.c:700] mm_plugin_supports_port(): (Generic) [wwan0] probing deferred until result suggested
<debug> [1401992536.132687] [mm-plugin-manager.c:505] plugin_supports_port_ready(): (Plugin Manager) [wwan0] deferring support check until result suggested
<debug> [1401992536.142664] [mm-port-probe.c:536] wdm_probe_mbim(): (usbmisc/cdc-wdm0) probing MBIM...
<debug> [1401992538.202591] [mm-plugin-manager.c:646] min_probing_timeout_cb(): (Plugin Manager) [/sys/devices/pci0000:00/0000:00:14.0/usb1/1-6] Minimum probing time consumed
[/dev/cdc-wdm0] Queried max control message size: 4096[/dev/cdc-wdm0] Sent message...
<<<<<< RAW:
<<<<<< length = 16
<<<<<< data = 01:00:00:00:10:00:00:00:01:00:00:00:00:10:00:00
[/dev/cdc-wdm0] Sent message (translated)...
<<<<<< Header:
<<<<<< length = 16
<<<<<< type = open (0x00000001)
<<<<<< transaction = 1
<<<<<< Contents:
<<<<<< max_control_transfer = 4096
[/dev/cdc-wdm0] Received message...
>>>>>> RAW:
>>>>>> length = 16
>>>>>> data = 01:00:00:80:10:00:00:00:01:00:00:00:00:00:00:00
<debug> [1401992539.481429] [mm-port-probe.c:300] mm_port_probe_set_result_mbim(): (usbmisc/cdc-wdm0) port is MBIM-capable
[/dev/cdc-wdm0] Sent message...
<<<<<< RAW:
<<<<<< length = 12
<<<<<< data = 02:00:00:00:0C:00:00:00:02:00:00:00
[/dev/cdc-wdm0] Sent message (translated)...
<<<<<< Header:
<<<<<< length = 12
<<<<<< type = close (0x00000002)
<<<<<< transaction = 2
[/dev/cdc-wdm0] Received message...
>>>>>> RAW:
>>>>>> length = 16
>>>>>> data = 02:00:00:80:10:00:00:00:02:00:00:00:00:00:00:00
<debug> [1401992539.545529] [mm-plugin-manager.c:417] plugin_supports_port_ready(): (Plugin Manager) (Generic) [cdc-wdm0] found best plugin for port
<debug> [1401992539.549361] [mm-plugin-manager.c:334] suggest_port_probe_result(): (Plugin Manager) (Generic) [wwan0] deferred task completed, got suggested plugin
<debug> [1401992539.553247] [mm-plugin-manager.c:274] port_probe_context_finished(): (Plugin Manager) 'cdc-wdm0' port probe finished, still 1 running probes in this device (wwan0)
<debug> [1401992539.556995] [mm-plugin.c:700] mm_plugin_supports_port(): (Generic) [wwan0] probing deferred until result suggested
<debug> [1401992539.560690] [mm-plugin-manager.c:485] plugin_supports_port_ready(): (Plugin Manager) (Generic) [wwan0] task completed, got suggested plugin
<debug> [1401992539.564175] [mm-plugin-manager.c:285] port_probe_context_finished(): (Plugin Manager) 'wwan0' port probe finished, last one in device
<debug> [1401992539.567868] [mm-plugin-manager.c:107] find_device_support_context_complete_and_free(): (Plugin Manager) [/sys/devices/pci0000:00/0000:00:14.0/usb1/1-6] device support check finished in '3.677528' seconds
<info> [1401992539.571611] [mm-device.c:486] mm_device_create_modem(): Creating modem with plugin 'Generic' and '2' ports
<debug> [1401992539.575477] [generic/mm-plugin-generic.c:73] create_modem(): MBIM-powered generic modem found...

mmcli output:

/org/freedesktop/ModemManager1/Modem/0 (device id 'b3a77501ed8da196baa804a4142ff280766f6f98')
  -------------------------
  Hardware | manufacturer: 'Generic'
           | model: 'MBIM [1199:9063]'
           | revision: 'SWI9X15C_01.12'
           | supported: 'gsm-umts, lte'
           | current: 'gsm-umts, lte'
           | equipment id: '356906050069168'
  -------------------------
  System | device: '/sys/devices/pci0000:00/0000:00:14.0/usb1/1-6'
           | drivers: 'cdc_mbim'
           | plugin: 'Generic'
           | primary port: 'cdc-wdm0'
           | ports: 'cdc-wdm0 (mbim), wwan0 (net)'
  -------------------------
  Numbers | own : 'unknown'
  -------------------------
  Status | lock: 'none'
           | unlock retries: 'sim-pin2 (3)'
           | state: 'disabled'
           | power state: 'on'
           | access tech: 'unknown'
           | signal quality: '0' (cached)
  -------------------------
  Modes | supported: 'allowed: 2g, 3g, 4g; preferred: none'
           | current: 'allowed: 2g, 3g, 4g; preferred: none'
  -------------------------
  Bands | supported: 'unknown'
           | current: 'unknown'
  -------------------------
  IP | supported: 'ipv4, ipv6, ipv4v6'
  -------------------------
  3GPP | imei: '356906050069168'
           | enabled locks: 'sim, fixed-dialing'
           | operator id: 'unknown'
           | operator name: 'unknown'
           | registration: 'unknown'
  -------------------------
  SIM | path: '/org/freedesktop/ModemManager1/SIM/0'

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Marius B. Kotsbak (mariusko)]

The logs indicate that the modem is perfectly indentified as a MBIM based modem using MBIM plugin, which works better than using the Sierra plugin, so that is expected. But when is the hang happening and how does the logs looks like at that time?

[Marius B. Kotsbak (mariusko)]

I'm sorry, it seems like it is in fact using the generic plugin instead of MBIM, probably after failing to use the latter. I think this issue is covered in the upstream bug report: https://bugzilla.gnome.org/show_bug.cgi?id=726613

Private bug #1307932 might be a duplicate.

[Данило Шеган (danilo)]

FWIW, additional details are given in a threads
   http://permalink.gmane.org/gmane.linux.network/319839
   http://lists.freedesktop.org/archives/modemmanager-devel/2014-June/001213.html
 (I am experiencing exactly the same problems).

[Pier Paolo (pierpaolo-franco)]

Mobile broadband not working after resume on Toshiba Tecra Z40, too.

$ lsusb
Bus 002 Device 002: ID 1199:9063 Sierra Wireless, Inc.

How can i help troubleshooting the problem?

[Pier Paolo (pierpaolo-franco)]

systemd workaround:

systemctl stop/start ModemManager.service

in pm-utils /etc/pm/sleep.d/

works only if mobile broadband is connected before suspend.

Seems a kernel/firmware/something issue to me.

[Aleksander Morgado (aleksander-m)]

Originally reported at:
  https://bugzilla.gnome.org/show_bug.cgi?id=726613
Please refer to the original bug report if more details are needed.

After resuming from a suspend, the MBIM-managed Sierra Wireless EM7305 doesn't seem to properly allow connections if ModemManager had an open MBIM session during the suspension. After resuming, a connection attempt will make the device connected, but not working properly.

   [1404835174.470611] (wwp0s20u6c2i12): port now connected
   [1404835174.470684] Connected bearer '/org/freedesktop/ModemManager1/Bearer/0'
   [1404835174.471132] Modem /org/freedesktop/ModemManager1/Modem/0: state changed (connecting -> connected)
   [1404835174.471737] Simple connect state (8/8): All done
(now something happens, and it seems we get a Disconnection via DBus?)
   [1404835181.411298] Disconnecting bearer '/org/freedesktop/ModemManager1/Bearer/0'
   [1404835181.412289] Modem /org/freedesktop/ModemManager1/Modem/0: state changed (connected -> disconnecting)
   [1404835181.412634] Launching disconnection on data port (net/wwp0s20u6c2i12)

Would be good to get a set of ModemManager *and* NetworkManager debug logs of the same run.

[Aleksander Morgado (aleksander-m)]

Created attachment 107821
Successful connection attempt after a full reboot

Log from the original reporter.

[Aleksander Morgado (aleksander-m)]

Created attachment 107822
Connection error after resuming from suspend

Log from the original reporter.

[Aleksander Morgado (aleksander-m)]

An additional report which is showing the same issue, but hibernating instead of suspending:

https://bugzilla.gnome.org/show_bug.cgi?id=725377
http://lists.freedesktop.org/archives/modemmanager-devel/2014-February/000893.html

[Aleksander Morgado (aleksander-m)]

(In reply to Aleksander Morgado from comment #3)
> An additional report which is showing the same issue, but hibernating
> instead of suspending:
>
> https://bugzilla.gnome.org/show_bug.cgi?id=725377
> http://lists.freedesktop.org/archives/modemmanager-devel/2014-February/
> 000893.html

This is unrelated sorry; the NotOpened error is actually tracked in bug 84994.

[Doome (doome)]

I reproduced the error situation (boot, connect, disconnect, sleep, connect) on my current f22, and saved ModemManager and NetworkManager logs as requested in the original bugreport.

Relevant software versions:
NetworkManager 1.0.0
ModemManager 1.4.4
kernel 4.0.0

Attaching the logs.

[Doome (doome)]

Created attachment 114288
NetworkManager log - connect failure after sleep

[Doome (doome)]

Created attachment 114289
ModemManager log - connect failure after sleep

[Ralph (ralph-bariz)]

proposed fix, works well for me.

whats happening here? forcing device into qmi mode.

source: http://www.0xf8.org/2015/07/dell-wireless-5809e-support-in-linux-a-followup/
had to modify his rules for the original device

create udev rules with pasted content. comment in first line is the filename.
http://pastebin.com/57r5QJ7A

delete existing mobile broadband profiles for device -> cold reboot -> recreate profile -> have fun
(after suspending, for sure device still needs time for finding signal)

regards
ralph

[Ralph (ralph-bariz)]

repost of udev rules fixing issue (/etc/udev/rules.d) as attachement

[Marius B. Kotsbak (mariusko)]

Is this information useful for this issue?: http://www.0xf8.org/2015/07/dell-wireless-5809e-support-in-linux-a-followup/

Or something else in downstream bug report: https://bugs.launchpad.net/bugs/1326954

[Doome (doome)]

With the aforementioned udev rules file, the situation got much better. However, it is not perfect. In some occasions (about 20~30% of resumes), the modem is still unusable, and when this happens, only a reboot can help to get it usable again.

[Ralph (ralph-bariz)]

It gives an overview about whats happening and why this solution works. (the dell device is an em7305)

[Ralph (ralph-bariz)]

problem still persists with ubuntu 16.04 beta with actual packages. as i can tell from first trying, the qmi mode (above fix proposal) works better than with actual 15.10.

br

[flopin (flopin)]

I can also confirm this bug in 16.04.

[Michael (3-ueuntu-4)]

This problem is also happening in debian Stretch (using kernel 4.8).

[Adrian Perez (aperezdc)]

I also have this issue, with a Fujitsu S936 laptop which includes an EM7305.
After adding the udev rules in the post at 0xf8.org (modifying them to fit
use the USB identifier that shows in my laptop, 1199:9041), the “mbim-proxy”
program seems to hang in some kind of loop, chewing 80% of CPU time according
to “top”. Here are the details of my configuration:

- Arch Linux
- ModemManager 1.6.4
- NetworkManager 1.4.4
- libmbim 1.14.0
- Kernel 4.9.5

I will be posting the output from “lsusb -v -d 1199:9041” as an attachment.

[Adrian Perez (aperezdc)]

Created attachment 129120
Output of "lsusb -v -d 1199:9041" on Fujitsu S936

[Aleksander Morgado (aleksander-m)]

(In reply to Adrian Perez de Castro from comment #10)
> I also have this issue, with a Fujitsu S936 laptop which includes an EM7305.
> After adding the udev rules in the post at 0xf8.org (modifying them to fit
> use the USB identifier that shows in my laptop, 1199:9041), the “mbim-proxy”
> program seems to hang in some kind of loop, chewing 80% of CPU time according
> to “top”. Here are the details of my configuration:
>
> - Arch Linux
> - ModemManager 1.6.4
> - NetworkManager 1.4.4
> - libmbim 1.14.0
> - Kernel 4.9.5
>
> I will be posting the output from “lsusb -v -d 1199:9041” as an attachment.

I believe you misread what the rules in the blogpost are doing :) I think the rules try to force the device into QMI mode, instead of the MBIM mode that would be picked up by default. This was a better choice for the Dell modem at that time because there wasn't support for running QMI commands over MBIM, and the Dell modem really required the FCC Auth command; but that is no longer the case, as MM already handles QMI over MBIM automatically as well as the FCC auth command for the Dell device.

Anyway, in your case it seems the rules didn't work as expected because you're still in MBIM mode, which is the one I would anyway suggest. I believe you can remove all the udev rules, as the kernel (or usb_modeswitch, it depends) should choose the MBIM configuration as preferred automatically.

That said, could you gather MM and mbim-proxy debug logs? I'd like to check whether the issue is exactly the same one:

$> sudo systemctl stop ModemManager
$> sudo killall -9 mbim-proxy
$> sudo /usr/libexec/mbim-proxy --verbose > /tmp/mbim-proxy.log 2>&1 &
$> sudo /usr/sbin/ModemManager --debug > /tmp/mm.log 2>&1 &
(and retry reproducing the issue)

[RussianNeuroMancer (russianneuromancer)]

I have same issue on Dell Venue 8 Pro 5855 tablet with Dell Wireless 5809e (Sierra Wireless AirPrime EM7305; default SWI9X15C_05.05.58.00 firmware).

Please look into attached logs:
4:26 mbim-proxy and ModemManager proxy is started, then tablet was suspended
4:27 wakeup from suspended, connection is not established
4:28 second attempt to connect, also unsuccessful.

mbim-proxy and ModemManager termination and following restart allowed me to successfully establish connection again.

If my issue is different and I need to fill separate bugreport - please let me know.

[RussianNeuroMancer (russianneuromancer)]

Created attachment 130974
mbim-proxy log (suspend -> wakeup) from EM7305

[RussianNeuroMancer (russianneuromancer)]

Created attachment 130975
ModemManager (suspend -> wakeup) from EM7305

[RussianNeuroMancer (russianneuromancer)]

And in case it could help someone, this workaround systemd unit helps me. With this unit connection could be established after suspend.

/etc/systemd/system/ModemManagerHook.service:

[Unit]
Description=ModemManager sleep hook
Before=sleep.target
StopWhenUnneeded=yes

[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=-/bin/systemctl stop ModemManager
ExecStop=-/bin/systemctl start ModemManager

[Install]
WantedBy=sleep.target

[Aleksander Morgado (aleksander-m)]

(In reply to russianneuromancer from comment #16)
> And in case it could help someone, this workaround systemd unit helps me.
> With this unit connection could be established after suspend.

Did you compile ModemManager with 'systemd' suspend/resume support? Ideally, MM should detect the suspend/resume events and reprobe the devices from scratch.

[Aleksander Morgado (aleksander-m)]

(In reply to Aleksander Morgado from comment #17)
> (In reply to russianneuromancer from comment #16)
> > And in case it could help someone, this workaround systemd unit helps me.
> > With this unit connection could be established after suspend.
>
> Did you compile ModemManager with 'systemd' suspend/resume support? Ideally,
> MM should detect the suspend/resume events and reprobe the devices from
> scratch.

Nevermind, I see the suspend/resume is in place in MM so the bug is still applicable there; I'll analyze the logs and let you know what I find.

[RussianNeuroMancer (russianneuromancer)]

I wonder if the fact that I use "suspend freeze" mode instead of default "suspend" mode makes a difference?
https://www.freedesktop.org/software/systemd/man/sleep.conf.d.html

I have to do so because modern hardware implement S0i3 instead of S3, so default mode will just won't work (tablets and laptops without S3 support will just poweroff or reboot on attempt to go into S3).

> I'll analyze the logs and let you know what I find.

Ok. Just to let you know, I find first unit not reliable enough, so I edited it a little bit:
Removed "StopWhenUnneeded=yes" and "RemainAfterExit=yes".
Replaced "=-/bin/systemctl" with "=/bin/systemctl".

[RussianNeuroMancer (russianneuromancer)]

Hi

Any news?

[Aleksander Morgado (aleksander-m)]

(In reply to russianneuromancer from comment #20)
> Hi
>
> Any news?

Yes, see: https://lists.freedesktop.org/archives/modemmanager-devel/2017-August/005668.html

Could you apply the patch in a custom build and retry, to see if it fixes your issue?

[RussianNeuroMancer (russianneuromancer)]

> Could you apply the patch in a custom build and retry, to see if it fixes your issue?

Hello!

Thank you for looking into this issue! :)

I tried to build version 1.6.8, but build failed:
https://launchpad.net/~russianneuromancer/+archive/ubuntu/drivers/+build/13571525

It is supposed to work with version 1.6.8 or I need master? (In latter case I have no idea how to build modemmanager package.)

[Aleksander Morgado (aleksander-m)]

If you want to apply it on a 1.6.x version, use this patch instead:
https://cgit.freedesktop.org/ModemManager/ModemManager/commit/?h=mm-1-6&id=196b8d619ad16d625ab0cc520854c2a044c0e4eb

[RussianNeuroMancer (russianneuromancer)]

Thanks you once again :)

Yes, with this patch build was successful. I will test it next week and will let you know.

[RussianNeuroMancer (russianneuromancer)]

Created attachment 134821
ModemManager 1.6.8, patched, suspend->resume cycle

I was able to test it kind of ahead of time, and unfortunately this doesn't help. Log attached.

[RussianNeuroMancer (russianneuromancer)]

Created attachment 134822
ModemManagerHook.service

I also need to mention that workaround from Commentary 16 later was modified to not only restart ModemManager, but also detach modem before suspend, and reattach it after suspend.

systemd unit is attached.

[Daniel-rowe (daniel-rowe)]

I am also seeing this issue on Fedora 27 with Toshiba laptop.

I was having this issues: https://bugs.freedesktop.org/show_bug.cgi?id=100879 but this was fix in Fedora 27.

Now it work just fine till suspend.

I have tried the systemd unit and the modem at least shows with this but it wont connect.

[RussianNeuroMancer (russianneuromancer)]

In addition to Dell Venue 8 Pro 5855 tablet with Dell Wireless 5809e (Comment 13) I find same issue reproducible on Dell Wireless 5810e (Telit LN930 with 1620 firmware) with patch from Comment 23.

I also find that detach/attach modem via systemd unit is sufficient, ModemManager restart seems like not necessary.

Aleksander, please let us know if any additional logs or testing is required.

[Gitlab-migration (gitlab-migration)]

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/mobile-broadband/ModemManager/issues/30.