From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:39648) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R8EpO-0003Lh-Fs for qemu-devel@nongnu.org; Mon, 26 Sep 2011 13:18:51 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1R8EpK-0001ht-Jm for qemu-devel@nongnu.org; Mon, 26 Sep 2011 13:18:50 -0400 Received: from mx1.redhat.com ([209.132.183.28]:16021) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R8EpK-0001hm-9u for qemu-devel@nongnu.org; Mon, 26 Sep 2011 13:18:46 -0400 Message-ID: <4E80B3EF.3070202@redhat.com> Date: Mon, 26 Sep 2011 20:18:39 +0300 From: Avi Kivity MIME-Version: 1.0 References: <4E7A828A.3030404@codemonkey.ws> <4E7F366F.9060501@redhat.com> <4E7F5B62.1090307@redhat.com> <4E804F20.2090007@redhat.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [FYI] Soft feature freeze for 1.0 is 10/15 (three weeks away) List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Blue Swirl Cc: qemu-devel On 09/26/2011 08:15 PM, Blue Swirl wrote: > On Mon, Sep 26, 2011 at 10:08 AM, Avi Kivity wrote: > > On 09/25/2011 08:31 PM, Blue Swirl wrote: > >> > >> > > >> > Please point out a test case and I'll try to fix it. > >> > >> Run qemu-system-ppc without any arguments. There is a black bar > >> (because of vga.chain4), it shouldn't be there. > > > > With your pci hole patch, it's fixed, except for: > > > > escc_mem = escc_init(0x80013000, pic[0x25], pic[0x24], > > serial_hds[0], serial_hds[1], ESCC_CLOCK, 4) > > > > This puts escc bang into the framebuffer. Changing it to 0x90013000 makes > > the black bar go away. > > > > Before the memory API, this worked, likely because the framebuffer overlays > > escc. > > > > The correct fix depends on what the hardware does. Is escc really > > registered into the pci area, and again as a BAR? > > I think the previous code assumed that there is a single BAR with > default address of 0x80013000, but it can move as controlled by macio > mapping. So the fix would be to just drop this extraneous mapping? -- error compiling committee.c: too many arguments to function