After some delay, I finally had a ‘good’ cooling solution for my 8GB Pi4, and resumed testing.. The last Kernel version I had running on it was 5.9-rc4, and everything seemed to be working OK (including 8GB of memory recognised). I then updated to 5.11.18, and found that none of the USB ports worked: # dmesg |grep … Continue reading →
Thanks to mbod, there is a simple kernel patch to restore the Kernel 5.8 ‘inherited taint’ behaviour to Kernel 5.9, and the detail is in this thread: https://forums.developer.nvidia.com/t/opencl-not-working-with-kernel-5-9/156941/6 I have applied this to Kernel 5.9.0, and NVIDIA driver 455.28 now installs and loads/runs OK. Until a proper fix is available, this will – of course – need … Continue reading →
Kernel 5.9-rc6 has been released, and brief details are here: http://lkml.iu.edu/hypermail/linux/kernel/2009.2/05870.html In a very rare occurrence, the kernel compile actually fails: …………………………….. CALL scripts/checksyscalls.sh CALL scripts/atomic/check-atomics.sh DESCEND objtool CHK include/generated/compile.h CC drivers/dax/super.o drivers/dax/super.c:325:6: error: redefinition of ‘dax_supported’ 325 | bool dax_supported(struct dax_device *dax_dev, struct block_device *bdev, | ^~~~~~~~~~~~~ In file included from drivers/dax/super.c:16: ./include/linux/dax.h:162:20: note: previous definition … Continue reading →
I have been testing Fedora 33 pre-release, and on x86_64 it seems relatively stable (usual caveats…) but on arm64 systems (Odroid N2 and Pi4) I found that after compiling a new kernel (5.8.3), the system booted, but login was impossible, and screen output was missing (uart/console was OK). Kernels compiled with Fedora 32 all booted OK, and … Continue reading →
After more testing, it appears that there is still a problem with the Intel e1000e driver and some – but not all – supported NICs.. I have several ex-HP systems that have Intel NICs, and some have more than one. The HP Z820 has two (different models..): $ lspci |grep Eth 00:19.0 Ethernet controller: Intel Corporation 82579LM … Continue reading →
After updating my main HP Z820 system to Kernel 5.4, I found that the previous Intel e1000e Ethernet problem I had encountered on my test system with Kernel 5.4-rc6 seemed to have reappeared. (see http://rglinuxtech.com/?p=2632 ). But – this time, two of my systems with e1000e drivers were OK, but the third – the HP Z820 – … Continue reading →
Testing Fedora 31 – which is still work-in-progress, of course.. Tried to use # rpmbuild –rebuild to create a missing RPM from a F30 source RPM, and found the following error: ………….. Illegal char ‘)’ (0x29) in: Obsoletes:………. I found a reference to this error in the buglist, but it had been flagged as ‘rawhide’, and closed, … Continue reading →
Solved: After more investigation, reinstalling the Xorg driver fixed the problem.. # dnf reinstall xorg-x11-server-Xorg After successfully patching the NVIDIA 410.73 driver (see previous article), I encountered another problem at runtime, after # startx : ………………………………. [ 145.489] (II) Initializing extension GLX [ 145.489] (II) AIGLX: Screen 0 is not DRI2 capable [ 145.489] (EE) AIGLX: reverting … Continue reading →
I just encountered a problem installing the latest NVIDIA driver 410.73 on my ‘Main’ system, having successfully tested it on my ‘Test’ system: …………………… MODPOST 4 modules WARNING: “nv_pmops_suspend” [/home/rgadsdon/kernel/NVIDIA-Linux-x86_64-410.73/kernel/nvidia.ko] undefined! WARNING: “nv_pmops_resume” [/home/rgadsdon/kernel/NVIDIA-Linux-x86_64-410.73/kernel/nvidia.ko] undefined! WARNING: “nv_pmops_thaw” [/home/rgadsdon/kernel/NVIDIA-Linux-x86_64-410.73/kernel/nvidia.ko] undefined! WARNING: “nv_pmops_poweroff” [/home/rgadsdon/kernel/NVIDIA-Linux-x86_64-410.73/kernel/nvidia.ko] undefined! WARNING: “nv_pmops_restore” [/home/rgadsdon/kernel/NVIDIA-Linux-x86_64-410.73/kernel/nvidia.ko] undefined! WARNING: “nv_pmops_freeze” [/home/rgadsdon/kernel/NVIDIA-Linux-x86_64-410.73/kernel/nvidia.ko] undefined! ………………….. It appears that NVIDIA now … Continue reading →
When doing a # dnf system-upgrade reboot on an ARM64 system you may encounter a stream of GPG errors, followed by reboot, without upgrade. To fix this, simply import the F28 GPG key in advance, as done for Rawhide: # rpm –import /etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-28-primary After this, the system-upgrade should proceed correctly.. Robert Gadsdon. July 6, 2018 … Continue reading →