[uml-devel] x86_64 when mem > 384M loadable modules do not work

Boaz Harrosh

author

2013-11-28 14:41 UTC #0 lore raw

Hi um hackers

I'm using an x86_64 deployment both host and um-guest. (Fedora 18)

When I load with mem=384M all is well but anything bigger will eventually give me problems because loadable modules will no longer load. The bigger mem= is, the earlier it will start.

When the Kernel tries to load the .ko driver I get these messages:

subarch: overflow in relocation type 11 val 805b1e40
subarch: `nfsv4' likely not compiled with -mcmodel=kernel
subarch: overflow in relocation type 11 val 806e4ca0
subarch: `nfsv3' likely not compiled with -mcmodel=kernel
...

(The first print is always around that same number
805b1e40 independent of the mem= (> 384M)
)

Do you guys see the same problem? I'm using loadable modules because it is kind of mandatory for the kind of development I do.

Please help because 384M is not enough for me anymore, even when I define a swap device for the uml to use.

Thanks in advance
Boaz

------------------------------------------------------------------------------
Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk
_______________________________________________
User-mode-linux-devel mailing list [email protected]
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Richard Weinberger

maintainer

2013-11-28 15:47 UTC #1 lore raw

Am Donnerstag, 28. November 2013, 16:40:48 schrieb Boaz Harrosh:

Quoted 21 lines

Hi um hackers
I'm using an x86_64 deployment both host and um-guest. (Fedora 18)
When I load with mem=384M all is well but anything bigger will eventually give me problems because loadable modules will no longer load. The bigger mem= is, the earlier it will start.
When the Kernel tries to load the .ko driver I get these messages:
subarch: overflow in relocation type 11 val 805b1e40
subarch: `nfsv4' likely not compiled with -mcmodel=kernel
subarch: overflow in relocation type 11 val 806e4ca0
subarch: `nfsv3' likely not compiled with -mcmodel=kernel
...
(The first print is always around that same number
805b1e40 independent of the mem= (> 384M)
)

Quoted 6 lines

Do you guys see the same problem? I'm using loadable modules because it is kind of mandatory for the kind of development I do.
Please help because 384M is not enough for me anymore, even when I define a swap device for the uml to use.

/me has a deja vu.
I've fixed that issue some time ago.

Let's see why it happens again. :)

Thanks,
//richard

------------------------------------------------------------------------------
Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk
_______________________________________________
User-mode-linux-devel mailing list [email protected]
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Richard Weinberger

maintainer

2013-11-28 16:09 UTC #2 lore raw

In reply to Boaz Harrosh

Am Donnerstag, 28. November 2013, 16:40:48 schrieb Boaz Harrosh:

Quoted 21 lines

Hi um hackers
I'm using an x86_64 deployment both host and um-guest. (Fedora 18)
When I load with mem=384M all is well but anything bigger will eventually give me problems because loadable modules will no longer load. The bigger mem= is, the earlier it will start.
When the Kernel tries to load the .ko driver I get these messages:
subarch: overflow in relocation type 11 val 805b1e40
subarch: `nfsv4' likely not compiled with -mcmodel=kernel
subarch: overflow in relocation type 11 val 806e4ca0
subarch: `nfsv3' likely not compiled with -mcmodel=kernel
...
(The first print is always around that same number
805b1e40 independent of the mem= (> 384M)
)

Quoted 6 lines

Do you guys see the same problem? I'm using loadable modules because it is kind of mandatory for the kind of development I do.
Please help because 384M is not enough for me anymore, even when I define a swap device for the uml to use.

Does the attached patch fix the issue?

Thanks,
//richard

arch/um/Makefile +1 -2

index 48d92bb..5ab2b17 100644
@@ -36,8 +36,7 @@ HEADER_ARCH 	:= $(SUBARCH)
 # Additional ARCH settings for x86
 ifeq ($(SUBARCH),i386)
         HEADER_ARCH := x86
-endif
-ifeq ($(SUBARCH),x86_64)
+else
         HEADER_ARCH := x86
 	KBUILD_CFLAGS += -mcmodel=large
 endif

------------------------------------------------------------------------------
Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk

_______________________________________________
User-mode-linux-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Boaz Harrosh

author

2013-12-01 11:46 UTC #3 lore raw

Quoted 3 lines · Richard Weinberger

Does the attached patch fix the issue?

Yes it is good. I'm very grateful. With this I now am able to fully stress the UML Fedora18 and almost not get stuck at all.

(stuckness is usually do to stressed system and allocation
failing where Kernel would not cope, but an HW system would fail just the same)

Quoted 3 lines

Thanks,
//richard

Thank you sir Richard. One very happy camper here
Boaz

------------------------------------------------------------------------------
Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk
_______________________________________________
User-mode-linux-devel mailing list [email protected]
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel