@Christopher
BIOS update is a risky operation that I would rather like to avoid. In
addition, the only change noted for that particular update is Support Xpress
BIOS Rescue function, so it seems to me that this update will just add that
described functionality and not fix any possible bugs (at
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
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
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
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 Kernel
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!
-
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
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
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
** 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 Kernel
Packages, which is
** 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 Kernel
Packages, which is subscribed to linux in
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: "/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 Kernel
Packages, which is subscribed to linux 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
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"
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:
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
Ok, I can confirm what I wrote on #28 on another installation.
Very hard for me to tackle this down - since bisecting obviously didn't
work.
Here is a summary of what I found out about this bug:
- Artful (or any other previous Ubuntu version) was not affected (at least not
to that extend, see
@Kai-Heng
Weird, I reinstalled and tested 4.15.0-23 again, and it seems that with
4.15.0-23 it can also happen that network is not coming up after suspend and
the driver has to be reloaded.
I'm going to further test this on another installation.
--
You received this bug notification because
This patch did help, my network comes up again after suspend with that
kernel version. Thanks alot!
--
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/1779817
Title:
r8169 no internet after
I have to correct myself a bit: Network coming up correctly after
suspend only works from time to time. On the cases where it's not
working, the driver still has to be reloaded.
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in
@Kai-Heng
With this kernel version, unfortunately my network doesn't come up at all (even
after fresh power on. Reloading driver does not help).
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
@Kai-Heng
I did that, with net-next directly it seems that everything is working again at
least as good as in 4.15.0-23 (Network card comes up at boot, and also after
suspend.
So hopefully this got fixed in net-next.
--
You received this bug notification because you are a member of Kernel
@Kai-Heng
I can confirm what Erik says - my network card seems to come up properly after
suspend with the backported kernel in #39.
--
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/1779817
Kai-Heng, the bug seems to be gone on my system with your newest kernel
in #63 and I don't experience any regression so far. Thanks for your
work!
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
During the last days I tried to bisect the commit that caused the
regression, but I'm not sure if the result is correct.
According to git the bad commit is
b489141369f78ead6ed540cff29ac1974852cd7f
Can anyone confirm?
--
You received this bug notification because you are a member of Kernel
Btw. I have tested this with two separate 18.04 installations on
different partitions of my PC.
--
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/1752772
Title:
r8169 ethernet card don't
For me the update makes things worse instead of better.
Before installing the updated kernel, it only happened from time to time
that the ethernet driver had locked up after suspend (and thus needed to
be reseted by removing and reloading the module via modprobe).
With the updated
Kai-Heng:
I have tried the kernel under https://people.canonical.com/~khfeng/lp1779817/
and I see no change on my system (bug still there; reloading network driver
after resume from suspend is still necessary).
--
You received this bug notification because you are a member of Kernel
Packages,
Kai-Heng, I have tested mainline kernel 4.18-rc3 from
http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.18-rc3/ and it seems
not to fix the issue.
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
I have tested https://people.canonical.com/~khfeng/lp1779817-2/ , and it
still does not fix the bug for me.
--
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/1779817
Title:
no internet
For me the version in bionic-proposed also seems to work fine.
--
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/1779817
Title:
r8169 no internet after suspending
Status in linux package
35 matches
Mail list logo
