From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 6228FC433EF for ; Tue, 15 Mar 2022 17:26:55 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1350557AbiCOR2G (ORCPT ); Tue, 15 Mar 2022 13:28:06 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:52504 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1347737AbiCOR2D (ORCPT ); Tue, 15 Mar 2022 13:28:03 -0400 Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 4469758810; Tue, 15 Mar 2022 10:26:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1647365211; x=1678901211; h=message-id:date:mime-version:subject:to:cc:references: from:in-reply-to:content-transfer-encoding; bh=ziFZXhnT03uuTOlbqC0mwUAOAr35MoEzqvS9Lt46bRY=; b=cCl5a8WOzZL0YfmBntZPZOfsuMxJ92lxp6l0S+LDgOEOVenBd4rovwxe 3wfMIWKzI2ayYoAm4PmOW5dkojF07ehe+syJuDwrWGFBDifEylVNoNOby PMTJkqWXfKOkeO+BNkteJZsSUEikaj2ttwwCYLCWsRpLSHaExOPy17neZ x6r8mXdpV8gfCm3pKpxpFXFKkURBwDY6jydkdlfs97OvFAsJbeGuvIEW0 ARWfQkjeLGnb+27v9W2IAeDGkGX++lVWcT4zUq5DcmOg2vhFSDKptBWia hHqxi07BY9nfmSUNnjAbVoTG8Di4Fokifsv0wGNxeL8vk+SglLp28y6OE g==; X-IronPort-AV: E=McAfee;i="6200,9189,10286"; a="281143973" X-IronPort-AV: E=Sophos;i="5.90,184,1643702400"; d="scan'208";a="281143973" Received: from orsmga002.jf.intel.com ([10.7.209.21]) by fmsmga101.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 15 Mar 2022 10:26:47 -0700 X-IronPort-AV: E=Sophos;i="5.90,184,1643702400"; d="scan'208";a="512690836" Received: from rariley-mobl.amr.corp.intel.com (HELO [10.209.120.225]) ([10.209.120.225]) by orsmga002-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 15 Mar 2022 10:26:46 -0700 Message-ID: <2d4e8811-dce6-c891-e92d-e3746434685e@linux.intel.com> Date: Tue, 15 Mar 2022 10:26:46 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Firefox/91.0 Thunderbird/91.5.0 Subject: Re: [PATCH v2] PCI/AER: Handle Multi UnCorrectable/Correctable errors properly Content-Language: en-US To: Eric Badger Cc: Bjorn Helgaas , Russell Currey , Oliver OHalloran , linux-pci@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org References: <20220315050842.120063-1-sathyanarayanan.kuppuswamy@linux.intel.com> <20220315171425.GA1521135@ebps> From: Sathyanarayanan Kuppuswamy In-Reply-To: <20220315171425.GA1521135@ebps> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 3/15/22 10:14 AM, Eric Badger wrote: >> # Prep injection data for a correctable error. >> $ cd /sys/kernel/debug/apei/einj >> $ echo 0x00000040 > error_type >> $ echo 0x4 > flags >> $ echo 0x891000 > param4 >> >> # Root Error Status is initially clear >> $ setpci -s ECAP0001+0x30.w >> 0000 >> >> # Inject one error >> $ echo 1 > error_inject >> >> # Interrupt received >> pcieport : AER: Root Error Status 0001 >> >> # Inject another error (within 5 seconds) >> $ echo 1 > error_inject >> >> # No interrupt received, but "multiple ERR_COR" is now set >> $ setpci -s ECAP0001+0x30.w >> 0003 >> >> # Wait for a while, then clear ERR_COR. A new interrupt immediately >> fires. >> $ setpci -s ECAP0001+0x30.w=0x1 >> pcieport : AER: Root Error Status 0002 >> >> Currently, the above issue has been only reproduced in the ICL server >> platform. >> >> [Eric: proposed reproducing steps] > Hmm, this differs from the procedure I described on v1, and I don't > think will work as described here. I have attempted to modify the steps to reproduce it without returning IRQ_NONE for all cases (which will break the functionality). But I think I did not correct the last few steps. How about replacing the last 3 steps with following? # Inject another error (within 5 seconds) $ echo 1 > error_inject # You will get a new IRQ with only multiple ERR_COR bit set pcieport : AER: Root Error Status 0002 -- Sathyanarayanan Kuppuswamy Linux Kernel Developer From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from lists.ozlabs.org (lists.ozlabs.org [112.213.38.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id DAE88C433EF for ; Tue, 15 Mar 2022 17:28:32 +0000 (UTC) Received: from boromir.ozlabs.org (localhost [IPv6:::1]) by lists.ozlabs.org (Postfix) with ESMTP id 4KJ0k72y4Pz3bbc for ; Wed, 16 Mar 2022 04:28:31 +1100 (AEDT) Authentication-Results: lists.ozlabs.org; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=intel.com header.i=@intel.com header.a=rsa-sha256 header.s=Intel header.b=eqT/ENsE; dkim-atps=neutral Authentication-Results: lists.ozlabs.org; spf=none (no SPF record) smtp.mailfrom=linux.intel.com (client-ip=134.134.136.24; helo=mga09.intel.com; envelope-from=sathyanarayanan.kuppuswamy@linux.intel.com; receiver=) Authentication-Results: lists.ozlabs.org; dkim=pass (2048-bit key; unprotected) header.d=intel.com header.i=@intel.com header.a=rsa-sha256 header.s=Intel header.b=eqT/ENsE; dkim-atps=neutral Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 4KJ0jL5nkgz2xXZ for ; Wed, 16 Mar 2022 04:27:49 +1100 (AEDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1647365271; x=1678901271; h=message-id:date:mime-version:subject:to:cc:references: from:in-reply-to:content-transfer-encoding; bh=ziFZXhnT03uuTOlbqC0mwUAOAr35MoEzqvS9Lt46bRY=; b=eqT/ENsE5cBjxKhYyiG0gwvmJD/AN7zNbL8PRWDL7B/H83LYyZYauYFm uNgCJUDUrx9fP913P4tjDCJVeusUuiS9T++E+ZNZYvgqkj25bpMvxR66m a+w/dXsIYHnEsio7A+uoHeD6IetSrdOiE3pBSP/7GxZO9hF/VVTfkoA7b eAMrMMcxZ1TtKUG3MKxo3n9Na5HPLZpMGuucWTnQl353R/cfRVxFFFT3y 8FF5D9ANjIWWf/QsW3Ghi7nGdxWrs4oi8r+OOid7y5FE+/80wDtFcbWEK Ru8z+zzy+EKYT6ufvwUA1TSnDeVq41y+uqK6DraM6bZtRV+3s8Snv52xl Q==; X-IronPort-AV: E=McAfee;i="6200,9189,10286"; a="256095974" X-IronPort-AV: E=Sophos;i="5.90,184,1643702400"; d="scan'208";a="256095974" Received: from orsmga002.jf.intel.com ([10.7.209.21]) by orsmga102.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 15 Mar 2022 10:26:47 -0700 X-IronPort-AV: E=Sophos;i="5.90,184,1643702400"; d="scan'208";a="512690836" Received: from rariley-mobl.amr.corp.intel.com (HELO [10.209.120.225]) ([10.209.120.225]) by orsmga002-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 15 Mar 2022 10:26:46 -0700 Message-ID: <2d4e8811-dce6-c891-e92d-e3746434685e@linux.intel.com> Date: Tue, 15 Mar 2022 10:26:46 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Firefox/91.0 Thunderbird/91.5.0 Subject: Re: [PATCH v2] PCI/AER: Handle Multi UnCorrectable/Correctable errors properly Content-Language: en-US To: Eric Badger References: <20220315050842.120063-1-sathyanarayanan.kuppuswamy@linux.intel.com> <20220315171425.GA1521135@ebps> From: Sathyanarayanan Kuppuswamy In-Reply-To: <20220315171425.GA1521135@ebps> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: linuxppc-dev@lists.ozlabs.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org, Oliver OHalloran , Bjorn Helgaas , linuxppc-dev@lists.ozlabs.org Errors-To: linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Sender: "Linuxppc-dev" On 3/15/22 10:14 AM, Eric Badger wrote: >> # Prep injection data for a correctable error. >> $ cd /sys/kernel/debug/apei/einj >> $ echo 0x00000040 > error_type >> $ echo 0x4 > flags >> $ echo 0x891000 > param4 >> >> # Root Error Status is initially clear >> $ setpci -s ECAP0001+0x30.w >> 0000 >> >> # Inject one error >> $ echo 1 > error_inject >> >> # Interrupt received >> pcieport : AER: Root Error Status 0001 >> >> # Inject another error (within 5 seconds) >> $ echo 1 > error_inject >> >> # No interrupt received, but "multiple ERR_COR" is now set >> $ setpci -s ECAP0001+0x30.w >> 0003 >> >> # Wait for a while, then clear ERR_COR. A new interrupt immediately >> fires. >> $ setpci -s ECAP0001+0x30.w=0x1 >> pcieport : AER: Root Error Status 0002 >> >> Currently, the above issue has been only reproduced in the ICL server >> platform. >> >> [Eric: proposed reproducing steps] > Hmm, this differs from the procedure I described on v1, and I don't > think will work as described here. I have attempted to modify the steps to reproduce it without returning IRQ_NONE for all cases (which will break the functionality). But I think I did not correct the last few steps. How about replacing the last 3 steps with following? # Inject another error (within 5 seconds) $ echo 1 > error_inject # You will get a new IRQ with only multiple ERR_COR bit set pcieport : AER: Root Error Status 0002 -- Sathyanarayanan Kuppuswamy Linux Kernel Developer