My OperaToo much security - Preventing resume from suspend
Thursday, January 28, 2010 8:48:13 AM
So I have been working tirelessly the last few days; I have been tryng to get pm-utils to suspend on my laptop. Hibernation was working great from the start but trying to suspend was a nightmare.
Just to differentiate: Suspend is lowering the power usage of all hardware (except the RAM) and keeping everything loaded in RAM; When resuming from suspend, all the hardware is returned to it's normal power usage, and the system is back to the way you left it.
Hibernate is writing an image of the RAM to the disk (either a file or a swap partition on Linux) and then [usually] shutting the system down; When the computer is booted back up, the image is loaded from the disk to decrease the time it takes to get back to the desktop, and to present you with the exact environment you had when you put it into Hibernation.
I had tried everything, s2ram, pm-utils, tuxonice, kernel based suspend. Every possible way of suspending my E1705 that I could find.
I could get the system to go to sleep, but waking up was another story.
I would press the power button to wake it up, and a few short seconds later I would have my desktop back, exactly how I left it. One problem though, I had no access to my hard drive.
If you are at all familiar with how computers work, you know every program you use is read from the disk. Well, if you don't have access to the disk, you get weird things like "input/output error". A lot.
I had been searching for days and posting in the forums trying to see if anyone else had this issue. Finally, I came across the Fedora bug report that led me to reboot my system, and enter into the BIOS.
One person in the bug report had mentioned they fixed their issue by turning off the hard drive password that they had set in the BIOS.
Well, I did that and rebooted; I tried to suspend again. FAIL.
I thought to myself, "what else could be causing this?"
There were no errors in the logs, nothing to indicate any problems getting dumped to the terminal, seriously, NOTHING.
So I went back to the BIOS.
I looked around in there to see what passwords I had set...
Hm... Admin password... There I saw it "including resuimg from StandBy"
rwioaklkaw!!! Could I be that dumb?
I disabled that password as well, went throught the process of booting, and loading some apps, and then finally issuing out "sudo pm-suspend"
Went to sleep...
I got a cup of tea, let my dog outside, and came back to my computer (still sleeping), then hit the power button again. As per the usual, the screen came back, but I was used to this happening and still not being able to say it was fully resumed, so I didn't hold my breath.
I entered in a simple "ls" - and there it was, real output. Not some kernel driven error about input/output, no, a real, live listing of my directory.
I checked NetworkManager, it was connected; Firestarter was running as well.
And here I am writing this post.
The lesson here is that sometimes, you can be overly paranoid, and it can make things break.
I have read several posts from Windows/Linux/Mac users where with certain BIOS this issue will arise. It seems to happen more on Linux and Mac OS's running on PC's more than anything else, but it does happen on Windows too.
So if you have an issue resuming from suspend while running Linux, don't get heated, simply disable the passwords in BIOS. If you find it doesn't fix the issue, you can always go back and re-enable them.
As always my dear friends,
Happy Hacking :]
PiklesOnFire
Just to differentiate: Suspend is lowering the power usage of all hardware (except the RAM) and keeping everything loaded in RAM; When resuming from suspend, all the hardware is returned to it's normal power usage, and the system is back to the way you left it.
Hibernate is writing an image of the RAM to the disk (either a file or a swap partition on Linux) and then [usually] shutting the system down; When the computer is booted back up, the image is loaded from the disk to decrease the time it takes to get back to the desktop, and to present you with the exact environment you had when you put it into Hibernation.
I had tried everything, s2ram, pm-utils, tuxonice, kernel based suspend. Every possible way of suspending my E1705 that I could find.
I could get the system to go to sleep, but waking up was another story.
I would press the power button to wake it up, and a few short seconds later I would have my desktop back, exactly how I left it. One problem though, I had no access to my hard drive.
If you are at all familiar with how computers work, you know every program you use is read from the disk. Well, if you don't have access to the disk, you get weird things like "input/output error". A lot.
I had been searching for days and posting in the forums trying to see if anyone else had this issue. Finally, I came across the Fedora bug report that led me to reboot my system, and enter into the BIOS.
One person in the bug report had mentioned they fixed their issue by turning off the hard drive password that they had set in the BIOS.
Well, I did that and rebooted; I tried to suspend again. FAIL.
I thought to myself, "what else could be causing this?"
There were no errors in the logs, nothing to indicate any problems getting dumped to the terminal, seriously, NOTHING.
So I went back to the BIOS.
I looked around in there to see what passwords I had set...
Hm... Admin password... There I saw it "including resuimg from StandBy"
rwioaklkaw!!! Could I be that dumb?
I disabled that password as well, went throught the process of booting, and loading some apps, and then finally issuing out "sudo pm-suspend"
Went to sleep...
I got a cup of tea, let my dog outside, and came back to my computer (still sleeping), then hit the power button again. As per the usual, the screen came back, but I was used to this happening and still not being able to say it was fully resumed, so I didn't hold my breath.
I entered in a simple "ls" - and there it was, real output. Not some kernel driven error about input/output, no, a real, live listing of my directory.
I checked NetworkManager, it was connected; Firestarter was running as well.
And here I am writing this post.
The lesson here is that sometimes, you can be overly paranoid, and it can make things break.
I have read several posts from Windows/Linux/Mac users where with certain BIOS this issue will arise. It seems to happen more on Linux and Mac OS's running on PC's more than anything else, but it does happen on Windows too.
So if you have an issue resuming from suspend while running Linux, don't get heated, simply disable the passwords in BIOS. If you find it doesn't fix the issue, you can always go back and re-enable them.
As always my dear friends,
Happy Hacking :]
PiklesOnFire
