5.35/5.36 bug / questions collection


tkaiser

Recommended Posts

Donate and support the project!

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

Link to post
Share on other sites

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

 

 

Link to post
Share on other sites

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

 

Link to post
Share on other sites

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 

 

image.png.ac63aa59356792b677117c02af0d8ae5.png

Link to post
Share on other sites

 

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

 

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.

Link to post
Share on other sites
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'.

Link to post
Share on other sites

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.

Link to post
Share on other sites
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.

Link to post
Share on other sites

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

Link to post
Share on other sites
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) ?

Link to post
Share on other sites
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.

 

Link to post
Share on other sites
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.

 

Link to post
Share on other sites

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!

Link to post
Share on other sites

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

 

Link to post
Share on other sites
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.

Link to post
Share on other sites
Guest
This topic is now closed to further replies.