Suspend to ram issues with OpenSUSE 11.3 on HP dv6z

English Hardware
#1

I’m running 11.3 swapless on a HP dv6z (AMD Turion dual-core processor, 3GB RAM, ATI Radeon HD 3200 graphics), customized by replacing the original hard drive with an Intel 40 GB X25-V SSD.

About 2 out of 3 times the suspend to RAM and resume work fine, taking a couple of seconds to suspend and resuming almost instantaneously. The other times, suspend seems to hang for about 30 seconds or so with the monitor displaying a console login (same as I see briefly when a suspend works). The display eventually shuts off, and the light is blinking on/off as in a normal suspend, but when I resume I’m unable to login. The message I get when I try to login is “Cannot unlock the session because the authentication system failed to work, you must kill kscreenlocker (pid 12,139) manually”; if I go to a console screen and try to login as root to do the kill I get “end-request: I/O error, dev sda sector …” repeated many times, and cannot login that way, either.

pm-suspend.log shows the hang-up occurring at the same point each time, after all the sleep.d operations. Here’s a sample:

/usr/lib/pm-utils/sleep.d/00powersave suspend suspend:success.
/usr/lib/pm-utils/sleep.d/02rtcwake suspend suspend:rtcwake alarm not enabled in /etc/pm/config.d/rtcwake.config, doing nothing…
not applicable.
/usr/lib/pm-utils/sleep.d/06autofs suspend suspend:Shutting down automount …done
success.
/usr/lib/pm-utils/sleep.d/30s2disk-check suspend suspend:success.
/usr/lib/pm-utils/sleep.d/45pcmcia suspend suspend:ejecting PCMCIA cards…
success.
/usr/lib/pm-utils/sleep.d/49bluetooth suspend suspend:not applicable.
/usr/lib/pm-utils/sleep.d/50rcnetwork suspend suspend:not applicable.
/usr/lib/pm-utils/sleep.d/55NetworkManager suspend suspend:not applicable.
/usr/lib/pm-utils/sleep.d/75modules suspend suspend:success.
/usr/lib/pm-utils/sleep.d/80acpi-fan suspend suspend:not applicable.
/usr/lib/pm-utils/sleep.d/80videobios suspend suspend:not applicable.
/usr/lib/pm-utils/sleep.d/90clock suspend suspend:not applicable.
/usr/lib/pm-utils/sleep.d/94cpufreq suspend suspend:success.
/usr/lib/pm-utils/sleep.d/95led suspend suspend:not applicable.
/usr/lib/pm-utils/sleep.d/95packagekit suspend suspend:success.
/usr/lib/pm-utils/sleep.d/98video-quirk-db-handler suspend suspend:success.
/usr/lib/pm-utils/sleep.d/99Zgrub suspend suspend:success.
/usr/lib/pm-utils/sleep.d/99info suspend suspend:not applicable.
/usr/lib/pm-utils/sleep.d/99video suspend suspend:disabled.
Fri Jul 23 09:39:54 NZST 2010: performing suspend
INFO: using built-in quirks database from HAL.
INFO: S2RAM_OPTS from HAL quirks: ’ '.

If I try to resume after this nothing more is added to the log. On a resume from a successful suspend, the log continues on:

switching from vt7 to vt1… succeeded
fbcon fb0 state 1
fbcon fb0 state 0
switching back to vt7… succeeded
Thu Jul 22 12:55:12 NZST 2010: Awake.
Thu Jul 22 12:55:12 NZST 2010: Running hooks for resume
…

Any ideas?

#2

On 2010-07-24 01:06 GMT dsosnoski wrote:

…
> you must kill kscreenlocker (pid 12,139) manually"; if I go to a
> console screen and try to login as root to do the kill I get
> “end-request: I/O error, dev sda sector …” repeated many times, and
> cannot login that way, either.

Run the SMART tests on that sda ASAP, meaning this minute.

–
Cheers / Saludos,

Carlos E. R.
(from 11.2 x86_64 “Emerald” GM (Elessar))

#3

I don’t believe the problem has anything to do with the SSD at all - the problem starts with the suspend part not working properly, and the errors on resume are just an indication that the system has not been properly restarted.

I haven’t had the problem occur over the last 8 suspends or so, so against my better judgement I’m hoping it’s a quirk that somehow self-corrected.

#4

On 2010-07-28 08:06, dsosnoski wrote:
>
> I don’t believe the problem has anything to do with the SSD at all - the
> problem starts with the suspend part not working properly, and the
> errors on resume are just an indication that the system has not been
> properly restarted.

I did not know it is a solid state disk. However, you are having disk errors, it shows in the
message you posted, and could cause the symptoms you saw.

> I haven’t had the problem occur over the last 8 suspends or so, so
> against my better judgement I’m hoping it’s a quirk that somehow
> self-corrected.

I don’t know how SSD are affected, but normal disks try to remap damaged sectors, so that the error
apparently disappears. But the damage remains.

–
Cheers / Saludos,

Carlos E. R.
(from 11.2 x86_64 “Emerald” GM (Elessar))

#5

The problem occurred again the next time I suspended after posting my last message. AFAIKS the disk error on resume is a symptom of the suspend problem, not the cause - the only time I see any disk problems is after the messed-up suspend.

#6

On 2010-07-30 08:06, dsosnoski wrote:
>
> The problem occurred again the next time I suspended after posting my
> last message. AFAIKS the disk error on resume is a symptom of the
> suspend problem, not the cause - the only time I see any disk problems
> is after the messed-up suspend.

Which may be because only at that time are certain files read. Do check the disk; if it uses flash
technology, the number of write operations are limited. After that, failure, cancel that sector.
After enough of that, replace disk.

–
Cheers / Saludos,

Carlos E. R.
(from 11.2 x86_64 “Emerald” GM (Elessar))