From ralf@oss.sgi.com  Wed Feb  2 02:18:25 2000
Received: from mailhost.uni-koblenz.de (mailhost.uni-koblenz.de [141.26.64.1]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id CAA27133; Wed, 2 Feb 2000 02:18:24 +0100 (MET)
Received-Date: Wed, 2 Feb 2000 02:18:24 +0100 (MET)
Received: from cacc-13.uni-koblenz.de (cacc-13.uni-koblenz.de [141.26.131.13])
	by mailhost.uni-koblenz.de (8.9.3/8.9.3) with ESMTP id CAA25946;
	Wed, 2 Feb 2000 02:17:45 +0100 (MET)
Received: by lappi.waldorf-gmbh.de id <S407893AbQBBBRB>;
	Wed, 2 Feb 2000 02:17:01 +0100
Date: Wed, 2 Feb 2000 02:17:01 +0100
From: Ralf Baechle <ralf@oss.sgi.com>
To: Jeff Harrell <jharrell@ti.com>
Cc: linux@engr.sgi.com, linux-mips@fnet.fr, linux-mips@vger.rutgers.edu
Subject: Re: Question concerning memory configuration variables
Message-ID: <20000202021701.A22003@uni-koblenz.de>
References: <38970DA5.165EDA0F@ti.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0pre3us
In-Reply-To: <38970DA5.165EDA0F@ti.com>
X-Accept-Language: de,en,fr
Content-Length: 2023
Lines: 41

On Tue, Feb 01, 2000 at 09:45:25AM -0700, Jeff Harrell wrote:

> I have been looking at 2.2.23 and noticed that a few things concerning
> memory paging has changed.  I wonder if anybody could give me a definition
> of a couple of the variables that are defined.  The first is the
> max_low_pfn variable.  It looks like the first time that I see this called
> is during the paging_init() function and passed to free_area_init().  The
> memory map size is determined from this variable.  It memory map will
> extend to the end of physical memory (what used to be mips_memory_ upper).
> Do I determine the max_low_pfn by calculating the available memory and
> subtract the size of the kernel?  How does the variable "start" play into
> this equation?  Are they the same?  Any help would be greatly appreciated.

The max_low_pfn variable is the number of `normal' memory pages.  Normal
as opposed to high memory which we don't currently don't support on MIPS.
That is for contiguous memory starting at physical address zero it's
value equals available_memory / PAGE_SIZE.

The value of max_low_pfn is set by a call to init_bootmem.  A typical
setup could look like below.  Mb in this example is the number of
available megabytes of memory.  You may simplify this somewhat more,
it's derived from the Origin code.

        free_start = PFN_ALIGN(&_end) - PAGE_OFFSET;
        free_end = PAGE_OFFSET + (mb << 20);
        start_pfn = PFN_UP((unsigned long)&_end - PAGE_OFFSET);

        /* Register all the contiguous memory with the bootmem allocator
           and free it.  Be careful about the bootmem freemap.  */
        bootmap_size = init_bootmem(start_pfn, mb << (20 - PAGE_SHIFT));

	/* Free the entire available memory after the _end symbol.  */
        free_bootmem(__pa(free_start), (mb << 20) - __pa(free_start));

	/* We also did free the memory where the bootmap is stored,
	   reserve it again. */
        reserve_bootmem(__pa(free_start), bootmap_size);

        printk("Found %ldmb of memory.\n", mb);

  Ralf

From Andre.McCurdy@soton.sc.philips.com  Wed Feb  2 14:01:17 2000
Received: from gw-nl4.philips.com (gw-nl4.philips.com [192.68.44.36]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id OAA00208; Wed, 2 Feb 2000 14:01:16 +0100 (MET)
Received-Date: Wed, 2 Feb 2000 14:01:16 +0100 (MET)
Received: from smtprelay-nl1.philips.com (localhost.philips.com [127.0.0.1])
          by gw-nl4.philips.com with ESMTP id OAA17696
          for <linux-mips@fnet.fr>; Wed, 2 Feb 2000 14:01:14 +0100 (MET)
          (envelope-from Andre.McCurdy@soton.sc.philips.com)
Received: from smtprelay-eur1.philips.com(130.139.36.3) by gw-nl4.philips.com via mwrap (4.0a)
	id xma017690; Wed, 2 Feb 00 14:01:15 +0100
Received: from mailgate.soton.sc.philips.com (mailgate.soton.sc.philips.com [130.141.89.1]) 
	by smtprelay-nl1.philips.com (8.9.3/8.8.5-1.2.2m-19990317) with ESMTP id OAA02439
	for <linux-mips@fnet.fr>; Wed, 2 Feb 2000 14:01:13 +0100 (MET)
Received: from dice.soton.sc.philips.com ([130.141.7.40]) 
	by mailgate.soton.sc.philips.com (8.6.10/8.6.10-1.001a-24Jul96) with ESMTP id MAA02650
	for <linux-mips@fnet.fr>; Wed, 2 Feb 2000 12:59:51 GMT
Received: from dice (localhost [127.0.0.1]) 
	by dice.soton.sc.philips.com (8.6.10/8.6.10-1.001a-24Jul96) with SMTP id MAA15359
	for <linux-mips@fnet.fr>; Wed, 2 Feb 2000 12:59:51 GMT
Sender: andre.mccurdy@soton.sc.philips.com
Message-ID: <38982A47.1B9C@soton.sc.philips.com>
Date: Wed, 02 Feb 2000 12:59:51 +0000
From: Andre McCurdy <Andre.McCurdy@soton.sc.philips.com>
Organization: Philips Semiconductors.
X-Mailer: Mozilla 3.01Gold (X11; I; HP-UX B.10.20 9000/879)
MIME-Version: 1.0
To: linux-mips@fnet.fr
Subject: Re: how can I join the mailing list.. ?
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Length: 640
Lines: 20

> > how can I join the mailing list?
> 
> You already made to the list, from the howto at
> http://www.linux.sgi.com/mips/mips-howto.html
> 
> This mailing list is used for most non-SGI related communication of
> all kinds. Subscription is handled by a human; send your
> subscription requests to linux-mips-mips@fnet.fr. You can
> unsubscribe from this mailing list by sending unsubscribe
> <your-email-ad dress> to the same address.

Apologies if this goes to everyone.

I'm trying to unsubscribe, but mail to linux-mips-mips@fnet.fr doesn't
seem to get through. Could I please:

unsubscribe andre.mccurdy@soton.sc.philips.com

Thanks
--

From <@Cologne.DE:karsten@excalibur.cologne.de>  Wed Feb  2 22:06:51 2000
Received: from fileserv2.Cologne.DE (fileserv2.cologne.de [193.29.188.3]) by guadalquivir.fnet.fr with SMTP (8.8.8/97.02.12/Guadalquivir); id WAA03060; Wed, 2 Feb 2000 22:06:50 +0100 (MET)
Received-Date: Wed, 2 Feb 2000 22:06:50 +0100 (MET)
Received: from localhost (1395 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 <m12G6zB-00071GC@fileserv2.Cologne.DE>
	for <linux-mips@fnet.fr>; Wed, 2 Feb 2000 22:06:49 +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 VAA05024;
	Wed, 2 Feb 2000 21:41:14 +0100
Message-ID: <20000202214114.A4526@excalibur.cologne.de>
Date: Wed, 2 Feb 2000 21:41:14 +0100
From: Karsten Merker <karsten@excalibur.cologne.de>
To: Andre McCurdy <Andre.McCurdy@soton.sc.philips.com>
Cc: linux-mips@fnet.fr
Subject: Re: how can I join the mailing list.. ?
Mail-Followup-To: Andre McCurdy <Andre.McCurdy@soton.sc.philips.com>,
	linux-mips@fnet.fr
References: <38982A47.1B9C@soton.sc.philips.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.91i
In-Reply-To: <38982A47.1B9C@soton.sc.philips.com>; from Andre McCurdy on Wed, Feb 02, 2000 at 12:59:51PM +0000
X-No-Archive: yes
Content-Length: 493
Lines: 16

On Wed, Feb 02, 2000 at 12:59:51PM +0000, Andre McCurdy wrote:

> I'm trying to unsubscribe, but mail to linux-mips-mips@fnet.fr doesn't
> seem to get through. Could I please:
> 
> unsubscribe andre.mccurdy@soton.sc.philips.com

The address is linux-mips-request@fnet.fr.

HTH,
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 ralf@oss.sgi.com  Thu Feb  3 02:10:54 2000
Received: from mailhost.uni-koblenz.de (mailhost.uni-koblenz.de [141.26.64.1]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id CAA05392; Thu, 3 Feb 2000 02:10:54 +0100 (MET)
Received-Date: Thu, 3 Feb 2000 02:10:54 +0100 (MET)
Received: from cacc-17.uni-koblenz.de (cacc-17.uni-koblenz.de [141.26.131.17])
	by mailhost.uni-koblenz.de (8.9.3/8.9.3) with ESMTP id CAA20314;
	Thu, 3 Feb 2000 02:10:49 +0100 (MET)
Received: by lappi.waldorf-gmbh.de id <S407893AbQBCBKS>;
	Thu, 3 Feb 2000 02:10:18 +0100
Date: Thu, 3 Feb 2000 02:10:18 +0100
From: Ralf Baechle <ralf@oss.sgi.com>
To: linux@engr.sgi.com, linux-mips@fnet.fr, linux-mips@vger.rutgers.edu
Subject: Indy crashes
Message-ID: <20000203021018.A25786@uni-koblenz.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0pre3us
X-Accept-Language: de,en,fr
Content-Length: 459
Lines: 12

Today I exchanged the R5000 CPU module in my Indy against a R4600 module
and found that on R4600SC the kernel runs reliable while it crashs pretty
soon after booting on a R5000SC module.  This is consistent with the
reports that I've looked at.

I'd appreciate some more reports from people who did upgrade from a
kernel older than 2.3.11 to 2.3.11 or newer.  Do you experience crashes
with the newer kernel?  What type of CPU are you using?

Thanks,

  Ralf

From aj@suse.de  Thu Feb  3 09:43:13 2000
Received: from news-ma.rhein-neckar.de (news-ma.rhein-neckar.de [193.197.90.3]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id JAA07362; Thu, 3 Feb 2000 09:43:12 +0100 (MET)
Received-Date: Thu, 3 Feb 2000 09:43:12 +0100 (MET)
Received: from arthur.rhein-neckar.de (uucp@localhost)
	by news-ma.rhein-neckar.de (8.8.8/8.8.8) with bsmtp id JAA28327
	for linux-mips@fnet.fr; Thu, 3 Feb 2000 09:43:11 +0100 (CET)
	(envelope-from aj@suse.de)
Received: from gromit.rhein-neckar.de ([192.168.27.3] ident=postfix)
	by arthur.rhein-neckar.de with esmtp (Exim 3.11 #1)
	id 12GHfm-00030J-00
	for linux-mips@fnet.fr; Thu, 03 Feb 2000 09:31:30 +0100
Received: by gromit.rhein-neckar.de (Postfix, from userid 207)
	id 4291E182C; Thu,  3 Feb 2000 09:31:29 +0100 (CET)
Sender: aj@suse.de
Mail-Copies-To: never
To: linux-mips@fnet.fr
Subject: abort instruction for Mips?
From: Andreas Jaeger <aj@suse.de>
Date: 03 Feb 2000 09:31:28 +0100
Message-ID: <u8iu06g00v.fsf@gromit.rhein-neckar.de>
User-Agent: Gnus/5.0804 (Gnus v5.8.4) XEmacs/21.2 (Hera)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Length: 504
Lines: 22


For glibc I could use [1] an abort instruction as fail safe to abort a
program.  Is there any way to achieve this?

For example on m68k I can use:
/* An instruction which should crash any program is `illegal'.  */
#define ABORT_INSTRUCTION asm ("illegal")

and on ix86:
/* An instruction which should crash any program is `hlt'.  */
#define ABORT_INSTRUCTION asm ("hlt")


Andreas

Footnotes: 
[1]  It works also without.

-- 
 Andreas Jaeger
  SuSE Labs aj@suse.de
   private aj@arthur.rhein-neckar.de

From dom@mudchute.algor.co.uk  Thu Feb  3 10:05:59 2000
Received: from kenton.algor.co.uk (root@kenton.algor.co.uk [193.117.190.25]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id KAA07526; Thu, 3 Feb 2000 10:05:57 +0100 (MET)
Received-Date: Thu, 3 Feb 2000 10:05:57 +0100 (MET)
Received: from mudchute.algor.co.uk (dom@mudchute.algor.co.uk [193.117.190.19])
	by kenton.algor.co.uk (8.8.8/8.8.8) with ESMTP id JAA27729;
	Thu, 3 Feb 2000 09:05:50 GMT
Received: (from dom@localhost)
	by mudchute.algor.co.uk (8.8.5/8.8.5) id JAA05548;
	Thu, 3 Feb 2000 09:05:50 GMT
Date: Thu, 3 Feb 2000 09:05:50 GMT
Message-Id: <200002030905.JAA05548@mudchute.algor.co.uk>
From: Dominic Sweetman <dom@algor.co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
To: Andreas Jaeger <aj@suse.de>
Cc: linux-mips@fnet.fr
Subject: Re: abort instruction for Mips?
In-Reply-To: <u8iu06g00v.fsf@gromit.rhein-neckar.de>
References: <u8iu06g00v.fsf@gromit.rhein-neckar.de>
X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid
Content-Length: 459
Lines: 16


Andreas Jaeger (aj@suse.de) writes:

> For glibc I could use [1] an abort instruction as fail safe to abort a
> program.  Is there any way to achieve this?

Unless someone comes up with some Linux-recommended prior art, 

  break 255

should work.  It's a breakpoint for the debugger, but it's
probably a good thing that a debugger should catch an abort.  An
astute debugger may look at the code value and complain further.

Dominic Sweetman
dom@algor.co.uk

From jbresnik@home.com  Tue Feb  8 06:47:38 2000
Received: from mail.rdc1.sdca.home.com (imail@ha1.rdc1.sdca.home.com [24.0.3.66]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id GAA17501; Tue, 8 Feb 2000 06:47:37 +0100 (MET)
Received-Date: Tue, 8 Feb 2000 06:47:37 +0100 (MET)
Received: from CX823089-A ([24.0.186.48]) by mail.rdc1.sdca.home.com
          (InterMail v4.01.01.00 201-229-111) with SMTP
          id <20000208054729.VLFD18874.mail.rdc1.sdca.home.com@CX823089-A>
          for <linux-mips@fnet.fr>; Mon, 7 Feb 2000 21:47:29 -0800
Message-ID: <000b01bf71f7$efa51ee0$30ba0018@CX823089-A.escnd1.sdca.home.com>
From: "johnBresnik" <jbresnik@home.com>
To: <linux-mips@fnet.fr>
Subject: Yous still in business?
Date: Mon, 7 Feb 2000 21:47:07 -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 4.72.3110.1
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Content-Length: 259
Lines: 7

Hello.    I just bought a DECStation 3100 for $20
but with no monitor or keyboard. you wouldn't know
where I could get one do ya? I bought it to learn the
MIPS instruction set; and would be willing to help
out if I could just get the thing going... 

Thanks.

From mitch@sfgoth.com  Tue Feb  8 12:12:24 2000
Received: from schmee.sfgoth.com (mitch@dhcp41.toaster.net [199.108.84.41]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id MAA20730; Tue, 8 Feb 2000 12:12:23 +0100 (MET)
Received-Date: Tue, 8 Feb 2000 12:12:23 +0100 (MET)
Received: (from mitch@localhost)
	by schmee.sfgoth.com (8.9.3/8.9.3) id DAA54771;
	Tue, 8 Feb 2000 03:12:09 -0800 (PST)
Date: Tue, 8 Feb 2000 03:12:09 -0800
From: Mitchell Blank Jr <mitch@sfgoth.com>
To: johnBresnik <jbresnik@home.com>
Cc: linux-mips@fnet.fr
Subject: Re: Yous still in business?
Message-ID: <20000208031209.D53038@sfgoth.com>
References: <000b01bf71f7$efa51ee0$30ba0018@CX823089-A.escnd1.sdca.home.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0i
In-Reply-To: <000b01bf71f7$efa51ee0$30ba0018@CX823089-A.escnd1.sdca.home.com>; from jbresnik@home.com on Mon, Feb 07, 2000 at 09:47:07PM -0800
Content-Length: 1315
Lines: 29

johnBresnik wrote:
> Hello.    I just bought a DECStation 3100 for $20
> but with no monitor or keyboard. you wouldn't know
> where I could get one do ya?

Monitor - I suspect you're screwed.  IIRC, the mono DECstation monitors
were custom TTL beasts... they're probably getting fairly rare.

Keyboard (that's the little RJ14 "phone jack" connector).  If I remember
right the 3100 shared a keyboard with the VT320, a very popular terminal.
I might be wrong though.

However, you don't need a keyboard or monitor to have a useful machine.
If you power on the machine without a keyboard it should come up with
a serial console (I've never actually done this on a 3100 but I have on
many other DECstations, so I assume the 3100 works too).  The 3100 uses
MMJ jacks (the things that look like a phone jack but with the tab off-
center).  This is the same jack the VT-320 used - search the web for the
pinouts.  You might be able to find a MMJ cable somewhere (old VMS shops
tend to have them lying around).  Another possibility is build one - take
a semi-standard 6-pin phone jack and break the tab off.. then use duct
tape to hold it in the jack :-)

Anyway one of the serial ports should give you a console... 9600bps 8N1.

Also, check out http://decstation.unix-ag.org/ for all the
linux-on-decstation info.

-Mitch

From brenth@engr.uconn.edu  Wed Feb  9 06:09:42 2000
Received: from UCONNVM.UConn.Edu (uconnvm.uconn.edu [137.99.26.3]) by guadalquivir.fnet.fr with SMTP (8.8.8/97.02.12/Guadalquivir); id GAA29625; Wed, 9 Feb 2000 06:09:41 +0100 (MET)
Received-Date: Wed, 9 Feb 2000 06:09:41 +0100 (MET)
Received: from *unknown [137.99.136.155] by UCONNVM.UConn.Edu (IBM VM SMTP V2R4a) via TCP with SMTP ; Wed, 09 Feb 2000 00:09:28 EST
X-Warning: UCONNVM.UConn.Edu: Could not confirm that host  [137.99.136.155] is cyn
Message-ID: <000801bf72bb$d65aa9e0$9b886389@cyn>
From: "brent" <brenth@engr.uconn.edu>
To: <linux-mips@fnet.fr>
Subject: linux/mips
Date: Wed, 9 Feb 2000 00:09:22 -0500
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0005_01BF7291.EAEBF5A0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2919.6700
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700
Content-Length: 1859
Lines: 54

This is a multi-part message in MIME format.

------=_NextPart_000_0005_01BF7291.EAEBF5A0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

hi,

i have an old sgi indy that i have come across, that i would like to put =
linux on.  i do not know how far the development has gone for the sgi =
indy machines, but it does not look like it has been worked on recently.

i was wondering if they had ever come out with a bootdisk image that i =
can install linux on directly without having to have irix already on the =
disk.  also, i'd like to know if they support DHCP installs.

thank you,
-brent

------=_NextPart_000_0005_01BF7291.EAEBF5A0
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.2920.0" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>hi,</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>i have an old sgi indy that i have come =
across,=20
that i would like to put linux on.&nbsp; i do not know how far the =
development=20
has gone for the sgi indy machines, but it does not look like it has =
been worked=20
on recently.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>i was wondering if they had ever come =
out with a=20
bootdisk image that i can install linux on directly without having to =
have irix=20
already on the disk.&nbsp; also, i'd like to know if they support DHCP=20
installs.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>thank you,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>-brent</FONT></DIV></BODY></HTML>

------=_NextPart_000_0005_01BF7291.EAEBF5A0--

From jharrell@ti.com  Wed Feb  9 21:33:48 2000
Received: from gatekeep.ti.com (gatekeep.ti.com [192.94.94.61]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id VAA07763; Wed, 9 Feb 2000 21:33:47 +0100 (MET)
Received-Date: Wed, 9 Feb 2000 21:33:47 +0100 (MET)
Received: from dlep7.itg.ti.com ([157.170.134.103])
	by gatekeep.ti.com (8.9.3/8.9.3) with ESMTP id OAA08445;
	Wed, 9 Feb 2000 14:32:59 -0600 (CST)
Received: from dlep7.itg.ti.com (localhost [127.0.0.1])
	by dlep7.itg.ti.com (8.9.3/8.9.3) with ESMTP id OAA21227;
	Wed, 9 Feb 2000 14:32:54 -0600 (CST)
Received: from dlep4.itg.ti.com (dlep4.itg.ti.com [157.170.188.63])
	by dlep7.itg.ti.com (8.9.3/8.9.3) with ESMTP id OAA21216;
	Wed, 9 Feb 2000 14:32:53 -0600 (CST)
Received: from ti.com (IDENT:jharrell@pcp97780pcs.sc.ti.com [158.218.100.100])
	by dlep4.itg.ti.com (8.9.3/8.9.3) with ESMTP id OAA22208;
	Wed, 9 Feb 2000 14:32:57 -0600 (CST)
Sender: jharrell@dsbmail.itg.ti.com
Message-ID: <38A1CFAE.EFA429BA@ti.com>
Date: Wed, 09 Feb 2000 13:35:58 -0700
From: Jeff Harrell <jharrell@ti.com>
X-Mailer: Mozilla 4.61 [en] (X11; U; Linux 2.2.12-20 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: sgi-mips <linux@cthulhu.engr.sgi.com>, linux-mips <linux-mips@fnet.fr>,
        linux-mips <linux-mips@vger.rutgers.edu>
Subject: Question concerning memory initialization (4M->64M)
Content-Type: multipart/alternative;
 boundary="------------0BB6A84381EA7F784BD03864"
Content-Length: 2992
Lines: 88


--------------0BB6A84381EA7F784BD03864
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit


I have run into an interesting problem and would like to run it past
this newsgroup
to see if anyone has any experience in these areas.  I am running kernel
2.3.22 and
have upgraded my memory space from ~4M (0x400000) to ~64M (0x4000000).
I run the 4M
version of the kernel and have no problems but when I run the 64M
version, I run
into problems during the mem_init() portion of the code.  Specifically
during the
free_page(tmp) call during the determination of totalram, codepages and
datapages.
It looks like it is failing during the call to remove_mem_queue() within
free_pages_ok().
I am seeing the next->prev and prev->next  set to 0 causing a page
fault.   Is there
anything that anyone is aware of that I would need to change (beyond
mips_memory_upper)
that would enable me to increase available memory to 64M.  Any insights
would be greatly appreciated.

Thanks
Jeff

Additional information:
------------------

high memory: 0x83fff000  start memory: 0x80433000

--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Jeff Harrell                    Work:  (801) 619-6104
Broadband Access group/TI
jharrell@ti.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~





--------------0BB6A84381EA7F784BD03864
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
&nbsp;
<br>I have run into an interesting problem and would like to run it past
this newsgroup
<br>to see if anyone has any experience in these areas.&nbsp; I am running
kernel 2.3.22 and
<br>have upgraded my memory space from ~4M (0x400000) to ~64M (0x4000000).&nbsp;
I run the 4M
<br>version of the kernel and have no problems but when I run the 64M version,
I run
<br>into problems during the mem_init() portion of the code.&nbsp; Specifically
during the
<br>free_page(tmp) call during the determination of totalram, codepages
and datapages.
<br>It looks like it is failing during the call to remove_mem_queue() within
free_pages_ok().
<br>I am seeing the next->prev and prev->next&nbsp; set to 0 causing a
page fault.&nbsp;&nbsp; Is there
<br>anything that anyone is aware of that I would need to change (beyond
mips_memory_upper)
<br>that would enable me to increase available memory to 64M.&nbsp; Any
insights would be greatly appreciated.
<p>Thanks
<br>Jeff
<p>Additional information:
<br>------------------
<p>high memory: 0x83fff000&nbsp; start memory: 0x80433000
<pre>--&nbsp;
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Jeff Harrell&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Work:&nbsp; (801) 619-6104&nbsp;
Broadband Access group/TI&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
jharrell@ti.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~</pre>
&nbsp;
<p>&nbsp;</html>

--------------0BB6A84381EA7F784BD03864--

From kevink@mips.com  Wed Feb  9 23:26:16 2000
Received: from mx.mips.com (mx.mips.com [206.31.31.226]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id XAA08376; Wed, 9 Feb 2000 23:26:15 +0100 (MET)
Received-Date: Wed, 9 Feb 2000 23:26:15 +0100 (MET)
Received: from newman.mips.com (newman [206.31.31.8])
	by mx.mips.com (8.9.3/8.9.0) with ESMTP id OAA18768;
	Wed, 9 Feb 2000 14:26:12 -0800 (PST)
Received: from satanas (satanas [192.168.236.12])
	by newman.mips.com (8.9.3/8.9.0) with SMTP id OAA17960;
	Wed, 9 Feb 2000 14:26:08 -0800 (PST)
Message-ID: <002401bf734c$e8b5cac0$0ceca8c0@satanas.mips.com>
From: "Kevin D. Kissell" <kevink@mips.com>
To: <linux@cthulhu.engr.sgi.com>, <linux-mips@fnet.fr>
Subject: Enhanced 2.2.12 MIPS Kernel Sources  Available
Date: Wed, 9 Feb 2000 23:27:52 +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 4.72.3110.5
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Content-Length: 2307
Lines: 56

As many of you will have inferred, MIPS Technologies Inc
has been working on the MIPS/Linux kernel for the past
six months or so, driven by the need for a flexible software
platform for valdiation and characterisation of new MIPS
processor designs.  Relatively early on, we made the difficult
decision not to try to track the SGI Linux repository: It was
too unstable, and the SGI activity is driven by a very
different set of goals.  We therefore took the 2.2.12
kernel sources from kernel.org, and worked from there.
I've shared some of our bug findings and fixes with 
the SGI mailing list, and still more of them with Ralf
directly, but a lot of other changes and improvements
have been made that will certainly be of interest to readers
of this list, particularly those targeting non-SGI platforms.

This kernel supports the new generation of 32-bit MIPS
CPUs with R4K exception models.  This involved fairly
extensive changes to semaphore support and to TLB
and cache management routines.  We know it works on
the MIPS 4Kc, and with appropriate additions to the
table of recognized CPUs in the (revised) CPU probe
code, it should run on the IDT 323xx, and Toshiba TX49
processor families as well.

It includes an integrated FPU emulator that handles 
the full MIPS FP instruction set, and allows FPU-less
CPUs to run standard MIPS/Linux binaries.

It contains a number of endianness fixes in the kernel
and driver code, and is very stable in both configurations.

It contains platform support for the Algorithmics P-5064
and MIPS "Atlas" development boards, as well as the
SGI Indy.

This code is NOT a supported product of MIPS
Technologies Inc.   It is being made available on an
"as is" basis subject to the ususal GPL.  It should be
accessible via anonymous (and blind) FTP for a while at
ftp://ftp.mips.com/incoming/linux.mips.src.01.01.tar.gz
and is archived on the Paralogos MIPS/Linux web site at 
http://www.paralogos.com/mipslinux/.  We'd be very interested
in any feedback, experimental results, and enhancements
that any of you may wish to provide, and I will answer
email questions to the extent that my time allows.

            Regards,

            Kevin K.
__

Kevin D. Kissell
MIPS Technologies European Architecture Lab
kevink@mips.com
Tel. +33.4.78.38.70.67
FAX. +33.4.78.38.70.68

From rabeeh@galileo.co.il  Wed Feb  9 19:25:21 2000
Received: from galileo5.galileo.co.il ([192.116.246.130]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id TAA06831; Wed, 9 Feb 2000 19:25:18 +0100 (MET)
Received-Date: Wed, 9 Feb 2000 19:25:18 +0100 (MET)
Received: from galileo.co.il ([10.2.20.126])
	by galileo.co.il (8.8.5/8.8.5) with ESMTP id UAA16506
	for <linux-mips@fnet.fr>; Wed, 9 Feb 2000 20:25:29 +0200 (GMT-2)
Sender: rabeeh@galileo.co.il
Message-ID: <38A213E5.BB2E9004@galileo.co.il>
Date: Wed, 09 Feb 2000 20:27:01 -0500
From: Rabeeh Khoury <rabeeh@galileo.co.il>
X-Mailer: Mozilla 4.51 [en] (X11; I; Linux 2.2.5-15 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: "linux-mips@fnet.fr" <linux-mips@fnet.fr>
Subject: error in compilation
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Length: 1525
Lines: 39

Hi all

In cross-compiling the r2300.c file in arch/mips/mm I get these error
messages :

make[2]: Entering directory
`/home/rabeeh/RottProject_Galileo/linux/arch/mips/mm'
mips-linux-gcc -D__KERNEL__
-I/home/rabeeh/RottProject_Galileo/linux/include -Wall
-Wstrict-prototypes -O2 -fomit-frame-pointer -G 0 -mno-abicalls -fno-pic
-mcpu=r3000 -mips1 -pipe   -c -o r2300.o r2300.c
r2300.c:429: `flush_tlb_all' redeclared as different kind of symbol
/home/rabeeh/RottProject_Galileo/linux/include/asm/pgalloc.h:37:
previous declaration of `flush_tlb_all'
r2300.c:451: `flush_tlb_mm' redeclared as different kind of symbol
/home/rabeeh/RottProject_Galileo/linux/include/asm/pgalloc.h:38:
previous declaration of `flush_tlb_mm'
r2300.c:468: `flush_tlb_range' redeclared as different kind of symbol
/home/rabeeh/RottProject_Galileo/linux/include/asm/pgalloc.h:40:
previous declaration of `flush_tlb_range'
r2300.c:510: `flush_tlb_page' redeclared as different kind of symbol
/home/rabeeh/RottProject_Galileo/linux/include/asm/pgalloc.h:41:
previous declaration of `flush_tlb_page'
r2300.c:539: warning: `r2300_load_pgd' defined but not used
make[2]: *** [r2300.o] Error 1
make[2]: Leaving directory
`/home/rabeeh/RottProject_Galileo/linux/arch/mips/mm'
make[1]: *** [first_rule] Error 2
make[1]: Leaving directory
`/home/rabeeh/RottProject_Galileo/linux/arch/mips/mm'
make: *** [_dir_arch/mips/mm] Error 2


I'v just recently got the newest sources for the CVS tree on
linus.linux.sgi.com

do you know whats going on ??!!

thank you

From alhaz@xmission.com  Thu Feb 10 05:54:26 2000
Received: from mail.xmission.com (root@mail.xmission.com [198.60.22.22]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id FAA12776; Thu, 10 Feb 2000 05:54:25 +0100 (MET)
Received-Date: Thu, 10 Feb 2000 05:54:25 +0100 (MET)
Received: from xmission.xmission.com ([198.60.22.20])
	by mail.xmission.com with esmtp (Exim 3.03 #3)
	id 12IlcU-0004ha-00
	for linux-mips@fnet.fr; Wed, 09 Feb 2000 21:54:22 -0700
Received: from alhaz by xmission.xmission.com with local (Exim 2.12 #1)
	id 12IlcS-0002us-00
	for linux-mips@fnet.fr; Wed, 9 Feb 2000 21:54:20 -0700
Subject: Indigo2 XL? 
To: linux-mips@fnet.fr
Date: Wed, 9 Feb 2000 21:54:19 -0700 (MST)
X-Mailer: ELM [version 2.5 PL2]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <E12IlcS-0002us-00@xmission.xmission.com>
From: Eric Jorgensen <alhaz@xmission.com>
Content-Length: 734
Lines: 22


	I picked up one of these puppies tonight, $75, oodles of simms,
cdrom drive, no harddrives or harddrive sleds. 

	What's support like for these? is graphics support still pretty
much lacking? 

	So far i haven't managed to hook up any sort of console to it. If
someone knows where i can get a cheap adapter to hook it up to an SVGA
monitor (less than $25) that'd be great. Otherwise I'm cannibalizing a
cable off a dead Sun moinitor. 

	Speaking of which, has SGI ever changed their monitor pinout? I
have a 13W3 pinout for them that actually refers to my Magnum4k, wondering
if that works ok. 

	And finally, any chance i can pull up a serial console on this
thing, while I'm working on the whole monitor issue? 

	Thanks

 - Eric

From alhaz@xmission.com  Thu Feb 10 06:58:53 2000
Received: from mail.xmission.com (root@mail.xmission.com [198.60.22.22]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id GAA13093; Thu, 10 Feb 2000 06:58:52 +0100 (MET)
Received-Date: Thu, 10 Feb 2000 06:58:52 +0100 (MET)
Received: from xmission.xmission.com ([198.60.22.20])
	by mail.xmission.com with esmtp (Exim 3.03 #3)
	id 12Imcr-00056B-00; Wed, 09 Feb 2000 22:58:49 -0700
Received: from alhaz by xmission.xmission.com with local (Exim 2.12 #1)
	id 12Imcq-0005YB-00; Wed, 9 Feb 2000 22:58:48 -0700
Subject: Re: Indigo2 XL?
To: alhaz@xmission.com (Eric Jorgensen)
Date: Wed, 9 Feb 2000 22:58:48 -0700 (MST)
Cc: linux-mips@fnet.fr
In-Reply-To: <E12IlcS-0002us-00@xmission.xmission.com> from "Eric Jorgensen" at Feb 09, 2000 09:54:19 PM
X-Mailer: ELM [version 2.5 PL2]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <E12Imcq-0005YB-00@xmission.xmission.com>
From: Eric Jorgensen <alhaz@xmission.com>
Content-Length: 956
Lines: 32

	I did get the serial console up - 150mhz r4400, 128 megs of ram, 1
meg cache, quite a catch for the price. 

	Anybody know where i can get a harddrive sled? 

 - Eric

> 
> 
> 	I picked up one of these puppies tonight, $75, oodles of simms,
> cdrom drive, no harddrives or harddrive sleds. 
> 
> 	What's support like for these? is graphics support still pretty
> much lacking? 
> 
> 	So far i haven't managed to hook up any sort of console to it. If
> someone knows where i can get a cheap adapter to hook it up to an SVGA
> monitor (less than $25) that'd be great. Otherwise I'm cannibalizing a
> cable off a dead Sun moinitor. 
> 
> 	Speaking of which, has SGI ever changed their monitor pinout? I
> have a 13W3 pinout for them that actually refers to my Magnum4k, wondering
> if that works ok. 
> 
> 	And finally, any chance i can pull up a serial console on this
> thing, while I'm working on the whole monitor issue? 
> 
> 	Thanks
> 
>  - Eric
> 
> 

From raiko@niisi.msk.ru  Thu Feb 10 10:49:29 2000
Received: from t111.niisi.ras.ru (root@t111.niisi.ras.ru [193.232.173.111]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id KAA15002; Thu, 10 Feb 2000 10:49:27 +0100 (MET)
Received-Date: Thu, 10 Feb 2000 10:49:27 +0100 (MET)
Received: from t06.niisi.ras.ru (t06.niisi.ras.ru [193.232.173.6])
	by t111.niisi.ras.ru (8.9.1/8.9.1) with ESMTP id MAA19459;
	Thu, 10 Feb 2000 12:49:59 +0300
Received: (from uucp@localhost) by t06.niisi.ras.ru (8.7.6/8.7.3) with UUCP id MAA14956; Thu, 10 Feb 2000 12:53:21 +0300
Received: from niisi.msk.ru (t34 [193.232.173.34]) by niisi.msk.ru (8.8.8/8.8.8) with ESMTP id MAA25629; Thu, 10 Feb 2000 12:39:02 +0300 (MSK)
Message-ID: <38A28945.2C193AE8@niisi.msk.ru>
Date: Thu, 10 Feb 2000 12:47:50 +0300
From: "Gleb O. Raiko" <raiko@niisi.msk.ru>
Organization: NIISI RAN
X-Mailer: Mozilla 4.7 [en] (WinNT; I)
X-Accept-Language: en,ru
MIME-Version: 1.0
To: "Kevin D. Kissell" <kevink@mips.com>
CC: linux@cthulhu.engr.sgi.com, linux-mips@fnet.fr
Subject: Re: Enhanced 2.2.12 MIPS Kernel Sources  Available
References: <002401bf734c$e8b5cac0$0ceca8c0@satanas.mips.com>
Content-Type: text/plain; charset=koi8-r
Content-Transfer-Encoding: 7bit
Content-Length: 1001
Lines: 23

"Kevin D. Kissell" wrote:
> 
> This code is NOT a supported product of MIPS
> Technologies Inc.   It is being made available on an
> "as is" basis subject to the ususal GPL.  It should be
> accessible via anonymous (and blind) FTP for a while at
> ftp://ftp.mips.com/incoming/linux.mips.src.01.01.tar.gz
> and is archived on the Paralogos MIPS/Linux web site at
> http://www.paralogos.com/mipslinux/.  We'd be very interested
> in any feedback, experimental results, and enhancements
> that any of you may wish to provide, and I will answer
> email questions to the extent that my time allows.
> 

It'll be great if you would put just patches too. I guess, it'll be easy
for us to look through set of patches instead of downloading entire
2.2.12 and making diff -ruN on it. Then, there might be a core patch
that decribes changes in machine independent part of the kernel and the
rest might cover specific boards. Most of developers here will be
interested in the core patch, I guess.

Regards,
Gleb.

From brad@ltc.com  Thu Feb 10 11:06:48 2000
Received: from ltc.com (ltc.ltc.com [38.149.17.171]) by guadalquivir.fnet.fr with SMTP (8.8.8/97.02.12/Guadalquivir); id LAA15147; Thu, 10 Feb 2000 11:06:46 +0100 (MET)
Received-Date: Thu, 10 Feb 2000 11:06:46 +0100 (MET)
Received: from d184.ltc.com (d184.ltc.com [38.149.17.184]) by ltc.com (NTMail 3.03.0017/1.afdd) with ESMTP id ca312054 for <linux-mips@fnet.fr>; Thu, 10 Feb 2000 05:08:19 -0500
Message-ID: <046d01bf73ae$7b2aced0$b8119526@ltc.com>
From: "Bradley D. LaRonde" <brad@ltc.com>
To: "Kevin D. Kissell" <kevink@mips.com>, <linux@cthulhu.engr.sgi.com>,
        <linux-mips@fnet.fr>
References: <002401bf734c$e8b5cac0$0ceca8c0@satanas.mips.com>
Subject: Re: Enhanced 2.2.12 MIPS Kernel Sources  Available
Date: Thu, 10 Feb 2000 05:06:21 -0500
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
Content-Length: 2729
Lines: 69

RFC: What about geting the same FPU emulation into SGI's tree?

Regards,
Brad

----- Original Message ----- 
From: "Kevin D. Kissell" <kevink@mips.com>
To: <linux@cthulhu.engr.sgi.com>; <linux-mips@fnet.fr>
Sent: Wednesday, February 09, 2000 5:27 PM
Subject: Enhanced 2.2.12 MIPS Kernel Sources Available


> As many of you will have inferred, MIPS Technologies Inc
> has been working on the MIPS/Linux kernel for the past
> six months or so, driven by the need for a flexible software
> platform for valdiation and characterisation of new MIPS
> processor designs.  Relatively early on, we made the difficult
> decision not to try to track the SGI Linux repository: It was
> too unstable, and the SGI activity is driven by a very
> different set of goals.  We therefore took the 2.2.12
> kernel sources from kernel.org, and worked from there.
> I've shared some of our bug findings and fixes with 
> the SGI mailing list, and still more of them with Ralf
> directly, but a lot of other changes and improvements
> have been made that will certainly be of interest to readers
> of this list, particularly those targeting non-SGI platforms.
> 
> This kernel supports the new generation of 32-bit MIPS
> CPUs with R4K exception models.  This involved fairly
> extensive changes to semaphore support and to TLB
> and cache management routines.  We know it works on
> the MIPS 4Kc, and with appropriate additions to the
> table of recognized CPUs in the (revised) CPU probe
> code, it should run on the IDT 323xx, and Toshiba TX49
> processor families as well.
> 
> It includes an integrated FPU emulator that handles 
> the full MIPS FP instruction set, and allows FPU-less
> CPUs to run standard MIPS/Linux binaries.
> 
> It contains a number of endianness fixes in the kernel
> and driver code, and is very stable in both configurations.
> 
> It contains platform support for the Algorithmics P-5064
> and MIPS "Atlas" development boards, as well as the
> SGI Indy.
> 
> This code is NOT a supported product of MIPS
> Technologies Inc.   It is being made available on an
> "as is" basis subject to the ususal GPL.  It should be
> accessible via anonymous (and blind) FTP for a while at
> ftp://ftp.mips.com/incoming/linux.mips.src.01.01.tar.gz
> and is archived on the Paralogos MIPS/Linux web site at 
> http://www.paralogos.com/mipslinux/.  We'd be very interested
> in any feedback, experimental results, and enhancements
> that any of you may wish to provide, and I will answer
> email questions to the extent that my time allows.
> 
>             Regards,
> 
>             Kevin K.
> __
> 
> Kevin D. Kissell
> MIPS Technologies European Architecture Lab
> kevink@mips.com
> Tel. +33.4.78.38.70.67
> FAX. +33.4.78.38.70.68
> 

From kevink@mips.com  Thu Feb 10 11:13:57 2000
Received: from mx.mips.com (mx.mips.com [206.31.31.226]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id LAA15219; Thu, 10 Feb 2000 11:13:56 +0100 (MET)
Received-Date: Thu, 10 Feb 2000 11:13:56 +0100 (MET)
Received: from newman.mips.com (newman [206.31.31.8])
	by mx.mips.com (8.9.3/8.9.0) with ESMTP id CAA01307;
	Thu, 10 Feb 2000 02:13:53 -0800 (PST)
Received: from satanas (satanas [192.168.236.12])
	by newman.mips.com (8.9.3/8.9.0) with SMTP id CAA06439;
	Thu, 10 Feb 2000 02:13:48 -0800 (PST)
Message-ID: <00bc01bf73af$c7b19bc0$0ceca8c0@satanas.mips.com>
From: "Kevin D. Kissell" <kevink@mips.com>
To: "Gleb O. Raiko" <raiko@niisi.msk.ru>
Cc: <linux@cthulhu.engr.sgi.com>, <linux-mips@fnet.fr>
Subject: Re: Enhanced 2.2.12 MIPS Kernel Sources  Available
Date: Thu, 10 Feb 2000 11:15:32 +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 4.72.3110.5
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Content-Length: 1272
Lines: 29

>"Kevin D. Kissell" wrote:
>> 
>> This code is NOT a supported product of MIPS
>> Technologies Inc.   It is being made available on an
>> "as is" basis subject to the ususal GPL.  It should be
>> accessible via anonymous (and blind) FTP for a while at
>> ftp://ftp.mips.com/incoming/linux.mips.src.01.01.tar.gz
>> and is archived on the Paralogos MIPS/Linux web site at
>> http://www.paralogos.com/mipslinux/.  We'd be very interested
>> in any feedback, experimental results, and enhancements
>> that any of you may wish to provide, and I will answer
>> email questions to the extent that my time allows.
>> 
>
>It'll be great if you would put just patches too. I guess, it'll be easy
>for us to look through set of patches instead of downloading entire
>2.2.12 and making diff -ruN on it. Then, there might be a core patch
>that decribes changes in machine independent part of the kernel and the
>rest might cover specific boards. Most of developers here will be
>interested in the core patch, I guess.
>
>Regards,
>Gleb.

The thought had certainly occurred to me to generate the patch
relative to the 2.2.12 baseline - it would certainly be more compact
than the whole source tree!   I'll try and find the time to do so, but
it probably won't be any time this week...


From kevink@mips.com  Thu Feb 10 14:16:01 2000
Received: from mx.mips.com (mx.mips.com [206.31.31.226]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id OAA16516; Thu, 10 Feb 2000 14:16:00 +0100 (MET)
Received-Date: Thu, 10 Feb 2000 14:16:00 +0100 (MET)
Received: from newman.mips.com (newman [206.31.31.8])
	by mx.mips.com (8.9.3/8.9.0) with ESMTP id FAA04130;
	Thu, 10 Feb 2000 05:15:50 -0800 (PST)
Received: from satanas (satanas [192.168.236.12])
	by newman.mips.com (8.9.3/8.9.0) with SMTP id FAA09715;
	Thu, 10 Feb 2000 05:15:48 -0800 (PST)
Message-ID: <00d801bf73c9$32d3b820$0ceca8c0@satanas.mips.com>
From: "Kevin D. Kissell" <kevink@mips.com>
To: "Bradley D. LaRonde" <brad@ltc.com>, <linux@cthulhu.engr.sgi.com>,
        <linux-mips@fnet.fr>
Subject: FPU Emulator (Re: Enhanced 2.2.12 MIPS Kernel Sources  Available)
Date: Thu, 10 Feb 2000 14:06:53 +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 4.72.3110.5
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Content-Length: 4080
Lines: 101

Hey, one reason I wanted to get the code out there
ASAP was to allow someone to do just that!

The bulk of the emulator lives in its own directory,
arch/mips/fpu_emulator, and the arch/mips/kernel/traps.c
hook is very simple.  There are, however, hooks that
need to be put into context switch, kgdb, and signal support
code here and there, and these key off some enhancements
we made to the CPU configuration code (e.g., there is
a mips_cpu data structure with an options field that
indicates the presence or absence of an FPU at
runtime).   In theory, the emulator is capable of executing
kernel FPU instructions and register register references
as well as those from user mode, but it's considerably
more efficient if the kernel knows to reference the simulator
state instead.  The work to merge all this into the SGI 2.3.xx
tree should not be too daunting, but it's not something that
MIPS is likely to take on internally any time soon.

            Regards,

            Kevin K.

-----Original Message-----
From: Bradley D. LaRonde <brad@ltc.com>
To: Kevin D. Kissell <kevink@mips.com>; linux@cthulhu.engr.sgi.com
<linux@cthulhu.engr.sgi.com>; linux-mips@fnet.fr <linux-mips@fnet.fr>
Date: Thursday, February 10, 2000 11:06 AM
Subject: Re: Enhanced 2.2.12 MIPS Kernel Sources Available


>RFC: What about geting the same FPU emulation into SGI's tree?
>
>Regards,
>Brad
>
>----- Original Message -----
>From: "Kevin D. Kissell" <kevink@mips.com>
>To: <linux@cthulhu.engr.sgi.com>; <linux-mips@fnet.fr>
>Sent: Wednesday, February 09, 2000 5:27 PM
>Subject: Enhanced 2.2.12 MIPS Kernel Sources Available
>
>
>> As many of you will have inferred, MIPS Technologies Inc
>> has been working on the MIPS/Linux kernel for the past
>> six months or so, driven by the need for a flexible software
>> platform for valdiation and characterisation of new MIPS
>> processor designs.  Relatively early on, we made the difficult
>> decision not to try to track the SGI Linux repository: It was
>> too unstable, and the SGI activity is driven by a very
>> different set of goals.  We therefore took the 2.2.12
>> kernel sources from kernel.org, and worked from there.
>> I've shared some of our bug findings and fixes with
>> the SGI mailing list, and still more of them with Ralf
>> directly, but a lot of other changes and improvements
>> have been made that will certainly be of interest to readers
>> of this list, particularly those targeting non-SGI platforms.
>>
>> This kernel supports the new generation of 32-bit MIPS
>> CPUs with R4K exception models.  This involved fairly
>> extensive changes to semaphore support and to TLB
>> and cache management routines.  We know it works on
>> the MIPS 4Kc, and with appropriate additions to the
>> table of recognized CPUs in the (revised) CPU probe
>> code, it should run on the IDT 323xx, and Toshiba TX49
>> processor families as well.
>>
>> It includes an integrated FPU emulator that handles
>> the full MIPS FP instruction set, and allows FPU-less
>> CPUs to run standard MIPS/Linux binaries.
>>
>> It contains a number of endianness fixes in the kernel
>> and driver code, and is very stable in both configurations.
>>
>> It contains platform support for the Algorithmics P-5064
>> and MIPS "Atlas" development boards, as well as the
>> SGI Indy.
>>
>> This code is NOT a supported product of MIPS
>> Technologies Inc.   It is being made available on an
>> "as is" basis subject to the ususal GPL.  It should be
>> accessible via anonymous (and blind) FTP for a while at
>> ftp://ftp.mips.com/incoming/linux.mips.src.01.01.tar.gz
>> and is archived on the Paralogos MIPS/Linux web site at
>> http://www.paralogos.com/mipslinux/.  We'd be very interested
>> in any feedback, experimental results, and enhancements
>> that any of you may wish to provide, and I will answer
>> email questions to the extent that my time allows.
>>
>>             Regards,
>>
>>             Kevin K.
>> __
>>
>> Kevin D. Kissell
>> MIPS Technologies European Architecture Lab
>> kevink@mips.com
>> Tel. +33.4.78.38.70.67
>> FAX. +33.4.78.38.70.68
>>
>

From kevink@mips.com  Thu Feb 10 15:35:29 2000
Received: from mx.mips.com (mx.mips.com [206.31.31.226]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id PAA19598; Thu, 10 Feb 2000 15:35:23 +0100 (MET)
Received-Date: Thu, 10 Feb 2000 15:35:23 +0100 (MET)
Received: from newman.mips.com (newman [206.31.31.8])
	by mx.mips.com (8.9.3/8.9.0) with ESMTP id GAA05450;
	Thu, 10 Feb 2000 06:35:16 -0800 (PST)
Received: from satanas (satanas [192.168.236.12])
	by newman.mips.com (8.9.3/8.9.0) with SMTP id GAA10905;
	Thu, 10 Feb 2000 06:35:14 -0800 (PST)
Message-ID: <00f001bf73d4$4b5f21d0$0ceca8c0@satanas.mips.com>
From: "Kevin D. Kissell" <kevink@mips.com>
To: "Gleb O. Raiko" <raiko@niisi.msk.ru>
Cc: <linux@cthulhu.engr.sgi.com>, <linux-mips@fnet.fr>
Subject: Re: Enhanced 2.2.12 MIPS Kernel Sources  Available
Date: Thu, 10 Feb 2000 15:36:55 +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 4.72.3110.5
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Content-Length: 887
Lines: 24

>It'll be great if you would put just patches too. I guess, it'll be easy
>for us to look through set of patches instead of downloading entire
>2.2.12 and making diff -ruN on it. Then, there might be a core patch
>that decribes changes in machine independent part of the kernel and the
>rest might cover specific boards. Most of developers here will be
>interested in the core patch, I guess.


OK, there is now a patch file available on the Paralogos site
(http://www.paralogos.com/mipslinux/) with the deltas relative
to the kernel.org 2.2.12 distribution.  It covers the whole kernel
tree - I don't think I can reasonably decompose the changes
without introducing a gratuitous opportunity to generate bugs.

            Happy hacking,

            Kevin K.
__

Kevin D. Kissell
MIPS Technologies European Architecture Lab
kevink@mips.com
Tel. +33.4.78.38.70.67
FAX. +33.4.78.38.70.68

From brad@ltc.com  Thu Feb 10 15:50:10 2000
Received: from ltc.com (ltc.ltc.com [38.149.17.171]) by guadalquivir.fnet.fr with SMTP (8.8.8/97.02.12/Guadalquivir); id PAA19727; Thu, 10 Feb 2000 15:50:07 +0100 (MET)
Received-Date: Thu, 10 Feb 2000 15:50:07 +0100 (MET)
Received: from d184.ltc.com (d184.ltc.com [38.149.17.184]) by ltc.com (NTMail 3.03.0017/1.afdd) with ESMTP id fa312057 for <linux-mips@fnet.fr>; Thu, 10 Feb 2000 09:51:47 -0500
Message-ID: <04af01bf73d6$14e3c410$b8119526@ltc.com>
From: "Bradley D. LaRonde" <brad@ltc.com>
To: "Kevin D. Kissell" <kevink@mips.com>, <linux@cthulhu.engr.sgi.com>,
        <linux-mips@fnet.fr>
References: <00d801bf73c9$32d3b820$0ceca8c0@satanas.mips.com>
Subject: Re: FPU Emulator (Re: Enhanced 2.2.12 MIPS Kernel Sources  Available)
Date: Thu, 10 Feb 2000 09:49:49 -0500
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
Content-Length: 4711
Lines: 116

Thank you.  I will forward this information to the Linux VR group.  Maybe
someone will volunteer.  Or maybe someone on this list?  :-)

Regards,
Brad

----- Original Message -----
From: "Kevin D. Kissell" <kevink@mips.com>
To: "Bradley D. LaRonde" <brad@ltc.com>; <linux@cthulhu.engr.sgi.com>;
<linux-mips@fnet.fr>
Sent: Thursday, February 10, 2000 8:06 AM
Subject: FPU Emulator (Re: Enhanced 2.2.12 MIPS Kernel Sources Available)


> Hey, one reason I wanted to get the code out there
> ASAP was to allow someone to do just that!
>
> The bulk of the emulator lives in its own directory,
> arch/mips/fpu_emulator, and the arch/mips/kernel/traps.c
> hook is very simple.  There are, however, hooks that
> need to be put into context switch, kgdb, and signal support
> code here and there, and these key off some enhancements
> we made to the CPU configuration code (e.g., there is
> a mips_cpu data structure with an options field that
> indicates the presence or absence of an FPU at
> runtime).   In theory, the emulator is capable of executing
> kernel FPU instructions and register register references
> as well as those from user mode, but it's considerably
> more efficient if the kernel knows to reference the simulator
> state instead.  The work to merge all this into the SGI 2.3.xx
> tree should not be too daunting, but it's not something that
> MIPS is likely to take on internally any time soon.
>
>             Regards,
>
>             Kevin K.
>
> -----Original Message-----
> From: Bradley D. LaRonde <brad@ltc.com>
> To: Kevin D. Kissell <kevink@mips.com>; linux@cthulhu.engr.sgi.com
> <linux@cthulhu.engr.sgi.com>; linux-mips@fnet.fr <linux-mips@fnet.fr>
> Date: Thursday, February 10, 2000 11:06 AM
> Subject: Re: Enhanced 2.2.12 MIPS Kernel Sources Available
>
>
> >RFC: What about geting the same FPU emulation into SGI's tree?
> >
> >Regards,
> >Brad
> >
> >----- Original Message -----
> >From: "Kevin D. Kissell" <kevink@mips.com>
> >To: <linux@cthulhu.engr.sgi.com>; <linux-mips@fnet.fr>
> >Sent: Wednesday, February 09, 2000 5:27 PM
> >Subject: Enhanced 2.2.12 MIPS Kernel Sources Available
> >
> >
> >> As many of you will have inferred, MIPS Technologies Inc
> >> has been working on the MIPS/Linux kernel for the past
> >> six months or so, driven by the need for a flexible software
> >> platform for valdiation and characterisation of new MIPS
> >> processor designs.  Relatively early on, we made the difficult
> >> decision not to try to track the SGI Linux repository: It was
> >> too unstable, and the SGI activity is driven by a very
> >> different set of goals.  We therefore took the 2.2.12
> >> kernel sources from kernel.org, and worked from there.
> >> I've shared some of our bug findings and fixes with
> >> the SGI mailing list, and still more of them with Ralf
> >> directly, but a lot of other changes and improvements
> >> have been made that will certainly be of interest to readers
> >> of this list, particularly those targeting non-SGI platforms.
> >>
> >> This kernel supports the new generation of 32-bit MIPS
> >> CPUs with R4K exception models.  This involved fairly
> >> extensive changes to semaphore support and to TLB
> >> and cache management routines.  We know it works on
> >> the MIPS 4Kc, and with appropriate additions to the
> >> table of recognized CPUs in the (revised) CPU probe
> >> code, it should run on the IDT 323xx, and Toshiba TX49
> >> processor families as well.
> >>
> >> It includes an integrated FPU emulator that handles
> >> the full MIPS FP instruction set, and allows FPU-less
> >> CPUs to run standard MIPS/Linux binaries.
> >>
> >> It contains a number of endianness fixes in the kernel
> >> and driver code, and is very stable in both configurations.
> >>
> >> It contains platform support for the Algorithmics P-5064
> >> and MIPS "Atlas" development boards, as well as the
> >> SGI Indy.
> >>
> >> This code is NOT a supported product of MIPS
> >> Technologies Inc.   It is being made available on an
> >> "as is" basis subject to the ususal GPL.  It should be
> >> accessible via anonymous (and blind) FTP for a while at
> >> ftp://ftp.mips.com/incoming/linux.mips.src.01.01.tar.gz
> >> and is archived on the Paralogos MIPS/Linux web site at
> >> http://www.paralogos.com/mipslinux/.  We'd be very interested
> >> in any feedback, experimental results, and enhancements
> >> that any of you may wish to provide, and I will answer
> >> email questions to the extent that my time allows.
> >>
> >>             Regards,
> >>
> >>             Kevin K.
> >> __
> >>
> >> Kevin D. Kissell
> >> MIPS Technologies European Architecture Lab
> >> kevink@mips.com
> >> Tel. +33.4.78.38.70.67
> >> FAX. +33.4.78.38.70.68
> >>
> >
>

From ralf@oss.sgi.com  Thu Feb 10 17:26:22 2000
Received: from mailhost.uni-koblenz.de (mailhost.uni-koblenz.de [141.26.64.1]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id RAA20363; Thu, 10 Feb 2000 17:26:20 +0100 (MET)
Received-Date: Thu, 10 Feb 2000 17:26:20 +0100 (MET)
Received: from cacc-9.uni-koblenz.de (cacc-9.uni-koblenz.de [141.26.131.9])
	by mailhost.uni-koblenz.de (8.9.3/8.9.3) with ESMTP id RAA29536;
	Thu, 10 Feb 2000 17:25:57 +0100 (MET)
Received: by lappi.waldorf-gmbh.de id <S407895AbQBJQPd>;
	Thu, 10 Feb 2000 17:15:33 +0100
Date: Thu, 10 Feb 2000 17:15:33 +0100
From: Ralf Baechle <ralf@oss.sgi.com>
To: Jeff Harrell <jharrell@ti.com>
Cc: sgi-mips <linux@cthulhu.engr.sgi.com>, linux-mips <linux-mips@fnet.fr>,
        linux-mips <linux-mips@vger.rutgers.edu>
Subject: Re: Question concerning memory initialization (4M->64M)
Message-ID: <20000210171533.A2933@uni-koblenz.de>
References: <38A1CFAE.EFA429BA@ti.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0pre3us
In-Reply-To: <38A1CFAE.EFA429BA@ti.com>
X-Accept-Language: de,en,fr
Content-Length: 1376
Lines: 32

On Wed, Feb 09, 2000 at 01:35:58PM -0700, Jeff Harrell wrote:

> I have run into an interesting problem and would like to run it past this
> newsgroup to see if anyone has any experience in these areas.  I am
> running kernel 2.3.22 and have upgraded my memory space from ~4M
> (0x400000) to ~64M (0x4000000).  I run the 4M version of the kernel and
> have no problems but when I run the 64M version, I run into problems
> during the mem_init() portion of the code.  Specifically during the
> free_page(tmp) call during the determination of totalram, codepages and
> datapages.  It looks like it is failing during the call to
> remove_mem_queue() within free_pages_ok().  I am seeing the next->prev and
> prev->next set to 0 causing a page fault.

The free pages are being stored in a circular list, so struct page of a free
page should never have prev or next set to zero.  Smells like memory
corruption.

> Is there anything that anyone is aware of that I would need to change
> (beyond mips_memory_upper) that would enable me to increase available
> memory to 64M.  Any insights would be greatly appreciated.

That alone should be sufficient.

> Additional information:
> ------------------
> 
> high memory: 0x83fff000  start memory: 0x80433000

I assume these are the values of start_mem and mem_end as passed to
mem_init()?  In that case these values look sane.

  Ralf

From Harald.Koerfgen@home.ivm.de  Thu Feb 10 19:01:50 2000
Received: from mail.ivm.net (mail.ivm.net [62.204.1.4]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id TAA21883; Thu, 10 Feb 2000 19:01:49 +0100 (MET)
Received-Date: Thu, 10 Feb 2000 19:01:49 +0100 (MET)
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 TAA03480;
	Thu, 10 Feb 2000 19:01:20 +0100
X-To: linux-mips@fnet.fr
Message-ID: <XFMail.000210190159.Harald.Koerfgen@home.ivm.de>
X-Mailer: XFMail 1.3 [p0] on Linux
X-Priority: 3 (Normal)
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
In-Reply-To: <38A213E5.BB2E9004@galileo.co.il>
Date: Thu, 10 Feb 2000 19:01:59 +0100 (MET)
Reply-To: "Harald Koerfgen" <Harald.Koerfgen@home.ivm.de>
Organization: none
Sender: harry@franz.no.dom
From: Harald Koerfgen <Harald.Koerfgen@home.ivm.de>
To: Rabeeh Khoury <rabeeh@galileo.co.il>
Subject: RE: error in compilation
Cc: "linux-mips@fnet.fr" <linux-mips@fnet.fr>
Content-Length: 668
Lines: 24


On 10-Feb-00 Rabeeh Khoury wrote:
> Hi all
> 
> In cross-compiling the r2300.c file in arch/mips/mm I get these error
> messages :
[snip]

> I'v just recently got the newest sources for the CVS tree on
> linus.linux.sgi.com
> 
> do you know whats going on ??!!

Well, I think so. The latest sync with 2.3.28 has wrong declarations in
pgalloc.h. They're perfectly valid for mips64 but not for mips32 any more.

Unfortunately this is not all what's not working for R3000s, the cache
management is broken as well. I have fixes here which work but while I am at it
I would like to reiterate the R3000 cache management, but that will take a few
days.

---
Regards,
Harald

From ralf@uni-koblenz.de  Fri Feb 11 23:29:59 2000
Received: from mailhost.uni-koblenz.de (mailhost.uni-koblenz.de [141.26.64.1]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id XAA06964; Fri, 11 Feb 2000 23:29:58 +0100 (MET)
Received-Date: Fri, 11 Feb 2000 23:29:58 +0100 (MET)
Received: from cacc-30.uni-koblenz.de (cacc-30.uni-koblenz.de [141.26.131.30])
	by mailhost.uni-koblenz.de (8.9.3/8.9.3) with ESMTP id XAA05170;
	Fri, 11 Feb 2000 23:29:55 +0100 (MET)
Received: by lappi.waldorf-gmbh.de id <S407893AbQBKW1x>;
	Fri, 11 Feb 2000 23:27:53 +0100
Date: Fri, 11 Feb 2000 23:27:53 +0100
From: Ralf Baechle <ralf@uni-koblenz.de>
To: Rabeeh Khoury <rabeeh@galileo.co.il>
Cc: "linux-mips@fnet.fr" <linux-mips@fnet.fr>
Subject: Re: error in memory
Message-ID: <20000211232753.B18013@uni-koblenz.de>
References: <38A49520.3062E702@galileo.co.il>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0pre3us
In-Reply-To: <38A49520.3062E702@galileo.co.il>
X-Accept-Language: de,en,fr
Content-Length: 1108
Lines: 32

On Fri, Feb 11, 2000 at 06:02:56PM -0500, Rabeeh Khoury wrote:

> I'm booting kernel version 2.3.38 on my embedded system and i'm getting
> this output :
> Loading R4000 MMU routines.
> CPU revision is: 000028a0
> Primary ins.truction cache esuize 32 bytes)
> mary data cache 32kb, linesize 32 bytes)
> Linux version 2.3.38 (rabeeh@bluelabel.galileo.co.il) (gcc version
> egcs-2.90.29 980515 (egcs-1.0.3 release)) #148 Fri Feb 11 17:46:53 EST
> 2000
> On node 0 totalpages: 00000000

> p.s. i'm using an old setup function that is called from setup_arch.
> this functions only tells the kernel the correct machine and
> mips_memmory_upper = 0x81000000
> should can i add any thing else here ?

mips_memory_upper doesn't exist anymore.  See how the initialization now
works for IP22 or IP27 as an example.

> how can I implement on the new kernel something like the old way of
> telling the kernel basic things such as memory size, TLB entries etc...
> ? (by old way I mean using the tag way)

Not necessarily a good idea.

> how can I tell the kernel not using neither swap nor paging ?

Not at all.

  Ralf

From rabeeh@galileo.co.il  Fri Feb 11 17:00:53 2000
Received: from galileo5.galileo.co.il ([192.116.246.130]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id RAA03877; Fri, 11 Feb 2000 17:00:50 +0100 (MET)
Received-Date: Fri, 11 Feb 2000 17:00:50 +0100 (MET)
Received: from galileo.co.il ([10.2.20.126])
	by galileo.co.il (8.8.5/8.8.5) with ESMTP id SAA24911
	for <linux-mips@fnet.fr>; Fri, 11 Feb 2000 18:01:24 +0200 (GMT-2)
Sender: rabeeh@galileo.co.il
Message-ID: <38A49520.3062E702@galileo.co.il>
Date: Fri, 11 Feb 2000 18:02:56 -0500
From: Rabeeh Khoury <rabeeh@galileo.co.il>
X-Mailer: Mozilla 4.51 [en] (X11; I; Linux 2.2.5-15 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: "linux-mips@fnet.fr" <linux-mips@fnet.fr>
Subject: error in memory
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Length: 2254
Lines: 68

Hi All

I'm booting kernel version 2.3.38 on my embedded system and i'm getting
this output :
Loading R4000 MMU routines.
CPU revision is: 000028a0
Primary ins.truction cache esuize 32 bytes)
mary data cache 32kb, linesize 32 bytes)
Linux version 2.3.38 (rabeeh@bluelabel.galileo.co.il) (gcc version
egcs-2.90.29 980515 (egcs-1.0.3 release)) #148 Fri Feb 11 17:46:53 EST
2000
On node 0 totalpages: 00000000
kernel BUG at bootmem.c:176!
kernel BUG at bootmem.c:179!
zone(0): 0 pages.
zone(1): 0 pages.
zone(2): 0 pages.
kmem_alloc: NULL ptr (name=unknown)
kmem_alloc: NULL ptr (name=unknown)
Calibrating delay loop...
52.33 BogoMIPS
kernel BUG at bootmem.c:229!
Unable to handle kernel paging request at virtual address 00000000, epc
== 80119708, ra == 80119708
Oops in fault.c:do_page_fault, line 146:
$0 : 00000000 10007c00 0000001d bd000024
$4 : 801270c4 801270cc 801270cc 0000003c
$8 : 00007c00 ffff00ff 0000000a 00000002
$12: 0000000a 00000000 8010de30 00000020
$16: bce85ffa b4000000 18bed735 a5cd9021
$20: eb022d55 0a398fe0 00000000 67dd85e0
$24: 00000001 00000010
$28: 80006000 80007f28 80138d80 80119708
epc   : 80119708
Status: 10007c03
Cause : 0080000c
Process swapper (pid: 0, stackpage=80006000)
Stack: 800f2f68 800f2ffc 000000e5 0000003c bce85ffa b4000000 18bed735
a5cd9021
       eb022d55 0a398fe0 f102dc3d 67dd85e0 54fb3697 80119a14 0000000f
00000010
       0000003c 800ebd22 80117994 b4000000 18bed735 a5cd9021 eb022d55
0a398fe0
       f102dc3d 67dd85e0 54fb3697 80116430 bce85ffa b4000000 18bed735
a5cd9021
       eb022d55 801167b0 800ebd18 801270cc 801270cc 0000003c 80126990
00000000
       bce85ffa ...
Call Trace: [<800f2f68>] [<800f2ffc>] [<800ebd22>] [<800ebd18>]
[<800005f8>]
Code: 24a52ffc  0c009e3f  240600e5 <aec00000> 3c108013  8e10856c
0000a021  8fc20000  8fc30004


p.s. i'm using an old setup function that is called from setup_arch.
this functions only tells the kernel the correct machine and
mips_memmory_upper = 0x81000000
should can i add any thing else here ?

how can I implement on the new kernel something like the old way of
telling the kernel basic things such as memory size, TLB entries etc...
? (by old way I mean using the tag way)

how can I tell the kernel not using neither swap nor paging ?


thank you


From ralf@oss.sgi.com  Sat Feb 12 01:17:12 2000
Received: from mailhost.uni-koblenz.de (mailhost.uni-koblenz.de [141.26.64.1]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id BAA08640; Sat, 12 Feb 2000 01:17:11 +0100 (MET)
Received-Date: Sat, 12 Feb 2000 01:17:11 +0100 (MET)
Received: from cacc-30.uni-koblenz.de (cacc-30.uni-koblenz.de [141.26.131.30])
	by mailhost.uni-koblenz.de (8.9.3/8.9.3) with ESMTP id BAA11938;
	Sat, 12 Feb 2000 01:17:07 +0100 (MET)
Received: by lappi.waldorf-gmbh.de id <S407894AbQBLAQ2>;
	Sat, 12 Feb 2000 01:16:28 +0100
Date: Sat, 12 Feb 2000 01:16:28 +0100
From: Ralf Baechle <ralf@oss.sgi.com>
To: linux@engr.sgi.com, linux-mips@fnet.fr, linux-mips@vger.rutgers.edu
Subject: 2.2 kernel fixes
Message-ID: <20000212011628.A19790@uni-koblenz.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0pre3us
X-Accept-Language: de,en,fr
Content-Length: 247
Lines: 6

I've fixed a number of bugs into the 2.2 branch.  At least one of them
seems to be significant, so I've put a new kernel binary for the Indy
as /pub/linux/mips/test/vmlinux-2.2.13-20000211.tar.bz2 and a new
source snapshot on oss.sgi.com.

  Ralf

From Hoyer@t-online.de  Sun Feb 13 09:52:58 2000
Received: from mailout05.sul.t-online.de (mailout05.sul.t-online.de [194.25.134.82]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id JAA20642; Sun, 13 Feb 2000 09:52:57 +0100 (MET)
Received-Date: Sun, 13 Feb 2000 09:52:57 +0100 (MET)
Received: from fwd00.sul.t-online.de 
	by mailout05.sul.t-online.de with smtp 
	id 12JulV-00078T-00; Sun, 13 Feb 2000 09:52:25 +0100
Received: from oclasen (320000535988-0001@[212.184.140.196]) by fwd00.sul.t-online.de
	with smtp id 12JulK-1d1p3oC; Sun, 13 Feb 2000 09:52:14 +0100
Message-ID: <001501bf75ff$c9b11840$c48cb8d4@oclasen.rhein-zeitung.de>
From: Hoyer@t-online.de (Peter Hoyer)
To: <linux-mips@fnet.fr>
Subject: MILO
Date: Sun, 13 Feb 2000 09:53:14 +0100
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0012_01BF7608.252411C0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3110.1
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
X-Sender: 320000535988-0001@t-dialin.net
Content-Length: 1852
Lines: 55

This is a multi-part message in MIME format.

------=_NextPart_000_0012_01BF7608.252411C0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Dear sir or madam,

I would like to install LINUX on my Siemens RM200 MIPS-PC. Therefore I =
tried to download MILO, but I could not get access to the download path  =
(ftp://ftp.fnet.fr/linux-mips/src/boot) on your server.

What I can I do in order to get MILO?

Sincerely Yours
Peter Hoyer

------=_NextPart_000_0012_01BF7608.252411C0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 HTML//EN">
<HTML>
<HEAD>

<META content=3Dtext/html;charset=3Diso-8859-1 =
http-equiv=3DContent-Type>
<META content=3D'"MSHTML 4.72.3110.7"' name=3DGENERATOR>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT color=3D#000000 face=3DArial size=3D2>Dear sir or =
madam,</FONT></DIV>
<DIV><FONT color=3D#000000 face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#000000 face=3DArial size=3D2>I would like to install =
LINUX on my=20
Siemens RM200 MIPS-PC. Therefore I tried to download MILO, but I could =
not get=20
access to the download path&nbsp; <A=20
href=3D"ftp://ftp.fnet.fr/linux-mips/src/boot">(</A><A=20
href=3D"ftp://ftp.fnet.fr/linux-mips/src/boot)">ftp://ftp.fnet.fr/linux-m=
ips/src/boot)</A>=20
on your server.</FONT></DIV>
<DIV><FONT color=3D#000000 face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#000000 face=3DArial size=3D2>What I can I do in =
order to get=20
MILO?</FONT></DIV>
<DIV><FONT color=3D#000000 face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#000000 face=3DArial size=3D2>Sincerely =
Yours</FONT></DIV>
<DIV><FONT color=3D#000000 face=3DArial size=3D2>Peter=20
Hoyer</FONT></DIV></BODY></HTML>

------=_NextPart_000_0012_01BF7608.252411C0--

From R.vandenBerg@inter.NL.net  Sun Feb 13 12:23:21 2000
Received: from altrade.nijmegen.inter.nl.net (altrade.nijmegen.inter.nl.net [193.67.237.6]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id MAA21293; Sun, 13 Feb 2000 12:23:20 +0100 (MET)
Received-Date: Sun, 13 Feb 2000 12:23:20 +0100 (MET)
Received: from whale.dutch.mountain by altrade.nijmegen.inter.nl.net
	via hn51-49.Hoorn.NL.net [193.79.46.213] with ESMTP
	id MAA01204 (8.8.8/3.41); Sun, 13 Feb 2000 12:23:19 +0100 (MET)
Received: from whale(really [127.0.0.1]) by whale.dutch.mountain
	via in.smtpd with smtp
	id <m12Jx4d-00024dC@whale.dutch.mountain>
	for <linux-mips@fnet.fr>; Sun, 13 Feb 2000 12:20:19 +0100 (MET)
	(Smail-3.2 1996-Jul-4 #2 built 1996-Nov-26)
Sender: R.vandenBerg@inter.NL.net
Message-ID: <38A69372.642CF3C9@inter.NL.net>
Date: Sun, 13 Feb 2000 12:20:18 +0100
From: Richard van den Berg <R.vandenBerg@inter.NL.net>
X-Mailer: Mozilla 3.01 (X11; I; Linux 2.0.29 i486)
MIME-Version: 1.0
To: Peter Hoyer <Hoyer@t-online.de>
CC: linux-mips@fnet.fr
Subject: Re: MILO
References: <001501bf75ff$c9b11840$c48cb8d4@oclasen.rhein-zeitung.de>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Length: 396
Lines: 14

Peter Hoyer wrote:

> I would like to install LINUX on my Siemens RM200 MIPS-PC. Therefore I
> tried to download MILO, but I could not get access to the download
> path  (ftp://ftp.fnet.fr/linux-mips/src/boot) on your server.
> 
> What I can I do in order to get MILO?

Go to a more up to date HOWTO at
http://www.linux.sgi.com/mips/mips-howto.html which has points to
sources.

Regards,
Richard

From Geert.Uytterhoeven@sonycom.com  Mon Feb 14 10:03:06 2000
Received: from mail.sonytel.be (mail.sonytel.be [193.74.243.200]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id KAA01985; Mon, 14 Feb 2000 10:03:02 +0100 (MET)
Received-Date: Mon, 14 Feb 2000 10:03:02 +0100 (MET)
Received: from dandelion.sonytel.be (dandelion.sonytel.be [193.74.243.153])
	by mail.sonytel.be (8.9.0/8.8.6) with ESMTP id KAA20776;
	Mon, 14 Feb 2000 10:01:44 +0100 (MET)
Date: Mon, 14 Feb 2000 10:01:44 +0100 (MET)
From: Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com>
Sender: geert@sonycom.com
To: Ralf Baechle <ralf@oss.sgi.com>
cc: linux@cthulhu.engr.sgi.com, linux-mips@fnet.fr,
        linux-mips@vger.rutgers.edu
Subject: Re: Indy crashes
In-Reply-To: <20000203021018.A25786@uni-koblenz.de>
Message-ID: <Pine.GSO.4.10.10002141000350.831-100000@dandelion.sonytel.be>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Content-Length: 724
Lines: 19

On Thu, 3 Feb 2000, Ralf Baechle wrote:
> Today I exchanged the R5000 CPU module in my Indy against a R4600 module
> and found that on R4600SC the kernel runs reliable while it crashs pretty
> soon after booting on a R5000SC module.  This is consistent with the
> reports that I've looked at.

That could explain the crashes I see on the DDB Vrc-5074 as well, which has a
NEC VR5000.

I'll try to fix the bootmem stuff ASAP and upgrade to 2.3.38.

Gr{oetje,eeting}s,

						Geert

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

From ralf@oss.sgi.com  Tue Feb 15 00:12:52 2000
Received: from mailhost.uni-koblenz.de (mailhost.uni-koblenz.de [141.26.64.1]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id AAA10626; Tue, 15 Feb 2000 00:12:51 +0100 (MET)
Received-Date: Tue, 15 Feb 2000 00:12:51 +0100 (MET)
Received: from cacc-16.uni-koblenz.de (cacc-16.uni-koblenz.de [141.26.131.16])
	by mailhost.uni-koblenz.de (8.9.3/8.9.3) with ESMTP id AAA23489;
	Tue, 15 Feb 2000 00:12:43 +0100 (MET)
Received: by lappi.waldorf-gmbh.de id <S407895AbQBNRNq>;
	Mon, 14 Feb 2000 18:13:46 +0100
Date: Mon, 14 Feb 2000 18:13:46 +0100
From: Ralf Baechle <ralf@oss.sgi.com>
To: Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com>
Cc: Ralf Baechle <ralf@oss.sgi.com>, linux@cthulhu.engr.sgi.com,
        linux-mips@fnet.fr, linux-mips@vger.rutgers.edu
Subject: Re: Indy crashes
Message-ID: <20000214181346.I30488@uni-koblenz.de>
References: <20000203021018.A25786@uni-koblenz.de> <Pine.GSO.4.10.10002141000350.831-100000@dandelion.sonytel.be>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0pre3us
In-Reply-To: <Pine.GSO.4.10.10002141000350.831-100000@dandelion.sonytel.be>
X-Accept-Language: de,en,fr
Content-Length: 608
Lines: 16

On Mon, Feb 14, 2000 at 10:01:44AM +0100, Geert Uytterhoeven wrote:

> On Thu, 3 Feb 2000, Ralf Baechle wrote:
> > Today I exchanged the R5000 CPU module in my Indy against a R4600 module
> > and found that on R4600SC the kernel runs reliable while it crashs pretty
> > soon after booting on a R5000SC module.  This is consistent with the
> > reports that I've looked at.
> 
> That could explain the crashes I see on the DDB Vrc-5074 as well, which has a
> NEC VR5000.
> 
> I'll try to fix the bootmem stuff ASAP and upgrade to 2.3.38.

I made a silly mistake during my tests and will have to retry.

  Ralf

From kevink@mips.com  Mon Feb 14 22:13:30 2000
Received: from mx.mips.com (mx.mips.com [206.31.31.226]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id WAA09402; Mon, 14 Feb 2000 22:13:29 +0100 (MET)
Received-Date: Mon, 14 Feb 2000 22:13:29 +0100 (MET)
Received: from newman.mips.com (newman [206.31.31.8])
	by mx.mips.com (8.9.3/8.9.0) with ESMTP id NAA19215;
	Mon, 14 Feb 2000 13:13:13 -0800 (PST)
Received: from satanas (satanas [192.168.236.12])
	by newman.mips.com (8.9.3/8.9.0) with SMTP id NAA23690;
	Mon, 14 Feb 2000 13:13:09 -0800 (PST)
Message-ID: <022301bf7730$92b87180$0ceca8c0@satanas.mips.com>
From: "Kevin D. Kissell" <kevink@mips.com>
To: <geert@linux-m68k.org>, "Ralf Baechle" <ralf@oss.sgi.com>
Cc: <linux@cthulhu.engr.sgi.com>, <linux-mips@fnet.fr>,
        <linux-mips@vger.rutgers.edu>
Subject: Re: Indy crashes
Date: Mon, 14 Feb 2000 22:15:02 +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 4.72.3110.5
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Content-Length: 1762
Lines: 44

>On Thu, 3 Feb 2000, Ralf Baechle wrote:
>> Today I exchanged the R5000 CPU module in my Indy against a R4600 module
>> and found that on R4600SC the kernel runs reliable while it crashs pretty
>> soon after booting on a R5000SC module.  This is consistent with the
>> reports that I've looked at.
>
>That could explain the crashes I see on the DDB Vrc-5074 as well, which has a
>NEC VR5000.
>
>I'll try to fix the bootmem stuff ASAP and upgrade to 2.3.38.


The problem may be in the assumption made even in the
most recent 2.3.x code that a hit-writeback-invalidate cache
operation on the secondary cache automagically affects the
primary.  That's the way it is on the R4000/4400, but that's
not the way the R5000 is specified.  So rather than set
dma_cache_wback_inv to r4k_dma_cache_wback_inv_sc
or r4k_dma_cache_wback_inv_pc, depending on the
presence or absence of a primary cache,  in the MIPS 
Technologies I bound it to a function:

static void
r4k_dma_cache_wback_inv(unsigned long addr, unsigned long size)
{
        r4k_dma_cache_wback_inv_pc(addr, size);
        if(sc_present) r4k_dma_cache_wback_inv_sc(addr, size);
}

However, I have not had the opportunity to test this code on
an R5000SC platform.   Looking at the R5000 spec, it is a
little ambiguous.  The special case of sc HWIs affecting
the primary isn't there, but then again sc HWIs aren't even
called out in the table of defined cache operations.  Indeed,
one *could* interpret the spec to mean that HWI on the 
*primary* flushes the secondary, the reverse of the R4000,
but it's by no means clear.   Thus I suggest hitting 'em both.

Does anybody on this list have an R527x manual?   How
is HWI of the primary/seconday caches defined there?

            Regards,

            Kevin K.

From wje@liveoak.engr.sgi.com  Mon Feb 14 22:57:39 2000
Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id WAA09666; Mon, 14 Feb 2000 22:57:38 +0100 (MET)
Received-Date: Mon, 14 Feb 2000 22:57:38 +0100 (MET)
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id NAA09088; Mon, 14 Feb 2000 13:53:03 -0800 (PST)
	mail_from (wje@liveoak.engr.sgi.com)
Received: from liveoak.engr.sgi.com (liveoak.engr.sgi.com [163.154.5.24])
	by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id NAA11954;
	Mon, 14 Feb 2000 13:57:29 -0800 (PST)
	mail_from (wje@liveoak.engr.sgi.com)
Received: (from wje@localhost)
	by liveoak.engr.sgi.com (8.9.3/8.8.7) id NAA26704;
	Mon, 14 Feb 2000 13:57:23 -0800
X-Authentication-Warning: liveoak.engr.sgi.com: wje set sender to wje@liveoak.engr.sgi.com using -f
From: "William J. Earl" <wje@cthulhu.engr.sgi.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <14504.31299.82555.477086@liveoak.engr.sgi.com>
Date: Mon, 14 Feb 2000 13:57:23 -0800 (PST)
To: "Kevin D. Kissell" <kevink@mips.com>
Cc: <geert@linux-m68k.org>, "Ralf Baechle" <ralf@oss.sgi.com>,
        <linux@cthulhu.engr.sgi.com>, <linux-mips@fnet.fr>,
        <linux-mips@vger.rutgers.edu>
Subject: Re: Indy crashes
In-Reply-To: <022301bf7730$92b87180$0ceca8c0@satanas.mips.com>
References: <022301bf7730$92b87180$0ceca8c0@satanas.mips.com>
X-Mailer: VM 6.74 under Emacs 20.3.1
Content-Length: 1289
Lines: 27

Kevin D. Kissell writes:
...
 > However, I have not had the opportunity to test this code on
 > an R5000SC platform.   Looking at the R5000 spec, it is a
 > little ambiguous.  The special case of sc HWIs affecting
 > the primary isn't there, but then again sc HWIs aren't even
 > called out in the table of defined cache operations.  Indeed,
 > one *could* interpret the spec to mean that HWI on the 
 > *primary* flushes the secondary, the reverse of the R4000,
 > but it's by no means clear.   Thus I suggest hitting 'em both.
 > 
 > Does anybody on this list have an R527x manual?   How
 > is HWI of the primary/seconday caches defined there?

      I am very familiar with how the R5000 and similar processors
works.  The secondary cache is essentially independent of the primary
caches, and is write-through.  It hangs on the SysAD bus and captures
cache lines being read, and returns a captured cache line on a later
read.

     You must separately invalidate the primary and secondary caches.
If you care about instruction cache coherency (as when reading in executable
pages), you have to invalidate the primary instruction cache, not just
the primary data cache.

     Since the secondary cache is write-through, you need only invalidate
it on reads; you can ignore it on writes.

From dom@algor.co.uk  Tue Feb 15 00:45:39 2000
Received: from kenton.algor.co.uk (root@kenton.algor.co.uk [193.117.190.25]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id AAA11757; Tue, 15 Feb 2000 00:45:38 +0100 (MET)
Received-Date: Tue, 15 Feb 2000 00:45:38 +0100 (MET)
Received: from gladsmuir.algor.co.uk (dom@gladsmuir.algor.co.uk [193.117.190.129])
	by kenton.algor.co.uk (8.8.8/8.8.8) with ESMTP id XAA05734;
	Mon, 14 Feb 2000 23:45:04 GMT
Received: (from dom@localhost)
	by gladsmuir.algor.co.uk (8.8.5/8.8.5) id XAA00626;
	Mon, 14 Feb 2000 23:45:06 GMT
Date: Mon, 14 Feb 2000 23:45:06 GMT
Message-Id: <200002142345.XAA00626@gladsmuir.algor.co.uk>
From: Dominic Sweetman <dom@algor.co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
To: "William J. Earl" <wje@cthulhu.engr.sgi.com>
Cc: "Kevin D. Kissell" <kevink@mips.com>, <geert@linux-m68k.org>,
        "Ralf Baechle" <ralf@oss.sgi.com>, <linux@cthulhu.engr.sgi.com>,
        <linux-mips@fnet.fr>, <linux-mips@vger.rutgers.edu>
Subject: Re: Indy crashes
In-Reply-To: <14504.31299.82555.477086@liveoak.engr.sgi.com>
References: <022301bf7730$92b87180$0ceca8c0@satanas.mips.com>
	<14504.31299.82555.477086@liveoak.engr.sgi.com>
X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid
Content-Length: 2626
Lines: 57


William J. Earl (wje@cthulhu.engr.sgi.com) ....

is of course right.

> The secondary cache is essentially independent of the primary
> caches, and is write-through.

The R5000 and QED RM527x share this kind of secondary cache.  It's
becoming obsolete - partly because it's not very efficient, and
partly because it depends on some special tag RAMs which nobody makes
any more.  [But it does work quite well in internet routers where a
big secondary can hold large chunks of routing table...]

QED's RM7000 has an internal secondary cache which is more like (but
not compatible with) an R4000.  As part of our Linux familiarisation
we'll try to get that working.  It's 4-way set associative, 256Kbytes
big, unified and write-back; so that should shake out some more bugs.

MIPS started off with the (fairly sound) argument that software should
manage the caches because software-invisible snoopy caches (x86-style)
cost a lot of hardware complication but don't buy any performance.
The argument is based on the observation (correct, then as now) that
the cache is so busy that snooping invariably makes the CPU wait.

I used to be an advocate of the MIPS position; but what this argument
ignores is the difficulty of maintaining a portable software base,
particulary an OS which (like Linux) has grown up with invisible x86
caches.

To make sure that Linux/MIPS kernels are and remain robust we have to
convince lots of people to take the trouble to learn about visible
caches - even though the systems they're working on don't have them.
And we have to hope that driver writers will do the right thing, even
though they've never used a system which needs cache management code
and have none at hand to test their drivers with...

This would be unlikely even if we all agreed what the word 'flush'
meant (does it mean "invalidate"?  or "write-back"?  or perhaps "both,
if necessary"? and can you build a robust OS without knowing the
answer?)

It *could* happen.  MIPS are not the only family of CPUs with visible
caches - though I think they probably have by far the most complicated
ones, because of their high-end history.

The meeting of Linux and MIPS is in this respect really good for Linux
- great at finding portability problems.  But it's not particularly
good for MIPS.  For now, Linux/MIPS kernels will only be reliable if
maintained by people who understand this stuff, keep a safe distance
from the x86 mainstream, and use only sanity-checked drivers.

Kevin, I think you'd better tell your colleagues who design the chips
that they'd better put some snooping in, and soon...

Dominic Sweetman
Algorithmics Ltd

From ralf@oss.sgi.com  Tue Feb 15 01:17:20 2000
Received: from mailhost.uni-koblenz.de (mailhost.uni-koblenz.de [141.26.64.1]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id BAA11957; Tue, 15 Feb 2000 01:17:19 +0100 (MET)
Received-Date: Tue, 15 Feb 2000 01:17:19 +0100 (MET)
Received: from cacc-16.uni-koblenz.de (cacc-16.uni-koblenz.de [141.26.131.16])
	by mailhost.uni-koblenz.de (8.9.3/8.9.3) with ESMTP id BAA29181;
	Tue, 15 Feb 2000 01:17:10 +0100 (MET)
Received: by lappi.waldorf-gmbh.de id <S407895AbQBOANq>;
	Tue, 15 Feb 2000 01:13:46 +0100
Date: Tue, 15 Feb 2000 01:13:46 +0100
From: Ralf Baechle <ralf@oss.sgi.com>
To: "Kevin D. Kissell" <kevink@mips.com>
Cc: geert@linux-m68k.org, Ralf Baechle <ralf@oss.sgi.com>,
        linux@cthulhu.engr.sgi.com, linux-mips@fnet.fr,
        linux-mips@vger.rutgers.edu
Subject: Re: Indy crashes
Message-ID: <20000215011346.D828@uni-koblenz.de>
References: <022301bf7730$92b87180$0ceca8c0@satanas.mips.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0pre3us
In-Reply-To: <022301bf7730$92b87180$0ceca8c0@satanas.mips.com>
X-Accept-Language: de,en,fr
Content-Length: 860
Lines: 21

On Mon, Feb 14, 2000 at 10:15:02PM +0100, Kevin D. Kissell wrote:

> The problem may be in the assumption made even in the
> most recent 2.3.x code that a hit-writeback-invalidate cache
> operation on the secondary cache automagically affects the
> primary.  That's the way it is on the R4000/4400, but that's

Yep.

> not the way the R5000 is specified.  So rather than set
> dma_cache_wback_inv to r4k_dma_cache_wback_inv_sc
> or r4k_dma_cache_wback_inv_pc, depending on the
> presence or absence of a primary cache,  in the MIPS 
> Technologies I bound it to a function:

I don't even pretend that Linux is running on a R5000 with L2 except on
Indy R5000SC's.  These R5000 modules are different in that they don't use
the L2 support which is part of the processor but rather use the same
external cache implementation as the R4600SC CPU modules do.

  Ralf

From ralf@oss.sgi.com  Tue Feb 15 01:38:22 2000
Received: from mailhost.uni-koblenz.de (mailhost.uni-koblenz.de [141.26.64.1]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id BAA12148; Tue, 15 Feb 2000 01:38:22 +0100 (MET)
Received-Date: Tue, 15 Feb 2000 01:38:22 +0100 (MET)
Received: from cacc-16.uni-koblenz.de (cacc-16.uni-koblenz.de [141.26.131.16])
	by mailhost.uni-koblenz.de (8.9.3/8.9.3) with ESMTP id BAA00820;
	Tue, 15 Feb 2000 01:38:12 +0100 (MET)
Received: by lappi.waldorf-gmbh.de id <S407895AbQBOAhj>;
	Tue, 15 Feb 2000 01:37:39 +0100
Date: Tue, 15 Feb 2000 01:37:39 +0100
From: Ralf Baechle <ralf@oss.sgi.com>
To: Dominic Sweetman <dom@algor.co.uk>
Cc: "William J. Earl" <wje@cthulhu.engr.sgi.com>,
        "Kevin D. Kissell" <kevink@mips.com>, geert@linux-m68k.org,
        Ralf Baechle <ralf@oss.sgi.com>, linux@cthulhu.engr.sgi.com,
        linux-mips@fnet.fr, linux-mips@vger.rutgers.edu
Subject: Re: Indy crashes
Message-ID: <20000215013739.E828@uni-koblenz.de>
References: <022301bf7730$92b87180$0ceca8c0@satanas.mips.com> <14504.31299.82555.477086@liveoak.engr.sgi.com> <200002142345.XAA00626@gladsmuir.algor.co.uk>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0pre3us
In-Reply-To: <200002142345.XAA00626@gladsmuir.algor.co.uk>
X-Accept-Language: de,en,fr
Content-Length: 2895
Lines: 65

On Mon, Feb 14, 2000 at 11:45:06PM +0000, Dominic Sweetman wrote:

> QED's RM7000 has an internal secondary cache which is more like (but
> not compatible with) an R4000.  As part of our Linux familiarisation
> we'll try to get that working.  It's 4-way set associative, 256Kbytes
> big, unified and write-back; so that should shake out some more bugs.

[...]

> I used to be an advocate of the MIPS position; but what this argument
> ignores is the difficulty of maintaining a portable software base,
> particulary an OS which (like Linux) has grown up with invisible x86
> caches.
> 
> To make sure that Linux/MIPS kernels are and remain robust we have to
> convince lots of people to take the trouble to learn about visible
> caches - even though the systems they're working on don't have them.
> And we have to hope that driver writers will do the right thing, even
> though they've never used a system which needs cache management code
> and have none at hand to test their drivers with...
> 
> This would be unlikely even if we all agreed what the word 'flush'
> meant (does it mean "invalidate"?  or "write-back"?  or perhaps "both,
> if necessary"? and can you build a robust OS without knowing the
> answer?)

Yes.

> It *could* happen.  MIPS are not the only family of CPUs with visible
> caches - though I think they probably have by far the most complicated
> ones, because of their high-end history.

Sparc.

> The meeting of Linux and MIPS is in this respect really good for Linux
> - great at finding portability problems.  But it's not particularly
> good for MIPS.  For now, Linux/MIPS kernels will only be reliable if
> maintained by people who understand this stuff, keep a safe distance
> from the x86 mainstream, and use only sanity-checked drivers.

No longer.  With Linux 2.3.41 Linux received a number of new software
interfaces which also could easily be backported to previous kernels.
As the side effect you even get scatter gather capabilities for every
driver.

Btw, please take a look at the new interfaces, they're documented in
Documentation/DMA-mapping.txt.  They're not yet cast into stone, so if
anybody has something to complain about these interfaces, better do it
soon.

> Kevin, I think you'd better tell your colleagues who design the chips
> that they'd better put some snooping in, and soon...

For I/O isn't not that bad to handle except a few cases like the
NCR 53c8xx driver.  And there is always the silver bullet solution of
using uncached accesses.

Things like mmap() and read/write right in the presence of virtual indexed
caches are the real vomit bag.  Linus & Co. so far refuse to accept any of
the optimal solutions.  And while I'd of course would like to such a
solution to get into the kernel I can well understand Linus' refusal.
>From that point of view the RM7000 is the first MIPS CPU that got caches
right since the R6000 ...

  Ralf

From Geert.Uytterhoeven@sonycom.com  Tue Feb 15 10:33:02 2000
Received: from mail.sonytel.be (mail.sonytel.be [193.74.243.200]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id KAA25381; Tue, 15 Feb 2000 10:32:57 +0100 (MET)
Received-Date: Tue, 15 Feb 2000 10:32:57 +0100 (MET)
Received: from dandelion.sonytel.be (dandelion.sonytel.be [193.74.243.153])
	by mail.sonytel.be (8.9.0/8.8.6) with ESMTP id KAA12980;
	Tue, 15 Feb 2000 10:30:52 +0100 (MET)
Date: Tue, 15 Feb 2000 10:30:52 +0100 (MET)
From: Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com>
Sender: geert@sonycom.com
To: "Kevin D. Kissell" <kevink@mips.com>
cc: Ralf Baechle <ralf@oss.sgi.com>, linux@cthulhu.engr.sgi.com,
        linux-mips@fnet.fr, linux-mips@vger.rutgers.edu
Subject: Re: Indy crashes
In-Reply-To: <022301bf7730$92b87180$0ceca8c0@satanas.mips.com>
Message-ID: <Pine.GSO.4.10.10002151030220.1123-100000@dandelion.sonytel.be>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Content-Length: 1120
Lines: 27

On Mon, 14 Feb 2000, Kevin D. Kissell wrote:
> >On Thu, 3 Feb 2000, Ralf Baechle wrote:
> >> Today I exchanged the R5000 CPU module in my Indy against a R4600 module
> >> and found that on R4600SC the kernel runs reliable while it crashs pretty
> >> soon after booting on a R5000SC module.  This is consistent with the
> >> reports that I've looked at.
> >
> >That could explain the crashes I see on the DDB Vrc-5074 as well, which has a
> >NEC VR5000.
> >
> >I'll try to fix the bootmem stuff ASAP and upgrade to 2.3.38.
> 
> The problem may be in the assumption made even in the
> most recent 2.3.x code that a hit-writeback-invalidate cache
> operation on the secondary cache automagically affects the
> primary.  That's the way it is on the R4000/4400, but that's

In that case it doesn't affect the NEC DDB Vrc-5074, since there's no L2.

Gr{oetje,eeting}s,

						Geert

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

From raiko@niisi.msk.ru  Tue Feb 15 13:59:04 2000
Received: from t111.niisi.ras.ru (root@t111.niisi.ras.ru [193.232.173.111]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id NAA26493; Tue, 15 Feb 2000 13:58:26 +0100 (MET)
Received-Date: Tue, 15 Feb 2000 13:58:26 +0100 (MET)
Received: from t06.niisi.ras.ru (t06.niisi.ras.ru [193.232.173.6])
	by t111.niisi.ras.ru (8.9.1/8.9.1) with ESMTP id PAA00565
	for <linux-mips@fnet.fr>; Tue, 15 Feb 2000 15:58:36 +0300
Received: (from uucp@localhost) by t06.niisi.ras.ru (8.7.6/8.7.3) with UUCP id QAA12471 for linux-mips@fnet.fr; Tue, 15 Feb 2000 16:06:56 +0300
Received: from niisi.msk.ru (t34 [193.232.173.34]) by niisi.msk.ru (8.8.8/8.8.8) with ESMTP id MAA13754 for <linux-mips@fnet.fr>; Tue, 15 Feb 2000 12:27:02 +0300 (MSK)
Message-ID: <38A91E19.CE7A9890@niisi.msk.ru>
Date: Tue, 15 Feb 2000 12:36:26 +0300
From: "Gleb O. Raiko" <raiko@niisi.msk.ru>
Organization: NIISI RAN
X-Mailer: Mozilla 4.7 [en] (WinNT; I)
X-Accept-Language: en,ru
MIME-Version: 1.0
To: linux-mips@fnet.fr
Subject: -fno-strict-aliasing problem in the latest 2.3
Content-Type: text/plain; charset=koi8-r
Content-Transfer-Encoding: 7bit
Content-Length: 992
Lines: 28

Hello,

There is a problem with the way main Makefile determines whether the
compiler suports -fno-strict-aliasing. Namely, Makefile blindly gets $CC
and tries to feed this option to it. Unfortunately, we set CC to proper
mips[el]-linux-gcc later in arch/mips/Makefile, so the main Makefile
just checks against native gcc. On RH6.1 with latest cross tool rpms
installed, I get cc1: Invalid option `-fno-strict-aliasing' during
comppilation, obviously.

I can't offer an elegenat solution to resolve this problem. Basically, I
see three choices: 

1. Move logic that sets CC from arch/mips/Makefile to the main Makefile
   (Nightmare for Ralf who have to either feed it to Linus or add this
logic in the main
   Makefile every merge, I think.)
2. Filter CFLAGS to remove -fno-strict-aliasing in arch/mips/Makefile
(Nasty.)
3. Fix the mips compiler :-)
   (Looks good for me despite the fact I don't understand exctly how
much work it costs,
   but can imagine...)

Any ideas ?

Regards,
Gleb.

From R.vandenBerg@inter.NL.net  Tue Feb 15 16:47:21 2000
Received: from altrade.nijmegen.inter.nl.net (altrade.nijmegen.inter.nl.net [193.67.237.6]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id QAA28797; Tue, 15 Feb 2000 16:47:15 +0100 (MET)
Received-Date: Tue, 15 Feb 2000 16:47:15 +0100 (MET)
Received: from whale.dutch.mountain by altrade.nijmegen.inter.nl.net
	via hn51-30.Hoorn.NL.net [193.79.46.194] with ESMTP for <linux-mips@fnet.fr>
	id QAA15964 (8.8.8/3.41); Tue, 15 Feb 2000 16:47:13 +0100 (MET)
Received: from localhost(really [127.0.0.1]) by whale.dutch.mountain
	via in.smtpd with smtp
	id <m12KkBB-00026DC@whale.dutch.mountain>
	for <linux-mips@fnet.fr>; Tue, 15 Feb 2000 16:46:21 +0100 (MET)
	(Smail-3.2 1996-Jul-4 #2 built 1996-Nov-26)
Date: Tue, 15 Feb 2000 16:46:20 +0100 (MET)
From: Richard van den Berg <R.vandenBerg@inter.NL.net>
X-Sender: ravdberg@whale.dutch.mountain
To: linux-mips@fnet.fr
Subject: 2.3.38 on DECstation (was Re: CVS Update@oss.sgi.com: linux)
In-Reply-To: <20000213205210Z305156-11638+65@oss.sgi.com>
Message-ID: <Pine.LNX.3.95.1000215163520.885B-100000@whale.dutch.mountain>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Content-Length: 784
Lines: 28

On Sun, 13 Feb 2000, Harald Koerfgen wrote:

> Log message:
> 	o bootmem fixes for DECstations
> 	o declarations in pgtable.h fixed
> 	o cache management for R3000 improved

[ravdberg@dolce ravdberg]$ uname -a
Linux dolce 2.3.38 #5 Mon Feb 14 19:13:31 CET 2000 mips unknown
[ravdberg@dolce ravdberg]$ cat /proc/cpuinfo
cpu                     : MIPS
cpu model               : R3000A V3.0
system type             : Digital Personal DECstation 5000/xx
BogoMIPS                : 24.84
byteorder               : little endian
unaligned accesses      : 0
wait instruction        : no
microsecond timers      : no
extra interrupt vector  : no
hardware watchpoint     : no
VCED exceptions         : not available
VCEI exceptions         : not available


Thank you Harald!

Regards,
Richard

From Harald.Koerfgen@home.ivm.de  Tue Feb 15 18:14:05 2000
Received: from mail.ivm.net (mail.ivm.net [62.204.1.4]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id SAA29336; Tue, 15 Feb 2000 18:14:05 +0100 (MET)
Received-Date: Tue, 15 Feb 2000 18:14:05 +0100 (MET)
Received: from franz.no.dom (port44.duesseldorf.ivm.de [195.247.65.44])
	by mail.ivm.net (8.8.8/8.8.8) with ESMTP id SAA26487;
	Tue, 15 Feb 2000 18:13:55 +0100
X-To: linux-mips@fnet.fr
Message-ID: <XFMail.000215181436.Harald.Koerfgen@home.ivm.de>
X-Mailer: XFMail 1.3 [p0] on Linux
X-Priority: 3 (Normal)
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
In-Reply-To: <Pine.LNX.3.95.1000215163520.885B-100000@whale.dutch.mountain>
Date: Tue, 15 Feb 2000 18:14:36 +0100 (MET)
Reply-To: "Harald Koerfgen" <Harald.Koerfgen@home.ivm.de>
Organization: none
Sender: harry@franz.no.dom
From: Harald Koerfgen <Harald.Koerfgen@home.ivm.de>
To: Richard van den Berg <R.vandenBerg@inter.NL.net>
Subject: RE: 2.3.38 on DECstation (was Re: CVS Update@oss.sgi.com: linux)
Cc: linux-mips@fnet.fr
Content-Length: 1213
Lines: 35


On 15-Feb-00 Richard van den Berg wrote:
> On Sun, 13 Feb 2000, Harald Koerfgen wrote:
> 
>> Log message:
>>      o bootmem fixes for DECstations
>>      o declarations in pgtable.h fixed
>>      o cache management for R3000 improved
> 
> [ravdberg@dolce ravdberg]$ uname -a
> Linux dolce 2.3.38 #5 Mon Feb 14 19:13:31 CET 2000 mips unknown
> [ravdberg@dolce ravdberg]$ cat /proc/cpuinfo
> cpu                     : MIPS
> cpu model               : R3000A V3.0
> system type             : Digital Personal DECstation 5000/xx
> BogoMIPS                : 24.84
> byteorder               : little endian
> unaligned accesses      : 0
> wait instruction        : no
> microsecond timers      : no
> extra interrupt vector  : no
> hardware watchpoint     : no
> VCED exceptions         : not available
> VCEI exceptions         : not available

Never mind, but, beware, swapping is broken for 2.3.38 with R3000.

While talking about the subject, I've put some assumptions into the
optimisation which seem to be valid for R3000As, but I am not exactly shure if
they are true for other R2000/R3000 variants. Thus, I'd like to have some
feedback from other boxes, for example DS2100/3100 or Bagets.

---
Regards,
Harald

From wje@liveoak.engr.sgi.com  Tue Feb 15 18:49:39 2000
Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id SAA00524; Tue, 15 Feb 2000 18:49:37 +0100 (MET)
Received-Date: Tue, 15 Feb 2000 18:49:37 +0100 (MET)
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id JAA04597; Tue, 15 Feb 2000 09:45:02 -0800 (PST)
	mail_from (wje@liveoak.engr.sgi.com)
Received: from liveoak.engr.sgi.com (liveoak.engr.sgi.com [163.154.5.24])
	by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id JAA36528;
	Tue, 15 Feb 2000 09:49:26 -0800 (PST)
	mail_from (wje@liveoak.engr.sgi.com)
Received: (from wje@localhost)
	by liveoak.engr.sgi.com (8.9.3/8.8.7) id JAA11519;
	Tue, 15 Feb 2000 09:49:19 -0800
X-Authentication-Warning: liveoak.engr.sgi.com: wje set sender to wje@liveoak.engr.sgi.com using -f
From: "William J. Earl" <wje@cthulhu.engr.sgi.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <14505.37279.164044.582169@liveoak.engr.sgi.com>
Date: Tue, 15 Feb 2000 09:49:19 -0800 (PST)
To: Ralf Baechle <ralf@oss.sgi.com>
Cc: "Kevin D. Kissell" <kevink@mips.com>, geert@linux-m68k.org,
        linux@cthulhu.engr.sgi.com, linux-mips@fnet.fr,
        linux-mips@vger.rutgers.edu
Subject: Re: Indy crashes
In-Reply-To: <20000215011346.D828@uni-koblenz.de>
References: <022301bf7730$92b87180$0ceca8c0@satanas.mips.com>
	<20000215011346.D828@uni-koblenz.de>
X-Mailer: VM 6.74 under Emacs 20.3.1
Content-Length: 810
Lines: 18

Ralf Baechle writes:
 > On Mon, Feb 14, 2000 at 10:15:02PM +0100, Kevin D. Kissell wrote:
...
 > > not the way the R5000 is specified.  So rather than set
 > > dma_cache_wback_inv to r4k_dma_cache_wback_inv_sc
 > > or r4k_dma_cache_wback_inv_pc, depending on the
 > > presence or absence of a primary cache,  in the MIPS 
 > > Technologies I bound it to a function:
 > 
 > I don't even pretend that Linux is running on a R5000 with L2 except on
 > Indy R5000SC's.  These R5000 modules are different in that they don't use
 > the L2 support which is part of the processor but rather use the same
 > external cache implementation as the R4600SC CPU modules do.
...

     If someone wants to do the real R5000SC (and RM5271 and RM7000)
cache routines, for some other platform, I can supply the required 
details.

From rabeeh@galileo.co.il  Tue Feb 15 16:17:15 2000
Received: from galileo5.galileo.co.il ([192.116.246.130]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id QAA28598; Tue, 15 Feb 2000 16:17:11 +0100 (MET)
Received-Date: Tue, 15 Feb 2000 16:17:11 +0100 (MET)
Received: from galileo.co.il ([10.2.20.126])
	by galileo.co.il (8.8.5/8.8.5) with ESMTP id RAA08312
	for <linux-mips@fnet.fr>; Tue, 15 Feb 2000 17:17:20 +0200 (GMT-2)
Sender: rabeeh@galileo.co.il
Message-ID: <38A9D0CB.FF958043@galileo.co.il>
Date: Tue, 15 Feb 2000 17:18:51 -0500
From: Rabeeh Khoury <rabeeh@galileo.co.il>
X-Mailer: Mozilla 4.51 [en] (X11; I; Linux 2.2.5-15 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: "linux-mips@fnet.fr" <linux-mips@fnet.fr>
Subject: boot memory
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Length: 820
Lines: 34

Hi All

I'm having trouble with my embedded system initializing the ram ; I do
the following for initializations in kernel_entry -

{
 mips_machgroup = MACH_GROUP_GALILEO;

 mips_memory_upper = 0x81000000; // not needed any more
 galileo_mem_init();
}

void __init galileo_mem_init(void)
{
  unsigned long bootmap_size;

 max_low_pfn = 0x1000; // 16 MB of ram - that's what I have on the
embedded
  bootmap_size = init_bootmem(0, max_low_pfn);
  free_bootmem (0 , 0x01000000);
  reserve_bootmem(0, 0x01000000);
}

but the kernel is stuck in the alloc_bootmem_node which is called from
free_area_init_core .

do you know what is the problem ?
am I doing right memory initializations for embedded board with 16 MByte
? ((start addr 0x80000000 - end addr 0x81000000)

p.s. I'm running in 32 bit MIPS - QED 5271

thank you


From kevink@mips.com  Tue Feb 15 23:22:07 2000
Received: from mx.mips.com (mx.mips.com [206.31.31.226]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id XAA14596; Tue, 15 Feb 2000 23:22:06 +0100 (MET)
Received-Date: Tue, 15 Feb 2000 23:22:06 +0100 (MET)
Received: from newman.mips.com (newman [206.31.31.8])
	by mx.mips.com (8.9.3/8.9.0) with ESMTP id OAA17249;
	Tue, 15 Feb 2000 14:21:55 -0800 (PST)
Received: from satanas (satanas [192.168.236.12])
	by newman.mips.com (8.9.3/8.9.0) with SMTP id OAA03662;
	Tue, 15 Feb 2000 14:21:53 -0800 (PST)
Message-ID: <006501bf7803$59855ad0$0ceca8c0@satanas.mips.com>
From: "Kevin D. Kissell" <kevink@mips.com>
To: "Geert Uytterhoeven" <Geert.Uytterhoeven@sonycom.com>
Cc: "Ralf Baechle" <ralf@oss.sgi.com>, <linux@cthulhu.engr.sgi.com>,
        <linux-mips@fnet.fr>, <linux-mips@vger.rutgers.edu>
Subject: Re: Indy crashes
Date: Tue, 15 Feb 2000 23:23:49 +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 4.72.3110.5
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Content-Length: 1710
Lines: 50

>> The problem may be in the assumption made even in the
>> most recent 2.3.x code that a hit-writeback-invalidate cache
>> operation on the secondary cache automagically affects the
>> primary.  That's the way it is on the R4000/4400, but that's
>
>In that case it doesn't affect the NEC DDB Vrc-5074, since there's no L2.


If it isn't the cache, and it tracks the CPU type, the next thing
I suspect is a pipe hazard.   The R5000 manual states that there
should be "at least two integer instructions between" any
instruction modifying the PageMask, EntryHi, or EntryLo[01]
registers and the subsequent tlbw[ir] or tlbp.  That's different
from the R4000.  In the current Linux arch/mips/head.S file, 
this interval does not seem to be respected by any of the TLB 
miss handlers.  Indeed, the default except_vec0_r4000 handler,
which I believe is what is used if an R5000 is detected, has 
the sequence

        mtc0    k1, CP0_ENTRYLO1                # load it
        b       1f
         tlbwr                                  # write random tlb entry
1:
        nop
        eret

wherin the purpose of the branch is obscure (I imagine
it fixed a bug seen somewhere on some CPU but it
makes me rather queasy)  but wherein in any case we 
do not seem to be assured 2 issues between the mtc0 
and the tlbwr.  It should be OK for an R4000, but not for 
an R5000.

So someone with the ability to reproduce the R5000
problem should really try sticking a nop between the
mtc0 and the branch (sigh) to see if that stabilizes 
the system.

            Regards,

            Kevin K.
__

Kevin D. Kissell
MIPS Technologies European Architecture Lab
kevink@mips.com
Tel. +33.4.78.38.70.67
FAX. +33.4.78.38.70.68

    

From ralf@oss.sgi.com  Wed Feb 16 01:16:12 2000
Received: from mailhost.uni-koblenz.de (mailhost.uni-koblenz.de [141.26.64.1]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id BAA16262; Wed, 16 Feb 2000 01:16:12 +0100 (MET)
Received-Date: Wed, 16 Feb 2000 01:16:12 +0100 (MET)
Received: from cacc-22.uni-koblenz.de (cacc-22.uni-koblenz.de [141.26.131.22])
	by mailhost.uni-koblenz.de (8.9.3/8.9.3) with ESMTP id BAA02764;
	Wed, 16 Feb 2000 01:15:59 +0100 (MET)
Received: by lappi.waldorf-gmbh.de id <S407895AbQBPANh>;
	Wed, 16 Feb 2000 01:13:37 +0100
Date: Wed, 16 Feb 2000 01:13:37 +0100
From: Ralf Baechle <ralf@oss.sgi.com>
To: "Kevin D. Kissell" <kevink@mips.com>
Cc: Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com>,
        linux@cthulhu.engr.sgi.com, linux-mips@fnet.fr,
        linux-mips@vger.rutgers.edu
Subject: Re: Indy crashes
Message-ID: <20000216011337.C4633@uni-koblenz.de>
References: <006501bf7803$59855ad0$0ceca8c0@satanas.mips.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0pre3us
In-Reply-To: <006501bf7803$59855ad0$0ceca8c0@satanas.mips.com>
X-Accept-Language: de,en,fr
Content-Length: 1932
Lines: 53

On Tue, Feb 15, 2000 at 11:23:49PM +0100, Kevin D. Kissell wrote:

> If it isn't the cache, and it tracks the CPU type, the next thing
> I suspect is a pipe hazard.   The R5000 manual states that there
> should be "at least two integer instructions between" any
> instruction modifying the PageMask, EntryHi, or EntryLo[01]
> registers and the subsequent tlbw[ir] or tlbp.  That's different
> from the R4000.  In the current Linux arch/mips/head.S file, 
> this interval does not seem to be respected by any of the TLB 
> miss handlers.  Indeed, the default except_vec0_r4000 handler,
> which I believe is what is used if an R5000 is detected, has 
> the sequence
> 
>         mtc0    k1, CP0_ENTRYLO1                # load it
>         b       1f
>          tlbwr                                  # write random tlb entry
> 1:
>         nop
>         eret
> 
> wherin the purpose of the branch is obscure (I imagine
> it fixed a bug seen somewhere on some CPU but it
> makes me rather queasy)  but wherein in any case we 
> do not seem to be assured 2 issues between the mtc0 
> and the tlbwr.  It should be OK for an R4000, but not for 
> an R5000.

No, it's not a bug workaround.  The reason for this branch is that the
R4000 and R4400 have a penalty of three cycles for a taken branch.  So
the branch above is equivalent with 

	mtc0	k1, CP0_ENTRYLO1
	nop
	tlbwr
	nop
	nop
	nop
	eret

Funky trick, isn't it?  I don't have the the R4600 / R5000 docs at hand
but as I understood them the above code should also work just perfect
for them.

> So someone with the ability to reproduce the R5000
> problem should really try sticking a nop between the
> mtc0 and the branch (sigh) to see if that stabilizes 
> the system.

Talking about CPU bugs - the R5230 and maybe it's relatives needs a nasty
workaround.  I think I only put the workaround into the Cobalt kernel.
Of course IDT doesn't admit that this bug even exists ...

  Ralf

From wje@liveoak.engr.sgi.com  Wed Feb 16 02:17:05 2000
Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id CAA16651; Wed, 16 Feb 2000 02:17:04 +0100 (MET)
Received-Date: Wed, 16 Feb 2000 02:17:04 +0100 (MET)
Received: from cthulhu.engr.sgi.com (gate3-relay.engr.sgi.com [130.62.1.234]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id RAA00515; Tue, 15 Feb 2000 17:19:47 -0800 (PST)
	mail_from (wje@liveoak.engr.sgi.com)
Received: from liveoak.engr.sgi.com (liveoak.engr.sgi.com [163.154.5.24])
	by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id RAA33395;
	Tue, 15 Feb 2000 17:16:52 -0800 (PST)
	mail_from (wje@liveoak.engr.sgi.com)
Received: (from wje@localhost)
	by liveoak.engr.sgi.com (8.9.3/8.8.7) id RAA09994;
	Tue, 15 Feb 2000 17:16:46 -0800
X-Authentication-Warning: liveoak.engr.sgi.com: wje set sender to wje@liveoak.engr.sgi.com using -f
From: "William J. Earl" <wje@cthulhu.engr.sgi.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <14505.64125.564813.333784@liveoak.engr.sgi.com>
Date: Tue, 15 Feb 2000 17:16:45 -0800 (PST)
To: Ralf Baechle <ralf@oss.sgi.com>
Cc: "Kevin D. Kissell" <kevink@mips.com>,
        Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com>,
        linux@cthulhu.engr.sgi.com, linux-mips@fnet.fr,
        linux-mips@vger.rutgers.edu
Subject: Re: Indy crashes
In-Reply-To: <20000216011337.C4633@uni-koblenz.de>
References: <006501bf7803$59855ad0$0ceca8c0@satanas.mips.com>
	<20000216011337.C4633@uni-koblenz.de>
X-Mailer: VM 6.74 under Emacs 20.3.1
Content-Length: 697
Lines: 17

Ralf Baechle writes:
 > On Tue, Feb 15, 2000 at 11:23:49PM +0100, Kevin D. Kissell wrote:
...
 > >         mtc0    k1, CP0_ENTRYLO1                # load it
 > >         b       1f
 > >          tlbwr                                  # write random tlb entry
 > > 1:
 > >         nop
 > >         eret
...
 > Funky trick, isn't it?  I don't have the the R4600 / R5000 docs at hand
 > but as I understood them the above code should also work just perfect
 > for them.

      There is a need for a workaround on the R5000 for a "bad $badvaddr" 
problem.  The except_vec0_r45k_bvahwbug() variation does not appear to be
enabled for the R5000.  (It should not be needed for the RM7000 or the RM5271.)

From ralf@oss.sgi.com  Wed Feb 16 02:24:13 2000
Received: from mailhost.uni-koblenz.de (mailhost.uni-koblenz.de [141.26.64.1]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id CAA16714; Wed, 16 Feb 2000 02:24:13 +0100 (MET)
Received-Date: Wed, 16 Feb 2000 02:24:13 +0100 (MET)
Received: from cacc-22.uni-koblenz.de (cacc-22.uni-koblenz.de [141.26.131.22])
	by mailhost.uni-koblenz.de (8.9.3/8.9.3) with ESMTP id CAA06438;
	Wed, 16 Feb 2000 02:24:04 +0100 (MET)
Received: by lappi.waldorf-gmbh.de id <S407895AbQBPBXe>;
	Wed, 16 Feb 2000 02:23:34 +0100
Date: Wed, 16 Feb 2000 02:23:34 +0100
From: Ralf Baechle <ralf@oss.sgi.com>
To: "William J. Earl" <wje@cthulhu.engr.sgi.com>
Cc: Ralf Baechle <ralf@oss.sgi.com>, "Kevin D. Kissell" <kevink@mips.com>,
        Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com>,
        linux@cthulhu.engr.sgi.com, linux-mips@fnet.fr,
        linux-mips@vger.rutgers.edu
Subject: Re: Indy crashes
Message-ID: <20000216022334.A1070@uni-koblenz.de>
References: <006501bf7803$59855ad0$0ceca8c0@satanas.mips.com> <20000216011337.C4633@uni-koblenz.de> <14505.64125.564813.333784@liveoak.engr.sgi.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0pre3us
In-Reply-To: <14505.64125.564813.333784@liveoak.engr.sgi.com>
X-Accept-Language: de,en,fr
Content-Length: 879
Lines: 23

On Tue, Feb 15, 2000 at 05:16:45PM -0800, William J. Earl wrote:

> Ralf Baechle writes:
>  > On Tue, Feb 15, 2000 at 11:23:49PM +0100, Kevin D. Kissell wrote:
> ...
>  > >         mtc0    k1, CP0_ENTRYLO1                # load it
>  > >         b       1f
>  > >          tlbwr                                  # write random tlb entry
>  > > 1:
>  > >         nop
>  > >         eret
> ...
>  > Funky trick, isn't it?  I don't have the the R4600 / R5000 docs at hand
>  > but as I understood them the above code should also work just perfect
>  > for them.
> 
>       There is a need for a workaround on the R5000 for a "bad $badvaddr" 
> problem.  The except_vec0_r45k_bvahwbug() variation does not appear to be
> enabled for the R5000.  (It should not be needed for the RM7000 or the RM5271.)

I don't have this bug in my erratas documented, can you elaborate on it?

  Ralf

From wje@liveoak.engr.sgi.com  Wed Feb 16 02:46:33 2000
Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id CAA16836; Wed, 16 Feb 2000 02:46:32 +0100 (MET)
Received-Date: Wed, 16 Feb 2000 02:46:32 +0100 (MET)
Received: from cthulhu.engr.sgi.com (gate3-relay.engr.sgi.com [130.62.1.234]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id RAA02385; Tue, 15 Feb 2000 17:49:21 -0800 (PST)
	mail_from (wje@liveoak.engr.sgi.com)
Received: from liveoak.engr.sgi.com (liveoak.engr.sgi.com [163.154.5.24])
	by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id RAA08518;
	Tue, 15 Feb 2000 17:46:26 -0800 (PST)
	mail_from (wje@liveoak.engr.sgi.com)
Received: (from wje@localhost)
	by liveoak.engr.sgi.com (8.9.3/8.8.7) id RAA11942;
	Tue, 15 Feb 2000 17:46:20 -0800
X-Authentication-Warning: liveoak.engr.sgi.com: wje set sender to wje@liveoak.engr.sgi.com using -f
From: "William J. Earl" <wje@cthulhu.engr.sgi.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <14506.350.713324.113307@liveoak.engr.sgi.com>
Date: Tue, 15 Feb 2000 17:46:06 -0800 (PST)
To: Ralf Baechle <ralf@oss.sgi.com>
Cc: "Kevin D. Kissell" <kevink@mips.com>,
        Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com>,
        linux@cthulhu.engr.sgi.com, linux-mips@fnet.fr,
        linux-mips@vger.rutgers.edu
Subject: Re: Indy crashes
In-Reply-To: <20000216022334.A1070@uni-koblenz.de>
References: <006501bf7803$59855ad0$0ceca8c0@satanas.mips.com>
	<20000216011337.C4633@uni-koblenz.de>
	<14505.64125.564813.333784@liveoak.engr.sgi.com>
	<20000216022334.A1070@uni-koblenz.de>
X-Mailer: VM 6.74 under Emacs 20.3.1
Content-Length: 2456
Lines: 50

Ralf Baechle writes:
 > On Tue, Feb 15, 2000 at 05:16:45PM -0800, William J. Earl wrote:
...
 > >       There is a need for a workaround on the R5000 for a "bad $badvaddr" 
 > > problem.  The except_vec0_r45k_bvahwbug() variation does not appear to be
 > > enabled for the R5000.  (It should not be needed for the RM7000 or the RM5271.)
 > 
 > I don't have this bug in my erratas documented, can you elaborate on it?

     Sometimes you get a utlbmiss exception when there is already matching
TLB entry.  If you then blindly drop in the TLB entry, you get a duplicate,
which leads to Bad Things (tm).  The workaround is to probe for a duplicate,
and skip the tlbwr if an entry already exists.  It should be enabled on any
real R5000.  

    This is from the R5000 Errata list of 30 October 1997:

----------------------------------------------------------------------
3.  An erroneous JTLB miss exception will be taken under
    these conditions. 

    a) An instruction which does not cause an exception or
       stall is 8 bytes away from the end of a page.
    b) A load or store instruction is the last instruction of that page.
    c) The load/store target address has a matching but invalid
       JTLB entry
    d) The next sequential page is not mapped in the JTLB

    In this situation, when the load/store instruction is executed,
    a JTLB invalid exception should be taken, instead a JTLB miss
    exception is incorrectly taken. If the exception handler
    does a random TLB write to resolve the exception, this will in 
    general insert a duplicate TLB entry for each erroneous exception.
    If the first instruction is a jump or branch, this will cause
    an infinite loop of JTLB miss exceptions to occur upon the return
    from the exception handler.  Otherwise, there will be only one
    erroneous exception, followed by a correct exception, leaving
    one duplicate entry in the TLB.

    A software fix is for the JTLB miss handler to detect this situation,
    by probing for a matching TLB entry (treating a hit as being this case),
    ignore the JTLB miss and treat the exception as an JTLB invalid exception.

    Errata 3 is fixed in Rev 2.0.
----------------------------------------------------------------------

      It is not clear to me that Errata 3 is fixed in all cases in Rev 2.*,
so IRIX has the workaround enabled for all R5000 revisions.

     In Linux, just use except_vec0_r45k_bvahwbug() for any R5000.

From agx@gandalf.physik.uni-konstanz.de  Wed Feb 16 10:07:34 2000
Received: from gandalf.physik.uni-konstanz.de (gandalf.physik.uni-konstanz.de [134.34.144.30]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id KAA21302; Wed, 16 Feb 2000 10:07:33 +0100 (MET)
Received-Date: Wed, 16 Feb 2000 10:07:33 +0100 (MET)
Received: from gimli.physik.uni-konstanz.de [134.34.144.35] 
	by gandalf.physik.uni-konstanz.de with esmtp (Exim 2.05 #1 (Debian))
	id 12L0Qm-0001eq-00; Wed, 16 Feb 2000 10:07:32 +0100
Received: from agx by gimli.physik.uni-konstanz.de with local (Exim 2.05 #1 (Debian))
	id 12L0Ql-0000Jw-00; Wed, 16 Feb 2000 10:07:31 +0100
Date: Wed, 16 Feb 2000 10:07:31 +0100
From: Guido Guenther <guido.guenther@uni-konstanz.de>
To: linux-mips@fnet.fr
Subject: Indy: reboot after HardHat installation fails
Message-ID: <20000216100731.A1220@gimli.physik.uni-konstanz.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
User-Agent: Mutt/1.0i
Sender: Guido Guenther <agx@gandalf.physik.uni-konstanz.de>
Content-Length: 754
Lines: 17

Hi,
after installing HardHat on an R4600 Indy I'm unable to boot with:
bootp()nfsserver:/vmlinux root=/dev/sdb1
I get a "unable to open console". The mailing list archives say
that I have to get the device numbers in /dev right. This seems
reasonable since the installation of the dev-rpm (along with many
others) died with a "unable to execute script". Unfortunately I can't
use "upgrade" in the hardhat installation programm to mount /dev/sdb1 (as
suggested in the mailing list archives) since it always dies with
"signal 11".  Any chance to mount /dev/sdb1 to fix the device numbers?
Regards,
-- Guido

-- 

PGP-Public Key: http://honk.physik.uni-konstanz.de/~guido/gunther.asc
GPG-Public Key: http://honk.physik.uni-konstanz.de/~agx/guenther.gpg.asc

From raiko@niisi.msk.ru  Wed Feb 16 10:32:38 2000
Received: from t111.niisi.ras.ru (root@t111.niisi.ras.ru [193.232.173.111]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id KAA21467; Wed, 16 Feb 2000 10:32:34 +0100 (MET)
Received-Date: Wed, 16 Feb 2000 10:32:34 +0100 (MET)
Received: from t06.niisi.ras.ru (t06.niisi.ras.ru [193.232.173.6])
	by t111.niisi.ras.ru (8.9.1/8.9.1) with ESMTP id MAA08481
	for <linux-mips@fnet.fr>; Wed, 16 Feb 2000 12:33:11 +0300
Received: (from uucp@localhost) by t06.niisi.ras.ru (8.7.6/8.7.3) with UUCP id MAA28577 for linux-mips@fnet.fr; Wed, 16 Feb 2000 12:37:17 +0300
Received: from niisi.msk.ru (t34 [193.232.173.34]) by niisi.msk.ru (8.8.8/8.8.8) with ESMTP id MAA10656 for <linux-mips@fnet.fr>; Wed, 16 Feb 2000 12:27:05 +0300 (MSK)
Message-ID: <38AA6F91.3DF9825C@niisi.msk.ru>
Date: Wed, 16 Feb 2000 12:36:17 +0300
From: "Gleb O. Raiko" <raiko@niisi.msk.ru>
Organization: NIISI RAN
X-Mailer: Mozilla 4.7 [en] (WinNT; I)
X-Accept-Language: en,ru
MIME-Version: 1.0
CC: "linux-mips@fnet.fr" <linux-mips@fnet.fr>
Subject: Re: boot memory
References: <38A9D0CB.FF958043@galileo.co.il>
Content-Type: text/plain; charset=koi8-r
Content-Transfer-Encoding: 7bit
Content-Length: 1020
Lines: 31

Rabeeh Khoury wrote:
> I'm having trouble with my embedded system initializing the ram ; I do
> the following for initializations in kernel_entry -
> 
> void __init galileo_mem_init(void)
> {
>   unsigned long bootmap_size;
> 
>  max_low_pfn = 0x1000; // 16 MB of ram - that's what I have on the
> embedded
>   bootmap_size = init_bootmem(0, max_low_pfn);
>   free_bootmem (0 , 0x01000000);
>   reserve_bootmem(0, 0x01000000);
> }
> 
> but the kernel is stuck in the alloc_bootmem_node which is called from
> free_area_init_core .
> 
> do you know what is the problem ?
> am I doing right memory initializations for embedded board with 16 MByte
> ? ((start addr 0x80000000 - end addr 0x81000000)
> 

Bootmem allocator needs __free__ memory. By specifing start pfn as 0 you
just poison exception handlers. Basically, you need to specify next pfn
__after__ the end of the kernel data as staring pfn, something like
UP(&end), look at i386 for example. The bootmem allocator stores its
bitmap at start pfn. 

Regards,
Gleb.

From kevink@mips.com  Wed Feb 16 11:40:43 2000
Received: from mx.mips.com (mx.mips.com [206.31.31.226]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id LAA21788; Wed, 16 Feb 2000 11:40:42 +0100 (MET)
Received-Date: Wed, 16 Feb 2000 11:40:42 +0100 (MET)
Received: from newman.mips.com (newman [206.31.31.8])
	by mx.mips.com (8.9.3/8.9.0) with ESMTP id CAA00085;
	Wed, 16 Feb 2000 02:40:38 -0800 (PST)
Received: from satanas (satanas [192.168.236.12])
	by newman.mips.com (8.9.3/8.9.0) with SMTP id CAA22938;
	Wed, 16 Feb 2000 02:40:31 -0800 (PST)
Message-ID: <003101bf786a$8c44d150$0ceca8c0@satanas.mips.com>
From: "Kevin D. Kissell" <kevink@mips.com>
To: "Ralf Baechle" <ralf@oss.sgi.com>
Cc: "Geert Uytterhoeven" <Geert.Uytterhoeven@sonycom.com>,
        <linux@cthulhu.engr.sgi.com>, <linux-mips@fnet.fr>,
        <linux-mips@vger.rutgers.edu>
Subject: Re: Indy crashes
Date: Wed, 16 Feb 2000 11:42:29 +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 4.72.3110.5
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Content-Length: 4123
Lines: 105

Ralf Baechle writes:
>On Tue, Feb 15, 2000 at 11:23:49PM +0100, Kevin D. Kissell wrote:
>>                                   The R5000 manual states that there
>> should be "at least two integer instructions between" any
>> instruction modifying the PageMask, EntryHi, or EntryLo[01]
>> registers and the subsequent tlbw[ir] or tlbp.  That's different
>> from the R4000.  In the current Linux arch/mips/head.S file, 
>> this interval does not seem to be respected by any of the TLB 
>> miss handlers.  Indeed, the default except_vec0_r4000 handler,
>> which I believe is what is used if an R5000 is detected, has 
>> the sequence
>> 
>>         mtc0    k1, CP0_ENTRYLO1                # load it
>>         b       1f
>>          tlbwr                                  # write random tlb entry
>> 1:
>>         nop
>>         eret
>> 
>> wherin the purpose of the branch is obscure (I imagine
>> it fixed a bug seen somewhere on some CPU but it
>> makes me rather queasy)  but wherein in any case we 
>> do not seem to be assured 2 issues between the mtc0 
>> and the tlbwr.  It should be OK for an R4000, but not for 
>> an R5000.
>
>No, it's not a bug workaround.  The reason for this branch is that the
>R4000 and R4400 have a penalty of three cycles for a taken branch.  So
>the branch above is equivalent with 
>
> mtc0 k1, CP0_ENTRYLO1
> nop
> tlbwr
> nop
> nop
> nop
> eret
>
>Funky trick, isn't it?  I don't have the the R4600 / R5000 docs at hand
>but as I understood them the above code should also work just perfect
>for them.

No.  Not as I read the specs.  There are three problems here.

First, the question is *not* one of no-ops between the TLBWR
and the ERET, but of no-ops between the MTC0 and the
TLBWR - re-read the quoted text above from my previous
message.  So the code may well be broken as I conjectured
even if your assumption about the branch delay was valid.

Second, the R5000 and R4600 piprlines are not as deep
as those of the R4000/4400.   The R5000 documentation
calls out a branch implementation with a *single* delay cycle.
I quote: "The one cycle branch delay is a result of the branch
comparison logic operating during the 1A pipeline stage of
the branch.  This allows the branch target address calculated
in the previous stage to be used for the instruction access in
the following 1I phase."   So even if the execution of the
branch were inserting delay between the MTC0 and the
TLBWR as you seemed to assume, it might not be inserting
as much delay as you think.

Thirdly, this whole thread underscores why "clever" solutions that 
depend on implementation features of particular CPUs should 
be avoided whenever possible. If you want to be assured of
getting a delay cycle in a MIPS instruction stream, you should
use a "SSNOP", (sll r0,r0,1 as opposed to the "nop" sll r0,r0,0),
which forces delays even in superscalar implementations.

>> So someone with the ability to reproduce the R5000
>> problem should really try sticking a nop between the
>> mtc0 and the branch (sigh) to see if that stabilizes 
>> the system.

I still think this would be a good idea.  Further, from Bill Earl's
comment on this same thread, it sounds like, to be conservative,
 trap_init() in arch/mips/kernel/traps.c needs to detect the R5000
case and patch in except_vec0_r45k_bvahwbug instead
of except_vec0_r4000, and that furthermore a nop (or ssnop) 
be added between the MTC0 and the branch of 
except_vec0_r45k_bvahwbug.

>Talking about CPU bugs - the R5230 and maybe it's relatives needs a nasty
>workaround.  I think I only put the workaround into the Cobalt kernel.
>Of course IDT doesn't admit that this bug even exists ...


Um, why should they, when IDT didn't do the R5230?  ;-)
Seriously, did you mean to refer to the R323xx from IDT,
or to QED as the design house for the R5230?  I have been 
running 2.2.12 on an R5260 for months and it has been very 
stable.   To which bug and which workaround are you referring?


            Regards,

            Kevin K.
__

Kevin D. Kissell
MIPS Technologies European Architecture Lab
kevink@mips.com
Tel. +33.4.78.38.70.67
FAX. +33.4.78.38.70.68


From flo@rfc822.org  Wed Feb 16 12:25:34 2000
Received: from noose.gt.owl.de (noose.gt.owl.de [62.52.19.4]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id MAA22033; Wed, 16 Feb 2000 12:25:33 +0100 (MET)
Received-Date: Wed, 16 Feb 2000 12:25:33 +0100 (MET)
Received: by noose.gt.owl.de (Postfix, from userid 10)
	id DA79A7F3; Wed, 16 Feb 2000 12:25:31 +0100 (CET)
Received: by paradigm.rfc822.org (Postfix, from userid 1000)
	id 8F8298FC4; Wed, 16 Feb 2000 12:22:50 +0100 (CET)
Date: Wed, 16 Feb 2000 12:22:50 +0100
From: Florian Lohoff <flo@rfc822.org>
To: linux-mips@vger.rutgers.edu, linux@cthulhu.engr.sgi.com,
        linux-mips@fnet.fr
Subject: oss.sgi.com CVS kernel doesn compile for DEC
Message-ID: <20000216122250.A898@paradigm.rfc822.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.95.3i
Organization: rfc822 - pure communication
Sender: flo@rfc822.org
Content-Length: 2501
Lines: 41


Just a small note - probably most of the people already stumbled on this.

ar  rcs lib.a  csum_partial.o csum_partial_copy.o floppy-std.o floppy-no.o ide-std.o ide-no.o kbd-std.o kbd-no.o rtc-std.o rtc-no.o memcpy.o memset.o strlen_user.o strncpy_user.o strnlen_user.o watch.o dump_tlb.o 
make[2]: Leaving directory `/data/kernel/linux/arch/mips/lib'
make[1]: Leaving directory `/data/kernel/linux/arch/mips/lib'
ld -static -G 0 -T arch/mips/ld.script.little -Ttext 0x80040000 arch/mips/kernel/head.o arch/mips/kernel/init_task.o init/main.o init/version.o \
        --start-group \
        arch/mips/kernel/kernel.o arch/mips/mm/mm.o kernel/kernel.o mm/mm.o fs/fs.o ipc/ipc.o arch/mips/dec/dec.o \
        net/network.a \
        drivers/block/block.a drivers/char/char.o drivers/misc/misc.o drivers/net/net.o drivers/parport/parport.a drivers/scsi/scsi.a drivers/cdrom/cdrom.a drivers/video/video.o drivers/tc/tc.a \
        arch/mips/lib/lib.a /data/kernel/linux/lib/lib.a arch/mips/dec/prom/rexlib.a \
        --end-group \
        -o vmlinux
drivers/char/char.o: In function `setkeycode':
keyboard.c(.text+0x848c): undefined reference to `pckbd_setkeycode'
keyboard.c(.text+0x848c): relocation truncated to fit: R_MIPS_26 pckbd_setkeycode
drivers/char/char.o: In function `getkeycode':
keyboard.c(.text+0x84a8): undefined reference to `pckbd_getkeycode'
keyboard.c(.text+0x84a8): relocation truncated to fit: R_MIPS_26 pckbd_getkeycode
drivers/char/char.o: In function `handle_scancode':
keyboard.c(.text+0x85c8): undefined reference to `pckbd_translate'
keyboard.c(.text+0x85c8): relocation truncated to fit: R_MIPS_26 pckbd_translate
keyboard.c(.text+0x8634): undefined reference to `pckbd_unexpected_up'
keyboard.c(.text+0x8634): relocation truncated to fit: R_MIPS_26 pckbd_unexpected_up
drivers/char/char.o: In function `kbd_bh':
keyboard.c(.text+0x9ab0): undefined reference to `pckbd_leds'
keyboard.c(.text+0x9ab0): relocation truncated to fit: R_MIPS_26 pckbd_leds
drivers/char/char.o: In function `misc_register':
misc.c(.text.init+0x910): undefined reference to `pckbd_init_hw'
misc.c(.text.init+0x910): relocation truncated to fit: R_MIPS_26 pckbd_init_hw
make: *** [vmlinux] Error 1

(root@193)/data/kernel/linux# egrep -i "KEY|KBD" .config
# CONFIG_KEYBOARD is not set

Flo
-- 
Florian Lohoff		flo@rfc822.org		      	+49-5241-470566
"Technology is a constant battle between manufacturers producing bigger and
more idiot-proof systems and nature producing bigger and better idiots."

From ralf@uni-koblenz.de  Thu Feb 17 11:33:39 2000
Received: from mailhost.uni-koblenz.de (mailhost.uni-koblenz.de [141.26.64.1]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id LAA10735; Thu, 17 Feb 2000 11:33:38 +0100 (MET)
Received-Date: Thu, 17 Feb 2000 11:33:38 +0100 (MET)
Received: from cacc-23.uni-koblenz.de (cacc-23.uni-koblenz.de [141.26.131.23])
	by mailhost.uni-koblenz.de (8.9.3/8.9.3) with ESMTP id LAA09124;
	Thu, 17 Feb 2000 11:33:29 +0100 (MET)
Received: by lappi.waldorf-gmbh.de id <S407914AbQBPRXP>;
	Wed, 16 Feb 2000 18:23:15 +0100
Date: Wed, 16 Feb 2000 18:23:15 +0100
From: Ralf Baechle <ralf@uni-koblenz.de>
To: "Gleb O. Raiko" <raiko@niisi.msk.ru>
Cc: linux-mips@fnet.fr
Subject: Re: -fno-strict-aliasing problem in the latest 2.3
Message-ID: <20000216182315.A6252@uni-koblenz.de>
References: <38A91E19.CE7A9890@niisi.msk.ru>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0pre3us
In-Reply-To: <38A91E19.CE7A9890@niisi.msk.ru>
X-Accept-Language: de,en,fr
Content-Length: 1615
Lines: 41

On Tue, Feb 15, 2000 at 12:36:26PM +0300, Gleb O. Raiko wrote:

> There is a problem with the way main Makefile determines whether the
> compiler suports -fno-strict-aliasing. Namely, Makefile blindly gets $CC
> and tries to feed this option to it. Unfortunately, we set CC to proper
> mips[el]-linux-gcc later in arch/mips/Makefile, so the main Makefile
> just checks against native gcc. On RH6.1 with latest cross tool rpms
> installed, I get cc1: Invalid option `-fno-strict-aliasing' during
> comppilation, obviously.
> 
> I can't offer an elegenat solution to resolve this problem. Basically, I
> see three choices: 
> 
> 1. Move logic that sets CC from arch/mips/Makefile to the main Makefile
>    (Nightmare for Ralf who have to either feed it to Linus or add this
>    logic in the main Makefile every merge, I think.)

This is a generic problem which affects all architectures so there is no
reason why to put it to somewhere else than into the main Makefile.

> 2. Filter CFLAGS to remove -fno-strict-aliasing in arch/mips/Makefile
>    (Nasty.)

Definately nastissimo.

> 3. Fix the mips compiler :-)

Don't fix what isn't broken.

>    (Looks good for me despite the fact I don't understand exctly how
>    much work it costs, but can imagine...)

The fix is trivial, move the offending lines:

# use '-fno-strict-aliasing', but only if the compiler can take it
CFLAGS += $(shell if $(CC) -fno-strict-aliasing -S -o /dev/null -xc /dev/null >/dev/null 2>&1; then echo "-fno-strict-aliasing"; fi)

down below the ``include arch/$(ARCH)/Makefile'' statement and you're
set.  I'll send this to CVS.

  Ralf

From Harald.Koerfgen@home.ivm.de  Wed Feb 16 18:24:10 2000
Received: from mail.ivm.net (mail.ivm.net [62.204.1.4]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id SAA28576; Wed, 16 Feb 2000 18:24:09 +0100 (MET)
Received-Date: Wed, 16 Feb 2000 18:24:09 +0100 (MET)
Received: from franz.no.dom (port85.duesseldorf.ivm.de [195.247.65.85])
	by mail.ivm.net (8.8.8/8.8.8) with ESMTP id SAA21781;
	Wed, 16 Feb 2000 18:23:20 +0100
X-To: linux-mips@fnet.fr
Message-ID: <XFMail.000216182402.Harald.Koerfgen@home.ivm.de>
X-Mailer: XFMail 1.3 [p0] on Linux
X-Priority: 3 (Normal)
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
In-Reply-To: <38A9D0CB.FF958043@galileo.co.il>
Date: Wed, 16 Feb 2000 18:24:02 +0100 (MET)
Reply-To: "Harald Koerfgen" <Harald.Koerfgen@home.ivm.de>
Organization: none
Sender: harry@franz.no.dom
From: Harald Koerfgen <Harald.Koerfgen@home.ivm.de>
To: Rabeeh Khoury <rabeeh@galileo.co.il>
Subject: RE: boot memory
Cc: "linux-mips@fnet.fr" <linux-mips@fnet.fr>
Content-Length: 1140
Lines: 48


On 15-Feb-00 Rabeeh Khoury wrote:
> Hi All
> 
> I'm having trouble with my embedded system initializing the ram ; I do
> the following for initializations in kernel_entry -
> 
> {
>  mips_machgroup = MACH_GROUP_GALILEO;
> 
>  mips_memory_upper = 0x81000000; // not needed any more
>  galileo_mem_init();
> }
> 
> void __init galileo_mem_init(void)
> {
>   unsigned long bootmap_size;
> 
>  max_low_pfn = 0x1000; // 16 MB of ram - that's what I have on the
> embedded
>   bootmap_size = init_bootmem(0, max_low_pfn);
>   free_bootmem (0 , 0x01000000);
>   reserve_bootmem(0, 0x01000000);
> }
> 

What about something like:

#define PFN_UP(x)       (((x) + PAGE_SIZE-1) >> PAGE_SHIFT)

void __init galileo_mem_init(void)
{
  extern char _end;
  unsigned long bootmap_size;

  start_pfn = PFN_UP((unsigned long)&_end);
  mem_size = 0x01000000;

  /* Register all the contiguous memory with the bootmem allocator
    and free it.  Be careful about the bootmem freemap.  */
  bootmap_size = init_bootmem(start_pfn, mem_size >> PAGE_SHIFT);
  free_bootmem(start_pfn + bootmap_size, mem_size - start_pfn - bootmap_size);
}

?
---
Regards,
Harald

From ralf@uni-koblenz.de  Thu Feb 17 11:33:41 2000
Received: from mailhost.uni-koblenz.de (mailhost.uni-koblenz.de [141.26.64.1]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id LAA10741; Thu, 17 Feb 2000 11:33:40 +0100 (MET)
Received-Date: Thu, 17 Feb 2000 11:33:40 +0100 (MET)
Received: from cacc-23.uni-koblenz.de (cacc-23.uni-koblenz.de [141.26.131.23])
	by mailhost.uni-koblenz.de (8.9.3/8.9.3) with ESMTP id LAA09176;
	Thu, 17 Feb 2000 11:33:36 +0100 (MET)
Received: by lappi.waldorf-gmbh.de id <S407915AbQBPRpW>;
	Wed, 16 Feb 2000 18:45:22 +0100
Date: Wed, 16 Feb 2000 18:45:22 +0100
From: Ralf Baechle <ralf@uni-koblenz.de>
To: Rabeeh Khoury <rabeeh@galileo.co.il>
Cc: "linux-mips@fnet.fr" <linux-mips@fnet.fr>
Subject: Re: boot memory
Message-ID: <20000216184522.B6252@uni-koblenz.de>
References: <38A9D0CB.FF958043@galileo.co.il>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0pre3us
In-Reply-To: <38A9D0CB.FF958043@galileo.co.il>
X-Accept-Language: de,en,fr
Content-Length: 811
Lines: 30

On Tue, Feb 15, 2000 at 05:18:51PM -0500, Rabeeh Khoury wrote:

> void __init galileo_mem_init(void)
> {
>   unsigned long bootmap_size;
> 
>  max_low_pfn = 0x1000; // 16 MB of ram - that's what I have on the
> embedded
>   bootmap_size = init_bootmem(0, max_low_pfn);

This will put the allocation bitmap at physical address zero where trap_init()
will overwrite it with the exception handlers.  *boom*.

>   free_bootmem (0 , 0x01000000);

This frees the entire physical memory ...

>   reserve_bootmem(0, 0x01000000);
> }

... and declares it as in use once again -> No free memory left for the
kernel.

> but the kernel is stuck in the alloc_bootmem_node which is called from
> free_area_init_core .

Fix the above bugs, then retry.  With what you did above free_area_init()
isn't supposed to work.

  Ralf

From raiko@niisi.msk.ru  Wed Feb 16 18:47:23 2000
Received: from t111.niisi.ras.ru (root@t111.niisi.ras.ru [193.232.173.111]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id SAA29142; Wed, 16 Feb 2000 18:47:21 +0100 (MET)
Received-Date: Wed, 16 Feb 2000 18:47:21 +0100 (MET)
Received: from t06.niisi.ras.ru (t06.niisi.ras.ru [193.232.173.6])
	by t111.niisi.ras.ru (8.9.1/8.9.1) with ESMTP id UAA04161
	for <linux-mips@fnet.fr>; Wed, 16 Feb 2000 20:48:01 +0300
Received: (from uucp@localhost) by t06.niisi.ras.ru (8.7.6/8.7.3) with UUCP id UAA02587 for linux-mips@fnet.fr; Wed, 16 Feb 2000 20:55:20 +0300
Received: from niisi.msk.ru (t34 [193.232.173.34]) by niisi.msk.ru (8.8.8/8.8.8) with ESMTP id UAA22649 for <linux-mips@fnet.fr>; Wed, 16 Feb 2000 20:44:59 +0300 (MSK)
Message-ID: <38AAE462.86F225D8@niisi.msk.ru>
Date: Wed, 16 Feb 2000 20:54:42 +0300
From: "Gleb O. Raiko" <raiko@niisi.msk.ru>
Organization: NIISI RAN
X-Mailer: Mozilla 4.7 [en] (WinNT; I)
X-Accept-Language: en,ru
MIME-Version: 1.0
To: "linux-mips@fnet.fr" <linux-mips@fnet.fr>
Subject: Re: boot memory
References: <XFMail.000216182402.Harald.Koerfgen@home.ivm.de>
Content-Type: text/plain; charset=koi8-r
Content-Transfer-Encoding: 7bit
Content-Length: 1243
Lines: 39

Harald Koerfgen wrote:

> What about something like:
> 
> #define PFN_UP(x)       (((x) + PAGE_SIZE-1) >> PAGE_SHIFT)
> 
> void __init galileo_mem_init(void)
> {
>   extern char _end;
>   unsigned long bootmap_size;
> 
>   start_pfn = PFN_UP((unsigned long)&_end);
>   mem_size = 0x01000000;
> 
>   /* Register all the contiguous memory with the bootmem allocator
>     and free it.  Be careful about the bootmem freemap.  */
>   bootmap_size = init_bootmem(start_pfn, mem_size >> PAGE_SHIFT);
>   free_bootmem(start_pfn + bootmap_size, mem_size - start_pfn - bootmap_size);
> }
> 

More easy :-), w/o PFN_UP. Just implemented for baget today:

/* endmem - highest address of phys memory, passed by Baget Linux loader
*/
static void __init prom_meminit(unsigned long endmem)
{
        extern int _end;
        unsigned long bootmap_size;
        unsigned long start_pfn, max_pfn;
        unsigned long free_start = PAGE_ALIGN((unsigned long)&_end);

        start_pfn = MAP_NR(free_start);
        max_pfn = MAP_NR(endmem);
        bootmap_size = init_bootmem(start_pfn, max_pfn);
        free_bootmem(__pa(free_start), endmem - free_start);
	/* reserve bootmem allocator's bitmap */
        reserve_bootmem(__pa(free_start), bootmap_size);
}

From Harald.Koerfgen@home.ivm.de  Wed Feb 16 19:02:56 2000
Received: from mail.ivm.net (mail.ivm.net [62.204.1.4]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id TAA29288; Wed, 16 Feb 2000 19:02:55 +0100 (MET)
Received-Date: Wed, 16 Feb 2000 19:02:55 +0100 (MET)
Received: from franz.no.dom (port216.duesseldorf.ivm.de [195.247.65.216])
	by mail.ivm.net (8.8.8/8.8.8) with ESMTP id TAA24531;
	Wed, 16 Feb 2000 19:02:37 +0100
X-To: linux-mips@fnet.fr
Message-ID: <XFMail.000216190319.Harald.Koerfgen@home.ivm.de>
X-Mailer: XFMail 1.3 [p0] on Linux
X-Priority: 3 (Normal)
MIME-Version: 1.0
Content-Type: multipart/mixed;
 boundary="_=XFMail.1.3.p0.Linux:000216190255:1753=_"
In-Reply-To: <38A91E19.CE7A9890@niisi.msk.ru>
Date: Wed, 16 Feb 2000 19:03:19 +0100 (MET)
Reply-To: "Harald Koerfgen" <Harald.Koerfgen@home.ivm.de>
Organization: none
Sender: harry@franz.no.dom
From: Harald Koerfgen <Harald.Koerfgen@home.ivm.de>
To: "Gleb O. Raiko" <raiko@niisi.msk.ru>
Subject: RE: -fno-strict-aliasing problem in the latest 2.3
Cc: linux-mips@fnet.fr, SGI Linux <linux@cthulhu.engr.sgi.com>
Content-Length: 1947
Lines: 56

This message is in MIME format
--_=XFMail.1.3.p0.Linux:000216190255:1753=_
Content-Type: text/plain; charset=us-ascii

Hi,

On 15-Feb-00 Gleb O. Raiko wrote:
> There is a problem with the way main Makefile determines whether the
> compiler suports -fno-strict-aliasing. Namely, Makefile blindly gets $CC
> and tries to feed this option to it. Unfortunately, we set CC to proper
> mips[el]-linux-gcc later in arch/mips/Makefile, so the main Makefile
> just checks against native gcc. On RH6.1 with latest cross tool rpms
> installed, I get cc1: Invalid option `-fno-strict-aliasing' during
> comppilation, obviously.

I am not exactly shure if it has ill side effects or if this may not be wanted
for some reason, but the attached patch fixes that for me.

OK to commit?
---
Regards,
Harald

--_=XFMail.1.3.p0.Linux:000216190255:1753=_
Content-Disposition: attachment; filename="Makefile-patch"
Content-Transfer-Encoding: 7bit
Content-Description: Makefile-patch
Content-Type: text/plain; charset=us-ascii; name=Makefile-patch; SizeOnDisk=835

--- /nfs/cvs/linux-2.3/linux/Makefile	Wed Feb 16 18:40:57 2000
+++ Makefile	Wed Feb 16 18:53:13 2000
@@ -96,9 +96,6 @@
 CFLAGS := $(CPPFLAGS) -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer
 AFLAGS := $(CPPFLAGS)
 
-# use '-fno-strict-aliasing', but only if the compiler can take it
-CFLAGS += $(shell if $(CC) -fno-strict-aliasing -S -o /dev/null -xc /dev/null >
/dev/null 2>&1; then echo "-fno-strict-aliasing"; fi)
-
 #
 # if you want the RAM disk device, define this to be the
 # size in blocks.
@@ -252,6 +249,9 @@
 endif
 
 include arch/$(ARCH)/Makefile
+
+# use '-fno-strict-aliasing', but only if the compiler can take it
+CFLAGS += $(shell if $(CC) -fno-strict-aliasing -S -o /dev/null -xc /dev/null >
/dev/null 2>&1; then echo "-fno-strict-aliasing"; fi)
 
 .S.s:
 	$(CC) -D__ASSEMBLY__ $(AFLAGS) -traditional -E -o $*.s $<

--_=XFMail.1.3.p0.Linux:000216190255:1753=_--
End of MIME message

From ralf@oss.sgi.com  Thu Feb 17 11:33:47 2000
Received: from mailhost.uni-koblenz.de (mailhost.uni-koblenz.de [141.26.64.1]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id LAA10773; Thu, 17 Feb 2000 11:33:45 +0100 (MET)
Received-Date: Thu, 17 Feb 2000 11:33:45 +0100 (MET)
Received: from cacc-23.uni-koblenz.de (cacc-23.uni-koblenz.de [141.26.131.23])
	by mailhost.uni-koblenz.de (8.9.3/8.9.3) with ESMTP id LAA09185;
	Thu, 17 Feb 2000 11:33:39 +0100 (MET)
Received: by lappi.waldorf-gmbh.de id <S407916AbQBPSY1>;
	Wed, 16 Feb 2000 19:24:27 +0100
Date: Wed, 16 Feb 2000 19:24:27 +0100
From: Ralf Baechle <ralf@oss.sgi.com>
To: linux@engr.sgi.com, linux-mips@fnet.fr, linux-mips@vger.rutgers.edu
Subject: 32-bit MIPS with > 512mb mem
Message-ID: <20000216192427.A6330@uni-koblenz.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0pre3us
X-Accept-Language: de,en,fr
Content-Length: 532
Lines: 15

Is anybody using 32-bit MIPS CPUs which have more than 512mb of memory or
to be more exact have RAM that isn't accessible via the KSEG0 / KSEG1
window?

So far I haven't ever seen such a machine.  For 64-bit CPUs the right
thing to do is easy - use a 64-bit kernel.  But for 32-bit CPUs the Intel
highmem stuff in the memory managment now gives us a sane way to use
the memory of such configuration with just a little bit of extra code.

So if anybody wants support for such a configuration, please drop me a
note.

Thanks,

  Ralf

From laneb@bcstec.ca.boeing.com  Wed Feb 16 19:39:06 2000
Received: from stl-smtpout-01.boeing.com (stl-smtpout-01.boeing.com [12.13.247.21]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id TAA29953; Wed, 16 Feb 2000 19:39:05 +0100 (MET)
Received-Date: Wed, 16 Feb 2000 19:39:05 +0100 (MET)
Received: from stl-av-01.boeing.com ([192.76.190.6])
	by stl-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id MAA27277
	for <linux-mips@fnet.fr>; Wed, 16 Feb 2000 12:39:02 -0600 (CST)
Received: from stl-hub-01.boeing.com (localhost [127.0.0.1])
	by stl-av-01.boeing.com (8.9.2/8.9.2) with ESMTP id MAA29183
	for <linux-mips@fnet.fr>; Wed, 16 Feb 2000 12:39:01 -0600 (CST)
Received: from [136.240.231.86] by stl-hub-01.boeing.com with ESMTP for linux-mips@fnet.fr; Wed, 16 Feb 2000 12:38:54 -0600
Sender: laneb@bcstec.ca.boeing.com
Message-Id: <38AAEEBD.1638AF47@bcstec.ca.boeing.com>
Date: Wed, 16 Feb 2000 10:38:53 -0800
From: Bruce Lane <laneb@bcstec.ca.boeing.com>
Organization: BCAG, RS/6000 (Unix) Systems Support
X-Mailer: Mozilla 4.51 [en] (X11; U; AIX 4.3)
X-Accept-Language: en
MIME-Version: 1.0
To: linux-mips@fnet.fr
Subject: NEC RISCServer Support
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Length: 833
Lines: 25

NOTE: This is being sent from work. Please direct responses to:
kyrrin@bluefeathertech.com

With that said...

Gentlemen,

	I currently have a spare NEC RISCServer 2200 with two R4000 CPU's that
I would love to resurrect. My coding skills are practically nil, but I
would be happy to (time allowing) try and assist with testing a Linux
port for the system.

	Has there been any further progress on SMP support?

	Thanks in advance.
	
-- 
-=-=-=-=-=-=-=-=-=-
Bruce Lane, RS/6000 Single-Glass (Unix) Support
BCAG Renton, 10-20.5, Cubie 5C1-1, (425) 234-2113
http://bcstec.ca.boeing.com/~laneb
The opinions and views expressed are strictly my own. They do not
necessarily represent the views of Boeing as a company, other
employees, or any domestic or exotic animals contained therein.
You have now been officially disclaimed. *beeeep*

From wje@liveoak.engr.sgi.com  Wed Feb 16 19:51:19 2000
Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id TAA00179; Wed, 16 Feb 2000 19:51:17 +0100 (MET)
Received-Date: Wed, 16 Feb 2000 19:51:17 +0100 (MET)
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id KAA24465; Wed, 16 Feb 2000 10:46:42 -0800 (PST)
	mail_from (wje@liveoak.engr.sgi.com)
Received: from liveoak.engr.sgi.com (liveoak.engr.sgi.com [163.154.5.24])
	by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id KAA25988;
	Wed, 16 Feb 2000 10:50:54 -0800 (PST)
	mail_from (wje@liveoak.engr.sgi.com)
Received: (from wje@localhost)
	by liveoak.engr.sgi.com (8.9.3/8.8.7) id KAA16521;
	Wed, 16 Feb 2000 10:50:47 -0800
X-Authentication-Warning: liveoak.engr.sgi.com: wje set sender to wje@liveoak.engr.sgi.com using -f
From: "William J. Earl" <wje@cthulhu.engr.sgi.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <14506.61831.733915.236157@liveoak.engr.sgi.com>
Date: Wed, 16 Feb 2000 10:50:47 -0800 (PST)
To: "Kevin D. Kissell" <kevink@mips.com>
Cc: "Ralf Baechle" <ralf@oss.sgi.com>,
        "Geert Uytterhoeven" <Geert.Uytterhoeven@sonycom.com>,
        <linux@cthulhu.engr.sgi.com>, <linux-mips@fnet.fr>,
        <linux-mips@vger.rutgers.edu>
Subject: Re: Indy crashes
In-Reply-To: <003101bf786a$8c44d150$0ceca8c0@satanas.mips.com>
References: <003101bf786a$8c44d150$0ceca8c0@satanas.mips.com>
X-Mailer: VM 6.74 under Emacs 20.3.1
Content-Length: 7260
Lines: 170

Kevin D. Kissell writes:
 > Ralf Baechle writes:
 > >On Tue, Feb 15, 2000 at 11:23:49PM +0100, Kevin D. Kissell wrote:
...
 > >No, it's not a bug workaround.  The reason for this branch is that the
 > >R4000 and R4400 have a penalty of three cycles for a taken branch.  So
 > >the branch above is equivalent with 
 > >
 > > mtc0 k1, CP0_ENTRYLO1
 > > nop
 > > tlbwr
 > > nop
 > > nop
 > > nop
 > > eret
 > >
 > >Funky trick, isn't it?  I don't have the the R4600 / R5000 docs at hand
 > >but as I understood them the above code should also work just perfect
 > >for them.
 > 
 > No.  Not as I read the specs.  There are three problems here.
 > 
 > First, the question is *not* one of no-ops between the TLBWR
 > and the ERET, but of no-ops between the MTC0 and the
 > TLBWR - re-read the quoted text above from my previous
 > message.  So the code may well be broken as I conjectured
 > even if your assumption about the branch delay was valid.

      Empirically, this does not appear to be the case.  Here are 
the handlers for the r4600 and r5000 on IRIX, which have been stable
for years:

eutlbmiss3_250mhz:
[1023] 0x880849b0:  40 1a 20 00       mfc0	k0,context
[1023] 0x880849b4:  00 1a d0 43       sra	k0,k0,1
utlbmiss_r4600:
[1031] 0x880849b8:  8f 5b 00 00       lw	k1,0(k0)
[1031] 0x880849bc:  8f 5a 00 04       lw	k0,4(k0)
[1032] 0x880849c0:  00 1b d9 80       sll	k1,k1,6
[1032] 0x880849c4:  00 1b d9 82       srl	k1,k1,6
[1033] 0x880849c8:  40 9b 10 00       mtc0	k1,tlblo
[1034] 0x880849cc:  00 1a d1 80       sll	k0,k0,6
[1034] 0x880849d0:  00 1a d1 82       srl	k0,k0,6
[1035] 0x880849d4:  40 9a 18 00       mtc0	k0,tlblo1
[1036] 0x880849d8:  00 00 00 00       nop
[1037] 0x880849dc:  42 00 00 06       c0	tlbwr
[1038] 0x880849e0:  00 00 00 00       nop
utlbmiss_eret_3:
[1039] 0x880849e4:  0a 01 c9 59       j		_r4600_2_0_cacheop_eret
[1039] 0x880849e8:  00 00 00 00       nop

_r4600_2_0_cacheop_eret:
[ 211] 0x88072564:  00 00 00 00       nop
[ 211] 0x88072568:  00 00 00 00       nop
[ 211] 0x8807256c:  00 00 00 00       nop
[ 211] 0x88072570:  00 00 00 00       nop
[ 211] 0x88072574:  00 00 00 00       nop
[ 211] 0x88072578:  00 00 00 00       nop
[ 211] 0x8807257c:  00 00 00 00       nop
[ 211] 0x88072580:  00 00 00 00       nop
_r4600_2_0_cacheop_eret_inst:
[ 211] 0x88072584:  42 00 00 18       c0	eret

eutlbmiss3_250mhz:
[1023] 0x880849b0:  40 1a 20 00       mfc0	k0,context
[1023] 0x880849b4:  00 1a d0 43       sra	k0,k0,1
utlbmiss_r5000:
[1061] 0x8007ede8:  8f 5b 00 00       lw	k1,0(k0)
[1061] 0x8007edec:  8f 5a 00 04       lw	k0,4(k0)
[1062] 0x8007edf0:  42 00 00 08       c0	tlbp
[1063] 0x8007edf4:  00 1b d9 00       sll	k1,k1,4
[1063] 0x8007edf8:  00 1b d9 02       srl	k1,k1,4
[1064] 0x8007edfc:  40 9b 10 00       mtc0	k1,tlblo
[1065] 0x8007ee00:  40 1b 00 00       mfc0	k1,index
[1066] 0x8007ee04:  00 1a d1 00       sll	k0,k0,4
[1066] 0x8007ee08:  00 1a d1 02       srl	k0,k0,4
[1067] 0x8007ee0c:  07 61 00 04       bgez	k1,0x8007ee20
[1068] 0x8007ee10:  40 9a 18 00       mtc0	k0,tlblo1
[1069] 0x8007ee14:  42 00 00 06       c0	tlbwr
[1070] 0x8007ee18:  00 00 00 00       nop
[1071] 0x8007ee1c:  42 00 00 18       c0	eret

Note that, in the R4600 case, the "j _r4600_2_0_cacheop_eret" is
replaced with an eret on the R4600 Rev. 1.*.  (The code is patched
at system startup time.)  

     Also notice that IRIX does not index a segment table directly.
Instead, a second level TLB miss handler drops a mapping into a reserved
part of K2SEG for the PTE page required, where the base of that reserved
area is loaded into $context at startup time.

 > Second, the R5000 and R4600 piprlines are not as deep
 > as those of the R4000/4400.   The R5000 documentation
 > calls out a branch implementation with a *single* delay cycle.
 > I quote: "The one cycle branch delay is a result of the branch
 > comparison logic operating during the 1A pipeline stage of
 > the branch.  This allows the branch target address calculated
 > in the previous stage to be used for the instruction access in
 > the following 1I phase."   So even if the execution of the
 > branch were inserting delay between the MTC0 and the
 > TLBWR as you seemed to assume, it might not be inserting
 > as much delay as you think.

      As you can see from the above examples, the IRIX handlers
for these processors are indeed different.  The R4000 and R4400 
require more nops in other places:

utlbmiss_prolog_up:
[ 144] 0x88084600:  40 1a 20 00       mfc0	k0,context
[ 144] 0x88084604:  00 00 00 00       nop
[ 145] 0x88084608:  00 1a d0 43       sra	k0,k0,1
utlbmiss:
[ 219] 0x88084680:  8f 5b 00 00       lw	k1,0(k0)
[ 219] 0x88084684:  8f 5a 00 04       lw	k0,4(k0)
[ 223] 0x88084688:  00 1b d9 80       sll	k1,k1,6
[ 223] 0x8808468c:  00 1b d9 82       srl	k1,k1,6
[ 224] 0x88084690:  40 9b 10 00       mtc0	k1,tlblo
[ 225] 0x88084694:  00 1a d1 80       sll	k0,k0,6
[ 225] 0x88084698:  00 1a d1 82       srl	k0,k0,6
[ 236] 0x8808469c:  40 9a 18 00       mtc0	k0,tlblo1
[ 237] 0x880846a0:  00 00 00 00       nop
[ 238] 0x880846a4:  42 00 00 06       c0	tlbwr
[ 239] 0x880846a8:  00 00 00 00       nop
[ 239] 0x880846ac:  00 00 00 00       nop
[ 239] 0x880846b0:  00 00 00 00       nop
[ 246] 0x880846b4:  42 00 00 18       c0	eret

Notice that the R4000 requires a nop after the mfc0 from $context,
and also requires extra nops after the tlbwr.

     Also, here is the utlbmiss for the 250 MHZ R4400, with another
workaround:

utlbmiss_prolog_up:
[ 144] 0x88084600:  40 1a 20 00       mfc0	k0,context
[ 144] 0x88084604:  00 00 00 00       nop
[ 145] 0x88084608:  00 1a d0 43       sra	k0,k0,1
eutlbmiss3:
[ 805] 0x88084830:  8f 5b 00 00       lw	k1,0(k0)
[ 805] 0x88084834:  8f 5a 00 04       lw	k0,4(k0)
[ 809] 0x88084838:  00 1b d9 80       sll	k1,k1,6
[ 809] 0x8808483c:  00 1b d9 82       srl	k1,k1,6
[ 810] 0x88084840:  40 80 10 00       mtc0	zero,tlblo
[ 811] 0x88084844:  40 9b 10 00       mtc0	k1,tlblo
[ 812] 0x88084848:  00 1a d1 80       sll	k0,k0,6
[ 812] 0x8808484c:  00 1a d1 82       srl	k0,k0,6
[ 824] 0x88084850:  40 80 18 00       mtc0	zero,tlblo1
[ 825] 0x88084854:  40 9a 18 00       mtc0	k0,tlblo1
[ 826] 0x88084858:  00 00 00 00       nop
[ 827] 0x8808485c:  42 00 00 06       c0	tlbwr
[ 828] 0x88084860:  00 00 00 00       nop
[ 828] 0x88084864:  00 00 00 00       nop
[ 828] 0x88084868:  00 00 00 00       nop
[ 829] 0x8808486c:  42 00 00 18       c0	eret

    Emprirically, it appears that the manual is incorrect in regard
to the number of nop instructions.  The above sequences are known
to work (via years of testing, and also via validation in discussions
with people familiar with the hardware pipelines).
        
 > Thirdly, this whole thread underscores why "clever" solutions that 
 > depend on implementation features of particular CPUs should 
 > be avoided whenever possible. If you want to be assured of
 > getting a delay cycle in a MIPS instruction stream, you should
 > use a "SSNOP", (sll r0,r0,1 as opposed to the "nop" sll r0,r0,0),
 > which forces delays even in superscalar implementations.

      This is not realistic, given the number of workarounds required
for various processors, unless you are willing to have most processors
run quite a bit slower.  (Extra cycles in utlbmiss are noticeable.)

From elmion@yahoo.com  Wed Feb 16 20:49:36 2000
Received: from web1003.mail.yahoo.com (web1003.mail.yahoo.com [128.11.23.93]) by guadalquivir.fnet.fr with SMTP (8.8.8/97.02.12/Guadalquivir); id UAA00681; Wed, 16 Feb 2000 20:49:34 +0100 (MET)
Received-Date: Wed, 16 Feb 2000 20:49:34 +0100 (MET)
Received: (qmail 9172 invoked by uid 60001); 16 Feb 2000 19:17:28 -0000
Message-ID: <20000216191728.9171.qmail@web1003.mail.yahoo.com>
Received: from [195.84.7.210] by web1003.mail.yahoo.com; Wed, 16 Feb 2000 11:17:28 PST
Date: Wed, 16 Feb 2000 11:17:28 -0800 (PST)
From: Christer Eliasson <elmion@yahoo.com>
Subject: Mips Magnum R4000
To: linux-mips@fnet.fr
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Length: 471
Lines: 25

Hi all

Im in possession of a Mips R4000 Magnum 100Mhz

After having tried everything it still wont Bootup.
It hangs in POST

So .... If anyone wants it its yours (real cheap)
for under 100$US (With Cabinet if you want it)

No Memory
FB Card
Soundcard
Ethernet Card

You pay the freight

Mail me if you want it

Best Regards
Christer
__________________________________________________
Do You Yahoo!?
Talk to your friends online with Yahoo! Messenger.
http://im.yahoo.com

From kevink@mips.com  Wed Feb 16 23:34:14 2000
Received: from mx.mips.com (mx.mips.com [206.31.31.226]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id XAA03848; Wed, 16 Feb 2000 23:34:13 +0100 (MET)
Received-Date: Wed, 16 Feb 2000 23:34:13 +0100 (MET)
Received: from newman.mips.com (newman [206.31.31.8])
	by mx.mips.com (8.9.3/8.9.0) with ESMTP id OAA13459;
	Wed, 16 Feb 2000 14:34:06 -0800 (PST)
Received: from satanas (satanas [192.168.236.12])
	by newman.mips.com (8.9.3/8.9.0) with SMTP id OAA16552;
	Wed, 16 Feb 2000 14:34:03 -0800 (PST)
Message-ID: <00bf01bf78ce$37cf6cc0$0ceca8c0@satanas.mips.com>
From: "Kevin D. Kissell" <kevink@mips.com>
To: "William J. Earl" <wje@cthulhu.engr.sgi.com>
Cc: <linux-mips@vger.rutgers.edu>, <linux-mips@fnet.fr>,
        <linux@cthulhu.engr.sgi.com>
Subject: Re: Indy crashes
Date: Wed, 16 Feb 2000 23:33: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 4.72.3110.5
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Content-Length: 1358
Lines: 30

>Emprirically, it appears that the [R5000] manual is incorrect in regard
>to the number of nop instructions.  The above sequences are known
>to work (via years of testing, and also via validation in discussions
>with people familiar with the hardware pipelines).

In principle, I could check it against the RTL, but I probably
won't bother.  Many thanks for sharing the IRIX disassembly!

> > Thirdly, this whole thread underscores why "clever" solutions that 
> > depend on implementation features of particular CPUs should 
> > be avoided whenever possible. If you want to be assured of
> > getting a delay cycle in a MIPS instruction stream, you should
> > use a "SSNOP", (sll r0,r0,1 as opposed to the "nop" sll r0,r0,0),
> > which forces delays even in superscalar implementations.
>
>      This is not realistic, given the number of workarounds required
>for various processors, unless you are willing to have most processors
>run quite a bit slower.  (Extra cycles in utlbmiss are noticeable.)


I agree that it is not realistic to hav a single binary TLB miss handler
for all possible MIPS CPUs, but that's not what I was getting at.
I just consider it unwise to use the fact that one "knows" that branches 
"always" delay three cycles to avoid hazards.  Such tricks are 
obscurantist, and lead, in my experience, to errors.

            Kevin K.




From rabeeh@galileo.co.il  Wed Feb 16 19:03:15 2000
Received: from galileo5.galileo.co.il ([192.116.246.130]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id TAA29309; Wed, 16 Feb 2000 19:03:08 +0100 (MET)
Received-Date: Wed, 16 Feb 2000 19:03:08 +0100 (MET)
Received: from galileo.co.il (rabeeh@[10.2.20.126])
	by galileo.co.il (8.8.5/8.8.5) with ESMTP id UAA08696
	for <linux-mips@fnet.fr>; Wed, 16 Feb 2000 20:03:21 +0200 (GMT-2)
Sender: rabeeh@galileo.co.il
Message-ID: <38AB4936.79483F98@galileo.co.il>
Date: Wed, 16 Feb 2000 20:04:54 -0500
From: Rabeeh Khoury <rabeeh@galileo.co.il>
X-Mailer: Mozilla 4.51 [en] (X11; I; Linux 2.2.5-15 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: "linux-mips@fnet.fr" <linux-mips@fnet.fr>
Subject: NFS - Root
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Length: 650
Lines: 26

Hi All

I'm running diskless embedded system which mounts root-NFS over a PC
running RedHat v.6.

The embedded executes all initab functions but when it gets to login ;
it displays the contents of the file /etc/issue , runs /bin/login then
it doesn't log in at all ; the file passwd contains :

root::0:0:root:/root:/bin/sh


and there is no file /etc/shadow.

the gid and uid of all the files in the directory are 0 , 0    .

p.s. if I run the kernel over the embedded with "init=/bin/sh" option it
runs with no problem even executes some binaries.

what could be the problem ? if you encountered such a problem please
email me.

thank you
Rabeeh



From raiko@niisi.msk.ru  Thu Feb 17 12:02:28 2000
Received: from t111.niisi.ras.ru (root@t111.niisi.ras.ru [193.232.173.111]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id MAA11029; Thu, 17 Feb 2000 12:02:25 +0100 (MET)
Received-Date: Thu, 17 Feb 2000 12:02:25 +0100 (MET)
Received: from t06.niisi.ras.ru (t06.niisi.ras.ru [193.232.173.6])
	by t111.niisi.ras.ru (8.9.1/8.9.1) with ESMTP id OAA10107
	for <linux-mips@fnet.fr>; Thu, 17 Feb 2000 14:02:48 +0300
Received: (from uucp@localhost) by t06.niisi.ras.ru (8.7.6/8.7.3) with UUCP id OAA15973 for linux-mips@fnet.fr; Thu, 17 Feb 2000 14:07:36 +0300
Received: from niisi.msk.ru (t34 [193.232.173.34]) by niisi.msk.ru (8.8.8/8.8.8) with ESMTP id NAA08164 for <linux-mips@fnet.fr>; Thu, 17 Feb 2000 13:55:08 +0300 (MSK)
Message-ID: <38ABD5D7.8EF12364@niisi.msk.ru>
Date: Thu, 17 Feb 2000 14:04:55 +0300
From: "Gleb O. Raiko" <raiko@niisi.msk.ru>
Organization: NIISI RAN
X-Mailer: Mozilla 4.7 [en] (WinNT; I)
X-Accept-Language: en,ru
MIME-Version: 1.0
To: "linux-mips@fnet.fr" <linux-mips@fnet.fr>
Subject: Re: boot memory
References: <38A9D0CB.FF958043@galileo.co.il> <20000216184522.B6252@uni-koblenz.de>
Content-Type: text/plain; charset=koi8-r
Content-Transfer-Encoding: 7bit
Content-Length: 361
Lines: 12

Ralf,

While we are discussing bootmem allocator, is there any plans to fix the
allocator in order to be friendly for initrd on all arches ? Or do you
have any ideas how to init bootmem w/o poisoning initrd image ? Call
init_bootmem_node/core directly ?

Also, why do not call init_bootmem in the machine independent place,
somewhere in setup ?

Regards,
Gleb.

From raiko@niisi.msk.ru  Thu Feb 17 12:12:15 2000
Received: from t111.niisi.ras.ru (root@t111.niisi.ras.ru [193.232.173.111]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id MAA11113; Thu, 17 Feb 2000 12:12:13 +0100 (MET)
Received-Date: Thu, 17 Feb 2000 12:12:13 +0100 (MET)
Received: from t06.niisi.ras.ru (t06.niisi.ras.ru [193.232.173.6])
	by t111.niisi.ras.ru (8.9.1/8.9.1) with ESMTP id OAA10172;
	Thu, 17 Feb 2000 14:12:50 +0300
Received: (from uucp@localhost) by t06.niisi.ras.ru (8.7.6/8.7.3) with UUCP id OAA16133; Thu, 17 Feb 2000 14:19:48 +0300
Received: from niisi.msk.ru (t34 [193.232.173.34]) by niisi.msk.ru (8.8.8/8.8.8) with ESMTP id OAA08394; Thu, 17 Feb 2000 14:08:29 +0300 (MSK)
Message-ID: <38ABD8F8.E25D670F@niisi.msk.ru>
Date: Thu, 17 Feb 2000 14:18:16 +0300
From: "Gleb O. Raiko" <raiko@niisi.msk.ru>
Organization: NIISI RAN
X-Mailer: Mozilla 4.7 [en] (WinNT; I)
X-Accept-Language: en,ru
MIME-Version: 1.0
To: Ralf Baechle <ralf@oss.sgi.com>
CC: linux@engr.sgi.com, linux-mips@fnet.fr, linux-mips@vger.rutgers.edu
Subject: Re: 32-bit MIPS with > 512mb mem
References: <20000216192427.A6330@uni-koblenz.de>
Content-Type: text/plain; charset=koi8-r
Content-Transfer-Encoding: 7bit
Content-Length: 947
Lines: 23

Ralf Baechle wrote:
> 
> Is anybody using 32-bit MIPS CPUs which have more than 512mb of memory or
> to be more exact have RAM that isn't accessible via the KSEG0 / KSEG1
> window?
> 
> So far I haven't ever seen such a machine.  For 64-bit CPUs the right
> thing to do is easy - use a 64-bit kernel.  But for 32-bit CPUs the Intel
> highmem stuff in the memory managment now gives us a sane way to use
> the memory of such configuration with just a little bit of extra code.
> 
> So if anybody wants support for such a configuration, please drop me a
> note.

Not exactly > 512 mb, but related things. On Baget and DECstations, if
memory serves correctly, there is IO space mapped on KSEG2. Now, Baget
uses kseg2_allocate_io for it, DECstation also has something similar. IO
space on Jazz and Co. are located in virtual address window too, can't
remember where. In princple, access to such IO spaces may be done by
using highmem.

Regards,
Gleb.

From Geert.Uytterhoeven@sonycom.com  Thu Feb 17 13:21:05 2000
Received: from mail.sonytel.be (mail.sonytel.be [193.74.243.200]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id NAA11476; Thu, 17 Feb 2000 13:21:04 +0100 (MET)
Received-Date: Thu, 17 Feb 2000 13:21:04 +0100 (MET)
Received: from dandelion.sonytel.be (dandelion.sonytel.be [193.74.243.153])
	by mail.sonytel.be (8.9.0/8.8.6) with ESMTP id NAA11747;
	Thu, 17 Feb 2000 13:20:31 +0100 (MET)
Date: Thu, 17 Feb 2000 13:20:31 +0100 (MET)
From: Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com>
Sender: geert@sonycom.com
To: Harald Koerfgen <Harald.Koerfgen@home.ivm.de>
cc: "Gleb O. Raiko" <raiko@niisi.msk.ru>, linux-mips@fnet.fr,
        SGI Linux <linux@cthulhu.engr.sgi.com>
Subject: RE: -fno-strict-aliasing problem in the latest 2.3
In-Reply-To: <XFMail.000216190319.Harald.Koerfgen@home.ivm.de>
Message-ID: <Pine.GSO.4.10.10002171319480.21353-100000@dandelion.sonytel.be>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Content-Length: 1093
Lines: 26

On Wed, 16 Feb 2000, Harald Koerfgen wrote:
> On 15-Feb-00 Gleb O. Raiko wrote:
> > There is a problem with the way main Makefile determines whether the
> > compiler suports -fno-strict-aliasing. Namely, Makefile blindly gets $CC
> > and tries to feed this option to it. Unfortunately, we set CC to proper
> > mips[el]-linux-gcc later in arch/mips/Makefile, so the main Makefile
> > just checks against native gcc. On RH6.1 with latest cross tool rpms
> > installed, I get cc1: Invalid option `-fno-strict-aliasing' during
> > comppilation, obviously.
> 
> I am not exactly shure if it has ill side effects or if this may not be wanted
> for some reason, but the attached patch fixes that for me.
> 
> OK to commit?

Apart from the fact that your mailer breaks long line, even in attachments, it
seems to work fine.

Gr{oetje,eeting}s,

						Geert

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

From ralf@oss.sgi.com  Thu Feb 17 17:27:15 2000
Received: from mailhost.uni-koblenz.de (mailhost.uni-koblenz.de [141.26.64.1]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id RAA07702; Thu, 17 Feb 2000 17:27:13 +0100 (MET)
Received-Date: Thu, 17 Feb 2000 17:27:13 +0100 (MET)
Received: from cacc-27.uni-koblenz.de (cacc-27.uni-koblenz.de [141.26.131.27])
	by mailhost.uni-koblenz.de (8.9.3/8.9.3) with ESMTP id RAA24549;
	Thu, 17 Feb 2000 17:27:05 +0100 (MET)
Received: by lappi.waldorf-gmbh.de id <S407900AbQBQNZ3>;
	Thu, 17 Feb 2000 14:25:29 +0100
Date: Thu, 17 Feb 2000 14:25:29 +0100
From: Ralf Baechle <ralf@oss.sgi.com>
To: Harald Koerfgen <Harald.Koerfgen@home.ivm.de>
Cc: "Gleb O. Raiko" <raiko@niisi.msk.ru>, linux-mips@fnet.fr,
        SGI Linux <linux@cthulhu.engr.sgi.com>
Subject: Re: -fno-strict-aliasing problem in the latest 2.3
Message-ID: <20000217142529.A5423@uni-koblenz.de>
References: <38A91E19.CE7A9890@niisi.msk.ru> <XFMail.000216190319.Harald.Koerfgen@home.ivm.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0pre3us
In-Reply-To: <XFMail.000216190319.Harald.Koerfgen@home.ivm.de>
X-Accept-Language: de,en,fr
Content-Length: 816
Lines: 19

On Wed, Feb 16, 2000 at 07:03:19PM +0100, Harald Koerfgen wrote:

> On 15-Feb-00 Gleb O. Raiko wrote:
> > There is a problem with the way main Makefile determines whether the
> > compiler suports -fno-strict-aliasing. Namely, Makefile blindly gets $CC
> > and tries to feed this option to it. Unfortunately, we set CC to proper
> > mips[el]-linux-gcc later in arch/mips/Makefile, so the main Makefile
> > just checks against native gcc. On RH6.1 with latest cross tool rpms
> > installed, I get cc1: Invalid option `-fno-strict-aliasing' during
> > comppilation, obviously.
> 
> I am not exactly shure if it has ill side effects or if this may not be wanted
> for some reason, but the attached patch fixes that for me.
> 
> OK to commit?

Yes, my solution is identical, so who commits first commits first :)

  Ralf

From ralf@uni-koblenz.de  Thu Feb 17 17:27:18 2000
Received: from mailhost.uni-koblenz.de (mailhost.uni-koblenz.de [141.26.64.1]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id RAA07708; Thu, 17 Feb 2000 17:27:16 +0100 (MET)
Received-Date: Thu, 17 Feb 2000 17:27:16 +0100 (MET)
Received: from cacc-27.uni-koblenz.de (cacc-27.uni-koblenz.de [141.26.131.27])
	by mailhost.uni-koblenz.de (8.9.3/8.9.3) with ESMTP id RAA24566;
	Thu, 17 Feb 2000 17:27:09 +0100 (MET)
Received: by lappi.waldorf-gmbh.de id <S407911AbQBQNt3>;
	Thu, 17 Feb 2000 14:49:29 +0100
Date: Thu, 17 Feb 2000 14:49:29 +0100
From: Ralf Baechle <ralf@uni-koblenz.de>
To: Rabeeh Khoury <rabeeh@galileo.co.il>
Cc: "linux-mips@fnet.fr" <linux-mips@fnet.fr>
Subject: Re: NFS - Root
Message-ID: <20000217144928.A5436@uni-koblenz.de>
References: <38AB4936.79483F98@galileo.co.il>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0pre3us
In-Reply-To: <38AB4936.79483F98@galileo.co.il>
X-Accept-Language: de,en,fr
Content-Length: 961
Lines: 30

On Wed, Feb 16, 2000 at 08:04:54PM -0500, Rabeeh Khoury wrote:

> I'm running diskless embedded system which mounts root-NFS over a PC
> running RedHat v.6.
> 
> The embedded executes all initab functions but when it gets to login ;
> it displays the contents of the file /etc/issue , runs /bin/login then
> it doesn't log in at all.

What does that mean, what happens exactly?  You get back to the login:
prompt or maybe an error message?

> ; the file passwd contains :
> 
> root::0:0:root:/root:/bin/sh
> 
> and there is no file /etc/shadow.
> 
> the gid and uid of all the files in the directory are 0 , 0    .
> 
> p.s. if I run the kernel over the embedded with "init=/bin/sh" option it
> runs with no problem even executes some binaries.
> 
> what could be the problem ? if you encountered such a problem please
> email me.

Checkout if /etc/securetty (stupid concept ...) has an entry for the tty
on which you try to login.  Afair it's also ok.

  Ralf

From ralf@uni-koblenz.de  Thu Feb 17 17:27:18 2000
Received: from mailhost.uni-koblenz.de (mailhost.uni-koblenz.de [141.26.64.1]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id RAA07709; Thu, 17 Feb 2000 17:27:17 +0100 (MET)
Received-Date: Thu, 17 Feb 2000 17:27:17 +0100 (MET)
Received: from cacc-27.uni-koblenz.de (cacc-27.uni-koblenz.de [141.26.131.27])
	by mailhost.uni-koblenz.de (8.9.3/8.9.3) with ESMTP id RAA24576;
	Thu, 17 Feb 2000 17:27:12 +0100 (MET)
Received: by lappi.waldorf-gmbh.de id <S407914AbQBQN4I>;
	Thu, 17 Feb 2000 14:56:08 +0100
Date: Thu, 17 Feb 2000 14:56:07 +0100
From: Ralf Baechle <ralf@uni-koblenz.de>
To: kyrrin@bluefeathertech.com
Cc: linux-mips@fnet.fr
Subject: Re: NEC RISCServer Support
Message-ID: <20000217145607.C5436@uni-koblenz.de>
References: <38AAEEBD.1638AF47@bcstec.ca.boeing.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0pre3us
In-Reply-To: <38AAEEBD.1638AF47@bcstec.ca.boeing.com>
X-Accept-Language: de,en,fr
Content-Length: 636
Lines: 22

On Wed, Feb 16, 2000 at 10:38:53AM -0800, Bruce Lane wrote:

> NOTE: This is being sent from work. Please direct responses to:
> kyrrin@bluefeathertech.com
> 
> With that said...

That's what god made Reply-To: for.

With that said ;-)

> 	I currently have a spare NEC RISCServer 2200 with two R4000 CPU's that
> I would love to resurrect. My coding skills are practically nil, but I
> would be happy to (time allowing) try and assist with testing a Linux
> port for the system.
> 
> 	Has there been any further progress on SMP support?

SMP yes but not for these systems.  Initially SMP will be supported only
for SGI Origins.

  Ralf

From ralf@oss.sgi.com  Thu Feb 17 17:27:31 2000
Received: from mailhost.uni-koblenz.de (mailhost.uni-koblenz.de [141.26.64.1]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id RAA07768; Thu, 17 Feb 2000 17:27:28 +0100 (MET)
Received-Date: Thu, 17 Feb 2000 17:27:28 +0100 (MET)
Received: from cacc-27.uni-koblenz.de (cacc-27.uni-koblenz.de [141.26.131.27])
	by mailhost.uni-koblenz.de (8.9.3/8.9.3) with ESMTP id RAA24597;
	Thu, 17 Feb 2000 17:27:20 +0100 (MET)
Received: by lappi.waldorf-gmbh.de id <S407918AbQBQO1L>;
	Thu, 17 Feb 2000 15:27:11 +0100
Date: Thu, 17 Feb 2000 15:27:11 +0100
From: Ralf Baechle <ralf@oss.sgi.com>
To: "Kevin D. Kissell" <kevink@mips.com>
Cc: "William J. Earl" <wje@cthulhu.engr.sgi.com>, linux-mips@vger.rutgers.edu,
        linux-mips@fnet.fr, linux@cthulhu.engr.sgi.com
Subject: Re: Indy crashes
Message-ID: <20000217152711.E5436@uni-koblenz.de>
References: <00bf01bf78ce$37cf6cc0$0ceca8c0@satanas.mips.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0pre3us
In-Reply-To: <00bf01bf78ce$37cf6cc0$0ceca8c0@satanas.mips.com>
X-Accept-Language: de,en,fr
Content-Length: 1468
Lines: 28

On Wed, Feb 16, 2000 at 11:33:33PM +0100, Kevin D. Kissell wrote:

> > > Thirdly, this whole thread underscores why "clever" solutions that 
> > > depend on implementation features of particular CPUs should 
> > > be avoided whenever possible. If you want to be assured of
> > > getting a delay cycle in a MIPS instruction stream, you should
> > > use a "SSNOP", (sll r0,r0,1 as opposed to the "nop" sll r0,r0,0),
> > > which forces delays even in superscalar implementations.
> >
> >      This is not realistic, given the number of workarounds required
> >for various processors, unless you are willing to have most processors
> >run quite a bit slower.  (Extra cycles in utlbmiss are noticeable.)
> 
> I agree that it is not realistic to hav a single binary TLB miss handler
> for all possible MIPS CPUs, but that's not what I was getting at.
> I just consider it unwise to use the fact that one "knows" that branches 
> "always" delay three cycles to avoid hazards.  Such tricks are 
> obscurantist, and lead, in my experience, to errors.

Maybe but then again TLB exception handles aren't supposed to be hacked
by Joe Random Hacker.  There is more to know about the real silicon
beaviour than what the manuals say.  So for example some of the documentation
regarding c0 hazards on the R4000 is plain wrong for certain CPU revisions.

The TLB exception handlers really deserve a rewrite.  Somebody at QED
once called them the longest ones he has ever seen.

  Ralf

From R.vandenBerg@inter.NL.net  Thu Feb 17 16:23:44 2000
Received: from altrade.nijmegen.inter.nl.net (altrade.nijmegen.inter.nl.net [193.67.237.6]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id QAA16270; Thu, 17 Feb 2000 16:23:43 +0100 (MET)
Received-Date: Thu, 17 Feb 2000 16:23:43 +0100 (MET)
Received: from whale.dutch.mountain by altrade.nijmegen.inter.nl.net
	via hn51-12.Hoorn.NL.net [193.79.46.176] with ESMTP
	id QAA19145 (8.8.8/3.41); Thu, 17 Feb 2000 16:23:41 +0100 (MET)
Received: from localhost(really [127.0.0.1]) by whale.dutch.mountain
	via in.smtpd with smtp
	id <m12LSlm-00024mC@whale.dutch.mountain>
	for <linux-mips@fnet.fr>; Thu, 17 Feb 2000 16:23:06 +0100 (MET)
	(Smail-3.2 1996-Jul-4 #2 built 1996-Nov-26)
Date: Thu, 17 Feb 2000 16:23:05 +0100 (MET)
From: Richard van den Berg <R.vandenBerg@inter.NL.net>
X-Sender: ravdberg@whale.dutch.mountain
To: Rabeeh Khoury <rabeeh@galileo.co.il>
cc: "linux-mips@fnet.fr" <linux-mips@fnet.fr>
Subject: Re: filesystem problems
In-Reply-To: <38AC6C30.8F8412F9@galileo.co.il>
Message-ID: <Pine.LNX.3.95.1000217162228.1351C-100000@whale.dutch.mountain>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Content-Length: 708
Lines: 24

On Thu, 17 Feb 2000, Rabeeh Khoury wrote:

> I managed to mount NFS for my embedded system over a PC running linux
> RedHat 6.0
> all the files on the filesystem are uid=0 (root) and gid=0 ; when I try
> to create any new file on the embedded system it creates the file with
> gid and uid 65534 ??!!

$ man 5 exports

...

       By default, nfsd tries to obtain the anonymous uid and gid
       by looking up user nobody in the password file at  startup
       time.  If it isn't found, a uid and gid of -2 (i.e. 65534)
       is used. These  values  can  also  be  overridden  by  the
       anonuid and anongid options.

...

Guess you have to edit /etc/exports to change the behaviour.

Regards,
Richard

From ralf@oss.sgi.com  Thu Feb 17 17:29:03 2000
Received: from mailhost.uni-koblenz.de (mailhost.uni-koblenz.de [141.26.64.1]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id RAA07812; Thu, 17 Feb 2000 17:29:02 +0100 (MET)
Received-Date: Thu, 17 Feb 2000 17:29:02 +0100 (MET)
Received: from cacc-27.uni-koblenz.de (cacc-27.uni-koblenz.de [141.26.131.27])
	by mailhost.uni-koblenz.de (8.9.3/8.9.3) with ESMTP id RAA24602;
	Thu, 17 Feb 2000 17:27:23 +0100 (MET)
Received: by lappi.waldorf-gmbh.de id <S407920AbQBQQHo>;
	Thu, 17 Feb 2000 17:07:44 +0100
Date: Thu, 17 Feb 2000 17:07:44 +0100
From: Ralf Baechle <ralf@oss.sgi.com>
To: "Kevin D. Kissell" <kevink@mips.com>
Cc: Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com>,
        linux@cthulhu.engr.sgi.com, linux-mips@fnet.fr,
        linux-mips@vger.rutgers.edu
Subject: Re: Indy crashes
Message-ID: <20000217170744.F5436@uni-koblenz.de>
References: <003101bf786a$8c44d150$0ceca8c0@satanas.mips.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0pre3us
In-Reply-To: <003101bf786a$8c44d150$0ceca8c0@satanas.mips.com>
X-Accept-Language: de,en,fr
Content-Length: 6407
Lines: 143

On Wed, Feb 16, 2000 at 11:42:29AM +0100, Kevin D. Kissell wrote:

> >Funky trick, isn't it?  I don't have the the R4600 / R5000 docs at hand
> >but as I understood them the above code should also work just perfect
> >for them.
> 
> No.  Not as I read the specs.  There are three problems here.
> 
> First, the question is *not* one of no-ops between the TLBWR
> and the ERET, but of no-ops between the MTC0 and the
> TLBWR - re-read the quoted text above from my previous
> message.  So the code may well be broken as I conjectured
> even if your assumption about the branch delay was valid.

Exactly _that_ is the trick.  The pipeline will execute the two extra
branch penalty cycles _after_ the tlbwr instruction.  That is exactly
what according to my reading of the manual is necessary in order to
guarantee correct operation.

The c0 hazard between the mtc0 and tlbwr is also taken care of by the
branch instruction itself, there is only one instruction necessary and
as per r4k manual any instruction does.

Yes, it's obfuscating.  However David Miller put this in the code, I
guess he took this trick from IRIX and I took it from him.  I think
it's highly unlikely that we all made the same mistake - and that nobody
got bit by this for a the past few years.

That said, the whole TLB exception handling is sometimes very performance
sensitive.  We've got good reason to optimize it at almost any price.
So the whole thing should be rewritten anyway.

> Second, the R5000 and R4600 piprlines are not as deep
> as those of the R4000/4400.   The R5000 documentation
> calls out a branch implementation with a *single* delay cycle.
> I quote: "The one cycle branch delay is a result of the branch
> comparison logic operating during the 1A pipeline stage of
> the branch.  This allows the branch target address calculated
> in the previous stage to be used for the instruction access in
> the following 1I phase."   So even if the execution of the
> branch were inserting delay between the MTC0 and the
> TLBWR as you seemed to assume, it might not be inserting
> as much delay as you think.

On the R4600 and R5000 the branch will be taken with a delay of a single
cycle, that is the instruction in the branch delay slot and no additional
penalty.  That's exactly what we want.

> Thirdly, this whole thread underscores why "clever" solutions that 
> depend on implementation features of particular CPUs should 
> be avoided whenever possible.

That's why we have a number of implementations of TLB exception handlers.
Let me reiterate that they are extremly performance sensitive.

> If you want to be assured of
> getting a delay cycle in a MIPS instruction stream, you should
> use a "SSNOP", (sll r0,r0,1 as opposed to the "nop" sll r0,r0,0),
> which forces delays even in superscalar implementations.
> 
> >> So someone with the ability to reproduce the R5000
> >> problem should really try sticking a nop between the
> >> mtc0 and the branch (sigh) to see if that stabilizes 
> >> the system.
> 
> I still think this would be a good idea.  Further, from Bill Earl's
> comment on this same thread, it sounds like, to be conservative,
>  trap_init() in arch/mips/kernel/traps.c needs to detect the R5000
> case and patch in except_vec0_r45k_bvahwbug instead
> of except_vec0_r4000, and that furthermore a nop (or ssnop) 
> be added between the MTC0 and the branch of 
> except_vec0_r45k_bvahwbug.

Indeed, and I'll do that.  The fact that we do not handle this bug is
simply an omission on my side.  The conditions that need to be true for
this bug to actually hit a system are sufficiently rare that I don't
wonder why nobody ever got hit by this.

> >Talking about CPU bugs - the R5230 and maybe it's relatives needs a nasty
> >workaround.  I think I only put the workaround into the Cobalt kernel.
> >Of course IDT doesn't admit that this bug even exists ...
> 
> Um, why should they, when IDT didn't do the R5230?  ;-)
> Seriously, did you mean to refer to the R323xx from IDT,
> or to QED as the design house for the R5230?  I have been 
> running 2.2.12 on an R5260 for months and it has been very 
> stable.   To which bug and which workaround are you referring?

Sorry, I permanently missattribute the R5230 to IDT even though the manual
says different in big letters on the frontpage.  This is the exception
handler from the Cobalt kernel.

	/*
	 * This version has a bug workaround for the Nevada.  It seems
	 * as if under certain circumstances the move from cp0_context
	 * might produce a bogus result when the mfc0 instruction and
	 * it's consumer are in a different cacheline or a load instruction,
	 * probably any memory reference, is between them.  This is
	 * potencially slower than the R4000 version, so we use this
	 * special version.
	 */
	LEAF(except_vec0_nevada)
	.set	mips3
	mfc0	k0, CP0_BADVADDR		# Get faulting address
	mfc0	k1, CP0_TAGLO
	srl	k0, k0, 22			# get pgd only bits
	sll	k0, k0, 2
	addu	k1, k1, k0			# add in pgd offset
	lw	k1, (k1)
	mfc0	k0, CP0_CONTEXT			# get context reg
	srl	k0, k0, 1			# get pte offset
	and	k0, k0, 0xff8
	addu	k1, k1, k0			# add in offset
	lw	k0, 0(k1)			# get even pte
	lw	k1, 4(k1)			# get odd pte
	srl	k0, k0, 6			# convert to entrylo0
	mtc0	k0, CP0_ENTRYLO0		# load it
	srl	k1, k1, 6			# convert to entrylo1
	mtc0	k1, CP0_ENTRYLO1		# load it
	tlbwr					# write random tlb entry
	nop
	nop
	eret					# return from trap
	END(except_vec0_nevada)

Note that this is a handler for Cobalt's 2.0 so it's not a drop in
replacement for what we have in other kernels.

What we observed was that the first access of the kernel to virtual
memory, that was buffer_init() which was still using vmalloc'ed memory
somehow was not being processed correctly.  We've never observed that the
bug hits at some other place.  The explanation given in above comment is a
possible explanation of what I suspect after playing with exception handler
modifications for a few hours.  Since the CPU is a blackbox for me I cannot
guarantee that this explanation is correct or even close to reality.

Two people at Cobalt did run independently into this problem and found that
c0_context was corrupted.  However when later on some of there other at
Cobalt were talking to QED they denied the possible existence of a bug like
this in their silicon.  Having an empirically correct workaround for this
problem we then stopped further tracking this problem.

  Ralf

From ralf@oss.sgi.com  Fri Feb 18 00:17:04 2000
Received: from mailhost.uni-koblenz.de (mailhost.uni-koblenz.de [141.26.64.1]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id AAA16852; Fri, 18 Feb 2000 00:17:03 +0100 (MET)
Received-Date: Fri, 18 Feb 2000 00:17:03 +0100 (MET)
Received: from cacc-4.uni-koblenz.de (cacc-4.uni-koblenz.de [141.26.131.4])
	by mailhost.uni-koblenz.de (8.9.3/8.9.3) with ESMTP id AAA27832;
	Fri, 18 Feb 2000 00:16:50 +0100 (MET)
Received: by lappi.waldorf-gmbh.de id <S407895AbQBQQoc>;
	Thu, 17 Feb 2000 17:44:32 +0100
Date: Thu, 17 Feb 2000 17:44:32 +0100
From: Ralf Baechle <ralf@oss.sgi.com>
To: "Gleb O. Raiko" <raiko@niisi.msk.ru>
Cc: linux@engr.sgi.com, linux-mips@fnet.fr, linux-mips@vger.rutgers.edu
Subject: Re: 32-bit MIPS with > 512mb mem
Message-ID: <20000217174432.B5659@uni-koblenz.de>
References: <20000216192427.A6330@uni-koblenz.de> <38ABD8F8.E25D670F@niisi.msk.ru>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0pre3us
In-Reply-To: <38ABD8F8.E25D670F@niisi.msk.ru>
X-Accept-Language: de,en,fr
Content-Length: 819
Lines: 18

On Thu, Feb 17, 2000 at 02:18:16PM +0300, Gleb O. Raiko wrote:

> Not exactly > 512 mb, but related things. On Baget and DECstations, if
> memory serves correctly, there is IO space mapped on KSEG2. Now, Baget
> uses kseg2_allocate_io for it, DECstation also has something similar. IO
> space on Jazz and Co. are located in virtual address window too, can't
> remember where. In princple, access to such IO spaces may be done by
> using highmem.

I've only been refering to RAM where an efficient solution is much more
difficult.

Devices on some R4k machines are special anyway because sometimes they
reside at physical addresses outside the lowest 4gb which means we cannot
even address them using our current page tables.  And changing those in
general isn't a good idea unless we also have RAM at >= 512mb.

  Ralf

From ralf@uni-koblenz.de  Fri Feb 18 00:16:05 2000
Received: from mailhost.uni-koblenz.de (mailhost.uni-koblenz.de [141.26.64.1]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id AAA16748; Fri, 18 Feb 2000 00:16:04 +0100 (MET)
Received-Date: Fri, 18 Feb 2000 00:16:04 +0100 (MET)
Received: from cacc-4.uni-koblenz.de (cacc-4.uni-koblenz.de [141.26.131.4])
	by mailhost.uni-koblenz.de (8.9.3/8.9.3) with ESMTP id AAA27772;
	Fri, 18 Feb 2000 00:16:01 +0100 (MET)
Received: by lappi.waldorf-gmbh.de id <S407898AbQBQRif>;
	Thu, 17 Feb 2000 18:38:35 +0100
Date: Thu, 17 Feb 2000 18:38:35 +0100
From: Ralf Baechle <ralf@uni-koblenz.de>
To: "Gleb O. Raiko" <raiko@niisi.msk.ru>
Cc: "linux-mips@fnet.fr" <linux-mips@fnet.fr>
Subject: Re: boot memory
Message-ID: <20000217183835.A5988@uni-koblenz.de>
References: <38A9D0CB.FF958043@galileo.co.il> <20000216184522.B6252@uni-koblenz.de> <38ABD5D7.8EF12364@niisi.msk.ru>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0pre3us
In-Reply-To: <38ABD5D7.8EF12364@niisi.msk.ru>
X-Accept-Language: de,en,fr
Content-Length: 788
Lines: 21

On Thu, Feb 17, 2000 at 02:04:55PM +0300, Gleb O. Raiko wrote:

> While we are discussing bootmem allocator, is there any plans to fix the
> allocator in order to be friendly for initrd on all arches ? Or do you
> have any ideas how to init bootmem w/o poisoning initrd image ? Call
> init_bootmem_node/core directly ?

You won't poison the initrd image.  The {init,free,reserve}_bootmem()
functions will only change the bootmem bitmap but nothing else.

> Also, why do not call init_bootmem in the machine independent place,
> somewhere in setup ?

free_bootmem / reserve_bootmem obviously need to be called from
arch dependent code and putting init_bootmem somewhere else is plain
ugly.

If your only worry is the initrd you can still reserve the memory for it
in setup_arch().

  Ralf

From ralf@uni-koblenz.de  Fri Feb 18 00:16:23 2000
Received: from mailhost.uni-koblenz.de (mailhost.uni-koblenz.de [141.26.64.1]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id AAA16816; Fri, 18 Feb 2000 00:16:21 +0100 (MET)
Received-Date: Fri, 18 Feb 2000 00:16:21 +0100 (MET)
Received: from cacc-4.uni-koblenz.de (cacc-4.uni-koblenz.de [141.26.131.4])
	by mailhost.uni-koblenz.de (8.9.3/8.9.3) with ESMTP id AAA27802;
	Fri, 18 Feb 2000 00:16:18 +0100 (MET)
Received: by lappi.waldorf-gmbh.de id <S407899AbQBQRln>;
	Thu, 17 Feb 2000 18:41:43 +0100
Date: Thu, 17 Feb 2000 18:41:43 +0100
From: Ralf Baechle <ralf@uni-koblenz.de>
To: Richard van den Berg <R.vandenBerg@inter.NL.net>
Cc: Rabeeh Khoury <rabeeh@galileo.co.il>,
        "linux-mips@fnet.fr" <linux-mips@fnet.fr>
Subject: Re: filesystem problems
Message-ID: <20000217184143.B5988@uni-koblenz.de>
References: <38AC6C30.8F8412F9@galileo.co.il> <Pine.LNX.3.95.1000217162228.1351C-100000@whale.dutch.mountain>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0pre3us
In-Reply-To: <Pine.LNX.3.95.1000217162228.1351C-100000@whale.dutch.mountain>
X-Accept-Language: de,en,fr
Content-Length: 661
Lines: 24

On Thu, Feb 17, 2000 at 04:23:05PM +0100, Richard van den Berg wrote:

> $ man 5 exports
> 
> ...
> 
>        By default, nfsd tries to obtain the anonymous uid and gid
>        by looking up user nobody in the password file at  startup
>        time.  If it isn't found, a uid and gid of -2 (i.e. 65534)
>        is used. These  values  can  also  be  overridden  by  the
>        anonuid and anongid options.
> 
> ...
> 
> Guess you have to edit /etc/exports to change the behaviour.

He is looking for the no_root_squash export option which disables uid /
gid remapping as you describe above.  Like:

# cat /etc/exports
/	victim(rw,no_root_squash)
#

  Ralf

From rabeeh@galileo.co.il  Thu Feb 17 15:49:55 2000
Received: from galileo5.galileo.co.il ([192.116.246.130]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id PAA13898; Thu, 17 Feb 2000 15:49:51 +0100 (MET)
Received-Date: Thu, 17 Feb 2000 15:49:51 +0100 (MET)
Received: from galileo.co.il (rabeeh@[10.2.20.126])
	by galileo.co.il (8.8.5/8.8.5) with ESMTP id QAA08130
	for <linux-mips@fnet.fr>; Thu, 17 Feb 2000 16:44:52 +0200 (GMT-2)
Sender: rabeeh@galileo.co.il
Message-ID: <38AC6C30.8F8412F9@galileo.co.il>
Date: Thu, 17 Feb 2000 16:46:24 -0500
From: Rabeeh Khoury <rabeeh@galileo.co.il>
X-Mailer: Mozilla 4.51 [en] (X11; I; Linux 2.2.5-15 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: "linux-mips@fnet.fr" <linux-mips@fnet.fr>
Subject: filesystem problems
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Length: 785
Lines: 23

Hi All

I managed to mount NFS for my embedded system over a PC running linux
RedHat 6.0
all the files on the filesystem are uid=0 (root) and gid=0 ; when I try
to create any new file on the embedded system it creates the file with
gid and uid 65534 ??!!

bash# id
uid=0(root) gid=0(root) groups=0(root)
bash# cd /lib
bash# ls -la libcra*
-rwxrwxrwx   1 root                 73628 Feb  8  2000 libcrack.so
-rwxrwxrwx   1 root                 73628 Feb  8  2000 libcrack.so.2.7
bash# ldconfig
bash# ls -lan libcra*
-rwxrwxrwx   1 0        0           73628 Feb  8  2000 libcrack.so
lrwxrwxrwx   1 65534    65534          15 Feb 17  2000 libcrack.so.2 ->
libcrack.so.2.7
-rwxrwxrwx   1 0        0           73628 Feb  8  2000 libcrack.so.2.7

do you know what is the problem ?
thank you

From bleggett@sofamordanek.com  Fri Feb 18 01:52:54 2000
Received: from mail.sofamordanek.com (server5.sofamordanek.com [208.14.121.5]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id BAA20058; Fri, 18 Feb 2000 01:52:53 +0100 (MET)
Received-Date: Fri, 18 Feb 2000 01:52:53 +0100 (MET)
Received: by SERVER5 with Internet Mail Service (5.5.2650.21)
	id <FCDCK6GQ>; Thu, 17 Feb 2000 18:52:45 -0600
Message-ID: <BDDC26ED91ACD1118D4E00805F9FDAC3B027F2@broomfield01.sofamordanek.com>
From: Bruce Leggett <bleggett@sofamordanek.com>
To: linux@cthulhu.engr.sgi.com, linux-mips@fnet.fr,
        linux-mips@vger.rutgers.edu
Subject: Linux on O2?
Date: Thu, 17 Feb 2000 18:52:52 -0600
Return-Receipt-To: Bruce Leggett <bleggett@sofamordanek.com>
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Length: 170
Lines: 8

Hello,

How many folks are actually out there working on the Linux on mips port?

Is there any work going on towards running Linux on the O2 specifically?

cheers,
bruce

From brett@madhouse.org  Fri Feb 18 02:14:23 2000
Received: from caligula.madhouse.org ([216.160.90.69]) by guadalquivir.fnet.fr with SMTP (8.8.8/97.02.12/Guadalquivir); id CAA20200; Fri, 18 Feb 2000 02:14:22 +0100 (MET)
Received-Date: Fri, 18 Feb 2000 02:14:22 +0100 (MET)
Received: (qmail 1485 invoked by uid 509); 18 Feb 2000 01:14:25 -0000
Received: from localhost (sendmail-bs@127.0.0.1)
  by localhost with SMTP; 18 Feb 2000 01:14:25 -0000
Date: Thu, 17 Feb 2000 17:14:25 -0800 (PST)
From: brett <brett@madhouse.org>
To: Bruce Leggett <bleggett@sofamordanek.com>
cc: linux@cthulhu.engr.sgi.com, linux-mips@fnet.fr,
        linux-mips@vger.rutgers.edu
Subject: Re: Linux on O2?
In-Reply-To: <BDDC26ED91ACD1118D4E00805F9FDAC3B027F2@broomfield01.sofamordanek.com>
Message-ID: <Pine.LNX.3.96.1000217171401.908G-100000@caligula.madhouse.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Content-Length: 537
Lines: 19

Im still wainting to hear anything about the indigo i hear alot of talk
about the indigo2 but nothing about the original blue boxes

-----------------------------------------------
brett wagner	|	brett@madhouse.org
get committed!	|	http://www.madhouse.org
-----------------------------------------------

On Thu, 17 Feb 2000, Bruce Leggett wrote:

> Hello,
> 
> How many folks are actually out there working on the Linux on mips port?
> 
> Is there any work going on towards running Linux on the O2 specifically?
> 
> cheers,
> bruce
> 

From wje@liveoak.engr.sgi.com  Fri Feb 18 02:33:08 2000
Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id CAA20306; Fri, 18 Feb 2000 02:33:06 +0100 (MET)
Received-Date: Fri, 18 Feb 2000 02:33:06 +0100 (MET)
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.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 ESMTP id RAA03267; Thu, 17 Feb 2000 17:32:58 -0800 (PST)
	mail_from (wje@liveoak.engr.sgi.com)
Received: from liveoak.engr.sgi.com (liveoak.engr.sgi.com [163.154.5.24])
	by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id RAA48331;
	Thu, 17 Feb 2000 17:32:50 -0800 (PST)
	mail_from (wje@liveoak.engr.sgi.com)
Received: (from wje@localhost)
	by liveoak.engr.sgi.com (8.9.3/8.8.7) id RAA24858;
	Thu, 17 Feb 2000 17:32:44 -0800
X-Authentication-Warning: liveoak.engr.sgi.com: wje set sender to wje@liveoak.engr.sgi.com using -f
From: "William J. Earl" <wje@cthulhu.engr.sgi.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <14508.41276.408855.988727@liveoak.engr.sgi.com>
Date: Thu, 17 Feb 2000 17:32:44 -0800 (PST)
To: brett <brett@madhouse.org>
Cc: Bruce Leggett <bleggett@sofamordanek.com>, linux@cthulhu.engr.sgi.com,
        linux-mips@fnet.fr, linux-mips@vger.rutgers.edu
Subject: Re: Linux on O2?
In-Reply-To: <Pine.LNX.3.96.1000217171401.908G-100000@caligula.madhouse.org>
References: <BDDC26ED91ACD1118D4E00805F9FDAC3B027F2@broomfield01.sofamordanek.com>
	<Pine.LNX.3.96.1000217171401.908G-100000@caligula.madhouse.org>
X-Mailer: VM 6.74 under Emacs 20.3.1
Content-Length: 555
Lines: 11

brett writes:
 > Im still wainting to hear anything about the indigo i hear alot of talk
 > about the indigo2 but nothing about the original blue boxes
...

      The original Indigo was R3000-based.  The I/O is an earlier generation
of that used in Indy and Indigo2, so some of the driver work could be reused,
but it is hard to find documentation at this point.  The Indigo R4000
is pretty close to Indy and Indigo2, so it would not be too hard.  On the
other hand, there is no work done so far on supporting the "starter" graphics
on the Indigo R4000.

From ralf@uni-koblenz.de  Fri Feb 18 02:34:34 2000
Received: from mailhost.uni-koblenz.de (mailhost.uni-koblenz.de [141.26.64.1]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id CAA20334; Fri, 18 Feb 2000 02:34:33 +0100 (MET)
Received-Date: Fri, 18 Feb 2000 02:34:33 +0100 (MET)
Received: from cacc-4.uni-koblenz.de (cacc-4.uni-koblenz.de [141.26.131.4])
	by mailhost.uni-koblenz.de (8.9.3/8.9.3) with ESMTP id CAA03445;
	Fri, 18 Feb 2000 02:34:29 +0100 (MET)
Received: by lappi.waldorf-gmbh.de id <S407895AbQBRBeG>;
	Fri, 18 Feb 2000 02:34:06 +0100
Date: Fri, 18 Feb 2000 02:34:06 +0100
From: Ralf Baechle <ralf@uni-koblenz.de>
To: Rabeeh Khoury <rabeeh@galileo.co.il>
Cc: "linux-mips@fnet.fr" <linux-mips@fnet.fr>
Subject: Re: RPM installation
Message-ID: <20000218023406.C5234@uni-koblenz.de>
References: <38ACA682.DE01FB8C@galileo.co.il>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0pre3us
In-Reply-To: <38ACA682.DE01FB8C@galileo.co.il>
X-Accept-Language: de,en,fr
Content-Length: 573
Lines: 16

On Thu, Feb 17, 2000 at 08:55:14PM -0500, Rabeeh Khoury wrote:

> I'm trying to install RPM on my embedded system over NFS ; when I try
> installing some of the RPM's the system starts transmitting endless
> lookup requests over the NFS and it doesn't stop. for example the RPM
> rootfiles-1.5-3.noarch.rpm
> 
> did any one see problem like this in the past ?

Nope, seems you invented a new bug :-)

Maybe your driver is broken and you're just re-transmitting the same
requests again and again but the server keeps droping them because
they corrupted?  Like that.

  Ralf

From brett@madhouse.org  Fri Feb 18 02:42:24 2000
Received: from caligula.madhouse.org ([216.160.90.69]) by guadalquivir.fnet.fr with SMTP (8.8.8/97.02.12/Guadalquivir); id CAA20422; Fri, 18 Feb 2000 02:42:21 +0100 (MET)
Received-Date: Fri, 18 Feb 2000 02:42:21 +0100 (MET)
Received: (qmail 1519 invoked by uid 509); 18 Feb 2000 01:42:25 -0000
Received: from localhost (sendmail-bs@127.0.0.1)
  by localhost with SMTP; 18 Feb 2000 01:42:25 -0000
Date: Thu, 17 Feb 2000 17:42:25 -0800 (PST)
From: brett <brett@madhouse.org>
To: "William J. Earl" <wje@cthulhu.engr.sgi.com>
cc: Bruce Leggett <bleggett@sofamordanek.com>, linux@cthulhu.engr.sgi.com,
        linux-mips@fnet.fr, linux-mips@vger.rutgers.edu
Subject: Re: Linux on O2?
In-Reply-To: <14508.41276.408855.988727@liveoak.engr.sgi.com>
Message-ID: <Pine.LNX.3.96.1000217174158.908H-100000@caligula.madhouse.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Content-Length: 931
Lines: 24

well all i care about is the R4000 indigos with "elan" graphics.  i just
happen to have a couple of them kicking around the shop.

b

-----------------------------------------------
brett wagner	|	brett@madhouse.org
get committed!	|	http://www.madhouse.org
-----------------------------------------------

On Thu, 17 Feb 2000, William J. Earl wrote:

> brett writes:
>  > Im still wainting to hear anything about the indigo i hear alot of talk
>  > about the indigo2 but nothing about the original blue boxes
> ...
> 
>       The original Indigo was R3000-based.  The I/O is an earlier generation
> of that used in Indy and Indigo2, so some of the driver work could be reused,
> but it is hard to find documentation at this point.  The Indigo R4000
> is pretty close to Indy and Indigo2, so it would not be too hard.  On the
> other hand, there is no work done so far on supporting the "starter" graphics
> on the Indigo R4000.
> 

From rabeeh@galileo.co.il  Thu Feb 17 19:53:31 2000
Received: from galileo5.galileo.co.il ([192.116.246.130]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id TAA11779; Thu, 17 Feb 2000 19:53:29 +0100 (MET)
Received-Date: Thu, 17 Feb 2000 19:53:29 +0100 (MET)
Received: from galileo.co.il (rabeeh@[10.2.20.126])
	by galileo.co.il (8.8.5/8.8.5) with ESMTP id UAA24765
	for <linux-mips@fnet.fr>; Thu, 17 Feb 2000 20:53:42 +0200 (GMT-2)
Sender: rabeeh@galileo.co.il
Message-ID: <38ACA682.DE01FB8C@galileo.co.il>
Date: Thu, 17 Feb 2000 20:55:14 -0500
From: Rabeeh Khoury <rabeeh@galileo.co.il>
X-Mailer: Mozilla 4.51 [en] (X11; I; Linux 2.2.5-15 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: "linux-mips@fnet.fr" <linux-mips@fnet.fr>
Subject: RPM installation
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Length: 309
Lines: 11

Hi All

I'm trying to install RPM on my embedded system over NFS ; when I try
installing some of the RPM's the system starts transmitting endless
lookup requests over the NFS and it doesn't stop. for example the RPM
rootfiles-1.5-3.noarch.rpm

did any one see problem like this in the past ?

thank you
Rabea

From ralf@oss.sgi.com  Fri Feb 18 22:29:27 2000
Received: from mailhost.uni-koblenz.de (mailhost.uni-koblenz.de [141.26.64.1]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id WAA28208; Fri, 18 Feb 2000 22:29:27 +0100 (MET)
Received-Date: Fri, 18 Feb 2000 22:29:27 +0100 (MET)
Received: from cacc-2.uni-koblenz.de (cacc-2.uni-koblenz.de [141.26.131.2])
	by mailhost.uni-koblenz.de (8.9.3/8.9.3) with ESMTP id WAA01864;
	Fri, 18 Feb 2000 22:29:20 +0100 (MET)
Received: by lappi.waldorf-gmbh.de id <S407897AbQBRCxf>;
	Fri, 18 Feb 2000 03:53:35 +0100
Date: Fri, 18 Feb 2000 03:53:35 +0100
From: Ralf Baechle <ralf@oss.sgi.com>
To: brett <brett@madhouse.org>
Cc: Bruce Leggett <bleggett@sofamordanek.com>, linux@cthulhu.engr.sgi.com,
        linux-mips@fnet.fr, linux-mips@vger.rutgers.edu
Subject: Re: Linux on O2?
Message-ID: <20000218035335.F5234@uni-koblenz.de>
References: <BDDC26ED91ACD1118D4E00805F9FDAC3B027F2@broomfield01.sofamordanek.com> <Pine.LNX.3.96.1000217171401.908G-100000@caligula.madhouse.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0pre3us
In-Reply-To: <Pine.LNX.3.96.1000217171401.908G-100000@caligula.madhouse.org>
X-Accept-Language: de,en,fr
Content-Length: 315
Lines: 9

On Thu, Feb 17, 2000 at 05:14:25PM -0800, brett wrote:

> Im still wainting to hear anything about the indigo i hear alot of talk
> about the indigo2 but nothing about the original blue boxes

The problem is that the origin docs are gone by now and SGI can't
just go and ship the IRIX source to hackers ...

  Ralf

From flo@rfc822.org  Fri Feb 18 10:29:46 2000
Received: from noose.gt.owl.de (noose.gt.owl.de [62.52.19.4]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id KAA23960; Fri, 18 Feb 2000 10:29:45 +0100 (MET)
Received-Date: Fri, 18 Feb 2000 10:29:45 +0100 (MET)
Received: by noose.gt.owl.de (Postfix, from userid 10)
	id 99BDF7F5; Fri, 18 Feb 2000 10:29:39 +0100 (CET)
Received: by paradigm.rfc822.org (Postfix, from userid 1000)
	id 09AED8FC4; Fri, 18 Feb 2000 10:25:06 +0100 (CET)
Date: Fri, 18 Feb 2000 10:25:05 +0100
From: Florian Lohoff <flo@rfc822.org>
To: linux@cthulhu.engr.sgi.com, linux-mips@fnet.fr,
        linux-mips@vger.rutgers.edu
Subject: Current cvs kernerl fails to compile for decstation
Message-ID: <20000218102505.B369@paradigm.rfc822.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.95.3i
Organization: rfc822 - pure communication
Sender: flo@rfc822.org
Content-Length: 1125
Lines: 38


On Decstation:


make[3]: Entering directory `/data/kernel/linux/drivers/net'
gcc -D__KERNEL__ -I/data/kernel/linux/include -Wall -Wstrict-prototypes -O2 -fom
it-frame-pointer -G 0 -mno-abicalls -fno-pic -mcpu=r4600 -mips2 -pipe    -DEXPOR
T_SYMTAB -c slhc.c
In file included from slhc.c:74:
/data/kernel/linux/include/net/tcp.h:343: #error HZ != 100 && HZ != 1024.
make[3]: *** [slhc.o] Error 1
make[3]: Leaving directory `/data/kernel/linux/drivers/net'
make[2]: *** [first_rule] Error 2
make[2]: Leaving directory `/data/kernel/linux/drivers/net'
make[1]: *** [_subdir_net] Error 2
make[1]: Leaving directory `/data/kernel/linux/drivers'
make: *** [_dir_drivers] Error 2


------------

#if HZ == 100
#define TCP_TW_RECYCLE_TICK (7+2-TCP_TW_RECYCLE_SLOTS_LOG)
#elif HZ == 1024
#define TCP_TW_RECYCLE_TICK (10+2-TCP_TW_RECYCLE_SLOTS_LOG)
#else
#error HZ != 100 && HZ != 1024.
#endif

-------------

Hrmpf ...

Flo
-- 
Florian Lohoff		flo@rfc822.org		      	+49-5241-470566
"Technology is a constant battle between manufacturers producing bigger and
more idiot-proof systems and nature producing bigger and better idiots."

From raiko@niisi.msk.ru  Fri Feb 18 11:07:55 2000
Received: from t111.niisi.ras.ru (root@t111.niisi.ras.ru [193.232.173.111]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id LAA24173; Fri, 18 Feb 2000 11:07:49 +0100 (MET)
Received-Date: Fri, 18 Feb 2000 11:07:49 +0100 (MET)
Received: from t06.niisi.ras.ru (t06.niisi.ras.ru [193.232.173.6])
	by t111.niisi.ras.ru (8.9.1/8.9.1) with ESMTP id NAA20506;
	Fri, 18 Feb 2000 13:07:59 +0300
Received: (from uucp@localhost) by t06.niisi.ras.ru (8.7.6/8.7.3) with UUCP id NAA01686; Fri, 18 Feb 2000 13:17:39 +0300
Received: from niisi.msk.ru (t34 [193.232.173.34]) by niisi.msk.ru (8.8.8/8.8.8) with ESMTP id NAA02056; Fri, 18 Feb 2000 13:04:06 +0300 (MSK)
Message-ID: <38AD1B65.ED8D9B5D@niisi.msk.ru>
Date: Fri, 18 Feb 2000 13:13:57 +0300
From: "Gleb O. Raiko" <raiko@niisi.msk.ru>
Organization: NIISI RAN
X-Mailer: Mozilla 4.7 [en] (WinNT; I)
X-Accept-Language: en,ru
MIME-Version: 1.0
To: Ralf Baechle <ralf@uni-koblenz.de>
CC: "linux-mips@fnet.fr" <linux-mips@fnet.fr>
Subject: Re: boot memory
References: <38A9D0CB.FF958043@galileo.co.il> <20000216184522.B6252@uni-koblenz.de> <38ABD5D7.8EF12364@niisi.msk.ru> <20000217183835.A5988@uni-koblenz.de>
Content-Type: text/plain; charset=koi8-r
Content-Transfer-Encoding: 7bit
Content-Length: 1179
Lines: 34



Ralf Baechle wrote:
> 
> On Thu, Feb 17, 2000 at 02:04:55PM +0300, Gleb O. Raiko wrote:
> 
> > While we are discussing bootmem allocator, is there any plans to fix the
> > allocator in order to be friendly for initrd on all arches ? Or do you
> > have any ideas how to init bootmem w/o poisoning initrd image ? Call
> > init_bootmem_node/core directly ?
> 
> You won't poison the initrd image.  The {init,free,reserve}_bootmem()
> functions will only change the bootmem bitmap but nothing else.
> 

But initrd image is located just after _end. From
arch/mips/kernel/setup.c

        tmp = (((unsigned long)&_end + PAGE_SIZE-1) & PAGE_MASK) - 8;
        if (tmp < (unsigned long)&_end)
                tmp += PAGE_SIZE;
        initrd_header = (unsigned long *)tmp;
        if (initrd_header[0] == 0x494E5244) {
                initrd_start = (unsigned long)&initrd_header[2];

We call init_bootmem with aligned &_end as start pfn. i.e. the same
address as tmp points to. Then, init_bootmem stores its bitmap exactly
at start pfn and overwrites initrd image. Am I missing the point ?

I think, pointing init_bootmem after initrd image isn't appropriate, is
it ?

Regards,
Gleb.

From ralf@oss.sgi.com  Fri Feb 18 22:29:34 2000
Received: from mailhost.uni-koblenz.de (mailhost.uni-koblenz.de [141.26.64.1]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id WAA28232; Fri, 18 Feb 2000 22:29:33 +0100 (MET)
Received-Date: Fri, 18 Feb 2000 22:29:33 +0100 (MET)
Received: from cacc-2.uni-koblenz.de (cacc-2.uni-koblenz.de [141.26.131.2])
	by mailhost.uni-koblenz.de (8.9.3/8.9.3) with ESMTP id WAA01867;
	Fri, 18 Feb 2000 22:29:22 +0100 (MET)
Received: by lappi.waldorf-gmbh.de id <S407899AbQBRM7H>;
	Fri, 18 Feb 2000 13:59:07 +0100
Date: Fri, 18 Feb 2000 13:59:07 +0100
From: Ralf Baechle <ralf@oss.sgi.com>
To: linux@engr.sgi.com, linux-mips@fnet.fr, linux-mips@vger.rutgers.edu
Subject: copy_from_user() bugfix
Message-ID: <20000218135907.A21082@uni-koblenz.de>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="AqsLC8rIMeq19msA"
X-Mailer: Mutt 1.0pre3us
X-Accept-Language: de,en,fr
Content-Length: 3718
Lines: 128


--AqsLC8rIMeq19msA
Content-Type: text/plain; charset=us-ascii

Appended are two patches, one for Linux 2.2 and one for 2.3, which fix
a bug copy_from_user / __copy_from_user.  When used in a module these
two functions may return a wrong result in the error case.

  Ralf

--AqsLC8rIMeq19msA
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="patch-2.2"

Index: include/asm-mips/uaccess.h
===================================================================
RCS file: /usr/src/cvs/linux/include/asm-mips/uaccess.h,v
retrieving revision 1.16.2.1
diff -u -r1.16.2.1 uaccess.h
--- uaccess.h	1999/10/21 21:26:27	1.16.2.1
+++ uaccess.h	2000/02/18 12:43:41
@@ -322,10 +322,12 @@
 		"move\t$4, %1\n\t" \
 		"move\t$5, %2\n\t" \
 		"move\t$6, %3\n\t" \
+		".set\tnoreorder\n\t" \
 		".set\tnoat\n\t" \
+		__MODULE_JAL(__copy_user) \
 		"addu\t$1, %2, %3\n\t" \
 		".set\tat\n\t" \
-		__MODULE_JAL(__copy_user) \
+		".set\treorder\n\t" \
 		"move\t%0, $6" \
 		: "=r" (__cu_len) \
 		: "r" (__cu_to), "r" (__cu_from), "r" (__cu_len) \
@@ -369,10 +371,12 @@
 			"move\t$4, %1\n\t" \
 			"move\t$5, %2\n\t" \
 			"move\t$6, %3\n\t" \
+			".set\tnoreorder\n\t" \
 			".set\tnoat\n\t" \
+			__MODULE_JAL(__copy_user) \
 			"addu\t$1, %2, %3\n\t" \
 			".set\tat\n\t" \
-			__MODULE_JAL(__copy_user) \
+			".set\treorder\n\t" \
 			"move\t%0, $6" \
 			: "=r" (__cu_len) \
 			: "r" (__cu_to), "r" (__cu_from), "r" (__cu_len) \

--AqsLC8rIMeq19msA
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="patch-2.3"

Index: include/asm-mips/uaccess.h
===================================================================
RCS file: /usr/src/cvs/linux/include/asm-mips/uaccess.h,v
retrieving revision 1.18
diff -u -r1.18 uaccess.h
--- uaccess.h	1999/11/19 20:35:48	1.18
+++ uaccess.h	2000/02/18 12:44:43
@@ -323,10 +323,12 @@
 		"move\t$4, %1\n\t" \
 		"move\t$5, %2\n\t" \
 		"move\t$6, %3\n\t" \
+		".set\tnoreorder\n\t" \
 		".set\tnoat\n\t" \
+		__MODULE_JAL(__copy_user) \
 		"addu\t$1, %2, %3\n\t" \
 		".set\tat\n\t" \
-		__MODULE_JAL(__copy_user) \
+		".set\treorder\n\t" \
 		"move\t%0, $6" \
 		: "=r" (__cu_len) \
 		: "r" (__cu_to), "r" (__cu_from), "r" (__cu_len) \
@@ -370,10 +372,12 @@
 			"move\t$4, %1\n\t" \
 			"move\t$5, %2\n\t" \
 			"move\t$6, %3\n\t" \
+			".set\tnoreorder\n\t" \
 			".set\tnoat\n\t" \
+			__MODULE_JAL(__copy_user) \
 			"addu\t$1, %2, %3\n\t" \
 			".set\tat\n\t" \
-			__MODULE_JAL(__copy_user) \
+			".set\treorder\n\t" \
 			"move\t%0, $6" \
 			: "=r" (__cu_len) \
 			: "r" (__cu_to), "r" (__cu_from), "r" (__cu_len) \
Index: include/asm-mips64/uaccess.h
===================================================================
RCS file: /usr/src/cvs/linux/include/asm-mips64/uaccess.h,v
retrieving revision 1.4
diff -u -r1.4 uaccess.h
--- uaccess.h	1999/11/19 20:35:49	1.4
+++ uaccess.h	2000/02/18 12:48:43
@@ -261,10 +261,12 @@
 		"move\t$4, %1\n\t" \
 		"move\t$5, %2\n\t" \
 		"move\t$6, %3\n\t" \
+		".set\tnoreorder\n\t" \
 		".set\tnoat\n\t" \
-		"addu\t$1, %2, %3\n\t" \
-		".set\tat\n\t" \
 		__MODULE_JAL(__copy_user) \
+		"daddu\t$1, %2, %3\n\t" \
+		".set\tat\n\t" \
+		".set\treorder\n\t" \
 		"move\t%0, $6" \
 		: "=r" (__cu_len) \
 		: "r" (__cu_to), "r" (__cu_from), "r" (__cu_len) \
@@ -308,10 +310,12 @@
 			"move\t$4, %1\n\t" \
 			"move\t$5, %2\n\t" \
 			"move\t$6, %3\n\t" \
+			".set\tnoreorder\n\t" \
 			".set\tnoat\n\t" \
-			"addu\t$1, %2, %3\n\t" \
-			".set\tat\n\t" \
 			__MODULE_JAL(__copy_user) \
+			"daddu\t$1, %2, %3\n\t" \
+			".set\tat\n\t" \
+			".set\treorder\n\t" \
 			"move\t%0, $6" \
 			: "=r" (__cu_len) \
 			: "r" (__cu_to), "r" (__cu_from), "r" (__cu_len) \

--AqsLC8rIMeq19msA--

From rabeeh@galileo.co.il  Fri Feb 18 14:36:39 2000
Received: from galileo5.galileo.co.il ([192.116.246.130]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id OAA25276; Fri, 18 Feb 2000 14:36:35 +0100 (MET)
Received-Date: Fri, 18 Feb 2000 14:36:35 +0100 (MET)
Received: from galileo.co.il ([10.2.3.3])
	by galileo.co.il (8.8.5/8.8.5) with ESMTP id PAA16449;
	Fri, 18 Feb 2000 15:36:02 +0200 (GMT-2)
Message-ID: <38AD4E50.4CB08751@galileo.co.il>
Date: Fri, 18 Feb 2000 15:51:13 +0200
From: Rabeeh Khoury <rabeeh@galileo.co.il>
X-Mailer: Mozilla 4.5 [en] (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Ralf Baechle <ralf@uni-koblenz.de>
CC: "linux-mips@fnet.fr" <linux-mips@fnet.fr>, kossay@galileo.co.il
Subject: Re: RPM installation
References: <38ACA682.DE01FB8C@galileo.co.il> <20000218023406.C5234@uni-koblenz.de>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Length: 1518
Lines: 42

Hi All

The driver can't be broken ; firstly because I built it !!!!! :-) secondly
because only specific RPMs are always stuck ; and I can install other RPM
and do lots of network stuff before every retry.
Can it be that the RPM installer tries performing other stuff than copying
the files in the package and updating it's database in /var/lib/rpm ? maybe
/proc stuff ? or dns or gateways checks ?
other RPM that is stuck is also bash.... - what is in common between bash
and rootfiles RPMs ?


p.s. regarding my former mails about checksum error in kernel 2.0.34 ; the
problem is that I'v used CHECKSUM_HW which returns bad checksum in the udp
layer. Instead we should use CHECKSUM_NONE which performs the right
checksum.
what is the differnce between CHECKSUM_HW and CHECKSUM_NONE ; does
CHECKSUM_NONE makes kernel perform checksum on the 4 octets of the ethernet
packet ?

Regards
    Rabea


Ralf Baechle wrote:

> On Thu, Feb 17, 2000 at 08:55:14PM -0500, Rabeeh Khoury wrote:
>
> > I'm trying to install RPM on my embedded system over NFS ; when I try
> > installing some of the RPM's the system starts transmitting endless
> > lookup requests over the NFS and it doesn't stop. for example the RPM
> > rootfiles-1.5-3.noarch.rpm
> >
> > did any one see problem like this in the past ?
>
> Nope, seems you invented a new bug :-)
>
> Maybe your driver is broken and you're just re-transmitting the same
> requests again and again but the server keeps droping them because
> they corrupted?  Like that.
>
>   Ralf

From niessena@natlab.research.philips.com  Fri Feb 18 16:35:54 2000
Received: from gw-nl4.philips.com (gw-nl4.philips.com [192.68.44.36]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id QAA25861; Fri, 18 Feb 2000 16:35:54 +0100 (MET)
Received-Date: Fri, 18 Feb 2000 16:35:54 +0100 (MET)
Received: from smtprelay-nl1.philips.com (localhost.philips.com [127.0.0.1])
          by gw-nl4.philips.com with ESMTP id QAA25573;
          Fri, 18 Feb 2000 16:35:26 +0100 (MET)
          (envelope-from niessena@natlab.research.philips.com)
Received: from smtprelay-eur1.philips.com(130.139.36.3) by gw-nl4.philips.com via mwrap (4.0a)
	id xma025569; Fri, 18 Feb 00 16:35:45 +0100
Received: from natlab.research.philips.com (prle.natlab.research.philips.com [130.139.161.112]) 
	by smtprelay-nl1.philips.com (8.9.3/8.8.5-1.2.2m-19990317) with SMTP id QAA21351; Fri, 18 Feb 2000 16:35:23 +0100 (MET)
Received: by natlab.research.philips.com; Fri, 18 Feb 2000 16:35:22 +0100
Received: by hpas13.natlab.research.philips.com ; Fri, 18 Feb 2000 16:35:21 +0100 (MET)
Date: Fri, 18 Feb 2000 16:35:21 +0100
From: Arnold Niessen <niessena@natlab.research.philips.com>
To: linux-mips@fnet.fr, kevink@mips.com, carstenl@mips.com,
        linux-porters@algor.co.uk
Subject: Linux on Algorithmics P4032 dev.board
Message-Id: <20000218163521.A21181@hpas13.natlab.research.philips.com>
Reply-To: Arnold.Niessen@philips.com
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.95i
Content-Length: 1379
Lines: 35

Dear Chris, Kevin, and other Linux/MIPS-ers,

I have just started to work on a port of Linux (with 
the intention of RT-Linux in a later stage)
to the Algorithmics P4032-board, based on the newly
released MIPS port for the P5064 and Atlas boards. 
Dominic Sweetman already told me there are more people 
interested in or working on this P4032 port.

I would be obliged if you could help me with
a status overview so far, and where work is still needed
mostly. Although MIPS and P4032 are new to me,
I am surrounded by pSOS-oriented colleagues with lots
of P4032 experience, and I am willing to invest time
in this port.

And to start with a silly question:
So far I have not found a ready-to-use cross compilation
environment; I have just started to build a gcc-2.95.2
mips cross compiler; monday I will try to solve the
first errors which stopped the compilation...
Any pointers (other than the CrossGCC FAQ and gcc doc) that
I should be aware of ?

Best regards,
Arnold.
-- 
A.J. Niessen                  | Philips Research Laboratories
Building WL 1.613             | Prof. Holstlaan 4
Phone: (+31-40-27)42715       | 5656 AA Eindhoven
Fax: (+31-40-27)44004         | The Netherlands
E-Mail:                   arnold.niessen@philips.com
E-Mail on mailing lists:  niessen@iae.nl
E-Mail old (still works): niessena@natlab.research.philips.com
                                 ^

From marc@mucom.co.il  Fri Feb 18 14:07:37 2000
Received: from biff.ibm.net.il (biff.ibm.net.il [192.115.72.164]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id OAA25122; Fri, 18 Feb 2000 14:07:12 +0100 (MET)
Received-Date: Fri, 18 Feb 2000 14:07:12 +0100 (MET)
Received: from moose (host13.mucom.co.il [192.115.216.45])
	by biff.ibm.net.il (Postfix) with ESMTP
	id 469B1121C; Fri, 18 Feb 2000 15:06:38 +0200 (IST)
Date: Fri, 18 Feb 2000 15:05:18 -0200 (GMT+2)
From: Marc Esipovich <marc@mucom.co.il>
To: Florian Lohoff <flo@rfc822.org>
Cc: linux@cthulhu.engr.sgi.com, linux-mips@fnet.fr,
        linux-mips@vger.rutgers.edu
Subject: Re: Current cvs kernerl fails to compile for decstation
In-Reply-To: <20000218102505.B369@paradigm.rfc822.org>
Message-ID: <Pine.LNX.4.20.0002181504271.6252-100000@mucom.co.il>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Content-Length: 395
Lines: 15

> #if HZ == 100
> #define TCP_TW_RECYCLE_TICK (7+2-TCP_TW_RECYCLE_SLOTS_LOG)
> #elif HZ == 1024
> #define TCP_TW_RECYCLE_TICK (10+2-TCP_TW_RECYCLE_SLOTS_LOG)
> #else
> #error HZ != 100 && HZ != 1024.
> #endif
> 

Without looking or knowing the source,  my recommendation is, see where HZ
is defined, and find out why it's not defined as either 100 or 1024, but
you know that already ;)


	Marc.

From <@Cologne.DE:karsten@excalibur.cologne.de>  Fri Feb 18 21:42:35 2000
Received: from fileserv2.Cologne.DE (fileserv2.cologne.de [193.29.188.3]) by guadalquivir.fnet.fr with SMTP (8.8.8/97.02.12/Guadalquivir); id VAA27709; Fri, 18 Feb 2000 21:42:33 +0100 (MET)
Received-Date: Fri, 18 Feb 2000 21:42:33 +0100 (MET)
Received: from localhost (1749 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 <m12LuES-000720C@fileserv2.Cologne.DE>
	for <linux-mips@fnet.fr>; Fri, 18 Feb 2000 21:42:32 +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 TAA04565;
	Fri, 18 Feb 2000 19:10:52 +0100
Message-ID: <20000218191052.A3634@excalibur.cologne.de>
Date: Fri, 18 Feb 2000 19:10:52 +0100
From: Karsten Merker <karsten@excalibur.cologne.de>
To: Arnold.Niessen@philips.com
Cc: linux-mips@fnet.fr
Subject: Re: Linux on Algorithmics P4032 dev.board
Mail-Followup-To: Arnold.Niessen@philips.com, linux-mips@fnet.fr
References: <20000218163521.A21181@hpas13.natlab.research.philips.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.91i
In-Reply-To: <20000218163521.A21181@hpas13.natlab.research.philips.com>; from Arnold Niessen on Fri, Feb 18, 2000 at 04:35:21PM +0100
X-No-Archive: yes
Content-Length: 855
Lines: 21

On Fri, Feb 18, 2000 at 04:35:21PM +0100, Arnold Niessen wrote:

> So far I have not found a ready-to-use cross compilation
> environment; I have just started to build a gcc-2.95.2
> mips cross compiler; monday I will try to solve the
> first errors which stopped the compilation...
> Any pointers (other than the CrossGCC FAQ and gcc doc) that
> I should be aware of ?

Take a look at ftp://bolug.uni-bonn.de/mips/crossdevel/. According to my
knowledge gcc-2.95.2 does not yet work correctly for MIPS, so you will
have to stick with the egcs-1.0.3a- and egcs-1.0.2-packages on
bolug.uni-bonn.de, which contain mips-specific patches.

HTH,
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 ralf@oss.sgi.com  Fri Feb 18 23:30:10 2000
Received: from mailhost.uni-koblenz.de (mailhost.uni-koblenz.de [141.26.64.1]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id XAA28614; Fri, 18 Feb 2000 23:30:09 +0100 (MET)
Received-Date: Fri, 18 Feb 2000 23:30:09 +0100 (MET)
Received: from cacc-2.uni-koblenz.de (cacc-2.uni-koblenz.de [141.26.131.2])
	by mailhost.uni-koblenz.de (8.9.3/8.9.3) with ESMTP id XAA05023;
	Fri, 18 Feb 2000 23:29:59 +0100 (MET)
Received: by lappi.waldorf-gmbh.de id <S407895AbQBRVg2>;
	Fri, 18 Feb 2000 22:36:28 +0100
Date: Fri, 18 Feb 2000 22:36:28 +0100
From: Ralf Baechle <ralf@oss.sgi.com>
To: Florian Lohoff <flo@rfc822.org>
Cc: linux@cthulhu.engr.sgi.com, linux-mips@fnet.fr,
        linux-mips@vger.rutgers.edu
Subject: Re: Current cvs kernerl fails to compile for decstation
Message-ID: <20000218223628.A24098@uni-koblenz.de>
References: <20000218102505.B369@paradigm.rfc822.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0pre3us
In-Reply-To: <20000218102505.B369@paradigm.rfc822.org>
X-Accept-Language: de,en,fr
Content-Length: 727
Lines: 29

On Fri, Feb 18, 2000 at 10:25:05AM +0100, Florian Lohoff wrote:

> #if HZ == 100
> #define TCP_TW_RECYCLE_TICK (7+2-TCP_TW_RECYCLE_SLOTS_LOG)
> #elif HZ == 1024
> #define TCP_TW_RECYCLE_TICK (10+2-TCP_TW_RECYCLE_SLOTS_LOG)
> #else
> #error HZ != 100 && HZ != 1024.
> #endif

How about making that:

#if HZ == 100
#define TCP_TW_RECYCLE_TICK (7+2-TCP_TW_RECYCLE_SLOTS_LOG)
#elif HZ == 64
#define TCP_TW_RECYCLE_TICK (6+2-TCP_TW_RECYCLE_SLOTS_LOG)
#elif HZ == 1024
#define TCP_TW_RECYCLE_TICK (10+2-TCP_TW_RECYCLE_SLOTS_LOG)
#else
#error HZ != 100 && HZ != 1024.
#endif

Without further reading the context that would by my first attempt.

> Hrmpf ...

Imagine, and tomorrow I'm going to break all networking drivers :-)

  Ralf

From ralf@oss.sgi.com  Fri Feb 18 23:29:50 2000
Received: from mailhost.uni-koblenz.de (mailhost.uni-koblenz.de [141.26.64.1]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id XAA28570; Fri, 18 Feb 2000 23:29:50 +0100 (MET)
Received-Date: Fri, 18 Feb 2000 23:29:50 +0100 (MET)
Received: from cacc-2.uni-koblenz.de (cacc-2.uni-koblenz.de [141.26.131.2])
	by mailhost.uni-koblenz.de (8.9.3/8.9.3) with ESMTP id XAA05003;
	Fri, 18 Feb 2000 23:29:45 +0100 (MET)
Received: by lappi.waldorf-gmbh.de id <S407898AbQBRVqJ>;
	Fri, 18 Feb 2000 22:46:09 +0100
Date: Fri, 18 Feb 2000 22:46:09 +0100
From: Ralf Baechle <ralf@oss.sgi.com>
To: Marc Esipovich <marc@mucom.co.il>
Cc: Florian Lohoff <flo@rfc822.org>, linux@cthulhu.engr.sgi.com,
        linux-mips@fnet.fr, linux-mips@vger.rutgers.edu
Subject: Re: Current cvs kernerl fails to compile for decstation
Message-ID: <20000218224609.C24098@uni-koblenz.de>
References: <20000218102505.B369@paradigm.rfc822.org> <Pine.LNX.4.20.0002181504271.6252-100000@mucom.co.il>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0pre3us
In-Reply-To: <Pine.LNX.4.20.0002181504271.6252-100000@mucom.co.il>
X-Accept-Language: de,en,fr
Content-Length: 563
Lines: 18

On Fri, Feb 18, 2000 at 03:05:18PM -0200, Marc Esipovich wrote:

> > #if HZ == 100
> > #define TCP_TW_RECYCLE_TICK (7+2-TCP_TW_RECYCLE_SLOTS_LOG)
> > #elif HZ == 1024
> > #define TCP_TW_RECYCLE_TICK (10+2-TCP_TW_RECYCLE_SLOTS_LOG)
> > #else
> > #error HZ != 100 && HZ != 1024.
> > #endif
> 
> Without looking or knowing the source,  my recommendation is, see where HZ
> is defined, and find out why it's not defined as either 100 or 1024, but
> you know that already ;)

It's 64 because it's not possible to program the DECstation RTC to 100Hz
or 1024Hz.

  Ralf

From brett@madhouse.org  Sat Feb 19 00:26:02 2000
Received: from caligula.madhouse.org ([216.160.90.69]) by guadalquivir.fnet.fr with SMTP (8.8.8/97.02.12/Guadalquivir); id AAA29006; Sat, 19 Feb 2000 00:14:28 +0100 (MET)
Received-Date: Sat, 19 Feb 2000 00:14:28 +0100 (MET)
Received: (qmail 2447 invoked by uid 509); 18 Feb 2000 22:13:11 -0000
Received: from localhost (sendmail-bs@127.0.0.1)
  by localhost with SMTP; 18 Feb 2000 22:13:11 -0000
Date: Fri, 18 Feb 2000 14:13:11 -0800 (PST)
From: brett <brett@madhouse.org>
To: Ralf Baechle <ralf@oss.sgi.com>
cc: Bruce Leggett <bleggett@sofamordanek.com>, linux@cthulhu.engr.sgi.com,
        linux-mips@fnet.fr, linux-mips@vger.rutgers.edu
Subject: Re: Linux on O2?
In-Reply-To: <20000218035335.F5234@uni-koblenz.de>
Message-ID: <Pine.LNX.3.96.1000218141259.2193A-100000@caligula.madhouse.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Content-Length: 622
Lines: 21

why not put a couple of hackers under nda and ship them the source.

b

-----------------------------------------------
brett wagner	|	brett@madhouse.org
get committed!	|	http://www.madhouse.org
-----------------------------------------------

On Fri, 18 Feb 2000, Ralf Baechle wrote:

> On Thu, Feb 17, 2000 at 05:14:25PM -0800, brett wrote:
> 
> > Im still wainting to hear anything about the indigo i hear alot of talk
> > about the indigo2 but nothing about the original blue boxes
> 
> The problem is that the origin docs are gone by now and SGI can't
> just go and ship the IRIX source to hackers ...
> 
>   Ralf
> 

From wje@liveoak.engr.sgi.com  Sat Feb 19 00:33:12 2000
Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id AAA00144; Sat, 19 Feb 2000 00:33:11 +0100 (MET)
Received-Date: Sat, 19 Feb 2000 00:33:11 +0100 (MET)
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id PAA08871; Fri, 18 Feb 2000 15:36:02 -0800 (PST)
	mail_from (wje@liveoak.engr.sgi.com)
Received: from liveoak.engr.sgi.com (liveoak.engr.sgi.com [163.154.5.24])
	by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id PAA72706;
	Fri, 18 Feb 2000 15:33:03 -0800 (PST)
	mail_from (wje@liveoak.engr.sgi.com)
Received: (from wje@localhost)
	by liveoak.engr.sgi.com (8.9.3/8.8.7) id PAA19290;
	Fri, 18 Feb 2000 15:32:58 -0800
X-Authentication-Warning: liveoak.engr.sgi.com: wje set sender to wje@liveoak.engr.sgi.com using -f
From: "William J. Earl" <wje@cthulhu.engr.sgi.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <14509.54953.882688.741736@liveoak.engr.sgi.com>
Date: Fri, 18 Feb 2000 15:32:57 -0800 (PST)
To: Ralf Baechle <ralf@oss.sgi.com>
Cc: brett <brett@madhouse.org>, Bruce Leggett <bleggett@sofamordanek.com>,
        linux@cthulhu.engr.sgi.com, linux-mips@fnet.fr,
        linux-mips@vger.rutgers.edu
Subject: Re: Linux on O2?
In-Reply-To: <20000218035335.F5234@uni-koblenz.de>
References: <BDDC26ED91ACD1118D4E00805F9FDAC3B027F2@broomfield01.sofamordanek.com>
	<Pine.LNX.3.96.1000217171401.908G-100000@caligula.madhouse.org>
	<20000218035335.F5234@uni-koblenz.de>
X-Mailer: VM 6.74 under Emacs 20.3.1
Content-Length: 945
Lines: 20

Ralf Baechle writes:
 > On Thu, Feb 17, 2000 at 05:14:25PM -0800, brett wrote:
 > 
 > > Im still wainting to hear anything about the indigo i hear alot of talk
 > > about the indigo2 but nothing about the original blue boxes
 > 
 > The problem is that the origin docs are gone by now and SGI can't
 > just go and ship the IRIX source to hackers ...

      We might be able to help out with some Indigo R4000 information,
if someone is seriously interested, since the Indigo R4000 is close to
Indigo2 and Indy.  Indigo R3000 is probably hopeless (that development
project was something like 12 years ago, after all).  The graphics is
a tougher problem, since all but Newport and Starter (Indigo) graphics
have geometry engines with relatively complex interfaces.  

     Ralf is quite right about the IRIX source.  Since it is based
on source licensed from SCO, Sun, and others, we do not have the right
to hand it out without cost to others.  


From ralf@oss.sgi.com  Sat Feb 19 01:41:56 2000
Received: from mailhost.uni-koblenz.de (mailhost.uni-koblenz.de [141.26.64.1]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id BAA00675; Sat, 19 Feb 2000 01:41:55 +0100 (MET)
Received-Date: Sat, 19 Feb 2000 01:41:55 +0100 (MET)
Received: from cacc-2.uni-koblenz.de (cacc-2.uni-koblenz.de [141.26.131.2])
	by mailhost.uni-koblenz.de (8.9.3/8.9.3) with ESMTP id BAA09782;
	Sat, 19 Feb 2000 01:41:25 +0100 (MET)
Received: by lappi.waldorf-gmbh.de id <S407895AbQBSADb>;
	Sat, 19 Feb 2000 01:03:31 +0100
Date: Sat, 19 Feb 2000 01:03:31 +0100
From: Ralf Baechle <ralf@oss.sgi.com>
To: "William J. Earl" <wje@cthulhu.engr.sgi.com>
Cc: Ralf Baechle <ralf@oss.sgi.com>, brett <brett@madhouse.org>,
        Bruce Leggett <bleggett@sofamordanek.com>, linux@cthulhu.engr.sgi.com,
        linux-mips@fnet.fr, linux-mips@vger.rutgers.edu
Subject: Re: Linux on O2?
Message-ID: <20000219010331.B19004@uni-koblenz.de>
References: <BDDC26ED91ACD1118D4E00805F9FDAC3B027F2@broomfield01.sofamordanek.com> <Pine.LNX.3.96.1000217171401.908G-100000@caligula.madhouse.org> <20000218035335.F5234@uni-koblenz.de> <14509.54953.882688.741736@liveoak.engr.sgi.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0pre3us
In-Reply-To: <14509.54953.882688.741736@liveoak.engr.sgi.com>
X-Accept-Language: de,en,fr
Content-Length: 1482
Lines: 30

On Fri, Feb 18, 2000 at 03:32:57PM -0800, William J. Earl wrote:

> Ralf Baechle writes:
>  > On Thu, Feb 17, 2000 at 05:14:25PM -0800, brett wrote:
>  > 
>  > > Im still wainting to hear anything about the indigo i hear alot of talk
>  > > about the indigo2 but nothing about the original blue boxes
>  > 
>  > The problem is that the origin docs are gone by now and SGI can't
>  > just go and ship the IRIX source to hackers ...
> 
>       We might be able to help out with some Indigo R4000 information,
> if someone is seriously interested, since the Indigo R4000 is close to
> Indigo2 and Indy.  Indigo R3000 is probably hopeless (that development
> project was something like 12 years ago, after all).  The graphics is
> a tougher problem, since all but Newport and Starter (Indigo) graphics
> have geometry engines with relatively complex interfaces.  
> 
>      Ralf is quite right about the IRIX source.  Since it is based
> on source licensed from SCO, Sun, and others, we do not have the right
> to hand it out without cost to others.  

How about if myself and possibly others who currently are under NDA for SGI
would support such projects by describing things via email where
neither docs nor uncontaminated source is available and possibly some
source where it's (C)-clean and managment aproved.  Could something like
that be made working?  It's a shame that still nobody so far has had an
actual chance to start working on an O2 port or something like that.

  Ralf

From wje@liveoak.engr.sgi.com  Sat Feb 19 04:43:03 2000
Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id EAA03597; Sat, 19 Feb 2000 04:43:02 +0100 (MET)
Received-Date: Sat, 19 Feb 2000 04:43:02 +0100 (MET)
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id TAA00463; Fri, 18 Feb 2000 19:45:54 -0800 (PST)
	mail_from (wje@liveoak.engr.sgi.com)
Received: from liveoak.engr.sgi.com (liveoak.engr.sgi.com [163.154.5.24])
	by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id TAA22751;
	Fri, 18 Feb 2000 19:42:56 -0800 (PST)
	mail_from (wje@liveoak.engr.sgi.com)
Received: (from wje@localhost)
	by liveoak.engr.sgi.com (8.9.3/8.8.7) id TAA03086;
	Fri, 18 Feb 2000 19:42:50 -0800
X-Authentication-Warning: liveoak.engr.sgi.com: wje set sender to wje@liveoak.engr.sgi.com using -f
From: "William J. Earl" <wje@cthulhu.engr.sgi.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Message-ID: <14510.4410.177164.703052@liveoak.engr.sgi.com>
Date: Fri, 18 Feb 2000 19:42:50 -0800 (PST)
To: Ralf Baechle <ralf@oss.sgi.com>
Cc: brett <brett@madhouse.org>, Bruce Leggett <bleggett@sofamordanek.com>,
        linux@cthulhu.engr.sgi.com, linux-mips@fnet.fr,
        linux-mips@vger.rutgers.edu
Subject: Re: Linux on O2?
In-Reply-To: <20000219010331.B19004@uni-koblenz.de>
References: <BDDC26ED91ACD1118D4E00805F9FDAC3B027F2@broomfield01.sofamordanek.com>
	<Pine.LNX.3.96.1000217171401.908G-100000@caligula.madhouse.org>
	<20000218035335.F5234@uni-koblenz.de>
	<14509.54953.882688.741736@liveoak.engr.sgi.com>
	<20000219010331.B19004@uni-koblenz.de>
X-Mailer: VM 6.74 under Emacs 20.3.1
Content-Length: 1400
Lines: 39

Ralf Baechle writes:
...
 > How about if myself and possibly others who currently are under NDA =
for SGI
 > would support such projects by describing things via email where
 > neither docs nor uncontaminated source is available and possibly som=
e
 > source where it's (C)-clean and managment aproved.  Could something =
like
 > that be made working?  It's a shame that still nobody so far has had=
 an
 > actual chance to start working on an O2 port or something like that.=


       That should be ok; we have approval to do so (and I have
sometimes supplied information on that basis), at least for Indigo, Ind=
igo2,
Indy, and Origin.  (There was some question about Octane and Onyx,=A0es=
pecially
in regard to graphics.) =20

       If someone is seriously interested in doing an O2 port, I will h=
elp
with explanations of the major issues, and we can make documentation av=
ailable
under the same restrictions as Indy documentation (no redistribution, n=
o
warranty, documentation is known to be inaccurate in various details). =
=20
As I have described earlier, however, an O2 port is a major undertaking=
.
(It would be quite an interesting and challenging project, but it is
not simple.)

       Again, Indigo documentation, except via the method Ralf suggests=
,
is going to be hard to come by.  The O2 documentation, albeit somewhat
inaccurate, is on the other hand readily available.


From marc@mucom.co.il  Sat Feb 19 05:31:52 2000
Received: from biff.ibm.net.il (biff.ibm.net.il [192.115.72.164]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id FAA05541; Sat, 19 Feb 2000 05:31:51 +0100 (MET)
Received-Date: Sat, 19 Feb 2000 05:31:51 +0100 (MET)
Received: from moose (host13.mucom.co.il [192.115.216.45])
	by biff.ibm.net.il (Postfix) with ESMTP
	id 525921004; Sat, 19 Feb 2000 06:31:43 +0200 (IST)
Date: Sat, 19 Feb 2000 06:30:22 -0200 (GMT+2)
From: Marc Esipovich <marc@mucom.co.il>
To: Ralf Baechle <ralf@oss.sgi.com>
Cc: brett <brett@madhouse.org>, Bruce Leggett <bleggett@sofamordanek.com>,
        linux@cthulhu.engr.sgi.com, linux-mips@fnet.fr,
        linux-mips@vger.rutgers.edu
Subject: Re: Linux on O2?
In-Reply-To: <20000218035335.F5234@uni-koblenz.de>
Message-ID: <Pine.LNX.4.20.0002190629430.7658-100000@mucom.co.il>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Content-Length: 471
Lines: 16


> On Thu, Feb 17, 2000 at 05:14:25PM -0800, brett wrote:
> 
> > Im still wainting to hear anything about the indigo i hear alot of talk
> > about the indigo2 but nothing about the original blue boxes
> 
> The problem is that the origin docs are gone by now and SGI can't
> just go and ship the IRIX source to hackers ...
> 
>   Ralf
> 

Wow, what do you mean gone by now?  are you saying there's no chance in
hell to obtain the documentation?  it can't be gone.

	Marc.

From ralf@uni-koblenz.de  Sat Feb 19 22:43:06 2000
Received: from mailhost.uni-koblenz.de (mailhost.uni-koblenz.de [141.26.64.1]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id WAA20480; Sat, 19 Feb 2000 22:43:05 +0100 (MET)
Received-Date: Sat, 19 Feb 2000 22:43:05 +0100 (MET)
Received: from cacc-10.uni-koblenz.de (cacc-10.uni-koblenz.de [141.26.131.10])
	by mailhost.uni-koblenz.de (8.9.3/8.9.3) with ESMTP id WAA27162;
	Sat, 19 Feb 2000 22:42:49 +0100 (MET)
Received: by lappi.waldorf-gmbh.de id <S407899AbQBSL1O>;
	Sat, 19 Feb 2000 12:27:14 +0100
Date: Sat, 19 Feb 2000 12:27:14 +0100
From: Ralf Baechle <ralf@uni-koblenz.de>
To: Arnold.Niessen@philips.com
Cc: linux-mips@fnet.fr, kevink@mips.com, carstenl@mips.com,
        linux-porters@algor.co.uk
Subject: Re: Linux on Algorithmics P4032 dev.board
Message-ID: <20000219122714.B22339@uni-koblenz.de>
References: <20000218163521.A21181@hpas13.natlab.research.philips.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0pre3us
In-Reply-To: <20000218163521.A21181@hpas13.natlab.research.philips.com>
X-Accept-Language: de,en,fr
Content-Length: 6484
Lines: 134

On Fri, Feb 18, 2000 at 04:35:21PM +0100, Arnold Niessen wrote:

> And to start with a silly question:
> So far I have not found a ready-to-use cross compilation
> environment; I have just started to build a gcc-2.95.2
> mips cross compiler; monday I will try to solve the
> first errors which stopped the compilation...

Do not try to build a Linux kernel based on egcs 2.95.x.  While the
compiler is ok it is known other platforms to overoptimize the kernel
in interesting way.

> Any pointers (other than the CrossGCC FAQ and gcc doc) that
> I should be aware of ?

http://oss.sgi.com/mips/, go to the Linux/MIPS FAQ.  For shrink wrapped
compiler packages here my announcment from Jul 1, 1999 again:

  Ralf

-----BEGIN PGP SIGNED MESSAGE-----

Hi,

I've uploaded new patches to build native and cross binutils and compilers
for mips-linux and mipsel-linux targets for Linux/MIPS on ftp.linux.sgi.com
into /pub/linux/mips/crossdev/src/ rsp.  /pub/linux/mips/crossdev/src/egcs/.

Binaries of binutils and egcs are available for the following types of
hosts are available in /pub/linux/mips/crossdev/

  - Linux/i386 (glibc 2.1 required)
  - Linux/Alpha (glibc 2.0 or newer required)
  - Linux/Sparc (glibc 2.0 or newer required)
  - Linux/PPC (glibc 2.0 or newer required)

Credits for providing the Alpha and Sparc binaries go to Arnaldo Carvalho
de Melo (acme@conectiva.com.br).

Please read the list of changes to the patch files and RPM packages below.

Please report problems ralf@uni-koblenz.de or one of the Linux/MIPS
mailing lists.

  Ralf

Changes to egcs since egcs 1.0.2:

 - Fixed #ident operator to generate .ident, not .string.

 You must upgrade binutils to at least binutils-2.8.1-1.diff before you can
 use or build this compiler.

 You must installed this compiler release if you want to compile modutils;
 previous releases were producing bad code.

Changes to binutils since version binutils-2.8.1-2.diff:

 - TLB instructions are now applied to the same instruction scheduling
   rules as other coprocessor instructions.
 - Rebuilt the binary RPM using the new patch.

 You must upgrade to binutils-2.8.1-2.diff if you wish to compile Linux/MIPS
 kernels for R3000 CPUs.

Changes to binutils since version binutils-2.8.1-1.diff:

 - Fix the .ident pseudo op in gas to handle sections correctly.

 You must upgrade to at least this version before you want to upgrade
 to egcs-1.0.3a.diff.

66f22d90c7bdbf77035f35a4cffa0e63  binutils-2.8.1-3.diff.gz
24906a53ab1abc105256d29e4928a77e  binutils-mips-linux-2.8.1-1.alpha.rpm
331bbbe37ec6005a429d8e5886ccba1c  binutils-mipsel-linux-2.8.1-1.alpha.rpm
17c1a924b4934040e6a5d0f7eef42278  binutils-mips-linux-2.8.1-1.i386.rpm
1e45a295ec695b241434332721144b1e  binutils-mipsel-linux-2.8.1-1.i386.rpm
c3214c60813f045e72ca2162a23c717e  binutils-mips-linux-2.8.1-1.ppc.rpm
30652af3c6d6daf390f1c8b682dcdbde  binutils-mipsel-linux-2.8.1-1.ppc.rpm
289f49618cb1fd122c0a1080575e30b8  binutils-mips-linux-2.8.1-1.sparc.rpm
489e2e34bf8d1671645b85fb3c630f68  binutils-mipsel-linux-2.8.1-1.sparc.rpm
ef30d241f81c13cf443631bcd5ab1914  cross-binutils-2.8.1-1.src.rpm
e64f9950999f3e0850ba7f73e65b75e5  cross-egcs-1.0.3a-1.src.rpm
5f57e092d9b5f221054332fc039dc4ff  egcs-1.0.3a-2.diff.gz
04b9084199eb234b588ae8fcdb930dac  egcs-c++-mips-linux-1.0.3a-1.alpha.rpm
f10ddf2c07d2fd36ad02bed7a3e3acc7  egcs-c++-mipsel-linux-1.0.3a-1.alpha.rpm
bbcfe6b7b1594d639156b90687fb4a5c  egcs-g77-mips-linux-1.0.3a-1.alpha.rpm
1ccb88ad648f1ee762f45788e4a61e79  egcs-g77-mipsel-linux-1.0.3a-1.alpha.rpm
67af9cea602b93b6d125e569a3f938b3  egcs-libstdc++-mips-linux-2.8.0-1.alpha.rpm
f0d2a5c19cbaf63859405f725f41818b  egcs-libstdc++-mipsel-linux-2.8.0-1.alpha.rpm
e3bf275316b98adb6367304d9db01a1d  egcs-mips-linux-1.0.3a-1.alpha.rpm
1ae65785a9deb0cdedb5a656ade821c4  egcs-mipsel-linux-1.0.3a-1.alpha.rpm
720e571214f8d9ba05a998a10704af6b  egcs-objc-mips-linux-1.0.3a-1.alpha.rpm
32bc3f37365483d5b65bd1aa4c8e0876  egcs-objc-mipsel-linux-1.0.3a-1.alpha.rpm
3d0dc466d92175c121300bdef4881a33  egcs-c++-mips-linux-1.0.3a-1.i386.rpm
c4272a37fe8e57b3f9bb8be738274836  egcs-c++-mipsel-linux-1.0.3a-1.i386.rpm
c0de740218490e1b5256c002df724e9e  egcs-g77-mips-linux-1.0.3a-1.i386.rpm
9d539da26bb07b7edca4c2106cb23d3a  egcs-g77-mipsel-linux-1.0.3a-1.i386.rpm
e6bd26ab57563f6d6e854325728fe3f2  egcs-libstdc++-mips-linux-2.8.0-1.i386.rpm
42300569bb1356d4c3209006700f1c6a  egcs-libstdc++-mipsel-linux-2.8.0-1.i386.rpm
9d69a4a9bb481ff8bde126b58e13f184  egcs-mips-linux-1.0.3a-1.i386.rpm
a84256a9295121d8042e0a5a8f1127ea  egcs-mipsel-linux-1.0.3a-1.i386.rpm
e5583f2486e5a87e4715e2a0757f316d  egcs-objc-mips-linux-1.0.3a-1.i386.rpm
0a1d9166d05c40fe242ebf3e8e4c9d67  egcs-objc-mipsel-linux-1.0.3a-1.i386.rpm
f0f1d54a00c61541326d7a9c6fabd856  egcs-c++-mips-linux-1.0.3a-1.ppc.rpm
f28e90e7bf2494be0c55d85a15ed7763  egcs-c++-mipsel-linux-1.0.3a-1.ppc.rpm
ee7eb7f1bb1a24ba024ef6b16eb140d1  egcs-g77-mips-linux-1.0.3a-1.ppc.rpm
599424fb7cb8c6f9c665b4724be07bc8  egcs-g77-mipsel-linux-1.0.3a-1.ppc.rpm
bf4a42ed26188fd3deaceeaf864d7765  egcs-libstdc++-mips-linux-2.8.0-1.ppc.rpm
770888f1c4c2882c9e5d1c6627c3ab81  egcs-libstdc++-mipsel-linux-2.8.0-1.ppc.rpm
be4bf0ac5d0804fcd6a31ec88cfe651e  egcs-mips-linux-1.0.3a-1.ppc.rpm
679de1a46ea47ef7a829e6abcb47a257  egcs-mipsel-linux-1.0.3a-1.ppc.rpm
3ab9e864b8b3d58bcac6c07fa7363daf  egcs-objc-mips-linux-1.0.3a-1.ppc.rpm
c48aaeabd8b7373ee8fd3b358fa0869c  egcs-objc-mipsel-linux-1.0.3a-1.ppc.rpm
f5dacd4ad42184f57a8cff6ea650e4be  egcs-c++-mips-linux-1.0.3a-1.sparc.rpm
09f2301fc208bf434fb83c6ccebe9752  egcs-c++-mipsel-linux-1.0.3a-1.sparc.rpm
dd9630b77a2ec7fa057da244040b4d6d  egcs-g77-mips-linux-1.0.3a-1.sparc.rpm
26c01a32ec26cbc1746bca05c9726e3b  egcs-g77-mipsel-linux-1.0.3a-1.sparc.rpm
f6c2debe62d93ddedf95a91ee98805fb  egcs-libstdc++-mips-linux-2.8.0-1.sparc.rpm
3da0d34a7420762c75fe477416451b71  egcs-libstdc++-mipsel-linux-2.8.0-1.sparc.rpm2ab9227097946bfbd4e795a07cad82a1  egcs-mips-linux-1.0.3a-1.sparc.rpm
0f19e28546a185da5969442a6d35b495  egcs-mipsel-linux-1.0.3a-1.sparc.rpm
6cdcfe0d1b52d3fd033c64a289ee4836  egcs-objc-mips-linux-1.0.3a-1.sparc.rpm
32ca712e0aa483520afe39b87b0fc6ab  egcs-objc-mipsel-linux-1.0.3a-1.sparc.rpm

-----BEGIN PGP SIGNATURE-----
Version: 2.6.3i
Charset: latin1

iQCVAwUBN3qbV0ckbl6vezDBAQGUsgP9F1VrQQELRKgm5SuVG7z13235ZgBmRnhA
dYkE9NQMY798XedAnuf7SmZZGeaqYivM1/td8AXaDG8gueMcAzOoIkNhdeOGBVj2
L7CilWqpW60iMdTsjbXYT+azD4/xAB8CoBnK7hgEeZIqkEgTXfxPuOeb8G+2NAGc
QpMp1L5xE+k=
=Spnq
-----END PGP SIGNATURE-----

From Harald.Koerfgen@home.ivm.de  Sat Feb 19 13:26:42 2000
Received: from mail.ivm.net (mail.ivm.net [62.204.1.4]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id NAA10217; Sat, 19 Feb 2000 13:26:41 +0100 (MET)
Received-Date: Sat, 19 Feb 2000 13:26:41 +0100 (MET)
Received: from franz.no.dom (port33.duesseldorf.ivm.de [195.247.65.33])
	by mail.ivm.net (8.8.8/8.8.8) with ESMTP id NAA02745;
	Sat, 19 Feb 2000 13:26:14 +0100
X-To: linux-mips@fnet.fr
Message-ID: <XFMail.000219132654.Harald.Koerfgen@home.ivm.de>
X-Mailer: XFMail 1.3 [p0] on Linux
X-Priority: 3 (Normal)
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
In-Reply-To: <20000218224609.C24098@uni-koblenz.de>
Date: Sat, 19 Feb 2000 13:26:54 +0100 (MET)
Reply-To: "Harald Koerfgen" <Harald.Koerfgen@home.ivm.de>
Organization: none
Sender: harry@franz.no.dom
From: Harald Koerfgen <Harald.Koerfgen@home.ivm.de>
To: Ralf Baechle <ralf@oss.sgi.com>
Subject: Re: Current cvs kernerl fails to compile for decstation
Cc: linux-mips@vger.rutgers.edu, linux-mips@fnet.fr,
        linux@cthulhu.engr.sgi.com, Florian Lohoff <flo@rfc822.org>,
        Marc Esipovich <marc@mucom.co.il>
Content-Length: 673
Lines: 26


On 18-Feb-00 Ralf Baechle wrote:
> On Fri, Feb 18, 2000 at 03:05:18PM -0200, Marc Esipovich wrote:
> 
>> > #if HZ == 100
>> > #define TCP_TW_RECYCLE_TICK (7+2-TCP_TW_RECYCLE_SLOTS_LOG)
>> > #elif HZ == 1024
>> > #define TCP_TW_RECYCLE_TICK (10+2-TCP_TW_RECYCLE_SLOTS_LOG)
>> > #else
>> > #error HZ != 100 && HZ != 1024.
>> > #endif

Well, I changed that to 
#if HZ == 100 || HZ == 128

HZ has been changed to 128 somewhere in the early 2.3.x series...

> It's 64 because it's not possible to program the DECstation RTC to 100Hz
> or 1024Hz.

Well, 1024 Hz would be possible but certainly total overkill for a DECstation
2100 with a 12.5 Mhz R2000 :-)

---
Regards,
Harald

From Harald.Koerfgen@home.ivm.de  Sat Feb 19 13:29:17 2000
Received: from mail.ivm.net (mail.ivm.net [62.204.1.4]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id NAA10679; Sat, 19 Feb 2000 13:29:16 +0100 (MET)
Received-Date: Sat, 19 Feb 2000 13:29:16 +0100 (MET)
Received: from franz.no.dom (port88.duesseldorf.ivm.de [195.247.65.88])
	by mail.ivm.net (8.8.8/8.8.8) with ESMTP id NAA02870;
	Sat, 19 Feb 2000 13:29:06 +0100
X-To: linux-mips@fnet.fr
Message-ID: <XFMail.000219132946.Harald.Koerfgen@home.ivm.de>
X-Mailer: XFMail 1.3 [p0] on Linux
X-Priority: 3 (Normal)
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
In-Reply-To: <20000219010331.B19004@uni-koblenz.de>
Date: Sat, 19 Feb 2000 13:29:46 +0100 (MET)
Reply-To: "Harald Koerfgen" <Harald.Koerfgen@home.ivm.de>
Organization: none
Sender: harry@franz.no.dom
From: Harald Koerfgen <Harald.Koerfgen@home.ivm.de>
To: Ralf Baechle <ralf@oss.sgi.com>
Subject: Re: Linux on O2?
Cc: linux-mips@vger.rutgers.edu, linux-mips@fnet.fr,
        linux@cthulhu.engr.sgi.com, Bruce Leggett <bleggett@sofamordanek.com>,
        brett <brett@madhouse.org>,
        "William J. Earl" <wje@cthulhu.engr.sgi.com>
Content-Length: 1639
Lines: 36


On 19-Feb-00 Ralf Baechle wrote:
> On Fri, Feb 18, 2000 at 03:32:57PM -0800, William J. Earl wrote:
> 
>> Ralf Baechle writes:
>>  > On Thu, Feb 17, 2000 at 05:14:25PM -0800, brett wrote:
>>  > 
>>  > > Im still wainting to hear anything about the indigo i hear alot of talk
>>  > > about the indigo2 but nothing about the original blue boxes
>>  > 
>>  > The problem is that the origin docs are gone by now and SGI can't
>>  > just go and ship the IRIX source to hackers ...
>> 
>>       We might be able to help out with some Indigo R4000 information,
>> if someone is seriously interested, since the Indigo R4000 is close to
>> Indigo2 and Indy.  Indigo R3000 is probably hopeless (that development
>> project was something like 12 years ago, after all).  The graphics is
>> a tougher problem, since all but Newport and Starter (Indigo) graphics
>> have geometry engines with relatively complex interfaces.  
>> 
>>      Ralf is quite right about the IRIX source.  Since it is based
>> on source licensed from SCO, Sun, and others, we do not have the right
>> to hand it out without cost to others.  
> 
> How about if myself and possibly others who currently are under NDA for SGI
> would support such projects by describing things via email where
> neither docs nor uncontaminated source is available and possibly some
> source where it's (C)-clean and managment aproved.  Could something like
> that be made working?  It's a shame that still nobody so far has had an
> actual chance to start working on an O2 port or something like that.

Well, if someone is willing to ship me an O2 I'll see what I can do :-)

---
Regards,
Harald

From mh@cs.tu-berlin.de  Sat Feb 19 15:12:56 2000
Received: from mail.cs.tu-berlin.de (root@mail.cs.tu-berlin.de [130.149.17.13]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id PAA13311; Sat, 19 Feb 2000 15:12:55 +0100 (MET)
Received-Date: Sat, 19 Feb 2000 15:12:55 +0100 (MET)
Received: from elverum.cs.tu-berlin.de (mh@elverum.cs.tu-berlin.de [130.149.17.27])
	by mail.cs.tu-berlin.de (8.9.3/8.9.3) with ESMTP id PAA00848;
	Sat, 19 Feb 2000 15:03:18 +0100 (MET)
From: Matthias Heidbrink <mh@cs.tu-berlin.de>
Received: (from mh@localhost)
	by elverum.cs.tu-berlin.de (8.9.3/8.9.3) id PAA07765;
	Sat, 19 Feb 2000 15:03:16 +0100 (MET)
Message-Id: <200002191403.PAA07765@elverum.cs.tu-berlin.de>
Subject: Re: Current cvs kernerl fails to compile for decstation
In-Reply-To: <XFMail.000219132654.Harald.Koerfgen@home.ivm.de> from Harald Koerfgen
 at "Feb 19, 2000 01:26:54 pm"
To: Harald Koerfgen <Harald.Koerfgen@home.ivm.de>
Date: Sat, 19 Feb 2000 15:03:16 +0100 (MET)
CC: linux-mips@fnet.fr
X-Mailer: ELM [version 2.4ME+ PL60 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 1511
Lines: 32

Hallo Harald,

> > It's 64 because it's not possible to program the DECstation RTC to 100Hz
> > or 1024Hz.
> 
> Well, 1024 Hz would be possible but certainly total overkill for a DECstation
> 2100 with a 12.5 Mhz R2000 :-)

I remember that problems with these "odd" 64 Hz have been discussed on this 
list several times before. Maybe it would not be such a bad idea to go to a
"standard" value.                                                          

How expensive is the interrupt handler for the timer, I mean, how large would
the loss in performance be when going to 1024 Hz?                   

Or would it make sense to modify the clock setup and interrupt handler to run
the clock with 1024 Hz, but run the complete timer interrupt handling code
only every 10 ms/at 100Hz (in average)?                               

I used this method some years ago under DOS because my application required
a fine timer resolution and DOS required a timer interrupt every 55ms.
On a 386-33 (which should be roughly equivalent in performance to an old MIPS
CPU with a bit less than half of the clock speed) it showed no remarkable loss
in performence. Even quite the opposite because the application that had some
delays in it ran smoother because of the finer granularity of the delays.

Ciao, Matthias
-- 
Matthias Heidbrink     E-Mail: 
Bundesratufer 12       Matthias_Heidbrink@b.maus.de  
10555 Berlin, Germany  mh@cs.tu-berlin.de         
Tel. +49-30-8536361    mh@carano.de   (at work; http://www.carano.com)

From spock@mgnet.de  Sat Feb 19 16:16:13 2000
Received: from obelix.hrz.tu-chemnitz.de (obelix.hrz.tu-chemnitz.de [134.109.132.55]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id QAA14061; Sat, 19 Feb 2000 16:16:12 +0100 (MET)
Received-Date: Sat, 19 Feb 2000 16:16:12 +0100 (MET)
Received: from sunnyboy.informatik.tu-chemnitz.de by obelix.hrz.tu-chemnitz.de 
          with Local SMTP (PP); Sat, 19 Feb 2000 16:15:39 +0100
Received: from scotty.mgnet.de (stampede.csn.tu-chemnitz.de [134.109.96.133]) 
          by sunnyboy.informatik.tu-chemnitz.de (8.8.8/8.8.8) with SMTP 
          id QAA07017 for <linux-mips@fnet.fr>;
          Sat, 19 Feb 2000 16:15:37 +0100 (MET)
Message-Id: <200002191515.QAA07017@sunnyboy.informatik.tu-chemnitz.de>
Received: (qmail 6379 invoked from network); 19 Feb 2000 15:15:30 -0000
Received: from spock.mgnet.de (192.168.1.4) by scotty.mgnet.de with SMTP;
          19 Feb 2000 15:15:30 -0000
Date: Sat, 19 Feb 2000 16:15:37 CET
From: Klaus Naumann <spock@mgnet.de>
To: linux-mips@fnet.fr
Subject: Bug in timex.h
Reply-To: spock@mgnet.de
X-Mailer: Spruce 0.5.16 for X11 w/smtpio 0.7.3
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="spruceBYXTSDUBBJTFZKFDYEQY"
Content-Length: 1592
Lines: 40


This is a multi-part message in MIME format.

--spruceBYXTSDUBBJTFZKFDYEQY
Content-Type: text/plain
Content-Transfer-Type: 8bit


Hi,

while compiling glibc (cross compile) I think I encountered a bug in 
include/asm-mips/timex.h .
It uses the define CP0_COUNT and the function read_32bit_cp0_register()
which are defined in mipsregs.h . But the timex.h does _not_
include this file. At least my compiler complained about undefined 
CP0_COUNT. I've appended a patch for the problem (Well, I 
hope it's fixing the problem in a correct way ;) ).

	Later , Klaus

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

--spruceBYXTSDUBBJTFZKFDYEQY
Content-Type: application/octet-stream; name="timex.h.diff"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="timex.h.diff"

LS0tIHRpbWV4Lmgub3JpZwlTYXQgRmViIDE5IDE2OjA4OjE3IDIwMDAKKysrIHRpbWV4LmgJU2F0
IEZlYiAxOSAxNjowOTo0NiAyMDAwCkBAIC0xMSw2ICsxMSwxMCBAQAogI2lmbmRlZiBfX0FTTV9N
SVBTX1RJTUVYX0gKICNkZWZpbmUgX19BU01fTUlQU19USU1FWF9ICiAKKyNpZm5kZWYgX19BU01f
TUlQU19NSVBTUkVHU19ICisjaW5jbHVkZSA8YXNtL21pcHNyZWdzLmg+CisjZW5kaWYKKwogI2Rl
ZmluZSBDTE9DS19USUNLX1JBVEUJMTE5MzE4MCAvKiBVbmRlcmx5aW5nIEhaICovCiAjZGVmaW5l
IENMT0NLX1RJQ0tfRkFDVE9SCTIwCS8qIEZhY3RvciBvZiBib3RoIDEwMDAwMDAgYW5kIENMT0NL
X1RJQ0tfUkFURSAqLwogI2RlZmluZSBGSU5FVFVORSAoKCgoKChsb25nKUxBVENIICogSFogLSBD
TE9DS19USUNLX1JBVEUpIDw8IFNISUZUX0haKSAqIFwK
--spruceBYXTSDUBBJTFZKFDYEQY--

From brianm@moffetimages.com  Sat Feb 19 22:04:19 2000
Received: from moffetimages.com (alar.scruz.predictive.com [207.251.1.130]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id WAA19752; Sat, 19 Feb 2000 22:04:17 +0100 (MET)
Received-Date: Sat, 19 Feb 2000 22:04:17 +0100 (MET)
Received: from brianm.moffetimages.com (dhcp8.moffetimages.com [10.0.1.8])
	by moffetimages.com (8.9.3/8.9.3) with SMTP id NAA18338;
	Sat, 19 Feb 2000 13:04:48 -0800 (PST)
	(envelope-from brianm@moffetimages.com)
Message-Id: <3.0.5.32.20000219130000.007af280@orac.moffetimages.com>
X-Sender: brianm@orac.moffetimages.com
X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.5 (32)
Date: Sat, 19 Feb 2000 13:00:00 -0800
To: "Harald Koerfgen" <Harald.Koerfgen@home.ivm.de>,
        Ralf Baechle <ralf@oss.sgi.com>
From: "Brian D. Moffet" <brianm@moffetimages.com>
Subject: Re: Linux on O2?
Cc: linux-mips@vger.rutgers.edu, linux-mips@fnet.fr,
        linux@cthulhu.engr.sgi.com, Bruce Leggett <bleggett@sofamordanek.com>,
        brett <brett@madhouse.org>,
        "William J. Earl" <wje@cthulhu.engr.sgi.com>
In-Reply-To: <XFMail.000219132946.Harald.Koerfgen@home.ivm.de>
References: <20000219010331.B19004@uni-koblenz.de>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Length: 478
Lines: 14

At 01:29 PM 2/19/00 +0100, Harald Koerfgen wrote:

>Well, if someone is willing to ship me an O2 I'll see what I can do :-)

I own an O2, and would be willing to work on a port, once my life gets more
free
time... :-)  Of course I would need to get as much hardware doc as possible,
but my time isn't gonna free up for at least another 6 - 9 months, probably 
longer...

Brian

Brian D. Moffet		www.moffetimages.com
brianm@ricochet.net	photographer, pilot, musician, programmer

From 1n15@1n15bz.net  Sat Feb 19 23:40:27 2000
Received: from yuhosha.co.jp (fortknox.yuhosha.co.jp [210.254.19.162]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id XAA21391; Sat, 19 Feb 2000 23:40:25 +0100 (MET)
Received-Date: Sat, 19 Feb 2000 23:40:25 +0100 (MET)
From: 1n15@1n15bz.net
Received: from cen.bellsouth.net (localhost [127.0.0.1])
	by yuhosha.co.jp (8.8.7/8.8.7) with SMTP id HAA03057;
	Sun, 20 Feb 2000 07:41:25 +0900 (GMT-9)
Date: Sun, 20 Feb 2000 07:41:25 +0900 (GMT-9)
Message-Id: <200002192241.HAA03057@yuhosha.co.jp>
To: hello56@eastmail.com
Subject: if under 21 please delete
MIME-Version: 1.0
Content-Type: text/plain; charset=unknown-8bit
Content-Length: 600
Lines: 20


 Fantasy Escape

For ultra-explicit pictures in every imaginable category..
 To get up close and personal with thousands of live video feeds..
 For live interaction with our Internet models..
 For stories that make your mind spin..
 For material that's a little off the beaten track..
 To become a secret spy using voyeurvision..
 To explore places you have never seen before with our toycam or
 dildovision..
 To nurture your dominant (or submissive side)..

 visit us at http://www.youngandsexy.com  where you wildest fantasies become
 reality!

WhiteHorse Mailing Service
Charlestown
Nevis, BWI


From ralf@oss.sgi.com  Sun Feb 20 00:44:30 2000
Received: from mailhost.uni-koblenz.de (mailhost.uni-koblenz.de [141.26.64.1]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id AAA23243; Sun, 20 Feb 2000 00:44:29 +0100 (MET)
Received-Date: Sun, 20 Feb 2000 00:44:29 +0100 (MET)
Received: from cacc-10.uni-koblenz.de (cacc-10.uni-koblenz.de [141.26.131.10])
	by mailhost.uni-koblenz.de (8.9.3/8.9.3) with ESMTP id AAA01473;
	Sun, 20 Feb 2000 00:44:18 +0100 (MET)
Received: by lappi.waldorf-gmbh.de id <S407899AbQBSXOp>;
	Sun, 20 Feb 2000 00:14:45 +0100
Date: Sun, 20 Feb 2000 00:14:45 +0100
From: Ralf Baechle <ralf@oss.sgi.com>
To: Marc Esipovich <marc@mucom.co.il>
Cc: Ralf Baechle <ralf@oss.sgi.com>, brett <brett@madhouse.org>,
        Bruce Leggett <bleggett@sofamordanek.com>, linux@cthulhu.engr.sgi.com,
        linux-mips@fnet.fr, linux-mips@vger.rutgers.edu
Subject: Re: Linux on O2?
Message-ID: <20000220001445.B23993@uni-koblenz.de>
References: <20000218035335.F5234@uni-koblenz.de> <Pine.LNX.4.20.0002190629430.7658-100000@mucom.co.il>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0pre3us
In-Reply-To: <Pine.LNX.4.20.0002190629430.7658-100000@mucom.co.il>
X-Accept-Language: de,en,fr
Content-Length: 1376
Lines: 29

On Sat, Feb 19, 2000 at 06:30:22AM -0200, Marc Esipovich wrote:

> > > Im still wainting to hear anything about the indigo i hear alot of talk
> > > about the indigo2 but nothing about the original blue boxes
> > 
> > The problem is that the origin docs are gone by now and SGI can't
> > just go and ship the IRIX source to hackers ...
> 
> Wow, what do you mean gone by now?  are you saying there's no chance in
> hell to obtain the documentation?  it can't be gone.

Remember that SGI is a company that designs a large fraction of a system.
So the designers of some piece of hardware and it's direct users, the
kernel programmers have close to each other.  For a lot of chips
documentation never is written or at least never the same way so it would
be the case for chips that would be marketed as such.  It's obvious that
this isn't good at all for Free Software where the access to high
quality documentation is crucial.

So now imagine what has happened to all the knowledge about a machine
during the decade after it was developed?  The product's development
finishes, it get's marketed, the OS for gets some final bugfixes and
even later it gets phased out.  Silence.  Meanwhile the brains behind
the machine leave the company, tapes and paper go to some dark room
where nobody still remembers them and the machine gets forgotten.

Slow death of a computer ...

  Ralf

From bhalchin@hotmail.com  Sun Feb 20 01:29:35 2000
Received: from hotmail.com (f196.law3.hotmail.com [209.185.241.196]) by guadalquivir.fnet.fr with SMTP (8.8.8/97.02.12/Guadalquivir); id BAA24000; Sun, 20 Feb 2000 01:29:33 +0100 (MET)
Received-Date: Sun, 20 Feb 2000 01:29:33 +0100 (MET)
Received: (qmail 38071 invoked by uid 0); 20 Feb 2000 00:29:01 -0000
Message-ID: <20000220002901.38070.qmail@hotmail.com>
Received: from 207.46.125.16 by www.hotmail.com with HTTP;	Sat, 19 Feb 2000 16:29:01 PST
X-Originating-IP: [207.46.125.16]
From: "Bill Halchin" <bhalchin@hotmail.com>
To: ralf@oss.sgi.com, marc@mucom.co.il
Cc: brett@madhouse.org, bleggett@sofamordanek.com, linux@cthulhu.engr.sgi.com,
        linux-mips@fnet.fr, linux-mips@vger.rutgers.edu
Subject: Re: Linux on O2?
Date: Sat, 19 Feb 2000 16:29:01 PST
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Content-Length: 2261
Lines: 54

This is precisely why I gave up on this project. I could not get any
documentation, no machine access (if you don't already have). In my
opinion, SGI Linux project must address this problem if they want to
attract "outsiders", i.e. people who are currently outside the SGI
user community, but what to contribute to a very interesting (!!)Open
Source project.


Regards,

Bill Halchin


>From: Ralf Baechle <ralf@oss.sgi.com>
>To: Marc Esipovich <marc@mucom.co.il>
>CC: Ralf Baechle <ralf@oss.sgi.com>, brett <brett@madhouse.org>,        
>Bruce Leggett <bleggett@sofamordanek.com>, linux@cthulhu.engr.sgi.com,      
>   linux-mips@fnet.fr, linux-mips@vger.rutgers.edu
>Subject: Re: Linux on O2?
>Date: Sun, 20 Feb 2000 00:14:45 +0100
>
>On Sat, Feb 19, 2000 at 06:30:22AM -0200, Marc Esipovich wrote:
>
> > > > Im still wainting to hear anything about the indigo i hear alot of 
>talk
> > > > about the indigo2 but nothing about the original blue boxes
> > >
> > > The problem is that the origin docs are gone by now and SGI can't
> > > just go and ship the IRIX source to hackers ...
> >
> > Wow, what do you mean gone by now?  are you saying there's no chance in
> > hell to obtain the documentation?  it can't be gone.
>
>Remember that SGI is a company that designs a large fraction of a system.
>So the designers of some piece of hardware and it's direct users, the
>kernel programmers have close to each other.  For a lot of chips
>documentation never is written or at least never the same way so it would
>be the case for chips that would be marketed as such.  It's obvious that
>this isn't good at all for Free Software where the access to high
>quality documentation is crucial.
>
>So now imagine what has happened to all the knowledge about a machine
>during the decade after it was developed?  The product's development
>finishes, it get's marketed, the OS for gets some final bugfixes and
>even later it gets phased out.  Silence.  Meanwhile the brains behind
>the machine leave the company, tapes and paper go to some dark room
>where nobody still remembers them and the machine gets forgotten.
>
>Slow death of a computer ...
>
>   Ralf

______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com

From ralf@oss.sgi.com  Sun Feb 20 02:02:42 2000
Received: from mailhost.uni-koblenz.de (mailhost.uni-koblenz.de [141.26.64.1]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id CAA24793; Sun, 20 Feb 2000 02:02:37 +0100 (MET)
Received-Date: Sun, 20 Feb 2000 02:02:37 +0100 (MET)
Received: from cacc-10.uni-koblenz.de (cacc-10.uni-koblenz.de [141.26.131.10])
	by mailhost.uni-koblenz.de (8.9.3/8.9.3) with ESMTP id CAA01181;
	Sun, 20 Feb 2000 02:02:22 +0100 (MET)
Received: by lappi.waldorf-gmbh.de id <S407895AbQBTBBg>;
	Sun, 20 Feb 2000 02:01:36 +0100
Date: Sun, 20 Feb 2000 02:01:36 +0100
From: Ralf Baechle <ralf@oss.sgi.com>
To: Bill Halchin <bhalchin@hotmail.com>
Cc: marc@mucom.co.il, brett@madhouse.org, bleggett@sofamordanek.com,
        linux@cthulhu.engr.sgi.com, linux-mips@fnet.fr,
        linux-mips@vger.rutgers.edu
Subject: Re: Linux on O2?
Message-ID: <20000220020136.A25065@uni-koblenz.de>
References: <20000220002901.38070.qmail@hotmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0pre3us
In-Reply-To: <20000220002901.38070.qmail@hotmail.com>
X-Accept-Language: de,en,fr
Content-Length: 755
Lines: 19

On Sat, Feb 19, 2000 at 04:29:01PM -0800, Bill Halchin wrote:

> This is precisely why I gave up on this project. I could not get any
> documentation, no machine access (if you don't already have). In my
> opinion, SGI Linux project must address this problem if they want to
> attract "outsiders", i.e. people who are currently outside the SGI
> user community, but what to contribute to a very interesting (!!)Open
> Source project.

You should consider that that porting Linus to all of SGI's machines is a
pretty unrealistic project so with all optimism I don't think it's going
to happen.

Aside of that, SGI's Linux efforts are primarily about the future, not
the past and that's good so.

(Time to mention that I'm not speaking for SGI ...)

  Ralf

From ralf@uni-koblenz.de  Sun Feb 20 04:06:36 2000
Received: from mailhost.uni-koblenz.de (mailhost.uni-koblenz.de [141.26.64.1]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id EAA29051; Sun, 20 Feb 2000 04:06:35 +0100 (MET)
Received-Date: Sun, 20 Feb 2000 04:06:35 +0100 (MET)
Received: from cacc-10.uni-koblenz.de (cacc-10.uni-koblenz.de [141.26.131.10])
	by mailhost.uni-koblenz.de (8.9.3/8.9.3) with ESMTP id EAA04835;
	Sun, 20 Feb 2000 04:06:31 +0100 (MET)
Received: by lappi.waldorf-gmbh.de id <S407895AbQBTCXU>;
	Sun, 20 Feb 2000 03:23:20 +0100
Date: Sun, 20 Feb 2000 03:23:20 +0100
From: Ralf Baechle <ralf@uni-koblenz.de>
To: Klaus Naumann <spock@mgnet.de>
Cc: linux-mips@fnet.fr
Subject: Re: Bug in timex.h
Message-ID: <20000220032320.B25401@uni-koblenz.de>
References: <200002191515.QAA07017@sunnyboy.informatik.tu-chemnitz.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0pre3us
In-Reply-To: <200002191515.QAA07017@sunnyboy.informatik.tu-chemnitz.de>
X-Accept-Language: de,en,fr
Content-Length: 735
Lines: 17

On Sat, Feb 19, 2000 at 04:15:37PM +0100, Klaus Naumann wrote:

> while compiling glibc (cross compile) I think I encountered a bug in 
> include/asm-mips/timex.h .
> It uses the define CP0_COUNT and the function read_32bit_cp0_register()
> which are defined in mipsregs.h . But the timex.h does _not_
> include this file. At least my compiler complained about undefined 
> CP0_COUNT. I've appended a patch for the problem (Well, I 
> hope it's fixing the problem in a correct way ;) ).

No.  The function which uses read_32bit_cp0_register() shouldn't be
defined for userland in first hand.

(This is fixed in my copy of glibc which I'll upload once I've gone
through the necessary pain of recompiling my entire system twice.

  Ralf

From ralf@uni-koblenz.de  Sun Feb 20 18:41:52 2000
Received: from mailhost.uni-koblenz.de (mailhost.uni-koblenz.de [141.26.64.1]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id SAA08583; Sun, 20 Feb 2000 18:41:51 +0100 (MET)
Received-Date: Sun, 20 Feb 2000 18:41:51 +0100 (MET)
Received: from cacc-24.uni-koblenz.de (cacc-24.uni-koblenz.de [141.26.131.24])
	by mailhost.uni-koblenz.de (8.9.3/8.9.3) with ESMTP id SAA05836;
	Sun, 20 Feb 2000 18:41:41 +0100 (MET)
Received: by lappi.waldorf-gmbh.de id <S407899AbQBTMrC>;
	Sun, 20 Feb 2000 13:47:02 +0100
Date: Sun, 20 Feb 2000 13:47:02 +0100
From: Ralf Baechle <ralf@uni-koblenz.de>
To: Matthias Heidbrink <mh@cs.tu-berlin.de>
Cc: Harald Koerfgen <Harald.Koerfgen@home.ivm.de>, linux-mips@fnet.fr
Subject: Re: Current cvs kernerl fails to compile for decstation
Message-ID: <20000220134701.D25401@uni-koblenz.de>
References: <XFMail.000219132654.Harald.Koerfgen@home.ivm.de> <200002191403.PAA07765@elverum.cs.tu-berlin.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0pre3us
In-Reply-To: <200002191403.PAA07765@elverum.cs.tu-berlin.de>
X-Accept-Language: de,en,fr
Content-Length: 2087
Lines: 43

On Sat, Feb 19, 2000 at 03:03:16PM +0100, Matthias Heidbrink wrote:

> > > It's 64 because it's not possible to program the DECstation RTC to 100Hz
> > > or 1024Hz.
> > 
> > Well, 1024 Hz would be possible but certainly total overkill for a
> > DECstation 2100 with a 12.5 Mhz R2000 :-)
> 
> I remember that problems with these "odd" 64 Hz have been discussed on this 
> list several times before. Maybe it would not be such a bad idea to go to a
> "standard" value.                                                          
> 
> How expensive is the interrupt handler for the timer, I mean, how large
> would the loss in performance be when going to 1024 Hz?                   
> 
> Or would it make sense to modify the clock setup and interrupt handler to run
> the clock with 1024 Hz, but run the complete timer interrupt handling code
> only every 10 ms/at 100Hz (in average)?                               
> 
> I used this method some years ago under DOS because my application required
> a fine timer resolution and DOS required a timer interrupt every 55ms.
> On a 386-33 (which should be roughly equivalent in performance to an old
> MIPS CPU with a bit less than half of the clock speed)

There was a reason that at that time /etc/motd as shipped by MIPS in
Risc/OS did say ``MIPS - the messure of performance'' :-)

> it showed no remarkable loss in performence. Even quite the opposite
> because the application that had some delays in it ran smoother because of
> the finer granularity of the delays.

Assuming we special case this the fast path and can get away with about 30
instructions which execute all from the cache then that's going to be
an additional 26880 cycles per second for interrupt handling.  For a
12.5MHz machine that's 0.2%.  That's still too optimistic as it ignores
the cache effects.

It's our current approach to convert all time information where it is
visible in kernel interfaces in units of ticks, that is 1/HZ.  That's a
relativly small number of places and will only punish the caller but
not result in a permanent performance penalty.

  Ralf

From geert@linux-m68k.org  Sun Feb 20 20:11:29 2000
Received: from pop01.chello.be (phoenix.chello.be [195.162.196.23]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id UAA09920; Sun, 20 Feb 2000 20:11:27 +0100 (MET)
Received-Date: Sun, 20 Feb 2000 20:11:27 +0100 (MET)
Received: from callisto.of.borg ([195.162.216.83]) by pop01.chello.be
          (InterMail vK.4.02.00.00 201-232-116 license f891beffebad5da1b2ebd034a97f2710)
          with ESMTP id <20000220191120.MFSQ15382.pop01@callisto.of.borg>;
          Sun, 20 Feb 2000 20:11:20 +0100
Received: from localhost (geert@localhost)
	by callisto.of.borg (8.9.3/8.9.3/Debian/GNU) with ESMTP id UAA03014;
	Sun, 20 Feb 2000 20:11:20 +0100
X-Authentication-Warning: callisto.of.borg: geert owned process doing -bs
Date: Sun, 20 Feb 2000 20:11:19 +0100 (CET)
From: Geert Uytterhoeven <geert@linux-m68k.org>
Sender: geert@linux-m68k.org
To: Ralf Baechle <ralf@oss.sgi.com>
cc: Marc Esipovich <marc@mucom.co.il>, brett <brett@madhouse.org>,
        Bruce Leggett <bleggett@sofamordanek.com>, linux@cthulhu.engr.sgi.com,
        linux-mips@fnet.fr, linux-mips@vger.rutgers.edu
Subject: Re: Linux on O2?
In-Reply-To: <20000220001445.B23993@uni-koblenz.de>
Message-ID: <Pine.LNX.4.05.10002202009380.786-100000@callisto.of.borg>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Content-Length: 2053
Lines: 45

On Sun, 20 Feb 2000, Ralf Baechle wrote:
> On Sat, Feb 19, 2000 at 06:30:22AM -0200, Marc Esipovich wrote:
> 
> > > > Im still wainting to hear anything about the indigo i hear alot of talk
> > > > about the indigo2 but nothing about the original blue boxes
> > > 
> > > The problem is that the origin docs are gone by now and SGI can't
> > > just go and ship the IRIX source to hackers ...
> > 
> > Wow, what do you mean gone by now?  are you saying there's no chance in
> > hell to obtain the documentation?  it can't be gone.
> 
> Remember that SGI is a company that designs a large fraction of a system.
> So the designers of some piece of hardware and it's direct users, the
> kernel programmers have close to each other.  For a lot of chips
> documentation never is written or at least never the same way so it would
> be the case for chips that would be marketed as such.  It's obvious that
> this isn't good at all for Free Software where the access to high
> quality documentation is crucial.
> 
> So now imagine what has happened to all the knowledge about a machine
> during the decade after it was developed?  The product's development
> finishes, it get's marketed, the OS for gets some final bugfixes and
> even later it gets phased out.  Silence.  Meanwhile the brains behind
> the machine leave the company, tapes and paper go to some dark room
> where nobody still remembers them and the machine gets forgotten.
> 
> Slow death of a computer ...

Unrelated, but similar: I'd like to port Linux/m68k to the Tektronix XP21
X-terminal I have. It has a 68030, TMS34020 and NE2000 Ethernet, but where do
you find docs? Tektronix has sold their X-terminal division to NCD.

If a machine is older than the web, AltaVista won't help you neither.

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- Linux/{m68k~Amiga,PPC~CHRP} -- 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 ralf@oss.sgi.com  Sun Feb 20 22:57:34 2000
Received: from mailhost.uni-koblenz.de (mailhost.uni-koblenz.de [141.26.64.1]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id WAA11758; Sun, 20 Feb 2000 22:57:34 +0100 (MET)
Received-Date: Sun, 20 Feb 2000 22:57:34 +0100 (MET)
Received: from cacc-16.uni-koblenz.de (cacc-16.uni-koblenz.de [141.26.131.16])
	by mailhost.uni-koblenz.de (8.9.3/8.9.3) with ESMTP id WAA18708;
	Sun, 20 Feb 2000 22:57:22 +0100 (MET)
Received: by lappi.waldorf-gmbh.de id <S407891AbQBTVFP>;
	Sun, 20 Feb 2000 22:05:15 +0100
Date: Sun, 20 Feb 2000 22:05:14 +0100
From: Ralf Baechle <ralf@oss.sgi.com>
To: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Ralf Baechle <ralf@oss.sgi.com>, Marc Esipovich <marc@mucom.co.il>,
        brett <brett@madhouse.org>, Bruce Leggett <bleggett@sofamordanek.com>,
        linux@cthulhu.engr.sgi.com, linux-mips@fnet.fr,
        linux-mips@vger.rutgers.edu
Subject: Re: Linux on O2?
Message-ID: <20000220220514.A867@uni-koblenz.de>
References: <20000220001445.B23993@uni-koblenz.de> <Pine.LNX.4.05.10002202009380.786-100000@callisto.of.borg>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0pre3us
In-Reply-To: <Pine.LNX.4.05.10002202009380.786-100000@callisto.of.borg>
X-Accept-Language: de,en,fr
Content-Length: 471
Lines: 12

On Sun, Feb 20, 2000 at 08:11:19PM +0100, Geert Uytterhoeven wrote:

> Unrelated, but similar: I'd like to port Linux/m68k to the Tektronix XP21
> X-terminal I have. It has a 68030, TMS34020 and NE2000 Ethernet, but where do
> you find docs? Tektronix has sold their X-terminal division to NCD.
> 
> If a machine is older than the web, AltaVista won't help you neither.

>From time to time I get email from people with ancient 68k-based SGIs
asking for Linux ...

  Ralf

From ralf@oss.sgi.com  Mon Feb 21 00:03:38 2000
Received: from mailhost.uni-koblenz.de (mailhost.uni-koblenz.de [141.26.64.1]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id AAA14146; Mon, 21 Feb 2000 00:03:38 +0100 (MET)
Received-Date: Mon, 21 Feb 2000 00:03:38 +0100 (MET)
Received: from cacc-16.uni-koblenz.de (cacc-16.uni-koblenz.de [141.26.131.16])
	by mailhost.uni-koblenz.de (8.9.3/8.9.3) with ESMTP id AAA22173;
	Mon, 21 Feb 2000 00:03:31 +0100 (MET)
Received: by lappi.waldorf-gmbh.de id <S407891AbQBTXDD>;
	Mon, 21 Feb 2000 00:03:03 +0100
Date: Mon, 21 Feb 2000 00:03:02 +0100
From: Ralf Baechle <ralf@oss.sgi.com>
To: Richard <richardh@penguin.nl>
Cc: Ralf Baechle <ralf@oss.sgi.com>, Geert Uytterhoeven <geert@linux-m68k.org>,
        Marc Esipovich <marc@mucom.co.il>, brett <brett@madhouse.org>,
        Bruce Leggett <bleggett@sofamordanek.com>, linux@cthulhu.engr.sgi.com,
        linux-mips@fnet.fr, linux-mips@vger.rutgers.edu
Subject: Re: Linux on O2?
Message-ID: <20000221000302.C2189@uni-koblenz.de>
References: <20000220001445.B23993@uni-koblenz.de> <Pine.LNX.4.05.10002202009380.786-100000@callisto.of.borg> <20000220220514.A867@uni-koblenz.de> <38B06B6D.A8DE9C5E@penguin.nl>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0pre3us
In-Reply-To: <38B06B6D.A8DE9C5E@penguin.nl>
X-Accept-Language: de,en,fr
Content-Length: 662
Lines: 18

On Sun, Feb 20, 2000 at 11:32:13PM +0100, Richard wrote:

> > > Unrelated, but similar: I'd like to port Linux/m68k to the Tektronix XP21
> > > X-terminal I have. It has a 68030, TMS34020 and NE2000 Ethernet, but where do
> > > you find docs? Tektronix has sold their X-terminal division to NCD.
> > >
> > > If a machine is older than the web, AltaVista won't help you neither.
> >
> > >From time to time I get email from people with ancient 68k-based SGIs
> > asking for Linux ...
> 
> I've still got an iris 3030 which is an 68k based SGI.
> 
> geert: It's even located in belgium :)

That was a failure.  Somebody will ring your door bell tonight :-)

  Ralf

From books11@freewwweb.com  Mon Feb 21 04:17:40 2000
Received: from pps-1.smartworld.net (pps-1.smartworld.net [216.70.64.22]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id EAA18984; Mon, 21 Feb 2000 04:17:39 +0100 (MET)
Received-Date: Mon, 21 Feb 2000 04:17:39 +0100 (MET)
Received: from pavilion (1Cust159.tnt1.sylva.nc.da.uu.net [63.27.171.159])
	by pps-1.smartworld.net (8.9.1a/8.9.1) with SMTP id WAA72777;
	Sun, 20 Feb 2000 22:17:09 -0500 (EST)
Date: Sun, 20 Feb 2000 22:17:09 -0500 (EST)
From: AUBC Used Book Search <books11@freewwweb.com>
To: <linux-l-request@computers.rootsweb.com>
Message-Id: <18161.236576.92903600 linvic@planet.eon.net>
Subject: looking for a used book?
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Length: 1642
Lines: 49

Introducing AUBC Used Book Search - the easy way to get your hands on that 
elusive book!!
> > by author, or title; used, or out of print books. 
As we get many email response for booksearches from people who do not truely 
want to buy books we have found it neccesary to ask for genuine enquiries to be 
mailed to us in the post. This only takes a couple of days but will ensure our 
swiftest reply and best efficiency to meet your needs without being snowed under 
by deadend requests. (All interaction therafter can be done by email - as soon as 
we recieve your mailed request we will acknowledge this by email confimation to 
your email address.) We hope this will ensure a better service for you 
INITIATE A BOOK SEARCH REQUEST:
MAIL: AUBC 336 Jim Mann Rd, Franklin, NC 28734, USA 
Please include ALL the following information in your request:
Your name: 
Your email address:
Author First Name
Author Surname:
Title:
Physical address 
OPTIONAL
Hard of soft cover:
Other special requirements:
Budget (if you have one):

As soon as a copy of the book has been found a price will be returned to you by 
email for your final sale decision. Looking forward to hearing from you.


Thank you
AUBC



Please note we do NOT deal in any pornographic or "adult only" materials
and have no connection with any such operators.

WE STRONGLY BELIEVE THAT PRESERVING THE 
CONFIDENTIALITY OF YOUR INFORMATION IS ONE OF OUR 
MOST IMPORTAINT RESPONSIBILITIES. BECAUSE OF THIS BELIEF 
WE FEEL IT ALSO IMPORTAINT TO ASSURE YOU THAT NO 
INFORMATION ABOUT YOU WILL BE SOLD OR REMARKETED TO 
OUTSIDE SOURCES.

Thank you
Larry L. Heave (Marketing Director)





From dstein@phoenixcontact.com  Mon Feb 21 09:49:47 2000
Received: from inet01.phoenix-contact.de ([62.157.123.66]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id JAA22926; Mon, 21 Feb 2000 09:49:46 +0100 (MET)
Received-Date: Mon, 21 Feb 2000 09:49:46 +0100 (MET)
From: dstein@phoenixcontact.com
Received: from phoenixcontact.com ([149.208.7.145]) by inet01.phoenix-contact.de with SMTP (8.7.1/8.7.1) id JAA02131 for <linux-mips@fnet.fr>; Mon, 21 Feb 2000 09:49:44 +0100 (MET)
Received: by phoenixcontact.com(Lotus SMTP MTA v4.6.5  (863.2 5-20-1999))  id 4125688C.00311FC1 ; Mon, 21 Feb 2000 09:56:33 +0100
X-Lotus-FromDomain: PHOENIX
To: linux-mips@fnet.fr
Message-ID: <4125688C.00311EBB.00@phoenixcontact.com>
Date: Mon, 21 Feb 2000 09:48:54 +0100
Subject: Pyramid Nile Cluster for sale
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Length: 767
Lines: 31

Hello

I know, this not a real topic for a mailing list, but I decided to post it here,
because I think, it is best way to do.

My company, Phoenix Contact GmbH (Blomberg, Germany), has a Pyramid Nile Cluster
for sale (very low price!!!).

Specification as follows:

Pyramid Nile Cluster, two machines
a) 10 CPUs, MIPS 4400, 2 GB RAM
b) 8 CPUs, MIPS 4400, 1.5 GB RAM

Two common drive bays HAAS-3
a) 12 x ST12550N, 2 x ST15150W
b) 10 x ST12550W, 6 x ST15150W

Current operating system
DC_OSX 1.1-95d087.4

If you have any interest or further question, do not hesitate to contact me.

I would ask you, to forward this mail to anyone you know who may be interested
in these machines.


Thanks for patience and understanding.

Dietmar Stein (dstein@phoenixcontact.com)


From ralf@oss.sgi.com  Mon Feb 21 16:18:44 2000
Received: from mailhost.uni-koblenz.de (mailhost.uni-koblenz.de [141.26.64.1]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id QAA27538; Mon, 21 Feb 2000 16:18:43 +0100 (MET)
Received-Date: Mon, 21 Feb 2000 16:18:43 +0100 (MET)
Received: from cacc-15.uni-koblenz.de (cacc-15.uni-koblenz.de [141.26.131.15])
	by mailhost.uni-koblenz.de (8.9.3/8.9.3) with ESMTP id QAA25248;
	Mon, 21 Feb 2000 16:18:36 +0100 (MET)
Received: by lappi.waldorf-gmbh.de id <S407892AbQBUL6U>;
	Mon, 21 Feb 2000 12:58:20 +0100
Date: Mon, 21 Feb 2000 12:58:20 +0100
From: Ralf Baechle <ralf@oss.sgi.com>
To: Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com>
Cc: linux@engr.sgi.com, linux-mips@fnet.fr, linux-mips@vger.rutgers.edu
Subject: Re: CVS Update@oss.sgi.com: linux
Message-ID: <20000221125820.A11469@uni-koblenz.de>
References: <20000219003324Z305163-11638+186@oss.sgi.com> <Pine.GSO.4.10.10002211054270.29481-100000@dandelion.sonytel.be>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0pre3us
In-Reply-To: <Pine.GSO.4.10.10002211054270.29481-100000@dandelion.sonytel.be>
X-Accept-Language: de,en,fr
Content-Length: 398
Lines: 16

On Mon, Feb 21, 2000 at 10:54:45AM +0100, Geert Uytterhoeven wrote:

> > Modified files:
> > 	include/asm-mips: uaccess.h 
> > 	include/asm-mips64: uaccess.h 
> > 
> > Log message:
> > 	Fix copy_from_user() in modules and 64-bit kernel.
> 
> Now the assembler complains with
> 
>     Warning: Used $at without ".set noat"

I just tried to build an Indy kernel and did not get this warning.

  Ralf

From kevink@mips.com  Mon Feb 21 15:25:52 2000
Received: from mx.mips.com (mx.mips.com [206.31.31.226]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id PAA26778; Mon, 21 Feb 2000 15:25:51 +0100 (MET)
Received-Date: Mon, 21 Feb 2000 15:25:51 +0100 (MET)
Received: from newman.mips.com (newman [206.31.31.8])
	by mx.mips.com (8.9.3/8.9.0) with ESMTP id GAA29135;
	Mon, 21 Feb 2000 06:25:38 -0800 (PST)
Received: from satanas (satanas [192.168.236.12])
	by newman.mips.com (8.9.3/8.9.0) with SMTP id GAA08619;
	Mon, 21 Feb 2000 06:25:34 -0800 (PST)
Message-ID: <013d01bf7c77$d79398b0$0ceca8c0@satanas.mips.com>
From: "Kevin D. Kissell" <kevink@mips.com>
To: <Arnold.Niessen@philips.com>, <linux-mips@fnet.fr>, <carstenl@mips.com>,
        <linux-porters@algor.co.uk>
Subject: Re: Linux on Algorithmics P4032 dev.board
Date: Mon, 21 Feb 2000 15:27:46 +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 4.72.3110.5
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Content-Length: 2755
Lines: 67

>Dear Chris, Kevin, and other Linux/MIPS-ers,
>
>I have just started to work on a port of Linux (with 
>the intention of RT-Linux in a later stage)
>to the Algorithmics P4032-board, based on the newly
>released MIPS port for the P5064 and Atlas boards. 
>Dominic Sweetman already told me there are more people 
>interested in or working on this P4032 port.
>
>I would be obliged if you could help me with
>a status overview so far, and where work is still needed
>mostly. Although MIPS and P4032 are new to me,
>I am surrounded by pSOS-oriented colleagues with lots
>of P4032 experience, and I am willing to invest time
>in this port.
>
>And to start with a silly question:
>So far I have not found a ready-to-use cross compilation
>environment; I have just started to build a gcc-2.95.2
>mips cross compiler; monday I will try to solve the
>first errors which stopped the compilation...
>Any pointers (other than the CrossGCC FAQ and gcc doc) that
>I should be aware of ?


I think Ralf Baechle has already responded to your compiler
enquiry, and I would follow his recommendation and use the
information (and tools) provided on the www.linux.sgi.com site.

We did do a couple of things at MIPS to try to make the
P4032 port simpler, or at least to open the possibility
of having a single binary kernel that could run on both
the P5064 and the P4032.  We fixed the TLB miss handlers
and CPU configuration logic to (a) know and (b) handle correctly
the 32 TLB entries of the R4300, and wherever possible we
made things like the address offsets to/from PCI space
and kernel debugger port bindings configurable at boot time 
from the platform setup code.  This is not to say that I would
suggest going for a dual-boot kernel right off the bat, only
that some work in that direction has been done, and that
you should try not to do anything that would actively prevent
it from working.

The ncr53c8xx.c SCSI driver should work with little or
no modification - perhaps someone else on the linux-porters
list can comment as to whether the platform-supplies-scsi-clock
option needs to be specified for the P4032 as it does for
the P5064.  The tulip.c driver is theoretically capable
of handling the 21041 as well as the 21043 on the P5064,
but that needs to be verified.

What needs to be done (in my opinion) is to:

a) set up a subtree arch/mips/algor/p4032 that parallels
     (and maybe even copies, to begin with) arch/mips/algor/p5064

b) replace/modify the PCI bridge configuration and setup code.
     This will probably be the most time-consuming element.

c) modify the platform-dependent "IRQ" binding and PCI-BIOS
     fixup code as appropriate.

d) tweak the existing drivers as necessary, if necessary.

            Regards,

            Kevin K.

From ralf@uni-koblenz.de  Mon Feb 21 16:18:53 2000
Received: from mailhost.uni-koblenz.de (mailhost.uni-koblenz.de [141.26.64.1]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id QAA27561; Mon, 21 Feb 2000 16:18:52 +0100 (MET)
Received-Date: Mon, 21 Feb 2000 16:18:52 +0100 (MET)
Received: from cacc-15.uni-koblenz.de (cacc-15.uni-koblenz.de [141.26.131.15])
	by mailhost.uni-koblenz.de (8.9.3/8.9.3) with ESMTP id QAA25268;
	Mon, 21 Feb 2000 16:18:39 +0100 (MET)
Received: by lappi.waldorf-gmbh.de id <S407894AbQBUO77>;
	Mon, 21 Feb 2000 15:59:59 +0100
Date: Mon, 21 Feb 2000 15:59:59 +0100
From: Ralf Baechle <ralf@uni-koblenz.de>
To: "Kevin D. Kissell" <kevink@mips.com>
Cc: Arnold.Niessen@philips.com, linux-mips@fnet.fr, carstenl@mips.com,
        linux-porters@algor.co.uk
Subject: Re: Linux on Algorithmics P4032 dev.board
Message-ID: <20000221155959.A14445@uni-koblenz.de>
References: <013d01bf7c77$d79398b0$0ceca8c0@satanas.mips.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0pre3us
In-Reply-To: <013d01bf7c77$d79398b0$0ceca8c0@satanas.mips.com>
X-Accept-Language: de,en,fr
Content-Length: 995
Lines: 23

On Mon, Feb 21, 2000 at 03:27:46PM +0100, Kevin D. Kissell wrote:

> I think Ralf Baechle has already responded to your compiler
> enquiry, and I would follow his recommendation and use the
> information (and tools) provided on the www.linux.sgi.com site.

Please don't refer to the old hostnae {www,ftp,linus}.linux.sgi.com
any longer.  All services have been moved to oss.sgi.com and somewhen
we'll also remove the old aliases.  The Linux/MIPS web content is now
available under http://oss.sgi.com/mips/.

> The ncr53c8xx.c SCSI driver should work with little or
> no modification - perhaps someone else on the linux-porters
> list can comment as to whether the platform-supplies-scsi-clock
> option needs to be specified for the P4032 as it does for
> the P5064.  The tulip.c driver is theoretically capable
> of handling the 21041 as well as the 21043 on the P5064,
> but that needs to be verified.

In the past I've used the tulip.c driver on MIPS also with 21040,
21041 and 21041.

  Ralf

From Geert.Uytterhoeven@sonycom.com  Mon Feb 21 16:48:10 2000
Received: from mail.sonytel.be (mail.sonytel.be [193.74.243.200]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id QAA28624; Mon, 21 Feb 2000 16:48:05 +0100 (MET)
Received-Date: Mon, 21 Feb 2000 16:48:05 +0100 (MET)
Received: from dandelion.sonytel.be (dandelion.sonytel.be [193.74.243.153])
	by mail.sonytel.be (8.9.0/8.8.6) with ESMTP id QAA02176;
	Mon, 21 Feb 2000 16:46:52 +0100 (MET)
Date: Mon, 21 Feb 2000 16:46:52 +0100 (MET)
From: Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com>
Sender: geert@sonycom.com
To: Ralf Baechle <ralf@oss.sgi.com>
cc: linux@engr.sgi.com, linux-mips@fnet.fr, linux-mips@vger.rutgers.edu
Subject: Re: CVS Update@oss.sgi.com: linux
In-Reply-To: <20000221125820.A11469@uni-koblenz.de>
Message-ID: <Pine.GSO.4.10.10002211634260.4234-100000@dandelion.sonytel.be>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Content-Length: 1631
Lines: 52

On Mon, 21 Feb 2000, Ralf Baechle wrote:
> On Mon, Feb 21, 2000 at 10:54:45AM +0100, Geert Uytterhoeven wrote:
> > > Modified files:
> > > 	include/asm-mips: uaccess.h 
> > > 	include/asm-mips64: uaccess.h 
> > > 
> > > Log message:
> > > 	Fix copy_from_user() in modules and 64-bit kernel.
> > 
> > Now the assembler complains with
> > 
> >     Warning: Used $at without ".set noat"
> 
> I just tried to build an Indy kernel and did not get this warning.

I guess it depends on the configuration. From looking at the list of files I
got complaints for, I do believe you didn't get them when building for an Indy.

Can you try to compile the module for the loop block device? The problem
happens near the call to copy_from_user() in loop_set_status(). The generated
code is (warning position indicated with `>>>'):

	    .set    noreorder
	    .set    noat
	    .set    noat
	    la      $1, __copy_user
	    jalr    $1
	    .set    at
>>>	    addu    $1, $13, $7
	    .set    at
	    .set    reorder
	    move    $7, $6
     #NO_APP
    $L1492:
	    .set    noreorder
	    .set    nomacro
	    bne     $7,$0,$L1502
	    li      $2,-14                  # 0xfffffff2
	    .set    macro
	    .set    reorder

I guess the problem is the nested .set noat/at construct, where __MODULE_JAL
does .set at while copy_from_user() assumes we're still in noat mode?

Gr{oetje,eeting}s,

						Geert

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

From ralf@oss.sgi.com  Mon Feb 21 22:38:00 2000
Received: from mailhost.uni-koblenz.de (mailhost.uni-koblenz.de [141.26.64.1]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id WAA03027; Mon, 21 Feb 2000 22:37:59 +0100 (MET)
Received-Date: Mon, 21 Feb 2000 22:37:59 +0100 (MET)
Received: from cacc-13.uni-koblenz.de (cacc-13.uni-koblenz.de [141.26.131.13])
	by mailhost.uni-koblenz.de (8.9.3/8.9.3) with ESMTP id WAA11990;
	Mon, 21 Feb 2000 22:37:49 +0100 (MET)
Received: by lappi.waldorf-gmbh.de id <S407897AbQBUSDw>;
	Mon, 21 Feb 2000 19:03:52 +0100
Date: Mon, 21 Feb 2000 19:03:52 +0100
From: Ralf Baechle <ralf@oss.sgi.com>
To: Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com>
Cc: linux@engr.sgi.com, linux-mips@fnet.fr, linux-mips@vger.rutgers.edu
Subject: Re: CVS Update@oss.sgi.com: linux
Message-ID: <20000221190352.B15668@uni-koblenz.de>
References: <20000221125820.A11469@uni-koblenz.de> <Pine.GSO.4.10.10002211634260.4234-100000@dandelion.sonytel.be>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0pre3us
In-Reply-To: <Pine.GSO.4.10.10002211634260.4234-100000@dandelion.sonytel.be>
X-Accept-Language: de,en,fr
Content-Length: 334
Lines: 9

On Mon, Feb 21, 2000 at 04:46:52PM +0100, Geert Uytterhoeven wrote:

> I guess the problem is the nested .set noat/at construct, where __MODULE_JAL
> does .set at while copy_from_user() assumes we're still in noat mode?

Yep, looking at the assembler code your report immediately made sense.
Fix going to CVS as I write this.

  Ralf

From spock@mgnet.de  Tue Feb 22 12:43:28 2000
Received: from asterix.hrz.tu-chemnitz.de (asterix.hrz.tu-chemnitz.de [134.109.132.84]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id MAA09739; Tue, 22 Feb 2000 12:43:27 +0100 (MET)
Received-Date: Tue, 22 Feb 2000 12:43:27 +0100 (MET)
Received: from sunnyboy.informatik.tu-chemnitz.de by asterix.hrz.tu-chemnitz.de 
          with Local SMTP (PP); Tue, 22 Feb 2000 12:43:06 +0100
Received: from scotty.mgnet.de (stampede.csn.tu-chemnitz.de [134.109.96.133]) 
          by sunnyboy.informatik.tu-chemnitz.de (8.8.8/8.8.8) with SMTP 
          id MAA01952 for <linux-mips@fnet.fr>;
          Tue, 22 Feb 2000 12:43:05 +0100 (MET)
Message-Id: <200002221143.MAA01952@sunnyboy.informatik.tu-chemnitz.de>
Received: (qmail 16071 invoked from network); 22 Feb 2000 11:42:55 -0000
Received: from spock.mgnet.de (192.168.1.4) by scotty.mgnet.de with SMTP;
          22 Feb 2000 11:42:55 -0000
Date: Tue, 22 Feb 2000 12:43:11 CET
From: Klaus Naumann <spock@mgnet.de>
To: linux-mips@fnet.fr
Subject: Trouble booting Linux on I2
Reply-To: spock@mgnet.de
X-Mailer: Spruce 0.5.16 for X11 w/smtpio 0.7.3
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
Content-Length: 1695
Lines: 50




Hi,

I'm having serious trouble booting MIPS Linux on my Indigo2
(for hinv see below).
I tried booting it in several ways.
1. I used the boot PROM console and tried booting the kernel
via the sash from the Harddisk.
2. I tried booting te kernel over network (This downloads the kernel file
from the bootp server but then also gives the following error)

But when the kernel should start either the system hangs or nothing happens
(you can simply press Done).
I also tried various kernels, like some from oss.sgi.com , the HardHat
kernel
and a selfcompiled (cross compiled) kernel. The selfcompiled kernel gave
the exception when I forgot to remove the -N in the Makefile. But it does
nothing
after I did so.

This is the hinv for my system:

CPU: MIPS R4400 Processor Chip Revision: 6.0
FPU: MIPS R4000 Floating Point Coprocessor Revision: 0.0
1 200 MHZ IP22 Processor
Main memory size: 64 Mbytes
Secondary unified instruction/data cache size: 1 Mbyte on Processor 0
Instruction cache size: 16 Kbytes
Data cache size: 16 Kbytes
Integral SCSI controller 0: Version WD33C93B, revision D
Integral SCSI controller 1: Version WD33C93B, revision D
  Disk drive: unit 1 on SCSI controller 1
On-board serial ports: 2
On-board bi-directional parallel port
Graphics board: GU1-Extreme
Integral Ethernet: ec0, version 1
Iris Audio Processor: version A2 revision 1.1.0
EISA bus: adapter 0

Can anyone help me with that problem ?

	Thank you very much in advance , Klaus

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

From dom@algor.co.uk  Tue Feb 22 23:26:58 2000
Received: from kenton.algor.co.uk (root@kenton.algor.co.uk [193.117.190.25]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id XAA15227; Tue, 22 Feb 2000 23:26:57 +0100 (MET)
Received-Date: Tue, 22 Feb 2000 23:26:57 +0100 (MET)
Received: from gladsmuir.algor.co.uk (dom@gladsmuir.algor.co.uk [193.117.190.129])
	by kenton.algor.co.uk (8.8.8/8.8.8) with ESMTP id WAA02584;
	Tue, 22 Feb 2000 22:26:47 GMT
Received: (from dom@localhost)
	by gladsmuir.algor.co.uk (8.8.5/8.8.5) id WAA00728;
	Tue, 22 Feb 2000 22:26:45 GMT
Date: Tue, 22 Feb 2000 22:26:45 GMT
Message-Id: <200002222226.WAA00728@gladsmuir.algor.co.uk>
From: Dominic Sweetman <dom@algor.co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
To: "Kevin D. Kissell" <kevink@mips.com>
Cc: <Arnold.Niessen@philips.com>, <linux-mips@fnet.fr>, <carstenl@mips.com>,
        <linux-porters@algor.co.uk>
Subject: Re: Linux on Algorithmics P4032 dev.board
In-Reply-To: <013d01bf7c77$d79398b0$0ceca8c0@satanas.mips.com>
References: <013d01bf7c77$d79398b0$0ceca8c0@satanas.mips.com>
X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid
Content-Length: 470
Lines: 15


Kevin D. Kissell (kevink@mips.com) writes (re P5064->P4032
transition): 

> b) replace/modify the PCI bridge configuration and setup code.
>      This will probably be the most time-consuming element.

That bit's not too bad: the P-5064's V360EPC bridge component is in
fact just the next revision of the V962PBC fitted to the P-4032.  It
differs only in some features (for some kind of I2O stuff) which we
don't use.

Dominic Sweetman
dom@algor.co.uk
Algorithmics Ltd

From ralf@uni-koblenz.de  Wed Feb 23 15:49:45 2000
Received: from mailhost.uni-koblenz.de (mailhost.uni-koblenz.de [141.26.64.1]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id PAA25785; Wed, 23 Feb 2000 15:49:43 +0100 (MET)
Received-Date: Wed, 23 Feb 2000 15:49:43 +0100 (MET)
Received: from cacc-4.uni-koblenz.de (cacc-4.uni-koblenz.de [141.26.131.4])
	by mailhost.uni-koblenz.de (8.9.3/8.9.3) with ESMTP id PAA14218;
	Wed, 23 Feb 2000 15:49:11 +0100 (MET)
Received: by lappi.waldorf-gmbh.de id <S407896AbQBWK5d>;
	Wed, 23 Feb 2000 11:57:33 +0100
Date: Wed, 23 Feb 2000 11:57:33 +0100
From: Ralf Baechle <ralf@uni-koblenz.de>
To: Klaus Naumann <spock@mgnet.de>
Cc: linux-mips@fnet.fr
Subject: Re: Trouble booting Linux on I2
Message-ID: <20000223115733.A7918@uni-koblenz.de>
References: <200002221143.MAA01952@sunnyboy.informatik.tu-chemnitz.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0pre3us
In-Reply-To: <200002221143.MAA01952@sunnyboy.informatik.tu-chemnitz.de>
X-Accept-Language: de,en,fr
Content-Length: 200
Lines: 8

On Tue, Feb 22, 2000 at 12:43:11PM +0100, Klaus Naumann wrote:

> Graphics board: GU1-Extreme

We don't support this card.  You will have to use either serial console
or PROM console for now.

  Ralf

From snelson@winningsolutionsinc.com  Mon Feb 28 03:06:42 2000
Received: from winning02.winningsolutionsinc.com (dns1.winningsolutionsinc.com [216.81.196.130]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id DAA17844; Mon, 28 Feb 2000 03:06:41 +0100 (MET)
Received-Date: Mon, 28 Feb 2000 03:06:41 +0100 (MET)
Received: from ws177.winningsolutionsinc.com by winning02.winningsolutionsinc.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.0.1460.8)
	id FB91FMWJ; Sun, 27 Feb 2000 20:00:25 -0600
From: "Steven L Nelson" <snelson@winningsolutionsinc.com>
To: <linux-mips@fnet.fr>
Subject: R3000 Based SGI Indigo's
Date: Sun, 27 Feb 2000 20:01:40 -0600
Message-ID: <NDBBLHNIKLGHNJDBBLDNCEBJCCAA.snelson@winningsolutionsinc.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Content-Length: 386
Lines: 12


	I am looking for any news about when the SGI Indigo 1 machines may or may
not
be supported under Linux. Also I am looking for any documentation any of you
may have found
for the hardware in this machine. Anything would be of help. I have
documentation of the R3k processor
which this machine runs on, but I don't have anything else

-Steve Nelson
System Analyst
Winning Solutions Inc

From ralf@uni-koblenz.de  Mon Feb 28 22:52:49 2000
Received: from mailhost.uni-koblenz.de (mailhost.uni-koblenz.de [141.26.64.1]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id WAA07093; Mon, 28 Feb 2000 22:52:48 +0100 (MET)
Received-Date: Mon, 28 Feb 2000 22:52:48 +0100 (MET)
Received: from cacc-18.uni-koblenz.de (cacc-18.uni-koblenz.de [141.26.131.18])
	by mailhost.uni-koblenz.de (8.9.3/8.9.3) with ESMTP id WAA24743;
	Mon, 28 Feb 2000 22:52:45 +0100 (MET)
Received: by lappi.waldorf-gmbh.de id <S407931AbQB1D72>;
	Mon, 28 Feb 2000 04:59:28 +0100
Date: Mon, 28 Feb 2000 04:59:28 +0100
From: Ralf Baechle <ralf@uni-koblenz.de>
To: Steven L Nelson <snelson@winningsolutionsinc.com>
Cc: linux-mips@fnet.fr
Subject: Re: R3000 Based SGI Indigo's
Message-ID: <20000228045928.A23168@uni-koblenz.de>
References: <NDBBLHNIKLGHNJDBBLDNCEBJCCAA.snelson@winningsolutionsinc.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0pre3us
In-Reply-To: <NDBBLHNIKLGHNJDBBLDNCEBJCCAA.snelson@winningsolutionsinc.com>
X-Accept-Language: de,en,fr
Content-Length: 303
Lines: 10

On Sun, Feb 27, 2000 at 08:01:40PM -0600, Steven L Nelson wrote:

> 
> 	I am looking for any news about when the SGI Indigo 1 machines may or may
> not
> be supported under Linux. Also I am looking for any documentation any of you

Still nothing happend and I wouldn't assume that it will ever.

  Ralf

From kevink@mips.com  Mon Feb 28 13:21:12 2000
Received: from mx.mips.com (mx.mips.com [206.31.31.226]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id NAA22415; Mon, 28 Feb 2000 13:21:10 +0100 (MET)
Received-Date: Mon, 28 Feb 2000 13:21:10 +0100 (MET)
Received: from newman.mips.com (newman [206.31.31.8])
	by mx.mips.com (8.9.3/8.9.0) with ESMTP id EAA08242;
	Mon, 28 Feb 2000 04:20:48 -0800 (PST)
Received: from satanas (satanas [192.168.236.12])
	by newman.mips.com (8.9.3/8.9.0) with SMTP id EAA25223;
	Mon, 28 Feb 2000 04:20:44 -0800 (PST)
Message-ID: <010101bf81e6$9c546120$0ceca8c0@satanas.mips.com>
From: "Kevin D. Kissell" <kevink@mips.com>
To: "Linux/MIPS fnet" <linux-mips@fnet.fr>,
        "Linux/MIPS algor" <linux-porters@algor.co.uk>,
        "Linux SGI" <linux@cthulhu.engr.sgi.com>
Subject: Kernel/User Memory Access and Original Sin
Date: Mon, 28 Feb 2000 13:23:17 +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 4.72.3110.5
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Content-Length: 4030
Lines: 85

My apologies to those of you who will get three copies of this, 
but I wanted to reach, to the extent possible, the full MIPS/Linux 
community.

I began running the "crashme" test program, available at
http://people.delphi.com/gjc/crashme.html, on a MIPS/Linux
configuration, a week or so ago.  It has been a useful exercise,
but one that opens up a real pandora's box.  Note that I've been
running it on our 2.2.12 kernel for embedded MIPS chips,
and not on 2.3.x for SGI platforms, but my findings are relevant
to both environments.

In addition to turning up a couple of bugs in the FPU emulator
interface to the kernel - the sort of thing I was looking for - crashme
turned up a problem with kernel access to the user memory map
that looks to me to be very serious.  I have implemented a fix,
but it casts doubt on the wisdom of the general Linux scheme
for handling kernel access to user memory - hence the "original
sin" reference above.

Linux, as written for the x86, goes very heavily for inlining.
Rather than call specially protected copyin/copyout sorts
of routines for manipulating user memory, Linux uses inline
macros (copy_from_user/copy_to_user, etc.) that depend on
doing explicit checks of the address space for correctness.
This is tenable if and only if the explicit check is both
cheap and reliable.   On the x86, this check, __range_ok,
is accomplished with a quick check of segment registers,
and may or may not actually be reliable, depending on
the x86 VM implementation.   In the MIPS 2.2 and 2.3
kernels, the check, __access_ok, is a simple heuristic
that verifies that the access does not reference kernel
memory, nor is it greater than 2GB in size.  That's cheap,
but not reliable.  The primary failure mode I observed was 
where signal.c blows up when trying to set up a signal context 
on a corrupted user stack, but the problem is more pervasive.

I have succeeded in writing what seems to be a "real"
__access_ok routine, but it is much more heavyweight
than the old heuristic.  Not only does it need to check the
virtual address against the process' VMAs, but it needs
to deal with accesses that span multiple, contiguous
VMAs (such as those the xmalloc returns to /bin/cat!),
and it needs to deal with accesses to addresses
to which a stack VMA will be grown.   In my opinion,
the result is too big to put in ubiquitous in-line macros,
so it became a function (in mm/fault.c for want of a better
home), and the macros now call the function.   The system
handles the previously fatal test cases, and now I need to 
make some measurements of the effects on performance.
I'll post patches/sources to the web shortly, but for the
moment, I'm curious as to the opinions of other kernel
hackers in the MIPS/Linux community.

Is it acceptable to allow corrupted processes to cause
system panics?  Is speed more important than stability 
to you and your users?  At MIPS, we need the OS to be 
as stable as possible, so that we can stress new chips on it
with some confidence that the chips will break before
the OS does, and we would happily pay a significant
penalty in performance for that confidence.   Those who
re-use our code for embedded Linux applications, on
the other hand, need stability *and* performance.

I have formed the opinion that the "correct" way to deal 
with kernel/user memory accesses in Linux, at least for 
MIPS, is to take a model much closer to System V and BSD 
than to the Linux/x86 tradition. Instead of performing range 
checks at each reference, protected routines (copyin/copyout, 
et al.) need to be set up to perform the necessary accesses in 
kernel mode, but with the appropriate VM hooks so that any 
page faults are handled as if for the user.  This way, the overhead 
of checking VMAs, etc, is only incurred if something out of the 
ordinary happens, and not on every access.  Is there a good 
reason *not* to do things this way?
__

Kevin D. Kissell
MIPS Technologies European Architecture Lab
kevink@mips.com
Tel. +33.4.78.38.70.67
FAX. +33.4.78.38.70.68




From Philip.Blundell@pobox.com  Mon Feb 28 14:03:41 2000
Received: from kings-cross.london.uk.eu.org (mail@tazenda.demon.co.uk [158.152.220.239]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id OAA23158; Mon, 28 Feb 2000 14:03:38 +0100 (MET)
Received-Date: Mon, 28 Feb 2000 14:03:38 +0100 (MET)
Received: from localhost
	([::ffff:127.0.0.1] helo=kings-cross.london.uk.eu.org ident=phil)
	by kings-cross.london.uk.eu.org with esmtp (Exim 3.11 #1)
	id 12PPpR-0000Cx-00; Mon, 28 Feb 2000 13:03:13 +0000
X-Mailer: exmh version 2.0.2 2/24/98 (debian) 
To: "Kevin D. Kissell" <kevink@mips.com>
cc: "Linux/MIPS fnet" <linux-mips@fnet.fr>,
        "Linux/MIPS algor" <linux-porters@algor.co.uk>,
        "Linux SGI" <linux@cthulhu.engr.sgi.com>
Subject: Re: Kernel/User Memory Access and Original Sin 
In-Reply-To: Message from "Kevin D. Kissell" <kevink@mips.com> 
   of "Mon, 28 Feb 2000 13:23:17 +0100." <010101bf81e6$9c546120$0ceca8c0@satanas.mips.com> 
References: <010101bf81e6$9c546120$0ceca8c0@satanas.mips.com> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Mon, 28 Feb 2000 13:03:13 +0000
From: Philip Blundell <Philip.Blundell@pobox.com>
Message-Id: <E12PPpR-0000Cx-00@kings-cross.london.uk.eu.org>
Content-Length: 854
Lines: 18

>the x86 VM implementation.   In the MIPS 2.2 and 2.3
>kernels, the check, __access_ok, is a simple heuristic
>that verifies that the access does not reference kernel
>memory, nor is it greater than 2GB in size.  That's cheap,
>but not reliable.  The primary failure mode I observed was 
>where signal.c blows up when trying to set up a signal context 
>on a corrupted user stack, but the problem is more pervasive.

The access_ok check is not supposed to be complete.  You need to also trap 
exceptions in get_user, put_user and so on - this goes for all architectures, 
not just MIPS.  Take a look at the hairy macros in asm/uaccess.h.

It sounds like this isn't working, but it's not cause for a complete redesign 
of the user-access mechanism.  In fact, what you are proposing sounds rather 
like the way these things were done in pre-2.2 days.

p.


From alan@lxorguk.ukuu.org.uk  Mon Feb 28 14:26:49 2000
Received: from the-village.bc.nu (lightning.swansea.uk.linux.org [194.168.151.1]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id OAA23742; Mon, 28 Feb 2000 14:26:42 +0100 (MET)
Received-Date: Mon, 28 Feb 2000 14:26:42 +0100 (MET)
Received: from alan by the-village.bc.nu with local (Exim 2.12 #1)
	id 12PQCX-0001uL-00; Mon, 28 Feb 2000 13:27:05 +0000
Subject: Re: Kernel/User Memory Access and Original Sin
To: kevink@mips.com (Kevin D. Kissell)
Date: Mon, 28 Feb 2000 13:27:02 +0000 (GMT)
Cc: linux-mips@fnet.fr (Linux/MIPS fnet),
        linux-porters@algor.co.uk (Linux/MIPS algor),
        linux@cthulhu.engr.sgi.com (Linux SGI)
In-Reply-To: <010101bf81e6$9c546120$0ceca8c0@satanas.mips.com> from "Kevin D. Kissell" at Feb 28, 2000 01:23: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: <E12PQCX-0001uL-00@the-village.bc.nu>
From: Alan Cox <alan@lxorguk.ukuu.org.uk>
Content-Length: 908
Lines: 22

> Linux, as written for the x86, goes very heavily for inlining.
> Rather than call specially protected copyin/copyout sorts
> of routines for manipulating user memory, Linux uses inline
> macros (copy_from_user/copy_to_user, etc.) that depend on

Its up to the port how it is done. Most of them are non inline for
x86 for example.

> __access_ok routine, but it is much more heavyweight
> than the old heuristic.  Not only does it need to check the
> virtual address against the process' VMAs, but it needs

Its broken if it does that. The process VMA may change on an SMP box or
during fault handling sleeps.

__access_ok has one purpose. To verify the address range given is entirely
sensible to feed to __copy_*_user. If you have to do handling the complex
way (eg if your cpu design requires it) then __access_ok can just return 1
and the __copy_*_user - inline or out of line - can do all the work.




From kevink@mips.com  Mon Feb 28 14:53:43 2000
Received: from mx.mips.com (mx.mips.com [206.31.31.226]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id OAA24357; Mon, 28 Feb 2000 14:53:42 +0100 (MET)
Received-Date: Mon, 28 Feb 2000 14:53:42 +0100 (MET)
Received: from newman.mips.com (newman [206.31.31.8])
	by mx.mips.com (8.9.3/8.9.0) with ESMTP id FAA09607;
	Mon, 28 Feb 2000 05:53:35 -0800 (PST)
Received: from satanas (satanas [192.168.236.12])
	by newman.mips.com (8.9.3/8.9.0) with SMTP id FAA26863;
	Mon, 28 Feb 2000 05:53:32 -0800 (PST)
Message-ID: <017a01bf81f3$92709130$0ceca8c0@satanas.mips.com>
From: "Kevin D. Kissell" <kevink@mips.com>
To: "Alan Cox" <alan@lxorguk.ukuu.org.uk>
Cc: "Linux/MIPS fnet" <linux-mips@fnet.fr>,
        "Linux/MIPS algor" <linux-porters@algor.co.uk>,
        "Linux SGI" <linux@cthulhu.engr.sgi.com>
Subject: Re: Kernel/User Memory Access and Original Sin
Date: Mon, 28 Feb 2000 14:56:04 +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 4.72.3110.5
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Content-Length: 609
Lines: 14

>__access_ok has one purpose. To verify the address range given is entirely
>sensible to feed to __copy_*_user. If you have to do handling the complex
>way (eg if your cpu design requires it) then __access_ok can just return 1
>and the __copy_*_user - inline or out of line - can do all the work.


Thanks.  I think I have localized the hole in the signal handling that
would have defeated these mechanisms, though another related
failure that was also solved by the sledgehammer __access_ok
remains mysterious.  I'll apply the more localized fix and repeat the 
crashme experiments...

            Kevin K.


From mbeaumont@lighthousegroup.com  Mon Feb 28 20:09:04 2000
Received: from pasexch.lighthousegroup.com ([208.237.149.234]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id UAA05589; Mon, 28 Feb 2000 20:09:02 +0100 (MET)
Received-Date: Mon, 28 Feb 2000 20:09:02 +0100 (MET)
From: mbeaumont@lighthousegroup.com
Received: by pasexch.lighthousegroup.com with Internet Mail Service (5.5.2650.21)
	id <DS7MRLA7>; Mon, 28 Feb 2000 11:01:50 -0800
Message-ID: <064E3FAD9554D311BAD600105A46E8E90447F4@pasexch.lighthousegroup.com>
To: linux-mips@fnet.fr
Subject: NETPOWER R4400
Date: Mon, 28 Feb 2000 11:01:49 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Length: 393
Lines: 9

I recently purchased several NETPOWER servers/workstations.  The machines
have R4400 dual processors installed  w/ 64K ram and 4Gb SCSI drive.  Modem,
NIC are installed.  Windows NT Server installed.  I want to use these
machines with a LINUX OS.  Will Linux run on this processor and where can I
download this ported software?

Your response is greatly appreciated.
Thanks,
Michael Beaumont 

From Mike.Wynn@insignia.com  Tue Feb 29 17:41:08 2000
Received: from gatekeeper.isltd.insignia.com (gatekeeper.isltd.insignia.com [195.153.60.130]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id RAA20026; Tue, 29 Feb 2000 17:41:07 +0100 (MET)
Received-Date: Tue, 29 Feb 2000 17:41:07 +0100 (MET)
Received: from wolf.isltd.insignia.com (wolf.isltd.insignia.com [193.112.16.10])
	by gatekeeper.isltd.insignia.com (8.9.3/8.9.3) with ESMTP id QAA26399
	for <linux-mips@fnet.fr>; Tue, 29 Feb 2000 16:40:36 GMT
Received: from isltd.insignia.com (luggage.isltd.insignia.com [193.112.17.47])
	by wolf.isltd.insignia.com (8.9.3/8.9.3) with ESMTP id QAA20581
	for <linux-mips@fnet.fr>; Tue, 29 Feb 2000 16:40:36 GMT
Sender: mike.wynn@insignia.com
Message-ID: <38BBF683.C6F56CC7@isltd.insignia.com>
Date: Tue, 29 Feb 2000 16:40:35 +0000
From: Mike Wynn <Mike.Wynn@insignia.com>
Organization: Insignia Ltd
X-Mailer: Mozilla 4.5 [en] (X11; I; FreeBSD 3.2-STABLE i386)
X-Accept-Language: en
MIME-Version: 1.0
To: linux-mips@fnet.fr
Subject: How do I get the latest Linux/Mips ?
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Length: 1073
Lines: 32

Any help here would be apriciated, the only experiance I have with Linux is
getting it running on X86 machines.

I have run pandora on my Mips Box which is labeled as a NetPower series 100
the results I get are as follows:

ARC Vendor ID            : [MIPS MAG]
ARC Product ID           : [0000e2025875004d]
ARC System ID            : [PICA-61]
ARC CPU ID               : [MIPS-R4000]
Processor type           : [R4400PC I04 V5.0]
Primary ICache size      : [0x4000 bytes]
Primary ICache line size : [0x0010 bytes]
Primary DCache size      : [0x4000 bytes]
Primary DCache line size : [0x0010 bytes]
Secondary cache size     : [unknown]
ARC System identified as : ACER PICA-61

I do know that this machine at one time ran NT 4, so i assume that it is a
little endian machine
(I believe I run the little endian pandora!)

I have installed the cross compiler binutils-2.7.3 and gcc-2.7.2-3 onto my
Linux 2.2.13-7 SMP x86 box
but have not used then yet!

are there newer linux mips binutils and gcc's availiable and/or kernal
images 

Thanks in advance for any help

Mike Wynn

From R.vandenBerg@inter.NL.net  Tue Feb 29 20:58:43 2000
Received: from altrade.nijmegen.inter.nl.net (altrade.nijmegen.inter.nl.net [193.67.237.6]) by guadalquivir.fnet.fr with ESMTP (8.8.8/97.02.12/Guadalquivir); id UAA21742; Tue, 29 Feb 2000 20:58:43 +0100 (MET)
Received-Date: Tue, 29 Feb 2000 20:58:43 +0100 (MET)
Received: from whale.dutch.mountain by altrade.nijmegen.inter.nl.net
	via hn51-16.Hoorn.NL.net [193.79.46.180] with ESMTP
	id UAA09435 (8.8.8/3.41); Tue, 29 Feb 2000 20:58:37 +0100 (MET)
Received: from localhost(really [127.0.0.1]) by whale.dutch.mountain
	via in.smtpd with smtp
	id <m12Psm5-00026iC@whale.dutch.mountain>
	for <linux-mips@fnet.fr>; Tue, 29 Feb 2000 20:57:41 +0100 (MET)
	(Smail-3.2 1996-Jul-4 #2 built 1996-Nov-26)
Date: Tue, 29 Feb 2000 20:57:40 +0100 (MET)
From: Richard van den Berg <R.vandenBerg@inter.NL.net>
X-Sender: ravdberg@whale.dutch.mountain
To: Mike Wynn <Mike.Wynn@insignia.com>
cc: linux-mips@fnet.fr
Subject: Re: How do I get the latest Linux/Mips ?
In-Reply-To: <38BBF683.C6F56CC7@isltd.insignia.com>
Message-ID: <Pine.LNX.3.95.1000229205716.1180B-100000@whale.dutch.mountain>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Content-Length: 1602
Lines: 49

On Tue, 29 Feb 2000, Mike Wynn wrote:

> I have installed the cross compiler binutils-2.7.3 and gcc-2.7.2-3 onto my
> Linux 2.2.13-7 SMP x86 box
> but have not used then yet!

If you're about to compile a recent kernel, you better upgrade these.

> are there newer linux mips binutils and gcc's availiable and/or kernal
> images 

I don't know about any image for your machine, there are certainly newer
cross-compile binaries available, from the HOWTO: 

-----

10.1 Available binaries

   The easist thing to setup a crosscompiler is to just download the binaries.
   For Linux/i386 hosts and big endian targets this are the packages:

  binutils-mips-linux-2.8.1-1.i386.rpm
  egcs-c++-mips-linux-1.0.3a-1.i386.rpm
  egcs-g77-mips-linux-1.0.3a-1.i386.rpm
  egcs-libstdc++-mips-linux-2.8.0-1.i386.rpm
  egcs-mips-linux-1.0.3a-1.i386.rpm
  egcs-objc-mips-linux-1.0.3a-1.i386.rpm

   And this is the list of packages for little endian targets:
  binutils-mipsel-linux-2.8.1-1.i386.rpm
  egcs-c++-mipsel-linux-1.0.3a-1.i386.rpm
  egcs-g77-mipsel-linux-1.0.3a-1.i386.rpm
  egcs-libstdc++-mipsel-linux-2.8.0-1.i386.rpm
  egcs-mipsel-linux-1.0.3a-1.i386.rpm
  egcs-objc-mipsel-linux-1.0.3a-1.i386.rpm

   It's not necessary that you install all these packages; most people can just
   omit the C++, Objective C and Fortran 77 compilers. The Intel binaries have
   been linked against GNU libc 2.1, so you may have to install that as well
   when upgrading. 

-----

This HOWTO is available at http://oss.sgi.com/mips/mips-howto.html and als
covers how to get the kernel source from cvs. 

Regards,

Richard