http://bugzilla.kernel.org/show_bug.cgi?id=13860 --- Comment #8 from Thomas Renninger <trenn@xxxxxxx> 2009-08-04 10:41:01 --- Pierre, some ideas to further evaluate the reason, I do not expect this is a duplicate of the other bugs: As we do not evaluate _PPC at processor load time anymore, but only on processor 0x80 notify events, it may be the case that the limit is intended by BIOS, but only gets exposed to the OS on the first processor event. Hmm, probably not, but best first check your BIOS for some kind of PowerNow! = powersave (or similar) setting. If this is the case, just modify that to some kind of "automatic" setting and the bug should get closed. If this is not the case, I recommend a BIOS update, it can be very frustrating if this boils down to an already fixed BIOS bug. If you still see this: After a quick look at the acpidump, it may come from _WAK function which gets called after suspend and some OEM specific functions (here it gets complicated) which in the end could touch _PPC value and notify OS about a BIOS frequency limitation, but this can get hard to debug to the ground. Hibernate means this only happens with s2disk? Linux does not 100% follow s2disk spec and it might come from ACPI getting re-initialized after s2disk which is not done on Windows (AFAIK). It might also come from the EC not being fully functional at _WAK call time, the Embedded Controller gets used at several places there or other not/wrong initialized io components. Find some ideas to better debug this below, it would be great if you could still try a bit more if things point to kernel/Linux bug: This could help to easier reproduce this ---------------------------------------- #/bin/bash CYCLES=10 echo reboot >/sys/power/disk REAL_MAX=`cat /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_max_freq` for ((x=0;x<$CYCLES;x++));do MAX_FREQ=`cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq` if [ $REAL_MAX -ne $MAX_FREQ ];then echo "Max freq: $MAX_FREQ - Bug detected after $x s2disk cycle" break; fi echo disk >/sys/power/state sleep 2 done if [ $x -eq $CYCLES ];then echo "No freq limitation detected after $CYCLES s2disk cycles" exit 0 fi exit 1 What you also could try is to increase ACPI debug level: echo 0x400002F >/sys/module/acpi/parameters/debug_level #add exec and IO debug echo 0xFFFFFFFF >/sys/module/acpi/parameters/debug_layer Interesting would the syslog output of a working and a non-working suspend cycle. I expect this boils down to an ACPI and not cpufreq problem, you might want to adjust the component of the bug. -- Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. -- To unsubscribe from this list: send the line "unsubscribe cpufreq" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
