Bug 157977

Created attachment 72809 [details]
Excerpt from /var/log/messages while suspending and resuming

Created attachment 72810 [details]
The complete /etc/sysconfig/powersave/ content.

Created attachment 72811 [details]
The last /home/taki/bugzilla/suspend2ram.log file

Created attachment 72812 [details]
The last /home/taki/bugzilla/suspend2ram.log file

Ok, I think I see it. At the time 16:15:52, restore_after_suspend_to_ram is executed. But this script never returns. Can you please check with ps aux if this script is still active at the point where lidclose is ignored?

But there popps up another question, the event RESUME_AFTER_SUSPEND2RAM should time out after about 2 Minutes and a line like similar to that should appear in /var/log/messages:

  Timeout for event RESUME_AFTER_SUSPEND_TO_RAM with id %d reached, removing it

Just to make sure and if this line does not appear, please set SUSPEND2RAM_RESTORE_CLOCK="yes" in /etc/sysconfig/powersave/sleep .

But even if the event would time out, ignore_buttons would not be set to false. That's actually a bug but not really related to your problem. Will fix that.

(In reply to comment #5)
> Ok, I think I see it. At the time 16:15:52, restore_after_suspend_to_ram is
> executed. But this script never returns. Can you please check with ps aux if
> this script is still active at the point where lidclose is ignored?

Heck, I should have think of that myself... This is the case and I recall having seen the still running restore_after_suspend_to_ram script in the past. After opening the lid and resuming I get the attached output when running ps aux.

Could it be timidity that causes the issues? (I did not modify the audio configuration after YaST recognised it while installing the OS).


> 
> But there popps up another question, the event RESUME_AFTER_SUSPEND2RAM should
> time out after about 2 Minutes and a line like similar to that should appear in
> /var/log/messages:
> 
>   Timeout for event RESUME_AFTER_SUSPEND_TO_RAM with id %d reached, removing it

I get this line:

[powersave]: WARNING (checkEventTimeouts:1313) Timeout for event global.resume.suspend2ram with id 11 reached, removing it.

> 
> Just to make sure and if this line does not appear, please set
> SUSPEND2RAM_RESTORE_CLOCK="yes" in /etc/sysconfig/powersave/sleep .
> 
> But even if the event would time out, ignore_buttons would not be set to false.
> That's actually a bug but not really related to your problem. Will fix that.
> 

I did not change the value of SUSPEND2RAM_RESTORE_CLOCK because the line appears. If you still need this please instruct me what logs you need...

Thanks for helping,

Taki

Created attachment 73000 [details]
Comment #5: Output of ps aux

> Could it be timidity that causes the issues? (I did not modify the audio
> configuration after YaST recognised it while installing the OS).

Timidity seems to be involved. Can you please set the following value in /etc/sysconfig/powersave/sleep and retest:
  SUSPEND2RAM_RESTART_SERVICES="alsasound"

> I get this line:

> [powersave]: WARNING (checkEventTimeouts:1313) Timeout for event
> global.resume.suspend2ram with id 11 reached, removing it.

Ok, this part seems fine.

> I did not change the value of SUSPEND2RAM_RESTORE_CLOCK because the line
> appears. If you still need this please instruct me what logs you need...

No, not needed, thanks.

(In reply to comment #8)

> Timidity seems to be involved. Can you please set the following value in
> /etc/sysconfig/powersave/sleep and retest:
>   SUSPEND2RAM_RESTART_SERVICES="alsasound"

no. It is already in S2RAM_RESTART_SERVICES:
Stopping services: ('hsf autofs alsasound openvpn network irda' configured)

And that's where it hangs. it hangs when starting alsasound, and it never starts autofs and hsf because it never gets there.

Do you need to stop alsasound for suspend to RAM?

(In reply to comment #9)
> (In reply to comment #8)
> 
> > Timidity seems to be involved. Can you please set the following value in
> > /etc/sysconfig/powersave/sleep and retest:
> >   SUSPEND2RAM_RESTART_SERVICES="alsasound"
> 
> no. It is already in S2RAM_RESTART_SERVICES:
> Stopping services: ('hsf autofs alsasound openvpn network irda' configured)
> 
> And that's where it hangs. it hangs when starting alsasound, and it never
> starts autofs and hsf because it never gets there.
> 
> Do you need to stop alsasound for suspend to RAM?
> 

I just tried to play a sound right now and it doesn't work. I probably did not notice that before because I always did a rcpowersaved restart before continuing to work (just to be sure that it worked and my laptop wouldn't get hurt by a malfunction).

Trying rcalsasound restart gives me this output:

thinkpad:~ # rcalsasound restart
Shutting down sound driverERROR: Module snd_mixer_oss is in use
ERROR: Module snd_intel8x0 is in use
ERROR: Module snd_ac97_codec is in use by snd_intel8x0
ERROR: Module snd_ac97_bus is in use by snd_ac97_codec
ERROR: Module snd_pcm is in use by snd_intel8x0,snd_ac97_codec
ERROR: Module snd_timer is in use by snd_pcm
ERROR: Module snd is in use by snd_mixer_oss,snd_intel8x0,snd_ac97_codec,snd_pcm,snd_timer
                                                                      failed
Starting sound driver:  intel8x0                                      done
Could not open sequencer Permission denied
Requested buffer size 2048, fragment size 1024
ALSA pcm 'default' set buffer size 60208, period size 3760 bytes
TiMidity starting in ALSA server mode
Opening sequencer port: 128:0 128:1 128:2 128:3

and sound works as expected and, surprise, the stale script disappeared now!

I think this is an evidence that something wents wrong when alsa is restarted. But even after the manual rcalsasound restart closing the lid isn't recognised.

I needed alsasound in the list because after resume it didn't work in the past. I did not tried it recently but I will in a few minutes.

Thanks for the fast reply!

(In reply to comment #9)
[...]
> 
> Do you need to stop alsasound for suspend to RAM?
> 

OK, I just verified that taking out alsasound does not prevent suspend/resume at all. Now also the other services as openvpn restart correctly...

I'd say that was it but it's still strange that alsasound doesn't work as expected and that somewhere in time its behaviour changed (needed to be in SUSPEND2RAM_RESTART_SERVICES and now *shouldn't*).

If you think that I can help you in any way to trace down what happened, I'd pleased to do so. Just send me instructions...

Thanks a lot,

Taki

Ok, we already removed rcalsasound restart for 10.1. 

So maybe Takashi can help here. But I don't know if it is worth to fix because it is a 10.0 issue.

Takashi, only comment 10 should be important for you, so no need to read the whole report. And please close the the bug if it is not worth to look at.

The bug that rcalsasound doesn't close /dev/mixer* is fixed recently.