[Qemu-devel] Re: Single stepping MIPS in GDB
Hi, if nobody has an idea regarding this, any hint where to search or how to debug this the best way? What confuses me is that qemu.log correctly shows pc=0x80010400 but qemu monitor register info and GDB show pc=0. Thanks Dirk Dirk Behme wrote: Hi, now, after ARM, I try to debug some low level system init code on MIPS as well. For this, I use qemu-snapshot-2006-03-21_23 because this already includes little endian MIPS (--target-list=mipsel-softmmu). I can load my program to MIPS default start address 0x8001, use mipsel-linux-gdb to attach to it and load symbols. Start address is set correctly. But seems that I have trouble single stepping (si). I would assume that with first si system should jump to 0x80010400 (please find some debug output below). Instead, PC is set to 0x0. If I start program with 'continue' in gdb, seems that program starts to run correctly. After stop at random location with ctrl-c in gdb, the following single steps seem to fail as well (please see below as well). Any hints what I'm making wrong here? Many thanks Dirk *1* Debug output for single step at startup. PC is set to 0x0 instead to next command at 0x80010400 _start () at uboot/u-boot-1.1.4/cpu/mips/start.S:43 43 RVECENT(reset,0)/* U-boot entry point */ (gdb) p/x $pc $1 = 0x8001 (gdb) x/2i $pc 0x8001 _start:b 0x80010400 reset 0x80010004 _start+4: nop (gdb) si 0x in ?? () (gdb) p/x $pc $2 = 0x0 (gdb) /tmp cat qemu.log pc=0x8001 HI=0x LO=0x ds 0002 0 GPR00: r0 at v0 v1 GPR04: a0 a1 a2 a3 GPR08: t0 t1 t2 t3 GPR12: t4 t5 t6 t7 GPR16: s0 s1 s2 s3 GPR20: s4 s5 s6 s7 GPR24: t8 t9 k0 k1 GPR28: gp sp s8 ra CP0 Status 0x1044 Cause 0x0400 EPC0x Config0 0x80008090 Config1 0x1e190c8a LLAddr 0x cpu_mips_handle_mmu_fault pc 8001 ad 8001 rw 2 is_user 0 smmu 1 cpu_mips_handle_mmu_fault address=8001 ret 0 physical 0001 prot 3 pc=0x8001 HI=0x LO=0x ds 0002 0 GPR00: r0 at v0 v1 GPR04: a0 a1 a2 a3 GPR08: t0 t1 t2 t3 GPR12: t4 t5 t6 t7 GPR16: s0 s1 s2 s3 GPR20: s4 s5 s6 s7 GPR24: t8 t9 k0 k1 GPR28: gp sp s8 ra CP0 Status 0x1044 Cause 0x0400 EPC0x Config0 0x80008090 Config1 0x1e190c8a LLAddr 0x IN: 0x8001: b 0x80010400 0x80010004: nop OP: 0x: goto_tb0 0x0001: save_pc 0x80010400 0x0002: set_T0 0x829ce00 0x0003: exit_tb 0x0004: reset_T0 0x0005: exit_tb 0x0006: end 2 0002 OUT: [size=24] 0x08a9ce00: jmp0xa4ab0b4 0x08a9ce05: movl $0x80010400,0x80(%ebp) 0x08a9ce0f: mov$0x829ce00,%ebx 0x08a9ce14: ret 0x08a9ce15: xor%ebx,%ebx 0x08a9ce17: ret Trace 0x08a9ce00 [8001] pc=0x80010400 HI=0x LO=0x ds 0002 0 GPR00: r0 at v0 v1 GPR04: a0 a1 a2 a3 GPR08: t0 t1 t2 t3 GPR12: t4 t5 t6 t7 GPR16: s0 s1 s2 s3 GPR20: s4 s5 s6 s7 GPR24: t8 t9 k0 k1 GPR28: gp sp s8 ra CP0 Status 0x1044 Cause 0x0400 EPC0x Config0 0x80008090 Config1 0x1e190c8a LLAddr 0x pc=0x80010400 HI=0x LO=0x ds 0002 0 GPR00: r0 at v0 v1 GPR04: a0 a1 a2 a3 GPR08: t0 t1 t2 t3 GPR12: t4 t5 t6 t7 GPR16: s0 s1 s2 s3 GPR20: s4 s5 s6 s7 GPR24: t8 t9 k0 k1 GPR28: gp sp s8 ra CP0 Status 0x1044 Cause 0x0400 EPC0x Config0 0x80008090 Config1 0x1e190c8a LLAddr 0x IN: OP: 0x: save_pc 0x80010400 0x0001: debug 0x0002: end 2 0002 OUT: [size=21] 0x08a9ce20: movl $0x80010400,0x80(%ebp) 0x08a9ce2a: push $0x10002 0x08a9ce2f: call 0x80866c0 0x08a9ce34: pop%eax Trace 0x08a9ce20 [80010400] search pc 1
[Qemu-devel] Missing ARMv6 instructions?
Hello list, Running an ARM application in user mode emulation (qemu CVS version of 3-15-2006), my code crashes at an SMMUL instruction (this is part of the ARMv6 instruction set). A brief glance at translate.c and op.c seems to suggest that qemu does not emulate that instruction (yet). Before I dig any deeper, could somebody in the know (Paul?) confirm or reject this suspicion? Thanks much, -- Wolfgang Schildbach, Senior Research Engineer Coding Technologies GmbH ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] [PATCH] Fix some minor warnings from qemu-doc.texi
Hi, texi2html prints several warnings when it processes qemu-doc.texi. Some of these warnings are fixed with my patch. Merci Stefan diff -u -b -B -u -r1.81 qemu-doc.texi --- qemu-doc.texi 20 Feb 2006 00:35:00 - 1.81 +++ qemu-doc.texi 29 Mar 2006 12:04:36 - @@ -903,7 +903,7 @@ @example ./qemu.sh Connected to host network interface: tun0 -Linux version 2.4.21 ([EMAIL PROTECTED]) (gcc version 3.2.2 20030222 (Red Hat Linux 3.2.2-5)) #5 Tue Nov 11 18:18:53 CET 2003 +Linux version 2.4.21 (bellard@@voyager.localdomain) (gcc version 3.2.2 20030222 (Red Hat Linux 3.2.2-5)) #5 Tue Nov 11 18:18:53 CET 2003 BIOS-provided physical RAM map: BIOS-e801: - 0009f000 (usable) BIOS-e801: 0010 - 0200 (usable) @@ -940,7 +940,7 @@ pty: 256 Unix98 ptys configured Serial driver version 5.05c (2001-07-08) with no serial options enabled ttyS00 at 0x03f8 (irq = 4) is a 16450 -ne.c:v1.10 9/23/94 Donald Becker ([EMAIL PROTECTED]) +ne.c:v1.10 9/23/94 Donald Becker (becker@@scyld.com) Last modified Nov 1, 2000 by Paul Gortmaker NE*000 ethercard probe at 0x300: 52 54 00 12 34 56 eth0: NE2000 found at 0x300, using IRQ 9. @@ -963,7 +963,7 @@ VFS: Mounted root (ext2 filesystem). Freeing unused kernel memory: 64k freed -Linux version 2.4.21 ([EMAIL PROTECTED]) (gcc version 3.2.2 20030222 (Red Hat Linux 3.2.2-5)) #5 Tue Nov 11 18:18:53 CET 2003 +Linux version 2.4.21 (bellard@@voyager.localdomain) (gcc version 3.2.2 20030222 (Red Hat Linux 3.2.2-5)) #5 Tue Nov 11 18:18:53 CET 2003 QEMU Linux test distribution (based on Redhat 9) ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] Re: Single stepping MIPS in GDB
Hi, answering to myself again ;) Now, I found where the PC is wrongly set to 0x0: In translate-all.c, end of function cpu_restore_state() (lines with '+' are debug output added): #elif defined(TARGET_MIPS) +printf(PC before: 0x%08x, j: %d, OPC_BUF_SIZE: %d\n, env-PC, j, OPC_BUF_SIZE); +for(c = 0; c OPC_BUF_SIZE; c++) + printf(OPC %03d: 0x%08x\n, c, gen_opc_pc[c]); env-PC = gen_opc_pc[j]; +printf(PC after: 0x%08x\n, env-PC); env-hflags = ~MIPS_HFLAG_BMASK; env-hflags |= gen_opc_hflags[j]; #endif results in the following output (0x80010400 is the correct one): PC before: 0x80010400, j: -8185, OPC_BUF_SIZE: 512 OPC 000: 0x OPC 001: 0x ... OPC 510: 0x OPC 511: 0x PC after: 0x If I temporarily delete the line env-PC = gen_opc_pc[j]; single stepping seems to work. Seems that gen_opc_pc is all 0, and j looks strange. But I don't know whats wrong here? ;( Best regards Dirk Dirk Behme wrote: I try to debug some low level system init code on MIPS as well. For this, I use qemu-snapshot-2006-03-21_23 because this already includes little endian MIPS (--target-list=mipsel-softmmu). I can load my program to MIPS default start address 0x8001, use mipsel-linux-gdb to attach to it and load symbols. Start address is set correctly. But seems that I have trouble single stepping (si). I would assume that with first si system should jump to 0x80010400 (please find some debug output below). Instead, PC is set to 0x0. *1* Debug output for single step at startup. PC is set to 0x0 instead to next command at 0x80010400 _start () at uboot/u-boot-1.1.4/cpu/mips/start.S:43 43 RVECENT(reset,0)/* U-boot entry point */ (gdb) p/x $pc $1 = 0x8001 (gdb) x/2i $pc 0x8001 _start:b 0x80010400 reset 0x80010004 _start+4: nop (gdb) si 0x in ?? () (gdb) p/x $pc $2 = 0x0 (gdb) ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel][PATCH] add PNI user instructions
I've posted a patch that adds SSE3 instruction emulation to QEMU some weeks ago, but it accidentally contained some silly changes. Sorry for that. I'm currently very short on time, so I've just attached a fixed version. To complete PNI, both the monitor and the mwait instruction, and also the MON CPUID flag must be added. Fabrice Bellard wrote: The problem is that it is not possible to trap on the CPUID instruction :-( So the only possible patch is to support PNI in QEMU. For monitor/mwait for example, doing nops should suffice... Fabrice. -- Joachim Henke http://he-jo.net/ sse3-2006-03-28.diff Description: Binary data --Apple-Mail-11--16704747- ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Missing ARMv6 instructions?
Thanks, Paul. That explains it... I find it strange that ARM would restrict emulation of their architecture -- that could hardly pose a threat to their business, I would say. Anyhow, thanks for the note. - Wolfgang Paul Brook [EMAIL PROTECTED] wrote on 29.03.2006 16:39:12: On Wednesday 29 March 2006 13:33, Wolfgang Schildbach wrote: Hello list, Running an ARM application in user mode emulation (qemu CVS version of 3-15-2006), my code crashes at an SMMUL instruction (this is part of the ARMv6 instruction set). A brief glance at translate.c and op.c seems to suggest that qemu does not emulate that instruction (yet). Before I dig any deeper, could somebody in the know (Paul?) confirm or reject this suspicion? qemu cvs only supports ARMv5TE. The ARMv6 architecture is released under a more restrictive licence than ARMv5. The Arm licencing department have explicitly prohibited the distribution of open source ARMv6/v7 emulators. We're trying to get this restriction lifted, but so far to no avail. Paul -- Wolfgang Schildbach, Senior Research Engineer Coding Technologies GmbH ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] [PATCH] Add gcc 4.0 support
I was just thinking that by enabling the required feature individually, someone else could choose -O0 and not have to investigate why it fails. Its not like its a big deal, though. :-) JP P.S. Why does the list set the reply-to header, isn't that supposed to be a Bad Thing™? On 29 Mar 2006, at 01:59, Thiemo Seufer wrote: On Tue, Mar 28, 2006 at 08:26:27PM -0800, John Davidorff Pell wrote: Out of curiosity, wouldn't it be better to specifically request that feature of gcc, with one of its myriad options, rather than forcing a rather large optimization sweep? I'm sure that -O2 is good generally, but using it as a kludge to get at one of the many things that it enables seems like a not-so-great-idea. Its like buying a restaurant so that you can get a chef's stove. Well, I went through the ppc disassembly and found no reason to disable -O2. Note that it was the default before, I only noticed the breakage when I lowered the global optimisation to -O0 for better debugging. Thiemo ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel -- Blood is thicker than water... and much tastier. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] [PATCH] Add gcc 4.0 support
On 3/29/06, John Davidorff Pell [EMAIL PROTECTED] wrote: P.S. Why does the list set the reply-to header, isn't that supposed to be a Bad Thing™? Only according to some people :) I hate when I reply to a list and the message goes to the guy and not to the list... (If someone enforces Reply-To in his mail I think however that it should remain). ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] [PATCH] Add gcc 4.0 support
On Wednesday 29 March 2006 18:03, John Davidorff Pell wrote: I was just thinking that by enabling the required feature individually, someone else could choose -O0 and not have to investigate why it fails. Its not like its a big deal, though. :-) Like most things dyngen relies on this isn't a feature as such. There's no gcc option that says make sure this function doesn't have a stack frame. It just happens that at with optimisation turned on this is generally true. Also, the gcc -O2 option is more than the sum of the other options it enables. Paul ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] [PATCH] Add gcc 4.0 support
On Wed, 29 Mar 2006 21:24:59 +0200, Pascal Terjan [EMAIL PROTECTED] wrote: On 3/29/06, John Davidorff Pell [EMAIL PROTECTED] wrote: P.S. Why does the list set the reply-to header, isn't that supposed to be a Bad Thing? Only according to some people :) I hate when I reply to a list and the message goes to the guy and not to the list... (If someone enforces Reply-To in his mail I think however that it should remain). I kind of like it and wish that some lists would allow me to set it as a user-preference - there are so many lists and I really never ever want to reply to *just* the person (ever, ever, ever). reply-to the list is good for me Auke ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Off Topic] Re: [Qemu-devel] [PATCH] Add gcc 4.0 support
On Wed, Mar 29, 2006 at 09:24:59PM +0200, Pascal Terjan wrote: On 3/29/06, John Davidorff Pell [EMAIL PROTECTED] wrote: P.S. Why does the list set the reply-to header, isn't that supposed to be a Bad Thing?? Only according to some people :) I hate when I reply to a list and the message goes to the guy and not to the list... (If someone enforces Reply-To in his mail I think however that it should remain). Thats the fault of a badly configured mail client. I personally dislike Reply-To mailing lists, but I fixed my mail client (mutt) so it doesn't matter as much. The reason I dislike Reply-To mailing lists - it is generally better to accidently send a list mail to one person than to send a one-person mail to the list. (But again I fixed my client so this doesn't affect me so much.) -- Infinite complexity begets infinite beauty. Infinite precision begets infinite perfection. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Missing ARMv6 instructions?
Paul Brook [EMAIL PROTECTED] wrote: The ARMv6 architecture is released under a more restrictive licence than ARMv5. The Arm licencing department have explicitly prohibited the distribution of open source ARMv6/v7 emulators. We're trying to get this restriction lifted, but so far to no avail. One more thing: how about adding the above to the QEMU FAQ? -- Jamie ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Missing ARMv6 instructions?
Paul Brook [EMAIL PROTECTED] wrote: qemu cvs only supports ARMv5TE. The ARMv6 architecture is released under a more restrictive licence than ARMv5. The Arm licencing department have explicitly prohibited the distribution of open source ARMv6/v7 emulators. We're trying to get this restriction lifted, but so far to no avail. Wolfgang Schildbach wrote: Thanks, Paul. That explains it... I find it strange that ARM would restrict emulation of their architecture -- that could hardly pose a threat to their business, I would say. I find it strange that they can restrict emulation, if they can. Perhaps they can't, and maybe they like to send threatening letters to frighten people away from doing it? That's not so surprising for ARM. They halted the development of an open source ARM-compatible FPGA design too. What claim does ARM have over software that they don't write and whose only resemblance is that it speaks the same protocol? It looks, and smells, like an attempt at interface copyright. I.e. to copyright something just for offering a similar interface. E.g. much the same as Microsoft attempting to stop people implementing a task bar. Yet, Microsoft can't do that, and nobody is afraid of writing window managers with task bars. I could understand a claim if someone acquired ARM's documentation under an agreement to not produce an emulator. But I don't see how someone who has no connection with ARM can be restricted by ARM in that way. Has ARM ever actually followed through on their threats and _won_ a case to ban compatible software from being distributed? And if there is a possibility of that - in which countries do they have any weight? Dare I suggest encouraging the development of patches they don't like to countries where they have no legal weight? -- Jamie ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Off Topic again] Re: [Qemu-devel] [PATCH] Add gcc 4.0 support
On Wed, Mar 29, 2006 at 07:37:50PM +, sofar wrote: I kind of like it and wish that some lists would allow me to set it as a user-preference - there are so many lists and I really never ever want to reply to *just* the person (ever, ever, ever). reply-to the list is good for me Auke Actually, I'm for making it a user preference. This might be difficult to implement in the mailing list software but is IMVHO a worthwhile addition. That way users who find mangled mails convient can get what they want without having to compromise the rest of us (sane) users.. Of course there are those who will say that this should be a mail client option, not a mailing list problem. Well, here is what I have to do to work around mailing lists of both types (those that do mangle and those that don't): reply command (looks at From: and ignores Reply-To: - necessary to reply just to the person if the list does reply-to mangling) reply-to-reply command (uses Reply-To: - I have never actually used this for anything ;) but it is there for those cases such as when I get an individual email that has a Reply-To: on it for whatever reason) reply-to-replied command (looks at the To: header, this is a bit counterintutive but provides an easy way to reply directly to the list when the list does not do reply-to mangling) reply-to-group (replies to everyone in the To: and Cc: and etc.. - generally avoided as it often results in duplicate mails) reply-to-list (replies to the mailing list as defined in a config file - this is for those corner cases where I want to reply to only the list but the list is in the Cc: or something - this is rare) Some food for thought. How many people think adding all these options to all e-mail clients is a good idea? :) -- Infinite complexity begets infinite beauty. Infinite precision begets infinite perfection. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Missing ARMv6 instructions?
I could understand a claim if someone acquired ARM's documentation under an agreement to not produce an emulator. That's exactly where the restriction comes from. Theoretically it may be possible to reverse engineer a good proportion of ARMv6 from other sources (eg. gcc). However if that were done it would mean anyone with access to the real ARM documentation (i.e. me and probably anyone else with any professional/commercial interest in ARM emulation) would be unable to contribute to qemu. And if there is a possibility of that - in which countries do they have any weight? Dare I suggest encouraging the development of patches they don't like to countries where they have no legal weight? I don't think that's particularly helpful or practical suggestion. Better would be to lobby ARM to allow open source emulators. I'd like to use ARM hardware for big project, but qemu doesn't support ARMv7 so I'm thinking of using PowerPC instead is a particularly good argument ;-) Paul ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Missing ARMv6 instructions?
So it's a purely contractual issue as opposed to an IP issue.Is a party to this contract allowed to write a disassembler? I can imagine a very nice disassembler feature that would explain in detail how each instruction it decodes works... Of course no matter how such documentation were to escape, you're still used up by your contractual obligations as far as implementing an emulator, I guess.-- John. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Missing ARMv6 instructions?
Paul Brook wrote: Better would be to lobby ARM to allow open source emulators. I'd like to use ARM hardware for big project, but qemu doesn't support ARMv7 so I'm thinking of using PowerPC instead is a particularly good argument ;-) I suspect ARM's business model - dependent wholly on licensing the ARM architecture in various forms - would make it very difficult for them to agree to that argument even if it would gain them one customer. It'll be interesting when someone develops a compiler that uses very detailed machine descriptions - with enough detail to describe an architecture well enough that the description can also be used (by a different program) to emulate it to a significant degree. They need good compilers to support the architrecture. But a very detailed machine description is also their business nightmare: the basis for software, and later hardware, implementations of their architecture. I wonder if people such as yourself will be able to contribute to the development of the machine description for such a compiler. -- Jamie ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] Qemu failures: x86_64 host / x86_64 guest
Hi,
still no luck with x86_64 on last night CVS build...
* CentOS 3.6 x86_64:
- UP won't boot with or without kqemu. Log file is attached.
- Booting with -kernel-kqemu is even worse: the guest kernel won't start
at all (at least it does not print anything).
- Booting with -smp 2 makes it a bit further: the kernel fully boots but
the system crashes while starting Anaconda. System output in attachment.
In all cases qemu gets stuck eating 100% CPU.
* CentOS 4.2 x86_64:
- UP does run without kqemu and with user code virtualization. Booting
with -smp 2 also works.
- However, running with -kernel-kqemu does not work: the kernel won't
boot and it makes qemu crash. Log files are attached (guest output and
crash).
The good news is that i386 versions for both distros do run smoothly :-)
Host system is an Athlon 64 running a Mandriva 2006.0 with a plain kernel.org
2.6.15-4 kernel. Kqemu is 1.3.0pre5. Qemu was compiled with gcc 3.3.6-2mdk
and the host kernel with gcc 4.0.2-1mdk.
I tried several values for '-m' (128,160,192,224) with the same results.
Fabrice, do you need any more information in order to help you debug this ?
Regards,
Thibaut
ok
Bootdata ok (command line is initrd=initrd.img devfs=nomount ramdisk_size=9216
BOOT_IMAGE=vmlinuz text console=ttyS0,115200)
Linux version 2.4.21-37.EL ([EMAIL PROTECTED]) (gcc version 3.2.3 20030502 (Red
Hat Linux 3.2.3-52)) #1 SMP Wed Sep 28 12:59:51 EDT 2005
BIOS-provided physical RAM map:
BIOS-e820: - 0009fc00 (usable)
BIOS-e820: 0010 - 0c00 (usable)
kernel direct mapping tables upto 1000c00 @ 8000-a000
No NUMA configuration found
Faking a node at -0c00
Bootmem setup node 0 -0c00
setting up node 0 0-c000
On node 0 totalpages: 49152
zone(0): 4096 pages.
zone(1): 45056 pages.
zone(2): 0 pages.
ACPI: Unable to locate RSDP
Found and enabled local APIC!
Kernel command line: initrd=initrd.img devfs=nomount ramdisk_size=9216
BOOT_IMAGE=vmlinuz text console=ttyS0,115200
Initializing CPU#0
time.c: Detected 1.193182 MHz PIT timer.
time.c: Detected 1795.151 MHz TSC timer.
Console: colour VGA+ 80x25
Calibrating delay loop... 3565.15 BogoMIPS
Page-cache hash table entries: 65536 (order: 7, 512 KB)
Page-pin hash table entries: 16384 (order: 4, 64 KB)
Dentry cache hash table entries: 32768 (order: 7, 512 KB)
Inode cache hash table entries: 16384 (order: 6, 256 KB)
Buffer cache hash table entries: 16384 (order: 5, 128 KB)
Memory: 179516k/196608k available (1821k kernel code, 0k reserved, 1883k data,
228k init)
Mount cache hash table entries: 256 (order: 0, 4096 bytes)
CPU: L1 I Cache: 64K (64 bytes/line/2 way), D cache 64K (64 bytes/line/2 way)
CPU: L2 Cache: 512K (64 bytes/line/8 way)
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#0.
POSIX conformance testing by UNIFIX
mtrr: v2.02 (20020716))
CPU: L1 I Cache: 64K (64 bytes/line/2 way), D cache 64K (64 bytes/line/2 way)
CPU: L2 Cache: 512K (64 bytes/line/8 way)
CPU0: QEMU Virtual CPU version 0.8.0 stepping 03
per-CPU timeslice cutoff: 2560.10 usecs.
task migration cache decay timeout: 10 msecs.
SMP motherboard not detected.
general protection fault:
CPU 0
Pid: 1, comm: swapper Not tainted
RIP: 0010:[f000ff53f000ff53]
RSP: :01000bfd3ee0 EFLAGS: 0216
RAX: RBX: 0011 RCX: 00050011
RDX: 804388c0 RSI: 010001bd6140 RDI: 804388a0
RBP: R08: R09:
R10: 0001 R11: R12:
R13: R14: R15:
FS: () GS:805e8040() knlGS:
CS: 0010 DS: 0018 ES: 0018 CR0: 8005003b
CR2: CR3: 00101000 CR4: 06e0
Call Trace: [8010c098]{init+40} [80110cc1]{child_rip+8}
[8010c070]{init+0} [80110cb9]{child_rip+0}
Process swapper (pid: 1, stackpage=1000bfd3000)
Stack: 01000bfd3ee0 806280f5
806286bc 80627b14
80621599 01000bfd2000 8010c098
80110cc1
000a
805eecc0 805eecc0 805eed08
8061e000 0e00 8010c070
80110cb9 0010 0200
01000bfd3f58
Call Trace: [8010c098]{init+40} [80110cc1]{child_rip+8}
[Qemu-devel] Keyboard/Mouse issues on WinXP loadvm
The virtual keyboard and mouse appear to be confused after loadvm'ing on Windows XP SP2 (and 2000 SP4 as well) guest (Qemu CVS on Linux host). The control key appears to be stuck down. While looking for something unrelated in the mailing list archives, I found these: http://lists.gnu.org/archive/html/qemu-devel/2005-05/msg00021.html http://lists.gnu.org/archive/html/qemu-devel/2005-05/msg0.html It appears to be describing the exact same problem, but on a Linux guest. The suggested solution was to press Ctrl, Shift, Alt one after the other after restoring the VM. This doesn't appear to work on my Windows guest. Is there another way to fix this? -- Andrew Barr | 1024D/AD9AE76A [EMAIL PROTECTED] | http://www.oakcourt.dyndns.org/~andrew Quimby: Can't we have one meeting that doesn't end in someone digging up a body? -- The Simpsons, Lisa the Iconoclast (3F13) ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Keyboard/Mouse issues on WinXP loadvm
Hi, On Wed, 29 Mar 2006, Andrew Barr wrote: The virtual keyboard and mouse appear to be confused after loadvm'ing on Windows XP SP2 (and 2000 SP4 as well) guest (Qemu CVS on Linux host). The control key appears to be stuck down. While looking for something unrelated in the mailing list archives, I found these: http://lists.gnu.org/archive/html/qemu-devel/2005-05/msg00021.html http://lists.gnu.org/archive/html/qemu-devel/2005-05/msg0.html It appears to be describing the exact same problem, but on a Linux guest. The suggested solution was to press Ctrl, Shift, Alt one after the other after restoring the VM. This doesn't appear to work on my Windows guest. Is there another way to fix this? Okay, let's recapitulate: you - switch to the console by hitting Ctrl+Alt+2 - say savevm bla.vm - exit and then - start qemu with -loadvm bla.vm? Now think a little about what the emulated machine is doing! The VM gets Ctrl+Alt and up to this point it does not yet know that you want to change to the console, so it dutifully reports these keyboard down events to the underlying machine. Since you then save the image and exit, the saved state still contains that information: the Ctrl and Shift keys are pressed. So, either you did not really try to hit Ctrl and Alt keys, or Windows does other strange things. You could try to switch to the console and back, to see if qemu is getting the keys. Hth, Dscho ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
