qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
* [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).