Orange Pi and kernel 4.19.1 (system non responsive after 5am each day)

ricky_cardo · 11-18-2018, 11:45 AM

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

Code:

screen -T screen-256color /dev/ttyUSB0 115200,-crtscts

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...

ricky_cardo · 11-18-2018, 12:27 PM

Seems like ~05:24 hrtimer interrupt then the system jumps to an invalid date.

syslog says this:

Code:

Nov 16 05:24:37 orange kernel: [80032.557903] hrtimer: interrupt took 986142 ns
Dec  1 03:30:23 orange kernel: [164700.108340] rcu: INFO: rcu_sched self-detected stall on CPU
Dec  1 03:30:23 orange kernel: [164700.108369] rcu: ^I0-...!: (23 ticks this GP) idle=d16/0/0x1 softirq=1130273/1130275 fqs=0 last_accelerate: 7af5/c1bb, nonlazy_posted: 0, L.
Dec  1 03:30:23 orange kernel: [164700.108372] rcu: ^I (t=149298918 jiffies g=3440309 q=26)
Dec  1 03:30:23 orange kernel: [164700.108385] rcu: rcu_sched kthread starved for 149298918 jiffies! g3440309 f0x0 RCU_GP_WAIT_FQS(5) ->state=0x402 ->cpu=3
Dec  1 03:30:23 orange kernel: [164700.108387] rcu: RCU grace-period kthread stack dump:
Dec  1 03:30:23 orange kernel: [164700.108427] [<c08b6c78>] (__schedule) from [<c08b6e10>] (schedule+0x7c/0x98)
Dec  1 03:30:23 orange kernel: [164700.108441] [<c08b6e10>] (schedule) from [<c08ba1ac>] (schedule_timeout+0x2f8/0x380)
Dec  1 03:30:23 orange kernel: [164700.108457] [<c08ba1ac>] (schedule_timeout) from [<c0398150>] (rcu_gp_kthread+0x518/0x8c8)
Dec  1 03:30:23 orange kernel: [164700.108472] [<c0398150>] (rcu_gp_kthread) from [<c03587c0>] (kthread+0x130/0x148)
Dec  1 03:30:23 orange kernel: [164700.108484] [<c03587c0>] (kthread) from [<c03010d8>] (ret_from_fork+0x14/0x3c)
Dec  1 03:30:23 orange kernel: [164700.108489] Exception stack(0xee0f7fb0 to 0xee0f7ff8)
Dec  1 03:30:23 orange kernel: [164700.108495] 7fa0:                                     00000000 00000000 00000000 00000000
Dec  1 03:30:23 orange kernel: [164700.108502] 7fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
Dec  1 03:30:23 orange kernel: [164700.108508] 7fe0: 00000000 00000000 00000000 00000000 00000013 00000000
Dec  1 03:30:23 orange kernel: [164700.108524] NMI backtrace for cpu 0
Dec  1 03:30:23 orange kernel: [164700.108534] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G         C        4.19.1-armv7 #2
Dec  1 03:30:23 orange kernel: [164700.108537] Hardware name: Allwinner sun8i Family
Dec  1 03:30:23 orange kernel: [164700.108553] [<c030fa84>] (unwind_backtrace) from [<c030b27c>] (show_stack+0x10/0x14)
Dec  1 03:30:23 orange kernel: [164700.108565] [<c030b27c>] (show_stack) from [<c08a42b8>] (dump_stack+0x80/0xa0)
Dec  1 03:30:23 orange kernel: [164700.108576] [<c08a42b8>] (dump_stack) from [<c08a95ec>] (nmi_cpu_backtrace+0xa0/0xb8)
Dec  1 03:30:23 orange kernel: [164700.108587] [<c08a95ec>] (nmi_cpu_backtrace) from [<c08a9688>] (nmi_trigger_cpumask_backtrace+0x84/0x114)
Dec  1 03:30:23 orange kernel: [164700.108598] [<c08a9688>] (nmi_trigger_cpumask_backtrace) from [<c039b184>] (rcu_dump_cpu_stacks+0xa0/0xb8)
Dec  1 03:30:23 orange kernel: [164700.108610] [<c039b184>] (rcu_dump_cpu_stacks) from [<c03999d0>] (rcu_check_callbacks+0x2e8/0x704)
Dec  1 03:30:23 orange kernel: [164700.108624] [<c03999d0>] (rcu_check_callbacks) from [<c03a0f90>] (update_process_times+0x30/0x5c)
Dec  1 03:30:23 orange kernel: [164700.108638] [<c03a0f90>] (update_process_times) from [<c03b0ee4>] (tick_sched_handle+0x54/0x60)
Dec  1 03:30:23 orange kernel: [164700.108649] [<c03b0ee4>] (tick_sched_handle) from [<c03b1108>] (tick_sched_timer+0x44/0x94)
Dec  1 03:30:23 orange kernel: [164700.108661] [<c03b1108>] (tick_sched_timer) from [<c03a1e04>] (__hrtimer_run_queues+0x198/0x2dc)
Dec  1 03:30:23 orange kernel: [164700.108673] [<c03a1e04>] (__hrtimer_run_queues) from [<c03a2634>] (hrtimer_interrupt+0x114/0x28c)
Dec  1 03:30:23 orange kernel: [164700.108687] [<c03a2634>] (hrtimer_interrupt) from [<c079e86c>] (arch_timer_handler_phys+0x28/0x30)
Dec  1 03:30:23 orange kernel: [164700.108701] [<c079e86c>] (arch_timer_handler_phys) from [<c038e80c>] (handle_percpu_devid_irq+0xb4/0x224)
Dec  1 03:30:23 orange kernel: [164700.108713] [<c038e80c>] (handle_percpu_devid_irq) from [<c0389db8>] (generic_handle_irq+0x18/0x28)
Dec  1 03:30:23 orange kernel: [164700.108724] [<c0389db8>] (generic_handle_irq) from [<c038a398>] (__handle_domain_irq+0x9c/0xb4)
Dec  1 03:30:23 orange kernel: [164700.108736] [<c038a398>] (__handle_domain_irq) from [<c0592d68>] (gic_handle_irq+0x54/0x80)
Dec  1 03:30:23 orange kernel: [164700.108747] [<c0592d68>] (gic_handle_irq) from [<c03019f8>] (__irq_svc+0x58/0x74)
Dec  1 03:30:23 orange kernel: [164700.108751] Exception stack(0xc0e01f30 to 0xc0e01f78)
Dec  1 03:30:23 orange kernel: [164700.108758] 1f20:                                     00000000 01a3dd14 eefa848c c0317d00
Dec  1 03:30:23 orange kernel: [164700.108766] 1f40: 00000000 ffffe000 00000000 00000001 c0e06238 c0e0627c c0d06a28 00000000
Dec  1 03:30:23 orange kernel: [164700.108774] 1f60: 00000000 c0e01f80 c0308264 c0308254 600f0013 ffffffff
Dec  1 03:30:23 orange kernel: [164700.108786] [<c03019f8>] (__irq_svc) from [<c0308254>] (arch_cpu_idle+0x1c/0x38)
Dec  1 03:30:23 orange kernel: [164700.108800] [<c0308254>] (arch_cpu_idle) from [<c036527c>] (do_idle+0x114/0x238)
Dec  1 03:30:23 orange kernel: [164700.108812] [<c036527c>] (do_idle) from [<c03655dc>] (cpu_startup_entry+0x18/0x1c)
Dec  1 03:30:23 orange kernel: [164700.108825] [<c03655dc>] (cpu_startup_entry) from [<c0c00d4c>] (start_kernel+0x3c0/0x44c)
Dec  1 03:30:23 orange kernel: [164700.109844] NMI backtrace for cpu 1
Dec  1 03:30:23 orange kernel: [164700.109848] CPU: 1 PID: 0 Comm: swapper/1 Tainted: G         C        4.19.1-armv7 #2
Dec  1 03:30:23 orange kernel: [164700.109850] Hardware name: Allwinner sun8i Family
Dec  1 03:30:23 orange kernel: [164700.109852] PC is at arch_cpu_idle+0x1c/0x38
Dec  1 03:30:23 orange kernel: [164700.109854] LR is at arch_cpu_idle+0x2c/0x38
Dec  1 03:30:23 orange kernel: [164700.109856] pc : [<c0308254>]    lr : [<c0308264>]    psr: 60000013
Dec  1 03:30:23 orange kernel: [164700.109858] sp : ee0fdfb8  ip : 00d28bd4  fp : 00000000
Dec  1 03:30:23 orange kernel: [164700.109861] r10: c0d06a28  r9 : c0e0627c  r8 : c0e06238
Dec  1 03:30:23 orange kernel: [164700.109863] r7 : 00000002  r6 : 00000000  r5 : ffffe000  r4 : 00000000
Dec  1 03:30:23 orange kernel: [164700.109866] r3 : c0317d00  r2 : eefb948c  r1 : 013d67a4  r0 : 00000000
Dec  1 03:30:23 orange kernel: [164700.109868] Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment user
Dec  1 03:30:23 orange kernel: [164700.109871] Control: 10c5387d  Table: 49fd806a  DAC: 00000055
Dec  1 03:30:23 orange kernel: [164700.109874] CPU: 1 PID: 0 Comm: swapper/1 Tainted: G         C        4.19.1-armv7 #2
Dec  1 03:30:23 orange kernel: [164700.109876] Hardware name: Allwinner sun8i Family
Dec  1 03:30:23 orange kernel: [164700.109879] [<c030fa84>] (unwind_backtrace) from [<c030b27c>] (show_stack+0x10/0x14)
Dec  1 03:30:23 orange kernel: [164700.109881] [<c030b27c>] (show_stack) from [<c08a42b8>] (dump_stack+0x80/0xa0)
Dec  1 03:30:23 orange kernel: [164700.109884] [<c08a42b8>] (dump_stack) from [<c08a95e4>] (nmi_cpu_backtrace+0x98/0xb8)
Dec  1 03:30:23 orange kernel: [164700.109887] [<c08a95e4>] (nmi_cpu_backtrace) from [<c030e29c>] (handle_IPI+0x210/0x340)
Dec  1 03:30:23 orange kernel: [164700.109890] [<c030e29c>] (handle_IPI) from [<c0592d8c>] (gic_handle_irq+0x78/0x80)
Dec  1 03:30:23 orange kernel: [164700.109893] [<c0592d8c>] (gic_handle_irq) from [<c03019f8>] (__irq_svc+0x58/0x74)
Dec  1 03:30:23 orange kernel: [164700.109895] Exception stack(0xee0fdf68 to 0xee0fdfb0)
Dec  1 03:30:23 orange kernel: [164700.109898] df60:                   00000000 013d67a4 eefb948c c0317d00 00000000 ffffe000
Dec  1 03:30:23 orange kernel: [164700.109901] df80: 00000000 00000002 c0e06238 c0e0627c c0d06a28 00000000 00d28bd4 ee0fdfb8
Dec  1 03:30:23 orange kernel: [164700.109903] dfa0: c0308264 c0308254 60000013 ffffffff
Dec  1 03:30:23 orange kernel: [164700.109906] [<c03019f8>] (__irq_svc) from [<c0308254>] (arch_cpu_idle+0x1c/0x38)
Dec  1 03:30:23 orange kernel: [164700.109908] [<c0308254>] (arch_cpu_idle) from [<c036527c>] (do_idle+0x114/0x238)
Dec  1 03:30:23 orange kernel: [164700.109911] [<c036527c>] (do_idle) from [<c03655dc>] (cpu_startup_entry+0x18/0x1c)
Dec  1 03:30:23 orange kernel: [164700.109914] [<c03655dc>] (cpu_startup_entry) from [<403023cc>] (0x403023cc)
Dec  1 03:43:23 orange kernel: [165480.034732] sun6i-rtc 1f00000.rtc: rtc only supports year in range 1970 - 2033
Dec  1 03:43:31 orange kernel: [165488.034915] sun6i-rtc 1f00000.rtc: rtc only supports year in range 1970 - 2033

