Aug 302012

It seems that VMware released a new major version and they fixed, again, things addressed by the previous patches only there (asking so people to buy a new version again, in case of workstation). So all the previous patches are not needed for these anymore on newer kernel, except one little patch provided here. It seems to give issues on 3.5+ kernels after some changes to the exception tables.

Jun 042012

Seems this time vmware didn’t give problems, instead it was virtualbox.

It seems do_mmap was removed in this commit (and related ones)

causing this:

/tmp/vbox.0/r0drv/linux/memobj-r0drv-linux.c: In function ‘rtR0MemObjLinuxDoMmap’:
/tmp/vbox.0/r0drv/linux/memobj-r0drv-linux.c:1150:9: error: implicit declaration of function ‘do_mmap’
make[2]: *** [/tmp/vbox.0/r0drv/linux/memobj-r0drv-linux.o] Error 1

Adding this piece of code at the top of the file with the error (it can be found in /usr/share/virtualbox/src/vboxhost/vboxdrv/r0drv/linux/memobj-r0drv-linux.c) after the other if LINUX_VERSION_CODE block:

#define do_mmap vm_mmap

Unfortunately this isn’t enough due to this error appearing upon modprobe:

vboxdrv: Unknown symbol do_munmap (err 0)

It seems this symbol was unexported, so it’s equally not accessible.

To fix this the patch goes in the-linux-kernel.h file. This is what’s there:

#ifndef MY_DO_MUNMAP
# define MY_DO_MUNMAP(a,b,c) do_munmap(a, b, c)

changing it to this allows everything to work:

#ifndef MY_DO_MUNMAP
# define MY_DO_MUNMAP(a,b,c) vm_munmap(b, c)
# define MY_DO_MUNMAP(a,b,c) do_munmap(a, b, c)

Unfortunately it seems there is still some sort of deadlock and I don’t have much time to check what is it, even though the modules load correctly.

The only other weird issue I’m experiencing is that I needed to re-associate my bluetooth mouse all the time.


Apr 012012

NOTICE: This patch works fine with 3.5.0 and 3.6.0-rc1

UPDATE: kwasik updated the previous 7.1.x/3.1.x patch with the changes detailed here and made a new patch so if you are using that version of vmware you can grab it ready from here

Another version of the kernel another broken module…

This time it was something easier and with a short solution directly in the kernel documentation, but not much said about the reasons for the change (which was done 11 days ago) except that it fixed bugs caused by misuse.

Anyway d_alloc_rot was replaced with d_make_root as said here. So that’s practically the fix to apply to the sources in order to make vmblock build (even though vmware seems to start also with this module not running).

The patch should be easy to apply also for 7.1.x vmware modules (but I’m not providing a patch as I don’t have the sources anymore).

This is the procedure:

Open vmblock.tar and search for filesystem.c. Then there search for d_alloc_root(rootInode). That needs to be replaced with d_make_root(rootInode). This will make vmblock build successfully.

And here it is the easier way for 8.0.x/4.0.x users: vmware 8.0.2 fix for linux 3.4.0

Remember that if you apply the patch you’ve to always start with clean module sources from 8.0.2 release. Also be careful that vmware, when uninstalled, doesn’t clean entirely it’s modules folder, so remember to do so before reinstalling it.

Attached Files:

Apr 012012

UPDATE1: as noted in the comments, and as now I had the chance to test it, I’ve removed some useless includes from the patch

Seems the drivers broke again with 3.4.0-rc1. According to git logs it seems someone dissected the asm/system.h header in several subfiles 3 days ago (so cannot really blame nvidia for this as this was done when they were going home for the weekend) and probably will break several other off tree modules. Anyway the fix is simple. to keep compatibility you need to replace #include <asm/system.h> in nv-linux.h and conftest.h with these two snippets. Also I’ve done a new version of with the additional changes. To use that just do sudo ./ <nvidiainstaller file> [parameters if any]


#include <asm/system.h>

#include <linux/version.h>
#include <asm/system.h>

That’s all…

Jan 262012

NOTICE: It seems some people are trying this patch on 3.4 kernels shipped with fedora. *This is only for 3.3 maximum* if you want a patch for 3.4 you’ve to go to this post in this blog. I always do new posts when there are new kernels, I don’t update previous ones.

UPDATE 4: Seems there was another slight problem with the 7.x patch so I’ve fixed it by hand. As i had to edit the patch itself by hand I hope it’s still applying (coudn’t test it as I don’t have the sources). So if you have downloaded the 7.1.5 (3.15) patch before now please download it again and patch from a clean file, else add a linux/pci.h as include in that line giving error and put the define at new line.

UPDATE 3: I’ve fixed a slight issue in the patch for 7.1.x which could prevent it from working on not fedora kernels (so with the normal numbering of vanilla kernels)

UPDATE 2: Thanks to Ariel, who backported this patch for 7.1.x, I’ve added here a patch to bring these fixes to the previous release series of the vmware player and workstation. The script uses the .5 versions (the last released) but you can change it for previous versions too (for sure for .4, as the kernel modules sources didn’t change)

UPDATE: Looks like a patch which I did previously for 3.2 wasn’t needed anymore for 3.3 (seems to be a 3.2 specific problem) and so I didn’t include it as I’m just running 3.3-rc1. Now I’ve included it again and updated the archive so if you’ve downloaded it and had problems you can get a proper version now.

Looks like VMware upgraded their virtualization solution and fixed some issues of their modules, but not all. So some patches which were already in the previous patch are still needed. I don’t know if this lack of support for recent linux kernel (even released as stable since more than half a month and that some distributions are starting to send to users) is, as the user who notified me of the new release of VMware said, done on purpose. In any case nothing changes so I’ve made a simple package with the only patch still needed on vmnet to make it work on the linux kernel 3.2 and 3.3.

NOTE: If you had used a patch in the past (using the patching script) the installer of VMware workstation/player won’t remove the file which tells the script that the sources are not patched, so, In case you get an error saying that your sources are already patched, remove the file /usr/lib/vmware/modules/source/.patched . This will tell the script that the sources are actually not patched. Another solution is restoring the backup before the upgrade.

You can grab the patch here:

vmware workstation 8.0.2 / player 4.0.2 fix for linux 3.2+

vmware workstation 7.1.5 / player 3.1.5 fix for linux 3.2+ (patch by Ariel)

Attached Files:

Jan 202012

UPDATE: I’ve added a simple bash script which does the first way. Just pass to it the installer name and the arguments you would pass normally. For example in my case I would just do ./ ./ -K –kernel-name=3.3.0-rc1-custom or if you are doing a full install in the current kernel you would just do ./ ./ (rember as root). Enjoy.

