Bug 123963 - longrun fails with /dev/cpu/0/cpuid: Invalid argument
longrun fails with /dev/cpu/0/cpuid: Invalid argument
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: kernel-utils (Show other bugs)
2
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Dave Jones
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-05-22 00:34 EDT by David A. Cafaro
Modified: 2015-01-04 17:06 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-01-10 20:23:52 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description David A. Cafaro 2004-05-22 00:34:24 EDT
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:
 GenuMx86ineT$     /

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):
kernel-utils-2.4-9.1.131

How reproducible:
Always

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.

Additional info:
Comment 1 Alan Cox 2004-05-22 11:16:06 EDT
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.
Comment 2 David A. Cafaro 2004-05-22 13:48:01 EDT
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)
Comment 3 David A. Cafaro 2004-05-22 22:47:43 EDT
New update!

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 works.

http://packages.debian.org/unstable/utils/longrun.html
Files used:
longrun_0.9.orig.tar.gz
longrun_0.9-13.diff.gz

Results:

# ./longrun -p
LongRun: disabled
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
Comment 4 Alan Cox 2004-05-23 07:16:27 EDT
Umm yes it is a bug. Until someone fixes our kernel-utils its broken.
Comment 5 Dave Jones 2004-05-23 07:24:06 EDT
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 ?
Comment 6 David A. Cafaro 2004-05-23 12:53:33 EDT
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:

# cpuspeed
Error: Cannot write to speed control file:
/sys/devices/system/cpu/cpu0/cpufreq/scaling_setspeed
Errir: No such file or directy

An ls of the /sys/devices/system/cpu/cpu0/cpufreq directy returns the
following:

# ls /sys/devices/system/cpu/cpu0/cpufreq/
cpuinfo_max_freq  scaling_available_governors  scaling_governor 
scaling_min_freq  cpuinfo_min_freq  scaling_driver              
scaling_max_freq

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.
Comment 7 Wayne Wylupski 2004-05-31 15:04:46 EDT
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.
Comment 8 Alan Cox 2004-06-14 18:56:46 EDT
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
file offset.

I've got a local merge of this with kernel-utils-2.4 if you want it Arjan
Comment 9 Sven Neuhaus 2004-08-10 17:57:02 EDT
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.
Comment 10 Dave Jones 2004-11-28 16:17:59 EST
this should be fixed in the latest release.
Comment 11 David A. Cafaro 2005-01-23 16:12:22 EST
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).

Note You need to log in before you can comment on or make changes to this bug.