Vista - RAM Issue

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" wrote:

> Andrew McNab wrote:
> > 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
>

Andrew McNab wrote:

> "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.

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.
--
freddy


"Andrew McNab" wrote:

> 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.

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)



"Andrew McNab" <AndrewMcNab@discussions.microsoft.com> wrote in message
news:557DFF27-EAB7-4364-9ABF-BB57323E5EF8@microsoft.com...
> 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.
>
> "Richard Urban" wrote:
>
>> 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)
>>
>>
>>
>> "Andrew McNab" <AndrewMcNab@discussions.microsoft.com> wrote in message
>> news:AB2FB012-2807-46C5-B9B3-5D61141976D0@microsoft.com...
>> > 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" wrote:
>> >
>> >> 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)
>> >>
>> >>
>> >>
>> >> "Andrew McNab" <AndrewMcNab@discussions.microsoft.com> wrote in
>> >> message
>> >> news:C28EC6C8-EAE6-4087-8C8D-F8354E669D18@microsoft.com...
>> >> > 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.
>> >>
>> >>
>>
>>

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

> 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.

Andrew McNab wrote:

> 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.

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)



"Andrew McNab" <AndrewMcNab@discussions.microsoft.com> wrote in message
news:C28EC6C8-EAE6-4087-8C8D-F8354E669D18@microsoft.com...
> 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.

"Steve Thackery" wrote:

> 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.

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

"freddy" wrote:

> 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.
> --
> freddy
>
>
> "Andrew McNab" wrote:
>
> > 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.