Jam? Easier to just unplug the fan...

This means, if you don't set auto-gpu and your fans fail when you're not around, firefighters might arrive.
See the example configuration

It's b except you don't need to meddle with gpu-range. auto-gpu and gpu-range "800" will do the trick.
Auto-gpu and gpu-range "400-800" will be even better.

Conman is a kernel hacker, I believe temp-cutoff depends on auto-gpu because he wanted to give the user full control over the hardware and make cgminer bulletproof against devices with failing temperature sensors...  or he just made a mistake nesting all those ifs

Damn the haste  
Post fixed now, sorry guys.

Good gods below, never use intensity >9 with 5xxx or 6xxx cards!
You're lowering your Utility rating processing incredibly long batches of calculations and throwing them out when they've become stale.
Intensity is a fine-tuning parameter, higher does not imply better.
Decrease intensity to 8 or 9 (either will be fine) && RTFM

There are two kinds of safeguards (fan speed configuration is excluded to simulate a catastrophic fan failure):
(1)  soft, speed throttling is supposed to keep the GPU temperature below target temperature:
       + "gpu-engine" : "400-1005",
       + "auto-gpu" : true,
       + "temp-overheat" : "76",
       + "temp-target" : "72",
       + "temp-hysteresis" : "2",

(2)  hard, a measure of last resort to switch the device off before it goes critical:
      + "temp-cutoff" : "81",

Once your card exceeds (temp-target + temp-hysteresis) two things may happen: the fan will speed up to maximum defined fan speed ("gpu-fan" : "52-57") and the core will be throttled down.
Obviously for this to work, auto-gpu and auto-fan need to be enabled. Gpu-fan needs to have a percentage range defined to change the fan speed.

Once your card exceeds temp-overheat two things may happen: the fan will speed up to 100% (we can forget that in our doomsday scenario) and the card will maximally throttle its core down according to gpu-engine.
auto-gpu is mandatory for the engine to be downclocked.
auto-fan is mandatory for the fan to be speeded up to 100%
If gpu-engine is defined as a static value the GPU will only underclock to its stock speed. Otherwise, the card will underclock as far as gpu-engine allows.

temp-cutoff absolutely depends on auto-gpu being set. It does not require a gpu-engine range to be defined.

Normal fan speeds ("auto-fan" : true, "gpu-fan" : "60-65") are only used to prevent the card from hitting temp-overheat. If gpu-fan is set too low and the card hits the temp-overheat threshold you'll definitely hear the fan going in the self-preservation mode.


Examples: (ver 1.0.42a)
"auto-gpu" : false, "auto-fan" : false - your card will burn if it exceeds critical temperature. All protections are inactive.
"auto-gpu" : true, "gpu-engine" : "942", "auto-fan" : false - the card will start throttling core speed on exceeding (temp-target + temp-hysteresis). On exceeding temp-overheat the core will be throttled down to its stock speed. On exceeding "temp-cutoff" mining threads will be disabled. The fan will keep steady on temp-overheat.
"auto-gpu" : true, "gpu-engine" : "400-942", "auto-fan" : false - as in previous example, except on exceeding temp-overheat core will be throttled down to 400MHz.

"auto-gpu" : false, "auto-fan" : true - your card will burn on catastrophic fan failure. The fan will speed up to 100% on temp-overheat.
"auto-gpu" : true, "gpu-engine" : "942", "auto-fan" : true, "gpu-fan" : "60" - the card will start throttling core speed on exceeding (temp-target + temp-hysteresis). On exceeding temp-overheat the core will be throttled down to its stock speed and the fan will speed up to 100%.  On exceeding "temp-cutoff" mining threads will be disabled.
"auto-gpu" : true, "gpu-engine" : "942", "auto-fan" : true, "gpu-fan" : "55-65" - as in previous example, except on exceeding (temp-target + temp-hysteresis), the card will start throttling core speed and will start raising the fan speed up to 65%.

