Kernel oops with Athlon 64 X2 Black Edition

If you have trouble with PHC you can ask and hope for help here.
User avatar
DavidG
Posts: 180
Joined: Fri 18. Jul 2008, 11:25
Contact:

Re: Kernel oops with Athlon 64 X2 Black Edition

Post by DavidG » Sun 9. Aug 2009, 17:10

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

fusterjj
Posts: 10
Joined: Sat 18. Jul 2009, 07:18

Re: Kernel oops with Athlon 64 X2 Black Edition

Post by fusterjj » Sun 9. Aug 2009, 19:58

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

User avatar
DavidG
Posts: 180
Joined: Fri 18. Jul 2008, 11:25
Contact:

Re: Kernel oops with Athlon 64 X2 Black Edition

Post by DavidG » Sun 9. Aug 2009, 23:13

fusterjj wrote: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...
A bank is a place where they lend you an umbrella in fair weather and ask for it back when it begins to rain -- R. Frost

fusterjj
Posts: 10
Joined: Sat 18. Jul 2009, 07:18

Re: Kernel oops with Athlon 64 X2 Black Edition

Post by fusterjj » Mon 10. Aug 2009, 01:32

Hello,
DavidG wrote: 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.

User avatar
DavidG
Posts: 180
Joined: Fri 18. Jul 2008, 11:25
Contact:

Re: Kernel oops with Athlon 64 X2 Black Edition

Post by DavidG » Mon 10. Aug 2009, 08:29

fusterjj wrote: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...
A bank is a place where they lend you an umbrella in fair weather and ask for it back when it begins to rain -- R. Frost

User avatar
DavidG
Posts: 180
Joined: Fri 18. Jul 2008, 11:25
Contact:

Re: Kernel oops with Athlon 64 X2 Black Edition

Post by DavidG » Tue 25. Aug 2009, 10:35

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...
A bank is a place where they lend you an umbrella in fair weather and ask for it back when it begins to rain -- R. Frost

lxp
Posts: 42
Joined: Sat 26. Sep 2009, 22:27
Contact:

Re: Kernel oops with Athlon 64 X2 Black Edition

Post by lxp » Wed 30. Sep 2009, 20:08

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

Post Reply