kernel module support broken on x86-64?

Quoted 12 lines · [email protected] wrote:

Hi!

I've compiled an UML kernel based on 2.6.25 but loading kernel modules seems to be broken. No matter which module I try to load the output looks similar to this:

overflow in relocation type 11 val 80836d41
'loop' likely not compiled with -mcmodel=kernel

After searching for a while I found some threads from 2006 discussing this issue, e.g.:
http://www.mail-archive.com/[email protected]/msg03693.html
and
http://marc.info/?l=user-mode-linux-devel&m=115125101012707&w=2

Quoted 9 lines

As Andi Kleen has mentioned in a mail from the first thread, simply appending "-mcmodel=kernel" to the KBUILD_CFLAGS does not work (I tried it anyway and can confirm his statement ;)

Since I could not find any solution I've decided to write this mail and ask about the current state of this issue and of course for a solution! I simply don't want to believe that there is no loadable module support for UML in 2008...

Regards
JK

Every thing is fine down here. What host Kernel-gcc-glibc / uml-gcc-glibc are you using?

I'm using out-of-tree modules with uml for every kernel since 2.6.19. I have both Host and UML as x86_64 on FC7 with gcc 4.1.2

Boaz

Quoted 31 lines · Boaz Harrosh

Quoted 19 lines · [email protected] wrote:

Hi!

I've compiled an UML kernel based on 2.6.25 but loading kernel modules
seems to be broken. No matter which module I try to load the output looks similar to this:

overflow in relocation type 11 val 80836d41
'loop' likely not compiled with -mcmodel=kernel

After searching for a while I found some threads from 2006 discussing this issue, e.g.:
http://www.mail-archive.com/[email protected]/msg03693.html
and
http://marc.info/?l=user-mode-linux-devel&m=115125101012707&w=2

As Andi Kleen has mentioned in a mail from the first thread, simply appending "-mcmodel=kernel" to the KBUILD_CFLAGS does not work (I tried it anyway and can confirm his statement ;)

Quoted 9 lines

Since I could not find any solution I've decided to write this mail and ask about the current state of this issue and of course for a solution! I simply don't want to believe that there is no loadable module support for UML in 2008...

Regards
JK

Quoted 9 lines

Every thing is fine down here. What host Kernel-gcc-glibc / uml-gcc-glibc are you using?

I'm using out-of-tree modules with uml for every kernel since 2.6.19. I have both Host and UML as x86_64 on FC7 with gcc 4.1.2

Boaz

I'm glad to here that the bug has been fixed. Anyway, it does not work with my configuration:

- CentOS 5.1 as host system and UML root fs
- Kernel 2.6.25.4 (vanilla, but config taken from the CentOS kernel)
- GCC 4.1.2
- GLIBC 2.5

Regards
JK

Quoted 48 lines · [email protected] wrote:

Quoted 26 lines · Boaz Harrosh

Quoted 12 lines · [email protected] wrote:

Hi!

I've compiled an UML kernel based on 2.6.25 but loading kernel modules seems to be broken. No matter which module I try to load the output looks similar to this:

overflow in relocation type 11 val 80836d41
'loop' likely not compiled with -mcmodel=kernel

After searching for a while I found some threads from 2006 discussing this issue, e.g.:
http://www.mail-archive.com/[email protected]/msg03693.html
and
http://marc.info/?l=user-mode-linux-devel&m=115125101012707&w=2

Quoted 10 lines

As Andi Kleen has mentioned in a mail from the first thread, simply appending "-mcmodel=kernel" to the KBUILD_CFLAGS does not work (I tried it anyway and can confirm his statement ;)

Since I could not find any solution I've decided to write this mail and ask about the current state of this issue and of course for a solution! I simply don't want to believe that there is no loadable module support for UML in 2008...

Regards
JK

Quoted 11 lines

Every thing is fine down here. What host Kernel-gcc-glibc / uml-gcc-glibc are you using?

I'm using out-of-tree modules with uml for every kernel since 2.6.19. I have both Host and UML as x86_64 on FC7 with gcc 4.1.2

Boaz

I'm glad to here that the bug has been fixed. Anyway, it does not work with my configuration:

- CentOS 5.1 as host system and UML root fs
- Kernel 2.6.25.4 (vanilla, but config taken from the CentOS kernel)
- GCC 4.1.2
- GLIBC 2.5

Quoted 5 lines

Regards
JK

I used to run with red-hat 4.5 so this should work. 64 bit, right?

work if I first do "make ARCH=um defconfig" and then manually enable any needed options with make xconfig. other wise it breaks in all kind of ways. Even doing a make oldconfig on a good uml config file from older kernel will not work. Try to do defconfig and see if it loads at all.

