public inbox for linux-pci@vger.kernel.org
 help / color / mirror / Atom feed
From: Myron Stowe <mstowe@redhat.com>
To: Lukas Wunner <lukas@wunner.de>
Cc: linux-pci@vger.kernel.org, bhelgaas@google.com, klimov.linux@gmail.com
Subject: Re: PCIe hot-plug issue: Failed to check link status
Date: Mon, 14 Sep 2020 14:08:59 -0600	[thread overview]
Message-ID: <20200914140859.3fb0db2b@zim> (raw)
In-Reply-To: <20200910132440.GA1661@wunner.de>

On Thu, 10 Sep 2020 15:24:40 +0200
Lukas Wunner <lukas@wunner.de> wrote:

> On Tue, Sep 08, 2020 at 08:57:26AM -0600, Myron Stowe wrote:
> > On a system with a Mellanox Technologies MT27800 Family [ConnectX-5]
> > NIC controller containing a power button, hot-plug fails to function
> > properly.  
> [...]
> > https://bugzilla.kernel.org/show_bug.cgi?id=209113  
> 
> Thanks for the report.
> 
> So in the dmesg output you've provided, the card is already inserted
> when the machine boots.  At 233 seconds, the Attention Button is
> pressed twice within 200 msec (the second press cancels the first).
> At 235 sec, the button is pressed again and after 5 sec the slot is
> brought down. So far so good.
> 
> At 291 sec the button is pressed but bringup of the slot fails.
> What happens here is, pciehp notices that upon the button press,
> a card is already present in the slot.  So for convenience,
> instead of waiting the full 5 sec, it attempts to bring up the slot
> immediately.  That fails because Data Link Layer Link Active isn't
> set within 1 sec.
> 
> The difference to v4.18 is that back then, pciehp waited the full
> 5 sec before bringing up the slot.
> 
> Per PCIe r4.0 sec 6.7.1.8:
> 
>     After turning power on, software must wait for a Data Link Layer
>     State Changed event, as described in Section 6.7.3.3.
> 
> And per sec 6.7.3.3:
> 
>     The Data Link Layer State Changed event must occur within 1 second
>     of the event that initiates the hot-insertion. If a power
> controller is supported, the time out interval is measured from when
> software initiated a write to the Slot Control register to turn on
> the power. [...] Software is allowed to time out on a hot add
> operation if the Data Link Layer State Changed event does not occur
> within 1 second.
> 
> So we adhere to the spec regarding the timeout between enabling power
> and waiting for DLLLA.  We do not exactly adhere to the spec regarding
> the 5 sec delay between button press and acting on it.  But I can't
> really imagine that's the problem.
> 
> As a shot in the dark, could you amend pcie_wait_for_link_delay()
> in drivers/pci/pci.c and increase the "timeout = 1000" a little?
> Maybe more than 1 sec is necessary in this case between enabling
> power and timing out for lack of a link?
> 
> The v4.18 output you've provided in the bugzilla is incomplete and
> lacks time stamps.  Could you provide it in full?

Hi Lukas,

I got back a full 'dmesg' log, with the hot-plug event included, from
the earlier, working scenario, kernel.  It's attached to the BZ as
"dmesg log of v3.10+ showing successful hot-plug event".  Note the
v3.10 basis as I was incorrect before in thinking the working case was
from a v4.18 basis. For this case, the hot-plug event starts 113
seconds in.

As for your "shot in the dark", the reporters doubled the timeout value
in pcie_wait_for_link_delay() and had positive results.  The 'dmesg'
log from that testing is also attached to the BZ as "dmesg log of
v5.8.8 with increased timeout".  So it looks as if this specific
controller is not adhering to the Data Link Layer State Changed event
within the specified time.


There was an earlier attachment of a couple of 'dmesg' logs that you
can ignore (i.e., dmesg with timestamp for RHEL...).

Myron

> 
> Thanks,
> 
> Lukas
> 


      reply	other threads:[~2020-09-14 20:09 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-08 14:57 PCIe hot-plug issue: Failed to check link status Myron Stowe
2020-09-10 13:24 ` Lukas Wunner
2020-09-14 20:08   ` Myron Stowe [this message]

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 \
    --in-reply-to=20200914140859.3fb0db2b@zim \
    --to=mstowe@redhat.com \
    --cc=bhelgaas@google.com \
    --cc=klimov.linux@gmail.com \
    --cc=linux-pci@vger.kernel.org \
    --cc=lukas@wunner.de \
    /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
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox