lkml.org 
[lkml]   [2014]   [Feb]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: pci-3.14 resource alloc
On Tue, Feb 18, 2014 at 6:59 AM, Bjorn Helgaas <bhelgaas@google.com> wrote:
> On Tue, Feb 18, 2014 at 3:08 AM, Steven Newbury <steve@snewbury.org.uk> wrote:

>> No, the only unusual option is I use pci=nocrs since the bios is
>> completely ignorant of support for 64bit BARs.
>
> Hi Steven, this is a tangent, but can you collect the complete dmesg
> log with "pci=nocrs" and let me know what happens when you *don't* use
> "pci=nocrs" (a complete dmesg log there would be useful too, but I
> don't know if you can boot without it)? I think Linux *should* be
> able to handle 64bit BARs even if the BIOS doesn't.
>
> Please post these as a separate thread so we don't muddle this
> conversation with Yinghai.

Oh, never mind. I think I remember now. I think the problem is not
so much that the BIOS doesn't handle 64bit *BARs*, but that your BIOS
doesn't report 64bit host bridge *apertures*, and you want to use
space above 4G for a graphics card or something.

That's not really anything we can fix in PCI because PCI doesn't
discover those apertures. Host bridge drivers like the generic ACPI
pci_root.c or the native amd_bus.c discover them. If those drivers
don't discover them, PCI can't just make them up.

It might be nice if we had cleaner kernel options to say "assume a
host bridge window here" and "put this device here," so you didn't
have to use the big hammer of "pci=nocrs". It's sort of a pain to
figure out how to attach info like that to the correct device (there
might be several host bridges, so how do you specify which one you
care about?), but maybe it could be done.

Bjorn


\
 
 \ /
  Last update: 2014-02-18 16:41    [W:1.707 / U:0.004 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site