having been a longtime slack user, i couldn't wait to give 13.1 a spin, but there are problems.

laptop 1 is an acer aspire 5570. closing and opening the lid works a few times, after editing acpi_handler.sh, and battery life reporting is ok during this time. then, for no apparent reason, the laptop no longer responds to the lid closing, and no longer seems to be able to read the battery charge state. once this has occurred, the computer will also no longer restart, it tries a few times, with lights flashing and the hd making ugly noises. the only way to extricate the computer from this state is to pull and reinsert the battery. very bad.

laptop 2 is a gateway nv18. suspend/resume with the lid are ok, mostly. the issure here is no display at all in x. but the computer does respond to ctrl-alt-backspace to kill x, with the command prompt returning. still not good.

any suggestions? i'm trying a fresh install on the gateway, to see if this was just an installation glitch.

btw, both laptops performed flawlessly in 13, regarding those issues.

an update, after more testing and a fresh install of slack 13.1

pm-suspend and resuming works correctly from the command line, on the gateway. i suspect that something in xfce-power-manager is at the root of this, that its also doing something when it detects the lid being closed.

Same problem here with a Lenovo S10. Judging from my experiences with Ubuntu, Debian, and ArchLinux, this problem is related to the 2.6.33 Linux kernel.

Some useful information would be the output of "groups" command, and also a "cat /var/log/pm-suspend" output. Any dmesg output would also help, maybe.

Since the S10 is my productive system, I rather prefer not to do to much hard power offs. With Arch, there was a problem with KMS (Intel Video), with Ubuntu just a mess (cf. https://bugs.launchpad.net/ubuntu/+s...ux/+bug/568711). With Debian Lenny, everything worked like a charm, but I was in the mood to change to Slackware.

The same problem occurs as root. So there should be no group problem I think. The log-files (pm-suspend, dmesg) were unfortunately not of much use up now (cf. Ubuntu).

Ever since kernel 2.6.29 with Slackware, everything works perfectly in here - suspend and hibernate shows no problem at all. The very first time (and only) I had a problem with suspend was by not having my user on 'power' group. This was noted because root could do a pm-suspend, while user can't.

Thanks for insisting. Pm-hibernate and pm-suspend work fine in console-mode as well as x-windows (at least now, after configuring the swap-partition in lilo). I will investigate further to see why resume from suspend didn't work before.

The last two resume from suspend-to-ram did not work . The computer was plugged and the suspend time was once approx. four, once half an hour. Dmesg.txt and pm-suspend.log are attached. Any further help will be highly appreciated.

Attached Files

	dmesg.txt (30.1 KB, 9 views)
	pm-suspend.log (4.1 KB, 14 views)

Strange, pm-suspend.log said that everything is ok, while dmesg didn't say if anything is wrong. But isn't this dmesg part of your system init? I mean, it's not the part of it that shows something about suspend, is it?

rfernandez: you're right, the dmesg.txt shows the init part because the problem occures not during suspend but during resume. As you can see from the attached pm-suspend.log, if anything works well, there is also an "awake" part after the system went to sleep. You can ignore the --quirk-none part, I was just testing, but apparently it is possible for the system to resume even with --quirk-none.

The difference between a failure and a success seems to be whether I did ask my system to hibernate before the suspend or not . My system behaves different whether it resumed from the swap-partition or did a fresh start. Unfortunately, threads that mention the same behavior did not provide me with further help. What I will try next is change the huge to the generic kernel, as I still run the kernel from the installation. Booting with the nomodeset kernel parameter did not help, too .

Attached Files

pm-suspend-success-20100708.log (4.9 KB, 12 views)