ricky_cardo · 11-18-2018, 05:38 PM

Found the following thread here:
on armbian forum:
https://forum.armbian.com/topic/6225...-stall-on-cpu/

Going to try this and report back:

Code:

[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

drmozes · 11-19-2018, 04:30 AM

Hi Ricky

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.

ricky_cardo · 11-19-2018, 09:03 PM

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

ricky_cardo · 11-20-2018, 12:06 AM

going to be slight delay appears to have frozen while upgrade-all was running...
during kernel-source upgrade.

Code:

  --> Deleting /usr/src/linux-4.19.1/drivers/gpu/drm/mga/mga_drv.h
  --> Deleting /usr/src/linux-4.19.1/drivers/gpu/drm/mga/mga_ioc32.c

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.

drmozes · 11-20-2018, 04:37 AM

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.

ricky_cardo · 11-20-2018, 07:18 AM

That's an excellent plan. (I like it)

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

ricky_cardo · 11-21-2018, 09:11 AM

Rats: unresponsive again this am.
going to reboot and check when, the time stamp.

Here is the breadcrumb file I was leaving:

Code:

Wed Nov 21 08:19:01 EST 2018
Wed Nov 21 08:20:01 EST 2018
Mon Dec  5 00:52:05 EST 1977
Mon Dec  5 00:53:01 EST 1977

Here is attempted ssh -v

Code:

rich@lemur ~ $ ssh -v orange
OpenSSH_7.9p1, OpenSSL 1.1.1  11 Sep 2018
debug1: Reading configuration data /home/rich/.ssh/config
debug1: /home/rich/.ssh/config line 1: Applying options for *
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: auto-mux: Trying existing master
debug1: Control socket "/home/rich/.ssh/rich@orange:22" does not exist
debug1: Connecting to orange [192.168.1.210] port 22.
debug1: Connection established.
debug1: identity file /home/rich/.ssh/id_rsa type 0
debug1: identity file /home/rich/.ssh/id_rsa-cert type -1
debug1: identity file /home/rich/.ssh/id_dsa type -1
debug1: identity file /home/rich/.ssh/id_dsa-cert type -1
debug1: identity file /home/rich/.ssh/id_ecdsa type -1
debug1: identity file /home/rich/.ssh/id_ecdsa-cert type -1
debug1: identity file /home/rich/.ssh/id_ed25519 type -1
debug1: identity file /home/rich/.ssh/id_ed25519-cert type -1
debug1: identity file /home/rich/.ssh/id_xmss type -1
debug1: identity file /home/rich/.ssh/id_xmss-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_7.9
debug1: Remote protocol version 2.0, remote software version OpenSSH_7.9
debug1: match: OpenSSH_7.9 pat OpenSSH* compat 0x04000000
debug1: Authenticating to orange:22 as 'rich'
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: curve25519-sha256
debug1: kex: host key algorithm: ecdsa-sha2-nistp256
debug1: kex: server->client cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none
debug1: kex: client->server cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ecdsa-sha2-nistp256 SHA256:Gk1Ie+1ucqWV1ifex8veGyjktura8Yy0TvUsp3BHLuQ
debug1: Host 'orange' is known and matches the ECDSA host key.
debug1: Found key in /home/rich/.ssh/known_hosts:46
debug1: rekey after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: rekey after 134217728 blocks
debug1: pubkey_prepare: ssh_get_authentication_socket: No such file or directory
debug1: Will attempt key: /home/rich/.ssh/id_rsa RSA SHA256:xxxxxxxxxxxxxx//QUCE
debug1: Will attempt key: /home/rich/.ssh/id_dsa 
debug1: Will attempt key: /home/rich/.ssh/id_ecdsa 
debug1: Will attempt key: /home/rich/.ssh/id_ed25519 
debug1: Will attempt key: /home/rich/.ssh/id_xmss 
debug1: SSH2_MSG_EXT_INFO received
debug1: kex_input_ext_info: server-sig-algs=<ssh-ed25519,ssh-rsa,rsa-sha2-256,rsa-sha2-512,ssh-dss,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521>
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug1: Next authentication method: publickey
debug1: Offering public key: /home/rich/.ssh/id_rsa RSA SHA256:xxxxxxxxxxxxx//QUCE
debug1: Server accepts key: /home/rich/.ssh/id_rsa RSA SHA256:xxxxxxxxxxxxxx//QUCE
debug1: Authentication succeeded (publickey).
Authenticated to orange ([192.168.1.210]:22).
debug1: setting up multiplex master socket
debug1: channel 0: new [/home/rich/.ssh/rich@orange:22]
debug1: channel 1: new [client-session]
debug1: Entering interactive session.
debug1: pledge: id
debug1: client_input_global_request: rtype hostkeys-00@openssh.com want_reply 0
debug1: Remote: /home/rich/.ssh/authorized_keys:4: key options: agent-forwarding port-forwarding pty user-rc x11-forwarding
debug1: Remote: /home/rich/.ssh/authorized_keys:4: key options: agent-forwarding port-forwarding pty user-rc x11-forwarding

ricky_cardo · 11-22-2018, 07:48 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)

ricky_cardo · 11-22-2018, 09:16 AM

Interesting now receiving permissions issues when trying to rebuild?

Code:

root@orange:~/SlackBuilds/librsync# ls -la
total 468
drwxr-xr-x  2 root root   4096 Feb 25  2017 ./
drwxr-xr-x 24 root root   4096 May  1  2018 ../
-rw-r--r--  1 root root    355 Feb 25  2017 README
-rw-r--r--  1 root root 453802 Feb 25  2017 librsync-0.9.7.tar.gz
-rwxr-xr-x  1 root root   2138 Feb 25  2017 librsync.SlackBuild*
-rw-r--r--  1 root root    301 Feb 25  2017 librsync.info
-rw-r--r--  1 root root   1016 Feb 25  2017 slack-desc
root@orange:~/SlackBuilds/librsync# sh ./librsync.SlackBuild
...(checks)...
./librsync.SlackBuild: line 63: ./configure: Permission denied

ricky_cardo · 11-26-2018, 08:19 PM

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.

__ I'll report results

ricky_cardo · 11-26-2018, 08:38 PM

***
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

interndan · 11-26-2018, 10:46 PM

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.

drmozes · 11-27-2018, 01:51 AM

Quote:

Originally Posted by ricky_cardo

***
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.