On Wed, Dec 04, 2002 at 10:17:41AM -0000, atul srivastava wrote: > macro Do_FAULt(write) expands like.. > > #define DO_FAULT(write) \ > .set noreorder; \ > .set noat; \ > SAVE_ALL; \ > STI; \ > nop; \ Unnecessary nop. > .set at; \ > move a0, sp; \ > jal do_page_fault; \ > li a1, write; \ > nop; \ Unnecessary nop. > j ret_from_sys_call; \ This is ret_from_exception since about 14 months. > nop; \ > .set noat; > > this macro is called by handle_tlbx() routines. > when I tracked this problem and i observed my pt_regs address > looked o.k. and apparently right till after STI; \ and just before > instruction mfc0 a2, CP0_BADVADDR; > this i found by putting following instructions, > > move a0,sp; \ > jal show_regs; \ > nop; \ > > later it jumps to do_page_fault() ,and pt_regs address there > equals unexpectedly to envp_init and from thereon everythings goes > wrong.. This would means something like your user process was running with c0_status.cu0 = 1 which is forbidden. If that happens the kernel wouldn't load a new stack pointer on kerne entry. > I also tried with negating STI; \ , but same result. This would means something like your user process was running with c0_status.cu0 = 1 which is forbidden. If that happens the kernel wouldn't load a new stack pointer on kerne entry. > 8001e6ac: 01094025 or $t0,$t0,$t1 STI macro code , though i The function there has doesn't have STI but KMODE since almost half a year. Time to upgrade. And our code never had the mfc0 from the badvaddr register after the STI / KMODE, so it seems you kernel tree is a) antique b) seems hacked beyond recognition. Moving the mfc0 behind the sti would be valid as long as we know there's always a hazard of at least one cycle before interrupts get activated. That was true for the initially supported processors like R4000 (3 cycles) or R4600 (1 cycle) but no longer for modern processors. Ralf
