[Qemu-devel] QEMU x86_64: sles 64, bug with floats (with test program) (3rd try)
Hi !
I've found a bug in Qemu x86_64 under a sles 64 10: conversion of floats
to strings fails in some cases. For example, Ganglia (cluster monitoring
software), shows random values and as well as PHP5 programs.
Here is a simple test program to confirm that you have the same bug as me
(maybe also under another distribution). Compile this and link with libapr-1:
==test.c===
#include stdio.h
#include math.h
#include apr.h
#include apr_strings.h
void main(void)
{
char buf[60];
double d = M_PI;
snprintf(buf, 60, %f\n, d);
printf(buf);
apr_snprintf(buf, 60, %f\n, d);
printf(buf);
}
Under a SLES 10/64 bits, you'll see something like:
3.141593
3.Ojuç_
I tested with Qemu 0.8.2 and the CVS, but of course, it works on a real
system (a Dell PE1950).
So it's a QEMU bug. Is it triggered by weird code produced by gcc 4.1.0 ? Or a
FPU emulation bug ? Any ideas ?
--
Ludovic DROLEZ Linbox / FreeALter Soft
http://lrs.linbox.org
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] Support for vga= kernel option
Hello,
here is a little patch to add support for vga= when using -kernel.
Index: hw/pc.c
===
RCS file: /sources/qemu/qemu/hw/pc.c,v
retrieving revision 1.68
diff -u -r1.68 pc.c
--- hw/pc.c 10 Jan 2007 16:23:41 - 1.68
+++ hw/pc.c 11 Jan 2007 13:10:55 -
@@ -544,6 +544,7 @@
if (linux_boot) {
uint8_t bootsect[512];
uint8_t old_bootsect[512];
+char *vmode;
if (bs_table[0] == NULL) {
fprintf(stderr, A disk image must be given for 'hda' when booting a Linux kernel\n);
@@ -595,6 +596,25 @@
KERNEL_CMDLINE_ADDR - KERNEL_PARAMS_ADDR);
/* loader type */
stw_raw(phys_ram_base + KERNEL_PARAMS_ADDR + 0x210, 0x01);
+
+/* handle vga= parameter */
+vmode = strstr(kernel_cmdline, vga=);
+if (vmode) {
+char *space;
+unsigned int video_mode;
+/* skip vga= */
+vmode += 4;
+if (!strncmp(vmode, normal, 6)) {
+video_mode = 0x;
+} else if (!strncmp(vmode, ext, 3)) {
+video_mode = 0xfffe;
+} else if (!strncmp(vmode, ask, 3)) {
+video_mode = 0xfffd;
+} else {
+video_mode = strtol(vmode, NULL, 0);
+}
+stw_raw(phys_ram_base + KERNEL_PARAMS_ADDR + 0x1fa, video_mode);
+}
}
if (pci_enabled) {
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] [PATCH] better handling of removal in IOHandlerRecord list
On Thu, 2007-01-11 at 14:56 +0100, jerome Arbez-Gindre wrote:
On Wed, 2007-01-10 at 17:34 +0100, jerome Arbez-Gindre wrote:
Hi,
by a call to qemu_set_fd_handler(fd,NULL,NULL,NULL) in the fd_read
callback, I have generated a Segmentation fault in vl.c.
My solution is not very smart... but it is very simple.
I reply to myself because I did not sleep last night:
Here is the fix without the double IOHandlerRecord list iteration.
Here is a little fix to handle the case when a IOHandler removes an
other IOHandler.
--- vl.c.mine 2007-01-11 15:06:47.0 +0100
+++ vl.c2007-01-11 15:27:27.0 +0100
@@ -5912,11 +5912,13 @@
pioh = first_io_handler ;
for(ioh = first_io_handler; ioh != NULL; ioh = ioh_next) {
ioh_next = ioh-next;
-if (FD_ISSET(ioh-fd, rfds)) {
+/* ioh-fd_read could have been set to null by an other
+ IOHandlerRecord callback */
+if (ioh-fd_read FD_ISSET(ioh-fd, rfds)) {
ioh-fd_read(ioh-opaque);
}
/* ioh-fd_write could have been set to null */
-if ((ioh-fd_write) (FD_ISSET(ioh-fd, wfds))) {
+if (ioh-fd_write FD_ISSET(ioh-fd, wfds)) {
ioh-fd_write(ioh-opaque);
}
/* the ioh could have been supressed */
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] Re: problem with 64/64 guest running grub (also 32/64)
Werner Dittmann Werner.Dittmann at t-online.de writes: Same happen to Suse 64 host/64 guest system (Suse 10.1). A 32-bit guest system install quite well. I've also got the problem on a Debian 32 host/64 guest. But installing lilo works. Cheers, Ludovic. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] Re: weird slirp problems (dns lookups stopped working, and maybe more)
On Wed, Jan 10, 2007 at 12:04:03AM +0100, Juergen Lock wrote: ... Ok, garrison on irc just helped solve this mystery: This (the same) one actually goes out first, before the 10.0.2.3 one (I didn't notice at first), and since slirp reuses the socket because the source ip and port hasnt changed (slirp/udp.c lines 172 and up, it doesn't check the dest ip), the second packet with the 10.0.2.3 dest ip (which gets replaced with the hosts's dns) goes out wrong. And the reason this worked previously with the same guest is multicast started working only recently... And here's the fix I just added to the FreeBSD qemu port: (thanx garrison!) Index: qemu/slirp/udp.c @@ -205,8 +208,6 @@ /* udp_last_so = so; */ so-so_laddr = ip-ip_src; so-so_lport = uh-uh_sport; - so-so_faddr = ip-ip_dst; /* XXX */ - so-so_fport = uh-uh_dport; /* XXX */ if ((so-so_iptos = udp_tos(so)) == 0) so-so_iptos = ip-ip_tos; @@ -216,6 +217,15 @@ * and if it is, do the fork_exec() etc. */ } + + /* +* Assign destination unconditionally +* +* This fixes the case where packets are sent from the same +* source ip/port to different destination ips/ports +*/ + so-so_faddr = ip-ip_dst; /* XXX */ + so-so_fport = uh-uh_dport; /* XXX */ iphlen += sizeof(struct udphdr); m-m_len -= iphlen; ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Re: weird slirp problems (dns lookups stopped working, and maybe more) [PATCH]
I posted a similar patch last year, but it was not accepted for some
reason. Making this change allows UDP nfs to work to a remote file
server as well.
I would recommend, making one further change as included in this patch.
It allows KGDBOE to operate on the local host or from a remote host
because it allow the special 10.0.2.2 address to be translated.
I have included the patch in the e-mail once again.
signed-off-by: [EMAIL PROTECTED]
Jason.
Juergen Lock wrote:
On Wed, Jan 10, 2007 at 12:04:03AM +0100, Juergen Lock wrote:
...
Ok, garrison on irc just helped solve this mystery: This (the same)
one actually goes out first, before the 10.0.2.3 one (I didn't notice
at first), and since slirp reuses the socket because the source ip and
port hasnt changed (slirp/udp.c lines 172 and up, it doesn't check the
dest ip), the second packet with the 10.0.2.3 dest ip (which gets
replaced with the hosts's dns) goes out wrong. And the reason this
worked previously with the same guest is multicast started working
only recently...
And here's the fix I just added to the FreeBSD qemu port: (thanx garrison!)
Index: qemu/slirp/udp.c
@@ -205,8 +208,6 @@
/* udp_last_so = so; */
so-so_laddr = ip-ip_src;
so-so_lport = uh-uh_sport;
- so-so_faddr = ip-ip_dst; /* XXX */
- so-so_fport = uh-uh_dport; /* XXX */
if ((so-so_iptos = udp_tos(so)) == 0)
so-so_iptos = ip-ip_tos;
@@ -216,6 +217,15 @@
* and if it is, do the fork_exec() etc.
*/
}
+
+ /*
+* Assign destination unconditionally
+*
+* This fixes the case where packets are sent from the same
+* source ip/port to different destination ips/ports
+*/
+ so-so_faddr = ip-ip_dst; /* XXX */
+ so-so_fport = uh-uh_dport; /* XXX */
iphlen += sizeof(struct udphdr);
m-m_len -= iphlen;
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
Index: qemu/slirp/udp.c
===
--- qemu.orig/slirp/udp.c
+++ qemu/slirp/udp.c
@@ -205,8 +205,6 @@ udp_input(m, iphlen)
/* udp_last_so = so; */
so-so_laddr = ip-ip_src;
so-so_lport = uh-uh_sport;
- so-so_faddr = ip-ip_dst; /* XXX */
- so-so_fport = uh-uh_dport; /* XXX */
if ((so-so_iptos = udp_tos(so)) == 0)
so-so_iptos = ip-ip_tos;
@@ -216,6 +214,13 @@ udp_input(m, iphlen)
* and if it is, do the fork_exec() etc.
*/
}
+ /* Always reset the from address as it can change,
+* as with NFS for example where it will talk to
+* the same destination port with multiple source
+* addresses. Or different gdb session to kgdboe.
+*/
+ so-so_faddr = ip-ip_dst; /* XXX */
+ so-so_fport = uh-uh_dport; /* XXX */
iphlen += sizeof(struct udphdr);
m-m_len -= iphlen;
@@ -312,7 +317,8 @@ int udp_output(struct socket *so, struct
struct sockaddr_in saddr, daddr;
saddr = *addr;
-if ((so-so_faddr.s_addr htonl(0xff00)) == special_addr.s_addr) {
+if ((so-so_faddr.s_addr htonl(0xff00)) == special_addr.s_addr
+addr-sin_addr.s_addr == htonl(0x7f01)) {
saddr.sin_addr.s_addr = so-so_faddr.s_addr;
if ((so-so_faddr.s_addr htonl(0x00ff)) == htonl(0xff))
saddr.sin_addr.s_addr = alias_addr.s_addr;
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Preliminary Malta platform support
On Thu, Jan 11, 2007 at 08:55:28PM +0100, Stefan Weil wrote: Hello Aurelien, Hi! merci pour l'emulation de MIPS malta. C'est très jolie. I added the MIPS display device which I already published in an earlier mail, so now Thiemo can see LINUX ON MALTA scrolling. Maybe the colors need some tuning (is green on black correct?). My console patch (published on the list some minutes ago) is also needed for correct display. The display was tested with the Malta patches and MIPS kernel http://temp.aurel32.net/vmlinux-2.6.18.5-mipsel like this: ./mipsel-softmmu/qemu-system-mipsel -M malta -kernel vmlinux-2.6.18.5-mipsel Alt-Ctrl-4 or Alt-Ctrl-5 should show the Malta ASCII display. Thanks for your work. I have just tested it, it works well. I will include it in the next version of my patches. I would be nice if your console patch could be merged meanwhile. About the color I don't know as I don't own such a board. I guess Thiemo knows the answer. Tschüss, AUrelien -- .''`. Aurelien Jarno | GPG: 1024D/F1BCDB73 : :' : Debian developer | Electrical Engineer `. `' [EMAIL PROTECTED] | [EMAIL PROTECTED] `-people.debian.org/~aurel32 | www.aurel32.net ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] [PATCH] darwin-user merge attempt
Hi, Here is an attempt to merge the qemu tree hosted in darwine CVS repository [1]. This branch contains a darwin-user target for qemu, which goal is similar to linux-user on linux. For now there is still much to do, like: 1- fill the ioctls*.h files 2- Accurately implement all the syscall. 3- have all the user access protected by lock_user/unlock_user and g2h/h2g macro. 4- Fix the bugs that prevent Cocoa apps from running i386-darwin-user on ppc But darwin-user is starting to become functionnal: - i386-darwin-user on x86: (Some) cocoa apps run fines. - i386-darwin-user on ppc: (Some) command line utility work fines, but we may have some bugs left that prevent Cocoa applications from working. - ppc-darwin-user on ppc: commpage issues can prevent qemu from running, hopefully todo#3 could fix that. - ppc-darwin-user on x86: ppc and x86 commpage overlap, so the ppc commpage can't be mapped, hopefully todo#3 could fix that too. I hope to ear some feedback about inclusion in the qemu TOT. Pierre. (Note that Matt Reda used to work on that too.) [1] http://darwine.cvs.sourceforge.net/darwine/qemu/ darwin_user.1.diff.txt.bz2 Description: Binary data ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
