From: Ralf Baechle <ralf@linux-mips.org>
To: atul srivastava <atulsrivastava9@rediffmail.com>
Cc: linux-mips@linux-mips.org
Subject: Re: hazards during DO_FAULT macro..
Date: Wed, 4 Dec 2002 15:14:16 +0100 [thread overview]
Message-ID: <20021204151416.A31089@linux-mips.org> (raw)
In-Reply-To: <20021204101741.8326.qmail@webmail24.rediffmail.com>; from atulsrivastava9@rediffmail.com on Wed, Dec 04, 2002 at 10:17:41AM -0000
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
next prev parent reply other threads:[~2002-12-04 14:14 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-12-04 10:17 hazards during DO_FAULT macro atul srivastava
2002-12-04 14:14 ` Ralf Baechle [this message]
-- strict thread matches above, loose matches on Subject: below --
2002-12-04 10:18 atul srivastava
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20021204151416.A31089@linux-mips.org \
--to=ralf@linux-mips.org \
--cc=atulsrivastava9@rediffmail.com \
--cc=linux-mips@linux-mips.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.