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...> - 2012-08-23 11:48:51
|
Tracker item #3560975, was opened at 2012-08-23 04:40 Message generated for change (Comment added) made by You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=989708&aid=3560975&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: Andreas () Assigned to: Nobody/Anonymous (nobody) Summary: Fails to compile in current Arch Linux Initial Comment: > uname -a Linux einherij-vm-arch 3.4.9-1-ARCH #1 SMP PREEMPT Wed Aug 15 18:11:01 UTC 2012 i686 GNU/Linux > make ... Making all in toolbox make[1]: Entering directory `/home/acs/Downloads/open-vm-tools-8.6.5-621624/toolbox' gcc -DPACKAGE_NAME=\"open-vm-tools\" -DPACKAGE_TARNAME=\"open-vm-tools\" -DPACKAGE_VERSION=\"8.6.5\" -DPACKAGE_STRING=\"open-vm-tools\ 8.6.5\" -DPACKAGE_BUGREPORT=\"ope...@li...\" -DPACKAGE_URL=\"\" -DPACKAGE=\"open-vm-tools\" -DVERSION=\"8.6.5\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DLT_OBJDIR=\".libs/\" -DHAVE_ECVT=1 -DHAVE_FCVT=1 -DNO_PROCPS=1 -DHAVE_CRYPT_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_WCHAR_H=1 -DHAVE_SYS_IO_H=1 -DHAVE_SYS_PARAM_H=1 -DHAVE_SYS_SYSINFO_H=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_USER_H=1 -DHAVE_SYS_VFS_H=1 -DHAVE_UNWIND_H=1 -DHAVE__BOOL=1 -DHAVE_STDBOOL_H=1 -DHAVE_STRUCT_STAT_ST_RDEV=1 -DTIME_WITH_SYS_TIME=1 -I. -DG_LOG_DOMAIN=\"toolbox\" -I../libvmtools -I/home/acs/Downloads/open-vm-tools-8.6.5-621624/lib/include -I/home/acs/Downloads/open-vm-tools-8.6.5-621624/lib/include -DUSING_AUTOCONF=1 -DOPEN_VM_TOOLS -D_REENTRANT -I/usr/include -DUSE_ICU -DVMX86_TOOLS -DNO_CORE_ICU -D_FILE_OFFSET_BITS=64 -D_LARGEFILE64_SOURCE -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -D_SVID_SOURCE -pthread -I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/pango-1.0 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/libpng15 -DGTK2 -g -O2 -Wall -Werror -Wno-pointer-sign -Wno-unused-value -fno-strict-aliasing -Wno-unknown-pragmas -Wno-uninitialized -Wno-unused-but-set-variable -MT vmware_toolbox-toolbox-gtk.o -MD -MP -MF .deps/vmware_toolbox-toolbox-gtk.Tpo -c -o vmware_toolbox-toolbox-gtk.o `test -f 'toolbox-gtk.c' || echo './'`toolbox-gtk.c toolbox-gtk.c: In function ‘main’: toolbox-gtk.c:1213:4: error: ‘gdk_pixbuf_unref’ is deprecated (declared at /usr/include/gdk-pixbuf-2.0/gdk-pixbuf/gdk-pixbuf-core.h:243): Use 'g_object_unref' instead [-Werror=deprecated-declarations] cc1: all warnings being treated as errors make[1]: *** [vmware_toolbox-toolbox-gtk.o] Error 1 make[1]: Leaving directory `/home/acs/Downloads/open-vm-tools-8.6.5-621624/toolbox' make: *** [all-recursive] Error 1 ---------------------------------------------------------------------- >Comment By: Andreas () Date: 2012-08-23 04:48 Message: Please merge upstream: > diff -r open-vm-tools-8.6.5-621624/toolbox/toolbox-gtk.c open-vm-tools-8.6.5-621624~acs/toolbox/toolbox-gtk.c 1213c1213 < g_list_foreach(gIconList, (GFunc)gdk_pixbuf_unref, NULL); --- > g_list_foreach(gIconList, (GFunc)g_object_unref, NULL); ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=989708&aid=3560975&group_id=204462 |
|
From: SourceForge.net <no...@so...> - 2012-08-23 11:40:27
|
Tracker item #3560975, was opened at 2012-08-23 04:40 Message generated for change (Tracker Item Submitted) made by You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=989708&aid=3560975&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: Andreas () Assigned to: Nobody/Anonymous (nobody) Summary: Fails to compile in current Arch Linux Initial Comment: > uname -a Linux einherij-vm-arch 3.4.9-1-ARCH #1 SMP PREEMPT Wed Aug 15 18:11:01 UTC 2012 i686 GNU/Linux > make ... Making all in toolbox make[1]: Entering directory `/home/acs/Downloads/open-vm-tools-8.6.5-621624/toolbox' gcc -DPACKAGE_NAME=\"open-vm-tools\" -DPACKAGE_TARNAME=\"open-vm-tools\" -DPACKAGE_VERSION=\"8.6.5\" -DPACKAGE_STRING=\"open-vm-tools\ 8.6.5\" -DPACKAGE_BUGREPORT=\"ope...@li...\" -DPACKAGE_URL=\"\" -DPACKAGE=\"open-vm-tools\" -DVERSION=\"8.6.5\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DLT_OBJDIR=\".libs/\" -DHAVE_ECVT=1 -DHAVE_FCVT=1 -DNO_PROCPS=1 -DHAVE_CRYPT_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_WCHAR_H=1 -DHAVE_SYS_IO_H=1 -DHAVE_SYS_PARAM_H=1 -DHAVE_SYS_SYSINFO_H=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_USER_H=1 -DHAVE_SYS_VFS_H=1 -DHAVE_UNWIND_H=1 -DHAVE__BOOL=1 -DHAVE_STDBOOL_H=1 -DHAVE_STRUCT_STAT_ST_RDEV=1 -DTIME_WITH_SYS_TIME=1 -I. -DG_LOG_DOMAIN=\"toolbox\" -I../libvmtools -I/home/acs/Downloads/open-vm-tools-8.6.5-621624/lib/include -I/home/acs/Downloads/open-vm-tools-8.6.5-621624/lib/include -DUSING_AUTOCONF=1 -DOPEN_VM_TOOLS -D_REENTRANT -I/usr/include -DUSE_ICU -DVMX86_TOOLS -DNO_CORE_ICU -D_FILE_OFFSET_BITS=64 -D_LARGEFILE64_SOURCE -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -D_SVID_SOURCE -pthread -I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/pango-1.0 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/libpng15 -DGTK2 -g -O2 -Wall -Werror -Wno-pointer-sign -Wno-unused-value -fno-strict-aliasing -Wno-unknown-pragmas -Wno-uninitialized -Wno-unused-but-set-variable -MT vmware_toolbox-toolbox-gtk.o -MD -MP -MF .deps/vmware_toolbox-toolbox-gtk.Tpo -c -o vmware_toolbox-toolbox-gtk.o `test -f 'toolbox-gtk.c' || echo './'`toolbox-gtk.c toolbox-gtk.c: In function ‘main’: toolbox-gtk.c:1213:4: error: ‘gdk_pixbuf_unref’ is deprecated (declared at /usr/include/gdk-pixbuf-2.0/gdk-pixbuf/gdk-pixbuf-core.h:243): Use 'g_object_unref' instead [-Werror=deprecated-declarations] cc1: all warnings being treated as errors make[1]: *** [vmware_toolbox-toolbox-gtk.o] Error 1 make[1]: Leaving directory `/home/acs/Downloads/open-vm-tools-8.6.5-621624/toolbox' make: *** [all-recursive] Error 1 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=989708&aid=3560975&group_id=204462 |
|
From: John W. <jl...@ux...> - 2012-07-24 17:26:09
|
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
<font size="+1"><tt>Dmitry,<br>
<br>
Thanks for removing the blinders on my eyes.<br>
Obviously I read through that many times and only saw the add.<br>
<br>
-- John<span class="moz-smiley-s6"><span> :-[ </span></span><br>
</tt></font><br>
Dmitry Torokhov wrote:
<blockquote cite="mid:364...@dt..."
type="cite">
<pre wrap="">John,
Unlike regular "addl", "xaddl %eax, (%edx)" is "Exchange and Add" instruction,
it exchanges old value in %(ebx) with data in %eax and adds and stores the
result in %(ebx), leaving %eax with old data that is later returned.
Thanks,
Dmitry
On Tuesday, July 24, 2012 12:58:08 PM John Wolfe wrote:
</pre>
<blockquote type="cite">
<pre wrap="">I am working on a port of the open-vm-tools for UnixWare 7.1.4 compiled
with the native C & C++ compiler. As I was coding AT&T/USLC enhanced
ASM functions equivalent to the __asm__ definitions in vm_atomic.h, I
noticed that the GCC x86 __asm__ statement for Atomic_FetchAnd
AddUnfenced() is clearly incorrect.
The comments clearly detail the function as "Atomic read (returned), add
a value, write". It also states that the results are the "value of the
variable before the operation". All functions calling
Atomic_FetchAndAddUnfenced() directly or through layered calls:
* Atomic_FetchAndAdd()
* Atomic_FetchAndInc()
* Atomic_FetchAndDec()
all clearly expect the return value to be the value of the variable
before the operation.
The ASM code generated for the GCC x86 compiler (as well as the MSC
compiler before version 1310) is returning the the uint32 "value" that
is to be added to the memory variable, not the value of the memory
variable before the operation.
Lifting just the GCC x86 ASM definition from vm_atomic.h
typedef long uint32;
/* Basic atomic type: 32 bits */
typedef struct Atomic_uint32 {
volatile uint32 value;
} Atomic_uint32;
uint32
Atomic_FetchAndAddUnfenced(Atomic_uint32 *var, // IN
uint32 val) // IN
{
/* Checked against the Intel manual and GCC --walken */
__asm__ __volatile__(
"lock; xaddl %0, %1"
: "=r" (val),
"+m" (var->value)
: "0" (val)
: "cc"
);
return val;
}
and compiling with "gcc -S -O2" yields the following assembly code
(comments added)
.file "gccasmadd.c"
.version "01.01"
.text
.globl Atomic_FetchAndAddUnfenced
.type Atomic_FetchAndAddUnfenced, @function
Atomic_FetchAndAddUnfenced:
pushl %ebp
movl %esp, %ebp
movl 8(%ebp), %edx # var into %edx
movl 12(%ebp), %eax # value into %eax
/APP
lock; xaddl %eax, (%edx) # add value to memory addressed
by %edx
/NO_APP
popl %ebp
ret # return (%eax) value is
the incoming parameter "value" !!!!
.size Atomic_FetchAndAddUnfenced, .-Atomic_FetchAndAddUnfenced
.ident "GCC: (GNU) 4.0.2"
From this, a number of pieces of code cannot function as expected if
the GNU C/C++ compiler
is used. Atomic_FetchAndInc() will always return the value 1.
* HgfsChannel server and data reference counts will always appear to
be 1; never zero which causes channel initialization.
* Linux VMCI delayed datagram queues would never MAX out - always 1.
* VThreadBaseSimpleNoID() will always come up with a newID of 1 with
the following statement
o newID = Atomic_FetchAndInc(&vthreadBaseGlobals.dynamicID);
And there are defines and conditionals in the header which suggests that
this may be a generic header that is used across other VMware
products. That makes me wonder what other problems may exist.
While I am working with the open-vm-tools-2011.04.25-402641 source drop
as a starting point, I have confirmed that the __asm__ code in question
in /lib/include/vm_atomic.h is still present in recent the releases.
* open-vm-tools-2012.05.21-724730
* open-vm-tools-8.8.2-590212
* open-vm-tools-8.6.5-621624
Is it possible that vm_atomic.h in the open-vm-tools source tree simply
needs a more recent and presumably correct version from the VMware
source tree?
-- John Wolfe UnXis, Inc
</pre>
</blockquote>
</blockquote>
</body>
</html>
|
|
From: Dmitry T. <dt...@vm...> - 2012-07-24 17:15:54
|
John,
Unlike regular "addl", "xaddl %eax, (%edx)" is "Exchange and Add" instruction,
it exchanges old value in %(ebx) with data in %eax and adds and stores the
result in %(ebx), leaving %eax with old data that is later returned.
Thanks,
Dmitry
On Tuesday, July 24, 2012 12:58:08 PM John Wolfe wrote:
> I am working on a port of the open-vm-tools for UnixWare 7.1.4 compiled
> with the native C & C++ compiler. As I was coding AT&T/USLC enhanced
> ASM functions equivalent to the __asm__ definitions in vm_atomic.h, I
> noticed that the GCC x86 __asm__ statement for Atomic_FetchAnd
> AddUnfenced() is clearly incorrect.
>
> The comments clearly detail the function as "Atomic read (returned), add
> a value, write". It also states that the results are the "value of the
> variable before the operation". All functions calling
> Atomic_FetchAndAddUnfenced() directly or through layered calls:
>
> * Atomic_FetchAndAdd()
> * Atomic_FetchAndInc()
> * Atomic_FetchAndDec()
>
> all clearly expect the return value to be the value of the variable
> before the operation.
>
> The ASM code generated for the GCC x86 compiler (as well as the MSC
> compiler before version 1310) is returning the the uint32 "value" that
> is to be added to the memory variable, not the value of the memory
> variable before the operation.
>
> Lifting just the GCC x86 ASM definition from vm_atomic.h
>
> typedef long uint32;
>
> /* Basic atomic type: 32 bits */
> typedef struct Atomic_uint32 {
> volatile uint32 value;
> } Atomic_uint32;
>
> uint32
> Atomic_FetchAndAddUnfenced(Atomic_uint32 *var, // IN
> uint32 val) // IN
> {
> /* Checked against the Intel manual and GCC --walken */
> __asm__ __volatile__(
> "lock; xaddl %0, %1"
>
> : "=r" (val),
>
> "+m" (var->value)
>
> : "0" (val)
> : "cc"
>
> );
> return val;
> }
>
> and compiling with "gcc -S -O2" yields the following assembly code
> (comments added)
>
> .file "gccasmadd.c"
> .version "01.01"
> .text
> .globl Atomic_FetchAndAddUnfenced
> .type Atomic_FetchAndAddUnfenced, @function
> Atomic_FetchAndAddUnfenced:
> pushl %ebp
> movl %esp, %ebp
> movl 8(%ebp), %edx # var into %edx
> movl 12(%ebp), %eax # value into %eax
> /APP
> lock; xaddl %eax, (%edx) # add value to memory addressed
> by %edx
> /NO_APP
> popl %ebp
> ret # return (%eax) value is
> the incoming parameter "value" !!!!
> .size Atomic_FetchAndAddUnfenced, .-Atomic_FetchAndAddUnfenced
> .ident "GCC: (GNU) 4.0.2"
>
> From this, a number of pieces of code cannot function as expected if
> the GNU C/C++ compiler
> is used. Atomic_FetchAndInc() will always return the value 1.
>
> * HgfsChannel server and data reference counts will always appear to
> be 1; never zero which causes channel initialization.
> * Linux VMCI delayed datagram queues would never MAX out - always 1.
> * VThreadBaseSimpleNoID() will always come up with a newID of 1 with
> the following statement
> o newID = Atomic_FetchAndInc(&vthreadBaseGlobals.dynamicID);
>
> And there are defines and conditionals in the header which suggests that
> this may be a generic header that is used across other VMware
> products. That makes me wonder what other problems may exist.
>
> While I am working with the open-vm-tools-2011.04.25-402641 source drop
> as a starting point, I have confirmed that the __asm__ code in question
> in /lib/include/vm_atomic.h is still present in recent the releases.
>
> * open-vm-tools-2012.05.21-724730
> * open-vm-tools-8.8.2-590212
> * open-vm-tools-8.6.5-621624
>
> Is it possible that vm_atomic.h in the open-vm-tools source tree simply
> needs a more recent and presumably correct version from the VMware
> source tree?
>
> -- John Wolfe UnXis, Inc
|
|
From: John W. <jl...@ux...> - 2012-07-24 16:58:30
|
I am working on a port of the open-vm-tools for UnixWare 7.1.4 compiled
with the native C & C++ compiler. As I was coding AT&T/USLC enhanced
ASM functions equivalent to the __asm__ definitions in vm_atomic.h, I
noticed that the GCC x86 __asm__ statement for Atomic_FetchAnd
AddUnfenced() is clearly incorrect.
The comments clearly detail the function as "Atomic read (returned), add
a value, write". It also states that the results are the "value of the
variable before the operation". All functions calling
Atomic_FetchAndAddUnfenced() directly or through layered calls:
* Atomic_FetchAndAdd()
* Atomic_FetchAndInc()
* Atomic_FetchAndDec()
all clearly expect the return value to be the value of the variable
before the operation.
The ASM code generated for the GCC x86 compiler (as well as the MSC
compiler before version 1310) is returning the the uint32 "value" that
is to be added to the memory variable, not the value of the memory
variable before the operation.
Lifting just the GCC x86 ASM definition from vm_atomic.h
typedef long uint32;
/* Basic atomic type: 32 bits */
typedef struct Atomic_uint32 {
volatile uint32 value;
} Atomic_uint32;
uint32
Atomic_FetchAndAddUnfenced(Atomic_uint32 *var, // IN
uint32 val) // IN
{
/* Checked against the Intel manual and GCC --walken */
__asm__ __volatile__(
"lock; xaddl %0, %1"
: "=r" (val),
"+m" (var->value)
: "0" (val)
: "cc"
);
return val;
}
and compiling with "gcc -S -O2" yields the following assembly code
(comments added)
.file "gccasmadd.c"
.version "01.01"
.text
.globl Atomic_FetchAndAddUnfenced
.type Atomic_FetchAndAddUnfenced, @function
Atomic_FetchAndAddUnfenced:
pushl %ebp
movl %esp, %ebp
movl 8(%ebp), %edx # var into %edx
movl 12(%ebp), %eax # value into %eax
/APP
lock; xaddl %eax, (%edx) # add value to memory addressed
by %edx
/NO_APP
popl %ebp
ret # return (%eax) value is
the incoming parameter "value" !!!!
.size Atomic_FetchAndAddUnfenced, .-Atomic_FetchAndAddUnfenced
.ident "GCC: (GNU) 4.0.2"
From this, a number of pieces of code cannot function as expected if
the GNU C/C++ compiler
is used. Atomic_FetchAndInc() will always return the value 1.
* HgfsChannel server and data reference counts will always appear to
be 1; never zero which causes channel initialization.
* Linux VMCI delayed datagram queues would never MAX out - always 1.
* VThreadBaseSimpleNoID() will always come up with a newID of 1 with
the following statement
o newID = Atomic_FetchAndInc(&vthreadBaseGlobals.dynamicID);
And there are defines and conditionals in the header which suggests that
this may be a generic header that is used across other VMware
products. That makes me wonder what other problems may exist.
While I am working with the open-vm-tools-2011.04.25-402641 source drop
as a starting point, I have confirmed that the __asm__ code in question
in /lib/include/vm_atomic.h is still present in recent the releases.
* open-vm-tools-2012.05.21-724730
* open-vm-tools-8.8.2-590212
* open-vm-tools-8.6.5-621624
Is it possible that vm_atomic.h in the open-vm-tools source tree simply
needs a more recent and presumably correct version from the VMware
source tree?
-- John Wolfe UnXis, Inc
|
|
From: Matthias A. <gu...@un...> - 2012-07-18 12:46:16
|
El día Wednesday, July 18, 2012 a las 11:57:15AM +0200, Matthias Apitz escribió: > > Hello, > > I have the following configuration: > > host: Win7, VMware workstation 7.1.3 build-324285 > guest: FreeBSD vm-9Current 9.0-CURRENT FreeBSD 9.0-CURRENT #2 r220692: Sun Apr 17 03:28:12 CEST 2011 guru@tinyCurrent:/usr/obj/usr/src/sys/GENERIC i386 > open-vm-tools-313025_2 Open VMware tools for FreeBSD VMware guests > > and I run the guest in fullscreen mode with the VMware toolbar hidden, > only a small stripe of it is visible on top of the display; > > sometimes, while moving the mouse to some upper part, the guest looses > the focus when the mouse is around 1cm away from the hidden toolbar, the > toolbar falls down and *both* have now the focus, guest and VMware; a > click, for example to close a window in guest, already once suspended > the guest, because VMware got the click. I have here a small JPEG showing the two mouse pointers at the same time, the white one of Windows and the black one of the FreeBSD guest; the toolbar has falling down; guess what will happen on click :-) it will try to crash VMware! matthias -- Matthias Apitz e <gu...@un...> - w http://www.unixarea.de/ UNIX since V7 on PDP-11, UNIX on mainframe since ESER 1055 (IBM /370) UNIX on x86 since SVR4.2 UnixWare 2.1.2, FreeBSD since 2.2.5 |
|
From: Matthias A. <gu...@un...> - 2012-07-18 11:55:38
|
Hello,
I have the following configuration:
host: Win7, VMware workstation 7.1.3 build-324285
guest: FreeBSD vm-9Current 9.0-CURRENT FreeBSD 9.0-CURRENT #2 r220692: Sun Apr 17 03:28:12 CEST 2011 guru@tinyCurrent:/usr/obj/usr/src/sys/GENERIC i386
open-vm-tools-313025_2 Open VMware tools for FreeBSD VMware guests
and I run the guest in fullscreen mode with the VMware toolbar hidden,
only a small stripe of it is visible on top of the display;
sometimes, while moving the mouse to some upper part, the guest looses
the focus when the mouse is around 1cm away from the hidden toolbar, the
toolbar falls down and *both* have now the focus, guest and VMware; a
click, for example to close a window in guest, already once suspended
the guest, because VMware got the click.
Is this a known issue?
Thanks
matthias
--
Matthias Apitz
e <gu...@un...> - w http://www.unixarea.de/
UNIX since V7 on PDP-11, UNIX on mainframe since ESER 1055 (IBM /370)
UNIX on x86 since SVR4.2 UnixWare 2.1.2, FreeBSD since 2.2.5
|
|
From: John W. <jl...@ux...> - 2012-07-17 18:05:49
|
Robert, UnXis Inc. is currently porting the open-vm-tools to be released with their UW714 for VMware release that is in Progress. This port includes additional or later versions of other open-source projects required by the open-vm-tools code. - icu - International Components for Unicode - libdnet - low-level networking routines - glib2 - GIMP Portability Libraries - version 2 - gettext - GNU gettext runtime - uriparser - URI Parser Library As well as development and testing tools - pkg-config - Provide meta-information about installed libraries - check - Unit Testing Framework for C - cunit - Unit Testing Framework for C - cpptest - C++ Unit Testing Framework As you can see there are a number of libraries and tools needed just to get started on a port. So tuned and stay in contact with your UnixWare salesman or reseller. -- John Wolfe (UnXis Inc.) robert ch wrote: > Hello everybody. > > I have a simple question, > > does Open Virtual Machine Tools work with SCO UnixWare 7.1.4 MP4 and ESX? > > Thanks for yor time > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > open-vm-tools-devel mailing list > ope...@li... > https://lists.sourceforge.net/lists/listinfo/open-vm-tools-devel > |
|
From: robert ch <chr...@go...> - 2012-07-17 14:46:45
|
Hello everybody. I have a simple question, does Open Virtual Machine Tools work with SCO UnixWare 7.1.4 MP4 and ESX? Thanks for yor time |
|
From: SourceForge.net <no...@so...> - 2012-07-13 17:48:42
|
Tracker item #3543664, was opened at 2012-07-13 10:48 Message generated for change (Tracker Item Submitted) made by You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=989708&aid=3543664&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: DS () Assigned to: Nobody/Anonymous (nobody) Summary: open-vm-tools-kmod 2012.05.21.724730 fails to compile Initial Comment: Gentoo 3.1.5 gcc 4.5.3-r2 glibc 2.14.1-r3, glib 2.30.3 open-vm-tools-kmod-2012.05.21.724730 fails to compile. Following error: make[1]: Entering directory `/usr/src/linux-3.1.5-hardened' CC [M] /var/tmp/portage/app-emulation/open-vm-tools-kmod-2012.05.21.724730/work/open-vm-tools-2012.05.21-724730/modules/linux/vmxnet/vmxnet.o /var/tmp/portage/app-emulation/open-vm-tools-kmod-2012.05.21.724730/work/open-vm-tools-2012.05.21-724730/modules/linux/vmxnet/vmxnet.c: In function 'vmxnet_map_pkt': /var/tmp/portage/app-emulation/open-vm-tools-kmod-2012.05.21.724730/work/open-vm-tools-2012.05.21-724730/modules/linux/vmxnet/vmxnet.c:2056:2: error: implicit declaration of function 'skb_frag_size' /var/tmp/portage/app-emulation/open-vm-tools-kmod-2012.05.21.724730/work/open-vm-tools-2012.05.21-724730/modules/linux/vmxnet/vmxnet.c:2068:42: error: request for member 'p' in something not a structure or union /var/tmp/portage/app-emulation/open-vm-tools-kmod-2012.05.21.724730/work/open-vm-tools-2012.05.21-724730/modules/linux/vmxnet/vmxnet.c:2098:36: error: request for member 'p' in something not a structure or union /var/tmp/portage/app-emulation/open-vm-tools-kmod-2012.05.21.724730/work/open-vm-tools-2012.05.21-724730/modules/linux/vmxnet/vmxnet.c: In function 'vmxnet_rx_frags': /var/tmp/portage/app-emulation/open-vm-tools-kmod-2012.05.21.724730/work/open-vm-tools-2012.05.21-724730/modules/linux/vmxnet/vmxnet.c:2600:10: error: implicit declaration of function '__skb_frag_set_page' make[2]: *** [/var/tmp/portage/app-emulation/open-vm-tools-kmod-2012.05.21.724730/work/open-vm-tools-2012.05.21-724730/modules/linux/vmxnet/vmxnet.o] Error 1 make[1]: *** [_module_/var/tmp/portage/app-emulation/open-vm-tools-kmod-2012.05.21.724730/work/open-vm-tools-2012.05.21-724730/modules/linux/vmxnet] Error 2 make[1]: Leaving directory `/usr/src/linux-3.1.5-hardened' make: *** [vmxnet.ko] Error 2 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=989708&aid=3543664&group_id=204462 |
|
From: SourceForge.net <no...@so...> - 2012-07-13 17:43:25
|
Tracker item #3471380, was opened at 2012-01-09 06:36 Message generated for change (Comment added) made by You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=989708&aid=3471380&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: https://www.google.com/accounts () Assigned to: Nobody/Anonymous (nobody) Summary: vmxnet 2011.12.20.562307 failed to compile for 3.1.6 kernel Initial Comment: make[1]: Entering directory `/usr/src/linux-3.1.6-gentoo' CC [M] /var/tmp/portage/app-emulation/open-vm-tools-kmod-2011.12.20.562307/work/open-vm-tools-2011.12.20-562307/modules/linux/vmxnet/vmxnet.o /var/tmp/portage/app-emulation/open-vm-tools-kmod-2011.12.20.562307/work/open-vm-tools-2011.12.20-562307/modules/linux/vmxnet/vmxnet.c: In function 'vmxnet_map_pkt': /var/tmp/portage/app-emulation/open-vm-tools-kmod-2011.12.20.562307/work/open-vm-tools-2011.12.20-562307/modules/linux/vmxnet/vmxnet.c:2045:2: error: implicit declaration of function 'skb_frag_size' /var/tmp/portage/app-emulation/open-vm-tools-kmod-2011.12.20.562307/work/open-vm-tools-2011.12.20-562307/modules/linux/vmxnet/vmxnet.c:2057:42: error: request for member 'p' in something not a structure or union /var/tmp/portage/app-emulation/open-vm-tools-kmod-2011.12.20.562307/work/open-vm-tools-2011.12.20-562307/modules/linux/vmxnet/vmxnet.c:2087:36: error: request for member 'p' in something not a structure or union /var/tmp/portage/app-emulation/open-vm-tools-kmod-2011.12.20.562307/work/open-vm-tools-2011.12.20-562307/modules/linux/vmxnet/vmxnet.c: In function 'vmxnet_rx_frags': /var/tmp/portage/app-emulation/open-vm-tools-kmod-2011.12.20.562307/work/open-vm-tools-2011.12.20-562307/modules/linux/vmxnet/vmxnet.c:2589:10: error: implicit declaration of function '__skb_frag_set_page' make[2]: *** [/var/tmp/portage/app-emulation/open-vm-tools-kmod-2011.12.20.562307/work/open-vm-tools-2011.12.20-562307/modules/linux/vmxnet/vmxnet.o] Error 1 make[1]: *** [_module_/var/tmp/portage/app-emulation/open-vm-tools-kmod-2011.12.20.562307/work/open-vm-tools-2011.12.20-562307/modules/linux/vmxnet] Error 2 make[1]: Leaving directory `/usr/src/linux-3.1.6-gentoo' make: *** [vmxnet.ko] Error 2 ---------------------------------------------------------------------- Comment By: DS () Date: 2012-07-13 10:43 Message: Replicated in Gentoo 3.1.5, gcc 4.5.3-r2, glibc 2.14.1-r3. make[1]: Entering directory `/usr/src/linux-3.1.5-hardened' CC [M] /var/tmp/portage/app-emulation/open-vm-tools-kmod-2012.05.21.724730/work/open-vm-tools-2012.05.21-724730/modules/linux/vmxnet/vmxnet.o /var/tmp/portage/app-emulation/open-vm-tools-kmod-2012.05.21.724730/work/open-vm-tools-2012.05.21-724730/modules/linux/vmxnet/vmxnet.c: In function 'vmxnet_map_pkt': /var/tmp/portage/app-emulation/open-vm-tools-kmod-2012.05.21.724730/work/open-vm-tools-2012.05.21-724730/modules/linux/vmxnet/vmxnet.c:2056:2: error: implicit declaration of function 'skb_frag_size' /var/tmp/portage/app-emulation/open-vm-tools-kmod-2012.05.21.724730/work/open-vm-tools-2012.05.21-724730/modules/linux/vmxnet/vmxnet.c:2068:42: error: request for member 'p' in something not a structure or union /var/tmp/portage/app-emulation/open-vm-tools-kmod-2012.05.21.724730/work/open-vm-tools-2012.05.21-724730/modules/linux/vmxnet/vmxnet.c:2098:36: error: request for member 'p' in something not a structure or union /var/tmp/portage/app-emulation/open-vm-tools-kmod-2012.05.21.724730/work/open-vm-tools-2012.05.21-724730/modules/linux/vmxnet/vmxnet.c: In function 'vmxnet_rx_frags': /var/tmp/portage/app-emulation/open-vm-tools-kmod-2012.05.21.724730/work/open-vm-tools-2012.05.21-724730/modules/linux/vmxnet/vmxnet.c:2600:10: error: implicit declaration of function '__skb_frag_set_page' make[2]: *** [/var/tmp/portage/app-emulation/open-vm-tools-kmod-2012.05.21.724730/work/open-vm-tools-2012.05.21-724730/modules/linux/vmxnet/vmxnet.o] Error 1 make[1]: *** [_module_/var/tmp/portage/app-emulation/open-vm-tools-kmod-2012.05.21.724730/work/open-vm-tools-2012.05.21-724730/modules/linux/vmxnet] Error 2 make[1]: Leaving directory `/usr/src/linux-3.1.5-hardened' make: *** [vmxnet.ko] Error 2 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=989708&aid=3471380&group_id=204462 |
|
From: SourceForge.net <no...@so...> - 2012-07-07 04:55:44
|
Tracker item #3533070, was opened at 2012-06-07 17:34 Message generated for change (Comment added) made by yosimoto You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=989708&aid=3533070&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: 9 Private: No Submitted By: Nate Muench (n-minker) Assigned to: Nobody/Anonymous (nobody) Summary: Patch to fix (or help fix) build issues with glib 2.31 Initial Comment: As it stands right now open-vm-tools (May dev package) doesn't build with glib 2.31 or greater because some of the threads have been depreciated. So, I've working on getting packaging the current dev release for Ubuntu Quantal. I've attached a patch that isolates the lines of code that needs to be changed. I had a problem with vmtoolsd (it was giving me a segment fault at boot), so that part isn't right I think the easiest way to fix this is to add if statements. Please, fix it. Don't say you won't fix it because "only effects Ubuntu," but other distros use these newer versions of glib. I've done all I can with my patch, I can't figure out why vmtoolsd is giving me faults. Thanks ---------------------------------------------------------------------- Comment By: Hiromasa YOSHIMOTO (yosimoto) Date: 2012-07-06 21:55 Message: I've modified the patch, which is available at http://www.momonga-linux.org/~y/open-vm-tools-2012.05.21-724730-glib231.patch Please check it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=989708&aid=3533070&group_id=204462 |
|
From: SourceForge.net <no...@so...> - 2012-06-26 01:00:34
|
Tracker item #3537233, was opened at 2012-06-22 11:19 Message generated for change (Comment added) made by lousybrit You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=989708&aid=3537233&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: Michael Roitzsch (mroi) Assigned to: Nobody/Anonymous (nobody) Summary: patch for running eCryptfs on top of vmhgfs Initial Comment: I want to create a setup where a vmhgfs share is encrypted using eCryptfs. However, when running eCryptfs on top of vmhgfs, I am unable to create files in the mounted eCryptfs. The error message from the kernel is: Jun 12 00:32:41 Thyone kernel: [ 1441.259207] ecryptfs_initialize_file: Error attempting to initialize the lower file for the dentry with name [.Xauthority]; rc = [-2] Jun 12 00:32:49 Thyone kernel: [ 1449.405191] Error opening lower file for lower_dentry [0xffff8800798c9b00] and lower_mnt [0xffff88007b83d000]; rc = [-2] I looked through the vmhgfs and eCryptfs sources and was able to fix the problem with the attached patch. The explanation is embedded into the patch as a comment. ---------------------------------------------------------------------- Comment By: Steve (lousybrit) Date: 2012-06-25 18:00 Message: Thanks, I will look at adding your changes. Steve ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=989708&aid=3537233&group_id=204462 |
|
From: SourceForge.net <no...@so...> - 2012-06-26 00:59:58
|
Tracker item #3537235, was opened at 2012-06-22 11:27 Message generated for change (Comment added) made by lousybrit You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=989708&aid=3537235&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: Michael Roitzsch (mroi) Assigned to: Nobody/Anonymous (nobody) Summary: uid and gid mount options should be checked for chown() Initial Comment: When mounting vmhgfs with the uid or gid mount options, these options should be considered when a chown() system call is being executed to change the owner or group. When the caller is running with the same uid/gid as in the mount option and tries to chown() a file to that same uid/gid, the operation should be treated as a noop and should not return an error. The current code paths check, whether the change would be allowed on the host, which they may not. However, since no actual change is being requested (uid/gid is "changed" to the current value), the error is unexpected by the caller. I need this change to use vmhgfs as a user home directory. Some per-user agents (I noticed with pulse audio) want to be really safe in creating a secure directory in the user’s $HOME: They create a new directory and then chown() it to the uid/gid of the user. With vmhgfs underneath, this will result in an error, causing the agent to quit. The attached patch fixes the issue for me. ---------------------------------------------------------------------- Comment By: Steve (lousybrit) Date: 2012-06-25 17:59 Message: Thanks, I will look into adding your changes. Steve ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=989708&aid=3537235&group_id=204462 |
|
From: SourceForge.net <no...@so...> - 2012-06-22 18:27:17
|
Tracker item #3537235, was opened at 2012-06-22 11:27 Message generated for change (Tracker Item Submitted) made by mroi You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=989708&aid=3537235&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: Michael Roitzsch (mroi) Assigned to: Nobody/Anonymous (nobody) Summary: uid and gid mount options should be checked for chown() Initial Comment: When mounting vmhgfs with the uid or gid mount options, these options should be considered when a chown() system call is being executed to change the owner or group. When the caller is running with the same uid/gid as in the mount option and tries to chown() a file to that same uid/gid, the operation should be treated as a noop and should not return an error. The current code paths check, whether the change would be allowed on the host, which they may not. However, since no actual change is being requested (uid/gid is "changed" to the current value), the error is unexpected by the caller. I need this change to use vmhgfs as a user home directory. Some per-user agents (I noticed with pulse audio) want to be really safe in creating a secure directory in the user’s $HOME: They create a new directory and then chown() it to the uid/gid of the user. With vmhgfs underneath, this will result in an error, causing the agent to quit. The attached patch fixes the issue for me. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=989708&aid=3537235&group_id=204462 |
|
From: SourceForge.net <no...@so...> - 2012-06-22 18:19:14
|
Tracker item #3537233, was opened at 2012-06-22 11:19 Message generated for change (Tracker Item Submitted) made by mroi You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=989708&aid=3537233&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: Michael Roitzsch (mroi) Assigned to: Nobody/Anonymous (nobody) Summary: patch for running eCryptfs on top of vmhgfs Initial Comment: I want to create a setup where a vmhgfs share is encrypted using eCryptfs. However, when running eCryptfs on top of vmhgfs, I am unable to create files in the mounted eCryptfs. The error message from the kernel is: Jun 12 00:32:41 Thyone kernel: [ 1441.259207] ecryptfs_initialize_file: Error attempting to initialize the lower file for the dentry with name [.Xauthority]; rc = [-2] Jun 12 00:32:49 Thyone kernel: [ 1449.405191] Error opening lower file for lower_dentry [0xffff8800798c9b00] and lower_mnt [0xffff88007b83d000]; rc = [-2] I looked through the vmhgfs and eCryptfs sources and was able to fix the problem with the attached patch. The explanation is embedded into the patch as a comment. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=989708&aid=3537233&group_id=204462 |
|
From: SourceForge.net <no...@so...> - 2012-06-08 00:35:07
|
Tracker item #3533070, was opened at 2012-06-07 17:34 Message generated for change (Settings changed) made by n-minker You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=989708&aid=3533070&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: 9 Private: No Submitted By: Nate Muench (n-minker) Assigned to: Nobody/Anonymous (nobody) Summary: Patch to fix (or help fix) build issues with glib 2.31 Initial Comment: As it stands right now open-vm-tools (May dev package) doesn't build with glib 2.31 or greater because some of the threads have been depreciated. So, I've working on getting packaging the current dev release for Ubuntu Quantal. I've attached a patch that isolates the lines of code that needs to be changed. I had a problem with vmtoolsd (it was giving me a segment fault at boot), so that part isn't right I think the easiest way to fix this is to add if statements. Please, fix it. Don't say you won't fix it because "only effects Ubuntu," but other distros use these newer versions of glib. I've done all I can with my patch, I can't figure out why vmtoolsd is giving me faults. Thanks ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=989708&aid=3533070&group_id=204462 |
|
From: SourceForge.net <no...@so...> - 2012-06-08 00:34:37
|
Tracker item #3533070, was opened at 2012-06-07 17:34 Message generated for change (Tracker Item Submitted) made by n-minker You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=989708&aid=3533070&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: Patch to fix (or help fix) build issues with glib 2.31 Initial Comment: As it stands right now open-vm-tools (May dev package) doesn't build with glib 2.31 or greater because some of the threads have been depreciated. So, I've working on getting packaging the current dev release for Ubuntu Quantal. I've attached a patch that isolates the lines of code that needs to be changed. I had a problem with vmtoolsd (it was giving me a segment fault at boot), so that part isn't right I think the easiest way to fix this is to add if statements. Please, fix it. Don't say you won't fix it because "only effects Ubuntu," but other distros use these newer versions of glib. I've done all I can with my patch, I can't figure out why vmtoolsd is giving me faults. Thanks ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=989708&aid=3533070&group_id=204462 |
|
From: Dmitry T. <dt...@vm...> - 2012-06-01 20:55:15
|
Hi Stephen, On Friday, June 01, 2012 12:47:36 PM Stephen Hemminger wrote: > If same device is mounted in multiple places like Vyatta does > with their installation, then VSphere snapshot would fail. > > The fix is to ignore -EBUSY which means filesystem is already frozen. > > See: > https://bugzilla.vyatta.com/show_bug.cgi?id=8108 > http://sourceforge.net/tracker/?func=detail&aid=3485535&group_id=204462&ati > d=989708 > > Patch against 8.8.1 but same issue exists in 8.8.2 Thanks for the patch, we have already fixed this issue in master branch. I will see if we can get it into stable branches but since 8.8.x branch is aligned with our hosted products I might not be able to. Thanks, Dmitry |
|
From: Stephen H. <she...@vy...> - 2012-06-01 20:06:32
|
If same device is mounted in multiple places like Vyatta does with their installation, then VSphere snapshot would fail. The fix is to ignore -EBUSY which means filesystem is already frozen. See: https://bugzilla.vyatta.com/show_bug.cgi?id=8108 http://sourceforge.net/tracker/?func=detail&aid=3485535&group_id=204462&atid=989708 Patch against 8.8.1 but same issue exists in 8.8.2 --- lib/syncDriver/syncDriverLinux.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/lib/syncDriver/syncDriverLinux.c b/lib/syncDriver/syncDriverLinux.c index 794a4b4..32c1a11 100644 --- a/lib/syncDriver/syncDriverLinux.c +++ b/lib/syncDriver/syncDriverLinux.c @@ -165,12 +165,13 @@ LinuxDriver_Freeze(const char *paths, if (ioctl(fd, FIFREEZE) == -1) { /* * If the ioctl does not exist, Linux will return ENOTTY. If it's not - * supported on the device, we get EOPNOTSUPP. Ignore the latter, + * supported on the device, we get EOPNOTSUPP. If filesystem is already + * frozen, then return EBUSY. Ignore the latter two, * since freezing does not make sense for all fs types, and some * Linux fs drivers may not have been hooked up in the running kernel. */ close(fd); - if (errno != EOPNOTSUPP) { + if (errno != EOPNOTSUPP && errno != EBUSY) { Debug(LGPFX "ioctl failed: %d (%s)\n", errno, strerror(errno)); err = first ? SD_UNAVAILABLE : SD_ERROR; break; -- 1.7.10 |
|
From: SourceForge.net <no...@so...> - 2012-05-25 17:54:39
|
Tracker item #3529801, was opened at 2012-05-25 10:54 Message generated for change (Tracker Item Submitted) made by You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=989708&aid=3529801&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: Build failes at backdoorGcc64.c Initial Comment: It's failing to compile at lib/backdoor/backdoorGcc64.c Any ideas? $ pwd /build/work/open-vm-tools-8.8.2-590212 $ ./configure --without-pam --without-x --without-dnet --without-icu --without-procps $ make ... backdoorGcc64.c: In function 'Backdoor_InOut': backdoorGcc64.c:78: error: PIC register 'rbx' clobbered in 'asm' backdoorGcc64.c: In function 'BackdoorHbIn': backdoorGcc64.c:144: error: PIC register 'rbx' clobbered in 'asm' backdoorGcc64.c: In function 'BackdoorHbOut': backdoorGcc64.c:197: error: PIC register 'rbx' clobbered in 'asm' make[2]: *** [backdoorGcc64.lo] Error 1 make[2]: Leaving directory `/mail/build/work/open-vm-tools-8.8.2-590212/lib/backdoor' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/mail/build/work/open-vm-tools-8.8.2-590212/lib' make: *** [all-recursive] Error 1 $ uname -a Linux barracuda 2.6.36.2-x86_64-_edit_1 #62 SMP Wed Nov 30 18:25:48 PST 2011 x86_64 x86_64 x86_64 GNU/Linux $ gcc -v Using built-in specs. Target: i686-pc-linux-gnu Configured with: ../butterfly-toolchain/configure --prefix=/usr --libexecdir=/usr/lib --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu --enable-languages=c,c++ --enable-checking --disable-werror Thread model: posix gcc version 4.1.2 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=989708&aid=3529801&group_id=204462 |
|
From: SourceForge.net <no...@so...> - 2012-05-23 20:38:25
|
Tracker item #3527672, was opened at 2012-05-17 12:32 Message generated for change (Comment added) made by johnpeterson You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=989708&aid=3527672&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: John Peterson (johnpeterson) Assigned to: Nobody/Anonymous (nobody) Summary: Symlink in Linux guest Initial Comment: Which guests support symlinks in a Windows 7 VMware Workstation host NTFS share? This artifact https://sourceforge.net/tracker/index.php?func=detail&aid=2531303&group_id=204462&atid=989708 seems to say that Gentoo guests support "ln -s". In Ubuntu the operation cd /mnt/hgfs/shared; touch foo; ln -snf foo fum return ln: failed to create symbolic link `fum': Permission denied and if sharedFolder0.followSymlinks = "FALSE" (in .vmx) it returns ln: failed to create symbolic link `fum': Operation not supported # cat /etc/issue Ubuntu 12.04 LTS \n \l # sudo dpkg -s open-vm-tools Version: 2011.12.20-562307-0ubuntu1 VMware Workstation 8.0.2 build-591240 ---------------------------------------------------------------------- >Comment By: John Peterson (johnpeterson) Date: 2012-05-23 13:38 Message: I've tried the Windows NFS servers and can give some comments about using them to build projects over. My test have been to checkout and build vlc and firefox from Debian/Ubuntu nfs-common. Microsoft Server for NFS (3.5, 2003-11-08) Not tested I've not figured out how to run it in Windows 7 x64. nfssvc.exe and pcnfsd.exe exit silently shortly after they are run. It could be because of a simple missing file or registry setting or a more complex reason such as incompatibility with a system file that can't be replaced. (It's not possible to run the installer (SFU35SEL_EN.exe) in Windows 7 x64 and I've not thoroughly examined all files and settings it writes to make sure it's not a case of a missing file or setting.) Cygwin nfs-server (2.5, 2006-10-17) vlc make fails because the symlink support fails for 'tar x'. (For example tar xvjfk vlc-contrib-i686-w64-mingw32-latest.tar.bz2 fails with the message "tar: [i686-w64-mingw32/lib/libdts.a]: Cannot utime: No such file or directory".) Another problem is that hard (junction) and symbolic folder links on the server are presented as symlinks to the client, which of course don't have the paths pointed to. I prefer to share one folder on the NFS server and link folders from that share, it's a significant burden to not have this feature available. haneWIN NFS Server (1.2.3, 2012-04-23) vlc make fails because sed fails. It can only make projects who's makefile don't use sed. sed with the current Debian/Ubuntu nfs-common write its temporary file with chmod 000, the server honors that and sed can't deleted its temporary file and returns a nonzero ${?} so that make ends. The server author Herbert Hanewinkel says that this is an issue with nfs-common and it might not be fixed in the server. Allegro NFS Server (repo and patches, 2012-05-22) vlc and firefox (and perhaps many other projects) can be build over it. In the current repo vlc make fails because nfsd-rename is too sensitive to ERROR_ACCESS_DENIED and because it reads and writes an incorrect mtime so that the autoconf mtime comparison between Makefile and config.status fail and run config.status in an endless loop. But fixed have been posted on the repo site https://github.com/franzinc/nfs/issues. So NFS is a viable workaround but vmhgfs support for symlinks would be superior. It could also emulate file locks like Allegro NFS Server does for increased compatibility in case they are used, however autoconf that normally lock files will honor an NFS share mounted with -onolock and don't attempt to lock files. ---------------------------------------------------------------------- Comment By: Steve (lousybrit) Date: 2012-05-23 11:12 Message: Thanks I will try that out. I know Windows have their own services for Unix which I have briefly tried in the past but not recently. ---------------------------------------------------------------------- Comment By: John Peterson (johnpeterson) Date: 2012-05-22 00:22 Message: As a workaround I'm using NFS to access the Windows host. (Allegro is the best Windows NFS server as it supports symlinks and locks and is open source.) It's important for me to be able to store all data on the host since my files are better organized that way. ---------------------------------------------------------------------- Comment By: Steve (lousybrit) Date: 2012-05-17 17:46 Message: It requires new code to be implemented in the vmware-vmx for the HGFS server side in the Windows platform specific code. Steve ---------------------------------------------------------------------- Comment By: John Peterson (johnpeterson) Date: 2012-05-17 17:34 Message: Can it be patched in modules/linux/vmhgfs/inode.c:Hgfs*Symlink* or does it also require a patch for vmware-vmx.exe? ---------------------------------------------------------------------- Comment By: Steve (lousybrit) Date: 2012-05-17 17:12 Message: Hi John, Currently for Windows hosts symlinks are not supported. We currently don't have plans to add it either. Only supported on Linux/OS X hosts. Sorry. Steve ---------------------------------------------------------------------- Comment By: John Peterson (johnpeterson) Date: 2012-05-17 12:35 Message: The share is mounted with mount -t vmhgfs .host:/ /mnt/hgfs ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=989708&aid=3527672&group_id=204462 |
|
From: SourceForge.net <no...@so...> - 2012-05-23 18:12:06
|
Tracker item #3527672, was opened at 2012-05-17 12:32 Message generated for change (Comment added) made by lousybrit You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=989708&aid=3527672&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: John Peterson (johnpeterson) Assigned to: Nobody/Anonymous (nobody) Summary: Symlink in Linux guest Initial Comment: Which guests support symlinks in a Windows 7 VMware Workstation host NTFS share? This artifact https://sourceforge.net/tracker/index.php?func=detail&aid=2531303&group_id=204462&atid=989708 seems to say that Gentoo guests support "ln -s". In Ubuntu the operation cd /mnt/hgfs/shared; touch foo; ln -snf foo fum return ln: failed to create symbolic link `fum': Permission denied and if sharedFolder0.followSymlinks = "FALSE" (in .vmx) it returns ln: failed to create symbolic link `fum': Operation not supported # cat /etc/issue Ubuntu 12.04 LTS \n \l # sudo dpkg -s open-vm-tools Version: 2011.12.20-562307-0ubuntu1 VMware Workstation 8.0.2 build-591240 ---------------------------------------------------------------------- Comment By: Steve (lousybrit) Date: 2012-05-23 11:12 Message: Thanks I will try that out. I know Windows have their own services for Unix which I have briefly tried in the past but not recently. ---------------------------------------------------------------------- Comment By: John Peterson (johnpeterson) Date: 2012-05-22 00:22 Message: As a workaround I'm using NFS to access the Windows host. (Allegro is the best Windows NFS server as it supports symlinks and locks and is open source.) It's important for me to be able to store all data on the host since my files are better organized that way. ---------------------------------------------------------------------- Comment By: Steve (lousybrit) Date: 2012-05-17 17:46 Message: It requires new code to be implemented in the vmware-vmx for the HGFS server side in the Windows platform specific code. Steve ---------------------------------------------------------------------- Comment By: John Peterson (johnpeterson) Date: 2012-05-17 17:34 Message: Can it be patched in modules/linux/vmhgfs/inode.c:Hgfs*Symlink* or does it also require a patch for vmware-vmx.exe? ---------------------------------------------------------------------- Comment By: Steve (lousybrit) Date: 2012-05-17 17:12 Message: Hi John, Currently for Windows hosts symlinks are not supported. We currently don't have plans to add it either. Only supported on Linux/OS X hosts. Sorry. Steve ---------------------------------------------------------------------- Comment By: John Peterson (johnpeterson) Date: 2012-05-17 12:35 Message: The share is mounted with mount -t vmhgfs .host:/ /mnt/hgfs ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=989708&aid=3527672&group_id=204462 |
|
From: Reindl H. <h.r...@th...> - 2012-05-23 08:25:52
|
Am 23.05.2012 00:40, schrieb Dmitry Torokhov: > On Tuesday, May 22, 2012 10:38:11 PM Reindl Harald wrote: >> hi >> >> i notice two issues since a longer time on >> VMware Workstation (host and guest fedora 16) >> >> * vmware-toolbox-cmd disk shrink /home >> it prepares only the given mountpoint (zerofill) but it alaways >> acts on ALL virtual disks like "vmware-vdiskmanager -k disk.vmdk" >> would do what is useless on non-prepared disks and a problem if >> one of them is really large and you did not like shrink this one > > Yes, the command that is sent to hypervisor is basically "shrink all disks", > it does not really know what device particular mount point resides on ok, but this is a little a miss-design in this case the mount-point param makes no sense and all disks should be perapred (zerofilled) becasue they will not get smaller without and you are wasting only IO for the full vmdk-sizes |
|
From: Dmitry T. <dt...@vm...> - 2012-05-22 22:40:14
|
On Tuesday, May 22, 2012 10:38:11 PM Reindl Harald wrote: > hi > > i notice two issues since a longer time on > VMware Workstation (host and guest fedora 16) > > * vmware-toolbox-cmd disk shrink /home > it prepares only the given mountpoint (zerofill) but it alaways > acts on ALL virtual disks like "vmware-vdiskmanager -k disk.vmdk" > would do what is useless on non-prepared disks and a problem if > one of them is really large and you did not like shrink this one Yes, the command that is sent to hypervisor is basically "shrink all disks", it does not really know what device particular mount point resides on. > > * [root@testserver:/data]$ vmware-toolbox-cmd disk shrink / > Die Partition / kann nicht verkleinert werden > > means in english something like "this partition can not be shriked" > i can remember times where it was no problem to shrink the root-fs > > may it be that this issue has somehting to do with the braindead > mount-output on recent kernels in case of bin-mounts and that > the rootfs appears two times? > > rootfs rootfs 12G 4,9G > 6,9G 42% / /dev/sdg1 ext4 12G > 4,9G 6,9G 42% / Most likely. Thanks, Dmitry |
58 messages has been excluded from this view by a project administrator.
