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): XFree86-4.2.99.4-20030121.0 kernel-2.4.20-2.25 glibc-2.2.93-5 How reproducible: Seems always. Steps to Reproduce: 1. try it on i845G 2. run xinit 3. exit 4. repeat above two steps several times 5. watch for free memory (e.g. using free) Actual results: After the free memory drops below certain amount the system will slow down and eventually freeze. Expected results: Obviously it shouldn't leak memory. Additional info: 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 xfree86 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 an attempt.
Ok. Now with: kernel-2.4.20-2.33 XFree86-4.2.99.4-20030129.5 glibc-2.3.1-40
Created attachment 89859 [details] Configuration file
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.