linux-kernel - Re: [Bug #15124] PCI host bridge windows ignored (works with pci=use

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <alpine.LFD.2.00.1001260955060.3574@localhost.localdomain>
Date:	Tue, 26 Jan 2010 10:16:12 -0800 (PST)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Bjorn Helgaas <bjorn.helgaas@...com>
cc:	"Rafael J. Wysocki" <rjw@...k.pl>,
	Jeff Garrett <jeff@...rrett.org>,
	Yinghai Lu <yinghai@...nel.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Kernel Testers List <kernel-testers@...r.kernel.org>,
	Linux PCI <linux-pci@...r.kernel.org>,
	Jesse Barnes <jbarnes@...tuousgeek.org>,
	Myron Stowe <myron.stowe@...com>,
	Matthew Garrett <mjg59@...f.ucam.org>,
	Ingo Molnar <mingo@...e.hu>
Subject: Re: [Bug #15124] PCI host bridge windows ignored (works with
 pci=use_crs)



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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/