Ubuntu
libmbim package

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

Bug #1326954 reported by Alex Yurchenko
40
This bug affects 8 people
Affects Status Importance Assigned to Milestone
ModemManager
Unknown
Medium
libmbim (Ubuntu)
Confirmed
Undecided
Unassigned
modemmanager (Ubuntu)
Invalid
Undecided
Unassigned

Bug Description

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'

Revision history for this message
Alex Yurchenko (ayurchen) wrote :
Alex Yurchenko (ayurchen)
summary: - ModemManager does not seem to recognize Sierra Wireless EM7305
+ ModemManager does not seem to recognize Sierra Wireless EM7305 (Fujitsu
+ Lifebook S904)
Revision history for this message
Launchpad Janitor (janitor) wrote : Re: ModemManager does not seem to recognize Sierra Wireless EM7305 (Fujitsu Lifebook S904)

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

Changed in modemmanager (Ubuntu):
status: New → Confirmed
Revision history for this message
Marius B. Kotsbak (mariusko) wrote :

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?

Changed in modemmanager (Ubuntu):
status: Confirmed → Incomplete
Changed in libmbim (Ubuntu):
status: New → Incomplete
Revision history for this message
Marius B. Kotsbak (mariusko) wrote :

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.

Changed in libmbim (Ubuntu):
status: Incomplete → Confirmed
Changed in modemmanager (Ubuntu):
status: Incomplete → Confirmed
status: Confirmed → Invalid
Bug Watch Updater (bug-watch-updater)
Changed in modemmanager:
importance: Unknown → Medium
status: Unknown → New
Revision history for this message
Данило Шеган (danilo) wrote :

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

Revision history for this message
Pier Paolo (pierpaolo-franco) wrote :

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?

Revision history for this message
Pier Paolo (pierpaolo-franco) wrote :

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.

Revision history for this message
In , Aleksander Morgado (aleksander-m) wrote :

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.

Revision history for this message
In , Aleksander Morgado (aleksander-m) wrote :

Created attachment 107821
Successful connection attempt after a full reboot

Log from the original reporter.

Revision history for this message
In , Aleksander Morgado (aleksander-m) wrote :

Created attachment 107822
Connection error after resuming from suspend

Log from the original reporter.

Revision history for this message
In , Aleksander Morgado (aleksander-m) wrote :

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

Revision history for this message
In , Aleksander Morgado (aleksander-m) wrote :

(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.

Bug Watch Updater (bug-watch-updater)
Changed in modemmanager:
status: New → Unknown
Marius B. Kotsbak (mariusko)
Changed in modemmanager:
importance: Medium → Unknown
Bug Watch Updater (bug-watch-updater)
Changed in modemmanager:
importance: Unknown → Medium
status: Unknown → Confirmed
Marius B. Kotsbak (mariusko)
summary: - ModemManager does not seem to recognize Sierra Wireless EM7305 (Fujitsu
- Lifebook S904)
+ Sierra Wireless EM7305 (Fujitsu Lifebook S904) does not work after
+ suspend/hibernate
Revision history for this message
In , Doome (doome) wrote :

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.

Revision history for this message
In , Doome (doome) wrote :

Created attachment 114288
NetworkManager log - connect failure after sleep

Revision history for this message
In , Doome (doome) wrote :

Created attachment 114289
ModemManager log - connect failure after sleep

Revision history for this message
Ralph (ralph-bariz) wrote :

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

Revision history for this message
Ralph (ralph-bariz) wrote :

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

Revision history for this message
In , Marius B. Kotsbak (mariusko) wrote :

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

Revision history for this message
In , Doome (doome) wrote :

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.

Revision history for this message
Ralph (ralph-bariz) wrote :

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

Revision history for this message
Ralph (ralph-bariz) wrote :

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

Revision history for this message
flopin (flopin) wrote :

I can also confirm this bug in 16.04.

Revision history for this message
Michael (3-ueuntu-4) wrote :

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

Revision history for this message
In , Adrian Perez (aperezdc) wrote :

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.

Revision history for this message
In , Adrian Perez (aperezdc) wrote :

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

Revision history for this message
In , Aleksander Morgado (aleksander-m) wrote :

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

Revision history for this message
In , RussianNeuroMancer (russianneuromancer) wrote :

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.

Revision history for this message
In , RussianNeuroMancer (russianneuromancer) wrote :

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

Revision history for this message
In , RussianNeuroMancer (russianneuromancer) wrote :

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

Revision history for this message
In , RussianNeuroMancer (russianneuromancer) wrote :

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

Revision history for this message
In , Aleksander Morgado (aleksander-m) wrote :

(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.

Revision history for this message
In , Aleksander Morgado (aleksander-m) wrote :

(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.

Revision history for this message
In , RussianNeuroMancer (russianneuromancer) wrote :

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".

Revision history for this message
In , RussianNeuroMancer (russianneuromancer) wrote :

Hi

Any news?

Revision history for this message
In , Aleksander Morgado (aleksander-m) wrote :

(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?

Bug Watch Updater (bug-watch-updater)
Changed in modemmanager:
status: Confirmed → Incomplete
Revision history for this message
In , RussianNeuroMancer (russianneuromancer) wrote :

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

Revision history for this message
In , Aleksander Morgado (aleksander-m) wrote :

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

Revision history for this message
In , RussianNeuroMancer (russianneuromancer) wrote :

Thanks you once again :)

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

Revision history for this message
In , RussianNeuroMancer (russianneuromancer) wrote :

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.

Revision history for this message
In , RussianNeuroMancer (russianneuromancer) wrote :

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.

Revision history for this message
In , Daniel-rowe (daniel-rowe) wrote :

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.

Revision history for this message
In , RussianNeuroMancer (russianneuromancer) wrote :

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.

Bug Watch Updater (bug-watch-updater)
Changed in modemmanager:
status: Incomplete → Confirmed
Revision history for this message
In , Gitlab-migration (gitlab-migration) wrote :

-- 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.

Bug Watch Updater (bug-watch-updater)
Changed in modemmanager:
status: Confirmed → Unknown
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.
Subscribing...

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.