lkml.org 
[lkml]   [2008]   [Aug]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Linux 2.6.27-rc5: System boot regression caused by commit a2bd7274b47124d2fc4dfdb8c0591f545ba749dd
On Sat, Aug 30, 2008 at 12:31 PM, Linus Torvalds
<torvalds@linux-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


\
 
 \ /
  Last update: 2008-08-30 22:17    [W:0.107 / U:0.396 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site