# s2ram issue

## DMoL

Hello, 

I'm trying to use s2ram. After invoking all possible methods (i.e. all possible command line options), I got the optimal variant:

```
s2ram -f --radeontool

```

The last command places my notebook into sleep node (the LED is blinking), I can press "power" button, and it resumes correctly. It seems that everything is OK: no kernel crashes, I can launch programs etc.

The problem arises when I try to reboot or poweroff: after displaying BIOS Logo, the GRUB menu does not appears at all : the cursor is blinking an left upper corner, and the computer hangs.  The force poweroff helps neither. I have to eject the battery and turn off the power cable... When I plug it again and power on, than

everything goes as usual, e.g. the problematic behaviour happens only after s2ram.

Could you advice me something? Thank for any assistance.

My config:

```
# s2ram -i

This machine can be identified by:

    sys_vendor   = "TOSHIBA"

    sys_product  = "Satellite C660D"

    sys_version  = "PSC20E-00E010RU"

    bios_version = "1.40"

# uname -a

Linux chimaera 3.0.4 #1 SMP PREEMPT Sun Sep 4 16:00:17 EEST 2011 x86_64

AMD E-350 Processor AuthenticAMD GNU/Linux

# lspci| grep -i vga  

00:01.0 VGA compatible controller: ATI Technologies Inc Device 9802

```

-- it is ATI Radeon HD 6310M video card.

----------

## nativemad

Hi, 

that sounds weird!   :Laughing: 

Have you tried to reset to the bios defaults if it's in such a faulty condition?

Maybe a bios update could help!?

HTH, Cheers

----------

## DMoL

Yep! It helped... the "buggy" option in kernel is SATA mode : if it is set to compatility (ide), than the buggy behaviour occurs, if it is set to AHCI, than everything looks good.

Thank you!

The current problem is that my notebook after resuming hangs approx. 1 minute of work... obviously the problem is in kernel or in kernel modules... How to detect it, instead of manual enumeration-rmmoding by one-by-one?

----------

## Hu

Rebuild your kernel with PRINTK_TIME=y, then reproduce the problem.  Every kernel message will have a timestamp, so you can examine dmesg to find which subsystem was slow.  Since you say it takes about a minute, my guess is that you have a driver that is wrongly trying to load firmware while there is no userspace available to provide it.

----------

## DMoL

Thank you! I don't know why, but it seems that using hibernate-ram instead of s2ram solved all problems...

----------

## Hu

Running hibernate-ram will eventually run s2ram, but it can also do various other things that may help you avoid some issues.

----------

