Bernie_O

Thanks for the quick reply

I want to downgrade the kernel because auf random freezes on my Banana Pi and was following this tutorial to downgrade to Mainline stable kernel (Armbian 5.31): At apt.armbian.com I can find all required packages except for: linux-firmware-image-next-sunxi According to the linked thread I need this package otherwise the system may not start anymore. Could someone tell me where to find that package? Thanks :-)

I switched to Kernel 4.19.57 on my Banana Pi M1 and can confirm that kworker eats 15-20% cpu constantly. Could get rid of it with: modprobe -r sun4i_gpadc sun4i_gpadc_iio With that I also lost thermal monitoring. However I found another source for thermal measurement calculated with: ( (in_temp_raw + in_temp_offset) / 10 ): /sys/bus/iio/devices/iio:device0/in_temp_raw /sys/bus/iio/devices/iio:device0/in_temp_offset /sys/bus/iio/devices/iio:device0/in_temp_scale While the scale seems to be wrong (it is only 10, not 100), it is a quite similar measurement like the one which only works with the 2 gpadc modules enabled: /sys/devices/virtual/thermal/thermal_zone0/temp However, I have absolutely no idea where this temperature comes from. Does anyone know where that measurement comes from? Could it be used as an alternative to the thermal monitoring with the gpadc modules?

Have a look at line 119: https://github.com/armbian/build/blob/master/config/templates/customize-image.sh.template#L119

cd /path/to/mountpoint/folder iozone -e -I -a -s 100M -r 1k -r 2k -r 4k -r 16k -r 128k -r 512k -r 1024k -r 16384k -i 0 -i 1 -i 2

I used this command to mount with write caching disabled: mount_exfat -o nodev,nosuid,noowners,noasync /dev/disk2s1 testmount still similar output (see attached file "storage-report"). Grml... I then did a very basic sequential test of writing 5GB to get a rough idea of sequential speed with: sh-3.2# time sh -c "dd if=/dev/zero of=testfile bs=100k count=50k && sync" 51200+0 records in 51200+0 records out 5242880000 bytes transferred in 61.054574 secs (85872027 bytes/sec) real 1m2.059s user 0m0.114s sys 0m2.953s So the sequential write speed seems kind of realistic to me (5.242,880000 / 62,059sec = 84,482Mbytes/second) The same command takes on the intenal SSD only 4,7 seconds real time. Wow! But I still don't have any clue why the iozone tests give such unrealistic results on the SD card... Attached file: storage-report.txt

I was also really surprised by the numbers. In the Terminal I navigated to a folder on the SD card and then issued the command. In a testing run I could see that there are temporary files created and deleted in that folder. So to me it looks like it was running on the SD Card. I have no idea how to switch caching off on Mac OS. Is there anything else I can do to prove that the test is running on the SD Card? The Card is plugged into the internal SD Card Reader of my MacBook Pro 11,4 (15 inch, mid 2015). EDIT: I‘ll try this, when I get back home after work today: https://superuser.com/questions/113019/is-it-possible-to-disable-write-caching-on-a-usb-mass-storage-device-on-mac-os-x#115640

I saw that you tested a SanDisk Extreme Pro 64GB - A2 card with ext4 and didn't get the expected results (https://github.com/ThomasKaiser/Knowledge/blob/master/articles/A1_and_A2_rated_SD_cards.md) I tested my SanDisk Extreme Pro A2 256GB micro with A2 logo (bought beginning of October 2018), formatted ExFAT under MacOS 10.14 (iozone installed via homebrew). I thought this might be interesting for you: Test 1: random random bkwd record stride kB reclen write rewrite read reread read write read rewrite read fwrite frewrite fread freread 102400 1 71735 74819 750573 769362 416685 61419 102400 2 72975 74808 1324810 1342211 787443 65213 102400 4 74887 76056 2067185 2154206 1440308 67627 102400 16 75828 76580 3978854 3807129 3004696 70542 102400 128 70181 75891 5519047 5797444 4493592 70074 102400 512 76834 76954 5866896 5991461 5061787 71180 102400 1024 79300 79602 5903994 4940446 5571237 72008 102400 16384 82960 82502 6244310 5044075 6105069 75332 Test 2: random random bkwd record stride kB reclen write rewrite read reread read write read rewrite read fwrite frewrite fread freread 102400 1 72111 74632 706436 714325 388037 60997 102400 2 75580 74301 1283544 1363348 783629 64232 102400 4 76621 75244 2168159 2201398 1419623 66416 102400 16 76340 77138 4087649 3789092 3370748 69204 102400 128 75380 75991 5518693 4827877 5774217 71572 102400 512 63009 77769 5990458 5759273 5894918 66458 102400 1024 73595 68298 5961108 5981698 6634301 62683 102400 16384 72310 72862 5990121 6236754 6470780 68542 Test 3: random random bkwd record stride kB reclen write rewrite read reread read write read rewrite read fwrite frewrite fread freread 102400 1 72706 72637 767523 787172 422875 61073 102400 2 73304 73348 1330300 1374293 800613 64702 102400 4 72564 74550 2140561 2198186 1445840 67664 102400 16 72701 76324 4004190 3749432 3430462 69190 102400 128 74825 76603 5780123 5851070 4953780 70198 102400 512 76477 76923 5890148 5900993 5225541 71628 102400 1024 77942 80417 5930079 5984115 5487737 72037 102400 16384 82740 82455 5965766 5569606 6449524 74115

No, I didn't run into any problems (not even non-severe ones). I did everything in a differen order though: - I changed /etc/apt/sources.list to point to Debian stretch repositories - apt-get update && apt-get dist-upgrade - then I did reboot the system - after couple of days I noticed that I maybe should also upgrade the armbian related packages and posted my questions above - I proceeded like pointed out above with upgrading stretch- (and purging jessie-) armbian related packages That was it. System is running nicely thanks to the good work the armbian people do!

Well... At least I did not. Upgraded two Banana Pis without any issues.

If you are using mainline kernel this might help:

Installed 5.38 (mainline) on two Banana Pi. Both have /boot on SD and system (Debian Stretch) on SATA. Both up and running after a reboot (required to activate kernel 4.14.15). No problems so far. I can confirm ~10% CPU load by kworker though. Thanks for Armbian and keep up the good work! EDIT: Sorry, that was misleading: I did not do a fresh install from an image. Both Banana Pi were upgraded from Armbian 5.36

Now that you wrote that, I also remember, that it took quite a while for the „freeze“ to disappear. So all you have to do is being patient ;-)

I also had this problem after updating to 5.36. I then noticed a permission error in /var/log/syslog. Once I corrected the permissions of the appropriate path/file the welcome-screen did not „hang“ anymore with old information. Unfortunately I can‘t remember which path or file I had to change the permissions, but it was clear when I saw the error in syslog. Hope that helps at least for that „hanging“-with-old-information issue.

Thank you. I am on NEXT kernel already (4.13.16). Can I do that on a running system just like this: apt-get update apt-get purge linux-jessie-root-next-bananpi apt-get install linux-stretch-root-next-bananapi Edit: is there a reboot required after doing this? I noticed that on your kernel page the proper naming for board support packages for next kernel is missing: https://www.armbian.com/kernel/