* [Qemu-devel] Knoppix results
@ 2004-01-29 6:11 Kyle Hayes
2004-01-29 14:12 ` Renzo Davoli
0 siblings, 1 reply; 12+ messages in thread
From: Kyle Hayes @ 2004-01-29 6:11 UTC (permalink / raw)
To: qemu-devel
Here's my host system:
QEMU: 0.5.2 (binary from web site)
Linux: Gentoo 1.4 up to date (stable)
CPU: Pentium 4 2.6 GHz (recent stepping)
Mem: 512MB DDR PC3200
I've tried to install Knoppix within QEMU. I have had some luck, but not
succeeded with everything. I can boot it and it seems to run Linux without
any problems as long as I do not try to use X Windows. Where I have
difficulties is when I try to install Knoppix onto the "hard disk".
Here's the command line I'm using:
qemu -hda hda.img -cdrom knoppix.iso -boot d -m 128
The disk image hda.img is initially blank. I created it with:
dd if=/dev/zero of=hda.img bs=1M count=4096
This produces a 4GB file full of zeros.
I them use the command line above to boot the Knoppix CD image. I boot
Knoppix with the following command line:
boot: knoppix lang=us 2
The "2" tells Knoppix to boot into command line mode, not graphical mode. No
GUI will be used. I tried that, but Knoppix can't figure out X. It sees a
generic VESA-type card, but cannot actually use it for some reason.
Knoppix boots and I get a command prompt. Everything looks OK at this point.
I can look at directories and start and stop things. I cannot run any
graphical tools but that wasn't my aim at this point.
I can launch cfdisk from within Knoppix. However, it is somewhat hit or miss
whether or not I can partition the disk image that I created. I can usually
do one partition write and that is it. On the second one, I seem to have a
strong change of having QEMU hang while using 100% of the CPU. So, some
problem with disk IO?
After a couple of tries, I got the disk image ready and partitioned. Whenever
cfdisk hung QEMU, I had to kill the emulator and restart the process. I found
that the changes that were successfully written to the disk image were good,
so I was able to make forward progress.
I then launched knx-hdinstall. This script installs Knoppix onto the hard
drive. I get though initial setup (I can skip through the partitioning
because I did that separately) including formatting the hard disk image and
preparing the swap space. When it gets to the stage where it is copying
files from the Knoppix CD image to the hard disk image, it hangs using 100%
of the CPU before it completes copying the files.
I attempted knx-install twice. The first time it got to 30% complete and
hung. The second time it got to 9%. I tried a third time while I was
writing this email and the screen saver kicked in. The screen (well, the
window) went black and nothing I typed would restart it. I was able to
release the mouse (it had been grabbed into the window) and was able to kill
off QEMU. I guess I need to figure out how to stop the screen saver :-)
The first two times, I don't think the screen saver started before it hung.
The first time, I was able to release the mouse from QEMU. The second time I
didn't have the mouse grabbed by QEMU.
How can I help debug this? It seems very, very close. The only common theme
I can see between by two cases of hanging is disk IO. In the case of cfdisk,
it is low level disk IO and may be calling some weird things to write to the
partition table (you wouldn't think so, but there's something odd about it).
The second case, knx-hdinstall, seems to simply cause a lot of disk IO.
Perhaps "interrupts" are being lost or something?
Best,
Kyle
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [Qemu-devel] Knoppix results
2004-01-29 6:11 [Qemu-devel] Knoppix results Kyle Hayes
@ 2004-01-29 14:12 ` Renzo Davoli
2004-01-29 14:32 ` Johan Rydberg
2004-01-29 23:22 ` Fabrice Bellard
0 siblings, 2 replies; 12+ messages in thread
From: Renzo Davoli @ 2004-01-29 14:12 UTC (permalink / raw)
To: Kyle Hayes; +Cc: qemu-devel
> After a couple of tries, I got the disk image ready and partitioned. Whenever
> cfdisk hung QEMU, I had to kill the emulator and restart the process. I found
> that the changes that were successfully written to the disk image were good,
> so I was able to make forward progress.
I have installed a complete debian.
I have had the very same problem: sometimes qemu freezes.
There is no apparent cause-effect relationship, qemu freezed at random
stages of the installation process any time the procedure was restarted.
I succeeded in installing the debian but after several attempts.
It seems to be a timing fault on the simulated ide.
When it freezes, it stops into a low level infinite loop: neither
clicking on the window to grab the mouse nor ctrl-c on the calling
terminal produce effects.
This is the only visible bug of qemu.
In debian both the network interface and the floppy work perfectly.
On the other hand when I boot Win98 into qemu I can't push ne2000 and
floppy drive to work.
The "floppy" problem is funny: it is recognized and used at boot time
(e.g. to boot with the rescue disk) but it fails to access the floppy
after a complete win boot.
renzo
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [Qemu-devel] Knoppix results
2004-01-29 14:12 ` Renzo Davoli
@ 2004-01-29 14:32 ` Johan Rydberg
2004-01-29 14:51 ` Renzo Davoli
` (2 more replies)
2004-01-29 23:22 ` Fabrice Bellard
1 sibling, 3 replies; 12+ messages in thread
From: Johan Rydberg @ 2004-01-29 14:32 UTC (permalink / raw)
To: qemu-devel
renzo@cs.unibo.it (Renzo Davoli) wrote:
: I have had the very same problem: sometimes qemu freezes.
: There is no apparent cause-effect relationship, qemu freezed at random
: stages of the installation process any time the procedure was restarted.
: I succeeded in installing the debian but after several attempts.
How hard would it be to attach the processor to GDB? I suspect you would
make things a lot easier for Fabrice if you showed him at least a backtrace.
Or how about tracking down the bug yourself and send a patch?
--
Johan Rydberg, Free Software Developer, Sweden
http://rtmk.sf.net | http://www.nongnu.org/guss/
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [Qemu-devel] Knoppix results
2004-01-29 14:32 ` Johan Rydberg
@ 2004-01-29 14:51 ` Renzo Davoli
2004-01-29 16:43 ` Kyle Hayes
2004-01-31 9:28 ` Renzo Davoli
2 siblings, 0 replies; 12+ messages in thread
From: Renzo Davoli @ 2004-01-29 14:51 UTC (permalink / raw)
To: Johan Rydberg; +Cc: qemu-devel
On Thu, Jan 29, 2004 at 03:32:17PM +0100, Johan Rydberg wrote:
> How hard would it be to attach the processor to GDB? I suspect you would
> make things a lot easier for Fabrice if you showed him at least a backtrace.
> Or how about tracking down the bug yourself and send a patch?
Everything's alright?
The use of gdb and the writing of patches is as simple for me as for
you.
I have posted fixes here and elsewhere when I have had the opportunity
to.
Sorry to have touched your bugfix sensibility.
renzo
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [Qemu-devel] Knoppix results
2004-01-29 14:32 ` Johan Rydberg
2004-01-29 14:51 ` Renzo Davoli
@ 2004-01-29 16:43 ` Kyle Hayes
2004-01-29 17:04 ` Gabriel Ebner
2004-01-29 17:38 ` Johan Rydberg
2004-01-31 9:28 ` Renzo Davoli
2 siblings, 2 replies; 12+ messages in thread
From: Kyle Hayes @ 2004-01-29 16:43 UTC (permalink / raw)
To: Johan Rydberg, qemu-devel
On Thursday 29 January 2004 06:32, Johan Rydberg wrote:
> renzo@cs.unibo.it (Renzo Davoli) wrote:
> : I have had the very same problem: sometimes qemu freezes.
> : There is no apparent cause-effect relationship, qemu freezed at random
> : stages of the installation process any time the procedure was restarted.
> : I succeeded in installing the debian but after several attempts.
>
> How hard would it be to attach the processor to GDB? I suspect you would
> make things a lot easier for Fabrice if you showed him at least a
> backtrace. Or how about tracking down the bug yourself and send a patch?
How easy is it to use GDB? It has been years since I looked at it. I think I
can managed to make it do a backtrace.
Would I run QEMU from the command line via GDB?
$ gdb qemu -hda hda.img -cdrom knoppix.iso -boot d -m 128
??
Oh, right, I can't pass it args... Ugh. I find GDB to be one of the more
difficult tools to use unless you use it every hour of every day. I do
almost exclusively Perl coding and have for years now.
Hmm, it looks like I need to build from source. Here's my GDB attempt:
kyle@salish $ gdb qemu
GNU gdb 5.3
Copyright 2002 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 "i686-pc-linux-gnu"...(no debugging symbols
found)...
(gdb)
No debugging symbols found so I guess it is a stripped executable. Let me
check... yep. Rats.
I decided to see if I could run it at all:
(gdb) set args -hda hda.img -cdrom knoppix.iso -boot d -m 128
(gdb) run
Starting program: /usr/local/bin/qemu -hda hda.img -cdrom knoppix.iso -boot d
-m 128
warning: shared library handler failed to enable breakpoint
Connected to host network interface: tun0
Password:
Could not initialize SDL - exiting
Program exited with code 01.
(gdb)
The password check was from sudo for the ifconfig tap0 in the qemu-ifup
script. However, it is barfing trying to load SDL. That's odd. Any clues
why that would happen? What does the shared library handler warning mean?
I'll try to build from source and see if I can get farther than this.
Best,
Kyle
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [Qemu-devel] Knoppix results
2004-01-29 16:43 ` Kyle Hayes
@ 2004-01-29 17:04 ` Gabriel Ebner
2004-01-29 17:38 ` Johan Rydberg
1 sibling, 0 replies; 12+ messages in thread
From: Gabriel Ebner @ 2004-01-29 17:04 UTC (permalink / raw)
To: kyle, qemu-devel
Hello,
Am Don, den 29.01.2004 schrieb Kyle Hayes um 17:43:
> Would I run QEMU from the command line via GDB?
>
> $ gdb qemu -hda hda.img -cdrom knoppix.iso -boot d -m 128
>
> ??
Well, I don't think so. It think you have to run qemu -s but then I
don't know how to make gdb connect to that port... gdb's info page
shows nothing like that at first sight.
$ qemu -help | grep gdb
-s wait gdb connection to port 1234
-p port change gdb connection port
Gabriel.
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [Qemu-devel] Knoppix results
2004-01-29 16:43 ` Kyle Hayes
2004-01-29 17:04 ` Gabriel Ebner
@ 2004-01-29 17:38 ` Johan Rydberg
2004-01-30 5:33 ` Kyle Hayes
2004-01-30 22:15 ` Herbert Poetzl
1 sibling, 2 replies; 12+ messages in thread
From: Johan Rydberg @ 2004-01-29 17:38 UTC (permalink / raw)
To: kyle; +Cc: qemu-devel
Kyle Hayes <kyle@silverbeach.net> wrote:
: Would I run QEMU from the command line via GDB?
:
: $ gdb qemu -hda hda.img -cdrom knoppix.iso -boot d -m 128
:
: Oh, right, I can't pass it args... Ugh.
If you have a recent version of GDB (I'm not sure GDB 5.3, which is ancient,
support this) you can use the --args argument.
$ gdb --args qemu -hda ....
: I find GDB to be one of the more difficult tools to use unless you use
: it every hour of every day. I do almost exclusively Perl coding and have
: for years now.
Sure, it's a rather complex tool. But as soon as you get familiar with it,
you can not live without it.
: That's odd. Any clues
: why that would happen? What does the shared library handler warning mean?
No idea. I suggest you update GDB (to version 6 at least) and give that
a try.
: I'll try to build from source and see if I can get farther than this.
:
: Best,
: Kyle
--
Johan Rydberg, Free Software Developer, Sweden
http://rtmk.sf.net | http://www.nongnu.org/guss/
Playing A-Skills and Krafty Kuts - Tricka Technology
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [Qemu-devel] Knoppix results
2004-01-29 14:12 ` Renzo Davoli
2004-01-29 14:32 ` Johan Rydberg
@ 2004-01-29 23:22 ` Fabrice Bellard
2004-01-30 5:29 ` Kyle Hayes
1 sibling, 1 reply; 12+ messages in thread
From: Fabrice Bellard @ 2004-01-29 23:22 UTC (permalink / raw)
To: qemu-devel
Renzo Davoli wrote:
>>After a couple of tries, I got the disk image ready and partitioned. Whenever
>>cfdisk hung QEMU, I had to kill the emulator and restart the process. I found
>>that the changes that were successfully written to the disk image were good,
>>so I was able to make forward progress.
>
>
> I have installed a complete debian.
>
> I have had the very same problem: sometimes qemu freezes.
> There is no apparent cause-effect relationship, qemu freezed at random
> stages of the installation process any time the procedure was restarted.
> I succeeded in installing the debian but after several attempts.
>
> It seems to be a timing fault on the simulated ide.
> When it freezes, it stops into a low level infinite loop: neither
> clicking on the window to grab the mouse nor ctrl-c on the calling
> terminal produce effects.
It seems there is a problem in TB invalidation during asynchronous
interrupts (I have already seen random infinite loops in
tb_reset_jump_recursive()). I have no idea of the exact cause of the
problem.
Fabrice.
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [Qemu-devel] Knoppix results
2004-01-29 23:22 ` Fabrice Bellard
@ 2004-01-30 5:29 ` Kyle Hayes
0 siblings, 0 replies; 12+ messages in thread
From: Kyle Hayes @ 2004-01-30 5:29 UTC (permalink / raw)
To: qemu-devel
On Thursday 29 January 2004 15:22, Fabrice Bellard wrote:
> It seems there is a problem in TB invalidation during asynchronous
> interrupts (I have already seen random infinite loops in
> tb_reset_jump_recursive()). I have no idea of the exact cause of the
> problem.
Hmm, is there any way we can help with this?
Something is definitely looping. The CPU pegs at 100%. It does seem related
to disk interrupts in my case. I haven't managed to make it do it anywhere
else.
Over the weekend I'll compile QEMU without stripping symbols and see if I can
get gdb to help me figure out how I got into the loop. I seem to be able to
recreate it without any problems using Knoppix and running the knx-hdinstall
script. It can take a while though (15 minutes sometimes).
QEMU is amazingly good already!
Best,
Kyle
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [Qemu-devel] Knoppix results
2004-01-29 17:38 ` Johan Rydberg
@ 2004-01-30 5:33 ` Kyle Hayes
2004-01-30 22:15 ` Herbert Poetzl
1 sibling, 0 replies; 12+ messages in thread
From: Kyle Hayes @ 2004-01-30 5:33 UTC (permalink / raw)
To: qemu-devel
On Thursday 29 January 2004 09:38, Johan Rydberg wrote:
> Kyle Hayes <kyle@silverbeach.net> wrote:
> : Would I run QEMU from the command line via GDB?
> :
> : $ gdb qemu -hda hda.img -cdrom knoppix.iso -boot d -m 128
> :
> : Oh, right, I can't pass it args... Ugh.
>
> If you have a recent version of GDB (I'm not sure GDB 5.3, which is
> ancient, support this) you can use the --args argument.
Odd, Gentoo uses 5.3. If I go to the unstable pool of packages, I can get
6.0. Normally Gentoo is quite up to date. Is there a stability problem with
newer GDB versions?
> $ gdb --args qemu -hda ....
Cool.
> : I find GDB to be one of the more difficult tools to use unless you use
> : it every hour of every day. I do almost exclusively Perl coding and have
> : for years now.
>
> Sure, it's a rather complex tool. But as soon as you get familiar with it,
> you can not live without it.
It doesn't help at all for Perl programming compared to the Perl debugger :-)
Since I don't do much C code anymore, the utility of GDB is fairly low for
me.
> : That's odd. Any clues
> : why that would happen? What does the shared library handler warning
> : mean?
>
> No idea. I suggest you update GDB (to version 6 at least) and give that
> a try.
Yeah, I'll try that. Now off to find the syntax for updating a package from
the unstable section...
Best,
Kyle
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [Qemu-devel] Knoppix results
2004-01-29 17:38 ` Johan Rydberg
2004-01-30 5:33 ` Kyle Hayes
@ 2004-01-30 22:15 ` Herbert Poetzl
1 sibling, 0 replies; 12+ messages in thread
From: Herbert Poetzl @ 2004-01-30 22:15 UTC (permalink / raw)
To: Johan Rydberg; +Cc: qemu-devel
On Thu, Jan 29, 2004 at 06:38:21PM +0100, Johan Rydberg wrote:
> Kyle Hayes <kyle@silverbeach.net> wrote:
>
> : Would I run QEMU from the command line via GDB?
> :
> : $ gdb qemu -hda hda.img -cdrom knoppix.iso -boot d -m 128
> :
> : Oh, right, I can't pass it args... Ugh.
>
> If you have a recent version of GDB (I'm not sure GDB 5.3, which is ancient,
> support this) you can use the --args argument.
>
> $ gdb --args qemu -hda ....
not necessary, just fire up gdb qemu
and pass the args on the run command
# gdb echo
GNU gdb 5.1.1
Copyright 2002 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-mandrake-linux"...(no debugging symbols found)...
(gdb) run hello world
Starting program: /bin/echo hello world
hello world
(no debugging symbols found)...
Program exited normally.
(gdb)
or attach to the running instance like that:
# sleep 100 &
[1] 17868
# gdb
GNU gdb 5.1.1
Copyright 2002 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-mandrake-linux".
(gdb) attach 17868
Attaching to process 17868
0x4011c7b1 in ?? ()
(gdb)
HTH,
Herbert
> : I find GDB to be one of the more difficult tools to use unless you use
> : it every hour of every day. I do almost exclusively Perl coding and have
> : for years now.
>
> Sure, it's a rather complex tool. But as soon as you get familiar with it,
> you can not live without it.
>
> : That's odd. Any clues
> : why that would happen? What does the shared library handler warning mean?
>
> No idea. I suggest you update GDB (to version 6 at least) and give that
> a try.
>
> : I'll try to build from source and see if I can get farther than this.
> :
> : Best,
> : Kyle
>
>
> --
> Johan Rydberg, Free Software Developer, Sweden
> http://rtmk.sf.net | http://www.nongnu.org/guss/
>
> Playing A-Skills and Krafty Kuts - Tricka Technology
>
>
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://mail.nongnu.org/mailman/listinfo/qemu-devel
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [Qemu-devel] Knoppix results
2004-01-29 14:32 ` Johan Rydberg
2004-01-29 14:51 ` Renzo Davoli
2004-01-29 16:43 ` Kyle Hayes
@ 2004-01-31 9:28 ` Renzo Davoli
2 siblings, 0 replies; 12+ messages in thread
From: Renzo Davoli @ 2004-01-31 9:28 UTC (permalink / raw)
To: Johan Rydberg; +Cc: qemu-devel
On Thu, Jan 29, 2004 at 03:32:17PM +0100, Johan Rydberg wrote:
> How hard would it be to attach the processor to GDB? I suspect you would
> make things a lot easier for Fabrice if you showed him at least a backtrace.
> Or how about tracking down the bug yourself and send a patch?
Okay. Be positive.
I have stresses qemu under gdb control until I have reached a freeze.
Either gdb affects in some way the timing or it is a matter of being
lucky, anyway it seems to me that freezing is less frequent when using
gdb.
After several attempt I got the freeze and here there is the traceback:
0x100156d4 in tb_reset_jump_recursive2 (tb=0x102899b0, n=0)
at /home/renzo/tests/qemu/cvs/qemu/exec.c:867
867 if (n1 == n && tb1 == tb)
(gdb) backtrace
#0 0x100156d4 in tb_reset_jump_recursive2 (tb=0x102899b0, n=0)
at /home/renzo/tests/qemu/cvs/qemu/exec.c:867
#1 0x100130d0 in tb_reset_jump_recursive (tb=0x102899b0)
at /home/renzo/tests/qemu/cvs/qemu/exec.c:884
#2 0x1000372c in pic_update_irq () at
/home/renzo/tests/qemu/cvs/qemu/vl.c:804
#3 0x10008ffc in ide_sector_write (s=0x10b8f254)
at /home/renzo/tests/qemu/cvs/qemu/ide.c:492
#4 0x1000a090 in ide_data_writew (env=0x102899b0, addr=0, val=0)
at /home/renzo/tests/qemu/cvs/qemu/ide.c:1306
#5 0x10002f00 in cpu_outw (env=0x102899b0, addr=271096248, val=0)
at /home/renzo/tests/qemu/cvs/qemu/vl.c:418
#6 0x106a44ec in code_gen_buffer ()
#7 0x10015be8 in cpu_x86_exec (env1=0x102899b0)
at /home/renzo/tests/qemu/cvs/qemu/cpu-exec.c:390
#8 0x100069d8 in main_loop (opaque=0x102899b0)
at /home/renzo/tests/qemu/cvs/qemu/vl.c:3132
#9 0x100077c4 in main (argc=2147480992, argv=0x7ffff580)
at /home/renzo/tests/qemu/cvs/qemu/vl.c:3748
As I said it seems stuck into the low level loop:
for(;;) {
tb1 = *ptb;
n1 = (long)tb1 & 3;
tb1 = (TranslationBlock *)((long)tb1 & ~3);
if (n1 == n && tb1 == tb)
break;
ptb = &tb1->jmp_next[n1];
}
step by step execution from breakpoint is:
host_alarm_handler (host_signum=14, info=0x7fffe690, puc=0x7fffe710)
at /home/renzo/tests/qemu/cvs/qemu/vl.c:3061
3061 timer_irq_count += pit_get_out_edges(&pit_channels[0]);
3057 {
3061 timer_irq_count += pit_get_out_edges(&pit_channels[0]);
3057 {
3061 timer_irq_count += pit_get_out_edges(&pit_channels[0]);
3057 {
3061 timer_irq_count += pit_get_out_edges(&pit_channels[0]);
3057 {
3061 timer_irq_count += pit_get_out_edges(&pit_channels[0]);
pit_get_out_edges (s=0x101fb0b0) at
/home/renzo/tests/qemu/cvs/qemu/vl.c:1238
1238 ticks = cpu_get_ticks();
cpu_get_ticks () at /home/renzo/tests/qemu/cvs/qemu/vl.c:1113
1113 return cpu_get_real_ticks() + cpu_ticks_offset;
cpu_get_real_ticks () at /home/renzo/tests/qemu/cvs/qemu/vl.c:1079
1079 asm volatile("mftbu %0" : "=r" (tbl));
1072 asm volatile("mftb %0" : "=r" (tbl));
1079 asm volatile("mftbu %0" : "=r" (tbl));
1091 } while (h != h1);
1092 return ((int64_t)h << 32) | l;
1093 }
cpu_get_ticks () at /home/renzo/tests/qemu/cvs/qemu/vl.c:1114
1114 }
1113 return cpu_get_real_ticks() + cpu_ticks_offset;
1114 }
cpu_get_ticks () at /home/renzo/tests/qemu/cvs/qemu/vl.c:1113
1113 return cpu_get_real_ticks() + cpu_ticks_offset;
1114 }
1113 return cpu_get_real_ticks() + cpu_ticks_offset;
1114 }
pit_get_out_edges (s=0x101fb0b0) at
/home/renzo/tests/qemu/cvs/qemu/vl.c:1239
1239 d1 = muldiv64(s->count_last_edge_check_time -
s->count_load_time,
1238 ticks = cpu_get_ticks();
1239 d1 = muldiv64(s->count_last_edge_check_time -
s->count_load_time,
muldiv64 (a=40281440059, b=1193182, c=0)
at /home/renzo/tests/qemu/cvs/qemu/vl.c:1165
1165 rh = (uint64_t)u.l.high * (uint64_t)b;
1166 rh += (rl >> 32);
1150 {
1168 res.l.low = (((rh % c) << 32) + (rl & 0xffffffff)) / c;
1167 res.l.high = rh / c;
1150 {
1167 res.l.high = rh / c;
1150 {
1165 rh = (uint64_t)u.l.high * (uint64_t)b;
1150 {
1166 rh += (rl >> 32);
1164 rl = (uint64_t)u.l.low * (uint64_t)b;
1167 res.l.high = rh / c;
1168 res.l.low = (((rh % c) << 32) + (rl & 0xffffffff)) / c;
1167 res.l.high = rh / c;
1168 res.l.low = (((rh % c) << 32) + (rl & 0xffffffff)) / c;
1167 res.l.high = rh / c;
1168 res.l.low = (((rh % c) << 32) + (rl & 0xffffffff)) / c;
1170 }
1168 res.l.low = (((rh % c) << 32) + (rl & 0xffffffff)) / c;
1170 }
pit_get_out_edges (s=0x101fb0b0) at
/home/renzo/tests/qemu/cvs/qemu/vl.c:1241
1241 d2 = muldiv64(ticks - s->count_load_time,
1239 d1 = muldiv64(s->count_last_edge_check_time -
s->count_load_time,
1241 d2 = muldiv64(ticks - s->count_load_time,
muldiv64 (a=41505879184, b=1193182, c=0)
at /home/renzo/tests/qemu/cvs/qemu/vl.c:1165
1165 rh = (uint64_t)u.l.high * (uint64_t)b;
1166 rh += (rl >> 32);
1150 {
1168 res.l.low = (((rh % c) << 32) + (rl & 0xffffffff)) / c;
1167 res.l.high = rh / c;
1150 {
1167 res.l.high = rh / c;
1150 {
1165 rh = (uint64_t)u.l.high * (uint64_t)b;
1150 {
1166 rh += (rl >> 32);
1164 rl = (uint64_t)u.l.low * (uint64_t)b;
1167 res.l.high = rh / c;
1168 res.l.low = (((rh % c) << 32) + (rl & 0xffffffff)) / c;
1167 res.l.high = rh / c;
1168 res.l.low = (((rh % c) << 32) + (rl & 0xffffffff)) / c;
1167 res.l.high = rh / c;
1168 res.l.low = (((rh % c) << 32) + (rl & 0xffffffff)) / c;
1170 }
1168 res.l.low = (((rh % c) << 32) + (rl & 0xffffffff)) / c;
1170 }
1243 s->count_last_edge_check_time = ticks;
1244 switch(s->mode) {
1241 d2 = muldiv64(ticks - s->count_load_time,
1244 switch(s->mode) {
1256 d1 /= s->count;
1257 d2 /= s->count;
1256 d1 /= s->count;
1257 d2 /= s->count;
1264 ret = d2 - d1;
1275 }
host_alarm_handler (host_signum=3668, info=0x1e5b9, puc=0xbab40000)
at /home/renzo/tests/qemu/cvs/qemu/vl.c:3062
3062 if (timer_irq_count) {
3061 timer_irq_count += pit_get_out_edges(&pit_channels[0]);
3062 if (timer_irq_count) {
3061 timer_irq_count += pit_get_out_edges(&pit_channels[0]);
3062 if (timer_irq_count) {
3063 if (timer_irq_count > 2)
3064 timer_irq_count = 2;
3065 timer_irq_count--;
3066 timer_irq_pending = 1;
3065 timer_irq_count--;
3066 timer_irq_pending = 1;
3065 timer_irq_count--;
3068 gui_refresh_count += timer_ms;
3069 if (gui_refresh_count >= GUI_REFRESH_INTERVAL) {
3075 DMA_run();
DMA_run () at /home/renzo/tests/qemu/cvs/qemu/dma.c:315
315 if (in_dma) {
310 {
315 if (in_dma) {
310 {
315 if (in_dma) {
320 in_dma = 1;
321 d = dma_controllers;
320 in_dma = 1;
321 d = dma_controllers;
323 for (icont = 0; icont < 2; icont++, d++) {
324 for (ichan = 0; ichan < 4; ichan++) {
329 if ((0 == (d->mask & mask)) && (0 != (d->status &
(mask << 4))))
327 mask = 1 << ichan;
329 if ((0 == (d->mask & mask)) && (0 != (d->status &
(mask << 4))))
324 for (ichan = 0; ichan < 4; ichan++) {
329 if ((0 == (d->mask & mask)) && (0 != (d->status &
(mask << 4))))
327 mask = 1 << ichan;
329 if ((0 == (d->mask & mask)) && (0 != (d->status &
(mask << 4))))
324 for (ichan = 0; ichan < 4; ichan++) {
329 if ((0 == (d->mask & mask)) && (0 != (d->status &
(mask << 4))))
327 mask = 1 << ichan;
329 if ((0 == (d->mask & mask)) && (0 != (d->status &
(mask << 4))))
324 for (ichan = 0; ichan < 4; ichan++) {
329 if ((0 == (d->mask & mask)) && (0 != (d->status &
(mask << 4))))
327 mask = 1 << ichan;
329 if ((0 == (d->mask & mask)) && (0 != (d->status &
(mask << 4))))
324 for (ichan = 0; ichan < 4; ichan++) {
323 for (icont = 0; icont < 2; icont++, d++) {
324 for (ichan = 0; ichan < 4; ichan++) {
329 if ((0 == (d->mask & mask)) && (0 != (d->status &
(mask << 4))))
327 mask = 1 << ichan;
329 if ((0 == (d->mask & mask)) && (0 != (d->status &
(mask << 4))))
324 for (ichan = 0; ichan < 4; ichan++) {
329 if ((0 == (d->mask & mask)) && (0 != (d->status &
(mask << 4))))
327 mask = 1 << ichan;
329 if ((0 == (d->mask & mask)) && (0 != (d->status &
(mask << 4))))
324 for (ichan = 0; ichan < 4; ichan++) {
329 if ((0 == (d->mask & mask)) && (0 != (d->status &
(mask << 4))))
327 mask = 1 << ichan;
329 if ((0 == (d->mask & mask)) && (0 != (d->status &
(mask << 4))))
324 for (ichan = 0; ichan < 4; ichan++) {
329 if ((0 == (d->mask & mask)) && (0 != (d->status &
(mask << 4))))
327 mask = 1 << ichan;
329 if ((0 == (d->mask & mask)) && (0 != (d->status &
(mask << 4))))
324 for (ichan = 0; ichan < 4; ichan++) {
323 for (icont = 0; icont < 2; icont++, d++) {
333 in_dma = 0;
334 }
host_alarm_handler (host_signum=1, info=0x0, puc=0xbab40000)
at /home/renzo/tests/qemu/cvs/qemu/vl.c:3076
3076 SB16_run();
SB16_run () at /home/renzo/tests/qemu/cvs/qemu/sb16.c:563
563 if (0 == dsp.speaker)
567 }
host_alarm_handler (host_signum=1, info=0x0, puc=0xbab40000)
at /home/renzo/tests/qemu/cvs/qemu/vl.c:3078
3078 if (gui_refresh_pending || timer_irq_pending) {
3080 cpu_interrupt(global_env, CPU_INTERRUPT_EXIT);
cpu_x86_interrupt (env=0x10b8f108, mask=1)
at /home/renzo/tests/qemu/cvs/qemu/exec.c:980
980 tb = env->current_tb;
977 env->interrupt_request |= mask;
981 if (tb) {
977 env->interrupt_request |= mask;
981 if (tb) {
982 tb_reset_jump_recursive(tb);
tb_reset_jump_recursive (tb=0x102899b0)
at /home/renzo/tests/qemu/cvs/qemu/exec.c:884
884 tb_reset_jump_recursive2(tb, 0);
tb_reset_jump_recursive2 (tb=0x102899b0, n=0)
at /home/renzo/tests/qemu/cvs/qemu/exec.c:848
848 tb1 = tb->jmp_next[n];
844 {
849 if (tb1 != NULL) {
844 {
849 if (tb1 != NULL) {
880 }
tb_reset_jump_recursive (tb=0x102899b0)
at /home/renzo/tests/qemu/cvs/qemu/exec.c:885
885 tb_reset_jump_recursive2(tb, 1);
tb_reset_jump_recursive2 (tb=0x102899b0, n=1)
at /home/renzo/tests/qemu/cvs/qemu/exec.c:848
848 tb1 = tb->jmp_next[n];
844 {
849 if (tb1 != NULL) {
844 {
849 if (tb1 != NULL) {
880 }
host_alarm_handler (host_signum=271096240, info=0x1, puc=0x4)
at /home/renzo/tests/qemu/cvs/qemu/vl.c:3082
3082 }
I hope this can help...
ciao
renzo
^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2004-01-31 9:29 UTC | newest]
Thread overview: 12+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2004-01-29 6:11 [Qemu-devel] Knoppix results Kyle Hayes
2004-01-29 14:12 ` Renzo Davoli
2004-01-29 14:32 ` Johan Rydberg
2004-01-29 14:51 ` Renzo Davoli
2004-01-29 16:43 ` Kyle Hayes
2004-01-29 17:04 ` Gabriel Ebner
2004-01-29 17:38 ` Johan Rydberg
2004-01-30 5:33 ` Kyle Hayes
2004-01-30 22:15 ` Herbert Poetzl
2004-01-31 9:28 ` Renzo Davoli
2004-01-29 23:22 ` Fabrice Bellard
2004-01-30 5:29 ` Kyle Hayes
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).