From: Paul Menzel <email@example.com> To: Bjorn Helgaas <firstname.lastname@example.org> Cc: email@example.com, Bjorn Helgaas <firstname.lastname@example.org>, email@example.com, firstname.lastname@example.org, Lukas Wunner <email@example.com> Subject: Re: pciehp 0000:00:1c.0:pcie004: Timeout on hotplug command 0x1038 (issued 65284 msec ago) Date: Tue, 8 May 2018 15:22:54 +0200 [thread overview] Message-ID: <firstname.lastname@example.org> (raw) In-Reply-To: <20180508123432.GJ161390@bhelgaas-glaptop.roam.corp.google.com> Dear Bjorn, Am 08.05.2018 um 14:34 schrieb Bjorn Helgaas: > On Tue, May 08, 2018 at 08:59:34AM +0200, Paul Menzel wrote: >> Am 07.05.2018 um 23:33 schrieb Bjorn Helgaas: >>> On Fri, May 04, 2018 at 08:33:27AM -0500, Bjorn Helgaas wrote: >>>> commit b0d6f2230e12c85ae3b65a854a53c67c7c1f6406 >>>> Author: Bjorn Helgaas <email@example.com> >>>> Date: Thu May 3 18:39:38 2018 -0500 >>>> >>>> PCI: pciehp: Add quirk for Intel Command Completed erratum >>>> The Intel CF118 erratum means the controller does not set the Command >>>> Completed bit unless writes to the Slot Command register change "Control" >>>> bits. Command Completed is never set for writes that only change software >>>> notification "Enable" bits. This results in timeouts like this: >>>> pciehp 0000:00:1c.0:pcie004: Timeout on hotplug command 0x1038 (issued 65284 msec ago) >>>> When this erratum is present, avoid these timeouts by marking commands >>>> "completed" immediately unless they change the "Control" bits. >>>> Here's the text of the erratum from the Intel document: >>>> CF118 PCIe Slot Status Register Command Completed bit not always >>>> updated on any configuration write to the Slot Control >>>> Register >>>> Problem: For PCIe root ports (devices 0 - 10) supporting hot-plug, >>>> the Slot Status Register (offset AAh) Command Completed >>>> (bit) status is updated under the following condition: >>>> IOH will set Command Completed bit after delivering the new >>>> commands written in the Slot Controller register (offset >>>> A8h) to VPP. The IOH detects new commands written in Slot >>>> Control register by checking the change of value for Power >>>> Controller Control (bit), Power Indicator Control >>>> (bits[9:8]), Attention Indicator Control (bits[7:6]), or >>>> Electromechanical Interlock Control (bit) fields. Any >>>> other configuration writes to the Slot Control register >>>> without changing the values of these fields will not cause >>>> Command Completed bit to be set. >>>> The PCIe Base Specification Revision 2.0 or later describes >>>> the “Slot Control Register” in section 7.8.10, as follows >>>> (Reference section 7.8.10, Slot Control Register, Offset >>>> 18h). In hot-plug capable Downstream Ports, a write to the >>>> Slot Control register must cause a hot-plug command to be >>>> generated (see Section 220.127.116.11 for details on hot-plug >>>> commands). A write to the Slot Control register in a >>>> Downstream Port that is not hotplug capable must not cause a >>>> hot-plug command to be executed. >>>> The PCIe Spec intended that every write to the Slot Control >>>> Register is a command and expected a command complete status >>>> to abstract the VPP implementation specific nuances from the >>>> OS software. IOH PCIe Slot Control Register implementation >>>> is not fully conforming to the PCIe Specification in this >>>> respect. >>>> Implication: Software checking on the Command Completed status after >>>> writing to the Slot Control register may time out. >>>> Workaround: Software can read the Slot Control register and compare the >>>> existing and new values to determine if it should check the >>>> Command Completed status after writing to the Slot Control >>>> register. >>>> Link: http://www.intel.com/content/www/us/en/processors/xeon/xeon-e7-v2-spec-update.html >>>> Link: https://firstname.lastname@example.org >>>> Reported-by: Paul Menzel <email@example.com> >>>> Signed-off-by: Bjorn Helgaas <firstname.lastname@example.org> >>> >>> I applied this with Paul's tested-by on pci/hotplug for v4.18. >> >> Thank you very much. Will this also be picked up by the stable Linux kernel >> series? > > I did not tag it for stable because I didn't think it was a serious enough > problem, based on this from Documentation/process/stable-kernel-rules.rst: > > - It must fix a problem that causes a build error (but not for things > marked CONFIG_BROKEN), an oops, a hang, data corruption, a real > security issue, or some "oh, that's not good" issue. In short, something > critical. > > I know I'm on the conservative end of the stable-tagging spectrum, so maybe > I could be convinced to add a stable tag. > > My impression was that this bug caused annoying messages and annoying > delays of a couple seconds during shutdown and resume. Is it more serious > than that? No, not more then that. But “oh, that’s not good” fits in my opinion. My impression was, that’s how most stable patches get in. Kind regards, Paul
next prev parent reply other threads:[~2018-05-08 13:22 UTC|newest] Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top 2018-04-26 10:17 Paul Menzel 2018-04-27 19:22 ` Bjorn Helgaas 2018-04-27 19:34 ` Sinan Kaya 2018-04-27 21:12 ` Bjorn Helgaas 2018-04-28 0:56 ` Dave Young 2018-04-28 1:18 ` Dave Young 2018-04-28 13:03 ` okaya 2018-04-30 20:48 ` Sinan Kaya 2018-04-30 21:17 ` Bjorn Helgaas 2018-04-30 21:27 ` Sinan Kaya 2018-04-30 21:38 ` Lukas Wunner 2018-05-01 12:38 ` Sinan Kaya 2018-05-01 12:59 ` Marc Zyngier 2018-05-01 13:25 ` Bjorn Helgaas 2018-05-01 16:31 ` Marc Zyngier 2018-05-01 22:32 ` Eric W. Biederman 2018-05-03 8:49 ` Paul Menzel 2018-05-04 2:45 ` Bjorn Helgaas 2018-05-04 6:37 ` okaya 2018-05-04 13:33 ` Bjorn Helgaas 2018-05-04 14:24 ` okaya 2018-05-06 9:35 ` Paul Menzel 2018-05-07 21:33 ` Bjorn Helgaas 2018-05-08 6:59 ` Paul Menzel 2018-05-08 12:34 ` Bjorn Helgaas 2018-05-08 13:22 ` Paul Menzel [this message] 2018-05-09 11:41 ` Lukas Wunner 2018-05-09 12:57 ` Bjorn Helgaas 2018-05-09 13:16 ` Lukas Wunner
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --subject='Re: pciehp 0000:00:1c.0:pcie004: Timeout on hotplug command 0x1038 (issued 65284 msec ago)' \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).