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 <richard.weinberger@gmail.com> wrote:
On Mon, Feb 13, 2012 at 12:29 AM, Joakim Arfvidsson
<joakim@arfvidsson.com> 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