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:13:26 +0200 Message-ID: <4CB6F3E6.9000407@siemens.com> References: <4CB6B0FB.7080100@web.de> <4CB6F1EA.6010309@redhat.com> <4CB6F35F.1030504@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Cc: Jan Kiszka , kvm To: Avi Kivity Return-path: Received: from david.siemens.de ([192.35.17.14]:20636 "EHLO david.siemens.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752529Ab0JNMNo (ORCPT ); Thu, 14 Oct 2010 08:13:44 -0400 In-Reply-To: <4CB6F35F.1030504@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: Am 14.10.2010 14:11, Avi Kivity wrote: > On 10/14/2010 02:04 PM, Avi Kivity wrote: >> On 10/14/2010 09:27 AM, 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). >>> >> >> Reproduces on kvm.git. I wonder what's going on. >> >> Looks like vesafb uses the bios to switch the display start, so I >> expect a problem in qemu reacting to this. >> > > Hm, you said it is a kernel regression. Maybe it's an issue with dirty > bit tracking. > Ah, cross-posting... It need not be a kernel thing, see my other mail. Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux