Re: intel kms "Failed to allocate space for kernel memory manager"

["Jan Dittmer" <jdi@l4x.org>]

On Mon, Jan 12, 2009 at 10:19 PM, Jan Dittmer <jdi@l4x.org> wrote:
> On Mon, Jan 12, 2009 at 6:56 PM, Jesse Barnes <jbarnes@virtuousgeek.org> wrote:
>> On Monday, January 12, 2009 12:37 am Jan Dittmer wrote:
>>> On Mon, Jan 12, 2009 at 9:04 AM, Dave Airlie <airlied@gmail.com> wrote:
>>> > the latest git should work with kms on most chipsets, we are still
>>> > chasing down some issues on some chipsets,
>>>
>>> So is there anything I can test to help you get it going on 'my' chipset
>>> (GM965, Lenovo X300)?
>>
>> I do much of my testing on GM965, so you should be able to get it to work with
>> the latest bits:
>>  - libdrm from git master of mesa/drm
>>  - mesa from git master of mesa/mesa
>>  - xf86-video-intel from git master
>>  - drm-intel-next from anholt's kernel tree
>>    (git://git.kernel.org/pub/scm/linux/kernel/git/anholt/drm-intel)
>>
>> You'll need to use UXA as your AccelMethod.  If you run into issues with the
>> above, please file bugs (if you don't already see your issue filed) at
>> bugs.freedesktop.org.
>
> Thanks, at least X starts now, though dri is still broken. Is there
> any quick fix to:
>
> name of display: :0.0
> libGL: XF86DRIGetClientDriverName: 1.9.0 i965 (screen 0)
> libGL: OpenDriver: trying /usr/local/lib/dri/i965_dri.so
> drmOpenDevice: node name is /dev/dri/card0
> drmOpenDevice: open result is 4, (OK)
> drmOpenByBusid: Searching for BusID pci:0000:00:02.0
> drmOpenDevice: node name is /dev/dri/card0
> drmOpenDevice: open result is 4, (OK)
> drmOpenByBusid: drmOpenMinor returns 4
> drmOpenByBusid: drmGetBusid reports pci:0000:00:02.0
> libGL error: drmMap of framebuffer failed (Resource temporarily unavailable)
> libGL error: reverting to software direct rendering

For each call to glxinfo (or any other libgl program) I get

[   93.768928] glxinfo:3071 map pfn expected mapping type write-back
for e5720000-e5f90000, got uncached
[   93.769760] glxinfo:3071 freeing invalid memtype e5720000-e5f90000

written in my kernel log buffer.

Jan