ARM64 design defines features long before there is a CPU that can implement those features. Since the ARM ecosystem is so varied, there are many different CPU designs out there with different capabilities. A general purpose linux Kernel build put out by a major distribution has to work across a wide array of chips by a large nuymber of vendors. Thus, there is an enumeration of the capabilities inside the Kernel and mechnism for describing how to probe each of these capabilities.
Continue readingMonthly Archives: August 2022
Finding Linux Kernel Config options in menuconfig
We have reason to believe that we should not be setting CONFIG_EFI_DISABLE_RUNTIME=y In our Kernel configs. I want to perform a controlled expereient booting two Kernel builds, one with this option set and one with it disabled. Since I have the option set, building that Kernel is trivial.
make olddefconfig make -j$(nproc) rpm-pkg |
Now, to turn that option off, I could just edit the .config file. However, it is possible that there are other config options linked to that one, and there is logic to modify them together. I want to see what happens if I use make menuconfig to change the option to confirm (or deny) that only that option gets changed. But where do I find this option in the menu?
Continue readingFunctional Fixedness
Today I was reminded how easy it is to get fixed in your thinking.
The short lessons learned: if the Hostname fails (due to SSL) try the IP address.
Longer story:
Continue readingBuilding and Running the Linux Kernel Selftests on AARCH64/ Fedora
I won’t go into checking out or building the Kernel, as that is covered elsewhere. Assuming you have a buildable Kernel, you can build the tests with:
make -C tools/testing/selftests |
But you are probably going to see errors like this:
ksm_tests.c:7:10: fatal error: numa.h: No such file or directory 7 | #include <numa.h> | ^~~~~~~~ compilation terminated. |
The userland test suites use several libraries and need headers to compile the tests that call those libraries. Here is the yum, line I ran to get the dependencies I needed for my system:
sudo yum install libmnl-devel fuse-devel numactl-devel libcap-ng-devel alsa-lib-devel |
With those installed, the make line succeeded.
Running the test like this CRASHED THE SYSTEM. Don’t do this.
make -C tools/testing/selftests run_tests |
A more sensible test to run is the example on the Docs page:
# make -C tools/testing/selftests TARGETS=ptrace run_tests make: Entering directory '/root/linux/tools/testing/selftests' make --no-builtin-rules ARCH=arm64 -C ../../.. headers_install make[1]: Entering directory '/root/linux' INSTALL ./usr/include make[1]: Leaving directory '/root/linux' make[1]: Entering directory '/root/linux/tools/testing/selftests/ptrace' make[1]: Nothing to be done for 'all'. make[1]: Leaving directory '/root/linux/tools/testing/selftests/ptrace' make[1]: Entering directory '/root/linux/tools/testing/selftests/ptrace' TAP version 13 1..3 # selftests: ptrace: get_syscall_info # TAP version 13 # 1..1 # # Starting 1 tests from 1 test cases. # # RUN global.get_syscall_info ... # # OK global.get_syscall_info # ok 1 global.get_syscall_info # # PASSED: 1 / 1 tests passed. # # Totals: pass:1 fail:0 xfail:0 xpass:0 skip:0 error:0 ok 1 selftests: ptrace: get_syscall_info # selftests: ptrace: peeksiginfo # PASS ok 2 selftests: ptrace: peeksiginfo # selftests: ptrace: vmaccess # TAP version 13 # 1..2 # # Starting 2 tests from 1 test cases. # # RUN global.vmaccess ... # # OK global.vmaccess # ok 1 global.vmaccess # # RUN global.attach ... # # attach: Test terminated by timeout # # FAIL global.attach # not ok 2 global.attach # # FAILED: 1 / 2 tests passed. # # Totals: pass:1 fail:1 xfail:0 xpass:0 skip:0 error:0 not ok 3 selftests: ptrace: vmaccess # exit=1 make[1]: Leaving directory '/root/linux/tools/testing/selftests/ptrace' make: Leaving directory '/root/linux/tools/testing/selftests' |
Next up is to write my own stub test.