Asus K52F - suspend/hibernate broken

I have an Asus K52F latop running SL6.1, and the suspend/hibernate feature just permanently crashes the machine - a static Scientific Linux splash logo on a black background and nothing else until I force power off.

This seems to be a known problem with other distros (mostly Ubuntu), and I've found no shortage of information online (e.g. here), but it all seems to refer to editing internal system files - sometimes quite extensively - which, as a total newbie, isn't something I want to risk in case I brick the machine! I'm also unsure how much of it can be validly applied to SL - stuff like this (solution 4) is all just so much gobbledegook to me, and it's very possible it only works on Ubuntu.

Can anyone help? If nobody's actually used the laptop personally, can anyone more knowledgeable than I sift through the advice and determine which of it can be applied to all distros (e.g. the EHCI fix), so I can safely blindly add bits until something fixes it?

The closest I can find on this forum is this post, which I've tried on the assumption it was unlikely to do any harm, but it hasn't done any good either.

Hi,
have a look on the redhat bugzilla, there are similar cases with asus laptops and solutions.

here:
rh bugzilla no. 694191

they suggest to create file (executable and owned by root):
"/etc/pm/sleep.d/20_custom-ehci_hcd" and put in it following lines:

and here another one with similar solution:
rh bugzilla no 697150

they also suggest to create file :
/etc/pm/sleep.d/10ehci_hcd.hook.sh (owned by root and executable)

Try both scripts and see if it helps.

cheers,

Hi,
any progress here?

Well, the main reason I was originally reluctant to try exactly these solutions was that I was unsure in the extreme exactly to what extent RedHat and SL are compatible! I mean, I know they're pretty similar, but for all I know there's one tiny incompatibility hiding under the bonnet somewhere which might cause the script to fail catastrophically. On the other hand, I could be being unjustifiably paranoid and/or misunderstanding the specific bits of distros which tend to differ (both of which are extremely likely), and these scripts are just as compatible with any Unix-based system.

Since you know more than I do and you don't seem to see any problems, I'll give it a go. If I don't report back, you'll know it didn't work...

Well, the main reason I was originally reluctant to try exactly these solutions was that I was unsure in the extreme exactly to what extent RedHat and SL are compatible! I mean, I know they're pretty similar, but for all I know there's one tiny incompatibility hiding under the bonnet somewhere which might cause the script to fail catastrophically. On the other hand, I could be being unjustifiably paranoid and/or misunderstanding the specific bits of distros which tend to differ (both of which are extremely likely), and these scripts are just as compatible with any Unix-based system.

Since you know more than I do and you don't seem to see any problems, I'll give it a go. If I don't report back, you'll know it didn't work...

Hi,
try one script at a time and we will see. Dont worry, it's not gonna break up you HW and should not break up the system either. This is like 9x% though. If you go 'behind desktop' and start hacking the system, it sometimes have consequences, but its in majority cases repairable.
As for compatibility with TUV, i wouldn't be worried about it.

cheers,

SUCCESS!!

I put in both scripts. Presumably one of them was irrelevant, but frankly I don't want to try removing them now in case I pick the wrong one, and it's not doing any harm, right?

Thanks so much for that - I can use my laptop on the Tube now without having to worry about setting the interminable shutdown procedure in motion one stop before I have to change trains!

Hi,
if it works, it works, it would just be nice to know which one is the 'good' one ... maybe both?
Anyway, good it worked for you.

cheers,