Re: 3.12: ethernet controller missing after resuming from suspend to RAM
Le mer. 12 févr. 2014 15:04:28 CET, Rafael J. Wysocki a écrit : >>> Mika, I'll add a changelog to your patch and queue it up as a fix for 3.14. >>> >> >> Thanks guys for solving this issue ! >> >> Rafael, could this be submitted to stable trees (at least 3.12, 3.13) as >> well ? > > Yes, I have marked it for stable. Thanks a lot for dealing with this! Cheers -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 3.12: ethernet controller missing after resuming from suspend to RAM
Le mer. 12 févr. 2014 15:04:28 CET, Rafael J. Wysocki a écrit : Mika, I'll add a changelog to your patch and queue it up as a fix for 3.14. Thanks guys for solving this issue ! Rafael, could this be submitted to stable trees (at least 3.12, 3.13) as well ? Yes, I have marked it for stable. Thanks a lot for dealing with this! Cheers -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 3.12: ethernet controller missing after resuming from suspend to RAM
On Wednesday, February 12, 2014 08:44:13 AM Francis Moreau wrote: > On 02/12/2014 12:58 AM, Rafael J. Wysocki wrote: > > On Tuesday, February 11, 2014 07:17:37 PM Peter Wu wrote: > >> On Tuesday 11 February 2014 12:42:37 Mika Westerberg wrote: > >>> On Mon, Feb 10, 2014 at 11:39:29PM +0100, Rafael J. Wysocki wrote: > > _STA() returns 0x0A instead of 0x0F. Could there be something missing in > > the ACPI hotplug code that overlooks this and removes the device on > > resume? > > That is possible. Actually even quite likely, but let's wait for the > response from Peter. > >>> > >>> Here's a hack that should take the 0xa return value into consideration. It > >>> turned out that this case is even mentioned in the ACPI spec. > >> > >> Tested-by: Peter Wu > >> > >> This works, the devices are not lost anymore after resume. dmesg > >> mentions the 04:00.* devices at resume compared to the unpatched kernel: > >> > >> [ 42.650721] PM: Finishing wakeup. > >> [ 42.650768] acpiphp_glue: hotplug_event: Bus check notify on > >> \_SB_.PCI0.RP03 > >> [ 42.650772] acpiphp_glue: hotplug_event: re-enumerating slots under > >> \_SB_.PCI0.RP03 > >> [ 42.650874] iwlwifi :05:00.0: no hotplug settings from platform > >> [ 42.650722] Restarting tasks ... done. > >> [ 42.650985] video LNXVIDEO:00: Restoring backlight state > >> [ 42.650988] video LNXVIDEO:01: Restoring backlight state > >> [ 43.124208] ACPI: \_SB_.AC__: ACPI_NOTIFY_BUS_CHECK event: unsupported > >> [ 43.128401] jme :04:00.5: irq 50 for MSI/MSI-X > >> [ 43.153005] jme :04:00.5 eth0: Link is down > >> [ 43.153030] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready > >> [ 43.154364] iwlwifi :05:00.0: L1 Enabled; Disabling L0S > >> [ 43.162307] iwlwifi :05:00.0: Radio type=0x1-0x3-0x1 > >> [ 43.276220] acpiphp_glue: hotplug_event: Bus check notify on > >> \_SB_.PCI0.RP01 > >> [ 43.276223] acpiphp_glue: hotplug_event: re-enumerating slots under > >> \_SB_.PCI0.RP01 > >> [ 43.276257] xhci_hcd :02:00.0: no hotplug settings from platform > >> [ 43.276267] acpiphp_glue: hotplug_event: Bus check notify on > >> \_SB_.PCI0.RP02 > >> [ 43.276268] acpiphp_glue: hotplug_event: re-enumerating slots under > >> \_SB_.PCI0.RP02 > >> [ 43.276355] sdhci-pci :04:00.0: no hotplug settings from platform > >> [ 43.276368] pci :04:00.2: no hotplug settings from platform > >> [ 43.276381] jmb38x_ms :04:00.3: no hotplug settings from platform > >> [ 43.276393] jme :04:00.5: no hotplug settings from platform > >> [ 43.276398] acpiphp_glue: hotplug_event: Bus check notify on > >> \_SB_.PCI0.RP03 > >> [ 43.276399] acpiphp_glue: hotplug_event: re-enumerating slots under > >> \_SB_.PCI0.RP03 > >> [ 43.276491] iwlwifi :05:00.0: no hotplug settings from platform > >> [ 43.277214] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready > >> > >> Rafael, do you want me to test the other patch as well? > > > > No, thanks! > > > > Mika, I'll add a changelog to your patch and queue it up as a fix for 3.14. > > > > Thanks guys for solving this issue ! > > Rafael, could this be submitted to stable trees (at least 3.12, 3.13) as > well ? Yes, I have marked it for stable. Thanks! -- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 3.12: ethernet controller missing after resuming from suspend to RAM
On Wed, Feb 12, 2014 at 12:58:07AM +0100, Rafael J. Wysocki wrote: > Mika, I'll add a changelog to your patch and queue it up as a fix for 3.14. Thanks Rafael. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 3.12: ethernet controller missing after resuming from suspend to RAM
On Wed, Feb 12, 2014 at 12:58:07AM +0100, Rafael J. Wysocki wrote: Mika, I'll add a changelog to your patch and queue it up as a fix for 3.14. Thanks Rafael. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 3.12: ethernet controller missing after resuming from suspend to RAM
On Wednesday, February 12, 2014 08:44:13 AM Francis Moreau wrote: On 02/12/2014 12:58 AM, Rafael J. Wysocki wrote: On Tuesday, February 11, 2014 07:17:37 PM Peter Wu wrote: On Tuesday 11 February 2014 12:42:37 Mika Westerberg wrote: On Mon, Feb 10, 2014 at 11:39:29PM +0100, Rafael J. Wysocki wrote: _STA() returns 0x0A instead of 0x0F. Could there be something missing in the ACPI hotplug code that overlooks this and removes the device on resume? That is possible. Actually even quite likely, but let's wait for the response from Peter. Here's a hack that should take the 0xa return value into consideration. It turned out that this case is even mentioned in the ACPI spec. Tested-by: Peter Wu lekenst...@gmail.com This works, the devices are not lost anymore after resume. dmesg mentions the 04:00.* devices at resume compared to the unpatched kernel: [ 42.650721] PM: Finishing wakeup. [ 42.650768] acpiphp_glue: hotplug_event: Bus check notify on \_SB_.PCI0.RP03 [ 42.650772] acpiphp_glue: hotplug_event: re-enumerating slots under \_SB_.PCI0.RP03 [ 42.650874] iwlwifi :05:00.0: no hotplug settings from platform [ 42.650722] Restarting tasks ... done. [ 42.650985] video LNXVIDEO:00: Restoring backlight state [ 42.650988] video LNXVIDEO:01: Restoring backlight state [ 43.124208] ACPI: \_SB_.AC__: ACPI_NOTIFY_BUS_CHECK event: unsupported [ 43.128401] jme :04:00.5: irq 50 for MSI/MSI-X [ 43.153005] jme :04:00.5 eth0: Link is down [ 43.153030] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready [ 43.154364] iwlwifi :05:00.0: L1 Enabled; Disabling L0S [ 43.162307] iwlwifi :05:00.0: Radio type=0x1-0x3-0x1 [ 43.276220] acpiphp_glue: hotplug_event: Bus check notify on \_SB_.PCI0.RP01 [ 43.276223] acpiphp_glue: hotplug_event: re-enumerating slots under \_SB_.PCI0.RP01 [ 43.276257] xhci_hcd :02:00.0: no hotplug settings from platform [ 43.276267] acpiphp_glue: hotplug_event: Bus check notify on \_SB_.PCI0.RP02 [ 43.276268] acpiphp_glue: hotplug_event: re-enumerating slots under \_SB_.PCI0.RP02 [ 43.276355] sdhci-pci :04:00.0: no hotplug settings from platform [ 43.276368] pci :04:00.2: no hotplug settings from platform [ 43.276381] jmb38x_ms :04:00.3: no hotplug settings from platform [ 43.276393] jme :04:00.5: no hotplug settings from platform [ 43.276398] acpiphp_glue: hotplug_event: Bus check notify on \_SB_.PCI0.RP03 [ 43.276399] acpiphp_glue: hotplug_event: re-enumerating slots under \_SB_.PCI0.RP03 [ 43.276491] iwlwifi :05:00.0: no hotplug settings from platform [ 43.277214] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready Rafael, do you want me to test the other patch as well? No, thanks! Mika, I'll add a changelog to your patch and queue it up as a fix for 3.14. Thanks guys for solving this issue ! Rafael, could this be submitted to stable trees (at least 3.12, 3.13) as well ? Yes, I have marked it for stable. Thanks! -- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 3.12: ethernet controller missing after resuming from suspend to RAM
On 02/12/2014 12:58 AM, Rafael J. Wysocki wrote: > On Tuesday, February 11, 2014 07:17:37 PM Peter Wu wrote: >> On Tuesday 11 February 2014 12:42:37 Mika Westerberg wrote: >>> On Mon, Feb 10, 2014 at 11:39:29PM +0100, Rafael J. Wysocki wrote: > _STA() returns 0x0A instead of 0x0F. Could there be something missing in > the ACPI hotplug code that overlooks this and removes the device on > resume? That is possible. Actually even quite likely, but let's wait for the response from Peter. >>> >>> Here's a hack that should take the 0xa return value into consideration. It >>> turned out that this case is even mentioned in the ACPI spec. >> >> Tested-by: Peter Wu >> >> This works, the devices are not lost anymore after resume. dmesg >> mentions the 04:00.* devices at resume compared to the unpatched kernel: >> >> [ 42.650721] PM: Finishing wakeup. >> [ 42.650768] acpiphp_glue: hotplug_event: Bus check notify on >> \_SB_.PCI0.RP03 >> [ 42.650772] acpiphp_glue: hotplug_event: re-enumerating slots under >> \_SB_.PCI0.RP03 >> [ 42.650874] iwlwifi :05:00.0: no hotplug settings from platform >> [ 42.650722] Restarting tasks ... done. >> [ 42.650985] video LNXVIDEO:00: Restoring backlight state >> [ 42.650988] video LNXVIDEO:01: Restoring backlight state >> [ 43.124208] ACPI: \_SB_.AC__: ACPI_NOTIFY_BUS_CHECK event: unsupported >> [ 43.128401] jme :04:00.5: irq 50 for MSI/MSI-X >> [ 43.153005] jme :04:00.5 eth0: Link is down >> [ 43.153030] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready >> [ 43.154364] iwlwifi :05:00.0: L1 Enabled; Disabling L0S >> [ 43.162307] iwlwifi :05:00.0: Radio type=0x1-0x3-0x1 >> [ 43.276220] acpiphp_glue: hotplug_event: Bus check notify on >> \_SB_.PCI0.RP01 >> [ 43.276223] acpiphp_glue: hotplug_event: re-enumerating slots under >> \_SB_.PCI0.RP01 >> [ 43.276257] xhci_hcd :02:00.0: no hotplug settings from platform >> [ 43.276267] acpiphp_glue: hotplug_event: Bus check notify on >> \_SB_.PCI0.RP02 >> [ 43.276268] acpiphp_glue: hotplug_event: re-enumerating slots under >> \_SB_.PCI0.RP02 >> [ 43.276355] sdhci-pci :04:00.0: no hotplug settings from platform >> [ 43.276368] pci :04:00.2: no hotplug settings from platform >> [ 43.276381] jmb38x_ms :04:00.3: no hotplug settings from platform >> [ 43.276393] jme :04:00.5: no hotplug settings from platform >> [ 43.276398] acpiphp_glue: hotplug_event: Bus check notify on >> \_SB_.PCI0.RP03 >> [ 43.276399] acpiphp_glue: hotplug_event: re-enumerating slots under >> \_SB_.PCI0.RP03 >> [ 43.276491] iwlwifi :05:00.0: no hotplug settings from platform >> [ 43.277214] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready >> >> Rafael, do you want me to test the other patch as well? > > No, thanks! > > Mika, I'll add a changelog to your patch and queue it up as a fix for 3.14. > Thanks guys for solving this issue ! Rafael, could this be submitted to stable trees (at least 3.12, 3.13) as well ? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 3.12: ethernet controller missing after resuming from suspend to RAM
On Tuesday, February 11, 2014 07:17:37 PM Peter Wu wrote:
> On Tuesday 11 February 2014 12:42:37 Mika Westerberg wrote:
> > On Mon, Feb 10, 2014 at 11:39:29PM +0100, Rafael J. Wysocki wrote:
> > > > _STA() returns 0x0A instead of 0x0F. Could there be something missing in
> > > > the ACPI hotplug code that overlooks this and removes the device on
> > > > resume?
> > >
> > > That is possible. Actually even quite likely, but let's wait for the
> > > response from Peter.
> >
> > Here's a hack that should take the 0xa return value into consideration. It
> > turned out that this case is even mentioned in the ACPI spec.
>
> Tested-by: Peter Wu
>
> This works, the devices are not lost anymore after resume. dmesg
> mentions the 04:00.* devices at resume compared to the unpatched kernel:
>
> [ 42.650721] PM: Finishing wakeup.
> [ 42.650768] acpiphp_glue: hotplug_event: Bus check notify on
> \_SB_.PCI0.RP03
> [ 42.650772] acpiphp_glue: hotplug_event: re-enumerating slots under
> \_SB_.PCI0.RP03
> [ 42.650874] iwlwifi :05:00.0: no hotplug settings from platform
> [ 42.650722] Restarting tasks ... done.
> [ 42.650985] video LNXVIDEO:00: Restoring backlight state
> [ 42.650988] video LNXVIDEO:01: Restoring backlight state
> [ 43.124208] ACPI: \_SB_.AC__: ACPI_NOTIFY_BUS_CHECK event: unsupported
> [ 43.128401] jme :04:00.5: irq 50 for MSI/MSI-X
> [ 43.153005] jme :04:00.5 eth0: Link is down
> [ 43.153030] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
> [ 43.154364] iwlwifi :05:00.0: L1 Enabled; Disabling L0S
> [ 43.162307] iwlwifi :05:00.0: Radio type=0x1-0x3-0x1
> [ 43.276220] acpiphp_glue: hotplug_event: Bus check notify on
> \_SB_.PCI0.RP01
> [ 43.276223] acpiphp_glue: hotplug_event: re-enumerating slots under
> \_SB_.PCI0.RP01
> [ 43.276257] xhci_hcd :02:00.0: no hotplug settings from platform
> [ 43.276267] acpiphp_glue: hotplug_event: Bus check notify on
> \_SB_.PCI0.RP02
> [ 43.276268] acpiphp_glue: hotplug_event: re-enumerating slots under
> \_SB_.PCI0.RP02
> [ 43.276355] sdhci-pci :04:00.0: no hotplug settings from platform
> [ 43.276368] pci :04:00.2: no hotplug settings from platform
> [ 43.276381] jmb38x_ms :04:00.3: no hotplug settings from platform
> [ 43.276393] jme :04:00.5: no hotplug settings from platform
> [ 43.276398] acpiphp_glue: hotplug_event: Bus check notify on
> \_SB_.PCI0.RP03
> [ 43.276399] acpiphp_glue: hotplug_event: re-enumerating slots under
> \_SB_.PCI0.RP03
> [ 43.276491] iwlwifi :05:00.0: no hotplug settings from platform
> [ 43.277214] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
>
> Rafael, do you want me to test the other patch as well?
No, thanks!
Mika, I'll add a changelog to your patch and queue it up as a fix for 3.14.
Thanks!
> > diff --git a/drivers/pci/hotplug/acpiphp_glue.c
> > b/drivers/pci/hotplug/acpiphp_glue.c index e2a783fdb98f..014381b42d86
> > 100644
> > --- a/drivers/pci/hotplug/acpiphp_glue.c
> > +++ b/drivers/pci/hotplug/acpiphp_glue.c
> > @@ -730,6 +730,17 @@ static unsigned int get_slot_status(struct acpiphp_slot
> > *slot) return (unsigned int)sta;
> > }
> >
> > +static inline bool device_sta_valid(unsigned long long sta)
> > +{
> > + /*
> > +* ACPI spec says that _STA may return bit 0 clear with bit 8 set
> > +* if the device is valid but does not require device driver to be
> > +* loaded (chapter 6.3.7).
> > +*/
> > + unsigned mask = ACPI_STA_DEVICE_ENABLED | ACPI_STA_DEVICE_FUNCTIONING;
> > + return (sta & mask) == mask;
> > +}
> > +
> > /**
> > * trim_stale_devices - remove PCI devices that are not responding.
> > * @dev: PCI device to start walking the hierarchy from.
> > @@ -745,7 +756,7 @@ static void trim_stale_devices(struct pci_dev *dev)
> > unsigned long long sta;
> >
> > status = acpi_evaluate_integer(handle, "_STA", NULL, );
> > - alive = (ACPI_SUCCESS(status) && sta == ACPI_STA_ALL)
> > + alive = (ACPI_SUCCESS(status) && device_sta_valid(sta))
> >
> > || acpiphp_no_hotplug(handle);
> >
> > }
> > if (!alive) {
> > @@ -792,7 +803,7 @@ static void acpiphp_check_bridge(struct acpiphp_bridge
> > *bridge) mutex_lock(>crit_sect);
> > if (slot_no_hotplug(slot)) {
> > ; /* do nothing */
> > - } else if (get_slot_status(slot) == ACPI_STA_ALL) {
> > + } else if (device_sta_valid(get_slot_status(slot))) {
> > /* remove stale devices if any */
> > list_for_each_entry_safe_reverse(dev, tmp,
> > >devices,
> > bus_list)
>
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at
Re: 3.12: ethernet controller missing after resuming from suspend to RAM
On Tuesday 11 February 2014 12:42:37 Mika Westerberg wrote:
> On Mon, Feb 10, 2014 at 11:39:29PM +0100, Rafael J. Wysocki wrote:
> > > _STA() returns 0x0A instead of 0x0F. Could there be something missing in
> > > the ACPI hotplug code that overlooks this and removes the device on
> > > resume?
> >
> > That is possible. Actually even quite likely, but let's wait for the
> > response from Peter.
>
> Here's a hack that should take the 0xa return value into consideration. It
> turned out that this case is even mentioned in the ACPI spec.
Tested-by: Peter Wu
This works, the devices are not lost anymore after resume. dmesg
mentions the 04:00.* devices at resume compared to the unpatched kernel:
[ 42.650721] PM: Finishing wakeup.
[ 42.650768] acpiphp_glue: hotplug_event: Bus check notify on \_SB_.PCI0.RP03
[ 42.650772] acpiphp_glue: hotplug_event: re-enumerating slots under
\_SB_.PCI0.RP03
[ 42.650874] iwlwifi :05:00.0: no hotplug settings from platform
[ 42.650722] Restarting tasks ... done.
[ 42.650985] video LNXVIDEO:00: Restoring backlight state
[ 42.650988] video LNXVIDEO:01: Restoring backlight state
[ 43.124208] ACPI: \_SB_.AC__: ACPI_NOTIFY_BUS_CHECK event: unsupported
[ 43.128401] jme :04:00.5: irq 50 for MSI/MSI-X
[ 43.153005] jme :04:00.5 eth0: Link is down
[ 43.153030] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
[ 43.154364] iwlwifi :05:00.0: L1 Enabled; Disabling L0S
[ 43.162307] iwlwifi :05:00.0: Radio type=0x1-0x3-0x1
[ 43.276220] acpiphp_glue: hotplug_event: Bus check notify on \_SB_.PCI0.RP01
[ 43.276223] acpiphp_glue: hotplug_event: re-enumerating slots under
\_SB_.PCI0.RP01
[ 43.276257] xhci_hcd :02:00.0: no hotplug settings from platform
[ 43.276267] acpiphp_glue: hotplug_event: Bus check notify on \_SB_.PCI0.RP02
[ 43.276268] acpiphp_glue: hotplug_event: re-enumerating slots under
\_SB_.PCI0.RP02
[ 43.276355] sdhci-pci :04:00.0: no hotplug settings from platform
[ 43.276368] pci :04:00.2: no hotplug settings from platform
[ 43.276381] jmb38x_ms :04:00.3: no hotplug settings from platform
[ 43.276393] jme :04:00.5: no hotplug settings from platform
[ 43.276398] acpiphp_glue: hotplug_event: Bus check notify on \_SB_.PCI0.RP03
[ 43.276399] acpiphp_glue: hotplug_event: re-enumerating slots under
\_SB_.PCI0.RP03
[ 43.276491] iwlwifi :05:00.0: no hotplug settings from platform
[ 43.277214] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
Rafael, do you want me to test the other patch as well?
Peter
> diff --git a/drivers/pci/hotplug/acpiphp_glue.c
> b/drivers/pci/hotplug/acpiphp_glue.c index e2a783fdb98f..014381b42d86
> 100644
> --- a/drivers/pci/hotplug/acpiphp_glue.c
> +++ b/drivers/pci/hotplug/acpiphp_glue.c
> @@ -730,6 +730,17 @@ static unsigned int get_slot_status(struct acpiphp_slot
> *slot) return (unsigned int)sta;
> }
>
> +static inline bool device_sta_valid(unsigned long long sta)
> +{
> + /*
> + * ACPI spec says that _STA may return bit 0 clear with bit 8 set
> + * if the device is valid but does not require device driver to be
> + * loaded (chapter 6.3.7).
> + */
> + unsigned mask = ACPI_STA_DEVICE_ENABLED | ACPI_STA_DEVICE_FUNCTIONING;
> + return (sta & mask) == mask;
> +}
> +
> /**
> * trim_stale_devices - remove PCI devices that are not responding.
> * @dev: PCI device to start walking the hierarchy from.
> @@ -745,7 +756,7 @@ static void trim_stale_devices(struct pci_dev *dev)
> unsigned long long sta;
>
> status = acpi_evaluate_integer(handle, "_STA", NULL, );
> - alive = (ACPI_SUCCESS(status) && sta == ACPI_STA_ALL)
> + alive = (ACPI_SUCCESS(status) && device_sta_valid(sta))
>
> || acpiphp_no_hotplug(handle);
>
> }
> if (!alive) {
> @@ -792,7 +803,7 @@ static void acpiphp_check_bridge(struct acpiphp_bridge
> *bridge) mutex_lock(>crit_sect);
> if (slot_no_hotplug(slot)) {
> ; /* do nothing */
> - } else if (get_slot_status(slot) == ACPI_STA_ALL) {
> + } else if (device_sta_valid(get_slot_status(slot))) {
> /* remove stale devices if any */
> list_for_each_entry_safe_reverse(dev, tmp,
>>devices,
> bus_list)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 3.12: ethernet controller missing after resuming from suspend to RAM
Le 09/02/2014 23:07, Peter Wu a écrit : > I think this is relevant. See also my test with 3.13.2 and different > kernel configs[1]. A workaround that triggers a scan was also posted[2]. > > Peter > > [1]: http://lkml.org/lkml/2014/2/8/264 > [2]: http://lkml.org/lkml/2014/2/7/809 Thanks, I can confirm that triggering a rescan by issuing sudo tee /sys/devices/pci:00/:00:1c.1/rescan <<<1 made the device reappear on my system (of course I had to adapt the command to match PCI Bridge number). That's a handy workaround, it avoids restarting each time. As I've never compiled a kernel so far I think I'll leave the configuration tweaks for another time :) Cheers -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 3.12: ethernet controller missing after resuming from suspend to RAM
On Tuesday, February 11, 2014 12:42:37 PM Mika Westerberg wrote:
> On Mon, Feb 10, 2014 at 11:39:29PM +0100, Rafael J. Wysocki wrote:
> > > _STA() returns 0x0A instead of 0x0F. Could there be something missing in
> > > the ACPI hotplug code that overlooks this and removes the device on
> > > resume?
> >
> > That is possible. Actually even quite likely, but let's wait for the
> > response
> > from Peter.
>
> Here's a hack that should take the 0xa return value into consideration. It
> turned out that this case is even mentioned in the ACPI spec.
Looks reasonable.
Peter, please check if this one makes a difference for you.
> diff --git a/drivers/pci/hotplug/acpiphp_glue.c
> b/drivers/pci/hotplug/acpiphp_glue.c
> index e2a783fdb98f..014381b42d86 100644
> --- a/drivers/pci/hotplug/acpiphp_glue.c
> +++ b/drivers/pci/hotplug/acpiphp_glue.c
> @@ -730,6 +730,17 @@ static unsigned int get_slot_status(struct acpiphp_slot
> *slot)
> return (unsigned int)sta;
> }
>
> +static inline bool device_sta_valid(unsigned long long sta)
> +{
> + /*
> + * ACPI spec says that _STA may return bit 0 clear with bit 8 set
> + * if the device is valid but does not require device driver to be
> + * loaded (chapter 6.3.7).
> + */
> + unsigned mask = ACPI_STA_DEVICE_ENABLED | ACPI_STA_DEVICE_FUNCTIONING;
> + return (sta & mask) == mask;
> +}
> +
> /**
> * trim_stale_devices - remove PCI devices that are not responding.
> * @dev: PCI device to start walking the hierarchy from.
> @@ -745,7 +756,7 @@ static void trim_stale_devices(struct pci_dev *dev)
> unsigned long long sta;
>
> status = acpi_evaluate_integer(handle, "_STA", NULL, );
> - alive = (ACPI_SUCCESS(status) && sta == ACPI_STA_ALL)
> + alive = (ACPI_SUCCESS(status) && device_sta_valid(sta))
> || acpiphp_no_hotplug(handle);
> }
> if (!alive) {
> @@ -792,7 +803,7 @@ static void acpiphp_check_bridge(struct acpiphp_bridge
> *bridge)
> mutex_lock(>crit_sect);
> if (slot_no_hotplug(slot)) {
> ; /* do nothing */
> - } else if (get_slot_status(slot) == ACPI_STA_ALL) {
> + } else if (device_sta_valid(get_slot_status(slot))) {
> /* remove stale devices if any */
> list_for_each_entry_safe_reverse(dev, tmp,
>>devices,
> bus_list)
>
>
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 3.12: ethernet controller missing after resuming from suspend to RAM
On Mon, Feb 10, 2014 at 11:39:29PM +0100, Rafael J. Wysocki wrote:
> > _STA() returns 0x0A instead of 0x0F. Could there be something missing in
> > the ACPI hotplug code that overlooks this and removes the device on resume?
>
> That is possible. Actually even quite likely, but let's wait for the response
> from Peter.
Here's a hack that should take the 0xa return value into consideration. It
turned out that this case is even mentioned in the ACPI spec.
diff --git a/drivers/pci/hotplug/acpiphp_glue.c
b/drivers/pci/hotplug/acpiphp_glue.c
index e2a783fdb98f..014381b42d86 100644
--- a/drivers/pci/hotplug/acpiphp_glue.c
+++ b/drivers/pci/hotplug/acpiphp_glue.c
@@ -730,6 +730,17 @@ static unsigned int get_slot_status(struct acpiphp_slot
*slot)
return (unsigned int)sta;
}
+static inline bool device_sta_valid(unsigned long long sta)
+{
+ /*
+* ACPI spec says that _STA may return bit 0 clear with bit 8 set
+* if the device is valid but does not require device driver to be
+* loaded (chapter 6.3.7).
+*/
+ unsigned mask = ACPI_STA_DEVICE_ENABLED | ACPI_STA_DEVICE_FUNCTIONING;
+ return (sta & mask) == mask;
+}
+
/**
* trim_stale_devices - remove PCI devices that are not responding.
* @dev: PCI device to start walking the hierarchy from.
@@ -745,7 +756,7 @@ static void trim_stale_devices(struct pci_dev *dev)
unsigned long long sta;
status = acpi_evaluate_integer(handle, "_STA", NULL, );
- alive = (ACPI_SUCCESS(status) && sta == ACPI_STA_ALL)
+ alive = (ACPI_SUCCESS(status) && device_sta_valid(sta))
|| acpiphp_no_hotplug(handle);
}
if (!alive) {
@@ -792,7 +803,7 @@ static void acpiphp_check_bridge(struct acpiphp_bridge
*bridge)
mutex_lock(>crit_sect);
if (slot_no_hotplug(slot)) {
; /* do nothing */
- } else if (get_slot_status(slot) == ACPI_STA_ALL) {
+ } else if (device_sta_valid(get_slot_status(slot))) {
/* remove stale devices if any */
list_for_each_entry_safe_reverse(dev, tmp,
>devices,
bus_list)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 3.12: ethernet controller missing after resuming from suspend to RAM
On Mon, Feb 10, 2014 at 11:39:29PM +0100, Rafael J. Wysocki wrote:
_STA() returns 0x0A instead of 0x0F. Could there be something missing in
the ACPI hotplug code that overlooks this and removes the device on resume?
That is possible. Actually even quite likely, but let's wait for the response
from Peter.
Here's a hack that should take the 0xa return value into consideration. It
turned out that this case is even mentioned in the ACPI spec.
diff --git a/drivers/pci/hotplug/acpiphp_glue.c
b/drivers/pci/hotplug/acpiphp_glue.c
index e2a783fdb98f..014381b42d86 100644
--- a/drivers/pci/hotplug/acpiphp_glue.c
+++ b/drivers/pci/hotplug/acpiphp_glue.c
@@ -730,6 +730,17 @@ static unsigned int get_slot_status(struct acpiphp_slot
*slot)
return (unsigned int)sta;
}
+static inline bool device_sta_valid(unsigned long long sta)
+{
+ /*
+* ACPI spec says that _STA may return bit 0 clear with bit 8 set
+* if the device is valid but does not require device driver to be
+* loaded (chapter 6.3.7).
+*/
+ unsigned mask = ACPI_STA_DEVICE_ENABLED | ACPI_STA_DEVICE_FUNCTIONING;
+ return (sta mask) == mask;
+}
+
/**
* trim_stale_devices - remove PCI devices that are not responding.
* @dev: PCI device to start walking the hierarchy from.
@@ -745,7 +756,7 @@ static void trim_stale_devices(struct pci_dev *dev)
unsigned long long sta;
status = acpi_evaluate_integer(handle, _STA, NULL, sta);
- alive = (ACPI_SUCCESS(status) sta == ACPI_STA_ALL)
+ alive = (ACPI_SUCCESS(status) device_sta_valid(sta))
|| acpiphp_no_hotplug(handle);
}
if (!alive) {
@@ -792,7 +803,7 @@ static void acpiphp_check_bridge(struct acpiphp_bridge
*bridge)
mutex_lock(slot-crit_sect);
if (slot_no_hotplug(slot)) {
; /* do nothing */
- } else if (get_slot_status(slot) == ACPI_STA_ALL) {
+ } else if (device_sta_valid(get_slot_status(slot))) {
/* remove stale devices if any */
list_for_each_entry_safe_reverse(dev, tmp,
bus-devices,
bus_list)
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 3.12: ethernet controller missing after resuming from suspend to RAM
On Tuesday, February 11, 2014 12:42:37 PM Mika Westerberg wrote:
On Mon, Feb 10, 2014 at 11:39:29PM +0100, Rafael J. Wysocki wrote:
_STA() returns 0x0A instead of 0x0F. Could there be something missing in
the ACPI hotplug code that overlooks this and removes the device on
resume?
That is possible. Actually even quite likely, but let's wait for the
response
from Peter.
Here's a hack that should take the 0xa return value into consideration. It
turned out that this case is even mentioned in the ACPI spec.
Looks reasonable.
Peter, please check if this one makes a difference for you.
diff --git a/drivers/pci/hotplug/acpiphp_glue.c
b/drivers/pci/hotplug/acpiphp_glue.c
index e2a783fdb98f..014381b42d86 100644
--- a/drivers/pci/hotplug/acpiphp_glue.c
+++ b/drivers/pci/hotplug/acpiphp_glue.c
@@ -730,6 +730,17 @@ static unsigned int get_slot_status(struct acpiphp_slot
*slot)
return (unsigned int)sta;
}
+static inline bool device_sta_valid(unsigned long long sta)
+{
+ /*
+ * ACPI spec says that _STA may return bit 0 clear with bit 8 set
+ * if the device is valid but does not require device driver to be
+ * loaded (chapter 6.3.7).
+ */
+ unsigned mask = ACPI_STA_DEVICE_ENABLED | ACPI_STA_DEVICE_FUNCTIONING;
+ return (sta mask) == mask;
+}
+
/**
* trim_stale_devices - remove PCI devices that are not responding.
* @dev: PCI device to start walking the hierarchy from.
@@ -745,7 +756,7 @@ static void trim_stale_devices(struct pci_dev *dev)
unsigned long long sta;
status = acpi_evaluate_integer(handle, _STA, NULL, sta);
- alive = (ACPI_SUCCESS(status) sta == ACPI_STA_ALL)
+ alive = (ACPI_SUCCESS(status) device_sta_valid(sta))
|| acpiphp_no_hotplug(handle);
}
if (!alive) {
@@ -792,7 +803,7 @@ static void acpiphp_check_bridge(struct acpiphp_bridge
*bridge)
mutex_lock(slot-crit_sect);
if (slot_no_hotplug(slot)) {
; /* do nothing */
- } else if (get_slot_status(slot) == ACPI_STA_ALL) {
+ } else if (device_sta_valid(get_slot_status(slot))) {
/* remove stale devices if any */
list_for_each_entry_safe_reverse(dev, tmp,
bus-devices,
bus_list)
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 3.12: ethernet controller missing after resuming from suspend to RAM
Le 09/02/2014 23:07, Peter Wu a écrit : I think this is relevant. See also my test with 3.13.2 and different kernel configs[1]. A workaround that triggers a scan was also posted[2]. Peter [1]: http://lkml.org/lkml/2014/2/8/264 [2]: http://lkml.org/lkml/2014/2/7/809 Thanks, I can confirm that triggering a rescan by issuing sudo tee /sys/devices/pci:00/:00:1c.1/rescan 1 made the device reappear on my system (of course I had to adapt the command to match PCI Bridge number). That's a handy workaround, it avoids restarting each time. As I've never compiled a kernel so far I think I'll leave the configuration tweaks for another time :) Cheers -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 3.12: ethernet controller missing after resuming from suspend to RAM
On Tuesday 11 February 2014 12:42:37 Mika Westerberg wrote:
On Mon, Feb 10, 2014 at 11:39:29PM +0100, Rafael J. Wysocki wrote:
_STA() returns 0x0A instead of 0x0F. Could there be something missing in
the ACPI hotplug code that overlooks this and removes the device on
resume?
That is possible. Actually even quite likely, but let's wait for the
response from Peter.
Here's a hack that should take the 0xa return value into consideration. It
turned out that this case is even mentioned in the ACPI spec.
Tested-by: Peter Wu lekenst...@gmail.com
This works, the devices are not lost anymore after resume. dmesg
mentions the 04:00.* devices at resume compared to the unpatched kernel:
[ 42.650721] PM: Finishing wakeup.
[ 42.650768] acpiphp_glue: hotplug_event: Bus check notify on \_SB_.PCI0.RP03
[ 42.650772] acpiphp_glue: hotplug_event: re-enumerating slots under
\_SB_.PCI0.RP03
[ 42.650874] iwlwifi :05:00.0: no hotplug settings from platform
[ 42.650722] Restarting tasks ... done.
[ 42.650985] video LNXVIDEO:00: Restoring backlight state
[ 42.650988] video LNXVIDEO:01: Restoring backlight state
[ 43.124208] ACPI: \_SB_.AC__: ACPI_NOTIFY_BUS_CHECK event: unsupported
[ 43.128401] jme :04:00.5: irq 50 for MSI/MSI-X
[ 43.153005] jme :04:00.5 eth0: Link is down
[ 43.153030] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
[ 43.154364] iwlwifi :05:00.0: L1 Enabled; Disabling L0S
[ 43.162307] iwlwifi :05:00.0: Radio type=0x1-0x3-0x1
[ 43.276220] acpiphp_glue: hotplug_event: Bus check notify on \_SB_.PCI0.RP01
[ 43.276223] acpiphp_glue: hotplug_event: re-enumerating slots under
\_SB_.PCI0.RP01
[ 43.276257] xhci_hcd :02:00.0: no hotplug settings from platform
[ 43.276267] acpiphp_glue: hotplug_event: Bus check notify on \_SB_.PCI0.RP02
[ 43.276268] acpiphp_glue: hotplug_event: re-enumerating slots under
\_SB_.PCI0.RP02
[ 43.276355] sdhci-pci :04:00.0: no hotplug settings from platform
[ 43.276368] pci :04:00.2: no hotplug settings from platform
[ 43.276381] jmb38x_ms :04:00.3: no hotplug settings from platform
[ 43.276393] jme :04:00.5: no hotplug settings from platform
[ 43.276398] acpiphp_glue: hotplug_event: Bus check notify on \_SB_.PCI0.RP03
[ 43.276399] acpiphp_glue: hotplug_event: re-enumerating slots under
\_SB_.PCI0.RP03
[ 43.276491] iwlwifi :05:00.0: no hotplug settings from platform
[ 43.277214] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
Rafael, do you want me to test the other patch as well?
Peter
diff --git a/drivers/pci/hotplug/acpiphp_glue.c
b/drivers/pci/hotplug/acpiphp_glue.c index e2a783fdb98f..014381b42d86
100644
--- a/drivers/pci/hotplug/acpiphp_glue.c
+++ b/drivers/pci/hotplug/acpiphp_glue.c
@@ -730,6 +730,17 @@ static unsigned int get_slot_status(struct acpiphp_slot
*slot) return (unsigned int)sta;
}
+static inline bool device_sta_valid(unsigned long long sta)
+{
+ /*
+ * ACPI spec says that _STA may return bit 0 clear with bit 8 set
+ * if the device is valid but does not require device driver to be
+ * loaded (chapter 6.3.7).
+ */
+ unsigned mask = ACPI_STA_DEVICE_ENABLED | ACPI_STA_DEVICE_FUNCTIONING;
+ return (sta mask) == mask;
+}
+
/**
* trim_stale_devices - remove PCI devices that are not responding.
* @dev: PCI device to start walking the hierarchy from.
@@ -745,7 +756,7 @@ static void trim_stale_devices(struct pci_dev *dev)
unsigned long long sta;
status = acpi_evaluate_integer(handle, _STA, NULL, sta);
- alive = (ACPI_SUCCESS(status) sta == ACPI_STA_ALL)
+ alive = (ACPI_SUCCESS(status) device_sta_valid(sta))
|| acpiphp_no_hotplug(handle);
}
if (!alive) {
@@ -792,7 +803,7 @@ static void acpiphp_check_bridge(struct acpiphp_bridge
*bridge) mutex_lock(slot-crit_sect);
if (slot_no_hotplug(slot)) {
; /* do nothing */
- } else if (get_slot_status(slot) == ACPI_STA_ALL) {
+ } else if (device_sta_valid(get_slot_status(slot))) {
/* remove stale devices if any */
list_for_each_entry_safe_reverse(dev, tmp,
bus-devices,
bus_list)
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 3.12: ethernet controller missing after resuming from suspend to RAM
On Tuesday, February 11, 2014 07:17:37 PM Peter Wu wrote:
On Tuesday 11 February 2014 12:42:37 Mika Westerberg wrote:
On Mon, Feb 10, 2014 at 11:39:29PM +0100, Rafael J. Wysocki wrote:
_STA() returns 0x0A instead of 0x0F. Could there be something missing in
the ACPI hotplug code that overlooks this and removes the device on
resume?
That is possible. Actually even quite likely, but let's wait for the
response from Peter.
Here's a hack that should take the 0xa return value into consideration. It
turned out that this case is even mentioned in the ACPI spec.
Tested-by: Peter Wu lekenst...@gmail.com
This works, the devices are not lost anymore after resume. dmesg
mentions the 04:00.* devices at resume compared to the unpatched kernel:
[ 42.650721] PM: Finishing wakeup.
[ 42.650768] acpiphp_glue: hotplug_event: Bus check notify on
\_SB_.PCI0.RP03
[ 42.650772] acpiphp_glue: hotplug_event: re-enumerating slots under
\_SB_.PCI0.RP03
[ 42.650874] iwlwifi :05:00.0: no hotplug settings from platform
[ 42.650722] Restarting tasks ... done.
[ 42.650985] video LNXVIDEO:00: Restoring backlight state
[ 42.650988] video LNXVIDEO:01: Restoring backlight state
[ 43.124208] ACPI: \_SB_.AC__: ACPI_NOTIFY_BUS_CHECK event: unsupported
[ 43.128401] jme :04:00.5: irq 50 for MSI/MSI-X
[ 43.153005] jme :04:00.5 eth0: Link is down
[ 43.153030] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
[ 43.154364] iwlwifi :05:00.0: L1 Enabled; Disabling L0S
[ 43.162307] iwlwifi :05:00.0: Radio type=0x1-0x3-0x1
[ 43.276220] acpiphp_glue: hotplug_event: Bus check notify on
\_SB_.PCI0.RP01
[ 43.276223] acpiphp_glue: hotplug_event: re-enumerating slots under
\_SB_.PCI0.RP01
[ 43.276257] xhci_hcd :02:00.0: no hotplug settings from platform
[ 43.276267] acpiphp_glue: hotplug_event: Bus check notify on
\_SB_.PCI0.RP02
[ 43.276268] acpiphp_glue: hotplug_event: re-enumerating slots under
\_SB_.PCI0.RP02
[ 43.276355] sdhci-pci :04:00.0: no hotplug settings from platform
[ 43.276368] pci :04:00.2: no hotplug settings from platform
[ 43.276381] jmb38x_ms :04:00.3: no hotplug settings from platform
[ 43.276393] jme :04:00.5: no hotplug settings from platform
[ 43.276398] acpiphp_glue: hotplug_event: Bus check notify on
\_SB_.PCI0.RP03
[ 43.276399] acpiphp_glue: hotplug_event: re-enumerating slots under
\_SB_.PCI0.RP03
[ 43.276491] iwlwifi :05:00.0: no hotplug settings from platform
[ 43.277214] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
Rafael, do you want me to test the other patch as well?
No, thanks!
Mika, I'll add a changelog to your patch and queue it up as a fix for 3.14.
Thanks!
diff --git a/drivers/pci/hotplug/acpiphp_glue.c
b/drivers/pci/hotplug/acpiphp_glue.c index e2a783fdb98f..014381b42d86
100644
--- a/drivers/pci/hotplug/acpiphp_glue.c
+++ b/drivers/pci/hotplug/acpiphp_glue.c
@@ -730,6 +730,17 @@ static unsigned int get_slot_status(struct acpiphp_slot
*slot) return (unsigned int)sta;
}
+static inline bool device_sta_valid(unsigned long long sta)
+{
+ /*
+* ACPI spec says that _STA may return bit 0 clear with bit 8 set
+* if the device is valid but does not require device driver to be
+* loaded (chapter 6.3.7).
+*/
+ unsigned mask = ACPI_STA_DEVICE_ENABLED | ACPI_STA_DEVICE_FUNCTIONING;
+ return (sta mask) == mask;
+}
+
/**
* trim_stale_devices - remove PCI devices that are not responding.
* @dev: PCI device to start walking the hierarchy from.
@@ -745,7 +756,7 @@ static void trim_stale_devices(struct pci_dev *dev)
unsigned long long sta;
status = acpi_evaluate_integer(handle, _STA, NULL, sta);
- alive = (ACPI_SUCCESS(status) sta == ACPI_STA_ALL)
+ alive = (ACPI_SUCCESS(status) device_sta_valid(sta))
|| acpiphp_no_hotplug(handle);
}
if (!alive) {
@@ -792,7 +803,7 @@ static void acpiphp_check_bridge(struct acpiphp_bridge
*bridge) mutex_lock(slot-crit_sect);
if (slot_no_hotplug(slot)) {
; /* do nothing */
- } else if (get_slot_status(slot) == ACPI_STA_ALL) {
+ } else if (device_sta_valid(get_slot_status(slot))) {
/* remove stale devices if any */
list_for_each_entry_safe_reverse(dev, tmp,
bus-devices,
bus_list)
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 3.12: ethernet controller missing after resuming from suspend to RAM
On 02/12/2014 12:58 AM, Rafael J. Wysocki wrote: On Tuesday, February 11, 2014 07:17:37 PM Peter Wu wrote: On Tuesday 11 February 2014 12:42:37 Mika Westerberg wrote: On Mon, Feb 10, 2014 at 11:39:29PM +0100, Rafael J. Wysocki wrote: _STA() returns 0x0A instead of 0x0F. Could there be something missing in the ACPI hotplug code that overlooks this and removes the device on resume? That is possible. Actually even quite likely, but let's wait for the response from Peter. Here's a hack that should take the 0xa return value into consideration. It turned out that this case is even mentioned in the ACPI spec. Tested-by: Peter Wu lekenst...@gmail.com This works, the devices are not lost anymore after resume. dmesg mentions the 04:00.* devices at resume compared to the unpatched kernel: [ 42.650721] PM: Finishing wakeup. [ 42.650768] acpiphp_glue: hotplug_event: Bus check notify on \_SB_.PCI0.RP03 [ 42.650772] acpiphp_glue: hotplug_event: re-enumerating slots under \_SB_.PCI0.RP03 [ 42.650874] iwlwifi :05:00.0: no hotplug settings from platform [ 42.650722] Restarting tasks ... done. [ 42.650985] video LNXVIDEO:00: Restoring backlight state [ 42.650988] video LNXVIDEO:01: Restoring backlight state [ 43.124208] ACPI: \_SB_.AC__: ACPI_NOTIFY_BUS_CHECK event: unsupported [ 43.128401] jme :04:00.5: irq 50 for MSI/MSI-X [ 43.153005] jme :04:00.5 eth0: Link is down [ 43.153030] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready [ 43.154364] iwlwifi :05:00.0: L1 Enabled; Disabling L0S [ 43.162307] iwlwifi :05:00.0: Radio type=0x1-0x3-0x1 [ 43.276220] acpiphp_glue: hotplug_event: Bus check notify on \_SB_.PCI0.RP01 [ 43.276223] acpiphp_glue: hotplug_event: re-enumerating slots under \_SB_.PCI0.RP01 [ 43.276257] xhci_hcd :02:00.0: no hotplug settings from platform [ 43.276267] acpiphp_glue: hotplug_event: Bus check notify on \_SB_.PCI0.RP02 [ 43.276268] acpiphp_glue: hotplug_event: re-enumerating slots under \_SB_.PCI0.RP02 [ 43.276355] sdhci-pci :04:00.0: no hotplug settings from platform [ 43.276368] pci :04:00.2: no hotplug settings from platform [ 43.276381] jmb38x_ms :04:00.3: no hotplug settings from platform [ 43.276393] jme :04:00.5: no hotplug settings from platform [ 43.276398] acpiphp_glue: hotplug_event: Bus check notify on \_SB_.PCI0.RP03 [ 43.276399] acpiphp_glue: hotplug_event: re-enumerating slots under \_SB_.PCI0.RP03 [ 43.276491] iwlwifi :05:00.0: no hotplug settings from platform [ 43.277214] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready Rafael, do you want me to test the other patch as well? No, thanks! Mika, I'll add a changelog to your patch and queue it up as a fix for 3.14. Thanks guys for solving this issue ! Rafael, could this be submitted to stable trees (at least 3.12, 3.13) as well ? -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 3.12: ethernet controller missing after resuming from suspend to RAM
On Monday, February 10, 2014 02:20:35 PM Mika Westerberg wrote:
> On Mon, Feb 10, 2014 at 01:10:19PM +0100, Rafael J. Wysocki wrote:
> > On Monday, February 10, 2014 02:15:22 AM Peter Wu wrote:
> > > On Monday 10 February 2014 01:52:14 Rafael J. Wysocki wrote:
> > > > > Could the following commit have something to do with it?
> > > > >
> > > > >
> > > > >
> > > > > commit 4ebe34503baa0644c9352bcd76d4cf573bffe206
> > > > > Author: Rafael J. Wysocki
> > > > > Date: Tue Jul 16 22:10:35 2013 +0200
> > > > >
> > > > >
> > > > > ACPI / hotplug / PCI: Check for new devices on enabled slots
> > > >
> > > > This one, or another one in that series. I rather suspect
> > > >
> > > > ab1225901da2 Revert "ACPI / hotplug / PCI: Avoid doing too much for
> > > > spurious
> > > > notifies"
> > > >
> > > > from Mika, but it really doesn't matter.
> > > >
> > > > Can you please check the patch below (it is on top of 3.14-rc1, but I
> > > > think
> > > > it'll still apply to 3.13) and report back?
> > >
> > > I applied the following patch:
> > >
> > > --- drivers/pci/hotplug/acpiphp_glue.c.orig 2014-02-10
> > > 01:46:59.678124018 +0100
> > > +++ drivers/pci/hotplug/acpiphp_glue.c2014-02-10 01:48:59.634124004
> > > +0100
> > > @@ -552,10 +552,10 @@
> > > struct pci_dev *dev;
> > > struct pci_bus *bus = slot->bus;
> > > struct acpiphp_func *func;
> > > - int max, pass;
> > > + int nr_found, max, pass, bridges_scanned = 0;
> > > LIST_HEAD(add_list);
> > >
> > > - acpiphp_rescan_slot(slot);
> > > + nr_found = acpiphp_rescan_slot(slot);
> > > max = acpiphp_max_busnr(bus);
> > > for (pass = 0; pass < 2; pass++) {
> > > list_for_each_entry(dev, >devices, bus_list) {
> > > @@ -571,9 +571,16 @@
> > > __pci_bus_size_bridges(dev->subordinate,
> > > _list);
> > > }
> > > + bridges_scanned++;
> > > }
> > > }
> > > }
> > > + /* Nothing more to do here if there are no new devices on this bus. */
> > > + if (!nr_found && !bridges_scanned && (slot->flags & SLOT_ENABLED)) {
> > > + pr_debug("No more new devices on this bus.\n");
> > > + return;
> > > + }
> > > +
> > > __pci_bus_assign_resources(bus, _list, NULL);
> > >
> > > acpiphp_sanitize_bus(bus);
> > >
> > > Unfortunately, the adapter still vanishes. dmesg is below this message.
> > >
> > > Peter
> > >
> > > [ 44.558995] CPU3 is up
> > > [ 44.561438] ACPI: Waking up from system sleep state S3
> > > [ 45.254084] ehci-pci :00:1a.0: System wakeup disabled by ACPI
> > > [ 45.280727] ehci-pci :00:1d.0: System wakeup disabled by ACPI
> > > [ 45.307403] xhci_hcd :02:00.0: System wakeup disabled by ACPI
> > > [ 45.361012] PM: noirq resume of devices complete after 133.354 msecs
> > > [ 45.361292] PM: early resume of devices complete after 0.233 msecs
> > > [ 45.361680] iwlwifi :05:00.0: RF_KILL bit toggled to enable radio.
> > > [ 45.361731] pcieport :00:1c.1: System wakeup disabled by ACPI
> > > [ 45.470912] snd_hda_intel :00:1b.0: irq 48 for MSI/MSI-X
> > > [ 45.700502] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
> > > [ 45.700533] ata5: SATA link down (SStatus 0 SControl 300)
> > > [ 45.701385] ata1.00: configured for UDMA/133
> > > [ 45.701503] sd 0:0:0:0: [sda] Starting disk
> > > [ 45.707139] ata2: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
> > > [ 45.872011] ata2.00: configured for UDMA/100
> > > [ 46.791141] PM: resume of devices complete after 1430.658 msecs
> > > [ 46.791560] PM: Finishing wakeup.
> > > [ 46.791565] acpiphp_glue: hotplug_event: Bus check notify on
> > > \_SB_.PCI0.RP03
> > > [ 46.791568] acpiphp_glue: hotplug_event: re-enumerating slots under
> > > \_SB_.PCI0.RP03
> > > [ 46.791642] acpiphp_glue: No more new devices on this bus.
> > > [ 46.791571] Restarting tasks ... done.
> > > [ 46.793204] video LNXVIDEO:00: Restoring backlight state
> > > [ 46.793211] video LNXVIDEO:01: Restoring backlight state
> > > [ 47.246425] ACPI: \_SB_.AC__: ACPI_NOTIFY_BUS_CHECK event: unsupported
> > > [ 47.251540] jme :04:00.5: irq 50 for MSI/MSI-X
> > > [ 47.276949] jme :04:00.5 eth0: Link is down
> >
> > I'm wondering why these two messages are printed here.
> >
> > > [ 47.276974] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
> > > [ 47.278423] iwlwifi :05:00.0: L1 Enabled; Disabling L0S
> > > [ 47.285758] iwlwifi :05:00.0: Radio type=0x1-0x3-0x1
> > > [ 47.393492] acpiphp_glue: hotplug_event: Bus check notify on
> > > \_SB_.PCI0.RP01
> > > [ 47.393495] acpiphp_glue: hotplug_event: re-enumerating slots under
> > > \_SB_.PCI0.RP01
> > > [ 47.393517] acpiphp_glue: No more new devices on this bus.
> > > [ 47.393525] acpiphp_glue: hotplug_event: Bus check notify on
> > > \_SB_.PCI0.RP02
> > > [ 47.393527]
Re: 3.12: ethernet controller missing after resuming from suspend to RAM
On Mon, Feb 10, 2014 at 01:10:19PM +0100, Rafael J. Wysocki wrote:
> On Monday, February 10, 2014 02:15:22 AM Peter Wu wrote:
> > On Monday 10 February 2014 01:52:14 Rafael J. Wysocki wrote:
> > > > Could the following commit have something to do with it?
> > > >
> > > >
> > > >
> > > > commit 4ebe34503baa0644c9352bcd76d4cf573bffe206
> > > > Author: Rafael J. Wysocki
> > > > Date: Tue Jul 16 22:10:35 2013 +0200
> > > >
> > > >
> > > > ACPI / hotplug / PCI: Check for new devices on enabled slots
> > >
> > > This one, or another one in that series. I rather suspect
> > >
> > > ab1225901da2 Revert "ACPI / hotplug / PCI: Avoid doing too much for
> > > spurious
> > > notifies"
> > >
> > > from Mika, but it really doesn't matter.
> > >
> > > Can you please check the patch below (it is on top of 3.14-rc1, but I
> > > think
> > > it'll still apply to 3.13) and report back?
> >
> > I applied the following patch:
> >
> > --- drivers/pci/hotplug/acpiphp_glue.c.orig 2014-02-10 01:46:59.678124018
> > +0100
> > +++ drivers/pci/hotplug/acpiphp_glue.c 2014-02-10 01:48:59.634124004
> > +0100
> > @@ -552,10 +552,10 @@
> > struct pci_dev *dev;
> > struct pci_bus *bus = slot->bus;
> > struct acpiphp_func *func;
> > - int max, pass;
> > + int nr_found, max, pass, bridges_scanned = 0;
> > LIST_HEAD(add_list);
> >
> > - acpiphp_rescan_slot(slot);
> > + nr_found = acpiphp_rescan_slot(slot);
> > max = acpiphp_max_busnr(bus);
> > for (pass = 0; pass < 2; pass++) {
> > list_for_each_entry(dev, >devices, bus_list) {
> > @@ -571,9 +571,16 @@
> > __pci_bus_size_bridges(dev->subordinate,
> >_list);
> > }
> > + bridges_scanned++;
> > }
> > }
> > }
> > + /* Nothing more to do here if there are no new devices on this bus. */
> > + if (!nr_found && !bridges_scanned && (slot->flags & SLOT_ENABLED)) {
> > + pr_debug("No more new devices on this bus.\n");
> > + return;
> > + }
> > +
> > __pci_bus_assign_resources(bus, _list, NULL);
> >
> > acpiphp_sanitize_bus(bus);
> >
> > Unfortunately, the adapter still vanishes. dmesg is below this message.
> >
> > Peter
> >
> > [ 44.558995] CPU3 is up
> > [ 44.561438] ACPI: Waking up from system sleep state S3
> > [ 45.254084] ehci-pci :00:1a.0: System wakeup disabled by ACPI
> > [ 45.280727] ehci-pci :00:1d.0: System wakeup disabled by ACPI
> > [ 45.307403] xhci_hcd :02:00.0: System wakeup disabled by ACPI
> > [ 45.361012] PM: noirq resume of devices complete after 133.354 msecs
> > [ 45.361292] PM: early resume of devices complete after 0.233 msecs
> > [ 45.361680] iwlwifi :05:00.0: RF_KILL bit toggled to enable radio.
> > [ 45.361731] pcieport :00:1c.1: System wakeup disabled by ACPI
> > [ 45.470912] snd_hda_intel :00:1b.0: irq 48 for MSI/MSI-X
> > [ 45.700502] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
> > [ 45.700533] ata5: SATA link down (SStatus 0 SControl 300)
> > [ 45.701385] ata1.00: configured for UDMA/133
> > [ 45.701503] sd 0:0:0:0: [sda] Starting disk
> > [ 45.707139] ata2: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
> > [ 45.872011] ata2.00: configured for UDMA/100
> > [ 46.791141] PM: resume of devices complete after 1430.658 msecs
> > [ 46.791560] PM: Finishing wakeup.
> > [ 46.791565] acpiphp_glue: hotplug_event: Bus check notify on
> > \_SB_.PCI0.RP03
> > [ 46.791568] acpiphp_glue: hotplug_event: re-enumerating slots under
> > \_SB_.PCI0.RP03
> > [ 46.791642] acpiphp_glue: No more new devices on this bus.
> > [ 46.791571] Restarting tasks ... done.
> > [ 46.793204] video LNXVIDEO:00: Restoring backlight state
> > [ 46.793211] video LNXVIDEO:01: Restoring backlight state
> > [ 47.246425] ACPI: \_SB_.AC__: ACPI_NOTIFY_BUS_CHECK event: unsupported
> > [ 47.251540] jme :04:00.5: irq 50 for MSI/MSI-X
> > [ 47.276949] jme :04:00.5 eth0: Link is down
>
> I'm wondering why these two messages are printed here.
>
> > [ 47.276974] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
> > [ 47.278423] iwlwifi :05:00.0: L1 Enabled; Disabling L0S
> > [ 47.285758] iwlwifi :05:00.0: Radio type=0x1-0x3-0x1
> > [ 47.393492] acpiphp_glue: hotplug_event: Bus check notify on
> > \_SB_.PCI0.RP01
> > [ 47.393495] acpiphp_glue: hotplug_event: re-enumerating slots under
> > \_SB_.PCI0.RP01
> > [ 47.393517] acpiphp_glue: No more new devices on this bus.
> > [ 47.393525] acpiphp_glue: hotplug_event: Bus check notify on
> > \_SB_.PCI0.RP02
> > [ 47.393527] acpiphp_glue: hotplug_event: re-enumerating slots under
> > \_SB_.PCI0.RP02
>
> Anyway, the message you've added to the patch is not printed for this bridge,
> so the condition is not satified for its bus. We need to find out why it
>
Re: 3.12: ethernet controller missing after resuming from suspend to RAM
On Monday, February 10, 2014 02:15:22 AM Peter Wu wrote:
> On Monday 10 February 2014 01:52:14 Rafael J. Wysocki wrote:
> > > Could the following commit have something to do with it?
> > >
> > >
> > >
> > > commit 4ebe34503baa0644c9352bcd76d4cf573bffe206
> > > Author: Rafael J. Wysocki
> > > Date: Tue Jul 16 22:10:35 2013 +0200
> > >
> > >
> > > ACPI / hotplug / PCI: Check for new devices on enabled slots
> >
> > This one, or another one in that series. I rather suspect
> >
> > ab1225901da2 Revert "ACPI / hotplug / PCI: Avoid doing too much for spurious
> > notifies"
> >
> > from Mika, but it really doesn't matter.
> >
> > Can you please check the patch below (it is on top of 3.14-rc1, but I think
> > it'll still apply to 3.13) and report back?
>
> I applied the following patch:
>
> --- drivers/pci/hotplug/acpiphp_glue.c.orig 2014-02-10 01:46:59.678124018
> +0100
> +++ drivers/pci/hotplug/acpiphp_glue.c2014-02-10 01:48:59.634124004
> +0100
> @@ -552,10 +552,10 @@
> struct pci_dev *dev;
> struct pci_bus *bus = slot->bus;
> struct acpiphp_func *func;
> - int max, pass;
> + int nr_found, max, pass, bridges_scanned = 0;
> LIST_HEAD(add_list);
>
> - acpiphp_rescan_slot(slot);
> + nr_found = acpiphp_rescan_slot(slot);
> max = acpiphp_max_busnr(bus);
> for (pass = 0; pass < 2; pass++) {
> list_for_each_entry(dev, >devices, bus_list) {
> @@ -571,9 +571,16 @@
> __pci_bus_size_bridges(dev->subordinate,
> _list);
> }
> + bridges_scanned++;
> }
> }
> }
> + /* Nothing more to do here if there are no new devices on this bus. */
> + if (!nr_found && !bridges_scanned && (slot->flags & SLOT_ENABLED)) {
> + pr_debug("No more new devices on this bus.\n");
> + return;
> + }
> +
> __pci_bus_assign_resources(bus, _list, NULL);
>
> acpiphp_sanitize_bus(bus);
>
> Unfortunately, the adapter still vanishes. dmesg is below this message.
>
> Peter
>
> [ 44.558995] CPU3 is up
> [ 44.561438] ACPI: Waking up from system sleep state S3
> [ 45.254084] ehci-pci :00:1a.0: System wakeup disabled by ACPI
> [ 45.280727] ehci-pci :00:1d.0: System wakeup disabled by ACPI
> [ 45.307403] xhci_hcd :02:00.0: System wakeup disabled by ACPI
> [ 45.361012] PM: noirq resume of devices complete after 133.354 msecs
> [ 45.361292] PM: early resume of devices complete after 0.233 msecs
> [ 45.361680] iwlwifi :05:00.0: RF_KILL bit toggled to enable radio.
> [ 45.361731] pcieport :00:1c.1: System wakeup disabled by ACPI
> [ 45.470912] snd_hda_intel :00:1b.0: irq 48 for MSI/MSI-X
> [ 45.700502] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
> [ 45.700533] ata5: SATA link down (SStatus 0 SControl 300)
> [ 45.701385] ata1.00: configured for UDMA/133
> [ 45.701503] sd 0:0:0:0: [sda] Starting disk
> [ 45.707139] ata2: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
> [ 45.872011] ata2.00: configured for UDMA/100
> [ 46.791141] PM: resume of devices complete after 1430.658 msecs
> [ 46.791560] PM: Finishing wakeup.
> [ 46.791565] acpiphp_glue: hotplug_event: Bus check notify on
> \_SB_.PCI0.RP03
> [ 46.791568] acpiphp_glue: hotplug_event: re-enumerating slots under
> \_SB_.PCI0.RP03
> [ 46.791642] acpiphp_glue: No more new devices on this bus.
> [ 46.791571] Restarting tasks ... done.
> [ 46.793204] video LNXVIDEO:00: Restoring backlight state
> [ 46.793211] video LNXVIDEO:01: Restoring backlight state
> [ 47.246425] ACPI: \_SB_.AC__: ACPI_NOTIFY_BUS_CHECK event: unsupported
> [ 47.251540] jme :04:00.5: irq 50 for MSI/MSI-X
> [ 47.276949] jme :04:00.5 eth0: Link is down
I'm wondering why these two messages are printed here.
> [ 47.276974] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
> [ 47.278423] iwlwifi :05:00.0: L1 Enabled; Disabling L0S
> [ 47.285758] iwlwifi :05:00.0: Radio type=0x1-0x3-0x1
> [ 47.393492] acpiphp_glue: hotplug_event: Bus check notify on
> \_SB_.PCI0.RP01
> [ 47.393495] acpiphp_glue: hotplug_event: re-enumerating slots under
> \_SB_.PCI0.RP01
> [ 47.393517] acpiphp_glue: No more new devices on this bus.
> [ 47.393525] acpiphp_glue: hotplug_event: Bus check notify on
> \_SB_.PCI0.RP02
> [ 47.393527] acpiphp_glue: hotplug_event: re-enumerating slots under
> \_SB_.PCI0.RP02
Anyway, the message you've added to the patch is not printed for this bridge,
so the condition is not satified for its bus. We need to find out why it isn't
satisfied and what exactly happens to the devices that appear to go away.
Please apply the appended patch instead of the previous one and check the
output.
Thanks,
Rafael
---
drivers/pci/hotplug/acpiphp_glue.c | 37
Re: 3.12: ethernet controller missing after resuming from suspend to RAM
On 02/09/2014 07:44 PM, Bastien Traverse wrote: > Le 07/02/2014 02:19, Rafael J. Wysocki a écrit : >> Please send the output of lspci -vv right before suspend and right after >> the subsequent resume as attachments. > > You'll find them attached, but I got a strange error when I wanted to > run it as root: > $ sudo lspci -vv > lspci_vv_before > pcilib: sysfs_read_vpd: read failed: Connection timed out > $ sudo -i > # lspci -vv > pcilib: sysfs_read_vpd: read failed: Connection timed out > > So I only got the unpriviledge output. > > Some complementary lines from my journal: > > kernel: r8169 Gigabit Ethernet driver 2.3LK-NAPI loaded > kernel: r8169 :03:00.2: can't disable ASPM; OS doesn't have ASPM control > kernel: pcieport :00:1c.3: driver skip pci_set_master, fix it! > kernel: r8169 :03:00.2: irq 44 for MSI/MSI-X > kernel: r8169 :03:00.2 eth0: RTL8411 at 0xc90016ed4000, > 00:90:f5:d7:34:53, XID 08800800 IRQ 44 > kernel: r8169 :03:00.2 eth0: jumbo features [frames: 9200 bytes, tx > checksumming: ko] > kernel: rtsx_pci :03:00.0: irq 45 for MSI/MSI-X > kernel: rtsx_pci :03:00.0: rtsx_pci_acquire_irq: pcr->msi_en = 1, > pci->irq = 45 > ... > > And one I thought of interest: > > kernel: rtsx_pci :03:00.0: vpd r/w failed. This is likely a > firmware bug on this device. Contact the card vendor for a firmware update. > > That came three times before suspend. > > Only two lines about hotplug, none special. > > Stripped journal attached for the suspend cycle. > > > Le 07/02/2014 08:29, Francis Moreau a écrit : >> yeah, but calling this "fast resolution" is quite incorrect. >> >> I don't blame anyone for this and I'm quite happy that a workaround has >> been found at last but calling this "fast resolution" is a bit funny >> compare to the PITA it was to debug this. > > Sorry, I didn't mean to underestimate the amount of work you put in that > bug resolution (actually it was the first time I heard of kernel > bisection and was pretty impressed by how you led it). No problem Bastien and don't be impressed by this :). Bisection thing is a mechanical work but can be useful sometimes when we, users, are lost and have no clue on what's going on. The real PITA in that case was to reboot more than 10 times the system in order to test each suspicious commits on a live system. Anyways, good luck, all my hopes are on you now :) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 3.12: ethernet controller missing after resuming from suspend to RAM
On 02/09/2014 07:44 PM, Bastien Traverse wrote: Le 07/02/2014 02:19, Rafael J. Wysocki a écrit : Please send the output of lspci -vv right before suspend and right after the subsequent resume as attachments. You'll find them attached, but I got a strange error when I wanted to run it as root: $ sudo lspci -vv lspci_vv_before pcilib: sysfs_read_vpd: read failed: Connection timed out $ sudo -i # lspci -vv pcilib: sysfs_read_vpd: read failed: Connection timed out So I only got the unpriviledge output. Some complementary lines from my journal: kernel: r8169 Gigabit Ethernet driver 2.3LK-NAPI loaded kernel: r8169 :03:00.2: can't disable ASPM; OS doesn't have ASPM control kernel: pcieport :00:1c.3: driver skip pci_set_master, fix it! kernel: r8169 :03:00.2: irq 44 for MSI/MSI-X kernel: r8169 :03:00.2 eth0: RTL8411 at 0xc90016ed4000, 00:90:f5:d7:34:53, XID 08800800 IRQ 44 kernel: r8169 :03:00.2 eth0: jumbo features [frames: 9200 bytes, tx checksumming: ko] kernel: rtsx_pci :03:00.0: irq 45 for MSI/MSI-X kernel: rtsx_pci :03:00.0: rtsx_pci_acquire_irq: pcr-msi_en = 1, pci-irq = 45 ... And one I thought of interest: kernel: rtsx_pci :03:00.0: vpd r/w failed. This is likely a firmware bug on this device. Contact the card vendor for a firmware update. That came three times before suspend. Only two lines about hotplug, none special. Stripped journal attached for the suspend cycle. Le 07/02/2014 08:29, Francis Moreau a écrit : yeah, but calling this fast resolution is quite incorrect. I don't blame anyone for this and I'm quite happy that a workaround has been found at last but calling this fast resolution is a bit funny compare to the PITA it was to debug this. Sorry, I didn't mean to underestimate the amount of work you put in that bug resolution (actually it was the first time I heard of kernel bisection and was pretty impressed by how you led it). No problem Bastien and don't be impressed by this :). Bisection thing is a mechanical work but can be useful sometimes when we, users, are lost and have no clue on what's going on. The real PITA in that case was to reboot more than 10 times the system in order to test each suspicious commits on a live system. Anyways, good luck, all my hopes are on you now :) -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 3.12: ethernet controller missing after resuming from suspend to RAM
On Monday, February 10, 2014 02:15:22 AM Peter Wu wrote:
On Monday 10 February 2014 01:52:14 Rafael J. Wysocki wrote:
Could the following commit have something to do with it?
commit 4ebe34503baa0644c9352bcd76d4cf573bffe206
Author: Rafael J. Wysocki rafael.j.wyso...@intel.com
Date: Tue Jul 16 22:10:35 2013 +0200
ACPI / hotplug / PCI: Check for new devices on enabled slots
This one, or another one in that series. I rather suspect
ab1225901da2 Revert ACPI / hotplug / PCI: Avoid doing too much for spurious
notifies
from Mika, but it really doesn't matter.
Can you please check the patch below (it is on top of 3.14-rc1, but I think
it'll still apply to 3.13) and report back?
I applied the following patch:
--- drivers/pci/hotplug/acpiphp_glue.c.orig 2014-02-10 01:46:59.678124018
+0100
+++ drivers/pci/hotplug/acpiphp_glue.c2014-02-10 01:48:59.634124004
+0100
@@ -552,10 +552,10 @@
struct pci_dev *dev;
struct pci_bus *bus = slot-bus;
struct acpiphp_func *func;
- int max, pass;
+ int nr_found, max, pass, bridges_scanned = 0;
LIST_HEAD(add_list);
- acpiphp_rescan_slot(slot);
+ nr_found = acpiphp_rescan_slot(slot);
max = acpiphp_max_busnr(bus);
for (pass = 0; pass 2; pass++) {
list_for_each_entry(dev, bus-devices, bus_list) {
@@ -571,9 +571,16 @@
__pci_bus_size_bridges(dev-subordinate,
add_list);
}
+ bridges_scanned++;
}
}
}
+ /* Nothing more to do here if there are no new devices on this bus. */
+ if (!nr_found !bridges_scanned (slot-flags SLOT_ENABLED)) {
+ pr_debug(No more new devices on this bus.\n);
+ return;
+ }
+
__pci_bus_assign_resources(bus, add_list, NULL);
acpiphp_sanitize_bus(bus);
Unfortunately, the adapter still vanishes. dmesg is below this message.
Peter
[ 44.558995] CPU3 is up
[ 44.561438] ACPI: Waking up from system sleep state S3
[ 45.254084] ehci-pci :00:1a.0: System wakeup disabled by ACPI
[ 45.280727] ehci-pci :00:1d.0: System wakeup disabled by ACPI
[ 45.307403] xhci_hcd :02:00.0: System wakeup disabled by ACPI
[ 45.361012] PM: noirq resume of devices complete after 133.354 msecs
[ 45.361292] PM: early resume of devices complete after 0.233 msecs
[ 45.361680] iwlwifi :05:00.0: RF_KILL bit toggled to enable radio.
[ 45.361731] pcieport :00:1c.1: System wakeup disabled by ACPI
[ 45.470912] snd_hda_intel :00:1b.0: irq 48 for MSI/MSI-X
[ 45.700502] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
[ 45.700533] ata5: SATA link down (SStatus 0 SControl 300)
[ 45.701385] ata1.00: configured for UDMA/133
[ 45.701503] sd 0:0:0:0: [sda] Starting disk
[ 45.707139] ata2: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[ 45.872011] ata2.00: configured for UDMA/100
[ 46.791141] PM: resume of devices complete after 1430.658 msecs
[ 46.791560] PM: Finishing wakeup.
[ 46.791565] acpiphp_glue: hotplug_event: Bus check notify on
\_SB_.PCI0.RP03
[ 46.791568] acpiphp_glue: hotplug_event: re-enumerating slots under
\_SB_.PCI0.RP03
[ 46.791642] acpiphp_glue: No more new devices on this bus.
[ 46.791571] Restarting tasks ... done.
[ 46.793204] video LNXVIDEO:00: Restoring backlight state
[ 46.793211] video LNXVIDEO:01: Restoring backlight state
[ 47.246425] ACPI: \_SB_.AC__: ACPI_NOTIFY_BUS_CHECK event: unsupported
[ 47.251540] jme :04:00.5: irq 50 for MSI/MSI-X
[ 47.276949] jme :04:00.5 eth0: Link is down
I'm wondering why these two messages are printed here.
[ 47.276974] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
[ 47.278423] iwlwifi :05:00.0: L1 Enabled; Disabling L0S
[ 47.285758] iwlwifi :05:00.0: Radio type=0x1-0x3-0x1
[ 47.393492] acpiphp_glue: hotplug_event: Bus check notify on
\_SB_.PCI0.RP01
[ 47.393495] acpiphp_glue: hotplug_event: re-enumerating slots under
\_SB_.PCI0.RP01
[ 47.393517] acpiphp_glue: No more new devices on this bus.
[ 47.393525] acpiphp_glue: hotplug_event: Bus check notify on
\_SB_.PCI0.RP02
[ 47.393527] acpiphp_glue: hotplug_event: re-enumerating slots under
\_SB_.PCI0.RP02
Anyway, the message you've added to the patch is not printed for this bridge,
so the condition is not satified for its bus. We need to find out why it isn't
satisfied and what exactly happens to the devices that appear to go away.
Please apply the appended patch instead of the previous one and check the
output.
Thanks,
Rafael
---
drivers/pci/hotplug/acpiphp_glue.c | 37 ++---
1 file changed, 26 insertions(+), 11 deletions(-)
Index:
Re: 3.12: ethernet controller missing after resuming from suspend to RAM
On Mon, Feb 10, 2014 at 01:10:19PM +0100, Rafael J. Wysocki wrote:
On Monday, February 10, 2014 02:15:22 AM Peter Wu wrote:
On Monday 10 February 2014 01:52:14 Rafael J. Wysocki wrote:
Could the following commit have something to do with it?
commit 4ebe34503baa0644c9352bcd76d4cf573bffe206
Author: Rafael J. Wysocki rafael.j.wyso...@intel.com
Date: Tue Jul 16 22:10:35 2013 +0200
ACPI / hotplug / PCI: Check for new devices on enabled slots
This one, or another one in that series. I rather suspect
ab1225901da2 Revert ACPI / hotplug / PCI: Avoid doing too much for
spurious
notifies
from Mika, but it really doesn't matter.
Can you please check the patch below (it is on top of 3.14-rc1, but I
think
it'll still apply to 3.13) and report back?
I applied the following patch:
--- drivers/pci/hotplug/acpiphp_glue.c.orig 2014-02-10 01:46:59.678124018
+0100
+++ drivers/pci/hotplug/acpiphp_glue.c 2014-02-10 01:48:59.634124004
+0100
@@ -552,10 +552,10 @@
struct pci_dev *dev;
struct pci_bus *bus = slot-bus;
struct acpiphp_func *func;
- int max, pass;
+ int nr_found, max, pass, bridges_scanned = 0;
LIST_HEAD(add_list);
- acpiphp_rescan_slot(slot);
+ nr_found = acpiphp_rescan_slot(slot);
max = acpiphp_max_busnr(bus);
for (pass = 0; pass 2; pass++) {
list_for_each_entry(dev, bus-devices, bus_list) {
@@ -571,9 +571,16 @@
__pci_bus_size_bridges(dev-subordinate,
add_list);
}
+ bridges_scanned++;
}
}
}
+ /* Nothing more to do here if there are no new devices on this bus. */
+ if (!nr_found !bridges_scanned (slot-flags SLOT_ENABLED)) {
+ pr_debug(No more new devices on this bus.\n);
+ return;
+ }
+
__pci_bus_assign_resources(bus, add_list, NULL);
acpiphp_sanitize_bus(bus);
Unfortunately, the adapter still vanishes. dmesg is below this message.
Peter
[ 44.558995] CPU3 is up
[ 44.561438] ACPI: Waking up from system sleep state S3
[ 45.254084] ehci-pci :00:1a.0: System wakeup disabled by ACPI
[ 45.280727] ehci-pci :00:1d.0: System wakeup disabled by ACPI
[ 45.307403] xhci_hcd :02:00.0: System wakeup disabled by ACPI
[ 45.361012] PM: noirq resume of devices complete after 133.354 msecs
[ 45.361292] PM: early resume of devices complete after 0.233 msecs
[ 45.361680] iwlwifi :05:00.0: RF_KILL bit toggled to enable radio.
[ 45.361731] pcieport :00:1c.1: System wakeup disabled by ACPI
[ 45.470912] snd_hda_intel :00:1b.0: irq 48 for MSI/MSI-X
[ 45.700502] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
[ 45.700533] ata5: SATA link down (SStatus 0 SControl 300)
[ 45.701385] ata1.00: configured for UDMA/133
[ 45.701503] sd 0:0:0:0: [sda] Starting disk
[ 45.707139] ata2: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[ 45.872011] ata2.00: configured for UDMA/100
[ 46.791141] PM: resume of devices complete after 1430.658 msecs
[ 46.791560] PM: Finishing wakeup.
[ 46.791565] acpiphp_glue: hotplug_event: Bus check notify on
\_SB_.PCI0.RP03
[ 46.791568] acpiphp_glue: hotplug_event: re-enumerating slots under
\_SB_.PCI0.RP03
[ 46.791642] acpiphp_glue: No more new devices on this bus.
[ 46.791571] Restarting tasks ... done.
[ 46.793204] video LNXVIDEO:00: Restoring backlight state
[ 46.793211] video LNXVIDEO:01: Restoring backlight state
[ 47.246425] ACPI: \_SB_.AC__: ACPI_NOTIFY_BUS_CHECK event: unsupported
[ 47.251540] jme :04:00.5: irq 50 for MSI/MSI-X
[ 47.276949] jme :04:00.5 eth0: Link is down
I'm wondering why these two messages are printed here.
[ 47.276974] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
[ 47.278423] iwlwifi :05:00.0: L1 Enabled; Disabling L0S
[ 47.285758] iwlwifi :05:00.0: Radio type=0x1-0x3-0x1
[ 47.393492] acpiphp_glue: hotplug_event: Bus check notify on
\_SB_.PCI0.RP01
[ 47.393495] acpiphp_glue: hotplug_event: re-enumerating slots under
\_SB_.PCI0.RP01
[ 47.393517] acpiphp_glue: No more new devices on this bus.
[ 47.393525] acpiphp_glue: hotplug_event: Bus check notify on
\_SB_.PCI0.RP02
[ 47.393527] acpiphp_glue: hotplug_event: re-enumerating slots under
\_SB_.PCI0.RP02
Anyway, the message you've added to the patch is not printed for this bridge,
so the condition is not satified for its bus. We need to find out why it
isn't
satisfied and what exactly happens to the devices that appear to go away.
One thing, I noticed when checking the DSDT:
Device (J380)
{
Method (_STA, 0, NotSerialized) // _STA: Status
Re: 3.12: ethernet controller missing after resuming from suspend to RAM
On Monday, February 10, 2014 02:20:35 PM Mika Westerberg wrote:
On Mon, Feb 10, 2014 at 01:10:19PM +0100, Rafael J. Wysocki wrote:
On Monday, February 10, 2014 02:15:22 AM Peter Wu wrote:
On Monday 10 February 2014 01:52:14 Rafael J. Wysocki wrote:
Could the following commit have something to do with it?
commit 4ebe34503baa0644c9352bcd76d4cf573bffe206
Author: Rafael J. Wysocki rafael.j.wyso...@intel.com
Date: Tue Jul 16 22:10:35 2013 +0200
ACPI / hotplug / PCI: Check for new devices on enabled slots
This one, or another one in that series. I rather suspect
ab1225901da2 Revert ACPI / hotplug / PCI: Avoid doing too much for
spurious
notifies
from Mika, but it really doesn't matter.
Can you please check the patch below (it is on top of 3.14-rc1, but I
think
it'll still apply to 3.13) and report back?
I applied the following patch:
--- drivers/pci/hotplug/acpiphp_glue.c.orig 2014-02-10
01:46:59.678124018 +0100
+++ drivers/pci/hotplug/acpiphp_glue.c2014-02-10 01:48:59.634124004
+0100
@@ -552,10 +552,10 @@
struct pci_dev *dev;
struct pci_bus *bus = slot-bus;
struct acpiphp_func *func;
- int max, pass;
+ int nr_found, max, pass, bridges_scanned = 0;
LIST_HEAD(add_list);
- acpiphp_rescan_slot(slot);
+ nr_found = acpiphp_rescan_slot(slot);
max = acpiphp_max_busnr(bus);
for (pass = 0; pass 2; pass++) {
list_for_each_entry(dev, bus-devices, bus_list) {
@@ -571,9 +571,16 @@
__pci_bus_size_bridges(dev-subordinate,
add_list);
}
+ bridges_scanned++;
}
}
}
+ /* Nothing more to do here if there are no new devices on this bus. */
+ if (!nr_found !bridges_scanned (slot-flags SLOT_ENABLED)) {
+ pr_debug(No more new devices on this bus.\n);
+ return;
+ }
+
__pci_bus_assign_resources(bus, add_list, NULL);
acpiphp_sanitize_bus(bus);
Unfortunately, the adapter still vanishes. dmesg is below this message.
Peter
[ 44.558995] CPU3 is up
[ 44.561438] ACPI: Waking up from system sleep state S3
[ 45.254084] ehci-pci :00:1a.0: System wakeup disabled by ACPI
[ 45.280727] ehci-pci :00:1d.0: System wakeup disabled by ACPI
[ 45.307403] xhci_hcd :02:00.0: System wakeup disabled by ACPI
[ 45.361012] PM: noirq resume of devices complete after 133.354 msecs
[ 45.361292] PM: early resume of devices complete after 0.233 msecs
[ 45.361680] iwlwifi :05:00.0: RF_KILL bit toggled to enable radio.
[ 45.361731] pcieport :00:1c.1: System wakeup disabled by ACPI
[ 45.470912] snd_hda_intel :00:1b.0: irq 48 for MSI/MSI-X
[ 45.700502] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
[ 45.700533] ata5: SATA link down (SStatus 0 SControl 300)
[ 45.701385] ata1.00: configured for UDMA/133
[ 45.701503] sd 0:0:0:0: [sda] Starting disk
[ 45.707139] ata2: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[ 45.872011] ata2.00: configured for UDMA/100
[ 46.791141] PM: resume of devices complete after 1430.658 msecs
[ 46.791560] PM: Finishing wakeup.
[ 46.791565] acpiphp_glue: hotplug_event: Bus check notify on
\_SB_.PCI0.RP03
[ 46.791568] acpiphp_glue: hotplug_event: re-enumerating slots under
\_SB_.PCI0.RP03
[ 46.791642] acpiphp_glue: No more new devices on this bus.
[ 46.791571] Restarting tasks ... done.
[ 46.793204] video LNXVIDEO:00: Restoring backlight state
[ 46.793211] video LNXVIDEO:01: Restoring backlight state
[ 47.246425] ACPI: \_SB_.AC__: ACPI_NOTIFY_BUS_CHECK event: unsupported
[ 47.251540] jme :04:00.5: irq 50 for MSI/MSI-X
[ 47.276949] jme :04:00.5 eth0: Link is down
I'm wondering why these two messages are printed here.
[ 47.276974] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
[ 47.278423] iwlwifi :05:00.0: L1 Enabled; Disabling L0S
[ 47.285758] iwlwifi :05:00.0: Radio type=0x1-0x3-0x1
[ 47.393492] acpiphp_glue: hotplug_event: Bus check notify on
\_SB_.PCI0.RP01
[ 47.393495] acpiphp_glue: hotplug_event: re-enumerating slots under
\_SB_.PCI0.RP01
[ 47.393517] acpiphp_glue: No more new devices on this bus.
[ 47.393525] acpiphp_glue: hotplug_event: Bus check notify on
\_SB_.PCI0.RP02
[ 47.393527] acpiphp_glue: hotplug_event: re-enumerating slots under
\_SB_.PCI0.RP02
Anyway, the message you've added to the patch is not printed for this
bridge,
so the condition is not satified for its bus. We need to find out why it
isn't
satisfied and what exactly happens to the devices that appear to go away.
One thing, I
Re: 3.12: ethernet controller missing after resuming from suspend to RAM
On Monday 10 February 2014 01:52:14 Rafael J. Wysocki wrote:
> > Could the following commit have something to do with it?
> >
> >
> >
> > commit 4ebe34503baa0644c9352bcd76d4cf573bffe206
> > Author: Rafael J. Wysocki
> > Date: Tue Jul 16 22:10:35 2013 +0200
> >
> >
> > ACPI / hotplug / PCI: Check for new devices on enabled slots
>
> This one, or another one in that series. I rather suspect
>
> ab1225901da2 Revert "ACPI / hotplug / PCI: Avoid doing too much for spurious
> notifies"
>
> from Mika, but it really doesn't matter.
>
> Can you please check the patch below (it is on top of 3.14-rc1, but I think
> it'll still apply to 3.13) and report back?
I applied the following patch:
--- drivers/pci/hotplug/acpiphp_glue.c.orig 2014-02-10 01:46:59.678124018
+0100
+++ drivers/pci/hotplug/acpiphp_glue.c 2014-02-10 01:48:59.634124004 +0100
@@ -552,10 +552,10 @@
struct pci_dev *dev;
struct pci_bus *bus = slot->bus;
struct acpiphp_func *func;
- int max, pass;
+ int nr_found, max, pass, bridges_scanned = 0;
LIST_HEAD(add_list);
- acpiphp_rescan_slot(slot);
+ nr_found = acpiphp_rescan_slot(slot);
max = acpiphp_max_busnr(bus);
for (pass = 0; pass < 2; pass++) {
list_for_each_entry(dev, >devices, bus_list) {
@@ -571,9 +571,16 @@
__pci_bus_size_bridges(dev->subordinate,
_list);
}
+ bridges_scanned++;
}
}
}
+ /* Nothing more to do here if there are no new devices on this bus. */
+ if (!nr_found && !bridges_scanned && (slot->flags & SLOT_ENABLED)) {
+ pr_debug("No more new devices on this bus.\n");
+ return;
+ }
+
__pci_bus_assign_resources(bus, _list, NULL);
acpiphp_sanitize_bus(bus);
Unfortunately, the adapter still vanishes. dmesg is below this message.
Peter
[ 44.558995] CPU3 is up
[ 44.561438] ACPI: Waking up from system sleep state S3
[ 45.254084] ehci-pci :00:1a.0: System wakeup disabled by ACPI
[ 45.280727] ehci-pci :00:1d.0: System wakeup disabled by ACPI
[ 45.307403] xhci_hcd :02:00.0: System wakeup disabled by ACPI
[ 45.361012] PM: noirq resume of devices complete after 133.354 msecs
[ 45.361292] PM: early resume of devices complete after 0.233 msecs
[ 45.361680] iwlwifi :05:00.0: RF_KILL bit toggled to enable radio.
[ 45.361731] pcieport :00:1c.1: System wakeup disabled by ACPI
[ 45.470912] snd_hda_intel :00:1b.0: irq 48 for MSI/MSI-X
[ 45.700502] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
[ 45.700533] ata5: SATA link down (SStatus 0 SControl 300)
[ 45.701385] ata1.00: configured for UDMA/133
[ 45.701503] sd 0:0:0:0: [sda] Starting disk
[ 45.707139] ata2: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[ 45.872011] ata2.00: configured for UDMA/100
[ 46.791141] PM: resume of devices complete after 1430.658 msecs
[ 46.791560] PM: Finishing wakeup.
[ 46.791565] acpiphp_glue: hotplug_event: Bus check notify on \_SB_.PCI0.RP03
[ 46.791568] acpiphp_glue: hotplug_event: re-enumerating slots under
\_SB_.PCI0.RP03
[ 46.791642] acpiphp_glue: No more new devices on this bus.
[ 46.791571] Restarting tasks ... done.
[ 46.793204] video LNXVIDEO:00: Restoring backlight state
[ 46.793211] video LNXVIDEO:01: Restoring backlight state
[ 47.246425] ACPI: \_SB_.AC__: ACPI_NOTIFY_BUS_CHECK event: unsupported
[ 47.251540] jme :04:00.5: irq 50 for MSI/MSI-X
[ 47.276949] jme :04:00.5 eth0: Link is down
[ 47.276974] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
[ 47.278423] iwlwifi :05:00.0: L1 Enabled; Disabling L0S
[ 47.285758] iwlwifi :05:00.0: Radio type=0x1-0x3-0x1
[ 47.393492] acpiphp_glue: hotplug_event: Bus check notify on \_SB_.PCI0.RP01
[ 47.393495] acpiphp_glue: hotplug_event: re-enumerating slots under
\_SB_.PCI0.RP01
[ 47.393517] acpiphp_glue: No more new devices on this bus.
[ 47.393525] acpiphp_glue: hotplug_event: Bus check notify on \_SB_.PCI0.RP02
[ 47.393527] acpiphp_glue: hotplug_event: re-enumerating slots under
\_SB_.PCI0.RP02
[ 47.398977] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
[ 47.463615] acpiphp_glue: hotplug_event: Bus check notify on \_SB_.PCI0.RP03
[ 47.463620] acpiphp_glue: hotplug_event: re-enumerating slots under
\_SB_.PCI0.RP03
[ 47.463685] acpiphp_glue: No more new devices on this bus.
After the last message, NetworkManager loses the interface within a second.
The next following messages follow two seconds later and are unrelated
(those are about wireless connectivity).
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please
Re: 3.12: ethernet controller missing after resuming from suspend to RAM
On Monday, February 10, 2014 12:18:16 AM Peter Wu wrote:
> 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 :00:1a.0: System wakeup disabled by ACPI
> [ 56.213939] ehci-pci :00:1d.0: System wakeup disabled by ACPI
> [ 56.240614] xhci_hcd :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 :00:1c.1: System wakeup disabled by ACPI
> [ 56.296628] iwlwifi :05:00.0: RF_KILL bit toggled to enable radio.
> [ 56.404258] snd_hda_intel :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 :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 :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 :04:00.5: irq 50 for MSI/MSI-X
> [ 58.233503] jme :04:00.5 eth0: Link is down
> [ 58.233578] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
> [ 58.235113] iwlwifi :05:00.0: L1 Enabled; Disabling L0S
> [ 58.242131] iwlwifi :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 :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
> Date: Tue Jul 16 22:10:35 2013 +0200
>
> ACPI / hotplug / PCI: Check for new devices on enabled slots
This one, or another one in that series. I rather suspect
ab1225901da2 Revert "ACPI / hotplug / PCI: Avoid doing too much for spurious
notifies"
from Mika, but it really doesn't matter.
Can you please check the patch below (it is on top of 3.14-rc1, but I think
it'll
still apply to 3.13) and report back?
Rafael
---
drivers/pci/hotplug/acpiphp_glue.c |9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
Index: linux-pm/drivers/pci/hotplug/acpiphp_glue.c
===
--- linux-pm.orig/drivers/pci/hotplug/acpiphp_glue.c
+++ linux-pm/drivers/pci/hotplug/acpiphp_glue.c
@@ -555,10 +555,10 @@ static void __ref enable_slot(struct acp
struct pci_dev *dev;
struct pci_bus *bus = slot->bus;
struct acpiphp_func *func;
- int max, pass;
+ int nr_found, max, pass, bridges_scanned = 0;
LIST_HEAD(add_list);
- acpiphp_rescan_slot(slot);
+ nr_found = acpiphp_rescan_slot(slot);
max = acpiphp_max_busnr(bus);
for (pass = 0; pass < 2; pass++) {
list_for_each_entry(dev, >devices, bus_list) {
@@ -574,9 +574,14 @@ static void __ref enable_slot(struct acp
__pci_bus_size_bridges(dev->subordinate,
Re: 3.12: ethernet controller missing after resuming from suspend to RAM
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 :00:1a.0: System wakeup disabled by ACPI [ 56.213939] ehci-pci :00:1d.0: System wakeup disabled by ACPI [ 56.240614] xhci_hcd :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 :00:1c.1: System wakeup disabled by ACPI [ 56.296628] iwlwifi :05:00.0: RF_KILL bit toggled to enable radio. [ 56.404258] snd_hda_intel :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 :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 :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 :04:00.5: irq 50 for MSI/MSI-X [ 58.233503] jme :04:00.5 eth0: Link is down [ 58.233578] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready [ 58.235113] iwlwifi :05:00.0: L1 Enabled; Disabling L0S [ 58.242131] iwlwifi :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 :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 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
Re: 3.12: ethernet controller missing after resuming from suspend to RAM
On Sunday 09 February 2014 19:44:27 Bastien Traverse wrote: > You'll find them attached, but I got a strange error when I wanted to > run it as root: > $ sudo lspci -vv > lspci_vv_before > pcilib: sysfs_read_vpd: read failed: Connection timed out > $ sudo -i > # lspci -vv > pcilib: sysfs_read_vpd: read failed: Connection timed out > > So I only got the unpriviledge output. This seems to be an issue of the rtsx driver / hardware, I also see it on a small Shuttle computer that runs at work. (off-topic lspci post:) 02:00.0 Unassigned class [ff00]: Realtek Semiconductor Co., Ltd. Device [10ec:5289] (rev 01) Subsystem: Realtek Semiconductor Co., Ltd. Device [10ec:5289] Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- Some complementary lines from my journal: > > kernel: r8169 Gigabit Ethernet driver 2.3LK-NAPI loaded > kernel: r8169 :03:00.2: can't disable ASPM; OS doesn't have ASPM control > kernel: pcieport :00:1c.3: driver skip pci_set_master, fix it! kernel: > r8169 :03:00.2: irq 44 for MSI/MSI-X > kernel: r8169 :03:00.2 eth0: RTL8411 at 0xc90016ed4000, > 00:90:f5:d7:34:53, XID 08800800 IRQ 44 > kernel: r8169 :03:00.2 eth0: jumbo features [frames: 9200 bytes, tx > checksumming: ko] > kernel: rtsx_pci :03:00.0: irq 45 for MSI/MSI-X > kernel: rtsx_pci :03:00.0: rtsx_pci_acquire_irq: pcr->msi_en = 1, > pci->irq = 45 > ... > > And one I thought of interest: > > kernel: rtsx_pci :03:00.0: vpd r/w failed. This is likely a > firmware bug on this device. Contact the card vendor for a firmware update. I think I have seen such an error before, but I cannot find it in the logs that were obtained a while ago. Failure to read VPD should not cause issues. > That came three times before suspend. > > Only two lines about hotplug, none special. I think this is relevant. See also my test with 3.13.2 and different kernel configs[1]. A workaround that triggers a scan was also posted[2]. Peter [1]: http://lkml.org/lkml/2014/2/8/264 [2]: http://lkml.org/lkml/2014/2/7/809 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 3.12: ethernet controller missing after resuming from suspend to RAM
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 :05:00.0: no hotplug settings from platform > xhci_hcd :02:00.0: no hotplug settings from platform > (here, NetworkManager complains that a device has gone) > iwlwifi :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! -- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 3.12: ethernet controller missing after resuming from suspend to RAM
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 :05:00.0: no hotplug settings from platform xhci_hcd :02:00.0: no hotplug settings from platform (here, NetworkManager complains that a device has gone) iwlwifi :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! -- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 3.12: ethernet controller missing after resuming from suspend to RAM
On Sunday 09 February 2014 19:44:27 Bastien Traverse wrote: You'll find them attached, but I got a strange error when I wanted to run it as root: $ sudo lspci -vv lspci_vv_before pcilib: sysfs_read_vpd: read failed: Connection timed out $ sudo -i # lspci -vv pcilib: sysfs_read_vpd: read failed: Connection timed out So I only got the unpriviledge output. This seems to be an issue of the rtsx driver / hardware, I also see it on a small Shuttle computer that runs at work. (off-topic lspci post:) 02:00.0 Unassigned class [ff00]: Realtek Semiconductor Co., Ltd. Device [10ec:5289] (rev 01) Subsystem: Realtek Semiconductor Co., Ltd. Device [10ec:5289] 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 43 Region 0: Memory at dfe0 (32-bit, non-prefetchable) [size=64K] Capabilities: [40] Power Management version 3 Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=375mA PME(D0-,D1+,D2+,D3hot+,D3cold+) Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME- Capabilities: [50] MSI: Enable+ Count=1/1 Maskable- 64bit+ Address: fee0f00c Data: 41c1 Capabilities: [70] Express (v2) Endpoint, MSI 00 DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s 512ns, L1 64us ExtTag- AttnBtn- AttnInd- PwrInd- RBE+ FLReset- DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported- RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop- MaxPayload 128 bytes, MaxReadReq 512 bytes DevSta: CorrErr+ UncorrErr- FatalErr- UnsuppReq+ AuxPwr+ TransPend- LnkCap: Port #0, Speed 2.5GT/s, Width x1, ASPM L0s L1, Latency L0 unlimited, L1 64us ClockPM+ Surprise- LLActRep- BwNot- LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk+ ExtSynch- ClockPM+ AutWidDis- BWInt- AutBWInt- LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt- DevCap2: Completion Timeout: Range ABCD, TimeoutDis+, LTR-, OBFF Not Supported DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis-, LTR-, OBFF Disabled LnkCtl2: Target Link Speed: 2.5GT/s, EnterCompliance- SpeedDis- Transmit Margin: Normal Operating Range, EnterModifiedCompliance- ComplianceSOS- Compliance De-emphasis: -6dB LnkSta2: Current De-emphasis Level: -6dB, EqualizationComplete-, EqualizationPhase1- EqualizationPhase2-, EqualizationPhase3-, LinkEqualizationRequest- Capabilities: [b0] MSI-X: Enable- Count=1 Masked- Vector table: BAR=0 offset= PBA: BAR=0 offset= Capabilities: [d0] Vital Product Data pcilib: sysfs_read_vpd: read failed: Connection timed out Not readable Capabilities: [100 v1] Advanced Error Reporting UESta: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol- UEMsk: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol- UESvrt: DLP+ SDES+ TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol- CESta: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr+ CEMsk: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr+ AERCap: First Error Pointer: 00, GenCap+ CGenEn- ChkCap+ ChkEn- Capabilities: [140 v1] Virtual Channel Caps: LPEVC=0 RefClk=100ns PATEntryBits=1 Arb:Fixed- WRR32- WRR64- WRR128- Ctrl: ArbSelect=Fixed Status: InProgress- VC0:Caps: PATOffset=00 MaxTimeSlots=1 RejSnoopTrans- Arb:Fixed- WRR32- WRR64- WRR128- TWRR128- WRR256- Ctrl: Enable+ ID=0 ArbSelect=Fixed TC/VC=ff Status: NegoPending- InProgress- Capabilities: [160 v1] Device Serial Number 00-00-00-00-00-00-00-00 Kernel driver in use: rtsx_pci Kernel modules: rtsx_pci Some complementary lines from my journal: kernel: r8169 Gigabit Ethernet driver 2.3LK-NAPI loaded kernel: r8169 :03:00.2: can't disable ASPM; OS doesn't have ASPM control kernel: pcieport :00:1c.3: driver skip pci_set_master, fix it! kernel: r8169 :03:00.2: irq 44 for MSI/MSI-X kernel: r8169 :03:00.2 eth0: RTL8411 at 0xc90016ed4000, 00:90:f5:d7:34:53, XID 08800800 IRQ 44 kernel: r8169 :03:00.2 eth0: jumbo features
Re: 3.12: ethernet controller missing after resuming from suspend to RAM
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 :00:1a.0: System wakeup disabled by ACPI [ 56.213939] ehci-pci :00:1d.0: System wakeup disabled by ACPI [ 56.240614] xhci_hcd :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 :00:1c.1: System wakeup disabled by ACPI [ 56.296628] iwlwifi :05:00.0: RF_KILL bit toggled to enable radio. [ 56.404258] snd_hda_intel :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 :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 :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 :04:00.5: irq 50 for MSI/MSI-X [ 58.233503] jme :04:00.5 eth0: Link is down [ 58.233578] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready [ 58.235113] iwlwifi :05:00.0: L1 Enabled; Disabling L0S [ 58.242131] iwlwifi :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 :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.wyso...@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
Re: 3.12: ethernet controller missing after resuming from suspend to RAM
On Monday, February 10, 2014 12:18:16 AM Peter Wu wrote:
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 :00:1a.0: System wakeup disabled by ACPI
[ 56.213939] ehci-pci :00:1d.0: System wakeup disabled by ACPI
[ 56.240614] xhci_hcd :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 :00:1c.1: System wakeup disabled by ACPI
[ 56.296628] iwlwifi :05:00.0: RF_KILL bit toggled to enable radio.
[ 56.404258] snd_hda_intel :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 :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 :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 :04:00.5: irq 50 for MSI/MSI-X
[ 58.233503] jme :04:00.5 eth0: Link is down
[ 58.233578] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
[ 58.235113] iwlwifi :05:00.0: L1 Enabled; Disabling L0S
[ 58.242131] iwlwifi :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 :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.wyso...@intel.com
Date: Tue Jul 16 22:10:35 2013 +0200
ACPI / hotplug / PCI: Check for new devices on enabled slots
This one, or another one in that series. I rather suspect
ab1225901da2 Revert ACPI / hotplug / PCI: Avoid doing too much for spurious
notifies
from Mika, but it really doesn't matter.
Can you please check the patch below (it is on top of 3.14-rc1, but I think
it'll
still apply to 3.13) and report back?
Rafael
---
drivers/pci/hotplug/acpiphp_glue.c |9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
Index: linux-pm/drivers/pci/hotplug/acpiphp_glue.c
===
--- linux-pm.orig/drivers/pci/hotplug/acpiphp_glue.c
+++ linux-pm/drivers/pci/hotplug/acpiphp_glue.c
@@ -555,10 +555,10 @@ static void __ref enable_slot(struct acp
struct pci_dev *dev;
struct pci_bus *bus = slot-bus;
struct acpiphp_func *func;
- int max, pass;
+ int nr_found, max, pass, bridges_scanned = 0;
LIST_HEAD(add_list);
- acpiphp_rescan_slot(slot);
+ nr_found = acpiphp_rescan_slot(slot);
max = acpiphp_max_busnr(bus);
for (pass = 0; pass 2; pass++) {
list_for_each_entry(dev, bus-devices, bus_list) {
@@ -574,9 +574,14 @@ static void __ref enable_slot(struct acp
__pci_bus_size_bridges(dev-subordinate,
Re: 3.12: ethernet controller missing after resuming from suspend to RAM
On Monday 10 February 2014 01:52:14 Rafael J. Wysocki wrote:
Could the following commit have something to do with it?
commit 4ebe34503baa0644c9352bcd76d4cf573bffe206
Author: Rafael J. Wysocki rafael.j.wyso...@intel.com
Date: Tue Jul 16 22:10:35 2013 +0200
ACPI / hotplug / PCI: Check for new devices on enabled slots
This one, or another one in that series. I rather suspect
ab1225901da2 Revert ACPI / hotplug / PCI: Avoid doing too much for spurious
notifies
from Mika, but it really doesn't matter.
Can you please check the patch below (it is on top of 3.14-rc1, but I think
it'll still apply to 3.13) and report back?
I applied the following patch:
--- drivers/pci/hotplug/acpiphp_glue.c.orig 2014-02-10 01:46:59.678124018
+0100
+++ drivers/pci/hotplug/acpiphp_glue.c 2014-02-10 01:48:59.634124004 +0100
@@ -552,10 +552,10 @@
struct pci_dev *dev;
struct pci_bus *bus = slot-bus;
struct acpiphp_func *func;
- int max, pass;
+ int nr_found, max, pass, bridges_scanned = 0;
LIST_HEAD(add_list);
- acpiphp_rescan_slot(slot);
+ nr_found = acpiphp_rescan_slot(slot);
max = acpiphp_max_busnr(bus);
for (pass = 0; pass 2; pass++) {
list_for_each_entry(dev, bus-devices, bus_list) {
@@ -571,9 +571,16 @@
__pci_bus_size_bridges(dev-subordinate,
add_list);
}
+ bridges_scanned++;
}
}
}
+ /* Nothing more to do here if there are no new devices on this bus. */
+ if (!nr_found !bridges_scanned (slot-flags SLOT_ENABLED)) {
+ pr_debug(No more new devices on this bus.\n);
+ return;
+ }
+
__pci_bus_assign_resources(bus, add_list, NULL);
acpiphp_sanitize_bus(bus);
Unfortunately, the adapter still vanishes. dmesg is below this message.
Peter
[ 44.558995] CPU3 is up
[ 44.561438] ACPI: Waking up from system sleep state S3
[ 45.254084] ehci-pci :00:1a.0: System wakeup disabled by ACPI
[ 45.280727] ehci-pci :00:1d.0: System wakeup disabled by ACPI
[ 45.307403] xhci_hcd :02:00.0: System wakeup disabled by ACPI
[ 45.361012] PM: noirq resume of devices complete after 133.354 msecs
[ 45.361292] PM: early resume of devices complete after 0.233 msecs
[ 45.361680] iwlwifi :05:00.0: RF_KILL bit toggled to enable radio.
[ 45.361731] pcieport :00:1c.1: System wakeup disabled by ACPI
[ 45.470912] snd_hda_intel :00:1b.0: irq 48 for MSI/MSI-X
[ 45.700502] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
[ 45.700533] ata5: SATA link down (SStatus 0 SControl 300)
[ 45.701385] ata1.00: configured for UDMA/133
[ 45.701503] sd 0:0:0:0: [sda] Starting disk
[ 45.707139] ata2: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[ 45.872011] ata2.00: configured for UDMA/100
[ 46.791141] PM: resume of devices complete after 1430.658 msecs
[ 46.791560] PM: Finishing wakeup.
[ 46.791565] acpiphp_glue: hotplug_event: Bus check notify on \_SB_.PCI0.RP03
[ 46.791568] acpiphp_glue: hotplug_event: re-enumerating slots under
\_SB_.PCI0.RP03
[ 46.791642] acpiphp_glue: No more new devices on this bus.
[ 46.791571] Restarting tasks ... done.
[ 46.793204] video LNXVIDEO:00: Restoring backlight state
[ 46.793211] video LNXVIDEO:01: Restoring backlight state
[ 47.246425] ACPI: \_SB_.AC__: ACPI_NOTIFY_BUS_CHECK event: unsupported
[ 47.251540] jme :04:00.5: irq 50 for MSI/MSI-X
[ 47.276949] jme :04:00.5 eth0: Link is down
[ 47.276974] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
[ 47.278423] iwlwifi :05:00.0: L1 Enabled; Disabling L0S
[ 47.285758] iwlwifi :05:00.0: Radio type=0x1-0x3-0x1
[ 47.393492] acpiphp_glue: hotplug_event: Bus check notify on \_SB_.PCI0.RP01
[ 47.393495] acpiphp_glue: hotplug_event: re-enumerating slots under
\_SB_.PCI0.RP01
[ 47.393517] acpiphp_glue: No more new devices on this bus.
[ 47.393525] acpiphp_glue: hotplug_event: Bus check notify on \_SB_.PCI0.RP02
[ 47.393527] acpiphp_glue: hotplug_event: re-enumerating slots under
\_SB_.PCI0.RP02
[ 47.398977] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
[ 47.463615] acpiphp_glue: hotplug_event: Bus check notify on \_SB_.PCI0.RP03
[ 47.463620] acpiphp_glue: hotplug_event: re-enumerating slots under
\_SB_.PCI0.RP03
[ 47.463685] acpiphp_glue: No more new devices on this bus.
After the last message, NetworkManager loses the interface within a second.
The next following messages follow two seconds later and are unrelated
(those are about wireless connectivity).
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the
Re: 3.12: ethernet controller missing after resuming from suspend to RAM
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 :05:00.0: no hotplug settings from platform xhci_hcd :02:00.0: no hotplug settings from platform (here, NetworkManager complains that a device has gone) iwlwifi :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-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 3.12: ethernet controller missing after resuming from suspend to RAM
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 :04:00.5: irq 50 for MSI/MSI-X > > > [ 49.671645] jme :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.txt2014-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- > SERR- Latency: 0, Cache Line Size: 64 bytes > Bus: primary=00, secondary=04, subordinate=04, sec-latency=0 > I/O behind bridge: 4000-4fff > Memory behind bridge: fd40-fd4f > Prefetchable memory behind bridge: c000-c01f > - Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort- > + Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort- > BridgeCtl: Parity- SERR- NoISA+ VGA- MAbort- >Reset- FastB2B- > PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn- > Capabilities: > 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- > SERR- Latency: 0, Cache Line Size: 64 bytes > Interrupt: pin A routed to IRQ 16 > Region 0: Memory at fc00 (64-bit, non-prefetchable) [size=8K] > Capabilities: > 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- > SERR- - 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: > - 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- > SERR- - Interrupt: pin B routed to IRQ 18 > - Region 0: Memory at fd405000 (32-bit, non-prefetchable) [size=256] > - Capabilities: > - 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- > SERR- - 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: > - 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- > SERR- - Latency: 0, Cache Line Size: 64 bytes > - Interrupt: pin B routed to IRQ 50 > - Region 0: Memory at fd40 (32-bit, non-prefetchable) [size=16K] > - Region 2: I/O ports at 4400 [size=128] > - Region 3:
Re: 3.12: ethernet controller missing after resuming from suspend to RAM
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 :04:00.5: irq 50 for MSI/MSI-X [ 49.671645] jme :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.txt2014-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: 4000-4fff Memory behind bridge: fd40-fd4f Prefetchable memory behind bridge: c000-c01f - 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 fc00 (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 -
Re: 3.12: ethernet controller missing after resuming from suspend to RAM
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 :05:00.0: no hotplug settings from platform xhci_hcd :02:00.0: no hotplug settings from platform (here, NetworkManager complains that a device has gone) iwlwifi :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-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 3.12: ethernet controller missing after resuming from suspend to RAM
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 :04:00.5: irq 50 for MSI/MSI-X > > [ 49.671645] jme :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): systemd[1]: Stopping Sleep. systemd[1]: Stopped target Sleep. systemd[1]: Starting Suspend. systemd[1]: Reached target Suspend. systemd-logind[284]: Operation finished. NetworkManager[276]: wake requested (sleeping: yes enabled: yes) NetworkManager[276]: waking up and re-enabling... NetworkManager[276]: WWAN now enabled by management service NetworkManager[276]: (eth0): device state change: unmanaged -> unavailable (reason 'managed') [10 20 2] NetworkManager[276]: (eth0): bringing up device. kernel: ACPI: \_SB_.AC__: ACPI_NOTIFY_BUS_CHECK event: unsupported kernel: jme :04:00.5: irq 50 for MSI/MSI-X dbus[285]: [system] Successfully activated service 'org.freedesktop.UPower' systemd[1]: Started Daemon for power management. NetworkManager[276]: (eth0): preparing device. NetworkManager[276]: (eth0): deactivating device (reason 'managed') [2] NetworkManager[276]: NetworkManager state is now DISCONNECTED NetworkManager[276]: (wlan0): device state change: unmanaged -> unavailable (reason 'managed') [10 20 2] NetworkManager[276]: (wlan0): bringing up device. kernel: jme :04:00.5 eth0: Link is down kernel: IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready kernel: iwlwifi :05:00.0: L1 Enabled; Disabling L0S kernel: iwlwifi :05:00.0: Radio type=0x1-0x3-0x1 NetworkManager[276]: (wlan0): preparing device. NetworkManager[276]: (wlan0): deactivating device (reason 'managed') [2] kernel: IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready NetworkManager[276]: (wlan0) supports 5 scan SSIDs NetworkManager[276]: (wlan0): supplicant interface state: starting -> ready NetworkManager[276]: (wlan0): device state change: unavailable -> disconnected (reason 'supplicant-available') [20 30 42] NetworkManager[276]: Trying to remove a non-existant call id. NetworkManager[276]: (wlan0): supplicant interface state: ready -> disconnected NetworkManager[276]: (wlan0) supports 5 scan SSIDs kernel: xhci_hcd :02:00.0: no hotplug settings from platform kernel: iwlwifi :05:00.0: no hotplug settings from platform NetworkManager[276]: (eth0): device state change: unavailable -> unmanaged (reason 'removed') [20 10 36] NetworkManager[276]: (eth0): cleaning up... NetworkManager[276]: (2) failed to find interface name for index NetworkManager[276]: (nm-system.c:766):nm_system_iface_get_flags: runtime check failed: (iface != NULL) NetworkManager[276]: [1391703079.229919] [nm-system.c:768] nm_system_iface_get_flags(): (unknown): failed to get interface link object > > [ 49.671717] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready > > [ 49.674119] iwlwifi :05:00.0: L1 Enabled; Disabling L0S > > [ 49.681037] iwlwifi :05:00.0: Radio type=0x1-0x3-0x1 > > [ 49.778035] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready > > [ 49.806241] xhci_hcd :02:00.0: no hotplug settings from platform > > [ 49.859417] iwlwifi :05:00.0: no hotplug settings from platform > > [ 56.264694] wlan0: authenticate with [STRIPPED] > > [ 56.277969] wlan0: send auth to [STRIPPED] (try 1/3) > > [ 56.282076] wlan0: authenticated > > [ 56.283879] wlan0: associate with [STRIPPED] (try 1/3) > > [ 56.297196] wlan0: RX AssocResp from [STRIPPED] (capab=0x411 status=0 > > aid=6) [ 56.303746] wlan0: associated > > [ 56.303826] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready > > Can you check the lspci differences between before/after the suspend-resume > cycle? See below. The MAbort+ looks suspicious. 00:1c.1 is the parent of the devices on bus 4. (`lspci -nnvt` differences:) - +-1c.1-[04]--+-00.0 JMicron Technology Corp. SD/MMC Host Controller [197b:2382] - |+-00.2 JMicron Technology Corp. Standard SD Host Controller [197b:2381] - |+-00.3 JMicron Technology Corp. MS Host Controller [197b:2383] - |\-00.5 JMicron Technology Corp. JMC250 PCI Express Gigabit Ethernet Controller [197b:0250] + +-1c.1-[04]-- --- lspci-nnvvv.txt 2014-02-06 17:11:02.867233563 +0100 +++ lspci-nnvvv2.txt2014-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-
Re: 3.12: ethernet controller missing after resuming from suspend to RAM
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 :04:00.5: irq 50 for MSI/MSI-X [ 49.671645] jme :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): systemd[1]: Stopping Sleep. systemd[1]: Stopped target Sleep. systemd[1]: Starting Suspend. systemd[1]: Reached target Suspend. systemd-logind[284]: Operation finished. NetworkManager[276]: info wake requested (sleeping: yes enabled: yes) NetworkManager[276]: info waking up and re-enabling... NetworkManager[276]: info WWAN now enabled by management service NetworkManager[276]: info (eth0): device state change: unmanaged - unavailable (reason 'managed') [10 20 2] NetworkManager[276]: info (eth0): bringing up device. kernel: ACPI: \_SB_.AC__: ACPI_NOTIFY_BUS_CHECK event: unsupported kernel: jme :04:00.5: irq 50 for MSI/MSI-X dbus[285]: [system] Successfully activated service 'org.freedesktop.UPower' systemd[1]: Started Daemon for power management. NetworkManager[276]: info (eth0): preparing device. NetworkManager[276]: info (eth0): deactivating device (reason 'managed') [2] NetworkManager[276]: info NetworkManager state is now DISCONNECTED NetworkManager[276]: info (wlan0): device state change: unmanaged - unavailable (reason 'managed') [10 20 2] NetworkManager[276]: info (wlan0): bringing up device. kernel: jme :04:00.5 eth0: Link is down kernel: IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready kernel: iwlwifi :05:00.0: L1 Enabled; Disabling L0S kernel: iwlwifi :05:00.0: Radio type=0x1-0x3-0x1 NetworkManager[276]: info (wlan0): preparing device. NetworkManager[276]: info (wlan0): deactivating device (reason 'managed') [2] kernel: IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready NetworkManager[276]: info (wlan0) supports 5 scan SSIDs NetworkManager[276]: info (wlan0): supplicant interface state: starting - ready NetworkManager[276]: info (wlan0): device state change: unavailable - disconnected (reason 'supplicant-available') [20 30 42] NetworkManager[276]: warn Trying to remove a non-existant call id. NetworkManager[276]: info (wlan0): supplicant interface state: ready - disconnected NetworkManager[276]: info (wlan0) supports 5 scan SSIDs kernel: xhci_hcd :02:00.0: no hotplug settings from platform kernel: iwlwifi :05:00.0: no hotplug settings from platform NetworkManager[276]: info (eth0): device state change: unavailable - unmanaged (reason 'removed') [20 10 36] NetworkManager[276]: info (eth0): cleaning up... NetworkManager[276]: warn (2) failed to find interface name for index NetworkManager[276]: (nm-system.c:766):nm_system_iface_get_flags: runtime check failed: (iface != NULL) NetworkManager[276]: error [1391703079.229919] [nm-system.c:768] nm_system_iface_get_flags(): (unknown): failed to get interface link object [ 49.671717] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready [ 49.674119] iwlwifi :05:00.0: L1 Enabled; Disabling L0S [ 49.681037] iwlwifi :05:00.0: Radio type=0x1-0x3-0x1 [ 49.778035] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready [ 49.806241] xhci_hcd :02:00.0: no hotplug settings from platform [ 49.859417] iwlwifi :05:00.0: no hotplug settings from platform [ 56.264694] wlan0: authenticate with [STRIPPED] [ 56.277969] wlan0: send auth to [STRIPPED] (try 1/3) [ 56.282076] wlan0: authenticated [ 56.283879] wlan0: associate with [STRIPPED] (try 1/3) [ 56.297196] wlan0: RX AssocResp from [STRIPPED] (capab=0x411 status=0 aid=6) [ 56.303746] wlan0: associated [ 56.303826] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready Can you check the lspci differences between before/after the suspend-resume cycle? See below. The MAbort+ looks suspicious. 00:1c.1 is the parent of the devices on bus 4. (`lspci -nnvt` differences:) - +-1c.1-[04]--+-00.0 JMicron Technology Corp. SD/MMC Host Controller [197b:2382] - |+-00.2 JMicron Technology Corp. Standard SD Host Controller [197b:2381] - |+-00.3 JMicron Technology Corp. MS Host Controller [197b:2383] - |\-00.5 JMicron Technology Corp. JMC250 PCI Express Gigabit Ethernet Controller [197b:0250] + +-1c.1-[04]-- --- lspci-nnvvv.txt 2014-02-06 17:11:02.867233563 +0100 +++ lspci-nnvvv2.txt2014-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-
Re: 3.12: ethernet controller missing after resuming from suspend to RAM
On 02/07/2014 12:15 AM, Bastien Traverse wrote: > > I was also hit by the rtsx driver bug > (https://bugs.archlinux.org/task/37720) and was delighted with its fast > resolution. I was hoping that its fix would also address the > disappearing Ethernet bug. yeah, but calling this "fast resolution" is quite incorrect. I don't blame anyone for this and I'm quite happy that a workaround has been found at last but calling this "fast resolution" is a bit funny compare to the PITA it was to debug this. That's probably why I haven't tried to do a similar work for this bug. Thanks. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 3.12: ethernet controller missing after resuming from suspend to RAM
On Friday, February 07, 2014 12:41:44 AM Bastien Traverse wrote: [...] > [ 200.934601] ACPI: Waking up from system sleep state S3 > [ 200.993469] xhci_hcd :00:14.0: System wakeup disabled by ACPI > [ 201.006819] ehci-pci :00:1a.0: System wakeup disabled by ACPI > [ 201.033495] ehci-pci :00:1d.0: System wakeup disabled by ACPI > [ 201.087040] PM: noirq resume of devices complete after 118.140 msecs > [ 201.087233] PM: early resume of devices complete after 0.169 msecs > [ 201.087270] i915 :00:02.0: setting latency timer to 64 > [ 201.087272] xhci_hcd :00:14.0: setting latency timer to 64 > [ 201.087456] ehci-pci :00:1a.0: setting latency timer to 64 > [ 201.087597] snd_hda_intel :00:1b.0: irq 43 for MSI/MSI-X > [ 201.090717] ahci :00:1f.2: setting latency timer to 64 > [ 201.090802] ehci-pci :00:1d.0: setting latency timer to 64 > [ 201.090889] r8169 :03:00.2: System wakeup disabled by ACPI The device appears to be alive here. > [ 201.430358] ata5: SATA link up 3.0 Gbps (SStatus 123 SControl 300) > [ 201.437019] ata3: SATA link up 1.5 Gbps (SStatus 113 SControl 300) > [ 201.509645] ata5.00: ACPI cmd ef/10:06:00:00:00:00 (SET FEATURES) > succeeded > [ 201.509647] ata5.00: ACPI cmd f5/00:00:00:00:00:00 (SECURITY FREEZE > LOCK) filtered out > [ 201.509649] ata5.00: ACPI cmd b1/c1:00:00:00:00:00 (DEVICE > CONFIGURATION OVERLAY) filtered out > [ 201.509919] ata5.00: supports DRM functions and may not be fully > accessible > [ 201.516754] ata5.00: ACPI cmd ef/10:06:00:00:00:00 (SET FEATURES) > succeeded > [ 201.516756] ata5.00: ACPI cmd f5/00:00:00:00:00:00 (SECURITY FREEZE > LOCK) filtered out > [ 201.516757] ata5.00: ACPI cmd b1/c1:00:00:00:00:00 (DEVICE > CONFIGURATION OVERLAY) filtered out > [ 201.516998] ata5.00: supports DRM functions and may not be fully > accessible > [ 201.523170] ata5.00: configured for UDMA/133 > [ 201.528884] ata3.00: configured for UDMA/100 > [ 201.533818] sd 4:0:0:0: [sdb] Starting disk > [ 202.197508] [drm] Enabling RC6 states: RC6 on, RC6p on, RC6pp on > [ 203.695165] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300) > [ 203.701879] ata1.00: ACPI cmd ef/10:06:00:00:00:00 (SET FEATURES) > succeeded > [ 203.701883] ata1.00: ACPI cmd f5/00:00:00:00:00:00 (SECURITY FREEZE > LOCK) filtered out > [ 203.701885] ata1.00: ACPI cmd b1/c1:00:00:00:00:00 (DEVICE > CONFIGURATION OVERLAY) filtered out > [ 203.715038] ata1.00: ACPI cmd ef/10:06:00:00:00:00 (SET FEATURES) > succeeded > [ 203.715042] ata1.00: ACPI cmd f5/00:00:00:00:00:00 (SECURITY FREEZE > LOCK) filtered out > [ 203.715044] ata1.00: ACPI cmd b1/c1:00:00:00:00:00 (DEVICE > CONFIGURATION OVERLAY) filtered out > [ 203.721440] ata1.00: configured for UDMA/133 > [ 203.731960] sd 0:0:0:0: [sda] Starting disk > [ 203.757734] PM: resume of devices complete after 2668.846 msecs > [ 203.758038] PM: Finishing wakeup. > [ 203.758039] Restarting tasks ... done. > [ 203.758936] video LNXVIDEO:00: Restoring backlight state > [ 203.784008] iwlwifi :02:00.0: L1 Disabled; Enabling L0S > [ 203.792083] iwlwifi :02:00.0: Radio type=0x2-0x0-0x0 > [ 203.856125] IPv6: ADDRCONF(NETDEV_UP): wlp2s0: link is not ready > [ 203.928106] r8169 :03:00.2 enp3s0f2: link down And here. > [ 203.928145] IPv6: ADDRCONF(NETDEV_UP): enp3s0f2: link is not ready > [ 204.999379] wlp2s0: authenticate with [MAC_STRIPPED] > [ 205.003235] wlp2s0: send auth to [MAC_STRIPPED] (try 1/3) > [ 205.005976] wlp2s0: authenticated > [ 205.009250] wlp2s0: associate with [MAC_STRIPPED] (try 1/3) > [ 205.019312] wlp2s0: RX AssocResp from [MAC_STRIPPED] (capab=0x411 > status=0 aid=4) > [ 205.043032] wlp2s0: associated > [ 205.043069] IPv6: ADDRCONF(NETDEV_CHANGE): wlp2s0: link becomes ready And there's no comments indicating any hotplug-related activity. > Here's the diff between before/after lspci -nnvt: > 9,10c9 > <+-1c.3-[03]--+-00.0 Realtek Semiconductor Co., Ltd. Device > [10ec:5289] > <|\-00.2 Realtek Semiconductor Co., Ltd. > RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller [10ec:8168] > --- > >+-1c.3-[03]-- > > Please tell me if you need the lspci log in complete form or how to tune > the diff command. Please send the output of lspci -vv right before suspend and right after the subsequent resume as attachments. Thanks! -- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 3.12: ethernet controller missing after resuming from suspend to RAM
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 :04:00.5: irq 50 for MSI/MSI-X > [ 49.671645] jme :04:00.5 eth0: Link is down Well, this means that Ethernet device is present after the resume. > [ 49.671717] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready > [ 49.674119] iwlwifi :05:00.0: L1 Enabled; Disabling L0S > [ 49.681037] iwlwifi :05:00.0: Radio type=0x1-0x3-0x1 > [ 49.778035] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready > [ 49.806241] xhci_hcd :02:00.0: no hotplug settings from platform > [ 49.859417] iwlwifi :05:00.0: no hotplug settings from platform > [ 56.264694] wlan0: authenticate with [STRIPPED] > [ 56.277969] wlan0: send auth to [STRIPPED] (try 1/3) > [ 56.282076] wlan0: authenticated > [ 56.283879] wlan0: associate with [STRIPPED] (try 1/3) > [ 56.297196] wlan0: RX AssocResp from [STRIPPED] (capab=0x411 status=0 > aid=6) > [ 56.303746] wlan0: associated > [ 56.303826] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready Can you check the lspci differences between before/after the suspend-resume cycle? -- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 3.12: ethernet controller missing after resuming from suspend to RAM
Le 06/02/2014 08:38, Francis Moreau a écrit : > I'm still leaving with this issue since my initial posting > unfortunately :( Damn, I was hoping you'd have found a workaround for this by now. It is quite severe though! > I'm wondering why PM support on this machine is so crapish My quick research turned up a few results ([1],[2],[3]) for similar bug with other setups, however there are rather old and not met with a fix. But yeah, this machine has some undeniable defects, a faulty BIOS made me RMA it just after its purchase. > (it initialy oopsed when resuming due to a bug in rtsx driver). I was also hit by the rtsx driver bug (https://bugs.archlinux.org/task/37720) and was delighted with its fast resolution. I was hoping that its fix would also address the disappearing Ethernet bug. Le 06/02/2014 13:40, Rafael J. Wysocki a écrit : > Is this a new problem in 3.12? There is a ticket in kernel bugzilla [4] that involves r8169 and suspend/resume or rather hibernate/resume. This bug involves kernels prior to 3.12, but I can't tell if it is really related. 3.12.x is the first and only kernel I tried on this machine (well I do have Debian 7 in dual boot but I haven't used it since I installed it). Would it help if I'd try another distribution with older kernel? If so, would doing it from LiveUSB be a valid way? [1] https://bbs.archlinux.org/viewtopic.php?id=98399 [2] https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/45696 [3] http://forums.linuxmint.com/viewtopic.php?f=150=36708=211140 [4] https://bugzilla.kernel.org/show_bug.cgi?id=45911 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 3.12: ethernet controller missing after resuming from suspend to RAM
On Thursday, February 06, 2014 10:08:25 PM Peter Wu wrote: > On Thursday 06 February 2014 00:42:51 Bastien Traverse wrote: > > I just used my Ethernet NIC for the first time on an up-to-date > > Archlinux; it was working fine until I suspended to RAM: on resume the > > Realtek/Ethernet device had completely disappeared. > > > > The two entries absent from lspci output after resume are: > > $ sudo lspci -v > [..] > > 03:00.2 Ethernet controller: Realtek Semiconductor Co., Ltd. > > RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 0a) > > Subsystem: CLEVO/KAPOK Computer Device 0540 > > Flags: bus master, fast devsel, latency 0, IRQ 45 > > I/O ports at e000 [size=256] > > Memory at f0a04000 (64-bit, prefetchable) [size=4K] > > Memory at f0a0 (64-bit, prefetchable) [size=16K] > > Capabilities: [40] Power Management version 3 > > Capabilities: [50] MSI: Enable+ Count=1/1 Maskable- 64bit+ > > Capabilities: [70] Express Endpoint, MSI 01 > > Capabilities: [b0] MSI-X: Enable- Count=4 Masked- > > Capabilities: [d0] Vital Product Data > > Capabilities: [100] Advanced Error Reporting > > Capabilities: [160] Device Serial Number 02-00-00-00-68-4c-e0-00 > > Kernel driver in use: r8169 > > Kernel modules: r8169 > > I also have an affected laptop where the network and MMC controller > vanishes on resume. The laptop is also from Clevo, but a different > model: Clevo B7130. I had no issues with my custom kernel > configuration (latest version that I tested was 3.13.1), but at least > the stock Arch kernels from 3.12.2 up to 3.12.6 and 3.13.1 are > affected by this issue. > > Reproduce with: > > 1. Boot system. > 2. lspci -nnvt > lspci-nnvt.txt > 3. Suspend system (lid close) > 4. lspci -nnvt > lspci-nnvt2.txt > 5. Observe missing network controller (see diff below). > > --- boot-3.13.1/lspci-nnvt.txt2014-02-06 17:11:07.070625446 +0100 > +++ boot-3.13.1/lspci-nnvt2.txt 2014-02-06 17:11:19.843386871 +0100 > @@ -11,10 +11,7 @@ > +-1a.0 Intel Corporation 5 Series/3400 Series Chipset USB2 > Enhanced Host Controller [8086:3b3c] > +-1b.0 Intel Corporation 5 Series/3400 Series Chipset High > Definition Audio [8086:3b56] > +-1c.0-[02-03]00.0 NEC Corporation uPD720200 USB 3.0 Host > Controller [1033:0194] > - +-1c.1-[04]--+-00.0 JMicron Technology Corp. SD/MMC Host > Controller [197b:2382] > - |+-00.2 JMicron Technology Corp. Standard SD Host > Controller [197b:2381] > - |+-00.3 JMicron Technology Corp. MS Host > Controller [197b:2383] > - |\-00.5 JMicron Technology Corp. JMC250 PCI > Express Gigabit Ethernet Controller [197b:0250] > + +-1c.1-[04]-- > +-1c.2-[05]00.0 Intel Corporation Centrino Advanced-N 6200 > [8086:422c] > +-1d.0 Intel Corporation 5 Series/3400 Series Chipset USB2 > Enhanced Host Controller [8086:3b34] > +-1e.0-[06]-- > > The only difference now is the kernel config. I guess that it comes > from CONFIG_HOTPLUG_PCI. In my non-broken config, it's unset. The > Arch kernel sets CONFIG_HOTPLUG_PCI=y (and also > CONFIG_HOTPLUG_PCI_ACPI=y). > > That guess is based on the additional messages I see with the broken config: > > [1.033628] pci_hotplug: PCI Hot Plug PCI Core version: 0.5 > [1.033642] pciehp: PCI Express Hot Plug Controller Driver version: > 0.4 > > ... > [ 102.704377] iwlwifi :05:00.0: no hotplug settings from platform > [ 103.170193] xhci_hcd :02:00.0: no hotplug settings from platform > [ 103.229008] iwlwifi :05:00.0: no hotplug settings from platform > > Before I start bisecting, do you have any ideas to debug this? > > The stock config of Arch Linux kernel 3.13.1-2-ARCH can be found on: > https://projects.archlinux.org/svntogit/packages.git/tree/trunk/config.x86_64?h=packages/linux=0ea780ba731bd214db3007f57f54a3fad709a078 Well, I suspected that it would result from hotplug changes. Please send me a dmesg log including the suspend-resume cycle after which the device is missing. Thanks! -- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 3.12: ethernet controller missing after resuming from suspend to RAM
On Thursday 06 February 2014 00:42:51 Bastien Traverse wrote: > I just used my Ethernet NIC for the first time on an up-to-date > Archlinux; it was working fine until I suspended to RAM: on resume the > Realtek/Ethernet device had completely disappeared. > > The two entries absent from lspci output after resume are: > $ sudo lspci -v [..] > 03:00.2 Ethernet controller: Realtek Semiconductor Co., Ltd. > RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 0a) > Subsystem: CLEVO/KAPOK Computer Device 0540 > Flags: bus master, fast devsel, latency 0, IRQ 45 > I/O ports at e000 [size=256] > Memory at f0a04000 (64-bit, prefetchable) [size=4K] > Memory at f0a0 (64-bit, prefetchable) [size=16K] > Capabilities: [40] Power Management version 3 > Capabilities: [50] MSI: Enable+ Count=1/1 Maskable- 64bit+ > Capabilities: [70] Express Endpoint, MSI 01 > Capabilities: [b0] MSI-X: Enable- Count=4 Masked- > Capabilities: [d0] Vital Product Data > Capabilities: [100] Advanced Error Reporting > Capabilities: [160] Device Serial Number 02-00-00-00-68-4c-e0-00 > Kernel driver in use: r8169 > Kernel modules: r8169 I also have an affected laptop where the network and MMC controller vanishes on resume. The laptop is also from Clevo, but a different model: Clevo B7130. I had no issues with my custom kernel configuration (latest version that I tested was 3.13.1), but at least the stock Arch kernels from 3.12.2 up to 3.12.6 and 3.13.1 are affected by this issue. Reproduce with: 1. Boot system. 2. lspci -nnvt > lspci-nnvt.txt 3. Suspend system (lid close) 4. lspci -nnvt > lspci-nnvt2.txt 5. Observe missing network controller (see diff below). --- boot-3.13.1/lspci-nnvt.txt 2014-02-06 17:11:07.070625446 +0100 +++ boot-3.13.1/lspci-nnvt2.txt 2014-02-06 17:11:19.843386871 +0100 @@ -11,10 +11,7 @@ +-1a.0 Intel Corporation 5 Series/3400 Series Chipset USB2 Enhanced Host Controller [8086:3b3c] +-1b.0 Intel Corporation 5 Series/3400 Series Chipset High Definition Audio [8086:3b56] +-1c.0-[02-03]00.0 NEC Corporation uPD720200 USB 3.0 Host Controller [1033:0194] - +-1c.1-[04]--+-00.0 JMicron Technology Corp. SD/MMC Host Controller [197b:2382] - |+-00.2 JMicron Technology Corp. Standard SD Host Controller [197b:2381] - |+-00.3 JMicron Technology Corp. MS Host Controller [197b:2383] - |\-00.5 JMicron Technology Corp. JMC250 PCI Express Gigabit Ethernet Controller [197b:0250] + +-1c.1-[04]-- +-1c.2-[05]00.0 Intel Corporation Centrino Advanced-N 6200 [8086:422c] +-1d.0 Intel Corporation 5 Series/3400 Series Chipset USB2 Enhanced Host Controller [8086:3b34] +-1e.0-[06]-- The only difference now is the kernel config. I guess that it comes from CONFIG_HOTPLUG_PCI. In my non-broken config, it's unset. The Arch kernel sets CONFIG_HOTPLUG_PCI=y (and also CONFIG_HOTPLUG_PCI_ACPI=y). That guess is based on the additional messages I see with the broken config: [1.033628] pci_hotplug: PCI Hot Plug PCI Core version: 0.5 [1.033642] pciehp: PCI Express Hot Plug Controller Driver version: 0.4 ... [ 102.704377] iwlwifi :05:00.0: no hotplug settings from platform [ 103.170193] xhci_hcd :02:00.0: no hotplug settings from platform [ 103.229008] iwlwifi :05:00.0: no hotplug settings from platform Before I start bisecting, do you have any ideas to debug this? The stock config of Arch Linux kernel 3.13.1-2-ARCH can be found on: https://projects.archlinux.org/svntogit/packages.git/tree/trunk/config.x86_64?h=packages/linux=0ea780ba731bd214db3007f57f54a3fad709a078 Regards, Peter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 3.12: ethernet controller missing after resuming from suspend to RAM
On 02/06/2014 01:40 PM, Rafael J. Wysocki wrote: > On Thursday, February 06, 2014 08:38:15 AM Francis Moreau wrote: >> Hi, >> >> On 02/06/2014 12:42 AM, Bastien Traverse wrote: >>> Hello, >>> >>> I'm encountering the exact same problem (same model of machine, same >>> controller, same OS) and was wondering where this bug was at. >> >> I'm still leaving with this issue since my initial posting unfortunately :( >> >> I'm wondering why PM support on this machine is so crapish (it initialy >> oopsed when resuming due to a bug in rtsx driver). > > Is this a new problem in 3.12? > I don't know, sorry, maybe Bastien has an idea. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 3.12: ethernet controller missing after resuming from suspend to RAM
On Thursday, February 06, 2014 08:38:15 AM Francis Moreau wrote: > Hi, > > On 02/06/2014 12:42 AM, Bastien Traverse wrote: > > Hello, > > > > I'm encountering the exact same problem (same model of machine, same > > controller, same OS) and was wondering where this bug was at. > > I'm still leaving with this issue since my initial posting unfortunately :( > > I'm wondering why PM support on this machine is so crapish (it initialy > oopsed when resuming due to a bug in rtsx driver). Is this a new problem in 3.12? Rafael -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 3.12: ethernet controller missing after resuming from suspend to RAM
On Thursday, February 06, 2014 08:38:15 AM Francis Moreau wrote: Hi, On 02/06/2014 12:42 AM, Bastien Traverse wrote: Hello, I'm encountering the exact same problem (same model of machine, same controller, same OS) and was wondering where this bug was at. I'm still leaving with this issue since my initial posting unfortunately :( I'm wondering why PM support on this machine is so crapish (it initialy oopsed when resuming due to a bug in rtsx driver). Is this a new problem in 3.12? Rafael -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 3.12: ethernet controller missing after resuming from suspend to RAM
On 02/06/2014 01:40 PM, Rafael J. Wysocki wrote: On Thursday, February 06, 2014 08:38:15 AM Francis Moreau wrote: Hi, On 02/06/2014 12:42 AM, Bastien Traverse wrote: Hello, I'm encountering the exact same problem (same model of machine, same controller, same OS) and was wondering where this bug was at. I'm still leaving with this issue since my initial posting unfortunately :( I'm wondering why PM support on this machine is so crapish (it initialy oopsed when resuming due to a bug in rtsx driver). Is this a new problem in 3.12? I don't know, sorry, maybe Bastien has an idea. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 3.12: ethernet controller missing after resuming from suspend to RAM
On Thursday 06 February 2014 00:42:51 Bastien Traverse wrote: I just used my Ethernet NIC for the first time on an up-to-date Archlinux; it was working fine until I suspended to RAM: on resume the Realtek/Ethernet device had completely disappeared. The two entries absent from lspci output after resume are: $ sudo lspci -v [..] 03:00.2 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 0a) Subsystem: CLEVO/KAPOK Computer Device 0540 Flags: bus master, fast devsel, latency 0, IRQ 45 I/O ports at e000 [size=256] Memory at f0a04000 (64-bit, prefetchable) [size=4K] Memory at f0a0 (64-bit, prefetchable) [size=16K] Capabilities: [40] Power Management version 3 Capabilities: [50] MSI: Enable+ Count=1/1 Maskable- 64bit+ Capabilities: [70] Express Endpoint, MSI 01 Capabilities: [b0] MSI-X: Enable- Count=4 Masked- Capabilities: [d0] Vital Product Data Capabilities: [100] Advanced Error Reporting Capabilities: [160] Device Serial Number 02-00-00-00-68-4c-e0-00 Kernel driver in use: r8169 Kernel modules: r8169 I also have an affected laptop where the network and MMC controller vanishes on resume. The laptop is also from Clevo, but a different model: Clevo B7130. I had no issues with my custom kernel configuration (latest version that I tested was 3.13.1), but at least the stock Arch kernels from 3.12.2 up to 3.12.6 and 3.13.1 are affected by this issue. Reproduce with: 1. Boot system. 2. lspci -nnvt lspci-nnvt.txt 3. Suspend system (lid close) 4. lspci -nnvt lspci-nnvt2.txt 5. Observe missing network controller (see diff below). --- boot-3.13.1/lspci-nnvt.txt 2014-02-06 17:11:07.070625446 +0100 +++ boot-3.13.1/lspci-nnvt2.txt 2014-02-06 17:11:19.843386871 +0100 @@ -11,10 +11,7 @@ +-1a.0 Intel Corporation 5 Series/3400 Series Chipset USB2 Enhanced Host Controller [8086:3b3c] +-1b.0 Intel Corporation 5 Series/3400 Series Chipset High Definition Audio [8086:3b56] +-1c.0-[02-03]00.0 NEC Corporation uPD720200 USB 3.0 Host Controller [1033:0194] - +-1c.1-[04]--+-00.0 JMicron Technology Corp. SD/MMC Host Controller [197b:2382] - |+-00.2 JMicron Technology Corp. Standard SD Host Controller [197b:2381] - |+-00.3 JMicron Technology Corp. MS Host Controller [197b:2383] - |\-00.5 JMicron Technology Corp. JMC250 PCI Express Gigabit Ethernet Controller [197b:0250] + +-1c.1-[04]-- +-1c.2-[05]00.0 Intel Corporation Centrino Advanced-N 6200 [8086:422c] +-1d.0 Intel Corporation 5 Series/3400 Series Chipset USB2 Enhanced Host Controller [8086:3b34] +-1e.0-[06]-- The only difference now is the kernel config. I guess that it comes from CONFIG_HOTPLUG_PCI. In my non-broken config, it's unset. The Arch kernel sets CONFIG_HOTPLUG_PCI=y (and also CONFIG_HOTPLUG_PCI_ACPI=y). That guess is based on the additional messages I see with the broken config: [1.033628] pci_hotplug: PCI Hot Plug PCI Core version: 0.5 [1.033642] pciehp: PCI Express Hot Plug Controller Driver version: 0.4 ... [ 102.704377] iwlwifi :05:00.0: no hotplug settings from platform [ 103.170193] xhci_hcd :02:00.0: no hotplug settings from platform [ 103.229008] iwlwifi :05:00.0: no hotplug settings from platform Before I start bisecting, do you have any ideas to debug this? The stock config of Arch Linux kernel 3.13.1-2-ARCH can be found on: https://projects.archlinux.org/svntogit/packages.git/tree/trunk/config.x86_64?h=packages/linuxid=0ea780ba731bd214db3007f57f54a3fad709a078 Regards, Peter -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 3.12: ethernet controller missing after resuming from suspend to RAM
On Thursday, February 06, 2014 10:08:25 PM Peter Wu wrote: On Thursday 06 February 2014 00:42:51 Bastien Traverse wrote: I just used my Ethernet NIC for the first time on an up-to-date Archlinux; it was working fine until I suspended to RAM: on resume the Realtek/Ethernet device had completely disappeared. The two entries absent from lspci output after resume are: $ sudo lspci -v [..] 03:00.2 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 0a) Subsystem: CLEVO/KAPOK Computer Device 0540 Flags: bus master, fast devsel, latency 0, IRQ 45 I/O ports at e000 [size=256] Memory at f0a04000 (64-bit, prefetchable) [size=4K] Memory at f0a0 (64-bit, prefetchable) [size=16K] Capabilities: [40] Power Management version 3 Capabilities: [50] MSI: Enable+ Count=1/1 Maskable- 64bit+ Capabilities: [70] Express Endpoint, MSI 01 Capabilities: [b0] MSI-X: Enable- Count=4 Masked- Capabilities: [d0] Vital Product Data Capabilities: [100] Advanced Error Reporting Capabilities: [160] Device Serial Number 02-00-00-00-68-4c-e0-00 Kernel driver in use: r8169 Kernel modules: r8169 I also have an affected laptop where the network and MMC controller vanishes on resume. The laptop is also from Clevo, but a different model: Clevo B7130. I had no issues with my custom kernel configuration (latest version that I tested was 3.13.1), but at least the stock Arch kernels from 3.12.2 up to 3.12.6 and 3.13.1 are affected by this issue. Reproduce with: 1. Boot system. 2. lspci -nnvt lspci-nnvt.txt 3. Suspend system (lid close) 4. lspci -nnvt lspci-nnvt2.txt 5. Observe missing network controller (see diff below). --- boot-3.13.1/lspci-nnvt.txt2014-02-06 17:11:07.070625446 +0100 +++ boot-3.13.1/lspci-nnvt2.txt 2014-02-06 17:11:19.843386871 +0100 @@ -11,10 +11,7 @@ +-1a.0 Intel Corporation 5 Series/3400 Series Chipset USB2 Enhanced Host Controller [8086:3b3c] +-1b.0 Intel Corporation 5 Series/3400 Series Chipset High Definition Audio [8086:3b56] +-1c.0-[02-03]00.0 NEC Corporation uPD720200 USB 3.0 Host Controller [1033:0194] - +-1c.1-[04]--+-00.0 JMicron Technology Corp. SD/MMC Host Controller [197b:2382] - |+-00.2 JMicron Technology Corp. Standard SD Host Controller [197b:2381] - |+-00.3 JMicron Technology Corp. MS Host Controller [197b:2383] - |\-00.5 JMicron Technology Corp. JMC250 PCI Express Gigabit Ethernet Controller [197b:0250] + +-1c.1-[04]-- +-1c.2-[05]00.0 Intel Corporation Centrino Advanced-N 6200 [8086:422c] +-1d.0 Intel Corporation 5 Series/3400 Series Chipset USB2 Enhanced Host Controller [8086:3b34] +-1e.0-[06]-- The only difference now is the kernel config. I guess that it comes from CONFIG_HOTPLUG_PCI. In my non-broken config, it's unset. The Arch kernel sets CONFIG_HOTPLUG_PCI=y (and also CONFIG_HOTPLUG_PCI_ACPI=y). That guess is based on the additional messages I see with the broken config: [1.033628] pci_hotplug: PCI Hot Plug PCI Core version: 0.5 [1.033642] pciehp: PCI Express Hot Plug Controller Driver version: 0.4 ... [ 102.704377] iwlwifi :05:00.0: no hotplug settings from platform [ 103.170193] xhci_hcd :02:00.0: no hotplug settings from platform [ 103.229008] iwlwifi :05:00.0: no hotplug settings from platform Before I start bisecting, do you have any ideas to debug this? The stock config of Arch Linux kernel 3.13.1-2-ARCH can be found on: https://projects.archlinux.org/svntogit/packages.git/tree/trunk/config.x86_64?h=packages/linuxid=0ea780ba731bd214db3007f57f54a3fad709a078 Well, I suspected that it would result from hotplug changes. Please send me a dmesg log including the suspend-resume cycle after which the device is missing. Thanks! -- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 3.12: ethernet controller missing after resuming from suspend to RAM
Le 06/02/2014 08:38, Francis Moreau a écrit : I'm still leaving with this issue since my initial posting unfortunately :( Damn, I was hoping you'd have found a workaround for this by now. It is quite severe though! I'm wondering why PM support on this machine is so crapish My quick research turned up a few results ([1],[2],[3]) for similar bug with other setups, however there are rather old and not met with a fix. But yeah, this machine has some undeniable defects, a faulty BIOS made me RMA it just after its purchase. (it initialy oopsed when resuming due to a bug in rtsx driver). I was also hit by the rtsx driver bug (https://bugs.archlinux.org/task/37720) and was delighted with its fast resolution. I was hoping that its fix would also address the disappearing Ethernet bug. Le 06/02/2014 13:40, Rafael J. Wysocki a écrit : Is this a new problem in 3.12? There is a ticket in kernel bugzilla [4] that involves r8169 and suspend/resume or rather hibernate/resume. This bug involves kernels prior to 3.12, but I can't tell if it is really related. 3.12.x is the first and only kernel I tried on this machine (well I do have Debian 7 in dual boot but I haven't used it since I installed it). Would it help if I'd try another distribution with older kernel? If so, would doing it from LiveUSB be a valid way? [1] https://bbs.archlinux.org/viewtopic.php?id=98399 [2] https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/45696 [3] http://forums.linuxmint.com/viewtopic.php?f=150t=36708p=211140 [4] https://bugzilla.kernel.org/show_bug.cgi?id=45911 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 3.12: ethernet controller missing after resuming from suspend to RAM
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 :04:00.5: irq 50 for MSI/MSI-X [ 49.671645] jme :04:00.5 eth0: Link is down Well, this means that Ethernet device is present after the resume. [ 49.671717] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready [ 49.674119] iwlwifi :05:00.0: L1 Enabled; Disabling L0S [ 49.681037] iwlwifi :05:00.0: Radio type=0x1-0x3-0x1 [ 49.778035] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready [ 49.806241] xhci_hcd :02:00.0: no hotplug settings from platform [ 49.859417] iwlwifi :05:00.0: no hotplug settings from platform [ 56.264694] wlan0: authenticate with [STRIPPED] [ 56.277969] wlan0: send auth to [STRIPPED] (try 1/3) [ 56.282076] wlan0: authenticated [ 56.283879] wlan0: associate with [STRIPPED] (try 1/3) [ 56.297196] wlan0: RX AssocResp from [STRIPPED] (capab=0x411 status=0 aid=6) [ 56.303746] wlan0: associated [ 56.303826] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready Can you check the lspci differences between before/after the suspend-resume cycle? -- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 3.12: ethernet controller missing after resuming from suspend to RAM
On Friday, February 07, 2014 12:41:44 AM Bastien Traverse wrote: [...] [ 200.934601] ACPI: Waking up from system sleep state S3 [ 200.993469] xhci_hcd :00:14.0: System wakeup disabled by ACPI [ 201.006819] ehci-pci :00:1a.0: System wakeup disabled by ACPI [ 201.033495] ehci-pci :00:1d.0: System wakeup disabled by ACPI [ 201.087040] PM: noirq resume of devices complete after 118.140 msecs [ 201.087233] PM: early resume of devices complete after 0.169 msecs [ 201.087270] i915 :00:02.0: setting latency timer to 64 [ 201.087272] xhci_hcd :00:14.0: setting latency timer to 64 [ 201.087456] ehci-pci :00:1a.0: setting latency timer to 64 [ 201.087597] snd_hda_intel :00:1b.0: irq 43 for MSI/MSI-X [ 201.090717] ahci :00:1f.2: setting latency timer to 64 [ 201.090802] ehci-pci :00:1d.0: setting latency timer to 64 [ 201.090889] r8169 :03:00.2: System wakeup disabled by ACPI The device appears to be alive here. [ 201.430358] ata5: SATA link up 3.0 Gbps (SStatus 123 SControl 300) [ 201.437019] ata3: SATA link up 1.5 Gbps (SStatus 113 SControl 300) [ 201.509645] ata5.00: ACPI cmd ef/10:06:00:00:00:00 (SET FEATURES) succeeded [ 201.509647] ata5.00: ACPI cmd f5/00:00:00:00:00:00 (SECURITY FREEZE LOCK) filtered out [ 201.509649] ata5.00: ACPI cmd b1/c1:00:00:00:00:00 (DEVICE CONFIGURATION OVERLAY) filtered out [ 201.509919] ata5.00: supports DRM functions and may not be fully accessible [ 201.516754] ata5.00: ACPI cmd ef/10:06:00:00:00:00 (SET FEATURES) succeeded [ 201.516756] ata5.00: ACPI cmd f5/00:00:00:00:00:00 (SECURITY FREEZE LOCK) filtered out [ 201.516757] ata5.00: ACPI cmd b1/c1:00:00:00:00:00 (DEVICE CONFIGURATION OVERLAY) filtered out [ 201.516998] ata5.00: supports DRM functions and may not be fully accessible [ 201.523170] ata5.00: configured for UDMA/133 [ 201.528884] ata3.00: configured for UDMA/100 [ 201.533818] sd 4:0:0:0: [sdb] Starting disk [ 202.197508] [drm] Enabling RC6 states: RC6 on, RC6p on, RC6pp on [ 203.695165] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300) [ 203.701879] ata1.00: ACPI cmd ef/10:06:00:00:00:00 (SET FEATURES) succeeded [ 203.701883] ata1.00: ACPI cmd f5/00:00:00:00:00:00 (SECURITY FREEZE LOCK) filtered out [ 203.701885] ata1.00: ACPI cmd b1/c1:00:00:00:00:00 (DEVICE CONFIGURATION OVERLAY) filtered out [ 203.715038] ata1.00: ACPI cmd ef/10:06:00:00:00:00 (SET FEATURES) succeeded [ 203.715042] ata1.00: ACPI cmd f5/00:00:00:00:00:00 (SECURITY FREEZE LOCK) filtered out [ 203.715044] ata1.00: ACPI cmd b1/c1:00:00:00:00:00 (DEVICE CONFIGURATION OVERLAY) filtered out [ 203.721440] ata1.00: configured for UDMA/133 [ 203.731960] sd 0:0:0:0: [sda] Starting disk [ 203.757734] PM: resume of devices complete after 2668.846 msecs [ 203.758038] PM: Finishing wakeup. [ 203.758039] Restarting tasks ... done. [ 203.758936] video LNXVIDEO:00: Restoring backlight state [ 203.784008] iwlwifi :02:00.0: L1 Disabled; Enabling L0S [ 203.792083] iwlwifi :02:00.0: Radio type=0x2-0x0-0x0 [ 203.856125] IPv6: ADDRCONF(NETDEV_UP): wlp2s0: link is not ready [ 203.928106] r8169 :03:00.2 enp3s0f2: link down And here. [ 203.928145] IPv6: ADDRCONF(NETDEV_UP): enp3s0f2: link is not ready [ 204.999379] wlp2s0: authenticate with [MAC_STRIPPED] [ 205.003235] wlp2s0: send auth to [MAC_STRIPPED] (try 1/3) [ 205.005976] wlp2s0: authenticated [ 205.009250] wlp2s0: associate with [MAC_STRIPPED] (try 1/3) [ 205.019312] wlp2s0: RX AssocResp from [MAC_STRIPPED] (capab=0x411 status=0 aid=4) [ 205.043032] wlp2s0: associated [ 205.043069] IPv6: ADDRCONF(NETDEV_CHANGE): wlp2s0: link becomes ready And there's no comments indicating any hotplug-related activity. Here's the diff between before/after lspci -nnvt: 9,10c9 +-1c.3-[03]--+-00.0 Realtek Semiconductor Co., Ltd. Device [10ec:5289] |\-00.2 Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller [10ec:8168] --- +-1c.3-[03]-- Please tell me if you need the lspci log in complete form or how to tune the diff command. Please send the output of lspci -vv right before suspend and right after the subsequent resume as attachments. Thanks! -- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 3.12: ethernet controller missing after resuming from suspend to RAM
On 02/07/2014 12:15 AM, Bastien Traverse wrote: I was also hit by the rtsx driver bug (https://bugs.archlinux.org/task/37720) and was delighted with its fast resolution. I was hoping that its fix would also address the disappearing Ethernet bug. yeah, but calling this fast resolution is quite incorrect. I don't blame anyone for this and I'm quite happy that a workaround has been found at last but calling this fast resolution is a bit funny compare to the PITA it was to debug this. That's probably why I haven't tried to do a similar work for this bug. Thanks. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 3.12: ethernet controller missing after resuming from suspend to RAM
Hi, On 02/06/2014 12:42 AM, Bastien Traverse wrote: > Hello, > > I'm encountering the exact same problem (same model of machine, same > controller, same OS) and was wondering where this bug was at. I'm still leaving with this issue since my initial posting unfortunately :( I'm wondering why PM support on this machine is so crapish (it initialy oopsed when resuming due to a bug in rtsx driver). Thanks -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 3.12: ethernet controller missing after resuming from suspend to RAM
Hello, I'm encountering the exact same problem (same model of machine, same controller, same OS) and was wondering where this bug was at. I just used my Ethernet NIC for the first time on an up-to-date Archlinux; it was working fine until I suspended to RAM: on resume the Realtek/Ethernet device had completely disappeared. The two entries absent from lspci output after resume are: $ sudo lspci -v (…) 03:00.0 Unassigned class [ff00]: Realtek Semiconductor Co., Ltd. Device 5289 (rev 01) Subsystem: CLEVO/KAPOK Computer Device 0540 Flags: bus master, fast devsel, latency 0, IRQ 44 Memory at f720 (32-bit, non-prefetchable) [size=64K] Capabilities: [40] Power Management version 3 Capabilities: [50] MSI: Enable+ Count=1/1 Maskable- 64bit+ Capabilities: [70] Express Endpoint, MSI 00 Capabilities: [b0] MSI-X: Enable- Count=1 Masked- Capabilities: [d0] Vital Product Data Capabilities: [100] Advanced Error Reporting Capabilities: [140] Virtual Channel Capabilities: [160] Device Serial Number 00-00-00-00-00-00-00-00 Kernel driver in use: rtsx_pci Kernel modules: rtsx_pci 03:00.2 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 0a) Subsystem: CLEVO/KAPOK Computer Device 0540 Flags: bus master, fast devsel, latency 0, IRQ 45 I/O ports at e000 [size=256] Memory at f0a04000 (64-bit, prefetchable) [size=4K] Memory at f0a0 (64-bit, prefetchable) [size=16K] Capabilities: [40] Power Management version 3 Capabilities: [50] MSI: Enable+ Count=1/1 Maskable- 64bit+ Capabilities: [70] Express Endpoint, MSI 01 Capabilities: [b0] MSI-X: Enable- Count=4 Masked- Capabilities: [d0] Vital Product Data Capabilities: [100] Advanced Error Reporting Capabilities: [160] Device Serial Number 02-00-00-00-68-4c-e0-00 Kernel driver in use: r8169 Kernel modules: r8169 Trying to modprobe r8169 & rtsx_pci didn't change anything. Tell me whether my dmesg may be of any use, but I doubt it as it is pretty close to original poster's one. Thanks, Bastien -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 3.12: ethernet controller missing after resuming from suspend to RAM
Hello, I'm encountering the exact same problem (same model of machine, same controller, same OS) and was wondering where this bug was at. I just used my Ethernet NIC for the first time on an up-to-date Archlinux; it was working fine until I suspended to RAM: on resume the Realtek/Ethernet device had completely disappeared. The two entries absent from lspci output after resume are: $ sudo lspci -v (…) 03:00.0 Unassigned class [ff00]: Realtek Semiconductor Co., Ltd. Device 5289 (rev 01) Subsystem: CLEVO/KAPOK Computer Device 0540 Flags: bus master, fast devsel, latency 0, IRQ 44 Memory at f720 (32-bit, non-prefetchable) [size=64K] Capabilities: [40] Power Management version 3 Capabilities: [50] MSI: Enable+ Count=1/1 Maskable- 64bit+ Capabilities: [70] Express Endpoint, MSI 00 Capabilities: [b0] MSI-X: Enable- Count=1 Masked- Capabilities: [d0] Vital Product Data Capabilities: [100] Advanced Error Reporting Capabilities: [140] Virtual Channel Capabilities: [160] Device Serial Number 00-00-00-00-00-00-00-00 Kernel driver in use: rtsx_pci Kernel modules: rtsx_pci 03:00.2 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 0a) Subsystem: CLEVO/KAPOK Computer Device 0540 Flags: bus master, fast devsel, latency 0, IRQ 45 I/O ports at e000 [size=256] Memory at f0a04000 (64-bit, prefetchable) [size=4K] Memory at f0a0 (64-bit, prefetchable) [size=16K] Capabilities: [40] Power Management version 3 Capabilities: [50] MSI: Enable+ Count=1/1 Maskable- 64bit+ Capabilities: [70] Express Endpoint, MSI 01 Capabilities: [b0] MSI-X: Enable- Count=4 Masked- Capabilities: [d0] Vital Product Data Capabilities: [100] Advanced Error Reporting Capabilities: [160] Device Serial Number 02-00-00-00-68-4c-e0-00 Kernel driver in use: r8169 Kernel modules: r8169 Trying to modprobe r8169 rtsx_pci didn't change anything. Tell me whether my dmesg may be of any use, but I doubt it as it is pretty close to original poster's one. Thanks, Bastien -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 3.12: ethernet controller missing after resuming from suspend to RAM
Hi, On 02/06/2014 12:42 AM, Bastien Traverse wrote: Hello, I'm encountering the exact same problem (same model of machine, same controller, same OS) and was wondering where this bug was at. I'm still leaving with this issue since my initial posting unfortunately :( I'm wondering why PM support on this machine is so crapish (it initialy oopsed when resuming due to a bug in rtsx driver). Thanks -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 3.12: ethernet controller missing after resuming from suspend to RAM
Hello Rafael, Could you see something in the logs ? Thanks On 12/12/2013 08:17 PM, Francis Moreau wrote: > On 12/12/2013 06:58 PM, Rafael J. Wysocki wrote: >> On Thursday, December 12, 2013 06:43:03 PM Francis Moreau wrote: > > [...] > >>> >>> Actually I can see this now: >>> >>> [ 42.400974] r8169 :03:00.2: System wakeup disabled by ACPI >> >> This should be harmless. >> >> Please run lspci -vv before and after suspend and send both results. > > Please find them attached. > > Thanks. > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 3.12: ethernet controller missing after resuming from suspend to RAM
Hello Rafael, Could you see something in the logs ? Thanks On 12/12/2013 08:17 PM, Francis Moreau wrote: On 12/12/2013 06:58 PM, Rafael J. Wysocki wrote: On Thursday, December 12, 2013 06:43:03 PM Francis Moreau wrote: [...] Actually I can see this now: [ 42.400974] r8169 :03:00.2: System wakeup disabled by ACPI This should be harmless. Please run lspci -vv before and after suspend and send both results. Please find them attached. Thanks. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 3.12: ethernet controller missing after resuming from suspend to RAM
On 12/12/2013 06:58 PM, Rafael J. Wysocki wrote: > On Thursday, December 12, 2013 06:43:03 PM Francis Moreau wrote: [...] >> >> Actually I can see this now: >> >> [ 42.400974] r8169 :03:00.2: System wakeup disabled by ACPI > > This should be harmless. > > Please run lspci -vv before and after suspend and send both results. Please find them attached. Thanks. 00:00.0 Host bridge: Intel Corporation 3rd Gen Core processor DRAM Controller (rev 09) Subsystem: CLEVO/KAPOK Computer Device 0550 Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- 00:02.0 VGA compatible controller: Intel Corporation 3rd Gen Core processor Graphics Controller (rev 09) (prog-if 00 [VGA controller]) Subsystem: CLEVO/KAPOK Computer Device 0550 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- [disabled] Capabilities: Kernel driver in use: i915 Kernel modules: i915 00:14.0 USB controller: Intel Corporation 7 Series/C210 Series Chipset Family USB xHCI Host Controller (rev 04) (prog-if 30 [XHCI]) Subsystem: CLEVO/KAPOK Computer Device 0550 Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- Kernel driver in use: xhci_hcd Kernel modules: xhci_hcd 00:16.0 Communication controller: Intel Corporation 7 Series/C210 Series Chipset Family MEI Controller #1 (rev 04) Subsystem: CLEVO/KAPOK Computer Device 0550 Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- Kernel driver in use: mei_me Kernel modules: mei_me 00:1a.0 USB controller: Intel Corporation 7 Series/C210 Series Chipset Family USB Enhanced Host Controller #2 (rev 04) (prog-if 20 [EHCI]) Subsystem: CLEVO/KAPOK Computer Device 0550 Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- Kernel driver in use: ehci-pci Kernel modules: ehci_pci 00:1b.0 Audio device: Intel Corporation 7 Series/C210 Series Chipset Family High Definition Audio Controller (rev 04) Subsystem: CLEVO/KAPOK Computer Device 0550 Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- Kernel driver in use: snd_hda_intel Kernel modules: snd_hda_intel 00:1c.0 PCI bridge: Intel Corporation 7 Series/C210 Series Chipset Family PCI Express Root Port 1 (rev c4) (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- SERR- TAbort- Reset- FastB2B- PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn- Capabilities: Kernel driver in use: pcieport Kernel modules: shpchp 00:1c.2 PCI bridge: Intel Corporation 7 Series/C210 Series Chipset Family PCI Express Root Port 3 (rev c4) (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- SERR- TAbort- Reset- FastB2B- PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn- Capabilities: Kernel driver in use: pcieport Kernel modules: shpchp 00:1c.3 PCI bridge: Intel Corporation 7 Series/C210 Series Chipset Family PCI Express Root Port 4 (rev c4) (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- SERR- TAbort- Reset- FastB2B- PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn- Capabilities: Kernel driver in use: pcieport Kernel modules: shpchp 00:1c.4 PCI bridge: Intel Corporation 7 Series/C210 Series Chipset Family PCI Express Root Port 5 (rev c4) (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- SERR- TAbort- Reset- FastB2B- PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn- Capabilities: Kernel driver in use: pcieport Kernel modules: shpchp
Re: 3.12: ethernet controller missing after resuming from suspend to RAM
On Thursday, December 12, 2013 06:43:03 PM Francis Moreau wrote: > Hi Rafael, > > On 12/12/2013 03:57 PM, Rafael J. Wysocki wrote: > > On Thursday, December 12, 2013 09:00:01 AM Francis Moreau wrote: > >> Hello, > >> > >> I'm encountering an issue after resuming my system from suspend to RAM: > >> my ethernet controller is missing, it seems that the kernel doesn't see > >> it anymore. It's missing from /sys/class/net. > >> > >> Before suspending, this is what lspci gives. > >> > >> 03:00.2 Ethernet controller: Realtek Semiconductor Co., Ltd. > >> RTL8111/8168 PCI Express Gigabit Ethernet controller (rev 0a) > >> Subsystem: CLEVO/KAPOK Computer Device 0540 > >> Flags: bus master, fast devsel, latency 0, IRQ 46 > >> I/O ports at e000 [size=256] > >> Memory at f0a04000 (64-bit, prefetchable) [size=4K] > >> Memory at f0a0 (64-bit, prefetchable) [size=16K] > >> Capabilities: [40] Power Management version 3 > >> Capabilities: [50] MSI: Enable+ Count=1/1 Maskable- 64bit+ > >> Capabilities: [70] Express Endpoint, MSI 01 > >> Capabilities: [b0] MSI-X: Enable- Count=4 Masked- > >> Capabilities: [d0] Vital Product Data > >> Capabilities: [100] Advanced Error Reporting > >> Capabilities: [160] Device Serial Number 02-00-00-00-68-4c-e0-00 > >> Kernel driver in use: r8169 > >> Kernel modules: r8169 > >> > >> I can't see anything obvious in dmesg. > > > > Please send a dmesg output including the first suspend-resume cycle > > after a fresh boot (the one when you lose the NIC). > > Here it is. > > Actually I can see this now: > > [ 42.400974] r8169 :03:00.2: System wakeup disabled by ACPI This should be harmless. Please run lspci -vv before and after suspend and send both results. Thanks, Rafael -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 3.12: ethernet controller missing after resuming from suspend to RAM
On Thursday, December 12, 2013 09:00:01 AM Francis Moreau wrote: > Hello, > > I'm encountering an issue after resuming my system from suspend to RAM: > my ethernet controller is missing, it seems that the kernel doesn't see > it anymore. It's missing from /sys/class/net. > > Before suspending, this is what lspci gives. > > 03:00.2 Ethernet controller: Realtek Semiconductor Co., Ltd. > RTL8111/8168 PCI Express Gigabit Ethernet controller (rev 0a) > Subsystem: CLEVO/KAPOK Computer Device 0540 > Flags: bus master, fast devsel, latency 0, IRQ 46 > I/O ports at e000 [size=256] > Memory at f0a04000 (64-bit, prefetchable) [size=4K] > Memory at f0a0 (64-bit, prefetchable) [size=16K] > Capabilities: [40] Power Management version 3 > Capabilities: [50] MSI: Enable+ Count=1/1 Maskable- 64bit+ > Capabilities: [70] Express Endpoint, MSI 01 > Capabilities: [b0] MSI-X: Enable- Count=4 Masked- > Capabilities: [d0] Vital Product Data > Capabilities: [100] Advanced Error Reporting > Capabilities: [160] Device Serial Number 02-00-00-00-68-4c-e0-00 > Kernel driver in use: r8169 > Kernel modules: r8169 > > I can't see anything obvious in dmesg. Please send a dmesg output including the first suspend-resume cycle after a fresh boot (the one when you lose the NIC). Thanks, Rafael -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 3.12: ethernet controller missing after resuming from suspend to RAM
On 12/12/2013 09:00 AM, Francis Moreau wrote: > Hello, > > I'm encountering an issue after resuming my system from suspend to RAM: > my ethernet controller is missing, it seems that the kernel doesn't see > it anymore. It's missing from /sys/class/net. > > Before suspending, this is what lspci gives. > > 03:00.2 Ethernet controller: Realtek Semiconductor Co., Ltd. > RTL8111/8168 PCI Express Gigabit Ethernet controller (rev 0a) > Subsystem: CLEVO/KAPOK Computer Device 0540 > Flags: bus master, fast devsel, latency 0, IRQ 46 > I/O ports at e000 [size=256] > Memory at f0a04000 (64-bit, prefetchable) [size=4K] > Memory at f0a0 (64-bit, prefetchable) [size=16K] > Capabilities: [40] Power Management version 3 > Capabilities: [50] MSI: Enable+ Count=1/1 Maskable- 64bit+ > Capabilities: [70] Express Endpoint, MSI 01 > Capabilities: [b0] MSI-X: Enable- Count=4 Masked- > Capabilities: [d0] Vital Product Data > Capabilities: [100] Advanced Error Reporting > Capabilities: [160] Device Serial Number 02-00-00-00-68-4c-e0-00 > Kernel driver in use: r8169 > Kernel modules: r8169 > > I can't see anything obvious in dmesg. > > Could anybody help me to fix this ? > Additionnal information: I have the same symptom when doing suspend to disk. Thanks. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
3.12: ethernet controller missing after resuming from suspend to RAM
Hello, I'm encountering an issue after resuming my system from suspend to RAM: my ethernet controller is missing, it seems that the kernel doesn't see it anymore. It's missing from /sys/class/net. Before suspending, this is what lspci gives. 03:00.2 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168 PCI Express Gigabit Ethernet controller (rev 0a) Subsystem: CLEVO/KAPOK Computer Device 0540 Flags: bus master, fast devsel, latency 0, IRQ 46 I/O ports at e000 [size=256] Memory at f0a04000 (64-bit, prefetchable) [size=4K] Memory at f0a0 (64-bit, prefetchable) [size=16K] Capabilities: [40] Power Management version 3 Capabilities: [50] MSI: Enable+ Count=1/1 Maskable- 64bit+ Capabilities: [70] Express Endpoint, MSI 01 Capabilities: [b0] MSI-X: Enable- Count=4 Masked- Capabilities: [d0] Vital Product Data Capabilities: [100] Advanced Error Reporting Capabilities: [160] Device Serial Number 02-00-00-00-68-4c-e0-00 Kernel driver in use: r8169 Kernel modules: r8169 I can't see anything obvious in dmesg. Could anybody help me to fix this ? Thanks. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
3.12: ethernet controller missing after resuming from suspend to RAM
Hello, I'm encountering an issue after resuming my system from suspend to RAM: my ethernet controller is missing, it seems that the kernel doesn't see it anymore. It's missing from /sys/class/net. Before suspending, this is what lspci gives. 03:00.2 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168 PCI Express Gigabit Ethernet controller (rev 0a) Subsystem: CLEVO/KAPOK Computer Device 0540 Flags: bus master, fast devsel, latency 0, IRQ 46 I/O ports at e000 [size=256] Memory at f0a04000 (64-bit, prefetchable) [size=4K] Memory at f0a0 (64-bit, prefetchable) [size=16K] Capabilities: [40] Power Management version 3 Capabilities: [50] MSI: Enable+ Count=1/1 Maskable- 64bit+ Capabilities: [70] Express Endpoint, MSI 01 Capabilities: [b0] MSI-X: Enable- Count=4 Masked- Capabilities: [d0] Vital Product Data Capabilities: [100] Advanced Error Reporting Capabilities: [160] Device Serial Number 02-00-00-00-68-4c-e0-00 Kernel driver in use: r8169 Kernel modules: r8169 I can't see anything obvious in dmesg. Could anybody help me to fix this ? Thanks. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 3.12: ethernet controller missing after resuming from suspend to RAM
On 12/12/2013 09:00 AM, Francis Moreau wrote: Hello, I'm encountering an issue after resuming my system from suspend to RAM: my ethernet controller is missing, it seems that the kernel doesn't see it anymore. It's missing from /sys/class/net. Before suspending, this is what lspci gives. 03:00.2 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168 PCI Express Gigabit Ethernet controller (rev 0a) Subsystem: CLEVO/KAPOK Computer Device 0540 Flags: bus master, fast devsel, latency 0, IRQ 46 I/O ports at e000 [size=256] Memory at f0a04000 (64-bit, prefetchable) [size=4K] Memory at f0a0 (64-bit, prefetchable) [size=16K] Capabilities: [40] Power Management version 3 Capabilities: [50] MSI: Enable+ Count=1/1 Maskable- 64bit+ Capabilities: [70] Express Endpoint, MSI 01 Capabilities: [b0] MSI-X: Enable- Count=4 Masked- Capabilities: [d0] Vital Product Data Capabilities: [100] Advanced Error Reporting Capabilities: [160] Device Serial Number 02-00-00-00-68-4c-e0-00 Kernel driver in use: r8169 Kernel modules: r8169 I can't see anything obvious in dmesg. Could anybody help me to fix this ? Additionnal information: I have the same symptom when doing suspend to disk. Thanks. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 3.12: ethernet controller missing after resuming from suspend to RAM
On Thursday, December 12, 2013 09:00:01 AM Francis Moreau wrote: Hello, I'm encountering an issue after resuming my system from suspend to RAM: my ethernet controller is missing, it seems that the kernel doesn't see it anymore. It's missing from /sys/class/net. Before suspending, this is what lspci gives. 03:00.2 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168 PCI Express Gigabit Ethernet controller (rev 0a) Subsystem: CLEVO/KAPOK Computer Device 0540 Flags: bus master, fast devsel, latency 0, IRQ 46 I/O ports at e000 [size=256] Memory at f0a04000 (64-bit, prefetchable) [size=4K] Memory at f0a0 (64-bit, prefetchable) [size=16K] Capabilities: [40] Power Management version 3 Capabilities: [50] MSI: Enable+ Count=1/1 Maskable- 64bit+ Capabilities: [70] Express Endpoint, MSI 01 Capabilities: [b0] MSI-X: Enable- Count=4 Masked- Capabilities: [d0] Vital Product Data Capabilities: [100] Advanced Error Reporting Capabilities: [160] Device Serial Number 02-00-00-00-68-4c-e0-00 Kernel driver in use: r8169 Kernel modules: r8169 I can't see anything obvious in dmesg. Please send a dmesg output including the first suspend-resume cycle after a fresh boot (the one when you lose the NIC). Thanks, Rafael -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 3.12: ethernet controller missing after resuming from suspend to RAM
On Thursday, December 12, 2013 06:43:03 PM Francis Moreau wrote: Hi Rafael, On 12/12/2013 03:57 PM, Rafael J. Wysocki wrote: On Thursday, December 12, 2013 09:00:01 AM Francis Moreau wrote: Hello, I'm encountering an issue after resuming my system from suspend to RAM: my ethernet controller is missing, it seems that the kernel doesn't see it anymore. It's missing from /sys/class/net. Before suspending, this is what lspci gives. 03:00.2 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168 PCI Express Gigabit Ethernet controller (rev 0a) Subsystem: CLEVO/KAPOK Computer Device 0540 Flags: bus master, fast devsel, latency 0, IRQ 46 I/O ports at e000 [size=256] Memory at f0a04000 (64-bit, prefetchable) [size=4K] Memory at f0a0 (64-bit, prefetchable) [size=16K] Capabilities: [40] Power Management version 3 Capabilities: [50] MSI: Enable+ Count=1/1 Maskable- 64bit+ Capabilities: [70] Express Endpoint, MSI 01 Capabilities: [b0] MSI-X: Enable- Count=4 Masked- Capabilities: [d0] Vital Product Data Capabilities: [100] Advanced Error Reporting Capabilities: [160] Device Serial Number 02-00-00-00-68-4c-e0-00 Kernel driver in use: r8169 Kernel modules: r8169 I can't see anything obvious in dmesg. Please send a dmesg output including the first suspend-resume cycle after a fresh boot (the one when you lose the NIC). Here it is. Actually I can see this now: [ 42.400974] r8169 :03:00.2: System wakeup disabled by ACPI This should be harmless. Please run lspci -vv before and after suspend and send both results. Thanks, Rafael -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 3.12: ethernet controller missing after resuming from suspend to RAM
On 12/12/2013 06:58 PM, Rafael J. Wysocki wrote: On Thursday, December 12, 2013 06:43:03 PM Francis Moreau wrote: [...] Actually I can see this now: [ 42.400974] r8169 :03:00.2: System wakeup disabled by ACPI This should be harmless. Please run lspci -vv before and after suspend and send both results. Please find them attached. Thanks. 00:00.0 Host bridge: Intel Corporation 3rd Gen Core processor DRAM Controller (rev 09) Subsystem: CLEVO/KAPOK Computer Device 0550 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 Capabilities: access denied 00:02.0 VGA compatible controller: Intel Corporation 3rd Gen Core processor Graphics Controller (rev 09) (prog-if 00 [VGA controller]) Subsystem: CLEVO/KAPOK Computer Device 0550 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 Interrupt: pin A routed to IRQ 40 Region 0: Memory at f640 (64-bit, non-prefetchable) [size=4M] Region 2: Memory at e000 (64-bit, prefetchable) [size=256M] Region 4: I/O ports at f000 [size=64] Expansion ROM at unassigned [disabled] Capabilities: access denied Kernel driver in use: i915 Kernel modules: i915 00:14.0 USB controller: Intel Corporation 7 Series/C210 Series Chipset Family USB xHCI Host Controller (rev 04) (prog-if 30 [XHCI]) Subsystem: CLEVO/KAPOK Computer Device 0550 Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- INTx- Latency: 0 Interrupt: pin A routed to IRQ 42 Region 0: Memory at f7d0 (64-bit, non-prefetchable) [size=64K] Capabilities: access denied Kernel driver in use: xhci_hcd Kernel modules: xhci_hcd 00:16.0 Communication controller: Intel Corporation 7 Series/C210 Series Chipset Family MEI Controller #1 (rev 04) Subsystem: CLEVO/KAPOK Computer Device 0550 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 Interrupt: pin A routed to IRQ 44 Region 0: Memory at f7d1b000 (64-bit, non-prefetchable) [size=16] Capabilities: access denied Kernel driver in use: mei_me Kernel modules: mei_me 00:1a.0 USB controller: Intel Corporation 7 Series/C210 Series Chipset Family USB Enhanced Host Controller #2 (rev 04) (prog-if 20 [EHCI]) Subsystem: CLEVO/KAPOK Computer Device 0550 Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- INTx- Latency: 0 Interrupt: pin A routed to IRQ 16 Region 0: Memory at f7d18000 (32-bit, non-prefetchable) [size=1K] Capabilities: access denied Kernel driver in use: ehci-pci Kernel modules: ehci_pci 00:1b.0 Audio device: Intel Corporation 7 Series/C210 Series Chipset Family High Definition Audio Controller (rev 04) Subsystem: CLEVO/KAPOK Computer Device 0550 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 45 Region 0: Memory at f7d1 (64-bit, non-prefetchable) [size=16K] Capabilities: access denied Kernel driver in use: snd_hda_intel Kernel modules: snd_hda_intel 00:1c.0 PCI bridge: Intel Corporation 7 Series/C210 Series Chipset Family PCI Express Root Port 1 (rev c4) (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=01, subordinate=01, sec-latency=0 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
