f



32-bit runtime under 64-bit kernel

What does it take to modify a 32-bit runtime filesystem tree so it can run
under a 64-bit kernel?  Is the VM memory model for a 32-bit process the same
in both kernels?  I've been told that the syscall interface is "compatible"
(which I take to mean the 64-bit kernel accepts 32-bit syscalls).  But so far
attempts to run 64-bit kernel on a 32-bit filesystem tree results in kernel
panic.

-- 
|WARNING: Due to extreme spam, googlegroups.com is blocked.  Due to ignorance |
|         by the abuse department, bellsouth.net is blocked.  If you post to  |
|         Usenet from these places, find another Usenet provider ASAP.        |
| Phil Howard KA9WGN (email for humans: first name in lower case at ipal.net) |
0
phil
12/26/2008 2:24:15 PM
comp.linux.development.system 5436 articles. 0 followers. zixenus (12) is leader. Post Follow

4 Replies
524 Views

Similar Articles

[PageSpeed] 5

phil-news-nospam@ipal.net writes:

> What does it take to modify a 32-bit runtime filesystem tree so it can run
> under a 64-bit kernel?  Is the VM memory model for a 32-bit process the same
> in both kernels?  I've been told that the syscall interface is "compatible"
> (which I take to mean the 64-bit kernel accepts 32-bit syscalls).  But so far
> attempts to run 64-bit kernel on a 32-bit filesystem tree results in kernel
> panic.

It should work.  Maybe there's some option in the kernel that needs to
be enabled for it to work; I don't remember.  You obviously need to
run it on 64-bit hardware.

-- 
M�ns Rullg�rd
mans@mansr.com
0
iso
12/26/2008 3:29:41 PM
phil-news-nospam@ipal.net wrote:
> What does it take to modify a 32-bit runtime filesystem tree so it can run
> under a 64-bit kernel?  Is the VM memory model for a 32-bit process the same
> in both kernels?

No.  Contrast the output from these commands running on a 64-bit system:
   cat    /proc/self/maps  # 64-bit 'cat'
   cat.32 /proc/self/maps  # 32-bit 'cat'
One difference is that the user address space on a 32-bit system often is
0-0xc0000000, while on a 64-bit system the user address space of a 32-bit
process often is 0-0xff000000 or so (almost 1GByte more.)

> I've been told that the syscall interface is "compatible"
> (which I take to mean the 64-bit kernel accepts 32-bit syscalls).  But so far
> attempts to run 64-bit kernel on a 32-bit filesystem tree results in kernel
> panic.

Get specific.  Identify the kernel and the filesystem.  Post the panic message
and the traceback.  If necessary, then capture the messages by booting with
serial console [UART], connected via null modem to another machine running
minicom.  See Documentation/serial-console.txt.

One significant early mistake is trying to use 32-bit drivers in a 64-bit
kernel.  The initrd/initramfs, plus any drivers loaded from /lib/modules/...,
must match the kernel.  One typical symptom is not having drivers for jbd
and ext3, which results in a panic because the ultimate root filesystem
cannot be mounted.

-- 
0
John
12/26/2008 4:46:57 PM
On Fri, 26 Dec 2008 15:29:41 +0000 M?ns Rullg?rd <mans@mansr.com> wrote:
| phil-news-nospam@ipal.net writes:
| 
|> What does it take to modify a 32-bit runtime filesystem tree so it can run
|> under a 64-bit kernel?  Is the VM memory model for a 32-bit process the same
|> in both kernels?  I've been told that the syscall interface is "compatible"
|> (which I take to mean the 64-bit kernel accepts 32-bit syscalls).  But so far
|> attempts to run 64-bit kernel on a 32-bit filesystem tree results in kernel
|> panic.
| 
| It should work.  Maybe there's some option in the kernel that needs to
| be enabled for it to work; I don't remember.  You obviously need to
| run it on 64-bit hardware.

I have 64-bit hardware.  64-bit Ubuntu (amd64) DVD boots and runs just fine.
In one machine it's a dual socket dual core genuine AMD at 2.8GHz with 8GB.
The other machine has a single socket quad core Intel at 2.66 GHz with 2GB.

When I chroot from 64-bit Ubuntu into my 32-bit filesystem tree on disk, the
processes just segfault.  So maybe the Ubuntu kernel is lacking that config
option during the compile.  But another issue is there are already 64-bit
processes running and the chroot itself was 64-bit.  The change would happen
when execve() loads a program image from the chroot file tree.  But I don't
know if there is really a 32-bit process mode or if execve() allows trivially
changing it.

-- 
|WARNING: Due to extreme spam, googlegroups.com is blocked.  Due to ignorance |
|         by the abuse department, bellsouth.net is blocked.  If you post to  |
|         Usenet from these places, find another Usenet provider ASAP.        |
| Phil Howard KA9WGN (email for humans: first name in lower case at ipal.net) |
0
phil
12/26/2008 6:36:30 PM
On Fri, 26 Dec 2008 08:46:57 -0800 John Reiser <jreiser@bitwagon.com> wrote:

| One significant early mistake is trying to use 32-bit drivers in a 64-bit
| kernel.  The initrd/initramfs, plus any drivers loaded from /lib/modules/...,
| must match the kernel.  One typical symptom is not having drivers for jbd
| and ext3, which results in a panic because the ultimate root filesystem
| cannot be mounted.

D'oh!  This is the problem, though somewhat different than you were thinking.
I forgot that my 32-bit system runs w/o modules and I was trying to boot up
a kernel from Ubuntu amd64.

OK, back to trying to compile my own kernel.

Anyone have an example kernel config file a kernel with all drivers built in
(doesn't have to be very many drivers; just to see an example of configuring
to see why my earlier compile attempts failed)?

-- 
|WARNING: Due to extreme spam, googlegroups.com is blocked.  Due to ignorance |
|         by the abuse department, bellsouth.net is blocked.  If you post to  |
|         Usenet from these places, find another Usenet provider ASAP.        |
| Phil Howard KA9WGN (email for humans: first name in lower case at ipal.net) |
0
phil
12/26/2008 6:45:11 PM
Reply: