From patchwork Wed Jan 24 22:39:53 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "Russell King (Oracle)" X-Patchwork-Id: 10183187 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 95A4B601D5 for ; Wed, 24 Jan 2018 22:40:14 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 716A8287E8 for ; Wed, 24 Jan 2018 22:40:14 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 6606B28763; Wed, 24 Jan 2018 22:40:14 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.8 required=2.0 tests=BAYES_00,DKIM_SIGNED, RCVD_IN_DNSWL_HI,T_DKIM_INVALID autolearn=ham version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id F3EFB287E8 for ; Wed, 24 Jan 2018 22:40:12 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932507AbeAXWkM (ORCPT ); Wed, 24 Jan 2018 17:40:12 -0500 Received: from pandora.armlinux.org.uk ([78.32.30.218]:39148 "EHLO pandora.armlinux.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932072AbeAXWkL (ORCPT ); Wed, 24 Jan 2018 17:40:11 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=armlinux.org.uk; s=pandora-2014; h=Sender:In-Reply-To:Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date; bh=BRvK6mgTaOevsjMjCwzUWeqr3FzXfpBJnuhA9NvtLjk=; b=AMJr3TrQSgreUWrqhRpzKD4UkHU4tSIjQ0zhghUJdmDZYgbEDqtpp+NZbkl0A9B10hfv5vX/hY6HdIrA5fnUv6IJFdaa3qhM4F2YnZPEQT3gjvm8DhwU2iIZrqelhndCUdKkiK2t7ezre/P3f1w45pxo2BDExWD9Zh7SYctwxD8=; Received: from n2100.armlinux.org.uk ([2001:4d48:ad52:3201:214:fdff:fe10:4f86]:54255) by pandora.armlinux.org.uk with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1eeTi1-0003M2-O9; Wed, 24 Jan 2018 22:39:57 +0000 Received: from linux by n2100.armlinux.org.uk with local (Exim 4.76) (envelope-from ) id 1eeThy-0001aj-5u; Wed, 24 Jan 2018 22:39:54 +0000 Date: Wed, 24 Jan 2018 22:39:53 +0000 From: Russell King - ARM Linux To: Aaro Koskinen Cc: Tony Lindgren , Keerthy , linux-omap@vger.kernel.org, linux-arm-kernel@lists.infradead.org Subject: Re: [BISECTED] kexec issue with v4.15-rc on N8x0 Message-ID: <20180124223953.GO28231@n2100.armlinux.org.uk> References: <20180111194747.k5qwz66mfntj6v2g@darkstar.musicnaut.iki.fi> <20180115181508.GM4821@atomide.com> <20180122220654.k6atriweesf2qmw4@darkstar.musicnaut.iki.fi> <20180123204544.GM28231@n2100.armlinux.org.uk> <20180123212327.GN28231@n2100.armlinux.org.uk> <20180124212133.qyav5w36meljaakq@darkstar.musicnaut.iki.fi> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20180124212133.qyav5w36meljaakq@darkstar.musicnaut.iki.fi> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-omap-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-omap@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP On Wed, Jan 24, 2018 at 11:21:33PM +0200, Aaro Koskinen wrote: > Hi, > > On Tue, Jan 23, 2018 at 09:23:27PM +0000, Russell King - ARM Linux wrote: > > On Tue, Jan 23, 2018 at 08:45:44PM +0000, Russell King - ARM Linux wrote: > > > On Tue, Jan 23, 2018 at 12:06:54AM +0200, Aaro Koskinen wrote: > > > > On Mon, Jan 15, 2018 at 10:15:08AM -0800, Tony Lindgren wrote: > > > > > * Aaro Koskinen [180111 11:48]: > > > > > > When booting v4.15-rc kernel with kexec (kexec-tools 2.0.16) on N8x0, I get: > > > > > > > > > > > > Uncompressing Linux... done, booting the kernel. > > > > > > no ATAGS support: can't continue > > > > > > > > > > > > v4.14 kernel works OK. > > > > > > > > > > > > I bisected this to: > > > > > > > > > > > > commit c772568788b5f0cbaac7c8d4111d7173bfc90673 > > > > > > Author: Russell King > > > > > > Date: Thu Sep 21 18:10:19 2017 +0100 > > > > > > > > > > > > ARM: add additional table to compressed kernel > > > > > > > > > > > > If I revert the commit, kexec booting starts to work. Interesting, > > > > > > the patch mentions "This is necessary for correct behaviour of kexec.", > > > > > > so I wonder what could be wrong... > > > > > > > > > > So care to post what you get if you load with kexec -d -l options > > > > > before and after this commit? > > > > > > > > See below. I guess the interesting part is the "zImage has tags" with the > > > > bad kernel. > > > > > > > > Bad (plain v4.15-rc9) > > > > --------------------- > > > > kernel: 0xb6a25008 kernel_size: 0x3ce605 > > > > MEMORY RANGES > > > > 0000000080000000-0000000087ffffff (0) > > > > zImage header: 0x016f2818 0x00000000 0x003c59d0 > > > > zImage size 0x3c59d0, file size 0x3ce605 > > > > > > This looks like you've appended a DTB blob to the zImage as the file > > > is larger than the zImage says it should be. > > Yes. I have now disabled/removed the appended DTB, just in case, but it > doesn't seem to make any difference. > > > > Right, so this says that this is a "modern" kernel that's being loaded > > > with the additional tags in that tell kexec how much space the > > > decompressed kernel requires. > > > > > > > kernel image size: 0x00c5c6ec > > > > > > and it requires this amount of space. > > > > > > > kexec_load: entry = 0x80008000 flags = 0x280000 > > > > nr_segments = 2 > > > > segment[0].buf = 0xb6a25008 > > > > segment[0].bufsz = 0x3c59d0 > > > > segment[0].mem = 0x80008000 > > > > segment[0].memsz = 0x3c6000 > > > > > > This is the kernel, with the appended dtb removed. > > > > > > > segment[1].buf = 0x1ed52b8 > > > > segment[1].bufsz = 0x8c35 > > > > segment[1].mem = 0x80c66000 > > > > segment[1].memsz = 0x9000 > > > > > > This is the DTB, placed out of the way from the kernel (the highest > > > address the kernel will use while decompressing is 0x00c5c6ec + > > > 0x80008000. Everything here looks correct. > > But something is still corrupting the DTB... > > > > > [ 4.850341] kexec_core: Starting new kernel > > > > [ 4.854766] Bye! > > > > > > > > (kernel fails to boot) > > > > > > > > Good (v4.15-rc9 and c772568788b5f0cbaac7c8d4111d7173bfc90673 reverted) > > > > ----------------------------- > > > > kernel: 0xb6999008 kernel_size: 0x3ce9bd > > > > MEMORY RANGES > > > > 0000000080000000-0000000087ffffff (0) > > > > zImage header: 0x016f2818 0x00000000 0x003c5d88 > > > > zImage size 0x3c5d88, file size 0x3ce9bd > > > > kexec_load: entry = 0x80008000 flags = 0x280000 > > > > nr_segments = 2 > > > > segment[0].buf = 0xb6999008 > > > > segment[0].bufsz = 0x3c5d88 > > > > segment[0].mem = 0x80008000 > > > > segment[0].memsz = 0x3c6000 > > > > > > Here we have the same thing for the kernel. > > > > > > > segment[1].buf = 0x14192b8 > > > > segment[1].bufsz = 0x8c35 > > > > segment[1].mem = 0x812e7000 > > > > segment[1].memsz = 0x9000 > > > > > > Here, the DTB is placed much further away. > > So, the "compression ratio 4 calculation" works better. > > > > It really doesn't help that it took ages for the kexec-tools patches > > > to get merged, and when they did get merged, the wrong patch set was > > > taken. Consequently, the debug above does not match my local source > > > tree, and neither does the code. > > > > > > Sorry, but I'm afraid I can't debug this at the moment. > > > > Here's the delta between what _was_ merged and what I intended to be > > merged: > > > > 8<===== > > From: Russell King > > Subject: [PATCH] ARM: read kernel size from zImage > > I tried this, output looks different but the kernel is still unbootable. > I also tried switching from XZ to GZIP decompressor, but it didn't help > either. > > kernel: 0xb68e7008 kernel_size: 0x56cdf0 > MEMORY RANGES > 0000000080000000-0000000087ffffff (0) > zImage header: 0x016f2818 0x00000000 0x0056cdf0 > zImage size 0x56cdf0, file size 0x56cdf0 > offset 0x000039c0 tag 0x5a534c4b size 8 > Kernel: address=0x80008000 size=0x010b4d90 > DT : address=0x810be000 size=0x00008c35 > kexec_load: entry = 0x80008000 flags = 0x280000 > nr_segments = 2 > segment[0].buf = 0xb68e7008 > segment[0].bufsz = 0x56cdf0 > segment[0].mem = 0x80008000 > segment[0].memsz = 0x56d000 > segment[1].buf = 0x7622b8 > segment[1].bufsz = 0x8c35 > segment[1].mem = 0x810be000 > segment[1].memsz = 0x9000 > [ 5.070251] kexec_core: Starting new kernel > [ 5.074676] Bye! > > Then I played around with kexec_arm_image_size in kexec-tools, and > noticed that adding only 0x2000 gets booting to work: > > kernel: 0xb681f008 kernel_size: 0x56cdf0 > MEMORY RANGES > 0000000080000000-0000000087ffffff (0) > zImage header: 0x016f2818 0x00000000 0x0056cdf0 > zImage size 0x56cdf0, file size 0x56cdf0 > offset 0x000039c0 tag 0x5a534c4b size 8 > Kernel: address=0x80008000 size=0x010b6d90 > DT : address=0x810c0000 size=0x00008c35 > kexec_load: entry = 0x80008000 flags = 0x280000 > nr_segments = 2 > segment[0].buf = 0xb681f008 > segment[0].bufsz = 0x56cdf0 > segment[0].mem = 0x80008000 > segment[0].memsz = 0x56d000 > segment[1].buf = 0x9412b8 > segment[1].bufsz = 0x8c35 > segment[1].mem = 0x810c0000 > segment[1].memsz = 0x9000 > [ 5.070312] kexec_core: Starting new kernel > [ 5.074737] Bye! > [ 0.000000] Booting Linux on physical CPU 0x0 > [ 0.000000] Linux version 4.15.0-rc9-n8x0-los_a513f+ (aaro@amd-fx-6350) (gcc version 6.4.0 (GCC)) #1 Wed Jan 24 21:30:47 EET 2018 > [...] > > So something is missing from the size calculation...? Maybe. Please try this patch on top of the previous one, and report the new debug output. diff --git a/kexec/arch/arm/kexec-zImage-arm.c b/kexec/arch/arm/kexec-zImage-arm.c index 76a0b5b66745..2a7eea907769 100644 --- a/kexec/arch/arm/kexec-zImage-arm.c +++ b/kexec/arch/arm/kexec-zImage-arm.c @@ -553,6 +553,14 @@ int zImage_arm_load(int argc, char **argv, const char *buf, off_t len, kernel_mem_size = len + 4; /* + * The zImage length does not include its stack (4k) or its + * malloc space (64k). Include this. + */ + len += 0x11000; + + dbgprintf("zImage requires 0x%08llx bytes\n", (unsigned long long)len); + + /* * Check for a kernel size extension, and set or validate the * image size. This is the total space needed to avoid the * boot kernel BSS, so other data (such as initrd) does not get @@ -565,6 +573,12 @@ int zImage_arm_load(int argc, char **argv, const char *buf, off_t len, uint32_t bss_size = le32_to_cpu(tag->u.krnl_size.bss_size); uint32_t kernel_size = edata_size + bss_size; + dbgprintf("Decompressed kernel sizes:\n"); + dbgprintf(" text+data 0x%08lx bss 0x%08lx total 0x%08lx\n", + (unsigned long)edata_size, + (unsigned long)bss_size, + (unsigned long)kernel_size); + /* * While decompressing, the zImage is placed past _edata * of the decompressed kernel. Ensure we account for that. @@ -572,6 +586,9 @@ int zImage_arm_load(int argc, char **argv, const char *buf, off_t len, if (kernel_size < edata_size + len) kernel_size = edata_size + len; + dbgprintf("Resulting kernel space: 0x%08lx\n", + (unsigned long)kernel_size); + if (kexec_arm_image_size == 0) kexec_arm_image_size = kernel_size; else if (kexec_arm_image_size < kernel_size) {