Precisely.
This fact seems to be oftentimes overlooked when users go only for MHash/s in their GPU tweaking.
If your pool server is constantly showing a significantly lower MHash/s estimate then what your miner tells you, consider dropping intensity a notch.
Using intensity 9 for low-to-medium class 200MHash/s GPUs is already too much, they really benefit from 8.

...or your account might get locked out due to the "anti-money-laundering" procedures, a.k.a. user-harassment procedures.
Eventually you'll regain access but additional costs may be necessary to get the required paperwork translated/notarized).
Personally, I wouldn't store 5 Bitcoins at MtGox... by definition, exchanges are not meant for storage.

Cypherdoc, you got a kill-a-watt there?
Did the hash rate budge an inch when you went from 0 powertune to +20%? Did the temps rise?
The reason I'm asking is, some cards will just lie about powertune status. My asus reports success with every powertune value but clearly ignores it.

Impossible.
An FPGA is just that - Field-Programmable device, meaning that the end user can reprogram it at leisure.
Please name one DRM scheme which has not been trivially broken.

Begging your pardon, my post was clearly targeted at someone else but since you decided to hop in:

Some people mine with their nVidia cards - doesn't mean they should either. That's all I have to say in regards to 40nm VLIW4 cards.

There, without knowing what you just said, you said it.
Windows is a decent everyday OS.
Serious bitcoin mining, however, is much simpler, easier, and less resource-intensive using a leaner, task-oriented OS like your favourite Linux flavor.

What good do automatic updates, insane amounts of background housekeeping stuff, the indexing service, or wide open NETBIOS ports do you for bitcoin mining purposes?
How suitable for mining are all those default Power Management options? How useful are System Restore and Shadow Files?
For all those useless (from mining POV) features you don't even get a functional Remote Desktop server...
...and worst of all, you have to dole out money for the doubtful pleasure of installing Windows on your mining rig.
Insanity.

Ahhh... I stand corrected

ASUS F1A75-V EVO has three PCIE slots.
Still, the board and APU are more expensive and far less flexible than the epic MSI 890fxa-gd70 and a Sempron 145.
The strongest Llano is still weaker than a hd 6570 which itself is by no means a card suitable for mining.
Why bother?

Your point being?
Those APUs do support OpenCL but there are no good boards for them - being targeted at the econo crowd, the mobos are low-cost microATX devices.
It makes no sense whatsoever to use one in a mining rig, especially since the integrated GPU is pathetically weak.

What the frak?
You're suppposed to flash your GPU bios, not the one on your mobo...
Try the search button, this subject was discussed many a time.

Also, while I hate to discourage you, your having made this mistake tells me you should probably not flash anything until you have done your research.
RTFM first, understand it, then flash. You're risking your hardware otherwise.

The OCZ ZT 750 is a very decent PSU. Bronze certified, fully modular unit, is this the one?
According to the load table, it can deliver up to 744 Watts on the 12V rail. I estimate the total PSU load at no more than 500W. It should run just fine.
The energy consumption will be even smaller if you underclock the memory. You know that memory speed can be lowered to 150..300MHz on most cards without affecting the hashing speed, right?

A good idea. An even better one would be going with the top-of-the-line mining card, the 5970.

Useful info here, see Performance tweaking.

It's obvious that CPU miners require a whole damned lot of getworks to mercifully complete one before it's gone stale.
I just wish to see them shot. Either you are able to achieve reasonable efficiency or the pools aren't interested in talking to you.
My guess is "reasonable" could be as low as 10% to allow for really slow GPUs.

OTOH, it's not that easy for one pool to fight against botnets - the owners retaliated to previous attempts with DDoS attacks which they can freely perform at will.
We'd need a coalition of major pools setting a deadline and removing CPU-mining support "for the sake of server loads", without even explicitly mentioning botnets.
Remember that cyber-thugs are still nothing more than thugs when push comes to shove.