Received: by 2002:a05:6a10:a0d1:0:0:0:0 with SMTP id j17csp2889119pxa; Tue, 18 Aug 2020 00:08:57 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzZWh065T3jLIdRx4kKKqgyuRl3WywHUJJ43LVO8jK7jX6Yrzm/CplHcDTKcFIjUs3YqAbu X-Received: by 2002:aa7:d607:: with SMTP id c7mr18314912edr.184.1597734537666; Tue, 18 Aug 2020 00:08:57 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1597734537; cv=none; d=google.com; s=arc-20160816; b=Zu4CepvCT6nW/xPjLYnhp7WqK0GD3jXt6n9oVtozQbPP584xPCaQIAAXEHdiLWSCSg 0H19SMOlqOSXM6JWAKxPAZlpdU8hEceX2KCNedHv4GD3obV2HXBYf9kAqO4lG6SokN5p z9PnA465zwrBjRmhXKchT+M/1ic4b2xbxxXBXC1RRFg5tekUudZvq/we3tFG9YLCU3/A N6iB+4P+NFFgmZVL4wQOw6bKFWeGxPVKAuIrfV9y4kqB04dzcrO6hFqRXHgRb9EoaG34 ziCOpCF+S9l1QqVwdCnxp6ehbLBRbLNwl2u7wj05m5C64a2Q9qGhRJ2haKihBNT9BSfv sD7g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:in-reply-to :mime-version:user-agent:date:message-id:from:cc:references:to :subject; bh=CWNzMe+GWUqjJ8fjhYgWSsvb/g29dbchoKg3oNw9ro4=; b=V43xOhkqb8hYSkBGt14bUZDs8barcAssjq/AAJVXkxSAtxhWEQ7ndaYjf3a8a5j7/0 Wz4DQmHKRb4GZ3jp3G8ghdSyPbiTakibV6yoT31afEKLHcnMMDhnnJgStMqJkuMaMBas v/UybFJhF4y65Qj2IePvlmSI5YnlR/wug9zNoE2b3OPXwGrgnRiSE9QADuQkDBBxKPHy kjJPIuO65/DQ1tnaxLTQ6Z877MtSPwkdo0F3Iijr3gMdLLmkPhuPCxOLXWemfN+tPA3K 3u8S9N44g7b7i+EwtMR3RZsB6Yz+i+aD85P82+MumECpR5BO+NN6BDYY20hV6RV8GT6a ojBQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id b12si12661735ejg.578.2020.08.18.00.08.34; Tue, 18 Aug 2020 00:08:57 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726582AbgHRHHX (ORCPT + 99 others); Tue, 18 Aug 2020 03:07:23 -0400 Received: from szxga07-in.huawei.com ([45.249.212.35]:47358 "EHLO huawei.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726043AbgHRHHW (ORCPT ); Tue, 18 Aug 2020 03:07:22 -0400 Received: from DGGEMS414-HUB.china.huawei.com (unknown [172.30.72.60]) by Forcepoint Email with ESMTP id 44F63BCD2F157C503327; Tue, 18 Aug 2020 15:07:14 +0800 (CST) Received: from [127.0.0.1] (10.174.176.220) by DGGEMS414-HUB.china.huawei.com (10.3.19.214) with Microsoft SMTP Server id 14.3.487.0; Tue, 18 Aug 2020 15:07:05 +0800 Subject: Re: [PATCH v11 5/5] kdump: update Documentation about crashkernel To: Dave Young References: <20200801130856.86625-1-chenzhou10@huawei.com> <20200801130856.86625-6-chenzhou10@huawei.com> <20200808100239.GB60590@dhcp-128-65.nay.redhat.com> <96d0da23-d484-7f66-1680-07b4b5984831@huawei.com> <20200810060355.GB6988@dhcp-128-65.nay.redhat.com> CC: , , , , , , , , , , , , , , , , , , , , , From: chenzhou Message-ID: <2e6aebf9-3765-5d8c-933c-698442db1d52@huawei.com> Date: Tue, 18 Aug 2020 15:07:04 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: <20200810060355.GB6988@dhcp-128-65.nay.redhat.com> Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 7bit X-Originating-IP: [10.174.176.220] X-CFilter-Loop: Reflected Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2020/8/10 14:03, Dave Young wrote: > Hi, > >>> Previously I remember we talked about to use similar logic as X86, but I >>> remember you mentioned on some arm64 platform there could be no low >>> memory at all. Is this not a problem now for the fallback? Just be >>> curious, thanks for the update, for the common part looks good. >> Hi Dave, >> >> Did you mean this discuss: https://lkml.org/lkml/2019/12/27/122? > I meant about this reply instead :) > https://lkml.org/lkml/2020/1/16/616 Hi Dave, Sorry for not repley in time, I was on holiday last week. The platform James mentioned may exist for which have no devices and need no low memory. For our arm64 server platform, there are some devices and need low memory. I got it. For the platform with no low memory, reserving crashkernel will always fail. How about like this: diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c index a8e34d97a894..4df18c7ea438 100644 --- a/arch/arm64/mm/init.c +++ b/arch/arm64/mm/init.c @@ -147,7 +147,7 @@ static void __init reserve_crashkernel(void) } memblock_reserve(crash_base, crash_size); - if (crash_base >= CRASH_ADDR_LOW_MAX) { + if (memstart_addr < CRASH_ADDR_LOW_MAX && crash_base >= CRASH_ADDR_LOW_MAX) { const char *rename = "Crash kernel (low)"; if (reserve_crashkernel_low()) { Thanks, Chen Zhou > > Thanks > Dave > > > . >