linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
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

  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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).