Red Hat Bugzilla – Bug 123963
longrun fails with /dev/cpu/0/cpuid: Invalid argument
Last modified: 2015-01-04 17:06:10 EST
Description of problem:
When trying to run longrun on a Sharp MM20 laptop with a Transmeta
Efficeon processor I get the following error:
# longrun -p
longrun: error reading /dev/cpu/0/cpuid Invalid argument
I have the msr and cpuid modules loaded (had to load manualy). Doing
"cat /dev/cpu/0/cpuid" returns:
Running the kernel-2.6.5-1.358 i686 kernel as chosen by the Fedora
Core 2 installer. Kernel arguments past at boot include: acpi=on
i8042.nomux idebus=66 rhgb quiet.
The i8042.nomux argument is needed for the Laptops synaptics touchpad
to function. With-out that argument the touchpad won't respond at all
and doesn't show in dmesg.
In dmesg I see these messages:
CPU: Transmeta Efficeon(tm) Processor TM8000 stepping 04
ACPI: Processor [CPU0] (supports C1 C2 C3)
ACPI: Thermal Zone [THRM] (33 C)
agpgart: Detected Transmeta Efficeon TM8000 series chipset
Those are just some of the relevant ones I thought to mark down.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Install Fedora Core 2 on Sharp MM20 Efficeon laptop
2. modprobe cpuid;modprobe msr
3. run longrun -p or longrun -l
Actual Results: # longrun -p
longrun: error reading /dev/cpu/0/cpuid: Invalid argument
Expected Results: A list of current longrun settings and status.
longrun attempts to read from the offset 0xFFFFFFFFFFFF80860000
using pread(). Looks like a sign extension bug in the longrun code
from a first glance at it - it would have stopped working at the point
we switched to 64bit file offsets when building it.
If there is anyway I can help with getting this fixed let me know.
I'm not a kernel hacker, but I've worked with C code in the past, and
am more than willing to test things on my laptop to get this up and
running (my laptop has volunteered to be a test machine). Would realy
like to get this up and running, these new Efficeon processors seem
pretty slick from what I've been able to play with so far and power
management is the only thing not working.
(Side note, the touchpad (i8042.nomux) things is a kernel specific
thing that is not part of this bug report, I filed a seperate bug
report for it at kernel.org since it is present in the 2.6.6 kernel as
well, just wanted to make that clear)
Ok, I went and downloaded the source files from the debian group and
the patch file. After compling those on the machine, that version of
# ./longrun -p
LongRun Thermal Extensions (LTX): inactive
Current performance window: 0 to 100
Current performance level: 100
LongRun flags: performance
# ./longrun -l
# % MHz Volts usage
0 533 0.850 0.228
14 600 0.925 0.304
36 700 1.000 0.414
64 833 1.150 0.652
100 1000 1.300 1.000
Umm yes it is a bug. Until someone fixes our kernel-utils its broken.
duh, not thinking. for some reason I thought this had been dropped
from kernel-utils. Is there any reason it shouldn't be ? What does
it do that cpufreq doesn't ?
I'm not sure if you are referring to
/sys/devices/system/cpu/cpu0/cpufreq that cpuspeed uses, but that was
going to be the next bug I reported. The cpuspeed utility doesn't
work. It fails with:
Error: Cannot write to speed control file:
Errir: No such file or directy
An ls of the /sys/devices/system/cpu/cpu0/cpufreq directy returns the
# ls /sys/devices/system/cpu/cpu0/cpufreq/
cpuinfo_max_freq scaling_available_governors scaling_governor
scaling_min_freq cpuinfo_min_freq scaling_driver
I thought it was because there was no longrun module driver built with
the kernel, but as I was going back to rebuild the kernel rpm I
noticed that longrun had been compiled into the kernel as oposed to as
a module. So it's there, but it's not working with cpuspeed.
Another small note on the longrun from debian, they added contol over
thermal scaling to the .13 patch, but that doesn't work with my
laptop, it actualy locks it up pretty good. All other functions seem
to work fine though.
If you need another bug open for just the cpuspeed issue, please let
me know. This is what I've figured out so far:
The default FC2 configuration supposedly has USERSPACE chosen, which
would allow 'userspace" as a governor. However,
cat scaling_available_governors does not list userspace, and you
cannot echo userspace > scaling_governor
So the first problem is that 'userspace' should be available.
The second problem is that 'cpuspeed' itself assumes "userspace" is an
available governor without actually checking for it first.
My laptop is a Fujitsu P2110, which has the Transmeta Crusoe chip.
longrun is supposedly compiled into the kernel.
Latest longrun from Debian is 0.9.14 which fixes other bits too. Still
doesn't seem to address the 64bit sign extend bug with pread and 64bit
I've got a local merge of this with kernel-utils-2.4 if you want it Arjan
Using the Debian 0.9.14 patch also fixes longrun on a Toshiba Libretto
L1. I think the fixed version should be included wether or not it is
still buggy with 64bits, it's better than the current one.
this should be fixed in the latest release.
I can't confirm this in Fedora Core 2 I have already migrated to
Fedora Core 3.
I can confirm that longrun does function in Fedora Core 3, so this is
probably fixed in FC2 as well (just can't confirm, sorry).