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: <86802c440808301314t525d1b75r9afcc73857cf5c79@mail.gmail.com>
Date:	Sat, 30 Aug 2008 13:14:57 -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 Sat, Aug 30, 2008 at 12:31 PM, Linus Torvalds
<torvalds@...ux-foundation.org> wrote:
>
>
> On Sat, 30 Aug 2008, Yinghai Lu wrote:
>>
>> do you agree to use quirk to make the BAR res to have correct end
>> between pci_probe and pci_resource_survey?
>
> In general I would agree, but now that I've looked at it a bit more, I
> actually don't think it's a bug in the chipset any more. See my previous
> email that crossed with yours.
>
> I suspect that that northbridge resource is basically acting as a bridge
> resource. So 0xe0000000 - 0xffffffff is actually _correct_. And MCFG being
> in that window (and being first in it) is just a detail.
>
> Look at the resource allocations on Rafael's machine: there are two
> different classes:
>
>  - outside that BAR3 window:
>
>   The "external gfx0 port A" decode (bridged by device 0000:02.0):
>
>        d8000000-dfffffff : PCI Bus 0000:01
>          d8000000-dfffffff : 0000:01:00.0
>            d8000000-d8ffffff : vesafb
>
>   and suspect the graphics port is special (considering that this is an
>   ATI chipset)
>
>  - inside that BAR3 window: everything else (PCI express):
>
>        e0000000-efffffff : PCI MMCONFIG 0
>        fe6f4000-fe6f7fff : 0000:00:14.2
>          fe6f4000-fe6f7fff : ICH HD audio
>        fe6fa000-fe6fafff : 0000:00:13.4
>          fe6fa000-fe6fafff : ohci_hcd
>        fe6fb000-fe6fbfff : 0000:00:13.3
>          fe6fb000-fe6fbfff : ohci_hcd
>        fe6fc000-fe6fcfff : 0000:00:13.2
>          fe6fc000-fe6fcfff : ohci_hcd
>        fe6fd000-fe6fdfff : 0000:00:13.1
>          fe6fd000-fe6fdfff : ohci_hcd
>        fe6fe000-fe6fefff : 0000:00:13.0
>          fe6fe000-fe6fefff : ohci_hcd
>        fe6ff000-fe6ff0ff : 0000:00:13.5
>          fe6ff000-fe6ff0ff : ehci_hcd
>        fe6ff800-fe6ffbff : 0000:00:12.0
>          fe6ff800-fe6ffbff : ahci
>        fe700000-fe7fffff : PCI Bus 0000:01
>          fe7c0000-fe7dffff : 0000:01:00.0
>          fe7e0000-fe7effff : 0000:01:00.1
>          fe7f0000-fe7fffff : 0000:01:00.0
>        fe800000-fe8fffff : PCI Bus 0000:02
>          fe8ffc00-fe8fffff : 0000:02:00.0
>            fe8ffc00-fe8fffff : ahci
>        fe900000-fe9fffff : PCI Bus 0000:03
>          fe9c0000-fe9dffff : 0000:03:00.0
>          fe9fc000-fe9fffff : 0000:03:00.0
>            fe9fc000-fe9fffff : sky2
>        fea00000-feafffff : PCI Bus 0000:04
>          feaffc00-feafffff : 0000:04:00.0
>            feaffc00-feafffff : ahci
>        feb00000-febfffff : PCI Bus 0000:05
>          febff000-febfffff : 0000:05:08.0
>            febff000-febff7ff : ohci1394
>        fec00000-fec00fff : IOAPIC 0
>        fed00000-fed003ff : HPET 2
>        fee00000-fee00fff : Local APIC
>        fff00000-ffffffff : reserved
>
> Hmm?
>
> (yeah, some of those resources are _really_ special, and are inside the
> CPU itself, eg the APIC and possibly HPET, and never necessarily even make
> it to the host bridge at all because they get decoded early).

wonder:
in old kernel, after BAR3 request_filed, pci_assigned_unassigned
should get update resource for that... but it could find that big
space for it.

that is interesting...

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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