All of lore.kernel.org
 help / color / mirror / Atom feed
From: Bjorn Helgaas <helgaas@kernel.org>
To: Blazej Kucman <blazej.kucman@linux.intel.com>
Cc: Kai-Heng Feng <kai.heng.feng@canonical.com>,
	Mariusz Tkaczyk <mariusz.tkaczyk@linux.intel.com>,
	linux-pci@vger.kernel.org,
	Blazej Kucman <blazej.kucman@intel.com>,
	Hans de Goede <hdegoede@redhat.com>,
	Lukas Wunner <lukas@wunner.de>,
	Naveen Naidu <naveennaidu479@gmail.com>,
	Keith Busch <kbusch@kernel.org>,
	Nirmal Patel <nirmal.patel@linux.intel.com>,
	Jonathan Derrick <jonathan.derrick@linux.dev>
Subject: Re: [Bug 215525] New: HotPlug does not work on upstream kernel 5.17.0-rc1
Date: Thu, 3 Feb 2022 09:58:04 -0600	[thread overview]
Message-ID: <20220203155804.GA97933@bhelgaas> (raw)
In-Reply-To: <20220203114709.00000fd1@linux.intel.com>

On Thu, Feb 03, 2022 at 11:47:09AM +0100, Blazej Kucman wrote:
> > > On Wed, Feb 02, 2022 at 04:48:01PM +0100, Blazej Kucman wrote:  
> > >> On Fri, 28 Jan 2022 08:03:28 -0600
> > >> Bjorn Helgaas <helgaas@kernel.org> wrote:  
> > >>>> On Fri, Jan 28, 2022 at 9:08 PM Bjorn Helgaas
> > >>>> <helgaas@kernel.org> wrote:    

> > >>>>> 04b12ef163d1 ("PCI: vmd: Honor ACPI _OSC on PCIe features")
> > >>>>> looks like a it could be related.  Try reverting that commit
> > >>>>> and see whether it makes a difference.    
> > >>>>
> > >>>> The affected NVMe is indeed behind VMD domain, so I think the
> > >>>> commit can make a difference.
> > >>>>
> > >>>> Does VMD behave differently on laptops and servers?
> > >>>> Anyway, I agree that the issue really lies in "pci=nommconf".    
> > >>>
> > >>> Oh, I have a guess:
> > >>>
> > >>>   - With "pci=nommconf", prior to v5.17-rc1, pciehp did not work
> > >>> in general, but *did* work for NVMe behind a VMD.  As of
> > >>> v5.17-rc1, pciehp no longer works for NVMe behind VMD.
> > >>>
> > >>>   - Without "pci=nommconf", pciehp works as expected for all
> > >>> devices including NVMe behind VMD, both before and after
> > >>> v5.17-rc1.
> > >>>
> > >>> Is that what you're observing?
> > >>>
> > >>> If so, I doubt there's anything to fix other than getting rid of
> > >>> "pci=nommconf".  
> > >>
> > >> I haven't tested with VMD disabled earlier. I verified it and my
> > >> observations are as follows:
> > >>
> > >> OS: RHEL 8.4
> > >> NO - hotplug not working
> > >> YES - hotplug working
> > >>
> > >> pci=nommconf added:
> > >> +--------------+-------------------+---------------------+--------------+
> > >> |              | pci-v5.17-changes | revert-04b12ef163d1 | inbox
> > >> kernel
> > >> +--------------+-------------------+---------------------+--------------+
> > >> | VMD enabled  | NO                | YES                 | YES
> > >> +--------------+-------------------+---------------------+--------------+
> > >> | VMD disabled | NO                | NO                  | NO
> > >> +--------------+-------------------+---------------------+--------------+

OK, so the only possible problem case is that booting with VMD enabled
and "pci=nommconf".  In that case, hotplug for devices below VMD
worked before 04b12ef163d1 and doesn't work after.

Your table doesn't show it, but hotplug for devices *not* behind VMD
should not work either before or after 04b12ef163d1 because Linux
doesn't request PCIe hotplug control when booting with "pci=nommconf".

Why were you testing with "pci=nommconf"?  Do you think anybody uses
that with VMD and NVMe?

Bjorn

  reply	other threads:[~2022-02-03 15:58 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <bug-215525-41252@https.bugzilla.kernel.org/>
2022-01-24 21:46 ` [Bug 215525] New: HotPlug does not work on upstream kernel 5.17.0-rc1 Bjorn Helgaas
2022-01-25  8:58   ` Hans de Goede
2022-01-25 15:33   ` Lukas Wunner
2022-01-26  7:31   ` Thorsten Leemhuis
2022-02-02 19:22     ` Lukas Wunner
2022-01-27 14:46   ` Mariusz Tkaczyk
2022-01-27 20:47     ` Jonathan Derrick
2022-01-27 22:31     ` Jonathan Derrick
2022-01-28  2:52     ` Bjorn Helgaas
2022-01-28  8:29       ` Mariusz Tkaczyk
2022-01-28 13:08         ` Bjorn Helgaas
2022-01-28 13:49           ` Kai-Heng Feng
2022-01-28 14:03             ` Bjorn Helgaas
2022-02-02 15:48               ` Blazej Kucman
2022-02-02 16:43                 ` Bjorn Helgaas
2022-02-03  9:13                   ` Thorsten Leemhuis
2022-02-03 10:47                     ` Blazej Kucman
2022-02-03 15:58                       ` Bjorn Helgaas [this message]
2022-02-09 13:41                         ` Blazej Kucman
2022-02-09 21:02                           ` Bjorn Helgaas
2022-02-10 11:14                             ` Blazej Kucman

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=20220203155804.GA97933@bhelgaas \
    --to=helgaas@kernel.org \
    --cc=blazej.kucman@intel.com \
    --cc=blazej.kucman@linux.intel.com \
    --cc=hdegoede@redhat.com \
    --cc=jonathan.derrick@linux.dev \
    --cc=kai.heng.feng@canonical.com \
    --cc=kbusch@kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=lukas@wunner.de \
    --cc=mariusz.tkaczyk@linux.intel.com \
    --cc=naveennaidu479@gmail.com \
    --cc=nirmal.patel@linux.intel.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.