lkml.org 
[lkml]   [2019]   [Nov]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH v3 15/15] powerpc/32s: Activate CONFIG_VMAP_STACK
Michael Ellerman <mpe@ellerman.id.au> a écrit :

> Christophe Leroy <christophe.leroy@c-s.fr> 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@c-s.fr>
>> ---
>> 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




\
 
 \ /
  Last update: 2019-11-20 08:40    [W:0.114 / U:0.508 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site