XO-1.75/Kernel/Issues: Difference between revisions
| Line 32: | Line 32: | ||
Only occurs with SUS_TIME not set to 3000. |
Only occurs with SUS_TIME not set to 3000. |
||
| ⚫ | |||
Instances: |
Instances: |
||
| Line 44: | Line 42: | ||
* http://dev.laptop.org/~quozl/z/1RhvpV.txt |
* http://dev.laptop.org/~quozl/z/1RhvpV.txt |
||
* http://dev.laptop.org/~quozl/z/1RiK9g.txt (proving it does not require the body of the function) |
* http://dev.laptop.org/~quozl/z/1RiK9g.txt (proving it does not require the body of the function) |
||
Diagnosis. |
|||
| ⚫ | |||
Adding a 60ms mdelay() per device within the dpm_resume() function, within the list processing, [http://dev.laptop.org/~quozl/z/1Rijw0.txt patch] has shown results [http://dev.laptop.org/~quozl/z/1Rijy3.txt t0], [http://dev.laptop.org/~quozl/z/1RijyO.txt t1]. Note that the elapsed time shows no correlation with the previous instances of the issue. |
|||
Revision as of 09:53, 5 January 2012
hang, mmp2-pcm-audio.0 resume
This is a hang with the last serial console message:
mmp2-pcm-audio mmp2-pcm-audio.0: resume
No FIQ. No SysRq. Always preceeded by a PM: Some devices failed to suspend.
Jon Nettleton says known problem. Caused by interrupted suspend, and during the unwind of the resume it hangs.
Can be worked around by removing the audio driver from the kernel.
Disabling runin-sound has no effect.
Seen within half an hour if SUS_TIME is set to 3000. Rarely or never seen if SUS_TIME is set to 10000.
Theory: once a suspend takes too long, the RTC alarm goes off before suspend has finished, and the suspend is interrupted, leading to this issue.
Impact: may trigger also with other wake sources, leading to a failed runin.
Instances:
Might be fixed by http://dev.laptop.org/git/olpc-kernel/commit/?h=arm-3.0-wip-wfi&id=92ef8264199818b91518f7fe7af365c5998381fa
hang, mmp2_pm_finish: Enable audio island
This is a hang shortly after the serial console message:
mmp2_pm_finish: Enable audio island
The time period may vary.
Only occurs with SUS_TIME not set to 3000.
Instances:
- http://dev.laptop.org/~quozl/z/1RiHT6.txt (75.904ms)
- http://dev.laptop.org/~greenfeld/temp/175bringup/os23-ff199462/screenlog.3-resumehang2ecmod.bz2 (80.341ms)
- http://dev.laptop.org/~greenfeld/temp/175bringup/os23-26f404e/screenlog.6-resumehang.bz2 (2.683ms)
- http://dev.laptop.org/~greenfeld/temp/175bringup/os23-26f404e/screenlog.3-ecfail1.bz2 (72.616ms)
- http://dev.laptop.org/~quozl/z/1Rhvmt.txt
- http://dev.laptop.org/~quozl/z/1RhvpV.txt
- http://dev.laptop.org/~quozl/z/1RiK9g.txt (proving it does not require the body of the function)
Diagnosis.
Tracing the point of hang by gradually adding printk has shown the problem occurs in dpm_resume(), before dpm_complete() is called by dpm_resume_end().
Adding a 60ms mdelay() per device within the dpm_resume() function, within the list processing, patch has shown results t0, t1. Note that the elapsed time shows no correlation with the previous instances of the issue.