Skip to contentSkip to conversation

drm_gem_create_mmap_offset / intel_uxa_prepare_access bo problems

DISCUSSION Knut Petersen 2 participants 4 messages Nov 22, 2012 – Dec 4, 2012

lore
Share & tools
lore
#0 lore raw

Hi Chris!

Problem:
=======
Slowdown of system, missing icons after 16 days kernel uptime and 12 days Xserver uptime.
Xorg log: flooded with "(WW) intel(0): intel_uxa_prepare_access: bo map (use gtt? 1, access 1) failed: No space left on device" lines
dmesg: flooded with "[drm:drm_gem_create_mmap_offset] *ERROR* failed to allocate offset for bo 0" entries

Hardware
=======
AOpen i915GMm-hfs, Pentium-M Dothan

Software:
=======
linux kernel 3.6.6
full Xorg git master, fetch/build 10 November 2012,
video-intel: git f5d79b202dd448e61ab6ffce26fe9cbf9051d770
xserver: git 011f8458805e443ac9130865d2840a929a00cabf rest of system openSuSE 12.1

Any idea?

cu,
Knut

#1 lore raw
Quoted 21 lines · Knut Petersen

Hi Chris!

Problem:
=======
Slowdown of system, missing icons after 16 days kernel uptime and 12 days Xserver uptime.
Xorg log: flooded with "(WW) intel(0): intel_uxa_prepare_access: bo map (use gtt? 1, access 1) failed: No space left on device" lines
dmesg: flooded with "[drm:drm_gem_create_mmap_offset] *ERROR* failed to allocate offset for bo 0" entries

Hardware
=======
AOpen i915GMm-hfs, Pentium-M Dothan

Software:
=======
linux kernel 3.6.6
full Xorg git master, fetch/build 10 November 2012,
video-intel: git f5d79b202dd448e61ab6ffce26fe9cbf9051d770
xserver: git 011f8458805e443ac9130865d2840a929a00cabf rest of system openSuSE 12.1

Quoted 1 line

Any idea?

Well you kernel and drm has all the latest protections, which is good because it's usually a bo leak of some sort. First stop is to check xrestop, /sys/kernel/debug/dri/0/i915_gem_objects and intel-gpu-tools/scripts/who.sh

That will undoubtably reveal a large number of objects being held by the X server...
-Chris

Signature · 1 line
Chris Wilson, Intel Open Source Technology Centre
#2 lore raw
Quoted 1 line · Chris Wilson

Well you kernel and drm has all the latest protections, which is good because it's usually a bo leak of some sort. First stop is to check xrestop, /sys/kernel/debug/dri/0/i915_gem_objects and intel-gpu-tools/scripts/who.sh That will undoubtably reveal a large number of objects being held by the X server... -Chris

As the server had to be rebooted it will probably take some days to gather more information.

cu,
Knut

#3 lore raw
In reply to Chris Wilson

Hi everybody!

xrestop is functional again in xorg master, so I remembered to have a look at the problem reported two weeks ago. It is caused by qinternet.

qinternet is a small utility that is frequently used in opensuse systems to control network connections. It attaches itself to the system tray of the kde panel, but it also might be used with other desktop environments.

xrestop, proc/sys/fs/file-nr and /sys/kernel/debug/dri/0/i915_gem_objects show that qinternet allocates one small pixmap every second. So it steadily increases the number of inactive gem objects, the memory usage and the number of used file descriptors. It is clear that this causes problems after some time.

If someone at opensuse is reading this: This is an opensuse problem. opensuse is a nice distribution, but as long as you do require people to create a Novell acount with full address, phone number etc. to be able to access the opensuse bugzilla I will not report bugs there.

cu,
Knut

Quoted 19 lines · Chris Wilson
Quoted 9 lines · Knut Petersen

Hi Chris!

Problem:
=======
Slowdown of system, missing icons after 16 days kernel uptime and 12 days Xserver uptime.
Xorg log: flooded with "(WW) intel(0): intel_uxa_prepare_access: bo map (use gtt? 1, access 1) failed: No space left on device" lines
dmesg: flooded with "[drm:drm_gem_create_mmap_offset] *ERROR* failed to allocate offset for bo 0" entries

Well you kernel and drm has all the latest protections, which is good because it's usually a bo leak of some sort. First stop is to check xrestop, /sys/kernel/debug/dri/0/i915_gem_objects and intel-gpu-tools/scripts/who.sh

That will undoubtably reveal a large number of objects being held by the X server...
-Chris