zador.blood.stained Posted December 1, 2017 Posted December 1, 2017 1 hour ago, Igor said: v.5.36 Are we ready to rebuild repository on Sunday ... and update only BSPs and RPI monitor? 1. Yes, 2. yes, + armbian-config maybe?
8thphloor Posted December 1, 2017 Posted December 1, 2017 hi. I want to share with you an issue encountered with my cubietruck (a20) with latest kernel (5.35 4.13.16) I have kworker who eats 15/20% of my CPU even after reboot. with 4.11.6 5.31 everything is fine. kworkers stays below 0.x % I tried perf monitoring but not able to find culprit. any hint? it's on my side or is a common issue? thanks for all your effort ale
tkaiser Posted December 1, 2017 Author Posted December 1, 2017 'sudo armbianmonitor -u' or it didn't happen...
zador.blood.stained Posted December 1, 2017 Posted December 1, 2017 7 minutes ago, tkaiser said: 'sudo armbianmonitor -u' or it didn't happen... I'm seeing a kworker (or rather different kworkers) eating 7-10% of CPU time on cubietruck sunxi-next 4.14 According to some quick debugging this is related to the thermal sensor polling.
8thphloor Posted December 1, 2017 Posted December 1, 2017 definitely I had some thermal sensor related voices in my perf report. sorry for poor debugging but I had to revert back asap to 5.31 because at home my cubietruck needs to stay healthy and online 24/7 1
vlad59 Posted December 3, 2017 Posted December 3, 2017 I just installed again from scratch one of my banana pi with Armbian_5.35_Bananapi_Debian_stretch_next_4.13.16.img, I've done an apt update && upgrade (initrd was updated) a few minutes ago, rebooted and I also see kworker using ~8% CPU. Is there something more to do with a Banana Pi ? I'm copying to SATA for now but I'll be happy to test after it's finished. SATA copy is finished : http://sprunge.us/dbSd
vlad59 Posted December 3, 2017 Posted December 3, 2017 Me again, Please tell me if you prefer that I open a topic for each issue. I found another strange thing : I used armbian-config to use my SSD and after the full copy and the reboot it seems that my SD card still contain a full armbian filesystem : root@minus:~/src/dtc# mount | grep "/boot" /dev/mmcblk0p1 on /boot type ext4 (rw,noatime,nodiratime,errors=remount-ro,commit=600) root@minus:~/src/dtc# ls /boot/ bin boot dev etc home lib lost+found media mnt opt proc root run sbin selinux srv sys tmp usr var on my other devices /boot only contain the real /boot file. It also causes problem with armbian-add-overlay for example because /boot/armbianEnv.txt is not found (it's under /boot/boot/armbianEnv.txt).
Bongho Lee Posted December 3, 2017 Posted December 3, 2017 Do you have a plan to release for Orange Pi One?
pfeerick Posted December 4, 2017 Posted December 4, 2017 Did the /etc/cron.d/armbian-updates permission issue get fixed (I'm guessing not... I just updated to 5.36 whilst I was writing this and it's back)? I was getting the insecure mode journal entries also on a just updated from 5.31 -> 5.35. Orange Pi Zero. Dec 04 12:02:01 orangepizero-1 cron[521]: (*system*armbian-updates) INSECURE MODE (group/other writable) (/etc/cron.d/armbian-updates) Dec 04 12:03:01 orangepizero-1 cron[521]: (*system*armbian-updates) INSECURE MODE (group/other writable) (/etc/cron.d/armbian-updates) As with the earlier report, the permissions for /etc/cron.d/armbian-updates were: -rw-rw-r-- 1 root root 83 Nov 21 21:14 armbian-updates And sudo chmod 644 /etc/cron.d/armbian-updates shut it up. Dec 04 12:04:01 orangepizero-1 cron[521]: (*system*armbian-updates) RELOAD (/etc/cron.d/armbian-updates) Until then, unsurprisingly, the update count on the welcome banner was stuck at: [ 0 security updates available, 41 updates total: apt upgrade ] Last check: 2017-12-03 00:00 even though the system had just been updated and rebooted, and only actually had 1 update waiting. btw, 5.36 still has a 'user-built' kernel :-P
Igor Posted December 4, 2017 Posted December 4, 2017 2 hours ago, pfeerick said: and only actually had 1 update waiting. At least that is correct Only BSP package was updated and at least most non-cosmetic problems were fixed ... Well, we need yet another mini updated. 5 hours ago, Bongho Lee said: Do you have a plan to release for Orange Pi One? There are only experimental 4.13.y builds and yes its planned when ready and tested. 9 hours ago, vlad59 said: and the reboot it seems that my SD card still contain a full armbian filesystem : That is completely normal. SD card content is left as is. We only alter boot environment when SD card is needed for booting. 12 hours ago, vlad59 said: I also see kworker using ~8% CPU. We only fixed bugs inboard support package scripts. There were no kernel updates and this problem need to be investigated. It's nothing critical so you can normally use the board. 1
zador.blood.stained Posted December 4, 2017 Posted December 4, 2017 41 minutes ago, Igor said: That is completely normal. but mount point for /boot is not correct, so we may have a (yet again) nand-sata-install issue
tkaiser Posted December 4, 2017 Author Posted December 4, 2017 10 hours ago, vlad59 said: I used armbian-config to use my SSD and after the full copy and the reboot it seems that my SD card still contain a full armbian filesystem : root@minus:~/src/dtc# mount | grep "/boot" /dev/mmcblk0p1 on /boot type ext4 (rw,noatime,nodiratime,errors=remount-ro,commit=600) root@minus:~/src/dtc# ls /boot/ bin boot dev etc home lib lost+found media mnt opt proc root run sbin selinux srv sys tmp usr var on my other devices /boot only contain the real /boot file. There should be no /boot fstab entry at all so there's something wrong here witch Stretch. I asked a while back whether other devs are testing this but got zero answers. A nand-sata-install related thread has been trashed in the past and I've no idea what happened to 'team testers'.
Igor Posted December 4, 2017 Posted December 4, 2017 If it's Stretch related, then we are too fast with it even for a server builds. 18 minutes ago, tkaiser said: I've no idea what happened to 'team testers'. Somebody has to take the lead and I left this task to @Tido and things are not running smoothly yet. Also because of breaking releases into two parts. We did quick testing on critical stuff and the team testing part was left for 4.14.y update. This was kind of compromise and give some time to prepare: the vital job description of "team tester leader" is to ping people from time to time, otherwise, they just don't react on "you have been assigned to the task of testing this and that. My emails are up to 3 weeks behind and I can't possibly cover more one2one communication. Eiter we help @Tido to get this up and running or come up with a better plan. 1
vlad59 Posted December 4, 2017 Posted December 4, 2017 1 hour ago, zador.blood.stained said: but mount point for /boot is not correct, so we may have a (yet again) nand-sata-install issue Yes, especially as armbianEnv.txt is expected to be found in /boot/armbianEnv.txt not /boot/boot/armbianEnv.txt https://github.com/armbian/build/blob/master/packages/bsp/common/usr/sbin/armbian-add-overlay#L31 Reading @tkaiser answer, I can umount /boot but it still feel strange as if I want to use DT Overlays, they still have to be read from SD card (loaded from uboot directly) so the /boot from my SATA drive won't be used.
vlad59 Posted December 4, 2017 Posted December 4, 2017 Changing fstab to this may solve the problem : root@minus:~# cat /etc/fstab # <file system> <mount point> <type> <options> <dump> <pass> tmpfs /tmp tmpfs defaults,nosuid 0 0 /var/swap none swap sw 0 0 UUID=f33f7df6-250e-499d-80fc-a8fd4441081e /media/mmcboot ext4 defaults,noatime,nodiratime,commit=600,errors=remount-ro 0 1 /media/mmcboot/boot /boot none bind 0 0 UUID=4240532a-38e9-4e3f-8a3d-3d3e814a38de / ext4 defaults,noatime,nodiratime,commit=600,errors=remount-ro 0 1 notice the /media/mmcboot/boot
vlad59 Posted December 4, 2017 Posted December 4, 2017 On 01/12/2017 at 8:01 PM, zador.blood.stained said: I'm seeing a kworker (or rather different kworkers) eating 7-10% of CPU time on cubietruck sunxi-next 4.14 According to some quick debugging this is related to the thermal sensor polling. I'm not sure , I debugged a little and I got this (worker 4425 is the one using 10% CPU) : kworker/0:1-4425 [000] dns. 15926.716039: workqueue_queue_work: work struct=bfa71244 function=gc_worker [nf_conntrack] workqueue=ef004900 req_cpu=4 cpu=0 kworker/0:1-4425 [000] d.s. 15927.836116: workqueue_queue_work: work struct=bfa71244 function=gc_worker [nf_conntrack] workqueue=ef004900 req_cpu=4 cpu=0 kworker/0:1-4425 [000] d.s. 15928.956207: workqueue_queue_work: work struct=bfa71244 function=gc_worker [nf_conntrack] workqueue=ef004900 req_cpu=4 cpu=0 kworker/0:1-4425 [000] d.s. 15930.076285: workqueue_queue_work: work struct=bfa71244 function=gc_worker [nf_conntrack] workqueue=ef004900 req_cpu=4 cpu=0 kworker/0:1-4425 [000] d.s. 15931.196364: workqueue_queue_work: work struct=bfa71244 function=gc_worker [nf_conntrack] workqueue=ef004900 req_cpu=4 cpu=0 kworker/0:1-4425 [000] d.s. 15931.256369: workqueue_queue_work: work struct=c0d1bc84 function=vmstat_shepherd workqueue=ef004500 req_cpu=4 cpu=0 kworker/0:1-4425 [000] d.s. 15932.316456: workqueue_queue_work: work struct=bfa71244 function=gc_worker [nf_conntrack] workqueue=ef004900 req_cpu=4 cpu=0 kworker/0:1-4425 [000] d.s. 15933.436530: workqueue_queue_work: work struct=bfa71244 function=gc_worker [nf_conntrack] workqueue=ef004900 req_cpu=4 cpu=0 kworker/0:1-4425 [000] d.s. 15934.556614: workqueue_queue_work: work struct=bfa71244 function=gc_worker [nf_conntrack] workqueue=ef004900 req_cpu=4 cpu=0 kworker/0:1-4425 [000] d.H. 15935.666723: workqueue_queue_work: work struct=ee4abe38 function=dbs_work_handler workqueue=ef004500 req_cpu=0 cpu=0 kworker/0:1-4425 [000] d.s. 15935.676705: workqueue_queue_work: work struct=bfa71244 function=gc_worker [nf_conntrack] workqueue=ef004900 req_cpu=4 cpu=0 kworker/0:1-4425 [000] d.s. 15936.796780: workqueue_queue_work: work struct=bfa71244 function=gc_worker [nf_conntrack] workqueue=ef004900 req_cpu=4 cpu=0 kworker/0:1-4425 [000] d.s. 15937.916862: workqueue_queue_work: work struct=bfa71244 function=gc_worker [nf_conntrack] workqueue=ef004900 req_cpu=4 cpu=0 kworker/0:1-4425 [000] d... 15938.257014: workqueue_queue_work: work struct=ef6bcd24 function=vmstat_update workqueue=ef0cfd00 req_cpu=0 cpu=0 kworker/0:1-4425 [000] d.s. 15939.036960: workqueue_queue_work: work struct=bfa71244 function=gc_worker [nf_conntrack] workqueue=ef004900 req_cpu=4 cpu=0 kworker/0:1-4425 [000] d.s. 15940.157029: workqueue_queue_work: work struct=bfa71244 function=gc_worker [nf_conntrack] workqueue=ef004900 req_cpu=4 cpu=0 kworker/0:1-4425 [000] d.s. 15940.217039: workqueue_queue_work: work struct=c0d1bc84 function=vmstat_shepherd workqueue=ef004500 req_cpu=4 cpu=0 kworker/0:1-4425 [000] d... 15940.237242: workqueue_queue_work: work struct=ef6cdd24 function=vmstat_update workqueue=ef0cfd00 req_cpu=1 cpu=1 kworker/0:1-4425 [000] d.s. 15941.277113: workqueue_queue_work: work struct=bfa71244 function=gc_worker [nf_conntrack] workqueue=ef004900 req_cpu=4 cpu=0 kworker/0:1-4425 [000] d... 15941.357319: workqueue_queue_work: work struct=ef6bcd24 function=vmstat_update workqueue=ef0cfd00 req_cpu=0 cpu=0 kworker/0:1-4425 [000] d.s. 15942.397206: workqueue_queue_work: work struct=bfa71244 function=gc_worker [nf_conntrack] workqueue=ef004900 req_cpu=4 cpu=0 kworker/0:1-4425 [000] dns. 15943.517309: workqueue_queue_work: work struct=bfa71244 function=gc_worker [nf_conntrack] workqueue=ef004900 req_cpu=4 cpu=0 kworker/0:1-4425 [000] d... 15944.247437: workqueue_queue_work: work struct=ef6cdd24 function=vmstat_update workqueue=ef0cfd00 req_cpu=1 cpu=1 kworker/0:1-4425 [000] d.s. 15944.637363: workqueue_queue_work: work struct=bfa71244 function=gc_worker [nf_conntrack] workqueue=ef004900 req_cpu=4 cpu=0 kworker/0:1-4425 [000] d... 15945.367559: workqueue_queue_work: work struct=ef6cdd24 function=vmstat_update workqueue=ef0cfd00 req_cpu=1 cpu=1 kworker/0:1-4425 [000] d.H. 15945.747474: workqueue_queue_work: work struct=ee4abe38 function=dbs_work_handler workqueue=ef004500 req_cpu=0 cpu=0 kworker/0:1-4425 [000] d.s. 15945.757456: workqueue_queue_work: work struct=bfa71244 function=gc_worker [nf_conntrack] workqueue=ef004900 req_cpu=4 cpu=0 kworker/0:1-4425 [000] d... 15946.227594: workqueue_queue_work: work struct=ef6bcd24 function=vmstat_update workqueue=ef0cfd00 req_cpu=0 cpu=0 kworker/0:1-4425 [000] d.s. 15946.877526: workqueue_queue_work: work struct=bfa71244 function=gc_worker [nf_conntrack] workqueue=ef004900 req_cpu=4 cpu=0 kworker/0:1-4425 [000] d... 15947.257684: workqueue_queue_work: work struct=ef6cdd24 function=vmstat_update workqueue=ef0cfd00 req_cpu=1 cpu=1 kworker/0:1-4425 [000] d.s. 15947.997610: workqueue_queue_work: work struct=bfa71244 function=gc_worker [nf_conntrack] workqueue=ef004900 req_cpu=4 cpu=0 Can it be network related (conntrack) ?
tkaiser Posted December 4, 2017 Author Posted December 4, 2017 All armbianmonitor thermal read outs are broken on at least pine64/legacy and odroidxu4/next 1
zador.blood.stained Posted December 4, 2017 Posted December 4, 2017 Since 5.36 is still marked as "user-built" and we may have to fix nand-sata-install and armbianmonitor we may have to release another BSP update in several days.
Paulo Paiva Posted December 4, 2017 Posted December 4, 2017 Hello, after the upgrade form 5.35 to 5.36, my Orange Pi 0 H2+ lost comunication with my 2 temperature sensor (DS18B20 - 1Wire). Can anyone help me with this issu? Sincerely, Paulo Paiva
chwe Posted December 4, 2017 Posted December 4, 2017 19 minutes ago, Paulo Paiva said: lost comunication with my 2 temperature sensor (DS18B20 - 1Wire). did you check min. cpu speed?
chrisf Posted December 5, 2017 Posted December 5, 2017 1 hour ago, Paulo Paiva said: Hello, after the upgrade form 5.35 to 5.36, my Orange Pi 0 H2+ lost comunication with my 2 temperature sensor (DS18B20 - 1Wire). Can anyone help me with this issu? Sincerely, Paulo Paiva I found if you want reliable 1wire communication, you need hardware. Especially when your computer is doing much more than idling. It's a time based protocol and a context switch or frequency scaling can easily cause it to fail. I use one of these: https://www.maximintegrated.com/en/products/interface/controllers-expanders/DS2482-100.html i2c is much more reliable and with the help of the i2c hardware every SoC has, it's also much easier on the CPU.
pfeerick Posted December 5, 2017 Posted December 5, 2017 11 hours ago, tkaiser said: All armbianmonitor thermal read outs are broken on at least pine64/legacy and odroidxu4/next Confirmed on my Orange Pi Zero w/ 5.36/legacy. After some digging, the extra [ ! -z "${SocTemp##*[!0-9]*}" ] on https://github.com/armbian/build/blob/master/packages/bsp/common/usr/bin/armbianmonitor#L346 that Igor added to make Soc readings more resilient with badly behaved kernels is the culprit. I've added an issue for it, and some explanation as to what broke. 1
BloodElf Posted December 5, 2017 Posted December 5, 2017 After upgrading from 5.31 or 5.30 to 5.36, i no longer get image through HDMI. I can connect through SSH, but i get no output to HDMI. This happens in OrangePI PC+. I have 3 boards and i get same issue on all 3 of them. Is there a way of avoiding upgrading to 5.36? Sorry, im new to armbian. Any help will be appreciated. Thanks!
Paulo Paiva Posted December 5, 2017 Posted December 5, 2017 22 hours ago, chwe said: did you check min. cpu speed? Hi, the problem was the min. cpu speed...is working now !!!! tank's PP
Igor Posted December 5, 2017 Posted December 5, 2017 16 minutes ago, Paulo Paiva said: the problem was the min. cpu speed...is working now !!!! CPU min/max setting is overwriting at each BSP update. Also on next one expected to happen soon.
csteinforth Posted December 6, 2017 Posted December 6, 2017 On 28.11.2017 at 12:20 AM, ning said: fixed by remove /var/cache/apt/updates.number Little correction: updates.number is in /var/cache/apt/archives.
bartek Posted December 7, 2017 Posted December 7, 2017 Hi. I have got problem with https://www.waveshare.com/wiki/7inch_HDMI_LCD_(C) display in 5.36 (lite). in 5.31 version it worked (after some changes in script.fex). Now i only see pink screen - nothing else. here are settings, that are good in 5.31: [disp_init] disp_init_enable = 1 disp_mode = 0 screen0_output_type = 3 screen0_output_mode = 5 screen1_output_type = 3 screen1_output_mode = 5 fb0_width = 1024 fb0_height = 600 fb1_width = 1024 fb1_height = 600 [hdmi_para] hdmi_used = 1 hdmi_x = 1024 hdmi_y = 600 hdmi_power = "vcc-hdmi-18" hdmi_cts_compatibility = 1 also added in /boot/armbianEnv.txt following: disp_mode="EDID:1280x720p60" disp_mem_reserves=on to be similar as in 5.31 But when i start with connected another monitor and then re-plug waveshare, then i see everything thanks
Igor Posted December 7, 2017 Posted December 7, 2017 24 minutes ago, bartek said: I have got problem with https://www.waveshare.com/wiki/7inch_HDMI_LCD_(C) display in 5.36 (lite). We don't support 3rd party hardware. Not possible. If this problem was caused by an upgrade, you need to find why and possible provide a fix for it. It's most likely a banal reason since there were not many changes to the old legacy kernel. Note that script.bin is overwritten on each upgrade. If you use custom, save it on different name and link to your script.bin to prevent from overwriting.
Recommended Posts