Kernel oops with Athlon 64 X2 Black Edition

[DavidG]

Alright, so now it works? Could you post exactly the same when using be_maxfid=22...?

[fusterjj]

Well actually, if you look at this section from my post:

Code: Select all

joel@periphas:/sys/devices/system/cpu/cpu0/cpufreq$ cat cpuinfo_max_freq
3000000
joel@periphas:/sys/devices/system/cpu/cpu0/cpufreq$ cat scaling_max_freq
3000000
joel@periphas:/sys/devices/system/cpu/cpu0/cpufreq$ cat scaling_available_frequencies
3000000 2800000 2600000 2400000 2200000 2000000 1800000 1000000
joel@periphas:/sys/devices/system/cpu/cpu0/cpufreq$ cat scaling_governor
performance
joel@periphas:/sys/devices/system/cpu/cpu0/cpufreq$ cat scaling_cur_freq
2600000
joel@periphas:/sys/devices/system/cpu/cpu0/cpufreq$ cat /proc/cpuinfo |grep MHz
cpu MHz      : 2600.000
cpu MHz      : 2600.000
joel@periphas:/sys/devices/system/cpu/cpu0/cpufreq$

You can see that while scaling_max_freq says 3000000 and the scaling_governor is "performance," scaling_cur_freq and cpuinfo still say 2600MHz.

If you follow the sequence in my previous post, you can see that for whatever reason, scaling_max_freq drops to 2600000 whenever I switch the scaling_governor to "ondemand." In either case though, scaling_cur_freq and the speed in cpuinfo never go above 2600MHz. I don't know if that's a hint or not.

Thanks,

Joel

[DavidG]

Well actually, if you look at this section from my post...

It doesn't contain the cpufreq debugging stuff. Those I mean, they are very important to trace what's going on...

[fusterjj]

Hello,

It doesn't contain the cpufreq debugging stuff. Those I mean, they are very important to trace what's going on...

I guess I'm a bit confused then. Are we both talking about this post right here (http://www.linux-phc.org/forum/viewtopic.php?p=606#p606)?

There definitely is a ton more output in dmesg than normal, which is in that post. I assumed that messages like "cpufreq-core: setting new policy for CPU 0: 1000000 - 2600000 kHz" are from the cpufreq debugging.

The contents of the post are sequential in time. So I show the dmesg output after modprobe, then after changing the governor, etc. Is there something else you were looking for? Are there other events you need the cpufreq dmesg output from?

Thanks.

[DavidG]

I guess I'm a bit confused then. Are we both talking about this post right here (http://www.linux-phc.org/forum/viewtopic.php?p=606#p606)?

No, that post is exactly what I needed with be_maxfid=23.
I would like to seen another post similar to that one, but this time with be_maxfid=22, so I can compare the output of what is happening with be_maxfid=22 and be_maxfid=23. If I'd had a BE processor, I could do it myself, but I since I don't I depend on your output...

[DavidG]

Again: it would REALLY help all future users of the phc-k8 driver if you could redo everything you did for post http://www.linux-phc.org/forum/viewtopic.php?p=606#p606 but this time use "be_maxfid=22". I would like to compare both cases (be_maxfid=22 and be_maxfid=23). Without this information I CANNOT solve this bug.

So please could you build your kernel with "Enable cpufreq debugging" (if you lost the previous one) and add the following to the kernel-options: cpufreq.debug=7
And use "be_maxfid=22" this time.

Then send the dmesg output, etcetera, especially after enabling the top frequency, especially the freq-table stuff...

[lxp]

Please take a look at this post, maybe it helps you with your overclocking problem too.