Hey all,
Since moving a 4.3 x86-64 install from a single athlon64 to a new dual core AMD cpu it would appear that cool'n quiet is having trouble as is shown in the system logs;
powernow-k8: ignoring illegal change in lo freq table-2 to 0x2 powernow-k8: transition frequency failed
Any ideas ?
Cheers,
Brian.
Centos-admin wrote:
Hey all,
Since moving a 4.3 x86-64 install from a single athlon64 to a new dual core AMD cpu it would appear that cool'n quiet is having trouble as is shown in the system logs;
powernow-k8: ignoring illegal change in lo freq table-2 to 0x2 powernow-k8: transition frequency failed
Any ideas ?
The consensus seems to be that powernow is broken at this juncture and a lot of folks are just turning it off. I disable it on all my systems and haven't had any issues as a result.
Cheers,
On Sat, 2006-08-19 at 09:31 -0400, chrism@imntv.com wrote:
Centos-admin wrote:
Hey all,
Since moving a 4.3 x86-64 install from a single athlon64 to a new dual core AMD cpu it would appear that cool'n quiet is having trouble as is shown in the system logs;
powernow-k8: ignoring illegal change in lo freq table-2 to 0x2 powernow-k8: transition frequency failed
Any ideas ?
The consensus seems to be that powernow is broken at this juncture and a lot of folks are just turning it off. I disable it on all my systems and haven't had any issues as a result.
Cheers,
kk, I'm runnin three 64 amds...1 socket 754 and 2 939's Now I don't really get into the log thing that much...I have seen those msgs but all and all works ok...I have noticed tho that the 939's seem to work a lot cleaner.
John Rose
I thought Powernow would not be running at all on default CentOS 4 since AMD says to recompile the kernel with the linux driver package they provide, and the latest drivers don't work with kernels before 2.6.9, anyway. After your three postings I googled around and found I have to load the powernow and cpufreq-ondemand modules. I did so on one of my machines and changed the governor to ondemand. Seems to work so far, no error messages yet. My machines are on AM2 sockets.
One problem I have is that I don't get cpuinfo_cur_freq, only scaling_cur_freq. I also don't get any temperatur reading via /proc/acpi/thermal_zone, but I assume that's because of the chipset? (nforce 430).
Kai
Centos-admin wrote on Sat, 19 Aug 2006 19:06:39 +1000:
dual core AMD cpu
btw, no one having issues in X server with these? I got two a few days ago and both have the same problems in gnome (I didn't try another window manager).
1. they randomly repeat characters I type. It's not that they repeat too fast or too early or so. It just happens randomly but much too often. I had to disable the key repeat. I tried the nvidia supplied X server/display driver but this didn't make a difference. I remembered that the CentOS Live CD doesn't have this problem and when I booted into it again and checked the kernel it was clear why: it uses the normal kernel.
2. the menus of the upper action bar often don't stick. Very often they go away right after the click, so that I have to press the mouse key most of the time to keep them in sight.
I haven't noticed any other bad signs for non-X programs and if it is confined to X or gnome only I'm happy, but I fear there might be more serious problems only revealed over time.
Kai
On 21/08/06, Kai Schaetzl maillists@conactive.com wrote:
Centos-admin wrote on Sat, 19 Aug 2006 19:06:39 +1000:
dual core AMD cpu
btw, no one having issues in X server with these? I got two a few days ago and both have the same problems in gnome (I didn't try another window manager).
None. Is this really problem with CPU's? Difficult to debug with information provided.
Sudev Barar wrote on Mon, 21 Aug 2006 06:18:33 +0530:
None. Is this really problem with CPU's?
It seems so since it goes away when using the single CPU kernel.
Difficult to debug with information provided.
Sure. ;-) I see this on an X2 4200+ and on an X2 3800+ EE. Motherboard for both is from Gigabyte with Nvidia 430 chipset (MCP51). Chipset driver from Nvidia is installed (forcedeth has a problem with the built-in network card). It only happens in Gnome, I didn't try other window managers. When I type in the Terminal window or in gedit I basically cannot type a single word without at least one character getting repeated, sometimes several dozen of it in an instant, quite often each and every character gets repeated. Happens with every key, including ENTER. The only way I can prevent this is to type very slowly, say type a character, wait a second, type next character. But even then it can happen, but very seldom. Or I switch off key repetition. It's got nothing to do with the repeat rate or interval. It doesn't happen on the console or via ssh terminal. That's why I hoped installing the graphics driver from Nvidia as well might solve the problem. But it doesn't. Using the single CPU kernel fixes this it, so I think it's directly related to it and has nothing to do with chipset or so.
There's another problem I encountered yesterday and first thought it's related to powernow-k8. With powernow-k8 system time runs too fast. This didn't seem to happen without it. However, now that I had it run over night without powernow the time has leaped almost an hour again, so it seems it happens without powernow as well. Could there be a connection? It seems that at least this issue is very common with the SMP kernel and there are several recommendations for kernel parameters, but I'm not sure which one to try first or what they exactly do:
clock=pmtmr notsc noapictimer no_timer_check
Kai
Kai Schaetzl wrote:
There's another problem I encountered yesterday and first thought it's related to powernow-k8. With powernow-k8 system time runs too fast. This didn't seem to happen without it. However, now that I had it run over night without powernow the time has leaped almost an hour again, so it seems it happens without powernow as well. Could there be a connection?
This disease seems to be ongoing for some people. On the box of mine that was affected, a later kernel fixed it.
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=55223
If you look in your dmesg you might see complaints about missing interrupts.
-Andy
Andy Green wrote on Mon, 21 Aug 2006 15:35:21 +0100:
This disease seems to be ongoing for some people. On the box of mine that was affected, a later kernel fixed it.
So you are running an FC kernel on CentOS or RHEL? Or running FC anyway?
Thanks for the link, Andy. Didn't sound that similar in the beginning. I tried to repro those network transfer issues and couldn't. But the keyboard repeat stuff reported later sounds "promising". Seems there were really two problems mixed in one report.
If you look in your dmesg you might see complaints about missing interrupts.
None. After reading the bug report I added report_lost_ticks to grub.conf and rebooted, but still no errors in dmesg. Is my understanding correct that report_lost_ticks enables reporting in dmesg or logs or is it something else? Hm, according to Google it's exactly for this. Do I need to add something, f.i. "report_lost_ticks=1" or so?
Hm, a few minutes later. The problem wasn't very apparent over the last hours. After an ntpdate it differed about 2 seconds within a few seconds and basically stayed that way, no increase or at least no noticable increase. Maybe it jumps from time to time to "achieve" a greater skew. However, now after rebooting with report_lost_ticks there's almost no difference. Hm. And, wow, I changed to runlevel 5 and the keyboard repeat problem is gone! I hope that really cures it, great!
And another few minutes later. Time is still okay, but maybe it's too early for that. But the keyboard repeat problem is back. Not as bad as before, though. Weird.
Kai
Kai Schaetzl wrote on Mon, 21 Aug 2006 18:44:16 +0200:
I tried to repro those network transfer issues and couldn't. But the keyboard repeat stuff reported later sounds "promising".
Actually, I was later able to repro the network transfer issue as well. You just need to transfer a lot before it is visible. As someone said in the original report it takes at least 600 MB, for whatever reason. But then it jumps really quick (3 to 5times as normal) and doesn't stop until you reboot.
A better bug report/discussion is here: http://bugzilla.kernel.org/show_bug.cgi?id=5105 There's even a (yes!) Microsoft KB article at http://support.microsoft.com/kb/918461/en-us which describes the problem very well, just for a different scenario. It also explains why I don't get lost ticks logged: there aren't any. However, the kernel thinks because of the unsynced TSCs he lost some and adjusts for that. As I understand clock=pit switches that adjustment algorithm off and so the problem is gone. The solution is to use the clock=pit kernel boot parameter. All my symptoms are gone with that. My clock is not rock-stable now, it leaped four seconds from yesterday to today, but this might be caused by something else and is something ntp can deal with. The obvious solution for the kernel would be to use only one core for TSC and not let it balance to other cores. Don't know if the patch from that bug report does that or something else or if it really works.
Kai
-
Andy Green -
Centos-admin -
chrism＠imntv.com -
Kai Schaetzl -
rado -
Sudev Barar