The patch attached to this blog post is needed to successfully run VMware Workstation 8.0.1 on the current Linux kernel 3.2.0-rc2. So, it will be needed for the final 3.2 release, too. If you need instructions how to apply the patch please consult my other blog entries. Have fun!
VMware Workstation 8.0.0 won't work on Linux Kernel 3.1.0 out of the box. But, some clever guy coded a very neat script that you can use to patch the workstation in a few easy steps:
$ cd /tmp
$ wget http://22.214.171.124/vmware3.1rc.sh
$ chmod +x vmware3.1rc.sh
That should patch the modules source, recompile it and start the vmware services. I've also attached the courtesy copy of the script to this article, in case the remote location becomes unavailable.
VMware Workstation 7.1.4 worked correctly on kernel 2.6.38, e.g. the modules built without problems.
Unfortunately, it's not working correctly anymore, after you upgrade to the latest linux kernel 2.6.39.
Thanks to Weltall, we now have a patch that brings Workstation (and probably Player, too) up-to-date with the newest kernel. Here's the original article: Running VMware Workstation / Player on linux 2.6.39 - UPDATED
I've also attached the patch to this article, because Weltall's blog is quite slow and sometimes even unreachable. If you need help applying the patch, follow the instructions on this page: VMware Workstation 7.1.3 runs great on Linux kernel 2.6.37.
Of course, only after you patch the installation. :) I can't remember when was the last time Workstation run without patching, that was really long long time ago. Maybe it's Linus' fault, he moves too fast, who can tell... :)
Also, you won't be able to compile and run the 2.6.37 kernel with the legacy BKL (Big Kernel Lock) disabled, Workstation still depends on lock_kernel() and unlock_kernel() primitives. Let's hope VMware fixes that in their next revision.
Anyway... the patch is relatively small this time, but many files had to be patched for the modules to compile properly, so I propose a slightly different methodology for patching.
Using 2.6.x kernel build system.
make: Entering directory `/tmp/vmware-root/modules/vmmon-only'
make -C /lib/modules/2.6.36/build/include/.. SUBDIRS=$PWD SRCROOT=$PWD/. \
make: Entering directory `/usr/src/linux'
CC [M] /tmp/vmware-root/modules/vmmon-only/linux/driver.o
/tmp/vmware-root/modules/vmmon-only/linux/driver.c: In function 'init_module':
/tmp/vmware-root/modules/vmmon-only/linux/driver.c:425: error: 'struct file_operations' has no member named 'ioctl'
This time compilation fails with:
make: Entering directory `/tmp/vmware-root/modules/vsock-only'
make -C /lib/modules/2.6.35/build/include/.. SUBDIRS=$PWD SRCROOT=$PWD/. \
make: Entering directory `/usr/src/linux'
CC [M] /tmp/vmware-root/modules/vsock-only/linux/af_vsock.o
/tmp/vmware-root/modules/vsock-only/linux/af_vsock.c:312: warning: initialization from incompatible pointer type
/tmp/vmware-root/modules/vsock-only/linux/af_vsock.c:359: warning: initialization from incompatible pointer type
With the attached patch you can persuade your VMware Workstation to work on the newest Linux kernel 2.6.29. There are no guarantees, but it works for me(tm).
Unpack tar's from /usr/lib/vmware/modules/source into some directory (except vmppuser.tar), patch the source (patch -p1), run make in every subdirectory, copy resulting kernel modules to /lib/modules/2.6.29/misc and run depmod -a. Then you can run /etc/init.d/vmware start and check that all modules loaded correctly. That should be it.
Referencing the post Nvidia Linux driver 100.14.11 and Linux kernel 2.6.23. Here I have attached the patches for the older versions of Nvidia drivers. The procedure to follow is the same as described in the above document.
Well, they're not working together. Unless you're not willing to tweak it a little bit. So, out of the box, you won't be able to test brand new Linux CFS scheduler, merged in the 2.6.23-rc1 release, if you drive your Nvidia card with the proprietary driver. I guess that's what we get for running binary drivers.
One of the more interesting patches for the linux kernel lately has been Wu Fengguang's adaptive readahead patchset, currently at version 12. Talking about its performance benefits Wu says: "besides file servers and desktops, it is recently found to benefit postgresql databases a lot.".
So I decided to do a simple benchmark to see what difference would adaptive readahead make in my case. The idea was to test a very simple database query (random select) to the PostgreSQL database and see how it performs through time (while the memory is being primed with data from disk).