One would also expect that cache scrubbing requires hardware
support.
You could just write-back invalidate the whole cache
periodically if there is no explicit hardware support
for cache scrubbing. Less efficient, sure :-)
Signed-off-by: doug thompson <[EMAIL PROTECTED]>
Shouldn't you spell your name correctly (with capitalisation)
in the sign off? It being a formal thing and all.
Some spelling and coding style nits:
+/* Valid scrub rates for the K8 hardware memory scrubber. We map
+ maps the scrubbing bandwith to a valid bit pattern. The 'set'
"map maps"
+ Currently, we only do scrubbing of sdram - the caches are assumed
+ to be excercised always by running code and if the scrubber is done
"excercised"
+ search for the bandwith that is eq or gt than the
"bandwith"
And please just write "greater or equal".
+ for (i=0; scrubrates[i].bandwidth != SDRATE_EOD; i++) {
i = 0;
+ /* find the bandwith matching the memory scrubber configuration
"bandwith" again
+ for (i=0; scrubrates[i].bandwidth != SDRATE_EOD; i++) {
i = 0;
+ /* the bit pattern is invalid - we might fix it
+ by applying the slowest scrub rate as this is
+ closest to the valid value, but we do not!
Why not?
+ if (scrubrates[i].bandwidth == SDRATE_EOD) {
+ edac_printk(KERN_WARNING, EDAC_MC,
+ "Invalid sdram scrub control value: %d \n",
Space before the newline.
/* FIXME - stolen from msr.c - the calls in msr.c could be exported */
So fix it :-)
Segher
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
