5.35/5.36 bug / questions collection

tkaiser · December 1, 2017

Fine with me.

zador.blood.stained · December 1, 2017

On 12/1/2017 at 11:26 AM, Igor said:

v.5.36 Are we ready to rebuild repository on Sunday ... and update only BSPs and RPI monitor?

Expand

1. Yes, 2. yes, + armbian-config maybe?

8thphloor · 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 · December 1, 2017

'sudo armbianmonitor -u' or it didn't happen...

zador.blood.stained · December 1, 2017

On 12/1/2017 at 6:18 PM, tkaiser said:

'sudo armbianmonitor -u' or it didn't happen...

Expand

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

Igor · December 3, 2017

done. apt-update & upgrade

vlad59 · 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 · 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 · December 3, 2017

Do you have a plan to release for Orange Pi One?

pfeerick · 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 · December 4, 2017

On 12/4/2017 at 2:16 AM, pfeerick said:

and only actually had 1 update waiting.

Expand

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:

On 12/3/2017 at 11:56 PM, Bongho Lee said:

Do you have a plan to release for Orange Pi One?

Expand

There are only experimental 4.13.y builds and yes its planned when ready and tested.

On 12/3/2017 at 7:53 PM, vlad59 said:

and the reboot it seems that my SD card still contain a full armbian filesystem :

Expand

That is completely normal. SD card content is left as is. We only alter boot environment when SD card is needed for booting.

On 12/3/2017 at 5:00 PM, vlad59 said:

I also see kworker using ~8% CPU.

Expand

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.

zador.blood.stained · December 4, 2017

On 12/4/2017 at 5:28 AM, Igor said:

That is completely normal.

Expand

but mount point for /boot is not correct, so we may have a (yet again) nand-sata-install issue

tkaiser · December 4, 2017

On 12/3/2017 at 7:53 PM, 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.
Expand

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 · December 4, 2017

If it's Stretch related, then we are too fast with it even for a server builds.

On 12/4/2017 at 6:45 AM, tkaiser said:

I've no idea what happened to 'team testers'.

Expand

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.

vlad59 · December 4, 2017

On 12/4/2017 at 6:10 AM, zador.blood.stained said:

but mount point for /boot is not correct, so we may have a (yet again) nand-sata-install issue

Expand

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 · 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 · December 4, 2017

On 12/1/2017 at 7: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.

Expand

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 · December 4, 2017

All armbianmonitor thermal read outs are broken on at least pine64/legacy and odroidxu4/next

zador.blood.stained · 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 · 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 · December 4, 2017

On 12/4/2017 at 11:07 PM, Paulo Paiva said:

lost comunication with my 2 temperature sensor (DS18B20 - 1Wire).

Expand

did you check min. cpu speed?

chrisf · December 5, 2017

On 12/4/2017 at 11:07 PM, 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

Expand

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 · December 5, 2017

On 12/4/2017 at 3:23 PM, tkaiser said:

All armbianmonitor thermal read outs are broken on at least pine64/legacy and odroidxu4/next

Expand

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.

BloodElf · 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 · December 5, 2017

On 12/4/2017 at 11:27 PM, chwe said:

did you check min. cpu speed?

Expand

Hi,

the problem was the min. cpu speed...is working now !!!!

tank's

PP

Igor · December 5, 2017

On 12/5/2017 at 9:47 PM, Paulo Paiva said:

the problem was the min. cpu speed...is working now !!!!

Expand

CPU min/max setting is overwriting at each BSP update. Also on next one expected to happen soon.

csteinforth · December 6, 2017

On 11/27/2017 at 11:20 PM, ning said:

fixed by remove /var/cache/apt/updates.number

Expand

Little correction: updates.number is in /var/cache/apt/archives.

bartek · 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 · December 7, 2017

On 12/7/2017 at 7:03 PM, bartek said:

I have got problem with https://www.waveshare.com/wiki/7inch_HDMI_LCD_(C) display in 5.36 (lite).

Expand

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.

Sign In

5.35/5.36 bug / questions collection

Recommended Posts

tkaiser

zador.blood.stained

8thphloor

tkaiser

zador.blood.stained

8thphloor

Igor

vlad59

vlad59

Bongho Lee

pfeerick

Igor

zador.blood.stained

tkaiser

Igor

vlad59

vlad59

vlad59

tkaiser

zador.blood.stained

Paulo Paiva

chwe

chrisf

pfeerick

BloodElf

Paulo Paiva

Igor

csteinforth

bartek

Igor

Forums

My Activity Streams

Download

Store

Important Information