SEO

Hello

I have E6300 procesor.
I downloaded stages and portage for ia64.
But i can not execute such binary. Why ?

Thanx

vertigo wrote:

> Hello
>
> I have E6300 procesor.
> I downloaded stages and portage for ia64.
> But i can not execute such binary. Why ?
>
> Thanx


Because you mix two architectures.

IA64 are uncommon and very expensive Itanium/Itanium2 chips.

AMD64 are amd64/Opteron and - surprise, surprise - all chips from EM64T
family, including new P4 and new Core/Core2 chips.

You need AMD64 binaries and set your C/C++ arch to nocona.

--
Pawel Kraszewski
www.kraszewscy.net

In article news:<ejih0n$5fa$1@nemesis.news.tpi.pl>, Pawel Kraszewski wrote:
> AMD64 are amd64/Opteron and - surprise, surprise - all chips from EM64T
> family, including new P4 and new Core/Core2 chips.

I believe that's nearly right: Core Solo/Duo chips are 32-bit only (no
EMT64 instructions), but Core 2 Duo/Quadro chips do have EMT64.

The OP's E6300 is a Core 2 Duo (Allendale) chip, so does have EMT64, and
should use AMD64 Gentoo binaries.

Cheers,
Daniel.

Daniel James wrote:

> I believe that's nearly right: Core Solo/Duo chips are 32-bit only (no
> EMT64 instructions), but Core 2 Duo/Quadro chips do have EMT64.
>
> The OP's E6300 is a Core 2 Duo (Allendale) chip, so does have EMT64, and
> should use AMD64 Gentoo binaries.

And that´s the reason why Gentoo should rename "AMD64" to "x86_64".

Hans

On Fri, 17 Nov 2006 14:08:33 +0100, Hanz Maier <hansimaier@gmx.at> wrote:


>Daniel James wrote:

>> I believe that's nearly right: Core Solo/Duo chips are 32-bit only (no
>> EMT64 instructions), but Core 2 Duo/Quadro chips do have EMT64.
>>
>> The OP's E6300 is a Core 2 Duo (Allendale) chip, so does have EMT64, and
>> should use AMD64 Gentoo binaries.

>And that´s the reason why Gentoo should rename "AMD64" to "x86_64".

AMD64 != x86_64.

In the kernel are three x86 64 bit options:
( ) AMD-Opteron/Athlon64
( ) Intel EM64T
( ) Generic-x86-64

I have no idea wether or not there are any real differences.

On Friday 17 November 2006 17:24, AZ Nomad stood up and addressed the masses
in /alt.os.linux.gentoo/ as follows...:

> On Fri, 17 Nov 2006 14:08:33 +0100, Hanz Maier <hansimaier@gmx.at> wrote:
>
>
>>Daniel James wrote:
>
>>> I believe that's nearly right: Core Solo/Duo chips are 32-bit only (no
>>> EMT64 instructions), but Core 2 Duo/Quadro chips do have EMT64.
>>>
>>> The OP's E6300 is a Core 2 Duo (Allendale) chip, so does have EMT64, and
>>> should use AMD64 Gentoo binaries.
>
>> And that?s the reason why Gentoo should rename "AMD64" to "x86_64".
>
> AMD64 != x86_64.

Actually, it is, or it /should/ be. Intel was the one to develop the /IA32/
architecture when they introduced the /i80386/ and the /IA64/ architecture
when they introduced the Itanium - which was originally codenamed /Merced./

However, the /x86_64/ platform was an AMD invention. Intel still had all of
its money on the /IA64/ at the time, but AMD chose to expand the
existing /x86/ architecture to a 64-bit level instead, which offered 32-bit
compatibility without having to use a slow emulation, as is the case
on /IA64./

Intel only followed this architecture later with their /EM64T/ CPU's,
because they finally realized that the Itanium was not going to hit
mainstream at the pricetag they had stuck to it. ;-)

> In the kernel are three x86 64 bit options:
> ( ) AMD-Opteron/Athlon64

This has AMD-specific optimizations.

> ( ) Intel EM64T

This has Intel-specific optimizations

> ( ) Generic-x86-64

This has generic code in it that circumvents the brand-specific
optimizations. A similar thing exists for /IA32,/ i.e. you can select a
specific type of CPU and/or include the "Generic x86 optimizations", which
will work on most /IA32/ CPU's.

> I have no idea wether or not there are any real differences.

Think of it kind of as a VESA driver or a generic VGA driver versus the
adapter-specific driver. It'll work on almost everything, but it's not
optimized for one or the other. ;-)

--
With kind regards,

*Aragorn*
(registered GNU/Linux user #223157)

Aragorn wrote:

> Intel only followed this architecture later with their /EM64T/ CPU's,
> because they finally realized that the Itanium was not going to hit
> mainstream at the pricetag they had stuck to it. ;-)

