Re: [Qemu-devel] and now bus error for i386 guest
Hi,
Blue Swirl wrote:
On 12/4/07, Shaddy Baddah [EMAIL PROTECTED] wrote:
HI,
Blue Swirl wrote:
On 11/14/07, Shaddy Baddah [EMAIL PROTECTED] wrote:
Hi again,
After further culling the target list, I was able to install qemu on my
sun4u host.
However, running it, I get a bus error. See below for details:
$ /opt/qemu-cvs/bin/qemu -m 128 -cdrom
~/KNOPPIX_V5.1.1CD-2007-01-04-EN.iso -vnc :1
Bus error
For some reason, Sparc Linux host is not working. I think Sparc Solaris is OK.
Yes, I do recall that I was able to get this working on Sparc Solaris.
Anyway, when I get more time, I will have a better stab at debugging
this. I got a start on this today, and here is a bit of cut and paste
that may or may not be insightful. The address for env1 looks questionable:
[EMAIL PROTECTED]:~/qemu-cvs/qemu-build$ gdb --args ./i386-softmmu/qemu
-hda ../../KNOPPIX_V5.1.1CD-2007-01-04-EN.iso -L ../qemu/pc-bios
GNU gdb 6.6.90.20070912-debian
Copyright (C) 2007 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
http://gnu.org/licenses/gpl.html
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type show copying
and show warranty for details.
This GDB was configured as sparc-linux-gnu...
Using host libthread_db library /lib/libthread_db.so.1.
(gdb) run
Starting program: /home/shaddy/qemu-cvs/qemu-build/i386-softmmu/qemu
-hda ../../KNOPPIX_V5.1.1CD-2007-01-04-EN.iso -L ../qemu/pc-bios
[Thread debugging using libthread_db enabled]
[New Thread 0xf7f7b550 (LWP 9363)]
Program received signal SIGBUS, Bus error.
[Switching to Thread 0xf7f7b550 (LWP 9363)]
cpu_x86_exec (env1=0x2) at /home/shaddy/qemu-cvs/qemu/cpu-exec.c:307
307 if (env-exception_index = 0) {
(gdb) info threads
* 1 Thread 0xf7f7b550 (LWP 9363) cpu_x86_exec (env1=0x2)
at /home/shaddy/qemu-cvs/qemu/cpu-exec.c:307
(gdb)
My guess is that Linux glibc overwrites global registers at some
point, like in signal handling or setjmp. The generated code looks OK
and it shouldn't be different from what Solaris version would
generate. I've been thinking of different register design (using
locals or outs) but then the op helpers would need to use different
mechanism to access T0/T1/T2. Compiling Qemu against uClibc could also
show something.
As I will detail later, this problem looks to me to be at least
partially caused by a bug in the compiler optimizer.
PS: couldn't this also be debugged from within qemu VM running Debian
Sparc, for those that don't have access to a real machine? I got a start
on this today as well (because I don't always have access to the Sun
Ultra box). Seems stable, and I was able to get a start on a compile,
that is currently still going.
Nice idea! Do you mean full system emulator or user mode?
I meant full system emulator mode. I was able to successfully compile
inside the guest Sparc(32) Debian Lenny system. However, I couldn't
really run qemu successfully inside the guest system. I was getting a
hang, and I traced that down to a call to glibc's timer_create function,
in the dynticks_start_timer function:
printf(timer_create1\n);
if (timer_create(CLOCK_REALTIME, ev, host_timer)) {
printf(timer_create\n);
perror(timer_create);
/* disable dynticks */
fprintf(stderr, Dynamic Ticks disabled\n);
return -1;
}
printf(timer_create2\n);
the bt shows three threads, and two of which are stuck in some type of
pthread suspend functions, and on stuck in a poll function. I don't know
much about the clocks, so I just randomly tried to select clocks via
-clock option. I tried -clock unix, and got a similar bus error. But all
this precludes what I am about to write with regards to my discoveries
on the compiler optimizer.
Back on the real Sun Ultra box, I did a bit of debug. I found the
following bit of failed code, as described in a capture of my gdb session:
$ gdb --args ./i386-softmmu/qemu -cdrom
../../KNOPPIX_V5.1.1CD-2007-01-04-EN.iso -L ../qemu/pc-bios
GNU gdb 6.6.90.20070912-debian
Copyright (C) 2007 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
http://gnu.org/licenses/gpl.html
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type show copying
and show warranty for details.
This GDB was configured as sparc-linux-gnu...
Using host libthread_db library /lib/libthread_db.so.1.
(gdb) break vl.c:7362
Breakpoint 1 at 0x1e958: file /home/shaddy/qemu-cvs/qemu/vl.c, line 7362.
(gdb) display /i $pc
(gdb) run
Starting program: /home/shaddy/qemu-cvs/qemu-build/i386-softmmu/qemu
-cdrom ../../KNOPPIX_V5.1.1CD-2007-01-04-EN.iso -L ../qemu/pc-bios
[Thread debugging using libthread_db enabled]
[New Thread 0xf7f77550 (LWP 13579)]
[Switching to Thread 0xf7f77550 (LWP 13579)]
Breakpoint 1, main (argc=1430528, argv=0x15d400) at
/home/shaddy/qemu-cvs/qemu/vl.c:7362
7362
Re: [Qemu-devel] and now bus error for i386 guest
Hi,
Blue Swirl wrote:
On 12/5/07, Shaddy Baddah [EMAIL PROTECTED] wrote:
0x1e958 main+13992: ld [ %l6 + 0x8c ], %l1
0x1e95c main+13996: call 0xa90b4 cpu_x86_exec
0x1e960 main+14000: mov %l1, %o0
Maybe you missed the effect of the delay slot. The first argument is
prepared in %l1 and moved to %o0 in the delay slot of the call
instruction.
You'll have to forgive me... although I know about the delay slot, I
only slightly dabble in assembly, so I am not so confident at reading
it. Reading this to mean that perhaps the assignment would be effected
after execution of a further instruction, I've redone the debugging, and
include it below:
$ gdb --args ./i386-softmmu/qemu -cdrom
../../KNOPPIX_V5.1.1CD-2007-01-04-EN.iso -L ../qemu/pc-bios
GNU gdb 6.6.90.20070912-debian
Copyright (C) 2007 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
http://gnu.org/licenses/gpl.html
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type show copying
and show warranty for details.
This GDB was configured as sparc-linux-gnu...
Using host libthread_db library /lib/libthread_db.so.1.
(gdb)
(gdb) break vl.c:7362
Breakpoint 1 at 0x1e958: file /home/shaddy/qemu-cvs/qemu/vl.c, line 7362.
(gdb) display /i $pc
(gdb) run
Starting program: /home/shaddy/qemu-cvs/qemu-optbuild/i386-softmmu/qemu
-cdrom ../../KNOPPIX_V5.1.1CD-2007-01-04-EN.iso -L ../qemu/pc-bios
[Thread debugging using libthread_db enabled]
[New Thread 0xf7f27550 (LWP 15523)]
[Switching to Thread 0xf7f27550 (LWP 15523)]
Breakpoint 1, main (argc=1430528, argv=0x15d400) at
/home/shaddy/qemu-cvs/qemu/vl.c:7362
7362env = next_cpu;
1: x/i $pc
0x1e958 main+13992: ld [ %l6 + 0x8c ], %l1
(gdb) print /x env
$1 = 0x322e3100
(gdb) print /x next_cpu
$2 = 0x1cd13e8
(gdb) stepi
7366ret = cpu_exec(env);
1: x/i $pc
0x1e95c main+13996: call 0xa90b4 cpu_x86_exec
0x1e960 main+14000: mov %l1, %o0
(gdb)
0x0001e960 7366ret = cpu_exec(env);
1: x/i $pc
0x1e960 main+14000: mov %l1, %o0
(gdb) print /x next_cpu
$3 = 0x1cd13e8
(gdb) print /x env
$4 = 0x322e3100
(gdb) print /x env
Address requested for identifier env which is in register $g6
(gdb) print $g6
$5 = 841888000
(gdb) print /x $g6
$6 = 0x322e3100
(gdb) stepi
cpu_x86_exec (env1=0x117000) at /home/shaddy/qemu-cvs/qemu/cpu-exec.c:244
244 {
1: x/i $pc
0xa90b4 cpu_x86_exec: add %sp, -232, %sp
(gdb) print /x $g6
$7 = 0x322e3100
(gdb) stepi
0x000a90b8 in cpu_x86_exec (env1=0x117000) at
/home/shaddy/qemu-cvs/qemu/cpu-exec.c:244
244 {
1: x/i $pc
0xa90b8 cpu_x86_exec+4: st %i7, [ %sp + 0x60 ]
(gdb) print /x $g6
$8 = 0x322e3100
(gdb) stepi
0x000a90bc 244 {
1: x/i $pc
0xa90bc cpu_x86_exec+8: sub %sp, -232, %i7
(gdb) print /x $g6
$9 = 0x322e3100
(gdb)
I still read that as failing to assign the value. Given my limited
knowledge, how is gdb so adamantly stating that env1=0x117000 when the
value of env1 (i.e. env in the calling function) is only known after the
delay slot instruction is completed? That's more a rhetorical
question... I've got to do a bit of research to be able to know these
things myself.
0x240a4 main_loop+152:sethi %hi(0x258800), %g4
0x240a8 main_loop+156:or %g4, 0x4c, %g4 ! 0x25884c
0x240ac main_loop+160:ld [ %g4 ], %g4
0x240b0 main_loop+164:st %g4, [ %fp + -20 ]
0x240b4 main_loop+168:ld [ %fp + -20 ], %o0
0x240b8 main_loop+172:call 0x14fa64 cpu_x86_exec
0x240bc main_loop+176:nop
This looks like equivalent code, only dumber version using an
intermediate store and not using the delay slot.
Sure. However, what do you read of gdb determining that the value for
env in the parameters to the cpu_exec call being different to its value
in the calling function?
Regards,
Shaddy
Re: [Qemu-devel] and now bus error for i386 guest
HI,
Blue Swirl wrote:
On 11/14/07, Shaddy Baddah [EMAIL PROTECTED] wrote:
Hi again,
After further culling the target list, I was able to install qemu on my
sun4u host.
However, running it, I get a bus error. See below for details:
$ /opt/qemu-cvs/bin/qemu -m 128 -cdrom
~/KNOPPIX_V5.1.1CD-2007-01-04-EN.iso -vnc :1
Bus error
For some reason, Sparc Linux host is not working. I think Sparc Solaris is OK.
Yes, I do recall that I was able to get this working on Sparc Solaris.
Anyway, when I get more time, I will have a better stab at debugging
this. I got a start on this today, and here is a bit of cut and paste
that may or may not be insightful. The address for env1 looks questionable:
[EMAIL PROTECTED]:~/qemu-cvs/qemu-build$ gdb --args ./i386-softmmu/qemu
-hda ../../KNOPPIX_V5.1.1CD-2007-01-04-EN.iso -L ../qemu/pc-bios
GNU gdb 6.6.90.20070912-debian
Copyright (C) 2007 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
http://gnu.org/licenses/gpl.html
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type show copying
and show warranty for details.
This GDB was configured as sparc-linux-gnu...
Using host libthread_db library /lib/libthread_db.so.1.
(gdb) run
Starting program: /home/shaddy/qemu-cvs/qemu-build/i386-softmmu/qemu
-hda ../../KNOPPIX_V5.1.1CD-2007-01-04-EN.iso -L ../qemu/pc-bios
[Thread debugging using libthread_db enabled]
[New Thread 0xf7f7b550 (LWP 9363)]
Program received signal SIGBUS, Bus error.
[Switching to Thread 0xf7f7b550 (LWP 9363)]
cpu_x86_exec (env1=0x2) at /home/shaddy/qemu-cvs/qemu/cpu-exec.c:307
307 if (env-exception_index = 0) {
(gdb) info threads
* 1 Thread 0xf7f7b550 (LWP 9363) cpu_x86_exec (env1=0x2)
at /home/shaddy/qemu-cvs/qemu/cpu-exec.c:307
(gdb)
HTH,
Shaddy
PS: couldn't this also be debugged from within qemu VM running Debian
Sparc, for those that don't have access to a real machine? I got a start
on this today as well (because I don't always have access to the Sun
Ultra box). Seems stable, and I was able to get a start on a compile,
that is currently still going.
Re: [Qemu-devel] and now bus error for i386 guest
HI,
Blue Swirl wrote:
On 11/14/07, Shaddy Baddah [EMAIL PROTECTED] wrote:
Hi again,
After further culling the target list, I was able to install qemu on my
sun4u host.
However, running it, I get a bus error. See below for details:
$ /opt/qemu-cvs/bin/qemu -m 128 -cdrom
~/KNOPPIX_V5.1.1CD-2007-01-04-EN.iso -vnc :1
Bus error
For some reason, Sparc Linux host is not working. I think Sparc Solaris is OK.
Yes, I do recall that I was able to get this working on Sparc Solaris.
Anyway, when I get more time, I will have a better stab at debugging
this. I got a start on this today, and here is a bit of cut and paste
that may or may not be insightful. The address for env1 looks questionable:
[EMAIL PROTECTED]:~/qemu-cvs/qemu-build$ gdb --args ./i386-softmmu/qemu
-hda ../../KNOPPIX_V5.1.1CD-2007-01-04-EN.iso -L ../qemu/pc-bios
GNU gdb 6.6.90.20070912-debian
Copyright (C) 2007 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
http://gnu.org/licenses/gpl.html
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type show copying
and show warranty for details.
This GDB was configured as sparc-linux-gnu...
Using host libthread_db library /lib/libthread_db.so.1.
(gdb) run
Starting program: /home/shaddy/qemu-cvs/qemu-build/i386-softmmu/qemu
-hda ../../KNOPPIX_V5.1.1CD-2007-01-04-EN.iso -L ../qemu/pc-bios
[Thread debugging using libthread_db enabled]
[New Thread 0xf7f7b550 (LWP 9363)]
Program received signal SIGBUS, Bus error.
[Switching to Thread 0xf7f7b550 (LWP 9363)]
cpu_x86_exec (env1=0x2) at /home/shaddy/qemu-cvs/qemu/cpu-exec.c:307
307 if (env-exception_index = 0) {
(gdb) info threads
* 1 Thread 0xf7f7b550 (LWP 9363) cpu_x86_exec (env1=0x2)
at /home/shaddy/qemu-cvs/qemu/cpu-exec.c:307
(gdb)
HTH,
Shaddy
PS: couldn't this also be debugged from within qemu VM running Debian
Sparc, for those that don't have access to a real machine? I got a start
on this today as well (because I don't always have access to the Sun
Ultra box). Seems stable, and I was able to get a start on a compile,
that is currently still going.
Re: [Qemu-devel] Qemu forum
Ottavio Caruso wrote: has anybody got any news on when the Qemu Forum will be up again? I'd like to second the call for its return. At least can the archive be retained somewhere... I had reason to read back my own postings in the forum, and am lamenting my lost memory. TIA, Shaddy
Re: [Qemu-devel] now ppc build failure: dyngen: empty code for op_splatw_T1_64
Hi again, Disabling the failed alpha build (from my previous email) via --target-list, I now find that the ppc build fails on sun4u (sun4m userland). A snip of the error is inlined below: ... /home/shaddy/qemu-cvs/qemu/target-ppc/op.c:2924: warning: right shift count = width of type ../dyngen -o op.h op.o dyngen: empty code for op_splatw_T1_64 make[1]: *** [op.h] Error 1 make[1]: Leaving directory `/home/shaddy/qemu-cvs/qemu/ppc-linux-user' make: *** [subdir-ppc-linux-user] Error 2 TIA, Shaddy
Re: [Qemu-devel] and now bus error for i386 guest
Hi again, After further culling the target list, I was able to install qemu on my sun4u host. However, running it, I get a bus error. See below for details: $ /opt/qemu-cvs/bin/qemu -m 128 -cdrom ~/KNOPPIX_V5.1.1CD-2007-01-04-EN.iso -vnc :1 Bus error I would really like to be able to get qemu running on this sun4u, so help would be appreciated. Thanks in advance, Shaddy PS: I am running Debian Lenny/Testing for SPARC. At the moment, I am not running swap. However, I have 1Gb of memory, so at this stage, I want to run small memory configs that should fit in the 1Gb.
Re: [Qemu-devel] [PATCH] Physical hard disk drive for win32
Hi, Stefan Weil wrote: longer than MS does? It would make things easier if we dropped support for W2K hosts. Surely not?!? I've heard of people being off hand about supporting Win95/98 (and I would agree with that) et al..., but surely W2K support should be sacrosanct ?!? Regards, Shaddy
Re: [Qemu-devel] QEMU only support USB endpoint 02(output)and 81(input)?
Hi, On 3/29/2007 2:52 PM, Yu, Xiaoyang wrote: I used QEMU 0.9.0 to do the testing. All the seven USB disks can work properly in host OS (Linux 2.6), so the USB devices and its interaction with the kernel drivers should be okay. So the problem must be in QEMU USB code. As far as I know, QEMU does not have any of its own special USB handling. It has USB emulation. But this does not influence how it handles disk images... even if they are on a USB device. Perhaps you can demonstrate some QEMU command-lines to indicate how you are testing these disks? Regards, Shaddy
[Qemu-devel] [PATCH] qemu/target-ppc/cpu.h: fix recent changes break Solaris 8 builds
Hi, Recent changes to qemu/target-ppc/cpu.h have broken Solaris 8 builds. Specifically, the insertion of a stdint.h insertion, which is not part of the Solaris C development library. [SNIP] make[1]: Entering directory `/var/home/shaddy/src/qemu/qemu/ppc-softmmu' gcc -Wall -O2 -g -fno-strict-aliasing -I. -I.. -I/var/home/shaddy/src/qemu/qemu/target-ppc -I/var/home/shaddy/src/qemu/qemu -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -I/var/home/shaddy/src/qemu/qemu/fpu -DHAS_AUDIO -I/var/home/shaddy/src/qemu/qemu/slirp -mcpu=ultrasparc -m32 -ffixed-g2 -ffixed-g3 -c -o vl.o /var/home/shaddy/src/qemu/qemu/vl.c In file included from /var/home/shaddy/src/qemu/qemu/vl.h:85, from /var/home/shaddy/src/qemu/qemu/vl.c:24: /var/home/shaddy/src/qemu/qemu/target-ppc/cpu.h:24:20: stdint.h: No such file or directory /var/home/shaddy/src/qemu/qemu/vl.c: In function `init_timer_alarm': /var/home/shaddy/src/qemu/qemu/vl.c:1116: warning: label `use_itimer' defined but not used /var/home/shaddy/src/qemu/qemu/vl.c: In function `parse_host_port': /var/home/shaddy/src/qemu/qemu/vl.c:3078: warning: subscript has type `char' /var/home/shaddy/src/qemu/qemu/vl.c: In function `net_slirp_smb': /var/home/shaddy/src/qemu/qemu/vl.c:3322: warning: int format, pid_t arg (arg 4) /var/home/shaddy/src/qemu/qemu/vl.c: At top level: /var/home/shaddy/src/qemu/qemu/vl.c:1030: warning: 'start_rtc_timer' defined but not used make[1]: *** [vl.o] Error 1 make[1]: Leaving directory `/var/home/shaddy/src/qemu/qemu/ppc-softmmu' make: *** [subdir-ppc-softmmu] Error 2 [/SNIP] Simple solution is to replace inclusion, unconditionally, with inttypes.h. This is consistent with the rest of the code-base. Patch inline'ed below. HTH, Shaddy Index: target-ppc/cpu.h === RCS file: /sources/qemu/qemu/target-ppc/cpu.h,v retrieving revision 1.31 diff -u -r1.31 cpu.h --- target-ppc/cpu.h23 Mar 2007 09:45:27 - 1.31 +++ target-ppc/cpu.h28 Mar 2007 16:30:12 - @@ -21,7 +21,7 @@ #define __CPU_PPC_H__ #include config.h -#include stdint.h +#include inttypes.h #if defined(TARGET_PPC64) || (HOST_LONG_BITS = 64) /* When using 64 bits temporary registers,
[Qemu-devel] SPARC Solaris 8: i386 guest - frequent hangs (cross-post)
Hi, This is a cross-post from http://qemu-forum.ipi.fi/viewtopic.php?p=10639#10639. Continuing on from http://qemu-forum.ipi.fi/viewtopic.php?p=10487#10487, I am being continually frustrated in bringing up my Debian i386 installation on my external USB drive. I have tried both the 0.8.2 version from the opensolaris.org project, my build of 0.9.0 and my build of latest CVS (as at this email) plus my earlier emailed patch. I am now running them with this command line (the no networking bit is to try to simplify the setup, and avoid the hangs... doesn't work though): *Code:* qemu -m 128 -hda /dev/rdsk/c3t0d0s0 -net none -nographic Basically, at random points, qemu hangs completely. The confirmation of this is, also at random points, I'm sending a ctrl-a h to output the command help onto the console. *Code:* C-a hprint this help C-a xexit emulator C-a ssave disk data back to file (if -snapshot) C-a bsend break (magic sysrq) C-a ttoggle console timestamps C-a cswitch between console and monitor C-a C-a send C-a When the hang occurs, I get no response from inputting this key sequence. In fact, there is obviously never a *read* call being made, because after I manually kill the process from another terminal session, the buffered inputs are being unbuffered to the shell prompt. The most interesting hang I had was, after booting single user, and then issuing a shutdown -h now, the hang occurred after the Linux kernel outputting: *Code:* Power down. I checked the message log, and there are no apparent USB IO errors. By the way, this is all aside from the seemingly much reported general slowness of the virtual machine. It's not nice, but I don't mind it if the VM is at least stable. As it stands now, I can't risk using it, as fsck has to sort out the mess after every hang. Any help on the matter (like how I can diagnose the problem) will be greatly appreciated. TIA, Shaddy
Re: [Qemu-devel] QEMU only support USB endpoint 02(output) and 81(input)?
Hi, On 3/29/2007 11:49 AM, Yu, Xiaoyang wrote: I found that some USB disks do not work in QEMU. I don't quite understand. In which way? As I understand it, QEMU just uses the I/O layer provided by the host operating system. In my experience, if there has been any USB problem, it is either with the USB device and its interaction with the kernel drivers. Regards, Shaddy
