From owner-linux-mips@oss.sgi.com Thu Feb  1 00:38:43 2001
Received:  by oss.sgi.com id <S553996AbRBAIie>;
	Thu, 1 Feb 2001 00:38:34 -0800
Received: from gandalf.physik.uni-konstanz.de ([134.34.144.69]:63757 "EHLO
        gandalf.physik.uni-konstanz.de") by oss.sgi.com with ESMTP
	id <S553979AbRBAIiJ>; Thu, 1 Feb 2001 00:38:09 -0800
Received: from bilbo.physik.uni-konstanz.de [134.34.144.81] 
	by gandalf.physik.uni-konstanz.de with esmtp (Exim 3.12 #1 (Debian))
	id 14OFFl-0007SK-00; Thu, 01 Feb 2001 09:38:05 +0100
Received: from agx by bilbo.physik.uni-konstanz.de with local (Exim 3.12 #1 (Debian))
	id 14OFFk-0001ay-00; Thu, 01 Feb 2001 09:38:04 +0100
Date:   Thu, 1 Feb 2001 09:38:04 +0100
From:   Guido Guenther <guido.guenther@gmx.net>
To:     Calvine Chew <calvine@sgi.com>
Cc:     'linux-mips' <linux-mips@oss.sgi.com>
Subject: Re: Building XFree86 4.0.2?
Message-ID: <20010201093804.A6104@bilbo.physik.uni-konstanz.de>
Mail-Followup-To: Calvine Chew <calvine@sgi.com>,
	'linux-mips' <linux-mips@oss.sgi.com>
References: <43FECA7CDC4CD411A4A3009027999112267E49@sgp-apsa001e--n.singapore.sgi.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <43FECA7CDC4CD411A4A3009027999112267E49@sgp-apsa001e--n.singapore.sgi.com>; from calvine@sgi.com on Thu, Feb 01, 2001 at 02:55:28PM +0800
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing

On Thu, Feb 01, 2001 at 02:55:28PM +0800, Calvine Chew wrote:
> Thanks Guido. Do I need to patch rpm too? Will glibc 2.0.6-7 do or do I need
> 2.1.95?
2.0.6 will do the job fine. You need the glibc rpm along with the
devel-rpm from oss.sgi.com:/pub/linux/mips/glibc/mips-linux. Your
toolchains might be outdated too. Egcs 1.0.3a and binutils 2.8.1 are
known to work.
 -- Guido

From owner-linux-mips@oss.sgi.com Thu Feb  1 01:27:03 2001
Received:  by oss.sgi.com id <S554067AbRBAJ0n>;
	Thu, 1 Feb 2001 01:26:43 -0800
Received: from bastion.power-x.co.uk ([62.232.19.201]:61450 "EHLO
        bastion.power-x.co.uk") by oss.sgi.com with ESMTP
	id <S554019AbRBAJ0U>; Thu, 1 Feb 2001 01:26:20 -0800
Received: from springhead.px.uk.com (IDENT:dg@springhead.px.uk.com [172.16.18.41])
	by bastion.power-x.co.uk (8.9.3/8.9.3) with ESMTP id JAA10262;
	Thu, 1 Feb 2001 09:26:14 GMT
Date:   Thu, 1 Feb 2001 09:26:55 +0000 (GMT)
From:   "Dr. David Gilbert" <gilbertd@treblig.org>
X-Sender:  <dg@springhead.px.uk.com>
To:     Kenneth C Barr <kbarr@MIT.EDU>
cc:     <linux-mips@oss.sgi.com>
Subject: Re: netbooting indy
In-Reply-To: <Pine.GSO.4.30L.0101311648280.22989-100000@home-on-the-dome.mit.edu>
Message-ID: <Pine.LNX.4.30.0102010926190.20992-100000@springhead.px.uk.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing

On Wed, 31 Jan 2001, Kenneth C Barr wrote:

> I finally got bootp/tftp to answer my indy's pleas for an image, but get
> the following behavior (with my own IP addr and server, obviously):
>
> >> boot bootp():/vmlinux


I haven't seen the error you got - however one thing I do differently is
to do

bootp():/vmlinux

without the initial 'boot ' - worth a go?

Dave

-- 
/------------------------------------------------------------------\
| Dr. David Alan Gilbert | Work:dg@px.uk.com +44-161-286-2000 Ex258|
| -------- G7FHJ --------|---------------------------------------- |
| Home: dave@treblig.org            http://www.treblig.org         |
\------------------------------------------------------------------/


From owner-linux-mips@oss.sgi.com Thu Feb  1 01:30:43 2001
Received:  by oss.sgi.com id <S554080AbRBAJae>;
	Thu, 1 Feb 2001 01:30:34 -0800
Received: from mail.sonytel.be ([193.74.243.200]:18136 "EHLO mail.sonytel.be")
	by oss.sgi.com with ESMTP id <S554054AbRBAJaZ>;
	Thu, 1 Feb 2001 01:30:25 -0800
Received: from escobaria.sonytel.be (escobaria.sonytel.be [10.34.80.3])
	by mail.sonytel.be (8.9.0/8.8.6) with ESMTP id KAA21284;
	Thu, 1 Feb 2001 10:27:45 +0100 (MET)
Date:   Thu, 1 Feb 2001 10:27:45 +0100 (MET)
From:   Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com>
To:     "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
cc:     Linux/MIPS Development <linux-mips@oss.sgi.com>
Subject: Re: glibc 2.2 on MIPS
In-Reply-To: <Pine.GSO.3.96.1010104222312.17873C-100000@delta.ds2.pg.gda.pl>
Message-ID: <Pine.GSO.4.10.10102011022400.1855-100000@escobaria.sonytel.be>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing

On Thu, 4 Jan 2001, Maciej W. Rozycki wrote:
>  For binutils 2.10.1 the following fix makes binaries be built as ld.so
> expects.  Other fixes might be needed for 2.10.1 to work at all -- they
> are all available from: 
> ftp://ftp.ds2.pg.gda.pl/pub/macro/SRPMS/binutils-2.10.1-3.src.rpm (or use
> a mirror at: ftp://ftp.rfc822.org/pub/mirror/ftp.ds2.pg.gda.pl/...).

I tried to compile mipsel-binutils using the sources/patches in
mipsel-linux-binutils-2.10.1-3.src.rpm and got the following result:

| gcc -DHAVE_CONFIG_H -I. -I. -I. -D_GNU_SOURCE -I. -I. -I./../include
| -I./../intl -I../intl -g -O2 -W -Wall -c section.c -o section.o
| section.c:571: warning: initialization makes integer from pointer without a cast
| section.c:571: warning: initialization from incompatible pointer type
| section.c:571: warning: initialization from incompatible pointer type
| section.c:571: warning: excess elements in struct initializer
| section.c:571: warning: (near initialization for `bfd_com_section')
| section.c:572: warning: initialization makes integer from pointer without a cast
| section.c:572: warning: initialization from incompatible pointer type
| section.c:572: warning: initialization from incompatible pointer type
| section.c:572: warning: excess elements in struct initializer
| section.c:572: warning: (near initialization for `bfd_und_section')
| section.c:573: warning: initialization makes integer from pointer without a cast
| section.c:573: warning: initialization from incompatible pointer type
| section.c:573: warning: initialization from incompatible pointer type
| section.c:573: warning: excess elements in struct initializer
| section.c:573: warning: (near initialization for `bfd_abs_section')
| section.c:574: warning: initialization makes integer from pointer without a cast
| section.c:574: warning: initialization from incompatible pointer type
| section.c:574: warning: initialization from incompatible pointer type
| section.c:574: warning: excess elements in struct initializer
| section.c:574: warning: (near initialization for `bfd_ind_section')
| section.c: In function `bfd_make_section_anyway':
| section.c:712: structure has no member named `kept_section'
| make[3]: *** [section.lo] Error 1
| make[3]: Leaving directory `/usr/people/geert.nba/mipsel-linux-binutils-2.10.1-3/binutils-2.10.1/bfd'

Should we try mipsel-linux-binutils-2.10.91-1.src.rpm instead?

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven ------------- Sony Software Development Center Europe (SDCE)
Geert.Uytterhoeven@sonycom.com ------------------- Sint-Stevens-Woluwestraat 55
Voice +32-2-7248626 Fax +32-2-7262686 ---------------- B-1130 Brussels, Belgium


From owner-linux-mips@oss.sgi.com Thu Feb  1 01:43:03 2001
Received:  by oss.sgi.com id <S554083AbRBAJmo>;
	Thu, 1 Feb 2001 01:42:44 -0800
Received: from fte036.mc2.chalmers.se ([129.16.41.199]:10256 "EHLO
        fte036.mc2.chalmers.se") by oss.sgi.com with ESMTP
	id <S554078AbRBAJmP>; Thu, 1 Feb 2001 01:42:15 -0800
Received: from fte004 (fte004.mc2.chalmers.se [129.16.41.163])
	by fte036.mc2.chalmers.se (8.9.3 (PHNE_18979)/8.9.3) with ESMTP id KAA06565
	for <linux-mips@oss.sgi.com>; Thu, 1 Feb 2001 10:52:36 +0100 (MET)
Message-ID: <004b01c08c33$e7b42ee0$a3291081@mc2.chalmers.se>
From:   "Erik Aderstedt" <erik@ic.chalmers.se>
To:     <linux-mips@oss.sgi.com>
Subject: OSLoadOptions
Date:   Thu, 1 Feb 2001 10:46:51 +0100
Organization: Solid State Electronics Laboratory
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2014.211
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2014.211
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing

Hi!

I'm using kernel 2.4.0-test3 from the SimpleLinux dist on an
Indy w/ R4400SC, booting using DHCP on an x86 RedHat 6.1
box. Right now the boot is completely unattended, I just turn on the Indy
and a few seconds later I'm at the single user bash prompt. To get further
than this, I would like to pass command line options to the kernel at boot,
and have tried setting the OSLoadOptions PROM variable.

The problem is that the kernel seems to be passed the string
'OSLoadOptions=<my kernel boot options>', instead of just the
boot options. At least that is what is indicated by the line

Kernel command line: OSLoadOptions=init=/sbin/simpleinit

during boot. At the end of this mail is a clunky patch that fixes this, but
I'm not sure if this is the right way to go about it.

/Erik
erik@ic.chalmers.se

Patch to linux/arch/mips/arc/cmdline.c of 2.4.0

37c37
<       int actr, i;
---
>       int actr, i, offset;
48a49
>           offset = (!strncmp(prom_argv[actr], "OSLoadOptions=",14)?14:0;
50,51c51,52
<               strcpy(cp, prom_argv[actr]);
<               cp += strlen(prom_argv[actr]);
---
>               strcpy(cp, prom_argv[actr] + offset);
>               cp += strlen(prom_argv[actr] + offset);



From owner-linux-mips@oss.sgi.com Thu Feb  1 02:29:34 2001
Received:  by oss.sgi.com id <S554081AbRBAK3Z>;
	Thu, 1 Feb 2001 02:29:25 -0800
Received: from gandalf.physik.uni-konstanz.de ([134.34.144.69]:37646 "EHLO
        gandalf.physik.uni-konstanz.de") by oss.sgi.com with ESMTP
	id <S553953AbRBAK3N>; Thu, 1 Feb 2001 02:29:13 -0800
Received: from bilbo.physik.uni-konstanz.de [134.34.144.81] 
	by gandalf.physik.uni-konstanz.de with esmtp (Exim 3.12 #1 (Debian))
	id 14OGzE-0007lq-00; Thu, 01 Feb 2001 11:29:08 +0100
Received: from agx by bilbo.physik.uni-konstanz.de with local (Exim 3.12 #1 (Debian))
	id 14OGzD-0001js-00; Thu, 01 Feb 2001 11:29:07 +0100
Date:   Thu, 1 Feb 2001 11:29:07 +0100
From:   Guido Guenther <guido.guenther@gmx.net>
To:     Erik Aderstedt <erik@ic.chalmers.se>
Cc:     linux-mips@oss.sgi.com
Subject: Re: OSLoadOptions
Message-ID: <20010201112907.A6581@bilbo.physik.uni-konstanz.de>
Mail-Followup-To: Erik Aderstedt <erik@ic.chalmers.se>,
	linux-mips@oss.sgi.com
References: <004b01c08c33$e7b42ee0$a3291081@mc2.chalmers.se>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <004b01c08c33$e7b42ee0$a3291081@mc2.chalmers.se>; from erik@ic.chalmers.se on Thu, Feb 01, 2001 at 10:46:51AM +0100
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing

On Thu, Feb 01, 2001 at 10:46:51AM +0100, Erik Aderstedt wrote:
[..snip..] 
> The problem is that the kernel seems to be passed the string
> 'OSLoadOptions=<my kernel boot options>', instead of just the
> boot options. At least that is what is indicated by the line
> 
> Kernel command line: OSLoadOptions=init=/sbin/simpleinit
> 
> during boot. At the end of this mail is a clunky patch that fixes this, but
> I'm not sure if this is the right way to go about it.
Could you do a "diff -u" - it makes things far easier to read.
Doesn't cmdline.c ignore OSLoadOptions along with the other prom
variables?  cmdline.c in 2.4.0pre9:

static char *ignored[] = {
       "ConsoleIn=",
        "ConsoleOut=",
        "SystemPartition=", 
        "OSLoader=",
        "OSLoadPartition=",
        "OSLoadFilename=",
        "OSLoadOptions="
};

One can easily remove OSLoadOptions from the above list, but then one has
to make sure it is still possible to override the OSLoadOptions with the
PROMS boot command(this makes parsing more complex I think).
 -- Guido

From owner-linux-mips@oss.sgi.com Thu Feb  1 03:16:24 2001
Received:  by oss.sgi.com id <S554090AbRBALQF>;
	Thu, 1 Feb 2001 03:16:05 -0800
Received: from noose.gt.owl.de ([62.52.19.4]:15121 "HELO noose.gt.owl.de")
	by oss.sgi.com with SMTP id <S554100AbRBALPz>;
	Thu, 1 Feb 2001 03:15:55 -0800
Received: by noose.gt.owl.de (Postfix, from userid 10)
	id ACF1A802; Thu,  1 Feb 2001 12:15:40 +0100 (CET)
Received: by paradigm.rfc822.org (Postfix, from userid 1000)
	id C6813EE9C; Thu,  1 Feb 2001 12:02:52 +0100 (CET)
Date:   Thu, 1 Feb 2001 12:02:52 +0100
From:   Florian Lohoff <flo@rfc822.org>
To:     "Dr. David Gilbert" <gilbertd@treblig.org>
Cc:     linux-mips@oss.sgi.com
Subject: Re: netbooting indy
Message-ID: <20010201120252.C3784@paradigm.rfc822.org>
References: <Pine.GSO.4.30L.0101311648280.22989-100000@home-on-the-dome.mit.edu> <Pine.LNX.4.30.0102010926190.20992-100000@springhead.px.uk.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <Pine.LNX.4.30.0102010926190.20992-100000@springhead.px.uk.com>; from gilbertd@treblig.org on Thu, Feb 01, 2001 at 09:26:55AM +0000
Organization: rfc822 - pure communication
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing

On Thu, Feb 01, 2001 at 09:26:55AM +0000, Dr. David Gilbert wrote:
> On Wed, 31 Jan 2001, Kenneth C Barr wrote:
> 
> > I finally got bootp/tftp to answer my indy's pleas for an image, but get
> > the following behavior (with my own IP addr and server, obviously):
> >
> > >> boot bootp():/vmlinux

This uses "sash" and says sash to "bootp"

> I haven't seen the error you got - however one thing I do differently is
> to do
> 
> bootp():/vmlinux
> 
> without the initial 'boot ' - worth a go?

This bootps directly from the prom

Flo
-- 
Florian Lohoff                  flo@rfc822.org             +49-5201-669912
     Why is it called "common sense" when nobody seems to have any?


From owner-linux-mips@oss.sgi.com Thu Feb  1 03:16:24 2001
Received:  by oss.sgi.com id <S554104AbRBALQE>;
	Thu, 1 Feb 2001 03:16:04 -0800
Received: from boco.fee.vutbr.cz ([147.229.9.11]:47883 "EHLO boco.fee.vutbr.cz")
	by oss.sgi.com with ESMTP id <S554090AbRBALPe>;
	Thu, 1 Feb 2001 03:15:34 -0800
Received: from fest.stud.fee.vutbr.cz (fest.stud.fee.vutbr.cz [147.229.9.16])
	by boco.fee.vutbr.cz (8.11.2/8.11.2) with ESMTP id f11BFSo55107
	(using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK)
	for <linux-mips@oss.sgi.com>; Thu, 1 Feb 2001 12:15:29 +0100 (CET)
Received: (from xjezda00@localhost)
	by fest.stud.fee.vutbr.cz (8.11.2/8.11.2) id f11BFSh03040
	for linux-mips@oss.sgi.com; Thu, 1 Feb 2001 12:15:28 +0100 (CET)
Date:   Thu, 1 Feb 2001 12:15:28 +0100
From:   David Jez <dave.jez@seznam.cz>
To:     linux-mips@oss.sgi.com
Subject: Re: fsck problem - version of ext2fs utils
Message-ID: <20010201121528.A3010@stud.fee.vutbr.cz>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing


Hi,

>Has anyone seen problems with fsck on the latest 2.4.0 kernel ?
>My filesystem gets corrupted from time to time when I use the latest
>2.4.0 kernel.
OK, you writes that you have this problems with 2.4.0 kernel.
my ask: have you got newer version of ext2fs utils (1.19)?

read file /usr/src/linux-2.4.0/Documentation/Changes

regards
-- 
-------------------------------------------------------
  David "Dave" Jez                Brno, CZ, Europe
 E-mail: dave.jez@seznam.cz
PGP key: finger xjezda00@fest.stud.fee.vutbr.cz
---------=[ ~EOF ]=------------------------------------

From owner-linux-mips@oss.sgi.com Thu Feb  1 04:17:44 2001
Received:  by oss.sgi.com id <S553807AbRBAMRe>;
	Thu, 1 Feb 2001 04:17:34 -0800
Received: from mx.mips.com ([206.31.31.226]:32216 "EHLO mx.mips.com")
	by oss.sgi.com with ESMTP id <S553798AbRBAMRR>;
	Thu, 1 Feb 2001 04:17:17 -0800
Received: from newman.mips.com (ns-dmz [206.31.31.225])
	by mx.mips.com (8.9.3/8.9.0) with ESMTP id EAA29682;
	Thu, 1 Feb 2001 04:16:41 -0800 (PST)
Received: from copfs01.mips.com (copfs01 [192.168.205.101])
	by newman.mips.com (8.9.3/8.9.0) with ESMTP id EAA02779;
	Thu, 1 Feb 2001 04:16:38 -0800 (PST)
Received: from mips.com (copsun17 [192.168.205.27])
	by copfs01.mips.com (8.9.1/8.9.0) with ESMTP id NAA01559;
	Thu, 1 Feb 2001 13:16:27 +0100 (MET)
Message-ID: <3A79539B.ADE4BCAD@mips.com>
Date:   Thu, 01 Feb 2001 13:16:27 +0100
From:   Carsten Langgaard <carstenl@mips.com>
X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To:     David Jez <dave.jez@seznam.cz>
CC:     linux-mips@oss.sgi.com
Subject: Re: fsck problem - version of ext2fs utils
References: <20010201121528.A3010@stud.fee.vutbr.cz>
Content-Type: text/plain; charset=iso-8859-15
Content-Transfer-Encoding: 7bit
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing

David Jez wrote:

> Hi,
>
> >Has anyone seen problems with fsck on the latest 2.4.0 kernel ?
> >My filesystem gets corrupted from time to time when I use the latest
> >2.4.0 kernel.
> OK, you writes that you have this problems with 2.4.0 kernel.
> my ask: have you got newer version of ext2fs utils (1.19)?

No, thanks for pointing this out.
Do you have a set of binaries, little endian aswell as bigendian ?

>
> read file /usr/src/linux-2.4.0/Documentation/Changes
>
> regards
> --
> -------------------------------------------------------
>   David "Dave" Jez                Brno, CZ, Europe
>  E-mail: dave.jez@seznam.cz
> PGP key: finger xjezda00@fest.stud.fee.vutbr.cz
> ---------=[ ~EOF ]=------------------------------------

--
_    _ ____  ___   Carsten Langgaard   Mailto:carstenl@mips.com
|\  /|||___)(___   MIPS Denmark        Direct: +45 4486 5527
| \/ |||    ____)  Lautrupvang 4B      Switch: +45 4486 5555
  TECHNOLOGIES     2750 Ballerup       Fax...: +45 4486 5556
                   Denmark             http://www.mips.com




From owner-linux-mips@oss.sgi.com Thu Feb  1 04:41:24 2001
Received:  by oss.sgi.com id <S553813AbRBAMlO>;
	Thu, 1 Feb 2001 04:41:14 -0800
Received: from delta.ds2.pg.gda.pl ([153.19.144.1]:2745 "EHLO
        delta.ds2.pg.gda.pl") by oss.sgi.com with ESMTP id <S553801AbRBAMk5>;
	Thu, 1 Feb 2001 04:40:57 -0800
Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id NAA21934;
	Thu, 1 Feb 2001 13:38:24 +0100 (MET)
Date:   Thu, 1 Feb 2001 13:38:24 +0100 (MET)
From:   "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To:     Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com>
cc:     Linux/MIPS Development <linux-mips@oss.sgi.com>
Subject: Re: glibc 2.2 on MIPS
In-Reply-To: <Pine.GSO.4.10.10102011022400.1855-100000@escobaria.sonytel.be>
Message-ID: <Pine.GSO.3.96.1010201122250.17657C-100000@delta.ds2.pg.gda.pl>
Organization: Technical University of Gdansk
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing

On Thu, 1 Feb 2001, Geert Uytterhoeven wrote:

> I tried to compile mipsel-binutils using the sources/patches in
> mipsel-linux-binutils-2.10.1-3.src.rpm and got the following result:
[...]
> | section.c: In function `bfd_make_section_anyway':
> | section.c:712: structure has no member named `kept_section'
> | make[3]: *** [section.lo] Error 1
> | make[3]: Leaving directory `/usr/people/geert.nba/mipsel-linux-binutils-2.10.1-3/binutils-2.10.1/bfd'

 Did you run `make -C bfd headers' after `./configure'?  It llok like you
didn't.

> Should we try mipsel-linux-binutils-2.10.91-1.src.rpm instead?

 It should not matter apart from this one is newer. 

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +


From owner-linux-mips@oss.sgi.com Thu Feb  1 07:19:25 2001
Received:  by oss.sgi.com id <S554054AbRBAPTO>;
	Thu, 1 Feb 2001 07:19:14 -0800
Received: from mail.sonytel.be ([193.74.243.200]:41373 "EHLO mail.sonytel.be")
	by oss.sgi.com with ESMTP id <S553972AbRBAPTB>;
	Thu, 1 Feb 2001 07:19:01 -0800
Received: from escobaria.sonytel.be (escobaria.sonytel.be [10.34.80.3])
	by mail.sonytel.be (8.9.0/8.8.6) with ESMTP id QAA07834;
	Thu, 1 Feb 2001 16:15:09 +0100 (MET)
Date:   Thu, 1 Feb 2001 16:15:08 +0100 (MET)
From:   Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com>
To:     "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
cc:     Linux/MIPS Development <linux-mips@oss.sgi.com>
Subject: Re: glibc 2.2 on MIPS
In-Reply-To: <Pine.GSO.3.96.1010201122250.17657C-100000@delta.ds2.pg.gda.pl>
Message-ID: <Pine.GSO.4.10.10102011611500.1855-100000@escobaria.sonytel.be>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing

On Thu, 1 Feb 2001, Maciej W. Rozycki wrote:
> On Thu, 1 Feb 2001, Geert Uytterhoeven wrote:
> > I tried to compile mipsel-binutils using the sources/patches in
> > mipsel-linux-binutils-2.10.1-3.src.rpm and got the following result:
> [...]
> > | section.c: In function `bfd_make_section_anyway':
> > | section.c:712: structure has no member named `kept_section'
> > | make[3]: *** [section.lo] Error 1
> > | make[3]: Leaving directory `/usr/people/geert.nba/mipsel-linux-binutils-2.10.1-3/binutils-2.10.1/bfd'
> 
>  Did you run `make -C bfd headers' after `./configure'?  It llok like you
> didn't.

Thanks! (BTW, this is the first time ever that I made a cross-compiler and had
to type `make -C bfd headers')

Now it aborts later at:

| /bin/sh ./genscripts.sh . /usr/local/lib sparc-sun-solaris2.6 mipsel-unknown-linux-gnu mipsel-linux "elf32lsmip" "/usr/ccs/lib" elf32lsmip "mipsel-linux"
| ./genscripts.sh: ./emulparams/mipsel-linux.sh: not found
| make[3]: *** [eelf32lsmip.c] Error 1
| make[3]: Leaving directory `/usr/people/geert.nba/mipsel-linux-binutils-2.10.1-3/binutils-2.10.1/ld'

ld/emulparams/ doesn't seem to contain any mipsel-related files.

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven ------------- Sony Software Development Center Europe (SDCE)
Geert.Uytterhoeven@sonycom.com ------------------- Sint-Stevens-Woluwestraat 55
Voice +32-2-7248626 Fax +32-2-7262686 ---------------- B-1130 Brussels, Belgium


From owner-linux-mips@oss.sgi.com Thu Feb  1 07:36:04 2001
Received:  by oss.sgi.com id <S554090AbRBAPfz>;
	Thu, 1 Feb 2001 07:35:55 -0800
Received: from delta.ds2.pg.gda.pl ([153.19.144.1]:51898 "EHLO
        delta.ds2.pg.gda.pl") by oss.sgi.com with ESMTP id <S554067AbRBAPfk>;
	Thu, 1 Feb 2001 07:35:40 -0800
Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id QAA28726;
	Thu, 1 Feb 2001 16:30:48 +0100 (MET)
Date:   Thu, 1 Feb 2001 16:30:48 +0100 (MET)
From:   "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To:     Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com>
cc:     Linux/MIPS Development <linux-mips@oss.sgi.com>
Subject: Re: glibc 2.2 on MIPS
In-Reply-To: <Pine.GSO.4.10.10102011611500.1855-100000@escobaria.sonytel.be>
Message-ID: <Pine.GSO.3.96.1010201162756.17657K-100000@delta.ds2.pg.gda.pl>
Organization: Technical University of Gdansk
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing

On Thu, 1 Feb 2001, Geert Uytterhoeven wrote:

> Now it aborts later at:
> 
> | /bin/sh ./genscripts.sh . /usr/local/lib sparc-sun-solaris2.6 mipsel-unknown-linux-gnu mipsel-linux "elf32lsmip" "/usr/ccs/lib" elf32lsmip "mipsel-linux"
> | ./genscripts.sh: ./emulparams/mipsel-linux.sh: not found
> | make[3]: *** [eelf32lsmip.c] Error 1
> | make[3]: Leaving directory `/usr/people/geert.nba/mipsel-linux-binutils-2.10.1-3/binutils-2.10.1/ld'
> 
> ld/emulparams/ doesn't seem to contain any mipsel-related files.

 Now you didn't run automake in bfd. ;-)  You need to run it in ld as
well.  How about looking at the included spec file? 

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +


From owner-linux-mips@oss.sgi.com Thu Feb  1 07:49:35 2001
Received:  by oss.sgi.com id <S554100AbRBAPt0>;
	Thu, 1 Feb 2001 07:49:26 -0800
Received: from mail.sonytel.be ([193.74.243.200]:30883 "EHLO mail.sonytel.be")
	by oss.sgi.com with ESMTP id <S554081AbRBAPtE>;
	Thu, 1 Feb 2001 07:49:04 -0800
Received: from escobaria.sonytel.be (escobaria.sonytel.be [10.34.80.3])
	by mail.sonytel.be (8.9.0/8.8.6) with ESMTP id QAA09260;
	Thu, 1 Feb 2001 16:48:09 +0100 (MET)
Date:   Thu, 1 Feb 2001 16:48:09 +0100 (MET)
From:   Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com>
To:     "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
cc:     Linux/MIPS Development <linux-mips@oss.sgi.com>
Subject: Re: glibc 2.2 on MIPS
In-Reply-To: <Pine.GSO.3.96.1010201162756.17657K-100000@delta.ds2.pg.gda.pl>
Message-ID: <Pine.GSO.4.10.10102011646500.1855-100000@escobaria.sonytel.be>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing

On Thu, 1 Feb 2001, Maciej W. Rozycki wrote:
> On Thu, 1 Feb 2001, Geert Uytterhoeven wrote:
> > Now it aborts later at:
> > | /bin/sh ./genscripts.sh . /usr/local/lib sparc-sun-solaris2.6 mipsel-unknown-linux-gnu mipsel-linux "elf32lsmip" "/usr/ccs/lib" elf32lsmip "mipsel-linux"
> > | ./genscripts.sh: ./emulparams/mipsel-linux.sh: not found
> > | make[3]: *** [eelf32lsmip.c] Error 1
> > | make[3]: Leaving directory `/usr/people/geert.nba/mipsel-linux-binutils-2.10.1-3/binutils-2.10.1/ld'
> > 
> > ld/emulparams/ doesn't seem to contain any mipsel-related files.
> 
>  Now you didn't run automake in bfd. ;-)  You need to run it in ld as

Thanks!

> well.  How about looking at the included spec file? 

Sorry, I didn't realize you had anything to do besides applying the patches,
configure and make (like I did last time).

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven ------------- Sony Software Development Center Europe (SDCE)
Geert.Uytterhoeven@sonycom.com ------------------- Sint-Stevens-Woluwestraat 55
Voice +32-2-7248626 Fax +32-2-7262686 ---------------- B-1130 Brussels, Belgium


From owner-linux-mips@oss.sgi.com Thu Feb  1 12:35:25 2001
Received:  by oss.sgi.com id <S554169AbRBAUfG>;
	Thu, 1 Feb 2001 12:35:06 -0800
Received: from stereotomy.lineo.com ([64.50.107.151]:37394 "HELO
        stereotomy.lineo.com") by oss.sgi.com with SMTP id <S554162AbRBAUew>;
	Thu, 1 Feb 2001 12:34:52 -0800
Received: from Lineo.COM (localhost.localdomain [127.0.0.1])
	by stereotomy.lineo.com (Postfix) with ESMTP id E42694CB82
	for <linux-mips@oss.sgi.com>; Thu,  1 Feb 2001 13:34:49 -0700 (MST)
Message-ID: <3A79C869.2040001@Lineo.COM>
Date:   Thu, 01 Feb 2001 13:34:49 -0700
From:   Quinn Jensen <jensenq@Lineo.COM>
Organization: Lineo, Inc.
User-Agent: Mozilla/5.0 (X11; U; Linux 2.2.16-9mdk i686; en-US; m18) Gecko/20001107 Netscape6/6.0
X-Accept-Language: en
MIME-Version: 1.0
To:     linux-mips@oss.sgi.com
Subject: NFS root with cache on
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing

Is anyone else having trouble with NFS root on
the 2.4.0 kernel?  It won't come up with the
KSEG0 cache on unless I pepper the network driver
with flush calls.

I'm using the new mips32 mm and cache code with
my own patches to deal with the IDT 334's weird
way bit (it's clear up at bit 12 even though the
cache is only 2k).

Quinn


From owner-linux-mips@oss.sgi.com Thu Feb  1 13:52:26 2001
Received:  by oss.sgi.com id <S554189AbRBAVwR>;
	Thu, 1 Feb 2001 13:52:17 -0800
Received: from sovereign.org ([209.180.91.170]:683 "EHLO lux.homenet")
	by oss.sgi.com with ESMTP id <S554180AbRBAVwB>;
	Thu, 1 Feb 2001 13:52:01 -0800
Received: (from jfree@localhost)
	by lux.homenet (8.11.2/8.11.2/Debian 8.11.2-1) id f11Lq3X01790
	for linux-mips@oss.sgi.com; Thu, 1 Feb 2001 14:52:03 -0700
From:   Jim Freeman <jfree@sovereign.org>
Date:   Thu, 1 Feb 2001 14:52:03 -0700
To:     linux-mips@oss.sgi.com
Subject: Re: mips/CVS vs stock 2.4.1
Message-ID: <20010201145203.A1657@sovereign.org>
References: <20010201135347.A1164@sovereign.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.3.12i
In-Reply-To: <20010201135347.A1164@sovereign.org>; from jfree@sovereign.org on Thu, Feb 01, 2001 at 01:53:47PM -0700
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing

In a merciful moment of remedial tutelage, Ilya kindly pointed out
that using   'cvs update -d'   would more properly sync my tree, thus
invalidating the first point of my previous e-mail.

  [ Apologies - publicly showing/rectifying one's ignorance may
    hurt the pride, but perhaps may be instructive to others ]

Someone may have as simple a fix for the dead/empty dirs in mips' CVS ?

...jfree
========
On Thu, Feb 01, 2001 at 01:53:47PM -0700, Jim Freeman wrote:
...
> Non-mips related directories mips has, but not present in stock 2.4.1
> (all empty, except for CVS-relate overhead - should be trimmed out of CVS?) :
> 
> 	Documentation/networking/ip_masq
> 	arch/arm/boot/tools
> 	arch/ia64/kdb
> 	arch/m68k/boot
> 	arch/m68k/console
> 	arch/ppc/kernel/include
> 	arch/sparc/ap1000
> 	drivers/char/hfmodem
> 	drivers/isdn/teles
> 	drivers/net/soundmodem
> 	drivers/sound/lowlevel
> 	drivers/usb/maps
> 	fs/ext
> 	fs/xiafs
> 	include/asm-arm/arch-a5k
> 	include/asm-arm/arch-vnc
> 	include/asm-sparc/ap1000
> 	net/netbeui
> 	scripts/usb
> 	net/irda/irlpt
> 	net/irda/irobex

From owner-linux-mips@oss.sgi.com Thu Feb  1 16:19:57 2001
Received:  by oss.sgi.com id <S554197AbRBBATg>;
	Thu, 1 Feb 2001 16:19:36 -0800
Received: from f120.law3.hotmail.com ([209.185.241.120]:21517 "EHLO
        hotmail.com") by oss.sgi.com with ESMTP id <S554194AbRBBAT2>;
	Thu, 1 Feb 2001 16:19:28 -0800
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Thu, 1 Feb 2001 16:19:23 -0800
Received: from 24.25.9.1 by lw3fd.law3.hotmail.msn.com with HTTP;	Fri, 02 Feb 2001 00:19:22 GMT
X-Originating-IP: [24.25.9.1]
From:   "James McD" <vile8@hotmail.com>
To:     linux-mips@oss.sgi.com
Subject: console driver for indigo2
Date:   Fri, 02 Feb 2001 00:19:22 
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: <F120dm5UxP9Fekzabtn000001ce@hotmail.com>
X-OriginalArrivalTime: 02 Feb 2001 00:19:23.0106 (UTC) FILETIME=[CB19A420:01C08CAD]
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing

has anyone come up with a console driver for the indigo2 extreme?
If not can anyone give me a pointer where to pick up a null modem
cable for the indigo2's strangely designed serial port? Off list is fine.
_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com


From owner-linux-mips@oss.sgi.com Thu Feb  1 17:46:57 2001
Received:  by oss.sgi.com id <S554024AbRBBBqh>;
	Thu, 1 Feb 2001 17:46:37 -0800
Received: from sgi.SGI.COM ([192.48.153.1]:25436 "EHLO sgi.com")
	by oss.sgi.com with ESMTP id <S554009AbRBBBqU>;
	Thu, 1 Feb 2001 17:46:20 -0800
Received: from sgisgp.singapore.sgi.com ([134.14.84.2]) 
	by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam:
       SGI does not authorize the use of its proprietary
       systems or networks for unsolicited or bulk email
       from the Internet.) 
	via SMTP id RAB03988
	for <linux-mips@oss.sgi.com>; Thu, 1 Feb 2001 17:46:14 -0800 (PST)
	mail_from (calvine@sgi.com)
Received: from sgp-apsa001e--n.singapore.sgi.com by sgisgp.singapore.sgi.com via ESMTP (950413.SGI.8.6.12/930416.SGI)
	for <linux-mips@oss.sgi.com> id JAA16190; Fri, 2 Feb 2001 09:56:15 +0800
Received: by sgp-apsa001e--n.singapore.sgi.com with Internet Mail Service (5.5.2650.21)
	id <1AC4SATX>; Fri, 2 Feb 2001 09:51:30 +0800
Message-ID: <43FECA7CDC4CD411A4A3009027999112267E4A@sgp-apsa001e--n.singapore.sgi.com>
From:   Calvine Chew <calvine@sgi.com>
To:     "'linux-mips'" <linux-mips@oss.sgi.com>
Subject: Where can I find precompiled binaries for XFree86 4.0.2?
Date:   Fri, 2 Feb 2001 09:51:29 +0800 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing

Hello all.

Anyone know where I can grab the above? I am encountering problems with
building my own on Hardhat 5.1. make world looked okay but make install died
trying to make the shared library X11lib.so.6.2~ (ld terminated with signal
6).

Thanks in advance!

Regards...

--
Calvine Chew, Technical Consultant
Technology & Industry Consulting Group (Asia South), SGI.
***************************************************************
Inter spem curamque, timores inter et iras, omnem crede diem tibi
diluxisse supremum: grata superveniet quae sperabitur hora.
http://calvine
***************************************************************





From owner-linux-mips@oss.sgi.com Thu Feb  1 18:28:18 2001
Received:  by oss.sgi.com id <S554207AbRBBC2I>;
	Thu, 1 Feb 2001 18:28:08 -0800
Received: from Sioux.meginc.com ([207.246.76.19]:6418 "EHLO sioux.meginc.com")
	by oss.sgi.com with ESMTP id <S554202AbRBBC1n>;
	Thu, 1 Feb 2001 18:27:43 -0800
Received: from localhost.localdomain (IDENT:brandon@[207.246.76.63])
	by sioux.meginc.com (8.9.3/8.9.1) with SMTP id VAA81615
	for <linux-mips@oss.sgi.com>; Thu, 1 Feb 2001 21:28:31 -0500 (EST)
	(envelope-from bebarker@meginc.com)
From:   Brandon Barker <bebarker@meginc.com>
Date:   Thu, 1 Feb 2001 21:31:17 -0500
X-Mailer: KMail [version 1.1.99]
Content-Type: text/plain;
  charset="iso-8859-1"
To:     "'linux-mips'" <linux-mips@oss.sgi.com>
Subject: OGL for Indy
MIME-Version: 1.0
Message-Id: <01020121311700.01655@localhost.localdomain>
Content-Transfer-Encoding: 8bit
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing

I've recently purchased 2 Indy boxes and wanted to use Linux on them to act 
as a graphics workstation.  However, it seems SGI has not provided us with 
the 3d acc. driver they must have (IRIX driver) so as to allow us to create 
one for XFree86.  This means I may have to buy IRIX, though I would much 
rather use Linux.  Why has SGI not provided the necessary specs/code for 3d 
(open GL in this case?) acceleration?

Brandon

From owner-linux-mips@oss.sgi.com Thu Feb  1 19:22:20 2001
Received:  by oss.sgi.com id <S554209AbRBBDWA>;
	Thu, 1 Feb 2001 19:22:00 -0800
Received: from sovereign.org ([209.180.91.170]:8320 "EHLO lux.homenet")
	by oss.sgi.com with ESMTP id <S554027AbRBBDVg>;
	Thu, 1 Feb 2001 19:21:36 -0800
Received: (from jfree@localhost)
	by lux.homenet (8.11.2/8.11.2/Debian 8.11.2-1) id f123LT901126
	for linux-mips@oss.sgi.com; Thu, 1 Feb 2001 20:21:29 -0700
From:   Jim Freeman <jfree@sovereign.org>
Date:   Thu, 1 Feb 2001 20:21:29 -0700
To:     linux-mips@oss.sgi.com
Subject: mystery files in stock->mips diff
Message-ID: <20010201202129.A1107@sovereign.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.3.12i
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing

The following files are in the mips tree, and not in stock 2.4.1
- but they seem not to be mips-related.  Clues?


	arch/ppc/coffboot/main.c
	arch/ppc/configs/gemini_defconfig
	arch/ppc/kernel/gemini_pci.c
	arch/ppc/kernel/gemini_prom.S
	arch/ppc/kernel/gemini_setup.c
	arch/ppc/mbxboot/vmlinux.lds

	drivers/acpi/hardware/hwcpu32.c
	drivers/acpi/hardware/hwxface.c
	drivers/acpi/ksyms.c

	include/asm-ppc/gemini.h
	include/asm-ppc/gemini_serial.h


...jfree

From owner-linux-mips@oss.sgi.com Thu Feb  1 19:23:30 2001
Received:  by oss.sgi.com id <S554213AbRBBDXU>;
	Thu, 1 Feb 2001 19:23:20 -0800
Received: from gateway-1237.mvista.com ([12.44.186.158]:63481 "EHLO
        hermes.mvista.com") by oss.sgi.com with ESMTP id <S554203AbRBBDXF>;
	Thu, 1 Feb 2001 19:23:05 -0800
Received: from mvista.com (IDENT:jsun@orion.mvista.com [10.0.0.75])
	by hermes.mvista.com (8.11.0/8.11.0) with ESMTP id f123JgI27051;
	Thu, 1 Feb 2001 19:19:42 -0800
Message-ID: <3A7A27D5.C27E3AA5@mvista.com>
Date:   Thu, 01 Feb 2001 19:21:57 -0800
From:   Jun Sun <jsun@mvista.com>
X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14-5.0 i686)
X-Accept-Language: en
MIME-Version: 1.0
To:     linux-mips@oss.sgi.com
Subject: NFS problem - nfs_refresh_inode: inode number mismatch 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing


I use nfs root fs to boot my MIPS box.  However, after several reboots, I
sometimes get the following error message.  Most of the time it seems
harmless, but sometime it seems that /proc may not get mounted.  Does anybody
have an idea?

...
Sending BOOTP requests.... OK
IP-Config: Got BOOTP answer from 10.23.3.2, my address is 10.23.3.17
kmem_create: Forcing size word alignment - nfs_fh
Looking up port of RPC 100003/2 on 10.23.3.2
Looking up port of RPC 100005/2 on 10.23.3.2
VFS: Mounted root (nfs filesystem).
Freeing unused kernel memory: 100k freed
nfs_refresh_inode: inode number mismatch
expected (0x305/0x1d265), got (0x305/0xd0d6)
nfs_refresh_inode: inode number mismatch
expected (0x305/0xd0d6), got (0x305/0x1d265)
...

Jun

From owner-linux-mips@oss.sgi.com Thu Feb  1 19:33:59 2001
Received:  by oss.sgi.com id <S554215AbRBBDdu>;
	Thu, 1 Feb 2001 19:33:50 -0800
Received: from router-100M.swansea.linux.org.uk ([194.168.151.17]:32019 "EHLO
        the-village.bc.nu") by oss.sgi.com with ESMTP id <S554214AbRBBDde>;
	Thu, 1 Feb 2001 19:33:34 -0800
Received: from alan by the-village.bc.nu with local (Exim 2.12 #1)
	id 14OWz8-0005jE-00; Fri, 2 Feb 2001 03:34:06 +0000
Subject: Re: OGL for Indy
To:     bebarker@meginc.com (Brandon Barker)
Date:   Fri, 2 Feb 2001 03:34:04 +0000 (GMT)
Cc:     linux-mips@oss.sgi.com ('linux-mips')
In-Reply-To: <01020121311700.01655@localhost.localdomain> from "Brandon Barker" at Feb 01, 2001 09:31:17 PM
X-Mailer: ELM [version 2.5 PL1]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <E14OWz8-0005jE-00@the-village.bc.nu>
From:   Alan Cox <alan@lxorguk.ukuu.org.uk>
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing

> one for XFree86.  This means I may have to buy IRIX, though I would much 
> rather use Linux.  Why has SGI not provided the necessary specs/code for 3d 
> (open GL in this case?) acceleration?

They have to a few people at least. However you should understand that the
direct render/context switch stuff aside the Indy is just a glorified drawing
machine for solid triangles. Its old. What was in its time awesome technology
is no longer.

Alan


From owner-linux-mips@oss.sgi.com Thu Feb  1 19:50:49 2001
Received:  by oss.sgi.com id <S554217AbRBBDua>;
	Thu, 1 Feb 2001 19:50:30 -0800
Received: from pneumatic-tube.sgi.com ([204.94.214.22]:48451 "EHLO
        pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP
	id <S554214AbRBBDuC>; Thu, 1 Feb 2001 19:50:02 -0800
Received: from sydney.sydney.sgi.com (sydney.sydney.sgi.com [134.14.48.2]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via SMTP id TAA02423
	for <linux-mips@oss.sgi.com>; Thu, 1 Feb 2001 19:59:09 -0800 (PST)
	mail_from (kaos@melbourne.sgi.com)
Received: from kao2.melbourne.sgi.com by sydney.sydney.sgi.com via ESMTP (950413.SGI.8.6.12/930416.SGI)
	 id OAA03192; Fri, 2 Feb 2001 14:49:19 +1100
X-Mailer: exmh version 2.1.1 10/15/1999
From:   Keith Owens <kaos@melbourne.sgi.com>
To:     Jim Freeman <jfree@sovereign.org>
cc:     linux-mips@oss.sgi.com
Subject: Re: mystery files in stock->mips diff 
In-reply-to: Your message of "Thu, 01 Feb 2001 20:21:29 PDT."
             <20010201202129.A1107@sovereign.org> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date:   Fri, 02 Feb 2001 14:48:39 +1100
Message-ID: <3672.981085719@kao2.melbourne.sgi.com>
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing

On Thu, 1 Feb 2001 20:21:29 -0700, 
Jim Freeman <jfree@sovereign.org> wrote:
>The following files are in the mips tree, and not in stock 2.4.1
>- but they seem not to be mips-related.  Clues?

	arch/ppc/coffboot/main.c		del in 2.4.1-pre9
	arch/ppc/configs/gemini_defconfig	del in 2.4.1-pre9
	arch/ppc/kernel/gemini_pci.c		del in 2.4.1-pre9
	arch/ppc/kernel/gemini_prom.S		del in 2.4.1-pre9
	arch/ppc/kernel/gemini_setup.c		del in 2.4.1-pre9
	arch/ppc/mbxboot/vmlinux.lds		del in 2.4.1-pre9

	drivers/acpi/hardware/hwcpu32.c		del in 2.4.1-pre11
	drivers/acpi/hardware/hwxface.c		del in 2.4.1-pre11
	drivers/acpi/ksyms.c			del in 2.4.1-pre9

	include/asm-ppc/gemini.h		del in 2.4.1-pre9
	include/asm-ppc/gemini_serial.h		del in 2.4.1-pre9

All recently deleted from 2.4.x.


From owner-linux-mips@oss.sgi.com Thu Feb  1 20:40:20 2001
Received:  by oss.sgi.com id <S554221AbRBBEkL>;
	Thu, 1 Feb 2001 20:40:11 -0800
Received: from PACIFIC-CARRIER-ANNEX.MIT.EDU ([18.69.0.28]:47378 "HELO MIT.EDU")
	by oss.sgi.com with SMTP id <S554218AbRBBEj4>;
	Thu, 1 Feb 2001 20:39:56 -0800
Received: from GRAND-CENTRAL-STATION.MIT.EDU by MIT.EDU with SMTP
	id AA12457; Thu, 1 Feb 01 23:41:55 EST
Received: from melbourne-city-street.MIT.EDU (MELBOURNE-CITY-STREET.MIT.EDU [18.69.0.45])
	by grand-central-station.MIT.EDU (8.9.2/8.9.2) with ESMTP id XAA25672
	for <linux-mips@oss.sgi.com>; Thu, 1 Feb 2001 23:39:48 -0500 (EST)
Received: from biohazard-cafe.mit.edu (BIOHAZARD-CAFE.MIT.EDU [18.184.0.31])
	by melbourne-city-street.MIT.EDU (8.9.3/8.9.2) with ESMTP id XAA04614
	for <linux-mips@oss.sgi.com>; Thu, 1 Feb 2001 23:39:47 -0500 (EST)
Received: from localhost (kbarr@localhost) by biohazard-cafe.mit.edu (8.9.3) with ESMTP
	id XAA19203; Thu, 1 Feb 2001 23:39:47 -0500 (EST)
Date:   Thu, 1 Feb 2001 23:39:47 -0500 (EST)
From:   Kenneth C Barr <kbarr@MIT.EDU>
To:     <linux-mips@oss.sgi.com>
Subject: Re: netbooting indy
In-Reply-To: <Pine.LNX.4.30.0102010926190.20992-100000@springhead.px.uk.com>
Message-Id: <Pine.GSO.4.30L.0102012329020.18202-100000@biohazard-cafe.mit.edu>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing

On Thu, 1 Feb 2001, Dr. David Gilbert wrote:

> On Wed, 31 Jan 2001, Kenneth C Barr wrote:
>
> > I finally got bootp/tftp to answer my indy's pleas for an image, but get
> > the following behavior (with my own IP addr and server, obviously):
> >
> > >> boot bootp():/vmlinux
>
>
> I haven't seen the error you got - however one thing I do differently is
> to do
>
> bootp():/vmlinux
>
> without the initial 'boot ' - worth a go?

Unfortunately this gives the same behavior.  Here are some other things I
observed.  Maybe they'll help make the solution more obvious.

1.  Same behavior on two different indys.  So it's not a flukey hardware
problem.

2.  Similar behavior with 3 different ELF kernel images (hardhat,
vmlinux-indy-2.2.1-990226, and the 2.4.0-test9).  I get the spinning
cursor and watch TFTP packets fly by.  then, it stops (with the disk full
tftp error observable on the sniffer).  Sometimes it has even rebooted
itself.  Each kernel dies after receiving a different number of blocks
(IE, I'm not filling up some buffer to the max each time), but --
and this is the most interesting thing -- repeated attempts with a fixed
kernel die at the identical block number!

eg hardhat always dies at 2130
   2.4.0 always dies at 2960
   etc...

Is there something in the image at a particular point that could cause a
freeze-up or reboot like that?

3.  When I specify init=/bin/sh as a parameter, it freezes halfway through
the kernel download as usual, but on the sniffer, I can see the beginning
of an NFS conversation.  It looks for /dev/console and then follows
/bin/sh to bash at which point the SGI starts issuing seemingly malformed
READ requests.  The NFS server tries to ship it "bash" but the responses
seemed malformed, too.

Thanks for your help in conquering this!

Ken



From owner-linux-mips@oss.sgi.com Fri Feb  2 01:38:33 2001
Received:  by oss.sgi.com id <S554045AbRBBJiX>;
	Fri, 2 Feb 2001 01:38:23 -0800
Received: from noose.gt.owl.de ([62.52.19.4]:32519 "HELO noose.gt.owl.de")
	by oss.sgi.com with SMTP id <S554024AbRBBJiO>;
	Fri, 2 Feb 2001 01:38:14 -0800
Received: by noose.gt.owl.de (Postfix, from userid 10)
	id 95D007F4; Fri,  2 Feb 2001 10:38:01 +0100 (CET)
Received: by paradigm.rfc822.org (Postfix, from userid 1000)
	id 3ED40EE9C; Fri,  2 Feb 2001 10:36:07 +0100 (CET)
Date:   Fri, 2 Feb 2001 10:36:07 +0100
From:   Florian Lohoff <flo@rfc822.org>
To:     Kenneth C Barr <kbarr@MIT.EDU>
Cc:     linux-mips@oss.sgi.com
Subject: Re: netbooting indy
Message-ID: <20010202103607.C18620@paradigm.rfc822.org>
References: <Pine.LNX.4.30.0102010926190.20992-100000@springhead.px.uk.com> <Pine.GSO.4.30L.0102012329020.18202-100000@biohazard-cafe.mit.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <Pine.GSO.4.30L.0102012329020.18202-100000@biohazard-cafe.mit.edu>; from kbarr@MIT.EDU on Thu, Feb 01, 2001 at 11:39:47PM -0500
Organization: rfc822 - pure communication
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing

On Thu, Feb 01, 2001 at 11:39:47PM -0500, Kenneth C Barr wrote:
> 
> 2.  Similar behavior with 3 different ELF kernel images (hardhat,
> vmlinux-indy-2.2.1-990226, and the 2.4.0-test9).  I get the spinning

Ever tried using an ECOFF image ? Some proms cant load elf ..

> 3.  When I specify init=/bin/sh as a parameter, it freezes halfway through
> the kernel download as usual, but on the sniffer, I can see the beginning
> of an NFS conversation.  It looks for /dev/console and then follows
> /bin/sh to bash at which point the SGI starts issuing seemingly malformed
> READ requests.  The NFS server tries to ship it "bash" but the responses
> seemed malformed, too.

This doesnt look like "half way through stop" - This sound like console
setup mismatch - Do you have a Newport GFX Board or something else ? If
something else you have to use Serial Console "console=ttyS0" and
attach a terminal.

Flo
-- 
Florian Lohoff                  flo@rfc822.org             +49-5201-669912
     Why is it called "common sense" when nobody seems to have any?


From owner-linux-mips@oss.sgi.com Fri Feb  2 01:38:53 2001
Received:  by oss.sgi.com id <S554042AbRBBJie>;
	Fri, 2 Feb 2001 01:38:34 -0800
Received: from noose.gt.owl.de ([62.52.19.4]:32775 "HELO noose.gt.owl.de")
	by oss.sgi.com with SMTP id <S553683AbRBBJiO>;
	Fri, 2 Feb 2001 01:38:14 -0800
Received: by noose.gt.owl.de (Postfix, from userid 10)
	id AEEAE7F8; Fri,  2 Feb 2001 10:38:01 +0100 (CET)
Received: by paradigm.rfc822.org (Postfix, from userid 1000)
	id 3F112EE9C; Fri,  2 Feb 2001 10:37:20 +0100 (CET)
Date:   Fri, 2 Feb 2001 10:37:20 +0100
From:   Florian Lohoff <flo@rfc822.org>
To:     James McD <vile8@hotmail.com>
Cc:     linux-mips@oss.sgi.com
Subject: Re: console driver for indigo2
Message-ID: <20010202103720.D18620@paradigm.rfc822.org>
References: <F120dm5UxP9Fekzabtn000001ce@hotmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <F120dm5UxP9Fekzabtn000001ce@hotmail.com>; from vile8@hotmail.com on Fri, Feb 02, 2001 at 12:19:22AM +0000
Organization: rfc822 - pure communication
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing

On Fri, Feb 02, 2001 at 12:19:22AM +0000, James McD wrote:
> has anyone come up with a console driver for the indigo2 extreme?
> If not can anyone give me a pointer where to pick up a null modem
> cable for the indigo2's strangely designed serial port? Off list is fine.

Go to the next Apple Mac shop - Its the same connector - I guess a 
"normal" serial cable Mini Din -> DB25  + a Null Modem gender changer
is much cheaper than a "real" Mini Din -> 9 Pin Serial as a null modem.

Flo
-- 
Florian Lohoff                  flo@rfc822.org             +49-5201-669912
     Why is it called "common sense" when nobody seems to have any?


From owner-linux-mips@oss.sgi.com Fri Feb  2 03:38:34 2001
Received:  by oss.sgi.com id <S554045AbRBBLiO>;
	Fri, 2 Feb 2001 03:38:14 -0800
Received: from sovereign.org ([209.180.91.170]:52352 "EHLO lux.homenet")
	by oss.sgi.com with ESMTP id <S554024AbRBBLh4>;
	Fri, 2 Feb 2001 03:37:56 -0800
Received: (from jfree@localhost)
	by lux.homenet (8.11.2/8.11.2/Debian 8.11.2-1) id f12Bbuq03913
	for linux-mips@oss.sgi.com; Fri, 2 Feb 2001 04:37:56 -0700
From:   Jim Freeman <jfree@sovereign.org>
Date:   Fri, 2 Feb 2001 04:37:56 -0700
To:     linux-mips@oss.sgi.com
Subject: hz_to_std(): parisc, etc.
Message-ID: <20010202043756.A3687@sovereign.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.3.12i
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing

asm-parisc/param.h is missing the hz_to_std() macro that the
other asm-*/param.h have.

For the other missing asm-arm/arch-*, something like the following
could catch laggards?  Or the test could be used in linux/param.h,
though I expect Linus wouldn't like crufting the toplevel .h
for a mips-ism (or is hz_to_std() a needed non-mips-centric
general mechanism)?

--- linux-mips.cvs/include/asm-arm/param.h	2001/02/02 11:14:40	1.1
+++ linux-mips.cvs/include/asm-arm/param.h	2001/02/02 11:27:18
@@ -16,9 +16,14 @@
 #ifndef HZ
 #define HZ 100
 #endif
-#if defined(__KERNEL__) && (HZ == 100)
+#ifdef __KERNEL__
+#if (HZ == 100)
 #define hz_to_std(a) (a)
-#endif
+#endif /* (HZ == 100) */
+#if !defined(hz_to_std)
+#error hz_to_std not defined	/* see asm-arm/arch-shark/param.h for details */
+#endif /* !defined(hz_to_std) */
+#endif /* def __KERNEL__ */
 
 #ifndef NGROUPS
 #define NGROUPS         32
--- linux-mips.cvs/include/asm-arm/arch-shark/param.h	2001/02/02 11:16:59	1.1
+++ linux-mips.cvs/include/asm-arm/arch-shark/param.h	2001/02/02 11:19:24
@@ -15,7 +15,7 @@
 
    is what has to be done, it just has overflow problems with the
    intermediate result of the multiply after a bit more than 7 days.
-   See include/asm-mips/param.h for a optized sample implementation
+   See include/asm-mips/param.h for an optimized sample implementation
    used on DECstations.
  */
 #error Provide a definiton for hz_to_std

From owner-linux-mips@oss.sgi.com Fri Feb  2 06:50:25 2001
Received:  by oss.sgi.com id <S554017AbRBBOuP>;
	Fri, 2 Feb 2001 06:50:15 -0800
Received: from mx.mips.com ([206.31.31.226]:38124 "EHLO mx.mips.com")
	by oss.sgi.com with ESMTP id <S553967AbRBBOtx>;
	Fri, 2 Feb 2001 06:49:53 -0800
Received: from newman.mips.com (ns-dmz [206.31.31.225])
	by mx.mips.com (8.9.3/8.9.0) with ESMTP id GAA12448
	for <linux-mips@oss.sgi.com>; Fri, 2 Feb 2001 06:49:50 -0800 (PST)
Received: from copfs01.mips.com (copfs01 [192.168.205.101])
	by newman.mips.com (8.9.3/8.9.0) with ESMTP id GAA08986
	for <linux-mips@oss.sgi.com>; Fri, 2 Feb 2001 06:49:49 -0800 (PST)
Received: from mips.com (copsun17 [192.168.205.27])
	by copfs01.mips.com (8.9.1/8.9.0) with ESMTP id PAA07178
	for <linux-mips@oss.sgi.com>; Fri, 2 Feb 2001 15:49:39 +0100 (MET)
Message-ID: <3A7AC901.4BD0F4E0@mips.com>
Date:   Fri, 02 Feb 2001 15:49:37 +0100
From:   Carsten Langgaard <carstenl@mips.com>
X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To:     linux-mips@oss.sgi.com
Subject: Cross build applications
Content-Type: text/plain; charset=iso-8859-15
Content-Transfer-Encoding: 7bit
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing

I'm trying to cross build a small test program on a linux PC, but it
fails.

mips-linux-gcc -o test test.c
/usr/mips-linux/bin/ld: cannot open crt1.o: No such file or directory

--
_    _ ____  ___   Carsten Langgaard   Mailto:carstenl@mips.com
|\  /|||___)(___   MIPS Denmark        Direct: +45 4486 5527
| \/ |||    ____)  Lautrupvang 4B      Switch: +45 4486 5555
  TECHNOLOGIES     2750 Ballerup       Fax...: +45 4486 5556
                   Denmark             http://www.mips.com




From owner-linux-mips@oss.sgi.com Fri Feb  2 07:03:15 2001
Received:  by oss.sgi.com id <S554046AbRBBPC4>;
	Fri, 2 Feb 2001 07:02:56 -0800
Received: from bastion.power-x.co.uk ([62.232.19.201]:49166 "EHLO
        bastion.power-x.co.uk") by oss.sgi.com with ESMTP
	id <S554024AbRBBPCo>; Fri, 2 Feb 2001 07:02:44 -0800
Received: from springhead.px.uk.com (IDENT:dg@springhead.px.uk.com [172.16.18.41])
	by bastion.power-x.co.uk (8.9.3/8.9.3) with ESMTP id PAA06849;
	Fri, 2 Feb 2001 15:02:25 GMT
Date:   Fri, 2 Feb 2001 15:03:11 +0000 (GMT)
From:   "Dr. David Gilbert" <gilbertd@treblig.org>
X-Sender:  <dg@springhead.px.uk.com>
To:     Carsten Langgaard <carstenl@mips.com>
cc:     <linux-mips@oss.sgi.com>
Subject: Re: Cross build applications
In-Reply-To: <3A7AC901.4BD0F4E0@mips.com>
Message-ID: <Pine.LNX.4.30.0102021502170.1654-100000@springhead.px.uk.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing

On Fri, 2 Feb 2001, Carsten Langgaard wrote:

> I'm trying to cross build a small test program on a linux PC, but it
> fails.
>
> mips-linux-gcc -o test test.c
> /usr/mips-linux/bin/ld: cannot open crt1.o: No such file or directory

Yep - you need to obtain a copy of this - just copy it out of Linux/mips
installation and put it in one of the lib directories under your
/usr/mips-linux.

(That let me get "hello world" crossing from Linux/Alpha last week)

Dave
-- 
/------------------------------------------------------------------\
| Dr. David Alan Gilbert | Work:dg@px.uk.com +44-161-286-2000 Ex258|
| -------- G7FHJ --------|---------------------------------------- |
| Home: dave@treblig.org            http://www.treblig.org         |
\------------------------------------------------------------------/


From owner-linux-mips@oss.sgi.com Fri Feb  2 07:07:45 2001
Received:  by oss.sgi.com id <S554055AbRBBPH1>;
	Fri, 2 Feb 2001 07:07:27 -0800
Received: from delta.ds2.pg.gda.pl ([153.19.144.1]:33733 "EHLO
        delta.ds2.pg.gda.pl") by oss.sgi.com with ESMTP id <S554045AbRBBPHK>;
	Fri, 2 Feb 2001 07:07:10 -0800
Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id QAA09450;
	Fri, 2 Feb 2001 16:04:04 +0100 (MET)
Date:   Fri, 2 Feb 2001 16:04:04 +0100 (MET)
From:   "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To:     Carsten Langgaard <carstenl@mips.com>
cc:     linux-mips@oss.sgi.com
Subject: Re: Cross build applications
In-Reply-To: <3A7AC901.4BD0F4E0@mips.com>
Message-ID: <Pine.GSO.3.96.1010202160104.28509I-100000@delta.ds2.pg.gda.pl>
Organization: Technical University of Gdansk
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing

On Fri, 2 Feb 2001, Carsten Langgaard wrote:

> I'm trying to cross build a small test program on a linux PC, but it
> fails.
> 
> mips-linux-gcc -o test test.c
> /usr/mips-linux/bin/ld: cannot open crt1.o: No such file or directory

 The file is supposed to come with glibc.  Do you have glibc for
mips-linux installed?

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +


From owner-linux-mips@oss.sgi.com Fri Feb  2 07:20:45 2001
Received:  by oss.sgi.com id <S554052AbRBBPUf>;
	Fri, 2 Feb 2001 07:20:35 -0800
Received: from mx.mips.com ([206.31.31.226]:59116 "EHLO mx.mips.com")
	by oss.sgi.com with ESMTP id <S554045AbRBBPUV>;
	Fri, 2 Feb 2001 07:20:21 -0800
Received: from newman.mips.com (ns-dmz [206.31.31.225])
	by mx.mips.com (8.9.3/8.9.0) with ESMTP id HAA12614;
	Fri, 2 Feb 2001 07:18:22 -0800 (PST)
Received: from copfs01.mips.com (copfs01 [192.168.205.101])
	by newman.mips.com (8.9.3/8.9.0) with ESMTP id HAA09622;
	Fri, 2 Feb 2001 07:18:21 -0800 (PST)
Received: from mips.com (copsun17 [192.168.205.27])
	by copfs01.mips.com (8.9.1/8.9.0) with ESMTP id QAA09136;
	Fri, 2 Feb 2001 16:18:10 +0100 (MET)
Message-ID: <3A7ACFB2.DAFC52E3@mips.com>
Date:   Fri, 02 Feb 2001 16:18:10 +0100
From:   Carsten Langgaard <carstenl@mips.com>
X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To:     "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
CC:     linux-mips@oss.sgi.com
Subject: Re: Cross build applications
References: <Pine.GSO.3.96.1010202160104.28509I-100000@delta.ds2.pg.gda.pl>
Content-Type: text/plain; charset=iso-8859-15
Content-Transfer-Encoding: 7bit
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing

"Maciej W. Rozycki" wrote:

> On Fri, 2 Feb 2001, Carsten Langgaard wrote:
>
> > I'm trying to cross build a small test program on a linux PC, but it
> > fails.
> >
> > mips-linux-gcc -o test test.c
> > /usr/mips-linux/bin/ld: cannot open crt1.o: No such file or directory
>
>  The file is supposed to come with glibc.  Do you have glibc for
> mips-linux installed?
>

No, where can I get it.

>
> --
> +  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
> +--------------------------------------------------------------+
> +        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

--
_    _ ____  ___   Carsten Langgaard   Mailto:carstenl@mips.com
|\  /|||___)(___   MIPS Denmark        Direct: +45 4486 5527
| \/ |||    ____)  Lautrupvang 4B      Switch: +45 4486 5555
  TECHNOLOGIES     2750 Ballerup       Fax...: +45 4486 5556
                   Denmark             http://www.mips.com




From owner-linux-mips@oss.sgi.com Fri Feb  2 07:43:45 2001
Received:  by oss.sgi.com id <S554059AbRBBPn0>;
	Fri, 2 Feb 2001 07:43:26 -0800
Received: from delta.ds2.pg.gda.pl ([153.19.144.1]:53445 "EHLO
        delta.ds2.pg.gda.pl") by oss.sgi.com with ESMTP id <S554053AbRBBPnT>;
	Fri, 2 Feb 2001 07:43:19 -0800
Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id QAA10525;
	Fri, 2 Feb 2001 16:40:45 +0100 (MET)
Date:   Fri, 2 Feb 2001 16:40:45 +0100 (MET)
From:   "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To:     Carsten Langgaard <carstenl@mips.com>
cc:     linux-mips@oss.sgi.com
Subject: Re: Cross build applications
In-Reply-To: <3A7ACFB2.DAFC52E3@mips.com>
Message-ID: <Pine.GSO.3.96.1010202162911.28509M-100000@delta.ds2.pg.gda.pl>
Organization: Technical University of Gdansk
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing

On Fri, 2 Feb 2001, Carsten Langgaard wrote:

> >  The file is supposed to come with glibc.  Do you have glibc for
> > mips-linux installed?
> 
> No, where can I get it.

 If you want glibc 2.2.1, you may get a source RPM package I made
available at 'ftp://ftp.ds2.pg.gda.pl/pub/macro/'.  I make mipsel-linux
builds only, so for cross-compilation you would get a mipsel-linux-glibc
package, modify the few defines at the top (and possibly the spec file
name) and build a mips-linux-glibc binary package.  Or build it in the
traditional way.  Note the few patches I include are not MIPS-specific, so
you do not really need them unless you want them. 

 If you want a glibc 2.0 package or a binary one, then I cannot help you. 
Check the usual resources -- oss.sgi.com and ftp.rfc822.org.  Others may
provide different pointers as well. 

  Maciej

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +


From owner-linux-mips@oss.sgi.com Fri Feb  2 07:53:56 2001
Received:  by oss.sgi.com id <S554062AbRBBPxr>;
	Fri, 2 Feb 2001 07:53:47 -0800
Received: from mx.mips.com ([206.31.31.226]:18157 "EHLO mx.mips.com")
	by oss.sgi.com with ESMTP id <S554058AbRBBPx3>;
	Fri, 2 Feb 2001 07:53:29 -0800
Received: from newman.mips.com (ns-dmz [206.31.31.225])
	by mx.mips.com (8.9.3/8.9.0) with ESMTP id HAA12818;
	Fri, 2 Feb 2001 07:51:31 -0800 (PST)
Received: from copfs01.mips.com (copfs01 [192.168.205.101])
	by newman.mips.com (8.9.3/8.9.0) with ESMTP id HAA10279;
	Fri, 2 Feb 2001 07:51:30 -0800 (PST)
Received: from mips.com (copsun17 [192.168.205.27])
	by copfs01.mips.com (8.9.1/8.9.0) with ESMTP id QAA11437;
	Fri, 2 Feb 2001 16:51:19 +0100 (MET)
Message-ID: <3A7AD776.46B10823@mips.com>
Date:   Fri, 02 Feb 2001 16:51:18 +0100
From:   Carsten Langgaard <carstenl@mips.com>
X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To:     "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
CC:     linux-mips@oss.sgi.com
Subject: Re: Cross build applications
References: <Pine.GSO.3.96.1010202162911.28509M-100000@delta.ds2.pg.gda.pl>
Content-Type: text/plain; charset=iso-8859-15
Content-Transfer-Encoding: 7bit
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing

Please, can anyone provide me with the right set of RPMs, so I can cross
compile a "hello-world" program on a linux PC ?

/Carsten

"Maciej W. Rozycki" wrote:

> On Fri, 2 Feb 2001, Carsten Langgaard wrote:
>
> > >  The file is supposed to come with glibc.  Do you have glibc for
> > > mips-linux installed?
> >
> > No, where can I get it.
>
>  If you want glibc 2.2.1, you may get a source RPM package I made
> available at 'ftp://ftp.ds2.pg.gda.pl/pub/macro/'.  I make mipsel-linux
> builds only, so for cross-compilation you would get a mipsel-linux-glibc
> package, modify the few defines at the top (and possibly the spec file
> name) and build a mips-linux-glibc binary package.  Or build it in the
> traditional way.  Note the few patches I include are not MIPS-specific, so
> you do not really need them unless you want them.
>
>  If you want a glibc 2.0 package or a binary one, then I cannot help you.
> Check the usual resources -- oss.sgi.com and ftp.rfc822.org.  Others may
> provide different pointers as well.
>
>   Maciej
>
> --
> +  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
> +--------------------------------------------------------------+
> +        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

--
_    _ ____  ___   Carsten Langgaard   Mailto:carstenl@mips.com
|\  /|||___)(___   MIPS Denmark        Direct: +45 4486 5527
| \/ |||    ____)  Lautrupvang 4B      Switch: +45 4486 5555
  TECHNOLOGIES     2750 Ballerup       Fax...: +45 4486 5556
                   Denmark             http://www.mips.com




From owner-linux-mips@oss.sgi.com Fri Feb  2 12:09:29 2001
Received:  by oss.sgi.com id <S554052AbRBBUJJ>;
	Fri, 2 Feb 2001 12:09:09 -0800
Received: from gateway-1237.mvista.com ([12.44.186.158]:14841 "EHLO
        orion.mvista.com") by oss.sgi.com with ESMTP id <S554045AbRBBUIs>;
	Fri, 2 Feb 2001 12:08:48 -0800
Received: (from jsun@localhost)
	by orion.mvista.com (8.9.3/8.9.3) id MAA21895;
	Fri, 2 Feb 2001 12:07:27 -0800
Date:   Fri, 2 Feb 2001 12:07:27 -0800
From:   Jun Sun <jsun@mvista.com>
To:     Carsten Langgaard <carstenl@mips.com>
Cc:     "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>, linux-mips@oss.sgi.com
Subject: Re: Cross build applications
Message-ID: <20010202120727.B21833@mvista.com>
References: <Pine.GSO.3.96.1010202162911.28509M-100000@delta.ds2.pg.gda.pl> <3A7AD776.46B10823@mips.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <3A7AD776.46B10823@mips.com>; from carstenl@mips.com on Fri, Feb 02, 2001 at 04:51:18PM +0100
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing

On Fri, Feb 02, 2001 at 04:51:18PM +0100, Carsten Langgaard wrote:
> Please, can anyone provide me with the right set of RPMs, so I can cross
> compile a "hello-world" program on a linux PC ?
> 
> /Carsten
> 

Go to ftp://ftp.mvista.com/pub/Area51/mips_fp_le/, and look for the following
packages for i386 host:

. binutils
. kernel-headers
. gcc 
. glibc

Install them and you are ready to go!

There are also big endian packages available.

Jun

From owner-linux-mips@oss.sgi.com Sat Feb  3 07:28:09 2001
Received:  by oss.sgi.com id <S554146AbRBCP17>;
	Sat, 3 Feb 2001 07:27:59 -0800
Received: from noose.gt.owl.de ([62.52.19.4]:61704 "HELO noose.gt.owl.de")
	by oss.sgi.com with SMTP id <S554143AbRBCP1o>;
	Sat, 3 Feb 2001 07:27:44 -0800
Received: by noose.gt.owl.de (Postfix, from userid 10)
	id D36607F4; Sat,  3 Feb 2001 16:27:31 +0100 (CET)
Received: by paradigm.rfc822.org (Postfix, from userid 1000)
	id 81F07EEAD; Sat,  3 Feb 2001 16:27:58 +0100 (CET)
Date:   Sat, 3 Feb 2001 16:27:58 +0100
From:   Florian Lohoff <flo@rfc822.org>
To:     linux-mips@oss.sgi.com
Subject: [PATCH] R3912 mm stuff from linux-vr tree 
Message-ID: <20010203162758.A1986@paradigm.rfc822.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
Organization: rfc822 - pure communication
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing

Hi,
here is a patch against the OSS tree to basically add R3912
support - It has mainly be done by Harald Koerfgen - I did basically
change the stuff to get it into the oss tree. 

The CPU Probing with the PRID is definitly not right but probably
someone else can come up with solutions. I havent got any R4650 
hardwate so i cant try.

I only booted on an R3912 Board and it seemed to work at least for
Cache detection - Could someone verify if this doesnt break R3k
Decstations e.g ?

Index: include/asm-mips/bootinfo.h
===================================================================
RCS file: /cvs/linux/include/asm-mips/bootinfo.h,v
retrieving revision 1.22
diff -u -r1.22 bootinfo.h
--- include/asm-mips/bootinfo.h	2000/12/13 19:43:03	1.22
+++ include/asm-mips/bootinfo.h	2001/02/03 15:25:58
@@ -176,14 +185,15 @@
 #define CPU_4KC                 30
 #define CPU_5KC                 31
 #define CPU_R4310               32
-#define CPU_LAST		32
+#define CPU_R3912		33
+#define CPU_LAST		33
 
 #define CPU_NAMES { "unknown", "R2000", "R3000", "R3000A", "R3041", "R3051", \
         "R3052", "R3081", "R3081E", "R4000PC", "R4000SC", "R4000MC",         \
         "R4200", "R4400PC", "R4400SC", "R4400MC", "R4600", "R6000",          \
         "R6000A", "R8000", "R10000", "R4300", "R4650", "R4700", "R5000",     \
         "R5000A", "R4640", "Nevada", "RM7000", "R5432", "MIPS 4Kc",          \
-        "MIPS 5Kc", "R4310" }
+        "MIPS 5Kc", "R4310", "R3912" }
 
 #define COMMAND_LINE_SIZE	256
 
Index: include/asm-mips/cpu.h
===================================================================
RCS file: /cvs/linux/include/asm-mips/cpu.h,v
retrieving revision 1.3
diff -u -r1.3 cpu.h
--- include/asm-mips/cpu.h	2000/11/25 04:49:47	1.3
+++ include/asm-mips/cpu.h	2001/02/03 15:25:58
@@ -26,6 +26,8 @@
 #define PRID_IMP_R4700		0x2100
 #define PRID_IMP_R4640		0x2200
 #define PRID_IMP_R4650		0x2200		/* Same as R4640 */
+#define PRID_IMP_R3912		0x2210
+#define PRID_IMP_R3922		0x2230
 #define PRID_IMP_R5000		0x2300
 #define PRID_IMP_R5432		0x5400
 #define PRID_IMP_SONIC		0x2400
Index: arch/mips/mm/r2300.c
===================================================================
RCS file: /cvs/linux/arch/mips/mm/r2300.c,v
retrieving revision 1.27
diff -u -r1.27 r2300.c
--- arch/mips/mm/r2300.c	2000/12/13 20:34:08	1.27
+++ arch/mips/mm/r2300.c	2001/02/03 15:25:59
@@ -4,9 +4,11 @@
  * Copyright (C) 1996 David S. Miller (dm@engr.sgi.com)
  *
  * with a lot of changes to make this thing work for R3000s
- * Copyright (C) 1998, 2000 Harald Koerfgen
+ * Tx39XX R4k style caches added. HK
+ * Copyright (C) 1998, 1999, 2000 Harald Koerfgen
  * Copyright (C) 1998 Gleb Raiko & Vladimir Roganov
  */
+#include <asm/bootinfo.h>
 #include <linux/init.h>
 #include <linux/kernel.h>
 #include <linux/sched.h>
@@ -19,16 +21,26 @@
 #include <asm/isadep.h>
 #include <asm/io.h>
 #include <asm/wbflush.h>
+#include <asm/cpu.h>
 
-/* Primary cache parameters. */
-static unsigned long icache_size, dcache_size; /* Size in bytes */
-/* the linesizes are usually fixed on R3000s */
+/*
+ * According to the paper written by D. Miller about Linux cache & TLB
+ * flush implementation, DMA/Driver coherence should be done at the 
+ * driver layer.  Thus, normally, we don't need flush dcache for R3000.
+ * Define this if driver does not handle cache consistency during DMA ops.
+ */
+
+/* For R3000 cores with R4000 style caches */
+static unsigned long icache_size, icache_lsize;
+static unsigned long dcache_size, dcache_lsize;
+static unsigned int scache_size = 0;
+
+#include <asm/cacheops.h>
+#include <asm/r4kcache.h>
 
 #undef DEBUG_TLB
 #undef DEBUG_CACHE
 
-#define NTLB_ENTRIES       64  /* Fixed on all R23000 variants... */
-
 /* page functions */
 void r3k_clear_page(void * page)
 {
@@ -113,7 +125,7 @@
 
 	p = (volatile unsigned long *) KSEG0;
 
-	flags = read_32bit_cp0_register(CP0_STATUS);
+	save_and_cli(flags);
 
 	/* isolate cache space */
 	write_32bit_cp0_register(CP0_STATUS, (ca_flags|flags)&~ST0_IEC);
@@ -135,8 +147,7 @@
 		if (size > 0x40000)
 			size = 0;
 	}
-
-	write_32bit_cp0_register(CP0_STATUS, flags);
+	restore_flags(flags);
 
 	return size * sizeof(*p);
 }
@@ -144,27 +155,26 @@
 static void __init probe_dcache(void)
 {
 	dcache_size = r3k_cache_size(ST0_ISC);
-	printk("Primary data cache %lukb, linesize 4 bytes\n",
+	printk("Primary data cache %dkb, linesize 4 bytes\n",
 		dcache_size >> 10);
 }
 
 static void __init probe_icache(void)
 {
 	icache_size = r3k_cache_size(ST0_ISC|ST0_SWC);
-	printk("Primary instruction cache %lukb, linesize 4 bytes\n",
+	printk("Primary instruction cache %dkb, linesize 4 bytes\n",
 		icache_size >> 10);
 }
 
-static void r3k_flush_icache_range(unsigned long start, unsigned long end)
+static void r3k_flush_icache_range(unsigned long start, unsigned long size)
 {
-	unsigned long size, i, flags;
+	unsigned long i, flags;
 	volatile unsigned char *p = (char *)start;
 
-	size = end - start;
 	if (size > icache_size)
 		size = icache_size;
 
-	flags = read_32bit_cp0_register(CP0_STATUS);
+	save_and_cli(flags);
 
 	/* isolate cache space */
 	write_32bit_cp0_register(CP0_STATUS, (ST0_ISC|ST0_SWC|flags)&~ST0_IEC);
@@ -206,19 +216,18 @@
 		p += 0x080;
 	}
 
-	write_32bit_cp0_register(CP0_STATUS, flags);
+	restore_flags(flags);
 }
 
-static void r3k_flush_dcache_range(unsigned long start, unsigned long end)
+static void r3k_flush_dcache_range(unsigned long start, unsigned long size)
 {
-	unsigned long size, i, flags;
+	unsigned long i, flags;
 	volatile unsigned char *p = (char *)start;
 
-	size = end - start;
 	if (size > dcache_size)
 		size = dcache_size;
 
-	flags = read_32bit_cp0_register(CP0_STATUS);
+	save_and_cli(flags);
 
 	/* isolate cache space */
 	write_32bit_cp0_register(CP0_STATUS, (ST0_ISC|flags)&~ST0_IEC);
@@ -260,7 +269,7 @@
 		p += 0x080;
 	}
 
-	write_32bit_cp0_register(CP0_STATUS, flags);
+	restore_flags(flags);
 }
 
 static inline unsigned long get_phys_page (unsigned long addr,
@@ -357,7 +366,7 @@
 }
 
 static void r3k_flush_icache_page(struct vm_area_struct *vma,
-				  struct page *page)
+				  struct page *page, unsigned long address)
 {
 	struct mm_struct *mm = vma->vm_mm;
 	unsigned long physpage;
@@ -385,7 +394,7 @@
 	printk("csigtramp[%08lx]", addr);
 #endif
 
-	flags = read_32bit_cp0_register(CP0_STATUS);
+	save_and_cli(flags);
 
 	write_32bit_cp0_register(CP0_STATUS, (ST0_ISC|ST0_SWC|flags)&~ST0_IEC);
 
@@ -394,15 +403,66 @@
 		"sb\t$0,0x008(%0)\n\t"
 		: : "r" (addr) );
 
-	write_32bit_cp0_register(CP0_STATUS, flags);
+	restore_flags(flags);
 }
 
 static void r3k_dma_cache_wback_inv(unsigned long start, unsigned long size)
 {
 	wbflush();
-	r3k_flush_dcache_range(start, start + size);
+	r3k_flush_dcache_range(start, size);
 }
 
+static __init void r3912_size_caches(void)
+  {
+	unsigned long config;
+
+	config = read_32bit_cp0_register(CP0_ENTRYLO1);
+
+	icache_size = 1 << (10 + ((config >> 19) & 7));
+	icache_lsize = 16;
+
+	dcache_size = 1 << (10 + ((config >> 16) & 7));
+	dcache_lsize = 4;
+
+	printk("Primary instruction cache %dkb, linesize %d bytes\n",
+	       icache_size >> 10, icache_lsize);
+	printk("Primary data cache %dkb, linesize %d bytes\n",
+	       dcache_size >> 10, dcache_lsize);	
+}
+
+static void r3912_flush_icache_all(void)
+{
+	unsigned long start = KSEG0;
+	unsigned long end = (start + icache_size);
+	unsigned long dummy = 0;
+
+	/* disable icache and stop streaming */
+	__asm__ __volatile__("
+	.set	noreorder
+	mfc0	%0, $3
+	xori	%0, 32		/* toggle ICE bit */
+	mtc0	%0, $3
+	j	1f		/* stop streaming */
+	nop
+	1:	.set	reorder"
+	: : "r"(dummy));
+
+	/* invalidate icache */
+	while(start < end) {
+		cache16_unroll32(start,Index_Invalidate_I);
+		start += 0x200;
+	}
+
+	/* enable icache */
+	__asm__ __volatile__("
+	.set	noreorder
+	mfc0	%0, $3
+	xori	%0, 32		/* toggle ICE bit */
+	mtc0	%0, $3
+	.set	reorder"
+	: : "r"(dummy));
+}
+
 /* TLB operations. */
 void flush_tlb_all(void)
 {
@@ -417,7 +477,7 @@
 	save_and_cli(flags);
 	old_ctx = (get_entryhi() & 0xfc0);
 	write_32bit_cp0_register(CP0_ENTRYLO0, 0);
-	for(entry = 0; entry < NTLB_ENTRIES; entry++) {
+	for(entry = 8; entry < mips_cpu.tlbsize; entry++) {
 		write_32bit_cp0_register(CP0_INDEX, entry << 8);
 		write_32bit_cp0_register(CP0_ENTRYHI, ((entry | 0x80000) << 12));
 		__asm__ __volatile__("tlbwi");
@@ -455,7 +515,7 @@
 #endif
 		save_and_cli(flags);
 		size = (end - start + (PAGE_SIZE - 1)) >> PAGE_SHIFT;
-		if(size <= NTLB_ENTRIES) {
+		if(size <= mips_cpu.tlbsize) {
 			int oldpid = (get_entryhi() & 0xfc0);
 			int newpid = (mm->context & 0xfc0);
 
@@ -590,19 +650,6 @@
 		printk("[HIT]");
 #endif
 	}
-#if 0
-	if(!strcmp(current->comm, "args")) {
-		printk("<");
-		for(idx = 0; idx < NTLB_ENTRIES; idx++) {
-			set_index(idx);
-			tlb_read();
-			address = get_entryhi();
-			if((address & 0xfc0) != 0)
-				printk("[%08lx]", address);
-		}
-		printk(">\n");
-	}
-#endif
 	set_entryhi(pid);
 	restore_flags(flags);
 }
@@ -643,10 +690,22 @@
 void add_wired_entry(unsigned long entrylo0, unsigned long entrylo1,
 				  unsigned long entryhi, unsigned long pagemask)
 {
-printk("r3k_add_wired_entry");
-        /*
-	 * FIXME, to be done
-	 */
+	unsigned long flags;
+	unsigned long old_ctx;
+	static unsigned long wired = 0;
+	
+	if (wired < 8) {
+		save_and_cli(flags);
+		old_ctx = get_entryhi() & 0xfc0;
+		set_entrylo0(entrylo0);
+		set_entryhi(entryhi);
+		set_index(wired);
+		wired++;
+		tlb_write_indexed();
+		set_entryhi(old_ctx);
+	        flush_tlb_all();    
+		restore_flags(flags);
+	}
 }
 
 void __init ld_mmu_r2300(void)
@@ -656,19 +715,49 @@
 	_clear_page = r3k_clear_page;
 	_copy_page = r3k_copy_page;
 
-	probe_icache();
-	probe_dcache();
+	switch (mips_cpu.cputype) {
+	case CPU_R2000:
+	case CPU_R3000:
+	case CPU_R3000A:
+		probe_icache();
+		probe_dcache();
+
+		_flush_cache_all = r3k_flush_cache_all;
+		_flush_cache_mm = r3k_flush_cache_mm;
+		_flush_cache_range = r3k_flush_cache_range;
+		_flush_cache_page = r3k_flush_cache_page;
+		_flush_cache_sigtramp = r3k_flush_cache_sigtramp;
+		_flush_page_to_ram = r3k_flush_page_to_ram;
+		_flush_icache_page = r3k_flush_icache_page;
+		_flush_icache_range = r3k_flush_icache_range;
+
+		_dma_cache_wback_inv = r3k_dma_cache_wback_inv;
+
+		break;
+	case CPU_R3912:
+		r3912_size_caches();
+
+		_flush_cache_all = r3912_flush_icache_all;
+		_flush_cache_mm = (void (*)(struct mm_struct *))r3912_flush_icache_all;
+		_flush_cache_range = (void (*)(struct mm_struct *, unsigned long, unsigned long))r3912_flush_icache_all;
+		_flush_cache_page = (void (*)(struct vm_area_struct *, unsigned long))r3912_flush_icache_all;
+		_flush_cache_sigtramp = (void (*)(unsigned long))r3912_flush_icache_all;
+		_flush_page_to_ram = r3k_flush_page_to_ram;
+
+#warning "This is extremely ineffective: I'm flushing all caches on r3912 when I should flush just one page"
+#warning "r3912_flush_icache_page needs to be written for r3912:"
+// MFK: I'm very confused here.  The above asignments for _flush_cache_{range,page} seem to
+//      only flush the icache, and apparently do the entire cache (not too unreasonable, given
+//      the size of the cache.  So this is probably a reasonable solution for
+//      _flush_icache_{page,range} below, but what about the dcache above???  Am I misisng
+//      something?  Can someone review and remove this comment (and above #warning lines)?
+		_flush_icache_page = r3912_flush_icache_all;
+		_flush_icache_range = r3912_flush_icache_all;
 
-	_flush_cache_all = r3k_flush_cache_all;
-	_flush_cache_mm = r3k_flush_cache_mm;
-	_flush_cache_range = r3k_flush_cache_range;
-	_flush_cache_page = r3k_flush_cache_page;
-	_flush_cache_sigtramp = r3k_flush_cache_sigtramp;
-	_flush_page_to_ram = r3k_flush_page_to_ram;
-	_flush_icache_page = r3k_flush_icache_page;
-	_flush_icache_range = r3k_flush_icache_range;
+	        _dma_cache_wback_inv = (void (*)(unsigned long, unsigned long))r3k_flush_page_to_ram;
 
-        _dma_cache_wback_inv = r3k_dma_cache_wback_inv;
+		break;
+	}
 
 	flush_tlb_all();
 }
Index: arch/mips/kernel/setup.c
===================================================================
RCS file: /cvs/linux/arch/mips/kernel/setup.c,v
retrieving revision 1.48
diff -u -r1.48 setup.c
--- arch/mips/kernel/setup.c	2001/01/10 17:17:55	1.48
+++ arch/mips/kernel/setup.c	2001/02/03 15:25:59
@@ -210,10 +210,18 @@
 		mips_cpu.tlbsize = 48;
 		break;
 	case PRID_IMP_R4650:
-		mips_cpu.cputype = CPU_R4650;
-		mips_cpu.isa_level = MIPS_CPU_ISA_III;
-		mips_cpu.options = R4K_OPTS | MIPS_CPU_FPU;
-		mips_cpu.tlbsize = 48;
+		/* This might also be R3912 & R3922 */
+		if (mips_cpu.processor_id == PRID_IMP_R3912) {
+			mips_cpu.isa_level = MIPS_CPU_ISA_I;
+			mips_cpu.options = MIPS_CPU_TLB;
+			mips_cpu.tlbsize = 32;
+			mips_cpu.cputype = CPU_R3912;
+		} else {
+			mips_cpu.cputype = CPU_R4650;
+			mips_cpu.isa_level = MIPS_CPU_ISA_III;
+			mips_cpu.options = R4K_OPTS | MIPS_CPU_FPU;
+			mips_cpu.tlbsize = 48;
+		}
 		break;
 	case PRID_IMP_R4700:
 		mips_cpu.cputype = CPU_R4700;

Flo
-- 
Florian Lohoff                  flo@rfc822.org             +49-5201-669912
     Why is it called "common sense" when nobody seems to have any?


From owner-linux-mips@oss.sgi.com Sat Feb  3 09:05:48 2001
Received:  by oss.sgi.com id <S554151AbRBCRF3>;
	Sat, 3 Feb 2001 09:05:29 -0800
Received: from [62.145.23.107] ([62.145.23.107]:23056 "HELO
        fileserv2.Cologne.DE") by oss.sgi.com with SMTP id <S554147AbRBCRFL>;
	Sat, 3 Feb 2001 09:05:11 -0800
Received: from localhost (1481 bytes) by fileserv2.Cologne.DE
	via rmail with P:stdio/R:bind/T:smtp
	(sender: <excalibur.cologne.de!karsten>) (ident <excalibur.cologne.de!karsten> using unix)
	id <m14P67Y-0007FZC@fileserv2.Cologne.DE>
	for <linux-mips@oss.sgi.com>; Sat, 3 Feb 2001 18:05:08 +0100 (CET)
	(Smail-3.2.0.101 1997-Dec-17 #5 built 1998-Jan-19)
Received: (from karsten@localhost)
	by excalibur.cologne.de (8.9.3/8.8.7) id SAA14172
	for linux-mips@oss.sgi.com; Sat, 3 Feb 2001 18:05:32 +0100
Date:   Sat, 3 Feb 2001 18:05:32 +0100
From:   Karsten Merker <karsten@excalibur.cologne.de>
To:     linux-mips@oss.sgi.com
Subject: Re: [PATCH] R3912 mm stuff from linux-vr tree
Message-ID: <20010203180532.A6849@excalibur.cologne.de>
Mail-Followup-To: linux-mips@oss.sgi.com
References: <20010203162758.A1986@paradigm.rfc822.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0.1i
In-Reply-To: <20010203162758.A1986@paradigm.rfc822.org>; from flo@rfc822.org on Sat, Feb 03, 2001 at 04:27:58PM +0100
X-No-Archive: yes
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing

On Sat, Feb 03, 2001 at 04:27:58PM +0100, Florian Lohoff wrote:

[PATCH]
> I only booted on an R3912 Board and it seemed to work at least for
> Cache detection - Could someone verify if this doesnt break R3k
> Decstations e.g ?

It looks like the DECstation support is already broken again :-(. I have
just tried to test the current CVS on a 5000/150 - the kernel crashes just
after mounting the rootfs. Anybody with similar experience?

Greetings,
Karsten
-- 
#include <standard_disclaimer>
Nach Paragraph 28 Abs. 3 Bundesdatenschutzgesetz widerspreche ich der
Nutzung oder Uebermittlung meiner Daten fuer Werbezwecke oder fuer die
Markt- oder Meinungsforschung.

From owner-linux-mips@oss.sgi.com Sat Feb  3 10:25:20 2001
Received:  by oss.sgi.com id <S554151AbRBCSZA>;
	Sat, 3 Feb 2001 10:25:00 -0800
Received: from noose.gt.owl.de ([62.52.19.4]:38668 "HELO noose.gt.owl.de")
	by oss.sgi.com with SMTP id <S554146AbRBCSYk>;
	Sat, 3 Feb 2001 10:24:40 -0800
Received: by noose.gt.owl.de (Postfix, from userid 10)
	id 9DAEA7FC; Sat,  3 Feb 2001 19:24:28 +0100 (CET)
Received: by paradigm.rfc822.org (Postfix, from userid 1000)
	id 6549CEEAD; Sat,  3 Feb 2001 19:24:53 +0100 (CET)
Date:   Sat, 3 Feb 2001 19:24:53 +0100
From:   Florian Lohoff <flo@rfc822.org>
To:     linux-mips@oss.sgi.com
Subject: Re: [PATCH] R3912 mm stuff from linux-vr tree
Message-ID: <20010203192453.B1986@paradigm.rfc822.org>
References: <20010203162758.A1986@paradigm.rfc822.org> <20010203180532.A6849@excalibur.cologne.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <20010203180532.A6849@excalibur.cologne.de>; from karsten@excalibur.cologne.de on Sat, Feb 03, 2001 at 06:05:32PM +0100
Organization: rfc822 - pure communication
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing

On Sat, Feb 03, 2001 at 06:05:32PM +0100, Karsten Merker wrote:
> On Sat, Feb 03, 2001 at 04:27:58PM +0100, Florian Lohoff wrote:
> 
> It looks like the DECstation support is already broken again :-(. I have
> just tried to test the current CVS on a 5000/150 - the kernel crashes just
> after mounting the rootfs. Anybody with similar experience?
> 

This is R4k and yes i have seen that too - But i cant find why but i didnt
have the time to search much.

Flo
-- 
Florian Lohoff                  flo@rfc822.org             +49-5201-669912
     Why is it called "common sense" when nobody seems to have any?


From owner-linux-mips@oss.sgi.com Sat Feb  3 11:25:39 2001
Received:  by oss.sgi.com id <S554146AbRBCTZa>;
	Sat, 3 Feb 2001 11:25:30 -0800
Received: from stav.org.il ([192.114.42.86]:3579 "EHLO fred.stav")
	by oss.sgi.com with ESMTP id <S553653AbRBCTZF>;
	Sat, 3 Feb 2001 11:25:05 -0800
Received: from adi by fred.stav with local (Exim 3.20 #1 (Debian))
	id 14P8Hs-0002xX-00; Sat, 03 Feb 2001 21:23:56 +0200
Date:   Sat, 3 Feb 2001 21:23:56 +0200
To:     linux-mips@oss.sgi.com
Subject: Progress with Linux on O2?
Message-ID: <20010203212356.C24513@stav.org.il>
Mail-Followup-To: linux-mips@oss.sgi.com
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.3.12i
From:   Adi Stav <stav@actcom.co.il>
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing

Hello,

I have an O2 and would very much like to run Linux on it. I was
looking for information on Linux on O2 but could not find any -- I
understand that there is no such usable port yet, but I was wondering
if someone could refer me to anyone working on it, or to work that has
been done already, so that I could follow the progress or maybe help a
bit. Or has no such work been done yet?

	Thanks in advance,
	Adi Stav

From owner-linux-mips@oss.sgi.com Sat Feb  3 11:29:20 2001
Received:  by oss.sgi.com id <S554151AbRBCT3J>;
	Sat, 3 Feb 2001 11:29:09 -0800
Received: from noose.gt.owl.de ([62.52.19.4]:63501 "HELO noose.gt.owl.de")
	by oss.sgi.com with SMTP id <S553660AbRBCT2v>;
	Sat, 3 Feb 2001 11:28:51 -0800
Received: by noose.gt.owl.de (Postfix, from userid 10)
	id C37357FC; Sat,  3 Feb 2001 20:28:35 +0100 (CET)
Received: by paradigm.rfc822.org (Postfix, from userid 1000)
	id 8DC5DEEAD; Sat,  3 Feb 2001 20:29:03 +0100 (CET)
Date:   Sat, 3 Feb 2001 20:29:03 +0100
From:   Florian Lohoff <flo@rfc822.org>
To:     linux-mips@oss.sgi.com
Subject: [PATCH] drivers/net/Config.in - CONFIG_IA64_SGI_SN1 vs. $CONFIG_IA64_SGI_SN1#
Message-ID: <20010203202903.A4098@paradigm.rfc822.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
Organization: rfc822 - pure communication
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing


I guess this is more correct :)

Index: drivers/net/Config.in
===================================================================
RCS file: /cvs/linux/drivers/net/Config.in,v
retrieving revision 1.53
diff -u -r1.53 Config.in
--- drivers/net/Config.in	2001/01/11 04:02:43	1.53
+++ drivers/net/Config.in	2001/02/03 19:27:39
@@ -55,7 +55,7 @@
    if [ "$CONFIG_SGI_IP27" = "y" ]; then
       bool '  SGI IOC3 Ethernet' CONFIG_SGI_IOC3_ETH
    fi
-   if [ "CONFIG_IA64_SGI_SN1" = "y" ]; then
+   if [ "$CONFIG_IA64_SGI_SN1" = "y" ]; then
       bool '  SGI IOC3 Ethernet' CONFIG_SGI_IOC3_ETH
    fi
    if [ "$CONFIG_SUPERH" = "y" ]; then


-- 
Florian Lohoff                  flo@rfc822.org             +49-5201-669912
     Why is it called "common sense" when nobody seems to have any?


From owner-linux-mips@oss.sgi.com Sun Feb  4 19:51:12 2001
Received:  by oss.sgi.com id <S554079AbRBEDux>;
	Sun, 4 Feb 2001 19:50:53 -0800
Received: from c824216-a.stcla1.sfba.home.com ([24.176.212.15]:23539 "EHLO
        dea.waldorf-gmbh.de") by oss.sgi.com with ESMTP id <S554040AbRBEDuq>;
	Sun, 4 Feb 2001 19:50:46 -0800
Received: (from ralf@localhost)
	by dea.waldorf-gmbh.de (8.11.1/8.11.1) id f153iqB26896;
	Sun, 4 Feb 2001 19:44:52 -0800
Date:   Sun, 4 Feb 2001 19:44:52 -0800
From:   Ralf Baechle <ralf@oss.sgi.com>
To:     Quinn Jensen <jensenq@Lineo.COM>
Cc:     linux-mips@oss.sgi.com
Subject: Re: NFS root with cache on
Message-ID: <20010204194451.A26868@bacchus.dhis.org>
References: <3A79C869.2040001@Lineo.COM>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <3A79C869.2040001@Lineo.COM>; from jensenq@Lineo.COM on Thu, Feb 01, 2001 at 01:34:49PM -0700
X-Accept-Language: de,en,fr
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing

On Thu, Feb 01, 2001 at 01:34:49PM -0700, Quinn Jensen wrote:

> Is anyone else having trouble with NFS root on
> the 2.4.0 kernel?  It won't come up with the
> KSEG0 cache on unless I pepper the network driver
> with flush calls.

That's expected for most old network drivers that don't yet use the
new PCI DMA API documented in Documentation/DMA-mapping.txt.

What driver is this?

  Ralf

From owner-linux-mips@oss.sgi.com Sun Feb  4 21:07:53 2001
Received:  by oss.sgi.com id <S554098AbRBEFHm>;
	Sun, 4 Feb 2001 21:07:42 -0800
Received: from c824216-a.stcla1.sfba.home.com ([24.176.212.15]:18420 "EHLO
        dea.waldorf-gmbh.de") by oss.sgi.com with ESMTP id <S554093AbRBEFHW>;
	Sun, 4 Feb 2001 21:07:22 -0800
Received: (from ralf@localhost)
	by dea.waldorf-gmbh.de (8.11.1/8.11.1) id f1551Xc27528;
	Sun, 4 Feb 2001 21:01:33 -0800
Date:   Sun, 4 Feb 2001 21:01:33 -0800
From:   Ralf Baechle <ralf@oss.sgi.com>
To:     Calvine Chew <calvine@sgi.com>
Cc:     "'linux-mips'" <linux-mips@oss.sgi.com>
Subject: Re: Where can I find precompiled binaries for XFree86 4.0.2?
Message-ID: <20010204210132.A27490@bacchus.dhis.org>
References: <43FECA7CDC4CD411A4A3009027999112267E4A@sgp-apsa001e--n.singapore.sgi.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <43FECA7CDC4CD411A4A3009027999112267E4A@sgp-apsa001e--n.singapore.sgi.com>; from calvine@sgi.com on Fri, Feb 02, 2001 at 09:51:29AM +0800
X-Accept-Language: de,en,fr
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing

On Fri, Feb 02, 2001 at 09:51:29AM +0800, Calvine Chew wrote:
> From: Calvine Chew <calvine@sgi.com>
> To: "'linux-mips'" <linux-mips@oss.sgi.com>
> Subject: Where can I find precompiled binaries for XFree86 4.0.2?
> Date:   Fri, 2 Feb 2001 09:51:29 +0800 
> 
> Hello all.
> 
> Anyone know where I can grab the above? I am encountering problems with
> building my own on Hardhat 5.1. make world looked okay but make install died
> trying to make the shared library X11lib.so.6.2~ (ld terminated with signal
> 6).

Hardhat is extremly rotten and buggy code by today's standard.  You really
want to replace it with a more current distribution before you even
attempt to compile a current X.

  Ralf

From owner-linux-mips@oss.sgi.com Sun Feb  4 21:27:02 2001
Received:  by oss.sgi.com id <S554158AbRBEF0x>;
	Sun, 4 Feb 2001 21:26:53 -0800
Received: from c824216-a.stcla1.sfba.home.com ([24.176.212.15]:37108 "EHLO
        dea.waldorf-gmbh.de") by oss.sgi.com with ESMTP id <S554101AbRBEF0d>;
	Sun, 4 Feb 2001 21:26:33 -0800
Received: (from ralf@localhost)
	by dea.waldorf-gmbh.de (8.11.1/8.11.1) id f155KNl27723;
	Sun, 4 Feb 2001 21:20:23 -0800
Date:   Sun, 4 Feb 2001 21:20:23 -0800
From:   Ralf Baechle <ralf@oss.sgi.com>
To:     Florian Lohoff <flo@rfc822.org>
Cc:     Kenneth C Barr <kbarr@MIT.EDU>, linux-mips@oss.sgi.com
Subject: Re: netbooting indy
Message-ID: <20010204212023.B27490@bacchus.dhis.org>
References: <Pine.LNX.4.30.0102010926190.20992-100000@springhead.px.uk.com> <Pine.GSO.4.30L.0102012329020.18202-100000@biohazard-cafe.mit.edu> <20010202103607.C18620@paradigm.rfc822.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <20010202103607.C18620@paradigm.rfc822.org>; from flo@rfc822.org on Fri, Feb 02, 2001 at 10:36:07AM +0100
X-Accept-Language: de,en,fr
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing

On Fri, Feb 02, 2001 at 10:36:07AM +0100, Florian Lohoff wrote:

> > 2.  Similar behavior with 3 different ELF kernel images (hardhat,
> > vmlinux-indy-2.2.1-990226, and the 2.4.0-test9).  I get the spinning
> 
> Ever tried using an ECOFF image ? Some proms cant load elf ..

If that's the problem the firmware will complain loudly.

  Ralf

From owner-linux-mips@oss.sgi.com Mon Feb  5 02:09:14 2001
Received:  by oss.sgi.com id <S554233AbRBEKJE>;
	Mon, 5 Feb 2001 02:09:04 -0800
Received: from c824216-a.stcla1.sfba.home.com ([24.176.212.15]:11513 "EHLO
        dea.waldorf-gmbh.de") by oss.sgi.com with ESMTP id <S554156AbRBEKIp>;
	Mon, 5 Feb 2001 02:08:45 -0800
Received: (from ralf@localhost)
	by dea.waldorf-gmbh.de (8.11.1/8.11.1) id f15A2fM30380;
	Mon, 5 Feb 2001 02:02:41 -0800
Date:   Mon, 5 Feb 2001 02:02:41 -0800
From:   Ralf Baechle <ralf@oss.sgi.com>
To:     Carsten Langgaard <carstenl@mips.com>
Cc:     linux-mips@oss.sgi.com
Subject: Re: Filesystem corruption
Message-ID: <20010205020241.A30062@bacchus.dhis.org>
References: <3A781F33.6B28D19C@mips.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <3A781F33.6B28D19C@mips.com>; from carstenl@mips.com on Wed, Jan 31, 2001 at 03:20:35PM +0100
X-Accept-Language: de,en,fr
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing

On Wed, Jan 31, 2001 at 03:20:35PM +0100, Carsten Langgaard wrote:

> Has anyone seen problems with fsck on the latest 2.4.0 kernel ?
> My filesystem gets corrupted from time to time when I use the latest
> 2.4.0 kernel.

2.4.1 is known to cause fs corruption for all architectures; 2.4.0 should
actually be fine.  I just reached 8 days of uptime on a 32p Origin 2000,
so it can't be that bad.

  Ralf

From owner-linux-mips@oss.sgi.com Mon Feb  5 04:10:13 2001
Received:  by oss.sgi.com id <S554115AbRBEMJy>;
	Mon, 5 Feb 2001 04:09:54 -0800
Received: from router-100M.swansea.linux.org.uk ([194.168.151.17]:51986 "EHLO
        the-village.bc.nu") by oss.sgi.com with ESMTP id <S554245AbRBEMJi>;
	Mon, 5 Feb 2001 04:09:38 -0800
Received: from alan by the-village.bc.nu with local (Exim 2.12 #1)
	id 14PkTf-0003DK-00; Mon, 5 Feb 2001 12:10:39 +0000
Subject: Re: Filesystem corruption
To:     ralf@oss.sgi.com (Ralf Baechle)
Date:   Mon, 5 Feb 2001 12:10:37 +0000 (GMT)
Cc:     carstenl@mips.com (Carsten Langgaard), linux-mips@oss.sgi.com
In-Reply-To: <20010205020241.A30062@bacchus.dhis.org> from "Ralf Baechle" at Feb 05, 2001 02:02:41 AM
X-Mailer: ELM [version 2.5 PL1]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <E14PkTf-0003DK-00@the-village.bc.nu>
From:   Alan Cox <alan@lxorguk.ukuu.org.uk>
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing

> 2.4.1 is known to cause fs corruption for all architectures; 2.4.0 should
> actually be fine.  I just reached 8 days of uptime on a 32p Origin 2000,
> so it can't be that bad.

Im tracking fs corruption and worse on 2.4.0 as well (zero page corruptions
since 2.4.0test10 for example)

I dont believe any 2.4 is currently 'safe'


From owner-linux-mips@oss.sgi.com Mon Feb  5 04:58:13 2001
Received:  by oss.sgi.com id <S554245AbRBEM5y>;
	Mon, 5 Feb 2001 04:57:54 -0800
Received: from mail.sonytel.be ([193.74.243.200]:50603 "EHLO mail.sonytel.be")
	by oss.sgi.com with ESMTP id <S553787AbRBEM5u>;
	Mon, 5 Feb 2001 04:57:50 -0800
Received: from escobaria.sonytel.be (escobaria.sonytel.be [10.34.80.3])
	by mail.sonytel.be (8.9.0/8.8.6) with ESMTP id NAA05332;
	Mon, 5 Feb 2001 13:56:54 +0100 (MET)
Date:   Mon, 5 Feb 2001 13:56:53 +0100 (MET)
From:   Geert Uytterhoeven <geert@linux-m68k.org>
To:     Alan Cox <alan@lxorguk.ukuu.org.uk>
cc:     Ralf Baechle <ralf@oss.sgi.com>,
        Carsten Langgaard <carstenl@mips.com>, linux-mips@oss.sgi.com
Subject: Re: Filesystem corruption
In-Reply-To: <E14PkTf-0003DK-00@the-village.bc.nu>
Message-ID: <Pine.GSO.4.10.10102051356090.1124-100000@escobaria.sonytel.be>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing

On Mon, 5 Feb 2001, Alan Cox wrote:
> > 2.4.1 is known to cause fs corruption for all architectures; 2.4.0 should
> > actually be fine.  I just reached 8 days of uptime on a 32p Origin 2000,
> > so it can't be that bad.
> 
> Im tracking fs corruption and worse on 2.4.0 as well (zero page corruptions
> since 2.4.0test10 for example)

Is the zero page mapped on non-m68k architectures?

> I dont believe any 2.4 is currently 'safe'

Ugh...

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds


From owner-linux-mips@oss.sgi.com Mon Feb  5 05:01:44 2001
Received:  by oss.sgi.com id <S554250AbRBENBY>;
	Mon, 5 Feb 2001 05:01:24 -0800
Received: from router-100M.swansea.linux.org.uk ([194.168.151.17]:3859 "EHLO
        the-village.bc.nu") by oss.sgi.com with ESMTP id <S554248AbRBENBP>;
	Mon, 5 Feb 2001 05:01:15 -0800
Received: from alan by the-village.bc.nu with local (Exim 2.12 #1)
	id 14PlGy-0003IW-00; Mon, 5 Feb 2001 13:01:36 +0000
Subject: Re: Filesystem corruption
To:     geert@linux-m68k.org (Geert Uytterhoeven)
Date:   Mon, 5 Feb 2001 13:01:33 +0000 (GMT)
Cc:     alan@lxorguk.ukuu.org.uk (Alan Cox),
        ralf@oss.sgi.com (Ralf Baechle),
        carstenl@mips.com (Carsten Langgaard), linux-mips@oss.sgi.com
In-Reply-To: <Pine.GSO.4.10.10102051356090.1124-100000@escobaria.sonytel.be> from "Geert Uytterhoeven" at Feb 05, 2001 01:56:53 PM
X-Mailer: ELM [version 2.5 PL1]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <E14PlGy-0003IW-00@the-village.bc.nu>
From:   Alan Cox <alan@lxorguk.ukuu.org.uk>
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing

> Is the zero page mapped on non-m68k architectures?

It can certainly be hit by DMA and kernel memory ops

> > I dont believe any 2.4 is currently 'safe'
> Ugh...

We'll get there, its doing pretty well for most folks


From owner-linux-mips@oss.sgi.com Mon Feb  5 05:15:43 2001
Received:  by oss.sgi.com id <S554248AbRBENPe>;
	Mon, 5 Feb 2001 05:15:34 -0800
Received: from woody.ichilton.co.uk ([216.29.174.40]:5637 "HELO
        woody.ichilton.co.uk") by oss.sgi.com with SMTP id <S553787AbRBENPK>;
	Mon, 5 Feb 2001 05:15:10 -0800
Received: by woody.ichilton.co.uk (Postfix, from userid 1000)
	id 3F82E7D14; Mon,  5 Feb 2001 13:16:10 +0000 (GMT)
Date:   Mon, 5 Feb 2001 13:16:10 +0000
From:   Ian Chilton <mailinglist@ichilton.co.uk>
To:     Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc:     linux-mips@oss.sgi.com
Subject: Re: Filesystem corruption
Message-ID: <20010205131610.A31306@woody.ichilton.co.uk>
Reply-To: Ian Chilton <ian@ichilton.co.uk>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.3.12i
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing

Hello,

> I dont believe any 2.4 is currently 'safe'

auchhh..

If Alan Cox himself (nearly as bad as Linus saying it..) is saying
that, I am glad I am still running 2.2.17/18 on my servers and am
wondering if I should have upgraded my workstations to 2.4.1  ;(


Bye for Now,

Ian

                                \|||/
                                (o o)
 /---------------------------ooO-(_)-Ooo---------------------------\
 |  Ian Chilton        (IRC Nick - GadgetMan)     ICQ #: 16007717  |
 |-----------------------------------------------------------------|
 |  E-Mail: ian@ichilton.co.uk     Web: http://www.ichilton.co.uk  |
 |-----------------------------------------------------------------|
 |        Proofread carefully to see if you any words out.         |
 \-----------------------------------------------------------------/


From owner-linux-mips@oss.sgi.com Mon Feb  5 07:43:54 2001
Received:  by oss.sgi.com id <S554258AbRBEPnq>;
	Mon, 5 Feb 2001 07:43:46 -0800
Received: from sovereign.org ([209.180.91.170]:27526 "EHLO lux.homenet")
	by oss.sgi.com with ESMTP id <S554255AbRBEPnd>;
	Mon, 5 Feb 2001 07:43:33 -0800
Received: (from jfree@localhost)
	by lux.homenet (8.11.2/8.11.2/Debian 8.11.2-1) id f15Fhdd07846
	for linux-mips@oss.sgi.com; Mon, 5 Feb 2001 08:43:39 -0700
From:   Jim Freeman <jfree@sovereign.org>
Date:   Mon, 5 Feb 2001 08:43:38 -0700
To:     linux-mips@oss.sgi.com
Subject: mips/config.in: CONFIG_SMP ?
Message-ID: <20010205084338.A7739@sovereign.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.3.12i
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing

One of the following patches should be applied (parisc/config.in
does the former ...) ?


--- linux/arch/mips/config.in	2001/02/05 15:17:46	1.1
+++ linux/arch/mips/config.in	2001/02/05 15:40:52
@@ -3,6 +3,7 @@
 # see Documentation/kbuild/config-language.txt.
 #
 define_bool CONFIG_MIPS y
+define_bool CONFIG_SMP n
 
 mainmenu_name "Linux Kernel Configuration"
 



--- linux/arch/mips/config.in	2001/02/05 15:17:46	1.1
+++ linux/arch/mips/config.in	2001/02/05 15:18:06
@@ -460,7 +460,5 @@
   bool 'Remote GDB kernel debugging' CONFIG_REMOTE_DEBUG
 fi
 bool 'Magic SysRq key' CONFIG_MAGIC_SYSRQ
-if [ "$CONFIG_SMP" != "y" ]; then
-   bool 'Run uncached' CONFIG_MIPS_UNCACHED
-fi
+bool 'Run uncached' CONFIG_MIPS_UNCACHED
 endmenu

From owner-linux-mips@oss.sgi.com Mon Feb  5 07:59:44 2001
Received:  by oss.sgi.com id <S554262AbRBEP7Y>;
	Mon, 5 Feb 2001 07:59:24 -0800
Received: from woody.ichilton.co.uk ([216.29.174.40]:7941 "HELO
        woody.ichilton.co.uk") by oss.sgi.com with SMTP id <S554259AbRBEP7F>;
	Mon, 5 Feb 2001 07:59:05 -0800
Received: by woody.ichilton.co.uk (Postfix, from userid 1000)
	id 8DA227D16; Mon,  5 Feb 2001 16:00:07 +0000 (GMT)
Date:   Mon, 5 Feb 2001 16:00:07 +0000
From:   Ian Chilton <ian@ichilton.co.uk>
To:     "J. Scott Kasten" <jsk@tetracon-eng.net>
Cc:     linux-mips@oss.sgi.com
Subject: Re: Filesystem corruption
Message-ID: <20010205160007.A31490@woody.ichilton.co.uk>
Reply-To: Ian Chilton <ian@ichilton.co.uk>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.3.12i
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing

Hello,

> If you're worried about it, do what I do.  Pick one server that always
> runs a known stable release and keep your working/home directories on it
> as NFS exports.  Run your development kernel/tools on an NFS client box.
> That way when it croaks, you don't wast a lot of you time fscking and
> possibly loosing files.


That's basically what I do..


Bye for Now,

Ian


                                \|||/ 
                                (o o)
 /---------------------------ooO-(_)-Ooo---------------------------\
 |  Ian Chilton        (IRC Nick - GadgetMan)     ICQ #: 16007717  |
 |-----------------------------------------------------------------|
 |  E-Mail: ian@ichilton.co.uk     Web: http://www.ichilton.co.uk  |
 |-----------------------------------------------------------------|
 |         Budget: A method for going broke methodically.          |
 \-----------------------------------------------------------------/


From owner-linux-mips@oss.sgi.com Mon Feb  5 08:51:34 2001
Received:  by oss.sgi.com id <S554246AbRBEQvP>;
	Mon, 5 Feb 2001 08:51:15 -0800
Received: from stereotomy.lineo.com ([64.50.107.151]:55054 "HELO
        stereotomy.lineo.com") by oss.sgi.com with SMTP id <S553839AbRBEQu5>;
	Mon, 5 Feb 2001 08:50:57 -0800
Received: from Lineo.COM (localhost.localdomain [127.0.0.1])
	by stereotomy.lineo.com (Postfix) with ESMTP
	id 407274CC5F; Mon,  5 Feb 2001 09:50:52 -0700 (MST)
Message-ID: <3A7ED9EB.6080801@Lineo.COM>
Date:   Mon, 05 Feb 2001 09:50:51 -0700
From:   Quinn Jensen <jensenq@Lineo.COM>
Organization: Lineo, Inc.
User-Agent: Mozilla/5.0 (X11; U; Linux 2.2.16-9mdk i686; en-US; m18) Gecko/20001107 Netscape6/6.0
X-Accept-Language: en
MIME-Version: 1.0
To:     Ralf Baechle <ralf@oss.sgi.com>
Cc:     linux-mips@oss.sgi.com
Subject: Re: NFS root with cache on
References: <3A79C869.2040001@Lineo.COM> <20010204194451.A26868@bacchus.dhis.org>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing


>> Is anyone else having trouble with NFS root on
>> the 2.4.0 kernel?  It won't come up with the
>> KSEG0 cache on unless I pepper the network driver
>> with flush calls.
> 
> 
> That's expected for most old network drivers that don't yet use the
> new PCI DMA API documented in Documentation/DMA-mapping.txt.
> 
> What driver is this?

Both the stock 2.4.0 tulip and eepro100 drivers.  The
problem doesn't happen when I go back to 2.3.99pre8.

In the tulip driver, both the rx and tx ring descriptors
are adjusted with pci_alloc_consistent() and are only
touched through KSEG1.

But I must be totally clueless because in both kernels
tulip_rx() calls pci_unmap_single() which does nothing.
But the skb data pointers all point to KSEG0.  With
cache on, how in the world will the kernel be able to
see what just got DMA'd into the skb?

Another thing that has been haunting me is that
in 2.3.99pre8, kmalloc() has and #ifdef __mips__ that
flushes the cache and bumps the address up to KSEG1.
This is gone in 2.4.0, but from what I can tell, this
case didn't happen for skb allocations (i.e. dev_alloc_skb)
because they only set GFP_ATOMIC, and not GFP_DMA.

Quinn




From owner-linux-mips@oss.sgi.com Mon Feb  5 09:02:05 2001
Received:  by oss.sgi.com id <S554268AbRBERBz>;
	Mon, 5 Feb 2001 09:01:55 -0800
Received: from mx.mips.com ([206.31.31.226]:18830 "EHLO mx.mips.com")
	by oss.sgi.com with ESMTP id <S553839AbRBERBb>;
	Mon, 5 Feb 2001 09:01:31 -0800
Received: from newman.mips.com (ns-dmz [206.31.31.225])
	by mx.mips.com (8.9.3/8.9.0) with ESMTP id JAA01961;
	Mon, 5 Feb 2001 09:01:28 -0800 (PST)
Received: from grendel (grendel [192.168.236.16])
	by newman.mips.com (8.9.3/8.9.0) with SMTP id JAA06230;
	Mon, 5 Feb 2001 09:01:26 -0800 (PST)
Message-ID: <007701c08f94$7de62360$10eca8c0@grendel>
From:   "Kevin D. Kissell" <kevink@mips.com>
To:     "Quinn Jensen" <jensenq@lineo.com>,
        "Ralf Baechle" <ralf@oss.sgi.com>
Cc:     <linux-mips@oss.sgi.com>
References: <3A79C869.2040001@Lineo.COM> <20010204194451.A26868@bacchus.dhis.org> <3A7ED9EB.6080801@Lineo.COM>
Subject: Re: NFS root with cache on
Date:   Mon, 5 Feb 2001 17:55:39 +0100
Organization: MIPS Technologies, Inc.
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing

> Another thing that has been haunting me is that
> in 2.3.99pre8, kmalloc() has and #ifdef __mips__ that
> flushes the cache and bumps the address up to KSEG1.

That's really hideous!  When did that happen?
It'll sure help cache coherency problems, but
the performance impact must have been monstrous.

            Kevin K.


From owner-linux-mips@oss.sgi.com Mon Feb  5 10:09:05 2001
Received:  by oss.sgi.com id <S554032AbRBESIp>;
	Mon, 5 Feb 2001 10:08:45 -0800
Received: from gateway-1237.mvista.com ([12.44.186.158]:36085 "EHLO
        hermes.mvista.com") by oss.sgi.com with ESMTP id <S554024AbRBESIl>;
	Mon, 5 Feb 2001 10:08:41 -0800
Received: from mvista.com (IDENT:jsun@orion.mvista.com [10.0.0.75])
	by hermes.mvista.com (8.11.0/8.11.0) with ESMTP id f15I59I27128;
	Mon, 5 Feb 2001 10:05:09 -0800
Message-ID: <3A7EEBD6.F4743A97@mvista.com>
Date:   Mon, 05 Feb 2001 10:07:18 -0800
From:   Jun Sun <jsun@mvista.com>
X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14-5.0 i686)
X-Accept-Language: en
MIME-Version: 1.0
To:     Quinn Jensen <jensenq@Lineo.COM>
CC:     Ralf Baechle <ralf@oss.sgi.com>, linux-mips@oss.sgi.com
Subject: Re: NFS root with cache on
References: <3A79C869.2040001@Lineo.COM> <20010204194451.A26868@bacchus.dhis.org> <3A7ED9EB.6080801@Lineo.COM>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing

Quinn Jensen wrote:
> 
> >> Is anyone else having trouble with NFS root on
> >> the 2.4.0 kernel?  It won't come up with the
> >> KSEG0 cache on unless I pepper the network driver
> >> with flush calls.
> >
> >
> > That's expected for most old network drivers that don't yet use the
> > new PCI DMA API documented in Documentation/DMA-mapping.txt.
> >
> > What driver is this?
> 
> Both the stock 2.4.0 tulip and eepro100 drivers.  The
> problem doesn't happen when I go back to 2.3.99pre8.
> 

Quinn,

Did you set rx_copybreak to 1518?  I sent patches long time ago to the driver
authors for MIPS, but I am not sure they are not there.

Jun

From owner-linux-mips@oss.sgi.com Mon Feb  5 10:43:36 2001
Received:  by oss.sgi.com id <S554100AbRBESnR>;
	Mon, 5 Feb 2001 10:43:17 -0800
Received: from stereotomy.lineo.com ([64.50.107.151]:32527 "HELO
        stereotomy.lineo.com") by oss.sgi.com with SMTP id <S554081AbRBESnA>;
	Mon, 5 Feb 2001 10:43:00 -0800
Received: from Lineo.COM (localhost.localdomain [127.0.0.1])
	by stereotomy.lineo.com (Postfix) with ESMTP
	id 2C01E4CC5F; Mon,  5 Feb 2001 11:42:58 -0700 (MST)
Message-ID: <3A7EF431.2060903@Lineo.COM>
Date:   Mon, 05 Feb 2001 11:42:57 -0700
From:   Quinn Jensen <jensenq@Lineo.COM>
Organization: Lineo, Inc.
User-Agent: Mozilla/5.0 (X11; U; Linux 2.2.16-9mdk i686; en-US; m18) Gecko/20001107 Netscape6/6.0
X-Accept-Language: en
MIME-Version: 1.0
To:     jsun@hermes.mvista.com
Cc:     Ralf Baechle <ralf@oss.sgi.com>, linux-mips@oss.sgi.com
Subject: Re: NFS root with cache on
References: <3A79C869.2040001@Lineo.COM> <20010204194451.A26868@bacchus.dhis.org> <3A7ED9EB.6080801@Lineo.COM> <3A7EEBD6.F4743A97@mvista.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing


jsun@hermes.mvista.com wrote:

> Quinn Jensen wrote:
> 
>>>> Is anyone else having trouble with NFS root on
>>>> the 2.4.0 kernel?  It won't come up with the
>>>> KSEG0 cache on unless I pepper the network driver
>>>> with flush calls.
>>> 
>>> 
>>> That's expected for most old network drivers that don't yet use tye
he
>>> new PCI DMA API documented in Documentation/DMA-mapping.txt.
>>> 
>>> What driver is this?
>> 
>> Both the stock 2.4.0 tulip and eepro100 drivers.  The
>> problem doesn't happen when I go back to 2.3.99pre8.
>> 
> 
> Did you set rx_copybreak to 1518?  I sent patches long time ago to the driver
> authors for MIPS, but I am not sure they are not there.

Jun,

I have tried that in this case but it didn't help,
because the receive skb data pointers all point to
the KSEG0 view of the data anyway.  But the maddening
thing is, when I force them to KSEG1 I still see the
NFS timeout problem.  So I'm starting to wonder if
the problem is higher up in the stack.  But I do know
that the behavior does not occur on a similarly configured
x86 build of the same kernel.

Quinn


From owner-linux-mips@oss.sgi.com Mon Feb  5 11:03:37 2001
Received:  by oss.sgi.com id <S553861AbRBETD1>;
	Mon, 5 Feb 2001 11:03:27 -0800
Received: from mail.ivm.net ([62.204.1.4]:31532 "EHLO mail.ivm.net")
	by oss.sgi.com with ESMTP id <S553753AbRBETDR>;
	Mon, 5 Feb 2001 11:03:17 -0800
Received: from franz.no.dom (port37.duesseldorf.ivm.de [195.247.65.37])
	by mail.ivm.net (8.8.8/8.8.8) with ESMTP id UAA09921;
	Mon, 5 Feb 2001 20:03:06 +0100
X-To:   linux-mips@oss.sgi.com
Message-ID: <XFMail.010205200312.Harald.Koerfgen@home.ivm.de>
X-Mailer: XFMail 1.4.0 on Linux
X-Priority: 3 (Normal)
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
In-Reply-To: <20010203162758.A1986@paradigm.rfc822.org>
Date:   Mon, 05 Feb 2001 20:03:12 +0100 (CET)
Reply-To: Harald Koerfgen <Harald.Koerfgen@home.ivm.de>
Organization: none
From:   Harald Koerfgen <Harald.Koerfgen@home.ivm.de>
To:     Florian Lohoff <flo@rfc822.org>
Subject: RE: [PATCH] R3912 mm stuff from linux-vr tree
Cc:     linux-mips@oss.sgi.com
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing


On 03-Feb-01 Florian Lohoff wrote:
> here is a patch against the OSS tree to basically add R3912
> support - It has mainly be done by Harald Koerfgen - I did basically
> change the stuff to get it into the oss tree. 

Now that I am seeing the stuff again I would say that it's in badly need of
some polishing here and there :)

-- 
Regards,
Harald

From owner-linux-mips@oss.sgi.com Mon Feb  5 11:17:07 2001
Received:  by oss.sgi.com id <S554102AbRBETQ5>;
	Mon, 5 Feb 2001 11:16:57 -0800
Received: from gateway-1237.mvista.com ([12.44.186.158]:41722 "EHLO
        hermes.mvista.com") by oss.sgi.com with ESMTP id <S553987AbRBETQn>;
	Mon, 5 Feb 2001 11:16:43 -0800
Received: from mvista.com (IDENT:jsun@orion.mvista.com [10.0.0.75])
	by hermes.mvista.com (8.11.0/8.11.0) with ESMTP id f15JDAI31829;
	Mon, 5 Feb 2001 11:13:10 -0800
Message-ID: <3A7EFBC7.9B7D6AF9@mvista.com>
Date:   Mon, 05 Feb 2001 11:15:19 -0800
From:   Jun Sun <jsun@mvista.com>
X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14-5.0 i686)
X-Accept-Language: en
MIME-Version: 1.0
To:     Quinn Jensen <jensenq@Lineo.COM>
CC:     jsun@hermes.mvista.com, Ralf Baechle <ralf@oss.sgi.com>,
        linux-mips@oss.sgi.com
Subject: Re: NFS root with cache on
References: <3A79C869.2040001@Lineo.COM> <20010204194451.A26868@bacchus.dhis.org> <3A7ED9EB.6080801@Lineo.COM> <3A7EEBD6.F4743A97@mvista.com> <3A7EF431.2060903@Lineo.COM>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing

Quinn Jensen wrote:
> 
> jsun@hermes.mvista.com wrote:
> 
> > Quinn Jensen wrote:
> >
> >>>> Is anyone else having trouble with NFS root on
> >>>> the 2.4.0 kernel?  It won't come up with the
> >>>> KSEG0 cache on unless I pepper the network driver
> >>>> with flush calls.
> >>>
> >>>
> >>> That's expected for most old network drivers that don't yet use tye
> he
> >>> new PCI DMA API documented in Documentation/DMA-mapping.txt.
> >>>
> >>> What driver is this?
> >>
> >> Both the stock 2.4.0 tulip and eepro100 drivers.  The
> >> problem doesn't happen when I go back to 2.3.99pre8.
> >>
> >
> > Did you set rx_copybreak to 1518?  I sent patches long time ago to the driver
> > authors for MIPS, but I am not sure they are not there.
> 
> Jun,
> 
> I have tried that in this case but it didn't help,
> because the receive skb data pointers all point to
> the KSEG0 view of the data anyway. 

I looked into similar problems a while back.  If I remeber correctly, the data
pointers do point to kseg0.  It is up to the driver to do appropriate
dma_cache_invalidate() (or some functions to that effect) at certain places.

What is the CPU?  It seems logical to suspect about the dma cache routines.

Jun

From owner-linux-mips@oss.sgi.com Mon Feb  5 11:57:57 2001
Received:  by oss.sgi.com id <S554162AbRBET5i>;
	Mon, 5 Feb 2001 11:57:38 -0800
Received: from sgigate.SGI.COM ([204.94.209.1]:41517 "EHLO dea.waldorf-gmbh.de")
	by oss.sgi.com with ESMTP id <S554129AbRBET5K>;
	Mon, 5 Feb 2001 11:57:10 -0800
Received: (from ralf@localhost)
	by dea.waldorf-gmbh.de (8.11.1/8.11.1) id f15JoQo02975;
	Mon, 5 Feb 2001 11:50:26 -0800
Date:   Mon, 5 Feb 2001 11:50:26 -0800
From:   Ralf Baechle <ralf@oss.sgi.com>
To:     Jun Sun <jsun@mvista.com>
Cc:     Quinn Jensen <jensenq@Lineo.COM>, linux-mips@oss.sgi.com
Subject: Re: NFS root with cache on
Message-ID: <20010205115026.C2487@bacchus.dhis.org>
References: <3A79C869.2040001@Lineo.COM> <20010204194451.A26868@bacchus.dhis.org> <3A7ED9EB.6080801@Lineo.COM> <3A7EEBD6.F4743A97@mvista.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <3A7EEBD6.F4743A97@mvista.com>; from jsun@mvista.com on Mon, Feb 05, 2001 at 10:07:18AM -0800
X-Accept-Language: de,en,fr
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing

On Mon, Feb 05, 2001 at 10:07:18AM -0800, Jun Sun wrote:

> Did you set rx_copybreak to 1518?  I sent patches long time ago to the driver
> authors for MIPS, but I am not sure they are not there.

Copybreak is just an optimization.  So even with this unused or set to a
wrong value the driver should work.

  Ralf

From owner-linux-mips@oss.sgi.com Mon Feb  5 13:15:47 2001
Received:  by oss.sgi.com id <S554193AbRBEVP0>;
	Mon, 5 Feb 2001 13:15:26 -0800
Received: from stereotomy.lineo.com ([64.50.107.151]:57359 "HELO
        stereotomy.lineo.com") by oss.sgi.com with SMTP id <S554184AbRBEVPA>;
	Mon, 5 Feb 2001 13:15:00 -0800
Received: from Lineo.COM (localhost.localdomain [127.0.0.1])
	by stereotomy.lineo.com (Postfix) with ESMTP
	id 2C41B4CE9E; Mon,  5 Feb 2001 14:14:48 -0700 (MST)
Message-ID: <3A7F17C7.4070406@Lineo.COM>
Date:   Mon, 05 Feb 2001 14:14:47 -0700
From:   Quinn Jensen <jensenq@Lineo.COM>
Organization: Lineo, Inc.
User-Agent: Mozilla/5.0 (X11; U; Linux 2.2.16-9mdk i686; en-US; m18) Gecko/20001107 Netscape6/6.0
X-Accept-Language: en
MIME-Version: 1.0
To:     jsun@hermes.mvista.com
Cc:     Ralf Baechle <ralf@oss.sgi.com>, linux-mips@oss.sgi.com
Subject: Re: NFS root with cache on
References: <3A79C869.2040001@Lineo.COM> <20010204194451.A26868@bacchus.dhis.org> <3A7ED9EB.6080801@Lineo.COM> <3A7EEBD6.F4743A97@mvista.com> <3A7EF431.2060903@Lineo.COM> <3A7EFBC7.9B7D6AF9@mvista.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing

jsun@hermes.mvista.com wrote:

>> 
>> I have tried that in this case but it didn't help,
>> because the receive skb data pointers all point to
>> the KSEG0 view of the data anyway. 
> 
> 
> I looked into similar problems a while back.  If I remeber correctly, the data
> pointers do point to kseg0.  It is up to the driver to do appropriate
> dma_cache_invalidate() (or some functions to that effect) at certain places.

Yes, the tulip driver calls pci_unmap_single() on the receive
buffer, but for mips (in asm-mips/pci.h) this call does
nothing.  And this is what is so confusing.  Only if the
receive buffer was forced to be in KSEG1 would this make
sense.

> 
> What is the CPU?  It seems logical to suspect about the dma cache routines.

Yes, I have scrubbed over my patch to the cache routines
many times, especially since on the IDT 334 the cache-way
selection for indexed cache ops is weird--they left the
way-bit up at bit 12 as if it were an 8KB cache, when
in reality it is only a 2KB cache.

Quinn



From owner-linux-mips@oss.sgi.com Mon Feb  5 13:17:57 2001
Received:  by oss.sgi.com id <S554269AbRBEVRr>;
	Mon, 5 Feb 2001 13:17:47 -0800
Received: from PACIFIC-CARRIER-ANNEX.MIT.EDU ([18.69.0.28]:274 "HELO MIT.EDU")
	by oss.sgi.com with SMTP id <S554190AbRBEVRb>;
	Mon, 5 Feb 2001 13:17:31 -0800
Received: from GRAND-CENTRAL-STATION.MIT.EDU by MIT.EDU with SMTP
	id AA22760; Mon, 5 Feb 01 16:19:32 EST
Received: from melbourne-city-street.MIT.EDU (MELBOURNE-CITY-STREET.MIT.EDU [18.69.0.45])
	by grand-central-station.MIT.EDU (8.9.2/8.9.2) with ESMTP id QAA21591
	for <linux-mips@oss.sgi.com>; Mon, 5 Feb 2001 16:13:25 -0500 (EST)
Received: from w20-575-66.mit.edu (W20-575-66.MIT.EDU [18.187.1.21])
	by melbourne-city-street.MIT.EDU (8.9.3/8.9.2) with ESMTP id QAA05137
	for <linux-mips@oss.sgi.com>; Mon, 5 Feb 2001 16:13:25 -0500 (EST)
Received: from localhost (kbarr@localhost) by w20-575-66.mit.edu (8.9.3) with ESMTP
	id QAA195850; Mon, 5 Feb 2001 16:13:24 -0500 (EST)
Date:   Mon, 5 Feb 2001 16:13:23 -0500
From:   Kenneth C Barr <kbarr@MIT.EDU>
To:     <linux-mips@oss.sgi.com>
Subject: netbooting indy - update, elf2ecoff?
In-Reply-To: <20010205115026.C2487@bacchus.dhis.org>
Message-Id: <Pine.SGI.4.30L.0102051604550.234337-100000@w20-575-66.mit.edu>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing

Thank you very much for your help so far!  Here's an update and another
question:

Updates:
1.  Had to attach a console (we have XZ graphics not XL)
2.  An ecoff kernel image downloaded fine.  The ELF ones download halfway
and fail silently (even with the console attached)

Question: As the vmlinux-indy-2.2.1-990226.ecoff kernel begins the boot
sequence, it hangs at "unable to open initial console."  I had unpacked
the filesystem on linux as the FAQ suggests, and my device files look
right.  So, on the NFS server, I symlinked /dev/console to /dev/ttyS0.
Now the message is replaced with a cryptic: "S<<<<<"

Perhaps that kernel doesn't have console support?  Is there any other
explanation for the "S<<<<<" failure where I used to see "...initial
console?"

I'd like to try a different kernel but I can't find an elf2ecoff binary.
Does anyone have this converted or a known-good ecoff kernel?

Ken


From owner-linux-mips@oss.sgi.com Mon Feb  5 13:39:16 2001
Received:  by oss.sgi.com id <S554221AbRBEVjH>;
	Mon, 5 Feb 2001 13:39:07 -0800
Received: from router-100M.swansea.linux.org.uk ([194.168.151.17]:3335 "EHLO
        the-village.bc.nu") by oss.sgi.com with ESMTP id <S554120AbRBEViw>;
	Mon, 5 Feb 2001 13:38:52 -0800
Received: from alan by the-village.bc.nu with local (Exim 2.12 #1)
	id 14PtMY-0004Ei-00; Mon, 5 Feb 2001 21:39:54 +0000
Subject: Re: NFS root with cache on
To:     ralf@oss.sgi.com (Ralf Baechle)
Date:   Mon, 5 Feb 2001 21:39:51 +0000 (GMT)
Cc:     jsun@mvista.com (Jun Sun), jensenq@Lineo.COM (Quinn Jensen),
        linux-mips@oss.sgi.com
In-Reply-To: <20010205115026.C2487@bacchus.dhis.org> from "Ralf Baechle" at Feb 05, 2001 11:50:26 AM
X-Mailer: ELM [version 2.5 PL1]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <E14PtMY-0004Ei-00@the-village.bc.nu>
From:   Alan Cox <alan@lxorguk.ukuu.org.uk>
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing

> On Mon, Feb 05, 2001 at 10:07:18AM -0800, Jun Sun wrote:
> 
> > Did you set rx_copybreak to 1518?  I sent patches long time ago to the driver
> > authors for MIPS, but I am not sure they are not there.
> 
> Copybreak is just an optimization.  So even with this unused or set to a
> wrong value the driver should work.

If you set it wrongly you can get network failures/stalls. The normal cases
are not a problem however. You need to copybreak small frames to avoid filling
the socket queue with empty spaces. Some platforms set it to 1518 to force
a copy thereby aligning the IP header on a 4 byte boundary, which most
PCI bus master drivers wont do if you are not copying


From owner-linux-mips@oss.sgi.com Mon Feb  5 14:08:37 2001
Received:  by oss.sgi.com id <S554040AbRBEWIR>;
	Mon, 5 Feb 2001 14:08:17 -0800
Received: from sgigate.SGI.COM ([204.94.209.1]:18902 "EHLO dea.waldorf-gmbh.de")
	by oss.sgi.com with ESMTP id <S553765AbRBEWH5>;
	Mon, 5 Feb 2001 14:07:57 -0800
Received: (from ralf@localhost)
	by dea.waldorf-gmbh.de (8.11.1/8.11.1) id f15M1E004103;
	Mon, 5 Feb 2001 14:01:14 -0800
Date:   Mon, 5 Feb 2001 14:01:14 -0800
From:   Ralf Baechle <ralf@oss.sgi.com>
To:     Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc:     geert@linux-m68k.org (Geert Uytterhoeven),
        carstenl@mips.com (Carsten Langgaard), linux-mips@oss.sgi.com
Subject: Re: Filesystem corruption
Message-ID: <20010205140114.D3880@bacchus.dhis.org>
References: <Pine.GSO.4.10.10102051356090.1124-100000@escobaria.sonytel.be> <E14PlGy-0003IW-00@the-village.bc.nu>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <E14PlGy-0003IW-00@the-village.bc.nu>; from alan@lxorguk.ukuu.org.uk on Mon, Feb 05, 2001 at 01:01:33PM +0000
X-Accept-Language: de,en,fr
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing

On Mon, Feb 05, 2001 at 01:01:33PM +0000, Alan Cox wrote:

> > Is the zero page mapped on non-m68k architectures?
> 
> It can certainly be hit by DMA and kernel memory ops
> 
> > > I dont believe any 2.4 is currently 'safe'
> > Ugh...
> 
> We'll get there, its doing pretty well for most folks

I hope so.  For many of us 2.2 is no longer an option.  That is at least
without heavy patching to add support for hardware that isn't supported
by 2.2.

  Ralf

From owner-linux-mips@oss.sgi.com Mon Feb  5 15:49:08 2001
Received:  by oss.sgi.com id <S554071AbRBEXs6>;
	Mon, 5 Feb 2001 15:48:58 -0800
Received: from sgigate.SGI.COM ([204.94.209.1]:2670 "EHLO dea.waldorf-gmbh.de")
	by oss.sgi.com with ESMTP id <S554001AbRBEXsl>;
	Mon, 5 Feb 2001 15:48:41 -0800
Received: (from ralf@localhost)
	by dea.waldorf-gmbh.de (8.11.1/8.11.1) id f15Ngk806293;
	Mon, 5 Feb 2001 15:42:46 -0800
Date:   Mon, 5 Feb 2001 15:42:46 -0800
From:   Ralf Baechle <ralf@oss.sgi.com>
To:     Jim Freeman <jfree@sovereign.org>
Cc:     linux-mips@oss.sgi.com
Subject: Re: mips/config.in: CONFIG_SMP ?
Message-ID: <20010205154245.A959@bacchus.dhis.org>
References: <20010205084338.A7739@sovereign.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <20010205084338.A7739@sovereign.org>; from jfree@sovereign.org on Mon, Feb 05, 2001 at 08:43:38AM -0700
X-Accept-Language: de,en,fr
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing

On Mon, Feb 05, 2001 at 08:43:38AM -0700, Jim Freeman wrote:

> One of the following patches should be applied (parisc/config.in
> does the former ...) ?

So did I.  Applied.

  Ralf

From owner-linux-mips@oss.sgi.com Mon Feb  5 22:34:30 2001
Received:  by oss.sgi.com id <S553855AbRBFGeU>;
	Mon, 5 Feb 2001 22:34:20 -0800
Received: from mail.sonytel.be ([193.74.243.200]:41390 "EHLO mail.sonytel.be")
	by oss.sgi.com with ESMTP id <S553792AbRBFGd5>;
	Mon, 5 Feb 2001 22:33:57 -0800
Received: from escobaria.sonytel.be (escobaria.sonytel.be [10.34.80.3])
	by mail.sonytel.be (8.9.0/8.8.6) with ESMTP id HAA06451;
	Tue, 6 Feb 2001 07:32:53 +0100 (MET)
Date:   Tue, 6 Feb 2001 07:32:53 +0100 (MET)
From:   Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com>
To:     Kenneth C Barr <kbarr@MIT.EDU>
cc:     linux-mips@oss.sgi.com
Subject: Re: netbooting indy - update, elf2ecoff?
In-Reply-To: <Pine.SGI.4.30L.0102051604550.234337-100000@w20-575-66.mit.edu>
Message-ID: <Pine.GSO.4.10.10102060732080.15534-100000@escobaria.sonytel.be>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing

On Mon, 5 Feb 2001, Kenneth C Barr wrote:
> Question: As the vmlinux-indy-2.2.1-990226.ecoff kernel begins the boot
> sequence, it hangs at "unable to open initial console."  I had unpacked
> the filesystem on linux as the FAQ suggests, and my device files look
> right.  So, on the NFS server, I symlinked /dev/console to /dev/ttyS0.
> Now the message is replaced with a cryptic: "S<<<<<"

However, /dev/console must _not_ be a symlink, but a character special device
with major 5 minor 1 (cfr. Documentation/devices.txt).

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven ------------- Sony Software Development Center Europe (SDCE)
Geert.Uytterhoeven@sonycom.com ------------------- Sint-Stevens-Woluwestraat 55
Voice +32-2-7248626 Fax +32-2-7262686 ---------------- B-1130 Brussels, Belgium


From owner-linux-mips@oss.sgi.com Tue Feb  6 08:08:47 2001
Received:  by oss.sgi.com id <S553882AbRBFQI1>;
	Tue, 6 Feb 2001 08:08:27 -0800
Received: from mx.mips.com ([206.31.31.226]:4004 "EHLO mx.mips.com")
	by oss.sgi.com with ESMTP id <S553879AbRBFQIU>;
	Tue, 6 Feb 2001 08:08:20 -0800
Received: from newman.mips.com (ns-dmz [206.31.31.225])
	by mx.mips.com (8.9.3/8.9.0) with ESMTP id IAA16433
	for <linux-mips@oss.sgi.com>; Tue, 6 Feb 2001 08:08:14 -0800 (PST)
Received: from copfs01.mips.com (copfs01 [192.168.205.101])
	by newman.mips.com (8.9.3/8.9.0) with ESMTP id IAA14561
	for <linux-mips@oss.sgi.com>; Tue, 6 Feb 2001 08:08:12 -0800 (PST)
Received: from mips.com (copsun17 [192.168.205.27])
	by copfs01.mips.com (8.9.1/8.9.0) with ESMTP id RAA10688
	for <linux-mips@oss.sgi.com>; Tue, 6 Feb 2001 17:07:59 +0100 (MET)
Message-ID: <3A80215E.D13FE590@mips.com>
Date:   Tue, 06 Feb 2001 17:07:58 +0100
From:   Carsten Langgaard <carstenl@mips.com>
X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To:     linux-mips@oss.sgi.com
Subject: The FPU emulator doesn't work properly
Content-Type: text/plain; charset=iso-8859-15
Content-Transfer-Encoding: 7bit
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing

I think I have send this patch before, but it hasn't got in to the
archive, apparently.
This is needed in order to get the FPU emulator work properly.


Index: arch/mips/kernel/branch.c
===================================================================
RCS file: /home/repository/sw/linux-2.4.0/arch/mips/kernel/branch.c,v
retrieving revision 1.3
diff -u -r1.3 branch.c
--- branch.c    2000/12/05 13:46:12     1.3
+++ branch.c    2001/02/06 15:46:53
@@ -69,7 +69,7 @@
                switch (insn.i_format.rt) {
                case bltz_op:
                case bltzl_op:
-                       if (regs->regs[insn.i_format.rs] < 0)
+                       if ((long)regs->regs[insn.i_format.rs] < 0)
                                epc = epc + 4 +
(insn.i_format.simmediate << 2);
                        else
                                epc += 8;
@@ -78,7 +78,7 @@

                case bgez_op:
                case bgezl_op:
-                       if (regs->regs[insn.i_format.rs] >= 0)
+                       if ((long)regs->regs[insn.i_format.rs] >= 0)
                                epc = epc + 4 +
(insn.i_format.simmediate << 2);
                        else
                                epc += 8;
@@ -88,7 +88,7 @@
                case bltzal_op:
                case bltzall_op:
                        regs->regs[31] = epc + 8;
-                       if (regs->regs[insn.i_format.rs] < 0)
+                       if ((long)regs->regs[insn.i_format.rs] < 0)
                                epc = epc + 4 +
(insn.i_format.simmediate << 2);
                        else
                                epc += 8;
@@ -98,7 +98,7 @@
                case bgezal_op:
                case bgezall_op:
                        regs->regs[31] = epc + 8;
-                       if (regs->regs[insn.i_format.rs] >= 0)
+                       if ((long)regs->regs[insn.i_format.rs] >= 0)
                                epc = epc + 4 +
(insn.i_format.simmediate << 2);
                        else
                                epc += 8;
@@ -146,7 +146,7 @@
        case blez_op: /* not really i_format */
        case blezl_op:
                /* rt field assumed to be zero */
-               if (regs->regs[insn.i_format.rs] <= 0)
+               if ((long)regs->regs[insn.i_format.rs] <= 0)
                        epc = epc + 4 + (insn.i_format.simmediate << 2);

                else
                        epc += 8;
@@ -156,7 +156,7 @@
        case bgtz_op:
        case bgtzl_op:
                /* rt field assumed to be zero */
-               if (regs->regs[insn.i_format.rs] > 0)
+               if ((long)regs->regs[insn.i_format.rs] > 0)
                        epc = epc + 4 + (insn.i_format.simmediate << 2);

                else
                        epc += 8;


--
_    _ ____  ___   Carsten Langgaard   Mailto:carstenl@mips.com
|\  /|||___)(___   MIPS Denmark        Direct: +45 4486 5527
| \/ |||    ____)  Lautrupvang 4B      Switch: +45 4486 5555
  TECHNOLOGIES     2750 Ballerup       Fax...: +45 4486 5556
                   Denmark             http://www.mips.com




From owner-linux-mips@oss.sgi.com Tue Feb  6 10:08:37 2001
Received:  by oss.sgi.com id <S553885AbRBFSIS>;
	Tue, 6 Feb 2001 10:08:18 -0800
Received: from natmail2.webmailer.de ([192.67.198.65]:46211 "EHLO
        post.webmailer.de") by oss.sgi.com with ESMTP id <S553699AbRBFSH7>;
	Tue, 6 Feb 2001 10:07:59 -0800
Received: from scotty.mgnet.de (p3E9EC519.dip.t-dialin.net [62.158.197.25])
	by post.webmailer.de (8.9.3/8.8.7) with SMTP id TAA24513
	for <linux-mips@oss.sgi.com>; Tue, 6 Feb 2001 19:07:43 +0100 (MET)
Received: (qmail 6025 invoked from network); 6 Feb 2001 18:07:42 -0000
Received: from spock.mgnet.de (192.168.1.4)
  by scotty.mgnet.de with SMTP; 6 Feb 2001 18:07:42 -0000
Date:   Tue, 6 Feb 2001 19:07:47 +0100 (CET)
From:   Klaus Naumann <spock@mgnet.de>
To:     Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com>
cc:     Kenneth C Barr <kbarr@MIT.EDU>, linux-mips@oss.sgi.com
Subject: Re: netbooting indy - update, elf2ecoff?
In-Reply-To: <Pine.GSO.4.10.10102060732080.15534-100000@escobaria.sonytel.be>
Message-ID: <Pine.LNX.4.21.0102061905330.8851-100000@spock.mgnet.de>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing

On Tue, 6 Feb 2001, Geert Uytterhoeven wrote:

> However, /dev/console must _not_ be a symlink, but a character special device
> with major 5 minor 1 (cfr. Documentation/devices.txt).

Unless you're using Linux/MIPS :)
The console implementation is horrible broken, so
this means that under most circumstances the 5,1 device doesn't
work. So the only option is to make /dev/console a symlink to /dev/ttyS0.

		Cya, Klaus

-- 
Full Name   : Klaus Naumann     | (http://www.mgnet.de/) (Germany)
Nickname    : Spock             | Org.: Mad Guys Network
Phone / FAX : ++49/177/7862964  | E-Mail: (spock@mgnet.de)
PGP Key     : www.mgnet.de/keys/key_spock.txt


From owner-linux-mips@oss.sgi.com Tue Feb  6 10:11:27 2001
Received:  by oss.sgi.com id <S553892AbRBFSLH>;
	Tue, 6 Feb 2001 10:11:07 -0800
Received: from pobox.sibyte.com ([208.12.96.20]:18444 "HELO pobox.sibyte.com")
	by oss.sgi.com with SMTP id <S553888AbRBFSLA>;
	Tue, 6 Feb 2001 10:11:00 -0800
Received: from postal.sibyte.com (moat.sibyte.com [208.12.96.21])
	by pobox.sibyte.com (Postfix) with SMTP id 182CB205FB
	for <linux-mips@oss.sgi.com>; Tue,  6 Feb 2001 10:10:50 -0800 (PST)
Received: from SMTP agent by mail gateway 
 Tue, 06 Feb 2001 10:04:49 -0800
Received: from plugh.sibyte.com (plugh.sibyte.com [10.21.64.158])
	by postal.sibyte.com (Postfix) with ESMTP id 9AB521595F
	for <linux-mips@oss.sgi.com>; Tue,  6 Feb 2001 10:10:50 -0800 (PST)
Received: by plugh.sibyte.com (Postfix, from userid 61017)
	id 319A2686D; Tue,  6 Feb 2001 10:11:47 -0800 (PST)
From:   Justin Carlson <carlson@sibyte.com>
Reply-To: carlson@sibyte.com
Organization: Sibyte
To:     linux-mips@oss.sgi.com
Date:   Tue, 6 Feb 2001 10:11:00 -0800
X-Mailer: KMail [version 1.0.29]
Content-Type: text/plain
MIME-Version: 1.0
Message-Id: <0102061011470N.21018@plugh.sibyte.com>
Content-Transfer-Encoding: 8bit
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing

On Tue, 06 Feb 2001, Greeen-III wrote:
> All experts,
> 
> I am trying to port mips to my target board.
> The board has two pieces of ram. One is addressed at 0x80000000(bank0).
> The other is addressed at 0x82000000(bank1).
> The loader will load the kernel and ramdisk to the bank0.
> The ramdisk seems too small. The system will halt at gunzip() function.
> 

The memory is at physical address 0 and 0x2000000, then, as those addresses are
unmapped virtual in KSEG0 that map to these general addresses.

You need to find a way to call add_memory_region, typically from the
prom_meminit function for your board.  This function (among other things)
should be able to figure out what the physical memory map is, usually by
querying the firmware. 

Take a look at arch/mips/arc/memory.c in prom_meminit() for sample code on how
to do this.

> So I modify the file "/linux-vr/arch/mips/ld.script".
> >From the address ". = 0x80020000" to ". = 0x82020000 "
> But the situation still exist.

This just moves the entry point for the kernel to your second chunk of memory. 
For things to work properly, the kernel needs to be able to figure out what
the physical memory layout looks like; where the kernel lies within this
memory, so long as it's reserved, isn't terribly important.

How much memory is on your board, anyways, and what kind of board is it?  As
the initrd stuff is currently set up, the whole ramdisk is loaded into the
buffer cache, and *then* the ramdisk image memory is freed.  I've got a small
patch to do the image reclamation on the fly, which I'm using for really tiny
memory systems, but it's not really a clean solution.  If you're on a really
small memory system, I'll post it for you to try out.

-Justin

From owner-linux-mips@oss.sgi.com Tue Feb  6 12:09:18 2001
Received:  by oss.sgi.com id <S553902AbRBFUJJ>;
	Tue, 6 Feb 2001 12:09:09 -0800
Received: from pobox.sibyte.com ([208.12.96.20]:64526 "HELO pobox.sibyte.com")
	by oss.sgi.com with SMTP id <S553890AbRBFUIu>;
	Tue, 6 Feb 2001 12:08:50 -0800
Received: from postal.sibyte.com (moat.sibyte.com [208.12.96.21])
	by pobox.sibyte.com (Postfix) with SMTP id 4EEEB205FB
	for <linux-mips@oss.sgi.com>; Tue,  6 Feb 2001 12:08:45 -0800 (PST)
Received: from SMTP agent by mail gateway 
 Tue, 06 Feb 2001 12:02:44 -0800
Received: from plugh.sibyte.com (plugh.sibyte.com [10.21.64.158])
	by postal.sibyte.com (Postfix) with ESMTP id 542B91595F
	for <linux-mips@oss.sgi.com>; Tue,  6 Feb 2001 12:08:45 -0800 (PST)
Received: by plugh.sibyte.com (Postfix, from userid 61017)
	id 7461D686D; Tue,  6 Feb 2001 12:09:41 -0800 (PST)
From:   Justin Carlson <carlson@sibyte.com>
Reply-To: carlson@sibyte.com
Organization: Sibyte
To:     linux-mips@oss.sgi.com
Subject: Cache/TLB ops atomicty/SMP effects
Date:   Tue, 6 Feb 2001 11:47:35 -0800
X-Mailer: KMail [version 1.0.29]
Content-Type: text/plain
MIME-Version: 1.0
Message-Id: <0102061209410T.21018@plugh.sibyte.com>
Content-Transfer-Encoding: 8bit
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing


>From what I've been able to dig up, I gather that the majority of the cache
flushing ops are only used  for virtually indexed caches, wherein virutal
aliasing is a potential problem upon changing the page tables or somesuch. 
Documentation/cachetlb.txt seems a bit out of date, but covers most of it.

That's fine.  But there are the times when you've modified a memory region and
need to then execute from the same region.  In those cases on a split-cache
architecture, the icache needs to be flushed.  More specifically, this sequence
needs to happen:

flush_dirty_data_from_dcache()
sync()
invalidate_icache_region()

In an SMP system, one of two things needs to be true:

1) The entire sequence, from initial write of code to dataspace to icache
invalidate, needs to be run on a single processor.  Since the scheduler doesn't
guarantee processor allocations to work that way, the entire code sequence has
to be atomic.

 -OR-

2) We need to execute the writeback and icache invalidate on all processors in
the system, with synchronization points occuring after the dcache writeback
as well as after the icache invalidate.

The first option looks completely infeasible, and if the second option is
implemented in the mips64 tree, I'm just missing it somehow.  The sparc/
tree has smp_flush_cache type ops in arch/sparc/kernel/smp.c.  The mips64
tree, though, has support for cross cpu TLB flushes, but not for cache flushes.

Does anyone with a clearer grasp of how this works care to enlighten me?

Thanks,
  Justin




 -- 
carlson@broadcom.com
(408) 922-7098

From owner-linux-mips@oss.sgi.com Tue Feb  6 12:24:29 2001
Received:  by oss.sgi.com id <S553901AbRBFUYS>;
	Tue, 6 Feb 2001 12:24:18 -0800
Received: from noose.gt.owl.de ([62.52.19.4]:46864 "HELO noose.gt.owl.de")
	by oss.sgi.com with SMTP id <S553664AbRBFUYD>;
	Tue, 6 Feb 2001 12:24:03 -0800
Received: by noose.gt.owl.de (Postfix, from userid 10)
	id 76545808; Tue,  6 Feb 2001 21:23:51 +0100 (CET)
Received: by paradigm.rfc822.org (Postfix, from userid 1000)
	id D7497EEAC; Tue,  6 Feb 2001 21:24:07 +0100 (CET)
Date:   Tue, 6 Feb 2001 21:24:07 +0100
From:   Florian Lohoff <flo@rfc822.org>
To:     Klaus Naumann <spock@mgnet.de>
Cc:     linux-mips@oss.sgi.com
Subject: Re: netbooting indy - update, elf2ecoff?
Message-ID: <20010206212407.E4098@paradigm.rfc822.org>
References: <Pine.GSO.4.10.10102060732080.15534-100000@escobaria.sonytel.be> <Pine.LNX.4.21.0102061905330.8851-100000@spock.mgnet.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <Pine.LNX.4.21.0102061905330.8851-100000@spock.mgnet.de>; from spock@mgnet.de on Tue, Feb 06, 2001 at 07:07:47PM +0100
Organization: rfc822 - pure communication
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing

On Tue, Feb 06, 2001 at 07:07:47PM +0100, Klaus Naumann wrote:
> On Tue, 6 Feb 2001, Geert Uytterhoeven wrote:
> 
> > However, /dev/console must _not_ be a symlink, but a character special device
> > with major 5 minor 1 (cfr. Documentation/devices.txt).
> 
> Unless you're using Linux/MIPS :)
> The console implementation is horrible broken, so
> this means that under most circumstances the 5,1 device doesn't
> work. So the only option is to make /dev/console a symlink to /dev/ttyS0.

This has nothing to do with "Linux/Mips" and is definitly not true
on all subarchs. It might be true on SGI machines but i dont even
there its necessary.

Flo
-- 
Florian Lohoff                  flo@rfc822.org             +49-5201-669912
     Why is it called "common sense" when nobody seems to have any?


From owner-linux-mips@oss.sgi.com Tue Feb  6 15:52:00 2001
Received:  by oss.sgi.com id <S553907AbRBFXvj>;
	Tue, 6 Feb 2001 15:51:39 -0800
Received: from fourier.numerik.math.uni-siegen.de ([141.99.112.6]:2953 "EHLO
        fourier.numerik.math.uni-siegen.de") by oss.sgi.com with ESMTP
	id <S553904AbRBFXvb>; Tue, 6 Feb 2001 15:51:31 -0800
Received: from jordan.numerik.math.uni-siegen.de (jordan [141.99.112.9]) by fourier.numerik.math.uni-siegen.de (Mailhost) with ESMTP id AAA26469 for <linux-mips@oss.sgi.com>; Wed, 7 Feb 2001 00:52:08 +0100 (MET)
Received: (from engel@localhost)
	by jordan.numerik.math.uni-siegen.de (8.9.1b+Sun/8.9.1) id AAA05235
	for linux-mips@oss.sgi.com; Wed, 7 Feb 2001 00:50:24 +0100 (MET)
From:   Michael Engel <engel@math.uni-siegen.de>
Message-Id: <200102062350.AAA05235@jordan.numerik.math.uni-siegen.de>
Subject: O2 docs?
To:     linux-mips@oss.sgi.com
Date:   Wed, 7 Feb 2001 00:50:24 +0100 (MET)
X-Mailer: ELM [version 2.5 PL2]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing


Hi,

seems like I'm the proud owner of a R5k O2 next week. I hope to
have some more time in the future to work on Linux/MIPS and would
like to hack the O2 (and continue work on the RM ports, the RM400
starts to crash in the interrupt handler - kind of success ;-). Oh
yeah, and the DECstations of course ...).

Are there any docs available for the O2 (other than the NetBSD sources)?

Btw., I'm organizing the Linux port free software booth at 
LinuxTag 2001 in Stuttgart, Germany (July 5th-8th). Everyone is 
invited to come and present his or her hacking toy ;-) - if you're
interested, please contact me.

regards,
	Michael
-- 
Michael Engel	(engel@unix-ag.org)

From owner-linux-mips@oss.sgi.com Tue Feb  6 16:50:50 2001
Received:  by oss.sgi.com id <S553695AbRBGAua>;
	Tue, 6 Feb 2001 16:50:30 -0800
Received: from Sioux.meginc.com ([207.246.76.19]:16913 "EHLO sioux.meginc.com")
	by oss.sgi.com with ESMTP id <S553669AbRBGAu0>;
	Tue, 6 Feb 2001 16:50:26 -0800
Received: from localhost.localdomain (IDENT:brandon@[207.246.76.126])
	by sioux.meginc.com (8.9.3/8.9.1) with SMTP id TAA44296
	for <linux-mips@oss.sgi.com>; Tue, 6 Feb 2001 19:54:12 -0500 (EST)
	(envelope-from bebarker@meginc.com)
From:   Brandon Barker <bebarker@meginc.com>
Date:   Tue, 6 Feb 2001 19:54:05 -0500
X-Mailer: KMail [version 1.1.99]
Content-Type: text/plain;
  charset="iso-8859-1"
To:     linux-mips@oss.sgi.com
Subject: Linux/Indy HOWTO
MIME-Version: 1.0
Message-Id: <01020619540500.01634@localhost.localdomain>
Content-Transfer-Encoding: 8bit
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing

Will there be a SGI/Linux Install HOWTO especially pertaining to the Indy.  I 
have an Indy, but I do not own IRIX, and I can't find any instructions in the 
current howto because it is not meant to be an install HOWTO.  I have also 
heard rumors that SGI eventually plans to drop MIPS/IRIX all togethor and 
that they never plan on offering Linux as a viable OS to it's MIPS systems.  
Am I correct?

Brandon Barker

From owner-linux-mips@oss.sgi.com Tue Feb  6 23:34:02 2001
Received:  by oss.sgi.com id <S553855AbRBGHdw>;
	Tue, 6 Feb 2001 23:33:52 -0800
Received: from sgigate.SGI.COM ([204.94.209.1]:8106 "EHLO dea.waldorf-gmbh.de")
	by oss.sgi.com with ESMTP id <S553695AbRBGHde>;
	Tue, 6 Feb 2001 23:33:34 -0800
Received: (from ralf@localhost)
	by dea.waldorf-gmbh.de (8.11.1/8.11.1) id f177RIm23266;
	Tue, 6 Feb 2001 23:27:18 -0800
Date:   Tue, 6 Feb 2001 23:27:13 -0800
From:   Ralf Baechle <ralf@oss.sgi.com>
To:     Brandon Barker <bebarker@meginc.com>
Cc:     linux-mips@oss.sgi.com
Subject: Re: Linux/Indy HOWTO
Message-ID: <20010206232713.A22875@bacchus.dhis.org>
References: <01020619540500.01634@localhost.localdomain>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <01020619540500.01634@localhost.localdomain>; from bebarker@meginc.com on Tue, Feb 06, 2001 at 07:54:05PM -0500
X-Accept-Language: de,en,fr
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing

On Tue, Feb 06, 2001 at 07:54:05PM -0500, Brandon Barker wrote:

> Will there be a SGI/Linux Install HOWTO especially pertaining to the Indy.  I 
> have an Indy, but I do not own IRIX, and I can't find any instructions in the 
> current howto because it is not meant to be an install HOWTO.  I have also 
> heard rumors that SGI eventually plans to drop MIPS/IRIX all togethor and 
> that they never plan on offering Linux as a viable OS to it's MIPS systems.  

IRIX will exist as long as SGI supports their MIPS systems, that is for
many years to come.  Linux as OS is only planned for the yet to be released
IA64 systems.  That's all stuff for their public press releases and not
for this list ...

  Ralf

From owner-linux-mips@oss.sgi.com Tue Feb  6 23:41:03 2001
Received:  by oss.sgi.com id <S553699AbRBGHkw>;
	Tue, 6 Feb 2001 23:40:52 -0800
Received: from sgigate.SGI.COM ([204.94.209.1]:36047 "EHLO dea.waldorf-gmbh.de")
	by oss.sgi.com with ESMTP id <S553669AbRBGHkn>;
	Tue, 6 Feb 2001 23:40:43 -0800
Received: (from ralf@localhost)
	by dea.waldorf-gmbh.de (8.11.1/8.11.1) id f177Yk123354;
	Tue, 6 Feb 2001 23:34:46 -0800
Date:   Tue, 6 Feb 2001 23:34:46 -0800
From:   Ralf Baechle <ralf@oss.sgi.com>
To:     Carsten Langgaard <carstenl@mips.com>
Cc:     linux-mips@oss.sgi.com
Subject: Re: The FPU emulator doesn't work properly
Message-ID: <20010206233446.B22875@bacchus.dhis.org>
References: <3A80215E.D13FE590@mips.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <3A80215E.D13FE590@mips.com>; from carstenl@mips.com on Tue, Feb 06, 2001 at 05:07:58PM +0100
X-Accept-Language: de,en,fr
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing

On Tue, Feb 06, 2001 at 05:07:58PM +0100, Carsten Langgaard wrote:

> I think I have send this patch before, but it hasn't got in to the
> archive, apparently.

If you send it to this list it may well happen that I miss it.  In fact
I can't remember having seen this patch.

  Ralf

From owner-linux-mips@oss.sgi.com Wed Feb  7 05:49:43 2001
Received:  by oss.sgi.com id <S553659AbRBGNtY>;
	Wed, 7 Feb 2001 05:49:24 -0800
Received: from noose.gt.owl.de ([62.52.19.4]:17422 "HELO noose.gt.owl.de")
	by oss.sgi.com with SMTP id <S553647AbRBGNs7>;
	Wed, 7 Feb 2001 05:48:59 -0800
Received: by noose.gt.owl.de (Postfix, from userid 10)
	id B2BB27D9; Wed,  7 Feb 2001 14:48:43 +0100 (CET)
Received: by paradigm.rfc822.org (Postfix, from userid 1000)
	id 671F8EEAC; Wed,  7 Feb 2001 14:48:58 +0100 (CET)
Date:   Wed, 7 Feb 2001 14:48:58 +0100
From:   Florian Lohoff <flo@rfc822.org>
To:     linux-mips@oss.sgi.com
Cc:     ralf@oss.sgi.com
Subject: NON FPU cpus - way to go
Message-ID: <20010207144857.B24485@paradigm.rfc822.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
Organization: rfc822 - pure communication
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing

Hi,
i would like to know the way to go for NON-FPU cpus - Currently its
partly an Compile Time thing and partly run time config. 

I stumbled over the current tree as on the 3912 we dont have a FPU
so we cant use the default "exit_thread" which simply causes the
CPU to halt (not even an cpu reset works)

arch/mips/process.c

     55 void exit_thread(void)
     56 {
     57         /* Forget lazy fpu state */
     58         if (last_task_used_math == current) {
     59                 set_cp0_status(ST0_CU1, ST0_CU1);
     60                 __asm__ __volatile__("cfc1\t$0,$31");
     61                 last_task_used_math = NULL;
     62         }
     63 }

The Linux-vr people IFDEFed this with CONFIG_NO_FPU which is an option
but then we could even remove the whole cpu probing as everything
would be compile time.

A question here - Which way to go - Compile or Run time config for
CPUs and is 

if(!(mips_cpu.options & MIPS_CPU_FPU))

this also valid for R3k CPU cores ? From my reading it is not as it doesnt
get initialized for R3000 ? As a lot architectures have the R3010
so this should get detected. The R3081 definitly has an FPU from
what i found on the web so this should be correct.

Index: arch/mips/kernel/setup.c
===================================================================
RCS file: /cvs/linux/arch/mips/kernel/setup.c,v
retrieving revision 1.49
diff -u -r1.49 setup.c
--- arch/mips/kernel/setup.c	2001/02/05 01:33:01	1.49
+++ arch/mips/kernel/setup.c	2001/02/07 13:39:16
@@ -182,15 +182,16 @@
 		mips_cpu.tlbsize = 64;
 		break;
 	case PRID_IMP_R3000:
+		mips_cpu.options = MIPS_CPU_TLB;
 		if ((mips_cpu.processor_id & 0xff) == PRID_REV_R3000A)
-			if (cpu_has_confreg())
+			if (cpu_has_confreg()) {
 				mips_cpu.cputype = CPU_R3081E;
-			else
+				mips_cpu.options |= MIPS_CPU_FPU;
+			} else
 				mips_cpu.cputype = CPU_R3000A;
 		else
 			 mips_cpu.cputype = CPU_R3000;
 		mips_cpu.isa_level = MIPS_CPU_ISA_I;
-		mips_cpu.options = MIPS_CPU_TLB;
 		mips_cpu.tlbsize = 64;
 		break;
 	case PRID_IMP_R4000:


Flo
-- 
Florian Lohoff                  flo@rfc822.org             +49-5201-669912
     Why is it called "common sense" when nobody seems to have any?


From owner-linux-mips@oss.sgi.com Wed Feb  7 08:52:25 2001
Received:  by oss.sgi.com id <S553691AbRBGQwP>;
	Wed, 7 Feb 2001 08:52:15 -0800
Received: from delta.ds2.pg.gda.pl ([153.19.144.1]:18323 "EHLO
        delta.ds2.pg.gda.pl") by oss.sgi.com with ESMTP id <S553659AbRBGQvy>;
	Wed, 7 Feb 2001 08:51:54 -0800
Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id RAA03801;
	Wed, 7 Feb 2001 17:36:33 +0100 (MET)
Date:   Wed, 7 Feb 2001 17:36:33 +0100 (MET)
From:   "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To:     Florian Lohoff <flo@rfc822.org>
cc:     linux-mips@oss.sgi.com, ralf@oss.sgi.com
Subject: Re: NON FPU cpus - way to go
In-Reply-To: <20010207144857.B24485@paradigm.rfc822.org>
Message-ID: <Pine.GSO.3.96.1010207171821.1418B-100000@delta.ds2.pg.gda.pl>
Organization: Technical University of Gdansk
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing

On Wed, 7 Feb 2001, Florian Lohoff wrote:

> i would like to know the way to go for NON-FPU cpus - Currently its
> partly an Compile Time thing and partly run time config. 

 The i386 way seems reasonable, IMHO.  Have a configure option to enable
an FPU emulator.  Panic upon boot if no FP hardware is available and no
emulator is compiled in. 

> A question here - Which way to go - Compile or Run time config for
> CPUs and is 
> 
> if(!(mips_cpu.options & MIPS_CPU_FPU))
> 
> this also valid for R3k CPU cores ? From my reading it is not as it doesnt
> get initialized for R3000 ? As a lot architectures have the R3010
> so this should get detected. The R3081 definitly has an FPU from
> what i found on the web so this should be correct.

 Hmm, I see MIPS_CPU_FPU is hand-coded all over arch/mips/kernel/setup.c.
It's too fragile, I believe.  Why not just use the way IDT recommends in
their "IDT MIPS Microprocessor Family Software Reference Manual" in
Chapter 8 "Floating Point Co-Processor?"  Quoting:


FLOATING-POINT IMPLEMENTATION/REVISION REGISTER

  This read-only registers fields are shown in Figure 8.2, "FPA
implementation/revision register".

 31                           16 15            8 7             0
+-------------------------------+---------------+---------------+
|0                              |Imp            |Rev            |
+-------------------------------+---------------+---------------+

  This register is co-processor 1 control register 0 (mnemonic FCR0),
and is accessed by ctc1 and cfc1 instructions.
  Unlike the CPUcs field, the "Imp" field is useful.  In the R30xx
family it will contain one of two values:

    0   No FPA is available.  Reading this register is the recommended
        way of sensing the presence of an FPA.  Note that software must
        enable "coprocessor 1" instructions before trying to read this
        register.
    3   The FPA is compatible with that used for the R3000 CPU and its
        successors.

  In the R4xxx family the "Imp" field is 0x20 for R4600, 0x21 for R4700
and 0x22 for the R4650.
  The "Rev" field contains no relevant software data.  The "Rev" field
is a value of the form y.x, where y is the major revision number (bits
7:4) and x is a minor revision number (bits 3:0).  Do not rely on this
field.


End of the quote.

 Is there any problem in a particular configuration which makes the FCR0
non-zero Imp field dependency unreliable? 

 The book covers R3081 and it states it contains the 3010A FPA device,
indeed. 

  Maciej

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +


From owner-linux-mips@oss.sgi.com Wed Feb  7 09:00:04 2001
Received:  by oss.sgi.com id <S553692AbRBGQ7z>;
	Wed, 7 Feb 2001 08:59:55 -0800
Received: from noose.gt.owl.de ([62.52.19.4]:44817 "HELO noose.gt.owl.de")
	by oss.sgi.com with SMTP id <S553671AbRBGQ7h>;
	Wed, 7 Feb 2001 08:59:37 -0800
Received: by noose.gt.owl.de (Postfix, from userid 10)
	id 46E6D7F3; Wed,  7 Feb 2001 17:59:25 +0100 (CET)
Received: by paradigm.rfc822.org (Postfix, from userid 1000)
	id DCE6DEEAC; Wed,  7 Feb 2001 17:59:35 +0100 (CET)
Date:   Wed, 7 Feb 2001 17:59:35 +0100
From:   Florian Lohoff <flo@rfc822.org>
To:     "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
Cc:     linux-mips@oss.sgi.com
Subject: Re: NON FPU cpus - way to go
Message-ID: <20010207175935.J26479@paradigm.rfc822.org>
References: <20010207144857.B24485@paradigm.rfc822.org> <Pine.GSO.3.96.1010207171821.1418B-100000@delta.ds2.pg.gda.pl>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <Pine.GSO.3.96.1010207171821.1418B-100000@delta.ds2.pg.gda.pl>; from macro@ds2.pg.gda.pl on Wed, Feb 07, 2001 at 05:36:33PM +0100
Organization: rfc822 - pure communication
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing

On Wed, Feb 07, 2001 at 05:36:33PM +0100, Maciej W. Rozycki wrote:
> On Wed, 7 Feb 2001, Florian Lohoff wrote:
> 
> > i would like to know the way to go for NON-FPU cpus - Currently its
> > partly an Compile Time thing and partly run time config. 
> 
>  The i386 way seems reasonable, IMHO.  Have a configure option to enable
> an FPU emulator.  Panic upon boot if no FP hardware is available and no
> emulator is compiled in. 

The problem with not compiling in the FPU Emulator at all means some
of your FPU instructions (even on FPU hardware) will fail as on some
specific operators the hardware decides to handle it in software. So
usually you would need an FPU Emulator even on FPU enabled CPUs.

This isnt true if you decide to compile your complete userland with
fpu emulation.

> > this also valid for R3k CPU cores ? From my reading it is not as it doesnt
> > get initialized for R3000 ? As a lot architectures have the R3010
> > so this should get detected. The R3081 definitly has an FPU from
> > what i found on the web so this should be correct.

>   This register is co-processor 1 control register 0 (mnemonic FCR0),
> and is accessed by ctc1 and cfc1 instructions.
>   Unlike the CPUcs field, the "Imp" field is useful.  In the R30xx
> family it will contain one of two values:

I dont know if this is a generic way to go - I saw complete "full-stops"
on an R3912 using the ctc/cfc instructions - I'll try the autodection
when i come home.

>  Is there any problem in a particular configuration which makes the FCR0
> non-zero Imp field dependency unreliable? 
> 
>  The book covers R3081 and it states it contains the 3010A FPA device,
> indeed. 

Flo
-- 
Florian Lohoff                  flo@rfc822.org             +49-5201-669912
     Why is it called "common sense" when nobody seems to have any?


From owner-linux-mips@oss.sgi.com Wed Feb  7 10:14:15 2001
Received:  by oss.sgi.com id <S553695AbRBGSNz>;
	Wed, 7 Feb 2001 10:13:55 -0800
Received: from sovereign.org ([209.180.91.170]:19084 "EHLO lux.homenet")
	by oss.sgi.com with ESMTP id <S553659AbRBGSNd>;
	Wed, 7 Feb 2001 10:13:33 -0800
Received: (from jfree@localhost)
	by lux.homenet (8.11.2/8.11.2/Debian 8.11.2-1) id f17IDg027176
	for linux-mips@oss.sgi.com; Wed, 7 Feb 2001 11:13:42 -0700
From:   Jim Freeman <jfree@sovereign.org>
Date:   Wed, 7 Feb 2001 11:13:42 -0700
To:     linux-mips@oss.sgi.com
Subject: merges into stock kernel tree
Message-ID: <20010207111342.A27046@sovereign.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.3.12i
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing

I'm trying to get a broad sense of where mips/CVS is with respect to
the stock upstream kernels, and what drives the merges of mips snapshots
into the upstream kernel.

As best I can tell from the mail archives, CVS logs, and the stock
source tree, the most recent mips merge into the main kernel was
about June 2000, with perhaps some later mips patchlets going in
here and there not ncessarily related to mips/CVS.
  [ Is this at all acccurate ? ]


Not having a variety of mips hw to play with, what is the functional
status of mips as shipped in the mainstream kernel?

How does that status compare to the functional status of the
current mips in cvs?

What's on the todo list prior to another merge into the upstream?


Thanks for any info [I'll summarize any non-list replies],
...jfree

From owner-linux-mips@oss.sgi.com Wed Feb  7 10:22:25 2001
Received:  by oss.sgi.com id <S553692AbRBGSWQ>;
	Wed, 7 Feb 2001 10:22:16 -0800
Received: from delta.ds2.pg.gda.pl ([153.19.144.1]:43668 "EHLO
        delta.ds2.pg.gda.pl") by oss.sgi.com with ESMTP id <S553671AbRBGSVz>;
	Wed, 7 Feb 2001 10:21:55 -0800
Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id TAA07258;
	Wed, 7 Feb 2001 19:19:46 +0100 (MET)
Date:   Wed, 7 Feb 2001 19:19:45 +0100 (MET)
From:   "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To:     Florian Lohoff <flo@rfc822.org>
cc:     linux-mips@oss.sgi.com
Subject: Re: NON FPU cpus - way to go
In-Reply-To: <20010207175935.J26479@paradigm.rfc822.org>
Message-ID: <Pine.GSO.3.96.1010207190614.1418F-100000@delta.ds2.pg.gda.pl>
Organization: Technical University of Gdansk
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing

On Wed, 7 Feb 2001, Florian Lohoff wrote:

> The problem with not compiling in the FPU Emulator at all means some
> of your FPU instructions (even on FPU hardware) will fail as on some
> specific operators the hardware decides to handle it in software. So
> usually you would need an FPU Emulator even on FPU enabled CPUs.

 I mean a full emulator.  I know that for simplicity certain actions
required by the IEEE spec are handled in software (Alpha does it as well). 
These bits have to be always included, of course.  I would like to save
wasted bits for hardware that always has an FPU, though.

> This isnt true if you decide to compile your complete userland with
> fpu emulation.

 I'm not sure if that approach has any advantages when using an operating
system such as Linux.  It might certainly be beneficial for firmware or
similar dedicated software.

> I dont know if this is a generic way to go - I saw complete "full-stops"
> on an R3912 using the ctc/cfc instructions - I'll try the autodection
> when i come home.

 We might work around pathological cases as usual -- such a behaviour
should count as a bug (I hope IDT did have a clue here -- is there any
original MIPS statement on how to handle FPU presence detection?).  You
might use the i386 setup code for a reference as a large mine of bug
workarounds. 

 Maciej

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +


From owner-linux-mips@oss.sgi.com Wed Feb  7 10:54:45 2001
Received:  by oss.sgi.com id <S553691AbRBGSyZ>;
	Wed, 7 Feb 2001 10:54:25 -0800
Received: from router-100M.swansea.linux.org.uk ([194.168.151.17]:28421 "EHLO
        the-village.bc.nu") by oss.sgi.com with ESMTP id <S553659AbRBGSyC>;
	Wed, 7 Feb 2001 10:54:02 -0800
Received: from alan by the-village.bc.nu with local (Exim 2.12 #1)
	id 14QZie-00011I-00; Wed, 7 Feb 2001 18:53:32 +0000
Subject: Re: NON FPU cpus - way to go
To:     macro@ds2.pg.gda.pl (Maciej W. Rozycki)
Date:   Wed, 7 Feb 2001 18:53:29 +0000 (GMT)
Cc:     flo@rfc822.org (Florian Lohoff), linux-mips@oss.sgi.com,
        ralf@oss.sgi.com
In-Reply-To: <Pine.GSO.3.96.1010207171821.1418B-100000@delta.ds2.pg.gda.pl> from "Maciej W. Rozycki" at Feb 07, 2001 05:36:33 PM
X-Mailer: ELM [version 2.5 PL1]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <E14QZie-00011I-00@the-village.bc.nu>
From:   Alan Cox <alan@lxorguk.ukuu.org.uk>
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing

>  The i386 way seems reasonable, IMHO.  Have a configure option to enable
> an FPU emulator.  Panic upon boot if no FP hardware is available and no
> emulator is compiled in. 

Its an interesting question whether it belongs in the kernel or libc. 
Discuss ;)

Also we missed a trick on the x86 and I want to fix that one day, which is
to have an __fpu ELF segment so if you boot an FPU emu kernel on an fpu
box you regain 47K


From owner-linux-mips@oss.sgi.com Wed Feb  7 11:03:35 2001
Received:  by oss.sgi.com id <S553695AbRBGTDQ>;
	Wed, 7 Feb 2001 11:03:16 -0800
Received: from gateway-1237.mvista.com ([12.44.186.158]:23282 "EHLO
        hermes.mvista.com") by oss.sgi.com with ESMTP id <S553671AbRBGTC4>;
	Wed, 7 Feb 2001 11:02:56 -0800
Received: from mvista.com (IDENT:jsun@orion.mvista.com [10.0.0.75])
	by hermes.mvista.com (8.11.0/8.11.0) with ESMTP id f17IxD818266;
	Wed, 7 Feb 2001 10:59:13 -0800
Message-ID: <3A819B80.7946F866@mvista.com>
Date:   Wed, 07 Feb 2001 11:01:20 -0800
From:   Jun Sun <jsun@mvista.com>
X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14-5.0 i686)
X-Accept-Language: en
MIME-Version: 1.0
To:     Florian Lohoff <flo@rfc822.org>
CC:     linux-mips@oss.sgi.com, ralf@oss.sgi.com
Subject: Re: NON FPU cpus - way to go
References: <20010207144857.B24485@paradigm.rfc822.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing

Florian Lohoff wrote:
> 
> Hi,
> i would like to know the way to go for NON-FPU cpus - Currently its
> partly an Compile Time thing and partly run time config.
> 

Flo,

My vote is to use config option.

Moving forward I see MIPS mainly used in embedded systems.  I think need of
using the same kernel binary for multiple CPUs is rare, especially for the
"same" CPU with or without FPU.  Therefore having run-time detection is a
waste of effort.  Half-config-half-runtime solution is pretty messy too.

For CPUs with the same PrID that may or may not have a FPU, we can add an
optional FPU selection in the config.in file.

To be complete, I probably would add a check for the existence of FPU, if we
can infer from PrID, when FPU config option is enabled.

Jun

From owner-linux-mips@oss.sgi.com Wed Feb  7 11:39:34 2001
Received:  by oss.sgi.com id <S553696AbRBGTjY>;
	Wed, 7 Feb 2001 11:39:24 -0800
Received: from [12.44.186.158] ([12.44.186.158]:1275 "EHLO hermes.mvista.com")
	by oss.sgi.com with ESMTP id <S553691AbRBGTjI>;
	Wed, 7 Feb 2001 11:39:08 -0800
Received: from mvista.com (IDENT:jsun@orion.mvista.com [10.0.0.75])
	by hermes.mvista.com (8.11.0/8.11.0) with ESMTP id f17JYr820473;
	Wed, 7 Feb 2001 11:34:53 -0800
Message-ID: <3A81A3DC.E75E6045@mvista.com>
Date:   Wed, 07 Feb 2001 11:37:00 -0800
From:   Jun Sun <jsun@mvista.com>
X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14-5.0 i686)
X-Accept-Language: en
MIME-Version: 1.0
To:     Alan Cox <alan@lxorguk.ukuu.org.uk>
CC:     "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>,
        Florian Lohoff <flo@rfc822.org>, linux-mips@oss.sgi.com,
        ralf@oss.sgi.com
Subject: Re: NON FPU cpus - way to go
References: <E14QZie-00011I-00@the-village.bc.nu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing

Alan Cox wrote:
> 
> >  The i386 way seems reasonable, IMHO.  Have a configure option to enable
> > an FPU emulator.  Panic upon boot if no FP hardware is available and no
> > emulator is compiled in.
> 
> Its an interesting question whether it belongs in the kernel or libc.
> Discuss ;)
> 

I favor the libc approach as it is faster.

Unfortunately I don't think glibc for MIPS can be configured with
--without-fp.  I modified a patch to get glibc 2.0.6 working for no-fp config,
but it is not a clean one.  Is anybody working on that for the latest glibc
2.2?

> Also we missed a trick on the x86 and I want to fix that one day, which is
> to have an __fpu ELF segment so if you boot an FPU emu kernel on an fpu
> box you regain 47K

Ironically for MIPS you MUST have the FPU emulater when the CPU actually has a
FPU. :-)

Jun

From owner-linux-mips@oss.sgi.com Wed Feb  7 12:29:25 2001
Received:  by oss.sgi.com id <S553691AbRBGU3P>;
	Wed, 7 Feb 2001 12:29:15 -0800
Received: from mail.ivm.net ([62.204.1.4]:25656 "EHLO mail.ivm.net")
	by oss.sgi.com with ESMTP id <S553696AbRBGU3O>;
	Wed, 7 Feb 2001 12:29:14 -0800
Received: from franz.no.dom (port162.duesseldorf.ivm.de [195.247.65.162])
	by mail.ivm.net (8.8.8/8.8.8) with ESMTP id VAA08757;
	Wed, 7 Feb 2001 21:28:56 +0100
X-To:   linux-mips@oss.sgi.com
Message-ID: <XFMail.010207212905.Harald.Koerfgen@home.ivm.de>
X-Mailer: XFMail 1.4.0 on Linux
X-Priority: 3 (Normal)
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
In-Reply-To: <20010203212356.C24513@stav.org.il>
Date:   Wed, 07 Feb 2001 21:29:05 +0100 (CET)
Reply-To: Harald Koerfgen <Harald.Koerfgen@home.ivm.de>
Organization: none
From:   Harald Koerfgen <Harald.Koerfgen@home.ivm.de>
To:     Adi Stav <stav@actcom.co.il>
Subject: RE: Progress with Linux on O2?
Cc:     linux-mips@oss.sgi.com
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing


On 03-Feb-01 Adi Stav wrote:
> I have an O2 and would very much like to run Linux on it. I was
> looking for information on Linux on O2 but could not find any -- I
> understand that there is no such usable port yet, but I was wondering
> if someone could refer me to anyone working on it, or to work that has
> been done already, so that I could follow the progress or maybe help a
> bit. Or has no such work been done yet?

Status:

> hinv
                   System: IP32
                Processor: 180 Mhz R5000, with FPU
     Primary I-cache size: 32 Kbytes
     Primary D-cache size: 32 Kbytes
     Secondary cache size: 512 Kbytes
              Memory size: 128 Mbytes
                 Graphics: CRM, Rev C
                    Audio: A3 version 1
                SCSI Disk: scsi(0)disk(1)
               SCSI CDROM: scsi(0)cdrom(4)
> boot bootp()/vmlinux root=/dev/ram
130768+22320+3184+341792+48560d+4604+6816 entry: 0x87fa60d0
Setting $netaddr to 192.168.0.7 (from server intel)
Obtaining /vmlinux from server intel
934384+117828 entry: 0x800025a8
ARCH: SGI-IP32
PROMLIB: ARC firmware Version 1 Revision 10
Loading R4000 MMU routines.
CPU revision is: 00002321
Primary instruction cache 32kb, linesize 32 bytes.
Primary data cache 32kb, linesize 32 bytes.
Secondary cache 512kb, linesize 32 bytes.
R5000 with secondary cache detected, disabling secondary cache
Linux version 2.4.1 (harry@intel) (gcc version egcs-2.91.66 19990314
(egcs-1.1.2 release)) #14 Mit Feb 7 20:44:38 CET 2001
Determined physical RAM map:
 memory: 00001000 @ 00000000 (reserved)
 memory: 00001000 @ 00001000 (reserved)
 memory: 00101000 @ 00002000 (reserved)
 memory: 00c4d000 @ 00103000 (usable)
 memory: 002b0000 @ 00d50000 (ROM data)
 memory: 00100000 @ 01000000 (reserved)
 memory: 00300000 @ 01100000 (ROM data)
 memory: 06b86000 @ 01400000 (usable)
 memory: 0007a000 @ 07f86000 (reserved)
On node 0 totalpages: 32646
zone(0): 32646 pages.
zone(1): 0 pages.
zone(2): 0 pages.
Kernel command line: root=/dev/ram
Calibrating delay loop... 179.40 BogoMIPS
Memory: 120516k/122700k available (693k kernel code, 2184k reserved, 44k data,
172k init)
Dentry-cache hash table entries: 16384 (order: 5, 131072 bytes)
Buffer-cache hash table entries: 4096 (order: 2, 16384 bytes)
Page-cache hash table entries: 32768 (order: 5, 131072 bytes)
Inode-cache hash table entries: 8192 (order: 4, 65536 bytes)
Checking for 'wait' instruction...  available.
POSIX conformance testing by UNIFIX
Linux NET4.0 for Linux 2.4
Based upon Swansea University Computer Society NET3.039
Starting kswapd v1.8
block: queued sectors max/low 80042kB/26680kB, 256 slots per queue
RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize
RAMDISK: Compressed image found at block 0
Serial driver version 5.02 (2000-08-09) with SHARE_IRQ enabled
ttyS00 at 0x0000 (irq = 14) is a 16550A
VFS: Mounted root (ext2 filesystem).
Freeing prom memory: 5824kb freed
Freeing unused kernel memory: 172k freed
Stand-alone shell (version 2.1)
> -mount -t proc none /proc
> -dd if=/proc/cpuinfo of=/dev/console
cpu                     : MIPS
cpu model               : R5000 V2.1
system type             : SGI O2
BogoMIPS                : 179.40
byteorder               : big endian
unaligned accesses      : 0
wait instruction        : yes
microsecond timers      : yes
extra interrupt vector  : no
hardware watchpoint     : no
VCED exceptions         : not available
VCEI exceptions         : not available
0+1 records in
0+1 records out
> -dd if=/proc/uptime of=/dev/console
442.60 442.29
0+1 records in
0+1 records out
> -dd if=/proc/interrupts of=/dev/console
 0:    97396 + timer
14:      242   serial
0+1 records in
0+1 records out
> 

Please note that PCI support is non-existing. The timer interrupt is
realised with CP0 count/compare, the second level cache is disabled, and the
only device working is the serial console.

-- 
Regards,
Harald

From owner-linux-mips@oss.sgi.com Wed Feb  7 12:29:25 2001
Received:  by oss.sgi.com id <S553712AbRBGU3P>;
	Wed, 7 Feb 2001 12:29:15 -0800
Received: from mail.ivm.net ([62.204.1.4]:15416 "EHLO mail.ivm.net")
	by oss.sgi.com with ESMTP id <S553691AbRBGU3K>;
	Wed, 7 Feb 2001 12:29:10 -0800
Received: from franz.no.dom (port162.duesseldorf.ivm.de [195.247.65.162])
	by mail.ivm.net (8.8.8/8.8.8) with ESMTP id VAA08747;
	Wed, 7 Feb 2001 21:28:55 +0100
X-To:   linux-mips@oss.sgi.com
Message-ID: <XFMail.010207212904.Harald.Koerfgen@home.ivm.de>
X-Mailer: XFMail 1.4.0 on Linux
X-Priority: 3 (Normal)
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
In-Reply-To: <200102062350.AAA05235@jordan.numerik.math.uni-siegen.de>
Date:   Wed, 07 Feb 2001 21:29:04 +0100 (CET)
Reply-To: Harald Koerfgen <Harald.Koerfgen@home.ivm.de>
Organization: none
From:   Harald Koerfgen <Harald.Koerfgen@home.ivm.de>
To:     Michael Engel <engel@math.uni-siegen.de>
Subject: RE: O2 docs?
Cc:     linux-mips@oss.sgi.com
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing


On 06-Feb-01 Michael Engel wrote:
> Are there any docs available for the O2 (other than the NetBSD sources)?

If you still have IRIX on your O2 you'll find "ls /usr/include/sys" usefull.

-- 
Regards,
Harald

From owner-linux-mips@oss.sgi.com Wed Feb  7 12:49:54 2001
Received:  by oss.sgi.com id <S553700AbRBGUtf>;
	Wed, 7 Feb 2001 12:49:35 -0800
Received: from blackdog.wirespeed.com ([208.170.106.25]:32014 "EHLO
        blackdog.wirespeed.com") by oss.sgi.com with ESMTP
	id <S553691AbRBGUtR>; Wed, 7 Feb 2001 12:49:17 -0800
Received: from redhat.com (IDENT:joe@dhcp-4.wirespeed.com [172.16.17.4])
	by blackdog.wirespeed.com (8.9.3/8.9.3) with ESMTP id OAA10922;
	Wed, 7 Feb 2001 14:36:54 -0600
Message-ID: <3A81B388.1090806@redhat.com>
Date:   Wed, 07 Feb 2001 14:43:52 -0600
From:   Joe deBlaquiere <jadb@redhat.com>
Organization: Red Hat, Inc.
User-Agent: Mozilla/5.0 (X11; U; Linux 2.2.16-22 i686; en-US; m18) Gecko/20001107 Netscape6/6.0
X-Accept-Language: en
MIME-Version: 1.0
To:     Jun Sun <jsun@mvista.com>
CC:     Alan Cox <alan@lxorguk.ukuu.org.uk>,
        "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>,
        Florian Lohoff <flo@rfc822.org>, linux-mips@oss.sgi.com,
        ralf@oss.sgi.com
Subject: Re: NON FPU cpus - way to go
References: <E14QZie-00011I-00@the-village.bc.nu> <3A81A3DC.E75E6045@mvista.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing



Jun Sun wrote:

> Alan Cox wrote:
> 
>>>  The i386 way seems reasonable, IMHO.  Have a configure option to enable
>>> an FPU emulator.  Panic upon boot if no FP hardware is available and no
>>> emulator is compiled in.
>> 
>> Its an interesting question whether it belongs in the kernel or libc.
>> Discuss ;)
>> 
> 
> 
> I favor the libc approach as it is faster.

You can still compile in the FP emulator just 'in case'... That way you 
leave it up to the application as to whether to do be quick or cheap. 
This also ensures binary portability (well, mostly, there's always .so 
ABI issues and the like...)

> 
> Unfortunately I don't think glibc for MIPS can be configured with
> --without-fp.  I modified a patch to get glibc 2.0.6 working for no-fp config,
> but it is not a clean one.  Is anybody working on that for the latest glibc
> 2.2?
> 
> 

AFAIK, 2.0.7-20 (from Jay Carlson), 2.1.95 (from SGI), 2.2, and the 
current CVS can all be configured for soft float.

>> Also we missed a trick on the x86 and I want to fix that one day, which is
>> to have an __fpu ELF segment so if you boot an FPU emu kernel on an fpu
>> box you regain 47K
> 
> 
> Ironically for MIPS you MUST have the FPU emulater when the CPU actually has a
> FPU. :-)
> 

I'm confused here... why is this?



-- 
Joe


From owner-linux-mips@oss.sgi.com Wed Feb  7 14:48:17 2001
Received:  by oss.sgi.com id <S553714AbRBGWr5>;
	Wed, 7 Feb 2001 14:47:57 -0800
Received: from mx.mips.com ([206.31.31.226]:7361 "EHLO mx.mips.com")
	by oss.sgi.com with ESMTP id <S553724AbRBGWru>;
	Wed, 7 Feb 2001 14:47:50 -0800
Received: from newman.mips.com (ns-dmz [206.31.31.225])
	by mx.mips.com (8.9.3/8.9.0) with ESMTP id OAA04217;
	Wed, 7 Feb 2001 14:47:48 -0800 (PST)
Received: from Ulysses (ulysses [192.168.236.13])
	by newman.mips.com (8.9.3/8.9.0) with SMTP id OAA04845;
	Wed, 7 Feb 2001 14:47:45 -0800 (PST)
Message-ID: <005101c09158$85941d40$0deca8c0@Ulysses>
From:   "Kevin D. Kissell" <kevink@mips.com>
To:     "Jun Sun" <jsun@mvista.com>, "Florian Lohoff" <flo@rfc822.org>
Cc:     <linux-mips@oss.sgi.com>, <ralf@oss.sgi.com>
References: <20010207144857.B24485@paradigm.rfc822.org> <3A819B80.7946F866@mvista.com>
Subject: Re: NON FPU cpus - way to go
Date:   Wed, 7 Feb 2001 23:51:25 +0100
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing

> Moving forward I see MIPS mainly used in embedded systems.  I think need
of
> using the same kernel binary for multiple CPUs is rare, especially for the
> "same" CPU with or without FPU.  Therefore having run-time detection is a
> waste of effort.  Half-config-half-runtime solution is pretty messy too.
>
> For CPUs with the same PrID that may or may not have a FPU, we can add an
> optional FPU selection in the config.in file.b
>
> To be complete, I probably would add a check for the existence of FPU, if
we
> can infer from PrID, when FPU config option is enabled.

A few comments here:

Moving forward,  MIPS CPUs will have a specific FPU-present bit
in one of the CP0 Config registers, as specified by MIPS32/MIPS64.
So the effort wasted in run-time detection will be pretty damned small.

As other people have observed, having the FPU emulator in
the kernel is necessary for full IEEE math even if one *has*
an FPU.  When I bolted the Algorithmics emulator into the 2.2
kernel at MIPS, I made it optional so that people could regress
to Ralf's old not-fully-compliant mini-emulator if they were really
desperate for memory and didn't need full IEEE.  Maybe I
should have just nuked it and made the full emulator mandatory.

As far as the library-versus-kernel-emulation debate is
concerned, yes, user-level emulation will always be faster.
However, you end up with a rather unpleasant configration
management problem - every application and library
distributed needs to be built both with and without FP.
And this affects *every* binary - even those that do zero
FP computation will try to save and restore FPU state
on setjmp/longjmp operations in the best of cases,
and in the existing subobtimal reality, whatever the
hell GCC calls crt0.o touches the floating control
registers on program startup.   My own opinion has
been that people who care about FP performance
run their applications on CPUs with hardware FP,
so the performance advantage of library-based
FP emulation is largely wasted on those who don't
care about it.  But I would understand if the Vr-Linux guys
disagreed with me on that!

            Regards,

            Kevin K.


From owner-linux-mips@oss.sgi.com Wed Feb  7 15:57:07 2001
Received:  by oss.sgi.com id <S553714AbRBGX4s>;
	Wed, 7 Feb 2001 15:56:48 -0800
Received: from sgigate.SGI.COM ([204.94.209.1]:48352 "EHLO dea.waldorf-gmbh.de")
	by oss.sgi.com with ESMTP id <S553687AbRBGX4e>;
	Wed, 7 Feb 2001 15:56:34 -0800
Received: (from ralf@localhost)
	by dea.waldorf-gmbh.de (8.11.1/8.11.1) id f17NoIS24931;
	Wed, 7 Feb 2001 15:50:18 -0800
Date:   Wed, 7 Feb 2001 15:50:17 -0800
From:   Ralf Baechle <ralf@oss.sgi.com>
To:     Jim Freeman <jfree@sovereign.org>
Cc:     linux-mips@oss.sgi.com
Subject: Re: merges into stock kernel tree
Message-ID: <20010207155017.A24908@bacchus.dhis.org>
References: <20010207111342.A27046@sovereign.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <20010207111342.A27046@sovereign.org>; from jfree@sovereign.org on Wed, Feb 07, 2001 at 11:13:42AM -0700
X-Accept-Language: de,en,fr
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing

On Wed, Feb 07, 2001 at 11:13:42AM -0700, Jim Freeman wrote:

> Not having a variety of mips hw to play with, what is the functional
> status of mips as shipped in the mainstream kernel?
> 
> How does that status compare to the functional status of the
> current mips in cvs?

32-bit kernel was never functional; 64-bit kernel should compile again
if Linus accepts my latest batch of patches.

> What's on the todo list prior to another merge into the upstream?

As usual - rework anything that isn't suitable to be merged into Linus'
tree.

  Ralf

From owner-linux-mips@oss.sgi.com Thu Feb  8 00:48:33 2001
Received:  by oss.sgi.com id <S553743AbRBHIsN>;
	Thu, 8 Feb 2001 00:48:13 -0800
Received: from mail.sonytel.be ([193.74.243.200]:33923 "EHLO mail.sonytel.be")
	by oss.sgi.com with ESMTP id <S553738AbRBHIrt>;
	Thu, 8 Feb 2001 00:47:49 -0800
Received: from escobaria.sonytel.be (escobaria.sonytel.be [10.34.80.3])
	by mail.sonytel.be (8.9.0/8.8.6) with ESMTP id JAA00884;
	Thu, 8 Feb 2001 09:45:57 +0100 (MET)
Date:   Thu, 8 Feb 2001 09:45:57 +0100 (MET)
From:   Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com>
To:     Joe deBlaquiere <jadb@redhat.com>
cc:     Jun Sun <jsun@mvista.com>, Alan Cox <alan@lxorguk.ukuu.org.uk>,
        "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>,
        Florian Lohoff <flo@rfc822.org>, linux-mips@oss.sgi.com,
        ralf@oss.sgi.com
Subject: Re: NON FPU cpus - way to go
In-Reply-To: <3A81B388.1090806@redhat.com>
Message-ID: <Pine.GSO.4.10.10102080944510.23477-100000@escobaria.sonytel.be>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing

On Wed, 7 Feb 2001, Joe deBlaquiere wrote:
> Jun Sun wrote:
> > Alan Cox wrote:
> >> Also we missed a trick on the x86 and I want to fix that one day, which is
> >> to have an __fpu ELF segment so if you boot an FPU emu kernel on an fpu
> >> box you regain 47K
> > 
> > 
> > Ironically for MIPS you MUST have the FPU emulater when the CPU actually has a
> > FPU. :-)
> 
> I'm confused here... why is this?

Because a MIPS CPU may implement only some functionality with some operands,
and decide to throw an `unsupported' exception if the operation is too complex.

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven ------------- Sony Software Development Center Europe (SDCE)
Geert.Uytterhoeven@sonycom.com ------------------- Sint-Stevens-Woluwestraat 55
Voice +32-2-7248626 Fax +32-2-7262686 ---------------- B-1130 Brussels, Belgium


From owner-linux-mips@oss.sgi.com Thu Feb  8 02:20:42 2001
Received:  by oss.sgi.com id <S553747AbRBHKUd>;
	Thu, 8 Feb 2001 02:20:33 -0800
Received: from delta.ds2.pg.gda.pl ([153.19.144.1]:50588 "EHLO
        delta.ds2.pg.gda.pl") by oss.sgi.com with ESMTP id <S553742AbRBHKUN>;
	Thu, 8 Feb 2001 02:20:13 -0800
Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id LAA29588;
	Thu, 8 Feb 2001 11:13:55 +0100 (MET)
Date:   Thu, 8 Feb 2001 11:13:55 +0100 (MET)
From:   "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To:     Jun Sun <jsun@mvista.com>
cc:     Alan Cox <alan@lxorguk.ukuu.org.uk>,
        Florian Lohoff <flo@rfc822.org>, linux-mips@oss.sgi.com,
        ralf@oss.sgi.com
Subject: Re: NON FPU cpus - way to go
In-Reply-To: <3A81A3DC.E75E6045@mvista.com>
Message-ID: <Pine.GSO.3.96.1010208110748.29177A-100000@delta.ds2.pg.gda.pl>
Organization: Technical University of Gdansk
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing

On Wed, 7 Feb 2001, Jun Sun wrote:

> I favor the libc approach as it is faster.

 No difference in speed, actually.  In both cases you switch to the kernel
mode when an FPU-related exception happens and then back to the user mode,
either after or before invoking the handler.  The libc approach has the
advantage of running unprivileged. 

> Unfortunately I don't think glibc for MIPS can be configured with
> --without-fp.  I modified a patch to get glibc 2.0.6 working for no-fp config,
> but it is not a clean one.  Is anybody working on that for the latest glibc
> 2.2?

 You never want to configure glibc with the --without-fp option.

> Ironically for MIPS you MUST have the FPU emulater when the CPU actually has a
> FPU. :-)

 The same for Alpha.  You don't need a full emulator anyway -- most of it
can be left out for FPU-equipped systems.

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +


From owner-linux-mips@oss.sgi.com Thu Feb  8 02:31:43 2001
Received:  by oss.sgi.com id <S553755AbRBHKbd>;
	Thu, 8 Feb 2001 02:31:33 -0800
Received: from delta.ds2.pg.gda.pl ([153.19.144.1]:59292 "EHLO
        delta.ds2.pg.gda.pl") by oss.sgi.com with ESMTP id <S553750AbRBHKbR>;
	Thu, 8 Feb 2001 02:31:17 -0800
Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id LAA29771;
	Thu, 8 Feb 2001 11:24:15 +0100 (MET)
Date:   Thu, 8 Feb 2001 11:24:14 +0100 (MET)
From:   "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To:     Jun Sun <jsun@mvista.com>
cc:     Florian Lohoff <flo@rfc822.org>, linux-mips@oss.sgi.com,
        ralf@oss.sgi.com
Subject: Re: NON FPU cpus - way to go
In-Reply-To: <3A819B80.7946F866@mvista.com>
Message-ID: <Pine.GSO.3.96.1010208111500.29177B-100000@delta.ds2.pg.gda.pl>
Organization: Technical University of Gdansk
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing

On Wed, 7 Feb 2001, Jun Sun wrote:

> Moving forward I see MIPS mainly used in embedded systems.  I think need of
> using the same kernel binary for multiple CPUs is rare, especially for the
> "same" CPU with or without FPU.  Therefore having run-time detection is a
> waste of effort.  Half-config-half-runtime solution is pretty messy too.

 Since the run-time detection is about three lines of code (and the
resulting code consists of a similar number of CPU instructions) I
consider it no effort at all.  And remember not only hackers want to use
Linux -- not everyone is going to recompile his own kernel, and the MIPS
world is not limited to embedded devices -- there is quite a number of
MIPS workstation and server systems out there. 

 Neither crashing silently nor printing an obscure oops is not an option
when no FP hw is available and we require it for one reason or another. 

 I hope we will be able to build a generic MIPS kernel one day, just like
we can do for Alpha -- it would encourage redundant code removal which in 
turn would improve cleanness and consistency. 

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +


From owner-linux-mips@oss.sgi.com Thu Feb  8 02:47:33 2001
Received:  by oss.sgi.com id <S553760AbRBHKrX>;
	Thu, 8 Feb 2001 02:47:23 -0800
Received: from delta.ds2.pg.gda.pl ([153.19.144.1]:4253 "EHLO
        delta.ds2.pg.gda.pl") by oss.sgi.com with ESMTP id <S553756AbRBHKrH>;
	Thu, 8 Feb 2001 02:47:07 -0800
Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id LAA00370;
	Thu, 8 Feb 2001 11:42:46 +0100 (MET)
Date:   Thu, 8 Feb 2001 11:42:45 +0100 (MET)
From:   "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To:     Alan Cox <alan@lxorguk.ukuu.org.uk>
cc:     Florian Lohoff <flo@rfc822.org>, linux-mips@oss.sgi.com,
        ralf@oss.sgi.com
Subject: Re: NON FPU cpus - way to go
In-Reply-To: <E14QZie-00011I-00@the-village.bc.nu>
Message-ID: <Pine.GSO.3.96.1010208112520.29177C-100000@delta.ds2.pg.gda.pl>
Organization: Technical University of Gdansk
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing

On Wed, 7 Feb 2001, Alan Cox wrote:

> Its an interesting question whether it belongs in the kernel or libc. 
> Discuss ;)

 Hmm, emulating a missing part of CPU seems more natural in the kernel
mode.  It's completely transparent -- no difference to userland software
whether there is a real part or an emulator.

 The libc approach has the advantage of being unprivileged -- a fault in
an emulator cannot itself bring a system down.  It's non-transparent,
though -- it may give interesting effects when debugging. 

> Also we missed a trick on the x86 and I want to fix that one day, which is
> to have an __fpu ELF segment so if you boot an FPU emu kernel on an fpu
> box you regain 47K

 A good idea, even though hardly anyone needs the emulator for i386 these
days. ;-) 

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +


From owner-linux-mips@oss.sgi.com Thu Feb  8 02:48:52 2001
Received:  by oss.sgi.com id <S553762AbRBHKsm>;
	Thu, 8 Feb 2001 02:48:42 -0800
Received: from mx.mips.com ([206.31.31.226]:43210 "EHLO mx.mips.com")
	by oss.sgi.com with ESMTP id <S553757AbRBHKsb>;
	Thu, 8 Feb 2001 02:48:31 -0800
Received: from newman.mips.com (ns-dmz [206.31.31.225])
	by mx.mips.com (8.9.3/8.9.0) with ESMTP id CAA10269;
	Thu, 8 Feb 2001 02:48:30 -0800 (PST)
Received: from Ulysses (ulysses [192.168.236.13])
	by newman.mips.com (8.9.3/8.9.0) with SMTP id CAA21819;
	Thu, 8 Feb 2001 02:48:25 -0800 (PST)
Message-ID: <003901c091bd$33686520$0deca8c0@Ulysses>
From:   "Kevin D. Kissell" <kevink@mips.com>
To:     "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>,
        "Jun Sun" <jsun@mvista.com>
Cc:     "Alan Cox" <alan@lxorguk.ukuu.org.uk>,
        "Florian Lohoff" <flo@rfc822.org>, <linux-mips@oss.sgi.com>,
        <ralf@oss.sgi.com>
References: <Pine.GSO.3.96.1010208110748.29177A-100000@delta.ds2.pg.gda.pl>
Subject: Re: NON FPU cpus - way to go
Date:   Thu, 8 Feb 2001 11:52:01 +0100
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing

> On Wed, 7 Feb 2001, Jun Sun wrote:
>
> > I favor the libc approach as it is faster.
>
>  No difference in speed, actually.  In both cases you switch to the kernel
> mode when an FPU-related exception happens and then back to the user mode,
> either after or before invoking the handler.  The libc approach has the
> advantage of running unprivileged.

Do you have some numbers to support this?  A proper library
implementation does *not* trap to the kernel on each FPU
instruction, and as such is considerably faster (and considerably
larger - a factor for embedded apps!) than a kernel emulation.
The Algorithmics emulator does have the virtue of being smart
enough to check if there is a sequence of consecutive FP
instructions, and to emulate the whole sequence without
returning to user mode, but such "runs" are not all that
common in real code - there are almost always loads,
stores, and address computations interspersed, because
the compiler is "clever" about hiding FP latencies!

> > Unfortunately I don't think glibc for MIPS can be configured with
> > --without-fp.  I modified a patch to get glibc 2.0.6 working for no-fp
config,
> > but it is not a clean one.  Is anybody working on that for the latest
glibc
> > 2.2?
>
>  You never want to configure glibc with the --without-fp option.

That's certainly what we had to do for OpenBSD without FP
emulation!  What is the alternative?

> > Ironically for MIPS you MUST have the FPU emulater when the CPU actually
has a
> > FPU. :-)
>
>  The same for Alpha.  You don't need a full emulator anyway -- most of it
> can be left out for FPU-equipped systems.

That may be true for Alpha, but not for MIPS.  The only
instructions that can *never* generate an unimplented
operation trap on a denormalized operand are the
loads, stores, and moves.  That's why we didn't bother
breaking up the Algorithmics emulator into with-FPU
and without-FPU modules - there was surprisingly little
that could really be left out.

            Regards,

            Kevin K.


From owner-linux-mips@oss.sgi.com Thu Feb  8 02:55:12 2001
Received:  by oss.sgi.com id <S553764AbRBHKzC>;
	Thu, 8 Feb 2001 02:55:02 -0800
Received: from mail.sonytel.be ([193.74.243.200]:31900 "EHLO mail.sonytel.be")
	by oss.sgi.com with ESMTP id <S553761AbRBHKy4>;
	Thu, 8 Feb 2001 02:54:56 -0800
Received: from escobaria.sonytel.be (escobaria.sonytel.be [10.34.80.3])
	by mail.sonytel.be (8.9.0/8.8.6) with ESMTP id LAA06953;
	Thu, 8 Feb 2001 11:53:52 +0100 (MET)
Date:   Thu, 8 Feb 2001 11:53:52 +0100 (MET)
From:   Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com>
To:     "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
cc:     Alan Cox <alan@lxorguk.ukuu.org.uk>,
        Florian Lohoff <flo@rfc822.org>, linux-mips@oss.sgi.com,
        ralf@oss.sgi.com
Subject: Re: NON FPU cpus - way to go
In-Reply-To: <Pine.GSO.3.96.1010208112520.29177C-100000@delta.ds2.pg.gda.pl>
Message-ID: <Pine.GSO.4.10.10102081151560.23477-100000@escobaria.sonytel.be>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing

On Thu, 8 Feb 2001, Maciej W. Rozycki wrote:
> On Wed, 7 Feb 2001, Alan Cox wrote:
> > Also we missed a trick on the x86 and I want to fix that one day, which is
> > to have an __fpu ELF segment so if you boot an FPU emu kernel on an fpu
> > box you regain 47K
> 
>  A good idea, even though hardly anyone needs the emulator for i386 these
> days. ;-) 

Yep, I put it on my m68k TODO list as well ;-)

Alternatively you can make (most of) it a loadable module. I don't think
/sbin/modprobe needs the FPU :-)

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven ------------- Sony Software Development Center Europe (SDCE)
Geert.Uytterhoeven@sonycom.com ------------------- Sint-Stevens-Woluwestraat 55
Voice +32-2-7248626 Fax +32-2-7262686 ---------------- B-1130 Brussels, Belgium


From owner-linux-mips@oss.sgi.com Thu Feb  8 02:58:52 2001
Received:  by oss.sgi.com id <S553767AbRBHK6m>;
	Thu, 8 Feb 2001 02:58:42 -0800
Received: from delta.ds2.pg.gda.pl ([153.19.144.1]:14493 "EHLO
        delta.ds2.pg.gda.pl") by oss.sgi.com with ESMTP id <S553761AbRBHK6e>;
	Thu, 8 Feb 2001 02:58:34 -0800
Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id LAA00667;
	Thu, 8 Feb 2001 11:54:57 +0100 (MET)
Date:   Thu, 8 Feb 2001 11:54:56 +0100 (MET)
From:   "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To:     "Kevin D. Kissell" <kevink@mips.com>
cc:     Jun Sun <jsun@mvista.com>, Florian Lohoff <flo@rfc822.org>,
        linux-mips@oss.sgi.com, ralf@oss.sgi.com
Subject: Re: NON FPU cpus - way to go
In-Reply-To: <005101c09158$85941d40$0deca8c0@Ulysses>
Message-ID: <Pine.GSO.3.96.1010208114254.29177D-100000@delta.ds2.pg.gda.pl>
Organization: Technical University of Gdansk
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing

On Wed, 7 Feb 2001, Kevin D. Kissell wrote:

> Moving forward,  MIPS CPUs will have a specific FPU-present bit
> in one of the CP0 Config registers, as specified by MIPS32/MIPS64.

 Thanks for pointing this out -- this might prove useful.  Though the old
IDT detection method is not any more complicated and it's universal.  It
should work for MIPS32/MIPS64 anyway, right? 

> As other people have observed, having the FPU emulator in
> the kernel is necessary for full IEEE math even if one *has*
> an FPU.  When I bolted the Algorithmics emulator into the 2.2
> kernel at MIPS, I made it optional so that people could regress
> to Ralf's old not-fully-compliant mini-emulator if they were really
> desperate for memory and didn't need full IEEE.  Maybe I
> should have just nuked it and made the full emulator mandatory.

 How much of the emulator is really required for every system?  Can we
assume R[23]010 functionality if there is FP hw present?

> As far as the library-versus-kernel-emulation debate is
> concerned, yes, user-level emulation will always be faster.

 Why would be faster?  You need to handle SIGFPE, which needs a
user->kernel->user transition anyway.  I think a kernel emulation might be
marginally faster as we may skip signal interface handling (and such
details like an integer overflow/division by zero) and handle exceptions
directly. 

> However, you end up with a rather unpleasant configration
> management problem - every application and library
> distributed needs to be built both with and without FP.

 Nope -- you just require an emulator in glibc (or whatever libc you
decide to use).  No need to change application software -- FP opcodes will
just trap into libc.

  Maciej

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +


From owner-linux-mips@oss.sgi.com Thu Feb  8 03:01:13 2001
Received:  by oss.sgi.com id <S553769AbRBHLBD>;
	Thu, 8 Feb 2001 03:01:03 -0800
Received: from router-100M.swansea.linux.org.uk ([194.168.151.17]:3338 "EHLO
        the-village.bc.nu") by oss.sgi.com with ESMTP id <S553763AbRBHLA7>;
	Thu, 8 Feb 2001 03:00:59 -0800
Received: from alan by the-village.bc.nu with local (Exim 2.12 #1)
	id 14QomC-0003Bu-00; Thu, 8 Feb 2001 10:58:12 +0000
Subject: Re: NON FPU cpus - way to go
To:     Geert.Uytterhoeven@sonycom.com (Geert Uytterhoeven)
Date:   Thu, 8 Feb 2001 10:58:09 +0000 (GMT)
Cc:     macro@ds2.pg.gda.pl (Maciej W. Rozycki),
        alan@lxorguk.ukuu.org.uk (Alan Cox),
        flo@rfc822.org (Florian Lohoff), linux-mips@oss.sgi.com,
        ralf@oss.sgi.com
In-Reply-To: <Pine.GSO.4.10.10102081151560.23477-100000@escobaria.sonytel.be> from "Geert Uytterhoeven" at Feb 08, 2001 11:53:52 AM
X-Mailer: ELM [version 2.5 PL1]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <E14QomC-0003Bu-00@the-village.bc.nu>
From:   Alan Cox <alan@lxorguk.ukuu.org.uk>
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing

> Yep, I put it on my m68k TODO list as well ;-)
> 
> Alternatively you can make (most of) it a loadable module. I don't think
> /sbin/modprobe needs the FPU :-)

Task state init ?

m68k wants __mac __amiga and __atari as well of course ;)


From owner-linux-mips@oss.sgi.com Thu Feb  8 03:07:22 2001
Received:  by oss.sgi.com id <S553772AbRBHLHM>;
	Thu, 8 Feb 2001 03:07:12 -0800
Received: from mail.sonytel.be ([193.74.243.200]:52382 "EHLO mail.sonytel.be")
	by oss.sgi.com with ESMTP id <S553763AbRBHLHH>;
	Thu, 8 Feb 2001 03:07:07 -0800
Received: from escobaria.sonytel.be (escobaria.sonytel.be [10.34.80.3])
	by mail.sonytel.be (8.9.0/8.8.6) with ESMTP id MAA07551;
	Thu, 8 Feb 2001 12:05:14 +0100 (MET)
Date:   Thu, 8 Feb 2001 12:05:14 +0100 (MET)
From:   Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com>
To:     Alan Cox <alan@lxorguk.ukuu.org.uk>
cc:     "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>,
        Florian Lohoff <flo@rfc822.org>, linux-mips@oss.sgi.com,
        ralf@oss.sgi.com
Subject: Re: NON FPU cpus - way to go
In-Reply-To: <E14QomC-0003Bu-00@the-village.bc.nu>
Message-ID: <Pine.GSO.4.10.10102081204300.23477-100000@escobaria.sonytel.be>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing

On Thu, 8 Feb 2001, Alan Cox wrote:
> > Yep, I put it on my m68k TODO list as well ;-)
> > 
> > Alternatively you can make (most of) it a loadable module. I don't think
> > /sbin/modprobe needs the FPU :-)
> 
> Task state init ?

That's why I wrote `(most of)'.

> m68k wants __mac __amiga and __atari as well of course ;)

Yep, one more thing for the list...

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven ------------- Sony Software Development Center Europe (SDCE)
Geert.Uytterhoeven@sonycom.com ------------------- Sint-Stevens-Woluwestraat 55
Voice +32-2-7248626 Fax +32-2-7262686 ---------------- B-1130 Brussels, Belgium


From owner-linux-mips@oss.sgi.com Thu Feb  8 03:20:53 2001
Received:  by oss.sgi.com id <S553774AbRBHLUn>;
	Thu, 8 Feb 2001 03:20:43 -0800
Received: from noose.gt.owl.de ([62.52.19.4]:25104 "HELO noose.gt.owl.de")
	by oss.sgi.com with SMTP id <S553768AbRBHLU1>;
	Thu, 8 Feb 2001 03:20:27 -0800
Received: by noose.gt.owl.de (Postfix, from userid 10)
	id E64CE7DD; Thu,  8 Feb 2001 12:20:15 +0100 (CET)
Received: by paradigm.rfc822.org (Postfix, from userid 1000)
	id 824DCEEAC; Thu,  8 Feb 2001 12:20:30 +0100 (CET)
Date:   Thu, 8 Feb 2001 12:20:30 +0100
From:   Florian Lohoff <flo@rfc822.org>
To:     linux-mips@oss.sgi.com
Subject: [RESUME] fpu emulator
Message-ID: <20010208122030.A5408@paradigm.rfc822.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
Organization: rfc822 - pure communication
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing


Hi,
just to get it right - As i thought the FPU emulator is not really
optional - It is even required for fpu-enabled devices which means
we should clean the code in that way that if the user decides to 
compile in the fpu emulator into the kernel we do an autodetection 
upfront and change some of the entry/exit/lazy_fpu stuff.
If the user decides not to compile in the FPU Emulator he is on his
own and we ignore the whole FPU stuff and simply send SIGILL/SIGFPE
to the processes causing all fpu binarys to fail on non-fpu enabled
kernels.

Flo
-- 
Florian Lohoff                  flo@rfc822.org             +49-5201-669912
     Why is it called "common sense" when nobody seems to have any?


From owner-linux-mips@oss.sgi.com Thu Feb  8 03:24:43 2001
Received:  by oss.sgi.com id <S553778AbRBHLYc>;
	Thu, 8 Feb 2001 03:24:32 -0800
Received: from mail.sonytel.be ([193.74.243.200]:12705 "EHLO mail.sonytel.be")
	by oss.sgi.com with ESMTP id <S553775AbRBHLYV>;
	Thu, 8 Feb 2001 03:24:21 -0800
Received: from ginger.sonytel.be (ginger.sonytel.be [10.34.16.6])
	by mail.sonytel.be (8.9.0/8.8.6) with ESMTP id MAA08295
	for <linux-mips@oss.sgi.com>; Thu, 8 Feb 2001 12:24:18 +0100 (MET)
Received: (from tea@localhost)
	by ginger.sonytel.be (8.9.0/8.8.6) id MAA08717
	for linux-mips@oss.sgi.com; Thu, 8 Feb 2001 12:24:18 +0100 (MET)
Date:   Thu, 8 Feb 2001 12:24:18 +0100
From:   Tom Appermont <tea@sonycom.com>
To:     linux-mips@oss.sgi.com
Subject: booting from NFS
Message-ID: <20010208122418.D8548@ginger.sonytel.be>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0i
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing


Hi,

I'm having a problem booting from a mipsel base file system over
NFS. The kernel version is 2.4.1, on a ddb5074 development board.
There is probably nothing wrong with the base file system itself 
(got it from bolug.uni-bonn.de and it works fine for an older 
2.4.0-test1-ac21 kernel). The nfsd log shows that the mount 
succeeds, but blocks when the board tries to get ld-2.0.6.so. The 
output of the nfsd is attached below. Any help is greatly 
appreciated.


Greetz,

Tom


--
Feb  8 12:18:38 crane bootpd[576]: recvd pkt from IP addr 0.0.0.0
Feb  8 12:18:38 crane bootpd[576]: bootptab mtime: Wed Feb  7 16:02:03 2001
Feb  8 12:18:38 crane bootpd[576]: request from Ethernet address 00:20:18:39:26:E9
Feb  8 12:18:38 crane bootpd[576]: found 192.168.18.70 (linux-ddb)
Feb  8 12:18:38 crane bootpd[576]: bootfile="/usr/boot/mipsel"
Feb  8 12:18:38 crane bootpd[576]: vendor magic field is 99.130.83.99
Feb  8 12:18:38 crane bootpd[576]: request message length=364
Feb  8 12:18:38 crane bootpd[576]: extended reply, length=364, options=128
Feb  8 12:18:38 crane bootpd[576]: sending reply (with RFC1048 options)
Feb  8 12:18:38 crane bootpd[576]: setarp 192.168.18.70 - 00:20:18:39:26:E9
Feb  8 12:18:38 crane mountd[214]: NFS mount of /usr/boot/mipsel attempted from 192.168.18.70
Feb  8 12:18:38 crane mountd[214]: /usr/boot/mipsel has been mounted by 192.168.18.70
Feb  8 12:18:38 crane nfsd[212]: getattr [1 70/1/1 01:00:00 192.168.18.70 0.0]
Feb  8 12:18:38 crane nfsd[212]:        /usr/boot/mipsel
Feb  8 12:18:38 crane nfsd[212]: result: 0
Feb  8 12:18:38 crane nfsd[212]: statfs [1 70/1/1 01:00:00 192.168.18.70 0.0]
Feb  8 12:18:38 crane nfsd[212]:        /usr/boot/mipsel
Feb  8 12:18:38 crane nfsd[212]: result: 0
Feb  8 12:18:38 crane nfsd[212]: lookup [1 70/1/1 01:00:00 192.168.18.70 0.0]
Feb  8 12:18:38 crane nfsd[212]:        fh:/usr/boot/mipsel n:dev
Feb  8 12:18:38 crane nfsd[212]:        new_fh = /usr/boot/mipsel/dev
Feb  8 12:18:38 crane nfsd[212]: result: 0
Feb  8 12:18:38 crane nfsd[212]: lookup [1 70/1/1 01:00:00 192.168.18.70 0.0]
Feb  8 12:18:38 crane nfsd[212]:        fh:/usr/boot/mipsel/dev n:console
Feb  8 12:18:38 crane nfsd[212]:        new_fh = /usr/boot/mipsel/dev/console
Feb  8 12:18:38 crane nfsd[212]: result: 0
Feb  8 12:18:38 crane nfsd[212]: lookup [1 70/1/1 01:00:00 192.168.18.70 0.0]
Feb  8 12:18:38 crane nfsd[212]:        fh:/usr/boot/mipsel n:sbin
Feb  8 12:18:38 crane nfsd[212]:        new_fh = /usr/boot/mipsel/sbin
Feb  8 12:18:38 crane nfsd[212]: result: 0
Feb  8 12:18:38 crane nfsd[212]: lookup [1 70/1/1 01:00:00 192.168.18.70 0.0]
Feb  8 12:18:38 crane nfsd[212]:        fh:/usr/boot/mipsel/sbin n:init
Feb  8 12:18:38 crane nfsd[212]:        new_fh = /usr/boot/mipsel/sbin/init
Feb  8 12:18:38 crane nfsd[212]: result: 0
Feb  8 12:18:38 crane nfsd[212]: read [1 70/1/1 01:00:00 192.168.18.70 0.0]
Feb  8 12:18:38 crane nfsd[212]:        /usr/boot/mipsel/sbin/init: 4096 bytes at 0
Feb  8 12:18:38 crane nfsd[212]: result: 0
Feb  8 12:18:38 crane nfsd[212]: lookup [1 70/1/1 01:00:00 192.168.18.70 0.0]
Feb  8 12:18:38 crane nfsd[212]:        fh:/usr/boot/mipsel n:lib
Feb  8 12:18:38 crane nfsd[212]:        new_fh = /usr/boot/mipsel/lib
Feb  8 12:18:38 crane nfsd[212]: result: 0
Feb  8 12:18:38 crane nfsd[212]: lookup [1 70/1/1 01:00:00 192.168.18.70 0.0]
Feb  8 12:18:38 crane nfsd[212]:        fh:/usr/boot/mipsel/lib n:ld.so.1
Feb  8 12:18:38 crane nfsd[212]:        new_fh = /usr/boot/mipsel/lib/ld.so.1
Feb  8 12:18:38 crane nfsd[212]: result: 0
Feb  8 12:18:38 crane nfsd[212]: readlink [1 70/1/1 01:00:00 192.168.18.70 0.0]
Feb  8 12:18:38 crane nfsd[212]:        /usr/boot/mipsel/lib/ld.so.1
Feb  8 12:18:38 crane nfsd[212]:  ld-2.0.6.so
Feb  8 12:18:38 crane nfsd[212]: result: 0
Feb  8 12:18:38 crane nfsd[212]: lookup [1 70/1/1 01:00:00 192.168.18.70 0.0]
Feb  8 12:18:38 crane nfsd[212]:        fh:/usr/boot/mipsel/lib n:ld-2.0.6.so
Feb  8 12:18:38 crane nfsd[212]:        new_fh = /usr/boot/mipsel/lib/ld-2.0.6.so
Feb  8 12:18:38 crane nfsd[212]: result: 0
Feb  8 12:18:38 crane nfsd[212]: read [1 70/1/1 01:00:00 192.168.18.70 0.0]
Feb  8 12:18:38 crane nfsd[212]:        /usr/boot/mipsel/lib/ld-2.0.6.so: 4096 bytes at 0
Feb  8 12:18:38 crane nfsd[212]: result: 0


From owner-linux-mips@oss.sgi.com Thu Feb  8 03:25:52 2001
Received:  by oss.sgi.com id <S553782AbRBHLZm>;
	Thu, 8 Feb 2001 03:25:42 -0800
Received: from delta.ds2.pg.gda.pl ([153.19.144.1]:38557 "EHLO
        delta.ds2.pg.gda.pl") by oss.sgi.com with ESMTP id <S553773AbRBHLZh>;
	Thu, 8 Feb 2001 03:25:37 -0800
Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id MAA01475;
	Thu, 8 Feb 2001 12:19:45 +0100 (MET)
Date:   Thu, 8 Feb 2001 12:19:43 +0100 (MET)
From:   "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To:     "Kevin D. Kissell" <kevink@mips.com>
cc:     Jun Sun <jsun@mvista.com>, Alan Cox <alan@lxorguk.ukuu.org.uk>,
        Florian Lohoff <flo@rfc822.org>, linux-mips@oss.sgi.com,
        ralf@oss.sgi.com
Subject: Re: NON FPU cpus - way to go
In-Reply-To: <003901c091bd$33686520$0deca8c0@Ulysses>
Message-ID: <Pine.GSO.3.96.1010208115525.29177E-100000@delta.ds2.pg.gda.pl>
Organization: Technical University of Gdansk
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing

On Thu, 8 Feb 2001, Kevin D. Kissell wrote:

> Do you have some numbers to support this?  A proper library
> implementation does *not* trap to the kernel on each FPU
> instruction, and as such is considerably faster (and considerably
> larger - a factor for embedded apps!) than a kernel emulation.

 Now you are writing of a compiler emulation and not a library one.  While
such a solution is reasonable for firmware or other OS-less or even
libc-less environment, its much too painful for normal use.  Either you
lose for real FPU environments due to extra overhead to invoke FPU
operations or you have two sets of incompatible binaries (one that invokes
FPU diractly and the other one with emulator hooks).

> >  You never want to configure glibc with the --without-fp option.
> 
> That's certainly what we had to do for OpenBSD without FP
> emulation!  What is the alternative?

 Write one. ;-)

> That may be true for Alpha, but not for MIPS.  The only
> instructions that can *never* generate an unimplented
> operation trap on a denormalized operand are the
> loads, stores, and moves.  That's why we didn't bother
> breaking up the Algorithmics emulator into with-FPU
> and without-FPU modules - there was surprisingly little
> that could really be left out.

 I dont know the gory details of the Alpha FPU implementation, but from
what I've read, it's denormal handling that needs the emulation.  And all
bits are already present in our generic emulator -- the only glue needed
is mapping of opcodes to FP operations -- see arch/alpha/math-emu/math.c
how its done (the file is "whole" 9kB!). 

 There are no FP-less Alpha parts, though.  And that's not surprising --
the FPU is one of Alpha aces.

  Maciej

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +


From owner-linux-mips@oss.sgi.com Thu Feb  8 03:28:03 2001
Received:  by oss.sgi.com id <S553785AbRBHL1x>;
	Thu, 8 Feb 2001 03:27:53 -0800
Received: from delta.ds2.pg.gda.pl ([153.19.144.1]:42909 "EHLO
        delta.ds2.pg.gda.pl") by oss.sgi.com with ESMTP id <S553777AbRBHL1n>;
	Thu, 8 Feb 2001 03:27:43 -0800
Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id MAA01590;
	Thu, 8 Feb 2001 12:22:15 +0100 (MET)
Date:   Thu, 8 Feb 2001 12:22:15 +0100 (MET)
From:   "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To:     Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com>
cc:     Alan Cox <alan@lxorguk.ukuu.org.uk>,
        Florian Lohoff <flo@rfc822.org>, linux-mips@oss.sgi.com,
        ralf@oss.sgi.com
Subject: Re: NON FPU cpus - way to go
In-Reply-To: <Pine.GSO.4.10.10102081151560.23477-100000@escobaria.sonytel.be>
Message-ID: <Pine.GSO.3.96.1010208122024.29177F-100000@delta.ds2.pg.gda.pl>
Organization: Technical University of Gdansk
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing

On Thu, 8 Feb 2001, Geert Uytterhoeven wrote:

> Alternatively you can make (most of) it a loadable module. I don't think
> /sbin/modprobe needs the FPU :-)

 I bet libc will want to initialize FPU's control word or something like
that at the least expected moment. ;-)

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +


From owner-linux-mips@oss.sgi.com Thu Feb  8 03:35:03 2001
Received:  by oss.sgi.com id <S553788AbRBHLey>;
	Thu, 8 Feb 2001 03:34:54 -0800
Received: from mx.mips.com ([206.31.31.226]:12238 "EHLO mx.mips.com")
	by oss.sgi.com with ESMTP id <S553784AbRBHLet>;
	Thu, 8 Feb 2001 03:34:49 -0800
Received: from newman.mips.com (ns-dmz [206.31.31.225])
	by mx.mips.com (8.9.3/8.9.0) with ESMTP id DAA11318;
	Thu, 8 Feb 2001 03:34:48 -0800 (PST)
Received: from Ulysses (ulysses [192.168.236.13])
	by newman.mips.com (8.9.3/8.9.0) with SMTP id DAA23183;
	Thu, 8 Feb 2001 03:34:45 -0800 (PST)
Message-ID: <005901c091c3$ab3c9b60$0deca8c0@Ulysses>
From:   "Kevin D. Kissell" <kevink@mips.com>
To:     "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
Cc:     "Jun Sun" <jsun@mvista.com>, "Alan Cox" <alan@lxorguk.ukuu.org.uk>,
        "Florian Lohoff" <flo@rfc822.org>, <linux-mips@oss.sgi.com>,
        <ralf@oss.sgi.com>
References: <Pine.GSO.3.96.1010208115525.29177E-100000@delta.ds2.pg.gda.pl>
Subject: Re: NON FPU cpus - way to go
Date:   Thu, 8 Feb 2001 12:38:23 +0100
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing

> On Thu, 8 Feb 2001, Kevin D. Kissell wrote:
>
> > Do you have some numbers to support this?  A proper library
> > implementation does *not* trap to the kernel on each FPU
> > instruction, and as such is considerably faster (and considerably
> > larger - a factor for embedded apps!) than a kernel emulation.
>
>  Now you are writing of a compiler emulation and not a library one.

Well, in fact it ends up being both.  The compiler substitutes library
invocations for FP instructions, one-for-one.

> While
> such a solution is reasonable for firmware or other OS-less or even
> libc-less environment, its much too painful for normal use.  Either you
> lose for real FPU environments due to extra overhead to invoke FPU
> operations or you have two sets of incompatible binaries (one that invokes
> FPU diractly and the other one with emulator hooks).

Which was my whole point about it not being a good idea.

The notion of using libc emulation based on catching SIGFP,
on the other hand, is so silly that I didn't even understand that
that's what you were referring to!  It would be an amazing pig,
and there are corner cases, such as the emulation of the
instructions in the delay slot of branch-on-floating-condition,
that would be damned difficult to handle that way.

> > >  You never want to configure glibc with the --without-fp option.
> >
> > That's certainly what we had to do for OpenBSD without FP
> > emulation!  What is the alternative?
>
>  Write one. ;-)

I don't understand, the alternative to building a --without-fp
glibc (which Carsten and I did for OpenBSD once already)
is to write *what*?

            Regards,

            Kevin K.



From owner-linux-mips@oss.sgi.com Thu Feb  8 03:40:32 2001
Received:  by oss.sgi.com id <S553793AbRBHLkX>;
	Thu, 8 Feb 2001 03:40:23 -0800
Received: from mx.mips.com ([206.31.31.226]:21966 "EHLO mx.mips.com")
	by oss.sgi.com with ESMTP id <S553784AbRBHLkI>;
	Thu, 8 Feb 2001 03:40:08 -0800
Received: from newman.mips.com (ns-dmz [206.31.31.225])
	by mx.mips.com (8.9.3/8.9.0) with ESMTP id DAA11407;
	Thu, 8 Feb 2001 03:40:07 -0800 (PST)
Received: from Ulysses (ulysses [192.168.236.13])
	by newman.mips.com (8.9.3/8.9.0) with SMTP id DAA23325;
	Thu, 8 Feb 2001 03:40:05 -0800 (PST)
Message-ID: <005d01c091c4$69940620$0deca8c0@Ulysses>
From:   "Kevin D. Kissell" <kevink@mips.com>
To:     "Florian Lohoff" <flo@rfc822.org>, <linux-mips@oss.sgi.com>
References: <20010208122030.A5408@paradigm.rfc822.org>
Subject: Re: [RESUME] fpu emulator
Date:   Thu, 8 Feb 2001 12:43:30 +0100
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing

> Hi,
> just to get it right - As i thought the FPU emulator is not really
> optional - It is even required for fpu-enabled devices which means
> we should clean the code in that way that if the user decides to 
> compile in the fpu emulator into the kernel we do an autodetection 
> upfront and change some of the entry/exit/lazy_fpu stuff.
> If the user decides not to compile in the FPU Emulator he is on his
> own and we ignore the whole FPU stuff and simply send SIGILL/SIGFPE
> to the processes causing all fpu binarys to fail on non-fpu enabled
> kernels.

Not quite.  Unless we create a variant of glibc that neither
initializes the FP control register on program startup, nor
saves/restores the FP registers in setjmp/longjmp, the
model of "simply sending SIGILL/SIGFPE" will result
in *all* processes being terminated with extreme prejudice,
starting with init!

            Regards,

            Kevin K.


From owner-linux-mips@oss.sgi.com Thu Feb  8 04:07:13 2001
Received:  by oss.sgi.com id <S553794AbRBHMHD>;
	Thu, 8 Feb 2001 04:07:03 -0800
Received: from Cantor.suse.de ([213.95.15.193]:56850 "HELO Cantor.suse.de")
	by oss.sgi.com with SMTP id <S553784AbRBHMGk>;
	Thu, 8 Feb 2001 04:06:40 -0800
Received: from Hermes.suse.de (Hermes.suse.de [213.95.15.136])
	by Cantor.suse.de (Postfix) with ESMTP
	id 13E811E0CD; Thu,  8 Feb 2001 13:06:38 +0100 (MET)
X-Authentication-Warning: gee.suse.de: aj set sender to aj@suse.de using -f
Mail-Copies-To: never
To:     "Kevin D. Kissell" <kevink@mips.com>
Cc:     "Florian Lohoff" <flo@rfc822.org>, <linux-mips@oss.sgi.com>
Subject: Re: [RESUME] fpu emulator
References: <20010208122030.A5408@paradigm.rfc822.org>
	<005d01c091c4$69940620$0deca8c0@Ulysses>
From:   Andreas Jaeger <aj@suse.de>
Date:   08 Feb 2001 13:06:29 +0100
In-Reply-To: <005d01c091c4$69940620$0deca8c0@Ulysses> ("Kevin D. Kissell"'s message of "Thu, 8 Feb 2001 12:43:30 +0100")
Message-ID: <hor919tm4a.fsf@gee.suse.de>
Lines:  33
User-Agent: Gnus/5.090001 (Oort Gnus v0.01) XEmacs/21.1 (Channel Islands)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing

"Kevin D. Kissell" <kevink@mips.com> writes:

> > Hi,
> > just to get it right - As i thought the FPU emulator is not really
> > optional - It is even required for fpu-enabled devices which means
> > we should clean the code in that way that if the user decides to 
> > compile in the fpu emulator into the kernel we do an autodetection 
> > upfront and change some of the entry/exit/lazy_fpu stuff.
> > If the user decides not to compile in the FPU Emulator he is on his
> > own and we ignore the whole FPU stuff and simply send SIGILL/SIGFPE
> > to the processes causing all fpu binarys to fail on non-fpu enabled
> > kernels.
> 
> Not quite.  Unless we create a variant of glibc that neither
> initializes the FP control register on program startup, nor

glibc doesn't initialize it for shared programs.

> saves/restores the FP registers in setjmp/longjmp, the

Any ideas how this can be done?

> model of "simply sending SIGILL/SIGFPE" will result
> in *all* processes being terminated with extreme prejudice,
> starting with init!


Andreas
-- 
 Andreas Jaeger
  SuSE Labs aj@suse.de
   private aj@arthur.inka.de
    http://www.suse.de/~aj

From owner-linux-mips@oss.sgi.com Thu Feb  8 04:08:13 2001
Received:  by oss.sgi.com id <S553795AbRBHMID>;
	Thu, 8 Feb 2001 04:08:03 -0800
Received: from delta.ds2.pg.gda.pl ([153.19.144.1]:9630 "EHLO
        delta.ds2.pg.gda.pl") by oss.sgi.com with ESMTP id <S553800AbRBHMHz>;
	Thu, 8 Feb 2001 04:07:55 -0800
Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id NAA02875;
	Thu, 8 Feb 2001 13:05:12 +0100 (MET)
Date:   Thu, 8 Feb 2001 13:05:12 +0100 (MET)
From:   "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To:     "Kevin D. Kissell" <kevink@mips.com>
cc:     Jun Sun <jsun@mvista.com>, Alan Cox <alan@lxorguk.ukuu.org.uk>,
        Florian Lohoff <flo@rfc822.org>, linux-mips@oss.sgi.com,
        ralf@oss.sgi.com
Subject: Re: NON FPU cpus - way to go
In-Reply-To: <005901c091c3$ab3c9b60$0deca8c0@Ulysses>
Message-ID: <Pine.GSO.3.96.1010208125342.29177I-100000@delta.ds2.pg.gda.pl>
Organization: Technical University of Gdansk
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing

On Thu, 8 Feb 2001, Kevin D. Kissell wrote:

> Well, in fact it ends up being both.  The compiler substitutes library
> invocations for FP instructions, one-for-one.

 That's a compiler emulator.  You need to generate special code and place
handlers in libgcc just like it's already being done for integer
operations not supported by a CPU.  I suppose all necessary glue code is
already present in gcc.

> The notion of using libc emulation based on catching SIGFP,
> on the other hand, is so silly that I didn't even understand that
> that's what you were referring to!  It would be an amazing pig,
> and there are corner cases, such as the emulation of the
> instructions in the delay slot of branch-on-floating-condition,
> that would be damned difficult to handle that way.

 How much more difficult than in the kernel?  The kernel needs to take
care of these case as well.  Do you mean we miss certain information that
is available for the kernel in the epc register?  Well, we may always make
the kernel pass it back, if needed. 

 I'm not particularly amazed by the idea, but it's certainly doable.

> > > >  You never want to configure glibc with the --without-fp option.
> > >
> > > That's certainly what we had to do for OpenBSD without FP
> > > emulation!  What is the alternative?
> >
> >  Write one. ;-)
> 
> I don't understand, the alternative to building a --without-fp
> glibc (which Carsten and I did for OpenBSD once already)
> is to write *what*?

 An FP emulator for OpenBSD.  Not that I care much...

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +


From owner-linux-mips@oss.sgi.com Thu Feb  8 04:34:13 2001
Received:  by oss.sgi.com id <S553804AbRBHMeD>;
	Thu, 8 Feb 2001 04:34:03 -0800
Received: from noose.gt.owl.de ([62.52.19.4]:31763 "HELO noose.gt.owl.de")
	by oss.sgi.com with SMTP id <S553800AbRBHMdo>;
	Thu, 8 Feb 2001 04:33:44 -0800
Received: by noose.gt.owl.de (Postfix, from userid 10)
	id 63ED57DD; Thu,  8 Feb 2001 13:33:33 +0100 (CET)
Received: by paradigm.rfc822.org (Postfix, from userid 1000)
	id 58601EEAC; Thu,  8 Feb 2001 13:33:39 +0100 (CET)
Date:   Thu, 8 Feb 2001 13:33:39 +0100
From:   Florian Lohoff <flo@rfc822.org>
To:     "Kevin D. Kissell" <kevink@mips.com>
Cc:     linux-mips@oss.sgi.com
Subject: Re: [RESUME] fpu emulator
Message-ID: <20010208133339.B6229@paradigm.rfc822.org>
References: <20010208122030.A5408@paradigm.rfc822.org> <005d01c091c4$69940620$0deca8c0@Ulysses>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <005d01c091c4$69940620$0deca8c0@Ulysses>; from kevink@mips.com on Thu, Feb 08, 2001 at 12:43:30PM +0100
Organization: rfc822 - pure communication
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing

On Thu, Feb 08, 2001 at 12:43:30PM +0100, Kevin D. Kissell wrote:
> > Hi,
> > just to get it right - As i thought the FPU emulator is not really
> > optional - It is even required for fpu-enabled devices which means
> > we should clean the code in that way that if the user decides to 
> > compile in the fpu emulator into the kernel we do an autodetection 
> > upfront and change some of the entry/exit/lazy_fpu stuff.
> > If the user decides not to compile in the FPU Emulator he is on his
> > own and we ignore the whole FPU stuff and simply send SIGILL/SIGFPE
> > to the processes causing all fpu binarys to fail on non-fpu enabled
> > kernels.
> 
> Not quite.  Unless we create a variant of glibc that neither
> initializes the FP control register on program startup, nor
> saves/restores the FP registers in setjmp/longjmp, the
> model of "simply sending SIGILL/SIGFPE" will result
> in *all* processes being terminated with extreme prejudice,
> starting with init!

Which is exactly i was trying to establish as when the fpu emulator
is not enabled the user should build a complete fp less userspace. And
when we edstablish the SIGILL/SIGFPE he is forced to do so which is
a "good thing(tm)"

Flo
-- 
Florian Lohoff                  flo@rfc822.org             +49-5201-669912
     Why is it called "common sense" when nobody seems to have any?


From owner-linux-mips@oss.sgi.com Thu Feb  8 04:55:33 2001
Received:  by oss.sgi.com id <S553818AbRBHMzX>;
	Thu, 8 Feb 2001 04:55:23 -0800
Received: from delta.ds2.pg.gda.pl ([153.19.144.1]:49054 "EHLO
        delta.ds2.pg.gda.pl") by oss.sgi.com with ESMTP id <S553809AbRBHMzN>;
	Thu, 8 Feb 2001 04:55:13 -0800
Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id NAA03970;
	Thu, 8 Feb 2001 13:34:38 +0100 (MET)
Date:   Thu, 8 Feb 2001 13:34:36 +0100 (MET)
From:   "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To:     Harald Koerfgen <Harald.Koerfgen@home.ivm.de>, linux-mips@fnet.fr,
        linux-mips@oss.sgi.com
Subject: An IRQ handler fix for arch/mips/dec/irq.c
Message-ID: <Pine.GSO.3.96.1010208131342.29177J-100000@delta.ds2.pg.gda.pl>
Organization: Technical University of Gdansk
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing

Hi,

 The epilogue for the DECstation's IRQ handler is buggy -- it permits
infinite interrupt recursion which may lead to a stack overflow.  I wasn't
able to check if that's the reason of random crashes I get when I run
strace at the console, yet, but it might be -- the load might be up to 10k
interrupts per second if data is available in time.

 Please apply.

  Maciej

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

patch-mips-2.4.0-do_irq-0
diff -up --recursive --new-file linux-mips-2.4.0-20010126.macro/arch/mips/dec/irq.c linux-mips-2.4.0-20010126/arch/mips/dec/irq.c
--- linux-mips-2.4.0-20010126.macro/arch/mips/dec/irq.c	Sun Dec  3 05:26:46 2000
+++ linux-mips-2.4.0-20010126/arch/mips/dec/irq.c	Thu Feb  8 07:44:10 2001
@@ -136,8 +136,8 @@ asmlinkage void do_IRQ(int irq, struct p
 	} while (action);
 	if (do_random & SA_SAMPLE_RANDOM)
 	    add_interrupt_randomness(irq);
-	unmask_irq(irq);
 	__cli();
+	unmask_irq(irq);
     }
     irq_exit(cpu, irq);
 


From owner-linux-mips@oss.sgi.com Thu Feb  8 12:29:58 2001
Received:  by oss.sgi.com id <S553646AbRBHU3i>;
	Thu, 8 Feb 2001 12:29:38 -0800
Received: from gateway-1237.mvista.com ([12.44.186.158]:14331 "EHLO
        hermes.mvista.com") by oss.sgi.com with ESMTP id <S553651AbRBHU3L>;
	Thu, 8 Feb 2001 12:29:11 -0800
Received: from mvista.com (IDENT:jsun@orion.mvista.com [10.0.0.75])
	by hermes.mvista.com (8.11.0/8.11.0) with ESMTP id f18KPR829704;
	Thu, 8 Feb 2001 12:25:27 -0800
Message-ID: <3A830135.B1304041@mvista.com>
Date:   Thu, 08 Feb 2001 12:27:33 -0800
From:   Jun Sun <jsun@mvista.com>
X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.18 i686)
X-Accept-Language: en
MIME-Version: 1.0
To:     linux-mips@oss.sgi.com
Subject: config option vs. run-time detection (the debate continues ...)
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing


I love this topic!

Instead of replying to 10 different emails, I decide to sort out my best
understanding of this topic and list them here, including some of MY responses
to some of the issues.

Definition:
------------

1. Config option approach :

	In the kernel config menu, one picks one or more CPUs.  One also specifies
whether the CPU(s) have a FPU.

	All FPU related code in kernel is configured in or out based on the CONFIG
setting.

2. run-time detection approach:

	CPU probing code probes CPU and sets has_fpu field in the mips_cpu structure.

	All FPU related code is on a conditional branch based on has_fpu value.


Run-time Detection Approach
---------------------------

Plus:
	. the same kernel image can run on CPUs either with or without a FPU.

Minus:
	. run-time overhead
		a) cpu detection
		b) conditional checking for FPU related code
	. extra code size (FPU detection and conditional branch for FPU related code)
	. do we have a reliable detection method without any help from CONFIG (I am
not 100% sure here)


Config Option Approach
----------------------

Plus:
	. The reverse of the minus for run-time detection approach

Minus:
	. The same kernel image cannot run on CPUs both with and without a FPU.


My Conclusion
--------------

Clearly, it is a trade-off decision based how much one values the minuses and
pluses of both approaches.

While I do agree the minus for run-time detection are not serious ones, I
think the minus for config option is even less serious.  Having the same
kernel image runs on multiple CPUs is very nice.  I just doubt about the
usefulness of requiring the same kernel image to run on CPUs both with a FPU
and without a FPU.  Therefore in the light of minus of the run-time detection
approach, I still favor config option.

(aha, I proved my intuition. It is a theory now. :-0)

Jun

From owner-linux-mips@oss.sgi.com Thu Feb  8 12:44:57 2001
Received:  by oss.sgi.com id <S553661AbRBHUos>;
	Thu, 8 Feb 2001 12:44:48 -0800
Received: from gateway-1237.mvista.com ([12.44.186.158]:53501 "EHLO
        hermes.mvista.com") by oss.sgi.com with ESMTP id <S553651AbRBHUoX>;
	Thu, 8 Feb 2001 12:44:23 -0800
Received: from mvista.com (IDENT:jsun@orion.mvista.com [10.0.0.75])
	by hermes.mvista.com (8.11.0/8.11.0) with ESMTP id f18KeZ830959;
	Thu, 8 Feb 2001 12:40:35 -0800
Message-ID: <3A8304C0.D3CFFEF7@mvista.com>
Date:   Thu, 08 Feb 2001 12:42:40 -0800
From:   Jun Sun <jsun@mvista.com>
X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.18 i686)
X-Accept-Language: en
MIME-Version: 1.0
To:     Andreas Jaeger <aj@suse.de>
CC:     "Kevin D. Kissell" <kevink@mips.com>,
        Florian Lohoff <flo@rfc822.org>, linux-mips@oss.sgi.com
Subject: Re: [RESUME] fpu emulator
References: <20010208122030.A5408@paradigm.rfc822.org>
		<005d01c091c4$69940620$0deca8c0@Ulysses> <hor919tm4a.fsf@gee.suse.de>
Content-Type: multipart/mixed;
 boundary="------------E064D9D48094491B5D63083D"
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing

This is a multi-part message in MIME format.
--------------E064D9D48094491B5D63083D
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Andreas Jaeger wrote:
> 
 
> > saves/restores the FP registers in setjmp/longjmp, the
> 
> Any ideas how this can be done?
> 
> > model of "simply sending SIGILL/SIGFPE" will result
> > in *all* processes being terminated with extreme prejudice,
> > starting with init!
> 

There is a patch for glibc2.0.7, which I think was done by Jay Carlson.  It
basically works for glibc2.0.6 as well.  See the one for glibc2.0.6 attached
below.

I think the patch is not "clean", in the sense that you only want to apply it
if you want to configure with "--without-fp".  Otherwise the patch will break
other configurations.

Jun
--------------E064D9D48094491B5D63083D
Content-Type: text/plain; charset=us-ascii;
 name="glibc-2.0.6-mips-softfloat.patch"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="glibc-2.0.6-mips-softfloat.patch"

--- glibc-2.0.6/sysdeps/mips/__longjmp.c.orig-rpm	Sat Sep 11 00:01:44 1999
+++ glibc-2.0.6/sysdeps/mips/__longjmp.c	Sat Sep 11 00:02:36 1999
@@ -35,6 +35,7 @@
      along the way.  */
   register int val asm ("a1");
 
+#ifdef __HAVE_FPU__
   /* Pull back the floating point callee-saved registers.  */
   asm volatile ("l.d $f20, %0" : : "m" (env[0].__fpregs[0]));
   asm volatile ("l.d $f22, %0" : : "m" (env[0].__fpregs[1]));
@@ -42,13 +43,16 @@
   asm volatile ("l.d $f26, %0" : : "m" (env[0].__fpregs[3]));
   asm volatile ("l.d $f28, %0" : : "m" (env[0].__fpregs[4]));
   asm volatile ("l.d $f30, %0" : : "m" (env[0].__fpregs[5]));
+#endif
   
   /* Restore the stack pointer.  */
   asm volatile ("lw $29, %0" : : "m" (env[0].__sp));
 
+#ifdef __HAVE_FPU__
   /* Get and reconstruct the floating point csr.  */
   asm volatile ("lw $2, %0" : : "m" (env[0].__fpc_csr));
   asm volatile ("ctc1 $2, $31");
+#endif
 
   /* Get the FP.  */
   asm volatile ("lw $30, %0" : : "m" (env[0].__fp));
--- glibc-2.0.6/sysdeps/mips/setjmp_aux.c.orig-rpm	Sat Sep 11 00:04:00 1999
+++ glibc-2.0.6/sysdeps/mips/setjmp_aux.c	Sat Sep 11 00:04:24 1999
@@ -26,6 +26,7 @@
 int
 __sigsetjmp_aux (jmp_buf env, int savemask, int sp, int fp)
 {
+#ifdef __HAVE_FPU__
   /* Store the floating point callee-saved registers...  */
   asm volatile ("s.d $f20, %0" : : "m" (env[0].__jmpbuf[0].__fpregs[0]));
   asm volatile ("s.d $f22, %0" : : "m" (env[0].__jmpbuf[0].__fpregs[1]));
@@ -33,6 +34,7 @@
   asm volatile ("s.d $f26, %0" : : "m" (env[0].__jmpbuf[0].__fpregs[3]));
   asm volatile ("s.d $f28, %0" : : "m" (env[0].__jmpbuf[0].__fpregs[4]));
   asm volatile ("s.d $f30, %0" : : "m" (env[0].__jmpbuf[0].__fpregs[5]));
+#endif
 
   /* .. and the PC;  */
   asm volatile ("sw $31, %0" : : "m" (env[0].__jmpbuf[0].__pc));
@@ -56,8 +58,10 @@
   asm volatile ("sw $22, %0" : : "m" (env[0].__jmpbuf[0].__regs[6]));
   asm volatile ("sw $23, %0" : : "m" (env[0].__jmpbuf[0].__regs[7]));
 
+#ifdef __HAVE_FPU__
   /* .. and finally get and reconstruct the floating point csr.  */
   asm ("cfc1 %0, $31" : "=r" (env[0].__jmpbuf[0].__fpc_csr));
+#endif
 
   /* Save the signal mask if requested.  */
   return __sigjmp_save (env, savemask);
--- glibc-2.0.6/sysdeps/mips/fpu_control.h.orig-rpm	Sat Sep 11 00:18:51 1999
+++ glibc-2.0.6/sysdeps/mips/fpu_control.h	Sat Sep 11 00:10:44 1999
@@ -83,8 +83,13 @@
 typedef unsigned int fpu_control_t __attribute__ ((__mode__ (__HI__)));
 
 /* Macros for accessing the hardware control word.  */
+#ifdef __HAVE_FPU__
 #define _FPU_GETCW(cw) __asm__ ("cfc1 %0,$31" : "=r" (cw) : )
 #define _FPU_SETCW(cw) __asm__ ("ctc1 %0,$31" : : "r" (cw))
+#else
+#define _FPU_GETCW(cw) (_FPU_DEFAULT)
+#define _FPU_SETCW(cw) 
+#endif
 
 /* Default control word set at startup.  */
 extern fpu_control_t __fpu_control;

--------------E064D9D48094491B5D63083D--


From owner-linux-mips@oss.sgi.com Thu Feb  8 14:03:48 2001
Received:  by oss.sgi.com id <S553668AbRBHWD2>;
	Thu, 8 Feb 2001 14:03:28 -0800
Received: from mx.mips.com ([206.31.31.226]:41687 "EHLO mx.mips.com")
	by oss.sgi.com with ESMTP id <S553663AbRBHWDD>;
	Thu, 8 Feb 2001 14:03:03 -0800
Received: from newman.mips.com (ns-dmz [206.31.31.225])
	by mx.mips.com (8.9.3/8.9.0) with ESMTP id OAA17088;
	Thu, 8 Feb 2001 14:03:02 -0800 (PST)
Received: from Ulysses (ulysses [192.168.236.13])
	by newman.mips.com (8.9.3/8.9.0) with SMTP id OAA09176;
	Thu, 8 Feb 2001 14:02:58 -0800 (PST)
Message-ID: <01bf01c0921b$6de26620$0deca8c0@Ulysses>
From:   "Kevin D. Kissell" <kevink@mips.com>
To:     "Jun Sun" <jsun@mvista.com>, <linux-mips@oss.sgi.com>
References: <3A830135.B1304041@mvista.com>
Subject: Re: config option vs. run-time detection (the debate continues ...)
Date:   Thu, 8 Feb 2001 23:06:33 +0100
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing

> I love this topic!

Well, I'm glad *you're* having fun!  ;-)

> Instead of replying to 10 different emails, I decide to sort out my best
> understanding of this topic and list them here, including some of MY
responses
> to some of the issues.
>
> Definition:
> ------------
>
> 1. Config option approach :
>
> In the kernel config menu, one picks one or more CPUs.  One also specifies
> whether the CPU(s) have a FPU.
>
> All FPU related code in kernel is configured in or out based on the CONFIG
> setting.

As has been noted in other messages in this exchange, whether one
has an FPU or not isn't really the determining factor in including FP
support code in the kernel.  The bulk of it is the emulator, and the
emulator needs to be there if you want to execute binaries built
to include MIPS FP instructions, whether in full emulation or using
the FPU (for the denormal cases, etc.).

So your CONFIG option would really be to say, regardless of
the CPU, whether your kernel can handle an FPU-ful userland,
or is stripped down to support only 100% integer binaries.

> 2. run-time detection approach:
>
> CPU probing code probes CPU and sets has_fpu field in the mips_cpu
structure.
>
> All FPU related code is on a conditional branch based on has_fpu value.

Again, the FPU-related code has to be there any time you're
going to run FP binaries.  The MIPS_CPU_FPU bit simply
tells the kernel how/when to use it.

...

> My Conclusion
> --------------
>
> Clearly, it is a trade-off decision based how much one values the minuses
and
> pluses of both approaches.
>
> While I do agree the minus for run-time detection are not serious ones, I
> think the minus for config option is even less serious.  Having the same
> kernel image runs on multiple CPUs is very nice.  I just doubt about the
> usefulness of requiring the same kernel image to run on CPUs both with a
FPU
> and without a FPU.

If you're building kernels for a workstation, that may be
true.  If you're building kernels for a testbed where you're
swapping CPU modules, it's actually rather nice to have
a single kernel that boots on any of them.  I personally
find myself in this situation.  Or to provide a less lab-oriented
example, NEC has the R43xx family which have FPUs,
and Toshiba markets some R49xx parts that are pin-compatible
but cheaper - because they have no FPU.   If I were building
a Linux-based system around either one, memory permitting,
I would want to  have a kernel that could cope with either of
them, to simplify the product management problem if I ever
ended up wanting to cut over from one to the other.

            Kevin K.


From owner-linux-mips@oss.sgi.com Thu Feb  8 15:00:00 2001
Received:  by oss.sgi.com id <S553686AbRBHW7u>;
	Thu, 8 Feb 2001 14:59:50 -0800
Received: from gateway-1237.mvista.com ([12.44.186.158]:7927 "EHLO
        hermes.mvista.com") by oss.sgi.com with ESMTP id <S553673AbRBHW7j>;
	Thu, 8 Feb 2001 14:59:39 -0800
Received: from mvista.com (IDENT:jsun@orion.mvista.com [10.0.0.75])
	by hermes.mvista.com (8.11.0/8.11.0) with ESMTP id f18Mu0806647;
	Thu, 8 Feb 2001 14:56:00 -0800
Message-ID: <3A83247D.FC52431D@mvista.com>
Date:   Thu, 08 Feb 2001 14:58:05 -0800
From:   Jun Sun <jsun@mvista.com>
X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.18 i686)
X-Accept-Language: en
MIME-Version: 1.0
To:     "Kevin D. Kissell" <kevink@mips.com>
CC:     linux-mips@oss.sgi.com
Subject: Re: config option vs. run-time detection (the debate continues ...)
References: <3A830135.B1304041@mvista.com> <01bf01c0921b$6de26620$0deca8c0@Ulysses>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing

"Kevin D. Kissell" wrote:
> 
> > I love this topic!
> 
> Well, I'm glad *you're* having fun!  ;-)
> 
> > Instead of replying to 10 different emails, I decide to sort out my best
> > understanding of this topic and list them here, including some of MY
> responses
> > to some of the issues.
> >
> > Definition:
> > ------------
> >
> > 1. Config option approach :
> >
> > In the kernel config menu, one picks one or more CPUs.  One also specifies
> > whether the CPU(s) have a FPU.
> >
> > All FPU related code in kernel is configured in or out based on the CONFIG
> > setting.
> 
> As has been noted in other messages in this exchange, whether one
> has an FPU or not isn't really the determining factor in including FP
> support code in the kernel.  The bulk of it is the emulator, and the
> emulator needs to be there if you want to execute binaries built
> to include MIPS FP instructions, whether in full emulation or using
> the FPU (for the denormal cases, etc.).
>

That needs a little more explanation.

. When I say "All FPU related code", I really meant FPU code which is not a
part of FPU emaulator.  One example is the code in exit_thread()
(arch/mips/process.c) as brough up by flo.  I believe there are also such code
in ptrace.c.

. Regarding whether we should have FPU emulator, I think it should be a
separate CONFIG option.  It is orthorgal to HAS_FPU option.

In other words, we will have four combinations:

 a) HAS_FPU & FPU_EMULATION - which is necessary when FPU is not a full
implementation.

 b) !HAS_FPU & FPU_EMULATION - which allows one to run fpu-ful userland
application

 c) HAS_FPU & !FPU_EMULATION - when FPU is a full implementaion (or use the
old incomplete emaulation?)

 d) !HAS_FPU & !FPU_EMULATION - it mandates non-fpu-ful userland (which to me
is perfectly fine)

I start to feel a little "shaky" here as I have not written any FPU code. 
Will such a classification make life easier or worse?  Is there any
feasibility issue here?


> 
> If you're building kernels for a workstation, that may be
> true.  If you're building kernels for a testbed where you're
> swapping CPU modules, it's actually rather nice to have
> a single kernel that boots on any of them.  I personally
> find myself in this situation.  Or to provide a less lab-oriented
> example, NEC has the R43xx family which have FPUs,
> and Toshiba markets some R49xx parts that are pin-compatible
> but cheaper - because they have no FPU.   If I were building
> a Linux-based system around either one, memory permitting,
> I would want to  have a kernel that could cope with either of
> them, to simplify the product management problem if I ever
> ended up wanting to cut over from one to the other.
> 

I think this example shifted my bias a little bit, although it has changed it
yet.

Are we confident we can do a clean run-time detection of all existing CPUs?

Jun

From owner-linux-mips@oss.sgi.com Thu Feb  8 15:05:30 2001
Received:  by oss.sgi.com id <S553698AbRBHXFU>;
	Thu, 8 Feb 2001 15:05:20 -0800
Received: from [62.145.23.107] ([62.145.23.107]:29547 "HELO
        fileserv2.Cologne.DE") by oss.sgi.com with SMTP id <S553683AbRBHXFD>;
	Thu, 8 Feb 2001 15:05:03 -0800
Received: from localhost (1513 bytes) by fileserv2.Cologne.DE
	via rmail with P:stdio/R:bind/T:smtp
	(sender: <excalibur.cologne.de!karsten>) (ident <excalibur.cologne.de!karsten> using unix)
	id <m14R07Z-0007GzC@fileserv2.Cologne.DE>
	for <linux-mips@oss.sgi.com>; Fri, 9 Feb 2001 00:05:01 +0100 (CET)
	(Smail-3.2.0.101 1997-Dec-17 #5 built 1998-Jan-19)
Received: (from karsten@localhost)
	by excalibur.cologne.de (8.9.3/8.8.7) id AAA17674
	for linux-mips@oss.sgi.com; Fri, 9 Feb 2001 00:04:19 +0100
Date:   Fri, 9 Feb 2001 00:04:19 +0100
From:   Karsten Merker <karsten@excalibur.cologne.de>
To:     linux-mips@oss.sgi.com
Subject: DECstation crashes
Message-ID: <20010209000419.A17609@excalibur.cologne.de>
Mail-Followup-To: linux-mips@oss.sgi.com
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0.1i
X-No-Archive: yes
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing

Hallo everyone,

I have been experimenting a bit to find out which changes cause the
kernel crashes on DECstations we experience in the last days. A checkout
from 2001-01-30 00:00 works fine, a checkout from 2001-02-02 00:00
crashes. Between these two dates is the large patch merging in the
changes from 2.4.0 -> 2.4.1, so it looks like the bug is somewhere in
there. Any ideas?

Do other Linux/MIPS-targets besides the DECstations show similar problems
(kernel crash due to NULL-pointer dereference in __free_pages_ok just
after mounting the rootfs) or is this a decstation-specific effect? The
problems happens both on R3k and R4k (tested on 5000/20 and 5000/150).

Greetings,
Karsten
-- 
#include <standard_disclaimer>
Nach Paragraph 28 Abs. 3 Bundesdatenschutzgesetz widerspreche ich der Nutzung
oder Uebermittlung meiner Daten fuer Werbezwecke oder fuer die Markt- oder
Meinungsforschung.

From owner-linux-mips@oss.sgi.com Thu Feb  8 16:22:10 2001
Received:  by oss.sgi.com id <S553729AbRBIAWA>;
	Thu, 8 Feb 2001 16:22:00 -0800
Received: from mx.mips.com ([206.31.31.226]:62425 "EHLO mx.mips.com")
	by oss.sgi.com with ESMTP id <S553724AbRBIAVh>;
	Thu, 8 Feb 2001 16:21:37 -0800
Received: from newman.mips.com (ns-dmz [206.31.31.225])
	by mx.mips.com (8.9.3/8.9.0) with ESMTP id QAA18964;
	Thu, 8 Feb 2001 16:21:35 -0800 (PST)
Received: from Ulysses (ulysses [192.168.236.13])
	by newman.mips.com (8.9.3/8.9.0) with SMTP id QAA14390;
	Thu, 8 Feb 2001 16:21:33 -0800 (PST)
Message-ID: <021b01c0922e$c8df4440$0deca8c0@Ulysses>
From:   "Kevin D. Kissell" <kevink@mips.com>
To:     "Jun Sun" <jsun@mvista.com>
Cc:     <linux-mips@oss.sgi.com>
References: <3A830135.B1304041@mvista.com> <01bf01c0921b$6de26620$0deca8c0@Ulysses> <3A83247D.FC52431D@mvista.com>
Subject: Re: config option vs. run-time detection (the debate continues ...)
Date:   Fri, 9 Feb 2001 01:25:10 +0100
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing

> > > 1. Config option approach :
> > >
> > > In the kernel config menu, one picks one or more CPUs.  One also
specifies
> > > whether the CPU(s) have a FPU.
> > >
> > > All FPU related code in kernel is configured in or out based on the
CONFIG
> > > setting.
> >
> > As has been noted in other messages in this exchange, whether one
> > has an FPU or not isn't really the determining factor in including FP
> > support code in the kernel.  The bulk of it is the emulator, and the
> > emulator needs to be there if you want to execute binaries built
> > to include MIPS FP instructions, whether in full emulation or using
> > the FPU (for the denormal cases, etc.).
> >
> That needs a little more explanation.
>
> . When I say "All FPU related code", I really meant FPU code which is not
a
> part of FPU emaulator.  One example is the code in exit_thread()
> (arch/mips/process.c) as brough up by flo.  I believe there are also such
code
> in ptrace.c.

Understood.  My point is that that code can be lumped with
the emulator as the set of support needed to run FPU-full
binaries.  Even with an emulator, one needs to manage
and communicate FP state.  The only difference is that
the "floating point registers" are in the thread structure,
not in the CPU.

> . Regarding whether we should have FPU emulator, I think it should be a
> separate CONFIG option.  It is orthorgal to HAS_FPU option.
>
> In other words, we will have four combinations:
>
>  a) HAS_FPU & FPU_EMULATION - which is necessary when FPU is not a full
> implementation.
>
>  b) !HAS_FPU & FPU_EMULATION - which allows one to run fpu-ful userland
> application
>
>  c) HAS_FPU & !FPU_EMULATION - when FPU is a full implementaion (or use
the
> old incomplete emaulation?)

We're talking about MIPS/Linux here.  To the best of my knowledge
there are *no* "full" implementations of IEEE floating point on
a MIPS CPU.  The number of unimplemented cases varies
somewhat from design to design, but I know of no MIPS CPU
where it is a null set.

>  d) !HAS_FPU & !FPU_EMULATION - it mandates non-fpu-ful userland (which to
me
> is perfectly fine)
>
> I start to feel a little "shaky" here as I have not written any FPU code.
> Will such a classification make life easier or worse?  Is there any
> feasibility issue here?

It's not so much that I doubt the feasibility, I just wonder
if there's any point to adding the complexity.  As noted
above, if you're going to support FP-full binaries, you
have to support the processor model of FPU.  The user
will be manipulating what he sees as FP registers, and
all of the state, signal, and context management logic
associated with them has to be there regardless of whether
they exist in the CPU or in the kernel.  It's true that there are
a few paths through the code, the ones that actually load
and store the FP registers, that are distinct.  Those could
certainly be suppressed at compile time if you wanted a
kernel that would never allow a real FPU to be used,
but the memory savings would be smaller than you seem
to think.  It's not "HAS_FPU" versus "EMULATOR",
it's "SUPPORTS_FP" and "HAS_FPU".

But my main objection to treating the two options as
orthogonal is that your (c) case above will simply
create kernels that are guaranteed fail for some
cases of IEEE math.  It's just not good engineering
to give people a 25% chance of building a kernel
that seems to be just fine, at first...

My own recommendation would be to either have
full FP support for binaries or none at all.  If someone
really wants to put the FPU-specific assembler
routines under a different conditional, that's cool, but
the configuration options should be such that the
(c) cannot be generated by the config scripts.


            Regards,

            Kevin K.


From owner-linux-mips@oss.sgi.com Thu Feb  8 16:29:10 2001
Received:  by oss.sgi.com id <S553736AbRBIA2v>;
	Thu, 8 Feb 2001 16:28:51 -0800
Received: from mx.mips.com ([206.31.31.226]:1754 "EHLO mx.mips.com")
	by oss.sgi.com with ESMTP id <S553726AbRBIA2r>;
	Thu, 8 Feb 2001 16:28:47 -0800
Received: from newman.mips.com (ns-dmz [206.31.31.225])
	by mx.mips.com (8.9.3/8.9.0) with ESMTP id QAA19016;
	Thu, 8 Feb 2001 16:28:45 -0800 (PST)
Received: from Ulysses (ulysses [192.168.236.13])
	by newman.mips.com (8.9.3/8.9.0) with SMTP id QAA14563;
	Thu, 8 Feb 2001 16:28:37 -0800 (PST)
Message-ID: <022d01c0922f$c91ccd00$0deca8c0@Ulysses>
From:   "Kevin D. Kissell" <kevink@mips.com>
To:     "Ralf Baechle" <ralf@oss.sgi.com>, "Andreas Jaeger" <aj@suse.de>
Cc:     "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>,
        "Justin Carlson" <carlson@sibyte.com>, <linux-mips@oss.sgi.com>
References: <0101261750492Y.00834@plugh.sibyte.com><Pine.GSO.3.96.1010127084850.29150E-100000@delta.ds2.pg.gda.pl><20010127110106.F867@bacchus.dhis.org> <u8itmz28nk.fsf@gromit.rhein-neckar.de>
Subject: Re: GDB 5 for mips-linux/Shared library loading with new binutils/glibc
Date:   Fri, 9 Feb 2001 01:31:12 +0100
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing

> > The only people who have contributed amounts of code large enough for
the
> > FSF to requires an assignment are David Miller (davem@redhat.com) and
> > myself.  I've already signed an assignment with the FSF and I'm also
sure
> > David has.  I btw. cannot remember having seen any mail from you
regarding
> > copyright assignments of GDB.
>
> David has only disclaimers for Binutils and GCC but not for GDB in the
> FSF list.

I asked MIPS' contacts with Red Hat to look into this, and
there was, apparently, some confusion as to whether GDB
was covered under a blanket assignment.  It's being taken
care of.

            Kevin K.


From owner-linux-mips@oss.sgi.com Thu Feb  8 18:08:01 2001
Received:  by oss.sgi.com id <S553830AbRBICHl>;
	Thu, 8 Feb 2001 18:07:41 -0800
Received: from sgigate.SGI.COM ([204.94.209.1]:6835 "EHLO dea.waldorf-gmbh.de")
	by oss.sgi.com with ESMTP id <S553815AbRBICHZ>;
	Thu, 8 Feb 2001 18:07:25 -0800
Received: (from ralf@localhost)
	by dea.waldorf-gmbh.de (8.11.1/8.11.1) id f1920UO05008;
	Thu, 8 Feb 2001 18:00:30 -0800
Date:   Thu, 8 Feb 2001 18:00:25 -0800
From:   Ralf Baechle <ralf@oss.sgi.com>
To:     "Kevin D. Kissell" <kevink@mips.com>
Cc:     "Andreas Jaeger" <aj@suse.de>,
        "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>,
        "Justin Carlson" <carlson@sibyte.com>, <linux-mips@oss.sgi.com>
Subject: Re: GDB 5 for mips-linux/Shared library loading with new binutils/glibc
Message-ID: <20010208180025.A4031@bacchus.dhis.org>
References: <0101261750492Y.00834@plugh.sibyte.com><Pine.GSO.3.96.1010127084850.29150E-100000@delta.ds2.pg.gda.pl><20010127110106.F867@bacchus.dhis.org> <u8itmz28nk.fsf@gromit.rhein-neckar.de> <022d01c0922f$c91ccd00$0deca8c0@Ulysses>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <022d01c0922f$c91ccd00$0deca8c0@Ulysses>; from kevink@mips.com on Fri, Feb 09, 2001 at 01:31:12AM +0100
X-Accept-Language: de,en,fr
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing

On Fri, Feb 09, 2001 at 01:31:12AM +0100, Kevin D. Kissell wrote:

> > > The only people who have contributed amounts of code large enough for
> > > the FSF to requires an assignment are David Miller (davem@redhat.com)
> > > and myself.  I've already signed an assignment with the FSF and I'm
> > > also sure David has.  I btw. cannot remember having seen any mail from
> > > you regarding copyright assignments of GDB.
> >
> > David has only disclaimers for Binutils and GCC but not for GDB in the
> > FSF list.
> 
> I asked MIPS' contacts with Red Hat to look into this, and
> there was, apparently, some confusion as to whether GDB
> was covered under a blanket assignment.  It's being taken
> care of.

This code was written in '96 during David's time as a SGI intern, so that's
probably not covered.

  Ralf

From owner-linux-mips@oss.sgi.com Fri Feb  9 01:17:53 2001
Received:  by oss.sgi.com id <S553688AbRBIJRe>;
	Fri, 9 Feb 2001 01:17:34 -0800
Received: from ns.suse.de ([213.95.15.193]:23302 "HELO Cantor.suse.de")
	by oss.sgi.com with SMTP id <S553645AbRBIJRL>;
	Fri, 9 Feb 2001 01:17:11 -0800
Received: from Hermes.suse.de (Hermes.suse.de [213.95.15.136])
	by Cantor.suse.de (Postfix) with ESMTP
	id 53C541E212; Fri,  9 Feb 2001 10:17:10 +0100 (MET)
X-Authentication-Warning: gee.suse.de: aj set sender to aj@suse.de using -f
To:     Jun Sun <jsun@mvista.com>
Cc:     "Kevin D. Kissell" <kevink@mips.com>,
        Florian Lohoff <flo@rfc822.org>, linux-mips@oss.sgi.com
Subject: Re: [RESUME] fpu emulator
References: <20010208122030.A5408@paradigm.rfc822.org>
	<005d01c091c4$69940620$0deca8c0@Ulysses> <hor919tm4a.fsf@gee.suse.de>
	<3A8304C0.D3CFFEF7@mvista.com>
From:   Andreas Jaeger <aj@suse.de>
Date:   09 Feb 2001 10:17:05 +0100
In-Reply-To: <3A8304C0.D3CFFEF7@mvista.com> (Jun Sun's message of "Thu, 08 Feb 2001 12:42:40 -0800")
Message-ID: <hoae7wjjvy.fsf@gee.suse.de>
Lines:  42
User-Agent: Gnus/5.090001 (Oort Gnus v0.01) XEmacs/21.1 (Channel Islands)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing

Jun Sun <jsun@mvista.com> writes:

> Andreas Jaeger wrote:
> > 
>  
> > > saves/restores the FP registers in setjmp/longjmp, the
> > 
> > Any ideas how this can be done?
> > 
> > > model of "simply sending SIGILL/SIGFPE" will result
> > > in *all* processes being terminated with extreme prejudice,
> > > starting with init!
> > 
> 
> There is a patch for glibc2.0.7, which I think was done by Jay Carlson.  It
> basically works for glibc2.0.6 as well.  See the one for glibc2.0.6 attached
> below.
> 
> I think the patch is not "clean", in the sense that you only want to apply it
> if you want to configure with "--without-fp".  Otherwise the patch will break
> other configurations.
> 
> Jun--- glibc-2.0.6/sysdeps/mips/__longjmp.c.orig-rpm	Sat Sep 11 00:01:44 1999
> +++ glibc-2.0.6/sysdeps/mips/__longjmp.c	Sat Sep 11 00:02:36 1999
> @@ -35,6 +35,7 @@
>       along the way.  */
>    register int val asm ("a1");
>  
> +#ifdef __HAVE_FPU__

I looked through the whole of glibc and GCC and __HAVE_FPU__ is nowhere
defined for MIPS.  __HAVE_FPU__ is defined for m68k in GCC but that's
the only platform.

Therefore I don't think the patch makes any sense at all,
Andreas

-- 
 Andreas Jaeger
  SuSE Labs aj@suse.de
   private aj@arthur.inka.de
    http://www.suse.de/~aj

From owner-linux-mips@oss.sgi.com Fri Feb  9 03:51:45 2001
Received:  by oss.sgi.com id <S553682AbRBILvg>;
	Fri, 9 Feb 2001 03:51:36 -0800
Received: from delta.ds2.pg.gda.pl ([153.19.144.1]:32681 "EHLO
        delta.ds2.pg.gda.pl") by oss.sgi.com with ESMTP id <S553672AbRBILvS>;
	Fri, 9 Feb 2001 03:51:18 -0800
Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id MAA06272;
	Fri, 9 Feb 2001 12:48:10 +0100 (MET)
Date:   Fri, 9 Feb 2001 12:48:10 +0100 (MET)
From:   "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To:     "Kevin D. Kissell" <kevink@mips.com>
cc:     Jun Sun <jsun@mvista.com>, linux-mips@oss.sgi.com
Subject: Re: config option vs. run-time detection (the debate continues ...)
In-Reply-To: <021b01c0922e$c8df4440$0deca8c0@Ulysses>
Message-ID: <Pine.GSO.3.96.1010209123643.4645B-100000@delta.ds2.pg.gda.pl>
Organization: Technical University of Gdansk
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing

On Fri, 9 Feb 2001, Kevin D. Kissell wrote:

> It's not so much that I doubt the feasibility, I just wonder
> if there's any point to adding the complexity.  As noted
> above, if you're going to support FP-full binaries, you
> have to support the processor model of FPU.  The user
> will be manipulating what he sees as FP registers, and
> all of the state, signal, and context management logic
> associated with them has to be there regardless of whether
> they exist in the CPU or in the kernel.  It's true that there are
> a few paths through the code, the ones that actually load
> and store the FP registers, that are distinct.  Those could
> certainly be suppressed at compile time if you wanted a
> kernel that would never allow a real FPU to be used,
> but the memory savings would be smaller than you seem
> to think.  It's not "HAS_FPU" versus "EMULATOR",
> it's "SUPPORTS_FP" and "HAS_FPU".

 Let me remind the actual problem the discussion started from was whether
we want to hardcode FP hw presence based on a CPU identification or to
check for it explicitly.  I hope we agree the latter is saner.

 But the code that needs to know whether there is a real FPU present is
indeed minimal (as it should be) thus the gain from removing the detection
altogether in favour to a config option is at least questionable if not
insane. 

> My own recommendation would be to either have
> full FP support for binaries or none at all.  If someone
> really wants to put the FPU-specific assembler
> routines under a different conditional, that's cool, but
> the configuration options should be such that the
> (c) cannot be generated by the config scripts.

 I think I may research what the gain from leaving parts of the FPU
emulator apart would be for systems that have FP hw.  It's not a priority
task for me at the moment -- the current configuration works and having
unused code in a running kernel is ugly but non-fatal. 

  Maciej

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +


From owner-linux-mips@oss.sgi.com Fri Feb  9 04:53:35 2001
Received:  by oss.sgi.com id <S553722AbRBIMx0>;
	Fri, 9 Feb 2001 04:53:26 -0800
Received: from mx.mips.com ([206.31.31.226]:61154 "EHLO mx.mips.com")
	by oss.sgi.com with ESMTP id <S553704AbRBIMxK>;
	Fri, 9 Feb 2001 04:53:10 -0800
Received: from newman.mips.com (ns-dmz [206.31.31.225])
	by mx.mips.com (8.9.3/8.9.0) with ESMTP id EAA23444;
	Fri, 9 Feb 2001 04:53:09 -0800 (PST)
Received: from Ulysses (ulysses [192.168.236.13])
	by newman.mips.com (8.9.3/8.9.0) with SMTP id EAA29940;
	Fri, 9 Feb 2001 04:53:05 -0800 (PST)
Message-ID: <009c01c09297$c78b8360$0deca8c0@Ulysses>
From:   "Kevin D. Kissell" <kevink@mips.com>
To:     "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
Cc:     "Jun Sun" <jsun@mvista.com>, <linux-mips@oss.sgi.com>
References: <Pine.GSO.3.96.1010209123643.4645B-100000@delta.ds2.pg.gda.pl>
Subject: Re: config option vs. run-time detection (the debate continues ...)
Date:   Fri, 9 Feb 2001 13:56:44 +0100
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing

> Let me remind the actual problem the discussion started from was whether
> we want to hardcode FP hw presence based on a CPU identification or to
> check for it explicitly.  I hope we agree the latter is saner.

Absolutely.

>  But the code that needs to know whether there is a real FPU present is
> indeed minimal (as it should be) thus the gain from removing the detection
> altogether in favour to a config option is at least questionable if not
> insane.

Well, I might not have put it that strongly, but I quite agree.

> > My own recommendation would be to either have
> > full FP support for binaries or none at all.  If someone
> > really wants to put the FPU-specific assembler
> > routines under a different conditional, that's cool, but
> > the configuration options should be such that the
> > (c) cannot be generated by the config scripts.
>
>  I think I may research what the gain from leaving parts of the FPU
> emulator apart would be for systems that have FP hw.

Surprisingly little.  Basically, you could remove emulation
for moves, loads, and stores.  Any instruction that actually
computes a value can potentially turn out to be unimplemented,
depending on the inputs.  If you *knew* you had an FPU, you
could also make the emulation fractionallly more efficient by
having it operate directly on the FP registers.  When the current
kernels emulate an instruction that failed on a HW FPU,
they copy the HW FPU state into the software FPU
registers, invoke the emulator, and when the emulation
has completed, restore the HW FPU state.  It made for
a clean interface to do things that way, and my
judgement was that the operation was too infrequent
to justify complicating things further.

> It's not a priority
> task for me at the moment -- the current configuration works and having
> unused code in a running kernel is ugly but non-fatal.

"If it ain't broke..."

            Kevin K.


From owner-linux-mips@oss.sgi.com Fri Feb  9 05:08:56 2001
Received:  by oss.sgi.com id <S553752AbRBINIq>;
	Fri, 9 Feb 2001 05:08:46 -0800
Received: from delta.ds2.pg.gda.pl ([153.19.144.1]:23978 "EHLO
        delta.ds2.pg.gda.pl") by oss.sgi.com with ESMTP id <S553712AbRBINIY>;
	Fri, 9 Feb 2001 05:08:24 -0800
Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id OAA08663;
	Fri, 9 Feb 2001 14:06:47 +0100 (MET)
Date:   Fri, 9 Feb 2001 14:06:46 +0100 (MET)
From:   "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To:     "Kevin D. Kissell" <kevink@mips.com>
cc:     Jun Sun <jsun@mvista.com>, linux-mips@oss.sgi.com
Subject: Re: config option vs. run-time detection (the debate continues ...)
In-Reply-To: <009c01c09297$c78b8360$0deca8c0@Ulysses>
Message-ID: <Pine.GSO.3.96.1010209140422.4645G-100000@delta.ds2.pg.gda.pl>
Organization: Technical University of Gdansk
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing

On Fri, 9 Feb 2001, Kevin D. Kissell wrote:

> "If it ain't broke..."

 Well, it's actually one of strengths of Linux we break things from time
to time to make them better. 

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +


From owner-linux-mips@oss.sgi.com Fri Feb  9 07:15:46 2001
Received:  by oss.sgi.com id <S553776AbRBIPPh>;
	Fri, 9 Feb 2001 07:15:37 -0800
Received: from noose.gt.owl.de ([62.52.19.4]:64518 "HELO noose.gt.owl.de")
	by oss.sgi.com with SMTP id <S553650AbRBIPPU>;
	Fri, 9 Feb 2001 07:15:20 -0800
Received: by noose.gt.owl.de (Postfix, from userid 10)
	id C74297D9; Fri,  9 Feb 2001 16:15:08 +0100 (CET)
Received: by paradigm.rfc822.org (Postfix, from userid 1000)
	id 94CF3EEAC; Fri,  9 Feb 2001 16:15:21 +0100 (CET)
Date:   Fri, 9 Feb 2001 16:15:21 +0100
From:   Florian Lohoff <flo@rfc822.org>
To:     linux-mips@oss.sgi.com
Subject: current cvs broken on sgi 
Message-ID: <20010209161521.D13248@paradigm.rfc822.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
Organization: rfc822 - pure communication
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing

Hi,
can someone confirm that the current cvs ONCE AGAIN is broken
on SGIs (Indy/I2) ?

Even with the "early console init" it simply dies ..

Command Monitor.  Type "exit" to return to the menu.
>> bootp():vmlinux-ip22 console=ttyS0 root=/dev/sda2
Setting $netaddr to 195.71.99.220 (from server watchdog)
Obtaining vmlinux-ip22 from server watchdog
1556544+0+152424 entry: 0x880025a8                                              


Flo
-- 
Florian Lohoff                  flo@rfc822.org             +49-5201-669912
     Why is it called "common sense" when nobody seems to have any?


From owner-linux-mips@oss.sgi.com Fri Feb  9 10:35:58 2001
Received:  by oss.sgi.com id <S553844AbRBISfr>;
	Fri, 9 Feb 2001 10:35:47 -0800
Received: from PACIFIC-CARRIER-ANNEX.MIT.EDU ([18.69.0.28]:56330 "HELO MIT.EDU")
	by oss.sgi.com with SMTP id <S553834AbRBISfl>;
	Fri, 9 Feb 2001 10:35:41 -0800
Received: from GRAND-CENTRAL-STATION.MIT.EDU by MIT.EDU with SMTP
	id AA24092; Fri, 9 Feb 01 13:37:35 EST
Received: from melbourne-city-street.MIT.EDU (MELBOURNE-CITY-STREET.MIT.EDU [18.69.0.45])
	by grand-central-station.MIT.EDU (8.9.2/8.9.2) with ESMTP id NAA23282
	for <linux-mips@oss.sgi.com>; Fri, 9 Feb 2001 13:35:24 -0500 (EST)
Received: from ten-thousand-dollar-bill.mit.edu (TEN-THOUSAND-DOLLAR-BILL.MIT.EDU [18.184.0.39])
	by melbourne-city-street.MIT.EDU (8.9.3/8.9.2) with ESMTP id NAA12247
	for <linux-mips@oss.sgi.com>; Fri, 9 Feb 2001 13:35:24 -0500 (EST)
Received: from localhost (kbarr@localhost) by ten-thousand-dollar-bill.mit.edu (8.9.3) with ESMTP
	id NAA09822; Fri, 9 Feb 2001 13:35:24 -0500 (EST)
Date:   Fri, 9 Feb 2001 13:35:24 -0500 (EST)
From:   Kenneth C Barr <kbarr@MIT.EDU>
To:     <linux-mips@oss.sgi.com>
Subject: Re: current cvs broken on sgi 
In-Reply-To: <20010209161521.D13248@paradigm.rfc822.org>
Message-Id: <Pine.GSO.4.30L.0102091239420.209-100000@ten-thousand-dollar-bill.mit.edu>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing

In light of list responses to my netbooting questions, I grabbed the src
on 2/6/01, made tweaks so it would link, built a kernel with serial
console support (and no VT support), ran elf2ecoff, booted with
console=ttyS0, and was able to reach a prompt on my Indy.

Here (I think) are the changes since then...

(grossglockner) ~/zips/crossdev/linux % cvs -d
:pserver:cvs@oss.sgi.com:/cvs history -a -D 2001-02-06 -c
M 02/07 02:43 +0000 ralf 1.3  threads.h  linux/include/linux == <remote>
M 02/08 18:10 +0000 xfs  1.20 todos.html xfs-website         == <remote>
M 02/08 20:52 +0000 xfs  1.21 todos.html xfs-website         == <remote>
M 02/08 20:54 +0000 ralf 1.50 setup.c    linux/arch/mips/kernel == <remote>

BTW, thanks to everyone for their help so far!  Now I'm trying to get a
local user filesystem setup...

Ken




P.S.  My changes:

(grossglockner) ~/zips/crossdev/linux/drivers/sgi/char % cvs -d
:pserver:cvs@oss.sgi.com:/cvs diff
cvs server: Diffing .
Index: sgiserial.c
===================================================================
RCS file: /cvs/linux/drivers/sgi/char/sgiserial.c,v
retrieving revision 1.28
diff -r1.28 sgiserial.c
49c49,53
< extern wait_queue_head_t keypress_wait;
---
> //extern wait_queue_head_t keypress_wait;
> /* changed so that kernel will link. -Nathan <npsimons@nmt.edu>
>    extern wait_queue_head_t keypress_wait; */
> DECLARE_WAIT_QUEUE_HEAD(keypress_wait);
>
Index: streamable.c
===================================================================
RCS file: /cvs/linux/drivers/sgi/char/streamable.c,v
retrieving revision 1.13
diff -r1.13 streamable.c
23c23,29
< extern struct kbd_struct kbd_table [MAX_NR_CONSOLES];
---
> //extern struct kbd_struct kbd_table [MAX_NR_CONSOLES];
>
> /* changed so that kernel will link -Nathan <npsimons@nmt.edu>
>  * extern struct kbd_struct kbd_table [MAX_NR_CONSOLES]; */
> struct kbd_struct kbd_table[MAX_NR_CONSOLES];
> int fg_console = 0;
>



On Fri, 9 Feb 2001, Florian Lohoff wrote:

> Hi,
> can someone confirm that the current cvs ONCE AGAIN is broken
> on SGIs (Indy/I2) ?
>
> Even with the "early console init" it simply dies ..
>
> Command Monitor.  Type "exit" to return to the menu.
> >> bootp():vmlinux-ip22 console=ttyS0 root=/dev/sda2
> Setting $netaddr to 195.71.99.220 (from server watchdog)
> Obtaining vmlinux-ip22 from server watchdog
> 1556544+0+152424 entry: 0x880025a8
>
>
> Flo
> --
> Florian Lohoff                  flo@rfc822.org             +49-5201-669912
>      Why is it called "common sense" when nobody seems to have any?
>
>



From owner-linux-mips@oss.sgi.com Fri Feb  9 10:51:57 2001
Received:  by oss.sgi.com id <S553846AbRBISvr>;
	Fri, 9 Feb 2001 10:51:47 -0800
Received: from gateway-1237.mvista.com ([12.44.186.158]:4860 "EHLO
        hermes.mvista.com") by oss.sgi.com with ESMTP id <S553842AbRBISve>;
	Fri, 9 Feb 2001 10:51:34 -0800
Received: from mvista.com (IDENT:ppopov@zeus.mvista.com [10.0.0.112])
	by hermes.mvista.com (8.11.0/8.11.0) with ESMTP id f19Ils811662
	for <linux-mips@oss.sgi.com>; Fri, 9 Feb 2001 10:47:54 -0800
Message-ID: <3A843C2D.525643E7@mvista.com>
Date:   Fri, 09 Feb 2001 10:51:25 -0800
From:   Pete Popov <ppopov@mvista.com>
Organization: Monta Vista Software
X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.17 i586)
X-Accept-Language: bg, en
MIME-Version: 1.0
To:     "linux-mips@oss.sgi.com" <linux-mips@oss.sgi.com>
Subject: irq.c
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing


There's a dozen copies of "irq.c", and a few more files that do the same
thing but are named differently. The irq.c in arch/mips/kernel doesn't
seem to be used by any system.  The PowerPC also has lots of variants
also, but I believe they have a single irq.c file that all systems use. 
So I guess my question is, is anyone using arch/mips/kernel/irq.c, and
does everyone plan on moving to that file (which seems like the right
thing to do).  

Pete

From owner-linux-mips@oss.sgi.com Fri Feb  9 11:00:38 2001
Received:  by oss.sgi.com id <S553848AbRBITA2>;
	Fri, 9 Feb 2001 11:00:28 -0800
Received: from pobox.sibyte.com ([208.12.96.20]:19472 "HELO pobox.sibyte.com")
	by oss.sgi.com with SMTP id <S553845AbRBITAV>;
	Fri, 9 Feb 2001 11:00:21 -0800
Received: from postal.sibyte.com (moat.sibyte.com [208.12.96.21])
	by pobox.sibyte.com (Postfix) with SMTP
	id 02982205FE; Fri,  9 Feb 2001 11:00:15 -0800 (PST)
Received: from SMTP agent by mail gateway 
 Fri, 09 Feb 2001 10:54:10 -0800
Received: from plugh.sibyte.com (plugh.sibyte.com [10.21.64.158])
	by postal.sibyte.com (Postfix) with ESMTP
	id 1ECEE1595F; Fri,  9 Feb 2001 11:00:15 -0800 (PST)
Received: by plugh.sibyte.com (Postfix, from userid 61017)
	id 47824686D; Fri,  9 Feb 2001 11:01:19 -0800 (PST)
From:   Justin Carlson <carlson@sibyte.com>
Reply-To: carlson@sibyte.com
Organization: Sibyte
To:     Pete Popov <ppopov@mvista.com>,
        "linux-mips@oss.sgi.com" <linux-mips@oss.sgi.com>
Subject: Re: irq.c
Date:   Fri, 9 Feb 2001 10:56:50 -0800
X-Mailer: KMail [version 1.0.29]
Content-Type: text/plain
References: <3A843C2D.525643E7@mvista.com>
In-Reply-To: <3A843C2D.525643E7@mvista.com>
MIME-Version: 1.0
Message-Id: <0102091101190P.01909@plugh.sibyte.com>
Content-Transfer-Encoding: 8bit
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing

On Fri, 09 Feb 2001, Pete Popov wrote:
> There's a dozen copies of "irq.c", and a few more files that do the same
> thing but are named differently. The irq.c in arch/mips/kernel doesn't
> seem to be used by any system.  The PowerPC also has lots of variants
> also, but I believe they have a single irq.c file that all systems use. 
> So I guess my question is, is anyone using arch/mips/kernel/irq.c, and
> does everyone plan on moving to that file (which seems like the right
> thing to do).  
> 

I've noticed that arch/i386/kernel/irq.c has this note on it:

/*
 * (mostly architecture independent, will move to kernel/irq.c in 2.5.)
 *
 * IRQs are in fact implemented a bit like signal handlers for the kernel.
 * Naturally it's not a 1:1 relation, but there are similarities.
 */

My internal code uses this as a template, in anticipation of this move;
assuming this will happen in 2.5, does it make sense to do an intermediate move
to a common mips/kernel/irq.c?

If it does, I'd like to see mips/kernel/irq.c updated to more closely match the
i386 version, but I'm curious what other people think.

-Justin

From owner-linux-mips@oss.sgi.com Fri Feb  9 11:08:28 2001
Received:  by oss.sgi.com id <S553850AbRBITIS>;
	Fri, 9 Feb 2001 11:08:18 -0800
Received: from gateway-1237.mvista.com ([12.44.186.158]:64497 "EHLO
        hermes.mvista.com") by oss.sgi.com with ESMTP id <S553847AbRBITII>;
	Fri, 9 Feb 2001 11:08:08 -0800
Received: from mvista.com (IDENT:ppopov@zeus.mvista.com [10.0.0.112])
	by hermes.mvista.com (8.11.0/8.11.0) with ESMTP id f19J4S812503;
	Fri, 9 Feb 2001 11:04:28 -0800
Message-ID: <3A84400E.82CEA4B@mvista.com>
Date:   Fri, 09 Feb 2001 11:07:58 -0800
From:   Pete Popov <ppopov@mvista.com>
Organization: Monta Vista Software
X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.17 i586)
X-Accept-Language: bg, en
MIME-Version: 1.0
To:     carlson@sibyte.com
CC:     "linux-mips@oss.sgi.com" <linux-mips@oss.sgi.com>
Subject: Re: irq.c
References: <3A843C2D.525643E7@mvista.com> <0102091101190P.01909@plugh.sibyte.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing

Justin Carlson wrote:
> 
> On Fri, 09 Feb 2001, Pete Popov wrote:
> > There's a dozen copies of "irq.c", and a few more files that do the same
> > thing but are named differently. The irq.c in arch/mips/kernel doesn't
> > seem to be used by any system.  The PowerPC also has lots of variants
> > also, but I believe they have a single irq.c file that all systems use.
> > So I guess my question is, is anyone using arch/mips/kernel/irq.c, and
> > does everyone plan on moving to that file (which seems like the right
> > thing to do).
> >
> 
> I've noticed that arch/i386/kernel/irq.c has this note on it:
> 
> /*
>  * (mostly architecture independent, will move to kernel/irq.c in 2.5.)
>  *
>  * IRQs are in fact implemented a bit like signal handlers for the kernel.
>  * Naturally it's not a 1:1 relation, but there are similarities.
>  */
> 
> My internal code uses this as a template, in anticipation of this move;
> assuming this will happen in 2.5, does it make sense to do an intermediate move
> to a common mips/kernel/irq.c?
> 
> If it does, I'd like to see mips/kernel/irq.c updated to more closely match the
> i386 version, but I'm curious what other people think.

Thanks for pointing that out.  If all architectures will move to
kernel/irq.c, then it probably makes sense to wait.  At first glance,
mips/kernel/irq.c seems pretty close to i386/kernel/irq.c -- certainly a
lot closer than many of the other copies.  

Pete

From owner-linux-mips@oss.sgi.com Fri Feb  9 11:33:07 2001
Received:  by oss.sgi.com id <S553849AbRBITcs>;
	Fri, 9 Feb 2001 11:32:48 -0800
Received: from gateway-1237.mvista.com ([12.44.186.158]:42491 "EHLO
        hermes.mvista.com") by oss.sgi.com with ESMTP id <S553832AbRBITcj>;
	Fri, 9 Feb 2001 11:32:39 -0800
Received: from mvista.com (IDENT:jsun@orion.mvista.com [10.0.0.75])
	by hermes.mvista.com (8.11.0/8.11.0) with ESMTP id f19JSr813936;
	Fri, 9 Feb 2001 11:28:53 -0800
Message-ID: <3A844571.7B5F8F61@mvista.com>
Date:   Fri, 09 Feb 2001 11:30:57 -0800
From:   Jun Sun <jsun@mvista.com>
X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.18 i686)
X-Accept-Language: en
MIME-Version: 1.0
To:     Andreas Jaeger <aj@suse.de>
CC:     "Kevin D. Kissell" <kevink@mips.com>,
        Florian Lohoff <flo@rfc822.org>, linux-mips@oss.sgi.com
Subject: Re: [RESUME] fpu emulator
References: <20010208122030.A5408@paradigm.rfc822.org>
		<005d01c091c4$69940620$0deca8c0@Ulysses> <hor919tm4a.fsf@gee.suse.de>
		<3A8304C0.D3CFFEF7@mvista.com> <hoae7wjjvy.fsf@gee.suse.de>
Content-Type: multipart/mixed;
 boundary="------------38F51F38B68967D495D856BE"
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing

This is a multi-part message in MIME format.
--------------38F51F38B68967D495D856BE
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Andreas Jaeger wrote:
> 
> Jun Sun <jsun@mvista.com> writes:
> 
> > Andreas Jaeger wrote:
> > >
> >
> > > > saves/restores the FP registers in setjmp/longjmp, the
> > >
> > > Any ideas how this can be done?
> > >
> > > > model of "simply sending SIGILL/SIGFPE" will result
> > > > in *all* processes being terminated with extreme prejudice,
> > > > starting with init!
> > >
> >
> > There is a patch for glibc2.0.7, which I think was done by Jay Carlson.  It
> > basically works for glibc2.0.6 as well.  See the one for glibc2.0.6 attached
> > below.
> >
> > I think the patch is not "clean", in the sense that you only want to apply it
> > if you want to configure with "--without-fp".  Otherwise the patch will break
> > other configurations.
> >
> > Jun--- glibc-2.0.6/sysdeps/mips/__longjmp.c.orig-rpm  Sat Sep 11 00:01:44 1999
> > +++ glibc-2.0.6/sysdeps/mips/__longjmp.c      Sat Sep 11 00:02:36 1999
> > @@ -35,6 +35,7 @@
> >       along the way.  */
> >    register int val asm ("a1");
> >
> > +#ifdef __HAVE_FPU__
> 
> I looked through the whole of glibc and GCC and __HAVE_FPU__ is nowhere
> defined for MIPS.  __HAVE_FPU__ is defined for m68k in GCC but that's
> the only platform.
>

You are right - it is not defined in glibc.  Instead it is defined in egcs. 
For this particular build, I need to apply the mips patch for egcs 1.0.3a,
which supplies __HAVE_FPU__.  You can find it somewhere on oss.sgi site. 
There is an additional patch for softfloat which makes __HAVE_FPU__
conditional.  See the attachement.
 
> Therefore I don't think the patch makes any sense at all,

Therefore, it does make sense. :-)

Jun
--------------38F51F38B68967D495D856BE
Content-Type: text/plain; charset=us-ascii;
 name="egcs-1.0.3a-mips-softfloat.patch"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="egcs-1.0.3a-mips-softfloat.patch"

--- egcs-1.0.3a/gcc/config/mips/t-linux.orig	Mon Sep  6 21:38:16 1999
+++ egcs-1.0.3a/gcc/config/mips/t-linux	Wed Sep  8 08:43:58 1999
@@ -9,8 +9,28 @@
 LIBGCC1 =
 CROSS_LIBGCC1 =
 
-MULTILIB_OPTIONS= EL/EB
-MULTILIB_DIRNAMES= el eb
+# These are really part of libgcc1, but this will cause them to be
+# built correctly, so... [taken from t-sparclite]
+LIB2FUNCS_EXTRA = fp-bit.c dp-bit.c
+
+dp-bit.c: $(srcdir)/config/fp-bit.c
+	echo '#ifdef __MIPSEL__' > dp-bit.c
+	echo '#define FLOAT_BIT_ORDER_MISMATCH' >> dp-bit.c
+	echo '#endif' >> dp-bit.c
+	echo '#define US_SOFTWARE_GOFAST' >> dp-bit.c
+	cat $(srcdir)/config/fp-bit.c >> dp-bit.c
+
+fp-bit.c: $(srcdir)/config/fp-bit.c
+	echo '#define FLOAT' > fp-bit.c
+	echo '#ifdef __MIPSEL__' >> fp-bit.c
+	echo '#define FLOAT_BIT_ORDER_MISMATCH' >> fp-bit.c
+	echo '#endif' >> fp-bit.c
+	echo '#define US_SOFTWARE_GOFAST' >> fp-bit.c
+	cat $(srcdir)/config/fp-bit.c >> fp-bit.c
+
+
+MULTILIB_OPTIONS= EL/EB msoft-float
+MULTILIB_DIRNAMES= el eb soft-float
 MULTILIB_MATCHES=
 MULTILIB_EXCEPTIONS=
 
--- egcs-1.0.3a/gcc/config/mips/linux.h.orig	Mon Sep  6 21:38:16 1999
+++ egcs-1.0.3a/gcc/config/mips/linux.h	Wed Sep  8 08:43:40 1999
@@ -82,7 +82,7 @@
 %{!mabi*: -U__mips64} \
 %{fno-PIC:-U__PIC__ -U__pic__} %{fno-pic:-U__PIC__ -U__pic__} \
 %{fPIC:-D__PIC__ -D__pic__} %{fpic:-D__PIC__ -D__pic__} \
-%{-D__HAVE_FPU__ } \
+%{!msoft-float: -D__HAVE_FPU__ } \
 %{posix:-D_POSIX_SOURCE} \
 %{pthread:-D_REENTRANT}"
 
@@ -756,3 +756,7 @@
 
 #undef	MAX_WCHAR_TYPE_SIZE
 #define MAX_WCHAR_TYPE_SIZE	MAX_LONG_TYPE_SIZE
+
+/* US Software GOFAST library support.  */
+#include "gofast.h"
+#define INIT_TARGET_OPTABS INIT_GOFAST_OPTABS

--------------38F51F38B68967D495D856BE--


From owner-linux-mips@oss.sgi.com Fri Feb  9 11:54:28 2001
Received:  by oss.sgi.com id <S553870AbRBITyS>;
	Fri, 9 Feb 2001 11:54:18 -0800
Received: from noose.gt.owl.de ([62.52.19.4]:1291 "HELO noose.gt.owl.de")
	by oss.sgi.com with SMTP id <S553864AbRBITyG>;
	Fri, 9 Feb 2001 11:54:06 -0800
Received: by noose.gt.owl.de (Postfix, from userid 10)
	id 789D87D9; Fri,  9 Feb 2001 20:53:54 +0100 (CET)
Received: by paradigm.rfc822.org (Postfix, from userid 1000)
	id 3ED60EEAC; Fri,  9 Feb 2001 20:54:06 +0100 (CET)
Date:   Fri, 9 Feb 2001 20:54:06 +0100
From:   Florian Lohoff <flo@rfc822.org>
To:     linux-mips@oss.sgi.com
Subject: Re: current cvs broken on sgi
Message-ID: <20010209205406.A26386@paradigm.rfc822.org>
References: <20010209161521.D13248@paradigm.rfc822.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <20010209161521.D13248@paradigm.rfc822.org>; from flo@rfc822.org on Fri, Feb 09, 2001 at 04:15:21PM +0100
Organization: rfc822 - pure communication
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing

On Fri, Feb 09, 2001 at 04:15:21PM +0100, Florian Lohoff wrote:
> Hi,
> can someone confirm that the current cvs ONCE AGAIN is broken
> on SGIs (Indy/I2) ?
> 
> Even with the "early console init" it simply dies ..
> 
I am completely wrong and i fooled myself again - Its the 
"I2 crashes if kernel compiled with newport console" 

Flo
-- 
Florian Lohoff                  flo@rfc822.org             +49-5201-669912
     Why is it called "common sense" when nobody seems to have any?


From owner-linux-mips@oss.sgi.com Fri Feb  9 12:01:28 2001
Received:  by oss.sgi.com id <S553855AbRBIUBS>;
	Fri, 9 Feb 2001 12:01:18 -0800
Received: from gateway-1237.mvista.com ([12.44.186.158]:42743 "EHLO
        hermes.mvista.com") by oss.sgi.com with ESMTP id <S553841AbRBIUBJ>;
	Fri, 9 Feb 2001 12:01:09 -0800
Received: from mvista.com (IDENT:jsun@orion.mvista.com [10.0.0.75])
	by hermes.mvista.com (8.11.0/8.11.0) with ESMTP id f19JvE815916;
	Fri, 9 Feb 2001 11:57:14 -0800
Message-ID: <3A844C16.DD53E7E0@mvista.com>
Date:   Fri, 09 Feb 2001 11:59:18 -0800
From:   Jun Sun <jsun@mvista.com>
X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.18 i686)
X-Accept-Language: en
MIME-Version: 1.0
To:     "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
CC:     "Kevin D. Kissell" <kevink@mips.com>, linux-mips@oss.sgi.com
Subject: Re: config option vs. run-time detection (the debate continues ...)
References: <Pine.GSO.3.96.1010209123643.4645B-100000@delta.ds2.pg.gda.pl>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing

"Maciej W. Rozycki" wrote:
> 
>  But the code that needs to know whether there is a real FPU present is
> indeed minimal (as it should be) thus the gain from removing the detection
> altogether in favour to a config option is at least questionable if not
> insane.
> 

Do you like run-time detection better because it allows a kernel to run on
CPUs both with a FPU and without a FPU?  Or there is something else to it?

Another question.  I know with mips32 and mips64 we can do run-time detection
reliably.  What about other existing processors?

Jun

From owner-linux-mips@oss.sgi.com Fri Feb  9 12:14:27 2001
Received:  by oss.sgi.com id <S553863AbRBIUOR>;
	Fri, 9 Feb 2001 12:14:17 -0800
Received: from noose.gt.owl.de ([62.52.19.4]:9227 "HELO noose.gt.owl.de")
	by oss.sgi.com with SMTP id <S553854AbRBIUNx>;
	Fri, 9 Feb 2001 12:13:53 -0800
Received: by noose.gt.owl.de (Postfix, from userid 10)
	id 6B1157D9; Fri,  9 Feb 2001 21:13:41 +0100 (CET)
Received: by paradigm.rfc822.org (Postfix, from userid 1000)
	id 3D593EEAC; Fri,  9 Feb 2001 20:58:38 +0100 (CET)
Date:   Fri, 9 Feb 2001 20:58:38 +0100
From:   Florian Lohoff <flo@rfc822.org>
To:     Jun Sun <jsun@mvista.com>
Cc:     "Kevin D. Kissell" <kevink@mips.com>, linux-mips@oss.sgi.com
Subject: Re: config option vs. run-time detection (the debate continues ...)
Message-ID: <20010209205838.B26386@paradigm.rfc822.org>
References: <3A830135.B1304041@mvista.com> <01bf01c0921b$6de26620$0deca8c0@Ulysses> <3A83247D.FC52431D@mvista.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <3A83247D.FC52431D@mvista.com>; from jsun@mvista.com on Thu, Feb 08, 2001 at 02:58:05PM -0800
Organization: rfc822 - pure communication
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing

On Thu, Feb 08, 2001 at 02:58:05PM -0800, Jun Sun wrote:

>  a) HAS_FPU & FPU_EMULATION - which is necessary when FPU is not a full
> implementation.
> 
>  b) !HAS_FPU & FPU_EMULATION - which allows one to run fpu-ful userland
> application

These 2 cases are perfectly good 

>  c) HAS_FPU & !FPU_EMULATION - when FPU is a full implementaion (or use the
> old incomplete emaulation?)
> 
>  d) !HAS_FPU & !FPU_EMULATION - it mandates non-fpu-ful userland (which to me
> is perfectly fine)

These 2 cases present a user/developer who decided not to have any
fpu support kernel/cpu wise. Kill his apps if using "illegal" instructions.

Flo
-- 
Florian Lohoff                  flo@rfc822.org             +49-5201-669912
     Why is it called "common sense" when nobody seems to have any?


From owner-linux-mips@oss.sgi.com Fri Feb  9 12:39:57 2001
Received:  by oss.sgi.com id <S553872AbRBIUjh>;
	Fri, 9 Feb 2001 12:39:37 -0800
Received: from delta.ds2.pg.gda.pl ([153.19.144.1]:20142 "EHLO
        delta.ds2.pg.gda.pl") by oss.sgi.com with ESMTP id <S553864AbRBIUjV>;
	Fri, 9 Feb 2001 12:39:21 -0800
Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id VAA20117;
	Fri, 9 Feb 2001 21:39:29 +0100 (MET)
Date:   Fri, 9 Feb 2001 21:39:29 +0100 (MET)
From:   "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To:     Jun Sun <jsun@mvista.com>
cc:     "Kevin D. Kissell" <kevink@mips.com>, linux-mips@oss.sgi.com
Subject: Re: config option vs. run-time detection (the debate continues ...)
In-Reply-To: <3A844C16.DD53E7E0@mvista.com>
Message-ID: <Pine.GSO.3.96.1010209212607.13007B-100000@delta.ds2.pg.gda.pl>
Organization: Technical University of Gdansk
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing

On Fri, 9 Feb 2001, Jun Sun wrote:

> Do you like run-time detection better because it allows a kernel to run on
> CPUs both with a FPU and without a FPU?  Or there is something else to it?

 Nope.  There are certain explicit actions that are to be performed by the
kernel if a real FPU is present, such as saving and restoring its
registers or setting the control register.  Therefore the kernel has to
know if a real part is present and act accordingly.  Maintaining a table
of all CPU ids ever manufactured and manually setting the FPU presence bit
is unreliable, especially as there are chips which cannot be classified
this way, e.g. knowing your CPU is an R3000A you don't know if an R3010A
FPU is soldered as well or not. 

> Another question.  I know with mips32 and mips64 we can do run-time detection
> reliably.  What about other existing processors?

 I've sent a quote from an IDT manual recently.  It recommended to use the
FPU implementation ID to check if an FP hw is present.  I believe it
should work for any sane implementation of a MIPS CPU.  See the mail for
details. 

  Maciej

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +


From owner-linux-mips@oss.sgi.com Fri Feb  9 12:41:38 2001
Received:  by oss.sgi.com id <S553875AbRBIUl2>;
	Fri, 9 Feb 2001 12:41:28 -0800
Received: from mail.kdt.de ([195.8.224.4]:32517 "EHLO mail.kdt.de")
	by oss.sgi.com with ESMTP id <S553871AbRBIUlK>;
	Fri, 9 Feb 2001 12:41:10 -0800
Received: from arthur.inka.de (arthur.kdt.de [195.8.250.5])
	by mail.kdt.de (8.11.1/8.11.0) with ESMTP id f19KeZ411455;
	Fri, 9 Feb 2001 21:40:39 +0100
Received: from gromit.rhein-neckar.de ([192.168.27.3] ident=postfix)
	by arthur.inka.de with esmtp (Exim 3.11 #1)
	id 14RKCO-00055g-00; Fri, 09 Feb 2001 21:31:20 +0100
Received: by gromit.rhein-neckar.de (Postfix, from userid 207)
	id 853991EA2A; Fri,  9 Feb 2001 21:31:18 +0100 (CET)
To:     Jun Sun <jsun@mvista.com>
Cc:     "Kevin D. Kissell" <kevink@mips.com>,
        Florian Lohoff <flo@rfc822.org>, linux-mips@oss.sgi.com
Subject: Re: [RESUME] fpu emulator
References: <20010208122030.A5408@paradigm.rfc822.org>
	<005d01c091c4$69940620$0deca8c0@Ulysses> <hor919tm4a.fsf@gee.suse.de>
	<3A8304C0.D3CFFEF7@mvista.com> <hoae7wjjvy.fsf@gee.suse.de>
	<3A844571.7B5F8F61@mvista.com>
From:   Andreas Jaeger <aj@suse.de>
Date:   09 Feb 2001 21:31:18 +0100
In-Reply-To: <3A844571.7B5F8F61@mvista.com> (Jun Sun's message of "Fri, 09 Feb 2001 11:30:57 -0800")
Message-ID: <u8r917r42x.fsf@gromit.rhein-neckar.de>
Lines:  61
User-Agent: Gnus/5.090001 (Oort Gnus v0.01) XEmacs/21.1 (Channel Islands)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing

Jun Sun <jsun@mvista.com> writes:

> Andreas Jaeger wrote:
> > 
> > Jun Sun <jsun@mvista.com> writes:
> > 
> > > Andreas Jaeger wrote:
> > > >
> > >
> > > > > saves/restores the FP registers in setjmp/longjmp, the
> > > >
> > > > Any ideas how this can be done?
> > > >
> > > > > model of "simply sending SIGILL/SIGFPE" will result
> > > > > in *all* processes being terminated with extreme prejudice,
> > > > > starting with init!
> > > >
> > >
> > > There is a patch for glibc2.0.7, which I think was done by Jay Carlson.  It
> > > basically works for glibc2.0.6 as well.  See the one for glibc2.0.6 attached
> > > below.
> > >
> > > I think the patch is not "clean", in the sense that you only want to apply it
> > > if you want to configure with "--without-fp".  Otherwise the patch will break
> > > other configurations.
> > >
> > > Jun--- glibc-2.0.6/sysdeps/mips/__longjmp.c.orig-rpm  Sat Sep 11 00:01:44 1999
> > > +++ glibc-2.0.6/sysdeps/mips/__longjmp.c      Sat Sep 11 00:02:36 1999
> > > @@ -35,6 +35,7 @@
> > >       along the way.  */
> > >    register int val asm ("a1");
> > >
> > > +#ifdef __HAVE_FPU__
> > 
> > I looked through the whole of glibc and GCC and __HAVE_FPU__ is nowhere
> > defined for MIPS.  __HAVE_FPU__ is defined for m68k in GCC but that's
> > the only platform.
> >
> 
> You are right - it is not defined in glibc.  Instead it is defined in egcs. 
> For this particular build, I need to apply the mips patch for egcs 1.0.3a,
> which supplies __HAVE_FPU__.  You can find it somewhere on oss.sgi site. 
> There is an additional patch for softfloat which makes __HAVE_FPU__
> conditional.  See the attachement.
>  
> > Therefore I don't think the patch makes any sense at all,
> 
> Therefore, it does make sense. :-)

As long as that old patch hasn't found it's way into the official
sources, the patch doesn't make sense ;-).  I'm willing to discuss
these issues again after those or similar patches have been added to
the CVS archive of GCC - but without this, there's no way to get the
patches into glibc.

Andreas
-- 
 Andreas Jaeger
  SuSE Labs aj@suse.de
   private aj@arthur.inka.de
    http://www.suse.de/~aj

From owner-linux-mips@oss.sgi.com Fri Feb  9 13:12:28 2001
Received:  by oss.sgi.com id <S553884AbRBIVMS>;
	Fri, 9 Feb 2001 13:12:18 -0800
Received: from gateway-1237.mvista.com ([12.44.186.158]:44272 "EHLO
        hermes.mvista.com") by oss.sgi.com with ESMTP id <S553878AbRBIVMG>;
	Fri, 9 Feb 2001 13:12:06 -0800
Received: from mvista.com (IDENT:jsun@orion.mvista.com [10.0.0.75])
	by hermes.mvista.com (8.11.0/8.11.0) with ESMTP id f19L7k819484;
	Fri, 9 Feb 2001 13:07:46 -0800
Message-ID: <3A845C9E.C006CC39@mvista.com>
Date:   Fri, 09 Feb 2001 13:09:50 -0800
From:   Jun Sun <jsun@mvista.com>
X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.18 i686)
X-Accept-Language: en
MIME-Version: 1.0
To:     Andreas Jaeger <aj@suse.de>
CC:     "Kevin D. Kissell" <kevink@mips.com>,
        Florian Lohoff <flo@rfc822.org>, linux-mips@oss.sgi.com
Subject: Re: [RESUME] fpu emulator
References: <20010208122030.A5408@paradigm.rfc822.org>
		<005d01c091c4$69940620$0deca8c0@Ulysses> <hor919tm4a.fsf@gee.suse.de>
		<3A8304C0.D3CFFEF7@mvista.com> <hoae7wjjvy.fsf@gee.suse.de>
		<3A844571.7B5F8F61@mvista.com> <u8r917r42x.fsf@gromit.rhein-neckar.de>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing

Andreas Jaeger wrote:
> 
> Jun Sun <jsun@mvista.com> writes:
> 
> > Andreas Jaeger wrote:
> > >
> > > Jun Sun <jsun@mvista.com> writes:
> > >
> > > > Andreas Jaeger wrote:
> > > > >
> > > >
> > > > > > saves/restores the FP registers in setjmp/longjmp, the
> > > > >
> > > > > Any ideas how this can be done?
> > > > >
> > > > > > model of "simply sending SIGILL/SIGFPE" will result
> > > > > > in *all* processes being terminated with extreme prejudice,
> > > > > > starting with init!
> > > > >
> > > >
> > > > There is a patch for glibc2.0.7, which I think was done by Jay Carlson.  It
> > > > basically works for glibc2.0.6 as well.  See the one for glibc2.0.6 attached
> > > > below.
> > > >
> > > > I think the patch is not "clean", in the sense that you only want to apply it
> > > > if you want to configure with "--without-fp".  Otherwise the patch will break
> > > > other configurations.
> > > >
> > > > Jun--- glibc-2.0.6/sysdeps/mips/__longjmp.c.orig-rpm  Sat Sep 11 00:01:44 1999
> > > > +++ glibc-2.0.6/sysdeps/mips/__longjmp.c      Sat Sep 11 00:02:36 1999
> > > > @@ -35,6 +35,7 @@
> > > >       along the way.  */
> > > >    register int val asm ("a1");
> > > >
> > > > +#ifdef __HAVE_FPU__
> > >
> > > I looked through the whole of glibc and GCC and __HAVE_FPU__ is nowhere
> > > defined for MIPS.  __HAVE_FPU__ is defined for m68k in GCC but that's
> > > the only platform.
> > >
> >
> > You are right - it is not defined in glibc.  Instead it is defined in egcs.
> > For this particular build, I need to apply the mips patch for egcs 1.0.3a,
> > which supplies __HAVE_FPU__.  You can find it somewhere on oss.sgi site.
> > There is an additional patch for softfloat which makes __HAVE_FPU__
> > conditional.  See the attachement.
> >
> > > Therefore I don't think the patch makes any sense at all,
> >
> > Therefore, it does make sense. :-)
> 
> As long as that old patch hasn't found it's way into the official
> sources, the patch doesn't make sense ;-).  I'm willing to discuss
> these issues again after those or similar patches have been added to
> the CVS archive of GCC - but without this, there's no way to get the
> patches into glibc.
> 

Well, like I said earlier.  This is not a clean patch - it cannot be checked
in because it will break other configurations, AFAIK.  (OK, I probably should
have called it *hack* from the beginning :-0)

It would be nice to have some clean solutions...

Jun

From owner-linux-mips@oss.sgi.com Fri Feb  9 13:33:48 2001
Received:  by oss.sgi.com id <S553663AbRBIVd1>;
	Fri, 9 Feb 2001 13:33:27 -0800
Received: from gateway-1237.mvista.com ([12.44.186.158]:62455 "EHLO
        hermes.mvista.com") by oss.sgi.com with ESMTP id <S553647AbRBIVdL>;
	Fri, 9 Feb 2001 13:33:11 -0800
Received: from mvista.com (IDENT:jsun@orion.mvista.com [10.0.0.75])
	by hermes.mvista.com (8.11.0/8.11.0) with ESMTP id f19LT3820818;
	Fri, 9 Feb 2001 13:29:03 -0800
Message-ID: <3A84619B.94224C30@mvista.com>
Date:   Fri, 09 Feb 2001 13:31:07 -0800
From:   Jun Sun <jsun@mvista.com>
X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.18 i686)
X-Accept-Language: en
MIME-Version: 1.0
To:     "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
CC:     "Kevin D. Kissell" <kevink@mips.com>, linux-mips@oss.sgi.com
Subject: Re: config option vs. run-time detection (the debate continues ...)
References: <Pine.GSO.3.96.1010209212607.13007B-100000@delta.ds2.pg.gda.pl>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing

"Maciej W. Rozycki" wrote:
> 
> On Fri, 9 Feb 2001, Jun Sun wrote:
> 
> > Do you like run-time detection better because it allows a kernel to run on
> > CPUs both with a FPU and without a FPU?  Or there is something else to it?
> 
>  Nope.  There are certain explicit actions that are to be performed by the
> kernel if a real FPU is present, such as saving and restoring its
> registers or setting the control register.  Therefore the kernel has to
> know if a real part is present and act accordingly.  Maintaining a table
> of all CPU ids ever manufactured and manually setting the FPU presence bit
> is unreliable, especially as there are chips which cannot be classified
> this way, e.g. knowing your CPU is an R3000A you don't know if an R3010A
> FPU is soldered as well or not.
> 

Apparently you did not read my first email on this thread. :-)

I agree "Maintaining a table of all CPU ids ever manufactured and manually
setting the FPU presence bit is unreliable ...".

I was debating about how we let kernel know if there is a real FPU:

  a) an explicit config option, CONFIG_HAS_FPU, (which is not associated with
PrID), plus "#ifdef CONFIG_HAS_FPU ..." code.  Or

  b) have run-time detection and many "if .. then .." code.

I listed some pro's and con's for both of them in my first email.  Right now,
I found myself not having a strong preference but still biased towards config
option approach ( - as if that really matters. :-0)

> > Another question.  I know with mips32 and mips64 we can do run-time detection
> > reliably.  What about other existing processors?
> 
>  I've sent a quote from an IDT manual recently.  It recommended to use the
> FPU implementation ID to check if an FP hw is present.  I believe it
> should work for any sane implementation of a MIPS CPU.  See the mail for
> details.
> 

I actually don't understand your IDT quote.  It requires one to call mfc1 to
get FCR0.  On many CPUs without a FPU, this will generate an exception.  Are
you suggesting that we should catch the exception and from that we conclude
there is no FPU present?

Jun

From owner-linux-mips@oss.sgi.com Fri Feb  9 14:08:48 2001
Received:  by oss.sgi.com id <S553686AbRBIWI2>;
	Fri, 9 Feb 2001 14:08:28 -0800
Received: from mx.mips.com ([206.31.31.226]:11242 "EHLO mx.mips.com")
	by oss.sgi.com with ESMTP id <S553647AbRBIWI0>;
	Fri, 9 Feb 2001 14:08:26 -0800
Received: from newman.mips.com (ns-dmz [206.31.31.225])
	by mx.mips.com (8.9.3/8.9.0) with ESMTP id OAA28965;
	Fri, 9 Feb 2001 14:08:25 -0800 (PST)
Received: from Ulysses (ulysses [192.168.236.13])
	by newman.mips.com (8.9.3/8.9.0) with SMTP id OAA14443;
	Fri, 9 Feb 2001 14:08:21 -0800 (PST)
Message-ID: <01b001c092e5$58f6a8a0$0deca8c0@Ulysses>
From:   "Kevin D. Kissell" <kevink@mips.com>
To:     "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>,
        "Jun Sun" <jsun@mvista.com>
Cc:     <linux-mips@oss.sgi.com>
References: <Pine.GSO.3.96.1010209212607.13007B-100000@delta.ds2.pg.gda.pl>
Subject: Re: config option vs. run-time detection (the debate continues ...)
Date:   Fri, 9 Feb 2001 23:12:00 +0100
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing

> > Another question.  I know with mips32 and mips64 we can do run-time
detection
> > reliably.  What about other existing processors?
>
>  I've sent a quote from an IDT manual recently.  It recommended to use the
> FPU implementation ID to check if an FP hw is present.  I believe it
> should work for any sane implementation of a MIPS CPU.  See the mail for
> details.

The best method I know for post-R3000 CPUs is to
write and read back the CU1 bit of the Status register.
CPUs without an integrated FPU will not have a flip-flop
for the bit, and will read back a 0 even after writing a 1.
There was never any architectural requirement that
this be so, however, and this cannot be absolutely
guaranteed to work.  If anyone has a counter-example,
however, I'd be interested in hearing about it.

            Kevin K.


From owner-linux-mips@oss.sgi.com Sat Feb 10 01:02:03 2001
Received:  by oss.sgi.com id <S553651AbRBJJBx>;
	Sat, 10 Feb 2001 01:01:53 -0800
Received: from delta.ds2.pg.gda.pl ([153.19.144.1]:14514 "EHLO
        delta.ds2.pg.gda.pl") by oss.sgi.com with ESMTP id <S553646AbRBJJBd>;
	Sat, 10 Feb 2001 01:01:33 -0800
Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id KAA02431;
	Sat, 10 Feb 2001 10:01:50 +0100 (MET)
Date:   Sat, 10 Feb 2001 10:01:50 +0100 (MET)
From:   "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To:     Jun Sun <jsun@mvista.com>
cc:     "Kevin D. Kissell" <kevink@mips.com>, linux-mips@oss.sgi.com
Subject: Re: config option vs. run-time detection (the debate continues ...)
In-Reply-To: <3A84619B.94224C30@mvista.com>
Message-ID: <Pine.GSO.3.96.1010210094331.2153A-100000@delta.ds2.pg.gda.pl>
Organization: Technical University of Gdansk
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing

On Fri, 9 Feb 2001, Jun Sun wrote:

>   a) an explicit config option, CONFIG_HAS_FPU, (which is not associated with
> PrID), plus "#ifdef CONFIG_HAS_FPU ..." code.  Or
> 
>   b) have run-time detection and many "if .. then .." code.
> 
> I listed some pro's and con's for both of them in my first email.  Right now,
> I found myself not having a strong preference but still biased towards config
> option approach ( - as if that really matters. :-0)

 Well, the number of places a run-time condition exist is small and they
are not performance-critical. 

> I actually don't understand your IDT quote.  It requires one to call mfc1 to
> get FCR0.  On many CPUs without a FPU, this will generate an exception.  Are
> you suggesting that we should catch the exception and from that we conclude
> there is no FPU present?

 I don't have an FPU-less system and I can't check such code.  I need to
depend on others (I couldn't test all possible configurations anyway).  If
we have a chance to get an exception we have to catch it, of course
(that's trivial to handle in Linux). 

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +


From owner-linux-mips@oss.sgi.com Sat Feb 10 01:05:23 2001
Received:  by oss.sgi.com id <S553686AbRBJJFN>;
	Sat, 10 Feb 2001 01:05:13 -0800
Received: from delta.ds2.pg.gda.pl ([153.19.144.1]:16562 "EHLO
        delta.ds2.pg.gda.pl") by oss.sgi.com with ESMTP id <S553650AbRBJJFF>;
	Sat, 10 Feb 2001 01:05:05 -0800
Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id KAA02509;
	Sat, 10 Feb 2001 10:05:28 +0100 (MET)
Date:   Sat, 10 Feb 2001 10:05:28 +0100 (MET)
From:   "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To:     "Kevin D. Kissell" <kevink@mips.com>
cc:     Jun Sun <jsun@mvista.com>, linux-mips@oss.sgi.com
Subject: Re: config option vs. run-time detection (the debate continues ...)
In-Reply-To: <01b001c092e5$58f6a8a0$0deca8c0@Ulysses>
Message-ID: <Pine.GSO.3.96.1010210100216.2153B-100000@delta.ds2.pg.gda.pl>
Organization: Technical University of Gdansk
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing

On Fri, 9 Feb 2001, Kevin D. Kissell wrote:

> The best method I know for post-R3000 CPUs is to
> write and read back the CU1 bit of the Status register.
> CPUs without an integrated FPU will not have a flip-flop
> for the bit, and will read back a 0 even after writing a 1.
> There was never any architectural requirement that
> this be so, however, and this cannot be absolutely
> guaranteed to work.  If anyone has a counter-example,
> however, I'd be interested in hearing about it.

 OK, then we may try to toggle CU1 and only if that succeeds check the FPU
implementation id.  Thanks for the point. 

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +


From owner-linux-mips@oss.sgi.com Sat Feb 10 05:02:47 2001
Received:  by oss.sgi.com id <S553748AbRBJNCh>;
	Sat, 10 Feb 2001 05:02:37 -0800
Received: from cvsftp.cotw.com ([208.242.241.39]:22023 "EHLO cvsftp.cotw.com")
	by oss.sgi.com with ESMTP id <S553688AbRBJNCX>;
	Sat, 10 Feb 2001 05:02:23 -0800
Received: from cotw.com (dsl19.cedar-rapids.net [208.242.241.211])
	by cvsftp.cotw.com (8.9.3/8.9.3) with ESMTP id HAA17339
	for <linux-mips@oss.sgi.com>; Sat, 10 Feb 2001 07:02:20 -0600
Message-ID: <3A853EB4.2DED9737@cotw.com>
Date:   Sat, 10 Feb 2001 07:14:28 -0600
From:   "Steven J. Hill" <sjhill@cotw.com>
Reply-To: sjhill@cotw.com
X-Mailer: Mozilla 4.73 [en] (X11; I; Linux 2.4.0 i686)
X-Accept-Language: en
MIME-Version: 1.0
To:     linux-mips@oss.sgi.com
Subject: Re: Patch for Philips Nino...
References: <Pine.LNX.4.21.0101231656410.3184-100000@cslin-gps> <3A84E2C4.112F8B2F@cotw.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing

"Steven J. Hill" wrote:
> 
> I would like to submit a patch for the Philips Nino. It can be
> gotten from here (ftp://ftp.cotw.com/pub/nino/mips-tools/).
> I didn't want to waste bandwidth by attaching it. It overlaps
> some of Florian's stuff. Criticisms very welcome. Thanks.
> 
And then he realizes that in his sleepiness, he attached it
anyway. Sorry everyone.

-Steve

-- 
 Steven J. Hill - Embedded SW Engineer
 Public Key: 'finger sjhill@mail.cotw.com'
 FPR1: E124 6E1C AF8E 7802 A815
 FPR2: 7D72 829C 3386 4C4A E17D

From owner-linux-mips@oss.sgi.com Sun Feb 11 22:15:51 2001
Received:  by oss.sgi.com id <S553849AbRBLGPb>;
	Sun, 11 Feb 2001 22:15:31 -0800
Received: from rotor.chem.unr.edu ([134.197.32.176]:54535 "EHLO
        rotor.chem.unr.edu") by oss.sgi.com with ESMTP id <S553840AbRBLGPN>;
	Sun, 11 Feb 2001 22:15:13 -0800
Received: (from wesolows@localhost)
	by rotor.chem.unr.edu (8.9.3/8.9.3) id WAA28578;
	Sun, 11 Feb 2001 22:15:16 -0800
Date:   Sun, 11 Feb 2001 22:15:15 -0800
From:   Keith M Wesolowski <wesolows@chem.unr.edu>
To:     Brandon Barker <bebarker@meginc.com>
Cc:     linux-mips@oss.sgi.com
Subject: Re: Linux/Indy HOWTO
Message-ID: <20010211221515.A28029@chem.unr.edu>
References: <01020619540500.01634@localhost.localdomain>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2i
In-Reply-To: <01020619540500.01634@localhost.localdomain>; from bebarker@meginc.com on Tue, Feb 06, 2001 at 07:54:05PM -0500
X-Complaints-To: postmaster@chem.unr.edu
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing

On Tue, Feb 06, 2001 at 07:54:05PM -0500, Brandon Barker wrote:

> Will there be a SGI/Linux Install HOWTO especially pertaining to the
> Indy.  I have an Indy, but I do not own IRIX, and I can't find any
> instructions in the current howto because it is not meant to be an
> install HOWTO.

There are several documents pertaining to installing various Linux
distributions on an Indy.  You should probably start with
http://oss.sgi.com/mips/i2-howto.html, which applies to Indy as well.
If you want to use Simple, start at the newly reanimated
http://foobazco.org/~wesolows/Install-HOWTO.html.  For Hard Hat, there
is an Indy-specific document at http://www.linux.sgi.com/manhattan/.
In short, a quick google search and/or the FAQ are more than adequate
to get you started.

> I have also heard rumors that SGI eventually plans to drop MIPS/IRIX
> all togethor and that they never plan on offering Linux as a viable
> OS to it's MIPS systems.

*sigh* This really should go in the FAQ.  Expect to see IRIX die at
about the same time the flying monkeys on the moon overthrow Earth by
hurling a giant wad of dung at us with their catapult.

-- 
Keith M Wesolowski			wesolows@chem.unr.edu

From owner-linux-mips@oss.sgi.com Mon Feb 12 10:26:06 2001
Received:  by oss.sgi.com id <S553893AbRBLSZ5>;
	Mon, 12 Feb 2001 10:25:57 -0800
Received: from [12.44.186.158] ([12.44.186.158]:15857 "EHLO hermes.mvista.com")
	by oss.sgi.com with ESMTP id <S553878AbRBLSZm>;
	Mon, 12 Feb 2001 10:25:42 -0800
Received: from mvista.com (IDENT:jsun@orion.mvista.com [10.0.0.75])
	by hermes.mvista.com (8.11.0/8.11.0) with ESMTP id f1CIJj829136;
	Mon, 12 Feb 2001 10:19:45 -0800
Message-ID: <3A8829B9.17B7F691@mvista.com>
Date:   Mon, 12 Feb 2001 10:21:45 -0800
From:   Jun Sun <jsun@mvista.com>
X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.18 i686)
X-Accept-Language: en
MIME-Version: 1.0
To:     "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
CC:     "Kevin D. Kissell" <kevink@mips.com>, linux-mips@oss.sgi.com
Subject: Re: config option vs. run-time detection (the debate continues ...)
References: <Pine.GSO.3.96.1010210094331.2153A-100000@delta.ds2.pg.gda.pl>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing

"Maciej W. Rozycki" wrote:
> 
>  Well, the number of places a run-time condition exist is small and they
> are not performance-critical.
> 
> > I actually don't understand your IDT quote.  It requires one to call mfc1 to
> > get FCR0.  On many CPUs without a FPU, this will generate an exception.  Are
> > you suggesting that we should catch the exception and from that we conclude
> > there is no FPU present?
> 
>  I don't have an FPU-less system and I can't check such code.  I need to
> depend on others (I couldn't test all possible configurations anyway).

However, with CONFIG_HAS_FPU approach I know for sure it will work for any
MIPS CPU, as long as the programmer specifies it correctly. :-)

> If
> we have a chance to get an exception we have to catch it, of course
> (that's trivial to handle in Linux).
> 

No effort (as in CONFIG_HAS_FPU approach) is still better than trivial or
small effort ( as in run-time detection).  :-)

---

I am very curious what makes you object to the CONFIG_HAS_FPU approach,
especially you said earlier it was not about the inability to support both FPU
and FPU-less CPUs with the same kernel image.

Jun

From owner-linux-mips@oss.sgi.com Tue Feb 13 06:52:55 2001
Received:  by oss.sgi.com id <S553919AbRBMOwq>;
	Tue, 13 Feb 2001 06:52:46 -0800
Received: from delta.ds2.pg.gda.pl ([153.19.144.1]:64400 "EHLO
        delta.ds2.pg.gda.pl") by oss.sgi.com with ESMTP id <S553916AbRBMOwZ>;
	Tue, 13 Feb 2001 06:52:25 -0800
Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id PAA22077;
	Tue, 13 Feb 2001 15:42:35 +0100 (MET)
Date:   Tue, 13 Feb 2001 15:42:34 +0100 (MET)
From:   "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
Reply-To: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To:     Karsten Merker <karsten@excalibur.cologne.de>,
        Ralf Baechle <ralf@uni-koblenz.de>
cc:     Harald Koerfgen <Harald.Koerfgen@home.ivm.de>,
        linux-mips@oss.sgi.com
Subject: Re: DECstation crashes
In-Reply-To: <20010209000419.A17609@excalibur.cologne.de>
Message-ID: <Pine.GSO.3.96.1010213152936.20214A-100000@delta.ds2.pg.gda.pl>
Organization: Technical University of Gdansk
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing

On Fri, 9 Feb 2001, Karsten Merker wrote:

> Do other Linux/MIPS-targets besides the DECstations show similar problems
> (kernel crash due to NULL-pointer dereference in __free_pages_ok just
> after mounting the rootfs) or is this a decstation-specific effect? The
> problems happens both on R3k and R4k (tested on 5000/20 and 5000/150).

 The following patch should fix it.  Hmm, I wonder how it worked before at
all...  There is a related small fix for ARC included.  Ralf, please apply
these changes.

 Still 2.4.1 is rather unstable here -- it crashes silently under moderate
system activity after boot.  If nothing gets executed the system survives
for long.  A single `ls -la' is able to kill it if unfortunate enough,
though.  I'm still using 2.4.0-test12 taken on Jan 10, which is rock solid
apart from a single libtool script which kills it repeatedly always at the
same point (currently investigating it).

  Maciej

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

patch-mips-2.4.1-20010208-mem_map-43
diff -up --recursive --new-file linux-mips-2.4.1-20010208.macro/arch/mips/arc/memory.c linux-mips-2.4.1-20010208/arch/mips/arc/memory.c
--- linux-mips-2.4.1-20010208.macro/arch/mips/arc/memory.c	Wed Jan 17 05:25:58 2001
+++ linux-mips-2.4.1-20010208/arch/mips/arc/memory.c	Sun Feb 11 11:19:37 2001
@@ -145,7 +145,7 @@ prom_free_prom_memory (void)
 			      + boot_mem_map.map[i].size) {
 			ClearPageReserved(virt_to_page(__va(addr)));
 			set_page_count(virt_to_page(__va(addr)), 1);
-			free_page(__va(addr));
+			free_page((unsigned long)__va(addr));
 			addr += PAGE_SIZE;
 			freed += PAGE_SIZE;
 		}
diff -up --recursive --new-file linux-mips-2.4.1-20010208.macro/arch/mips/dec/prom/memory.c linux-mips-2.4.1-20010208/arch/mips/dec/prom/memory.c
--- linux-mips-2.4.1-20010208.macro/arch/mips/dec/prom/memory.c	Tue Dec 12 05:26:20 2000
+++ linux-mips-2.4.1-20010208/arch/mips/dec/prom/memory.c	Sun Feb 11 11:41:12 2001
@@ -108,10 +108,10 @@ void __init prom_meminit(unsigned int ma
 		rex_setup_memory_region();
 }
 
-void prom_free_prom_memory (void)
+void __init prom_free_prom_memory (void)
 {
 	unsigned long addr, end;
-	extern	char _ftext;
+	extern char _ftext;
 
 	/*
 	 * Free everything below the kernel itself but leave
@@ -126,16 +126,16 @@ void prom_free_prom_memory (void)
 	 * XXX: save this address for use in dec_lance.c?
 	 */
 	if (IOASIC)
-		end = PHYSADDR(&_ftext) - 0x00020000;
+		end = __pa(&_ftext) - 0x00020000;
 	else
 #endif
-		end = PHYSADDR(&_ftext);
+		end = __pa(&_ftext);
 
 	addr = PAGE_SIZE;
 	while (addr < end) {
-		ClearPageReserved(virt_to_page(addr));
-		set_page_count(virt_to_page(addr), 1);
-		free_page(addr);
+		ClearPageReserved(virt_to_page(__va(addr)));
+		set_page_count(virt_to_page(__va(addr)), 1);
+		free_page((unsigned long)__va(addr));
 		addr += PAGE_SIZE;
 	}
 


From owner-linux-mips@oss.sgi.com Tue Feb 13 08:18:25 2001
Received:  by oss.sgi.com id <S553920AbRBMQSQ>;
	Tue, 13 Feb 2001 08:18:16 -0800
Received: from delta.ds2.pg.gda.pl ([153.19.144.1]:54417 "EHLO
        delta.ds2.pg.gda.pl") by oss.sgi.com with ESMTP id <S553852AbRBMQSC>;
	Tue, 13 Feb 2001 08:18:02 -0800
Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id QAA22691;
	Tue, 13 Feb 2001 16:00:28 +0100 (MET)
Date:   Tue, 13 Feb 2001 16:00:28 +0100 (MET)
From:   "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To:     Ralf Baechle <ralf@uni-koblenz.de>
cc:     Harald Koerfgen <Harald.Koerfgen@home.ivm.de>, linux-mips@fnet.fr,
        linux-mips@oss.sgi.com
Subject: An IRQ handler fix for arch/mips/dec/irq.c (fwd)
Message-ID: <Pine.GSO.3.96.1010213155128.20214B-100000@delta.ds2.pg.gda.pl>
Organization: Technical University of Gdansk
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing

Ralf,

 The fix does make crashes go away indeed.  Please apply.  Thanks.

  Maciej

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

---------- Forwarded message ----------
Message-ID: <Pine.GSO.3.96.1010208131342.29177J-100000@delta.ds2.pg.gda.pl>
Date: Thu, 8 Feb 2001 13:34:36 +0100 (MET)
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To: Harald Koerfgen <Harald.Koerfgen@home.ivm.de>, linux-mips@fnet.fr,
    linux-mips@oss.sgi.com
Subject: An IRQ handler fix for arch/mips/dec/irq.c

Hi,

 The epilogue for the DECstation's IRQ handler is buggy -- it permits
infinite interrupt recursion which may lead to a stack overflow.  I wasn't
able to check if that's the reason of random crashes I get when I run
strace at the console, yet, but it might be -- the load might be up to 10k
interrupts per second if data is available in time.

 Please apply.

  Maciej

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

patch-mips-2.4.0-do_irq-0
diff -up --recursive --new-file linux-mips-2.4.0-20010126.macro/arch/mips/dec/irq.c linux-mips-2.4.0-20010126/arch/mips/dec/irq.c
--- linux-mips-2.4.0-20010126.macro/arch/mips/dec/irq.c	Sun Dec  3 05:26:46 2000
+++ linux-mips-2.4.0-20010126/arch/mips/dec/irq.c	Thu Feb  8 07:44:10 2001
@@ -136,8 +136,8 @@ asmlinkage void do_IRQ(int irq, struct p
 	} while (action);
 	if (do_random & SA_SAMPLE_RANDOM)
 	    add_interrupt_randomness(irq);
-	unmask_irq(irq);
 	__cli();
+	unmask_irq(irq);
     }
     irq_exit(cpu, irq);
 


From owner-linux-mips@oss.sgi.com Tue Feb 13 08:25:56 2001
Received:  by oss.sgi.com id <S553925AbRBMQZp>;
	Tue, 13 Feb 2001 08:25:45 -0800
Received: from ezksun.unizh.ch ([130.60.20.131]:43460 "EHLO geo.umnw.ethz.ch")
	by oss.sgi.com with ESMTP id <S553859AbRBMQZ3>;
	Tue, 13 Feb 2001 08:25:29 -0800
Received: from geo.umnw.ethz.ch (ezges53d [130.60.20.135])
	by geo.umnw.ethz.ch (8.8.8/8.8.8) with ESMTP id RAA22725
	for <linux-mips@oss.sgi.com>; Tue, 13 Feb 2001 17:25:26 +0100 (MET)
Message-ID: <3A895FF4.B627089E@geo.umnw.ethz.ch>
Date:   Tue, 13 Feb 2001 17:25:25 +0100
From:   Stockli Reto <stockli@geo.umnw.ethz.ch>
Organization: Institute for Climate Research, ETH Zuerich
X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To:     linux-mips@oss.sgi.com
Subject: R10000 SGI O2
Content-Type: text/plain; charset=iso-8859-2
Content-Transfer-Encoding: 8bit
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing

I will give a try later to have my SGI O2 R10000 175MHz running Linux
and will report found problems and possible solutions. 

For not repeating here what has already been done:
Has anyone ever tried the same before and what are the problems to
encounter? I will most likely boot from a bootp linux server. Is there a
chance that I get a console on my O2 or do I only have a serial
connection.

Thanks for any nice introductory remarks!
Cheers,

Reto

-- 
Reto Stöckli				Bldg:   Uni Irchel  Room: 25 J53
Climate Research ETH			Phone:  +41 (0)1 635 5209
Winterthurerstrasse 190			Fax: 	+41 (0)1 362 5197
8057 Zürich 				Email:  stockli@geo.umnw.ethz.ch
Switzerland				Web:    http://www.geo.umnw.ethz.ch

From owner-linux-mips@oss.sgi.com Tue Feb 13 10:51:58 2001
Received:  by oss.sgi.com id <S553949AbRBMSvr>;
	Tue, 13 Feb 2001 10:51:47 -0800
Received: from delta.ds2.pg.gda.pl ([153.19.144.1]:29588 "EHLO
        delta.ds2.pg.gda.pl") by oss.sgi.com with ESMTP id <S553948AbRBMSvn>;
	Tue, 13 Feb 2001 10:51:43 -0800
Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id TAA00039;
	Tue, 13 Feb 2001 19:31:11 +0100 (MET)
Date:   Tue, 13 Feb 2001 19:31:11 +0100 (MET)
From:   "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To:     Jun Sun <jsun@mvista.com>
cc:     "Kevin D. Kissell" <kevink@mips.com>, linux-mips@oss.sgi.com
Subject: Re: config option vs. run-time detection (the debate continues ...)
In-Reply-To: <3A8829B9.17B7F691@mvista.com>
Message-ID: <Pine.GSO.3.96.1010213192415.20214H-100000@delta.ds2.pg.gda.pl>
Organization: Technical University of Gdansk
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing

On Mon, 12 Feb 2001, Jun Sun wrote:

> >  I don't have an FPU-less system and I can't check such code.  I need to
> > depend on others (I couldn't test all possible configurations anyway).
> 
> However, with CONFIG_HAS_FPU approach I know for sure it will work for any
> MIPS CPU, as long as the programmer specifies it correctly. :-)

 Tha latter being a BIG if.

> > If
> > we have a chance to get an exception we have to catch it, of course
> > (that's trivial to handle in Linux).
> > 
> 
> No effort (as in CONFIG_HAS_FPU approach) is still better than trivial or
> small effort ( as in run-time detection).  :-)

 Regardless of the CONFIG_HAS_FPU option you still need to check if a FPU
is present.

> I am very curious what makes you object to the CONFIG_HAS_FPU approach,
> especially you said earlier it was not about the inability to support both FPU
> and FPU-less CPUs with the same kernel image.

 That's pretty orthogonal -- I do not object the CONFIG_HAS_FPU option (I
even favor it, if it could save us unneeded bits), but whether having it
or not, we still have to properly detect FP hardware.  A silent crash or
an obscure oops is not an option in case of a config error.

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +


From owner-linux-mips@oss.sgi.com Tue Feb 13 16:41:59 2001
Received:  by oss.sgi.com id <S553991AbRBNAls>;
	Tue, 13 Feb 2001 16:41:48 -0800
Received: from sgigate.SGI.COM ([204.94.209.1]:4920 "EHLO dea.waldorf-gmbh.de")
	by oss.sgi.com with ESMTP id <S553987AbRBNAli>;
	Tue, 13 Feb 2001 16:41:38 -0800
Received: (from ralf@localhost)
	by dea.waldorf-gmbh.de (8.11.1/8.11.1) id f1D6IP806517;
	Mon, 12 Feb 2001 22:18:25 -0800
Date:   Mon, 12 Feb 2001 22:18:25 -0800
From:   Ralf Baechle <ralf@oss.sgi.com>
To:     Pete Popov <ppopov@mvista.com>
Cc:     carlson@sibyte.com,
        "linux-mips@oss.sgi.com" <linux-mips@oss.sgi.com>
Subject: Re: irq.c
Message-ID: <20010212221825.B2239@bacchus.dhis.org>
References: <3A843C2D.525643E7@mvista.com> <0102091101190P.01909@plugh.sibyte.com> <3A84400E.82CEA4B@mvista.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <3A84400E.82CEA4B@mvista.com>; from ppopov@mvista.com on Fri, Feb 09, 2001 at 11:07:58AM -0800
X-Accept-Language: de,en,fr
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing

On Fri, Feb 09, 2001 at 11:07:58AM -0800, Pete Popov wrote:

> Thanks for pointing that out.  If all architectures will move to
> kernel/irq.c, then it probably makes sense to wait.  At first glance,
> mips/kernel/irq.c seems pretty close to i386/kernel/irq.c -- certainly a
> lot closer than many of the other copies.  

It was derived from a fairly recent copy of the x86 irq.c; running out of
time I never completed the rewrite.  The idea is to implement some kind
of modular interrupt mechanism which allows us to have a single piece of
code in the MIPS kernel that knows how to handle i8259 interrupt, a single
piece of code to handle GT64120 interrupts etc.  Not like the current mess
which duplicates code ad infinitum.

Aside it's also going to make the RTLinux fraction happy.

  Ralf

From owner-linux-mips@oss.sgi.com Tue Feb 13 19:07:39 2001
Received:  by oss.sgi.com id <S554070AbRBNDHT>;
	Tue, 13 Feb 2001 19:07:19 -0800
Received: from rotor.chem.unr.edu ([134.197.32.176]:14349 "EHLO
        rotor.chem.unr.edu") by oss.sgi.com with ESMTP id <S554063AbRBNDHL>;
	Tue, 13 Feb 2001 19:07:11 -0800
Received: (from wesolows@localhost)
	by rotor.chem.unr.edu (8.9.3/8.9.3) id TAA29416;
	Tue, 13 Feb 2001 19:07:16 -0800
Date:   Tue, 13 Feb 2001 19:07:16 -0800
From:   Keith M Wesolowski <wesolows@chem.unr.edu>
To:     Stockli Reto <stockli@geo.umnw.ethz.ch>
Cc:     linux-mips@oss.sgi.com
Subject: Re: R10000 SGI O2
Message-ID: <20010213190716.A29070@chem.unr.edu>
References: <3A895FF4.B627089E@geo.umnw.ethz.ch>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2i
In-Reply-To: <3A895FF4.B627089E@geo.umnw.ethz.ch>; from stockli@geo.umnw.ethz.ch on Tue, Feb 13, 2001 at 05:25:25PM +0100
X-Complaints-To: postmaster@chem.unr.edu
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing

On Tue, Feb 13, 2001 at 05:25:25PM +0100, Stockli Reto wrote:

> I will give a try later to have my SGI O2 R10000 175MHz running Linux
> and will report found problems and possible solutions. 

Well, the most serious problem is known: that architecture isn't
supported.

> For not repeating here what has already been done:
> Has anyone ever tried the same before and what are the problems to
> encounter? I will most likely boot from a bootp linux server. Is there a
> chance that I get a console on my O2 or do I only have a serial
> connection.

There is no chance whatever that you will get anything.  If you want
to have any chance at all of getting this to work I would recommend
you ask Harald for his latest patch; it provides some level of support
for r5k-based IP32 (O2) systems.  r10k O2 suffers from the same
cache-noncoherency problem as r10k I2 does, and to the best of my
knowledge nobody has ever really tried to even boot one.

Not to discourage you at all...there's just a lot of work to do.

-- 
Keith M Wesolowski			wesolows@chem.unr.edu

From owner-linux-mips@oss.sgi.com Tue Feb 13 20:02:29 2001
Received:  by oss.sgi.com id <S554077AbRBNECU>;
	Tue, 13 Feb 2001 20:02:20 -0800
Received: from agile-50.OntheNet.com.au ([203.144.13.50]:35337 "EHLO
        surfers.oz.agile.tv") by oss.sgi.com with ESMTP id <S554073AbRBNECD>;
	Tue, 13 Feb 2001 20:02:03 -0800
Received: from agile.tv (IDENT:ldavies@tugun.oz.agile.tv [192.168.16.20])
	by surfers.oz.agile.tv (8.11.0/8.11.0) with ESMTP id f1E420V24839
	for <linux-mips@oss.sgi.com>; Wed, 14 Feb 2001 14:02:00 +1000
Message-ID: <3A8A02E6.9030408@agile.tv>
Date:   Wed, 14 Feb 2001 14:00:38 +1000
From:   Liam Davies <ldavies@agile.tv>
Reply-To: ldavies@oz.agile.tv
User-Agent: Mozilla/5.0 (X11; U; Linux 2.2.16-22 i686; en-US; m18) Gecko/20010131 Netscape6/6.01
X-Accept-Language: en
MIME-Version: 1.0
To:     linux-mips <linux-mips@oss.sgi.com>
Subject: Ooops in kmalloc from request_region
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing


I am currently at the stage of calling request_region in my irq_setup 
function.
The call to request_region does a kmalloc which oops. The box has 256Mb Ram.

Is this the right stage to be doing this call? Is there something that I 
have missed
in setting up the memory regions or paging?


Thanks
Liam Davies



Unable to handle kernel paging request at virtual address 10003278, epc 
== 80035314, ra == 800a1d60
Oops in fault.c:do_page_fault, line 172:


static void __init cobalt_irq_setup(void)
{
       set_cp0_status(ST0_IM, 0);

       set_except_vector(0, cobalt_handle_int);

---->> request_region(0xb0000020, 0x20, "pic1");
       request_region(0xb00000A0, 0x20, "pic2");
...


From owner-linux-mips@oss.sgi.com Wed Feb 14 04:44:03 2001
Received:  by oss.sgi.com id <S553881AbRBNMnw>;
	Wed, 14 Feb 2001 04:43:52 -0800
Received: from mail.sonytel.be ([193.74.243.200]:32931 "EHLO mail.sonytel.be")
	by oss.sgi.com with ESMTP id <S553720AbRBNMnf>;
	Wed, 14 Feb 2001 04:43:35 -0800
Received: from ginger.sonytel.be (ginger.sonytel.be [10.34.16.6])
	by mail.sonytel.be (8.9.0/8.8.6) with ESMTP id NAA25909
	for <linux-mips@oss.sgi.com>; Wed, 14 Feb 2001 13:43:02 +0100 (MET)
Received: (from tea@localhost)
	by ginger.sonytel.be (8.9.0/8.8.6) id NAA12606
	for linux-mips@oss.sgi.com; Wed, 14 Feb 2001 13:43:01 +0100 (MET)
Date:   Wed, 14 Feb 2001 13:43:01 +0100
From:   Tom Appermont <tea@sonycom.com>
To:     linux-mips@oss.sgi.com
Subject: no page fault on R5000?
Message-ID: <20010214134301.B12039@ginger.sonytel.be>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0i
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing


Howdy,
  
Is anybody running a 2.4.1 kernel on an R5000? I am currently
trying on a NEC ddb5074, but I'm not getting a page fault when
start_thread() is called for the init process...
  
Greetz,
  
Tom

-- 
................................................................
Tom Appermont                       SDCE
mailto: tom.appermont@sonycom.com   Sint Stevens Woluwestraat 55
tel: +32 2 7248620                  1130 Brussel
fax: +32 2 7262686                  Belgium

From owner-linux-mips@oss.sgi.com Wed Feb 14 05:16:53 2001
Received:  by oss.sgi.com id <S553908AbRBNNQn>;
	Wed, 14 Feb 2001 05:16:43 -0800
Received: from 108dsl063.dsl.micron.net ([206.207.108.63]:29286 "HELO
        ridgerun-lx.ridgerun.cxm") by oss.sgi.com with SMTP
	id <S553862AbRBNNQT>; Wed, 14 Feb 2001 05:16:19 -0800
Received: (qmail 6501 invoked from network); 14 Feb 2001 06:16:08 -0700
Received: from stevej-lx.ridgerun.cxm (HELO ridgerun.com) (stevej@192.168.1.4)
  by ridgerun-lx.ridgerun.cxm with SMTP; 14 Feb 2001 06:16:08 -0700
Message-ID: <3A8A8518.F66EBFA3@ridgerun.com>
Date:   Wed, 14 Feb 2001 06:16:08 -0700
From:   Steve Johnson <stevej@ridgerun.com>
Organization: Ridgerun, Inc.
X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.1-bigphys i686)
X-Accept-Language: en
MIME-Version: 1.0
To:     ldavies@oz.agile.tv
CC:     linux-mips <linux-mips@oss.sgi.com>
Subject: Re: Ooops in kmalloc from request_region
References: <3A8A02E6.9030408@agile.tv>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing

Liam,

    You can't call kmalloc that early in the startup process.  Look at main.c,
and init_IRQ comes before any of the memory initialization.

    Steve

Liam Davies wrote:

> I am currently at the stage of calling request_region in my irq_setup
> function.
> The call to request_region does a kmalloc which oops. The box has 256Mb Ram.
>
> Is this the right stage to be doing this call? Is there something that I
> have missed
> in setting up the memory regions or paging?
>


From owner-linux-mips@oss.sgi.com Wed Feb 14 05:21:12 2001
Received:  by oss.sgi.com id <S553994AbRBNNVD>;
	Wed, 14 Feb 2001 05:21:03 -0800
Received: from mail.sonytel.be ([193.74.243.200]:2219 "EHLO mail.sonytel.be")
	by oss.sgi.com with ESMTP id <S553906AbRBNNVC>;
	Wed, 14 Feb 2001 05:21:02 -0800
Received: from escobaria.sonytel.be (escobaria.sonytel.be [10.34.80.3])
	by mail.sonytel.be (8.9.0/8.8.6) with ESMTP id OAA27622;
	Wed, 14 Feb 2001 14:19:32 +0100 (MET)
Date:   Wed, 14 Feb 2001 14:19:31 +0100 (MET)
From:   Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com>
To:     Steve Johnson <stevej@ridgerun.com>
cc:     ldavies@oz.agile.tv, linux-mips <linux-mips@oss.sgi.com>
Subject: Re: Ooops in kmalloc from request_region
In-Reply-To: <3A8A8518.F66EBFA3@ridgerun.com>
Message-ID: <Pine.GSO.4.10.10102141418550.8142-100000@escobaria.sonytel.be>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing

On Wed, 14 Feb 2001, Steve Johnson wrote:
>     You can't call kmalloc that early in the startup process.  Look at main.c,
> and init_IRQ comes before any of the memory initialization.
> 
>     Steve
> 
> Liam Davies wrote:
> 
> > I am currently at the stage of calling request_region in my irq_setup
> > function.
> > The call to request_region does a kmalloc which oops. The box has 256Mb Ram.
> >
> > Is this the right stage to be doing this call? Is there something that I
> > have missed
> > in setting up the memory regions or paging?

Hence use request_resource() while passing a statically allocated and
initialized struct resource instead.

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven ------------- Sony Software Development Center Europe (SDCE)
Geert.Uytterhoeven@sonycom.com ------------------- Sint-Stevens-Woluwestraat 55
Voice +32-2-7248626 Fax +32-2-7262686 ---------------- B-1130 Brussels, Belgium


From owner-linux-mips@oss.sgi.com Wed Feb 14 09:04:25 2001
Received:  by oss.sgi.com id <S554003AbRBNREF>;
	Wed, 14 Feb 2001 09:04:05 -0800
Received: from [194.90.113.98] ([194.90.113.98]:27654 "EHLO
        yes.home.krftech.com") by oss.sgi.com with ESMTP id <S554000AbRBNRDs>;
	Wed, 14 Feb 2001 09:03:48 -0800
Received: from jungo.com (michaels@kobie.home.krftech.com [199.204.71.69])
	by yes.home.krftech.com (8.8.7/8.8.7) with ESMTP id UAA01024;
	Wed, 14 Feb 2001 20:08:35 +0200
From:   michaels@jungo.com
Message-ID: <3A8ABA30.1D42A067@jungo.com>
Date:   Wed, 14 Feb 2001 19:02:40 +0200
Organization: Jungo LTD
X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.17-21mdk i686)
X-Accept-Language: en
MIME-Version: 1.0
To:     "linux-mips@oss.sgi.com" <linux-mips@oss.sgi.com>,
        MIPS Support <support@mips.com>
Subject: MIPS R5Kc core configuration
Content-Type: text/plain; charset=koi8-r
Content-Transfer-Encoding: 7bit
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing

Hello,

I have recently started to work with the new R5Kc core from MIPS.
It is defined to be 64 Bit. I wonder if you know of other processors
that are also 64
bits that can be safely used for kernel configuration (R10000 maybe?).

Sincerely yours,
Michael Shmulevich
______________________________________
Software Developer
Jungo - R&D 
email: michaels@jungo.com
web: http://www.jungo.com
Phone: 1-877-514-0537(USA)  +972-9-8859365(Worldwide) ext. 233
Fax:   1-877-514-0538(USA)  +972-9-8859366(Worldwide)

From owner-linux-mips@oss.sgi.com Wed Feb 14 13:20:36 2001
Received:  by oss.sgi.com id <S554011AbRBNVUR>;
	Wed, 14 Feb 2001 13:20:17 -0800
Received: from sovereign.org ([209.180.91.170]:9118 "EHLO lux.homenet")
	by oss.sgi.com with ESMTP id <S554008AbRBNVUD>;
	Wed, 14 Feb 2001 13:20:03 -0800
Received: (from jfree@localhost)
	by lux.homenet (8.11.2/8.11.2/Debian 8.11.2-1) id f1ELKOM05658;
	Wed, 14 Feb 2001 14:20:24 -0700
From:   Jim Freeman <jfree@sovereign.org>
Date:   Wed, 14 Feb 2001 14:20:24 -0700
To:     linux-mips@oss.sgi.com, linux-mips@fnet.fr
Subject: bi-endian toolchain switches
Message-ID: <20010214142024.A5614@sovereign.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.3.12i
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing

For bi-endian cross-compiler toolchains, something akin to the following
patch can be helpful for setting endianness switches according to
CONFIG_CPU_LITTLE_ENDIAN :

	--- linux/arch/mips/Makefile	2001/02/14 21:04:31	1.1
	+++ linux/arch/mips/Makefile	2001/02/14 21:07:00
	@@ -18,9 +18,13 @@
	 ifdef CONFIG_CPU_LITTLE_ENDIAN
	 tool-prefix	= mipsel-linux-
	 output-format	= elf32-littlemips
	+export LD		= $(CROSS_COMPILE)ld -EL
	+export CC		= $(CROSS_COMPILE)cc -EL
	 else
	 tool-prefix	= mips-linux-
	 output-format	= elf32-bigmips
	+export LD		= $(CROSS_COMPILE)ld -EB
	+export CC		= $(CROSS_COMPILE)cc -EB
	 endif
	 
	 ifdef CONFIG_CROSSCOMPILE

From owner-linux-mips@oss.sgi.com Wed Feb 14 16:23:09 2001
Received:  by oss.sgi.com id <S554019AbRBOAW6>;
	Wed, 14 Feb 2001 16:22:58 -0800
Received: from ws149.wipro.com ([207.88.89.150]:35541 "EHLO
        santa.mail.wipro.com") by oss.sgi.com with ESMTP id <S554016AbRBOAWv>;
	Wed, 14 Feb 2001 16:22:51 -0800
Received: from webmail ([207.88.89.150]) by santa.mail.wipro.com
          (Netscape Messaging Server 3.6)  with SMTP id AAA7057;
          Wed, 14 Feb 2001 16:27:06 -0800
From:   deepa.suresh@wipro.com (Deepa  Suresh)
To:     linux-mips@oss.sgi.com
Cc:     deepa.suresh@wipro.com
X-Mailer: Netscape Messenger Express 3.5.2 [Mozilla/4.73 [en] (WinNT; I)]
Date:   Wed, 14 Feb 2001 16:27:06 -0800
Message-ID: <77452A3CA92.AAA7057@santa.mail.wipro.com>
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing


Hello,

We have a QED based MIPs processor, running Linux 2.4-test6. 
We use our own graphics card.
We want to get X/display up on this board. WE have a frame buffer driver
written
for the same card running on x86 Linux version and running X using
XFBDev server.

I want to know if we can reuse the same driver for mips also?
In the case of i386 Linux, fbcon.c and fbmem.c do most of the
processing before giving control to the corresponding graphics card.

In mips port can we use the same fbcon.c and fbmem.c functionality 
with our graphics driver. Is this enough for X to come up
without any problems. (i have seen sgi using newport_con , can we use
fb_con itself instead , what are the problems?)

I did see in the mailing list, someone mentioning using ATI graphics
card with the same hardware and running X. How was the frame buffer
driver modified?

Any help on this would be appreciated.

Thanks & Rgds
deepa






From owner-linux-mips@oss.sgi.com Thu Feb 15 03:05:47 2001
Received:  by oss.sgi.com id <S553709AbRBOLFh>;
	Thu, 15 Feb 2001 03:05:37 -0800
Received: from mail.sonytel.be ([193.74.243.200]:49871 "EHLO mail.sonytel.be")
	by oss.sgi.com with ESMTP id <S553687AbRBOLFK>;
	Thu, 15 Feb 2001 03:05:10 -0800
Received: from escobaria.sonytel.be (escobaria.sonytel.be [10.34.80.3])
	by mail.sonytel.be (8.9.0/8.8.6) with ESMTP id MAA03835;
	Thu, 15 Feb 2001 12:03:43 +0100 (MET)
Date:   Thu, 15 Feb 2001 12:03:43 +0100 (MET)
From:   Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com>
To:     Deepa Suresh <deepa.suresh@WIPRO.COM>
cc:     linux-mips@oss.sgi.com
Subject: Re: your mail
In-Reply-To: <77452A3CA92.AAA7057@santa.mail.wipro.com>
Message-ID: <Pine.GSO.4.10.10102151201280.10238-100000@escobaria.sonytel.be>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing

On Wed, 14 Feb 2001, Deepa  Suresh wrote:
> We have a QED based MIPs processor, running Linux 2.4-test6. 
> We use our own graphics card.
> We want to get X/display up on this board. WE have a frame buffer driver
> written
> for the same card running on x86 Linux version and running X using
> XFBDev server.

Does the frame buffer driver you wrote for x86 Linux relies on the card being
initialised by the video BIOS on the card? If not, it'll work out-of-the-box.
If yes, you'll have to make sure a similar initialization is done on the MIPS
platform.

> I want to know if we can reuse the same driver for mips also?
> In the case of i386 Linux, fbcon.c and fbmem.c do most of the
> processing before giving control to the corresponding graphics card.
> 
> In mips port can we use the same fbcon.c and fbmem.c functionality 
> with our graphics driver. Is this enough for X to come up
> without any problems. (i have seen sgi using newport_con , can we use
> fb_con itself instead , what are the problems?)

Fbmem and fbcon should work fine. They are not architecture specific.

And if these work, XF{68,86}_FBDev should work as well.

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven ------------- Sony Software Development Center Europe (SDCE)
Geert.Uytterhoeven@sonycom.com ------------------- Sint-Stevens-Woluwestraat 55
Voice +32-2-7248626 Fax +32-2-7262686 ---------------- B-1130 Brussels, Belgium


From owner-linux-mips@oss.sgi.com Thu Feb 15 08:16:59 2001
Received:  by oss.sgi.com id <S554020AbRBOQQi>;
	Thu, 15 Feb 2001 08:16:38 -0800
Received: from [194.90.113.98] ([194.90.113.98]:3335 "EHLO
        yes.home.krftech.com") by oss.sgi.com with ESMTP id <S553746AbRBOQQT>;
	Thu, 15 Feb 2001 08:16:19 -0800
Received: from jungo.com (michaels@kobie.home.krftech.com [199.204.71.69])
	by yes.home.krftech.com (8.8.7/8.8.7) with ESMTP id TAA04117;
	Thu, 15 Feb 2001 19:20:47 +0200
From:   michaels@jungo.com
Message-ID: <3A8C0079.9B8DDAA@jungo.com>
Date:   Thu, 15 Feb 2001 18:14:49 +0200
Organization: Jungo LTD
X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.17-21mdk i686)
X-Accept-Language: en
MIME-Version: 1.0
To:     Paul Kleist <paulk@mips.com>
CC:     "linux-mips@oss.sgi.com" <linux-mips@oss.sgi.com>
Subject: Re: MIPS R5Kc core configuration
References: <3A8ABA30.1D42A067@jungo.com> <3A8BCC28.32E9E240@mips.com>
Content-Type: text/plain; charset=koi8-r
Content-Transfer-Encoding: 7bit
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing

Paul,

What I meant is: when configuring linux for some specific MIPS CPU,
right now there is no MIPS64 CPU option (like there was MIPS32 for
Atlas), therefore I don't know what CPU configuration may be used for
5Kc core. 

Do we have an FPU? What are the permitted CP register operations, and
how do we set up the kernel for 64 bit architecture. I guess there were
another 64 bit CPUs that are configured like the LJA0004 MIPS-5KC that
is sitting on our Core board. 

Are you suggesting that QED's 5261 is a close shot?

Thanks,
Michael.

Paul Kleist wrote:
> 
> Hi Michael,
> 
> what do you mean by the phrase 'that can be used for kernel
> configuration' ?
> 
> You can look at eg. QED or NEC websites for other 64 bit mips
> processors, but they
> are not nescessarily identical implementations so do not be sure that
> you can use
> another processor instead of 5Kc which is a MIPS64 implementation.
> 
> The QED5261 is *close*, and we do have 200/100 MHz boards (core/bus
> freq) that can run
> on Atlas/Malta, and this cpuboard run our Linux also.
> 
> Regards
> Paul Kleist
> 
> michaels@jungo.com wrote:
> >
> > Hello,
> >
> > I have recently started to work with the new R5Kc core from MIPS.
> > It is defined to be 64 Bit. I wonder if you know of other processors
> > that are also 64
> > bits that can be safely used for kernel configuration (R10000 maybe?).
> 
> --
> _    _ ____  ___    Paul Kleist        Mailto:paulk@mips.com
> |\  /|||___)(___    MIPS Denmark       Direct: +45 44 86 55 43
> | \/ |||    ____)   Lautrupvang 4 B    Switch: +45 44 86 55 55
>   TECHNOLOGIES      DK-2750 Ballerup   Fax...: +45 44 86 55 56
>                     Denmark            http://www.mips.com/

-- 
Sincerely yours,
Michael Shmulevich
______________________________________
Software Developer
Jungo - R&D 
email: michaels@jungo.com
web: http://www.jungo.com
Phone: 1-877-514-0537(USA)  +972-9-8859365(Worldwide) ext. 233
Fax:   1-877-514-0538(USA)  +972-9-8859366(Worldwide)

From owner-linux-mips@oss.sgi.com Thu Feb 15 09:11:19 2001
Received:  by oss.sgi.com id <S553806AbRBORK7>;
	Thu, 15 Feb 2001 09:10:59 -0800
Received: from mx.mips.com ([206.31.31.226]:1169 "EHLO mx.mips.com")
	by oss.sgi.com with ESMTP id <S553735AbRBORK2>;
	Thu, 15 Feb 2001 09:10:28 -0800
Received: from newman.mips.com (ns-dmz [206.31.31.225])
	by mx.mips.com (8.9.3/8.9.0) with ESMTP id JAA05969;
	Thu, 15 Feb 2001 09:10:23 -0800 (PST)
Received: from Ulysses (ulysses [192.168.236.13])
	by newman.mips.com (8.9.3/8.9.0) with SMTP id JAA22693;
	Thu, 15 Feb 2001 09:10:20 -0800 (PST)
Message-ID: <00e101c09772$b65ba860$0deca8c0@Ulysses>
From:   "Kevin D. Kissell" <kevink@mips.com>
To:     <michaels@jungo.com>, "Paul Kleist" <paulk@mips.com>
Cc:     <linux-mips@oss.sgi.com>
References: <3A8ABA30.1D42A067@jungo.com> <3A8BCC28.32E9E240@mips.com> <3A8C0079.9B8DDAA@jungo.com>
Subject: Re: MIPS R5Kc core configuration
Date:   Thu, 15 Feb 2001 18:14:00 +0100
MIME-Version: 1.0
Content-Type: text/plain;
	charset="koi8-r"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing

The 5KC should run an 4KC MIPS32 kernel with
no modifications if you want to run in 32-bit "mode".
As far as 64-bit operation is concerned, the 5KC
gives you an option that the R4xxx and R5xxx do
not, which is to enable 64-bit load/store/math operations
without also enabling 64-bit addressing.  But the
UX/KX bits in the Status register have the same
semantics on the 5KC as on the 4xxx and R5xxx,
as do the 64-bit memory management registers
and exceptions.  Yes, the R5261 would be a pretty
close match, though not perfect:  The basic 5KC
has no FPU, and the 5KC cache geometry cannot
be assumed based on the PrID register, and should
be inferred from the Config registers in the same
manner as on a 4KC, though of course as an expedient
you can set the cache size/associativity for the 5KC
in the kernel source to correpsond to your Core
board CPU.

        Kevin K.

----- Original Message -----
From: <michaels@jungo.com>
To: "Paul Kleist" <paulk@mips.com>
Cc: <linux-mips@oss.sgi.com>
Sent: Thursday, February 15, 2001 5:14 PM
Subject: Re: MIPS R5Kc core configuration


> Paul,
>
> What I meant is: when configuring linux for some specific MIPS CPU,
> right now there is no MIPS64 CPU option (like there was MIPS32 for
> Atlas), therefore I don't know what CPU configuration may be used for
> 5Kc core.
>
> Do we have an FPU? What are the permitted CP register operations, and
> how do we set up the kernel for 64 bit architecture. I guess there were
> another 64 bit CPUs that are configured like the LJA0004 MIPS-5KC that
> is sitting on our Core board.
>
> Are you suggesting that QED's 5261 is a close shot?
>
> Thanks,
> Michael.
>
> Paul Kleist wrote:
> >
> > Hi Michael,
> >
> > what do you mean by the phrase 'that can be used for kernel
> > configuration' ?
> >
> > You can look at eg. QED or NEC websites for other 64 bit mips
> > processors, but they
> > are not nescessarily identical implementations so do not be sure that
> > you can use
> > another processor instead of 5Kc which is a MIPS64 implementation.
> >
> > The QED5261 is *close*, and we do have 200/100 MHz boards (core/bus
> > freq) that can run
> > on Atlas/Malta, and this cpuboard run our Linux also.
> >
> > Regards
> > Paul Kleist
> >
> > michaels@jungo.com wrote:
> > >
> > > Hello,
> > >
> > > I have recently started to work with the new R5Kc core from MIPS.
> > > It is defined to be 64 Bit. I wonder if you know of other processors
> > > that are also 64
> > > bits that can be safely used for kernel configuration (R10000 maybe?).
> >
> > --
> > _    _ ____  ___    Paul Kleist        Mailto:paulk@mips.com
> > |\  /|||___)(___    MIPS Denmark       Direct: +45 44 86 55 43
> > | \/ |||    ____)   Lautrupvang 4 B    Switch: +45 44 86 55 55
> >   TECHNOLOGIES      DK-2750 Ballerup   Fax...: +45 44 86 55 56
> >                     Denmark            http://www.mips.com/
>
> --
> Sincerely yours,
> Michael Shmulevich
> ______________________________________
> Software Developer
> Jungo - R&D
> email: michaels@jungo.com
> web: http://www.jungo.com
> Phone: 1-877-514-0537(USA)  +972-9-8859365(Worldwide) ext. 233
> Fax:   1-877-514-0538(USA)  +972-9-8859366(Worldwide)


From owner-linux-mips@oss.sgi.com Fri Feb 16 16:29:51 2001
Received:  by oss.sgi.com id <S553851AbRBQA3l>;
	Fri, 16 Feb 2001 16:29:41 -0800
Received: from woody.ichilton.co.uk ([216.29.174.40]:7943 "HELO
        woody.ichilton.co.uk") by oss.sgi.com with SMTP id <S553816AbRBQA3R>;
	Fri, 16 Feb 2001 16:29:17 -0800
Received: by woody.ichilton.co.uk (Postfix, from userid 1000)
	id DB1987D1B; Sat, 17 Feb 2001 00:29:29 +0000 (GMT)
Date:   Sat, 17 Feb 2001 00:29:29 +0000
From:   Ian Chilton <ian@ichilton.co.uk>
To:     linux-mips@oss.sgi.com
Subject: DECstation Hardware
Message-ID: <20010217002929.B24746@woody.ichilton.co.uk>
Reply-To: Ian Chilton <ian@ichilton.co.uk>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.3.12i
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing

Hello,

My MIPS boxes are SGI Big Endian machines, but I have been offered some
DECstation hardware for FREE, excpet for shipping costs.

I was wondering if someone working on the DECStation ports could tell
me what these are like, if they will run Linux yet, and if they are
worth shipping. I know nothing about this hardware, so as much info as
possible would be good :)

3 x Personal DEC station 5000/25
1 x Digital VAX station 4000 - 60
1 x DEC station 3100
2 x DEC station 2100
4 x DEC Storage Expansion (Disk)


Thanks!


Bye for Now,

Ian


                                \|||/ 
                                (o o)
 /---------------------------ooO-(_)-Ooo---------------------------\
 |  Ian Chilton        (IRC Nick - GadgetMan)     ICQ #: 16007717  |
 |-----------------------------------------------------------------|
 |  E-Mail: ian@ichilton.co.uk     Web: http://www.ichilton.co.uk  |
 |-----------------------------------------------------------------|
 |      For people who like peace and quiet: a phoneless cord      |
 \-----------------------------------------------------------------/


From owner-linux-mips@oss.sgi.com Fri Feb 16 18:00:41 2001
Received:  by oss.sgi.com id <S553683AbRBQCAb>;
	Fri, 16 Feb 2001 18:00:31 -0800
Received: from sgigate.SGI.COM ([204.94.209.1]:51881 "EHLO dea.waldorf-gmbh.de")
	by oss.sgi.com with ESMTP id <S553661AbRBQCAG>;
	Fri, 16 Feb 2001 18:00:06 -0800
Received: (from ralf@localhost)
	by dea.waldorf-gmbh.de (8.11.1/8.11.1) id f1H1x7803433;
	Fri, 16 Feb 2001 17:59:07 -0800
Date:   Fri, 16 Feb 2001 17:59:02 -0800
From:   Ralf Baechle <ralf@oss.sgi.com>
To:     Keith M Wesolowski <wesolows@chem.unr.edu>
Cc:     Stockli Reto <stockli@geo.umnw.ethz.ch>, linux-mips@oss.sgi.com
Subject: Re: R10000 SGI O2
Message-ID: <20010216175902.C2233@bacchus.dhis.org>
References: <3A895FF4.B627089E@geo.umnw.ethz.ch> <20010213190716.A29070@chem.unr.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <20010213190716.A29070@chem.unr.edu>; from wesolows@chem.unr.edu on Tue, Feb 13, 2001 at 07:07:16PM -0800
X-Accept-Language: de,en,fr
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing

On Tue, Feb 13, 2001 at 07:07:16PM -0800, Keith M Wesolowski wrote:

> > For not repeating here what has already been done:
> > Has anyone ever tried the same before and what are the problems to
> > encounter? I will most likely boot from a bootp linux server. Is there a
> > chance that I get a console on my O2 or do I only have a serial
> > connection.
> 
> There is no chance whatever that you will get anything.  If you want
> to have any chance at all of getting this to work I would recommend
> you ask Harald for his latest patch; it provides some level of support
> for r5k-based IP32 (O2) systems.  r10k O2 suffers from the same
> cache-noncoherency problem as r10k I2 does, and to the best of my
> knowledge nobody has ever really tried to even boot one.
> 
> Not to discourage you at all...there's just a lot of work to do.

It's really hard work to do.  R12000 O2s however should be much easier to
do; the processor feature which causes so much grief in the O2 can be
disabled there.

  Ralf

From owner-linux-mips@oss.sgi.com Sat Feb 17 01:39:14 2001
Received:  by oss.sgi.com id <S553742AbRBQJjE>;
	Sat, 17 Feb 2001 01:39:04 -0800
Received: from kuolema.Infodrom.North.DE ([195.27.69.163]:34825 "HELO
        kuolema.infodrom.north.de") by oss.sgi.com with SMTP
	id <S553663AbRBQJih>; Sat, 17 Feb 2001 01:38:37 -0800
Received: from finladia.infodrom.north.de (finlandia.Infodrom.North.DE [195.27.69.162])
	by kuolema.infodrom.north.de (Postfix) with ESMTP
	id C774F4D73F; Sat, 17 Feb 2001 10:37:14 +0100 (CET)
Received: by finladia.infodrom.north.de (Postfix, from userid 501)
	id 7949210983; Sat, 17 Feb 2001 10:36:34 +0100 (CET)
Date:   Sat, 17 Feb 2001 10:36:34 +0100
From:   Martin Schulze <joey@finlandia.infodrom.north.de>
To:     Ian Chilton <ian@ichilton.co.uk>
Cc:     linux-mips@oss.sgi.com
Subject: Re: DECstation Hardware
Message-ID: <20010217103634.M25990@finlandia.infodrom.north.de>
Reply-To: Martin Schulze <joey@infodrom.north.de>
References: <20010217002929.B24746@woody.ichilton.co.uk>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.3.12i
In-Reply-To: <20010217002929.B24746@woody.ichilton.co.uk>; from ian@ichilton.co.uk on Sat, Feb 17, 2001 at 12:29:29AM +0000
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing

Ian Chilton wrote:
> Hello,
> 
> My MIPS boxes are SGI Big Endian machines, but I have been offered some
> DECstation hardware for FREE, excpet for shipping costs.
> 
> I was wondering if someone working on the DECStation ports could tell
> me what these are like, if they will run Linux yet, and if they are
> worth shipping. I know nothing about this hardware, so as much info as
> possible would be good :)
> 
> 3 x Personal DEC station 5000/25
> 1 x Digital VAX station 4000 - 60
> 1 x DEC station 3100
> 2 x DEC station 2100

Maybe this helps:

From: http://decstation.unix-ag.org/status/

   System support status:
   System                                    Ethernet SCSI serial console TurboChannel keyboard/mouse
   DECstation 2100/3100                      yes      ?    yes            n/a          no
   Personal DECstation 5000/xx (20,25,33,50) yes      yes  yes            yes          yes
   DECstation 5000/1xx (120,125,133,150)     yes      yes  yes            yes          no
   DECstation 5000/200                       yes      yes  yes            yes          no
   DECstation 5000/240,/260                  yes      yes  yes            yes          no
   DECstation 5100                           ?        ?    ?              ?            ?

> 4 x DEC Storage Expansion (Disk)

These are just hard disk cases of 19" width for two 5 1/4" full height
disks.  Stacking them gives nice towers. :)

Regards,

	Joey

-- 
It's time to close the windows.

From owner-linux-mips@oss.sgi.com Sat Feb 17 02:25:55 2001
Received:  by oss.sgi.com id <S553736AbRBQKZp>;
	Sat, 17 Feb 2001 02:25:45 -0800
Received: from hermes.research.kpn.com ([139.63.192.8]:53767 "EHLO
        hermes.research.kpn.com") by oss.sgi.com with ESMTP
	id <S553645AbRBQKZf>; Sat, 17 Feb 2001 02:25:35 -0800
Received: from sparta.research.kpn.com (sparta.research.kpn.com [139.63.192.6])
 by research.kpn.com (PMDF V5.2-31 #42699)
 with ESMTP id <01K07R6NTFO6000E6N@research.kpn.com> for
 linux-mips@oss.sgi.com; Sat, 17 Feb 2001 11:25:33 +0100
Received: (from karel@localhost)	by sparta.research.kpn.com (8.8.8+Sun/8.8.8)
 id LAA13892; Sat, 17 Feb 2001 11:25:32 +0100 (MET)
X-URL:  http://www-lsdm.research.kpn.com/~karel
Date:   Sat, 17 Feb 2001 11:25:32 +0100 (MET)
From:   Karel van Houten <K.H.C.vanHouten@research.kpn.com>
Subject: Re: DECstation Hardware
In-reply-to: <20010217002929.B24746@woody.ichilton.co.uk>
To:     ian@ichilton.co.uk
Cc:     linux-mips@oss.sgi.com
Message-id: <200102171025.LAA13892@sparta.research.kpn.com>
MIME-version: 1.0
X-Mailer: ELM [version 2.5 PL2]
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7bit
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing

Hi Ian,

You wrote:
> My MIPS boxes are SGI Big Endian machines, but I have been offered some
> DECstation hardware for FREE, excpet for shipping costs.
> 
> I was wondering if someone working on the DECStation ports could tell
> me what these are like, if they will run Linux yet, and if they are
> worth shipping. I know nothing about this hardware, so as much info as
> possible would be good :)
> 
> 3 x Personal DEC station 5000/25
> 1 x Digital VAX station 4000 - 60
> 1 x DEC station 3100
> 2 x DEC station 2100
> 4 x DEC Storage Expansion (Disk)

As I told you in a private mail some time ago ;-),
all info about linux on DECStations can be found at:
http://www.xs4all.nl/~vhouten/mipsel

The 5000/25 should work OK, the 2100/3100 might have some problems
with the current kernels.
The VAX station is not a MIPS cpu, but a vax.

-- 
Karel van Houten

----------------------------------------------------------
The box said "Requires Windows 95 or better."
I can't understand why it won't work on my Linux computer. 
----------------------------------------------------------

From owner-linux-mips@oss.sgi.com Sat Feb 17 13:27:17 2001
Received:  by oss.sgi.com id <S553747AbRBQV1I>;
	Sat, 17 Feb 2001 13:27:08 -0800
Received: from pobox.sibyte.com ([208.12.96.20]:60690 "HELO pobox.sibyte.com")
	by oss.sgi.com with SMTP id <S553650AbRBQV0q>;
	Sat, 17 Feb 2001 13:26:46 -0800
Received: from postal.sibyte.com (moat.sibyte.com [208.12.96.21])
	by pobox.sibyte.com (Postfix) with SMTP id F3E91205FB
	for <linux-mips@oss.sgi.com>; Sat, 17 Feb 2001 13:26:31 -0800 (PST)
Received: from SMTP agent by mail gateway 
 Sat, 17 Feb 2001 13:20:15 -0800
Received: from plugh.sibyte.com (plugh.sibyte.com [10.21.64.158])
	by postal.sibyte.com (Postfix) with ESMTP id B19D81595F
	for <linux-mips@oss.sgi.com>; Sat, 17 Feb 2001 13:26:31 -0800 (PST)
Received: by plugh.sibyte.com (Postfix, from userid 61017)
	id 8FE2B686D; Sat, 17 Feb 2001 13:27:16 -0800 (PST)
From:   Justin Carlson <carlson@sibyte.com>
Reply-To: carlson@sibyte.com
Organization: Sibyte
To:     linux-mips@oss.sgi.com
Subject: saved_command_line, arcs_cmdline, command_line
Date:   Sat, 17 Feb 2001 13:11:27 -0800
X-Mailer: KMail [version 1.0.29]
Content-Type: text/plain
MIME-Version: 1.0
Message-Id: <0102171327160R.15790@plugh.sibyte.com>
Content-Transfer-Encoding: 8bit
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing


I'm scanning over the command line arguments stuff, and noted a few things. 
Comments welcome.

Is there any reason saved_command_line is not architecture neutral?  Seems like
it should live in init/main.c, if anywhere.

Why do we have arcs_cmdline[] *AND* command_line[]?  Is there any respect in
which this isn't completely redundant?   (And misnamed, for that matter, for
non-arcs boards?)

-Justin


From owner-linux-mips@oss.sgi.com Sun Feb 18 11:00:32 2001
Received:  by oss.sgi.com id <S553769AbRBRTAY>;
	Sun, 18 Feb 2001 11:00:24 -0800
Received: from mta6.snfc21.pbi.net ([206.13.28.240]:56214 "EHLO
        mta6.snfc21.pbi.net") by oss.sgi.com with ESMTP id <S553788AbRBRS77>;
	Sun, 18 Feb 2001 10:59:59 -0800
Received: from pacbell.net ([63.194.214.47])
 by mta6.snfc21.pbi.net (Sun Internet Mail Server sims.3.5.2000.01.05.12.18.p9)
 with ESMTP id <0G8Y00076V6UMG@mta6.snfc21.pbi.net> for linux-mips@oss.sgi.com;
 Sun, 18 Feb 2001 10:54:30 -0800 (PST)
Date:   Sun, 18 Feb 2001 10:58:07 -0800
From:   ppopov@pacbell.net
Subject: redhat 7.0
To:     "linux-mips@oss.sgi.com" <linux-mips@oss.sgi.com>
Message-id: <3A901B3F.ADADC601@pacbell.net>
MIME-version: 1.0
X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.18 i686)
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7bit
X-Accept-Language: bg, en
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing


Has anyone tried installing 7.0 that's on oss.sgi.com?  The problem I'm
running into is that after I netboot and mount simple-0.2b as the root
fs, and install the rpm-4.0 tarball, rpm doesn't work with the
libraries, or lack of, of that root fs.  It looks like I need an fs with
a working rpm-4.0, so that I can mount my second disk somewhere and
install the 7.0 packages.  Any suggestions?

Pete

From owner-linux-mips@oss.sgi.com Mon Feb 19 00:50:10 2001
Received:  by oss.sgi.com id <S553790AbRBSItv>;
	Mon, 19 Feb 2001 00:49:51 -0800
Received: from ezksun.unizh.ch ([130.60.20.131]:7044 "EHLO geo.umnw.ethz.ch")
	by oss.sgi.com with ESMTP id <S553784AbRBSIts>;
	Mon, 19 Feb 2001 00:49:48 -0800
Received: from geo.umnw.ethz.ch (ezges53d [130.60.20.135])
	by geo.umnw.ethz.ch (8.8.8/8.8.8) with ESMTP id JAA04368;
	Mon, 19 Feb 2001 09:49:45 +0100 (MET)
Message-ID: <3A90DE28.FCDE8CB8@geo.umnw.ethz.ch>
Date:   Mon, 19 Feb 2001 09:49:44 +0100
From:   Stockli Reto <stockli@geo.umnw.ethz.ch>
Organization: Institute for Climate Research, ETH Zuerich
X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To:     Ralf Baechle <ralf@oss.sgi.com>
CC:     Keith M Wesolowski <wesolows@chem.unr.edu>, linux-mips@oss.sgi.com
Subject: Re: R10000 SGI O2
References: <3A895FF4.B627089E@geo.umnw.ethz.ch> <20010213190716.A29070@chem.unr.edu> <20010216175902.C2233@bacchus.dhis.org>
Content-Type: text/plain; charset=iso-8859-2
Content-Transfer-Encoding: 7bit
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing

Hi There

> 
> On Tue, Feb 13, 2001 at 07:07:16PM -0800, Keith M Wesolowski wrote:
> 
> > > For not repeating here what has already been done:
> > > Has anyone ever tried the same before and what are the problems to
> > > encounter? I will most likely boot from a bootp linux server. Is there a
> > > chance that I get a console on my O2 or do I only have a serial
> > > connection.
> >
> > There is no chance whatever that you will get anything.  If you want
> > to have any chance at all of getting this to work I would recommend
> > you ask Harald for his latest patch; it provides some level of support
> > for r5k-based IP32 (O2) systems.  r10k O2 suffers from the same
> > cache-noncoherency problem as r10k I2 does, and to the best of my
> > knowledge nobody has ever really tried to even boot one.
> >
> > Not to discourage you at all...there's just a lot of work to do.
> 
> It's really hard work to do.  R12000 O2s however should be much easier to
> do; the processor feature which causes so much grief in the O2 can be
> disabled there.
> 
>   Ralf

Thanks Keith and Ralf for your information on running a R10000 O2 with
Linux. I knew that the video and sound HW as well as some of the
machine's graphics features were not supported by any linux drivers,
because it's even hard on SGI/Irix to find useful documentation about
this hardware! I guess this is the point why so few developers have
programmed applications that would take advantage of the very nice
capabilities of the machine.

So, I still would like to contribute something to the implementation of
Linux on SGI machines and I have this O2 standing on my desk. I have
installed and maintained some I386 based linux systems, but am not
really into fixing kernels. As I see there's no kernel that will boot
rightaway (with or without screen console). Let me know if the situation
is hopeless or if I can make a step taking a current mips-kernel (any
specific R10000-patch around there?) and start to consult R10000/ SGI O2
manuals.

It would be nice, but maybe I'm too much on the admin/user side and for
sure I am not into developing kernels. Anyway, curious I am...

Cheers,
Reto

From owner-linux-mips@oss.sgi.com Mon Feb 19 05:34:42 2001
Received:  by oss.sgi.com id <S553837AbRBSNeb>;
	Mon, 19 Feb 2001 05:34:31 -0800
Received: from home174.liacs.nl ([132.229.210.174]:16134 "EHLO
        fog.mors.wiggy.net") by oss.sgi.com with ESMTP id <S553815AbRBSNeL>;
	Mon, 19 Feb 2001 05:34:11 -0800
Received: (from wichert@localhost)
	by fog.mors.wiggy.net (8.11.2/8.11.2/Debian 8.11.2-1) id f1JDBUg17443
	for linux-mips@oss.sgi.com; Mon, 19 Feb 2001 14:11:30 +0100
Date:   Mon, 19 Feb 2001 14:11:30 +0100
From:   Wichert Akkerman <wichert@cistron.nl>
To:     linux-mips@oss.sgi.com
Subject: strace sysmips support (was: Re: [FIX] sysmips(MIPS_ATMIC_SET, ...) ret_from_sys_call vs. o32_ret_from_sys_call)
Message-ID: <20010219141130.C17354@cistron.nl>
Mail-Followup-To: linux-mips@oss.sgi.com
References: <20010124163048.B15348@paradigm.rfc822.org> <20010124165919.C15348@paradigm.rfc822.org> <20010125165530.B12576@paradigm.rfc822.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.3.15i
In-Reply-To: <20010125165530.B12576@paradigm.rfc822.org>; from flo@rfc822.org on Thu, Jan 25, 2001 at 04:55:31PM +0100
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing

Previously Florian Lohoff wrote:
> From the strace i find
> 
> sysmips(0x7d1, 0x2ac95d24, 0x1, 0)      = 4149

FWIW, I've just put code in strace CVS to decode this properly. Looking
in my (stock Linus) kerneltree I noticed the sys_sysmips code assumes
it can get away with converting an int to a char*, which seems like a
wrong assumption to me..

I don't have my indy up and running at the moment, so the code is
completely untested. Feedback is welcomed :)

Wichert.

-- 
  _________________________________________________________________
 /       Nothing is fool-proof to a sufficiently talented fool     \
| wichert@cistron.nl                  http://www.liacs.nl/~wichert/ |
| 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0  2805 3CB8 9250 2FA3 BC2D |

From owner-linux-mips@oss.sgi.com Mon Feb 19 05:35:11 2001
Received:  by oss.sgi.com id <S553841AbRBSNew>;
	Mon, 19 Feb 2001 05:34:52 -0800
Received: from home174.liacs.nl ([132.229.210.174]:16134 "EHLO
        fog.mors.wiggy.net") by oss.sgi.com with ESMTP id <S553832AbRBSNeh>;
	Mon, 19 Feb 2001 05:34:37 -0800
Received: (from wichert@localhost)
	by fog.mors.wiggy.net (8.11.2/8.11.2/Debian 8.11.2-1) id f1JCYMH17405;
	Mon, 19 Feb 2001 13:34:22 +0100
Date:   Mon, 19 Feb 2001 13:34:22 +0100
From:   Wichert Akkerman <wichert@cistron.nl>
To:     "'linux-mips@oss.sgi.com'" <linux-mips@oss.sgi.com>,
        linux-mips <linux-mips@fnet.fr>
Subject: Re: strace package
Message-ID: <20010219133422.B17354@cistron.nl>
Mail-Followup-To: "'linux-mips@oss.sgi.com'" <linux-mips@oss.sgi.com>,
	linux-mips <linux-mips@fnet.fr>
References: <3A5E75C4.2020203@redhat.com> <3A5E7F3A.4BD57AC5@mvista.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.3.15i
In-Reply-To: <3A5E7F3A.4BD57AC5@mvista.com>; from jsun@mvista.com on Thu, Jan 11, 2001 at 07:51:22PM -0800
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing

Previously Jun Sun wrote:
> strace is included in the MontaVista HHL distribution.  You can find the rpm
> and srpm under ftp.mvista.com/pub/CDK?? and/or ftp.mvista.com/pub/area51.

Do you happen to know if those have any patches that are not already in
CVS?

Wichert.

-- 
  _________________________________________________________________
 /       Nothing is fool-proof to a sufficiently talented fool     \
| wichert@cistron.nl                  http://www.liacs.nl/~wichert/ |
| 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0  2805 3CB8 9250 2FA3 BC2D |

From owner-linux-mips@oss.sgi.com Mon Feb 19 05:35:42 2001
Received:  by oss.sgi.com id <S553842AbRBSNfV>;
	Mon, 19 Feb 2001 05:35:21 -0800
Received: from home174.liacs.nl ([132.229.210.174]:18182 "EHLO
        fog.mors.wiggy.net") by oss.sgi.com with ESMTP id <S553823AbRBSNfR>;
	Mon, 19 Feb 2001 05:35:17 -0800
Received: (from wichert@localhost)
	by fog.mors.wiggy.net (8.11.2/8.11.2/Debian 8.11.2-1) id f1JCXk617400;
	Mon, 19 Feb 2001 13:33:46 +0100
Date:   Mon, 19 Feb 2001 13:33:46 +0100
From:   Wichert Akkerman <wichert@cistron.nl>
To:     "'linux-mips@oss.sgi.com'" <linux-mips@oss.sgi.com>,
        linux-mips <linux-mips@fnet.fr>
Subject: Re: strace package
Message-ID: <20010219133346.A17354@cistron.nl>
Mail-Followup-To: "'linux-mips@oss.sgi.com'" <linux-mips@oss.sgi.com>,
	linux-mips <linux-mips@fnet.fr>
References: <20010116134453.B12858@bacchus.dhis.org> <Pine.GSO.3.96.1010116171558.5546M-100000@delta.ds2.pg.gda.pl>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.3.15i
In-Reply-To: <Pine.GSO.3.96.1010116171558.5546M-100000@delta.ds2.pg.gda.pl>; from macro@ds2.pg.gda.pl on Tue, Jan 16, 2001 at 05:18:46PM +0100
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing

Previously Maciej W. Rozycki wrote:
>  Well, here is most of the information available from the site...
> 
>                  Welcome to http://strace.sourceforge.net/
> 
>       We're Sorry but this Project hasn't yet uploaded their personal
>                                 webpage yet.
>           Please check back soon for updates or visit SourceForge

Hmm, I guess I should fix that :)

I've started looking at strace again after not having had any time for
it in a while, and strace 4.3 should appear in a week or so. If there
are any problems with the MIPS support now is the time to tell me.
I'm especially interesting in strace reporting umoven() errors while
tracing a program.

Wichert.

-- 
  _________________________________________________________________
 /       Nothing is fool-proof to a sufficiently talented fool     \
| wichert@cistron.nl                  http://www.liacs.nl/~wichert/ |
| 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0  2805 3CB8 9250 2FA3 BC2D |

From owner-linux-mips@oss.sgi.com Mon Feb 19 11:42:45 2001
Received:  by oss.sgi.com id <S553854AbRBSTmZ>;
	Mon, 19 Feb 2001 11:42:25 -0800
Received: from yacht.ee.fit.edu ([163.118.137.187]:9186 "EHLO yacht.ee.fit.edu")
	by oss.sgi.com with ESMTP id <S553793AbRBSTmL>;
	Mon, 19 Feb 2001 11:42:11 -0800
Received: from localhost (altine@localhost)
	by yacht.ee.fit.edu (8.9.1b+Sun/8.9.1) with ESMTP id OAA13587
	for <linux-mips@oss.sgi.com>; Mon, 19 Feb 2001 14:52:10 -0500 (EST)
Date:   Mon, 19 Feb 2001 14:52:10 -0500 (EST)
From:   Can Altineller <altine@ee.fit.edu>
X-Sender: altine@yacht
To:     linux-mips@oss.sgi.com
Subject: newbie question.
In-Reply-To: <20010219141130.C17354@cistron.nl>
Message-ID: <Pine.GSO.4.05.10102191449510.13560-100000@yacht>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing


	Hello;

	I got an Indy 4600SC with 64Megs of memory, and I dont feel like
running Irix on it. What is the status of the sgi port port of linux. Is
there a distro available? Also, I dont have a floppy in my indy, so can I
net boot? If someone point me out in the correct way, I will be very
happy.

	Thanks.
	-C.A.



From owner-linux-mips@oss.sgi.com Mon Feb 19 20:42:22 2001
Received:  by oss.sgi.com id <S553795AbRBTEmM>;
	Mon, 19 Feb 2001 20:42:12 -0800
Received: from agile-50.OntheNet.com.au ([203.144.13.50]:34316 "EHLO
        surfers.oz.agile.tv") by oss.sgi.com with ESMTP id <S553772AbRBTElr>;
	Mon, 19 Feb 2001 20:41:47 -0800
Received: from agile.tv (IDENT:ldavies@tugun.oz.agile.tv [192.168.16.20])
	by surfers.oz.agile.tv (8.11.0/8.11.0) with ESMTP id f1K4fjV26637;
	Tue, 20 Feb 2001 14:41:45 +1000
Message-ID: <3A91F56F.9020603@agile.tv>
Date:   Tue, 20 Feb 2001 14:41:19 +1000
From:   Liam Davies <ldavies@agile.tv>
Reply-To: ldavies@oz.agile.tv
User-Agent: Mozilla/5.0 (X11; U; Linux 2.2.16-22 i686; en-US; m18) Gecko/20010131 Netscape6/6.01
X-Accept-Language: en
MIME-Version: 1.0
To:     linux-mips <linux-mips@oss.sgi.com>
Subject: pci io remapping and ide_ioreg_t
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing

I have an old (2.0.x) ide driver that used to hard code the 
hwif->io_ports up to the 0x100001f0-0x100001f7 range. This is now broken 
in the 2.4 kernel since ide_ioreg_t has changed from unsigned long to 
unsigned short.

What is the mechanism for reaching these ports now?


Thanks
Liam


From owner-linux-mips@oss.sgi.com Mon Feb 19 23:37:13 2001
Received:  by oss.sgi.com id <S553896AbRBTHhE>;
	Mon, 19 Feb 2001 23:37:04 -0800
Received: from boco.fee.vutbr.cz ([147.229.9.11]:61198 "EHLO boco.fee.vutbr.cz")
	by oss.sgi.com with ESMTP id <S553869AbRBTHgu>;
	Mon, 19 Feb 2001 23:36:50 -0800
Received: from fest.stud.fee.vutbr.cz (fest.stud.fee.vutbr.cz [147.229.9.16])
	by boco.fee.vutbr.cz (8.11.2/8.11.2) with ESMTP id f1K7agA07256
	(using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK);
	Tue, 20 Feb 2001 08:36:47 +0100 (CET)
Received: (from xjezda00@localhost)
	by fest.stud.fee.vutbr.cz (8.11.2/8.11.2) id f1K6n4n68739;
	Tue, 20 Feb 2001 07:49:04 +0100 (CET)
Date:   Tue, 20 Feb 2001 07:49:04 +0100
From:   David Jez <dave.jez@seznam.cz>
To:     ppopov@pacbell.net
Cc:     linux-mips@oss.sgi.com
Subject: Re: redhat 7.0
Message-ID: <20010220074903.A68652@stud.fee.vutbr.cz>
References: <3A901B3F.ADADC601@pacbell.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <3A901B3F.ADADC601@pacbell.net>; from ppopov@pacbell.net on Sun, Feb 18, 2001 at 10:58:07AM -0800
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing

On Sun, Feb 18, 2001 at 10:58:07AM -0800, ppopov@pacbell.net wrote:
> 
> Has anyone tried installing 7.0 that's on oss.sgi.com?  The problem I'm
> running into is that after I netboot and mount simple-0.2b as the root
> fs, and install the rpm-4.0 tarball, rpm doesn't work with the
> libraries, or lack of, of that root fs.  It looks like I need an fs with
> a working rpm-4.0, so that I can mount my second disk somewhere and
> install the 7.0 packages.  Any suggestions?
Yes,
If you download rpm-3.0 (I'm not sure, try get newer version) you'll should
be able to work with rpm 4 packages.

> 
> Pete

Best regards,
Dave
-- 
-------------------------------------------------------
  David "Dave" Jez                Brno, CZ, Europe
 E-mail: dave.jez@seznam.cz
PGP key: finger xjezda00@fest.stud.fee.vutbr.cz
---------=[ ~EOF ]=------------------------------------

From owner-linux-mips@oss.sgi.com Mon Feb 19 23:37:23 2001
Received:  by oss.sgi.com id <S553894AbRBTHhN>;
	Mon, 19 Feb 2001 23:37:13 -0800
Received: from boco.fee.vutbr.cz ([147.229.9.11]:61454 "EHLO boco.fee.vutbr.cz")
	by oss.sgi.com with ESMTP id <S553892AbRBTHgv>;
	Mon, 19 Feb 2001 23:36:51 -0800
Received: from fest.stud.fee.vutbr.cz (fest.stud.fee.vutbr.cz [147.229.9.16])
	by boco.fee.vutbr.cz (8.11.2/8.11.2) with ESMTP id f1K7agC07256
	(using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK);
	Tue, 20 Feb 2001 08:36:47 +0100 (CET)
Received: (from xjezda00@localhost)
	by fest.stud.fee.vutbr.cz (8.11.2/8.11.2) id f1K76AN69127;
	Tue, 20 Feb 2001 08:06:10 +0100 (CET)
Date:   Tue, 20 Feb 2001 08:06:10 +0100
From:   David Jez <dave.jez@seznam.cz>
To:     Can Altineller <altine@ee.fit.edu>
Cc:     linux-mips@oss.sgi.com
Subject: Re: newbie question.
Message-ID: <20010220080610.A69044@stud.fee.vutbr.cz>
References: <20010219141130.C17354@cistron.nl> <Pine.GSO.4.05.10102191449510.13560-100000@yacht>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <Pine.GSO.4.05.10102191449510.13560-100000@yacht>; from altine@ee.fit.edu on Mon, Feb 19, 2001 at 02:52:10PM -0500
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing

On Mon, Feb 19, 2001 at 02:52:10PM -0500, Can Altineller wrote:
> 
> 	Hello;
> 
> 	I got an Indy 4600SC with 64Megs of memory, and I dont feel like
> running Irix on it. What is the status of the sgi port port of linux. Is
> there a distro available? Also, I dont have a floppy in my indy, so can I
> net boot? If someone point me out in the correct way, I will be very
> happy.
Hi,

Try download doc & faqs & tutorials & distro from:

ftp://ftp.oss.sgi.com/pub/linux/mips

or RedHat from:

ftp://ftp.oss.sgi.com/pub/linux/mips/redhat

PS: Don't worry about instalation. In directory redhat you can find Getting
started and README. Read it carefully. If you search archive of this conf. you
can find thread about netbooting Indy ( bootp():/vmlinuz ) from PROM monitor
and setting bootpd in linux boot server.
> 
> 	Thanks.
> 	-C.A.
> 
> 
Best Regards,
Dave

-- 
-------------------------------------------------------
  David "Dave" Jez                Brno, CZ, Europe
 E-mail: dave.jez@seznam.cz
PGP key: finger xjezda00@fest.stud.fee.vutbr.cz
---------=[ ~EOF ]=------------------------------------

From owner-linux-mips@oss.sgi.com Tue Feb 20 00:54:23 2001
Received:  by oss.sgi.com id <S554083AbRBTIyO>;
	Tue, 20 Feb 2001 00:54:14 -0800
Received: from mail.sonytel.be ([193.74.243.200]:22004 "EHLO mail.sonytel.be")
	by oss.sgi.com with ESMTP id <S553902AbRBTIxz>;
	Tue, 20 Feb 2001 00:53:55 -0800
Received: from escobaria.sonytel.be (escobaria.sonytel.be [10.34.80.3])
	by mail.sonytel.be (8.9.0/8.8.6) with ESMTP id JAA23505;
	Tue, 20 Feb 2001 09:52:57 +0100 (MET)
Date:   Tue, 20 Feb 2001 09:52:53 +0100 (MET)
From:   Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com>
To:     ldavies@oz.agile.tv
cc:     linux-mips <linux-mips@oss.sgi.com>
Subject: Re: pci io remapping and ide_ioreg_t
In-Reply-To: <3A91F56F.9020603@agile.tv>
Message-ID: <Pine.GSO.4.10.10102200952300.4626-100000@escobaria.sonytel.be>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing

On Tue, 20 Feb 2001, Liam Davies wrote:
> I have an old (2.0.x) ide driver that used to hard code the 
> hwif->io_ports up to the 0x100001f0-0x100001f7 range. This is now broken 
> in the 2.4 kernel since ide_ioreg_t has changed from unsigned long to 
> unsigned short.
> 
> What is the mechanism for reaching these ports now?

Change ide_ioreg_t back to unsigned long? ide_ioreg_t is arch specific.

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven ------------- Sony Software Development Center Europe (SDCE)
Geert.Uytterhoeven@sonycom.com ------------------- Sint-Stevens-Woluwestraat 55
Voice +32-2-7248626 Fax +32-2-7262686 ---------------- B-1130 Brussels, Belgium


From owner-linux-mips@oss.sgi.com Tue Feb 20 11:28:36 2001
Received:  by oss.sgi.com id <S553898AbRBTT20>;
	Tue, 20 Feb 2001 11:28:26 -0800
Received: from u-12-18.karlsruhe.ipdial.viaginterkom.de ([62.180.18.12]:22254
        "EHLO dea.waldorf-gmbh.de") by oss.sgi.com with ESMTP
	id <S553829AbRBTT2V>; Tue, 20 Feb 2001 11:28:21 -0800
Received: (from ralf@localhost)
	by dea.waldorf-gmbh.de (8.11.1/8.11.1) id f1J2pJk02022;
	Mon, 19 Feb 2001 03:51:19 +0100
Date:   Sun, 18 Feb 2001 20:51:19 -0600
From:   Ralf Baechle <ralf@oss.sgi.com>
To:     Jim Freeman <jfree@sovereign.org>
Cc:     linux-mips@oss.sgi.com, linux-mips@fnet.fr
Subject: Re: bi-endian toolchain switches
Message-ID: <20010218205119.C1644@bacchus.dhis.org>
References: <20010214142024.A5614@sovereign.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <20010214142024.A5614@sovereign.org>; from jfree@sovereign.org on Wed, Feb 14, 2001 at 02:20:24PM -0700
X-Accept-Language: de,en,fr
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing

On Wed, Feb 14, 2001 at 02:20:24PM -0700, Jim Freeman wrote:

> For bi-endian cross-compiler toolchains, something akin to the following
> patch can be helpful for setting endianness switches according to
> CONFIG_CPU_LITTLE_ENDIAN :

We don't do this because -EB and -EL options don't affect the default
SEARCH_DIR statements in the default linker scripts yet we have to get
ld searching these directories without additional options.  In other words
multilib support is less than perfect ...

  Ralf

From owner-linux-mips@oss.sgi.com Tue Feb 20 11:29:16 2001
Received:  by oss.sgi.com id <S553907AbRBTT3G>;
	Tue, 20 Feb 2001 11:29:06 -0800
Received: from u-12-18.karlsruhe.ipdial.viaginterkom.de ([62.180.18.12]:23790
        "EHLO dea.waldorf-gmbh.de") by oss.sgi.com with ESMTP
	id <S553865AbRBTT25>; Tue, 20 Feb 2001 11:28:57 -0800
Received: (from ralf@localhost)
	by dea.waldorf-gmbh.de (8.11.1/8.11.1) id f1J2Wom01959;
	Mon, 19 Feb 2001 03:32:50 +0100
Date:   Sun, 18 Feb 2001 20:32:50 -0600
From:   Ralf Baechle <ralf@oss.sgi.com>
To:     Justin Carlson <carlson@sibyte.com>
Cc:     linux-mips@oss.sgi.com
Subject: Re: saved_command_line, arcs_cmdline, command_line
Message-ID: <20010218203250.B1644@bacchus.dhis.org>
References: <0102171327160R.15790@plugh.sibyte.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <0102171327160R.15790@plugh.sibyte.com>; from carlson@sibyte.com on Sat, Feb 17, 2001 at 01:11:27PM -0800
X-Accept-Language: de,en,fr
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing

On Sat, Feb 17, 2001 at 01:11:27PM -0800, Justin Carlson wrote:

> I'm scanning over the command line arguments stuff, and noted a few things. 
> Comments welcome.
> 
> Is there any reason saved_command_line is not architecture neutral?  Seems
> like it should live in init/main.c, if anywhere.
> 
> Why do we have arcs_cmdline[] *AND* command_line[]?  Is there any respect in
> which this isn't completely redundant?   (And misnamed, for that matter, for
> non-arcs boards?)

The ARC firmware has the stupid habit of passing in all the environment
variables as part of the command line when makes them look to the kernel
like kernel options.  So prom_init_cmdline() filters the names of those
variables which get passed by the firmware.  So what actually should happen
is removing arcs_cmdline from setup.c.

  Ralf

From owner-linux-mips@oss.sgi.com Tue Feb 20 12:27:47 2001
Received:  by oss.sgi.com id <S553762AbRBTU1h>;
	Tue, 20 Feb 2001 12:27:37 -0800
Received: from saturn.mikemac.com ([216.99.199.88]:35076 "EHLO
        saturn.mikemac.com") by oss.sgi.com with ESMTP id <S553744AbRBTU1Q>;
	Tue, 20 Feb 2001 12:27:16 -0800
Received: from Saturn (localhost [127.0.0.1])
	by saturn.mikemac.com (8.9.3/8.9.3) with ESMTP id MAA28680;
	Tue, 20 Feb 2001 12:26:11 -0800
Message-Id: <200102202026.MAA28680@saturn.mikemac.com>
To:     David Jez <dave.jez@seznam.cz>
cc:     Can Altineller <altine@ee.fit.edu>, linux-mips@oss.sgi.com
Subject: Re: newbie question. 
In-Reply-To: Your message of "Tue, 20 Feb 2001 08:06:10 +0100."
             <20010220080610.A69044@stud.fee.vutbr.cz> 
Date:   Tue, 20 Feb 2001 12:26:11 -0800
From:   Mike McDonald <mikemac@mikemac.com>
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing


>Date:   Tue, 20 Feb 2001 08:06:10 +0100
>From: David Jez <dave.jez@seznam.cz>
>To: Can Altineller <altine@ee.fit.edu>
>Subject: Re: newbie question.
>
>On Mon, Feb 19, 2001 at 02:52:10PM -0500, Can Altineller wrote:
>> 
>> 	Hello;
>> 
>> 	I got an Indy 4600SC with 64Megs of memory, and I dont feel like
>> running Irix on it. What is the status of the sgi port port of linux. Is
>> there a distro available? Also, I dont have a floppy in my indy, so can I
>> net boot? If someone point me out in the correct way, I will be very
>> happy.
>Hi,
>
>Try download doc & faqs & tutorials & distro from:
>
>ftp://ftp.oss.sgi.com/pub/linux/mips

  Actually, it's ftp://oss.sgi.com/pub/linux/mips but I can't find any
FAQs or tutorials there. http://oss.sgi.com/mips/ has some more info.
(I've heard there's a FAQ someplace but I've never found it.)


  Mike McDonald
  mikemac@mikemac.com

From owner-linux-mips@oss.sgi.com Tue Feb 20 12:31:08 2001
Received:  by oss.sgi.com id <S553767AbRBTUa6>;
	Tue, 20 Feb 2001 12:30:58 -0800
Received: from ns.snowman.net ([63.80.4.34]:63500 "EHLO ns.snowman.net")
	by oss.sgi.com with ESMTP id <S553761AbRBTUar>;
	Tue, 20 Feb 2001 12:30:47 -0800
Received: from localhost (nick@localhost)
	by ns.snowman.net (8.9.3/8.9.3/Debian 8.9.3-21) with ESMTP id PAA15190;
	Tue, 20 Feb 2001 15:30:07 -0500
Date:   Tue, 20 Feb 2001 15:30:07 -0500 (EST)
From:   <nick@snowman.net>
X-Sender: nick@ns
To:     Mike McDonald <mikemac@mikemac.com>
cc:     David Jez <dave.jez@seznam.cz>, Can Altineller <altine@ee.fit.edu>,
        linux-mips@oss.sgi.com
Subject: Re: newbie question. 
In-Reply-To: <200102202026.MAA28680@saturn.mikemac.com>
Message-ID: <Pine.LNX.4.21.0102201529510.10973-100000@ns>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing

www.foobazco.org is the faq I have used.
	Nick

On Tue, 20 Feb 2001, Mike McDonald wrote:

> 
> >Date:   Tue, 20 Feb 2001 08:06:10 +0100
> >From: David Jez <dave.jez@seznam.cz>
> >To: Can Altineller <altine@ee.fit.edu>
> >Subject: Re: newbie question.
> >
> >On Mon, Feb 19, 2001 at 02:52:10PM -0500, Can Altineller wrote:
> >> 
> >> 	Hello;
> >> 
> >> 	I got an Indy 4600SC with 64Megs of memory, and I dont feel like
> >> running Irix on it. What is the status of the sgi port port of linux. Is
> >> there a distro available? Also, I dont have a floppy in my indy, so can I
> >> net boot? If someone point me out in the correct way, I will be very
> >> happy.
> >Hi,
> >
> >Try download doc & faqs & tutorials & distro from:
> >
> >ftp://ftp.oss.sgi.com/pub/linux/mips
> 
>   Actually, it's ftp://oss.sgi.com/pub/linux/mips but I can't find any
> FAQs or tutorials there. http://oss.sgi.com/mips/ has some more info.
> (I've heard there's a FAQ someplace but I've never found it.)
> 
> 
>   Mike McDonald
>   mikemac@mikemac.com
> 


From owner-linux-mips@oss.sgi.com Tue Feb 20 12:37:57 2001
Received:  by oss.sgi.com id <S553771AbRBTUhi>;
	Tue, 20 Feb 2001 12:37:38 -0800
Received: from u-12-18.karlsruhe.ipdial.viaginterkom.de ([62.180.18.12]:55790
        "EHLO dea.waldorf-gmbh.de") by oss.sgi.com with ESMTP
	id <S553766AbRBTUhU>; Tue, 20 Feb 2001 12:37:20 -0800
Received: (from ralf@localhost)
	by dea.waldorf-gmbh.de (8.11.1/8.11.1) id f1KKb3h04162;
	Tue, 20 Feb 2001 21:37:03 +0100
Date:   Tue, 20 Feb 2001 21:37:03 +0100
From:   Ralf Baechle <ralf@oss.sgi.com>
To:     "'linux-mips@oss.sgi.com'" <linux-mips@oss.sgi.com>,
        linux-mips <linux-mips@fnet.fr>
Subject: Re: strace package
Message-ID: <20010220213703.B2086@bacchus.dhis.org>
References: <20010116134453.B12858@bacchus.dhis.org> <Pine.GSO.3.96.1010116171558.5546M-100000@delta.ds2.pg.gda.pl> <20010219133346.A17354@cistron.nl>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <20010219133346.A17354@cistron.nl>; from wichert@cistron.nl on Mon, Feb 19, 2001 at 01:33:46PM +0100
X-Accept-Language: de,en,fr
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing

On Mon, Feb 19, 2001 at 01:33:46PM +0100, Wichert Akkerman wrote:

> Hmm, I guess I should fix that :)
> 
> I've started looking at strace again after not having had any time for
> it in a while, and strace 4.3 should appear in a week or so. If there
> are any problems with the MIPS support now is the time to tell me.
> I'm especially interesting in strace reporting umoven() errors while
> tracing a program.

Conincidentally I today built strace-cvs for MIPS before receiving your
message and found it to be working just fine.  The only bug which my
last several month old build from an older snapshot doesn't have is
that syscall 4129 (from memory, number may be incorrect) gets decoded
as a syscall with very many arguments (~ 20).  Will have to look into
it.

  Ralf

From owner-linux-mips@oss.sgi.com Tue Feb 20 12:42:08 2001
Received:  by oss.sgi.com id <S553850AbRBTUl6>;
	Tue, 20 Feb 2001 12:41:58 -0800
Received: from u-12-18.karlsruhe.ipdial.viaginterkom.de ([62.180.18.12]:57838
        "EHLO dea.waldorf-gmbh.de") by oss.sgi.com with ESMTP
	id <S553768AbRBTUll>; Tue, 20 Feb 2001 12:41:41 -0800
Received: (from ralf@localhost)
	by dea.waldorf-gmbh.de (8.11.1/8.11.1) id f1KKfPE04203
	for linux-mips@oss.sgi.com; Tue, 20 Feb 2001 21:41:25 +0100
Date:   Tue, 20 Feb 2001 21:41:25 +0100
From:   Ralf Baechle <ralf@oss.sgi.com>
To:     linux-mips@oss.sgi.com
Subject: Re: strace sysmips support (was: Re: [FIX] sysmips(MIPS_ATMIC_SET, ...) ret_from_sys_call vs. o32_ret_from_sys_call)
Message-ID: <20010220214125.C2086@bacchus.dhis.org>
References: <20010124163048.B15348@paradigm.rfc822.org> <20010124165919.C15348@paradigm.rfc822.org> <20010125165530.B12576@paradigm.rfc822.org> <20010219141130.C17354@cistron.nl>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <20010219141130.C17354@cistron.nl>; from wichert@cistron.nl on Mon, Feb 19, 2001 at 02:11:30PM +0100
X-Accept-Language: de,en,fr
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing

On Mon, Feb 19, 2001 at 02:11:30PM +0100, Wichert Akkerman wrote:

> > sysmips(0x7d1, 0x2ac95d24, 0x1, 0)      = 4149
> 
> FWIW, I've just put code in strace CVS to decode this properly. Looking
> in my (stock Linus) kerneltree I noticed the sys_sysmips code assumes
> it can get away with converting an int to a char*, which seems like a
> wrong assumption to me..
> 
> I don't have my indy up and running at the moment, so the code is
> completely untested. Feedback is welcomed :)

Some versions of the kernel were simply not return anything usefull, so
the the value in $v0 stayed unchanged; 4149 is the syscall number of
sysmips(2).

  Ralf

From owner-linux-mips@oss.sgi.com Tue Feb 20 12:52:28 2001
Received:  by oss.sgi.com id <S553870AbRBTUwI>;
	Tue, 20 Feb 2001 12:52:08 -0800
Received: from u-12-18.karlsruhe.ipdial.viaginterkom.de ([62.180.18.12]:62958
        "EHLO dea.waldorf-gmbh.de") by oss.sgi.com with ESMTP
	id <S553853AbRBTUv4>; Tue, 20 Feb 2001 12:51:56 -0800
Received: (from ralf@localhost)
	by dea.waldorf-gmbh.de (8.11.1/8.11.1) id f1KKpI704304;
	Tue, 20 Feb 2001 21:51:18 +0100
Date:   Tue, 20 Feb 2001 21:51:18 +0100
From:   Ralf Baechle <ralf@oss.sgi.com>
To:     ldavies@oz.agile.tv
Cc:     linux-mips <linux-mips@oss.sgi.com>
Subject: Re: pci io remapping and ide_ioreg_t
Message-ID: <20010220215118.D2086@bacchus.dhis.org>
References: <3A91F56F.9020603@agile.tv>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <3A91F56F.9020603@agile.tv>; from ldavies@agile.tv on Tue, Feb 20, 2001 at 02:41:19PM +1000
X-Accept-Language: de,en,fr
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing

On Tue, Feb 20, 2001 at 02:41:19PM +1000, Liam Davies wrote:

> I have an old (2.0.x) ide driver that used to hard code the 
> hwif->io_ports up to the 0x100001f0-0x100001f7 range. This is now broken 
> in the 2.4 kernel since ide_ioreg_t has changed from unsigned long to 
> unsigned short.
> 
> What is the mechanism for reaching these ports now?

Consider this size of ide_ioreg_t a glitch; most current MIPS designs
have their IDE ports in outer space.  It shouldn't break anything, so
until somebody is going to cry I'll change it to unsigned long.

  Ralf

From owner-linux-mips@oss.sgi.com Tue Feb 20 12:55:08 2001
Received:  by oss.sgi.com id <S553876AbRBTUy7>;
	Tue, 20 Feb 2001 12:54:59 -0800
Received: from u-12-18.karlsruhe.ipdial.viaginterkom.de ([62.180.18.12]:65006
        "EHLO dea.waldorf-gmbh.de") by oss.sgi.com with ESMTP
	id <S553866AbRBTUyo>; Tue, 20 Feb 2001 12:54:44 -0800
Received: (from ralf@localhost)
	by dea.waldorf-gmbh.de (8.11.1/8.11.1) id f1KKrt704342;
	Tue, 20 Feb 2001 21:53:55 +0100
Date:   Tue, 20 Feb 2001 21:53:55 +0100
From:   Ralf Baechle <ralf@oss.sgi.com>
To:     Mike McDonald <mikemac@mikemac.com>
Cc:     David Jez <dave.jez@seznam.cz>, Can Altineller <altine@ee.fit.edu>,
        linux-mips@oss.sgi.com
Subject: Re: newbie question.
Message-ID: <20010220215355.E2086@bacchus.dhis.org>
References: <20010220080610.A69044@stud.fee.vutbr.cz> <200102202026.MAA28680@saturn.mikemac.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <200102202026.MAA28680@saturn.mikemac.com>; from mikemac@mikemac.com on Tue, Feb 20, 2001 at 12:26:11PM -0800
X-Accept-Language: de,en,fr
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing

On Tue, Feb 20, 2001 at 12:26:11PM -0800, Mike McDonald wrote:

>   Actually, it's ftp://oss.sgi.com/pub/linux/mips but I can't find any
> FAQs or tutorials there. http://oss.sgi.com/mips/ has some more info.
> (I've heard there's a FAQ someplace but I've never found it.)

Write 100 times: http://oss.sgi.com/mips/mips-howto.html ;-)

  Ralf

From owner-linux-mips@oss.sgi.com Tue Feb 20 12:57:08 2001
Received:  by oss.sgi.com id <S553887AbRBTU46>;
	Tue, 20 Feb 2001 12:56:58 -0800
Received: from u-12-18.karlsruhe.ipdial.viaginterkom.de ([62.180.18.12]:1007
        "EHLO dea.waldorf-gmbh.de") by oss.sgi.com with ESMTP
	id <S553873AbRBTU4t>; Tue, 20 Feb 2001 12:56:49 -0800
Received: (from ralf@localhost)
	by dea.waldorf-gmbh.de (8.11.1/8.11.1) id f1KKuG504374;
	Tue, 20 Feb 2001 21:56:16 +0100
Date:   Tue, 20 Feb 2001 21:56:16 +0100
From:   Ralf Baechle <ralf@oss.sgi.com>
To:     David Jez <dave.jez@seznam.cz>
Cc:     ppopov@pacbell.net, linux-mips@oss.sgi.com
Subject: Re: redhat 7.0
Message-ID: <20010220215616.F2086@bacchus.dhis.org>
References: <3A901B3F.ADADC601@pacbell.net> <20010220074903.A68652@stud.fee.vutbr.cz>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <20010220074903.A68652@stud.fee.vutbr.cz>; from dave.jez@seznam.cz on Tue, Feb 20, 2001 at 07:49:04AM +0100
X-Accept-Language: de,en,fr
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing

On Tue, Feb 20, 2001 at 07:49:04AM +0100, David Jez wrote:

> > Has anyone tried installing 7.0 that's on oss.sgi.com?  The problem I'm
> > running into is that after I netboot and mount simple-0.2b as the root
> > fs, and install the rpm-4.0 tarball, rpm doesn't work with the
> > libraries, or lack of, of that root fs.  It looks like I need an fs with
> > a working rpm-4.0, so that I can mount my second disk somewhere and
> > install the 7.0 packages.  Any suggestions?
> Yes,
> If you download rpm-3.0 (I'm not sure, try get newer version) you'll should
> be able to work with rpm 4 packages.

Oss has a tarball with statically linked rpm 4 binaries.  Use that to
convert your rpm database and then install the rpm 4 rpm package for real.

  Ralf

From owner-linux-mips@oss.sgi.com Tue Feb 20 16:25:19 2001
Received:  by oss.sgi.com id <S553929AbRBUAZJ>;
	Tue, 20 Feb 2001 16:25:09 -0800
Received: from gateway-1237.mvista.com ([12.44.186.158]:1531 "EHLO
        hermes.mvista.com") by oss.sgi.com with ESMTP id <S553788AbRBUAYx>;
	Tue, 20 Feb 2001 16:24:53 -0800
Received: from mvista.com (IDENT:ppopov@zeus.mvista.com [10.0.0.112])
	by hermes.mvista.com (8.11.0/8.11.0) with ESMTP id f1L0Km824721;
	Tue, 20 Feb 2001 16:20:48 -0800
Message-ID: <3A930AB3.3AEAE5BF@mvista.com>
Date:   Tue, 20 Feb 2001 16:24:19 -0800
From:   Pete Popov <ppopov@mvista.com>
Organization: Monta Vista Software
X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.17 i586)
X-Accept-Language: en, bg
MIME-Version: 1.0
To:     Ralf Baechle <ralf@oss.sgi.com>
CC:     David Jez <dave.jez@seznam.cz>, ppopov@pacbell.net,
        linux-mips@oss.sgi.com
Subject: Re: redhat 7.0
References: <3A901B3F.ADADC601@pacbell.net> <20010220074903.A68652@stud.fee.vutbr.cz> <20010220215616.F2086@bacchus.dhis.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing

Ralf Baechle wrote:
> 
> On Tue, Feb 20, 2001 at 07:49:04AM +0100, David Jez wrote:
> 
> > > Has anyone tried installing 7.0 that's on oss.sgi.com?  The problem I'm
> > > running into is that after I netboot and mount simple-0.2b as the root
> > > fs, and install the rpm-4.0 tarball, rpm doesn't work with the
> > > libraries, or lack of, of that root fs.  It looks like I need an fs with
> > > a working rpm-4.0, so that I can mount my second disk somewhere and
> > > install the 7.0 packages.  Any suggestions?
> > Yes,
> > If you download rpm-3.0 (I'm not sure, try get newer version) you'll should
> > be able to work with rpm 4 packages.
> 
> Oss has a tarball with statically linked rpm 4 binaries.  Use that to
> convert your rpm database and then install the rpm 4 rpm package for real.

I tried that; "rpm --rebuilddb" failed because it couldn't find some
library.  I'll try again.

Pete

From owner-linux-mips@oss.sgi.com Tue Feb 20 16:59:10 2001
Received:  by oss.sgi.com id <S553942AbRBUA7A>;
	Tue, 20 Feb 2001 16:59:00 -0800
Received: from davinci.artisan.calpoly.edu ([129.65.60.31]:45063 "EHLO
        davinci.artisan.calpoly.edu") by oss.sgi.com with ESMTP
	id <S553935AbRBUA6r>; Tue, 20 Feb 2001 16:58:47 -0800
Received: from localhost (root@localhost)
	by davinci.artisan.calpoly.edu (8.8.6 (PHNE_17135)/8.8.6) with SMTP id QAA23121
	for linux-mips@oss.sgi.com; Tue, 20 Feb 2001 16:58:02 -0800 (PST)
From:   cgut@calpoly.edu
X-OpenMail-Hops: 1
Date:   Tue, 20 Feb 2001 16:57:56 -0800
Message-Id: <H0005e15069dcdd2@MHS>
In-Reply-To: <3A930AB3.3AEAE5BF@mvista.com>
Subject: Linux on Origin 200 (newbie)
MIME-Version: 1.0
TO:     linux-mips@oss.sgi.com
Content-Type: text/plain; charset=US-ASCII
Content-Disposition: inline
Content-Transfer-Encoding: 7bit
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing

Hello,

I'm an absolutely MIPS newbie and before screwing up anything, I wanted to ask
if ever someone tried to install Linux on a Origin 200 Machine?

Chris


From owner-linux-mips@oss.sgi.com Tue Feb 20 17:03:40 2001
Received:  by oss.sgi.com id <S553947AbRBUBD3>;
	Tue, 20 Feb 2001 17:03:29 -0800
Received: from saturn.mikemac.com ([216.99.199.88]:55300 "EHLO
        saturn.mikemac.com") by oss.sgi.com with ESMTP id <S553679AbRBUBDH>;
	Tue, 20 Feb 2001 17:03:07 -0800
Received: from Saturn (localhost [127.0.0.1])
	by saturn.mikemac.com (8.9.3/8.9.3) with ESMTP id RAA32502;
	Tue, 20 Feb 2001 17:03:04 -0800
Message-Id: <200102210103.RAA32502@saturn.mikemac.com>
To:     cgut@calpoly.edu
cc:     linux-mips@oss.sgi.com
Subject: Re: Linux on Origin 200 (newbie) 
In-Reply-To: Your message of "Tue, 20 Feb 2001 16:57:56 PST."
             <H0005e15069dcdd2@MHS> 
Date:   Tue, 20 Feb 2001 17:03:03 -0800
From:   Mike McDonald <mikemac@mikemac.com>
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing


>From: cgut@calpoly.edu
>Date:   Tue, 20 Feb 2001 16:57:56 -0800
>Subject: Linux on Origin 200 (newbie)
>
>Hello,
>
>I'm an absolutely MIPS newbie and before screwing up anything, I wanted to ask
>if ever someone tried to install Linux on a Origin 200 Machine?
>
>Chris

  See the howto at http://oss.sgi.com/mips/mips-howto.html. :-)

  Mike McDonald
  mikemac@mikemac.com

From owner-linux-mips@oss.sgi.com Tue Feb 20 17:09:09 2001
Received:  by oss.sgi.com id <S553950AbRBUBJA>;
	Tue, 20 Feb 2001 17:09:00 -0800
Received: from ns.snowman.net ([63.80.4.34]:30478 "EHLO ns.snowman.net")
	by oss.sgi.com with ESMTP id <S553940AbRBUBIk>;
	Tue, 20 Feb 2001 17:08:40 -0800
Received: from localhost (nick@localhost)
	by ns.snowman.net (8.9.3/8.9.3/Debian 8.9.3-21) with ESMTP id UAA19995;
	Tue, 20 Feb 2001 20:08:03 -0500
Date:   Tue, 20 Feb 2001 20:08:03 -0500 (EST)
From:   <nick@snowman.net>
X-Sender: nick@ns
To:     cgut@calpoly.edu
cc:     linux-mips@oss.sgi.com
Subject: Re: Linux on Origin 200 (newbie)
In-Reply-To: <H0005e15069dcdd2@MHS>
Message-ID: <Pine.LNX.4.21.0102202007480.19261-100000@ns>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing

Yes.  It may or may not work . It does not work on my O200.
	Nick

On Tue, 20 Feb 2001 cgut@calpoly.edu wrote:

> Hello,
> 
> I'm an absolutely MIPS newbie and before screwing up anything, I wanted to ask
> if ever someone tried to install Linux on a Origin 200 Machine?
> 
> Chris
> 


From owner-linux-mips@oss.sgi.com Wed Feb 21 04:31:44 2001
Received:  by oss.sgi.com id <S553736AbRBUMbe>;
	Wed, 21 Feb 2001 04:31:34 -0800
Received: from u-18-20.karlsruhe.ipdial.viaginterkom.de ([62.180.20.18]:30960
        "EHLO dea.waldorf-gmbh.de") by oss.sgi.com with ESMTP
	id <S553648AbRBUMbL>; Wed, 21 Feb 2001 04:31:11 -0800
Received: (from ralf@localhost)
	by dea.waldorf-gmbh.de (8.11.1/8.11.1) id f1L7COU07832;
	Wed, 21 Feb 2001 08:12:24 +0100
Date:   Wed, 21 Feb 2001 08:12:24 +0100
From:   Ralf Baechle <ralf@oss.sgi.com>
To:     Pete Popov <ppopov@mvista.com>
Cc:     David Jez <dave.jez@seznam.cz>, ppopov@pacbell.net,
        linux-mips@oss.sgi.com
Subject: Re: redhat 7.0
Message-ID: <20010221081224.A7767@bacchus.dhis.org>
References: <3A901B3F.ADADC601@pacbell.net> <20010220074903.A68652@stud.fee.vutbr.cz> <20010220215616.F2086@bacchus.dhis.org> <3A930AB3.3AEAE5BF@mvista.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <3A930AB3.3AEAE5BF@mvista.com>; from ppopov@mvista.com on Tue, Feb 20, 2001 at 04:24:19PM -0800
X-Accept-Language: de,en,fr
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing

On Tue, Feb 20, 2001 at 04:24:19PM -0800, Pete Popov wrote:

> > Oss has a tarball with statically linked rpm 4 binaries.  Use that to
> > convert your rpm database and then install the rpm 4 rpm package for real.
> 
> I tried that; "rpm --rebuilddb" failed because it couldn't find some
> library.  I'll try again.

Hmm...  I know I went through the procedure when I upgraded posix0 from
5.1 to 7.0, so it's definately to get to work even though it definately
was hairy beyond Joe Average Sysadmin's skills.  Maybe you'll also have to
dump a copy of glibc into the to-be updates system or use the --root
option.  Somebody will have to figure out a reasonably easy to follow
and safe procedure here.

  Ralf

From owner-linux-mips@oss.sgi.com Wed Feb 21 04:38:44 2001
Received:  by oss.sgi.com id <S553769AbRBUMie>;
	Wed, 21 Feb 2001 04:38:34 -0800
Received: from u-18-20.karlsruhe.ipdial.viaginterkom.de ([62.180.20.18]:33776
        "EHLO dea.waldorf-gmbh.de") by oss.sgi.com with ESMTP
	id <S553719AbRBUMiV>; Wed, 21 Feb 2001 04:38:21 -0800
Received: (from ralf@localhost)
	by dea.waldorf-gmbh.de (8.11.1/8.11.1) id f1L6kcV07687;
	Wed, 21 Feb 2001 07:46:38 +0100
Date:   Wed, 21 Feb 2001 07:46:38 +0100
From:   Ralf Baechle <ralf@oss.sgi.com>
To:     <nick@snowman.net>
Cc:     cgut@calpoly.edu, linux-mips@oss.sgi.com
Subject: Re: Linux on Origin 200 (newbie)
Message-ID: <20010221074638.B7335@bacchus.dhis.org>
References: <H0005e15069dcdd2@MHS> <Pine.LNX.4.21.0102202007480.19261-100000@ns>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <Pine.LNX.4.21.0102202007480.19261-100000@ns>; from nick@snowman.net on Tue, Feb 20, 2001 at 08:08:03PM -0500
X-Accept-Language: de,en,fr
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing

On Tue, Feb 20, 2001 at 08:08:03PM -0500, nick@snowman.net wrote:

> Yes.  It may or may not work . It does not work on my O200.

Latest theory is that we have a problem which is related to different
versions of various chips of the system.  When it's actually running on
an Origin 200 / 2000 then it's also very reliable.

Aside of that the current list of open bugs for the Origin 200 / 2000 is:

 - we don't have FPU emulation code
 - the performance of the ioc3-eth driver is weak to say the least
 - ioc3-eth doesn't handle autonegotiation correctly
 - the binary compatibility code for running 32-bit apps is less than perfect.
 - we crash on systems with more than 64 processors.  Yes dudes, that's
   tested on real world hardware :-)

  Ralf

From owner-linux-mips@oss.sgi.com Wed Feb 21 04:39:45 2001
Received:  by oss.sgi.com id <S553784AbRBUMje>;
	Wed, 21 Feb 2001 04:39:34 -0800
Received: from u-18-20.karlsruhe.ipdial.viaginterkom.de ([62.180.20.18]:34544
        "EHLO dea.waldorf-gmbh.de") by oss.sgi.com with ESMTP
	id <S553747AbRBUMjO>; Wed, 21 Feb 2001 04:39:14 -0800
Received: (from ralf@localhost)
	by dea.waldorf-gmbh.de (8.11.1/8.11.1) id f1L6C9K07567;
	Wed, 21 Feb 2001 07:12:09 +0100
Date:   Wed, 21 Feb 2001 07:12:09 +0100
From:   Ralf Baechle <ralf@oss.sgi.com>
To:     Stockli Reto <stockli@geo.umnw.ethz.ch>
Cc:     Keith M Wesolowski <wesolows@chem.unr.edu>, linux-mips@oss.sgi.com
Subject: Re: R10000 SGI O2
Message-ID: <20010221071209.A7335@bacchus.dhis.org>
References: <3A895FF4.B627089E@geo.umnw.ethz.ch> <20010213190716.A29070@chem.unr.edu> <20010216175902.C2233@bacchus.dhis.org> <3A90DE28.FCDE8CB8@geo.umnw.ethz.ch>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <3A90DE28.FCDE8CB8@geo.umnw.ethz.ch>; from stockli@geo.umnw.ethz.ch on Mon, Feb 19, 2001 at 09:49:44AM +0100
X-Accept-Language: de,en,fr
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing

Gruezi,

On Mon, Feb 19, 2001 at 09:49:44AM +0100, Stockli Reto wrote:

> Thanks Keith and Ralf for your information on running a R10000 O2 with
> Linux. I knew that the video and sound HW as well as some of the
> machine's graphics features were not supported by any linux drivers,
> because it's even hard on SGI/Irix to find useful documentation about
> this hardware! I guess this is the point why so few developers have
> programmed applications that would take advantage of the very nice
> capabilities of the machine.

You're mixing two completly different things.  SGI never released hardware
programming information for the O2 to the general public.  The graphics
APIs however have been published and there is a ton more good reasons to
stick with those like those APIs beying consistent beyond just the O2 and
even SGI platforms.

> So, I still would like to contribute something to the implementation of
> Linux on SGI machines and I have this O2 standing on my desk. I have
> installed and maintained some I386 based linux systems, but am not
> really into fixing kernels. As I see there's no kernel that will boot
> rightaway (with or without screen console). Let me know if the situation
> is hopeless or if I can make a step taking a current mips-kernel (any
> specific R10000-patch around there?) and start to consult R10000/ SGI O2
> manuals.

Only the mips64 kernel has R10000 support.  Anyway you want to use the
mips64 kernel as an O2 can have more memory than 32-bit kernel can handle.

> It would be nice, but maybe I'm too much on the admin/user side and for
> sure I am not into developing kernels. Anyway, curious I am...

Everybody was a newbie once at a time ...

  Ralf

From owner-linux-mips@oss.sgi.com Wed Feb 21 05:07:04 2001
Received:  by oss.sgi.com id <S553910AbRBUNGy>;
	Wed, 21 Feb 2001 05:06:54 -0800
Received: from sovereign.org ([209.180.91.170]:51375 "EHLO lux.homenet")
	by oss.sgi.com with ESMTP id <S553773AbRBUNGc>;
	Wed, 21 Feb 2001 05:06:32 -0800
Received: (from jfree@localhost)
	by lux.homenet (8.11.2/8.11.2/Debian 8.11.2-1) id f1LD7BD26818
	for linux-mips@oss.sgi.com; Wed, 21 Feb 2001 06:07:11 -0700
From:   Jim Freeman <jfree@sovereign.org>
Date:   Wed, 21 Feb 2001 06:07:11 -0700
To:     linux-mips@oss.sgi.com
Subject: sync plea
Message-ID: <20010221060711.A26654@sovereign.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.3.15i
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing

I have a farm of MIPS, PPC, and IA32 machines that I need to
keep running from a common current source tree.

The recent mips update into 2.4.2pre2 (thankyouthankyouthankyou...)
has helped in this task, but the diff between any 2.4.2pre[n>=2] or
2.4.1-ac[n>=9] tree vs the MIPS cvs tree is still huge, and painful
to cull through to wind up with a sane mips patch (should be fairly
small since the update into 2.4.2pre2) against a 2.4.*{pre*|-ac*} tree.

A sync of mips cvs to any 2.4.1{pre*|-ac*} kernel post 2.4.2pre2
would be of great use, but I don't know how much pain that entails
for the maintainers.

In lieu of that, can anyone clue me in to newbie tricks (CVS or
otherwise) for syncing 2 trees less painfully than culling diffs?

TIA,
...jfree

From owner-linux-mips@oss.sgi.com Wed Feb 21 06:48:35 2001
Received:  by oss.sgi.com id <S553962AbRBUOsY>;
	Wed, 21 Feb 2001 06:48:24 -0800
Received: from mail.sonytel.be ([193.74.243.200]:17536 "EHLO mail.sonytel.be")
	by oss.sgi.com with ESMTP id <S553959AbRBUOsE>;
	Wed, 21 Feb 2001 06:48:04 -0800
Received: from ginger.sonytel.be (ginger.sonytel.be [10.34.16.6])
	by mail.sonytel.be (8.9.0/8.8.6) with ESMTP id PAA25983
	for <linux-mips@oss.sgi.com>; Wed, 21 Feb 2001 15:48:00 +0100 (MET)
Received: (from tea@localhost)
	by ginger.sonytel.be (8.9.0/8.8.6) id PAA18306
	for linux-mips@oss.sgi.com; Wed, 21 Feb 2001 15:48:00 +0100 (MET)
Date:   Wed, 21 Feb 2001 15:48:00 +0100
From:   Tom Appermont <tea@sonycom.com>
To:     linux-mips@oss.sgi.com
Subject: gcc 2.95.3
Message-ID: <20010221154800.C12301@ginger.sonytel.be>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0i
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing


Howdy,

This is just to report a problem I was having with gcc 2.95.3,
on an R5000 LE target (ddb5074). I got the compiler and binutils 
from ftp.ds2.pg.gda.pl (thank you Maciej ;).

For some reason (which I don't know), the code compiled with
gcc 2.95.3-14 fails to deal correctly with tlb exceptions on my
target. One obvious result is that page faults do not occur. 
Compiling with egcs 1.1.2 made this problem disappear. I spent 
many days trying to pin down what went wrong where, needless to 
say that it has been a painful introduction to Linux/MIPS... 


Cheerio,

Tom


-- 
................................................................
Tom Appermont                       SDCE
mailto: tom.appermont@sonycom.com   Sint Stevens Woluwestraat 55
tel: +32 2 7248620                  1130 Brussel
fax: +32 2 7262686                  Belgium

From owner-linux-mips@oss.sgi.com Wed Feb 21 11:18:07 2001
Received:  by oss.sgi.com id <S553758AbRBUTRs>;
	Wed, 21 Feb 2001 11:17:48 -0800
Received: from u-233-19.karlsruhe.ipdial.viaginterkom.de ([62.180.19.233]:64752
        "EHLO dea.waldorf-gmbh.de") by oss.sgi.com with ESMTP
	id <S553683AbRBUTRW>; Wed, 21 Feb 2001 11:17:22 -0800
Received: (from ralf@localhost)
	by dea.waldorf-gmbh.de (8.11.1/8.11.1) id f1LF4IM22028;
	Wed, 21 Feb 2001 16:04:18 +0100
Date:   Wed, 21 Feb 2001 16:04:18 +0100
From:   Ralf Baechle <ralf@oss.sgi.com>
To:     Jim Freeman <jfree@sovereign.org>
Cc:     linux-mips@oss.sgi.com
Subject: Re: sync plea
Message-ID: <20010221160418.A21995@bacchus.dhis.org>
References: <20010221060711.A26654@sovereign.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <20010221060711.A26654@sovereign.org>; from jfree@sovereign.org on Wed, Feb 21, 2001 at 06:07:11AM -0700
X-Accept-Language: de,en,fr
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing

On Wed, Feb 21, 2001 at 06:07:11AM -0700, Jim Freeman wrote:

> I have a farm of MIPS, PPC, and IA32 machines that I need to
> keep running from a common current source tree.
> 
> The recent mips update into 2.4.2pre2 (thankyouthankyouthankyou...)
> has helped in this task, but the diff between any 2.4.2pre[n>=2] or
> 2.4.1-ac[n>=9] tree vs the MIPS cvs tree is still huge, and painful
> to cull through to wind up with a sane mips patch (should be fairly
> small since the update into 2.4.2pre2) against a 2.4.*{pre*|-ac*} tree.
> 
> A sync of mips cvs to any 2.4.1{pre*|-ac*} kernel post 2.4.2pre2
> would be of great use, but I don't know how much pain that entails
> for the maintainers.
> 
> In lieu of that, can anyone clue me in to newbie tricks (CVS or
> otherwise) for syncing 2 trees less painfully than culling diffs?

Imagine, that's what we do on a daily base.  The most easy receipe to make
diffs less painfull is half a gig of RAM which brings time for diffing
two kernel trees down to ~ 2s on an Origin or decent PC.

Unfortunately Linus dropped piles of additional patches I sent to him.
That's the standard way this works, so just wait ...

  Ralf

From owner-linux-mips@oss.sgi.com Wed Feb 21 18:29:48 2001
Received:  by oss.sgi.com id <S553997AbRBVC3i>;
	Wed, 21 Feb 2001 18:29:38 -0800
Received: from [210.241.238.126] ([210.241.238.126]:772 "EHLO
        viditec-netmedia.com.tw") by oss.sgi.com with ESMTP
	id <S553699AbRBVC3Q>; Wed, 21 Feb 2001 18:29:16 -0800
Received: from kjlin ([210.241.238.122])
	by viditec-netmedia.com.tw (8.9.3/8.8.7) with SMTP id LAA28570
	for <linux-mips@oss.sgi.com>; Thu, 22 Feb 2001 11:11:04 +0800
Message-ID: <00ba01c09c6e$84788380$056aaac0@kjlin>
From:   "kjlin" <kj.lin@viditec-netmedia.com.tw>
To:     <linux-mips@oss.sgi.com>
Subject: Does linux support for microprocessor without MMU?
Date:   Thu, 22 Feb 2001 09:26:44 +0800
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_00B7_01C09CB1.9247D720"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2919.6600
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing

This is a multi-part message in MIME format.

------=_NextPart_000_00B7_01C09CB1.9247D720
Content-Type: text/plain;
	charset="big5"
Content-Transfer-Encoding: quoted-printable

Howdy,

I got an embedded MIPS board recently.
It has the following features:
- CPU implements a five-stage pipeline with performance similar to the =
MIPS R3000 pipeline.
- MIPS32 compatible instruction set
- R4000 style privileged resource architecture.
- Without MMU.

I am estimating the possibility of porting linux on it.
Can Linux/MIPS 2.2 or 2.4 support for such a board which without MMU ?
Because i consider it is the most difficult part in the porting process.
Am i right?

KJ




------=_NextPart_000_00B7_01C09CB1.9247D720
Content-Type: text/html;
	charset="big5"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Dbig5" http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.2919.6307" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT size=3D2>Howdy,</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT size=3D2>I got an embedded MIPS board recently.</FONT></DIV>
<DIV><FONT size=3D2>It has the following features:</FONT></DIV>
<DIV><FONT size=3D2>- CPU implements a five-stage pipeline with =
performance=20
similar to the MIPS&nbsp;R3000 pipeline.</FONT></DIV>
<DIV><FONT size=3D2>- MIPS32 compatible instruction set</FONT></DIV>
<DIV><FONT size=3D2>- R4000 style privileged resource =
architecture.</FONT></DIV>
<DIV><FONT size=3D2>- Without MMU.</FONT></DIV>
<DIV><FONT size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT size=3D2>I am estimating the possibility of porting linux on=20
it.</FONT></DIV>
<DIV><FONT size=3D2>Can&nbsp;Linux/MIPS 2.2 or 2.4 support for such a =
board which=20
without MMU ?</FONT></DIV>
<DIV><FONT size=3D2>Because i consider it is the most difficult part in =
the=20
porting process.</FONT></DIV>
<DIV><FONT size=3D2>Am i right?</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT size=3D2>KJ</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV></BODY></HTML>

------=_NextPart_000_00B7_01C09CB1.9247D720--


From owner-linux-mips@oss.sgi.com Wed Feb 21 18:36:48 2001
Received:  by oss.sgi.com id <S554002AbRBVCgj>;
	Wed, 21 Feb 2001 18:36:39 -0800
Received: from [203.101.127.117] ([203.101.127.117]:43400 "EHLO eris.xware.cx")
	by oss.sgi.com with ESMTP id <S553998AbRBVCg3>;
	Wed, 21 Feb 2001 18:36:29 -0800
Received: (from chris@localhost)
	by eris.xware.cx (8.11.0/8.11.0) id f1M2a2A24908;
	Thu, 22 Feb 2001 13:36:02 +1100
Date:   Thu, 22 Feb 2001 13:36:02 +1100
From:   Crossfire <xfire@xware.cx>
To:     kjlin <kj.lin@viditec-netmedia.com.tw>
Cc:     linux-mips@oss.sgi.com
Subject: Re: Does linux support for microprocessor without MMU?
Message-ID: <20010222133602.A24899@eris.xware.cx>
References: <00ba01c09c6e$84788380$056aaac0@kjlin>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <00ba01c09c6e$84788380$056aaac0@kjlin>; from kj.lin@viditec-netmedia.com.tw on Thu, Feb 22, 2001 at 09:26:44AM +0800
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing

kjlin was once rumoured to have said:
> Howdy,
> 
> I got an embedded MIPS board recently.
> It has the following features:
> - CPU implements a five-stage pipeline with performance similar to the MIPS R3000 pipeline.
> - MIPS32 compatible instruction set
> - R4000 style privileged resource architecture.
> - Without MMU.
> 
> I am estimating the possibility of porting linux on it.
> Can Linux/MIPS 2.2 or 2.4 support for such a board which without MMU ?
> Because i consider it is the most difficult part in the porting process.
> Am i right?

the Standard Linux kernels all require an MMU.  However, there is a
version of the kernel known as "ucLinux" (Microcontroller Linux) which
will run on CPUs without MMU.

I don't know if ucLinux has a MIPS target yet.

C.
-- 
--==============================================--
  Crossfire      | This email was brought to you
  xfire@xware.cx | on 100% Recycled Electrons
--==============================================--

From owner-linux-mips@oss.sgi.com Wed Feb 21 19:19:39 2001
Received:  by oss.sgi.com id <S554061AbRBVDTS>;
	Wed, 21 Feb 2001 19:19:18 -0800
Received: from gateway-1237.mvista.com ([12.44.186.158]:48117 "EHLO
        hermes.mvista.com") by oss.sgi.com with ESMTP id <S554058AbRBVDTN>;
	Wed, 21 Feb 2001 19:19:13 -0800
Received: from mvista.com (IDENT:ppopov@zeus.mvista.com [10.0.0.112])
	by hermes.mvista.com (8.11.0/8.11.0) with ESMTP id f1M3F6815347
	for <linux-mips@oss.sgi.com>; Wed, 21 Feb 2001 19:15:06 -0800
Message-ID: <3A94850D.FDFE52CD@mvista.com>
Date:   Wed, 21 Feb 2001 19:18:37 -0800
From:   Pete Popov <ppopov@mvista.com>
Organization: Monta Vista Software
X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.17 i586)
X-Accept-Language: en, bg
MIME-Version: 1.0
To:     "linux-mips@oss.sgi.com" <linux-mips@oss.sgi.com>
Subject: RM7000 cache question
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing


Question on the RM7000 caches:

The function __flush_cache_all_d32i32() (and some other ones), flush the
entire primary data cache using blast_dache32().  Since writebacks from
the primary cache go to the secondary and tertiary/main memory, this
function seems fine. However, blast_dcache32() uses indexed cache
instructions. The primary data cache is only 16KB; the secondary cache
is 256KB. So my question is, since we're using indexed instructions, and
the primary data cache is only 16KB, will that flush only one of the 4
ways of the secondary cache, since each way is 64KB?  

static void __flush_cache_all_d32i32(void)
{
        blast_dcache32();
        blast_icache32();
}                              


Pete

From owner-linux-mips@oss.sgi.com Wed Feb 21 19:24:39 2001
Received:  by oss.sgi.com id <S554065AbRBVDYT>;
	Wed, 21 Feb 2001 19:24:19 -0800
Received: from gnyf.wheel.dk ([193.162.159.104]:45307 "EHLO gnyf.wheel.dk")
	by oss.sgi.com with ESMTP id <S554060AbRBVDYE>;
	Wed, 21 Feb 2001 19:24:04 -0800
Received: (from soren@localhost)
	by gnyf.wheel.dk (8.9.1/8.9.1) id EAA23129;
	Thu, 22 Feb 2001 04:23:59 +0100 (CET)
Date:   Thu, 22 Feb 2001 04:23:58 +0100
From:   "Soren S. Jorvang" <soren@wheel.dk>
To:     Ralf Baechle <ralf@oss.sgi.com>
Cc:     linux-mips@oss.sgi.com
Subject: Re: R10000 SGI O2
Message-ID: <20010222042358.H22997@gnyf.wheel.dk>
References: <3A895FF4.B627089E@geo.umnw.ethz.ch> <20010213190716.A29070@chem.unr.edu> <20010216175902.C2233@bacchus.dhis.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.95.4us
In-Reply-To: <20010216175902.C2233@bacchus.dhis.org>; from Ralf Baechle on Fri, Feb 16, 2001 at 05:59:02PM -0800
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing

On Fri, Feb 16, 2001 at 05:59:02PM -0800, Ralf Baechle wrote:
> > for r5k-based IP32 (O2) systems.  r10k O2 suffers from the same
> > cache-noncoherency problem as r10k I2 does, and to the best of my
> > knowledge nobody has ever really tried to even boot one.
> > 
> > Not to discourage you at all...there's just a lot of work to do.
> 
> It's really hard work to do.  R12000 O2s however should be much easier to
> do; the processor feature which causes so much grief in the O2 can be
> disabled there.

Unfortunately, noone I have talked to seems to know how
specifically to turn off speculative writes..

Does anyone on this list happen to know?


-- 
Soren

From owner-linux-mips@oss.sgi.com Wed Feb 21 20:12:29 2001
Received:  by oss.sgi.com id <S554076AbRBVEMU>;
	Wed, 21 Feb 2001 20:12:20 -0800
Received: from [208.170.106.25] ([208.170.106.25]:2323 "EHLO
        blackdog.wirespeed.com") by oss.sgi.com with ESMTP
	id <S554069AbRBVEMR>; Wed, 21 Feb 2001 20:12:17 -0800
Received: from redhat.com (IDENT:joe@dhcp-246.hsv.redhat.com [172.16.17.246] (may be forged))
	by blackdog.wirespeed.com (8.9.3/8.9.3) with ESMTP id WAA23751;
	Wed, 21 Feb 2001 22:07:08 -0600
Message-ID: <3A949279.5020707@redhat.com>
Date:   Wed, 21 Feb 2001 22:15:53 -0600
From:   Joe deBlaquiere <jadb@redhat.com>
Organization: Red Hat, Inc.
User-Agent: Mozilla/5.0 (X11; U; Linux 2.2.17-14 i686; en-US; 0.8) Gecko/20010217
X-Accept-Language: en
MIME-Version: 1.0
To:     Crossfire <xfire@xware.cx>
CC:     kjlin <kj.lin@viditec-netmedia.com.tw>, linux-mips@oss.sgi.com
Subject: Re: Does linux support for microprocessor without MMU?
References: <00ba01c09c6e$84788380$056aaac0@kjlin> <20010222133602.A24899@eris.xware.cx>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing

Crossfire wrote:

> kjlin was once rumoured to have said:
> 
>> Howdy,
>> 
>> I got an embedded MIPS board recently.
>> It has the following features:
>> - CPU implements a five-stage pipeline with performance similar to the MIPS R3000 pipeline.
>> - MIPS32 compatible instruction set
>> - R4000 style privileged resource architecture.
>> - Without MMU.
>> 
>> I am estimating the possibility of porting linux on it.
>> Can Linux/MIPS 2.2 or 2.4 support for such a board which without MMU ?
>> Because i consider it is the most difficult part in the porting process.
>> Am i right?
> 
> 
> the Standard Linux kernels all require an MMU.  However, there is a
> version of the kernel known as "ucLinux" (Microcontroller Linux) which
> will run on CPUs without MMU.
> 
> I don't know if ucLinux has a MIPS target yet.
> 
> C.

There isn't (yet) support for MIPS on uClinux.

-- 
Joe

(aka joe@uclinux.org)


From owner-linux-mips@oss.sgi.com Wed Feb 21 22:48:09 2001
Received:  by oss.sgi.com id <S554102AbRBVGrt>;
	Wed, 21 Feb 2001 22:47:49 -0800
Received: from sovereign.org ([209.180.91.170]:20914 "EHLO lux.homenet")
	by oss.sgi.com with ESMTP id <S554098AbRBVGro>;
	Wed, 21 Feb 2001 22:47:44 -0800
Received: (from jfree@localhost)
	by lux.homenet (8.11.2/8.11.2/Debian 8.11.2-1) id f1M6mO502934;
	Wed, 21 Feb 2001 23:48:24 -0700
From:   Jim Freeman <jfree@sovereign.org>
Date:   Wed, 21 Feb 2001 23:48:24 -0700
To:     Ralf Baechle <ralf@oss.sgi.com>
Cc:     linux-mips@oss.sgi.com
Subject: Re: sync plea
Message-ID: <20010221234824.A2820@sovereign.org>
References: <20010221060711.A26654@sovereign.org> <20010221160418.A21995@bacchus.dhis.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.3.15i
In-Reply-To: <20010221160418.A21995@bacchus.dhis.org>; from ralf@oss.sgi.com on Wed, Feb 21, 2001 at 04:04:18PM +0100
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing

On Wed, Feb 21, 2001 at 04:04:18PM +0100, Ralf Baechle wrote:
> On Wed, Feb 21, 2001 at 06:07:11AM -0700, Jim Freeman wrote:
...
> > The recent mips update into 2.4.2pre2 (thankyouthankyouthankyou...)
> > has helped in this task, but the diff between any 2.4.2pre[n>=2] or
> > 2.4.1-ac[n>=9] tree vs the MIPS cvs tree is still huge, and painful
> > to cull through to wind up with a sane mips patch (should be fairly
> > small since the update into 2.4.2pre2) against a 2.4.*{pre*|-ac*} tree.
> > 
> > A sync of mips cvs to any 2.4.1{pre*|-ac*} kernel post 2.4.2pre2
> > would be of great use, but I don't know how much pain that entails
> > for the maintainers.
> > 
> > In lieu of that, can anyone clue me in to newbie tricks (CVS or
> > otherwise) for syncing 2 trees less painfully than culling diffs?
> 
> Imagine, that's what we do on a daily base.  The most easy recipe to make
> diffs less painful is half a gig of RAM which brings time for diffing
> two kernel trees down to ~ 2s on an Origin or decent PC.
> 
> Unfortunately Linus dropped piles of additional patches I sent to him.
> That's the standard way this works, so just wait ...

The problem was not the mips-related changes that didn't make it into
2.4.2pre, but the non-mips changes that the mips cvs tree wasn't sync'd
to.

The merge of 2.4.2 into mips cvs will solve this - then the diff will
be just mips-related changes.

Many thanks,
...jfree

From owner-linux-mips@oss.sgi.com Wed Feb 21 22:56:19 2001
Received:  by oss.sgi.com id <S554104AbRBVG4K>;
	Wed, 21 Feb 2001 22:56:10 -0800
Received: from mail.sonytel.be ([193.74.243.200]:40432 "EHLO mail.sonytel.be")
	by oss.sgi.com with ESMTP id <S554100AbRBVG4C>;
	Wed, 21 Feb 2001 22:56:02 -0800
Received: from escobaria.sonytel.be (escobaria.sonytel.be [10.34.80.3])
	by mail.sonytel.be (8.9.0/8.8.6) with ESMTP id HAA22050;
	Thu, 22 Feb 2001 07:53:28 +0100 (MET)
Date:   Thu, 22 Feb 2001 07:53:24 +0100 (MET)
From:   Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com>
To:     Joe deBlaquiere <jadb@redhat.com>
cc:     Crossfire <xfire@xware.cx>, kjlin <kj.lin@viditec-netmedia.com.tw>,
        linux-mips@oss.sgi.com
Subject: Re: Does linux support for microprocessor without MMU?
In-Reply-To: <3A949279.5020707@redhat.com>
Message-ID: <Pine.GSO.4.10.10102220752430.13615-100000@escobaria.sonytel.be>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing

On Wed, 21 Feb 2001, Joe deBlaquiere wrote:
> Crossfire wrote:
> > kjlin was once rumoured to have said:
> >> I got an embedded MIPS board recently.
> >> It has the following features:
> >> - CPU implements a five-stage pipeline with performance similar to the MIPS R3000 pipeline.
> >> - MIPS32 compatible instruction set
> >> - R4000 style privileged resource architecture.
> >> - Without MMU.
> >> 
> >> I am estimating the possibility of porting linux on it.
> >> Can Linux/MIPS 2.2 or 2.4 support for such a board which without MMU ?
> >> Because i consider it is the most difficult part in the porting process.
> >> Am i right?
> > 
> > the Standard Linux kernels all require an MMU.  However, there is a
> > version of the kernel known as "ucLinux" (Microcontroller Linux) which
> > will run on CPUs without MMU.
> > 
> > I don't know if ucLinux has a MIPS target yet.
> 
> There isn't (yet) support for MIPS on uClinux.

But it can't be that hard to add support for it...

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven ------------- Sony Software Development Center Europe (SDCE)
Geert.Uytterhoeven@sonycom.com ------------------- Sint-Stevens-Woluwestraat 55
Voice +32-2-7248626 Fax +32-2-7262686 ---------------- B-1130 Brussels, Belgium


From owner-linux-mips@oss.sgi.com Thu Feb 22 16:07:23 2001
Received:  by oss.sgi.com id <S553840AbRBWAHM>;
	Thu, 22 Feb 2001 16:07:12 -0800
Received: from u-186-19.karlsruhe.ipdial.viaginterkom.de ([62.180.19.186]:39153
        "EHLO dea.waldorf-gmbh.de") by oss.sgi.com with ESMTP
	id <S553802AbRBWAHD>; Thu, 22 Feb 2001 16:07:03 -0800
Received: (from ralf@localhost)
	by dea.waldorf-gmbh.de (8.11.1/8.11.1) id f1N04NX02182;
	Fri, 23 Feb 2001 01:04:23 +0100
Date:   Fri, 23 Feb 2001 01:04:23 +0100
From:   Ralf Baechle <ralf@oss.sgi.com>
To:     "Soren S. Jorvang" <soren@wheel.dk>
Cc:     linux-mips@oss.sgi.com
Subject: Re: R10000 SGI O2
Message-ID: <20010223010423.A1212@bacchus.dhis.org>
References: <3A895FF4.B627089E@geo.umnw.ethz.ch> <20010213190716.A29070@chem.unr.edu> <20010216175902.C2233@bacchus.dhis.org> <20010222042358.H22997@gnyf.wheel.dk>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <20010222042358.H22997@gnyf.wheel.dk>; from soren@wheel.dk on Thu, Feb 22, 2001 at 04:23:58AM +0100
X-Accept-Language: de,en,fr
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing

On Thu, Feb 22, 2001 at 04:23:58AM +0100, Soren S. Jorvang wrote:

> > > for r5k-based IP32 (O2) systems.  r10k O2 suffers from the same
> > > cache-noncoherency problem as r10k I2 does, and to the best of my
> > > knowledge nobody has ever really tried to even boot one.
> > > 
> > > Not to discourage you at all...there's just a lot of work to do.
> > 
> > It's really hard work to do.  R12000 O2s however should be much easier to
> > do; the processor feature which causes so much grief in the O2 can be
> > disabled there.
> 
> Unfortunately, noone I have talked to seems to know how
> specifically to turn off speculative writes..

> 
> Does anyone on this list happen to know?

RTFM ;-)

B.2 DSD (Delay Speculative Dirty)

  The Boot Mode bit 24 corresponds to the Config register[24] bit and this
  controls DSD during kernel and supervisor modes. However, the DSD mode can
  also be enabled in the user mode by setting the Status register[24]
  bit. Config register[24] is read-only and can be set only at boot time. If
  the DSD mode is set -

  a) R12000 will not set the Dirty bit for a secondary cache block until the
     store instruction is the oldest in the Active List and is about to be
     executed. (An interrupt could cause a case where the dirty bit is set
     (store is no longer speculative), but the store does not immediately
     graduate. We believe this case should not cause any problem. This mode
     does prevent speculative stores from setting the dirty bit.

  b) This mode will have slightly lower performance due to the delay in the
     setting of the Dirty bit. This delay will occur just once per block
     refill from main memory, when it is necessary to set the dirty
     bit. Setting the bit requires about ten cycles; but usually the
     processor will continue to overlap execution of other instructions.
     Once a block becomes dirty in secondary cache, this mode has no
     performance effect.

  c) In this mode, a miss in secondary cache, due to a store instruction
     which is not already the oldest in the pipeline, will cause a refill to
     the clean exclusive state. A hit to a shared line will immediately
     cause an upgrade to clean exclusive . Thus, bus operations (which are
     relatively slow) will still begin speculatively. Independent of the DSD
     mode, R12000 will delay a cached, non-coherent load until it is the
     oldest instruction. This change is implemented because a speculative
     load accessing an unmapped xkphys address as cached, non-coherent might
     bring data into the secondary cache without the proper coherency
     checks. R12000 is doing no changes to prevent it from speculatively
     refilling cache lines in shared or clean states except the xkphys case
     described above.

So as you see the details are actually a bit more complicated than just
disabling speculative stores; the actual problem are dirty lines which might
be written back to memory on an O2 or Indigo 2 R10000.  DSD doesn't help
with speculative loads but these are easier to handle.

  Ralf

From owner-linux-mips@oss.sgi.com Thu Feb 22 16:11:32 2001
Received:  by oss.sgi.com id <S553872AbRBWALW>;
	Thu, 22 Feb 2001 16:11:22 -0800
Received: from gnyf.wheel.dk ([193.162.159.104]:15355 "EHLO gnyf.wheel.dk")
	by oss.sgi.com with ESMTP id <S553831AbRBWALL>;
	Thu, 22 Feb 2001 16:11:11 -0800
Received: (from soren@localhost)
	by gnyf.wheel.dk (8.9.1/8.9.1) id BAA01831;
	Fri, 23 Feb 2001 01:11:08 +0100 (CET)
Date:   Fri, 23 Feb 2001 01:11:08 +0100
From:   "Soren S. Jorvang" <soren@wheel.dk>
To:     Ralf Baechle <ralf@oss.sgi.com>
Cc:     linux-mips@oss.sgi.com
Subject: Re: R10000 SGI O2
Message-ID: <20010223011108.A1813@gnyf.wheel.dk>
References: <3A895FF4.B627089E@geo.umnw.ethz.ch> <20010213190716.A29070@chem.unr.edu> <20010216175902.C2233@bacchus.dhis.org> <20010222042358.H22997@gnyf.wheel.dk> <20010223010423.A1212@bacchus.dhis.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.95.4us
In-Reply-To: <20010223010423.A1212@bacchus.dhis.org>; from Ralf Baechle on Fri, Feb 23, 2001 at 01:04:23AM +0100
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing

On Fri, Feb 23, 2001 at 01:04:23AM +0100, Ralf Baechle wrote:
> > Does anyone on this list happen to know?
> 
> RTFM ;-)
> 
> B.2 DSD (Delay Speculative Dirty)

Wow, actual R12K documentation!

Is that freely available somewhere? Maybe I just didn't look
hard enough, but it's not very easy to find at least..


-- 
Soren

From owner-linux-mips@oss.sgi.com Thu Feb 22 17:08:52 2001
Received:  by oss.sgi.com id <S553886AbRBWBIm>;
	Thu, 22 Feb 2001 17:08:42 -0800
Received: from u-186-19.karlsruhe.ipdial.viaginterkom.de ([62.180.19.186]:42481
        "EHLO dea.waldorf-gmbh.de") by oss.sgi.com with ESMTP
	id <S553877AbRBWBId>; Thu, 22 Feb 2001 17:08:33 -0800
Received: (from ralf@localhost)
	by dea.waldorf-gmbh.de (8.11.1/8.11.1) id f1N18H906901;
	Fri, 23 Feb 2001 02:08:17 +0100
Date:   Fri, 23 Feb 2001 02:08:17 +0100
From:   Ralf Baechle <ralf@oss.sgi.com>
To:     "Soren S. Jorvang" <soren@wheel.dk>
Cc:     linux-mips@oss.sgi.com
Subject: Re: R10000 SGI O2
Message-ID: <20010223020817.A2478@bacchus.dhis.org>
References: <3A895FF4.B627089E@geo.umnw.ethz.ch> <20010213190716.A29070@chem.unr.edu> <20010216175902.C2233@bacchus.dhis.org> <20010222042358.H22997@gnyf.wheel.dk> <20010223010423.A1212@bacchus.dhis.org> <20010223011108.A1813@gnyf.wheel.dk>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <20010223011108.A1813@gnyf.wheel.dk>; from soren@wheel.dk on Fri, Feb 23, 2001 at 01:11:08AM +0100
X-Accept-Language: de,en,fr
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing

On Fri, Feb 23, 2001 at 01:11:08AM +0100, Soren S. Jorvang wrote:

> > > Does anyone on this list happen to know?
> > 
> > RTFM ;-)
> > 
> > B.2 DSD (Delay Speculative Dirty)
> 
> Wow, actual R12K documentation!
> 
> Is that freely available somewhere? Maybe I just didn't look
> hard enough, but it's not very easy to find at least..

http://www.nec.com

The manual isn't exactly great so they don't tell you that the values in
c0_prid did change also and there are more inaccuracies.

  Ralf

From owner-linux-mips@oss.sgi.com Thu Feb 22 17:47:12 2001
Received:  by oss.sgi.com id <S554005AbRBWBrC>;
	Thu, 22 Feb 2001 17:47:02 -0800
Received: from gateway-1237.mvista.com ([12.44.186.158]:64761 "EHLO
        hermes.mvista.com") by oss.sgi.com with ESMTP id <S553995AbRBWBqv>;
	Thu, 22 Feb 2001 17:46:51 -0800
Received: from mvista.com (IDENT:ppopov@zeus.mvista.com [10.0.0.112])
	by hermes.mvista.com (8.11.0/8.11.0) with ESMTP id f1N1gd828456;
	Thu, 22 Feb 2001 17:42:39 -0800
Message-ID: <3A95C0E2.5173DEA6@mvista.com>
Date:   Thu, 22 Feb 2001 17:46:10 -0800
From:   Pete Popov <ppopov@mvista.com>
Organization: Monta Vista Software
X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.17 i586)
X-Accept-Language: en, bg
MIME-Version: 1.0
To:     Ralf Baechle <ralf@uni-koblenz.de>,
        "linux-mips@oss.sgi.com" <linux-mips@oss.sgi.com>
Subject: loops_per_sec
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing


Ralf,

The variable loops_per_sec has become loops_per_jiffy around 2.4.1,
breaking the mips delay functions.  I edited include/asm-mips/delay.h to
rename the variable.  There's other places in mips64 where loops_per_sec
is being used. Furthermore, since it's loops per "jiffy", the delay must
be further increased by a factor of HZ.  

Pete

From owner-linux-mips@oss.sgi.com Thu Feb 22 20:27:13 2001
Received:  by oss.sgi.com id <S554001AbRBWE1F>;
	Thu, 22 Feb 2001 20:27:05 -0800
Received: from agile-50.OntheNet.com.au ([203.144.13.50]:17158 "EHLO
        surfers.oz.agile.tv") by oss.sgi.com with ESMTP id <S553890AbRBWE0o>;
	Thu, 22 Feb 2001 20:26:44 -0800
Received: from agile.tv (IDENT:ldavies@tugun.oz.agile.tv [192.168.16.20])
	by surfers.oz.agile.tv (8.11.0/8.11.0) with ESMTP id f1N4QgV06922;
	Fri, 23 Feb 2001 14:26:42 +1000
Message-ID: <3A95E682.982AC529@agile.tv>
Date:   Fri, 23 Feb 2001 14:26:42 +1000
From:   Liam Davies <ldavies@agile.tv>
Reply-To: ldavies@oz.agile.tv
Organization: Agile TV
X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.16-22 i686)
X-Accept-Language: en
MIME-Version: 1.0
To:     linux-mips@oss.sgi.com
Subject: Small remote debug kernels??
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing

I would like to remote debug my kernel.
On the Cobalt box I have there is (allegedly) a bootloader bug that
stops the
kernel being any larger than 1M/2.5M, compressed/uncompressed.
I have stripped the kernel bare but can't get much lower than 6M
uncompressed.

Is there any way I can have a mini-remote debugging kernel??


Thanks
Liam


From owner-linux-mips@oss.sgi.com Thu Feb 22 21:41:13 2001
Received:  by oss.sgi.com id <S553801AbRBWFlD>;
	Thu, 22 Feb 2001 21:41:03 -0800
Received: from [208.170.106.25] ([208.170.106.25]:9744 "EHLO
        blackdog.wirespeed.com") by oss.sgi.com with ESMTP
	id <S553739AbRBWFkm>; Thu, 22 Feb 2001 21:40:42 -0800
Received: from redhat.com (IDENT:joe@dhcp-242.hsv.redhat.com [172.16.17.242] (may be forged))
	by blackdog.wirespeed.com (8.9.3/8.9.3) with ESMTP id XAA12094;
	Thu, 22 Feb 2001 23:33:39 -0600
Message-ID: <3A95F83D.9030600@redhat.com>
Date:   Thu, 22 Feb 2001 23:42:21 -0600
From:   Joe deBlaquiere <jadb@redhat.com>
Organization: Red Hat, Inc.
User-Agent: Mozilla/5.0 (X11; U; Linux 2.2.17-14 i686; en-US; 0.8) Gecko/20010217
X-Accept-Language: en
MIME-Version: 1.0
To:     Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com>
CC:     Crossfire <xfire@xware.cx>, kjlin <kj.lin@viditec-netmedia.com.tw>,
        linux-mips@oss.sgi.com
Subject: Re: Does linux support for microprocessor without MMU?
References: <Pine.GSO.4.10.10102220752430.13615-100000@escobaria.sonytel.be>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing

Geert Uytterhoeven wrote:

> On Wed, 21 Feb 2001, Joe deBlaquiere wrote:
> 
>> 
>> There isn't (yet) support for MIPS on uClinux.
> 
> 
> But it can't be that hard to add support for it...
> 
Porting the kernel isn't much worse than any other architectural port. 
Of course that's only a part of the story, since you'll need to port the 
C library (uClibc/uC-glibc) and you will have to play around with the 
object file format to make it work with FLAT binaries... If you're 
serious about doing uClinux you can find a somewhat cryptic article on 
porting to uClinux at:

http://www.redhat.com/embedded/technologies/resources

-- 
Joe


From owner-linux-mips@oss.sgi.com Fri Feb 23 06:14:57 2001
Received:  by oss.sgi.com id <S554013AbRBWOOi>;
	Fri, 23 Feb 2001 06:14:38 -0800
Received: from mail.sonytel.be ([193.74.243.200]:12282 "EHLO mail.sonytel.be")
	by oss.sgi.com with ESMTP id <S554022AbRBWOO2>;
	Fri, 23 Feb 2001 06:14:28 -0800
Received: from ginger.sonytel.be (ginger.sonytel.be [10.34.16.6])
	by mail.sonytel.be (8.9.0/8.8.6) with ESMTP id PAA21748
	for <linux-mips@oss.sgi.com>; Fri, 23 Feb 2001 15:13:57 +0100 (MET)
Received: (from tea@localhost)
	by ginger.sonytel.be (8.9.0/8.8.6) id PAA21266
	for linux-mips@oss.sgi.com; Fri, 23 Feb 2001 15:13:55 +0100 (MET)
Date:   Fri, 23 Feb 2001 15:13:55 +0100
From:   Tom Appermont <tea@sonycom.com>
To:     linux-mips@oss.sgi.com
Subject: ELF header kernel module wrong?
Message-ID: <20010223151355.A9091@ginger.sonytel.be>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0i
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing


Greetings,

I'm trying to get modules to work on my R5000 little endian 
target, linux 2.4.1 + modutils 2.4.2 .

When I insmod a module, I get error messages like: 

[root@192 /]# insmod dummy.o 
dummy.o: local symbol gcc2_compiled. with index 10 exceeds local_symtab_size 10
dummy.o: local symbol __gnu_compiled_c with index 11 exceeds local_symtab_size 10
dummy.o: local symbol __module_kernel_version with index 12 exceeds local_symtab_size 10
dummy.o: local symbol set_multicast_list with index 13 exceeds local_symtab_size 10
dummy.o: local symbol dummy_init with index 14 exceeds local_symtab_size 10
dummy.o: local symbol dummy_xmit with index 15 exceeds local_symtab_size 10
dummy.o: local symbol dummy_get_stats with index 18 exceeds local_symtab_size 10
dummy.o: local symbol dummy_init_module with index 21 exceeds local_symtab_size 10
dummy.o: local symbol dev_dummy with index 22 exceeds local_symtab_size 10
dummy.o: local symbol dummy_cleanup_module with index 26 exceeds local_symtab_size 10
[root@192 /]#

Looking at the source code of modutils, I suspect that there is 
something wrong with the ELF header of the module (the sh_info
field of the SYMTAB section is 0xa while it should be 0x17 ??).
ELF header is attached below. The command used to compile the 
module is :

mipsel-linux-gcc -I/usr/src/linux/include/asm/gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -fno-strict-aliasing -G 0 -mno-abicalls -fno-pic -mcpu=r8000 -mips2 -Wa,--trap -pipe -DMODULE -mlong-calls

I use egcs 1.2.1 + binutils 2.9.5. Is this a problem with my
binutils?


Tom


--
Elf header
  e_ident =  7f 45 4c 46 1 1 1 0 0 0 0 0 0 0 0 0  
  e_ident[EI_CLASS] = ELFCLASS32
  e_ident[EI_DATA] = ELFDATA2LSB
  e_ident[EI_VERSION] = 1
  e_type = ET_REL
  e_machine = EM_MIPS
  e_version = 1
  e_entry = 0x0
  e_phoff = 0x0
  e_shoff = 0xa1c
  e_flags = 0x30000101
  e_ehsize = 52
  e_phentsize = 0
  e_phnum = 0
  e_shentsize = 40
  e_shnum = 15
  e_shstrndx = 12

Section header #0
  sh_name = <NULL>
  sh_type = SHT_NULL
  sh_flags = 0x0 (no flags)
  sh_addr = 0x0
  sh_offset = 0x0
  sh_size = 0x0
  sh_link = 0x0
  sh_info = 0x0
  sh_addralign = 0
  sh_entsize = 0

Section header #1
  sh_name = .text
  sh_type = SHT_PROGBITS
  sh_flags = 0x6 (Execinstr, Alloc)
  sh_addr = 0x0
  sh_offset = 0x40
  sh_size = 0x220
  sh_link = 0x0
  sh_info = 0x0
  sh_addralign = 16
  sh_entsize = 0

Section header #2
  sh_name = .rel.text
  sh_type = SHT_REL
  sh_flags = 0x0 (no flags)
  sh_addr = 0x0
  sh_offset = 0xf90
  sh_size = 0x128
  sh_link = 0xd
  sh_info = 0x1
  sh_addralign = 4
  sh_entsize = 8

Section header #3
  sh_name = .rela.text
  sh_type = SHT_RELA
  sh_flags = 0x0 (no flags)
  sh_addr = 0x0
  sh_offset = 0x10b8
  sh_size = 0x0
  sh_link = 0xd
  sh_info = 0x1
  sh_addralign = 4
  sh_entsize = 12

Section header #4
  sh_name = .data
  sh_type = SHT_PROGBITS
  sh_flags = 0x3 (Alloc, Write)
  sh_addr = 0x0
  sh_offset = 0x260
  sh_size = 0x0
  sh_link = 0x0
  sh_info = 0x0
  sh_addralign = 16
  sh_entsize = 0

Section header #5
  sh_name = .bss
  sh_type = SHT_NOBITS
  sh_flags = 0x3 (Alloc, Write)
  sh_addr = 0x0
  sh_offset = 0x260
  sh_size = 0x130
  sh_link = 0x0
  sh_info = 0x0
  sh_addralign = 16
  sh_entsize = 0

Section header #6
  sh_name = .reginfo
  sh_type = <<< unknown sh_type (0x70000006) >>>
  sh_flags = 0x2 (Alloc)
  sh_addr = 0x0
  sh_offset = 0x260
  sh_size = 0x18
  sh_link = 0x0
  sh_info = 0x0
  sh_addralign = 4
  sh_entsize = 1


Section header #7
  sh_name = .mdebug
  sh_type = <<< unknown sh_type (0x70000005) >>>
  sh_flags = 0x0 (no flags)
  sh_addr = 0x0
  sh_offset = 0x278
  sh_size = 0x614
  sh_link = 0x0
  sh_info = 0x0
  sh_addralign = 4
  sh_entsize = 1

Section header #8
  sh_name = .note
  sh_type = SHT_NOTE
  sh_flags = 0x0 (no flags)
  sh_addr = 0x0
  sh_offset = 0x88c
  sh_size = 0x14
  sh_link = 0x0
  sh_info = 0x0
  sh_addralign = 1
  sh_entsize = 0

Section header #9
  sh_name = .modinfo
  sh_type = SHT_PROGBITS
  sh_flags = 0x0 (no flags)
  sh_addr = 0x0
  sh_offset = 0x8a0
  sh_size = 0x18
  sh_link = 0x0
  sh_info = 0x0
  sh_addralign = 4
  sh_entsize = 0

Section header #10
  sh_name = .rodata
  sh_type = SHT_PROGBITS
  sh_flags = 0x2 (Alloc)
  sh_addr = 0x0
  sh_offset = 0x8c0
  sh_size = 0xb0
  sh_link = 0x0
  sh_info = 0x0
  sh_addralign = 16
  sh_entsize = 0

Section header #11
  sh_name = .comment
  sh_type = SHT_PROGBITS
  sh_flags = 0x0 (no flags)
  sh_addr = 0x0
  sh_offset = 0x970
  sh_size = 0x37
  sh_link = 0x0
  sh_info = 0x0
  sh_addralign = 1
  sh_entsize = 0


Section header #12
  sh_name = .shstrtab
  sh_type = SHT_STRTAB
  sh_flags = 0x0 (no flags)
  sh_addr = 0x0
  sh_offset = 0x9a7
  sh_size = 0x72
  sh_link = 0x0
  sh_info = 0x0
  sh_addralign = 1
  sh_entsize = 0

Section header #13
  sh_name = .symtab
  sh_type = SHT_SYMTAB
  sh_flags = 0x0 (no flags)
  sh_addr = 0x0
  sh_offset = 0xc74
  sh_size = 0x1f0
  sh_link = 0xe
  sh_info = 0xa
  sh_addralign = 4
  sh_entsize = 16

Section header #14
  sh_name = .strtab
  sh_type = SHT_STRTAB
  sh_flags = 0x0 (no flags)
  sh_addr = 0x0
  sh_offset = 0xe64
  sh_size = 0x12a
  sh_link = 0x0
  sh_info = 0x0
  sh_addralign = 1
  sh_entsize = 0

Symbol Table: .symtab (@ 0xc74)
0. <NULL>, value=0, size=0, info=0, shndx=0
1. <NULL>, value=0, size=0, info=(local, section), shndx=.text(1)
2. <NULL>, value=0, size=0, info=(local, section), shndx=.data(4)
3. <NULL>, value=0, size=0, info=(local, section), shndx=.bss(5)
4. <NULL>, value=0, size=0, info=(local, section), shndx=.modinfo(9)
5. <NULL>, value=0, size=0, info=(local, section), shndx=.rodata(10)
6. <NULL>, value=0, size=0, info=(local, section), shndx=.reginfo(6)
7. <NULL>, value=0, size=0, info=(local, section), shndx=.mdebug(7)
8. <NULL>, value=0, size=0, info=(local, section), shndx=.note(8)
9. <NULL>, value=0, size=0, info=(local, section), shndx=.comment(11)
10. gcc2_compiled., value=0, size=0, info=0, shndx=.text(1)
11. __gnu_compiled_c, value=0, size=0, info=0, shndx=.text(1)
12. __module_kernel_version, value=0, size=21, info=(local, object), shndx=.modinfo(9)
13. set_multicast_list, value=0, size=8, info=(local, func), shndx=.text(1)
14. dummy_init, value=8, size=168, info=(local, func), shndx=.text(1)
15. dummy_xmit, value=0xb0, size=124, info=(local, func), shndx=.text(1)
16. kmalloc, value=0, size=0, info=(global, notype), shndx=0
17. memset, value=0, size=0, info=(global, notype), shndx=0
18. dummy_get_stats, value=0x12c, size=8, info=(local, func), shndx=.text(1)
19. ether_setup, value=0, size=0, info=(global, notype), shndx=0
20. __kfree_skb, value=0, size=0, info=(global, notype), shndx=0
21. dummy_init_module, value=0x134, size=124, info=(local, func), shndx=.text(1)
22. dev_dummy, value=0, size=304, info=(local, object), shndx=.bss(5)
23. __this_module, value=0, size=0, info=(global, notype), shndx=0
24. dev_alloc_name, value=0, size=0, info=(global, notype), shndx=0
25. register_netdev, value=0, size=0, info=(global, notype), shndx=0
26. dummy_cleanup_module, value=0x1b0, size=104, info=(local, func), shndx=.text(1)
27. unregister_netdev, value=0, size=0, info=(global, notype), shndx=0
28. kfree, value=0, size=0, info=(global, notype), shndx=0
29. init_module, value=0x134, size=124, info=(global, func), shndx=.text(1)
30. cleanup_module, value=0x1b0, size=104, info=(global, func), shndx=.text(1)

Relocation section .rel.text (2)
Index   Offset          Symbol          Type
0.      1c              1               R_MIPS_HI16 (5)
1.      20              1               R_MIPS_LO16 (6)
2.      24              16              R_MIPS_HI16 (5)
3.      28              16              R_MIPS_LO16 (6)
4.      48              17              R_MIPS_HI16 (5)
5.      4c              17              R_MIPS_LO16 (6)
6.      5c              1               R_MIPS_HI16 (5)
7.      60              1               R_MIPS_LO16 (6)
8.      64              1               R_MIPS_HI16 (5)
9.      68              1               R_MIPS_LO16 (6)
10.     70              19              R_MIPS_HI16 (5)
11.     74              19              R_MIPS_LO16 (6)
12.     94              1               R_MIPS_26 (4)
13.     10c             20              R_MIPS_HI16 (5)
14.     110             20              R_MIPS_LO16 (6)
15.     138             3               R_MIPS_HI16 (5)
16.     13c             3               R_MIPS_LO16 (6)
17.     140             1               R_MIPS_HI16 (5)
18.     144             1               R_MIPS_LO16 (6)
19.     154             23              R_MIPS_HI16 (5)
20.     158             23              R_MIPS_LO16 (6)
21.     164             5               R_MIPS_HI16 (5)
22.     168             5               R_MIPS_LO16 (6)
23.     16c             24              R_MIPS_HI16 (5)
24.     170             24              R_MIPS_LO16 (6)
25.     184             25              R_MIPS_HI16 (5)
26.     188             25              R_MIPS_LO16 (6)
27.     1b8             3               R_MIPS_HI16 (5)
28.     1bc             3               R_MIPS_LO16 (6)
29.     1c0             27              R_MIPS_HI16 (5)
30.     1c4             27              R_MIPS_LO16 (6)
31.     1d4             28              R_MIPS_HI16 (5)
32.     1d8             28              R_MIPS_LO16 (6)
33.     1ec             17              R_MIPS_HI16 (5)
34.     1f0             17              R_MIPS_LO16 (6)
35.     200             1               R_MIPS_HI16 (5)
36.     204             1               R_MIPS_LO16 (6)


From owner-linux-mips@oss.sgi.com Fri Feb 23 09:22:09 2001
Received:  by oss.sgi.com id <S554022AbRBWRVt>;
	Fri, 23 Feb 2001 09:21:49 -0800
Received: from monarch.cr.usgs.gov ([159.189.176.193]:43022 "HELO
        monarch.cr.usgs.gov") by oss.sgi.com with SMTP id <S553861AbRBWRVl>;
	Fri, 23 Feb 2001 09:21:41 -0800
Received: from fleance.cr.usgs.gov (fleance.cr.usgs.gov [159.189.176.46])
	by monarch.cr.usgs.gov (Postfix) with SMTP id 53B3715AD8E
	for <linux-mips@oss.sgi.com>; Fri, 23 Feb 2001 10:29:19 -0700 (MST)
Content-Type: text/plain;
  charset="iso-8859-1"
From:   Ray <rcarlino@home.com>
To:     linux-mips@oss.sgi.com
Subject: Hardware support
Date:   Fri, 23 Feb 2001 10:23:27 +0000
X-Mailer: KMail [version 1.2]
MIME-Version: 1.0
Message-Id: <01022310232702.19197@fleance.cr.usgs.gov>
Content-Transfer-Encoding: 8bit
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing

I am getting a SGI Challenge L with r4400 processors and would like to know 
the status of a linux port that will run on it????

-- 
Ray

From owner-linux-mips@oss.sgi.com Fri Feb 23 09:23:19 2001
Received:  by oss.sgi.com id <S554027AbRBWRXI>;
	Fri, 23 Feb 2001 09:23:08 -0800
Received: from gateway-1237.mvista.com ([12.44.186.158]:55802 "EHLO
        hermes.mvista.com") by oss.sgi.com with ESMTP id <S553878AbRBWRW5>;
	Fri, 23 Feb 2001 09:22:57 -0800
Received: from mvista.com (IDENT:jsun@orion.mvista.com [10.0.0.75])
	by hermes.mvista.com (8.11.0/8.11.0) with ESMTP id f1NHIf805371;
	Fri, 23 Feb 2001 09:18:41 -0800
Message-ID: <3A969BDD.C6A41060@mvista.com>
Date:   Fri, 23 Feb 2001 09:20:29 -0800
From:   Jun Sun <jsun@mvista.com>
X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.18 i686)
X-Accept-Language: en
MIME-Version: 1.0
To:     Tom Appermont <tea@sonycom.com>
CC:     linux-mips@oss.sgi.com
Subject: Re: ELF header kernel module wrong?
References: <20010223151355.A9091@ginger.sonytel.be>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing

Tom Appermont wrote:
> 
> Greetings,
> 
> I'm trying to get modules to work on my R5000 little endian
> target, linux 2.4.1 + modutils 2.4.2 .
> 
> When I insmod a module, I get error messages like:
> 

Tom,

This is a well-known problem which also exists in the old toolchain.  If you
can search the archive, you can see a string of discussions a few months
back.  (I don't know if we have any mailing archive?)

> 
> I use egcs 1.2.1 + binutils 2.9.5. Is this a problem with my
> binutils?
> 

Essentially it is caused by the different symbols sorting used in binutial and
modutils.  I was trying to fix it but it was beyond my ken.

Jun

From owner-linux-mips@oss.sgi.com Fri Feb 23 10:13:49 2001
Received:  by oss.sgi.com id <S554030AbRBWSNj>;
	Fri, 23 Feb 2001 10:13:39 -0800
Received: from mail.sonytel.be ([193.74.243.200]:10404 "EHLO mail.sonytel.be")
	by oss.sgi.com with ESMTP id <S554026AbRBWSNb>;
	Fri, 23 Feb 2001 10:13:31 -0800
Received: from ginger.sonytel.be (ginger.sonytel.be [10.34.16.6])
	by mail.sonytel.be (8.9.0/8.8.6) with ESMTP id TAA01478;
	Fri, 23 Feb 2001 19:13:27 +0100 (MET)
Received: (from tea@localhost)
	by ginger.sonytel.be (8.9.0/8.8.6) id TAA00796;
	Fri, 23 Feb 2001 19:13:27 +0100 (MET)
Date:   Fri, 23 Feb 2001 19:13:27 +0100
From:   Tom Appermont <tea@sonycom.com>
To:     Jun Sun <jsun@mvista.com>
Cc:     Tom Appermont <tea@sonycom.com>, linux-mips@oss.sgi.com
Subject: Re: ELF header kernel module wrong?
Message-ID: <20010223191327.A18076@ginger.sonytel.be>
References: <20010223151355.A9091@ginger.sonytel.be> <3A969BDD.C6A41060@mvista.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="OgqxwSJOaUobr8KG"
X-Mailer: Mutt 1.0i
In-Reply-To: <3A969BDD.C6A41060@mvista.com>; from jsun@mvista.com on Fri, Feb 23, 2001 at 09:20:29AM -0800
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing


--OgqxwSJOaUobr8KG
Content-Type: text/plain; charset=us-ascii

Jun Sun wrote:
>
> > I'm trying to get modules to work on my R5000 little endian
> > target, linux 2.4.1 + modutils 2.4.2 .
> > 
> > When I insmod a module, I get error messages like:
> > 
>
> This is a well-known problem which also exists in the old toolchain.  If you
> can search the archive, you can see a string of discussions a few months
> back.  (I don't know if we have any mailing archive?)

I also don't know if their is a linux-mips archive, but luckily Geert
keeps one himself. I found the discussion thread you are referring to
(I think) and attached the final mail below.

> > I use egcs 1.2.1 + binutils 2.9.5. Is this a problem with my
> > binutils?
> > 
> 
> Essentially it is caused by the different symbols sorting used in binutial and
> modutils.  I was trying to fix it but it was beyond my ken.

Hmmmm ... anybody else tried to fix this or with plans to do so?


Tom








--OgqxwSJOaUobr8KG
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename=ralfb

From owner-linux-mips@oss.sgi.com  Tue Oct 24 03:20:15 2000
Return-Path: <owner-linux-mips@oss.sgi.com>
Received: from oss.sgi.com (IDENT:root@oss.sgi.com [216.32.174.190])
	by mail.sonytel.be (8.9.0/8.8.6) with ESMTP id DAA05862
	for <geert.uytterhoeven@sonycom.com>; Tue, 24 Oct 2000 03:20:14 +0200 (MET DST)
Received:  by oss.sgi.com id <S553712AbQJXBTh>;
	Mon, 23 Oct 2000 18:19:37 -0700
Received: from u-50.karlsruhe.ipdial.viaginterkom.de ([62.180.19.50]:23300
        "EHLO u-50.karlsruhe.ipdial.viaginterkom.de") by oss.sgi.com
	with ESMTP id <S553686AbQJXBTS>; Mon, 23 Oct 2000 18:19:18 -0700
Received: (ralf@lappi) by lappi.waldorf-gmbh.de id <S870343AbQJXBS2>;
        Tue, 24 Oct 2000 03:18:28 +0200
Date:   Tue, 24 Oct 2000 03:18:28 +0200
From: Ralf Baechle <ralf@oss.sgi.com>
To: Jun Sun <jsun@mvista.com>
Cc: Keith Owens <kaos@melbourne.sgi.com>, linux-mips@oss.sgi.com
Subject: Re: problems with insmod ...
Message-ID: <20001024031828.A2816@bacchus.dhis.org>
References: <39F48742.933941B8@mvista.com> <7690.972340323@ocs3.ocs-net> <20001024024040.D1009@bacchus.dhis.org> <39F4E113.6BC85A5C@mvista.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0.1i
In-Reply-To: <39F4E113.6BC85A5C@mvista.com>; from jsun@mvista.com on Mon, Oct 23, 2000 at 06:08:35PM -0700
X-Accept-Language: de,en,fr
X-Orcpt: rfc822;linux-mips@oss.sgi.com
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
X-Keywords:
X-UID: 246
Content-Length: 1638
Lines: 44

On Mon, Oct 23, 2000 at 06:08:35PM -0700, Jun Sun wrote:

> > > Jun Sun <jsun@mvista.com> wrote:
> > > >I tried with 2.3.19, and now I am having problem with out of bound index
> > > >in symbol table.  See the output below.
> > > >
> > > >---------
> > > >sh-2.03# insmod hello.o
> > > >hello.o: local symbol gcc2_compiled. with index 10 exceeds
> > > >local_symtab_size 10
> > > >hello.o: local symbol __gnu_compiled_c with index 11 exceeds
> > > >local_symtab_size 10
> > > >---------
> > >
> > > It is a toolchain bug, I think it is in the assembler.  I have a dim
> > > distant memory from about a month ago that somebody on linux-mips found
> > > the problem.  Ask the toolchain experts.
> > 
> > It's a bug bug in ld, one in BFD and a sillyness in IRIX ELF which the linker
> > uses.  IRIX ELF uses different sorting rules for the symbol table, see
> > mips_elf_sym_is_global in bfd/elf32-mips.c.
> > 
> >  - Bug one: ld generated output should follow the same rules as assembler
> >    generated output.
> >  - Bug two is more a design flaw - why does Linux/MIPS and most other
> >    MIPS ELF configurations use IRIX and not ABI ELF?
> >  - Bug three is that mips_elf_sym_is_global applies these IRIX ELF sorting
> >    rules even to ABI ELF.
> > 
> >   Ralf
> 
> This sounds like a serious problem to me.  So here are the questions : 
> 
> 1) is it fixed in the latest binutils?

No, all binutils ever are affected.

> 2) is it worth fixed for binutil v2.8.1?

Probably not.  I believe modulo some testing current CVS binutils are ready
for more serious use than just binutils fixing.  In any case fixing should
be easy.

  Ralf


--OgqxwSJOaUobr8KG--

From owner-linux-mips@oss.sgi.com Fri Feb 23 10:36:29 2001
Received:  by oss.sgi.com id <S554040AbRBWSgJ>;
	Fri, 23 Feb 2001 10:36:09 -0800
Received: from snowman.foobazco.org ([198.144.194.230]:48811 "HELO
        mail.foobazco.org") by oss.sgi.com with SMTP id <S554029AbRBWSfz>;
	Fri, 23 Feb 2001 10:35:55 -0800
Received: by mail.foobazco.org (Postfix, from userid 1014)
	id BE28B109CE; Fri, 23 Feb 2001 10:35:56 -0800 (PST)
Date:   Fri, 23 Feb 2001 10:35:56 -0800
From:   Keith M Wesolowski <wesolows@foobazco.org>
To:     Ray <rcarlino@home.com>
Cc:     linux-mips@oss.sgi.com
Subject: Re: Hardware support
Message-ID: <20010223103555.A333@foobazco.org>
References: <01022310232702.19197@fleance.cr.usgs.gov>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <01022310232702.19197@fleance.cr.usgs.gov>; from rcarlino@home.com on Fri, Feb 23, 2001 at 10:23:27AM +0000
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing

On Fri, Feb 23, 2001 at 10:23:27AM +0000, Ray wrote:

> I am getting a SGI Challenge L with r4400 processors and would like to know 
> the status of a linux port that will run on it????

None exists.  The systems which are supported are listed in the FAQ.

-- 
Keith M Wesolowski <wesolows@foobazco.org> http://foobazco.org/~wesolows
------(( Project Foobazco Coordinator and Network Administrator ))------

From owner-linux-mips@oss.sgi.com Fri Feb 23 16:04:01 2001
Received:  by oss.sgi.com id <S553811AbRBXADl>;
	Fri, 23 Feb 2001 16:03:41 -0800
Received: from u-183-20.karlsruhe.ipdial.viaginterkom.de ([62.180.20.183]:1522
        "EHLO dea.waldorf-gmbh.de") by oss.sgi.com with ESMTP
	id <S553796AbRBXAD3>; Fri, 23 Feb 2001 16:03:29 -0800
Received: (from ralf@localhost)
	by dea.waldorf-gmbh.de (8.11.1/8.11.1) id f1NBbe113526;
	Fri, 23 Feb 2001 12:37:40 +0100
Date:   Fri, 23 Feb 2001 12:37:40 +0100
From:   Ralf Baechle <ralf@oss.sgi.com>
To:     ldavies@oz.agile.tv
Cc:     linux-mips@oss.sgi.com
Subject: Re: Small remote debug kernels??
Message-ID: <20010223123739.A13254@bacchus.dhis.org>
References: <3A95E682.982AC529@agile.tv>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <3A95E682.982AC529@agile.tv>; from ldavies@agile.tv on Fri, Feb 23, 2001 at 02:26:42PM +1000
X-Accept-Language: de,en,fr
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing

On Fri, Feb 23, 2001 at 02:26:42PM +1000, Liam Davies wrote:

> I would like to remote debug my kernel.
> On the Cobalt box I have there is (allegedly) a bootloader bug that
> stops the
> kernel being any larger than 1M/2.5M, compressed/uncompressed.

I've never read the bootloader code during my Cobalt time but supposedly
it reserves a fixed amount of memory for loading and decompressing the
kernel.  As the firmware uses gzip routines to decompress the loaded
kernel and has an entire Linux kernel in it for reading the real kernel
from an ext2 filesystem it must be covered by the GPL and you can ask
Cobalt^WSun for the source to change this limit.

> I have stripped the kernel bare but can't get much lower than 6M
> uncompressed.
> 
> Is there any way I can have a mini-remote debugging kernel??

Either your kernel isn't really stripped or you have a huge configuration.
The 64-bit Origin kernel which I'm using here is 3037235 (unstripped) /
1874064 (striped) in size.  Did you strip symbols only and left debug
information in the object file?

  Ralf

From owner-linux-mips@oss.sgi.com Fri Feb 23 17:54:52 2001
Received:  by oss.sgi.com id <S553925AbRBXBym>;
	Fri, 23 Feb 2001 17:54:42 -0800
Received: from sovereign.org ([209.180.91.170]:6272 "EHLO lux.homenet")
	by oss.sgi.com with ESMTP id <S553720AbRBXByT>;
	Fri, 23 Feb 2001 17:54:19 -0800
Received: (from jfree@localhost)
	by lux.homenet (8.11.2/8.11.2/Debian 8.11.2-1) id f1N8GPH05776
	for linux-mips@oss.sgi.com; Fri, 23 Feb 2001 01:16:25 -0700
From:   Jim Freeman <jfree@sovereign.org>
Date:   Fri, 23 Feb 2001 01:16:25 -0700
To:     linux-mips@oss.sgi.com
Subject: Redundant Configure.help entries?
Message-ID: <20010223011625.A5748@sovereign.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.3.15i
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing

mips.cvs/Documentation/Configure.help has redundant
CONFIG_DDB5074 entries ??

	Support for NEC DDB Vrc-5074
	CONFIG_DDB5074
	  This enables support for the VR5000-based NEC DDB Vrc-5074
	  evaluation board.

	Support for NEC DDB Vrc-5476
	CONFIG_DDB5476
	  This enables support for the R5432-based NEC DDB Vrc-5476
	  evaluation board.

	  Features : kernel debugging, serial terminal, NFS root fs, on-board
	  ether port (with a patch to tulip driver), IDE controller,
	  PS2 keyboard, PS2 mouse, etc.

	  TODO : USB, Compact-PCI interface.

	Support for MIPS Atlas board
	CONFIG_DDB5074
	  This enables support for the QED R5231-based MIPS Atlas evaluation
	  board.

	Support for MIPS Malta board
	CONFIG_DDB5074
	  This enables support for the VR5000-based MIPS Malta evaluation
	  board.

From owner-linux-mips@oss.sgi.com Fri Feb 23 18:02:02 2001
Received:  by oss.sgi.com id <S553852AbRBXCBw>;
	Fri, 23 Feb 2001 18:01:52 -0800
Received: from [203.101.127.117] ([203.101.127.117]:39040 "EHLO eris.xware.cx")
	by oss.sgi.com with ESMTP id <S553746AbRBXCBf>;
	Fri, 23 Feb 2001 18:01:35 -0800
Received: (from chris@localhost)
	by eris.xware.cx (8.11.0/8.11.0) id f1O228H21210
	for linux-mips@oss.sgi.com; Sat, 24 Feb 2001 13:02:08 +1100
Date:   Sat, 24 Feb 2001 13:02:08 +1100
From:   Crossfire <xfire@xware.cx>
To:     linux-mips@oss.sgi.com
Subject: troubles with Indy
Message-ID: <20010224130208.B21094@eris.xware.cx>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
X-Face: 1_cwV#-Eyv`RXe|JgLID]fWI-xnk962I)$LufLo.W'Y;S-B<P]U'$*^!=\RU3]^If:nE;RO
 8tb)CB{E"ErEo7Qv-%^j.tFbto}`2ClPpS5yXT6[Ig|o?iJg1vK7;:XQP#F>8jl#<,n-@'~7WHtl;J
 DJ&RiZA
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing

Hi All.

I've just acquired a R4600 Indy which I've proceed to attempt to seed
a debian installation on.

I've crosscompiled a linux-2.4.1 kernel from CVS [after a little code
patching] to find that the kernel boots fine, and can do most things,
except run tar, and a few other binaries from the debian image.

If I use the linux-2.4.1-test2 kernel from test, I can run tar, but it
can't read filesystems correctly, and the init process fails.  Also,
other operations become extremely unreliable.

Is there a 'known working' kernel image floating about somewhere? or
are things generally at this silghtly flaky point?

Or is something else completely different to blame?

TIA

C.
-- 
--==============================================--
  Crossfire      | This email was brought to you
  xfire@xware.cx | on 100% Recycled Electrons
--==============================================--

From owner-linux-mips@oss.sgi.com Sat Feb 24 02:45:46 2001
Received:  by oss.sgi.com id <S553813AbRBXKpg>;
	Sat, 24 Feb 2001 02:45:36 -0800
Received: from u-182-21.karlsruhe.ipdial.viaginterkom.de ([62.180.21.182]:62962
        "EHLO dea.waldorf-gmbh.de") by oss.sgi.com with ESMTP
	id <S553797AbRBXKpV>; Sat, 24 Feb 2001 02:45:21 -0800
Received: (from ralf@localhost)
	by dea.waldorf-gmbh.de (8.11.1/8.11.1) id f1OAis605060;
	Sat, 24 Feb 2001 11:44:54 +0100
Date:   Sat, 24 Feb 2001 11:44:54 +0100
From:   Ralf Baechle <ralf@oss.sgi.com>
To:     Jim Freeman <jfree@sovereign.org>
Cc:     linux-mips@oss.sgi.com
Subject: Re: Redundant Configure.help entries?
Message-ID: <20010224114454.B3280@bacchus.dhis.org>
References: <20010223011625.A5748@sovereign.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <20010223011625.A5748@sovereign.org>; from jfree@sovereign.org on Fri, Feb 23, 2001 at 01:16:25AM -0700
X-Accept-Language: de,en,fr
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing

On Fri, Feb 23, 2001 at 01:16:25AM -0700, Jim Freeman wrote:

> mips.cvs/Documentation/Configure.help has redundant
> CONFIG_DDB5074 entries ??

Just the CONFIG_* label was wrong.  Fixed.

  Ralf

From owner-linux-mips@oss.sgi.com Sat Feb 24 06:12:26 2001
Received:  by oss.sgi.com id <S553906AbRBXOMR>;
	Sat, 24 Feb 2001 06:12:17 -0800
Received: from cabal.wiggy.net ([195.64.66.141]:11524 "EHLO fog.mors.wiggy.net")
	by oss.sgi.com with ESMTP id <S553838AbRBXOLx>;
	Sat, 24 Feb 2001 06:11:53 -0800
Received: (from wichert@localhost)
	by fog.mors.wiggy.net (8.11.2/8.11.2/Debian 8.11.2-1) id f1OCfLu04948;
	Sat, 24 Feb 2001 13:41:21 +0100
Date:   Sat, 24 Feb 2001 13:41:21 +0100
From:   Wichert Akkerman <wichert@cistron.nl>
To:     Ralf Baechle <ralf@oss.sgi.com>
Cc:     "'linux-mips@oss.sgi.com'" <linux-mips@oss.sgi.com>,
        linux-mips <linux-mips@fnet.fr>
Subject: Re: strace package
Message-ID: <20010224134121.A4925@cistron.nl>
Mail-Followup-To: Ralf Baechle <ralf@oss.sgi.com>,
	"'linux-mips@oss.sgi.com'" <linux-mips@oss.sgi.com>,
	linux-mips <linux-mips@fnet.fr>
References: <20010116134453.B12858@bacchus.dhis.org> <Pine.GSO.3.96.1010116171558.5546M-100000@delta.ds2.pg.gda.pl> <20010219133346.A17354@cistron.nl> <20010220213703.B2086@bacchus.dhis.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.3.15i
In-Reply-To: <20010220213703.B2086@bacchus.dhis.org>; from ralf@oss.sgi.com on Tue, Feb 20, 2001 at 09:37:03PM +0100
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing

Previously Ralf Baechle wrote:
> Conincidentally I today built strace-cvs for MIPS before receiving your
> message and found it to be working just fine.

Good!

> The only bug which my last several month old build from an older
> snapshot doesn't have is that syscall 4129 (from memory, number may be
> incorrect) gets decoded as a syscall with very many arguments (~ 20).

Hmm, 4129 is delete_module, which is handled exactly like sys_chdir
(syscal with one string argument). Looking at the syscall table I
can't find any syscall with that many argument, the highest number
I can find is 6 (mmap, recvfrom and sendto).

Wichert.

-- 
  _________________________________________________________________
 /       Nothing is fool-proof to a sufficiently talented fool     \
| wichert@cistron.nl                  http://www.liacs.nl/~wichert/ |
| 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0  2805 3CB8 9250 2FA3 BC2D |

From owner-linux-mips@oss.sgi.com Sat Feb 24 19:04:05 2001
Received:  by oss.sgi.com id <S554084AbRBYDDz>;
	Sat, 24 Feb 2001 19:03:55 -0800
Received: from snowman.foobazco.org ([198.144.194.230]:43440 "HELO
        mail.foobazco.org") by oss.sgi.com with SMTP id <S554081AbRBYDDb>;
	Sat, 24 Feb 2001 19:03:31 -0800
Received: from pimp.foobazco.org (pimp.foobazco.org [198.144.194.227])
	by mail.foobazco.org (Postfix) with ESMTP
	id 1E5A7109CE; Sat, 24 Feb 2001 19:03:35 -0800 (PST)
Received: by pimp.foobazco.org (Postfix, from userid 1014)
	id B2A0910003; Sat, 24 Feb 2001 19:03:24 -0800 (PST)
Date:   Sat, 24 Feb 2001 19:03:24 -0800
From:   Keith M Wesolowski <wesolows@foobazco.org>
To:     Pete Popov <ppopov@mvista.com>
Cc:     Ralf Baechle <ralf@uni-koblenz.de>,
        "linux-mips@oss.sgi.com" <linux-mips@oss.sgi.com>
Subject: Re: loops_per_sec
Message-ID: <20010224190323.A1373@foobazco.org>
References: <3A95C0E2.5173DEA6@mvista.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="rwEMma7ioTxnRzrJ"
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <3A95C0E2.5173DEA6@mvista.com>; from ppopov@mvista.com on Thu, Feb 22, 2001 at 05:46:10PM -0800
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing


--rwEMma7ioTxnRzrJ
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

On Thu, Feb 22, 2001 at 05:46:10PM -0800, Pete Popov wrote:

> The variable loops_per_sec has become loops_per_jiffy around 2.4.1,
> breaking the mips delay functions.  I edited include/asm-mips/delay.h to
> rename the variable.  There's other places in mips64 where loops_per_sec
> is being used. Furthermore, since it's loops per "jiffy", the delay must
> be further increased by a factor of HZ.  

A partial fix appears to be in place for mips already.  This patch
should complete the picture.  I need people using mips and mips64 to
confirm that it works please; I can't test it right now.

-- 
Keith M Wesolowski <wesolows@foobazco.org> http://foobazco.org/~wesolows
------(( Project Foobazco Coordinator and Network Administrator ))------

--rwEMma7ioTxnRzrJ
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="jiffy.diff"

Index: arch/mips/kernel/setup.c
===================================================================
RCS file: /cvs/linux/arch/mips/kernel/setup.c,v
retrieving revision 1.53
diff -u -r1.53 setup.c
--- arch/mips/kernel/setup.c	2001/02/22 04:12:11	1.53
+++ arch/mips/kernel/setup.c	2001/02/25 02:34:49
@@ -62,8 +62,6 @@
  */
 char cyclecounter_available;
 
-unsigned long loops_per_sec;
-
 /*
  * There are several bus types available for MIPS machines.  "RISC PC"
  * type machines have ISA, EISA, VLB or PCI available, DECstations
Index: arch/mips64/kernel/proc.c
===================================================================
RCS file: /cvs/linux/arch/mips64/kernel/proc.c,v
retrieving revision 1.4
diff -u -r1.4 proc.c
--- arch/mips64/kernel/proc.c	2000/10/26 23:43:28	1.4
+++ arch/mips64/kernel/proc.c	2001/02/25 02:34:49
@@ -48,8 +48,8 @@
 		       mach_group_to_name[mips_machgroup][mips_machtype]);
 */
 		len += sprintf(buffer + len, "BogoMIPS\t\t: %lu.%02lu\n",
-		       (loops_per_sec + 2500) / 500000,
-	               ((loops_per_sec + 2500) / 5000) % 100);
+		       (loops_per_jiffy + 2500) / (500000/HZ),
+	               ((loops_per_jiffy + 2500) / (5000/HZ)) % 100);
 /*		len += sprintf(buffer + len, "Number of cpus\t\t: %d\n", smp_num_cpus);*/
 #if defined (__MIPSEB__)
 		len += sprintf(buffer + len, "byteorder\t\t: big endian\n");
Index: arch/mips64/kernel/setup.c
===================================================================
RCS file: /cvs/linux/arch/mips64/kernel/setup.c,v
retrieving revision 1.17
diff -u -r1.17 setup.c
--- arch/mips64/kernel/setup.c	2001/01/10 17:17:56	1.17
+++ arch/mips64/kernel/setup.c	2001/02/25 02:34:50
@@ -56,8 +56,6 @@
  */
 char cyclecounter_available;
 
-unsigned long loops_per_sec;
-
 /*
  * Set if box has EISA slots.
  */
Index: include/asm-mips/delay.h
===================================================================
RCS file: /cvs/linux/include/asm-mips/delay.h,v
retrieving revision 1.9
diff -u -r1.9 delay.h
--- include/asm-mips/delay.h	2001/01/10 17:18:04	1.9
+++ include/asm-mips/delay.h	2001/02/25 02:34:56
@@ -11,7 +11,7 @@
 
 #include <linux/config.h>
 
-extern unsigned long loops_per_sec;
+extern unsigned long loops_per_jiffy;
 
 extern __inline__ void
 __delay(unsigned long loops)
@@ -35,21 +35,21 @@
  * first constant multiplications gets optimized away if the delay is
  * a constant)
  */
-extern __inline__ void __udelay(unsigned long usecs, unsigned long lps)
+extern __inline__ void __udelay(unsigned long usecs, unsigned long lpj)
 {
 	unsigned long lo;
 
-	usecs *= 0x000010c6;		/* 2**32 / 1000000 */
+	usecs *= 0x00068db8;		/* 2**32 / (1000000 / HZ) */
 	__asm__("multu\t%2,%3"
 		:"=h" (usecs), "=l" (lo)
-		:"r" (usecs),"r" (lps));
+		:"r" (usecs),"r" (lpj));
 	__delay(usecs);
 }
 
 #ifdef CONFIG_SMP
 #define __udelay_val cpu_data[smp_processor_id()].udelay_val
 #else
-#define __udelay_val loops_per_sec
+#define __udelay_val loops_per_jiffy
 #endif
 
 #define udelay(usecs) __udelay((usecs),__udelay_val)
Index: include/asm-mips64/delay.h
===================================================================
RCS file: /cvs/linux/include/asm-mips64/delay.h,v
retrieving revision 1.7
diff -u -r1.7 delay.h
--- include/asm-mips64/delay.h	2001/01/10 17:18:04	1.7
+++ include/asm-mips64/delay.h	2001/02/25 02:34:56
@@ -12,7 +12,7 @@
 
 #include <linux/config.h>
 
-extern unsigned long loops_per_sec;
+extern unsigned long loops_per_jiffy;
 
 extern __inline__ void
 __delay(unsigned long loops)
@@ -36,21 +36,21 @@
  * first constant multiplications gets optimized away if the delay is
  * a constant)
  */
-extern __inline__ void __udelay(unsigned long usecs, unsigned long lps)
+extern __inline__ void __udelay(unsigned long usecs, unsigned long lpj)
 {
 	unsigned long lo;
 
-	usecs *= 0x000010c6f7a0b5edUL;		/* 2**64 / 1000000 */
+	usecs *= 0x00068db8bac710cbUL;		/* 2**64 / (1000000 / HZ) */
 	__asm__("dmultu\t%2,%3"
 		:"=h" (usecs), "=l" (lo)
-		:"r" (usecs),"r" (lps));
+		:"r" (usecs),"r" (lpj));
 	__delay(usecs);
 }
 
 #ifdef CONFIG_SMP
 #define __udelay_val cpu_data[smp_processor_id()].udelay_val
 #else
-#define __udelay_val loops_per_sec
+#define __udelay_val loops_per_jiffy
 #endif
 
 #define udelay(usecs) __udelay((usecs),__udelay_val)
Index: include/asm-mips64/smp.h
===================================================================
RCS file: /cvs/linux/include/asm-mips64/smp.h,v
retrieving revision 1.3
diff -u -r1.3 smp.h
--- include/asm-mips64/smp.h	2000/08/08 18:54:51	1.3
+++ include/asm-mips64/smp.h	2001/02/25 02:34:56
@@ -10,7 +10,7 @@
 
 #if 0
 struct cpuinfo_mips {				/* XXX  */
-	unsigned long loops_per_sec;
+	unsigned long loops_per_jiffy;
 	unsigned long last_asn;
 	unsigned long *pgd_cache;
 	unsigned long *pte_cache;

--rwEMma7ioTxnRzrJ--

From owner-linux-mips@oss.sgi.com Sun Feb 25 01:08:28 2001
Received:  by oss.sgi.com id <S554169AbRBYJIS>;
	Sun, 25 Feb 2001 01:08:18 -0800
Received: from [194.90.113.98] ([194.90.113.98]:7428 "EHLO
        yes.home.krftech.com") by oss.sgi.com with ESMTP id <S554167AbRBYJIA>;
	Sun, 25 Feb 2001 01:08:00 -0800
Received: from jungo.com (michaels@kobie.home.krftech.com [199.204.71.69])
	by yes.home.krftech.com (8.8.7/8.8.7) with ESMTP id MAA13261;
	Sun, 25 Feb 2001 12:12:33 +0200
From:   michaels@jungo.com
Message-ID: <3A98CB15.CE4DE67D@jungo.com>
Date:   Sun, 25 Feb 2001 11:06:29 +0200
Organization: Jungo LTD
X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.17-21mdk i686)
X-Accept-Language: en
MIME-Version: 1.0
To:     Tom Appermont <tea@sonycom.com>, linux-mips@oss.sgi.com
Subject: Re: ELF header kernel module wrong?
References: <20010223151355.A9091@ginger.sonytel.be>
Content-Type: text/plain; charset=koi8-r
Content-Transfer-Encoding: 7bit
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing

Tom, 

I have seen this problem too. My kernel is 2.2.14 though, using modutils
2.3.x.
I tried to do many things with modutils, tried even not to check the
boundary, but that caused crashes. The only solution that worked for me
was to step downwards to modutils 2.2.2. Even then, depmod segfaults
unless you put a remark on obj_free in some place... Hope you get a
better solution. 
I don't think that the reason for this is in modutils though. We have
one particularly complex (and thus big) module, written for DSL device,
which worked with these modutils without any problem. This module
however did not come from the kernel tree, but was compiled with the
same cross toolchain. Identical compilation flags were used in both
cases, but the sections inside ELF were named differently and their
order was slightly different.

More information can be provided upon request :-)

Tom Appermont wrote:
> 
> Greetings,
> 
> I'm trying to get modules to work on my R5000 little endian
> target, linux 2.4.1 + modutils 2.4.2 .
> 
> When I insmod a module, I get error messages like:
> 
> [root@192 /]# insmod dummy.o
> dummy.o: local symbol gcc2_compiled. with index 10 exceeds local_symtab_size 10
> dummy.o: local symbol __gnu_compiled_c with index 11 exceeds local_symtab_size 10
> dummy.o: local symbol __module_kernel_version with index 12 exceeds local_symtab_size 10
> dummy.o: local symbol set_multicast_list with index 13 exceeds local_symtab_size 10
> dummy.o: local symbol dummy_init with index 14 exceeds local_symtab_size 10
> dummy.o: local symbol dummy_xmit with index 15 exceeds local_symtab_size 10
> dummy.o: local symbol dummy_get_stats with index 18 exceeds local_symtab_size 10
> dummy.o: local symbol dummy_init_module with index 21 exceeds local_symtab_size 10
> dummy.o: local symbol dev_dummy with index 22 exceeds local_symtab_size 10
> dummy.o: local symbol dummy_cleanup_module with index 26 exceeds local_symtab_size 10
> [root@192 /]#
> 
> Looking at the source code of modutils, I suspect that there is
> something wrong with the ELF header of the module (the sh_info
> field of the SYMTAB section is 0xa while it should be 0x17 ??).
> ELF header is attached below. The command used to compile the
> module is :
> 
> mipsel-linux-gcc -I/usr/src/linux/include/asm/gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -fno-strict-aliasing -G 0 -mno-abicalls -fno-pic -mcpu=r8000 -mips2 -Wa,--trap -pipe -DMODULE -mlong-calls
> 
> I use egcs 1.2.1 + binutils 2.9.5. Is this a problem with my
> binutils?
> 
> Tom

-- 
Sincerely yours,
Michael Shmulevich
______________________________________
Software Developer
Jungo - R&D 
email: michaels@jungo.com
web: http://www.jungo.com
Phone: 1-877-514-0537(USA)  +972-9-8859365(Worldwide) ext. 233
Fax:   1-877-514-0538(USA)  +972-9-8859366(Worldwide)

From owner-linux-mips@oss.sgi.com Sun Feb 25 01:39:28 2001
Received:  by oss.sgi.com id <S554171AbRBYJjS>;
	Sun, 25 Feb 2001 01:39:18 -0800
Received: from [194.90.113.98] ([194.90.113.98]:10244 "EHLO
        yes.home.krftech.com") by oss.sgi.com with ESMTP id <S554168AbRBYJjE>;
	Sun, 25 Feb 2001 01:39:04 -0800
Received: from jungo.com (michaels@kobie.home.krftech.com [199.204.71.69])
	by yes.home.krftech.com (8.8.7/8.8.7) with ESMTP id MAA13516;
	Sun, 25 Feb 2001 12:43:48 +0200
From:   michaels@jungo.com
Message-ID: <3A98D268.90A2D50B@jungo.com>
Date:   Sun, 25 Feb 2001 11:37:44 +0200
Organization: Jungo LTD
X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.17-21mdk i686)
X-Accept-Language: en
MIME-Version: 1.0
To:     Wichert Akkerman <wichert@cistron.nl>
CC:     Ralf Baechle <ralf@oss.sgi.com>,
        "'linux-mips@oss.sgi.com'" <linux-mips@oss.sgi.com>,
        linux-mips <linux-mips@fnet.fr>
Subject: Re: strace package
References: <20010116134453.B12858@bacchus.dhis.org> <Pine.GSO.3.96.1010116171558.5546M-100000@delta.ds2.pg.gda.pl> <20010219133346.A17354@cistron.nl> <20010220213703.B2086@bacchus.dhis.org> <20010224134121.A4925@cistron.nl>
Content-Type: text/plain; charset=koi8-r
Content-Transfer-Encoding: 7bit
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing

Wichert Akkerman wrote:
> 
> Previously Ralf Baechle wrote:
> > Conincidentally I today built strace-cvs for MIPS before receiving your
> > message and found it to be working just fine.
> 
> Good!
> 

I wonder whether it is my sillines, or something is wrong with strace or
my mips tools. Checked out clean version from
cvs.strace.sourceforge.net:/cvsroot/strace, run configure "NATIVELY" on
mips32 system and got a whole bunch of errors on strace.c :

gcc -Wall -DHAVE_CONFIG_H   -I. -Ilinux/mips -I./linux/mips -Ilinux
-I./linux -D_GNU_SOURCE  -c syscall.c
syscall.c: In function `sys_sysmips':
syscall.c:103: parameter `sysent0' is initialized
syscall.c:106: parameter `nsyscalls0' is initialized
syscall.c:132: parameter `errnoent0' is initialized
In file included from syscall.c:133:
linux/mips/errnoent.h:1: warning: initialization from incompatible
pointer type linux/mips/errnoent.h:2: warning: excess elements in scalar
initializer after `errnoent0'
linux/mips/errnoent.h:3: warning: excess elements in scalar initializer
after `errnoent0'
linux/mips/errnoent.h:4: warning: excess elements in scalar initializer
after `errnoent0'
linux/mips/errnoent.h:5: warning: excess elements in scalar initializer
after `errnoent0'
linux/mips/errnoent.h:6: warning: excess elements in scalar initializer
after `errnoent0'
... < aroud 1000 errors like these >
syscall.c:135: parameter `nerrnos0' is initialized
syscall.c:158: warning: parameter names (without types) in function
declaration
syscall.c:158: parse error before `int'
syscall.c:158: declaration for parameter `set_personality' but no such
parameter
syscall.c:154: declaration for parameter `current_personality' but no
such parameter
syscall.c:152: declaration for parameter `nerrnos' but no such parameter
syscall.c:151: declaration for parameter `errnoent' but no such
parameter
syscall.c:135: declaration for parameter `nerrnos0' but no such
parameter
syscall.c:132: declaration for parameter `errnoent0' but no such
parameter
syscall.c:123: declaration for parameter `nsyscalls' but no such
parameter
syscall.c:122: declaration for parameter `sysent' but no such parameter
syscall.c:106: declaration for parameter `nsyscalls0' but no such
parameter
syscall.c:103: declaration for parameter `sysent0' but no such parameter
linux/syscall.h:183: declaration for parameter `sys_capset' but no such
parameter
linux/syscall.h:183: declaration for parameter `sys_capget' but no such
parameter
linux/syscall.h:182: declaration for parameter `sys_utimes' but no such
parameter
linux/syscall.h:182: declaration for parameter `sys_getdtablesize' but
no such parameter
linux/syscall.h:182: declaration for parameter `sys_gethostname' but no
such parameter
linux/syscall.h:182: declaration for parameter `sys_setpgrp' but no such
parameter
syscall.c:160: `personality' undeclared (first use this function)
syscall.c:160: (Each undeclared identifier is reported only once
syscall.c:160: for each function it appears in.)

Here's the info:
[michaels@verdi strace]$ gcc --version
egcs-2.90.27 980315 (egcs-1.0.2
release)                                        
[michaels@verdi strace]$ rpm -q glibc
glibc-2.0.6-4                                                                   
[michaels@verdi strace]$ uname -a
Linux verdi.home.krftech.com 2.2.12-MIPS-01.05 #1 Thu Sep 7 11:36:42
CEST 2000 mips unknown 
[michaels@verdi strace]$ cat /proc/cpuinfo
cpu                     : MIPS
cpu model               : MIPS 5Kc V0.1
system type             : unknown unknown
BogoMIPS                : 39.94
byteorder               : big endian
unaligned accesses      : 0
wait instruction        : no
microsecond timers      : no
extra interrupt vector  : yes
hardware watchpoint     : yes
VCED exceptions         : not available
VCEI exceptions         : not
available                                         

Exactly same code compiles on i386 silently and clean.
Audience, please, what seems to be my problem?

Sincerely yours,
Michael Shmulevich
______________________________________
Software Developer
Jungo - R&D 
email: michaels@jungo.com
web: http://www.jungo.com
Phone: 1-877-514-0537(USA)  +972-9-8859365(Worldwide) ext. 233
Fax:   1-877-514-0538(USA)  +972-9-8859366(Worldwide)

From owner-linux-mips@oss.sgi.com Sun Feb 25 14:18:21 2001
Received:  by oss.sgi.com id <S554213AbRBYWSL>;
	Sun, 25 Feb 2001 14:18:11 -0800
Received: from u-220-10.karlsruhe.ipdial.viaginterkom.de ([62.180.10.220]:18934
        "EHLO dea.waldorf-gmbh.de") by oss.sgi.com with ESMTP
	id <S553764AbRBYWRx>; Sun, 25 Feb 2001 14:17:53 -0800
Received: (from ralf@localhost)
	by dea.waldorf-gmbh.de (8.11.1/8.11.1) id f1PCPnH11106;
	Sun, 25 Feb 2001 13:25:49 +0100
Date:   Sun, 25 Feb 2001 13:25:49 +0100
From:   Ralf Baechle <ralf@oss.sgi.com>
To:     michaels@jungo.com
Cc:     Wichert Akkerman <wichert@cistron.nl>,
        "'linux-mips@oss.sgi.com'" <linux-mips@oss.sgi.com>,
        linux-mips <linux-mips@fnet.fr>
Subject: Re: strace package
Message-ID: <20010225132549.A10624@bacchus.dhis.org>
References: <20010116134453.B12858@bacchus.dhis.org> <Pine.GSO.3.96.1010116171558.5546M-100000@delta.ds2.pg.gda.pl> <20010219133346.A17354@cistron.nl> <20010220213703.B2086@bacchus.dhis.org> <20010224134121.A4925@cistron.nl> <3A98D268.90A2D50B@jungo.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <3A98D268.90A2D50B@jungo.com>; from michaels@jungo.com on Sun, Feb 25, 2001 at 11:37:44AM +0200
X-Accept-Language: de,en,fr
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing

On Sun, Feb 25, 2001 at 11:37:44AM +0200, michaels@jungo.com wrote:

> Exactly same code compiles on i386 silently and clean.
> Audience, please, what seems to be my problem?

I've used glibc 2.1.95.

  Ralf

From owner-linux-mips@oss.sgi.com Sun Feb 25 16:52:42 2001
Received:  by oss.sgi.com id <S554221AbRBZAwc>;
	Sun, 25 Feb 2001 16:52:32 -0800
Received: from deliverator.sgi.com ([204.94.214.10]:33307 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S554217AbRBZAwQ>;
	Sun, 25 Feb 2001 16:52:16 -0800
Received: from sydney.sydney.sgi.com (sydney.sydney.sgi.com [134.14.48.2]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via SMTP id QAA11195
	for <linux-mips@oss.sgi.com>; Sun, 25 Feb 2001 16:51:10 -0800 (PST)
	mail_from (kaos@melbourne.sgi.com)
Received: from kao2.melbourne.sgi.com by sydney.sydney.sgi.com via ESMTP (950413.SGI.8.6.12/930416.SGI)
	 id LAA23553; Mon, 26 Feb 2001 11:50:48 +1100
X-Mailer: exmh version 2.1.1 10/15/1999
From:   Keith Owens <kaos@melbourne.sgi.com>
To:     michaels@jungo.com
cc:     Tom Appermont <tea@sonycom.com>, linux-mips@oss.sgi.com
Subject: Re: ELF header kernel module wrong? 
In-reply-to: Your message of "Sun, 25 Feb 2001 11:06:29 +0200."
             <3A98CB15.CE4DE67D@jungo.com> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date:   Mon, 26 Feb 2001 11:50:50 +1100
Message-ID: <11701.983148650@kao2.melbourne.sgi.com>
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing

On Sun, 25 Feb 2001 11:06:29 +0200, 
michaels@jungo.com wrote:
>I have seen this problem too. My kernel is 2.2.14 though, using modutils
>2.3.x.
>I tried to do many things with modutils, tried even not to check the
>boundary, but that caused crashes. The only solution that worked for me
>was to step downwards to modutils 2.2.2. Even then, depmod segfaults
>unless you put a remark on obj_free in some place... Hope you get a
>better solution. 

All you are doing by using old modutils is hiding the problem and
risking storage corruption.  modutils follows the ELF specification

  "A symbol table section's sh_info section header member holds the
  symbol table index for the first non-local symbol."

The mips toolchain is generating local symbols with index numbers
greater than sh_info.  Old modutils did not check for that and silently
created corrupt modules.  New modutils check this field for
correctness.  Fix the mips toolchain.


From owner-linux-mips@oss.sgi.com Mon Feb 26 02:22:46 2001
Received:  by oss.sgi.com id <S553783AbRBZKWh>;
	Mon, 26 Feb 2001 02:22:37 -0800
Received: from [210.241.238.126] ([210.241.238.126]:60168 "EHLO
        viditec-netmedia.com.tw") by oss.sgi.com with ESMTP
	id <S553775AbRBZKWO>; Mon, 26 Feb 2001 02:22:14 -0800
Received: from kjlin ([210.241.238.122])
	by viditec-netmedia.com.tw (8.9.3/8.8.7) with SMTP id TAA09319;
	Mon, 26 Feb 2001 19:02:36 +0800
Message-ID: <037601c09fd4$e81ef540$056aaac0@kjlin>
From:   "kjlin" <kj.lin@viditec-netmedia.com.tw>
To:     "Joe deBlaquiere" <jadb@redhat.com>
Cc:     <linux-mips@oss.sgi.com>
References: <Pine.GSO.4.10.10102220752430.13615-100000@escobaria.sonytel.be> <3A95F83D.9030600@redhat.com>
Subject: Re: Does linux support for microprocessor without MMU?
Date:   Mon, 26 Feb 2001 17:17:13 +0800
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2919.6600
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing

Is the uClibc/uC-glibc platform dependent??
Can we use the "normal linux  glibc" instead of uClibc/uC-glibc when running
uClinux??
As to object file format, is it real necessary to modify the elf2flt
program?
On the other hand, there is an isssue which confuses me.
That is, i had already got a cross-compiler for compiling the "normal linux"
kernel used.
Should i need to remake a cross-compiler to compile the uClinux kernel and
applications?

Thanks.


----- Original Message -----
From: "Joe deBlaquiere" <jadb@redhat.com>
To: "Geert Uytterhoeven" <Geert.Uytterhoeven@sonycom.com>
Cc: "Crossfire" <xfire@xware.cx>; "kjlin" <kj.lin@viditec-netmedia.com.tw>;
<linux-mips@oss.sgi.com>
Sent: Friday, February 23, 2001 1:42 PM
Subject: Re: Does linux support for microprocessor without MMU?


> Geert Uytterhoeven wrote:
>
> > On Wed, 21 Feb 2001, Joe deBlaquiere wrote:
> >
> >>
> >> There isn't (yet) support for MIPS on uClinux.
> >
> >
> > But it can't be that hard to add support for it...
> >
> Porting the kernel isn't much worse than any other architectural port.
> Of course that's only a part of the story, since you'll need to port the
> C library (uClibc/uC-glibc) and you will have to play around with the
> object file format to make it work with FLAT binaries... If you're
> serious about doing uClinux you can find a somewhat cryptic article on
> porting to uClinux at:
>
> http://www.redhat.com/embedded/technologies/resources
>
> --
> Joe


From owner-linux-mips@oss.sgi.com Mon Feb 26 03:20:07 2001
Received:  by oss.sgi.com id <S554235AbRBZLTr>;
	Mon, 26 Feb 2001 03:19:47 -0800
Received: from [194.90.113.98] ([194.90.113.98]:22021 "EHLO
        yes.home.krftech.com") by oss.sgi.com with ESMTP id <S554201AbRBZLTb>;
	Mon, 26 Feb 2001 03:19:31 -0800
Received: from jungo.com (michaels@kobie.home.krftech.com [199.204.71.69])
	by yes.home.krftech.com (8.8.7/8.8.7) with ESMTP id OAA18369;
	Mon, 26 Feb 2001 14:23:50 +0200
From:   michaels@jungo.com
Message-ID: <3A9A3B56.B0141D21@jungo.com>
Date:   Mon, 26 Feb 2001 13:17:42 +0200
Organization: Jungo LTD
X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.17-21mdk i686)
X-Accept-Language: en
MIME-Version: 1.0
To:     Keith Owens <kaos@melbourne.sgi.com>
CC:     Tom Appermont <tea@sonycom.com>, linux-mips@oss.sgi.com
Subject: Re: ELF header kernel module wrong?
References: <11701.983148650@kao2.melbourne.sgi.com>
Content-Type: text/plain; charset=koi8-r
Content-Transfer-Encoding: 7bit
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing

Keith,

If what you say is correct, then any module created by this toolchain
would be impossible to 'insmod', and that is not the case. As I said, we
have one module which we managed to install, and it was compiled with
exactly the same toolchain. The module is quite large, has a lot of
symbols, and was NOT taken from the kernel tree. I would suspect that
there is some problem with kernel module linkage that is incompatible
with mips toolchain. 

Besides that, in "old" modultils there IS a check for symtab size, and
it did work as expected. So, what you say is only part of the truth.

Keith Owens wrote:
> 
> On Sun, 25 Feb 2001 11:06:29 +0200,
> michaels@jungo.com wrote:
> >I have seen this problem too. My kernel is 2.2.14 though, using modutils
> >2.3.x.
> >I tried to do many things with modutils, tried even not to check the
> >boundary, but that caused crashes. The only solution that worked for me
> >was to step downwards to modutils 2.2.2. Even then, depmod segfaults
> >unless you put a remark on obj_free in some place... Hope you get a
> >better solution.
> 
> All you are doing by using old modutils is hiding the problem and
> risking storage corruption.  modutils follows the ELF specification
> 
>   "A symbol table section's sh_info section header member holds the
>   symbol table index for the first non-local symbol."
> 
> The mips toolchain is generating local symbols with index numbers
> greater than sh_info.  Old modutils did not check for that and silently
> created corrupt modules.  New modutils check this field for
> correctness.  Fix the mips toolchain.

-- 
Sincerely yours,
Michael Shmulevich
______________________________________
Software Developer
Jungo - R&D 
email: michaels@jungo.com
web: http://www.jungo.com
Phone: 1-877-514-0537(USA)  +972-9-8859365(Worldwide) ext. 233
Fax:   1-877-514-0538(USA)  +972-9-8859366(Worldwide)

From owner-linux-mips@oss.sgi.com Mon Feb 26 07:46:29 2001
Received:  by oss.sgi.com id <S554242AbRBZPqT>;
	Mon, 26 Feb 2001 07:46:19 -0800
Received: from mx.mips.com ([206.31.31.226]:49569 "EHLO mx.mips.com")
	by oss.sgi.com with ESMTP id <S553782AbRBZPqH>;
	Mon, 26 Feb 2001 07:46:07 -0800
Received: from newman.mips.com (ns-dmz [206.31.31.225])
	by mx.mips.com (8.9.3/8.9.0) with ESMTP id HAA23218;
	Mon, 26 Feb 2001 07:46:02 -0800 (PST)
Received: from copfs01.mips.com (copfs01 [192.168.205.101])
	by newman.mips.com (8.9.3/8.9.0) with ESMTP id HAA02350;
	Mon, 26 Feb 2001 07:46:00 -0800 (PST)
Received: from mips.com (copsun17 [192.168.205.27])
	by copfs01.mips.com (8.9.1/8.9.0) with ESMTP id QAA12834;
	Mon, 26 Feb 2001 16:45:38 +0100 (MET)
Message-ID: <3A9A7A21.F6CE24CB@mips.com>
Date:   Mon, 26 Feb 2001 16:45:37 +0100
From:   Carsten Langgaard <carstenl@mips.com>
X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To:     Ralf Baechle <ralf@oss.sgi.com>
CC:     linux-mips@oss.sgi.com
Subject: Re: RedHat 7.0 ?
References: <3A71B011.4B82F6C3@mips.com> <20010127105409.E867@bacchus.dhis.org>
Content-Type: text/plain; charset=iso-8859-15
Content-Transfer-Encoding: 7bit
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing

Ralf Baechle wrote:

> On Fri, Jan 26, 2001 at 06:12:49PM +0100, Carsten Langgaard wrote:
> > Date:   Fri, 26 Jan 2001 18:12:49 +0100
> > From: Carsten Langgaard <carstenl@mips.com>
> > To: linux-mips@oss.sgi.com
> > Subject: RedHat 7.0 ?
> >
> > Has anyone put together an easy-to-install tar file, similar to the old
> > hard-hat 5.1 tarfile, where you could install everything though an
> > install program running on a nfs server ?
> > I really like the old hard-hat approach, it was easy to install and
> > everything seems to work, but it would be nice to have a newer release.
> > The old hard-hat install program doesn't work with the new 2.4.0 kernel.
>
> At this time we don't have an easy installer for it.  I intend to strip
> down an RH 7.0 installation which I'm running on an Origin here and put
> it up for ftp somewhen soon.

Any progress on the RH7.0 easy installer ?

>
>   Ralf

--
_    _ ____  ___   Carsten Langgaard   Mailto:carstenl@mips.com
|\  /|||___)(___   MIPS Denmark        Direct: +45 4486 5527
| \/ |||    ____)  Lautrupvang 4B      Switch: +45 4486 5555
  TECHNOLOGIES     2750 Ballerup       Fax...: +45 4486 5556
                   Denmark             http://www.mips.com




From owner-linux-mips@oss.sgi.com Mon Feb 26 10:03:51 2001
Received:  by oss.sgi.com id <S554261AbRBZSDl>;
	Mon, 26 Feb 2001 10:03:41 -0800
Received: from gatekeep.ti.com ([192.94.94.61]:43455 "EHLO gatekeep.ti.com")
	by oss.sgi.com with ESMTP id <S554258AbRBZSDc>;
	Mon, 26 Feb 2001 10:03:32 -0800
Received: from dlep8.itg.ti.com ([157.170.134.88])
	by gatekeep.ti.com (8.11.1/8.11.1) with ESMTP id f1QI3Pr00090;
	Mon, 26 Feb 2001 12:03:25 -0600 (CST)
Received: from dlep8.itg.ti.com (localhost [127.0.0.1])
	by dlep8.itg.ti.com (8.9.3/8.9.3) with ESMTP id MAA04640;
	Mon, 26 Feb 2001 12:03:25 -0600 (CST)
Received: from dlep3.itg.ti.com (dlep3-maint.itg.ti.com [157.170.133.16])
	by dlep8.itg.ti.com (8.9.3/8.9.3) with ESMTP id MAA04622;
	Mon, 26 Feb 2001 12:03:24 -0600 (CST)
Received: from ti.com (IDENT:bbrown@bbrowndt.sc.ti.com [158.218.100.126])
	by dlep3.itg.ti.com (8.9.3/8.9.3) with ESMTP id MAA06449;
	Mon, 26 Feb 2001 12:03:24 -0600 (CST)
Message-ID: <3A9A9B52.C990A581@ti.com>
Date:   Mon, 26 Feb 2001 11:07:15 -0700
From:   Brady Brown <bbrown@ti.com>
Organization: Texas Instruments
X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14-5.0 i686)
X-Accept-Language: en
MIME-Version: 1.0
To:     Tom Appermont <tea@sonycom.com>
CC:     linux-mips@oss.sgi.com
Subject: Re: ELF header kernel module wrong?
References: <20010223151355.A9091@ginger.sonytel.be>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing

Tom Appermont wrote:

> Greetings,
>
> I'm trying to get modules to work on my R5000 little endian
> target, linux 2.4.1 + modutils 2.4.2 .
>
> When I insmod a module, I get error messages like:
>
> [root@192 /]# insmod dummy.o
> dummy.o: local symbol gcc2_compiled. with index 10 exceeds local_symtab_size 10
> dummy.o: local symbol __gnu_compiled_c with index 11 exceeds local_symtab_size 10
> dummy.o: local symbol __module_kernel_version with index 12 exceeds local_symtab_size 10
> dummy.o: local symbol set_multicast_list with index 13 exceeds local_symtab_size 10
> dummy.o: local symbol dummy_init with index 14 exceeds local_symtab_size 10
> dummy.o: local symbol dummy_xmit with index 15 exceeds local_symtab_size 10
> dummy.o: local symbol dummy_get_stats with index 18 exceeds local_symtab_size 10
> dummy.o: local symbol dummy_init_module with index 21 exceeds local_symtab_size 10
> dummy.o: local symbol dev_dummy with index 22 exceeds local_symtab_size 10
> dummy.o: local symbol dummy_cleanup_module with index 26 exceeds local_symtab_size 10
> [root@192 /]#

I think the final conclusion on this problem in the old thread was that the assembler is generating ELF files that are IRIX flavored with respect to the symbol table ordering and index. I discovered by playing around that the linker was creating
correct ELF symbol tables, so as a temporary work around until the assembler is tweaked I started to incrementally link my modules with the linker `ld -r <filename>` . This eliminated the immediate problem for me.

--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Brady Brown (bbrown@ti.com)       Work:(801)619-6103
Texas Instruments: Broadband Access Group
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~



From owner-linux-mips@oss.sgi.com Mon Feb 26 12:21:53 2001
Received:  by oss.sgi.com id <S553791AbRBZUVn>;
	Mon, 26 Feb 2001 12:21:43 -0800
Received: from smtp.psdc.com ([209.125.203.83]:25162 "EHLO smtp.psdc.com")
	by oss.sgi.com with ESMTP id <S553756AbRBZUVN>;
	Mon, 26 Feb 2001 12:21:13 -0800
Received: from BANANA ([209.125.203.85])
	by smtp.psdc.com (8.8.8/8.8.8) with SMTP id MAA20819
	for <linux-mips@oss.sgi.com>; Mon, 26 Feb 2001 12:05:06 -0800
Message-ID: <001c01c09fcd$61c20070$dde0490a@BANANA>
From:   "Steven Liu" <stevenliu@psdc.com>
To:     <linux-mips@oss.sgi.com>
Subject: Where is 2.2.x kernel? 
Date:   Mon, 26 Feb 2001 00:23:22 -0800
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0019_01C09F8A.537D07A0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing

This is a multi-part message in MIME format.

------=_NextPart_000_0019_01C09F8A.537D07A0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi All:

In ftp://oss.sgi.com/pub/linux/mips/kernel/, there are many folders like =
v2.1, v2.2, and v2.3. But there is nothing in v2.2. Where could I=20
find 2.2.x kernel?=20

I would be very pleased if you can give me any information about that.=20
Here is my e-mail address:
                     =20
                     stevenliu@psdc.com

Thank you.

Steven Liu

------=_NextPart_000_0019_01C09F8A.537D07A0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.3103.1000" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>Hi All:</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>In <A=20
href=3D"ftp://oss.sgi.com/pub/linux/mips/kernel/">ftp://oss.sgi.com/pub/l=
inux/mips/kernel/</A><A=20
href=3D"ftp://oss.sgi.com/pub/linux/mips/"></A>, there are many folders =
like v2.1,=20
v2.2, and v2.3. But there is nothing in v2.2. Where could I </DIV>
<DIV><FONT face=3DArial size=3D2>find 2.2.x kernel? </FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV>I would be very pleased if you can give me any information about =
that.=20
</DIV>
<DIV>Here is my e-mail address:</DIV>
<DIV>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
</DIV>
<DIV>&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;=20
&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; stevenliu@psdc.com</DIV>
<DIV>&nbsp;</DIV>
<DIV>Thank you.</DIV>
<DIV>&nbsp;</DIV>
<DIV>Steven Liu</DIV></FONT></BODY></HTML>

------=_NextPart_000_0019_01C09F8A.537D07A0--


From owner-linux-mips@oss.sgi.com Mon Feb 26 15:09:52 2001
Received:  by oss.sgi.com id <S554277AbRBZXJm>;
	Mon, 26 Feb 2001 15:09:42 -0800
Received: from pigsty.barnyard.co.uk ([195.149.50.58]:6409 "EHLO
        pigsty.barnyard.co.uk") by oss.sgi.com with ESMTP
	id <S554270AbRBZXJ2>; Mon, 26 Feb 2001 15:09:28 -0800
Received: (from david@localhost)
	by pigsty.barnyard.co.uk (8.11.0/8.11.0) id f1QN7qw20327
	for linux-mips@oss.sgi.com; Mon, 26 Feb 2001 23:07:52 GMT
X-Authentication-Warning: pigsty.barnyard.co.uk: david set sender to david@cantrell.org.uk using -f
Date:   Mon, 26 Feb 2001 23:07:52 +0000
From:   David Cantrell <david@cantrell.org.uk>
To:     linux-mips@oss.sgi.com
Subject: Re: RedHat 7.0 ?
Message-ID: <20010226230750.A19551@pigsty.barnyard.co.uk>
References: <3A71B011.4B82F6C3@mips.com> <20010127105409.E867@bacchus.dhis.org> <3A9A7A21.F6CE24CB@mips.com>
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-md5;
	protocol="application/pgp-signature"; boundary="oyUTqETQ0mS9luUI"
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <3A9A7A21.F6CE24CB@mips.com>; from carstenl@mips.com on Mon, Feb 26, 2001 at 04:45:37PM +0100
X-public-key-is-at: http://www.cantrell.org.uk/david/public-key.txt
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing


--oyUTqETQ0mS9luUI
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Mon, Feb 26, 2001 at 04:45:37PM +0100, Carsten Langgaard wrote:

> Any progress on the RH7.0 easy installer ?

Are we talking a bootable CD?  If so, I'd *kill* for it!

--=20
David Cantrell | root@alphacomplex.org | http://www.cantrell.org.uk/david/

   Any technology distinguishable from magic is insufficiently advanced

** I read encrypted mail first, so encrypt if your message is important **

--oyUTqETQ0mS9luUI
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.2 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE6muHGQmE+qbO4leURAqWjAKCXwH0Ux0vXFtyZVL1yDbJlIVUoewCeMfVP
0AUqiERMfSb+OOzj2htIdIg=
=Jwdi
-----END PGP SIGNATURE-----

--oyUTqETQ0mS9luUI--

From owner-linux-mips@oss.sgi.com Mon Feb 26 15:41:32 2001
Received:  by oss.sgi.com id <S554276AbRBZXlM>;
	Mon, 26 Feb 2001 15:41:12 -0800
Received: from deliverator.sgi.com ([204.94.214.10]:34395 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S553847AbRBZXlA>;
	Mon, 26 Feb 2001 15:41:00 -0800
Received: from sydney.sydney.sgi.com (sydney.sydney.sgi.com [134.14.48.2]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via SMTP id PAA11895
	for <linux-mips@oss.sgi.com>; Mon, 26 Feb 2001 15:39:55 -0800 (PST)
	mail_from (kaos@melbourne.sgi.com)
Received: from kao2.melbourne.sgi.com by sydney.sydney.sgi.com via ESMTP (950413.SGI.8.6.12/930416.SGI)
	 id KAA08771; Tue, 27 Feb 2001 10:39:32 +1100
X-Mailer: exmh version 2.1.1 10/15/1999
From:   Keith Owens <kaos@melbourne.sgi.com>
To:     michaels@jungo.com
cc:     linux-mips@oss.sgi.com
Subject: Re: ELF header kernel module wrong? 
In-reply-to: Your message of "Mon, 26 Feb 2001 13:17:42 +0200."
             <3A9A3B56.B0141D21@jungo.com> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date:   Tue, 27 Feb 2001 10:39:39 +1100
Message-ID: <23954.983230779@kao2.melbourne.sgi.com>
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing

On Mon, 26 Feb 2001 13:17:42 +0200, 
michaels@jungo.com wrote:
>If what you say is correct, then any module created by this toolchain
>would be impossible to 'insmod'

Not impossible, just silently corrupted if the symbol numbers were
wrong.  modutils 2.3.11 added a sanity check on the number of local
symbols, a version before 2.3.11 would accept any local symbol number
and overrun the allocated table if the number was out of bounds.

Sometimes the toolchain creates valid symbol numbers, sometimes an
invalid number will not cause any problems.  It is pure luck if it
works.


From owner-linux-mips@oss.sgi.com Mon Feb 26 17:43:44 2001
Received:  by oss.sgi.com id <S554314AbRB0Bne>;
	Mon, 26 Feb 2001 17:43:34 -0800
Received: from u-217-21.karlsruhe.ipdial.viaginterkom.de ([62.180.21.217]:38899
        "EHLO dea.waldorf-gmbh.de") by oss.sgi.com with ESMTP
	id <S554312AbRB0BnP>; Mon, 26 Feb 2001 17:43:15 -0800
Received: (from ralf@localhost)
	by dea.waldorf-gmbh.de (8.11.1/8.11.1) id f1R1gZX26804;
	Tue, 27 Feb 2001 02:42:35 +0100
Date:   Tue, 27 Feb 2001 02:42:35 +0100
From:   Ralf Baechle <ralf@oss.sgi.com>
To:     "Steven Liu" <stevenliu@psdc.com>
Cc:     <linux-mips@oss.sgi.com>
Subject: Re: Where is 2.2.x kernel?
Message-ID: <20010227024235.A26684@bacchus.dhis.org>
References: <001c01c09fcd$61c20070$dde0490a@BANANA>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <001c01c09fcd$61c20070$dde0490a@BANANA>; from stevenliu@psdc.com on Mon, Feb 26, 2001 at 12:23:22AM -0800
X-Accept-Language: de,en,fr
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing

On Mon, Feb 26, 2001 at 12:23:22AM -0800, Steven Liu wrote:

> In ftp://oss.sgi.com/pub/linux/mips/kernel/, there are many folders like v2.1, v2.2, and v2.3. But there is nothing in v2.2. Where could I 
> find 2.2.x kernel? 

You can now get the kernel from anonymous CVS.  See the howto at
http://oss.sgi.com/mips/mips-howto.html for how to access anonymous CVS;
Linux 2.2 is on the CVS branch linux_2_2.

  Ralf

From owner-linux-mips@oss.sgi.com Tue Feb 27 06:40:40 2001
Received:  by oss.sgi.com id <S554369AbRB0OkV>;
	Tue, 27 Feb 2001 06:40:21 -0800
Received: from enst.enst.fr ([137.194.2.16]:11502 "HELO enst.enst.fr")
	by oss.sgi.com with SMTP id <S554365AbRB0OkQ>;
	Tue, 27 Feb 2001 06:40:16 -0800
Received: from email.enst.fr (muse.enst.fr [137.194.2.33])
	by enst.enst.fr (Postfix) with ESMTP id 085BB1C918
	for <linux-mips@oss.sgi.com>; Tue, 27 Feb 2001 15:40:14 +0100 (MET)
Received: from donjuan.enst.fr (donjuan.enst.fr [137.194.168.21])
	by email.enst.fr (8.9.3/8.9.3) with ESMTP id PAA00253
	for <linux-mips@oss.sgi.com>; Tue, 27 Feb 2001 15:40:13 +0100 (MET)
Received: from localhost (bellard@localhost)
	by donjuan.enst.fr (8.9.3+Sun/8.9.3) with SMTP id PAA22829
	for <linux-mips@oss.sgi.com>; Tue, 27 Feb 2001 15:40:11 +0100 (MET)
Date:   Tue, 27 Feb 2001 15:40:11 +0100 (MET)
From:   Fabrice Bellard <bellard@email.enst.fr>
To:     linux-mips@oss.sgi.com
Subject: Serious bug in uaccess.h
Message-ID: <Pine.GSO.4.02.10102271534030.22188-100000@donjuan.enst.fr>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing

Hi!

I found a serious bug in the assembler macros in asm-mips/uaccess.h. They
all do something like that:

		__asm__ __volatile__( \
			"move\t$4, %1\n\t" \
			"move\t$5, %2\n\t" \
			"move\t$6, %3\n\t" \
			".set\tnoreorder\n\t" \
			__MODULE_JAL(__copy_user) \
...

The problem is that you cannot assume that gcc will not put %1, %2 or %3
in registers different from $4, $5 or $6. For example, if %2 is put in $4,
the code is incorrect. (With gcc-2.95.2 I got a bug in
generic_file_write!).

Did someone already fixed this bug ?

A possible fix would be to use asm registers:

#define copy_from_user(to,from,n) ({ \
	register void *__cu_to asm("$4"); \
	register const void *__cu_from asm("$5"); \
	register long __cu_len asm("$6"); \
	\
	__cu_to = (to); \
	__cu_from = (from); \
	__cu_len = (n); \
	if (access_ok(VERIFY_READ, __cu_from, __cu_len)) \
		__asm__ __volatile__( \
			".set\tnoreorder\n\t" \
			__MODULE_JAL(__copy_user) \
...

But I am not sure that it is always correct. Any idea ?

Fabrice.


From owner-linux-mips@oss.sgi.com Tue Feb 27 07:34:11 2001
Received:  by oss.sgi.com id <S554366AbRB0PeA>;
	Tue, 27 Feb 2001 07:34:00 -0800
Received: from enst.enst.fr ([137.194.2.16]:23028 "HELO enst.enst.fr")
	by oss.sgi.com with SMTP id <S553900AbRB0Pdn>;
	Tue, 27 Feb 2001 07:33:43 -0800
Received: from email.enst.fr (muse.enst.fr [137.194.2.33])
	by enst.enst.fr (Postfix) with ESMTP
	id 901451C913; Tue, 27 Feb 2001 16:33:38 +0100 (MET)
Received: from donjuan.enst.fr (donjuan.enst.fr [137.194.168.21])
	by email.enst.fr (8.9.3/8.9.3) with ESMTP id QAA07034;
	Tue, 27 Feb 2001 16:33:33 +0100 (MET)
Received: from localhost (bellard@localhost)
	by donjuan.enst.fr (8.9.3+Sun/8.9.3) with SMTP id QAA23114;
	Tue, 27 Feb 2001 16:33:17 +0100 (MET)
Date:   Tue, 27 Feb 2001 16:33:17 +0100 (MET)
From:   Fabrice Bellard <bellard@email.enst.fr>
To:     "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
Cc:     Fabrice Bellard <bellard@email.enst.fr>, linux-mips@oss.sgi.com
Subject: Re: Serious bug in uaccess.h
In-Reply-To: <Pine.GSO.3.96.1010227155414.2952A-100000@delta.ds2.pg.gda.pl>
Message-ID: <Pine.GSO.4.02.10102271629230.22188-100000@donjuan.enst.fr>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing


I read the gcc docs and you are right, so it seems to be a gcc bug. I am
using gcc 2.95.2. Which version of gcc is OK to compile a linux mips
kernel ?

BTW, the kernel would be smaller by moving all the asm around __copy_user
in __copy_user itself. I am currently doing that. The cost is an added
'jr' to jump to __memcpy. Do you think it is worthwhile to do that ?

Fabrice.

On Tue, 27 Feb 2001, Maciej W. Rozycki wrote:

> On Tue, 27 Feb 2001, Fabrice Bellard wrote:
> 
> > I found a serious bug in the assembler macros in asm-mips/uaccess.h. They
> > all do something like that:
> > 
> > 		__asm__ __volatile__( \
> > 			"move\t$4, %1\n\t" \
> > 			"move\t$5, %2\n\t" \
> > 			"move\t$6, %3\n\t" \
> > 			".set\tnoreorder\n\t" \
> > 			__MODULE_JAL(__copy_user) \
> > ...
> > 
> > The problem is that you cannot assume that gcc will not put %1, %2 or %3
> > in registers different from $4, $5 or $6. For example, if %2 is put in $4,
> > the code is incorrect. (With gcc-2.95.2 I got a bug in
> > generic_file_write!).
> 
>  Hmm, haven't looked through gcc sources, but docs state: "It is an error
> for a clobber description to overlap an input or output operand (for
> example, an operand describing a register class with one member, mentioned
> in the clobber list)."  I guess it implies clobbers are not used for input
> or output.  It's reasonable anyway and if gcc acts otherwise, you might
> just have caught a bug in gcc.
> 
> > A possible fix would be to use asm registers:
> > 
> > #define copy_from_user(to,from,n) ({ \
> > 	register void *__cu_to asm("$4"); \
> > 	register const void *__cu_from asm("$5"); \
> > 	register long __cu_len asm("$6"); \
> > 	\
> > 	__cu_to = (to); \
> > 	__cu_from = (from); \
> > 	__cu_len = (n); \
> > 	if (access_ok(VERIFY_READ, __cu_from, __cu_len)) \
> > 		__asm__ __volatile__( \
> > 			".set\tnoreorder\n\t" \
> > 			__MODULE_JAL(__copy_user) \
> > ...
> > 
> > But I am not sure that it is always correct. Any idea ?
> 
>  This is fine and saves us three instructions.  Go on, make a patch (I'd
> suggest using "__asm__" for consistency, though)! 
> 
> -- 
> +  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
> +--------------------------------------------------------------+
> +        e-mail: macro@ds2.pg.gda.pl, PGP key available        +
> 


From owner-linux-mips@oss.sgi.com Tue Feb 27 07:53:40 2001
Received:  by oss.sgi.com id <S554371AbRB0PxV>;
	Tue, 27 Feb 2001 07:53:21 -0800
Received: from delta.ds2.pg.gda.pl ([153.19.144.1]:43393 "EHLO
        delta.ds2.pg.gda.pl") by oss.sgi.com with ESMTP id <S554363AbRB0Pwx>;
	Tue, 27 Feb 2001 07:52:53 -0800
Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id QAA04477;
	Tue, 27 Feb 2001 16:13:34 +0100 (MET)
Date:   Tue, 27 Feb 2001 16:13:33 +0100 (MET)
From:   "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To:     Fabrice Bellard <bellard@email.enst.fr>
cc:     linux-mips@oss.sgi.com
Subject: Re: Serious bug in uaccess.h
In-Reply-To: <Pine.GSO.4.02.10102271534030.22188-100000@donjuan.enst.fr>
Message-ID: <Pine.GSO.3.96.1010227155414.2952A-100000@delta.ds2.pg.gda.pl>
Organization: Technical University of Gdansk
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing

On Tue, 27 Feb 2001, Fabrice Bellard wrote:

> I found a serious bug in the assembler macros in asm-mips/uaccess.h. They
> all do something like that:
> 
> 		__asm__ __volatile__( \
> 			"move\t$4, %1\n\t" \
> 			"move\t$5, %2\n\t" \
> 			"move\t$6, %3\n\t" \
> 			".set\tnoreorder\n\t" \
> 			__MODULE_JAL(__copy_user) \
> ...
> 
> The problem is that you cannot assume that gcc will not put %1, %2 or %3
> in registers different from $4, $5 or $6. For example, if %2 is put in $4,
> the code is incorrect. (With gcc-2.95.2 I got a bug in
> generic_file_write!).

 Hmm, haven't looked through gcc sources, but docs state: "It is an error
for a clobber description to overlap an input or output operand (for
example, an operand describing a register class with one member, mentioned
in the clobber list)."  I guess it implies clobbers are not used for input
or output.  It's reasonable anyway and if gcc acts otherwise, you might
just have caught a bug in gcc.

> A possible fix would be to use asm registers:
> 
> #define copy_from_user(to,from,n) ({ \
> 	register void *__cu_to asm("$4"); \
> 	register const void *__cu_from asm("$5"); \
> 	register long __cu_len asm("$6"); \
> 	\
> 	__cu_to = (to); \
> 	__cu_from = (from); \
> 	__cu_len = (n); \
> 	if (access_ok(VERIFY_READ, __cu_from, __cu_len)) \
> 		__asm__ __volatile__( \
> 			".set\tnoreorder\n\t" \
> 			__MODULE_JAL(__copy_user) \
> ...
> 
> But I am not sure that it is always correct. Any idea ?

 This is fine and saves us three instructions.  Go on, make a patch (I'd
suggest using "__asm__" for consistency, though)! 

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +


From owner-linux-mips@oss.sgi.com Tue Feb 27 09:51:32 2001
Received:  by oss.sgi.com id <S554375AbRB0RvM>;
	Tue, 27 Feb 2001 09:51:12 -0800
Received: from u-53-18.karlsruhe.ipdial.viaginterkom.de ([62.180.18.53]:48371
        "EHLO dea.waldorf-gmbh.de") by oss.sgi.com with ESMTP
	id <S554372AbRB0RvB>; Tue, 27 Feb 2001 09:51:01 -0800
Received: (from ralf@localhost)
	by dea.waldorf-gmbh.de (8.11.1/8.11.1) id f1RHo4201646;
	Tue, 27 Feb 2001 18:50:04 +0100
Date:   Tue, 27 Feb 2001 18:50:04 +0100
From:   Ralf Baechle <ralf@oss.sgi.com>
To:     Fabrice Bellard <bellard@email.enst.fr>
Cc:     linux-mips@oss.sgi.com
Subject: Re: Serious bug in uaccess.h
Message-ID: <20010227185004.C963@bacchus.dhis.org>
References: <Pine.GSO.4.02.10102271534030.22188-100000@donjuan.enst.fr>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <Pine.GSO.4.02.10102271534030.22188-100000@donjuan.enst.fr>; from bellard@email.enst.fr on Tue, Feb 27, 2001 at 03:40:11PM +0100
X-Accept-Language: de,en,fr
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing

On Tue, Feb 27, 2001 at 03:40:11PM +0100, Fabrice Bellard wrote:

> #define copy_from_user(to,from,n) ({ \
> 	register void *__cu_to asm("$4"); \
> 	register const void *__cu_from asm("$5"); \
> 	register long __cu_len asm("$6"); \
> 	\
> 	__cu_to = (to); \
> 	__cu_from = (from); \
> 	__cu_len = (n); \
> 	if (access_ok(VERIFY_READ, __cu_from, __cu_len)) \
> 		__asm__ __volatile__( \
> 			".set\tnoreorder\n\t" \
> 			__MODULE_JAL(__copy_user) \
> ...
> 
> But I am not sure that it is always correct. Any idea ?

While this should be correct - it was my original attempt also - it was
misscompiled by whatever C compiler I was using at that time.  If
egcs 1.1.2 and gcc 2.95 both compile this construct right now then I'd
say go for it.

  Ralf

From owner-linux-mips@oss.sgi.com Tue Feb 27 09:59:02 2001
Received:  by oss.sgi.com id <S554377AbRB0R6m>;
	Tue, 27 Feb 2001 09:58:42 -0800
Received: from delta.ds2.pg.gda.pl ([153.19.144.1]:21379 "EHLO
        delta.ds2.pg.gda.pl") by oss.sgi.com with ESMTP id <S554373AbRB0R6f>;
	Tue, 27 Feb 2001 09:58:35 -0800
Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id SAA10066;
	Tue, 27 Feb 2001 18:54:22 +0100 (MET)
Date:   Tue, 27 Feb 2001 18:54:22 +0100 (MET)
From:   "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To:     Fabrice Bellard <bellard@email.enst.fr>
cc:     linux-mips@oss.sgi.com
Subject: Re: Serious bug in uaccess.h
In-Reply-To: <Pine.GSO.4.02.10102271629230.22188-100000@donjuan.enst.fr>
Message-ID: <Pine.GSO.3.96.1010227185131.9765A-100000@delta.ds2.pg.gda.pl>
Organization: Technical University of Gdansk
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing

On Tue, 27 Feb 2001, Fabrice Bellard wrote:

> I read the gcc docs and you are right, so it seems to be a gcc bug. I am
> using gcc 2.95.2. Which version of gcc is OK to compile a linux mips
> kernel ?

 Patched 2.95.2 should be fine; RPM packages of what I use are available
at 'ftp://ftp.ds2.pg.gda.pl/pub/macro/'. 

> BTW, the kernel would be smaller by moving all the asm around __copy_user
> in __copy_user itself. I am currently doing that. The cost is an added
> 'jr' to jump to __memcpy. Do you think it is worthwhile to do that ?

 What asm do you mean?

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +


From owner-linux-mips@oss.sgi.com Tue Feb 27 14:24:04 2001
Received:  by oss.sgi.com id <S553762AbRB0WXz>;
	Tue, 27 Feb 2001 14:23:55 -0800
Received: from enst.enst.fr ([137.194.2.16]:9115 "HELO enst.enst.fr")
	by oss.sgi.com with SMTP id <S553744AbRB0WXg>;
	Tue, 27 Feb 2001 14:23:36 -0800
Received: from email.enst.fr (muse.enst.fr [137.194.2.33])
	by enst.enst.fr (Postfix) with ESMTP
	id BD7781C913; Tue, 27 Feb 2001 23:23:33 +0100 (MET)
Received: from cal-ppp20.ppp.enst.fr (root@cal-ppp20.ppp.enst.fr [137.194.3.20])
	by email.enst.fr (8.9.3/8.9.3) with ESMTP id XAA29440;
	Tue, 27 Feb 2001 23:23:31 +0100 (MET)
Received: (from bellard@localhost)
	by cal-ppp20.ppp.enst.fr (8.9.3/8.9.3/Debian 8.9.3-21) id XAA00555;
	Tue, 27 Feb 2001 23:22:27 +0100
Date:   Tue, 27 Feb 2001 23:22:27 +0100
From:   Fabrice Bellard <bellard@email.enst.fr>
To:     "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
Cc:     linux-mips@oss.sgi.com
Subject: Re: Serious bug in uaccess.h
Message-ID: <20010227232227.B384@email.enst.fr>
References: <Pine.GSO.4.02.10102271629230.22188-100000@donjuan.enst.fr> <Pine.GSO.3.96.1010227185131.9765A-100000@delta.ds2.pg.gda.pl>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <Pine.GSO.3.96.1010227185131.9765A-100000@delta.ds2.pg.gda.pl>; from macro@ds2.pg.gda.pl on Tue, Feb 27, 2001 at 06:54:22PM +0100
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing

On Tue, Feb 27, 2001 at 06:54:22PM +0100, Maciej W. Rozycki wrote:
> > BTW, the kernel would be smaller by moving all the asm around __copy_user
> > in __copy_user itself. I am currently doing that. The cost is an added
> > 'jr' to jump to __memcpy. Do you think it is worthwhile to do that ?
> 
>  What asm do you mean?

I mean the code in arch/mips/lib/memcpy.S. It is possible to modify
__copy_user so that it has exactly the same calling convention of a C
function. Then, no asm is necessary in uaccess.h. It costs us a
supplementary jump.

Fabrice.

From owner-linux-mips@oss.sgi.com Tue Feb 27 19:09:45 2001
Received:  by oss.sgi.com id <S553766AbRB1DJ0>;
	Tue, 27 Feb 2001 19:09:26 -0800
Received: from smtp.psdc.com ([209.125.203.83]:24654 "EHLO smtp.psdc.com")
	by oss.sgi.com with ESMTP id <S553690AbRB1DJC>;
	Tue, 27 Feb 2001 19:09:02 -0800
Received: from BANANA ([209.125.203.85])
	by smtp.psdc.com (8.8.8/8.8.8) with SMTP id SAA28761
	for <linux-mips@oss.sgi.com>; Tue, 27 Feb 2001 18:52:53 -0800
Message-ID: <000a01c0a0cf$849efbe0$dde0490a@BANANA>
From:   "Steven Liu" <stevenliu@psdc.com>
To:     <linux-mips@oss.sgi.com>
Subject: binutils-2.8.1-mips.patch and egcs-1.1.2-mips.patch ?
Date:   Tue, 27 Feb 2001 07:11:10 -0800
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0007_01C0A08C.7616DF90"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing

This is a multi-part message in MIME format.

------=_NextPart_000_0007_01C0A08C.7616DF90
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi ALL:

Thank you for your help.

If any one knows where I can find the following files:=20
     binutils-2.8.1-mips.patch  and
    egcs-1.1.2-mips.patch,
please let me know.

Regards,


Steven Liu



------=_NextPart_000_0007_01C0A08C.7616DF90
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.3103.1000" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial>Hi ALL:</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial>Thank you for your help.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial>If&nbsp;any one knows where I can find the =
following=20
files: </FONT></DIV>
<DIV><FONT face=3DArial>&nbsp;&nbsp;&nbsp;&nbsp;=20
<STRONG>binutils-2.8.1-mips.patch&nbsp; </STRONG>and</FONT></DIV>
<DIV><FONT face=3DArial>&nbsp;&nbsp;&nbsp;=20
<STRONG>egcs-1.1.2-mips.patch</STRONG>,</FONT></DIV>
<DIV><FONT face=3DArial>please let me know.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial>Regards,</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial>Steven Liu</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV></BODY></HTML>

------=_NextPart_000_0007_01C0A08C.7616DF90--


From owner-linux-mips@oss.sgi.com Wed Feb 28 04:34:29 2001
Received:  by oss.sgi.com id <S553682AbRB1MeI>;
	Wed, 28 Feb 2001 04:34:08 -0800
Received: from u-155-18.karlsruhe.ipdial.viaginterkom.de ([62.180.18.155]:12036
        "EHLO u-155-18.karlsruhe.ipdial.viaginterkom.de") by oss.sgi.com
	with ESMTP id <S553768AbRB1Mdv>; Wed, 28 Feb 2001 04:33:51 -0800
Received: from [193.98.169.28] ([193.98.169.28]:53376 "EHLO
	dea.waldorf-gmbh.de") by bacchus.dhis.org with ESMTP
	id <S870763AbRB1Md3>; Wed, 28 Feb 2001 04:33:29 -0800
Received: (from ralf@localhost)
	by dea.waldorf-gmbh.de (8.11.1/8.11.1) id f1SCX7305490;
	Wed, 28 Feb 2001 13:33:07 +0100
Date:	Wed, 28 Feb 2001 13:33:07 +0100
From:	Ralf Baechle <ralf@oss.sgi.com>
To:	"Steven Liu" <stevenliu@psdc.com>
Cc:	<linux-mips@oss.sgi.com>
Subject: Re: binutils-2.8.1-mips.patch and egcs-1.1.2-mips.patch ?
Message-ID: <20010228133307.A5452@bacchus.dhis.org>
References: <000a01c0a0cf$849efbe0$dde0490a@BANANA>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <000a01c0a0cf$849efbe0$dde0490a@BANANA>; from stevenliu@psdc.com on Tue, Feb 27, 2001 at 07:11:10AM -0800
X-Accept-Language: de,en,fr
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing

On Tue, Feb 27, 2001 at 07:11:10AM -0800, Steven Liu wrote:

> Thank you for your help.
> 
> If any one knows where I can find the following files: 
>      binutils-2.8.1-mips.patch  and
>     egcs-1.1.2-mips.patch,
> please let me know.

They're part of the srpm crosscompiler packages on oss.sgi.com.

  Ralf

From owner-linux-mips@oss.sgi.com Wed Feb 28 04:54:09 2001
Received:  by oss.sgi.com id <S553748AbRB1Mx7>;
	Wed, 28 Feb 2001 04:53:59 -0800
Received: from delta.ds2.pg.gda.pl ([153.19.144.1]:63118 "EHLO
        delta.ds2.pg.gda.pl") by oss.sgi.com with ESMTP id <S553679AbRB1Mxs>;
	Wed, 28 Feb 2001 04:53:48 -0800
Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id NAA08338;
	Wed, 28 Feb 2001 13:47:27 +0100 (MET)
Date:   Wed, 28 Feb 2001 13:47:27 +0100 (MET)
From:   "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To:     Fabrice Bellard <bellard@email.enst.fr>,
        Ralf Baechle <ralf@uni-koblenz.de>
cc:     linux-mips@oss.sgi.com
Subject: Re: Serious bug in uaccess.h
In-Reply-To: <20010227232227.B384@email.enst.fr>
Message-ID: <Pine.GSO.3.96.1010228130945.6646A-100000@delta.ds2.pg.gda.pl>
Organization: Technical University of Gdansk
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing

On Tue, 27 Feb 2001, Fabrice Bellard wrote:

> I mean the code in arch/mips/lib/memcpy.S. It is possible to modify
> __copy_user so that it has exactly the same calling convention of a C
> function. Then, no asm is necessary in uaccess.h. It costs us a
> supplementary jump.

 You mean the supplementary return value in a2?  Hmm, it is always set to
zero!  Also "addu $1, %2, %3" makes no sense.

 Ralf, the code is weird.  The header implies you are the author.  Could
you please elaborate what you meant in copy_*_user()? 

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +


From owner-linux-mips@oss.sgi.com Wed Feb 28 04:58:40 2001
Received:  by oss.sgi.com id <S553768AbRB1M63>;
	Wed, 28 Feb 2001 04:58:29 -0800
Received: from u-155-18.karlsruhe.ipdial.viaginterkom.de ([62.180.18.155]:15108
        "EHLO u-155-18.karlsruhe.ipdial.viaginterkom.de") by oss.sgi.com
	with ESMTP id <S553690AbRB1M6S>; Wed, 28 Feb 2001 04:58:18 -0800
Received: from [193.98.169.28] ([193.98.169.28]:55936 "EHLO
	dea.waldorf-gmbh.de") by bacchus.dhis.org with ESMTP
	id <S870768AbRB1M5p>; Wed, 28 Feb 2001 04:57:45 -0800
Received: (from ralf@localhost)
	by dea.waldorf-gmbh.de (8.11.1/8.11.1) id f1SCuS705711;
	Wed, 28 Feb 2001 13:56:28 +0100
Date:	Wed, 28 Feb 2001 13:56:28 +0100
From:	Ralf Baechle <ralf@oss.sgi.com>
To:	"Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
Cc:	Fabrice Bellard <bellard@email.enst.fr>, linux-mips@oss.sgi.com
Subject: Re: Serious bug in uaccess.h
Message-ID: <20010228135628.C5452@bacchus.dhis.org>
References: <20010227232227.B384@email.enst.fr> <Pine.GSO.3.96.1010228130945.6646A-100000@delta.ds2.pg.gda.pl>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <Pine.GSO.3.96.1010228130945.6646A-100000@delta.ds2.pg.gda.pl>; from macro@ds2.pg.gda.pl on Wed, Feb 28, 2001 at 01:47:27PM +0100
X-Accept-Language: de,en,fr
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing

On Wed, Feb 28, 2001 at 01:47:27PM +0100, Maciej W. Rozycki wrote:
> Date: Wed, 28 Feb 2001 13:47:27 +0100 (MET)
> From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
> To: Fabrice Bellard <bellard@email.enst.fr>,
>         Ralf Baechle <ralf@uni-koblenz.de>
> cc: linux-mips@oss.sgi.com
> Subject: Re: Serious bug in uaccess.h
> 
> On Tue, 27 Feb 2001, Fabrice Bellard wrote:
> 
> > I mean the code in arch/mips/lib/memcpy.S. It is possible to modify
> > __copy_user so that it has exactly the same calling convention of a C
> > function. Then, no asm is necessary in uaccess.h. It costs us a
> > supplementary jump.
> 
>  You mean the supplementary return value in a2?  Hmm, it is always set to
> zero!  Also "addu $1, %2, %3" makes no sense.
> 
>  Ralf, the code is weird.  The header implies you are the author.  Could
> you please elaborate what you meant in copy_*_user()? 

I'll look at it and try to recall :-)

  Ralf

From owner-linux-mips@oss.sgi.com Wed Feb 28 13:42:53 2001
Received:  by oss.sgi.com id <S553829AbRB1Vmo>;
	Wed, 28 Feb 2001 13:42:44 -0800
Received: from stereotomy.lineo.com ([64.50.107.151]:38162 "HELO
        stereotomy.lineo.com") by oss.sgi.com with SMTP id <S553773AbRB1Vm1>;
	Wed, 28 Feb 2001 13:42:27 -0800
Received: from Lineo.COM (localhost.localdomain [127.0.0.1])
	by stereotomy.lineo.com (Postfix) with ESMTP id DD36F4C92B
	for <linux-mips@oss.sgi.com>; Wed, 28 Feb 2001 14:42:26 -0700 (MST)
Message-ID: <3A9D70C2.6010504@Lineo.COM>
Date:   Wed, 28 Feb 2001 14:42:26 -0700
From:   Quinn Jensen <jensenq@Lineo.COM>
Organization: Lineo, Inc.
User-Agent: Mozilla/5.0 (X11; U; Linux 2.2.16-9mdk i686; en-US; m18) Gecko/20001107 Netscape6/6.0
X-Accept-Language: en
MIME-Version: 1.0
To:     linux-mips@oss.sgi.com
Subject: Patch allowing GDB to ignore misaligned data faults
References: <000a01c0a0cf$849efbe0$dde0490a@BANANA>
Content-Type: multipart/mixed;
 boundary="------------040204030603060306000202"
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing

This is a multi-part message in MIME format.
--------------040204030603060306000202
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

When using gdb on the kernel, I've found it helpful to allow
misaligned exceptions to be emulated instead of being
intercepted by gdb.  The following patch does this.  But is
there a better way?  Perhaps a config.in option?

Or is this a case of treating the symptom?  Maybe there are
far too many altogether.  The network stack seems to
be littered with them--is skbuf alignment bad or something?

Ouch, I just looked and after a couple of days there have
been a lot!  This machine is running with nfs root, so every
time you breathe there's a lot of network I/O.

What kind of "unaligned accesses" counts are others seeing?

/ # cat /proc/cpuinfo
cpu                     : MIPS
cpu model               : RC32300 V0.0
system type             : IDT 79S334
BogoMIPS                : 149.91
byteorder               : little endian
unaligned accesses      : 329630
wait instruction        : no
microsecond timers      : no
extra interrupt vector  : yes
hardware watchpoint     : yes
VCED exceptions         : not available
VCEI exceptions         : not available

/ # uptime
   2:07pm  up 1 day, 21:07, load average: 0.00, 0.00, 0.00

Quinn






--------------040204030603060306000202
Content-Type: text/plain;
 name="patch-gdb-stub"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="patch-gdb-stub"

diff -bpBuN -r -X - linux-sgi-cvs/arch/mips/kernel/gdb-stub.c linux+4/arch/mips/kernel/gdb-stub.c
--- linux-sgi-cvs/arch/mips/kernel/gdb-stub.c	Sun Dec  3 21:04:09 2000
+++ linux+4/arch/mips/kernel/gdb-stub.c	Mon Feb 26 14:56:05 2001
@@ -399,8 +399,11 @@ void set_debug_traps(void)
 	unsigned char c;
 
 	save_and_cli(flags);
-	for (ht = hard_trap_info; ht->tt && ht->signo; ht++)
+	for (ht = hard_trap_info; ht->tt && ht->signo; ht++) {
+		/* let the emulator handle adel and ades */
+		if (ht->tt == 4 || ht->tt == 5) continue;
 		set_except_vector(ht->tt, trap_low);
+	}
   
 	/*
 	 * In case GDB is started before us, ack any packets

--------------040204030603060306000202--


From owner-linux-mips@oss.sgi.com Wed Feb 28 14:21:43 2001
Received:  by oss.sgi.com id <S553850AbRB1WVX>;
	Wed, 28 Feb 2001 14:21:23 -0800
Received: from gateway-1237.mvista.com ([12.44.186.158]:5880 "EHLO
        hermes.mvista.com") by oss.sgi.com with ESMTP id <S553788AbRB1WVU>;
	Wed, 28 Feb 2001 14:21:20 -0800
Received: from mvista.com (IDENT:jsun@orion.mvista.com [10.0.0.75])
	by hermes.mvista.com (8.11.0/8.11.0) with ESMTP id f1SMGv009199;
	Wed, 28 Feb 2001 14:16:57 -0800
Message-ID: <3A9D793E.4063ED17@mvista.com>
Date:   Wed, 28 Feb 2001 14:18:38 -0800
From:   Jun Sun <jsun@mvista.com>
X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.18 i686)
X-Accept-Language: en
MIME-Version: 1.0
To:     Quinn Jensen <jensenq@Lineo.COM>
CC:     linux-mips@oss.sgi.com
Subject: Re: Patch allowing GDB to ignore misaligned data faults
References: <000a01c0a0cf$849efbe0$dde0490a@BANANA> <3A9D70C2.6010504@Lineo.COM>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing

Quinn Jensen wrote:
> 
> When using gdb on the kernel, I've found it helpful to allow
> misaligned exceptions to be emulated instead of being
> intercepted by gdb.  The following patch does this.  But is
> there a better way?  Perhaps a config.in option?
> 

This does not sound right:  this is already fixed long time ago by not
installing traps for exception 4&5.  What kernel are you using?

Jun

From owner-linux-mips@oss.sgi.com Wed Feb 28 14:55:43 2001
Received:  by oss.sgi.com id <S553837AbRB1WzX>;
	Wed, 28 Feb 2001 14:55:23 -0800
Received: from erebus.lineo.com ([64.50.107.39]:26240 "HELO erebus.lineo.com")
	by oss.sgi.com with SMTP id <S553663AbRB1Wy5>;
	Wed, 28 Feb 2001 14:54:57 -0800
Received: by erebus.lineo.com (Postfix, from userid 441)
	id 3949038C58; Wed, 28 Feb 2001 15:53:37 -0700 (MST)
Date:   Wed, 28 Feb 2001 15:53:37 -0700
From:   Curtis Veit <curtisv@lineo.com>
To:     ldavies@oz.agile.tv
Cc:     linux-mips@oss.sgi.com
Subject: Re: Small remote debug kernels??
Message-ID: <20010228155337.A1136@lineo.com>
Reply-To: curtisv@lineo.com
References: <3A95E682.982AC529@agile.tv>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.3.15i
In-Reply-To: <3A95E682.982AC529@agile.tv>; from ldavies@agile.tv on Fri, Feb 23, 2001 at 02:26:42PM +1000
X-No-Junk-Mail: Beware - Local law allows collection of damages for spam.
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing


Hi Liam,

On Fri, Feb 23, 2001 at 02:26:42PM +1000, Liam Davies wrote:
> I would like to remote debug my kernel.
> On the Cobalt box I have there is (allegedly) a bootloader bug that
> stops the
> kernel being any larger than 1M/2.5M, compressed/uncompressed.
> I have stripped the kernel bare but can't get much lower than 6M
> uncompressed.
> 
> Is there any way I can have a mini-remote debugging kernel??

It sounds like the kernel on the target system still has the
debug symbols in it. The symbols are actually only needed 
in the kernel on the host end.  (present on the same machine
as gdb.)

You can strip the kernel you put on your target with
	strip --strip-unneeded vmlinux
This should allow you to use more then a bare kernel.

It seems that you have fallen prey to a common misconception
about remote debugging.  Hope this helps.

Regards,

Curtis Veit
curtisv@lineo.com


From owner-linux-mips@oss.sgi.com Wed Feb 28 17:55:06 2001
Received:  by oss.sgi.com id <S553719AbRCAByq>;
	Wed, 28 Feb 2001 17:54:46 -0800
Received: from smtp.psdc.com ([209.125.203.83]:17487 "EHLO smtp.psdc.com")
	by oss.sgi.com with ESMTP id <S553650AbRCAByY>;
	Wed, 28 Feb 2001 17:54:24 -0800
Received: from BANANA ([209.125.203.85])
	by smtp.psdc.com (8.8.8/8.8.8) with SMTP id RAA25611
	for <linux-mips@oss.sgi.com>; Wed, 28 Feb 2001 17:38:09 -0800
Message-ID: <001001c0a18e$3f494bd0$dde0490a@BANANA>
From:   "Steven Liu" <stevenliu@psdc.com>
To:     <linux-mips@oss.sgi.com>
Subject: mips-tfile and gcc.
Date:   Wed, 28 Feb 2001 05:56:28 -0800
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_000D_01C0A14B.31090DF0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing

This is a multi-part message in MIME format.

------=_NextPart_000_000D_01C0A14B.31090DF0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi, All:

I have just got a problem when I egcs-1.1.2 for MIPS R3000 under i386. I =
did the following.

./configure --prefix=3D/root/liumips/ --with-newlib =
--target=3Dmips-linux
make SUBDIRS=3D"libiberty textinfo gcc" ALLTARGET_MODULES=3D =
CONFIGURE_TARGET_MODULES=3D INSTALL_TARGET_MODULES=3D LANGUAGES=3D"c"

Here is what I got.

cp xgcc gcc-cross
/root/liumips/egcs-1.1.2/gcc/xgcc -B/root/liumips/egcs-1.1.2/gcc/ =
-dumpspecs > tmp-specs
mv tmp-specs specs
if [ -f libgcc2.ready ] ; then \
 true; \
else \
 touch libgcc2.ready; \
fi
rm -f tmplibgcc2.a
for name in _muldi3 _divdi3 _moddi3 _udivdi3 _umoddi3 _negdi2 _lshrdi3 =
_ashldi3 _ashrdi3 _ffsdi2 _udiv_w_sdiv _udivmoddi4 _cmpdi2 _ucmpdi2 =
_floatdidf _floatdisf _fixunsdfsi _fixunssfsi _fixunsdfdi _fixdfdi =
_fixunssfdi _fixsfdi _fixxfdi _fixunsxfdi _floatdixf _fixunsxfsi =
_fixtfdi _fixunstfdi _floatditf __gcc_bcmp _varargs __dummy _eprintf _bb =
_shtab _clear_cache _trampoline __main _exit _ctors _pure; \
do \
  echo ${name}; \
  /root/liumips/egcs-1.1.2/gcc/xgcc -B/root/liumips/egcs-1.1.2/gcc/ -O2  =
-DCROSS_COMPILE -DIN_GCC    -g -O2 -I./include   -g1  -DIN_LIBGCC2 =
-D__GCC_FLOAT_NOT_NEEDED -Dinhibit_libc  -I. -I. -I./config -c =
-DL${name} \
      ./libgcc2.c -o ${name}.o; \
  if [ $? -eq 0 ] ; then true; else exit 1; fi; \
  mips-linux-ar rc tmplibgcc2.a ${name}.o; \
  rm -f ${name}.o; \
done
_muldi3
xgcc: installation problem, cannot exec `mips-tfile': No such file or =
directory
make[1]: *** [libgcc2.a] Error 1
make[1]: Leaving directory `/root/liumips/egcs-1.1.2/gcc'
make: *** [all-gcc] Error 2

Thank you.

Steven Liu

------=_NextPart_000_000D_01C0A14B.31090DF0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.3103.1000" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>Hi, All:</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>I have just got a problem when I =
egcs-1.1.2 for=20
MIPS R3000 under i386. I did the following.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>./configure --prefix=3D/root/liumips/ =
--with-newlib=20
--target=3Dmips-linux</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>make SUBDIRS=3D"libiberty textinfo gcc" =

ALLTARGET_MODULES=3D CONFIGURE_TARGET_MODULES=3D =
INSTALL_TARGET_MODULES=3D=20
LANGUAGES=3D"c"</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Here is what I got.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>cp xgcc=20
gcc-cross<BR>/root/liumips/egcs-1.1.2/gcc/xgcc =
-B/root/liumips/egcs-1.1.2/gcc/=20
-dumpspecs &gt; tmp-specs<BR>mv tmp-specs specs<BR>if [ -f libgcc2.ready =
] ;=20
then \<BR>&nbsp;true; \<BR>else \<BR>&nbsp;touch libgcc2.ready; =
\<BR>fi<BR>rm -f=20
tmplibgcc2.a<BR>for name in _muldi3 _divdi3 _moddi3 _udivdi3 _umoddi3 =
_negdi2=20
_lshrdi3 _ashldi3 _ashrdi3 _ffsdi2 _udiv_w_sdiv _udivmoddi4 _cmpdi2 =
_ucmpdi2=20
_floatdidf _floatdisf _fixunsdfsi _fixunssfsi _fixunsdfdi _fixdfdi =
_fixunssfdi=20
_fixsfdi _fixxfdi _fixunsxfdi _floatdixf _fixunsxfsi _fixtfdi =
_fixunstfdi=20
_floatditf __gcc_bcmp _varargs __dummy _eprintf _bb _shtab _clear_cache=20
_trampoline __main _exit _ctors _pure; \<BR>do \<BR>&nbsp; echo ${name}; =

\<BR>&nbsp; /root/liumips/egcs-1.1.2/gcc/xgcc =
-B/root/liumips/egcs-1.1.2/gcc/=20
-O2&nbsp; -DCROSS_COMPILE -DIN_GCC&nbsp;&nbsp;&nbsp; -g -O2=20
-I./include&nbsp;&nbsp; -g1&nbsp; -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED=20
-Dinhibit_libc&nbsp; -I. -I. -I./config -c -DL${name}=20
\<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ./libgcc2.c -o ${name}.o; =
\<BR>&nbsp; if [=20
$? -eq 0 ] ; then true; else exit 1; fi; \<BR>&nbsp; mips-linux-ar rc=20
tmplibgcc2.a ${name}.o; \<BR>&nbsp; rm -f ${name}.o;=20
\<BR>done<BR>_muldi3<BR>xgcc: installation problem, cannot exec =
`mips-tfile': No=20
such file or directory<BR>make[1]: *** [libgcc2.a] Error 1<BR>make[1]: =
Leaving=20
directory `/root/liumips/egcs-1.1.2/gcc'<BR>make: *** [all-gcc] Error=20
2</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Thank you.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Steven Liu</FONT></DIV></BODY></HTML>

------=_NextPart_000_000D_01C0A14B.31090DF0--


From owner-linux-mips@oss.sgi.com Wed Feb 28 19:06:57 2001
Received:  by oss.sgi.com id <S553823AbRCADGq>;
	Wed, 28 Feb 2001 19:06:46 -0800
Received: from mailhost.taec.com ([209.243.128.33]:1676 "EHLO
        mailhost.taec.toshiba.com") by oss.sgi.com with ESMTP
	id <S553758AbRCADGV>; Wed, 28 Feb 2001 19:06:21 -0800
Received: from hdqmta.taec.toshiba.com (hdqmta [209.243.180.59])
	by mailhost.taec.toshiba.com (8.8.8+Sun/8.8.8) with ESMTP id TAA21772;
	Wed, 28 Feb 2001 19:06:14 -0800 (PST)
Subject: NFSROOT filesystem
To:     linux-mips@oss.sgi.com, owner-linux-mips@oss.sgi.com
X-Mailer: Lotus Notes Release 5.0.3  March 21, 2000
Message-ID: <OF67407876.E19EEFE1-ON88256A02.000F849E@taec.toshiba.com>
From:   Lisa.Hsu@taec.toshiba.com
Date:   Wed, 28 Feb 2001 19:00:13 -0800
X-MIMETrack: Serialize by Router on HDQMTA/TOSHIBA_TAEC(Release 5.0.5 |September 22, 2000) at
 02/28/2001 07:05:00 PM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing


Hi, All

For using NFS boot, I've already edited the /etc/hosts, /etc/exports to add
the entry for my target board.  The command line that I use in our EPROM
based bootloader  is as follows:

root=/dev/nfs rw ip=::::::rarp console=ttyS2
nfsroot=209.243.136.151:/work/nfsroot

I need to setup the NFSROOT filesystem on the server for my target board
(which is running in Big-endian mode),  what are the steps that I have to
do?

There is a FTP site for getting RPM packages for little endian mode:

         tp://ftp.linux.sgi.com/[ig/linux/mips/mipsel-linux/RedHat-6.1/RPMS

I could not find similar one for big-endian.    Can anybody give me a
pointer to where the RPM packages reside on the web?


Thanks,

Lisa