I’d like to save some power, so I thought I’d look to see if AMD Cool’n’Quiet was turned on in my BIOS. It was off, and I presume it always was off. I changed the setting to ‘AUTO’ and re-booted.
Now the machine hangs at the splash screen. No alt=<Fn> console screens are accessible - it’s a goner.
I press the m/b reset, go back into the BIOS to disable C’n’Q again and now it boots into Gnome correctly as before.
Is this an architectural limitation ( grub2 options) , a DSDT bug ?, any clue ?
Asus M2A-VM last BIOS, AMD Athlon x2 64 4200, 2G DRAM, x86_64 install of 12.3
Thanks, but I can’t see how those scripts will help, as the machine will not complete boot at all if Cool’n’Quiet is turned on, so is a brick not a CPU.
It hangs at what I called the splash screen, the stuttery animation of the pale green chameleon on a branch that increases stepwise in saturation. Is that called ‘Plymouth’ ? (?)
That’s after I let grub2 auto-pick the first option in the list. I haven’t modified any grub2 stuff since 12.3 upgrade. I never tried C’n’Q on 12.2 - the only previous version of OpenSUSE on this m/b.
I’ve been reading about DSDT fixing and it appears this is now pointless because overloading with a patched dsdt.aml has been disabled and labelled as ‘WONTFIX’, i.e.
Try to boot in run-level 1 (press ‘e’ on grub menu entry, go to the end of line that starts with “linux …” and add " 1" (space, 1), press F10. Then do “insserv -r cpufreq” to disable it. It may allow you to boot.
I do want to troubleshoot the problem if there is anywhere useful left to go, but not loading the CPUFreq kernel module will disable all userspace tools and interfaces that do p-state power management, won’t it ?
I’ve loaded the cpupower package and that reports,as expected, that
:->cpupower frequency-info
analyzing CPU 0:
no or unknown cpufreq driver is active on this CPU
Is there a possibility that loading the CPUFreq module *after *Gnome has booted may work whereas loading it at boot time is somehow different ? I’m unfamiliar with this level of kernel subtlety.
I can only see that there is most likely an unfixed bug in my m/b BIOS and, because custom dsdt.aml files are disabled in OpenSUSE as a matter of policy according to a previous link I posted, I can’t do anything to get CPUFreq working by fixing DSDT bugs, can I ?
How should we know? Normally system loads cpufreq drivers that match hardware automatically. In this case it apparently does not happen, so cpufreq tries to probe all of them one by one. One of modules causes your system to hang. It may well be acpi-cpufreq, you will never know in advance.
If you want to experiment with it
do it in run level 3, not in run level 5, to be able to capture console output
or even better in run level 1, so you have as small number of processes as possible running to minimize chance of file system corruption
bump console log level so you will get all kernel messages on console (dmesg -n 7)
try to load cpufreq modules one by one
If system hangs and there is any output on console, make a picture of it, upload to SUSE Paste for review.
Debugging kernel problem does require some experience. The main problem on PC is, you need console logs that you are not able to capture, and screen is often too small to show all of them even if you make a picture. I often had to set up netconsole for it.
Linux kernel p-state management cannot be done unless BIOS turns on CPU p-state feature, surely ? After all, if I turn C’n’Q off in the BIOS, the CPUFreq kernel module does not load. If I turn it on, the CPU reports p-state capability and the CPUFreq module tries to load (unsuccessfully).
My only working option at the moment for OpenSUSE 12.3 is no CPU power management.