* Re: efficeon and longrun
2004-11-28 23:59 efficeon and longrun Ralph Metzler
@ 2004-11-29 1:11 ` dean gaudet
2004-11-30 0:01 ` H. Peter Anvin
1 sibling, 0 replies; 5+ messages in thread
From: dean gaudet @ 2004-11-29 1:11 UTC (permalink / raw)
To: Ralph Metzler; +Cc: linux-kernel
On Mon, 29 Nov 2004, Ralph Metzler wrote:
> I recently got a Sharp MP70G with a 1.6 GHz efficeon processor
> and have some questions regarding longrun support. I am using
> longrun-0.9-15 and kernel 2.6.10-rc2.
>
> In arch/i386/kernel/cpu/proc.c the kernel seems to check bit 3
> for the lrti capability, longrun.c checks bit2.
bit 3 is the correct bit for lrti... this is one of the few things we
actually have in our scant public docs
<http://www.transmeta.com/crusoe_docs/Crusoe_CPUID_5-7-02.pdf>, see page
6.
the kernel appears to check the right bit, but the debian userland longrun
tool doesn't... it probably hasn't mattered until now because many crusoe
with LRTI also have bit 2 set (bit 2 isn't documented, sorry).
> Are thermal extensions different on the efficeon compared to the crusoe?
> No matter what I choose (between 0 and 7) the level field in the ATM
> register is always 0.
in theory they're backward compatible -- i've actually been using a
longrun executable compiled years ago on crusoe and never bothered
recompiling it on efficeon. but there are definitely some quirks -- and
the quirks appear to interfere poorly with the debian longrun-0.9-15
package. (i bet i'm using a longrun.c which is old enough to pre-date
lrti...)
the tables defined for crusoe include information that's meaningless on
efficeon -- crusoe has two memory controllers, and only one clock domain
for the entire processor. when crusoe is varying the frequency it also
stops/starts the memory bus and possibly runs memory at different rates --
the longrun tables include all this divisor information.
efficeon has only one memory controller, and two clock domains, one for
the "northbridge" and one for the "core". only the core speed varies
after boot -- the memory clocks at a fixed rate. so the divisors in the
longrun table are essentially meaningless. in fact it looks like they
come back as all zeros... and this causes the debian longrun-0.9-15 some
angst.
below is a patch to debian longrun-0.9-15 -- it passes the "works for me"
test on my development efficeon board, but i don't have a crusoe handy
from remote this weekend to verify it works there. i've placed pre-built
debs at <http://arctic.org/~dean/longrun/> ... if crusoe/efficeon users
can verify them i'll submit my patch upstream (make sure "longrun -l",
"-p" and "-s low hi" work).
> Are there any new efficeon features not yet supported in the kernel or
> the longrun utility? Is there any register information available
> anywhere? I looked on the transmeta pages but did not find anything
> about this.
we suck at publishing this stuff (it makes it out to our customers, but
not out for general consumption). i've no clue where it's all linked
from, but google finds a bunch of stuff -- try a search for "crusoe_docs
site:transmeta.com". there's nothing apparently recent there though.
aside from the efficeon kernel patch i submitted (it's in 2.6.10-rc2, and
i think -rc1) there aren't any efficeon-specific features that i think
need supporting. there's tweaking you could do -- but it's mostly
userland (i.e. gcc -msse2 -mfpmath=sse).
> The BIOS also allows one to select C4 as possible power level,
> /proc/acpi/processor/CPU0/power only offers C1, C2 and C3.
>
> I ask because under Windows, if nothing is running, the fan will
> stay off. Under Linux it is turning on about every two minutes and
> will then run for about a minute (also with everything turned off, and
> about every daemon shut down).
maybe try building your kernel with HZ=100 instead of default 1000? maybe
at HZ=1000 it wakes up just enough to cross some unfortunate power
threshold. my next suggestion beyond that would be to see if ext2 and/or
noflushd do anything... i don't know if it's still true, but ext3 used to
cause sync's every 5s... and didn't interact well with noflushd.
-dean
diff -ru longrun-0.9/debian/changelog longrun-0.9.dg1/debian/changelog
--- longrun-0.9/debian/changelog 2004-11-29 00:43:18.000000000 -0800
+++ longrun-0.9.dg1/debian/changelog 2004-11-29 00:39:46.000000000 -0800
@@ -1,3 +1,15 @@
+longrun (0.9-15.dg1) unstable; urgency=low
+
+ * LRTI is bit 3, not bit 2... the old code happens to have worked on
+ many crusoe because they also set bit 2, but this bit is not set on
+ all crusoe, nor is it set on efficeon. (i'm not sure if bit 2 is
+ publically documented).
+ * mhz * millivolt * millivolt power estimation overflows 31-bit
+ signed integer once the clock is fast enough... use double instead.
+ * io_div (and most divisors) are 0 on efficeon, avoid div-by-0.
+
+ -- dean gaudet <dean@arctic.org> Mon, 29 Nov 2004 00:38:13 -0800
+
longrun (0.9-15) unstable; urgency=low
* Fix mistake on man page. Closes: #249866
diff -ru longrun-0.9/longrun.c longrun-0.9.dg1/longrun.c
--- longrun-0.9/longrun.c 2004-11-29 00:43:18.000000000 -0800
+++ longrun-0.9.dg1/longrun.c 2004-11-29 00:42:23.000000000 -0800
@@ -32,6 +32,7 @@
#include <string.h>
#include <sys/io.h>
#include <sys/sysmacros.h>
+#include <locale.h>
#define __USE_UNIX98 /* for pread/pwrite */
#define __USE_FILE_OFFSET64 /* we should use 64 bit offset for pread/pwrite */
#include <unistd.h>
@@ -68,7 +69,7 @@
#define CPUID_TMx86_PROCESSOR_INFO 0x80860001
#define CPUID_TMx86_LONGRUN_STATUS 0x80860007
#define CPUID_TMx86_FEATURE_LONGRUN(x) ((x) & 0x02)
-#define CPUID_TMx86_FEATURE_LRTI(x) ((x) & 0x04)
+#define CPUID_TMx86_FEATURE_LRTI(x) ((x) & 0x08)
/* Advanced Thermal Management */
#define LR_NORTHBRIDGE "/proc/bus/pci/00/00.0"
@@ -242,21 +243,23 @@
{
int max;
int junk;
- int max_voltage, max_mhz, max_power;
+ int max_voltage, max_mhz;
+ double max_power;
read_msr(MSR_TMx86_LRTI_READOUT, &junk, &max);
write_msr(MSR_TMx86_LRTI_READOUT, 0, max);
read_msr(MSR_TMx86_LRTI_VOLT_MHZ, &max_mhz, &max_voltage);
- max_power = max_mhz * max_voltage * max_voltage;
+ max_power = ((double)max_mhz * max_voltage) * max_voltage;
printf(_("# %% MHz Volts usage SDR DDR PCI\n"));
int i;
for (i = max; i >= 0; i--)
{
- int percent, mhz, voltage, power;
+ int percent, mhz, voltage;
+ double power;
int ddr_mem_div, sdr_mem_div, ddr_freq, sdr_freq;
int io_div;
write_msr(MSR_TMx86_LRTI_READOUT, i, max);
@@ -267,9 +270,9 @@
read_msr(MSR_TMx86_LRTI_VOLT_MHZ, &mhz, &voltage);
printf(_("%5d %6.3f "), mhz, (voltage / 1000.0));
- power = mhz * voltage * voltage;
+ power = ((double)mhz * voltage) * voltage;
- printf(_("%6.3f "), ((float) power) / max_power);
+ printf(_("%6.3f "), ((double) power) / max_power);
// TODO: Watch for zeros
read_msr(MSR_TMx86_LRTI_DIV_MEM, &sdr_mem_div, &ddr_mem_div);
@@ -289,9 +292,13 @@
printf(_("%4d %4d "), sdr_freq, ddr_freq);
- // TODO: Watch for zeros
read_msr(MSR_TMx86_LRTI_DIV_IO, &io_div, &junk);
- printf(_("%4d\n"), mhz / io_div);
+ if (io_div) {
+ printf(_("%4d\n"), mhz / io_div);
+ }
+ else {
+ printf("%4s\n", "--");
+ }
/*
// Most of the rest of these flags don't appear too interesting
^ permalink raw reply [flat|nested] 5+ messages in thread