Description of problem: If you suspend a system using a 32-bit desktop kernel from the 4.14 series, as when closing the lid on a laptop, it will not resume, but restarts. This was first reported with the 4.14.10 i586 desktop kernel, and has continued with all 4.14 series test kernels since, including the current 4.14.16-1 kernel. The i586 server kernel is not affected; nor are any of the x86-64 kernels. I am seeing this behavior on an HP Probook 6550b laptop (i3 processor, 8GB RAM, integrated Intel graphics, Intel wifi), but others have reported seeing it on different hardware. How reproducible: Always Steps to Reproduce: 1.Create an i586 system with a desktop kernel 2.Suspend the system, as in closing the lid on a laptop 3.Attempt to resume the system, as in opening the lid on a laptop
My Probook has both kernels installed on the same i586 install. I just did a test where I booted into the 4.14.16-1 desktop kernel, closed the lid to suspend it, then attempted to resume by opening the lid again. (On this laptop, you also have to press the power button to actually begin the resume.) The laptop restarted, instead of resuming, and I booted into the server kernel. Then I copied the contents of /var/log/dmesg.old (from the desktop session that failed to resume) and /var/log/dmesg (from the server session) to a flash drive. I then put the journal from the session that failed to resume into a file I named deskjour.txt. Next, I suspended by closing the lid, and resumed, successfully, and collected the contents of that session's journal into a file I named servjour.txt. I will be attaching copies of all those files here. I forgot to mention in the original report - When I boot into the desktop kernel I see a highly unusual amount of verbiage on the screen, verbiage that passes by too fast to read most of it. I do not see this when booting into the server kernel.
Created attachment 9946 [details] contents of /var/log/dmesg from the desktop kernel session
Created attachment 9947 [details] contents of /var/log/dmesg from the server kernel session
Created attachment 9948 [details] journal from the desktop session that failed to resume
Created attachment 9949 [details] journal from the server session that resumed successfully.
this soun like the bug i report https://bugs.mageia.org/show_bug.cgi?id=22356
CC: (none) => j.alberto.vc
(In reply to katnatek from comment #6) > this soun like the bug i report https://bugs.mageia.org/show_bug.cgi?id=22356 I believe you are right. It certainly sounds like the same one. I searched before reporting mine, but didn't use the search term I needed to find it. Marja, when you see this, I believe one of these needs to be marked as a duplicate, but I don't know which would be better. Please advise as to where we should go from here.
i think this have a better title and have better explanation of issue. i don't matter to follow this bug from now.
Created attachment 9952 [details] output of lspcidrake -v
Does it happend with the desktop586 kernel too ?
CC: (none) => tmb
And is this a Plasma issue only? I have not seen it with Mate.
CC: (none) => tarazed25
(In reply to Thomas Backlund from comment #10) > Does it happend with the desktop586 kernel too ? I you ask to me, the answer is yes I try with the server flavor and don't have the issue
(In reply to Len Lawrence from comment #11) > And is this a Plasma issue only? I have not seen it with Mate. I can't be sure but i only have plasma/sddm in the laptop, also Thomas points that don't is present on x86_64 desktop kernel
(In reply to Thomas Backlund from comment #10) > Does it happend with the desktop586 kernel too ? sorry i don't understand the question the first time i make the test with deskop586 and the issue is present
(In reply to Len Lawrence from comment #11) > And is this a Plasma issue only? I have not seen it with Mate. I will see if I can check that out, but it may take a while. I have only the one laptop, and it has but two installs on it - one 64-bit Plasma that I use for production and a bit of testing, and the 32-bit Plasma install used almost exclusively for testing. At present I have but one more 32-bit Mageia 6 install, Xfce on very different hardware - an AMD/Nvidia340-based desktop. That install has always had just the server kernel on it, installed by the Classical iso. I can try installing the desktop kernel and see if I can figure out how to make it suspend. (All of my desktops are configured to stay awake.) But that brings up another thought: Could it be an Intel issue? Something to do with the latest microcodes, perhaps? I don't recall anybody with AMD-based hardware mentioning being affected. Len, is your hardware AMD or Intel?
(In reply to Len Lawrence from comment #11) > And is this a Plasma issue only? I have not seen it with Mate. I finally got the chance to check it out on my existing 32-bit Xfce system, and I'm not seeing it there. But, that system is AMD/nvidia340. Next step is to install Mageia 6 Xfce on an unused partition of my Intel-based production machine, and see what happens there. Again, that'll take a while...
@tj, comment 15; everything here is Intel.
(In reply to Len Lawrence from comment #17) > @tj, comment 15; everything here is Intel. Interesting. After installing Xfce on this Intel-based machine from the 32-bit Classical iso, and getting updates, the server kernel would suspend and resume as it should. But after installing and booting into the desktop kernel, it restarts instead of resuming. So, it's not a Plasma thing, and apparently not an Intel thing. But, I still think it acts like a hardware-dependent thing. Curiouser and curiouser.
Created attachment 9961 [details] Output of lspcidrake for the AMD-based machine that resumes properly
Created attachment 9962 [details] output of lspcidrake for the 2nd Intel machine that doesn't resume
(In reply to Thomas Andrews from comment #18) > Interesting. After installing Xfce on this Intel-based machine from the > 32-bit Classical iso, and getting updates, the server kernel would suspend > and resume as it should. But after installing and booting into the desktop > kernel, it restarts instead of resuming. > > So, it's not a Plasma thing, and apparently not an Intel thing. But, I still > think it acts like a hardware-dependent thing. > > Curiouser and curiouser. Just to discard other thing, what dm use in the xfce installation? I think maybe is a combination of hardware+sddm
Both of the Xfce installs, the one that works and the one that doesn't, are using the LightDM, as installed by the Classical iso.
Assignee: bugsquad => kernelCC: (none) => marja11
(In reply to Thomas Andrews from comment #22) > Both of the Xfce installs, the one that works and the one that doesn't, are > using the LightDM, as installed by the Classical iso. Another issue related, with the kernel-server in the Plasma/SDDM laptop i lost the cursor after suspend/resume I have to kill the graphic session with Ctrl+Alt*Backspace
I haven't seen that one yet, even after ten or twelve tries just a few minutes ago. With my laptop, the cursor shows first.
Still valid for the 4.14.18 kernels.
*** Bug 22356 has been marked as a duplicate of this bug. ***
Still valid with the 4.14.20 kernels. No changes, including after updating various firmware packages.
Hi QA team Some one said in the 4.14.25 update request that the suspend option is working again Can test for this again using that kernel to close this issue?? Thanks
CC: (none) => neoser10
I was just coming here to do that. The issue has been resolved for me on two different sets of hardware, and another user confirmed it in the 4.14.25 update request. That's good enough for me. Marking this as resolved, as of kernel 4.14.25. Of course, should it re-appear with a later kernel, it can be re-opened.
Status: NEW => RESOLVEDResolution: (none) => FIXED