Received: by 10.223.185.116 with SMTP id b49csp1664965wrg; Wed, 14 Feb 2018 22:46:15 -0800 (PST) X-Google-Smtp-Source: AH8x227dZMF8kN0a/rhmqCtR/tqEaqDy9Y+LbLTS5ldGYDIjgcMlJTYH7oDipJwgAeJy7bGioZWN X-Received: by 2002:a17:902:901:: with SMTP id 1-v6mr1595146plm.404.1518677175871; Wed, 14 Feb 2018 22:46:15 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1518677175; cv=none; d=google.com; s=arc-20160816; b=MKAEl570Epi7SFmFHrvde+hLZmkKlayhQ0gvQ9yS+bhqIBcIAWXxdKwt+Ix6+k3GQb lzYSHzIyI44vDQSDM9m/xPservKl8Pxrbq0UrZCQ3rLFDoj/uzARTVac0R4wMPo5687Q GBIs59HqH8sjxWNreFidfDRouHDc8VH4EyJr7p9SKK+ybwYn6AtthGYZyN3oYmTy4J01 AgxZpoKphG52WWX0MwkW8jarmmCm9xQKE/oUG5NKfHu7COPP3HKFqcRw5j/OvajNe+Jh 8DREdGOfz/33Z3gPQtmS3qxDcf5pDPEfeMEqg4BnjCHErGMoeFvccjWO0fFmFO3xecCg zaqA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:message-id:mime-version:date:references :in-reply-to:subject:cc:to:from:arc-authentication-results; bh=nF/ljf/d19OU1L5whZXpG8jLU1DsR49tUe0KSGMg+1E=; b=AZvNvNsL4rnfOsEYNP4GlNIcZXPwhVVTyCIOUdtJelsQWmAXAKfjmVgqtZn/Oplh9E VDaGOy5j1d9uvOi8p1sY0d8OKToTS61zZSMnQLMhjWeDl97mXqhQHHWOYESFAOi+ehpX OITgU7X7xymGsHyn1wYX4CyfSwH1bXdeFFOPGC77LsANXlCY9RtoDD/L2rYJvFUHHVVJ TW2zv2OgYSi+VW1oWtyWFuk0hhA8CMiwkJNRseQjJS6P49ioABROeGQ22KVSgDHZqhis qFyaaYvOZCdmIKko+MR7lO8usQhZOyAC4+A+B7g8rzLNDv0Jt3mn84UfnIO00TpBli+n cQpQ== 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=ibm.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id c67si2089596pfl.332.2018.02.14.22.45.29; Wed, 14 Feb 2018 22:46:15 -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=ibm.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754871AbeBOGnT (ORCPT + 99 others); Thu, 15 Feb 2018 01:43:19 -0500 Received: from mx0b-001b2d01.pphosted.com ([148.163.158.5]:40312 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1754842AbeBOGnN (ORCPT ); Thu, 15 Feb 2018 01:43:13 -0500 Received: from pps.filterd (m0098421.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w1F6elvm018925 for ; Thu, 15 Feb 2018 01:43:13 -0500 Received: from e06smtp13.uk.ibm.com (e06smtp13.uk.ibm.com [195.75.94.109]) by mx0a-001b2d01.pphosted.com with ESMTP id 2g4wduwny9-1 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=NOT) for ; Thu, 15 Feb 2018 01:43:12 -0500 Received: from localhost by e06smtp13.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Thu, 15 Feb 2018 06:43:10 -0000 Received: from b06cxnps3074.portsmouth.uk.ibm.com (9.149.109.194) by e06smtp13.uk.ibm.com (192.168.101.143) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Thu, 15 Feb 2018 06:43:06 -0000 Received: from d06av21.portsmouth.uk.ibm.com (d06av21.portsmouth.uk.ibm.com [9.149.105.232]) by b06cxnps3074.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id w1F6h6d81114448; Thu, 15 Feb 2018 06:43:06 GMT Received: from d06av21.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 95FCC52043; Thu, 15 Feb 2018 05:35:06 +0000 (GMT) Received: from vajain21.in.ibm.com (unknown [9.124.35.190]) by d06av21.portsmouth.uk.ibm.com (Postfix) with SMTP id 338DE5203F; Thu, 15 Feb 2018 05:35:04 +0000 (GMT) Received: by vajain21.in.ibm.com (sSMTP sendmail emulation); Thu, 15 Feb 2018 12:13:03 +0530 From: Vaibhav Jain To: Michael Ellerman , Balbir Singh Cc: "linux-kernel\@vger.kernel.org" , Nicholas Piggin , Paul Mackerras , Douglas Miller , Pan Xinhui , "open list\:LINUX FOR POWERPC \(32-BIT AND 64-BIT\)" Subject: Re: [PATCH] powerpc/xmon: Dont register sysrq key when kernel param xmon=off In-Reply-To: <87eflnre7w.fsf@concordia.ellerman.id.au> References: <20180212085956.12016-1-vaibhav@linux.vnet.ibm.com> <8737264c91.fsf@vajain21.in.ibm.com> <87eflnre7w.fsf@concordia.ellerman.id.au> Date: Thu, 15 Feb 2018 12:13:03 +0530 MIME-Version: 1.0 Content-Type: text/plain X-TM-AS-GCONF: 00 x-cbid: 18021506-0012-0000-0000-000005AEE6F5 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 18021506-0013-0000-0000-0000192AB4E5 Message-Id: <87d116wy6g.fsf@vajain21.in.ibm.com> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2018-02-15_03:,, signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=1 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1709140000 definitions=main-1802150085 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Thanks for looking into this patch Mpe. Michael Ellerman writes: > > > But the same crash happens with XMON_DEFAULT=n and nothing on the > command line. Yes, XMON_DEFAULT=n and empty boot command line implies xmon=off hence you will see the same issue and this patch should fix that issue too. > > The problem is not xmon=off on the command line. > > The problem is that when xmon_on = false and we enter xmon via sysrq and > then set breakpoints, we need to enable xmon_on before leaving xmon. > Agree on both the points made. > So this is a bug introduced by: > > 3b5bf42b81d5 ("powerpc/xmon: Fix an unexpected xmon on/off state change") > > > How to fix it is not entirely clear. In general I like the behaviour we > have since the above commit, ie. quickly dropping into xmon and > inspecting something doesn't leave xmon enabled, which then causes the > system not to kdump/reboot later. Agree on the convenience factor of leaving the xmon console enabled. However we still need a way to disable xmon completely at kernel-boot time. Leaving xmon enabled even if 'xmon=off' is provided at command line is counter intuitive. > > What would be nice is if we keep that behaviour, but any action you take > in xmon that requires xmon to remain resident, ie. setting a breakpoint, > calls a function which makes sure xmon_on = true and if it wasn't prints > a nice message saying "Turning xmon on due to breakpoint insertion" or > something. That makes sense to me and sounds workable. However we already have a debugfs interface to enable/disable xmon debugger hook. I can also tweak this interface to also register the sysrq key when xmon is enabled. This should provide the user the ability to still use xmon if they want to after the system has booted with xmon=off. > > cheers > -- Vaibhav Jain Linux Technology Center, IBM India Pvt. Ltd.