Re: [PATCH v3 15/15] powerpc/32s: Activate CONFIG_VMAP_STACK

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Michael Ellerman <mpe@xxxxxxxxxxxxxx> a écrit :

Christophe Leroy <christophe.leroy@xxxxxx> writes:
A few changes to retrieve DAR and DSISR from struct regs
instead of retrieving them directly, as they may have
changed due to a TLB miss.

Also modifies hash_page() and friends to work with virtual
data addresses instead of physical ones.

Signed-off-by: Christophe Leroy <christophe.leroy@xxxxxx>
---
 arch/powerpc/kernel/entry_32.S         |  4 +++
 arch/powerpc/kernel/head_32.S          | 19 +++++++++++---
 arch/powerpc/kernel/head_32.h          |  4 ++-
arch/powerpc/mm/book3s32/hash_low.S | 46 +++++++++++++++++++++-------------
 arch/powerpc/mm/book3s32/mmu.c         |  9 +++++--
 arch/powerpc/platforms/Kconfig.cputype |  2 ++
 6 files changed, 61 insertions(+), 23 deletions(-)

This is faulting with qemu mac99 model:

  Key type id_resolver registered
  Key type id_legacy registered
  BUG: Unable to handle kernel data access on read at 0x2f0db684
  Faulting instruction address: 0x00004130
  Oops: Kernel access of bad area, sig: 11 [#1]
  BE PAGE_SIZE=4K MMU=Hash PowerMac
  Modules linked in:
  CPU: 0 PID: 65 Comm: modprobe Not tainted 5.4.0-rc2-gcc49+ #63
  NIP:  00004130 LR: 000008c8 CTR: b7eb86e0
  REGS: f106de80 TRAP: 0300   Not tainted  (5.4.0-rc2-gcc49+)
  MSR:  00003012 <FP,ME,DR,RI>  CR: 4106df38  XER: 20000000
  DAR: 2f0db684 DSISR: 40000000
GPR00: b7ec5d64 f106df38 00000000 bf988a70 00000000 2f0db540 b7ec3620 bf988d38 GPR08: 10000880 0000d032 72656773 f106df38 b7ed10ec 00000000 b7ed3d38 b7ee8900 GPR16: bf988d10 00000001 00000000 bf988d10 b7ec3620 bf988d50 b7ee76ec b7ee7320 GPR24: 10000878 00000000 b7ee8900 00000000 10029f00 10000879 b7ee7ff4 bf988d30
  NIP [00004130] 0x4130
  LR [000008c8] 0x8c8
  Call Trace:
  [f106df38] [c0016224] ret_from_syscall+0x0/0x34 (unreliable)
  --- interrupt: c01 at 0xb7ed0f50
      LR = 0xb7ec5d64
  Instruction dump:
  db8300e0 XXXXXXXX XXXXXXXX XXXXXXXX fc00048e XXXXXXXX XXXXXXXX XXXXXXXX
  60a52000 XXXXXXXX XXXXXXXX XXXXXXXX 80850144 XXXXXXXX XXXXXXXX XXXXXXXX
  ---[ end trace 265da51c6d8b86c5 ]---


I think I'll have to drop this series for now.

What about taking the series up to patch 13 ?

I think the problem is related to hash handling as it is working well on the 8xx (and on the 83xx which is a nohash book3s). I'll look at book3s hash next week.

Christophe









[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux