Whenever I've tried to upgrade to RC16C after about 1/2 hour, the system comes to a complete grinding halt.  Network shares are unavailable, the GUI is not available, I cannot telnet into the system, nor is my attached keyboard responsive at all.  A hard reset is the only thing that works.

 

I was thinking that it was possibly a network (driver) issue, so I added a Intel PCI NIC card to force the system to use a different driver other than the one for my built-in realtek NIC to no avail.

 

When I downgrade to RC11 (the last version which I found worked best on my system) all of the problems disappear.

 

Also, the only add-ons which I use are Cache_Dirs, and Unmenu.  Beyond that everything else is 100% stock.

 

Memtest over night shows no problems.

 

This is about the 3rd time that I have tried this upgrade, and each time has had the same result.

 

This may be a really stupid question, but how can I grab the syslog to attach here when the system crashes so hard that I can't access anything on it?  Is there a way to capture it to another file as its created?

 

The hardware is:

 

MB: Gigabyte A75M-UD2H

Ram: 4 Gig DDR3

P/S: 750W OCZ (Customized wiring to utilitize 12V from the PCIE connectors)

16 HDD

 

There are some other plugins which unmenu is still loading, even in safemode (acupsd, clean powerdown, status email, etc)

 

This may be some sort of OOM problem that is happening.  How can I capture the syslog when this problem happens?

 

It will be a lot easier to diagnose for me to see what was happening rather than trying to disable one at a time to see where the issue is.

See my sig to disable all add-ons. Then upgrade. Re-enable half of the add-ons. It should take at most (log₂n)+1 trials to determine the offending add-on, where n is the number of add-ons.

I knew that best way was to disable all add-ons, and did try  safe mode, but still noticed that there were other items running.

 

What I was really looking for was some way to capture the syslog in a situation like this.

 

But, seeing as how it was a safe assumption that it was an OOM causing this, I thought about what was chewing up memory, and Cache_dirs is about it.

 

I've set the cache_pressure to be 100 which as I understand it will prevent the kernel from ever killing processes, and it seems to be working...  RC16C is still running after 16 odd hours, which is by far the best result I've had.

 

What puzzles me however is why RC11 does not crash with the cache_pressure set to the default of 10, and RC16C does.  The different kernals must be handling the OOM differently.

I've set the cache_pressure to be 100 which as I understand it will prevent the kernel from ever killing processes,

You are very incorrect about how (and what) cache-pressure is used for.    It has absolutely nothing to do with the kernel oom process killer.