patrick charles wrote:
Yeah, you replaced the file, but did the new module get installed? Run lsmod as root:On Thursday 13 February 2003 09:03 pm, David Dawes wrote:On Thu, Feb 13, 2003 at 02:11:40PM -0700, patrick charles wrote:On Wednesday 12 February 2003 10:20 pm, David Dawes wrote:On Tue, Feb 11, 2003 at 02:51:04PM -0700, patrick charles wrote:On Saturday 08 February 2003 05:41 pm, David Dawes wrote:On Sat, Feb 08, 2003 at 01:07:25PM -0700, patrick charles wrote:First of all, how are you "killing" the X server? I haven't seenHow would I communicate this? Somebody on XFree86 working with or have contact with the appropriate people in kernel/agpgart development?
this behaviour when the X server exits normally, and I've done a
lot of testing where 32MB is allocated per run on machines with
only 128MB of physical memory.
There are people here familiar with the kernel agpgart driver.
Note that just because top shows that there's little memory free
doesn't mean that the agpgart driver isn't freeing it. Also the
agpgart driver allocates physical pages, never swap. I'm not sure
what the symptoms are when it can't get any free physical pages. On my test system the free memory indicated by top does go up when
the X server exits, and this is on an otherwise idle system.
So, I'd suggest starting a bare X server (run just 'X') on an
otherwise idle system, see what top reports, then exit it cleanly
(<Ctrl><Alt><Backspace>), and see if the free memory amount
changes. Check the X server log to confirm how much memory was
allocated via the agpgart mechanism (look for the lines containing
"Allocated").
If that looks OK, then try the same thing you tried before but with
a bare X server and an idle system.
David
David, I ran some tests as you suggested. I started up a bare X server using the command 'X' on an idle system. I then exited cleanly using ctrl-alt-bak. I recorded the amount of physical RAM free before and after the X start. I repeated this process. After 13 iterations, the machine became very sluggish. After 16 iterations, the machine hung. Still looks like X (or, the agpgart driver?) is not freeing resources. The machine gradually ran out of physical RAM.I just tried repeating this with what I think should be an even more demanding configuration: 845G system with 128MB physical memory, 1MB stolen memory (preallocated video memory), X configured to use 32MB video memory, so just over 31MB of physical memory needs to be allocated at each server start. After several iterations, I got to a pattern where the free memory after the server starts is 2MB, and the free memory when it exits is 41MB. I went as far as 25 iterations without any change in this pattern and without any slowdown. This is with RH 7.3, using the default kernel plus an agpgart driver patched for correct 845G support. The 2.4.20 kernel should already have the correct 845G agpgart support. The source for the agpgart driver I'm using can be found at <http://www.xfree86.org/~dawes/intel-85x/agpgart-85x.tar.gz>, in case that makes a difference. DavidOk. To simplify my environment, I did a fresh install of Red Hat 8.0. I then installed kernel 2.4.20-2.21 and XFree86-4.2.99.3-20030115, taken as RPM's from the RH81 'phoebe' beta, required for the i845 support. So, I now have a 'clean' setup which doesn't contain any of the pieces which I previously downloaded/built from various cvs repositories. On this machine (which has quite a few services running since it is a default 8.0 workstation-type install), it only takes 6 restart iterations of X before the system hangs. I (unfortunately) have 4 of these brand new GX60 machines. I see the exact same behavior on all of them. Therefore, I don't think the problem is specific to a particular system. By using the RH RPM's, also doesn't appear that the problem stems from something peculiar in my build environment. You tried on an i845G and can't reproduce, but you are using RH7.3?Yep, RH7.3 with its default kernel plus the agpgart driver referenced above. Could you try your setup using that agpgart driver? That might help narrow down if the problem lies there or elsewhere. I don't see how the problem could be anywhere other than the kernel or agpgart driver. Davidi replaced agpgart.o with one recompiled from agpgart-85x.tar.gz % uname -a Linux localhost.localdomain 2.4.20-2.21 #1 Wed Jan 15 20:31:35 EST 2003 i686 i686 i386 GNU/Linux % ls -l /lib/modules/2.4.20-2.21/kernel/drivers/char/agp -rw-r--r-- 1 root root 64920 Feb 14 12:21 agpgart.o -rw-r--r-- 1 root root 23738 Jan 15 18:38 agpgart.o.gz.bak I am still seeing the same behavior.
lsmod | grep agpgart
Send in the results of that.
Handling the easy stuff, :)
Harold
thanks, -pat _______________________________________________ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
_______________________________________________ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel