Wine Hides On-board RAM
Andreas Mohr
andi at rhlx01.fht-esslingen.de
Sun Aug 25 06:38:03 CDT 2002
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:
> > >
> > > 1) Has anybody else encountered this?
> > > 2) Does anyone know what causes this, or better yet how to avoid it?
> > > 3) 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 ! ;)
--
The Declaration of Software Freedom:
http://freedevelopers.net/freedomdec/index.php
More information about the wine-users
mailing list