I’d think in some run away proc (for example the browser) which consumes a lot of CPU; use SSH or the terminal app and check with top
.
You might be right. I use Firefox pretty much, usually a couple of windows open. Just now, my phone was very unresponsive so I ssh:ed into it and launched htop to see what was happening. Firefox was at the top of the list, so I killed it and the phone went back to more normal response. After relaunching firefox, phone remainded normal though.
My experience of FF since some years is: don’t leave to much tabs open for a longer time (e.g. over night). Even a modern desktop can get unresponsive or freeze completely. I think that it’s busy with swapping.
My experience with the L5 after some weeks is: shutdown all unused apps when you put the L5 away for longer time (over night or so), esp. browsers and the gnome-gsettings app.
This is almost certainly it. iOS and Android basically turn apps “off” when they are not in active use… especially iOS - so they don’t use power/battery while you are not using. As far as I’m aware there is no mechanism for this on the L5 currently. You will need to adjust your habits to close everything that you don’t need to be running before putting it back in your pocket. Especially something like a browser running some crappy JS code.
So we might rewrite this fact: “Maximum temperature raise at different discharge currents: 1A:+1,2°C, 2A:+3,3°C, 3A:+5,8°C, 5A:+11,3°C, 7A:+16,6°C, 10A:+22,1°C,” based on testing upon Eneloop NiMH AA HR-3UTGB in order to pretend that we are focused onto 1.0A range only (up to 4.0A range?), on what is actual BPP-L503 temperature raise (with/without WiFi on, particular apps open/closed, etc.),
to something like: with 10 FFox open Tabs (because of swapping) might raise your L5 battery (when battery inside of the phone and with display on) temperature to about “+22,1°C”, might (occasionally) add significant temperature to your L5 battery itself and the rest of the phone will be used to cool it down, please reduce number of open FFox Tabs. Just asking, don’t get me wrong (if you can).
In the Ubuntu mobile (BQ E4.5, M10, …) any app which is not on the screen receives the SIGSTOP signal and when it returns to the screen a SIGCONT. You can define exceptions for this, for example for the browser to be able to listen some stream from Internet while reading other stuff in another app.
You could killall -19 firefox
to freeze firefox, and killall -18 firefox
to unfreeze.
Edit: what guru says, did not read this far yet.
Very interesting, works well using firefox-esr
and really freezes the browser and brings it back when needed. Memory usage stays the same though, which should be expected as it saves the state it is in when frozen. If this could happen automatically when switching apps it would be awesome!
although I would not want to have this for all applications. Your music player would stop when backgrounded, your messenger stop to receive messages, ssh connections would time out…
For other, well defined things, that would be a nice way to save CPU cycles indeed (although improving specific apps to use less CPU when idling is a worthwhile goal in itself).
I totally agree with that, but maybe a setting to decide which apps are allowed to freeze in the background.
For, say, email - and I suspect it’s the same with text messages - it is more complicated than that because there are two processes. There is a GUI process that interacts with the user and which could be safely frozen when not the current app and there is a background process that interacts with the remote system in order to get “messages”. The background process can probably manage itself, as it will likely be idle most of the time anyway, either polling infrequently or being event driven by the arrival of a message.
Of course, but the devil is in the details :-). If you freeze “thunderbird” you might as well freeze the service thread which is supposed to run in the background, so it really depends I guess. But I think, in the end we are all on the same page that it would be immensely useful to be able to freeze (or stop) an app at any point in time (for some app and frontend processes)…
This is what Android has actually done well. So well, that it is hard to keep an app running in the background even if you want to.
What does this method precisely do? Does it send specific signals to the process? What happens with the memory? Will the memory swapped to disk? How long would that take on a process like FF with three digits of tabs?
I wonder how FF mobile handles my 4 digits of tabs on my android. Since I am permanently low on storage I see that FF always has to reload a tab. It has to store more than the URL because it also state like the viewport or input like text in text fields. Now that I wrote this I am not sure anymore if that’s always the case. It might be done by the website. This forum e.g. can store drafts of a post.
Yes, SIGSTOP, which basically tells the kernel to not give any time slices to that process until SIGCONT.
It does not automatically swap anything, but when swapping is needed, I think the kernel should prefer swapping pages which were not used for a while.
There is a merge request to fix the issue initially reported in this thread.
I am getting the slow blinking light when trying to charge sometimes and the phone is hot. I noticed what sometimes helps is not only killing unused processes but clearing the memory swap for that program (If this is what usage app does).
This should almost be a automatic function since charging the phone should take priority over all other processes and apps). Maybe with priority:
- phone too hot while charging,
- send that suspend signal to all running processes, except maybe the clock and any timers,
- if process does not suspend kill it,
- for killed process clean swap,
- dim screen,
- if bluetooth is on turn off,
- if wifi is on turn off (keep alive mobile connection if that was on),
- exceptions to the above rules for processes related to streaming video or audio over wifi, bluetooth, usb, lan,
- set all networks connected to metered connection,
- set wifi if still connected to power save mode, is there such a thing for bluetooth?
- finally limit any remaining running processes to 5% CPU.
etc
Well the Librem 5 it is a Hot and Cold phone by design(first in world) because the all terrain Freescale CPU it get hot a lot because the powerful cpu, but at the same time the dedicated-monitor-and-frame-plus-paste get cold the phone fast. Of course the L5 can be more cooler when the free-software got more optimized and adapted.
So if the red light it blink for temperature the phone will get cold by waiting time.
Like’s
Hot to Convergence Mode = Docked
Cold to Personal Mode = Undocked
Most mobile device is designed to block the temp to outside by using a dedicated and closed unlinux cpu plus materials also including the pinephones slightly.
L5 is diferent.
The fake 85C bug seems gone on linux-5.16.18.
On the same topic of a burning phone, I disassembled my Librem 5 to fix something else but did not replace the thermal paste on the CPU. It was hot before, but since the reassemble the metal ring around the side of the phone is burning. I suspect I should attempt another tear down and replace the thermal paste with some top tier paste. Has anyone done this, and if so, was it worthwhile? Thanks!