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

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

[Boaz Harrosh]

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
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

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

[Richard Weinberger]

Am Donnerstag, 28. November 2013, 16:40:48 schrieb Boaz Harrosh:
> 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.

/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
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

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

[Richard Weinberger]

[-- Attachment #1: Type: text/plain, Size: 1076 bytes --]

Am Donnerstag, 28. November 2013, 16:40:48 schrieb Boaz Harrosh:
> 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.

Does the attached patch fix the issue?

Thanks,
//richard

[-- Attachment #2: fix_subarch.diff --]
[-- Type: text/x-patch, Size: 366 bytes --]

diff --git a/arch/um/Makefile b/arch/um/Makefile
index 48d92bb..5ab2b17 100644
--- a/arch/um/Makefile
+++ b/arch/um/Makefile
@@ -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

[-- Attachment #3: Type: text/plain, Size: 455 bytes --]

------------------------------------------------------------------------------
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

[-- Attachment #4: Type: text/plain, Size: 194 bytes --]

_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

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

[Boaz Harrosh]

On 11/28/2013 06:09 PM, Richard Weinberger wrote:
> 
> 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)

> 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
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel