[Bug 937] Qemu doesn't want to flash images

bugzilla-daemon at bugzilla.openmoko.org bugzilla-daemon at bugzilla.openmoko.org
Fri Nov 16 22:39:22 CET 2007


balrogg at gmail.com changed:

           What    |Removed                     |Added
             Status|NEW                         |ASSIGNED
            Summary|Qemu doens't want to flash  |Qemu doesn't want to flash
                   |images                      |images

------- Additional Comments From balrogg at gmail.com  2007-11-16 22:39 -------
Okay, I was able to reproduce the bug today and I committed a workaround for
this into SVN.  The issue is a bit mysterious and reveals a flaw in upstream
qemu and possibly a kernel bug.

The hang is caused by qemu giving full control to the target system (in this
case u-boot).  Normally the qemu main loop translates target code blocks and
then executes them, and only after a block finishes executing qemu gets back to
its duties as a host process, such as displaying graphics, dealing with serial
input (e.g. u-boot commands), reacting to keyboard/mouse events etc.  A
translation blocks ends when an interrupt occurs, a timer expires (by delivery
of a signal) or the block fills an entire code buffer.  Since u-boot doesn't use
interrupts, and since it polls s3c2410 serial for received bytes in a very tight
loop (that fits very well into the code buffer), the control returns to host
only on timer expiry events.  But.  The Debian/Ubuntu kernel 2.6.22 claims to
support dyntics, so that qemu uses dynticks for delivering timer expiry. 
However the signals stop being delivered to qemu after a random period, I can't
explain why (yet), I suspect a kernel bug, so that the control constantly
remains in hands of target u-boot, and qemu main loop never gets a chance to
spin and fetch more serial input.

I hadn't had this problem when I tried Ubuntu the last time because I had not
rebooted into the new kernel after upgrading to 7.10, and with 2.6.21 kernels
everything seems to be fine.  Later I built Gentoo on the vm (under qemu) and
today rebooted it back into Ubuntu for a while, this time with its new kernel,
and the bug could be observed (though not 100% reproducible, rather randomly).

I made the flash.sh script force unix timers instead of dyntics, it works around
the issue for me.  Please test (svn r3434) and report back.

There are two issues, one is that of depending on timer events for performing
host tasks, and I will address it upstream.
Second issue is that of dynticks failing randomly, I will investigate it if I
have nothing better to do.

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

More information about the buglog mailing list