Message ID | 8389318.FWd8nDZBjU@al (mailing list archive) |
---|---|
State | Not Applicable, archived |
Headers | show |
On Friday, February 07, 2014 02:43:03 PM Peter Wu wrote: > On Friday 07 February 2014 00:48:14 Rafael J. Wysocki wrote: > > On Friday, February 07, 2014 12:27:03 AM you wrote: > > [...] > > > > > [ 49.170694] video LNXVIDEO:01: Restoring backlight state > > > [ 49.644845] ACPI: \_SB_.AC__: ACPI_NOTIFY_BUS_CHECK event: unsupported > > > [ 49.646671] jme 0000:04:00.5: irq 50 for MSI/MSI-X > > > [ 49.671645] jme 0000:04:00.5 eth0: Link is down > > > > Well, this means that Ethernet device is present after the resume. > > Right, but it is gone when I check it (lspci). Here is the original > journal with dates and machine name stripped from the left (2 seconds): [...] > --- lspci-nnvvv.txt 2014-02-06 17:11:02.867233563 +0100 > +++ lspci-nnvvv2.txt 2014-02-06 17:11:22.603425311 +0100 > @@ -86,17 +86,17 @@ > 00:1c.1 PCI bridge [0604]: Intel Corporation 5 Series/3400 Series Chipset PCI Express Root Port 2 [8086:3b44] (rev 05) (prog-if 00 [Normal decode]) > Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx- > Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- > Latency: 0, Cache Line Size: 64 bytes > Bus: primary=00, secondary=04, subordinate=04, sec-latency=0 > I/O behind bridge: 00004000-00004fff > Memory behind bridge: fd400000-fd4fffff > Prefetchable memory behind bridge: 00000000c0000000-00000000c01fffff > - Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- <SERR- <PERR- > + Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort+ <SERR- <PERR- > BridgeCtl: Parity- SERR- NoISA+ VGA- MAbort- >Reset- FastB2B- > PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn- > Capabilities: <access denied> > Kernel driver in use: pcieport > Kernel modules: shpchp > > 00:1c.2 PCI bridge [0604]: Intel Corporation 5 Series/3400 Series Chipset PCI Express Root Port 3 [8086:3b46] (rev 05) (prog-if 00 [Normal decode]) > Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx- > @@ -200,60 +200,16 @@ > Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- > Latency: 0, Cache Line Size: 64 bytes > Interrupt: pin A routed to IRQ 16 > Region 0: Memory at fc000000 (64-bit, non-prefetchable) [size=8K] > Capabilities: <access denied> > Kernel driver in use: xhci_hcd > Kernel modules: xhci_hcd > > -04:00.0 System peripheral [0880]: JMicron Technology Corp. SD/MMC Host Controller [197b:2382] (rev 80) > - Subsystem: CLEVO/KAPOK Computer Device [1558:7130] > - Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx- > - Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- > - Latency: 0, Cache Line Size: 64 bytes > - Interrupt: pin B routed to IRQ 18 > - Region 0: Memory at fd404000 (32-bit, non-prefetchable) [size=256] > - Capabilities: <access denied> > - Kernel driver in use: sdhci-pci > - Kernel modules: sdhci_pci > - > -04:00.2 SD Host controller [0805]: JMicron Technology Corp. Standard SD Host Controller [197b:2381] (rev 80) (prog-if 01) > - Subsystem: CLEVO/KAPOK Computer Device [1558:7130] > - Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx- > - Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- > - Interrupt: pin B routed to IRQ 18 > - Region 0: Memory at fd405000 (32-bit, non-prefetchable) [size=256] > - Capabilities: <access denied> > - Kernel modules: sdhci_pci > - > -04:00.3 System peripheral [0880]: JMicron Technology Corp. MS Host Controller [197b:2383] (rev 80) > - Subsystem: CLEVO/KAPOK Computer Device [1558:7130] > - Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx- > - Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- > - Latency: 0, Cache Line Size: 64 bytes > - Interrupt: pin C routed to IRQ 19 > - Region 0: Memory at fd406000 (32-bit, non-prefetchable) [size=256] > - Capabilities: <access denied> > - Kernel driver in use: jmb38x_ms > - Kernel modules: jmb38x_ms > - > -04:00.5 Ethernet controller [0200]: JMicron Technology Corp. JMC250 PCI Express Gigabit Ethernet Controller [197b:0250] (rev 03) > - Subsystem: CLEVO/KAPOK Computer Device [1558:7130] > - Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx+ > - Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- > - Latency: 0, Cache Line Size: 64 bytes > - Interrupt: pin B routed to IRQ 50 > - Region 0: Memory at fd400000 (32-bit, non-prefetchable) [size=16K] > - Region 2: I/O ports at 4400 [size=128] > - Region 3: I/O ports at 4000 [size=256] > - Capabilities: <access denied> > - Kernel driver in use: jme > - Kernel modules: jme > - > 05:00.0 Network controller [0280]: Intel Corporation Centrino Advanced-N 6200 [8086:422c] (rev 35) > Subsystem: Intel Corporation Centrino Advanced-N 6200 2x2 AGN [8086:1301] > Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx+ > Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- > Latency: 0, Cache Line Size: 64 bytes > Interrupt: pin A routed to IRQ 49 > Region 0: Memory at fd500000 (64-bit, non-prefetchable) [size=8K] > Capabilities: <access denied> > > > I forgot to mention a workaround, by triggering a rescan, the > devices become alive again. Here is a log from 3.12.7 (different > from the above): > > sudo tee /sys/devices/pci0000:00/0000:00:1c.1/rescan <<<1 > > The journal following the above command (duration of 2 seconds): OK It looks like we fail to resume the device, then, for some reason. That may be a PCIe link issue or something similar. Is this a regression for you? If so, what's the last kernel that didn't have this problem? Does 3.13.y (as released by Greg, without and distro "improvements") have it too? Rafael -- To unsubscribe from this list: send the line "unsubscribe linux-pm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Saturday 08 February 2014 16:01:36 Rafael J. Wysocki wrote: > It looks like we fail to resume the device, then, for some reason. > > That may be a PCIe link issue or something similar. > > Is this a regression for you? If so, what's the last kernel that didn't > have this problem? Does 3.13.y (as released by Greg, without and distro > "improvements") have it too? It was a regression from 3.11.x to 3.12 (and it is still broken with 3.13). Due to some mistakes from my side, I have tested more configs: (based on Arch Linux 3.13.1 x86_64 config) (a) 3.13.2 with CONFIG_HOTPLUG_PCI=y, but CONFIG_HOTPLUG_PCI_ACPI=n works. (b) 3.13.2 with CONFIG_HOTPLUG_PCI=y and CONFIG_HOTPLUG_PCI_ACPI=y is broken. (c) 3.13.2 with CONFIG_HOTPLUG_PCI=n still works. (my stripped config) (d) 3.13.2 with CONFIG_HOTPLUG_PCI=y, but CONFIG_HOTPLUG_PCI_ACPI=n works. With CONFIG_HOTPLUG_PCI_ACPI=y, the only difference in dmesg is: (during boot) acpiphp: ACPI Hot Plug PCI Controller Driver version: 0.5 (after resume) iwlwifi 0000:05:00.0: no hotplug settings from platform xhci_hcd 0000:02:00.0: no hotplug settings from platform (here, NetworkManager complains that a device has gone) iwlwifi 0000:05:00.0: no hotplug settings from platform Of course, with config (b), the ethernet adapter vanishes while it is still present with configs (a), (c) and (d). Time to do a bisect? Peter -- To unsubscribe from this list: send the line "unsubscribe linux-pm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Saturday, February 08, 2014 10:34:23 PM Peter Wu wrote: > On Saturday 08 February 2014 16:01:36 Rafael J. Wysocki wrote: > > It looks like we fail to resume the device, then, for some reason. > > > > That may be a PCIe link issue or something similar. > > > > Is this a regression for you? If so, what's the last kernel that didn't > > have this problem? Does 3.13.y (as released by Greg, without and distro > > "improvements") have it too? > > It was a regression from 3.11.x to 3.12 (and it is still broken with 3.13). > Due to some mistakes from my side, I have tested more configs: > > (based on Arch Linux 3.13.1 x86_64 config) > (a) 3.13.2 with CONFIG_HOTPLUG_PCI=y, but CONFIG_HOTPLUG_PCI_ACPI=n works. > (b) 3.13.2 with CONFIG_HOTPLUG_PCI=y and CONFIG_HOTPLUG_PCI_ACPI=y is broken. > (c) 3.13.2 with CONFIG_HOTPLUG_PCI=n still works. > (my stripped config) > (d) 3.13.2 with CONFIG_HOTPLUG_PCI=y, but CONFIG_HOTPLUG_PCI_ACPI=n works. > > With CONFIG_HOTPLUG_PCI_ACPI=y, the only difference in dmesg is: > > (during boot) > acpiphp: ACPI Hot Plug PCI Controller Driver version: 0.5 > (after resume) > iwlwifi 0000:05:00.0: no hotplug settings from platform > xhci_hcd 0000:02:00.0: no hotplug settings from platform > (here, NetworkManager complains that a device has gone) > iwlwifi 0000:05:00.0: no hotplug settings from platform > > Of course, with config (b), the ethernet adapter vanishes while it is still > present with configs (a), (c) and (d). > > Time to do a bisect? That most likely would single out one of the ACPIPHP commits without giving us much clue about what's going on. I fail to see what the connection between those changes and system resume is, however. Please replace all pr_debug() calls in hotplug_notify() with pr_info() and see if you get any events from there. Thanks!
On Sunday 09 February 2014 22:46:05 Rafael J. Wysocki wrote: > That most likely would single out one of the ACPIPHP commits without giving > us much clue about what's going on. > > I fail to see what the connection between those changes and system resume > is, however. > > Please replace all pr_debug() calls in hotplug_notify() with pr_info() and > see if you get any events from there. I could not find a hotplug_notify function in the kernel tree, but I have dyndbg enabled. Booting with `pci_hotplug.debug=Y pci_hotplug.debug_acpi=Y pci_hotplug.dyndbg acpiphp.dyndbg` gives me only a few acpiphp_glue messages. After resume: [ 55.492261] CPU3 is up [ 55.494710] ACPI: Waking up from system sleep state S3 [ 56.187298] ehci-pci 0000:00:1a.0: System wakeup disabled by ACPI [ 56.213939] ehci-pci 0000:00:1d.0: System wakeup disabled by ACPI [ 56.240614] xhci_hcd 0000:02:00.0: System wakeup disabled by ACPI [ 56.294230] PM: noirq resume of devices complete after 133.375 msecs [ 56.294507] PM: early resume of devices complete after 0.231 msecs [ 56.294798] pcieport 0000:00:1c.1: System wakeup disabled by ACPI [ 56.296628] iwlwifi 0000:05:00.0: RF_KILL bit toggled to enable radio. [ 56.404258] snd_hda_intel 0000:00:1b.0: irq 48 for MSI/MSI-X [ 56.627043] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300) [ 56.627929] ata1.00: configured for UDMA/133 [ 56.628044] sd 0:0:0:0: [sda] Starting disk [ 56.633730] ata2: SATA link up 1.5 Gbps (SStatus 113 SControl 300) [ 56.640403] ata5: SATA link down (SStatus 0 SControl 300) [ 56.802771] ata2.00: configured for UDMA/100 [ 57.737542] PM: resume of devices complete after 1443.847 msecs [ 57.737951] PM: Finishing wakeup. [ 57.737957] acpiphp_glue: hotplug_event: Bus check notify on \_SB_.PCI0.RP03 [ 57.737960] acpiphp_glue: hotplug_event: re-enumerating slots under \_SB_.PCI0.RP03 [ 57.738080] iwlwifi 0000:05:00.0: no hotplug settings from platform [ 57.737963] Restarting tasks ... done. [ 57.740480] video LNXVIDEO:00: Restoring backlight state [ 57.740487] video LNXVIDEO:01: Restoring backlight state [ 58.203311] ACPI: \_SB_.AC__: ACPI_NOTIFY_BUS_CHECK event: unsupported [ 58.204080] acpiphp_glue: hotplug_event: Bus check notify on \_SB_.PCI0.RP01 [ 58.204083] acpiphp_glue: hotplug_event: re-enumerating slots under \_SB_.PCI0.RP01 [ 58.204121] xhci_hcd 0000:02:00.0: no hotplug settings from platform [ 58.204132] acpiphp_glue: hotplug_event: Bus check notify on \_SB_.PCI0.RP02 [ 58.204134] acpiphp_glue: hotplug_event: re-enumerating slots under \_SB_.PCI0.RP02 [ 58.209339] jme 0000:04:00.5: irq 50 for MSI/MSI-X [ 58.233503] jme 0000:04:00.5 eth0: Link is down [ 58.233578] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready [ 58.235113] iwlwifi 0000:05:00.0: L1 Enabled; Disabling L0S [ 58.242131] iwlwifi 0000:05:00.0: Radio type=0x1-0x3-0x1 [ 58.346311] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready [ 58.392764] acpiphp_glue: hotplug_event: Bus check notify on \_SB_.PCI0.RP03 [ 58.392766] acpiphp_glue: hotplug_event: re-enumerating slots under \_SB_.PCI0.RP03 [ 58.392874] iwlwifi 0000:05:00.0: no hotplug settings from platform RP02 is the ACPI Device for 00:1c.1 [1]. Could the following commit have something to do with it? commit 4ebe34503baa0644c9352bcd76d4cf573bffe206 Author: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Date: Tue Jul 16 22:10:35 2013 +0200 ACPI / hotplug / PCI: Check for new devices on enabled slots The current implementation of acpiphp_check_bridge() is pretty dumb: - It enables a slot if it's not enabled and the slot status is ACPI_STA_ALL. - It disables a slot if it's enabled and the slot status is not ACPI_STA_ALL. This behavior is not sufficient to handle the Thunderbolt daisy chaining case properly, however, because in that case the bus behind the already enabled slot needs to be rescanned for new devices. For this reason, modify acpiphp_check_bridge() so that slots are disabled and stopped if they are not in the ACPI_STA_ALL state. For slots in the ACPI_STA_ALL state, devices behind them that don't respond are trimmed using a new function, trim_stale_devices(), introduced specifically for this purpose. That function walks the given bus and checks each device on it. If the device doesn't respond, it is assumed to be gone and is removed. Once all of the stale devices directy behind the slot have been removed, acpiphp_check_bridge() will start looking for new devices that might have appeared on the given bus. It will do that even if the slot is already enabled (SLOT_ENABLED is set for it). In addition to that, make the bus check notification ignore SLOT_ENABLED and go for enable_device() directly if bridge is NULL, so that devices behind the slot are re-enumerated in that case too. This change is based on earlier patches from Kirill A Shutemov and Mika Westerberg. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com> Peter [1]: https://github.com/Lekensteyn/acpi-stuff/blob/master/dsl/Clevo_B7130/DSDT.dsl#L8882 -- To unsubscribe from this list: send the line "unsubscribe linux-pm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
--- lspci-nnvvv.txt 2014-02-06 17:11:02.867233563 +0100 +++ lspci-nnvvv2.txt 2014-02-06 17:11:22.603425311 +0100 @@ -86,17 +86,17 @@ 00:1c.1 PCI bridge [0604]: Intel Corporation 5 Series/3400 Series Chipset PCI Express Root Port 2 [8086:3b44] (rev 05) (prog-if 00 [Normal decode]) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Latency: 0, Cache Line Size: 64 bytes Bus: primary=00, secondary=04, subordinate=04, sec-latency=0 I/O behind bridge: 00004000-00004fff Memory behind bridge: fd400000-fd4fffff Prefetchable memory behind bridge: 00000000c0000000-00000000c01fffff - Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- <SERR- <PERR- + Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort+ <SERR- <PERR- BridgeCtl: Parity- SERR- NoISA+ VGA- MAbort- >Reset- FastB2B- PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn- Capabilities: <access denied> Kernel driver in use: pcieport Kernel modules: shpchp 00:1c.2 PCI bridge [0604]: Intel Corporation 5 Series/3400 Series Chipset PCI Express Root Port 3 [8086:3b46] (rev 05) (prog-if 00 [Normal decode]) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx- @@ -200,60 +200,16 @@ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Latency: 0, Cache Line Size: 64 bytes Interrupt: pin A routed to IRQ 16 Region 0: Memory at fc000000 (64-bit, non-prefetchable) [size=8K] Capabilities: <access denied> Kernel driver in use: xhci_hcd Kernel modules: xhci_hcd -04:00.0 System peripheral [0880]: JMicron Technology Corp. SD/MMC Host Controller [197b:2382] (rev 80) - Subsystem: CLEVO/KAPOK Computer Device [1558:7130] - Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx- - Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- - Latency: 0, Cache Line Size: 64 bytes - Interrupt: pin B routed to IRQ 18 - Region 0: Memory at fd404000 (32-bit, non-prefetchable) [size=256] - Capabilities: <access denied> - Kernel driver in use: sdhci-pci - Kernel modules: sdhci_pci - -04:00.2 SD Host controller [0805]: JMicron Technology Corp. Standard SD Host Controller [197b:2381] (rev 80) (prog-if 01) - Subsystem: CLEVO/KAPOK Computer Device [1558:7130] - Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx- - Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- - Interrupt: pin B routed to IRQ 18 - Region 0: Memory at fd405000 (32-bit, non-prefetchable) [size=256] - Capabilities: <access denied> - Kernel modules: sdhci_pci - -04:00.3 System peripheral [0880]: JMicron Technology Corp. MS Host Controller [197b:2383] (rev 80) - Subsystem: CLEVO/KAPOK Computer Device [1558:7130] - Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx- - Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- - Latency: 0, Cache Line Size: 64 bytes - Interrupt: pin C routed to IRQ 19 - Region 0: Memory at fd406000 (32-bit, non-prefetchable) [size=256] - Capabilities: <access denied> - Kernel driver in use: jmb38x_ms - Kernel modules: jmb38x_ms - -04:00.5 Ethernet controller [0200]: JMicron Technology Corp. JMC250 PCI Express Gigabit Ethernet Controller [197b:0250] (rev 03) - Subsystem: CLEVO/KAPOK Computer Device [1558:7130] - Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx+ - Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- - Latency: 0, Cache Line Size: 64 bytes - Interrupt: pin B routed to IRQ 50 - Region 0: Memory at fd400000 (32-bit, non-prefetchable) [size=16K] - Region 2: I/O ports at 4400 [size=128] - Region 3: I/O ports at 4000 [size=256] - Capabilities: <access denied> - Kernel driver in use: jme - Kernel modules: jme - 05:00.0 Network controller [0280]: Intel Corporation Centrino Advanced-N 6200 [8086:422c] (rev 35) Subsystem: Intel Corporation Centrino Advanced-N 6200 2x2 AGN [8086:1301] Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Latency: 0, Cache Line Size: 64 bytes Interrupt: pin A routed to IRQ 49 Region 0: Memory at fd500000 (64-bit, non-prefetchable) [size=8K] Capabilities: <access denied>