Hello Blue, Testing a potential AREG0 fix for ppc host by malc I got an error running `./sparc-softmmu/sparc-softmmu` (same with CD/kernel):
qemu: fatal: Trap 0x07 while interrupts disabled, Error state pc: 00005e0c npc: 00005e10 General Registers: %g0-7: 00000000 00000001 babababa 00000000 00000020 07ffff08 07ffe000 babababa Current Register Window: %o0-7: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 %l0-7: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 %i0-7: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 Floating Point Registers: %f00: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 %f08: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 %f16: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 %f24: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 psr: 048000c0 (icc: N--- SPE: SP-) wim: 00000001 fsr: 00000000 y: 00000020 Abgebrochen The 0xbabababa in %g2 and %g7 is a signature I've seen in uninitialized memory on openSUSE 12.1 Betas. So I ran valgrind, and the following caught my eye on both ppc and x86_64: ==18801== Command: ./sparc-softmmu/qemu-system-sparc ==18801== ==18801== Thread 2: ==18801== Conditional jump or move depends on uninitialised value(s) ==18801== at 0x25C5AF: compute_all_logic (cc_helper.c:37) ==18801== by 0x25C648: helper_compute_psr (cc_helper.c:470) ==18801== by 0x8CD0981: ??? ==18801== Uninitialised value was created by a heap allocation ==18801== at 0x4C27CE8: memalign (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==18801== by 0x4C27D97: posix_memalign (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==18801== by 0x1F2101: qemu_memalign (oslib-posix.c:93) ==18801== by 0x1F21A9: qemu_vmalloc (oslib-posix.c:126) ==18801== by 0x2665F6: qemu_ram_alloc_from_ptr (exec.c:2647) ==18801== by 0x286D76: memory_region_init_ram (memory.c:954) ==18801== by 0x297FFD: ram_init1 (sun4m.c:757) ==18801== by 0x204DAE: qdev_init (qdev.c:151) ==18801== by 0x204EEC: qdev_init_nofail (qdev.c:258) ==18801== by 0x298845: ram_init.constprop.7 (sun4m.c:783) ==18801== by 0x298980: sun4m_hw_init (sun4m.c:862) ==18801== by 0x2994A2: ss5_init (sun4m.c:1289) This is at 8f473dd104f0937ce98523fa6f9de0bd845aebbe, and cc_helper.c:37 is int32_t dst argument of get_NZ_icc(), which is always called with CC_DST, i.e. env->cc_dst. This seems to indicate that a read from uninitialized memory occurred, from which cc_dst is being initialized? Any idea where that could originate from or how to further debug? It doesn't seem to be caused by the 7d21dcc84b8c07918124a9c0708694d2fb013f65 OpenBIOS r1056 update. Regards, Andreas -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg