[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#585663: marked as done (xorg: i915 and DRI leak memory)

Your message dated Sun, 1 Aug 2010 14:18:19 +0200
with message-id <20100801121819.GI3096@radis.liafa.jussieu.fr>
and subject line Re: Bug#585663: xorg: i915 and DRI leak memory
has caused the Debian Bug report #585663,
regarding xorg: i915 and DRI leak memory
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org
immediately.)


-- 
585663: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=585663
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message --- 
Package: xorg
Version: 1:7.5+6
Severity: important


X with xserver-xorg-video-intel is no longer usable: is causes memory corruption
which can only be solved by restarting X every week or so.

A little bit of googling suggests this is related to DRI corrupting kernel memory,
so I am not sure if this is kernel or X bug, please retarget as necessary.

Symptoms: SUnreclaim slab increases by about 1 MB per minute, yielding about 1 GB
of SUnreclaim within two weeks. This can be slowed down by not doing anything or
speeded up by opening windows, moving them around, causing a program to draw stuff
on screen etc. Basically any use of X increases the rate of memory corruption while
just letting it idle (without a screensaver!) slows it down. Of course, slowing
memory corruption speed down by doing nothing is not quite acceptable - if I did
no want to do anything with X, I would not start X in the first place.

Curiously, setting "DRI" and "DRI2" to "False" and "NoAccel" to "True" do not seem
to disable direct rendering: glxinfo still says; "direct rendering: Yes". What else
do I need to turn off to make X usable again?

Here are the values of the relevant parts on /proc/meminfo right after logging off X
but not yet shutting down kdm (i.e. X is still running) and immediately after 
shutting down kdm (and therefore X, too):

Before:
MemFree:          390412 kB
Buffers:               0 kB
Cached:           442828 kB
SwapCached:        52508 kB
Active:           182880 kB
Inactive:         405552 kB
Active(anon):      88712 kB
Inactive(anon):   110184 kB
Active(file):      94168 kB
Inactive(file):   295368 kB
AnonPages:        101876 kB
Mapped:            30536 kB
Slab:             976616 kB
SReclaimable:      23784 kB
SUnreclaim:       952832 kB

After:
MemFree:         1460024 kB
Buffers:               0 kB
Cached:           395244 kB
SwapCached:        41652 kB
Active:           106172 kB
Inactive:         344176 kB
Active(anon):      11348 kB
Inactive(anon):    49228 kB
Active(file):      94824 kB
Inactive(file):   294948 kB
AnonPages:         21496 kB
Mapped:            11620 kB
Slab:              47056 kB
SReclaimable:      23716 kB
SUnreclaim:        23340 kB


The culprit is kmalloc-32 according to slabinfo. Unfortunately I forgot to
save its output. Its size was about 940MB anyway.

I will be happy to provide more info as soon as the slab grows again in a few days. :/

-Juha

P.S. I realise my xserver-xorg-video-intel is from experimental, but the older versions
have been even less usable: mostly crashing or completely freezing at random (see 
#575965 for example).


-- System Information:
Debian Release: squeeze/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.34 (SMP w/2 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=UTF-8) (ignored: LC_ALL set to en_GB.UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages xorg depends on:
ii  konsole [x-terminal-emulator] 4:4.4.3-1  X terminal emulator for KDE 4
ii  libgl1-mesa-dri               7.7.1-2    A free implementation of the OpenG
ii  libgl1-mesa-glx [libgl1]      7.7.1-2    A free implementation of the OpenG
ii  libglu1-mesa                  7.7.1-2    The OpenGL utility library (GLU)
ii  lxterminal [x-terminal-emulat 0.1.7-1    desktop independent vte-based term
ii  rxvt-unicode [x-terminal-emul 9.07-2     RXVT-like terminal emulator with U
ii  x11-apps                      7.5+5      X applications
ii  x11-session-utils             7.5+1      X session utilities
ii  x11-utils                     7.5+3      X11 utilities
ii  x11-xfs-utils                 7.4+1      X font server utilities
ii  x11-xkb-utils                 7.5+2      X11 XKB utilities
ii  x11-xserver-utils             7.5+1      X server utilities
ii  xauth                         1:1.0.4-1  X authentication utility
ii  xfonts-100dpi                 1:1.0.1    100 dpi fonts for X
ii  xfonts-75dpi                  1:1.0.1    75 dpi fonts for X
ii  xfonts-base                   1:1.0.1    standard fonts for X
ii  xfonts-scalable               1:1.0.1-1  scalable fonts for X
ii  xfonts-utils                  1:7.5+2    X Window System font utility progr
ii  xinit                         1.2.0-1    X server initialisation tool
ii  xkb-data                      1.8-1      X Keyboard Extension (XKB) configu
ii  xorg-docs-core                1:1.5-1    Core documentation for the X.org X
ii  xserver-xorg                  1:7.5+6    the X.Org X server
ii  xterm [x-terminal-emulator]   258-1      X terminal emulator

xorg recommends no packages.

Versions of packages xorg suggests:
ii  xorg-docs                     1:1.5-1    Miscellaneous documentation for th

-- no debconf information

--- End Message ---
--- Begin Message --- 
reassign 585663 xserver-xorg-video-intel
fixed 585663 2:2.11.0-1
kthxbye

On Sat, Jul 31, 2010 at 19:48:57 +0100, Juha Jäykkä wrote:

> > Can you attach your X and kernel logs, and track the contents of
> > /sys/kernel/debug/dri/0/gem_objects (you can mount debugfs with 'mount
> > -t debugfs none /sys/kernel/debug)?
> 
> Sorry, I cannot: ever since 2:2.11.0-1, the problem either went away or is at 
> least a LOT less severe. I now have 41 days old X process, and the 
> unreclaimable kernel memory is 	244584 kB, where it previously rose to a 
> gigabyte in less than 14 days.
> 
OK, in that case I'll mark the bug as fixed in that version.

> The file /sys/kernel/debug/dri/0/gem_objects is 0 bytes long, how do I "track 
> its contents"?
> 
Weird...

> > Does this also happen with debian's 2.6.32 kernel?
> 
> It happens with everything Debian (including experimental) has had since 
> 2.6.31. Only the .35 kernels I have not tested (because the problem seems to 
> have gone away before they came available).
> 
Thanks for the followup.

Cheers,
Julien

Attachment: signature.asc
Description: Digital signature


--- End Message ---
Reply to: