From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jan Kiszka Subject: Re: Frame buffer corruptions with KVM >= 2.6.36 Date: Thu, 14 Oct 2010 14:36:02 +0200 Message-ID: <4CB6F932.8030605@siemens.com> References: <4CB6B0FB.7080100@web.de> <4CB6F33E.3020009@siemens.com> <4CB6F3F1.9060409@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Cc: kvm , Takuya Yoshikawa To: Avi Kivity Return-path: Received: from goliath.siemens.de ([192.35.17.28]:24314 "EHLO goliath.siemens.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753091Ab0JNMgX (ORCPT ); Thu, 14 Oct 2010 08:36:23 -0400 In-Reply-To: <4CB6F3F1.9060409@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: 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