I've spent the past week trying to find a full answer on amd64 support.
Maybe I'm just not understanding it, but all I can find are debian howtos.
I'm running 2.4.25 on slack 9.1. I was assuming I could simply recompile
the kernel for the amd64, and then whatever other bits of software I
wanted specifically to run at 64bit, but it's not seeming that way.
Should 2.4.25 be able to run 64bit, or are is it more of an all or nothing
type thing?
Thanks,
Bryan
Bryan Koschmann - GKT <[email protected]> writes:
> I've spent the past week trying to find a full answer on amd64 support.
> Maybe I'm just not understanding it, but all I can find are debian howtos.
Debian seems to have some unique problems in the way they handle AMD64
compared to other distributions. I would not trust what you read
there, they make it much more complicated than it really is. The right
forum would have been [email protected]
> I'm running 2.4.25 on slack 9.1. I was assuming I could simply recompile
> the kernel for the amd64, and then whatever other bits of software I
> wanted specifically to run at 64bit, but it's not seeming that way.
It's that way. You just need a 64bit capable cross compiler to compile
the kernel, which is not that difficult to build from sources. You can also
find binaries for that at
ftp://ftp.suse.com/pub/suse/x86_64/supplementary/CrossTools/8.1-i386/
(usable with rpm2cpio on non RPM distributions). Then you can
cross compile the kernel in the normal way with
make ARCH=x86_64 CROSS_COMPILE=x86_64-linux-
A few programs (namely iptables and ipsec tools) need to be used
as 64bit programs because the 32bit emulation doesn't work for them.
ipchains works though.
> Should 2.4.25 be able to run 64bit, or are is it more of an all or nothing
> type thing?
2.4.25 supports 64bit just fine.
-Andi
On Apr 7, 2004, at 13:29, Andi Kleen wrote:
> A few programs (namely iptables and ipsec tools) need to be used
> as 64bit programs because the 32bit emulation doesn't work for them.
> ipchains works though.
I seem to recall reading that the DM based programs also need to be 64
bit, since their 32 bit stuff was also broken?
The question I have is whether or not this is a kernel bug that should
be fixed? As I understand the DM case, fixing it so that 32bit works,
then breaks the 64bit interfaces, requiring re-compiles of the DM
programs.
Cheers,
Paul
Paul Wagland <[email protected]> writes:
> On Apr 7, 2004, at 13:29, Andi Kleen wrote:
>
>> A few programs (namely iptables and ipsec tools) need to be used
>> as 64bit programs because the 32bit emulation doesn't work for them.
>> ipchains works though.
>
> I seem to recall reading that the DM based programs also need to be 64
> bit, since their 32 bit stuff was also broken?
That was already fixed, but the fix may not be in mainline yet
[and I think it broke ppc64 too]. But right, DM has problems too.
> The question I have is whether or not this is a kernel bug that should
> be fixed? As I understand the DM case, fixing it so that 32bit works,
> then breaks the 64bit interfaces, requiring re-compiles of the DM
> programs.
It is a subsystem bug really. These subsystems were all designed to
not require emulation, but the designers weren't aware of all the
requirements for this and broke it for AMD64/IA64. Unfortunately the
interfaces were done in a way that it would be very complicated and a
lot of work to write an emulation layer, because they're extremly
emulation unfriendly. Maybe it would be still possible to write an
emulation layer, but easier is it to just use static 64bit executables
or hacked 32bit executables.
I don't have any plans to write emulation layers for such hopeless
cases on my own, but just declared these subsystems as broken.
The problem is always the long long alignment. AMD64/IA64 have different
alignment for long long than i386. The emulation was originally tested
on some RISC port, where the alignment is the same.
-Andi
Andi Kleen wrote:
> The problem is always the long long alignment. AMD64/IA64 have different
> alignment for long long than i386. The emulation was originally tested
> on some RISC port, where the alignment is the same.
What about a compiler flag to emit i386 code with the more strenuous
long long alignment?
Chris
On Wed, 7 Apr 2004, Andi Kleen wrote:
> Debian seems to have some unique problems in the way they handle AMD64
> compared to other distributions. I would not trust what you read
> there, they make it much more complicated than it really is. The right
> forum would have been [email protected]
I was hoping that was the case. I wouldn't think the only way would be so
"rigged". I will check out the x86-64 list, thanks for that.
> It's that way. You just need a 64bit capable cross compiler to compile
> the kernel, which is not that difficult to build from sources. You can also
> find binaries for that at
> ftp://ftp.suse.com/pub/suse/x86_64/supplementary/CrossTools/8.1-i386/
> (usable with rpm2cpio on non RPM distributions). Then you can
> cross compile the kernel in the normal way with
> make ARCH=x86_64 CROSS_COMPILE=x86_64-linux-
Great, much better than I had hoped. I always build from source, I'm
guessing I can find something on freshmeat.
> A few programs (namely iptables and ipsec tools) need to be used
> as 64bit programs because the 32bit emulation doesn't work for them.
> ipchains works though.
Okay, thanks for the tip, that probably would have gotten me when I
started installing.
Thanks for all the information Andi, it was extremely helpful!
Bryan
On Wed, Apr 07, 2004 at 12:49:20PM -0400, Chris Friesen wrote:
> Andi Kleen wrote:
>
> >The problem is always the long long alignment. AMD64/IA64 have different
> >alignment for long long than i386. The emulation was originally tested
> >on some RISC port, where the alignment is the same.
>
> What about a compiler flag to emit i386 code with the more strenuous
> long long alignment?
That would break other things, glibc uses long long heavily too.
The only simple way would be to add the necessary alignment by hand and
create a special 32bit on 64bit kernel iptables or ipsec.
-Andi
Andi Kleen wrote:
>It is a subsystem bug really. These subsystems were all designed to
>not require emulation, but the designers weren't aware of all the
>requirements for this and broke it for AMD64/IA64. Unfortunately the
>interfaces were done in a way that it would be very complicated and a
>lot of work to write an emulation layer, because they're extremly
>emulation unfriendly. Maybe it would be still possible to write an
>emulation layer, but easier is it to just use static 64bit executables
>or hacked 32bit executables.
>
>I don't have any plans to write emulation layers for such hopeless
>cases on my own, but just declared these subsystems as broken.
>
>
So let me get this straight, we can't use LVM with AMD64 under the 2.6
line either? Or we can if we use AMD64 [DM] libraries with a AMD64
kernel? DM = Device Mapper right?
-ryan
> So let me get this straight, we can't use LVM with AMD64 under the 2.6
No, you completely misunderstood.
> line either? Or we can if we use AMD64 [DM] libraries with a AMD64
> kernel? DM = Device Mapper right?
You can't use Device Mapper with 32bit user tools on a 64bit kernel
right now.
-Andi
On Sat, Apr 10, 2004 at 08:49:04PM +0200, Andi Kleen wrote:
> > So let me get this straight, we can't use LVM with AMD64 under the 2.6
>
> No, you completely misunderstood.
>
> > line either? Or we can if we use AMD64 [DM] libraries with a AMD64
> > kernel? DM = Device Mapper right?
>
> You can't use Device Mapper with 32bit user tools on a 64bit kernel
> right now.
Well, you can, because that's what I'm doing on this machine. Joe
Thornber posted a patch[1] here a few weeks ago which fixes the
problem in a "sealing-wax-and-string" kind of way. It Works For
Me(tm), which is about all you can say about it -- it's not the
prettiest piece of code, even to my non-kernel eyes. :)
Hugo.
[1] http://marc.theaimsgroup.com/?l=linux-kernel&m=107908531723751&w=2
--
=== Hugo Mills: hugo@... carfax.org.uk | darksatanic.net | lug.org.uk ===
PGP key: 1C335860 from wwwkeys.eu.pgp.net or http://www.carfax.org.uk
--- Ceci est un travail pour l'Australien. ---
Andi Kleen wrote:
>>So let me get this straight, we can't use LVM with AMD64 under the 2.6
>>
>>
>
>No, you completely misunderstood.
>
>
It was ambiguous, I saw more than one valid interpretation.
>>line either? Or we can if we use AMD64 [DM] libraries with a AMD64
>>kernel? DM = Device Mapper right?
>>
>>
>
>You can't use Device Mapper with 32bit user tools on a 64bit kernel
>right now.
>
>
Which doesn't say we can use 64bit user tools with a 64bit kernel, but I
assume this is what you mean.
-ryan
On Apr 10, 2004, at 21:02, Hugo Mills wrote:
> On Sat, Apr 10, 2004 at 08:49:04PM +0200, Andi Kleen wrote:
>>> line either? Or we can if we use AMD64 [DM] libraries with a AMD64
>>> kernel? DM = Device Mapper right?
>>
>> You can't use Device Mapper with 32bit user tools on a 64bit kernel
>> right now.
>
> Well, you can, because that's what I'm doing on this machine. Joe
> Thornber posted a patch[1] here a few weeks ago which fixes the
> problem in a "sealing-wax-and-string" kind of way. It Works For
> Me(tm), which is about all you can say about it -- it's not the
> prettiest piece of code, even to my non-kernel eyes. :)
Ah, yes, but you missed the bit slightly later in the thread where Andi
requested that this not be added to the kernel since it would then
break all currently existing 64bit DM user tools. Newly compiled ones
would, of course, work, but you introduce a DM user tool versioning
problem, where the old 64 bit utils need to be used with old kernels,
and the new tools need to be used with the new kernels. As far as I
understood, this is the "official" line for the mainstream kernel. It
is my hope that the disties all decide to use Thornbers patch when they
do release, but only time will tell...
Of course, this also means that you can't "dual boot" your linux
partition based if you use DM on the fact that you cannot use the same
DM tools. For this reason I would like the problem to be fixed in the
mainline kernel, but that is primarily a selfish concern ;-) as it
makes my own migration harder.
Cheers,
Paul
On Sun, Apr 11, 2004 at 01:37:46PM +0200, Paul Wagland wrote:
>
> On Apr 10, 2004, at 21:02, Hugo Mills wrote:
>
> >On Sat, Apr 10, 2004 at 08:49:04PM +0200, Andi Kleen wrote:
> >>>line either? Or we can if we use AMD64 [DM] libraries with a AMD64
> >>>kernel? DM = Device Mapper right?
> >>
> >>You can't use Device Mapper with 32bit user tools on a 64bit kernel
> >>right now.
> >
> > Well, you can, because that's what I'm doing on this machine. Joe
> >Thornber posted a patch[1] here a few weeks ago which fixes the
> >problem in a "sealing-wax-and-string" kind of way. It Works For
> >Me(tm), which is about all you can say about it -- it's not the
> >prettiest piece of code, even to my non-kernel eyes. :)
>
> Ah, yes, but you missed the bit slightly later in the thread where Andi
> requested that this not be added to the kernel since it would then
> break all currently existing 64bit DM user tools. Newly compiled ones
> would, of course, work, but you introduce a DM user tool versioning
> problem, where the old 64 bit utils need to be used with old kernels,
> and the new tools need to be used with the new kernels. As far as I
> understood, this is the "official" line for the mainstream kernel. It
> is my hope that the disties all decide to use Thornbers patch when they
> do release, but only time will tell...
Sorry, I probably wasn't making myself clear.
I'm well aware of the issues surrounding this patch, and the fact
that it's never going to get into mainline kernels. However, it _does_
allow you to use DM with 32-bit user-space + 64-bit kernel, which was
my only point.
Hugo.
--
=== Hugo Mills: hugo@... carfax.org.uk | darksatanic.net | lug.org.uk ===
PGP key: 1C335860 from wwwkeys.eu.pgp.net or http://www.carfax.org.uk
--- The English language has the mot juste for every occasion. ---