On 10/19/2013 07:55 AM, Scott Wood wrote:
On Thu, 2013-06-20 at 18:28 +0800, Tiejun Chen wrote:
We always alloc critical/machine/debug check exceptions. This is
different from the normal exception. So we should load these exception
stack properly like we did for booke.

Signed-off-by: Tiejun Chen <tiejun.c...@windriver.com>
---
  arch/powerpc/kernel/exceptions-64e.S |   49 +++++++++++++++++++++++++++++++---
  1 file changed, 46 insertions(+), 3 deletions(-)

diff --git a/arch/powerpc/kernel/exceptions-64e.S 
b/arch/powerpc/kernel/exceptions-64e.S
index 4b23119..4d8e57f 100644
--- a/arch/powerpc/kernel/exceptions-64e.S
+++ b/arch/powerpc/kernel/exceptions-64e.S
@@ -36,6 +36,37 @@
   */
  #define       SPECIAL_EXC_FRAME_SIZE  INT_FRAME_SIZE

+/* only on book3e */
+#define DBG_STACK_BASE         dbgirq_ctx
+#define MC_STACK_BASE          mcheckirq_ctx
+#define CRIT_STACK_BASE                critirq_ctx
+
+#ifdef CONFIG_RELOCATABLE
+#define LOAD_STACK_BASE(reg, level)                    \
+       tovirt(r2,r2);                                  \
+       LOAD_REG_ADDR(reg, level##_STACK_BASE);

Where does r2 come from here, where does it get used, and why do we need
tovirt() on book3e?


As I remember this should be covered when we boot that capture kernel in kexec/kdump case.

Now this is also gone away after move forward the c code.

Thanks,

Tiejun

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Reply via email to