Happens to Me too, it appears Micro$oft has been shoving down function calls since 1995 to make sure you have the right ram. I have 320Mb, set to imitate winme, but my M$ apps say I still don't have enough Andreas Mohr wrote:
On Sun, Aug 25, 2002 at 08:17:09AM -0400, Ian D. Stewart wrote:
On 2002.08.18 12:21 Andreas Mohr wrote:
On Sun, Aug 18, 2002 at 11:32:54AM -0400, Ian D. Stewart wrote:
After running Wine for awhile, /proc/meminfo reports MemTotal as
32680
kb. The system performs as if it only had 32 MB of RAM. A reboot
of
the system resets total memory to the proper value.
My question is:
- Has anybody else encountered this?
- Does anyone know what causes this, or better yet how to avoid it?
- Is there anyway to recover the lost RAM short of a reboot?
Huh ? This is very, very, VERY strange ! Something like this should never happen. Are you sure it's caused by Wine only, or maybe it is due to faulty memory instead ? (and thus the board/Linux notices that only 32MB are useable and resorts to accessing 32MB only).
Well I can't say with absolute certainty that it's caused by Wine, but the system runs without any problems for extended periods of time so long as I don't run Wine, and consistently 'loses' memory when I *do* run wine.
I don't know exactly what's going on. I do know that there appears to be some sort of threshold that is reached at which point the memory hiding occurs (e.g., the same issue arises whether I run Wine for 5 hours at one shot or for 30 minutes a day for 10 days) and the threshold isn't 'reset' until I reboot.
Again, I'm utterly puzzled when hearing such a story. Or maybe Wine accesses some Linux memory management function in some way that causes Linux to tamper with the value for some reason ? This wouldn't be the first time that Wine is the only program to reveal some severe bug in Linux memory management...
Definitely try upgrading your kernel, too.
I have no problem with upgrading, but I would like to know *why* I am upgrading (i.e., what bug is causing the problem, and how does the new kernel address the bug). To do otherwise strikes me as being equivelant to the tendency in the Windows community whenever something odd happens.
*sigh* You're definitely not of the easy kind of people, are you ? ;-) A lot of people would just upgrade and be happy in case the bug is fixed, but you... :)
Well, if you're so eager to learn what the problem is, then I'd suggest to get your hands pitch black dirty immediately ;-)
Find out where /proc/meminfo gets fed with values, then find out which part messes with the MemTotal value in any way.
Hmm, arch/i386/mm/init.c/si_meminfo() sounds like a sure winner. I'd suggest looking for the totalram_pages variable (add logging whenever that one gets modified in some way). OTOH I don't see any place where there is a direct assignment of that variable. Hmm, where does that variable even get initialized then ??? (well, probably declaration auto initialization then)
Oh well, good luck ! ;)