Bug 84992

Created attachment 107821 [details]
Successful connection attempt after a full reboot

Log from the original reporter.

Created attachment 107822 [details]
Connection error after resuming from suspend

Log from the original reporter.

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

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

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.

Created attachment 114288 [details]
NetworkManager log - connect failure after sleep

Created attachment 114289 [details]
ModemManager log - connect failure after sleep

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

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.

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.

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

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

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.

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

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

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

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

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

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

Hi

Any news?

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

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

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

Thanks you once again :)

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

Created attachment 134821 [details]
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.

Created attachment 134822 [details]
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.

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.

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