When you say it wouldn’t turn the screen on, are you sure the phone was powered on at that moment? I mean, could it be that it had powered itself off earlier?
1 Like
Reasonably certain, as I believe holding down the power button should have powered it on in that case.
(If you hold down the power button and it’s off the green light will come on,and it turns on)
I had to hold down the power button, wait, then had to hold it down again to get it to power on.
1 Like
Do you by any chance have automatic suspend enabled in the power settings?
Nope, it’s disabled.
Digging in the logs here’s what I see before the last boot that wasn’t the running out of battery. Which is almost certainly the mentioned issue:
Aug 11 12:16:50 librem ModemManager[724]: <warn> [modem1/bearer1] reloading stats failed: QMI operation failed: Transaction timed out
Aug 11 12:17:01 librem CRON[5704]: pam_unix(cron:session): session opened for user root(uid=0) by (uid=0)
Aug 11 12:17:01 librem CRON[5705]: (root) CMD ( cd / && run-parts --report /etc/cron.hourly)
Aug 11 12:17:01 librem CRON[5704]: pam_unix(cron:session): session closed for user root
Aug 11 12:18:14 librem kernel: rcu: INFO: rcu_preempt self-detected stall on CPU
Aug 11 12:18:14 librem kernel: rcu: 0-....: (1 GPs behind) idle=762/1/0x4000000000000004 softirq=278238/278239 fqs=75389
Aug 11 12:18:14 librem kernel: (t=162780 jiffies g=586405 q=10077)
Aug 11 12:18:14 librem kernel: Task dump for CPU 0:
Aug 11 12:18:14 librem kernel: task:kworker/0:2 state:R running task stack: 0 pid: 5162 ppid: 2 flags:0x0000000a
Aug 11 12:18:14 librem kernel: Workqueue: usb_hub_wq hub_event [usbcore]
Aug 11 12:18:14 librem kernel: Call trace:
Aug 11 12:18:14 librem kernel: dump_backtrace+0x0/0x1e4
Aug 11 12:18:14 librem kernel: show_stack+0x24/0x30
Aug 11 12:18:14 librem kernel: sched_show_task+0x15c/0x180
Aug 11 12:18:14 librem kernel: dump_cpu_task+0x50/0x60
Aug 11 12:18:14 librem kernel: rcu_dump_cpu_stacks+0xfc/0x144
Aug 11 12:18:14 librem kernel: rcu_sched_clock_irq+0xacc/0xe50
Aug 11 12:18:14 librem kernel: update_process_times+0xa8/0xf4
Aug 11 12:18:14 librem kernel: tick_sched_handle+0x3c/0x60
Aug 11 12:18:14 librem kernel: tick_sched_timer+0x58/0xb0
Aug 11 12:18:14 librem kernel: __hrtimer_run_queues+0x18c/0x3a0
Aug 11 12:18:14 librem kernel: hrtimer_interrupt+0xf4/0x2cc
Aug 11 12:18:14 librem kernel: arch_timer_handler_phys+0x40/0x50
Aug 11 12:18:14 librem kernel: handle_percpu_devid_irq+0x94/0x280
Aug 11 12:18:14 librem kernel: __handle_domain_irq+0x8c/0xf0
Aug 11 12:18:14 librem kernel: gic_handle_irq+0xc8/0x148
Aug 11 12:18:14 librem kernel: el1_irq+0xbc/0x154
Aug 11 12:18:14 librem kernel: _raw_spin_unlock_irqrestore+0x18/0x5c
Aug 11 12:18:14 librem kernel: usb_hcd_submit_urb+0xdc/0xa60 [usbcore]
Aug 11 12:18:14 librem kernel: usb_submit_urb+0x19c/0x5c0 [usbcore]
Aug 11 12:18:14 librem kernel: usb_wwan_indat_callback+0x50/0x170 [usb_wwan]
Aug 11 12:18:14 librem kernel: __usb_hcd_giveback_urb+0x98/0x150 [usbcore]
Aug 11 12:18:14 librem kernel: usb_giveback_urb_bh+0xb8/0x120 [usbcore]
Aug 11 12:18:14 librem kernel: tasklet_action_common.constprop.0+0x100/0x130
Aug 11 12:18:14 librem kernel: tasklet_action+0x34/0x40
Aug 11 12:18:14 librem kernel: __do_softirq+0x120/0x3e8
Aug 11 12:18:14 librem kernel: irq_exit+0xf8/0x100
Aug 11 12:18:14 librem kernel: __handle_domain_irq+0x90/0xf0
Aug 11 12:18:14 librem kernel: gic_handle_irq+0xc8/0x148
Aug 11 12:18:14 librem kernel: el1_irq+0xbc/0x154
Aug 11 12:18:14 librem kernel: _raw_spin_unlock_irq+0x1c/0x60
Aug 11 12:18:14 librem kernel: schedule+0xf8/0x110
Aug 11 12:18:14 librem kernel: schedule_timeout+0xa4/0x1d4
Aug 11 12:18:14 librem kernel: wait_for_completion_timeout+0x8c/0x110
Aug 11 12:18:14 librem kernel: usb_start_wait_urb+0xec/0x170 [usbcore]
Aug 11 12:18:14 librem kernel: usb_control_msg+0xc8/0x144 [usbcore]
Aug 11 12:18:14 librem kernel: hub_event+0x8c4/0x18cc [usbcore]
Aug 11 12:18:14 librem kernel: process_one_work+0x204/0x4dc
Aug 11 12:18:14 librem kernel: worker_thread+0x148/0x47c
Aug 11 12:18:14 librem kernel: kthread+0x15c/0x170
Aug 11 12:18:14 librem kernel: ret_from_fork+0x10/0x34
-- Boot facfc953c38a467d8ba744e240719f33 --
Aug 11 12:45:23 librem kernel: Booting Linux on physical CPU 0x0000000000 [0x410fd034]
I’ll note with the mention of cron hourly, the /etc/cron.hourly/ directory is empty, so I think that’s just coincidental.
Annother log entry on boot before that:
Aug 10 18:52:09 librem iio-sensor-prox[625]: Failed to read input level at /sys/devices/platform/soc@0/30800000.bus/30a30000.i2c/i2c-1/1-0060/iio:device0/in_illuminance_raw>
Aug 10 18:52:09 librem iio-sensor-prox[625]: Failed to read input level at /sys/devices/platform/soc@0/30800000.bus/30a30000.i2c/i2c-1/1-0060/iio:device0/in_illuminance_raw>
Aug 10 18:52:10 librem iio-sensor-prox[625]: Failed to read input level at /sys/devices/platform/soc@0/30800000.bus/30a30000.i2c/i2c-1/1-0060/iio:device0/in_illuminance_raw>
Aug 10 18:52:11 librem iio-sensor-prox[625]: Failed to read input level at /sys/devices/platform/soc@0/30800000.bus/30a30000.i2c/i2c-1/1-0060/iio:device0/in_illuminance_raw>
Aug 10 18:52:12 librem iio-sensor-prox[625]: Failed to read input level at /sys/devices/platform/soc@0/30800000.bus/30a30000.i2c/i2c-1/1-0060/iio:device0/in_illuminance_raw>
Aug 10 18:52:13 librem iio-sensor-prox[625]: Failed to read input level at /sys/devices/platform/soc@0/30800000.bus/30a30000.i2c/i2c-1/1-0060/iio:device0/in_illuminance_raw>
Aug 10 18:52:13 librem iio-sensor-prox[625]: Failed to read input level at /sys/devices/platform/soc@0/30800000.bus/30a30000.i2c/i2c-1/1-0060/iio:device0/in_illuminance_raw>
Aug 10 18:52:14 librem iio-sensor-prox[625]: Failed to read input level at /sys/devices/platform/soc@0/30800000.bus/30a30000.i2c/i2c-1/1-0060/iio:device0/in_illuminance_raw>
Aug 10 18:52:15 librem iio-sensor-prox[625]: Failed to read input level at /sys/devices/platform/soc@0/30800000.bus/30a30000.i2c/i2c-1/1-0060/iio:device0/in_illuminance_raw>
Aug 10 18:52:16 librem iio-sensor-prox[625]: Failed to read input level at /sys/devices/platform/soc@0/30800000.bus/30a30000.i2c/i2c-1/1-0060/iio:device0/in_illuminance_raw>
Aug 10 18:52:17 librem iio-sensor-prox[625]: Failed to read input level at /sys/devices/platform/soc@0/30800000.bus/30a30000.i2c/i2c-1/1-0060/iio:device0/in_illuminance_raw>
Aug 10 18:53:00 librem kernel: qmi_wwan 1-1.2:1.4: nonzero urb status received: -71
Aug 10 18:53:00 librem kernel: qmi_wwan 1-1.2:1.4: wdm_int_callback - 0 bytes
Aug 10 18:53:11 librem kernel: rcu: INFO: rcu_preempt self-detected stall on CPU
Aug 10 18:53:11 librem kernel: rcu: 0-....: (2614 ticks this GP) idle=386/1/0x4000000000000004 softirq=131649/131649 fqs=9377
Aug 10 18:53:11 librem kernel: (t=21007 jiffies g=267877 q=3294)
Aug 10 18:53:11 librem kernel: Task dump for CPU 0:
Aug 10 18:53:11 librem kernel: task:kworker/0:1 state:R running task stack: 0 pid: 2948 ppid: 2 flags:0x0000000a
Aug 10 18:53:11 librem kernel: Workqueue: mm_percpu_wq drain_local_pages_wq
Aug 10 18:53:11 librem kernel: Call trace:
Aug 10 18:53:11 librem kernel: dump_backtrace+0x0/0x1e4
Aug 10 18:53:11 librem kernel: show_stack+0x24/0x30
Aug 10 18:53:11 librem kernel: sched_show_task+0x15c/0x180
Aug 10 18:53:11 librem kernel: dump_cpu_task+0x50/0x60
Aug 10 18:53:11 librem kernel: rcu_dump_cpu_stacks+0xfc/0x144
Aug 10 18:53:11 librem kernel: rcu_sched_clock_irq+0xacc/0xe50
Aug 10 18:53:11 librem kernel: update_process_times+0xa8/0xf4
Aug 10 18:53:11 librem kernel: tick_sched_handle+0x3c/0x60
Aug 10 18:53:11 librem kernel: tick_sched_timer+0x58/0xb0
Aug 10 18:53:11 librem kernel: __hrtimer_run_queues+0x18c/0x3a0
Aug 10 18:53:11 librem kernel: hrtimer_interrupt+0xf4/0x2cc
Aug 10 18:53:11 librem kernel: hrtimer_interrupt+0xf4/0x2cc
Aug 10 18:53:11 librem kernel: arch_timer_handler_phys+0x40/0x50
Aug 10 18:53:11 librem kernel: handle_percpu_devid_irq+0x94/0x280
Aug 10 18:53:11 librem kernel: __handle_domain_irq+0x8c/0xf0
Aug 10 18:53:11 librem kernel: gic_handle_irq+0xc8/0x148
Aug 10 18:53:11 librem kernel: el1_irq+0xbc/0x154
Aug 10 18:53:11 librem kernel: __inval_dcache_area+0x48/0x5c
Aug 10 18:53:11 librem kernel: dma_map_page_attrs+0x138/0x210
Aug 10 18:53:11 librem kernel: usb_hcd_map_urb_for_dma+0x34c/0x480 [usbcore]
Aug 10 18:53:11 librem kernel: xhci_map_urb_for_dma+0x180/0x2d0 [xhci_hcd]
Aug 10 18:53:11 librem kernel: usb_hcd_submit_urb+0xbc/0xa60 [usbcore]
Aug 10 18:53:11 librem kernel: usb_submit_urb+0x19c/0x5c0 [usbcore]
Aug 10 18:53:11 librem kernel: usb_wwan_indat_callback+0x50/0x170 [usb_wwan]
Aug 10 18:53:11 librem kernel: __usb_hcd_giveback_urb+0x98/0x150 [usbcore]
Aug 10 18:53:11 librem kernel: usb_giveback_urb_bh+0xb8/0x120 [usbcore]
Aug 10 18:53:11 librem kernel: tasklet_action_common.constprop.0+0x100/0x130
Aug 10 18:53:11 librem kernel: tasklet_action+0x34/0x40
Aug 10 18:53:11 librem kernel: __do_softirq+0x120/0x3e8
Aug 10 18:53:11 librem kernel: irq_exit+0xf8/0x100
Aug 10 18:53:11 librem kernel: __handle_domain_irq+0x90/0xf0
Aug 10 18:53:11 librem kernel: gic_handle_irq+0xc8/0x148
Aug 10 18:53:11 librem kernel: el1_irq+0xbc/0x154
Aug 10 18:53:11 librem kernel: drain_local_pages+0x60/0xa0
Aug 10 18:53:11 librem kernel: drain_local_pages_wq+0x34/0x70
Aug 10 18:53:11 librem kernel: process_one_work+0x204/0x4dc
Aug 10 18:53:11 librem kernel: worker_thread+0x2cc/0x47c
Aug 10 18:53:11 librem kernel: kthread+0x15c/0x170
Aug 10 18:53:11 librem kernel: ret_from_fork+0x10/0x34
-- Boot 2c02b4163eb748c1941f979247853fdb --
Aug 10 18:56:49 librem kernel: Booting Linux on physical CPU 0x0000000000 [0x410fd034]
1 Like
Im curious to hear more about your (and others) experience using maps and location with the librem5. Which app are you using, PureMaps?
1 Like
It’s on my list to play with more. Right now I don’t have it working though.
Here’s a topic on it posted recently Librem 5 GPS/Location Tracking
1 Like
Reminds me of HF vs VHF. You can get HF depending on the skip zone of the continent you’re on. You can get VHF ground propagation depending on the weather and maybe bouncing off a cloud.
Thanks for sharing. Folks like me who haven’t gotten theirs yet appreciate the real-world usage reports you don’t get from review channels. 
2 Likes
This has been bugging me for a while. Out of the box, I configured my Librem 5 to use the 5 GHz band - but the signal range was not very good e.g. no signal where I had my charger, which was a pain. I could have put in a second WAP but …
Spurred on by your post, I changed my Librem 5 to use the 2.4 GHz band instead. Not only can I now get signal where I have my charger but it looks like time-on-battery has increased too. Not dramatically but enough to be helpful.
4 Likes
Glad you found it helpfull! Yeah I was having that same exact issue. I was using a dell ethernet/power thing so it could be backed up and get updates while charging.
The sad thing is with the Librem 5 is knowing that it’s the first mass produced version, I’m expecting problems that may not be fixed until later hardware versions. Thus things like this are sometimes assumed to be that sort of issue without realizing there is a fix.
The good news is that so far I’ve seen no real examples of that. Yes, there are lots of gaps in the software. (Maybe there’s some weird stuff with USB bus speed. I can live with that.)
(I was using a dock that does not have an ethernet port so was using a USB-to-ethernet dongle plugged in to the dock, which is another solution.)
I can’t see a way to directly specify the frequency on the phone. (At least, not in the GUI.) Do you have your Wi-Fi configured so that it uses a separate SSID / network name for each frequency band?
My Wi-Fi is configured so that the same SSID is used for both 5GHz and 2.4GHz. This works well for my laptop. The Librem 5 does have worse 5GHz reception than my laptop, but the main issue I get is that it takes too long to switch to 2.4GHz when the 5GHz signal strength has decreased, such as when I walk into the living room. I usually find it quicker to go into the settings and manually disconnect and reconnect to the Wi-Fi network, rather than wait for it to go over to 2.4GHz of its own accord. (At least, I presume this is due to the 5GHz signal strength. I never actually checked which frequency it was using.)
Oddly, it is currently sitting about 60cm from the Wi-Fi AP, which is where it was when I last rebooted it, and it’s telling me it’s put itself onto 2.4GHz, even though it should have perfect 5GHz signal here. This is actually great, because it means it won’t have issues switching from 5GHz to 2.4GHz, but I’ve no idea why it’s done it. 
1 Like
My wifi is setup with separate SSIDs for each. Told the librem 5 to connect to the 2.4Ghz one, and it stays on it. I don’t think it will try to switch on it’s own unless it loses signal.
1 Like
Yes, I do. I do that for ease of management so that I can easily know and control what is using what (I have lots of SSIDs and lots of devices).
If you choose to advertise the same SSID on both bands, which is perfectly valid, then I’m sure there would be some way of controlling which band is used on the client side (e.g. at its simplest disable 5 GHz on the client side) but I don’t know what the incantation is. Maybe use nmcli to look at 802-11-wireless.band ?
Adding: If you directly edit the xyz.nmconnection file, you may be able to add band= in the [wifi] section but I don’t know what syntax you need for the value. Also, if you edit such a file, you will either need to reload or reboot.
2 Likes
$ nmcli conn edit <ID>
===| nmcli interactive connection editor |===
Editing existing '802-11-wireless' connection: '<ID>'
Type 'help' or '?' for available commands.
Type 'print' to show all the connection properties.
Type 'describe [<setting>.<prop>]' for detailed property description.
You may edit the following settings: connection, 802-11-wireless (wifi),
802-11-wireless-security (wifi-sec), 802-1x, ethtool, match, ipv4, ipv6, tc,
proxy
nmcli> describe wifi.band
=== [band] ===
[NM property description]
802.11 frequency band of the network. One of "a" for 5GHz 802.11a or "bg" for
2.4GHz 802.11. This will lock associations to the Wi-Fi network to the
specific band, i.e. if "a" is specified, the device will not associate with the
same network in the 2.4GHz band even if the network's settings are compatible.
This setting depends on specific driver capability and may not work with all
drivers.
(I only just figured out nmcli has the ability to describe things in this way.)
1 Like
@patch Out of curiosity, have you now made that setting and does it work? (where “work” means either “does what it says” or “solves your problem” or both)
Just as well I asked about the syntax because that is well um … non-obvious.
For the record, we are only grappling with the opposite situation i.e. same SSID used with each band.
Assuming that you (like me) use different SSIDs on each band, it looks as if you can set a preferred SSID and in my experience it will hold onto that SSID until it actually loses it (rather than jumping around based on highest signal strength) and for this particular problem if you set 2.4 GHz as preferred and you lose 2.4 GHz signal then it is very likely that you have also lost 5 GHz signal (unless you have more than one WAP and your WAPs have different configs) so it would “never” change band.
Back to the subject line but not to anyone in particular. I watch a youtuber by the moniker “Itchy Boots”. She rides her motorcycle through several countries. Currently she is in Botswana, having just left Namibia.
Every time she crosses a border she has to get a new SIM card.
Yes, I made the 802-11-wireless.band setting (bg).
In one test just now, I could not reproduce the problem I had before, but I can’t conclusively prove that that is because of the band setting.
Another way to attack this issue might be to implement 802.11r in the network, perhaps with 802.11k and perhaps with 802.11v, to encourage client devices to switch to stronger signals more readily. (Don’t ask me for details; I know not much more about these standards than you can learn from Wikipedia and your favourite search engine.)
I feel like I’ve derailed the thread a bit here. Sorry about that.
1 Like
If you go into Settings / WiFi then somewhere in there it shows you the band that it is using. That doesn’t prove anything either but, if both bands should have a strong signal i.e. you are right on top of the WAP, it should give you confidence that the setting is working.
Well, not really. As I said yesterday; it was using 2.4GHz when it was right on top of the WAP even before the setting was made. So, it really doesn’t prove anything if it’s on 2.4GHz right now!
Even so, probably worth a try if you find yourself with poor signal in a hotel with the same SSID for 2.4GHz and 5GHz.
That sounds like an interesting travelogue. I’ll take a look.
1 Like