https://bugzilla.kernel.org/show_bug.cgi?id=55411 --- Comment #32 from Viresh Kumar <viresh.kumar@xxxxxxxxxx> 2013-03-24 10:02:42 --- Hi Duncan, Please reply to this mail rather than using bugzilla as all others might not be following bugzilla rerport. > --- Comment #31 from Duncan <1i5t5.duncan@xxxxxxx> 2013-03-24 09:48:41 --- > (In reply to comment #28) >> My weekend is already spoiled (due to my bugs :) ) and i don't want to spoil >> yours. > > Don't worry about it. They're all days in the week, to me. I don't really > have a defined "weekend". In fact, I had been (somewhat impatiently) grumbling > to myself Friday that I was likely to have to wait until Monday for something > concrete to test, so I'm happy to be demonstrated wrong! =:^) :) >> [PATCH] cpufreq: acpi-cpufreq: Set policy->cpus correctly from .init() > > You appear to be on the right path as all the dirs and symlinks are there now, > but it looks like you'll need a v2 as the order/pairing is now very strange, > both as booted and after a s2ram/resume (which changes the order but it's still > strange): :( > Testing against 3.9-rc4 now. > > Patch applied pre-suspend ls -dl as above (original pairing is 0/1, 2/3, 4/5, > with the first always a dir and the second always a symlink to the first, as > seen in comment #0): > > /sys/devices/system/cpu/cpu0/cpufreq/ > /sys/devices/system/cpu/cpu1/cpufreq -> ../cpu0/cpufreq/ > /sys/devices/system/cpu/cpu2/cpufreq/ > /sys/devices/system/cpu/cpu3/cpufreq/ > /sys/devices/system/cpu/cpu4/cpufreq -> ../cpu3/cpufreq/ > /sys/devices/system/cpu/cpu5/cpufreq -> ../cpu2/cpufreq/ The way it works (in cpufreq core), the first cpu of group registered for cpufreq would get a directory and second one would get a symlink. And the above ones also doesn't look good. 2/5 and 3/4 shouldn't be the groups. acpi-cpufreq driver is getting this information from perf->shared_cpu_map and that seems to be wrong to me now. > Post s2ram/resume cycle: > > /sys/devices/system/cpu/cpu0/cpufreq/ > /sys/devices/system/cpu/cpu1/cpufreq -> ../cpu0/cpufreq/ > /sys/devices/system/cpu/cpu2/cpufreq -> ../cpu4/cpufreq/ > /sys/devices/system/cpu/cpu3/cpufreq -> ../cpu5/cpufreq/ > /sys/devices/system/cpu/cpu4/cpufreq/ > /sys/devices/system/cpu/cpu5/cpufreq/ 2/4 and 3/5 are also wrong groups. > But I don't know whether it's CPU ordering that's weird, or the cpufreq > ordering. IOW, I don't know whether it /should/ be 0/1, 2/3, 4/5 or not, > because I don't know whether those numbers actually reflect the hardware so > it's the ordering above that's bad, or if the cpu numbers are just arbitrarily > assigned, and the ordering above reflects the actual hardware, and just looks > strange due to the arbitrary cpu numbering. One thing i am sure about is cpu order is fixed at boot and after boot whatever you do can't change that order... So order should always be 0/1, 2/3, 4/5 > Either way, there's the correct number of dirs and links now, but the ordering > is extremely confusing and looks wrong, regardless of whether it actually > corresponds to the hardware or not, something I don't have the ability to > judge. Hmm.. Can you try one thing? Run 3.8 over your machine and give output of cpufreq-info and ls -ld after boot and resume.. I would like to see what's the original behavior. -- viresh -- Configure bugmail: https://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
