Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757370AbZDWMgX (ORCPT ); Thu, 23 Apr 2009 08:36:23 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1753058AbZDWMgM (ORCPT ); Thu, 23 Apr 2009 08:36:12 -0400 Received: from jurassic.park.msu.ru ([195.208.223.243]:49327 "EHLO jurassic.park.msu.ru" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752313AbZDWMgL (ORCPT ); Thu, 23 Apr 2009 08:36:11 -0400 Date: Thu, 23 Apr 2009 16:36:19 +0400 From: Ivan Kokshaysky To: Yinghai Lu Cc: Ingo Molnar , Linus Torvalds , Jesse Barnes , "H. Peter Anvin" , Andrew Morton , Thomas Gleixner , "linux-kernel@vger.kernel.org" , linux-pci@vger.kernel.org, yannick.roehlly@free.fr Subject: Re: [RFC PATCH 1/2] pci: don't assume pref memio are 64bit -v3 Message-ID: <20090423123619.GA11519@jurassic.park.msu.ru> References: <49EA57C4.1000603@kernel.org> <20090419090208.GA30211@elte.hu> <20090419090615.GA30631@elte.hu> <20090420223305.GA15340@jurassic.park.msu.ru> <49ED0EBC.4070901@kernel.org> <20090421105629.GB17904@jurassic.park.msu.ru> <49EF9C10.6090107@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <49EF9C10.6090107@kernel.org> User-Agent: Mutt/1.5.17 (2007-11-01) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2862 Lines: 64 On Wed, Apr 22, 2009 at 03:37:04PM -0700, Yinghai Lu wrote: > one system with 4g installed ( there is 1g hole) > > when 4G installed. > BIOS put ACPI etc need the hole > [ 0.000000] BIOS-provided physical RAM map: > [ 0.000000] BIOS-e820: 0000000000000000 - 000000000009bc00 (usable) > [ 0.000000] BIOS-e820: 000000000009bc00 - 00000000000a0000 (reserved) > [ 0.000000] BIOS-e820: 00000000000e3000 - 0000000000100000 (reserved) > [ 0.000000] BIOS-e820: 0000000000100000 - 00000000bffa0000 (usable) > [ 0.000000] BIOS-e820: 00000000bffa0000 - 00000000bffae000 (ACPI data) > [ 0.000000] BIOS-e820: 00000000bffae000 - 00000000bfff0000 (ACPI NVS) > [ 0.000000] BIOS-e820: 00000000bfff0000 - 00000000c0000000 (reserved) > [ 0.000000] BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved) > [ 0.000000] BIOS-e820: 00000000ffb00000 - 0000000100000000 (reserved) > [ 0.000000] BIOS-e820: 0000000100000000 - 0000000140000000 (usable) > so in kernel resource will be reserved for 0xbffa0000 - 0xbfff0000 for ACPI > 0x100000 - 0xbffa0000 for RAM... > > and BIOS set > [ 0.240007] pci 0000:00:01.0: bridge 64bit mmio pref: [0xbdf00000-0xddefffff] > [ 0.237102] pci 0000:01:00.0: reg 10 32bit mmio: [0xc0000000-0xcfffffff] > that is conflict with reserved res. so it can not be reserved Kernel. > > then Kernel try to get range from 0x140000000 ( above the RAM, 5G and above 4g) > and set let the bridge to use it, and ATI cards to use it. > > but the problem is that ATI only support 32bit ... Yinghai, you are trying to get a quick fix for quite a complex problem that cannot be solved with a quick fix. Even more, there is no rush on a quick fix because it's not a critical bug at all. 32-bit stuff ends up above 4G *only* when there is no free space left on the 32-bit PCI bus, and it can be considered as very effective (though rather ugly) way of disabling the BAR that we failed to allocate. In this particular case it was simply a side effect of the "pci_mem_start" issue (which was indeed critical, but hopefully fixed now). > +/* need to insert those two under iomem */ > +struct resource iomem32_resource = { > + .name = "PCI mem 32bit", > + .start = 0, > + .end = 0xffffffff, > + .flags = IORESOURCE_MEM, > +}; > +struct resource iomem64_resource = { > + .name = "PCI mem 64bit", > + .start = 1ULL<<32, > + .end = -1, > + .flags = IORESOURCE_MEM | IORESOURCE_MEM_64, > +}; > + This only works on x86 and similar systems with 1:1 CPU address to bus address mapping. There is a lot of machines with multiple 32-bit PCI bus spaces (4G per PCI domain). Ivan. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/