Le mercredi 23 janvier 2008 à 21:52 +0100, Fabrice Bellard a écrit :
Two questions:
- Why do you use AIO ? If the Linux sg device supports selects, then
using the QEMU select() callback suffices.
Basically because when I want to have asynchronous I/O I use AIO...
If you explain me briefly
qemu's audio subdirectory contains a copy of BSD's sys-queue.h, which
defines a bunch of LIST_ macros. This makes it difficult to build a
program made partly out of qemu and partly out of the Linux kernel[1],
since Linux has a different set of LIST_ macros. It might also cause
trouble when
This bug exists on Windows host only.
TeLeMan wrote:
qemu_memalign was introduced after this patch:
http://www.nabble.com/forum/ViewPost.jtp?post=14488239framed=y
But the free function was qemu_free yet, the correct function should be
qemu_vfree.
This bug will lead to heap corrupted.
Robert Reif wrote:
Thiemo Seufer wrote:
CVSROOT: /sources/qemu
Module name: qemu
Changes by: Thiemo Seufer ths 08/01/23 19:01:12
Modified files:
. : cpu-all.h cpu-exec.c qemu-doc.texi vl.c
Log message:
Add option to disable TB cache, by Herve Poussineau.
Exactly which version of gcc is this? It appears to work fine with at
least some gcc 3 versions.
gcc (GCC) 3.2.2 20030222 (Red Hat Linux 3.2.2-5)
Standard Red Hat 9.
Hi!
I can't understand why clock in guest OS (Windows 2003) goes very slow.
Host OS: Debian GNU/Linux Etch x86_64 (kernel 2.6.18.5-amd64)
Host CPU: something like Intel Core Duo
$ cat /proc/cpuinfo
processor : 0 # and 1 too
vendor_id : GenuineIntel
cpu family : 15
model
Hi...
On Jan 25, 2008 5:08 AM, Sergey Bychkov [EMAIL PROTECTED] wrote:
Hi!
I can't understand why clock in guest OS (Windows 2003) goes very slow.
Are you sure the rtc freq has been made to 1024?
# cat /proc/sys/dev/rtc/max-user-freq
should yield 1024 before you ran qemu.
If yes, then we
