On 09/10/11 01:45 AM, Blue Swirl wrote:
I don't know enough about SPARC32 architecture to know if that gives more useful information... I don't see the 0x4c value in my log file. I tried turning on DEBUG_MMU, but stopped when my log file hit 4GB and I hadn't hit the stopping point yet.
Any ideas for other things to try or set for more debugging?
Since this is repeatable, you could try something like this (untested): diff --git a/target-sparc/op_helper.c b/target-sparc/op_helper.c index d1a8dd9..2594bbd 100644 --- a/target-sparc/op_helper.c +++ b/target-sparc/op_helper.c @@ -1836,6 +1836,11 @@ uint64_t helper_ld_asi(target_ulong addr, int asi, int size, int sign) ret = mmu_probe(env, addr, mmulev); DPRINTF_MMU("mmu_probe: 0x%08x (lev %d) -> 0x%08" PRIx64 "\n", addr, mmulev, ret);
if (addr == 0xf5901400) {printf("mmu_probe: 0x%08x (lev %d) -> 0x%08" PRIx64 "\n",addr, mmulev, ret);dump_mmu(stdout, fprintf, env);} } break; case 4: /* read MMU regs */
Tweaking that a little, I now find myself at pc=0xf01850c8, because that is the current instruction when the page tables write out.
(qemu) info cpus * CPU #0: pc=0xf01850c8 npc=0xf01850cc thread_id=3483 (qemu) info registers pc: f01850c8 npc: f01850cc General Registers: %g0-7: 00000000 f024dc00 00000003 f5a6b104 00000004 fbf45b80 f0041000 f5dd0500
Current Register Window: %o0-7: 00000000 f026a2d8 f5901000 f5901200 f026a2dc f018505c f026a270 f005c5a4 %l0-7: 04001fc5 f00436ac 000003a6 00000020 00000000 00000009 00000000 00000001 %i0-7: f026a6c0 f026a40c f5901000 000003a6 00000002 f026a384 f026a2e8 f005cefc
Floating Point Registers: %f00: 000000000.000000 000000000.000000 -NaN -NaN %f04: -NaN -NaN -NaN -NaN .... %f28: -NaN -NaN -NaN -NaN psr: 04401fe5 (icc: -Z-- SPE: SPE) wim: 00000002 fsr: 00080000 y: 00000000 (qemu) x /30i 0xf01850a0 0xf01850a0: and %o0, 3, %o3 0xf01850a4: cmp %o3, 2 0xf01850a8: bne 0xf01850c0 0xf01850ac: srl %o2, 0xc, %o3 0xf01850b0: and %o3, 0x3f, %o3 0xf01850b4: sll %o3, 8, %o3 0xf01850b8: b 0xf01850c8 0xf01850bc: add %o0, %o3, %o0 0xf01850c0: mov %o2, %o3 0xf01850c4: lda [ %o3 ] #ASI_M_FLUSH_PROBE, %o0 0xf01850c8: srl %o0, 0x18, %o3 0xf01850cc: andcc %o3, 7, %o3 0xf01850d0: be 0xf01850dc 0xf01850d4: nop 0xf01850d8: sta %g0, [ %o2 ] #ASI_M_FLUSH_PROBE 0xf01850dc: mov 0x300, %o2 0xf01850e0: cmp %o1, 0 0xf01850e4: be 0xf01850f0 0xf01850e8: lda [ %o2 ] #ASI_M_MMUREGS, %o2 0xf01850ec: st %o2, [ %o1 ] 0xf01850f0: retl 0xf01850f4: nop 0xf01850f8: sethi %hi(0x10003000), %o2 0xf01850fc: or %o2, 0x18, %o2 ! 0x10003018 0xf0185100: retl 0xf0185104: lda [ %o2 ] #ASI_M_BYPASS, %o0 0xf0185108: unimp 0 0xf018510c: unimp 0 0xf0185110: unimp 0 0xf0185114: unimp 0
Now I know reading fragments of assembly are lots of fun, so I've attached the dump_mmu results, which will hopefully also be useful.
Does that help point to a next step?
Thanks! Nathan
On 10/09/11 23:23, Nathan Kunkee wrote:
Tweaking that a little, I now find myself at pc=0xf01850c8, because that is the current instruction when the page tables write out.
(qemu) info cpus
- CPU #0: pc=0xf01850c8 npc=0xf01850cc thread_id=3483
(qemu) info registers pc: f01850c8 npc: f01850cc General Registers: %g0-7: 00000000 f024dc00 00000003 f5a6b104 00000004 fbf45b80 f0041000 f5dd0500
Current Register Window: %o0-7: 00000000 f026a2d8 f5901000 f5901200 f026a2dc f018505c f026a270 f005c5a4 %l0-7: 04001fc5 f00436ac 000003a6 00000020 00000000 00000009 00000000 00000001 %i0-7: f026a6c0 f026a40c f5901000 000003a6 00000002 f026a384 f026a2e8 f005cefc
Floating Point Registers: %f00: 000000000.000000 000000000.000000 -NaN -NaN %f04: -NaN -NaN -NaN -NaN .... %f28: -NaN -NaN -NaN -NaN psr: 04401fe5 (icc: -Z-- SPE: SPE) wim: 00000002 fsr: 00080000 y: 00000000 (qemu) x /30i 0xf01850a0 0xf01850a0: and %o0, 3, %o3 0xf01850a4: cmp %o3, 2 0xf01850a8: bne 0xf01850c0 0xf01850ac: srl %o2, 0xc, %o3 0xf01850b0: and %o3, 0x3f, %o3 0xf01850b4: sll %o3, 8, %o3 0xf01850b8: b 0xf01850c8 0xf01850bc: add %o0, %o3, %o0 0xf01850c0: mov %o2, %o3 0xf01850c4: lda [ %o3 ] #ASI_M_FLUSH_PROBE, %o0 0xf01850c8: srl %o0, 0x18, %o3 0xf01850cc: andcc %o3, 7, %o3 0xf01850d0: be 0xf01850dc 0xf01850d4: nop 0xf01850d8: sta %g0, [ %o2 ] #ASI_M_FLUSH_PROBE 0xf01850dc: mov 0x300, %o2 0xf01850e0: cmp %o1, 0 0xf01850e4: be 0xf01850f0 0xf01850e8: lda [ %o2 ] #ASI_M_MMUREGS, %o2 0xf01850ec: st %o2, [ %o1 ] 0xf01850f0: retl 0xf01850f4: nop 0xf01850f8: sethi %hi(0x10003000), %o2 0xf01850fc: or %o2, 0x18, %o2 ! 0x10003018 0xf0185100: retl 0xf0185104: lda [ %o2 ] #ASI_M_BYPASS, %o0 0xf0185108: unimp 0 0xf018510c: unimp 0 0xf0185110: unimp 0 0xf0185114: unimp 0
Now I know reading fragments of assembly are lots of fun, so I've attached the dump_mmu results, which will hopefully also be useful.
Does that help point to a next step?
Hi Nathan,
From previous experience with Solaris 8, I think that you may be on a red herring with your 0xf0.. address being the cause. I expect you'll find that this is some kind of error/panic handler within the main Solaris kernel.
The way to find out is make sure that you have a cross-SPARC gdb to hand and then invoke QEMU with the -s (gdbstub) option and connect into the SPARC virtual using gdb's target command as per the documentation. You can then use add-symbol-file to load the Solaris ELF kernel executable into gdb and continue execution. Then at the point where it hangs, you can issue a CTRL-C in the gdb window followed by "bt" to get a backtrace to confirm my panic handler suspicion.
Looking at the address spaces, my guess is that the memory region around 0xf59... is reserved for loading dynamic modules into the kernel. Possibly I would try and use objdump of the binaries on the CDROM to locate some kind of module magic containing the module name. You should then be able to use GDB (or perhaps even the QEMU monitor as you have done) to work backwards in memory to locate the magic, and hence determine which module is causing the error.
HTH,
Mark.
-
Mark Cave-Ayland -
Nathan Kunkee