I am using the version deployed with fedora rawhide (2.6.99.902) with xserver-1.6 on my 945GM and it looks like theres a memory/buffer leak somewhere. After a day of normal desktop work on KDE-4.2 (without composition manager), top reports Xorg is using: 1,4gb VIRT 1,2gb RSS 1,1gb SHR and: "lsof | grep "drm mm object" | wc -l" is somewhere arround ~8500 The groth rate seems to be at least a bit related to the QT4 theme choosen, since I switched from "plastik" to "windows" groth is slower, but still seems unbound.
This may be the "we don't ever free objects from the BO cache" problem. I'm at 8.5k and 1GB after a couple of days, though much less mapped to the server (likely since I'm running software that has much fewer software fallbacks, so fewer cached buffers have mappings). If it is that problem, then the amount of memory allocated should level out. Does your leak continue linearly over time?
this seems similar to bug#20704.
I think I can confirm this; on a little different setup though: Kubuntu Jaunty Beta; last updated 5min before this report: * xorg-server 2:1.6.0-0ubuntu6 (buildd@rothera.buildd) * linux 2.6.28-11-generic (ubuntu: linux-image-2.6.28-11-generic, version: 2.6.28-11.38) * xserver-xorg-video-intel 2:2.6.3-0ubuntu2 I'm using KDE 4.2 *with* desktop effects. My uptime is 46h, X weighting: * VIRT 1208m * RES 528m * SHR 31m Noticed that in the past 6-8 hours X has gained about 200M more VIRT, the only software running at that time was ktorrent. ktorrent might be a bit problematic itself, as it seems to cause X to use 50% of CPU even when just keeping it minimized. Here: $ sudo lsof | grep "drm mm object" | wc -l 5261 $ lspci | grep VGA 00:02.0 VGA compatible controller: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (rev 0c) My GTK theme is currenlty QtCurve. I'll keep this one on, if I could get more information on the linearity of this.
Few hours in, after semi-active Firefox usage: VIRT 1297m (+89) RSS 528m SHR 31m I've only got 2GB of ram, and at this point Linux has swapped almost 2GB. Cannot continue using this anymore. Could some dev hint on what kind of information should I gather in the next session?
Gordin: I don't think this is related to 20704, I experience it also whithout running any opengl app/compositor. This bug is really disturbing on my laptop, because it slows down syspend to disk a lot. Furthermore I have less swap than RAM (1,5gb swap, 3gb ram) which has never been a problem until now - now I run out of it sometimes when suspending.
I confirm this (Gentoo, x11-drivers/xf86-video-intel-2.6.3-r1, KDE4/Qt-4.5/QtCurve). Each day I have to restart X, because of huge RAM usage. It reveals as big HDD usage. After zapping X (ctrl-alt-backspace), there are only 100Mb of cache and 1.5Gb in free mem. (In reply to comment #1) > If it is that problem, then the amount of memory allocated should level out. > Does your leak continue linearly over time? > Yes, it goes up until get all free mem.
I think I'm seeing the same memory leak. It's driving me insane because I have to reboot my computer every 3-4hrs if I'm using UXA!!! I'm using Ubuntu 9.4 and I have an intel GM945. I've tested with kernels 2.6.28 and 2.6.30-rc. I've also tested the intel 2.6 / 2.7 / 2.7.99 drivers. All of them have a memory leak. intel 2.6 and 2.7 seems to exhibit the leak more with compiz. This means that if I sort by process virt mem then compiz is on top then xorg. But with the intel 2.7.99 xorg eats memory faster. It seems that only the virt mem increases and not the res mem. Either way after about 3hrs xorg is using >600M and compiz is using >300M. After that the computer starts to exhibit rendering errors and is very slow. I only have 1G of ram but I'm using 1.4G mem -- the computer's toast at this point, have to reboot. Is there any information that I could provide that would help?
I've been experiencing this bug for a quite some time now. I found an easy way to trigger an amassed leakage by using Okular (tested with 4.2.2): 1. Check the value of 'object bytes' in /proc/dri/0/gem_objects 2. Run Okular, and open up a large enough PDF file (i.e. 100 pages?) 3. Scroll through the pages so they all get rendered 4. After 50 pages or so check 1. again. Closing Okular does not free the memory. Make sure you set "Aggressive" in Okular's Performance->Memory usage. I also noticed some strange font (and font color too) corruption when stressing my system with this technique. If taken to the limits, the system would grind to a halt (with magic sysrq keys working though). Tested on: - GMA965 running xf86-video-intel from git* - kernel from git* - xorg-server 1.6.1 - w/o screen compositing - w/ & w/o KMS - w/ 1GB of RAM * fetched on 2009.05.07
I've updated to xf86-video-intel-2.7. Out of memory condition doesn't appear no more, but there is another issue with memory: as I understand, Xorg tries to clean memory, so video output fully freezes for long periods (up to minute without any response) and processor starts to run on max power (cooler starts and throw hot air). After some time normal operation is possible, until next memory cleaning. In dmesg: May 8 20:04:27 localhost kernel: [ 5891.570049] X:3001 freeing invalid memtype d5329000-d532a000 May 8 20:04:27 localhost kernel: [ 5891.570085] X:3001 freeing invalid memtype d532a000-d532b000 May 8 20:04:27 localhost kernel: [ 5891.570122] X:3001 freeing invalid memtype d532b000-d532c000 May 8 20:04:27 localhost kernel: [ 5891.570158] X:3001 freeing invalid memtype d532c000-d532d000 May 8 20:04:27 localhost kernel: [ 5891.570194] X:3001 freeing invalid memtype d532d000-d532e000 May 8 20:04:27 localhost kernel: [ 5891.570231] X:3001 freeing invalid memtype d532e000-d532f000 May 8 20:04:27 localhost kernel: [ 5891.570267] X:3001 freeing invalid memtype d532f000-d5330000 May 8 20:04:27 localhost kernel: [ 5891.570304] X:3001 freeing invalid memtype d5330000-d5331000 May 8 20:04:27 localhost kernel: [ 5891.570340] X:3001 freeing invalid memtype d5331000-d5332000 continusly. linux-2.6.29.1 with KMS fix patch. 00:02.0 VGA compatible controller: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (rev 0c) xorg-server-1.6.1
Same for me (gentoo, amd64) Xorg leaks drm objects massively: 00:02.0 VGA compatible controller: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (rev 0c) tried: xorg-server: 1.5.3, xorg-server-1.5.99.1-877-g525aa17 xf86-video-intel: 2.7.0, 2.7.1, 2.7.99.1-28-gad21288 libdrm: 2.4.5, 2.4.11, libdrm-2.4.11-2-gf355ad8 kernels: 2.6.29, 2.6.30-rc6 30 minutes of working xorg (linear leakage) $ pmap `pidof X` | grep 'drm mm obj' | wc -l 2218 $ pmap `pidof X` | tail ... total 526708K Starting from linux-2.6.30-rc6 I got in dmesg: [336622.157909] [drm:i915_get_vblank_counter] *ERROR* trying to get vblank count for disabled pipe 1
I also have this issue on 2.6.30-rc8+git and xf86-intel git on a samsung nc10. As uptime is decreased due to the crasher bugs it hardly matters to me currently :(
All problems disappear when I enable i915 KMS in kernel (linux-2.6.30-rc8 for now). Xorg VSIZE reduces from 500M to 200M, VT switch does not cause any warnings. So, bug only appears in non-KMS mode. pmap still shows vma growth
This should fix the known memory growth problems: commit 3f3c5be6f908272199ccf53f108b1124bfe0a00e Author: Eric Anholt <eric@anholt.net> Date: Thu Jul 9 17:49:46 2009 -0700 intel: Free buffers in the BO cache that haven't been reused in a while. The goal of the BO cache is to keep buffers on hand for fast continuous use, as in every frame of a game or every batchbuffer of the X Server. Keeping older buffers on hand not only doesn't serve this purpose, it may hurt performance by resulting in disk cache getting kicked out, or even driving the system to swap. Bug #20766.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.