linux-kernel - Re: [PATCH] x86/pci: do assign root bus res if

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: <86802c440904271400q379da621ja808c96152c3fb8b@mail.gmail.com>
Date:	Mon, 27 Apr 2009 14:00:16 -0700
From:	Yinghai Lu <yhlu.kernel@...il.com>
To:	Bjorn Helgaas <bjorn.helgaas@...com>
Cc:	Jesse Barnes <jbarnes@...tuousgeek.org>,
	Ingo Molnar <mingo@...e.hu>, "H. Peter Anvin" <hpa@...or.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	linux-pci@...r.kernel.org, Gary Hade <garyhade@...ibm.com>,
	Alex Chiang <achiang@...com>, linux-acpi@...r.kernel.org,
	Matthew Wilcox <matthew@....cx>
Subject: Re: [PATCH] x86/pci: do assign root bus res if _CRS is used

On Mon, Apr 27, 2009 at 1:39 PM, Bjorn Helgaas <bjorn.helgaas@...com> wrote:

>>
>> other system may have broken _CRS.
>
> Do you have examples of problems here, or are you just worried that
> there *may* be problems?
one system with three chains... with pci=use_crs
[    9.365669] pci_bus 0000:00: resource 0 io:  [0x00-0x3af]
[    9.371065] pci_bus 0000:00: resource 1 io:  [0x3e0-0xcf7]
[    9.376551] pci_bus 0000:00: resource 2 io:  [0x3b0-0x3bb]
[    9.382028] pci_bus 0000:00: resource 3 io:  [0x3c0-0x3df]
[    9.387513] pci_bus 0000:00: resource 4 io:  [0xd00-0xefff]
[    9.393077] pci_bus 0000:00: resource 5 mem: [0x0a0000-0x0bffff]
[    9.399084] pci_bus 0000:00: resource 6 mem: [0x0d0000-0x0dffff]
[    9.405089] pci_bus 0000:00: resource 7 mem: [0xdd000000-0xdfffffff]
[    9.505332] pci_bus 0000:40: resource 0 io:  [0x5000-0x8fff]
[    9.510991] pci_bus 0000:40: resource 1 mem: [0xdb000000-0xdcffffff]
[    9.553378] pci_bus 0000:80: resource 0 io:  [0x1000-0x4fff]
[    9.559036] pci_bus 0000:80: resource 1 mem: [0xda000000-0xdaffffff]

without that: amd_bus.c will read that from pci conf space
[    9.310965] pci_bus 0000:00: resource 0 io:  [0x9000-0xefff]
[    9.316621] pci_bus 0000:00: resource 1 io:  [0x00-0xfff]
[    9.322020] pci_bus 0000:00: resource 2 mem: [0xdd000000-0xdfffffff]
[    9.328373] pci_bus 0000:00: resource 3 mem: [0x0a0000-0x0bffff]
[    9.334378] pci_bus 0000:00: resource 4 mem: [0xc0000000-0xd9ffffff]
[    9.340731] pci_bus 0000:00: resource 5 mem: [0xf0000000-0xffffffff]
[    9.347084] pci_bus 0000:00: resource 6 mem: [0x840000000-0xfcffffffff]
[    9.444440] pci_bus 0000:40: resource 0 io:  [0x5000-0x8fff]
[    9.450099] pci_bus 0000:40: resource 1 io:  [0xf000-0xffff]
[    9.455757] pci_bus 0000:40: resource 2 mem: [0xdb000000-0xdcffffff]
[    9.498118] pci_bus 0000:80: resource 0 io:  [0x1000-0x4fff]
[    9.503777] pci_bus 0000:80: resource 1 mem: [0xda000000-0xdaffffff]

>
>> maybe we could try to use DMI whitelist them?
>
> I don't like a whitelist because it requires ongoing maintenance
> for correctly-working machines.  A blacklist is nicer because it
> only requires maintenance for *broken* machines.  A date-based
> solution would be better from that point of view.

could try apply that in development cycle like -rcX, and disable that
formal release.
so could find more broken system.

YH
--
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/