How do you compile and run the out-of-tree module or is it one of the built in modules?

Boaz

Quoted 70 lines · Boaz Harrosh

Quoted 47 lines · [email protected] wrote:

Quoted 32 lines · Boaz Harrosh

Quoted 19 lines · [email protected] wrote:

Hi!

I've compiled an UML kernel based on 2.6.25 but loading kernel modules
seems to be broken. No matter which module I try to load the output looks similar to this:

overflow in relocation type 11 val 80836d41
'loop' likely not compiled with -mcmodel=kernel

After searching for a while I found some threads from 2006 discussing this issue, e.g.:
http://www.mail-archive.com/[email protected]/msg03693.html
and
http://marc.info/?l=user-mode-linux-devel&m=115125101012707&w=2

As Andi Kleen has mentioned in a mail from the first thread, simply appending "-mcmodel=kernel" to the KBUILD_CFLAGS does not work (I tried it anyway and can confirm his statement ;)

Quoted 10 lines

Since I could not find any solution I've decided to write this mail and ask about the current state of this issue and of course for a solution! I simply don't want to believe that there is no loadable module support for UML in 2008...

Regards
JK

Quoted 10 lines

Every thing is fine down here. What host Kernel-gcc-glibc / uml-gcc-glibc are you using?

I'm using out-of-tree modules with uml for every kernel since 2.6.19. I have both Host and UML as x86_64 on FC7 with gcc 4.1.2

Boaz

I'm glad to here that the bug has been fixed. Anyway, it does not work with my configuration:

Quoted 9 lines

- CentOS 5.1 as host system and UML root fs
- Kernel 2.6.25.4 (vanilla, but config taken from the CentOS kernel)
- GCC 4.1.2
- GLIBC 2.5

Regards
JK

I used to run with red-hat 4.5 so this should work. 64 bit, right?

From passed experience I've seen that UML will only work if I first do "make ARCH=um defconfig" and then manually enable any needed options with make xconfig. other wise it breaks in all kind of ways. Even doing a make oldconfig on a good uml config file from older kernel will not work. Try to do defconfig and see if it loads at all.

Quoted 6 lines

How do you compile and run the out-of-tree module or is it one of the built in modules?

Boaz

I tried what you've suggested and did the following:
- make mrproper
- make defconfig ARCH=um
- make linux ARCH=um
- make modules ARCH=um
- make modules_install INSTALL_MOD_PATH=/path/to/mounted/uml_root_fs ARCH=um

It did not work (same result).

After that, I copied the kernel source to the uml-root-fs, started the UML and did a 'make clean' and 'make modules ARCH=um' inside the running UML, followed by a 'make modules_install'. Again, it did not work.

After that, I've extracted the kernel source again (completely vanilla) and restarted at 'make defconfig'. Same result.
No module is loadable. They all have 'invalid fomrat' an the usage of the '-mcmodel=kernel' flag is suggested.

BTW : with the same sources (and the same commands as listed above) I've successfully built a fully working 32 bit UML kernel!

I've also tried kernel 2.6.24.7 with identical results.

Last but not least, I've tried the same with a fresh download of the 2.6.26 kernel. Unfortunately, this time there was another problem: the kernel exits with a panic on startup (tried to build it twice with the same result). According to the stack-trace, the panic happens somewhere inside "get_page_from_free_list()"...

I'm really running out of ideas right now, does anyone have some suggestions?

Regards
JK

Quoted 116 lines · [email protected] wrote:

Quoted 73 lines · Boaz Harrosh

Quoted 47 lines · [email protected] wrote:

Quoted 28 lines · Boaz Harrosh

Quoted 12 lines · [email protected] wrote:

Hi!

I've compiled an UML kernel based on 2.6.25 but loading kernel modules seems to be broken. No matter which module I try to load the output looks similar to this:

overflow in relocation type 11 val 80836d41
'loop' likely not compiled with -mcmodel=kernel

After searching for a while I found some threads from 2006 discussing this issue, e.g.:
http://www.mail-archive.com/[email protected]/msg03693.html
and
http://marc.info/?l=user-mode-linux-devel&m=115125101012707&w=2

Quoted 11 lines

As Andi Kleen has mentioned in a mail from the first thread, simply appending "-mcmodel=kernel" to the KBUILD_CFLAGS does not work (I tried it anyway and can confirm his statement ;)

Since I could not find any solution I've decided to write this mail and ask about the current state of this issue and of course for a solution! I simply don't want to believe that there is no loadable module support for UML in 2008...

Regards
JK

Quoted 12 lines

Every thing is fine down here. What host Kernel-gcc-glibc / uml-gcc-glibc are you using?

I'm using out-of-tree modules with uml for every kernel since 2.6.19. I have both Host and UML as x86_64 on FC7 with gcc 4.1.2

Boaz

I'm glad to here that the bug has been fixed. Anyway, it does not work with my configuration:

Quoted 11 lines

- CentOS 5.1 as host system and UML root fs
- Kernel 2.6.25.4 (vanilla, but config taken from the CentOS kernel)
- GCC 4.1.2
- GLIBC 2.5

Regards
JK

I used to run with red-hat 4.5 so this should work. 64 bit, right?

From passed experience I've seen that UML will only work if I first do "make ARCH=um defconfig" and then manually enable any needed options with make xconfig. other wise it breaks in all kind of ways. Even doing a make oldconfig on a good uml config file from older kernel will not work. Try to do defconfig and see if it loads at all.

Quoted 8 lines

How do you compile and run the out-of-tree module or is it one of the built in modules?

Boaz

I tried what you've suggested and did the following:
- make mrproper
- make defconfig ARCH=um
- make linux ARCH=um
- make modules ARCH=um
- make modules_install INSTALL_MOD_PATH=/path/to/mounted/uml_root_fs ARCH=um

It did not work (same result).

After that, I copied the kernel source to the uml-root-fs, started the UML and did a 'make clean' and 'make modules ARCH=um' inside the running UML, followed by a 'make modules_install'. Again, it did not work.

After that, I've extracted the kernel source again (completely vanilla) and restarted at 'make defconfig'. Same result.
No module is loadable. They all have 'invalid fomrat' an the usage of the '-mcmodel=kernel' flag is suggested.

BTW : with the same sources (and the same commands as listed above) I've successfully built a fully working 32 bit UML kernel!

I've also tried kernel 2.6.24.7 with identical results.

Last but not least, I've tried the same with a fresh download of the 2.6.26 kernel. Unfortunately, this time there was another problem: the kernel exits with a panic on startup (tried to build it twice with the same result). According to the stack-trace, the panic happens somewhere inside "get_page_from_free_list()"...

I'm really running out of ideas right now, does anyone have some suggestions?

Quoted 5 lines

Regards
JK

It all works down here. Just a long shot you have installed uml_utilities on the host ...

I run the uml from the root of the source tree like this:
.../.build_um/vmlinux ubd0=/usr0/var/local/um/Fedora7-AMD64-root_fs eth0=tuntap,,,192.168.0.117 mem=256M (The .build_um/ is because I use KBUILD_OUTPUT=.build_um so I can compile multiple targets from same source tree)

Maybe there is some package missing from the Linux image you are using. You are using a 64bit Linux image with your 64bit kernel, yes? Try to compare the 32 bit image with the 64bit one. See if they have the same packages installed. I started with a ready made fedora7 uml image and never really touched it much except the occasional yum install of a library or two.

Boaz

Quoted 118 lines · Boaz Harrosh

Quoted 116 lines · [email protected] wrote:

Quoted 75 lines · Boaz Harrosh

Quoted 51 lines · [email protected] wrote:

Quoted 34 lines · Boaz Harrosh

Quoted 19 lines · [email protected] wrote:

Hi!

I've compiled an UML kernel based on 2.6.25 but loading kernel modules
seems to be broken. No matter which module I try to load the output looks similar to this:

overflow in relocation type 11 val 80836d41
'loop' likely not compiled with -mcmodel=kernel

After searching for a while I found some threads from 2006 discussing this issue, e.g.:
http://www.mail-archive.com/[email protected]/msg03693.html
and
http://marc.info/?l=user-mode-linux-devel&m=115125101012707&w=2

As Andi Kleen has mentioned in a mail from the first thread, simply appending "-mcmodel=kernel" to the KBUILD_CFLAGS does not work (I tried it anyway and can confirm his statement ;)

Quoted 11 lines

Since I could not find any solution I've decided to write this mail and ask about the current state of this issue and of course for a solution! I simply don't want to believe that there is no loadable module support for UML in 2008...

Regards
JK

Quoted 11 lines

Every thing is fine down here. What host Kernel-gcc-glibc / uml-gcc-glibc are you using?

I'm using out-of-tree modules with uml for every kernel since 2.6.19. I have both Host and UML as x86_64 on FC7 with gcc 4.1.2

Boaz

I'm glad to here that the bug has been fixed. Anyway, it does not work with my configuration:

Quoted 10 lines

- CentOS 5.1 as host system and UML root fs
- Kernel 2.6.25.4 (vanilla, but config taken from the CentOS kernel)
- GCC 4.1.2
- GLIBC 2.5

