Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp2384256imu; Thu, 10 Jan 2019 13:14:22 -0800 (PST) X-Google-Smtp-Source: ALg8bN7pAzV6lcQ2xZosG5szXW7zDoW2u+wU2w5ZveKHSNKqd76lylmrOCzfgvQfMP/JAdT6S4r6 X-Received: by 2002:a17:902:8484:: with SMTP id c4mr11612410plo.59.1547154862370; Thu, 10 Jan 2019 13:14:22 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1547154862; cv=none; d=google.com; s=arc-20160816; b=TtMI5r6kCnHqeT/vBC/ShlbfHaWlGShvjtGsf3wv/q7I7BPFmftBcJWRP/qQILhZRv hTcoovJggdgLW9EzVkS0EpzFyd+XEoniatIPyqDObHooHfWwVicf8HRas2KybouShdDT XAA2dkcZfTxAI2zkJQIcKOIpSrKnmpeqYcv3g5skHBil+UTLn6tHHqjxGG824T3yj0es vtZOSsVJnYezwWI5VS3yBbi7HZOYY7W8vQNZ6qLMVCwkmwhL4w/cD4sRb1FP/8T20cot O9uMckHcoAmbgONjSxYqWBY0wFf4OypcIbn6cAraXhvvHqiJAnzq6Lt9h9jVsAzcW0cC a2Zg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version; bh=IPmQEHAt+sKPcUs7anxfhO25G59A/UNlRVD68a8kfAU=; b=dyyLb/nvHcClzcCwmk58asL8gPwyfKrDjEr99Y7luMo2iXgIVH67CsMEgSeYrwqGa7 P5fSdF32rR54gVZc1jtPSc95o256+aw1104spO5piGcufJXMm3tlKatujBXgD5GExyzc LenaKXo1KAr4A7xlKcF7XfE/Xn3H9vZFbXYu1S5INxQoQ4IVA5YgK34O8JeglRjV2+Hb QR9PbB9GDMNS5oa6BKnwRSoozU56LqThyQiHambXZQMkmrhvJEK7IhUGYXqkeTAthXo/ vOl3Leb3b/y+v0Bcgf1C1uyrYtXbzlGJTlzNogfk4y9iHuNd8R5tFu2irA8PZigLm09a vVqw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id p11si5895644plk.191.2019.01.10.13.14.07; Thu, 10 Jan 2019 13:14:22 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729843AbfAJUAl (ORCPT + 99 others); Thu, 10 Jan 2019 15:00:41 -0500 Received: from mail-lf1-f68.google.com ([209.85.167.68]:38763 "EHLO mail-lf1-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726242AbfAJUAk (ORCPT ); Thu, 10 Jan 2019 15:00:40 -0500 Received: by mail-lf1-f68.google.com with SMTP id a8so9191532lfk.5 for ; Thu, 10 Jan 2019 12:00:39 -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=IPmQEHAt+sKPcUs7anxfhO25G59A/UNlRVD68a8kfAU=; b=tyS471DoV+WXoV7whUXo8mHdDbtZmKYP4ER8UZs3gx4EPznZlMVLp5JdEX67raMbYa vUXcWKe4j1nMvD6rh0JipX0/7RuM5pXC7sSPUc42HPv4gzdnL/eiW0u/saHFbl7RTuU6 Am56bjIvfp2aw6KmLSYufeWpUoKWwgCo3gDuG08CyGdUIWhpg95xNeKPVFPFmh66cbcn q1+TISaYTQr7UoYylC9+1vuU4eiVgw5TXhZcAMjkgc+RrcBu4PPyhf4CKHAxi/pr62f3 tMhygcmeY40sj39m+wKazgSX422QhpjtmnVZgxHD2cZQ3JXdMbA57mrktdUnfO68hz4T kxXw== X-Gm-Message-State: AJcUuke0qLNoAsH512K41IDXWzSaeIb/F7q73pVOZ360L7Yq0LI/4mXc sMHlABLn/KYK9PVHd2w7ncqKPu0JzuLOc3+sAvNM2Q== X-Received: by 2002:ac2:51af:: with SMTP id f15mr6312409lfk.44.1547150438890; Thu, 10 Jan 2019 12:00:38 -0800 (PST) MIME-Version: 1.0 References: <20181213052259.56352-1-cai@lca.pw> <20181214040819.58625-1-cai@lca.pw> In-Reply-To: From: Bhupesh Sharma Date: Fri, 11 Jan 2019 01:30:26 +0530 Message-ID: Subject: Re: [PATCH v2] arm64: invalidate TLB just before turning MMU on To: Qian Cai Cc: Ard Biesheuvel , Marc Zyngier , Catalin Marinas , Will Deacon , Linux Kernel Mailing List , AKASHI Takahiro , James Morse , Kexec Mailing List , linux-arm-kernel Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Qian, On Sat, Dec 15, 2018 at 7:24 AM Qian Cai wrote: > > On 12/14/18 2:23 AM, Ard Biesheuvel wrote: > > On Fri, 14 Dec 2018 at 05:08, Qian Cai wrote: > >> Also tried to move the local TLB flush part around a bit inside > >> __cpu_setup(), although it did complete kdump some times, it did trigger > >> "Synchronous Exception" in EFI after a cold-reboot fairly often that > >> seems no way to recover remotely without reinstalling the OS. > > > > This doesn't make any sense to me. If the system gets into a weird > > state out of cold reboot, how could this code be the culprit? Please > > check your firmware, and try to reproduce the issue on a system that > > doesn't have such defects. > > > > I'll continue investigating those "Synchronous Exception" although it is kind of > hard due to I don't have any source code of the firmware to confirm it is buggy > or not. > > I did manage to reproduce this kdump issue on around 5 of those server running a > fairly recent version of the firmware (07/01/2018). I don't have access to other > large CPU machines. Sorry I got busy with some other stuff, but as I reported earlier, I am not able to reproduce this on my HPE apollo with the latest linus tree as well. Here are some details on my setup: 1. # uname -r 5.0.0-rc1+ with the following commit as the HEAD: commit a88cc8da0279f8e481b0d90e51a0a1cffac55906 (HEAD -> master, origin/master, origin/HEAD) Merge: 9cb2feb4d21d 73444bc4d8f9 Author: Linus Torvalds Date: Tue Jan 8 18:58:29 2019 -0800 Merge branch 'akpm' (patches from Andrew) 2. I use the following kdump commandline: Kernel command line: BOOT_IMAGE=(hd9,gpt2)/vmlinuz-5.0.0-rc1+ ro irqpoll nr_cpus=1 swiotlb=noforce reset_devices earlycon=pl011,mmio,0x402020000 3. I am able to run kdump successfully on the machine and also collect the crash core properly: .. snip.. kdump: saving to /sysroot//var/crash/127.0.0.1-2019-01-10-10:52:25/ kdump: saving vmcore-dmesg.txt kdump: saving vmcore-dmesg.txt complete kdump: saving vmcore Copying data : [100.0 %] \ eta: 0s kdump: saving vmcore complete .. snip .. 4. I use the same firmware version on the board as you shared earlier: # dmidecode | grep -A 20 -i "BIOS Information" BIOS Information Vendor: American Megatrends Inc. Version: L50_5.13_1.0.6 Release Date: 07/10/2018 Address: 0xF0000 Runtime Size: 64 kB ROM Size: 64 MB Characteristics: PCI is supported BIOS is upgradeable BIOS shadowing is allowed Boot from CD is supported Selectable boot is supported BIOS ROM is socketed ACPI is supported BIOS boot specification is supported Targeted content distribution is supported UEFI is supported BIOS Revision: 6.3 So, I am guessing that it might be a kdump command line issue at your end. Thanks, Bhupesh