On Sun, Oct 31, 2010 at 2:07 PM, Mark Cave-Ayland mark.cave-ayland@siriusit.co.uk wrote:
Mark Cave-Ayland wrote:
I'm not sure exactly what's happening, although it seems like some kind of I/O memory access is triggering the error before the neverland mapping is removed?
I still think it's just an access to the unmapped memory region.
Even simpler than that: the reason the neverland code is being invoked is because env->psret == 0 (i.e. traps are disabled), not because the MMU is in no fault mode:
This means that is a fault in a fault handler. The reason for it can be stack or something else getting exhausted while trying to process some trap. Or the trap handler tries to report the error over some non-existent device.
Are you running with -nographic?
Also Solaris boot option "-v" makes the boot more verbose.
Breakpoint 1, cpu_sparc_handle_mmu_fault (env=0x10579f0, address=4028890828, rw=1, mmu_idx=1, is_softmmu=1) at /home/build/src/qemu/git/qemu/target-sparc/helper.c:261 261 vaddr = address & TARGET_PAGE_MASK; (gdb) p/x env->mmuregs[0] & MMU_NF No symbol "MMU_NF" in current context. (gdb) p/x env->mmuregs[0] & 2 $5 = 0x0 (gdb) p/x env->psret $6 = 0x0 (gdb) quit
Based upon this, it would seem that we shouldn't be invoking the data access exception if traps have been globally disabled. Blue, what do you make of the following patch?
diff --git a/target-sparc/op_helper.c b/target-sparc/op_helper.c index be3c1e0..d3a9f28 100644 --- a/target-sparc/op_helper.c +++ b/target-sparc/op_helper.c @@ -4258,7 +4258,7 @@ void do_unassigned_access(target_phys_addr_t addr, int is_write, int is_exec, env->mmuregs[3] |= 1; }
- if ((env->mmuregs[0] & MMU_E) && !(env->mmuregs[0] & MMU_NF)) {
- if ((env->mmuregs[0] & MMU_E) && !(env->mmuregs[0] & MMU_NF) &&
(env->psret)) { if (is_exec) raise_exception(TT_CODE_ACCESS); else
OBP works without this hack.