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