[Qemu-devel] Emulation differences, qemu-system-x86_64 vs Athlon64
Recently I've been playing with CVS qemu-system (softmmu) on amd64 and had some stability problems. I decided to run Valgrind's amd64 instruction-set tests (derived from qemu's) to see if they picked up anything. Resulting diffs are attached. There are a bunch of differences for the C flag for rotates (rol/ror) by multiples of the word size. I don't think these are significant, but who knows. Perhaps more worryingly are the 20 or so lines at the bottom of the diff. These I believe are for double-to-int/short conversions for a value which is out of range for an int/short; the hardware produces 0x8000/0x8000 respectively, which is the "integer indefinite"; QEMU produces zero. I can imagine some obscure routine somewhere checking for integer indefinite after conversion and being confused as a result. J diffs-qemu-vs-Athlon64.txt.bz2 Description: BZip2 compressed data ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Re: Network Performance between Win Host and Linux
Hi Ken, (all) the patches seem to work very well and be very stable with Windows 2000 guests here. I measured some SMB over TCP/IP transfers, and got about a 1.5x downstream improvement and a 2x upstream improvement. You will likely get more boost from less convoluted protocols like FTP or something, but I didn't get around to testing that. Plus it's not clear how much Windows itself is impeding the bandwidth. I am using -kernel-kqemu. 2 additional things I noticed: 1. before your patches, the upstream transfers (guest->host) consumed almost no CPU at all, but of course were much slower. Now, about half the CPU gets used under heavy upstream load. The downstream, with Windows guests at least, consumes 100% CPU the same as before. I suspect you addressed this specifically with your select hack to avoid the delay if there is pending slirp activity 2. overall latency "feels" improved as well, at least for basic stuff like web browsing, etc. This is purely subjective. Nice work! I'll be testing with a Linux VM soon and try to pin down some better benchmarks, free of Windows clutter. - Leo Reiter Kenneth Duda wrote: The "qemu-slirp-performance" patch contains three improvements to qemu slirp networking performance. Booting my virtual machine (which NFS-mounts its root filesystem from the host) has been accelerated by 8x, from over 5 minutes to 40 seconds. TCP throughput has been accelerated from about 2 megabytes/sec to 9 megabytes/sec, in both directions (measured using a simple python script). The system is subjectively more responsive (for activities such as logging in or running simple python scripts). The specific problems fixed are: - the mss for the slirp-to-vm direction was 512 bytes (now 1460); - qemu would block in select() for up to four milliseconds at a time, even when data was waiting on slirp sockets; - slirp was deliberately delaying acks until timer expiration (TF_DELACK), preventing the vm from opening its send window, in violation of rfc2581. These fixes are together in one patch (qemu-slirp-performance.patch). -- Leonardo E. Reiter Vice President of Product Development, CTO Win4Lin, Inc. Virtual Computing from Desktop to Data Center Main: +1 512 339 7979 Fax: +1 512 532 6501 http://www.win4lin.com ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] PowerPC doesn't work
Is there any place I could submit a bug? I wasn't able to run ppc emulation in Qemu 0.8.0, and I found people with similar problems on users forum. I was unable to find any ppc success report. http://fabrice.bellard.free.fr/qemu/status.html shows that ppc is "OK". I tried to change rom to version from this website: http://perso.magic.fr/l_indien/qemu-ppc/ But it also didn't help. Could you point me to bugtracker or person who knows something about ppc in Qemu? The information contained in this e-mail and in any attachments is confidential and is designated solely for the attention of the intended recipient(s). If you are not an intended recipient, you must not use, disclose, copy, distribute or retain this e-mail or any part thereof. If you have received this e-mail in error, please notify the sender by return e-mail and delete all copies of this e-mail from your computer system(s). Please direct any additional queries to: [EMAIL PROTECTED] Thank You. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Re: Network Performance between Win Host and Linux
On an additional note, Windows host users may want to try moving the arbitrary Sleep() in main_loop_wait() to the end of the function, and making that conditional if there are no I/O events pending. Otherwise, there is a fixed penalty and this does not take advantage of Ken's new patch to avoid the delay if there are pending slirp requests for example. When I have some time I will see if there is a better way to multiplex poll in Windows, so that you can use something like select() but still get interrupted. There might for example be something relevant in the newer winsock libraries (i.e. V2), but of course it has to be general enough to work on any type of fd. I apologize but I have not yet been able to successfully build QEMU on Windows, even after mucking with the mingw stuff. I probably need to spend more time on it at some point. But if anyone is using Windows and can compile QEMU from source, you can try moving the Sleep to see if that helps, especially after applying Ken's new patches. Actually Kazu's patch for TAP performance addresses this for TAP for example, so it should be easy to adapt to slirp... the code is in very close proximity. - Leo Reiter Kenneth Duda wrote: The "qemu-slirp-performance" patch contains three improvements to qemu slirp networking performance. Booting my virtual machine (which NFS-mounts its root filesystem from the host) has been accelerated by 8x, from over 5 minutes to 40 seconds. TCP throughput has been accelerated from about 2 megabytes/sec to 9 megabytes/sec, in both directions (measured using a simple python script). The system is subjectively more responsive (for activities such as logging in or running simple python scripts). -- Leonardo E. Reiter Vice President of Product Development, CTO Win4Lin, Inc. Virtual Computing from Desktop to Data Center Main: +1 512 339 7979 Fax: +1 512 532 6501 http://www.win4lin.com ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] PowerPC doesn't work
> Could you point me to bugtracker or person who knows something about ppc > in Qemu? Bug reporting, patch submission and feature/development discussion is all done on this mailing list. Additionally you can get help in irc (#qemu on freenode) and the user forum. Now to get your problem pinned down, you should try to check if it prevails with the current cvs version of qemu. With regards, Jan Simons ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Re: Network Performance between Win Host and Linux
Leo, thank you for exercising this stuff. > 1. before your patches, the upstream transfers (guest->host) consumed > almost no CPU at all, but of course were much slower. Now, about half > the CPU gets used under heavy upstream load. I am surprised that only half the CPU gets consumed --- that suggests there's another factor of two improvement waiting to be made. If you see anything like this with Linux-on-Linux, please let me know and I'll try to track it down. Separately, I'm curious about the path for getting these changes into the qemu mainline. If that's something you're in tune with and are in the mood to summarize for me, I'd appreciate that. We love qemu but there are some rough edges and I think we have something like 16 patches we're maintaining internally, many of which might be helpful for others. -Ken On 4/12/06, Leonardo E. Reiter <[EMAIL PROTECTED]> wrote: > Hi Ken, > > (all) the patches seem to work very well and be very stable with Windows > 2000 guests here. I measured some SMB over TCP/IP transfers, and got > about a 1.5x downstream improvement and a 2x upstream improvement. You > will likely get more boost from less convoluted protocols like FTP or > something, but I didn't get around to testing that. Plus it's not clear > how much Windows itself is impeding the bandwidth. I am using > -kernel-kqemu. > > 2 additional things I noticed: > > 1. before your patches, the upstream transfers (guest->host) consumed > almost no CPU at all, but of course were much slower. Now, about half > the CPU gets used under heavy upstream load. The downstream, with > Windows guests at least, consumes 100% CPU the same as before. I > suspect you addressed this specifically with your select hack to avoid > the delay if there is pending slirp activity > > 2. overall latency "feels" improved as well, at least for basic stuff > like web browsing, etc. This is purely subjective. > > Nice work! I'll be testing with a Linux VM soon and try to pin down > some better benchmarks, free of Windows clutter. > > - Leo Reiter ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Re: Network Performance between Win Host and Linux
Ken, I'll check that on Linux-on-Linux... it's likely just some Windows overhead. Windows is my guest OS priority, which is why I tested on Windows. As for getting patches into the mainline, this is a job for the maintainers. Fabrice is the main person, but Paul Brook also merges a lot of patches in. I'm not sure what their process is, or to what extent they communicate with each other. I'm sure Paul and/or Fabrice would be kind enough to explain. I agree that there are lots of pending patches... in the case of yours specifically though, since it's so sweeping, I would guess that it probably needs more field testing before it becomes mainline. Regards, Leo Reiter Kenneth Duda wrote: Leo, thank you for exercising this stuff. 1. before your patches, the upstream transfers (guest->host) consumed almost no CPU at all, but of course were much slower. Now, about half the CPU gets used under heavy upstream load. I am surprised that only half the CPU gets consumed --- that suggests there's another factor of two improvement waiting to be made. If you see anything like this with Linux-on-Linux, please let me know and I'll try to track it down. Separately, I'm curious about the path for getting these changes into the qemu mainline. If that's something you're in tune with and are in the mood to summarize for me, I'd appreciate that. We love qemu but there are some rough edges and I think we have something like 16 patches we're maintaining internally, many of which might be helpful for others. -Ken On 4/12/06, Leonardo E. Reiter <[EMAIL PROTECTED]> wrote: Hi Ken, (all) the patches seem to work very well and be very stable with Windows 2000 guests here. I measured some SMB over TCP/IP transfers, and got about a 1.5x downstream improvement and a 2x upstream improvement. You will likely get more boost from less convoluted protocols like FTP or something, but I didn't get around to testing that. Plus it's not clear how much Windows itself is impeding the bandwidth. I am using -kernel-kqemu. 2 additional things I noticed: 1. before your patches, the upstream transfers (guest->host) consumed almost no CPU at all, but of course were much slower. Now, about half the CPU gets used under heavy upstream load. The downstream, with Windows guests at least, consumes 100% CPU the same as before. I suspect you addressed this specifically with your select hack to avoid the delay if there is pending slirp activity 2. overall latency "feels" improved as well, at least for basic stuff like web browsing, etc. This is purely subjective. Nice work! I'll be testing with a Linux VM soon and try to pin down some better benchmarks, free of Windows clutter. - Leo Reiter ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel -- Leonardo E. Reiter Vice President of Product Development, CTO Win4Lin, Inc. Virtual Computing from Desktop to Data Center Main: +1 512 339 7979 Fax: +1 512 532 6501 http://www.win4lin.com ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] usb-tablet support
Hello, I'm a little late for the party, it seems... ...never the less: here comes the patch for cocoa.m Tested with win2k and winXP. This patch fixes the cocoa compile problem that was introduced with the multi-display-support as well. Greetings Mike cocoa.m_tablet_02.diff.gz Description: GNU Zip compressed data ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] qemu vl.c vl.h
CVSROOT:/sources/qemu Module name:qemu Branch: Changes by: Fabrice Bellard <[EMAIL PROTECTED]> 06/04/12 20:21:17 Modified files: . : vl.c vl.h Log message: win32 serial port support (initial patch by kazu CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/qemu/vl.c.diff?tr1=1.168&tr2=1.169&r1=text&r2=text http://cvs.savannah.gnu.org/viewcvs/qemu/qemu/vl.h.diff?tr1=1.107&tr2=1.108&r1=text&r2=text ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] qemu/hw serial.c
CVSROOT:/sources/qemu Module name:qemu Branch: Changes by: Fabrice Bellard <[EMAIL PROTECTED]> 06/04/12 20:42:42 Modified files: hw : serial.c Log message: simulate a null modem cable CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/qemu/hw/serial.c.diff?tr1=1.11&tr2=1.12&r1=text&r2=text ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] qemu monitor.c
CVSROOT:/sources/qemu Module name:qemu Branch: Changes by: Fabrice Bellard <[EMAIL PROTECTED]> 06/04/12 21:07:07 Modified files: . : monitor.c Log message: 64 bit disassembly CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/qemu/monitor.c.diff?tr1=1.47&tr2=1.48&r1=text&r2=text ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] qemu hw/usb.h hw/ps2.c hw/usb-hid.c ./sdl.c ./v...
CVSROOT:/sources/qemu Module name:qemu Branch: Changes by: Fabrice Bellard <[EMAIL PROTECTED]> 06/04/12 21:09:08 Modified files: hw : usb.h ps2.c usb-hid.c . : sdl.c vl.c vl.h Log message: USB tablet support (Brad Campbell, Anthony Liguori) CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/qemu/hw/usb.h.diff?tr1=1.3&tr2=1.4&r1=text&r2=text http://cvs.savannah.gnu.org/viewcvs/qemu/qemu/hw/ps2.c.diff?tr1=1.3&tr2=1.4&r1=text&r2=text http://cvs.savannah.gnu.org/viewcvs/qemu/qemu/hw/usb-hid.c.diff?tr1=1.1&tr2=1.2&r1=text&r2=text http://cvs.savannah.gnu.org/viewcvs/qemu/qemu/sdl.c.diff?tr1=1.25&tr2=1.26&r1=text&r2=text http://cvs.savannah.gnu.org/viewcvs/qemu/qemu/vl.c.diff?tr1=1.169&tr2=1.170&r1=text&r2=text http://cvs.savannah.gnu.org/viewcvs/qemu/qemu/vl.h.diff?tr1=1.108&tr2=1.109&r1=text&r2=text ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] qemu Changelog
CVSROOT:/sources/qemu Module name:qemu Branch: Changes by: Fabrice Bellard <[EMAIL PROTECTED]> 06/04/12 21:09:31 Modified files: . : Changelog Log message: update CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/qemu/Changelog.diff?tr1=1.110&tr2=1.111&r1=text&r2=text ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] qemu/hw adb.c slavio_serial.c
CVSROOT:/sources/qemu Module name:qemu Branch: Changes by: Fabrice Bellard <[EMAIL PROTECTED]> 06/04/12 21:59:55 Modified files: hw : adb.c slavio_serial.c Log message: mouse API change CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/qemu/hw/adb.c.diff?tr1=1.5&tr2=1.6&r1=text&r2=text http://cvs.savannah.gnu.org/viewcvs/qemu/qemu/hw/slavio_serial.c.diff?tr1=1.5&tr2=1.6&r1=text&r2=text ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Emulation differences, qemu-system-x86_64 vs Athlon64
Julian Seward wrote: Recently I've been playing with CVS qemu-system (softmmu) on amd64 and had some stability problems. I decided to run Valgrind's amd64 instruction-set tests (derived from qemu's) to see if they picked up anything. Resulting diffs are attached. There are a bunch of differences for the C flag for rotates (rol/ror) by multiples of the word size. I don't think these are significant, but who knows. This is a bug in QEMU. From the manuals, the C flag must be updated even if the resulting shift is zero. I just modified the QEMU tests to catch this problem (it is not x86_64 specific). Perhaps more worryingly are the 20 or so lines at the bottom of the diff. These I believe are for double-to-int/short conversions for a value which is out of range for an int/short; the hardware produces 0x8000/0x8000 respectively, which is the "integer indefinite"; QEMU produces zero. I can imagine some obscure routine somewhere checking for integer indefinite after conversion and being confused as a result. I guess the problem comes from the usage of lrintl() on x86_64 in fpu/softfloat-native.c, but I cannot test it yet. Fabrice. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] [PATCH] -net user options for setting subnet and hostname
Currently the user-level networking (slirp) code in qemu uses subnet
10.0.2.0/24. Changing this hardcoded value, which can be desirable if
that subnet is already used for other purposes, requires recompiling
qemu.
The attached patch makes the subnet configurable on the command line
via a new "subnet" option to "-net user". The subnet must be specified
as "X.X.X.X/24".
This change also affected the handling of "-redir", since qemu uses
X.X.X.15 as the target address if the user does not specify one. Since
qemu parses command-line options immediately but defers acting on
"-net" options, net_slirp_redir() wouldn't know what subnet to use. It
seems that "-redir", "-smb" and "-tftp", which are all slirp-specific,
logically belong under "-net user" anyway, so I converted them into
"-net user" options. Doing so cleans up the code quite a bit, as slirp
gets initialized only by net_client_init().
Finally, the patch includes the "hostname" option to "-net user",
which I posted in a previous patch.
Comments and suggestions would be welcome.
--Ed
diff -BurN -x '*.orig' -x '*~' qemu-snapshot-2006-03-27_23.orig/slirp/bootp.c qemu-snapshot-2006-03-27_23/slirp/bootp.c
--- qemu-snapshot-2006-03-27_23.orig/slirp/bootp.c 2005-06-05 17:11:42.0 +
+++ qemu-snapshot-2006-03-27_23/slirp/bootp.c 2006-04-10 23:26:49.0 +
@@ -27,8 +27,6 @@
#define NB_ADDR 16
-#define START_ADDR 15
-
#define LEASE_TIME (24 * 3600)
typedef struct {
@@ -47,6 +45,8 @@
#define dprintf(fmt, args...)
#endif
+const char *dhcp_hostname;
+
static BOOTPClient *get_new_addr(struct in_addr *paddr)
{
BOOTPClient *bc;
@@ -60,7 +60,7 @@
found:
bc = &bootp_clients[i];
bc->allocated = 1;
-paddr->s_addr = htonl(ntohl(special_addr.s_addr) | (i + START_ADDR));
+paddr->s_addr = htonl(ntohl(special_addr.s_addr) | (i + DHCP_START_ADDR));
return bc;
}
@@ -77,7 +77,7 @@
found:
bc = &bootp_clients[i];
bc->allocated = 1;
-paddr->s_addr = htonl(ntohl(special_addr.s_addr) | (i + START_ADDR));
+paddr->s_addr = htonl(ntohl(special_addr.s_addr) | (i + DHCP_START_ADDR));
return bc;
}
@@ -228,6 +228,16 @@
val = htonl(LEASE_TIME);
memcpy(q, &val, 4);
q += 4;
+
+if (dhcp_hostname && *dhcp_hostname) {
+val = strlen(dhcp_hostname);
+if (val > 32)
+val = 32;
+*q++ = RFC1533_HOSTNAME;
+*q++ = val;
+memcpy(q, dhcp_hostname, val);
+q += val;
+}
}
*q++ = RFC1533_END;
diff -BurN -x '*.orig' -x '*~' qemu-snapshot-2006-03-27_23.orig/slirp/ctl.h qemu-snapshot-2006-03-27_23/slirp/ctl.h
--- qemu-snapshot-2006-03-27_23.orig/slirp/ctl.h 2004-04-22 00:10:47.0 +
+++ qemu-snapshot-2006-03-27_23/slirp/ctl.h 2006-04-10 23:26:49.0 +
@@ -2,6 +2,3 @@
#define CTL_EXEC 1
#define CTL_ALIAS 2
#define CTL_DNS 3
-
-#define CTL_SPECIAL "10.0.2.0"
-#define CTL_LOCAL "10.0.2.15"
diff -BurN -x '*.orig' -x '*~' qemu-snapshot-2006-03-27_23.orig/slirp/libslirp.h qemu-snapshot-2006-03-27_23/slirp/libslirp.h
--- qemu-snapshot-2006-03-27_23.orig/slirp/libslirp.h 2005-06-05 17:11:42.0 +
+++ qemu-snapshot-2006-03-27_23/slirp/libslirp.h 2006-04-10 23:26:49.0 +
@@ -13,7 +13,7 @@
extern "C" {
#endif
-void slirp_init(void);
+void slirp_init(struct in_addr subnet, char *dhcp_host, char *tftp_pfx);
void slirp_select_fill(int *pnfds,
fd_set *readfds, fd_set *writefds, fd_set *xfds);
@@ -31,8 +31,6 @@
int slirp_add_exec(int do_pty, const char *args, int addr_low_byte,
int guest_port);
-extern const char *tftp_prefix;
-
#ifdef __cplusplus
}
#endif
diff -BurN -x '*.orig' -x '*~' qemu-snapshot-2006-03-27_23.orig/slirp/slirp.c qemu-snapshot-2006-03-27_23/slirp/slirp.c
--- qemu-snapshot-2006-03-27_23.orig/slirp/slirp.c 2006-04-10 23:23:29.0 +
+++ qemu-snapshot-2006-03-27_23/slirp/slirp.c 2006-04-10 23:26:49.0 +
@@ -123,7 +123,7 @@
}
#endif
-void slirp_init(void)
+void slirp_init(struct in_addr subnet, char *dhcp_host, char *tftp_pfx)
{
//debug_init("/tmp/slirp.log", DEBUG_DEFAULT);
@@ -151,8 +151,13 @@
exit(1);
}
-inet_aton(CTL_SPECIAL, &special_addr);
+special_addr = subnet;
getouraddr();
+
+if (dhcp_host)
+dhcp_hostname = dhcp_host;
+if (tftp_pfx)
+tftp_prefix = tftp_pfx;
}
#define CONN_CANFSEND(so) (((so)->so_state & (SS_FCANTSENDMORE|SS_ISFCONNECTED)) == SS_ISFCONNECTED)
@@ -639,6 +644,8 @@
int slirp_redir(int is_udp, int host_port,
struct in_addr guest_addr, int guest_port)
{
+if (!guest_addr.s_addr)
+guest_addr.s_addr = htonl(ntohl(special_addr.s_addr) | DHCP_START_ADDR);
if (is_udp) {
if (!udp_listen(htons(host_port), guest_addr.s_addr,
htons(guest_port), 0))
diff -BurN -x '*.orig' -x '*~' qemu-snapshot-200
Re: [Qemu-devel] Emulation differences, qemu-system-x86_64 vs Athlon64
> I guess the problem comes from the usage of lrintl() on x86_64 in > fpu/softfloat-native.c, but I cannot test it yet. It might be that you have to pass in an extra value into those float -> int conversion routines, which describes what to do if the conversion is going to overflow. That's because the behaviour is different depending on the guest architecture. x86/amd64 always give 0x8000, whereas ppc gives either 0x8000... or 0x7FFF depending on the sign of the argument (IIRC). J ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] Custom floppy image not booting, hanging at ramdisk...
Heya guys, I am trying to create my own uclibc/busybox floppy bootdisk, and am running into an issue with the expansion of the RAMDISK... the CPU shoots up to 100% and even leaving it overnight, it never recovers from that situation. I have tried it under qemu 0.7.2 and 0.8.0 in linux and windows, and all fail to boot the image, where as vmware (and/or native) boot the disk fine, and goes correctly to the "Please press Enter to activate this console". I am using the command line: qemu -fda floppy.img -boot a And it loads up the kernel, no problem, reaching the ramdisk stage, and then it dies at the following: RAMDISK: Compressed image found at block 680 If anyone wants a crack at this, the image can be found at http://tusker.sg/floppy.img How would I go about debugging this issue? Cheers in advance, Damien ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
