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:  https://docs.vmware.com/en/VMware-Workstation-Pro/14/rn/workstation-1411-release-notes.html

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:  http://lkml.iu.edu/hypermail/linux/kernel/1801.0/04858.html.    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: https://github.com/mkubecek/vmware-host-modules/tree/workstation-14.1.0 ) 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 http://www.nvidia.com/download/driverResults.aspx/128743/en-us )    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:  https://www.theregister.co.uk/2018/01/02/intel_cpu_design_flaw/

The Linux Kernel devs have been working to provide a workaround, as – apparently – there is no other practical solution: https://lkml.org/lkml/2017/12/4/709

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:
4.15-rc6:  http://lkml.iu.edu/hypermail/linux/kernel/1712.3/02898.html
4.14.11:   https://cdn.kernel.org/pub/linux/kernel/v4.x/ChangeLog-4.14.11

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: http://lkml.iu.edu/hypermail/linux/kernel/1712.3/02608.html

So – it seems the patch is now a permanent requirement for all subsequent 4.14 releases..  (see http://rglinuxtech.com/?p=2168 )..

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

Robert Gadsdon.  January 1, 2018.

Kernel – 4.14.10 Still breaks NVIDIA!

Just updated the test system to Kernel 4.14.10, and was ‘somewhat dismayed‘ – to put it politely – that the NVIDIA breakage introduced in 4.14.9 is still there!

............
/home/rgadsdon/kernel/NVIDIA-Linux-x86_64-384.98/kernel/nvidia-uvm/uvm8_va_block.c: In function ‘block_cpu_fault_locked’:
/usr/src/linux-4.14.10/arch/x86/include/asm/processor.h:826:39: error: implicit declaration of function ‘task_stack_page’; did you mean ‘task_stack_vm_area’? [-Werror=implicit-function-declaration]
 unsigned long __ptr = (unsigned long)task_stack_page(task); \
 ^
/usr/src/linux-4.14.10/arch/x86/include/asm/processor.h:900:26: note: in expansion of macro ‘task_pt_regs’
 #define KSTK_EIP(task) (task_pt_regs(task)->ip)
 ^~~~~~~~~~~~
/home/rgadsdon/kernel/NVIDIA-Linux-x86_64-384.98/kernel/nvidia-uvm/uvm8_va_block.c:8771:41: note: in expansion of macro ‘KSTK_EIP’
 KSTK_EIP(current));
 ^~~~~~~~
cc1: some warnings being treated as errors
make[3]: *** [/usr/src/linux-4.14.10/scripts/Makefile.build:315: /home/rgadsdon/kernel/NVIDIA-Linux-x86_64-384.98/kernel/nvidia-uvm/uvm8_va_block.o] Error 1
make[2]: *** [/usr/src/linux-4.14.10/Makefile:1504: _module_/home/rgadsdon/kernel/NVIDIA-Linux-x86_64-384.98/kernel] Error 2
make[2]: Leaving directory '/usr/src/linux-4.14.10'
make[1]: *** [Makefile:146: sub-make] Error 2
make[1]: Leaving directory '/usr/src/linux-4.14.10'
make: *** [Makefile:81: modules] Error 2

So… the 4.14.9 patch still applies, and fixes the problem (see http://rglinuxtech.com/?p=2168 ):

........
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.10'
make[1]: Leaving directory '/usr/src/linux-4.14.10'

Its not as if the kernel devs weren’t told…  http://lkml.iu.edu/hypermail/linux/kernel/1712.3/02196.html

Oh well, maybe in 4.14.11??

Robert Gadsdon.  December 29, 2017.

Kernel – 4.14.9 NVIDIA Saga – Simple Patch, or Wait for 4.14.10..?

More on the Kernel 4.14.9 NVIDIA breakage..     Basically, code that should have only gone into 4.15-rc found its way into 4.14.9 – which is why the existing 4.15 NVIDIA patch fixed it..     Thanks to dinosaur_ on the NVIDIA forum, there is a simpler patch available:  https://devtalk.nvidia.com/default/topic/1028016/linux/patch-for-compiling-v384-98-modules-with-linux-v4-14-9-/

There is also a 4.14.10-rc1 patch which is supposed to revert some of the offending changes, at https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.1.10-rc1.xz but this is not recommended, for the simple reasons that a) it fails (..make[2]: execvp: ./sync-check.sh: Permission denied ) and even when this is fixed (make sync-check.sh executable..), then b) the resulting kernel ‘4.14.10-rc1’ does not fix the NVIDIA problem!    Apparently the changes were actually supposed to be applied via githttps://www.spinics.net/lists/stable/msg207374.html

Bottom line…  If you really want a feature/fix only available in 4.14.9, then use the NVIDIA patch, or wait a short time for 4.14.10 (and keep your fingers crossed that it will actually fix the problem, this time..)    I have tested the simple NVIDIA patch, and the 384.98 driver compile/load now works OK:

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

Robert Gadsdon   December 27, 2017.

 

KERNEL – 4.14.9 Breaks NVIDIA – and a Fix..

Just updated to Kernel 4.14.9, and normally this should not be anything to cause concern, but this time there has been a significant code change made, that has broken NVIDIA (384.98):

.....................
/home/rgadsdon/kernel/NVIDIA-Linux-x86_64-384.98/kernel/nvidia-uvm/uvm8_va_block.c: In function ‘block_cpu_fault_locked’:
/usr/src/linux-4.14.9/arch/x86/include/asm/processor.h:826:39: error: implicit declaration of function ‘task_stack_page’; did you mean ‘task_stack_vm_area’? [-Werror=implicit-function-declaration]
 unsigned long __ptr = (unsigned long)task_stack_page(task); \
 ^
/usr/src/linux-4.14.9/arch/x86/include/asm/processor.h:900:26: note: in expansion of macro ‘task_pt_regs’
 #define KSTK_EIP(task) (task_pt_regs(task)->ip)
 ^~~~~~~~~~~~
/home/rgadsdon/kernel/NVIDIA-Linux-x86_64-384.98/kernel/nvidia-uvm/uvm8_va_block.c:8771:41: note: in expansion of macro ‘KSTK_EIP’
 KSTK_EIP(current));
 ^~~~~~~~
cc1: some warnings being treated as errors
make[3]: *** [/usr/src/linux-4.14.9/scripts/Makefile.build:315: /home/rgadsdon/kernel/NVIDIA-Linux-x86_64-384.98/kernel/nvidia-uvm/uvm8_va_block.o] Error 1
make[2]: *** [/usr/src/linux-4.14.9/Makefile:1504: _module_/home/rgadsdon/kernel/NVIDIA-Linux-x86_64-384.98/kernel] Error 2
make[2]: Leaving directory '/usr/src/linux-4.14.9'
make[1]: *** [Makefile:146: sub-make] Error 2
make[1]: Leaving directory '/usr/src/linux-4.14.9'
make: *** [Makefile:81: modules] Error 2

This sort of thing is expected in ‘testing’ -rc kernel versions, but is not supposed to occur in ‘mainline/stable’ versions..

It had already been mentioned in the Kernel mailing list:  http://lkml.iu.edu/hypermail/linux/kernel/1712.3/00099.html

Fortunately, there is a fix, and it is – somewhat ironically – the patch intended for Kernel 4.15 (see http://rglinuxtech.com/?p=2141 ), and with this, the compile/load completes successfully:

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

It remains to be seen whether this significant change to the stable 4.14 kernel series will be reverted, but – IMHO – it should be!

FYI.. I had seen a report that VMware 14.1.0 was also broken with Kernel 4.14.9, but it seems OK on my system..

Robert Gadsdon.  December 27, 2017.

SCSI – Adding and Removing Disk, Without Reboot..

Many aeons ago, I used to have SCSI disks on my ancient Linux systems, but the only SCSI device I attached nowadays was the LTO Tape drive, for full system backups, very occasionally..   Now, I have the HP RX2600 IA64 system, with nothing but U320 SCSI LVD disks, and needed to find a way of attaching one to my x86_64 system temporarily, to backup/(re)install the root filesystem, during testing..

The physical attachment is via an LVD/68-pin adapter, connected to the main SCSI cable, with an external 12v power supply.   I remembered to connect the disk directly, after disconnecting the LTO drive..

SCSI disk attachment

I used to use the old ‘rescan-scsi-bus.sh’ script, but that no longer worked, and I found a useful article on an alternative method, here:  https://geekpeek.net/rescan-scsi-bus-on-linux-system/    This suggested running the command on every scsi hostID, but that seemed a bit of a waste, so I worked out a simpler solution..

First, find the PCI bus ID of the SCSI adapter card (Adaptec, in my case) using # lspci:
.…………………
03:04.0 SCSI storage controller: Adaptec ASC-29320ALP U320 (rev 10)
…………………

Then, look for the same PCI bus id (03:04:0, in this case) after entering  # ls /sys/class/scsi_host -l:
………………..
lrwxrwxrwx 1 root root 0 Dec 23 14:33 host14 -> ../../devices/pci0000:00/0000:00:06.0/0000:02:00.0/0000:03:04.0/host14/scsi_host/host14
……………….

This gives you the hostID for the SCSI adapter (host14, in this example)

Then – as per the article – just enter # echo “- – -” > /sys/class/scsi_host/host14/scan

— and this will find and attach the disk..

# lsscsi
[0:0:0:0] disk ATA WDC WD20EZRZ-00Z 0A80 /dev/sda 
[1:0:0:0] disk ATA WDC WD1001FALS-0 0K05 /dev/sdb 
[2:0:0:0] disk ATA WDC WD1001FALS-0 0K05 /dev/sdc 
[3:0:0:0] disk ATA WDC WD1001FALS-0 0K05 /dev/sdd 
[4:0:0:0] disk ATA WDC WD1001FALS-0 0K05 /dev/sde 
[5:0:0:0] disk ATA WDC WD1001FALS-0 0K05 /dev/sdf 
[6:0:0:0] disk ATA WDC WD20EARX-00P AB51 /dev/sdg 
[7:0:0:0] disk ATA WDC WD20EARX-00P AB51 /dev/sdh 
[13:0:0:0] process Marvell 91xx Config 1.01 - 
[14:0:9:0] disk COMPAQ BF07288285 HPB2 /dev/sdi

To detach the disk, enter # echo 1 > /sys/block/sdi/device/delete – where sdi is the SCSI disk ID from the lsscsi example above ..

Tested, and works successfully, on Kernel 4.14.8, Fedora 27.

Robert Gadsdon  December 22, 2017.