On 07/03/2011 04:27 PM, Rami Vaknin wrote:
From: rootroot@fed15.localdomain
Compiling with gcc-c++-4.6.0-9.fc15.i686 on Fedora 15
---
server/main_channel.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/server/main_channel.c b/server/main_channel.c
index
When the worker was stoped, the cursor was copied from guest ram to the host
ram,
and its corresponding qxl command was released.
This is unecessary, since the qxl ram still exists (we keep references
to the surfaces in the same manner).
It also led to BSOD on guest upon migration: the device
In addition (1) make handle_dev_destroy_surfaces call red_release_cursor
(2) call red_wait_outgoing_item(cursor_channel) only after adding msgs to pipe
---
server/red_worker.c | 71 +-
1 files changed, 24 insertions(+), 47 deletions(-)
diff --git
On Sat, Jul 02, 2011 at 05:06:39AM +0200, Alon Levy wrote:
--- a/gtk/spice-channel-priv.h
+++ b/gtk/spice-channel-priv.h
@@ -123,6 +123,8 @@ struct spice_channel {
GArray *common_caps;
GArray *remote_caps;
GArray
Hi Gerd,
I encountered several problems after migration, maybe you can help:
1) on qxl_pre_load, sometimes the command ring is not empty and when
handle_dev_destroy_surface (on hard reset), flush_all_qxl_commands is
called. When attempting to process a command we receive
id 0, group 0, virt
On Mon, Jul 04, 2011 at 09:37:53AM +0300, Uri Lublin wrote:
On 07/03/2011 04:27 PM, Rami Vaknin wrote:
From: rootroot@fed15.localdomain
Compiling with gcc-c++-4.6.0-9.fc15.i686 on Fedora 15
The spice server is compiled for 64 bit machines (at least currently).
Try compiling with
On Sun, Jul 03, 2011 at 05:57:08PM +0200, Alon Levy wrote:
On Sun, Jul 03, 2011 at 04:27:57PM +0300, Rami Vaknin wrote:
From: root root@fed15.localdomain
ACK. I'll push this.
This adds warnings on 64 bit builds:
main_channel.c: In function 'main_channel_handle_parsed':
On 07/04/2011 11:54 AM, Yonit Halperin wrote:
Hi Gerd,
I encountered several problems after migration, maybe you can help:
1) on qxl_pre_load, sometimes the command ring is not empty and when
handle_dev_destroy_surface (on hard reset), flush_all_qxl_commands is
called. When attempting to
On 07/04/11 10:51, Yonit Halperin wrote:
Hi Gerd,
I encountered several problems after migration, maybe you can help:
1) on qxl_pre_load, sometimes the command ring is not empty and when
handle_dev_destroy_surface (on hard reset), flush_all_qxl_commands is
called. When attempting to process a
On 07/04/2011 12:23 PM, Gerd Hoffmann wrote:
On 07/04/11 10:51, Yonit Halperin wrote:
Hi Gerd,
I encountered several problems after migration, maybe you can help:
1) on qxl_pre_load, sometimes the command ring is not empty and when
handle_dev_destroy_surface (on hard reset),
Hi
- Original Message -
On Sat, Jul 02, 2011 at 05:06:39AM +0200, Alon Levy wrote:
--- a/gtk/spice-channel-priv.h
+++ b/gtk/spice-channel-priv.h
@@ -123,6 +123,8 @@ struct spice_channel {
GArray *common_caps;
GArray *remote_caps;
GArray *remote_common_caps;
+
On Mon, Jul 04, 2011 at 10:53:33AM +0200, Christophe Fergeau wrote:
On Mon, Jul 04, 2011 at 09:37:53AM +0300, Uri Lublin wrote:
On 07/03/2011 04:27 PM, Rami Vaknin wrote:
From: rootroot@fed15.localdomain
Compiling with gcc-c++-4.6.0-9.fc15.i686 on Fedora 15
The spice server is
---
hw/qxl.c |9 ++---
1 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/hw/qxl.c b/hw/qxl.c
index 2bb36c6..9fdeffb 100644
--- a/hw/qxl.c
+++ b/hw/qxl.c
@@ -1165,11 +1165,14 @@ static void qxl_vm_change_state_handler(void *opaque,
int running, int reason)
Hi,
+qxl_set_dirty(devram_addr, devram_addr + qxl-vga.vram_size);
It is enougth to dirty the surface0 area.
Otherwise the patch looks fine.
cheers,
Gerd
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
On Mon, Jul 04, 2011 at 12:01:02PM +0200, Alon Levy wrote:
I was about to mention that these warnings are probably one of the smallest
issue you'll encounter on a 32 bit spice-server build. However, the patch
doesn't hurt, it's actually a first step in the right direction, and I
assume
On 07/01/11 15:58, Christophe Fergeau wrote:
Hi,
While looking at a crash in qemu when SPICE_INTERFACE_PLAYBACK_MINOR was
increased, I came across the version checking code in spice_server_add_interface
in server/reds.c which does stuff like
if (strcmp(interface-type, SPICE_INTERFACE_RECORD)
---
hw/qxl.c |9 ++---
1 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/hw/qxl.c b/hw/qxl.c
index 2bb36c6..cff95a4 100644
--- a/hw/qxl.c
+++ b/hw/qxl.c
@@ -1165,11 +1165,14 @@ static void qxl_vm_change_state_handler(void *opaque,
int running, int reason)
On 07/03/11 15:12, Frédéric Grelot wrote:
[ 664.762] Out of surfaces [ 664.802] Out of surfaces
I suspected that this was somewhat related to the resolution I did
set in X : 1920x1080. I then set the VRAM size to 128Mb instead of
64Mb : unfortunately, the host was overloaded with the
Hi,
+qxl_set_dirty(devram_addr, devram_addr + qxl-rom-surface0_area_size);
s/rom/shadow_rom/, then it is perfect. rom points directly to guest
memory, better don't trust that.
cheers,
Gerd
___
Spice-devel mailing list
---
hw/qxl.c |9 ++---
1 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/hw/qxl.c b/hw/qxl.c
index 2bb36c6..b3a3507 100644
--- a/hw/qxl.c
+++ b/hw/qxl.c
@@ -1165,11 +1165,14 @@ static void qxl_vm_change_state_handler(void *opaque,
int running, int reason)
On 06/24/2011 02:52 PM, Alon Levy wrote:
ret = read(d-aio_pipe[0],io, sizeof(io));
+if (ret 0 (errno == EAGAIN || errno == EINTR)) {
+continue;
+}
This means you'd be busy waiting if you get EAGAIN. If you really need
EAGAIN, perhaps there is another
On migration, destroy_surfaces is called from qxl (qxl_hard_reset), before the
device was loaded (on destination).
handle_dev_destroy_surfaces led to red_process_commands, which read the qxl
command ring
(which appeared to be not empty), and then when processing the command
it accessed unmapped
Hi,
On Mon, Jul 04, 2011 at 01:27:16PM +0200, Gerd Hoffmann wrote:
On 07/01/11 15:58, Christophe Fergeau wrote:
if (strcmp(interface-type, SPICE_INTERFACE_RECORD) == 0) {
red_printf(SPICE_INTERFACE_RECORD);
if (interface-major_version != SPICE_INTERFACE_RECORD_MAJOR ||
Hi,
I see, thanks. In this case, the change adds new messages and new methods
for the Playback and Record channels, so nothing should change unless these
new methods are explicitly called from qemu, which means raising the minor
version number was probably not strictly needed (but not harmful
On 07/04/11 14:08, Yonit Halperin wrote:
---
hw/qxl.c |9 ++---
1 files changed, 6 insertions(+), 3 deletions(-)
Added to spice patch queue.
thanks,
Gerd
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
On Mon, 2011-07-04 at 17:48 +0300, Yonit Halperin wrote:
On 07/04/2011 05:21 PM, John A. Sullivan III wrote:
Very helpful and interesting. I'll respond in-line - John
On Sun, 2011-07-03 at 10:38 +0300, Yaniv Kaul wrote:
On 06/30/2011 10:10 AM, Yaniv Kaul wrote:
On 06/30/2011 05:33 AM,
How does /proc/iomem look like with 128Mb?
I couldn't log in to the guest, since the host was overloaded with the MSI-X
message. I should try with logging deactivated.
Anyway, the problem occured again (still with 64Mb), and here is iomem :
- : reserved
0001-0009f3ff :
Which client should one use? I'm a little confused reading the
documentation version looking at the download page.
http://spice-space.org/page/DeveloperStartPage says, client - this is
the old spice client. It is still supported but is being phased out in
favor of a new widgetized gtk/glib based
On Mon, Jul 04, 2011 at 01:25:01PM -0400, John A. Sullivan III wrote:
Which client should one use? I'm a little confused reading the
documentation version looking at the download page.
http://spice-space.org/page/DeveloperStartPage says, client - this is
the old spice client. It is still
On Jul 4, 2011 6:25 PM, John A. Sullivan III
jsulli...@opensourcedevel.com wrote:
However, spicec looks like it is in 0.8.1 whereas the download page says
gtk is experimental and provides a link with the latest versio being 0.6
from April. Thanks - John
Hi,
I believe that spice-gtk follows
On 07/04/2011 07:33 PM, John A. Sullivan III wrote:
On Mon, 2011-07-04 at 17:48 +0300, Yonit Halperin wrote:
On 07/04/2011 05:21 PM, John A. Sullivan III wrote:
Very helpful and interesting. I'll respond in-line - John
On Sun, 2011-07-03 at 10:38 +0300, Yaniv Kaul wrote:
On 06/30/2011 10:10
Hello, all. Being a Windows ignoramus, I am having a nightmare of a
time compiling the Windows client on our Windows 7 build system. I'll
recount them for other ignorami and to ask for help for the things I
could not figure out.
I installed the Windows SDK 7.1 and it installed without compilers
Hello, all. I'm spinning this off of the Unfair Comparisons with RDP
thread as that one is getting a bit long. However, in it, Yaniv
identified that we were not using vdagent in our Windows guest based
upon the packet traces we submitted. That sounded plausible as we have
noticed the agent
33 matches
Mail list logo
