Your message dated Mon, 17 Dec 2007 14:48:20 +0100
with message-id <[email protected]>
has caused the Debian Bug report #419369,
regarding Please initialise memory with garbage
to be marked as having been forwarded to the upstream software
author(s) [email protected]
(NB: If you are a system administrator and have no idea what I am
talking about this indicates a serious mail system misconfiguration
somewhere. Please contact me immediately.)
Debian bug tracking system administrator
(administrator, Debian Bugs database)
--- Begin Message ---
Mon, 17 Dec 2007 14:48:20 +0100
While writing a kernel and testing it with qemu, I found some bugs in
qemu (and many in my kernel ;-) ). Here's a list of them. They are all
about x86 emulation on x86. Some are a bit old, and since my kernel is
now fixed I can't easily test if they still aren't fixed, though.
- When a protection level 0 process returns with iret to a pl3 process,
and the segment registers (other than cs and ss) are set to values
that shouldn't be usable by pl3, real hardware will hang (if there's
no gpf handler) when they are used. However qemu doesn't seem to have
a problem with it at all.
- Qemu initializes all its memory to 0. Real hardware doesn't seem to
do that. This means that usage of uninitialized memory is very hard
to debug (because 0 is often a good value, while [random] is not, so
the problem can only be seen on real hardware, which makes it hard to
- The timing of the ports are impossibly fast. When writing a byte to a
serial port and immediately asking if the send buffer is empty, it
says it is. This means that code which only runs when waiting for
data to be transmitted will never get tested in qemu, because it is
never "waiting". The same is at least true for the keyboard, I
suppose for other devices as well.
- The system timer (irq 0) runs on real-time, not on emulated time.
This means that the behaviour of programs may differ between machines,
and that sending a test case to someone else may not work.r
For example, if I write (too) much output to the serial port in the
irq0 handler, the cpu never exits the handler (that is, it reenters
when it's about to exit). However, when redirecting the serial port
output from screen into a file (it's going to stdout), the machine
suddenly does execute programs other than the irq handler.
That's all (so far). I can imagine that it is not always desirable to
emulate these things "right", for example with the timing: it's more
important that the emulated machine behaves properly, for example when
it plays music, than that it is reproducible. However, I think
reproducibility would be a nice feature as well. Perhaps it would be
better to add it via a commandline option.
Ps: Please CC me, I'm not subscribed to the list.
I encourage people to send encrypted e-mail (see http://www.gnupg.org).
If you have problems reading my e-mail, use a better reader.
Please send the central message of e-mails as plain text
in the message body, not as HTML and definitely not as MS Word.
Please do not use the MS Word format for attachments either.
For more information, see http://pcbcn10.phys.rug.nl/e-mail.html
--- End Message ---