Description of problem:
I have a Dell OptiPlex GX260 with i845G chipset graphics on the motherboard.
When I run and exit Xserver, using xinit, several times in a raw, I get less
free memory until the system freezes cold. Then I need to perform a cold reset
to make it work again.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. try it on i845G
2. run xinit
4. repeat above two steps several times
5. watch for free memory (e.g. using free)
After the free memory drops below certain amount the system will slow down and
Obviously it shouldn't leak memory.
I didn't try recent glibc or another graphics card yet.
Very unlikely. Video drivers don't allocate memory, then continuously
allocate more over time. More likely this is an application you are using
leaking X resources, pixmaps, etc. X resources are stored in the X server,
so an app leaking resources increases the X server size.
Likely candidates are Mozilla, Nautilus, and other common desktop applications,
although you'd have to investigate it yourself to find out which app is doing
it for you.
Without a way to reproduce this 100%, unfortunately I'd be unable to
troubleshoot the problem either way. Can you narrow the problem down?
No Mozilla, no Nautilus, no nothing. I just booted the system and ran xinit
several times. I should add that I boot kernel with vga=4 and the video mode
isn't restored correctly by XFree86. Following is the output of ps -e, lsmod and
free just before the system freezed, sorry for the long list:
PID TTY TIME CMD
1 ? 00:00:03 init
2 ? 00:00:00 keventd
3 ? 00:00:00 kapmd
4 ? 00:00:00 ksoftirqd_CPU0
7 ? 00:00:00 bdflush
5 ? 00:00:00 kswapd
6 ? 00:00:00 kscand
8 ? 00:00:00 kupdated
9 ? 00:00:00 mdrecoveryd
13 ? 00:00:00 kjournald
69 ? 00:00:00 khubd
533 ? 00:00:00 syslogd
537 ? 00:00:00 klogd
638 ? 00:00:00 xfs
645 ? 00:00:00 login
646 tty2 00:00:00 mingetty
647 tty3 00:00:00 mingetty
648 tty4 00:00:00 mingetty
649 tty5 00:00:00 mingetty
650 tty6 00:00:00 mingetty
653 tty1 00:00:00 bash
726 tty1 00:00:00 xinit
727 ? 00:00:00 X
736 tty1 00:00:00 xterm
738 pts/0 00:00:00 bash
764 pts/0 00:00:00 ps
Module Size Used by Not tainted
i830 74208 1
agpgart 46880 11 (autoclean)
e1000 50636 1
iptable_filter 2412 0 (autoclean) (unused)
ip_tables 14872 1 [iptable_filter]
keybdev 2976 0 (unused)
mousedev 5492 1
hid 22212 0 (unused)
input 5856 0 [keybdev mousedev hid]
usb-uhci 26412 0 (unused)
ehci-hcd 19816 0 (unused)
usbcore 78752 1 [hid usb-uhci ehci-hcd]
ext3 88200 1
jbd 51924 1 [ext3]
total used free shared buffers cached
Mem: 253644 231612 22032 0 320 4668
-/+ buffers/cache: 226624 27020
Swap: 0 0 0
Here's what I found:
1. It doesn't happen with kernel 2.4.18-19.8.0
2. With kernel 2.4.20-2.25 it happen even with XFree86-4.2.0-72
3. The problem is still present in kernel-2.4.20-2.27
4. When I set video memory size to 8MB in BIOS settings or when I'm using vesa
driver the leak is very small
5. When I set video memory size to 1MB in BIOS or when I try it on a computer
with i815E chipset where there is no such BIOS option, the leak is about 7MB
each time I run and exit X server with xinit
So, the question is: should it be moved to the kernel component?
Ugh... I also found out that if module dri is loaded (through XF86Config), then
the leak happens no matter what I do. If it's commented out, then everything
works as described above.
can you attach dmesg output from AFTER this has happened ?
Created attachment 89733 [details]
dmesg output BEFORE xinit with 1MB of video memory
Created attachment 89734 [details]
dmesg output AFTER xinit with 1MB of video memory
Created attachment 89735 [details]
dmesg output BEFORE xinit with 8MB of video memory
Created attachment 89736 [details]
dmesg output AFTER xinit with 8MB of video memory
This doesn't look like a memory leak at all. It looks to me like your
BIOS is either hard coded, or otherwise configured to provide a large
AGP aperture by default, and X is simply reading the size of the aperture
from the BIOS and using it.
Some laptops don't have the ability to control the AGP aperture in their
broken BIOSs, and so by defualt the BIOS hardcoded aperture size is used.
The only solution for this is to reconfigure the aperture size in your
XF86Config file in order to override the braindead hardcoded BIOS setting.
This can be done with the AGPsize option in the config file.
Does this make the problem go away?
Created attachment 89737 [details]
dmesg output AFTER second xinit with 1MB of video memory
Created attachment 89738 [details]
dmesg output AFTER second xinit with 8MB of video memory
I set Option "AGPsize" "1024" in section "Device" and there is a line in
XFree86.log: "Option AGPsize is not used".
1024 == 1Megabyte, which is invalid size for AGP aperture. Please note
that bugzilla is not a technical support forum. If you need assistance
configuring any of the suggestions offered here, please try an XFree86
related mailing list such as email@example.com or dri-devel
I'm not able to spend time providing technical support, sorry.
Please attach the X server config file and x server log from
Ok. Now with:
Created attachment 89859 [details]
Created attachment 89860 [details]
Log with BIOS set up for 1MB of video memory
Created attachment 89861 [details]
Log with BIOS set up for 8MB of video memory
Seems that bug #85106 was a duplicate of this one. I no longer can reproduce the
memory leak with the latest rawhide kernel, so I think it can be closed now.
*** This bug has been marked as a duplicate of 85106 ***
Changed to 'CLOSED' state since 'RESOLVED' has been deprecated.