Ubuntu Wiki

• Launchpad Entry: kernel-karmic-suspend-resume

• Created:

• Contributors:

• Packages affected:

Summary

We integrated suspend and resume apport reporting in Jaunty and got a ton of reports of Resume failures, We would like to improve suspend/resume experience in Karmic. Triaging the suspend resume bugs that got opened recently we have identified that most of the issues were related to modules that deal with graphics card drivers and ethernet/wireless drivers. In this session we intend to do a little bit of brain storming to improve suspend/resume in Karmic.

Release Note

The impact of changes that will be put in place as a result of this session should improve suspend/resume experience on Karmic.

Rationale

Users of Laptops and Netbooks almost never shutdown and power on their devices, they prefer to close the laptop lid and expect the laptops to suspend, and open the lid to resume. This saves the state of the various applications they were running before suspend, and resume using these application upon resume. This continues to be the use case for laptops and netbooks in spite of fast shutdown/reboot times in Jaunty.

Design

- remove offending modules (Realtek drivers for example) before suspend and load them after resume. - fix X drivers before suspend and insert them after resume - perhaps modify the suspend/resume scripts (?)

Unresolved issues

We have over 600 bugs opened on suspend/resume for jaunty, although I was able to identify some offending drivers that are common to some of the bugs, we are not able to resolve all of them.

Summary of Discussion

There was discussion how things went in the Jaunty cycle when we enabled reporting on suspend/resume issues. There was an overwealming amount of bug reports and we were unable to cope and fairly respond to them in a timely fashion. This work did find several generic bugs but we were unable to satisfactory find common theams. Some improvements were made over the cycle including better reporting and potential to use the hardware DB.

It was pointed out that Rafael had written an OLS paper on the improvements coming in this area.

There was disussions of what our goals should be in the Karmic cycle. We clearly want to continue to improve the suspend/resume experience and if nothing else our testing in Jaunty has shown we have a problem. Also we have a number of improvements in the pipe coming from KMS which we would like to evaluate against Jaunty's results. The direct Goals were:

• no drivers needing removal
• a review and cleanup of the pm-util scripts
• better unstanding of the Jaunty issues via data analysis
  • dupping of common problems together etc

A number of ideas were suggested:

• investigate the debugging features and why they don't work
• investigate leaving the console on longer
  • no_console_suspend how would this affect the experience
  • how does KMS affect this
• /sys/power/pm_test file, tell it which level suspends to go down to
• look at some Karmic testing, but more focused this time
  • look at very bad machines, and request specific testing on those
  • Can script updating bug reports from testers w/ request to re-test
  • there are many suspend resume bug fixes available in newer kernels,
  • expectation is that things or better, being able to measure that
  • has value
• look at how we can help the normal people find out how to communicate
• upstream
  • WIP for lp/bugzilla plugin for kernel bugzilla
• are we upstreaming bugs where we are using suspend/resume remove of
• module as a solution
  • we should be opening generic bugs for failures, with upstream bugs
  • linked each
  • we should be getting upstream kernel testing if possible too

We should also consider allowing users to opt in to reporting more information to make these reports better:

• do you want to send data "i don't mind":
  • success reports
    • success needs data on the environment that leads to success
  • having something in launchpad, allowing us to take more testing
  • with them and reporting success etc

CategorySpec