* Re: Issue with 395f121e6199 ("PCI/PM: Wait for device to become ready after power-on") [not found] <20191127153433.GA2665@lahna.fi.intel.com> @ 2019-11-28 8:23 ` Mika Westerberg 2019-11-28 14:59 ` Bjorn Helgaas 0 siblings, 1 reply; 3+ messages in thread From: Mika Westerberg @ 2019-11-28 8:23 UTC (permalink / raw) To: Vidya Sagar, Bjorn Helgaas; +Cc: linux-pci Hi, For some reason I don't see this in linux-pci archives. Maybe it was not accepted because of the attachment? In any case the full dmesg can be found here as well: https://gist.github.com/westeri/ca2574a4e48dc6e3eb76184922e103e5 On Wed, Nov 27, 2019 at 05:34:37PM +0200, Mika Westerberg wrote: > Hi, > > I noticed that latest Bjorn's pci/pm branch breaks native PCIe hotplug > so that when I unplug a device (connected over TBT) the pciehp notices > it but then the core PCI code starts waiting for all the devices that > are now gone: > > [ 160.344476] pcieport 0000:04:04.0: pciehp: pciehp_check_link_active: lnk_status = 5041 > [ 160.344531] pcieport 0000:04:04.0: pciehp: Slot(4): Card not present > [ 160.346004] pcieport 0000:04:04.0: pciehp: pciehp_unconfigure_device: domain:bus:dev = 0000:3a:00 > [ 161.421569] pcieport 0000:3a:00.0: not ready 1023ms after Switch to D0; waiting > [ 162.509610] pcieport 0000:3a:00.0: not ready 2047ms after Switch to D0; waiting > [ 164.621620] pcieport 0000:3a:00.0: not ready 4095ms after Switch to D0; waiting > [ 169.165529] pcieport 0000:3a:00.0: not ready 8191ms after Switch to D0; waiting > [ 177.869521] pcieport 0000:3a:00.0: not ready 16383ms after Switch to D0; waiting > [ 194.765581] pcieport 0000:3a:00.0: not ready 32767ms after Switch to D0; waiting > ... > > It seems to continue forever so the devices are not removed from the > system. > > The test system used here is Dell XPS 9380 but it happens also on other > systems that support native PCIe hotplug. > > Reverting 395f121e6199 ("PCI/PM: Wait for device to become ready after > power-on") makes the problem go away. > > I've attached full dmesg from the system. The way I reproduce this is > that I boot the system up (no device connected yet), the I connect TBT > dock that includes the PCIe switch etc. Then I unplug the dock. The > unplug happens around 160.335355 in the dmesg. ^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Issue with 395f121e6199 ("PCI/PM: Wait for device to become ready after power-on") 2019-11-28 8:23 ` Issue with 395f121e6199 ("PCI/PM: Wait for device to become ready after power-on") Mika Westerberg @ 2019-11-28 14:59 ` Bjorn Helgaas 2019-11-28 15:01 ` Mika Westerberg 0 siblings, 1 reply; 3+ messages in thread From: Bjorn Helgaas @ 2019-11-28 14:59 UTC (permalink / raw) To: Mika Westerberg; +Cc: Vidya Sagar, linux-pci On Thu, Nov 28, 2019 at 10:23:14AM +0200, Mika Westerberg wrote: > Hi, > > For some reason I don't see this in linux-pci archives. Maybe it was not > accepted because of the attachment? In any case the full dmesg can be > found here as well: > > https://gist.github.com/westeri/ca2574a4e48dc6e3eb76184922e103e5 > > On Wed, Nov 27, 2019 at 05:34:37PM +0200, Mika Westerberg wrote: > > Hi, > > > > I noticed that latest Bjorn's pci/pm branch breaks native PCIe hotplug > > so that when I unplug a device (connected over TBT) the pciehp notices > > it but then the core PCI code starts waiting for all the devices that > > are now gone: > > > > [ 160.344476] pcieport 0000:04:04.0: pciehp: pciehp_check_link_active: lnk_status = 5041 > > [ 160.344531] pcieport 0000:04:04.0: pciehp: Slot(4): Card not present > > [ 160.346004] pcieport 0000:04:04.0: pciehp: pciehp_unconfigure_device: domain:bus:dev = 0000:3a:00 > > [ 161.421569] pcieport 0000:3a:00.0: not ready 1023ms after Switch to D0; waiting > > [ 162.509610] pcieport 0000:3a:00.0: not ready 2047ms after Switch to D0; waiting > > [ 164.621620] pcieport 0000:3a:00.0: not ready 4095ms after Switch to D0; waiting > > [ 169.165529] pcieport 0000:3a:00.0: not ready 8191ms after Switch to D0; waiting > > [ 177.869521] pcieport 0000:3a:00.0: not ready 16383ms after Switch to D0; waiting > > [ 194.765581] pcieport 0000:3a:00.0: not ready 32767ms after Switch to D0; waiting > > ... > > > > It seems to continue forever so the devices are not removed from the > > system. > > > > The test system used here is Dell XPS 9380 but it happens also on other > > systems that support native PCIe hotplug. > > > > Reverting 395f121e6199 ("PCI/PM: Wait for device to become ready after > > power-on") makes the problem go away. > > > > I've attached full dmesg from the system. The way I reproduce this is > > that I boot the system up (no device connected yet), the I connect TBT > > dock that includes the PCIe switch etc. Then I unplug the dock. The > > unplug happens around 160.335355 in the dmesg. Thanks for testing this. I dropped 395f121e6199 ("PCI/PM: Wait for device to become ready after power-on") for now. We can sort this out for v5.6. ^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Issue with 395f121e6199 ("PCI/PM: Wait for device to become ready after power-on") 2019-11-28 14:59 ` Bjorn Helgaas @ 2019-11-28 15:01 ` Mika Westerberg 0 siblings, 0 replies; 3+ messages in thread From: Mika Westerberg @ 2019-11-28 15:01 UTC (permalink / raw) To: Bjorn Helgaas; +Cc: Vidya Sagar, linux-pci On Thu, Nov 28, 2019 at 08:59:21AM -0600, Bjorn Helgaas wrote: > On Thu, Nov 28, 2019 at 10:23:14AM +0200, Mika Westerberg wrote: > > Hi, > > > > For some reason I don't see this in linux-pci archives. Maybe it was not > > accepted because of the attachment? In any case the full dmesg can be > > found here as well: > > > > https://gist.github.com/westeri/ca2574a4e48dc6e3eb76184922e103e5 > > > > On Wed, Nov 27, 2019 at 05:34:37PM +0200, Mika Westerberg wrote: > > > Hi, > > > > > > I noticed that latest Bjorn's pci/pm branch breaks native PCIe hotplug > > > so that when I unplug a device (connected over TBT) the pciehp notices > > > it but then the core PCI code starts waiting for all the devices that > > > are now gone: > > > > > > [ 160.344476] pcieport 0000:04:04.0: pciehp: pciehp_check_link_active: lnk_status = 5041 > > > [ 160.344531] pcieport 0000:04:04.0: pciehp: Slot(4): Card not present > > > [ 160.346004] pcieport 0000:04:04.0: pciehp: pciehp_unconfigure_device: domain:bus:dev = 0000:3a:00 > > > [ 161.421569] pcieport 0000:3a:00.0: not ready 1023ms after Switch to D0; waiting > > > [ 162.509610] pcieport 0000:3a:00.0: not ready 2047ms after Switch to D0; waiting > > > [ 164.621620] pcieport 0000:3a:00.0: not ready 4095ms after Switch to D0; waiting > > > [ 169.165529] pcieport 0000:3a:00.0: not ready 8191ms after Switch to D0; waiting > > > [ 177.869521] pcieport 0000:3a:00.0: not ready 16383ms after Switch to D0; waiting > > > [ 194.765581] pcieport 0000:3a:00.0: not ready 32767ms after Switch to D0; waiting > > > ... > > > > > > It seems to continue forever so the devices are not removed from the > > > system. > > > > > > The test system used here is Dell XPS 9380 but it happens also on other > > > systems that support native PCIe hotplug. > > > > > > Reverting 395f121e6199 ("PCI/PM: Wait for device to become ready after > > > power-on") makes the problem go away. > > > > > > I've attached full dmesg from the system. The way I reproduce this is > > > that I boot the system up (no device connected yet), the I connect TBT > > > dock that includes the PCIe switch etc. Then I unplug the dock. The > > > unplug happens around 160.335355 in the dmesg. > > Thanks for testing this. I dropped 395f121e6199 ("PCI/PM: Wait for > device to become ready after power-on") for now. We can sort this out > for v5.6. Thanks! ^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2019-11-28 15:01 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <20191127153433.GA2665@lahna.fi.intel.com>
2019-11-28 8:23 ` Issue with 395f121e6199 ("PCI/PM: Wait for device to become ready after power-on") Mika Westerberg
2019-11-28 14:59 ` Bjorn Helgaas
2019-11-28 15:01 ` Mika Westerberg
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.