LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Slackware (https://www.linuxquestions.org/questions/slackware-14/)
-   -   TTY freeze after hibernation (4.4.x kernel) (https://www.linuxquestions.org/questions/slackware-14/tty-freeze-after-hibernation-4-4-x-kernel-4175577598/)

dr.s 04-16-2016 11:28 AM

TTY freeze after hibernation (4.4.x kernel)
 
1 Attachment(s)
Machine is running Slackware64 with the latest updates but the problem started occurring intermittently ever since moving to 4.4.x (4.1.x had no issues).

Suspend to disk (hibernate) seems to work well, but upon resume all the TTY's are frozen, only the X session (using KDE here) is back up. Logging out of X or trying to change TTY's (via ctrl-alt-F1 through F6) leads to a frozen TTY showing the resume lines. Keyboard remains active and responds to crtl-alt-del etc.

Suspend to RAM works well on the other hand and has no issues.

bl0tt0 04-16-2016 04:44 PM

I can confirm at least a similar issue on my thinkpad T430. In my case, it doesn't appear to be directly related to suspend/resume, but something with the change in how the control of the screen gets handed off between the X server and kernel when switching between TTYs. The only other thing I have noticed is that the issue first arose when I switched this system from booting from Legacy BIOS to UEFI.

I haven't yet found a workable solution, as there are multiple posts on other forums suggesting turning off the gfxterm in grub, checking checking power-saving options in WMs, etc.

Sorry I don't have a fix, but I did want to confirm that you aren't the only one running into this on the 4.4 kernel. The 4.3 kernel works as expected, however.

***Edit***

Interestingly enough, the issue doesn't appear to occur on a 4.5 kernel built from the same config, so it appears to be a bug specific to the 4.4 branch.

dr.s 04-19-2016 10:06 PM

Thanks for your tips. Haven't tried the 4.5.x kernel but interestingly the TTY freeze stopped occurring as of the Apr. 18 updates to Slackware-current, I could not reproduce it at all so far so I'll mark this thread as solved (for now).

By the way the laptop that was affected has UEFI boot, my other older machine uses BIOS boot and never had that problem in the first place.

dr.s 04-24-2016 10:23 AM

Marking as unsolved, problem re-occurred today, not sure if due to the Apr. 19th or Apr. 24th updates. Also hard to tell if it had been solved in the first place after the Apr. 18th updates, although it stopped occurring during those few days in between.

bl0tt0 04-25-2016 05:42 PM

Seriously, try the 4.5 series of kernel. That's been the only way that I've managed to get TTY switching working as expected with post 4.3 kernels. you can just copy the config from /proc/config.gz and follow through with the defaults on make oldconfig, and it seems to work fine. I dunno what got screwed up in the 4.4 series, but I'm a little surprised that more people haven't seen this issue.

***Correction***
originally posted most recent kernels. This problem seems unique to 4.4, as both 4.3 and 4.5 run as expected.

dr.s 05-10-2016 05:38 PM

Quote:

Originally Posted by bl0tt0 (Post 5536464)
Seriously, try the 4.5 series of kernel. That's been the only way that I've managed to get TTY switching working as expected with post 4.3 kernels. you can just copy the config from /proc/config.gz and follow through with the defaults on make oldconfig, and it seems to work fine. I dunno what got screwed up in the 4.4 series, but I'm a little surprised that more people haven't seen this issue.

***Correction***
originally posted most recent kernels. This problem seems unique to 4.4, as both 4.3 and 4.5 run as expected.

Agreed the 4.4.x hasn't been good on my laptop, 4.5.3 has so far been running without this issue.

dr.s 07-01-2016 04:42 PM

Marking as solved, no issues with 4.1.x, 4.5.x and 4.6.x kernels.


All times are GMT -5. The time now is 03:05 AM.