Am 14.10.2010 14:13, Avi Kivity wrote:
> On 10/14/2010 02:10 PM, Jan Kiszka wrote:
>> Am 14.10.2010 09:27, Jan Kiszka wrote:
>>> Hi,
>>>
>>> I'm seeing quite frequent corruptions of the VESA frame buffer with
>>> Linux guests (vga=0x317) that are starting with KVM kernel modules of
>>> upcoming 2.6.36 (I'm currently running -rc7). Effects disappears when
>>> downgrading to kvm-kmod-2.6.35.6. Will see if I can bisect later, but
>>> maybe someone already has an idea or wants to reproduce (just run
>>> something like "find /" on one text console and witch to another one -
>>> text fragments will remain on the screen on every few switches).
>>
>> Commit d25f31f488e5f7597c17a3ac7d82074de8138e3b in kvm.git ("KVM: x86:
>> avoid unnecessary bitmap allocation when memslot is clean") is at least
>> magnifying the issue. With this patch applied, I can easily trigger
>> display corruptions when switching between VGA consoles while one of
>> them is undergoing heavy updates.
>>
>> However, I once saw a much smaller inconsistency during my tests even
>> with a previous revision. Maybe there is a fundamental issue in when and
>> how the coalesced backlog is replayed,
>
> I didn't see any mmio writes to the framebuffer, so I don't think
> coalescing plays a part here.
>
>> and this commit just makes the
>> corruptions more likely. This may even be a QEMU issue in the cirrus/vga
>> model (both qemu-kvm and upstream show the effect).
>>
>
> What about -no-kvm?
Just booted it (took ages), and the result was actually a completely
black screen. Kind of persistent corruption. This really looks like a
qemu issue now, maybe even a regression as I don't remember running into
such effects a while back.
Jan
--
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
