Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp485615yba; Thu, 9 May 2019 00:50:05 -0700 (PDT) X-Google-Smtp-Source: APXvYqyWG3wzVy3N66XYq18S/7oq8bAjPWieM09rQOX91A3NOo9D/EYYR5o14o+dNOeBPrJjAiIV X-Received: by 2002:a17:902:b412:: with SMTP id x18mr3209728plr.304.1557388205324; Thu, 09 May 2019 00:50:05 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1557388205; cv=none; d=google.com; s=arc-20160816; b=zb1GycA2XXgpaO8bLzbhH4UWzuO5QNu3aYCpRYJ/xRmcTYMMsGh1DGSJmpTXyaucK3 wWpu8jFRK1g9oLRscd1YGY0LWlnpKDaTzLQ79O5QHLuBGr7CUTV9oYhKS1UWdfRWyzho 9hZahLNV46NE473HSWRAbTbDK2FE9A/hz/C42Xj/RFd9Ma9kqTDsIZTYC9T6RsO2zrc9 nLEy9xF+gLPoLEnly/4eIeoevziEtLXMULASxcpbCWxQHTeUTzDGBz8+ZEsu9RR3Fe8Y qtjQ/yfmEWaDo0ZTL4ffANQi+Xdy7mGq5ccysvzQGob6Mho0hMsrvKMdLNqim+WiCKTI eWKw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:organization:user-agent :references:in-reply-to:subject:cc:to:from:message-id:date; bh=/gDhXjHKcb6kVwsIevP/5QEj8W1C+sBNy6S4MtSXNYw=; b=s3A7LiwykUql1/KsM8zxKhfakONB7ydA8klJoW2VkFGz2/8lhaGCGl5pRg38yFoRe/ aK8HRkJW3DL2BuIyvDpzulhQQPZRjTzP4dVilis/rQMOIy7NQbNTeUpwXqyQ13kPykcY c1jBZojET741GM48CsXevD32qOc0uS7CDWqWJVMvcuvC4xPBkwfYCXSMdXXtOEQkO/th xCjoHjcQUg3tcZqSJInrsQDY6zGM8Oib0rghjyNM6TawUNUGa4D2szUqx9xY/6GiV12U 9FwCygUz9QT2NBQ6pxAuvIVWTwqxi3DRO9+aqnXLdQI8MTDylx/fi+8dRH+12/I7cKgi CH9A== 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 p22si1720024plo.341.2019.05.09.00.49.49; Thu, 09 May 2019 00:50:05 -0700 (PDT) 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 S1726617AbfEIHsy (ORCPT + 99 others); Thu, 9 May 2019 03:48:54 -0400 Received: from usa-sjc-mx-foss1.foss.arm.com ([217.140.101.70]:32952 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725774AbfEIHsy (ORCPT ); Thu, 9 May 2019 03:48:54 -0400 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 7018DA78; Thu, 9 May 2019 00:48:53 -0700 (PDT) Received: from big-swifty.misterjones.org (usa-sjc-mx-foss1.foss.arm.com [217.140.101.70]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 09E013F7BD; Thu, 9 May 2019 00:48:43 -0700 (PDT) Date: Thu, 09 May 2019 08:48:26 +0100 Message-ID: <868svg9igl.wl-marc.zyngier@arm.com> From: Marc Zyngier To: Heyi Guo Cc: , wanghaibin 00208455 , kvmarm Subject: Re: ARM/gic-v4: deadlock occurred In-Reply-To: <4d60d130-b7ce-96cb-5f8a-11e83329601a@huawei.com> References: <9efe0260-4a84-7489-ecdd-2e9561599320@huawei.com> <86lfzl9ofe.wl-marc.zyngier@arm.com> <0b413592-7d98-ebe8-35c5-da330f800326@huawei.com> <86a7fx9lg8.wl-marc.zyngier@arm.com> <4d60d130-b7ce-96cb-5f8a-11e83329601a@huawei.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL/10.8 EasyPG/1.0.0 Emacs/26 (aarch64-unknown-linux-gnu) MULE/6.0 (HANACHIRUSATO) Organization: ARM Ltd MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Heyi, On Wed, 08 May 2019 14:01:48 +0100, Heyi Guo wrote: > > Hi Marc, > > The bad news is that though your previous patch fixed the lockdep > warnings, we can still reproduce soft lockup panics and some other > exceptions... So our issue may not be related with this lock defect. > > Most of the call traces are as below, stuck in smp_call_function_many: > > [ 6862.660611] watchdog: BUG: soft lockup - CPU#27 stuck for 23s! [CPU 18/KVM:95311] > [ 6862.668283] Modules linked in: ebtable_filter ebtables ip6table_filter ip6_tables iptable_filter vport_vxlan vxlan ip6_udp_tunnel udp_tunnel openvswitch nsh nf_nat_ipv6 nf_nat_ipv4 nf_conncount nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ib_isert iscsi_target_mod ib_srpt target_core_mod ib_srp scsi_transport_srp ib_ipoib ib_umad rpcrdma sunrpc rdma_ucm ib_uverbs ib_iser rdma_cm iw_cm ib_cm hns_roce_hw_v2 hns_roce aes_ce_blk crypto_simd ib_core cryptd aes_ce_cipher crc32_ce ghash_ce sha2_ce sha256_arm64 sha1_ce marvell ses enclosure hibmc_drm ttm drm_kms_helper drm sg ixgbe mdio fb_sys_fops syscopyarea hns3 hclge sysfillrect hnae3 sysimgblt sbsa_gwdt vhost_net tun vhost tap ip_tables dm_mod megaraid_sas hisi_sas_v3_hw hisi_sas_main ipmi_si ipmi_devintf ipmi_msghandler br_netfilter xt_sctp > [ 6862.668519] irq event stamp: 1670812 > [ 6862.668526] hardirqs last enabled at (1670811): [] el1_irq+0xd8/0x180 > [ 6862.668530] hardirqs last disabled at (1670812): [] el1_irq+0x88/0x180 > [ 6862.668534] softirqs last enabled at (1661542): [] __do_softirq+0x41c/0x51c > [ 6862.668539] softirqs last disabled at (1661535): [] irq_exit+0x18c/0x198 > [ 6862.668544] CPU: 27 PID: 95311 Comm: CPU 18/KVM Kdump: loaded Tainted: G W 4.19.36-1.2.141.aarch64 #1 > [ 6862.668548] Hardware name: Huawei TaiShan 2280 V2/BC82AMDA, BIOS TA BIOS TaiShan 2280 V2 - B900 01/29/2019 > [ 6862.668551] pstate: 80400009 (Nzcv daif +PAN -UAO) > [ 6862.668557] pc : smp_call_function_many+0x360/0x3b8 > [ 6862.668560] lr : smp_call_function_many+0x320/0x3b8 > [ 6862.668563] sp : ffff000028f338e0 > [ 6862.668566] x29: ffff000028f338e0 x28: ffff000009893fb4 > [ 6862.668575] x27: 0000000000000400 x26: 0000000000000000 > [ 6862.668583] x25: ffff0000080b1e08 x24: 0000000000000001 > [ 6862.668591] x23: ffff000009891bc8 x22: ffff000009891bc8 > [ 6862.668599] x21: ffff805f7d6da408 x20: ffff000009893fb4 > [ 6862.668608] x19: ffff805f7d6da400 x18: 0000000000000000 > [ 6862.668616] x17: 0000000000000000 x16: 0000000000000000 > [ 6862.668624] x15: 0000000000000000 x14: 0000000000000000 > [ 6862.668632] x13: 0000000000000040 x12: 0000000000000228 > [ 6862.668640] x11: 0000000000000020 x10: 0000000000000040 > [ 6862.668648] x9 : 0000000000000000 x8 : 0000000000000010 > [ 6862.668656] x7 : 0000000000000000 x6 : ffff805f7d329660 > [ 6862.668664] x5 : ffff000028f33850 x4 : 0000000002000402 > [ 6862.668673] x3 : 0000000000000000 x2 : ffff803f7f3dc678 > [ 6862.668681] x1 : 0000000000000003 x0 : 000000000000000a > [ 6862.668689] Call trace: > [ 6862.668693] smp_call_function_many+0x360/0x3b8 This would tend to indicate that one of the CPUs isn't responding to the IPI because it has its interrupts disabled, or has crashed badly already. Can you check where in smp_call_function_many this is hanging? My bet is on the wait loop at the end of the function. You'll need to find out what this unresponsive CPU is doing... > Any idea is appreciated. > > We will find some time and board to test your new patch set, but > right now our top priority is to debug the above issue, so it may > take some time to get back with the test result. Sorry for that. No worries, that can wait. M. -- Jazz is not dead, it just smell funny.