Bisected 3.12.0-rc1 Laptop screen goes blank during kernelboot
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 [email protected] developers test-tree problem less they sugested a bisect. That bisect ended in:
commit 137b944e100278d696826cf25c83014ac17473fe
Author: Daniel Lezcano <[email protected]> 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).
:040000 040000 45e7cb28411864c00b62296a7ff239f9f139d5d9 86a36b01dee52a77cfbab41a973b7a2bfa44ce34 M drivers
Reverting it makes the problem go away.
Signature · 1 line
Hans
Add linux-pm.
-Aaron
Quoted 52 lines · Hans de Bruin
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 [email protected] developers test-tree problem less they sugested a bisect. That bisect ended in:
commit
137b944e100278d696826cf25c83014ac17473feAuthor: Daniel Lezcano <[email protected]> Date: Wed Jun 12 15:08:48 2013 +0200cpuidle: Make it clear that governors cannot be modules
cpufreq governors are defined as modules in the code, but the
Kconfigoptions 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()callscpuidle_enable_device()which fails at the first attempt, because governors have not been registered yet. When a governor is registered, the framework callscpuidle_enable_device()again which runs__cpuidle_register_device()only then. Of course, for that to work, thecpuidle_enable_device()return value has to be ignored bycpuidle_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_initcalland 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 <[email protected]>Signed-off-by Rafael J. Wysocki <[email protected]>:040000 040000
45e7cb28411864c00b62296a7ff239f9f139d5d986a36b01dee52a77cfbab41a973b7a2bfa44ce34M driversReverting it makes the problem go away.
Quoted 56 lines · Aaron Lu
Add linux-pm.
-Aaron
Quoted 51 lines · Hans de Bruin
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 [email protected] developers test-tree problem less they sugested a bisect. That bisect ended in:
commit
137b944e100278d696826cf25c83014ac17473feAuthor: Daniel Lezcano <[email protected]> Date: Wed Jun 12 15:08:48 2013 +0200cpuidle: Make it clear that governors cannot be modules
cpufreq governors are defined as modules in the code, but the
Kconfigoptions 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()callscpuidle_enable_device()which fails at the first attempt, because governors have not been registered yet. When a governor is registered, the framework callscpuidle_enable_device()again which runs__cpuidle_register_device()only then. Of course, for that to work, thecpuidle_enable_device()return value has to be ignored bycpuidle_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_initcalland 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 <[email protected]>Signed-off-by Rafael J. Wysocki <[email protected]>:040000 040000
45e7cb28411864c00b62296a7ff239f9f139d5d986a36b01dee52a77cfbab41a973b7a2bfa44ce34M driversReverting 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
Signature · 5 lines
<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
A message that is not in the archive (sent off-list or not yet received): [email protected]
On 09/26/2013 08:17 PM, Hans de Bruin wrote:
[ ... ]
Quoted 29 lines
todays kernel with problem:
#
# CPU Idle
#CONFIG_CPU_IDLE=y
#CONFIG_CPU_IDLE_MULTIPLE_DRIVERSis not setCONFIG_CPU_IDLE_GOV_LADDER=yCONFIG_CPU_IDLE_GOV_MENU=y
#CONFIG_ARCH_NEEDS_CPU_IDLE_COUPLEDis not setCONFIG_INTEL_IDLE=y==>
/sys/devices/system/cpu/cpuidle/current_driver<==acpi_idle==>
/sys/devices/system/cpu/cpuidle/current_governor_ro<== menu[ 0.056000] cpuidle: using governor ladder [ 0.056000] cpuidle: using governor menu3.8.0:
bash-4.1# tail/sys/devices/system/cpu/cpuidle/*==>/sys/devices/system/cpu/cpuidle/current_driver<==acpi_idle
Quoted 7 lines
==>
/sys/devices/system/cpu/cpuidle/current_governor_ro<== menu[ 1.759857] cpuidle: using governor ladder [ 1.763849] scsi 0:0:0:0: Direct-Access ATA TOSHIBA MK4009GA BS11 PQ: 0 ANSI: 5 [ 1.767098] cpuidle: using governor menu
Thanks for the detailed information. Could you pastebin you kernel config file or send it to me privately so I can reproduce the problem ?
Signature · 10 lines
<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 [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html