# 2.4.22-gentoo-r2 eats memory?!

## alexbuell

I've been running 2.4.22-gentoo-r2 for over a week and noticed that on both of my boxes, memory seems to get eaten and never gets released. On the Athlon box w/512MB, 100% of physical memory and the swap file is now 44MB, and is still slowly increasing. On my old Pentium 166 box w/ 128MB, I've had to reboot it every two days as the memory gets all eaten up and constantly swaps for hours upon hours. Has anyone seen similiar problems like this?

----------

## M104

I've had a problem recently with slocate (usually called updatedb, which is run at midnight every night) eating up hundreds of megs of memory and then not releasing them.  I'm running a Duron with 768 MB of RAM using 2.6.0 and ext3 filesystem, but it was the same with -test9, -test10, and -test11.  My "solution" was to lose the nightly updatedb cron job and just reboot to free the memory.  It's worked fine without the nightly process, so I haven't really bothered investigating.  My other box (unaffected) is a Pentium MMX on 2.4.19 with 32 MB of RAM and using ReiserFS.  Both are up to date with x86, besides the kernels.  I'm thinking that maybe my slocate and ext3 don't play well together, since everything was peachy when I used ReiserFS and 2.4.22 on the same system, but I really haven't had a change to check this out.

----------

## alexbuell

Chuffin' hell, the slocate nightly run *was* definitely  the culprit. I use ext3fs on both my boxes. Have you tried recompiling slocate? I'm about to try that out now.

----------

## M104

Wow, so this is the problem, huh?  This bug sucked up like 500MB of RAM from me and it sounds like you too.  I'll check the gentoo bug repository for this and see what's up.  And yes, I've re-emerged to no avail.

I'm glad I caught your post since I thought I was the only one to have this problem and ignored it!

----------

## alexbuell

 *M104 wrote:*   

> Wow, so this is the problem, huh?  This bug sucked up like 500MB of RAM from me and it sounds like you too.  I'll check the gentoo bug repository for this and see what's up.  And yes, I've re-emerged to no avail.
> 
> I'm glad I caught your post since I thought I was the only one to have this problem and ignored it!

 

Loosk like we've stumbled across a nasty kernel bug. I've run updatedb twice now, and will keep trying until the problem happens again - I've got to be quite sure I'm blaming the right miscreant.

----------

## alexbuell

Wow, kswapd looks _very_ unhappy now.

----------

## alexbuell

Hang on. Show me your tune2fs -l output for your filesystems - most particularly, I want to see what filesystem features you've got enabled.

----------

## alexbuell

 *alexbuell wrote:*   

> Hang on. Show me your tune2fs -l output for your filesystems - most particularly, I want to see what filesystem features you've got enabled.

 

Once I've seen your tune2fs -l results, and that confirms my suspicions, the next step will be to download vanilla kernel sources and confirm that it's not caused by a gentoo patch as used with the gentoo-sources.

----------

## M104

Alright, I added this as Bug 36855.  (My first Gentoo bug!)  I'm not at the affected computer right now, but I will be in about two hours.  I'll post more information then and hopefully we can narrow it down a bit.

----------

## M104

 *alexbuell wrote:*   

> Loosk like we've stumbled across a nasty kernel bug. I've run updatedb twice now, and will keep trying until the problem happens again - I've got to be quite sure I'm blaming the right miscreant.

 

I ran for over a week with this bug and the nightly updates and the funny thing was that the memory leak seemed to decrease over a few days and then stabilize from a maximum of 600MB down to around 400MB.  I really thought that it was some new kernel caching feature because of the weird behaviour.  Eventually, though, I just got sick of all that wasted memory so I dropped the cron job and rebooted.

 *alexbuell wrote:*   

> Once I've seen your tune2fs -l results, and that confirms my suspicions, the next step will be to download vanilla kernel sources and confirm that it's not caused by a gentoo patch as used with the gentoo-sources.

 

Well, first of all, I'm running development-sources.  Are there any Gentoo patches in there?  I'm betting that the problem is slocate, but we'll see.   :Laughing: 

----------

## alexbuell

 *M104 wrote:*   

>  *alexbuell wrote:*   Loosk like we've stumbled across a nasty kernel bug. I've run updatedb twice now, and will keep trying until the problem happens again - I've got to be quite sure I'm blaming the right miscreant. 
> 
> I ran for over a week with this bug and the nightly updates and the funny thing was that the memory leak seemed to decrease over a few days and then stabilize from a maximum of 600MB down to around 400MB.  I really thought that it was some new kernel caching feature because of the weird behaviour.  Eventually, though, I just got sick of all that wasted memory so I dropped the cron job and rebooted.

 

Ah, that explains why my 512MB box hasn't died yet. I'm on my fifth consecutive updatedb run on the 128MB box, it seems to be quite distinctly slow. I now think it's a combination of rsync and updatedb operations that triggers this bug.

----------

## M104

Mods, can we move this to Other Things Gentoo?

----------

## incubator

I too suffer from it.

I have 512mb ddr and have curretly 200mb free.

There was 435mb free when I just booted, and after a few emerges and an updatedb this is whats left.

The programs i am running atm is low: konqueror, xmms, apache, mysql, gkrellm and the regular batch of system processes.

since I use fluxbox I should have about 380mb free right now, but I dont.

Yestderday (first time I tested my frashly installed 2.4.22-r2)

I experienced enormous lags when emerging (regular or pretend), X restarted at random and konqueror crashed at random. Today I recompiled the kernel, (not much vital changes mind you, just and addition to i2c wich I apparently didn t even need :p), I recompiled kde and updated xmms (wich also crashed yesterday at random) today I have experienced no crashes anymore (even after rebooting several times) though as I said; currently 200mb left  :Sad:  (this is the value shown by gkrellm, not top, since top always says I have a few legs free, even with other kernels due to the different memory managment in linux)

my output from tune2fs -l:

```

tune2fs -l /dev/hda1

tune2fs 1.34 (25-Jul-2003)

Filesystem volume name:   <none>

Last mounted on:          <not available>

Filesystem UUID:          fba8d41a-f018-4ac4-a8bd-778d7e2a1430

Filesystem magic number:  0xEF53

Filesystem revision #:    1 (dynamic)

Filesystem features:      has_journal dir_index filetype sparse_super

Default mount options:    (none)

Filesystem state:         clean

Errors behavior:          Continue

Filesystem OS type:       Linux

Inode count:              18072

Block count:              72261

Reserved block count:     3613

Free blocks:              63865

Free inodes:              18043

First block:              1

Block size:               1024

Fragment size:            1024

Blocks per group:         8192

Fragments per group:      8192

Inodes per group:         2008

Inode blocks per group:   251

Filesystem created:       Fri Jul 18 00:50:08 2003

Last mount time:          Tue Dec 30 20:46:38 2003

Last write time:          Tue Dec 30 20:47:08 2003

Mount count:              10

Maximum mount count:      24

Last checked:             Wed Oct 15 00:43:56 2003

Check interval:           15552000 (6 months)

Next check after:         Mon Apr 12 00:43:56 2004

Reserved blocks uid:      0 (user root)

Reserved blocks gid:      0 (group root)

First inode:              11

Inode size:               128

Journal inode:            8

Default directory hash:   tea

Directory Hash Seed:      9567ca6c-efd1-47d9-8a70-0c1029316425

```

this is from /boot wich is the only ext3 partition, root is reiserfs

----------

## M104

Here's mine:

```
almond root # tune2fs -l /dev/sda1

tune2fs 1.34 (25-Jul-2003)

Filesystem volume name:   <none>

Last mounted on:          <not available>

Filesystem UUID:          9b04a478-7f67-4d87-b265-7eb3eac679e4

Filesystem magic number:  0xEF53

Filesystem revision #:    1 (dynamic)

Filesystem features:      has_journal filetype needs_recovery sparse_super

Default mount options:    (none)

Filesystem state:         clean

Errors behavior:          Continue

Filesystem OS type:       Linux

Inode count:              625248

Block count:              1249045

Reserved block count:     62452

Free blocks:              1055673

Free inodes:              612390

First block:              0

Block size:               4096

Fragment size:            4096

Blocks per group:         32768

Fragments per group:      32768

Inodes per group:         16032

Inode blocks per group:   501

Filesystem created:       Sun Nov 23 19:53:41 2003

Last mount time:          Thu Dec 25 02:29:35 2003

Last write time:          Thu Dec 25 02:29:35 2003

Mount count:              16

Maximum mount count:      30

Last checked:             Sun Nov 23 19:53:41 2003

Check interval:           15552000 (6 months)

Next check after:         Fri May 21 20:53:41 2004

Reserved blocks uid:      0 (user root)

Reserved blocks gid:      0 (group root)

First inode:              11

Inode size:               128

Journal inode:            8

Default directory hash:   tea

Directory Hash Seed:      033736f2-da61-4958-a6af-5c0839b08af6
```

----------

## wll

For what it's worth, I've got the same problem on a UML system (at Linode.com, highly recommended) based on 2.4.23.

This kernel is used by all the Linode.com distros, not just Gentoo (Debian, Fedora, Mandrake, RedHat and Slackware, too).

Tracked it down a couple of days before this thread (damn!) and was wondering whether to bring it up here or at my host. Guess I'll point him here. I wrote a little process monitoring script that found it (live, debug and learn). I'm about to move from UML to a dedicated host, so I guess slocate will stay disabled (/etc/cron.never).

----------

## pjp

Moved from Installing Gentoo.

----------

## incubator

update: X crashed again this night, and even though all apps were shutdown, I was left with 235mb ram.

Wich should be 435 when I would restart

----------

## incubator

and apparently, reiserfs IS affected as well.

I had 450mb ram free, updatedb finished and 100 mb was left.

