[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87zfv9m5og.fsf@mail.lhotse>
Date: Fri, 08 Mar 2024 20:30:39 +1100
From: Michael Ellerman <mpe@...erman.id.au>
To: Joel Savitz <jsavitz@...hat.com>
Cc: linux-kernel@...r.kernel.org, Nicholas Piggin <npiggin@...il.com>,
Christophe Leroy <christophe.leroy@...roup.eu>, "Aneesh Kumar K.V"
<aneesh.kumar@...nel.org>, "Naveen N. Rao" <naveen.n.rao@...ux.ibm.com>,
Benjamin Gray <bgray@...ux.ibm.com>, Paul Mackerras <paulus@...abs.org>,
linuxppc-dev@...ts.ozlabs.org, Gonzalo Siero <gsierohu@...hat.com>
Subject: Re: [PATCH] powerpc: align memory_limit to 16MB in early_parse_mem
Joel Savitz <jsavitz@...hat.com> writes:
> On Fri, Mar 1, 2024 at 6:23 PM Michael Ellerman <mpe@...erman.id.au> wrote:
>> Joel Savitz <jsavitz@...hat.com> writes:
>> > On 64-bit powerpc, usage of a non-16MB-aligned value for the mem= kernel
>> > cmdline parameter results in a system hang at boot.
>>
>> Can you give us any more details on that? It might be a bug we can fix.
>
> The console freezes after the following output:
>
> Booting a command list
>
> OF stdout device is: /vdevice/vty@...00000
> Preparing to boot Linux version 6.8.0-rc6.memNOfix-00120-g87adedeba51a
> (root@...-p9z-26-lp11.virt.pnr.lab.eng.rdu2.redhat.com) (gcc (GCC)
> 11.4.1 20231218 (Red Hat 11.4.1-3), GNU ld version 2.35.2-43.el9) #3
> SMP Fri Mar 1 10:45:45 EST 2024
> Detected machine type: 0000000000000101
> command line: BOOT_IMAGE=(ieee1275//vdevice/v-scsi@...00003/disk@...0000000000000,msdos2)/vmlinuz-6.8.0-rc6.memNOfix-00120-g87adedeba51a
> root=/dev/mapper/rhel_ibm--p9z--26--lp11-root ro
> crashkernel=2G-4G:384M,4G-16G:512M,16G-64G:1G,64G-128G:2G,128G-:4G
> rd.lvm.lv=rhel_ibm-p9z-26-lp11/root
> rd.lvm.lv=rhel_ibm-p9z-26-lp11/swap mem=4198400K
> Max number of cores passed to firmware: 256 (NR_CPUS = 2048)
> Calling ibm,client-architecture-support... done
> Ignoring mem=0000000101000000 >= ram_top.
> memory layout at init:
> memory_limit : 0000000000000000 (16 MB aligned)
> alloc_bottom : 00000000114f0000
> alloc_top : 0000000020000000
> alloc_top_hi : 0000000020000000
> rmo_top : 0000000020000000
> ram_top : 0000000020000000
> instantiating rtas at 0x000000001ecb0000... done
> prom_hold_cpus: skipped
> copying OF device tree...
> Building dt strings...
> Building dt structure...
> Device tree strings 0x0000000011500000 -> 0x00000000115017b7
> Device tree struct 0x0000000011510000 -> 0x0000000011520000
> Quiescing Open Firmware ...
> Booting Linux via __start() @ 0x000000000a6e0000 ...
Thanks.
I haven't been able to reproduce this unfortunately, and I don't see the
bug. As Aneesh pointed out the code should be aligning later anyway.
Can you build a kernel with CONFIG_PPC_EARLY_DEBUG_LPAR=y and boot it
without the patch? That should hopefully give you some more output.
cheers
Powered by blists - more mailing lists