Menu
▾
▴
user-mode-linux-user
|
From: Joakim A. <jo...@ar...> - 2012-02-12 20:23:55
|
It finds the bottom address, but is stuck forever on top address. This is all on an Amazon EC2 instance (so it's running within some Xen vm). Host is running 32 bit RedHat. Command line and results: > ./kernel32-3.2.5 -v ubda=/tmp/cow4:Debian-Squeeze-x86-root_fs mem=256m Locating the bottom of the address space ... 0x0 Locating the top of the address space ... Freaky thing is that this was working fine on the same machine yesterday, but started failing today. Now fails consistently, never getting farther than here. I can't think of anything I changed about the setup. Any help appreciated! |
|
From: richard -r. w. <ric...@gm...> - 2012-02-12 23:08:17
|
On Sun, Feb 12, 2012 at 9:23 PM, Joakim Arfvidsson <jo...@ar...> wrote: > It finds the bottom address, but is stuck forever on top address. > > This is all on an Amazon EC2 instance (so it's running within some Xen vm). > Host is running 32 bit RedHat. > > Command line and results: > >> ./kernel32-3.2.5 -v ubda=/tmp/cow4:Debian-Squeeze-x86-root_fs mem=256m > Locating the bottom of the address space ... 0x0 > Locating the top of the address space ... > > Freaky thing is that this was working fine on the same machine yesterday, > but started failing today. Now fails consistently, never getting farther > than here. I can't think of anything I changed about the setup. > > Any help appreciated! > Is the UML process consuming CPU time at this point? The calculation happens here: arch/x86/um/os-Linux/task_size.c Which host kernel are you using? -- Thanks, //richard |
|
From: Joakim A. <jo...@ar...> - 2012-02-12 23:29:30
|
Yes, the CPU is pegged while this is happening. I've left it for an hour with no results. I looked at that code and couldn't really see a good reason for it to block forever, except if the address space was so large it took a long time to get through. The host kernel is 2.6.32-220.4.1.el6.i686 #1 SMP This is an Amazon EC2 instance, and I just found one hilarious workaround for this. If I remove the "user-data" from the instance, UML starts working again. User-data is a string that EC2 makes available to the running instance as the response of an http request to a fake ip. On Sun, Feb 12, 2012 at 3:08 PM, richard -rw- weinberger < ric...@gm...> wrote: > On Sun, Feb 12, 2012 at 9:23 PM, Joakim Arfvidsson > <jo...@ar...> wrote: > > It finds the bottom address, but is stuck forever on top address. > > > > This is all on an Amazon EC2 instance (so it's running within some Xen > vm). > > Host is running 32 bit RedHat. > > > > Command line and results: > > > >> ./kernel32-3.2.5 -v ubda=/tmp/cow4:Debian-Squeeze-x86-root_fs mem=256m > > Locating the bottom of the address space ... 0x0 > > Locating the top of the address space ... > > > > Freaky thing is that this was working fine on the same machine yesterday, > > but started failing today. Now fails consistently, never getting farther > > than here. I can't think of anything I changed about the setup. > > > > Any help appreciated! > > > > Is the UML process consuming CPU time at this point? > The calculation happens here: > arch/x86/um/os-Linux/task_size.c > > Which host kernel are you using? > > -- > Thanks, > //richard > |
|
From: richard -r. w. <ric...@gm...> - 2012-02-12 23:41:29
|
On Mon, Feb 13, 2012 at 12:29 AM, Joakim Arfvidsson <jo...@ar...> wrote: > Yes, the CPU is pegged while this is happening. I've left it for an hour > with no results. > > I looked at that code and couldn't really see a good reason for it to block > forever, except if the address space was so large it took a long time to get > through. Can you please very this? Just add a printf()... > The host kernel is 2.6.32-220.4.1.el6.i686 #1 SMP > > This is an Amazon EC2 instance, and I just found one hilarious workaround > for this. If I remove the "user-data" from the instance, UML starts working > again. User-data is a string that EC2 makes available to the running > instance as the response of an http request to a fake ip. > ??? -- Thanks, //richard |
|
From: Joakim A. <jo...@ar...> - 2012-02-14 03:08:13
|
To debug, I ran UML in gdb. It segfaulted once during finding the bottom limit, which is expected I guess. I then interrupted it a couple of times while hanging on finding the top. All interrupts hit the same line of code in task_size.c, so I think it's stuck on the single line. line 32 in http://lxr.free-electrons.com/source/arch/x86/um/os-Linux/task_size.c n = *address; Does this tell you anything? Locating the bottom of the address space ... Program received signal SIGSEGV, Segmentation fault. 0x08078b9b in page_ok (page=<value optimized out>) at arch/x86/um/os-Linux/task_size.c:32 32 arch/x86/um/os-Linux/task_size.c: No such file or directory. in arch/x86/um/os-Linux/task_size.c (gdb) c Continuing. 0x0 Locating the top of the address space ... ^C Program received signal SIGINT, Interrupt. 0x08078b9b in page_ok (page=<value optimized out>) at arch/x86/um/os-Linux/task_size.c:32 32 in arch/x86/um/os-Linux/task_size.c On Sun, Feb 12, 2012 at 3:41 PM, richard -rw- weinberger < ric...@gm...> wrote: > On Mon, Feb 13, 2012 at 12:29 AM, Joakim Arfvidsson > <jo...@ar...> wrote: > > Yes, the CPU is pegged while this is happening. I've left it for an hour > > with no results. > > > > I looked at that code and couldn't really see a good reason for it to > block > > forever, except if the address space was so large it took a long time to > get > > through. > > Can you please very this? > Just add a printf()... > > > The host kernel is 2.6.32-220.4.1.el6.i686 #1 SMP > > > > This is an Amazon EC2 instance, and I just found one hilarious workaround > > for this. If I remove the "user-data" from the instance, UML starts > working > > again. User-data is a string that EC2 makes available to the running > > instance as the response of an http request to a fake ip. > > > > ??? > > -- > Thanks, > //richard > |
|
From: richard -r. w. <ric...@gm...> - 2012-02-14 09:10:24
|
On Tue, Feb 14, 2012 at 4:08 AM, Joakim Arfvidsson <jo...@ar...> wrote: > To debug, I ran UML in gdb. It segfaulted once during finding the bottom > limit, which is expected I guess. gdb has to ignore UML's SIGSEGV. UML is using it to handle page faults. Type "handle SIGSEGV noprint nostop pass" into gdb. > I then interrupted it a couple of times while hanging on finding the top. > All interrupts hit the same line of code in task_size.c, so I think it's > stuck on the single line. > > line 32 > in http://lxr.free-electrons.com/source/arch/x86/um/os-Linux/task_size.c > n = *address; > > Does this tell you anything? > Not really. :( -- Thanks, //richard |
Thanks for helping keep SourceForge clean.
X