CONFIG_BKL does not exist anymore w/ 2.6.39 Found a patch at http://weltall.heliohost.org/wordpress/2011/05/14/running-vmware-workstation-player-on-linux-2-6-39-updated/ Attached my diff for a new ebuild and the patch. Reproducible: Always
Created attachment 274083 [details, diff] diff vmware-modules-238.4.ebuild diff -Nur vmware-modules-238.4.ebuild /usr/portage/app-emulation/vmware-modules/vmware-modules-238.4.ebuild
Created attachment 274085 [details, diff] patch to remove BKL patch from http://weltall.heliohost.org/wordpress/2011/05/14/running-vmware-workstation-player-on-linux-2-6-39-updated/
Thanks for the patch, confirmed to compile and work. For your ebuild diff you should only apply the patch if "kernel_is ge 2 6 39", and also keep the CONFIG_BLK check for 2.6.37 and 2.6.38.
Thanks for making this patch. I applied the patch to the vmware-modules-238.4.ebuild file. Also, as per Comment #3 below, I modified it slightly so that it checks the kernel version number first. The BKL check is preserved for 2.6.37 and 2.6.38, and the new patch file is only applied for 2.6.39. Attaching the ebuild file to this bug. Josh
Created attachment 274245 [details] The modified ebuild file from Comment 4, applies the patch
(In reply to comment #4) > Also, as per Comment #3 below, I modified it slightly so that it checks the > kernel version number first. > > The BKL check is preserved for 2.6.37 and 2.6.38, and the new patch file is > only applied for 2.6.39. Thanks to both of you, you are obviously right with your suggestions.
Is there an easy way to get this to work with vmware-modules-208.2?
Stefan: I don't think so. VMware's support for new kernel versions was a very late addition, starting with the latest 7.1.4 release. Also, wouldn't it make more sense to want to run with the bleeding-edge latest VMware modules, if already choosing to run the bleeding-edge latest 2.6.39 kernel?
Krellan: unfortunately I'm running vmware-server-2.0.2.203138-r4 on my server machine, and that package does not run with the 238.x modules, as those modules require vmware-player which block with the server.
At the people already using this ebuild: Do you notice any change in performance in your VMs? My VM here seems slower ... could be related to changes inside the VM ... Thanks for feedback, Stefan
I have added the ebuild plus patch to my overlay at http://git.overlays.gentoo.org/gitweb/?p=user/seden.git (available via [i]layman -a seden[/i]) and am currently updating to 2.6.39 to test the ebuild and the patch.
I have tested the ebuild and the patches, and everything is up and running fine. Stefan, neither my virtual Gentoo Cluster, nor my Windows XP dev machine seem to run with different speed or responsiveness.
So, does this mean there's no way to run vmware-server 2.0 with a 2.6.39+ kernel anymore?
(In reply to comment #13) > So, does this mean there's no way to run vmware-server 2.0 with a 2.6.39+ > kernel anymore? Maybe someone can patch the old modules. VMware has ditched vmware-server ages ago for vSphere I'm afraid. They still have the server section in their products list, but the description closes with a chapter about how to migrate from server to vSphere.
(In reply to comment #2) > Created attachment 274085 [details, diff] > patch to remove BKL > > patch from > http://weltall.heliohost.org/wordpress/2011/05/14/running-vmware-workstation-player-on-linux-2-6-39-updated/ This patch produces a warning: /var/tmp/portage/app-emulation/vmware-modules-238.4-r1/work/vmblock-only/linux/dentry.c:107:4: warning: passing argument 3 of 'kern_path' from incompatible pointer type include/linux/namei.h:76:12: note: expected 'struct path *' but argument is of type 'struct nameidata *' I have modified patch in vmware overlay. Thanks.
(In reply to comment #15) > (In reply to comment #2) > > Created attachment 274085 [details, diff] > > patch to remove BKL > > > > patch from > > http://weltall.heliohost.org/wordpress/2011/05/14/running-vmware-workstation-player-on-linux-2-6-39-updated/ > > This patch produces a warning: > /var/tmp/portage/app-emulation/vmware-modules-238.4-r1/work/vmblock-only/linux/dentry.c:107:4: > warning: passing argument 3 of 'kern_path' from incompatible pointer type > include/linux/namei.h:76:12: note: expected 'struct path *' but argument is of > type 'struct nameidata *' > > I have modified patch in vmware overlay. > > Thanks. Thanks a lot! I have taken the ebuild and (old) patch out of my overlay. "vmware" is the far better overlay for that! ;-)
Any reason to hide this fix in an overlay?
Hide? At the top of this bug is everything "unhidden"! ;-)
Main portage tree ~arch is broken with 2.6.39 gentoo-sources existing long ago is what I mean of course, while vadimk is a fellow gentoo dev touching/maintaining vmware-modules in main tree...
*** Bug 373471 has been marked as a duplicate of this bug. ***
Patch and modified ebuild works. Please commit this to the main tree. It's annoying to have to maintain this in the local overlay.
BUG #373471 was marked as a duplicate of this one, but I'm not sure that should be the case. This bug is for the modules that go with vmware-workstation-7.0, but the other bug is for vmware-modules-1.0.0.25-r4 which is for vmware-workstation-6.5.5. I have seen a patch for 6.5.5 here: http://communities.vmware.com/message/1784494
Thanks for the link, I used it to create a patch for the 10.0.0.25 version (see bug #375461).
*** Bug 376641 has been marked as a duplicate of this bug. ***
Thanks to all it worsks! Perhaps could it put in official portage?
*** Bug 382335 has been marked as a duplicate of this bug. ***
Good news: The vmware-modules version in Portage has been updated to 238.5, not 238.4 anymore. The new 238.5 is now compatible with 2.6.39 and 3.0.0 kernels. Bad news: Kernel 3.1.0 broke it again, and now 238.5 doesn't compile. The bug is similar, but for updated versions of both vmware-modules and the kernel gentoo-sources. Should a new bug be opened for 3.1.0, or should this current bug keep being extended?
Great news, somebody else already came up with a patch that will fix the problem for 3.1.0 kernel. I wrote about it here: http://forums.gentoo.org/viewtopic-p-6857414.html Any chance of getting this into the Portage tree?
(In reply to comment #28) > Great news, somebody else already came up with a patch that will fix the > problem for 3.1.0 kernel. > > I wrote about it here: http://forums.gentoo.org/viewtopic-p-6857414.html > > Any chance of getting this into the Portage tree? Just as feedback: works here.
i believe this bug is fixed in the tree. thanks.