Small inconvenience but new and annoying: Machine is Thinkpad x260 uname -a: Linux rwells-x260 4.14.7-300.fc27.x86_64 #1 SMP Mon Dec 18 16:06:12 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux Desktop: Gnome 3.26.4-1.fc27.x86_64
When the lid is opened on the suspended machine the screen saver appears and the clock proceeds to update until the enter key is hit. Then the clock stops updating for 27 seconds followed by the login entry dialog appearing. Then everything is back to normal. This began right after the upgrade from F26 to F27 and has persisted through one or two subsequent routine updates. There are inconsistencies, sometimes it only does it when there is only wireless connections and no wired options. Sometimes it doesn't do it at all, no pattern here. Sometimes the 27 second delay is much shorter but this is quite rare. I have been running Fedora/Gnome for years and have never seen this.
Any thoughts or things to try to help pin it down will be appreciated.
thanks
-
Roger Wells, P.E. leidos 221 Third St Newport, RI 02840 401-847-4210 (voice) 401-849-1585 (fax) roger.k.wells@leidos.com
On 12/26/2017 12:23 PM, Wells, Roger K. wrote:
Small inconvenience but new and annoying: Machine is Thinkpad x260 uname -a: Linux rwells-x260 4.14.7-300.fc27.x86_64 #1 SMP Mon Dec 18 16:06:12 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux Desktop: Gnome 3.26.4-1.fc27.x86_64
When the lid is opened on the suspended machine the screen saver appears and the clock proceeds to update until the enter key is hit. Then the clock stops updating for 27 seconds followed by the login entry dialog appearing. Then everything is back to normal. This began right after the upgrade from F26 to F27 and has persisted through one or two subsequent routine updates. There are inconsistencies, sometimes it only does it when there is only wireless connections and no wired options. Sometimes it doesn't do it at all, no pattern here. Sometimes the 27 second delay is much shorter but this is quite rare. I have been running Fedora/Gnome for years and have never seen this.
Any thoughts or things to try to help pin it down will be appreciated.
thanks
There have been a lot of recent changes in ACPI code for suspend and hibernate; it's always possible that something got tweaked in a recent kernel that could affect this particular model of machine.
That being said, the 27 second delay sounds like the laptop hibernated (not suspended); if you waited a variable length of time to open the lid again, it might explain some of the variation -- sometimes it suspended, sometimes it was caught before hibernation was complete, sometime it was caught after it had fully hibernated. The other things that occur to me are that perhaps hibernate was not working before for this model of laptop and now it does; or, the power settings changed defaults, or did not retain settings when updating; or, some of the recent changes for lid notification aren't quite right for this laptop (there have been a few cases of that). Those are some of the places where I would start looking, at least...
On 01/02/2018 01:18 PM, Al Stone wrote:
On 12/26/2017 12:23 PM, Wells, Roger K. wrote:
Small inconvenience but new and annoying: Machine is Thinkpad x260 uname -a: Linux rwells-x260 4.14.7-300.fc27.x86_64 #1 SMP Mon Dec 18 16:06:12 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux Desktop: Gnome 3.26.4-1.fc27.x86_64
When the lid is opened on the suspended machine the screen saver appears and the clock proceeds to update until the enter key is hit. Then the clock stops updating for 27 seconds followed by the login entry dialog appearing. Then everything is back to normal. This began right after the upgrade from F26 to F27 and has persisted through one or two subsequent routine updates. There are inconsistencies, sometimes it only does it when there is only wireless connections and no wired options. Sometimes it doesn't do it at all, no pattern here. Sometimes the 27 second delay is much shorter but this is quite rare. I have been running Fedora/Gnome for years and have never seen this.
Any thoughts or things to try to help pin it down will be appreciated.
thanks
There have been a lot of recent changes in ACPI code for suspend and hibernate; it's always possible that something got tweaked in a recent kernel that could affect this particular model of machine.
That being said, the 27 second delay sounds like the laptop hibernated (not suspended); if you waited a variable length of time to open the lid again, it might explain some of the variation -- sometimes it suspended, sometimes it was caught before hibernation was complete, sometime it was caught after it had fully hibernated. The other things that occur to me are that perhaps hibernate was not working before for this model of laptop and now it does; or, the power settings changed defaults, or did not retain settings when updating; or, some of the recent changes for lid notification aren't quite right for this laptop (there have been a few cases of that). Those are some of the places where I would start looking, at least...
It turns out that this delay only occurs when the suspend happened when an external filesystem is mounted. In this case a cifs mount, and IIRC there have been some issues related to version changes that necessitated specifying "vers=1.0" in the fstab file. I will do some experiments and report back if anything interesting develops.
On 01/04/2018 06:18 AM, Wells, Roger K. wrote:
On 01/02/2018 01:18 PM, Al Stone wrote:
On 12/26/2017 12:23 PM, Wells, Roger K. wrote:
Small inconvenience but new and annoying: Machine is Thinkpad x260 uname -a: Linux rwells-x260 4.14.7-300.fc27.x86_64 #1 SMP Mon Dec 18 16:06:12 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux Desktop: Gnome 3.26.4-1.fc27.x86_64
When the lid is opened on the suspended machine the screen saver appears and the clock proceeds to update until the enter key is hit. Then the clock stops updating for 27 seconds followed by the login entry dialog appearing. Then everything is back to normal. This began right after the upgrade from F26 to F27 and has persisted through one or two subsequent routine updates. There are inconsistencies, sometimes it only does it when there is only wireless connections and no wired options. Sometimes it doesn't do it at all, no pattern here. Sometimes the 27 second delay is much shorter but this is quite rare. I have been running Fedora/Gnome for years and have never seen this.
Any thoughts or things to try to help pin it down will be appreciated.
thanks
There have been a lot of recent changes in ACPI code for suspend and hibernate; it's always possible that something got tweaked in a recent kernel that could affect this particular model of machine.
That being said, the 27 second delay sounds like the laptop hibernated (not suspended); if you waited a variable length of time to open the lid again, it might explain some of the variation -- sometimes it suspended, sometimes it was caught before hibernation was complete, sometime it was caught after it had fully hibernated. The other things that occur to me are that perhaps hibernate was not working before for this model of laptop and now it does; or, the power settings changed defaults, or did not retain settings when updating; or, some of the recent changes for lid notification aren't quite right for this laptop (there have been a few cases of that). Those are some of the places where I would start looking, at least...
It turns out that this delay only occurs when the suspend happened when an external filesystem is mounted. In this case a cifs mount, and IIRC there have been some issues related to version changes that necessitated specifying "vers=1.0" in the fstab file. I will do some experiments and report back if anything interesting develops.
Interesting. Could there be an ordering dependency somewhere on resume? E.g., I need to start file system but can't do that until network is ready but the info I need to start the network is on the file system ... some weirdness like that?
On Thu, Jan 4, 2018 at 8:18 AM, Wells, Roger K. wellsr@leidos.com wrote:
It turns out that this delay only occurs when the suspend happened when an external filesystem is mounted. In this case a cifs mount, and IIRC there have been some issues related to version changes that necessitated specifying "vers=1.0" in the fstab file. I will do some experiments and report back if anything interesting develops.
If you have external network mounts, such as CIFS and NFS, you might consider using autofs or automounts or whatever your OS supports, rather than /etc/fstab mounts, to enable them by default. There's nothing quite like needing to resolve an uncommitted change, or a release a mount that is being opened by a GUI file browser, to mess with reboot processes.
(Apologies for the top-posting -- I'm on a mobile device at the moment.)
Interesting... I noticed something similar today, but with a WebDAV external filesystem mounted. Turning off fprintd seemed to stop the delay, however. Does turning off fprintd solve the problem for you as well?
-Jared
On Thu, Jan 4, 2018 at 8:18 AM, Wells, Roger K. wellsr@leidos.com wrote:
On 01/02/2018 01:18 PM, Al Stone wrote:
On 12/26/2017 12:23 PM, Wells, Roger K. wrote:
Small inconvenience but new and annoying: Machine is Thinkpad x260 uname -a: Linux rwells-x260 4.14.7-300.fc27.x86_64 #1 SMP Mon Dec 18 16:06:12 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux Desktop: Gnome 3.26.4-1.fc27.x86_64
When the lid is opened on the suspended machine the screen saver appears and the clock proceeds to update until the enter key is hit. Then the clock stops updating for 27 seconds followed by the login entry dialog appearing. Then everything is back to normal. This began right after the upgrade from F26 to F27 and has persisted through one or two subsequent routine updates. There are inconsistencies, sometimes it only does it when there is only wireless connections and no wired options. Sometimes it doesn't do it at all, no pattern here. Sometimes the 27 second delay is much shorter but this is quite rare. I have been running Fedora/Gnome for years and have never seen this.
Any thoughts or things to try to help pin it down will be appreciated.
thanks
There have been a lot of recent changes in ACPI code for suspend and hibernate; it's always possible that something got tweaked in a recent kernel that could affect this particular model of machine.
That being said, the 27 second delay sounds like the laptop hibernated (not suspended); if you waited a variable length of time to open the lid again, it might explain some of the variation -- sometimes it suspended, sometimes it was caught before hibernation was complete, sometime it was caught after it had fully hibernated. The other things that occur to me are that perhaps hibernate was not working before for this model of laptop and now it does; or, the power settings changed defaults, or did not retain settings when updating; or, some of the recent changes for lid notification aren't quite right for this laptop (there have been a few cases of that). Those are some of the places where I would start looking, at least...
It turns out that this delay only occurs when the suspend happened when
an external filesystem is mounted. In this case a cifs mount, and IIRC there have been some issues related to version changes that necessitated specifying "vers=1.0" in the fstab file. I will do some experiments and report back if anything interesting develops.
-- Roger Wells, P.E. leidos 221 Third St Newport, RI 02840 401-847-4210 (voice) 401-849-1585 (fax) roger.k.wells@leidos.com _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org
devel@lists.stg.fedoraproject.org
-
Al Stone -
Jared K. Smith -
Nico Kadel-Garcia -
Wells, Roger K.