This is not yet close to be a definite answer. Instead, it's a set of suggestions too long to fit in comments.
I'm afraid you might slightly misinterpret the meanings of sysfs cpufreq parameters. For instance, on my Core Duo laptop, the related_cpu parameters for both cores read 0 1 - which, according to your interpretation, would mean that the cores cannot switch frequencies independently. But that is not the case - I can set each frequency at will. By contrast, the affected_cpus parameter for each core lists only the respective CPU number.
You might want to take a look at kernel documentation for cpu-freq to get a better understanding of the parameters such as affected_cpus,related_cpus,scaling_* and cpuinfo_*. The documentation is normally distributed with kernel source packages. Specifically, I recommend reading <kernel-sources-dir>/Documentation/cpu-freq/user-guide.txt, where <kernel-sources-dir> would typically stand for /usr/src/linux or /usr/src/linux-<kernel-version>. (However, when I skim through the documentation myself now, I confess I don't catch some of the frequency-scaling-related nuances. To fully understand these, one probably needs to gain a solid understanding of CPU architectures first.)
Back to your question. And one more test case on my part: when I change the value of scaling_max_freq (with either userspace or performance governor being used), the core's clock automatically switches to that new maximum. The different behaviour you're observing might be any of:
- specific to hardware implementation of frequency scaling mechanisms on your CPU,
- due to differences between the standard
cpufreq module and phc-intel which I'm using,
- normal behaviour (call it a bug or a feature if you will) of
cpufreq module, which has changed at some point since 2.6.35 (my current kernel version is 3.6.2),
- result of a bug in
cpufreq implementation for your CPU (or entire family),
- specific to the implementation of
performance CPU governor as of 2.6.35.
Some of the things you might do to push your investigation further:
- read the
user-guide.txt and fiddle more with other cpufreq parameters,
- repeat the tests while running a newer kernel - the easiest way is to boot a liveCD/DVD/USB.
If you continue to experience unexpected behaviour and gain more reasons to believe it is due to a bug (definitely must check with the latest minor kernel version), go ahead and report this on kernel.org bugzilla.