Messages in this thread | | | Date | Thu, 18 Nov 1999 11:08:46 -0800 | From | Robert Redelmeier <> | Subject | RE: DRAM thermal throttling by 440BX chipset |
| |
Brian wrote:
> 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/
| |