I am trying to adopt the User-Mode Linux kernel  to boot a live ISO
of Android-x86 . In particular, this is a eeepc-flavored live ISO
of Gingerbread 2.3.5 . The ISO boots and works fine in KVM (which I
use as a reference). For UML, I only changed the init script in initrd
slightly, but the rest of filesystems located on the ISO are used
without any change.
With User-mode kernel I got to the point when I can load Android
userland, get through the animated splash screen, and see the home
screen. Everything seems to work, but there are considerable delays in
response to user actions. Such delays may be tens of seconds (from the
moment of click or keypress to the moment when anything changes on the
screen). Once I was patient enough to bring up the ethernet
configuration screen, fill out IP address, netmask, and DNS fields,
and was able to browse Internet
In the same time if I switch to another console (Alt-arrows work as in
regular Linux desktop), I do not
see any delays in response to key presses, nor does top show any extra
load on CPU.
In logcat, I see tens of messages like this:
W/SharedBufferStack( 889): waitForCondition(LockCondition) timed out
(identity=13, status=0). CPU may be pegged. trying again.
In KVM, I do not see anything like this: Android boots in seconds, and
responds to keys/clicks almost instantaneously.
In both cases, virtual framebuffer driver does not support page
flipping (that is, yres = yres_virtual). In KVM, color resolution is
16bpp. In UML It was initially 32bpp, but I tried to decrease it to
16bpp, no effect.
What in the kernel may function improperly to cause such messages and
I am not posting the logcat output here as it is very long. But if
there is anything to pay attention to, I'll post relevant portions if
that may help.
Thanks for any ideas.
PS One visual difference in the boot process between KVM and UML: in
KVM splash screen is animated smoothly, in UML, the light reflex moves
in "leaps" however it moves with the same speed.
PPS I traced the shared buffer locking code down to the piece in
bionic where futexes are used to provide the locking facility. As an
experiment, I compiled a kernel without futexes (CONFIG_FUTEX is not
set), which caused the userland to not load at all. So futexes are
certainly in effect, but perhaps something else prevents the platform
code from proper unlocking the shared buffers.
 http://android-x86.googlecode.com/files ... -eeepc.iso