VMware version 12.5.7 is out, and the release notes are here: http://pubs.vmware.com/Release_Notes/en/workstation/12/workstation-1257-release-notes.html As usual, not much actual detail, apart from “…some bug fixes and security updates.”
This version compiles OK with Kernel 4.12 (tested with 4.12-rc6), but the runtime GUI and GCC7 workarounds mentioned in previous articles are still needed, for ‘newer’ distros, such as Fedora 26….
Robert Gadsdon. June 22, 2017.
More distro-specific than usual posts, but hopefully ‘useful’..
I found that Kodi on Fedora 25 would no longer play M2T/MTS files. Frustratingly, there was no error shown, or apparent debug clue, but the program just exited without any messages, when playback of one of these file types was selected.
After checking associated libraries and not getting any clues, I did find that the Fedora 26 version played everything OK, despite the fact that the version (17.3-1) was the same as F25. This was confirmed on four different systems..
I decided to try rebuilding the kodi rpm from source, using the ‘latest’ version, from here:
After sorting out and installing the required …devel.. rpms, the rpmbuild –rebuild on F25 completed OK, and after (force) updating with the resulting set of rpms, everything works OK again.. Slightly annoying to not have the cause of the problem, but at least this fixes it..
Robert Gadsdon. June 18, 2017.
In the thread on the VMware forum ( https://communities.vmware.com/thread/565157 ) there is a link to a potential patch for Kernel 4.12 support, but you are advised to not try to execute this, as – although it compiles OK – it will cause the host system to reboot without warning as soon as a client is started.. I have ‘tested’ this, and confirm that the host immediately reboots, without any console output!
I did mention in the earlier article that VirtualBox suffered from a similar problem, and it appears that they now have a solution ( https://www.virtualbox.org/ticket/16725 ). To see the changes that have been made, compare the old and new versions of memobj-r0drv-linux.c in the source tree..
Hopefully a fix will be available for VMware, soon..
Robert Gadsdon. June 9, 2017.
After further research, I have found a simple solution for the VMware 12.5.6 runtime, with Fedora 26, thanks to comments by ronengi and others on the Archlinux site ( https://aur.archlinux.org/packages/vmware-patch/ ). This made sense, as the vmware-installer graphical interface still ran OK, despite the runtime vmware not doing so..
# cp -r /usr/lib/vmware-installer/2.1.0/lib/lib/libexpat.so.0 /usr/lib/vmware/lib # cd /usr/lib/vmware/lib/libz.so.1 # mv -i libz.so.1 libz.so.1.old # ln -s /usr/lib64/libz.so.1 .
Then just run the executable in the normal way – # vmware
The kernel modules vmmon and vmnet still need to be manually compiled with gcc 7 and copied, as follows:
In the /usr/lib/vmware/modules/source directory, unTAR vmmon.tar and vmnet.tar, and then enter the resulting vmmon-only and vmnet-only directories and just type # make in each. Then create a /lib/modules/<kernel version>/misc directory, and copy vmmon.ko and vmnet.ko there, then # depmod -a.
I have still not found a solution for vmmon with Kernel 4.12-rc, but have reported the problem on the VMware forum..
Robert Gadsdon. May 29, 2017
I had been testing VMware 12.5.6 – unsuccessfully – with Kernel 4.12-rc2, but on reverting to Kernel 4.11.3, I found that the vmware runtime workaround for Fedora 26 / GCC 7 ( see http://rglinuxtech.com/?p=1939 ) no longer worked, and produced the same result as before the modifications – no execution, and a return to the command prompt..
After further testing, I found that the only solution was to revert to VMware 12.5.5 – with the 4.11 vmmon/vmnet patches. The workaround was successful, again..
Fedora 26 is due to be released in about six weeks time (but may slip..) and hopefully this workaround will be unnecessary, by then..
Robert Gadsdon. May 26, 2017.
VMware version 12.5.6 is out, and (brief) details are here: http://pubs.vmware.com/Release_Notes/en/workstation/12/workstation-1256-release-notes.html
In the release notes, it would be helpful if a bit more detail than just ” Bug fixes and security updates ” were given…
This version now works OK with Kernel 4.11 without any patches (tested with 4.11.1), but still fails (vmmon) with 4.12 (tested with 4.12-rc1):
............................... /usr/lib/vmware/modules/source/vmmon-only/./include/pgtbl.h: In function ‘PgtblPGD2PTELocked’: /usr/lib/vmware/modules/source/vmmon-only/./include/pgtbl.h:125:28: error: passing argument 1 of ‘pud_offset’ from incompatible pointer type [-Werror=incompatible-pointer-types] pud = compat_pud_offset(pgd, addr); ^ /usr/lib/vmware/modules/source/vmmon-only/./include/compat_pgtable.h:72:56: note: in definition of macro ‘compat_pud_offset’ # define compat_pud_offset(pgd, address) pud_offset(pgd, address) ^~~ In file included from ./include/linux/mm.h:70:0, from /usr/lib/vmware/modules/source/vmmon-only/./include/compat_page.h:23, from /usr/lib/vmware/modules/source/vmmon-only/linux/hostif.c:32: ./arch/x86/include/asm/pgtable.h:826:22: note: expected ‘p4d_t * {aka struct <anonymous> *}’ but argument is of type ‘compat_pgd_t * {aka struct <anonymous> *}’ static inline pud_t *pud_offset(p4d_t *p4d, unsigned long address) ^~~~~~~~~~ cc1: some warnings being treated as errors make[2]: *** [scripts/Makefile.build:303: /usr/lib/vmware/modules/source/vmmon-only/linux/hostif.o] Error 1 make[1]: *** [Makefile:1512: _module_/usr/lib/vmware/modules/source/vmmon-only] Error 2 make[1]: Leaving directory '/usr/src/linux-4.12-rc1' make: *** [Makefile:120: vmmon.ko] Error 2
A similar compile failure also occurs with VirtualBox and Kernel 4.12: https://www.virtualbox.org/ticket/16725 , but there is no solution mentioned there – so far..
The rather messy workarounds are still needed for GCC 7 (Fedora 26 etc.) and details are here: http://rglinuxtech.com/?p=1939 , but remember that the library version numbers will now be different from the examples shown..
Update – May 26: The workaround no longer works with 12.5.6 – see latest article..
Robert Gadsdon. May 18, 2017.
Kernel 4.11.1 has been released, and the changelog is here: https://cdn.kernel.org/pub/linux/kernel/v4.x/ChangeLog-4.11.1
This does include the licence ‘revert’ for refcount.c, and so the latest NVIDIA drivers now compile/load OK..
............................ Building modules, stage 2. MODPOST 4 modules CC /home/rgadsdon/NVIDIA-Linux-x86_64-381.22/kernel/nvidia-drm.mod.o LD [M] /home/rgadsdon/NVIDIA-Linux-x86_64-381.22/kernel/nvidia-drm.ko CC /home/rgadsdon/NVIDIA-Linux-x86_64-381.22/kernel/nvidia-modeset.mod.o LD [M] /home/rgadsdon/NVIDIA-Linux-x86_64-381.22/kernel/nvidia-modeset.ko CC /home/rgadsdon/NVIDIA-Linux-x86_64-381.22/kernel/nvidia-uvm.mod.o LD [M] /home/rgadsdon/NVIDIA-Linux-x86_64-381.22/kernel/nvidia-uvm.ko CC /home/rgadsdon/NVIDIA-Linux-x86_64-381.22/kernel/nvidia.mod.o LD [M] /home/rgadsdon/NVIDIA-Linux-x86_64-381.22/kernel/nvidia.ko make[2]: Leaving directory '/usr/src/linux-4.11.1' make[1]: Leaving directory '/usr/src/linux-4.11.1'
Robert Gadsdon. May14, 2017.
Kernel 4.12-rc1 is out – one day early – and brief details are here: http://lkml.iu.edu/hypermail/linux/kernel/1705.1/03964.html
The release includes the reverted GPL/MIT licence changes in refcount.c, and the latest NVIDIA drivers compile/load OK, now:
........................... Building modules, stage 2. MODPOST 4 modules CC /home/rgadsdon/kernel/NVIDIA-Linux-x86_64-381.22/kernel/nvidia-drm.mod.o LD [M] /home/rgadsdon/kernel/NVIDIA-Linux-x86_64-381.22/kernel/nvidia-drm.ko CC /home/rgadsdon/kernel/NVIDIA-Linux-x86_64-381.22/kernel/nvidia-modeset.mod.o LD [M] /home/rgadsdon/kernel/NVIDIA-Linux-x86_64-381.22/kernel/nvidia-modeset.ko CC /home/rgadsdon/kernel/NVIDIA-Linux-x86_64-381.22/kernel/nvidia-uvm.mod.o LD [M] /home/rgadsdon/kernel/NVIDIA-Linux-x86_64-381.22/kernel/nvidia-uvm.ko CC /home/rgadsdon/kernel/NVIDIA-Linux-x86_64-381.22/kernel/nvidia.mod.o LD [M] /home/rgadsdon/kernel/NVIDIA-Linux-x86_64-381.22/kernel/nvidia.ko make[2]: Leaving directory '/usr/src/linux-4.12-rc1' make[1]: Leaving directory '/usr/src/linux-4.12-rc1'
4.11-patched VMware 12.5.5 fails to compile.. vmnet is OK, but vmmon fails:
............................ In file included from /usr/lib/vmware/modules/source/vmmon-only/./include/pgtbl.h:25:0, from /usr/lib/vmware/modules/source/vmmon-only/linux/hostif.c:99: /usr/lib/vmware/modules/source/vmmon-only/./include/pgtbl.h: In function ‘PgtblPGD2PTELocked’: /usr/lib/vmware/modules/source/vmmon-only/./include/pgtbl.h:125:28: error: passing argument 1 of ‘pud_offset’ from incompatible pointer type [-Werror=incompatible-pointer-types] pud = compat_pud_offset(pgd, addr); ^ /usr/lib/vmware/modules/source/vmmon-only/./include/compat_pgtable.h:72:56: note: in definition of macro ‘compat_pud_offset’ # define compat_pud_offset(pgd, address) pud_offset(pgd, address) ^~~ In file included from ./include/linux/mm.h:70:0, from /usr/lib/vmware/modules/source/vmmon-only/./include/compat_page.h:23, from /usr/lib/vmware/modules/source/vmmon-only/linux/hostif.c:32: ./arch/x86/include/asm/pgtable.h:826:22: note: expected ‘p4d_t * {aka struct <anonymous> *}’ but argument is of type ‘compat_pgd_t * {aka struct <anonymous> *}’ static inline pud_t *pud_offset(p4d_t *p4d, unsigned long address) ^~~~~~~~~~
Robert Gadsdon. May 13, 2017.
New NVIDIA driver 381.22 has been released, and details are here: http://www.nvidia.com/Download/driverResults.aspx/118524/en-us
The 4.11 ‘workaround’ still applies (see http://rglinuxtech.com/?p=1970 ).
It seems now that the reason the fix was – still – not made by NVIDIA, is that the problem may well be ‘fixed’ in a future Kernel release..
Changes to ‘revert’ the licensing have been proposed, as mentioned in a comment from this post: https://devtalk.nvidia.com/default/topic/1008121/linux/nvidia-drivers-381-22-linux-4-11-patch-is-still-required-really-nvidia-/ The comment mentions ”4.12 kernel should work” but I hope the patch will be applied to a later release of 4.11.x..
The proposed Kernel patch can be found at:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=d557d1b58b3546bab2c5bc2d624c5709840e6b10
The comment with the patch includes “….. changing api markings isn’t considered “nice”, so let’s fix this up. ”
I applied the patch to Kernel 4.11.0 (with quite a lot of ‘fuzz’..) and can confirm that it does – as expected – fix the licensing issue, for 375.66 and 381.22:
.................. /home/rgadsdon/kernel/NVIDIA-Linux-x86_64-381.22/kernel/nvidia-modeset/nvidia-modeset-linux.o Building modules, stage 2. MODPOST 4 modules CC /home/rgadsdon/kernel/NVIDIA-Linux-x86_64-381.22/kernel/nvidia-drm.mod.o LD [M] /home/rgadsdon/kernel/NVIDIA-Linux-x86_64-381.22/kernel/nvidia-drm.ko CC /home/rgadsdon/kernel/NVIDIA-Linux-x86_64-381.22/kernel/nvidia-modeset.mod.o LD [M] /home/rgadsdon/kernel/NVIDIA-Linux-x86_64-381.22/kernel/nvidia-modeset.ko CC /home/rgadsdon/kernel/NVIDIA-Linux-x86_64-381.22/kernel/nvidia-uvm.mod.o LD [M] /home/rgadsdon/kernel/NVIDIA-Linux-x86_64-381.22/kernel/nvidia-uvm.ko CC /home/rgadsdon/kernel/NVIDIA-Linux-x86_64-381.22/kernel/nvidia.mod.o LD [M] /home/rgadsdon/kernel/NVIDIA-Linux-x86_64-381.22/kernel/nvidia.ko make[2]: Leaving directory '/usr/src/linux-4.11' make[1]: Leaving directory '/usr/src/linux-4.11'
Robert Gadsdon. May 10, 2017.
NVIDIA have released driver 375.66, and the details are here: http://www.nvidia.com/Download/driverResults.aspx/118290/en-us
The details include the following:
“Installation of the nvidia-drm kernel module is now optional. The new ‘- -no-drm’ option can be used to prevent nvidia-installer from building and installing nvidia-drm, on systems where this kernel module fails to build and/or load.”
This does not mention Kernel 4.11 and GPL issues specifically, but this is what this ‘new feature’ is actually designed for.. This is a workaround, but not a solution..
Using the new option – -no-drm when executing NVIDIA-Linux-x86_64-375.66.run, the nvidia-drm modules are simply ignored..
To use this feature when just compiling the kernel modules themselves, from ~/NVIDIA-Linux-x86_64-375.66/kernel, do the following:
# export NV_EXCLUDE_KERNEL_MODULES=nvidia-drm # make
– and the compile will ignore the troublesome nvidia-drm modules, and complete successfully, without them:
............. Building modules, stage 2. MODPOST 3 modules CC /home/rgadsdon/kernel/NVIDIA-Linux-x86_64-375.66/kernel/nvidia-modeset.mod.o LD [M] /home/rgadsdon/kernel/NVIDIA-Linux-x86_64-375.66/kernel/nvidia-modeset.ko CC /home/rgadsdon/kernel/NVIDIA-Linux-x86_64-375.66/kernel/nvidia-uvm.mod.o LD [M] /home/rgadsdon/kernel/NVIDIA-Linux-x86_64-375.66/kernel/nvidia-uvm.ko CC /home/rgadsdon/kernel/NVIDIA-Linux-x86_64-375.66/kernel/nvidia.mod.o LD [M] /home/rgadsdon/kernel/NVIDIA-Linux-x86_64-375.66/kernel/nvidia.ko make[2]: Leaving directory '/usr/src/linux-4.11' make[1]: Leaving directory '/usr/src/linux-4.11'
I have tested this on 4.11, and it all seems to work as advertised…
It would seem that NVIDIA is having difficulty in re-writing the offending code in nvidia-drm to embrace the changes to licensing enforcement, and it may be – from initial correspondence on the kernel mailing list – that they were counting on the Kernel code changes being reverted, which they were not..
Robert Gadsdon. May 5, 2017. (reformatted to show two-dashes correctly..)