I just started having this problem last week. My wife telling me she tried to call, but I don’t answer. After some testing, it seems like the modem goes to sleep or just hangs in some weird state after a couple of hours of non use. I let the phone sit on the charger overnite, then I tried to call it in the morning. Using my wife phone, it sounds like the call is going through. I hear ringing for a while then it goes to voicemail. Nothing happens on the L5. I run the bm818 tool, it takes about 20 seconds to open, Under FW version it say “fetching” then eventually shows “Failed to get Modem FW version”. The weird thing is, I have 3 bars of signal strength and showing 4G. So I’m guessing the cell modem is hung and the screen isn’t updating? If I cycle the switch on the side, it starts working again
Probably you are seeing this issue:
That sounds like what it’s doing. But, I have this phone for almost a year and never had this problem. I did get a bunch of updates last week. Maybe something in there causing trouble? If I did a restore from 2 weeks ago would that reverse the system updates or does that just backup my apps?
Could you try editing /lib/udev/rules.d/85-librem5-pm.rules
:
change line:
SUBSYSTEM=="usb", ATTR{idVendor}=="2020", ATTR{idProduct}=="2060", TEST=="power/autosuspend_delay_ms", ATTR{power/autosuspend_delay_ms}="1500"
to
SUBSYSTEM=="usb", ATTR{idVendor}=="2020", ATTR{idProduct}=="2060", TEST=="power/autosuspend_delay_ms", ATTR{power/autosuspend_delay_ms}="2000"
and
SUBSYSTEM=="usb", ATTR{idVendor}=="0424", ATTR{idProduct}=="2640", TEST=="power/autosuspend_delay_ms", ATTR{power/autosuspend_delay_ms}="500"
to
SUBSYSTEM=="usb", ATTR{idVendor}=="0424", ATTR{idProduct}=="2640", TEST=="power/autosuspend_delay_ms", ATTR{power/autosuspend_delay_ms}="0"
then reboot. This was the only recent change that comes to my mind as potentially relevant.
I have also noticed more problems during the last week or so.
A theory is that some recent update(s) have made it so that it does not recover the way it used to. The USB disconnect thing usually happens several times every day, but the phone used to recover by itself, the modem connected again automatically. Now it seems more often it does not recover by itself.
I changed those values last night. Everything was good this morning. I’ll keep you posted if it acts up again.
Thanks
Seems this is just a matter of luck. On some devices the new settings make things better.
The good news is that we may have just came up with an actual workaround to these issues that doesn’t rely on probability, so stay tuned:)
Could be a regression on my L5, also. I’ll try the former settings…
I suspect that what may appear random here is in fact a result of the network communication pattern, that may depend on what your phone has installed and what things in the outside world it is communicating with. Because the issue seems to be “remote wakeup” happening at the same time as autosuspend was just happening. Example: if my phone talks to a chat server that often tries to talk to my phone after a delay of 3 seconds, then autosuspend_delay_ms
3000 ms might be a poor choice for me.
Not just network communication pattern, but also other “random” things like signal strength indications. You may have different results just because you placed your phone in another room where reception is different.
FWIW I have reverted the recent changes, updated package is going to appear in byzantium in a few days.
@dos, will you reset those to the former settings with one of the next versions?
I just reverted to check whether this stops the modem from not functioning without any sign in the gui or in mmcli
.
Is there somewhere an open issue for this behaviour: modem does not work, but mmcli
and gui show a working state?
What would be the test/check to find out that the modem is in this sad state?
Update: reverting to the old settings made the modem reset a few times and then finally the usb bus fail. Basically the old behaviour. I’ll have to wait whether the state that the modem looks o.k. from the OS, but doesn’t have a connection will return or not.
I don’t see anyone capitalizing on this so I will. This is GREAT NEWS!!! I am drooling for the update!
This combined with the double lockscreen race condition error on resume from suspend will be huge quality of life improvements!
Really excited! I’m just going to wait for this fix to be pushed. I really hope it pans out!
I am following this thread with great interest, because the cell modem on my L5 is unusable more often than not. It very often fails to connect altogether, sometimes it connects briefly just to disconnect the moment after. I am also used to seeing 4 bars + 4G in the indicator and no internet connection. If I am connected to WiFi and then turn WiFi off or leave the house, I also see the 4 bars + 4G and no internet connection very frequently.
I can’t say for sure that the problems have gotten worse lately, but my L5 may have had more of a struggle to keep a cellular connection during the past week or so.
Bottom line is that on WiFi I am mostly fine, but rarely when I leave the house and move about trying to rely on a cellular internet connection. I don’t know what role roaming in Spain may have in this, but the cellular performance is definitely worse than when I am in Sweden connected to my home carrier Telia.
Which logs should I provide to help troubleshoot these problems?
Edit: I use the following .desktop file to reset the modem several times a day:
[Desktop Entry]
Name=Modem reset
Exec=gnome-terminal -x bash -c "echo 0 | sudo tee /sys/class/leds/wwan_en/brightness; sleep 5; echo 1 | sudo tee /sys/class/leds/wwan_en/brightness"
StartupNotify=true
Terminal=false
Type=Application
Categories=Utilities;
X-Purism-FormFactor=Workstation;Mobile;
Icon=/home/purism/.local/share/icons/modem-reset.png
Just to be clear - this is about random USB re-enumerations, so basically modem disappearing randomly and reappearing soon after. It’s completely unrelated to system suspend, and there are also other things that can trigger lack of mobile data connection (but it should be a great improvement on modem’s reliability already).
Yeah, here I am referring to improvements being pushed in the form of Phosh 0.25.
Basically thanking you all for two very important improvements coming down the pipe!
I am there again where the modem can’t be recovered. Don’t know if it is related to the above, but here is end of journalctl log:
mar 07 16:25:17 pureos NetworkManager[692]: <warn> [1678202717.6174] modem-broadband[cdc-wdm0]: failed to disconnect modem: GDBus.Error:org.freedesktop.DBus.Error.UnknownMethod: No such interface “org.freedesktop.ModemManager1.Modem.Simple” on object at path /org/freedesktop/ModemManager1/Modem/4
mar 07 16:52:06 pureos ModemManager[6425]: <info> [base-manager] couldn't check support for device '/sys/devices/platform/soc@0/30800000.bus/30b50000.mmc/mmc_host/mmc1/mmc1:fffd/mmc1:fffd:1': not supported by any plugin
Edit: After a fresh reboot I get this in the log.
mar 07 16:59:25 pureos mmsdtng[1339]: ../plugins/modemmanager.c:modem_state_changed_cb() State Change: Old State: 8 New State: 10, Reason: 1
mar 07 16:59:25 pureos mmsdtng[1339]: ../plugins/modemmanager.c:mmsd_mm_get_modem_state() MM_MODEM_GOOD_STATE: 10
mar 07 16:59:25 pureos mmsdtng[1339]: ../plugins/modemmanager.c:mmsd_mm_state() MMSD_MM_STATE_READY
mar 07 16:59:25 pureos mmsdtng[1339]: ../plugins/modemmanager.c:mmsd_mm_state() Setting Bearer Handler
mar 07 16:59:25 pureos ModemManager[804]: <info> [modem0/bearer2] couldn't start network: QMI protocol error (14): 'CallFailed'
mar 07 16:59:25 pureos ModemManager[804]: <info> [modem0/bearer2] verbose call end reason (3,2001): [cm] no-service
mar 07 16:59:25 pureos ModemManager[804]: <warn> [modem0/bearer2] connection attempt #3 failed: Call failed: cm error: no-service
mar 07 16:59:25 pureos ModemManager[804]: <info> [modem0] state changed (connecting -> registered)
mar 07 16:59:25 pureos ModemManager[804]: <info> [modem0/bearer2] connection #3 finished: duration 0s, tx: 0 bytes, rx: 0 bytes
mar 07 16:59:25 pureos mmsdtng[1339]: ../plugins/modemmanager.c:modem_state_changed_cb() State Change: Old State: 10 New State: 8, Reason: 1
mar 07 16:59:25 pureos mmsdtng[1339]: ../plugins/modemmanager.c:mmsd_mm_get_modem_state() MM_MODEM_GOOD_STATE: 8
mar 07 16:59:25 pureos mmsdtng[1339]: ../plugins/modemmanager.c:mmsd_mm_state() MMSD_MM_STATE_READY
mar 07 16:59:25 pureos mmsdtng[1339]: ../plugins/modemmanager.c:mmsd_mm_state() Setting Bearer Handler
mar 07 16:59:25 pureos ModemManager[804]: <info> [modem0] simple connect started...
mar 07 16:59:25 pureos ModemManager[804]: <info> [modem0] simple connect state (4/8): wait to get fully enabled
mar 07 16:59:25 pureos ModemManager[804]: <info> [modem0] simple connect state (5/8): register
mar 07 16:59:25 pureos ModemManager[804]: <info> [modem0] simple connect state (6/8): bearer
mar 07 16:59:25 pureos ModemManager[804]: <info> [modem0] simple connect state (7/8): connect
mar 07 16:59:25 pureos ModemManager[804]: <info> [modem0] state changed (registered -> connecting)
mar 07 16:59:25 pureos mmsdtng[1339]: ../plugins/modemmanager.c:modem_state_changed_cb() State Change: Old State: 8 New State: 10, Reason: 1
mar 07 16:59:25 pureos mmsdtng[1339]: ../plugins/modemmanager.c:mmsd_mm_get_modem_state() MM_MODEM_GOOD_STATE: 10
mar 07 16:59:25 pureos mmsdtng[1339]: ../plugins/modemmanager.c:mmsd_mm_state() MMSD_MM_STATE_READY
mar 07 16:59:25 pureos mmsdtng[1339]: ../plugins/modemmanager.c:mmsd_mm_state() Setting Bearer Handler
mar 07 16:59:25 pureos ModemManager[804]: <info> [modem0/bearer3] couldn't start network: QMI protocol error (14): 'CallFailed'
mar 07 16:59:25 pureos ModemManager[804]: <info> [modem0/bearer3] verbose call end reason (3,2001): [cm] no-service
mar 07 16:59:25 pureos ModemManager[804]: <warn> [modem0/bearer3] connection attempt #3 failed: Call failed: cm error: no-service
mar 07 16:59:25 pureos ModemManager[804]: <info> [modem0] state changed (connecting -> registered)
mar 07 16:59:25 pureos ModemManager[804]: <info> [modem0/bearer3] connection #3 finished: duration 0s, tx: 0 bytes, rx: 0 bytes
mar 07 16:59:25 pureos mmsdtng[1339]: ../plugins/modemmanager.c:modem_state_changed_cb() State Change: Old State: 10 New State: 8, Reason: 1
mar 07 16:59:25 pureos mmsdtng[1339]: ../plugins/modemmanager.c:mmsd_mm_get_modem_state() MM_MODEM_GOOD_STATE: 8
mar 07 16:59:25 pureos mmsdtng[1339]: ../plugins/modemmanager.c:mmsd_mm_state() MMSD_MM_STATE_READY
mar 07 16:59:25 pureos mmsdtng[1339]: ../plugins/modemmanager.c:mmsd_mm_state() Setting Bearer Handler
This is the 3rd time my cell modem failed today. Below are the logs for the latest one:
mar 09 13:08:10 pureos ModemManager[799]: <warn> [modem1] port ttyUSB1 timed out 2 consecutive times
mar 09 13:08:13 pureos ModemManager[799]: <warn> [modem1] couldn't load network timezone from the current network
mar 09 13:08:13 pureos ModemManager[799]: <warn> [modem1] port ttyUSB1 timed out 3 consecutive times
mar 09 13:08:15 pureos ModemManager[799]: <info> [modem1] simple connect started...
mar 09 13:08:15 pureos ModemManager[799]: <info> [modem1] simple connect state (4/8): wait to get fully enabled
mar 09 13:08:15 pureos ModemManager[799]: <info> [modem1] simple connect state (5/8): register
mar 09 13:08:16 pureos ModemManager[799]: <warn> [modem1] port ttyUSB1 timed out 4 consecutive times
mar 09 13:08:19 pureos ModemManager[799]: <warn> [modem1] couldn't load operator code: Serial command timed out
mar 09 13:08:19 pureos ModemManager[799]: <warn> [modem1] port ttyUSB1 timed out 5 consecutive times
mar 09 13:08:22 pureos ModemManager[799]: <warn> [modem1/bearer5] connection attempt #1 failed: Serial command timed out
mar 09 13:08:22 pureos ModemManager[799]: <info> [modem1/bearer5] connection #1 finished: duration 0s, tx: 0 bytes, rx: 0 bytes
mar 09 13:08:22 pureos ModemManager[799]: <warn> [modem1] port ttyUSB1 timed out 6 consecutive times
mar 09 13:08:25 pureos ModemManager[799]: <warn> [modem1] port ttyUSB1 timed out 7 consecutive times
mar 09 13:10:25 pureos ModemManager[799]: <info> [modem1] 3GPP registration state changed (searching -> idle)
mar 09 13:10:25 pureos ModemManager[799]: <info> [modem1] state changed (searching -> enabled)
mar 09 13:10:25 pureos ModemManager[799]: <warn> [modem1] port ttyUSB1 timed out 8 consecutive times
mar 09 13:10:25 pureos ModemManager[799]: <info> [modem1] simple connect started...
mar 09 13:10:25 pureos ModemManager[799]: <info> [modem1] simple connect state (4/8): wait to get fully enabled
mar 09 13:10:25 pureos ModemManager[799]: <info> [modem1] simple connect state (5/8): register
mar 09 13:10:29 pureos ModemManager[799]: <warn> [modem1] port ttyUSB1 timed out 9 consecutive times
mar 09 13:10:32 pureos ModemManager[799]: <warn> [modem1] couldn't load operator name: Serial command timed out
mar 09 13:10:32 pureos ModemManager[799]: <info> [modem1] 3GPP registration state changed (registering -> roaming)
mar 09 13:10:32 pureos ModemManager[799]: <info> [modem1] state changed (enabled -> registered)
mar 09 13:10:32 pureos ModemManager[799]: <error> [modem1] port ttyUSB1 timed out 10 consecutive times, marking modem as invalid
mar 09 13:10:32 pureos ModemManager[799]: <info> [modem1] 3GPP registration state changed (roaming -> idle)
mar 09 13:10:32 pureos mmsdtng[1350]: ../plugins/modemmanager.c:cb_object_removed() Modem removed: /org/freedesktop/ModemManager1/Modem/1
mar 09 13:10:32 pureos NetworkManager[671]: <warn> [1678363832.6616] modem-broadband[ttyUSB1]: failed to disconnect modem: GDBus.Error:org.freedesktop.DBus.Error.UnknownMethod: No such interface “org.freedesktop.ModemManager1.Modem.Simple” on object at path /org/freedesktop/ModemManager1/Modem/1
The most recent one, I was able to recover by the command below, but one of the earlier ones today needed a reboot to come back.
sudo tee /sys/class/leds/wwan_en/brightness; sleep 5; echo 1 | sudo tee /sys/class/leds/wwan_en
@dos Any clue to why this is happening?
That’s how it works right now. Improvements are on the way.
It definitely works better with this tweak. Thanks
FWIW it’s already made it to a package update in byzantium, so it’s there by default on an up-to-date system.
Further improvements are still coming.