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 mixing
This bug exists on Windows host only.
TeLeMan wrote:
>
> qemu_memalign was introduced after this patch:
> http://www.nabble.com/forum/ViewPost.jtp?post=14488239&framed=y
>
> But the "free" function was qemu_free yet, the correct function should be
> qemu_vfree.
>
> This bug will lead to heap
Robert Reif wrote:
> Thiemo Seufer wrote:
>
>> CVSROOT: /sources/qemu
>> Module name: qemu
>> Changes by: Thiemo Seufer 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 H
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