Regards
JK

I used to run with red-hat 4.5 so this should work. 64 bit, right?

From passed experience I've seen that UML will only work if I first do "make ARCH=um defconfig" and then manually enable any needed options with make xconfig. other wise it breaks in all kind of ways. Even doing a make oldconfig on a good uml config file from older kernel will not work. Try to do defconfig and see if it loads at all.

Quoted 7 lines

How do you compile and run the out-of-tree module or is it one of the built in modules?

Boaz

I tried what you've suggested and did the following:
- make mrproper
- make defconfig ARCH=um
- make linux ARCH=um
- make modules ARCH=um
- make modules_install INSTALL_MOD_PATH=/path/to/mounted/uml_root_fs ARCH=um

It did not work (same result).

After that, I copied the kernel source to the uml-root-fs, started the UML and did a 'make clean' and 'make modules ARCH=um' inside the running UML, followed by a 'make modules_install'. Again, it did not work.

After that, I've extracted the kernel source again (completely vanilla) and restarted at 'make defconfig'. Same result.
No module is loadable. They all have 'invalid fomrat' an the usage of the '-mcmodel=kernel' flag is suggested.

BTW : with the same sources (and the same commands as listed above) I've successfully built a fully working 32 bit UML kernel!

I've also tried kernel 2.6.24.7 with identical results.

Last but not least, I've tried the same with a fresh download of the 2.6.26 kernel. Unfortunately, this time there was another problem: the kernel exits with a panic on startup (tried to build it twice with the same result). According to the stack-trace, the panic happens somewhere inside "get_page_from_free_list()"...

I'm really running out of ideas right now, does anyone have some suggestions?

Quoted 8 lines

Quoted 4 lines

Regards
JK

It all works down here. Just a long shot you have installed uml_utilities on the host ...

They are installed.

Quoted 5 lines

I run the uml from the root of the source tree like this:
......./.build_um/vmlinux ubd0=/usr0/var/local/um/Fedora7-AMD64-root_fs eth0=tuntap,,,192.168.0.117 mem=256M (The .build_um/ is because I use KBUILD_OUTPUT=.build_um so I can compile
multiple targets from same source tree)

Quoted 9 lines

Maybe there is some package missing from the Linux image you are using. You are using a 64bit Linux image with your 64bit kernel, yes? Try to compare the 32 bit image with the 64bit one. See if they have the same packages installed. I started with a ready made fedora7 uml image and never really touched it much except the occasional yum install of a library or two.

Boaz

I already thought about the root fs being the reason for this, but I can't imagine how a different root can affect the kernel's ability to load modules. It should not be affected by any packages installed, isn't it?
Anyway, after taking a closer look to your starting command, I noticed
another difference: I've always been using "mem=512m" on the 64 bit system (it's an 8 GB machine). I've tried it with "mem=256" and IT FINALLY WORKS! All the kernels I've compiled are working correctly now, except for the 2.6.26 which still exits with a panic on startup...

Thank you very much for your help! But I'd really like to know why it did not work with "m= 512m". I've always thought that this would only alter the max. available memory inside the UML. Maybe this is a bug though?

Regards
JK

[email protected] wrote:
<snip>

Quoted 3 lines

except for the 2.6.26 which still exits with a panic on startup...

