Message ID | 20240301203023.2197451-1-jsavitz@redhat.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel+bounces-89090-ouuuleilei=gmail.com@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:7301:fa17:b0:10a:f01:a869 with SMTP id ju23csp138864dyc; Fri, 1 Mar 2024 12:31:51 -0800 (PST) X-Forwarded-Encrypted: i=3; AJvYcCWKcfkDg5Wy8seaNjmquSf4QuMXnfCmz0H8micuB3eLmuq+7eZEYX0NzrI/shQ5ZGl/iYNtN5CbnSWXEB6E1w+yiIaeyA== X-Google-Smtp-Source: AGHT+IE6P1xNgnRp3Fi8tJoMuy/SRK/w/6UYechV2UbLR6yIgXYaE89p5Kymhpo3fZGr87wDPaN+ X-Received: by 2002:a0c:aa17:0:b0:68f:d31c:aceb with SMTP id d23-20020a0caa17000000b0068fd31cacebmr2528621qvb.34.1709325110999; Fri, 01 Mar 2024 12:31:50 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1709325110; cv=pass; d=google.com; s=arc-20160816; b=tu8IgB23voxtyWqdYqcTAS7soqNqt9hh80Fi0N41kTlcSnWjj8CR6wV2cqi0Qb+mFV juRS3Yehi1fHAzJur/68sjC/TU1cgzMoPkVP0/NwkwE9sw3StQr5DkKn5y20BbLgQLIk pWUywju63n/waBmzPEU11ErxmWpuOL0CdtX3wdGC7U8Rkn8mjzCDxPUQJc42G9MvaSCb ID2AtvfqovS+7cbzrZ43ZwNNBB2rmxDd7JDZK2Z+LTejuLgtv19uMs/+3RvIFf7x9Kjz x+bZsC1q7Zh2EEMWwjiD+LoR6VhNLWKUa3UsDt1oUvgbkjDX5c5JS+von7eLr3mdH8EC EDmg== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:message-id:date:subject:cc:to :from:dkim-signature; bh=p4HV6m6g6G800ZFnvQF0dUMRRFs2reQboirIXeVEjws=; fh=+07qlRN+Fpthi6WvcrtsBb2fp0Nx6nS6eGXa8kvijZ4=; b=V/INxsER2h5EfrihfJiljqOwojf3XtZYwGhh/oDFtEO4NqSCRrSKG0PINWGd9LW0pH d/1kUCi1XZtxkv1sxsyxnrWQz0+KO1B2/qKrrV6iKvYCVf7kKRhOdV6VjAneiWpOFR4a 8BdNx+W7KTn5zog/XLy4nBbbmmCDqUvdtJyOZtzouaxvqLcJMI6CDlRRvjsHjr62zZ4g 3GssGRlM7vGQnqQGNk0CXO49PqXff0+lz2SVNsAL6z4k4VQse2nYK0TKkCnmriIyUmtE ESgCEWvBL5Cn2Pkcxll/+v1QGQTFL0zzUMGLfHFTrnacWz9GWEq0pB6teTn71sUbPmB5 5L1A==; dara=google.com ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=FPc3Av9j; arc=pass (i=1 spf=pass spfdomain=redhat.com dkim=pass dkdomain=redhat.com dmarc=pass fromdomain=redhat.com); spf=pass (google.com: domain of linux-kernel+bounces-89090-ouuuleilei=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-89090-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: from ny.mirrors.kernel.org (ny.mirrors.kernel.org. [2604:1380:45d1:ec00::1]) by mx.google.com with ESMTPS id 4-20020a0562140d0400b0068f59455cf3si4230623qvh.606.2024.03.01.12.31.50 for <ouuuleilei@gmail.com> (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 01 Mar 2024 12:31:50 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-89090-ouuuleilei=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) client-ip=2604:1380:45d1:ec00::1; Authentication-Results: mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=FPc3Av9j; arc=pass (i=1 spf=pass spfdomain=redhat.com dkim=pass dkdomain=redhat.com dmarc=pass fromdomain=redhat.com); spf=pass (google.com: domain of linux-kernel+bounces-89090-ouuuleilei=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-89090-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ny.mirrors.kernel.org (Postfix) with ESMTPS id 4CE341C255D6 for <ouuuleilei@gmail.com>; Fri, 1 Mar 2024 20:30:48 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 20AE839FC4; Fri, 1 Mar 2024 20:30:37 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="FPc3Av9j" Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 7380316FF2A for <linux-kernel@vger.kernel.org>; Fri, 1 Mar 2024 20:30:32 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.133.124 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1709325034; cv=none; b=QgX1tiS6fU6MKzqkKSvlGM5nBM0oDG30jpn45hh9hZ1p8kqBk1S4uKY7q9KgrdbaaIEDmYjkZ3frPbQjmzjt0xg+jOki69Fwtm+mM34wLAxNYeYBV/GdcUALvg2goxpFHAZwSpOv7GxwLavYNBjaFClqwo0IkklLkb/PUDcAyFA= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1709325034; c=relaxed/simple; bh=t7pqRF9fRBz2eiE5gjDIRduy9WZfkjtR+VuQSDyGcR4=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=K7grqdh/DRk7wpYn/DyUSM3+e84lg6f0NON7uk4ac6BVW3fYkAtcz9dVDpxWdcKnHSSvzoavXwImO38oyDiSvAN5iURUDiexyiOdkHve8lWAhziZkmKGV8Do7GrZmMO80VUwX1c3q4HXIQN6OiLLHbE5+J4CDStP+wosGxwr84k= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=FPc3Av9j; arc=none smtp.client-ip=170.10.133.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1709325031; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding; bh=p4HV6m6g6G800ZFnvQF0dUMRRFs2reQboirIXeVEjws=; b=FPc3Av9j5oJdP3o7ep7UdMPJMXRRGGJXFPjsqAfxqNY5t7eJEHdn9OYyI0OZ4asI76Nk2p +IsxhCUilNZwzrg1zq/YkMG2P7KKojeQ2I+kzPltycqQHAFyFl47H2P0IxTIzqt0jL4MOI ObWEfOvhvFYrI7CJM43VcwVsUBm5pC0= Received: from mimecast-mx02.redhat.com (mx-ext.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-556-6Y1hDfuoONGk5m_HhEMYUQ-1; Fri, 01 Mar 2024 15:30:28 -0500 X-MC-Unique: 6Y1hDfuoONGk5m_HhEMYUQ-1 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.rdu2.redhat.com [10.11.54.5]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 320F0380406D; Fri, 1 Mar 2024 20:30:27 +0000 (UTC) Received: from fedora.redhat.com (unknown [10.22.8.150]) by smtp.corp.redhat.com (Postfix) with ESMTP id EC07A39D6D; Fri, 1 Mar 2024 20:30:25 +0000 (UTC) From: Joel Savitz <jsavitz@redhat.com> To: linux-kernel@vger.kernel.org Cc: Joel Savitz <jsavitz@redhat.com>, Michael Ellerman <mpe@ellerman.id.au>, Nicholas Piggin <npiggin@gmail.com>, Christophe Leroy <christophe.leroy@csgroup.eu>, "Aneesh Kumar K.V" <aneesh.kumar@kernel.org>, "Naveen N. Rao" <naveen.n.rao@linux.ibm.com>, Benjamin Gray <bgray@linux.ibm.com>, Paul Mackerras <paulus@ozlabs.org>, linuxppc-dev@lists.ozlabs.org, Gonzalo Siero <gsierohu@redhat.com> Subject: [PATCH] powerpc: align memory_limit to 16MB in early_parse_mem Date: Fri, 1 Mar 2024 15:30:23 -0500 Message-ID: <20240301203023.2197451-1-jsavitz@redhat.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: <linux-kernel.vger.kernel.org> List-Subscribe: <mailto:linux-kernel+subscribe@vger.kernel.org> List-Unsubscribe: <mailto:linux-kernel+unsubscribe@vger.kernel.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 3.4.1 on 10.11.54.5 X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1792357287467161644 X-GMAIL-MSGID: 1792357287467161644 |
Series |
powerpc: align memory_limit to 16MB in early_parse_mem
|
|
Commit Message
Joel Savitz
March 1, 2024, 8:30 p.m. UTC
On 64-bit powerpc, usage of a non-16MB-aligned value for the mem= kernel cmdline parameter results in a system hang at boot. For example, using 'mem=4198400K' will always reproduce this issue. This patch fixes the problem by aligning any argument to mem= to 16MB corresponding with the large page size on powerpc. Fixes: 2babf5c2ec2f ("[PATCH] powerpc: Unify mem= handling") Co-developed-by: Gonzalo Siero <gsierohu@redhat.com> Signed-off-by: Gonzalo Siero <gsierohu@redhat.com> Signed-off-by: Joel Savitz <jsavitz@redhat.com> --- arch/powerpc/kernel/prom.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-)
Comments
Hi Joel, Joel Savitz <jsavitz@redhat.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. > For example, using 'mem=4198400K' will always reproduce this issue. > > This patch fixes the problem by aligning any argument to mem= to 16MB > corresponding with the large page size on powerpc. The large page size depends on the MMU, with Radix it's 2MB or 1GB. So depending on what's happening 16MB may not be enough. What system are you testing on? cheers > Fixes: 2babf5c2ec2f ("[PATCH] powerpc: Unify mem= handling") > Co-developed-by: Gonzalo Siero <gsierohu@redhat.com> > Signed-off-by: Gonzalo Siero <gsierohu@redhat.com> > Signed-off-by: Joel Savitz <jsavitz@redhat.com> > --- > arch/powerpc/kernel/prom.c | 6 +++++- > 1 file changed, 5 insertions(+), 1 deletion(-) > > diff --git a/arch/powerpc/kernel/prom.c b/arch/powerpc/kernel/prom.c > index 0b5878c3125b..8cd3e2445d8a 100644 > --- a/arch/powerpc/kernel/prom.c > +++ b/arch/powerpc/kernel/prom.c > @@ -82,8 +82,12 @@ static int __init early_parse_mem(char *p) > { > if (!p) > return 1; > - > +#ifdef CONFIG_PPC64 > + /* Align to 16 MB == size of ppc64 large page */ > + memory_limit = ALIGN(memparse(p, &p), 0x1000000); > +#else > memory_limit = PAGE_ALIGN(memparse(p, &p)); > +#endif > DBG("memory limit = 0x%llx\n", memory_limit); > > return 0; > -- > 2.43.0
On Fri, Mar 1, 2024 at 6:23 PM Michael Ellerman <mpe@ellerman.id.au> wrote: > > Hi Joel, > > Joel Savitz <jsavitz@redhat.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@30000000 Preparing to boot Linux version 6.8.0-rc6.memNOfix-00120-g87adedeba51a (root@ibm-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@30000003/disk@8100000000000000,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 ... > > > For example, using 'mem=4198400K' will always reproduce this issue. > > > > This patch fixes the problem by aligning any argument to mem= to 16MB > > corresponding with the large page size on powerpc. > > The large page size depends on the MMU, with Radix it's 2MB or 1GB. So > depending on what's happening 16MB may not be enough. > > What system are you testing on? I'm running a virtual system in PowerVM on an IBM Z mainframe, 8375-42A model. Best, Joel Savitz > > cheers > > > Fixes: 2babf5c2ec2f ("[PATCH] powerpc: Unify mem= handling") > > Co-developed-by: Gonzalo Siero <gsierohu@redhat.com> > > Signed-off-by: Gonzalo Siero <gsierohu@redhat.com> > > Signed-off-by: Joel Savitz <jsavitz@redhat.com> > > --- > > arch/powerpc/kernel/prom.c | 6 +++++- > > 1 file changed, 5 insertions(+), 1 deletion(-) > > > > diff --git a/arch/powerpc/kernel/prom.c b/arch/powerpc/kernel/prom.c > > index 0b5878c3125b..8cd3e2445d8a 100644 > > --- a/arch/powerpc/kernel/prom.c > > +++ b/arch/powerpc/kernel/prom.c > > @@ -82,8 +82,12 @@ static int __init early_parse_mem(char *p) > > { > > if (!p) > > return 1; > > - > > +#ifdef CONFIG_PPC64 > > + /* Align to 16 MB == size of ppc64 large page */ > > + memory_limit = ALIGN(memparse(p, &p), 0x1000000); > > +#else > > memory_limit = PAGE_ALIGN(memparse(p, &p)); > > +#endif > > DBG("memory limit = 0x%llx\n", memory_limit); > > > > return 0; > > -- > > 2.43.0 >
On 3/2/24 4:53 AM, Michael Ellerman wrote: > Hi Joel, > > Joel Savitz <jsavitz@redhat.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. > >> For example, using 'mem=4198400K' will always reproduce this issue. >> >> This patch fixes the problem by aligning any argument to mem= to 16MB >> corresponding with the large page size on powerpc. > > The large page size depends on the MMU, with Radix it's 2MB or 1GB. So > depending on what's happening 16MB may not be enough. > > What system are you testing on? > htab_bolt_mapping should have aligned things to a lower value that is 16MB aligned. /* Carefully map only the possible range */ vaddr = ALIGN(vstart, step); paddr = ALIGN(pstart, step); vend = ALIGN_DOWN(vend, step); -aneesh
diff --git a/arch/powerpc/kernel/prom.c b/arch/powerpc/kernel/prom.c index 0b5878c3125b..8cd3e2445d8a 100644 --- a/arch/powerpc/kernel/prom.c +++ b/arch/powerpc/kernel/prom.c @@ -82,8 +82,12 @@ static int __init early_parse_mem(char *p) { if (!p) return 1; - +#ifdef CONFIG_PPC64 + /* Align to 16 MB == size of ppc64 large page */ + memory_limit = ALIGN(memparse(p, &p), 0x1000000); +#else memory_limit = PAGE_ALIGN(memparse(p, &p)); +#endif DBG("memory limit = 0x%llx\n", memory_limit); return 0;