Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754734Ab0AZSRP (ORCPT ); Tue, 26 Jan 2010 13:17:15 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1754466Ab0AZSRO (ORCPT ); Tue, 26 Jan 2010 13:17:14 -0500 Received: from smtp1.linux-foundation.org ([140.211.169.13]:53604 "EHLO smtp1.linux-foundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753936Ab0AZSRN (ORCPT ); Tue, 26 Jan 2010 13:17:13 -0500 Date: Tue, 26 Jan 2010 10:16:12 -0800 (PST) From: Linus Torvalds X-X-Sender: torvalds@localhost.localdomain To: Bjorn Helgaas cc: "Rafael J. Wysocki" , Jeff Garrett , Yinghai Lu , Linux Kernel Mailing List , Kernel Testers List , Linux PCI , Jesse Barnes , Myron Stowe , Matthew Garrett , Ingo Molnar Subject: Re: [Bug #15124] PCI host bridge windows ignored (works with pci=use_crs) In-Reply-To: <201001261032.37053.bjorn.helgaas@hp.com> Message-ID: References: <20100126071912.GA7543@jgarrett.org> <201001261348.59508.rjw@sisk.pl> <201001261032.37053.bjorn.helgaas@hp.com> User-Agent: Alpine 2.00 (LFD 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1429 Lines: 32 On Tue, 26 Jan 2010, Bjorn Helgaas wrote: > > which IS big enough, and we know the bridge is in fact forwarding the > [mem 0xd0000000-0xdfffffff 64bit pref] region, because the Radeon works > when Jeff boots with "pci=use_crs". I bet it's a subtractive decode thing. Sure, it could be just another undocumented range register (does anybody have the datasheet for that thing?) but Intel tends to often have subtractive decode. That system in question has three PCI express root ports, but two of them have IO and memory disabled according to the lspci info. So maybe it's as simple as that "I/O Hub PCI Express Root Port 7" just catching anything that nobody else does, and the single IOH host chip doing the same? > I think we should remove intel_bus.c before .33. It's breaking boxes > and we don't know how to fix it. Even if we do find out how to fix it, > I think we should move toward using _CRS instead, because that's what > Windows uses and it's an easy way for the firmware to tell us about > platform quirks. I suspect that for 33 it is indeed best to just revert. But somebody is bound to have information on how the actual hardware works. Yinghai? Linus -- 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/