-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
What are the chances of getting an ia32e specific kernel in the x86_64 version of Fedora Core 3? We're starting to ship Nacona based systems, and we have always done Fedora Core pre-installs. While the x86_64 kernel of FC2 works now, I thought it was in some sort of 'compatible 64bit' mode rather than ia32e or em64t specific mode.
I guess a better question: With kernel 2.6, is there any need to have a specific ia32e vs amd64 kernel? Are all the differences worked out at runtime and thus a non-issue? Thanks.
- -- Jesse Keating RHCE (http://geek.j2solutions.net) Fedora Legacy Team (http://www.fedoralegacy.org) GPG Public Key (http://geek.j2solutions.net/jkeating.j2solutions.pub)
Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating
On Mon, 2004-09-06 at 19:11, Jesse Keating wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
What are the chances of getting an ia32e specific kernel in the x86_64 version of Fedora Core 3? We're starting to ship Nacona based systems, and we have always done Fedora Core pre-installs. While the x86_64 kernel of FC2 works now, I thought it was in some sort of 'compatible 64bit' mode rather than ia32e or em64t specific mode.
I guess a better question: With kernel 2.6, is there any need to have a specific ia32e vs amd64 kernel? Are all the differences worked out at runtime and thus a non-issue?
it's all runtime. The extra amd64 instructions are patched in at runtime no problem....
On Mon, Sep 06, 2004 at 10:11:51AM -0700, Jesse Keating wrote:
I guess a better question: With kernel 2.6, is there any need to have a specific ia32e vs amd64 kernel? Are all the differences worked out at runtime and thus a non-issue? Thanks.
em64t as Intel currently call it is pretty close to the x86-64 architecture so its not too bad a clone. It lacks prefetch/prefetchw which can also be used by some fancy user space stuff like image processors. It also lacks a hardware IOMMU so you may have performance problems going above about 3.5Gb of RAM depending on your other hardware.
Alan
On Mon, 2004-09-06 at 13:47 -0400, Alan Cox wrote:
em64t as Intel currently call it is pretty close to the x86-64 architecture so its not too bad a clone. It lacks prefetch/prefetchw which can also be used by some fancy user space stuff like image processors.
Er, EM64T provides the SSE prefetch{nta,t[012]} instructions, which are somewhat more expressive than prefetch anyway, and which also run on AMD chips. Shame about the lack of a prefetchw analogue, but it's hardly a surprise that Intel isn't implementing 3dnow.
<b
On Mon, Sep 06, 2004 at 10:44:47PM -0700, Bryan O'Sullivan wrote:
On Mon, 2004-09-06 at 13:47 -0400, Alan Cox wrote:
em64t as Intel currently call it is pretty close to the x86-64 architecture so its not too bad a clone. It lacks prefetch/prefetchw which can also be used by some fancy user space stuff like image processors.
Er, EM64T provides the SSE prefetch{nta,t[012]} instructions, which are somewhat more expressive than prefetch anyway, and which also run on AMD
Somewhat more and somewhat less expressive to be exact. SSE prefetches allow you to specify locality very well, 3dNOW prefetch allows prefetching for write, but no locality. If GCC knows both SSE and 3dNOW prefetches are available, it will use 3dNOW prefetch for __builtin_prefetch (p, 1, [0-3]) (and disregard the locality) and SSE prefetch for __builtin_prefetch (p, 0, [0-3]) (where locality is used).
chips. Shame about the lack of a prefetchw analogue, but it's hardly a surprise that Intel isn't implementing 3dnow.
Jakub
On Mon, Sep 06, 2004 at 10:44:47PM -0700, Bryan O'Sullivan wrote:
On Mon, 2004-09-06 at 13:47 -0400, Alan Cox wrote:
em64t as Intel currently call it is pretty close to the x86-64 architecture so its not too bad a clone. It lacks prefetch/prefetchw which can also be used by some fancy user space stuff like image processors.
Er, EM64T provides the SSE prefetch{nta,t[012]} instructions, which are somewhat more expressive than prefetch anyway, and which also run on AMD chips. Shame about the lack of a prefetchw analogue, but it's hardly a surprise that Intel isn't implementing 3dnow.
x86-64 requires prefetch/prefetchw. It's in the specification.
Alan
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Monday 06 September 2004 10:47, Alan Cox wrote:
em64t as Intel currently call it is pretty close to the x86-64 architecture so its not too bad a clone. It lacks prefetch/prefetchw which can also be used by some fancy user space stuff like image processors. It also lacks a hardware IOMMU so you may have performance problems going above about 3.5Gb of RAM depending on your other hardware.
I know they are similar, and em64t lacks some things that AMD64 has, however we have lots of customers that refuse to run anything but Intel, and they want to run Naconas. I'm just making sure that the performance hit they get against Opteron isn't due to misconfigured software. If what Arjan says is true, and it's a runtime detection thing and I don't have to build a complete kernel optimized for em64t than that is cool. Thanks.
- -- Jesse Keating RHCE (http://geek.j2solutions.net) Fedora Legacy Team (http://www.fedoralegacy.org) GPG Public Key (http://geek.j2solutions.net/jkeating.j2solutions.pub)
Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating
Alan Cox wrote:
On Mon, Sep 06, 2004 at 10:11:51AM -0700, Jesse Keating wrote:
I guess a better question: With kernel 2.6, is there any need to have a specific ia32e vs amd64 kernel? Are all the differences worked out at runtime and thus a non-issue? Thanks.
em64t as Intel currently call it is pretty close to the x86-64 architecture so its not too bad a clone. It lacks prefetch/prefetchw which can also be used by some fancy user space stuff like image processors. It also lacks a hardware IOMMU so you may have performance problems going above about 3.5Gb of RAM depending on your other hardware.
Sorry for following up on an old thread...
I have a Xeon/EM64T machine with 4G.
FC3-32bit installs without problems, 4G available.
FC3 x86-64 doesn't install, no disks are found.
If I boot FC3 x86-64 installation with mem=3072M, there are no problems.
I have to add mem=3072M to grub after the installation to get a running system.
The funny thing is, if I write mem=4096M, it still boots, but only 3G memory is available.
I can see from /proc/iomem that there are devices starting at the 3G address, so my guess is that I've run into the problem described above.
Is there any way to get a x86-64 kernel to use all 4G?
Mogens
On Wed, 2004-12-22 at 08:23 +0100, Mogens Kjaer wrote:
I have a Xeon/EM64T machine with 4G.
FC3-32bit installs without problems, 4G available.
FC3 x86-64 doesn't install, no disks are found.
If I boot FC3 x86-64 installation with mem=3072M, there are no problems.
I have to add mem=3072M to grub after the installation to get a running system.
The funny thing is, if I write mem=4096M, it still boots, but only 3G memory is available.
this is a known issue and I think is fixed now; not sure if the kernel with the fix has gone out of testing yet.
Arjan van de Ven wrote:
On Wed, 2004-12-22 at 08:23 +0100, Mogens Kjaer wrote:
...
The funny thing is, if I write mem=4096M, it still boots, but only 3G memory is available.
this is a known issue and I think is fixed now; not sure if the kernel with the fix has gone out of testing yet.
Thanks, with kernel-smp-2.6.9-1.1047_FC4.x86_64.rpm I get 4G of RAM.
However, now the (reinstalled) nvidia driver won't work - but I guess this is not your problem :-)
The nvidia module loads (with a warning about increasing swiotlb), but it fails with rm_init_adapter failed. I tried setting swiotlb to 16384 or 32768, but it didn't help.
Mogens
On Wed, Dec 22, 2004 at 01:56:22PM +0100, Mogens Kjaer wrote:
The nvidia module loads (with a warning about increasing swiotlb), but it fails with rm_init_adapter failed. I tried setting swiotlb to 16384 or 32768, but it didn't help.
Correct. The Nvidia driver wants huge amounts of I/O memory space below 32bit. Various other drivers have similar issues due to the lack of an IOMMU. There has been some discussion and proposals on the kernel list about ways to handle this better but that is certainly not likely to occur until after 2.6.10
On Wed, Dec 22, 2004 at 08:23:36AM +0100, Mogens Kjaer wrote:
FC3-32bit installs without problems, 4G available. FC3 x86-64 doesn't install, no disks are found.
SATA ? If so you are hitting a known limit/bug in the older SATA code that Jeff has now fixed up.
The funny thing is, if I write mem=4096M, it still boots, but only 3G memory is available.
Typically the extra memory is mapped higher than 4Gb and a 512Mb-1Gb hole is left for the PCI devices.
devel@lists.stg.fedoraproject.org
-
Alan Cox -
Arjan van de Ven -
Bryan O'Sullivan -
Jakub Jelinek -
Jesse Keating -
Mogens Kjaer