From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=47723 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OCBB2-000069-5H for qemu-devel@nongnu.org; Wed, 12 May 2010 08:36:41 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OCBAz-00065r-Qy for qemu-devel@nongnu.org; Wed, 12 May 2010 08:36:40 -0400 Received: from mx1.redhat.com ([209.132.183.28]:19452) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OCBAz-00065Y-J7 for qemu-devel@nongnu.org; Wed, 12 May 2010 08:36:37 -0400 Message-ID: <4BEAA0CC.4090906@redhat.com> Date: Wed, 12 May 2010 15:36:28 +0300 From: Avi Kivity MIME-Version: 1.0 References: <4BE32178.2090103@msgid.tls.msk.ru> <4BE7B8C1.9060807@redhat.com> <4BE7C0A5.3090909@redhat.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: [Qemu-devel] Re: Another SIGFPE in display code, now in cirrus List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Stefano Stabellini Cc: Brian Kress , Michael Tokarev , qemu-devel , KVM list On 05/12/2010 03:20 PM, Stefano Stabellini wrote: > On Mon, 10 May 2010, Avi Kivity wrote: > >> On 05/10/2010 10:41 AM, Avi Kivity wrote: >> >>> On 05/06/2010 11:07 PM, Michael Tokarev wrote: >>> >>>> There was a bug recently fixed in vnc code. Apparently >>>> there's something similar in the cirrus emulation as well. >>>> Here it triggers _always_ (including old versions of kvm) >>>> when running windows NT and hitting "test" button in its >>>> display resolution dialog. Here's what gdb is to say: >>>> >>>> Program received signal SIGFPE, Arithmetic exception. >>>> [Switching to Thread 0xf76cab70 (LWP 580)] >>>> 0x080c5e45 in cirrus_do_copy (s=0x86134dc, dst=960000, src=0, w=2, h=9) >>>> at hw/cirrus_vga.c:687 >>>> 687 sx = (src % ABS(s->cirrus_blt_srcpitch)) / depth; >>>> (gdb) p depth >>>> $1 = 2 >>>> (gdb) p s->cirrus_blt_srcpitch >>>> $2 = 0 >>>> >>>> >>>> This qemu-kvm-0.12.3 - actually a debian package of it, >>>> but there's no patches relevant to video applied. >>>> >>>> Anything can be done with it? >>>> >>> Well, it's trivial to check for the condition, but how to handle it? >>> >>> >> That code is wrong. It shouldn't be using the bitblt source pitch, but >> the actual display pitch. If the two are different, then the blt >> doesn't actually affect a rectangular region, but instead a parallelogram. >> >> > Reading some documention about the Cirrus card we are emulating, it > seems that the source pitch is ignored in video to video operations, so > I think you are right here. > From what I've read I don't think it's ignored. Rather there are two separate pitches, one for bitblt and one for display. I think the code should be something like if bitblt destination intersects display memory: if bitblt pitch == display pitch use console_copy else invalidate entire display > The Windows NT driver probably relies on this behaviour and doesn't set > the source pitch properly before the bitblt. > Note it's just during mode changes. During normal operation I'm sure the pitches are equal. >> 31c05501c says this breaks bitblt, but I can't see why this is true. >> The copy should update the display. This is probably due to a >> miscalculation of the affected region, and now we have two invalidates >> instead of one, reducing performance. >> >> > I agree with you: qemu_console_copy does imply that the copied portion > of the screen changed, so there is no reason to invalidate it again if > qemu_console_copy is called. > Well, we can't just revert 31c05501c. There's probably another bug involved. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic.