Dietpi version is the current one, V139 | NanoPi Neo (armv7l)
After rebooting and looking at dmesg there is a continuous stream of twi_start()434 - [i2c0] START can’t sendout! messages. I haven’t enabled i2c in the config file or anything like that.
I also am unable to find any services linked to twi_start(). But I think for now, it can safely be ignored. Doesn’t appear to effect the operation of the system, and messages are only produced during boot phase (at least for me).
Had a look at the link you posted. They don’t seem to identify twi_start()434 - [i2c0] START can’t sendout! as a problem. They don’t seem to have the continuous stream that I am having.
After the NEO boots there are no messages sent to dmesg for about 13 sec. and then the i2c0 errors come at a steady stream and fill it
[ 13.755719] EXT4-fs (mmcblk0p2): re-mounted. Opts: discard
[ 15.685435] systemd-journald[171]: Received request to flush runtime journal from PID 1
[ 16.142052] gmac0: probed
[ 16.142494] gmac0 gmac0: eth0: eth0: PHY ID 00441400 at 0 IRQ poll (gmac0-0:00)
[ 17.347868] Adding 102396k swap on /var/swap. Priority:-1 extents:3 across:233468k SS
[ 20.140241] PHY: gmac0-0:00 - Link is Up - 100/Full
[ 26.400038] eth0: no IPv6 routers present <<<<<<<<<<<<<<< break of about 13 sec before i2c0 start
[ 39.341215] twi_start()434 - [i2c0] START can’t sendout!
[ 39.341497] twi_start()434 - [i2c0] START can’t sendout!
[ 39.341769] twi_start()434 - [i2c0] START can’t sendout!
[ 39.356914] twi_start()434 - [i2c0] START can’t sendout!
[ 39.357206] twi_start()434 - [i2c0] START can’t sendout!
[ 39.357487] twi_start()434 - [i2c0] START can’t sendout!
and so on every ms or so.
I think that this is using up a certain amount of CPU time. On-demand and interactive don’t slow the processor down when at idle. The processor speed stays up around 1 GHz. Only conservative allows the processor to run at 240 MHz at idle. Idle is with a ssh conection and Netdata.
Comparing a rp3 with NanoPi Neo both with at idle with only ssh and netdata running (continious update mode) and both with conservative governor.
NanoPi runs at 240 MHz and is about 20% busy
rpi3 runs at 600 MHz and is about 6% busy.
My assumption is that the CPUs are well matched on a clock speed basis. Therefore the rpi3 which runs at 600 MHz at idle should have a lower load than the NanoPi at 240 Mhz, which it does. But if you scale the rpi results 6% busy * 600/240 = 15 % busy based on clock speed. Nanopi runs 20% busy so is the extra work due to the i2c errors being sent to dmesg log?
Looking at the netdata measurements for CPU usage. The nice CPU time scales like the the clock ratios so that seems reasonable.
The system CPU times are:
NanoPi 12%
rpi3 3%
so instead of being 600/240 =2.5 times different they are 4 times different.
I installed the Armbian images and noticed a couple of things.
They didn’t suffer from the same stream of i2c errors. There was a bit in dmesg during boot then it stopped.
The boot speed of Armbian was much faster around 12 sec vs 20 sec for dietpi
The Armbian images are newer by about a month, if I understand that correctly.
As a further note the dietpi image was WAY smaller and WAY easier to set up. So Thanks.
There are some issues with running both ethernet and wifi dongle with Nanopi. I haven’t been able to get the wifi started. I hoped the same /etc/network/interfaces file that I use on the rpi3 could also be used on the nanopi, but something is not right. Either it does not associate with the AP or the interface is missing.
Yep, ARMbian is constantly releasing updates and improvements daily. But these only take effect when the image is built, which we need to do manually each time, then convert to DietPi.
We do revisit existing images and update the ones for the “problem” devices, but overall we are roughly a month behind ARMbian.
I didn’t check if this error occurs on our 4.9 kernel test image. So, if you get a chance, please check this also.
So Thanks.