From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=33339 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OCFFl-0006sR-HC for qemu-devel@nongnu.org; Wed, 12 May 2010 12:57:50 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OCFFj-0007dr-EB for qemu-devel@nongnu.org; Wed, 12 May 2010 12:57:49 -0400 Received: from mx1.redhat.com ([209.132.183.28]:28503) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OCFFi-0007dl-RD for qemu-devel@nongnu.org; Wed, 12 May 2010 12:57:47 -0400 Message-ID: <4BEADE03.7040405@redhat.com> Date: Wed, 12 May 2010 19:57:39 +0300 From: Avi Kivity MIME-Version: 1.0 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> 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 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.