From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S265130AbUAOQ6j (ORCPT ); Thu, 15 Jan 2004 11:58:39 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S265162AbUAOQ6j (ORCPT ); Thu, 15 Jan 2004 11:58:39 -0500 Received: from stat1.steeleye.com ([65.114.3.130]:57015 "EHLO hancock.sc.steeleye.com") by vger.kernel.org with ESMTP id S265130AbUAOQ6g (ORCPT ); Thu, 15 Jan 2004 11:58:36 -0500 Subject: Re: [PATCH] Intel Alder IOAPIC fix From: James Bottomley To: "Eric W. Biederman" Cc: Linus Torvalds , Andrew Morton , Linux Kernel In-Reply-To: References: <1073876117.2549.65.camel@mulgrave> <1073948641.4178.76.camel@mulgrave> <1073954751.4178.98.camel@mulgrave> <1074012755.2173.135.camel@mulgrave> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 (1.0.8-9) Date: 15 Jan 2004 11:58:10 -0500 Message-Id: <1074185897.1868.118.camel@mulgrave> Mime-Version: 1.0 Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 2004-01-15 at 00:18, Eric W. Biederman wrote: > James Bottomley writes: > > > On Mon, 2004-01-12 at 19:25, Linus Torvalds wrote: > > > I think BARs 1-5 don't exist at all. Being set to all ones is common for > > > "unused" (it ends up being a normal result of a lazy probe - you set all > > > bits to 1 to check for the size of the region, and if you decide not to > > > map it and leave it there, you'll get the above behaviour). > > > > > > I suspect only BAR0 is actually real. > > > > OK, I cleaned up the patch to forcibly insert BAR0 and clear BARs 1-5 > > (it still requires changes to insert_resource to work, though). > > When I looked at the ia64 code that uses insert_resource (and I admit I am > reading between the lines a little) it seems to come along after potentially > allocating some resources behind some kind of bridge and then realize a bridge > is there. Ah, that explains why it's expecting to find the new resource covering the old one. > Which is totally something different from this case where we just want > to ignore the BIOS, because we know better. I have seen a number of > boxes that reserver the area where apics or ioapics live. So I think > we need an IORESOURCE_TENTATIVE thing. This is the third flavor of > thing that has shown up, lately. > > Want me to code up a patch? Well, I'm not sure there's a need for it. It seems to me that all insert_resource is supposed to be doing is saying "I've got this resource here that should have been placed into the tree...please do it now". The ia64 I forgot this bridge, and the Alder IO-APIC this PCI BAR is actually the IO-APIC and thus part of the reserved BIOS area look to be similar aspects of the same problem. The only difference (which is what I needed the patch for) was that the Alder resource needs to go underneath the bios reserved area. How are you proposing that IORESOURCE_TENTATIVE should work? James