I have just applied the latest updates to eeebuntu NBR 3.0.1 which includes an upgrade to eeepc-acpi-utilities from 1.0.46 to 1.0.48. At 1.0.46 all was okay. However at 1.0.48 I cannot resume from suspend when on battery. I sometimes get the login screen and sometimes I get a blank screen; in all cases the keyboard and mouse are locked. The only way I can recover the machine is to hold down the power button to force a shut down. This can result in a corrupt file system which requires fixing using fsck.

I have reloaded the system and upgraded all files except eeepc-acpi-utilities and everything appears okay. When I upgrade eeepc-acpi-utilities the fault returns.

I have an eee PC 900 and the eeepc-acpi-utilities is at the default configuration

Any ideas?

Would you mind shooting me a CPU debug? It may be that it's not setting your clock properly before suspending.

Right click the tray, select Help, then click the debug link.

Thanks for the quick response. I have emailed the results from the debug tests.

Try this:

sudo -s
chmod -x /etc/acpi/eeepc/eeepc-cpu-control.sh

suspend
unsuspend

let me know if it still crashes.

To restore the original setting:

sudo -s
chmod +x /etc/acpi/eeepc/eeepc-cpu-control.sh

Hi. I have tried your suggestion. After doing chmod -x when I press suspend the machine just goes to the login screen - it doesn't go into suspend. However it doesn't crash and I can log in again.

Once I use chmod +x to restore back to normal the fault returns.

Unfortunately it's not a valid test since it didn't suspend. It probably got stuck trying to reset the CPU and failed the suspend command when it couldn't. Try:

sudo -s
chmod -x /etc/pm/sleep.d/00-eeepc-cpu
chmod -x /etc/acpi/eeepc-cpu-toggle.sh

then try suspending / unsuspending.

to change back:
sudo -s
chmod +x /etc/pm/sleep.d/00-eeepc-cpu
chmod +x /etc/acpi/eeepc-cpu-toggle.sh

Hi, I couldn't find /etc/acpi/eeepc-cpu-toggle.sh so I have assumed that may have been an error (if not I may have a file missing). Anyway, I assumed you may have meant me to apply the previous command together with the new one and so I applied the following:

sudo -s
chmod -x /etc/pm/sleep.d/00-eeepc-cpu
chmod -x /etc/acpi/eeepc/eeepc-cpu-control.sh

After entering the above I was able to suspend and unsuspend with no problems.

If what I have done is invalid, please let me know.

Fewt always gets those directories mixed up. He meant to say /etc/acpi/eeepc/eeepc-cpu-control.sh
So you did what he said.

I don't know why I do that

Can you tell me what mode you are in before suspending? (Reduced, Super, Powersave)

Also, try putting this in /etc/default/eeepc-acpi.local:

FSB_SCALE="10"

I have tried it in both Super High Performance and Reduced Performance whilst on battery and it still fails. However it is okay if powered from the mains.

I have also put FSB_SCALE="10" into /etc/default/eeepc-acpi.local (should the 10 be in quotes?). This didn't make any difference.

I noticed from another thread that someone had a similar problem to mine with suspend when on battery. It was suggested that they set DONOT_SCALE_FSB="1" which overcame their problem.

Suspend also works on my 900, both on mains and battery, if I set this parameter.

fewt,

I'm experiencing this same thing (using your new testing debs). I never tried suspending before... so I'm not sure that it has to do with the testing debs or not. However, I also cannot switch to another tty (say via CTL+ALT+F2) and then back to the X11 desktop.

I tried removing the executable permissions on the two scripts referenced above and I tried uncommenting the DONOT_SCALE_FSB and the FSB_SCALE parameters in eeepc-acpi.local. Nothing worked. It also did not matter if my machine was plugged in or not.

In testing, I've had to do an ungraceful poweroff numerous times and fsck found some errors (and luckily corrected them). Is there anything I can do to troubleshoot safely? A CPU debug is on its way (the missing /proc/netbook/ is an error when running it).

siege

PS: TRiPgod, your setup is a lot like mine. Do you have any trouble resuming from suspend or switching to a tty[1-6] and then switching back?

Upgrading to the 2.6.30 generic kernel fixed this for me.

Though we talked in email,
suspend works the way it should, and I can switch between the tty's just fine.