After upgrading to Kernel 2.6.29 the code won't compile anymore. I found the following thread http://communities.vmware.com/message/1194084 at the vmware communities. After applying this patch the ebuild gets installed properly, although I get some complaints about /dev/rtc priveleges from VMware Workstation (the privileges are correct): http://communities.vmware.com/servlet/JiveServlet/download/2835-188410-1149089-18058/vmware-workstation-6.5.1.126130-2.6.29_x86_64.patch Reproducible: Always
Thanks for the bug report, Modules that will build under 2.6.29 are already available in the vmware overlay [1] (which you can get using layman). Please give this a test, and let me know if you encounter any issues. If there are no issues by next week, these modules will be pushed into the main tree... [1] http://overlays.gentoo.org/proj/vmware/browser/trunk/app-emulation/vmware-modules
Overlay works fine, although the RTC issue remains. VMWare Workstation tells me "The host high-resolution timer device (/dev/rtc) is not available (Permission denied). Without this device, the guest operating system can fail to keep time correctly. For more information, see http://vmware.com/info?id=34." % ls -l /dev/rtc lrwxrwxrwx 1 root root 4 Mar 24 13:59 /dev/rtc -> rtc0 % ls -l /dev/rtc0 crw-rw-r-- 1 root wheel 254, 0 Mar 24 13:59 /dev/rtc0 % groups disk wheel [...] I'm not sure if this is a problem with 2.6.29, but before the update the VM didn't complain.
I was able to build vmware-modules from the overlay. So far no problems. Thanks
I can report that vmware-modules-1.0.0.23 from overlay compile on gentoo-sources-2.6.29 and vmware-workstation runs without any problems. I run ~x86. Thank you for the prompt solution.
I have a problem with vmware-server-2.0.0.122956 from the vmware overlay. After updating the kernel to vanilla-sources-2.6.29 and rebuilding vmware-modules and (just in case) vmware-server, and also re-running vmware-config.pl the entire network subsystem and many vmware proceses will freeze after starting the first vm. I'm using bridged network with a dedicated PCI NIC (rtl8169). These are the logs, right after the first log it will freeze the net and keep throwing these entries: Mar 24 22:18:36 ithil bridge-eth1: history full Mar 24 22:18:36 ithil bridge-eth1: history full Mar 24 22:18:41 ithil bridge-eth1: history full [...] I went back to my old kernel (2.6.28.7) and everything is working OK now. Didn't have to reemerge nor reconfigure anything.
Ok, thanks for the heads-up Cristian, I've got no leads as to what could be causing that, but it means these will stay in testing a little longer, until we can get that sorted...
I've been looking and can't find any error related to this in the vmware hostd logs. Looks like a problem with the module or it's relation to the nic driver. I'm using amd64 btw. Let me know if you need any aditional info. Maybe tonight I can try bridging my other nic (Attansic L1) and see if the error shows up, just to be sure it's not driver related.
*** Bug 263768 has been marked as a duplicate of this bug. ***
Like Cristian I'm using bridged networking with an r8169 nic but I'm not seeing any problems here (on ~x86 though) with the vmware-modules from the overlay.
I have bridged networking with r8169 on ~amd64. I have no problems with vmware-modules from the overlay.
Jonathan and jose: Are you using kernel 2.6.29 just like me? It seems weird, I went back to 2.6.28.7 with the same .config and didn't have a single problem since then. The problem is only with 2.6.29
(In reply to comment #11) > Jonathan and jose: Are you using kernel 2.6.29 just like me? Yes, I'm on 2.6.29 vanilla-sources.
(In reply to comment #11) > Jonathan and jose: Are you using kernel 2.6.29 just like me? It seems weird, I > went back to 2.6.28.7 with the same .config and didn't have a single problem > since then. The problem is only with 2.6.29 > Yeah, gentoo-sources-2.6.29 here, on 'complete' ~x86. Did you make oldconfig when you upgraded to 2.6.29? That's what I did, and iirc pretty much well stuck with the defaults for any new kernel options. The only changes I made were 'no' to X86_PTRACE_BITS and adding support for CONFIG_LBD to support an ext4 partition I'm testing.
Ok I switched the vmware bridge from the Realtek 8169 NIC (rtl8169)to the Attansic L1 (atl1) and now it's working fine on 2.6.29 :) It seems there is some compatibility problem with that Realtek network card... weird I always liked it better than the atl1 :P
Hi, don't know if this belongs here (maybe new bug). After switching to 2.6.29 I experience problems reaching my vmware virtual hosts. On my gentoo box I have IP 192.168.204.1 and my vmware virtual machine (RHEL) is NATed with IP 192.168.204.138. When running linux-2.6.28-gentoo-r3 then I'm able to connect from my gentoo box to virtual machine. But when running linux-2.6.29-gentoo then I'm not even able to ping my virtual machine. When I boot back to 2.6.28 then everything is back to normal. I've obtained 2.6.29 kernel config by running make oldconfig. I'm running vmware-modules-1.0.0.23 from vmware overlay. Does anyone have such problem?
bridge-eth1: history full bridge-eth1: history full bridge-eth1: history full Vmware failed again with kernel 2.6.29 and atl1 NIC :( It seems it happens when network activity is high. I started to download a torrent and after a couple of minutes the bridge stopped responding again. Had to switch back to 2.6.28.7 one more time to keep it running stable. Suggestions are welcome. ---- Jan, did you reemerge vmware-modules after starting with 2.6.29?
(In reply to comment #16) > > Jan, did you reemerge vmware-modules after starting with 2.6.29? > Yes I did. Without re-emerging vmware-modules the VMs won't even start.
Today I updated to kernel 2.6.29.1 and now it seems to be working OK. I have a couple of vms running with high network activity for several hours now and didn't get any problems. BTW I checked the changelog for 2.6.29.1 and found this: ------------------------------------------------------------------------- commit 813352bc3317b1104212667ce227a901a8d49908 Author: Stephen Hemminger <shemminger@vyatta.com> Date: Wed Mar 25 21:01:47 2009 -0700 bridge: bad error handling when adding invalid ether address [ Upstream commit cda6d377ec6b2ee2e58d563d0bd7eb313e0165df ] This fixes an crash when empty bond device is added to a bridge. If an interface with invalid ethernet address (all zero) is added to a bridge, then bridge code detects it when setting up the forward databas entry. But the error unwind is broken, the bridge port object can get freed twice: once when ref count went to zeo, and once by kfree. Since object is never really accessible, just free it. Signed-off-by: Stephen Hemminger <shemminger@vyatta.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Chris Wright <chrisw@sous-sol.org> ------------------------------------------------------------------------- I guess that may have been the cause of the error.
(In reply to comment #18) > Today I updated to kernel 2.6.29.1 and now it seems to be working OK. Christian, would you like to try VMware Workstation 6.5.2 build 156735 ? http://bugs.gentoo.org/show_bug.cgi?id=264948
I can confirm that it works well now with: gentoo-sources 2.6.29-r1 (aka 2.6.29.1) vmware-modules from the overlay vmware workstation 6.5.2 no rtc or compile problems anymore
I think I was too quick, today I got the rtc permission error again (ws 6.5.2, gentoo sources 2.6.29-r1)
works from overlay
Marc, rtc permission errors are probably because the vmware group doesn't have write access to /dev/rtc (in fact, I believe only root has that). I'd suggest that's a different problem, since vmware can cope without an rtc device (it may not keep accurate time, but it will run and function without it). If the lack of rtc is a major concern for you, could you please file it as a different bug? This one is specifically about failed compilation. Thanks... 5:)
(In reply to comment #21 & #23) Re: /dev/rtc access problem. I found that this problem goes away if you compile the host kernel with the timer frequency set to 1000Hz. ie., set: CONFIG_HZ_1000 = y More about this is found here: http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=892 Although this is not the appropriate bug for this comment I think it may be helpful to share this info.
The vmware-modules overlay ebuild compiles fine for me, however vmware-workstation-6.5.2-156735 doesn't like the build kernel modules: [...] filename: /lib/modules/2.6.29-gentoo-r1/misc/vmmon.ko supported: external license: GPL v2 description: VMware Virtual Machine Monitor. author: VMware, Inc. depends: vermagic: 2.6.29-gentoo-r1 SMP preempt mod_unload modversions CORE2 VMware Workstation Error: VMware Workstation is installed, but it has not been (correctly) configured for your running kernel. To (re-)configure it, your system administrator must find and run "vmware-config.pl". For more information, please see the VMware Workstation documentation.
Michael, please ensure that the vmware service was started, and that you ran emerge --config vmware-workstation after installation.
Tried both already, doesn't solve my problem though.
Hi Michael, it's not clear what's actually going wrong (save for it producing an uninformative error message). Could you please check that: 1. The machine has no vm* modules loaded. 2. Start the vmware service. 3. Check that the vm* modules are all loaded (you should have vmnet, vmblock, vmci and vmmon). 4. Start vmware and if you're still having problems please post a complete copy of the output from running vmware (and your emerge --info output too). Thanks...
Created attachment 188026 [details] vmware console output I've attached the output log here. The modules seem to load properly, I have no idea why vmware doesn't accept them.
Hiya Michael, the first line of your output suggests that vmware creates a log at /tmp/vmware-root/setup-<something>.log. Could you please check the output from that and let me know if there's anything else going on. The rest of your output (save for the need to configure) is identical to my working setup...
the log is of no use, this is all that's printed there: Apr 13 15:08:54.760: app| Log for VMware Workstation pid=7089 version=6.5.2 build=build-156735 option=Release Apr 13 15:08:54.760: app| Host codepage=UTF-8 encoding=UTF-8 Apr 13 15:08:54.760: app| Logging to /tmp/vmware-root/setup-7089.log
Michael, disable the Module Versioning support in the kernel, recompile it, install it, reboot and reinstall vmware-modules again. I had problems with that kernel setting and VMWare. Let me know if that helped. If it does help then it would be nice to check that setting during installation.
I figured it out: the problem is a file called /etc/vmware/not_configured Whenever this file exists, vmware will pretend it's not configured properly. After removing this file, vmware accepts the modules and works as expected without errors.
*** Bug 266795 has been marked as a duplicate of this bug. ***
*** Bug 269777 has been marked as a duplicate of this bug. ***
Several vmware packages were recently added to the main portage tree with a dependency on ~vmware-modules-1.0.0.23. So now people with any of them in their world file and a recent kernel will encounter this issue. Furthermore, the security bug 265139 seems to be a good reason why people would want to update to these packages as soon as possible. Therefore having a modules package in the portage tree which actually compiles against kernel 2.6.29 would be nice. Latest comments above sound good to me. If you believe it really isn't ready for ~ARCH yet (as 2.6.29 is still in ~ARCH, so this whole issue won't affect stable users in any case), you might specify all major 2.6.29 kernel packages as blockers, so that portage will find the problem and users won't have to wait for the ebuild to start and fail and then search for this bug here.
Ok, I just pushed vmware-modules to the main tree and left the vmware herd. Please don't CC me to any vmware bugs, I'll just un-CC myself. Hopefully a new dev will be along sometime soon to look after you all...
(In reply to comment #37) > Ok, I just pushed vmware-modules to the main tree and left the vmware herd. > Please don't CC me to any vmware bugs, I'll just un-CC myself. Hopefully a new > dev will be along sometime soon to look after you all... Mike, STOP ! , hold on ! , reconsider, *PLEASE* !!! To everybody else: The last *stable* kernel releases in tree are: . . . sys-kernel/gentoo-sources-2.6.27-r8 . . . sys-kernel/vanilla-sources-2.6.27.10 . . . sys-kernel/vanilla-sources-2.6.28.9 . . . Notabene: 2.6.27 == "long-term edition" by Adrian Bunk Everything beyond that is *development*. Thus: - You first of all have to *read*, - you might participate in *development*, - or wait patiently, - or ask VMware ;( - or look at any other distribution's stage of suport ... Mike, considering the really horrible situation with VMware's "input" / "support" / deliveries, I really think that every non-construktive request (esp. "complaint-only") should resolutely be reprimanded via reference to 'unstable' - and simply be done with it: . . . grep -v "patch" >> /dev/null ;) Kind regards Respectfully yours Manfred
I'm sorry if my last comment gave the wrong impression. There's no one person or particular reason for my leaving the vmware herd, I've simply been doing it too long and been unable to help with too many bugs, and I really desperately need a long break from it, which I'm now taking. I hope that clears up any misunderstandings that might have occurred...
(ADDENDUM to comment #38) VMware states it's stage of suport for distributions at: http://pubs.vmware.com/ws65_ace25/ws_user/wwhelp/wwhimpl/common/html/wwhelp.htm?context=ws_user&file=intro_sysreqs_ws.html ( perhaps not so easy to find). Examplum Gratia: - OpenSuse (latest release: 11.1 <-- 2.6.27 ) : - - supported:......10.2 ( 2.6.18 ) <--- - - experimental:...10.3 ( 2.6.22 ) I'm really grateful to all that have contributed enabling Gentoo to run e.g. current VMware Workstation 6.5.2 build 156735 under - - - - - - - - - - - - - - 2.6.28 <--- Thank you *very* much.
ping to any maintainers... 2.6.29 is planned to go stable on 23rd may, would be nice to see this fixed
*** Bug 271997 has been marked as a duplicate of this bug. ***
I've commited new vmware-modules ebuild to portage tree. It has patches for 2.6.29 and 2.6.30.
I wasn't the reporter so I can't reopen this bug, but for me this does not build with 2.26.30: /var/tmp/paludis/app-emulation-vmware-modules-1.0.0.24/work/vmnet-only/netif.c: In function 'VNetNetIfSetup': /var/tmp/paludis/app-emulation-vmware-modules-1.0.0.24/work/vmnet-only/netif.c:225: error: 'struct net_device' has no member named 'init' /var/tmp/paludis/app-emulation-vmware-modules-1.0.0.24/work/vmnet-only/netif.c:226: error: 'struct net_device' has no member named 'open' /var/tmp/paludis/app-emulation-vmware-modules-1.0.0.24/work/vmnet-only/netif.c:227: error: 'struct net_device' has no member named 'hard_start_xmit' /var/tmp/paludis/app-emulation-vmware-modules-1.0.0.24/work/vmnet-only/netif.c:228: error: 'struct net_device' has no member named 'stop' /var/tmp/paludis/app-emulation-vmware-modules-1.0.0.24/work/vmnet-only/netif.c:229: error: 'struct net_device' has no member named 'get_stats' /var/tmp/paludis/app-emulation-vmware-modules-1.0.0.24/work/vmnet-only/netif.c:230: error: 'struct net_device' has no member named 'set_mac_address' /var/tmp/paludis/app-emulation-vmware-modules-1.0.0.24/work/vmnet-only/netif.c:231: error: 'struct net_device' has no member named 'set_multicast_list' make[3]: *** [/var/tmp/paludis/app-emulation-vmware-modules-1.0.0.24/work/vmnet-only/netif.o] Error 1 make[2]: *** [_module_/var/tmp/paludis/app-emulation-vmware-modules-1.0.0.24/work/vmnet-only] Error 2 make[1]: *** [sub-make] Error 2 make[1]: Leaving directory `/usr/src/linux-2.6.30' make: *** [vmnet.ko] Error 2 /usr/libexec/paludis/utils/emake: emake returned error 2
Created attachment 194881 [details] Build log for vmware-modules-1.0.0.24 w/2.26.30
Created attachment 194882 [details] Output of paludis --info vmware-modules
(In reply to comment #44) Please see Bug 274173
