From: "Jonathan Neuschäfer" <j.neuschaefer@gmx.net>
To: Christophe Leroy <christophe.leroy@c-s.fr>
Cc: "Jonathan Neuschäfer" <j.neuschaefer@gmx.net>,
linux-kernel@vger.kernel.org, "Paul Mackerras" <paulus@samba.org>,
linuxppc-dev@lists.ozlabs.org
Subject: Re: [PATCH v2 00/15] powerpc/32s: Use BATs/LTLBs for STRICT_KERNEL_RWX
Date: Thu, 17 Jan 2019 00:48:16 +0100 [thread overview]
Message-ID: <20190116234816.GG22334@latitude> (raw)
In-Reply-To: <5051e5cb-89ea-b857-1288-1ac6bfe67872@c-s.fr>
On Wed, Jan 16, 2019 at 02:34:53PM +0100, Christophe Leroy wrote:
> Le 16/01/2019 à 14:16, Jonathan Neuschäfer a écrit :
> > On Wed, Jan 16, 2019 at 07:55:29AM +0100, Christophe Leroy wrote:
> > > Le 16/01/2019 à 01:35, Jonathan Neuschäfer a écrit :
> > > > Thinning the kernel down a bit actually makes it boot again. Ooops...!
> > > > Maybe enabling CONFIG_STRICT_KERNEL_RWX has made it just large enough to
> > > > fail the hash table allocation, but there may have been other factors
> > > > involved (I'm not sure exactly). Sorry for the confusion!
> > >
> > > Ok, that must be the reason. Thanks for testing.
> > >
> > > What about the following modification which maps a second 256Mb BAT, does it
> > > helps ?
> > >
> > >
> > >
> > > diff --git a/arch/powerpc/kernel/head_32.S b/arch/powerpc/kernel/head_32.S
> > > index c2f564690778..ea574596de37 100644
> > > --- a/arch/powerpc/kernel/head_32.S
> > > +++ b/arch/powerpc/kernel/head_32.S
> > > @@ -1160,6 +1160,14 @@ initial_bats:
> > > mtspr SPRN_DBAT0U,r11 /* bit in upper BAT register */
> > > mtspr SPRN_IBAT0L,r8
> > > mtspr SPRN_IBAT0U,r11
> > > +#ifdef CONFIG_WII
> > > + addis r11,r11,0x10000000@h
> > > + addis r8,r8,0x10000000@h
> > > + mtspr SPRN_DBAT2L,r8
> > > + mtspr SPRN_DBAT2U,r11
> > > + mtspr SPRN_IBAT2L,r8
> > > + mtspr SPRN_IBAT2U,r11
> > > +#endif
> > > isync
> > > blr
> > >
> > > diff --git a/arch/powerpc/mm/ppc_mmu_32.c b/arch/powerpc/mm/ppc_mmu_32.c
> > > index 3f4193201ee7..a334fd5210a8 100644
> > > --- a/arch/powerpc/mm/ppc_mmu_32.c
> > > +++ b/arch/powerpc/mm/ppc_mmu_32.c
> > > @@ -259,6 +259,8 @@ void setup_initial_memory_limit(phys_addr_t
> > > first_memblock_base,
> > > /* 601 can only access 16MB at the moment */
> > > if (PVR_VER(mfspr(SPRN_PVR)) == 1)
> > > memblock_set_current_limit(min_t(u64, first_memblock_size, 0x01000000));
> > > + else if (IS_ENABLED(CONFIG_WII))
> > > + memblock_set_current_limit(min_t(u64, first_memblock_size, 0x20000000));
> > > else /* Anything else has 256M mapped */
> > > memblock_set_current_limit(min_t(u64, first_memblock_size, 0x10000000));
> > > }
> >
> > I haven't tested it, but this patch won't be enough, because we're only
> > looking at the first memblock, and the additional memory in the Wii
> > (MEM2) is the second memblock.
> >
>
> Yes right.
>
>
> Would the following work instead ?
>
> memblock_set_current_limit(0x20000000);
With the config at https://gist.githubusercontent.com/neuschaefer/12ccc87ff8aeff543fad558e8742cd2b/raw/d49d321709cac364779e6893bbd91ff5a80bcb03/config
it still doesn't boot, but with a different error:
top of MEM2 @ 13F00000
zImage starting: loaded at 0x01000000 (sp: 0x0178afa0)
Allocating 0x166b2c8 bytes for kernel...
Decompressing (0x00000000 <- 0x01011000:0x01788799)...
Done! Decompressed 0xf421f4 bytes
Linux/PowerPC load: root=/dev/mmcblk0p2 rootwait console=usbgecko1
Finalizing device tree... flat tree at 0x178b7a0
[ 0.000000] printk: bootconsole [udbg0] enabled
[ 0.000000] __memblock_find_range_top_down(1000:20000000, 100000:100000, ffffffff, 0)
[ 0.000000] __memblock_find_range_top_down: in loop, 10000000:13f00000
[ 0.000000] Total memory = 319MB; using 1024kB for hash table (at d3e00000)
[ 0.000000] __memblock_find_range_top_down(1000:20000000, 1000:1000, ffffffff, 0)
[ 0.000000] __memblock_find_range_top_down: in loop, 10000000:13e00000
[ 0.000000] __memblock_find_range_top_down(1000:20000000, 1000:1000, ffffffff, 0)
[ 0.000000] __memblock_find_range_top_down: in loop, 10000000:13dff000
[ 0.000000] BUG: Unable to handle kernel data access at 0xc106a434
[ 0.000000] Faulting instruction address: 0xc0071bf4
[ 0.000000] Oops: Kernel access of bad area, sig: 11 [#1]
[ 0.000000] BE PREEMPT
[ 0.000000] Modules linked in:
[ 0.000000] CPU: 0 PID: 0 Comm: swapper Not tainted 5.0.0-rc1-wii-00038-gc34b70d591b6-dirty #1337
[ 0.000000] NIP: c0071bf4 LR: c00727d8 CTR: 00000000
[ 0.000000] REGS: c0f1fd30 TRAP: 0300 Not tainted (5.0.0-rc1-wii-00038-gc34b70d591b6-dirty)
[ 0.000000] MSR: 00001032 <ME,IR,DR,RI> CR: 44002842 XER: 00000000
[ 0.000000] DAR: c106a434 DSISR: 40000000
[ 0.000000] GPR00: c0074a98 c0f1fde0 c0ead4a0 c0ead4a0 c0ead9c8 00000008 00000000 00000000
[ 0.000000] GPR08: 00000003 c106a418 00000258 00000001 24000444 fb43ef5b c0f30000 7561f327
[ 0.000000] GPR16: c0f40000 691cfd11 38afe359 f161e513 00000000 c0ead9c8 00000001 00000000
[ 0.000000] GPR24: 00000000 c0f46288 00000000 c0ead4a0 c0ead9c8 00000008 c0ead4a0 00000100
[ 0.000000] NIP [c0071bf4] mark_lock+0x64/0x858
[ 0.000000] LR [c00727d8] __lock_acquire+0x334/0x1a40
[ 0.000000] Call Trace:
[ 0.000000] [c0f1fe20] [00000006] 0x6
[ 0.000000] [c0f1fed0] [c0074a98] lock_acquire+0x110/0x20c
[ 0.000000] [c0f1ff10] [c085e8cc] _raw_spin_lock+0x44/0x60
[ 0.000000] [c0f1ff30] [c007f220] vprintk_emit+0xa0/0x328
[ 0.000000] [c0f1ff70] [c007fc48] printk+0x5c/0x84
[ 0.000000] [c0f1ffb0] [c0c00854] start_kernel+0x64/0x460
[ 0.000000] [c0f1fff0] [00003438] 0x3438
[ 0.000000] Instruction dump:
[ 0.000000] 41820170 55086cfe 550a083c 7d4a4214 554a1838 3d20c0f4 7d4a4214 39296288
[ 0.000000] 554a1838 3d290012 7d295214 39293f38 <8129001c> 7fe94839 41820028 3bc00001
[ 0.000000] random: get_random_bytes called from print_oops_end_marker+0x34/0x6c with crng_init=0
[ 0.000000] ---[ end trace 0000000000000000 ]---
[ 0.000000]
[ 0.000000] Kernel panic - not syncing: Attempted to kill the idle task!
Not sure what's wrong. It does work with wii_defconfig, though.
I think for now I'm happy without this patch, as it doesn't seem to be
really necessary.
Jonathan
next prev parent reply other threads:[~2019-01-16 23:50 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-01-10 15:11 [PATCH v2 00/15] powerpc/32s: Use BATs/LTLBs for STRICT_KERNEL_RWX Christophe Leroy
2019-01-10 15:11 ` [PATCH v2 01/15] powerpc/mm/32: add base address to mmu_mapin_ram() Christophe Leroy
2019-01-10 15:11 ` [PATCH v2 02/15] powerpc/mm/32s: rework mmu_mapin_ram() Christophe Leroy
2019-01-10 15:11 ` [PATCH v2 03/15] powerpc/mm/32s: use generic mmu_mapin_ram() for all blocks Christophe Leroy
2019-01-10 15:11 ` [PATCH v2 04/15] powerpc/32: always populate page tables for Abatron BDI Christophe Leroy
2019-01-10 15:11 ` [PATCH v2 05/15] powerpc/wii: remove wii_mmu_mapin_mem2() Christophe Leroy
2019-01-10 15:11 ` [PATCH v2 06/15] powerpc/mm/32s: use _PAGE_EXEC in setbat() Christophe Leroy
2019-01-10 15:11 ` [PATCH v2 07/15] powerpc/mm/32s: add setibat() clearibat() and update_bats() Christophe Leroy
2019-01-10 15:11 ` [PATCH v2 08/15] powerpc/32: add helper to write into segment registers Christophe Leroy
2019-01-10 15:11 ` [PATCH v2 09/15] powerpc/mmu: add is_strict_kernel_rwx() helper Christophe Leroy
2019-01-10 15:11 ` [PATCH v2 10/15] powerpc/kconfig: define PAGE_SHIFT inside Kconfig Christophe Leroy
2019-01-10 15:12 ` [PATCH v2 11/15] powerpc/kconfig: define CONFIG_DATA_SHIFT and CONFIG_ETEXT_SHIFT Christophe Leroy
2019-01-10 15:12 ` [PATCH v2 12/15] powerpc/mm/32s: Use BATs for STRICT_KERNEL_RWX Christophe Leroy
2019-01-10 15:12 ` [PATCH v2 13/15] powerpc/kconfig: make _etext and data areas alignment configurable on Book3s 32 Christophe Leroy
2019-01-10 15:12 ` [PATCH v2 14/15] powerpc/8xx: don't disable large TLBs with CONFIG_STRICT_KERNEL_RWX Christophe Leroy
2019-01-10 15:12 ` [PATCH v2 15/15] powerpc/kconfig: make _etext and data areas alignment configurable on 8xx Christophe Leroy
2019-01-13 18:16 ` [PATCH v2 00/15] powerpc/32s: Use BATs/LTLBs for STRICT_KERNEL_RWX Jonathan Neuschäfer
2019-01-13 19:43 ` Christophe Leroy
2019-01-13 21:02 ` Jonathan Neuschäfer
2019-01-14 18:23 ` Christophe Leroy
2019-01-15 0:33 ` Jonathan Neuschäfer
2019-01-15 6:51 ` Christophe Leroy
2019-01-15 10:22 ` Michael Ellerman
2019-01-15 10:57 ` Christophe Leroy
2019-02-20 13:23 ` Michael Ellerman
2019-02-20 15:30 ` Christophe Leroy
2019-01-16 0:35 ` Jonathan Neuschäfer
2019-01-16 6:55 ` Christophe Leroy
2019-01-16 13:16 ` Jonathan Neuschäfer
2019-01-16 13:34 ` Christophe Leroy
2019-01-16 23:48 ` Jonathan Neuschäfer [this message]
2019-01-17 10:14 ` Christophe Leroy
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=20190116234816.GG22334@latitude \
--to=j.neuschaefer@gmx.net \
--cc=christophe.leroy@c-s.fr \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=paulus@samba.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.