| 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
| ||
|
Message-ID: <alpine.LFD.2.01.0906241639030.3605@localhost.localdomain> Date: Wed, 24 Jun 2009 16:44:40 -0700 (PDT) From: Linus Torvalds <torvalds@...ux-foundation.org> To: Larry Finger <Larry.Finger@...inger.net> cc: Yinghai Lu <yhlu.kernel@...il.com>, Gary Hade <garyhade@...ibm.com>, Thomas Gleixner <tglx@...utronix.de>, Jesse Barnes <jbarnes@...tuousgeek.org>, Jaswinder Singh Rajput <jaswinder@...nel.org>, LKML <linux-kernel@...r.kernel.org>, Ingo Molnar <mingo@...e.hu>, x86 maintainers <x86@...nel.org>, Len Brown <lenb@...nel.org> Subject: Re: Regression with commit f9cde5f in 2.6.30-gitX On Wed, 24 Jun 2009, Larry Finger wrote: > > From what I read in Linus's mails, it may be a moot point; however, my > system boots with these 3, and only these 3, patches applied. Well, it's definitely not moot. We want "use_crs" to work, whether it's the default or not. I just doubt it should be the default (necessarily ever). The resources listed in the _CRS table may well be useful to make decisions on (minimally: "is this a root bridge", but possibly also scanning decisions). But I seriously doubt it makes any sense to insert the _CRS resources into the bus resource list. It might, for example, make sense to add them to the resource tree (after scanning), the same way we add the e820 resources to the resource tree. But judging from your dmesg: pci_bus 0000:00: resource 0 io: [0x00-0xcf7] pci_bus 0000:00: resource 1 io: [0xd00-0xffff] pci_bus 0000:00: resource 2 mem: [0x0a0000-0x0bffff] pci_bus 0000:00: resource 3 mem: [0x0c0000-0x0c3fff] pci_bus 0000:00: resource 4 mem: [0x0c4000-0x0c7fff] pci_bus 0000:00: resource 5 mem: [0x0c8000-0x0cbfff] pci_bus 0000:00: resource 6 mem: [0x0cc000-0x0cffff] pci_bus 0000:00: resource 7 mem: [0x0d4000-0x0d7fff] pci_bus 0000:00: resource 8 mem: [0x0d8000-0x0dbfff] pci_bus 0000:00: resource 9 mem: [0x0dc000-0x0dffff] pci_bus 0000:00: resource 10 mem: [0x0e0000-0x0e3fff] pci_bus 0000:00: resource 11 mem: [0x0e4000-0x0e7fff] pci_bus 0000:00: resource 12 mem: [0x0e8000-0x0ebfff] pci_bus 0000:00: resource 13 mem: [0x0ec000-0x0effff] pci_bus 0000:00: resource 14 mem: [0x0f0000-0x0fffff] pci_bus 0000:00: resource 15 mem: [0xc0000000-0xfebfffff] pci_bus 0000:01: resource 1 mem: [0xfc100000-0xfc1fffff] pci_bus 0000:01: resource 3 io: [0x00-0xcf7] pci_bus 0000:01: resource 4 io: [0xd00-0xffff] pci_bus 0000:01: resource 5 mem: [0x0a0000-0x0bffff] pci_bus 0000:01: resource 6 mem: [0x0c0000-0x0c3fff] pci_bus 0000:01: resource 7 mem: [0x0c4000-0x0c7fff] pci_bus 0000:01: resource 8 mem: [0x0c8000-0x0cbfff] pci_bus 0000:01: resource 9 mem: [0x0cc000-0x0cffff] pci_bus 0000:01: resource 10 mem: [0x0d4000-0x0d7fff] pci_bus 0000:01: resource 11 mem: [0x0d8000-0x0dbfff] pci_bus 0000:01: resource 12 mem: [0x0dc000-0x0dffff] pci_bus 0000:01: resource 13 mem: [0x0e0000-0x0e3fff] pci_bus 0000:01: resource 14 mem: [0x0e4000-0x0e7fff] pci_bus 0000:01: resource 15 mem: [0x0e8000-0x0ebfff] pci_bus 0000:01: resource 16 mem: [0x0ec000-0x0effff] pci_bus 0000:01: resource 17 mem: [0x0f0000-0x0fffff] pci_bus 0000:01: resource 18 mem: [0xc0000000-0xfebfffff] none of those look in any way like sensible "resources" to be put in the device. Quite frankly, they look like total garbage to me. 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/
Powered by blists - more mailing lists