** Changed in: systemd (Ubuntu)
Status: Triaged => Invalid
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1450396
Title:
Gigabyte P35-DS3: does not stay suspended with default "ug" wake-on-
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
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1450396
** 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 bug
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&m=144420765316442&w=2
http://www.spinics.net/lists/netdev/msg346751.html
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is
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
availabl
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
Bugs, which is subscribed to Ubuntu.
https://
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
** 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
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1450396
Titl
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 p
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
https://bugs.launc
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 t
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 ker
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 availa
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: I
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 both
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"
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1450396/+attachment/4483622/+files/s
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.
** Summa
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
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 b
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!
- Af
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 packet
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 ena
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 bug
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 a
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 sp
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,
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
Bugs, wh
** Tags added: bios-outdated-f14
** Changed in: linux (Ubuntu)
Importance: Undecided => Low
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1450396
Title:
Gigabyte P35-DS3: does not stay suspended
Thanks. So we need to find out which hook does the magic. For each value
of in the below list, can you please run
sudo /usr/lib/pm-utils/sleep.d/ suspend ; sudo systemctl
suspend; sudo /usr/lib/pm-utils/sleep.d/ resume
In descending order of likelyhood, I recommend the following list for
:
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 is
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
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 memb
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 a
35 matches
Mail list logo
