swsusp 2.0 with kernel 2.6.4, failure to suspend (vaio fx701)

swsusp 2.0 with kernel 2.6.4, failure to suspend (vaio fx701)

[Romano Giannetti]

Hi all, hi Nigel,

   as promised I tried swsusp2 with my vaio. Here is my report: 

Ok,
     I tried swsup2 with kernel 2.6.4. Maybe I have made something
     incorrect, so I will simply report what happened to me. 
     
   * I have a Sony FX701 laptop; Mandrake 9.2 with upgrades, with
     working 2.6.4 kernel. It works (in the sense that it will suspend
     correctly) with in-kernel swsusp and pmdisk. 
     
   * To test swsusp2, I did the following: 
     - patched a vanilla kernel with (in the order):
              software-suspend-linux-2.6.4-test3-whole.bz2
              software-suspend-core-2.0-whole.bz2*
              software-suspend-core-2.0.0.22-incremental.bz2*
     Configured and installed; .config and lilo.conf available here: 
     http://perso.wanadoo.es/r_mano/vaio/suspend/dot_config.zip
     http://perso.wanadoo.es/r_mano/vaio/suspend/lilo.conf.zip
     
   * Then I used my suspend script, with  the only change of 
          echo yes > /proc/swsusp/activate
     instead of 
          echo 4 > /proc/acpi/sleep
     (script is rg_sw2_script) 
     http://perso.wanadoo.es/r_mano/vaio/suspend/rg_sw2_script
     
   * The result is:
     - the laptop switch to text console
     - a screen says "waiting to activities to finish" 
     - I waited 5 minutes, but nothing happened - the "status bar" would not
       move. 
     Pressing ESC at this point, the laptop comes back to its normal working
     condition, with the task dump included in the file 
     failed_suspend1.txt.gz.
     http://perso.wanadoo.es/r_mano/vaio/suspend/failed_suspend1.txt.zip     
   
    * I rebooted (to have a fresh start) and repeated with swsusp2
    debug_level set to 9, log_everything to yes, like this:
    # echo 9 > /proc/swsusp/default_console_level
    # echo yes > /proc/swsusp/log_everything
    # echo yes > /proc/swsusp/beeping
    # echo yes > /proc/swsusp/slow
    and what I obtained is a very similar behaviour, see it in
    failed_suspend2.txt.gz. Now during suspend a few traces were printed (I
    am not sure they have been logged, they scrolled really fast) then a
    series of lines told "swsusp_num_active is 4, Idle for 250 jiffies"
    scrolled away, more or less one or two per second. Pressing ESC will 
    resume the laptop. 
    http://perso.wanadoo.es/r_mano/vaio/suspend/failed_suspend2.txt.zip
      
Conclusion: swsusp2 does not work for me, but probably it's a trivial
problem... There is something that would not freeze. 
I am available to give more info on request and try more things.


Romano

   
-- 
Romano Giannetti             -  Univ. Pontificia Comillas (Madrid, Spain)
Electronic Engineer - phone +34 915 422 800 ext 2416  fax +34 915 596 569

Re: swsusp 2.0 with kernel 2.6.4, failure to suspend (vaio fx701)

[Nigel Cunningham]

Hi.

Thanks for the report; The end of your log shows us that it was
saslauthd that was causing the freezing failure. I'll look at what
adjustments would fix that issue.

Regarding getting more debugging info, you need to use debug_sections as
well as the default_console_level; the console level says how much
information you want. debug_sections says what information you want.
(Suspend it capable of printing an awful lot of debugging info; usually
we're only interested in one particular area).

Regards,

Nigel
   
-- 
Nigel Cunningham
C/- Westminster Presbyterian Church Belconnen
61 Templeton Street, Cook, ACT 2614.
+61 (2) 6251 7727(wk); +61 (2) 6253 0250 (home)

Evolution (n): A hypothetical process whereby infinitely improbable events occur 
with alarming frequency, order arises from chaos, and no one is given credit.

Re: swsusp 2.0 with kernel 2.6.4, failure to suspend (vaio fx701)

[Romano Giannetti]

On Tue, Mar 23, 2004 at 09:22:22AM +1200, Nigel Cunningham wrote:
> Hi.
> 
> Thanks for the report; The end of your log shows us that it was
> saslauthd that was causing the freezing failure. I'll look at what
> adjustments would fix that issue.

Ok.

> Regarding getting more debugging info, you need to use debug_sections as
> well as the default_console_level; the console level says how much
> information you want. debug_sections says what information you want.
> (Suspend it capable of printing an awful lot of debugging info; usually
> we're only interested in one particular area).

Darn, I missed it. Tell me which sections are of interest, and I can repeat
(this afternoon, if it's useful) and report. 

Thanks,
       Romano

-- 
Romano Giannetti             -  Univ. Pontificia Comillas (Madrid, Spain)
Electronic Engineer - phone +34 915 422 800 ext 2416  fax +34 915 596 569