(still after 30 ' )

and my entire root (full storage etc) is reiserfs. Only my /boot is ext3.

----------

## Epyon

I have the same problem with every version of 2.6.0 I have tried. I'm using reiserfs. The slocate job ran over an hour ago and half my 512mb of ram is still apparently being used.

----------

## alexbuell

Look at your /proc/slabinfo figures for inode_cache and dentry_cache. Those two are responsible for the problems we've been seeing. if you get hold of Larry McVoy's lmbench programs, runnng lmdd will force a reclaim and you get all that memory freed. Caveat: Exit X11 first before running it. See http://www.ussg.iu.edu/hypermail/linux/kernel/0112.1/0072.html for more details.

----------

## M104

 *alexbuell wrote:*   

> Look at your /proc/slabinfo figures for inode_cache and dentry_cache. Those two are responsible for the problems we've been seeing. if you get hold of Larry McVoy's lmbench programs, runnng lmdd will force a reclaim and you get all that memory freed. Caveat: Exit X11 first before running it. See http://www.ussg.iu.edu/hypermail/linux/kernel/0112.1/0072.html for more details.

 

If it's the same problem we're experiencing, umm wow...  That post was from over two years ago!  Well I'm off to test lmdd and see what happens.

----------

## alexbuell

 *M104 wrote:*   

>  *alexbuell wrote:*   Look at your /proc/slabinfo figures for inode_cache and dentry_cache. Those two are responsible for the problems we've been seeing. if you get hold of Larry McVoy's lmbench programs, runnng lmdd will force a reclaim and you get all that memory freed. Caveat: Exit X11 first before running it. See http://www.ussg.iu.edu/hypermail/linux/kernel/0112.1/0072.html for more details. 
> 
> If it's the same problem we're experiencing, umm wow...  That post was from over two years ago!  Well I'm off to test lmdd and see what happens.

 

Well yes, the VM sucks mightily in not reclaiming memory aggressively enough.

----------

## M104

Alright, results after a fresh reboot:

```
#free -mt

             total       used       free     shared    buffers     cached       

Mem:           756         68        688          0          2         41       

-/+ buffers/cache:         24        732                                        

Swap:          972          0        972                                        

Total:        1729         68       1660 
```

Only 24 MB being used.  Now let's activate the bug and see how much we have left:

```
#updatedb

#free -mt

             total       used       free     shared    buffers     cached       

Mem:           756        493        263          0        162         45       

-/+ buffers/cache:        285        470                                        

Swap:          972          0        972                                        

Total:        1729        493       1235
```

OK, So I've "lost" 260 MB of space.  Now lets see what I can reclaim:

```
#lmdd opat=1 count=1 bs=900m

#free -mt

             total       used       free     shared    buffers     cached       

Mem:           756         87        669          0          0          3       

-/+ buffers/cache:         84        672                                        

Swap:          972         72        900                                        

Total:        1729        159       1570                                        

```

So, there's still an additional 150MB or so that was not reclaimed in this case.  That memory isn't cached or buffered, though, so it's technically  unavailable to the system, right?  That sounds like a memory leak to me, but I'm new to debugging like this.

----------

## alexbuell

 *M104 wrote:*   

> 
> 
> So, there's still an additional 150MB or so that was not reclaimed in this case.  That memory isn't cached or buffered, though, so it's technically  unavailable to the system, right?  That sounds like a memory leak to me, but I'm new to debugging like this.

 

Try it with bs=1500m (i.e. total amount of memory available (includes swap))

----------

## M104

 *alexbuell wrote:*   

>  *M104 wrote:*   
> 
> So, there's still an additional 150MB or so that was not reclaimed in this case.  That memory isn't cached or buffered, though, so it's technically  unavailable to the system, right?  That sounds like a memory leak to me, but I'm new to debugging like this. 
> 
> Try it with bs=1500m (i.e. total amount of memory available (includes swap))

 

I tried it with the maximum bs=???m that it would let me (1600m, for the first run) and then increased it as more memory was reclaimed.  I got to about 1720m before it wouldn't reclaim any more.  At that point though, I was still out about 30 MB in "lost" memory and it took a while to get to that point.  So I guess it is possible to reclaim most of the lost memory, but it's still pretty gross.

EDIT:  I went looking through the kernel source for any hints as to where this lost memory might be going and the first thing I saw is that I don't know anything about the kernel source...    :Embarassed: 

----------

## alexbuell

 *M104 wrote:*   

> 
> 
> I tried it with the maximum bs=???m that it would let me (1600m, for the first run) and then increased it as more memory was reclaimed.  I got to about 1720m before it wouldn't reclaim any more.  At that point though, I was still out about 30 MB in "lost" memory and it took a while to get to that point.  So I guess it is possible to reclaim most of the lost memory, but it's still pretty gross.

 

That fits in what I've found. That's probably the mimimum amount the kernel needs to keep open. I've posted to the linux-kernel mailing list about this problem, and hopefully there might be a patch soon to resolve this issue.

----------

## alexbuell

According to replies I've had on the linux-kernel list, there is a fix in 2.6.1, and 2.4.23 has a fix for this problem.

----------

## NeighborhoodGullwings

 *alexbuell wrote:*   

> According to replies I've had on the linux-kernel list, there is a fix in 2.6.1, and 2.4.23 has a fix for this problem.

 There is? Is it a separate patch for 2.4.23 or is it included? Because I've been running the 2.4.24 pres and I've been having this problem too. Maybe I'll try 2.4.23 again to see if that corrects it.

----------

## alexbuell

 *NeighborhoodGullwings wrote:*   

>  *alexbuell wrote:*   According to replies I've had on the linux-kernel list, there is a fix in 2.6.1, and 2.4.23 has a fix for this problem. There is? Is it a separate patch for 2.4.23 or is it included? Because I've been running the 2.4.24 pres and I've been having this problem too. Maybe I'll try 2.4.23 again to see if that corrects it.

 

Try the aa-sources - that'll have the fixes in them.

----------

## Epyon

 *alexbuell wrote:*   

> According to replies I've had on the linux-kernel list, there is a fix in 2.6.1, and 2.4.23 has a fix for this problem.

 

Well it isn't in 2.6.1-rc1-mm1 because I'm still having the problem...

----------

## mhodak

Alex,

can you post the link to the thread you created in kernel mailing list archives?

Also, anybody understands why in the old thread in the kernel mailing list http://www.ussg.iu.edu/hypermail/linux/kernel/0112.1/0072.html  the fix is to disable ntfs support? I have compiled ntfs in as a module, but it is not loaded so I do not think that recompiling without ntfs support would help.

----------

## aengus9

I'm running 2.4.22-gentoo-r2 and did *not* compile ntfs support in the kernel and am having the same problems.

----------

## NeighborhoodGullwings

 *mhodak wrote:*   

> 
> 
> Also, anybody understands why in the old thread in the kernel mailing list http://www.ussg.iu.edu/hypermail/linux/kernel/0112.1/0072.html  the fix is to disable ntfs support? I have compiled ntfs in as a module, but it is not loaded so I do not think that recompiling without ntfs support would help.

 That thread is over 2 years old and is highly likely a different problem than what we're experiencing now.

----------

## alexbuell

Red herring. The real problem appears to be a leak in ext3. Here's a patch for you to try.

```
diff -Nru a/fs/ext3/dir.c b/fs/ext3/dir.c

--- a/fs/ext3/dir.c     Wed Apr 23 21:37:34 2003

+++ b/fs/ext3/dir.c     Wed Apr 23 21:37:34 2003

@@ -501,7 +501,7 @@

 

 static int ext3_release_dir (struct inode * inode, struct file * filp)

 {

-       if (is_dx(inode) && filp->private_data)

+       if (filp->private_data)

                ext3_htree_free_dir_info(filp->private_data);

 

        return 0;

```

----------

## mhodak

That is nice, but I have reiserfs and this bug affects me as well. It eats quite a lot of my memory overnight. Other people also see this on reiser, so it is not ext3 specific. It may be worse on ext3, but it is already bad on reiser.

BTW, has this patch been accepted to a recent kernel?

----------

## wll

Hey, Alex,

I'm about to compile a kernel for my new box after leaving behind a UML kernel. Any recommendations for which sources? It'd be nice if I knew I could leave this bug behind.

I'm a total newbie at the Linux kernel although not to compiling or software development in general. Something about this puzzles me -- why aren't more people affected and this bug more "web-visible"? Surely slocate is widespread enough that thousands of people should be experiencing this.

Thanks,

Wes

----------

## mhodak

I have been wondering the same thing, this must affect many linux users. The fact that this bug did not get enough publicity is probably because (as somebody pointed out previously), the memory "loss" seems to stabilize over time and kernel seems to reclaim part of the memory over time, so that my system, even if it is on over two weeks still runs. Each locatedb run increases my memory usage very close to 100 %, and after its done, starting any program, even xterm hits swap (should not happen with my 512 MB memory) and the system feels slow for a while. But in a matter of hours, kernel reclaims some of the "lost" memory (about 100MB in 24 hours) which is enough for many tasks (once GUI is up and running).

So I think that people that do not monitor their memory usage (I use gkrellm) do not notice this.

----------

## aengus9

That seems to make sense.  I'm running on a Pentium 100 with 48 MB of memory, so my system is pretty much useless after this problem occurs.  I might not notice the slight slowdown if I was running bigger hardware

I've removed the slocate from the cron.daily folder in /etc, which means that my system stays up and running now, but I have a question about how will I go about actually fixing this problem?  Running 'emerge sync' causes the machine to go into thrash mode (Does emerge run updatedb?) and even after letting it run for two days never finished.  So I'm not sure how I'll go about actually getting the update once it comes out.  

Also, am I okay running a system without the daily updatedb job running?

Thanks

----------

## MadScientist

 *aengus9 wrote:*   

> so, am I okay running a system without the daily updatedb job running?

 The only side effect is that the "locate" command will have out of date information.

----------

## mhodak

Whoever comes here and experience this problem, can you post your kernel version and filesystem?

May help to identify the bug.

Mine:  2.4.22-gentoo-r2, ReiserFS

----------

## ahr

 *mhodak wrote:*   

> Whoever comes here and experience this problem, can you post your kernel version and filesystem?
> 
> May help to identify the bug.
> 
> Mine:  2.4.22-gentoo-r2, ReiserFS

 

2.6.1-rc1-mm2 I believe.  EXT3.

512 MB ram. Fills up every midnight or so  :Smile: 

----------

## mhodak

 *Quote:*   

> 
> 
> 2.6.1-rc1-mm2 I believe. EXT3.
> 
> 512 MB ram. Fills up every midnight or so
> ...

 

Wow, so this problem shows even with latest 2.6 kernel. According to Alex post,

it was supposed to be fixed in 2.6.1, but apparently it is not.

----------

## r1chardgreen

Mhodak:

 *mhodak wrote:*   

> Whoever comes here and experience this problem, can you post your kernel version and filesystem?
> 
> May help to identify the bug.
> 
> 

 

Mine is 2.4.22-gentoo-r2, using ext3 - definitely - can reproduce with slocate, emerge rsync, etc.

I think I get this on one of my servers too which has very different hardware... testing there isn't really possible but the kernel it uses a lot more RAM than I would expect - though it's stable now using just under 1GB.

----------

## aengus9

2.4.22-gentoo-r2, with ext3 on all partitions.  Come midnight my Pentium 100 with 48 Meg doesn't stand a chance

----------

## M104

 *alexbuell wrote:*   

> Red herring. The real problem appears to be a leak in ext3. Here's a patch for you to try.
> 
> ```
> diff -Nru a/fs/ext3/dir.c b/fs/ext3/dir.c
> 
> ...

 

No, this patch is already in 2.6.0, my affected system, and not in 2.4.19-gentoo-r10, my unaffected system.   :Sad: 

----------

## alexbuell

How odd. That patch really does solve the problem for me and I'll know for sure by tomorrow if the problem is really gone. It takes two days before the problem manifests itself for me, and I applied the patch the day before on both boxes.

----------

## Epyon

 *M104 wrote:*   

> 
> 
> No, this patch is already in 2.6.0, my affected system, and not in 2.4.19-gentoo-r10, my unaffected system.  

 

I think that's because its not a problem with ext3 in 2.6.0. I and some other people here are using reiserfs exclusively and we're still having the problem.

----------

## dudds

Guys,

Not sure this is relevant or not, but I'm adding because I noticed memory problems with my PC. I am using kernel 2.4.20-gentoo-r6. I first noticed the problem after copying very large files (>700MB)  between disk partitions. I have 1GB of RAM in my system. When I use nautilus to kick off a file copy and have the Gnome system monitor open, the used memory will steadily increase during the file copy until all bar about 20MB of available memory is used up.

I have also noticed this behaviour when using MPlayer to play movies. This is totally repeatable behaviour. Closing the above apps does not free all the memory again. I was unsure if the bug might be with Gnome or the System monitor.

Is there other commands I can use to verify the amount of memory used. I'm still a pretty new Linux user.

Cheers,

Dave

----------

## imageek

i have been memory problems alot lately. Both my work box and home box. Mostly my work box i have noticed because i run an ftp server for some of our mandrake servers and i rsync with mandrakes site. I would come in on mondays and the box would be unresponsive. X crashed on it. And the log files full of "memory allocation" errors. I had never noticed or looked at how much memory was being used BEFORE these crashes. 

Here are my specs

Work: Dell Optiplex GX400

kernel - 2.4.22-gentoo-r2

CPU - Intel(R) Pentium(R) 4 CPU 1400MHz

memory - 1gig

file system - ext3

Home: Custom built

kernel - 2.4.22-gentoo-r3

CPU - AMD Athlon XP 1700

memory - 1.5gig

file system - ext3

Let me know if i can provide anymore information.

----------

## aengus9

Ok, I'm screwed.  If anyone has any suggestions I'd really appreciate it.  My extremely low end hardware (Pentium 100 with 48 Meg of RAM) simply can't finish any large task with the memory bug.  'Emerge sync' won't finish.  "emerge gentor-sources-2.4.20-r7.ebuild" won't finish.  So I can't even download new kernel sources, and even if I could I'm not sure the kernel would be able to compile.

I have a bzImage from my previous kernel (2.4.20-r7) but I deleted the source from /usr/src and the modules from /lib/modules.

I tried having grub point to the 2.4.20-r2 bzImage and copied everything from /lib/modules/2.4.22-gentoo-r2 to /lib/modules/2.4.20-gentoo-r7

This boots, but the module for my network card won't load.  Are modules from 2.4.22 not compatible with modules for 2.4.20?  Do I actually need the source directory to be in /usr/src?

Can anyone help me?  I've got two bzImage files, one from 2.4.22-r2 and one from 2.4.20-r7.  I have the /usr/src directory for 2.4.22-r2 and the /lib/modules directory for 2.4.22-r2.  I can't emerge sync, I can't emerge *kernel-source*  I'm kind of at a loss.

Thanks for any help

----------

## NeighborhoodGullwings

 *aengus9 wrote:*   

> 
> 
> This boots, but the module for my network card won't load.  Are modules from 2.4.22 not compatible with modules for 2.4.20? 

 That could be the case. Or maybe you upgraded your compiler between kernel versions?

Can you boot from a LiveCD and then fix your system from there?

How much swap space do you have? Can you make more?

This sure is seeming to be a weird problem afterall.

----------

## r1chardgreen

 *aengus9 wrote:*   

> Ok, I'm screwed.  If anyone has any suggestions I'd really appreciate it.  

 

You are not screwed. With linux you are rarely totally screwed. Thats one reason we like it so much  :Wink: 

Here's one suggestion to get going again:

Boot from an install CD - e.g. a gentoo bootable CD, though other CDs, such as knoppix etc would probably work.  

Use single user mode, then manually start any networking componants you need to, by following sections in the Gentoo install docs.

Next follow the gentoo install docs to mount your existing partitions and then chroot. (Of course, don't do any of the initial disk partitioning and stuff or you will delete everything on your system). 

At that stage you are ready to reconfigure your boot loader for an older kernel you already have in /boot, download older kernel source, patch new kernels, whatever you want to do. 

Once you are fixed up, and boot loader is correctly configured, reboot.

RG

----------

## alexbuell

Yep, I can confirm the patch fixes the problem for me. Two days now and no more problems!

----------

## mhodak

 *Quote:*   

> 
> 
> ep, I can confirm the patch fixes the problem for me. Two days now and no more problems!

 

That means that whatever we seen reiser is a different issue. Strange.

----------

## imageek

ok call me a n00b or whatever, i cant get this patch to apply. Im doing it from the wrong place or something. Here is the error im getting.

cd /usr/src/linux/fs/ext3/

```

imageek ext3 # patch <patch_ext3

patching file dir.c

patch: **** malformed patch at line 6: static int ext3_release_dir (struct inode * inode, struct file * filp)
```

maybe its too early and im not awake enough or something. Someone give me a clue or a nudge in the right direction.

----------

## r1chardgreen

The ext3 patch fine works for me too. I noticed that the release of memory only seems to happen when something else demands it (at least according the to little memory monitor thing on my task bar) - could that be why some posts in this thread reckon the ext3 patch did not work?

Also, imageek, applying the patch... the line that throws the error when you run patch is at line 5 in my patch file, not line 6. You may have a linewrap or the diff command left in at the top or something. Also I had to use used 'patch -l' so there must be some white space differences. But anyway, it's one line - so just type it in  :Wink: 

RG

----------

## imageek

yeah i know and i did just type it in, but i still wanted to know why it didnt work lol. and yeah i must have copied and pasted the patch wrong.

----------

## mhodak

Alex,

or anybody else for whom the patch works. Can you post here your free output before and after updatedb. I would really like to see what  it looks like when things work properly. Is all the extra memory that updatedb used reported in "buffers" and "cached" columns?

Thanks

----------

## aengus9

Here's my output after applying the patch and recompiling.  No one laugh at the amount of RAM though

```

thalia root # free -mt

             total       used       free     shared    buffers     cached

Mem:            37         35          1          0          1          6

-/+ buffers/cache:         28          8

Swap:          133          9        123

Total:         170         45        125

thalia root # ./slocate

thalia root # free -mt

             total       used       free     shared    buffers     cached

Mem:            37         36          0          0          3          1

-/+ buffers/cache:         31          6

Swap:          133         21        112

Total:         170         57        112

```

Looks like the memory wasn't freed immediately after updatedb ran.  I'll check it in the morning and see if any was reclaimed over time.

----------

## mhodak

aengus9,

since applying patch, did you in any way see improvment (memory-wise)?

----------

## imageek

anyone know if this is supposed to be fixed in 2.6.1? i installed the gentoo-dev-sources saturday morning and my box was maxed out on memory (1.5gig)  by sunday morning.

----------

## mhodak

 *Quote:*   

> 
> 
> nyone know if this is supposed to be fixed in 2.6.1? i installed the gentoo-dev-sources saturday morning and my box was maxed out on memory (1.5gig) by sunday morning. 

 

I do not think so (unless you see the ext3 bug), since people running release candidates for 2.6.1 also had this bug. I think part of the problem is that nobody reported this to kernel people, (Alex reported bug in ext3 which was fixed in 2.6.0). Also, the bugzilla report did not see much activity from developers, so it will take some time for this issue to be resolved.

----------

## imageek

well i went digging around in the source and it does have the patch in the gentoo-dev-sources for 2.6.1, which i am running since saturday. I am showing that almost all of my memory is eaten up. But i have a good chunk in the buffers and cache.  Does this mean the memory is there to be used by the system if it needs it? Here is the output of free -mt while i am doing an emerge -uDv world. 

```

free -mt

             total       used       free     shared    buffers     cached

Mem:          1517       1413        103          0        292        463

-/+ buffers/cache:        658        859

Swap:          729          0        729

Total:        2246       1413        833

```

----------

## imageek

well for some reason it freed up some memory this morning. I swear when i woke up this morning there was only like 12 meg free. So maybe it is working just takes some time.

----------

## tomaw

I seem to be having this issue recently with:

Linux tawesley 2.6.1-gentoo #1 SMP Fri Jan 9 19:37:52 GMT 2004 i686 AMD Athlon(tm) MP 2400+ AuthenticAMD GNU/Linux

and a reiserfs root partition.

Is there a suspected fix as yet?

----------

## mhodak

 *Quote:*   

> 
> 
> I am showing that almost all of my memory is eaten up. But i have a good chunk in the buffers and cache. Does this mean the memory is there to be used by the system if it needs it? Here is the output of free -mt while i am doing an emerge -uDv world. 

 

imageek,

Yes, system can use "buffers" and "cached" memeory whenever necessary, so available memory is basically "free" +  "buffers"  + "cached".

Try out the patch, and run "free -mt" before and after updatedb run and also after you see the raclaim of memeory. Count up the free memory and post it.

----------

## imageek

well i have upgraded to 2.6.1 gentoo-sources over the weekend and it seems to be patched.  and i have been allowing slocate to run every evening in the cron job again and not noticing any performance degredation. i can still post the output but updatedb takes about 30 seconds to run right now and only grabs about 5mb of memory it seems.

----------

## mhodak

imageek,

if it is not too much hassle I would like to see actual "free -mt" output.

----------

## imageek

```

 free -mt

             total       used       free     shared    buffers     cached

Mem:          1517       1352        164          0        302        485

-/+ buffers/cache:        564        952

Swap:          729          0        729

Total:        2246       1352        893

```

Ill get you another one in the morning also when i get up.

----------

## chiatello

 :Surprised: 

----------

## aengus9

After letting my system sit and do nothing all day, no memory appears to have been freed  Here is my output of 'free -mt'

```

thalia root # free -mt

             total       used       free     shared    buffers     cached

Mem:            37         36          0          0          2          1

-/+ buffers/cache:         32          4

Swap:          133          5        127

Total:         170         41        128

```

Its exactly what I had after I ran updatedb last night.  Does memory one get freed when some other application asks for it?

----------

## mhodak

 *aengus9 wrote:*   

>  Does memory one get freed when some other application asks for it?

 

If I understand Linux memory management correctly, memory should be freed  as soon as application is finished, i.e. the part of memory that application used should be "shifted" into some of "free", "cached" or "buffers". The further freeing can occur only when some cached memory not used for certain time is moved to swap. The rest of memory (used - buffers - cached) cannot be used by anything else (except when system is low in memory, then it can move some part of  it to swap), that is it cannot be freed because something is using it.

----------

## aengus9

Just upgraded my kernel to 2.4.22-gentoo-r4 and I can report that the bug is still present.  The patch given earlier doesn't apprear to have been applied.   Same story as last time, applied patch, recompiled, memory still doesn't appear to be freed after running updatedb, but at least the system runs.

----------

## alexbuell

 *aengus9 wrote:*   

> Just upgraded my kernel to 2.4.22-gentoo-r4 and I can report that the bug is still present.  The patch given earlier doesn't apprear to have been applied.   Same story as last time, applied patch, recompiled, memory still doesn't appear to be freed after running updatedb, but at least the system runs.

 

I think it's in gentoo-sources 2.4.22-r5 now. I'm downloading to find out if it really is. Hurrah, if true!

[ edited ] 

YES!! It's in, at last! Rejoice!   :Very Happy: 

----------

## aengus9

Just download and compiled 2.4.22-r5, and while the patch has been applied, I still don't see memory released after running updatedb.  Not sure if this is normal behavior or not, (I'm a bit of a noob) but at least my system runs.  I guess I won't worry about it any more, but I'd feel a bit better if I could actually see memory being released.  Maybe I'll try to reboot periodically

```

thalia root # free -mt

             total       used       free     shared    buffers     cached

Mem:            60         28         32          0          1         15

-/+ buffers/cache:         10         49

Swap:          188          0        188

Total:         248         28        220

thalia root # updatedb

thalia root # free -mt

             total       used       free     shared    buffers     cached

Mem:            60         59          1          0          5          2

-/+ buffers/cache:         51          9

Swap:          188          3        184

Total:         248         63        185

thalia root #

```

I also upgraded my machine, which is why there's the difference in memory size since my previous posts.

----------

## mhodak

aengus9,

did the ext3 patch helped you at all (you are using ext3, right)? 

Your first post in this thread said that your system was thrashed after updatedb run, is this still happening, or is the only annoyance that memory is not reclaimed?

As for as reclaiming, read my next post.

BTW, when reading free output, the most relevant numbers are on the second line "-/+ buffers/cache", these should show real used and available memory.

It should be just sum of free + buffers and caches.

Oh, and do not reboot until necessary.

----------

## mhodak

Everybody following this thread

The bug was officially closed as resolved.

The ext3 problem was fixed with the patch that made it into gentoo 2.4.22-r5 kernel.

As for as not reclaimng memory, the reply from developer to my free command output was that it is not bug and that it happens  on every system he has seen. I did search on this problem and quite a lot of people noticed this problems over past two years, it even appeared several times on kernel mailing list leading to technical discussions (involving Linus) about reclaimng memory saying basically that memory is in fact available but is reclaimed only when there is no other memory avaialable -at least that is my impression. A couple of people (not on kernel mailing list)  used a C program which allocates lots of  memory (using malloc)  to confirm that this memory can be in fact used by other applications.

So, it seems like this issue is not a bug, but a kernel memory management feature that we do not understand (or perhaps free command does not handle report memory usage correclty in some special situations). Also, if this would be a real memory leak this would lead to crashes, which nobody reported.

One last thing: Strangely, it seems to me that this does not happen on redhat 9 box I use at work.  I will try to test it on Monday.

----------

## aengus9

I'm sorry, I should have been more clear.  Yes, the patch did take care of my problem.  Before the patch, my system would be completely thrashed after running updatedb.  After applying the patch, while I can't see memory being freed, my system does seem to function well enough now.  

Thanks for the explanation mhodak, I appreciate the englightenment.  I'll hold off on the scheduled reboots.  I do enough of that with my windows machines anyway.

----------

## RioFL

 *mhodak wrote:*   

> Whoever comes here and experience this problem, can you post your kernel version and filesystem?
> 
> May help to identify the bug.
> 
> Mine:  2.4.22-gentoo-r2, ReiserFS

 

I came here researching exactly the same problem. I have experienced it on all of the 2.4.22 kernels. I am presently using 2.4.22-gentoo-r4 with reiserfs and several mounted nfs directories. I believe locatedb is ignoring the nfs directories. (hope so anyway).

I run 1gb ram, and my memory jumps to 580mb used and stays there after running updatedb. Normally light usage stays about 280mb, and any increases are freed immediately upon exit of the extra programs.

I have the kernel set for 4gb high memory configuration and tested both with and without the 'himem' checkbox below that. no change.

I do not recall this problem when I was running 2.4.20 but then I also had a different hardware resource configuration and at that time was running vmware consistantly which inflated my swap to the point I had to reboot every 2 days.

Chuck

----------

## RioFL

 *mhodak wrote:*   

> Everybody following this thread
> 
> The bug was officially closed as resolved.
> 
> The ext3 problem was fixed with the patch that made it into gentoo 2.4.22-r5 kernel.
> ...

 

I don't buy their excuse. For this simple reason that when I went back to 2.4.20-gentoo-r7 kernel [in the past 15 min] my locatedb memory usage NEVER exceeded 290mb total and freed itself (100% of it) immediately upon exit!!

Sorry, but there is something odd about the 2.4.22+ kernels.

----------

## mhodak

 *RioFL wrote:*   

> 
> 
> I don't buy their excuse. For this simple reason that when I went back to 2.4.20-gentoo-r7 kernel [in the past 15 min] my locatedb memory usage NEVER exceeded 290mb total and freed itself (100% of it) immediately upon exit!!
> 
> Sorry, but there is something odd about the 2.4.22+ kernels.

 

This thing bothers me as well, I do not like updatedb caching and not releasing memory properly. As I wrote above, it can be reclaimed if really needed , but it is 50% of my memory and  I really do not care about updatedb running fast since it runs over night anyway. At least the second run  of updatedb do not take any more memory.

Perhaps the best solution would be to open a new bug and see if we can get developers to do something about it, since even 2.6 kernels experience this behavior. I will do this if my test on RH box will show that RH kernel works as expected.

----------

## RioFL

 *mhodak wrote:*   

>  *RioFL wrote:*   
> 
> I don't buy their excuse. For this simple reason that when I went back to 2.4.20-gentoo-r7 kernel [in the past 15 min] my locatedb memory usage NEVER exceeded 290mb total and freed itself (100% of it) immediately upon exit!!
> 
> Sorry, but there is something odd about the 2.4.22+ kernels. 
> ...

 

I am beginning to suspect maybe more than one thing. I downgraded back to 2.4.20-gentoo-r7 after 4 hours of playing with aa-sources, and gentoo sources and various combinations of configurations with and without himem support. 

This is really confusing. All kernels left memory high as reported by gkrellm2 and free. Except 2.4.20. That one used 890mb with the kernel configured for no highmem support at all so I lose 100mb or so of top ram. It has been an hour since I ran it. Free still reports 886mb used, however gkrellm2 reports 304mb used which I expect considering with highmem support my usual is 240mb.

This machine I have this trouble on has the latest of everything on it. The other machine which also uses the 2.4.20-r7 kernel, has not been updated in a while. That one also only has 512mb ram. Behavior on that machine is perfect. Memory goes up to close to 450mb, and as soon as updatedb is finished, it drops right back down to 145mb where it normally is. What appeared to be a simple case of finding which version kernel this began with, has suddenly turned into a possible shared library/gcc/whoknowswhat nightmare.

----------

## mhodak

I also think that when using 2.4.20 kernel my memory usage was lower, but I do not have this kernel anymore. I am ruuning gkrellm and to my recollection the used memory bar was showing about half, but now it is close to full.

BTW, in my experience, gkrellm and free alway gave the same (within 5 MB or so).

----------

## RioFL

 *mhodak wrote:*   

> I also think that when using 2.4.20 kernel my memory usage was lower, but I do not have this kernel anymore. I am ruuning gkrellm and to my recollection the used memory bar was showing about half, but now it is close to full.
> 
> BTW, in my experience, gkrellm and free alway gave the same (within 5 MB or so).

 

I don't have the ebuild stuff any more I just tarred up my directory from the other machine. If you want it I can put it on a site you can download it. It is 200mb because I did not clear out the object modules since I didnt want to disturb the config for that machine. The free/gkrellm agreement has always been my experience too. but this time around it is different. Currently my gkrellm is telling me I have 288mb used yet my free command is way up. here it is:

             total       used       free     shared    buffers     cached

Mem:        902584     894704       7880          0     350996     249268

-/+ buffers/cache:     294440     608144

Swap:       498004       6968     491036

VERY odd behavior.

Chuck

----------

## mhodak

I just did tests on RH machine which uses 2.4.20 kernel and  here are the results (the machine is freshly rebooted):

```

# free -m

             total       used       free     shared    buffers     cached

Mem:           249         43        206          0          5         20

-/+ buffers/cache:      16        233

Swap:          517          0        517

#updatedb

# free -m

             total       used       free     shared    buffers     cached

Mem:           249        229         20          0         64         22

-/+ buffers/cache:     142        107

Swap:          517          0        517

```

Thus it eats about half of the memory, the same as 2.4.22 kernel on my gentoo machine. But doing anything intensive (installing rpm for new kernel, running nvidia-installer) frees up most of the memory. Here is memory after "nvidia-installer -f"

```

#free -m

             total       used       free     shared    buffers     cached

Mem:           249        210         38          0         64        107

-/+ buffers/cache:         38        210

Swap:          517          0        517

```

I have also tried rerunning of upgradedb at this point to see if it wants some more memory, but memory usage stays the same after the rerun.

It seems as if the memory held by updatedb can in fact be easily freed when needed in 2.4.20, but I still do not undertsand why it is not freed immediately as it is the case for other applications (or perhaps free is wrong?). The thing is that with 2.4.22 kernel on my Gentoo box, doing emerge or something similar does not seem to free up the memory, but it may be because the gentoo box has twice the memory of RH box.

I realized that 2.4.20 kernel is still available through portage so I will try it 

later today and test if its memory management is any better.

In the meantime, can anybody test this freeing behavior, that is to run a big job (emerge, open office, anything that requires lots of memory) and see  if memory was freed (without increasing swap usage)?

----------

## RioFL

 *mhodak wrote:*   

>  <snipped for brevity>
> 
> It seems as if the memory held by updatedb can in fact be easily freed when needed in 2.4.20, but I still do not undertsand why it is not freed immediately as it is the case for other applications (or perhaps free is wrong?). The thing is that with 2.4.22 kernel on my Gentoo box, doing emerge or something similar does not seem to free up the memory, but it may be because the gentoo box has twice the memory of RH box.
> 
> I realized that 2.4.20 kernel is still available through portage so I will try it 
> ...

 

I have done that and yes I can run anything I want and it appears to have enough memory without resorting to swap, I just don't like not being able to see what is real. Having memory reporting utilities is useless with this setup.

btw, I found that acpi and 2.4.20 and highmem and nvidia to not co-exist well at all. I am running the kernel without highmem, using the default 3gb split, and without acpi. It appears the acpi code in that kernel is a bit strange. I lose the use of about 100mb ram that way, but everything appars to be more than good, and even though free still is reporting 890mb used after 15 hrs, gkrellm is reporting presently 310mb used which would be very close to my expectations for what I have running at the moment.

Chuck

----------

## mhodak

 *RioFL wrote:*   

>  *mhodak wrote:*   
> 
> In the meantime, can anybody test this freeing behavior, that is to run a big job (emerge, open office, anything that requires lots of memory) and see  if memory was freed (without increasing swap usage)? 
> 
> I have done that and yes I can run anything I want and it appears to have enough memory without resorting to swap, I just don't like not being able to see what is real. Having memory reporting utilities is useless with this setup.
> ...

 

Which kernel is this? Did you see (in free or gkrellm) that the amount of used memory decreased when application was done?

----------

## RioFL

 *mhodak wrote:*   

>  *RioFL wrote:*    *mhodak wrote:*   
> 
> In the meantime, can anybody test this freeing behavior, that is to run a big job (emerge, open office, anything that requires lots of memory) and see  if memory was freed (without increasing swap usage)? 
> 
> I have done that and yes I can run anything I want and it appears to have enough memory without resorting to swap, I just don't like not being able to see what is real. Having memory reporting utilities is useless with this setup.
> ...

 

everything but updatedb reduces memory immediately upon exit. this is kernel 2.4.20-gentoo-r7

I went back to that after running 2.4.22 and having this memory problem.

----------

## ___c___

```

$ uname -a

Linux GEN2 2.4.22-gentoo-r5 #1 Thu Jan 15 21:30:08 CET 2004 i686 AMD Athlon(tm) processor AuthenticAMD GNU/Linux

$ grep "hda3" /etc/fstab

/dev/hda3               /               reiserfs        noatime                 0 0

$ free -m

             total       used       free     shared    buffers     cached

Mem:           756        108        647          0          6         47

-/+ buffers/cache:         55        700

Swap:          517          0        517

$ updatedb

$ free -m

             total       used       free     shared    buffers     cached

Mem:           756        714         41          0        326         51

-/+ buffers/cache:        335        420

Swap:          517          0        517

$ ooffice

$ free -m 

             total       used       free     shared    buffers     cached

Mem:           756        735         20          0        288        108

-/+ buffers/cache:        338        417

Swap:          517          0        517

```

----------

## RioFL

 *___c___ wrote:*   

> 
> 
> ```
> 
> $ uname -a
> ...

 

presently my gkrellm is at 326mb but i have a lot going on. however free has never changed from last night, at least not any noticable amount:

gndmstr@eron gndmstr $ free -m

             total       used       free     shared    buffers     cached

Mem:           881        874          7          0         80        465

-/+ buffers/cache:        327        553

Swap:          486         11        475

i have 1024mb ram but with himem turned off 881 (900) is what the kernel sees. as you can see, free still sees 874mb used, but gkrellm reports 326 which is more in keeping with what i am doing.

----------

## RioFL

Oh, I don't think I ever mentioned, I am running reiserfs on everything but /boot which is ext2

Chuck

----------

## mhodak

Guys, 

I installed 2.4.20 kernel on my Gentoo box and compared it to 2.4.22 kernel. 2.4.20 works better with respect to the updatedb problem. First running updatedb eats less memory (but it still does not release it properly) but when trying after running emerge most of the memory is released. For 2.4.22 kernel  running emerge worsens the situation.

I am about to fill a bug report, do not know what else to do.

----------

## mhodak

Bug submitted as # 38886

https://bugs.gentoo.org/show_bug.cgi?id=38886

Please add your comments so that developers see that I am not the only one  that sees the problem.

----------

## ekoontz

I had this problem also; not knowing what else to do, I tried 2.6.1-rc1, and it seems to have gone away.

I know that doesn't help much with finding out the root cause, but I guess it qualifies as a workaround!  :Smile: 

----------

## mhodak

Great to hear that there is a kernel in which this weird memory behavior was fixed !!!

----------

## tomaw

I seem to still suffer from the memory reporting being wrong in 2.6.1 final - hoping to try 2.6.2 within a few days and see if that has gone anywhere to fixing it...

----------

## RioFL

 *ekoontz wrote:*   

> I had this problem also; not knowing what else to do, I tried 2.6.1-rc1, and it seems to have gone away.
> 
> I know that doesn't help much with finding out the root cause, but I guess it qualifies as a workaround! 

 

never played with the dev sources before because I always thought that they were supposed to be too unstable... i see bugs images on 2.6.1-r1, don't find an rc1, but there is a 2.6.1 that looks like a 'release' so I am going to try that one. 2.4.20 is just too 'backward' for me. I notice it is slightly slower than 2.4.22, video isn't as crisp and of course memory management is worse with buggy highmem code.. so I am going to try the 2.6.1 this morning and see what it does.  

My biggest concern is if I switch to this, can I still go backward to lower versions? I heard somewhere that 2.6.1 did away with devfs which is the core of my system.

Chuck

----------

## ekoontz

RioFL, devfs seems to be considered deprecated in 2.6, but still you can choose it (as I did), and it seems to work fine.

You can still boot older kernels; devfs doesn't change anything permanently about the /dev directory as far as I Know. (it just creates /dev entries dynamically which go away at the next boot).

tomaw, here's some data; i've been up for 4 days so updatedb has been running every night through cron..

(the load is high because I'm emerging a bunch of stuff  :Smile:  )

```

hiro-tan(ekoontz)[~] $ uptime

 09:15:25 up 4 days,  8:11,  2 users,  load average: 1.01, 1.07, 1.06

hiro-tan(ekoontz)[~] $ free -m

             total       used       free     shared    buffers     cached

Mem:           216        203         12          0         21         85

-/+ buffers/cache:         96        120

Swap:         1027         60        967

hiro-tan(ekoontz)[~] $ uname -a

Linux hiro-tan.org 2.6.1-rc1 #1 SMP Fri Jan 16 00:04:54 PST 2004 i686 VIA Samuel 2 CentaurHauls GNU/Linux

```

----------

## RioFL

 *ekoontz wrote:*   

> RioFL, devfs seems to be considered deprecated in 2.6, but still you can choose it (as I did), and it seems to work fine.
> 
> You can still boot older kernels; devfs doesn't change anything permanently about the /dev directory as far as I Know. (it just creates /dev entries dynamically which go away at the next boot).
> 
> tomaw, here's some data; i've been up for 4 days so updatedb has been running every night through cron..
> ...

 

I put it in and am not using devfs. Decided to get into the spirit of 2.6.1 and 'go with the flow'. Everything appears to work just fine except my sensors and my logitech quickcam module which won't compile now. They eliminated LM80 sensors although the VIAPro stuff is in there, gkrellm isnt seeing the sensors at all:( will have to research it. Outside of that, my video is better, everything seems quicker.

 Unfortunately the updatedb problem is still there so for now I have decided to eliminiate it from the nightly run and I will run it manually then reboot right after.. maybe a few times a week.  

Only other problem I see which isnt really a problem, is the boot script warns me devfs is not installed, but it does not appear to affect anything.

Chuck

----------

## mhodak

Guys,

I checked Kernel mailing list to see if there were any replies to the post with our problem, but there are none, which means that there is no solutiom or explanation for the problem we are experiencing. Considering that this exists even in 2.6 kernels I would really like to see an explanation from somebody who knows about kernel memory management.  

I am thinking about posting there our problem again, it may get noticed.

On the other hand, my machine has 10 days uptime now, I do updatedb everyday and besides having almost 100% used memory (reported by gkrellm), it does not seem to affect me.

----------

