NVIDIA – 396.54 Patched for Kernel 4.19-rc1 – OK for Some?

Thanks to Tomas Pruzina for more info on this problem…    I have now tested NVIDIA 396.54 – patched with the changes mentioned in my previous article – and it runs OK on my system (Fedora 28, KDE/Plasma).    I created a patched runtime version of the installer, and then (as root) installed it as usual:

# ./NVIDIA-Linux-x86_64-396.54-419.run -s --install-libglvnd --glvnd-glx-client

As mentioned in Tomas’ comments, it has been reported that some systems are showing a ‘black screen’ with this patched-driver/kernel combination, so this may not be a solution for everyone…

Robert Gadsdon   August 29, 2018.

Kernel – 4.19-rc1 – OK with VMware, breaks NVIDIA – and Possible Fix..

Kernel 4.19-rc1 has been released, and very brief details of changes are here: http://lkml.iu.edu/hypermail/linux/kernel/1808.3/01014.html

VMware 14.1.3 compiles/loads OK, but NVIDIA (396.54) compile failed:

......................
/home/rgadsdon/kernel/NVIDIA-Linux-x86_64-396.54/kernel/nvidia-drm/nvidia-drm-encoder.c:219:11: error: implicit declaration of function ‘drm_mode_connector_attach_encoder’; did you mean ‘drm_connector_attach_encoder’? [-Werror=implicit-function-declaration]
ret = drm_mode_connector_attach_encoder(connector, encoder);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
drm_connector_attach_encoder
cc1: some warnings being treated as errors
....................

– and a similar error with nvidia-drm-connector.c

Changing occurrences of ‘drm_mode_connector_attach_encoder’ to ‘drm_connector_attach_encoder’ and ‘drm_mode_connector_update_edid_property’ to ‘drm_connector_update_edid_property’ enabled the driver to compile/load OK, but this has not been further tested, yet:

........................
ld -r -o /home/rgadsdon/kernel/NVIDIA-Linux-x86_64-396.54/kernel/nvidia-modeset/nv-modeset-interface.o /home/rgadsdon/kernel/NVIDIA-Linux-x86_64-396.54/kernel/nvidia-modeset/nvidia-modeset-linux.o
Building modules, stage 2.
MODPOST 4 modules
CC /home/rgadsdon/kernel/NVIDIA-Linux-x86_64-396.54/kernel/nvidia-drm.mod.o
LD [M] /home/rgadsdon/kernel/NVIDIA-Linux-x86_64-396.54/kernel/nvidia-drm.ko
CC /home/rgadsdon/kernel/NVIDIA-Linux-x86_64-396.54/kernel/nvidia-modeset.mod.o
LD [M] /home/rgadsdon/kernel/NVIDIA-Linux-x86_64-396.54/kernel/nvidia-modeset.ko
CC /home/rgadsdon/kernel/NVIDIA-Linux-x86_64-396.54/kernel/nvidia-uvm.mod.o
LD [M] /home/rgadsdon/kernel/NVIDIA-Linux-x86_64-396.54/kernel/nvidia-uvm.ko
CC /home/rgadsdon/kernel/NVIDIA-Linux-x86_64-396.54/kernel/nvidia.mod.o
LD [M] /home/rgadsdon/kernel/NVIDIA-Linux-x86_64-396.54/kernel/nvidia.ko
make[2]: Leaving directory '/usr/src/linux-4.19-rc1'
make[1]: Leaving directory '/usr/src/linux-4.19-rc1'

I also found that this was a problem for the DisplayLink 4.2 driver, as well..

Robert Gadsdon,  August 27, 2018.

VMware – 14.1.3 Released – OK with Kernel 4.18..

VMware 14.1.3 has been released, and details (not very informative..) are here:  https://docs.vmware.com/en/VMware-Workstation-Pro/14/rn/workstation-1413-release-notes.html

Although it is not mentioned, this version does work OK with Kernel 4.18 without any patches (tested with 4.18.3)

Robert Gadsdon.   August 19, 2018

Kernel – 4.18 Finally Released – OK with latest NVIDIA, and Patched VMware

Kernel 4.18 has finally arrived, and details of changes since -rc8 are here:  http://lkml.iu.edu/hypermail/linux/kernel/1808.1/02806.html

As expected, after changes in -rc7, the latest NVIDIA and (patched) VMware all compile/load OK..    Tested with VMware 14.1.2 with the vmmon patch, and NVIDIA 390.77 and 396.51.

Coincidentally, I can also confirm that 4.18 boots OK on HP PA-RISC (HP9000/785-C3700) – but more on that, in a later article..

# uname -a
Linux rgparisc 4.18.0 #1 Sun Aug 12 15:06:04 PDT 2018 parisc64 GNU/Linux

Robert Gadsdon.   August 12, 2018.

PA-RISC – Back to the Future (Again..)

As part of my quest to test Linux on more obscure/historical hardware, and given that the theme was ‘HP’ after my perilous foray into the world of Linux on IA64, I have now acquired (eBay!) an ‘inexpensive’ PA-RISC system – HP 9000/785 C3700 – after upgrading from an older C3000, and adding some more up-to-date IO cards..

HP C3700

The system shows its age, by only having 10/100 (DEC!) Ethernet built-in, and USB1.1 connectors for just a mouse and keyboard, and has mixed PCI/PCIX card slots – and a floppy drive!.   Fortunately, there are inexpensive HP PCIX Gigabit Ethernet cards available, and I installed one of these (NC7771), together with a ‘proper’ USB2 card (Belkin). I also beefed up the memory to 4GB, but this may well have been overkill, as I later discovered…

There are two Distros available for PA-RISC, and after my struggles with Gentoo on the IA64 system, I decided (from over 20 years with Red Hat / Fedora!) on the lesser-of-two-evils, and installed Debian. The ‘standard’ Debian release was quite ancient – with a 3.16 Kernel – but fortunately there is an up-to-date ‘development’ version available, with Kernel 4.17 etc…    This may be ‘interesting’ for my IA64 project as well, as it appears that Debian have started to produce a similarly up-to-date version for IA64 as well, after many years!

My goal for this project, as usual, is to be able to use this as another more ‘interesting’ testing platform for the latest kernel versions, for the least expense!

More on my tribulations with the actual Linux installation, and configuration, in a later article…

Robert Gadsdon. August 8, 2018.

NVIDIA – GPL Problem with Kernel 4.18, But only for Some.. Fixed in 4.18-rc7.

Thanks to towo, for pointing out that some others have had GPL issues with the latest NVIDIA drivers and Kernel 4.18-rc6, even though they compiled/loaded OK on my test system, as reported in an earlier article..

……………
ld -r -o /home/rgadsdon/kernel/NVIDIA-Linux-x86_64-390.77/kernel/nvidia-modeset/nv-modeset-interface.o /home/rgadsdon/kernel/NVIDIA-Linux-x86_64-390.77/kernel/nvidia-modeset/nvidia-modeset-linux.o
Building modules, stage 2.
MODPOST 4 modules
CC /home/rgadsdon/kernel/NVIDIA-Linux-x86_64-390.77/kernel/nvidia-drm.mod.o
LD [M] /home/rgadsdon/kernel/NVIDIA-Linux-x86_64-390.77/kernel/nvidia-drm.ko
CC /home/rgadsdon/kernel/NVIDIA-Linux-x86_64-390.77/kernel/nvidia-modeset.mod.o
LD [M] /home/rgadsdon/kernel/NVIDIA-Linux-x86_64-390.77/kernel/nvidia-modeset.ko
CC /home/rgadsdon/kernel/NVIDIA-Linux-x86_64-390.77/kernel/nvidia-uvm.mod.o
LD [M] /home/rgadsdon/kernel/NVIDIA-Linux-x86_64-390.77/kernel/nvidia-uvm.ko
CC /home/rgadsdon/kernel/NVIDIA-Linux-x86_64-390.77/kernel/nvidia.mod.o
LD [M] /home/rgadsdon/kernel/NVIDIA-Linux-x86_64-390.77/kernel/nvidia.ko
make[2]: Leaving directory ‘/usr/src/linux-4.18-rc6’
make[1]: Leaving directory ‘/usr/src/linux-4.18-rc6’

See https://devtalk.nvidia.com/default/topic/1037642/linux/driver-390-77-not-compiling-in-kernel-4-18-rc5-xubuntu-18-04/ and other reports..

I changed my usual system-specific kernel config in 4.18-rc6 to the ‘Distro’ (Fedora) version, with almost-everything-selected, and was then able to reproduce the problem:

........
Building modules, stage 2.
MODPOST 4 modules
FATAL: modpost: GPL-incompatible module nvidia.ko uses GPL-only symbol '__put_devmap_managed_page'
make[3]: *** [/usr/src/linux-4.18-rc6/scripts/Makefile.modpost:92: __modpost] Error 1
make[2]: *** [/usr/src/linux-4.18-rc6/Makefile:1504: modules] Error 2
make[2]: Leaving directory '/usr/src/linux-4.18-rc6'
make[1]: *** [Makefile:146: sub-make] Error 2
make[1]: Leaving directory '/usr/src/linux-4.18-rc6'
make: *** [Makefile:79: modules] Error 2

I have checked on the offending code, in linux-4.18-rc6/kernel/memremap.c, and compared with the same file in 4.18-rc7:

4.18-rc6:
# grep EXPORT_SYMBOL memremap.c
EXPORT_SYMBOL(device_private_entry_fault);
EXPORT_SYMBOL(devm_memremap_pages);
EXPORT_SYMBOL_GPL(get_dev_pagemap);
EXPORT_SYMBOL_GPL(devmap_managed_key);
EXPORT_SYMBOL_GPL(dev_pagemap_get_ops);
EXPORT_SYMBOL_GPL(dev_pagemap_put_ops);
EXPORT_SYMBOL_GPL(__put_devmap_managed_page);

4.18-rc7:
# grep EXPORT_SYMBOL memremap.c
EXPORT_SYMBOL(device_private_entry_fault);
EXPORT_SYMBOL(devm_memremap_pages);
EXPORT_SYMBOL_GPL(get_dev_pagemap);
EXPORT_SYMBOL(devmap_managed_key);
EXPORT_SYMBOL_GPL(dev_pagemap_get_ops);
EXPORT_SYMBOL_GPL(dev_pagemap_put_ops);
EXPORT_SYMBOL(__put_devmap_managed_page);

So.. It would appear that the problem has been fixed in 4.18-rc7 (tested with the full ‘Distro’ kernel config):

 .................
Building modules, stage 2.
MODPOST 4 modules
CC /home/rgadsdon/kernel/NVIDIA-Linux-x86_64-390.77/kernel/nvidia-drm.mod.o
LD [M] /home/rgadsdon/kernel/NVIDIA-Linux-x86_64-390.77/kernel/nvidia-drm.ko
CC /home/rgadsdon/kernel/NVIDIA-Linux-x86_64-390.77/kernel/nvidia-modeset.mod.o
LD [M] /home/rgadsdon/kernel/NVIDIA-Linux-x86_64-390.77/kernel/nvidia-modeset.ko
CC /home/rgadsdon/kernel/NVIDIA-Linux-x86_64-390.77/kernel/nvidia-uvm.mod.o
LD [M] /home/rgadsdon/kernel/NVIDIA-Linux-x86_64-390.77/kernel/nvidia-uvm.ko
CC /home/rgadsdon/kernel/NVIDIA-Linux-x86_64-390.77/kernel/nvidia.mod.o
LD [M] /home/rgadsdon/kernel/NVIDIA-Linux-x86_64-390.77/kernel/nvidia.ko
make[2]: Leaving directory '/usr/src/linux-4.18-rc7'
make[1]: Leaving directory '/usr/src/linux-4.18-rc7'

