Description of problem: After updating to kernel-4.14.11-300.fc27.i686, when I try to resume from suspend, the system reboots (instead of resuming). This happens when the system goes to standby by itself, by keyboard shortcut, when closing the laptop lid, or explicitly choosing Suspend from the Logout dialog. Hibernating (or perhaps resuming from hibernate) has the same problem. If I select kernel-4.14.8-300.fc27.i686 from the Grub menu, suspend/resume works as expected (which is why I set component to kernel). Version-Release number of selected component (if applicable): kernel-4.14.11-300.fc27.i686 How reproducible: Every Time Steps to Reproduce: 1. Suspend the computer (for example, close the lid of the laptop) 2. Resume (for example, open the lid of the laptop) Actual results: The system reboots. Once you log in again, Firefox reports that it had crashed. Expected results: The system resumes from suspend. You may have to re-enter your password, but all programs which were running before suspending are still running. Additional info: The last kernel version that works is kernel-4.14.8-300.fc27.i686 The first kernel version that has a problem is kernel-4.14.11-300.fc27.i686 I saw that Bug #1206936 is listed as a common problem, but I think this is a different bug for a few reasons. 1) That bug is old and my problem just started on a recent kernel update. 2) That bug refers to Hibernate and my problem involves Suspend, too. 3) The suggested work-around for that bug (adding a resume=[my swap] and rebuilding the grub configuration) didn't fix my problem. My machine is a Dell Inspiron 700m laptop. It uses BIOS. It only has pure Fedora packages installed, running FC27. I don't know how to trouble-shoot this further. I saw for related bugs that people request a journalctl dump. Here's a snippet that shows the problem. """ Jan 19 18:35:06 lappy systemd[1]: Reached target Sleep. Jan 19 18:35:06 lappy systemd[1]: Starting Suspend... Jan 19 18:35:07 lappy systemd-sleep[5538]: Suspending system... Jan 19 18:35:07 lappy kernel: PM: suspend entry (deep) -- Reboot -- Jan 20 00:01:15 lappy kernel: Linux version 4.14.13-300.fc27.i686 (mockbuild.fedoraproject.org) (gcc version 7. Jan 20 00:01:15 lappy kernel: Disabled fast string operations Jan 20 00:01:15 lappy kernel: x86/fpu: x87 FPU will use FXSAVE Jan 20 00:01:15 lappy kernel: e820: BIOS-provided physical RAM map: Jan 20 00:01:15 lappy kernel: BIOS-e820: [mem 0x0000000000000000-0x000000000009f7ff] usable Jan 20 00:01:15 lappy kernel: BIOS-e820: [mem 0x000000000009f800-0x000000000009ffff] reserved Jan 20 00:01:15 lappy kernel: BIOS-e820: [mem 0x00000000000dc000-0x00000000000fffff] reserved Jan 20 00:01:15 lappy kernel: BIOS-e820: [mem 0x0000000000100000-0x000000003eedffff] usable Jan 20 00:01:15 lappy kernel: BIOS-e820: [mem 0x000000003eee0000-0x000000003eeeafff] ACPI data Jan 20 00:01:15 lappy kernel: BIOS-e820: [mem 0x000000003eeeb000-0x000000003eefffff] ACPI NVS Jan 20 00:01:15 lappy kernel: BIOS-e820: [mem 0x000000003ef00000-0x000000003fffffff] reserved Jan 20 00:01:15 lappy kernel: BIOS-e820: [mem 0x00000000ff800000-0x00000000ffbfffff] reserved Jan 20 00:01:15 lappy kernel: BIOS-e820: [mem 0x00000000fffffc00-0x00000000ffffffff] reserved Jan 20 00:01:15 lappy kernel: Notice: NX (Execute Disable) protection missing in CPU! Jan 20 00:01:15 lappy kernel: random: fast init done Jan 20 00:01:15 lappy kernel: SMBIOS 2.3 present. Jan 20 00:01:15 lappy kernel: DMI: Dell Inc. Inspiron 700m /0D9593, BIOS A07 03/20/06 """ And here's another snippet, this time using the older kernel which can resume. """ Jan 20 08:57:03 lappy systemd[1]: Reached target Sleep. Jan 20 08:57:03 lappy systemd[1]: Starting Suspend... Jan 20 08:57:03 lappy systemd-sleep[965]: Suspending system... Jan 20 08:57:03 lappy kernel: PM: suspend entry (deep) Jan 20 08:57:03 lappy chronyd[545]: Source 108.61.56.35 offline Jan 20 08:57:03 lappy chronyd[545]: Source 45.76.244.193 offline Jan 20 08:57:03 lappy chronyd[545]: Source 66.79.167.34 offline Jan 20 08:57:03 lappy chronyd[545]: Source 138.236.128.112 offline Jan 20 08:57:03 lappy chronyd[545]: Can't synchronise: no selectable sources Jan 20 08:57:03 lappy nm-dispatcher[761]: req:6 'down' [wlp2s1]: start running ordered scripts... Jan 20 08:57:04 lappy kernel: PM: Syncing filesystems ... done. Jan 20 13:17:18 lappy kernel: Freezing user space processes ... (elapsed 0.001 seconds) done. Jan 20 13:17:18 lappy kernel: OOM killer disabled. Jan 20 13:17:18 lappy kernel: Freezing remaining freezable tasks ... (elapsed 0.000 seconds) done. Jan 20 13:17:18 lappy kernel: Suspending console(s) (use no_console_suspend to debug) Jan 20 13:17:18 lappy kernel: sd 0:0:0:0: [sda] Synchronizing SCSI cache Jan 20 13:17:18 lappy kernel: wlp2s1: Going into suspend... Jan 20 13:17:18 lappy kernel: sd 0:0:0:0: [sda] Stopping disk Jan 20 13:17:18 lappy kernel: PM: suspend devices took 1.081 seconds Jan 20 13:17:18 lappy kernel: ACPI: Preparing to enter system sleep state S3 Jan 20 13:17:18 lappy kernel: ACPI: EC: event blocked Jan 20 13:17:18 lappy kernel: ACPI: EC: EC stopped Jan 20 13:17:18 lappy kernel: PM: Saving platform NVS memory Jan 20 13:17:18 lappy kernel: Disabling non-boot CPUs ... Jan 20 13:17:18 lappy kernel: ACPI: Low-level resume complete Jan 20 13:17:18 lappy kernel: ACPI: EC: EC started Jan 20 13:17:18 lappy kernel: PM: Restoring platform NVS memory Jan 20 13:17:18 lappy kernel: ACPI: Waking up from system sleep state S3 Jan 20 13:17:18 lappy kernel: usb usb2: root hub lost power or was reset Jan 20 13:17:18 lappy kernel: usb usb3: root hub lost power or was reset Jan 20 13:17:18 lappy kernel: usb usb4: root hub lost power or was reset Jan 20 13:17:18 lappy kernel: wlp2s1: Coming out of suspend... Jan 20 13:17:18 lappy kernel: sd 0:0:0:0: [sda] Starting disk Jan 20 13:17:18 lappy kernel: ACPI: EC: event unblocked """ I don't claim to understand the output, but it looks like the system is intentionally rebooting. That is, there's no system crash, just a "-- Reboot --" after going into suspend mode.
I can reproduce the same problem on two old 32-bit laptops; an Asus EeePc 901 and a Lenovo ThinkPad Z61m. Reproduced with versions 4.14.11-300.fc27.i686 and 4.14.14-300.fc27.i686.
The problem persists in kernel-4.14.16-300.fc27.i686. I noticed that when I install the kernel updates, dnf reports an error: """ Running scriptlet: libwbclient-2:4.7.4-2.fc27.i686 239/239 Running scriptlet: kernel-core-4.14.14-300.fc27.i686 239/239 cat: write error: Broken pipe Running scriptlet: python3-3.6.4-3.fc27.i686 """ And again: """ Running scriptlet: kernel-core-4.14.16-300.fc27.i686 13/13 cat: write error: Broken pipe """ I looked in the logs and couldn't find any more details. It might be that the "Broken pipe" error is completely unrelated to my reboot-on-resume problem, but I mention it, just in case the problem is not with the kernel itself, but with how it's packaged for Fedora.
Same thing on my Aspire One (AOA150) with an Atom N270, running 4.14.13-300 (and patiently waiting to get upgraded to 4.14.17-300). Laura, do you need any additional information, or do you have a patch to test?
(In reply to Alexander Ploumistos from comment #3) > (and patiently waiting to get upgraded to 4.14.17-300). No change in 4.14.17-300.
Got the same message: """ Running scriptlet: kernel-core-4.14.16-300.fc27.i686 13/13 cat: write error: Broken pipe """ upon the upgrade from the kernel 4.14.13 to 4.14.16-300. Is "Broken pipe" expected during the update?
Apologies for the second post. Please, ignore my previous, and use this one instead. Got the same message : """ Running scriptlet: kernel-core-4.14.16-300.fc27.x86_64 13/13 cat: write error: Broken pipe """ upon the installation of the kernel-core required for "dnf upgrade" from the kernel 4.13.9-300 to 4.14.16-300. Is "Broken pipe" expected during the upgrade? Is there any better way to report such deficiency?
Please try the following: 1. Logout 2. Trigger a suspend after logged out This case (and only this) has seemed to work for me after a recent update. Suspending from my session causes some sort of hang instead. -------------- in messages: Mar 6 01:42:40 jm NetworkManager[901]: <info> [1520322160.6443] device (wlp3s0): state change: disconnected -> unmanaged (reason 'sleeping', internal state 'managed') Mar 6 01:42:40 jm NetworkManager[901]: <info> [1520322160.6827] device (wlp3s0): set-hw-addr: reset MAC address to xx:xx:xx:xx:xx:xx (unmanage) Mar 6 01:42:40 jm systemd[1]: Reached target Sleep. Mar 6 01:42:40 jm systemd[1]: Starting Suspend... ^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@Mar 6 01:42:41 jm chronyd[862]: Can't synchronise: no selectable sources Mar 6 01:42:41 jm nm-dispatcher[11636]: req:2 'down' [wlp3s0]: start running ordered scripts... Mar 6 02:18:59 jm kernel: microcode: microcode updated early to revision 0x4, date = 2013-06-28 Mar 6 02:18:59 jm kernel: Linux version 4.15.6-200.fc26.x86_64 (mockbuild.fedoraproject.org) (gcc version 7.3.1 20180130 (Red Hat 7.3.1-2) (GCC)) #1 SMP Mon Feb 26 18:51:32 UTC 2018
I can't reproduce this, I logged out, set the system to sleep and these are the last lines from my journal: Mar 06 21:16:25 systemd[1]: Reached target Sleep. Mar 06 21:16:25 systemd[1]: Starting Suspend... Mar 06 21:16:25 systemd[1]: Stopping Sendmail Mail Transport Client... Mar 06 21:16:25 kernel: PM: suspend entry (deep) Mar 06 21:16:25 systemd-sleep[26500]: Suspending system... Mar 06 21:16:25 systemd[1]: Stopped Sendmail Mail Transport Client. Mar 06 21:16:25 audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=sm-client comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' Mar 06 21:16:25 systemd[1]: Stopping Sendmail Mail Transport Agent... Mar 06 21:16:25 systemd[1]: Stopped Sendmail Mail Transport Agent. Mar 06 21:16:25 audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=sendmail comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' Mar 06 21:16:25 systemd[1]: Starting Sendmail Mail Transport Agent... Mar 06 21:16:25 sendmail[26529]: starting daemon (8.15.2): SMTP+queueing@01:00:00 Mar 06 21:16:25 systemd[1]: Started Sendmail Mail Transport Agent. Mar 06 21:16:25 audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=sendmail comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' Mar 06 21:16:25 systemd[1]: Starting Sendmail Mail Transport Client... Waking up the system just caused a reboot. Using kernel 4.15.7-300.fc27.i686.
I can not reproduce this problem on kernel-core-4.15.8-300.fc27.i686 or kernel-core-4.15.9-300.fc27.i686. As far as I'm concerned, the bug is fixed. I still saw the message of "cat: write error: Broken pipe" when installing kernel-core-4.15.9-300.fc27.i686, so it must not be related.
I've just tested kernel 4.15.14-300.fc27 and it seems that the problem is gone. I am closing the bug, if someone is still seeing this on recent fedora kernels, please reopen it.
Excuse my ignarance, but bugzilla is not my cup of tea. Just want to add that I think I hit a regression of this bug in my Fedora28 install. This week I updated to kernel-4.16.13-300.fc28.x86_64. When I resume my laptop by opening the lid, I can log in, but seconds after logging in, the laptop reboots. I have still kernel-4.16.12-300.fc28.x86_64 installed too, and when I boot into that kernel, the reboot does not occur.
> [Rob Bosch] Excuse my ignarance, but bugzilla is not my cup of tea. Bugzilla isn't my cup of tea, either. Actually, my cup of tea is a cup of coffee, which I'm having right now. I upgraded to kernel-4.16.13-200.fc27.i686 and was not able to reproduce the bug that I reported. Of course, our kernels aren't the same (I'm on FC27, not FC28 and my CPU is i686, not x86_64), so that's not to say that this bug has regressed, only that I cannot confirm that it has. Either way, since this bug is CLOSED, I don't think any developers will look at the problem you're having. I recommend that you open a new bug and provide the relevant part from journalctl and perhaps mention that this could be a duplicate of this bug, or mark this bug as OPEN. If you claim ignorant-newbie-who-is-just-trying-to-make-the-world-a-better-place, I don't see how any decent person could get angry.
I posted here because @Alexander Ploumistos wrote in his last post: "if someone is still seeing this on recent fedora kernels, please reopen it." I doubt I have the rights to re-open bugs, so I just informed here. As far as I'm concerned, I have done the things I can do. I'll leave it to the pro's to act or not act on it. regards, robb
I'll try to bring my (really slow) testing system up to speed -hopefully sometime today- and see if I can reproduce this.
(In reply to Rob Bosch from comment #11) > This week I updated to kernel-4.16.13-300.fc28.x86_64. Hello again, I just noticed that you are on x86_64 and considering that I can not reproduce this i686-specific bug with kernel 4.16.14-300 on 32-bit hardware, you have probably stumbled upon something different. Please file a new bug, mentioning the 64-bit architecture. I am closing this one.