[Khadas WiP] VIM4 NVMe IO Errors

I get ‘Installing needed tools (can’t build cpuminer)’ when I run this.

I had a look at the cpuminer-multi github repository and there seems to be a lot of dependencies mentioned that I can’t install.

I tried to build it manually but it fails spectacularly.

Thank you both. cpuminer isn’t really important since it was all about reading out the various OPP tables and in the meantime I got them: JVnV Pastebin – View paste – Untitled

So supply voltage for all cpufreqs below 1.3 GHz is always the same as such it shouldn’t matter much whether the board idles at 500 MHz or 1 GHz. But if as in @ps23Rick’s case cpufreq governor is really set to performance then in fact the board idles at 2.0/2.2GHz which is just a waste of energy.

Does your installation also output performance twice with this:

cat /sys/devices/system/cpu/cpufreq/policy?/scaling_governor

A better setting would IMO be /etc/default/cpufrequtils containing this:

# WARNING: this file will be replaced on board support package upgrade
ENABLE=true
MIN_SPEED=1000000
MAX_SPEED=2208000
GOVERNOR=ondemand

since then the code snippet inside the fenix-hardware-optimization script would actually work. This would result in lower idle consumption while keeping I/O performance up. But if cpufreq governor is set to performance anyway by a different mechanism/script then of course this all doesn’t matter :slight_smile:

yes, both instances of scaling_governor are performance on mine as well.

The script did complete BTW and there’s some interesting stuff in the log file so thanks for that.

Then there’s some script or startup service adjusting this since kernel config defaults to schedutil. If you call sensors with your board being idle for a while you get with all sensors close to 50°C, right?

Does this change significantly after editing /etc/default/cpufrequtils with the values above, followed by an systemctl restart cpufrequtils, followed by half an hour waiting and then calling sensors again?

And BTW: what do you use for cooling? The usual fansink?

I’ve got the usual fan sink (active cooling?)… it cycles on-n-off periodically even when the machine is idle other than the occasional cron job…

Should I try adjusting that config file/script you mentioned or ? In my case I had the two different settings — one performance and one conservative if I recall. Seems like something might be a little off perhaps if the setting in the file above is not being honored.

I’m using the ‘active cooling’ fansink. The temp hovers around 50 degrees and the fan cycles on-off every minute or so.

I had a look at the rc scripts and found that init.d/cpufrequtils was set to ondemand, 0, 0 but according to /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_governors, the governors available are performance and schedutil.

I changed it to schedutil, 50000, 208000 but it didn’t make any difference because it seems something else is setting it to performance on boot.

I did echo “schedutil” | sudo tee /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
and cat /sys/devices/system/cpu/cpufreq/policy?/scaling_governor
gave me
schedutil
performance

but it didn’t stick.

just discovered that cpufrequtils won’t start because it says the governor is not available no matter what I set it to - I guess it just defaults to performance?

I feel this has gone a long way of topic now - should we start a new thread?

Hello @RIGeek @technodevotee @JeremiahCornelius @deepvim @foxsquirrel

We have some improgress about the NVMe SSD issues, as we don’t have too much SSD models, so we need your help to check the SSDs on your side.

Before testing, you need to follow the steps below to upgrade the kernel.

$ wget https://dl.khadas.com/.test/linux-dtb-amlogic-5.4_1.1.6_arm64.deb
$ wget https://dl.khadas.com/.test/linux-image-amlogic-5.4_1.1.6_arm64.deb
$ sudo dpkg -i linux-dtb-amlogic-5.4_1.1.6_arm64.deb linux-image-amlogic-5.4_1.1.6_arm64.deb
$ sync
$ sudo reboot

After reboot double check the kernel version.

$ uname -a
Linux Khadas 5.4.180 #1.1.6 SMP PREEMPT Mon Oct 10 16:14:32 CST 2022 aarch64 aarch64 aarch64 GNU/Linux
2 Likes

How many merge conflicts have you dismissed while bringing Amlogic’s 5.4.125 up to 5.4.180?

I just did the same test under I did before.

With my Netac N930 Pro plugged into the board, I created an image of the eMMC using dd to it. I copied the image from the NVMe to my NAS and compared the two files.

They were the same, when they were always different before on Ubuntu-Gnome.

I ‘burned’ the image from my NAS to an SD card and can boot from it. That never worked on Ubuntu-Gnome before.

So far, it seems better.

I can try some tests tonight my time here in California and see how things go… I’ve got a spare NVMe drive — one of the Crucial models I can test with.

@tkaiser … If we want to manually review the changes between the versions of the amlogic code-base specific to the VIM 4, does the general public have access to that stuff? Just curious… I’ve got a lot of C/C++ experience over the decades with embedded devices, albeit not w/ Linux but I’d be happy to look over the changes for anything looking odd or not right for some reason. :man_shrugging::thinking:

Sure.

Here is the 5.4.180 Khadas is using: GitHub - khadas/linux at khadas-vims-5.4.y

Here is the real upstream 5.4.217 LTS: https://github.com/gregkh/linux/tree/linux-5.4.y

The process has been explained by Willy over at Radxa forum (who deal with the exact same problem: vendor BSP kernels you can’t trust at all): The radxa bsp kernel patches : from 5.10.67 to 5.10.123 - ROCK 5 Series - Radxa Forum

Great… Thanks @tkaiser !! I’ll probably take peek at some point this week. Much appreciated!

Wow… I just read a little … Seems like there are some very knowledgable people participating there – yourself included obviously… I’m not sure I’m up to speed on things but hoping that perhaps there are some people here aside from a few people that have chimed in already that can help weed through all this stuff… lots to learn! Thanks for the links!

I just installed the new kernel. I just started recompiling the RetroPie package. That should take about 48 hours, if successful. I will report back with my results.

You can check the source code. :wink:

@numbqq

Updated the kernel and it works with the WD 570, no serious testing, just functionality. Your test kernel is configured differently so it did break nftables/UFW so I went back to my custom kernel config. Where is the kernel config file in fenix?

Really? No change to che config.

1 Like

Willy Tarreau maintained 3.10 LTS kernel so he qualifies as ‘official’ kernel hacker. Me not at all, in fact I learned just few weeks ago how shitty the situation with those Android vendor kernels is since I believed for many years Google would require those SoC vendors to rebase all their code on upstream kernel of the version they require for a certain Android version.

But that’s not happening, they just forward port their crappy internal code base since forever, that way hiding every merge conflict that ever happened and as such even with a 5.4 version number the kernel running on any VIM4 is far away from official 5.4 LTS.

How far? You would need to take your time and efforts but it’s easily hundreds of thousands of differences. Anyone trusting into this crap is lost. But since people have no idea that neither SoC vendors nor board vendors give a shit they rely on this kernel even for security relevant stuff.

@foxsquirrel mentioned nftables. So I just checked out net/netfilter/nf_tables_api.c from official 5.4 LTS and from the Amlogic/Khadas mess:

https://www.diffchecker.com/frCrkIrU

That’s just a single file and that is something that has zero relationship to Amlogic adoptions (in such cases it would be understandable that official LTS and vendor kernel differ).

Yes, that is correct. I had to change the “official release” kernel to get nftables and UFW to work.

Thank you for the link.

Tried to post the diff and the file is too large for the forum.