On Tue, Feb 14, 2012 at 4:08 AM, Joakim Arfvidsson
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.
>
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:/
On Mon, Feb 13, 2012 at 12:29 AM, Joakim Arfvidsson
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 lon
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
On Sun, Feb 12, 2012 at 9:23 PM, Joakim Arfvidsson
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
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 t