Well, I had the pleasure to put my hands on a quad Itanium2 machine (16G RAM
to make things even more pleasant) - all four horses running a dedicated
Redhat server. Well, *that* power was breathtaking. SQL query that lasted
>10 minutes on a strong, multiprocessor IA32 server took just a few SECONDS
on 4x I2. I guess that this huge amount of RAM helped a lot, but still
reduction of time by a factor of well over 50 is impressive. I didn't dare
to ask about the price...

--
Pawel Kraszewski
www.kraszewscy.net

On Friday 17 November 2006 23:32, Pawel Kraszewski stood up and addressed
the masses in /alt.os.linux.gentoo/ as follows...:

> Aragorn wrote:
>
>> Intel only followed this architecture later with their /EM64T/ CPU's,
>> because they finally realized that the Itanium was not going to hit
>> mainstream at the pricetag they had stuck to it. ;-)
>
> Well, I had the pleasure to put my hands on a quad Itanium2 machine (16G
> RAM to make things even more pleasant) - all four horses running a
> dedicated Redhat server. Well, *that* power was breathtaking. SQL query
> that lasted 10 minutes on a strong, multiprocessor IA32 server took just a
> few SECONDS on 4x I2. I guess that this huge amount of RAM helped a lot,
> but still reduction of time by a factor of well over 50 is impressive. I
> didn't dare to ask about the price...

Well, as it just so happens to be, those on this newsgroup who also happen
to be subscribed to /alt.os.linux.mandrake/ and/or /alt.os.linux.mandriva/
are already aware of my absolutely insane folly... I'm planning on a
4-node/8-core 1.6 GHz Opteron NUMA machine with 64 GB of ECC registered
DDR-333, an U320 SCSI hardware RAID-5EE and an SATA-II hardware
RAID-1... ;-)

I'm expecting great things from /MAKEOPTS=-j9.../ ;-þ

By the way, does anyone have any recommendations for the CPU timer frequency
on such a machine? It'll be both a heavy-duty workstation and a server, so
should I go for 1000 Hz or 250 Hz, considering that they're will be 8 CPU
cores? ;-)

--
With kind regards,

*Aragorn*
(registered GNU/Linux user #223157)

Aragorn <stryder@telenet.invalid> wrote:
>
> By the way, does anyone have any recommendations for the CPU timer
> frequency on such a machine? It'll be both a heavy-duty workstation
> and a server, so should I go for 1000 Hz or 250 Hz, considering that
> they're will be 8 CPU cores? ;-)

100, definitely. There's 8 times as many cores to pick up the next thread,
so 100 Hz will feel faster than 250 Hz on a dual CPU box would (which is
what I'd recommend for a 2-cpu or dual-core workstation), and only slightly
slower than 1000 Hz on a single-CPU box. Each CPU switching less often
means the CPU cache and pipeline won't have to be filled again as often,
which increases the overall performance, reducing the need for switching.

If insane UI responsiveness is the overall goal, I'd still not go above 250
Hz.

Regards,
--
*Art

On Saturday 18 November 2006 06:21, Arthur Hagen stood up and addressed the
masses in /alt.os.linux.gentoo/ as follows...:

> Aragorn <stryder@telenet.invalid> wrote:
>>
>> By the way, does anyone have any recommendations for the CPU timer
>> frequency on such a machine? It'll be both a heavy-duty workstation
>> and a server, so should I go for 1000 Hz or 250 Hz, considering that
>> they're will be 8 CPU cores? ;-)
^^^^^^^
That should have read "there", of course. ;-)

> 100, definitely. There's 8 times as many cores to pick up the next
> thread, so 100 Hz will feel faster than 250 Hz on a dual CPU box would
> (which is what I'd recommend for a 2-cpu or dual-core workstation), and
> only slightly slower than 1000 Hz on a single-CPU box. Each CPU switching
> less often means the CPU cache and pipeline won't have to be filled again
> as often, which increases the overall performance, reducing the need for
> switching.
>
> If insane UI responsiveness is the overall goal, I'd still not go above
> 250 Hz.

An insightful reply, thank you. ;-) I hadn't really figured out the finer
points of it all yet. My current kernel is compiled with a 1000 Hz CPU
timer and this machine is a 32-bit dual Xeon with hyperthreading enabled.

There is a general slowness to this system's UI, but this is due to the very
buggy Radeon driver. It was faster with my previous videocard - a Hercules
with a Kyro chip - but that one was not supported by the vendor on 2.6
kernels, and I so had to use a framebuffer driver - so no OpenGL
acceleration and no DPMS. Eventually, the card also broke down, leaving
the system running normally but forcing me to blindly issue a...

shutdown -r now

.... command in a root console, which I fortunately could access via a
desktop-switching shortcut key combination. ;-)

Either way, I'm not going to sit and wait until AMD opens up the ATI driver
code to X.Org. My next machine will have an nVidia again. ;-)

--
With kind regards,

*Aragorn*
(registered GNU/Linux user #223157)