Re: [Bug 215525] New: HotPlug does not work on upstream kernel 5.17.0-rc1

From: Mariusz Tkaczyk <mariusz.tkaczyk@linux.intel.com>
To: Bjorn Helgaas <helgaas@kernel.org>
Cc: 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: Fri, 28 Jan 2022 09:29:31 +0100	[thread overview]
Message-ID: <20220128092931.00004a24@linux.intel.com> (raw)
In-Reply-To: <20220128025212.GA152555@bhelgaas>

On Thu, 27 Jan 2022 20:52:12 -0600
Bjorn Helgaas <helgaas@kernel.org> wrote:

> On Thu, Jan 27, 2022 at 03:46:15PM +0100, Mariusz Tkaczyk wrote:
> > ...
> > Thanks for your suggestions. Blazej did some tests and results were
> > inconclusive. He tested it on two same platforms. On the first one
> > it didn't work, even if he reverted all suggested patches. On the
> > second one hotplugs always worked.
> > 
> > He noticed that on first platform where issue has been found
> > initally, there was boot parameter "pci=nommconf". After adding
> > this parameter on the second platform, hotplugs stopped working too.
> > 
> > Tested on tag pci-v5.17-changes. He have CONFIG_HOTPLUG_PCI_PCIE
> > and CONFIG_DYNAMIC_DEBUG enabled in config. He also attached two
> > dmesg logs to bugzilla with boot parameter 'dyndbg="file pciehp*
> > +p" as requested. One with "pci=nommconf" and one without.
> > 
> > Issue seems to related to "pci=nommconf" and it is probably caused
> > by change outside pciehp.  
> 
> Maybe I'm missing something.  If I understand correctly, the problem
> has nothing to do with the kernel version (correct me if I'm wrong!)
> 
Hi Bjorn,

The problem occurred after the merge commit. It is some kind of
regression.

> PCIe native hotplug doesn't work when booted with "pci=nommconf".
> When using "pci=nommconf", obviously we can't access the extended PCI
> config space (offset 0x100-0xfff), so none of the extended
> capabilities are available.
> 
> In that case, we don't even ask the platform for control of PCIe
> hotplug via _OSC.  From the dmesg diff from normal (working) to
> "pci=nommconf" (not working):
> 
>   -Command line: BOOT_IMAGE=/boot/vmlinuz-smp ...
>   +Command line: BOOT_IMAGE=/boot/vmlinuz-smp pci=nommconf ...
>   ...
>   -acpi PNP0A08:00: _OSC: OS supports [ExtendedConfig ASPM ClockPM
> Segments MSI HPX-Type3] -acpi PNP0A08:00: _OSC: platform does not
> support [AER LTR] -acpi PNP0A08:00: _OSC: OS now controls
> [PCIeHotplug PME PCIeCapability] +acpi PNP0A08:00: _OSC: OS supports
> [ASPM ClockPM Segments MSI HPX-Type3] +acpi PNP0A08:00: _OSC: not
> requesting OS control; OS requires [ExtendedConfig ASPM ClockPM MSI]
> +acpi PNP0A08:00: MMCONFIG is disabled, can't access extended PCI
> configuration space under this bridge.
> 

So, it shouldn't work from years but it has been broken recently, that
is the only objection I have. Could you tell why it was working?
According to your words- it shouldn't. We are using VMD driver, is that
matter?

I already saw Jonathan's finding, we can check this. But if nommconf
stays against hotplug, is it valuable? Maybe we should accept the
regression as desired.

> Why are you using "pci=nommconf"?  As far as I know, there's no reason
> to use that except to work around some kind of defect.

It was added long time ago when it was useful, and sometimes is
returning. We need to get rid of it definitely.

Thanks,
Mariusz