The original report for this is stale. If anyone is experiencing similar
issues on different hardware with newer releases, please open a separate
bug report.
** Changed in: systemd (Ubuntu)
Status: Confirmed => Invalid
--
You received this bug notification because you are a member of Kern
Does "echo mem | sudo tee /sys/power/state" suspend the system
immediately?
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1829399
Title:
Lid switch triggered suspend takes much longer t
there has been no progress on this issue, it's the same in ubuntu 21.04.
the behavior described in #15 is especially annoying since closing the
lid by mistake (while eg carrying it around) and opening it immediately
does not cancel the suspend, it comes 30s later no matter what one is
currently doi
there has been no progress on this issue, it's the same in ubuntu 21.04.
the behavior described in #15 is especially annoying since closing the
lid by mistake (while eg carrying it around) and opening it immediately
does not cancel the suspend, it comes 30s later no matter what one is
currently doi
I can confirm behavior on my Xubuntu 20.04 x86_64 package. Suspend mode
is "assigned" to power button. Not until round about 30 seconds after
pressing the button, the PC goes into suspend mode.
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed
interesting observation: if i close the lid for, say, 1 sec, and then
open it again, after similar time delay as observed in the previous
comment, my thinkpad goes into suspend although i am working in my
desktop (obviously with the lid open). the lid close seems to trigger
the suspend which comes
similar thing happens with my lenovo thinkpad x1 carbon gen5. the time
it takes for suspend is excrutiationgly long. it used to be a couple of
seconds, at most, now the wait for the red led on top of "i" in ThinkPad
logo seems to be taking for ages to start blinking. the output of the
loop (suggest
Status changed to 'Confirmed' because the bug affects multiple users.
** Changed in: systemd (Ubuntu)
Status: New => Confirmed
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1829399
** Also affects: systemd (Ubuntu)
Importance: Undecided
Status: New
** Changed in: linux (Ubuntu)
Status: Expired => Invalid
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs
[Expired for linux (Ubuntu) because there has been no activity for 60
days.]
** Changed in: linux (Ubuntu)
Status: Incomplete => Expired
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bu
Thanks Chris, looking at journalct it seems that from the "Lid closed"
event and "Reached target Sleep" there's just 1s. So, the time between
these two events is also definitely fast, therefore the bottleneck is
not in the part of systemd that processes the "lid closed" event.
At this point I'm wo
It does seem to have improved in the last update
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1829399
Title:
Lid switch triggered suspend takes much longer than UI triggered
suspend
May 25 08:50:46 Thermia microk8s.daemon-apiserver[7167]: I0525 08:50:46.182335
7167 wrap.go:47] PUT
/api/v1/namespaces/kube-system/endpoints/kube-controller-manager?timeout=10s:
(3.332254ms) 200 [kube-controller-manager/v1.14.1 (linux/amd64)
kubernetes/b739410/leader-election 127.0.0.1:56726
Chris, any chance we can get the data that Andrea is asking for above?
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1829399
Title:
Lid switch triggered suspend takes much longer than U
Alright, the fact that `echo mem > /sys/power/state` is fast means that
the delay issue is not in the "suspend" path and we also know that it's
not even in the detection path (/proc/acpi/button/lid/LID0/state). So
the delay must be somewhere between the detection of the event and the
delivery of th
Looks like it was actually longer than 10 seconds as I opened the lid 1 sec
after the power light began to pulse.
Fri 17 May 2019 09:48:20 AM CEST - state: open
Fri 17 May 2019 09:48:21 AM CEST - state: open
Fri 17 May 2019 09:48:22 AM CEST - state: open
Fri 17 May 2019 09:48:23 AM CEST - state: o
This is interesting.
`echo mem > /sys/power/state`
This command was instant S3. The screen went black and the power light
immediately began to blink.
However...for lid switch the power light takes around 10 seconds to begin
to pulse, but the state immediately switches.
Fri 17 May 2019 09:48:22 A
Hi Chris, just to make sure I understand (from a kernel perspective),
can you confirm that `echo mem > /sys/power/state` is also fast at
reaching the suspend state?
In that case it would be interesting to check if there's a delay at
detecting the state of the lid switch. For this, could you run th
** Attachment added: "lspci-vnvn.log"
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1829399/+attachment/5264256/+files/lspci-vnvn.log
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bu
19 matches
Mail list logo
