RAM Issue

[Guest]

I've been running Vista Ultimate on 2GB of RAM fine but decided to upgrade to
4GB because the prefetch cache got up to 1.4GB. My BIOS reports 4075MB of
installed and useable RAM. Supports up to 8GB.

Windows Vista only reports 3528MB RAM and results in a Blue Screen crash
when logging in or shortly afterwards. I tested the 2 new SIMS by themselves
and tried combinations of the original 2 SIMS and either of the 2 new SIMS to
make 3GB. Windows reports 3GB of RAM and runs fine.

I was wondering if there was an issue with a certain amount of memory the OS
can work with at this point. I'm running Vista Ultimate with the latest OS
updates.

 

[BigJim]

windows 32 bit can only access about 3.5 meg of memory if you want to run
more
you need the 64 bit OS.

 

[Guest]

2^32 is 4294967296 which is 4096MB and each memory location is a single byte.
Considering my WinXP box has 4GB of ram and works fine, also supports this.
There is a similar post to mine a few down where someone tried putting 4GB in
and it crashed.

 

[Richard Urban]

If your system is crashing when you install the extra RAM you must look at
the manual for your M/B to determine what the RAM specifics are. All 1 gig
sticks RAM are not the same. Some are single sided. Some are double sided.
There are timing frequencies. The list goes on.

--


Regards,

Richard Urban
Microsoft MVP Windows Shell/User
(For email, remove the obvious from my address)

 

[Guest]

In my original post, I made it clear that the BIOS properly recognised the
memory. All 4 SIMS are 667MHz and both memory channels have matched SIMS. The
conditions can't be any more ideal.

The mother board supports 800/667 etc with up to 8GB addressed at 64-bits. I
also stated that i'm using 3 SIMS for now. The original pair and a single sim
in the second memory channel making it 3GB. I've tested both SIMS and they're
fine.

The obvious question is, why is there a discrepency between the BIOS and
Windows in terms of the amount of memory that is installed in the machine?
BIOS reporting 4072 and Windows reporting 3582 with all four SIMS and both
reporting 3000 with 3 SIMS.

Having been a developer on every version of Windows since Windows for
Workgroups 3.11, i'm more inclined to believe it's a teething problem.

 

[Richard Urban]

The fact that the bios recognizes the RAM means nothing to Windows. Vista
works the RAM much more intensely than any previous version of Windows ever
did. If you don't have "precisely" ***matched*** RAM - you may well have
problems.

I previously had 2-500 meg sticks of matched RAM. I wanted to move to 2 gig
of RAM. I purchased 2 NEW 1 gig sticks of RAM (at the same time to be
certain they even came from the same date/batch/lot). I could have just
purchased a single 1 gig stick and I would have had 2 gig. The RAM would NOT
have been matched - even though it was all identified in the bios.

--


Regards,

Richard Urban
Microsoft MVP Windows Shell/User
(For email, remove the obvious from my address)

 

[Steve Thackery]

Andrew,

I'm not sure you're really listening to the previous responders. I'll spell
it out...

32-bit Vista can only address 4G of memory addresses in total.
Memory-mapped I/O must sit inside this 4G address range, Depending on what
you've got by way of hardware, the top half to three quarters of a Gig in
the 4G address range is used by the memory-mapped I/O. The video card is
the biggest user of memory-mapped I/O.

So, even though you have 4G of RAM, the top 0.5 to 0.75 Gig is disabled
because it occupies the same address range as the video card, et al.

There are two ways to get round this:

1/ Install Vista 64 bit. This can address much more than 4G, so the I/O is
moved out of the way of the physical RAM.

2/ Some BIOSs support remapping, which requires a 64-bit processor (which
I'm sure yours will be). I don't know for sure whether it moves the I/O up
above 4G, or some of the physical memory, but basically it allows Vista to
see all 4G of physical memory AND the memory-mapped I/O. Only some
motherboards/BIOSs support this - mine doesn't.

Steve

 

[Guest]

Workload isn't the issue. Especially when the addresses of the 2nd two gigs
is far out of the range of startup memory requirements. The OS uses the BIOS
to determine the amount of ram, PCI devices and drives etc. Considering that
it hasn't had a problem with any other hardware devices, it seems to be a
very specific issue. Especially since the methodology of addressing memory is
static for any OS running on the machine. Fetching and setting is managed by
the mother board.

Hardware performance failure due to stress is generally a result of
overclocking heat or external heat and in both cases, I take carefull
measures to ensure I don't overclock or expose the chassis to heat. Under
these conditions, RAM only fails if it is physically damaged and a read
instruction occurs in an area that a DDR transistor circuit has failed.

Rather than pinning the blame on something in particular, I'd be more
interested to find out the discrepency in total memory installed. Allthough I
use .Net framework and Server 2003 religiously, i'm poking MS in the belly on
this one. Handballing it off to the mother board or precisely matched SIMS
isn't a reasonable conclusion.

 

[Guest]

Steve,

If you've done a bit of assembly programming or even C programming, all
memory addresses used for programs are 100% RAM. Hardware interfaces are done
through hardware interrupts or CPU registers and stack pointers. They can
share the same address from time to time but the CPU can differentiate
between RAM, I/O, stack and ALU defined by a previous instruction loaded into
the CPU. The full 32-bit address is loaded into a register when addressing
memory. There is no debate about that. 32 bits can address 4096MB of RAM.

You are correct in the concept of the video card requiring static memory
mapping. This is why the first 16MB of RAM is reserved for the OS. Other
reserved memory addresses like 0x00 are used for NULL pointer references.
Regardless of how much memory the OS needs reserved for operation, 4GB of RAM
are still addressable. The fact still remains that my 32-bit XP box has 4GB
of memory registered with the OS and working fine. Even though Vista
implements Pre-Fetching, this is still just reserved RAM to improve the
performance of reguarly used applications.

In terms of video card memory, i've been programming 3D video card
interfaces since the Voodoo 2 came out using the Glide API. I've also used
OpenGL and Direct3D. All texture and pipeline memory is addressed through the
hardware interrupt. Serialised data is sent to the video card and it manages
memory from there. Not the OS. Textures are serialised to the video card and
memory is allocated for the mip-map/bump-map at the video card end of
computations.

Having studied 4 years of Digital Systems as part of my engineering degree,
it might appear that i'm not really listening to what other posters have to
say. It's more a situation that the replies didn't take all the simple facts
stated.

Andrew

 

[jorgen]

Steve,

If you've done a bit of assembly programming or even C programming, all
memory addresses used for programs are 100% RAM.

Not true. You don't address RAM, you address the CPU's memory space. And
in PC architecture, not all addresses in this memory space points to RAM

 

[Guest]

Apart from the ambiguous wording, you didn't read passed the first sentence.

"Hardware interfaces are done through hardware interrupts or CPU registers
and stack pointers. They can share the same address from time to time but the
CPU can differentiate between RAM, I/O, stack and ALU defined by a previous
instruction loaded into the CPU. The full 32-bit address is loaded into a
register when addressing memory. There is no debate about that. 32 bits can
address 4096MB of RAM."

CPU's dont have "memory spaces". They're interpreters and routers with
number crunching capabilities. It knows how to route data to different
sub-systems based on defined "key-words" in the CPU architecture. The
proceeding data has no meaning to the CPU and is routed to the relevent
sub-system. The only memory in the CPU is the stack which keeps track of
programme flow. Any other types of "memory" in the CPU are considered
enhancements to improve speed.

 

[jorgen]

"Hardware interfaces are done through hardware interrupts or CPU registers
and stack pointers. They can share the same address from time to time but the
CPU can differentiate between RAM, I/O, stack and ALU defined by a previous
instruction loaded into the CPU. The full 32-bit address is loaded into a
register when addressing memory. There is no debate about that. 32 bits can
address 4096MB of RAM."

CPU's dont have "memory spaces". They're interpreters and routers with
number crunching capabilities. It knows how to route data to different
sub-systems based on defined "key-words" in the CPU architecture. The
proceeding data has no meaning to the CPU and is routed to the relevent
sub-system. The only memory in the CPU is the stack which keeps track of
programme flow. Any other types of "memory" in the CPU are considered
enhancements to improve speed.

Of course the CPU has a memory space (memory space is not RAM). All
units have it's own memory space. A memory map describes how the memory
space is populated.

When you send out an address on the bus, the CPU doesn't deside if goes
to the IO subsystem or the memory controller. That's the point.

 

[Guest]

Andrew,

The following Microsoft article explains the issue more fully:

http://support.microsoft.com/kb/929605/

Note that one of the KEY requirements is that you must have the "remapping"
feature in BIOS.

 

[Richard Urban]

Again, aside from the total RAM question, if you don't have ***MATCHED***
RAM you "may" have problems. I have seen it often. So have many other techs.

--


Regards,

Richard Urban
Microsoft MVP Windows Shell/User
(For email, remove the obvious from my address)

 

[Steve Thackery]

Andrew, you've completely confused me.

Either you know the answer to your own question (or you think you do) - in
which case why ask it? Or you don't know the answer to your question, in
which case why reject everyone who offers help?

Even so, you've raised a really interesting point. If you have an XP system
with 4G of RAM, and it really and genuinely can see and use all of it, then
the "received wisdom" that memory-mapped I/O takes up some of that 4G in
Vista must be wrong. XP and Vista ought to work the same.

However, I'm prepared to bet that you are mistaken about your XP system.

Are you sure you understand the difference between the I/O address space and
the memory address space?
The early Intel processors had an address bus and a data bus which went to
both the system RAM and the various I/O devices. A separate line (on the
8086 it's pin 28 - M/IO) signalled to the surrounding electronics whether
the processor was reading/writing to I/O space or memory space, and it
switched the chip enable signals appropriately.

Memory addresses and I/O addresses are quite different, and you can instruct
the processor to read address $0100 in the I/O space, or address $0100 in
the memory space, and they are completely different.

You are right to say that I/O that sits in the I/O map doesn't clash or
overlap in any way with memory at the "same" address, because it isn't
really the "same" address at all - they are in completely different maps -
as signalled by that M/IO line.

BUT - with your experience you MUST have come across the situation where I/O
sits in the normal MEMORY map, NOT the I/O map. This is the case with the
memory on the video card: it sits in the memory space, not the I/O space.
Whenever this occurs your address decoding hardware must disable the RAM
that occupies that same address, otherwise both the system RAM and the video
RAM will try to read/write to the bus at the same time.

I'm sure you know this already, so why are you arguing about it?

Steve

 

[Guest]

Of course the CPU has a memory space (memory space is not RAM). All
units have it's own memory space. A memory map describes how the memory
space is populated.

The only memory a CPU has fundamentaly is the stack which contains program
counter pointers to restore programme flow in nested functionality. It has no
idea whatsoever what the contents is of the RAM is and what it is used for.
That is the role of the OS and the software threads.

When you send out an address on the bus, the CPU doesn't deside if goes
to the IO subsystem or the memory controller. That's the point.

No, when you put an address on a bus, regardless of whether it is a polled
bus, round robin or arbitrated bus, every device on that bus compares the
transmitted address to it's own address and responds accordingly. The role of
the CPU is to route information based on what it's target is. The
RISC(Reduced Instruction Set Controller) or CISC(Complex Instruction Set
Controller) CPU can distinguish between RAM usage, register usage, ALU usage
and I/O usage.

E.G. To write to RAM, 3 fundamental data words are required. The first being
the RISC/CISC instruction to tell the CPU that you are writing to memory(
equivelant ASM symbol is "SET"). Second being the 32 bit memory address. 3rd
being the 8-bit byte representing the data to be stored.

You can't seriously believe that an address is unique and corresponds to a
specific action. There are many arbitration buses on a mother board. Each bus
may share an address with a neighbouring bus. The thing that distinguishes
one address from another is the CPU instruction set instruction that is
administered to the CPU. Study LSI and CPU architechture and you'll
understand that the point isn't as obvious as you think.

 

[jorgen]

You can't seriously believe that an address is unique and corresponds to a
specific action. There are many arbitration buses on a mother board. Each bus
may share an address with a neighbouring bus. The thing that distinguishes
one address from another is the CPU instruction set instruction that is
administered to the CPU. Study LSI and CPU architechture and you'll
understand that the point isn't as obvious as you think.

I don't really wanna argue this anymore, it gets tiresome. But look op
what "memory mapped I/O" means.

 

[Richard Urban]

You seem to know a lot about computers, address space etc.

Why are you even asking this question? You "know" the answer. You have
almost stated as much.

--


Regards,

Richard Urban
Microsoft MVP Windows Shell/User
(For email, remove the obvious from my address)

 

[Guest]

Andrew, you've completely confused me.

Either you know the answer to your own question (or you think you do) - in
which case why ask it? Or you don't know the answer to your question, in
which case why reject everyone who offers help?

To be honest Steve, I expected this forum to be more of a
discussion/exposure forum which I am used to in terms of development. The
original argument being that my system crashes with 4GB of RAM. I'm quite
aware that properly developed arguments in forums are recognised by
developers of the software in question. This being Windows Vista. The grounds
of argument being a suitable rebutle to defend my simple request of
investigating an issue without doubt.

Even so, you've raised a really interesting point. If you have an XP system
with 4G of RAM, and it really and genuinely can see and use all of it, then
the "received wisdom" that memory-mapped I/O takes up some of that 4G in
Vista must be wrong. XP and Vista ought to work the same.
Correct

However, I'm prepared to bet that you are mistaken about your XP system.

Are you sure you understand the difference between the I/O address space and
the memory address space?

It is a fundamental, professional obligation of mine to understand the
difference.

The early Intel processors had an address bus and a data bus which went to
both the system RAM and the various I/O devices. A separate line (on the
8086 it's pin 28 - M/IO) signalled to the surrounding electronics whether
the processor was reading/writing to I/O space or memory space, and it
switched the chip enable signals appropriately.

Regardless of different types of archtechture, the goal has always been the
same. Differentiate between relevent buses via the use of an instruction set.
If the primative bus system was shared, it still remains that certain signals
on that bus accompanied by the address/data had a meaningfull obligation to
distribute the data/action to the appropriate destination at the discretion
of the CPU.

Memory addresses and I/O addresses are quite different, and you can instruct
the processor to read address $0100 in the I/O space, or address $0100 in
the memory space, and they are completely different.
Correct

You are right to say that I/O that sits in the I/O map doesn't clash or
overlap in any way with memory at the "same" address, because it isn't
really the "same" address at all - they are in completely different maps -
as signalled by that M/IO line.

And the data flow to each address exists on separate sub systems routed by
the CPU and goverened by the programme CPU instruction.

BUT - with your experience you MUST have come across the situation where I/O
sits in the normal MEMORY map, NOT the I/O map.

Don't think if RAM being mapped as the contents of memory generally contains
abstract data types and can only be intepreted by the programme accessing the
memory.

It is quite common at assembly level or even C to store I/O addresses in
memory. It is purely for the sake of functions to know where to send
information. Whether it be the I/O interrupt for video or sound etc. Take
note of the difference between RAM addresses and I/O interrupts.

This is the case with the
memory on the video card: it sits in the memory space, not the I/O space.
Whenever this occurs your address decoding hardware must disable the RAM
that occupies that same address, otherwise both the system RAM and the video
RAM will try to read/write to the bus at the same time.

Although the memory BITMAP generated by the OS exists in RAM, this does not
explain your estimation of 500MG. A typical high resolution display would be
1900x1200. Each pixel having 24bits of information padded out to 32 bits for
processing speed. The total screen bitmap would be roughly 8.7MB of RAM.

Although with some BIOS chipsets it is possible to assign RAM as texture
memory via the nForce co-processor in the event of a lack of texture memory
on the video card, the motherboard I am using does not. Take note that it
only involves texture memory and nothing else and only applies to 3D
applications.

I'm not sure where people get the idea that RAM addresses are reserved for
video card memory addresses as some type of easy by-pass method to write to
video RAM. As stated in another post of mine, all texture or pipeline data is
serialised on the PCI bus and the video card understands how to interpret the
information that has been coded by the video card drivers and parsed to the
CPU as an I/O instruction directed at the interrupt of the video hardware.
The usage of the word interrupt is essential as only a single instruction is
processed by the CPU at any one time. The use of hardware and software
interrupts are used to determine if the CPU is able to address a sub-system
at that point in time or if it has to wait till other sub-systems on the same
target bus are finished.

I'm sure you know this already, so why are you arguing about it?

Steve

As stated earlier, creating a cause for investigation without doubt. As
always, dicussions blow out into almost irrelevant tangents. Dispite any
knowledge that I may have, I am not the distributer of Windows Vista or a
developer of it. I'm simply creating a discussion about it and it is almost
certain that ignorance brings about solutions that I have already considered
myself and found to be not applicable. I am ignorant as to how I will get
around this problem which is why am here but I am not here to ask questions I
already know the answer to.

 

[Guest]

Thankyou very much for this article. Although it explains the discrepency I
have, it doesn't solve the OS crashes.