Hi guys,
I installed 4 x 1 GB DDR2 memory in my Intel Dual-Core 2.80GHz system,
but it shows me only 3.3 GB of RAM:
Memory: 3339124k/3398656k available (2029k kernel code, 56232k reserved,
741k data, 184k init)
The BIOS and dmidecode tells me that I have 4 GB of RAM installed and I
don't have any idea where to look for details. What information do you
need to analyze this?
Regards
Marcel
Marcel> The BIOS and dmidecode tells me that I have 4 GB of RAM
Marcel> installed and I don't have any idea where to look for
Marcel> details. What information do you need to analyze this?
Look at the e820 dump in your kernel bootlog. I'll bet you'll see a
big chunk of reserved address space. Do you have any PCI devices like
video cards that use a lot of PCI address space?
I don't know if EM64T systems (or whatever the right term is) have a
way of remapping some RAM above 4 GB so that you can use all your
memory in a case like this.
- R.
Hi Roland,
> Marcel> The BIOS and dmidecode tells me that I have 4 GB of RAM
> Marcel> installed and I don't have any idea where to look for
> Marcel> details. What information do you need to analyze this?
>
> Look at the e820 dump in your kernel bootlog. I'll bet you'll see a
> big chunk of reserved address space. Do you have any PCI devices like
> video cards that use a lot of PCI address space?
BIOS-provided physical RAM map:
BIOS-e820: 0000000000000000 - 000000000009fc00 (usable)
BIOS-e820: 000000000009fc00 - 00000000000a0000 (reserved)
BIOS-e820: 00000000000edbb0 - 0000000000100000 (reserved)
BIOS-e820: 0000000000100000 - 00000000cec11000 (usable)
BIOS-e820: 00000000cec11000 - 00000000cee12000 (ACPI NVS)
BIOS-e820: 00000000cee12000 - 00000000cf68f000 (usable)
BIOS-e820: 00000000cf68f000 - 00000000cf6e9000 (ACPI NVS)
BIOS-e820: 00000000cf6e9000 - 00000000cf6ed000 (usable)
BIOS-e820: 00000000cf6ed000 - 00000000cf6ff000 (ACPI data)
BIOS-e820: 00000000cf6ff000 - 00000000cf700000 (usable)
I see the stuff above, but the system doesn't contain any PCI device. I
didn't install a PCI-Express video card, because I still use the onboard
card.
> I don't know if EM64T systems (or whatever the right term is) have a
> way of remapping some RAM above 4 GB so that you can use all your
> memory in a case like this.
The kernel is compiled for x86_64 and the term EM64T is correct. The
important question is now how do I remap that memory. Loosing almost a
full GB of memory wasn't my plan when upgrading to 4 GB.
Regards
Marcel
On Thu, 27 Oct 2005 13:44:19 -0700, Roland Dreier wrote
> Marcel> The BIOS and dmidecode tells me that I have 4 GB of RAM
> Marcel> installed and I don't have any idea where to look for
> Marcel> details. What information do you need to analyze this?
>
> Look at the e820 dump in your kernel bootlog. I'll bet you'll see a
> big chunk of reserved address space. Do you have any PCI devices
> like video cards that use a lot of PCI address space?
>
> I don't know if EM64T systems (or whatever the right term is) have a
> way of remapping some RAM above 4 GB so that you can use all your
> memory in a case like this.
I think this always shows this amount of RAM. Windows does the same thing
AFAIK. It's basically some sort of limitation and the motherboard reports an
specific amount of memory.
There is a deeper reason, ask google.
(IA32 does not support all that much RAM, so it shows like 3.xxGB RAM but uses
the rest for System Resources like Video, PCI, bla bla)
EM64T is not really 64Bit so, is still IA32.
.Alejandro
> BIOS-provided physical RAM map:
> BIOS-e820: 0000000000000000 - 000000000009fc00 (usable)
> BIOS-e820: 000000000009fc00 - 00000000000a0000 (reserved)
> BIOS-e820: 00000000000edbb0 - 0000000000100000 (reserved)
> BIOS-e820: 0000000000100000 - 00000000cec11000 (usable)
> BIOS-e820: 00000000cec11000 - 00000000cee12000 (ACPI NVS)
> BIOS-e820: 00000000cee12000 - 00000000cf68f000 (usable)
> BIOS-e820: 00000000cf68f000 - 00000000cf6e9000 (ACPI NVS)
> BIOS-e820: 00000000cf6e9000 - 00000000cf6ed000 (usable)
> BIOS-e820: 00000000cf6ed000 - 00000000cf6ff000 (ACPI data)
> BIOS-e820: 00000000cf6ff000 - 00000000cf700000 (usable)
If that's the full e820 map, then I guess the question is why did the
BIOS not tell you about any memory above 0xcf700000?
And I have no idea why it wouldn't. For comparison, here's an AMD64
system I have with 4 GB of RAM. Notice how it put a big chunk of RAM
above 4G:
BIOS-e820: 0000000000000000 - 0000000000098800 (usable)
BIOS-e820: 0000000000098800 - 00000000000a0000 (reserved)
BIOS-e820: 00000000000c2000 - 0000000000100000 (reserved)
BIOS-e820: 0000000000100000 - 00000000bff20000 (usable)
BIOS-e820: 00000000bff20000 - 00000000bff2a000 (ACPI data)
BIOS-e820: 00000000bff2a000 - 00000000bff80000 (ACPI NVS)
BIOS-e820: 00000000bff80000 - 00000000c0000000 (reserved)
BIOS-e820: 00000000d8800000 - 00000000d8800400 (reserved)
BIOS-e820: 00000000d8801000 - 00000000d8801400 (reserved)
BIOS-e820: 00000000e0000000 - 00000000f0000000 (reserved)
BIOS-e820: 00000000fec00000 - 00000000fec00400 (reserved)
BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved)
BIOS-e820: 00000000fff80000 - 0000000100000000 (reserved)
BIOS-e820: 0000000100000000 - 0000000140000000 (usable)
- R.
Hi Alejandro,
> > Look at the e820 dump in your kernel bootlog. I'll bet you'll see a
> > big chunk of reserved address space. Do you have any PCI devices
> > like video cards that use a lot of PCI address space?
> >
> > I don't know if EM64T systems (or whatever the right term is) have a
> > way of remapping some RAM above 4 GB so that you can use all your
> > memory in a case like this.
>
> I think this always shows this amount of RAM. Windows does the same thing
> AFAIK. It's basically some sort of limitation and the motherboard reports an
> specific amount of memory.
>
> There is a deeper reason, ask google.
>
> (IA32 does not support all that much RAM, so it shows like 3.xxGB RAM but uses
> the rest for System Resources like Video, PCI, bla bla)
>
> EM64T is not really 64Bit so, is still IA32.
the board in this system is a Intel D945GNT and the box tells me the
maximum supported amount of RAM is 4 GB. So there should be a way to
address this amount memory.
Regards
Marcel
On Thu, 27 Oct 2005 22:51:18 +0200, Marcel Holtmann wrote
> Hi Roland,
>
> > Marcel> The BIOS and dmidecode tells me that I have 4 GB of RAM
> > Marcel> installed and I don't have any idea where to look for
> > Marcel> details. What information do you need to analyze this?
.....
>
> The kernel is compiled for x86_64 and the term EM64T is correct. The
> important question is now how do I remap that memory. Loosing almost
> a full GB of memory wasn't my plan when upgrading to 4 GB.
This is pretty much how it works. Else, purchase an Itanium system. ;-)
EM64T != IA64
.Alejandro
>
> Regards
>
> Marcel
Hi Roland,
> > BIOS-provided physical RAM map:
> > BIOS-e820: 0000000000000000 - 000000000009fc00 (usable)
> > BIOS-e820: 000000000009fc00 - 00000000000a0000 (reserved)
> > BIOS-e820: 00000000000edbb0 - 0000000000100000 (reserved)
> > BIOS-e820: 0000000000100000 - 00000000cec11000 (usable)
> > BIOS-e820: 00000000cec11000 - 00000000cee12000 (ACPI NVS)
> > BIOS-e820: 00000000cee12000 - 00000000cf68f000 (usable)
> > BIOS-e820: 00000000cf68f000 - 00000000cf6e9000 (ACPI NVS)
> > BIOS-e820: 00000000cf6e9000 - 00000000cf6ed000 (usable)
> > BIOS-e820: 00000000cf6ed000 - 00000000cf6ff000 (ACPI data)
> > BIOS-e820: 00000000cf6ff000 - 00000000cf700000 (usable)
>
> If that's the full e820 map, then I guess the question is why did the
> BIOS not tell you about any memory above 0xcf700000?
yes, that's it. Attached is the full dmesg of the last boot.
Regards
Marcel
On Thu, 27 Oct 2005 22:57:47 +0200, Marcel Holtmann wrote
> Hi Alejandro,
>
> the board in this system is a Intel D945GNT and the box tells me the
> maximum supported amount of RAM is 4 GB. So there should be a way to
> address this amount memory.
Marcel,
The board did take the 4GB of RAM and it is finding them, therefore supports
them. It is just not designed to give a full 4GB of RAM to the system, it only
gives 3.4XGB RAM and the rest is really not used, then basically the system
just tries to give the 0.6xGB RAM remaining a task by it being used by "System
Resources"
This isn't really Linux dependant.
.Alejandro
>
> Regards
>
> Marcel
Marcel> yes, that's it.
OK, I've exhausted my ideas. I guess you could always try contacting
the vendor....
- R.
Hi Alejandro,
> > the board in this system is a Intel D945GNT and the box tells me the
> > maximum supported amount of RAM is 4 GB. So there should be a way to
> > address this amount memory.
>
> The board did take the 4GB of RAM and it is finding them, therefore supports
> them. It is just not designed to give a full 4GB of RAM to the system, it only
> gives 3.4XGB RAM and the rest is really not used, then basically the system
> just tries to give the 0.6xGB RAM remaining a task by it being used by "System
> Resources"
>
> This isn't really Linux dependant.
so there is no way to give me back the "lost" memory. Is it possible
that another motherboard might help?
Regards
Marcel
Hi Roland,
> Marcel> yes, that's it.
>
> OK, I've exhausted my ideas. I guess you could always try contacting
> the vendor....
guess what, this is the CPU and board that I won at the OLS this year ;)
Regards
Marcel
On Thu, 27 Oct 2005, Marcel Holtmann wrote:
> Hi guys,
>
> I installed 4 x 1 GB DDR2 memory in my Intel Dual-Core 2.80GHz system,
> but it shows me only 3.3 GB of RAM:
>
> Memory: 3339124k/3398656k available (2029k kernel code, 56232k reserved,
> 741k data, 184k init)
>
> The BIOS and dmidecode tells me that I have 4 GB of RAM installed and I
> don't have any idea where to look for details. What information do you
> need to analyze this?
>
> Regards
>
> Marcel
Hmmm. Do you have a screen card? Trick question. It takes address-
space. How about stuff on the PCI bus? That takes address-space
also. If you look at the boot log, you will probably find that
there is a lot of "reserved" address-space. Since RAM needs
to "share" such address-space, any RAM behind the reserved addresses
will not be accessed.
Cheers,
Dick Johnson
Penguin : Linux version 2.6.13.4 on an i686 machine (5589.55 BogoMips).
Warning : 98.36% of all statistics are fiction.
.
****************************************************************
The information transmitted in this message is confidential and may be privileged. Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to [email protected] - and destroy all copies of this information, including any attachments, without reading or disclosing them.
Thank you.
Let's see if I can backup my comments.
http://support.intel.com/support/motherboards/server/sb/cs-010458.htm
Hope it clarifies,
.Alejandro
On Thu, 27 Oct 2005 23:07:41 +0200, Marcel Holtmann wrote
> Hi Alejandro,
>
> > > the board in this system is a Intel D945GNT and the box tells me the
> > > maximum supported amount of RAM is 4 GB. So there should be a way to
> > > address this amount memory.
> >
> > The board did take the 4GB of RAM and it is finding them, therefore supports
> > them. It is just not designed to give a full 4GB of RAM to the system, it only
> > gives 3.4XGB RAM and the rest is really not used, then basically the system
> > just tries to give the 0.6xGB RAM remaining a task by it being used by "System
> > Resources"
> >
> > This isn't really Linux dependant.
>
> so there is no way to give me back the "lost" memory. Is it possible
> that another motherboard might help?
AFAIK, No. AMD and Intel will always do the same thing until we all move to
real IA64.
Unless there is some sort of kernel hack that will do some crazy thing to give
you the power there.
But hey, look at it this way, if you remove 1GB, you will lose the Dual
Channel capability.
.Alejandro
Hi Alejandro,
> > so there is no way to give me back the "lost" memory. Is it possible
> > that another motherboard might help?
>
> AFAIK, No. AMD and Intel will always do the same thing until we all move to
> real IA64.
>
> Unless there is some sort of kernel hack that will do some crazy thing to give
> you the power there.
do you think that activating NUMA emulation might help?
> But hey, look at it this way, if you remove 1GB, you will lose the Dual
> Channel capability.
I could have bought two 512 MB modules ;)
Regards
Marcel
In article <1130445194.5416.3.camel@blade> you wrote:
> I installed 4 x 1 GB DDR2 memory in my Intel Dual-Core 2.80GHz system,
> but it shows me only 3.3 GB of RAM:
What Vendor?
Try a BIOS update, some recent BIOSes support remapping, others dont. Look
in BIOS for remapping settings and also try to change the Video mapping
hole.
Gruss
Bernd
On Thu, Oct 27, 2005 at 05:15:50PM -0400, Alejandro Bonilla wrote:
> On Thu, 27 Oct 2005 23:07:41 +0200, Marcel Holtmann wrote
> > Hi Alejandro,
> >
> > > > the board in this system is a Intel D945GNT and the box tells me the
> > > > maximum supported amount of RAM is 4 GB. So there should be a way to
> > > > address this amount memory.
> > >
> > > The board did take the 4GB of RAM and it is finding them, therefore supports
> > > them. It is just not designed to give a full 4GB of RAM to the system, it only
> > > gives 3.4XGB RAM and the rest is really not used, then basically the system
> > > just tries to give the 0.6xGB RAM remaining a task by it being used by "System
> > > Resources"
> > >
> > > This isn't really Linux dependant.
> >
> > so there is no way to give me back the "lost" memory. Is it possible
> > that another motherboard might help?
>
> AFAIK, No. AMD and Intel will always do the same thing until we all move to
> real IA64.
Somehow, I doubt AMD see it that way :-)
Some boards at least have a BIOS option to support 'memory hoisting'
to map the 'lost' memory above the 4G address space.
I suspect a lot of the lower-end (and older) boards however don't have
this option, as they were not tested with 4GB.
Dave
> > AFAIK, No. AMD and Intel will always do the same thing until we all move to
> > real IA64.
>
> Somehow, I doubt AMD see it that way :-)
>
> Some boards at least have a BIOS option to support 'memory hoisting'
> to map the 'lost' memory above the 4G address space.
>
> I suspect a lot of the lower-end (and older) boards however don't have
> this option, as they were not tested with 4GB.
>
I have Tyan k8e which supports memory remapping. Question, however, will
that work with i686-based kernel? Or do we have to switch to x86_64?
Vlad
Hi Dave,
> Some boards at least have a BIOS option to support 'memory hoisting'
> to map the 'lost' memory above the 4G address space.
>
> I suspect a lot of the lower-end (and older) boards however don't have
> this option, as they were not tested with 4GB.
do you have any information about remapping support of the D945GNT
motherboard from Intel.
Regards
Marcel
Roland Dreier <[email protected]> writes:
>
> I don't know if EM64T systems (or whatever the right term is) have a
> way of remapping some RAM above 4 GB so that you can use all your
> memory in a case like this.
The lower/middle end non server intel chipsets typically only support
4GB of physical address space in hardware. No memory remapping
possible. So with 4GB RAM you always lose to the memory hole.
-Andi
On Fri, Oct 28, 2005 at 12:11:11AM +0200, Marcel Holtmann wrote:
> Hi Dave,
>
> > Some boards at least have a BIOS option to support 'memory hoisting'
> > to map the 'lost' memory above the 4G address space.
> >
> > I suspect a lot of the lower-end (and older) boards however don't have
> > this option, as they were not tested with 4GB.
>
> do you have any information about remapping support of the D945GNT
> motherboard from Intel.
I've not come across an EM64T with that much RAM, so I've not had
reason to go looking.. Sorry.
Dave
On Thu, 27 Oct 2005 18:05:33 -0400, Dave Jones wrote
> On Thu, Oct 27, 2005 at 05:15:50PM -0400, Alejandro Bonilla wrote:
> > On Thu, 27 Oct 2005 23:07:41 +0200, Marcel Holtmann wrote
> > > Hi Alejandro,
> > >
> > > > > the board in this system is a Intel D945GNT and the box
> tells me the > > > > maximum supported amount of RAM is 4 GB. So
> there should be a way to > > > > address this amount memory. > > >
> > > > The board did take the 4GB of RAM and it is finding them,
> therefore supports > > > them. It is just not designed to give a
> full 4GB of RAM to the system, it only > > > gives 3.4XGB RAM and
> the rest is really not used, then basically the system > > > just
> tries to give the 0.6xGB RAM remaining a task by it being used by "System
> > > > Resources"
> > > >
> > > > This isn't really Linux dependant.
> > >
> > > so there is no way to give me back the "lost" memory. Is it possible
> > > that another motherboard might help?
> >
> > AFAIK, No. AMD and Intel will always do the same thing until we
> all move to > real IA64.
>
> Somehow, I doubt AMD see it that way :-)
>
> Some boards at least have a BIOS option to support 'memory hoisting'
> to map the 'lost' memory above the 4G address space.
True, probably AMD added a "workaround" for this problem, but by nature, this
is what happens.
>
> I suspect a lot of the lower-end (and older) boards however don't
> have this option, as they were not tested with 4GB.
Probably no Intel boards have the option. So, it would be that Marcel contact
Intel so they can add a mapping option on the BIOS for this situation. It is
somehow missleading.
.Alejandro
>
> Dave
Hi Dave,
> > > Some boards at least have a BIOS option to support 'memory hoisting'
> > > to map the 'lost' memory above the 4G address space.
> > >
> > > I suspect a lot of the lower-end (and older) boards however don't have
> > > this option, as they were not tested with 4GB.
> >
> > do you have any information about remapping support of the D945GNT
> > motherboard from Intel.
>
> I've not come across an EM64T with that much RAM, so I've not had
> reason to go looking.. Sorry.
am I really the first person trying to use that board with 4 GB of RAM
and an Intel Dual-Core with EM64T :(
Regards
Marcel
Hi Alejandro,
> > I suspect a lot of the lower-end (and older) boards however don't
> > have this option, as they were not tested with 4GB.
>
> Probably no Intel boards have the option. So, it would be that Marcel contact
> Intel so they can add a mapping option on the BIOS for this situation. It is
> somehow missleading.
since Intel gave that board to me, they should really add something ;)
Regards
Marcel
On Fri, 28 Oct 2005 00:17:01 +0200, Marcel Holtmann wrote
> Hi Dave,
>
> > > > Some boards at least have a BIOS option to support 'memory hoisting'
> > > > to map the 'lost' memory above the 4G address space.
> > > >
> > > > I suspect a lot of the lower-end (and older) boards however don't have
> > > > this option, as they were not tested with 4GB.
> > >
> > > do you have any information about remapping support of the D945GNT
> > > motherboard from Intel.
> >
> > I've not come across an EM64T with that much RAM, so I've not had
> > reason to go looking.. Sorry.
>
> am I really the first person trying to use that board with 4 GB of
> RAM and an Intel Dual-Core with EM64T :(
Dude, again. This has nothing to do with the CPU. The arch IA32 is simply
_not_ made for 4GB, so, some motherboards manufacturers make a workaround like
Dave said, to Map such RAM. After all, that 0.6GB RAM will be used and
allocated for other resources. This is just how the arch works and I doubt it
will change.
Only thing that you can do is buy a new Mobo which might support Mapping for
the extra RAM.
There isn't really much that you can do.
.Alejandro
Marcel Holtmann wrote:
> I could have bought two 512 MB modules ;)
I'll trade you two 512MB modules for two 1GB modules. :)
On Fri, 28 Oct 2005, Marcel Holtmann wrote:
> Hi Dave,
>
>> >> Some boards at least have a BIOS option to support 'memory hoisting'
>> >> to map the 'lost' memory above the 4G address space.
>> >>
>> >> I suspect a lot of the lower-end (and older) boards however don't have
>> >> this option, as they were not tested with 4GB.
>> >
>> > do you have any information about remapping support of the D945GNT
>> > motherboard from Intel.
>>
>> I've not come across an EM64T with that much RAM, so I've not had
>> reason to go looking.. Sorry.
>
> am I really the first person trying to use that board with 4 GB of RAM
> and an Intel Dual-Core with EM64T :(
maybe the first one to not use it to play half-life 2...
> Regards
>
> Marcel
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
--
--------------------------------------------------------------------------
Joel Jaeggli Unix Consulting [email protected]
GPG Key Fingerprint: 5C6E 0104 BAF0 40B0 5BD3 C38B F000 35AB B67F 56B2
In article <[email protected]> you wrote:
> Dude, again. This has nothing to do with the CPU. The arch IA32 is simply
> _not_ made for 4GB
thats wrong.
Gruss
Bernd
On 10/28/05, Alejandro Bonilla <[email protected]> wrote:
> On Thu, 27 Oct 2005 23:07:41 +0200, Marcel Holtmann wrote
> > Hi Alejandro,
> >
> > so there is no way to give me back the "lost" memory. Is it possible
> > that another motherboard might help?
>
> AFAIK, No. AMD and Intel will always do the same thing until we all move to
> real IA64.
>
Can you tell me the main differences between IA64 and x86_64 (Opteron)
? because in your one of the previous mail you said IA64 != EM64T and
its true, but I know is EM64T/AMD64 in 64-bit mode != IA32 but you
said that too EM64T is not really 64-bit, its a IA32 .. Can you give
me some link which just tells the difference between IA64 (Itanium)
and AMD64 (Opteron) ?
While googling I found this article
http://www.eweek.com/article2/0,1895,1046390,00.asp but its not
clearing mentioning the difference between Opteron and Itanium !
Although I found this difference in that article :
With the Itanium, Intel proposes to examine
programs when they are compiled into their executable form and encode
concurrent operations ahead of time. Intel calls this approach EPIC,
for Explicitly Parallel Instruction Computing, and it is the genuine
difference between the Itanium and AMD's x86-64. EPIC's drawback is
that the core of the Itanium no longer offers an effective
upward-compatible path to existing x86 code; its speed in running that
32-bit code has proved to be disappointing.
So is there any other difference except above ?
--
Fawad Lateef
On Fri, 28 Oct 2005, Fawad Lateef wrote:
> On 10/28/05, Alejandro Bonilla <[email protected]> wrote:
>> On Thu, 27 Oct 2005 23:07:41 +0200, Marcel Holtmann wrote
>>> Hi Alejandro,
>>>
>>> so there is no way to give me back the "lost" memory. Is it possible
>>> that another motherboard might help?
>>
>> AFAIK, No. AMD and Intel will always do the same thing until we all move to
>> real IA64.
>>
>
> Can you tell me the main differences between IA64 and x86_64 (Opteron)
IA64 is itanium - there are a lot of differences but the principle one for
your perspective is that you don't want to run x86 code on a itanium, it
has an x86 instruction decoder but you wouldn't want to use it if you
could avoid it.
> ? because in your one of the previous mail you said IA64 != EM64T and
emt64 getts lumped with amd64 collectivly x86_64. fundamentaly intels
implementation is compatible with amd's
> its true, but I know is EM64T/AMD64 in 64-bit mode != IA32 but you
> said that too EM64T is not really 64-bit, its a IA32 .. Can you give
It is ia32 except with 40 bits of real memory and 48 bits of virtual
memory and 64 bit registers.
one article that's use for getting a start on the instruction set is here:
http://arstechnica.com/cpu/03q1/x86-64/x86-64-1.html
> me some link which just tells the difference between IA64 (Itanium)
> and AMD64 (Opteron) ?
you're not likely to care about ia64, so I think what your'e really
interested in is ia32 vs x86_64 and intel vs amd in the context of x86_64
> While googling I found this article
> http://www.eweek.com/article2/0,1895,1046390,00.asp but its not
> clearing mentioning the difference between Opteron and Itanium !
>
> Although I found this difference in that article :
> With the Itanium, Intel proposes to examine
> programs when they are compiled into their executable form and encode
> concurrent operations ahead of time. Intel calls this approach EPIC,
> for Explicitly Parallel Instruction Computing, and it is the genuine
> difference between the Itanium and AMD's x86-64. EPIC's drawback is
> that the core of the Itanium no longer offers an effective
> upward-compatible path to existing x86 code; its speed in running that
> 32-bit code has proved to be disappointing.
>
> So is there any other difference except above ?
>
>
> --
> Fawad Lateef
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
--
--------------------------------------------------------------------------
Joel Jaeggli Unix Consulting [email protected]
GPG Key Fingerprint: 5C6E 0104 BAF0 40B0 5BD3 C38B F000 35AB B67F 56B2
On 10/28/05, Joel Jaeggli <[email protected]> wrote:
> On Fri, 28 Oct 2005, Fawad Lateef wrote:
>
> > Can you tell me the main differences between IA64 and x86_64 (Opteron)
>
> IA64 is itanium - there are a lot of differences but the principle one for
> your perspective is that you don't want to run x86 code on a itanium, it
> has an x86 instruction decoder but you wouldn't want to use it if you
> could avoid it.
>
OK
> > ? because in your one of the previous mail you said IA64 != EM64T and
>
> emt64 getts lumped with amd64 collectivly x86_64. fundamentaly intels
> implementation is compatible with amd's
>
> > its true, but I know is EM64T/AMD64 in 64-bit mode != IA32 but you
> > said that too EM64T is not really 64-bit, its a IA32 .. Can you give
>
> It is ia32 except with 40 bits of real memory and 48 bits of virtual
> memory and 64 bit registers.
>
And a difference of memory architecture is there tooo. x86_64 in
64-bit mode implements flat memory model but IA32 uses
segmentation/paging. As far as Linux Kernel is concern I know kernel
won't implements segmentation in IA32 so it memory management is
almost compatible with x86_64 except registers/real address /virtual
addresses ...
> one article that's use for getting a start on the instruction set is here:
>
> http://arstechnica.com/cpu/03q1/x86-64/x86-64-1.html
>
Thanks, nice link :)
>
> > me some link which just tells the difference between IA64 (Itanium)
> > and AMD64 (Opteron) ?
>
> you're not likely to care about ia64, so I think what your'e really
> interested in is ia32 vs x86_64 and intel vs amd in the context of x86_64
>
Nops, I am not interested in x86_64 context of intel and amd, I rather
wanted a comparison between the intel and amd server processors
architecture (Itanium and Opteron).
Any ways, Thanks
--
Fawad Lateef
"Alejandro Bonilla" <[email protected]> writes:
>> so there is no way to give me back the "lost" memory. Is it possible
>> that another motherboard might help?
>
> AFAIK, No. AMD and Intel will always do the same thing until we all move to
> real IA64.
IA64 inherits this part of the architecture from x86, so no magic fix.
This is a fundamentally a chipset limitation, not an architectural bug.
rev-E amd64 cpus from AMD all have memory hoisting support,
as do all server chipsets from Intel for the last several years.
To avoid this you just need a good chipset and a good BIOS implementation.
Any recent server board should be fine. Hopefully the desktop boards
will catch up soon.
Eric
On Fri, 28 Oct 2005 09:29:34 -0600, Eric W. Biederman wrote
> "Alejandro Bonilla" <[email protected]> writes:
>
> >> so there is no way to give me back the "lost" memory. Is it possible
> >> that another motherboard might help?
> >
> > AFAIK, No. AMD and Intel will always do the same thing until we all move to
> > real IA64.
>
> IA64 inherits this part of the architecture from x86, so no magic
> fix. This is a fundamentally a chipset limitation, not an
> architectural bug.
Probably, but if they add a function to support this, then is a Fix, else it
would have been there all the time.
>
> rev-E amd64 cpus from AMD all have memory hoisting support,
> as do all server chipsets from Intel for the last several years.
Not according to the link I provided since we started the conversation. But
they have done tweaks to start "supporting" all this memory.
>
> To avoid this you just need a good chipset and a good BIOS implementation.
> Any recent server board should be fine. Hopefully the desktop boards
> will catch up soon.
I doubt it, Intel is slowly moving to 64bit so applications and OS can catch
up in the future to leave 32bit behind. (Probably)
Anyway, I think Marcel got most of he's doubt answered.
.Alejandro
>
> Eric
Fawad Lateef wrote:
> Can you tell me the main differences between IA64 and x86_64 (Opteron)
> ? because in your one of the previous mail you said IA64 != EM64T and
> its true, but I know is EM64T/AMD64 in 64-bit mode != IA32 but you
> said that too EM64T is not really 64-bit, its a IA32 .. Can you give
> me some link which just tells the difference between IA64 (Itanium)
> and AMD64 (Opteron) ?
IA64 (Itanium [Itanic, really -- the architecture IMO is a real
disappointment IRL for something which on paper looked very impressive])
is a true 64 bit CPU. It's a new architecture built from scratch -- as
different from IA32 as SPARC is. IA64 has a "compatibility mode" which
allows it to run IA32 code natively, albeit very, very slow. Make no
mistake -- IA64 is a completely different CPU type and architecture from
IA32.
x86_64 (both AMD64 and Intel's EM64T offerings) are 64-bit extensions to
a 32 bit microprocessor. The system architecture stayed basically the
same. This is different from IA32 in the same ways PPC64 is different
from PPC32 and SPARC64 is different from SPARC32. Both CPUs use the same
set of commands as their predecessors, with the inclusion of several
more instructions and registers (as well as the registers being of
greater width).
The differences between AMD64 and EM64T are significant as well; however
from a programming standpoint the differences are almost negligible. THe
biggest difference (which may have impact on programming principles) is
AMD64 is a NUMA architecture whereas EM64T still uses the same memory
model and architecture as the IA32. Quite simply, you gain more from
AMD64 than you do from EM64T, in my opinion.
Both (really, all three) architectures have their plusses and minuses.
EM64T is Intel's idea of playing catch-up with the competition (AMD), IMO.
> With the Itanium, Intel proposes to examine
> programs when they are compiled into their executable form and encode
> concurrent operations ahead of time. Intel calls this approach EPIC,
> for Explicitly Parallel Instruction Computing, and it is the genuine
> difference between the Itanium and AMD's x86-64. EPIC's drawback is
This is so blatantly simplified it's outright wrong.
EPIC is a very clever, revolutionary design. When I first read the
Itanium whitepapers some years ago, it seemed like this technology was
definitely worth taking a look at. Apparently I wasn't the only one who
thought this: HP dropped PA-RISC for Itanium, SGI dropped MIPS, Compaq
(at the time its own entity) dropped Alpha... Everyone, it seems, jumped
on the bandwagon with the exception of Sun, who elected to wait for
AMD's offering. Turns out though, what looked good on paper turned out
to be quite a disappointment. The original Itanium, at its release, was
very disappointing in terms of performance. At the time, the 32-bit
Pentium III Tualatin could perform the same calculations as Itanium in
less time -- for a fraction of the cost. And the 32-bit codepath
compatibility? It was a joke -- some compared it to a sluggish
Pentium-II 266. HP took the Itanium specification from Intel, used its
expertise from years with PA-RISC, and redesigned Itanium, to later
release Itanium II. This offered a great performance increase over the
previous release, but the 32-bit codepath is still abysmally slow. Even
the new, improved EPIC still lacks; thus far nobody's compiler -- not
even Intel's -- can take full advantage or make full use of the features
in this CPU. Many high-performance applications are still hand-tuned in
IA64 assembler to take advantage of its offerings.
Hope this helped to clear some things up.
Cheers,
-Kelsey
"Alejandro Bonilla" <[email protected]> writes:
> On Fri, 28 Oct 2005 09:29:34 -0600, Eric W. Biederman wrote
>> "Alejandro Bonilla" <[email protected]> writes:
>>
>> >> so there is no way to give me back the "lost" memory. Is it possible
>> >> that another motherboard might help?
>> >
>> > AFAIK, No. AMD and Intel will always do the same thing until we all move to
>> > real IA64.
>>
>> IA64 inherits this part of the architecture from x86, so no magic
>> fix. This is a fundamentally a chipset limitation, not an
>> architectural bug.
>
> Probably, but if they add a function to support this, then is a Fix, else it
> would have been there all the time.
It is an optimization. Most chipsets have a hole from XXX-4GB where
you can't put memory. In most configurations the hole is only a couple
of megabytes. Although with PCI-E I think it is now typically about 512M
because of the memory mapped PCI-E config space.
If you put in more that 4G the memory usually shows up at 4G and keeps going.
With memory hoisting that many recent chipsets implement you can see the
memory that would normally be covered by the mmio hole someplace about
4G, so you don't loose any memory in that situation.
Now that I think about it that explains why memory was missing on the
system with PCI-E the memory mapped PCI-E config space was out there
covering it up.
>> rev-E amd64 cpus from AMD all have memory hoisting support,
>> as do all server chipsets from Intel for the last several years.
>
> Not according to the link I provided since we started the conversation. But
> they have done tweaks to start "supporting" all this memory.
I have been writing BIOS's for the last 5 years, on Intel and on AMD boards.
I know exactly what the situation is for the boards and chipsets I
have been dealing with. I actually find it mildly surprising that
desktop boards don't handle this yet.
>> To avoid this you just need a good chipset and a good BIOS implementation.
>> Any recent server board should be fine. Hopefully the desktop boards
>> will catch up soon.
>
> I doubt it, Intel is slowly moving to 64bit so applications and OS can catch
> up in the future to leave 32bit behind. (Probably)
???
What has this to do with 32bit and 64bit. x86_64 (aka amd64+em64t) is
the 64bit desktop architecture, and that is what I am talking about.
Basically everything is 64bit now, the only question is how well does
the chipset and BIOS support your memory configuration.
Eric
Hello,
I have system with 2 Pentium 4 Xeon EM64T processors using 4GB of RAM.
Kernel is 2.6.13.4 compiled for x86_64 architecture.
Btw, /proc/cpuinfo reports, that only 36 bits are availalable for physical
memory. Not 40.
# cat /proc/meminfo
MemTotal: 4075408 kB
MemFree: 23696 kB
# cat /proc/iomem
[...]
dd100000-dd3fffff : PCI Bus #01
dd100000-dd100fff : 0000:01:00.1
dd101000-dd101fff : 0000:01:00.3
dd200000-dd2fffff : PCI Bus #02
dd200000-dd201fff : 0000:02:02.0
dd200000-dd200fff : aic79xx
dd202000-dd203fff : 0000:02:02.1
dd202000-dd202fff : aic79xx
dd220000-dd23ffff : 0000:02:03.0
dd220000-dd23ffff : e1000
dd240000-dd25ffff : 0000:02:03.1
dd240000-dd25ffff : e1000
dd300000-dd3fffff : PCI Bus #03
dd300000-dd3fffff : 0000:03:04.0
dd400000-deffffff : PCI Bus #06
dd400000-dd400fff : 0000:06:01.0
de000000-deffffff : 0000:06:01.0
e0000000-efffffff : reserved
fec00000-fec0ffff : reserved
fee00000-fee00fff : reserved
ff800000-ffbfffff : reserved
fffffc00-ffffffff : reserved
100000000-12fffffff : System RAM
According to /proc/pci it is E7520/E7525 board. It has a number of PCI devices.
--
Luk?? Hejtm?nek
On Fri, Oct 28, 2005 at 10:58:33PM +0200, Lukas Hejtmanek wrote:
> Hello,
>
> I have system with 2 Pentium 4 Xeon EM64T processors using 4GB of RAM.
>
> Kernel is 2.6.13.4 compiled for x86_64 architecture.
>
> Btw, /proc/cpuinfo reports, that only 36 bits are availalable for physical
> memory. Not 40.
That should be fixed in 2.6.14
Dave
Hi Dave,
> > I have system with 2 Pentium 4 Xeon EM64T processors using 4GB of RAM.
> >
> > Kernel is 2.6.13.4 compiled for x86_64 architecture.
> >
> > Btw, /proc/cpuinfo reports, that only 36 bits are availalable for physical
> > memory. Not 40.
>
> That should be fixed in 2.6.14
is this only true for the Xeon series or should it be 40 bits for every
EM64T capable CPU from Intel? I ask, because mine still shows 36 bits
with the latest vanilla from today.
processor : 0
vendor_id : GenuineIntel
cpu family : 15
model : 4
model name : Intel(R) Pentium(R) D CPU 2.80GHz
stepping : 4
cpu MHz : 2800.229
cache size : 1024 KB
physical id : 0
siblings : 2
core id : 0
cpu cores : 2
fpu : yes
fpu_exception : yes
cpuid level : 5
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm syscall lm constant_tsc pni monitor ds_cpl cid cx16 xtpr
bogomips : 5609.23
clflush size : 64
cache_alignment : 128
address sizes : 36 bits physical, 48 bits virtual
power management:
Regards
Marcel
On Sat, Oct 29, 2005 at 01:15:24PM +0200, Marcel Holtmann wrote:
> Hi Dave,
>
> > > I have system with 2 Pentium 4 Xeon EM64T processors using 4GB of RAM.
> > >
> > > Kernel is 2.6.13.4 compiled for x86_64 architecture.
> > >
> > > Btw, /proc/cpuinfo reports, that only 36 bits are availalable for physical
> > > memory. Not 40.
> >
> > That should be fixed in 2.6.14
>
> is this only true for the Xeon series or should it be 40 bits for every
> EM64T capable CPU from Intel? I ask, because mine still shows 36 bits
> with the latest vanilla from today.
Actually, I mixed this up a little. 36 bits is 'the norm' for EM64T
(for right now at least). However, there were two models that advertised
40 bits, but only actually have 36 bits.
The following patch Andi forwarded never actually made it into 2.6.14.
Definite 2.6.14.1 material IMO.
Dave
From: Andi Kleen <[email protected]>
To: Linus Torvalds <[email protected]>
Subject: [PATCH] x86_64/i386: Compute correct MTRR mask on early Noconas
Date: Thu, 13 Oct 2005 02:28:26 +0200
Cc: [email protected], Shaohua Li <[email protected]>, [email protected]
Force correct address space size for MTRR on some 64bit Intel Xeons
They report 40bit, but only have 36bits of physical address space.
This caused problems with setting up the correct masks for MTRR,
resulting in incorrect MTRRs.
CPUID workaround for steppings 0F33h(supporting x86) and 0F34h(supporting x86
and EM64T). Detail info can be found at:
http://download.intel.com/design/Xeon/specupdt/30240216.pdf
http://download.intel.com/design/Pentium4/specupdt/30235221.pdf
Signed-off-by: Shaohua Li<[email protected]>
Signed-off-by: Andi Kleen <[email protected]>
Index: linux/arch/i386/kernel/cpu/mtrr/main.c
===================================================================
--- linux.orig/arch/i386/kernel/cpu/mtrr/main.c
+++ linux/arch/i386/kernel/cpu/mtrr/main.c
@@ -626,6 +626,14 @@ void __init mtrr_bp_init(void)
if (cpuid_eax(0x80000000) >= 0x80000008) {
u32 phys_addr;
phys_addr = cpuid_eax(0x80000008) & 0xff;
+ /* CPUID workaround for Intel 0F33/0F34 CPU */
+ if (boot_cpu_data.x86_vendor == X86_VENDOR_INTEL &&
+ boot_cpu_data.x86 == 0xF &&
+ boot_cpu_data.x86_model == 0x3 &&
+ (boot_cpu_data.x86_mask == 0x3 ||
+ boot_cpu_data.x86_mask == 0x4))
+ phys_addr = 36;
+
size_or_mask = ~((1 << (phys_addr - PAGE_SHIFT)) - 1);
size_and_mask = ~size_or_mask & 0xfff00000;
} else if (boot_cpu_data.x86_vendor == X86_VENDOR_CENTAUR &&
Index: linux/arch/x86_64/kernel/setup.c
===================================================================
--- linux.orig/arch/x86_64/kernel/setup.c
+++ linux/arch/x86_64/kernel/setup.c
@@ -990,6 +990,11 @@ static void __cpuinit init_intel(struct
unsigned eax = cpuid_eax(0x80000008);
c->x86_virt_bits = (eax >> 8) & 0xff;
c->x86_phys_bits = eax & 0xff;
+ /* CPUID workaround for Intel 0F34 CPU */
+ if (c->x86_vendor == X86_VENDOR_INTEL &&
+ c->x86 == 0xF && c->x86_model == 0x3 &&
+ c->x86_mask == 0x4)
+ c->x86_phys_bits = 36;
}
if (c->x86 == 15)
On Iau, 2005-10-27 at 17:15 -0400, Alejandro Bonilla wrote:
> > so there is no way to give me back the "lost" memory. Is it possible
> > that another motherboard might help?
>
> AFAIK, No. AMD and Intel will always do the same thing until we all move to
> real IA64.
Fortunately you can use a real processor with 4GB of RAM as well as an
IA-64 (if you can find one even!). It is chipset dependant whether RAM
lost to the PCI window can be made to appear over the 4GB boundary with
a PAE capable intel ia32 processor (or clone) with an AMD x86-64
processor (or clone)
It depends entirely on the chipset quality
On Iau, 2005-10-27 at 18:20 -0400, Alejandro Bonilla wrote:
> Dude, again. This has nothing to do with the CPU. The arch IA32 is simply
> _not_ made for 4GB, so, some motherboards manufacturers make a workaround like
Wrong IA-32 supports more than 4Gb in PAE 36bit physical 32bit virtual
mode and has done since the Preventium Pro
Alan Cox wrote:
>On Iau, 2005-10-27 at 18:20 -0400, Alejandro Bonilla wrote:
>
>
>>Dude, again. This has nothing to do with the CPU. The arch IA32 is simply
>>_not_ made for 4GB, so, some motherboards manufacturers make a workaround like
>>
>>
>
>Wrong IA-32 supports more than 4Gb in PAE 36bit physical 32bit virtual
>mode and has done since the Preventium Pro
>
>
I guess you are right and wrong. The architecture has the limitation,
the chipset as well and the OS. According to this document, it is the
fault of the architecture as well as it requires to support addressing
which is not available *stock*, only several other providers have added
such "mapping" to get a better use of the memory.
http://www.intel.com/support/motherboards/server/sb/cs-010458.htm
I really don't want to argue on who knows more or less, just want to
clarify the fact that IA32 will have this problem normally and that the
chipsets that go with it also will make this noticeable.
If you don't believe me, contact the guys who built the Arch which I
think are the ones that made the document?
.Alejandro
On Sul, 2005-10-30 at 20:39 -0700, Alejandro Bonilla Beeche wrote:
> I guess you are right and wrong. The architecture has the limitation,
> the chipset as well and the OS. According to this document, it is the
> fault of the architecture as well as it requires to support addressing
> which is not available *stock*, only several other providers have added
> such "mapping" to get a better use of the memory.
That document reads like a "don't blame us because we didn't bother to
do remapping". That is an Intel business decision not a hardware limit,
as is shown by other vendors whose hardware can do the remap.
* Dave Jones ([email protected]) wrote:
> The following patch Andi forwarded never actually made it into 2.6.14.
> Definite 2.6.14.1 material IMO.
Thanks, queued to -stable. Also, this one is still not upstream.
-chris
--On Sunday, October 30, 2005 22:26:05 +0000 Alan Cox <[email protected]> wrote:
> On Iau, 2005-10-27 at 18:20 -0400, Alejandro Bonilla wrote:
>> Dude, again. This has nothing to do with the CPU. The arch IA32 is simply
>> _not_ made for 4GB, so, some motherboards manufacturers make a workaround like
>
> Wrong IA-32 supports more than 4Gb in PAE 36bit physical 32bit virtual
> mode and has done since the Preventium Pro
Indeed ... I have 64GB ia32 boxes ;-)
M.
On Mon, Oct 31, 2005 at 03:03:08PM -0800, Martin J. Bligh wrote:
> > Wrong IA-32 supports more than 4Gb in PAE 36bit physical 32bit virtual
> > mode and has done since the Preventium Pro
>
> Indeed ... I have 64GB ia32 boxes ;-)
And Intel server chipsets do support remapping. I've seen boards with 2
GB IO holes remapped above 4 GB.
A 4 GB system reports 6 GB of memory, 4 of which are usable as DRAM.
Intel doesn't document it, but there's a slight performance hit for the
remapped memory, too.
On Thu, Oct 27, 2005 at 05:15:50PM -0400, Alejandro Bonilla wrote:
> AFAIK, No. AMD and Intel will always do the same thing until we all move to
> real IA64.
Many boards DO allow remapping memory past 3GB to the 4GB+ area to make
it accessable. There should be a BIOS option for remapping memory or
letting software create a memory hole at 3GB. It is NOT normal to not
allow full access to all the memeory on an amd64/em64t system. Of
course the bios defaults are often set so as to provide as much ram to a
32bit OS as possible at the expense of doing it properly for a 64bit OS.
And it looks like the world has no intension of ever moving to IA64, and
that's probably for the best. PowerPC or Alpha or something would make
more sense if you are going to drop x86.
> Unless there is some sort of kernel hack that will do some crazy thing to give
> you the power there.
>
> But hey, look at it this way, if you remove 1GB, you will lose the Dual
> Channel capability.
Len Sorensen
On Fri, Oct 28, 2005 at 12:09:25AM +0200, Vladimir Lazarenko wrote:
> I have Tyan k8e which supports memory remapping. Question, however, will
> that work with i686-based kernel? Or do we have to switch to x86_64?
I suspect with PAE it will still work yes. I haven't tried it of course
(I don't have that much ram). It will still have the PAE performance
hit on memory access to memory past 4GB just because that's what PAE
does.
Len Sorensen
On Monday 31 October 2005 22:04, Chris Wright wrote:
> * Dave Jones ([email protected]) wrote:
> > The following patch Andi forwarded never actually made it into 2.6.14.
> > Definite 2.6.14.1 material IMO.
>
> Thanks, queued to -stable. Also, this one is still not upstream.
Will be soon, but in general I would prefer if you didn't merge anything
into STABLE that wasn't upstream yet. Otherwise we risk code drift again.
Thanks,
-Andi
* Andi Kleen ([email protected]) wrote:
> On Monday 31 October 2005 22:04, Chris Wright wrote:
> > * Dave Jones ([email protected]) wrote:
> > > The following patch Andi forwarded never actually made it into 2.6.14.
> > > Definite 2.6.14.1 material IMO.
> >
> > Thanks, queued to -stable. Also, this one is still not upstream.
>
> Will be soon, but in general I would prefer if you didn't merge anything
> into STABLE that wasn't upstream yet. Otherwise we risk code drift again.
Absolutely. I just put it in the queue to keep from losing it, and
that's why I mentioned it's not upstream yet. I'm happy to drop it if
you want to resend once it's merged.
thanks,
-chris