__ said:
Hello All,
I don't know if this is Windows or hardware, but I have an old Dell
laptop and it came with 128 MB of RAM and I upped it to 384 with a 256
MB chip. The problem is that every other reboot on average, it gives the
"amount of memory has changed" and it will go down to 128 or back up to
384. I would wonder if the memory isn't tight in the slot but it's in a
docking station and not getting moved. Any ideas appreciated, the box
is already slow at 384, at 128 it's just unbearable.
The BIOS is the part of the process, that detects memory and
sets up the address map. As far as I know, the OS cannot
redefine (bump up) the size of memory, after the BIOS has
done its part. You can add an option to limit the amount
of memory the OS uses (bump down), but that is not
necessarily changing any Northbridge registers. That
would just be a matter of not using all the memory that
has been set up.
In terms of the process the BIOS carries out, the
BIOS is pretty careful to only set up things that
have been detected. For example, the BIOS reads the
tiny SPD (serial presence detect) chip on each DIMM,
and the information in there says what the size of
the memory is. But based on what happened to one person,
the BIOS also appears to double check what it has read,
by using the older methods of verifying the size of
memory (write to the memory, and then try and read
back the value written). When the BIOS is finished, it
should be pretty sure what size the memory is, because
it did a binary search to find the end.
Now, a minor bookkeeping issue, is DMI and ESCD. On modern
motherboards, these two things are written to the BIOS flash
chip, on any occasion where the amount and type of hardware
has changed. So, if you had one stick of RAM, and you added
a second, then on the POST after the second stick was added,
the BIOS would say "updating ..." and it would write out the
hardware inventory to the BIOS chip. The DMI information,
is used for such purposes as remote surveillance, where a
system administrator in a large company, can check the
hardware content of computers daily, to detect if company
assets have gone missing. (Not that it would be a workable
idea or anything.)
I'm not aware of any feedback in the reverse direction,
where the information content of DMI or ESCD, does anything
to the RAM detection process. I thought the information flow
was unidirectional, and the DMI/ESCD is not touched, unless
a new hardware inventory detected, requires it to be updated.
Options -
1) If both the 128MB and 256MB are SODIMMs, and one of them
isn't soldered to the motherboard, then you could swap them.
Some BIOS, when bugs show up, are size/order dependent. And
sometimes, if you change the order of the sticks of RAM, the
errant behavior disappears. While at least some computing
products receive BIOS updates to correct bugs, sometimes a
workaround like this, is all that is available to try.
2) I don't see a reason for this to be related to the CMOS or
be affected by "clearing the CMOS". But clearing the CMOS
is something else you could try. I didn't think any aspect
of memory or quantity of memory, is stored in the CMOS.
Things like the boot order might be stored in there.
3) Another possible workaround, if the behavior is predictable,
is to boot twice. The first time, it boots to the 128MB case,
and the second time, it boots to 384MB. If you want to speed
up the process a bit, you could use a memtest86+ test disc,
from memtest.org , as it boots reasonably quickly, and also
has an indicator on the screen, that prints out the total
amount of memory detected. Pressing <esc>, once the memtest
screen appears, would cause the machine to reboot, and the
second time, you could remove the memtest86+ boot media, leaving
the hard drive to do the booting on the second attempt.
I realize such a workaround is not a solution, but if you cannot
come up with another theory, then it may be all you've got to
work with.
Post back if you get any new symptoms, because I learn about
BIOS behavior, as a result of cases like this
HTH,
Paul
