From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pg1-f171.google.com (mail-pg1-f171.google.com [209.85.215.171]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 3054A48D874 for ; Wed, 19 Aug 2026 18:00:12 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.215.171 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787162414; cv=none; b=u0683k+39zEveDZ6fIVm3rXl8CPUhgpZvVr6uOXvmdRfk/tLNGq9gTlZ/em+oXgpzcFn9FcsDVdyByxO7MM5D7X9pb8o8M/rHmCiEV6RMZO9U7b6g9XjhUF26IJK5xJU+8FQnkG23RjzOM/4+LXwUEMPR1JJ0Ser3NKC2dzcZzA= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787162414; c=relaxed/simple; bh=ENtvYKYEhz5FjfsHNNre0679dXILkBcT7wr5GO5Ucec=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=ny5/2RBu9CFlFaoSj5553oEJsZdz8XIH6BMVe/a0djCcg6X9xauy+SO+6/w2lpzAIrFUJYCKt02s7XaaaL0xr6N/qgGXlDb2Z295ut9hHTkzzoVd9PGrvRb8Bj7Mhv9OdP2oKPgQ+TAxfp/XksJuM563fBJzrnsUGRXJE3dUMUo= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=purestorage.com; spf=pass smtp.mailfrom=purestorage.com; dkim=pass (2048-bit key) header.d=purestorage.com header.i=@purestorage.com header.b=IlFQ7QCl; arc=none smtp.client-ip=209.85.215.171 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=purestorage.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=purestorage.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=purestorage.com header.i=@purestorage.com header.b="IlFQ7QCl" Received: by mail-pg1-f171.google.com with SMTP id 41be03b00d2f7-ca80d708489so107498a12.1 for ; Wed, 19 Aug 2026 11:00:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=purestorage.com; s=google2022; t=1787162412; x=1787767212; darn=vger.kernel.org; h=content-transfer-encoding:content-type:mime-version:references :in-reply-to:message-id:date:subject:cc:to:from:from:to:cc:subject :date:message-id:reply-to:content-type; bh=ENtvYKYEhz5FjfsHNNre0679dXILkBcT7wr5GO5Ucec=; b=IlFQ7QClHKR0jRNTezLWoQBtfEiDuPqnSDzVqOikla5NlqBmLRN0wYiGiM11WADPmH Aaj1+kDJDts9wexrs5qenbyfWjK+/5C6ztxAWZo0PHRo0PUbNaMrYG7P77Nz1b12NFHB 6luN8xqm7768So0f8lUHKsfoaXaO7n3hZebbu7+fswCVW/msxkea4BlQ7Fd4EoJiC8RI Uug7OPGnd5BbaItxA8dFQnp1r+yNhhgpfgvvGFoSh2RvfYtdGXQyGzwgtJsTfY44okNU yjrGrsxthSBKkZwwefjN0w3zyq9/Sp9/Ll5OWlNSaoUDR+tOQmzZx2FzrHepJJaiKrJA XWpA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1787162412; x=1787767212; h=content-transfer-encoding:content-type:mime-version:references :in-reply-to:message-id:date:subject:cc:to:from:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=ENtvYKYEhz5FjfsHNNre0679dXILkBcT7wr5GO5Ucec=; b=ozK5H/oz9Iv/8ZiMaKw5CYNC6Dp1eCHPoh078fYd8Nhz+8XQE/EHeZsU/PxycCdiBS 2ygVyV729oFU17XfGhKkAWVTpUuA5Q+nqNyNOYhIgxCI7AEMxD4tNgw4BtL7CgIC/JEv 2o4qi/VJnGB4yaEBBtV1740MUH7teIDiiweoDLYgmwSqqhNgCMiacJJJNWtmGLNH5IRj GoaHYcYPrwkS8XaaGbGInszQXowrDXZGFxYkaBSEEizoFrHmWUI1qqjkXvHg8ZLgt4OW ytaQJykx6kWebETEFWGKlGUzE9Xb8cFxOZZ+kx78snv4iR9O3/etV7l81BibwXtITf6q VDUQ== X-Forwarded-Encrypted: i=1; AHgh+Rr0qlI0Z3G/Fj8vk9p8ZCAjQnjKJb0+om0njjoKQFTe2+o0yg+RtPIKeuxLXqQjVQh8BOrJTn8eVcjl@vger.kernel.org X-Gm-Message-State: AOJu0YzDEyW4TmPI9sSxRjbQNadP+t2EggIYHbbS+BXIwXlO2ef09bNJ LZC9HufenmmgiWPGqv0F+rsqFn44ELu1bvt8Amr31BaHv7RiTUh34nx77GvnPb1EIuk= X-Gm-Gg: AR+sD13PMAedB//2iIVEBeWcRkOYxVs10nsX04hf4BQkGN59xwKzbfx+/9F1jmwFtrG CSYejcRwTnB4sLbj2vR16IYIHmiGc7r5OAIp7HZcBqnk6P0exd41EMYvCo6w2tB3iSkC4SOQvGW RjQQP2FPqngPqw9Zfx2NumGOij0M2PJZe0+KgFlx9YjlO0GCVgo3ro2jH7FjFR5CW4p0WzqeKcz m/XvGaX+5nmFr/zdR+daJTO6Shg4N5xaGf0RsjY6cgRZmgaL63T/AU9p/umirsx62QNB5KtO6os cf1eGxFwAAAmU+SQJtc8/kshQaYIKTVyFzI/4P+BThHfW+f2bE9BdCEwwEvsRN4g95fqZELVONL Sv3h9RlpiHGHfMQxT3XhTymN2cym3aage+dCk0wv1plz5h3NGplpVpBgYclLAnHZ8PpT+x7Rpls jlpeLd2uCdg5Au/pSMcs8Fy2vRlo5/YM1aEovLfzpyhHsvTAHzFwTASvGMOCMMy0G2hPgyC+Qa1 yxbIQknnw893tA= X-Received: by 2002:a05:6a21:60c3:b0:3cc:dce8:1109 with SMTP id adf61e73a8af0-3cd14c6b137mr1001854637.3.1787162412361; Wed, 19 Aug 2026 11:00:12 -0700 (PDT) Received: from dev-jrangi.dev.purestorage.com ([208.88.159.128]) by smtp.googlemail.com with ESMTPSA id 5a478bee46e88-327bf10b584sm15843476eec.16.2026.08.19.11.00.11 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 19 Aug 2026 11:00:11 -0700 (PDT) From: Jasjeet Rangi To: yazen.ghannam@amd.com Cc: Smita.KoralahalliChannabasappa@amd.com, bp@alien8.de, dave.hansen@linux.intel.com, dgiani@purestorage.com, hpa@zytor.com, jrangi@purestorage.com, linux-edac@vger.kernel.org, mingo@redhat.com, msaggi@purestorage.com, rhan@purestorage.com, rjethwani@purestorage.com, stable@vger.kernel.org, tglx@kernel.org, tony.luck@intel.com, x86@kernel.org Subject: Re: [PATCH v2 1/2] x86/mce/amd: Fix inverted interrupt enablement during storm handling Date: Wed, 19 Aug 2026 10:59:38 -0700 Message-ID: <20260819175939.2068993-1-jrangi@purestorage.com> X-Mailer: git-send-email 2.50.1 In-Reply-To: <20260819140647.GA2416@yaz-khff2.amd.com> References: <20260819140647.GA2416@yaz-khff2.amd.com> Precedence: bulk X-Mailing-List: linux-edac@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On Wed, Aug 19, 2026 at 7:07 AM Yazen Ghannam wrote: > > IMO, disabling the interrupt is the best way to manage the storm. The > reason for Intel to set a high limit is to keep the interrupt enabled. > The reason to keep the interrupt enabled is because the same interrupt > line is used for reporting "uncorrectable,no action" errors. This isn't > necessary on AMD because there's a separate interrupt line for those > errors: Deferred error interrupt. Agreed. Also that was the original intent of the patch that this thread/patch is fixing. From the commit message for 5c4663ed1eac ("x86/mce: Handle AMD threshold interrupt storms"): ``` But, unlike CMCI, do not set thresholds and reduce interrupt rate on a storm. Rather, disable the interrupt on the corresponding CPU and bank. Re-enable back the interrupts if enough consecutive polls of the bank show no corrected errors (30, as programmed by Intel). ``` > It's fair to set a low threshold limit. Some users want to see corrected > errors without needing to poll. And they'd like to see them ASAP. > > The threshold limit isn't much of a contributor to interrupt storms. A > stuck bit/failing device will likely trigger a storm whether the limit > is '1' or '4095'. Agreed. Thanks for clarifying. Thanks, Jasjeet