I should mention that using the full ‘Distro’ kernel config is not ideal for my test system, as it causes a load of ACPI and other errors at boot time, and is only for a ‘generic X86_64’…  A better solution – at least for compile-time testing – would probably be to use a VMware Fedora VM..

Robert Gadsdon.  August 1, 2018

Kernel – 4.18-rc6 – OK with Latest NVIDIA, and Patched VMware..

Kernel 4.18-rc6 has been released, and details of changes since -rc5 are here:  http://lkml.iu.edu/hypermail/linux/kernel/1807.2/06572.html

The latest NVIDIA drivers ( 390.77 and 396.45 ) compile/load OK, as does vmmon-patched VMware 14.1.2 (see http://rglinuxtech.com/?p=2322 ).

Robert Gadsdon.  July 22. 2018.

NVIDIA – New Driver 390.77 – OK with Kernel 4.18..

NVIDIA have released driver 390.77, and details are here:  http://www.nvidia.com/Download/driverResults.aspx/136120/en-us

I have tested this with Kernel 4.18-rc5, and it compiles/loads successfully:

......................................
ld -r -o /home/rgadsdon/kernel/NVIDIA-Linux-x86_64-390.77/kernel/nvidia-modeset/nv-modeset-interface.o /home/rgadsdon/kernel/NVIDIA-Linux-x86_64-390.77/kernel/nvidia-modeset/nvidia-modeset-linux.o
Building modules, stage 2.
MODPOST 4 modules
CC /home/rgadsdon/kernel/NVIDIA-Linux-x86_64-390.77/kernel/nvidia-drm.mod.o
LD [M] /home/rgadsdon/kernel/NVIDIA-Linux-x86_64-390.77/kernel/nvidia-drm.ko
CC /home/rgadsdon/kernel/NVIDIA-Linux-x86_64-390.77/kernel/nvidia-modeset.mod.o
LD [M] /home/rgadsdon/kernel/NVIDIA-Linux-x86_64-390.77/kernel/nvidia-modeset.ko
CC /home/rgadsdon/kernel/NVIDIA-Linux-x86_64-390.77/kernel/nvidia-uvm.mod.o
LD [M] /home/rgadsdon/kernel/NVIDIA-Linux-x86_64-390.77/kernel/nvidia-uvm.ko
CC /home/rgadsdon/kernel/NVIDIA-Linux-x86_64-390.77/kernel/nvidia.mod.o
LD [M] /home/rgadsdon/kernel/NVIDIA-Linux-x86_64-390.77/kernel/nvidia.ko
make[2]: Leaving directory '/usr/src/linux-4.18-rc5'
make[1]: Leaving directory '/usr/src/linux-4.18-rc5'

Robert Gadsdon.   July 16, 2018

X86_64 – Fedora Upgrade on Intel ‘Apollo Lake’ System Disables EFI boot – and Fix

The Intel SOC AP42 system is not supported by Grub2-EFI, but boots using rEFInd (see article at http://rglinuxtech.com/?p=2021 ).

I had hoped to prevent the ‘automatic’ (re)install of grub2-efi etc by masking the (minimal) grub installation of grubby etc. – necessary to support the Kernel # make install function – using # rpm -e --justdb --nodeps <package>.  I then found that – for some reason – the rEFInd install was still overwritten during # dnf system-upgrade reboot etc..

Fortunately the re-install of rEFInd on this system was relatively simple.    I created a bootable  USB stick with the AltLinux Rescue Disk installed – which uses rEFInd (see https://en.altlinux.org/Rescue ), and booted from this.     Then all I had to do was run # refind-install --usedefault /dev/mmcblk0p1 to get the boot working again, with my existing rEFInd config.   Note that this is different from the usual grub2 install, and the target is the EFI partition itself.

Robert Gadsdon   July 15, 2018.

Fedora – F28 Upgrade on ARM64 – Fix for GPG Errors..

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