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: Dyno H. Fu <dy...@gm...> - 2014-07-02 18:57:59
|
have you tried to call "autoreconf -i" which will regenerate the configure file? rgds, Dyno On Wed, Jul 2, 2014 at 11:49 AM, Reindl Harald <h.r...@th...> wrote: > something is terrible wrong with open-vm-tools-9.4.6-1770165 > > there is no ./configure and calling "autoconf" before > ./configure in the SPEC leades to a lot of other errors > > [builduser@buildserver64:/rpmbuild/SPECS]$ rpmbuild -bb vmware-tools.spec > Executing(%prep): /bin/sh -e /var/tmp/rpm-tmp.mXaiCw > + umask 022 > + cd /home/builduser/rpmbuild/BUILD > + cd /home/builduser/rpmbuild/BUILD > + rm -rf open-vm-tools-9.4.6-1770165 > + /usr/bin/gzip -dc > /home/builduser/rpmbuild/SOURCES/open-vm-tools-9.4.6-1770165.tar.gz > + /usr/bin/tar -xf - > + STATUS=0 > + '[' 0 -ne 0 ']' > + cd open-vm-tools-9.4.6-1770165 > + /usr/bin/chmod -Rf a+rX,u+w,g-w,o-w . > + exit 0 > Executing(%build): /bin/sh -e /var/tmp/rpm-tmp.kOwJ28 > + umask 022 > + cd /home/builduser/rpmbuild/BUILD > + cd open-vm-tools-9.4.6-1770165 > + autoconf > configure.ac:86: error: possibly undefined macro: AC_MSG_ERROR > If this token and others are legitimate, please use m4_pattern_allow. > See the Autoconf documentation. > configure.ac:137: error: possibly undefined macro: AC_MSG_WARN > configure.ac:210: error: possibly undefined macro: AM_INIT_AUTOMAKE > configure.ac:243: error: possibly undefined macro: AM_PROG_CC_C_O > configure.ac:252: error: possibly undefined macro: AC_PROG_LIBTOOL > configure.ac:295: error: possibly undefined macro: AC_VMW_CHECK_LIB > configure.ac:379: error: possibly undefined macro: AC_VMW_DEFAULT_FLAGS > configure.ac:388: error: possibly undefined macro: AC_VMW_LIB_ERROR > configure.ac:532: error: possibly undefined macro: AC_VMW_CHECK_LIBXX > configure.ac:657: error: possibly undefined macro: AC_DEFINE > configure.ac:1016: error: possibly undefined macro: AM_CONDITIONAL > error: Bad exit status from /var/tmp/rpm-tmp.kOwJ28 (%build) > > > > ------------------------------------------------------------------------------ > Open source business process management suite built on Java and Eclipse > Turn processes into business applications with Bonita BPM Community Edition > Quickly connect people, data, and systems into organized workflows > Winner of BOSSIE, CODIE, OW2 and Gartner awards > http://p.sf.net/sfu/Bonitasoft > _______________________________________________ > open-vm-tools-devel mailing list > ope...@li... > https://lists.sourceforge.net/lists/listinfo/open-vm-tools-devel > > -- reality, with all its ambiguities, does the job just fine. |
|
From: Reindl H. <h.r...@th...> - 2014-07-02 18:49:57
|
something is terrible wrong with open-vm-tools-9.4.6-1770165
there is no ./configure and calling "autoconf" before
./configure in the SPEC leades to a lot of other errors
[builduser@buildserver64:/rpmbuild/SPECS]$ rpmbuild -bb vmware-tools.spec
Executing(%prep): /bin/sh -e /var/tmp/rpm-tmp.mXaiCw
+ umask 022
+ cd /home/builduser/rpmbuild/BUILD
+ cd /home/builduser/rpmbuild/BUILD
+ rm -rf open-vm-tools-9.4.6-1770165
+ /usr/bin/gzip -dc /home/builduser/rpmbuild/SOURCES/open-vm-tools-9.4.6-1770165.tar.gz
+ /usr/bin/tar -xf -
+ STATUS=0
+ '[' 0 -ne 0 ']'
+ cd open-vm-tools-9.4.6-1770165
+ /usr/bin/chmod -Rf a+rX,u+w,g-w,o-w .
+ exit 0
Executing(%build): /bin/sh -e /var/tmp/rpm-tmp.kOwJ28
+ umask 022
+ cd /home/builduser/rpmbuild/BUILD
+ cd open-vm-tools-9.4.6-1770165
+ autoconf
configure.ac:86: error: possibly undefined macro: AC_MSG_ERROR
If this token and others are legitimate, please use m4_pattern_allow.
See the Autoconf documentation.
configure.ac:137: error: possibly undefined macro: AC_MSG_WARN
configure.ac:210: error: possibly undefined macro: AM_INIT_AUTOMAKE
configure.ac:243: error: possibly undefined macro: AM_PROG_CC_C_O
configure.ac:252: error: possibly undefined macro: AC_PROG_LIBTOOL
configure.ac:295: error: possibly undefined macro: AC_VMW_CHECK_LIB
configure.ac:379: error: possibly undefined macro: AC_VMW_DEFAULT_FLAGS
configure.ac:388: error: possibly undefined macro: AC_VMW_LIB_ERROR
configure.ac:532: error: possibly undefined macro: AC_VMW_CHECK_LIBXX
configure.ac:657: error: possibly undefined macro: AC_DEFINE
configure.ac:1016: error: possibly undefined macro: AM_CONDITIONAL
error: Bad exit status from /var/tmp/rpm-tmp.kOwJ28 (%build)
|
|
From: Thomas H. <the...@vm...> - 2014-05-22 08:45:25
|
Geoffrey, It has been down for quite some time. I'll check what I can do to get it responding again. /Thomas On 05/21/2014 10:58 PM, Geoffrey Thomas wrote: > For the past few days I've been unable to fetch my clone of > git://git.opensource.vmware.com/opensource/open-vm-tools (it connects, but > times out on actually receiving anything over the TCP port). Is the > repository down? > > Thanks, |
|
From: Geoffrey T. <gt...@mo...> - 2014-05-21 22:12:01
|
For the past few days I've been unable to fetch my clone of git://git.opensource.vmware.com/opensource/open-vm-tools (it connects, but times out on actually receiving anything over the TCP port). Is the repository down? Thanks, -- Geoffrey Thomas gt...@mo... |
|
From: Dāvis M. <dav...@gm...> - 2014-05-05 20:26:39
|
I've added some changes so it compiles on newer kernels. It builds fine on Arch Linux with 3.14 kernel, but shared folders doesn't work. Other things like clipboard, 3D hw acceleration does work fine. Here's commit https://github.com/davispuh/open-vm-tools/commit/34503f06e284eed7be41801bc6f1dbe9920ee4b2 Also attached patch itself. But it's not complete for full support, but still is usable. |
|
From: Dāvis M. <dav...@gm...> - 2014-05-05 20:19:49
|
it works now, thanks :) 2014-04-11 20:30 GMT+03:00 Dāvis Mosāns <dav...@gm...>: > It still doesn't work. Why? > > > 2014-03-30 19:07 GMT+03:00 Dāvis Mosāns <dav...@gm...>: > > Is it moved? >> >> $ git clone git://git.opensource.vmware.com/opensource/open-vm-tools/ >> Cloning into 'open-vm-tools'... >> fatal: read error: Connection reset by peer >> >> >> I think it's worth mirroring on https://github.com/vmware/ >> >> > |
|
From: Dāvis M. <dav...@gm...> - 2014-04-11 17:30:39
|
It still doesn't work. Why? 2014-03-30 19:07 GMT+03:00 Dāvis Mosāns <dav...@gm...>: > Is it moved? > > $ git clone git://git.opensource.vmware.com/opensource/open-vm-tools/ > Cloning into 'open-vm-tools'... > fatal: read error: Connection reset by peer > > > I think it's worth mirroring on https://github.com/vmware/ > > |
|
From: Károly K. <ka...@gm...> - 2014-04-04 08:12:07
|
Hello,
I'm compiling open-vm-tools-9.4.0-1280544 (stable) with uClibc (using
current buildroot GIT).
Compiling fails with the message:
../lib/misc/.libs/libMisc.a(msgList.o): In function `MsgList_ToString':
msgList.c:(.text+0x688): undefined reference to `MsgFmt_Asprintf'
../lib/misc/.libs/libMisc.a(msgList.o): In function `MsgList_Log':
msgList.c:(.text+0x788): undefined reference to `MsgFmt_Asprintf'
This function can be backtraced to lib/misc/msgfmt.c, and it only compiles
if HAS_BSD_PRINTF was defined.
It looks like that msgList.c has 2 functions referencing back
unconditionally, but they are not used anyway, when the define exist.
If I insert the same #ifdef in msgList.c it compiles uClibc successfully,
my limited tests show that it works afterwards.
I recommend applying the following patch:
--- openvmtools-9.4.0-1280544.orig/lib/misc/msgList.c<->2013-09-23
17:51:10.000000000 +0200
+++ openvmtools-9.4.0-1280544/lib/misc/msgList.c<------>2014-04-03 13:42:
14.138500061 +0200
@@ -487,6 +487,7 @@
return messages->id;
}
.
+#ifdef HAS_BSD_PRINTF
.
/*
*----------------------------------------------------------------------
@@ -566,6 +567,7 @@
}
}
.
+#endif
.
/*
*----------------------------------------------------------------------
Best regards,
Karoly
|
|
From: Dāvis M. <dav...@gm...> - 2014-03-30 16:07:55
|
Is it moved? $ git clone git://git.opensource.vmware.com/opensource/open-vm-tools/ Cloning into 'open-vm-tools'... fatal: read error: Connection reset by peer I think it's worth mirroring on https://github.com/vmware/ |
|
From: Norbert L. <np...@ch...> - 2014-03-18 20:18:49
|
Hi, I am using the OpenVM Tools that come with Debian 7 - Upstream Version 2:8.8.0. I posted my issues on the debian tracker, but one issue seems to be an upstream problem: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=736812 To Quote: "the vmtoolsd instances spawned by vmware-user-suid-wrapper dont handle SIGUSR1 and SIGUSR2 as they should. The issue here is that you cant stop/start the vmblock filesystem as long as anyone is using it. Supposedly you would send a signal to the user daemons, telling them to give up any references to it - but its not handled and instead the user daemon terminates." In short, I got everything working with the fixes I outlined in the referenced report, but the vmblock "service" cant be stopped or restarted. Kind Regards, Norbert |
|
From: Reindl H. <h.r...@th...> - 2014-03-11 09:25:33
|
Am 11.03.2014 08:03, schrieb Manoel: > Reindl Harald <h.reindl <at> thelounge.net> writes: > >> Am 18.11.2012 12:47, schrieb Konrad Vrba: >>> Dear all, >>> I am trying to compile open-vm-tools-9.0.0-782409 against linux 3.6.6 > and get the following error: >>> I have also tried to compile open-vm-tools-9.2.2-893683, which works, > but apparently only because it compiles >>> without the vmsync module >>> >>> could somebody please advise how to fix this? >> >> there is no need to fix this >> the vmsync moule is NOT NEEDED at all on recenct kernels > > If it is not used why the code that does not compile and make us waste time > is still there ? even removing the vmsync from makefiles other errors show > us up... this is so basic and people need to waste time cleaning ... waste > of time.. just add --without-kernel-modules building on a recent kernel and you are done |
|
From: Manoel <man...@gm...> - 2014-03-11 07:10:14
|
Reindl Harald <h.reindl <at> thelounge.net> writes: > > > Am 18.11.2012 12:47, schrieb Konrad Vrba: > > Dear all, > > I am trying to compile open-vm-tools-9.0.0-782409 against linux 3.6.6 and get the following error: > > I have also tried to compile open-vm-tools-9.2.2-893683, which works, but apparently only because it compiles > > without the vmsync module > > > > could somebody please advise how to fix this? > > there is no need to fix this > the vmsync moule is NOT NEEDED at all on recenct kernels > > > > -------------------------------------------------------------------------- ---- > Monitor your physical, virtual and cloud infrastructure from a single > web console. Get in-depth insight into apps, servers, databases, vmware, > SAP, cloud infrastructure, etc. Download 30-day Free Trial. > Pricing starts from $795 for 25 servers or applications! > http://p.sf.net/sfu/zoho_dev2dev_nov > > _______________________________________________ > open-vm-tools-devel mailing list > open-vm-tools-devel <at> lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/open-vm-tools-devel > If it is not used why the code that does not compile and make us waste time is still there ? even removing the vmsync from makefiles other errors show us up... this is so basic and people need to waste time cleaning ... waste of time.. |
|
From: Reindl H. <h.r...@th...> - 2014-01-28 10:21:26
|
Am 26.01.2014 23:53, schrieb Ravindra Kumar: > Thanks Reindl for reporting the issue. > > I have forwarded your message to the developers responsible for pvscsi driver. > > Thanks, > Ravindra thank you very much! |
|
From: Ravindra K. <rav...@vm...> - 2014-01-26 22:53:42
|
Thanks Reindl for reporting the issue. I have forwarded your message to the developers responsible for pvscsi driver. Thanks, Ravindra |
|
From: Reindl H. <h.r...@th...> - 2014-01-25 13:13:50
|
may somebody of VMware Inc. please take a look at https://bugzilla.redhat.com/show_bug.cgi?id=926917 these messages appear in dmesg in case of debug-kernels for a long time and given that we speak about the main storage driver that leaves a bad taste [ 15.641689] scsi2 : VMware PVSCSI storage adapter rev 2, req/cmp/msg rings: 8/8/1 pages, cmd_per_lun=64 [ 15.650348] vmw_pvscsi 0000:13:00.0: VMware PVSCSI rev 2 host #2 [ 15.656531] ------------[ cut here ]------------ [ 15.657055] WARNING: CPU: 0 PID: 6 at lib/dma-debug.c:937 check_unmap+0x47b/0x920() [ 15.657577] vmw_pvscsi 0000:13:00.0: DMA-API: device driver failed to check map error[device address=0x0000000028cbcc40] [size=96 bytes] [mapped as single] [ 15.658483] Modules linked in: [ 15.659064] vmw_pvscsi(+) [ 15.659460] CPU: 0 PID: 6 Comm: kworker/u2:0 Not tainted 3.14.0-0.rc0.git3.1.fc21.x86_64 #1 [ 15.660174] Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 07/31/2013 [ 15.661267] Workqueue: events_unbound async_run_entry_fn [ 15.661944] 0000000000000009 ffff88002fc03ad8 ffffffff817685b8 ffff88002fc03b20 [ 15.662548] ffff88002fc03b10 ffffffff8107ad3d ffff88002d24f2d0 ffff88002c51ee38 [ 15.663353] ffffffff82d6b950 0000000000000086 ffffffff81a23e5b ffff88002fc03b70 [ 15.664135] Call Trace: [ 15.664481] <IRQ> [<ffffffff817685b8>] dump_stack+0x4d/0x66 [ 15.665162] [<ffffffff8107ad3d>] warn_slowpath_common+0x7d/0xa0 [ 15.665626] [<ffffffff8107adac>] warn_slowpath_fmt+0x4c/0x50 [ 15.666272] [<ffffffff813b523b>] check_unmap+0x47b/0x920 [ 15.666941] [<ffffffff813b582d>] ? debug_dma_unmap_sg+0x6d/0x130 [ 15.667574] [<ffffffff813b573f>] debug_dma_unmap_page+0x5f/0x70 [ 15.668141] [<ffffffffa00006ba>] pvscsi_unmap_buffers.isra.12+0x11a/0x1f0 [vmw_pvscsi] [ 15.668912] [<ffffffffa0000896>] pvscsi_process_completion_ring+0x106/0x2d0 [vmw_pvscsi] [ 15.669496] [<ffffffffa0000b14>] pvscsi_isr+0x34/0xa0 [vmw_pvscsi] [ 15.670171] [<ffffffff810ed3fe>] handle_irq_event_percpu+0x3e/0x370 [ 15.670661] [<ffffffff810ed76d>] handle_irq_event+0x3d/0x60 [ 15.671305] [<ffffffff810f0257>] handle_edge_irq+0x77/0x130 [ 15.671935] [<ffffffff8101bbaf>] handle_irq+0xbf/0x150 [ 15.672385] [<ffffffff81081aa2>] ? irq_enter+0x42/0x90 [ 15.673000] [<ffffffff8177d34f>] do_IRQ+0x4f/0xf0 [ 15.673521] [<ffffffff81771eb2>] common_interrupt+0x72/0x72 [ 15.674089] [<ffffffff810814e8>] ? __do_softirq+0xc8/0x460 [ 15.674557] [<ffffffff810814e1>] ? __do_softirq+0xc1/0x460 [ 15.675196] [<ffffffff810bd8d1>] ? sched_clock_cpu+0x11/0xd0 [ 15.675670] [<ffffffff81081bb5>] irq_exit+0xc5/0xd0 [ 15.676285] [<ffffffff8177d435>] smp_apic_timer_interrupt+0x45/0x60 [ 15.676927] [<ffffffff8177bd72>] apic_timer_interrupt+0x72/0x80 [ 15.677410] <EOI> [<ffffffff8177119b>] ? _raw_spin_unlock_irqrestore+0x3b/0x70 [ 15.678148] [<ffffffffa0001750>] pvscsi_queue+0x130/0x830 [vmw_pvscsi] [ 15.678661] [<ffffffff814ce2f0>] ? perf_trace_scsi_dispatch_cmd_error+0x1a0/0x1a0 [ 15.679367] [<ffffffff814ce8f1>] scsi_dispatch_cmd+0xb1/0x4e0 [ 15.679999] [<ffffffff814d627c>] scsi_request_fn+0x33c/0x540 [ 15.680469] [<ffffffff8135a603>] __blk_run_queue+0x33/0x40 [ 15.681095] [<ffffffff81363241>] blk_execute_rq_nowait+0xa1/0x120 [ 15.681579] [<ffffffff81363366>] blk_execute_rq+0x76/0x100 [ 15.682213] [<ffffffff8135911f>] ? blk_rq_init+0xff/0x170 [ 15.682707] [<ffffffff81363650>] ? blk_recount_segments+0x20/0x40 [ 15.683359] [<ffffffff81241209>] ? bio_phys_segments+0x19/0x20 [ 15.684013] [<ffffffff8135e890>] ? blk_rq_bio_prep+0x70/0xd0 [ 15.684469] [<ffffffff813630f0>] ? blk_rq_map_kern+0xc0/0x170 [ 15.685107] [<ffffffff814d4d87>] scsi_execute+0xd7/0x160 [ 15.685556] [<ffffffff814d656c>] scsi_execute_req_flags+0x8c/0x100 [ 15.686201] [<ffffffff814d898c>] scsi_probe_and_add_lun+0x20c/0xc00 [ 15.686687] [<ffffffff814d97f8>] __scsi_scan_target+0xf8/0x6a0 [ 15.687330] [<ffffffff810d8339>] ? mark_held_locks+0xb9/0x140 [ 15.687986] [<ffffffff81771196>] ? _raw_spin_unlock_irqrestore+0x36/0x70 [ 15.692147] [<ffffffff810d84c5>] ? trace_hardirqs_on_caller+0x105/0x1d0 [ 15.692661] [<ffffffff810d859d>] ? trace_hardirqs_on+0xd/0x10 [ 15.693345] [<ffffffff814d9f16>] scsi_scan_channel.part.6+0x66/0x90 [ 15.694016] [<ffffffff814da0d9>] scsi_scan_host_selected+0xf9/0x1c0 [ 15.694497] [<ffffffff814da231>] do_scsi_scan_host+0x91/0xa0 [ 15.695125] [<ffffffff814da40c>] do_scan_async+0x1c/0x160 [ 15.695574] [<ffffffff810ae389>] async_run_entry_fn+0x39/0x120 [ 15.696229] [<ffffffff8109d4c1>] process_one_work+0x211/0x6b0 [ 15.696689] [<ffffffff8109d455>] ? process_one_work+0x1a5/0x6b0 [ 15.697332] [<ffffffff8109da7b>] worker_thread+0x11b/0x3a0 [ 15.697958] [<ffffffff8109d960>] ? process_one_work+0x6b0/0x6b0 [ 15.698423] [<ffffffff810a6550>] kthread+0xf0/0x110 [ 15.699031] [<ffffffff81021f59>] ? sched_clock+0x9/0x10 [ 15.699472] [<ffffffff810a6460>] ? insert_kthread_work+0x80/0x80 [ 15.700112] [<ffffffff8177afbc>] ret_from_fork+0x7c/0xb0 [ 15.700587] [<ffffffff810a6460>] ? insert_kthread_work+0x80/0x80 [ 15.701261] ---[ end trace 9e665d6a1a3e2037 ]--- [ 15.701676] Mapped at: [ 15.702234] [<ffffffff813b4081>] debug_dma_map_page+0x91/0x140 [ 15.702722] [<ffffffffa00018a1>] pvscsi_queue+0x281/0x830 [vmw_pvscsi] [ 15.703360] [<ffffffff814ce8f1>] scsi_dispatch_cmd+0xb1/0x4e0 [ 15.704018] [<ffffffff814d627c>] scsi_request_fn+0x33c/0x540 [ 15.704530] [<ffffffff8135a603>] __blk_run_queue+0x33/0x40 [ 15.706915] scsi 2:0:0:0: Direct-Access VMware, VMware Virtual S 1.0 PQ: 0 ANSI: 2 [ 15.708230] scsi 2:0:1:0: Direct-Access VMware, VMware Virtual S 1.0 PQ: 0 ANSI: 2 |
|
From: Dmitry T. <dt...@vm...> - 2014-01-06 17:40:04
|
On Monday, January 06, 2014 10:00:03 AM Thomas Hellstrom wrote: > Hi! > > it appears the git server > git.opensource.vmware.com/opensource/open-vm-tools* > > *Doesn't respond? > > /Thomas I let our infrastructure guys know. Thanks, Dmitry |
|
From: Thomas H. <the...@vm...> - 2014-01-06 09:00:15
|
Hi! it appears the git server git.opensource.vmware.com/opensource/open-vm-tools* *Doesn't respond? /Thomas |
|
From: Steve W. <sw...@Fr...> - 2013-11-21 03:00:27
|
There already is a ticket, with core file attached, for the same issue with 9.2.3: http://sourceforge.net/p/open-vm-tools/tracker/176/ Steve On Wed, Nov 20, 2013 at 10:20:33AM -0800, Ravindra Kumar wrote: > Could you please create a tracker for this? And, provide attachments for backtrace and core? > > http://sourceforge.net/p/open-vm-tools/tracker/ > > Thanks, > Ravindra > ------------------------------------------------------------------------------ > Shape the Mobile Experience: Free Subscription > Software experts and developers: Be at the forefront of tech innovation. > Intel(R) Software Adrenaline delivers strategic insight and game-changing > conversations that shape the rapidly evolving mobile landscape. Sign up now. > http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk > _______________________________________________ > open-vm-tools-devel mailing list > ope...@li... > https://lists.sourceforge.net/lists/listinfo/open-vm-tools-devel |
|
From: Ravindra K. <rav...@vm...> - 2013-11-20 18:20:46
|
Could you please create a tracker for this? And, provide attachments for backtrace and core? http://sourceforge.net/p/open-vm-tools/tracker/ Thanks, Ravindra |
|
From: Douglas C. <dca...@dc...> - 2013-11-20 12:20:59
|
To whom it may concern:
Ever since I updated to 9.3/9.4 tools on FreeBSD, I’ve been getting consistent SIGABRTs with vmtoolsd upon shutting down or rebooting the VM.
When I looked at the gdb backtrace, it seems to consistently SIGABRT on cleaning up the glib main loop with g_main_loop_unref(), but I haven’t the experience to recognize what specifically could cause it.
Here’s an excerpt from the backtrace:
(gdb) frame 10
#10 0x0000000000405137 in main (argc=5, argv=0x80501a4f0, envp=0x7fffffffdd18)
at mainPosix.c:272
272 ret = ToolsCore_Run(&gState);
(gdb) frame 9
#9 0x0000000000404bda in ToolsCore_Run (state=0x60a900) at mainLoop.c:445
445 return ToolsCoreRunLoop(state);
(gdb) frame 8
#8 0x00000000004045c7 in ToolsCoreRunLoop (state=0x60a900) at mainLoop.c:241
241 ToolsCoreCleanup(state);
(gdb) frame 7
#7 0x00000000004042be in ToolsCoreCleanup (state=0x60a900) at mainLoop.c:67
67 g_main_loop_unref(state->ctx.mainLoop);
What could possibly cause this?
(I can provide the full backtrace and core file upon request.)
—Doulgas |
|
From: Reindl H. <h.r...@th...> - 2013-10-11 15:40:39
|
open-vm-tools-9.4.0-1280544 --without-procps --without-dnet these warnings should not happen in that case all the time Oct 11 17:28:41 master vmsvc[291]: [ warning] [guestinfo] Failed to get nic info. Oct 11 17:28:41 master vmsvc[291]: [ warning] [guestinfo] Failed to get vmstats. Oct 11 17:29:11 master vmsvc[291]: [ warning] [guestinfo] Failed to get nic info. Oct 11 17:29:11 master vmsvc[291]: [ warning] [guestinfo] Failed to get vmstats. Oct 11 17:29:41 master vmsvc[291]: [ warning] [guestinfo] Failed to get nic info. Oct 11 17:29:41 master vmsvc[291]: [ warning] [guestinfo] Failed to get vmstats. Oct 11 17:30:11 master vmsvc[291]: [ warning] [guestinfo] Failed to get nic info. Oct 11 17:30:11 master vmsvc[291]: [ warning] [guestinfo] Failed to get vmstats. Oct 11 17:30:41 master vmsvc[291]: [ warning] [guestinfo] Failed to get nic info. Oct 11 17:30:41 master vmsvc[291]: [ warning] [guestinfo] Failed to get vmstats. Oct 11 17:31:11 master vmsvc[291]: [ warning] [guestinfo] Failed to get nic info. Oct 11 17:31:11 master vmsvc[291]: [ warning] [guestinfo] Failed to get vmstats. Oct 11 17:31:41 master vmsvc[291]: [ warning] [guestinfo] Failed to get nic info. Oct 11 17:31:41 master vmsvc[291]: [ warning] [guestinfo] Failed to get vmstats. Oct 11 17:32:11 master vmsvc[291]: [ warning] [guestinfo] Failed to get nic info. Oct 11 17:32:11 master vmsvc[291]: [ warning] [guestinfo] Failed to get vmstats. Oct 11 17:32:41 master vmsvc[291]: [ warning] [guestinfo] Failed to get nic info. Oct 11 17:32:41 master vmsvc[291]: [ warning] [guestinfo] Failed to get vmstats. Oct 11 17:33:11 master vmsvc[291]: [ warning] [guestinfo] Failed to get nic info. Oct 11 17:33:11 master vmsvc[291]: [ warning] [guestinfo] Failed to get vmstats. Oct 11 17:33:41 master vmsvc[291]: [ warning] [guestinfo] Failed to get nic info. Oct 11 17:33:41 master vmsvc[291]: [ warning] [guestinfo] Failed to get vmstats. Oct 11 17:34:11 master vmsvc[291]: [ warning] [guestinfo] Failed to get nic info. Oct 11 17:34:11 master vmsvc[291]: [ warning] [guestinfo] Failed to get vmstats. |
|
From: Reindl H. <h.r...@th...> - 2013-10-11 10:22:21
|
Am 02.10.2013 17:24, schrieb Dmitry Torokhov: > On Wednesday, October 02, 2013 02:34:15 PM Reindl Harald wrote: >> and that was also already fixed without need to use >> "-Wno-deprecated-declarations" - what happened with >> these commits/fixes? > > The 9.4.0 is from vSphere lineage which was branched off earlier than 9.2.3 > and is under stricter control, so these fixes have not made there yet. > > These are not critical issues, you should be able to pass needed CFLAGS and > the procps name to ./configure and then it will build just fine. ah - thanks is there any improvement by not using --without-procps? it would be pretty cool if someone explains what the VMware-Tools are supposed to do except HA/filesystem-freeze/shutdown-reboot on recent Linux guests having all the VMware drivers in the mainline Kernel and in which situations what is needed/helpful personally i like to disable as much as possible linking for a smaller footprint and in doubt improved security in case libraries needs pacthes because of bugs |
|
From: Dmitry T. <dt...@vm...> - 2013-10-02 15:24:46
|
On Wednesday, October 02, 2013 02:34:15 PM Reindl Harald wrote: > and that was also already fixed without need to use > "-Wno-deprecated-declarations" - what happened with > these commits/fixes? The 9.4.0 is from vSphere lineage which was branched off earlier than 9.2.3 and is under stricter control, so these fixes have not made there yet. These are not critical issues, you should be able to pass needed CFLAGS and the procps name to ./configure and then it will build just fine. Thanks, Dmitry |
|
From: Don C. <don...@ya...> - 2013-10-02 15:06:08
|
I believe it was discussed earlier, but in order to maintain compatibility with older distributions, the CFLAGS workaround is needed for newer distro's. For the libproc issue, try the following before your build, and you can include procps support again. export CUSTOM_PROCPS_NAME=procps export CUSTOM_PROCPS_LIBS=-L/usr/lib/libprocps.so ________________________________ From: Reindl Harald <h.r...@th...> To: ope...@li... Sent: Wednesday, October 2, 2013 8:00 AM Subject: Re: configure: error: libproc not found. Please configure without procps (using --without-procps) or install procps try to build them on Fedora 18/19 x with gcc-4.8.1/procps-ng/glib2-2.36.3 this was already fixed months ago (2013/01 or 2013/02 AFAIK) both, procps-ng and the deprecated errors while for them a CFLAG works and --without-procps for the other case Am 02.10.2013 16:56, schrieb Don Cupp: > When and where is this causing you problems? > > ------------------------------------------------------------------------------------------------------------------- > *From: * Reindl Harald <h.r...@th...>; > *To: * Mailing-List open-vm-tools <ope...@li...>; > *Subject: * Re: configure: error: libproc not found. Please configure without procps (using --without-procps) or > install procps > *Sent: * Wed, Oct 2, 2013 12:34:15 PM > > and that was also already fixed without need to use > "-Wno-deprecated-declarations" - what happened with > these commits/fixes? > > sysLogger.c:116:4: error: 'g_static_mutex_get_mutex_impl' is deprecated (declared at > /usr/include/glib-2.0/glib/deprecated/gthread.h:149): Use 'GMutex' instead [-Werror=deprecated-declarations] > g_static_mutex_unlock(&gSysLoggerLock); > ^ > sysLogger.c: In function 'GlibUtils_CreateSysLogger': > sysLogger.c:143:4: error: 'g_static_mutex_get_mutex_impl' is deprecated (declared at > /usr/include/glib-2.0/glib/deprecated/gthread.h:149): Use 'GMutex' instead [-Werror=deprecated-declarations] > g_static_mutex_lock(&gSysLoggerLock); > ^ > sysLogger.c:206:4: error: 'g_static_mutex_get_mutex_impl' is deprecated (declared at > /usr/include/glib-2.0/glib/deprecated/gthread.h:149): Use 'GMutex' instead [-Werror=deprecated-declarations] > g_static_mutex_unlock(&gSysLoggerLock); > ^ > cc1: all warnings being treated as errors > make[2]: *** [libGlibUtils_la-sysLogger.lo] Error 1 > make[2]: Leaving directory `/home/builduser/rpmbuild/BUILD/open-vm-tools-9.4.0-1280544/lib/glibUtils' > make[1]: *** [all-recursive] Error 1 > make[1]: Leaving directory `/home/builduser/rpmbuild/BUILD/open-vm-tools-9.4.0-1280544/lib' > make: *** [all-recursive] Error 1 > Fehler: Fehler-Status beim Beenden von /var/tmp/rpm-tmp.vOxzPk (%build) > > Am 02.10.2013 14:30, schrieb Reindl Harald: >> Hi >> >> open-vm-tools-9.4.0-1280544.tar.gz >> configure: error: libproc not found. Please configure without procps (using --without-procps) or install procps >> >> this was already fixed in open-vm-tools-9.2.3.1098359 >> >> [builduser@testserver <javascript:return>:/rpmbuild/SPECS]$ rpm -qa | grep procps >> procps-ng-3.3.8-10.fc19.x86_64 >> procps-ng-devel-3.3.8-10.fc19.x86_64 ------------------------------------------------------------------------------ October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register > http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk _______________________________________________ open-vm-tools-devel mailing list ope...@li... https://lists.sourceforge.net/lists/listinfo/open-vm-tools-devel |
|
From: Reindl H. <h.r...@th...> - 2013-10-02 15:00:42
|
try to build them on Fedora 18/19 x with gcc-4.8.1/procps-ng/glib2-2.36.3 this was already fixed months ago (2013/01 or 2013/02 AFAIK) both, procps-ng and the deprecated errors while for them a CFLAG works and --without-procps for the other case Am 02.10.2013 16:56, schrieb Don Cupp: > When and where is this causing you problems? > > ------------------------------------------------------------------------------------------------------------------- > *From: * Reindl Harald <h.r...@th...>; > *To: * Mailing-List open-vm-tools <ope...@li...>; > *Subject: * Re: configure: error: libproc not found. Please configure without procps (using --without-procps) or > install procps > *Sent: * Wed, Oct 2, 2013 12:34:15 PM > > and that was also already fixed without need to use > "-Wno-deprecated-declarations" - what happened with > these commits/fixes? > > sysLogger.c:116:4: error: 'g_static_mutex_get_mutex_impl' is deprecated (declared at > /usr/include/glib-2.0/glib/deprecated/gthread.h:149): Use 'GMutex' instead [-Werror=deprecated-declarations] > g_static_mutex_unlock(&gSysLoggerLock); > ^ > sysLogger.c: In function 'GlibUtils_CreateSysLogger': > sysLogger.c:143:4: error: 'g_static_mutex_get_mutex_impl' is deprecated (declared at > /usr/include/glib-2.0/glib/deprecated/gthread.h:149): Use 'GMutex' instead [-Werror=deprecated-declarations] > g_static_mutex_lock(&gSysLoggerLock); > ^ > sysLogger.c:206:4: error: 'g_static_mutex_get_mutex_impl' is deprecated (declared at > /usr/include/glib-2.0/glib/deprecated/gthread.h:149): Use 'GMutex' instead [-Werror=deprecated-declarations] > g_static_mutex_unlock(&gSysLoggerLock); > ^ > cc1: all warnings being treated as errors > make[2]: *** [libGlibUtils_la-sysLogger.lo] Error 1 > make[2]: Leaving directory `/home/builduser/rpmbuild/BUILD/open-vm-tools-9.4.0-1280544/lib/glibUtils' > make[1]: *** [all-recursive] Error 1 > make[1]: Leaving directory `/home/builduser/rpmbuild/BUILD/open-vm-tools-9.4.0-1280544/lib' > make: *** [all-recursive] Error 1 > Fehler: Fehler-Status beim Beenden von /var/tmp/rpm-tmp.vOxzPk (%build) > > Am 02.10.2013 14:30, schrieb Reindl Harald: >> Hi >> >> open-vm-tools-9.4.0-1280544.tar.gz >> configure: error: libproc not found. Please configure without procps (using --without-procps) or install procps >> >> this was already fixed in open-vm-tools-9.2.3.1098359 >> >> [builduser@testserver <javascript:return>:/rpmbuild/SPECS]$ rpm -qa | grep procps >> procps-ng-3.3.8-10.fc19.x86_64 >> procps-ng-devel-3.3.8-10.fc19.x86_64 |
58 messages has been excluded from this view by a project administrator.
