arm March 2019

arm@lists.fedoraproject.org

18 participants
27 discussions

Re: Banana Pi-R1 stabil
by Gerhard Wiesinger 06 Mar '19

06 Mar '19

On 06.03.2019 08:36, Maxime Ripard wrote: > >> Yes, there might at least 2 scenarios: >> >> 1.) Frequency switching itself is the problem > But that code is also the one being used by the BananaPro, which you > reported as stable. Yes, BananaPro is stable (with exactly same configuration as far as I know) .... > >> 2.) lower frequency/voltage operating points are not stable. >> >> For both scenarios: it might be possible that the crash happens on idle CPU, >> high CPU load or just randomly. Therefore just "waiting" might be better >> than 100% CPU utilization.But will test also 100% CPU. >> >> Therefore it would be good to see where the voltages for different >> frequencies for the SoC are defined (to compare). > In the device tree. > >> I'm currently testing 2 different settings on the 2 new Banana Pi R1 with >> newest kernel (see below), so 2 static frequencies: >> >> # Set to specific frequency 144000 (currently testing on Banana Pi R1 #1) >> >> # Set to specific frequency 312000 (currently testing on Banana Pi R1 #2) >> >> If that's fine I'll test also further frequencies (with different loads). > Look, you can come up with whatever program you want for this, but if > I insist on running that cpustress program (for the 4th time now), is > that it's actually good at it and caught all the cpufreq issues we've > seen so far. As I wrote, I run several stress tests also with the program you mention. But test combination require a minimum testing time to get verifiable results. The combinations are: - idle cpu vs. 100% CPU - on demand governor vs. several fixed frequencies. So far stable testing conditions for idle CPU and 100% CPU with command line below and cpuburn-a7 program: # Set to max performance (stable)=> frequency 960000 # Set to specific frequency 144000 (stable) # Set to specific frequency 312000 (stable) TODO list to test with "idle" CPU and 100% CPU: # Set to specific frequency 528000 (next step tested) # Set to specific frequency 720000 (next step tested) # Set to specific frequency 864000 # Set to specific frequency 912000 # Set to ondemand My guess is (but it is just a guess which has to be verified): - stable in all fixed frequencies in idle CPU and 100% CPU condition as well as on demand and 100% CPU - not stable with ondemand and "idle" CPU (so real frequency switching will happen often) > > Feel free to not trust me on this, but I'm not sure how the discussion > can continue if you do. > You missed my point from my previous mail: "But will test also 100% CPU.". See command line below. Ciao, Gerhard Test script: while true; do echo "========================================"; echo -n "CPU_FREQ0: "; cat /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_cur_freq; echo -n "CPU_FREQ1: "; cat /sys/devices/system/cpu/cpu1/cpufreq/cpuinfo_cur_freq; sleep 1; done& ./stress/cpuburn-a7

1 0

Re: Banana Pi-R1 stabil
by Gerhard Wiesinger 05 Mar '19

05 Mar '19

On 05.03.2019 10:28, Maxime Ripard wrote: > On Sat, Mar 02, 2019 at 09:42:08AM +0100, Gerhard Wiesinger wrote: >> On 01.03.2019 10:30, Maxime Ripard wrote: >>> On Thu, Feb 28, 2019 at 08:41:53PM +0100, Gerhard Wiesinger wrote: >>>> On 28.02.2019 10:35, Maxime Ripard wrote: >>>>> On Wed, Feb 27, 2019 at 07:58:14PM +0100, Gerhard Wiesinger wrote: >>>>>> On 27.02.2019 10:20, Maxime Ripard wrote: >>>>>>> On Sun, Feb 24, 2019 at 09:04:57AM +0100, Gerhard Wiesinger wrote: >>>>>>>> Hello, >>>>>>>> >>>>>>>> I've 3 Banana Pi R1, one running with self compiled kernel >>>>>>>> 4.7.4-200.BPiR1.fc24.armv7hl and old Fedora 25 which is VERY STABLE, the 2 >>>>>>>> others are running with Fedora 29 latest, kernel 4.20.10-200.fc29.armv7hl. I >>>>>>>> tried a lot of kernels between of around 4.11 >>>>>>>> (kernel-4.11.10-200.fc25.armv7hl) until 4.20.10 but all had crashes without >>>>>>>> any output on the serial console or kernel panics after a short time of >>>>>>>> period (minutes, hours, max. days) >>>>>>>> >>>>>>>> Latest known working and stable self compiled kernel: kernel >>>>>>>> 4.7.4-200.BPiR1.fc24.armv7hl: >>>>>>>> >>>>>>>> https://www.wiesinger.com/opensource/fedora/kernel/BananaPi-R1/ >>>>>>>> >>>>>>>> With 4.8.x the DSA b53 switch infrastructure has been introduced which >>>>>>>> didn't work (until ca8931948344c485569b04821d1f6bcebccd376b and kernel >>>>>>>> 4.18.x): >>>>>>>> >>>>>>>> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/drive… >>>>>>>> >>>>>>>> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/log/driver… >>>>>>>> >>>>>>>> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/dri… >>>>>>>> >>>>>>>> I has been fixed with kernel 4.18.x: >>>>>>>> >>>>>>>> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/log/driver… >>>>>>>> >>>>>>>> >>>>>>>> So current status is, that kernel crashes regularly, see some samples below. >>>>>>>> It is typically a "Unable to handle kernel paging request at virtual addres" >>>>>>>> >>>>>>>> Another interesting thing: A Banana Pro works well (which has also an >>>>>>>> Allwinner A20 in the same revision) running same Fedora 29 and latest >>>>>>>> kernels (e.g. kernel 4.20.10-200.fc29.armv7hl.). >>>>>>>> >>>>>>>> Since it happens on 2 different devices and with different power supplies >>>>>>>> (all with enough power) and also the same type which works well on the >>>>>>>> working old kernel) a hardware issue is very unlikely. >>>>>>>> >>>>>>>> I guess it has something to do with virtual memory. >>>>>>>> >>>>>>>> Any ideas? >>>>>>>> [47322.960193] Unable to handle kernel paging request at virtual addres 5675d0 >>>>>>> That line is a bit suspicious >>>>>>> >>>>>>> Anyway, cpufreq is known to cause those kind of errors when the >>>>>>> voltage / frequency association is not correct. >>>>>>> >>>>>>> Given the stack trace and that the BananaPro doesn't have cpufreq >>>>>>> enabled, my first guess would be that it's what's happening. Could you >>>>>>> try using the performance governor and see if it's more stable? >>>>>>> >>>>>>> If it is, then using this: >>>>>>> https://github.com/ssvb/cpuburn-arm/blob/master/cpufreq-ljt-stress-test >>>>>>> >>>>>>> will help you find the offending voltage-frequency couple. >>>>>> For me it looks like they have all the same config regarding cpu governor >>>>>> (Banana Pro, old kernel stable one, new kernel unstable ones) >>>>> The Banana Pro doesn't have a regulator set up, so it will only change >>>>> the frequency, not the voltage. >>>>> >>>>>> They all have the ondemand governor set: >>>>>> >>>>>> I set on the 2 unstable "new kernel Banana Pi R1": >>>>>> >>>>>> # Set to max performance >>>>>> echo "performance" > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor >>>>>> echo "performance" > /sys/devices/system/cpu/cpu1/cpufreq/scaling_governor >>>>> What are the results? >>>> Stable since more than around 1,5 days. Normally they have been crashed for >>>> such a long uptime. So it looks that the performance governor fixes it. >>>> >>>> I guess crashes occour because of changing CPU voltage and clock changes and >>>> invalid data (e.g. also invalid RAM contents might be read, register >>>> problems, etc). >>>> >>>> Any ideas how to fix it for ondemand mode, too? >>> Run https://github.com/ssvb/cpuburn-arm/blob/master/cpufreq-ljt-stress-test >>> >>>> But it doesn't explaing that it works with kernel 4.7.4 without any >>>> problems. >>> My best guess would be that cpufreq wasn't enabled at that time, or >>> without voltage scaling. >>> >> Where can I see the voltage scaling parameters? >> >> on DTS I don't see any difference between kernel 4.7.4 and 4.20.10 regarding >> voltage: >> >> dtc -I dtb -O dts -o >> /boot/dtb-4.20.10-200.fc29.armv7hl/sun7i-a20-lamobo-r1.dts >> /boot/dtb-4.20.10-200.fc29.armv7hl/sun7i-a20-lamobo-r1.dtb > This can be also due to configuration being changed, driver support, etc. Where will the voltages for scaling then be set in detail (drivers, etc.)? > >> There is another strange thing (tested with >> kernel-5.0.0-0.rc8.git1.1.fc31.armv7hl, kernel-4.19.8-300.fc29.armv7hl, >> kernel-4.20.13-200.fc29.armv7hl, kernel-4.20.10-200.fc29.armv7hl): >> >> There is ALWAYS high CPU of around 10% in kworker: >> >> PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND >> 18722 root 20 0 0 0 0 I 9.5 0.0 0:47.52 >> [kworker/1:3-events_freezable_power_] >> >> PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND >> 776 root 20 0 0 0 0 I 8.6 0.0 0:02.77 >> [kworker/0:4-events] > The first one looks like it's part of the workqueue code. Any guessed reason for that? > >> Therefore CPU doesn't switch to low frequencies (see below). > You said previously that those crashes were happening when the board > was changing frequency, so I'm confused? For the ondemand setting: due to the high load of kworker, the frequency is not changing often to lower values (but does some time and crashes also regularly) For the performance setting: frequency is fixed (to maximum in the current configuration) and is stable > >> Any ideas? > Run the cpustress program I told you to use already twice. Had no time to try it yet. Will do. See also my comment below regarding idle CPU and high CPU. > >> BTW: Still stable at aboout 2,5days on both devices. So solution IS the >> performance governor. > No, the performance governor prevents any change in frequency. My > guess is that a lower frequency operating point is not working and is > crashing the CPU. > Yes, there might at least 2 scenarios: 1.) Frequency switching itself is the problem 2.) lower frequency/voltage operating points are not stable. For both scenarios: it might be possible that the crash happens on idle CPU, high CPU load or just randomly. Therefore just "waiting" might be better than 100% CPU utilization.But will test also 100% CPU. Therefore it would be good to see where the voltages for different frequencies for the SoC are defined (to compare). I'm currently testing 2 different settings on the 2 new Banana Pi R1 with newest kernel (see below), so 2 static frequencies: # Set to specific frequency 144000 (currently testing on Banana Pi R1 #1) # Set to specific frequency 312000 (currently testing on Banana Pi R1 #2) If that's fine I'll test also further frequencies (with different loads). Thnx. Ciao, Gerhard # Set to max performance (stable) echo "performance" > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor echo "performance" > /sys/devices/system/cpu/cpu1/cpufreq/scaling_governor echo "144000" > /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq echo "960000" > /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq echo "144000" > /sys/devices/system/cpu/cpu1/cpufreq/scaling_min_freq echo "960000" > /sys/devices/system/cpu/cpu1/cpufreq/scaling_max_freq # Set to ondemand (not stable) echo "ondemand" > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor echo "ondemand" > /sys/devices/system/cpu/cpu1/cpufreq/scaling_governor echo "144000" > /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq echo "960000" > /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq echo "144000" > /sys/devices/system/cpu/cpu1/cpufreq/scaling_min_freq echo "960000" > /sys/devices/system/cpu/cpu1/cpufreq/scaling_max_freq # Set to specific frequency 144000 (currently testing on Banana Pi R1 #1) echo "performance" > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor echo "performance" > /sys/devices/system/cpu/cpu1/cpufreq/scaling_governor echo "144000" > /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq echo "144000" > /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq echo "144000" > /sys/devices/system/cpu/cpu1/cpufreq/scaling_min_freq echo "144000" > /sys/devices/system/cpu/cpu1/cpufreq/scaling_max_freq # Set to specific frequency 312000 (currently testing on Banana Pi R1 #2) echo "performance" > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor echo "performance" > /sys/devices/system/cpu/cpu1/cpufreq/scaling_governor echo "312000" > /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq echo "312000" > /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq echo "312000" > /sys/devices/system/cpu/cpu1/cpufreq/scaling_min_freq echo "312000" > /sys/devices/system/cpu/cpu1/cpufreq/scaling_max_freq # Set to specific frequency 528000 (untested) echo "performance" > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor echo "performance" > /sys/devices/system/cpu/cpu1/cpufreq/scaling_governor echo "528000" > /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq echo "528000" > /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq echo "528000" > /sys/devices/system/cpu/cpu1/cpufreq/scaling_min_freq echo "528000" > /sys/devices/system/cpu/cpu1/cpufreq/scaling_max_freq # Set to specific frequency 720000 (untested) echo "performance" > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor echo "performance" > /sys/devices/system/cpu/cpu1/cpufreq/scaling_governor echo "720000" > /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq echo "720000" > /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq echo "720000" > /sys/devices/system/cpu/cpu1/cpufreq/scaling_min_freq echo "720000" > /sys/devices/system/cpu/cpu1/cpufreq/scaling_max_freq # Set to specific frequency 864000 (untested) echo "performance" > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor echo "performance" > /sys/devices/system/cpu/cpu1/cpufreq/scaling_governor echo "864000" > /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq echo "864000" > /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq echo "864000" > /sys/devices/system/cpu/cpu1/cpufreq/scaling_min_freq echo "864000" > /sys/devices/system/cpu/cpu1/cpufreq/scaling_max_freq # Set to specific frequency 912000 (untested) echo "performance" > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor echo "performance" > /sys/devices/system/cpu/cpu1/cpufreq/scaling_governor echo "912000" > /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq echo "912000" > /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq echo "912000" > /sys/devices/system/cpu/cpu1/cpufreq/scaling_min_freq echo "912000" > /sys/devices/system/cpu/cpu1/cpufreq/scaling_max_freq # Set to specific frequency 960000 (untested) echo "performance" > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor echo "performance" > /sys/devices/system/cpu/cpu1/cpufreq/scaling_governor echo "960000" > /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq echo "960000" > /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq echo "960000" > /sys/devices/system/cpu/cpu1/cpufreq/scaling_min_freq echo "960000" > /sys/devices/system/cpu/cpu1/cpufreq/scaling_max_freq

