Received: by 2002:a05:6a10:413:0:0:0:0 with SMTP id 19csp403644pxp; Wed, 16 Mar 2022 08:08:27 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyTdqoRuaykDAnYqDA1V6jnYqusmdHGkAo52mtfMAOzdAY3bBuF89jyJIRTfke+2DigKPYe X-Received: by 2002:a17:902:9348:b0:14e:ec3d:2baa with SMTP id g8-20020a170902934800b0014eec3d2baamr388917plp.107.1647443306915; Wed, 16 Mar 2022 08:08:26 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1647443306; cv=none; d=google.com; s=arc-20160816; b=DSPIEwalS3yYMQS/wBIQyeWjaAwjqNH2zm0wt4lOti1mqT6kxFONQ7q2qMhd5EbJk/ RnJUTSP0qNQRgwbsapHZf1g4MbvOJ0uJFC5EFwlh5xre1q/sKGO+DiF/TD0pAeCJE2+O ciwdutJAujWIyqQEVP9+CwNmZ4aFWnKLiHr/v5eum8usXVYKb737jEiuN9R2oNwryCfx 4nVwBk6pNXJXngGPN3Y6JUyiZHmDo3fgaGwMenbNGWGlGlau7LUILbDRtlcIQu2viaLr TXkmlAy3Qe5WKnhCSS0TTBcoUVT8hIhBFa5MQbR5IxGdcwpDAcujf1Ce6qkN3rb7Ry3W uaQQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to:from :references:cc:to:content-language:subject:user-agent:mime-version :date:message-id:dkim-signature; bh=iFaKBItu3kudCNhOlRagPPSprzhkgJAjRGmvvNIrNBM=; b=cJeVf7r3+ye1LFCSc7qqOWF/6THviaJ2ka8d4SDmow3z8cG3LEFIgvUc0p34cGTh/l /cY5Rs/iR9Bc5KVbBnLZecs45kwWP4dEentm6aSglOmfNVydt6YS9IWk5ZjUNl4a7PKW 4hiMGK8VZq3R5eDVzc35AvyzuaxfFOFJSR/B+6NJzeO8rh3Mzrxa3jfh2c8URjDwAemm p/Tw8RnHxO/lEJD/EHaoXkEITXyo7WmQMrjT+gl3cz9Qcb3dyEnAInE81oe8CCUPUwLl jCDTUOdkWiIL9wTXN4LLEuChsjIWZMulOTakozIMypnhhE8HwTBb+xm4jnNNwGlVSDXE o4tA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b="ElKfy/Iu"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id 19-20020aa79153000000b004fa2c8b07b3si723106pfi.329.2022.03.16.08.08.10; Wed, 16 Mar 2022 08:08:26 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b="ElKfy/Iu"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S244849AbiCOVai (ORCPT + 99 others); Tue, 15 Mar 2022 17:30:38 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:36302 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233018AbiCOVah (ORCPT ); Tue, 15 Mar 2022 17:30:37 -0400 Received: from mga04.intel.com (mga04.intel.com [192.55.52.120]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A8CF31BEB1; Tue, 15 Mar 2022 14:29:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1647379764; x=1678915764; h=message-id:date:mime-version:subject:to:cc:references: from:in-reply-to:content-transfer-encoding; bh=A7BNzJil5UVOdacWFDYWEMOTLH+DuBVapnx31WlTQXY=; b=ElKfy/Iu4/s7abPLQTIeEQBXsrWkgyh6N8XY1/dvQjCfwSdJwth58+Np VRb/ifXZ9FnCKUqmTvQGybKv7uWlA+aXFtD7RQeCXuHMjWNOiKL3TiYMM LTt95iszkV0yFIHpwPiWDkJaL/Yv/WdqhGIijKegPhBOUjyvfA/+PGX3q bOf2KPq2MbibTq2wS/U9xEXLeYlrGS1VicSnh87t1LvBrFQSGarxT1WaO qgoc7odbymN4mgMuKLUyxJXC52NVk51V38Vgt7MkaXcAU1xxXvLGijk+y F7KnmAoIdP1quq1KPwJZ+R1Dsqd8K4srNJIqsEwlAeZRlpN6cqCX0gcdg g==; X-IronPort-AV: E=McAfee;i="6200,9189,10286"; a="255256380" X-IronPort-AV: E=Sophos;i="5.90,184,1643702400"; d="scan'208";a="255256380" Received: from orsmga002.jf.intel.com ([10.7.209.21]) by fmsmga104.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 15 Mar 2022 14:29:24 -0700 X-IronPort-AV: E=Sophos;i="5.90,184,1643702400"; d="scan'208";a="512767160" 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 14:29:23 -0700 Message-ID: Date: Tue, 15 Mar 2022 14:29:23 -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> <2d4e8811-dce6-c891-e92d-e3746434685e@linux.intel.com> <20220315195255.GA1523195@ebps> From: Sathyanarayanan Kuppuswamy In-Reply-To: <20220315195255.GA1523195@ebps> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-5.8 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_EF,NICE_REPLY_A,RCVD_IN_DNSWL_MED, SPF_HELO_NONE,SPF_NONE,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 3/15/22 12:52 PM, Eric Badger wrote: > On Tue, Mar 15, 2022 at 10:26:46AM -0700, Sathyanarayanan Kuppuswamy wrote: >> 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. > > Well, the thinking in always returning IRQ_NONE was so that only setpci > modified the register and we could clearly see how writes to the > register affect interrupt generation. Got it. Makes sense. > >> 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 > > This seems accurate. Though it does muddy a detail that I think was > clearer in the original procedure: was the second interrupt triggered by > the second error, or by the write of 0x1 to Root Error Status? I think you are talking about the following command, right? setpci -s ECAP0001+0x30.w=0x1 If yes, my previously modified instructions already removed it. So no confusion. To summarize, In your case, you have controlled both register read/write of Root error status register to simulate the interrupt with only multi ERR_COR bit set. In my case, I have attempted to simulate it without changing the default behavior of aer_irq() in the kernel. Both seem ok to me. Although my personal preference is to trigger the error without changing the code behavior, if both you and Bjorn prefer to revert to old instructions, I will fix this in the next version. > > Cheers, > Eric -- Sathyanarayanan Kuppuswamy Linux Kernel Developer