Suspend no longer works after updating to 2.6.31-605.9 kernel

This regression might be caused by our kexec patches which are not in upstream mainline. I reverted 2 patches and prepared kernel packages for testing: http://people.canonical.com/~roc/kernel/lp537083/

Thanks, please update the testing result here.

kernel still won't resume after installing this kernel

Paul,

Could you please help me to test again? the kernel is in the same url: http://people.canonical.com/~roc/kernel/lp537083/

Thanks a lot,
-Bryan

With this one, I am now able to suspend and resume

I am still unable to resume from suspend. Not sure why. Not seeing any indication on console output to indicate power button is being acknowledged.

Further checking shows that the power button is being seen in dmesg log when system is online. Checked power applet settings, and it is supposed to ask what to do when power button is pressed, however nothing comes up. Not sure which app is supposed to monitor power button, but it appears to be not configured correctly on my system.

Tobin and Paul,

It is so weird, I failed to find any kernel to make suspend/resume work now. Which kernel works on your side?

-Bryan

The one you posted on http://people.canonical.com/~roc/kernel/lp537083/linux-image-2.6.31-605-imx51_2.6.31-605.9~lp537083_armel.deb worked for me, and I think oliver reported it working for him as well. For some reason Tobin's still will not resume correctly with this kernel.

I believe there is a configuration setting outside the kernel that maps the power button to an applet that may be missing in newer images. I am trying to go backwards to find out what images work, then move forward to narrow it down. I believe the reason it works for Paul(plars) and Oliver(ogra) is that they have been doing updates to existing images, whereas I have been running nuke & pave image testing.

I have narrowed it down to a difference between the 20100303 and 20100305 daily images (20100304 failed to build). Reviewing the image manifests to determine a probable cause.

Reinstalled my system from todays image (20100316) and confirmed that the bug still exists. I could not resume after suspending. Downgraded again to the kernel in comment #8, and suspend/resume works correctly again.

I think I narrowed down to the check-in about a fixing of leds driver. Then I reverted that patch and prepared a kernel package for testing. Please help me to test. Thanks a lot
http://people.canonical.com/~roc/kernel/lp537083/linux-headers-2.6.31-605-imx51_2.6.31-605.10+revert_leds_armel.deb

-Bryan

That was the headers :) but yes the kernel with revert_leds_armel there works, I can suspend and resume with it.

Working on a fix for the update leds driver.

This patch fixes the problem for me. Please test & let me know the results.

From the patch comments:

[PATCH] leds-mc13892: fix suspend/resume

The workqueue update for the leds-mc13892 driver introduced a regression
where machine would no longer suspend and resume, as the wrong type was
being retrieved from the platform drvdata.

This change updates the suspend and resume functions to use the struct
mc13892_led type.

Signed-off-by: Jeremy Kerr <email address hidden>

Jeremy,

Thanks a lot. I prepared a kernel package here for testing:
http://people.canonical.com/~roc/kernel/lp537083/linux-image-2.6.31-605-imx51_2.6.31-605.10+lp537083_fix_leds_armel.deb

and the patch is in my git tree:
http://kernel.ubuntu.com/git?p=roc/ubuntu-lucid.git;a=shortlog;h=refs/heads/leds

Paul and Tobin,
would you please help us to test? This time it is kernel package, -:)

Thanks,
-Bryan

The fix_leds_armel kernel you just posted works for me.

Applied to fsl-imx51 in lucid.

This bug was fixed in the package linux-fsl-imx51 - 2.6.31-605.10

---------------
linux-fsl-imx51 (2.6.31-605.10) lucid; urgency=low

  [ Upstream Kernel Changes ]

  * leds-mc13892: fix suspend/resume
    - LP: #537083
 -- Andy Whitcroft <email address hidden> Fri, 19 Mar 2010 19:43:08 +0000