1 0

[Fedocal] Reminder meeting : Fedora ARM & AArch64 status meeting
by pwhalen＠redhat.com 03 Mar '19

03 Mar '19

Dear all, You are kindly invited to the meeting: Fedora ARM & AArch64 status meeting on 2019-03-05 from 15:00:00 to 16:00:00 UTC At fedora-meeting-2(a)irc.freenode.net The meeting will be about: Fedora ARM & AArch64 weekly status meeting. More information available at: [https://fedoraproject.org/wiki/Architectures/ARM](https://fedoraproject.org… Source: https://apps.fedoraproject.org/calendar/meeting/9431/

1 0

Raspberry Pi 3 B+ with Aarch64 image changing IP every half hour
by Jeffrey Walton 02 Mar '19

02 Mar '19

This is kind of unusual. Raspberry Pi 3 B+ with Aarch64 image. My SSH session keeps dying. I've noticed it happens about every half hour. When I log into the physical machine I see the IP address has changed. My DHCP server's default lease time is 60 minutes (max lease 120 minutes). 60 minutes is aggressive and it is intended to scavenge old leases quickly because of of device activity in my lab. Many devices are started up, a test is run, and then shutdown immediately. If I allow them to hang around for days or weeks then I sometimes run out of addresses in the subnet. I'm guessing the RPI is trying to renew at 30 minutes. Looking at DMESG I don't see a renew request; only a message about wlan0: [ 33.641372] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready [ 33.658658] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready [ 33.701586] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready [ 33.776179] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready [ 33.839349] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready [ 34.384878] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready [ 35.183999] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready [ 380.555159] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready [ 696.561166] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready [ 1012.565499] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready [ 1328.575936] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready [ 1644.604460] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready <disconnect around here> The RPI is the only device exhibiting the behavior. Does anyone know how to sidestep the problem? Thanks in advance.

3 6

What repos should be used for RPI3 B+?
by Jeffrey Walton 02 Mar '19

02 Mar '19

Hi Everyone, I need to sort out the dnf problems after a RPI3 B+ install using Fedora-Minimal-armhfp-29-1.2-sda.raw.xz. Searching for DNF and repos is returning hits for tradition Fedora desktops (like https://fedoraproject.org/wiki/Repositories) Would someone please provide the dnf tweaks needed or cat a working conf file and post it here? Thanks in advance.

5 9

Re: Banana Pi-R1 stabil
by Gerhard Wiesinger 02 Mar '19

02 Mar '19

On 01.03.2019 10:30, Maxime Ripard wrote: > On Thu, Feb 28, 2019 at 08:41:53PM +0100, Gerhard Wiesinger wrote: >> On 28.02.2019 10:35, Maxime Ripard wrote: >>> On Wed, Feb 27, 2019 at 07:58:14PM +0100, Gerhard Wiesinger wrote: >>>> On 27.02.2019 10:20, Maxime Ripard wrote: >>>>> On Sun, Feb 24, 2019 at 09:04:57AM +0100, Gerhard Wiesinger wrote: >>>>>> Hello, >>>>>> >>>>>> I've 3 Banana Pi R1, one running with self compiled kernel >>>>>> 4.7.4-200.BPiR1.fc24.armv7hl and old Fedora 25 which is VERY STABLE, the 2 >>>>>> others are running with Fedora 29 latest, kernel 4.20.10-200.fc29.armv7hl. I >>>>>> tried a lot of kernels between of around 4.11 >>>>>> (kernel-4.11.10-200.fc25.armv7hl) until 4.20.10 but all had crashes without >>>>>> any output on the serial console or kernel panics after a short time of >>>>>> period (minutes, hours, max. days) >>>>>> >>>>>> Latest known working and stable self compiled kernel: kernel >>>>>> 4.7.4-200.BPiR1.fc24.armv7hl: >>>>>> >>>>>> https://www.wiesinger.com/opensource/fedora/kernel/BananaPi-R1/ >>>>>> >>>>>> With 4.8.x the DSA b53 switch infrastructure has been introduced which >>>>>> didn't work (until ca8931948344c485569b04821d1f6bcebccd376b and kernel >>>>>> 4.18.x): >>>>>> >>>>>> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/drive… >>>>>> >>>>>> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/log/driver… >>>>>> >>>>>> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/dri… >>>>>> >>>>>> I has been fixed with kernel 4.18.x: >>>>>> >>>>>> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/log/driver… >>>>>> >>>>>> >>>>>> So current status is, that kernel crashes regularly, see some samples below. >>>>>> It is typically a "Unable to handle kernel paging request at virtual addres" >>>>>> >>>>>> Another interesting thing: A Banana Pro works well (which has also an >>>>>> Allwinner A20 in the same revision) running same Fedora 29 and latest >>>>>> kernels (e.g. kernel 4.20.10-200.fc29.armv7hl.). >>>>>> >>>>>> Since it happens on 2 different devices and with different power supplies >>>>>> (all with enough power) and also the same type which works well on the >>>>>> working old kernel) a hardware issue is very unlikely. >>>>>> >>>>>> I guess it has something to do with virtual memory. >>>>>> >>>>>> Any ideas? >>>>>> [47322.960193] Unable to handle kernel paging request at virtual addres 5675d0 >>>>> That line is a bit suspicious >>>>> >>>>> Anyway, cpufreq is known to cause those kind of errors when the >>>>> voltage / frequency association is not correct. >>>>> >>>>> Given the stack trace and that the BananaPro doesn't have cpufreq >>>>> enabled, my first guess would be that it's what's happening. Could you >>>>> try using the performance governor and see if it's more stable? >>>>> >>>>> If it is, then using this: >>>>> https://github.com/ssvb/cpuburn-arm/blob/master/cpufreq-ljt-stress-test >>>>> >>>>> will help you find the offending voltage-frequency couple. >>>> For me it looks like they have all the same config regarding cpu governor >>>> (Banana Pro, old kernel stable one, new kernel unstable ones) >>> The Banana Pro doesn't have a regulator set up, so it will only change >>> the frequency, not the voltage. >>> >>>> They all have the ondemand governor set: >>>> >>>> I set on the 2 unstable "new kernel Banana Pi R1": >>>> >>>> # Set to max performance >>>> echo "performance" > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor >>>> echo "performance" > /sys/devices/system/cpu/cpu1/cpufreq/scaling_governor >>> What are the results? >> Stable since more than around 1,5 days. Normally they have been crashed for >> such a long uptime. So it looks that the performance governor fixes it. >> >> I guess crashes occour because of changing CPU voltage and clock changes and >> invalid data (e.g. also invalid RAM contents might be read, register >> problems, etc). >> >> Any ideas how to fix it for ondemand mode, too? > Run https://github.com/ssvb/cpuburn-arm/blob/master/cpufreq-ljt-stress-test > >> But it doesn't explaing that it works with kernel 4.7.4 without any >> problems. > My best guess would be that cpufreq wasn't enabled at that time, or > without voltage scaling. > Where can I see the voltage scaling parameters? on DTS I don't see any difference between kernel 4.7.4 and 4.20.10 regarding voltage: dtc -I dtb -O dts -o /boot/dtb-4.20.10-200.fc29.armv7hl/sun7i-a20-lamobo-r1.dts /boot/dtb-4.20.10-200.fc29.armv7hl/sun7i-a20-lamobo-r1.dtb There is another strange thing (tested with kernel-5.0.0-0.rc8.git1.1.fc31.armv7hl, kernel-4.19.8-300.fc29.armv7hl, kernel-4.20.13-200.fc29.armv7hl, kernel-4.20.10-200.fc29.armv7hl): There is ALWAYS high CPU of around 10% in kworker: PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 18722 root 20 0 0 0 0 I 9.5 0.0 0:47.52 [kworker/1:3-events_freezable_power_] PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 776 root 20 0 0 0 0 I 8.6 0.0 0:02.77 [kworker/0:4-events] Therefore CPU doesn't switch to low frequencies (see below). Any ideas? BTW: Still stable at aboout 2,5days on both devices. So solution IS the performance governor. Ciao, Gerhard ================================================================================================================================================================ # monitor frequency while true; do echo "========================================"; echo -n "CPU_FREQ0: "; cat /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_cur_freq; echo -n "CPU_FREQ1: "; cat /sys/devices/system/cpu/cpu1/cpufreq/cpuinfo_cur_freq; sleep 1; done ================================================================================================================================================================ # Kernel 4.7.4: ======================================== CPU_FREQ0: 144000 CPU_FREQ1: 144000 ======================================== CPU_FREQ0: 144000 CPU_FREQ1: 144000 ======================================== CPU_FREQ0: 144000 CPU_FREQ1: 144000 ======================================== # Kernel 4.20.10 ======================================== CPU_FREQ0: 864000 CPU_FREQ1: 720000 ======================================== CPU_FREQ0: 960000 CPU_FREQ1: 960000 ======================================== CPU_FREQ0: 960000 CPU_FREQ1: 960000 ======================================== CPU_FREQ0: 144000 CPU_FREQ1: 144000 ======================================== CPU_FREQ0: 720000 CPU_FREQ1: 960000 ======================================== CPU_FREQ0: 960000 CPU_FREQ1: 864000 ======================================== CPU_FREQ0: 720000 CPU_FREQ1: 864000 ======================================== CPU_FREQ0: 528000 CPU_FREQ1: 864000

1 0

Fedora-Minimal-armhfp-29-1.2-sda.raw.xz install
by Jeffrey Walton 01 Mar '19

01 Mar '19

Hi Everyone, Good job on the Fedora ARM images. The Fedora-Minimal-armhfp-29-1.2-sda.raw.xz ISO installed flawlessly on a Raspberry Pi 3 B+. The web page at https://fedoraproject.org/wiki/Architectures/ARM/Raspberry_Pi was especially helpful because it provided all the information I needed. I noticed the machine did not prompt me for a hostname on first boot. Changing the hostname would be helpful during configuration after first boot. I wanted to install or configure OpenSSH for remote access. I looked for the ip address using ifconfig but the utility is missing. It would probably be helpful if OpenSSH had a mini-wizard and/or ifconfig was present. I also noticed dnf does not work after an install. After logging in locally as root and running 'dnf update': Error: Failed to synchronize cache for repo 'fedora' That means I can't install Emacs to make configuration changes, or developer tools like GCC, Git, GDB, Make, Autoconf, Automake, etc. I also have not been able to install openssh-server. I think it would be helpful if the image included: 1) Emacs to make configuration changes 2) ifconfig to view network configuration 3) OpenSSH server enabled with a default password 4) Well configured DNF to install and update software Jeff

3 2

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

arm March 2019