Received: by 10.223.185.116 with SMTP id b49csp8762911wrg; Fri, 2 Mar 2018 07:32:31 -0800 (PST) X-Google-Smtp-Source: AG47ELub6u36AE9tHTMRz8DF+dlN4D8VgIyHU/ru2TittH5o5alqH/fFfDtZsXgg9e7HYkMkNNMK X-Received: by 10.98.159.209 with SMTP id v78mr5969003pfk.49.1520004751541; Fri, 02 Mar 2018 07:32:31 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1520004751; cv=none; d=google.com; s=arc-20160816; b=QLcy8jdqbDtHor/wgH+jYBjtcBdY8duVmPtxREI0NXBfiRo9Vxp+ZLucz70KkuLOCo 8ndo2SOoflUmBnEgllLQX8NZ0lCYxf4ZcFfiogDYkm3mCw2j7uyd6RY6UkBXQwmdafEw jiwxsQPx5Dh6nT5KgTPswaspCl/kjEWNSgsF6Za+WYBitISIKLL92q6TtDgmdznKo25A ojpqpccTIKB7mK77Ks5P12DdsuL/ZFZFuqjXu3rOZB0eMCBbnU6uxJMAWbP6xLmIQSvg 53lJUtiKZN135fy2hrB/4ijHnpkLo3i2GSc3t/77gXZspRggyQ81C7FC1TX/lUZCbMfO 0fiA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:arc-authentication-results; bh=xwFe5khmIYoKAa5oY5oPYfoqYneE2ogtRw912JyklM4=; b=NlWkpg0EYwd0NaugB9GAPOH3jPlZwdxJZm0V4MHdF/Md//CellrmEL9eSlSEGSH1OC gDcpFTMe7uhPae7EtSWADEXWBQHj2TGy41lgE7xG4PGvz3E4cJloAfxyOWqHKZzkGMrK 54RZqlpC0+CTnD09+N2r07PYwcm1dOGi78H5aJ+waUsIJeZ/xOEJ2rw4OL/aZJQwPTPA Q4ieMb69/oMj/gfGz6fL91kRZxOO3vopfYVEa71oNbfDzDuKYVtVTqd99elLWjZKbvmr SqFN6MNwk3ITC+hBH39ILokBZRYrsimMc7UAZ6zOy/2FG3IX0iIOK6DRd14zDgrsVkhg YRcw== 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id e13si4107988pgt.569.2018.03.02.07.32.16; Fri, 02 Mar 2018 07:32:31 -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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1424157AbeCBNPw (ORCPT + 99 others); Fri, 2 Mar 2018 08:15:52 -0500 Received: from foss.arm.com ([217.140.101.70]:55100 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1423742AbeCBNPv (ORCPT ); Fri, 2 Mar 2018 08:15:51 -0500 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id D51371529; Fri, 2 Mar 2018 05:15:50 -0800 (PST) Received: from lakrids.cambridge.arm.com (usa-sjc-imap-foss1.foss.arm.com [10.72.51.249]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id D07B83F25C; Fri, 2 Mar 2018 05:15:48 -0800 (PST) Date: Fri, 2 Mar 2018 13:15:46 +0000 From: Mark Rutland To: Grzegorz Jaszczyk Cc: Marc Zyngier , catalin.marinas@arm.com, will.deacon@arm.com, james.morse@arm.com, "AKASHI, Takahiro" , Hoeun Ryu , linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, Nadav Haklai , Marcin Wojtas Subject: Re: [PATCH] arm64: kdump: fix interrupt handling done during machine_crash_shutdown Message-ID: <20180302131545.q2vf6uc3yofofqdb@lakrids.cambridge.arm.com> References: <1519837260-30662-1-git-send-email-jaz@semihalf.com> <20180228171647.6t4dabntujcb5kon@lakrids.cambridge.arm.com> <20180302120556.xujh3hoy44y7ouz7@lakrids.cambridge.arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20170113 (1.7.2) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Mar 02, 2018 at 01:59:27PM +0100, Grzegorz Jaszczyk wrote: > 2018-03-02 13:05 GMT+01:00 Mark Rutland : > > Do you have a way to reproduce the problem? > > > > Is there an easy way to cause the watchdog to trigger a kdump as above, > > e.g. via LKDTM? > > You can reproduce this problem by: > - enabling CONFIG_ARM_SBSA_WATCHDOG in your kernel > - passing via command-line: sbsa_gwdt.action=1 sbsa_gwdt.timeout=170 > - then load/prepare crasdump kernel (I am doing it via kexec tool) > - echo 1 > /dev/watchdog > > and after 170s the watchdog interrupt will hit triggering panic and > the whole kexec machinery will run. The sbsa_gwdt.timeout can't be too > small since it is also used for reset: > |----timeout-----(panic)----timeout-----reset. > If it is too small the crasdump kernel will not have enough time to start. > > It is also reproducible with different interrupts, e.g. for test I put > the panic to i2c interrupt handler and it was behaving the same. Do you see this for a panic() in *any* interrupt handler? Can you trigger the issue with magic-sysrq c, for example? > > I think you just mean GICv2 here. GICv2m is an MSI controller, and > > shouldn't interact with the SBSA watchdog's SPI. > > Yes of course, I just wanted to mention that it has MSI controller. Can you please tell us which platform you're seeing this on? Thanks, Mark.