BTW: v2.6.26 checkout from Linus git crashes for me too 2.6.27-rc1 is fine (except it has another problem which I'm bisecting now)

here is the BUG_ON trace:
Stub registers -

        0 - 0
        1 - 0
        2 - 0
        3 - 0
        4 - 0
        5 - 0
        6 - 0
        7 - 0
        8 - 0
        9 - 0
        10 - 0
        11 - 0
        12 - 0
        13 - 0
        14 - 0
        15 - ffffffffffffffff
        16 - 0
        17 - 33
        18 - 10216
        19 - 2aaaaaab0f30
        20 - 2b
        21 - 2aaaaaaad910
        22 - 0
        23 - 0
        24 - 0
        25 - 0
        26 - 0
wait_stub_done : failed to wait for SIGTRAP, pid = 1348, n = 1348, errno = 0, status = 0xb7f
Kernel panic - not syncing: Attempted to kill init!

Modules linked in:
Pid: 1, comm: swapper Not tainted 2.6.26
RIP: 0033:[<000000319e430a57>]
RSP: 00007fff26d69cd8  EFLAGS: 00000206
RAX: 0000000000000000 RBX: 000000000000053e RCX: ffffffffffffffff
RDX: 0000000000000000 RSI: 0000000000000013 RDI: 000000000000053e
RBP: 00007fff26d69d00 R08: 0000000000000000 R09: 00007fff26d69d00
R10: 0000000000000000 R11: 0000000000000206 R12: 000000000000053a
R13: 0000000000000004 R14: 00007fff26d6b58c R15: 00007fff26d69fc0
Call Trace:
6fc21778:  [<60013bc1>] panic_exit+0x2f/0x45
6fc21798:  [<600412f5>] notifier_call_chain+0x33/0x5b
6fc217d8:  [<60041326>] __atomic_notifier_call_chain+0x9/0xb
6fc217e8:  [<60041337>] atomic_notifier_call_chain+0xf/0x11
6fc217f8:  [<6002b8a1>] panic+0xe6/0x17d
6fc21818:  [<60053abe>] get_page_from_freelist+0x2a1/0x41f
6fc218b8:  [<6006a144>] kmem_cache_free+0x55/0x5e
6fc218e8:  [<6002eca3>] do_exit+0x6b/0x694
6fc21908:  [<60036bcd>] __dequeue_signal+0x10e/0x172
6fc21958:  [<6002f35c>] do_group_exit+0x90/0xbf
6fc21998:  [<60037c30>] get_signal_to_deliver+0x2ca/0x318
6fc219b8:  [<60026b7f>] wake_up_state+0xb/0xd
6fc219f8:  [<6001202d>] do_signal+0x1f8/0x2ca
6fc21a58:  [<6002023a>] set_signals+0x1c/0x2e
6fc21a78:  [<6003644f>] force_sig_info+0xb0/0xbf
6fc21ae8:  [<60013a26>] fatal_sigsegv+0x28/0x2d
6fc21b08:  [<60022647>] wait_stub_done+0xbd/0xc8
6fc21b48:  [<60021dd0>] do_syscall_stub+0xbb/0x1b6
6fc21b88:  [<60022032>] run_syscall_stub+0xd1/0xdd
6fc21bc8:  [<60023396>] write_ldt_entry+0x111/0x180
6fc21c48:  [<600235e4>] init_new_ldt+0x1df/0x303
6fc21c68:  [<60053cd6>] __alloc_pages_internal+0x9a/0x36e
6fc21cb8:  [<60053fc0>] __alloc_pages+0xb/0xd
6fc21d18:  [<60013fa4>] init_new_context+0xc9/0x10d
6fc21d28:  [<6002ab7b>] mm_alloc+0x4c/0x53
6fc21d58:  [<600711ce>] bprm_mm_init+0x4c/0x168
6fc21da8:  [<60071f6a>] do_execve+0x89/0x1db
6fc21dd8:  [<6000a854>] tcp_congestion_default+0x0/0x10
6fc21df8:  [<60010257>] execve1+0x27/0x42
6fc21e28:  [<600102cf>] um_execve+0xd/0x36
6fc21e38:  [<6006b945>] do_sys_open+0xc9/0xd8
6fc21e48:  [<60012354>] kernel_execve+0x2d/0x38
6fc21e78:  [<6000ff72>] run_init_process+0x1a/0x1c
6fc21e88:  [<60010029>] init_post+0xb5/0xe0
6fc21ea8:  [<60001574>] kernel_init+0x1d8/0x1e9
6fc21f48:  [<6001f309>] run_kernel_thread+0x41/0x4a
6fc21f58:  [<6000139c>] kernel_init+0x0/0x1e9
6fc21f98:  [<6001f2f0>] run_kernel_thread+0x28/0x4a
6fc21fc8:  [<600114be>] new_thread_handler+0x67/0x91

Terminated

Is there a plan to fix this for the 2.6.26 stable ?

Please forgive me if this is old news and it's already been reported.

Boaz

Jeff: Is this queued for 2.6.26-stable ?

I'm glad to here that the bug has been fixed. Anyway, it does not work with my configuration:

- CentOS 5.1 as host system and UML root fs
- Kernel 2.6.25.4 (vanilla, but config taken from the CentOS kernel)
- GCC 4.1.2
- GLIBC 2.5

Quoted 2 lines · On Tue, Aug 05, 2008 at 06:37:18PM +0200, [email protected] wrote:

I'm glad to here that the bug has been fixed. Anyway, it does not work with my configuration:

Quoted 6 lines

- CentOS 5.1 as host system and UML root fs
- Kernel 2.6.25.4 (vanilla, but config taken from the CentOS kernel)
- GCC 4.1.2
- GLIBC 2.5

I'm not sure that anything was ever broken.

You are building the modules against a UML tree, with ARCH=um on the make line? I.e. you're not trying to load a host module into UML?

Jeff