From mboxrd@z Thu Jan 1 00:00:00 1970 From: Takuya Yoshikawa Subject: Re: Frame buffer corruptions with KVM >= 2.6.36 Date: Mon, 18 Oct 2010 21:14:18 +0900 Message-ID: <4CBC3A1A.40307@oss.ntt.co.jp> References: <4CB6B0FB.7080100@web.de> <4CB6F33E.3020009@siemens.com> <4CB6F3F1.9060409@redhat.com> <4CB6F932.8030605@siemens.com> <4CB6F9DE.6060008@redhat.com> <4CB7F7A1.4030409@oss.ntt.co.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Cc: Jan Kiszka , kvm To: Avi Kivity Return-path: Received: from serv2.oss.ntt.co.jp ([222.151.198.100]:37038 "EHLO serv2.oss.ntt.co.jp" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752040Ab0JRMMV (ORCPT ); Mon, 18 Oct 2010 08:12:21 -0400 In-Reply-To: <4CB7F7A1.4030409@oss.ntt.co.jp> Sender: kvm-owner@vger.kernel.org List-ID: (2010/10/15 15:41), Takuya Yoshikawa wrote: > (2010/10/14 21:38), Avi Kivity wrote: >> On 10/14/2010 02:36 PM, Jan Kiszka wrote: >>> > >>> >> 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. >> >> Worked fine for me (though yes it was slow - did tcg regress?). >> > > I reread my commit but could not find any reason to make this corruption > in kernel side. > > But at least, I want to make it clear whether my commit was just a magnifier > of this problem, I know that magnifier itself is bad, or not. > > Though I'm now trying some debugging but have not got a way to show > kvm_vm_ioctl_get_dirty_log() is 100% correct yet. > I tried some tests and found another issue. I opened a terminal in one workspace and did "find /" on it. Then I switched to another workspace. When I switched back to the first one, the display of "find /" result was frozen. I also replaced kvm_vm_ioctl_get_dirty_log() with the version before my patch was applied and got the same result. I don't know this is related to your report, but something seems wrong. Thanks, Takuya