longrun broken on RH8?

[Des Johnston]

Is the longrun utility broken on RH8? It was working fine for
me on an RH73 installation on a Sony Vaio C1VE, now I find
after upgrading to RH8:

longrun: error reading /dev/cpu/0/cpuid: Invalid argument

The msr and cpuid modules are loaded and the entries in /dev/cpu/0/
seem to have correct permissions.

The (2.4.19) kernel was compiled as a Crusoe kernel,
but it also happened with the generic install 2.4.18-14 kernel.

Any advice appreciated.

Des Johnston

[Brett E. Dufault]

If you do a 'modprobe cpuid', does /dev/cpu/0/cpuid start working? If so,
try adding the following line to /etc/modules.conf:

alias char-major-203 cpuid

That does the trick on a P-III w/ RH 8.0 and the stock 2.4.18-14 kernel, so
hopefully it'll work for your Crusoe.

HTH!
--Brett

[Des Johnston]

Thanks for the suggestion Brett - but it's still broken ... :(

>
> If you do a 'modprobe cpuid', does /dev/cpu/0/cpuid start working? If so,
> try adding the following line to /etc/modules.conf:
>

Loading and unloading the msr and cpuid by hand still gives the error

longrun: error reading /dev/cpu/0/cpuid: Invalid argument

when longrun is run. If I add:

> alias char-major-203 cpuid
>

(and alias char-major-202 msr) the modules will autoload, but the error
remains. If I cat /dev/cpu/0/cpuid I get something back, so the device
seems to be really there.

Des Johnston

[Björn Rabenstein]

Des Johnston wrote:

> Loading and unloading the msr and cpuid by hand still gives the error
>
> longrun: error reading /dev/cpu/0/cpuid: Invalid argument
>
> when longrun is run. If I add:
>
>> alias char-major-203 cpuid
>>
>
> (and alias char-major-202 msr) the modules will autoload, but the error
> remains. If I cat /dev/cpu/0/cpuid I get something back, so the device
> seems to be really there.

I have fixed the bug. Probably this is a problem with signed and
unsigned longs and the __off_t being converted to 64bit somewhere. The
relevant output line from strace:

pread(3, 0xbffff5c0, 16, 13835047131041628160) = -1 EINVAL (Invalidargument)
^^^^^^^^^^^^^^^^^^^^^
This is supposed to be 0x80860000.

I have fiddled around a little bit resulting in the following patch. I
am not quite an expert in this area, so I don't know if this is the
most elegant or correct way, but it seems to work now. I have tried to send
this to the author of the program, but his e-mail address at Transmeta is
not working any longer...

diff -ruN longrun-orig/longrun.c longrun/longrun.c
--- longrun-orig/longrun.c 2001-02-14 11:51:44.000000000 +0100
+++ longrun/longrun.c 2002-10-17 21:40:05.000000000 +0200
@@ -33,6 +33,7 @@
#include <sys/io.h>
#include <sys/sysmacros.h>
#define __USE_UNIX98 /* for pread/pwrite */
+#define __USE_FILE_OFFSET64
#include <unistd.h>

#define MSR_DEVICE "/dev/cpu/0/msr"
@@ -139,7 +140,7 @@
}

/* note: if an output is NULL, then don't set it */
-void read_msr(long address, int *lower, int *upper)
+void read_msr(unsigned long address, int *lower, int *upper)
{
uint32_t data[2];

@@ -151,7 +152,7 @@
if (upper) *upper = data[1];
}

-void write_msr(long address, int lower, int upper)
+void write_msr(unsigned long address, int lower, int upper)
{
uint32_t data[2];

@@ -164,7 +165,7 @@
}

/* note: if an output is NULL, then don't set it */
-void read_cpuid(long address, int *eax, int *ebx, int *ecx, int *edx)
+void read_cpuid(unsigned long address, int *eax, int *ebx, int *ecx, int
*edx)
{
uint32_t data[4];

--
Björn Rabenstein
[PGP-ID] 0x3ADA0C25
[email] b.rabe...@gmx.de
[WWW] http://rabenstein.dyndns.biz

[jason]

I've been having the exact same problem and have tried to apply your
patch by copying it and executing the command patch -p1 ../lonrun_diff

but this produces the error:
patching file longrun.c
patch: **** malformed patch at line 10: @@ -33,6 +33,7 @@

am I doing something wrong?

cheers,
Jason

Björn Rabenstein <b.rabe...@gmx.de> wrote in message news:<aon8kv$nujt4$1...@ID-52101.news.dfncis.de>...

[Scar E.]

"Brett E. Dufault" <bduf...@ehugin.NO.SPAM.PLEASE.com> wrote in message news:<ctlp9.44616$hb4.10270@sccrnsc02>...

Brett,

the problem is, something is wrong with glibc 2.2.93 that shiped with
rh-8.0

the PREAD(..) function returns an error 22 (EINVAL) or Invalid Ags.
then the prog aborts..

I fixed longrun by compiling and linking statically with the older
glibc 2.2.5 (or equiv) from a redhat 6.2 machine.

I can mail you a statically linked version if you need it...

-scar

[Brett E. Dufault]

On Tuesday 22 October 2002 04:09 am, Scar E. wrote:

> the problem is, something is wrong with glibc 2.2.93 that shiped with
> rh-8.0
>
> the PREAD(..) function returns an error 22 (EINVAL) or Invalid Ags.
> then the prog aborts..
>
> I fixed longrun by compiling and linking statically with the older
> glibc 2.2.5 (or equiv) from a redhat 6.2 machine.
>
> I can mail you a statically linked version if you need it...

Appreciate the offer, Scar E, but I don't need longrun myself -- I only
hopped into the thread to see if I could give Des a hand. (He's the one
with the cool Transmeta CPU...I've just got some grotty old PIII/Athlon
boxes. :-) Thanks though!

Cheers!
--Brett