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 <richard.weinberger@gmail.com> wrote:
On Sun, Feb 12, 2012 at 9:23 PM, Joakim Arfvidsson
<joakim@arfvidsson.com> 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