Re: [Qemu-devel] [PATCH] cpu-exec(): also reload CPUClass *cc after longjmp return
On Fri, Oct 04, 2013 at 09:15:37AM +0200, Jan Kiszka wrote: On 2013-10-03 18:05, Peter Maydell wrote: On 3 October 2013 23:09, Juergen Lock qem...@jelal.kn-bremen.de wrote: Local variable CPUClass *cc needs to be reloaded after return from longjmp too. (This fixes the mips-softmmu crash observed on FreeBSD when qemu is built with clang.) Signed-off-by: Juergen Lock n...@jelal.kn-bremen.de Found-by: Dimitry Andric d...@freebsd.org --- a/cpu-exec.c +++ b/cpu-exec.c @@ -681,6 +681,10 @@ int cpu_exec(CPUArchState *env) * local variables as longjmp is marked 'noreturn'. */ cpu = current_cpu; env = cpu-env_ptr; +#if !(defined(CONFIG_USER_ONLY) \ + (defined(TARGET_M68K) || defined(TARGET_PPC) || defined(TARGET_S390X))) +cc = CPU_GET_CLASS(cpu); +#endif This is a c compiler or libc bug -- the C standard says that this local variable should not be trashed by the longjmp. We were actually discussing removing the current workarounds there... But we didn't decide if we should stop supporting the affected compiler versions. Does this issue also exist with the latest clang version available for your platform? It happens with up to date clang as it's in FreeBSD 10.0-current which is due for a release soon. I think the clang folks are looking into this issue but I don't know if a fix will make it into the release... (For now I've added the workaround to the FreeBSD qemu-devel port.) Thanx, Juergen
Re: [Qemu-devel] [PATCH] cpu-exec(): also reload CPUClass *cc after longjmp return
On Sat, Oct 05, 2013 at 08:06:22PM +0200, Stefan Weil wrote: Am 05.10.2013 19:54, schrieb Juergen Lock: On Fri, Oct 04, 2013 at 09:15:37AM +0200, Jan Kiszka wrote: On 2013-10-03 18:05, Peter Maydell wrote: On 3 October 2013 23:09, Juergen Lock qem...@jelal.kn-bremen.de wrote: Local variable CPUClass *cc needs to be reloaded after return from longjmp too. (This fixes the mips-softmmu crash observed on FreeBSD when qemu is built with clang.) Signed-off-by: Juergen Lock n...@jelal.kn-bremen.de Found-by: Dimitry Andric d...@freebsd.org --- a/cpu-exec.c +++ b/cpu-exec.c @@ -681,6 +681,10 @@ int cpu_exec(CPUArchState *env) * local variables as longjmp is marked 'noreturn'. */ cpu = current_cpu; env = cpu-env_ptr; +#if !(defined(CONFIG_USER_ONLY) \ + (defined(TARGET_M68K) || defined(TARGET_PPC) || defined(TARGET_S390X))) +cc = CPU_GET_CLASS(cpu); +#endif This is a c compiler or libc bug -- the C standard says that this local variable should not be trashed by the longjmp. We were actually discussing removing the current workarounds there... But we didn't decide if we should stop supporting the affected compiler versions. Does this issue also exist with the latest clang version available for your platform? It happens with up to date clang as it's in FreeBSD 10.0-current which is due for a release soon. I think the clang folks are looking into this issue but I don't know if a fix will make it into the release... (For now I've added the workaround to the FreeBSD qemu-devel port.) Thanx, Juergen Could you try whether QEMU crashes when it was configured with TCG interpreter (--enable-tcg-interpreter)? If it does not crash, it might be that TCG does not save / restore enough registers. Still crashes the same. Which register is used for the local variable 'cc'? Here is the original debug log with part of the disassembly: http://people.freebsd.org/~nox/tmp/qemu-1.6.0-mips-softmmu-crash.txt (I wrote the comment at the top before I knew cc needs to be reloaded...) So apparently cc gets loaded from the stack before the crash: -0x40(%rbp) Thanx, Juergen
[Qemu-devel] [PATCH] cpu-exec(): also reload CPUClass *cc after longjmp return
Local variable CPUClass *cc needs to be reloaded after return from longjmp too. (This fixes the mips-softmmu crash observed on FreeBSD when qemu is built with clang.) Signed-off-by: Juergen Lock n...@jelal.kn-bremen.de Found-by: Dimitry Andric d...@freebsd.org --- a/cpu-exec.c +++ b/cpu-exec.c @@ -681,6 +681,10 @@ int cpu_exec(CPUArchState *env) * local variables as longjmp is marked 'noreturn'. */ cpu = current_cpu; env = cpu-env_ptr; +#if !(defined(CONFIG_USER_ONLY) \ + (defined(TARGET_M68K) || defined(TARGET_PPC) || defined(TARGET_S390X))) +cc = CPU_GET_CLASS(cpu); +#endif } } /* for(;;) */
Re: [Qemu-devel] 1.4.1 won't build with --enable-debug-tcg (or --enable-debug)
On Sat, May 04, 2013 at 03:23:28PM +0100, Richard Sandiford wrote:
Juergen Lock n...@jelal.kn-bremen.de writes:
Hi!
The failure is in the mips64-softmmu target: (at least)
[...]
CCmips64-softmmu/target-mips/translate.o
..qemu-1.4.1/target-mips/translate.c::2780:35 : error:
passing 'int' to parameter of incompatible type 'TCGv_i32'
gen_helper_dmult(cpu_env, acc, t0, t1);
^~~
[...]
Looks like this line came in with this patch by Aurelien Jarno: (Cc'd)
http://patchwork.ozlabs.org/patch/234926/
Ouch. I can see what Michael means about scary conflicts. The code
in the 1.4 branch looks different from both the code at the time the
patch was submitted and the code at the time the patch was applied.
Here's one fix, but maybe Aurelien has a better idea.
Thanx, I just updated the FreeBSD port to 1.4.1 and included this fix.
Juergen
Richard
From 61b79e34bc57df0aa0c8086bd86f4c8818618d0e Mon Sep 17 00:00:00 2001
From: Richard Sandiford rdsandif...@googlemail.com
Date: Sat, 4 May 2013 15:01:31 +0100
Subject: [PATCH] target-mips: Fix accumulator arguments to gen_helper_dmult(u)
gen_muldiv was passing int accumulator arguments directly
to gen_helper_dmult(u). This patch fixes it to use TCGs,
via the gen_helper_0e2i wrapper.
Fixes an --enable-debug-tcg build failure reported by Juergen Lock.
Signed-off-by: Richard Sandiford rdsandif...@googlemail.com
---
target-mips/helper.h| 4 ++--
target-mips/op_helper.c | 8
target-mips/translate.c | 4 ++--
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/target-mips/helper.h b/target-mips/helper.h
index cfe98f1..7aa5f79 100644
--- a/target-mips/helper.h
+++ b/target-mips/helper.h
@@ -24,8 +24,8 @@ DEF_HELPER_FLAGS_1(clz, TCG_CALL_NO_RWG_SE, tl, tl)
#ifdef TARGET_MIPS64
DEF_HELPER_FLAGS_1(dclo, TCG_CALL_NO_RWG_SE, tl, tl)
DEF_HELPER_FLAGS_1(dclz, TCG_CALL_NO_RWG_SE, tl, tl)
-DEF_HELPER_4(dmult, void, env, int, tl, tl)
-DEF_HELPER_4(dmultu, void, env, int, tl, tl)
+DEF_HELPER_4(dmult, void, env, tl, tl, int)
+DEF_HELPER_4(dmultu, void, env, tl, tl, int)
#endif
DEF_HELPER_3(muls, tl, env, tl, tl)
diff --git a/target-mips/op_helper.c b/target-mips/op_helper.c
index c054300..01df687 100644
--- a/target-mips/op_helper.c
+++ b/target-mips/op_helper.c
@@ -268,14 +268,14 @@ target_ulong helper_mulshiu(CPUMIPSState *env,
target_ulong arg1,
}
#ifdef TARGET_MIPS64
-void helper_dmult(CPUMIPSState *env, int acc, target_ulong arg1,
- target_ulong arg2)
+void helper_dmult(CPUMIPSState *env, target_ulong arg1,
+ target_ulong arg2, int acc)
{
muls64((env-active_tc.LO[acc]), (env-active_tc.HI[acc]), arg1, arg2);
}
-void helper_dmultu(CPUMIPSState *env, int acc, target_ulong arg1,
- target_ulong arg2)
+void helper_dmultu(CPUMIPSState *env, target_ulong arg1,
+ target_ulong arg2, int acc)
{
mulu64((env-active_tc.LO[acc]), (env-active_tc.HI[acc]), arg1, arg2);
}
diff --git a/target-mips/translate.c b/target-mips/translate.c
index 9ed6477..8205456 100644
--- a/target-mips/translate.c
+++ b/target-mips/translate.c
@@ -2777,11 +2777,11 @@ static void gen_muldiv(DisasContext *ctx, uint32_t
opc,
opn = ddivu;
break;
case OPC_DMULT:
-gen_helper_dmult(cpu_env, acc, t0, t1);
+gen_helper_0e2i(dmult, t0, t1, acc);
opn = dmult;
break;
case OPC_DMULTU:
-gen_helper_dmultu(cpu_env, acc, t0, t1);
+gen_helper_0e2i(dmultu, t0, t1, acc);
opn = dmultu;
break;
#endif
--
1.8.1.4
[Qemu-devel] 1.4.1 won't build with --enable-debug-tcg (or --enable-debug)
Hi! The failure is in the mips64-softmmu target: (at least) [...] CCmips64-softmmu/target-mips/translate.o ..qemu-1.4.1/target-mips/translate.c::2780:35 : error: passing 'int' to parameter of incompatible type 'TCGv_i32' gen_helper_dmult(cpu_env, acc, t0, t1); ^~~ [...] Looks like this line came in with this patch by Aurelien Jarno: (Cc'd) http://patchwork.ozlabs.org/patch/234926/ Now I wonder is the failure just cosmetic or is the mips emulation actually broken in 1.4.1? More so than in 1.4.0? I guess not but with all the #defines that code is kinda hard to follow... :) Thanx! Juergen
[Qemu-devel] tcg/i386: Workaround for clang not defining bit_CMOV
This fixes the build with clang on 32 bit x86. Signed-off-by: Juergen Lock n...@jelal.kn-bremen.de --- a/tcg/i386/tcg-target.c +++ b/tcg/i386/tcg-target.c @@ -104,6 +104,10 @@ static const int tcg_target_call_oarg_re # define have_cmov 1 #elif defined(CONFIG_CPUID_H) #include cpuid.h +#ifndef bit_CMOV +/* clang's cpuid.h doesn't define bit_* */ +#define bit_CMOV (1 15) +#endif static bool have_cmov; #else # define have_cmov 0
[Qemu-devel] [PATCH] tcg/i386: Workaround for clang not defining bit_CMOV
I guess I should have put [PATCH] in the Subject, sorry. On Fri, Apr 26, 2013 at 09:11:41PM +0200, Juergen Lock wrote: This fixes the build with clang on 32 bit x86. Signed-off-by: Juergen Lock n...@jelal.kn-bremen.de --- a/tcg/i386/tcg-target.c +++ b/tcg/i386/tcg-target.c @@ -104,6 +104,10 @@ static const int tcg_target_call_oarg_re # define have_cmov 1 #elif defined(CONFIG_CPUID_H) #include cpuid.h +#ifndef bit_CMOV +/* clang's cpuid.h doesn't define bit_* */ +#define bit_CMOV (1 15) +#endif static bool have_cmov; #else # define have_cmov 0
Re: [Qemu-devel] [ANNOUNCE] QEMU 1.0 release
In article 1323105616.14716.23.camel@Nokia-N900 you write: - Original message - On 12/05/2011 09:06 AM, Alex Jia wrote: Hi Anthony, It seems the following link is unavailable now: http://wiki.qemu.org/download/qemu-1.0.tar.gz The VM is crashing pretty often. We're working on a migration plan that will resolve this problem. I'll post dates once I can confirm them. The link should be working again by the time you get this message. Regards, Anthony Liguori Could the QEMU distfiles be officially mirrored somewhere else like it used to be? I maintain the FreeBSD qemu port(s) and just got reports of this problem too (unable to fetch the source tarball), so I pushed it out to the FreeBSD.org MASTER_SITE_LOCAL mirrrors i.e. it should soon be available on several mirrors like: http://ftp.FreeBSD.org/pub/FreeBSD/ports/local-distfiles/nox/qemu-1.0.tar.gz ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/local-distfiles/nox/qemu-1.0.tar.gz ftp://ftp.country.FreeBSD.org/pub/FreeBSD/ports/local-distfiles/nox/qemu-1.0.tar.gz ftp://ftp.countrynumber.FreeBSD.org/pub/FreeBSD/ports/local-distfiles/nox/qemu-1.0.tar.gz http://ftp.country.FreeBSD.org/pub/FreeBSD/ports/local-distfiles/nox/qemu-1.0.tar.gz http://ftp.countrynumber.FreeBSD.org/pub/FreeBSD/ports/local-distfiles/nox/qemu-1.0.tar.gz (the first two links already work at the time of writing.) HTH, :) Juergen
Re: [Qemu-devel] qemu 0.15.0 testing, usb redirection, and libusb_get_device_speed()
On Tue, Aug 16, 2011 at 09:37:39AM +0200, Hans Petter Selasky wrote: On Monday 15 August 2011 22:26:56 Juergen Lock wrote: Hi! I just prepared a preliminary update of the emulators/qemu-devel port to 0.15.0 [1], and among other things it now also has a usb network redirection feature using usbredir [2], which uses libusb 1.0 and a function that is missing in our version, libusb_get_device_speed(). I added a stub to the code that always returns LIBUSB_SPEED_UNKNOWN (files/patch-usbredirhost-usbredirhost.c in the usbredir port [2]), question for Hans (I guess), would there be an easy way to make a `proper' implementation? If anyone wants to help me test qemu 0.15.0, thanx! Please try the attached patch to libusb in /usr/src/lib/libusb . You only need to rebuild libusb: make all install clean FETCHENTRY: entry at 22C5484 is of type 2 which is not supported yet processing error - resetting ehci HC Try my patch first. EHCI needs to know device speed. Thanx, tho it turns out: a) the FETCHENTRY:.. crash also happens without any device redirection with FreeBSD 8.2 (at least) guests and ehci enabled (-readconfig docs/ich9-ehci-uhci.cfg), and b) if I test this with your patch (working libusb_get_device_speed() that doesn't just always return LIBUSB_SPEED_UNKNOWN) and redirecting an usb 2.0 device with ehci enabled using usbredir then qemu complains like: qemu: Warning: speed mismatch trying to attach usb device USB Redirectio n Device to bus usb.0 and ignores the redirected device. So for now I have added a #define IGNORE_LIBUSB_GET_DEVICE_SPEED to the (updated) preliminary usbredir FreeBSD port, http://people.freebsd.org/~nox/qemu/usbredir.shar so that usbredirhost_open() now always works with: device_connect.speed = usb_redir_speed_unknown; Question: do people also see this problem on Linux? This post has an usage example: http://thread.gmane.org/gmane.comp.emulators.qemu/110176/focus=110183 Or is the problem just that with the example usage, sudo usbredirserver 045e:0772 ... qemu ... \ -readconfig docs/ich9-ehci-uhci.cfg \ -chardev socket,id=usbredirchardev,host=localhost,port=4000 \ -device usb-redir,chardev=usbredirchardev,id=usbredirdev qemu 0.15.0 tries to attach the redirected usb 2.0 device to the uhci bus instead of to the ehci one and if yes, how can I fix that? Thanx! :) Juergen
Re: [Qemu-devel] qemu 0.15.0 testing, usb redirection, and libusb_get_device_speed()
On Tue, Aug 16, 2011 at 09:54:23PM +0200, Juergen Lock wrote: On Tue, Aug 16, 2011 at 09:37:39AM +0200, Hans Petter Selasky wrote: On Monday 15 August 2011 22:26:56 Juergen Lock wrote: Hi! I just prepared a preliminary update of the emulators/qemu-devel port to 0.15.0 [1], and among other things it now also has a usb network redirection feature using usbredir [2], which uses libusb 1.0 and a function that is missing in our version, libusb_get_device_speed(). I added a stub to the code that always returns LIBUSB_SPEED_UNKNOWN (files/patch-usbredirhost-usbredirhost.c in the usbredir port [2]), question for Hans (I guess), would there be an easy way to make a `proper' implementation? If anyone wants to help me test qemu 0.15.0, thanx! Please try the attached patch to libusb in /usr/src/lib/libusb . You only need to rebuild libusb: make all install clean FETCHENTRY: entry at 22C5484 is of type 2 which is not supported yet processing error - resetting ehci HC Try my patch first. EHCI needs to know device speed. Thanx, tho it turns out: a) the FETCHENTRY:.. crash also happens without any device redirection with FreeBSD 8.2 (at least) guests and ehci enabled (-readconfig docs/ich9-ehci-uhci.cfg), and b) if I test this with your patch (working libusb_get_device_speed() that doesn't just always return LIBUSB_SPEED_UNKNOWN) and redirecting an usb 2.0 device with ehci enabled using usbredir then qemu complains like: qemu: Warning: speed mismatch trying to attach usb device USB Redirectio n Device to bus usb.0 and ignores the redirected device. So for now I have added a #define IGNORE_LIBUSB_GET_DEVICE_SPEED to the (updated) preliminary usbredir FreeBSD port, http://people.freebsd.org/~nox/qemu/usbredir.shar so that usbredirhost_open() now always works with: device_connect.speed = usb_redir_speed_unknown; Question: do people also see this problem on Linux? This post has an usage example: http://thread.gmane.org/gmane.comp.emulators.qemu/110176/focus=110183 Or is the problem just that with the example usage, sudo usbredirserver 045e:0772 ... qemu ... \ -readconfig docs/ich9-ehci-uhci.cfg \ -chardev socket,id=usbredirchardev,host=localhost,port=4000 \ -device usb-redir,chardev=usbredirchardev,id=usbredirdev qemu 0.15.0 tries to attach the redirected usb 2.0 device to the uhci bus instead of to the ehci one and if yes, how can I fix that? Nevermind, I didn't actually put the -readconfig parameter first. :( (It didn't occur to me that the order would matter...) But now I found that: a) seabios hangs at boot when I redirect an usb 2.0 flashkey with ehci enabled (at least with -cdrom), and b) with ehci disabled I still get the speed mismatch warning and the device is ignored. Maybe the speed mismatch check should be relaxed if there isn't a bus as fast as the device, and the device be attached to the fastest available bus instead? (i.e. also the same is likely to happen with usb 3.0 devices?) Thanx, Juergen (who will leave the FreeBSD usbredir port using usb_redir_speed_unknown for now I guess...)
[Qemu-devel] qemu 0.15.0 testing, usb redirection, and libusb_get_device_speed()
Hi! I just prepared a preliminary update of the emulators/qemu-devel port to 0.15.0 [1], and among other things it now also has a usb network redirection feature using usbredir [2], which uses libusb 1.0 and a function that is missing in our version, libusb_get_device_speed(). I added a stub to the code that always returns LIBUSB_SPEED_UNKNOWN (files/patch-usbredirhost-usbredirhost.c in the usbredir port [2]), question for Hans (I guess), would there be an easy way to make a `proper' implementation? If anyone wants to help me test qemu 0.15.0, thanx! I also updated the net.c and net.h udp patches for gns3 for this qemu version: (the other gns3 patchfiles for qemu 0.14 still apply) http://people.freebsd.org/~nox/qemu/qemu-0.15.0-gns3-patches/ I added this note to the qemu-devel pkg-message about the usb redirection [1]: snip-- - If you want to test the new (in 0.15.0) usb network redirection (USBREDIR option) see this thread by Hans de Goede hdegoede at redhat.com: http://thread.gmane.org/gmane.comp.emulators.qemu/110176/focus=110183 Quote: Example usage: 1) Start usbredirserver for a usb device: sudo usbredirserver 045e:0772 2) Start qemu with usb2 support + a chardev talking to usbredirserver + a usb-redir device using this chardev: qemu ... \ -readconfig docs/ich9-ehci-uhci.cfg \ -chardev socket,id=usbredirchardev,host=localhost,port=4000 \ -device usb-redir,chardev=usbredirchardev,id=usbredirdev [you would replace docs/ich9-ehci-uhci.cfg with e.g. /usr/local/share/doc/qemu/docs/ich9-ehci-uhci.cfg, but turns out ehci seems broken for me here with FreeBSD guests at least, I get: FETCHENTRY: entry at 22C5484 is of type 2 which is not supported yet processing error - resetting ehci HC Assertion failed: (0), function ehci_advance_state, file /data/ports/emulators/qemu-devel/work/qemu-0.15.0/hw/usb-ehci.c, line 2045. Starting the same without ehci (-readconfig) works, tho usbredirserver crashes when qemu exits.] snip-- Thanx! :) Juergen [1] Changelog: http://wiki.qemu.org/ChangeLog/0.15 Preliminary port: http://people.freebsd.org/~nox/qemu/qemu-devel-0.15.0.shar Patch against current qemu-devel port: http://people.freebsd.org/~nox/qemu/qemu-devel-0.15.0.patch [2] usbredir 0.3: http://cgit.freedesktop.org/~jwrdegoede/usbredir/ Preliminary port: http://people.freebsd.org/~nox/qemu/usbredir.shar
Re: [Qemu-devel] qemu FreeBSD/sparc64 host - a bit of debugging
On Mon, Jul 18, 2011 at 10:58:58PM -0400, Super Bisquit wrote: On Mon, Jul 18, 2011 at 2:22 PM, Juergen Lock n...@jelal.kn-bremen.dewrote: Hi! I'm the FreeBSD qemu port maintainer and don't have a sparc64 box myself, but Jashank Jeremy (Cc'd) now was so kind to test qemu 0.14.1 on a FreeBSD/sparc64 box booting a FreeBSD 8/i386 install iso using i386-softmmu What's the difference- an honest question- between this and a normal qemu boot? Depends on what you mean by normal qemu boot... If you are wondering about the i386-softmmu, that's just the name of the 32bit x86 system emulation target, the executable is called qemu. So he ran something like: qemu -cdrom FreeBSD-8.2-i386-bootonly.iso -vnc ... and we found two things: 1. The hang people have been reporting seems to be caused by this tb: IN: 0x000e7a31: in $0xb3,%al 0x000e7a33: test %al,%al 0x000e7a35: jne0xe7a31 i.e. it (the qemu bios I suppose) is waiting for x86 ioport 0xb3 to become zero. This port is #defined in hw/apm.c as: qemu-0.14.1/hw/apm.c:#define APM_STS_IOPORT 0xb3 but the definition seems to be used nowhere in that source file. Anyone have an idea why this port is never zero on sparc64 hosts but seems to be on others? (endian issue? uninitialized variable?) Have you asked Whitehorn what it my be? No but I can Cc him... Actually I can Cc the freebsd-sparc64 list too. 2. Booting the same guest with -no-acpi gets further, bios and bootloader messages are printed until it hangs again, this time while handling a guest irq 8 which seems to be rtc. Is there a way of disabling the clock? If not, then would it be useful to set the emulated cpu speed? I don't think any of these two are possible. Maybe this is useful to some... :) Actually, it's quite useful to me. That's good to hear. :) Juergen
[Qemu-devel] qemu FreeBSD/sparc64 host - a bit of debugging
Hi! I'm the FreeBSD qemu port maintainer and don't have a sparc64 box myself, but Jashank Jeremy (Cc'd) now was so kind to test qemu 0.14.1 on a FreeBSD/sparc64 box booting a FreeBSD 8/i386 install iso using i386-softmmu and we found two things: 1. The hang people have been reporting seems to be caused by this tb: IN: 0x000e7a31: in $0xb3,%al 0x000e7a33: test %al,%al 0x000e7a35: jne0xe7a31 i.e. it (the qemu bios I suppose) is waiting for x86 ioport 0xb3 to become zero. This port is #defined in hw/apm.c as: qemu-0.14.1/hw/apm.c:#define APM_STS_IOPORT 0xb3 but the definition seems to be used nowhere in that source file. Anyone have an idea why this port is never zero on sparc64 hosts but seems to be on others? (endian issue? uninitialized variable?) 2. Booting the same guest with -no-acpi gets further, bios and bootloader messages are printed until it hangs again, this time while handling a guest irq 8 which seems to be rtc. Maybe this is useful to some... :) Thanx, Juergen
[Qemu-devel] [PATCH] (master, stable-0.13) Fix a make -j race
Signed-off-by: Juergen Lock n...@jelal.kn-bremen.de --- a/Makefile +++ b/Makefile @@ -114,7 +114,7 @@ bt-host.o: QEMU_CFLAGS += $(BLUEZ_CFLAGS ## qemu-img.o: qemu-img-cmds.h -qemu-img.o qemu-tool.o qemu-nbd.o qemu-io.o: $(GENERATED_HEADERS) +qemu-img.o qemu-tool.o qemu-nbd.o qemu-io.o cmd.o: $(GENERATED_HEADERS) qemu-img$(EXESUF): qemu-img.o qemu-tool.o qemu-error.o $(block-obj-y) $(qobject-obj-y)
[Qemu-devel] [PATCH] (master, stable-0.13) zaurus: workaround for io base address rounded down
The 2nd scoop's base address (0x08800040) now gets rounded down to
start of page which causes its io read/write callbacks to be passed
addresses 0x40 higher than the code expects: (as witnessed by
Bad register offset messages and failure to attach the internal
CF disk aka microdrive at least.)
[There may be more bugs of this kind hiding in other targets, this
was just the one I tested...]
Signed-off-by: Juergen Lock n...@jelal.kn-bremen.de
--- a/hw/zaurus.c
+++ b/hw/zaurus.c
@@ -70,6 +70,10 @@ static uint32_t scoop_readb(void *opaque
{
ScoopInfo *s = (ScoopInfo *) opaque;
+// XXX Workaround for base address (0x08800040 in this case)
+// rounded down to start of page
+addr = 0x3f;
+
switch (addr) {
case SCOOP_MCR:
return s-mcr;
@@ -104,6 +108,10 @@ static void scoop_writeb(void *opaque, t
ScoopInfo *s = (ScoopInfo *) opaque;
value = 0x;
+// XXX Workaround for base address (0x08800040 in this case)
+// rounded down to start of page
+addr = 0x3f;
+
switch (addr) {
case SCOOP_MCR:
s-mcr = value;
Re: [Qemu-devel] [RFT] qemu 0.13.0-rc3
On Wed, Oct 13, 2010 at 05:28:37AM +0200, Juergen Lock wrote: On Tue, Oct 12, 2010 at 05:00:34PM -0500, Anthony Liguori wrote: On 10/12/2010 04:34 PM, Juergen Lock wrote: In article4cb38c82.1090...@linux.vnet.ibm.com you write: After suffering from a prolonged maintainer softlockup, I'm attempting to get 0.13.0 release process back on track. I've tagged qemu-0.13.0-rc3 in git which only carries a few changes since 0.13.0-rc1. Most notably, a series of updates from Kevin Wolf and Cam Macdonell's ivshmem device. I think we're pretty good testing wise for the final release but I wanted to offer a 24-hour window for last minute fixes. I'm only interested in the following: 1) Patches that are *tested* against the stable-0.13 branch that are already committed in master. Please tell me explicitly that you've tested the patch and how you've tested it. [...] First tests: - vmmouse seems broken (or disabled? I don't see it in `info qdm'...) I don't think vmmouse is part of qdev yet. Ok, but it also stopped working, pointer doesn't move... - to test arm emulation I tried booting my old zaurus images (-M terrier) which failed (qd fix below), and in the process also tested -M n800 w/o an image which failed with: qemu-system-arm: Duplicate ID 'null' for chardev Can't create serial device, empty char device and that I got fixed by cherry-picking this commit from master: 6a8aabd3c132188ee8e0e82ef4aba09f782cbe96 From: Stefan Weilw...@mail.berlios.de Date: Sun, 8 Aug 2010 14:09:26 +0200 Subject: [PATCH] hw/omap: Fix default setup for OMAP UART devices Sorry, is the patch below an additional fix? Yes, different and unrelated bug. If so, please submit against master. Right, I shall build test that as well - later. :) Done, and I can report vmmouse is broken on master too. Or at least it is w/ jit, didn't test kvm since this was on FreeBSD. And I tested sidux/aptosid isos since those enable vmmouse by default if detected. Cheers, Juergen
Re: [Qemu-devel] [PATCH] (master, stable-0.13) zaurus: workaround for io base address rounded down
On Wed, Oct 13, 2010 at 07:45:19PM +, Blue Swirl wrote: On Wed, Oct 13, 2010 at 7:12 PM, Juergen Lock qem...@jelal.kn-bremen.de wrote: The 2nd scoop's base address (0x08800040) now gets rounded down to start of page which causes its io read/write callbacks to be passed addresses 0x40 higher than the code expects: (as witnessed by Bad register offset messages and failure to attach the internal CF disk aka microdrive at least.) [There may be more bugs of this kind hiding in other targets, this was just the one I tested...] The devices are passed an offset to base address. Perhaps the real problem is that scoop_init registers too much MMIO: 0x1000, when the real range should be only 0x28. Also the registers are in 4 byte intervals and any access to address between the registers also triggers a warning. Well I just tried registering only 0x28 bytes and still got the messages: --- a/hw/zaurus.c +++ b/hw/zaurus.c @@ -237,7 +241,7 @@ ScoopInfo *scoop_init(PXA2xxState *cpu, s-in = qemu_allocate_irqs(scoop_gpio_set, s, 16); iomemtype = cpu_register_io_memory(scoop_readfn, scoop_writefn, s); -cpu_register_physical_memory(target_base, 0x1000, iomemtype); +cpu_register_physical_memory(target_base, 0x28, iomemtype); register_savevm(NULL, scoop, instance, 1, scoop_save, scoop_load, s); return s; What were the messages exactly? Excerpt: [...] scoop_readb: Bad register offset 0x4c scoop_writeb: Bad register offset 0x54 scoop_writeb: Bad register offset 0x5c scoop_writeb: Bad register offset 0x54 scoop_readb: Bad register offset 0x48 scoop_writeb: Bad register offset 0x44 scoop_readb: Bad register offset 0x4c scoop_readb: Bad register offset 0x48 scoop_readb: Bad register offset 0x4c scoop_readb: Bad register offset 0x48 scoop_readb: Bad register offset 0x4c scoop_readb: Bad register offset 0x48 spitz_out_switch: Green LED off. spitz_out_switch: Green LED on. spitz_out_switch: Green LED off. spitz_out_switch: Green LED on. scoop_readb: Bad register offset 0x4c scoop_writeb: Bad register offset 0x54 scoop_writeb: Bad register offset 0x5c scoop_writeb: Bad register offset 0x54 scoop_readb: Bad register offset 0x48 scoop_writeb: Bad register offset 0x44 spitz_out_switch: Green LED off. spitz_out_switch: Green LED on. spitz_out_switch: Green LED off. spitz_out_switch: Green LED on. scoop_readb: Bad register offset 0x4c scoop_writeb: Bad register offset 0x54 scoop_writeb: Bad register offset 0x5c scoop_writeb: Bad register offset 0x54 scoop_readb: Bad register offset 0x48 scoop_writeb: Bad register offset 0x44 spitz_out_switch: Green LED off. spitz_out_switch: Green LED on. spitz_out_switch: Green LED off. spitz_out_switch: Green LED on. scoop_readb: Bad register offset 0x4c scoop_writeb: Bad register offset 0x54 scoop_writeb: Bad register offset 0x5c scoop_writeb: Bad register offset 0x54 scoop_readb: Bad register offset 0x48 scoop_writeb: Bad register offset 0x44 spitz_out_switch: Green LED off. spitz_out_switch: Green LED on. spitz_out_switch: Green LED off. spitz_out_switch: Green LED on. scoop_readb: Bad register offset 0x4c scoop_writeb: Bad register offset 0x54 scoop_writeb: Bad register offset 0x5c scoop_writeb: Bad register offset 0x54 scoop_readb: Bad register offset 0x48 scoop_writeb: Bad register offset 0x44 spitz_out_switch: Green LED off. spitz_out_switch: Green LED on. spitz_out_switch: Green LED off. spitz_out_switch: Green LED on. scoop_readb: Bad register offset 0x4c scoop_writeb: Bad register offset 0x54 scoop_writeb: Bad register offset 0x5c scoop_writeb: Bad register offset 0x54 scoop_readb: Bad register offset 0x48 scoop_writeb: Bad register offset 0x44 spitz_out_switch: Green LED off. (The above patch together with the addr = 0x3f changes works tho.) Thanx, :) Juergen
Re: [Qemu-devel] [RFT] qemu 0.13.0-rc3
In article 4cb38c82.1090...@linux.vnet.ibm.com you write:
After suffering from a prolonged maintainer softlockup, I'm attempting
to get 0.13.0 release process back on track.
I've tagged qemu-0.13.0-rc3 in git which only carries a few changes
since 0.13.0-rc1. Most notably, a series of updates from Kevin Wolf and
Cam Macdonell's ivshmem device.
I think we're pretty good testing wise for the final release but I
wanted to offer a 24-hour window for last minute fixes. I'm only
interested in the following:
1) Patches that are *tested* against the stable-0.13 branch that are
already committed in master. Please tell me explicitly that you've
tested the patch and how you've tested it.
[...]
First tests:
- vmmouse seems broken (or disabled? I don't see it in `info qdm'...)
- to test arm emulation I tried booting my old zaurus images (-M terrier)
which failed (qd fix below), and in the process also tested -M n800
w/o an image which failed with:
qemu-system-arm: Duplicate ID 'null' for chardev
Can't create serial device, empty char device
and that I got fixed by cherry-picking this commit from master:
6a8aabd3c132188ee8e0e82ef4aba09f782cbe96
From: Stefan Weil w...@mail.berlios.de
Date: Sun, 8 Aug 2010 14:09:26 +0200
Subject: [PATCH] hw/omap: Fix default setup for OMAP UART devices
==
And the zaurus patch, problem was the 2nd scoop's base address
(0x08800040) gets rounded down to start of page which causes its
io read/write callbacks to be passed addresses 0x40 higher than
the code expects: (as witnessed by Bad register offset messages
and failure to attach the internal CF disk aka microdrive at least.)
Signed-off-by: Juergen Lock n...@jelal.kn-bremen.de
--- a/hw/zaurus.c
+++ b/hw/zaurus.c
@@ -70,6 +70,10 @@ static uint32_t scoop_readb(void *opaque
{
ScoopInfo *s = (ScoopInfo *) opaque;
+// XXX Workaround for base address (0x08800040 in this case)
+// rounded down to start of page
+addr = 0x3f;
+
switch (addr) {
case SCOOP_MCR:
return s-mcr;
@@ -104,6 +108,10 @@ static void scoop_writeb(void *opaque, t
ScoopInfo *s = (ScoopInfo *) opaque;
value = 0x;
+// XXX Workaround for base address (0x08800040 in this case)
+// rounded down to start of page
+addr = 0x3f;
+
switch (addr) {
case SCOOP_MCR:
s-mcr = value;
Re: [Qemu-devel] [RFT] qemu 0.13.0-rc3
On Tue, Oct 12, 2010 at 05:00:34PM -0500, Anthony Liguori wrote: On 10/12/2010 04:34 PM, Juergen Lock wrote: In article4cb38c82.1090...@linux.vnet.ibm.com you write: After suffering from a prolonged maintainer softlockup, I'm attempting to get 0.13.0 release process back on track. I've tagged qemu-0.13.0-rc3 in git which only carries a few changes since 0.13.0-rc1. Most notably, a series of updates from Kevin Wolf and Cam Macdonell's ivshmem device. I think we're pretty good testing wise for the final release but I wanted to offer a 24-hour window for last minute fixes. I'm only interested in the following: 1) Patches that are *tested* against the stable-0.13 branch that are already committed in master. Please tell me explicitly that you've tested the patch and how you've tested it. [...] First tests: - vmmouse seems broken (or disabled? I don't see it in `info qdm'...) I don't think vmmouse is part of qdev yet. Ok, but it also stopped working, pointer doesn't move... - to test arm emulation I tried booting my old zaurus images (-M terrier) which failed (qd fix below), and in the process also tested -M n800 w/o an image which failed with: qemu-system-arm: Duplicate ID 'null' for chardev Can't create serial device, empty char device and that I got fixed by cherry-picking this commit from master: 6a8aabd3c132188ee8e0e82ef4aba09f782cbe96 From: Stefan Weilw...@mail.berlios.de Date: Sun, 8 Aug 2010 14:09:26 +0200 Subject: [PATCH] hw/omap: Fix default setup for OMAP UART devices Sorry, is the patch below an additional fix? Yes, different and unrelated bug. If so, please submit against master. Right, I shall build test that as well - later. :) Thanx, Juergen
Re: [Qemu-devel] [PATCH, resend] [STABLE] Sync OSS_GETVERSION handling with head
On Sun, Apr 18, 2010 at 11:52:16PM +0200, Juergen Lock wrote: On Sun, Apr 18, 2010 at 11:38:34PM +0200, Aurelien Jarno wrote: On Sun, Apr 18, 2010 at 11:16:46PM +0200, Juergen Lock wrote: On Sun, Apr 18, 2010 at 10:52:22PM +0200, Aurelien Jarno wrote: On Sun, Apr 11, 2010 at 06:17:32PM +0200, Juergen Lock wrote: As suggested by Andreas Färber, here is a cumulative patch that syncs OSS_GETVERSION handling with head by merging the following commits: 1. oss: issue OSS_GETVERSION ioctl only when needed 6d246526ce3c145b2831285def6983f5de6190d3 2. oss: fix fragment setting 3d709fe73a77c40e263b3af6e650fd4b519c3562 3. Workaround for broken OSS_GETVERSION on FreeBSD, part two 72ff25e4e98d6dba9286d032b9ff5432553bbad5 Signed-off-by: Juergen Lock n...@jelal.kn-bremen.de I would actually prefer a patch series instead of a cumulative patch, so that we can match commits between HEAD and stable-0.12. Oh, I only did what was suggested... If you want to merge those as individual commits I think you can just cherry-pick them from head? They doesn't apply directly, and fixing them doesn't seems that trivial. Oh, I must have completely forgot about that then. :( I'll see what I can do over the next few days... Ok found the reason cherry-picking didn't work: There were two commits missing at the beginning of the above list (doh!), the correct list is: 1. oss: workaround for cases when OSS_GETVERSION is not defined e726fe7d60d46636c74c1c4a8fac7e4a05efb163 2. oss: refactor code around policy setting 78d9356d3caad95a74bc9cd65eea5fc7e050c35d 3. oss: issue OSS_GETVERSION ioctl only when needed 6d246526ce3c145b2831285def6983f5de6190d3 4. oss: fix fragment setting 3d709fe73a77c40e263b3af6e650fd4b519c3562 5. Workaround for broken OSS_GETVERSION on FreeBSD, part two 72ff25e4e98d6dba9286d032b9ff5432553bbad5 So with this list you should be able to sync audio/ossaudio.c correctly, and sorry again about the confusion... Juergen
Re: [Qemu-devel] [PATCH, resend] [STABLE] Sync OSS_GETVERSION handling with head
On Sun, Apr 18, 2010 at 10:52:22PM +0200, Aurelien Jarno wrote: On Sun, Apr 11, 2010 at 06:17:32PM +0200, Juergen Lock wrote: As suggested by Andreas Färber, here is a cumulative patch that syncs OSS_GETVERSION handling with head by merging the following commits: 1. oss: issue OSS_GETVERSION ioctl only when needed 6d246526ce3c145b2831285def6983f5de6190d3 2. oss: fix fragment setting 3d709fe73a77c40e263b3af6e650fd4b519c3562 3. Workaround for broken OSS_GETVERSION on FreeBSD, part two 72ff25e4e98d6dba9286d032b9ff5432553bbad5 Signed-off-by: Juergen Lock n...@jelal.kn-bremen.de I would actually prefer a patch series instead of a cumulative patch, so that we can match commits between HEAD and stable-0.12. Oh, I only did what was suggested... If you want to merge those as individual commits I think you can just cherry-pick them from head? Also malc, do you have any comment on that? Last time he approved (with some delay), it just never got committed. Cheers, Juergen
Re: [Qemu-devel] [PATCH, resend] [STABLE] Sync OSS_GETVERSION handling with head
On Sun, Apr 18, 2010 at 11:38:34PM +0200, Aurelien Jarno wrote: On Sun, Apr 18, 2010 at 11:16:46PM +0200, Juergen Lock wrote: On Sun, Apr 18, 2010 at 10:52:22PM +0200, Aurelien Jarno wrote: On Sun, Apr 11, 2010 at 06:17:32PM +0200, Juergen Lock wrote: As suggested by Andreas Färber, here is a cumulative patch that syncs OSS_GETVERSION handling with head by merging the following commits: 1. oss: issue OSS_GETVERSION ioctl only when needed 6d246526ce3c145b2831285def6983f5de6190d3 2. oss: fix fragment setting 3d709fe73a77c40e263b3af6e650fd4b519c3562 3. Workaround for broken OSS_GETVERSION on FreeBSD, part two 72ff25e4e98d6dba9286d032b9ff5432553bbad5 Signed-off-by: Juergen Lock n...@jelal.kn-bremen.de I would actually prefer a patch series instead of a cumulative patch, so that we can match commits between HEAD and stable-0.12. Oh, I only did what was suggested... If you want to merge those as individual commits I think you can just cherry-pick them from head? They doesn't apply directly, and fixing them doesn't seems that trivial. Oh, I must have completely forgot about that then. :( I'll see what I can do over the next few days... Cheers, Juergen
[Qemu-devel] [PATCH, resend] [STABLE] Sync OSS_GETVERSION handling with head
As suggested by Andreas Färber, here is a cumulative patch that syncs
OSS_GETVERSION handling with head by merging the following commits:
1. oss: issue OSS_GETVERSION ioctl only when needed
6d246526ce3c145b2831285def6983f5de6190d3
2. oss: fix fragment setting
3d709fe73a77c40e263b3af6e650fd4b519c3562
3. Workaround for broken OSS_GETVERSION on FreeBSD, part two
72ff25e4e98d6dba9286d032b9ff5432553bbad5
Signed-off-by: Juergen Lock n...@jelal.kn-bremen.de
--- a/audio/ossaudio.c
+++ b/audio/ossaudio.c
@@ -38,6 +38,10 @@
#define AUDIO_CAP oss
#include audio_int.h
+#if defined OSS_GETVERSION defined SNDCTL_DSP_POLICY
+#define USE_DSP_POLICY
+#endif
+
typedef struct OSSVoiceOut {
HWVoiceOut hw;
void *pcm_buf;
@@ -236,14 +240,39 @@ static void oss_dump_info (struct oss_pa
}
#endif
+#ifdef USE_DSP_POLICY
+static int oss_get_version (int fd, int *version, const char *typ)
+{
+if (ioctl (fd, OSS_GETVERSION, version)) {
+#if defined(__FreeBSD__) || defined(__FreeBSD_kernel__)
+/*
+ * Looks like atm (20100109) FreeBSD knows OSS_GETVERSION
+ * since 7.x, but currently only on the mixer device (or in
+ * the Linuxolator), and in the native version that part of
+ * the code is in fact never reached so the ioctl fails anyway.
+ * Until this is fixed, just check the errno and if its what
+ * FreeBSD's sound drivers return atm assume they are new enough.
+ */
+if (errno == EINVAL) {
+*version = 0x04;
+return 0;
+}
+#endif
+oss_logerr2 (errno, typ, Failed to get OSS version\n);
+return -1;
+}
+return 0;
+}
+#endif
+
static int oss_open (int in, struct oss_params *req,
struct oss_params *obt, int *pfd)
{
int fd;
-int version;
int oflags = conf.exclusive ? O_EXCL : 0;
audio_buf_info abinfo;
int fmt, freq, nchannels;
+int setfragment = 1;
const char *dspname = in ? conf.devpath_in : conf.devpath_out;
const char *typ = in ? ADC : DAC;
@@ -281,27 +310,30 @@ static int oss_open (int in, struct oss_
goto err;
}
-if (ioctl (fd, OSS_GETVERSION, version)) {
-oss_logerr2 (errno, typ, Failed to get OSS version\n);
-version = 0;
-}
+#ifdef USE_DSP_POLICY
+if (conf.policy = 0) {
+int version;
-if (conf.debug) {
-dolog (OSS version = %#x\n, version);
-}
+if (!oss_get_version (fd, version, typ)) {
+if (conf.debug) {
+dolog (OSS version = %#x\n, version);
+}
-#ifdef SNDCTL_DSP_POLICY
-if (conf.policy = 0 version = 0x04) {
-int policy = conf.policy;
-if (ioctl (fd, SNDCTL_DSP_POLICY, policy)) {
-oss_logerr2 (errno, typ, Failed to set timing policy to %d\n,
- conf.policy);
-goto err;
+if (version = 0x04) {
+int policy = conf.policy;
+if (ioctl (fd, SNDCTL_DSP_POLICY, policy)) {
+oss_logerr2 (errno, typ,
+ Failed to set timing policy to %d\n,
+ conf.policy);
+goto err;
+}
+setfragment = 0;
+}
}
}
-else
#endif
-{
+
+if (setfragment) {
int = (req-nfrags 16) | ctz32 (req-fragsize);
if (ioctl (fd, SNDCTL_DSP_SETFRAGMENT, )) {
oss_logerr2 (errno, typ, Failed to set buffer length (%d, %d)\n,
@@ -857,7 +889,7 @@ static struct audio_option oss_options[]
.valp = conf.exclusive,
.descr = Open device in exclusive mode (vmix wont work)
},
-#ifdef SNDCTL_DSP_POLICY
+#ifdef USE_DSP_POLICY
{
.name = POLICY,
.tag = AUD_OPT_INT,
Re: [Qemu-devel] [PATCHv2] Avoid page_set_flags() assert in qemu-user host page protection code
On Sat, Apr 10, 2010 at 05:22:08PM +0200, Aurelien Jarno wrote: On Fri, Apr 09, 2010 at 10:02:41PM +0200, Aurelien Jarno wrote: On Wed, Mar 31, 2010 at 11:00:36PM +0200, Juergen Lock wrote: V2 that uses endaddr = end-of-guest-address-space if !h2g_valid(endaddr) after I found out that indeed works; and also disables the FreeBSD 6.x /compat/linux/proc/self/maps fallback because it can return partial lines if (at least I think that's the reason) the mappings change between subsequent read() calls. Signed-off-by: Juergen Lock n...@jelal.kn-bremen.de Thanks, applied. This patch actually breaks the build on 32-bit hosts. I have reverted it. Oh dear, sorry about that. :( Should I make a new version thats conditional on the host being 64-bit? Or do you think 32-bit hosts also need something fixed there? Sorry again... Juergen
Re: [Qemu-devel] qemu git head 20100323 on FreeBSD - qemu-devel port update for testing
On Thu, Apr 01, 2010 at 11:59:11AM +, Paul Brook wrote: Oh this is happening with x86_64-bsd-user on the same arch so I'd say (abi_ulong)-1 would be the same as ~0ul (and still cause the assert.) No. These two are different when sizeof(abi_ulong) sizeof(long). Yeah sorry I meant in this case that caused the assert. (x86_64-bsd-user on same-arch host.) Cheers, Juergen
[Qemu-devel] [PATCHv2] Avoid page_set_flags() assert in qemu-user host page protection code
V2 that uses endaddr = end-of-guest-address-space if !h2g_valid(endaddr)
after I found out that indeed works; and also disables the FreeBSD 6.x
/compat/linux/proc/self/maps fallback because it can return partial lines
if (at least I think that's the reason) the mappings change between
subsequent read() calls.
Signed-off-by: Juergen Lock n...@jelal.kn-bremen.de
--- a/exec.c
+++ b/exec.c
@@ -306,13 +306,14 @@ static void page_init(void)
if (h2g_valid(endaddr)) {
endaddr = h2g(endaddr);
-page_set_flags(startaddr, endaddr, PAGE_RESERVED);
} else {
#if TARGET_ABI_BITS = L1_MAP_ADDR_SPACE_BITS
endaddr = ~0ul;
-page_set_flags(startaddr, endaddr, PAGE_RESERVED);
+#else
+endaddr = ((abi_ulong)1 L1_MAP_ADDR_SPACE_BITS) - 1;
#endif
}
+page_set_flags(startaddr, endaddr, PAGE_RESERVED);
}
}
free(freep);
@@ -323,11 +324,7 @@ static void page_init(void)
last_brk = (unsigned long)sbrk(0);
-#if defined(__FreeBSD__) || defined(__FreeBSD_kernel__) ||
defined(__DragonFly__)
-f = fopen(/compat/linux/proc/self/maps, r);
-#else
f = fopen(/proc/self/maps, r);
-#endif
if (f) {
mmap_lock();
@@ -343,7 +340,11 @@ static void page_init(void)
if (h2g_valid(endaddr)) {
endaddr = h2g(endaddr);
} else {
+#if TARGET_ABI_BITS = L1_MAP_ADDR_SPACE_BITS
endaddr = ~0ul;
+#else
+endaddr = ((abi_ulong)1 L1_MAP_ADDR_SPACE_BITS) - 1;
+#endif
}
page_set_flags(startaddr, endaddr, PAGE_RESERVED);
}
Re: [Qemu-devel] qemu git head 20100323 on FreeBSD - qemu-devel port update for testing
On Tue, Mar 30, 2010 at 09:04:28PM +0300, Blue Swirl wrote:
On 3/25/10, Juergen Lock n...@jelal.kn-bremen.de wrote:
Hi!
Now that qemu git head works again (thanx Aurelien! :) I've finished
the FreeBSD qemu-devel port update patch/shar that made me uncover
the bug:
http://people.freebsd.org/~nox/qemu/qemu-devel-20100323.patch
resp.
http://people.freebsd.org/~nox/qemu/qemu-devel-20100323.shar
This also adds a few misc fixes (that I'll submit on the qemu list
seperately), I have...
. Fixed the FreeBSD executable path detection to work without /proc
mounted (it usually isn't on FreeBSD), so you now no longer have to
pass the path to the pc-bios dir with -L if you run qemu out of the
build dir when another version is installed, like,
work/qemu-snapshot-20100323_20/i386-softmmu/qemu ...
(files/patch-vl.c in the shar/patch)
. Fixed some more bsd-user bugs so all of i386-bsd-user, x86_64-bsd-user,
and sparc64-bsd-user now run for me again on FreeBSD stable/8 amd64.
(I didn't test sparc-bsd-user as I only tried -bsd freebsd and FreeBSD
doesn't run on 32bit sparc.) - Yes bsd-user still needs more work but
at least simple exectuables run.
(files/patch-bsd-user-mmap.c, files/patch-exec.c)
. Fixed the bsd-user host page protection code for FreeBSD hosts
(using kinfo_getvmmap(3) on FeeBSD = 7.x and /compat/linux/proc
on older FreeBSD.)
(files/patch-bsd-user-linproc)
. Fixed some compilation warnings and a missing #include.
(files/patch-qemu-char.c, files/patch-qemu-timer.c)
Thanks, applied all except exec.c one.
Oh, is there something wrong with it? You mean this one, right?
Subject: [PATCH] Avoid page_set_flags() assert in qemu-user host page
protection code
Message-ID: 20100325211421.ga52...@triton8.kn-bremen.de
[...]
--- a/exec.c
+++ b/exec.c
@@ -293,10 +293,13 @@ static void page_init(void)
if (h2g_valid(endaddr)) {
endaddr = h2g(endaddr);
+page_set_flags(startaddr, endaddr, PAGE_RESERVED);
} else {
+#if TARGET_ABI_BITS = L1_MAP_ADDR_SPACE_BITS
endaddr = ~0ul;
+page_set_flags(startaddr, endaddr, PAGE_RESERVED);
+#endif
}
-page_set_flags(startaddr, endaddr, PAGE_RESERVED);
}
} while (!feof(f));
I first tried to replace the endaddr in the !h2g_valid(endaddr) case with
((abi_ulong)1 L1_MAP_ADDR_SPACE_BITS) - 1
if TARGET_ABI_BITS L1_MAP_ADDR_SPACE_BITS (which comes from the condition
of the assert in page_set_flags() that was triggered on the ~0ul value),
but that caused the qemu process to grow into swap and made the box
usuable when that code was reached and I had to kill qemu. (The box has
8 GB RAM.) And so I thought just leaving that page range unprotected
if only the start address is valid was the lesser evil...
..and thanx for committing the other ones, :)
Juergen
Re: [Qemu-devel] qemu git head 20100323 on FreeBSD - qemu-devel port update for testing
In article 4bb2540b.90...@twiddle.net you write: On 03/30/2010 12:16 PM, Juergen Lock wrote: I first tried to replace the endaddr in the !h2g_valid(endaddr) case with ((abi_ulong)1 L1_MAP_ADDR_SPACE_BITS) - 1 if TARGET_ABI_BITS L1_MAP_ADDR_SPACE_BITS (which comes from the condition of the assert in page_set_flags() that was triggered on the ~0ul value), but that caused the qemu process to grow into swap and made the box usuable when that code was reached and I had to kill qemu. (The box has 8 GB RAM.) And so I thought just leaving that page range unprotected if only the start address is valid was the lesser evil... What's are the real arguments to the page_set_flags that causes things to go into swap? I can't imagine the range really being so large that it causes massive allocation within that function... Oh sorry if that was not clear, things go into swap if I _replace_ the endaddr ~0ul (which caused the assert) with the max value the assert still tolerates i.e. ((abi_ulong)1 L1_MAP_ADDR_SPACE_BITS) - 1 which in this case seems to be 0x7fff: #3 0x60012731 in page_set_flags (start=140737488224256, end=18446744073709551615, flags=32) at /usr/ports/emulators/qemu-devel-20100323a/work/qemu-snapshot-20100323_20/exec.c:2426 2426assert(end ((abi_ulong)1 L1_MAP_ADDR_SPACE_BITS)); (gdb) i li 2426 Line 2426 of /usr/ports/emulators/qemu-devel-20100323a/work/qemu-snapshot-20100323_20/exec.c starts at address 0x60012662 page_set_flags+34 and ends at 0x60012675 page_set_flags+53. (gdb) disassemble 0x60012662 0x60012675 Dump of assembler code from 0x60012662 to 0x60012675: 0x60012662 page_set_flags+34: mov$0x7fff,%rax ^^ 0x6001266c page_set_flags+44: cmp%rax,%rsi 0x6001266f page_set_flags+47: ja 0x60012718 page_set_flags+216 End of assembler dump. (gdb) q Cheers, Juergen
Re: [Qemu-devel] qemu git head 20100323 on FreeBSD - qemu-devel port update for testing
On Tue, Mar 30, 2010 at 10:54:03PM +0300, Blue Swirl wrote:
On 3/30/10, Juergen Lock n...@jelal.kn-bremen.de wrote:
On Tue, Mar 30, 2010 at 09:04:28PM +0300, Blue Swirl wrote:
On 3/25/10, Juergen Lock n...@jelal.kn-bremen.de wrote:
Hi!
Now that qemu git head works again (thanx Aurelien! :) I've finished
the FreeBSD qemu-devel port update patch/shar that made me uncover
the bug:
http://people.freebsd.org/~nox/qemu/qemu-devel-20100323.patch
resp.
http://people.freebsd.org/~nox/qemu/qemu-devel-20100323.shar
This also adds a few misc fixes (that I'll submit on the qemu list
seperately), I have...
. Fixed the FreeBSD executable path detection to work without /proc
mounted (it usually isn't on FreeBSD), so you now no longer have to
pass the path to the pc-bios dir with -L if you run qemu out of the
build dir when another version is installed, like,
work/qemu-snapshot-20100323_20/i386-softmmu/qemu ...
(files/patch-vl.c in the shar/patch)
. Fixed some more bsd-user bugs so all of i386-bsd-user,
x86_64-bsd-user,
and sparc64-bsd-user now run for me again on FreeBSD stable/8 amd64.
(I didn't test sparc-bsd-user as I only tried -bsd freebsd and
FreeBSD
doesn't run on 32bit sparc.) - Yes bsd-user still needs more work but
at least simple exectuables run.
(files/patch-bsd-user-mmap.c, files/patch-exec.c)
. Fixed the bsd-user host page protection code for FreeBSD hosts
(using kinfo_getvmmap(3) on FeeBSD = 7.x and /compat/linux/proc
on older FreeBSD.)
(files/patch-bsd-user-linproc)
. Fixed some compilation warnings and a missing #include.
(files/patch-qemu-char.c, files/patch-qemu-timer.c)
Thanks, applied all except exec.c one.
Oh, is there something wrong with it? You mean this one, right?
Subject: [PATCH] Avoid page_set_flags() assert in qemu-user host page
protection code
Message-ID: 20100325211421.ga52...@triton8.kn-bremen.de
[...]
--- a/exec.c
+++ b/exec.c
@@ -293,10 +293,13 @@ static void page_init(void)
if (h2g_valid(endaddr)) {
endaddr = h2g(endaddr);
+page_set_flags(startaddr, endaddr, PAGE_RESERVED);
} else {
+#if TARGET_ABI_BITS = L1_MAP_ADDR_SPACE_BITS
endaddr = ~0ul;
+page_set_flags(startaddr, endaddr, PAGE_RESERVED);
+#endif
}
-page_set_flags(startaddr, endaddr, PAGE_RESERVED);
}
} while (!feof(f));
I first tried to replace the endaddr in the !h2g_valid(endaddr) case with
((abi_ulong)1 L1_MAP_ADDR_SPACE_BITS) - 1
if TARGET_ABI_BITS L1_MAP_ADDR_SPACE_BITS (which comes from the condition
of the assert in page_set_flags() that was triggered on the ~0ul value),
but that caused the qemu process to grow into swap and made the box
usuable when that code was reached and I had to kill qemu. (The box has
8 GB RAM.) And so I thought just leaving that page range unprotected
if only the start address is valid was the lesser evil...
I was thinking something like (abi_ulong)-1 but maybe that isn't any
more correct.
Oh this is happening with x86_64-bsd-user on the same arch so I'd say
(abi_ulong)-1 would be the same as ~0ul (and still cause the assert.)
Cheers,
Juergen
Re: [Qemu-devel] qemu git head 20100323 on FreeBSD - qemu-devel port update for testing
On Tue, Mar 30, 2010 at 10:09:47PM +0200, Juergen Lock wrote: In article 4bb2540b.90...@twiddle.net you write: On 03/30/2010 12:16 PM, Juergen Lock wrote: I first tried to replace the endaddr in the !h2g_valid(endaddr) case with ((abi_ulong)1 L1_MAP_ADDR_SPACE_BITS) - 1 if TARGET_ABI_BITS L1_MAP_ADDR_SPACE_BITS (which comes from the condition of the assert in page_set_flags() that was triggered on the ~0ul value), but that caused the qemu process to grow into swap and made the box usuable when that code was reached and I had to kill qemu. (The box has 8 GB RAM.) And so I thought just leaving that page range unprotected if only the start address is valid was the lesser evil... What's are the real arguments to the page_set_flags that causes things to go into swap? I can't imagine the range really being so large that it causes massive allocation within that function... Oh sorry if that was not clear, things go into swap if I _replace_ the endaddr ~0ul (which caused the assert) with the max value the assert still tolerates i.e. ((abi_ulong)1 L1_MAP_ADDR_SPACE_BITS) - 1 which in this case seems to be 0x7fff: #3 0x60012731 in page_set_flags (start=140737488224256, end=18446744073709551615, flags=32) at /usr/ports/emulators/qemu-devel-20100323a/work/qemu-snapshot-20100323_20/exec.c:2426 2426 assert(end ((abi_ulong)1 L1_MAP_ADDR_SPACE_BITS)); (gdb) i li 2426 Line 2426 of /usr/ports/emulators/qemu-devel-20100323a/work/qemu-snapshot-20100323_20/exec.c starts at address 0x60012662 page_set_flags+34 and ends at 0x60012675 page_set_flags+53. (gdb) disassemble 0x60012662 0x60012675 Dump of assembler code from 0x60012662 to 0x60012675: 0x60012662 page_set_flags+34: mov$0x7fff,%rax ^^ 0x6001266c page_set_flags+44: cmp%rax,%rsi 0x6001266f page_set_flags+47: ja 0x60012718 page_set_flags+216 End of assembler dump. (gdb) q Ok sorry about the confusion, this is a different problem, I just looked at the value of start, it seems to be: (gdb) p start $2 = 0x7ffe So I'd say the real problem is page_set_flags() has a bug that makes it allocate too much if the range is the last allowed page... Cheers, Juergen
Re: [Qemu-devel] qemu git head 20100323 on FreeBSD - qemu-devel port update for testing
On Tue, Mar 30, 2010 at 01:33:15PM -0700, Richard Henderson wrote: On 03/30/2010 01:09 PM, Juergen Lock wrote: Oh sorry if that was not clear, things go into swap if I _replace_ the endaddr ~0ul (which caused the assert) with the max value the assert still tolerates i.e. ((abi_ulong)1 L1_MAP_ADDR_SPACE_BITS) - 1 which in this case seems to be 0x7fff: Yes, I got that. And I see from ... #3 0x60012731 in page_set_flags (start=140737488224256, end=18446744073709551615, flags=32) ... here that the range we're reserving is 0x7ffe ... 0x7fff which is a mere 128k range. Which ought to allocate no more than a single leaf page table (and thus N-1 pages for the N-level table). Which doesn't answer the question of why you'd wind up running out of memory. Ah yeah our mails crossed each other :) Yeah I don't know... Cheers, Juergen
Re: [Qemu-devel] qemu git head 20100323 on FreeBSD - qemu-devel port update for testing
On Tue, Mar 30, 2010 at 10:45:48PM +0200, Juergen Lock wrote: On Tue, Mar 30, 2010 at 01:33:15PM -0700, Richard Henderson wrote: On 03/30/2010 01:09 PM, Juergen Lock wrote: Oh sorry if that was not clear, things go into swap if I _replace_ the endaddr ~0ul (which caused the assert) with the max value the assert still tolerates i.e. ((abi_ulong)1 L1_MAP_ADDR_SPACE_BITS) - 1 which in this case seems to be 0x7fff: Yes, I got that. And I see from ... #3 0x60012731 in page_set_flags (start=140737488224256, end=18446744073709551615, flags=32) ... here that the range we're reserving is 0x7ffe ... 0x7fff which is a mere 128k range. Which ought to allocate no more than a single leaf page table (and thus N-1 pages for the N-level table). Which doesn't answer the question of why you'd wind up running out of memory. Ah yeah our mails crossed each other :) Yeah I don't know... Ok found the problem: Reads from /compat/linux/proc/self/maps are broken i.e. return partial lines if (at least I think that's the reason) the mappings change between read() calls. (It got a line like this after the first line that originally caused the assert: fe-8000 rwxp 0002 00:00 0 ) Well good that we now use kinfo_getvmmap(), I hope noone needs bsd-user on FreeBSD 6.x... Oh well... Juergen
[Qemu-devel] qemu git head 20100323 on FreeBSD - qemu-devel port update for testing
Hi! Now that qemu git head works again (thanx Aurelien! :) I've finished the FreeBSD qemu-devel port update patch/shar that made me uncover the bug: http://people.freebsd.org/~nox/qemu/qemu-devel-20100323.patch resp. http://people.freebsd.org/~nox/qemu/qemu-devel-20100323.shar This also adds a few misc fixes (that I'll submit on the qemu list seperately), I have... . Fixed the FreeBSD executable path detection to work without /proc mounted (it usually isn't on FreeBSD), so you now no longer have to pass the path to the pc-bios dir with -L if you run qemu out of the build dir when another version is installed, like, work/qemu-snapshot-20100323_20/i386-softmmu/qemu ... (files/patch-vl.c in the shar/patch) . Fixed some more bsd-user bugs so all of i386-bsd-user, x86_64-bsd-user, and sparc64-bsd-user now run for me again on FreeBSD stable/8 amd64. (I didn't test sparc-bsd-user as I only tried -bsd freebsd and FreeBSD doesn't run on 32bit sparc.) - Yes bsd-user still needs more work but at least simple exectuables run. (files/patch-bsd-user-mmap.c, files/patch-exec.c) . Fixed the bsd-user host page protection code for FreeBSD hosts (using kinfo_getvmmap(3) on FeeBSD = 7.x and /compat/linux/proc on older FreeBSD.) (files/patch-bsd-user-linproc) . Fixed some compilation warnings and a missing #include. (files/patch-qemu-char.c, files/patch-qemu-timer.c) Enjoy, :) Juergen
[Qemu-devel] [PATCH] Fix some compilation warnings on FreeBSD hosts
Signed-off-by: Juergen Lock n...@jelal.kn-bremen.de
--- a/qemu-char.c
+++ b/qemu-char.c
@@ -1372,7 +1372,7 @@ static CharDriverState *qemu_chr_open_pp
#if defined(__FreeBSD__) || defined(__FreeBSD_kernel__) ||
defined(__DragonFly__)
static int pp_ioctl(CharDriverState *chr, int cmd, void *arg)
{
-int fd = (int)chr-opaque;
+int fd = (int)(long)chr-opaque;
uint8_t b;
switch(cmd) {
@@ -1418,7 +1418,7 @@ static CharDriverState *qemu_chr_open_pp
return NULL;
chr = qemu_mallocz(sizeof(CharDriverState));
-chr-opaque = (void *)fd;
+chr-opaque = (void *)(long)fd;
chr-chr_write = null_chr_write;
chr-chr_ioctl = pp_ioctl;
return chr;
[Qemu-devel] [PATCH] Fix bsd-user qemu_vmalloc() host page protection code
Just do the same as linux-user does.
Signed-off-by: Juergen Lock n...@jelal.kn-bremen.de
--- a/bsd-user/mmap.c
+++ b/bsd-user/mmap.c
@@ -77,16 +77,15 @@ void mmap_unlock(void)
void *qemu_vmalloc(size_t size)
{
void *p;
-unsigned long addr;
mmap_lock();
/* Use map and mark the pages as used. */
p = mmap(NULL, size, PROT_READ | PROT_WRITE,
MAP_PRIVATE | MAP_ANON, -1, 0);
-addr = (unsigned long)p;
-if (addr == (target_ulong) addr) {
+if (h2g_valid(p)) {
/* Allocated region overlaps guest address space.
This may recurse. */
+abi_ulong addr = h2g(p);
page_set_flags(addr TARGET_PAGE_MASK, TARGET_PAGE_ALIGN(addr + size),
PAGE_RESERVED);
}
[Qemu-devel] [PATCH] Add a missing #include for FreeBSD hosts
Signed-off-by: Juergen Lock n...@jelal.kn-bremen.de --- a/qemu-timer.c +++ b/qemu-timer.c @@ -35,6 +35,9 @@ #include errno.h #include sys/time.h #include signal.h +#ifdef __FreeBSD__ +#include sys/param.h +#endif #ifdef __linux__ #include sys/ioctl.h
[Qemu-devel] [PATCH] Avoid page_set_flags() assert in qemu-user host page protection code
Signed-off-by: Juergen Lock n...@jelal.kn-bremen.de
--- a/exec.c
+++ b/exec.c
@@ -293,10 +293,13 @@ static void page_init(void)
if (h2g_valid(endaddr)) {
endaddr = h2g(endaddr);
+page_set_flags(startaddr, endaddr, PAGE_RESERVED);
} else {
+#if TARGET_ABI_BITS = L1_MAP_ADDR_SPACE_BITS
endaddr = ~0ul;
+page_set_flags(startaddr, endaddr, PAGE_RESERVED);
+#endif
}
-page_set_flags(startaddr, endaddr, PAGE_RESERVED);
}
} while (!feof(f));
[Qemu-devel] [PATCH] Get bsd-user host page protection code working on FreeBSD hosts
Use kinfo_getvmmap(3) on FeeBSD = 7.x and /compat/linux/proc on older
FreeBSD. (kinfo_getvmmap is preferred since /compat/linux/proc is
usually only mounted on hosts also using the Linuxolator.)
This patch is a bit hacky because the includes needed for kinfo_getvmmap
conflict with other definitions in exec.c by default so I had to `trick
around' a little, but I built the result in FreeBSD 6.4-stable and
7.2-stable tbs and on 8-stable on the host so the hacks at least
should be stable. (If this is a problem maybe we could also move the
kinfo_getvmmap invocations into a seperate source file but that would
be more work...)
Signed-off-by: Juergen Lock n...@jelal.kn-bremen.de
--- a/configure
+++ b/configure
@@ -335,6 +335,8 @@ FreeBSD)
make=gmake
audio_drv_list=oss
audio_possible_drivers=oss sdl esd pa
+ # needed for kinfo_getvmmap(3) in libutil.h
+ LIBS=-lutil $LIBS
;;
DragonFly)
bsd=yes
--- a/exec.c
+++ b/exec.c
@@ -41,6 +41,21 @@
#if defined(CONFIG_USER_ONLY)
#include qemu.h
#include signal.h
+#if defined(__FreeBSD__) || defined(__FreeBSD_kernel__)
+#include sys/param.h
+#if __FreeBSD_version = 700104
+#define HAVE_KINFO_GETVMMAP
+#define sigqueue sigqueue_freebsd /* avoid redefinition */
+#include sys/time.h
+#include sys/proc.h
+#include machine/profile.h
+#define _KERNEL
+#include sys/user.h
+#undef _KERNEL
+#undef sigqueue
+#include libutil.h
+#endif
+#endif
#endif
//#define DEBUG_TB_INVALIDATE
@@ -274,11 +289,45 @@ static void page_init(void)
#if !defined(_WIN32) defined(CONFIG_USER_ONLY)
{
+#ifdef HAVE_KINFO_GETVMMAP
+struct kinfo_vmentry *freep;
+int i, cnt;
+
+freep = kinfo_getvmmap(getpid(), cnt);
+if (freep) {
+mmap_lock();
+for (i = 0; i cnt; i++) {
+unsigned long startaddr, endaddr;
+
+startaddr = freep[i].kve_start;
+endaddr = freep[i].kve_end;
+if (h2g_valid(startaddr)) {
+startaddr = h2g(startaddr) TARGET_PAGE_MASK;
+
+if (h2g_valid(endaddr)) {
+endaddr = h2g(endaddr);
+page_set_flags(startaddr, endaddr, PAGE_RESERVED);
+} else {
+#if TARGET_ABI_BITS = L1_MAP_ADDR_SPACE_BITS
+endaddr = ~0ul;
+page_set_flags(startaddr, endaddr, PAGE_RESERVED);
+#endif
+}
+}
+}
+free(freep);
+mmap_unlock();
+}
+#else
FILE *f;
last_brk = (unsigned long)sbrk(0);
+#if defined(__FreeBSD__) || defined(__FreeBSD_kernel__) ||
defined(__DragonFly__)
+f = fopen(/compat/linux/proc/self/maps, r);
+#else
f = fopen(/proc/self/maps, r);
+#endif
if (f) {
mmap_lock();
@@ -303,6 +352,7 @@ static void page_init(void)
fclose(f);
mmap_unlock();
}
+#endif
}
#endif
}
[Qemu-devel] [PATCH] Fix bsd-user broken by commit b5ec5ce0e39d6e7ea707d5604a5f6d567dfd2f48
Signed-off-by: Juergen Lock n...@jelal.kn-bremen.de
--- a/bsd-user/main.c
+++ b/bsd-user/main.c
@@ -759,6 +759,10 @@ int main(int argc, char **argv)
}
cpu_model = NULL;
+#if defined(cpudef_setup)
+cpudef_setup(); /* parse cpu definitions in target config file (TBD) */
+#endif
+
optind = 1;
for(;;) {
if (optind = argc)
[Qemu-devel] git head broken? (x86 softmmu w/o kvm)
Hi! I just wanted to make another FreeBSD qemu git head snaphot port update, and found both i386-softmmu and x86_64-softmmu no longer boot, they seem to hang early in the bios before it prints anything, last tb seems to be this loop: IN: 0x000f1b8e: mov0xf81a0,%ecx 0x000f1b94: cmp%ecx,%eax 0x000f1b96: jne0xf1b8e OUT: [size=184] 0x4000e440: mov$0xf81a0,%ebp 0x4000e445: mov%rbp,%rsi 0x4000e448: mov%rbp,%rdi 0x4000e44b: shr$0x7,%rsi 0x4000e44f: and$0xf003,%rdi 0x4000e456: and$0x1fe0,%esi 0x4000e45c: lea0x4f8(%rsi,%r14,1),%rsi 0x4000e464: cmp(%rsi),%rdi 0x4000e467: mov%rbp,%rdi 0x4000e46a: je 0x4000e477 0x4000e46c: xor%esi,%esi 0x4000e46e: callq 0x51fd30 0x4000e473: mov%eax,%ebp 0x4000e475: jmp0x4000e47d 0x4000e477: add0x18(%rsi),%rdi 0x4000e47b: mov(%rdi),%ebp 0x4000e47d: mov%ebp,%ebp 0x4000e47f: mov%rbp,%rbx 0x4000e482: mov(%r14),%r12 0x4000e485: mov%rbx,%r13 0x4000e488: sub%rbx,%r12 0x4000e48b: mov%r12,%rbx 0x4000e48e: mov%ebx,%ebx 0x4000e490: mov$0x10,%r15d 0x4000e496: mov%r15d,0xa0(%r14) 0x4000e49d: mov%r13,0x90(%r14) 0x4000e4a4: mov%r12,0x98(%r14) 0x4000e4ab: mov%rbp,0x8(%r14) 0x4000e4af: test %rbx,%rbx 0x4000e4b2: jne0x4000e4d8 0x4000e4b8: jmpq 0x4000e4bd 0x4000e4bd: mov$0xf1b98,%ebp 0x4000e4c2: mov%rbp,0x80(%r14) 0x4000e4c9: mov$0x802c05c80,%rax 0x4000e4d3: jmpq 0xb65b8e 0x4000e4d8: jmpq 0x4000e4dd 0x4000e4dd: mov$0xf1b8e,%ebp 0x4000e4e2: mov%rbp,0x80(%r14) 0x4000e4e9: mov$0x802c05c81,%rax 0x4000e4f3: jmpq 0xb65b8e Is 0xf81a0 an io port or how is it supposed to change? And, can anyone reproduce this on Linux? As I said this is without kvm... Thanx! :) Juergen
[Qemu-devel] Re: git head broken? (x86 softmmu w/o kvm)
On Mon, Mar 22, 2010 at 10:25:24PM +0100, Juergen Lock wrote: Hi! I just wanted to make another FreeBSD qemu git head snaphot port update, and found both i386-softmmu and x86_64-softmmu no longer boot, they seem to hang early in the bios before it prints anything, last tb seems to be this loop: IN: 0x000f1b8e: mov0xf81a0,%ecx 0x000f1b94: cmp%ecx,%eax 0x000f1b96: jne0xf1b8e OUT: [size=184] 0x4000e440: mov$0xf81a0,%ebp 0x4000e445: mov%rbp,%rsi 0x4000e448: mov%rbp,%rdi 0x4000e44b: shr$0x7,%rsi 0x4000e44f: and$0xf003,%rdi 0x4000e456: and$0x1fe0,%esi 0x4000e45c: lea0x4f8(%rsi,%r14,1),%rsi 0x4000e464: cmp(%rsi),%rdi 0x4000e467: mov%rbp,%rdi 0x4000e46a: je 0x4000e477 0x4000e46c: xor%esi,%esi 0x4000e46e: callq 0x51fd30 0x4000e473: mov%eax,%ebp 0x4000e475: jmp0x4000e47d 0x4000e477: add0x18(%rsi),%rdi 0x4000e47b: mov(%rdi),%ebp 0x4000e47d: mov%ebp,%ebp 0x4000e47f: mov%rbp,%rbx 0x4000e482: mov(%r14),%r12 0x4000e485: mov%rbx,%r13 0x4000e488: sub%rbx,%r12 0x4000e48b: mov%r12,%rbx 0x4000e48e: mov%ebx,%ebx 0x4000e490: mov$0x10,%r15d 0x4000e496: mov%r15d,0xa0(%r14) 0x4000e49d: mov%r13,0x90(%r14) 0x4000e4a4: mov%r12,0x98(%r14) 0x4000e4ab: mov%rbp,0x8(%r14) 0x4000e4af: test %rbx,%rbx 0x4000e4b2: jne0x4000e4d8 0x4000e4b8: jmpq 0x4000e4bd 0x4000e4bd: mov$0xf1b98,%ebp 0x4000e4c2: mov%rbp,0x80(%r14) 0x4000e4c9: mov$0x802c05c80,%rax 0x4000e4d3: jmpq 0xb65b8e 0x4000e4d8: jmpq 0x4000e4dd 0x4000e4dd: mov$0xf1b8e,%ebp 0x4000e4e2: mov%rbp,0x80(%r14) 0x4000e4e9: mov$0x802c05c81,%rax 0x4000e4f3: jmpq 0xb65b8e Is 0xf81a0 an io port or how is it supposed to change? And, can anyone reproduce this on Linux? As I said this is without kvm... ..and in case its supposed to be changed by an irq I just tried -d in_asm,out_asm,int and saw none listed. I've put the qemu.log here: http://people.freebsd.org/~nox/qemu/qemu.log.gz TIA, Juergen
[Qemu-devel] [PATCH] FreeBSD ppc_init_cacheline_sizes(): add missing #includes
This fixes commit e4ee916d3f9a93df06bd498c92767c1558d59a0b. (The bug was mine actually...) Submitted by: Andreas Tobler andre...@fgznet.ch Signed-off-by: Juergen Lock n...@jelal.kn-bremen.de --- a/cache-utils.c +++ b/cache-utils.c @@ -58,7 +58,10 @@ static void ppc_init_cacheline_sizes(voi #endif #if defined(__FreeBSD__) || defined(__FreeBSD_kernel__) +#include errno.h #include stdio.h +#include stdlib.h +#include string.h #include sys/types.h #include sys/sysctl.h
Re: [Qemu-devel] [PATCH 1/3] Add FreeBSD/ppc host ppc_init_cacheline_sizes() implementation.
On Tue, Feb 16, 2010 at 09:52:50AM +0300, malc wrote: On Mon, 15 Feb 2010, Juergen Lock wrote: On Mon, Feb 15, 2010 at 06:16:07AM +0300, malc wrote: On Sun, 14 Feb 2010, Juergen Lock wrote: Submitted by: Andreas Tobler andre...@fgznet.ch Signed-off-by: Juergen Lock n...@jelal.kn-bremen.de --- a/cache-utils.c +++ b/cache-utils.c @@ -57,6 +57,23 @@ } #endif +#if defined(__FreeBSD__) || defined(__FreeBSD_kernel__) __FreeBSD_kernel__ is for something like Debian/kFreeBSD? Yep, it is. Support for it was added to qemu some time ago so I figured I should do the same. Perhaps it would be better to avoid this particular ifdefery and just go with _CALL_SYSV, can you verify that: ~$ gcc -E -dM -x c /dev/null | grep SYSV yields #define _CALL_SYSV 1 on FreeBSD and Debian/kFreeBSD? Nope, not found on FreeBSD. (Also I would kinda doubt that sysctl is standardized?) Cheers, Juergen
[Qemu-devel] Re: [PATCH 1/3] Add FreeBSD/ppc host ppc_init_cacheline_sizes() implementation.
On Tue, Feb 16, 2010 at 08:50:49PM +0100, Paolo Bonzini wrote:
Nope, not found on FreeBSD. (Also I would kinda doubt that sysctl is
standardized?)
_CALL_SYSV means that calling convention is SysV one, nothing to do with
sysctl, and i wanted you/patch author to run it on FreeBSD/PPC...
Yes, one of _CALL_SYSV, _CALL_AIX, _CALL_DARWIN is always defined by GCC
on PPC. Don't know about other compilers.
Aaah, now I understand, malc meant this patch:
[PATCH 3/3] Add FreeBSD/ppc host
TCG_TARGET_CALL_{ALIGN_ARGS,STACK_OFFSET} definitions.
not the ppc_init_cacheline_sizes() one, right? :)
Anyway, I'll pass the question on...
Juergen
[Qemu-devel] Re: [PATCH 3/3] Add FreeBSD/ppc host TCG_TARGET_CALL_{ALIGN_ARGS,STACK_OFFSET} definitions.
On Sun, Feb 14, 2010 at 09:13:31PM +0100, Juergen Lock wrote:
Submitted by: Andreas Tobler andre...@fgznet.ch
Signed-off-by: Juergen Lock n...@jelal.kn-bremen.de
--- a/tcg/ppc/tcg-target.h
+++ b/tcg/ppc/tcg-target.h
@@ -69,7 +69,7 @@
#define TCG_TARGET_CALL_STACK_OFFSET 24
#elif defined _AIX
#define TCG_TARGET_CALL_STACK_OFFSET 52
-#elif defined __linux__
+#elif defined __linux__ || defined __FreeBSD__ || defined(__FreeBSD_kernel__)
#define TCG_TARGET_CALL_ALIGN_ARGS 1
#define TCG_TARGET_CALL_STACK_OFFSET 8
#else
New version using ppc _CALL_* definitions after malc's comments:
Signed-off-by: Juergen Lock n...@jelal.kn-bremen.de
--- a/tcg/ppc/tcg-target.h
+++ b/tcg/ppc/tcg-target.h
@@ -65,11 +65,11 @@ enum {
/* used for function call generation */
#define TCG_REG_CALL_STACK TCG_REG_R1
#define TCG_TARGET_STACK_ALIGN 16
-#if defined __APPLE__
+#if defined _CALL_DARWIN
#define TCG_TARGET_CALL_STACK_OFFSET 24
-#elif defined _AIX
+#elif defined _CALL_AIX
#define TCG_TARGET_CALL_STACK_OFFSET 52
-#elif defined __linux__
+#elif defined _CALL_SYSV
#define TCG_TARGET_CALL_ALIGN_ARGS 1
#define TCG_TARGET_CALL_STACK_OFFSET 8
#else
[Qemu-devel] Re: [PATCH 1/3] Add FreeBSD/ppc host ppc_init_cacheline_sizes() implementation.
On Tue, Feb 16, 2010 at 09:34:12PM +0100, Juergen Lock wrote:
On Tue, Feb 16, 2010 at 08:50:49PM +0100, Paolo Bonzini wrote:
Nope, not found on FreeBSD. (Also I would kinda doubt that sysctl is
standardized?)
_CALL_SYSV means that calling convention is SysV one, nothing to do with
sysctl, and i wanted you/patch author to run it on FreeBSD/PPC...
Yes, one of _CALL_SYSV, _CALL_AIX, _CALL_DARWIN is always defined by GCC
on PPC. Don't know about other compilers.
Aaah, now I understand, malc meant this patch:
[PATCH 3/3] Add FreeBSD/ppc host
TCG_TARGET_CALL_{ALIGN_ARGS,STACK_OFFSET} definitions.
not the ppc_init_cacheline_sizes() one, right? :)
Anyway, I'll pass the question on...
Yup, confirmed, _CALL_SYSV is defined on FreeBSD/ppc.
Re: [Qemu-devel] [PATCH 1/3] Add FreeBSD/ppc host ppc_init_cacheline_sizes() implementation.
On Mon, Feb 15, 2010 at 06:15:41AM +0300, malc wrote:
On Sun, 14 Feb 2010, Juergen Lock wrote:
Submitted by: Andreas Tobler andre...@fgznet.ch
Signed-off-by: Juergen Lock n...@jelal.kn-bremen.de
--- a/cache-utils.c
+++ b/cache-utils.c
@@ -57,6 +57,23 @@
}
#endif
+#if defined(__FreeBSD__) || defined(__FreeBSD_kernel__)
+#include stdio.h
+#include sys/types.h
+#include sys/sysctl.h
+
+static void ppc_init_cacheline_sizes(void)
+{
+size_t len = 4;
+unsigned cacheline;
+
+sysctlbyname (machdep.cacheline_size, cacheline, len, NULL, 0);
Error handling missing.
Mmh I suspect thats a sysctl that simply can't fail but of course checking
still doesn't hurt:
Submitted by: Andreas Tobler andre...@fgznet.ch
Signed-off-by: Juergen Lock n...@jelal.kn-bremen.de
--- a/cache-utils.c
+++ b/cache-utils.c
@@ -57,6 +57,27 @@ static void ppc_init_cacheline_sizes(voi
}
#endif
+#if defined(__FreeBSD__) || defined(__FreeBSD_kernel__)
+#include stdio.h
+#include sys/types.h
+#include sys/sysctl.h
+
+static void ppc_init_cacheline_sizes(void)
+{
+size_t len = 4;
+unsigned cacheline;
+
+if (sysctlbyname (machdep.cacheline_size, cacheline, len, NULL, 0)) {
+fprintf(stderr, sysctlbyname machdep.cacheline_size failed: %s\n,
+strerror(errno));
+exit(1);
+}
+
+qemu_cache_conf.dcache_bsize = cacheline;
+qemu_cache_conf.icache_bsize = cacheline;
+}
+#endif
+
#ifdef __linux__
void qemu_cache_utils_init(char **envp)
{
Re: [Qemu-devel] [PATCH 1/3] Add FreeBSD/ppc host ppc_init_cacheline_sizes() implementation.
On Mon, Feb 15, 2010 at 06:16:07AM +0300, malc wrote: On Sun, 14 Feb 2010, Juergen Lock wrote: Submitted by: Andreas Tobler andre...@fgznet.ch Signed-off-by: Juergen Lock n...@jelal.kn-bremen.de --- a/cache-utils.c +++ b/cache-utils.c @@ -57,6 +57,23 @@ } #endif +#if defined(__FreeBSD__) || defined(__FreeBSD_kernel__) __FreeBSD_kernel__ is for something like Debian/kFreeBSD? Yep, it is. Support for it was added to qemu some time ago so I figured I should do the same. Cheers, Juergen
[Qemu-devel] [PATCH 3/3] Add FreeBSD/ppc host TCG_TARGET_CALL_{ALIGN_ARGS,STACK_OFFSET} definitions.
Submitted by: Andreas Tobler andre...@fgznet.ch Signed-off-by: Juergen Lock n...@jelal.kn-bremen.de --- a/tcg/ppc/tcg-target.h +++ b/tcg/ppc/tcg-target.h @@ -69,7 +69,7 @@ #define TCG_TARGET_CALL_STACK_OFFSET 24 #elif defined _AIX #define TCG_TARGET_CALL_STACK_OFFSET 52 -#elif defined __linux__ +#elif defined __linux__ || defined __FreeBSD__ || defined(__FreeBSD_kernel__) #define TCG_TARGET_CALL_ALIGN_ARGS 1 #define TCG_TARGET_CALL_STACK_OFFSET 8 #else
[Qemu-devel] [PATCH 1/3] Add FreeBSD/ppc host ppc_init_cacheline_sizes() implementation.
Submitted by: Andreas Tobler andre...@fgznet.ch
Signed-off-by: Juergen Lock n...@jelal.kn-bremen.de
--- a/cache-utils.c
+++ b/cache-utils.c
@@ -57,6 +57,23 @@
}
#endif
+#if defined(__FreeBSD__) || defined(__FreeBSD_kernel__)
+#include stdio.h
+#include sys/types.h
+#include sys/sysctl.h
+
+static void ppc_init_cacheline_sizes(void)
+{
+size_t len = 4;
+unsigned cacheline;
+
+sysctlbyname (machdep.cacheline_size, cacheline, len, NULL, 0);
+
+qemu_cache_conf.dcache_bsize = cacheline;
+qemu_cache_conf.icache_bsize = cacheline;
+}
+#endif
+
#ifdef __linux__
void qemu_cache_utils_init(char **envp)
{
[Qemu-devel] [PATCH 2/3] Add FreeBSD/ppc host ucontext definitions.
Submitted by: Andreas Tobler andre...@fgznet.ch
Signed-off-by: Juergen Lock n...@jelal.kn-bremen.de
--- a/cpu-exec.c
+++ b/cpu-exec.c
@@ -933,6 +933,20 @@
# define TRAP_sig(context) REG_sig(trap, context)
#endif /* linux */
+#if defined(__FreeBSD__) || defined(__FreeBSD_kernel__)
+#include ucontext.h
+# define IAR_sig(context) ((context)-uc_mcontext.mc_srr0)
+# define MSR_sig(context) ((context)-uc_mcontext.mc_srr1)
+# define CTR_sig(context) ((context)-uc_mcontext.mc_ctr)
+# define XER_sig(context) ((context)-uc_mcontext.mc_xer)
+# define LR_sig(context) ((context)-uc_mcontext.mc_lr)
+# define CR_sig(context) ((context)-uc_mcontext.mc_cr)
+/* Exception Registers access */
+# define DAR_sig(context) ((context)-uc_mcontext.mc_dar)
+# define DSISR_sig(context)((context)-uc_mcontext.mc_dsisr)
+# define TRAP_sig(context) ((context)-uc_mcontext.mc_exc)
+#endif /* __FreeBSD__|| __FreeBSD_kernel__ */
+
#ifdef __APPLE__
# include sys/ucontext.h
typedef struct ucontext SIGCONTEXT;
@@ -962,7 +976,11 @@
void *puc)
{
siginfo_t *info = pinfo;
+#if defined(__FreeBSD__) || defined(__FreeBSD_kernel__)
+ucontext_t *uc = puc;
+#else
struct ucontext *uc = puc;
+#endif
unsigned long pc;
int is_write;
[Qemu-devel] [PATCH 0/3] FreeBSD/ppc host patches
Hi!
These are patches submitted by Andreas Tobler to get qemu working on
FreeBSD/ppc hosts. There is one other patch to ppc.ld that's needed
because of FreeBSD's older binutils that probably should stay
FreeBSD-specific, here is the link to it in FreeBSD ports:
http://www.freebsd.org/cgi/cvsweb.cgi/ports/emulators/qemu-devel/files/patch-ppc.ld
1. Add FreeBSD/ppc host ppc_init_cacheline_sizes() implementation.
2. Add FreeBSD/ppc host ucontext definitions.
3. Add FreeBSD/ppc host TCG_TARGET_CALL_{ALIGN_ARGS,STACK_OFFSET} definitions.
[Qemu-devel] [PATCH] [For stable-0.12] Sync OSS_GETVERSION handling with head
As suggested by Andreas Färber, here is a cumulative patch that syncs
OSS_GETVERSION handling with head by merging the following commits:
1. oss: issue OSS_GETVERSION ioctl only when needed
6d246526ce3c145b2831285def6983f5de6190d3
2. oss: fix fragment setting
3d709fe73a77c40e263b3af6e650fd4b519c3562
3. Workaround for broken OSS_GETVERSION on FreeBSD, part two
72ff25e4e98d6dba9286d032b9ff5432553bbad5
Signed-off-by: Juergen Lock n...@jelal.kn-bremen.de
--- a/audio/ossaudio.c
+++ b/audio/ossaudio.c
@@ -38,6 +38,10 @@
#define AUDIO_CAP oss
#include audio_int.h
+#if defined OSS_GETVERSION defined SNDCTL_DSP_POLICY
+#define USE_DSP_POLICY
+#endif
+
typedef struct OSSVoiceOut {
HWVoiceOut hw;
void *pcm_buf;
@@ -236,14 +240,39 @@ static void oss_dump_info (struct oss_pa
}
#endif
+#ifdef USE_DSP_POLICY
+static int oss_get_version (int fd, int *version, const char *typ)
+{
+if (ioctl (fd, OSS_GETVERSION, version)) {
+#if defined(__FreeBSD__) || defined(__FreeBSD_kernel__)
+/*
+ * Looks like atm (20100109) FreeBSD knows OSS_GETVERSION
+ * since 7.x, but currently only on the mixer device (or in
+ * the Linuxolator), and in the native version that part of
+ * the code is in fact never reached so the ioctl fails anyway.
+ * Until this is fixed, just check the errno and if its what
+ * FreeBSD's sound drivers return atm assume they are new enough.
+ */
+if (errno == EINVAL) {
+*version = 0x04;
+return 0;
+}
+#endif
+oss_logerr2 (errno, typ, Failed to get OSS version\n);
+return -1;
+}
+return 0;
+}
+#endif
+
static int oss_open (int in, struct oss_params *req,
struct oss_params *obt, int *pfd)
{
int fd;
-int version;
int oflags = conf.exclusive ? O_EXCL : 0;
audio_buf_info abinfo;
int fmt, freq, nchannels;
+int setfragment = 1;
const char *dspname = in ? conf.devpath_in : conf.devpath_out;
const char *typ = in ? ADC : DAC;
@@ -281,27 +310,30 @@ static int oss_open (int in, struct oss_
goto err;
}
-if (ioctl (fd, OSS_GETVERSION, version)) {
-oss_logerr2 (errno, typ, Failed to get OSS version\n);
-version = 0;
-}
+#ifdef USE_DSP_POLICY
+if (conf.policy = 0) {
+int version;
-if (conf.debug) {
-dolog (OSS version = %#x\n, version);
-}
+if (!oss_get_version (fd, version, typ)) {
+if (conf.debug) {
+dolog (OSS version = %#x\n, version);
+}
-#ifdef SNDCTL_DSP_POLICY
-if (conf.policy = 0 version = 0x04) {
-int policy = conf.policy;
-if (ioctl (fd, SNDCTL_DSP_POLICY, policy)) {
-oss_logerr2 (errno, typ, Failed to set timing policy to %d\n,
- conf.policy);
-goto err;
+if (version = 0x04) {
+int policy = conf.policy;
+if (ioctl (fd, SNDCTL_DSP_POLICY, policy)) {
+oss_logerr2 (errno, typ,
+ Failed to set timing policy to %d\n,
+ conf.policy);
+goto err;
+}
+setfragment = 0;
+}
}
}
-else
#endif
-{
+
+if (setfragment) {
int = (req-nfrags 16) | ctz32 (req-fragsize);
if (ioctl (fd, SNDCTL_DSP_SETFRAGMENT, )) {
oss_logerr2 (errno, typ, Failed to set buffer length (%d, %d)\n,
@@ -857,7 +889,7 @@ static struct audio_option oss_options[]
.valp = conf.exclusive,
.descr = Open device in exclusive mode (vmix wont work)
},
-#ifdef SNDCTL_DSP_POLICY
+#ifdef USE_DSP_POLICY
{
.name = POLICY,
.tag = AUD_OPT_INT,
Re: [Qemu-devel] [PATCH] Workaround for broken OSS_GETVERSION on FreeBSD, part two
On Sun, Jan 10, 2010 at 01:40:18AM +0300, malc wrote: On Sat, 9 Jan 2010, Juergen Lock wrote: Turns out on those versions of FreeBSD (= 7.x) that know OSS_GETVERSION the ioctl doesn't actually work yet (except in the Linuxolator), so if building on FreeBSD fall back to using SOUND_VERSION as defined in sys/soundcard.h (which atm is 0x04) if the ioctl is defined but fails. I've changed the code in the meantime, so this wont apply. Also this is wrong version is dynamic by nature, if someone runs qemu on FreeBSD where SOUND_VERSION is less than 4, things will get ugly. Yes but running packages on an older FreeBSD version than they were built on isn't really supported (read: won't work, especially if its an older major branch too like in this case.) On top of that, SOUND_VERSION was bumped to 0x04 for FreeBSD 7.0 already (the commit is from 2006), and FreeBSD 6 is nothing more than a legacy branch now that I think few ppl still use (or at least for things like qemu), the last release was FreeBSD 8.0... In the new code i mentioned one can opt for not considering POLICY failure a hard error and proceed with a SETFRAGMENT path, which is what i would prefer to see on FreeBSD. Anyway, you are the qemu audio maintainer, so if thats really what you prefer, fine with me. :) Cheers, Juergen
Re: [Qemu-devel] [PATCH] Fix build if OSS_GETVERSION is not defined
On Sat, Jan 09, 2010 at 12:33:44AM +0300, malc wrote:
On Fri, 8 Jan 2010, Juergen Lock wrote:
On Fri, Jan 08, 2010 at 11:27:13AM +0300, malc wrote:
On Thu, 7 Jan 2010, Juergen Lock wrote:
In this case it was missing on FreeBSD = 6.x (Which also doesn't have
SNDCTL_DSP_POLICY yet so the version doesn't get used anyway.)
I've commited slightly different fix for the issue, thanks.
Hmm looking at the last hunk of the commit,
[...]
@@ -289,9 +292,17 @@ static int oss_open (int in, struct oss_params *req,
if (conf.debug) {
dolog (OSS version = %#x\n, version);
}
+#endif
#ifdef SNDCTL_DSP_POLICY
-if (conf.policy = 0 version = 0x04) {
+if (conf.policy = 0
+#ifdef OSS_GETVERSION
+ version = 0x04
+#else
+0
...these last two lines (#else and 0) probably should go, I dont think
the compiler likes whitespace between digits. :)
Uh, yeah, my bad, sorry, hopefuly fixed now..
Yeah looking better now... Thanx!
+#endif
+)
+{
int policy = conf.policy;
if (ioctl (fd, SNDCTL_DSP_POLICY, policy)) {
oss_logerr2 (errno, typ, Failed to set timing policy to
%d\n,
--
1.6.6
And also I forgot to say this is stable-0.12 material too.
You really should talk to the people who know what that means :)
Oh sorry I should have guessed not all committers do merges to stable
branches... Anthony? :)
Greets,
Juergen
Re: [Qemu-devel] [PATCH] Fix build if OSS_GETVERSION is not defined
On Sat, Jan 09, 2010 at 03:03:43PM +0100, Andreas Färber wrote: Am 09.01.2010 um 14:45 schrieb Juergen Lock: On Sat, Jan 09, 2010 at 12:33:44AM +0300, malc wrote: On Fri, 8 Jan 2010, Juergen Lock wrote: And also I forgot to say this is stable-0.12 material too. You really should talk to the people who know what that means :) Oh sorry I should have guessed not all committers do merges to stable branches... Anthony? :) In this case you should probably resubmit one accumulated top-level patch marked [PATCH][For stable-0.12] or similar (instead of having two commits cherry-picked). Ok I can do that, but first I have another patch to the same code, turns out the ioctl doesn't actually work yet on FreeBSD even if it is defined... Cheers, Juergen
[Qemu-devel] [PATCH] Workaround for broken OSS_GETVERSION on FreeBSD, part two
Turns out on those versions of FreeBSD (= 7.x) that know OSS_GETVERSION
the ioctl doesn't actually work yet (except in the Linuxolator), so if
building on FreeBSD fall back to using SOUND_VERSION as defined in
sys/soundcard.h (which atm is 0x04) if the ioctl is defined but
fails.
Signed-off-by: Juergen Lock n...@jelal.kn-bremen.de
--- a/audio/ossaudio.c
+++ b/audio/ossaudio.c
@@ -289,8 +289,25 @@ static int oss_open (int in, struct oss_
#ifdef USE_DSP_POLICY
if (ioctl (fd, OSS_GETVERSION, version)) {
+#ifdef __FreeBSD__
+/*
+* Looks like atm (20100109) FreeBSD knows OSS_GETVERSION
+* since 7.x, but currently only on the mixer device (or in
+* the Linuxolator), and in the native version that part of
+* the code is in fact never reached so the ioctl fails anyway.
+* But since it just (attempts to) return SOUND_VERSION as
+* defined in sys/soundcard.h we can fall back to getting it
+* from there. (On FreeBSD, /usr/include is part of the base
+* system which is assumed to be always in sync with the kernel.)
+* XXX What if the user runs the original OSS from ports instead
+* of FreeBSD's own code? Well I hope we can assume the ioctl
+* works there... :)
+*/
+version = SOUND_VERSION;
+#else
oss_logerr2 (errno, typ, Failed to get OSS version\n);
version = 0;
+#endif
}
if (conf.debug) {
[Qemu-devel] [PATCH] Fix build if OSS_GETVERSION is not defined
In this case it was missing on FreeBSD = 6.x (Which also doesn't have
SNDCTL_DSP_POLICY yet so the version doesn't get used anyway.)
Signed-off-by: Juergen Lock n...@jelal.kn-bremen.de
--- a/audio/ossaudio.c
+++ b/audio/ossaudio.c
@@ -240,7 +240,7 @@ static int oss_open (int in, struct oss_
struct oss_params *obt, int *pfd)
{
int fd;
-int version;
+int version = 0;
int oflags = conf.exclusive ? O_EXCL : 0;
audio_buf_info abinfo;
int fmt, freq, nchannels;
@@ -281,10 +281,12 @@ static int oss_open (int in, struct oss_
goto err;
}
+#ifdef OSS_GETVERSION
if (ioctl (fd, OSS_GETVERSION, version)) {
oss_logerr2 (errno, typ, Failed to get OSS version\n);
version = 0;
}
+#endif
if (conf.debug) {
dolog (OSS version = %#x\n, version);
[Qemu-devel] [PATCH:] Fix a make -j race
Make libuser.a depend on $(GENERATED_HEADERS) too so make -j won't start building it before the headers exist. (There may be more bugs like this but at least this makes (g)make -j4 started from scratch on a quadcore now always complete here again.) Signed-off-by: Juergen Lock n...@jelal.kn-bremen.de --- a/Makefile +++ b/Makefile @@ -79,7 +79,7 @@ $(filter %-softmmu,$(SUBDIR_RULES)): lib $(filter %-user,$(SUBDIR_RULES)): libuser.a -libuser.a: +libuser.a: $(GENERATED_HEADERS) $(call quiet-command,$(MAKE) $(SUBDIR_MAKEFLAGS) -C libuser V=$(V) TARGET_DIR=libuser/ all,) ROMSUBDIR_RULES=$(patsubst %,romsubdir-%, $(ROMS))
[Qemu-devel] FreeBSD qemu-devel 0.12.0-rc2 port update available for testing
Hi! I updated my git head snapshot qemu-devel port update to 0.12.0-rc2 today (that was just announced: http://lists.gnu.org/archive/html/qemu-devel/2009-12/msg01514.html - the Subject says rc1 but in fact its rc2) so people can test that version on FreeBSD more easily: http://people.freebsd.org/~nox/qemu/qemu-devel-0.12.0-rc2.patch resp. http://people.freebsd.org/~nox/qemu/qemu-devel-0.12.0-rc2.shar (As mentioned before 0.11 was the last qemu branch that supported kqemu so this is probably only interesting for those FreeBSD users that want to emulate non-x86 guests or when performance doesn't matter. But the others are probably already moving to virtualbox now anyway... :) I have updated the FreeBSD pcap patch just enough so that it still runs (it probably will never be committed upstream anyway since Linux pcap doesn't have BIOCFEEDBACK i.e. can't talk to the host, only to other machines on the network) and I still see this weird issue here that packets `sometimes' are only processed with a delay (when the nic is otherwise idle?), i.e. pinging the host or another box on the lan with e.g. -i5 from the guest sees many packets with 5000ms roundtrip time. Can anyone else reproduce this or is that `just me'? This is on stable/8 now (amd64) but it also happened with earlier versions, tested with qemu 8.0-RELEASE-i386-dvd1.iso -m 256 -net nic,model=e1000 -net pcap,ifname=em0 via fixit-cdrom. And this is most likely pcap related, I don't see anything like it with tap networking. Cheers, Juergen
[Qemu-devel] [PATCH] Allow build of linuxboot.S with old assemblers
In the spirit of ff56954baf9cfab5cbbe18d10b4a09e4a17f39a8, fix the build of linuxboot.S with old as(1) (as found in some BSD base systems) by emitting the bytes of the insn it doesn't like instead. Signed-off-by: Juergen Lock n...@jelal.kn-bremen.de --- a/pc-bios/optionrom/optionrom.h +++ b/pc-bios/optionrom/optionrom.h @@ -66,7 +66,10 @@ outw%ax, (%dx); \ mov $BIOS_CFG_IOPORT_DATA, %dx; \ cld;\ - rep insb(%dx), %es:(%edi); + /* old as(1) doesn't like this insn so emit the bytes instead: \ + rep insb(%dx), %es:(%edi); \ + */ \ + .dc.b 0x67,0xf3,0x6c #define OPTION_ROM_START \ .code16; \
[Qemu-devel] [PATCH 1/3] Fix tap breakage on BSD hosts (no IFF_VNET_HDR)
net/tap-bsd.c was assuming IFF_VNET_HDR was always available, which
I think isn't true on any BSD.
Signed-off-by: Juergen Lock n...@jelal.kn-bremen.de
--- a/net/tap-bsd.c
+++ b/net/tap-bsd.c
@@ -87,6 +87,17 @@ int tap_open(char *ifname, int ifname_si
dev = devname(s.st_rdev, S_IFCHR);
pstrcpy(ifname, ifname_size, dev);
+if (*vnet_hdr) {
+/* BSD doesn't have IFF_VNET_HDR */
+*vnet_hdr = 0;
+
+if (vnet_hdr_required !*vnet_hdr) {
+qemu_error(vnet_hdr=1 requested, but no kernel
+ support for IFF_VNET_HDR available);
+close(fd);
+return -1;
+}
+}
fcntl(fd, F_SETFL, O_NONBLOCK);
return fd;
}
[Qemu-devel] [PATCH 3/3] tap-bsd: handle ifname on FreeBSD hosts
Handle ifname on FreeBSD hosts; if no ifname is given, always start
the search from tap0. (Simplified/cleaned up version of what has been
in the FreeBSD ports for a long time.)
Signed-off-by: Juergen Lock n...@jelal.kn-bremen.de
--- a/net/tap-bsd.c
+++ b/net/tap-bsd.c
@@ -49,11 +49,39 @@ int tap_open(char *ifname, int ifname_si
char *dev;
struct stat s;
+#ifdef __FreeBSD__
+/* if no ifname is given, always start the search from tap0. */
+int i;
+char dname[100];
+
+for (i = 0; i 10; i++) {
+if (*ifname) {
+snprintf(dname, sizeof dname, /dev/%s, ifname);
+} else {
+snprintf(dname, sizeof dname, /dev/tap%d, i);
+}
+TFR(fd = open(dname, O_RDWR));
+if (fd = 0) {
+break;
+}
+else if (errno == ENXIO || errno == ENOENT) {
+break;
+}
+if (*ifname) {
+break;
+}
+}
+if (fd 0) {
+qemu_error(warning: could not open %s (%s): no virtual network
emulation\n, dname, strerror(errno));
+return -1;
+}
+#else
TFR(fd = open(/dev/tap, O_RDWR));
if (fd 0) {
fprintf(stderr, warning: could not open /dev/tap: no virtual network
emulation\n);
return -1;
}
+#endif
fstat(fd, s);
dev = devname(s.st_rdev, S_IFCHR);
[Qemu-devel] [PATCH 0/3] Misc tap fixes found on FreeBSD
Hi! I made another experimental FreeBSD qemu git snapshot port update (see other mail), and came up with these patches when getting tap back to working order again: 1. Fix tap breakage on BSD hosts (no IFF_VNET_HDR) 2. Avoid segfault on net_tap_init() failure 3. tap-bsd: handle ifname on FreeBSD hosts Signed-off-by: Juergen Lock n...@jelal.kn-bremen.de
[Qemu-devel] [PATCH 2/3] Avoid segfault on net_tap_init() failure
Check for fd == -1 there.
Signed-off-by: Juergen Lock n...@jelal.kn-bremen.de
--- a/net/tap.c
+++ b/net/tap.c
@@ -400,6 +400,9 @@ int net_init_tap(QemuOpts *opts, Monitor
}
fd = net_tap_init(opts, vnet_hdr);
+if (fd == -1) {
+return -1;
+}
}
s = net_tap_fd_init(vlan, tap, name, fd, vnet_hdr);
Re: [Qemu-devel] Re: playing with qemu usermode emulation on FreeBSD...
On Sun, Oct 18, 2009 at 09:26:00PM +0300, Blue Swirl wrote:
On Sat, Oct 17, 2009 at 1:34 AM, Juergen Lock n...@jelal.kn-bremen.de wrote:
On Wed, Oct 14, 2009 at 12:19:32AM +0200, Juergen Lock wrote:
On Tue, Oct 13, 2009 at 12:20:58AM +0200, Juergen Lock wrote:
On Mon, Oct 12, 2009 at 10:55:24PM +0300, Blue Swirl wrote:
On Mon, Oct 12, 2009 at 1:18 AM, Juergen Lock
n...@jelal.kn-bremen.de wrote:
On Thu, Oct 08, 2009 at 12:05:49AM +0200, Juergen Lock wrote:
I recently noticed there are x86 bsd-user targets now (yeah I
totally
missed those commits...) and now got it working a tiny little bit:
I can run
qemu-x86_64 -bsd freebsd /rescue/echo foo bar
here on FreeBSD 8/amd64 and it echoes foo bar as expected, but
segfaults afterwards. :) (in pthread_setcancelstate() invoked from
a guest write() syscall, in case anyone is wondering.) Other things
I tried either exit with errors or segfault as well, and i386 hosts
probably still don't work at all yet. (qemu-i386 here on amd64 does
at least something, but probably needs lock_user() treatment for all
kinds of syscalls, I only tried adding that for sysctl so far.)
Anyway, here is an emulators/qemu-devel git head snapshot port
update with my current patches (files/patch-bsd-user), feel free to
test/debug/improve:
http://people.freebsd.org/~nox/qemu/qemu-devel-20091007.patch
(For the folks reading this on the qemu list: I shall start doing
`proper' patch submissions later, this is more for the FreeBSD folks
and because I was asked to send what I have...)
New version at the same place, which now runs FreeBSD/{i386,sparc64}
/rescue/echo on FreeBSD/amd64, the FreeBSD/amd64 target now segfaults
in pthread_setcancelstate() invoked from the final writev() tho.
Oh and I also uploaded the snapshot tarball so others can now
actually
build the port too... :) And I have switched to the cpu-exec.c patch
posted by Aleksej Saushev on the qemu list and added back amd64
code there.
Here is the bsd-user patch again:
Please add Signed-off-by: line and use 'diff -u' (or preferably git
diff).
Well I wasn't expecting this diff to be committed just yet anyway,
it's still more a wip version...
+ if (1 /* bsd_type == target_freebsd */)
+ regs-rdi = infop-start_stack;
Why the if and comment?
+ if (1 /* bsd_type == target_freebsd */) {
+ regs-u_regs[8] = infop-start_stack;
+ regs-u_regs[11] = infop-start_stack;
Same here.
Because bsd_type isn't available at these places in the code but
probably should be checked, I still wanted to fix that. (Maybe
make it global?)
I still haven't fixed this...
case 0x100:
+ /* FreeBSD uses 0x141 for syscalls too */
+ case 0x141:
+ if (bsd_type != target_freebsd)
+ goto badtrap;
You are now also trapping on case 0x100 if bsd_type != target_freebsd,
which probably breaks other BSDs.
Right, thats broken, the 0x141 case should come before the 0x100
here of course.
...but this I just fixed, and I added the multiboot.S patch, and
fixed the port's cdrom dma disable knob (files/cdrom-dma-patch).
(And I added the cpu-exec.c whitspace fix that was already in the
patch I posted in the BSD support thread.)
New version at the same place,
http://people.freebsd.org/~nox/qemu/qemu-devel-20091007.patch
and I now also made a shar of the patched port:
http://people.freebsd.org/~nox/qemu/qemu-devel-20091007.shar
Updated again, among other things I added basic FreeBSD sysarch(2)
handling, fixed syscall errno return (I had added code to set the
carry bit for the x86 target before but the sign of the returned errno
was still wrong), and I finally fixed the if (1) above (made bsd_type
global.)
And, I now can run FreeBSD/amd64 /bin/sh and vim on same! :) (zsh
not yet tho.)
Oh and Toni tested taking FreeBSD/i386's default linker script,
changing only the load address to 0x6000 as in qemu's and,
using that as i386.ld, he now can run qemu-i386 on FreeBSD/i386 with
simple executables too... See files/patch-bsd-user-ld in the shar,
which I also now moved the x86_64.ld patch to that I had talked about
earlier. It probably can't be used everywhere as is tho since it has:
OUTPUT_FORMAT(elf32-i386-freebsd, elf32-i386-freebsd,
elf32-i386-freebsd)
(and I also don't know if the one currently in the tree has other
features that are needed at least on Linux, any linker gurus care
to comment?)
Here is the rest of the bsd-user patches again (files/patch-bsd-user
in the shar), if you think they are ready to commit I'm not against it
anymore :), comments are also
[Qemu-devel] vmwarevga regression (broken with two Linux and FreeBSD guests)
Hmm. Looks like the latest vmwarevga commits broke *ix/xorg guests. I tested the 2008-03-11 cvs snapshot with sidux-2008-01-200803010113-nyx_pre1-kde-lite-i386.iso (debian sid based Linux livecd) and FreeSBIE-2.0.1-RELEASE.iso (FreeBSD based livecd), on sidux xorg said: (WW) INVALID MEM ALLOCATION b: 0xf000 e: 0xf07f correcting and the xserver display was garbage, and on FreeSBIE xorg didn't even start, showing a similar complaint. (both with Driver vmware in xorg.conf) Do the latest commits need a bios update maybe? Anyway, a 2008-03-02 snapshot works (now committed as FreeBSD qemu-devel port), at least for these two guests (I don't have a windows guest here atm.) FreeSBIE even was able to attach ed0 (the default ne2kpci nic) as well as the emulated es1370 soundcard, which didn't work previously when using vmwarevga. Just thought I'd mention... :) Juergen
[Qemu-devel] patch: tcg bug (was: Re: qemu 2008-03-02 snapshot FreeBSD 7.0/amd64 guest regression) (tcg?)
On Mon, Mar 03, 2008 at 01:01:34AM +0100, Juergen Lock wrote: On Sun, Mar 02, 2008 at 09:47:02PM +0100, Juergen Lock wrote: Hi! I've prepared a FreeBSD qemu-devel port update, as already mentioned on the freebsd-emulation list, and found the FreeBSD 7.0/amd64 isos now pagefault repeatedly, saying: panic: page fault cpuid = 0 kernel trap 12 with interrupts disabled Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x20 fault code = supervisor read data, page not present instruction pointer = 0x8:0x8046c704 trap number = 12 frame pointer = 0x10:0x0 ... 0x8046c704 in the 7.0-RELEASE kernel used on the isos is in _thread_lock_flags: (kgdb) disassemble _thread_lock_flags Dump of assembler code for function _thread_lock_flags: 0x8046c6e0 _thread_lock_flags+0: push %r14 0x8046c6e2 _thread_lock_flags+2: mov%rdi,%r14 0x8046c6e5 _thread_lock_flags+5: push %r13 0x8046c6e7 _thread_lock_flags+7: push %r12 0x8046c6e9 _thread_lock_flags+9: push %rbp 0x8046c6ea _thread_lock_flags+10: push %rbx 0x8046c6eb _thread_lock_flags+11: mov%gs:0x0,%r13 0x8046c6f4 _thread_lock_flags+20: xor%r12d,%r12d 0x8046c6f7 _thread_lock_flags+23: callq 0x8071df80 spinlock_enter 0x8046c6fc _thread_lock_flags+28: mov(%r14),%rbp 0x8046c6ff _thread_lock_flags+31: mov$0x4,%eax 0x8046c704 _thread_lock_flags+36: lock cmpxchg %r13,0x20(%rbp) 0x8046c70a _thread_lock_flags+42: sete %al 0x8046c70d _thread_lock_flags+45: test %al,%al 0x8046c70f _thread_lock_flags+47: jne0x8046c799 _thread_lock_flags+185 0x8046c715 _thread_lock_flags+53: mov0x20(%rbp),%rdx 0x8046c719 _thread_lock_flags+57: cmp%r13,%rdx 0x8046c71c _thread_lock_flags+60: je 0x8046c7cd _thread_lock_flags+237 0x8046c722 _thread_lock_flags+66: callq 0x8071c4e0 spinlock_exit ---Type return to continue, or q return to quit--- 0x8046c727 _thread_lock_flags+71: jmp0x8046c73c _thread_lock_flags+92 0x8046c729 _thread_lock_flags+73: data16 ... so this looks like either %rbp is indeed zero or that cmpxchg insn isnt getting correctly translated. If you want to reproduce just boot the 35 MB 7.0-RELEASE-amd64-bootonly.iso in qemu-system-x86_64 (without kqemu); you can find mirrors via http://mirrorlist.freebsd.org/ (search for isos, amd64 architecture, I used 7.0 as you can see.) Oh, if you want to look at the live kernel you can boot the 7.0-RELEASE-amd64-livefs.iso in 0.9.1 with the previously mentioned patch (see http://www.nabble.com/forum/ViewPost.jtp?post=14921171 ), select fixit-cdrom in the menu that comes up after choosing the keyboard layout, and run `kgdb /dist/boot/kernel/kernel /dev/mem'. Update: looks like the bug is i386 host only, at least I got a report of amd64 host working. (will try to confirm later...) Ok, confirmed. Tho the real problem was another fault that I must have overlooked at first: There's a movsbq at (in this kernel) vm_phys_free_pages+4 that gets sign extended wrong, 1 gets turned into 0x10001 in %r8 at vm_phys_free_pages+9, which causes the offset into vm_phys_segs (0x80a68340) to end up as 0x200020 instead of 0x20, causing the first fault at vm_phys_free_pages+43, which then only seems to trigger the repeated faults mentioned above. (kgdb) disassemble vm_phys_free_pages Dump of assembler code for function vm_phys_free_pages: 0x80692ae0 vm_phys_free_pages+0: push %r12 0x80692ae2 vm_phys_free_pages+2: push %rbp 0x80692ae3 vm_phys_free_pages+3: push %rbx 0x80692ae4 vm_phys_free_pages+4: movsbq 0x61(%rdi),%r8 0x80692ae9 vm_phys_free_pages+9: mov%esi,%ebx 0x80692aeb vm_phys_free_pages+11: mov0x40(%rdi),%rbp 0x80692aef vm_phys_free_pages+15: shl$0x5,%r8 0x80692af3 vm_phys_free_pages+19: cmp$0xb,%esi 0x80692af6 vm_phys_free_pages+22: lea 0x80a68340(%r8),%r12 0x80692afd vm_phys_free_pages+29: jg 0x80692c4e vm_phys_free_pages+366 0x80692b03 vm_phys_free_pages+35: lea0xc(%rbx),%ecx 0x80692b06 vm_phys_free_pages+38: mov$0x1,%eax 0x80692b0b vm_phys_free_pages+43: mov 0x80a68340(%r8),%rdx 0x80692b12 vm_phys_free_pages+50: shl%cl,%eax 0x80692b14 vm_phys_free_pages+52: cltq 0x80692b16 vm_phys_free_pages+54: xor%rbp,%rax 0x80692b19 vm_phys_free_pages+57: cmp%rdx,%rax ... I'll attch the fix for qemu/tcg/tcg-op.h (the same bug was in the movswq case
[Qemu-devel] qemu 2008-03-02 snapshot FreeBSD 7.0/amd64 guest regression (tcg?)
Hi! I've prepared a FreeBSD qemu-devel port update, as already mentioned on the freebsd-emulation list, and found the FreeBSD 7.0/amd64 isos now pagefault repeatedly, saying: panic: page fault cpuid = 0 kernel trap 12 with interrupts disabled Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x20 fault code = supervisor read data, page not present instruction pointer = 0x8:0x8046c704 trap number = 12 frame pointer = 0x10:0x0 ... 0x8046c704 in the 7.0-RELEASE kernel used on the isos is in _thread_lock_flags: (kgdb) disassemble _thread_lock_flags Dump of assembler code for function _thread_lock_flags: 0x8046c6e0 _thread_lock_flags+0: push %r14 0x8046c6e2 _thread_lock_flags+2: mov%rdi,%r14 0x8046c6e5 _thread_lock_flags+5: push %r13 0x8046c6e7 _thread_lock_flags+7: push %r12 0x8046c6e9 _thread_lock_flags+9: push %rbp 0x8046c6ea _thread_lock_flags+10: push %rbx 0x8046c6eb _thread_lock_flags+11: mov%gs:0x0,%r13 0x8046c6f4 _thread_lock_flags+20: xor%r12d,%r12d 0x8046c6f7 _thread_lock_flags+23: callq 0x8071df80 spinlock_enter 0x8046c6fc _thread_lock_flags+28: mov(%r14),%rbp 0x8046c6ff _thread_lock_flags+31: mov$0x4,%eax 0x8046c704 _thread_lock_flags+36: lock cmpxchg %r13,0x20(%rbp) 0x8046c70a _thread_lock_flags+42: sete %al 0x8046c70d _thread_lock_flags+45: test %al,%al 0x8046c70f _thread_lock_flags+47: jne0x8046c799 _thread_lock_flags+185 0x8046c715 _thread_lock_flags+53: mov0x20(%rbp),%rdx 0x8046c719 _thread_lock_flags+57: cmp%r13,%rdx 0x8046c71c _thread_lock_flags+60: je 0x8046c7cd _thread_lock_flags+237 0x8046c722 _thread_lock_flags+66: callq 0x8071c4e0 spinlock_exit ---Type return to continue, or q return to quit--- 0x8046c727 _thread_lock_flags+71: jmp0x8046c73c _thread_lock_flags+92 0x8046c729 _thread_lock_flags+73: data16 ... so this looks like either %rbp is indeed zero or that cmpxchg insn isnt getting correctly translated. If you want to reproduce just boot the 35 MB 7.0-RELEASE-amd64-bootonly.iso in qemu-system-x86_64 (without kqemu); you can find mirrors via http://mirrorlist.freebsd.org/ (search for isos, amd64 architecture, I used 7.0 as you can see.) Oh, if you want to look at the live kernel you can boot the 7.0-RELEASE-amd64-livefs.iso in 0.9.1 with the previously mentioned patch (see http://www.nabble.com/forum/ViewPost.jtp?post=14921171 ), select fixit-cdrom in the menu that comes up after choosing the keyboard layout, and run `kgdb /dist/boot/kernel/kernel /dev/mem'. Thanx, Juergen
[Qemu-devel] Re: qemu 2008-03-02 snapshot FreeBSD 7.0/amd64 guest regression (tcg?)
On Sun, Mar 02, 2008 at 09:47:02PM +0100, Juergen Lock wrote: Hi! I've prepared a FreeBSD qemu-devel port update, as already mentioned on the freebsd-emulation list, and found the FreeBSD 7.0/amd64 isos now pagefault repeatedly, saying: panic: page fault cpuid = 0 kernel trap 12 with interrupts disabled Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x20 fault code = supervisor read data, page not present instruction pointer = 0x8:0x8046c704 trap number = 12 frame pointer = 0x10:0x0 ... 0x8046c704 in the 7.0-RELEASE kernel used on the isos is in _thread_lock_flags: (kgdb) disassemble _thread_lock_flags Dump of assembler code for function _thread_lock_flags: 0x8046c6e0 _thread_lock_flags+0:push %r14 0x8046c6e2 _thread_lock_flags+2:mov%rdi,%r14 0x8046c6e5 _thread_lock_flags+5:push %r13 0x8046c6e7 _thread_lock_flags+7:push %r12 0x8046c6e9 _thread_lock_flags+9:push %rbp 0x8046c6ea _thread_lock_flags+10: push %rbx 0x8046c6eb _thread_lock_flags+11: mov%gs:0x0,%r13 0x8046c6f4 _thread_lock_flags+20: xor%r12d,%r12d 0x8046c6f7 _thread_lock_flags+23: callq 0x8071df80 spinlock_enter 0x8046c6fc _thread_lock_flags+28: mov(%r14),%rbp 0x8046c6ff _thread_lock_flags+31: mov$0x4,%eax 0x8046c704 _thread_lock_flags+36: lock cmpxchg %r13,0x20(%rbp) 0x8046c70a _thread_lock_flags+42: sete %al 0x8046c70d _thread_lock_flags+45: test %al,%al 0x8046c70f _thread_lock_flags+47: jne0x8046c799 _thread_lock_flags+185 0x8046c715 _thread_lock_flags+53: mov0x20(%rbp),%rdx 0x8046c719 _thread_lock_flags+57: cmp%r13,%rdx 0x8046c71c _thread_lock_flags+60: je 0x8046c7cd _thread_lock_flags+237 0x8046c722 _thread_lock_flags+66: callq 0x8071c4e0 spinlock_exit ---Type return to continue, or q return to quit--- 0x8046c727 _thread_lock_flags+71: jmp0x8046c73c _thread_lock_flags+92 0x8046c729 _thread_lock_flags+73: data16 ... so this looks like either %rbp is indeed zero or that cmpxchg insn isnt getting correctly translated. If you want to reproduce just boot the 35 MB 7.0-RELEASE-amd64-bootonly.iso in qemu-system-x86_64 (without kqemu); you can find mirrors via http://mirrorlist.freebsd.org/ (search for isos, amd64 architecture, I used 7.0 as you can see.) Oh, if you want to look at the live kernel you can boot the 7.0-RELEASE-amd64-livefs.iso in 0.9.1 with the previously mentioned patch (see http://www.nabble.com/forum/ViewPost.jtp?post=14921171 ), select fixit-cdrom in the menu that comes up after choosing the keyboard layout, and run `kgdb /dist/boot/kernel/kernel /dev/mem'. Update: looks like the bug is i386 host only, at least I got a report of amd64 host working. (will try to confirm later...) Juergen
Re: [Qemu-devel] qemu-system-amd64 (0.9.1) and freebsd guest - irq patch (pointer)
In article [EMAIL PROTECTED] you write: I reported this bug and gave a patch. http://www.nabble.com/forum/ViewPost.jtp?post=14921171 Hmm, any particular reason this hasn't been committed yet? Just wondering... Juergen
[Qemu-devel] qemu-system-amd64 (0.9.1) and freebsd guest - irq patch (pointer)
Hi! I received the following posting and patch, sent to the freebsd-emulation list, can anyone here say if it is correct, and if yes, apply? http://docs.freebsd.org/cgi/mid.cgi?20080216164331.GJ57756 (You can use the `Raw E-Mail' link to get the unmangled patch out.) Thanx, Juergen
[Qemu-devel] patch: qemu-system-arm -old-param segfault
Hi! I guess thats what I get for not testing cvs for so long... :) There's a break missing in vl.c, patch attached. The good news is with this patch the spitz emu seems to still work as well as with the (patched) August cvs snapshot that I was using when last tesing it. enjoy, Juergen Index: qemu/vl.c @@ -8784,6 +8784,7 @@ #ifdef TARGET_ARM case QEMU_OPTION_old_param: old_param = 1; +break; #endif case QEMU_OPTION_clock: configure_alarms(optarg);
[Qemu-devel] scsi emulation throughput (was: Re: qemu-cvs FreeBSD guests, cirrus, vmwarevga emulation - experimental qemu-devel FreeBSD port update available for testing)
On Sun, Jan 06, 2008 at 11:44:50PM +0100, Juergen Lock wrote: Hi! Yesterday (so, just before the qemu version commit...) I prepared a FreeBSD qemu-devel port update using the 2008-01-05_05 snapshot, http://people.freebsd.org/~nox/qemu/qemu-devel-20080105.patch and I already got a report of xorg 7.3 using the cirrus emulation in a FreeBSD 6.3 RC guest crashing with -kernel-kqemu, and hanging without it, which he said worked with the previous qemu cvs snapshot thats still in ports (2007-08-02_05.) -vmwarevga worked, but still had the old problem of causing the ne2kpci nic not to attach (ed0.) The i82557b nic can be used as a workaround (fxp0, its faster anyway), but I just verified with a FreeBSD 6.2 guest (you can use e.g. a FreeSBIE livecd iso, use `su' if you want to edit its /etc/X11/xorg.conf, after that exit the root shell and run `startx'; I gave qemu -m 256) that -vmwarevga also still causes the es1370 soundcard not to attach and I don't know a workaround for that. Also, still slirp causes qemu to crash on amd64 hosts when just trying to access a webpage from inside a guest. So, can anyone reproduce any of these problems on e.g. a Linux host? Also, more testing of the FreeBSD port update is certainly needed, also using non-FreeBSD guests, non-i386/amd64 targets, and the new -disk option (...which is now called -drive btw.) (which I didn't yet test at all, it should e.g. allow scsi drives to be emulated, tho very likely FreeBSD host support for the scsi passthru feature still needs to be done, and io via qemu is probably too slow to burn a dvd anyway. :) Actually... I just played with -drive if=scsi and -kernel-kqemu in a linux guest and a dd bs=64k from a 5MB file to /dev/null got me more than 25 MB/s! While a similar dd off the emulated ide cdrom drive (I was using a livecd iso, sidux-2007-04.5-200712260120-eros_xmas-kde-lite-i386.iso) only gets me about a tenth of that. Can anyone reproduce this? :) This is the first time I've seen qemu doing more than a few MB/s IO on this box... Btw a FreeBSD (FreeSBIE) guest didn't get nearly as much, tho that may partly be because the image I used was vfat and FreeBSD's msdosfs is not exactly fast. (Or maybe scsi tags weren't enabled or something.) Still surprised... Juergen
[Qemu-devel] Re: qemu-cvs FreeBSD guests, cirrus, vmwarevga emulation - experimental qemu-devel FreeBSD port update available for testing
On Sun, Jan 06, 2008 at 11:44:50PM +0100, Juergen Lock wrote: Hi! Yesterday (so, just before the qemu version commit...) I prepared a FreeBSD qemu-devel port update using the 2008-01-05_05 snapshot, http://people.freebsd.org/~nox/qemu/qemu-devel-20080105.patch and I already got a report of xorg 7.3 using the cirrus emulation in a FreeBSD 6.3 RC guest crashing with -kernel-kqemu, and hanging without it, which he said worked with the previous qemu cvs snapshot thats still in ports (2007-08-02_05.) -vmwarevga worked, but still had the old problem of causing the ne2kpci nic not to attach (ed0.) The i82557b nic can be used as a workaround (fxp0, its faster anyway), but I just verified with a FreeBSD 6.2 guest (you can use e.g. a FreeSBIE livecd iso, use `su' if you want to edit its /etc/X11/xorg.conf, after that exit the root shell and run `startx'; I gave qemu -m 256) that -vmwarevga also still causes the es1370 soundcard not to attach and I don't know a workaround for that. Also, still slirp causes qemu to crash on amd64 hosts when just trying to access a webpage from inside a guest. Update for the cirrus problem: He just said that in fact it also occured with the 2007-08-02_05 snapshot, so at least the problem is older. So, can anyone reproduce any of these problems on e.g. a Linux host? Also, more testing of the FreeBSD port update is certainly needed, also using non-FreeBSD guests, non-i386/amd64 targets, and the new -disk option (which I didn't yet test at all, it should e.g. allow scsi drives to be emulated, tho very likely FreeBSD host support for the scsi passthru feature still needs to be done, and io via qemu is probably too slow to burn a dvd anyway. :) Thanx, Juergen PS: I just see that 0.9.1 is actually out now, so I guess I should prepare an update to the qemu port instead, but not today... (and testing this one is still useful.) Ok I have a 0.9.1 update now that currently building on tb3, please help testing: http://people.freebsd.org/~nox/qemu/qemu-0.9.1.patch Thanx, Juergen
[Qemu-devel] qemu-cvs FreeBSD guests, cirrus, vmwarevga emulation - experimental qemu-devel FreeBSD port update available for testing
Hi! Yesterday (so, just before the qemu version commit...) I prepared a FreeBSD qemu-devel port update using the 2008-01-05_05 snapshot, http://people.freebsd.org/~nox/qemu/qemu-devel-20080105.patch and I already got a report of xorg 7.3 using the cirrus emulation in a FreeBSD 6.3 RC guest crashing with -kernel-kqemu, and hanging without it, which he said worked with the previous qemu cvs snapshot thats still in ports (2007-08-02_05.) -vmwarevga worked, but still had the old problem of causing the ne2kpci nic not to attach (ed0.) The i82557b nic can be used as a workaround (fxp0, its faster anyway), but I just verified with a FreeBSD 6.2 guest (you can use e.g. a FreeSBIE livecd iso, use `su' if you want to edit its /etc/X11/xorg.conf, after that exit the root shell and run `startx'; I gave qemu -m 256) that -vmwarevga also still causes the es1370 soundcard not to attach and I don't know a workaround for that. Also, still slirp causes qemu to crash on amd64 hosts when just trying to access a webpage from inside a guest. So, can anyone reproduce any of these problems on e.g. a Linux host? Also, more testing of the FreeBSD port update is certainly needed, also using non-FreeBSD guests, non-i386/amd64 targets, and the new -disk option (which I didn't yet test at all, it should e.g. allow scsi drives to be emulated, tho very likely FreeBSD host support for the scsi passthru feature still needs to be done, and io via qemu is probably too slow to burn a dvd anyway. :) Thanx, Juergen PS: I just see that 0.9.1 is actually out now, so I guess I should prepare an update to the qemu port instead, but not today... (and testing this one is still useful.)
Re: [Qemu-devel] cdrom disc type - is this patch correct? (unbreaks recent FreeBSD guest's -cdrom access)
Oops, I seem to have missed this post, sorry for not answering earlier...
In article [EMAIL PROTECTED] you write:
On Tue, Nov 13 2007, Juergen Lock wrote:
Hi!
Yesterday I learned that FreeBSD 7.0-BETA2 guests will no longer
read from the emulated cd drive, apparently because of this commit:
http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/ata/atapi-cd.c.diff?r1=1.193;r2=1.193.2.1
The following patch file added to the qemu-devel port fixes the issue
for me, is it also correct? (making the guest see a dvd in the drive
when it is inserted, previously it saw the drive as empty.)
The second hunk is already in qemu cvs so remove it if you want to
test on that. ISO used for testing:
ftp://ftp.freebsd.org:/pub/FreeBSD/ISO-IMAGES-i386/7.0/7.0-BETA2-i386-disc1.iso
(test by either selecting fixit-cdrom or by trying to install, just
booting it will always work because that goes thru the bios.)
Index: qemu/hw/ide.c
@@ -1339,6 +1341,8 @@
case 0x2a:
cpu_to_ube16(buf[0], 28 + 6);
buf[2] = 0x70;
+if (bdrv_is_inserted(s-bs))
+buf[2] = 0x40;
medium type code has been obsoleted since at least 1999. Looking back at
even older docs, 0x70 is 'door closed, no disc present'. 0x40 is a
reserved value though, I would not suggest using that. Given that
freebsd breaks, my suggest change would be the below - keep the 0x70 for
when no disc is really inserted, but don't set anything if there is.
diff --git a/hw/ide.c b/hw/ide.c
index 5f76c27..52d4c78 100644
--- a/hw/ide.c
+++ b/hw/ide.c
@@ -1344,7 +1344,10 @@ static void ide_atapi_cmd(IDEState *s)
break;
case 0x2a:
cpu_to_ube16(buf[0], 28 + 6);
-buf[2] = 0x70;
+ if (!bdrv_is_inserted(s-bs))
+ buf[2] = 0x70;
+ else
+ buf[2] = 0;
buf[3] = 0;
buf[4] = 0;
buf[5] = 0;
Well that (0) doesn't work. The relevant FreeBSD header,
http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/ata/atapi-cd.h?rev=1.46.2.1;content-type=text%2Fx-cvsweb-markup
, defines the following:
[...]
/* CDROM Capabilities and Mechanical Status Page */
struct cappage {
/* mode page data header */
u_int16_t data_length;
u_int8_tmedium_type;
#define MST_TYPE_MASK_LOW 0x0f
#define MST_FMT_NONE0x00
#define MST_DATA_1200x01
#define MST_AUDIO_120 0x02
#define MST_COMB_1200x03
#define MST_PHOTO_120 0x04
#define MST_DATA_80 0x05
#define MST_AUDIO_800x06
#define MST_COMB_80 0x07
#define MST_PHOTO_800x08
#define MST_TYPE_MASK_HIGH 0x70
#define MST_CDROM 0x00
#define MST_CDR 0x10
#define MST_CDRW0x20
#define MST_DVD 0x40
#define MST_NO_DISC 0x70
#define MST_DOOR_OPEN 0x71
#define MST_FMT_ERROR 0x72
u_int8_tdev_spec;
u_int16_t unused;
u_int16_t blk_desc_len;
/* capabilities page */
u_int8_tpage_code;
#define ATAPI_CDROM_CAP_PAGE0x2a
u_int8_tparam_len;
u_int16_t media;
#define MST_READ_CDR0x0001
#define MST_READ_CDRW 0x0002
#define MST_READ_PACKET 0x0004
#define MST_READ_DVDROM 0x0008
#define MST_READ_DVDR 0x0010
#define MST_READ_DVDRAM 0x0020
#define MST_WRITE_CDR 0x0100
#define MST_WRITE_CDRW 0x0200
#define MST_WRITE_TEST 0x0400
#define MST_WRITE_DVDR 0x1000
#define MST_WRITE_DVDRAM0x2000
u_int16_t capabilities;
#define MST_AUDIO_PLAY 0x0001
#define MST_COMPOSITE 0x0002
#define MST_AUDIO_P10x0004
#define MST_AUDIO_P20x0008
#define MST_MODE2_f10x0010
#define MST_MODE2_f20x0020
#define MST_MULTISESSION0x0040
#define MST_BURNPROOF 0x0080
#define MST_READ_CDDA 0x0100
#define MST_CDDA_STREAM 0x0200
#define MST_COMBINED_RW 0x0400
#define MST_CORRECTED_RW0x0800
#define MST_SUPPORT_C2 0x1000
#define MST_ISRC0x2000
#define MST_UPC 0x4000
u_int8_tmechanism;
#define MST_LOCKABLE0x01
#define MST_LOCKED 0x02
#define MST_PREVENT 0x04
#define MST_EJECT 0x08
#define MST_MECH_MASK 0xe0
#define MST_MECH_CADDY 0x00
#define MST_MECH_TRAY 0x20
#define MST_MECH_POPUP 0x40
#define MST_MECH_CHANGER0x80
#define MST_MECH_CARTRIDGE 0xa0
uint8_t audio;
#define MST_SEP_VOL 0x01
#define MST_SEP_MUTE0x02
u_int16_t max_read_speed; /* max raw data rate in bytes/1000 */
u_int16_t max_vol_levels
[Qemu-devel] cdrom disc type - is this patch correct? (unbreaks recent FreeBSD guest's -cdrom access)
Hi! Yesterday I learned that FreeBSD 7.0-BETA2 guests will no longer read from the emulated cd drive, apparently because of this commit: http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/ata/atapi-cd.c.diff?r1=1.193;r2=1.193.2.1 The following patch file added to the qemu-devel port fixes the issue for me, is it also correct? (making the guest see a dvd in the drive when it is inserted, previously it saw the drive as empty.) The second hunk is already in qemu cvs so remove it if you want to test on that. ISO used for testing: ftp://ftp.freebsd.org:/pub/FreeBSD/ISO-IMAGES-i386/7.0/7.0-BETA2-i386-disc1.iso (test by either selecting fixit-cdrom or by trying to install, just booting it will always work because that goes thru the bios.) Index: qemu/hw/ide.c @@ -1339,6 +1341,8 @@ case 0x2a: cpu_to_ube16(buf[0], 28 + 6); buf[2] = 0x70; +if (bdrv_is_inserted(s-bs)) +buf[2] = 0x40; buf[3] = 0; buf[4] = 0; buf[5] = 0; @@ -1347,7 +1351,7 @@ buf[8] = 0x2a; buf[9] = 0x12; -buf[10] = 0x00; +buf[10] = 0x08; buf[11] = 0x00; buf[12] = 0x70; Thanx, Juergen
Re: [Qemu-devel] qemu-system-arm -M akita/terrier - which roms work? (more patches, this time keyboard... :)
On Mon, Jul 30, 2007 at 12:30:23AM +0200, Juergen Lock wrote:
On Sun, Jul 29, 2007 at 03:46:37AM +0200, andrzej zaborowski wrote:
Hi,
Hi,
On 29/07/07, Juergen Lock [EMAIL PROTECTED] wrote:
Anyway, boot now fails with:
qemu: fatal: pxa2xx_gpio_read: Bad offset 0x1c
i.e. it is apparently expecting something there that is not yet
Oh, it's Sharp's poor code :) the GPSR (0x1c) and GPCR registers are
write-only. I think it's safe to assume that the real hardware returns
the last written value in these addresses when reading, but in the
documentation they are write-only.
Yeah it was crashing in static int force_8bit_access_check_and_set
in linux/drivers/pcmcia/cistpl.c, apparently while doing an
GPSR(GPIO54_nPCE_2) = GPSR(GPIO54_nPCE_2);
Patched that (patch-pxa-gpsr, attached), and now the boot seems
to be hanging somewhere in userland...
Btw that patch is not yet committed, did it get lost? or does it
cause problems...
emulated. And when i boot with init=/bin/sh I can't do much because
the keymap seems to be wrong or the fn key otherwise gets lost.
(similar effect with the poky image btw, I wonder is this a qemu
problem or is just noone using the terminal there? :)
The problem here is the 2.6 kernel's default keymap and the zaurusd
daemon used in poky and openzaurus. They use this strange keymap and
qemu tries to account for that. I had first set a keymap in qemu that
matched the console keymap but later when I started using X it was
unusable and other users also didn't like that so I remapped all the
keys, but the remapping is not perfect even now, because the real
Zaurus keymap is too far from a normal pc keyboard (and I don't have a
physical one).
Yeah it has an fn key that is used to generate most special characters...
But even shift didn't work on the 2.4 kernel's console (and as I said
fn apparently got lost too), and with the poky rxvt it seemed like
anything that uses fn caused an error (cursor flashes quickly) instead
of sending the corresponding character.
Anyway I just played with this a bit again and got the fn key
working by exchanging 0x3d and 0x38 in hw/spitz.c, spitz_keymap... :)
(after looking at linux/drivers/char/spitz_rawmap.h in the sharp kernel.)
I also added definitions for { and } while I was at it, and now
the keyboard mostly works, only the right shift key still does nothing
on the sharp kernel's console and there seem to be the occasional
timing issues especially with 2.6 kernels i.e. sometimes the fn key
still gets lost etc.
Patch attached, enjoy...
Juergen
Index: qemu/hw/spitz.c
@@ -194,8 +194,8 @@
{ 0x0f, 0x10, 0x12, 0x14, 0x22, 0x16, 0x24, 0x25, -1 , -1 , -1 },
{ 0x3c, 0x11, 0x1f, 0x21, 0x2f, 0x23, 0x32, 0x26, -1 , 0x36, -1 },
{ 0x3b, 0x1e, 0x20, 0x2e, 0x30, 0x31, 0x34, -1 , 0x1c, 0x2a, -1 },
-{ 0x44, 0x2c, 0x2d, 0x0c, 0x39, 0x33, -1 , 0x48, -1 , -1 , 0x3d },
-{ 0x37, 0x38, -1 , 0x45, 0x57, 0x58, 0x4b, 0x50, 0x4d, -1 , -1 },
+{ 0x44, 0x2c, 0x2d, 0x0c, 0x39, 0x33, -1 , 0x48, -1 , -1 , 0x38 },
+{ 0x37, 0x3d, -1 , 0x45, 0x57, 0x58, 0x4b, 0x50, 0x4d, -1 , -1 },
{ 0x52, 0x43, 0x01, 0x47, 0x49, -1 , -1 , -1 , -1 , -1 , -1 },
};
@@ -425,6 +428,10 @@
s-pre_map[0x35 | SHIFT] = 0x34 | SHIFT; /* question */
s-pre_map[0x49] = 0x48 | FN; /* Page_Up */
s-pre_map[0x51] = 0x50 | FN; /* Page_Down */
+s-pre_map[0x33 | SHIFT] = 0x33 | FN; /* less */
+s-pre_map[0x34 | SHIFT] = 0x34 | FN; /* greater */
+s-pre_map[0x1a | SHIFT] = 0x16 | FN; /* braceleft */
+s-pre_map[0x1b | SHIFT] = 0x17 | FN; /* braceright */
s-modifiers = 0;
s-imodifiers = 0;
Re: [Qemu-devel] qemu-system-arm -M akita/terrier - which roms work? (more patches... :)
On Tue, Jul 31, 2007 at 02:37:04AM +0200, Juergen Lock wrote: On Mon, Jul 30, 2007 at 12:30:23AM +0200, Juergen Lock wrote: On Sun, Jul 29, 2007 at 03:46:37AM +0200, andrzej zaborowski wrote: Hi, Hi, On 29/07/07, Juergen Lock [EMAIL PROTECTED] wrote: Anyway, boot now fails with: qemu: fatal: pxa2xx_gpio_read: Bad offset 0x1c i.e. it is apparently expecting something there that is not yet Oh, it's Sharp's poor code :) the GPSR (0x1c) and GPCR registers are write-only. I think it's safe to assume that the real hardware returns the last written value in these addresses when reading, but in the documentation they are write-only. Yeah it was crashing in static int force_8bit_access_check_and_set in linux/drivers/pcmcia/cistpl.c, apparently while doing an GPSR(GPIO54_nPCE_2) = GPSR(GPIO54_nPCE_2); Patched that (patch-pxa-gpsr, attached), and now the boot seems to be hanging somewhere in userland... Ok I set a breakpoint on do_execve and found that it was repeatedly calling `/bin/grep ^1 /var/lib/pcmcia/stab'. On my zaurus that file looks like: Socket 0: empty Socket 1: ATA/IDE Fixed Disk 1 ide ide_cs 0hda 3 0 and indeed in qemu it has the disk in socket 0. Patched that (see patch-spitz-hda, attached), and now (well I also added an sd image since I got lots of pxa_sd_put_command: responce time out by jiffies (cmd=01) ) I at least get INIT: version 2.78 booting mount: Mounting /dev/hda1 on /hdd1 failed: Invalid argument and when I hit ^c (btw, the left shift key does work, only the right one doesnt) it continues with INIT: Entering runlevel: 4 INIT: Switching to runlevel: 6 INIT: Sending processes the TERM signal umount: forced umount of /dev/ram1 failed! Can't find /dev in /etc/fstab umount: /proc: Device or resource busy Rebooting the system... and the kernel's last words on the serial console are flushing ide devices: Restarting system. reboot the kernel (1) Reboot failed -- System halted Okay, time to sfdisk the hda image (it was empty :), boot with `rw init=/bin/sh', mknod /dev/hda*, mounting /proc and /home and then try sfdisk: # sfdisk /dev/hda modprobe: modprobe: Can't locate module block-major-3 /dev/hda: No such device or address sfdisk: cannot open /dev/hda read-write Hmm, some module not loaded? looking around in /lib/modules/ I see no obvious candidate, anyone have an idea? Okay, back to the akita image... booting that to runlevel 2 or 4 now in fact gets me a login prompt on the serial console, and in runlevel 4 I even see the gui splash screen flashing, but the gui doesnt start, and after a few iterations I get INIT: Id ln respawning too fast: disabled for 5 minutes ln is (grep ln /etc/inittab): ln:345:respawn:survive -l 6 /sbin/launch Ok i now created a proper terrier hda image using the http://www.trisoft.de/download/SLC3200SYSPART.zip and now I get essentially the same behaviour as with the akita image, and I can confirm the gui startup is crashing with gawk (277): undefined instruction: pc=00023dd4 Code: e3130020 1d908100 1a00 eb0020d1 (ee103170) and qpe (297): undefined instruction: pc=4044fc88 Code: ed81110a ee120180 ee00018e e5913008 (ee102170) (repeated as init respawns it.) I also posted a FreeBSD qemu-devel port update, http://docs.freebsd.org/cgi/mid.cgi?20070731201608.GA30162 using the 2007-07-31_05 snapshot with the pxa-gpsr and spitz-hda patches added. So if anyone has an idea about the fpu emulation crashes I'd be thankful. Cheers, Juergen
Re: [Qemu-devel] qemu-system-arm -M akita/terrier - which roms work? (more patches... :)
On Tue, Jul 31, 2007 at 11:31:58PM +0200, andrzej zaborowski wrote: On 31/07/07, Juergen Lock [EMAIL PROTECTED] wrote: On Tue, Jul 31, 2007 at 02:37:04AM +0200, Juergen Lock wrote: On Mon, Jul 30, 2007 at 12:30:23AM +0200, Juergen Lock wrote: On Sun, Jul 29, 2007 at 03:46:37AM +0200, andrzej zaborowski wrote: Hi, Hi, On 29/07/07, Juergen Lock [EMAIL PROTECTED] wrote: Anyway, boot now fails with: qemu: fatal: pxa2xx_gpio_read: Bad offset 0x1c i.e. it is apparently expecting something there that is not yet Oh, it's Sharp's poor code :) the GPSR (0x1c) and GPCR registers are write-only. I think it's safe to assume that the real hardware returns the last written value in these addresses when reading, but in the documentation they are write-only. Yeah it was crashing in static int force_8bit_access_check_and_set in linux/drivers/pcmcia/cistpl.c, apparently while doing an GPSR(GPIO54_nPCE_2) = GPSR(GPIO54_nPCE_2); Patched that (patch-pxa-gpsr, attached), and now the boot seems to be hanging somewhere in userland... Ok I set a breakpoint on do_execve and found that it was repeatedly calling `/bin/grep ^1 /var/lib/pcmcia/stab'. On my zaurus that file looks like: Socket 0: empty Socket 1: ATA/IDE Fixed Disk 1 ide ide_cs 0hda 3 0 and indeed in qemu it has the disk in socket 0. Patched that (see patch-spitz-hda, attached), and now (well I also added an sd image since I got lots of pxa_sd_put_command: responce time out by jiffies (cmd=01) ) I at least get INIT: version 2.78 booting mount: Mounting /dev/hda1 on /hdd1 failed: Invalid argument and when I hit ^c (btw, the left shift key does work, only the right one doesnt) it continues with INIT: Entering runlevel: 4 INIT: Switching to runlevel: 6 INIT: Sending processes the TERM signal umount: forced umount of /dev/ram1 failed! Can't find /dev in /etc/fstab umount: /proc: Device or resource busy Rebooting the system... and the kernel's last words on the serial console are flushing ide devices: Restarting system. reboot the kernel (1) Reboot failed -- System halted Okay, time to sfdisk the hda image (it was empty :), boot with `rw init=/bin/sh', mknod /dev/hda*, mounting /proc and /home and then try sfdisk: # sfdisk /dev/hda modprobe: modprobe: Can't locate module block-major-3 /dev/hda: No such device or address sfdisk: cannot open /dev/hda read-write Hmm, some module not loaded? looking around in /lib/modules/ I see no obvious candidate, anyone have an idea? Okay, back to the akita image... booting that to runlevel 2 or 4 now in fact gets me a login prompt on the serial console, and in runlevel 4 I even see the gui splash screen flashing, but the gui doesnt start, and after a few iterations I get INIT: Id ln respawning too fast: disabled for 5 minutes ln is (grep ln /etc/inittab): ln:345:respawn:survive -l 6 /sbin/launch Ok i now created a proper terrier hda image using the http://www.trisoft.de/download/SLC3200SYSPART.zip and now I get essentially the same behaviour as with the akita image, and I can confirm the gui startup is crashing with gawk (277): undefined instruction: pc=00023dd4 Code: e3130020 1d908100 1a00 eb0020d1 (ee103170) According to objdump this is: 0: e3130020tst r3, #32 ; 0x20 4: 1d908100wldrwne wr8, [r0] 8: 1a00bne 0x10 c: eb0020d1bl 0x8358 10: ee103170fixzr3, f0 So the last opcode is not an iWMMXt opcode and not XScale-specific, but somehow it got generated by gcc, right? (and if the gcc knew that it's compiling for an iWMMXt enabled processor, there would be no fpu insns) I guess the guys at sharp just didn't realize their cpu had no fpu or something :) (Or that you can compile to use softfloats.) So unless the idea is that the condition for bne was supposed to be always false and the function at 0x8358 is supposed to not return, it's the kernel's emulation fault. Are you running the stock kernel? otherwise maybe some fpu emulation is missing. I tried with the stock kernel too. (I had used its config as a base.) And as I said when I traced the kernel's fpu emulation code the problem seemed to be unitialized registers... It's weird. With fpu this code would be: 0: e3130020tst r3, #32 ; 0x20 4: 1d908100ldfned f0, [r0] 8: 1a00bne 0x10 c: eb0020d1bl 0x8358 10: ee103170fixzr3, f0 can you try this change: --- a/target-arm/helper.c +++ b/target-arm/helper.c @@ -840,7 +840,7 @@ void
Re: [Qemu-devel] qemu-system-arm -M akita/terrier - which roms work? (more patches... :)
On Mon, Jul 30, 2007 at 12:30:23AM +0200, Juergen Lock wrote:
On Sun, Jul 29, 2007 at 03:46:37AM +0200, andrzej zaborowski wrote:
Hi,
Hi,
On 29/07/07, Juergen Lock [EMAIL PROTECTED] wrote:
Anyway, boot now fails with:
qemu: fatal: pxa2xx_gpio_read: Bad offset 0x1c
i.e. it is apparently expecting something there that is not yet
Oh, it's Sharp's poor code :) the GPSR (0x1c) and GPCR registers are
write-only. I think it's safe to assume that the real hardware returns
the last written value in these addresses when reading, but in the
documentation they are write-only.
Yeah it was crashing in static int force_8bit_access_check_and_set
in linux/drivers/pcmcia/cistpl.c, apparently while doing an
GPSR(GPIO54_nPCE_2) = GPSR(GPIO54_nPCE_2);
Patched that (patch-pxa-gpsr, attached), and now the boot seems
to be hanging somewhere in userland...
Ok I set a breakpoint on do_execve and found that it was repeatedly
calling `/bin/grep ^1 /var/lib/pcmcia/stab'. On my zaurus that file
looks like:
Socket 0: empty
Socket 1: ATA/IDE Fixed Disk
1 ide ide_cs 0hda 3 0
and indeed in qemu it has the disk in socket 0. Patched that
(see patch-spitz-hda, attached), and now (well I also added an
sd image since I got lots of
pxa_sd_put_command: responce time out by jiffies (cmd=01)
) I at least get
INIT: version 2.78 booting
mount: Mounting /dev/hda1 on /hdd1 failed: Invalid argument
and when I hit ^c (btw, the left shift key does work, only the
right one doesnt) it continues with
INIT: Entering runlevel: 4
INIT: Switching to runlevel: 6
INIT: Sending processes the TERM signal
umount: forced umount of /dev/ram1 failed!
Can't find /dev in /etc/fstab
umount: /proc: Device or resource busy
Rebooting the system...
and the kernel's last words on the serial console are
flushing ide devices:
Restarting system.
reboot the kernel (1)
Reboot failed -- System halted
Okay, time to sfdisk the hda image (it was empty :), boot with
`rw init=/bin/sh', mknod /dev/hda*, mounting /proc and /home and
then try sfdisk:
# sfdisk /dev/hda
modprobe: modprobe: Can't locate module block-major-3
/dev/hda: No such device or address
sfdisk: cannot open /dev/hda read-write
Hmm, some module not loaded? looking around in /lib/modules/
I see no obvious candidate, anyone have an idea?
Okay, back to the akita image... booting that to runlevel 2 or 4 now
in fact gets me a login prompt on the serial console, and in runlevel 4
I even see the gui splash screen flashing, but the gui doesnt
start, and after a few iterations I get
INIT: Id ln respawning too fast: disabled for 5 minutes
ln is (grep ln /etc/inittab):
ln:345:respawn:survive -l 6 /sbin/launch
Playing around I also found that both `more /etc/inittab' and `ps'
exit with `Illegal instruction', ouch! Afer adding CONFIG_DEBUG_USER
to the kernel I get
more (25): undefined instruction: pc=0002087c
Code: ed9fa149 e59f0128 ee012190 ee400181 (ee100182)
and
ps (26): undefined instruction: pc=0200d94c
Code: e24b204c ebffce16 ed1bb113 ed1ba10c (ee230182)
(the one in brackets seems to be the insn in question), and
tracing the kernel's fpu emulator (starting with EmulateAll in
linux/arch/arm/nwfpe/fpa11.c) I find that both failure seem to be
caused by an fpa11-fType[x] being 0 == typeNone, i.e. it seems
an fpu emulator's register is uninitialized... Anyone have an idea
what's up with that? (oh, I didn't rebuild the akita kernel so this
was actually debugged with the terrier image.)
Thanx,
Juergen
Index: qemu/hw/spitz.c
@@ -929,7 +929,8 @@
if (bs bdrv_is_inserted(bs) !bdrv_is_removable(bs)) {
md = dscm1_init(bs);
-pxa2xx_pcmcia_attach(cpu-pcmcia[0], md);
+ /* at least terrier microdrive is in socket 1 */
+pxa2xx_pcmcia_attach(cpu-pcmcia[1], md);
}
}
Re: [Qemu-devel] qemu-system-arm -M akita/terrier - which roms work? (more patches... :)
On Sun, Jul 29, 2007 at 03:46:37AM +0200, andrzej zaborowski wrote: Hi, Hi, On 29/07/07, Juergen Lock [EMAIL PROTECTED] wrote: Anyway, boot now fails with: qemu: fatal: pxa2xx_gpio_read: Bad offset 0x1c i.e. it is apparently expecting something there that is not yet Oh, it's Sharp's poor code :) the GPSR (0x1c) and GPCR registers are write-only. I think it's safe to assume that the real hardware returns the last written value in these addresses when reading, but in the documentation they are write-only. Yeah it was crashing in static int force_8bit_access_check_and_set in linux/drivers/pcmcia/cistpl.c, apparently while doing an GPSR(GPIO54_nPCE_2) = GPSR(GPIO54_nPCE_2); Patched that (patch-pxa-gpsr, attached), and now the boot seems to be hanging somewhere in userland... emulated. And when i boot with init=/bin/sh I can't do much because the keymap seems to be wrong or the fn key otherwise gets lost. (similar effect with the poky image btw, I wonder is this a qemu problem or is just noone using the terminal there? :) The problem here is the 2.6 kernel's default keymap and the zaurusd daemon used in poky and openzaurus. They use this strange keymap and qemu tries to account for that. I had first set a keymap in qemu that matched the console keymap but later when I started using X it was unusable and other users also didn't like that so I remapped all the keys, but the remapping is not perfect even now, because the real Zaurus keymap is too far from a normal pc keyboard (and I don't have a physical one). Yeah it has an fn key that is used to generate most special characters... But even shift didn't work on the 2.4 kernel's console (and as I said fn apparently got lost too), and with the poky rxvt it seemed like anything that uses fn caused an error (cursor flashes quickly) instead of sending the corresponding character. Thanks for the patches, I will have a look tomorrow (hopefully). Thanx for committing, :) Juergen Index: qemu/hw/pxa2xx_gpio.c @@ -152,6 +152,9 @@ case GPDR: /* GPIO Pin-Direction registers */ return s-dir[bank]; +case GPSR: /* GPIO Pin-Output Set registers */ +return s-olevel[bank]; + case GRER: /* GPIO Rising-Edge Detect Enable registers */ return s-rising[bank];
Re: [Qemu-devel] qemu-system-arm -M akita/terrier - which roms work? (more patches... :)
On Sat, Jul 28, 2007 at 02:12:37AM +0200, Juergen Lock wrote:
On Sat, Jul 28, 2007 at 12:27:33AM +0200, andrzej zaborowski wrote:
On 28/07/07, andrzej zaborowski [EMAIL PROTECTED] wrote:
On 26/07/07, Juergen Lock [EMAIL PROTECTED] wrote:
and now I get lots of
nand ecc errors and mount failures, I guess the mtdparts= arg isnt right
yet and/or the raw2flash.c source needs fixing...
Okay the first reason for this was the terrier kernel doing long reads
from the nand flash io port, expecting to get 2 bytes at a time.
(enabled by CONFIG_ARCH_PXA_TERRIER at least in the sharp kernel),
see patch-nand-terrier (attached).
Likely the input to raw2flash.c was not what it expected. It expects a
1:1 image of the entire flash chip (but excluding oob - only data that
can be normally read from /dev/mtblock* and in the same order), and
(/dev/mtdblock*)
with a 10 byte header at the start of the file, which is discarded.
(rather 16)
Yeah I hat removed that, but was overlooking the fact that it
repeats the first PARTITION_START (0x0070) bytes in the output,
because it didnt expect this data in the input, and so it just fills
it out. Added another #ifndef which fixed that, see attached
patch-raw2flash-fullimage.
The partitions layout also matters. This format is the one that
OpenEmbedded outputs, but maybe the original format is also the same,
I don't know.
Guess not, at least my zaurus uses
mtdparts=sharpsl-nand:[EMAIL PROTECTED](smf),[EMAIL
PROTECTED](root),-(home)
and the 44032k is filled in by the sharp firmware as you can see when
you do a `strings -a' on the image. (It would be interesting to know
how it finds out that value btw...)
Found a table that seems to define that, example in the terrier image:
00644000 00 00 00 00 00 00 70 00 42 4F 4F 54 00 00 00 00 ..p.BOOT
00644010 00 00 70 00 00 00 20 03 46 53 52 4F 00 00 00 00 ..p... .FSRO
00644020 00 00 20 03 00 00 00 08 46 53 52 57 00 00 00 00 .. .FSRW
(entries of 1 long offset, 1 long length, 4 chars type, 1 long 0, so
the [EMAIL PROTECTED](root) above is indeed right. The akita image has a
similar table at 0x0066.)
Anyway, boot now fails with:
qemu: fatal: pxa2xx_gpio_read: Bad offset 0x1c
i.e. it is apparently expecting something there that is not yet
emulated. And when i boot with init=/bin/sh I can't do much because
the keymap seems to be wrong or the fn key otherwise gets lost.
(similar effect with the poky image btw, I wonder is this a qemu
problem or is just noone using the terminal there? :)
Okay enough for today...
Juergen
Index: qemu/hw/spitz.c
+++ work-arm3/qemu-snapshot-2007-07-02_05/hw/spitz.cSun Jul 29 00:33:34 2007
@@ -78,6 +78,23 @@
return 0;
}
+static uint32_t sl_readl(void *opaque, target_phys_addr_t addr)
+{
+struct sl_nand_s *s = (struct sl_nand_s *) opaque;
+int ryby;
+addr -= s-target_base;
+
+switch (addr) {
+case FLASH_FLASHIO:
+return ecc_digest(s-ecc, nand_getio(s-nand)) |
+(ecc_digest(s-ecc, nand_getio(s-nand)) 16);
+
+default:
+spitz_printf(Bad register offset REG_FMT \n, addr);
+}
+return 0;
+}
+
static void sl_writeb(void *opaque, target_phys_addr_t addr,
uint32_t value)
{
@@ -139,7 +156,7 @@
CPUReadMemoryFunc *sl_readfn[] = {
sl_readb,
sl_readb,
-sl_readb,
+sl_readl,
};
CPUWriteMemoryFunc *sl_writefn[] = {
sl_writeb,
--- orig/raw2flash.cWed May 2 00:35:49 2007
+++ new/raw2flash.c Sun Jul 29 01:56:50 2007
@@ -203,12 +203,14 @@
}
*partition = 1;
case 1:
+#ifndef FULLIMAGE
if (count - PARTITION_START PARTITION_START) {
memcpy(buffer, jffs_buffer + count - PARTITION_START,
ecc-style-eccbytes);
*len = ecc-style-eccbytes;
break;
}
+#endif
while (*len ecc-style-eccbytes) {
ret = TFR(read(0, buffer + *len, 0x800 - *len));
@@ -254,8 +256,10 @@
fprintf(stderr, [);
# endif
+#ifndef FULLIMAGE
/* Skip first 10 bytes */
TFR(read(0, buffer, 0x10));
+#endif
len = 0;
jffs = (uint8_t *) malloc(PARTITION_START);
Re: [Qemu-devel] qemu-system-arm -M akita/terrier - which roms work? (have first patches now :)
On Sat, Jul 28, 2007 at 12:27:33AM +0200, andrzej zaborowski wrote:
On 28/07/07, andrzej zaborowski [EMAIL PROTECTED] wrote:
On 26/07/07, Juergen Lock [EMAIL PROTECTED] wrote:
Okay I got a little further now...
On Wed, Jul 25, 2007 at 10:13:42PM +0200, andrzej zaborowski wrote:
On 24/07/07, Juergen Lock [EMAIL PROTECTED] wrote:
I was under the impression that -append doesnt work, is this wrong?
Also /proc/cmdline on the zaurus is
console=ttyS0 root=/dev/mtdblock2
mtdparts=sharpsl-nand:[EMAIL PROTECTED](smf),[EMAIL
PROTECTED](root),-(home)
jffs2_orphaned_inodes=delete EQUIPMENT=5 LOGOLANG=1 DEFYEAR=2007 LOGO=1
LAUNCH=q
and even when I do pass that with -append to qemu I still dont get
anything on the serial console. So maybe the problem is just missing
kernel commandline... Can -append be fixed?
No, not in qemu :( zaurus kernels don't accept any parameters from
bootloaders, that's because they use the
arch/arm/boot/compressed/head-sharpsl.S file instead of the generic
arm head.S. Set the parameters in your .config.
Actually... at least the sharp kernel does in fact take args as
I found out, but it wants them in the old-style struct param_struct
as defined in linux/include/asm-arm/setup.h (because of
CONFIG_SHARPSL_BOOTLDR_PARAMS e.g. in linux/arch/arm/mach-pxa/corgi.c)
This must be only in the Sharp's kernel because 2.6 doesn't have it.
Well its also a 2.4 kernel...
I've prepared a patch that adds an -old-param flag to qemu (to be used
together with -append), see patch-arm-oldparms (attached). And the
reason I got nothing on ttyS0 was simply that the sharp kernel had
CONFIG_SERIAL_CONSOLE unset... (as seen e.g. in
linux/arch/arm/def-configs/terrier-j)
Great, I merged the patch, hopefully I didn't break anything. I think
the hardcoded root device shouldn't be much problem, if there's anyone
interested, they can change it.
I'm wondering if there's a way to autodetect older Linux kernels
through some magic numbers and automatically set up the old style boot
parameters, and get rid of the -old-param switch.
I though about that too, but in the end didn't bother... also kernels
w/o CONFIG_SHARPSL_BOOTLDR_PARAMS will still understand the new-style
params, its just this code in linux/arch/arm/mach-pxa/corgi.c
that forces use of the old-style struct:
...
#ifdef CONFIG_SHARPSL_BOOTLDR_PARAMS
if (params-u1.s.page_size != PAGE_SIZE) {
params-u1.s.page_size = PAGE_SIZE;
params-u1.s.nr_pages = 32 * 1024 * 1024 / PAGE_SIZE;
params-u1.s.ramdisk_size = 0;
params-u1.s.flags = FLAG_READONLY | FLAG_RDLOAD | FLAG_RDPROMPT;
params-u1.s.rootdev = ROOT_DEV;
params-u1.s.initrd_start = 0;
params-u1.s.initrd_size = 0;
params-u1.s.rd_start = 0;
params-u1.s.system_rev = 0;
params-u1.s.system_serial_low = 0;
params-u1.s.system_serial_high = 0;
strcpy(params-commandline, CONFIG_CMDLINE);
}
#endif
...
Could be, but can `info jit' also show no change then? (qemu is still
using all the cpu time it can get.)
Oh, then maybe it really hangs. I have only tested 2.6 kernels from
different trees (but they were all descendants of linus' tree more
than Sharp's) and OpenBSD (some post 4.0 cvs checkout). It's possible
that Sharp kernels depend on something that is set up by the Sharp
PROM code, which is closed-source (the one that runs the japanese
menu). It should be possible to run it in qemu though.
I've managed to build a sharp kernel with a modified config now
(sidux live cd to the rescue!) and then saw that its hanging after the
sound init. built a cross gdb (which was easier than I thought, luckily
qemu's gdbserver listens on the network so I didn't even have to build
a qemu snapshot on linux :), and found it hanging in a tight loop
waiting for bit 0 (TNF) of SASR0 in corgi_i2s_write in
linux/drivers/sound/pxa-i2s_spitz.c . Patched that (not sure its
right but it works for me, see patch-pxa-audio),
Yes, I think your fix is correct, also merged. I don't know why I
missed this bit.
(drivers/sound/ doesn't exist in 2.6 either)
Yeah 2.6 has switched from oss to alsa...
and now I get lots of
nand ecc errors and mount failures, I guess the mtdparts= arg isnt right
yet and/or the raw2flash.c source needs fixing...
Likely the input to raw2flash.c was not what it expected. It expects a
1:1 image of the entire flash chip (but excluding oob - only data that
can be normally read from /dev/mtblock* and in the same order), and
(/dev/mtdblock*)
with a 10 byte header at the start of the file, which is discarded.
(rather 16)
The partitions layout also matters. This format is the one that
OpenEmbedded outputs, but maybe the original format
Re: [Qemu-devel] qemu-system-arm -M akita/terrier - which roms work? (have first patches now :)
Okay I got a little further now...
On Wed, Jul 25, 2007 at 10:13:42PM +0200, andrzej zaborowski wrote:
On 24/07/07, Juergen Lock [EMAIL PROTECTED] wrote:
I was under the impression that -append doesnt work, is this wrong?
Also /proc/cmdline on the zaurus is
console=ttyS0 root=/dev/mtdblock2
mtdparts=sharpsl-nand:[EMAIL PROTECTED](smf),[EMAIL PROTECTED](root),-(home)
jffs2_orphaned_inodes=delete EQUIPMENT=5 LOGOLANG=1 DEFYEAR=2007 LOGO=1
LAUNCH=q
and even when I do pass that with -append to qemu I still dont get
anything on the serial console. So maybe the problem is just missing
kernel commandline... Can -append be fixed?
No, not in qemu :( zaurus kernels don't accept any parameters from
bootloaders, that's because they use the
arch/arm/boot/compressed/head-sharpsl.S file instead of the generic
arm head.S. Set the parameters in your .config.
Actually... at least the sharp kernel does in fact take args as
I found out, but it wants them in the old-style struct param_struct
as defined in linux/include/asm-arm/setup.h (because of
CONFIG_SHARPSL_BOOTLDR_PARAMS e.g. in linux/arch/arm/mach-pxa/corgi.c)
I've prepared a patch that adds an -old-param flag to qemu (to be used
together with -append), see patch-arm-oldparms (attached). And the
reason I got nothing on ttyS0 was simply that the sharp kernel had
CONFIG_SERIAL_CONSOLE unset... (as seen e.g. in
linux/arch/arm/def-configs/terrier-j)
Could be, but can `info jit' also show no change then? (qemu is still
using all the cpu time it can get.)
Oh, then maybe it really hangs. I have only tested 2.6 kernels from
different trees (but they were all descendants of linus' tree more
than Sharp's) and OpenBSD (some post 4.0 cvs checkout). It's possible
that Sharp kernels depend on something that is set up by the Sharp
PROM code, which is closed-source (the one that runs the japanese
menu). It should be possible to run it in qemu though.
I've managed to build a sharp kernel with a modified config now
(sidux live cd to the rescue!) and then saw that its hanging after the
sound init. built a cross gdb (which was easier than I thought, luckily
qemu's gdbserver listens on the network so I didn't even have to build
a qemu snapshot on linux :), and found it hanging in a tight loop
waiting for bit 0 (TNF) of SASR0 in corgi_i2s_write in
linux/drivers/sound/pxa-i2s_spitz.c . Patched that (not sure its
right but it works for me, see patch-pxa-audio), and now I get lots of
nand ecc errors and mount failures, I guess the mtdparts= arg isnt right
yet and/or the raw2flash.c source needs fixing...
Installing debian however should not
depend on what rom you use, afterall debian is supposed to replace the
contents.
Well I dont want to replace the contents, I want to run debian in
addition to the sharp stuff in a chroot :) See e.g. here,
http://wiki.debian.org/PocketWorkstation
and under `Installing Debian/PocketWorkstation' here:
http://www.users.on.net/~hluc/myZaurus/jumbo/xqtjumbo.html
(these instructions and packages are a bit dated and not directly for
c3200 which is one of the reasons i'd like to test/prepare things
using qemu.)
I still think that debian shouldn't care about what was your original
distribution or what distribution hosts the chroot environment.
In an ideal world... At least it interacts with the (old in this case)
kernel, and also the xserver (x/qt) that will run outside the chroot.
Thanx,
Juergen
Index: qemu/hw/arm_boot.c
@@ -76,6 +76,76 @@
stl_raw(p++, 0);
}
+static void set_kernel_args_old(uint32_t ram_size, int initrd_size,
+const char *kernel_cmdline,
+target_phys_addr_t loader_start)
+{
+uint32_t *p;
+unsigned char *s;
+
+/* see linux/include/asm-arm/setup.h */
+p = (uint32_t *)(phys_ram_base + KERNEL_ARGS_ADDR);
+/* page_size */
+stl_raw(p++, 4096);
+/* nr_pages */
+stl_raw(p++, ram_size / 4096);
+/* ramdisk_size */
+stl_raw(p++, 0);
+#define FLAG_READONLY 1
+#define FLAG_RDLOAD4
+#define FLAG_RDPROMPT 8
+/* flags */
+stl_raw(p++, FLAG_READONLY | FLAG_RDLOAD | FLAG_RDPROMPT);
+/* rootdev */
+stl_raw(p++, (31 8) | 0); /* /dev/mtdblock0 */
+/* video_num_cols */
+stl_raw(p++, 0);
+/* video_num_rows */
+stl_raw(p++, 0);
+/* video_x */
+stl_raw(p++, 0);
+/* video_y */
+stl_raw(p++, 0);
+/* memc_control_reg */
+stl_raw(p++, 0);
+/* unsigned char sounddefault */
+/* unsigned char adfsdrives */
+/* unsigned char bytes_per_char_h */
+/* unsigned char bytes_per_char_v */
+stl_raw(p++, 0);
+/* pages_in_bank[4] */
+stl_raw(p++, 0);
+stl_raw(p++, 0);
+stl_raw(p++, 0);
+stl_raw(p++, 0);
+/* pages_in_vram */
+stl_raw(p++, 0);
+/* initrd_start */
+if (initrd_size)
+ stl_raw(p++, loader_start + INITRD_LOAD_ADDR);
+else
+ stl_raw(p
Re: [Qemu-devel] qemu-system-arm -M akita/terrier - which roms work? (and cursor issue)
In article [EMAIL PROTECTED] you write: On 24/07/07, Juergen Lock [EMAIL PROTECTED] wrote: Hi! I just played with this a bit and although I got the stuff at http://pokylinux.org/releases/clyde-2.0/ somewhat working (tried the akita ones going after http://butterfeet.org/?m=200705 , I seem to miss -showcursor and consequently got no cursor which made navigating the gui a `little' difficult... :) - anyway (-show-cursor worked, thx!) I couldnt get the sharp rom kernel to boot further than showing the splash screen with a blinking cursor (i tried terrier and akita ones, That would suggest that it's hanging somewhere in the userspace (but not necessarily). Hmm maybe, after a while the cursor stops blinking... Have you tried booting with no init scripts? (e.g. init=/bin/sh) I was under the impression that -append doesnt work, is this wrong? Also /proc/cmdline on the zaurus is console=ttyS0 root=/dev/mtdblock2 mtdparts=sharpsl-nand:[EMAIL PROTECTED](smf),[EMAIL PROTECTED](root),-(home) jffs2_orphaned_inodes=delete EQUIPMENT=5 LOGOLANG=1 DEFYEAR=2007 LOGO=1 LAUNCH=q and even when I do pass that with -append to qemu I still dont get anything on the serial console. So maybe the problem is just missing kernel commandline... Can -append be fixed? Otherwise do you have sources for the kernel you're using so that you could enable initcalls debugging in its config? Kernel source can apparently be downloaded here, http://support.ezaurus.com/developer/source/source_dl.asp (page is in japanese, but you can look at the links and filenames), but to build it i guess I'd have to update my linux installation first and then figure out how to cross-build a kernel... they both seem to hang somewhere regardless of a proper -mtdblock passed or even none, at least info registers in the monitor showed no changes.) When you issue info registers more than likely the kernel is always in the idle loop saving the battery power, so it will almost always show the same values, even if there are actually processes running and doing some work. Could be, but can `info jit' also show no change then? (qemu is still using all the cpu time it can get.) Anyone know which roms work? atm I want to play with debian for the existing sharp rom that i have on the zaurus (a c3200), so a rom thats at least similar to sharp would be preferable... Unfortunately I have no physical zaurus, so no access to any Sharp rom because they are copyrighted. Hmm they are also available e.g. here (english version, clink on model below `Downloads' in the left column, then look for `NAND-Backup'): http://trisoft.de/downloads.htm (see below for the hack I used to convert the .dbk files to a raw image) There's also cacko, http://my-zaurus.narod.ru/cacko.html which may be similar enough to the sharp rom, but I haven't yet tried it. Installing debian however should not depend on what rom you use, afterall debian is supposed to replace the contents. Well I dont want to replace the contents, I want to run debian in addition to the sharp stuff in a chroot :) See e.g. here, http://wiki.debian.org/PocketWorkstation and under `Installing Debian/PocketWorkstation' here: http://www.users.on.net/~hluc/myZaurus/jumbo/xqtjumbo.html (these instructions and packages are a bit dated and not directly for c3200 which is one of the reasons i'd like to test/prepare things using qemu.) And now the .dbk extraction hack, adapted from the mountjffs script in this thread, http://www.oesf.org/forums/index.php?showtopic=22034 (I didn't really clean up all the comments; run e.g. as ./dumpjffs.sh c3200all all SYSTC320.DBK , assumes 128MB size. If you want to extract parts i.e. `rom' or `root' or `user' instead of `all' you may need to adjust ROOTFS and/or ROMFS below too.) ---cut-here- #!/bin/bash ### # # Copyright (C) 2007 SCL Internet #www.scl.co.uk # # Original Author: John Sutton [EMAIL PROTECTED] # # $Id: dumpjffs$ # # This program is free software; you can redistribute it and/or modify # it under the terms of the GNU General Public License as published by # the Free Software Foundation; either version 2 of the License, or # (at your option) any later version. # # This program is distributed in the hope that it will be useful, # but WITHOUT ANY WARRANTY; without even the implied warranty of # MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the # GNU General Public License for more details. # # You should have received a copy of the GNU General Public License # along with this program; if not, write to the Free Software # Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. # ### # # dumpjffs : a shell script for extracting the jffs filesystems which
[Qemu-devel] vnc with german keymap
Hi!
I got a report yesterday of -vnc not working right with german
keymaps (I hadn't really played with -vnc yet so I hadn't noticed),
and came up with the following hack: (which still needs -k de,
that just wasn't enough)
Index: qemu/vnc.c
@@ -763,7 +763,31 @@
{
int keycode;
+#if 1
+/* XXX fixup some de keysyms (use with -k de) */
+if ((sym 0x) == 0xfe03)/* Alt_Gr - Alt_R */
+ sym = 0xffea;
+if ((sym 0x) == 0xfe50)/* grave */
+ sym = '`';
+#if 0
+if ((sym 0x) == 0xfe51)/* '/acute (gets mixed up with #) */
+ sym = '\'';
+#endif
+if ((sym 0x) == 0xfe52)/* asciicircum */
+ sym = '^';
+if ((sym 0x) == 0xfe53)/* asciitilde */
+ sym = '~';
+#endif
keycode = keysym2scancode(vs-kbd_layout, sym 0x);
+#if 1
+/* '/acute key needs special treatment */
+if (!keycode (sym 0x) == 0xfe51)/* acute */
+ keycode = 0xd;
+#endif
+#ifdef VNCDEBUGKEYS
+printf(do_key_event down %d, sym 0x%x, keycode 0x%x\n,
+ down, (int) sym, keycode);
+#endif
/* QEMU console switch */
switch(keycode) {
I wasn't able to fix this by editing vnc_keysym.h and/or keymaps
because those dont take duplicate definitions, but this is certainly
`somewhat' ugly; anyone care to fix it for real? :)
Thanx,
Juergen
Re: [Qemu-devel] QEMU Various Vulnerabilities
In article [EMAIL PROTECTED] Kirill A. Shutemov wrote: On [Wed, 02.05.2007 18:21], malc wrote: On Wed, 2 May 2007, Kirill A. Shutemov wrote: =20 http://secunia.com/advisories/25073/ Any comments ? =20 AAM - http://lists.gnu.org/archive/html/qemu-devel/2007-04/msg00650.html SB16/DMA - in attachment Thanks. Other Vulnerabilities? Yesterday I added the debian security patch (90_security.patch from http://security.debian.org/pool/updates/main/q/qemu/qemu_0.8.2-4etch1.diff.gz ) to the FreeBSD qemu ports (had to modify it slightly), cvsweb location of the one for qemu 0.9.0 is here, http://www.freebsd.org/cgi/cvsweb.cgi/ports/emulators/qemu/files/patch-90_security and the one for the 20070405 cvs snapshot is here, http://www.freebsd.org/cgi/cvsweb.cgi/ports/emulators/qemu-devel/files/patch-90_security (I haven't checked if it still applies to today's cvs, but it might :) I also disabled the -vmwarevga acceleration code because of the missing range checks, cvsweb of that patch is here, http://www.freebsd.org/cgi/cvsweb.cgi/ports/emulators/qemu-devel/files/patch-hw-vmware_vga.c HTH, Juergen
Re: [Qemu-devel] [Patch] eepro100 issues
In article [EMAIL PROTECTED] you write: -=-=-=-=-=- The crashs are caused by transmit descriptors with packet sizes larger than the buffer which is defined in the driver. Using netperf or rsync will always result in a buffer overflow and crash QEMU with the current eepro100 driver. Up to now I could not find the reason for these large packet sizes. My patch now just ignores data which does not fit in a normal frame. Netperf and rsync no longer crash when the patch is applied. Thanx, that seems to fix my crashes. Juergen
[Qemu-devel] -vmwarevga issues
I just tried this new toy and found these things: 1. Has it been tested with xorg 7.1.0 guests? I booted http://debian.tu-bs.de/project/sidux/release/SIDUX-2007-01-200702210759-CHAOS.ISO (see http://www.sidux.com/Article116.html , it is based on debian sid and has has xorg 7.1.0) and it detected the vmware vga, but hung when trying to start X. 2. And with http://ftp.us.freesbie.org/pub/FreeSBIE/2.0.1-RELEASE/FreeSBIE-2.0.1-RELEASE.iso (see http://www.freesbie.org/ , based on FreeBSD 6.2 and using xorg 6.9.0) it worked (after editing `Driver vmware' into xorg.conf because its xorg autoconfiguration didnt know that card), but caused both the ne2kpci (ed0) and es1370 (pcm0) cards not to be detected: (from bootverbose dmesg:) ed0: RealTek 8029 port 0xfb00-0xfbff irq 11 at device 3.0 on pci0 device_attach: ed0 attach returned 2 pcm0: AudioPCI ES1370 port 0xfc00-0xfcff irq 9 at device 4.0 on pci0 pcm0: unable to map register space (both are detected and work when using the default cirrus vga.) Interestingly, the new eepro100 nic which I also tried (i82559er == fxp0, see other post) still worked... And I just tried the rtl8139 nic (re0) which also didn't work, saying: re0: couldn't map ports/memory rl0: couldn't map ports/memory (the rl driver also matches for this pci id, but would use non-C+ mode which eats more cpu.) Hope this is helpful to some :) Juergen
[Qemu-devel] Re: -vmwarevga issues
On Thu, Apr 05, 2007 at 10:13:22PM +0200, I wrote: ... 2. And with http://ftp.us.freesbie.org/pub/FreeSBIE/2.0.1-RELEASE/FreeSBIE-2.0.1-RELEASE.iso (see http://www.freesbie.org/ , based on FreeBSD 6.2 and using xorg 6.9.0) it worked (after editing `Driver vmware' into xorg.conf because its xorg autoconfiguration didnt know that card), but caused both the ne2kpci (ed0) and es1370 (pcm0) cards not to be detected: (from bootverbose dmesg:) ed0: RealTek 8029 port 0xfb00-0xfbff irq 11 at device 3.0 on pci0 device_attach: ed0 attach returned 2 pcm0: AudioPCI ES1370 port 0xfc00-0xfcff irq 9 at device 4.0 on pci0 pcm0: unable to map register space (both are detected and work when using the default cirrus vga.) Hmm I just found qemu that I had left running hang (monitor, on stdio, not responding), attaching gdb found it here: Script started on Thu Apr 5 22:29:42 2007 % gdb work/qemu-snapshot-2007-04-05_05/i386-softmmu/qemu 24677 GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as i386-marcel-freebsd... Attaching to program: /ad4/usr/ports/emulators/qemu-devel/work/qemu-snapshot-2007-04-05_05/i386-softmmu/qemu, process 24677 Reading symbols from /lib/libm.so.4...done. Loaded symbols for /lib/libm.so.4 Reading symbols from /lib/libz.so.3...done. Loaded symbols for /lib/libz.so.3 Reading symbols from /usr/local/lib/libSDL.so.11...done. Loaded symbols for /usr/local/lib/libSDL.so.11 Reading symbols from /lib/libutil.so.5...done. Loaded symbols for /lib/libutil.so.5 Reading symbols from /usr/lib/libpthread.so.2...done. warning: Unable to get location for thread creation breakpoint: generic error [New LWP 100167] Loaded symbols for /usr/lib/libpthread.so.2 Reading symbols from /lib/libc.so.6...done. Loaded symbols for /lib/libc.so.6 Reading symbols from /usr/local/lib/libiconv.so.3...done. Loaded symbols for /usr/local/lib/libiconv.so.3 Reading symbols from /usr/X11R6/lib/libX11.so.6...done. Loaded symbols for /usr/X11R6/lib/libX11.so.6 Reading symbols from /usr/X11R6/lib/libXext.so.6...done. Loaded symbols for /usr/X11R6/lib/libXext.so.6 Reading symbols from /usr/X11R6/lib/libXrandr.so.2...done. Loaded symbols for /usr/X11R6/lib/libXrandr.so.2 Reading symbols from /usr/X11R6/lib/libXrender.so.1...done. Loaded symbols for /usr/X11R6/lib/libXrender.so.1 Reading symbols from /usr/local/lib/libvga.so.1...done. Loaded symbols for /usr/local/lib/libvga.so.1 Reading symbols from /usr/lib/libvgl.so.4...done. Loaded symbols for /usr/lib/libvgl.so.4 Reading symbols from /usr/local/lib/libaa.so.1...done. Loaded symbols for /usr/local/lib/libaa.so.1 Reading symbols from /usr/lib/libusbhid.so.2...done. Loaded symbols for /usr/lib/libusbhid.so.2 Reading symbols from /lib/libncurses.so.6...done. Loaded symbols for /lib/libncurses.so.6 Reading symbols from /usr/X11R6/lib/X11/locale/lib/common/xlcDef.so.2...done. Loaded symbols for /usr/X11R6/lib/X11/locale/lib/common/xlcDef.so.2 Reading symbols from /usr/X11R6/lib/X11/locale/lib/common/ximcp.so.2...done. Loaded symbols for /usr/X11R6/lib/X11/locale/lib/common/ximcp.so.2 Reading symbols from /usr/X11R6/lib/libXcursor.so.1...done. Loaded symbols for /usr/X11R6/lib/libXcursor.so.1 Reading symbols from /usr/X11R6/lib/libXfixes.so.3...done. Loaded symbols for /usr/X11R6/lib/libXfixes.so.3 Reading symbols from /libexec/ld-elf.so.1...done. Loaded symbols for /libexec/ld-elf.so.1 [Switching to LWP 100167] 0x282bf776 in memmove () from /lib/libc.so.6 (gdb) bt #0 0x282bf776 in memmove () from /lib/libc.so.6 #1 0x080afc3e in vmsvga_fifo_run (s=0x9ba71d4) at /ad4/usr/ports/emulators/qemu-devel/work/qemu-snapshot-2007-04-05_05/hw/vmware_vga.c:373 #2 0x080b029c in vmsvga_update_display (opaque=0x9ba71d4) at /ad4/usr/ports/emulators/qemu-devel/work/qemu-snapshot-2007-04-05_05/hw/vmware_vga.c:862 #3 0x08057f54 in vga_hw_update () at /ad4/usr/ports/emulators/qemu-devel/work/qemu-snapshot-2007-04-05_05/console.c:149 #4 0x080b1e30 in sdl_refresh (ds=0x8130760) at /ad4/usr/ports/emulators/qemu-devel/work/qemu-snapshot-2007-04-05_05/sdl.c:344 #5 0x08050a61 in gui_update (opaque=0x0) at /ad4/usr/ports/emulators/qemu-devel/work/qemu-snapshot-2007-04-05_05/vl.c:6146 #6 0x0804bf05 in qemu_run_timers (ptimer_head=0x81307cc, current_time=Unhandled dwarf expression opcode 0x93 ) at /ad4/usr/ports/emulators/qemu-devel/work/qemu-snapshot-2007-04-05_05/vl.c:882 #7 0x0805150d in main_loop_wait (timeout=0) at /ad4/usr/ports/emulators/qemu-devel/work/qemu-snapshot-2007-04-05_05/vl.c:6400 #8 0x0805161d in main_loop () ---Type return to continue, or q return to quit--- at
[Qemu-devel] eepro100 issues
Hi again! I also played with the new eepro100 nic and found these things: 1. i82557b seem to work with http://debian.tu-bs.de/project/sidux/release/SIDUX-2007-01-200702210759-CHAOS.ISO (see http://www.sidux.com/Article116.html , it is based on debian sid), but 2. i82551 and i82559er with the same livecd sooner or later will cause qemu to crash like this with no backtrace available: % gdb work/qemu-snapshot-2007-04-05_05/i386-softmmu/qemu qemu.core GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as i386-marcel-freebsd... Core was generated by `qemu'. Program terminated with signal 11, Segmentation fault. Reading symbols from /lib/libm.so.4...done. Loaded symbols for /lib/libm.so.4 Reading symbols from /lib/libz.so.3...done. Loaded symbols for /lib/libz.so.3 Reading symbols from /usr/local/lib/libSDL.so.11...done. Loaded symbols for /usr/local/lib/libSDL.so.11 Reading symbols from /lib/libutil.so.5...done. Loaded symbols for /lib/libutil.so.5 Reading symbols from /usr/lib/libpthread.so.2...done. Loaded symbols for /usr/lib/libpthread.so.2 Reading symbols from /lib/libc.so.6...done. Loaded symbols for /lib/libc.so.6 Reading symbols from /usr/local/lib/libiconv.so.3...done. Loaded symbols for /usr/local/lib/libiconv.so.3 Reading symbols from /usr/X11R6/lib/libX11.so.6...done. Loaded symbols for /usr/X11R6/lib/libX11.so.6 Reading symbols from /usr/X11R6/lib/libXext.so.6...done. Loaded symbols for /usr/X11R6/lib/libXext.so.6 Reading symbols from /usr/X11R6/lib/libXrandr.so.2...done. Loaded symbols for /usr/X11R6/lib/libXrandr.so.2 Reading symbols from /usr/X11R6/lib/libXrender.so.1...done. Loaded symbols for /usr/X11R6/lib/libXrender.so.1 Reading symbols from /usr/local/lib/libvga.so.1...done. Loaded symbols for /usr/local/lib/libvga.so.1 Reading symbols from /usr/lib/libvgl.so.4...done. Loaded symbols for /usr/lib/libvgl.so.4 Reading symbols from /usr/local/lib/libaa.so.1...done. Loaded symbols for /usr/local/lib/libaa.so.1 Reading symbols from /usr/lib/libusbhid.so.2...done. Loaded symbols for /usr/lib/libusbhid.so.2 Reading symbols from /lib/libncurses.so.6...done. Loaded symbols for /lib/libncurses.so.6 Reading symbols from /usr/X11R6/lib/X11/locale/lib/common/xlcDef.so.2...done. Loaded symbols for /usr/X11R6/lib/X11/locale/lib/common/xlcDef.so.2 Reading symbols from /usr/X11R6/lib/X11/locale/lib/common/ximcp.so.2...done. Loaded symbols for /usr/X11R6/lib/X11/locale/lib/common/ximcp.so.2 Reading symbols from /usr/X11R6/lib/libXcursor.so.1...done. Loaded symbols for /usr/X11R6/lib/libXcursor.so.1 Reading symbols from /usr/X11R6/lib/libXfixes.so.3...done. Loaded symbols for /usr/X11R6/lib/libXfixes.so.3 Reading symbols from /libexec/ld-elf.so.1...done. Loaded symbols for /libexec/ld-elf.so.1 #0 0x in ?? () [New LWP 100186] (gdb) q (this first occured when playing with -smb in runlevel 2 which can be mounted like this: # mount.smbfs //10.0.2.4/qemu /mnt and then dd'ing a bigger file to /dev/null, I was trying to test network throughput... but once it even crashed like that just while typing the mount command.) 3. And with http://ftp.us.freesbie.org/pub/FreeSBIE/2.0.1-RELEASE/FreeSBIE-2.0.1-RELEASE.iso (see http://www.freesbie.org/ , based on FreeBSD 6.2) i82557b and i82559er worked, but 4. i82551 attached but would not receive packets. Hope this is helpful to some :) Juergen
[Qemu-devel] Re: strange crash on FreeBSD-current/amd64 (pointer truncation?)
On Wed, Jan 24, 2007 at 09:00:19PM +0100, Juergen Lock wrote:
Hi!
I got a report of qemu segfaulting here on FreeBSD-current/amd64:
#0 main_loop () at
/usr/ports-cvs/emulators/qemu/work/qemu-snapshot-2007-01-11_05/vl.c:6125
6125env = env-next_cpu;
[New Thread 0x801e10190 (LWP 100214)]
(gdb) print env
$1 = (CPUX86State *) 0xac1
(gdb) print first_cpu
$2 = (CPUX86State *) 0x80ac1
Ok Jung-uk Kim found the following fix: (Thanx!)
--- qemu/cpu-exec.c.origWed Jan 31 16:58:03 2007
+++ qemu/cpu-exec.c Wed Jan 31 17:08:11 2007
@@ -226,9 +226,9 @@
int cpu_exec(CPUState *env1)
{
-int saved_T0, saved_T1;
+long saved_T0, saved_T1;
#if defined(reg_T2)
-int saved_T2;
+long saved_T2;
#endif
CPUState *saved_env;
#if defined(TARGET_I386)
It's funny that the upper half of rbx (which holds env above)
apparently only gets spilled on FreeBSD-current, even tho on amd64
T0 (== AREG1 == rbx) certainly doesn't fit into an int...
Juergen
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] Jung-uk Kim found another bug, this time acpi
Hi! The bios wasn't clearing RSDT before checksum calculation, causing FreeBSD/amd64 SMP guests to fail booting. His post with fix is here: http://docs.freebsd.org/cgi/mid.cgi?200702011502.56443.jkim Juergen ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] strange crash on FreeBSD-current/amd64 (pointer truncation?)
Hi! I got a report of qemu segfaulting here on FreeBSD-current/amd64: #0 main_loop () at /usr/ports-cvs/emulators/qemu/work/qemu-snapshot-2007-01-11_05/vl.c:6125 6125env = env-next_cpu; [New Thread 0x801e10190 (LWP 100214)] (gdb) print env $1 = (CPUX86State *) 0xac1 (gdb) print first_cpu $2 = (CPUX86State *) 0x80ac1 This works on earlier FreeBSD branches, and the build logs, http://pointyhat.freebsd.org/errorlogs/amd64-7-latest-logs/qemu-0.8.2s.20070111.log http://pointyhat.freebsd.org/errorlogs/amd64-6-latest-logs/qemu-0.8.2s.20070111.log (7 is the -current branch and 6 is the branch that the latest release, 6.2, was branched off) show no differences in compiler warnings, so I'm a bit at a loss where to look for the problem. So the qeustion is: Has anyone seen something like this or has a helpful idea? Thanx, Juergen ___ 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
[Qemu-devel] weird slirp problems (dns lookups stopped working, and maybe more)
Hi!
I'm not sure why I didn't notice signs of this earlier (using the
Dec 25 snapshot, I'm on FreeBSD), maybe I really only talked to the host
(10.0.2.2) from inside guests. Anyway, after I first saw it yesterday
night, today I sniffed on the external interface and saw dns requests
of a `host google.com' going out to 224.0.0.251, port 5353, instead
of the dns in resolv.conf. Hmm? And when I patched slirp like this:
Index: qemu/slirp/slirp.c
@@ -130,6 +130,7 @@
void slirp_init(void)
{
//debug_init(/tmp/slirp.log, DEBUG_DEFAULT);
+debug_init(/usr/tmp/slirp.log, DEBUG_DEFAULT);
#ifdef _WIN32
{
Index: qemu/slirp/udp.c
@@ -104,6 +104,9 @@
*/
ip = mtod(m, struct ip *);
uh = (struct udphdr *)((caddr_t)ip + iphlen);
+#if 1
+ DEBUG_MISC((dfd, udp_input(), ip_dst.s_addr=0x%x, uh_dport=%d\n,
ntohl(ip-ip_dst.s_addr), ntohs(uh-uh_dport)));
+#endif
/*
* Make mbuf data length reflect UDP length.
it indeed shows slirp is getting the dest ip + port correctly and
then sends them out wrong:
...
m_get...
m = 9bd7800
ip_input...
m = 9bd7800
m_len = 56
udp_input...
m = 9bd7800
iphlen = 20
udp_input(), ip_dst.s_addr=0xa000203, uh_dport=53
sosendto...
so = 9b39b80
m = 9bd7800
sendto()ing, addr.sin_port=5353, addr.sin_addr.s_addr=224.0.0.251
m_free...
m = 9bd7000
ip_slowtimo...
tcp_slowtimo...
...
In between I see these which I'm not sure where they are coming from:
...
m_get...
m = 9bd7800
ip_input...
m = 9bd7800
m_len = 74
udp_input...
m = 9bd7800
iphlen = 20
udp_input(), ip_dst.s_addr=0xe0fb, uh_dport=5353
sosendto...
so = 9b39b80
m = 9bd7800
sendto()ing, addr.sin_port=5353, addr.sin_addr.s_addr=224.0.0.251
m_free...
m = 9bd7000
ip_slowtimo...
tcp_slowtimo...
m_get...
m = 9bd7000
ip_input...
m = 9bd7000
m_len = 74
udp_input...
m = 9bd7000
iphlen = 20
udp_input(), ip_dst.s_addr=0xe0fb, uh_dport=5353
sosendto...
so = 9b39b80
m = 9bd7000
sendto()ing, addr.sin_port=5353, addr.sin_addr.s_addr=224.0.0.251
m_free...
m = 9bd7800
ip_slowtimo...
tcp_slowtimo...
ip_slowtimo...
tcp_slowtimo...
And this is my try giving the real dns (which worked yesterday btw):
m_get...
m = 9bd7800
ip_input...
m = 9bd7800
m_len = 56
udp_input...
m = 9bd7800
iphlen = 20
udp_input(), ip_dst.s_addr=0xd9ed958e, uh_dport=53
sosendto...
so = 9b39b80
m = 9bd7800
sendto()ing, addr.sin_port=5353, addr.sin_addr.s_addr=224.0.0.251
m_free...
m = 9bd7000
ip_slowtimo...
tcp_slowtimo...
...
I also got a report which stated that for him also tcp stopped working,
while I still can do http://google.com's ip and get the expected page,
and as said I can also ssh (and scp) to the host (10.0.2.2).
Soo, does anyone know slirp enough to have an idea whats going on here?
The puzzling thing is I don't see recent slirp commits that could be
relevant either...
Thanx,
Juergen
___
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 Tue, Jan 09, 2007 at 09:47:40PM +0100, Juergen Lock wrote: Hi! I'm not sure why I didn't notice signs of this earlier (using the Dec 25 snapshot, I'm on FreeBSD), maybe I really only talked to the host (10.0.2.2) from inside guests. Anyway, after I first saw it yesterday night, today I sniffed on the external interface and saw dns requests of a `host google.com' going out to 224.0.0.251, port 5353, instead of the dns in resolv.conf. [...] In between I see these which I'm not sure where they are coming from: ... m_get... m = 9bd7800 ip_input... m = 9bd7800 m_len = 74 udp_input... m = 9bd7800 iphlen = 20 udp_input(), ip_dst.s_addr=0xe0fb, uh_dport=5353 sosendto... so = 9b39b80 m = 9bd7800 sendto()ing, addr.sin_port=5353, addr.sin_addr.s_addr=224.0.0.251 m_free... m = 9bd7000 ip_slowtimo... tcp_slowtimo... ... 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... (Now why tcp stopped working for the other guy I still don't know...) Thanx, Juergen ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] scsi emulation crash with linux guests
Hi! playing with -disk scsi and a linux guest I get this, $ qemu -monitor stdio -cdrom /home/nox/iso/KNOPPIX_V5.0.1CD-2006-06-01-DE.iso -m 256 -usb -soundhw es1370 -net nic,model=rtl8139 -net user -boot d -disk scsi,img=/home/nox/q-61/61.img QEMU 0.8.2 monitor - type 'help' for more information (qemu) lsi_scsi: error: Unhandled writeb 0x5b = 0x52 lsi_scsi: error: Unhandled writeb 0x52 = 0xe0 lsi_scsi: error: Unhandled writeb 0x50 = 0x80 lsi_scsi: error: Unhandled writeb 0x50 = 0x88 lsi_scsi: error: readb 0x51 and qemu exits. Anyone else seeing this? (I tried several other knoppix and kanotix versions too, all crashing like that...) FreeBSD guests see and can mount the image btw (I tried FreeSBIE-2.0-RC1-20061123.iso with ide dma disabled in qemu), relevant boot -v dmesg: sym0: 895a port 0xc300-0xc3ff mem 0xf2001400-0xf20017ff,0xf2002000-0xf2003fff irq 11 at device 5.0 on pci0 sym0: Reserved 0x400 bytes for rid 0x14 type 3 at 0xf2001400 sym0: Reserved 0x2000 bytes for rid 0x18 type 3 at 0xf2002000 sym0: chip clock is 0KHz sym0: No NVRAM, ID 7, Fast-40, LVD, parity checking sym0: open drain IRQ line driver, using on-chip SRAM sym0: using LOAD/STORE-based firmware. sym0: handling phase mismatch from SCRIPTS. sym0: [GIANT-LOCKED] ... pass0 at sym0 bus 0 target 0 lun 0 pass0: QEMU QEMU HARDDISK 0.8. Fixed Direct Access SCSI-3 device pass0: Serial Number pass0: 3.300MB/s transfers, Tagged Queueing Enabled ... da0 at sym0 bus 0 target 0 lun 0 da0: QEMU QEMU HARDDISK 0.8. Fixed Direct Access SCSI-3 device da0: Serial Number da0: 3.300MB/s transfers, Tagged Queueing Enabled da0: 5120MB (10485760 512 byte sectors: 255H 63S/T 652C) Thanx, Juergen ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
