* [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 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
* 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
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).