My #pinephone UBPorts edition running #mobian likes to #timetravel: The date jumps ahead to year 2115 after a while.
Each time a jump to the future is initiated it is acompanied by messages of the type 'rcu: INFO: rcu_sched self-detected stall on CPU'.
The return to my timeline can only be initiated by rebooting.
I started playing with timing for RAM and got so far the imagination that the interval from reboot to timetravel got longer with lower settings.
Yeah, new highscore. My #PinePhone running (unused) for more than 187000 seconds since last reboot with the correct clock.
When I logged in on serial console I observed that the moment of login the #camera is clicking and there are dmesgs about #ov5640 loading #firmware.
Shouldn't this happen after reboot automatically and not just after the first login (however it is triggered at that moment)?
The phone is over-exhausting itself:
It took a long rest from #timetravel and stayed with me for more than 328000 seconds and then leapt into the far unknown year 2203 for the first time.
It seems to get help by journald which is in preparation stopped and started a few times.
I'll get it back by rebooting and look what it's got to tell.
Meanwhile I didn't find the information whether a #mobian update after the major changes is save again for my #pinephone.
O.k., updated #mobian on my #pinephone the first time since 2020-10-31 using
apt-get update; apt-get upgrade
apt-get update; apt-get dist-upgrade
apt autoremove
apt-get purge linux-image-5.7-pinephone linux-image-5.8-sunxi64
reboot
Here's the result (the first reboot hung, after switching it off and on again):
root@mobian:~# uname -a
Linux mobian 5.9-sunxi64 #3 SMP PREEMPT Tue Nov 3 16:24:16 UTC 2020 aarch64 GNU/Linux
I guess it worked. Apps I'm using work also.
Hey @mobian - GREAT WORK!
Only downside: After first boot #mobian and #pinephone already fled to future year 2116 after staying only ~5270 seconds with me.
The ability to #timetravel improved greatly.
That might be because of the new u-boot which probably reset my lower clocked ram to the standard value.
@devrtz, what do you think?
I really look forward to my new mainboard. I can't wait to try it and compare the stability to the older one...
Today arrived the new #mainboard for my #pinephone.
This means that my old mainboard these days will start its #timetravel back in my time forward to my history.
I'm curious whether the new board will behave different and maybe the problems with the clock will be gone.
BTW - the transport (standard) from @PINE64 to Germany took eight days. The parcel arrived by Deutsche Post and not by DHL. I didn't have to pay any fees or taxes.
Just in case somebody read the toot and didn't marvel over the little screenshot:
YES, THAT is the screenshot of an ssh session on my PHONE.
It becomes more and more usual and normal to see that, but it can't be emphasized enough ;-).
I even couldn't imagine this when I ordered my #Librem5 and later the #Pinephone. I knew they would run Linux, but I couldn't imagine how it would be using a Linux phone.
@chrichri @mobian @PINE64
Ah, the infamous timetraveling pinephone! :)
I'm afraid that I don't have a lot of insight in this regard.
I have a BH and UBports CE and from what I've seen my BH almost never travelled into 2115 (maybe once since I own it), while the other one does it more frequently.
So I wish you the best of luck with your new mainboard ;)
Rebooted my #pinephone running #mobian after some updates today.
Uptime 330232 seconds without any glitch or clock error.
But why is the screen going on and off all the time while the phone lies on my desk?
Wonder whether that stops after the updates and the reboots.
Otherwise I'll look into the system dbus messages I saw at the same time the screen went on and off again (no, didn't push any button, just watched the serial console ;-) ).
@mobian @PINE64
Exchanged the mainboard and restored the image of the #mobian I already used on my old 2GB RAM / 16 GB eMMC mainboard.
So far no #timetravel. It looks like the mainboard of my #pinephone UBPorts edition had a hardware issue.
With the old board it ran for a few days without problems already, once, but the clock usually jumped within 24h.
If the error does not return thereby confirming the suspected hardware problem, is there interest to look further into the problem, @PINE64?