From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: Another SIGFPE in display code, now in cirrus Date: Wed, 12 May 2010 19:57:39 +0300 Message-ID: <4BEADE03.7040405@redhat.com> References: <4BE32178.2090103@msgid.tls.msk.ru> <4BE7B8C1.9060807@redhat.com> <4BE7C0A5.3090909@redhat.com> <4BEAA0CC.4090906@redhat.com> <4BEABABC.6080305@redhat.com> <4BEAD232.2040700@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Michael Tokarev , KVM list , qemu-devel , Brian Kress To: Stefano Stabellini Return-path: Received: from mx1.redhat.com ([209.132.183.28]:57998 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752092Ab0ELQ5u (ORCPT ); Wed, 12 May 2010 12:57:50 -0400 In-Reply-To: Sender: kvm-owner@vger.kernel.org List-ID: On 05/12/2010 07:55 PM, Stefano Stabellini wrote: > >>> 3CEh index 26h W(R/W): BLT Source Pitch (5426 +) >>> bit 0-11 (5426-28) Number of bytes in a scanline at the source. >>> 0-12 (5429 +) do >>> >>> if the source BLT is supposed to be the number of bytes in a scanline at >>> the source, then 0 is not a correct value for it. >>> >>> >> It's useful if you have a one-line horizontal pattern you want to >> propagate all over. >> >> > > It might be useful all right, but it is not entirely clear what the > hardware should do in this situation from the documentation we have, and > certainly the current state of the cirrus emulation code doesn't help. > > Without any clear indication of what a Cirrus Logic graphic card would > have done here, I would choose the safest answer that is disregard the > "delicate" case (if it doesn't break Windows NT). > My guess is that the src or dst address simply doesn't increment. I think it's also fine to ignore the operation completely. > However I don't mind if we try to handle this case too, provided > that we handle it well, without SIGFPEs that is :) > -- Do not meddle in the internals of kernels, for they are subtle and quick to panic.