Re: [Qemu-devel] [patch] Fix a typo in 'P' packet processing for M68K.
Hi Aurelien, I don't have a write access to the repository. Could someone apply this patch if it's OK? This patch looks ok, but is missing a Signed-of-by: Thank you for a review. I'm going to resubmit the patch in the git style. Kazu Hirata
[Qemu-devel] [PATCH] Fix a typo in 'P' packet processing for M68K.
Hi,
Attached is a patch to fix a typo in 'P' packet processing for M68K.
Without this patch, QEMU fails to honor GDB's P packets from GDB
(writing to registers) for the address registers (A0 - A7).
The problem is because of an obvious typo. Notice that the second
if condition is meant to be n 16 in:
if (n 8) {
:
} else if (n 8) {
Signed-off-by: Kazu Hirata k...@codesourcery.com
---
gdbstub.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/gdbstub.c b/gdbstub.c
index 6180171..80477be 100644
--- a/gdbstub.c
+++ b/gdbstub.c
@@ -1014,7 +1014,7 @@ static int cpu_gdb_write_register(CPUState *env, uint8_t
*mem_buf, int n)
if (n 8) {
/* D0-D7 */
env-dregs[n] = tmp;
-} else if (n 8) {
+} else if (n 16) {
/* A0-A7 */
env-aregs[n - 8] = tmp;
} else {
--
1.6.2.4
[Qemu-devel] [patch] Fix a typo in 'P' packet processing for M68K.
Hi,
Attached is a patch to fix a typo in 'P' packet processing for M68K.
Without this patch, QEMU fails to honor GDB's P packets from GDB
(writing to registers) for the address registers (A0 - A7).
The problem is because of an obvious typo. Notice that the second
if condition is meant to be n 16 in:
if (n 8) {
:
} else if (n 8) {
I don't have a write access to the repository. Could someone apply
this patch if it's OK?
Thanks in advance,
Kazu Hirata
diff --git a/gdbstub.c b/gdbstub.c
index 055093f..1a1640a 100644
--- a/gdbstub.c
+++ b/gdbstub.c
@@ -1014,7 +1014,7 @@ static int cpu_gdb_write_register(CPUState *env, uint8_t
*mem_buf, int n)
if (n 8) {
/* D0-D7 */
env-dregs[n] = tmp;
-} else if (n 8) {
+} else if (n 16) {
/* A0-A7 */
env-aregs[n - 8] = tmp;
} else {
Re: [Qemu-devel] Binaries for Windows
Ottavio Caruso wrote: Kazu, thank you for your work. Without your binaries I'd have never discovered qemu and Linux and I'd be stuck with Window$. I am sorry about your conditions, I'd like to have you back soon and I'd like you to know that there are many people here that appreciate your work. Thank you. I hope so. Regards, Kazu ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] Binaries for Windows
Hi, I will stop updating QEMU on Windows web site at least for several months. Because my eye condition becomes not good, I can't see display well. New binaries for Windows will be avialable here by TAKEDA Toshiya. He is developing old Japanese computer emulators. http://www1.interq.or.jp/t-takeda/top.html http://www1.interq.or.jp/~t-takeda/qemu/ Thank you for your help. Regards, Kazu ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] kqemu-1.3.0pre11 installer for Windows
Hi, I made a Kqemu-1.3.0pre11 installer. http://www.h6.dion.ne.jp/~kazuw/qemu-win/Kqemu-1.3.0pre11-install.exe Please uninstall your old version before installing it. It is KQEMU virtualization module for QEMU in the control panel-add/remove software. The new Kqemu is installed as QEMU Accereration Module. Also 0.9.0 binary. http://www.h6.dion.ne.jp/~kazuw/qemu-win/Qemu-0.9.0-install.exe BIOS is in a pc-bios directory. Use -L like this. -L C:\Program Files\Qemu\pc-bios If you install Kqemu-1.3.0pre11-install.exe, non installable package qemu-0.9.0-windows.zip is also accelerated. I have not tested on Windows Vista host. Regards, Kazu ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel][PATCH] Built-in DHCP server
Hi, After I used TAP device by -net nic -net tap,ifname=mytap and I tried to use user mode network by -net nic -net user, a Windows XP guest doesn't get IP address from a built-in DHCP server. It is fixed by an attached patch. DHCPRELEASE and DHCPNACK are introduced. DHCPRELEASE code is borrowed from VirtualBox. Windows 2000/XP tries to call DHCPREQUEST and get old IP address when it boots. I made a code to reply DHCPNACK to the request. Then the Win2k/XP called DHCPDISCOVER and try to get a new IP address. I tested Windows 98SE/2000/XP, Knoppix 3.8, Morphix, Fedora Core 3 and RedHat 7.2 guest. There is not problem except RH7.2. It can get IP address but it is 10.0.2.16. dhcpcd in RH7.2 tries to call DHCPDISCOVER two times. So it consumes two entries in the built-in DHCP server. It seems that it is a bug of dhcpcd in RH7.2. Regards, Kazu qemu-20070220-dhcp.patch Description: Binary data ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel][PATCH] CD-ROM read-only fix for win32
Hi, When a file has a read-only attribute for its property, the program doesn't boot. An attached patch fixes it. For example, read-only CD-ROM file can be used. It also fixes the problem that restricted user can't access host's CD-ROM drive. Thanks, Kazu qemu-20070114-cdrom.patch Description: Binary data ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Re: Problem with windows qemu port
Sent: Saturday, November 25, 2006 9:19 AM Johannes Schindelin wrote: Hi, On Fri, 24 Nov 2006, Eric Bellard wrote: Kazu kazoo at r3.dion.ne.jp writes: -monitor option is not supported. Do you have any plan to support it? Is it not supported because it has not be tested? do you have a known problem with this option? IIRC it is that stupid limitation of Windows, where you cannot have a non-console program with stdin/stdout. That is right. I don't have a plan to support it soon. There was a patch to support console but it is too old. Regards, Kazu ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Compilation error from CVS while turning offoptimization
Sent: Tuesday, November 07, 2006 7:27 PM Lauro Moura wrote: On 11/5/06, Neo Jia [EMAIL PROTECTED] wrote: hi, I am still trying to debug qemu with gdb so I would like to turn off the optimization. But the build failed. I put the build output in this attachment, please check. I really appreciate if you can share the way you used to debug qemu. I didn't find any build error on that log, but the -O2 flag is still there. I believe it'd be useful if you post your build configuration or the changes you made. I'm trying to make it work with gdb too. Tried the guide on qemu-win site [1] but without success. GDB keeps showing no symbols found. [1] http://www.h7.dion.ne.jp/~qemu-win/DebuggingTips-en.html I don't know why no symbols found. This patch turns off optimization for current CVS and to disable SIGUSR2 and AIO use SIGALRM. Because gdb can't ignore SIGUSR2 signal. It also disable timer interrupt because it is not good for debugging. After AIO is introduced, SIGALRM and SIGUSR2 are used on Linux host. They have effect on gdb. http://www.h7.dion.ne.jp/~qemu-win/download/qemu-20061108-debug-on-linux.patch On Windows host, these signal handling are not used so that debugging is easier. http://www.h7.dion.ne.jp/~qemu-win/download/qemu-20061108-debug-on-windows.patch This is my debugging method on Linux host. (1)Apply patch to current CVS and make. $ cvs -z3 -d:pserver:[EMAIL PROTECTED]:/sources/qemu co qemu $ cd qemu qemu$ patch -p0 ../qemu-20061108-debug-on-linux.patch qemu$ ./configure --target-list=i386-softmmu --cc=gcc32 qemu$ make (2) Change directory to i386-softmmu and edit .gdbinit file. qemu$ cd i386-softmmu i386-softmmu$ vi .gdbinit This is .gdbinit file. -- file qemu set args -L ../pc-bios -hda ../../linux.img b main define hook-stop handle SIGALRM nopass end define hook-run handle SIGALRM pass end defilen hook-continue handle SIGALRM pass end run - AIO used SIGALRM in the patch and set gdb ingore it. (3) Start gdb. i386-softmmu$ gdb Then the program stops at main routine. Regards, Kazu ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] -k option on Windows host
Hi, FYI, -k option can be used only for -vnc option on Windows host. It is correct that keyboard layout is US keyboard when you start a guest OS. After booting the guest OS, key layout is converted to your language environment by the guest OS. You can use your language layout in the guest OS. Attatched is a patch for disable -k option if -vnc option is not used. Regards, Kazu qemu-20061030-k-option.patch Description: Binary data ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] AltGr key for Windows host
Hello, Andreas. Thank you. It seems that ctrl left event before right alt makes something wrong for SDL_VIDEODRIVER=windib. I updated binary. SDL is patched and updated. SDL version is 1.2.11 so that windib is default. How about this one. It seems that Knoppix 4.0 works good for me, though I don't know much German... http://www.h6.dion.ne.jp/~kazuw/qemu-win/qemu-20061023-keyboard.zip When SDL_VIDEODRIVER=windib, ctrl alt events before right alt is removed. OS ver = 5.1 0.0.2600 Keyboard = 7, 0 Layout = 0x04070407 LayoutName = 0407 key = 0x133 key name = right alt PRESSED sdl_process_key: keycode = 0xb8 OS ver = 5.1 0.0.2600 Keyboard = 7, 0 Layout = 0x04070407 LayoutName = 0407 key = 0x133 key name = right alt RELEASED sdl_process_key: keycode = 0xb8 It is necessary to make a conversion table for SDL_VIDEODRIVER=directx. DirectInput reports DirectInput's keycode. But QEMU needs AT keyboard's mechanical scancode. I know a key layout of German keyboard. But I don't know which value is reported by DirectInput when the key is pressed. If windib works correct, comparing output results of windib and directx makes the conversion table. I think it is a lot of work, though. Regards, Kazu Sent: Sunday, October 22, 2006 8:24 PM Andreas Bollhalder wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello Kazu I did the test as you asked. My Machine is a Notebook with a Pentium III 1200MHz ULV running WinXP SP2 english. See below for the results. Greetings Andreas SET SDL_VIDEODRIVER=windib - -- C:\Documents and Settings\bolle\Desktop\qemu-20061020-keyboardREM Start qemu on windows. Could not open '\\.\kqemu' - QEMU acceleration layer not activated - OS ver = 5.1 0.0.2600 Keyboard = 4, 0 Layout = 0x08070807 LayoutName = 0807 key = 0x132 key name = left ctrl PRESSED sdl_process_key: keycode = 0x1d - OS ver = 5.1 0.0.2600 Keyboard = 4, 0 Layout = 0x08070807 LayoutName = 0807 key = 0x133 key name = right alt PRESSED sdl_process_key: keycode = 0xb8 - OS ver = 5.1 0.0.2600 Keyboard = 4, 0 Layout = 0x08070807 LayoutName = 0807 key = 0x132 key name = left ctrl RELEASED sdl_process_key: keycode = 0x1d - OS ver = 5.1 0.0.2600 Keyboard = 4, 0 Layout = 0x08070807 LayoutName = 0807 key = 0x133 key name = right alt RELEASED sdl_process_key: keycode = 0xb8 SET SDL_VIDEODRIVER=directx - --- C:\Documents and Settings\bolle\Desktop\qemu-20061020-keyboardREM Start qemu on windows. Could not open '\\.\kqemu' - QEMU acceleration layer not activated - OS ver = 5.1 0.0.2600 Keyboard = 4, 0 Layout = 0x08070807 LayoutName = 0807 key = 0x133 key name = right alt PRESSED sdl_process_key: keycode = 0xb8 - OS ver = 5.1 0.0.2600 Keyboard = 4, 0 Layout = 0x08070807 LayoutName = 0807 key = 0x133 key name = right alt RELEASED sdl_process_key: keycode = 0xb8 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFO1TqkyKr2gmercERAlRyAJ9nVEMyZP2zy5A78paf1G/zvQeUBwCghc+s 9Ew6EGkzZkAGlSSG3Soe1GA= =kneY -END PGP SIGNATURE- ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] AltGr key for Windows host
Hi, Jan and Jeremie. Thank you for your reply. I think your result is for SDL_VIDEODRIVER=windib. I updated the binary. How about this one? Does AltGr key work for you? http://www.h6.dion.ne.jp/~kazuw/qemu-win/qemu-20061023-keyboard.zip Regards, Kazu Sent: Monday, October 23, 2006 7:35 PM Jan wrote: Kazu schrieb: Hi, I made German language environment on Windows XP Japanese host. I investigated a problem of AltGr key. If you have a German keyboard, please use this binary and tell me the data which is displayed on console window when AltGr key is pressed. I want to know the results for both SDL_VIDEODRIVER=windib and SDL_VIDEODRIVER=directx. I forward this from Jeremie, as he is not subscribed: Cc: [EMAIL PROTECTED] Reply to: [Qemu-devel] AltGr key for Windows host Hi Kazu, here is the output of the debug binary you provided. I'm running a simple french keyboard and cannot use characters access by AltGr.r* This happens when I press and then release AltGr: OS ver = 5.1 0.0.2600 Keyboard = 4, 0 Layout = 0x040c040c LayoutName = 040C key = 0x132 key name = left ctrl PRESSED sdl_process_key: keycode = 0x1d OS ver = 5.1 0.0.2600 Keyboard = 4, 0 Layout = 0x040c040c LayoutName = 040C key = 0x133 key name = right alt PRESSED sdl_process_key: keycode = 0xb8 OS ver = 5.1 0.0.2600 Keyboard = 4, 0 Layout = 0x040c040c LayoutName = 040C key = 0x132 key name = left ctrl RELEASED sdl_process_key: keycode = 0x1d OS ver = 5.1 0.0.2600 Keyboard = 4, 0 Layout = 0x040c040c LayoutName = 040C key = 0x133 key name = right alt RELEASED sdl_process_key: keycode = 0xb8 Thank you. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] AltGr key for Windows host
Hi, I made German language environment on Windows XP Japanese host. I investigated a problem of AltGr key. If you have a German keyboard, please use this binary and tell me the data which is displayed on console window when AltGr key is pressed. I want to know the results for both SDL_VIDEODRIVER=windib and SDL_VIDEODRIVER=directx. http://www.h6.dion.ne.jp/~kazuw/qemu-win/qemu-20061020-keyboard.zip These are reference outputs. When SDL_VIDEODRIVER=windib, an event that left ctrl key is pressed is added to the event right alt is pressed. OS ver = 5.1 0.0.2600 Keyboard = 7, 0 Layout = 0x04070407 LayoutName = 0407 key = 0x132 key name = left ctrl PRESSED sdl_process_key: keycode = 0x1d OS ver = 5.1 0.0.2600 Keyboard = 7, 0 Layout = 0x04070407 LayoutName = 0407 key = 0x133 key name = right alt PRESSED sdl_process_key: keycode = 0xb8 OS ver = 5.1 0.0.2600 Keyboard = 7, 0 Layout = 0x04070407 LayoutName = 0407 key = 0x132 key name = left ctrl RELEASED sdl_process_key: keycode = 0x1d OS ver = 5.1 0.0.2600 Keyboard = 7, 0 Layout = 0x04070407 LayoutName = 0407 key = 0x133 key name = right alt RELEASED sdl_process_key: keycode = 0xb8 When SDL_VIDEODRIVER=directx, only right alt key event is made. OS ver = 5.1 0.0.2600 Keyboard = 7, 0 Layout = 0x04070407 LayoutName = 0407 key = 0x133 key name = right alt PRESSED sdl_process_key: keycode = 0xb8 OS ver = 5.1 0.0.2600 Keyboard = 7, 0 Layout = 0x04070407 LayoutName = 0407 key = 0x133 key name = right alt RELEASED sdl_process_key: keycode = 0xb8 There is a duscussion about alt-ctrl. http://blogs.msdn.com/oldnewthing/archive/2004/03/29/101121.aspx Regards, Kazu ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Win32 build
Alexey Eremenko wrote: Hi Kazu ! I have heard, that you are Win32 Qemu maintainer; I am Windows, Linux and Qemu user myself so I would like to work out some issues with you. I am not a meaitainer. I only provide binary packages. 1) I would like to build user-friendly setup for Qemu. 2) I would like to have the setup with extras: Qemu-accelerator(s), GUI(s), TAP-Win32 driver, small Linux image etc... If you disagree with #2, then: 3) I can build 2 setups for Qemu - one for minimal Qemu (the official package) and second is Qemu+extras.(for user's convenience) What do you think? If you want to provide your binary, do it and announce it in this mailing list. Regards, Kazu ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Physical hard disk drive for win32
Alexey Eremenko wrote: Is it hard to access raw hardware under Windows ? like Hard Disk...? Under Linux it is easy. CVS build cannot access host's physical hard disk drive by -hdb //./PhysicalDrive0 after AIO was introduced. So I made a patch to fix it. Regards, Kazu ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] Win32 build
Hi, Win32 build has been still broken. Regards, Kazu ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] VLAN for win32
Hi, A patch below improves a performance of VLAN for win32. It is from three to five times faster than now. I used events to handle network instead of select and used WaitForMultipleObjects to detect events. Binary. http://www.h6.dion.ne.jp/~kazuw/qemu-win/qemu-20060922-vlan-tap.zip Patch. http://www.h7.dion.ne.jp/~qemu-win/download/qemu-20060922-vlan.patch Regards, Kazu ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] QCOW/QCOW2 for win32
Sent: Monday, September 11, 2006 9:28 AM Jamie Lokier wrote: Kazu wrote: Patch. http://www.h7.dion.ne.jp/~qemu-win/download/qemu-20060906-qcow.patch #ifdef QEMU_TOOL -overlapped = 0; +overlapped = FILE_ATTRIBUTE_NORMAL; #else overlapped = FILE_FLAG_OVERLAPPED; #endif I suspect the second value should be (FILE_ATTRIBUTE_NORMAL | FILE_FLAG_OVERLAPPED). But I'm no Win32 expert. I think FILE_ATTRIBUTE_NORMAL is only used without other options. Regards, Kazu ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] QCOW/QCOW2 for win32
Hi, A patch below fixes QCOW/QCOW2 for win32. -snapshot option works. When -snapshot is used, a temporary file is created at C:\Documents and Settings\(user name)\Local Settings\temp. In path_is_absolute in block.c, path separation '/' also works for win32. A named snapshot works. I can make a named temporary file by qemu-img.exe and boots from it. When I used qcow2, VM snapshots work. localtime in block.c is thread-safe for win32. For more information, see. http://www.h7.dion.ne.jp/~qemu-win/HowToFloppyCdrom-en.html#snapshot Patch. http://www.h7.dion.ne.jp/~qemu-win/download/qemu-20060906-qcow.patch Binary. http://www.h6.dion.ne.jp/~kazuw/qemu-win/qemu-20060906-qcow.zip Regards, Kazu ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] block-vvfat RW patch
Hi, I confirmed it works. Thank you. Regards, Kazu Sent: Tuesday, September 05, 2006 8:57 AM Roger Lathrop wrote: Attached patch fixes 3 issues I found while trying to write files from guest to a vfat drive using this configuration: Host: Windows XP (NTFS) Guest: DOS 5 (yeah, really!) Compiler: gcc version 3.4.2 (mingw-special) Qemu Version: 0.8.2 Command line: qemu -hdb fat:rw:c:\dev\qemu\work... Problem: Qemu would fault when copying files from guest to d:\ Changes: 1) Fixed assert macro for mingw. Original causes spurious faults when there's a dangling else after the assert. 2) Added O_BINARY to open call in commit_one_file(). Without it, binary files get LF--CR/LF translations on Windows. 3) Changed sector2cluster to return a signed int, and added type casts to force the division to be signed. First 2 changes are straight forward and should be safe. 3'rd solved my problem, but should be looked at by someone who understands vvfat better than me. I've only tested on the above configuration. The problem I saw was DOS writing to sectors less than s-faked_sectors. The unsigned divide returned a large positive number, which would fault in this bit of code in vvfat_write: if (i = 0) s-used_clusters[i] |= USED_ALLOCATED; This fix seems reasonable, since the callers of sector2cluster seem to expect a signed result. I suppose an alternate fix would be to test for the special case and always return -1. But I hate special cases ;-) Patch is against 0.8.2, not current CVS, sorry. Doesn't appear to have been fixed since 0.8.2 Good to have this working. Our app is an embedded system with really crude (read, no TCP/IP) network support. Until now, getting log files off the guest has been a pain. So, a big THANKS to whoever wrote block-vvfat, despite the little buglets. Roger ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] Compile fix for win32
Hi,
A patch below fixes compile for win32.
Regards,
Kazu
Index: block-raw.c
===
RCS file: /sources/qemu/qemu/block-raw.c,v
retrieving revision 1.10
diff -u -r1.10 block-raw.c
--- block-raw.c 3 Sep 2006 12:08:37 - 1.10
+++ block-raw.c 5 Sep 2006 05:06:14 -
@@ -1134,6 +1134,10 @@
{
}
+void qemu_aio_flush(void)
+{
+}
+
void qemu_aio_wait_start(void)
{
}
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] mingw compile error patch
alex wrote: Hi, The patch below allows me to compile qemu on Windows, however it is still not working. The program exits immediately reporting that it can't open the hard disk image. GDB reports the offensive pies of code is in malloc(), which does not make sense to me. Am I doing something wrong? An attached patch fixes compile error for win32. It also fixes using /dev/cdrom and a file name with a drive letter. Qcow is not fixed. Regards, Kazu qemu-20060821-compile.patch Description: Binary data ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Re: Compile error on Windows
Alex wrote: MSYS/MinGW on Athlon 1.25 GHz with 500MB of RAM, Windows XP Pro $ uname -a MINGW32_NT-5.1 VIC 1.0.10(0.46/3/2) 2004-03-15 07:17 i686 unknown $ gcc --version gcc.exe (GCC) 3.2.3 (mingw special 20030504-1) ./configure --target-list=i386-softmmu --static make I compiled several previous versions of QEMU with no problem (last time from from a July 27 snapshot) Use this patch. http://lists.gnu.org/archive/html/qemu-devel/2006-08/msg00107.html Regards, Kazu ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] Compile fix for win32
Hi, An attatched patch fixes compile error for win32. Regards, Kazu qemu-20060807-compile.patch Description: Binary data ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] Raw CD-ROM and hard disk for win32
Hi, An attached patch fixes raw CD-ROM and hard disk handling for win32. Qcow is not fixed. Regards, Kazu qemu-20060807-cdrom.patch Description: Binary data ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Latest CVS doesn't start
Sent: Friday, August 04, 2006 6:00 PM denis.sheidt wrote: Hello everybody, I'm having some troubles with latest CVS version on a Windows XP host. QEmu compiles OK, but it doesn't start. Here is my command line : qemu.exe -L bios -boot d -cdrom cd_w2k_SP4_FR.iso -hda TEST.IMG -localtime - cd_w2k_SP4_FR.iso is a W2KPRO image, with SP4 that works fine with previous version of qemu (31-jul) - TEST.IMG is a new qcow image made with latest qemu-img version. when I launch this command line, with or without kqemu, qemu just displays a window saying : QEMU 0.8.2 monitor - type 'help' for more information (qemu) The window's title bar says : QEMU [Stopped] I also notice that -cdrom //./d: or -cdrom \\.\d: do no longer work. I get the message : qemu: could not open hard disk image '//./d:' Did I miss something ? Is this related to aio implementation ? It seems that it is related aio implementation. Raw image works but Qcow image doesn't work. CD-ROM also doesn't work now. Regards, Kazu ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Win32 MinGW build with current CVS
Sent: Thursday, August 03, 2006 4:07 AM NyOS wrote: On Wed, 02 Aug 2006 20:07:46 +0200, Andreas Bollhalder [EMAIL PROTECTED] wrote: Hello It seems that the aio support broke my MinGW build batch under Win32. Is it suposed to work on WIN32 ? Any ideas ? Andreas ... Support for kernel AIO has been included in the 2.6 Linux kernel. source: http://lse.sourceforge.net/io/aio.html So, I don't think so. But please correct me, if I'm wrong. Asynchronous I/O is implemented by overlapped I/O for Win32 but it is not enabled. I tried to make the program. A patch attached fixs compile errors. I found some problems about it. GetFileSizeEx needs to define WINVER 0x0500. It means that Windows 98/Me host is not supported. If we try to support Win 98/Me host, it is necessary to change configure to use --enable-win9x and make another binary, etc. The first attempt to open a hard disk image with a drive letter always failed. After the second time is OK. Regards, Kazu qemu-20060803-aio.patch Description: Binary data ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] host_alarm for Win32
Hi, host_alarm_handler for Win32 is called 1000 times/sec but it doesn't always wake upWaitForMultipleObjects. The behavior is not the same as Linux host because signal always wake up select. A patch fixes it. http://www.h7.dion.ne.jp/~qemu-win/download/qemu-20060730-host_alarm.patch Regards, Kazu ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] Using thread for serial for win32
Hi, I made a patch that uses a thread instead of polling for -serial option for Win32 . It improves a performance of a serial communication. A new option is introduced to connect two QEMUs by a named pipe. Usage: -serial pipe_client:com_1 -serial pipe_client: set the program a clinet mode and can connect to a server. com_1 is a name of the named pipe. A pair of -serial pipe: and -serial pipe_clinet: can connect QEMUs each other. http://www.h7.dion.ne.jp/~qemu-win/download/qemu-20060730-serial-thread.patch I found another problem about using windbg. I will send a next post. Regards, Kazu ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] Workaround for windbg
Hi, My previous patch is not enough to use windbg. A rate of loop in main_loop in vl.c drops a lot. The rate does not drop for Fedora Core 4 guest but not good for RedHat 7.2 and Windows 2000. It is expected at least 1000 cycles/sec, but the rate drops to 130 cycles/sec while CPU load is high. It is the case while OS is booting. The rate is slow so that a communication through serial line is slow. I made a workaround for it and checked the data sending/receiving rate by it. The patch exits CPU loop in cpu_exec every 100 times and handle I/O of serial data. The rate of loop in main_loop is about 3 cycles/sec. Win2k booting time with windbg is much improved. The patch is not efficient so it can only be used for windbg. It seems that cpu_interrupt does not work while CPU load is high depending on a guest OS. Binary. http://www.h6.dion.ne.jp/~kazuw/qemu-win/qemu-0.8.2-windbg.zip Patch. http://www.h7.dion.ne.jp/~qemu-win/download/qemu-20060730-windbg.patch Regards, Kazu ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] sparc-softmmu
Hi, After openbios-sparc32 is introduced for sparc-softmmu, I can see a Linux penguin but can't see booting texts. When it is used with -nographic, I can see prompt. It seems that texts are not shown. It is both on Linux and Windows hosts. Regards, Kazu ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Ask for debugging linux kernel with Qemu 0.8.1 onMsys
Sent: Wednesday, June 07, 2006 4:56 PM Tieu Ma Dau wrote: I recently try the patch you recommend but I got the same result. In fact, after make this patch into Qemu source code 0.8.1, I compiled it with these commands: ./configure --prefix=/travail/install/qemu-8.1 make install And I run Qemu to simulate ARM on debugging mode: ./qemu-system-arm -kernel myKernel-with-kgdb -initrd arm_root.img -s And I tried to connect to Qemu by default port 1234: (gdb) target remote localhost:1234 But I got the error: connection refused MinGW's gdb doesn't support network debugging. You need to use Cygwin's gdb for remote debugging with network. So I test the current openned port in localhost by the command: netstat -ao And the result I got is below: [code] Connexions actives Proto Adresse locale Adresse distante Etat TCPvinh-phu:epmap vinh-phu:0 LISTENING 1056 TCPvinh-phu:microsoft-ds vinh-phu:0 LISTENING 4 TCPvinh-phu:1025 vinh-phu:0 LISTENING 1216 TCPvinh-phu:1027 vinh-phu:0 LISTENING 4 TCPvinh-phu:2869 vinh-phu:0 LISTENING 1416 TCPvinh-phu:3016 vinh-phu:0 LISTENING 2036 TCPvinh-phu:3019 vinh-phu:0 LISTENING 2012 TCPvinh-phu:3026 vinh-phu:0 LISTENING 2012 TCPvinh-phu:5000 vinh-phu:0 LISTENING 1416 TCPvinh-phu:5101 vinh-phu:0 LISTENING 2012 TCPvinh-phu:3001 vinh-phu:0 LISTENING 1800 TCPvinh-phu:3002 vinh-phu:0 LISTENING 1216 TCPvinh-phu:3003 vinh-phu:0 LISTENING 1216 TCPvinh-phu:3015 vinh-phu:0 LISTENING 2036 TCPvinh-phu:3015 localhost:3016 ESTABLISHED 2036 TCPvinh-phu:3016 localhost:3015 ESTABLISHED 2036 TCPvinh-phu:3019 cs8.msg.dcn.yahoo.com:5050 ESTABLISHED 2012 TCPvinh-phu:3026 sip7.voice.re2.yahoo.com:5061 ESTABLISHED 2012 TCPvinh-phu:15871 vinh-phu:0 LISTENING 1988 UDPvinh-phu:epmap *:*1056 UDPvinh-phu:microsoft-ds *:*4 UDPvinh-phu:isakmp*:*896 UDPvinh-phu:1026 *:*1216 UDPvinh-phu:3004 *:*1216 UDPvinh-phu:3011 *:*1988 UDPvinh-phu:3012 *:*1384 UDPvinh-phu:3025 *:*1384 UDPvinh-phu:3068 *:*1384 UDPvinh-phu:3069 *:*1384 UDPvinh-phu:3071 *:*1384 UDPvinh-phu:3072 *:*1384 UDPvinh-phu:3073 *:*1384 UDPvinh-phu:3074 *:*1384 UDPvinh-phu:ntp *:*1216 UDPvinh-phu:1900 *:*1416 UDPvinh-phu:3005 *:*1216 UDPvinh-phu:3009 *:*1216 UDPvinh-phu:3022 *:*2012 UDPvinh-phu:3441 *:*2036 UDPvinh-phu:3997 *:*1540 UDPvinh-phu:ntp *:*1216 UDPvinh-phu:1900 *:*1416 UDPvinh-phu:3030 *:*2012 UDPvinh-phu:3031 *:*2012 UDPvinh-phu:8257 *:*1988 UDPvinh-phu:57073 *:*1988 [/code] Do you know any suggestion for this problem? Port 1234 doesn't open. The program doesn't work well. If you use the patch , TCP 1234 port will be used. Did you see this message? Waiting gdb connection on port 1234 Regards, Kazu ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] gdb-stub support for Win32 host
Sent: Sunday, May 28, 2006 12:11 AM Jason Wessel wrote: This patch adds support for the gdb-stub to work on the Win32 host and compile in by default. I retested to make sure everything was compatible so as not to break the unix side. I works fine. Thank you. Regards, Kazu ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] objective benchmark?
Tuesday, May 16, 2006 3:55 PM Christian MICHON wrote: how can we do the same if the host is winXP ? Today, on linux guests, 2.4.x kernel boot faster than 2.6.x kernel inside qemu (unless using clock=pit on 2.6.x). 2 days ago, when I tried to setup Solaris x86 10 guest inside winXP host, I gave up since the timing engine inside the guest seems slow. I would really like to know how to solve this on XP hosts. RTC is not used on Win host. SpeedStep/PowerNow! is disabled by changing miminal power management to other items at Control Panel-Power Option-Power Management Setting. I don't think it is necessary to set it if your PC is ACPI. Set it if the clock of win2k guest is faster than the real time while IE is running. It is normal that 2.4 kernel boots faster than 2.6 kernel, isn't it? I don't know why Solaris x86 10 doesn't work. Regards, Kazu ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] [PATCH] VLAN and Tap for win32
Sent: Monday, May 15, 2006 11:03 PM Kazu wrote: I heard that WSAWaitForMultipleEvents is the same as WaitForMultipleObjects in winsock 2 mailing list. I used it. I think supressing polling means using win32 thread. Is it OK? I will try to use threads. http://www.h7.dion.ne.jp/~qemu-win/download/qemu-20060515-tap.patch WSAWaitForMultipleEvents needs WSAStartup. WaitForMultipleObjects can wait for network events. WaitForMultipleObjects is better. http://www.h7.dion.ne.jp/~qemu-win/download/qemu-20060516-tap.patch Regards, Kazu ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] [PATCH] VLAN and Tap for win32
Monday, May 15, 2006 3:35 AM Fabrice Bellard wrote: Kazu wrote: Hi, VLAN and Tap patches for win32 are updated. I added handling for wait objects. http://www.h7.dion.ne.jp/~qemu-win/download/qemu-0.8.1-vlan.patch I don't undertand this patch: the connect() is meant to be non blocking so the 'socket_wait_event' just after is not correct. The wait for the connection must be done inside the QEMU main loop as it is done on the Unix target (connect() on Unix in non blocking mode usually return EINPROGRESS and we can wait for the connection using select()). connect() usually retruns with WSAEWOULDBLOCK and second time it becomes WSAEINVAL. It doesn't become WSAEINPROGRESS. Winsock FAQ says that WSAEWOULDBLOCK has a little different meaning with Unix socket and a header in MinGW says that WSAEINPROGRESS is deprecated in Winsock2. MS says that connect() should not be called again for asynchronous socket. This patch would be better. http://www.h7.dion.ne.jp/~qemu-win/download/qemu-20060515-vlan.patch http://www.h7.dion.ne.jp/~qemu-win/download/qemu-0.8.1-tap.patch OK for this one. Suppressing all the remaning polling in the win32 version would be good. In particular, it would be good to be able to wait for network events while waiting for other events. I heard that WSAWaitForMultipleEvents is the same as WaitForMultipleObjects in winsock 2 mailing list. I used it. I think supressing polling means using win32 thread. Is it OK? I will try to use threads. http://www.h7.dion.ne.jp/~qemu-win/download/qemu-20060515-tap.patch Regards, Kazu ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] [PATCH] VLAN and Tap for win32
Hi, VLAN and Tap patches for win32 are updated. I added handling for wait objects. http://www.h7.dion.ne.jp/~qemu-win/download/qemu-0.8.1-vlan.patch http://www.h7.dion.ne.jp/~qemu-win/download/qemu-0.8.1-tap.patch Regards, Kazu ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] QEMU 0.8.1
Sent: Thursday, May 04, 2006 5:45 AM Fabrice Bellard wrote:
Hi,
QEMU version 0.8.1 is available at http://bellard.org/qemu/download.html.
qemu-system-sparc.exe doesn't work. A patch is below.
Regards,
Kazu
--- qemu-0.8.1.orig/loader.c Thu May 4 05:32:58 2006
+++ qemu-0.8.1/loader.c Thu May 4 17:35:10 2006
@@ -200,7 +200,7 @@
int fd, data_order, must_swab, ret;
uint8_t e_ident[EI_NIDENT];
-fd = open(filename, O_RDONLY);
+fd = open(filename, O_RDONLY | O_BINARY);
if (fd 0) {
perror(filename);
return -1;
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Network Performance between Win Host and Linux
Hi, I have already made a patch. Try this. http://lists.gnu.org/archive/html/qemu-devel/2006-03/msg00041.html Regards, Kazu Sent: Wednesday, April 12, 2006 3:19 AM Helmut Auer wrote: Hello In my case, the guest CPU is idle. The host CPU utilization is only 5 or 10 percent when running find / -print /dev/null on the guest. So I don't think guest interrupt latency is the issue for me in this case. In my environment the performance of about 300 KB is the good case, that means the cpu is idle. When the cpu is busy it degrades to20 KB in the worst case. As I said before, with the tap-patched qemu 0.7.2 it is about 10 times faster. -- Helmut Auer, [EMAIL PROTECTED] ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] [PATCH] Timer/clock for Linux
Hi, I made a little patch of timer/clock for Linux host. It always trys to use /dev/rtc. getitimer doesn't report a correct interval value. http://www.h7.dion.ne.jp/~qemu-win/download/qemu-20060407-linux-timer.patch To get a precise timer/clock., do: (1) Set max-user-freq 1024 as root. [Linux host] # echo 1024 /proc/sys/dev/rtc/max-user-freq It is necessary to set it everytime you reboot the host OS. Write it to /etc/rc.d/rc.local. (2) Apply the patch and build a binary. (1) is necessary and (2) is optional. I think latest kernel doesn't need the patch. When I use 2.6.11-1.11369_FC4 host, it is necessary to apply (2). But when 2.6.15-1.1831_FC4 host, it is not. If you don't set max-user-freq, the clock in Windows 2000 guest is unstable while IE is running. Timer uses RTC(Real Time Clock). If it can not be used, setitimer/getitimer are used. If the timer's interval is set to 999 us, the interval becomes 2ms. It is the cause that a guest OS clock is 1/2 slow than the real time. Recent Linux kernel is 4ms and clock is 1/4 slow. Tested environments are: Windows 2000 guest/FC4 kernel-2.6.11-1.1831_FC4 host FC4-i386-rescuecd.iso guest/FC4 kernel-2.6.11-1.1831_FC4 host Windows 2000 guest/FC4 kernel-2.6.15-1.1831_FC4 host FC4-i386-rescuecd.iso guest/FC4 kernel-2.6.15-1.1831_FC4 host I have not tested Linux 2.4 host. The clock of guest OS on x86_64 host is unstable. 1ms interval interrupts occure but the clock in Windows 2000 guest on x86_64 host doesn't work well. Regards, Kazu ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] [PATCH] Improving timer/clock for win32
Sent: Saturday, April 01, 2006 6:54 AM André Braga wrote: Kazu, have you tested whether this avoids the hang (and 100% CPU time usage by QEMU, and being unable to kill the process by absolutely no means - Process Explorer's 'kill' included - other than rebooting) on WinXP host + kqemu and WinXP guest when opening the guests' clock application by double-clicking it on the taskbar? I know it but it isn't fixed. Regards, Kazu ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] [PATCH] Improving timer/clock for win32
Hi, This patch improves timer/clock for win32. Here is the patch and a binary. http://www.h7.dion.ne.jp/~qemu-win/download/qemu-20060330-timer.patch http://www.h6.dion.ne.jp/~kazuw/qemu-win/qemu-20060330-timer.zip It supports 1ms interval interrupt. It also improves the delay when it is used with Kqemu/Qvm86. A main reason of delay of time is that when main_loop_wait is slept and an interrupt timer is expired, the timer interrupt doesn't occured. I used an event object to wake up the main loop. I used QueryPerformanceCounter/QueryPerformanceFrequency to measure time. It uses ACPI PM Timer on my system. Some system use RDTSC value. It depends on your system. It might be possible to run on SMP(HT or Multi-core) system. I haven't tested it, though. Regards, Kazu ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] kqemu version 1.3.0pre5
Sent: Tuesday, March 28, 2006 6:30 AM Fabrice Bellard wrote: Hi, I just released a new version of kqemu which fixes some recently discovered issues. The fixes are the following: - Support for guest Linux kernels compiled with gcc = 3.3 - x86_64 host support is working again (only i386 on x86_64 full virtualization has been tested, x86_64 on x86_64 is implemented but not tested yet). - Workaround for full virtualization on Windows host (more tests needed). I tested Linux guest/WinXP host but the host OS crashed. Redhat 7.2 guest/Fedora Core 4 host with normal kqemu is slower than -no-kqemu. Why ? Regards, Kazu ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] kqemu version 1.3.0pre5
Sent: Tuesday, March 28, 2006 8:50 PM Brad Campbell wrote: Kazu wrote: I tested Linux guest/WinXP host but the host OS crashed. I believe -kernel-kqemu is still somewhat experimental on Windows host. Redhat 7.2 guest/Fedora Core 4 host with normal kqemu is slower than -no-kqemu. Why ? Have you got your tmpfs set up correctly so qemu can place its memory swap file in a ramdisk rather than on disk? I used tmpfs but the result is the same. Thanks, anyway. Regards, Kazu ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] [PATCH] Serial port suppourt for win32
Hi, I updated a serial patch. -serial pipe: and -serial file: option are supported. Here is a patch and binary. http://www.h7.dion.ne.jp/~qemu-win/download/qemu-20060320-serial-3.patch http://www.h6.dion.ne.jp/~kazuw/qemu-win/qemu-20060320-serial.zip Option's examples are: -serial pipe:com_1 -serial file:text.txt Only one -serial option is supported. Use lower case for pipe: and file:. -serial pipe:com_1 option is for windbg. For more information, http://www.h7.dion.ne.jp/~qemu-win/DebuggingTips-en.html#windbg Regards, Kazu Sent: Wednesday, March 15, 2006 3:44 PM from Kazu Hi, It is an experimental serial port support for win32. Here is patches and a binary. http://www.h7.dion.ne.jp/~qemu-win/download/qemu-20060311-serial-3.patch http://www.h7.dion.ne.jp/~qemu-win/download/qemu-20060311-16550a.patch http://www.h7.dion.ne.jp/~qemu-win/download/qemu-20060311-serial-win2kxp.patch http://www.h6.dion.ne.jp/~kazuw/qemu-win/qemu-20060311-serial.zip The 16550A patch is by Benoit Canet from here. http://lists.gnu.org/archive/html/qemu-devel/2006-02/msg4.html An option is: -serial COM1 ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] serial control DTR/DSR RTS/CTS
Sent: Tuesday, March 14, 2006 4:23 PM Drlik Zbynek wrote: Hello. My external device is connected with serial port and use hardware flow control - it can switch beetwen DTR/DSR or RTS/CTS. I have instaled winxp and win98 for multiplatform testing in qemu but my aplication - if i wont to communicate must by set to no flow control. In that case it could by read from device without lost data, write isn't funcional - much data lost. When I set up some control - state of DTR or RTS are still down and communication isn't allowed. Qemu run under linux. When I run application in normaly installed windows without qemu, the application run perfectly with any of that conntrols. Is there any possibility to correct this? Thanks. Drlik Zbynek. It is a quck hack for it. http://www.h7.dion.ne.jp/~qemu-win/download/qemu-20060311-serial-win2kxp.patch Regards, Kazu ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] [PATCH] Japanese keyboard
Hi, Attached is a patch for Japanese keyboard. It is for X Window on Linux. I tested it on Fedora Core 4 host. It has a workaround for SDL bug. Regards, kazu qemu-20060226-keyboard.patch Description: Binary data ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] [PATCH] Serial port suppourt for win32
Hi, It is an experimental serial port support for win32. Here is patches and a binary. http://www.h7.dion.ne.jp/~qemu-win/download/qemu-20060311-serial-3.patch http://www.h7.dion.ne.jp/~qemu-win/download/qemu-20060311-16550a.patch http://www.h7.dion.ne.jp/~qemu-win/download/qemu-20060311-serial-win2kxp.patch http://www.h6.dion.ne.jp/~kazuw/qemu-win/qemu-20060311-serial.zip The 16550A patch is by Benoit Canet from here. http://lists.gnu.org/archive/html/qemu-devel/2006-02/msg4.html An option is: -serial COM1 Use upper-case for COM number. Dialog is popped up and set communication parameters. After patches are applied and the first time Windows boots, Windows recognizes the device is updated. So wait until a device driver is installed and reboot. I have not tested a real COM port. I used ComEmulDrv which provides a virtual COM port pair as a device driver for Win2k/XP. I set COM5 and COM6 by it and used HyperTerminal on both Win2k guest and WinXP host. Files can be transfer between them. http://mixw.net/related.htm#tncemu Communication parameters are important. Tested parameters are: Baud rate: 9600 bps Data bit: 8 bit Parity: none Stop bit: 1 Flow control: none It is necessary to set the same parameters among the guest and the host and QEMU. When flow control is hardware, if qemu-20060311-serial-win2kxp.patch is not used, data can not be sent from Win2k guest to WinXP host. It is too slow to use windbg. I will try to make a patch to use a named pipe for it. Regards, Kazu ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Network Performance between Win Host and Linux Guest
Tuesday, March 07, 2006 6:44 AM Helmut Auer wrote: [EMAIL PROTECTED] schrieb: Hello, I just upgraded to qemu 0.8.0 including vlan/tap patch and I noticed that the network speed is much slower than under 0.7.2 with tap patch ( 300KB/s vs 1MB/s ). Any hints what I can do to sped this up ? Helmut No ideas what can cause this ? I just checked it again with the tapped win binaries from the dion page. Net performance is about 15 times faster under 0.7.2 Attached patch improves the performance against current CVS. Regards, Kazu qemu-20060307-tap.patch Description: Binary data ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] -kernel-kqemu
Sent: Friday, February 10, 2006 7:01 AM Fabrice Bellard wrote: Hi, I will update the documentation about -kernel-kqemu soon. To be short: as some people already noticed, this option allows to run user code and most of the kernel code on bare metal. The result is usually a noticable speed up. Only the following guest OSes are supported: Linux, Windows 2000 or XP. The installation of Windows 2000/XP must be run without the -kernel-kqemu option. I did not test the win32 and x86_64 versions of kqemu yet, but the i386 version is usable. I tested it on Windows XP host. But linux.img in linux-test package and Win2k don't boot. A strange thing is that when I used RedHat 7.2 guest, user-kqemu is much slower than no-kqemu. On Fedora Core 4 host, Win2k boots fine and is faster than user-kqemu and no-kqemu. Great! linux.img from linux-test package also works fine with kernel-kqemu, user-kqemu on FC4 host. But FC4-i386-rescuecd.iso guest doesn't boot with kernel-kqemu. It works with user-kqemu and no-kqemu. I can see about TSC error messages. Morphix.iso doesn't boot with kernel-kqemu. It works with user-kqemu and no-kqemu. I couldn't see booting logo. And a strange thing is that when I used Redhat 7.2 guest, user-kqemu is much slower than no-kqemu. And kernel-kqemu is much slower than user-kqemu. It is the same result as on WinXP host. I seems that Linux guest doesn't work well. PS. user-kqemu means no option. Regards, Kazu ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel][PATCH] Tap and VLAN socket support for win32
Hi, I send this mail again because it doesn't reach qemu-devel list by unknown security reason. Sent: Sunday, February 05, 2006 3:28 AM Fabrice Bellard wrote: Kazu wrote: Thursday, February 02, 2006 8:10 AM Fabrice Bellard wrote: Hi, I merged your patches and I made important changes to simplify them. I did not do any tests so tell me if you see problems. -net socket,connect doesn't work. On Windows host, connect returns with err = WSAEWOULDBLOCK and second time err = WSAEINVAL. I think changing the place of EWOULDBLOCK would be good. On Linux host, EWOULDBLOCK is the same as EAGAIN but a patch works on both Linux and Windows. Unfortunately on Linux the correct return value we are expecting is EINPROGRESS. EAGAIN means that the 'connect' was not initiated so it is necessary to redo it. There is not good way to detect a completion of asynchronous connect. So I used an event object to detect it. A patch is attached. For -net socket,mcast, bind have to be done by sin_addr.s_addr = INADDR_ANY. It seems that it works on Linux host. It works on Linux but it is not correct because it prevents from listening to several multicast addresses at the same time. If doing the same on Windows is not possible I agree to make a special case. I couldn't find a way to set a multicast address. I made it a special case in the patch Regards, Kazu qemu-20060208-vlan-2.patch.gz Description: GNU Zip compressed data ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel][PATCH] Tap and VLAN socket support for win32
Sunday, February 05, 2006 3:28 AM Fabrice Bellard wrote:
Kazu wrote:
Thursday, February 02, 2006 8:10 AM Fabrice Bellard wrote:
Hi,
I merged your patches and I made important changes to simplify them. I
did not do any tests so tell me if you see problems.
-net socket,connect doesn't work. On Windows host, connect returns with
err
= WSAEWOULDBLOCK and second time err = WSAEINVAL. I think changing the
place
of EWOULDBLOCK would be good. On Linux host, EWOULDBLOCK is the same as
EAGAIN but a patch works on both Linux and Windows.
Unfortunately on Linux the correct return value we are expecting is
EINPROGRESS. EAGAIN means that the 'connect' was not initiated so it is
necessary to redo it.
There is not good way to detect a completion of asynchronous connect. So I
used an event object to detect it. A patch is attached.
For -net socket,mcast, bind have to be done by sin_addr.s_addr =
INADDR_ANY.
It seems that it works on Linux host.
It works on Linux but it is not correct because it prevents from listening
to several multicast addresses at the same time. If doing the same on
Windows is not possible I agree to make a special case.
I couldn't find a way to set a multicast address. I made it a special case
in the patch
Regard,
Kazu
Index: vl.c
===
RCS file: /sources/qemu/qemu/vl.c,v
retrieving revision 1.162
diff -u -r1.162 vl.c
--- vl.c 5 Feb 2006 04:14:41 - 1.162
+++ vl.c 8 Feb 2006 05:50:28 -
@@ -1083,9 +1083,10 @@
#define socket_error() WSAGetLastError()
#undef EINTR
-#define EWOULDBLOCK WSAEWOULDBLOCK
-#define EINTR WSAEINTR
-#define EINPROGRESS WSAEINPROGRESS
+#define EWOULDBLOCK WSAEWOULDBLOCK
+#define EINTR WSAEINTR
+#define EINPROGRESS WSAEINPROGRESS
+#define EADDRNOTAVAIL WSAEADDRNOTAVAIL
static void socket_cleanup(void)
{
@@ -1136,6 +1137,59 @@
ioctlsocket(fd, FIONBIO, opt);
}
+static int socket_set_event(SOCKET fd, WSAEVENT *phEvent)
+{
+int ret;
+
+*phEvent = WSACreateEvent();
+if (*phEvent == WSA_INVALID_EVENT) {
+perror(connect: CreateEvent);
+return -1;
+}
+
+ret = WSAEventSelect(fd, *phEvent, FD_CONNECT);
+if (ret == SOCKET_ERROR) {
+perror(connect: EventSelect);
+return -1;
+}
+return 0;
+}
+
+static int socket_wait_event(SOCKET fd, WSAEVENT *phEvent)
+{
+WSANETWORKEVENTS events;
+int ret;
+
+ret = WSAWaitForMultipleEvents(1, phEvent, FALSE, WSA_INFINITE, FALSE);
+if (ret == WSA_WAIT_FAILED) {
+perror(connect: Wait);
+goto fail;
+}
+
+ret = WSAEnumNetworkEvents(fd, *phEvent, events);
+if (ret == SOCKET_ERROR) {
+perror(connect: EnumEvent);
+goto fail;
+} else {
+if (events.lNetworkEvents FD_CONNECT) {
+if (events.iErrorCode[FD_CONNECT_BIT] == 0) {
+if (*phEvent != WSA_INVALID_EVENT)
+WSACloseEvent(*phEvent);
+return 1;
+} else {
+perror(connect: refused);
+goto fail;
+}
+} else {
+perror(connect: fd_connect);
+goto fail;
+}
+}
+ fail:
+if (*phEvent != WSA_INVALID_EVENT)
+WSACloseEvent(*phEvent);
+return 0;
+}
#else
#define socket_error() errno
@@ -2330,7 +2384,9 @@
{
struct ip_mreq imr;
int fd;
-int val, ret;
+int val, ret, err;
+struct sockaddr_in addr;
+
if (!IN_MULTICAST(ntohl(mcastaddr-sin_addr.s_addr))) {
fprintf(stderr, qemu: error: specified mcastaddr \%s\ (0x%08x) does not
contain a multicast address\n,
inet_ntoa(mcastaddr-sin_addr),
@@ -2354,8 +2410,22 @@
ret = bind(fd, (struct sockaddr *)mcastaddr, sizeof(*mcastaddr));
if (ret 0) {
-perror(bind);
-goto fail;
+err = socket_error();
+if (err == EADDRNOTAVAIL) {
+memset(addr, 0, sizeof(addr));
+addr.sin_family = AF_INET;
+addr.sin_port = mcastaddr-sin_port;
+addr.sin_addr.s_addr = INADDR_ANY;
+
+ret = bind(fd, (struct sockaddr *)addr, sizeof(addr));
+if (ret 0) {
+perror(bind);
+goto fail;
+}
+} else {
+perror(bind);
+goto fail;
+}
}
/* Add host to multicast group */
@@ -2557,11 +2627,15 @@
return 0;
}
+
static int net_socket_connect_init(VLANState *vlan, const char *host_str)
{
NetSocketState *s;
int fd, connected, ret, err;
struct sockaddr_in saddr;
+#ifdef _WIN32
+WSAEVENT hEvent;
+#endif
if (parse_host_port(saddr, host_str) 0)
return -1;
@@ -2573,6 +2647,26 @@
}
socket_set_nonblock(fd);
+#ifdef _WIN32
+ret = socket_set_event(fd, hEvent);
+if (ret 0) {
+perror(connect: set_event);
+closesocket(fd);
+return -1;
+}
+
+connected = 0;
+ret = connect(fd, (struct sockaddr *)saddr, sizeof(saddr
Re: [Qemu-devel][PATCH] Tap and VLAN socket support for win32
Thursday, February 02, 2006 8:10 AM Fabrice Bellard wrote:
Hi,
I merged your patches and I made important changes to simplify them. I
did not do any tests so tell me if you see problems.
-net socket,connect doesn't work. On Windows host, connect returns with err
= WSAEWOULDBLOCK and second time err = WSAEINVAL. I think changing the place
of EWOULDBLOCK would be good. On Linux host, EWOULDBLOCK is the same as
EAGAIN but a patch works on both Linux and Windows.
For -net socket,mcast, bind have to be done by sin_addr.s_addr = INADDR_ANY.
It seems that it works on Linux host.
Regards,
Kazu
Index: vl.c
===
RCS file: /sources/qemu/qemu/vl.c,v
retrieving revision 1.160
diff -u -r1.160 vl.c
--- vl.c 1 Feb 2006 23:06:55 - 1.160
+++ vl.c 2 Feb 2006 09:28:19 -
@@ -2335,7 +2335,13 @@
goto fail;
}
-ret = bind(fd, (struct sockaddr *)mcastaddr, sizeof(*mcastaddr));
+struct sockaddr_in addr;
+memset(addr, 0, sizeof(addr));
+addr.sin_family = AF_INET;
+addr.sin_port = mcastaddr-sin_port;
+addr.sin_addr.s_addr = INADDR_ANY;
+
+ret = bind(fd, (struct sockaddr *)addr, sizeof(addr));
if (ret 0) {
perror(bind);
goto fail;
@@ -2561,8 +2567,8 @@
ret = connect(fd, (struct sockaddr *)saddr, sizeof(saddr));
if (ret 0) {
err = socket_error();
-if (err == EINTR || err == EWOULDBLOCK) {
-} else if (err == EINPROGRESS) {
+if (err == EINTR) {
+} else if (err == EINPROGRESS || err == EWOULDBLOCK) {
break;
} else {
perror(connect);
qemu-20060202-vlan.patch
Description: Binary data
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] HT problem
Sunday, January 15, 2006 6:43 AM malc wrote: On Fri, 23 Dec 2005, Kazu wrote: Hi, I have a report that when hyper-threading is on, Linux doesn't boot on Windows XP. It occurs when linux kernel is loading. But when HT is turned off, qemu works fine. Does this occur on Linux host ? Jari Komppa made a launcher that sets affinities just right to run QEMU on Windows HT/MP systems. The binary and source are available at: http://sol.gfxile.net/ (http://sol.gfxile.net/files/splauncher.zip) Great! I asked my friends and got a report that it works on HT system.. Regard, Kazu ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] [PATCH] VLAN socket support for win32
Hi, This is a patch to support -net socket,listen ,-net socket,connect and -net socket,mcast for Win32. I used select instead of poll. I set blank space to see disconnecting the socket. Out of band data is not cared. I added listen socket to VLANClient to close socket. Allocated memories are freed when the program finishes. It seems that they are not freed on Linux host. Opened sockets are closed when program finishes. It seems that it is not closed on Linux host. Here is a patch and binary I used. http://www.h7.dion.ne.jp/~qemu-win/download/qemu-20060102-vlan-4.patch http://www.h6.dion.ne.jp/~kazuw/qemu-win/qemu-20060102-vlan.zip I took three experiment. Here is a report I made. ping, telnet, ssh and lynx are used as client. I made two copies of Redhat hard disk image and start them at different terminals. ne2k-pci kernel module is loaded so that I can see network interface by ifconfig -a. Overall notices are: It is necessary to set macaddr at the second OS. IP address or localhost is necesary to set listen or connect. Otherwise it is set to 0.0.0.0. Don't start two QEMU using one hard disk image. It will break your hard disk image. CASE 1: Guest-only network Command line options are: term1$ qemu -L ./pc-bios -hda redhat1.img -net nic -net socket,listen=localhost:1234 term2$ qemu -L ./pc-bios -hda redhat2.img -net nic,macaddr=52:54:00:12:34:57 -net socket,connect=localhost:1234 Setinng on guest OS: Redhat1 guestifconfig eth0 10.0.2.16 Redhat2 guestifconfig eth0 10.0.2.17 Results: ping works between two guests. telnet, ssh work fine between them.. CASE2: One guest using user-mode net, listening socket at the different VLAN bus and the other connecting to the one Command line options are: term1$ qemu -L ./pc-bios -hda redhat1.img -net nic,vlan=1 -net user,vlan=1 -net nic,vlan=2,macaddr=52:54:00:12:34:57 -net socket,vlan=2,listen=localhost:1234 term2$ qemu -L ./pc-bios -hda redhat2.img -net nic,vlan=2,macaddr=52:54:00:12:34:01 -net socket,vlan=2,connect=localhost:1234 Setting on guest OS: Redhat1 guest dhcpcd eth0 (or dhclinet eth0. If eth0 has been already configured, it is not necessary to do this.) (eth0 will get 10.0.2.15 or 10.0.2.16.) Redhat1 guest ifconfig eth1 192.168.10.2 The second guest OS does not have DHCP server so that it is necessary to set IP address. Redhat2 guest ifconfig eth0 192.168.10.3 Redhat2 guest route add default gw 192.168.10.2 eth0 Results: telnet and ssh works between guests. lynx works on Redhat1. It is necessary to set Redhat1 as a router to browse the Internet from Redhat2. Note: VLAN ID is NOT necessary the same between guests. Port number (in this case 1234) determines which bus is used. CASE3: One guest using user-mode net and listening socket in the same VLAN bus and the other guest is connecting to the one It doesn't work well but for your infomation. Command line options are: term1$ qemu -L ./pc-bios -hda redhat1.img -net nic -net user -net socket,listen=localhost:1234 term2$ qemu -L ./pc-bios -hda redhat2.img -net nic,macaddr=52:54:00:12:34:01 -net socket,connect=localhost:1234 Setting on guest OS: Redhat1 guest dhcpcd eth0 (Or dhclient eth0) The second guest OS gets IP address from DHCP server but it is the same IP as the first OS's IP. It is necessary to set it manually. Redhat2 guest ifconfig eth0 10.0.2.17 Redhat2 guest route add default gw 10.0.2.2 eth0 Results: telnet sometimes works but sometimes refuse to connect. When telnetd is working on connected guest, it can be success. When ssh is used, RSA key is saved at the first time but failed with this message. Write failed: Connection reset by peer. After second time, it failed with this message. ssh_exchange_identification: read: Connection Reset by peer. I can browse the Internet from both Redhat1 and Redhat2. Notes: This case does not work well. It is not necessary to set Redhat1 as router to browse the Internet from Redhat2. It is good if case 3 works well, but it has a problem. These results are the same as on Linux host. For more information. http://www.h7.dion.ne.jp/~qemu-win/HowToNetwork-en.html#vlan Regards, Kazu ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] HT problem
Hi, I have a report that when hyper-threading is on, Linux doesn't boot on Windows XP. It occurs when linux kernel is loading. But when HT is turned off, qemu works fine. Does this occur on Linux host ? Host: Windows XP SP2 Guest : linux-test image QEMU version : 0.8.0 ASUS P4P800 Deluxe Intel Pentium4 3.0GHz DDR400 512MB x 2 Regards, Kazu ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Real hard disk drive for Win2k/XP host
Thursday, September 15, 2005 12:39 AM Jim C. Brown wrote: I don't see any code for this in your patch. AFAIK qemu supports this already. I didn't know that. Thanks. Regards, Kazu ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] Real hard disk drive for Win2k/XP host
Hi, This patch supports a real hard disk drive by \\.\PhysicalDriveN (N=0,1,2,...) on Windows 2000/XP host. Windows 98/Me are not supported. You can also use slash like //./PhysicalDriveN. You can see a number in Administration Tools in Control Panel. This is not case-sensitive. It is necessary to have an administrative priviledge.This can be used like this. qemu.exe -L .\bios -hda win2k.img -hdb \\.\PhysicalDrive0 This patch also adds a size information about CD-ROM. It is safe to use it as a read-only. Making a file from guest OS to real hard disk isn't recognized immediately. Rebooting a host OS recognized the file. Making a directory from guest OS breaks a host's file system. There is a case that changes of files in a host OS isn't recognized by a guest OS. Shut down the guest OS, move the file to another directory and boot the guest OS. Then the file is recognized. Windows 98/Me doesn't recognize NTFS file system. When you use Windows XP on NTFS, Windows 98/Me guest can't see host files. If you don't have a multi-boot environment, don't boot from your system hard disk. qemu.exe -L .\bios -hda \\.\PhysicalDrive0 It will break your host OS. Regards, Kazu qemu-0.7.2-hd.patch Description: Binary data ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] ssh access from a Windows Host
Friday, August 26, 2005 3:39 AM Helmut Auer wrote: Hi List, I tried to access the linux 2.6 client from the windows host via ssh using putty. therfore I started: qemu -user-net -redir tcp:::22 ... the sshd is started on the client, but putty -ssh localhost does not work. Also using the own IP address instead of localhost does not help. Any hints what I am doing wrong ? What is your guestOS's IP address? If it is 10.0.2.16, options should be qemu.exe -user-net -redir tcp::10.0.2.16:22 ... Regards, Kazu ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Read/Write to shares on Windows (XP Pro) host fromWindows (2000 Adv) guest.
Thursday, August 25, 2005 11:23 AM Francois Rioux wrote: What I'm trying to achieve is to write a file from a guest OS to a host. In this case both are Windows OS. I use the user network command line options since I looking for a no install on host, portable solution. I've tried various build in solutions: -tftp (read-only), and -smb (not supported in windows host) do me no good. What I manage to do with a certain success is to map network shares of the host in the guest (net use z: 10.0.2.2\MyShare in the guest). I can browse and read files from the mapped drive. However I can't write to it from the guest. I received an Access Denied message instead even if the share is set so Everyone has Full Control. I think there is a checkbox that Allow to change files to network user in MyShrare folder's property on Windows XP host. Sorry I don't have English version of Windows, so explanation is not correct. I checked it, then I can write a file from guest to host. There isn't such checkbox on Windows 2000 host. Regards, Kazu ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] DMA in Windows 2000/XP/2003
Hi, Tuesday, August 23, 2005 10:28 PM Víctor Córcoles López wrote: Subject: [Qemu-devel] DMA in Windows 2000/XP/2003 Hello developers. My English is not good. I see that DMA in Hard Disks in guest OS Windows 2000/XP/2003 is not avalaible, it run in PIO mode. How can activate UDMA mode for hard disk ? This patch might help.. http://ebisa.hp.infoseek.co.jp/qemu/arcs/qemu-piix4-udma-20050514.zip This patch is made by Juergen Lock and Juergen Keil and improved by lukewarm. Hard disk is DMA mode but CD-ROM is PIO mode. Windows98/2000 and OS/2 work with this patch. FreeSBIE also works because CD-ROM is PIO mode. http://lists.gnu.org/archive/html/qemu-devel/2004-11/msg00468.html Regards, Kazu ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] qemu-img.exe to create file greater than 4GB for win32
Hi, Now qemu-img.exe can't create a file greater than 2GB on Windows. A patch and a binary below supports to make a file greater than 4GB on NTFS file system for Windows 2000/XP. This patch is made by lukewarm. http://ebisa.hp.infoseek.co.jp/qemu/arcs/qemu-0.7.1-win32-imgover4g.zip Note: MinGW's ls doesn't show a correct file size if greater than 2GB. Regards, Kazu ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] pcnet/mingw32 debug info (help needed)
Hi, Sent: Friday, July 22, 2005 4:31 PM Christian MICHON wrote: here's the output of gdb. If anyone can make something from it, thanks in advance. This is a part of backtrace output of gdb after I set IP address and ping 10.0.2.2. I seems that arp packet loops endlessly between pcnet and slirp. I think something is wrong in pcnet_receive? #27399 0x004552ac in pcnet_transmit (s=0xcdbf8e8) at C:/msys/1.0/home/kazu/qemu-0.7.0/hw/pcnet.c:582 #27400 0x00455571 in pcnet_poll (s=0xcdbf8e8) at C:/msys/1.0/home/kazu/qemu-0.7.0/hw/pcnet.c:625 #27401 0x00454fc3 in pcnet_receive (opaque=0xcdbf8e8, buf=0x22f7b0 RT, size=0) at C:/msys/1.0/home/kazu/qemu-0.7.0/hw/pcnet.c:538 #27402 0x004025f7 in slirp_output (pkt=0x22f7b0 RT, pkt_len=42) at C:/msys/1.0/home/kazu/qemu-0.7.0/vl.c:1402 #27403 0x0045b980 in arp_input (pkt=0xcdbfc30 ??RT, pkt_len=42) at C:/msys/1.0/home/kazu/qemu-0.7.0/slirp/slirp.c:583 #27404 0x0045b9dc in slirp_input (pkt=0xcdbfc30 ??RT, pkt_len=42) at C:/msys/1.0/home/kazu/qemu-0.7.0/slirp/slirp.c:602 #27405 0x00402611 in slirp_send_packet (nd=0x4e6a90, buf=0xcdbfc30 ??RT, size=42) at C:/msys/1.0/home/kazu/qemu-0.7.0/vl.c:1411 #27406 0x00402541 in qemu_send_packet (nd=0x4e6a90, buf=0xcdbfc30 ??RT, size=42) at C:/msys/1.0/home/kazu/qemu-0.7.0/vl.c:1353 #27407 0x004552ac in pcnet_transmit (s=0xcdbf8e8) at C:/msys/1.0/home/kazu/qemu-0.7.0/hw/pcnet.c:582 #27408 0x00455571 in pcnet_poll (s=0xcdbf8e8) at C:/msys/1.0/home/kazu/qemu-0.7.0/hw/pcnet.c:625 #27409 0x004556aa in pcnet_poll_timer (opaque=0xcdbf8e8) at C:/msys/1.0/home/kazu/qemu-0.7.0/hw/pcnet.c:647 #27410 0x00455fa1 in pcnet_ioport_writew (opaque=0xcdbf8e8, addr=49202, val=0) at C:/msys/1.0/home/kazu/qemu-0.7.0/hw/pcnet.c:915 #27411 0x004018f0 in cpu_outw (env=0x3d7358, addr=49202, val=0) at C:/msys/1.0/home/kazu/qemu-0.7.0/vl.c:372 #27412 0x0078456b in code_gen_buffer () #27413 0x00404315 in main_loop () at C:/msys/1.0/home/kazu/qemu-0.7.0/vl.c:2700 #27414 0x00406c94 in main (argc=6, argv=0x3d27e8) at C:/msys/1.0/home/kazu/qemu-0.7.0/vl.c:3719 (gdb) q This backtrace said that as follows. cpu_outputw pcnet_ioport_wirtew - arp packet is send from pcnet to slirp pcnet_poll_timer pcnet_poll pcnet_transmit snip slirp_input arp_input - arp packet returns form slirp to pcnet slirp_output pcnet_receive - arp packet received by pcnet pcnet_poll - I don't know why pcnet_poll is called again pcnet_transmit - endless loop Regards, Kazu ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