Looks like a file, which is needed during the configuration test of the nvidia drivers installer, got moved (and autogenerated see So it’s position is not the same as before, and this breaks the checks showing the classic dialog:

If you are using a Linux 2.4 kernel, please make sure
you either have configured kernel sources matching your
kernel or the correct set of kernel headers installed
on your system.

If you are using a Linux 2.6 kernel, please make sure
you have configured kernel sources matching your kernel
installed on your system. If you specified a separate
output directory using either the “KBUILD_OUTPUT” or
the “O” KBUILD parameter, make sure to specify this
directory with the SYSOUT environment variable or with
the equivalent nvidia-installer command line option.

Depending on where and how the kernel sources (or the
kernel headers) were installed, you may need to specify
their location with the SYSSRC environment variable or
the equivalent nvidia-installer command line option.

There are two ways this can be fixed:

The first way is fixing the nvidia installer side.

Extract the nvidia installer package with -x as argument passed to the sh package then go in the folder it was extracted to (should be /tmp)

Then go to the kernel sub folder and open the search for

CFLAGS=”$CFLAGS -I$SOURCES/arch/x86/include”  and replace it with CFLAGS=”$CFLAGS -I$SOURCES/arch/x86/include -I$SOURCES/arch/x86/include/generated”

this way the files needed for the conftest will be included and it will succeed.

You can use this script to get it done easily. It will cleanup after running the installer so it will look like a normal install.

The second way is hacking a bit the include folders

Go in /lib/modules/<kernelname>/source/arch/x86/include/ and do cp generated/asm/unistd*.h ./asm/

This will copy the required files where they were expected and all will go well.

Enjoy the new kernel with your nvidia drivers!

On a side note this time there are no more patches required for vmware over the ones for 3.2.

Attached Files:

Nov 092011

UPDATE3: If you are looking for patches for 8.0.2+ and 4.0.2+ you might have a look at this post instead as VMware did several changes to their module sources

UPDATE2: I’ve changed the patch to support the weird versioning in the fedora kernels.

UPDATE: I’ve added in the list of supported versions 8.0.1 and 4.0.1 for vmware player, so the script will run with no modifications but remember that when vmware releases a new minor most probably changing the version at the top of the script (or applying the patch manually) will work fine.

New kernel version new issues.

This time can’t blame vmware a lot as some changes were a bit unannounced but I’m not expecting a fix for a long while even after the final release of 3.2.

Anyway this time it was a bit weird iommu api change which changed the iommu_found() to iommu_present(..) with an argument which is a global constant (that’s why it’s weird, maybe the point is making a transition to something more flexible in the future) and the same thing, but without name change, for iommu_domain_alloc(). As a side note this little change can fix also virtualbox builds, which are broken too for the same exact reason. I’m sure they will fix it soon themselves so there is no need of a specific patch, but you could just copy this piece near the top of the file failing to build to fix it:

#include <linux/pci.h>
#define iommu_found() iommu_present(&pci_bus_type)
#define iommu_domain_alloc() iommu_domain_alloc(&pci_bus_type)

The others, instead are specific only to vmware modules: still the network one from the 3.1 patch, some change to the placement of macros for modules, a removed entry in the net device struct and finally something which was described, by who did the change to the kernel, as a way to force people to use an api to access some data (instead of direct access).

You can find the package with the patch and the classic script attached to this post.

For 3.x/7.5.x users probably the patch is similar (provided the 2.6.39 one is applied) but I don’t have the sources right now to compare.

A last remind: you need to apply this to clean sources, so not to patched sources with the linux 3.1 fix (else just remove the part which was patched in 3.1 from this patch).


vmware workstation 8 / player 4 linux 3.2 fix

Attached Files:

Oct 202011

This year was the first year we’ve been in GSOC and it was a great experience. Even if there were some little negative episodes, we had many positives ones too that we didn’t expect. But i’ll probably leave that for another post. Instead I’d like to say that PlaneShift will be at the mentor summit and I’m looking forward to meet the other mentors from all over the globe!

Sep 292011

UPDATE2: I’ve changed the patch to support the weird versioning in the fedora kernels.

UPDATE: I’ve added in the list of supported versions 8.0.1 and 4.0.1 for vmware player, so the script will run with no modifications but remember that when vmware releases a new minor most probably changing the version at the top of the script (or applying the patch manually) will work fine.

Even though vmware just released vmware workstation 8.0 it seems that also this time they didn’t look forward to the kernel which is going to come out in just some weeks. So users again this time will have to rely soon on patches in order to get vmware to work on their linux boxes.

At least this time the fix was quite easier to make.

You can find it here togheter with the script to patch it automatically: vmware8linux31fix.tar

Attached Files:

  • vmware8linux31fix.tar

    Patch and script to fix the build of kernel modules from vmware on linux 3.1 and newer

Aug 102011

UPDATE3: I’ve changed the patch to support the weird versioning in the fedora kernels.

UPDATE2: I’ve added in the list of supported versions 7.1.5 and 3.1.5 for vmware player, so the script will run with no modifications but remember that when vmware releases a new minor most probably changing the version at the top of the script (or applying the patch manually) will work fine.

UPDATE: I’ve added now a full patch starting from clean vmware 7.1.4 sources (together with the patch script for easier use)

This time fixing the kernel modules for vmware was quite simple. It seems some define used to “advertise” the presence of some features in the kernel where removed (in netdevice.h), breaking so the “compatibility” layer of the kernel modules sources of vmware.

So the fix is quite easy. It ends up in just adding those missing defines in the compat_netdevice.h if the kernel version is greater or equal to 3.1.

I’ve attached a patch which is to be applied after the previous one. Later I will probably do a full patch like with the previous one.

Attached Files: