Received: by 2002:a25:e74b:0:0:0:0:0 with SMTP id e72csp2226066ybh; Fri, 24 Jul 2020 07:33:23 -0700 (PDT) X-Google-Smtp-Source: ABdhPJycyWPPEI4TeKrpkp5foFuPFUSs/L4uBMDSkK2YcWtZjpdp0agdwtV7LEyrxSGYuAJU4Gp9 X-Received: by 2002:a17:906:7698:: with SMTP id o24mr2880791ejm.182.1595601203031; Fri, 24 Jul 2020 07:33:23 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1595601203; cv=none; d=google.com; s=arc-20160816; b=R+DOB4Ni5bkaW9vySA145eJ4WUlZJ4WjUDmI33p2yu/FFgTRiLurSZagRVanKJxHQM TfPR5Nz+p/ooXSE50rVio2H7HJFlTw50CM2aigMy+00ANBszbZnwsNb+BYomxB+Exi8X JJqc2I600PGcYEPEVmvTrnMooUkJIJNdQCODB9Vf61W82O0tG3Mj6WzQGEsaWzpGbji9 J8wfoiEsW5pAxAOBc32vXzz8CSTwa6PeHVqifS1tC0PF1EDGrxbxDG3wg2OHrjBo6WQ/ VgA0FUNOzbqopLtIiYqlr0AJUh0Tpg7rb3i9kHjoOj7Em1jiifglUME1pY4cDah6hiqx KmFA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:to:references:message-id :content-transfer-encoding:cc:date:in-reply-to:from:subject :mime-version; bh=SolB7n0+L56NXudwxIlZ9H7h5bfmulyTdq89n4TkuVs=; b=xlslmPHljOtRZn/xF8DBWFUf6luOYsdJCOUiyRCazpIChPyQB0ghFff0NhQqJQ+SbX i31ceOZWZxyNQmeu1KET5tQriIGqtJzpgyoucXQrDcqP+GBoYy5hIXokh2PsTmJ7i66h BeDnm9pj17qZhhhsOiaDaOOgpHIeskK3VGMvcTJsITMkIqMsiBgi+uD1R3hZHXWqALMy iSowC8DwfPYPiIMOiD6cbRK7/oxsUd5ot/QsXQbjmXX7LEqDgthdTzuh54IhreSPjy0U 0nsm7H+5fI/Qr28OtlyULA15RGAlsUI3IoNMuSTOShaIgrVnCEKcp/B5SboSdgVMY/pB NHSg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=canonical.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id d3si622231edn.145.2020.07.24.07.33.00; Fri, 24 Jul 2020 07:33:23 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=canonical.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726870AbgGXOcM convert rfc822-to-8bit (ORCPT + 99 others); Fri, 24 Jul 2020 10:32:12 -0400 Received: from youngberry.canonical.com ([91.189.89.112]:38349 "EHLO youngberry.canonical.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726814AbgGXOcM (ORCPT ); Fri, 24 Jul 2020 10:32:12 -0400 Received: from mail-pf1-f199.google.com ([209.85.210.199]) by youngberry.canonical.com with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.86_2) (envelope-from ) id 1jyyk5-000597-Lz for linux-kernel@vger.kernel.org; Fri, 24 Jul 2020 14:32:09 +0000 Received: by mail-pf1-f199.google.com with SMTP id w4so6382102pfq.11 for ; Fri, 24 Jul 2020 07:32:09 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=OY6zbYqXoDNfg1vkCWS7IkbQH43ot9XbU/fDyuAMUME=; b=jjazPLXL2oXV7a47tJqPK0HZV5HP0UZBgyPJwJH0QZd54y/Okg727TDZ9uAzekNTF4 VymTuEkIZovQ8YqM8JyuXQu2GYHyItHYdZBfDwToDIhXfFst9ValuBiL3PONu29VxlTD CZT8ZZ783MD/pRww7OLG7eWsYb79Iu/Z6dNRxyjWPvn5xmmNkosvHxJvL02xRQ6MAjG4 nwHUeOeKmmHs1QG1NvldXSCxVMrMDAOkeEbP9zJuDk30lnMFk0XnPJwF/X1fVo++SMtu Pnn6stuhhcrDP4BWSp20XFEqBrPH7Et7kR40a6mlWFiUK4nWTAY42PcenQ7R2oV/SWVp /nOQ== X-Gm-Message-State: AOAM530IWIv0jEXj8ysnxGrxnPxyIglq16DwNrJ0ctHhTrwivSbFVWga dzZGBWxWavDKIzDFHtVRIn4xL86QLvbrO5RSB9tga21Ca05K+HeN56W0spm/8Hb/FzYwXWtyPCf oM0TJIN0LPmxkLGo2H6vg3jTKte0xxI3HbSWF8XiwVA== X-Received: by 2002:aa7:8e90:: with SMTP id a16mr8853492pfr.84.1595601128058; Fri, 24 Jul 2020 07:32:08 -0700 (PDT) X-Received: by 2002:aa7:8e90:: with SMTP id a16mr8853466pfr.84.1595601127681; Fri, 24 Jul 2020 07:32:07 -0700 (PDT) Received: from [192.168.1.208] (220-133-187-190.HINET-IP.hinet.net. [220.133.187.190]) by smtp.gmail.com with ESMTPSA id n9sm6136816pjo.53.2020.07.24.07.32.06 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 24 Jul 2020 07:32:07 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) Subject: Re: 5.7 regression: Lots of PCIe AER errors and suspend failure without pcie=noaer From: Kai-Heng Feng In-Reply-To: Date: Fri, 24 Jul 2020 22:32:05 +0800 Cc: linux-kernel , "open list:PCI SUBSYSTEM" , Bjorn Helgaas Content-Transfer-Encoding: 8BIT Message-Id: <87CA0F2C-5CEB-4CE7-8399-534CABE5ADD8@canonical.com> References: To: Robert Hancock X-Mailer: Apple Mail (2.3608.120.23.2.1) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Robert, > On Jul 22, 2020, at 07:55, Robert Hancock wrote: > > On Fri, Jul 10, 2020 at 6:28 PM Robert Hancock wrote: >> >> On Fri, Jul 10, 2020 at 6:23 PM Robert Hancock wrote: >>> >>> Noticed a problem on my desktop with an Asus PRIME H270-PRO >>> motherboard after Fedora 32 upgraded to the 5.7 kernel (now on 5.7.8): >>> periodically there are PCIe AER errors getting spewed in dmesg that >>> weren't happening before, and this also seems to causes suspend to >>> fail - the system just wakes back up again right away, I am assuming >>> due to some AER errors interrupting the process. 5.6 kernels didn't >>> have this problem. Setting "pcie=noaer" on the kernel command line >>> works around the issue, but I'm not sure what would have changed to >>> trigger this to occur? >> >> Correction: the workaround option is "pci=noaer". > > As a follow-up, from some more experimentation, it appears that > disabling PCIe ASPM with setpci on both the ASMedia PCIe-PCI bridge as > well as the PCIe root port it is connected to seems to silence the AER > errors and allow suspend/resume to work again: > > setpci -s 00:1c.0 0x50.B=0x00 > setpci -s 02:00.0 0x90.B=0x00 > > It appears the behavior changed as a result of this patch (which went > into the stable tree for 5.7.6 and so affects 5.7 kernels as well): > > commit 66ff14e59e8a30690755b08bc3042359703fb07a > Author: Kai-Heng Feng > Date: Wed May 6 01:34:21 2020 +0800 > > PCI/ASPM: Allow ASPM on links to PCIe-to-PCI/PCI-X Bridges > > 7d715a6c1ae5 ("PCI: add PCI Express ASPM support") added the ability for > Linux to enable ASPM, but for some undocumented reason, it didn't enable > ASPM on links where the downstream component is a PCIe-to-PCI/PCI-X Bridge. > > Remove this exclusion so we can enable ASPM on these links. > > The Dell OptiPlex 7080 mentioned in the bugzilla has a TI XIO2001 > PCIe-to-PCI Bridge. Enabling ASPM on the link leading to it allows the > Intel SoC to enter deeper Package C-states, which is a significant power > savings. > > [bhelgaas: commit log] > Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=207571 > Link: https://lore.kernel.org/r/20200505173423.26968-1-kai.heng.feng@canonical.com > Signed-off-by: Kai-Heng Feng > Signed-off-by: Bjorn Helgaas > Reviewed-by: Mika Westerberg > > Unfortunately it appears that this ASMedia PCIe-PCI bridge: > > 02:00.0 PCI bridge [0604]: ASMedia Technology Inc. ASM1083/1085 PCIe > to PCI Bridge [1b21:1080] (rev 04) > > doesn't cope with ASPM properly and causes a bunch of PCIe link > errors. (This is in addition to some broken-ness known as far back as > 2012 with these ASM1083/1085 chips with regard to PCI interrupts > getting stuck, but this ASPM problem causes issues even if no devices > are connected to the PCI side of the bridge, as is the case on my > system.) > > Might need a quirk to disable ASPM on this device? Yes I think it's a great idea to do it. Can you please file a bug on [1] and we can continue our discussion there. [1] https://bugzilla.kernel.org Kai-Heng