Bug 82896 - Severe memory leak in kernel DRM?
Severe memory leak in kernel DRM?
Status: CLOSED DUPLICATE of bug 85106
Product: Red Hat Raw Hide
Classification: Retired
Component: XFree86 (Show other bugs)
1.0
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Mike A. Harris
David Lawrence
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2003-01-28 03:02 EST by vvs
Modified: 2007-04-18 12:50 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-02-21 13:51:27 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
dmesg output BEFORE xinit with 1MB of video memory (7.01 KB, text/plain)
2003-01-31 09:29 EST, vvs
no flags Details
dmesg output AFTER xinit with 1MB of video memory (7.30 KB, text/plain)
2003-01-31 09:30 EST, vvs
no flags Details
dmesg output BEFORE xinit with 8MB of video memory (7.01 KB, text/plain)
2003-01-31 09:31 EST, vvs
no flags Details
dmesg output AFTER xinit with 8MB of video memory (7.28 KB, text/plain)
2003-01-31 09:32 EST, vvs
no flags Details
dmesg output AFTER second xinit with 1MB of video memory (7.37 KB, text/plain)
2003-01-31 09:42 EST, vvs
no flags Details
dmesg output AFTER second xinit with 8MB of video memory (7.34 KB, text/plain)
2003-01-31 09:43 EST, vvs
no flags Details
Configuration file (3.06 KB, text/plain)
2003-02-05 07:13 EST, vvs
no flags Details
Log with BIOS set up for 1MB of video memory (52.13 KB, text/plain)
2003-02-05 07:14 EST, vvs
no flags Details
Log with BIOS set up for 8MB of video memory (52.01 KB, text/plain)
2003-02-05 07:15 EST, vvs
no flags Details

  None (edit)
Description vvs 2003-01-28 03:02:30 EST
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.
Comment 1 Mike A. Harris 2003-01-28 04:15:29 EST
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?
Comment 2 vvs 2003-01-28 06:31:21 EST
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
Comment 3 vvs 2003-01-30 04:15:26 EST
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?
Comment 4 vvs 2003-01-30 06:40:43 EST
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.
Comment 5 Arjan van de Ven 2003-01-31 07:48:05 EST
can you attach dmesg output from AFTER this has happened ?
Comment 6 vvs 2003-01-31 09:29:59 EST
Created attachment 89733 [details]
dmesg output BEFORE xinit with 1MB of video memory
Comment 7 vvs 2003-01-31 09:30:55 EST
Created attachment 89734 [details]
dmesg output AFTER xinit with 1MB of video memory
Comment 8 vvs 2003-01-31 09:31:39 EST
Created attachment 89735 [details]
dmesg output BEFORE xinit with 8MB of video memory
Comment 9 vvs 2003-01-31 09:32:40 EST
Created attachment 89736 [details]
dmesg output AFTER xinit with 8MB of video memory
Comment 10 Mike A. Harris 2003-01-31 09:38:27 EST
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?
Comment 11 vvs 2003-01-31 09:42:16 EST
Created attachment 89737 [details]
dmesg output AFTER second xinit with 1MB of video memory
Comment 12 vvs 2003-01-31 09:43:20 EST
Created attachment 89738 [details]
dmesg output AFTER second xinit with 8MB of video memory
Comment 13 vvs 2003-01-31 10:00:14 EST
I set Option "AGPsize" "1024" in section "Device" and there is a line in
XFree86.log: "Option AGPsize is not used".
Comment 14 Mike A. Harris 2003-02-01 01:04:15 EST
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@xfree86.org or dri-devel

I'm not able to spend time providing technical support, sorry.
Comment 15 Mike A. Harris 2003-02-05 01:50:06 EST
Please attach the X server config file and x server log from
an attempt.
Comment 16 vvs 2003-02-05 07:12:48 EST
Ok. Now with:

kernel-2.4.20-2.33
XFree86-4.2.99.4-20030129.5
glibc-2.3.1-40
Comment 17 vvs 2003-02-05 07:13:44 EST
Created attachment 89859 [details]
Configuration file
Comment 18 vvs 2003-02-05 07:14:48 EST
Created attachment 89860 [details]
Log with BIOS set up for 1MB of video memory
Comment 19 vvs 2003-02-05 07:15:20 EST
Created attachment 89861 [details]
Log with BIOS set up for 8MB of video memory
Comment 20 vvs 2003-04-01 00:16:45 EST
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 ***
Comment 21 Red Hat Bugzilla 2006-02-21 13:51:27 EST
Changed to 'CLOSED' state since 'RESOLVED' has been deprecated.

Note You need to log in before you can comment on or make changes to this bug.