I sent this here because i don't know which author screwed up.
Basically, it's a massive kernel memory leak or a VM problem.
System specs:
1 GBytes RAM
duel CPU system; 1 Ghz each.
IDE disk system, 133 Mhz bus speed, DMA.
USB mouse.
PS/2 Keyboard.
Creative Labs emu10k1-based sound card. (LIVE!)
Asus Motherboard.
Problem:
When I boot the system, run X11 with KDE--totalling 100 M at most--things
are fine.
When I run applications that use quite a bit of memory -- those that use 500
Megs of RAM -- Linux keeps on allocating memory until it's full. When full,
system acts dead, as expected from the bad VM design. But why does the
system allocate memory until the RAM is full? User applications are NOT
leaking memory.
Example: Installing Unreal Tournament 2003 -- from the CD drive, IDE -- for
example, playing mp3 files and browsing the web with Mozilla, and the system
will eventually allocate memory until the system freezes. All of RAM is
allocated, and the system is frozen.
Possible problem: VM algorithm is not too good, and should take a lesson to
BSD; or the kernel is leaking memory -- unknown location. I'll look into
the problem in a few weeks when i'm free; but now, i got work.
I'm sure many people are getting this problem...
I can fix the problem, but i got engineering projects to worry about.
Matt.
_________________________________________________________________
The new MSN 8: smart spam protection and 2 months FREE*
http://join.msn.com/?page=features/junkmail
At 06:49 AM 3/12/2003 +0000, M. Soltysiak wrote:
>I sent this here because i don't know which author screwed up.
I note that diplomacy isn't your strong suite.
>System specs:
>1 GBytes RAM
>duel CPU system; 1 Ghz each.
>IDE disk system, 133 Mhz bus speed, DMA.
>USB mouse.
>PS/2 Keyboard.
>Creative Labs emu10k1-based sound card. (LIVE!)
>Asus Motherboard.
Which kernel version, and how much swap (0?).
>Problem:
>
>When I boot the system, run X11 with KDE--totalling 100 M at most--things
>are fine.
>
>When I run applications that use quite a bit of memory -- those that use
>500 Megs of RAM -- Linux keeps on allocating memory until it's full. When
>full, system acts dead, as expected from the bad VM design. But why does
>the system allocate memory until the RAM is full? User applications are
>NOT leaking memory.
What are you basing these assertions upon?
>Example: Installing Unreal Tournament 2003 -- from the CD drive, IDE --
>for example, playing mp3 files and browsing the web with Mozilla, and the
>system will eventually allocate memory until the system freezes. All of
>RAM is allocated, and the system is frozen.
Please post a detailed report including kernel version, process sizes and
/proc/slabinfo just prior to live-lock. This report is useless. (not to
mention arrogant)
-Mike
Good day, Matt,
On Wed, 12 Mar 2003, M. Soltysiak wrote:
> I sent this here because i don't know which author screwed up.
Please don't start the post with a negative tone; focus on a
problem in software rather than on insulting the people from whom you want
help.
Please take a look at /usr/src/linux/REPORTING-BUGS. At an
absolute minimum, the people on this list can't do anything at all until
you tell us what kernel version you're using, what modules are loaded,
etc. - all things that that file is designed to uncover. You might also
want to mention what Linux distribution you're using. Did you compile the
kernel yourself, or are you using a vendor-supplied kernel? If it's from
your vendor, have you updated it to the most current for your
distribution? If you compiled it yourself, what compile options did you
use? Did you apply any patches to the source?
> Basically, it's a massive kernel memory leak or a VM problem.
>
> System specs:
> 1 GBytes RAM
> duel CPU system; 1 Ghz each.
> IDE disk system, 133 Mhz bus speed, DMA.
> USB mouse.
> PS/2 Keyboard.
> Creative Labs emu10k1-based sound card. (LIVE!)
> Asus Motherboard.
Does the system pass a night's worth of memtest86 successfully?
If we can rule out hardware, that narrows the problem space down some.
> Problem:
>
> When I boot the system, run X11 with KDE--totalling 100 M at most--things
> are fine.
>
> When I run applications that use quite a bit of memory -- those that use 500
> Megs of RAM -- Linux keeps on allocating memory until it's full. When full,
> system acts dead, as expected from the bad VM design. But why does the
Again, it sounds like you're taking an insulting tone. :-)
> system allocate memory until the RAM is full? User applications are NOT
> leaking memory.
"Acts dead" - what does that mean? Sluggish? Pauses for a few
seconds, then returns to normal? Swapping madly? For how long? Hard
lockup, no keys do anything? Does the caps lock key change the state of
the caps lock led? Do the caps/scroll/numlock lights flash on and off
without keypresses? Does anything show up in the logs on next boot? Can
you kill X11 with Ctrl-Alt-Backspace? Can you reboot the box with
Ctrl-Alt-Del? Does Sysrq-S force disk activity? Can you ssh in from
another box when it "acts dead"?
> Example: Installing Unreal Tournament 2003 -- from the CD drive, IDE -- for
> example, playing mp3 files and browsing the web with Mozilla, and the system
> will eventually allocate memory until the system freezes. All of RAM is
> allocated, and the system is frozen.
What are the last few lines from "vmstat 1" when the system
freezes? Does top show any memory amounts=0? What does top claim is the
biggest memory user, both in the header area and down in application
space?
Can you make the problem occur with fewer programs, say, just with
Mozilla, or just with Unreal? How long does it take for the problem to
show up? Minutes, hours, days?
> Possible problem: VM algorithm is not too good, and should take a lesson to
> BSD; or the kernel is leaking memory -- unknown location. I'll look into
> the problem in a few weeks when i'm free; but now, i got work.
>
> I'm sure many people are getting this problem...
As I mentioned above... ;-)
> I can fix the problem, but i got engineering projects to worry about.
If you'd prefer, feel free. You do remember that the people from
whom you're asking help have day jobs too, right? *grin*
http://www.stearns.org/doc/howtoask.current.html
Cheers,
- Bill
---------------------------------------------------------------------------
"A raccoon tangled with a 23,000 volt line today. The results
blacked out 1400 homes and, of course, one raccoon."
-- Steel City News
(Courtesy of G.W. Wettstein <[email protected]>)
--------------------------------------------------------------------------
William Stearns ([email protected]). Mason, Buildkernel, freedups, p0f,
rsync-backup, ssh-keyinstall, dns-check, more at: http://www.stearns.org
Linux articles at: http://www.opensourcedigest.com
--------------------------------------------------------------------------
Err for starters you should include kernel version and OS versions etc.
Also how do you expect any computer to work once it has run out of
memory? Do you have swap partition? I suspect not, or a small one in
any case!
Some of the applications you mention are notorios for memory leaks
themselves. ie UT!
Cheers
Dave
----- Original Message -----
From: "M. Soltysiak" <[email protected]>
To: <[email protected]>
Sent: Wednesday, March 12, 2003 2:49 PM
Subject: Linux BUG: Memory Leak
> I sent this here because i don't know which author screwed up.
>
> Basically, it's a massive kernel memory leak or a VM problem.
>
> System specs:
> 1 GBytes RAM
> duel CPU system; 1 Ghz each.
> IDE disk system, 133 Mhz bus speed, DMA.
> USB mouse.
> PS/2 Keyboard.
> Creative Labs emu10k1-based sound card. (LIVE!)
> Asus Motherboard.
>
> Problem:
>
> When I boot the system, run X11 with KDE--totalling 100 M at most--things
> are fine.
>
> When I run applications that use quite a bit of memory -- those that use
500
> Megs of RAM -- Linux keeps on allocating memory until it's full. When
full,
> system acts dead, as expected from the bad VM design. But why does the
> system allocate memory until the RAM is full? User applications are NOT
> leaking memory.
>
> Example: Installing Unreal Tournament 2003 -- from the CD drive, IDE --
for
> example, playing mp3 files and browsing the web with Mozilla, and the
system
> will eventually allocate memory until the system freezes. All of RAM is
> allocated, and the system is frozen.
>
> Possible problem: VM algorithm is not too good, and should take a lesson
to
> BSD; or the kernel is leaking memory -- unknown location. I'll look into
> the problem in a few weeks when i'm free; but now, i got work.
>
> I'm sure many people are getting this problem...
>
> I can fix the problem, but i got engineering projects to worry about.
>
> Matt.
>
>
>
>
> _________________________________________________________________
> The new MSN 8: smart spam protection and 2 months FREE*
> http://join.msn.com/?page=features/junkmail
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
Hi,
i just gotta denote that This M. Soltysiak <[email protected]>
is not me, though my name is the same :)
I would not like to be mixed up with someone else :)
Regards,
Maciej Soltysiak
<[email protected]>
For starters, read (and apply!) everyone else's comments re politeness,
proper information to include, etc.
But to add some info in a "Me too":
System has 1G lowmem (the AA vm patches) and showed almost the same
symptoms last night after 1wk of uptime. Its now been up for about 14
hours with several large processes, agp, etc all going and is - yet
again - running out of memory. (After booting and logging in, 130 megs
was used.. and that was it.)
Kernel: 2.4.20 + patches (see list below)
Memory: PC133 @ 133 - 1024M lowmem, 0M highmem, 2048M swap
Disk: AIC7xxx + LVM1 (raid0)
CPU: Tbird 1.2G non-overclocked
Added modules: lm-sensors, alsa, gatos radeon hardware-gl for X 4.2.0 (X
ver 4.2.1)
Config: Attached
I showed up last night to find it was 900 megs into swap and (relatively
slowly) climbing, but nothing in ps showed a particularly large memory
usage (largest was X, which was - AFAIU - likely to be a mix of "X
leaks" and agp/vidram buffers.. and it was 200M total). Killed off X
and the other largish apps (apache at 30M, etc..) such that ps showed
well under 300 megs of total VM accounted for. But free still showed
950 megs of ram and 100 megs of swap in use. /proc/meminfo showed some
of it (300 megs or so) as buffers, only 16M in cache.
Its been rebooted to the same workload and the same kernel, and happened
again. That info is attached below.
Basically the patches come from the debian kernel-patch-ck package:
O(1) and batch scheduler (ck)
Author: Ingo Molnar
URL: http://people.redhat.com/mingo/O(1)-scheduler/
Fix for a locking bug in wait_on_page, wait_on_buffer, get_request_wait
(ck)
See the URL below for information on what this patch fixes.
Author: Andrea Arcangeli
URL: http://marc.theaimsgroup.com/?l=linux-kernel&m=103707362523414&w=2
Preemptible kernel (ck)
This patch must be enabled via the kernel configuration.
Author: Robert M. Love
URL: http://www.tech9.net/rml/linux/
Low-latency (ck)
This patch must be enabled via the kernel configuration. The "control
low latency with sysctl" configuration option is not needed and will
only disable low latency unless you manually enable it after bootup
(using "echo 1 > /proc/sys/kernel/lowlatency").
Author: Andrew Morton
URL: http://www.zip.com.au/~akpm/linux/schedlat.html
Andrea Arcangeli's VM patches (aa)
Recommended by Con Kolivas for SMP machines.
Author: Andrea Arcangeli
URL: http://www.kernel.org/pub/linux/kernel/people/andrea/
Desktop tuning (tune)
Minor changes to magic numbers benchmarked to improve desktop
responsiveness, and lower disk latency more at the expense of a small
amount of disk throughput.
This patch depends on the (aa) patch, and cannot be used with the (rmap)
patch.
1000Hz timer with autoregulated timeslice duration (vartimeslice)
This patch will adjust the time a process can run for according to the
stress the system is under. If there are many running processes or any
writing to disk the timeslice duration will be decreased. It is
decreased proportionately less in SMP machines. You can see the current
value for timeslice_multiplier by doing 'cat /proc/stat'.
Vairable HZ (varhz)
This patch allows you to configure the frequency the system timer
interrupt pops. Higher tick values provide improved granularity of
timers, improved select() and poll() performance, and lower scheduling
latency. Higher values, however, increase interrupt overhead and will
allow jiffie wraparound sooner.
The default value, which was the value for all of eternity, is 100. If
you are looking to provide better timer granularity or increased desktop
performance, try 500 or 1000. If unsure, go with the default of 100.
Disk read latency update (read_latency)
See the URL below for more information.
URL: http://marc.theaimsgroup.com/?l=linux-kernel&m=101355715821610&w=2
Evidently there is a website about this patcheset:
http://kernel.kolivas.net/
On Wed, 2003-03-12 at 01:49, M. Soltysiak wrote:
> I sent this here because i don't know which author screwed up.
>
> Basically, it's a massive kernel memory leak or a VM problem.
>
> System specs:
> 1 GBytes RAM
> duel CPU system; 1 Ghz each.
> IDE disk system, 133 Mhz bus speed, DMA.
> USB mouse.
> PS/2 Keyboard.
> Creative Labs emu10k1-based sound card. (LIVE!)
> Asus Motherboard.
>
> Problem:
>
> When I boot the system, run X11 with KDE--totalling 100 M at most--things
> are fine.
--
Disconnect <[email protected]>
On Wed, 2003-03-12 at 07:19, David Shirley wrote:
> Err for starters you should include kernel version and OS versions etc.
>
> Also how do you expect any computer to work once it has run out of
> memory? Do you have swap partition? I suspect not, or a small one in
> any case!
>
> Some of the applications you mention are notorios for memory leaks
> themselves. ie UT!
iirc UT will only run with openGL under X last time i looked about 3
months ago the only card that was fully supporting this was the nvidia
Geforce series with closed source drivers.
Tainted kernel :/
James
----- Original Message -----
From: James Stevenson <[email protected]>
Date: 12 Mar 2003 18:38:57 +0000
To: David Shirley <[email protected]>
Subject: Re: Linux BUG: Memory Leak
> On Wed, 2003-03-12 at 07:19, David Shirley wrote:
> iirc UT will only run with openGL under X last time i looked about 3
> months ago the only card that was fully supporting this was the nvidia
> Geforce series with closed source drivers.
>
> Tainted kernel :/
Besides tainted kernel, nVidia drivers are pretty good :-)
There are more GL-enabled cards standard with XFree86, like
Radeons and family. I have also had some success with Mach64
based video cards (although FPS rate is somewhat low).
Best regards,
Felipe
--
______________________________________________
http://www.linuxmail.org/
Now with e-mail forwarding for only US$5.95/yr
Powered by Outblaze
On Wed, Mar 12, 2003 at 06:38:57PM +0000, James Stevenson wrote:
> On Wed, 2003-03-12 at 07:19, David Shirley wrote:
> > Err for starters you should include kernel version and OS versions etc.
> >
> > Also how do you expect any computer to work once it has run out of
> > memory? Do you have swap partition? I suspect not, or a small one in
> > any case!
> >
> > Some of the applications you mention are notorios for memory leaks
> > themselves. ie UT!
>
> iirc UT will only run with openGL under X last time i looked about 3
> months ago the only card that was fully supporting this was the nvidia
> Geforce series with closed source drivers.
>
> Tainted kernel :/
Reportedly, the latest releastes of UT2k3 no longer require S3TC to run,
and will thus work with some open source drivers.
-J
> > On Wed, 2003-03-12 at 07:19, David Shirley wrote:
> > iirc UT will only run with openGL under X last time i looked about 3
> > months ago the only card that was fully supporting this was the nvidia
> > Geforce series with closed source drivers.
> >
> > Tainted kernel :/
>
> Besides tainted kernel, nVidia drivers are pretty good :-)
> There are more GL-enabled cards standard with XFree86, like
> Radeons and family. I have also had some success with Mach64
> based video cards (although FPS rate is somewhat low).
nvidia drivers
cat /dev/nvidia
causes a kernel opps
----- Original Message -----
From: James Stevenson <[email protected]>
Date: 12 Mar 2003 20:58:11 +0000
To: Felipe Alfaro Solana <[email protected]>
Subject: Re: Linux BUG: Memory Leak
> > > On Wed, 2003-03-12 at 07:19, David Shirley wrote:
> > Besides tainted kernel, nVidia drivers are pretty good :-)
> > There are more GL-enabled cards standard with XFree86, like
> > Radeons and family. I have also had some success with Mach64
> > based video cards (although FPS rate is somewhat low).
>
> nvidia drivers
>
> cat /dev/nvidia
> causes a kernel opps
Hmm... Last time I tried was with 2.4.20. Will have to give it
a shot with 2.5.64.
Thanks!
Felipe
--
______________________________________________
http://www.linuxmail.org/
Now with e-mail forwarding for only US$5.95/yr
Powered by Outblaze
(Response sent to me, bounced back to the list where brighter
minds may be able to offer useful suggestions)
> Please don't start the post with a negative tone; focus on a
problem in software rather than > on insulting the people from whom you
want.
Sorry.? And, no, I'm not insulting people.? But I do encourage good
programming practices.? Don't you? :)
>you tell us what kernel version you're using, what modules are
loaded,
Sorry.? I forgot--2.4.20.? Modules: ne2000 network driver, pci; via-rhine,
pci; emu10k1, pci; usbcore, uhci, usb mouse; all iptables modules--all of
them.
>want to mention what Linux distribution you're using.
Sorry.? Slackware 8.1.??Won't help.
>kernel yourself.
I compiled the kernel myself.? Memory leak located in kernel.
> Does the system pass a night's worth of memtest86 successfully?
Kernel memory leak.
>If we can rule out hardware, that narrows the problem space down
some.
cards: emu10k1, via-rhine, pci; ne2000, pci; usb standard, intel.? Via
chipset, unknown - on another computer right now.? but that's *not* the
problem.
> Again, it sounds like you're taking an insulting tone. :-)
I am sorry.? I'm usually direct.? I will try to look for the bug this
weekend, but i have a few things to do.? Sigh.
> "Acts dead" - what does that mean? Sluggish?
Dead.? It's a DOSS over the system.? All I did was install this game,
hoping to play it, after a few weaks.? Anyway, the systems installs,
X11-KDE running (140 Megs total by X11 and KDE); Linux installs it, then
it gets slower and slower, etc.? Finally dead.? Even the interrupts
die--only keyboards, usb mouse; but the network still works (slowly)).
>seconds, then returns to normal? Swapping madly? For how long?
Swap space will become full.? Then the duel-1Ghz with 1 MByte system will
die - hardware -- except network - interrupts die.
>lockup, no keys do anything? Does the caps lock key change the
state of the caps lock led? Do the caps/scroll/numlock lights flash on and
off without keypresses? Does anything show up in the logs on next boot?
Can you kill X11 with Ctrl-Alt-Backspace? Can you reboot the box with
Ctrl-Alt-Del? Does Sysrq-S force disk activity? Can you ssh in from
>another box when it "acts dead"?
Interrupts are dead on the keyboard and mouse, except for the harddisk and
network.
> What are the last few lines from "vmstat 1" when the system
freezes?
Ah, i did not use that.? not on my box now.? sorry.? but the ram is 0
free, system is working, but interrupts are crippled.
> Can you make the problem occur with fewer programs, say, just
with Mozilla, or just with > Unreal?
Yes.? Xine - movie player.? I watch a few movies (not completely) and
Linux keeps using memory until it acts dead.? In other words, I watch Lord
of the Rings: Two Towers.? Then the system will play the movie slower,
slower, until the frames' speed record becomes about 5 to 10 fps.? Then i
will just stand still - frozen - and?some hardware interrupts (keyboard,
usb-mouse) will not respond.
?>show up? Minutes, hours, days?
This occurs in about 2 hours or less.? Not time-dependent, sort of like
Stationary states in quantum mechanics.
> If you'd prefer, feel free.
I will try.? Fibre optics and school do take time.
>You do remember that the people from whom you're asking help
have day jobs too, right? >*grin*
Yea.? Why are you working on Linux again?
Don't get offended to anything. I respect those who write for Linux.? But
I do believe, that If one will write open source software as major as
linux, one should not write software if they're not serious -- that is,
good at?relative, but-free programming -- toward it.? Just a thought.
M.C.S
________________________________________________________________________
Help STOP SPAM with the new MSN 8 and get 2 months FREE*
With all due respect to all the great programmers and
minds in this mailing list. I could not read this and
not reply to this guy:
Maybe you should take your games and movies to windows
and leave linux for more serious stuff. That'll fix
your memory leak.
--- William Stearns <[email protected]> wrote:
> (Response sent to me, bounced back to the list
> where brighter
> minds may be able to offer useful suggestions)
>
>
> > Please don't start the post with a negative tone;
> focus on a
> problem in software rather than > on insulting the
> people from whom you
> want.
>
> Sorry.? And, no, I'm not insulting people.? But I do
> encourage good
> programming practices.? Don't you? :)
>
> >you tell us what kernel version you're using, what
> modules are
> loaded,
>
> Sorry.? I forgot--2.4.20.? Modules: ne2000 network
> driver, pci; via-rhine,
> pci; emu10k1, pci; usbcore, uhci, usb mouse; all
> iptables modules--all of
> them.
>
> >want to mention what Linux distribution you're
> using.
>
> Sorry.? Slackware 8.1.??Won't help.
>
> >kernel yourself.
>
> I compiled the kernel myself.? Memory leak located
> in kernel.
>
> > Does the system pass a night's worth of memtest86
> successfully?
>
> Kernel memory leak.
>
> >If we can rule out hardware, that narrows the
> problem space down
> some.
>
> cards: emu10k1, via-rhine, pci; ne2000, pci; usb
> standard, intel.? Via
> chipset, unknown - on another computer right now.?
> but that's *not* the
> problem.
>
> > Again, it sounds like you're taking an insulting
> tone. :-)
>
> I am sorry.? I'm usually direct.? I will try to look
> for the bug this
> weekend, but i have a few things to do.? Sigh.
>
> > "Acts dead" - what does that mean? Sluggish?
>
> Dead.? It's a DOSS over the system.? All I did was
> install this game,
> hoping to play it, after a few weaks.? Anyway, the
> systems installs,
> X11-KDE running (140 Megs total by X11 and KDE);
> Linux installs it, then
> it gets slower and slower, etc.? Finally dead.? Even
> the interrupts
> die--only keyboards, usb mouse; but the network
> still works (slowly)).
>
> >seconds, then returns to normal? Swapping madly?
> For how long?
>
> Swap space will become full.? Then the duel-1Ghz
> with 1 MByte system will
> die - hardware -- except network - interrupts die.
>
> >lockup, no keys do anything? Does the caps lock key
> change the
> state of the caps lock led? Do the
> caps/scroll/numlock lights flash on and
> off without keypresses? Does anything show up in the
> logs on next boot?
> Can you kill X11 with Ctrl-Alt-Backspace? Can you
> reboot the box with
> Ctrl-Alt-Del? Does Sysrq-S force disk activity? Can
> you ssh in from
>
> >another box when it "acts dead"?
>
> Interrupts are dead on the keyboard and mouse,
> except for the harddisk and
> network.
>
> > What are the last few lines from "vmstat 1" when
> the system
> freezes?
>
> Ah, i did not use that.? not on my box now.? sorry.?
> but the ram is 0
> free, system is working, but interrupts are
> crippled.
>
> > Can you make the problem occur with fewer
> programs, say, just
> with Mozilla, or just with > Unreal?
>
> Yes.? Xine - movie player.? I watch a few movies
> (not completely) and
> Linux keeps using memory until it acts dead.? In
> other words, I watch Lord
> of the Rings: Two Towers.? Then the system will play
> the movie slower,
> slower, until the frames' speed record becomes about
> 5 to 10 fps.? Then i
> will just stand still - frozen - and?some hardware
> interrupts (keyboard,
> usb-mouse) will not respond.
>
> ?>show up? Minutes, hours, days?
>
> This occurs in about 2 hours or less.? Not
> time-dependent, sort of like
> Stationary states in quantum mechanics.
>
> > If you'd prefer, feel free.
>
> I will try.? Fibre optics and school do take time.
>
> >You do remember that the people from whom you're
> asking help
> have day jobs too, right? >*grin*
>
> Yea.? Why are you working on Linux again?
>
> Don't get offended to anything. I respect those who
> write for Linux.? But
> I do believe, that If one will write open source
> software as major as
> linux, one should not write software if they're not
> serious -- that is,
> good at?relative, but-free programming -- toward
> it.? Just a thought.
>
> M.C.S
>
>
>
________________________________________________________________________
> Help STOP SPAM with the new MSN 8 and get 2 months
> FREE*
>
>
> -
> To unsubscribe from this list: send the line
> "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at
> http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
__________________________________________________
Do you Yahoo!?
Yahoo! Web Hosting - establish your business online
http://webhosting.yahoo.com
> With all due respect to all the great programmers and
> minds in this mailing list. I could not read this and
> not reply to this guy:
>
> Maybe you should take your games and movies to windows
> and leave linux for more serious stuff. That'll fix
> your memory leak.
correct me if i am wrong here but i know alot of students
who use linux todo serious stuff and get really pissed off have to
reboot into windows to play games because they dont work
under windows and for various other things that also cause
problems in linux. Actually quite alot of them end up
dumping linux because any of the serious games wont work on there
system because they would have to tear much of it apart toget
them to work.
this isnt a serious problem then ?
James
> With all due respect to all the great programmers and
> minds in this mailing list. I could not read this and
> not reply to this guy:
>
> Maybe you should take your games and movies to windows
> and leave linux for more serious stuff. That'll fix
> your memory leak.
correct me if i am wrong here but i know alot of students
who use linux todo serious stuff and get really pissed off have to
reboot into windows to play games because they dont work
under windows and for various other things that also cause
problems in linux. Actually quite alot of them end up
dumping linux because any of the serious games wont work on there
system because they would have to tear much of it apart toget
them to work.
this isnt a serious problem then ?
James
> With all due respect to all the great programmers and
> minds in this mailing list. I could not read this and
> not reply to this guy:
>
> Maybe you should take your games and movies to windows
> and leave linux for more serious stuff. That'll fix
> your memory leak.
correct me if i am wrong here but i know alot of students
who use linux todo serious stuff and get really pissed off have to
reboot into windows to play games because they dont work
under windows and for various other things that also cause
problems in linux. Actually quite alot of them end up
dumping linux because any of the serious games wont work on there
system because they would have to tear much of it apart toget
them to work.
this isnt a serious problem then ?
James
On Thu, 2003-03-13 at 14:27, James Stevenson wrote:
> correct me if i am wrong here but i know alot of students
> who use linux todo serious stuff and get really pissed off have to
> reboot into windows to play games because they dont work
> under windows and for various other things that also cause
> problems in linux. Actually quite alot of them end up
> dumping linux because any of the serious games wont work on there
> system because they would have to tear much of it apart toget
> them to work.
>
> this isnt a serious problem then ?
Ignore the trolls, thank you
On Thu, 13 Mar 2003, James Stevenson wrote:
>
>
> > With all due respect to all the great programmers and
> > minds in this mailing list. I could not read this and
> > not reply to this guy:
> >
> > Maybe you should take your games and movies to windows
> > and leave linux for more serious stuff. That'll fix
> > your memory leak.
>
> correct me if i am wrong here but i know alot of students
> who use linux todo serious stuff and get really pissed off have to
> reboot into windows to play games because they dont work
> under windows and for various other things that also cause
> problems in linux. Actually quite alot of them end up
> dumping linux because any of the serious games wont work on there
> system because they would have to tear much of it apart toget
> them to work.
>
> this isnt a serious problem then ?
>
> James
>
But it's a memory leak in the game, not the kernel. They should
complain to the game makers. If a game runs the system out of
memory so a user can't log in on the root account and kill off
the game, it's a problem with the game.
--and I don't know what a 'serious game' is. Perhaps its what
the student is doing instead of studying so future engineers
develop that necessary hand-eye coordination. It's great
in design reviews, can swap hands and get a beat in between.
Cheers,
Dick Johnson
Penguin : Linux version 2.4.20 on an i686 machine (797.90 BogoMips).
Why is the government concerned about the lunatic fringe? Think about it.
On Thu, 2003-03-13 at 14:26, James Stevenson wrote:
> this isnt a serious problem then ?
There were problems with the XFree 4.3 DRM if you mixed it with
certain other ingredients like rmap. I don't know what Slackware
ships but that may be the problem.
With a base kernel + XFree 4.3 DRM port the only problems I'm now
hitting are serious breakages in the DRM code causing memory
corruption on Radeon 9x00 and the fact 4.3 broke SiS DRM support.
On Thu, Mar 13, 2003 at 09:42:39AM -0500, Richard B. Johnson wrote:
> But it's a memory leak in the game, not the kernel. They should
> complain to the game makers. If a game runs the system out of
> memory so a user can't log in on the root account and kill off
> the game, it's a problem with the game.
I would like to encourage the camp of people who believe that UNIX can
be a stable server platform to innovate ways of ensuring that if a game
(or other memory intensive program) does run the system out of memory,
an administrator could login as root and kill the game.
So I don't agree with your conclusion. I think "your system crashed? well
contact the application designer..." is a mindset that was strongly
encoduraged by companies such as Microsoft, as it allowed them to release
half baked kernels and call them stable. Thankfully, even Microsoft has
learned that this isn't the best approach, and WinXP is quite a deal more
solid than Win95.
Yes, Linux is the result of (mostly) volunteer effort contributed to the
community. No, I don't think that means it is acceptable for it to contain
security exploits, or for it to be any less robust than other operating
systems in its class such as AIX or Solaris. We have smart people. Let's
use them. Let's not be satisfied with less.
mark
--
[email protected]/[email protected]/[email protected] __________________________
. . _ ._ . . .__ . . ._. .__ . . . .__ | Neighbourhood Coder
|\/| |_| |_| |/ |_ |\/| | |_ | |/ |_ |
| | | | | \ | \ |__ . | | .|. |__ |__ | \ |__ | Ottawa, Ontario, Canada
One ring to rule them all, one ring to find them, one ring to bring them all
and in the darkness bind them...
http://mark.mielke.cc/
> [[email protected]]
>
> There were problems with the XFree 4.3 DRM if you mixed it with
> certain other ingredients like rmap. I don't know what Slackware
> ships but that may be the problem.
Slackware 8.1 shipped with XFree 4.2.0 and linux-2.4.18 vanilla.
Slackware 9.0 will probably ship with XFree 4.3.0 and linux-2.4.20
with Andrew Morton's ext3 patches.
As far as I can tell, DRM has worked nicely with both 8.1 and 9.0-rc[12].
--
Tomas Szepe <[email protected]>
On Thu, 13 Mar 2003, Mark Mielke wrote:
> On Thu, Mar 13, 2003 at 09:42:39AM -0500, Richard B. Johnson wrote:
> > But it's a memory leak in the game, not the kernel. They should
> > complain to the game makers. If a game runs the system out of
> > memory so a user can't log in on the root account and kill off
> > the game, it's a problem with the game.
>
> I would like to encourage the camp of people who believe that UNIX can
> be a stable server platform to innovate ways of ensuring that if a game
> (or other memory intensive program) does run the system out of memory,
> an administrator could login as root and kill the game.
>
> So I don't agree with your conclusion. I think "your system crashed? well
> contact the application designer..." is a mindset that was strongly
> encoduraged by companies such as Microsoft, as it allowed them to release
> half baked kernels and call them stable. Thankfully, even Microsoft has
> learned that this isn't the best approach, and WinXP is quite a deal more
> solid than Win95.
>
> Yes, Linux is the result of (mostly) volunteer effort contributed to the
> community. No, I don't think that means it is acceptable for it to contain
> security exploits, or for it to be any less robust than other operating
> systems in its class such as AIX or Solaris. We have smart people. Let's
> use them. Let's not be satisfied with less.
>
> mark
For the most part we are getting people who don't know about
CTL-ALT-BACKSPACE, and have never even seen a shell, and don't
know that the GUI is not the normal interface, complaining because
the machine "locks" after they play some lossy games. You don't
have to reboot, you need to restart the X-Server (that will kill off
the memory-hogging games). Most distributions don't even configure
to allow the X-Server to be restarted. Still, it's not a kernel
problem and it can't be "fixed" or "worked around" in the kernel.
When you hang the user inteface, you can interface with users.
It's really that simple.
Cheers,
Dick Johnson
Penguin : Linux version 2.4.20 on an i686 machine (797.90 BogoMips).
Why is the government concerned about the lunatic fringe? Think about it.
On Thu, 2003-03-13 at 16:26, James Stevenson wrote:
> > With all due respect to all the great programmers and
> > minds in this mailing list. I could not read this and
> > not reply to this guy:
> >
> > Maybe you should take your games and movies to windows
> > and leave linux for more serious stuff. That'll fix
> > your memory leak.
>
> correct me if i am wrong here but i know alot of students
> who use linux todo serious stuff and get really pissed off have to
> reboot into windows to play games because they dont work
> under windows and for various other things that also cause
> problems in linux. Actually quite alot of them end up
> dumping linux because any of the serious games wont work on there
> system because they would have to tear much of it apart toget
> them to work.
>
> this isnt a serious problem then ?
>
Ok, I do agree that when doing support for something like Linux
where most of your free time are spent at no charge, the way
help is asked, do make a difference. However, we should try to
refrain from chasing people away when they do approach things with
a slight offensive attitude ....
Anyhow, as for your problem James, I did experience similar issues
in the past. It was basically related to a gtk+ theme engine that
leaked memory like hell. Try to change gtk+/kde/whatever themes.
Also maybe try to update your XFree86 if Slackware do have later
revisions out, as I really wont rule X out of being totally free
of major memory leaks (No offense toward xfree.org, you guys are
doing a great job =). On the other hand ... XFree86 4.3.0 is out,
so you might try to compile that by hand just as a test.
Then, do not rule out the nvidia drivers for being totally bug free.
The version before 4191 had some serious page_alloc.c bugs, which
should partly be fixed by 4191. It does still have issues though
if you are using rmap. You can get patches for it here:
http://www.minion.de/nvidia/
Also, I think there are another patch somewhere to fix one or other
problem, but cannot find it now.
Then kernel .... Did you try earlier versions to verify your suspicion ?
Or if the same thing with earlier kernel, maybe try it with 2.5.64 ?
Patches to get it working with 2.5 can be found above.
I am running a Geforce3 Ti5 here, and UT2003, UT, Quake3, etc are
working just fine. Same thing for 2.4.19 (before I switched to
2.5 kernel) ... meaning if you have the same issues with 2.4.19,
then it is very possible that it is something else at fault. Yes,
this is not clear cut, but ....
Regards,
--
Martin Schlemmer
Gentoo Linux Developer, Desktop Team
Cape Town, South Africa
* Tomas Szepe ([email protected]) wrote:
> As far as I can tell, DRM has worked nicely with both 8.1 and 9.0-rc[12].
Not on every hardware!
For example:
- X: 4.3.0 (slackware-current)
- mainboard_chipset: via-kt-400
- g.card: ATI Radeon 9000 (rv250If)
- kernel: 2.4.21-pre5-acX & 2.4.20-ac2 -> DRM 1.{6|7|8}.0 (from -ac - DRM-7)
- DRI, DRM:
dri.sf.net,
http://www.xfree86.org/~alanh/,
http://cpbotha.net/dri_resume.html,
etc...
Don't work with OpenGL (hardware acceleration) like it was in _fglrx_
(ATI-2.5.1 binary driver for X-4.{1|2}.x).
.~. $ dmesg | grep drm
[drm] AGP 0.99 on VIA Apollo KT400 @ 0xd0000000 128MB
[drm] Initialized radeon 1.7.0 20020828 on minor 0
.~. $ dmesg | grep radeonfb
radeonfb: ref_clk=2700, ref_div=12, xclk=20000 from BIOS
radeonfb: MTRR enabled
radeonfb: ATI Radeon 9000 If DDR SGRAM 64 MB
radeonfb: DVI port no monitor connected
radeonfb: CRT port CRT monitor connected
.~. $
Simple test, tray to run ut2003-demo ;-)
P.S. On debian-sid, with SiS mainboard chipset it works in X-4.3.0 (but not so
fine like on binary _fglrx_) :-(
--
# Damian *dEiMoS* Ko?kowski # http://deimos.one.pl/ #
slackware 8.1 could have problems, if you upgrade to XFree86 4.3 manually with
the precompiled binaries you can download from xfree86.org if you still use the
DRM modules coming with the kernel 2.4.18 vanilla. AT less you will have to
download and recompile correct DRM modules.
Slackware 9.0 (now rc2) has Xfree86 4.3 compiled with glibc 2.3.1, and kernel
2.4.20 with
some patches. This slackware ships also the correct DRM modules to work
correctly on XFree86 4.3.
That just to clarify esplicitally this question
Bests
Luigi
On Thu, 13 Mar 2003, Tomas Szepe wrote:
> Date: Thu, 13 Mar 2003 16:05:44 +0100
> From: Tomas Szepe <[email protected]>
> To: Alan Cox <[email protected]>
> Cc: James Stevenson <[email protected]>, pd dd <[email protected]>,
> M. Soltysiak <[email protected]>,
> ML-linux-kernel <[email protected]>,
> William Stearns <[email protected]>
> Subject: re: Linux BUG: Memory Leak
>
> > [[email protected]]
> >
> > There were problems with the XFree 4.3 DRM if you mixed it with
> > certain other ingredients like rmap. I don't know what Slackware
> > ships but that may be the problem.
>
> Slackware 8.1 shipped with XFree 4.2.0 and linux-2.4.18 vanilla.
>
> Slackware 9.0 will probably ship with XFree 4.3.0 and linux-2.4.20
> with Andrew Morton's ext3 patches.
>
> As far as I can tell, DRM has worked nicely with both 8.1 and 9.0-rc[12].
>
> --
> Tomas Szepe <[email protected]>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
On Thu, 2003-03-13 at 15:10, Mark Mielke wrote:
> On Thu, Mar 13, 2003 at 09:42:39AM -0500, Richard B. Johnson wrote:
> > But it's a memory leak in the game, not the kernel. They should
> > complain to the game makers. If a game runs the system out of
> > memory so a user can't log in on the root account and kill off
> > the game, it's a problem with the game.
>
> I would like to encourage the camp of people who believe that UNIX can
> be a stable server platform to innovate ways of ensuring that if a game
> (or other memory intensive program) does run the system out of memory,
> an administrator could login as root and kill the game.
echo "2" >/proc/sys/vm/overcommit_memory
in a -ac kernel