From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-13.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 9AD21C63798 for ; Thu, 19 Nov 2020 21:56:55 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 513822222A for ; Thu, 19 Nov 2020 21:56:55 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726497AbgKSV4y (ORCPT ); Thu, 19 Nov 2020 16:56:54 -0500 Received: from youngberry.canonical.com ([91.189.89.112]:55092 "EHLO youngberry.canonical.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726463AbgKSV4y (ORCPT ); Thu, 19 Nov 2020 16:56:54 -0500 Received: from mail-ed1-f71.google.com ([209.85.208.71]) by youngberry.canonical.com with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.86_2) (envelope-from ) id 1kfrv9-0001aS-8N for linux-kernel@vger.kernel.org; Thu, 19 Nov 2020 21:56:51 +0000 Received: by mail-ed1-f71.google.com with SMTP id bc27so2852401edb.18 for ; Thu, 19 Nov 2020 13:56:51 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=lhFyzHKwMpafV6CqL/rG6oJZPrxLkevFP6v3DPlHTjQ=; b=MzEg4cWalB6CgpdxfG792Z0ceiNj56CIP3yuQnNlJGO9olO36DmQk4to/5nYfRrbjQ RTQvvQ3KrLD7l9ocwK1A8TGK71HDBx910hzJVQARrCVAWiv+Jyqlktf4tsxOwSVRY90f O2qdtQQWrBg0+vKGFubY1KC2meSejBy+RjiE+0ptp1dueNGHcncjPJPfA7JxkBVi85HY 3NuwFIiQxvOXHLtgEPiFeWZqDNN7unHMTLxPFA84P4ObBwEJYJOF+kHDich4gC1oDd5B xzfwXhiDRBRo1w7Ip4PJGj9B6TKO9sU5qyb0Jt2F/uEF8Bfyk15HJ8o5GbC7Vv06JdNN vvMg== X-Gm-Message-State: AOAM5306JnycXadBoATKhmzSOlVYNwtzkV/bKJ55g/HrdjINawyVzavI alD54KPARoUfWJq9lcGFQq1ZSAmooX22ZtWMQd2TJ8XtjhcHbH1aBP9ovH7Bl5HuLGHnoei36KJ K14l1hvlE7uFOWBjLLqQrOHoNT/dxjLvj+AegCTq37IXHnjFyUuObRuNzEw== X-Received: by 2002:a17:906:c298:: with SMTP id r24mr12518355ejz.381.1605823010850; Thu, 19 Nov 2020 13:56:50 -0800 (PST) X-Google-Smtp-Source: ABdhPJyeZ68/adrbEJ2QL8FWoGR/7QczQEdL/SJ/roqlAOfSUFE97woxfB9XeYew72aotj7J5ZRFC0uKzMIuINdlucY= X-Received: by 2002:a17:906:c298:: with SMTP id r24mr12518308ejz.381.1605823010561; Thu, 19 Nov 2020 13:56:50 -0800 (PST) MIME-Version: 1.0 References: <20201118232431.21832-1-saeed.mirzamohammadi@oracle.com> In-Reply-To: <20201118232431.21832-1-saeed.mirzamohammadi@oracle.com> From: Guilherme Piccoli Date: Thu, 19 Nov 2020 18:56:14 -0300 Message-ID: Subject: Re: [PATCH 1/1] kernel/crash_core.c - Add crashkernel=auto for x86 and ARM To: Saeed Mirzamohammadi Cc: Geert Uytterhoeven , linux-doc@vger.kernel.org, Catalin Marinas , Bjorn Andersson , "H. Peter Anvin" , Will Deacon , Anson Huang , Jonathan Corbet , x86@kernel.org, Michael Walle , Krzysztof Kozlowski , Ingo Molnar , Dave Young , Vivek Goyal , john.p.donnelly@oracle.com, Arnd Bergmann , Borislav Petkov , Thomas Gleixner , linux-arm-kernel@lists.infradead.org, Baoquan He , "Martin K. Petersen" , Randy Dunlap , kexec mailing list , LKML , "# v4 . 16+" , Li Yang , Miguel Ojeda , Vinod Koul , =?UTF-8?Q?Diego_Elio_Petten=C3=B2?= , Olof Johansson , Shawn Guo , Thadeu Lima de Souza Cascardo , Dann Frazier Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Saeed, thanks for your patch/idea! Comments inline, below. On Wed, Nov 18, 2020 at 8:29 PM Saeed Mirzamohammadi wrote: > > This adds crashkernel=auto feature to configure reserved memory for > vmcore creation to both x86 and ARM platforms based on the total memory > size. > > Cc: stable@vger.kernel.org > Signed-off-by: John Donnelly > Signed-off-by: Saeed Mirzamohammadi > --- > Documentation/admin-guide/kdump/kdump.rst | 5 +++++ > arch/arm64/Kconfig | 26 ++++++++++++++++++++++- > arch/arm64/configs/defconfig | 1 + > arch/x86/Kconfig | 26 ++++++++++++++++++++++- > arch/x86/configs/x86_64_defconfig | 1 + > kernel/crash_core.c | 20 +++++++++++++++-- > 6 files changed, 75 insertions(+), 4 deletions(-) > > diff --git a/Documentation/admin-guide/kdump/kdump.rst b/Documentation/admin-guide/kdump/kdump.rst > index 75a9dd98e76e..f95a2af64f59 100644 > --- a/Documentation/admin-guide/kdump/kdump.rst > +++ b/Documentation/admin-guide/kdump/kdump.rst > @@ -285,7 +285,12 @@ This would mean: > 2) if the RAM size is between 512M and 2G (exclusive), then reserve 64M > 3) if the RAM size is larger than 2G, then reserve 128M > > +Or you can use crashkernel=auto if you have enough memory. The threshold > +is 1G on x86_64 and arm64. If your system memory is less than the threshold, > +crashkernel=auto will not reserve memory. The size changes according to > +the system memory size like below: > > + x86_64/arm64: 1G-64G:128M,64G-1T:256M,1T-:512M As mentioned in the thread, this was tried before and never got merged - I'm not sure the all the reasons, but I speculate that a stronger reason is that it'd likely fail in many cases. I've seen cases of 256G servers that require crashkernel=600M (or more), due to the amount of devices. Also, the minimum nowadays would likely be 96M or more - I'm looping Cascardo and Dann (Debian/Ubuntu maintainers of kdump stuff) so they maybe can jump in with even more examples/considerations. What we've been trying to do in Ubuntu/Debian is using an estimator approach [0] - this is purely userspace and tries to infer the amount of necessary memory a kdump minimal[1] kernel would take. I'm not -1'ing your approach totally, but I think a bit more consideration is needed in the ranges, at least accounting the number of devices of the machine or something like that. Cheers, Guilherme [0] https://salsa.debian.org/debian/makedumpfile/-/merge_requests/7 [1] Minimal as having a reduced initrd + "shrinking" parameters (like nr_cpus=1). From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-13.8 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER, INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id D16C1C6379D for ; Thu, 19 Nov 2020 21:58:43 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 53E3822242 for ; Thu, 19 Nov 2020 21:58:43 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="VTCOkwVn" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 53E3822242 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=canonical.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:To:Subject:Message-ID:Date:From:In-Reply-To: References:MIME-Version:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=Zleu6amTeiGN6bgF8Xw97oErll72slzNfe4mY8YcUI8=; b=VTCOkwVnlPdnNatsL4I/LFvrw spNcJHBihsJB6gltxajdUa5secPhUznvC6w+lGC95n5n2Fqult3ugidbrGDmWQoxz592h84piHvG6 CSbheRUhrfNxBz6JK2uG1ksZNExP0pWxUYYtSsmF8N1RKHvDM6GR881WOoNiWHre0b6QTe87vgdh0 KQ7I+ZEDvdUyakU/CkeKAULlOjJQEB7NGtAKs9Cp+bFOQkb7b5ZHmyWphRgpjyPQhkuxPCxk6nTVq e+oID8YPBwT0VZboFSBC8Lp77NDzI3IbFtZItwmq/Cn+3b9Ehco5kgdgHnmlrZkqe0MYvaCQoNs8d cbtJ28eGQ==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kfrvT-0005Vu-6i; Thu, 19 Nov 2020 21:57:11 +0000 Received: from youngberry.canonical.com ([91.189.89.112]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1kfrvQ-0005VP-MJ for linux-arm-kernel@lists.infradead.org; Thu, 19 Nov 2020 21:57:09 +0000 Received: from mail-ej1-f69.google.com ([209.85.218.69]) by youngberry.canonical.com with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.86_2) (envelope-from ) id 1kfrv9-0001af-Ip for linux-arm-kernel@lists.infradead.org; Thu, 19 Nov 2020 21:56:51 +0000 Received: by mail-ej1-f69.google.com with SMTP id p6so2710270ejj.5 for ; Thu, 19 Nov 2020 13:56:51 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=lhFyzHKwMpafV6CqL/rG6oJZPrxLkevFP6v3DPlHTjQ=; b=Kaj5tAeJ2d9pwFydRzjZwOEu+pUWIM7H+Nln0woaeA8d3Sz1R+GV4hhC0vEO1qyZ8e DxiEz6rdJy+hoBrmpy68bn/X/nK28hGg6LE0l37zILhdVCpYv50kSo6I4xU5KHcxyVYJ WU7lYvoaSu7uI4ZTBG1bEoLbLXHvUFlbrjSosWlVS1hBNdas6FKf7QlNgDFyAWSFiaPq mmwaMxwllCc+r2N8P0EAwco/JuYPTpRGfHSBBwPkQ3bNl2zogdw0fCBYqT/d2VdjRKyQ g8roxDrd1eorjeZLi0R/EH2rv0sdKrvFQyvbHlME7+nNT+5VNQQaim29nSBHeMomKhp4 OLKg== X-Gm-Message-State: AOAM533QIM+SIiDprqhDhqUdnqbnPoue80auLUsY2q+iCuX+aNJ7h8N7 QD+kmcHO7nxURPwAEiMEdFgZ72+/dZLO5ve+fMuzYpD7w9VvtgYqRnJoymj2gy+UZd7j7NnNAyQ UaHc4HzTR984iCR+6XJflmmB6JfJERMt4a92BAerAxz8RQiUSofqMSvTtnGpEEdnrnHLt X-Received: by 2002:a17:906:c298:: with SMTP id r24mr12518324ejz.381.1605823010845; Thu, 19 Nov 2020 13:56:50 -0800 (PST) X-Google-Smtp-Source: ABdhPJyeZ68/adrbEJ2QL8FWoGR/7QczQEdL/SJ/roqlAOfSUFE97woxfB9XeYew72aotj7J5ZRFC0uKzMIuINdlucY= X-Received: by 2002:a17:906:c298:: with SMTP id r24mr12518308ejz.381.1605823010561; Thu, 19 Nov 2020 13:56:50 -0800 (PST) MIME-Version: 1.0 References: <20201118232431.21832-1-saeed.mirzamohammadi@oracle.com> In-Reply-To: <20201118232431.21832-1-saeed.mirzamohammadi@oracle.com> From: Guilherme Piccoli Date: Thu, 19 Nov 2020 18:56:14 -0300 Message-ID: Subject: Re: [PATCH 1/1] kernel/crash_core.c - Add crashkernel=auto for x86 and ARM To: Saeed Mirzamohammadi X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20201119_165708_810732_1D22CF43 X-CRM114-Status: GOOD ( 25.72 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Thadeu Lima de Souza Cascardo , Geert Uytterhoeven , linux-doc@vger.kernel.org, Catalin Marinas , Bjorn Andersson , "H. Peter Anvin" , Will Deacon , Anson Huang , Jonathan Corbet , Dann Frazier , x86@kernel.org, Vinod Koul , Krzysztof Kozlowski , Ingo Molnar , Dave Young , Vivek Goyal , john.p.donnelly@oracle.com, Arnd Bergmann , Borislav Petkov , Thomas Gleixner , linux-arm-kernel@lists.infradead.org, Baoquan He , "Martin K. Petersen" , Randy Dunlap , kexec mailing list , LKML , "# v4 . 16+" , Li Yang , Miguel Ojeda , Michael Walle , =?UTF-8?Q?Diego_Elio_Petten=C3=B2?= , Olof Johansson , Shawn Guo Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org Hi Saeed, thanks for your patch/idea! Comments inline, below. On Wed, Nov 18, 2020 at 8:29 PM Saeed Mirzamohammadi wrote: > > This adds crashkernel=auto feature to configure reserved memory for > vmcore creation to both x86 and ARM platforms based on the total memory > size. > > Cc: stable@vger.kernel.org > Signed-off-by: John Donnelly > Signed-off-by: Saeed Mirzamohammadi > --- > Documentation/admin-guide/kdump/kdump.rst | 5 +++++ > arch/arm64/Kconfig | 26 ++++++++++++++++++++++- > arch/arm64/configs/defconfig | 1 + > arch/x86/Kconfig | 26 ++++++++++++++++++++++- > arch/x86/configs/x86_64_defconfig | 1 + > kernel/crash_core.c | 20 +++++++++++++++-- > 6 files changed, 75 insertions(+), 4 deletions(-) > > diff --git a/Documentation/admin-guide/kdump/kdump.rst b/Documentation/admin-guide/kdump/kdump.rst > index 75a9dd98e76e..f95a2af64f59 100644 > --- a/Documentation/admin-guide/kdump/kdump.rst > +++ b/Documentation/admin-guide/kdump/kdump.rst > @@ -285,7 +285,12 @@ This would mean: > 2) if the RAM size is between 512M and 2G (exclusive), then reserve 64M > 3) if the RAM size is larger than 2G, then reserve 128M > > +Or you can use crashkernel=auto if you have enough memory. The threshold > +is 1G on x86_64 and arm64. If your system memory is less than the threshold, > +crashkernel=auto will not reserve memory. The size changes according to > +the system memory size like below: > > + x86_64/arm64: 1G-64G:128M,64G-1T:256M,1T-:512M As mentioned in the thread, this was tried before and never got merged - I'm not sure the all the reasons, but I speculate that a stronger reason is that it'd likely fail in many cases. I've seen cases of 256G servers that require crashkernel=600M (or more), due to the amount of devices. Also, the minimum nowadays would likely be 96M or more - I'm looping Cascardo and Dann (Debian/Ubuntu maintainers of kdump stuff) so they maybe can jump in with even more examples/considerations. What we've been trying to do in Ubuntu/Debian is using an estimator approach [0] - this is purely userspace and tries to infer the amount of necessary memory a kdump minimal[1] kernel would take. I'm not -1'ing your approach totally, but I think a bit more consideration is needed in the ranges, at least accounting the number of devices of the machine or something like that. Cheers, Guilherme [0] https://salsa.debian.org/debian/makedumpfile/-/merge_requests/7 [1] Minimal as having a reduced initrd + "shrinking" parameters (like nr_cpus=1). _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from youngberry.canonical.com ([91.189.89.112]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1kfrvC-0005Sk-AR for kexec@lists.infradead.org; Thu, 19 Nov 2020 21:56:55 +0000 Received: from mail-ed1-f69.google.com ([209.85.208.69]) by youngberry.canonical.com with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.86_2) (envelope-from ) id 1kfrvA-0001bM-2D for kexec@lists.infradead.org; Thu, 19 Nov 2020 21:56:52 +0000 Received: by mail-ed1-f69.google.com with SMTP id y11so2873914edv.6 for ; Thu, 19 Nov 2020 13:56:52 -0800 (PST) MIME-Version: 1.0 References: <20201118232431.21832-1-saeed.mirzamohammadi@oracle.com> In-Reply-To: <20201118232431.21832-1-saeed.mirzamohammadi@oracle.com> From: Guilherme Piccoli Date: Thu, 19 Nov 2020 18:56:14 -0300 Message-ID: Subject: Re: [PATCH 1/1] kernel/crash_core.c - Add crashkernel=auto for x86 and ARM List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "kexec" Errors-To: kexec-bounces+dwmw2=infradead.org@lists.infradead.org To: Saeed Mirzamohammadi Cc: Thadeu Lima de Souza Cascardo , Geert Uytterhoeven , linux-doc@vger.kernel.org, Catalin Marinas , Bjorn Andersson , "H. Peter Anvin" , Will Deacon , Anson Huang , Jonathan Corbet , Dann Frazier , x86@kernel.org, Vinod Koul , Krzysztof Kozlowski , Ingo Molnar , Dave Young , Vivek Goyal , john.p.donnelly@oracle.com, Arnd Bergmann , Borislav Petkov , Thomas Gleixner , linux-arm-kernel@lists.infradead.org, Baoquan He , "Martin K. Petersen" , Randy Dunlap , kexec mailing list , LKML , "# v4 . 16+" , Li Yang , Miguel Ojeda , Michael Walle , =?UTF-8?Q?Diego_Elio_Petten=C3=B2?= , Olof Johansson , Shawn Guo Hi Saeed, thanks for your patch/idea! Comments inline, below. On Wed, Nov 18, 2020 at 8:29 PM Saeed Mirzamohammadi wrote: > > This adds crashkernel=auto feature to configure reserved memory for > vmcore creation to both x86 and ARM platforms based on the total memory > size. > > Cc: stable@vger.kernel.org > Signed-off-by: John Donnelly > Signed-off-by: Saeed Mirzamohammadi > --- > Documentation/admin-guide/kdump/kdump.rst | 5 +++++ > arch/arm64/Kconfig | 26 ++++++++++++++++++++++- > arch/arm64/configs/defconfig | 1 + > arch/x86/Kconfig | 26 ++++++++++++++++++++++- > arch/x86/configs/x86_64_defconfig | 1 + > kernel/crash_core.c | 20 +++++++++++++++-- > 6 files changed, 75 insertions(+), 4 deletions(-) > > diff --git a/Documentation/admin-guide/kdump/kdump.rst b/Documentation/admin-guide/kdump/kdump.rst > index 75a9dd98e76e..f95a2af64f59 100644 > --- a/Documentation/admin-guide/kdump/kdump.rst > +++ b/Documentation/admin-guide/kdump/kdump.rst > @@ -285,7 +285,12 @@ This would mean: > 2) if the RAM size is between 512M and 2G (exclusive), then reserve 64M > 3) if the RAM size is larger than 2G, then reserve 128M > > +Or you can use crashkernel=auto if you have enough memory. The threshold > +is 1G on x86_64 and arm64. If your system memory is less than the threshold, > +crashkernel=auto will not reserve memory. The size changes according to > +the system memory size like below: > > + x86_64/arm64: 1G-64G:128M,64G-1T:256M,1T-:512M As mentioned in the thread, this was tried before and never got merged - I'm not sure the all the reasons, but I speculate that a stronger reason is that it'd likely fail in many cases. I've seen cases of 256G servers that require crashkernel=600M (or more), due to the amount of devices. Also, the minimum nowadays would likely be 96M or more - I'm looping Cascardo and Dann (Debian/Ubuntu maintainers of kdump stuff) so they maybe can jump in with even more examples/considerations. What we've been trying to do in Ubuntu/Debian is using an estimator approach [0] - this is purely userspace and tries to infer the amount of necessary memory a kdump minimal[1] kernel would take. I'm not -1'ing your approach totally, but I think a bit more consideration is needed in the ranges, at least accounting the number of devices of the machine or something like that. Cheers, Guilherme [0] https://salsa.debian.org/debian/makedumpfile/-/merge_requests/7 [1] Minimal as having a reduced initrd + "shrinking" parameters (like nr_cpus=1). _______________________________________________ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec