** Changed in: systemd (Ubuntu)
Status: Triaged => Invalid
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1450396
Title:
Gigabyte P35-DS3: does not stay suspended
I just tested it, just by installing the 4.8.0 Kernel in Ubuntu 16.04,
without any workaround and Nvidia drivers enabled. Nothing changed so
far.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
** Bug watch added: Linux Kernel Bug Tracker #105981
http://bugzilla.kernel.org/show_bug.cgi?id=105981
** Also affects: systemd via
http://bugzilla.kernel.org/show_bug.cgi?id=105981
Importance: Unknown
Status: Unknown
** Project changed: systemd => linux
--
You received this
Here are the links to the upstream bug report that I posted to the
linux-pm and the netdev mailing list:
https://marc.info/?l=linux-pm=144420765316442=2
http://www.spinics.net/lists/netdev/msg346751.html
--
You received this bug notification because you are a member of Ubuntu
Touch seeded
Ok, I made a resume trace with my workaround deactivated on Kernel
4.3-rc4, while the bug (= waking up automatically) appeared.
I have attached two dmesg files: The first one contains the output
directly after resume. The second one contains the output directly after
the next reboot. I'm not sure
** Attachment added: "Output of dmesg after next reboot"
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1450396/+attachment/4486124/+files/dmesg-after-next-reboot.txt
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed
** Attachment added: "/proc/acpi/wakeup"
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1450396/+attachment/4485485/+files/wakeup
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
Christopher, yes, my workaround seems to work in both cases 1) and 2) (
=PC stays suspended properly and doesn't power itself on unwantedly).
Btw. it seems that which graphics driver is in use is completely
unrelated to this bug.
Regarding 3):
- It doesn't seem to matter if I suspend by pressing
Jan Rathmann, the issue you are reporting is an upstream one. Could you
please report this problem following the instructions verbatim at
https://wiki.ubuntu.com/Bugs/Upstream/kernel to the appropriate venue
(linux-pm)?
Please provide a direct URL to your newly made report when it becomes
Jan Rathmann:
>"- Is it really necessary to provide a resume trace?"
Yes the trace is helpful with the latest mainline kernel (now 4.3-rc4). Just
narrowing it down it WOL isn't necessarily enough for a developer to fix it
quickly. However, the requested trace may provide which file and line of a
The lasted upstream kernel I could test was 4.2.3, because with 4.3 the
compilation and installation of the Nvidia kernel module fails, and I
can only test with the propritary Nvidia driver because suspend doesn't
work properly with Nouveau on my card.
** Tags added: kernel-bug-exists-upstream
Disregard my last comment - I did a test anyway with 4.3-rc4 and Nouveau
and supending with Nouveau worked at least one time so I could reproduce
and confirm the bug for 4.3-rc4.
** Tags removed: kernel-bug-exists-upstream-4.2.3
** Tags added: kernel-bug-exists-upstream-4.3-rc4
--
You received
Jan Rathmann, to clarify:
1) If you use nvidia with 4.2.3, are you able to suspend with the WORKAROUND
noted in
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1450396/comments/22 ?
2) If you use nouveau with 4.3-rc4, are you able to suspend with the
WORKAROUND noted in
I'm attaching the script here that I'm using as a workaround under Vivid
and Wily for proper suspend (put into /lib/systemd/system-sleep).
Kind regards,
Jan
** Attachment added: "set-wol-on-suspend.sh"
Jan Rathmann, as per http://www.gigabyte.com/products/product-
page.aspx?pid=2544#bios an update to your computer's buggy and outdated
BIOS is available (F14). If you update to this following
https://help.ubuntu.com/community/BIOSUpdate does it change anything?
If it doesn't, could you please
Hello Christopher,
I updated the BIOS to F14 a few months ago to test if this makes any
change on the bug, but it didn't.
Here's the output of sudo dmidecode -s bios-version && sudo dmidecode -s
bios-release-date:
F14
06/18/2009
Kind regards,
Jan
** Changed in: linux (Ubuntu)
Status:
Jan Rathmann, could you please test the latest upstream kernel available
from the very top line at the top of the page from
http://kernel.ubuntu.com/~kernel-ppa/mainline/?C=N;O=D (the release
names are irrelevant for testing, and please do not test the daily
folder)? Install instructions are
Thanks for your patience! I believe this is sufficiently understood now.
I retitled the bug accordingly, this should indeed be fixed properly in
the driver then. In the meantime, putting that workaround into rc.local
or /lib/systemd/system-sleep/ (see man systemd-suspend.service) is fine.
**
Hello Martin,
I think I have found the real cause of the bug: It seems to always
happen when the wol flag is set to 'ug' (instead of 'g' or 'd'). I made
a few reboots and checked the wol value with 'ethtool eth0' and it was
always set to 'ug' by default after system startup (I don't know if this
Martin, I did check that and I think I can preliminary give results that
are quite interesting:
- If I run the ethtool command before 'systemctl suspend', the bug
hasn't appeared so far - and it does not seem to matter if I run ethtool
with the 'wol g' (enable WOL) or with the 'wol d' flag!
-
Hello Jan,
Jan Rathmann [2015-06-15 14:06 -]:
- If I run the ethtool command before 'systemctl suspend', the bug
hasn't appeared so far - and it does not seem to matter if I run ethtool
with the 'wol g' (enable WOL) or with the 'wol d' flag!
That's indeed interesting -- After a clean
Ah, great. So can you confirm that this works:
sudo pm-powersave false; sudo systemctl suspend; sudo pm-powersave
true
? If so, can you repeat the bisecting exercise with the hooks in
/usr/lib/pm-utils/power.d/ to find out which one is the important one
here?
Thanks!
--
You received this
Yes, 'pm-powersave false; systemctl suspend; pm-powersave true' seems to
work, and I think I have identified the responsible hook:
/usr/lib/pm-utils/power.d/disable_wol
The bug appears even when all other hooks are there and otherwise has
not occured so far when disable_wol is the only hook
Ah, thanks! That's a bit weird -- on powersave false wake-on-lan is
*enabled*. So it seems that with WOL disabled your computer doesn't stay
suspended, but with WOL enabled it does.
Cross-check:
sudo ethtool -s wlan0 wol g ; sudo systemctl suspend
- that enables WOL on the usual magick
Some progress: After I failed to identify the responsible hook by
running them before 'systemctl suspend' I had the idea to test vice
versa if I would be able to reproduce the undesired wakeups with pm-
suspend by successively disabling its hooks (=moving the files in
/usr/lib/pm-utils/sleep.d to
** Tags added: bios-outdated-f14
** Changed in: linux (Ubuntu)
Importance: Undecided = Low
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1450396
Title:
Gigabyte
Yes, the output of 'lsmod|grep alx' is indeed empty.
Since my system doesn't have wifi, I don't think anything WPA related
could be the cause. I ran the commands anyway:
sudo wpa_cli suspend ; sudo systemctl suspend; sudo wpa_cli resume
and it has no positive impact. The output of wpa_cli
Ok, then I'll test those hooks, it may take a few days before I can give
a definitive feedback because it will need quite a few suspend-resume
cycles to validate if one of the hooks really makes the problem go away.
--
You received this bug notification because you are a member of Ubuntu
Touch
Thanks Jan. Note that you can make this a little faster too -- you can
start with testing (i. e. starting with suspend) all five hooks at the
same time, to confirm whether it's actually any of these five. If it
still doesn't help, then the problem is somewhere entirely different. If
it does help,
Thanks for the hint to try more than one hook at once, that's really
useful!
I'm done with the testing faster than I thought, because unfortunately
none of the hooks makes the bug go away. I even tested applying all five
of them together, but no success.
The only thing notable is, that /bin/sh
Thanks. So we need to find out which hook does the magic. For each value
of hook in the below list, can you please run
sudo /usr/lib/pm-utils/sleep.d/hook suspend ; sudo systemctl
suspend; sudo /usr/lib/pm-utils/sleep.d/hook resume
In descending order of likelyhood, I recommend the following
OK, then it might be one of the other hooks in /usr/lib/pm-utils/sleep.d
that pm-suspend runs. According to your dmesg it's unlikely that you
have the alx module loaded (lsmod | grep alx should be empty).
Can you please attach your /var/log/pm-suspend.log?
60_wpa_supplicant could be a likely
I did check it again yesterday and today using 'systemctl suspend'. The
bug does not always happen, e.g. yesterday I was able to suspend my
system 4 or 5 times in a row properly, but tomorrow after the first
attempt the PC woke up again by itself ~2 seconds after I suspended it.
So yes, the bug is
Martin, thanks for looking into this, I have attached the requested
file.
** Attachment added: last_known_working.quirkdb
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1450396/+attachment/4408564/+files/last_known_working.quirkdb
--
You received this bug notification because you
Interesting, pm-suspend uses no quirks at all. Can you double-check that
running sudo pm-suspend is reliable while sudo systemctl suspend is
not? The two do exactly the same without quirks, i.e. writing mem into
/sys/power/state..
--
You received this bug notification because you are a member of
35 matches
Mail list logo
