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), flush_all_qxl_commands is
called. When attempting to process a command we receive
id 0, group 0, virt start 0, virt end ffffffffffffffff, generation 0,
delta 0
validate_virt: panic: virtual address out of range
virt=0x175f99c+0xbf slot_id=1 group_id=1
slot=0x0-0x0 delta=0x0
Is it valid that the command ring is not empty? Maybe we shouldn't
process commands as long as worker->running is not set?
Yes, that should fix it, otherwise you'll try to process commands before
qxl fully restored the state (especially memory slots and surfaces)
which will not work.
2) immediately after migration, before processing any commands, it looks
like the primary surface on the destination is not the most updated one
(or alternatively was badly rendered). When I connect to the source
server (the stopped one), the primary surface looks o.k (this made me
think it is not a rendering problem).
Maybe there is a problem with setting all the ram dirty? I also checked
that the stopped server doesn't preform any processing commands after it
has been stopped, and that the destination doesn't preform any commands
before loadvm (when it doesn't crash on the previos problem I described).
Could be. qxl_vm_change_state_handler() takes care to tag all vram
dirty, the primary lives in devram though ...
o.k. missed it because it is called vram as well (vga.vram). I will set
it dirty as well.
cheers,
Gerd
_______________________________________________
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel
