> Interesting. Is there a way to turn off this throttling, and perhaps
> minimize memory errors via better cooling?
NO! That's the cursed part of this. The DRAM Write Throttle
Control Word has a lock bit (bit 63 addr E7:7) that when set
makes both Read & Write throttle controls read-only. Scandalous!
Worse since I suspect throttling causes crashes, especially SMP.
The need for thermal throttling in a desktop mystifies me.
The 82443BX is a 6.3 Watt part rated for 105'C. It would be
hard to get it that hot in a desktop. I've never felt DRAM
get hot. Perhaps some peripherals/HD's need throttling?
For a laptop, throttling might make good sense. OTOH, it could
be _very_ dangerous in an SMP machine because some semaphore
writes might be held up. The deadlocks might be rare, but deadly.
User code is (ought to be) interrupt, stall and throttle safe.
But not the kernel code. There are PIC's that need acknowledgement,
and semaphores that have to be anatomically set that just might
not be! Plus Linus knows what else! Throttling doesn't know or care
about CLI or kernel mode. It might not even preserve LOCK. The
time-critical kernel code will have to be looked at with a new eye.
Both my Abit BP6 and Josip's fleet of ASUS P-2D's have roughly
the same throttling: It has a very low trigger value, so should
always assumed to be active. When DRAM reads or writes are done
optimized (burst) back-to-back, both will get halted for roughly
1/3 of the time while the full throttle window expires, waiting
for a new window.
Beyond the obvious performance debit, this will increase all
latencies. Assuming x-1-1-1... reads, there will be a 379
busclk wait (~2000 cpuclk, 3.8-5.7 us). For writes at x-2-2-2...,
there will be a 555 bclk wait (~3000 cpuclk, 5.6-8.3 us).
Oddly enough, overclocking reduces the latency, which is perhaps
why I haven't seen any problems, yet non-overclockers have.
Furthermore, I don't run X with it's heavy video card loading.
PCI busmaster packet transfers (eth/HD/vid) >5.8kB will certainly
get stalled, and smaller will be proportionately probable.
Regular code might not reach the maximums need to trigger the stall.
The usually informative Intel website is curiously silent on
thermal throttling, and so is the raucous DejaNews.
In any case, here is my code: compile with `gcc -O2`, run as root:
8<-------------------------------
/* dumpBX 1.0 - Display the Intel 82443BX chipset config regs.
* Copyright 1999 RJ Redelmeier. GPL 2.0
* NO WARRANTEE -- USE AT YOUR OWN RISK
*/
#include <stdio.h>
#include <unistd.h>
#include <asm/io.h>
#include <sys/io.h>
#include <linux/config.h>
main () {
unsigned int j ;
unsigned long i, d[99] ;
iopl(3); /* need this plus root to access ports */
for (i = 0; i < 65; i++ ) {
outl ( 1<<31 | i << 2 , 0xCF8 ) ;
d[i] = inl ( 0x0CFC );
}
iopl(0); /* close security back down */
/* right-to-left HexDumper for little-endian */
for (j = 0; j < 16; j++ ) {
printf ("%3XF: %08X-",j,d[4*j+3]);
printf ( "%08X-", d[4*j+2]);
printf ( "%08X-", d[4*j+1]);
printf ( "%08X :%1X0\n", d[4*j+0], j);
}
}
8<----------------------------------------------------
Look at the line EF: .... :E0 . These are the DRAM
throttle registers. Look particularly at byte E7.
If it is 80h, your lock bit is SET.
FWIW, here's my Abit BP-6:
DWTC = 80003E91 E3FFB6D4
DRTC = 00003E9D 0FF7D32C
Josip has some nice code that automatically decodes these bitfields.
Perhaps he will be so kind as to post it?
Anyone have _any_ ideas on why throttling is needed?
Or whether the kernel can tolerate throttle-stalls (latency)?
-- Robert author `cpuburn` http://users.ev1.net/~redelm
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/