test machines; illegal instructions

test machines; illegal instructions

[Jim Paris]

Anyone looking for test machines?  My dorm has three unused SGI
machines sitting in the basement, and I'd be willing to dump a kernel
on them and plug them into the network if anyone here is looking to do
some testing or whatnot.  I don't know much about SGIs, but here's
what they tell me (or what I can gleam from looking at them):

Crimson: IP17, R4000 50 MHz (R4010 FPU), 64MB RAM, GR2-Elan graphics, 
	 two 1.3 gig drives, one currently has Irix 4.0.5
Indigo2: Aqua, IP22, R4000 100 MHz, ~192MB RAM, some beefy graphics
	 card, no drive but I could spare at least a gig (or 60 over NFS)
Indigo2: Purple, IP22, R4400 250 MHz, 128MB RAM, High Impact graphics,
	 one 2 gig drive, CD-ROM, currently has Irix 6.2 or so

----

On an unrelated note, my Vadem Clio project is halted again, this time
with frequent SIGILLs.  In particular, GCC 3.0.1 (and latest CVS)
crashes (in cc1), and 'rm' crashes unless I disable the 'check for
infinite recursion' code.  (the problem also goes away if I add some
debugging printf()s, sometimes).  A cross-gdb on my PC doesn't seem to
like core files, and I haven't had much luck getting gdb to run
natively, so I'm running out of ideas for how to debug this.  Anyone
seen anything similar?  It's quite possibly a buggy cross compiler
just generating buggy binaries (GCC 3.0.1 on the PC, with glibc 2.2.4)
but I thought others were using this compiler just fine.

(Running a somewhat hacked 2.4.5-ish Linux-VR/Linux-MIPS kernel, with
sysmips patches as recommended by Maciej)

-jim

Re: test machines; illegal instructions

[H . J . Lu]

On Wed, Sep 26, 2001 at 10:12:23PM -0400, Jim Paris wrote:
> seen anything similar?  It's quite possibly a buggy cross compiler
> just generating buggy binaries (GCC 3.0.1 on the PC, with glibc 2.2.4)
> but I thought others were using this compiler just fine.

I won't recommend gcc 3.0.1 for mips. My RedHat 7.1 port has everyting
you need for cross/native compiling.


H.J.

Re: test machines; illegal instructions

[Jim Paris]

> > seen anything similar?  It's quite possibly a buggy cross compiler
> 
> I won't recommend gcc 3.0.1 for mips. My RedHat 7.1 port has everyting
> you need for cross/native compiling.

Even with the glibc and fileutils binaries from your port, 'rm' still
either segfaults or gives an illegal instruction, so it's pretty
certain that this is a kernel or CPU issue somehow.  Have you seen
anything like this?  'rm' does work if I compile fileutils with -O0,
but there still seems to be a larger problem at hand.

-jim

Re: test machines; illegal instructions

[Jun Sun]

Jim Paris wrote:
> 
> > > seen anything similar?  It's quite possibly a buggy cross compiler
> >
> > I won't recommend gcc 3.0.1 for mips. My RedHat 7.1 port has everyting
> > you need for cross/native compiling.
> 
> Even with the glibc and fileutils binaries from your port, 'rm' still
> either segfaults or gives an illegal instruction, so it's pretty
> certain that this is a kernel or CPU issue somehow.  Have you seen
> anything like this?  'rm' does work if I compile fileutils with -O0,
> but there still seems to be a larger problem at hand.
> 

If your cpu does not have ll/sc instruction, you might be suffering the famous
sysmips() problem.  The latest kernel should get you going.

There is also FPU emulation bug which may cause this problem, but that only
happens on heavy context switches and FPU usages.

Jun

Re: test machines; illegal instructions

[Ralf Baechle]

On Fri, Oct 05, 2001 at 10:48:15AM -0700, Jun Sun wrote:

> If your cpu does not have ll/sc instruction, you might be suffering the famous
> sysmips() problem.  The latest kernel should get you going.
> 
> There is also FPU emulation bug which may cause this problem, but that only
> happens on heavy context switches and FPU usages.

I've checked in a major bundle of FPU emu fixes last week.  The kernel
fp code should now produce accurate results and handle exceptions and
the Flush to Zero bit as per spec.

I have a load more fp fixes pending which I'll checking as soon as I'm
absolutely convinced they'll do the right thing.

  Ralf

Re: test machines; illegal instructions

[Jun Sun]

[-- Attachment #1: Type: text/plain, Size: 716 bytes --]

On Sun, Oct 07, 2001 at 03:39:10AM +0200, Ralf Baechle wrote:
> On Fri, Oct 05, 2001 at 10:48:15AM -0700, Jun Sun wrote:
> 
> > If your cpu does not have ll/sc instruction, you might be suffering the famous
> > sysmips() problem.  The latest kernel should get you going.
> > 
> > There is also FPU emulation bug which may cause this problem, but that only
> > happens on heavy context switches and FPU usages.
> 
> I've checked in a major bundle of FPU emu fixes last week.  The kernel
> fp code should now produce accurate results and handle exceptions and
> the Flush to Zero bit as per spec.
> 

This particular problem seems still there.  Anybody can try the following
test program on a CPU *without* fpu.

Jun


[-- Attachment #2: kfpe_chk3.c --]
[-- Type: text/plain, Size: 890 bytes --]


/* mipel-linux-gcc -O -o kfpe_chk3 kfpe_chk3.c */

#include <stdio.h>
#include <math.h>
#include <signal.h>
#include <sys/time.h>


double count;
int dummy;
struct itimerval ival;
int icnt=0;

static void alarm_sig_handler(int signum)
{
    int i,j;
    double d;

    if( icnt++ > 500 ){
	icnt = 0;
	/*	printf("count = %f\n", count);*/
    }
    for( i = 0, d = 0.0; d < 1.0; i++, d+=0.1 ){
	count = d;
    }
    setitimer(ITIMER_REAL, &ival, NULL);
    //    alarm(1);
}

int main()
{
    int i,j;
    double d;
    signal(SIGALRM, alarm_sig_handler);

    ival.it_interval.tv_sec = 0;
    ival.it_interval.tv_usec = 0;
    ival.it_value.tv_sec = 0;
    ival.it_value.tv_usec = 10000;
    setitimer(ITIMER_REAL, &ival, NULL);
    //    alarm(1);
    for(;;){
	for( i = 0, d = 0.0; d < 10000.0; i++, d+=0.1 ){
	    count = d;
	}
	signal(SIGALRM, alarm_sig_handler);
    }
    return 0;
}