All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Devriendt, Paul" <paul.devriendt@amd.com>
To: John Belmonte <john@neggie.net>, cpufreq@lists.linux.org.uk
Subject: RE: powernow-k8 and stuck change-pending bit
Date: Tue, 7 Jun 2005 00:07:22 -0500	[thread overview]
Message-ID: <84EA05E2CA77634C82730353CBE3A843028F4CC5@SAUSEXMB1.amd.com> (raw)

> symptoms:
> 
>     After working fine for a while (several minutes to several hours),
> cpufreq seems to get into a bad state where:
> 
>      * change pending bit set / stuck kernel messages appear
> 
>      * reloading powernow-k8 module fails, with "change 
> pending bit stuck"

I have seen a very small number of reports of this over the past
couple of years. Perhaps 3 or 4. I can tell you what is happening, but
it may not be much help.

The processor has to communicate externally during a frequency or
a voltage change. On a frequency change, all devices on the 
HyperTransport fabric will see a LDT_STOP. On a voltage change, the 
new vid (voltage code) has to be driven out to the external VRM 
(voltage regulator module) which actually supplies the correct 
voltage. Obviously, this external activity takes a little while.

The software interface to this is via a register, and there is a bit
to warn the software that a change is in progress. This is the pending 
bit. A change should never fail to complete. It can fail if the change
request was invalid, but it should not fail to complete.

The driver is written to timeout (i.e. not hang the system) if the
pending bit should ever fail to clear.

It is also written to never attempt to make a change if the pending
bit is set.

This is what you are seeing. A transition was attempted, it never
completed, and the driver is not happy about it.

The most likely scenario here is the VRM was unable to change
voltage, and that means flaky hardware as it has previously been
able to successfully do so. The reason I pick on the VRM and not
some sort of issue with the HyperTransport fabric is that it is
unlikely anything would still be alive if there was some sort of 
problem coming back from the LDT_STOP.

Assuming the VRM continues to supply the current voltage within 
spec, the system will stay up indefinitely, at the current
voltage and frequency.

The best path to follow would be to investigate warrantee replacement
of the board.

Paul.

             reply	other threads:[~2005-06-07  5:07 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-06-07  5:07 Devriendt, Paul [this message]
2005-07-09 14:29 ` powernow-k8 and stuck change-pending bit John Belmonte
2005-07-26  4:34   ` John Belmonte
  -- strict thread matches above, loose matches on Subject: below --
2005-06-04 20:32 John Belmonte

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=84EA05E2CA77634C82730353CBE3A843028F4CC5@SAUSEXMB1.amd.com \
    --to=paul.devriendt@amd.com \
    --cc=cpufreq@lists.linux.org.uk \
    --cc=john@neggie.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.