[Spice-devel] bad primary surface and server crash after migration

Yonit Halperin yhalperi at redhat.com
Mon Jul 4 02:46:03 PDT 2011


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
>



More information about the Spice-devel mailing list