Menu
▾
▴
open-vm-tools-devel — List for open-vm-tools developer discussions.
You can subscribe to this list here.
| 2007 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(30) |
Oct
(50) |
Nov
(42) |
Dec
(17) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2008 |
Jan
(36) |
Feb
(13) |
Mar
(74) |
Apr
(17) |
May
(62) |
Jun
(53) |
Jul
(32) |
Aug
(58) |
Sep
(44) |
Oct
(21) |
Nov
(35) |
Dec
(53) |
| 2009 |
Jan
(43) |
Feb
(58) |
Mar
(14) |
Apr
(16) |
May
(61) |
Jun
(49) |
Jul
(11) |
Aug
(22) |
Sep
(37) |
Oct
(12) |
Nov
(23) |
Dec
(10) |
| 2010 |
Jan
(21) |
Feb
(13) |
Mar
(5) |
Apr
(18) |
May
(14) |
Jun
(10) |
Jul
(1) |
Aug
|
Sep
(13) |
Oct
(8) |
Nov
(11) |
Dec
(14) |
| 2011 |
Jan
(13) |
Feb
(19) |
Mar
(16) |
Apr
(10) |
May
(22) |
Jun
(4) |
Jul
(63) |
Aug
(14) |
Sep
(10) |
Oct
(12) |
Nov
(10) |
Dec
(43) |
| 2012 |
Jan
(3) |
Feb
(4) |
Mar
(35) |
Apr
(1) |
May
(32) |
Jun
(8) |
Jul
(10) |
Aug
(6) |
Sep
(3) |
Oct
(25) |
Nov
(14) |
Dec
(4) |
| 2013 |
Jan
(12) |
Feb
(6) |
Mar
(15) |
Apr
(24) |
May
(9) |
Jun
(2) |
Jul
|
Aug
(4) |
Sep
|
Oct
(8) |
Nov
(3) |
Dec
|
| 2014 |
Jan
(5) |
Feb
|
Mar
(4) |
Apr
(2) |
May
(4) |
Jun
|
Jul
(4) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(3) |
| 2015 |
Jan
|
Feb
(5) |
Mar
|
Apr
(1) |
May
(3) |
Jun
(1) |
Jul
(2) |
Aug
(5) |
Sep
|
Oct
|
Nov
(2) |
Dec
|
| 2017 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: SourceForge.net <no...@so...> - 2011-08-26 22:50:52
|
Tracker item #3398994, was opened at 2011-08-26 21:34 Message generated for change (Comment added) made by You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=989708&aid=3398994&group_id=204462 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: libraries Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: https://www.google.com/accounts () Assigned to: Nobody/Anonymous (nobody) Summary: FreeBSD 'make install' failure Initial Comment: open-vm-tools-2011.08.21-471295 FreeBSD 8.2 automake 1.11.1 autoconf 2.68 libtool 2.4 (See full log of 'make install' in the attachment.) % pwd # build directory /usr/local/opt/samba/tmp/open-vm-tools-2011.08.21-471295 % ./configure --prefix=`pwd`/1 --without-procps --disable-unity % patch -p0 < /usr/ports/emulators/open-vm-tools/files/patch-freebsd-8 % make # builds fine % make install # FAILS [...] libtool: relink: gcc -shared .libs/libhgfs_la-hgfslib.o -Wl,--whole-archive ../lib/hgfs/.libs/libHgfs.a ../lib/hgfsHelper/.libs/libHgfsHelper.a ../lib/hgfsServer/.libs/libHgfsServer.a ../lib/hgfsServerManagerGuest/.libs/libHgfsServerManagerGuest.a ../lib/hgfsServerPolicyGuest/.libs/libHgfsServerPolicyGuest.a -Wl,--no-whole-archive -Wl,-rpath -Wl,/usr/local/lib -Wl,-rpath -Wl,/usr/local/opt/samba/tmp/open-vm-tools-2011.08.21-471295/1/lib -L/usr/local/lib -lgthread-2.0 -L/usr/local/opt/samba/tmp/open-vm-tools-2011.08.21-471295/1/lib -lvmtools -lglib-2.0 -Wl,-z -Wl,defs -Wl,-lc -pthread -pthread -Wl,-soname -Wl,libhgfs.so.0 -o .libs/libhgfs.so.0 ../lib/hgfsServer/.libs/libHgfsServer.a(hgfsServer.o)(.text+0x564): In function `HgfsIsCached': /usr/local/opt/samba/tmp/open-vm-tools-2011.08.21-471295/lib/hgfsServer/hgfsServer.c:4963: undefined reference to `MXUser_AcquireExclLock' [...] libtool: install: error: relink `libhgfs.la' with the above command before installing it *** Error code 1 Stop in /usr/local/opt/samba/tmp/open-vm-tools-2011.08.21-471295/libhgfs. ---------------------------------------------------------------------- >Comment By: https://www.google.com/accounts () Date: 2011-08-26 22:50 Message: @mvanzin This is a local drive. Running autoreconf didn't help. nm output is: 00019d30 t MXUserAcquisition 0001b010 T MXUserAcquisitionSample 0001b750 T MXUserAcquisitionStatsSetUp 0001b5b0 T MXUserAcquisitionStatsTearDown 0001be20 T MXUserAddToList 0001b260 T MXUserAllocSerialNumber 0001af80 T MXUserBasicStatsSample 0001b6b0 T MXUserBasicStatsSetUp 0001b570 T MXUserBasicStatsTearDown 00017b10 T MXUserCreateCondVar 00018b50 t MXUserCreateRecLock 0001a2f0 t MXUserDown 0001b4c0 T MXUserDumpAcquisitionStats 000176c0 T MXUserDumpAndPanic 0001adc0 t MXUserDumpBarrier 0001b2c0 T MXUserDumpBasicStats 00017fc0 t MXUserDumpExclLock 00019970 T MXUserDumpRWLock 00018750 t MXUserDumpRecLock 0001a910 T MXUserDumpSemaphore 0001bc90 T MXUserForceHisto 00019280 t MXUserFreeHashEntry 000192b0 t MXUserGetHolderContext 0001b7d0 T MXUserHistoDump 0001ba10 T MXUserHistoSample 0001bb80 T MXUserHistoSetUp 0001b5e0 T MXUserHistoTearDown 00017620 T MXUserInstallMxHooks 00017710 T MXUserInternalSingleton 0001b0b0 T MXUserKitchen 0005d0e4 B MXUserMX_IsLockedByCurThreadRec 0005d0d8 B MXUserMX_LockRec 0005d0e0 B MXUserMX_TryLockRec 0005d0dc B MXUserMX_UnlockRec 0005d0ec b MXUserMxCheckRank 0005d0e8 b MXUserMxLockLister 00019400 t MXUserNativeRWDestroy 0001bf00 T MXUserRemoveFromList 00018090 t MXUserStatsActionExcl 00019820 t MXUserStatsActionRW 00018ce0 t MXUserStatsActionRec 0001a430 t MXUserStatsActionSema 0001b230 T MXUserStatsEnabled 0001b280 t MXUserStatsLog 0001a200 t MXUserTimedDown 0005d0d4 B MXUserTryAcquireForceFail 0001a1a0 t MXUserTryDown 00017920 T MXUserWaitCondVar 00018470 T MXUser_AcquireExclLock 0001a180 T MXUser_AcquireForRead 0001a170 T MXUser_AcquireForWrite 000190e0 T MXUser_AcquireRecLock 00018670 T MXUser_BindMXMutexRec 00017860 T MXUser_BroadcastCondVar 00017d20 T MXUser_ControlExclLock 00019530 T MXUser_ControlRWLock 000189e0 T MXUser_ControlRecLock 0001ac60 T MXUser_CreateBarrier 00017c20 T MXUser_CreateCondVarExclLock 000188e0 T MXUser_CreateCondVarRecLock 00017e80 T MXUser_CreateExclLock 00019690 T MXUser_CreateRWLock 00018ca0 T MXUser_CreateRecLock 00018cc0 T MXUser_CreateRecLockSilent 0001a730 T MXUser_CreateSemaphore 0001af00 T MXUser_CreateSingletonBarrier 000183c0 T MXUser_CreateSingletonExclLock 00019a50 T MXUser_CreateSingletonRWLock 00018e30 T MXUser_CreateSingletonRecLock 0001a8a0 T MXUser_CreateSingletonSemaphore 0001abc0 T MXUser_DestroyBarrier 000177e0 T MXUser_DestroyCondVar 00017c50 T MXUser_DestroyExclLock 00019420 T MXUser_DestroyRWLock 00018910 T MXUser_DestroyRecLock 0001a330 T MXUser_DestroySemaphore 0001a610 T MXUser_DownSemaphore 00018850 T MXUser_DumpRecLock 0001ab20 T MXUser_EnterBarrier 00018660 T MXUser_GetRecLockRank 00018650 T MXUser_GetRecLockVmm 00017600 T MXUser_InPanic 00018430 T MXUser_IsCurThreadHoldingExclLock 00019370 T MXUser_IsCurThreadHoldingRWLock 00018f50 T MXUser_IsCurThreadHoldingRecLock 0001bd00 T MXUser_PerLockData 000181e0 T MXUser_ReleaseExclLock 00019ac0 T MXUser_ReleaseRWLock 00018fb0 T MXUser_ReleaseRecLock 000175e0 T MXUser_SetInPanic 0001b630 T MXUser_SetStatsFunc 000178c0 T MXUser_SignalCondVar 0001b200 T MXUser_StatisticsControl 0001a9d0 T MXUser_TimedDownSemaphore 00017ba0 T MXUser_TimedWaitCondVarExclLock 00018860 T MXUser_TimedWaitCondVarRecLock 00018300 T MXUser_TryAcquireExclLock 00018ea0 T MXUser_TryAcquireRecLock 0001a580 T MXUser_TryDownSemaphore 0001a510 T MXUser_UpSemaphore 00017be0 T MXUser_WaitCondVarExclLock 000188a0 T MXUser_WaitCondVarRecLock ---------------------------------------------------------------------- Comment By: Marcelo Vanzin (mvanzin) Date: 2011-08-26 22:00 Message: This works for me on FreeBSD 7.1. Few questions: . is /usr/local/opt/samba/tmp/open-vm-tools-2011.08.21-471295 a local or remote drive? If it's remote could you try a local one? . could you try running "autoreconf" before running configure? . what's the output of: nm -C /usr/local/opt/samba/tmp/open-vm-tools-2011.08.21-471295/1/lib/libvmtools.so | grep MXUser I see that symbol (as a 'T' = exported symbol) in my build. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=989708&aid=3398994&group_id=204462 |
|
From: SourceForge.net <no...@so...> - 2011-08-26 22:00:19
|
Tracker item #3398994, was opened at 2011-08-26 14:34 Message generated for change (Comment added) made by mvanzin You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=989708&aid=3398994&group_id=204462 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: libraries Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: https://www.google.com/accounts () Assigned to: Nobody/Anonymous (nobody) Summary: FreeBSD 'make install' failure Initial Comment: open-vm-tools-2011.08.21-471295 FreeBSD 8.2 automake 1.11.1 autoconf 2.68 libtool 2.4 (See full log of 'make install' in the attachment.) % pwd # build directory /usr/local/opt/samba/tmp/open-vm-tools-2011.08.21-471295 % ./configure --prefix=`pwd`/1 --without-procps --disable-unity % patch -p0 < /usr/ports/emulators/open-vm-tools/files/patch-freebsd-8 % make # builds fine % make install # FAILS [...] libtool: relink: gcc -shared .libs/libhgfs_la-hgfslib.o -Wl,--whole-archive ../lib/hgfs/.libs/libHgfs.a ../lib/hgfsHelper/.libs/libHgfsHelper.a ../lib/hgfsServer/.libs/libHgfsServer.a ../lib/hgfsServerManagerGuest/.libs/libHgfsServerManagerGuest.a ../lib/hgfsServerPolicyGuest/.libs/libHgfsServerPolicyGuest.a -Wl,--no-whole-archive -Wl,-rpath -Wl,/usr/local/lib -Wl,-rpath -Wl,/usr/local/opt/samba/tmp/open-vm-tools-2011.08.21-471295/1/lib -L/usr/local/lib -lgthread-2.0 -L/usr/local/opt/samba/tmp/open-vm-tools-2011.08.21-471295/1/lib -lvmtools -lglib-2.0 -Wl,-z -Wl,defs -Wl,-lc -pthread -pthread -Wl,-soname -Wl,libhgfs.so.0 -o .libs/libhgfs.so.0 ../lib/hgfsServer/.libs/libHgfsServer.a(hgfsServer.o)(.text+0x564): In function `HgfsIsCached': /usr/local/opt/samba/tmp/open-vm-tools-2011.08.21-471295/lib/hgfsServer/hgfsServer.c:4963: undefined reference to `MXUser_AcquireExclLock' [...] libtool: install: error: relink `libhgfs.la' with the above command before installing it *** Error code 1 Stop in /usr/local/opt/samba/tmp/open-vm-tools-2011.08.21-471295/libhgfs. ---------------------------------------------------------------------- >Comment By: Marcelo Vanzin (mvanzin) Date: 2011-08-26 15:00 Message: This works for me on FreeBSD 7.1. Few questions: . is /usr/local/opt/samba/tmp/open-vm-tools-2011.08.21-471295 a local or remote drive? If it's remote could you try a local one? . could you try running "autoreconf" before running configure? . what's the output of: nm -C /usr/local/opt/samba/tmp/open-vm-tools-2011.08.21-471295/1/lib/libvmtools.so | grep MXUser I see that symbol (as a 'T' = exported symbol) in my build. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=989708&aid=3398994&group_id=204462 |
|
From: SourceForge.net <no...@so...> - 2011-08-26 21:34:04
|
Tracker item #3398994, was opened at 2011-08-26 21:34 Message generated for change (Tracker Item Submitted) made by You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=989708&aid=3398994&group_id=204462 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: libraries Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: https://www.google.com/accounts () Assigned to: Nobody/Anonymous (nobody) Summary: FreeBSD 'make install' failure Initial Comment: open-vm-tools-2011.08.21-471295 FreeBSD 8.2 automake 1.11.1 autoconf 2.68 libtool 2.4 (See full log of 'make install' in the attachment.) % pwd # build directory /usr/local/opt/samba/tmp/open-vm-tools-2011.08.21-471295 % ./configure --prefix=`pwd`/1 --without-procps --disable-unity % patch -p0 < /usr/ports/emulators/open-vm-tools/files/patch-freebsd-8 % make # builds fine % make install # FAILS [...] libtool: relink: gcc -shared .libs/libhgfs_la-hgfslib.o -Wl,--whole-archive ../lib/hgfs/.libs/libHgfs.a ../lib/hgfsHelper/.libs/libHgfsHelper.a ../lib/hgfsServer/.libs/libHgfsServer.a ../lib/hgfsServerManagerGuest/.libs/libHgfsServerManagerGuest.a ../lib/hgfsServerPolicyGuest/.libs/libHgfsServerPolicyGuest.a -Wl,--no-whole-archive -Wl,-rpath -Wl,/usr/local/lib -Wl,-rpath -Wl,/usr/local/opt/samba/tmp/open-vm-tools-2011.08.21-471295/1/lib -L/usr/local/lib -lgthread-2.0 -L/usr/local/opt/samba/tmp/open-vm-tools-2011.08.21-471295/1/lib -lvmtools -lglib-2.0 -Wl,-z -Wl,defs -Wl,-lc -pthread -pthread -Wl,-soname -Wl,libhgfs.so.0 -o .libs/libhgfs.so.0 ../lib/hgfsServer/.libs/libHgfsServer.a(hgfsServer.o)(.text+0x564): In function `HgfsIsCached': /usr/local/opt/samba/tmp/open-vm-tools-2011.08.21-471295/lib/hgfsServer/hgfsServer.c:4963: undefined reference to `MXUser_AcquireExclLock' [...] libtool: install: error: relink `libhgfs.la' with the above command before installing it *** Error code 1 Stop in /usr/local/opt/samba/tmp/open-vm-tools-2011.08.21-471295/libhgfs. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=989708&aid=3398994&group_id=204462 |
|
From: Marcelo V. <mv...@vm...> - 2011-08-11 17:22:26
|
Hi Joakim, On 08/10/2011 11:21 PM, Joakim Reck wrote: > This file contains any messages produced by compilers while > running configure, to aid debugging if configure makes a mistake. So, do you actually have a question? The error below seems clear to me: you don't have the FreeBSD kernel sources installed on your system. They're needed to compile the kernel modules. You can disable that using the recommended option if you don't want to install the kernel sources. > configure:3018: error: FreeBSD kernel tree not found. Please install the kernel sources (or provide the location using SYSDIR) or configure using --without-kernel-modules. -- - Marcelo |
|
From: Joakim R. <jo...@mn...> - 2011-08-11 06:55:26
|
This file contains any messages produced by compilers while running configure, to aid debugging if configure makes a mistake. It was created by open-vm-tools configure 2010.10.18, which was generated by GNU Autoconf 2.65. Invocation command line was $ ./configure --without-procps --sysconfdir=/usr/local/etc --disable-unity --with-x --x-libraries=/usr/local/lib --x-includes=/usr/local/include --prefix=/usr/local --mandir=/usr/local/man --infodir=/usr/loca ## --------- ## ## Platform. ## ## --------- ## hostname = www5.mn2m.com uname -m = i386 uname -r = 8.2-RELEASE uname -s = FreeBSD uname -v = FreeBSD 8.2-RELEASE #0: Fri Feb 18 02:24:46 UTC 2011 ro...@al...:/usr/obj/usr/src/sys/GENERIC /usr/bin/uname -p = i386 /bin/uname -X = unknown /bin/arch = unknown /usr/bin/arch -k = unknown /usr/convex/getsysinfo = unknown /usr/bin/hostinfo = unknown /bin/machine = unknown /usr/bin/oslevel = unknown /bin/universe = unknown PATH: /sbin PATH: /bin PATH: /usr/sbin PATH: /usr/bin PATH: /usr/games PATH: /usr/local/sbin PATH: /usr/local/bin PATH: /root/bin ## ----------- ## ## Core tests. ## ## ----------- ## configure:2851: checking build system type configure:2865: result: i386-portbld-freebsd8.2 configure:2885: checking host system type configure:2898: result: i386-undermydesk-freebsd configure:3018: error: FreeBSD kernel tree not found. Please install the kernel sources (or provide the location using SYSDIR) or configure using --without-kernel-modules. ## ---------------- ## ## Cache variables. ## ## ---------------- ## ac_cv_build=i386-portbld-freebsd8.2 ac_cv_env_CCC_set='' ac_cv_env_CCC_value='' ac_cv_env_CC_set=set ac_cv_env_CC_value=cc ac_cv_env_CFLAGS_set=set ac_cv_env_CFLAGS_value='-O2 -pipe -fno-strict-aliasing' ac_cv_env_CPPFLAGS_set=set ac_cv_env_CPPFLAGS_value=-I/usr/local/include ac_cv_env_CPP_set=set ac_cv_env_CPP_value=cpp ac_cv_env_CXXCPP_set='' ac_cv_env_CXXCPP_value='' ac_cv_env_CXXFLAGS_set=set ac_cv_env_CXXFLAGS_value='-O2 -pipe -fno-strict-aliasing' ac_cv_env_CXX_set=set ac_cv_env_CXX_value=c++ ac_cv_env_LDFLAGS_set=set ac_cv_env_LDFLAGS_value=-L/usr/local/lib ac_cv_env_LIBS_set='' ac_cv_env_LIBS_value='' ac_cv_env_XMKMF_set='' ac_cv_env_XMKMF_value='' ac_cv_env_build_alias_set=set ac_cv_env_build_alias_value=i386-portbld-freebsd8.2 ac_cv_env_host_alias_set='' ac_cv_env_host_alias_value='' ac_cv_env_target_alias_set='' ac_cv_env_target_alias_value='' ac_cv_host=i386-undermydesk-freebsd lt_cv_sys_max_cmd_len=262144 ## ----------------- ## ## Output variables. ## ## ----------------- ## ACLOCAL='' AMDEPBACKSLASH='' AMDEP_FALSE='' AMDEP_TRUE='' AMTAR='' AR='' AUTOCONF='' AUTOHEADER='' AUTOMAKE='' AWK='' BUILD_HGFSMOUNTER_FALSE='' BUILD_HGFSMOUNTER_TRUE='' CC='cc' CCDEPMODE='' CFLAGS='-O2 -pipe -fno-strict-aliasing' COMMON_PLUGIN_INSTALLDIR='' COMMON_XLIBS='' CPP='cpp' CPPFLAGS='-I/usr/local/include' CUNIT_CPPFLAGS='' CUNIT_LIBS='' CXX='c++' CXXCPP='' CXXDEPMODE='' CXXFLAGS='-O2 -pipe -fno-strict-aliasing' CYGPATH_W='' DEFS='' DEPDIR='' DNET_CPPFLAGS='' DNET_LIBS='' DOT='' DSYMUTIL='' DUMPBIN='' ECHO_C='' ECHO_N='-n' ECHO_T='' EGREP='' ENABLE_TESTS_FALSE='' ENABLE_TESTS_TRUE='' ENABLE_UNITY_FALSE='' ENABLE_UNITY_TRUE='' EXEEXT='' FGREP='' FREEBSD_CUSTOM_SYSDIR_FALSE='' FREEBSD_CUSTOM_SYSDIR_TRUE='' FREEBSD_FALSE='' FREEBSD_TRUE='' FUSE_CPPFLAGS='' FUSE_LIBS='' GIO_CPPFLAGS='' GIO_LIBS='' GLIB2_CPPFLAGS='' GLIB2_LIBS='' GMODULE_CPPFLAGS='' GMODULE_LIBS='' GOBJECT_CPPFLAGS='' GOBJECT_LIBS='' GREP='' GTHREAD_CPPFLAGS='' GTHREAD_LIBS='' GTKMM_CPPFLAGS='' GTKMM_LIBS='' GTK_CPPFLAGS='' GTK_LIBS='' HAVE_DNET_FALSE='' HAVE_DNET_TRUE='' HAVE_DOT='' HAVE_DOXYGEN_FALSE='' HAVE_DOXYGEN_TRUE='' HAVE_FUSE_FALSE='' HAVE_FUSE_TRUE='' HAVE_GNU_LD_FALSE='' HAVE_GNU_LD_TRUE='' HAVE_GTKMM_FALSE='' HAVE_GTKMM_TRUE='' HAVE_ICU_FALSE='' HAVE_ICU_TRUE='' HAVE_PAM_FALSE='' HAVE_PAM_TRUE='' HAVE_PKG_CONFIG='' HAVE_X11_FALSE='' HAVE_X11_TRUE='' HGFS_LIBS='' ICU_CPPFLAGS='' ICU_LIBS='' INSTALL_DATA='install -o root -g wheel -m 444' INSTALL_PROGRAM='install -s -o root -g wheel -m 555' INSTALL_SCRIPT='install -o root -g wheel -m 555' INSTALL_STRIP_PROGRAM='' KERNEL_RELEASE='8.2-RELEASE' LD='' LDFLAGS='-L/usr/local/lib' LIBOBJS='' LIBPNG_CPPFLAGS='' LIBPNG_LIBS='' LIBS='' LIBTOOL='' LIBVMTOOLS_LIBADD='' LIB_AUTH_CPPFLAGS='' LIB_IMPERSONATE_CPPFLAGS='' LIB_USER_CPPFLAGS='' LINUX_FALSE='' LINUX_TRUE='' LIPO='' LN_S='' LTLIBOBJS='' MAKEINFO='' MKDIR_P='' MODULES='' MODULES_DIR='' MODULES_OS='' MSCGEN='' MSCGEN_DIR='' NM='' NMEDIT='' OBJDUMP='' OBJEXT='' OTOOL64='' OTOOL='' PACKAGE='' PACKAGE_BUGREPORT='ope...@li...' PACKAGE_NAME='open-vm-tools' PACKAGE_STRING='open-vm-tools 2010.10.18' PACKAGE_TARNAME='open-vm-tools' PACKAGE_URL='' PACKAGE_VERSION='2010.10.18' PAM_CPPFLAGS='' PAM_LIBS='' PAM_PREFIX='' PATH_SEPARATOR=':' PLUGIN_CPPFLAGS='' PLUGIN_LDFLAGS='' PROCPS_CPPFLAGS='' PROCPS_LIBS='' RANLIB='' RPCGEN='' RPCGENFLAGS='' SED='' SET_MAKE='' SHELL='/bin/sh' SOLARIS_FALSE='' SOLARIS_TRUE='' STRIP='' SYSDIR='' TARGET_OS='' TEST_PLUGIN_INSTALLDIR='' THIRTY_TWO_BIT_USERSPACE_FALSE='' THIRTY_TWO_BIT_USERSPACE_TRUE='' TOOLS_VERSION='' URIPARSER_CPPFLAGS='' URIPARSER_LIBS='' USE_SLASH_PROC_FALSE='' USE_SLASH_PROC_TRUE='' VERSION='' VIX_LIBADD='' VMSVC_PLUGIN_INSTALLDIR='' VMTOOLS_CPPFLAGS='' VMTOOLS_LIBS='' VMUSR_PLUGIN_INSTALLDIR='' WITH_KERNEL_MODULES_FALSE='' WITH_KERNEL_MODULES_TRUE='' WITH_ROOT_PRIVILEGES_FALSE='' WITH_ROOT_PRIVILEGES_TRUE='' XDR_LIBS='' XMKMF='' X_CFLAGS='' X_EXTRA_LIBS='' X_LIBS='' X_PRE_LIBS='' ZLIB_CPPFLAGS='' ZLIB_LIBS='' ac_ct_CC='' ac_ct_CXX='' ac_ct_DUMPBIN='' ac_vmw_lib_cfg='' am__EXEEXT_FALSE='' am__EXEEXT_TRUE='' am__fastdepCC_FALSE='' am__fastdepCC_TRUE='' am__fastdepCXX_FALSE='' am__fastdepCXX_TRUE='' am__include='' am__isrc='' am__leading_dot='' am__quote='' am__tar='' am__untar='' bindir='${exec_prefix}/bin' build='i386-portbld-freebsd8.2' build_alias='i386-portbld-freebsd8.2' build_cpu='i386' build_os='freebsd8.2' build_vendor='portbld' datadir='${datarootdir}' datarootdir='${prefix}/share' docdir='${datarootdir}/doc/${PACKAGE_TARNAME}' dvidir='${docdir}' exec_prefix='NONE' have_cxx='' have_doxygen='' have_genmarshal='' host='i386-undermydesk-freebsd' host_alias='i386-undermydesk-freebsd' host_cpu='i386' host_os='freebsd' host_vendor='undermydesk' htmldir='${docdir}' includedir='${prefix}/include' infodir='/usr/local/info' install_sh='' libdir='${exec_prefix}/lib' libexecdir='${exec_prefix}/libexec' localedir='${datarootdir}/locale' localstatedir='${prefix}/var' lt_ECHO='echo' mandir='/usr/local/man' mkdir_p='' oldincludedir='/usr/include' pdfdir='${docdir}' prefix='/usr/local' program_transform_name='s,x,x,' psdir='${docdir}' sbindir='${exec_prefix}/sbin' sharedstatedir='${prefix}/com' sysconfdir='/usr/local/etc' target_alias='' ## ----------- ## ## confdefs.h. ## ## ----------- ## /* confdefs.h */ #define PACKAGE_NAME "open-vm-tools" #define PACKAGE_TARNAME "open-vm-tools" #define PACKAGE_VERSION "2010.10.18" #define PACKAGE_STRING "open-vm-tools 2010.10.18" #define PACKAGE_BUGREPORT "ope...@li..." #define PACKAGE_URL "" configure: exit 1 ls /var/db/pkg ImageMagick-6.7.0.10_1 gconf2-2.32.0_2 libXext-1.1.2,1 libxslt-1.1.26_3 php52-xmlwriter-5.2.17_1 ORBit2-2.14.19 gd-2.0.35_7,1 libXfixes-4.0.4 m4-1.4.16,1 php52-zip-5.2.17_1 ZendOptimizer-3.3.0.a gdk-pixbuf-2.23.5 libXfont-1.4.3,1 makedepend-1.0.3,1 php52-zlib-5.2.17_1 aspell-0.60.6.1 gettext-0.18.1.1 libXft-2.1.14 memcached-1.4.5_3 pixman-0.22.0 atk-2.0.1 ghostscript9-9.02_4 libXi-1.3.2,1 mencoder-1.0.r20110329_2pkg-config-0.25_1 atkmm-2.22.5 gio-fam-backend-2.28.8 libXinerama-1.1,1 mkfontdir-1.0.6 png-1.4.8 autoconf-2.68 glib-2.28.8 libXmu-1.1.0,1 mkfontscale-1.0.8 polkit-0.99 autoconf-wrapper-20101119glibmm-2.28.2,1 libXp-1.0.0,1 mp4v2-1.9.1 popt-1.16 automake-1.11.1 glproto-1.4.12 libXpm-3.5.7 mpfr-3.0.1 portmanager-0.4.1_9 automake-wrapper-20101119gmake-3.82 libXrandr-1.3.0 mplayer-1.0.r20110329_3printproto-1.0.4 bash-4.1.10 gmp-5.0.2 libXrender-0.9.5 mysql-client-5.5.15 python27-2.7.2_1 bdftopcf-1.0.3 gnome_subr-1.0 libXt-1.0.9 nasm-2.09.10,1 randrproto-1.3.2 bigreqsproto-1.1.1 gnomehier-2.3_12 libXtst-1.1.0 nettle-2.2 recode-3.6_8 binutils-2.21.1 gnutls-2.12.7_2 libXv-1.0.5,1 nginx-1.1.0 recordproto-1.14 bison-2.4.3,1 gobject-introspection-0.10.8libXxf86dga-1.1.1 opencv-core-2.3.0 renderproto-0.11 bitstream-vera-1.10_5 google-perftools-1.7 libXxf86vm-1.1.0 openjpeg-1.3_2 rpm2cpio-1.3_1 ca_root_nss-3.12.9 gpac-libgpac-0.4.5_4,1 libass-0.9.13 orc-0.4.14_1 rtmpdump-2.3_1 cairo-1.10.2_2,1 gpac-mp4box-0.4.5 libcheck-0.9.8 p5-Locale-gettext-1.05_3ruby-1.8.7.352,1 cairomm-1.10.0 gperf-3.0.3 libcroco-0.6.2_1 p5-Unicode-Map8-0.13 ruby18-gems-1.7.2 cmake-2.8.4_1 gsfonts-8.11_5 libdnet-1.11_3 p5-Unicode-String-2.09 rubygem-rake-0.8.7 compat6x-i386-6.4.604000.200810_3gtk-2.24.5_1 libdrm-2.4.12_1 p5-XML-Parser-2.40 schroedinger-1.0.10 compositeproto-0.4.2 gtk-engines2-2.20.2 libdv-1.0.0_2 pango-1.28.4 shared-mime-info-0.80_1 cups-client-1.4.6 gtk-update-icon-cache-2.24.5libevent-1.4.14b_2 pangomm-2.28.2 spawn-fcgi-1.6.3 cups-image-1.4.6 gtkmm-2.24.2 libffi-3.0.9 pcre-8.12 speex-1.2.r1_3,1 curl-7.21.3_2 help2man-1.40.4 libfontenc-1.1.0 pear-1.9.3 t1lib-5.1.2_1,1 damageproto-1.2.1 hicolor-icon-theme-0.12libfpx-1.2.0.12_1 pecl-imagick-3.0.1 texi2html-1.82,1 dbus-1.4.6 icu-4.8.1 libgcrypt-1.5.0 pecl-memcache-3.0.6 tiff-4.0.0_2 dbus-glib-0.88 igbinary-1.1.1 libgee-0.6.1 perl-5.12.4_1 twolame-0.3.13 dconf-0.5.1_3 inputproto-2.0.1 libgpg-error-1.10 php52-5.2.17_1 unzip-6.0_1 docbook-4.1_4 intltool-0.41.1 libgsf-1.14.21 php52-bz2-5.2.17_1 vala-0.12.1 docbook-xsl-1.75.2_1 ioncube-4.0.10 libiconv-1.13.1_1 php52-curl-5.2.17_1 videoproto-2.3.0 dri2proto-2.3 iso8879-1986_2 libidn-1.22 php52-dom-5.2.17_1 win32-codecs-20110131,1 eggdbus-0.6_1 jasper-1.900.1_9 liblqr-1-0.4.1_2 php52-exif-5.2.17_1 x264-0.115.2000 enca-1.13 jbig2dec-0.11 libltdl-2.4 php52-gd-5.2.17_1 xcb-proto-1.6 encodings-1.0.4,1 jbigkit-1.6 libmad-0.15.1b_2 php52-gettext-5.2.17_1 xcb-util-0.3.6_1 expat-2.0.1_1 jpeg-8_3 libmcrypt-2.5.8 php52-iconv-5.2.17_1 xcmiscproto-1.2.0 faac-1.28_2 kbproto-1.0.5 libmemcached-0.51 php52-json-5.2.17_1 xextproto-7.1.1 ffmpeg-0.7.2,1 lame-3.98.4 libnotify-0.5.2 php52-mbstring-5.2.17_1xf86bigfontproto-1.2.0 fftw3-3.2.2_1 lcms-1.19_1,1 libogg-1.2.2,4 php52-mcrypt-5.2.17_1 xf86dgaproto-2.1 fixesproto-4.1.2 libGL-7.4.4 libpthread-stubs-0.3_3 php52-mysql-5.2.17_1 xf86vidmodeproto-2.3 flac-1.2.1_2 libGLU-7.4.4 librsvg2-2.34.0_1 php52-mysqli-5.2.17_1 xineramaproto-1.2 font-bh-ttf-1.0.3 libICE-1.0.7,1 libsigc++-2.2.10 php52-pcre-5.2.17_1 xmlcatmgr-2.2 font-misc-ethiopic-1.0.3libIDL-0.8.14_1 libsndfile-1.0.24 php52-pspell-5.2.17_1 xorg-fonts-truetype-7.5.1 font-misc-meltho-1.0.3 libSM-1.1.1_3,1 libtheora-1.1.1_2 php52-readline-5.2.17_1xorg-macros-1.11.0 font-util-1.2.0 libX11-1.3.6,1 libtool-2.4 php52-recode-5.2.17_1 xproto-7.0.16 fontconfig-2.8.0_1,1 libXau-1.0.6 libungif-4.1.4_5 php52-session-5.2.17_1 xtrans-1.2.5 fontsproto-2.1.1 libXaw-1.0.8,1 libvorbis-1.3.2,3 php52-simplexml-5.2.17_1xvid-1.3.0,1 freetype2-2.4.4 libXcomposite-0.4.3,1 libvpx-0.9.6 php52-spl-5.2.17_1 yamdi-1.8 frei0r-1.3_1 libXcursor-1.1.11 libxcb-1.7 php52-xml-5.2.17_1 yasm-1.1.0 fusefs-libs-2.7.4 libXdamage-1.1.3 libxml++-2.34.1 php52-xmlreader-5.2.17_1zip-3.0 gamin-0.1.10_4 libXdmcp-1.0.3 libxml2-2.7.8_1 php52-xmlrpc-5.2.17_1 Med venlig hilsen / Best regards Joakim Reck Sdr. Ringvej 60 DK-4000 Roskilde Tlf: (+45) 20 30 51 33 (Timezone GMT +1 Copenhagen) |
|
From: Marcelo V. <mv...@vm...> - 2011-08-10 21:01:36
|
Hi Mike, Thanks for reporting the issue and providing the patch. In general we can't accept patches unless you send us a contribution agreement (see http://open-vm-tools.sourceforge.net/contribute.php), but I'll let the people responsible for vmxnet3 know about the issue. On 08/10/2011 03:55 AM, Mike wrote: > Good day. > > While trying to test vmxnet3s's LSO functionality under > Illumos (it is an OpenSolaris-based OS), I noticed, that > throughput was dramatically slow - about 200-300 Kbits/Sec. > Investigation led me to the fact that HW_LSO flag is resolved > in a wrong way in ' > > Here is the patch that fixes the problem: > > > @@ -103,13 +103,19 @@ vmxnet3_tx_prepare_offload(vmxnet3_softc_t *dp, > mblk_t *mp) > { > int ret = 0; > - uint32_t start, stuff, value, flags; > + uint32_t start, stuff, value, flags, lsoflags, mss; > > ol->om = VMXNET3_OM_NONE; > ol->hlen = 0; > ol->msscof = 0; > > hcksum_retrieve(mp, NULL, NULL, &start, &stuff, NULL, &value, > &flags); > + > + mac_lso_get(mp, &mss, &lsoflags); > + if (lsoflags & HW_LSO) { > + flags |= HW_LSO; > + } > + -- - Marcelo |
|
From: Mike <mic...@ne...> - 2011-08-10 11:12:22
|
Good day.
While trying to test vmxnet3s's LSO functionality under
Illumos (it is an OpenSolaris-based OS), I noticed, that
throughput was dramatically slow - about 200-300 Kbits/Sec.
Investigation led me to the fact that HW_LSO flag is resolved
in a wrong way in '
Here is the patch that fixes the problem:
@@ -103,13 +103,19 @@ vmxnet3_tx_prepare_offload(vmxnet3_softc_t *dp,
mblk_t *mp)
{
int ret = 0;
- uint32_t start, stuff, value, flags;
+ uint32_t start, stuff, value, flags, lsoflags, mss;
ol->om = VMXNET3_OM_NONE;
ol->hlen = 0;
ol->msscof = 0;
hcksum_retrieve(mp, NULL, NULL, &start, &stuff, NULL, &value,
&flags);
+
+ mac_lso_get(mp, &mss, &lsoflags);
+ if (lsoflags & HW_LSO) {
+ flags |= HW_LSO;
+ }
+
Sincerely,
Michael Tsymbalyuk
|
|
From: Marcelo V. <mv...@vm...> - 2011-08-01 21:59:29
|
Hi John, On 07/29/2011 01:29 PM, John Wolfe wrote: > What I would really like to accomplish is a more thorough round of testing. > I have built the Cunit open source package required to build the tests > directory, which yields several *.so files, but I am not certain how to > utilize this shared objects. > > - a "gmake check" does nothing > - the vmtoolsd has an option for debug mode (-g) and an associated path, > but nothing on how to run any specific set of tests. Unfortunately, as you noticed, there isn't a functional test suite available for open-vm-tools. The tests you built are more API-level tests and test very little Tools functionality; they're more targeted at making sure vmtoolsd and the associated libraries are working properly. (Also, we never implemented a "make check" or anything like that.) In general, getting the guest information published through the MOB is a good indication that things are working. Other things you could try are VIX commands (using the "vmrun" command to talk to your ESX host), although I'm not sure vmrun would allow you to send a command to a VM configured as running a SCO OS. > Is there a list of the object data items that can be queried or managed > by the > vmtoolsd -cmd? or a complete list of supported vmtoolsd CMDs? Hmmm... I don't think we have a comprehensive list of the commands. Also, today, it would be hard to send these commands via command line, since most of the payloads are binary. The most useful commands here would be the "info-get" and "info-set" pair you already mentioned; others that could be used here already have more user-friendly wrappers through vmware-toolbox-cmd. > How much of the objects managed by the ESX host "vmware-cmd" are accessible > through and appropriately constructed vmtoolsd cmd or an rpctool command? Theoretically, anything that is sent using RpcChannel_Send() / RpcOut_send() can be sent using the command line tool. So things like the guest network configuration information could be sent using these tools, if you can build the binary command that contains the payload. -- - Marcelo |
|
From: Marcelo V. <mv...@vm...> - 2011-08-01 21:49:48
|
Hi John, On 07/26/2011 08:43 AM, John Wolfe wrote: > Our OSR6 efforts are starting with generation of the VM on > ESX 4.0 which offers guest OS types for "SCO OpenServer 5" and > "SCO UnixWare 7", but nothing for OpenServer 6. The identifier provided by the guest os is, mostly, used for the UI only. The other uses are for features that wouldn't support SCO anyway, so having it not completely accurate wouldn't really be a problem aside from the cosmetic issue. The warning you saw in hostd's logs is because it expects the guest to provide exactly the same string it has in its internal table; looking at the ESX 4.0 sources it seems there are three flavors of SCO: openserver5, openserver6 and unixware7. I don't know for sure but my guess is that they are case-sensitive. They're also not marked as fully supported, although I don't know if that flag affects anything in the UI (e.g. whether to show the OS when setting up a new VM). But none of this fixes the original bug that was fixed on ESX 5.0, where the Tools status would be incorrectly reported for OSes that don't have official VMware Tools packages. So I can't really tell you what the exact behavior there would be, because I don't know. -- - Marcelo |
|
From: John W. <jl...@sc...> - 2011-07-29 20:30:04
|
I have a very basic port of open-vm-tools running on OpenServer 6:
- heartbeat established
- guestOSType set to "openServer6" which the vSphere client
displays as "SCO OpenServer 6"
- all IP addresses are visible
- fully qualified domain name is presented.
and the same information is visible through the Managed Object Browser
GuestInfo page for that VM
I have poked around the various open-vm-tools commands for Unix:
- rpctool - setting and retrieving guestInfo variable(s).
- vmware-toolbox-cmd - help, device, disk (no shrinking yet), stat,
script, timesync
- vmware-xferlogs (although not certain how to verify the content
transfered)
- vmtoolsd -cmd=
- limited set of commands such as enabling/disabling time sync.
What I would really like to accomplish is a more thorough round of testing.
I have built the Cunit open source package required to build the tests
directory, which yields several *.so files, but I am not certain how to
utilize this shared objects.
- a "gmake check" does nothing
- the vmtoolsd has an option for debug mode (-g) and an associated path,
but nothing on how to run any specific set of tests.
Is there some test suite that is available to the open-vm-tools developers
to validate a build and is it available to the public?
Is there a list of the object data items that can be queried or managed
by the
vmtoolsd -cmd? or a complete list of supported vmtoolsd CMDs?
How much of the objects managed by the ESX host "vmware-cmd" are accessible
through and appropriately constructed vmtoolsd cmd or an rpctool command?
Thanks for any information. Off to work on various modules now....
-- John Wolfe UnXis, Inc.
|
|
From: John W. <jl...@sc...> - 2011-07-26 15:47:36
|
Marcelo Vanzin wrote:
> I don't know if "could" there means that the status would always be set to "not
> installed".
Could vs. would seems to suggest some variability in observed behavior.
We can assure OSR5, OSR6 or probably UW714 VM users on ESX 4.x
hosts that the display of the IP(s) and system name indicate that
open-vm-tools are installed and running on their VM. That should
satisfy everyone.
> The workaround that the user who first complained used was to set up the VM as
> "linux" or "linux 64-bit". That would work around this particular bug, since we
> do have a Tools package for Linux.
>
I think that it would be preferable to display the correct Guest OS type.
(See below)
> I'm not sure whether ESX 4.1 has a specific guest os type for SCO. I think we
> have some internal tweaks for SCO regarding time keeping, that are only applied
> if you choose the appropriate guest OS type. So changing it to Linux might have
> some adverse side-effects.
>
Our current OSR 5.0.5 VA released was generated on WS for Windows 6.5.x
as:
Other: Other-32 (No SCO guest type available then)
VM version: 4
open-vm-tools: 2010.03.20-243334
INFO_OS_NAME = null string.
and that guest OS type is carried through the import of the VA and running
of the VM.
Our OSR6 efforts are starting with generation of the VM on
ESX 4.0 which offers guest OS types for "SCO OpenServer 5" and
"SCO UnixWare 7", but nothing for OpenServer 6.
Other: Other-32
VM Version: 7
open-vm-tools: 2011.04.25-402641 (port starting point)
INFO_OS_NAME = "openServer6"
I just invented an OS_NAME string which triggered a warning in the
hostd.log file about an unrecognized/unsupported guest OS. A search
through the ESX host files revealed Guest OS types for "openServer5",
"openServer6" and "unixWare7".
When open-vm-tools was modified to provide INFO_OS_NAME
as "openServer6", the vSphere Client will switch from "Other-32" to
"SCO OpenServer 6" on a running VM.
The next release of open-vm-tools for OpenServer 5.0.7 will by corrected
to provide "openServer5".
-- John Wolfe
|
|
From: SourceForge.net <no...@so...> - 2011-07-26 14:38:38
|
Tracker item #3378690, was opened at 2011-07-26 10:38 Message generated for change (Tracker Item Submitted) made by svz90 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=989708&aid=3378690&group_id=204462 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: kernel modules Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Sean (svz90) Assigned to: Nobody/Anonymous (nobody) Summary: DnD From Host to Guest Fails Initial Comment: When trying to drag and drop a file from the Host operating system to the guest, I get the following error message: Error stating file '/proc/fs/vmblock/mountPoint/cdd623db/filename' No such file or directory where filename is the file from the host system. I am running open-vm-tools version 2011.07.19, with Arch Linux (kernel version 2.6.39), and Xfce 4.8. Using VMWare Player 3.1.4 build-385536. I checked the startup scripts, and vmblock is mounted and running. The /proc/fs/vmblock/mountpoint directory is symlinked to /tmp/VMWareDnD/cdd623db. Drag and drop from guest to host works fine. Clipboard synchronization works in both directions (though only with text - not with files). Thank you for any help in this matter. Regards, svz90 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=989708&aid=3378690&group_id=204462 |
|
From: SourceForge.net <no...@so...> - 2011-07-25 16:03:55
|
Tracker item #3298068, was opened at 2011-05-05 23:40 Message generated for change (Comment added) made by katjai You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=989708&aid=3298068&group_id=204462 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: hgfsClient Group: None Status: Closed Resolution: Fixed Priority: 5 Private: No Submitted By: Ekaterina (katjai) Assigned to: Nobody/Anonymous (nobody) Summary: kernel Oops when called phpunit Initial Comment: Hello, Have this problem, when trying execute phpunit tests for a whole directory (seems problem caused by SPL directory iterators + mounted vmhgfs drive) In root console: 2011 May 5 23:30:28 dev Oops: 0000 [#1] PREEMPT SMP 2011 May 5 23:30:28 dev last sysfs file: /sys/devices/virtual/vc/vcsa9/uevent 2011 May 5 23:30:28 dev Process php (pid: 30138, ti=e6f3a000 task=e2ced590 task.ti=e6f3a000) 2011 May 5 23:30:28 dev Stack: 2011 May 5 23:30:28 dev Call Trace: 2011 May 5 23:30:28 dev Code: 89 e5 83 ec 10 89 75 f8 89 c6 89 7d fc 89 55 f0 89 5d f4 bb c0 03 4a c1 9c 58 8d 74 26 00 89 c1 fa 90 8d 74 26 00 8b 45 f0 89 08 <8b> 46 04 8b 40 10 8b 3c 85 20 34 43 c1 01 df 89 f8 e8 ee 34 2d 2011 May 5 23:30:28 dev EIP: [<c103312c>] task_rq_lock+0x2c/0x80 SS:ESP 0068:e6f3bedc 2011 May 5 23:30:28 dev CR2: 0000000000000004 In error.log May 5 23:30:29 dev kernel: BUG: scheduling while atomic: php/30138/0x10000002 dmesg: BUG: scheduling while atomic: php/30138/0x10000002 Modules linked in: ipv6 vmsync vmblock vmhgfs parport_pc uhci_hcd ehci_hcd ppdev usbcore container ac processor button psmouse thermal i2c_piix4 intel_agp agpgart sg vmw_balloon i2c_core vmci lp shpchp pci_hotplug serio_raw parport evdev pcspkr pcnet32 mii ext2 mbcache sr_mod cdrom sd_mod ide_pci_generic piix ide_core floppy ata_piix mptspi mptscsih libata mptbase scsi_transport_spi BusLogic scsi_mod Pid: 30138, comm: php Tainted: G D W 2.6.36-ARCH #1 Call Trace: [<c1035ead>] __schedule_bug+0x5d/0x70 [<c1304531>] schedule+0x7b1/0x900 [<c110e719>] ? __d_free+0x29/0x40 [<c110e767>] ? d_free+0x37/0x40 [<c110e89a>] ? d_kill+0x4a/0x60 [<c110f034>] ? dput+0x84/0x120 [<c103a786>] __cond_resched+0x16/0x30 [<c1304783>] _cond_resched+0x23/0x30 [<c10476cc>] put_files_struct+0x8c/0x100 [<c10477e2>] exit_files+0x42/0x60 [<c1047bf2>] do_exit+0x152/0x770 [<c1045b9a>] ? kmsg_dump+0x10a/0x120 [<c1303a85>] ? printk+0x18/0x1b [<c1006fec>] oops_end+0x8c/0xd0 [<c102897c>] no_context+0xbc/0x150 [<c1028a9d>] __bad_area_nosemaphore+0x8d/0x130 [<c1306aae>] ? _raw_spin_unlock+0x1e/0x30 [<c1028e10>] ? do_page_fault+0x0/0x3e0 [<c1028b52>] bad_area_nosemaphore+0x12/0x20 [<c1029134>] do_page_fault+0x324/0x3e0 [<c119e674>] ? rb_insert_color+0x74/0x100 [<c10026ee>] ? __switch_to+0x10e/0x180 [<c1035efa>] ? finish_task_switch+0x3a/0xa0 [<c1028e10>] ? do_page_fault+0x0/0x3e0 [<c130770b>] error_code+0x67/0x6c [<c103312c>] ? task_rq_lock+0x2c/0x80 [<c103e4e5>] try_to_wake_up+0x25/0x340 [<c103e81f>] wake_up_process+0xf/0x20 [<c13056ac>] __mutex_unlock_slowpath+0x8c/0x120 [<c1305748>] mutex_unlock+0x8/0x10 [<ede2018e>] HgfsDirLlseek+0x8e/0xf0 [vmhgfs] [<ede20100>] ? HgfsDirLlseek+0x0/0xf0 [vmhgfs] [<c10fd353>] vfs_llseek+0x33/0x40 [<c10fd76c>] sys_lseek+0x5c/0x80 [<c100379f>] sysenter_do_call+0x12/0x28 Main OS: Windows7 Guest OS: Arch Linux (Linux dev 2.6.36-ARCH #1 SMP PREEMPT Sat Jan 8 13:16:43 UTC 2011 i686 Intel(R) Core(TM)2 Duo CPU T9400 @ 2.53GHz GenuineIntel GNU/Linux) Kernel string: kernel /vmlinuz26 root=/dev/sda3 ro maxcpus=0 nosmp noreplace-smp Vmtoolsd: VMware Tools daemon, version 8.9.0.5114 (build-387002) Can you tell me, it's vmhgfs driver issue or php directory iterators implementation? Thanks, Katya ---------------------------------------------------------------------- Comment By: Ekaterina (katjai) Date: 2011-07-25 19:03 Message: Working great now. Thanks! ---------------------------------------------------------------------- Comment By: Marcelo Vanzin (mvanzin) Date: 2011-07-21 02:34 Message: This is fixed in the last release. If you're using distro packages, you may need to ask them to update their version or backport the fix (commit id b76ee8). ---------------------------------------------------------------------- Comment By: Marcelo Vanzin (mvanzin) Date: 2011-07-08 20:51 Message: Hi, We forwarded the bug to the appropriate team but haven't heard back from them. I'll ping them again. ---------------------------------------------------------------------- Comment By: Ekaterina (katjai) Date: 2011-07-08 00:12 Message: Any chance to get this fixed in nearest time? Maybe I can help somehow? I.e. prepare vmware drive with necessary software so that illustrate a problem? Thanks, Katya ---------------------------------------------------------------------- Comment By: Ekaterina (katjai) Date: 2011-05-06 01:42 Message: Nothing changed after updating up to last version: [ki@dev ~]$ vmtoolsd -v VMware Tools daemon, version 8.9.0.5529 (build-402641) [ki@dev ~]$ lsmod | grep vm vmsync 2685 0 vmblock 9422 1 vmhgfs 47514 1 vmw_balloon 3570 0 vmci 60023 1 vmhgfs dmesg: [ 143.773285] BUG: scheduling while atomic: php/2529/0x10000002 [ 143.773471] Modules linked in: ipv6 vmsync vmblock vmhgfs uhci_hcd ehci_hcd floppy usbcore parport_pc ppdev processor psmouse button ac intel_agp intel_gtt container lp i2c_piix4 agpgart shpchp pci_hotplug sg parport i2c_core vmw_balloon serio_raw evdev vmci pcspkr pcnet32 mii ext2 mbcache sr_mod cdrom ide_pci_generic piix ide_core sd_mod ata_piix mptspi mptscsih mptbase libata scsi_transport_spi BusLogic scsi_mod [ 143.777696] Pid: 2529, comm: php Tainted: G D W 2.6.38-ARCH #1 [ 143.777990] Call Trace: [ 143.778251] [<c1312dee>] ? __schedule_bug+0x59/0x5f [ 143.778518] [<c1317f88>] ? schedule+0x858/0x9e0 [ 143.778809] [<c1115f84>] ? __d_free+0x34/0x50 [ 143.779063] [<c1115f84>] ? __d_free+0x34/0x50 [ 143.779355] [<c1115f84>] ? __d_free+0x34/0x50 [ 143.779638] [<c111d15f>] ? vfsmount_lock_global_unlock_online+0x4f/0x60 [ 143.814856] [<c111deb9>] ? mntput_no_expire+0x89/0xd0 [ 143.815148] [<c111df13>] ? mntput+0x13/0x20 [ 143.815400] [<c1105c14>] ? fput+0x134/0x1d0 [ 143.815726] [<c103cda6>] ? __cond_resched+0x16/0x30 [ 143.815992] [<c1318215>] ? _cond_resched+0x25/0x30 [ 143.816279] [<c10473a8>] ? put_files_struct+0x78/0xd0 [ 143.816585] [<c10474a0>] ? exit_files+0x40/0x50 [ 143.816919] [<c10478bd>] ? do_exit+0x13d/0x760 [ 143.817199] [<c1313018>] ? printk+0x18/0x1a [ 143.817453] [<c1006fcc>] ? oops_end+0x8c/0xd0 [ 143.817750] [<c1312a20>] ? no_context+0x137/0x13f [ 143.818013] [<c1312b43>] ? __bad_area_nosemaphore+0x11b/0x123 [ 143.818319] [<c1229530>] ? vt_console_print+0x0/0x340 [ 143.818587] [<c1027530>] ? do_page_fault+0x0/0x430 [ 143.818886] [<c1312b5d>] ? bad_area_nosemaphore+0x12/0x14 [ 143.819196] [<c10278a0>] ? do_page_fault+0x370/0x430 [ 143.819464] [<c10339d4>] ? finish_task_switch+0x34/0xb0 [ 143.819792] [<c13179bd>] ? schedule+0x28d/0x9e0 [ 143.820051] [<c1027530>] ? do_page_fault+0x0/0x430 [ 143.820392] [<c131b13b>] ? error_code+0x67/0x6c [ 143.820687] [<c131007b>] ? init_smp_flush+0x1b/0x66 [ 143.820954] [<c103038c>] ? task_rq_lock+0x2c/0x80 [ 143.821241] [<c103e1f5>] ? try_to_wake_up+0x25/0x350 [ 143.821532] [<c1318251>] ? preempt_schedule+0x31/0x50 [ 143.821839] [<c103e53f>] ? wake_up_process+0xf/0x20 [ 143.822106] [<c131916a>] ? __mutex_unlock_slowpath+0x8a/0x120 [ 143.822410] [<c1319208>] ? mutex_unlock+0x8/0x10 [ 143.822709] [<ede6317f>] ? HgfsDirLlseek+0x7f/0xe0 [vmhgfs] [ 143.822989] [<ede63100>] ? HgfsDirLlseek+0x0/0xe0 [vmhgfs] [ 143.823286] [<c1104203>] ? vfs_llseek+0x33/0x40 [ 143.823544] [<c1104655>] ? sys_lseek+0x65/0x80 [ 143.823910] [<c10037df>] ? sysenter_do_call+0x12/0x28 ---------------------------------------------------------------------- Comment By: Ekaterina (katjai) Date: 2011-05-06 00:19 Message: Previous, 2011.03.28 ---------------------------------------------------------------------- Comment By: Dmitry Torokhov (dtor) Date: 2011-05-06 00:01 Message: Looks like HGFS issue. Is this with the latest release? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=989708&aid=3298068&group_id=204462 |
|
From: SourceForge.net <no...@so...> - 2011-07-24 21:22:21
|
Tracker item #3373006, was opened at 2011-07-20 21:42 Message generated for change (Settings changed) made by n-minker You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=989708&aid=3373006&group_id=204462 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed Resolution: None Priority: 5 Private: No Submitted By: Nate Muench (n-minker) Assigned to: Nobody/Anonymous (nobody) Summary: open-vm-tools still fails to build with GCC 4.6 or later Initial Comment: I just downloaded the new release for open-vm-tools (2011.07.19-450511), There still appears to be issues, below are the remaining issues: lib/file/ fileLockPrimitive.c:1404:8: error: variable 'cnt' set but not used lib/file/ fileLockPosix.c:988:9: error: variable 'gotProcData' set but not used I've also attached a partial build log (which is from later during the build), with more errors. It may not be related to GCC 4.6 but I thought I'd bring it up. ---------------------------------------------------------------------- Comment By: Nate Muench (n-minker) Date: 2011-07-22 15:50 Message: Adding "-Wno-unused-but-set-variable" to the CFLAGS worked, it built successfully. ---------------------------------------------------------------------- Comment By: Marcelo Vanzin (mvanzin) Date: 2011-07-21 12:33 Message: Could you try to configure with "-Wno-unused-but-set-variable" in your CFLAGS? You're interested in building, not in keeping the code clean, so that should work for you. (FYI: it needs to come after "-Wall -Werror" in the gcc command line; I believe just setting CFLAGS in the configure command line will do that.) We still don't use gcc 4.6 internally, so it's hard for us to keep track of these warnings. We'll fix them as we run into them, but disabling that warning is probably the easier solution for you guys. As for the other build errors, they seem to be related to not finding the SunRPC functions in libc. Did something change in the version of glibc you're using? The functions used to be in libc.so. If they've moved, you may need to tweak LDFLAGS. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=989708&aid=3373006&group_id=204462 |
|
From: SourceForge.net <no...@so...> - 2011-07-22 20:50:30
|
Tracker item #3373006, was opened at 2011-07-20 21:42 Message generated for change (Comment added) made by n-minker You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=989708&aid=3373006&group_id=204462 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nate Muench (n-minker) Assigned to: Nobody/Anonymous (nobody) Summary: open-vm-tools still fails to build with GCC 4.6 or later Initial Comment: I just downloaded the new release for open-vm-tools (2011.07.19-450511), There still appears to be issues, below are the remaining issues: lib/file/ fileLockPrimitive.c:1404:8: error: variable 'cnt' set but not used lib/file/ fileLockPosix.c:988:9: error: variable 'gotProcData' set but not used I've also attached a partial build log (which is from later during the build), with more errors. It may not be related to GCC 4.6 but I thought I'd bring it up. ---------------------------------------------------------------------- >Comment By: Nate Muench (n-minker) Date: 2011-07-22 15:50 Message: Adding "-Wno-unused-but-set-variable" to the CFLAGS worked, it built successfully. ---------------------------------------------------------------------- Comment By: Marcelo Vanzin (mvanzin) Date: 2011-07-21 12:33 Message: Could you try to configure with "-Wno-unused-but-set-variable" in your CFLAGS? You're interested in building, not in keeping the code clean, so that should work for you. (FYI: it needs to come after "-Wall -Werror" in the gcc command line; I believe just setting CFLAGS in the configure command line will do that.) We still don't use gcc 4.6 internally, so it's hard for us to keep track of these warnings. We'll fix them as we run into them, but disabling that warning is probably the easier solution for you guys. As for the other build errors, they seem to be related to not finding the SunRPC functions in libc. Did something change in the version of glibc you're using? The functions used to be in libc.so. If they've moved, you may need to tweak LDFLAGS. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=989708&aid=3373006&group_id=204462 |
|
From: SourceForge.net <no...@so...> - 2011-07-22 14:45:11
|
Tracker item #3297924, was opened at 2011-05-05 06:49 Message generated for change (Comment added) made by mvanzin You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=989708&aid=3297924&group_id=204462 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Timo Gurr (tgurr) Assigned to: Nobody/Anonymous (nobody) Summary: Wrong "Guest OS" information in vSphere client displayed Initial Comment: The guest is configured as "Other 2.6x Linux (64-bit)", attached screenshot (vmware-tools_stopped.png). # uname -a Linux wwwproxy 2.6.38.5 #2 SMP Wed May 4 12:33:49 CEST 2011 x86_64 Six-Core AMD Opteron(tm) Processor 2425 HE AuthenticAMD GNU/Linux After starting open-vm-tools-2011.04.25-402641 the information in vCenter changes to "Other (32-bit)", attached screenshot (vmware-tools_started.png) which is obviously wrong. VMware vSphere vCenter Client/Server is Version 4.1.0 Build 345043. ---------------------------------------------------------------------- >Comment By: Marcelo Vanzin (mvanzin) Date: 2011-07-22 07:45 Message: Gentoo and many "Other" distros will probably show as their original configured OS. There's no point in adding every single distro out there to our UI, when only a few of them require tweaks at the hypervisor level. (I'd argue that the current list is already too long, but that's a separate discusssion.) As for the Fedora problem; unless you add some log statements to GuestInfoGather() in services/plugins/guestInfo/guestInfoServer.c (after the call to Hostinfo_GetOSName()), there's not much I can figure out from logs or anything else, because we don't log the raw data anywhere. "osName" and "osNameFull" are the strings provided to the UI to identify the OS. ---------------------------------------------------------------------- Comment By: Greg Emerick (gemerick) Date: 2011-07-22 07:00 Message: I tried hardcoding lsb_release to return "Fedora release 8 (Werewolf)" and my image is still 32 bit. I've been looking at the code where lsb_release is called and it would seem that uname is also involved. Although command line uname appears to return very similar information as what I found online for FC 8. I sure don't see any issues with it. ---------------------------------------------------------------------- Comment By: Timo Gurr (tgurr) Date: 2011-07-22 05:02 Message: So what's the deal on Gentoo or (m)any other "Other" Linux distributions? # lsb_release -sd "Gentoo Base System release 2.0.3" Issue on the open virtual machine tools side, or time to open a vmware bug? ---------------------------------------------------------------------- Comment By: Marcelo Vanzin (mvanzin) Date: 2011-07-21 11:44 Message: I just tried with Fedora 8 (which has a very similar output of "lsb_release -sd") and the code seems to detect Fedora correctly. I'll close this as an issue with the vCenter / VI client code (they may be missing the mapping to show Fedora correctly), but I shouldn't worry much because this is mostly a cosmetic issue. ---------------------------------------------------------------------- Comment By: Marcelo Vanzin (mvanzin) Date: 2011-07-21 10:56 Message: In general, the OS would be reported as "Other (32-bit)" if the code completely failed to recognize that output. The interesting bit is that we do have a check for Fedora in the code, and it should recognize that output. I'll need to try it out to see what's going on. As for what if affects, there are a couple of vCenter features that will look at that value and decide whether they'll run against the VM or not. But I think those features do not support Fedora anyway, so you should be safe. In your case it's probably just a cosmetic thing. ---------------------------------------------------------------------- Comment By: Greg Emerick (gemerick) Date: 2011-07-20 18:21 Message: lsb_release -sd returns: "Fedora release 9 (Sulphur)" I can see where that would get me Other (32-bit). Could you give me some idea of what tools are looking for in the response to indicate 64 bit? If I have to, I'll make this return what's necessary, since it's not used by our appliance for any other purpose. Also, would there be any side-effects to just allowing this to happen? The vmx file is still set to Other (64 bit). ---------------------------------------------------------------------- Comment By: Marcelo Vanzin (mvanzin) Date: 2011-07-20 16:36 Message: Tools will generally use the output of "lsb_release -sd" to figure out the OS information. Fedora 9 should have that; what's the output of that command in your VM? If lsb_release is not available, then that's probably the cause. ---------------------------------------------------------------------- Comment By: Greg Emerick (gemerick) Date: 2011-07-18 19:44 Message: I'm seeing this on Fedora 9 as well with open-vm-tools-2011.06.27-437995. Anything I can provide to assist? vSphere 4.1.0 Build 260247 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=989708&aid=3297924&group_id=204462 |
|
From: SourceForge.net <no...@so...> - 2011-07-22 14:00:43
|
Tracker item #3297924, was opened at 2011-05-05 08:49 Message generated for change (Comment added) made by gemerick You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=989708&aid=3297924&group_id=204462 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Timo Gurr (tgurr) Assigned to: Nobody/Anonymous (nobody) Summary: Wrong "Guest OS" information in vSphere client displayed Initial Comment: The guest is configured as "Other 2.6x Linux (64-bit)", attached screenshot (vmware-tools_stopped.png). # uname -a Linux wwwproxy 2.6.38.5 #2 SMP Wed May 4 12:33:49 CEST 2011 x86_64 Six-Core AMD Opteron(tm) Processor 2425 HE AuthenticAMD GNU/Linux After starting open-vm-tools-2011.04.25-402641 the information in vCenter changes to "Other (32-bit)", attached screenshot (vmware-tools_started.png) which is obviously wrong. VMware vSphere vCenter Client/Server is Version 4.1.0 Build 345043. ---------------------------------------------------------------------- Comment By: Greg Emerick (gemerick) Date: 2011-07-22 09:00 Message: I tried hardcoding lsb_release to return "Fedora release 8 (Werewolf)" and my image is still 32 bit. I've been looking at the code where lsb_release is called and it would seem that uname is also involved. Although command line uname appears to return very similar information as what I found online for FC 8. I sure don't see any issues with it. ---------------------------------------------------------------------- Comment By: Timo Gurr (tgurr) Date: 2011-07-22 07:02 Message: So what's the deal on Gentoo or (m)any other "Other" Linux distributions? # lsb_release -sd "Gentoo Base System release 2.0.3" Issue on the open virtual machine tools side, or time to open a vmware bug? ---------------------------------------------------------------------- Comment By: Marcelo Vanzin (mvanzin) Date: 2011-07-21 13:44 Message: I just tried with Fedora 8 (which has a very similar output of "lsb_release -sd") and the code seems to detect Fedora correctly. I'll close this as an issue with the vCenter / VI client code (they may be missing the mapping to show Fedora correctly), but I shouldn't worry much because this is mostly a cosmetic issue. ---------------------------------------------------------------------- Comment By: Marcelo Vanzin (mvanzin) Date: 2011-07-21 12:56 Message: In general, the OS would be reported as "Other (32-bit)" if the code completely failed to recognize that output. The interesting bit is that we do have a check for Fedora in the code, and it should recognize that output. I'll need to try it out to see what's going on. As for what if affects, there are a couple of vCenter features that will look at that value and decide whether they'll run against the VM or not. But I think those features do not support Fedora anyway, so you should be safe. In your case it's probably just a cosmetic thing. ---------------------------------------------------------------------- Comment By: Greg Emerick (gemerick) Date: 2011-07-20 20:21 Message: lsb_release -sd returns: "Fedora release 9 (Sulphur)" I can see where that would get me Other (32-bit). Could you give me some idea of what tools are looking for in the response to indicate 64 bit? If I have to, I'll make this return what's necessary, since it's not used by our appliance for any other purpose. Also, would there be any side-effects to just allowing this to happen? The vmx file is still set to Other (64 bit). ---------------------------------------------------------------------- Comment By: Marcelo Vanzin (mvanzin) Date: 2011-07-20 18:36 Message: Tools will generally use the output of "lsb_release -sd" to figure out the OS information. Fedora 9 should have that; what's the output of that command in your VM? If lsb_release is not available, then that's probably the cause. ---------------------------------------------------------------------- Comment By: Greg Emerick (gemerick) Date: 2011-07-18 21:44 Message: I'm seeing this on Fedora 9 as well with open-vm-tools-2011.06.27-437995. Anything I can provide to assist? vSphere 4.1.0 Build 260247 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=989708&aid=3297924&group_id=204462 |
|
From: SourceForge.net <no...@so...> - 2011-07-22 13:34:11
|
Tracker item #3371547, was opened at 2011-07-19 16:26 Message generated for change (Comment added) made by You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=989708&aid=3371547&group_id=204462 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: https://www.google.com/accounts () Assigned to: Nobody/Anonymous (nobody) Summary: patches to allow vmtools to be built with uclibc/buildroot Initial Comment: With the attached patches, vmtools will be able to be built for uclibc. Tested successfully in a buildroot environment. ---------------------------------------------------------------------- >Comment By: https://www.google.com/accounts () Date: 2011-07-22 13:34 Message: Tried sending you a private email via sourceforge but it's erroring out. My contact email is wal...@cc... ---------------------------------------------------------------------- Comment By: Marcelo Vanzin (mvanzin) Date: 2011-07-21 18:00 Message: Hey, could you send me a private e-mail? Sourceforge doesn't seem to show your user info. ---------------------------------------------------------------------- Comment By: Marcelo Vanzin (mvanzin) Date: 2011-07-21 17:42 Message: Thanks. I'll ping our legal department since generally they haven't been very good in processing those. ---------------------------------------------------------------------- Comment By: https://www.google.com/accounts () Date: 2011-07-21 11:20 Message: Contributor agreement sent. ---------------------------------------------------------------------- Comment By: https://www.google.com/accounts () Date: 2011-07-21 11:05 Message: I've substituted patch #4 with a much simpler version -- just moves NO_FLOATING_POINT ifdef to exclude one function. The rest of the code that was problematic can be stubbed out by compiling with NO_FLOATING_POINT. So basically these patches just modify some ifdef's now. Will submit contributor agreement. ---------------------------------------------------------------------- Comment By: Marcelo Vanzin (mvanzin) Date: 2011-07-20 17:08 Message: For the libc bits, I don't think we can accept those into our repository, unless you manage to get the copyright owner to sign off the copyright on those bits to VMware (which I think is unlikely to happen...). ---------------------------------------------------------------------- Comment By: https://www.google.com/accounts () Date: 2011-07-20 08:08 Message: Hi, All patches except one are nothing more than adding an extra #if defined so signing and returning the approval form isn't a problem. Patch number #4 is more problematic however since the code is lifted off libc. What's the contribution policy on that? ---------------------------------------------------------------------- Comment By: Marcelo Vanzin (mvanzin) Date: 2011-07-19 17:30 Message: Thanks for taking the time to do this, but we can't accept any patches unless you follow the instructions at: http://open-vm-tools.sourceforge.net/contribute.php Lots of this code is shared with our closed-sourced products, so we can't just merge (L)GPL code into our code base without being able to change the license. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=989708&aid=3371547&group_id=204462 |
|
From: SourceForge.net <no...@so...> - 2011-07-22 12:02:59
|
Tracker item #3297924, was opened at 2011-05-05 15:49 Message generated for change (Comment added) made by tgurr You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=989708&aid=3297924&group_id=204462 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Closed Resolution: None Priority: 5 Private: No Submitted By: Timo Gurr (tgurr) Assigned to: Nobody/Anonymous (nobody) Summary: Wrong "Guest OS" information in vSphere client displayed Initial Comment: The guest is configured as "Other 2.6x Linux (64-bit)", attached screenshot (vmware-tools_stopped.png). # uname -a Linux wwwproxy 2.6.38.5 #2 SMP Wed May 4 12:33:49 CEST 2011 x86_64 Six-Core AMD Opteron(tm) Processor 2425 HE AuthenticAMD GNU/Linux After starting open-vm-tools-2011.04.25-402641 the information in vCenter changes to "Other (32-bit)", attached screenshot (vmware-tools_started.png) which is obviously wrong. VMware vSphere vCenter Client/Server is Version 4.1.0 Build 345043. ---------------------------------------------------------------------- Comment By: Timo Gurr (tgurr) Date: 2011-07-22 14:02 Message: So what's the deal on Gentoo or (m)any other "Other" Linux distributions? # lsb_release -sd "Gentoo Base System release 2.0.3" Issue on the open virtual machine tools side, or time to open a vmware bug? ---------------------------------------------------------------------- Comment By: Marcelo Vanzin (mvanzin) Date: 2011-07-21 20:44 Message: I just tried with Fedora 8 (which has a very similar output of "lsb_release -sd") and the code seems to detect Fedora correctly. I'll close this as an issue with the vCenter / VI client code (they may be missing the mapping to show Fedora correctly), but I shouldn't worry much because this is mostly a cosmetic issue. ---------------------------------------------------------------------- Comment By: Marcelo Vanzin (mvanzin) Date: 2011-07-21 19:56 Message: In general, the OS would be reported as "Other (32-bit)" if the code completely failed to recognize that output. The interesting bit is that we do have a check for Fedora in the code, and it should recognize that output. I'll need to try it out to see what's going on. As for what if affects, there are a couple of vCenter features that will look at that value and decide whether they'll run against the VM or not. But I think those features do not support Fedora anyway, so you should be safe. In your case it's probably just a cosmetic thing. ---------------------------------------------------------------------- Comment By: Greg Emerick (gemerick) Date: 2011-07-21 03:21 Message: lsb_release -sd returns: "Fedora release 9 (Sulphur)" I can see where that would get me Other (32-bit). Could you give me some idea of what tools are looking for in the response to indicate 64 bit? If I have to, I'll make this return what's necessary, since it's not used by our appliance for any other purpose. Also, would there be any side-effects to just allowing this to happen? The vmx file is still set to Other (64 bit). ---------------------------------------------------------------------- Comment By: Marcelo Vanzin (mvanzin) Date: 2011-07-21 01:36 Message: Tools will generally use the output of "lsb_release -sd" to figure out the OS information. Fedora 9 should have that; what's the output of that command in your VM? If lsb_release is not available, then that's probably the cause. ---------------------------------------------------------------------- Comment By: Greg Emerick (gemerick) Date: 2011-07-19 04:44 Message: I'm seeing this on Fedora 9 as well with open-vm-tools-2011.06.27-437995. Anything I can provide to assist? vSphere 4.1.0 Build 260247 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=989708&aid=3297924&group_id=204462 |
|
From: Marcelo V. <mv...@vm...> - 2011-07-21 22:53:28
|
Hi John, On 07/21/2011 03:01 PM, John Wolfe wrote: > Is the "bug" in vSphere 4.x flaky enough for the tools status > to occasionally be reported as "unmanaged" for unsupported guests? The flakiness of the status does look weird; but looking at the fix for the bug, it does seem like it would properly handle this case. The bug was that the status could be set to "not installed" if the configured guest OS did not have a VMware tools package (which would be the case for "other" or "sco" guest OS types). I don't know if "could" there means that the status would always be set to "not installed". But with the fix, if the Tools version is "unmanaged", that's always properly reported, regardless of the OS type. > Is there anything that I can do to reduce the number of tools > running, not running, version not available, not installed > messages that are being dropped into /var/log/vmware/hostd.log? The workaround that the user who first complained used was to set up the VM as "linux" or "linux 64-bit". That would work around this particular bug, since we do have a Tools package for Linux. I'm not sure whether ESX 4.1 has a specific guest os type for SCO. I think we have some internal tweaks for SCO regarding time keeping, that are only applied if you choose the appropriate guest OS type. So changing it to Linux might have some adverse side-effects. -- - Marcelo |
|
From: John W. <jl...@sc...> - 2011-07-21 22:05:12
|
Marcelo,
Petr,
Is the "bug" in vSphere 4.x flaky enough for the tools status
to occasionally be reported as "unmanaged" for unsupported guests?
- yesterday my OSR6 VM was "Unmanaged" for several reboots
and restarts of the vmtoolsd
- today, following a power-hit to our Intel Modular Servers,
an OSR507 VM was rebooted and is reporting a VMtools status of
"Unmanaged" - through several shutdown and power-up cycles.
Previously the status was being reported as "Not Installed".
Is there anything that I can do to reduce the number of tools
running, not running, version not available, not installed
messages that are being dropped into /var/log/vmware/hostd.log?
-- John
Marcelo Vanzin wrote:
> Hi John,
>
> On 07/21/2011 01:32 PM, John Wolfe wrote:
>
>> Jul 21 14:24:12.732: vcpu-1| VMXVmdb_SetToolsVersionState: status value set to
>> 'notAvailable'
>>
>
> I'm pretty sure this is a bug in VMware's host code, so there's nothing you can
> do from the Tools side. Someone else reported a similar issue here before, and
> we've already fixed the host code in the vSphere 5.0 release. (I don't think the
> fix was backported to any maintenance release of previous vSphere versions.)
>
>
|
|
From: Marcelo V. <mv...@vm...> - 2011-07-21 20:47:10
|
Hi John, On 07/21/2011 01:32 PM, John Wolfe wrote: > Jul 21 14:24:12.732: vcpu-1| VMXVmdb_SetToolsVersionState: status value set to > 'notAvailable' I'm pretty sure this is a bug in VMware's host code, so there's nothing you can do from the Tools side. Someone else reported a similar issue here before, and we've already fixed the host code in the vSphere 5.0 release. (I don't think the fix was backported to any maintenance release of previous vSphere versions.) -- - Marcelo |
|
From: John W. <jl...@sc...> - 2011-07-21 20:36:06
|
I have the basics for vmtools ported for OpenServer 6. The RPC loop
is running and the hostd.log file on the ESX host reports the current
heartbeat status as green.
But, the vSphere Client Summary tab for the running VM indicates:
"VMware Tools: Not Installed"
And it has consistently been displayed that way except for about 1/2 hour
of testing during which the status was displayed as "Unmanaged" while
the RPC loop was running, and "Not Running" when vmtoolsd was killed.
The "Not Installed" status has returned, but that got me digging a
little bit.
Managed Object Browser:
===========================================
The Managed Object Browser (MOB) of the GuestInfo for my running OSR6 VM
shows:
toolsRuningStatus string "guestToolsRunning"
toolsStatus VirtualMachineToolsStatus "toolsOK"
toolsVersion string "2147483647"
(32 bit MAXINT - 0x7fffffff)
- probably the TOOLS_VERSION_UNMANAGED
toolsVersionStatus string "guestToolsNotInstalled"
Now, from the top three items, I would have expected the
"VMware Tools:" status to at least indicate "Unmanaged".
Clearly the last item "toolsVersionStatus" is being set incorrectly (?)
and that is apparently what results in the
VMware Tools: Not Installed
being displayed in the vSphere Client Summary tab for a running VM.
I have confirmed that services/vmtoolsd/toolsRpstatusc.c is sending
the "tools.set.version 2147483647"
ESX 4.0 (build-398348): /var/log/vmware/hostd.log
===================================================
Looking in the ESX 4.0 host /var/log/vmware/hostd.log I see:
- the tools status is changed to "running"
- the tools version changing from 0 (default) to
TOOLS_VERSION_MANAGED
- and then a struggle between "Unexpected toolsVersionStatus
notAvailable - using offline status guestToolsNotInstalled"
and "changing status to running"
- repeating within msecs - not on to 30 sec vmtools polling
interval
- rapidly filling /var/log/vmware/hostd.log
- section of log attached (hope the attachment is usable)
/vmfs/volumes/*/<VM>/vmware.log file contains:
===============================================
Jul 21 14:24:12.677: vcpu-1| GuestRpc: Channel 0, guest application toolbox.
Jul 21 14:24:12.677: vcpu-1| Vix: [104286 mainDispatch.c:3169]:
VMAutomationReportPowerStateChange: Reporting power state change
(opcode=2, err=0).
Jul 21 14:24:12.696: vcpu-1| TOOLS ToolsCapabilityGuestConfDirectory
received /etc/vmware-tools
Jul 21 14:24:12.701: vcpu-1| TOOLS setting legacy tools version to
'2147483647', manifest status is 4
Jul 21 14:24:12.702: vcpu-1| DISKLIB-DDB : "toolsVersion" =
"2147483647" (was "0")
Jul 21 14:24:12.732: vcpu-1| VMXVmdb_SetToolsVersionState: status value
set to 'notAvailable'
Jul 21 14:24:12.732: vcpu-1| TOOLS unified loop capability requested by
'toolbox'; now sending options via TCLO
Jul 21 14:24:12.734: vcpu-1| TOOLS sending 'OS_PowerOn' (3) state change
request
Jul 21 14:24:12.735: vcpu-1| Guest: toolbox: Version: build-402641
Jul 21 14:24:12.815: vcpu-0| TOOLS state change 3 returned status 1
The question is what am I forgetting to set?
Thanks.
-- John Wolfe UnXis, Inc.
|
|
From: SourceForge.net <no...@so...> - 2011-07-21 18:44:41
|
Tracker item #3297924, was opened at 2011-05-05 06:49 Message generated for change (Comment added) made by mvanzin You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=989708&aid=3297924&group_id=204462 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed Resolution: None Priority: 5 Private: No Submitted By: Timo Gurr (tgurr) Assigned to: Nobody/Anonymous (nobody) Summary: Wrong "Guest OS" information in vSphere client displayed Initial Comment: The guest is configured as "Other 2.6x Linux (64-bit)", attached screenshot (vmware-tools_stopped.png). # uname -a Linux wwwproxy 2.6.38.5 #2 SMP Wed May 4 12:33:49 CEST 2011 x86_64 Six-Core AMD Opteron(tm) Processor 2425 HE AuthenticAMD GNU/Linux After starting open-vm-tools-2011.04.25-402641 the information in vCenter changes to "Other (32-bit)", attached screenshot (vmware-tools_started.png) which is obviously wrong. VMware vSphere vCenter Client/Server is Version 4.1.0 Build 345043. ---------------------------------------------------------------------- >Comment By: Marcelo Vanzin (mvanzin) Date: 2011-07-21 11:44 Message: I just tried with Fedora 8 (which has a very similar output of "lsb_release -sd") and the code seems to detect Fedora correctly. I'll close this as an issue with the vCenter / VI client code (they may be missing the mapping to show Fedora correctly), but I shouldn't worry much because this is mostly a cosmetic issue. ---------------------------------------------------------------------- Comment By: Marcelo Vanzin (mvanzin) Date: 2011-07-21 10:56 Message: In general, the OS would be reported as "Other (32-bit)" if the code completely failed to recognize that output. The interesting bit is that we do have a check for Fedora in the code, and it should recognize that output. I'll need to try it out to see what's going on. As for what if affects, there are a couple of vCenter features that will look at that value and decide whether they'll run against the VM or not. But I think those features do not support Fedora anyway, so you should be safe. In your case it's probably just a cosmetic thing. ---------------------------------------------------------------------- Comment By: Greg Emerick (gemerick) Date: 2011-07-20 18:21 Message: lsb_release -sd returns: "Fedora release 9 (Sulphur)" I can see where that would get me Other (32-bit). Could you give me some idea of what tools are looking for in the response to indicate 64 bit? If I have to, I'll make this return what's necessary, since it's not used by our appliance for any other purpose. Also, would there be any side-effects to just allowing this to happen? The vmx file is still set to Other (64 bit). ---------------------------------------------------------------------- Comment By: Marcelo Vanzin (mvanzin) Date: 2011-07-20 16:36 Message: Tools will generally use the output of "lsb_release -sd" to figure out the OS information. Fedora 9 should have that; what's the output of that command in your VM? If lsb_release is not available, then that's probably the cause. ---------------------------------------------------------------------- Comment By: Greg Emerick (gemerick) Date: 2011-07-18 19:44 Message: I'm seeing this on Fedora 9 as well with open-vm-tools-2011.06.27-437995. Anything I can provide to assist? vSphere 4.1.0 Build 260247 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=989708&aid=3297924&group_id=204462 |
|
From: SourceForge.net <no...@so...> - 2011-07-21 18:00:43
|
Tracker item #3371547, was opened at 2011-07-19 09:26 Message generated for change (Comment added) made by mvanzin You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=989708&aid=3371547&group_id=204462 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: https://www.google.com/accounts () Assigned to: Nobody/Anonymous (nobody) Summary: patches to allow vmtools to be built with uclibc/buildroot Initial Comment: With the attached patches, vmtools will be able to be built for uclibc. Tested successfully in a buildroot environment. ---------------------------------------------------------------------- >Comment By: Marcelo Vanzin (mvanzin) Date: 2011-07-21 11:00 Message: Hey, could you send me a private e-mail? Sourceforge doesn't seem to show your user info. ---------------------------------------------------------------------- Comment By: Marcelo Vanzin (mvanzin) Date: 2011-07-21 10:42 Message: Thanks. I'll ping our legal department since generally they haven't been very good in processing those. ---------------------------------------------------------------------- Comment By: https://www.google.com/accounts () Date: 2011-07-21 04:20 Message: Contributor agreement sent. ---------------------------------------------------------------------- Comment By: https://www.google.com/accounts () Date: 2011-07-21 04:05 Message: I've substituted patch #4 with a much simpler version -- just moves NO_FLOATING_POINT ifdef to exclude one function. The rest of the code that was problematic can be stubbed out by compiling with NO_FLOATING_POINT. So basically these patches just modify some ifdef's now. Will submit contributor agreement. ---------------------------------------------------------------------- Comment By: Marcelo Vanzin (mvanzin) Date: 2011-07-20 10:08 Message: For the libc bits, I don't think we can accept those into our repository, unless you manage to get the copyright owner to sign off the copyright on those bits to VMware (which I think is unlikely to happen...). ---------------------------------------------------------------------- Comment By: https://www.google.com/accounts () Date: 2011-07-20 01:08 Message: Hi, All patches except one are nothing more than adding an extra #if defined so signing and returning the approval form isn't a problem. Patch number #4 is more problematic however since the code is lifted off libc. What's the contribution policy on that? ---------------------------------------------------------------------- Comment By: Marcelo Vanzin (mvanzin) Date: 2011-07-19 10:30 Message: Thanks for taking the time to do this, but we can't accept any patches unless you follow the instructions at: http://open-vm-tools.sourceforge.net/contribute.php Lots of this code is shared with our closed-sourced products, so we can't just merge (L)GPL code into our code base without being able to change the license. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=989708&aid=3371547&group_id=204462 |
58 messages has been excluded from this view by a project administrator.
