Got a weird one. Took me a while to even recognize the problem!

My laptop is older by some standards, because it dates back to 2013.

In November I performed a fresh install of Slackware. 64-bit Current. All but a small /boot partition on a LUKS-encrypted LVM. I used Alien Bob's multilib. To make life easier, I tried to see how things would work if I left pulseaudio in and did not (as in the past) go to a pure alsa system.

Aside from an increased chance of stuttering on playback of audio, all seemed well.

Around that time, something odd happened to my laptop. I had been away from the keyboard for a while and the screen was turned of. Normal. As it should be, not a problem.

I pressed a key to get the screen to wake, like I always have. The keyboard lit up (laptop, so has LEDs in the keys) and the screen remained turned off. Then, after a delay of ... five to ten seconds? ... The bios boot logo appeared: the computer had rebooted.

At the time I said "crap, need to get a new laptop. Can't do it now. Arrg."

Over time, a pattern emerged: some of the time, not all of the time, hitting a key to "wake" the screen would cause the reboot. I eventually switched to waving the mouse (USB, plugged into the laptop) to wake the screen. That works without the reboot problem, every time.

In March, I did a fresh install. The only major difference from the November was that the HD had failed and thus had been replaced, and I was using a thin provisioned LVM.

Hitting a key to turn the screen back on after being away from the keyboard still sometimes caused the problem. No changes there.

A new problem, which I feel may be connected, has been added. If I close the lid to sleep the machine and then open the lid again, the computer reboots itself. Every time. Not random.

Now, is this the firmware, the kernel, the hardware or something else completely? I don't know.

So, has anyone, in recent times, had this sort of problem? Does anyone have any ideas as to how to even ascertain anything about the problem?

Thank you.

First, snap on the 2013 laptop.

I agree, pulseaudio sucks, but so much stuff uses it, you kinda need it. I would updat6e first.

Current of last november(2019) is a flavour of the month. What I do is download the iso. If you want to update a current, you can simply loop mount the iso, cd to the slackware64 directory, and run That doesn't update what you haven't installed, but it does break multilib, which you need to upgrade at the same time. Then keep them both backed up.

There's acpi, and window managers often want to manage that too. stop each in turn to see what it is. I have my wm power manager set to "Go and play in the traffic!"

From my early days with acpi (There was an APM vs. ACPI war then) it became clear many laptops had dodgy Bios: thinkpads; sony viao; no-name objects, etc. Sometimes conflicting kernel fixes are now kernel options, rarely chosen by distros, because what fixes one laptop often breaks another. What's your box?

Huh? The 90's techno band Snap or the binary package scheme that some other distros use?

As noted before, I did another install in March. Current doesn't have an ISO so one has to use AlienBob's utilities to make one's own. Fortunately, for me, that process has become routine.

Again, not sure this is the kernel, firmware, packages, or what.

p.s. One additional data point: because my my partition scheme, both March and November installs are present and I can boot to the older one (november) for whatever. I did this and verified that the lid closing problem does not happen in the november slackware.

None of the above. I have a vintage 2013 laptop too. Sorry for confusion.

Current does isos.http://bear.alienbase.nl/mirrors/sla...4-current-iso/

If your acpi works in last November's install, surely you have the answer on your own box. You would also want to check acpi settings and window managers are identical. I find window managers having their own settings. Currently, IIRC, I have acpi set to work, and the WM set to go and play in the traffic.

I perfomed a fresh install of Slackware 64 current in August.

• Lid close and open will still make it crash ... sometimes.
• Hitting a key to "wake" the display after it's timed out and switched off seems to work now. Whew! That's an improvement.

The nature & timing of the improvement increases the likelihood that it is a firmware and/or kernel bug, not a hardware problem ... I think.

Just reading your post without remembering the thread : enough swap space ?

Sorry if I'm only noisy…

I have a machine that displayed similar behaviour.

I investigated by having a line in /etc/acpi/acpi_handler.sh
As a result, I now have in /etc/acpi/acpi_handler.sh