Hawk’s Babble-Log

When I first saw this message:

powernow-k8: failing targ, change pending bit set

I thought to myself, “Eh?” I had no idea what it meant. Then I did some research and discovered it was due to a hardware bug with some AMD processors, and that there was a process in linux (CentOS/Redhat) which was unable to update a bit due to this hardware bug. This process was responsible for changing the speed of the processor on the fly, to help save power.

However, this process then did the stupidest thing I’ve ever seen: it repeatedly displayed this message to the console:

powernow-k8: failing targ, change pending bit set
Once
powernow-k8: failing targ, change pending bit set
per
powernow-k8: failing targ, change pending bit set
second.
powernow-k8: failing targ, change pending bit set

This is, without a doubt, the most suppressive error message I’ve ever seen. Because it was displayed to the console once per second, I was unable to debug the issue using the console. The best I could do was configure one of the network cards (blind, I might add), so that I could then SSH in to the machine from elsewhere. Then I was able to debug it.

Any process which repeatedly displays anything to the console, overwriting anything you’ve got up there, on any virtual terminal, is a suppressive process and should be completely eliminated with prejudice.

Here’s what I did to stop these suppressive error messages:

# /etc/rc.d/init.d/cpuspeed stop
Disabling ondemand cpu frequency scaling:                  [  OK  ]

Now those annoying (and suppressive) error messages stopped appearing on the console, and I breathed a sigh of relief. However, the dang thing would start back up again after a reboot:

# chkconfig --list cpuspeed
cpuspeed        0:off   1:on    2:on    3:on    4:on    5:on    6:off

chkconfig is telling you that this process will start for all runlevels except 0 and 6.

Here’s what I did to prevent it from loading up again:

# chkconfig --del cpuspeed

Now check the status:

# chkconfig—list cpuspeed
service cpuspeed supports chkconfig, but is not referenced in any runlevel (run ‘chkconfig—add cpuspeed’)

There, it’s gone forever. This did not fix the hardware bug, it just prevented my system from trying to change the cpu speed and, failing, spewing forth suppressive error messages all over the console continuously.

I hope this helps.