linux-kernel - Re: Linux 2.6.27-rc5: System boot regression caused by commit a2bd7274b47124d2fc4dfdb8c0591f545ba749dd

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]

Date:	Fri, 29 Aug 2008 21:41:53 -0700
From:	"Yinghai Lu" <yhlu.kernel@...il.com>
To:	"Linus Torvalds" <torvalds@...ux-foundation.org>
Cc:	"Rafael J. Wysocki" <rjw@...k.pl>,
	"Linux Kernel Mailing List" <linux-kernel@...r.kernel.org>,
	"Jeff Garzik" <jeff@...zik.org>, "Tejun Heo" <htejun@...il.com>,
	"Ingo Molnar" <mingo@...e.hu>,
	"David Witbrodt" <dawitbro@...global.net>,
	"Andrew Morton" <akpm@...ux-foundation.org>,
	"Kernel Testers" <kernel-testers@...r.kernel.org>
Subject: Re: Linux 2.6.27-rc5: System boot regression caused by commit a2bd7274b47124d2fc4dfdb8c0591f545ba749dd

On Fri, Aug 29, 2008 at 8:24 PM, Linus Torvalds
<torvalds@...ux-foundation.org> wrote:
>
>
> On Fri, 29 Aug 2008, Yinghai Lu wrote:
>>
>> we need to use insert_resource_split_to_fit instead...
>>
>> otherwise __request_region will not be happy.
>
> Are you really really sure?
>
> Try just removing the IORESOURCE_BUSY. As mentioned, if we expect the PCI
> BAR's to work with the e820 resources, then BUSY really is simply not
> right any more. Not that I think it should matter either..
>
> The ones that are added _early_ should be IORESOURCE_BUSY (ie the ones
> that cover RAM), but the others we now expect to nest with PCI BARs.

not all. some are MMCONF, some are for GART, and some for fixed lapic,
and fixed ioapic, and fixed HPET.

>
> But since we add them after we have parsed the BAR's, I don't even see why
> the BUSY bit should even matter - we've already added the fixed BARs, and
> any newly allocated non-fixed ones shouldn't be allocated in e820 areas
> _regardless_ of whether the BUSY bit is set or not.
>
> So pls explain why it matters?

if we don't add the IORESOURCE_BUSY, why bother to add these entries...

good layout from BIOS, it should only reserve mmio range is not showing in BAR.

for example:
0xdc000000 - 0xdd000000 for GART ( some offset BAR 0x94)
0xdd000000 - 0xde000000 is for bus 0x80
0xde000000 - 0xdf000000 is for bus 0x00
0xe0000000 - 0xf0000000 is for mmconfig ( CPU set it in MSR for amd fam 10h)

if one stupid BIOS set
0xdc000000 - 0x100000000 for reserved.

then when in insert that range late
we should still have set ranges other than range 0xdd000000 - 0xdf000000

also do we need set other leaf range in 0xdd000000 - 0xdf0000000 ?

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/