Kernel – 4.16-rc1 – OK with VMware 14.1.1, Breaks NVIDIA?..

Kernel 4.16-rc1 is out, and brief details are here:

VMware 14.1.1 is OK, and NVIDIA 384.111 and 390.25 both compile OK, but then fail to load/run:

modprobe: ERROR: could not insert 'nvidia': Unknown symbol in module, or unknown parameter (see dmesg)
[ 2142.352238] nvidia: Unknown symbol swiotlb_map_sg_attrs (err 0)

Comparing kernel 4.15.x compiled source tree (OK) with 4.16-rc1 (failed..):

# grep swiotlb_map_sg_attrs *
Module.symvers:0x00000000 swiotlb_map_sg_attrs vmlinux EXPORT_SYMBOL
........ T swiotlb_map_sg_attrs r __ksymtab_swiotlb_map_sg_attrs r __kstrtab_swiotlb_map_sg_attrs

# grep swiotlb_map_sg_attrs *
................ T swiotlb_map_sg_attrs

I tried using a ‘clean’ re-created kernel config for 4.16-rc1, but still got the same result..  More research needed, before this can be confirmed as a ‘defect’….

Robert Gadsdon.  February 11, 2018.



Kernel – GCC and ‘Retpoline’..

The recent summary of Kernel 4.15 mentioned the test for ‘compliant’ versions of GCC which fully support the retpoline mitigation, but only gave an example of non-compliance:

With GCC 7.2:

~]$ cat /sys/devices/system/cpu/vulnerabilities/spectre_v2
 Vulnerable: Minimal generic ASM retpoline

I re-created Fedora (Rawhide) GCC 7.3.1 for Fedora 27, and it gives the following, after Kernel 4.15 compilation/boot:

~]$ cat /sys/devices/system/cpu/vulnerabilities/spectre_v2
 Mitigation: Full generic retpoline

GCC 7.3.x should be available for Fedora 27 and other Distros, soon..

Robert Gadsdon.  February 1, 2018.

Kernel – 4.15 Final, at Last..

Kernel 4.15 is – finally – released, and an overview of changes since -rc9 is here:

The latest NVIDIA drivers – 384.111 and 390.12 – compile and load OK, and VMware 14.1.1 is also OK.

It is worth mentioning that , although the final release was delayed due to more work on PTI mitigation etc,  this is still work-in-progress…   There is further protection – retpoline – that depends on compiler features, which have already been incorporated into beta GCC 8.X, and are due to be ‘backported’ to the next mainstream 7.X release – GCC 7.3.

Robert Gadsdon.   January 28, 2018

IA64 – The Gentoo saga.. Kernel 4.15-rc9

After a lot of patience(!) I now have a much-hacked version of Gentoo running on the HP RX2600, and have just updated the kernel to 4.15-rc9:

[ OK ] Reached target Multi-User System.
 [ OK ] Reached target Graphical Interface.
 This is rgia64.unknown_domain (Linux ia64 4.15.0-rc9) 19:42:44

root@rgia64 ~ # uname -a
 Linux rgia64 4.15.0-rc9 #1 SMP Sun Jan 21 18:34:32 PST 2018 ia64 Madison GenuineIntel GNU/Linux
root@rgia64 ~ # cat /proc/cpuinfo processor : 0
 vendor : GenuineIntel
 arch : IA-64
 family : 31
 model : 1
 model name : Madison
 revision : 5
 archrev : 0
 features : branchlong
 cpu number : 0
 cpu regs : 4
 cpu MHz : 1500.000
 itc MHz : 1500.000000
 BogoMIPS : 2246.65
 siblings : 1
 physical id: 0

processor : 1
 vendor : GenuineIntel
 arch : IA-64
 family : 31
 model : 1
 model name : Madison
 revision : 5
 archrev : 0
 features : branchlong
 cpu number : 0
 cpu regs : 4
 cpu MHz : 1500.000
 itc MHz : 1500.000000
 BogoMIPS : 2246.65
 siblings : 1
 physical id: 3

I have had problems with some web-related software, and some of this is explicitly prevented from compiling:
QtWebEngine can only be built for x86, x86-64, ARM, Aarch64, and MIPSel architectures.
QtWebEngine will not be built.

Firefox and Konqueror failed to compile, with ‘inlining‘ errors, and I have been unable to find a workaround, despite changing compiler parameters etc,..

I did (eventually) get the Midori browser to compile, but this would only display sites if java/javascript was disabled..

The Gentoo java is no longer available, but I was able to get a reasonably recent IA64 version from the Sun/Oracle site..
root@rgia64 ~ # java -version
java version "1.6.0_45"
Java(TM) SE Runtime Environment (build 1.6.0_45-b0602)
Java HotSpot(TM) 64-Bit Server VM (build 17.0-b17, mixed mode)

At least the actual Kernel still compiles OK, but I found that the Gentoo instructions for EFI were a bit odd, and so kept the Fedora setup..     After # make install, I have to copy the kernel vmlinuz…  image to /boot/EFI/EFI/redhat,and create the initrd there manually, but this works OK..

Robert Gadsdon.   January 22, 2018

VMware – 14.1.1 released – OK with Kernel 4.15..

As expected, there is a new release of VMware – 14.1.1 – and brief details are here:

This version compiles and loads OK with the latest 4.15-rc kernel – tested with 4.15-rc7, and no longer needs the vmmon series of patches.

Robert Gadsdon.   January 10, 2018.

Kernel – 4.15-rc7 Released – And there will be an -rc8..

Kernel 4.15-rc7 is out, and (brief) details of changes since -rc6 are here:    The preamble is worth a read, as it pays tribute to the work done on the x86 PTI fixes..

Vmmon-patched VMware 14.1.0 is OK (see: ) and the latest NVIDIA drivers – 384.111 and 390.12 are both still OK.

As mentioned, in view of the PTI work, there will be a 4.15-rc8 – at least – before 4.15 Final is released..

Robert Gadsdon.   January 7, 2018.

NVIDIA – Two New Drivers, OK with 4.14.12-rc1 and 4.15-rc6..

Thanks to zezaocapoeia, for spotting the newly released NVIDIA Beta driver 390.12 ( see )    There is also a new version of the ‘long lived branch’ series – 384.111.

I have tested these with Kernel 4.14.12-rc1 and 4.15-rc6, and they both compile and load/run OK.    In this case, NVIDIA has fixed their GPL error with recent 4.14 kernels, themselves.

Robert Gadsdon.   January 5, 2018.

Kernel – 4.14.11 ‘Final’ Breaks NVIDIA 384.98 and 387.34 – GPL Error..

I had previously tested Kernel 4.14.11-rc1 with the 4.14.9+-patched NVIDIA driver 384.98, and that was OK:

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

But, after updating to 4.14.11 ‘final’, the following occurred:

ld -r -o /home/rgadsdon/kernel/NVIDIA-Linux-x86_64-384.98-41410/kernel/nvidia-modeset/nv-modeset-interface.o /home/rgadsdon/kernel/NVIDIA-Linux-x86_64-384.98-41410/kernel/nvidia-modeset/nvidia-modeset-linux.o
 Building modules, stage 2.
 MODPOST 4 modules
FATAL: modpost: GPL-incompatible module nvidia.ko uses GPL-only symbol 'cpu_tlbstate'
make[3]: *** [/usr/src/linux-4.14.11/scripts/Makefile.modpost:92: __modpost] Error 1
make[2]: *** [/usr/src/linux-4.14.11/Makefile:1511: modules] Error 2
make[2]: Leaving directory '/usr/src/linux-4.14.11'
make[1]: *** [Makefile:146: sub-make] Error 2
make[1]: Leaving directory '/usr/src/linux-4.14.11'
make: *** [Makefile:81: modules] Error 2

The ‘short-lived-branch’ driver 387.34 did not need patching for 4.4.9 and 10, but also fails with the same GPL error.   I had previously tried using that driver, but had found – at least on my system – that it caused Firefox to freeze, and crash, repeatedly..

So.. For the time being, If you need the changes in 4.14.11, then you can – at least – use 4.14.11-rc1..

Robert Gadsdon.   January 2, 2018.   (updated January 3, 2018)

Kernel – Urgent Changes in Latest Versions, to Fix Intel CPU Security..

Apparently, there has been a major security defect discovered in Intel CPUs, and full details have been embargoed until early-January, but there is a comprehensive article in The Register, here:

The Linux Kernel devs have been working to provide a workaround, as – apparently – there is no other practical solution:

The article does hint that ‘hypervisors’ may also be affected, and so I would speculate that changes to VMware, as well as Xen, may be forthcoming..

The fix will add extra processing, and will affect the overall performance of Intel CPUs..

These changes are being incorporated in Kernel 4.14.11, and had already been incorporated in 4.15-rc6  (look for references to “PTI” and/or “PAGE_TABLE_ISOLATION” in the changelogs:

Robert Gadsdon.   January 2, 2018.  (updated January 3, 2018)

Kernel – 4.14.11-rc1 Still breaks NVIDIA, and Won’t be Fixed?

Just tried the ‘stable-review’ patch for the ‘stable’ Kernel – 4.14.11-rc1, and the same NVIDIA problem is there, and it seems the kernel devs won’t do anything:

So – it seems the patch is now a permanent requirement for all subsequent 4.14 releases..  (see )..

And… It seems the unwritten rule of ‘don’t break stuff during stable kernel releases‘ no longer applies?

Robert Gadsdon.  January 1, 2018.