When Qemu seems to loop I switched to monitor mode "stop" the emulator and gathered the output of some "info" operations. The "info registers" show that registers contain the "strange" values, for example:
RBX=ffffffff80523028 RSP=ffffffff80522dc0 RIP=ffffffff8025e67c Is it normal that e.g. the instruction pointer (RIP) can have such a value? Any clue where to look why this loop happens? Just as a side note: trying to print registers using "p /x $r15" this show the content of R15, but using "p /x $rip" or "p /x $rbx" gives an "unknown register" error message. Regards, Werner Werner Dittmann wrote: > Just forgot to give the info about my system: > > Qemu was built and runs on a Suse 10.1 64 bit system (AMD CPU). Also, > while compiling Qemu I got quite some warning about casting pointers to > integer of different size (64bit vs 32 bit). Is this ok? > > Regards, > Werner > > Werner Dittmann wrote: >> All, >> >> currently I'm trying to install an Opensuse 10.2 64Bit version in Qemu. >> >> Using a plain 0.82 didn't work out, after the Install screen Qemu goes >> in a loop. I've tried several parameters (witout net, ACPI, kqemu, etc). >> I could not even stop Qemu but had to use kill -9 . >> Because of some mail in the list that reported similar errors I >> downloaded the latest CVS version and built it using a gcc 3.3. >> >> That didn't solve the problem: It seems to be in a loop but I can close >> the qemu window and the window also grabs the mouse cursor (that was not >> the case with the 0.8.2 version). >> >> After loading the kernel I get the following message on the console >> (only in VESA mode): >> >> " >> Decompressing Linux ... done. >> Booting the kernel. >> " >> >> and at the bottom of the console screen the message (without the qutes): >> >> "kernel direct mapping tables up to 100000000 @ 8000-d000" >> >> I tried to switch on some -d but I don't know which one is relevant >> here. I tried "-d int" but this produced about 90MB log data in just >> some seconds. >> >> Which info do you need to get down to the problem? What can I try to >> tackle the problem? >> >> Regards, >> Werner >> >> PS: Because I'm somewhat experienced with security software I would ask >> if there is any interest to have a TPM module (Software based TPM) for >> Qemu that looks like a real HW TPM according the the TPM specs? If yes I >> would start to look how to do it for Qemu. There is a software based TPM >> avaliable with a GPL licence. The "only thing" to do would be to wrap it >> with the HW interface functions (it's a memory mapped interface) so that >> standard drivers would see it as standard TPM module. >> >> Werner >> >> >> >> >> _______________________________________________ >> Qemu-devel mailing list >> Qemu-devel@nongnu.org >> http://lists.nongnu.org/mailman/listinfo/qemu-devel >> > > > > > _______________________________________________ > Qemu-devel mailing list > Qemu-devel@nongnu.org > http://lists.nongnu.org/mailman/listinfo/qemu-devel > _______________________________________________ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel