Orange Pi and kernel 4.19.1 (system non responsive after 5am each day)
Slackware - ARMThis forum is for the discussion of Slackware ARM.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Orange Pi and kernel 4.19.1 (system non responsive after 5am each day)
Interesting problem with Orange pi becoming non-responsive after 5am each day.
-It appears to be related to switching up to 4.19 kernel in current.
-Interesting the date seems to have changed as well?
I have so far been power cycling the device
Code:
root@orange:/var/log# head messages
Nov 18 05:21:06 orange syslogd 1.5.1: restart.
Dec 2 02:16:35 orange kernel: [48003.903608] rcu_sched I 0 10 2 0x00000000
Dec 2 02:16:35 orange kernel: [48003.904069] Sending NMI from CPU 0 to CPUs 3:
Second day in a row the system seems unresponsive in the morning.
-attempted access via SSH (no response and interestingly hang ((tommorrow I'll try ssh -v))
-attempt to connect on tty no response
SYSTEM information:
Orange Pi Plus2
Slackware-ARM -current
Code:
root@orange:/var/log# uname -a
Linux orange.xxxxxxxx.org 4.19.1-armv7 #2 SMP Sat Nov 10 21:22:44 GMT 2018 armv7l Allwinner sun8i Family GNU/Linux
root@orange:/var/log# cat /proc/cpuinfo
processor : 0
model name : ARMv7 Processor rev 5 (v7l)
BogoMIPS : 48.00
Features : half thumb fastmult vfp edsp thumbee neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm
CPU implementer : 0x41
CPU architecture: 7
CPU variant : 0x0
CPU part : 0xc07
CPU revision : 5
--As MoZes pointed out in the changelog there seem to be issues with 4.19 on OrangePi.
What is a good log to examine to determine cause?
so far I found the most info in /var/log/messages.
Just looking for some ideas to help determine a better understanding of the cause...
[root@PKBACKUP ~]# cat /etc/default/cpufrequtils
# WARNING: this file will be replaced on board support package (linux-root-...) upgrade
ENABLE=true
MIN_SPEED=480000
MAX_SPEED=1296000
GOVERNOR=ondemand
#GOVERNOR=performance
Thanks for the report. This is the sort of issue I referred to when I was first testing 4.19.
However, since I reverted to the 4.17 Kernel config and upgraded it to 4.19 for the second time, I excluded lots of the new stuff and both of my Orange Pi's are completely stable with this Kernel, and both are being used to build packages.
My Banana Pi on the other hand, has now hung.
In the 4.17 kernel, the default governor was "performance", but perhaps it's changed how it works. I'll rebuild 4.19 with the governor as "demand" as the default and see if it makes any difference. I'll push out those updates ASAP.
The 4.17 kernels will also be placed within /extra for the foreseeable future.
Good plan with /extra. I'll keep plugging on 4.19 to see if I can be helpful maybe uncover something.
... shoot still hung at ~ 05:21 maybe...
(hard to tell for certain here are two consecutive entries in /var/log/messages)
So my ondemand trick did not help.
Code:
Nov 18 05:21:06 orange syslogd 1.5.1: restart.
Dec 2 02:16:35 orange kernel: [48003.903608] rcu_sched I 0 10 2 0x00000000
here is current setting
root@orange:~# cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
ondemand
I'm going to suspend my rdiff-backup script in cron, maybe the heavy ethernet and sata disk writes exacerbates the issue.
(although, a maunal run is ok and does not lock up while I'm watching... I've been using /etc/cron.daily at 4:40 every day for the rdiff-backup)
--I'll suspend anyway keep util low on the orange pi.
--I'll report back at 7am EST to see if this helps the lockup.
----Also think I'm going to cron a simple date command to write to a file to see when exacty the system freezes/changes date
(as regular user)
Code:
rich@orange ~ $ crontab -l
# .---------------- minute (0 - 59)
# | .------------- hour (0 - 23)
# | | .---------- day of month (1 - 31)
# | | | .------- month (1 - 12) OR jan,feb,mar,apr ...
# | | | | .---- day of week (0 - 6) (Sunday=0 or 7) OR 0=sun,1=mon,2=tue,3=wed,4=thu,5=fri,6=sat
# | | | | |
# * * * * * command to be executed
* * * * * /usr/bin/date >> /home/rich/orange_pi_freeze_date.txt
This should leave some breadcrumbs
just upgrading to the new 4.19.2, will see what the morning brings
Last edited by ricky_cardo; 11-20-2018 at 12:03 AM.
Reason: updated to 4.19.2
Nervous now think the headers are there and the actual is not...
--[some time elapsed] luckily packages were here /var/cache/packages/slackware/k (downloaded just not installed)
--kernel booted just missing all modules, so had to correct locally. ((modules were 4.19.2, kernel was still 4.19.1))
all better now back to test to see if locks up.
Last edited by ricky_cardo; 11-20-2018 at 01:27 AM.
Reason: update
You can always boot back into the installer using (the RAM disks are within the linux-4.17/isolinux dir in /extra, and the kernels in a dir of the same name), mount your file system, get access to the new Kernel packages,
Code:
# cd /path/to/newpackages
# ROOT=/path/to/that/fs upgradepkg a/kernel-*z d/kernel-header*z k/kernel-source*z
Or something like that. Then reboot.
This is how I fix stuff like that, if the OS is unstable.
Well the good news so far is It is 8am and still stable. (admittedly too early to tell yet)
Code:
rich@orange ~ $ date ;uptime;uname -a
Tue Nov 20 08:19:12 EST 2018
08:19:12 up 6:00, 1 user, load average: 0.00, 0.01, 0.00
Linux orange.xxxx.no-ip.org 4.19.2-armv7 #2 SMP Mon Nov 19 11:36:50 GMT 2018 armv7l Allwinner sun8i Family GNU/Linux
Last edited by ricky_cardo; 11-20-2018 at 07:23 AM.
Made it through?
--I'll assume for now I need to rebuild
librsync
rdiff-backup
Seems to be stable if I don't schedule a backup. (using the orange-pi as a backup server for couple clients).
--I'm going to rebuild these two slackBuilds, and wait a few days to start them up again. (add rdiff-backup back to cron)
Still locking up consistently on 4.19.4 (with no other tasks running), going to try a fresh reload of current to include updated uboot.
I'm going to try a fresh load of current because One of the packages I have is corrupted... having strange permissions issues, where I can see it is root owned and executable yet I can't execute? (permission denied)
(I think the u-boot may be from 2017) --
--If that still gives trouble I'll just roll back to the kernel in extra.
***
Is there a uboot difference between Orange Pi Plus 2E and Orange Pi Plus 2
I see on the manufacturers site I actually have the Orange Pi Plus 2 and until now was setting up as Orange Pi Plus 2E
To me seems like it is the same as Orange Pi Plus (just with 1 extra gig ram)
UPDATE
OK it is definitely Orange Pi Plus
u-boot displays: Orange Pi Plus / Orange Pi Plus 2
****THINKING THIS IS THE ROOT OF EVIL -- should be better now hoping
Last edited by ricky_cardo; 11-26-2018 at 09:24 PM.
Distribution: Slackware 15 64bit on Desktop Slackwarearm on Raspberry PI v1b
Posts: 381
Rep:
I've been following this thread with some interest as I have an orange pi pc that I intend to put Slackware arm back on once I fill in some rather large and somewhat shocking holes I have in what should probably be basic knowledge. So I wonder if a little gem I discovered quite by accident quite number of years ago would work around this issue until a permanent fix is found.
This has worked so well at keeping my system accurate for me that I do it as a matter of course any more whenever I do a fresh install of Slackware on any my equipment. I create a file in cron.hourly called settime.
As root
Code:
nano /etc/cron.hourly/settime
and insert the following in that file:
Code:
/usr/sbin/ntpdate north-america.pool.ntp.org
if the system has a rtc I add
Code:
&& /sbin/hwclock -w
And then
Code:
chmod +x /etc/cron.hourly/settime
After that
Code:
/etc/cron.hourly/settime
to set the clock the first time.
That && /sbin/hwclock -w won't work with the fake hwclock in the orange pi or raspberry either and I haven't figured out how to make it work with either, so I just leave it off on them, but it does keep the system time accurate as long as it doesn't reboot.
***
Is there a uboot difference between Orange Pi Plus 2E and Orange Pi Plus 2
I see on the manufacturers site I actually have the Orange Pi Plus 2 and until now was setting up as Orange Pi Plus 2E
To me seems like it is the same as Orange Pi Plus (just with 1 extra gig ram)
The version of the Orange Pi is printed on the circuit board.
I use the version of U-Boot that's linked from the Slackware installation documents. I haven't updated it in ages because it works fine on both of mine.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
