On 09/22/2013 04:10 AM, Aaron Lu wrote: > Add linux-pm. > > -Aaron > > On 09/21/2013 01:13 AM, Hans de Bruin wrote: >> During boot time my laptop screen goes blank when de kernel switches the >> screen to another resolution. The backlight is on. Eventually a kde >> login box appears out of the blackness. Swiching to a lower resolution >> gives me a black screen again. After testing the >> intel-gfx@xxxxxxxxxxxxxxxxxxxxx developers test-tree problem less they >> sugested a bisect. That bisect ended in: >> >> >> commit 137b944e100278d696826cf25c83014ac17473fe >> Author: Daniel Lezcano <daniel.lezcano@xxxxxxxxxx> >> Date: Wed Jun 12 15:08:48 2013 +0200 >> >> cpuidle: Make it clear that governors cannot be modules >> >> cpufreq governors are defined as modules in the code, but the Kconfig >> options do not allow them to be built as modules. This is not really >> a problem, but the cpuidle init ordering is: the cpuidle init >> functions (framework and driver) and then the governors. That leads >> to some weirdness in the cpuidle framework. >> >> Namely, cpuidle_register_device() calls cpuidle_enable_device() which >> fails at the first attempt, because governors have not been registered >> yet. When a governor is registered, the framework calls >> cpuidle_enable_device() again which runs __cpuidle_register_device() >> only then. Of course, for that to work, the cpuidle_enable_device() >> return value has to be ignored by cpuidle_register_device(). >> >> Instead of having this cyclic call graph and relying on a positive >> side effects of the hackish back and forth cpuidle_enable_device() >> calls it is better to fix the cpuidle init ordering. >> >> To that end, replace the module init code with postcore_initcall() >> so we have: >> >> * cpuidle framework : core_initcall >> * cpuidle governors : postcore_initcall >> * cpuidle drivers : device_initcall >> >> and remove the corresponding module exit code as it is dead anyway >> (governors can't be built as modules). >> >> [rjw: Changelog] >> Signed-off-by: Daniel Lezcano <daniel.lezcano@xxxxxxxxxx> >> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@xxxxxxxxx> >> >> :040000 040000 45e7cb28411864c00b62296a7ff239f9f139d5d9 >> 86a36b01dee52a77cfbab41a973b7a2bfa44ce34 M drivers >> >> >> >> Reverting it makes the problem go away. Ok, can you give more informations about it, I don't see the connection between screen resolution and cpuidle. It would be interesting here to understand the root problem. Can you give the cpuidle configuration (used governor and driver) ? If you don't revert the patch but disable cpuidle (eg. cpuidle.off=1 or don't compile it in the kernel), does the bug issue still occur ? Thanks -- Daniel -- <http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook | <http://twitter.com/#!/linaroorg> Twitter | <http://www.linaro.org/linaro-blog/> Blog -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
