PCI resources above 4GB

Steven Newbury steve at snewbury.org.uk
Fri Apr 13 04:58:47 PDT 2012

Hash: SHA1

On 13/04/12 12:45, Steven Newbury wrote:
> On Fri, 13 Apr 2012, 09:26:55 BST, Yinghai Lu <yinghai at kernel.org>
> wrote:
>> On Thu, Apr 12, 2012 at 9:40 AM, Steven Newbury
>> <steve at snewbury.org.uk> wrote:
>>>>> It would be useful to preserve as much low PCI memory
>>>>> address space as possible for hotplug devices (like my
>>>>> Radeon), but the other problem is small regions get
>>>>> allocated at the bottom, resulting in the inability to find
>>>>> large aligned regions later on. I see code to default to
>>>>> top-down allocation was reverted, I guess I'm going to have
>>>>> to dig into the archive to find out why...
>> Please check attached patches that will find_resource with fit.
>> It may leave space for your hotplug devices.
>> PCI: Should add children device res to fail list PCI: Try to
>> allocate mem64 above 4G at first intel-gtt: Read 64bit for
>> gmar_bus_addr PCI: Make sure assign same align with large size
>> resource at first resource: make find_resource could return just
>> fit resource PCI: Don't allocate small resource in big empty
>> space. resource: only return range with needed align
>> You can get them from
>> git://git.kernel.org/pub/scm/linux/kernel/git/yinghai/linux-yinghai.git
> I pulled this in on top of a branch with any of the prior PCI
> patches since they conflict anyway.
> It's not stable, crashes soon after GMA comes up. (Could be
> unrelated breakage in linus/master? Probably not but I will
> verify.)  I noticed the high allocations are occuring from the top
> of 64-bit address-space, whilst /proc/cpuinfo shows only 48 bits of
> virtual addressing.  Could that be why..?
To reply to myself again, I should have said crashes shortly after
Xorg initialises using the intel driver, in both cases!  I'm building
a kernel now without the patch set to see if it's unrelated.  If it
still dies I'll try applying your patch set to a branch without the
changes from linus/master... (should have done that anyway...)

> Also, when not docked GMA still isn't mapped high so there's no
> room for the 256M radeon pref mem.
> Attached /proc/iomem output for docked and undocked.

Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/


More information about the dri-devel mailing list