From chamakmann@yahoo.co.in Thu Jan  2 03:57:13 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 02 Jan 2003 03:57:13 +0000 (GMT)
Received: from web8204.mail.in.yahoo.com ([IPv6:::ffff:203.199.70.124]:15908
	"HELO web8204.mail.in.yahoo.com") by linux-mips.org with SMTP
	id <S8225970AbTABD5N>; Thu, 2 Jan 2003 03:57:13 +0000
Message-ID: <20030102035704.91069.qmail@web8204.mail.in.yahoo.com>
Received: from [203.145.184.209] by web8204.mail.in.yahoo.com via HTTP; Thu, 02 Jan 2003 03:57:04 GMT
Date: Thu, 2 Jan 2003 03:57:04 +0000 (GMT)
From: =?iso-8859-1?q?chamak=20man?= <chamakmann@yahoo.co.in>
Subject: System Call in MIPS
To: linux-mips@linux-mips.org
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Return-Path: <chamakmann@yahoo.co.in>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1075
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: chamakmann@yahoo.co.in
Precedence: bulk
X-list: linux-mips

Hi,

   I am finding problems in adding a new system call
for MIPS kernel.  Where can i get information on it. 

with regards,
sumanth.g



________________________________________________________________________
Missed your favourite TV serial last night? Try the new, Yahoo! TV.
       visit http://in.tv.yahoo.com

From ralf@linux-mips.org Thu Jan  2 11:05:39 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 02 Jan 2003 11:05:39 +0000 (GMT)
Received: from p508B5BAC.dip.t-dialin.net ([IPv6:::ffff:80.139.91.172]:35296
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225687AbTABLFj>; Thu, 2 Jan 2003 11:05:39 +0000
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.11.6/8.11.6) id h02B5Su14781;
	Thu, 2 Jan 2003 12:05:28 +0100
Date: Thu, 2 Jan 2003 12:05:28 +0100
From: Ralf Baechle <ralf@linux-mips.org>
To: chamak man <chamakmann@yahoo.co.in>
Cc: linux-mips@linux-mips.org
Subject: Re: System Call in MIPS
Message-ID: <20030102120528.A7401@linux-mips.org>
References: <20030102035704.91069.qmail@web8204.mail.in.yahoo.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5.1i
In-Reply-To: <20030102035704.91069.qmail@web8204.mail.in.yahoo.com>; from chamakmann@yahoo.co.in on Thu, Jan 02, 2003 at 03:57:04AM +0000
Return-Path: <ralf@linux-mips.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1076
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips

On Thu, Jan 02, 2003 at 03:57:04AM +0000, chamak man wrote:

>    I am finding problems in adding a new system call
> for MIPS kernel.  Where can i get information on it. 

See include include/asm-mips/unistd.h and arch/mips/kernel/scall_o32.S.

In general adding new syscalls is considered a bad idea you may want to
look into using ioctl, sysctl(2) or procfs.

  Ralf

From nmckee@telogy.com Thu Jan  2 15:44:15 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 02 Jan 2003 15:44:16 +0000 (GMT)
Received: from [IPv6:::ffff:209.116.120.7] ([IPv6:::ffff:209.116.120.7]:2320
	"EHLO tnint11.telogy.design.ti.com") by linux-mips.org with ESMTP
	id <S8225689AbTABPoP>; Thu, 2 Jan 2003 15:44:15 +0000
Received: by tnint11.telogy.design.ti.com with Internet Mail Service (5.5.2653.19)
	id <WY1Z4JYL>; Thu, 2 Jan 2003 10:42:06 -0500
Message-ID: <37A3C2F21006D611995100B0D0F9B73CBFE3E1@tnint11.telogy.design.ti.com>
From: "Zajerko-McKee, Nick" <nmckee@telogy.com>
To: 'chamak man' <chamakmann@yahoo.co.in>, linux-mips@linux-mips.org
Subject: RE: System Call in MIPS
Date: Thu, 2 Jan 2003 10:42:05 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Return-Path: <nmckee@telogy.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1077
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: nmckee@telogy.com
Precedence: bulk
X-list: linux-mips

One thing to check is if unistd.h matches whats in the syscall table.  In
2.4.17 I was working with, there were more entries in the defines than in
the table so when I added my calls they went to never never land...

-----Original Message-----
From: chamak man [mailto:chamakmann@yahoo.co.in]
Sent: Wednesday, January 01, 2003 10:57 PM
To: linux-mips@linux-mips.org
Subject: System Call in MIPS


Hi,

   I am finding problems in adding a new system call
for MIPS kernel.  Where can i get information on it. 

with regards,
sumanth.g



________________________________________________________________________
Missed your favourite TV serial last night? Try the new, Yahoo! TV.
       visit http://in.tv.yahoo.com

From quintela@mandrakesoft.com Thu Jan  2 19:26:11 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 02 Jan 2003 19:26:12 +0000 (GMT)
Received: from cm19173.red.mundo-r.com ([IPv6:::ffff:213.60.19.173]:56001 "EHLO
	demo.mitica") by linux-mips.org with ESMTP id <S8225692AbTABT0L>;
	Thu, 2 Jan 2003 19:26:11 +0000
Received: by demo.mitica (Postfix, from userid 501)
	id C6E35D657; Thu,  2 Jan 2003 20:33:30 +0100 (CET)
To: Ralf Baechle <ralf@linux-mips.org>,
	mipslist <linux-mips@linux-mips.org>
Subject: [PATCH]: fix possible buffer overflow problem in promlib
X-Url: http://people.mandrakesoft.com/~quintela
From: Juan Quintela <quintela@mandrakesoft.com>
Date: 02 Jan 2003 20:33:30 +0100
Message-ID: <m2hecrbb3p.fsf@demo.mitica>
Lines: 72
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Return-Path: <quintela@mandrakesoft.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1078
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: quintela@mandrakesoft.com
Precedence: bulk
X-list: linux-mips


Hi
        as the issue about prom.h is still not clear, please aply the
        trivial part.

        32 and 64 bits patch.

Later, Juan.

Index: arch/mips64/lib/promlib.c
===================================================================
RCS file: /home/cvs/linux/arch/mips64/lib/promlib.c,v
retrieving revision 1.1.2.1
diff -u -r1.1.2.1 promlib.c
--- arch/mips64/lib/promlib.c	28 Sep 2002 22:28:38 -0000	1.1.2.1
+++ arch/mips64/lib/promlib.c	20 Dec 2002 19:10:45 -0000
@@ -1,13 +1,19 @@
+
+
+#include <linux/kernel.h>
+
 #include <stdarg.h>
 
+#define BUFSIZE 1024
+
 void prom_printf(char *fmt, ...)
 {
 	va_list args;
-	char ppbuf[1024];
+	char ppbuf[BUFSIZE];
 	char *bptr;
 
 	va_start(args, fmt);
-	vsprintf(ppbuf, fmt, args);
+	vsnprintf(ppbuf, BUFSIZE, fmt, args);
 
 	bptr = ppbuf;
 
Index: arch/mips/lib/promlib.c
===================================================================
RCS file: /home/cvs/linux/arch/mips/lib/promlib.c,v
retrieving revision 1.1.2.1
diff -u -r1.1.2.1 promlib.c
--- arch/mips/lib/promlib.c	28 Sep 2002 22:28:38 -0000	1.1.2.1
+++ arch/mips/lib/promlib.c	20 Dec 2002 19:10:43 -0000
@@ -1,13 +1,19 @@
+
+
+#include <linux/kernel.h>
+
 #include <stdarg.h>
 
+#define BUFSIZE 1024
+
 void prom_printf(char *fmt, ...)
 {
 	va_list args;
-	char ppbuf[1024];
+	char ppbuf[BUFSIZE];
 	char *bptr;
 
 	va_start(args, fmt);
-	vsprintf(ppbuf, fmt, args);
+	vsnprintf(ppbuf, BUFSIZE, fmt, args);
 
 	bptr = ppbuf;
 


-- 
In theory, practice and theory are the same, but in practice they 
are different -- Larry McVoy

From Geert.Uytterhoeven@sonycom.com Thu Jan  2 19:51:16 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 02 Jan 2003 19:51:16 +0000 (GMT)
Received: from mail2.sonytel.be ([IPv6:::ffff:195.0.45.172]:10672 "EHLO
	mail.sonytel.be") by linux-mips.org with ESMTP id <S8225694AbTABTvQ>;
	Thu, 2 Jan 2003 19:51:16 +0000
Received: from vervain.sonytel.be (mail.sonytel.be [10.17.0.27])
	by mail.sonytel.be (8.9.0/8.8.6) with ESMTP id UAA07041;
	Thu, 2 Jan 2003 20:47:50 +0100 (MET)
Date: Thu, 2 Jan 2003 20:47:49 +0100 (MET)
From: Geert Uytterhoeven <geert@linux-m68k.org>
To: Juan Quintela <quintela@mandrakesoft.com>
cc: Ralf Baechle <ralf@linux-mips.org>,
	mipslist <linux-mips@linux-mips.org>
Subject: Re: [PATCH]: fix possible buffer overflow problem in promlib
In-Reply-To: <m2hecrbb3p.fsf@demo.mitica>
Message-ID: <Pine.GSO.4.21.0301022047090.4873-100000@vervain.sonytel.be>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <Geert.Uytterhoeven@sonycom.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1079
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: geert@linux-m68k.org
Precedence: bulk
X-list: linux-mips

On 2 Jan 2003, Juan Quintela wrote:
>         as the issue about prom.h is still not clear, please aply the
>         trivial part.

>  void prom_printf(char *fmt, ...)
>  {
>  	va_list args;
> -	char ppbuf[1024];
> +	char ppbuf[BUFSIZE];

What about making ppbuf static, to reduce stack usage?

Gr{oetje,eeting}s,

						Geert

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

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


From ppopov@mvista.com Fri Jan  3 10:27:47 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 03 Jan 2003 10:27:48 +0000 (GMT)
Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:20206 "EHLO
	av.mvista.com") by linux-mips.org with ESMTP id <S8225702AbTACK1r>;
	Fri, 3 Jan 2003 10:27:47 +0000
Received: from localhost (av [127.0.0.1])
	by av.mvista.com (8.9.3/8.9.3) with ESMTP id CAA26202
	for <linux-mips@linux-mips.org>; Fri, 3 Jan 2003 02:27:26 -0800
Subject: unaligned handler problem
From: Pete Popov <ppopov@mvista.com>
To: linux-mips <linux-mips@linux-mips.org>
Content-Type: text/plain
Organization: MontaVista Software
Message-Id: <1041589762.18883.4.camel@adsl.pacbell.net>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.2.1 
Date: 03 Jan 2003 02:29:22 -0800
Content-Transfer-Encoding: 7bit
Return-Path: <ppopov@mvista.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1080
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ppopov@mvista.com
Precedence: bulk
X-list: linux-mips

The changes betwen rev 1.23 and 1.24 in unaligned.c, to replace
check_axs() with verify_area(), causes any unaligned access from within
a kernel module to crash. access_ok() returns -EFAULT as the
__access_mask is 0xffffffff so __access_ok evaluates to > 0.  It's too
late for me to look into it any further but perhaps the problem will be
obvious to someone else. I'm not sure what get_fs() should return in
this case (again, the access is from within a kernel module) but it
returns 0xffffffff.

Pete


From ralf@linux-mips.org Fri Jan  3 12:54:44 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 03 Jan 2003 12:54:45 +0000 (GMT)
Received: from p508B705C.dip.t-dialin.net ([IPv6:::ffff:80.139.112.92]:45186
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225973AbTACMyo>; Fri, 3 Jan 2003 12:54:44 +0000
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.11.6/8.11.6) id h03CsNN07917;
	Fri, 3 Jan 2003 13:54:23 +0100
Date: Fri, 3 Jan 2003 13:54:23 +0100
From: Ralf Baechle <ralf@linux-mips.org>
To: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Juan Quintela <quintela@mandrakesoft.com>,
	mipslist <linux-mips@linux-mips.org>
Subject: Re: [PATCH]: fix possible buffer overflow problem in promlib
Message-ID: <20030103135422.A7796@linux-mips.org>
References: <m2hecrbb3p.fsf@demo.mitica> <Pine.GSO.4.21.0301022047090.4873-100000@vervain.sonytel.be>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5.1i
In-Reply-To: <Pine.GSO.4.21.0301022047090.4873-100000@vervain.sonytel.be>; from geert@linux-m68k.org on Thu, Jan 02, 2003 at 08:47:49PM +0100
Return-Path: <ralf@linux-mips.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1081
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips

On Thu, Jan 02, 2003 at 08:47:49PM +0100, Geert Uytterhoeven wrote:

> On 2 Jan 2003, Juan Quintela wrote:
> >         as the issue about prom.h is still not clear, please aply the
> >         trivial part.
> 
> >  void prom_printf(char *fmt, ...)
> >  {
> >  	va_list args;
> > -	char ppbuf[1024];
> > +	char ppbuf[BUFSIZE];
> 
> What about making ppbuf static, to reduce stack usage?

By the time when prom_printf() is called stack overflow is not really a
consideration anymore, something fatal has happened before.

prom_printf() is our own variant of early_print() so eventually should
be replaced by that anyway.

  Ralf

From ralf@linux-mips.org Fri Jan  3 13:46:19 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 03 Jan 2003 13:46:20 +0000 (GMT)
Received: from p508B705C.dip.t-dialin.net ([IPv6:::ffff:80.139.112.92]:14723
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225976AbTACNqT>; Fri, 3 Jan 2003 13:46:19 +0000
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.11.6/8.11.6) id h03DkFE08978;
	Fri, 3 Jan 2003 14:46:15 +0100
Date: Fri, 3 Jan 2003 14:46:15 +0100
From: Ralf Baechle <ralf@linux-mips.org>
To: Pete Popov <ppopov@mvista.com>
Cc: linux-mips <linux-mips@linux-mips.org>
Subject: Re: unaligned handler problem
Message-ID: <20030103144615.A8482@linux-mips.org>
References: <1041589762.18883.4.camel@adsl.pacbell.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5.1i
In-Reply-To: <1041589762.18883.4.camel@adsl.pacbell.net>; from ppopov@mvista.com on Fri, Jan 03, 2003 at 02:29:22AM -0800
Return-Path: <ralf@linux-mips.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1082
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips

On Fri, Jan 03, 2003 at 02:29:22AM -0800, Pete Popov wrote:

> The changes betwen rev 1.23 and 1.24 in unaligned.c, to replace
> check_axs() with verify_area(), causes any unaligned access from within
> a kernel module to crash. access_ok() returns -EFAULT as the
> __access_mask is 0xffffffff so __access_ok evaluates to > 0.  It's too
> late for me to look into it any further but perhaps the problem will be
> obvious to someone else. I'm not sure what get_fs() should return in
> this case (again, the access is from within a kernel module) but it
> returns 0xffffffff.

The address error handler should do something like:

	mm_segment_t seg;

	seg = get_fs();
	if (!user_mode(regs))
		set_fs(KERNEL_DS);

	... usual unaligned stuff goes here ...

	set_fs(seg);

  Ralf

From ica2_ts@csv.ica.uni-stuttgart.de Fri Jan  3 14:30:00 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 03 Jan 2003 14:30:01 +0000 (GMT)
Received: from iris1.csv.ica.uni-stuttgart.de ([IPv6:::ffff:129.69.118.2]:56655
	"EHLO iris1.csv.ica.uni-stuttgart.de") by linux-mips.org with ESMTP
	id <S8225978AbTACOaA>; Fri, 3 Jan 2003 14:30:00 +0000
Received: from rembrandt.csv.ica.uni-stuttgart.de ([129.69.118.42])
	by iris1.csv.ica.uni-stuttgart.de with esmtp (Exim 3.36 #2)
	id 18USpg-000fgY-00; Fri, 03 Jan 2003 15:29:56 +0100
Received: from ica2_ts by rembrandt.csv.ica.uni-stuttgart.de with local (Exim 3.35 #1 (Debian))
	id 18USpg-0006ej-00; Fri, 03 Jan 2003 15:29:56 +0100
Date: Fri, 3 Jan 2003 15:29:56 +0100
To: Ralf Baechle <ralf@linux-mips.org>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>,
	Juan Quintela <quintela@mandrakesoft.com>,
	mipslist <linux-mips@linux-mips.org>
Subject: Re: [PATCH]: fix possible buffer overflow problem in promlib
Message-ID: <20030103142956.GI31256@rembrandt.csv.ica.uni-stuttgart.de>
References: <m2hecrbb3p.fsf@demo.mitica> <Pine.GSO.4.21.0301022047090.4873-100000@vervain.sonytel.be> <20030103135422.A7796@linux-mips.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20030103135422.A7796@linux-mips.org>
User-Agent: Mutt/1.4i
From: Thiemo Seufer <ica2_ts@csv.ica.uni-stuttgart.de>
Return-Path: <ica2_ts@csv.ica.uni-stuttgart.de>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1083
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ica2_ts@csv.ica.uni-stuttgart.de
Precedence: bulk
X-list: linux-mips

Ralf Baechle wrote:
> On Thu, Jan 02, 2003 at 08:47:49PM +0100, Geert Uytterhoeven wrote:
> 
> > On 2 Jan 2003, Juan Quintela wrote:
> > >         as the issue about prom.h is still not clear, please aply the
> > >         trivial part.
> > 
> > >  void prom_printf(char *fmt, ...)
> > >  {
> > >  	va_list args;
> > > -	char ppbuf[1024];
> > > +	char ppbuf[BUFSIZE];
> > 
> > What about making ppbuf static, to reduce stack usage?
> 
> By the time when prom_printf() is called stack overflow is not really a
> consideration anymore, something fatal has happened before.

I don't think printing e.g. "LINUX started..." indicates something fatal. :-)


Thiemo

From ralf@linux-mips.org Fri Jan  3 15:48:40 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 03 Jan 2003 15:48:41 +0000 (GMT)
Received: from p508B6E6D.dip.t-dialin.net ([IPv6:::ffff:80.139.110.109]:22661
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225980AbTACPsk>; Fri, 3 Jan 2003 15:48:40 +0000
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.11.6/8.11.6) id h03FmWx11578;
	Fri, 3 Jan 2003 16:48:32 +0100
Date: Fri, 3 Jan 2003 16:48:32 +0100
From: Ralf Baechle <ralf@linux-mips.org>
To: Thiemo Seufer <ica2_ts@csv.ica.uni-stuttgart.de>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>,
	Juan Quintela <quintela@mandrakesoft.com>,
	mipslist <linux-mips@linux-mips.org>
Subject: Re: [PATCH]: fix possible buffer overflow problem in promlib
Message-ID: <20030103164832.A11536@linux-mips.org>
References: <m2hecrbb3p.fsf@demo.mitica> <Pine.GSO.4.21.0301022047090.4873-100000@vervain.sonytel.be> <20030103135422.A7796@linux-mips.org> <20030103142956.GI31256@rembrandt.csv.ica.uni-stuttgart.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5.1i
In-Reply-To: <20030103142956.GI31256@rembrandt.csv.ica.uni-stuttgart.de>; from ica2_ts@csv.ica.uni-stuttgart.de on Fri, Jan 03, 2003 at 03:29:56PM +0100
Return-Path: <ralf@linux-mips.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1084
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips

On Fri, Jan 03, 2003 at 03:29:56PM +0100, Thiemo Seufer wrote:

> > > What about making ppbuf static, to reduce stack usage?
> > 
> > By the time when prom_printf() is called stack overflow is not really a
> > consideration anymore, something fatal has happened before.
> 
> I don't think printing e.g. "LINUX started..." indicates something fatal. :-)

So use printk :-)

  Ralf

From ica2_ts@csv.ica.uni-stuttgart.de Fri Jan  3 15:58:34 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 03 Jan 2003 15:58:35 +0000 (GMT)
Received: from iris1.csv.ica.uni-stuttgart.de ([IPv6:::ffff:129.69.118.2]:6992
	"EHLO iris1.csv.ica.uni-stuttgart.de") by linux-mips.org with ESMTP
	id <S8225980AbTACP6e>; Fri, 3 Jan 2003 15:58:34 +0000
Received: from rembrandt.csv.ica.uni-stuttgart.de ([129.69.118.42])
	by iris1.csv.ica.uni-stuttgart.de with esmtp (Exim 3.36 #2)
	id 18UUDR-000fsd-00; Fri, 03 Jan 2003 16:58:33 +0100
Received: from ica2_ts by rembrandt.csv.ica.uni-stuttgart.de with local (Exim 3.35 #1 (Debian))
	id 18UUDQ-0006nX-00; Fri, 03 Jan 2003 16:58:32 +0100
Date: Fri, 3 Jan 2003 16:58:32 +0100
To: Ralf Baechle <ralf@linux-mips.org>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>,
	Juan Quintela <quintela@mandrakesoft.com>,
	mipslist <linux-mips@linux-mips.org>
Subject: Re: [PATCH]: fix possible buffer overflow problem in promlib
Message-ID: <20030103155832.GN31256@rembrandt.csv.ica.uni-stuttgart.de>
References: <m2hecrbb3p.fsf@demo.mitica> <Pine.GSO.4.21.0301022047090.4873-100000@vervain.sonytel.be> <20030103135422.A7796@linux-mips.org> <20030103142956.GI31256@rembrandt.csv.ica.uni-stuttgart.de> <20030103164832.A11536@linux-mips.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20030103164832.A11536@linux-mips.org>
User-Agent: Mutt/1.4i
From: Thiemo Seufer <ica2_ts@csv.ica.uni-stuttgart.de>
Return-Path: <ica2_ts@csv.ica.uni-stuttgart.de>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1085
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ica2_ts@csv.ica.uni-stuttgart.de
Precedence: bulk
X-list: linux-mips

Ralf Baechle wrote:
> On Fri, Jan 03, 2003 at 03:29:56PM +0100, Thiemo Seufer wrote:
> 
> > > > What about making ppbuf static, to reduce stack usage?
> > > 
> > > By the time when prom_printf() is called stack overflow is not really a
> > > consideration anymore, something fatal has happened before.
> > 
> > I don't think printing e.g. "LINUX started..." indicates something fatal. :-)
> 
> So use printk :-)

printk might not be ready at that time. I grepped the example from
arch/mips/mips-boards/generic/init.c, and there are some more
occurences in arch/mips which seem to be non-fatal.


Thiemo

From cwu@deltartp.com Fri Jan  3 21:10:49 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 03 Jan 2003 21:10:50 +0000 (GMT)
Received: from 216-166-237-83.clec.madisonriver.net ([IPv6:::ffff:216.166.237.83]:44037
	"EHLO dpr338") by linux-mips.org with ESMTP id <S8225986AbTACVKt>;
	Fri, 3 Jan 2003 21:10:49 +0000
Received: from dprn03.deltartp.com ([216.166.210.181]) by 216.166.237.83 with InterScan Messaging Security Suite; Fri, 03 Jan 2003 16:16:56 -0800
Received: by dprn03.deltartp.com with Internet Mail Service (5.5.2653.19)
	id <YQ1SVA26>; Fri, 3 Jan 2003 15:52:35 -0500
Message-ID: <A4E787A2467EF849B00585F14C9005590689BF@dprn03.deltartp.com>
From: Chien-Lung Wu <cwu@deltartp.com>
To: "'linux-mips@linux-mips.org'" <linux-mips@linux-mips.org>
Subject: glibc-2.2.5  configuration error (cross-compiler)
Date: Fri, 3 Jan 2003 15:52:29 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Return-Path: <cwu@deltartp.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1086
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: cwu@deltartp.com
Precedence: bulk
X-list: linux-mips


Hi, 

I try to build a cross-compiler for mips-linux for mips target (idt32332).

I followed the instruction of Bradley D. LaRonde (thanks)
 http://www.ltc.com/~brad/mips/mips-cross-toolchain/

I downloaded :

	binutils-2.13
	gcc-2.95.3
	glibc-2.2.5 and glibc-linuxthreads-2.2.5

and my build system is gcc version 2.96 20000731 (Red Hat Linux 7.1 2.96-98)
and gmake 3.79.1.

As I compiled and install binutils-2.13 and gcc-2.95.3 (1th time),
everything is fine. However, as I configured
glibc-2-2.5 following the instruction:
tar -xzf glibc-2.2.5.tar.gz 
cd glibc-2.2.5
 patch -i ../glibc-2.2.5-mips-build-gmon.diff 
tar -xzf ../glibc-linuxthreads-2.2.5.tar.gz cd .. 
mkdir mips-glibc-2.2.5-1-3
 cd mips-glibc-2.2.5-1-3
 CFLAGS="-O2 -g -finline-limit=10000" ../glibc-2.2.5/configure
--build=i686-linux \
  --host=mips-linux --enable-add-ons --prefix=/usr 
I got error as following:
////// error output //////
loading cache ./config.cache
checking host system type... mips-mips-linux-gnu
checking sysdep dirs... sysdeps/mips/elf
linuxthreads/sysdeps/unix/sysv/linux linuxthreads/sysdeps/pthread
sysdeps/pthread linuxthreads/sysdeps/unix/sysv linuxthreads/sysdeps/unix
linuxthreads/sysdeps/mips sysdeps/unix/sysv/linux/mips
sysdeps/unix/sysv/linux sysdeps/gnu sysdeps/unix/common sysdeps/unix/mman
sysdeps/unix/inet sysdeps/unix/sysv sysdeps/unix/mips sysdeps/unix
sysdeps/posix sysdeps/mips/fpu sysdeps/mips sysdeps/wordsize-32
sysdeps/ieee754/flt-32 sysdeps/ieee754/dbl-64 sysdeps/ieee754
sysdeps/generic/elf sysdeps/generic
checking for a BSD compatible install... /usr/bin/install -c
checking whether ln -s works... yes
checking for pwd... /bin/pwd
checking build system type... i686-pc-linux-gnu
checking for mips-linux-gcc... no
checking for mips-linux-cc... no
checking for gnumake... no
checking for gmake... gmake
checking version of gmake... 3.79.1, ok

*** These critical programs are missing or too old:gcc
*** Check the INSTALL file for required versions.
[root@dpr211 mips-glibc-2.2.5-1-3]# 
//// end of error output /////

As i compiled and install cross-compiler, I use the option
--prfix=/usr/xmips-1-3, that means I will
install the cross-compiler in the directory /usr/xmips-1-3. And I also check
tools and mips-linux-gcc are on my cross-compiler directory
/usr/xmips-1-3/bin.

My question is why I got the message:
	checking for mips-linux-gcc... no
	checking for mips-linux-cc... no
And how can I set up path such that this configure can find them.

Another question is the configure error.
I check the INSTALL to make sure the gcc version. It requires gcc 2.95 or
newer.
I check my host gcc is 2.96 and cross-compiler gcc is 2.95.3. 
Why do I get the configure error:
*** These critical programs are missing or too old:gcc
*** Check the INSTALL file for required versions.

Any solution to fix it. Thanks.

Chien-Lung











From quintela@mandrakesoft.com Fri Jan  3 23:51:56 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 03 Jan 2003 23:51:57 +0000 (GMT)
Received: from cm19173.red.mundo-r.com ([IPv6:::ffff:213.60.19.173]:8904 "EHLO
	demo.mitica") by linux-mips.org with ESMTP id <S8225989AbTACXv4>;
	Fri, 3 Jan 2003 23:51:56 +0000
Received: by demo.mitica (Postfix, from userid 501)
	id 9BA97D657; Sat,  4 Jan 2003 00:59:22 +0100 (CET)
To: Chien-Lung Wu <cwu@deltartp.com>
Cc: "'linux-mips@linux-mips.org'" <linux-mips@linux-mips.org>
Subject: Re: glibc-2.2.5  configuration error (cross-compiler)
References: <A4E787A2467EF849B00585F14C9005590689BF@dprn03.deltartp.com>
X-Url: http://people.mandrakesoft.com/~quintela
From: Juan Quintela <quintela@mandrakesoft.com>
In-Reply-To: <A4E787A2467EF849B00585F14C9005590689BF@dprn03.deltartp.com>
Date: 04 Jan 2003 00:59:22 +0100
Message-ID: <m27kdlbx9h.fsf@demo.mitica>
Lines: 25
User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2.92
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Return-Path: <quintela@mandrakesoft.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1087
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: quintela@mandrakesoft.com
Precedence: bulk
X-list: linux-mips

>>>>> "chien-lung" == Chien-Lung Wu <cwu@deltartp.com> writes:

Hi

chien-lung> As i compiled and install cross-compiler, I use the option
chien-lung> --prfix=/usr/xmips-1-3, that means I will
              ^^^^^
I guess prefix :)

chien-lung> install the cross-compiler in the directory /usr/xmips-1-3. And I also check
chien-lung> tools and mips-linux-gcc are on my cross-compiler directory
chien-lung> /usr/xmips-1-3/bin.

chien-lung> My question is why I got the message:
chien-lung> checking for mips-linux-gcc... no
chien-lung> checking for mips-linux-cc... no
chien-lung> And how can I set up path such that this configure can find them.

Are you sure that /usr/xmips-1-3/bin is in your path?

Later, Juan.

-- 
In theory, practice and theory are the same, but in practice they 
are different -- Larry McVoy

From ppopov@mvista.com Mon Jan  6 11:58:09 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 06 Jan 2003 11:58:09 +0000 (GMT)
Received: from p508B7CBF.dip.t-dialin.net ([IPv6:::ffff:80.139.124.191]:19658
	"EHLO p508B7CBF.dip.t-dialin.net") by linux-mips.org with ESMTP
	id <S8225896AbTAFL6J>; Mon, 6 Jan 2003 11:58:09 +0000
Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:51187 "EHLO
	av.mvista.com") by ralf.linux-mips.org with ESMTP
	id <S869794AbTAEBjq>; Sun, 5 Jan 2003 02:39:46 +0100
Received: from localhost (av [127.0.0.1])
	by av.mvista.com (8.9.3/8.9.3) with ESMTP id MAA05799;
	Sat, 4 Jan 2003 12:25:23 -0800
Subject: PATCH:  unaligned handler problem
From: Pete Popov <ppopov@mvista.com>
To: Ralf Baechle <ralf@linux-mips.org>
Cc: linux-mips <linux-mips@linux-mips.org>
In-Reply-To: <20030103144615.A8482@linux-mips.org>
References: <1041589762.18883.4.camel@adsl.pacbell.net>
	 <20030103144615.A8482@linux-mips.org>
Content-Type: text/plain
Organization: MontaVista Software
Message-Id: <1041711952.29512.4.camel@adsl.pacbell.net>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.2.1 
Date: 04 Jan 2003 12:25:52 -0800
Content-Transfer-Encoding: 7bit
Return-Path: <ppopov@mvista.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1088
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ppopov@mvista.com
Precedence: bulk
X-list: linux-mips

On Fri, 2003-01-03 at 05:46, Ralf Baechle wrote:
> On Fri, Jan 03, 2003 at 02:29:22AM -0800, Pete Popov wrote:
> 
> > The changes betwen rev 1.23 and 1.24 in unaligned.c, to replace
> > check_axs() with verify_area(), causes any unaligned access from within
> > a kernel module to crash. access_ok() returns -EFAULT as the
> > __access_mask is 0xffffffff so __access_ok evaluates to > 0.  It's too
> > late for me to look into it any further but perhaps the problem will be
> > obvious to someone else. I'm not sure what get_fs() should return in
> > this case (again, the access is from within a kernel module) but it
> > returns 0xffffffff.
> 
> The address error handler should do something like:
> 
> 	mm_segment_t seg;
> 
> 	seg = get_fs();
> 	if (!user_mode(regs))
> 		set_fs(KERNEL_DS);
> 
> 	... usual unaligned stuff goes here ...
> 
> 	set_fs(seg);

Thanks! The patch below works. I had a test case plus a pcmcia driver that was
crashing, and now they both pass.


--- linux-2.4-head/arch/mips/kernel/unaligned.c	Thu Dec 26 21:35:00 2002
+++ linux-2.4-dev/arch/mips/kernel/unaligned.c	Sat Jan  4 12:21:06 2003
@@ -98,6 +98,11 @@
 	union mips_instruction insn;
 	unsigned long value, fixup;
 	unsigned int res;
+	mm_segment_t seg;
+
+	seg = get_fs();
+	if (!user_mode(regs))
+		set_fs(KERNEL_DS);
 
 	regs->regs[0] = 0;
 	/*
@@ -458,6 +463,7 @@
 	unaligned_instructions++;
 #endif
 
+	set_fs(seg);
 	return;
 
 fault:
@@ -469,24 +475,28 @@
 		printk(KERN_DEBUG "%s: Forwarding exception at [<%lx>] (%lx)\n",
 		       current->comm, regs->cp0_epc, new_epc);
 		regs->cp0_epc = new_epc;
+		set_fs(seg);
 		return;
 	}
 
 	die_if_kernel ("Unhandled kernel unaligned access", regs);
 	send_sig(SIGSEGV, current, 1);
 
+	set_fs(seg);
 	return;
 
 sigbus:
 	die_if_kernel("Unhandled kernel unaligned access", regs);
 	send_sig(SIGBUS, current, 1);
 
+	set_fs(seg);
 	return;
 
 sigill:
 	die_if_kernel("Unhandled kernel unaligned access or invalid instruction", regs);
 	send_sig(SIGILL, current, 1);
 
+	set_fs(seg);
 	return;
 }
 




From cwu@deltartp.com Mon Jan  6 21:11:55 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 06 Jan 2003 21:11:56 +0000 (GMT)
Received: from 216-166-237-83.clec.madisonriver.net ([IPv6:::ffff:216.166.237.83]:49156
	"EHLO dpr338") by linux-mips.org with ESMTP id <S8225993AbTAFVLz>;
	Mon, 6 Jan 2003 21:11:55 +0000
Received: from dprn03.deltartp.com ([216.166.210.181]) by 216.166.237.83 with InterScan Messaging Security Suite; Mon, 06 Jan 2003 16:19:23 -0800
Received: by dprn03.deltartp.com with Internet Mail Service (5.5.2653.19)
	id <YQ1SVFCQ>; Mon, 6 Jan 2003 15:54:50 -0500
Message-ID: <A4E787A2467EF849B00585F14C9005590689C1@dprn03.deltartp.com>
From: Chien-Lung Wu <cwu@deltartp.com>
To: "'linux-mips@linux-mips.org'" <linux-mips@linux-mips.org>
Subject: Cross-compiler: glibc-2.2.5 compiling error
Date: Mon, 6 Jan 2003 15:54:49 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Return-Path: <cwu@deltartp.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1089
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: cwu@deltartp.com
Precedence: bulk
X-list: linux-mips



Hi, 

I am working on the cross-compiler for mips target.
I uses:
	binutil-2.13.10
	gcc-2.95.3
	glibc-2.2.5.

I installed the binutils in /usr/xmips-1-2
and get the first phase of gcc compiled and installed on the same directory.

Now when I compile glibc-2.2.5, I got the following error:

/*error message */
mips-linux-gcc   -shared  -Wl,-O1  -Wl,-dynamic-linker=/lib/ld.so.1
-B/home/cross-compiler/mips-glibc-2.2.5-1-6/csu/
-Wl,--version-script=/home/cross-compiler/mips-glibc-2.2.5-1-6/libc.map
-Wl,-soname=libc.so.6  -nostdlib -nostartfiles -e __libc_main -u
__register_frame -L/home/cross-compiler/mips-glibc-2.2.5-1-6
-L/home/cross-compiler/mips-glibc-2.2.5-1-6/math
-L/home/cross-compiler/mips-glibc-2.2.5-1-6/elf
-L/home/cross-compiler/mips-glibc-2.2.5-1-6/dlfcn
-L/home/cross-compiler/mips-glibc-2.2.5-1-6/nss
-L/home/cross-compiler/mips-glibc-2.2.5-1-6/nis
-L/home/cross-compiler/mips-glibc-2.2.5-1-6/rt
-L/home/cross-compiler/mips-glibc-2.2.5-1-6/resolv
-L/home/cross-compiler/mips-glibc-2.2.5-1-6/crypt
-L/home/cross-compiler/mips-glibc-2.2.5-1-6/linuxthreads
-Wl,-rpath-link=/home/cross-compiler/mips-glibc-2.2.5-1-6:/home/cross-compil
er/mips-glibc-2.2.5-1-6/math:/home/cross-compiler/mips-glibc-2.2.5-1-6/elf:/
home/cross-compiler/mips-glibc-2.2.5-1-6/dlfcn:/home/cross-compiler/mips-gli
bc-2.2.5-1-6/nss:/home/cross-compiler/mips-glibc-2.2.5-1-6/nis:/home/cross-c
ompiler/mips-glibc-2.2.5-1-6/rt:/home/cross-compiler/mips-glibc-2.2.5-1-6/re
solv:/home/cross-compiler/mips-glibc-2.2.5-1-6/crypt:/home/cross-compiler/mi
ps-glibc-2.2.5-1-6/linuxthreads -o
/home/cross-compiler/mips-glibc-2.2.5-1-6/libc.so -T
/home/cross-compiler/mips-glibc-2.2.5-1-6/libc.so.lds
/home/cross-compiler/mips-glibc-2.2.5-1-6/csu/abi-note.o
/home/cross-compiler/mips-glibc-2.2.5-1-6/elf/soinit.os
/home/cross-compiler/mips-glibc-2.2.5-1-6/libc_pic.os
/home/cross-compiler/mips-glibc-2.2.5-1-6/elf/sofini.os
/home/cross-compiler/mips-glibc-2.2.5-1-6/elf/interp.os
/home/cross-compiler/mips-glibc-2.2.5-1-6/elf/ld.so -lgcc
/home/cross-compiler/mips-glibc-2.2.5-1-6/libc_pic.os: In function
`__sigprocmask':
/home/cross-compiler/glibc-2.2.5/signal/../sysdeps/unix/sysv/linux/sigprocma
sk.c(.text+0x1bc30): relocation truncated to fit: R_MIPS_PC16
__syscall_error
/home/cross-compiler/mips-glibc-2.2.5-1-6/libc_pic.os: In function
`sigstack':
/home/cross-compiler/glibc-2.2.5/signal/../sysdeps/unix/sysv/linux/sigstack.
c(.text+0x1c6d0): relocation truncated to fit: R_MIPS_PC16 __syscall_error
/home/cross-compiler/mips-glibc-2.2.5-1-6/libc_pic.os: In function `sigset':
/home/cross-compiler/glibc-2.2.5/signal/../sysdeps/posix/sigset.c(.text+0x1d
670): relocation truncated to fit: R_MIPS_PC16 __syscall_error
/home/cross-compiler/glibc-2.2.5/signal/../sysdeps/posix/sigset.c(.text+0x1d
690): relocation 
....

/** end of error emssages ****/

Do anyone ever see this before? Any solution(s)? TIA.


Chien-Lung


	



From ladis@psi.cz Wed Jan  8 12:21:46 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 08 Jan 2003 12:21:47 +0000 (GMT)
Received: from erebor.lep.brno.cas.cz ([IPv6:::ffff:195.178.65.162]:40972 "EHLO
	erebor.lep.brno.cas.cz") by linux-mips.org with ESMTP
	id <S8225970AbTAHMVq>; Wed, 8 Jan 2003 12:21:46 +0000
Received: from ladis by erebor.lep.brno.cas.cz with local (Exim 3.12 #1 (Debian))
	id 18WFLZ-0004nO-00; Wed, 08 Jan 2003 13:30:13 +0100
Date: Wed, 8 Jan 2003 13:30:13 +0100
To: linux-mips <linux-mips@linux-mips.org>
Cc: Ralf Baechle <ralf@linux-mips.org>,
	Guido Guenther <agx@sigxcpu.org>
Subject: Remove GIO interface
Message-ID: <20030108133013.A17162@erebor.psi.cz>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
From: Ladislav Michl <ladis@psi.cz>
Return-Path: <ladis@psi.cz>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1090
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ladis@psi.cz
Precedence: bulk
X-list: linux-mips

Hi,

after many tests I decided to remove GIO interface from kernel...

Reasons:
* Due to hardware setup it is not possible to determine device in GFX slot.
  Even more it's not possible to say if there is any. (gio.ps Lie #1)
* Newport XL nor XZ doesn't provide GIO product identification word. In fact
  Newport is simply mapped from SLOT_BASE + 0xf0000. (gio.ps Lie #2)
* Even in case everything work as stated in documentation, we are unable
  to use this mechanism to detect Newport for console driver (the main
  reason why I created this interface was to provide neccessary
  informations to Xserver), because our DBE handling doesn't work until
  modules are initialized (in case we are building kernel with modules
  support).

Because we have only three (two on Indigo) slots and each type of device
can be located only in one (rarely two possitions), drivers will use
get_dbe for device probing (see my next post).

I think now is time to eat humble pie for my stupidity, I'll no more trust
any documentation and will always verify facts. I'm sorry.

	ladis

Index: include/asm-mips/sgi/sgigio.h
===================================================================
RCS file: /home/cvs/linux/include/asm-mips/sgi/sgigio.h,v
retrieving revision 1.1.2.2
diff -u -r1.1.2.2 sgigio.h
--- include/asm-mips/sgi/sgigio.h	5 Aug 2002 23:53:38 -0000	1.1.2.2
+++ include/asm-mips/sgi/sgigio.h	8 Jan 2003 11:10:37 -0000
@@ -12,6 +12,11 @@
 #define _ASM_SGI_SGIGIO_H
 
 /*
+ * GIO bus addresses
+ *
+ * The Indigo and Indy have two GIO bus connectors. Indigo2 (all models) have
+ * three physical connectors, but only two slots, GFX and EXP0.
+ * 
  * There is 10MB of GIO address space for GIO64 slot devices
  * slot#   slot type address range            size
  * -----   --------- ----------------------- -----
@@ -26,44 +31,56 @@
  * Following space is reserved and unused
  *   -     RESERVED  0x18000000 - 0x1effffff 112MB
  *
- * The GIO specification tends to use slot numbers while the MC specification
- * tends to use slot types.
+ * GIO bus IDs
+ *
+ * Each GIO bus device identifies itself to the system by answering a
+ * read with an "ID" value. IDs are either 8 or 32 bits long. IDs less
+ * than 128 are 8 bits long, with the most significant 24 bits read from
+ * the slot undefined.
+ *
+ * 32-bit IDs are divided into
+ *	bits 0:6        the product ID; ranges from 0x00 to 0x7F.
+ *	bit 7		0=GIO Product ID is 8 bits wide
+ *			1=GIO Product ID is 32 bits wide.
+ *	bits 8:15       manufacturer version for the product.
+ *	bit 16		0=GIO32 and GIO32-bis, 1=GIO64.
+ *	bit 17		0=no ROM present
+ *			1=ROM present on this board AND next three words
+ *			space define the ROM.
+ *	bits 18:31	up to manufacturer.
+ *
+ * IDs above 0x50/0xd0 are of 3rd party boards.
+ *
+ * 8-bit IDs
+ *	0x01		XPI low cost FDDI
+ *	0x02		GTR TokenRing
+ *	0x04		Synchronous ISDN
+ *	0x05		ATM board [*]
+ *	0x06		Canon Interface
+ *	0x07		16 bit SCSI Card [*]
+ *	0x08		JPEG (Double Wide)
+ *	0x09		JPEG (Single Wide)
+ *	0x0a		XPI mez. FDDI device 0
+ *	0x0b		XPI mez. FDDI device 1
+ *	0x0c		SMPTE 259M Video [*]
+ *	0x0d		Babblefish Compression [*]
+ *	0x0e		E-Plex 8-port Ethernet
+ *	0x30		Lyon Lamb IVAS
+ *	0xb8		GIO 100BaseTX Fast Ethernet (gfe)
+ *
+ * [*] Device provide 32-bit ID.
  *
- * slot0  - the "graphics" (GFX) slot but there is no requirement that
- *          a graphics dev may only use this slot
- * slot1  - this is the "expansion"-slot 0 (EXP0), do not confuse with
- *          slot 0 (GFX).
- * slot2  - this is the "expansion"-slot 1 (EXP1), do not confuse with
- *          slot 1 (EXP0).
  */
 
-#define GIO_SLOT_GFX	0
-#define GIO_SLOT_GIO1	1
-#define GIO_SLOT_GIO2	2
-#define GIO_NUM_SLOTS	3
-
-#define GIO_ANY_ID	0xff
-
-#define GIO_VALID_ID_ONLY	0x01
-#define GIO_IFACE_64		0x02
-#define GIO_HAS_ROM		0x04
-
-struct gio_dev {
-	unsigned char	device;
-	unsigned char	revision;
-	unsigned short	vendor;
-	unsigned char	flags;
-
-	unsigned char	slot_number;
-	unsigned long	base_addr;
-	unsigned int	map_size;
-
-	char		*name;
-	char		slot_name[5];
-};
-
-extern struct gio_dev* gio_find_device(unsigned char device, const struct gio_dev *from);
-
-extern void sgigio_init(void);
+#define GIO_ID(x)		(x & 0x7f)
+#define GIO_32BIT_ID		0x80
+#define GIO_REV(x)		((x >> 8) & 0xff)
+#define GIO_64BIT_IFACE		0x10000
+#define GIO_ROM_PRESENT		0x20000
+#define GIO_VENDOR_CODE(x)	((x >> 18) & 0x3fff)
+
+#define GIO_SLOT_GFX_BASE	0x1f000000
+#define GIO_SLOT_EXP0_BASE	0x1f400000
+#define GIO_SLOT_EXP1_BASE	0x1f600000
 
 #endif /* _ASM_SGI_SGIGIO_H */
Index: include/asm-mips64/sgi/sgigio.h
===================================================================
RCS file: /home/cvs/linux/include/asm-mips64/sgi/sgigio.h,v
retrieving revision 1.1.2.2
diff -u -r1.1.2.2 sgigio.h
--- include/asm-mips64/sgi/sgigio.h	5 Aug 2002 23:53:40 -0000	1.1.2.2
+++ include/asm-mips64/sgi/sgigio.h	8 Jan 2003 11:10:37 -0000
@@ -12,6 +12,11 @@
 #define _ASM_SGI_SGIGIO_H
 
 /*
+ * GIO bus addresses
+ *
+ * The Indigo and Indy have two GIO bus connectors. Indigo2 (all models) have
+ * three physical connectors, but only two slots, GFX and EXP0.
+ * 
  * There is 10MB of GIO address space for GIO64 slot devices
  * slot#   slot type address range            size
  * -----   --------- ----------------------- -----
@@ -26,44 +31,56 @@
  * Following space is reserved and unused
  *   -     RESERVED  0x18000000 - 0x1effffff 112MB
  *
- * The GIO specification tends to use slot numbers while the MC specification
- * tends to use slot types.
+ * GIO bus IDs
+ *
+ * Each GIO bus device identifies itself to the system by answering a
+ * read with an "ID" value. IDs are either 8 or 32 bits long. IDs less
+ * than 128 are 8 bits long, with the most significant 24 bits read from
+ * the slot undefined.
+ *
+ * 32-bit IDs are divided into
+ *	bits 0:6        the product ID; ranges from 0x00 to 0x7F.
+ *	bit 7		0=GIO Product ID is 8 bits wide
+ *			1=GIO Product ID is 32 bits wide.
+ *	bits 8:15       manufacturer version for the product.
+ *	bit 16		0=GIO32 and GIO32-bis, 1=GIO64.
+ *	bit 17		0=no ROM present
+ *			1=ROM present on this board AND next three words
+ *			space define the ROM.
+ *	bits 18:31	up to manufacturer.
+ *
+ * IDs above 0x50/0xd0 are of 3rd party boards.
+ *
+ * 8-bit IDs
+ *	0x01		XPI low cost FDDI
+ *	0x02		GTR TokenRing
+ *	0x04		Synchronous ISDN
+ *	0x05		ATM board [*]
+ *	0x06		Canon Interface
+ *	0x07		16 bit SCSI Card [*]
+ *	0x08		JPEG (Double Wide)
+ *	0x09		JPEG (Single Wide)
+ *	0x0a		XPI mez. FDDI device 0
+ *	0x0b		XPI mez. FDDI device 1
+ *	0x0c		SMPTE 259M Video [*]
+ *	0x0d		Babblefish Compression [*]
+ *	0x0e		E-Plex 8-port Ethernet
+ *	0x30		Lyon Lamb IVAS
+ *	0xb8		GIO 100BaseTX Fast Ethernet (gfe)
+ *
+ * [*] Device provide 32-bit ID.
  *
- * slot0  - the "graphics" (GFX) slot but there is no requirement that
- *          a graphics dev may only use this slot
- * slot1  - this is the "expansion"-slot 0 (EXP0), do not confuse with
- *          slot 0 (GFX).
- * slot2  - this is the "expansion"-slot 1 (EXP1), do not confuse with
- *          slot 1 (EXP0).
  */
 
-#define GIO_SLOT_GFX	0
-#define GIO_SLOT_GIO1	1
-#define GIO_SLOT_GIO2	2
-#define GIO_NUM_SLOTS	3
-
-#define GIO_ANY_ID	0xff
-
-#define GIO_VALID_ID_ONLY	0x01
-#define GIO_IFACE_64		0x02
-#define GIO_HAS_ROM		0x04
-
-struct gio_dev {
-	unsigned char	device;
-	unsigned char	revision;
-	unsigned short	vendor;
-	unsigned char	flags;
-
-	unsigned char	slot_number;
-	unsigned long	base_addr;
-	unsigned int	map_size;
-
-	char		*name;
-	char		slot_name[5];
-};
-
-extern struct gio_dev* gio_find_device(unsigned char device, const struct gio_dev *from);
-
-extern void sgigio_init(void);
+#define GIO_ID(x)		(x & 0x7f)
+#define GIO_32BIT_ID		0x80
+#define GIO_REV(x)		((x >> 8) & 0xff)
+#define GIO_64BIT_IFACE		0x10000
+#define GIO_ROM_PRESENT		0x20000
+#define GIO_VENDOR_CODE(x)	((x >> 18) & 0x3fff)
+
+#define GIO_SLOT_GFX_BASE	0x1f000000
+#define GIO_SLOT_EXP0_BASE	0x1f400000
+#define GIO_SLOT_EXP1_BASE	0x1f600000
 
 #endif /* _ASM_SGI_SGIGIO_H */
Index: arch/mips/sgi-ip22/ip22-time.c
===================================================================
RCS file: /home/cvs/linux/arch/mips/sgi-ip22/ip22-time.c,v
retrieving revision 1.1.2.11
diff -u -r1.1.2.11 ip22-time.c
--- arch/mips/sgi-ip22/ip22-time.c	18 Dec 2002 22:37:29 -0000	1.1.2.11
+++ arch/mips/sgi-ip22/ip22-time.c	8 Jan 2003 11:10:38 -0000
@@ -180,14 +180,6 @@
 		(int) (r4k_tick / 5000), (int) (r4k_tick % 5000) / 50);
 
 	mips_counter_frequency = r4k_tick * HZ;
-
-	/* HACK ALERT! This get's called after traps initialization
-	 * We piggyback the initialization of GIO bus here even though
-	 * it is technically not related with the timer in any way.
-	 * Doing it from ip22_setup wouldn't work since traps aren't
-	 * initialized yet.
-	 */
-	sgigio_init();
 }
 
 /* Generic SGI handler for (spurious) 8254 interrupts */
Index: arch/mips/sgi-ip22/ip22-setup.c
===================================================================
RCS file: /home/cvs/linux/arch/mips/sgi-ip22/ip22-setup.c,v
retrieving revision 1.1.2.14
diff -u -r1.1.2.14 ip22-setup.c
--- arch/mips/sgi-ip22/ip22-setup.c	27 Sep 2002 16:45:04 -0000	1.1.2.14
+++ arch/mips/sgi-ip22/ip22-setup.c	8 Jan 2003 11:18:39 -0000
@@ -47,7 +47,6 @@
 extern struct rtc_ops indy_rtc_ops;
 extern void indy_reboot_setup(void);
 extern void sgi_volume_set(unsigned char);
-extern void create_gio_proc_entry(void);
 
 #define sgi_kh ((struct hpc_keyb *) &(hpc3mregs->kbdmouse0))
 
@@ -69,11 +68,6 @@
 	 * ip22_setup wouldn't work since kmalloc isn't initialized yet.
 	 */
 	indy_reboot_setup();
-
-	/* Ehm, well... once David used hack above, let's add yet another.
-	 * Register GIO bus proc entry here.
-	 */
-	create_gio_proc_entry();
 
 	return request_irq(SGI_KEYBD_IRQ, handler, 0, "keyboard", NULL);
 }
Index: arch/mips/sgi-ip22/ip22-gio.c
===================================================================
RCS file: /home/cvs/linux/arch/mips/sgi-ip22/ip22-gio.c,v
retrieving revision 1.1.2.4
diff -u -r1.1.2.4 ip22-gio.c
--- arch/mips/sgi-ip22/ip22-gio.c	18 Dec 2002 19:11:09 -0000	1.1.2.4
+++ arch/mips/sgi-ip22/ip22-gio.c	8 Jan 2003 12:14:53 -0000
@@ -1,137 +1,5 @@
 /*
- * ip22-gio.c: Support for GIO64 bus (inspired by PCI code)
- *
- * Copyright (C) 2002 Ladislav Michl
+ * ip22-gio.c: Support for GIO bus (add interrupt handling code here)
  */
 
-#include <linux/kernel.h>
-#include <linux/types.h>
-#include <linux/slab.h>
-#include <linux/init.h>
-#include <linux/proc_fs.h>
-
-#include <asm/addrspace.h>
-#include <asm/sgi/sgimc.h>
 #include <asm/sgi/sgigio.h>
-
-#define GIO_PIO_MAP_BASE	0x1f000000L
-#define GIO_PIO_MAP_SIZE	(16 * 1024*1024)
-
-#define GIO_ADDR_GFX		0x1f000000L
-#define GIO_ADDR_GIO1		0x1f400000L
-#define GIO_ADDR_GIO2		0x1f600000L
-
-#define GIO_GFX_MAP_SIZE	(4 * 1024*1024)
-#define GIO_GIO1_MAP_SIZE	(2 * 1024*1024)
-#define GIO_GIO2_MAP_SIZE	(4 * 1024*1024)
-
-#define GIO_NO_DEVICE		0x80
-
-static struct gio_dev gio_slot[GIO_NUM_SLOTS] = {{
-	.flags		= GIO_NO_DEVICE,
-	.slot_number	= GIO_SLOT_GFX,
-	.base_addr	= GIO_ADDR_GFX,
-	.map_size	= GIO_GFX_MAP_SIZE,
-	.slot_name	= "GFX",
-}, {
-	.flags		= GIO_NO_DEVICE,
-	.slot_number	= GIO_SLOT_GIO1,
-	.base_addr	= GIO_ADDR_GIO1,
-	.map_size	= GIO_GIO1_MAP_SIZE,
-	.slot_name	= "EXP0",
-}, {
-	.flags		= GIO_NO_DEVICE,
-	.slot_number	= GIO_SLOT_GIO2,
-	.base_addr	= GIO_ADDR_GIO2,
-	.map_size	= GIO_GIO2_MAP_SIZE,
-	.slot_name	= "EXP1"
-}};
-
-static int gio_read_proc(char *buf, char **start, off_t off,
-			 int count, int *eof, void *data)
-{
-	int i;
-	char *p = buf;
-
-	p += sprintf(p, "GIO devices found:\n");
-	for (i = 0; i < GIO_NUM_SLOTS; i++) {
-		if (gio_slot[i].flags & GIO_NO_DEVICE)
-			continue;
-		p += sprintf(p, "  Slot %s, DeviceId 0x%02x\n",
-			     gio_slot[i].slot_name, gio_slot[i].device);
-		p += sprintf(p, "    BaseAddr 0x%08lx, MapSize 0x%08x\n",
-			     gio_slot[i].base_addr, gio_slot[i].map_size);
-	}
-
-	return p - buf;
-}
-
-void create_gio_proc_entry(void)
-{
-	create_proc_read_entry("gio", 0, NULL, gio_read_proc, NULL);
-}
-
-/**
- * gio_find_device - begin or continue searching for a GIO device by device id
- * @device: GIO device id to match, or %GIO_ANY_ID to match all device ids
- * @from: Previous GIO device found in search, or %NULL for new search.
- *
- * Iterates through the list of known GIO devices. If a GIO device is found
- * with a matching @device, a pointer to its device structure is returned.
- * Otherwise, %NULL is returned.
- * A new search is initiated by passing %NULL to the @from argument.
- * Otherwise if @from is not %NULL, searches continue from next device.
- */
-struct gio_dev *
-gio_find_device(unsigned char device, const struct gio_dev *from)
-{
-	int i;
-
-	for (i = (from) ? from->slot_number : 0; i < GIO_NUM_SLOTS; i++)
-		if (!(gio_slot[i].flags & GIO_NO_DEVICE) &&
-		   (device == GIO_ANY_ID || device == gio_slot[i].device))
-			return &gio_slot[i];
-
-	return NULL;
-}
-
-#define GIO_IDCODE(x)		(x & 0x7f)
-#define GIO_ALL_BITS_VALID	0x80
-#define GIO_REV(x)		((x >> 8) & 0xff)
-#define GIO_GIO_SIZE_64		0x10000
-#define GIO_ROM_PRESENT		0x20000
-#define GIO_VENDOR_CODE(x)	((x >> 18) & 0x3fff)
-
-extern int ip22_baddr(unsigned int *val, unsigned long addr);
-
-/**
- * sgigio_init - scan the GIO space and figure out what hardware is actually
- * present.
- */
-void __init sgigio_init(void)
-{
-	unsigned int i, id, found = 0;
-
-	printk("GIO: Scanning for GIO cards...\n");
-	for (i = 0; i < GIO_NUM_SLOTS; i++) {
-		if (ip22_baddr(&id, KSEG1ADDR(gio_slot[i].base_addr)))
-			continue;
-
-		found = 1;
-		gio_slot[i].device = GIO_IDCODE(id);
-		if (id & GIO_ALL_BITS_VALID) {
-			gio_slot[i].revision = GIO_REV(id);
-			gio_slot[i].vendor = GIO_VENDOR_CODE(id);
-			gio_slot[i].flags =
-				(id & GIO_GIO_SIZE_64) ? GIO_IFACE_64 : 0 |
-				(id & GIO_ROM_PRESENT) ? GIO_HAS_ROM : 0;
-		} else
-			gio_slot[i].flags = GIO_VALID_ID_ONLY;
-
-		printk("GIO: Card 0x%02x @ 0x%08lx\n", gio_slot[i].device,
-			gio_slot[i].base_addr);
-	}
-
-	if (!found)
-		printk("GIO: No GIO cards present.\n");
-}

From ladis@psi.cz Wed Jan  8 12:33:05 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 08 Jan 2003 12:33:06 +0000 (GMT)
Received: from erebor.lep.brno.cas.cz ([IPv6:::ffff:195.178.65.162]:42252 "EHLO
	erebor.lep.brno.cas.cz") by linux-mips.org with ESMTP
	id <S8226009AbTAHMdF>; Wed, 8 Jan 2003 12:33:05 +0000
Received: from ladis by erebor.lep.brno.cas.cz with local (Exim 3.12 #1 (Debian))
	id 18WFWd-0004rG-00; Wed, 08 Jan 2003 13:41:39 +0100
Date: Wed, 8 Jan 2003 13:41:38 +0100
To: linux-mips <linux-mips@linux-mips.org>
Cc: Ralf Baechle <ralf@linux-mips.org>,
	Guido Guenther <agx@sigxcpu.org>
Subject: [PATCH] proper bus error handling for IP22
Message-ID: <20030108134138.B17162@erebor.psi.cz>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
From: Ladislav Michl <ladis@psi.cz>
Return-Path: <ladis@psi.cz>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1091
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ladis@psi.cz
Precedence: bulk
X-list: linux-mips

This patch makes get_dbe/put_dbe useable. Additionaly prints some useful
informations on bus error. Depends on GIO interface removing patch.

	ladis

Index: arch/mips/sgi-ip22/ip22-berr.c
===================================================================
RCS file: /home/cvs/linux/arch/mips/sgi-ip22/ip22-berr.c,v
retrieving revision 1.1.2.2
diff -u -r1.1.2.2 ip22-berr.c
--- arch/mips/sgi-ip22/ip22-berr.c	5 Aug 2002 23:53:35 -0000	1.1.2.2
+++ arch/mips/sgi-ip22/ip22-berr.c	8 Jan 2003 12:22:32 -0000
@@ -15,12 +15,11 @@
 #include <asm/sgi/sgimc.h>
 #include <asm/sgi/sgihpc.h>
 
-unsigned int cpu_err_stat;	/* Status reg for CPU */
-unsigned int gio_err_stat;	/* Status reg for GIO */
-unsigned int cpu_err_addr;	/* Error address reg for CPU */
-unsigned int gio_err_addr;	/* Error address reg for GIO */
 
-volatile int nofault;
+static unsigned int cpu_err_stat;	/* Status reg for CPU */
+static unsigned int gio_err_stat;	/* Status reg for GIO */
+static unsigned int cpu_err_addr;	/* Error address reg for CPU */
+static unsigned int gio_err_addr;	/* Error address reg for GIO */
 
 static void save_and_clear_buserr(void)
 {
@@ -33,6 +32,35 @@
 	mcmisc_regs->cstat = mcmisc_regs->gstat = 0;
 }
 
+#define GIO_ERRMASK	0xff00
+#define CPU_ERRMASK	0x3f00
+
+static void print_buserr(void)
+{
+	if (cpu_err_stat & CPU_ERRMASK)
+		printk(KERN_ALERT "CPU Error/Addr 0x%x<%s%s%s%s%s%s> 0x%08x\n",
+			cpu_err_stat,
+			cpu_err_stat & SGIMC_CSTAT_RD ? "RD " : "",
+			cpu_err_stat & SGIMC_CSTAT_PAR ? "PAR " : "",
+			cpu_err_stat & SGIMC_CSTAT_ADDR ? "ADDR " : "",
+			cpu_err_stat & SGIMC_CSTAT_SYSAD_PAR ? "SYSAD " : "",
+			cpu_err_stat & SGIMC_CSTAT_SYSCMD_PAR ? "SYSCMD " : "",
+			cpu_err_stat & SGIMC_CSTAT_BAD_DATA ? "BAD_DATA " : "",
+			cpu_err_addr);
+	if (gio_err_stat & GIO_ERRMASK)
+		printk(KERN_ALERT "GIO Error/Addr 0x%x:<%s%s%s%s%s%s%s%s> 0x08%x\n",
+			gio_err_stat,
+			gio_err_stat & SGIMC_GSTAT_RD ? "RD " : "",
+			gio_err_stat & SGIMC_GSTAT_WR ? "WR " : "",
+			gio_err_stat & SGIMC_GSTAT_TIME ? "TIME " : "",
+			gio_err_stat & SGIMC_GSTAT_PROM ? "PROM " : "",
+			gio_err_stat & SGIMC_GSTAT_ADDR ? "ADDR " : "",
+			gio_err_stat & SGIMC_GSTAT_BC ? "BC " : "",
+			gio_err_stat & SGIMC_GSTAT_PIO_RD ? "PIO_RD " : "",
+			gio_err_stat & SGIMC_GSTAT_PIO_WR ? "PIO_WR " : "",
+			gio_err_addr);
+}
+
 /*
  * MC sends an interrupt whenever bus or parity errors occur. In addition,
  * if the error happened during a CPU read, it also asserts the bus error
@@ -43,33 +71,18 @@
 void be_ip22_interrupt(int irq, struct pt_regs *regs)
 {
 	save_and_clear_buserr();
-	printk(KERN_ALERT "Bus error, epc == %08lx, ra == %08lx\n",
-	       regs->cp0_epc, regs->regs[31]);
-	die_if_kernel("Oops", regs);
-	force_sig(SIGBUS, current);
+	print_buserr();
+	panic("Bus error, epc == %08lx, ra == %08lx\n",
+	      regs->cp0_epc, regs->regs[31]);
 }
 
 int be_ip22_handler(struct pt_regs *regs, int is_fixup)
 {
 	save_and_clear_buserr();
-	if (nofault) {
-		nofault = 0;
-		compute_return_epc(regs);
-		return MIPS_BE_DISCARD;
-	}
-	return MIPS_BE_FIXUP;
-}
-
-int ip22_baddr(unsigned int *val, unsigned long addr)
-{
-	nofault = 1;
-	*val = *(volatile unsigned int *) addr;
-	__asm__ __volatile__("nop;nop;nop;nop");
-	if (nofault) {
-		nofault = 0;
-		return 0;
-	}
-	return -EFAULT;
+	if (is_fixup)
+		return MIPS_BE_FIXUP;
+	print_buserr();
+	return MIPS_BE_FATAL;
 }
 
 void __init bus_error_init(void)
Index: include/asm-mips/sgi/sgimc.h
===================================================================
RCS file: /home/cvs/linux/include/asm-mips/sgi/sgimc.h,v
retrieving revision 1.5
diff -u -r1.5 sgimc.h
--- include/asm-mips/sgi/sgimc.h	6 Sep 2001 13:12:03 -0000	1.5
+++ include/asm-mips/sgi/sgimc.h	8 Jan 2003 12:22:33 -0000
@@ -15,144 +15,159 @@
 
 struct sgimc_misc_ctrl {
 	u32 _unused1;
-	volatile u32 cpuctrl0;     /* CPU control register 0, readwrite */
-#define SGIMC_CCTRL0_REFS         0x0000000f /* REFS mask */
-#define SGIMC_CCTRL0_EREFRESH     0x00000010 /* Memory refresh enable */
-#define SGIMC_CCTRL0_EPERRGIO     0x00000020 /* GIO parity error enable */
-#define SGIMC_CCTRL0_EPERRMEM     0x00000040 /* Main mem parity error enable */
-#define SGIMC_CCTRL0_EPERRCPU     0x00000080 /* CPU bus parity error enable */
-#define SGIMC_CCTRL0_WDOG         0x00000100 /* Watchdog timer enable */
-#define SGIMC_CCTRL0_SYSINIT      0x00000200 /* System init bit */
-#define SGIMC_CCTRL0_GFXRESET     0x00000400 /* Graphics interface reset */
-#define SGIMC_CCTRL0_EISALOCK     0x00000800 /* Lock CPU from memory for EISA */
-#define SGIMC_CCTRL0_EPERRSCMD    0x00001000 /* SysCMD bus parity error enable */
-#define SGIMC_CCTRL0_IENAB        0x00002000 /* Allow interrupts from MC */
-#define SGIMC_CCTRL0_ESNOOP       0x00004000 /* Snooping I/O enable */
-#define SGIMC_CCTRL0_EPROMWR      0x00008000 /* Prom writes from cpu enable */
-#define SGIMC_CCTRL0_WRESETPMEM   0x00010000 /* Perform warm reset, preserves mem */
-#define SGIMC_CCTRL0_LENDIAN      0x00020000 /* Put MC in little-endian mode */
-#define SGIMC_CCTRL0_WRESETDMEM   0x00040000 /* Warm reset, destroys mem contents */
-#define SGIMC_CCTRL0_CMEMBADPAR   0x02000000 /* Generate bad perr from cpu to mem */
-#define SGIMC_CCTRL0_R4KNOCHKPARR 0x04000000 /* Don't chk parity on mem data reads */
-#define SGIMC_CCTRL0_GIOBTOB      0x08000000 /* Allow GIO back to back writes */
+	volatile u32 cpuctrl0;	/* CPU control register 0, readwrite */
+#define SGIMC_CCTRL0_REFS	0x0000000f /* REFS mask */
+#define SGIMC_CCTRL0_EREFRESH	0x00000010 /* Memory refresh enable */
+#define SGIMC_CCTRL0_EPERRGIO	0x00000020 /* GIO parity error enable */
+#define SGIMC_CCTRL0_EPERRMEM	0x00000040 /* Main mem parity error enable */
+#define SGIMC_CCTRL0_EPERRCPU	0x00000080 /* CPU bus parity error enable */
+#define SGIMC_CCTRL0_WDOG	0x00000100 /* Watchdog timer enable */
+#define SGIMC_CCTRL0_SYSINIT	0x00000200 /* System init bit */
+#define SGIMC_CCTRL0_GFXRESET	0x00000400 /* Graphics interface reset */
+#define SGIMC_CCTRL0_EISALOCK	0x00000800 /* Lock CPU from memory for EISA */
+#define SGIMC_CCTRL0_EPERRSCMD	0x00001000 /* SysCMD bus parity error enable */
+#define SGIMC_CCTRL0_IENAB	0x00002000 /* Allow interrupts from MC */
+#define SGIMC_CCTRL0_ESNOOP	0x00004000 /* Snooping I/O enable */
+#define SGIMC_CCTRL0_EPROMWR	0x00008000 /* Prom writes from cpu enable */
+#define SGIMC_CCTRL0_WRESETPMEM	0x00010000 /* Perform warm reset, preserves mem */
+#define SGIMC_CCTRL0_LENDIAN	0x00020000 /* Put MC in little-endian mode */
+#define SGIMC_CCTRL0_WRESETDMEM	0x00040000 /* Warm reset, destroys mem contents */
+#define SGIMC_CCTRL0_CMEMBADPAR	0x02000000 /* Generate bad perr from cpu to mem */
+#define SGIMC_CCTRL0_R4KNOPAR	0x04000000 /* Don't chk parity on mem data reads */
+#define SGIMC_CCTRL0_GIOBTOB	0x08000000 /* Allow GIO back to back writes */
 
 	u32 _unused2;
-	volatile u32 cpuctrl1;     /* CPU control register 1, readwrite */
-#define SGIMC_CCTRL1_EGIOTIMEO    0x00000010 /* GIO bus timeout enable */
-#define SGIMC_CCTRL1_FIXEDEHPC    0x00001000 /* Fixed HPC endianness */
-#define SGIMC_CCTRL1_LITTLEHPC    0x00002000 /* Little endian HPC */
-#define SGIMC_CCTRL1_FIXEDEEXP0   0x00004000 /* Fixed EXP0 endianness */
-#define SGIMC_CCTRL1_LITTLEEXP0   0x00008000 /* Little endian EXP0 */
-#define SGIMC_CCTRL1_FIXEDEEXP1   0x00010000 /* Fixed EXP1 endianness */
-#define SGIMC_CCTRL1_LITTLEEXP1   0x00020000 /* Little endian EXP1 */
+	volatile u32 cpuctrl1;	/* CPU control register 1, readwrite */
+#define SGIMC_CCTRL1_EGIOTIMEO	0x00000010 /* GIO bus timeout enable */
+#define SGIMC_CCTRL1_FIXEDEHPC	0x00001000 /* Fixed HPC endianness */
+#define SGIMC_CCTRL1_LITTLEHPC	0x00002000 /* Little endian HPC */
+#define SGIMC_CCTRL1_FIXEDEEXP0	0x00004000 /* Fixed EXP0 endianness */
+#define SGIMC_CCTRL1_LITTLEEXP0	0x00008000 /* Little endian EXP0 */
+#define SGIMC_CCTRL1_FIXEDEEXP1	0x00010000 /* Fixed EXP1 endianness */
+#define SGIMC_CCTRL1_LITTLEEXP1	0x00020000 /* Little endian EXP1 */
 
 	u32 _unused3;
-	volatile u32 watchdogt;    /* Watchdog reg rdonly, write clears */
+	volatile u32 watchdogt;	/* Watchdog reg rdonly, write clears */
 
 	u32 _unused4;
-	volatile u32 systemid;     /* MC system ID register, readonly */
-#define SGIMC_SYSID_MASKREV       0x0000000f /* Revision of MC controller */
-#define SGIMC_SYSID_EPRESENT      0x00000010 /* Indicates presence of EISA bus */
+	volatile u32 systemid;	/* MC system ID register, readonly */
+#define SGIMC_SYSID_MASKREV	0x0000000f /* Revision of MC controller */
+#define SGIMC_SYSID_EPRESENT	0x00000010 /* Indicates presence of EISA bus */
 
 	u32 _unused5[3];
-	volatile u32 divider;      /* Divider reg for RPSS */
+	volatile u32 divider;	/* Divider reg for RPSS */
 
 	u32 _unused6;
-	volatile unsigned char eeprom;       /* EEPROM byte reg for r4k */
-#define SGIMC_EEPROM_PRE          0x00000001 /* eeprom chip PRE pin assertion */
-#define SGIMC_EEPROM_CSEL         0x00000002 /* Active high, eeprom chip select */
-#define SGIMC_EEPROM_SECLOCK      0x00000004 /* EEPROM serial clock */
-#define SGIMC_EEPROM_SDATAO       0x00000008 /* Serial EEPROM data-out */
-#define SGIMC_EEPROM_SDATAI       0x00000010 /* Serial EEPROM data-in */
+	volatile unsigned char eeprom;     /* EEPROM byte reg for r4k */
+#define SGIMC_EEPROM_PRE	0x00000001 /* eeprom chip PRE pin assertion */
+#define SGIMC_EEPROM_CSEL	0x00000002 /* Active high, eeprom chip select */
+#define SGIMC_EEPROM_SECLOCK	0x00000004 /* EEPROM serial clock */
+#define SGIMC_EEPROM_SDATAO	0x00000008 /* Serial EEPROM data-out */
+#define SGIMC_EEPROM_SDATAI	0x00000010 /* Serial EEPROM data-in */
 
 	unsigned char _unused7[3];
 	u32 _unused8[3];
-	volatile unsigned short rcntpre;     /* Preload refresh counter */
+	volatile unsigned short rcntpre;   /* Preload refresh counter */
 
 	unsigned short _unused9;
 	u32 _unused9a;
-	volatile unsigned short rcounter;    /* Readonly refresh counter */
+	volatile unsigned short rcounter;  /* Readonly refresh counter */
 
 	unsigned short _unused10;
 	u32 _unused11[13];
-	volatile u32 gioparm;      /* Parameter word for GIO64 */
-#define SGIMC_GIOPARM_HPC64       0x00000001 /* HPC talks to GIO using 64-bits */
-#define SGIMC_GIOPARM_GFX64       0x00000002 /* GFX talks to GIO using 64-bits */
-#define SGIMC_GIOPARM_EXP064      0x00000004 /* EXP(slot0) talks using 64-bits */
-#define SGIMC_GIOPARM_EXP164      0x00000008 /* EXP(slot1) talks using 64-bits */
-#define SGIMC_GIOPARM_EISA64      0x00000010 /* EISA bus talks 64-bits to GIO */
-#define SGIMC_GIOPARM_HPC264      0x00000020 /* 2nd HPX talks 64-bits to GIO */
-#define SGIMC_GIOPARM_RTIMEGFX    0x00000040 /* GFX device has realtime attr */
-#define SGIMC_GIOPARM_RTIMEEXP0   0x00000080 /* EXP(slot0) has realtime attr */
-#define SGIMC_GIOPARM_RTIMEEXP1   0x00000100 /* EXP(slot1) has realtime attr */
-#define SGIMC_GIOPARM_MASTEREISA  0x00000200 /* EISA bus can act as bus master */
-#define SGIMC_GIOPARM_ONEBUS      0x00000400 /* Exists one GIO64 pipelined bus */
-#define SGIMC_GIOPARM_MASTERGFX   0x00000800 /* GFX can act as a bus master */
-#define SGIMC_GIOPARM_MASTEREXP0  0x00001000 /* EXP(slot0) can bus master */
-#define SGIMC_GIOPARM_MASTEREXP1  0x00002000 /* EXP(slot1) can bus master */
-#define SGIMC_GIOPARM_PLINEEXP0   0x00004000 /* EXP(slot0) has pipeline attr */
-#define SGIMC_GIOPARM_PLINEEXP1   0x00008000 /* EXP(slot1) has pipeline attr */
+	volatile u32 gioparm;	/* Parameter word for GIO64 */
+#define SGIMC_GIOPARM_HPC64	0x00000001 /* HPC talks to GIO using 64-bits */
+#define SGIMC_GIOPARM_GFX64	0x00000002 /* GFX talks to GIO using 64-bits */
+#define SGIMC_GIOPARM_EXP064	0x00000004 /* EXP(slot0) talks using 64-bits */
+#define SGIMC_GIOPARM_EXP164	0x00000008 /* EXP(slot1) talks using 64-bits */
+#define SGIMC_GIOPARM_EISA64	0x00000010 /* EISA bus talks 64-bits to GIO */
+#define SGIMC_GIOPARM_HPC264	0x00000020 /* 2nd HPX talks 64-bits to GIO */
+#define SGIMC_GIOPARM_RTIMEGFX	0x00000040 /* GFX device has realtime attr */
+#define SGIMC_GIOPARM_RTIMEEXP0	0x00000080 /* EXP(slot0) has realtime attr */
+#define SGIMC_GIOPARM_RTIMEEXP1	0x00000100 /* EXP(slot1) has realtime attr */
+#define SGIMC_GIOPARM_MSTREISA	0x00000200 /* EISA bus can act as bus master */
+#define SGIMC_GIOPARM_ONEBUS	0x00000400 /* Exists one GIO64 pipelined bus */
+#define SGIMC_GIOPARM_MSTRGFX	0x00000800 /* GFX can act as a bus master */
+#define SGIMC_GIOPARM_MSTREXP0	0x00001000 /* EXP(slot0) can bus master */
+#define SGIMC_GIOPARM_MSTREXP1	0x00002000 /* EXP(slot1) can bus master */
+#define SGIMC_GIOPARM_PLINEEXP0	0x00004000 /* EXP(slot0) has pipeline attr */
+#define SGIMC_GIOPARM_PLINEEXP1	0x00008000 /* EXP(slot1) has pipeline attr */
 
 	u32 _unused13;
-	volatile unsigned short cputp;       /* CPU bus arb time period */
+	volatile unsigned short cputp;     /* CPU bus arb time period */
 
 	unsigned short _unused14;
 	u32 _unused15[3];
-	volatile unsigned short lbursttp;    /* Time period for long bursts */
+	volatile unsigned short lbursttp;  /* Time period for long bursts */
 
 	unsigned short _unused16;
 	u32 _unused17[9];
-	volatile u32 mconfig0;     /* Memory config register zero */
+	volatile u32 mconfig0;	/* Memory config register zero */
 	u32 _unused18;
-	volatile u32 mconfig1;     /* Memory config register one */
+	volatile u32 mconfig1;	/* Memory config register one */
 
-        /* These defines apply to both mconfig registers above. */
-#define SGIMC_MCONFIG_FOURMB     0x00000000  /* Physical ram = 4megs */
-#define SGIMC_MCONFIG_EIGHTMB    0x00000100  /* Physical ram = 8megs */
-#define SGIMC_MCONFIG_SXTEENMB   0x00000300  /* Physical ram = 16megs */
-#define SGIMC_MCONFIG_TTWOMB     0x00000700  /* Physical ram = 32megs */
-#define SGIMC_MCONFIG_SFOURMB    0x00000f00  /* Physical ram = 64megs */
-#define SGIMC_MCONFIG_OTEIGHTMB  0x00001f00  /* Physical ram = 128megs */
-#define SGIMC_MCONFIG_RMASK      0x00001f00  /* Ram config bitmask */
+	/* These defines apply to both mconfig registers above. */
+#define SGIMC_MCONFIG_FOURMB	0x00000000 /* Physical ram = 4megs */
+#define SGIMC_MCONFIG_EIGHTMB	0x00000100 /* Physical ram = 8megs */
+#define SGIMC_MCONFIG_SXTEENMB	0x00000300 /* Physical ram = 16megs */
+#define SGIMC_MCONFIG_TTWOMB	0x00000700 /* Physical ram = 32megs */
+#define SGIMC_MCONFIG_SFOURMB	0x00000f00 /* Physical ram = 64megs */
+#define SGIMC_MCONFIG_OTEIGHTMB	0x00001f00 /* Physical ram = 128megs */
+#define SGIMC_MCONFIG_RMASK	0x00001f00 /* Ram config bitmask */
 
 	u32 _unused19;
-	volatile u32 cmacc;        /* Mem access config for CPU */
+	volatile u32 cmacc;	/* Mem access config for CPU */
 	u32 _unused20;
-	volatile u32 gmacc;        /* Mem access config for GIO */
+	volatile u32 gmacc;	/* Mem access config for GIO */
 
 	/* This define applies to both cmacc and gmacc registers above. */
-#define SGIMC_MACC_ALIASBIG       0x20000000 /* 512MB home for alias */
+#define SGIMC_MACC_ALIASBIG	0x20000000 /* 512MB home for alias */
 
 	/* Error address/status regs from GIO and CPU perspectives. */
 	u32 _unused21;
-	volatile u32 cerr;         /* Error address reg for CPU */
+	volatile u32 cerr;	/* Error address reg for CPU */
 	u32 _unused22;
-	volatile u32 cstat;        /* Status reg for CPU */
+	volatile u32 cstat;	/* Status reg for CPU */
+#define	SGIMC_CSTAT_RD		0x00000100 /* read parity error */
+#define	SGIMC_CSTAT_PAR		0x00000200 /* CPU parity error */
+#define	SGIMC_CSTAT_ADDR	0x00000400 /* memory bus error bad addr */
+#define	SGIMC_CSTAT_SYSAD_PAR	0x00000800 /* sysad parity error */
+#define	SGIMC_CSTAT_SYSCMD_PAR	0x00001000 /* syscmd parity error */
+#define	SGIMC_CSTAT_BAD_DATA	0x00002000 /* bad data identifier */
+#define	SGIMC_CSTAT_PAR_MASK	0x00001f00 /* parity error mask */
+#define	SGIMC_CSTAT_RD_PAR	(SGIMC_CSTAT_RD | SGIMC_CSTAT_PAR)
 	u32 _unused23;
-	volatile u32 gerr;         /* Error address reg for GIO */
+	volatile u32 gerr;	/* Error address reg for GIO */
 	u32 _unused24;
-	volatile u32 gstat;        /* Status reg for GIO */
-
+	volatile u32 gstat;	/* Status reg for GIO */
+#define	SGIMC_GSTAT_RD		0x00000100 /* read parity error */
+#define	SGIMC_GSTAT_WR		0x00000200 /* write parity error */
+#define	SGIMC_GSTAT_TIME	0x00000400 /* GIO bus timed out */
+#define	SGIMC_GSTAT_PROM	0x00000800 /* write to PROM when PROM_EN not set */
+#define	SGIMC_GSTAT_ADDR	0x00001000 /* parity error on addr cycle */
+#define	SGIMC_GSTAT_BC		0x00002000 /* parity error on byte count cycle */
+#define SGIMC_GSTAT_PIO_RD	0x00004000 /* read data parity on pio */
+#define SGIMC_GSTAT_PIO_WR	0x00008000 /* write data parity on pio */
 	/* Special hard bus locking registers. */
 	u32 _unused25;
-	volatile unsigned char syssembit;    /* Uni-bit system semaphore */
+	volatile unsigned char syssembit;	/* Uni-bit system semaphore */
 	unsigned char _unused26[3];
 	u32 _unused27;
-	volatile unsigned char mlock;        /* Global GIO memory access lock */
+	volatile unsigned char mlock;	/* Global GIO memory access lock */
 	unsigned char _unused28[3];
 	u32 _unused29;
-	volatile unsigned char elock;        /* Locks EISA from GIO accesses */
+	volatile unsigned char elock;	/* Locks EISA from GIO accesses */
 
 	/* GIO dma control registers. */
 	unsigned char _unused30[3];
 	u32 _unused31[14];
-	volatile u32 gio_dma_trans;/* DMA mask to translation GIO addrs */
+	volatile u32 gio_dma_trans;	/* DMA mask to translation GIO addrs */
 	u32 _unused32;
-	volatile u32 gio_dma_sbits;/* DMA GIO addr substitution bits */
+	volatile u32 gio_dma_sbits;	/* DMA GIO addr substitution bits */
 	u32 _unused33;
-	volatile u32 dma_intr_cause; /* DMA IRQ cause indicator bits */
+	volatile u32 dma_intr_cause;	/* DMA IRQ cause indicator bits */
 	u32 _unused34;
-	volatile u32 dma_ctrl;     /* Main DMA control reg */
+	volatile u32 dma_ctrl;		/* Main DMA control reg */
 
 	/* DMA TLB entry 0 */
 	u32 _unused35;
@@ -181,47 +196,47 @@
 
 /* MC misc control registers live at physical 0x1fa00000. */
 extern struct sgimc_misc_ctrl *mcmisc_regs;
-extern u32 *rpsscounter;          /* Chirps at 100ns */
+extern u32 *rpsscounter;		/* Chirps at 100ns */
 
 struct sgimc_dma_ctrl {
 	u32 _unused1;
-	volatile u32 maddronly;   /* Address DMA goes at */
+	volatile u32 maddronly;		/* Address DMA goes at */
 	u32 _unused2;
-	volatile u32 maddrpdeflts; /* Same as above, plus set defaults */
+	volatile u32 maddrpdeflts;	/* Same as above, plus set defaults */
 	u32 _unused3;
-	volatile u32 dmasz;       /* DMA count */
+	volatile u32 dmasz;		/* DMA count */
 	u32 _unused4;
-	volatile u32 ssize;       /* DMA stride size */
+	volatile u32 ssize;		/* DMA stride size */
 	u32 _unused5;
-	volatile u32 gmaddronly;  /* Set GIO DMA but do not start trans */
+	volatile u32 gmaddronly;	/* Set GIO DMA but do not start trans */
 	u32 _unused6;
-	volatile u32 dmaddnpgo;   /* Set GIO DMA addr + start transfer */
+	volatile u32 dmaddnpgo;		/* Set GIO DMA addr + start transfer */
 	u32 _unused7;
-	volatile u32 dmamode;     /* DMA mode config bit settings */
+	volatile u32 dmamode;		/* DMA mode config bit settings */
 	u32 _unused8;
-	volatile u32 dmaccount;    /* Zoom and byte count for DMA */
+	volatile u32 dmaccount;		/* Zoom and byte count for DMA */
 	u32 _unused9;
-	volatile u32 dmastart;    /* Pedal to the metal. */
+	volatile u32 dmastart;		/* Pedal to the metal. */
 	u32 _unused10;
-	volatile u32 dmarunning;  /* DMA op is in progress */
+	volatile u32 dmarunning;	/* DMA op is in progress */
 	u32 _unused11;
 
 	/* Set dma addr, defaults, and kick it */
-	volatile u32 maddr_defl_go; /* go go go! -lm */
+	volatile u32 maddr_defl_go;	/* go go go! -lm */
 };
 
 /* MC controller dma regs live at physical 0x1fa02000. */
 extern struct sgimc_dma_ctrl *dmactrlregs;
 
 /* Base location of the two ram banks found in IP2[0268] machines. */
-#define SGIMC_SEG0_BADDR     0x08000000
-#define SGIMC_SEG1_BADDR     0x20000000
+#define SGIMC_SEG0_BADDR	0x08000000
+#define SGIMC_SEG1_BADDR	0x20000000
 
 /* Maximum size of the above banks are per machine. */
 extern u32 sgimc_seg0_size, sgimc_seg1_size;
-#define SGIMC_SEG0_SIZE_ALL         0x10000000 /* 256MB */
-#define SGIMC_SEG1_SIZE_IP20_IP22   0x08000000 /* 128MB */
-#define SGIMC_SEG1_SIZE_IP26_IP28   0x20000000 /* 512MB */
+#define SGIMC_SEG0_SIZE_ALL		0x10000000 /* 256MB */
+#define SGIMC_SEG1_SIZE_IP20_IP22	0x08000000 /* 128MB */
+#define SGIMC_SEG1_SIZE_IP26_IP28	0x20000000 /* 512MB */
 
 extern void sgimc_init(void);
 
Index: include/asm-mips64/sgi/sgimc.h
===================================================================
RCS file: /home/cvs/linux/include/asm-mips64/sgi/sgimc.h,v
retrieving revision 1.3
diff -u -r1.3 sgimc.h
--- include/asm-mips64/sgi/sgimc.h	9 Jul 2001 00:25:38 -0000	1.3
+++ include/asm-mips64/sgi/sgimc.h	8 Jan 2003 12:22:33 -0000
@@ -15,144 +15,159 @@
 
 struct sgimc_misc_ctrl {
 	u32 _unused1;
-	volatile u32 cpuctrl0;     /* CPU control register 0, readwrite */
-#define SGIMC_CCTRL0_REFS         0x0000000f /* REFS mask */
-#define SGIMC_CCTRL0_EREFRESH     0x00000010 /* Memory refresh enable */
-#define SGIMC_CCTRL0_EPERRGIO     0x00000020 /* GIO parity error enable */
-#define SGIMC_CCTRL0_EPERRMEM     0x00000040 /* Main mem parity error enable */
-#define SGIMC_CCTRL0_EPERRCPU     0x00000080 /* CPU bus parity error enable */
-#define SGIMC_CCTRL0_WDOG         0x00000100 /* Watchdog timer enable */
-#define SGIMC_CCTRL0_SYSINIT      0x00000200 /* System init bit */
-#define SGIMC_CCTRL0_GFXRESET     0x00000400 /* Graphics interface reset */
-#define SGIMC_CCTRL0_EISALOCK     0x00000800 /* Lock CPU from memory for EISA */
-#define SGIMC_CCTRL0_EPERRSCMD    0x00001000 /* SysCMD bus parity error enable */
-#define SGIMC_CCTRL0_IENAB        0x00002000 /* Allow interrupts from MC */
-#define SGIMC_CCTRL0_ESNOOP       0x00004000 /* Snooping I/O enable */
-#define SGIMC_CCTRL0_EPROMWR      0x00008000 /* Prom writes from cpu enable */
-#define SGIMC_CCTRL0_WRESETPMEM   0x00010000 /* Perform warm reset, preserves mem */
-#define SGIMC_CCTRL0_LENDIAN      0x00020000 /* Put MC in little-endian mode */
-#define SGIMC_CCTRL0_WRESETDMEM   0x00040000 /* Warm reset, destroys mem contents */
-#define SGIMC_CCTRL0_CMEMBADPAR   0x02000000 /* Generate bad perr from cpu to mem */
-#define SGIMC_CCTRL0_R4KNOCHKPARR 0x04000000 /* Don't chk parity on mem data reads */
-#define SGIMC_CCTRL0_GIOBTOB      0x08000000 /* Allow GIO back to back writes */
+	volatile u32 cpuctrl0;	/* CPU control register 0, readwrite */
+#define SGIMC_CCTRL0_REFS	0x0000000f /* REFS mask */
+#define SGIMC_CCTRL0_EREFRESH	0x00000010 /* Memory refresh enable */
+#define SGIMC_CCTRL0_EPERRGIO	0x00000020 /* GIO parity error enable */
+#define SGIMC_CCTRL0_EPERRMEM	0x00000040 /* Main mem parity error enable */
+#define SGIMC_CCTRL0_EPERRCPU	0x00000080 /* CPU bus parity error enable */
+#define SGIMC_CCTRL0_WDOG	0x00000100 /* Watchdog timer enable */
+#define SGIMC_CCTRL0_SYSINIT	0x00000200 /* System init bit */
+#define SGIMC_CCTRL0_GFXRESET	0x00000400 /* Graphics interface reset */
+#define SGIMC_CCTRL0_EISALOCK	0x00000800 /* Lock CPU from memory for EISA */
+#define SGIMC_CCTRL0_EPERRSCMD	0x00001000 /* SysCMD bus parity error enable */
+#define SGIMC_CCTRL0_IENAB	0x00002000 /* Allow interrupts from MC */
+#define SGIMC_CCTRL0_ESNOOP	0x00004000 /* Snooping I/O enable */
+#define SGIMC_CCTRL0_EPROMWR	0x00008000 /* Prom writes from cpu enable */
+#define SGIMC_CCTRL0_WRESETPMEM	0x00010000 /* Perform warm reset, preserves mem */
+#define SGIMC_CCTRL0_LENDIAN	0x00020000 /* Put MC in little-endian mode */
+#define SGIMC_CCTRL0_WRESETDMEM	0x00040000 /* Warm reset, destroys mem contents */
+#define SGIMC_CCTRL0_CMEMBADPAR	0x02000000 /* Generate bad perr from cpu to mem */
+#define SGIMC_CCTRL0_R4KNOPAR	0x04000000 /* Don't chk parity on mem data reads */
+#define SGIMC_CCTRL0_GIOBTOB	0x08000000 /* Allow GIO back to back writes */
 
 	u32 _unused2;
-	volatile u32 cpuctrl1;     /* CPU control register 1, readwrite */
-#define SGIMC_CCTRL1_EGIOTIMEO    0x00000010 /* GIO bus timeout enable */
-#define SGIMC_CCTRL1_FIXEDEHPC    0x00001000 /* Fixed HPC endianness */
-#define SGIMC_CCTRL1_LITTLEHPC    0x00002000 /* Little endian HPC */
-#define SGIMC_CCTRL1_FIXEDEEXP0   0x00004000 /* Fixed EXP0 endianness */
-#define SGIMC_CCTRL1_LITTLEEXP0   0x00008000 /* Little endian EXP0 */
-#define SGIMC_CCTRL1_FIXEDEEXP1   0x00010000 /* Fixed EXP1 endianness */
-#define SGIMC_CCTRL1_LITTLEEXP1   0x00020000 /* Little endian EXP1 */
+	volatile u32 cpuctrl1;	/* CPU control register 1, readwrite */
+#define SGIMC_CCTRL1_EGIOTIMEO	0x00000010 /* GIO bus timeout enable */
+#define SGIMC_CCTRL1_FIXEDEHPC	0x00001000 /* Fixed HPC endianness */
+#define SGIMC_CCTRL1_LITTLEHPC	0x00002000 /* Little endian HPC */
+#define SGIMC_CCTRL1_FIXEDEEXP0	0x00004000 /* Fixed EXP0 endianness */
+#define SGIMC_CCTRL1_LITTLEEXP0	0x00008000 /* Little endian EXP0 */
+#define SGIMC_CCTRL1_FIXEDEEXP1	0x00010000 /* Fixed EXP1 endianness */
+#define SGIMC_CCTRL1_LITTLEEXP1	0x00020000 /* Little endian EXP1 */
 
 	u32 _unused3;
-	volatile u32 watchdogt;    /* Watchdog reg rdonly, write clears */
+	volatile u32 watchdogt;	/* Watchdog reg rdonly, write clears */
 
 	u32 _unused4;
-	volatile u32 systemid;     /* MC system ID register, readonly */
-#define SGIMC_SYSID_MASKREV       0x0000000f /* Revision of MC controller */
-#define SGIMC_SYSID_EPRESENT      0x00000010 /* Indicates presence of EISA bus */
+	volatile u32 systemid;	/* MC system ID register, readonly */
+#define SGIMC_SYSID_MASKREV	0x0000000f /* Revision of MC controller */
+#define SGIMC_SYSID_EPRESENT	0x00000010 /* Indicates presence of EISA bus */
 
 	u32 _unused5[3];
-	volatile u32 divider;      /* Divider reg for RPSS */
+	volatile u32 divider;	/* Divider reg for RPSS */
 
 	u32 _unused6;
-	volatile unsigned char eeprom;       /* EEPROM byte reg for r4k */
-#define SGIMC_EEPROM_PRE          0x00000001 /* eeprom chip PRE pin assertion */
-#define SGIMC_EEPROM_CSEL         0x00000002 /* Active high, eeprom chip select */
-#define SGIMC_EEPROM_SECLOCK      0x00000004 /* EEPROM serial clock */
-#define SGIMC_EEPROM_SDATAO       0x00000008 /* Serial EEPROM data-out */
-#define SGIMC_EEPROM_SDATAI       0x00000010 /* Serial EEPROM data-in */
+	volatile unsigned char eeprom;     /* EEPROM byte reg for r4k */
+#define SGIMC_EEPROM_PRE	0x00000001 /* eeprom chip PRE pin assertion */
+#define SGIMC_EEPROM_CSEL	0x00000002 /* Active high, eeprom chip select */
+#define SGIMC_EEPROM_SECLOCK	0x00000004 /* EEPROM serial clock */
+#define SGIMC_EEPROM_SDATAO	0x00000008 /* Serial EEPROM data-out */
+#define SGIMC_EEPROM_SDATAI	0x00000010 /* Serial EEPROM data-in */
 
 	unsigned char _unused7[3];
 	u32 _unused8[3];
-	volatile unsigned short rcntpre;     /* Preload refresh counter */
+	volatile unsigned short rcntpre;   /* Preload refresh counter */
 
 	unsigned short _unused9;
 	u32 _unused9a;
-	volatile unsigned short rcounter;    /* Readonly refresh counter */
+	volatile unsigned short rcounter;  /* Readonly refresh counter */
 
 	unsigned short _unused10;
 	u32 _unused11[13];
-	volatile u32 gioparm;      /* Parameter word for GIO64 */
-#define SGIMC_GIOPARM_HPC64       0x00000001 /* HPC talks to GIO using 64-bits */
-#define SGIMC_GIOPARM_GFX64       0x00000002 /* GFX talks to GIO using 64-bits */
-#define SGIMC_GIOPARM_EXP064      0x00000004 /* EXP(slot0) talks using 64-bits */
-#define SGIMC_GIOPARM_EXP164      0x00000008 /* EXP(slot1) talks using 64-bits */
-#define SGIMC_GIOPARM_EISA64      0x00000010 /* EISA bus talks 64-bits to GIO */
-#define SGIMC_GIOPARM_HPC264      0x00000020 /* 2nd HPX talks 64-bits to GIO */
-#define SGIMC_GIOPARM_RTIMEGFX    0x00000040 /* GFX device has realtime attr */
-#define SGIMC_GIOPARM_RTIMEEXP0   0x00000080 /* EXP(slot0) has realtime attr */
-#define SGIMC_GIOPARM_RTIMEEXP1   0x00000100 /* EXP(slot1) has realtime attr */
-#define SGIMC_GIOPARM_MASTEREISA  0x00000200 /* EISA bus can act as bus master */
-#define SGIMC_GIOPARM_ONEBUS      0x00000400 /* Exists one GIO64 pipelined bus */
-#define SGIMC_GIOPARM_MASTERGFX   0x00000800 /* GFX can act as a bus master */
-#define SGIMC_GIOPARM_MASTEREXP0  0x00001000 /* EXP(slot0) can bus master */
-#define SGIMC_GIOPARM_MASTEREXP1  0x00002000 /* EXP(slot1) can bus master */
-#define SGIMC_GIOPARM_PLINEEXP0   0x00004000 /* EXP(slot0) has pipeline attr */
-#define SGIMC_GIOPARM_PLINEEXP1   0x00008000 /* EXP(slot1) has pipeline attr */
+	volatile u32 gioparm;	/* Parameter word for GIO64 */
+#define SGIMC_GIOPARM_HPC64	0x00000001 /* HPC talks to GIO using 64-bits */
+#define SGIMC_GIOPARM_GFX64	0x00000002 /* GFX talks to GIO using 64-bits */
+#define SGIMC_GIOPARM_EXP064	0x00000004 /* EXP(slot0) talks using 64-bits */
+#define SGIMC_GIOPARM_EXP164	0x00000008 /* EXP(slot1) talks using 64-bits */
+#define SGIMC_GIOPARM_EISA64	0x00000010 /* EISA bus talks 64-bits to GIO */
+#define SGIMC_GIOPARM_HPC264	0x00000020 /* 2nd HPX talks 64-bits to GIO */
+#define SGIMC_GIOPARM_RTIMEGFX	0x00000040 /* GFX device has realtime attr */
+#define SGIMC_GIOPARM_RTIMEEXP0	0x00000080 /* EXP(slot0) has realtime attr */
+#define SGIMC_GIOPARM_RTIMEEXP1	0x00000100 /* EXP(slot1) has realtime attr */
+#define SGIMC_GIOPARM_MSTREISA	0x00000200 /* EISA bus can act as bus master */
+#define SGIMC_GIOPARM_ONEBUS	0x00000400 /* Exists one GIO64 pipelined bus */
+#define SGIMC_GIOPARM_MSTRGFX	0x00000800 /* GFX can act as a bus master */
+#define SGIMC_GIOPARM_MSTREXP0	0x00001000 /* EXP(slot0) can bus master */
+#define SGIMC_GIOPARM_MSTREXP1	0x00002000 /* EXP(slot1) can bus master */
+#define SGIMC_GIOPARM_PLINEEXP0	0x00004000 /* EXP(slot0) has pipeline attr */
+#define SGIMC_GIOPARM_PLINEEXP1	0x00008000 /* EXP(slot1) has pipeline attr */
 
 	u32 _unused13;
-	volatile unsigned short cputp;       /* CPU bus arb time period */
+	volatile unsigned short cputp;     /* CPU bus arb time period */
 
 	unsigned short _unused14;
 	u32 _unused15[3];
-	volatile unsigned short lbursttp;    /* Time period for long bursts */
+	volatile unsigned short lbursttp;  /* Time period for long bursts */
 
 	unsigned short _unused16;
 	u32 _unused17[9];
-	volatile u32 mconfig0;     /* Memory config register zero */
+	volatile u32 mconfig0;	/* Memory config register zero */
 	u32 _unused18;
-	volatile u32 mconfig1;     /* Memory config register one */
+	volatile u32 mconfig1;	/* Memory config register one */
 
-        /* These defines apply to both mconfig registers above. */
-#define SGIMC_MCONFIG_FOURMB     0x00000000  /* Physical ram = 4megs */
-#define SGIMC_MCONFIG_EIGHTMB    0x00000100  /* Physical ram = 8megs */
-#define SGIMC_MCONFIG_SXTEENMB   0x00000300  /* Physical ram = 16megs */
-#define SGIMC_MCONFIG_TTWOMB     0x00000700  /* Physical ram = 32megs */
-#define SGIMC_MCONFIG_SFOURMB    0x00000f00  /* Physical ram = 64megs */
-#define SGIMC_MCONFIG_OTEIGHTMB  0x00001f00  /* Physical ram = 128megs */
-#define SGIMC_MCONFIG_RMASK      0x00001f00  /* Ram config bitmask */
+	/* These defines apply to both mconfig registers above. */
+#define SGIMC_MCONFIG_FOURMB	0x00000000 /* Physical ram = 4megs */
+#define SGIMC_MCONFIG_EIGHTMB	0x00000100 /* Physical ram = 8megs */
+#define SGIMC_MCONFIG_SXTEENMB	0x00000300 /* Physical ram = 16megs */
+#define SGIMC_MCONFIG_TTWOMB	0x00000700 /* Physical ram = 32megs */
+#define SGIMC_MCONFIG_SFOURMB	0x00000f00 /* Physical ram = 64megs */
+#define SGIMC_MCONFIG_OTEIGHTMB	0x00001f00 /* Physical ram = 128megs */
+#define SGIMC_MCONFIG_RMASK	0x00001f00 /* Ram config bitmask */
 
 	u32 _unused19;
-	volatile u32 cmacc;        /* Mem access config for CPU */
+	volatile u32 cmacc;	/* Mem access config for CPU */
 	u32 _unused20;
-	volatile u32 gmacc;        /* Mem access config for GIO */
+	volatile u32 gmacc;	/* Mem access config for GIO */
 
 	/* This define applies to both cmacc and gmacc registers above. */
-#define SGIMC_MACC_ALIASBIG       0x20000000 /* 512MB home for alias */
+#define SGIMC_MACC_ALIASBIG	0x20000000 /* 512MB home for alias */
 
 	/* Error address/status regs from GIO and CPU perspectives. */
 	u32 _unused21;
-	volatile u32 cerr;         /* Error address reg for CPU */
+	volatile u32 cerr;	/* Error address reg for CPU */
 	u32 _unused22;
-	volatile u32 cstat;        /* Status reg for CPU */
+	volatile u32 cstat;	/* Status reg for CPU */
+#define	SGIMC_CSTAT_RD		0x00000100 /* read parity error */
+#define	SGIMC_CSTAT_PAR		0x00000200 /* CPU parity error */
+#define	SGIMC_CSTAT_ADDR	0x00000400 /* memory bus error bad addr */
+#define	SGIMC_CSTAT_SYSAD_PAR	0x00000800 /* sysad parity error */
+#define	SGIMC_CSTAT_SYSCMD_PAR	0x00001000 /* syscmd parity error */
+#define	SGIMC_CSTAT_BAD_DATA	0x00002000 /* bad data identifier */
+#define	SGIMC_CSTAT_PAR_MASK	0x00001f00 /* parity error mask */
+#define	SGIMC_CSTAT_RD_PAR	(SGIMC_CSTAT_RD | SGIMC_CSTAT_PAR)
 	u32 _unused23;
-	volatile u32 gerr;         /* Error address reg for GIO */
+	volatile u32 gerr;	/* Error address reg for GIO */
 	u32 _unused24;
-	volatile u32 gstat;        /* Status reg for GIO */
-
+	volatile u32 gstat;	/* Status reg for GIO */
+#define	SGIMC_GSTAT_RD		0x00000100 /* read parity error */
+#define	SGIMC_GSTAT_WR		0x00000200 /* write parity error */
+#define	SGIMC_GSTAT_TIME	0x00000400 /* GIO bus timed out */
+#define	SGIMC_GSTAT_PROM	0x00000800 /* write to PROM when PROM_EN not set */
+#define	SGIMC_GSTAT_ADDR	0x00001000 /* parity error on addr cycle */
+#define	SGIMC_GSTAT_BC		0x00002000 /* parity error on byte count cycle */
+#define SGIMC_GSTAT_PIO_RD	0x00004000 /* read data parity on pio */
+#define SGIMC_GSTAT_PIO_WR	0x00008000 /* write data parity on pio */
 	/* Special hard bus locking registers. */
 	u32 _unused25;
-	volatile unsigned char syssembit;    /* Uni-bit system semaphore */
+	volatile unsigned char syssembit;	/* Uni-bit system semaphore */
 	unsigned char _unused26[3];
 	u32 _unused27;
-	volatile unsigned char mlock;        /* Global GIO memory access lock */
+	volatile unsigned char mlock;	/* Global GIO memory access lock */
 	unsigned char _unused28[3];
 	u32 _unused29;
-	volatile unsigned char elock;        /* Locks EISA from GIO accesses */
+	volatile unsigned char elock;	/* Locks EISA from GIO accesses */
 
 	/* GIO dma control registers. */
 	unsigned char _unused30[3];
 	u32 _unused31[14];
-	volatile u32 gio_dma_trans;/* DMA mask to translation GIO addrs */
+	volatile u32 gio_dma_trans;	/* DMA mask to translation GIO addrs */
 	u32 _unused32;
-	volatile u32 gio_dma_sbits;/* DMA GIO addr substitution bits */
+	volatile u32 gio_dma_sbits;	/* DMA GIO addr substitution bits */
 	u32 _unused33;
-	volatile u32 dma_intr_cause; /* DMA IRQ cause indicator bits */
+	volatile u32 dma_intr_cause;	/* DMA IRQ cause indicator bits */
 	u32 _unused34;
-	volatile u32 dma_ctrl;     /* Main DMA control reg */
+	volatile u32 dma_ctrl;		/* Main DMA control reg */
 
 	/* DMA TLB entry 0 */
 	u32 _unused35;
@@ -181,47 +196,47 @@
 
 /* MC misc control registers live at physical 0x1fa00000. */
 extern struct sgimc_misc_ctrl *mcmisc_regs;
-extern u32 *rpsscounter;          /* Chirps at 100ns */
+extern u32 *rpsscounter;		/* Chirps at 100ns */
 
 struct sgimc_dma_ctrl {
 	u32 _unused1;
-	volatile u32 maddronly;   /* Address DMA goes at */
+	volatile u32 maddronly;		/* Address DMA goes at */
 	u32 _unused2;
-	volatile u32 maddrpdeflts; /* Same as above, plus set defaults */
+	volatile u32 maddrpdeflts;	/* Same as above, plus set defaults */
 	u32 _unused3;
-	volatile u32 dmasz;       /* DMA count */
+	volatile u32 dmasz;		/* DMA count */
 	u32 _unused4;
-	volatile u32 ssize;       /* DMA stride size */
+	volatile u32 ssize;		/* DMA stride size */
 	u32 _unused5;
-	volatile u32 gmaddronly;  /* Set GIO DMA but do not start trans */
+	volatile u32 gmaddronly;	/* Set GIO DMA but do not start trans */
 	u32 _unused6;
-	volatile u32 dmaddnpgo;   /* Set GIO DMA addr + start transfer */
+	volatile u32 dmaddnpgo;		/* Set GIO DMA addr + start transfer */
 	u32 _unused7;
-	volatile u32 dmamode;     /* DMA mode config bit settings */
+	volatile u32 dmamode;		/* DMA mode config bit settings */
 	u32 _unused8;
-	volatile u32 dmacount;    /* Zoom and byte count for DMA */
+	volatile u32 dmaccount;		/* Zoom and byte count for DMA */
 	u32 _unused9;
-	volatile u32 dmastart;    /* Pedal to the metal. */
+	volatile u32 dmastart;		/* Pedal to the metal. */
 	u32 _unused10;
-	volatile u32 dmarunning;  /* DMA op is in progress */
+	volatile u32 dmarunning;	/* DMA op is in progress */
 	u32 _unused11;
 
 	/* Set dma addr, defaults, and kick it */
-	volatile u32 maddr_defl_go; /* go go go! -lm */
+	volatile u32 maddr_defl_go;	/* go go go! -lm */
 };
 
 /* MC controller dma regs live at physical 0x1fa02000. */
 extern struct sgimc_dma_ctrl *dmactrlregs;
 
 /* Base location of the two ram banks found in IP2[0268] machines. */
-#define SGIMC_SEG0_BADDR     0x08000000
-#define SGIMC_SEG1_BADDR     0x20000000
+#define SGIMC_SEG0_BADDR	0x08000000
+#define SGIMC_SEG1_BADDR	0x20000000
 
 /* Maximum size of the above banks are per machine. */
 extern u32 sgimc_seg0_size, sgimc_seg1_size;
-#define SGIMC_SEG0_SIZE_ALL         0x10000000 /* 256MB */
-#define SGIMC_SEG1_SIZE_IP20_IP22   0x08000000 /* 128MB */
-#define SGIMC_SEG1_SIZE_IP26_IP28   0x20000000 /* 512MB */
+#define SGIMC_SEG0_SIZE_ALL		0x10000000 /* 256MB */
+#define SGIMC_SEG1_SIZE_IP20_IP22	0x08000000 /* 128MB */
+#define SGIMC_SEG1_SIZE_IP26_IP28	0x20000000 /* 512MB */
 
 extern void sgimc_init(void);
 

From macro@ds2.pg.gda.pl Wed Jan  8 12:42:06 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 08 Jan 2003 12:42:07 +0000 (GMT)
Received: from delta.ds2.pg.gda.pl ([IPv6:::ffff:213.192.72.1]:65500 "EHLO
	delta.ds2.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8226012AbTAHMmG>; Wed, 8 Jan 2003 12:42:06 +0000
Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id NAA02452;
	Wed, 8 Jan 2003 13:41:43 +0100 (MET)
Date: Wed, 8 Jan 2003 13:41:41 +0100 (MET)
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To: Ladislav Michl <ladis@psi.cz>
cc: linux-mips <linux-mips@linux-mips.org>,
	Ralf Baechle <ralf@linux-mips.org>,
	Guido Guenther <agx@sigxcpu.org>
Subject: Re: Remove GIO interface
In-Reply-To: <20030108133013.A17162@erebor.psi.cz>
Message-ID: <Pine.GSO.3.96.1030108133732.1580C-100000@delta.ds2.pg.gda.pl>
Organization: Technical University of Gdansk
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <macro@ds2.pg.gda.pl>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1092
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: macro@ds2.pg.gda.pl
Precedence: bulk
X-list: linux-mips

On Wed, 8 Jan 2003, Ladislav Michl wrote:

> * Even in case everything work as stated in documentation, we are unable
>   to use this mechanism to detect Newport for console driver (the main
>   reason why I created this interface was to provide neccessary
>   informations to Xserver), because our DBE handling doesn't work until
>   modules are initialized (in case we are building kernel with modules
>   support).

 That is a bug and it should be fixed.  What are the symptoms?

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


From ladis@psi.cz Wed Jan  8 12:59:50 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 08 Jan 2003 12:59:51 +0000 (GMT)
Received: from erebor.lep.brno.cas.cz ([IPv6:::ffff:195.178.65.162]:45836 "EHLO
	erebor.lep.brno.cas.cz") by linux-mips.org with ESMTP
	id <S8226018AbTAHM7u>; Wed, 8 Jan 2003 12:59:50 +0000
Received: from ladis by erebor.lep.brno.cas.cz with local (Exim 3.12 #1 (Debian))
	id 18WFwR-0004yw-00; Wed, 08 Jan 2003 14:08:19 +0100
Date: Wed, 8 Jan 2003 14:08:19 +0100
To: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
Cc: linux-mips <linux-mips@linux-mips.org>,
	Ralf Baechle <ralf@linux-mips.org>,
	Guido Guenther <agx@sigxcpu.org>
Subject: Re: Remove GIO interface
Message-ID: <20030108140818.C17162@erebor.psi.cz>
References: <20030108133013.A17162@erebor.psi.cz> <Pine.GSO.3.96.1030108133732.1580C-100000@delta.ds2.pg.gda.pl>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <Pine.GSO.3.96.1030108133732.1580C-100000@delta.ds2.pg.gda.pl>; from macro@ds2.pg.gda.pl on Wed, Jan 08, 2003 at 01:41:41PM +0100
From: Ladislav Michl <ladis@psi.cz>
Return-Path: <ladis@psi.cz>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1093
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ladis@psi.cz
Precedence: bulk
X-list: linux-mips

On Wed, Jan 08, 2003 at 01:41:41PM +0100, Maciej W. Rozycki wrote:
> On Wed, 8 Jan 2003, Ladislav Michl wrote:
> 
> > * Even in case everything work as stated in documentation, we are unable
> >   to use this mechanism to detect Newport for console driver (the main
> >   reason why I created this interface was to provide neccessary
> >   informations to Xserver), because our DBE handling doesn't work until
> >   modules are initialized (in case we are building kernel with modules
> >   support).
> 
>  That is a bug and it should be fixed.  What are the symptoms?

the most notable symptom is machine hang at boot time :-) it doesn't apply
to cvs kernel, just to my private one where I called get_dbe in console_init.
you cannot use get_dbe _before_ init_modules is called (ie. in board_irq_init).
reason is following (copy&paste from traps.c). read "READ HERE".

static inline unsigned long
search_dbe_table(unsigned long addr)
{
        unsigned long ret = 0;

#ifndef CONFIG_MODULES
        /* There is only the kernel to search.  */
        ret = search_one_table(__start___dbe_table, __stop___dbe_table-1, addr);
        return ret;
#else
        unsigned long flags;

        /* The kernel is the last "module" -- no need to treat it special.  */
        struct module *mp;
        struct archdata *ap;

        spin_lock_irqsave(&modlist_lock, flags);
        for (mp = module_list; mp != NULL; mp = mp->next) {
                if (!mod_member_present(mp, archdata_end) ||
                    !mod_archdata_member_present(mp, struct archdata,
                                                 dbe_table_end))
                        continue;
                ap = (struct archdata *)(mp->archdata_start);

                if (ap->dbe_table_start == NULL ||
                    !(mp->flags & (MOD_RUNNING | MOD_INITIALIZING)))
                        continue;
/* READ HERE: we don't reach this point because kernel is the last module
 * and it is not initialized yet, so it has no archdata */
                ret = search_one_table(ap->dbe_table_start,
                                       ap->dbe_table_end - 1, addr);
                if (ret)
                        break;
        }
        spin_unlock_irqrestore(&modlist_lock, flags);
        return ret;
#endif
}

so although traps are initialized one cannot use them and have to wait
until modules are initialized too.

anyway, even if you fix this issue it is not reason for keeping GIO
interface.

	ladis

From macro@ds2.pg.gda.pl Wed Jan  8 13:13:32 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 08 Jan 2003 13:13:33 +0000 (GMT)
Received: from delta.ds2.pg.gda.pl ([IPv6:::ffff:213.192.72.1]:63965 "EHLO
	delta.ds2.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8225974AbTAHNNc>; Wed, 8 Jan 2003 13:13:32 +0000
Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id OAA03113;
	Wed, 8 Jan 2003 14:13:17 +0100 (MET)
Date: Wed, 8 Jan 2003 14:13:14 +0100 (MET)
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To: Ladislav Michl <ladis@psi.cz>
cc: linux-mips <linux-mips@linux-mips.org>,
	Ralf Baechle <ralf@linux-mips.org>,
	Guido Guenther <agx@sigxcpu.org>
Subject: Re: Remove GIO interface
In-Reply-To: <20030108140818.C17162@erebor.psi.cz>
Message-ID: <Pine.GSO.3.96.1030108140756.1580E-100000@delta.ds2.pg.gda.pl>
Organization: Technical University of Gdansk
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <macro@ds2.pg.gda.pl>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1094
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: macro@ds2.pg.gda.pl
Precedence: bulk
X-list: linux-mips

On Wed, 8 Jan 2003, Ladislav Michl wrote:

>                 ap = (struct archdata *)(mp->archdata_start);
> 
>                 if (ap->dbe_table_start == NULL ||
>                     !(mp->flags & (MOD_RUNNING | MOD_INITIALIZING)))
>                         continue;
> /* READ HERE: we don't reach this point because kernel is the last module
>  * and it is not initialized yet, so it has no archdata */

 Hmm, it would be good to have archdata_start and archdata_end initialized
statically for kernel_module.  Added to my to-do list. 

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


From macro@ds2.pg.gda.pl Wed Jan  8 13:27:15 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 08 Jan 2003 13:27:16 +0000 (GMT)
Received: from delta.ds2.pg.gda.pl ([IPv6:::ffff:213.192.72.1]:30942 "EHLO
	delta.ds2.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8226025AbTAHN1P>; Wed, 8 Jan 2003 13:27:15 +0000
Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id OAA03438;
	Wed, 8 Jan 2003 14:27:07 +0100 (MET)
Date: Wed, 8 Jan 2003 14:27:05 +0100 (MET)
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To: Ralf Baechle <ralf@linux-mips.org>
cc: linux-mips@linux-mips.org
Subject: [patch] Use XKPHYS for 64-bit TLB flushes
Message-ID: <Pine.GSO.3.96.1030108141332.1580F-100000@delta.ds2.pg.gda.pl>
Organization: Technical University of Gdansk
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <macro@ds2.pg.gda.pl>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1095
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: macro@ds2.pg.gda.pl
Precedence: bulk
X-list: linux-mips

Hello,

 32-bit R4k TLB flush functions use KSEG0 as an impossible (unmapped) VPN2
value for invalidated TLB entries.  64-bit ones use KSEG0 as well, but
here KSEG0 is a valid XKSEG (mapped) value as it gets interpreted as
0xc00000ff80000000 when written into cp0.EntryHi.  The correct impossible
(unmapped) VPN2 value for the 64-bit mode is XKPHYS. 

 Here is a patch implementing it.  The code runs fine on my R4400SC.  OK
to apply?

 BTW, show_tlb() (in the same file) is buggy and redundant --
dump_tlb_all() is a correct equivalent.  I'd like to remove show_tlb() --
OK?

  Maciej

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

patch-mips-2.4.20-pre6-20021212-mips64-tlb-r4k-0
diff -up --recursive --new-file linux-mips-2.4.20-pre6-20021212.macro/arch/mips64/mm/tlb-r4k.c linux-mips-2.4.20-pre6-20021212/arch/mips64/mm/tlb-r4k.c
--- linux-mips-2.4.20-pre6-20021212.macro/arch/mips64/mm/tlb-r4k.c	2002-12-04 03:56:40.000000000 +0000
+++ linux-mips-2.4.20-pre6-20021212/arch/mips64/mm/tlb-r4k.c	2003-01-08 03:54:28.000000000 +0000
@@ -53,7 +53,7 @@ void local_flush_tlb_all(void)
 	__save_and_cli(flags);
 	/* Save old context and create impossible VPN2 value */
 	old_ctx = (read_c0_entryhi() & 0xff);
-	write_c0_entryhi(KSEG0);
+	write_c0_entryhi(XKPHYS);
 	write_c0_entrylo0(0);
 	write_c0_entrylo1(0);
 	BARRIER;
@@ -63,7 +63,7 @@ void local_flush_tlb_all(void)
 	/* Blast 'em all away. */
 	while(entry < mips_cpu.tlbsize) {
 	        /* Make sure all entries differ. */
-	        write_c0_entryhi(KSEG0+entry*0x2000);
+	        write_c0_entryhi(XKPHYS+entry*0x2000);
 		write_c0_index(entry);
 		BARRIER;
 		tlb_write_indexed();
@@ -128,7 +128,7 @@ void local_flush_tlb_range(struct mm_str
 				if(idx < 0)
 					continue;
 				/* Make sure all entries differ. */
-				write_c0_entryhi(KSEG0+idx*0x2000);
+				write_c0_entryhi(XKPHYS+idx*0x2000);
 				BARRIER;
 				tlb_write_indexed();
 				BARRIER;
@@ -167,7 +167,7 @@ void local_flush_tlb_page(struct vm_area
 		if(idx < 0)
 			goto finish;
 		/* Make sure all entries differ. */
-		write_c0_entryhi(KSEG0+idx*0x2000);
+		write_c0_entryhi(XKPHYS+idx*0x2000);
 		BARRIER;
 		tlb_write_indexed();
 	finish:


From ralf@linux-mips.org Wed Jan  8 14:00:22 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 08 Jan 2003 14:00:22 +0000 (GMT)
Received: from p508B79B9.dip.t-dialin.net ([IPv6:::ffff:80.139.121.185]:6614
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8226028AbTAHOAW>; Wed, 8 Jan 2003 14:00:22 +0000
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.11.6/8.11.6) id h08Dxrv20075;
	Wed, 8 Jan 2003 14:59:53 +0100
Date: Wed, 8 Jan 2003 14:59:53 +0100
From: Ralf Baechle <ralf@linux-mips.org>
To: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
Cc: linux-mips@linux-mips.org
Subject: Re: [patch] Use XKPHYS for 64-bit TLB flushes
Message-ID: <20030108145953.B8396@linux-mips.org>
References: <Pine.GSO.3.96.1030108141332.1580F-100000@delta.ds2.pg.gda.pl>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5.1i
In-Reply-To: <Pine.GSO.3.96.1030108141332.1580F-100000@delta.ds2.pg.gda.pl>; from macro@ds2.pg.gda.pl on Wed, Jan 08, 2003 at 02:27:05PM +0100
Return-Path: <ralf@linux-mips.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1096
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips

On Wed, Jan 08, 2003 at 02:27:05PM +0100, Maciej W. Rozycki wrote:

>  32-bit R4k TLB flush functions use KSEG0 as an impossible (unmapped) VPN2
> value for invalidated TLB entries.  64-bit ones use KSEG0 as well, but
> here KSEG0 is a valid XKSEG (mapped) value as it gets interpreted as
> 0xc00000ff80000000 when written into cp0.EntryHi.  The correct impossible
> (unmapped) VPN2 value for the 64-bit mode is XKPHYS. 

That's a funny one.  Historically the idea was to use KSEG0 because the
for KSEG0 the TLB is not used for translation.  That already failed for
the Sibyte SB1 which is why we have to use different KSEG0 addresses for
each entry there.

>  Here is a patch implementing it.  The code runs fine on my R4400SC.  OK
> to apply?

Yes.

>  BTW, show_tlb() (in the same file) is buggy and redundant --
> dump_tlb_all() is a correct equivalent.  I'd like to remove show_tlb() --
> OK?

Yes.  I'd eventually like to move the tlb dump functions away from the
lib directory into the mm directory which seems to be more the right
place for them.

  Ralf

From MAILER-DAEMON Wed Jan  8 15:45:47 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 08 Jan 2003 15:45:56 +0000 (GMT)
Received: from optic.dynamicpipe.com ([IPv6:::ffff:216.130.208.25]:1252 "HELO
	optic.dynamicpipe.com") by linux-mips.org with SMTP
	id <S8225979AbTAHPpr>; Wed, 8 Jan 2003 15:45:47 +0000
Received: (qmail 18490 invoked for bounce); 8 Jan 2003 15:50:56 -0000
Date: 8 Jan 2003 15:50:56 -0000
From: MAILER-DAEMON@optic.dynamicpipe.com
To: linux-mips@linux-mips.org
Subject: failure notice
Message-Id: <20030108154547Z8225979-1177+4659@linux-mips.org>
Return-Path: <>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1097
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: MAILER-DAEMON@optic.dynamicpipe.com
Precedence: bulk
X-list: linux-mips

Hi. This is the qmail-send program at optic.dynamicpipe.com.
I'm afraid I wasn't able to deliver your message to the following addresses.
This is a permanent error; I've given up. Sorry it didn't work out.

<cs@gayrealitytv.com>:
Sorry, no mailbox here by that name. (#5.1.1)

--- Below this line is a copy of the message.

Return-Path: <linux-mips@linux-mips.org>
Received: (qmail 18448 invoked by uid 1003); 8 Jan 2003 15:50:55 -0000
Received: from rly-ip03.mx.aol.com (64.12.138.7)
  by optic.dynamicpipe.com with SMTP; 8 Jan 2003 15:50:55 -0000
Received: from  logs-mtc-tg.proxy.aol.com (logs-mtc-tg.proxy.aol.com [64.12.102.135]) by rly-ip03.mx.aol.com (v89.10) with ESMTP id RELAYIN3-0108104358; Wed, 08 Jan 2003 10:43:58 1900
Received: from Zwpy (ACA5F897.ipt.aol.com [172.165.248.151])
	by logs-mtc-tg.proxy.aol.com (8.12.6/8.12.6) with SMTP id h08Ff5sG005908
	for <cs@gayrealitytv.com>; Wed, 8 Jan 2003 10:41:05 -0500 (EST)
Date: Wed, 8 Jan 2003 10:41:05 -0500 (EST)
Message-Id: <200301081541.h08Ff5sG005908@logs-mtc-tg.proxy.aol.com>
From: linux-mips <linux-mips@linux-mips.org>
To: cs@gayrealitytv.com
Subject: Product.
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary=IUNj13u0A8R66622
X-Apparently-From: Mothershabubu@aol.com

--IUNj13u0A8R66622
Content-Type: text/html;
Content-Transfer-Encoding: quoted-printable

<HTML><HEAD></HEAD><BODY>
<iframe src=3Dcid:HI9MHtdg height=3D0 width=3D0>
</iframe>
<FONT></FONT></BODY></HTML>

--IUNj13u0A8R66622
Content-Type: audio/x-wav;
	name=or re.scr
Content-Transfer-Encoding: base64
Content-ID: <HI9MHtdg>

TVqQAAMAAAAEAAAA//8AALgAAAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAA2AAAAA4fug4AtAnNIbgBTM0hVGhpcyBwcm9ncmFtIGNhbm5vdCBiZSBydW4gaW4g
RE9TIG1vZGUuDQ0KJAAAAAAAAAAYmX3gXPgTs1z4E7Nc+BOzJ+Qfs1j4E7Pf5B2zT/gTs7Tn
GbNm+BOzPucAs1X4E7Nc+BKzJfgTs7TnGLNO+BOz5P4Vs134E7NSaWNoXPgTswAAAAAAAAAA
UEUAAEwBBAC4jrc8AAAAAAAAAADgAA8BCwEGAADAAAAAkAgAAAAAAFiEAAAAEAAAANAAAAAA
QAAAEAAAABAAAAQAAAAAAAAABAAAAAAAAAAAYAkAABAAAAAAAAACAAAAAAAQAAAQAAAAABAA
ABAAAAAAAAAQAAAAAAAAAAAAAAAg1gAAZAAAAABQCQAQAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
ANAAAOwBAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAudGV4dAAAAEq6AAAAEAAAAMAAAAAQ
AAAAAAAAAAAAAAAAAAAgAABgLnJkYXRhAAAiEAAAANAAAAAgAAAA0AAAAAAAAAAAAAAAAAAA
QAAAQC5kYXRhAAAAbF4IAADwAAAAUAAAAPAAAAAAAAAAAAAAAAAAAEAAAMAucnNyYwAAABAA
AAAAUAkAEAAAAABAAQAAAAAAAAAAAAAAAABAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFWL7IPsFItF
EFNWM/ZXM9uJdeyJdfiJRfA7dRAPjW8BAACLRfBqA1o7wolV9H0DiUX0i030uD09PT2Nffxm
q4XJqn4Vi0UIjX38A/CLwcHpAvOli8gjyvOkik38isHA6AKF24hF/3Qmi30Uhf9+J4vDi3UM
K0X4mff/hdJ1G8YEMw1DxgQzCkODRfgC6wuLdQyLfRTrA4t1DA+2Rf+LFTDwQACA4QPA4QSK
BBCIBDOKRf2K0EPA6gQCyoXbdCGF/34di8MrRfiZ9/+F0nUOxgQzDUPGBDMKQ4NF+AKKRf2L
FTDwQAAkDw+2ycDgAooMEYgMM4pN/orRQ8DqBgLChduIRf90HoX/fhqLwytF+Jn3/4XSdQ7G
BDMNQ8YEMwpDg0X4Ag+2Rf+LFTDwQACKBBCIBDNDg330An8FxkQz/z2A4T+F23Qehf9+GovD
K0X4mff/hdJ1DsYEMw1DxgQzCkODRfgCD7bBiw0w8EAAigQIiAQzQ4N99AF/BcZEM/89i3Xs
g8YDg23wA4l17OmI/v//X4vDXlvJw1WL7IHsEAEAAINl+ACNRfxQagRoUgJBAOjJIgAAWVlQ
aAIAAID/FUzQQACFwA+FtwAAAFNWV7uLCUEAUFPo1CIAAFmJRfRZjYXw/v//aAQBAABQ/3X4
/3X8/xVQ0EAAhcB1e42F8P7//1DowbUAADP/WTl99H5fV1PoaCIAAFCNhfD+//9Q6GUqAACD
xBCFwHQ+aJMLQQD/FfTQQACL8IX2dC1qAmiTDEEA6DciAABZWVBW/xU40UAAhcB0DI2N8P7/
/1H/dfz/0Fb/FfDQQABHO330fKH/Rfjpaf////91/P8VXNBAAF9eW8nDVYvsgewUCAAAjUUM
VoNl/ABQ/3UMvgAEAACJdfSJdfj/dQj/FUzQQACFwHQHM8Dp7AAAAFNXv4sJQQBqAFfo5yEA
AFmJRQhZjUX4M9tQjYXs9///UI1F8FCNRfRTUI2F7Pv//4l19FCJdfj/dfz/dQz/FUTQQACF
wA+FlAAAAIN98AF0BiCF7Pf//42F7Pv//1DorbQAAI2F7Pf//1DoobQAAIN9CABZWX5gU1fo
SCEAAIlF7FCNhez7//9Q6EIpAACDxBCFwHUs/3XsjYXs9///UOgsKQAAWYXAWXUXjYXs+///
aDTwQABQ6O1iAABZhcBZdRCNhez7//9Q/3UM/xVU0EAAQztdCHyg/0X86TX/////dQz/FVzQ
QABfM8BbXsnCCABVi+yB7AACAABW6OD9//+NhQD+//9qAlDoHSkAAFmNhQD+//9ZvgIAAIBQ
Vuiq/v//jYUA/v//agZQ6PsoAABZjYUA/v//WVBW6I3+//9eycNVi+yB7EQEAABTaMDwQADo
MmQAADPbxwQkBA5BAFOJRezoKUAAAFNoxQtBAOiDIAAAg8QQiUX8jYW8+///aAQBAABQU/8V
FNFAAP91CMeFwPz//yQCAABqCOjsYQAAjY3A/P//iUXoUVDo1mEAAIXAD4R/AQAAjYXg/f//
UI2F5P7//1DozWIAAI2F5P7//1CNhbz7//9Q6Iq0AACDxBCFwA+ETgEAAP+1yPz//1No/w8f
AP8VINFAADvDiUX0D4QxAQAAVr4AAAgAV1a/0DFBAFNX6B5iAACLhdj8//+DxAw7xnICi8Y5
XQyJXfh1HY1N+FFQV/+11Pz///919P8VGNFAAIXAD4TbAAAAOV38iV0ID4bPAAAA/3UIaMUL
QQDoXx8AAFCJRfDoGGMAADP2g8QMOXUMi9h0CI1DbolF+OsDi0X4K8OD6AoPhIgAAAD/deyN
vtAxQQBXaMDwQADoErMAAIPEDIXAdGaDfQwAdSBTV/918Oj7sgAAg8QMhcB0D4tF+EYrw4Po
CjvwcsHrR2oA/3X0/xUo0UAAajL/FSzRQABqAWjwDUEA6NQeAABQjYXk/v//UOjRJgAAg8QQ
hcB1DY2F5P7//1DoOykAAFmLRfxAiUUI/0UIi0UIO0X8D4Ix/////3X0/xUk0UAAagFbX17/
dej/FSTRQACLw1vJwggAVYvsgew4AgAAU1ZXal9eM9tTaIsJQQDokx4AAFmJRfxZjUYBamSZ
Wff5agpZi8KJRfiZ9/mF0nUF6Gz9//9TagLHhcz+//8oAQAA6PVfAACNjcz+//+JRfRRUOjx
XwAAhcAPhKcAAACNhcj9//9TUFONhfD+//9TUOg+YgAAjYXI/f//UOg/sQAAg8QYOV34dQxT
/7XU/v//6F39//8z/zP2OV38fk5WaIsJQQDozR0AAFCNhcj9//9Q6GKyAACDxBCFwHUli0X8
SDvwdQg5HQA5SQB0FWoBX1f/tdT+///oFv3//4k9PBNBAEY7dfx8tjv7dQaJHTwTQQCNhcz+
//9Q/3X06EFfAADpUf////919P8VJNFAADkd8DhJAHQcaOQ1SQBo3DNJAGjgNEkAaAIAAIDo
Ey8AAIPEEGpk/xUs0UAAi3X46dX+//+LwcNVi+xRUVNWV2oCWovxagQz/zl9EFm4AAAAgIva
iU34iX38iT6JfgSJfgh1CrgAAADAi9mJVfg5fQh0NVdqIGoDV2oBUP91CP8V/NBAAIP4/4kG
dF2NTfxRUP8V7NBAADl9/IlGDHUdi00MO890AokBV1dXU1f/Nv8VBNFAADvHiUYEdQr/Nv8V
JNFAAOsjV1dX/3X4UP8VCNFAADvHiUYIdRH/dgSLPSTRQAD/1/82/9czwF9eW8nCDABWi/FX
i0YIhcB0B1D/FfjQQACLRgSLPSTRQACFwHQDUP/XiwaFwHQDUP/XgyYAg2YEAINmCABfXsNT
Vot0JAwz21dT6GYvAACD4AFqB4mGHAkAAGomjYa4CAAAagpQ6MQeAACDxBQ4Heg2SQB0E42G
tAcAAGjoNkkAUOjJXgAAWVlW6I8BAAAPvoYsAQAAjb4sAQAAUOhgYQAAOJ6sAQAAWVmIB3UK
x4YcCQAAAQAAADiesAYAAI2+sAYAAHUfagH/tiAJAABo3AFBAOimGwAAWVlQU1fofykAAIPE
EF9eW8NVi+yD7BxTVo1F5FdQ/xXY0EAAM9u+5gZBAFNW6KQbAABZO8NZiUX0D44AAQAAvxjS
QAAzwIH/KNJAAA+dwEiLD4PgColN/IPABYlN+PfYUI1F/FDoMzIAAFlZZotN+GY5Tfx+CWaD
wQxmg0X6Hg+3ReYPv1X8O9B/HQ+/yTvBfxYPt0XqD79N/jvIfwoPv036QUE7wX4JQ4PHBDtd
9HyTO130D42FAAAAU1bo5RoAAGoAi9joFC4AAIvwi0UIg+YBVmhmB0EAjbgsAQAA6MMaAABQ
V+iOXQAAagDo7S0AAIPEIDPSagNZ9/GF0nQEhfZ0LmoA6NQtAABqBjPSWffxUmikA0EA6Ioa
AABQV+hlXQAAaDjwQABX6FpdAACDxBxTV+hQXQAAWVlqAVjrAjPAX15bycNVi+yB7AgMAABT
Vot1CI2F+Pf//1dQjYX48///M9tQjUZkUIld/Iid+PP//+hpIQAAjYasAQAAU4lF+GjcAUEA
iBiNhiwBAACInVz0//+Infj7//+JRQiIGIiesAYAAOgsGgAAU4v46CwtAAAz0lP394mWIAkA
AOgcLQAAg8QcqAN1D1boQv7//4XAWQ+FTQMAAFPoAC0AAFkz0moYWffxhdJ1LGi0DkEAiZ4c
CQAA/3UI6HtcAACBxsgAAABWaMoOQQD/dfjosGAAAOkMAwAAU+jCLAAAWTPSahhZ9/GF0g+F
pwAAAMdF/AEAAABT6KUsAABZM9JqA1n38YXSD4TxAQAAOV38D4XoAQAAv/IDQQBTV+h4GQAA
U4lF+Oh3LAAAM9L3dfhSV+gzGQAAU4v46GMsAACDxBgz0moDWffxhdIPhZ0BAABT6EssAABZ
M9JqCln38YXSD4UnAQAAV1PoNCwAAIPgAYPABFBoEANBAOjrGAAAg8QMUP91COj6XwAAV1bo
ZgYAAOlPAgAAU+gFLAAAqB9ZdQpoOPBAAOlDAQAAU+jwKwAAqAFZD4U8////OB3sN0kAD4Qw
////agFqMo2F+Pv//2oIv+w3SQBQV+hcHgAAg8QUhcAPhA3///9Tx4YcCQAAAQAAAOioKwAA
WTPSagqInfj3//9Z9/GNhfj7//9QO9N1L1PoiSsAAIPgAYPABFBoEANBAOhAGAAAg8QMUP91
COhPXwAAjYX4+///UOlK/////3UI6PJaAABT6FIrAACDxAyoPw+FjgEAAGoBaCADAACNhfj3
//9qCFBXiJ349///6MQdAACNhfj3//9Q/3X46LZaAACDxBzpWwEAAFPoDisAAIPgA1BoEANB
AOjIFwAAi3UIUFbokFoAAFPo8CoAAIPEGKgBdBuNhfjz//9QVuiGWgAAaDzwQABW6HtaAACD
xBAPvgdQ6N1dAABXVogH6GZaAACDxAzp+wAAAFf/dQjoRVoAAFlZ6esAAABT6J4qAABZM9Jq
BVn38Tld/Iv6dAIz/4sEvfDRQABTiUX8iwS9BNJAAIlF+OhzKgAAM9JZ93X4AVX8g/8EfWNT
6F8qAACoAVl1I4P/A3QeU+hPKgAAg+ABg8AIUGioBUEA6AYXAACDxAyL2OsFu6AxQQD/dfxo
pANBAOjtFgAAWVlQU1doVANBAOjeFgAAWVlQjYX4+///UOjqXQAAg8QQ6y3/dfxopANBAOi9
FgAAWVlQV2hUA0EA6K8WAABZWVCNhfj7//9Q6LtdAACDxAyNhfj7//9Q/3UI6GBZAAD/dfxX
VugIAAAAg8QUX15bycNVi+yB7GACAACDfQwEU1ZXD4SZAQAAM9tT6JYpAACoAVm+qAVBAHUg
g30MA3QaU+iAKQAAg+ABg8AIUFboOxYAAIPEDIv46wW/oDFBAP91EGikA0EA6CIWAABZWVBX
/3UMaFQDQQDoERYAAFlZUI2FaP7//1DoHV0AAFPoNCkAAIPgAYPAEFBW6O8VAACDxBxQU+gd
KQAAagMz0ln38YPCElJW6NQVAACDxAxQag9W6MgVAABZWVCNhTD///9Q6NRcAABT6OsoAACD
xBSoAXUmU+jeKAAAg+ABUGgQA0EA6JgVAABQi0UIBawBAABQ6FtYAACDxBSLRQhqDlaNuKwB
AACJfRDochUAAFBX6E1YAACNhWj+//9QV+hAWAAAg8QYOV0Mv3YHQQB1ZFf/dRDoKlgAAGgz
CUEA/3UQ6B1YAACLdQhTaHQNQQCJnhwJAACJniAJAADoURUAAFOJRfyBxrAGAADoSigAADPS
93X8Umh0DUEA6AIVAABQVujNVwAAaNwBQQBW6NJXAACDxDRX/3UQ6MZXAACNhTD///9Q/3UQ
6LdXAACDxBDpVgIAADPbU+j9JwAAg+ABvlgFQQCJRfyLRQhTVomYHAkAAImYIAkAAOjUFAAA
U4v46NQnAAAz0vf3UlbokRQAAIlF+FCNhWj+//9Q6FNXAABT6LMnAACDxCS+qAVBAKgBdAnH
RQygMUEA6xlT6JgnAACD4AGDwAhQVuhTFAAAg8QMiUUM/3UMagRW6EIUAABZWVCNhTD///9Q
6E5bAACNhTD///9QjYVo/v//UOgCVwAAi30QV2ikA0EA6BIUAACDxByJRRBQagRoVANBAOj/
EwAAWVlQjYUw////UOgLWwAAjYUw////UI2FaP7//1Dov1YAAP91EI2FMP///1DooFYAACs9
ANJAAIPHBldW6L4TAACDxCRQ/3UMagVW6K8TAABZWVCNhaD9//9Q6LtaAACNhaD9//9QjYUw
////UOhvVgAAi0UIg8QYOV38dC6NjWj+//8FrAEAAFFQ6EJWAACLRQi/dgdBAAWsAQAAV1Do
PlYAAI2FMP///+ssjY0w////BawBAABRUOgUVgAAi0UIv3YHQQAFrAEAAFdQ6BBWAACNhWj+
//9Qi0UIBawBAABQ6PtVAACLRQiDxBgFrAEAAFdQ6OlVAACLRQhXjbisAQAAV+jZVQAAag1W
6O8SAABQV+jKVQAAagpW6OASAABQV+i7VQAAagtW6NESAABQV+isVQAAg8RA/3X4V+igVQAA
agxW6LYSAABQV+iRVQAAi0UIU4mYHAkAAI2wsAYAAOjSJQAAg+ABUGh0DUEA6IwSAABQVuhX
VQAAaNwBQQBW6FxVAACDxDRfXlvJw4PsZFOLXCRsVVaNq8gAAABXjbOsAQAAVWioBUEAVuhq
WQAAv3YHQQBXVuglVQAAV1boHlUAAGiQBUEAVugTVQAAjUNkUFboCVUAAFdW6AJVAABqAWiQ
BUEA6BQSAABQVujvVAAAg8REVVbo5VQAAFdW6N5UAABqAmiQBUEA6PARAABQVujLVAAA/7Qk
nAAAAFbovlQAAFdW6LdUAABqAOgGJQAAg+ABv6gFQQBAUFfovhEAAFBW6JlUAACDxERqA1fo
rBEAAFBW6IdUAACNRCQgUI1DZGoAUOjPGAAAagFofQdBAOiJEQAAUFXoVFQAAI1EJDxQVehZ
VAAAg8Q0g6McCQAAAF9eXVuDxGTDVYvsgexoCAAAU1ZXi30MaJAFQQBX6B1UAACLXQiNhZj3
//9QjYWY+///jbPIAAAAUFboaBgAAI2FmPv//1ZQjYWY9///aCsNQQBQ6DBYAACNhZj3//9Q
V+jqUwAAvn0HQQBWV+jeUwAAagFokAVBAOjwEAAAUFfoy1MAAIPERI1DZFBX6L5TAABWV+i3
UwAAagJokAVBAOjJEAAAUFfopFMAAI2DLAEAAFBX6JdTAABWV+iQUwAAaJ0HQQBX6IVTAACN
g7gIAABQV4lFDOh1UwAAg8RAVlfoa1MAAFZX6GRTAABqB2oUjUWYaghQ6CQTAABqAf91DFfo
NQIAAIPELIO7HAkAAACLxnQejUWYUI2FmPf//2j7CEEAUOhgVwAAg8QMjYWY9///UI2FmPv/
/2jhB0EAUOhFVwAAjYWY+///UFfo/1IAAI2DrAEAAFBX6PJSAABoTwhBAFfo51IAAFZX6OBS
AABWV+jZUgAAagDoKCMAAIPEOIPgAYO7HAkAAACJRQh1B8dFCAIAAABqAf91DFfomQEAAIPE
DI1FmFCNg7AGAABQ/3UIaMEIQQDosQ8AAFlZUI2FmPv//2hnCEEAUOi4VgAAjYWY+///UFfo
clIAAFZX6GtSAABWV+hkUgAAjUX8agFQjYOsBQAAUOi6HAAAg8Q4iUUIhcB0ElBX6EFSAAD/
dQjoxFYAAIPEDFZX6C9SAACBw7QHAABZWYA7AA+E6wAAAFPozhgAAD0AyAAAWYlF/HIbPQDQ
BwAPg88AAABqAOhRIgAAqAFZD4S/AAAAjUX8agBQU+hOHAAAg8QMiUUIhcAPhKUAAABqAf91
DFfouAAAAGoB/3UMV+itAAAAjYWY+///UI2FmPf//1BqAGoAU+gFUwAAjYWY+///UI2FmPf/
/1Dol1EAAIPENI1FmFCNhZj3//9QagJowQhBAOibDgAAWVlQjYWY+///aGcIQQBQ6KJVAACN
hZj7//9QV+hcUQAAVlfoVVEAAFZX6E5RAAD/dQhX6EVRAABWV+g+UQAA/3UI6MFVAACDxEBq
AP91DFfoEwAAAGhA8EAAV+gdUQAAg8QUX15bycNVi+xoQPBAAP91COgFUQAA/3UM/3UI6PpQ
AACDxBCDfRAAdA9ofQdBAP91COjkUAAAWVldw1WL7IPsMFNWV/8V1NBAAIt9CDPbUFNo/w8f
AIld8MdF9DIAAACJXfiIXdiIXdmIXdqIXduIXdzGRd0FiV3oiV3siV38iV3kiR//FSDRQACN
TfCJReBRaghQ/xUg0EAAhcB1Dv8V4NBAAIlF/OkSAQAA/3X0U/8VlNBAADvDiUX4dOGNTfRR
/3X0UGoC/3Xw/xUw0EAAizXg0EAAhcB1OP/Wg/h6dWv/dfj/FdzQQAD/dfRT/xWU0EAAO8OJ
Rfh0UY1N9FH/dfRQagL/dfD/FTDQQACFwHQ6jUXoUFNTU1NTU1NqBI1F2GoBUP8VKNBAAIXA
dB2NRexQU1NTU1NTU2oGjUXYagFQ/xUo0EAAhcB1B//W6VH///+LdfiJXQg5HnZSg8YE/3Xo
iwaLTgSJRdBQiU3U/xUs0EAAhcB1Iv917P910P8VLNBAAIXAdR3/RQiLRfiLTQiDxgg7CHLH
6xTHReQBAAAAiR/rCccHAQAAAIld5DkfdQs5XeR1BscHAQAAADld7Is1PNBAAHQF/3Xs/9Y5
Xeh0Bf916P/WOV34dAn/dfj/FdzQQAA5XfCLNSTRQAB0Bf918P/WOV3gdAX/deD/1otF/F9e
W8nDVYvsuOAtAADoBlcAAFMz2zldEFZXx0X8IAAAAIideP///3QT/3UQjYV4////UOjQTgAA
WVnrFWoHagqNhXj///9qBVDomQ4AAIPEEDldGHQF/3UY6wVo5DVJAI2FePr//1DonE4AAIt1
CFlZjYV0/v//VlDoik4AAP91DI2FdP7//1Doi04AAIPEEDldFHQT/3UUjYVw/f//UOhkTgAA
WVnrImoBaNwBQQDoQ1YAAGoCmVn3+Y2FcP3//1JQ6FIZAACDxBA5HfA4SQB0HmoBU+gdVgAA
agKZWff5jYVw/f//UlDoLBkAAIPEEI2FdP7//1Do/E4AAIC8BXP+//9cjYQFc/7//1l1AogY
gL1w/f//XHQTjYV0/v//aETwQABQ6O5NAABZWY2FcP3//1CNhXT+//9Q6NlNAABZjYV0/v//
WVNQjYV4+v//UP8VfNBAAIXAD4RlAQAA6JRVAABqBZlZ9/mF0nQi6IVVAACZuQAoAAD3+Y2F
dP7//4HCgFABAFJQ6JkWAABZWWh6IgAAjYUg0v//aMDwQABQ6BNSAACNhSDS//+InTTi//9Q
jYV0/v//UOj/LAAAjYV0/v//UOgQKwAAg8QYOR3wOEkAD4XqAAAAjUX8UI1F3FD/FWTQQACN
RdxQjUYCUOjkngAAWYXAWQ+ExQAAAGoCU1aLNQDQQAD/1ov4O/t1CTldHA+EqgAAAFNTU1ON
hXT+//9TUFNqA2gQAQAAjYV4////U1CNhXj///9QV/8VSNBAAFeLPUDQQAD/12oBU/91CP/W
i/CNhXj///9qEFBW/xU40EAAU1NQiUUQ/xUk0EAA/3UQiUUY/9dW/9c5XRgPhWUBAAC6gQAA
ADPAi8qNvab2//9miZ2k9v//ZomdnPT///OrZquLyjPAjb2e9P//OR0EOUkA86uJXRCJXRhm
q3UHM8DpJAEAAItFDIA4XHUHx0UYAQAAAL8EAQAAjYWk9v//V4s1eNBAAFBq//91CGoBU//W
i00MjYWc9P//V1CLRRhq/wPBUGoBU//WjUUQUI2FnPT//2oCUI2FpPb//1D/FQQ5SQCFwA+F
uwAAAFNTjYV8+///V1CLRRBq/4idfPv///9wGFNT/xWg0EAAjUUUUGgCAACA/3UI/xUc0EAA
hcB1d42FrPj//2oDUOgnEQAAjYV8+///aETwQABQ6JNLAACNhXD9//9QjYV8+///UOiASwAA
jYV0+f//U1BTjYV8+///U1CInXT5///ov0wAAI2FfPv//1CNhXT5//9QjYWs+P//UP91FOgy
GgAAg8Q8/3UU/xVc0EAAoQw5SQA7w3QF/3UQ/9BqAVhfXlvJw1WL7ItFFFNWi/FXM9v/dQiJ
RhiNRhyJHlCJXgzo9EoAAIt9EGaLRQxXZomGnAEAAGbHhp4BAAAZAOgWUwAAg8QMO8OJRgR1
DMeGpAEAAAIAAIDrY1fo+lIAADvDWYlGEHTmV1P/dgSJfgiJfhToQ0oAAFdT/3YQ6DlKAACD
xBiNjqABAACJnqQBAACJnqgBAABqAWoB/3UMiZ6sAQAAiJ4cAQAA6D4FAACFwHUOx4akAQAA
BQAAgDPA6xA5Xgx0CDkedARqAesCagJYX15bXcIQAFaL8VeLRgSFwHQHUOjNTgAAWYtGEIXA
dAdQ6L9OAABZjb6gAQAAagBqBmhI8EAAi8/ojAUAAIvP6MEFAACFwHT1g/gBdRBo3QAAAIvO
6NUCAACL8OsDagFei8/okAUAAIvGX17DVovxV2aLhpwBAACNvqABAABQjUYcUIvP6N0EAACF
wHUNuAEAAICJhqQBAADrK4vP6GQFAACFwHT1g/gBdQ5o3AAAAIvO6HgCAADrDWoBx4akAQAA
AwAAgFhfXsNVi+yB7AQBAABTVovxV42GHAEAAFCNhfz+//9oYPBAAFDopU0AAIPEDI2F/P7/
/42+oAEAAGoAUOg1SgAAWVCNhfz+//9Qi8/otAQAAIvP6OkEAACFwHT1g/gBD4WdAAAAu/oA
AACLzlPo+AEAAIXAD4WVAAAAi87olQAAAIXAD4WGAAAAIUX8OQaLfgR2IVeLzug1AQAAhcB1
cFfo0UkAAP9F/I18BwGLRfxZOwZy32oAjb6gAQAAagdoWPBAAIvP6DsEAABoYgEAAIvO6JQB
AACFwHU1UIvP/3UM/3UI6B0EAABqAGoFaFDwQACLz+gNBAAAU4vO6GoBAADrDWoBx4akAQAA
AwAAgFhfXlvJwggAU1aL8YtGFIPAZFDon1AAAIvYWYXbdQhqAljpmAAAAFVXaHDwQABT6ERI
AACLfhAz7TluDFlZdiVXU+hBSAAAaDjwQABT6DZIAABX6BBJAACDxBRFO24MjXwHAXLbaGzw
QABT6BhIAABZjb6gAQAAWWoAU+joSAAAWVBTi8/obQMAAIvP6KIDAACL6IXtdPNT6HZMAABZ
agFYXzvoXXUOaPoAAACLzuipAAAA6wrHhqQBAAADAACAXlvDU1b/dCQMi9nomUgAAIPAZFDo
308AAIvwWYX2WXUFagJY63JVV2iA8EAAVuiGRwAA/3QkHFbojEcAAGhs8EAAVuiBRwAAg8QY
jbugAQAAagBW6FBIAABZUFaLz+jVAgAAi8/oCgMAAIvohe1081bo3ksAAFlqAVhfO+hddQ5o
+gAAAIvL6BEAAADrCseDpAEAAAMAAIBeW8IEAFWL7IHsBAQAAFaL8VdqAI2+oAEAAI2F/Pv/
/2gABAAAUIvP6IoCAACLz+ioAgAAhcB09YP4AXVAjUX8UI2F/Pv//2iM8EAAUOgcTwAAi0UI
i038g8QMO8F0GseGpAEAAAQAAICJjqgBAACJhqwBAABqAusQM8DrDceGpAEAAAMAAIBqAVhf
XsnCBAD/dCQEgcEcAQAAUeiBRgAAWVnCBABVi+xRU1ZXi/H/dQiLfhDoWEcAAINl/ACDfgwA
WYvYdhZX6EVHAAD/RfyNfAcBi0X8WTtGDHLqK14Qi0YUA9872HZOi04YA8FQiUYU6GpOAACL
2FmF23UMx4akAQAAAgAAgOs+/3YUagBT6K1FAACLRhCLzyvIUVBT6I5OAACLRhBQK/jojkoA
AIPEHIleEAP7/3UIV+jiRQAA/0YMi0YMWVlfXlvJwgQAVYvsUVNWV4vx/3UIi34E6K9GAACD
ZfwAgz4AWYvYdhVX6J1GAAD/RfyNfAcBi0X8WTsGcusrXgSLRggD3zvYdk6LThgDwVCJRgjo
w00AAIvYWYXbdQzHhqQBAAACAACA6zz/dghqAFPoBkUAAItGBIvPK8hRUFPo500AAItGBFAr
+OjnSQAAg8QciV4EA/v/dQhX6DtFAAD/BosGWVlfXlvJwgQAVYvsgeyQAQAAU1ZqAY2FcP7/
/1uL8VBqAv8V4NFAAA+/RQxISHUDagJbD7/DagZQagL/FeTRQAAzyYP4/4kGXg+VwYvBW8nC
DABVi+yD7BBWi/H/dQz/FdTRQABmiUXyjUUMUIvO/3UIZsdF8AIA6HkAAACLRQxqEIhF9IpF
DohF9opFD4hl9YhF941F8FD/Nv8V2NFAAIXAXnQK/xXc0UAAM8DrA2oBWMnCCAD/dCQM/3Qk
DP90JAz/Mf8V0NFAAMIMAP90JAz/dCQM/3QkDP8x/xXM0UAAwgwA/zH/FcTRQAD/JcjRQABq
AVjDVYvsUVFTVleLfQhqATP2W4lN+FeJdfzoFUUAAIXAWX4sigQ+PC51Bf9F/OsKPDB8BDw5
fgIz21dG6PNEAAA78Fl83oXbdBiDffwDdAQzwOs6/3UMi034V+g1AAAA6ylX/xXA0UAAi/D/
FdzRQACF9nQWM8CLTgyLVQyLCYoMAYgMEECD+AR87GoBWF9eW8nCCABVi+xRU4tdCFYz9leJ
dfyNRQiNPB5QaIzwQABX6NtLAACLVQyLRfyKTQiDxAyD+AOIDBB0F0aAPy50CIoEHkY8LnX4
/0X8g338BHzDX15bycIIAFWL7FFTVlf/dQzoPUQAAIt1CItdEFmJRfxW6C1EAACL+FmF/3Qt
hdt0CYvGK0UIO8N9IIN9FAB0D/91DFbo6pQAAFmFwFl0Bo10PgHry4PI/+syi038i8YrRQiN
RAgCO8N+CIXbdAQzwOsa/3UMVujoQgAAVujSQwAAg8QMgGQwAQBqAVhfXlvJw1aLdCQIVzP/
OXwkEH4dVuiuQwAAhcBZdBJW6KNDAABHWTt8JBCNdAYBfOOLxl9ew1aLdCQIVzP/VuiEQwAA
hcBZdBqDfCQQAHQMi84rTCQMO0wkEH0HjXQGAUfr24vHX17DVYvsUVOLXQhWi3UMV2oAU4l1
/Oi2////i/hZhf9ZfwczwOmVAAAAhfZ9D2oA6KQSAAAz0ln394lV/I1HAlBT6Fr///+L8Cvz
0eZW6F9KAABWM/ZWUIlFDOizQQAAg8QYhf9+JDt1/HQaagH/dRBWU+gp////WVlQ/3UM6JT+
//+DxBBGO/d83DP2Tzv+iTN+H2oB/3UQVv91DOj//v//WVlQU+hs/v//g8QQRjv3fOH/dQzo
U0YAAFlqAVhfXlvJw1ZXM/+L92oA994b9oHm+AAAAIPGCOj7EQAAM9JZ9/aLRCQMA8eE0ogQ
dQPGAAFHg/8EfNBfXsNVi+yD7AyLRRCDZfgAg30MAFOKCIpAAVZXiE3+iEX/fjOLRQiLTfgD
wYlF9IoAiEUTYIpFE4pN/tLAMkX/iEUTYYtN9IpFE/9F+IgBi0X4O0UMfM1qAVhfXlvJw1WL
7IPsDItFEINl+ACDfQwAU4oIikABVleITf6IRf9+M4tFCItN+APBiUX0igCIRRNgikUTik3+
MkX/0siIRRNhi030ikUT/0X4iAGLRfg7RQx8zWoBWF9eW8nDU1ZXM/9X6BsRAABZM9JqGotc
JBRZ9/GL8oPGYYP7BHR4g/sBdRVX6PoQAABZM9JqCln38YvCg8Aw62D2wwJ0E1fo4BAAAFkz
0moaWffxi/KDxkFX6M0QAACoAVl0GPbDBHQTV+i9EAAAWTPSahpZ9/GL8oPGYVfoqhAAAKgB
WXQY9sMBdBNX6JoQAABZM9JqCln38Yvyg8Ywi8ZfXlvDU4tcJAxWV4t8JBiL8zv7fhJqAOhv
EAAAK/sz0vf3WYvyA/OLXCQQM/+F9n4S/3QkHOgr////iAQfRzv+WXzuagLoG////1mIA4Ak
HwBqAVhfXlvDVle/kPBAADP2V+iuQAAAhcBZfhiKRCQMOoaQ8EAAdBFXRuiWQAAAO/BZfOgz
wF9ew2oBWOv4U4pcJAhWV4TbfD8PvvNW6EhLAACFwFl1NVboa0sAAIXAWXUqv5jwQAAz9lfo
VkAAAIXAWX4UOp6Y8EAAdBBXRuhCQAAAO/BZfOwzwOsDagFYX15bw1aLdCQIigZQ/xVo0EAA
hcB0C4B+AYB2BWoBWF7DM8Bew4tEJASKADyhdAc8o3QDM8DDagFYw1WL7IHs/AcAAItFHFNW
V4t9DDP2iXX8gCcAOXUQiTB/CYtFCEDp3AEAAItdCIoDUOhA////hcBZdVCJXQyDfSAAdCv/
dQzof////4XAWXQN/3UM6JP///+FwFl0Lf91DOiG////hcBZdARG/0UMi0UQRv9FDEg78H0Q
i0UMigBQ6PD+//+FwFl0s4tFEEg78IlFDA+NagEAAIoEHlDo0/7//4XAWQ+EvgAAAIoEHlDo
i/7//4XAWXULRjt1DHzs6T8BAACKBB5Q6Kj+//+FwFl0G4tN/IoEHv9F/EY7dQyIBDl9CYtF
GEg5Rfx814tFGEg5Rfx8HIN9/AB0FotF/IoEOFDoN/7//4XAWXUF/038deqLRfyFwHwEgCQ4
ADPbOB90FYoEO1DoE/7//4XAWXQHQ4A8OwB1640EO1CNhQT4//9Q6MQ9AACNhQT4//9QV+i3
PQAAi0X8g8QQK8M7RRQPjYQAAACLXQiDfSAAD4SKAAAAi0UIgCcAA8Yz21DoR/7//4XAWXRZ
i0UQg8D+iUUgi0UIA8aJRRD/dRDoSv7//4XAWXUZi0UQigiIDDuKSAFDRkCIDDtDRkCJRRDr
BkZGg0UQAjt1IH0Xi0UYg8D+O9h9Df91EOju/f//hcBZdbiAJDsAO10UfBCLRRzHAAEAAACL
RQgDxusMi10Ii0UcgyAAjQQeX15bycNVi+y4HBAAAOgERQAAU1ZXjU3k6OTc//+LfQyNRfhq
AVD/dQgz241N5Igf6M/c//+L8DvzD4QrAQAAi1X4g/oKD4IXAQAAiJ3k7///iV38/3UYjU38
Uf91FP91EFJXUOiR/f//i034g8Qci9Er0APWg/oFD47iAAAAOV38dNGJXQgz//91GI1V/CvI
UgPO/3UU/3UQUY2N5O///1FQ6FP9//+DxBw5Xfx0A/9FCItN+IvRK9AD1oP6BXYJR4H/ECcA
AHy/OV0IdBFT6JgMAAAz0ln394tN+IlVCIv+iV30/3UYjUX8K89QA87/dRSNheTv////dRBR
UFfo9/z//4PEHDld/Iv4dBk5XQh0Lv9NCI2F5O///1D/dQzo4jsAAFlZi034i8ErxwPGg/gF
dgz/RfSBffQQJwAAfKSNTeTodtz///91DOimPAAAWTPJO0UQD53Bi8FfXlvJw4gfjU3k6FTc
//8zwOvtVYvsi1UMUzPbVoXSdAIgGotFEIXAdAOAIACLdQiAPkB0HFeL+ovGK/6KCITJdA6F
0nQDiAwHQ0CAOEB17F+F0nQEgCQTAIA8MwCNBDNeW3UEM8Bdw4N9EAB0C1D/dRDoNDsAAFlZ
agFYXcNVi+xRU4pdCFZXvqTwQACNffxmpYD7IKR+NID7fn0vD77zVujKRgAAhcBZdShW6O1G
AACFwFl1HYD7QHQYgPsudBM6XAX8dA1Ag/gCfPQzwF9eW8nDagFY6/b/dCQE6J3///9Zw1WL
7LgAIAAA6MtCAAD/dQiNhQDg//9Q6Kw6AAD/dQyNhQDw//9Q6J06AACNhQDg//9Q6O2MAACN
hQDw//9Q6OGMAACNhQDw//9QjYUA4P//UOjCRgAAg8QgycNWvlICQQBW/3QkDOhdOgAA/3Qk
FFbogff//1D/dCQc6Fk6AACDxBhew1OLXCQIVldT6Cc7AACL+FmD/wR8JIP/DH8fM/aF/34U
D74EHlDoDUYAAIXAWXQKRjv3fOxqAVjrAjPAX15bw1WL7IHsBAEAAFNWV42F/P7//zP/UFdX
V/91COhQOwAAvvwBQQBXVug39///i9iDxBw7334gV1bo9/b//1CNhfz+//9Q6IyLAACDxBCF
wHQnRzv7fOCNhfz+//9owg1BAFDob4sAAPfYG8BZg+BjWYPAnF9eW8nDi8fr91WL7FYz9ldW
aiBqAlZqA2gAAADA/3UI/xX80EAAi/iJdQiD//90Izl1DHQejUUIVlD/dRD/dQxX/xVs0EAA
V/8VJNFAAGoBWOsCM8BfXl3DVYvsU1dqAGonagNqAGoDaAAAAID/dQj/FfzQQACDZQgAi/iD
y/87+3QdjUUIUFf/FezQQACDfQgAi9h0A4PL/1f/FSTRQACLw19bXcNVi+yD7BSNTezo2tj/
/41F/GoBUI1N7P91COjM2P//hcB0DY1N7Oh62f//agFYycMzwMnDVYvsgewYAQAAVmoEagWN
RexqAlDof/j//4PEEI2F6P7//1BoBAEAAP8VmNBAAIt1CI1F7FZqAFCNhej+//9Q/xV00EAA
VugjAAAAVuhYOQAAWVlIeAaAPDAudfcDxmjcAUEAUOhQOAAAWVleycNqIP90JAj/FYDQQAD/
dCQE/xWc0EAAw1WL7IHsSAMAAFZX/3UIjYX4/f//M/ZQ6Bg4AACNhfj9//9Q6Pw4AACDxAyF
wHQXgLwF9/3//1yNhAX3/f//dQaAIABqAV6Nhfj9//9osPBAAFDo7TcAAFmNhbj8//9ZUI2F
+P3//1D/FYzQQACL+IP//w+E1AAAAP91CI2F/P7//1DorTcAAFmF9ll1E42F/P7//2hE8EAA
UOimNwAAWVmNheT8//9QjYX8/v//UOiRNwAA9oW4/P//EFlZdFuNheT8//9orPBAAFDodTYA
AFmFwFl0Wo2F5Pz//2io8EAAUOheNgAAWYXAWXRD/3UQjYX8/v//agFQ/1UMg8QMhcB0Lf91
EI2F/P7///91DFDo7P7//4PEDOsW/3UQjYX8/v//agBQ/1UMg8QMhcB0Fo2FuPz//1BX/xWI
0EAAhcAPhTP///9X/xWE0EAAXzPAXsnDVYvsUYF9DABQAQBTVld8Kmog/3UI/xWA0EAAM9tT
aiBqA1NqA2gAAADA/3UI/xX80EAAi/iD//91BzPA6YQAAACNRfxQV/8V7NBAAIvwO3UMfhVT
U/91DFf/FeTQQABX/xWQ0EAA61NqAlNTV/8V5NBAAItFDCvGvgAACACJRQiLzpn3+TvDix1s
0EAAfheJRQyNRfxqAFBWaNAxQQBX/9P/TQx17I1F/GoAUItFCJn3/lJo0DFBAFf/01f/FSTR
QABqAVhfXlvJw1ZqAGonagNqAGoDaAAAAID/dCQg/xX80EAAi/CD/v91BDPAXsOLRCQMV41I
EFGNSAhRUFb/FejQQABWi/j/FSTRQACLx19ew1ZqAGonagNqAGoDaAAAAMD/dCQg/xX80EAA
i/CD/v91BDPAXsOLRCQMV41IEFGNSAhRUFb/FTDRQABWi/j/FSTRQACLx19ew1WL7IPsFFON
TezodNX//41F/GoBUI1N7P91COhm1f//i9iF23Rwg30QAHQmgX38AJABAHYdagDosgUAAFkz
0moKWffxg8JUweIKO1X8cwOJVfyLRfxWA8BQ6Gk9AACL8FmF9nQmi0X8A8BQagBW6LU0AABq
SP91/FZT6LnN//+LTQyDxByFyXQCiQGNTezordX//4vGXlvJw1WL7IHsBAEAAFNWV4t9CDPb
ahRTV4id/P7//+hvNAAAg8QMOB3sN0kAdD5T6CQFAABZM9JqA1n38YXSdCxqAWoKjYX8/v//
UVBo7DdJAOib9///g8QUhcB0D42F/P7//1BX6Ig0AABZWTgfD4WLAAAAOB3oNkkAdDZT6NYE
AABZM9JqA1n38YXSdCSNhfz+//9TUFNTaOg2SQDouzUAAI2F/P7//1BX6EM0AACDxBw4H3VJ
U+icBAAAqA9ZdSu+dA1BAFNW6IPx//9TiUUI6IIEAAAz0vd1CFJW6D7x//9QV+gJNAAAg8Qc
OB91D2oEagZqAlfo1fP//4PEEDldDHQrvvwBQQBTVuhA8f//U4lFCOg/BAAAM9L3dQhSVuj7
8P//UFfo1jMAAIPEHDldEHQN/3UQV+jFMwAAWVnrMDldFHQrvtwBQQBTVuj+8P//U4lFCOj9
AwAAM9L3dQhSVui58P//UFfolDMAAIPEHF9eW8nDVYvsg+wUU4tFGFZX/3UUM9uDz/+JXfxT
iX34/3UQiV3wiV30iRjo8TIAAIt1CIoGUOgZ+P//g8QQhcAPhIwAAACKBlDoBvj//4XAWXRc
i0UMi95IiUUIi0UQK8aJRezrA4tF7IoLiAwYigM8QHUJi03w/0X0iU34PC51B4X/fQOLffD/
RfxDi0X8/0XwO0UIfRaLRRRIOUXwfQ2KA1DorPf//4XAWXW5M9uLRfCLTRArffiAJAgAg/8D
fhFqAVg5Rfh+CTlF9A+EoAAAAINN+P+DTfD/iV38ZoseM/9TIX306MP3//+FwFkPhIoAAABT
6LT3//+FwFl0VItFDEghfQyJRQiLRRCA+0CIHAd1Bv9F9Il9+ID7LnUJg33wAH0DiX3wg0UM
BINF/AKLRQxHO0UIfRqLRRRIO/h9EotF/GaLHDBT6GD3//+FwFl1totFEIAkBwCLRfArRfiD
+AJ+EmoBWDlF+H4KOUX0dQWLTRiJAYtF/APG6wONRgFfXlvJw1WL7IHsGAQAAFMz21aNTeiJ
Xfzo3tH//41F+GoBUI1N6P91COjQ0f//i/A783UEM8DrY1eL/otF+IvPK86NUP87yn1HjU38
K8dRjY3o+///aAAEAACNRDD/UVBX6B7+//+DxBSDffwAi/h0yv91FI2F6Pv///91EFD/dQzo
Hu7//4PEEIXAfq5D66uNTejoINL//4vDX15bycNVi+xRUYtFGINN+P9QagD/dRSJRfzo5zAA
AIPEDI1FGFD/dQz/dQj/FUzQQACFwHQFagFYycONRfxQjUX4/3UUUGoA/3UQ/3UY/xUU0EAA
/3UY/xVc0EAAM8DJw1WL7I1FDFD/dQz/dQj/FRjQQACFwHQFagFYXcP/dRTo0TEAAFlQ/3UU
agFqAP91EP91DP8VENBAAP91DP8VXNBAADPAXcNVi+yB7AwBAACNRfxWUDP2/3UM/3UI/xVM
0EAAhcB0BDPA61eNhfT+//9oBAEAAFBW/3X8/xVQ0EAAhcB1LzlFEHQjIUX4/3UUjUX4UI2F
9P7//1D/dQz/dQj/VRCDxBSDffgAdQNG67uL8OsDagFe/3X8/xVc0EAAi8ZeycNVi+yB7BQI
AABTjUX8VlD/dQy+AAQAADPbiXXw/3UIiXX4/xVM0EAAhcB0BDPA63ONRfiJdfBQjYXs9///
UI1F7FCNRfBqAFCNhez7//+JdfhQU/91/P8VRNBAAIXAdTWDfewBdSg5RRB0IyFF9P91FI1F
9FCNhez7//9Q/3UM/3UI/1UQg8QUg330AHUDQ+ufi/DrA2oBXv91/P8VXNBAAIvGXlvJw4N8
JAQAdQmDPcwxQQAAdRf/FTTRQABQ6GM3AABZ6Gc3AACjzDFBAOldNwAAVYvsg+xUVjP2akSN
RaxWUOj5LgAAg8QMjUXwx0WsRAAAAFCNRaxQVlZWVlZW/3UM/3UI/xWk0EAA99gbwF4jRfDJ
w1WL7IPsHFNWjU3k6BbP//+DZfgAvsDwQABW6PwvAABZiUX0jUX8agFQjU3k/3UI6PXO//+L
2IXbdFOLTfxXgfkAoAAAcju4ABAAAIHBGPz//zvIi/h2Kv919I0EH1BW6Jc7AACDxAyFwHQP
i0X8RwUY/P//O/hy3+sHx0X4AQAAAI1N5Ohaz///i0X4X15bycNVi+yB7AAEAABojQdBAP91
EOi88///WYXAWXRzjYUA/P//aAAEAABQgKUA/P//AP91EP91DP91COj8/P//jYUA/P//UOgm
////g8QYhcB0P4tNGGoBWP91DIkBi00UaOA0SQCJAegwLgAAjYUA/P//UGjkNUkA6B8uAAD/
dRBo3DNJAOgSLgAAg8QYM8DJw2oBWMnDVYvsgewACAAA/3UMjYUA/P//UOjuLQAAjYUA/P//
aETwQABQ6O0tAAD/dRCNhQD8//9Q6N4tAACNhQD8//9ojQdBAFDo9fL//4PEIIXAdHmNhQD4
//+ApQD4//8AaAAEAABQjYUA/P//aJMHQQBQ/3UI6C78//+NhQD4//9Q6Fj+//+DxBiFwHQ/
i00YagFY/3UMiQGLTRRo4DRJAIkB6GItAACNhQD4//9QaOQ1SQDoUS0AAP91EGjcM0kA6EQt
AACDxBgzwMnDagFYycNVi+yB7BwFAACDZfwAgz3wOEkAAHUlagRoUgJBAOhE6v//jU38UWhK
SUAAUGgCAACA6EP8//+DxBjrPI2F6Pv//2oCUOiC8v//jYXo+///UGjgNEkA6N4sAACNRfxQ
jYXo+///aLZIQABQaAIAAIDog/z//4PEIItF/IXAo/Q4SQAPhdEAAABWjYXk+v//aAQBAABQ
/xWo0EAAM/aAZegAjUXoaI0HQQBQ6IosAABZjUXoWWoEagRqAlDoaS0AAFmNRAXoUOhN7P//
jUXpUOjBfgAAjYXk+v//UI2F6Pv//1DoUiwAAI2F6Pv//2hE8EAAUOhRLAAAjUXoUI2F6Pv/
/1DoQSwAAI2F6Pv//2jcAUEAUOgwLAAAjYXo+///UOgn8///g8Q4hcB0CkaD/goPjGf///+N
RehQaNwzSQDoBSwAAI2F6Pv//1Bo5DVJAOjkKwAAg8QQXmoBWMnDi0QkBGaLTCQIZgFIAmaL
SAJmg/kBfQ5mg0ACHmaLSAJm/wjr7GaDeAIffhJmg0AC4maLSAJm/wBmg/kff+5miwhmg/kB
fQaDwQxmiQhmiwhmg/kMfgaDwfRmiQjDi0QkDFaLdCQIV4t8JBCAJwCAIACAPlx1WIB+AVx1
UlNouPBAAFfoUysAAFmNRgJZighqAoD5XFp0F4vfK96EyXQPighCiAwDikgBQID5XHXtgCQ6
AAPWW4A6AHUEagLrElL/dCQY6BMrAABZM8BZ6wNqAVhfXsNVi+yB7BAEAABWjYX0/P//aOQ1
SQBQ6OwqAABZjYX8/v//WTP2aAQBAABQVv8VFNFAAFaNhfD7//9WUI2F9Pz//1ZQ6CosAABW
jYX4/f//VlCNhfz+//9WUOgULAAAjYX4/f//UI2F8Pv//1DoZnwAAIPEMPfYG8BeQMnDVot0
JAyD/kRyMYtMJAiAOU11KIB5AVp1Ig+3QTwDwYPG/IvQK9E71ncRiwBeLVBFAAD32BvA99Aj
wsMzwF7DVYvsU4tdEFaLdQhXU1borv///1mFwFl0UI0MMIt1DItRdI1BdDvWckAPt0kGi3Tw
/IPABDP/hcmNRNAIdiuDw/yJXRCL0CtVCDtVEHMbi1AEixgD2jvedgQ71nYIg8AoRzv5ct87
+XICM8BfXltdw1WL7FNWi3UMV4t9CI1GEIlFDIvGK8eDwBA7RRgPh4AAAAAPt0YOD7dODINl
CAADwYXAfmaLXRSLRQyLTRgrx4PACDvBd1SLRQyLQASpAAAAgHQcUVP/dRAl////fwPHUFfo
mv///4PEFIXAdDXrFYvTA8crVRABEIsAO8NyJAPLO8FzHg+3Rg4Pt04Mg0UMCP9FCAPBOUUI
fJ1qAVhfXltdwzPA6/dVi+yD7DxWjU3U6CLJ//+NTcToGsn//41F/GoBUDP2/3UMjU3EiXX4
iXX8iXX0iXXw6P7I//87xolFDHUHM8DpZAEAAItF/ItNEFONhAgAEAAAUP91COj58f//WY1F
+FlWUP91CI1N1OjHyP//i9g73old7A+E/gAAAFf/dfhqA1PoZP7//4v4g8QMO/4PhNoAAAD/
dfxqA/91DOhK/v//i/CDxAyF9g+EwAAAAP91/P91DOjz/f///3X4iUUQU+jn/f//i00Qi1UM
A8qDxBBmg3lcAg+FkwAAAIuJjAAAAAPYiU0QiYuMAAAAi0YIi08MiUcIiwaJB4tHCAPBiUXw
i0YEiUXki0cEiUXoi0YIi3YMA/KLVeyNPBGLyCtNDAPOO038d0dQVlfouCwAAP91EP916P91
5FdX6Bz+//8Pt0sUiUX0i9MPt0MGA9GDxCCNBICNTML4i0TC/AMBZqn/D3QHwegMQMHgDIlD
UI1N1Oh5yP//M/ZfjU3E6G7I//85dfRbdB+LRfA7RfxzA4tF/FD/dQjouvD///91COhMAQAA
g8QMi0X0XsnDVYvsg+wUU1aNTezodsf//zP2jUX8VlD/dQiNTezoZ8f//4vYO951BzPA6b0A
AABX/3X8U+jH/P//i/hZhf9ZD4SBAAAA/3X8agNT6O/8//+DxAyFwHRvahCNNB9aiZaMAAAA
i0gEA8qJEGb3wf8PiVAIdAfB6QxBweEMiU5Qi0gMi3gIA/k7fQxzA4t9DGb3x/8PdAfB7wxH
wecMjQQZi8gryztN/HMMUmoAUOh6JgAAg8QMi4bsAAAAhcB0A4lGKGoBXusDi30IjU3s6HLH
//+F9nQLV/91COjL7///WVn/dQjoWwAAAFmLxl9eW8nDVYvsUYtFDDPJ0eiJTfx0KYtVCFaL
8A+3AgPIiU0Ii0UIwegQiUUIgeH//wAAA00IQkJOdeGJTfxeiU0Ii0UIwegQi1X8ZgPCiUUI
i0UIA0UMycNVi+yD7BRWV41N7Ogzxv//g2X8ADP2jUX8VlCNTez/dQjoIMb//4v4hf90O/91
/FfoiPv//1mFwFl0IoN8OFgAjXQ4WHQSgyYA/3X8V+hb////WYkGWesDi0UIi/CNTezom8b/
/4vGX17Jw1WL7IHsAAgAAIM98DhJAAB1NYM9EDlJAAB0LI2FAPj//2jIAAAAUGr//3UIagFq
AP8VeNBAAI2FAPj//1BqAP8VEDlJAMnDM8DJw1WL7IPsDFNWV4tFCIlF+ItFDIlF9It1+It9
9FFSUzPJSYvRM8Az26wywYrNiuqK1rYIZtHrZtHYcwlmNSCDZoHzuO3+znXrM8gz00911ffS
99Fbi8LBwBBmi8FaWYlF/ItF/F9eW8nDVYvsgexQAQAAU1ZXagNfjU3Q6A7F////dRDo+yUA
AIvwWY1F6IPGIFD/FdjQQABmgWXq/v8z21PoU/X//1kz0moeWffxZilV8maDffI8cgZmx0Xy
AQCKRfKLTfCD4D/B4QYLwYpN9NDpweAFg+EfC8GKTf5miUX8i0Xog8BEg+EfweAJM8GKTeqD
4Q9mJR/+weEFC8GKTe5miUX+Mk3+g+EfZjPBOV0UZolF/nQDagJfaiD/dQj/FYDQQABTaiBX
U2oDaAAAAMD/dQj/FfzQQACL+IP//4l9+HQqagJTU1f/FeTQQACNReRqAVCNTdD/dQzoMcT/
/zvDiUUMdQ5X/xUk0UAAM8Dp8wAAAItF5MaFsv7//3RQZseFs/7//wCA/3UMZom1tf7//4mF
t/7//4mFu/7//4idv/7//+hX/v///3UQiYXA/v//i0X8xoXI/v//FImFxP7//8aFyf7//zDo
tCQAAP91EGaJhcr+//+NhdD+//+Jncz+//9Q6KgjAAAPt/6NR/5QjYWy/v//UOgD/v//izVs
0EAAg8QcOV0UZomFsP7//3QRjUXgU1BqFGisDUEA/3X4/9aNReBTUI2FsP7//1dQ/3X4/9aN
ReBTUP915P91DP91+P/WjU3Q6P3D////dfj/FSTRQAA5XRR0Cf91COgBAQAAWWoBWF9eW8nD
VYvsUYsNFDlJAINl/ABqAYXJWHQIjUX8agBQ/9HJw1WL7IHsYAYAAItFCFMz28dF8EAGAAA7
w4ld/HUG/xWs0EAAjU0IUWooUP8VINBAAIXAD4SeAAAAVo1F9FdQ/3UMU/8VCNBAAIXAdHyL
RfSLNQzQQACJReSLRfiJReiNRfBQjYWg+f//UI1F4GoQUFOJXeD/dQiJXez/1os94NBAAP/X
hcB1QYtF9IONrPn//wKJhaT5//+LRfiJhaj5//9TU42FoPn//2oQUFPHhaD5//8BAAAA/3UI
/9b/14XAdQfHRfwBAAAA/3UI/xUk0UAAi0X8X15bycNVi+yD7BhWM/ZXVmogagNWagFoAAAA
wP91CP8V/NBAAIv4O/4PhK4AAACNRehQ/xW00EAAVuha8v//ajwz0ln38VZmiVXy6Eny//9Z
M9JZahhZ9/FmKVXwZjl18H8IZgFN8Gb/Te5W6Cjy//9ZM9JqHFn38WYpVe5mOXXufxJW6BDy
//9ZM9JqA1n38WaJVe5W6P7x//9ZM9JqDFn38WYpVepmOXXqfwhmAU3qZv9N6I1F+FCNRehQ
/xWw0EAAjUX4UI1F+FCNRfhQV/8VMNFAAFf/FSTRQABfXsnDVYvsgeyUAAAAU1ZXagFbU+ij
8f//vgQBAAAz/1ZXaOw3SQDoyiAAAFZXaOg2SQDoviAAAFZXaOQ1SQDosiAAAFZXaOA0SQDo
piAAAFZXaNwzSQDomiAAAIPEQGjQ8EAAaGYiAABo1PBAAOjH3///aPg4SQDoCdD//4PEEP8V
vNBAACUAAACAiT0AOUkAo/A4SQCNhWz///9Qx4Vs////lAAAAP8VuNBAAIO9cP///wV1Djmd
dP///3UGiR0AOUkA6FXz//++ANAHAFbowSgAADvHWaPYM0kAdQQzwOskVldQ6AwgAADo1QAA
AFNoBA5BAOiK3f//UFfoTv3//4PEHIvDX15bycNVi+yD7BRXjU3s6DfA//+NRfxqAFCNTez/
dQjoKcD//4v4hf8PhIwAAABWvgAQAAA5dfxzBDP263JT/3UM6PkgAACL2ItF/AUY/P//WTvG
dlaNBD5TUP91DOi9LAAAg8QMhcB0D4tF/EYFGPz//zvwct/rM418PhS+ZiIAAI1f/FNWV+in
3v//i0UMVoPAFFBX6GUkAABT6ADe//9TVlfoL97//4PEKGoBXluNTezoUMD//4vGXl/Jw1NV
VldqAmiTC0EA6LDc//+LHfTQQABZWVD/04s1ONFAAIvohe2/kwxBAHQ5agFX6Izc//9ZWVBV
/9ZqBFejCDlJAOh53P//WVlQVf/WagVXowQ5SQDoZtz//1lZUFX/1qMMOUkAagNokwtBAOhP
3P//WVlQ/9OL6IXtdBNqA1foPNz//1lZUFX/1qMQOUkAv8gNQQBX/9OL2IXbdBNqAVfoG9z/
/1lZUFP/1qMUOUkAX15dW8NVi+yB7EwGAABTVleNTeToxL7//4t9CDPbV4ld9OiQ7///hcBZ
D4VqAgAAV+jP+P//hcBZD4VbAgAAvvsMQQBTVuj12///iUX8jYW4+v//U1BTU1fo7x8AAIPE
HDld/IldCH4x/3UIVuie2///OBhZWXQXUI2FuPr//1DoleP//1mFwFkPhQsCAAD/RQiLRQg7
Rfx8z42FyP7//1Dog+X//42FvPv//8cEJAQBAABQU/8VFNFAAI2FyP7//1NQjYW8+///UP8V
fNBAAIXAD4TCAQAAizWA0EAAjYXI/v//aiBQ/9ZoAFABAI2FyP7//1dQ6LH0//+DxAyFwA+E
hwEAAI1F+FNQV41N5OjMvf//O8OJRQgPhG4BAACBffgAUAEAD4ZZAQAAgX34AAAwAA+DTAEA
AI2FvPv//1NQjYW0+f//UI2FxP3//1BX6PgeAACNhbT5//9QjYXE/f//UOiKHQAAjYW8+///
UI2FxP3//1Dodx0AAI2FxP3//2is8EAAUOhmHQAAagRqA42FwPz//2oDUOgj3f//D76FwPz/
/1DotSAAAIPEQIiFwPz//42FwPz//1CNhcT9//9Q6CsdAACNRfRQ/3X4/3UI6BkaAACDxBQ7
w4lFCI1N5A+EoQAAAOiuvf///3X0jYXE/f///3UIUOha4///jYXE/f//UOiq+v//g8QQjYXE
/f//aidQ/9aNRcxQV+io5v//WYlF/FlqIFf/1lONhcj+//9XUP8VfNBAAI2FyP7//1DoUOT/
/42FxP3//1Bo1ABBAOiKHAAAaMDwQABX6DT8//+DxBQ5Xfx0DI1FzFBX6J3m//9ZWf91COj+
IAAAWWoBWOsXjU3k6A29//+Nhcj+//9Q6P7j//9ZM8BfXlvJw1WL7IHsKAQAAFaNTejoKrz/
/4Nl/ACNRfhqAVD/dQiNTejoGLz//4vwhfYPhJMAAACNheD9//9QjYXY+///UI2F3Pz//1CN
heT+//9Q/3UI6FcdAACNhdz8//9QjYXk/v//UOjpGwAAjYXY+///UI2F5P7//1Do1hsAAICl
5f3//wCNheH9//9QjYXk/v//UOi8GwAAjYXk/v//aNwBQQBQ6KsbAACNRfxQ/3X4VuiqGQAA
i/CDxECF9o1N6HUJ6DW8//8zwOtU6Cy8////dfyNheT+//9WUOja4f//Vuj5HwAAg8QQM/b/
FcTQQABQjYXk/v//UOjY6///WYXAWXQZav9Q/xXA0EAAjYXk/v//UOjg4v//WWoBXovGXsnD
VYvsgewEAQAAjYX8/v//aAQBAABQaKAxQQBqBWhSAkEA6CrY//9ZWVBoAQAAgOiO6f//agGN
hfz+////dQz/dQhQ6ODo//+DxCTJw1WL7IHsDAIAAFMz2zldDFZXiV38D4WLAQAAvosJQQBT
VugO2P//i/iNhfT9//9QjYX4/v//UFNTiJ34/v///3UI6PsbAACDxBxPO/uJXQx+Mf91DFbo
qtf//1CNhfj+//9Q6D9sAACDxBCFwHUMOX0MdAfHRfwBAAAA/0UMOX0MfM+NhfT9//9QjYX4
/v//UOhRGgAAvhsLQQBTVuiT1///g8QQM/87w4lFDH4oV1boUNf//1CNhfj+//9Q6OVrAACD
xBCFwHUHx0X8AQAAAEc7fQx82Dld/HQpagFo8A1BAOge1///i3UIUFboHt///4PEEIXAdQ9W
6I7h//9Z6aIAAACLdQhW6MXf//+L+Fk7+3w1VmjoNkkA6LgZAABZg/8FWX02VmjsN0kA6KYZ
AABqAWgA0AcA/zXYM0kAVuiY5///g8QY6xOD/5x1DlNq/2r/Vuh6EgAAg8QQixUYOUkAadIs
AQAAgfpYGwAAfhdT6Mfp//9ZM9JqBVn38YPCB2nS6AMAAFL/FSzRQAD/BRg5SQCBPRg5SQAQ
JwAAfgaJHRg5SQBqAVhfXlvJw1WL7IHsDAMAAFMz242F9Pz//1NQjYX8/v//UFP/dQjocBoA
AIPEFDldDHVtOV0QdT+Nhfz+//9Q6NwZAAA7w1l0B4icBfv+//+Nhfj9//9TUFONhfz+//9T
UOg1GgAAjYX4/f//UOh63v//g8QY6w2NhfT8//9Q6Gne//9ZhcB0GGoBaADQBwD/NdgzSQD/
dQjomOb//4PEEGoBWFvJw1ZXi3wkDGoBXmhuCUEAV+iu3f//WYXAWXQlaG0JQQBX6J3d//9Z
hcBZdAIz9lZoJ15AAFfoHeD//4PEDGoBWF9ew1WL7IHsDAsAAItFFFNWV/91DDPbiRiNhfT0
//9Q6CYYAACNhfT0//9oRPBAAFDoJRgAAP91EI2F9PT//1DoFhgAAI2F9Pj//2gABAAAUI2F
9PT//1NQaAIAAIDoh+b//42F9Pj//1CNhfz+//9Q6NUXAACDxDSNhfT4//9oBAEAAFCNhfz+
//9Q/xXI0EAAvosJQQBTVugL1f//iUUUjYX0/P//U1BTjYX0+P//U1Do/xgAAIPEHDP/OV0U
fitXVuix1P//OBhZWXQTUI2F9Pz//1DoqNz//1mFwFl1Bkc7fRR82jt9FHwkjYX0+P//aCMN
QQBQ6Ibc//9ZhcBZdA2NhfT4//9Q6F/4//9ZU42F+P3//1NQjYX8/v//UI2F9Pj//1DoihgA
AI2F+P3//1CNhfz+//9Q6BwXAACNhfz+//9Q6Hb+//+DxCBo6AMAAP8VLNFAAGoBWF9eW8nD
VYvsgewIAQAAgKX4/v//AI2F+P7//2oBUOhf3P//jUX8UI2F+P7//2gIX0AAUGgCAACA6PPl
//+DxBhogO42AP8VLNFAAOvBVYvsg30MAHU0g30QAHUIagX/FSzRQAD/dQjoftz//4XAWXwU
g/gDfQ//dQho7DdJAOhsFgAAWVlqAVhdw/91COjT/f//hcBZdAQzwF3DM8A5RRAPlMBdw1WL
7IHsDAEAAICl9P7//wBTjYX0/v//aAQBAABQagFobQlBAOhP0///WVlQaFICQQBoAgAAgOiu
5P//jYX0/v//UOh5/f//D76F9P7//4qd9v7//1DobhkAAIPEHINl+ACIRf+KRfgEYTpF/3Q8
gKX2/v//AIiF9P7//42F9P7//1D/FczQQACD+AOInfb+//91F/91CI2F9P7//2iuYEAAUOhv
3f//g8QM/0X4g334GnyxM8BbycIEAFZohQlBAP90JBDogRUAAIt0JBBW6GcWAACDxAwzyYXA
fguAPDFAdAVBO8h89Ug7yHwEM8Bew41EMQFQ/3QkEOhcFQAAWVlqAVhew1WL7IHsFAIAAIA9
1DJJAABWD4SbAAAAgD3QMUkAAA+EjgAAAIN9EACLdQh0ElboA7b///91DFbo0sD//4PEDGpk
aAABAABqGWjUMkkAjY3s/f//6NjJ//9qBGoKjUWcagNQ6L3U//+DxBCNRZyNjez9//9Q6DvO
//+DxmSNjez9//9W6OrO//9o0DFJAI2N7P3//+gxzv//jY3s/f//6MTK//+FwHQQjY3s/f//
6FDK//8zwF7Jw/91DOh2FQAAWVCNjez9////dQzo9Mr//42N7P3//4vw6CbK//8zwIX2D5TA
689Vi+yB7BgDAABWi3UIjYXo/P//UFbotv7//1mFwFl1BzPA6boAAACDfRAAdBJW6B61////
dQxW6O2///+DxAxqZGgAAQAAjYXo/P//ahlQjY3s/f//6PHI//9qBGoKjUWcagNQ6NbT//+D
xBCNRZyNjez9//9Q6FTN//+NRmSNjez9//9Q6APO//9WjY3s/f//6E7N//+Njez9///o4cn/
/4XAdBCNjez9///obcn//+lr/////3UM6JMUAABZUI2N7P3///91DOgRyv//jY3s/f//i/Do
Q8n//zPAhfYPlMBeycNVi+yB7AAIAACApQD4//8AgKUA/P//AI2FAPj//1D/dQjoxv3//42F
APz//1D/dQzot/3//42FAPz//1CNhQD4//9Q6ARlAACDxBj32BvAQMnDg+wQVVZXg0wkGP+9
ABAAAGoBVb7U8EAA/3QkKDP/iXwkIFbops///4PEEIXAD4XvAAAAV1boTtD//1k7x1mJRCQQ
D46yAAAAUzPbhf+JXCQQfjNTVuj+z///WVlQV1bo9M///1lZUOhC////WYXAWXQIx0QkEAEA
AABDO9981IN8JBAAdUxqAY1fATtcJBhYiUQkEH0uU1bou8///1lZUFdW6LHP//9ZWVDo//7/
/1mFwFl0BP9EJBBDO1wkFHzWi0QkEDtEJBh+CIlEJBiJfCQcRzt8JBQPjGz///+DfCQYAFt+
FYN8JBgAfA5V/3QkHFbow8///4PEDDP/agFV/3QkKFboxc7//4PEEIXAdRJVav9W6KHP//+D
xAxHg/8KfNpqAVhfXl2DxBDDgewEAgAAU1VWV8dEJBABAAAAMtu+Xg5BAL0EAQAAvwEAAID/
dCQQjUQkGIgd1DJJAIgd0DFJAFZo6ChBAFDoBBYAAIPEEFVo1DJJAGoBVujYzv//WVlQjUQk
IFBX6Dvg//+DxBQ4HdQySQB0J1Vo0DFJAGoCVuixzv//WVlQjUQkIFBX6BTg//+DxBQ4HdAx
SQB1F/9EJBCDfCQQCX6EiB3UMkkAiB3QMUkAX15dW4HEBAIAAMNVi+y4IDAAAOhLGQAAU1ZX
aAAAEADobRkAADPbWTvDiUXsdQlfXjPAW8nCBADo8O3//4XAdQ1oYOoAAP8VLNFAAOvqaADQ
BwD/NdgzSQDo0/X//1lZagHoovr//+jp/v//jYWI8///aAQBAABQU/8VFNFAAI2F3P7//1Do
D9j//1mJXfi+JAkAAOiU7f//hcB1Cmhg6gAA6YcDAACNhdz+//9Q6LPX//+FwFl1Wo2F3P7/
/1NQjYWI8///UP8VfNBAAI2F3P7//2ogUP8VgNBAAI2F3P7//2gAUAEAUOjb6P//U+jG4P//
M9K5ACgAAPfxjYXc/v//gcIAUgEAUlDoYtn//4PEFFP/NdgzSQDok83//zlF+FlZiUXoD439
AgAAaHoiAACNheDP//9owPBAAFDowRQAAI2F4M///4id9N///1CNhdz+//9Q6K3v//9WjYWM
9P//U1Doig8AAP91+P812DNJAOgKzf//g8QoOBiJReQPhJUCAABQjYXw9P//UOjBDwAAU+gh
4P//M9KDxAz3deg7Vfh1AUI7Veh8AjPSUv812DNJAOjIzP//i/hZWTgfdRBT/zXYM0kA6LTM
//9Zi/hZjYXc/v//UI2FOPr//1Dobw8AAI2FVPX//1dQ6GIPAACNhYz0//9XUOhVDwAAagGN
hYz0////dexQ6P/5//+DxCSFwA+FAAIAAFaNhYz0//9TUOjLDgAAjYXc/v//UI2FOPr//1Do
GA8AAI2FVPX//1dQ6AsPAACNhYz0//9XUOj+DgAA/3XkjYXw9P//UOjvDgAAagGNhYz0////
dexQ6H76//+DxDiFwHQMV+in+///WemSAQAAU2jU8EAA6B7M//+DTeD/WVmJRfSJXfBWjYWM
9P//U1DoRg4AAI2F3P7//1CNhTj6//9Q6JMOAACNhVT1//9XUOiGDgAA/3XkjYXw9P//UOh3
DgAAU+jX3v//M9KDxCj3dfQ7VeCJVfx1BEKJVfw7VfR8A4ld/P91/GjU8EAA6HbL//9QjYWM
9P//UOg7DgAAagGNhYz0////dexQ6Mr5//+DxByFwHUT/0Xwi0X8g33wBolF4A+MXP///4N9
8AYPjM0AAABTaCwOQQDoWcv//1OJRfToWN7//zPSg8QM93X0O1X0iVX8fAOJXfyNhVzy//9Q
jYWw/f//UFfoM9L//42FsP3//2g08EAAUOjKDQAA/3X8aCwOQQDo28r//1CNhbD9//9Q6LAN
AABWjYWM9P//U1DoMg0AAI2F3P7//1CNhTj6//9Q6H8NAACNhVT1//9XUOhyDQAAg8RAjYXw
9P///3XkUOhgDQAAjYWw/f//UI2FjPT//1DoTQ0AAGoBjYWM9P///3XsUOjc+P//g8Qc/0X4
i0X4O0XoD4wD/f//aMAnCQD/FSzRQADpW/z//1WL7IHsYAUAAGah9ChBAFZXagdmiUWgWTPA
jX2i86tmq6HwKEEAjX3oiUXkM8CrZqsz/8dF4CAAAAA5PfA4SQCJffSJffgPhd8BAAA5PQg5
SQAPhNMBAACLdQg793QljUXgUI1FgFD/FWTQQACNRYBQjUYCUOhwXgAAWYXAWQ+EpwEAAI2F
WP///4NN0P+JRdiNhbD+//+JRcCNhbD+//+JRciNRYBTUI1FoIl9xFCJfdSJfdzHRcx/AAAA
6GkMAABZjYUY////WWoiUGr/Vos1eNBAAGoBV//Wx0X8AgAAALtE8EAAikX8ahQEQYhF5I2F
WP///1CNReRq/1BqAVf/1opF5Go0iEWgjYWw/v//UI1FoGr/UGoBV//WjUX0UI1FwFCNhRj/
//9qAlD/FQg5SQA5fQyJRfAPhN4AAAA7x3VgOX34dVtqAWjcAUEAV+gr3P//WYPgAVCNhaT7
//9Q6MXW//+Nhaj8//9TUOinCwAAjUWgUI2FqPz//1DopwsAAGoBjYWk+///V1CNhaj8//9X
UP91COh6vP//g8Q4iUX4OX3wdXVqAWjCDUEAjYWg+v//V1Dob9b///91CI2FrP3//1DoTwsA
AI2FrP3//1NQ6FILAACNRaBQjYWs/f//UOhCCwAAjYWs/f//U1DoNQsAAI2FoPr//1CNhaz9
//9Q6CILAABqAWr/jYWs/f//av9Q6PwDAACDxEj/RfyDffwFD4y8/v//W19eycNVi+y4nEMA
AOjuEgAAjUUMV1CDTfz//3UIx0X4gD4AAGoDagFfV/91DOgpWwAAhcAPhUABAACNRfhTUI2F
ZLz//1CNRfxQ/3UM6ANbAAAz2zld/IldCA+GEQEAAFaNtXi8///2RvgCjUbsdBP/dRBqAlDo
if///4PEDOnbAAAAjYXs/P//UI2F8P3//1D/NujZ3v//g8QMhcAPhbsAAAD/dRCNhfD9//9Q
6CP9//9ZWVdo3AFBAFPoldr//1kjx1CNheT6//9Q6DDV//+DxBA5XRAPhIIAAABXjYXk+v//
U1CNhez8//9TUI2F8P3//1Do87r//4PEGFdowg1BAFPoTdr//1kjx1CNhej7//9Q6OjU////
No2F9P7//1DoyQkAAI2F9P7//2hE8EAAUOjICQAAjYXo+///UI2F9P7//1DotQkAAFdq/42F
9P7//2r/UOiQAgAAg8Q4/0UIg8Ygi0UIO0X8D4L3/v//Xv91DOjWWQAAW1/Jw2oBWFBqAmoA
6Hr+//+DxAxoAN1tAP8VLNFAADPA6+S4hCMAAOhZEQAAU1VWV41EJBRoBAEAADPbUFP/FRTR
QACLPYDQQAC+5DVJAGogVv/XU41EJBhWUP8VfNBAAGogVolEJBj/1zlcJBB0Vmh6IgAAjYQk
HAEAAGjA8EAAUOifDQAAjYQkJAEAAIicJDgRAABQVuiP6P//aABQAQBW6ETh//9T6C/Z//8z
0rkAKAAA9/GBwgBSAQBSVujR0f//g8QoVuh85v//WWonVv/XOR3wOEkAv9wzSQB0RVZXaOA0
SQBoAgAAgOiB1///agFokwtBAOioxf//g8QYUP8V9NBAAIvoaJMMQQBV/xU40UAAO8N0BWoB
U//QVf8V8NBAADlcJBB1BDPA63U5HfA4SQB0C1NW6MvY//9ZWetfOR34OEkAdVeLLQDQQABq
AlNT/9VTU1NTU1ZTagJoEAEAAFNXV1CJRCRE/xVI0EAA/3QkEIs1QNBAAP/WagFTU//Vi+hq
EFdV/xU40EAAi/hTU1f/FSTQQABX/9ZV/9ZqAVhfXl1bgcSEIwAAw1WL7FGh8ChBAIlF/IpF
CABF/I1F/FD/FczQQACD+AN0DIP4BHQHagFYycIEAGoAjUX8aHpcQABQ6FfP//+DxAxoAHS3
Af8VLNFAAOvgVYvsgexYAgAAVr5SAkEAjYXU/v//VlDoXwcAAGoHVuiFxP//UI2F1P7//1Do
WgcAAIClqP3//wCNhaj9//9oLAEAAFCNhdT+//9o8A1BAFBoAgAAgOjA1f//agCNhaj9//9o
elxAAFDo2s7//4PEODPAXsnCBABVi+y4kCUAAOgHDwAAi0UQU1aLdQwz21c5XRSJdfyJRfh1
Ef91COiu1///hcBZD4U+AQAAv3QNQQBTV+gixP//WTvzWYlFDH0PU+gb1///M9JZ93UMiVX8
vtwBQQBTVuj+w///OV0QWVmJRQx9D1Po9tb//zPSWfd1DIlV+I2F9P7//1Dows3//42F7Pz/
/8cEJAQBAABQU/8VFNFAAI2F9P7//1NQjYXs/P//UP8VfNBAAIXAD4S3AAAAjYX0/v//aiBQ
/xWA0EAAaHoiAACNhXDa//9owPBAAFDo1AoAAI2FcNr//4idhOr//1CNhfT+//9Q6MDl//9T
6GvW//8z0rkAKAAA9/GNhfT+//+BwgBSAQBSUOgHz////3X8V+gOw///UI2F8P3//1Do0wUA
AP91+Fbo+ML//1CNhfD9//9Q6M0FAACDxECNhfD9////dRRQjYX0/v//UP91COh34P//jYX0
/v//UOhKzf//g8QUX15bycNq//8VLNFAAOv2VYvsgewgAgAAagRqBY1F6GoCUOhKxf//gKXg
/f//AIPEEI2F4P3//2gEAQAAUGoBaG0JQQDod8L//1lZUGhSAkEAaAIAAIDo1tP//4PEFI2F
5P7//1CNRehqAFCNheD9//9Q/xV00EAAjYXk/v//UOjDzP//jYXk/v//UOjyBQAAWVlIeAqA
vAXk/v//LnXzhcB+FI2EBeT+//9o3AFBAFDo3QQAAFlZjUX8VlBophUAAGhAE0EA6OMCAAD/
dfyL8I2F5P7//1ZQ6CvL//+DxBiFwHUfjYXk/v//UOjpy////3X8jYXk/v//VlDoCMv//4PE
EI2F5P7//2oAUOgT1f//WVlehcB0Fmr/UP8VwNBAAI2F5P7//1DoGsz//1kzwMnCBABVi+xR
U1aLNdDQQABXjUX8M/9QV1do/xVAAFdX/9aNRfxQV1doCGZAAFdX/9aNRfxQV1do3m1AAFdX
/9aNRfxQV1doZmBAAFdX/9aNRfxQV1dozXFAAFdX/9aNRfxQV1do1W9AAFdX/9Yz241F/FBX
U2iIb0AAV1f/1kOD+xp86+hM/v//X15bycNVi+yD7BwzwMdF5BABAACJReyJRfCJRfSJRfiJ
RfyNReRQx0XoBAAAAP81HDlJAP8VWNBAAOiT2P//hcB0Begz////ycIEAGh8c0AAaNwzSQD/
FTTQQABqAKMcOUkA6J3////CCABVi+yB7KABAACNhWD+//9QagL/FeDRQADo/+H//4XAdFTo
9fn//4A91ABBAAB0D2jUAEEA6PTm//+FwFl1N4M9+DhJAAB0IINl+ACDZfwAjUXwx0Xw3DNJ
AFDHRfTDc0AA/xUE0EAA6PvX//+FwHQF6Jv+//8zwMnCEABVi+y4jDgBAOj2CgAAU1b/dQzo
GwsAAIvYM/Y73lmJXfSJdfiJdfx1BzPA6dsAAABXaIA4AQCNhXTH/v9WUOhQAgAAg8QMM8CN
vXjH/v87RQxzZotNCIoMCITJdA2IDB5GQIl1/DtFDHLpO0UMc0qLyItVCIA8EQB1BkE7TQxy
8YvRK9CD+gpzETvBc8GLVQiKFBCIFB5GQOvvgX34ECcAAHMP/0X4iUf8iReDxwiLweuciXX8
M/brSItF+Il1/Iv4wecDjVw3BFPoZAoAAIvwi0X4V4kGjYV0x/7/UI1GBFDovQYAAP91/I1E
NwT/dfRQ6K0GAACLRRCDxByJGItd9FPohwYAAFmLxl9eW8nDVYvsg+wMU4tdCFZXiwMz0ov4
jUsEwecDiVX8iU30jXcEiUX4OXUMcwczwOmcAAAAhcB2I4vxiUUIiw470XMHK8oD0QFN/ItG
BIXAdgID0IPGCP9NCHXii0UMK8eDwPw5RfyJRQxzBStF/APQi0UQM/YhdfxSiRDopwkAAI18
HwSLXfiF21l2LotN9Dsxcw+LVfyKFDqIFDBG/0X86+0z0jlRBHYLgCQwAEZCO1EEcvWDwQhL
ddWLTfw7TQxzDgPwihQ5iBZGQTtNDHL0X15bycPM/yUc0UAA/yUM0UAA/yUQ0UAA/yUA0UAA
zMzMzMzMzMzMzItUJASLTCQI98IDAAAAdTyLAjoBdS4KwHQmOmEBdSUK5HQdwegQOkECdRkK
wHQROmEDdRCDwQSDwgQK5HXSi/8zwMOQG8DR4EDDi//3wgEAAAB0FIoCQjoBdelBCsB04PfC
AgAAAHSoZosCg8ICOgF10grAdMo6YQF1yQrkdMGDwQLrjMzMzMzMzMzMzMzMzItUJAyLTCQE
hdJ0RzPAikQkCFeL+YP6BHIt99mD4QN0CCvRiAdHSXX6i8jB4AgDwYvIweAQA8GLyoPiA8Hp
AnQG86uF0nQGiAdHSnX6i0QkCF/Di0QkBMPMzMzMzMzMzFeLfCQI62qNpCQAAAAAi/+LTCQE
V/fBAwAAAHQPigFBhMB0O/fBAwAAAHXxiwG6//7+fgPQg/D/M8KDwQSpAAEBgXToi0H8hMB0
I4TkdBqpAAD/AHQOqQAAAP90AuvNjXn/6w2Nef7rCI15/esDjXn8i0wkDPfBAwAAAHQZihFB
hNJ0ZIgXR/fBAwAAAHXu6wWJF4PHBLr//v5+iwED0IPw/zPCixGDwQSpAAEBgXThhNJ0NIT2
dCf3wgAA/wB0EvfCAAAA/3QC68eJF4tEJAhfw2aJF4tEJAjGRwIAX8NmiReLRCQIX8OIF4tE
JAhfw4tMJAT3wQMAAAB0FIoBQYTAdED3wQMAAAB18QUAAAAAiwG6//7+fgPQg/D/M8KDwQSp
AAEBgXToi0H8hMB0MoTkdCSpAAD/AHQTqQAAAP90AuvNjUH/i0wkBCvBw41B/otMJAQrwcON
Qf2LTCQEK8HDjUH8i0wkBCvBw1WL7FGDZfwAU4tdCFZXU+hx////g/gBWXIhgHsBOnUbi3UM
hfZ0EGoCU1bojBAAAIPEDIBmAgBDQ+sKi0UMhcB0A4AgAINlDACAOwCLw77/AAAAiUUIdGWK
CA+20faCYU1JAAR0A0DrGoD5L3QPgPlcdAqA+S51C4lF/OsGjUgBiU0MQIA4AHXPi30MiUUI
hf90KoN9EAB0Hyv7O/5yAov+V1P/dRDoERAAAItFEIPEDIAkBwCLRQiLXQzrCotNEIXJdAOA
IQCLffyF/3RMO/tySIN9FAB0Hyv7O/5yAov+V1P/dRTo0g8AAItFFIPEDIAkBwCLRQiLfRiF
/3REK0X8O8ZzAovwVv91/Ffoqw8AAIPEDIAkPgDrKIt9FIX/dBcrwzvGcwKL8FZTV+iLDwAA
g8QMgCQ+AItFGIXAdAOAIABfXlvJw1WL7FGDPTw5SQAAU3Udi0UIg/hhD4yvAAAAg/h6D4+m
AAAAg+gg6Z4AAACLXQiB+wABAAB9KIM9HCxBAAF+DGoCU+gHEgAAWVnrC6EQKkEAigRYg+AC
hcB1BIvD62uLFRAqQQCLw8H4CA+2yPZESgGAdA6AZQoAiEUIiF0JagLrCYBlCQCIXQhqAViN
TfxqAWoAagNRUI1FCFBoAAIAAP81PDlJAOhVDwAAg8QghcB0qYP4AXUGD7ZF/OsND7ZF/Q+2
TfzB4AgLwVvJw1WL7FGDPTw5SQAAU1ZXdR2LRQiD+EEPjKoAAACD+FoPj6EAAACDwCDpmQAA
AItdCL8AAQAAagE73159JTk1HCxBAH4LVlPoNxEAAFlZ6wqhECpBAIoEWCPGhcB1BIvD62WL
FRAqQQCLw8H4CA+2yPZESgGAdA+AZQoAagKIRQiIXQlY6wmAZQkAiF0Ii8ZWagCNTfxqA1FQ
jUUIUFf/NTw5SQDoiw4AAIPEIIXAdK47xnUGD7ZF/OsND7ZF/Q+2TfzB4AgLwV9eW8nDVYvs
g+wgi0UIVolF6IlF4I1FEMdF7EIAAABQjUXg/3UMx0Xk////f1DoExIAAIPEDP9N5IvweAiL
ReCAIADrDY1F4FBqAOjhEAAAWVmLxl7Jw/90JATo8BkAAFnDzMzMzMzMzMzMzFWL7FdWi3UM
i00Qi30Ii8GL0QPGO/52CDv4D4J4AQAA98cDAAAAdRTB6QKD4gOD+QhyKfOl/ySVSH1AAIvH
ugMAAACD6QRyDIPgAwPI/ySFYHxAAP8kjVh9QACQ/ySN3HxAAJBwfEAAnHxAAMB8QAAj0YoG
iAeKRgGIRwGKRgLB6QKIRwKDxgODxwOD+QhyzPOl/ySVSH1AAI1JACPRigaIB4pGAcHpAohH
AYPGAoPHAoP5CHKm86X/JJVIfUAAkCPRigaIB0bB6QJHg/kIcozzpf8klUh9QACNSQA/fUAA
LH1AACR9QAAcfUAAFH1AAAx9QAAEfUAA/HxAAItEjuSJRI/ki0SO6IlEj+iLRI7siUSP7ItE
jvCJRI/wi0SO9IlEj/SLRI74iUSP+ItEjvyJRI/8jQSNAAAAAAPwA/j/JJVIfUAAi/9YfUAA
YH1AAGx9QACAfUAAi0UIXl/Jw5CKBogHi0UIXl/Jw5CKBogHikYBiEcBi0UIXl/Jw41JAIoG
iAeKRgGIRwGKRgKIRwKLRQheX8nDkI10MfyNfDn898cDAAAAdSTB6QKD4gOD+QhyDf3zpfz/
JJXgfkAAi//32f8kjZB+QACNSQCLx7oDAAAAg/kEcgyD4AMryP8kheh9QAD/JI3gfkAAkPh9
QAAYfkAAQH5AAIpGAyPRiEcDTsHpAk+D+Qhytv3zpfz/JJXgfkAAjUkAikYDI9GIRwOKRgLB
6QKIRwKD7gKD7wKD+QhyjP3zpfz/JJXgfkAAkIpGAyPRiEcDikYCiEcCikYBwekCiEcBg+4D
g+8Dg/kID4Ja/////fOl/P8kleB+QACNSQCUfkAAnH5AAKR+QACsfkAAtH5AALx+QADEfkAA
135AAItEjhyJRI8ci0SOGIlEjxiLRI4UiUSPFItEjhCJRI8Qi0SODIlEjwyLRI4IiUSPCItE
jgSJRI8EjQSNAAAAAAPwA/j/JJXgfkAAi//wfkAA+H5AAAh/QAAcf0AAi0UIXl/Jw5CKRgOI
RwOLRQheX8nDjUkAikYDiEcDikYCiEcCi0UIXl/Jw5CKRgOIRwOKRgKIRwKKRgGIRwGLRQhe
X8nDi0QkBKMAKUEAw6EAKUEAacD9QwMABcOeJgCjAClBAMH4ECX/fwAAw8zMzFE9ABAAAI1M
JAhyFIHpABAAAC0AEAAAhQE9ABAAAHPsK8iLxIUBi+GLCItABFDDagH/dCQI6IsWAABZWcNV
i+yD7CCLRQjHRexJAAAAUIlF6IlF4OiH+P//iUXkjUUQUI1F4P91DFDouxYAAIPEEMnDzMzM
zMzMzMzMzMzMzMzMVYvsV1aLdQyLTRCLfQiLwYvRA8Y7/nYIO/gPgngBAAD3xwMAAAB1FMHp
AoPiA4P5CHIp86X/JJUogUAAi8e6AwAAAIPpBHIMg+ADA8j/JIVAgEAA/ySNOIFAAJD/JI28
gEAAkFCAQAB8gEAAoIBAACPRigaIB4pGAYhHAYpGAsHpAohHAoPGA4PHA4P5CHLM86X/JJUo
gUAAjUkAI9GKBogHikYBwekCiEcBg8YCg8cCg/kIcqbzpf8klSiBQACQI9GKBogHRsHpAkeD
+QhyjPOl/ySVKIFAAI1JAB+BQAAMgUAABIFAAPyAQAD0gEAA7IBAAOSAQADcgEAAi0SO5IlE
j+SLRI7oiUSP6ItEjuyJRI/si0SO8IlEj/CLRI70iUSP9ItEjviJRI/4i0SO/IlEj/yNBI0A
AAAAA/AD+P8klSiBQACL/ziBQABAgUAATIFAAGCBQACLRQheX8nDkIoGiAeLRQheX8nDkIoG
iAeKRgGIRwGLRQheX8nDjUkAigaIB4pGAYhHAYpGAohHAotFCF5fycOQjXQx/I18Ofz3xwMA
AAB1JMHpAoPiA4P5CHIN/fOl/P8klcCCQACL//fZ/ySNcIJAAI1JAIvHugMAAACD+QRyDIPg
AyvI/ySFyIFAAP8kjcCCQACQ2IFAAPiBQAAggkAAikYDI9GIRwNOwekCT4P5CHK2/fOl/P8k
lcCCQACNSQCKRgMj0YhHA4pGAsHpAohHAoPuAoPvAoP5CHKM/fOl/P8klcCCQACQikYDI9GI
RwOKRgKIRwKKRgHB6QKIRwGD7gOD7wOD+QgPglr////986X8/ySVwIJAAI1JAHSCQAB8gkAA
hIJAAIyCQACUgkAAnIJAAKSCQAC3gkAAi0SOHIlEjxyLRI4YiUSPGItEjhSJRI8Ui0SOEIlE
jxCLRI4MiUSPDItEjgiJRI8Ii0SOBIlEjwSNBI0AAAAAA/AD+P8klcCCQACL/9CCQADYgkAA
6IJAAPyCQACLRQheX8nDkIpGA4hHA4tFCF5fycONSQCKRgOIRwOKRgKIRwKLRQheX8nDkIpG
A4hHA4pGAohHAopGAYhHAYtFCF5fycODPRwsQQABfhFoAwEAAP90JAjoJAkAAFlZw4tEJASL
DRAqQQBmiwRBJQMBAADDgz0cLEEAAX4OagT/dCQI6PkIAABZWcOLRCQEiw0QKkEAigRBg+AE
w4M9HCxBAAF+DmoI/3QkCOjRCAAAWVnDi0QkBIsNECpBAIoEQYPgCMPMzMzMzMzMzMzMzMzM
i0wkCFdTVooRi3wkEITSdGmKcQGE9nRPi/eLTCQUigdGONB0FYTAdAuKBkY40HQKhMB19V5b
XzPAw4oGRjjwdeuNfv+KYQKE5HQoigaDxgI44HXEikEDhMB0GIpm/4PBAjjgdN/rsTPAXltf
isLpQx0AAI1H/15bX8OLx15bX8NVi+xXVlOLTRDjJovZi30Ii/czwPKu99kDy4v+i3UM86aK
Rv8zyTpH/3cEdARJSffRi8FbXl/Jw1WL7Gr/aEDSQABoBKxAAGShAAAAAFBkiSUAAAAAg+xY
U1ZXiWXo/xW80EAAM9KK1IkVbDlJAIvIgeH/AAAAiQ1oOUkAweEIA8qJDWQ5SQDB6BCjYDlJ
ADP2VugWJgAAWYXAdQhqHOiwAAAAWYl1/OhWJAAA/xXE0EAAo2hOSQDoFCMAAKMgOUkA6L0g
AADo/x8AAOgcHQAAiXXQjUWkUP8VeNFAAOiQHwAAiUWc9kXQAXQGD7dF1OsDagpYUP91nFZW
/xV00UAAUOi87v//iUWgUOgKHQAAi0XsiwiLCYlNmFBR6M4dAABZWcOLZej/dZjo/BwAAIM9
KDlJAAF1BeiAJwAA/3QkBOiwJwAAaP8AAAD/FRApQQBZWcODPSg5SQABdQXoWycAAP90JATo
iycAAFlo/wAAAP8VfNFAAMNVi+yD7BhTVlf/dQjoiAEAAIvwWTs1OExJAIl1CA+EagEAADPb
O/MPhFYBAAAz0rggKUEAOTB0coPAMEI9ECpBAHzxjUXoUFb/FYDRQACD+AEPhSQBAABqQDPA
Wb9gTUkAg33oAYk1OExJAPOrqokdZE5JAA+G7wAAAIB97gAPhLsAAACNTe+KEYTSD4SuAAAA
D7ZB/w+20jvCD4eTAAAAgIhhTUkABEDr7mpAM8BZv2BNSQDzq400Uold/MHmBKqNnjApQQCA
OwCLy3QsilEBhNJ0JQ+2AQ+2+jvHdxSLVfyKkhgpQQAIkGFNSQBAO8d29UFBgDkAddT/RfyD
wwiDffwEcsGLRQjHBUxMSQABAAAAUKM4TEkA6MYAAACNtiQpQQC/QExJAKWlWaNkTkkApetV
QUGAef8AD4VI////agFYgIhhTUkACEA9/wAAAHLxVuiMAAAAWaNkTkkAxwVMTEkAAQAAAOsG
iR1MTEkAM8C/QExJAKurq+sNOR0sOUkAdA7ojgAAAOiyAAAAM8DrA4PI/19eW8nDi0QkBIMl
LDlJAACD+P51EMcFLDlJAAEAAAD/JYjRQACD+P11EMcFLDlJAAEAAAD/JYTRQACD+Px1D6FM
OUkAxwUsOUkAAQAAAMOLRCQELaQDAAB0IoPoBHQXg+gNdAxIdAMzwMO4BAQAAMO4EgQAAMO4
BAgAAMO4EQQAAMNXakBZM8C/YE1JAPOrqjPAv0BMSQCjOExJAKNMTEkAo2ROSQCrq6tfw1WL
7IHsFAUAAI1F7FZQ/zU4TEkA/xWA0UAAg/gBD4UWAQAAM8C+AAEAAIiEBez+//9AO8Zy9IpF
8saF7P7//yCEwHQ3U1eNVfMPtgoPtsA7wXcdK8iNvAXs/v//QbggICAgi9nB6QLzq4vLg+ED
86pCQopC/4TAddBfW2oAjYXs+v///zVkTkkA/zU4TEkAUI2F7P7//1ZQagHo8yUAAGoAjYXs
/f///zU4TEkAVlCNhez+//9WUFb/NWROSQDoaAEAAGoAjYXs/P///zU4TEkAVlCNhez+//9W
UGgAAgAA/zVkTkkA6EABAACDxFwzwI2N7Pr//2aLEfbCAXQWgIhhTUkAEIqUBez9//+IkGBM
SQDrHPbCAnQQgIhhTUkAIIqUBez8///r44CgYExJAABAQUE7xnK/60kzwL4AAQAAg/hBchmD
+Fp3FICIYU1JABCKyIDBIIiIYExJAOsfg/hhchOD+Hp3DoCIYU1JACCKyIDpIOvggKBgTEkA
AEA7xnK+XsnDgz0oTEkAAHUSav3oLPz//1nHBShMSQABAAAAw1WL7IM9TExJAABXi30IiX0I
dRH/dRD/dQxX6ComAACDxAzrY4tVEFaF0nQ9i00MigFKD7bw9oZhTUkABIgHdBNHQYXSdBmK
AUqIB0dBhMB0FOsGR0GEwHQQhdJ10usKgGf/AOsEgGf+AIvCSoXAXnQTjUoBM8CL0cHpAvOr
i8qD4QPzqotFCF9dw1WL7Gr/aFjSQABoBKxAAGShAAAAAFBkiSUAAAAAg+wcU1ZXiWXoM/85
PTA5SQB1RldXagFbU2hQ0kAAvgABAABWV/8VPNFAAIXAdAiJHTA5SQDrIldXU2hM0kAAVlf/
FUDRQACFwA+EIgEAAMcFMDlJAAIAAAA5fRR+EP91FP91EOieAQAAWVmJRRShMDlJAIP4AnUd
/3Uc/3UY/3UU/3UQ/3UM/3UI/xVA0UAA6d4AAACD+AEPhdMAAAA5fSB1CKFMOUkAiUUgV1f/
dRT/dRCLRST32BvAg+AIQFD/dSD/FXjQQACL2Ild5DvfD4ScAAAAiX38jQQbg8ADJPzoXfT/
/4ll6IvEiUXcg038/+sTagFYw4tl6DP/iX3cg038/4td5Dl93HRmU/913P91FP91EGoB/3Ug
/xV40EAAhcB0TVdXU/913P91DP91CP8VPNFAAIvwiXXYO/d0MvZFDQR0QDl9HA+EsgAAADt1
HH8e/3Uc/3UYU/913P91DP91CP8VPNFAAIXAD4WPAAAAM8CNZciLTfBkiQ0AAAAAX15bycPH
RfwBAAAAjQQ2g8ADJPzoqfP//4ll6IvciV3gg038/+sSagFYw4tl6DP/M9uDTfz/i3XYO990
tFZT/3Xk/3Xc/3UM/3UI/xU80UAAhcB0nDl9HFdXdQRXV+sG/3Uc/3UYVlNoIAIAAP91IP8V
oNBAAIvwO/cPhHH///+Lxuls////i1QkCItEJASF0laNSv90DYA4AHQIQIvxSYX2dfOAOABe
dQUrRCQEw4vCw1WL7FGLRQiNSAGB+QABAAB3DIsNECpBAA+3BEHrUovIVos1ECpBAMH5CA+2
0fZEVgGAXnQOgGX+AIhN/IhF/WoC6wmAZf0AiEX8agFYjU0KagFqAGoAUVCNRfxQagHotSEA
AIPEHIXAdQLJww+3RQojRQzJw1WL7FNWi3UMi0YMi14QqIIPhPMAAACoQA+F6wAAAKgBdBaD
ZgQAqBAPhNsAAACLTggk/okOiUYMi0YMg2YEAINlDAAk7wwCZqkMAYlGDHUigf6gLUEAdAiB
/sAtQQB1C1PoHiYAAIXAWXUHVujPJQAAWWb3RgwIAVd0ZItGCIs+K/iNSAGJDotOGEmF/4lO
BH4QV1BT6PkjAACDxAyJRQzrM4P7/3QWi8OLy8H4BYPhH4sEhSBLSQCNBMjrBbjILEEA9kAE
IHQNagJqAFPoJyMAAIPEDItGCIpNCIgI6xRqAY1FCF9XUFPopiMAAIPEDIlFDDl9DF90BoNO
DCDrD4tFCCX/AAAA6wgMIIlGDIPI/15bXcNVi+yB7EgCAABTVleLfQwz9oofR4TbiXX0iXXs
iX0MD4T0BgAAi03wM9LrCItN8It10DPSOVXsD4zcBgAAgPsgfBOA+3h/Dg++w4qAUNJAAIPg
D+sCM8APvoTGcNJAAMH4BIP4B4lF0A+HmgYAAP8khfuUQACDTfD/iVXMiVXYiVXgiVXkiVX8
iVXc6XgGAAAPvsOD6CB0O4PoA3Qtg+gIdB9ISHQSg+gDD4VZBgAAg038COlQBgAAg038BOlH
BgAAg038Aek+BgAAgE38gOk1BgAAg038AuksBgAAgPsqdSONRRBQ6PUGAACFwFmJReAPjRIG
AACDTfwE99iJReDpBAYAAItF4A++y40EgI1EQdDr6YlV8OntBQAAgPsqdR6NRRBQ6LYGAACF
wFmJRfAPjdMFAACDTfD/6coFAACNBIkPvsuNREHQiUXw6bgFAACA+0l0LoD7aHQggPtsdBKA
+3cPhaAFAACATf0I6ZcFAACDTfwQ6Y4FAACDTfwg6YUFAACAPzZ1FIB/ATR1DkdHgE39gIl9
DOlsBQAAiVXQiw0QKkEAiVXcD7bD9kRBAYB0GY1F7FD/dQgPvsNQ6H8FAACKH4PEDEeJfQyN
RexQ/3UID77DUOhmBQAAg8QM6SUFAAAPvsOD+GcPjxwCAACD+GUPjZYAAACD+FgPj+sAAAAP
hHgCAACD6EMPhJ8AAABISHRwSEh0bIPoDA+F6QMAAGb3RfwwCHUEgE39CIt18IP+/3UFvv//
/3+NRRBQ6JwFAABm90X8EAhZi8iJTfgPhP4BAACFyXUJiw0sLEEAiU34x0XcAQAAAIvBi9ZO
hdIPhNQBAABmgzgAD4TKAQAAQEDr58dFzAEAAACAwyCDTfxAjb24/f//O8qJffgPjc8AAADH
RfAGAAAA6dEAAABm90X8MAh1BIBN/Qhm90X8EAiNRRBQdDvoMAUAAFCNhbj9//9Q6HUjAACD
xAyJRfSFwH0yx0XYAQAAAOspg+hadDKD6Al0xUgPhOgBAADpCAMAAOjYBAAAWYiFuP3//8dF
9AEAAACNhbj9//+JRfjp5wIAAI1FEFDoswQAAIXAWXQzi0gEhcl0LPZF/Qh0Fw+/ANHoiU34
iUX0x0XcAQAAAOm1AgAAg2XcAIlN+A+/AOmjAgAAoSgsQQCJRfhQ6Y4AAAB1DID7Z3UHx0Xw
AQAAAItFEP91zIPACIlFEP918ItI+IlNuItA/IlFvA++w1CNhbj9//9QjUW4UP8VADBBAIt1
/IPEFIHmgAAAAHQUg33wAHUOjYW4/f//UP8VDDBBAFmA+2d1EoX2dQ6Nhbj9//9Q/xUEMEEA
WYC9uP3//y11DYBN/QGNvbn9//+JffhX6GHm//9Z6fwBAACD6GkPhNEAAACD6AUPhJ4AAABI
D4SEAAAASHRRg+gDD4T9/f//SEgPhLEAAACD6AMPhckBAADHRdQnAAAA6zwrwdH46bQBAACF
yXUJiw0oLEEAiU34i8GL1k6F0nQIgDgAdANA6/ErwemPAQAAx0XwCAAAAMdF1AcAAAD2RfyA
x0X0EAAAAHRdikXUxkXqMARRx0XkAgAAAIhF6+tI9kX8gMdF9AgAAAB0O4BN/QLrNY1FEFDo
GwMAAPZF/CBZdAlmi03sZokI6wWLTeyJCMdF2AEAAADpIwIAAINN/EDHRfQKAAAA9kX9gHQM
jUUQUOjtAgAAWetB9kX8IHQh9kX8QI1FEFB0DOjIAgAAWQ+/wJnrJei8AgAAWQ+3wOvy9kX8
QI1FEFB0COinAgAAWevg6J8CAABZM9L2RfxAdBuF0n8XfASFwHMR99iD0gCL8PfagE39AYv6
6wSL8Iv69kX9gHUDg+cAg33wAH0Jx0XwAQAAAOsEg2X894vGC8d1BINl5ACNRbeJRfiLRfD/
TfCFwH8Gi8YLx3Q7i0X0mVJQV1aJRcCJVcTobyEAAP91xIvYg8Mw/3XAV1bo7SAAAIP7OYvw
i/p+AwNd1ItF+P9N+IgY67WNRbcrRfj/Rfj2Rf0CiUX0dBmLTfiAOTB1BIXAdQ3/TfhAi034
xgEwiUX0g33YAA+F9AAAAItd/PbDQHQm9scBdAbGReot6xT2wwF0BsZF6ivrCfbDAnQLxkXq
IMdF5AEAAACLdeArdeQrdfT2wwx1Eo1F7FD/dQhWaiDoFwEAAIPEEI1F7FCNRer/dQj/deRQ
6DIBAACDxBD2wwh0F/bDBHUSjUXsUP91CFZqMOjlAAAAg8QQg33cAHRBg330AH47i0X0i134
jXj/ZosDQ1CNRchQQ+iWHwAAWYXAWX4yjU3sUf91CFCNRchQ6NgAAACDxBCLx0+FwHXQ6xWN
RexQ/3UI/3X0/3X46LoAAACDxBD2RfwEdBKNRexQ/3UIVmog6HEAAACDxBCLfQyKH0eE24l9
DA+FE/n//4tF7F9eW8nDeY9AAE+OQABqjkAAto5AAO2OQAD1jkAAKo9AAL2PQABVi+yLTQz/
SQR4DosRikUIiAL/AQ+2wOsLUf91COiI9///WVmD+P+LRRB1BYMI/13D/wBdw1ZXi3wkEIvH
T4XAfiGLdCQYVv90JBj/dCQU6Kz///+DxAyDPv90B4vHT4XAf+NfXsNTi1wkDIvDS1ZXhcB+
Jot8JByLdCQQD74GV0b/dCQcUOh1////g8QMgz//dAeLw0uFwH/iX15bw4tEJASDAASLAItA
/MOLRCQEgwAIiwiLQfiLUfzDi0QkBIMABIsAZotA/MNWi3QkCIX2dCRW6MAfAABZhcBWdApQ
6N8fAABZWV7DagD/NQRLSQD/FZDRQABew/81uDpJAP90JAjoAwAAAFlZw4N8JATgdyL/dCQE
6BwAAACFwFl1FjlEJAh0EP90JATodScAAIXAWXXeM8DDVot0JAg7NSAwQQB3C1bopSIAAIXA
WXUchfZ1A2oBXoPGD4Pm8FZqAP81BEtJAP8VlNFAAF7DVYvsgezEAQAAgGXrAFNWi3UMM9tX
igaJXfyEwIldzA+E4QkAAIt9COsFi30IM9uDPRwsQQABfg8PtsBqCFDohvX//1lZ6w+LDRAq
QQAPtsCKBEGD4Ag7w3Q2/038V41F/FdQ6CUKAABZWVDoBgoAAA+2RgFGUOhp7P//g8QMhcB0
Dg+2RgFGUOhX7P//WevugD4lD4XZCAAAgGXLAIBl6ACAZekAgGXyAIBl8QCAZeoAM/+AZfsA
iV3kiV3giV30xkXzAYld0A+2XgFGgz0cLEEAAX4PD7bDagRQ6On0//9ZWesPiw0QKkEAD7bD
igRBg+AEhcB0EotF9P9F4I0EgI1EQ9CJRfTrZYP7Tn8+dF6D+yp0MoP7RnRUg/tJdAqD+0x1
N/5F8+tFgH4BNnUsgH4CNI1GAnUj/0XQg2XYAINl3ACL8Osn/kXy6yKD+2h0F4P7bHQKg/t3
dAj+RfHrDv5F8/5F++sG/k3z/k37gH3xAA+ET////4B98gCJdQx1EotFEIlFvIPABIlFEItA
/IlF1IBl8QCAffsAdRSKBjxTdAo8Q3QGgE37/+sExkX7AYtdDA+2M4POIIP+bol1xHQog/5j
dBSD/nt0D/91CI1F/FDotQgAAFnrC/91CP9F/Oh2CAAAWYlF7DPAOUXgdAk5RfQPhNwHAACD
/m8Pj14CAAAPhAoFAACD/mMPhCwCAACD/mQPhPgEAAAPjmoCAACD/md+OIP+aXQbg/5uD4VX
AgAAgH3yAIt9/A+EAAcAAOkhBwAAamRei13sg/stD4V+AgAAxkXpAel6AgAAi13sjbU8/v//
g/stdQ6InTz+//+NtT3+///rBYP7K3UXi30I/030/0X8V+jOBwAAi9hZiV3s6wOLfQiDfeAA
dAmBffRdAQAAfgfHRfRdAQAAgz0cLEEAAX4MagRT6Anz//9ZWesLoRAqQQCKBFiD4ASFwHQh
i0X0/030hcB0F/9F5IgeRv9F/FfocAcAAIvYWYld7Ou7OB0gLEEAdWaLRfT/TfSFwHRc/0X8
V+hNBwAAi9igICxBAIgGWYld7EaDPRwsQQABfgxqBFPom/L//1lZ6wuhECpBAIoEWIPgBIXA
dCGLRfT/TfSFwHQX/0XkiB5G/0X8V+gCBwAAi9hZiV3s67uDfeQAD4SOAAAAg/tldAmD+0UP
hYAAAACLRfT/TfSFwHR2xgZlRv9F/FfoywYAAIvYWYP7LYld7HUFiAZG6wWD+yt1HotF9P9N
9IXAdQUhRfTrD/9F/FfongYAAIvYWYld7IM9HCxBAAF+DGoEU+j08f//WVnrC6EQKkEAigRY
g+AEhcB0EotF9P9N9IXAdAj/ReSIHkbru/9N/FdT6HIGAACDfeQAWVkPhPYFAACAffIAD4VN
BQAA/0XMgCYAjYU8/v//UA++RfP/ddRIUP8VCDBBAIPEDOkpBQAAOUXgdQr/RfTHReABAAAA
gH37AH4ExkXqAb84LEEA6QsBAACLxoPocA+EowIAAIPoAw+E6AAAAEhID4SWAgAAg+gDD4TD
/f//g+gDdCQPtgM7RewPhT8FAAD+TeuAffIAD4XDBAAAi0W8iUUQ6bgEAACAffsAfgTGReoB
i30MR4l9DIA/Xg+FpwAAAIvHjXgB6ZkAAACD+yt1Iv9N9HUMg33gAHQGxkXxAesR/3UI/0X8
6GgFAACL2FmJXeyD+zAPhUUCAAD/dQj/RfzoTgUAAIvYWYD7eIld7HQvgPtYdCqD/njHReQB
AAAAdAhqb17pFgIAAP91CP9N/FPoOAUAAFlZajBb6f0BAAD/dQj/RfzoCQUAAFmL2Ild7Gp4
68+AffsAfgTGReoBvzAsQQCATej/aiCNRZxqAFDo7Nr//4PEDIN9xHt1DoA/XXUJsl1HxkWn
IOsDilXLigc8XXRfRzwtdUGE0nQ9ig+A+V10Nkc60XMEisHrBIrCitE60HchD7bSD7bwK/JG
i8qLwoPhB7MBwegD0uONRAWcCBhCTnXoMtLrtA+2yIrQi8GD4QezAcHoA9LjjUQFnAgY65uA
PwAPhAEEAACDfcR7dQOJfQyLfQiLddT/TfxX/3XsiXXQ6FMEAABZWYN94AB0DotF9P9N9IXA
D4ScAAAA/0X8V+gaBAAAg/j/WYlF7HR+i8hqAYPhB1oPvl3o0+KLyMH5Aw++TA2cM8uF0XRg
gH3yAHVSgH3qAHRBiw0QKkEAiEXID7bA9kRBAYB0Df9F/FfoywMAAFmIRcn/NRwsQQCNRchQ
jUXCUOiqIAAAZotFwoPEDGaJBkZG6wOIBkaJddTpZP////9F0Olc/////038V1DoowMAAFlZ
OXXQD4QoAwAAgH3yAA+FfwIAAP9FzIN9xGMPhHICAACAfeoAi0XUdAlmgyAA6WACAACAIADp
WAIAAMZF8wGLXeyD+y11BsZF6QHrBYP7K3Ui/030dQyDfeAAdAbGRfEB6xH/dQj/RfzoGgMA
AFmL2Ild7IN90AAPhA8BAACAffEAD4XjAAAAg/54dU+DPRwsQQABfg9ogAAAAFPoVO7//1lZ
6w2hECpBAIoEWCWAAAAAhcAPhKMAAACLRdiLVdxqBFnozSAAAFOJRdiJVdzofQIAAIvYWYld
7OtTgz0cLEEAAX4MagRT6Aju//9ZWesLoRAqQQCKBFiD4ASFwHRdg/5vdRWD+zh9U4tF2ItV
3GoDWeh9IAAA6w9qAGoK/3Xc/3XY6CwgAACJRdiJVdz/ReSNQ9CZAUXYEVXcg33gAHQF/030
dCT/dQj/RfzoNgIAAIvYWYld7Okr/////3UI/038U+g5AgAAWVmAfekAD4TcAAAAi0XYi03c
99iD0QCJRdj32YlN3OnEAAAAgH3xAA+FsgAAAIP+eHQ/g/5wdDqDPRwsQQABfgxqBFPoQ+3/
/1lZ6wuhECpBAIoEWIPgBIXAdHaD/m91CoP7OH1swecD6z+NPL/R5+s4gz0cLEEAAX4PaIAA
AABT6Abt//9ZWesNoRAqQQCKBFglgAAAAIXAdDdTwecE6EQBAACL2FmJXez/ReSDfeAAjXwf
0HQF/030dCT/dQj/RfzoWAEAAIvYWYld7Olc/////3UI/038U+hbAQAAWVmAfekAdAL334P+
RnUEg2XkAIN95AAPhM4AAACAffIAdSn/RcyDfdAAdBCLRdSLTdiJCItN3IlIBOsQgH3zAItF
1HQEiTjrA2aJOP5F6/9FDIt1DOtC/0X8V+jhAAAAi9hZD7YGRjvDiV3siXUMdVWLDRAqQQAP
tsP2REEBgHQY/0X8V+i3AAAAWQ+2DkY7yIl1DHU+/038g33s/3UQgD4ldU2LRQyAeAFudUSL
8IoGhMAPhVb2///rMP91CP9N/P917OsF/038V1PoiwAAAFlZ6xf/TfxXUOh9AAAA/038V1Po
cwAAAIPEEIN97P91EYtFzIXAdQ04Ret1CIPI/+sDi0XMX15bycODPRwsQQABVn4Qi3QkCGoE
VuiO6///WVnrD4t0JAihECpBAIoEcIPgBIXAdQaD5t+D7geLxl7Di1QkBP9KBHgJiwoPtgFB
iQrDUugUHgAAWcODfCQE/3QP/3QkCP90JAjo1x4AAFlZw1aLdCQIV/90JBD/Bui+////i/hX
6D7i//9ZhcBZdeeLx19ew8zMzMzMzMzMjUL/W8ONpCQAAAAAjWQkADPAikQkCFOL2MHgCItU
JAj3wgMAAAB0E4oKQjjZdNGEyXRR98IDAAAAde0L2FeLw8HjEFYL2IsKv//+/n6LwYv3M8sD
8AP5g/H/g/D/M88zxoPCBIHhAAEBgXUcJQABAYF00yUAAQEBdQiB5gAAAIB1xF5fWzPAw4tC
/DjYdDaEwHTvONx0J4TkdOfB6BA42HQVhMB03DjcdAaE5HTU65ZeX41C/1vDjUL+Xl9bw41C
/V5fW8ONQvxeX1vDoTRMSQCFwHQC/9BoFPBAAGgI8EAA6M4AAABoBPBAAGgA8EAA6L8AAACD
xBDDagBqAP90JAzoFQAAAIPEDMNqAGoB/3QkDOgEAAAAg8QMw1dqAV85PZw5SQB1Ef90JAj/
FazQQABQ/xUo0UAAg3wkDABTi1wkFIk9mDlJAIgdlDlJAHU8oTBMSQCFwHQiiw0sTEkAVo1x
/DvwchOLBoXAdAL/0IPuBDs1MExJAHPtXmgg8EAAaBjwQADoKgAAAFlZaCjwQABoJPBAAOgZ
AAAAWVmF21t1EP90JAiJPZw5SQD/FXzRQABfw1aLdCQIO3QkDHMNiwaFwHQC/9CDxgTr7V7D
VYvsU/91COg1AQAAhcBZD4QgAQAAi1gIhdsPhBUBAACD+wV1DINgCABqAVjpDQEAAIP7AQ+E
9gAAAIsNoDlJAIlNCItNDIkNoDlJAItIBIP5CA+FyAAAAIsNuCxBAIsVvCxBAAPRVjvKfRWN
NEkr0Y00tUgsQQCDJgCDxgxKdfeLAIs1xCxBAD2OAADAdQzHBcQsQQCDAAAA63A9kAAAwHUM
xwXELEEAgQAAAOtdPZEAAMB1DMcFxCxBAIQAAADrSj2TAADAdQzHBcQsQQCFAAAA6zc9jQAA
wHUMxwXELEEAggAAAOskPY8AAMB1DMcFxCxBAIYAAADrET2SAADAdQrHBcQsQQCKAAAA/zXE
LEEAagj/01mJNcQsQQBZXusIg2AIAFH/01mLRQijoDlJAIPI/+sJ/3UM/xWY0UAAW13Di1Qk
BIsNwCxBADkVQCxBAFa4QCxBAHQVjTRJjTS1QCxBAIPADDvGcwQ5EHX1jQxJXo0MjUAsQQA7
wXMEORB0AjPAw4M9KExJAAB1Bei75P//Vos1aE5JAIoGPCJ1JYpGAUY8InQVhMB0EQ+2wFDo
lBsAAIXAWXTmRuvjgD4idQ1G6wo8IHYGRoA+IHf6igaEwHQEPCB26YvGXsNTM9s5HShMSQBW
V3UF6F/k//+LNSA5SQAz/4oGOsN0Ejw9dAFHVugr0///WY10BgHr6I0EvQQAAABQ6Orw//+L
8Fk784k1fDlJAHUIagnoEeD//1mLPSA5SQA4H3Q5VVfo8dL//4voWUWAPz10IlXotfD//zvD
WYkGdQhqCeji3///WVf/Nujb0f//WYPGBFkD/Tgfdcld/zUgOUkA6Fjw//9ZiR0gOUkAiR5f
XscFJExJAAEAAABbw1WL7FFRUzPbOR0oTEkAVld1Beih4///vqQ5SQBoBAEAAFZT/xUU0UAA
oWhOSQCJNYw5SQCL/jgYdAKL+I1F+FCNRfxQU1NX6E0AAACLRfiLTfyNBIhQ6BXw//+L8IPE
GDvzdQhqCOhA3///WY1F+FCNRfxQi0X8jQSGUFZX6BcAAACLRfyDxBRIiTV0OUkAX16jcDlJ
AFvJw1WL7ItNGItFFFNWgyEAi3UQV4t9DMcAAQAAAItFCIX/dAiJN4PHBIl9DIA4InVEilAB
QID6InQphNJ0JQ+20vaCYU1JAAR0DP8BhfZ0BooQiBZGQP8BhfZ01YoQiBZG687/AYX2dASA
JgBGgDgidUZA60P/AYX2dAWKEIgWRooQQA+22vaDYU1JAAR0DP8BhfZ0BYoYiB5GQID6IHQJ
hNJ0CYD6CXXMhNJ1A0jrCIX2dASAZv8Ag2UYAIA4AA+E4AAAAIoQgPogdAWA+gl1A0Dr8YA4
AA+EyAAAAIX/dAiJN4PHBIl9DItVFP8Cx0UIAQAAADPbgDhcdQRAQ+v3gDgidSz2wwF1JTP/
OX0YdA2AeAEijVABdQSLwusDiX0Ii30MM9I5VRgPlMKJVRjR64vTS4XSdA5DhfZ0BMYGXEb/
AUt184oQhNJ0SoN9GAB1CoD6IHQ/gPoJdDqDfQgAdC6F9nQZD7ba9oNhTUkABHQGiBZGQP8B
ihCIFkbrDw+20vaCYU1JAAR0A0D/Af8BQOlY////hfZ0BIAmAEb/AekX////hf90A4MnAItF
FF9eW/8AXcNRUaGoOkkAU1WLLajRQABWVzPbM/Yz/zvDdTP/1YvwO/N0DMcFqDpJAAEAAADr
KP8VpNFAAIv4O/sPhOoAAADHBag6SQACAAAA6Y8AAACD+AEPhYEAAAA783UM/9WL8DvzD4TC
AAAAZjkei8Z0DkBAZjkYdflAQGY5GHXyK8aLPaDQQADR+FNTQFNTUFZTU4lEJDT/14voO+t0
MlXogu3//zvDWYlEJBB0I1NTVVD/dCQkVlNT/9eFwHUO/3QkEOgw7f//WYlcJBCLXCQQVv8V
oNFAAIvD61OD+AJ1TDv7dQz/FaTRQACL+Dv7dDw4H4vHdApAOBh1+0A4GHX2K8dAi+hV6Bvt
//+L8Fk783UEM/brC1VXVuj10v//g8QMV/8VnNFAAIvG6wIzwF9eXVtZWcOD7ERTVVZXaAAB
AADo4Oz//4vwWYX2dQhqG+gN3P//WYk1IEtJAMcFIExJACAAAACNhgABAAA78HMagGYEAIMO
/8ZGBQqhIEtJAIPGCAUAAQAA6+KNRCQQUP8VeNFAAGaDfCRCAA+ExQAAAItEJESFwA+EuQAA
AIswjWgEuAAIAAA78I0cLnwCi/A5NSBMSQB9Ur8kS0kAaAABAADoUOz//4XAWXQ4gwUgTEkA
IIkHjYgAAQAAO8FzGIBgBACDCP/GQAUKiw+DwAiBwQABAADr5IPHBDk1IExJAHy76waLNSBM
SQAz/4X2fkaLA4P4/3Q2ik0A9sEBdC72wQh1C1D/FWzRQACFwHQei8eLz8H4BYPhH4sEhSBL
SQCNBMiLC4kIik0AiEgER0WDwwQ7/ny6M9uhIEtJAIM82P+NNNh1TYXbxkYEgXUFavZY6wqL
w0j32BvAg8D1UP8VcNFAAIv4g///dBdX/xVs0UAAhcB0DCX/AAAAiT6D+AJ1BoBOBEDrD4P4
A3UKgE4ECOsEgE4EgEOD+wN8m/81IExJAP8VjNFAAF9eXVuDxETDM8BqADlEJAhoABAAAA+U
wFD/FWTRQACFwKMES0kAdBXogwoAAIXAdQ//NQRLSQD/FWjRQAAzwMNqAVjDzMzMVYvsU1ZX
VWoAagBoJKtAAP91COieHAAAXV9eW4vlXcOLTCQE90EEBgAAALgBAAAAdA+LRCQIi1QkEIkC
uAMAAADDU1ZXi0QkEFBq/mgsq0AAZP81AAAAAGSJJQAAAACLRCQgi1gIi3AMg/7/dC47dCQk
dCiNNHaLDLOJTCQIiUgMg3yzBAB1EmgBAQAAi0SzCOhAAAAA/1SzCOvDZI8FAAAAAIPEDF9e
W8MzwGSLDQAAAACBeQQsq0AAdRCLUQyLUgw5UQh1BbgBAAAAw1NRu9QsQQDrClNRu9QsQQCL
TQiJSwiJQwSJawxZW8IEAMzMVkMyMFhDMDBVi+yD7AhTVldV/ItdDItFCPdABAYAAAAPhYIA
AACJRfiLRRCJRfyNRfiJQ/yLcwyLewiD/v90YY0MdoN8jwQAdEVWVY1rEP9UjwRdXotdDAvA
dDN4PIt7CFPoqf7//4PEBI1rEFZT6N7+//+DxAiNDHZqAYtEjwjoYf///4sEj4lDDP9UjwiL
ewiNDHaLNI/robgAAAAA6xy4AQAAAOsVVY1rEGr/U+ie/v//g8QIXbgBAAAAXV9eW4vlXcNV
i0wkCIspi0EcUItBGFDoef7//4PECF3CBAChKDlJAIP4AXQNhcB1KoM9FClBAAF1IWj8AAAA
6BgAAAChrDpJAFmFwHQC/9Bo/wAAAOgCAAAAWcNVi+yB7KQBAACLVQgzybjoLEEAOxB0C4PA
CEE9eC1BAHzxVovxweYDO5boLEEAD4UcAQAAoSg5SQCD+AEPhOgAAACFwHUNgz0UKUEAAQ+E
1wAAAIH6/AAAAA+E8QAAAI2FXP7//2gEAQAAUGoA/xUU0UAAhcB1E42FXP7//2i81UAAUOiz
yf//WVmNhVz+//9XUI29XP7//+iOyv//QFmD+Dx2KY2FXP7//1Doe8r//4v4jYVc/v//g+g7
agMD+Gi41UAAV+jhAQAAg8QQjYVg////aJzVQABQ6F3J//+NhWD///9XUOhgyf//jYVg////
aJjVQABQ6E/J////tuwsQQCNhWD///9Q6D3J//9oECABAI2FYP///2hw1UAAUOhfEgAAg8Qs
X+smjUUIjbbsLEEAagBQ/zbo7sn//1lQ/zZq9P8VcNFAAFD/FWzQQABeycNVi+xq/2jY1UAA
aASsQABkoQAAAABQZIklAAAAAIPsGFNWV4ll6KGwOkkAM9s7w3U+jUXkUGoBXlZoUNJAAFb/
FVTRQACFwHQEi8brHY1F5FBWaEzSQABWU/8VWNFAAIXAD4TOAAAAagJYo7A6SQCD+AJ1JItF
HDvDdQWhPDlJAP91FP91EP91DP91CFD/FVjRQADpnwAAAIP4AQ+FlAAAADldGHUIoUw5SQCJ
RRhTU/91EP91DItFIPfYG8CD4AhAUP91GP8VeNBAAIlF4DvDdGOJXfyNPACLx4PAAyT86BTQ
//+JZeiL9Il13FdTVuiUx///g8QM6wtqAVjDi2XoM9sz9oNN/P8783Qp/3XgVv91EP91DGoB
/3UY/xV40EAAO8N0EP91FFBW/3UI/xVU0UAA6wIzwI1lzItN8GSJDQAAAABfXlvJw8zMzMzM
zMzMzMzMzMzMzItMJAxXhcl0elZTi9mLdCQU98YDAAAAi3wkEHUHwekCdW/rIYoGRogHR0l0
JYTAdCn3xgMAAAB164vZwekCdVGD4wN0DYoGRogHR4TAdC9LdfOLRCQQW15fw/fHAwAAAHQS
iAdHSQ+EigAAAPfHAwAAAHXui9nB6QJ1bIgHR0t1+ltei0QkCF/DiReDxwRJdK+6//7+fosG
A9CD8P8zwosWg8YEqQABAYF03oTSdCyE9nQe98IAAP8AdAz3wgAAAP91xokX6xiB4v//AACJ
F+sOgeL/AAAAiRfrBDPSiReDxwQzwEl0CjPAiQeDxwRJdfiD4wN1hYtEJBBbXl/Di0QkBFM7
BSBMSQBWV3Nzi8iL8MH5BYPmH408jSBLSQDB5gOLD/ZEMQQBdFZQ6BIRAACD+P9ZdQzHBVQ5
SQAJAAAA60//dCQYagD/dCQcUP8V5NBAAIvYg/v/dQj/FeDQQADrAjPAhcB0CVDo8w8AAFnr
IIsHgGQwBP2NRDAEi8PrFIMlWDlJAADHBVQ5SQAJAAAAg8j/X15bw1WL7IHsFAQAAItNCFM7
DSBMSQBWVw+DeQEAAIvBi/HB+AWD5h+NHIUgS0kAweYDiwOKRDAEqAEPhFcBAAAz/zl9EIl9
+Il98HUHM8DpVwEAAKggdAxqAldR6Aj///+DxAyLAwPG9kAEgA+EwQAAAItFDDl9EIlF/Il9
CA+G5wAAAI2F7Pv//4tN/CtNDDtNEHMpi038/0X8igmA+Qp1B/9F8MYADUCICECLyI2V7Pv/
/yvKgfkABAAAfMyL+I2F7Pv//yv4jUX0agBQjYXs+///V1CLA/80MP8VbNBAAIXAdEOLRfQB
Rfg7x3wLi0X8K0UMO0UQcooz/4tF+DvHD4WLAAAAOX0IdF9qBVg5RQh1TMcFVDlJAAkAAACj
WDlJAOmAAAAA/xXg0EAAiUUI68eNTfRXUf91EP91DP8w/xVs0EAAhcB0C4tF9Il9CIlF+Oun
/xXg0EAAiUUI65z/dQjoZA4AAFnrPYsD9kQwBEB0DItFDIA4Gg+Ezf7//8cFVDlJABwAAACJ
PVg5SQDrFitF8OsUgyVYOUkAAMcFVDlJAAkAAACDyP9fXlvJw/8FtDpJAGgAEAAA6P7i//9Z
i0wkBIXAiUEIdA2DSQwIx0EYABAAAOsRg0kMBI1BFIlBCMdBGAIAAACLQQiDYQQAiQHDi0Qk
BDsFIExJAHIDM8DDi8iD4B/B+QWLDI0gS0kAikTBBIPgQMOhAEtJAFZqFIXAXnUHuAACAADr
BjvGfQeLxqMAS0kAagRQ6KkOAABZo+Q6SQCFwFl1IWoEVok1AEtJAOiQDgAAWaPkOkkAhcBZ
dQhqGuiN0f//WTPJuIAtQQCLFeQ6SQCJBBGDwCCDwQQ9ADBBAHzqM9K5kC1BAIvCi/LB+AWD
5h+LBIUgS0kAiwTwg/j/dASFwHUDgwn/g8EgQoH58C1BAHzUXsPokg8AAIA9lDlJAAB0BemV
DgAAw1WL7ItFCIXAdQJdw4M9PDlJAAB1EmaLTQxmgfn/AHc5agGICFhdw41NCINlCABRagD/
NRwsQQBQjUUMagFQaCACAAD/NUw5SQD/FaDQQACFwHQGg30IAHQNxwVUOUkAKgAAAIPI/13D
U1aLRCQYC8B1GItMJBSLRCQQM9L38YvYi0QkDPfxi9PrQYvIi1wkFItUJBCLRCQM0enR29Hq
0dgLyXX09/OL8PdkJBiLyItEJBT35gPRcg47VCQQdwhyBztEJAx2AU4z0ovGXlvCEADMzMzM
zMzMzFOLRCQUC8B1GItMJBCLRCQMM9L38YtEJAj38YvCM9LrUIvIi1wkEItUJAyLRCQI0enR
29Hq0dgLyXX09/OLyPdkJBSR92QkEAPRcg47VCQMdwhyDjtEJAh2CCtEJBAbVCQUK0QkCBtU
JAz32vfYg9oAW8IQAGhAAQAAagD/NQRLSQD/FZTRQACFwKPgOkkAdQHDgyXYOkkAAIMl3DpJ
AABqAaPUOkkAxwXMOkkAEAAAAFjDodw6SQCNDICh4DpJAI0MiDvBcxSLVCQEK1AMgfoAABAA
cgeDwBTr6DPAw1WL7IPsFItVDItNCFNWi0EQi/IrcQyLWvyDwvxXwe4Pi86LevxpyQQCAABL
iX38jYwBRAEAAIld9IlN8IsME/bBAYlN+HV/wfkEaj9JX4lNDDvPdgOJfQyLTBMEO0wTCHVI
i00Mg/kgcxy/AAAAgNPvjUwBBPfXIXywRP4JdSuLTQghOeskg8HgvwAAAIDT74tNDI1MAQT3
1yG8sMQAAAD+CXUGi00IIXkEi0wTCIt8EwSJeQSLTBMEi3wTCANd+Il5CIld9Iv7wf8ET4P/
P3YDaj9fi038g+EBiU3sD4WgAAAAK1X8i038wfkEaj+JVfhJWjvKiU0MdgWJVQyLygNd/Iv7
iV30wf8ETzv6dgKL+jvPdGuLTfiLUQQ7UQh1SItNDIP5IHMcugAAAIDT6o1MAQT30iFUsET+
CXUri00IIRHrJIPB4LoAAACA0+qLTQyNTAEE99IhlLDEAAAA/gl1BotNCCFRBItN+ItRCItJ
BIlKBItN+ItRBItJCIlKCItV+IN97AB1CTl9DA+EiQAAAItN8I0M+YtJBIlKBItN8I0M+YlK
CIlRBItKBIlRCItKBDtKCHVjikwHBIP/IIhND/7BiEwHBHMlgH0PAHUOuwAAAICLz9Pri00I
CRm7AAAAgIvP0+uNRLBECRjrKYB9DwB1EI1P4LsAAACA0+uLTQgJWQSNT+C/AAAAgNPvjYSw
xAAAAAk4i130i0XwiRqJXBP8/wgPhfoAAACh2DpJAIXAD4TfAAAAiw3QOkkAiz1g0UAAweEP
A0gMuwCAAABoAEAAAFNR/9eLDdA6SQCh2DpJALoAAACA0+oJUAih2DpJAIsN0DpJAItAEIOk
iMQAAAAAodg6SQCLQBD+SEOh2DpJAItIEIB5QwB1CYNgBP6h2DpJAIN4CP91bFNqAP9wDP/X
odg6SQD/cBBqAP81BEtJAP8VkNFAAKHcOkkAixXgOkkAjQSAweACi8ih2DpJACvIjUwR7FGN
SBRRUOgPx///i0UIg8QM/w3cOkkAOwXYOkkAdgOD6BSLDeA6SQCJDdQ6SQDrA4tFCKPYOkkA
iTXQOkkAX15bycNVi+yD7BSh3DpJAIsV4DpJAFNWjQSAV408gotFCIl9/I1IF4Ph8IlN8MH5
BEmD+SB9DoPO/9Pug034/4l19OsQg8Hgg8j/M/bT6Il19IlF+KHUOkkAi9g734ldCHMZi0sE
izsjTfgj/gvPdQuDwxQ7XfyJXQhy5ztd/HV5i9o72IldCHMVi0sEizsjTfgj/gvPdQWDwxTr
5jvYdVk7XfxzEYN7CAB1CIPDFIldCOvtO138dSaL2jvYiV0Icw2DewgAdQWDwxTr7jvYdQ7o
OAIAAIvYhduJXQh0FFPo2gIAAFmLSxCJAYtDEIM4/3UHM8DpDwIAAIkd1DpJAItDEIsQg/r/
iVX8dBSLjJDEAAAAi3yQRCNN+CP+C891N4uQxAAAAItwRCNV+CN19INl/ACNSEQL1ot19HUX
i5GEAAAA/0X8I1X4g8EEi/4jOQvXdOmLVfyLyjP/ackEAgAAjYwBRAEAAIlN9ItMkEQjznUN
i4yQxAAAAGogI034X4XJfAXR4Ufr94tN9ItU+QSLCitN8IvxiU34wf4EToP+P34Daj9eO/cP
hA0BAACLSgQ7Sgh1YYP/IH0ruwAAAICLz9Pri038jXw4BPfTiV3sI1yIRIlciET+D3U4i10I
i03sIQvrMY1P4LsAAACA0+uLTfyNfDgEjYyIxAAAAPfTIRn+D4ld7HULi10Ii03sIUsE6wOL
XQiLSgiLegSDffgAiXkEi0oEi3oIiXkID4SUAAAAi030i3zxBI0M8Yl6BIlKCIlRBItKBIlR
CItKBDtKCHVkikwGBIP+IIhNC30p/sGAfQsAiEwGBHULvwAAAICLztPvCTu/AAAAgIvO0++L
TfwJfIhE6y/+wYB9CwCITAYEdQ2NTuC/AAAAgNPvCXsEi038jbyIxAAAAI1O4L4AAACA0+4J
N4tN+IXJdAuJColMEfzrA4tN+It18APRjU4BiQqJTDL8i3X0iw6FyY15AYk+dRo7Hdg6SQB1
EotN/DsN0DpJAHUHgyXYOkkAAItN/IkIjUIEX15bycOh3DpJAIsNzDpJAFZXM/87wXUwjUSJ
UMHgAlD/NeA6SQBX/zUES0kA/xVM0UAAO8d0YYMFzDpJABCj4DpJAKHcOkkAiw3gOkkAaMRB
AABqCI0EgP81BEtJAI00gf8VlNFAADvHiUYQdCpqBGgAIAAAaAAAEABX/xVQ0UAAO8eJRgx1
FP92EFf/NQRLSQD/FZDRQAAzwOsXg04I/4k+iX4E/wXcOkkAi0YQgwj/i8ZfXsNVi+xRi00I
U1ZXi3EQi0EIM9uFwHwF0eBD6/eLw2o/acAEAgAAWo2EMEQBAACJRfyJQAiJQASDwAhKdfSL
+2oEwecPA3kMaAAQAABoAIAAAFf/FVDRQACFwHUIg8j/6ZMAAACNlwBwAAA7+nc8jUcQg0j4
/4OI7A8AAP+NiPwPAADHQPzwDwAAiQiNiPzv//+JSATHgOgPAADwDwAABQAQAACNSPA7ynbH
i0X8jU8MBfgBAABqAV+JSASJQQiNSgyJSAiJQQSDZJ5EAIm8nsQAAACKRkOKyP7BhMCLRQiI
TkN1Awl4BLoAAACAi8vT6vfSIVAIi8NfXlvJw6G8OkkAhcB0D/90JAT/0IXAWXQEagFYwzPA
w1WL7FNWi3UMM9s783QVOV0QdBCKBjrDdRCLRQg7w3QDZokYM8BeW13DOR08OUkAdROLTQg7
y3QHZg+2wGaJAWoBWOvhiw0QKkEAD7bA9kRBAYB0TaEcLEEAg/gBfio5RRB8LzPJOV0ID5XB
Uf91CFBWagn/NUw5SQD/FXjQQACFwKEcLEEAdZ05RRByBTheAXWTxwVUOUkAKgAAAIPI/+uE
M8A5XQgPlcBQ/3UIagFWagn/NUw5SQD/FXjQQACFwA+Fef///+vKzMzMzMzMzMzMzMzMzMzM
i0QkCItMJBALyItMJAx1CYtEJAT34cIQAFP34YvYi0QkCPdkJBQD2ItEJAj34QPTW8IQAMzM
zMzMzMzMzMzMzID5QHMVgPkgcwYPpcLT4MOL0DPAgOEf0+LDM8Az0sNWi3QkCItGDKiDD4TE
AAAAqEAPhbwAAACoAnQKDCCJRgzprgAAAAwBZqkMAYlGDHUJVui/8///WesFi0YIiQb/dhj/
dgj/dhDozgQAAIPEDIlGBIXAdGyD+P90Z4tWDPbCgnU0i04QV4P5/3QUi/nB/wWD4R+LPL0g
S0kAjTzP6wW/yCxBAIpPBF+A4YKA+YJ1BoDOIIlWDIF+GAACAAB1FItODPbBCHQM9sUEdQfH
RhgAEAAAiw5IiUYED7YBQYkOXsP32BvAg+AQg8AQCUYMg2YEAIPI/17DU4tcJAiD+/9WdEGL
dCQQi0YMqAF1CKiAdDKoAnUug34IAHUHVujz8v//WYsGO0YIdQmDfgQAdRRAiQb2RgxAdBH/
DosGOBh0D0CJBoPI/15bw/8OiwaIGItGDP9GBCTvDAGJRgyLwyX/AAAA6+FqBGoA/3QkDOgE
AAAAg8QMww+2RCQEikwkDISIYU1JAHUcg3wkCAB0Dg+3BEUaKkEAI0QkCOsCM8CFwHUBw2oB
WMNTM9s5HcA6SQBWV3VCaBTWQAD/FfTQQACL+Dv7dGeLNTjRQABoCNZAAFf/1oXAo8A6SQB0
UGj41UAAV//WaOTVQABXo8Q6SQD/1qPIOkkAocQ6SQCFwHQW/9CL2IXbdA6hyDpJAIXAdAVT
/9CL2P90JBj/dCQY/3QkGFP/FcA6SQBfXlvDM8Dr+ItMJAQz0okNWDlJALgwMEEAOwh0IIPA
CEI9mDFBAHzxg/kTch2D+SR3GMcFVDlJAA0AAADDiwTVNDBBAKNUOUkAw4H5vAAAAHISgfnK
AAAAxwVUOUkACAAAAHYKxwVUOUkAFgAAAMOLTCQEVjsNIExJAFdzVYvBi/HB+AWD5h+NPIUg
S0kAweYDiwcDxvZABAF0N4M4/3Qygz0UKUEAAXUfM8AryHQQSXQISXUTUGr06whQavXrA1Bq
9v8VSNFAAIsHgwww/zPA6xSDJVg5SQAAxwVUOUkACQAAAIPI/19ew4tEJAQ7BSBMSQBzHIvI
g+AfwfkFiwyNIEtJAPZEwQQBjQTBdAOLAMODJVg5SQAAxwVUOUkACQAAAIPI/8NTVot0JAxX
D690JBSD/uCL3ncNhfZ1A2oBXoPGD4Pm8DP/g/7gdyo7HSAwQQB3DVPolfb//4v4WYX/dStW
agj/NQRLSQD/FZTRQACL+IX/dSKDPbg6SQAAdBlW6B/7//+FwFl0FOu5U2oAV+hBtP//g8QM
i8dfXlvDM8Dr+FZXagMz/145NQBLSQB+RKHkOkkAiwSwhcB0L/ZADIN0DVDoPQMAAIP4/1l0
AUeD/hR8F6HkOkkA/zSw6OjS//+h5DpJAFmDJLAARjs1AEtJAHy8i8dfXsNWi3QkCIX2dQlW
6JEAAABZXsNW6CMAAACFwFl0BYPI/17D9kYNQHQP/3YQ6DIDAAD32FleG8DDM8Bew1NWi3Qk
DDPbV4tGDIvIg+EDgPkCdTdmqQgBdDGLRgiLPiv4hf9+JldQ/3YQ6Njt//+DxAw7x3UOi0YM
qIB0DiT9iUYM6weDTgwgg8v/i0YIg2YEAIkGX4vDXlvDagHoAgAAAFnDU1ZXM/Yz2zP/OTUA
S0kAfk2h5DpJAIsEsIXAdDiLSAz2wYN0MIN8JBABdQ9Q6C7///+D+P9ZdB1D6xqDfCQQAHUT
9sECdA5Q6BP///+D+P9ZdQIL+EY7NQBLSQB8s4N8JBABi8N0AovHX15bw2oC6CbB//9Zw1WL
7IPsDFNWi3UIVzs1IExJAA+DxQEAAIvGg+YfwfgFweYDjRyFIEtJAIsEhSBLSQADxopQBPbC
AQ+EngEAAINl+ACLfQyDfRAAi890Z/bCAnVi9sJIdB2KQAU8CnQW/00QiAeLA41PAcdF+AEA
AADGRDAFCo1F9GoAUIsD/3UQUf80MP8VcNBAAIXAdTr/FeDQQABqBVk7wXUVxwVUOUkACQAA
AIkNWDlJAOk+AQAAg/htdQczwOk1AQAAUOg1/P//WekmAQAAiwOLVfQBVfiNTDAEikQwBKiA
D4T4AAAAhdJ0CYA/CnUEDATrAiT7iAGLRQyLTfiJRRADyDvBiU34D4PLAAAAi0UQigA8Gg+E
rgAAADwNdAuIB0f/RRDpkQAAAEk5TRBzGItFEECAOAp1BoNFEALrXsYHDUeJRRDrc41F9GoA
UP9FEI1F/2oBUIsD/zQw/xVw0EAAhcB1Cv8V4NBAAIXAdUeDffQAdEGLA/ZEMARIdBOKRf88
CnQXxgcNiwtHiEQxBespO30MdQuAff8KdQXGBwrrGGoBav//dQjo7er//4PEDIB9/wp0BMYH
DUeLTfg5TRAPgkf////rEIsDjXQwBIoGqEB1BAwCiAYrfQyJffiLRfjrFIMlWDlJAADHBVQ5
SQAJAAAAg8j/X15bycNWi3QkCFeDz/+LRgyoQHQFg8j/6zqog3Q0VugQ/f//Vov46DkBAAD/
dhDofgAAAIPEDIXAfQWDz//rEotGHIXAdAtQ6HzP//+DZhwAWYvHg2YMAF9ew4tEJAQ7BSBM
SQBzPYvIi9DB+QWD4h+LDI0gS0kA9kTRBAF0JVDoYvv//1lQ/xVE0UAAhcB1CP8V4NBAAOsC
M8CFwHQSo1g5SQDHBVQ5SQAJAAAAg8j/w1NVVleLfCQUOz0gTEkAD4OGAAAAi8eL98H4BYPm
H40chSBLSQDB5gOLA/ZEMAQBdGlX6P76//+D+P9ZdDyD/wF0BYP/AnUWagLo5/r//2oBi+jo
3vr//1k7xVl0HFfo0vr//1lQ/xUk0UAAhcB1Cv8V4NBAAIvo6wIz7VfoOvr//4sDWYBkMAQA
he10CVXowfn//1nrFTPA6xSDJVg5SQAAxwVUOUkACQAAAIPI/19eXVvDVot0JAiLRgyog3Qd
qAh0Gf92COhMzv//ZoFmDPf7M8BZiQaJRgiJRgRew8zMzMzM/yW40UAA/yW00UAA/yWw0UAA
/yVc0UAAVYvsUaE8OUkAUzPbO8OJXfx1IYtFCIvQOBh0f4oKgPlhfAqA+Xp/BYDpIIgKQjga
derrZ1ZXagFTU1Nq/74AAgAA/3UIVlDo7cH//4v4g8QgO/t0OFfo8M3//zvDWYlF/HQqagFT
V1Bq//91CFb/NTw5SQDowMH//4PEIIXAdA3/dfz/dQjo/a7//1lZ/3X86IfN//+LRQhZX15b
ycPMzMzMzMzMzMzMVYvsV1ZTi00QC8kPhJUAAACLdQiLfQyNBTQ5SQCDeAgAdUO3QbNatiCN
SQCKJgrkigd0IQrAdB1GRzj8cgY43HcCAuY4+HIGONh3AgLGOMR1CUl11zPJOMR0S7n/////
ckT32etAM8Az24v/igYLwIofdCML23QfRkdRUFPo3LH//4vYg8QE6NKx//+DxARZO8N1CUl1
1TPJO8N0Cbn/////cgL32YvBW15fycPMzMxVi+xXVlOLdQyLfQiNBTQ5SQCDeAgAdTuw/4v/
CsB0LooGRoonRzjEdPIsQTwaGsmA4SACwQRBhuAsQTwaGsmA4SACwQRBOOB00hrAHP8PvsDr
NLj/AAAAM9uL/wrAdCeKBkaKH0c42HTyUFPoPbH//4vYg8QE6DOx//+DxAQ4w3TaG8CD2P9b
Xl/Jw1WL7FGhPDlJAFMz2zvDiV38dSGLRQiL0DgYdH+KCoD5QXwKgPlafwWAwSCICkI4GnXq
62dWV2oBU1NTav++AAEAAP91CFZQ6AnA//+L+IPEIDv7dDhX6AzM//87w1mJRfx0KmoBU1dQ
av//dQhW/zU8OUkA6Ny///+DxCCFwHQN/3X8/3UI6Bmt//9ZWf91/Oijy///i0UIWV9eW8nD
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAJbcAACo3AAA2N0AAMDdAACe3QAAit0AALDdAABk3QAAUN0AAHrdAAAe3QAAEt0AADrd
AADq3AAA2twAAAjdAABu3AAAXtwAAITcAAA+3AAAMNwAAEzcAADG3AAAItwAAAAAAAAg2gAA
QNoAAFLaAABe2gAAatoAAAraAAA02gAAnNoAALLaAAC+2gAAztoAAODaAADQ2QAAftoAAI7a
AAD02QAALtsAAEDbAABW2wAAatsAAILbAACS2wAAotsAALDbAADG2wAA2NsAAPTbAAAE3AAA
3tkAAKTZAADE2QAAtNkAAPDaAAAC2wAAdtkAAHDYAACQ2AAAktkAAITZAAA+2QAAYNkAAFDZ
AAD82AAALtkAABjZAADK2AAA7NgAAN7YAACg2AAAttgAAK7YAAAQ2wAAHtsAAH7YAACs3gAA
nN4AAA7gAAD+3wAA8N8AAODfAADO3wAAvN8AALDfAACi3wAAlN8AAIbfAAB43wAAaN8AAEbe
AABa3gAAbN4AAHreAACG3gAAkN4AAFbfAAC83gAAyN4AANTeAADw3gAACt8AACTfAAA83wAA
AAAAAC7eAAAa3gAACt4AAAAAAAA0AACAAwAAgHQAAIAQAACAEwAAgAkAAIAEAACAbwAAgHMA
AIAXAACAAAAAAAAAAAAAAAAABQAAAAAAAAAHAAAACQAAAAUAAAACAAAAAgAAAAIAAAACAAAA
DAAZAAEAAQACAA4ACgAfAAQAAQADABkACAAPAAIAAgALAAIAAQAGAP////8vhUAAQ4VAAAAA
AAAAAAAAAAAAAP////8Ri0AAFYtAAP/////Fi0AAyYtAAAYAAAYAAQAAEAADBgAGAhAERUVF
BQUFBQU1MABQAAAAACAoOFBYBwgANzAwV1AHAAAgIAgAAAAACGBoYGBgYAAAcHB4eHh4CAcI
AAAHAAgICAAACAAIAAcIAAAAKABuAHUAbABsACkAAAAAAChudWxsKQAAcnVudGltZSBlcnJv
ciAAAA0KAABUTE9TUyBlcnJvcg0KAAAAU0lORyBlcnJvcg0KAAAAAERPTUFJTiBlcnJvcg0K
AABSNjAyOA0KLSB1bmFibGUgdG8gaW5pdGlhbGl6ZSBoZWFwDQoAAAAAUjYwMjcNCi0gbm90
IGVub3VnaCBzcGFjZSBmb3IgbG93aW8gaW5pdGlhbGl6YXRpb24NCgAAAABSNjAyNg0KLSBu
b3QgZW5vdWdoIHNwYWNlIGZvciBzdGRpbyBpbml0aWFsaXphdGlvbg0KAAAAAFI2MDI1DQot
IHB1cmUgdmlydHVhbCBmdW5jdGlvbiBjYWxsDQoAAABSNjAyNA0KLSBub3QgZW5vdWdoIHNw
YWNlIGZvciBfb25leGl0L2F0ZXhpdCB0YWJsZQ0KAAAAAFI2MDE5DQotIHVuYWJsZSB0byBv
cGVuIGNvbnNvbGUgZGV2aWNlDQoAAAAAUjYwMTgNCi0gdW5leHBlY3RlZCBoZWFwIGVycm9y
DQoAAAAAUjYwMTcNCi0gdW5leHBlY3RlZCBtdWx0aXRocmVhZCBsb2NrIGVycm9yDQoAAAAA
UjYwMTYNCi0gbm90IGVub3VnaCBzcGFjZSBmb3IgdGhyZWFkIGRhdGENCgANCmFibm9ybWFs
IHByb2dyYW0gdGVybWluYXRpb24NCgAAAABSNjAwOQ0KLSBub3QgZW5vdWdoIHNwYWNlIGZv
ciBlbnZpcm9ubWVudA0KAFI2MDA4DQotIG5vdCBlbm91Z2ggc3BhY2UgZm9yIGFyZ3VtZW50
cw0KAAAAUjYwMDINCi0gZmxvYXRpbmcgcG9pbnQgbm90IGxvYWRlZA0KAAAAAE1pY3Jvc29m
dCBWaXN1YWwgQysrIFJ1bnRpbWUgTGlicmFyeQAAAAAKCgAAUnVudGltZSBFcnJvciEKClBy
b2dyYW06IAAAAC4uLgA8cHJvZ3JhbSBuYW1lIHVua25vd24+AAAAAAAA/////2GvQABlr0AA
R2V0TGFzdEFjdGl2ZVBvcHVwAABHZXRBY3RpdmVXaW5kb3cATWVzc2FnZUJveEEAdXNlcjMy
LmRsbAAA6NYAAAAAAAAAAAAAFNwAAGTQAACE1gAAAAAAAAAAAADw3QAAANAAAETYAAAAAAAA
AAAAAP7dAADA0QAANNgAAAAAAAAAAAAAPt4AALDRAAAAAAAAAAAAAAAAAAAAAAAAAAAAAJbc
AACo3AAA2N0AAMDdAACe3QAAit0AALDdAABk3QAAUN0AAHrdAAAe3QAAEt0AADrdAADq3AAA
2twAAAjdAABu3AAAXtwAAITcAAA+3AAAMNwAAEzcAADG3AAAItwAAAAAAAAg2gAAQNoAAFLa
AABe2gAAatoAAAraAAA02gAAnNoAALLaAAC+2gAAztoAAODaAADQ2QAAftoAAI7aAAD02QAA
LtsAAEDbAABW2wAAatsAAILbAACS2wAAotsAALDbAADG2wAA2NsAAPTbAAAE3AAA3tkAAKTZ
AADE2QAAtNkAAPDaAAAC2wAAdtkAAHDYAACQ2AAAktkAAITZAAA+2QAAYNkAAFDZAAD82AAA
LtkAABjZAADK2AAA7NgAAN7YAACg2AAAttgAAK7YAAAQ2wAAHtsAAH7YAACs3gAAnN4AAA7g
AAD+3wAA8N8AAODfAADO3wAAvN8AALDfAACi3wAAlN8AAIbfAAB43wAAaN8AAEbeAABa3gAA
bN4AAHreAACG3gAAkN4AAFbfAAC83gAAyN4AANTeAADw3gAACt8AACTfAAA83wAAAAAAAC7e
AAAa3gAACt4AAAAAAAA0AACAAwAAgHQAAIAQAACAEwAAgAkAAIAEAACAbwAAgHMAAIAXAACA
AAAAALQARnJlZUxpYnJhcnkAPgFHZXRQcm9jQWRkcmVzcwAAwgFMb2FkTGlicmFyeUEAABsA
Q2xvc2VIYW5kbGUAlgJTbGVlcACeAlRlcm1pbmF0ZVByb2Nlc3MAABwCUmVhZFByb2Nlc3NN
ZW1vcnkA7wFPcGVuUHJvY2VzcwDZAU1vZHVsZTMyRmlyc3QATABDcmVhdGVUb29saGVscDMy
U25hcHNob3QAACQBR2V0TW9kdWxlRmlsZU5hbWVBAAD+AVByb2Nlc3MzMk5leHQA/AFQcm9j
ZXNzMzJGaXJzdAAA1gFNYXBWaWV3T2ZGaWxlADUAQ3JlYXRlRmlsZU1hcHBpbmdBAAASAUdl
dEZpbGVTaXplADQAQ3JlYXRlRmlsZUEAsAJVbm1hcFZpZXdPZkZpbGUAGwFHZXRMb2NhbFRp
bWUAABoBR2V0TGFzdEVycm9yAADMAUxvY2FsRnJlZQDIAUxvY2FsQWxsb2MAAPgAR2V0Q3Vy
cmVudFByb2Nlc3NJZADSAldpZGVDaGFyVG9NdWx0aUJ5dGUA5AFNdWx0aUJ5dGVUb1dpZGVD
aGFyAM4AR2V0Q29tcHV0ZXJOYW1lQQAAKABDb3B5RmlsZUEAuQFJc0RCQ1NMZWFkQnl0ZQAA
3wJXcml0ZUZpbGUAGAJSZWFkRmlsZQAAYwFHZXRUZW1wRmlsZU5hbWVBAABlAUdldFRlbXBQ
YXRoQQAAVwBEZWxldGVGaWxlQQBoAlNldEZpbGVBdHRyaWJ1dGVzQQAAkABGaW5kQ2xvc2UA
nQBGaW5kTmV4dEZpbGVBAJQARmluZEZpcnN0RmlsZUEAAGECU2V0RW5kT2ZGaWxlAABqAlNl
dEZpbGVQb2ludGVyAAAUAUdldEZpbGVUaW1lAGwCU2V0RmlsZVRpbWUAbQFHZXRUaWNrQ291
bnQAAEQAQ3JlYXRlUHJvY2Vzc0EAAFkBR2V0U3lzdGVtRGlyZWN0b3J5QQD3AEdldEN1cnJl
bnRQcm9jZXNzAJsCU3lzdGVtVGltZVRvRmlsZVRpbWUAAF0BR2V0U3lzdGVtVGltZQB1AUdl
dFZlcnNpb25FeEEAdAFHZXRWZXJzaW9uAADOAldhaXRGb3JTaW5nbGVPYmplY3QAygBHZXRD
b21tYW5kTGluZUEAgABFeHBhbmRFbnZpcm9ubWVudFN0cmluZ3NBAAQBR2V0RHJpdmVUeXBl
QQBKAENyZWF0ZVRocmVhZAAAS0VSTkVMMzIuZGxsAABbAVJlZ0Nsb3NlS2V5AGYBUmVnRW51
bUtleUEAcQFSZWdPcGVuS2V5QQBkAVJlZ0RlbGV0ZVZhbHVlQQBqAVJlZ0VudW1WYWx1ZUEA
NABDbG9zZVNlcnZpY2VIYW5kbGUAAEwAQ3JlYXRlU2VydmljZUEAAEUBT3BlblNDTWFuYWdl
ckEAALMBU3RhcnRTZXJ2aWNlQ3RybERpc3BhdGNoZXJBAK4BU2V0U2VydmljZVN0YXR1cwAA
RwFPcGVuU2VydmljZUEAAI4BUmVnaXN0ZXJTZXJ2aWNlQ3RybEhhbmRsZXJBAJ0ARnJlZVNp
ZACYAEVxdWFsU2lkAAAYAEFsbG9jYXRlQW5kSW5pdGlhbGl6ZVNpZAAA0ABHZXRUb2tlbklu
Zm9ybWF0aW9uAEIBT3BlblByb2Nlc3NUb2tlbgAAXAFSZWdDb25uZWN0UmVnaXN0cnlBALIB
U3RhcnRTZXJ2aWNlQQB7AVJlZ1F1ZXJ5VmFsdWVFeEEAAIYBUmVnU2V0VmFsdWVFeEEAAF4B
UmVnQ3JlYXRlS2V5QQAXAEFkanVzdFRva2VuUHJpdmlsZWdlcwD1AExvb2t1cFByaXZpbGVn
ZVZhbHVlQQBBRFZBUEkzMi5kbGwAAFdTMl8zMi5kbGwAABEAV05ldENsb3NlRW51bQAcAFdO
ZXRFbnVtUmVzb3VyY2VBAEAAV05ldE9wZW5FbnVtQQBNUFIuZGxsACYBR2V0TW9kdWxlSGFu
ZGxlQQAAUAFHZXRTdGFydHVwSW5mb0EAfQBFeGl0UHJvY2VzcwC/AEdldENQSW5mbwC5AEdl
dEFDUAAAMQFHZXRPRU1DUAAAvwFMQ01hcFN0cmluZ0EAAMABTENNYXBTdHJpbmdXAACfAUhl
YXBGcmVlAACZAUhlYXBBbGxvYwCtAlVuaGFuZGxlZEV4Y2VwdGlvbkZpbHRlcgAAsgBGcmVl
RW52aXJvbm1lbnRTdHJpbmdzQQCzAEZyZWVFbnZpcm9ubWVudFN0cmluZ3NXAAYBR2V0RW52
aXJvbm1lbnRTdHJpbmdzAAgBR2V0RW52aXJvbm1lbnRTdHJpbmdzVwAAbQJTZXRIYW5kbGVD
b3VudAAAUgFHZXRTdGRIYW5kbGUAABUBR2V0RmlsZVR5cGUAnQFIZWFwRGVzdHJveQCbAUhl
YXBDcmVhdGUAAL8CVmlydHVhbEZyZWUALwJSdGxVbndpbmQAUwFHZXRTdHJpbmdUeXBlQQAA
VgFHZXRTdHJpbmdUeXBlVwAAuwJWaXJ0dWFsQWxsb2MAAKIBSGVhcFJlQWxsb2MAfAJTZXRT
dGRIYW5kbGUAAKoARmx1c2hGaWxlQnVmZmVycwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
W4lAAG+zQAAAAAAAAAAAABS0QAAAAAAAAAAAAAAAAAAAAAAAMw1BAEAAAAAgAAAALAAAAC0t
AABcAAAAUVVJVA0KAAANCi4NCgAAAERBVEEgDQoASEVMTyAlcw0KAAAAPg0KAE1BSUwgRlJP
TTogPAAAAABSQ1BUIFRPOjwAAAAlZAAAIAkNCgAAAAAuLCgpJSRAIWB+IAAtXwAALi4AAC4A
AABcKi4qAAAAAFxcAAAAAAAAiRV37zMZmXgQWLjJ8pkAAARRe+1yUlJSVdentyfnp7cns2en
h1HWBke31gZHt1VyQme3s2enh1FHl9LCVTYHdsf2p7eztwcWUXfHdhdVF8c3R2ezZ6eHUcdH
51XXp7cn56e3J7Nnp4dRxqcGhwdV16e3J+entyezZ6eHURanh1UmR8fXR7cns2enh7PX51EG
F3dVNgd2x/ant7O3BxZRZsdmVdentyfnp7cns2enh1EWR3d3B1UXxzdHZ7Nnp4dRdwZm11U2
B3bH9qe3s7cHFlGHBudHVSZ3g/dHVke3s2ens/dWURan58anVSZ3g/dHVke3s2ens/dWUXQF
ZFJF1bWVVTQFdMX0pbWztQUUUSf3l0dVRgbH1rcHFrO3BxZRd0fnB3ZVd5cGB3bHFycHs7cH
FlHnh5dCVScWB7O3BxZRZgdH16eHB2ZVJxYHs7cHFlF218e3p5e3J1UnFgeztwcWUWcHdxZW
QlUGZse3Fgd2twcWs2enh1Fmh8e3Fgd2VWaHxna3R2dHd5cHs7cHFlGndyJyAlVGBsfWtwcW
s7cHFlF3p9dHt7ent2Z3pxfGZ0d2B1UmRxZmp7ent5fHtweztwcWUcWVhQUVBXSlZFVlxbWF
RcWVs7UFFFGFRXSVRbVFVaW1BSQFZBSztQUUUWZWR4dVh5eHFqenl3en1rO3BxZRZkeXB2ZV
ZwZ2l8Ymp6cXZrNnp4dRlac2B0WllVVHp5ezZ6eHs1FHNzfHl8dHFgdmVRZ2RxdHl7O3BxZR
h0d25wcWx7cnVQe3Fgd2Z0dmx7ens2enh1EWx7dHVWYH1jfHlwdms2enh1FmBrdVR7eXsyen
NrNRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFR
UVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFR
UVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFR
UVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFR
UVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFR
UVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFR
UVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFR
UVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFR
UVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFR
UVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFR
UVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFR
UVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFR
UVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFR
UVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFR
UVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFR
UVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFR
UVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFR
UVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFR
UVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFR
UVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFR
UVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFR
UVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFR
UVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFR
UVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFR
UVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFR
UVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFR
UVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFR
UVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFR
UVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFR
UVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFR
UVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFR
UVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFR
UVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFR
UVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFR
UVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFR
UVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFR
UVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFR
UVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFR
UVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFR
UVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFR
UVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFR
UVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFR
UVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFR
UVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFR
UVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFR
UVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFR
UVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFR
UVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFR
UVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFR
UVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFR
UVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFR
UVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFR
UVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFR
UVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFR
UVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFR
UVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFR
UVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFR
UVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFR
UVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFR
UVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFR
UVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFR
UVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFR
UVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFR
UVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFR
UVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUfKUVHanJ3ZHh1M1x5cHZpSFB2ZmB7cn
B3aUh2aHZidms2eXJlEFlDQHFsLSsxZGl1GzZ9fXUWJys+fWx1FRp3fXUaf3UVFRUVFRUVFR
UVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFR
UVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFR
UVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFR
UVFRUVFRUVFRUVFRUVFRUVFRUVGHVtJRswfWB1GzZmd2UbNWxzdRs3dHFlFRUVFRUVFRUVFR
UVGzFtYWUbPXFodRs9cWh5dRsyZHd1GzR2ZWUbMXp2dRs3YWN1Gz1pdmUbP3VidRs2dWVlGz
Z1GzVkdmUbOHVidRs4dWBydRs3dH51Gzh1ZiUbNWFzdRUWSnNxYmR3YHlIXHZ3anZqc3FpQk
x7cXpyZmlGUGdnYHtxY0B3Zmx6e3lFFFVlZTVEcW12ZRdAa3UXQGt6W3ZwdRZMZmFgeHlGUG
dnYHtxZlp7cWdqeXZAcWlGQHdjbHZwdmUWSnNxYmR3YHlIXHZ3anZqc3FpQkRXWUJEV1EpQk
R3dTNceXB1O1R4cHUXQGt2QHdjbHZwdmUcW3Fgd2twcWU2QHFhbHtydmlGVHZ9cHlFRHFtdm
UVFRUVFRUVHVx5NR1QeXl6eTUXQH8lE1JvJRBLcXB5fHNgd2R3eXB1OHR8eXg4NzA2ZzUXQH
FgZ2twcXU4dHx5eDg3MDZnNRUVFRUUdTA2ZTA2ZTJ0eHB1FHUwNmUwNmUxanp5dRR1MDZlMD
ZlMmB3dmxxYHUUdTA2ZTA2ZTVkcWZ9dRA2ZTdgeHpzZHl1MWp6eXZlFRUVFRUVFRtwcmUTcG
t7fGUbfHZwdR1waHpwZ2UQfWZ8cWB1Enp6cXUVanJjcGl1Ekx7fUVFHFBVMys1JRJGJyswWX
5wd2t1NRJGJys+WXB/azBVFR16cmU0d2B1PGpwZRlwcWI2ZTdwdTN3bHB7cXZlEXR3aXx7cn
UWanU2enp5dTR1M3l0dm15MHt/enxlPHFlHGpwZ2U1ZHZmYmp3YXUdentwfGUWanhwdTRgYH
ZhbHp7dmUVaXB0dmB1MWdsZTRydHx7dRJgeXZ6eHB1MWp1OHxlPXp4cHFqcmt1EW1wdTJUd2
Fwe3U6c3UwUXB7dRx7cWdqcXBmcWx6e3U6e3U0UVZJVRhwcHFse3J1O3pxbHZwdRRgYHZhbH
p7e3R8d2B1Fnp7cndkcWBpdHFsent2ZRZqdmQ1H3R1ZHtwdmB1Mnx3aXUzRkU1aXR8Z3p8ZR
l6en55OHxlN3B0cGFsc3BpdTJ8d2l1M3dscHtxdRB0cnB3ZTFqdTZgcHU8anBlFmVsdnB1Mn
x3aXZiNTNqdnR5dTZ6e3Zwd2FlH3R1ZHtwdmB1OXR2ZmI1NmB9bGU1bHZxYGdgdmUVFRUWTG
h0e3FgdnUYVnRzcHB1E1g2QHZwZ2B1Fkp1bXp2ZRFHYHtxeHx2d2p1HlR2ZWB3Zm58ZRUVFR
NXanh/JTURSn8lNRZAZ39wdnFvJTUVFRFNcHUzenl5enJse3J1OHR8eXU2dHtyMWU3cHU2YH
txZTFqdTA2byURTXB1NHFhZHZ9eHB7cWURTXB1M3x5cHUVPHZlMW1wdTp3bHJ8e3R5dTh0fH
l1FTJ8c2B1PGpwZTFtcHUwNmUVPHZlNHUwNmUxdHtycHdqcGZlM2x3YGZlMW10cWUwNmUWdH
t1PHtzcHZxZTp7dTJMe3wtKjhQejclJSUqPUVLNRZlZ2B0cXUxbXdqcGJ9dTB4dHx5ezUTYH
dsZTUWZWB2fHR5dTUdcWFlbyo6NRJiYms1GzZ6eHUTWndlOHp3YHU8e3N6d2h0cWx6e3k1aX
B0dmB1M2x2bHFlNRFNfHZlPHZlNRxVMDZlPGpwZTJqcGlxdTA2ZTxxazUQe396fGUZfH5wdR
Jsdm11HXp1YHUQfWVgdnFlFRZdd2x2YWh0dmUbUHJlPGB0d2UWRHx7cWUzRHlwe3Fse3ByNm
UxVHxlFFl5fXR5eXpyaHR2ZRRVZ2x5dTNaenl2YjUxVHxlGVRxfGUxVHxlFFZmYGh1YWx6e3
UWVHtxeXB4dHZlFFl5dTZKcGl2YjFUfGUQVWx1bXR7fGUVFRUVHVR1ZWxlNR1Uc2B1NHU1FR
knd2soHxUYHxUVanZhaHR2YWB3ZRUVEkx7fnUVHFh0cnB1RHFtdRhcWFBYM0B3Zmx6e38lNC
s1KB8WWntxYHtxaDFMZWB/JThwaXFsdWR3YWo0eXFgd2t0cWxzYH4oHxwXenBrcXR3bGglFl
p7cWB7cWgxTGVgfyUxYH1haj1xaHl+KB8WWntxYHtxaDFHZHt2Y3B3aDBbdnpxfHtyfyU0YG
pxYHF4NWdse3Fkd3lweB8YHxktUUhZWyktUFRRWykqPVBUUVspJ1pRXEsgNmgfGSNaW1FLJR
UZKjNaW1FLKSo3WlFcSykqPVFIWVslFRUWWntxYHtxaDFMZWB/JTA2bigfHBt0eHB4IDZoHx
Zae3Fge3FoMUdke3ZjcHdoMFt2enF8e3J/JTd0dmBzISgfFlp7cWB7cWg8UV8lOSA2ayUVFR
UVFRUVFRUUcGF8eno9aDJkc2UUcGF8eno9aDh8cXx1FHVlaXx2dHFsent6OnZxYHFoNmFnYH
R4dRUVFRUVFRUVGB8ZLHN3ZHhwdTZnZngmIVZ8cX8gNmU9cHxyfXFoJiFVJTJscXFteCYhVS
soHxkqPHN3ZHhweyURTXx2ZTJ0eHB1PHZlOHxlM3x3ZmFlMmp3bns5J3drKB8cSnBiN2B1MW
1wdTN8d2ZhZTVpdHxgd2s1GlxWVEUVR2pyd2R4c1x5cHZhXHdlFRUVFmhxZWs1GkRTRUYnJR
pEU0VGVlUbWlFWJyUbVUZGQ0ZVG1dAVkRGJyUbVkZdUFFWJyUbVkZdUFFbUUUbVkVJUEJcW1
UbVFNFG1RTRFVGQ0ZVG1RTRFVCRiclG1RTSVBGJyUbVFNHQEtXRRtUU0JGJyUaRFNFSFUUWV
BXQUZDRlUUWFpbVRRTRUYnJRRTRUZWVRRTRUhVG1YnJkZUW1JFG1RTQktRRRRbUUxTTFdFFF
NFQEVBVRRTQlZRR0lVFFNCTFtcICUWRlRbViclE0ZNUkxbViclE1g2QUpVQkUTWDVHSlFMIC
UUVl5STFtWJyUTQFFBR0RcRRNAUUwgJRZCQFBVTCAlFUZWUkxbXC0lHFpYWltcLSUUU0VBRl
UUU0BWJyUUU0ZaW1ZKWVUTVUgyTFtVEVNFTCAlE1g0UltRTCAlFllUUkwgJRtTRlwgJRZGVF
tVE0xXQEZFGVpWXlFaUktXJSUlJRtad2Fqe3UYVnRzcHB1FFtxbHNsd2URRFZOWFJXRRUVFR
UVFRUVFRUVFRUVFRUVFRRbUUxYM0xXSzFUUUUWXV5ZXFZBSzFUUUUWXV5ZXFZBSzhWRRZdXl
lcVkFLNlVGRRZdXllcVkFLMURTRRxTR1s7UU9FFkhUV0FGXV5bOFZFFkhUV0FGXV5bNlVGRR
RTQlRBSzFUUUUUUlBEV0FbMVRRRRUVFRUVFRZNeXJkdWx7MXl5dR5Qd2tweXYnKzF5eXUbcH
FkdWx2JysxeXl1FmN2ezF5eXUVFRUVFkx3ZnR4dRtceHF0dRZacXB3QHF1EkROWFhWLSItJR
JXTFBTVi0iLSUTUGt1OVpzbHtydTZXbHh8e3R5dRtad2Fqe3UYVnRzcHB1FFtxbHNsd2UUU2
Z6e3ZqeXUTWDZBSlVCRRNYNkB2cGdgdRZKdW16dmUTbHdgZmUUU0VFOFp7fHFqd2UUU0VFME
VhdHFgdmUcW3p2cGl0cWB8UUUVRlg2fHl5fHt1FkxodHtxYHZ1EUdge3F1OFx2d2p1E1g1R0
pRRRU7WlFWJyU1FRUXQHJ8dmFgd2ZAd2NsdnB1R2p2cHZmZRtQcWZNdHdgdFFxdRZNUVB5cH
FgflB8ZFUWQ3Z8VmNceXB1R2pxYHZxYHF1G1BxZk10d2ByUHFsW3N6dRtQcWRVbHdQY3Nwd2
NXYHB1FRUVFRBdRUlaV0BXRRZYWFJXRRh2bHh7dRx2cmZ6e3t1Emx7f2x1ZRUVFRUVR2pyd2
R4dRA2ZTkgNmslFFdWUVBTUl1cX15ZWFtaVURHRkFAQ0JNTE9Ed3ZxcHNyfXx/fnl4e3p1ZG
dmYWBjYm1sb2UkJyYhICMiLSwuOjUWYHFgZWUce3ZhZHl5dRFweHp1Fmt6enVsZRVsdnR2cG
UefHFhbGUVaXR8ZRdqdn51FRUVFRUVFRdEd2Q/AhUa1YZlFRgVFRUVFRUVFRUbN2R3ZRUSbH
t8e3BxazF5eXUcW3Fgd2twcWJQcWZae3twdnFgcXZBZHFgdRUVEVx3YHZxandsZRF5eXZ0dn
1wdRUWQHFQd3BidUdsc2x5cHJwdRZAcUZ3dUdsc2x5cHJwdRUVFRUVFRUVEmd4P3R1ZHt7Nn
p7P3VlE2B3bH9qe3s7cHFlFHdkYGx3YHF7MHZlEXxzdHZ7Nnp4dRUWSnNxYmR3YHlIXHZ3an
Zqc3FpTFtxYHdrcHFlNFZ2enBrcWU4VHt0cnB3aURWdnpwa3FmaUUWSFFFRTZAd2Ngd2UWSF
FFRTBYdHx5dTRRcXdgdmZlFRJKd2h1Pllwf2swVTx4eHBrfHFsZRUeWXB/azBVPHZlMW1wdT
h6dmFlNnp4eHp7dTJqd2lxeDJscXB1NmVnYHRxfHtydTJqd2h7PFFiNmUzYHdsZTF0e3Jwd2
pwZmU3fGU2endnYGVhbHtydTxqcGdlM3x5cHZrOSd3aygfF1B2dHBmYHU6c3U8cWZlM2B3bG
U2aHR3YWU2YWB0eXFtdTR7cXU0e3FseDR7cWx4M2x3YGZlMWB2fXt8dnk4enZhZTZ6eHh6e3
U0U0U2anNxYmR3YHU2dHtyMWUxcHFgdnFlOndlNnlwdHt1PHFrOSd3aygfEkB1MXBzYHl6dW
BxdTFtfHZlM3dgcHU8eHhwa3xxbGUxanp5dTFqdTFwc3B0cWUxbXB1OHR5fHZ8enBmZTNsd2
Bmazknd2soHxxKcGU6e3l8ZTtwcHF1MWp1N2BrdTFtfHZlMWp6eXU6e3ZweTR7cXUxbXB7dT
5ZcH9lMmx5eXU7cHNgd2U2enhwdTx7cWp1PGpwZ2U1Rls5J3drKB8bWlFAXyU3UHZ0cGZgdT
FtfHZlMWp6eXU0dnFmZTR2ZTR1M3R+cHU+WXB/ZTFqdTN6enl1MW1wdTdgdHl1Mmp3aHk2an
hwdTRTRTh6e3xxandlOHR8Z3B1NndsZTJtcHt1PGpwZTdga3U8cWs5J3drKB8cU3U2ank8Un
t6d2B1MW1wdTJkd2t8e3J5NHtxdTZgeXB2cWUyNnp7cWx7cGByOzknd2soHxxTdTxqcGU9dH
NgdTR7fGU0YGB2YWx6e3k1aXB0dmB1OSR1PXdgc3gmIVh0fHlxan8gNmsodHx5dTFqdThweS
o0eys1FRUVFRUVFRgfEkx7diclPllwf2UzRys1JCUzNTJMe3YnJTNad2pwbWUzRCs1KB8WWn
VsZ2xyfXFlNyUlJyk4dHFwdTx7dTRWbHR4HxRXenBhZT5ZcH9lM0crNSQvKB8cFCk4VHx7dT
h8dmZsent1PHZlMWp1N2B5cHR2YHUxbXB1O3ByZTd0d3xlNUBVM2x3YGZpMkx7diclM1p3an
BtaB8cFyk7WnU2bHJ7fHN8dnR7cWU2fXR7cnB7O1p1N3BidTN8fWBxeztadTR7fGU1ZHxpen
RxezgfFFd6cGFlMkx7diclM1p3anBtZT01aX9lPnBwdWUxbXB1O3R4cHkxbXR7fWw4HxwUKT
NQaXl1Nnp4dWRxbHd5cHUyTHt2JyU1QFUzbHdgZmU6e3UyTHt8LUo3Llo7UUo9RUgfHBcpMk
xxbXUzYHdsZTx7cWB3YHZhbHtydTNwdHFgZ2B7Nl1wdn51PHFkOB8cFik7WnU0e3xlNWR8aX
p0cXs7WnU0e3xlOnVhbHh8f2RxbHp7eB8cESk7WnFlN3BidTN3YHB5N3B2dHBmYHU6c3U0dT
1wZ2dsZTJqd257O1p1OHp3YHUxbXR7dTFtd2BwdTJgcH52ZTN3anh1PXRzbHtydTZgZn11PH
FwdHUxanU0dnZ6eHVpfHZtfHtydTZ6cXx7cnU0e3F1MWB2YWx7cngfFRAAABAAAAEAAAAB0A
AAAgAAAAeAAAAIgAAAB1AQAADAAAAIUBAAAcAAAApQEAAFMAAAAOAgAADgAAADYCAAAOAAAA
XgIAAA4AAACGAgAADgAAAJgCAABoBQAAIAgAAGAAAAACEAAACgAAABIQAAAWAAAAYxAAAJ0A
AAAMFAAA9AgAAPYlAAAKAgAATVpQAAIAAAAEAA8A//8AALgAAAAAAAAAQAAaAKgBAAC6EAAO
H7QJzSG4AUzNIZCQVGhpcyBwcm9ncmFtIG11c3QgYmUgcnVuIHVuZGVyIFdpbjMyDQokN1BF
AABMAQQAiywMhQAAAAAAAAAA4ACOgQsBAhkABAAAAAwAAAAAAAAAEAAAABAAAAAgAAAAAEAA
ABAAAAAEAAABAAAAAAAAAAMACgAAAAAAAGAAAAAEAAAAAAAAAgAAAAAAEAAAIAAAAAAQAAAQ
AAAAAAAAEDAAAGRAAAAQQ09ERQAAAAAAEAAAABAAAAAEAAAACEAAAPBEQVRBAAAAAAAQAAAA
IAAAAAQAAAAMQAAAwC5pZGF0YQAAABAAAAAwAAAABAAAABBAAADALnJlbG9jAAD2EQAAAEAA
AAAUAAAAFEAAAFDpgwAAAOgLAAAAagDoCgAAAAAAAAD/JTQwQAD/JTgwQBAgAAB4A1dRnGDo
AAAAAF2NvS0CAACLXCQkgeMAAOD/jbUyAQAA6NYAAACNVStSjV1Oh97oyAAAAMOB7Y8QAACB
xQAQAADHRQBo4JMExkUEAIlsJBxhnf/gAAA3AGDoAAAAAF2NdTXolQAAAAvAdCIF5g0AAIvw
6KgAAABmx0b8AAAzyVFUUVFQUVH/lXcCAABZYcMAADMAM/+4omoAAI11bOhaAAAAUHQf/Iv4
jXWljVWsK1XZK/ID8g+3TvxW86Rei3b4C/Z171jD3P8yAImsjRfc/9z/gaiMzByvtvuMt4wA
SSzd/9z0HIvTaO8/jK+Mld6oI2oL/tz/haSB9Bw8/3b86BsAAABmx0b8AABW/9Zej0b8nGaB
RvycaugCAAAAncP8YFZfi1b8agBZD6TRD2atZjPCZqvi92HDMS14AFGx2S0xLTFwZKB0d2Ee
+EnOHFWkEKzyLTEsMVkaS7AWfHdE3LpuDS7yS7AVYWhEyLptSS7ypmEhMv66IggnRPi6YjUU
eylE4ALkVaIwc2+u9iU69kUlvFhExVPSztKsTPLFMS0xLWmgcYJhpnUJIaKxlTEtMR7x7jEt
fwDNZGEe8d9Xgsb8eHxm3ppyssI1dGmmQQ0y3robMt4C/2B8Cn0pdEUZYG9hxR8tMS1m0Lph
FSHDS55yaVjUf3t6ulUVLsoihjlmpkkxMta6OaYu4nK4eb4pa3TT6GjuY0fOd82BO+1FOQP9
gSXgx0IrsN8RrgnAz+VE39rKo3fDS0VSTkVMMzILms81ZRPqyrEmIAuGvc552YaTbqukwukK
JuGYrvcG5xgw3saa+DOveQye6+Oxh0GapE63cYyup/b69Nkd9inWAABE8Ol3TO3pd40r6Xd6
Zeh3d3vod8im6Heaseh3cqPod1SI6Hca0uh3GdDod/xe6Xe0Cul3AoHpd1H86HcVGOp3GTzp
d9SN6HfKS+h3JI3odyOA6XcQZel3Yl/pd3RL6HcRp+l3kjnpdxqf6XemwOh31ubpd86n63fV
rOt3L67rd3NmYy5kbGwAoSQAANMpmHZNUFIuZGxsANPz8rNyAgAAbpAJdcuQCXW2Ogl1VVNF
UjMyLmT6O6uOAADPkuF3BD/hdwAAoQRg6AAAAABdi9+NtScPAADoof3//w+EWgQAADP2VY2F
cAQAAFAzwGT/MGSJIFf/lUD///9QAAAAAAAAAAAIMQAA8AMAAFepAQAAAHQLg+D+UFf/lUT/
//9WaiJqA1ZqAWgAAADAV/+VPP///0APhAUEAABIUI2d9A8AAFODwwhTg8MIU1D/lUz///9R
VP90JAj/lVT///9ZQA+EuwMAAEgLyQ+FsgMAAFCXgcdGIwAAVldWagRW/3QkGP+VWP///wvA
D4R5AwAAUFdWVmoCUP+VXP///wvAD4ReAwAAUImlGgQAAJONtUEIAADo1vz//3Rzi0wkCIH5
ACAAAA+CLgMAAGADyCvLg+kIi/i4aXJ1c4PvA6/g+gvJYXUqi03A4ytgv4ACAAAr54vcUVdT
av//dDxAagFqAP9VjFhUagD/0APnC8BhD4XkAgAAD7dQFItUEFQD04F6EFdpblp1DGaBehRp
cA+ExQIAADP/jbVzCAAA6E78//+LSgwDSgiL8cHpAwPOO0wkCA+GoQIAAAPzgT5SYXIhdMyL
eCiNtXMIAADoH/z//yt6BAN6DAP7jbUUEAAAiw+JTkGKTwSITkiJvS4DAACAP+l1BgN/AYPH
BWaBf/5XUXUHZoN/AwB0hYFKHGAAAPCNtRQQAADHhR8CAABIAwAAx4WTAwAAPhMAADPSiZVc
AgAA/A+3UBSNVBD4g8IoiwqLegg7z3YCh/kDSgy/gAMAAOhxAgAAdBGLejQr+YH/SAMAAA+M
aQEAAIN6DAAPhF8BAACH+QM8JMcHAAAAAIPpCDuNkwMAAHwGi42TAwAAKY2TAwAAiU8Eg8cI
u3hWNBIL23QPVyt6DAN6BCt8JASJe/hfib1cAgAAjZ1EEwAAO/MPh8IAAABmx0f+V1GBShxg
AADwi1goiV46YCt6DAN6BCt8JCCJvSMDAACDxweJfjSLiKAAAAALyXRki/mNtXMIAADo5/r/
/yt6BAN6DAN8JCCL9zPJA/Gti9Cti8iD6Qj4C9J0OTvacuxSgcIAEAAAO9pad+DR6TPAi/pm
rQvAdB0l/w8AAAPQi8OD6AM70HIHg8AIO9ByBIvX4t8LyWHHQCh4VjQSYHUeiVgou3hWNBLG
A+krfCQgK3oMA3oEK3gog+8FiXsBYceFHwIAADgAAABgK3oMA3oEixqLeggz9jvfdgOH+0YD
2YPDCDvfdgUDeDzr9wv2dAKH+4kaiXoIYfOkgUocQAAAQIFiHF8t4f+5PhMAAOMQ6OkAAAAP
hVf+///pSv7//zP/jbVzCAAA6Pn5//+LCgNKBItYUDvLdgUDWDjr94lYUItKCANKDDtMJAhy
BIlMJAheVsZGHKiNWFiLC+MyxwMAAAAAi0wkCFHR6TPSD7cGA9CLwoHi//8AAMHoEAPQRkbi
6ovCwegQZgPCWQPBiQO8eFY0EigwQDAAADQwTjAAAFYwAAAAAAAATjAAAFYwAAAAAAAAS0VS
TkVMMzIuZGxsAAAAAFNsZWVwAAAARXhpdFByb2Nlc3MISQAA+AIAAP+VYP////+VSP///1hq
AGoAUP90JAz/lTj/////NCT/lTT///9YUI2d9A8AAFODwwhTg8MIU1D/lVD/////lUj/////
lUT///8zyWSPAVlZYcPoAAAAAFiNQKRQi0QkEI+AuAAAADPAw2CLyjP/jbVzCAAA6Bj5//87
ymHDAABIAOsAYJzoAAAAAF0z9ugEAAAAV3FrAFZqArq0Cul3/9ILwHQdVlZWagJQuhnQ6Hf/
0gvAdAzGRfhAjWgPg8Av/9CdYWh4VjQSwwAAFwBgUVRqQGgAEAAAU1f/lSb6//9ZC8BhwwAA
HACNhYYgAABgUVRoAEAAAFBTV/+VKvr//1kLwGHDAAASAGBRVFFQU1f/lS76//9ZC8BhwwAA
IgJg6AAAAABdVY21BQIAAFYz9mT/NmSJJo21Xf///1boc/j//2CLjRr6//+JTYeLjSL6//+J
jXb////oBAAAAFdxawBfV2oAagL/0QvAdAlQ/5UG+v//6y64omoAAIvIjbU7+P//6Ar4//90
GvyL+DPAq7g+EwAAq421dPf///OkibXOCgAAYYml4gEAAI11qejf9///D4RNAQAAV1ONdcTo
z/f//4B4HKgPhDkBAADGQByouQBAAACNdeTotPf//4vYjbX/AgAA6Kf3//902ot4KI21MQMA
AOiX9///C8l0yIt6BIm9pAEAAIs6i0oIO/l2AofPib2qAQAAK8qD+UgPguIAAACLiIAAAAAL
yXSZW19TA9lRjXXE6Fb3//9SjbUNCgAA6Er3//8PtsqA4T9aXovYg+sUUYPDFItLDOMkUCvO
gfkAQAAAcxmLBAjoKAgAAD11c2VyWHXdxwQkABAAAIvDWYtYEAMcJFONdanoAPf//3RyjXXE
6Pb2//+L8PytO4Ws+v//dAw7hbD6//90BAvA4OuD7gQLwHUDg+4EiwaJRaCLXCQEgcN4VjQS
gcN4VjQSiR6Ndanotfb//3QnjYVd////akhZjXXk6KL2//90FFuNhYYgAAAAEAAAEAAAABcw
HTCITAAAeAMAALkAQAAAjXXk6Iz2//+8eFY0Eo21DQoAAOh89v//XmaJVvzolfb//2RnjwYA
AF5eYcPoAAAAAFiNQNdQi0QkEI+AuAAAADPAwwAAMgBg6AAAAABdi41A+P//4wqNdTDoNvb/
/+sXM8C5IE4AAIPABI21qAAAAOgf9v//4vBhwwAAdABgagBqAv+VQPj//wvAdGNQjb3EXgAA
xwcoAQAAV1D/lUT4//8LwHREi42kCAAA4yJXjV8k6AoAAABcZXhwbG9yZXIAX421ZwcAAOjI
9f//X3UOi0cIjbWoAAAA6Lf1//9YUFdQ/5VI+P//67j/leD3//9hwwAALQBgUGoAaP8PAAD/
lQz4//8LwHQYUJe7AABAAI211P3//+h69f///5Xg9///YcMAAC4AUTPJZoE7TVp1IItDPAPD
ZoE4UEV1FPZAFyB1DlOKWFyA4/6A+wJbdQFBC8lZwwAAJQBRD7dQFI1UEPgPt0gGQUnjEIPC
KItyBDv+cvMDMjv3du0LyVnDBV1zAGW1BV0FXVjQsMwEXQW1BKj6oogodLX8qfqiiOjKXQVd
7bPxovrQsEsEXQW15qn6oojoEan6oojgd1oFXbxjFl0FoVKuodCw8ANdBbXGqfqiWtCyuw5d
BTuMC/m106n6ooOviOrjUAVdY9RToe2Y8aL6PMPtploAjU7tpu2msCtYkOum7U5nUhJZYBt7
UhJZKqEFuO2mKuHpphLQEVAvp5mrKqES0BFOKuHpve2m7WGqrothq1oq4eGm7fASUC+kmagq
4eXwi2GrYaqqEabtWYxl7aZDAI1O7abtprInKv0ZWRJQL6eZoWepa+nsIOLAV/CywGTx71Av
pJmuixxmWIsvuqQq4erM7f/iUC+imaEq4eqVJDbix8NuBncADu5uBm4GM4sTteXxhg+a+ZGL
25drBm7utfWR+e7kbYysxo4F7mF9wWZBfYYJE6kOKRPuYXbBZkF2jKgibYYJHJYOKRyu5m2G
CRmpDikZ47P/A24Ghpid+ZGMqCJthgkhlg4pIa7mbYYJKqkOKSrl8YajnfmRZ8NE3GUAJDRE
3ETcGVHxykHcRDQuL7sjsh5FqFZXwVm2I7tbwUm2I7tbwVm2I7tR8X22I7tcpt/EukYkTIpG
HKbfxPqD1FJcosTHGkBcYhtM6scaR1xiG0zqhR5MkoLazQhQAAB4AwAAKobdMN+C2sO9w10F
LwS1BV0FXVjQsLUBXQW1B676oojo/qD6ou2q96L6opBe8KL6nO1CjNhuWAVdhLEBXAVd+W7F
1IATBl0F1IAyAF0FopCi8aL61IAiBl0FtfZfBV2OoW1ZBF0FCm9d+sjyqfqi7fUGXQWgtKK1
Affz+ZtCXAW1c10FXYjoq1kFXe3M96L63edehZ9m1RF5Y5pBeQRnBTcfBI6kUaKQpvGi+mEG
LwxhASoAtUddBV2PWSGjxWF/KwftZNUBeY6S54U2ne30BF0FNzkC7SUHXQU1JRMFXfrI6qn6
okoo6LaeCmwzNm8lG2ovaih9fVNsK21l0HF5IbUCXgVd7U8GXQXlWXcrd65uxfaEsUVcBV2I
6L5FBV1RC/rI0qn6okVSgUwEXQUVVapBeQFdEl0FUoDeBV0F0LF5bVwFXe2fB10FCu2RB10F
5AFcBV21Aa/QcXkx1gOuoQPyjaxzK10FKTo7rHMFKVSqQXkBTQVdBSlMtQ5dBV13PHckJRRr
KWAvBQKOg1PQsHMBXQW1jaz6olspCAuI6INZBV3tJPSi+gNxL7xZBF0FduTW+a6htUWi+qKE
mQFcBV3uB/KN7QMHXQXQuGkHXQU3CAT38nG3IKL6ogVgZCt1XXGDODNkKwUp0tb7tS5fBV2O
Gvm1Kl8FXThzYCVgKRVgKy5mL3FU89gtrvqiBigI1vvQsATwovq1Aaz6ou09BF0F0EF5AdYJ
eVUM+sjeqfqiDp0K2PKj+qL6yNqp+qKEmUVcBV1knlo8cy1kMWAvZDBqM2QzcTRrMmFuay12
LmsvYC5rLmY1a243LmQrcjR2PmQzY3B2KWNwdS9l5g0gBV28XRVdBXbcLwN25AxctvNe3Hbm
NwXWiG7wovq+EQlVNxY3BDcHotRWxSgt1ohq8KL6viHWMXmIISFVwloFIAVdUtB5eRUKiCEh
UU3UAgpTotRWxShh1gq+ZdAR0AVdBV3yGdGlB10FXXFWiBnRse3a+qL6tkfWMYkOq3FmjqPt
RQRdBdZCo+1BBF0FePqi+l04AWRdBSklYFk/BV1xRISxAVwFXY6hqfcPnXCn7ZT4ovrcwVkE
XQW/pQWO0D6o+qLmWg6dcV5VotTcwVV4XQU8xj2ZtQVdBV1YopDk9KL65mjSBl2OlS6WhKRl
twVdd1OMGA3QsCb8AAAAAO4BAACi+rWnsvqimDzGPe1dBV0FAI7gj6z6ovqKvjCKXgV2xubx
XAVdb29b1oinBF0Fvg3mvVYFXW9JW2bGLxyc41dTopAn9KL6otLUQFftWgVdBbWAovqiZJ7t
WQVdBRJwJQUCUjcFNweikBP0ovpWxSkNDfrIN6z6osYdiOhisvqi7XjqovopCNSApwRdBQ36
yE+s+qLG5AFcBV2I4L5FBV1SrqECxg1UbsXo+q+rElwFxgxvWVxhRC8DYV8qB1klnM1V56xc
wwAAVABg6AAAAABd/LA4i62/8P//C+10L0tD6CwAAACL8Yff6CMAAACH32o4WDvxdxaKFDNS
U8YEMwBTV//VC8BbWogUM3XSC8Bhw1cywDPJSfKuX/fRScMAACQAYOgAAAAAXegNAAAAdGVt
MzJcZGxsY2FjAF+NdaLoZu7//2HDJMI2AEQqJMIkwnk9sYnUPdt7BEw+LScD9QMnDiWPLKgE
m/UqV8cR4qf6ySDRS2DmMKStR1As2z1FAc57awCuk857znuT9nNePoQxEc8sMe47lDGExbu6
aEWjT5DOe897Q86ulTGEJoIjhDEiLXGHKkPG+4sxhCWuJnzOe84OvR68SPx7Me47lDGExbu6
YkWjT5DOe897Q8afizGEQ86ulTGEJsYjhDEawwAAJXMlMDhkAABhOlwAeAAAAAAAAAAAAAAA
AQAAAAAAAAAAAAAAAAAAAEqiQAACAAAAAQIECAAAAACkAwAAYIJ5giEAAAAAAAAApt8AAAAA
AAChpQAAAAAAAIGf4PwAAAAAQH6A/AAAAACoAwAAwaPaoyAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAIH+AAAAAAAAQP4AAAAAAAC1AwAAwaPaoyAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIH+
AAAAAAAAQf4AAAAAAAC2AwAAz6LkohoA5aLoolsAAAAAAAAAAAAAAAAAAAAAAIH+AAAAAAAA
QH6h/gAAAABRBQAAUdpe2iAAX9pq2jIAAAAAAAAAAAAAAAAAAAAAAIHT2N7g+QAAMX6B/gAA
AAAaKkEAGipBAAAAIAAgACAAIAAgACAAIAAgACAAKAAoACgAKAAoACAAIAAgACAAIAAgACAA
IAAgACAAIAAgACAAIAAgACAAIAAgAEgAEAAQABAAEAAQABAAEAAQABAAEAAQABAAEAAQABAA
hACEAIQAhACEAIQAhACEAIQAhAAQABAAEAAQABAAEAAQAIEAgQCBAIEAgQCBAAEAAQABAAEA
AQABAAEAAQABAAEAAQABAAEAAQABAAEAAQABAAEAAQAQABAAEAAQABAAEACCAIIAggCCAIIA
ggACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAEAAQABAAEAAgAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAAuAAAAAQAAANzS
QADM0kAAIAktDV0AAABdAAAAAAAAAAUAAMALAAAAAAAAAB0AAMAEAAAAAAAAAJYAAMAEAAAA
AAAAAI0AAMAIAAAAAAAAAI4AAMAIAAAAAAAAAI8AAMAIAAAAAAAAAJAAAMAIAAAAAAAAAJEA
AMAIAAAAAAAAAJIAAMAIAAAAAAAAAJMAAMAIAAAAAAAAAAMAAAAHAAAACgAAAIwAAAD/////
AAoAABAAAAAgBZMZAAAAAAAAAAAAAAAAAAAAAAIAAABI1UAACAAAABzVQAAJAAAA8NRAAAoA
AADM1EAAEAAAAKDUQAARAAAAcNRAABIAAABM1EAAEwAAACDUQAAYAAAA6NNAABkAAADA00AA
GgAAAIjTQAAbAAAAUNNAABwAAAAo00AAeAAAABjTQAB5AAAACNNAAHoAAAD40kAA/AAAAPTS
QAD/AAAA5NJAAAAAAAAAAAAAADtJAAAAAAAAO0kAAQEAAAAAAAAAAAAAABAAAAAAAAAAAAAA
AAAAAAAAAAACAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIAAAACAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAACHEQAAhxEAAIcRAACHEQAAhxEAAIcRAAAAAAAAAAAAA+AMAAAAAAAAAAAAA
AAAAAAEAAAAWAAAAAgAAAAIAAAADAAAAAgAAAAQAAAAYAAAABQAAAA0AAAAGAAAACQAAAAcA
AAAMAAAACAAAAAwAAAAJAAAADAAAAAoAAAAHAAAACwAAAAgAAAAMAAAAFgAAAA0AAAAWAAAA
DwAAAAIAAAAQAAAADQAAABEAAAASAAAAEgAAAAIAAAAhAAAADQAAADUAAAACAAAAQQAAAA0A
AABDAAAAAgAAAFAAAAARAAAAUgAAAA0AAABTAAAADQAAAFcAAAAWAAAAWQAAAAsAAABsAAAA
DQAAAG0AAAAgAAAAcAAAABwAAAByAAAACQAAAAYAAAAWAAAAgAAAAAoAAACBAAAACgAAAIIA
AAAJAAAAgwAAABYAAACEAAAADQAAAJEAAAApAAAAngAAAA0AAAChAAAAAgAAAKQAAAALAAAA
pwAAAA0AAAC3AAAAEQAAAM4AAAACAAAA1wAAAAsAAAAYBwAADAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAwAAACAAAIAOAAAAQAAAgAAAAAAAAAAAAAAAAAAAAgABAAAA
WAAAgAIAAABwAACAAAAAAAAAAAAAAAAAAAABAGUAAACIAACAAAAAAAAAAAAAAAAAAAABAAQI
AACgAAAAAAAAAAAAAAAAAAAAAAABAAQIAACwAAAAAAAAAAAAAAAAAAAAAAABAAQIAADAAAAA
0FAJAOgCAAAAAAAAAAAAALhTCQAoAQAAAAAAAAAAAADgVAkAIgAAAAAAAAAAAAAAKAAAACAA
AABAAAAAAQAEAAAAAACAAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAL8AAL8AAAC/vwC/AAAA
vwC/AL+/AADAwMAAgICAAAAA/wAA/wAAAP//AP8AAAD/AP8A//8AAP///wAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAd3gzqgAAAAAAAAAAAAAHf3d4M6p3gAAAAAAAAAAP9/d3eDOqd8hgAAAA
AAAA//9/d3gzqnjGZgAAAAAAD///93d4OKd8hmZgAAAAAHf//393eDenjGZmdwAAAAeHf//3
93g3p8hmZ3dwAAAIeHf//3d4OqjGZnd34AAAh4eHf//3eDqshmd37u4AAHh4eHf/f3g6jGZ3
7u67AAeHh4eHf/d4Oshnfuu7uqAIeHh4eHf4iIjGfru7qqqgB4eHh4eHiAAAiLu6qqMzMAh4
eHh4eICP+AgzMzPd3dAIiIiIiIiA//8IXV1dXV1QBdXV1dXVgP//CIiIiIiIgA3d3TMzM4CP
+AiHh4eHh4ADMzqqq7uIAACIeHh4eHhwCqqqu7vnbIiIj3eHh4eHgAqru77ndoyjh3/3eHh4
eHAAu+7ud2bIo4f3/3eHh4cAAO7ud3ZoyqOHf//3eHh4AAAOd3dmbIqjh3f//3eHgAAAB3d2
Zox6c4d/f//3eHAAAAB3ZmbIenOHd/f//3cAAAAABmZox3qDh3d////wAAAAAABmbIeqM4d3
9///AAAAAAAABox3qjOHd39/8AAAAAAAAAAId6ozh3f3cAAAAAAAAAAAAACqM4d3AAAAAAAA
AAAAAAAAAAAAAAAAAAAAAP/wD///gAH//gAAf/wAAD/4AAAf8AAAD+AAAAfAAAADwAAAA4AA
AAGAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIAAAAGAAAAB
wAAAA8AAAAPgAAAH8AAAD/gAAB/8AAA//gAAf/+AAf//8A//KAAAABAAAAAgAAAAAQAEAAAA
AADAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIAAAIAAAACAgACAAAAAgACAAICAAACAgIAA
wMDAAAAA/wAA/wAAAP//AP8AAAD/AP8A//8AAP///wAAAAAAAAAAAAAACIc6gAAAAA/4hzLM
YAAACPiHMsZoAACHj4csZoYACHh4hyxoqqAHh4dwCCqiIAh4eA/wERVQBVERD/CHh4ACKqKA
CHh4cAqqhsJ4h4eAAGhmwnj4eAAAhmwjeI+IAAAGzCN4j/AAAAAIo3iAAAAAAAAAAAAAAPgf
AADgBwAAwAMAAIABAACAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgAEAAIABAADAAwAA
4AcAAPgfAAAAAAEAAgAgIBAAAQAEAOgCAAABABAQEAABAAQAKAEAAAIAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
--IUNj13u0A8R66622
--IUNj13u0A8R66622
Content-Type: application/octet-stream;
	name=tour1_09[2].jpg
Content-Transfer-Encoding: base64
Content-ID: <HI9MHtdg>

/9j/4AAQSkZJRgABAgAAZABkAAD/7AARRHVja3kAAQAEAAAALgAA/+4AIUFkb2JlAGTAAAAA
AQMAEAMDBgkAAA1uAAAe8gAALyv/2wCEAAoHBwcHBwoHBwoOCQgJDhAMCgoMEBMPDxAPDxMS
DhAPDxAOEhIVFhcWFRIdHR8fHR0pKSkpKS8vLy8vLy8vLy8BCgkJCgsKDQsLDRANDg0QFA4O
Dg4UFw8PEQ8PFx0VEhISEhUdGhwXFxccGiAgHR0gICgoJigoLy8vLy8vLy8vL//CABEIAKAA
+gMBIgACEQEDEQH/xADxAAACAwEBAQAAAAAAAAAAAAAEBQIDBgcBAAEAAwEBAQEAAAAAAAAA
AAAAAAIDAQQFBhAAAQQBAwMEAQQDAQEAAAAAAQIDBAUAERIGECETICIUFTEwQTIjQzUWQiQR
AAIBAwICBgcFAwoDCQAAAAECAwARBCESMRMQQVEiMgUgYXGBQiMUkaGxUjMwYqLB0XKCkrJz
NBU14UNT8MJjo9MkRFR0EgABBAEBBQgDAQAAAAAAAAABABExAiESECBBUWEwQHGxwSIyA4Gh
0fATAQACAgICAgEFAQEAAAAAAAEAESExQVFhcYGRoRDwscHR4fH/2gAMAwEAAhEDEQAAABk+
qt+m+wKcc/PnLrarLp+Lz9Aszp/f6ajdliKkmackLVJecd9DcE0wp+tgqVVXUUrBskPVac/o
1m7PL7rBs8JwZO9LLT6fj4OXgdDUUosIGJpedk7zBIsrEnSZGUoUAXAW6MadpisFmZ2JTMvK
ru3T4VylGqiwetqiRLQNUtM5KL7mnQebu8JU2Ll9/r9mE1vlQV2R9zCrqLAvuEuxSYfQVa5+
Vu/1q8UG1SygGvqao3R+pyzLaIiG3TF+B3XZ5OXvI+vcp3ayqrmY5hkY5nX83iWk5bXyyh6H
2DEBK4e4L/PLApTM8yF9QShU0IypMk9HWnfvSp+JNntPBJMo+FkbqIZezFhiNhRmY33VyVMs
3a6BncnTvDH0oDMzREClBKUfQJtHtAPNafOBjM/v20ObmGxPOZoSL9rcb0j4IBl3gFI74FMT
4gLSVUEbDPgFZiNcV9OucYc4Fbg0q5OTsQLlVYFlo9gQVsRgJ8tpDOXeLgezV3Ad8FWHrRZY
B8l1gT+HtD6mIwNYBfTkU3zOgRNBZTazYMYWTMactM3S2qQrm5WY7YPl5ERmlPXMgVpc5mIV
x7zs7MoFvkU53ZvtOcjHMT6QgVeet3023PKOgZ0IIun8zVWXuz8zMBoedd4d8adkeju2Q9C3
PmS54ZoK21a4KGTEDbYc4MepOhYDRP0HnHVem2SCerOaOtxmj5nV0nd+Kdto+Oo3CLjgm1pg
+GMcqtgxiXcKKa/pWr3YM3bcZZtH0Tk3Rey2Y3GBv+c5ztOkQ4JOl5mNRHuc09QzyJ+DVeiY
V3kpbua8xoFMMfOHuW2goBPhxrPVLWNiqJSKMPlwlgPovKdH32Lua4Pzo6XTYl8gQZnvgvDa
BdHrKlj1J6kPjQfO5dlPPk/Ic13QeRMENQvBU0Ldlzdn6r6Zlztv5i6JdlS1XrOPDzPPofQO
dav6Cm1nzfRfPTKbYmp8p6vwPoPRubWxY/R16PzVwl+Tj//aAAgBAgABBQEjFakJaIODFDXE
9ge2a4MWNQg+0Hot0pO87emuHXB2zTv6Ufxz3Z3zcP1P26bs0HqKgM8icB19Jzbmma+oo1IQ
B+hrmp/W3elwqA3r2+VWeVWKUQ2HfaHjr5VZ5VZ5VZ5DnkOFas1VqXVbfKvdvUUbyQ2oFUjR
OeQ40lS8ke0hfu34V9/8aU6ts/2H/KfIc0eIPmXilu+MFW5vfqreChZDP9ww+Uq/t2J3eSWD
oPIrP7NPdvxhebscad8pjvlLLUgPzWtyHI6vj+F/ytsugzULUyqPJAUy75ZEdWxLaUN+B3Z/
/9oACAEDAAEFASO6tSEMKSrB+Vp1xPYK7ZrgxY1Sg+0HvjjyknyHZmubsJJxPYae7pp1b/hn
uzvm4ej9/X/56bhm0eoqAwuowK19JzbgGa9/SpvcUoSn9AnTNx1/U1zf116OlQG9enlXnkXi
lHxpd9gdXr5F55V55V5vVm9WFa81Xrqc3Kzv0H5cA176JSTjgGvXTtt7JGp/yadNPSD7fQvT
0ntm70HNM06K9Gntz//aAAgBAQABBQGRDaltsSJFW6wpmQmK2EuBQ0m6Kwp7yprERCWJVu8G
0sNoOpSBo8NMKcT782aZoM2joc1yOrtPQMaP9j7HnYd7r0zYo4iG85iaeUcXAcbHx8SMU2hx
CqhxpTFjaxlfeoAf5DvxUm2mZFpxvbaDST7ySE4h3QPvAIRbRFYFapbWHEkdDhwnI6vdaKKS
2wMiJ3hxQC0ODG3EawHmNA41pLcaOfFGDBgBwJXhacViYeNspTiU6Y+vtu0FvLl7qticyHx5
mhUqS6Fpbbjk7ddehw5+7J/stlbcYkFOF9MdD7vfynPOcTMcTgsZORpD61fKVgxJwYDg6DCr
QH34Q6jA02vC2CEte4p0BbSSnBhwnFHog6Ltj7N2SGyzH3jPHiWk41HbOMRkYmveCduEYMT0
1wHBjh7J6ad9wA8icVIRnkSc3DArTCrCrFKwKxKhvsm/KzAjtJyeN8EhQJStKm0LOIO3GZaG
l/eV4b+5bz9k4OmuDBi8HYKVpincUvNUHCrTCvA6Rjb4XgOqTijr0H5kqUIsFXvkKSW96BiX
BnnSA4+VKCicQ088r6qbh7EHE/jBgwYe2KOgcdGpcwr1zzbAuRripIz5GNOr3h4gBS1F9lTX
Qfycc2R4Q902YEyXva77s74lJORYDj7kWK2y34RjiTgxPUYOjqtAT2WtDaftYmOW1ejFWhXj
UKZILcNlACdM0xPbJLu9KdcJOb1Yh5xOKZacU5EjqxMSKR8KPgjtoyAAcQNBkuUlKGnPIlHU
HB0f7oP8bV0qPjUcEZxRhQG4425tGaYE5p7WwV4lGFGFIwJwgjF6nG0dgjNnasTgGdse1Koa
9Cg+hPRz+Dw24iq3rTAabC20ocQnsE5tIzbm3JBCUNN/1JRikYUYE91/yIwJ7AdzleNG9c1y
S2Ehn8tqwHqDmuLxKAtYGLHZ/s6heo3die+p1UcUS49rm7NcKu+muKAz8kntuxSsrz/SOj6d
yG29FIViVYD6F/hn8YvJaTolzErzfm/FvbUxwEguaZ5jhc7A5vwrAzy6r8pOFwJG/K4//OM7
4pzsV4nEK0x6QI7Caq9Wn6e+xEK7VImOTYMh+BcVzEWFcTo3096c0cWWIEubMnQ51S4qRtxH
HrxaZ7MyseYobiQwjj9s5khqfBkmkuChyhvGk17My1eVxm6VlhXWNURx638a+O3ARCpbWxYY
o7xhD6biCr43IceDjMhZxs6jAQRSMtR73lKQ5G4u0hiTaTapizv/APS0H+llMVxkViUobpBp
ecrgzZmUNLO+zlGT5+WQDNqa3/XcflVcjHw8OXcwbDtXFpUfF4qz8a4uG4rmWDZYsnrF4REU
9VMiGKIFvcEioitrhSfnW+XPHSzGrONxZtfV1D0uwsagQZttRR66A3x9tgVLM3krEGAmDdW1
fWB63sWZjRmWdbHrYtqY8KBU3WQo02LySSfhotrjwsznpEp3619Ud2LdV8+yrjx1isp5FwJ6
LBqBQfbWroYr6efZWzrTgZrb9UiRGqsjvM3DcPiTgn3Mp9yU1HRItfhO5c0dDXV9AQaWovJE
+1vloTa8mUj6TjE5LsFIi17HHnlyb6Z88puvsmnLB6K/ErLCJPi8bq36SGxPizeYchtX6uNN
s7O3Ehptli0mGLWVtlGtI3JW2prEyRDroNNIhPQa+tch2bK7hEvknwPFRLaVb3zrLdm4+1Hn
WUr4tcw/FYVJlshH/RVmS6yvXyj4FahI4vEFwa+rdx2miPck+FTx3OU18eudjUVbDYr7SLYM
CNXnkkiDEbZvPK3WU9VVoglqQgfGYespDYisR6qtrIF5SwnIXGYUCTW3HHIM+KzUwE1fF4UJ
2jZlwHLzk0OK1EfaiIiNwKmfB4vTNpYbj1L3JuQ18BD9gxXwoVP9fbwv+cpMetYy761u25OK
5PVBFNfMRmot3TNzXr9tyXeXlHOrI3Iq+XGgXNXTMWF5WyLmRySgksWLtNIjQneNxWodrAgt
SLqLOsvtK42NjyqsUxF5bT/HqbymhR6/k7caU7yepW1QXdbXViJ/F2rW75DX2DSpkfKG+iQm
HeT07SKe0jxbG7u6+U9Mv6CXFr7njlTE/wCzg4oYoY8ncgK1CFbDu25xlhlUVm1lL5LyeHH3
kobSunbFxyU6YsueSlsZNgi1t50WfQOKdqodKqLccpA1c8njsHb1mDVgJzjQHx58GLaxqyMq
JX8W7VEj7jzP31tAkoVuQ9b2FvElJ2pt1sGo2RsIxacUMKdqyMQ5sNdZO1SU21QmdaWUqyVa
XqZ8CLyZbTNrafanyqGVNuzV5OniwsKq9Yr4EKd8S5ubduyx3lFe627J42tuv1Qqvsfp24tx
JjzzyhspqLX6uDJsaCS7KDDy0cqhoZgpKGpbZUmRZVT8benP/9oACAECAgY/AXEpk/YhEbMB
O28+8Nye7ZKlR2znvGN1wVqfopUp1k5UqVKlSpUytLqTKnh6J34qxEBVBQYKwBcIFsOqgJj+
U/BekLXyWt8pzAT8GVRmP2na2MIDTbFfDKqGsGJf0RatmILSyGqtp5FHFj4g/pk7ZAjihdrO
/wDsK1g+C4ROm3yHPqqNWwGHeH4oGkjgFe5cYwFT226yvjfQ/WNjbPsJoban0kZ8F9VTU8X6
AlU11LVw/Raq1e/TkqaaHW/u5qrgn2yzcIXu+u08n9U1A5eAhXSSPl+VY6Czng/8X1n66FyP
ciKBn4dU2i/y5L//2gAIAQMCBj8BcYPn4po8k6/q8ysLO6ERsYVWrTnlusn3gsbZ7hG9ksp9
VDePbOU/d8brgp36KVKB4ouc8FKlSpUqVK0upUnaFhNsxy3XWU79hO7w7Yb3/9oACAEBAQY/
AeXINfhYcRQhzBuiPhk6j/xrfE16B6ugdBZ21oPNePHBuF6z6zSxpoFFgK16brVm0b07VfoF
jYq2lMfX090Ve1d4V7+gpIoZDxBrmeXTcv8A8N+HuatuXASPzjUfwX/Cu8v8dvuYCvk47sf+
3YKsFECmubkEyydrfyDqq/Cieksxso1JoKr+LhpVx7q9fpWpF/NRkXxDiKIPDjUw6g38vTxF
cRVhYmv4vQ0rU13jetB0EDoMURKL2jiT7aDyyM6vqwY3tTRdTaUth8oVtvwq/pCo/XVzwqZx
/V9+tFR1ncenRq0Y0C164fDb9iattvV3UE+hcirekKiNWHE0Xl7Nx+y1aKD6z06irKmtbrAV
937O/Tx/YC/bUPeta+tXteT8xqZT8KtVqK9nRqbUCzV4yW/LavD8e73fs9PR7pq3WOI9EUum
4ddMalh+Flb760vp1GtejTo2xAsfVrXgPD1UR6fr6COodHdq3XXG1WDVpQZdbca7tcaVjwcf
f19IX81a1ZNVVzuP8lOvYT06UAe6nxGhHGoUdFz+wJq/bRZzYDjQuWIvwA++vlxtL/CPvqyQ
8eGt/wAK5kpEK9g4/ZWvePrqw6QLkn7uFX6ONd1iKJZRu663Mne9prwH+1XX9taXprdVunTj
1UG9NvZ0LAv9Jv5OgALxq/ilPFv5vSZvs91a9Fum9a9L+3p48KKfZ6Zqw1oyzaljwrwigAPQ
t0AdfGgPtq3ogUKv0X7Sem9etf2BY9XDpv0aV7em3Z0cOnX0h7+m/E0fZ+wsOncOr0NOFes8
K3niei3Gtav0E1p6C+/8en10Ol5iL8sbreyg4kxVDC9ru3H1ga1+ri/x/wA1SYq/TbolVmk3
Pbv7rDbtvfu1Hg5SxNkZG0Y/LY7WLNs724AjU1JmzfTyRRAvIqM+4Acdu5bGo8yBseOKZd6K
28sAeF7C161lxf8AzP5qmgnCibHflybDdSeNwdO2nxMMxqyLzHaQmwBNhbaDeokzDGyz7tjR
E8Vte4YDtoWG5mIVUHEsdABW5mx4ifgLMx95C2rZ5gq3ZS0bRm6MBxtcA6VHOkuOqyqrqp33
AYXsdKJjycVwNDtLHXs0FR4WRBvyZv0BCdyydtibWt13rmZEmNiJ++xY+/QD763oYMleNkYq
x9m4bfvqWDE2RPjgc3n3uCSV22UHUWr9fG/j/mqHn8uf6huXGsN92/qFmA41zcibHxVA13Et
b+kdB99c2KSDKFrgKSpI/dJuv319RG0MK7mTZISXBQ7W3bRpqKCLLikDt3/zVCsscOU2Q/Lj
SFiG3WLXO8eGw1Nfo4vb+q/9n9PjRjlFivH0NrcDoRUawjYrY8hKg6aMnVWHG19r5aBrG2my
XsrzGOPRQ0Xr+Fu2sKDMxjNlSsv08oRTsJcKCSWBHerO/wAF/wAKwf8ABT8KmL+T5krl2vIv
hY3PeHzxofZU0KoYdsr/ACX1dLm4Vj16Vk//AJk/vmsNsOEz8ppN4UgWuFt4iKTI8wgaGLGG
9A1jukOi+EnhxrG5DxrGHJnV2szLtKgLYG+pvTyRj52L81P6NrOPs1rE/wAGP+6Ky18uxzjm
OW09/ibXW9z2Vi82QNEceQwpa23qb23qNX3cr6iPmlBuKpqGa1RDF8yzlx9g5Q3qtl6tGiBF
eb4+9pOWwXe5uzd59WPWah+pwZ8627byPg8N93zE41gT+VeWTY86sdi5HCRuO3xsBpfW9FvN
vLJBCR81UMc6gfvKGBI91I+LzseKQXTlSSRWB/cJt91DGjffycqNOYNN3eXxW69bGs4jQ/Tz
f3GrDn8rh+ozWQ3hZvEhA3nc57tf7Z1f/Yj49lSZuNlOzQIWKTkMCo1sHsCPfUGXPPPzZ0Dn
YygLfWyjYfvrKw8pp4sfFLBJVGzm2cqDuKkcOysHFgyZuVmuY33FWZbWN0O38akzYcrIDRbS
25la4LBTpt4619b5flz/AFXLPKkYo6ndrYqUtY00vm2RJyYJByVjCxfNA77Ehb6brVJiY2bO
d8AmmDcttQwRLkp7ahzfM8udZEPyWFtCp36COPtqLBw8+WYzttmjMYF4rd4luUtvdXLiznjx
4V7i8uJrAcBdkJqOXP8AMJGldQxjSOFVF9bfpkmp87ByspZC9pXva7WGu1ltwo4UmQRfGLia
NUBdNw27g6uBY34UJMjPnVCdoISNtePBYD2Un+n+ZTHKZgqo8SbSvxHvQqNKGRkzNLk91UlO
hXXTaFsBYmjjzeYZD7htZvlKezQiK/31h4EWdKfK5zyw+2MyJtUnZuKHqGhr6vyrLmheeZUm
37HU33HdZk41F5x5nmT83X6bl7YyEvo2i/Fx0qSbAymkljQugkWNg1hew2qvGpvMG8xlSDSP
uqneIG47VZSqgbuynPMyopcsbpcoqGiJuTZmKFQfdULeX+dGdGkCzQrHDJIqfE67IuodtAL5
hkTvikSDbaIoTwbSJNajTM8wlXmX5e8KxO219ViJ66mXGz8gBG2tsCRsL8CLx7teo1KuRK64
sDK+PIlt8jE7rsSD4euv9Jgy5HjKH626x8GFhGCqA3YcaxIHlkx1VHMLwkKxdbd3cb6bb1/n
cjhb/lf+lTkyOs4U8hDJuLP8I2Hq91YVjf5KfhWbhTCIQ47OIGS+5grlNbsQdOyvJtzAWmcm
59QrJUkd8KF9ffXhQwncGfDJitfUoNUb7NKY6QwKXkYnQDcS7H7TWVmy6NlQlwp6k3qqD+yB
S/QNCrX7/PVmFvVsZaw5/M5ccxLIVVYQyG7Ke93y1xUqJMm5lNu8Kikx5FbuDcl+8ptqGHqq
aPNePvSb9ynS20LqWA7K3Y8gdI8QxbgdCwbedp6+NRPi8tppZQm2W57u1iTZWU8QKijyViCR
NvXlKy96xXUszdtXdhzCV4+0cKny4WG5ELRniCeoeuknjI3/ABxHxIw4gisby8zIjy5CXuwB
CgMWNvZRMz/TwKojTb4h8ICDXUVHHgzNNHAOVeT9QbdLMLL+FZkWD5mmOhk3DD2iTRgDezML
W4adlLDkLDNiEa5Ed42B7DGzPf3GlFk/1IunIK25g1G4m2u3bxvWby2Vvkw+E9YL3ry4zMqj
ZkeL18q1YebjyKvMkWCc3G1o3/N7DqKycpGUNHE7xk8NwUlfbrTNzg7yWZ5C1yzEAkn3mkyI
JUM2OwljG4cV1t7xpX6q/wCX+q4jw/k4+L1VjQnHTlSY7SOgFlZgTqwFr1y/poFV+6F5a2Oh
NrW7K+q5a/RBLrB1c29uHZbWmQ4sDW0YctewG3Dsp/LYIQkA2SyWv3UCgsAercdKixfpYFaU
Ny15a67Lbur11HnxQrypFKbfhWUd5SB1XH4VukgTJnVbvLKN5LDXTde3uotm+TEof02hxjKh
HXrt4g1hpj4UmPBKSXiyY9oJAbVFfqpngwIZ5RbbHtRL6694i3Cp2byWKAWA5yvGSlzow2Le
oJERMlmQEzvaQknjYte2vVTrleUwZCg3Q4+zh61m261OyYzYdgvyJfHfW7C/BTTSgXbgi9ZY
6AfbXPzoY5ZY035EzqHJPFrbr6dgp8rEx40yYPmoY1A3BdSp28bihmS48cs0ryXkdQxsGIHi
4aU4xYY4MoC8ciKFufytbiDSRy4cW8QjfeNb7tutzbjesaWXHikkfmbnZFJPzHGpIqTydvLo
Aq3CzBV4hQ+q7fXUU8cfKImRW5Xc3K2hDBbXqQYsaq/iIt47a7WPrpXhxokjnjujKigruHUQ
BYipsnPgV5mflASDdYRdxj3u1gabDjxIdmPjFpAEG3mFo7d21rhT99eVlMaJTJmRI+1FG5Sd
Vaw1FT5Yw4HMKF9vLUXt1eGvqHwIIiGaN02Iw09e0dtf5OPxb/f2ez1cKg8yVZTiQwtE0nLf
xMSdFI3W91Yp8q3zS486zP3GQbArqy3kC8d1qveTmf8AS5T7r9l9u376n/1VmiyJpmm8Dutm
tYAoDwtasvMdpEbIKBXaKSxRFAFtqnrvSTxYPPx4TYZLC0oDaOYlZb8PZepsQysZXW8Sctwd
41XxKBx9dXyN+M7L31dGFr9jWIoYozXz4lI27Y9Ik9ZA1415dmwyM+NjcznS8t7DcLda3oxH
NkjD278SzI2hvoypTw4udmZGXxgikaZhuHC4lULQSZZ8DJbxktMCX67PEbU4n8xfLBN0LoxZ
R+Xurc0MmzxRQIYk3Kdz7iCSbDQC2lYsk0u/FgvKxjBe0g8G7b1DU0I8ZFzhKbMsqskdvXvT
U36rUgyWOJKBYw7HIH9HapFqfGDyRossjRgxP4WYsPCp7ay1y+Z9FJK8mO+w3QE6hh2HjTLA
8k7spAVIn/7yqKg8vzZTFlRb90fLduLs48CkcDT+afVy/Uv8BSTaLrtuF5V+HrqPGxizxrKs
kkxUqoCa2F9bmu425f3QT+FNg5ZdURyYJNjEbW723ugnQ3puXKZZFueWiPcns8Nh76GZl790
0UnOcIx+ZJIj9QvYAWry76dmcY+VHNIeW691eNtwBJ9lS402S6xyqUYiKUEA9l4zXJx8mSRC
xbc8chZmPr5ajqr9GXx7fh8P5vFx/d6T2jUVrW0+E8K7Vp85lByJZZAZCNQqtsCg9Q0rI8rb
b9NHGGXTvX2xtx/rVg5QQCV8qOKQgeNWu1n7fDWtlXQDqGugFQeaQAJbcJ06iSpAkA7eo1gN
18/j/UaoZ4Somx23pvG5TcFdRcdRqf6pUR4JOX8u9j3Q3xe2vpMRImXkiYtJuvqzLbun92oZ
nADymR32iw3M7E2qfzMyho5Q+yLbbYXKkm9/3a8tNtfrIxem5VuZY7N3h3dV7dVTySfRbVRr
+PhbXxaUo/d66yXsN5yXBbrIAW2tPjS2PUHHiR+0dhqDFktuiQI1uFxxpf8AEl/vmm+l+m5O
m3mb93DW+3TjWZuTFkKFd+wNbwj4r34dRpWPxAGljmSKOFyrnYG3d07gBc6ail7DJHf+0KzU
3If/AG8thcdSG1q8Kf7DfgP1O3+l6BWvVW1tQeBp4OQcjGZy6csjeu7UrtawIv66fzJMPJ+t
kXY529Wg4GTb1CoGEHJgxpVmEbEF3ZT120Gl6kxIMaeKWXb332hVsQ17q5PVSx52NLLIgsZY
dpDeuzMtr1AscDwpA/M3SWudCtgqk9vRkLkRyOJpOYrRgMPCFsdQeqjlwo8cfJWEcwAEkMzX
sCdO9UeHkQTF4rjcihla7FhbvDtrI83eGQxZIddi23qCUIJF7fD21i/TQSgY0yzsXAW4X4V7
x1popcTJaOQFXUqmoOhH6tOsXlUocghTZV16teYbUqubttsTU0M+NLIryGVZItpFmA0IZltW
TmCJnxcpgTj3G9SAFDDq1tqK+VhZDNw72xRf27z+FDFyMWd3VnYtCFZbMd3W6nr7KORk+Vzy
SyWu5RLmw2j/AJvqqf6GE4uPIoCRPx3dbWBNr+2lU4+RzFUDbtXiPXutUUTcQNaUhd+x0cp+
YKwJGvbUsWP5YwndGVbwxrtJFr7r9Vf7b/8AE+m4R/q/9X/jxr//2gAIAQIDAT8QyWV24Tpi
ZkWV2ff+w+sV5ltf24PrcorWTl7Y+RMAXMvkagv0WPiZCZOj+5cqlvlnn/UuLFxJhBUpnXVB
ePqNXmOSVTCORJpe5jY759S/CHZJ4HW5cuOYGf0czEuXLlzTPf8AMDHUEOZRaJ4ndy5cuXLm
gD2xHg+s/wARcrHVy5cucJ3MjE8mAJa6ly5cuXCZPXqN2FvmXLly5cuXEhazNdY/MuXLly5c
uXLly5cuN8faGW3LPH4uDcuYhA2QuabjX+zMm0EXy1mGNs4EKLsM25RajD1CpP8AqCpdvc5f
+IauiypxnVwBSrDqOAocquN5IUbhggV1x4ioc6v+qmSIG7SWWAl9mIhkYls/iIFhZWO4tAqt
K67i0x2oxj1CsiUl+D5gihYquM3LcYLa9RNqYSmU1tk3xjFQLUea3RlvqK71QU2woNBcZU3b
vMsCoMEUx/qAp1y8GMJuYrQb0/YR5IXgI/JS3kaFu3HnMHMWSuf7RBJwDeRdHfqVbAuCtKtC
sMLSnyIh61p6XwRiSjlFr0eCOUoW4Cxc5vA1aBmBbrJKdMrrwCYKlvFE34AW+4ijYfDS+fmW
6iQHbLqHW0FQ6O4E5NOAf4Q5wHHD2ioCTReSoSU6FcIyeJfTqhDfPVwjSUhm8VZbUwbRacon
yQ0vXuf/2gAIAQMDAT8Qtt8F8DqG52krv7f7UAPFeSC1/eB9bjFU2GzaxBcYwi2JyNfxBOn9
Nx4zL2ep6R/cuZ2PLOcfszLjCiIV3AQUyrdUF4PiNXkLjkqYOIYi2J3NB8/zLMq3z6l+MO6f
BOWnW+ZcuOYEXmOZiXLly4WIPP8AMDHWb+4IcwZozOG1Xe5cuXLlzTns1BcX1/iNlYcdviXL
lzhO4VMMO7AJfDiXLly5cBU9HiKULe2XLly5cuXBFrU2Kx+ZcuXLly5cuXLly403G2M/MC23
L3PH4v8AELS5gmDZOX1caek82DI5VmKZC8As2OSebFCsK6IUJ9uZe5TXcy7QldyypxHu+O5x
2r3HZ+SKjKp7lNeNsBk1ZcGKgVxL2GniKlFl5hCAA4SpUrxNzfNVCztp14m/YO38SjQqr8dV
BdepUE8X8cSzWJwZjXDK+JTQp6xMdzHPMo+IV43Moj0o4lHZKMzHiJHa2J4FiPzeZTlp8Ygd
dkJhPmWw5zcVSU5iPAwNYSuUT4nAcwKDeZQVXafmU3dT/9oACAEBAwE/EHtIZFl7P8liXUej
3x7f9g4Bdhs9kRWLDnUzVn3KBEat7jC1BQU0bzwFbfBDesD/AGNa6hRFIPEqeMbtiGV4iKtV
RlC6Hslv+oNsjurMQP7m03x7ZY7f8uYaMl57IgQcGYq8mJNmq/EFC3mPxzBsNTmNgrCLVJUt
XiW6jBcDstDEZf8AoyMorgsnzCAXxvzUgYfE2UX2P4ioMyKVr8sUfnA16MsINsdH4Ip4KFBF
0hqZi61Esld6qNARpBFSUH2kUn1lQLfCUaxXEviV+45kWYnfO+oHy2xfBUGMUBTrxKs4Vlwj
cJW+D8pyYYKkpMD5SZU+4mfkYnmNRWC5w5yUBeTmBdo+oOUgcwM0uZYqpes9xVBeMNjiAUHY
tGKuAgiFh1XUPOUK48QCgIrOGbVtshVncQizHsiraKeVqpXdXTg5CJoXgU9TOgIUPB/pKmDI
p26PiAcwPmbOPTAOX8sfhg3p/TGG+IGIzcLBEXUKi+mXFQ1GriV0eEqo8DbeQofEMGjom0lk
+JlN68LFV6VqplmLHqBmszJcG3+pazOcQBOm/uoGjIlAbWEKIOnKaT8ypb5sptz41C3MVtWL
GSXwFtYmE7V1efqfDf3lLff6VxBoxsh+mWfEQRC0RLyysN5KS1DvM1adcxqZMwTSY1NZYYXe
J5fUOm2fkhrVFPiVwykbXiEJreVDx1MOeUYoK/yDFm6pNNxW5VSmrnAe4mMV3cN03MqgGiX/
ACed6ibvtXH6NcTzzCF1GxX8Q5INrcBuWZdHb/Uvyq1VwTk8wMA3WYPWIpdC8cQR0/cE57TL
hmNY4gxlTprPMQL6B/GeJR2Cpc4bZXkajWQlYoolu1lyy+LzMStEyVS1X8Fp7qfnG9utwnGb
nBHhOIiPqL4jpm7YP0B1zNk7f+S+qcXVxkmlZziJs8Mf9lDIE0x5YhKVvEUc9Tk5I2Bvllws
rjMMPVoL0Ko/cyKDMx74jD5blsIKtupZoyQq8VX7gSSqQeLmTZEe4/QVhZOzlDx5YDInG3yu
2eQgoLMeCGpk1qPXiIX+4ahOuAWcpnL5Zl6JTwRtsAFgovKefRF2zRylD8r/ABGK9qgpZ8An
QyitfbHzABbFav6JQBAOAj2b/ENFIAV0LY0AGL5XcA4RYqRpq+PMYvhMMUKVqbFvbhIS6otA
aMdzLBTaL/JxAXun+SnXTyEfAwgL3KArUz1+YzHfF5hDYvfvmL6g1Nko3FZBxR1BS8vupjni
ooDX/ihqDHxKqMQGwBkNeOkLygtxUO+PEB8+uJQbQcEYqwv0wmS9uoqXYeIy0U9z7NOJpj9+
IiA0uKiJflMudufRECszxcS1xp9SgJ/SBC20b35iIOHPtLj3uDRmGpUUGvnUIju7JUMh4N3G
3dOp0RRg+IJQ5nCjuHr2EaBVBmo6advuXsTtOoKDkv4IAxBAy73AdChw+obk3B53uEC1eLi7
XHtNQgj5ZR5obtcErew/NSuDtlepQAC3mXA6b8QmnvP3LiEdXLo4RWJwzK8KsutxxuiuKl38
oQuCfi4AGMbgcdNL3FFbYJQ1Kd348Q2ilt2PN2MqNszQ1REtAFBC4XROYWW2yruBQ3moDZzi
XfMCmoFK6qJ1t1Z5go15lnv/AJMXiY/EEPQPMRj0X4aqEYGqdS6q3MWdTefxDDiDZ5jpeCHy
OYt00V1Ghq/EWCq2e6lCdQKu8w8r8RpnDptl9XJyvPiWAxZ8w04s15IDgZaZpcPuXNdf3CtU
j59xhHXEMzAI2c4/uUQ3/MrS/FzOftlF1P6QWoQg26zUaN6iqrjXiqG2moZqBxALrF9if+DN
Urz2pURqyXbqmL1dteZMEgu8ShlIwK7BT3UCRJPIduk6iakQGRBYGAVCquRjUEIMFokFK5SI
w5wIVLpSxDazhFTyysAZkUr4yT1cBnv1xEopsWJzGmvQgBQrYMLRlYIG1ywOvRCNUr5KSjMG
aMwxdCPqxQUig88eNN9wBp5IYHcdyHqYqlv1tHLB2IB3OGu+EP4UKv4X61USzsEZWl3RSDCE
xc0ZxReV6CBYVQCi5MT6L959mpYEtDvyeGW1TsuU7eSF1jcdBYWMidS0W1mdCrUb4j3AiRNq
rQ8QZVCCqzyWYGukxqCYIcDF+z5xfs+MRqzv+7lHJhjiFpz6CiraxmEUi2ZyEIE8hUUhe6Xw
Ib9qgL17DInaB5Vol4a+jKhfLfyCOXoarhbmpt1ljESS1V7qi7bUu/xBkqVfCRzoceYxjMil
MSijQ6hCAOxk+tZeWfzAFfgOt6YHrNFmAEayzD+JR5XiefgEdTIi/wB0eJ+ZQYL+UFsFSPkR
hEGEwiSSzgUmNNEKU/ieTy/4WvP4gMpLSquJWrOYC2GKx6APaDGzitJkJuMVo5CbCKW+DMAi
QeUo4CSocpoHiAZUwuq8ML4NfrdgLV43H0N4zII8LwDrMMjQeKgdHRtJSSf7uNw6Blm4XUcv
h9sPFsozoKEWq4diS0MdHVQS64VQYxKDnCGALCk8vxKlFoawgtNKXgvgthi2Gm5YSVAq3pc0
YlGGoBglsE+U+Zlj6oQ8Mv7TGITAKIUstR3FSiq4UjVG1AYqH3ICuQZ405lURa002I8iy63A
PyNhYJdugRkQoUtsD1DPcDYKq6jN9GuSD6u3ftJVdsb6KscW4QD2RA91GoQa0VhliAIWtrJZ
C00e4bUJBVmFFdVZqfvhX9vO5fLmGm5obbrAiiQAUbyUT4gZEAAsVgC2hFPAoChEW/MYbJRQ
U4O0TvQqcUjq58IJlkSx94Evw27ioPixBmIrJKYzA33ABPinMlwBSCcMQZKPJWIpNaQoByoq
B6NRdSJoMAFaTL0AxQ49MHeoIFxuACu6zKkC5RoFtQLBUT5o7Bi7Blgv7QEsuLOKg+qBUPnk
KdPJmHgXIFYSONPNEv4uMwQrSbCsMrMEUAY7YIVwxKq1NaMrMD3VkxGK2kMayAQ4M34hrgSq
GvT2XB81KSChoToHVkFa7VAWOTumOthTMWKNcxxFZmnFkOXYGOZdYIUhuvlIYpuWL231cvc/
ZH+x5wY8l9S6sve5WZwCOUaLgyiTOQouxLYrw1cEAWOemivcMR6XfkeuyYdysWbZ4lk2Wosp
N1XqEZWDEYdjjGWaQb0Aojn869wNIOItiir/AMq8bNXqdiODoMmKSzYkBrAEFx6YV/nAIdQ6
UqucxJWbTfHNh8PqVVxrVCwdugCmMdSiyATaU/KqjFlT5SpilsB4gkzGvg4Azavmo6OZuhYh
oAKIphghHphoW63xD2auys3yPJd3HZAm2CKC4AigBSKrTwe0DoL0lLXLhvOI55AzK26cpWmC
agfbCtLHDECaM3aGrTeeiZR1618fJWuU4EyWKALOmCTHsSN5WqJmWUSq2ZQg4n+Jv8n72JRm
K9gFCqO4xCul/b8jo7iq/TDNeR/QgxgxVGdb+B6ilqcsjkmd7riGOC0vhavtDGo4P5wrCnpC
LVg+QpTadZ+Id+BUqVUxHsvQTEYMBhGAVc0RBhAKUK3pdU1xFgMGgYXTGNsISIVvMnXks16i
d01EuLP7WFNNJ0JyYTJvccIghgBjKWewJjzA4efChQUYCCuo4paxjURgwPjk4pTMOBWlUbSW
WUrTcJUA6qlGSPuLwwuougrYOZZ2ua5gYDkeVMS4h1CqWE2GJdpc2Qc5pQ8TOI1n+SkV4VUe
SwHtiyix7RZQDW+Qi2EUcRUpqIHuiuOAwJpzgaVCH2TRfRAI/wCCn+9fvPt+jklY/wBAhUDH
cqsu8/xLC18nXuARwAslWQLUcsxdeSuUrftwo3OBbTwXC+2CLCbVAoN7UCV6iaBoPGfsxLBY
DO1N5fmpf+EHUqEmykbGYRatFlZLAYs3qV6jEA4otCY6thitDuBy7sOOYlYdAzTeI/k+9D3s
t1H2tRU3ZQsJrQygboJfDE4fFRQgdkOJcKF06LIuwxjkgfrfJBSPe4QYUcc1/k732iq4h0xl
gqooXPLQx8aVA1aXH5fzHWoxgW9SpJhA6RNH4goAZMLTV4Qqfsd/azuEyhmCF1Tj0w0SrWzu
OPEm/h8y2LnAqyjIEw3K/wDFBaCvANfVGeY5kV0bAW7laQAWNSirTEJYW+0wNlDfmK79Tlqn
kFuGwxg+W3hEkfSFoYCGvAIUrLhQkVhjkEBTc3a2zXcOUY8S9VCxXmiUjYoxqOiMWjcjCKVW
o80zCEdBdRQLud5QkVF/nUs5lmNjrOJYrjhX+RWLB2qdeDiMGAfAqoFo4gI+11QUCVCMMRcC
QNVFY1vMxxmB53KUBnrwisCsysJJEsGWFs4zPL/eWdQ//9=9
--IUNj13u0A8R66622--

From dom@algor.co.uk Wed Jan  8 19:02:29 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 08 Jan 2003 19:02:29 +0000 (GMT)
Received: from alg145.algor.co.uk ([IPv6:::ffff:62.254.210.145]:29197 "EHLO
	dmz.algor.co.uk") by linux-mips.org with ESMTP id <S8226057AbTAHTC3>;
	Wed, 8 Jan 2003 19:02:29 +0000
Received: from alg158.algor.co.uk ([62.254.210.158] helo=olympia.algor.co.uk)
	by dmz.algor.co.uk with esmtp (Exim 3.35 #1 (Debian))
	id 18WLbe-0004iw-00; Wed, 08 Jan 2003 19:11:14 +0000
Received: from arsenal.algor.co.uk ([192.168.192.197] ident=mail)
	by olympia.algor.co.uk with esmtp (Exim 3.36 #1 (Debian))
	id 18WLSq-0006V1-00; Wed, 08 Jan 2003 19:02:08 +0000
Received: from dom by arsenal.algor.co.uk with local (Exim 3.35 #1 (Debian))
	id 18WLSp-0003Zb-00; Wed, 08 Jan 2003 19:02:07 +0000
From: Dominic Sweetman <dom@mips.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15900.30127.646847.937900@arsenal.algor.co.uk>
Date: Wed, 8 Jan 2003 19:02:07 +0000
To: Ralf Baechle <ralf@linux-mips.org>
Cc: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>,
	linux-mips@linux-mips.org
Subject: Re: [patch] Use XKPHYS for 64-bit TLB flushes
In-Reply-To: <20030108145953.B8396@linux-mips.org>
References: <Pine.GSO.3.96.1030108141332.1580F-100000@delta.ds2.pg.gda.pl>
	<20030108145953.B8396@linux-mips.org>
X-Mailer: VM 7.03 under 21.4 (patch 6) "Common Lisp" XEmacs Lucid
X-MTUK-Scanner: Found to be clean
X-MTUK-SpamCheck: not spam, SpamAssassin (score=-1.2, required 5, AWL,
	IN_REP_TO, QUOTED_EMAIL_TEXT, REFERENCES, SPAM_PHRASE_00_01)
Return-Path: <dom@algor.co.uk>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1098
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: dom@mips.com
Precedence: bulk
X-list: linux-mips


> On Wed, Jan 08, 2003 at 02:27:05PM +0100, Maciej W. Rozycki wrote:
> 
> >  32-bit R4k TLB flush functions use KSEG0 as an impossible (unmapped) VPN2
> > value for invalidated TLB entries.  64-bit ones use KSEG0 as well, but
> > here KSEG0 is a valid XKSEG (mapped) value as it gets interpreted as
> > 0xc00000ff80000000 when written into cp0.EntryHi.  The correct impossible
> > (unmapped) VPN2 value for the 64-bit mode is XKPHYS. 
> 
> That's a funny one.  Historically the idea was to use KSEG0 because the
> for KSEG0 the TLB is not used for translation.  That already failed for
> the Sibyte SB1 which is why we have to use different KSEG0 addresses for
> each entry there.

Amplification: some MIPS CPUs really hate having the same "virtual
address" in more than one TLB entry.  Some of MIPS Technologies' own
cores are the same.

It's probably better to use legal kuseg virtual addresses (but with
the invalid bit set) for initialising TLBs.  And to make them all
different...

--
Dominic Sweetman
mailto:dom@mips.com

From macro@ds2.pg.gda.pl Wed Jan  8 19:18:55 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 08 Jan 2003 19:18:56 +0000 (GMT)
Received: from delta.ds2.pg.gda.pl ([IPv6:::ffff:213.192.72.1]:22251 "EHLO
	delta.ds2.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8226059AbTAHTSz>; Wed, 8 Jan 2003 19:18:55 +0000
Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id UAA10656;
	Wed, 8 Jan 2003 20:18:50 +0100 (MET)
Date: Wed, 8 Jan 2003 20:18:46 +0100 (MET)
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To: Dominic Sweetman <dom@mips.com>
cc: Ralf Baechle <ralf@linux-mips.org>, linux-mips@linux-mips.org
Subject: Re: [patch] Use XKPHYS for 64-bit TLB flushes
In-Reply-To: <15900.30127.646847.937900@arsenal.algor.co.uk>
Message-ID: <Pine.GSO.3.96.1030108200826.7872A-100000@delta.ds2.pg.gda.pl>
Organization: Technical University of Gdansk
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <macro@ds2.pg.gda.pl>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1099
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: macro@ds2.pg.gda.pl
Precedence: bulk
X-list: linux-mips

On Wed, 8 Jan 2003, Dominic Sweetman wrote:

> It's probably better to use legal kuseg virtual addresses (but with

 I'd wait until there is an implementation that breaks with KSEG0 or
XKPHYS addresses.  Hopefully forever. 

> the invalid bit set) for initialising TLBs.  And to make them all
> different...

 They do are different: KSEG0+entry*0x2000, likewise for XKPHYS -- see the
patch. 

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


From uhler@mips.com Wed Jan  8 19:34:04 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 08 Jan 2003 19:34:05 +0000 (GMT)
Received: from ftp.mips.com ([IPv6:::ffff:206.31.31.227]:451 "EHLO
	mx2.mips.com") by linux-mips.org with ESMTP id <S8226063AbTAHTeE>;
	Wed, 8 Jan 2003 19:34:04 +0000
Received: from newman.mips.com (ns-dmz [206.31.31.225])
	by mx2.mips.com (8.12.5/8.12.5) with ESMTP id h08JXH67023968;
	Wed, 8 Jan 2003 11:33:17 -0800 (PST)
Received: from uhler-linux.mips.com (uhler-linux [192.168.11.222])
	by newman.mips.com (8.9.3/8.9.0) with ESMTP id LAA15398;
	Wed, 8 Jan 2003 11:33:01 -0800 (PST)
Received: from uhler-linux.mips.com (uhler@localhost)
	by uhler-linux.mips.com (8.11.2/8.9.3) with ESMTP id h08JX1F09754;
	Wed, 8 Jan 2003 11:33:01 -0800
Message-Id: <200301081933.h08JX1F09754@uhler-linux.mips.com>
X-Authentication-Warning: uhler-linux.mips.com: uhler owned process doing -bs
X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4
To: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
cc: Dominic Sweetman <dom@mips.com>,
	Ralf Baechle <ralf@linux-mips.org>, linux-mips@linux-mips.org
cc: uhler@mips.com
Reply-To: uhler@mips.com
Subject: Re: [patch] Use XKPHYS for 64-bit TLB flushes 
In-reply-to: Your message of "Wed, 08 Jan 2003 20:18:46 +0100."
             <Pine.GSO.3.96.1030108200826.7872A-100000@delta.ds2.pg.gda.pl> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Wed, 08 Jan 2003 11:33:01 -0800
From: "Mike Uhler" <uhler@mips.com>
Return-Path: <uhler@mips.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1100
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: uhler@mips.com
Precedence: bulk
X-list: linux-mips


> 
>  They do are different: KSEG0+entry*0x2000, likewise for XKPHYS -- see the
> patch. 

This is precisely what we use for our internal testing (which is also
exported to MIPS32 and MIPS64 architecture licensees) to initialize the
TLB.  I have not yet seen a case where this fails, and would be interested
in hearing about any case where it does fail.

/gmu

-- 

  =*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
  Michael Uhler, VP, Systems, Architecture, and Software Products 
  MIPS Technologies, Inc.   Email: uhler@mips.com   Pager: uhler_p@mips.com
  1225 Charleston Road      Voice:  (650)567-5025   FAX:   (650)567-5225
  Mountain View, CA 94043   Mobile: (650)868-6870   Admin: (650)567-5085



From ralf@linux-mips.org Wed Jan  8 19:44:22 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 08 Jan 2003 19:44:23 +0000 (GMT)
Received: from p508B6BF1.dip.t-dialin.net ([IPv6:::ffff:80.139.107.241]:11996
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8226065AbTAHToW>; Wed, 8 Jan 2003 19:44:22 +0000
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.11.6/8.11.6) id h08Ji8M28110;
	Wed, 8 Jan 2003 20:44:08 +0100
Date: Wed, 8 Jan 2003 20:44:08 +0100
From: Ralf Baechle <ralf@linux-mips.org>
To: Mike Uhler <uhler@mips.com>
Cc: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>,
	Dominic Sweetman <dom@mips.com>, linux-mips@linux-mips.org
Subject: Re: [patch] Use XKPHYS for 64-bit TLB flushes
Message-ID: <20030108204408.A27888@linux-mips.org>
References: <Pine.GSO.3.96.1030108200826.7872A-100000@delta.ds2.pg.gda.pl> <200301081933.h08JX1F09754@uhler-linux.mips.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5.1i
In-Reply-To: <200301081933.h08JX1F09754@uhler-linux.mips.com>; from uhler@mips.com on Wed, Jan 08, 2003 at 11:33:01AM -0800
Return-Path: <ralf@linux-mips.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1101
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips

On Wed, Jan 08, 2003 at 11:33:01AM -0800, Mike Uhler wrote:

> >  They do are different: KSEG0+entry*0x2000, likewise for XKPHYS -- see the
> > patch. 
> 
> This is precisely what we use for our internal testing (which is also
> exported to MIPS32 and MIPS64 architecture licensees) to initialize the
> TLB.  I have not yet seen a case where this fails, and would be interested
> in hearing about any case where it does fail.

We used to use just KSEG0 instead of KSEG0+entry*0x2000.  That was running
fine over years but had to be changed for the sake of two CPUs afair.  There
was some discussion on this list about this and I accepted the change by that
time because Kevin imho correctly argued that the spec left it unspecified
if an implementation is feeding addresses in an unmapped address space
though the TLB.

  Ralf

From macro@ds2.pg.gda.pl Wed Jan  8 20:11:52 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 08 Jan 2003 20:11:53 +0000 (GMT)
Received: from delta.ds2.pg.gda.pl ([IPv6:::ffff:213.192.72.1]:21997 "EHLO
	delta.ds2.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8226069AbTAHULw>; Wed, 8 Jan 2003 20:11:52 +0000
Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id VAA11713;
	Wed, 8 Jan 2003 21:12:03 +0100 (MET)
Date: Wed, 8 Jan 2003 21:12:03 +0100 (MET)
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To: Ralf Baechle <ralf@linux-mips.org>
cc: Mike Uhler <uhler@mips.com>, Dominic Sweetman <dom@mips.com>,
	linux-mips@linux-mips.org
Subject: Re: [patch] Use XKPHYS for 64-bit TLB flushes
In-Reply-To: <20030108204408.A27888@linux-mips.org>
Message-ID: <Pine.GSO.3.96.1030108210002.11293A-100000@delta.ds2.pg.gda.pl>
Organization: Technical University of Gdansk
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <macro@ds2.pg.gda.pl>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1102
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: macro@ds2.pg.gda.pl
Precedence: bulk
X-list: linux-mips

On Wed, 8 Jan 2003, Ralf Baechle wrote:

> We used to use just KSEG0 instead of KSEG0+entry*0x2000.  That was running
> fine over years but had to be changed for the sake of two CPUs afair.  There
> was some discussion on this list about this and I accepted the change by that
> time because Kevin imho correctly argued that the spec left it unspecified
> if an implementation is feeding addresses in an unmapped address space
> though the TLB.

 Well, like it or not, CAMs do not like multiple matches -- up to a
physical damage even.  So they should be avoided if possible.  While KSEG0
won't match for any real address translation, there is a non-zero
probability of executing a tlbp for it as a result of buggy code or
execution gone wild (root running crashme?). 

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


From gilad@riverhead.com Wed Jan  8 20:32:44 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 08 Jan 2003 20:32:45 +0000 (GMT)
Received: from mxout1.netvision.net.il ([IPv6:::ffff:194.90.9.20]:17292 "EHLO
	mxout1.netvision.net.il") by linux-mips.org with ESMTP
	id <S8226071AbTAHUco>; Wed, 8 Jan 2003 20:32:44 +0000
Received: from Crusty ([62.0.78.173]) by mxout1.netvision.net.il
 (iPlanet Messaging Server 5.2 HotFix 1.08 (built Dec  6 2002))
 with ESMTPA id <0H8E002TCX24WX@mxout1.netvision.net.il> for
 linux-mips@linux-mips.org; Wed, 08 Jan 2003 22:32:30 +0200 (IST)
Date: Wed, 08 Jan 2003 22:15:19 +0200
From: Gilad Benjamini <gilad@riverhead.com>
Subject: ksymoops and 64 bit mips
To: linux-mips@linux-mips.org
Message-id: <ECEPLLMMNGHMFBLHCLMAGEDGDHAA.gilad@riverhead.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Content-type: text/plain; charset=windows-1255
Content-transfer-encoding: 7BIT
Importance: Normal
X-Priority: 3 (Normal)
X-MSMail-priority: Normal
Return-Path: <gilad@riverhead.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1103
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: gilad@riverhead.com
Precedence: bulk
X-list: linux-mips

I tried using ksymoops to analyze an oops on my 64 bit SMP mips kernel.
I am running ksymoops on x86 platform.

Initially I got a lot of garbage.
Upgrdaing to ksymoops 2.4.5 , and using the --truncate=1 and 
-t elf32-little reduced 
the amount of garbage, but still all the output shown
was "No symbol available".

Any additional things I should do ?

TIA


From ralf@linux-mips.org Thu Jan  9 01:36:10 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 09 Jan 2003 01:36:11 +0000 (GMT)
Received: from p508B6BF1.dip.t-dialin.net ([IPv6:::ffff:80.139.107.241]:15840
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8226079AbTAIBgK>; Thu, 9 Jan 2003 01:36:10 +0000
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.11.6/8.11.6) id h091a1a03540;
	Thu, 9 Jan 2003 02:36:01 +0100
Date: Thu, 9 Jan 2003 02:36:01 +0100
From: Ralf Baechle <ralf@linux-mips.org>
To: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
Cc: Mike Uhler <uhler@mips.com>, Dominic Sweetman <dom@mips.com>,
	linux-mips@linux-mips.org
Subject: Re: [patch] Use XKPHYS for 64-bit TLB flushes
Message-ID: <20030109023601.A1213@linux-mips.org>
References: <20030108204408.A27888@linux-mips.org> <Pine.GSO.3.96.1030108210002.11293A-100000@delta.ds2.pg.gda.pl>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5.1i
In-Reply-To: <Pine.GSO.3.96.1030108210002.11293A-100000@delta.ds2.pg.gda.pl>; from macro@ds2.pg.gda.pl on Wed, Jan 08, 2003 at 09:12:03PM +0100
Return-Path: <ralf@linux-mips.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1104
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips

On Wed, Jan 08, 2003 at 09:12:03PM +0100, Maciej W. Rozycki wrote:

>  Well, like it or not, CAMs do not like multiple matches -- up to a
> physical damage even.  So they should be avoided if possible.  While KSEG0
> won't match for any real address translation, there is a non-zero
> probability of executing a tlbp for it as a result of buggy code or
> execution gone wild (root running crashme?). 

I'm told the TLB Shutdown bit in the R4000 is basically implemented as an
overcurrent protection.  That is on many chips even a hit on several
entries won't cause a tlb shutdown until the matches do result in the
TLB drawing more than a certain current.

A tlbp on a KSEG0 address shouldn't happen.  If it's attempted we already
have worse problems.

  Ralf

From lindahl@keyresearch.com Thu Jan  9 02:42:43 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 09 Jan 2003 02:42:43 +0000 (GMT)
Received: from ppp-66-122-194-201.aonnetworks.com ([IPv6:::ffff:66.122.194.201]:23941
	"EHLO localhost.localdomain") by linux-mips.org with ESMTP
	id <S8226083AbTAICmn>; Thu, 9 Jan 2003 02:42:43 +0000
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1])
	by localhost.localdomain (8.12.5/8.12.5) with ESMTP id h092jcDP002663
	for <linux-mips@linux-mips.org>; Wed, 8 Jan 2003 18:45:38 -0800
Received: (from lindahl@localhost)
	by localhost.localdomain (8.12.5/8.12.5/Submit) id h092jcgi002661
	for linux-mips@linux-mips.org; Wed, 8 Jan 2003 18:45:38 -0800
X-Authentication-Warning: localhost.localdomain: lindahl set sender to lindahl@keyresearch.com using -f
Date: Wed, 8 Jan 2003 18:45:38 -0800
From: Greg Lindahl <lindahl@keyresearch.com>
To: linux-mips@linux-mips.org
Subject: IS_ERR() in linux32.c
Message-ID: <20030109024537.GA2653@wumpus.internal.keyresearch.com>
Mail-Followup-To: linux-mips@linux-mips.org
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.4i
Return-Path: <lindahl@keyresearch.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1105
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: lindahl@keyresearch.com
Precedence: bulk
X-list: linux-mips

The file arch/mips64/kernel/linux32.c has a bunch of uses of IS_ERR(),
some against pointers (which is what it's designed to be used with),
and some against integers. I see a patch posted in 2001 which fixes
that, but it was also fixing other things and didn't get applied.

Anyone have a comment? This is about 1/3 of the remaining warnings when
I do "make -s" on the kernel.

-- greg



From giladb@riverhead.com Thu Jan  9 07:27:20 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 09 Jan 2003 07:27:21 +0000 (GMT)
Received: from mxout3.netvision.net.il ([IPv6:::ffff:194.90.9.24]:51913 "EHLO
	mxout3.netvision.net.il") by linux-mips.org with ESMTP
	id <S8225943AbTAIH1U>; Thu, 9 Jan 2003 07:27:20 +0000
Received: from mail.riverhead.com ([194.90.64.163]) by mxout3.netvision.net.il
 (iPlanet Messaging Server 5.2 HotFix 1.08 (built Dec  6 2002))
 with ESMTP id <0H8F00HKNRDCAT@mxout3.netvision.net.il> for
 linux-mips@linux-mips.org; Thu, 09 Jan 2003 09:27:13 +0200 (IST)
Received: from Crusty (comp76.wanwall.com [10.0.0.76])
	by mail.riverhead.com (8.11.0/8.11.0) with SMTP id h097RhY08576	for
 <linux-mips@linux-mips.org>; Thu, 09 Jan 2003 09:27:43 +0200
Date: Thu, 09 Jan 2003 09:09:19 +0200
From: Gilad Benjamini <giladb@riverhead.com>
Subject: kgdb & mips-linux
To: linux-mips@linux-mips.org
Message-id: <ECEPLLMMNGHMFBLHCLMAMEDGDHAA.giladb@riverhead.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Content-type: text/plain; charset=windows-1255
Content-transfer-encoding: 7BIT
Importance: Normal
X-Priority: 3 (Normal)
X-MSMail-priority: Normal
X-RAV-AntiVirus: This e-mail has been scanned for viruses on host:
 mail.riverhead.com
Return-Path: <giladb@riverhead.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1106
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: giladb@riverhead.com
Precedence: bulk
X-list: linux-mips

After many efforts I was able to start a succesfull kgdb session.
However, each time I tell gdb to "continue", it receives a SIGTRAP
in process.c.
I was told that this is probably a yet un-resolved mips SMP issue.

Is this a known issue ?
Any workarounds or solutions ?

TIA


From ralf@linux-mips.org Thu Jan  9 13:38:30 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 09 Jan 2003 13:38:31 +0000 (GMT)
Received: from p508B6BF1.dip.t-dialin.net ([IPv6:::ffff:80.139.107.241]:3818
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8226087AbTAINia>; Thu, 9 Jan 2003 13:38:30 +0000
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.11.6/8.11.6) id h09DcMK24074;
	Thu, 9 Jan 2003 14:38:22 +0100
Date: Thu, 9 Jan 2003 14:38:22 +0100
From: Ralf Baechle <ralf@linux-mips.org>
To: Gilad Benjamini <gilad@riverhead.com>
Cc: linux-mips@linux-mips.org
Subject: Re: ksymoops and 64 bit mips
Message-ID: <20030109143822.A23928@linux-mips.org>
References: <ECEPLLMMNGHMFBLHCLMAGEDGDHAA.gilad@riverhead.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5.1i
In-Reply-To: <ECEPLLMMNGHMFBLHCLMAGEDGDHAA.gilad@riverhead.com>; from gilad@riverhead.com on Wed, Jan 08, 2003 at 10:15:19PM +0200
Return-Path: <ralf@linux-mips.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1107
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips

On Wed, Jan 08, 2003 at 10:15:19PM +0200, Gilad Benjamini wrote:

> Initially I got a lot of garbage.
> Upgrdaing to ksymoops 2.4.5 , and using the --truncate=1 and 
> -t elf32-little reduced 
> the amount of garbage, but still all the output shown
> was "No symbol available".
> 
> Any additional things I should do ?

Possibly your ksymoops is get confused by the System.map file.  The vmlinux
file is a 32-bit ELF file but the System.map file contains the addresses
sign-extended to 64-bit.  As a bandaid you can just chop off the high
32-bits of all addresses in System.map.

  Ralf

From macro@ds2.pg.gda.pl Thu Jan  9 14:03:06 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 09 Jan 2003 14:03:07 +0000 (GMT)
Received: from delta.ds2.pg.gda.pl ([IPv6:::ffff:213.192.72.1]:61335 "EHLO
	delta.ds2.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8226089AbTAIODG>; Thu, 9 Jan 2003 14:03:06 +0000
Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id PAA01439;
	Thu, 9 Jan 2003 15:03:16 +0100 (MET)
Date: Thu, 9 Jan 2003 15:03:14 +0100 (MET)
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To: Ralf Baechle <ralf@linux-mips.org>
cc: Gilad Benjamini <gilad@riverhead.com>, linux-mips@linux-mips.org
Subject: Re: ksymoops and 64 bit mips
In-Reply-To: <20030109143822.A23928@linux-mips.org>
Message-ID: <Pine.GSO.3.96.1030109144947.225C-100000@delta.ds2.pg.gda.pl>
Organization: Technical University of Gdansk
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <macro@ds2.pg.gda.pl>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1108
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: macro@ds2.pg.gda.pl
Precedence: bulk
X-list: linux-mips

On Thu, 9 Jan 2003, Ralf Baechle wrote:

> > Initially I got a lot of garbage.
> > Upgrdaing to ksymoops 2.4.5 , and using the --truncate=1 and 
> > -t elf32-little reduced 
> > the amount of garbage, but still all the output shown
> > was "No symbol available".
> > 
> > Any additional things I should do ?
> 
> Possibly your ksymoops is get confused by the System.map file.  The vmlinux
> file is a 32-bit ELF file but the System.map file contains the addresses
> sign-extended to 64-bit.  As a bandaid you can just chop off the high
> 32-bits of all addresses in System.map.

 Recent versions of ksymoops contain code to handle 64-bit MIPS flexibly
and are expected to take care of address aliases.  They don't works very
well, though, and I've done a few fixes.  They are available in a ksymoops
2.4.8 package at my site and hopefully will be applied in a future
release.

 Anyway the cross-ksymoops case referred by Gilad is tricky -- you need to
build ksymoops linking against an appropriate BFD library, i.e. one that
supports a MIPS64 target.  Additionally MIPS64-specific nm and objdump
programs have to be available to that ksymoops binary (cf. KSYMOOPS_NM and
KSYMOOPS_OBJDUMP environment variables). 

 For detailed information on using a cross-setup see the ksymoops
documentation.

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


From gilad@riverhead.com Thu Jan  9 14:06:25 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 09 Jan 2003 14:06:26 +0000 (GMT)
Received: from mxout1.netvision.net.il ([IPv6:::ffff:194.90.9.20]:20975 "EHLO
	mxout1.netvision.net.il") by linux-mips.org with ESMTP
	id <S8226089AbTAIOGZ>; Thu, 9 Jan 2003 14:06:25 +0000
Received: from mail.riverhead.com ([194.90.64.163]) by mxout1.netvision.net.il
 (iPlanet Messaging Server 5.2 HotFix 1.08 (built Dec  6 2002))
 with ESMTP id <0H8G0043N9UBNX@mxout1.netvision.net.il>; Thu,
 09 Jan 2003 16:06:12 +0200 (IST)
Received: from GILAD (comp113.wanwall.com [10.0.0.113])
	by mail.riverhead.com (8.11.0/8.11.0) with SMTP id h09E6kY17405; Thu,
 09 Jan 2003 16:06:46 +0200
Date: Thu, 09 Jan 2003 16:01:01 +0200
From: Gilad Benjamini <gilad@riverhead.com>
Subject: RE: ksymoops and 64 bit mips
In-reply-to: <20030109143822.A23928@linux-mips.org>
To: 'Ralf Baechle' <ralf@linux-mips.org>,
	Gilad Benjamini <gilad@riverhead.com>
Cc: linux-mips@linux-mips.org
Message-id: <001801c2b7e7$8b3c04d0$7100000a@riverhead.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0)
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
Importance: Normal
X-Priority: 3 (Normal)
X-MSMail-priority: Normal
X-RAV-AntiVirus: This e-mail has been scanned for viruses on host:
 mail.riverhead.com
Return-Path: <gilad@riverhead.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1109
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: gilad@riverhead.com
Precedence: bulk
X-list: linux-mips

Au contraire.
System.map has 32 bit addresses, which I tried to sign extended 
with "ffffffff" (the wonders of sed), but that didn't help.

> -----Original Message-----
> From: Ralf Baechle [mailto:ralf@linux-mips.org]
> Sent: Thursday, January 09, 2003 3:38 PM
> To: Gilad Benjamini
> Cc: linux-mips@linux-mips.org
> Subject: Re: ksymoops and 64 bit mips
> 
> 
> On Wed, Jan 08, 2003 at 10:15:19PM +0200, Gilad Benjamini wrote:
> 
> > Initially I got a lot of garbage.
> > Upgrdaing to ksymoops 2.4.5 , and using the --truncate=1 and 
> > -t elf32-little reduced 
> > the amount of garbage, but still all the output shown
> > was "No symbol available".
> > 
> > Any additional things I should do ?
> 
> Possibly your ksymoops is get confused by the System.map 
> file.  The vmlinux
> file is a 32-bit ELF file but the System.map file contains 
> the addresses
> sign-extended to 64-bit.  As a bandaid you can just chop off the high
> 32-bits of all addresses in System.map.
> 
>   Ralf
> 

From gilad@riverhead.com Thu Jan  9 14:06:45 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 09 Jan 2003 14:06:46 +0000 (GMT)
Received: from mxout1.netvision.net.il ([IPv6:::ffff:194.90.9.20]:20975 "EHLO
	mxout1.netvision.net.il") by linux-mips.org with ESMTP
	id <S8226091AbTAIOG0>; Thu, 9 Jan 2003 14:06:26 +0000
Received: from mail.riverhead.com ([194.90.64.163]) by mxout1.netvision.net.il
 (iPlanet Messaging Server 5.2 HotFix 1.08 (built Dec  6 2002))
 with ESMTP id <0H8G0043N9UBNX@mxout1.netvision.net.il>; Thu,
 09 Jan 2003 16:06:14 +0200 (IST)
Received: from exchange.riverhead.com (exchange.wanwall.com [10.0.0.10])
	by mail.riverhead.com (8.11.0/8.11.0) with ESMTP id h09E6mY17412; Thu,
 09 Jan 2003 16:06:48 +0200
Date: Thu, 09 Jan 2003 16:01:03 +0200
From: Gilad Benjamini <gilad@riverhead.com>
Subject: RE: ksymoops and 64 bit mips
To: Ralf Baechle <ralf@linux-mips.org>,
	Gilad Benjamini <gilad@riverhead.com>
Cc: linux-mips@linux-mips.org
Message-id: <328392AA673C0A49B54DABA457E37DAA458D@exchange.riverhead.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft Exchange V6.0.4417.0
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
Content-class: urn:content-classes:message
Thread-topic: ksymoops and 64 bit mips
Thread-index: AcK354pUgK49iMd+ShSpD+xdCoGTlA==
X-RAV-AntiVirus: This e-mail has been scanned for viruses on host:
 mail.riverhead.com
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Return-Path: <gilad@riverhead.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1110
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: gilad@riverhead.com
Precedence: bulk
X-list: linux-mips

Au contraire.
System.map has 32 bit addresses, which I tried to sign extended 
with "ffffffff" (the wonders of sed), but that didn't help.

> -----Original Message-----
> From: Ralf Baechle [mailto:ralf@linux-mips.org]
> Sent: Thursday, January 09, 2003 3:38 PM
> To: Gilad Benjamini
> Cc: linux-mips@linux-mips.org
> Subject: Re: ksymoops and 64 bit mips
> 
> 
> On Wed, Jan 08, 2003 at 10:15:19PM +0200, Gilad Benjamini wrote:
> 
> > Initially I got a lot of garbage.
> > Upgrdaing to ksymoops 2.4.5 , and using the --truncate=1 and 
> > -t elf32-little reduced 
> > the amount of garbage, but still all the output shown
> > was "No symbol available".
> > 
> > Any additional things I should do ?
> 
> Possibly your ksymoops is get confused by the System.map 
> file.  The vmlinux
> file is a 32-bit ELF file but the System.map file contains 
> the addresses
> sign-extended to 64-bit.  As a bandaid you can just chop off the high
> 32-bits of all addresses in System.map.
> 
>   Ralf
> 

From iilangov@cisco.com Thu Jan  9 15:18:29 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 09 Jan 2003 15:18:30 +0000 (GMT)
Received: from sj-msg-core-2.cisco.com ([IPv6:::ffff:171.70.145.30]:14259 "EHLO
	sj-msg-core-2.cisco.com") by linux-mips.org with ESMTP
	id <S8226095AbTAIPS3>; Thu, 9 Jan 2003 15:18:29 +0000
Received: from cisco.com (megha.cisco.com [192.122.173.140])
	by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id h09FIRfm017781;
	Thu, 9 Jan 2003 07:18:27 -0800 (PST)
Received: from IILANGOVW2K ([10.77.139.167])
	by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with SMTP id UAA05081;
	Thu, 9 Jan 2003 20:47:23 +0530 (IST)
Message-ID: <040b01c2b7f2$56ff0f40$a78b4d0a@apac.cisco.com>
From: "Indukumar Ilangovan" <iilangov@cisco.com>
To: <linux-kernel@vger.kernel.org>, <linux-mips@linux-mips.org>
Subject: [OT] cross-compiler problem
Date: Thu, 9 Jan 2003 20:48:18 +0530
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 6.00.2600.0000
x-mimeole: Produced By Microsoft MimeOLE V6.00.2600.0000
Return-Path: <iilangov@cisco.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1111
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: iilangov@cisco.com
Precedence: bulk
X-list: linux-mips

Hi All,

I tried to build cross compiler on Red Hat Linux
Kernel 2.4.2-2 on an i686.
I use binutils-2.13, gcc-3.2, glibc-2.2.5, glibc-2.2.5-mips-build-gmon.diff,
glibc-linuxthreads.tar.gz.
I followed the instructions from
http://www.ltc.com/~brad/mips/mipsel-linux-cross-toolchain-building.txt

I installed binutils  without any problems.

While compiling glibc2.2.5 I get the following error.

../sysdeps/unix/syscall.S: Assembler messages:
../sysdeps/unix/syscall.S:28: Error: absolute expression required `li'
make[2]: *** [/home/iilangov/crossGCC/mips/mips-glibc/misc/syscall.o] Error
1
make[2]: Leaving directory `/home/iilangov/crossGCC/mips/glibc-2.2.5/misc'
make[1]: *** [misc/subdir_lib] Error 2
make[1]: Leaving directory `/home/iilangov/crossGCC/mips/glibc-2.2.5'
make: *** [all] Error 2

I have "asm/unistd.h" in the include path, still this problem is happening.
Do you guys have any clue ?

Thanks in Advance !
Indu


----- Original Message -----
From: "Alexandre Oliva" <aoliva@redhat.com>
To: "Khantharat Anekboon" <dfos1@hotmail.com>
Cc: <crossgcc@sources.redhat.com>
Sent: Saturday, December 28, 2002 12:22 PM
Subject: Re: cross-compiler problem


| On Dec 28, 2002, "Khantharat Anekboon" <dfos1@hotmail.com> wrote:
|
| > ../sysdeps/unix/syscall.S:28: Error: absolute expression required 'li'
|
| Looks like you're missing the kernel headers where the syscall numbers
| are defined.  (.../include/asm/unistd.h)
|
| --
| Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
| Red Hat GCC Developer                 aoliva@{redhat.com, gcc.gnu.org}
| CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
| Free Software Evangelist                Professional serial bug killer
|
| ------
| Want more information?  See the CrossGCC FAQ,
http://www.objsw.com/CrossGCC/
| Want to unsubscribe? Send a note to
crossgcc-unsubscribe@sources.redhat.com

********************************************************
Indukumar Ilangovan
HCL-Cisco Offshore development center,
49-50, Nelson Manickam Road, Chennai - 600029 ,  India .
TEL:  +91-44-2374 1939 x 2215 FAX: +91-44-3741038
Email :iilangov@cisco.com


From krishnakumar@naturesoft.net Thu Jan  9 15:32:19 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 09 Jan 2003 17:06:27 +0000 (GMT)
Received: from [IPv6:::ffff:203.145.184.221] ([IPv6:::ffff:203.145.184.221]:29968
	"EHLO naturesoft.net") by linux-mips.org with ESMTP
	id <S8226098AbTAIPcT> convert rfc822-to-8bit; Thu, 9 Jan 2003 15:32:19 +0000
Received: from [192.168.0.15] (helo=krishna.royalchallenge.com)
	by naturesoft.net with esmtp (Exim 3.35 #1)
	id 18Weem-0000qg-00; Thu, 09 Jan 2003 21:01:44 +0530
Content-Type: text/plain;
  charset="iso-8859-1"
From: "Krishnakumar. R" <krishnakumar@naturesoft.net>
Reply-To: krishnakumar@naturesoft.net
To: "Indukumar Ilangovan" <iilangov@cisco.com>
Subject: Re: [OT] cross-compiler problem
Date: Thu, 9 Jan 2003 21:01:12 +0530
User-Agent: KMail/1.4.1
References: <040b01c2b7f2$56ff0f40$a78b4d0a@apac.cisco.com>
In-Reply-To: <040b01c2b7f2$56ff0f40$a78b4d0a@apac.cisco.com>
Cc: <linux-mips@linux-mips.org>
MIME-Version: 1.0
Content-Transfer-Encoding: 8BIT
Message-Id: <200301092101.12871.krishnakumar@naturesoft.net>
Return-Path: <krishnakumar@naturesoft.net>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1112
X-Approved-By: ralf@linux-mips.org
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: krishnakumar@naturesoft.net
Precedence: bulk
X-list: linux-mips

Hi,

Have you changed the /usr/src/linux/include/asm 
link to point to the asm-mips.
IMHO you should do it.

Hope it helps
Regards
KK





On Thursday 09 January 2003 08:48 pm, you wrote:
> Hi All,
>
> I tried to build cross compiler on Red Hat Linux
> Kernel 2.4.2-2 on an i686.
> I use binutils-2.13, gcc-3.2, glibc-2.2.5,
> glibc-2.2.5-mips-build-gmon.diff, glibc-linuxthreads.tar.gz.
> I followed the instructions from
> http://www.ltc.com/~brad/mips/mipsel-linux-cross-toolchain-building.txt
>
> I installed binutils  without any problems.
>
> While compiling glibc2.2.5 I get the following error.
>
> ../sysdeps/unix/syscall.S: Assembler messages:
> ../sysdeps/unix/syscall.S:28: Error: absolute expression required `li'
> make[2]: *** [/home/iilangov/crossGCC/mips/mips-glibc/misc/syscall.o] Error
> 1
> make[2]: Leaving directory `/home/iilangov/crossGCC/mips/glibc-2.2.5/misc'
> make[1]: *** [misc/subdir_lib] Error 2
> make[1]: Leaving directory `/home/iilangov/crossGCC/mips/glibc-2.2.5'
> make: *** [all] Error 2
>
> I have "asm/unistd.h" in the include path, still this problem is happening.
> Do you guys have any clue ?
>
> Thanks in Advance !
> Indu
>
>
> ----- Original Message -----
> From: "Alexandre Oliva" <aoliva@redhat.com>
> To: "Khantharat Anekboon" <dfos1@hotmail.com>
> Cc: <crossgcc@sources.redhat.com>
> Sent: Saturday, December 28, 2002 12:22 PM
> Subject: Re: cross-compiler problem
>
> | On Dec 28, 2002, "Khantharat Anekboon" <dfos1@hotmail.com> wrote:
> | > ../sysdeps/unix/syscall.S:28: Error: absolute expression required 'li'
> |
> | Looks like you're missing the kernel headers where the syscall numbers
> | are defined.  (.../include/asm/unistd.h)
> |
> | --
> | Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
> | Red Hat GCC Developer                 aoliva@{redhat.com, gcc.gnu.org}
> | CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
> | Free Software Evangelist                Professional serial bug killer
> |
> | ------
> | Want more information?  See the CrossGCC FAQ,
>
> http://www.objsw.com/CrossGCC/
>
> | Want to unsubscribe? Send a note to
>
> crossgcc-unsubscribe@sources.redhat.com
>
> ********************************************************
> Indukumar Ilangovan
> HCL-Cisco Offshore development center,
> 49-50, Nelson Manickam Road, Chennai - 600029 ,  India .
> TEL:  +91-44-2374 1939 x 2215 FAX: +91-44-3741038
> Email :iilangov@cisco.com


From cvieira@mediaprimer.pt Thu Jan  9 17:32:39 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 09 Jan 2003 17:32:39 +0000 (GMT)
Received: from a213-22-99-250.netcabo.pt ([IPv6:::ffff:213.22.99.250]:62725
	"EHLO orion.mediaprimer.pt") by linux-mips.org with ESMTP
	id <S8226086AbTAIRcj>; Thu, 9 Jan 2003 17:32:39 +0000
Received: from pc03.mediaprimer.pt ([192.168.0.32])
	by orion.mediaprimer.pt (8.12.6/8.12.6) with ESMTP id h09J8IUE013154
	for <linux-mips@linux-mips.org>; Thu, 9 Jan 2003 19:08:41 GMT
Message-Id: <5.0.2.1.2.20030109172726.02a694e0@192.168.0.1>
X-Sender: cvieira@192.168.0.1
X-Mailer: QUALCOMM Windows Eudora Version 5.0.2
Date: Thu, 09 Jan 2003 17:29:03 +0000
To: linux-mips@linux-mips.org
From: Carlos Vieira <cvieira@mediaprimer.pt>
Subject: SGI INDY and RedHat
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Return-Path: <cvieira@mediaprimer.pt>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1113
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: cvieira@mediaprimer.pt
Precedence: bulk
X-list: linux-mips

Hi,

I have an SGI Indy with R5000 MIPS processor
and with IRIX OS.
I want to make this machine a DNS Server with
RedHat for MIPS processor.
How can i install RedHat in this machine without
using IRIX that is installed.
Netboot at machine boot time is a good option (using bootp server
for downloading kernel and then get the rest of the
OS installation)?

Thanks in advance

	Carlos


From carstenl@linux-mips.org Thu Jan  9 20:09:12 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 09 Jan 2003 20:09:13 +0000 (GMT)
Received: from cpe.atm2-0-1031142.0x50c4469e.albnxx9.customer.tele.dk ([IPv6:::ffff:80.196.70.158]:33285
	"EHLO localhost.localdomain") by linux-mips.org with ESMTP
	id <S8226107AbTAIUJM>; Thu, 9 Jan 2003 20:09:12 +0000
Received: from linux-mips.org (localhost.localdomain [127.0.0.1])
	by localhost.localdomain (8.11.2/8.11.2) with ESMTP id h09KA2L01409;
	Thu, 9 Jan 2003 21:10:02 +0100
Message-ID: <3E1DD719.2464A916@linux-mips.org>
Date: Thu, 09 Jan 2003 21:10:01 +0100
From: Carsten Langgaard <carstenl@linux-mips.org>
X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.20 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Ralf Baechle <ralf@linux-mips.org>
CC: Mike Uhler <uhler@mips.com>,
	"Maciej W. Rozycki" <macro@ds2.pg.gda.pl>,
	Dominic Sweetman <dom@mips.com>, linux-mips@linux-mips.org
Subject: Re: [patch] Use XKPHYS for 64-bit TLB flushes
References: <Pine.GSO.3.96.1030108200826.7872A-100000@delta.ds2.pg.gda.pl> <200301081933.h08JX1F09754@uhler-linux.mips.com> <20030108204408.A27888@linux-mips.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Return-Path: <carstenl@linux-mips.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1114
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: carstenl@linux-mips.org
Precedence: bulk
X-list: linux-mips

Ralf Baechle wrote:

> On Wed, Jan 08, 2003 at 11:33:01AM -0800, Mike Uhler wrote:
>
> > >  They do are different: KSEG0+entry*0x2000, likewise for XKPHYS -- see the
> > > patch.
> >
> > This is precisely what we use for our internal testing (which is also
> > exported to MIPS32 and MIPS64 architecture licensees) to initialize the
> > TLB.  I have not yet seen a case where this fails, and would be interested
> > in hearing about any case where it does fail.
>
> We used to use just KSEG0 instead of KSEG0+entry*0x2000.  That was running
> fine over years but had to be changed for the sake of two CPUs afair.  There
> was some discussion on this list about this and I accepted the change by that
> time because Kevin imho correctly argued that the spec left it unspecified
> if an implementation is feeding addresses in an unmapped address space
> though the TLB.
>

All MIPS's CPUs need these unique TLB entries otherwise you get a machine check
error.
Inspired by Kevin Kissell's changes to openBSD, I made the above change
(KSEG0+entry*0x2000) to the TLB routine in linux. It was done when we first tried
to boot linux on the MIPS 4Kc CPU, a couple of years ago.


>
>   Ralf


From atulsrivastava9@rediffmail.com Fri Jan 10 10:18:14 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 10 Jan 2003 10:18:15 +0000 (GMT)
Received: from webmail29.rediffmail.com ([IPv6:::ffff:203.199.83.39]:16315
	"HELO rediffmail.com") by linux-mips.org with SMTP
	id <S8226112AbTAJKSO>; Fri, 10 Jan 2003 10:18:14 +0000
Received: (qmail 7451 invoked by uid 510); 10 Jan 2003 10:14:03 -0000
Date: 10 Jan 2003 10:14:03 -0000
Message-ID: <20030110101403.7450.qmail@webmail29.rediffmail.com>
Received: from unknown (203.196.179.98) by rediffmail.com via HTTP; 10 jan 2003 10:14:03 -0000
MIME-Version: 1.0
From: "atul srivastava" <atulsrivastava9@rediffmail.com>
Reply-To: "atul srivastava" <atulsrivastava9@rediffmail.com>
To: linux-mips@linux-mips.org
Subject: handling of s-record images by bootloader
Content-type: text/plain;
	format=flowed
Content-Disposition: inline
Return-Path: <atulsrivastava9@rediffmail.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1115
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: atulsrivastava9@rediffmail.com
Precedence: bulk
X-list: linux-mips

Hello .

A quick question..

I have developed a primitive bootloader for custom board, that is 
successfuly doing the board bringup and loads linux os image
currently through serial link (kermit) only.
network link is also likely to be up soon.

but through serial it loads  kernel image only in raw binary 
format.
now i want to extend this for s-record images as well..

I am umware that, how differently s-record image need to be 
handled..?
i just need some idea or if possible any example code for that..

Best Reagards,
Atul





From atulsrivastava9@rediffmail.com Fri Jan 10 10:20:59 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 10 Jan 2003 10:21:00 +0000 (GMT)
Received: from webmail27.rediffmail.com ([IPv6:::ffff:203.199.83.37]:32689
	"HELO rediffmail.com") by linux-mips.org with SMTP
	id <S8226116AbTAJKU7>; Fri, 10 Jan 2003 10:20:59 +0000
Received: (qmail 27154 invoked by uid 510); 10 Jan 2003 10:17:15 -0000
Date: 10 Jan 2003 10:17:15 -0000
Message-ID: <20030110101715.27153.qmail@webmail27.rediffmail.com>
Received: from unknown (203.196.179.98) by rediffmail.com via HTTP; 10 jan 2003 10:17:15 -0000
MIME-Version: 1.0
From: "atul srivastava" <atulsrivastava9@rediffmail.com>
Reply-To: "atul srivastava" <atulsrivastava9@rediffmail.com>
To: linux-mips@linux-mips.org
Subject: handling of s-record images by bootloader
Content-type: text/plain;
	format=flowed
Content-Disposition: inline
Return-Path: <atulsrivastava9@rediffmail.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1116
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: atulsrivastava9@rediffmail.com
Precedence: bulk
X-list: linux-mips

Hello .

A quick question..

I have developed a primitive bootloader for custom board, that is 
successfuly doing the board bringup and loads linux os image
currently through serial link (kermit) only.
network link is also likely to be up soon.

but through serial it loads  kernel image only in raw binary 
format.
now i want to extend this for s-record images as well..

I am umware that, how differently s-record image need to be 
handled..?
i just need some idea or if possible any example code for that..

Best Reagards,
Atul





From Jon_Burgess@eur.3com.com Fri Jan 10 10:21:58 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 10 Jan 2003 10:21:59 +0000 (GMT)
Received: from ip-161-71-171-238.corp-eur.3com.com ([IPv6:::ffff:161.71.171.238]:4807
	"EHLO columba.www.eur.3com.com") by linux-mips.org with ESMTP
	id <S8226119AbTAJKV6>; Fri, 10 Jan 2003 10:21:58 +0000
Received: from toucana.eur.3com.com (toucana.EUR.3Com.COM [140.204.220.50])
	by columba.www.eur.3com.com  with ESMTP id h0AANYNS006441;
	Fri, 10 Jan 2003 10:23:34 GMT
Received: from notesmta.eur.3com.com (eurmta1.EUR.3Com.COM [140.204.220.206])
	by toucana.eur.3com.com  with SMTP id h0AANKQ03089;
	Fri, 10 Jan 2003 10:23:20 GMT
Received: by notesmta.eur.3com.com(Lotus SMTP MTA v4.6.3  (733.2 10-16-1998))  id 80256CAA.0038F253 ; Fri, 10 Jan 2003 10:22:00 +0000
X-Lotus-FromDomain: 3COM
From: "Jon Burgess" <Jon_Burgess@eur.3com.com>
To: "atul srivastava" <atulsrivastava9@rediffmail.com>
cc: linux-mips@linux-mips.org
Message-ID: <80256CAA.0038F181.00@notesmta.eur.3com.com>
Date: Fri, 10 Jan 2003 10:21:42 +0000
Subject: Re: handling of s-record images by bootloader
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Return-Path: <Jon_Burgess@eur.3com.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1117
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: Jon_Burgess@eur.3com.com
Precedence: bulk
X-list: linux-mips



> I am umware that, how differently s-record image need
> to be handled..?
> i just need some idea or if possible any example code for that..

Have you tried looking at binutils? objcopy can convert Binary<->S-Record

     Jon



From Jon_Burgess@eur.3com.com Fri Jan 10 12:36:10 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 10 Jan 2003 12:36:10 +0000 (GMT)
Received: from ip-161-71-171-238.corp-eur.3com.com ([IPv6:::ffff:161.71.171.238]:18922
	"EHLO columba.www.eur.3com.com") by linux-mips.org with ESMTP
	id <S8226125AbTAJMgK>; Fri, 10 Jan 2003 12:36:10 +0000
Received: from toucana.eur.3com.com (toucana.EUR.3Com.COM [140.204.220.50])
	by columba.www.eur.3com.com  with ESMTP id h0ACbcNS017223;
	Fri, 10 Jan 2003 12:37:44 GMT
Received: from notesmta.eur.3com.com (eurmta1.EUR.3Com.COM [140.204.220.206])
	by toucana.eur.3com.com  with SMTP id h0ACbQQ17121;
	Fri, 10 Jan 2003 12:37:26 GMT
Received: by notesmta.eur.3com.com(Lotus SMTP MTA v4.6.3  (733.2 10-16-1998))  id 80256CAA.00453B66 ; Fri, 10 Jan 2003 12:36:11 +0000
X-Lotus-FromDomain: 3COM
From: "Jon Burgess" <Jon_Burgess@eur.3com.com>
To: "atul srivastava" <atulsrivastava9@rediffmail.com>
cc: linux-mips@linux-mips.org
Message-ID: <80256CAA.00453946.00@notesmta.eur.3com.com>
Date: Fri, 10 Jan 2003 12:33:13 +0000
Subject: Re: handling of s-record images by bootloader
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Return-Path: <Jon_Burgess@eur.3com.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1118
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: Jon_Burgess@eur.3com.com
Precedence: bulk
X-list: linux-mips




atul srivastava wrote:
> I am umware that, how differently s-record image need
> to be handled..?
> i just need some idea or if possible any example code for that..


On second thoughts the binutils code is probably rather large. You could try the
pmon source

http://www.carmel.com/pmon/pmon.tgz

pmon/tools/rdsrec.c might do what you want.

     Jon



From macro@ds2.pg.gda.pl Fri Jan 10 12:37:04 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 10 Jan 2003 12:37:05 +0000 (GMT)
Received: from delta.ds2.pg.gda.pl ([IPv6:::ffff:213.192.72.1]:20939 "EHLO
	delta.ds2.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8226128AbTAJMhE>; Fri, 10 Jan 2003 12:37:04 +0000
Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id NAA24336;
	Fri, 10 Jan 2003 13:37:14 +0100 (MET)
Date: Fri, 10 Jan 2003 13:37:12 +0100 (MET)
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To: Ralf Baechle <ralf@linux-mips.org>
cc: linux-mips@linux-mips.org
Subject: [patch] R4k cache code synchronization
Message-ID: <Pine.GSO.3.96.1030110131859.23678B-100000@delta.ds2.pg.gda.pl>
Organization: Technical University of Gdansk
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <macro@ds2.pg.gda.pl>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1119
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: macro@ds2.pg.gda.pl
Precedence: bulk
X-list: linux-mips

Ralf,

 Here are some bits to synchronize c-r4k.c across ports.  There are no
functional changes, at least no intended ones.  OK to apply?

 I can't see any need for flush_cache_l1() and flush_cache_l2().  I'd like
to remove them.  A single flush_cache_all() seems sufficient for our
needs.  Any objections? 

  Maciej

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

patch-mips-2.4.20-pre6-20030107-mips-c-r4k-sync-0
diff -up --recursive --new-file linux-mips-2.4.20-pre6-20030107.macro/arch/mips/mm/c-r4k.c linux-mips-2.4.20-pre6-20030107/arch/mips/mm/c-r4k.c
--- linux-mips-2.4.20-pre6-20030107.macro/arch/mips/mm/c-r4k.c	2002-12-20 03:56:50.000000000 +0000
+++ linux-mips-2.4.20-pre6-20030107/arch/mips/mm/c-r4k.c	2003-01-09 22:23:33.000000000 +0000
@@ -948,12 +948,13 @@ static void r4k_flush_icache_page_p(stru
 static void r4k_dma_cache_wback_inv_pc(unsigned long addr, unsigned long size)
 {
 	unsigned long end, a;
-	unsigned int flags;
 
 	if (size >= dcache_size) {
 		flush_cache_all();
 	} else {
 #ifdef R4600_V2_HIT_CACHEOP_WAR
+		unsigned long flags;
+
 		/* Workaround for R4600 bug.  See comment in <asm/war>. */
 		local_irq_save(flags);
 		*(volatile unsigned long *)KSEG1;
@@ -962,7 +963,7 @@ static void r4k_dma_cache_wback_inv_pc(u
 		a = addr & ~(dc_lsize - 1);
 		end = (addr + size - 1) & ~(dc_lsize - 1);
 		while (1) {
-			flush_dcache_line(a); /* Hit_Writeback_Inv_D */
+			flush_dcache_line(a);	/* Hit_Writeback_Inv_D */
 			if (a == end) break;
 			a += dc_lsize;
 		}
@@ -970,6 +971,7 @@ static void r4k_dma_cache_wback_inv_pc(u
 		local_irq_restore(flags);
 #endif
 	}
+
 	bc_wback_inv(addr, size);
 }
 
@@ -994,12 +996,13 @@ static void r4k_dma_cache_wback_inv_sc(u
 static void r4k_dma_cache_inv_pc(unsigned long addr, unsigned long size)
 {
 	unsigned long end, a;
-	unsigned int flags;
 
 	if (size >= dcache_size) {
 		flush_cache_all();
 	} else {
 #ifdef R4600_V2_HIT_CACHEOP_WAR
+		unsigned long flags;
+
 		/* Workaround for R4600 bug.  See comment in <asm/war>. */
 		local_irq_save(flags);
 		*(volatile unsigned long *)KSEG1;
@@ -1008,7 +1011,7 @@ static void r4k_dma_cache_inv_pc(unsigne
 		a = addr & ~(dc_lsize - 1);
 		end = (addr + size - 1) & ~(dc_lsize - 1);
 		while (1) {
-			flush_dcache_line(a); /* Hit_Writeback_Inv_D */
+			flush_dcache_line(a);	/* Hit_Writeback_Inv_D */
 			if (a == end) break;
 			a += dc_lsize;
 		}
@@ -1016,6 +1019,7 @@ static void r4k_dma_cache_inv_pc(unsigne
 		local_irq_restore(flags);
 #endif
 	}
+
 	bc_inv(addr, size);
 }
 
@@ -1031,7 +1035,7 @@ static void r4k_dma_cache_inv_sc(unsigne
 	a = addr & ~(sc_lsize - 1);
 	end = (addr + size - 1) & ~(sc_lsize - 1);
 	while (1) {
-		flush_scache_line(a); /* Hit_Writeback_Inv_SD */
+		flush_scache_line(a);	/* Hit_Writeback_Inv_SD */
 		if (a == end) break;
 		a += sc_lsize;
 	}
@@ -1232,10 +1236,10 @@ static void __init setup_noscache_funcs(
 		_flush_cache_page = r4k_flush_cache_page_d32i32;
 		break;
 	}
-	___flush_cache_all = _flush_cache_all;
-
 	_flush_icache_page = r4k_flush_icache_page_p;
 
+	___flush_cache_all = _flush_cache_all;
+
 	_dma_cache_wback_inv = r4k_dma_cache_wback_inv_pc;
 	_dma_cache_wback = r4k_dma_cache_wback_inv_pc;
 	_dma_cache_inv = r4k_dma_cache_inv_pc;
@@ -1317,8 +1321,10 @@ static void __init setup_scache_funcs(vo
 		_copy_page = r4k_copy_page_s128;
 		break;
 	}
-	___flush_cache_all = _flush_cache_all;
 	_flush_icache_page = r4k_flush_icache_page_s;
+
+	___flush_cache_all = _flush_cache_all;
+
 	_dma_cache_wback_inv = r4k_dma_cache_wback_inv_sc;
 	_dma_cache_wback = r4k_dma_cache_wback_inv_sc;
 	_dma_cache_inv = r4k_dma_cache_inv_sc;
@@ -1373,10 +1379,10 @@ void __init ld_mmu_r4xx0(void)
 	}
 
 	_flush_cache_sigtramp = r4k_flush_cache_sigtramp;
-	_flush_icache_range = r4k_flush_icache_range;	/* Ouch */
 	if ((read_c0_prid() & 0xfff0) == 0x2020) {
 		_flush_cache_sigtramp = r4600v20k_flush_cache_sigtramp;
 	}
+	_flush_icache_range = r4k_flush_icache_range;	/* Ouch */
 
 	__flush_cache_all();
 }
diff -up --recursive --new-file linux-mips-2.4.20-pre6-20030107.macro/arch/mips64/mm/c-r4k.c linux-mips-2.4.20-pre6-20030107/arch/mips64/mm/c-r4k.c
--- linux-mips-2.4.20-pre6-20030107.macro/arch/mips64/mm/c-r4k.c	2002-12-20 03:56:52.000000000 +0000
+++ linux-mips-2.4.20-pre6-20030107/arch/mips64/mm/c-r4k.c	2003-01-09 23:21:39.000000000 +0000
@@ -950,7 +950,7 @@ static void r4k_dma_cache_wback_inv_pc(u
 	unsigned long end, a;
 
 	if (size >= dcache_size) {
-		flush_cache_l1();
+		flush_cache_all();
 	} else {
 #ifdef R4600_V2_HIT_CACHEOP_WAR
 		unsigned long flags;
@@ -963,7 +963,7 @@ static void r4k_dma_cache_wback_inv_pc(u
 		a = addr & ~(dc_lsize - 1);
 		end = (addr + size - 1) & ~(dc_lsize - 1);
 		while (1) {
-			flush_dcache_line(a); /* Hit_Writeback_Inv_D */
+			flush_dcache_line(a);	/* Hit_Writeback_Inv_D */
 			if (a == end) break;
 			a += dc_lsize;
 		}
@@ -971,6 +971,7 @@ static void r4k_dma_cache_wback_inv_pc(u
 		local_irq_restore(flags);
 #endif
 	}
+
 	bc_wback_inv(addr, size);
 }
 
@@ -979,7 +980,7 @@ static void r4k_dma_cache_wback_inv_sc(u
 	unsigned long end, a;
 
 	if (size >= scache_size) {
-		flush_cache_l1();
+		flush_cache_all();
 		return;
 	}
 
@@ -997,7 +998,7 @@ static void r4k_dma_cache_inv_pc(unsigne
 	unsigned long end, a;
 
 	if (size >= dcache_size) {
-		flush_cache_l1();
+		flush_cache_all();
 	} else {
 #ifdef R4600_V2_HIT_CACHEOP_WAR
 		unsigned long flags;
@@ -1010,7 +1011,7 @@ static void r4k_dma_cache_inv_pc(unsigne
 		a = addr & ~(dc_lsize - 1);
 		end = (addr + size - 1) & ~(dc_lsize - 1);
 		while (1) {
-			flush_dcache_line(a); /* Hit_Writeback_Inv_D */
+			flush_dcache_line(a);	/* Hit_Writeback_Inv_D */
 			if (a == end) break;
 			a += dc_lsize;
 		}
@@ -1027,14 +1028,14 @@ static void r4k_dma_cache_inv_sc(unsigne
 	unsigned long end, a;
 
 	if (size >= scache_size) {
-		flush_cache_l1();
+		flush_cache_all();
 		return;
 	}
 
 	a = addr & ~(sc_lsize - 1);
 	end = (addr + size - 1) & ~(sc_lsize - 1);
 	while (1) {
-		flush_scache_line(a); /* Hit_Writeback_Inv_SD */
+		flush_scache_line(a);	/* Hit_Writeback_Inv_SD */
 		if (a == end) break;
 		a += sc_lsize;
 	}
@@ -1241,9 +1242,10 @@ static void __init setup_noscache_funcs(
 		_flush_cache_page = r4k_flush_cache_page_d32i32;
 		break;
 	}
-
 	_flush_icache_page = r4k_flush_icache_page_p;
 
+	___flush_cache_all = _flush_cache_all;
+
 	_dma_cache_wback_inv = r4k_dma_cache_wback_inv_pc;
 	_dma_cache_wback = r4k_dma_cache_wback_inv_pc;
 	_dma_cache_inv = r4k_dma_cache_inv_pc;
@@ -1333,6 +1335,9 @@ static void __init setup_scache_funcs(vo
 		break;
 	}
 	_flush_icache_page = r4k_flush_icache_page_s;
+
+	___flush_cache_all = _flush_cache_all;
+
 	_dma_cache_wback_inv = r4k_dma_cache_wback_inv_sc;
 	_dma_cache_wback = r4k_dma_cache_wback_inv_sc;
 	_dma_cache_inv = r4k_dma_cache_inv_sc;
@@ -1394,5 +1399,5 @@ void __init ld_mmu_r4xx0(void)
 
 	_flush_cache_l2 = r4k_flush_cache_l2;
 
-	flush_cache_l1();
+	__flush_cache_all();
 }


From ralf@linux-mips.org Fri Jan 10 13:03:31 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 10 Jan 2003 13:03:32 +0000 (GMT)
Received: from p508B758A.dip.t-dialin.net ([IPv6:::ffff:80.139.117.138]:11408
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8226133AbTAJNDb>; Fri, 10 Jan 2003 13:03:31 +0000
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.11.6/8.11.6) id h0AD3QI08346;
	Fri, 10 Jan 2003 14:03:26 +0100
Date: Fri, 10 Jan 2003 14:03:26 +0100
From: Ralf Baechle <ralf@linux-mips.org>
To: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
Cc: linux-mips@linux-mips.org
Subject: Re: [patch] R4k cache code synchronization
Message-ID: <20030110140326.B7699@linux-mips.org>
References: <Pine.GSO.3.96.1030110131859.23678B-100000@delta.ds2.pg.gda.pl>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5.1i
In-Reply-To: <Pine.GSO.3.96.1030110131859.23678B-100000@delta.ds2.pg.gda.pl>; from macro@ds2.pg.gda.pl on Fri, Jan 10, 2003 at 01:37:12PM +0100
Return-Path: <ralf@linux-mips.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1120
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips

On Fri, Jan 10, 2003 at 01:37:12PM +0100, Maciej W. Rozycki wrote:

>  I can't see any need for flush_cache_l1() and flush_cache_l2().  I'd like
> to remove them.  A single flush_cache_all() seems sufficient for our
> needs.  Any objections? 

The reason for the existance of flush_cache_l1 and flush_cache_l2 is the
Origin.  An empty flush_cache_all() is sufficient on the Origin because
it's R10000 processor doesn't suffer from cache aliases.  During bootup
we have to flush all caches or the cache coherence logic will send crazy
exceptions at us.  For all other occasions just a flush of the primary
caches is sufficient which is why there is flush_cache_l1.

So I think we want to wrap things a bit nicer but basically we have to
keep those cacheops for the sake of the Origin.

  Ralf

From quintela@mandrakesoft.com Fri Jan 10 13:25:51 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 10 Jan 2003 13:25:51 +0000 (GMT)
Received: from cm19173.red.mundo-r.com ([IPv6:::ffff:213.60.19.173]:27623 "EHLO
	demo.mitica") by linux-mips.org with ESMTP id <S8226137AbTAJNZv>;
	Fri, 10 Jan 2003 13:25:51 +0000
Received: by demo.mitica (Postfix, from userid 501)
	id 519BDD657; Fri, 10 Jan 2003 14:33:51 +0100 (CET)
To: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
Cc: Ralf Baechle <ralf@linux-mips.org>, linux-mips@linux-mips.org
Subject: Re: [patch] R4k cache code synchronization
References: <Pine.GSO.3.96.1030110131859.23678B-100000@delta.ds2.pg.gda.pl>
X-Url: http://people.mandrakesoft.com/~quintela
From: Juan Quintela <quintela@mandrakesoft.com>
In-Reply-To: <Pine.GSO.3.96.1030110131859.23678B-100000@delta.ds2.pg.gda.pl>
Date: 10 Jan 2003 14:33:51 +0100
Message-ID: <m24r8h6se8.fsf@demo.mitica>
Lines: 26
User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2.92
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Return-Path: <quintela@mandrakesoft.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1121
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: quintela@mandrakesoft.com
Precedence: bulk
X-list: linux-mips


I agree with the cleanup.

The only thing that could be controversial is the _l1() thing, and as
current thing is broken, I vote for insclusion.

maciej> diff -up --recursive --new-file linux-mips-2.4.20-pre6-20030107.macro/arch/mips64/mm/c-r4k.c linux-mips-2.4.20-pre6-20030107/arch/mips64/mm/c-r4k.c
maciej> --- linux-mips-2.4.20-pre6-20030107.macro/arch/mips64/mm/c-r4k.c	2002-12-20 03:56:52.000000000 +0000
maciej> +++ linux-mips-2.4.20-pre6-20030107/arch/mips64/mm/c-r4k.c	2003-01-09 23:21:39.000000000 +0000
@@ -979,7 +980,7 @@ static void r4k_dma_cache_wback_inv_sc(u
 	unsigned long end, a;
 
 	if (size >= scache_size) {
-		flush_cache_l1();
+		flush_cache_all();
 		return;
 	}

This one is fixing a bug, we are talking about a chip with Secondary
cache and don't touch the secondary cache at all :(

Later, Juan. 

-- 
In theory, practice and theory are the same, but in practice they 
are different -- Larry McVoy

From quintela@mandrakesoft.com Fri Jan 10 13:28:42 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 10 Jan 2003 13:28:43 +0000 (GMT)
Received: from cm19173.red.mundo-r.com ([IPv6:::ffff:213.60.19.173]:30183 "EHLO
	demo.mitica") by linux-mips.org with ESMTP id <S8226140AbTAJN2m>;
	Fri, 10 Jan 2003 13:28:42 +0000
Received: by demo.mitica (Postfix, from userid 501)
	id 016BBD657; Fri, 10 Jan 2003 14:36:45 +0100 (CET)
To: Ralf Baechle <ralf@linux-mips.org>
Cc: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>,
	linux-mips@linux-mips.org
Subject: Re: [patch] R4k cache code synchronization
References: <Pine.GSO.3.96.1030110131859.23678B-100000@delta.ds2.pg.gda.pl>
	<20030110140326.B7699@linux-mips.org>
X-Url: http://people.mandrakesoft.com/~quintela
From: Juan Quintela <quintela@mandrakesoft.com>
In-Reply-To: <20030110140326.B7699@linux-mips.org>
Date: 10 Jan 2003 14:36:45 +0100
Message-ID: <m21y3l6s9e.fsf@demo.mitica>
Lines: 84
User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2.92
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Return-Path: <quintela@mandrakesoft.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1122
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: quintela@mandrakesoft.com
Precedence: bulk
X-list: linux-mips

>>>>> "ralf" == Ralf Baechle <ralf@linux-mips.org> writes:

ralf> On Fri, Jan 10, 2003 at 01:37:12PM +0100, Maciej W. Rozycki wrote:
>> I can't see any need for flush_cache_l1() and flush_cache_l2().  I'd like
>> to remove them.  A single flush_cache_all() seems sufficient for our
>> needs.  Any objections? 

ralf> The reason for the existance of flush_cache_l1 and flush_cache_l2 is the
ralf> Origin.  An empty flush_cache_all() is sufficient on the Origin because
ralf> it's R10000 processor doesn't suffer from cache aliases.  During bootup
ralf> we have to flush all caches or the cache coherence logic will send crazy
ralf> exceptions at us.  For all other occasions just a flush of the primary
ralf> caches is sufficient which is why there is flush_cache_l1.

ralf> So I think we want to wrap things a bit nicer but basically we have to
ralf> keep those cacheops for the sake of the Origin.

Humm, I thought that there wasn't origins with R4400 processors :)

Anyways, I think that the change is the good direction, at least:
- unsigned int flags -> unsigned long flags
  && under proper #ifdefs

and the mips64 port just now should work only in R4400MC & R4400PC (to me
knowlegge the most unusual ones), and broke in the R4400SC :(


Once talking about caches, why do we _allways_ do the writeback,
indeed if they asked us to do a invalidate?

Something like that?

Later, Juan.

Index: arch/mips64/mm/c-r4k.c
===================================================================
RCS file: /home/cvs/linux/arch/mips64/mm/c-r4k.c,v
retrieving revision 1.1.2.11
diff -u -r1.1.2.11 c-r4k.c
--- arch/mips64/mm/c-r4k.c	8 Jan 2003 14:16:31 -0000	1.1.2.11
+++ arch/mips64/mm/c-r4k.c	9 Jan 2003 23:16:41 -0000
@@ -979,7 +979,7 @@
 	unsigned long end, a;
 
 	if (size >= scache_size) {
-		flush_cache_l1();
+		flush_cache_all();
 		return;
 	}
 
@@ -1010,7 +1010,7 @@
 		a = addr & ~(dc_lsize - 1);
 		end = (addr + size - 1) & ~(dc_lsize - 1);
 		while (1) {
-			flush_dcache_line(a); /* Hit_Writeback_Inv_D */
+			invalidate_dcache_line(a); /* Hit_Invalidate_D */
 			if (a == end) break;
 			a += dc_lsize;
 		}
@@ -1027,14 +1027,14 @@
 	unsigned long end, a;
 
 	if (size >= scache_size) {
-		flush_cache_l1();
+		flush_cache_all();
 		return;
 	}
 
 	a = addr & ~(sc_lsize - 1);
 	end = (addr + size - 1) & ~(sc_lsize - 1);
 	while (1) {
-		flush_scache_line(a); /* Hit_Writeback_Inv_SD */
+		invalidate_scache_line(a); /* Hit_Invalidate_SD */
 		if (a == end) break;
 		a += sc_lsize;
 	}
 




-- 
In theory, practice and theory are the same, but in practice they 
are different -- Larry McVoy

From macro@ds2.pg.gda.pl Fri Jan 10 13:30:08 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 10 Jan 2003 13:30:08 +0000 (GMT)
Received: from delta.ds2.pg.gda.pl ([IPv6:::ffff:213.192.72.1]:21965 "EHLO
	delta.ds2.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8226143AbTAJNaI>; Fri, 10 Jan 2003 13:30:08 +0000
Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id OAA25438;
	Fri, 10 Jan 2003 14:30:15 +0100 (MET)
Date: Fri, 10 Jan 2003 14:30:12 +0100 (MET)
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To: Ralf Baechle <ralf@linux-mips.org>
cc: linux-mips@linux-mips.org
Subject: Re: [patch] R4k cache code synchronization
In-Reply-To: <20030110140326.B7699@linux-mips.org>
Message-ID: <Pine.GSO.3.96.1030110140613.23678E-100000@delta.ds2.pg.gda.pl>
Organization: Technical University of Gdansk
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <macro@ds2.pg.gda.pl>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1123
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: macro@ds2.pg.gda.pl
Precedence: bulk
X-list: linux-mips

On Fri, 10 Jan 2003, Ralf Baechle wrote:

> The reason for the existance of flush_cache_l1 and flush_cache_l2 is the
> Origin.  An empty flush_cache_all() is sufficient on the Origin because
> it's R10000 processor doesn't suffer from cache aliases.  During bootup
> we have to flush all caches or the cache coherence logic will send crazy
> exceptions at us.  For all other occasions just a flush of the primary
> caches is sufficient which is why there is flush_cache_l1.

 So flush_cache_l1() as currently defined is sufficient for DMA coherency
on the R10000, isn't it?

> So I think we want to wrap things a bit nicer but basically we have to
> keep those cacheops for the sake of the Origin.

 The naming is grossly incorrect.  If the R10000 has such a cache
semantics, then it should use flush_cache_all() (targetting L1) for
coherency and __flush_cache_all() (targetting L2; I assume L2 operations
imply L1 ones, otherwise the function should explicitly operate on L1,
too) for a maintenance flush.  Just like it's done for the 32-bit port. 

 There was a patch attached -- what about it? 

  Maciej

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


From macro@ds2.pg.gda.pl Fri Jan 10 13:32:59 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 10 Jan 2003 13:33:00 +0000 (GMT)
Received: from delta.ds2.pg.gda.pl ([IPv6:::ffff:213.192.72.1]:30925 "EHLO
	delta.ds2.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8226146AbTAJNc7>; Fri, 10 Jan 2003 13:32:59 +0000
Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id OAA25532;
	Fri, 10 Jan 2003 14:33:05 +0100 (MET)
Date: Fri, 10 Jan 2003 14:33:03 +0100 (MET)
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To: Juan Quintela <quintela@mandrakesoft.com>
cc: Ralf Baechle <ralf@linux-mips.org>, linux-mips@linux-mips.org
Subject: Re: [patch] R4k cache code synchronization
In-Reply-To: <m24r8h6se8.fsf@demo.mitica>
Message-ID: <Pine.GSO.3.96.1030110143030.23678F-100000@delta.ds2.pg.gda.pl>
Organization: Technical University of Gdansk
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <macro@ds2.pg.gda.pl>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1124
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: macro@ds2.pg.gda.pl
Precedence: bulk
X-list: linux-mips

On 10 Jan 2003, Juan Quintela wrote:

> The only thing that could be controversial is the _l1() thing, and as
> current thing is broken, I vote for insclusion.
> 
> maciej> diff -up --recursive --new-file linux-mips-2.4.20-pre6-20030107.macro/arch/mips64/mm/c-r4k.c linux-mips-2.4.20-pre6-20030107/arch/mips64/mm/c-r4k.c
> maciej> --- linux-mips-2.4.20-pre6-20030107.macro/arch/mips64/mm/c-r4k.c	2002-12-20 03:56:52.000000000 +0000
> maciej> +++ linux-mips-2.4.20-pre6-20030107/arch/mips64/mm/c-r4k.c	2003-01-09 23:21:39.000000000 +0000
> @@ -979,7 +980,7 @@ static void r4k_dma_cache_wback_inv_sc(u
>  	unsigned long end, a;
>  
>  	if (size >= scache_size) {
> -		flush_cache_l1();
> +		flush_cache_all();
>  		return;
>  	}
> 
> This one is fixing a bug, we are talking about a chip with Secondary
> cache and don't touch the secondary cache at all :(

 That bug is inactive -- both function pointers are defined to the same
value as surprisinly enough "l1" means "both caches" for the R4k.  Anyway,
I for removing flush_cache_l1() altogether in the next step. 

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


From quintela@mandrakesoft.com Fri Jan 10 13:43:17 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 10 Jan 2003 13:43:18 +0000 (GMT)
Received: from cm19173.red.mundo-r.com ([IPv6:::ffff:213.60.19.173]:34535 "EHLO
	demo.mitica") by linux-mips.org with ESMTP id <S8226150AbTAJNnR>;
	Fri, 10 Jan 2003 13:43:17 +0000
Received: by demo.mitica (Postfix, from userid 501)
	id 06EA5D657; Fri, 10 Jan 2003 14:51:20 +0100 (CET)
To: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
Cc: Ralf Baechle <ralf@linux-mips.org>, linux-mips@linux-mips.org
Subject: Re: [patch] R4k cache code synchronization
References: <Pine.GSO.3.96.1030110143030.23678F-100000@delta.ds2.pg.gda.pl>
X-Url: http://people.mandrakesoft.com/~quintela
From: Juan Quintela <quintela@mandrakesoft.com>
In-Reply-To: <Pine.GSO.3.96.1030110143030.23678F-100000@delta.ds2.pg.gda.pl>
Date: 10 Jan 2003 14:51:20 +0100
Message-ID: <m2smw15d0n.fsf@demo.mitica>
Lines: 42
User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2.92
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Return-Path: <quintela@mandrakesoft.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1125
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: quintela@mandrakesoft.com
Precedence: bulk
X-list: linux-mips

>>>>> "maciej" == Maciej W Rozycki <macro@ds2.pg.gda.pl> writes:

maciej> On 10 Jan 2003, Juan Quintela wrote:
>> The only thing that could be controversial is the _l1() thing, and as
>> current thing is broken, I vote for insclusion.
>> 
maciej> diff -up --recursive --new-file linux-mips-2.4.20-pre6-20030107.macro/arch/mips64/mm/c-r4k.c linux-mips-2.4.20-pre6-20030107/arch/mips64/mm/c-r4k.c
maciej> --- linux-mips-2.4.20-pre6-20030107.macro/arch/mips64/mm/c-r4k.c	2002-12-20 03:56:52.000000000 +0000
maciej> +++ linux-mips-2.4.20-pre6-20030107/arch/mips64/mm/c-r4k.c	2003-01-09 23:21:39.000000000 +0000
>> @@ -979,7 +980,7 @@ static void r4k_dma_cache_wback_inv_sc(u
>> unsigned long end, a;
>> 
>> if (size >= scache_size) {
>> -		flush_cache_l1();
>> +		flush_cache_all();
>> return;
>> }
>> 
>> This one is fixing a bug, we are talking about a chip with Secondary
>> cache and don't touch the secondary cache at all :(

maciej> That bug is inactive -- both function pointers are defined to the same
maciej> value as surprisinly enough "l1" means "both caches" for the R4k.  Anyway,
maciej> I for removing flush_cache_l1() altogether in the next step. 

Yep, you are right, only 2 weeks since I looked at that file and
already forgot it.

Ralf, current code (as Maciej tolds), just have _l1 & _l2 variants,
but at least in that file, they are defined to be the same :(

I also vote to unify the mips & mips64 versions of that file, they are
the same :(

Maciej, in the other hand, you didn't coment in the other part, that
we writeback & invalidate when we are asked only to invalidate?

Later, Juan.

-- 
In theory, practice and theory are the same, but in practice they 
are different -- Larry McVoy

From macro@ds2.pg.gda.pl Fri Jan 10 14:02:05 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 10 Jan 2003 14:02:06 +0000 (GMT)
Received: from delta.ds2.pg.gda.pl ([IPv6:::ffff:213.192.72.1]:37582 "EHLO
	delta.ds2.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8226157AbTAJOCF>; Fri, 10 Jan 2003 14:02:05 +0000
Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id PAA26103;
	Fri, 10 Jan 2003 15:02:08 +0100 (MET)
Date: Fri, 10 Jan 2003 15:02:05 +0100 (MET)
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To: Juan Quintela <quintela@mandrakesoft.com>
cc: Ralf Baechle <ralf@linux-mips.org>, linux-mips@linux-mips.org
Subject: Re: [patch] R4k cache code synchronization
In-Reply-To: <m2smw15d0n.fsf@demo.mitica>
Message-ID: <Pine.GSO.3.96.1030110145323.23678J-100000@delta.ds2.pg.gda.pl>
Organization: Technical University of Gdansk
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <macro@ds2.pg.gda.pl>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1126
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: macro@ds2.pg.gda.pl
Precedence: bulk
X-list: linux-mips

On 10 Jan 2003, Juan Quintela wrote:

> Maciej, in the other hand, you didn't coment in the other part, that
> we writeback & invalidate when we are asked only to invalidate?

 I did some investigation now and I think dma_cache_wback_inv(),
dma_cache_wback() and dma_cache_inv() all should do what the name implies. 
I'll make a fix.

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


From macro@ds2.pg.gda.pl Fri Jan 10 14:32:32 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 10 Jan 2003 14:32:33 +0000 (GMT)
Received: from delta.ds2.pg.gda.pl ([IPv6:::ffff:213.192.72.1]:63183 "EHLO
	delta.ds2.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8226161AbTAJOcc>; Fri, 10 Jan 2003 14:32:32 +0000
Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id PAA26838;
	Fri, 10 Jan 2003 15:32:37 +0100 (MET)
Date: Fri, 10 Jan 2003 15:32:34 +0100 (MET)
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To: Ralf Baechle <ralf@linux-mips.org>, linux-mips@linux-mips.org
cc: Karsten Merker <karsten@excalibur.cologne.de>,
	Thiemo Seufer <ica2_ts@csv.ica.uni-stuttgart.de>
Subject: [patch] R4000/R4400 64-bit errata handling
Message-ID: <Pine.GSO.3.96.1030110150339.23678K-100000@delta.ds2.pg.gda.pl>
Organization: Technical University of Gdansk
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <macro@ds2.pg.gda.pl>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1127
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: macro@ds2.pg.gda.pl
Precedence: bulk
X-list: linux-mips

Hello,

 As you might already know there are a few nasty errata in the R4000 and
the early R4400 that hit 64-bit operation badly.  Here is proposed code to
detect them.  If an erratum is found in the processor and no workaround is
applied to a kernel executable, the kernel refuses to run.  In all cases
the result of the probes is output to the bootstrap log.

 The code has bits that make use of features of non-standard tools
(binutils and gcc).  But it doesn't depend on them -- when built with
standard tools and run on an affected system, a kernel will simply fail,
and on good systems it will run normally.  Therefore it's safe to apply,
and if the ultimate implementation in the tools differs, the code may get
adjusted appropriately later. 

 I'd like to apply this code as soon as possible as I consider it a
prerequisite for integrating 64-bit support for the DECstation (to prevent
people from running unreliable code), so please tell me if there are any
doubts about it.  Errata descriptions are available at the MIPS site --
see: 'http://www.mips.com/publications/r400_r5000.html'.  Unfortunately,
despite several attempts to get a permission to duplicate them within
Linux sources, I failed to get one.

 I'd like to express my gratitude to Karsten and Thiemo for testing the
code with their hardware.  Without their help, I wouldn't be able to
prepare appropriate tests for errata my hardware doesn't suffer from. 

  Maciej

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

patch-mips-2.4.20-pre6-20021212-mips-bugs-20
diff -up --recursive --new-file linux-mips-2.4.20-pre6-20021212.macro/arch/mips64/kernel/Makefile linux-mips-2.4.20-pre6-20021212/arch/mips64/kernel/Makefile
--- linux-mips-2.4.20-pre6-20021212.macro/arch/mips64/kernel/Makefile	2002-12-04 03:56:39.000000000 +0000
+++ linux-mips-2.4.20-pre6-20021212/arch/mips64/kernel/Makefile	2003-01-09 19:04:31.000000000 +0000
@@ -32,6 +32,7 @@ ifndef CONFIG_MAPPED_PCI_IO
 obj-y				+= pci-dma.o
 endif
 
-AFLAGS_r4k_genex.o := -P
+CFLAGS_cpu-probe.o	= $(shell if $(CC) $(CFLAGS) -Wa,-mdaddi -c -o /dev/null -xc /dev/null >/dev/null 2>&1; then echo "-DHAVE_AS_SET_DADDI"; fi)
+AFLAGS_r4k_genex.o	= -P
 
 include $(TOPDIR)/Rules.make
diff -up --recursive --new-file linux-mips-2.4.20-pre6-20021212.macro/arch/mips64/kernel/cpu-probe.c linux-mips-2.4.20-pre6-20021212/arch/mips64/kernel/cpu-probe.c
--- linux-mips-2.4.20-pre6-20021212.macro/arch/mips64/kernel/cpu-probe.c	2002-12-04 03:56:39.000000000 +0000
+++ linux-mips-2.4.20-pre6-20021212/arch/mips64/kernel/cpu-probe.c	2003-01-09 20:19:32.000000000 +0000
@@ -1,10 +1,27 @@
+/*
+ *	arch/mips64/kernel/cpu-probe.c
+ *
+ *	Processor capabilities determination functions.
+ *
+ *	Copyright (C) xxxx  the Anonymous
+ *	Copyright (C) 2003  Maciej W. Rozycki
+ *
+ *	This program is free software; you can redistribute it and/or
+ *	modify it under the terms of the GNU General Public License
+ *	as published by the Free Software Foundation; either version
+ *	2 of the License, or (at your option) any later version.
+ */
+
 #include <linux/init.h>
 #include <linux/kernel.h>
+#include <linux/ptrace.h>
 #include <linux/stddef.h>
+
 #include <asm/bugs.h>
 #include <asm/cpu.h>
 #include <asm/fpu.h>
 #include <asm/mipsregs.h>
+#include <asm/system.h>
 
 /*
  * Not all of the MIPS CPUs have the "wait" instruction available. Moreover,
@@ -90,9 +107,229 @@ static inline void check_wait(void)
 	}
 }
 
+static inline void check_mult_sh(void)
+{
+	unsigned long flags;
+	int m1, m2;
+	long p, s, v;
+
+	printk("Checking for the multiply/shift bug... ");
+
+	__save_and_cli(flags);
+	/*
+	 * The following code leads to a wrong result of dsll32 when
+	 * executed on R4000 rev. 2.2 or 3.0.
+	 *
+	 * See "MIPS R4000PC/SC Errata, Processor Revision 2.2 and
+	 * 3.0" by MIPS Technologies, Inc., errata #16 and #28 for
+	 * details.  I got no permission to duplicate them here,
+	 * sigh... --macro
+	 */
+	asm volatile(
+		".set	push\n\t"
+		".set	noat\n\t"
+		".set	noreorder\n\t"
+		".set	nomacro\n\t"
+		"mult	%1, %2\n\t"
+		"dsll32	%0, %3, %4\n\t"
+		"mflo	$0\n\t"
+		".set	pop"
+		: "=r" (v)
+		: "r" (5), "r" (8), "r" (5), "I" (0)
+		: "hi", "lo", "accum");
+	__restore_flags(flags);
+
+	if (v == 5L << 32) {
+		printk("no.\n");
+		return;
+	}
+
+	printk("yes, workaround... ");
+	__save_and_cli(flags);
+	/*
+	 * We want the multiply and the shift to be isolated from the
+	 * rest of the code to disable gcc optimizations.  Hence the
+	 * asm statements that execute nothing, but make gcc not know
+	 * what the values of m1, m2 and s are and what v and p are
+	 * used for.
+	 *
+	 * We have to use single integers for m1 and m2 and a double
+	 * one for p to be sure the mulsidi3 gcc's RTL multiplication
+	 * instruction has the workaround applied.  Older versions of
+	 * gcc have correct mulsi3, but other multiplication variants
+	 * lack the workaround.
+	 */
+	asm volatile(
+		""
+		: "=r" (m1), "=r" (m2), "=r" (s)
+		: "0" (5), "1" (8), "2" (5));
+	p = m1 * m2;
+	v = s << 32;
+	asm volatile(
+		""
+		: "=r" (v)
+		: "0" (v), "r" (p));
+	__restore_flags(flags);
+
+	if (v == 5L << 32) {
+		printk("yes.\n");
+		return;
+	}
+
+	printk("no.\n");
+	panic("Reliable operation impossible!\n"
+#ifndef CONFIG_CPU_R4000
+	      "Configure for R4000 to enable the workaround."
+#else
+	      "Please report to <linux-mips@linux-mips.org>."
+#endif
+	      );
+}
+
+static volatile int daddi_ov __initdata = 0;
+
+asmlinkage void __init do_daddi_ov(struct pt_regs *regs)
+{
+	daddi_ov = 1;
+	regs->cp0_epc += 4;
+}
+
+static inline void check_daddi(void)
+{
+	extern asmlinkage void handle_daddi_ov(void);
+	unsigned long flags;
+	void *handler;
+	long v;
+
+	printk("Checking for the daddi bug... ");
+
+	__save_and_cli(flags);
+	handler = set_except_vector(12, handle_daddi_ov);
+	/*
+	 * The following code fails to trigger an overflow exception
+	 * when executed on R4000 rev. 2.2 or 3.0.
+	 *
+	 * See "MIPS R4000PC/SC Errata, Processor Revision 2.2 and
+	 * 3.0" by MIPS Technologies, Inc., erratum #23 for details.
+	 * I got no permission to duplicate it here, sigh... --macro
+	 */
+	asm volatile(
+		".set	push\n\t"
+		".set	noat\n\t"
+		".set	noreorder\n\t"
+		".set	nomacro\n\t"
+#ifdef HAVE_AS_SET_DADDI
+		".set	daddi\n\t"
+#endif
+		"daddi	%0, %1, %2\n\t"
+		".set	pop"
+		: "=r" (v)
+		: "r" (0x7fffffffffffedcd), "I" (0x1234));
+	set_except_vector(12, handler);
+	__restore_flags(flags);
+
+	if (daddi_ov) {
+		printk("no.\n");
+		return;
+	}
+
+	printk("yes, workaround... ");
+
+	__save_and_cli(flags);
+	handler = set_except_vector(12, handle_daddi_ov);
+	asm volatile(
+		"daddi	%0, %1, %2"
+		: "=r" (v)
+		: "r" (0x7fffffffffffedcd), "I" (0x1234));
+	set_except_vector(12, handler);
+	__restore_flags(flags);
+
+	if (daddi_ov) {
+		printk("yes.\n");
+		return;
+	}
+
+	printk("no.\n");
+	panic("Reliable operation impossible!\n"
+#if !defined(CONFIG_CPU_R4000) && !defined(CONFIG_CPU_R4400)
+	      "Configure for R4000 or R4400 to enable the workaround."
+#else
+	      "Please report to <linux-mips@linux-mips.org>."
+#endif
+	      );
+}
+
+static inline void check_daddiu(void)
+{
+	long v, w;
+
+	printk("Checking for the daddiu bug... ");
+
+	/*
+	 * The following code leads to a wrong result of daddiu when
+	 * executed on R4400 rev. 1.0.
+	 *
+	 * See "MIPS R4400PC/SC Errata, Processor Revision 1.0" by
+	 * MIPS Technologies, Inc., erratum #7 for details.
+	 *
+	 * According to "MIPS R4000PC/SC Errata, Processor Revision
+	 * 2.2 and 3.0" by MIPS Technologies, Inc., erratum #41 this
+	 * problem affects R4000 rev. 2.2 and 3.0, too.  Testing
+	 * failed to trigger it so far.
+	 *
+	 * I got no permission to duplicate the errata here, sigh...
+	 * --macro
+	 */
+	asm volatile(
+		".set	push\n\t"
+		".set	noat\n\t"
+		".set	noreorder\n\t"
+		".set	nomacro\n\t"
+#ifdef HAVE_AS_SET_DADDI
+		".set	daddi\n\t"
+#endif
+		"daddiu	%0, %2, %3\n\t"
+		"addiu	%1, $0, %3\n\t"
+		"daddu	%1, %2\n\t"
+		".set	pop"
+		: "=&r" (v), "=&r" (w)
+		: "r" (0x7fffffffffffedcd), "I" (0x1234));
+
+	if (v == w) {
+		printk("no.\n");
+		return;
+	}
+
+	printk("yes, workaround... ");
+
+	asm volatile(
+		"daddiu	%0, %2, %3\n\t"
+		"addiu	%1, $0, %3\n\t"
+		"daddu	%1, %2"
+		: "=&r" (v), "=&r" (w)
+		: "r" (0x7fffffffffffedcd), "I" (0x1234));
+
+	if (v == w) {
+		printk("yes.\n");
+		return;
+	}
+
+	printk("no.\n");
+	panic("Reliable operation impossible!\n"
+#if !defined(CONFIG_CPU_R4000) && !defined(CONFIG_CPU_R4400)
+	      "Configure for R4000 or R4400 to enable the workaround."
+#else
+	      "Please report to <linux-mips@linux-mips.org>."
+#endif
+	      );
+}
+
 void __init check_bugs(void)
 {
 	check_wait();
+	check_mult_sh();
+	check_daddi();
+	check_daddiu();
 }
 
 /*
diff -up --recursive --new-file linux-mips-2.4.20-pre6-20021212.macro/arch/mips64/kernel/r4k_genex.S linux-mips-2.4.20-pre6-20021212/arch/mips64/kernel/r4k_genex.S
--- linux-mips-2.4.20-pre6-20021212.macro/arch/mips64/kernel/r4k_genex.S	2002-10-02 17:22:18.000000000 +0000
+++ linux-mips-2.4.20-pre6-20021212/arch/mips64/kernel/r4k_genex.S	2002-10-22 21:44:51.000000000 +0000
@@ -35,6 +35,11 @@
 
 	__INIT
 
+/* A temporary overflow handler used by check_daddi(). */
+
+	BUILD_HANDLER  daddi_ov daddi_ov none silent	/* #12 */
+
+
 /* General exception handler for CPUs with virtual coherency exception.
  *
  * Be careful when changing this, it has to be at most 256 (as a special


From ralf@linux-mips.org Fri Jan 10 14:47:57 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 10 Jan 2003 14:47:57 +0000 (GMT)
Received: from p508B758A.dip.t-dialin.net ([IPv6:::ffff:80.139.117.138]:22929
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8226164AbTAJOr5>; Fri, 10 Jan 2003 14:47:57 +0000
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.11.6/8.11.6) id h0AEljH10678;
	Fri, 10 Jan 2003 15:47:45 +0100
Date: Fri, 10 Jan 2003 15:47:45 +0100
From: Ralf Baechle <ralf@linux-mips.org>
To: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
Cc: linux-mips@linux-mips.org,
	Karsten Merker <karsten@excalibur.cologne.de>,
	Thiemo Seufer <ica2_ts@csv.ica.uni-stuttgart.de>
Subject: Re: [patch] R4000/R4400 64-bit errata handling
Message-ID: <20030110154745.D7699@linux-mips.org>
References: <Pine.GSO.3.96.1030110150339.23678K-100000@delta.ds2.pg.gda.pl>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5.1i
In-Reply-To: <Pine.GSO.3.96.1030110150339.23678K-100000@delta.ds2.pg.gda.pl>; from macro@ds2.pg.gda.pl on Fri, Jan 10, 2003 at 03:32:34PM +0100
Return-Path: <ralf@linux-mips.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1128
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips

On Fri, Jan 10, 2003 at 03:32:34PM +0100, Maciej W. Rozycki wrote:

>  As you might already know there are a few nasty errata in the R4000 and
> the early R4400 that hit 64-bit operation badly.  Here is proposed code to
> detect them.  If an erratum is found in the processor and no workaround is
> applied to a kernel executable, the kernel refuses to run.  In all cases
> the result of the probes is output to the bootstrap log.
> 
>  The code has bits that make use of features of non-standard tools
> (binutils and gcc).  But it doesn't depend on them -- when built with
> standard tools and run on an affected system, a kernel will simply fail,
> and on good systems it will run normally.  Therefore it's safe to apply,
> and if the ultimate implementation in the tools differs, the code may get
> adjusted appropriately later. 
> 
>  I'd like to apply this code as soon as possible as I consider it a
> prerequisite for integrating 64-bit support for the DECstation (to prevent
> people from running unreliable code), so please tell me if there are any
> doubts about it.  Errata descriptions are available at the MIPS site --
> see: 'http://www.mips.com/publications/r400_r5000.html'.  Unfortunately,
> despite several attempts to get a permission to duplicate them within
> Linux sources, I failed to get one.
> 
>  I'd like to express my gratitude to Karsten and Thiemo for testing the
> code with their hardware.  Without their help, I wouldn't be able to
> prepare appropriate tests for errata my hardware doesn't suffer from. 

> +	__save_and_cli(flags);

> +	__restore_flags(flags);

I suggest to replace these with local_irq_save and local_irq_restore.
They're already deprecated for 2.4 and completly gone in 2.5.

Looks ok to me otherwise.

  Ralf

From macro@ds2.pg.gda.pl Fri Jan 10 14:52:31 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 10 Jan 2003 14:52:32 +0000 (GMT)
Received: from delta.ds2.pg.gda.pl ([IPv6:::ffff:213.192.72.1]:57296 "EHLO
	delta.ds2.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8226168AbTAJOwb>; Fri, 10 Jan 2003 14:52:31 +0000
Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id PAA27368;
	Fri, 10 Jan 2003 15:52:41 +0100 (MET)
Date: Fri, 10 Jan 2003 15:52:38 +0100 (MET)
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To: Ralf Baechle <ralf@linux-mips.org>
cc: linux-mips@linux-mips.org,
	Karsten Merker <karsten@excalibur.cologne.de>,
	Thiemo Seufer <ica2_ts@csv.ica.uni-stuttgart.de>
Subject: Re: [patch] R4000/R4400 64-bit errata handling
In-Reply-To: <20030110154745.D7699@linux-mips.org>
Message-ID: <Pine.GSO.3.96.1030110155123.23678N-100000@delta.ds2.pg.gda.pl>
Organization: Technical University of Gdansk
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <macro@ds2.pg.gda.pl>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1129
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: macro@ds2.pg.gda.pl
Precedence: bulk
X-list: linux-mips

On Fri, 10 Jan 2003, Ralf Baechle wrote:

> > +	__save_and_cli(flags);
> 
> > +	__restore_flags(flags);
> 
> I suggest to replace these with local_irq_save and local_irq_restore.
> They're already deprecated for 2.4 and completly gone in 2.5.

 Sure -- sorry for missing it.

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


From nmckee@telogy.com Fri Jan 10 15:24:43 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 10 Jan 2003 15:24:44 +0000 (GMT)
Received: from [IPv6:::ffff:209.116.120.7] ([IPv6:::ffff:209.116.120.7]:26640
	"EHLO tnint11.telogy.design.ti.com") by linux-mips.org with ESMTP
	id <S8226173AbTAJPYn>; Fri, 10 Jan 2003 15:24:43 +0000
Received: by tnint11.telogy.design.ti.com with Internet Mail Service (5.5.2653.19)
	id <WY1ZW1DC>; Fri, 10 Jan 2003 10:22:17 -0500
Message-ID: <37A3C2F21006D611995100B0D0F9B73CBFE40C@tnint11.telogy.design.ti.com>
From: "Zajerko-McKee, Nick" <nmckee@telogy.com>
To: 'atul srivastava' <atulsrivastava9@rediffmail.com>,
	linux-mips@linux-mips.org
Subject: RE: handling of s-record images by bootloader
Date: Fri, 10 Jan 2003 10:22:15 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Return-Path: <nmckee@telogy.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1130
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: nmckee@telogy.com
Precedence: bulk
X-list: linux-mips

I had a simular problem.  I ended up writing my own code for my
platform.  Here is a description of s-records:

http://www.amelek.gda.pl/avr/uisp/srecord.htm

-----Original Message-----
From: atul srivastava [mailto:atulsrivastava9@rediffmail.com]
Sent: Friday, January 10, 2003 5:17 AM
To: linux-mips@linux-mips.org
Subject: handling of s-record images by bootloader


Hello .

A quick question..

I have developed a primitive bootloader for custom board, that is 
successfuly doing the board bringup and loads linux os image
currently through serial link (kermit) only.
network link is also likely to be up soon.

but through serial it loads  kernel image only in raw binary 
format.
now i want to extend this for s-record images as well..

I am umware that, how differently s-record image need to be 
handled..?
i just need some idea or if possible any example code for that..

Best Reagards,
Atul





From ladis@psi.cz Fri Jan 10 20:48:05 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 10 Jan 2003 20:48:06 +0000 (GMT)
Received: from prahad-5-64.dialup.vol.cz ([IPv6:::ffff:212.20.121.196]:260
	"EHLO kopretinka") by linux-mips.org with ESMTP id <S8226179AbTAJUsF>;
	Fri, 10 Jan 2003 20:48:05 +0000
Received: from ladis by kopretinka with local (Exim 3.35 #1 (Debian))
	id 18X5zl-0000Bm-00; Fri, 10 Jan 2003 21:43:13 +0100
Date: Fri, 10 Jan 2003 21:43:13 +0100
To: linux-mips@linux-mips.org
Cc: Ralf Baechle <ralf@linux-mips.org>,
	Ulf Karlsson <md1ulfc@mdstud.chalmers.se>
Subject: [PATCH] HAL2: fix LE stream playback
Message-ID: <20030110204313.GA712@kopretinka>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.3.28i
From: Ladislav Michl <ladis@psi.cz>
Return-Path: <ladis@psi.cz>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1131
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ladis@psi.cz
Precedence: bulk
X-list: linux-mips

Hi,

several people complained about it on IRC, so here is a patch against
linux_2_4 branch. Please apply.

Side note: recording still doesn't work. while ago i tried to play with
PBUS configuration and found following (refer to hpc3.ps):
1) writing 0x08248844 (ie. 16bit DMA stream) into pbus_dmacfgs produces
   noise at output.
2) writing 0x082c8844 (ie. 16bit with EVEN_HIGH bit set) make playback
   two times faster.
3) writing 0x08248844 (ie. 8 bit stream) works as expected. That is
   strange, because I still believe that HAL2 is 16bit device. I'd guess
   that there are two bugs in driver which neutralizes each other.
In all cases DMA stream wasn't started for recording.


--- XXX/drivers/sound/hal2.c	Mon Aug  5 19:40:50 2002
+++ linux/drivers/sound/hal2.c	Fri Jan 10 21:06:27 2003
@@ -1,6 +1,6 @@
 /*
  *  Driver for HAL2 sound processors
- *  Copyright (c) 2001, 2002 Ladislav Michl <ladis@psi.cz>
+ *  Copyright (c) 2001-2003 Ladislav Michl <ladis@linux-mips.org>
  *  
  *  Based on Ulf Carlsson's code.
  *
@@ -394,7 +394,8 @@
 	fifobeg = 0;				/* playback is first */
 	fifoend = (sample_size * 4) >> 3;	/* doublewords */
 	pbus->ctrl = HPC3_PDMACTRL_RT | HPC3_PDMACTRL_LD |
-		     (highwater << 8) | (fifobeg << 16) | (fifoend << 24);
+		     (highwater << 8) | (fifobeg << 16) | (fifoend << 24) |
+		     (hal2->dac.format & AFMT_S16_LE ? HPC3_PDMACTRL_SEL : 0);
 	/* We disable everything before we do anything at all */
 	pbus->pbus->pbdma_ctrl = HPC3_PDMACTRL_LD;
 	hal2_i_clearbit16(hal2, H2I_DMA_PORT_EN, H2I_DMA_PORT_EN_CODECTX);
@@ -420,7 +421,8 @@
 	fifobeg = (4 * 4) >> 3;				/* record is second */
 	fifoend = (4 * 4 + sample_size * 4) >> 3;	/* doublewords */
 	pbus->ctrl = HPC3_PDMACTRL_RT | HPC3_PDMACTRL_RCV | HPC3_PDMACTRL_LD | 
-		     (highwater << 8) | (fifobeg << 16) | (fifoend << 24);
+		     (highwater << 8) | (fifobeg << 16) | (fifoend << 24) |
+		     (hal2->adc.format & AFMT_S16_LE ? HPC3_PDMACTRL_SEL : 0);
 	pbus->pbus->pbdma_ctrl = HPC3_PDMACTRL_LD;
 	hal2_i_clearbit16(hal2, H2I_DMA_PORT_EN, H2I_DMA_PORT_EN_CODECR);
 	hal2_i_clearbit16(hal2, H2I_DMA_DRV, (1 << pbus->pbusnr));


From vivienc@nerim.net Sat Jan 11 18:55:16 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 11 Jan 2003 18:55:17 +0000 (GMT)
Received: from p508B688C.dip.t-dialin.net ([IPv6:::ffff:80.139.104.140]:2951
	"EHLO p508B688C.dip.t-dialin.net") by linux-mips.org with ESMTP
	id <S8225701AbTAKSzQ>; Sat, 11 Jan 2003 18:55:16 +0000
Received: from smtp-101.noc.nerim.net ([IPv6:::ffff:62.4.17.101]:8718 "EHLO
	mallaury.noc.nerim.net") by ralf.linux-mips.org with ESMTP
	id <S869811AbTAKSzO>; Sat, 11 Jan 2003 19:55:14 +0100
Received: from melkor (vivienc.net1.nerim.net [213.41.134.233])
	by mallaury.noc.nerim.net (Postfix) with ESMTP
	id 0855062E1B; Sat, 11 Jan 2003 19:55:02 +0100 (CET)
Received: from glaurung (helo=localhost)
	by melkor with local-esmtp (Exim 3.36 #1 (Debian))
	id 18XQmb-0002FI-00; Sat, 11 Jan 2003 19:55:01 +0100
Date: Sat, 11 Jan 2003 19:55:00 +0100 (CET)
From: Vivien Chappelier <vivienc@nerim.net>
X-Sender: glaurung@melkor
To: Ralf Baechle <ralf@oss.sgi.com>
Cc: linux-mips@linux-mips.org
Subject: [PATCH 2.5] udelay
Message-ID: <Pine.LNX.4.21.0301111951300.7511-100000@melkor>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <vivienc@nerim.net>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1132
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: vivienc@nerim.net
Precedence: bulk
X-list: linux-mips

Hi,

	The HZ constant has been changed in 2.5 and this breaks
udelay(). Here is a patch to fix this. Note that the first multiply in
udelay is still optimized out by the compiler if the delay is constant, as
in current implementation.

Vivien.

--- include/asm-mips64/delay.h	2002-12-11 20:44:20.000000000 +0100
+++ include/asm-mips64/delay.h	2003-01-07 20:36:37.000000000 +0100
@@ -41,11 +41,11 @@
 {
 	unsigned long lo;
 
-#if (HZ == 100)
-	usecs *= 0x00068db8bac710cbUL;		/* 2**64 / (1000000 / HZ) */
-#elif (HZ == 128)
-	usecs *= 0x0008637bd05af6c6UL;		/* 2**64 / (1000000 / HZ) */
-#endif
+/* HZ * 2**64 / 1000000 */
+#define __UDELAY_FIXED64_HZ_1000000 (0x8000000000000000UL / (500000 / HZ)) 
+
+	usecs *= __UDELAY_FIXED64_HZ_1000000;
+
 	__asm__("dmultu\t%2,%3"
 		:"=h" (usecs), "=l" (lo)
 		:"r" (usecs),"r" (lpj));
--- include/asm-mips/delay.h	2002-12-11 20:44:18.000000000 +0100
+++ include/asm-mips/delay.h	2003-01-08 19:25:17.000000000 +0100
@@ -40,11 +40,10 @@
 {
 	unsigned long lo;
 
-#if (HZ == 100)
-	usecs *= 0x00068db8;		/* 2**32 / (1000000 / HZ) */
-#elif (HZ == 128)
-	usecs *= 0x0008637b;		/* 2**32 / (1000000 / HZ) */
-#endif
+/* HZ * 2**32 / 1000000 */
+#define __UDELAY_FIXED32_HZ_1000000 (0x80000000UL / (500000 / HZ)) 
+
+	usecs *= __UDELAY_FIXED32_HZ_1000000;
 	__asm__("multu\t%2,%3"
 		:"=h" (usecs), "=l" (lo)
 		:"r" (usecs),"r" (lpj));


From ralf@linux-mips.org Sun Jan 12 17:10:19 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 12 Jan 2003 17:20:02 +0000 (GMT)
Received: from p508B6452.dip.t-dialin.net ([IPv6:::ffff:80.139.100.82]:62648
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8226241AbTALRKT>; Sun, 12 Jan 2003 17:10:19 +0000
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.11.6/8.11.6) id h0CH9H419209;
	Sun, 12 Jan 2003 18:09:17 +0100
Date: Sun, 12 Jan 2003 18:09:17 +0100
From: Ralf Baechle <ralf@linux-mips.org>
To: "Krishnakumar. R" <krishnakumar@naturesoft.net>
Cc: linux-mips@linux-mips.org
Subject: Re: Cpu frequency scaling
Message-ID: <20030112180917.A18654@linux-mips.org>
References: <200301101600.26246.krishnakumar@naturesoft.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5.1i
In-Reply-To: <200301101600.26246.krishnakumar@naturesoft.net>; from krishnakumar@naturesoft.net on Sun, Jan 12, 2003 at 08:20:05PM +0530
Return-Path: <ralf@linux-mips.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1134
X-Approved-By: ralf@linux-mips.org
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips

On Sun, Jan 12, 2003 at 08:20:05PM +0530, Krishnakumar. R wrote:

> Can frequency scaling (through software) 
> be done on mips using linux ?
> 
> Is  such a feature feasible in mips ??
> 
> I could not find any documentation nor patches 
> for  frequency
> scaling on mips at 
> http://www.brodo.de/cpufreq/
> :-(

None of the currently supported MIPS CPUs support such a feature in
hardware as such our support is already complete and by definition
bug free ;-)

  Ralf

From kevink@mips.com Sun Jan 12 18:56:07 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 12 Jan 2003 20:43:22 +0000 (GMT)
Received: from mx2.mips.com ([IPv6:::ffff:206.31.31.227]:12193 "EHLO
	mx2.mips.com") by linux-mips.org with ESMTP id <S8226246AbTALS4H>;
	Sun, 12 Jan 2003 18:56:07 +0000
Received: from newman.mips.com (ns-dmz [206.31.31.225])
	by mx2.mips.com (8.12.5/8.12.5) with ESMTP id h0CItu67013021;
	Sun, 12 Jan 2003 10:55:56 -0800 (PST)
Received: from grendel (grendel [192.168.236.16])
	by newman.mips.com (8.9.3/8.9.0) with SMTP id KAA24683;
	Sun, 12 Jan 2003 10:55:51 -0800 (PST)
Message-ID: <003b01c2ba6c$f64ef840$10eca8c0@grendel>
From: "Kevin D. Kissell" <kevink@mips.com>
To: "Ralf Baechle" <ralf@linux-mips.org>,
	"Krishnakumar. R" <krishnakumar@naturesoft.net>
Cc: <linux-mips@linux-mips.org>
References: <200301101600.26246.krishnakumar@naturesoft.net> <20030112180917.A18654@linux-mips.org>
Subject: Re: Cpu frequency scaling
Date: Sun, 12 Jan 2003 20:01: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 5.50.4807.1700
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300
Return-Path: <kevink@mips.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1135
X-Approved-By: ralf@linux-mips.org
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: kevink@mips.com
Precedence: bulk
X-list: linux-mips

> > Can frequency scaling (through software) 
> > be done on mips using linux ?
> > 
> > Is  such a feature feasible in mips ??
> > 
> > I could not find any documentation nor patches 
> > for  frequency
> > scaling on mips at 
> > http://www.brodo.de/cpufreq/
> > :-(
> 
> None of the currently supported MIPS CPUs support such a feature in
> hardware as such our support is already complete and by definition
> bug free ;-)

Actually, that's not *quite* true.  A number of MIPS CPUs and
cores that are otherwise supported by Linux (e.g. 4K, 5K) have
a "reduced power" mode which is modulated by the CP0 "RP"
bit. In general, this bit does nothing in the CPU itself, however.
It was intended that it be connected to system-level logic for
frequency scaling (1/n normal clock, or CPU=Bus).  So on
most systems it does nothing, and on the ones where it does
do something, it's entirely system dependent.  I don't have an
Alchemy AU1000 spec handy, but since they've integrated
a lot of other logic with their CPU, and since they designed
their component to go into low-power devices, it wouldn't
surprise me in the least if they do something well-defined
with the RP bit.

So, to get back to the original question, something highly
platform dependent *could* be done using MIPS/Linux, 
via /proc/cpu or some kind of system call, but I don't believe 
anyone has made such a hook generally available as yet.

            Kevin K.

From jmjsgi@free.fr Sun Jan 12 23:30:54 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 12 Jan 2003 23:30:55 +0000 (GMT)
Received: from postfix4-2.free.fr ([IPv6:::ffff:213.228.0.176]:30175 "EHLO
	postfix4-2.free.fr") by linux-mips.org with ESMTP
	id <S8226252AbTALXay>; Sun, 12 Jan 2003 23:30:54 +0000
Received: from free.fr (lns-p19-22-81-56-92-102.adsl.proxad.net [81.56.92.102])
	by postfix4-2.free.fr (Postfix) with ESMTP id 5B307C0F1
	for <linux-mips@linux-mips.org>; Mon, 13 Jan 2003 00:30:51 +0100 (CET)
Message-ID: <3E21FAC0.E69BD643@free.fr>
Date: Mon, 13 Jan 2003 00:31:12 +0100
From: jmjsgi <jmjsgi@free.fr>
X-Mailer: Mozilla 4.5 [fr]C-CCK-MCD SGI  (WinNT; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: "linux-mips@linux-mips.org" <linux-mips@linux-mips.org>
Subject: sgi O2 linux
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Return-Path: <jmjsgi@free.fr>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1136
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: jmjsgi@free.fr
Precedence: bulk
X-list: linux-mips

Hi, i'm french and i woold like install linux on my SGI O2 R5000, but i
dont know wath version of linux i can take. Can you help me.
Thank


From ilya@gateway.total-knowledge.com Sun Jan 12 23:53:35 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 12 Jan 2003 23:53:36 +0000 (GMT)
Received: from 12-234-207-60.client.attbi.com ([IPv6:::ffff:12.234.207.60]:23475
	"HELO gateway.total-knowledge.com") by linux-mips.org with SMTP
	id <S8226255AbTALXxf>; Sun, 12 Jan 2003 23:53:35 +0000
Received: (qmail 11765 invoked by uid 502); 12 Jan 2003 23:53:31 -0000
Date: Sun, 12 Jan 2003 15:53:31 -0800
From: ilya@theIlya.com
To: jmjsgi <jmjsgi@free.fr>
Cc: "linux-mips@linux-mips.org" <linux-mips@linux-mips.org>
Subject: Re: sgi O2 linux
Message-ID: <20030112235331.GA6184@gateway.total-knowledge.com>
References: <3E21FAC0.E69BD643@free.fr>
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="X1bOJ3K7DJ5YkBrT"
Content-Disposition: inline
In-Reply-To: <3E21FAC0.E69BD643@free.fr>
User-Agent: Mutt/1.4i
Return-Path: <ilya@gateway.total-knowledge.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1137
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ilya@theIlya.com
Precedence: bulk
X-list: linux-mips


--X1bOJ3K7DJ5YkBrT
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Start with http://www.total-knowledge.com/progs/mips/o2-howto

	Ilya.

On Mon, Jan 13, 2003 at 12:31:12AM +0100, jmjsgi wrote:
> Hi, i'm french and i woold like install linux on my SGI O2 R5000, but i
> dont know wath version of linux i can take. Can you help me.
> Thank
>=20
>=20

--X1bOJ3K7DJ5YkBrT
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE+If/77sVBmHZT8w8RAvPPAJ0beGxcuVmAQIhuyK9sAtBdOvhSYACfb4GY
rYIDKHPoRIO/kwfO5+5ZHIY=
=FRCW
-----END PGP SIGNATURE-----

--X1bOJ3K7DJ5YkBrT--

From ppopov@mvista.com Mon Jan 13 04:13:57 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 13 Jan 2003 04:15:52 +0000 (GMT)
Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:65010 "EHLO
	av.mvista.com") by linux-mips.org with ESMTP id <S8226259AbTAMEN5>;
	Mon, 13 Jan 2003 04:13:57 +0000
Received: from localhost (av [127.0.0.1])
	by av.mvista.com (8.9.3/8.9.3) with ESMTP id UAA17795;
	Sun, 12 Jan 2003 20:13:47 -0800
Subject: Re: Cpu frequency scaling
From: Pete Popov <ppopov@mvista.com>
To: "Kevin D. Kissell" <kevink@mips.com>
Cc: Ralf Baechle <ralf@linux-mips.org>,
	"Krishnakumar. R" <krishnakumar@naturesoft.net>,
	linux-mips <linux-mips@linux-mips.org>
In-Reply-To: <003b01c2ba6c$f64ef840$10eca8c0@grendel>
References: <200301101600.26246.krishnakumar@naturesoft.net>
	 <20030112180917.A18654@linux-mips.org>
	 <003b01c2ba6c$f64ef840$10eca8c0@grendel>
Content-Type: text/plain
Organization: MontaVista Software
Message-Id: <1042431334.29107.9.camel@adsl.pacbell.net>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.2.1 
Date: 12 Jan 2003 20:15:34 -0800
Content-Transfer-Encoding: 7bit
Return-Path: <ppopov@mvista.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1138
X-Approved-By: ralf@linux-mips.org
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ppopov@mvista.com
Precedence: bulk
X-list: linux-mips

On Sun, 2003-01-12 at 11:01, Kevin D. Kissell wrote:
> > > Can frequency scaling (through software) 
> > > be done on mips using linux ?
> > > 
> > > Is  such a feature feasible in mips ??
> > > 
> > > I could not find any documentation nor patches 
> > > for  frequency
> > > scaling on mips at 
> > > http://www.brodo.de/cpufreq/
> > > :-(
> > 
> > None of the currently supported MIPS CPUs support such a feature in
> > hardware as such our support is already complete and by definition
> > bug free ;-)
> 
> Actually, that's not *quite* true.  A number of MIPS CPUs and
> cores that are otherwise supported by Linux (e.g. 4K, 5K) have
> a "reduced power" mode which is modulated by the CP0 "RP"
> bit. In general, this bit does nothing in the CPU itself, however.
> It was intended that it be connected to system-level logic for
> frequency scaling (1/n normal clock, or CPU=Bus).  So on
> most systems it does nothing, and on the ones where it does
> do something, it's entirely system dependent.  I don't have an
> Alchemy AU1000 spec handy, but since they've integrated
> a lot of other logic with their CPU, and since they designed
> their component to go into low-power devices, it wouldn't
> surprise me in the least if they do something well-defined
> with the RP bit.

Actually the Au1x CPUs support both, frequency and voltage scaling.

> So, to get back to the original question, something highly
> platform dependent *could* be done using MIPS/Linux, 
> via /proc/cpu or some kind of system call, but I don't believe 
> anyone has made such a hook generally available as yet.

For the Au1x CPUs, I had added a /proc interface that allows you to do something
like "echo 192 > /proc/cpufreq" to reduce the frequency from 396 MHz to 192,
or whatever number you chose, but the implementation was very adhoc and
probably not generally useful for other CPUs.  IBM and MontaVista recently 
published a whitepaper on power management that's designed to be arch 
independent. The design considers not only CPU scaling but scaling of all the 
buses as well, which I don't think the cpufreq project takes into account.

Pete


From jpauley@xwizards.com Mon Jan 13 04:31:40 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 13 Jan 2003 04:31:40 +0000 (GMT)
Received: from smtp03.infoave.net ([IPv6:::ffff:165.166.0.28]:64734 "EHLO
	smtp03.infoave.net") by linux-mips.org with ESMTP
	id <S8226262AbTAMEbk>; Mon, 13 Jan 2003 04:31:40 +0000
Received: from opus ([204.116.3.125])
 by SMTP00.InfoAve.Net (PMDF V6.1-1IA5 #38776)
 with ESMTP id <01KR5YSHTN9Y94QAW9@SMTP00.InfoAve.Net> for
 linux-mips@linux-mips.org; Sun, 12 Jan 2003 23:31:35 -0500 (EST)
Date: Sun, 12 Jan 2003 23:32:03 -0500
From: Justin Pauley <jpauley@xwizards.com>
Subject: Decstation 5000/25 with no TFTP
To: linux-mips@linux-mips.org
Message-id: <1042432324.2735.42.camel@Opus>
MIME-version: 1.0
X-Mailer: Ximian Evolution 1.0.8 (1.0.8-10)
Content-type: text/plain
Content-transfer-encoding: 7bit
Return-Path: <jpauley@xwizards.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1139
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: jpauley@xwizards.com
Precedence: bulk
X-list: linux-mips

I have a Decstation 5000/25 that I would like to install Linux onto.
However, because this particular firmware won't allow any TFTP transfers
over a meg I cannot find a solution. The decstation has ethernet and has
a floppy drive. I would appreciate any directions someone could give me
on how to solve the problem of installing Linux on it. Additionally, if
someone has a linux box that uses a mips processor and would care to
sell it to me I would love to buy it from you if I cannot get mine
working. It is for an assembly class at Winthrop Uni (www.winthrop.edu)

Thanks,
Justin Pauley




From macro@ds2.pg.gda.pl Mon Jan 13 08:26:58 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 13 Jan 2003 08:26:59 +0000 (GMT)
Received: from delta.ds2.pg.gda.pl ([IPv6:::ffff:213.192.72.1]:5089 "EHLO
	delta.ds2.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8226270AbTAMI06>; Mon, 13 Jan 2003 08:26:58 +0000
Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id JAA23357;
	Mon, 13 Jan 2003 09:27:04 +0100 (MET)
Date: Mon, 13 Jan 2003 09:27:04 +0100 (MET)
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To: Justin Pauley <jpauley@xwizards.com>
cc: linux-mips@linux-mips.org
Subject: Re: Decstation 5000/25 with no TFTP
In-Reply-To: <1042432324.2735.42.camel@Opus>
Message-ID: <Pine.GSO.3.96.1030113091209.22840B-100000@delta.ds2.pg.gda.pl>
Organization: Technical University of Gdansk
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <macro@ds2.pg.gda.pl>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1140
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: macro@ds2.pg.gda.pl
Precedence: bulk
X-list: linux-mips

On Sun, 12 Jan 2003, Justin Pauley wrote:

> I have a Decstation 5000/25 that I would like to install Linux onto.
> However, because this particular firmware won't allow any TFTP transfers
> over a meg I cannot find a solution. The decstation has ethernet and has
> a floppy drive. I would appreciate any directions someone could give me
> on how to solve the problem of installing Linux on it. Additionally, if

 You can use MOP to boot Linux (and probably any other) ELF images using
mopd running on a Linux server.  I haven't heard of any DECstation model
that would fail this way of booting.  I have made a suitable version of
mopd available at my site, specifically: 
'ftp://ftp.ds2.pg.gda.pl/pub/macro/mopd/' (for raw sources + patches) and
'ftp://ftp.ds2.pg.gda.pl/pub/macro/SRPMS/' (for source RPM packages; i386
and mipsel binaries are available nearby, too).

 All you need to do on the server is to put vmlinux in /home/tftpboot/mop
with a suitable name so that it can be seen by the daemon (see mopd(8)). 
Then you can boot your DECstation client with "boot 3/mop <arguments>"
(either manually or by setting the REX's "boot" variable). 

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


From vchappel@irisa.fr Mon Jan 13 10:05:28 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 13 Jan 2003 10:05:28 +0000 (GMT)
Received: from eau.irisa.fr ([IPv6:::ffff:131.254.60.97]:26549 "EHLO
	eau.irisa.fr") by linux-mips.org with ESMTP id <S8226274AbTAMKF1>;
	Mon, 13 Jan 2003 10:05:27 +0000
Received: from irisa.fr (traezhenn.irisa.fr [131.254.41.15])
	by eau.irisa.fr (8.11.4/8.11.4) with ESMTP id h0DA4qi26470;
	Mon, 13 Jan 2003 11:04:52 +0100 (MET)
Message-ID: <3E228F44.8070309@irisa.fr>
Date: Mon, 13 Jan 2003 11:04:52 +0100
From: Vivien Chappelier <vchappel@irisa.fr>
Reply-To: Vivien Chappelier <vivienc@nerim.net>
User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.0.1) Gecko/20020920 Netscape/7.0
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Ralf Baechle <ralf@oss.sgi.com>
CC: linux-mips@linux-mips.org
Subject: [PATCH 2.5] udelay 
Content-Type: multipart/mixed;
 boundary="------------070901080807060908060409"
X-MailScanner: Found to be clean
Return-Path: <vchappel@irisa.fr>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1141
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: vchappel@irisa.fr
Precedence: bulk
X-list: linux-mips

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

Hi,

         The HZ constant has been changed in 2.5 and this breaks
udelay(). Here is a patch to fix this. Note that the first multiply in
udelay is still optimized out by the compiler if the delay is constant, 
as in current implementation.

Vivien.


--------------070901080807060908060409
Content-Type: text/plain;
 name="linux-mips-udelay.diff"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="linux-mips-udelay.diff"

--- include/asm-mips64/delay.h	2002-12-11 20:44:20.000000000 +0100
+++ include/asm-mips64/delay.h	2003-01-07 20:36:37.000000000 +0100
@@ -41,11 +41,11 @@
 {
 	unsigned long lo;
 
-#if (HZ == 100)
-	usecs *= 0x00068db8bac710cbUL;		/* 2**64 / (1000000 / HZ) */
-#elif (HZ == 128)
-	usecs *= 0x0008637bd05af6c6UL;		/* 2**64 / (1000000 / HZ) */
-#endif
+/* HZ * 2**64 / 1000000 */
+#define __UDELAY_FIXED64_HZ_1000000 (0x8000000000000000UL / (500000 / HZ)) 
+
+	usecs *= __UDELAY_FIXED64_HZ_1000000;
+
 	__asm__("dmultu\t%2,%3"
 		:"=h" (usecs), "=l" (lo)
 		:"r" (usecs),"r" (lpj));
--- include/asm-mips/delay.h	2002-12-11 20:44:18.000000000 +0100
+++ include/asm-mips/delay.h	2003-01-08 19:25:17.000000000 +0100
@@ -40,11 +40,10 @@
 {
 	unsigned long lo;
 
-#if (HZ == 100)
-	usecs *= 0x00068db8;		/* 2**32 / (1000000 / HZ) */
-#elif (HZ == 128)
-	usecs *= 0x0008637b;		/* 2**32 / (1000000 / HZ) */
-#endif
+/* HZ * 2**32 / 1000000 */
+#define __UDELAY_FIXED32_HZ_1000000 (0x80000000UL / (500000 / HZ)) 
+
+	usecs *= __UDELAY_FIXED32_HZ_1000000;
 	__asm__("multu\t%2,%3"
 		:"=h" (usecs), "=l" (lo)
 		:"r" (usecs),"r" (lpj));

--------------070901080807060908060409--


From vchappel@irisa.fr Mon Jan 13 10:07:12 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 13 Jan 2003 10:07:13 +0000 (GMT)
Received: from eau.irisa.fr ([IPv6:::ffff:131.254.60.97]:4534 "EHLO
	eau.irisa.fr") by linux-mips.org with ESMTP id <S8226275AbTAMKHM>;
	Mon, 13 Jan 2003 10:07:12 +0000
Received: from irisa.fr (traezhenn.irisa.fr [131.254.41.15])
	by eau.irisa.fr (8.11.4/8.11.4) with ESMTP id h0DA6Zi26740;
	Mon, 13 Jan 2003 11:06:35 +0100 (MET)
Message-ID: <3E228FAB.5010004@irisa.fr>
Date: Mon, 13 Jan 2003 11:06:35 +0100
From: Vivien Chappelier <vchappel@irisa.fr>
Reply-To: Vivien Chappelier <vivienc@nerim.net>
User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.0.1) Gecko/20020920 Netscape/7.0
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Ralf Baechle <ralf@oss.sgi.com>
CC: linux-mips <linux-mips@linux-mips.org>
Subject: [2.5 PATCH] signal handling
Content-Type: multipart/mixed;
 boundary="------------090906020704070304070501"
X-MailScanner: Found to be clean
Return-Path: <vchappel@irisa.fr>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1142
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: vchappel@irisa.fr
Precedence: bulk
X-list: linux-mips

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

Hello,

         This patch fixes various bugs in the 2.5 signal code (native and
mips64 32bit compatibility code):
         - revert changes to ucontext.h to match the arguments of
setup_sigcontext and restore_sigcontext (which need a sigcontext struct,
not mcontext struct)
         - fix swapped arguments in the call to do_signal in
do_notify_resume
         - cleanup and fix 32 bit compatibility code for mips64, 
including making sigset_t32 and sigset_t size match.

Vivien.

--------------090906020704070304070501
Content-Type: text/plain;
 name="linux-mips-signal.diff"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="linux-mips-signal.diff"

--- include/asm-mips/ucontext.h	2002-10-09 23:12:56.000000000 +0200
+++ include/asm-mips/ucontext.h	2003-01-10 23:36:16.000000000 +0100
@@ -10,33 +10,12 @@
 #ifndef _ASM_UCONTEXT_H
 #define _ASM_UCONTEXT_H
 
-typedef unsigned int greg_t;
-
-#define NGREG 36
-
-typedef greg_t gregset_t[NGREG];
-
-typedef struct fpregset {
-	union {
-		double		fp_dregs[16];
-		float		fp_fregs [32];
-		unsigned int	fp_regs[32];
-	} fp_r;
-	unsigned int fp_csr;
-	unsigned int fp_pad;
-} fpregset_t;
-
-typedef struct {
-	gregset_t gregs;
-	fpregset_t fpregs;
-} mcontext_t;
-
 struct ucontext {
-	unsigned long	uc_flags;
-	struct ucontext	*uc_link;
-	stack_t		uc_stack;
-	mcontext_t	uc_mcontext;
-	sigset_t	uc_sigmask;	/* mask last for extensibility */
+	unsigned long	  uc_flags;
+	struct ucontext  *uc_link;
+	stack_t		  uc_stack;
+	struct sigcontext uc_mcontext;
+	sigset_t	  uc_sigmask;	/* mask last for extensibility */
 };
 
 #endif /* _ASM_UCONTEXT_H */
--- include/asm-mips64/ucontext.h	2002-10-09 23:12:58.000000000 +0200
+++ include/asm-mips64/ucontext.h	2003-01-10 23:35:06.000000000 +0100
@@ -10,33 +10,12 @@
 #ifndef _ASM_UCONTEXT_H
 #define _ASM_UCONTEXT_H
 
-typedef unsigned int greg_t;
-
-#define NGREG 36
-
-typedef greg_t gregset_t[NGREG];
-
-typedef struct fpregset {
-	union {
-		double		fp_dregs[32];
-		float		fp_fregs [32];
-		unsigned long	fp_regs[32];
-	} fp_r;
-	unsigned int fp_csr;
-	unsigned int fp_pad;
-} fpregset_t;
-
-typedef struct {
-	gregset_t gregs;
-	fpregset_t fpregs;
-} mcontext_t;
-
 struct ucontext {
-	unsigned long	uc_flags;
-	struct ucontext	*uc_link;
-	stack_t		uc_stack;
-	mcontext_t	uc_mcontext;
-	sigset_t	uc_sigmask;	/* mask last for extensibility */
+	unsigned long	  uc_flags;
+	struct ucontext  *uc_link;
+	stack_t		  uc_stack;
+	struct sigcontext uc_mcontext;
+	sigset_t	  uc_sigmask;	/* mask last for extensibility */
 };
 
 #endif /* _ASM_UCONTEXT_H */
--- include/asm-mips64/signal.h	2002-11-09 16:16:54.000000000 +0100
+++ include/asm-mips64/signal.h	2003-01-11 00:57:26.000000000 +0100
@@ -11,25 +11,47 @@
 
 #include <linux/types.h>
 
-#define _NSIG		64
+#define _NSIG		128
 #define _NSIG_BPW	64
 #define _NSIG_WORDS	(_NSIG / _NSIG_BPW)
 
 typedef struct {
-	long sig[_NSIG_WORDS];
+	unsigned long sig[_NSIG_WORDS];
 } sigset_t;
 
+typedef unsigned long old_sigset_t;		/* at least 32 bits */
+
+#ifdef __KERNEL__
+
 #define _NSIG32		128
 #define _NSIG_BPW32	32
 #define _NSIG_WORDS32	(_NSIG32 / _NSIG_BPW32)
 
 typedef struct {
-	long sig[_NSIG_WORDS32];
+	unsigned int sig[_NSIG_WORDS32];
 } sigset_t32;
 
-typedef unsigned long old_sigset_t;		/* at least 32 bits */
 typedef unsigned int old_sigset_t32;
 
+typedef unsigned int __sighandler_t32;
+
+struct sigaction32 {
+	unsigned int		sa_flags;
+	__sighandler_t32	sa_handler;
+	sigset_t32		sa_mask;
+	unsigned int		sa_restorer;
+	unsigned int		sa_resv[1];     /* reserved */
+};
+
+/* IRIX compatible stack_t  */
+typedef struct sigaltstack32 {
+	unsigned int ss_sp;
+	__kernel_size_t32 ss_size;
+	int ss_flags;
+} stack32_t;
+
+#endif /* __KERNEL__ */
+
 #define SIGHUP		 1	/* Hangup (POSIX).  */
 #define SIGINT		 2	/* Interrupt (ANSI).  */
 #define SIGQUIT		 3	/* Quit (POSIX).  */
--- arch/mips/kernel/signal.c	2002-11-09 16:10:08.000000000 +0100
+++ arch/mips/kernel/signal.c	2003-01-10 21:26:35.000000000 +0100
@@ -580,6 +580,6 @@
 			return;
 		}
 #endif
-		do_signal(regs,oldset);
+		do_signal(oldset, regs);
 	}
 }
--- arch/mips64/kernel/signal.c	2002-11-09 16:10:14.000000000 +0100
+++ arch/mips64/kernel/signal.c	2003-01-10 22:40:25.000000000 +0100
@@ -411,6 +411,6 @@
 			return;
 		}
 #endif
-		do_signal(regs,oldset);
+		do_signal(oldset, regs);
 	}
 }
--- arch/mips64/kernel/signal32.c	2002-11-09 16:10:14.000000000 +0100
+++ arch/mips64/kernel/signal32.c	2003-01-11 01:39:50.000000000 +0100
@@ -35,37 +35,10 @@
 
 extern asmlinkage void do_syscall_trace(void);
 
-/* 32-bit compatibility types */
-
-#define _NSIG32_BPW	32
-#define _NSIG32_WORDS	(_NSIG / _NSIG32_BPW)
-
-typedef struct {
-	unsigned int sig[_NSIG32_WORDS];
-} sigset32_t;
-
-typedef unsigned int __sighandler32_t;
-typedef void (*vfptr_t)(void);
-
-struct sigaction32 {
-	unsigned int		sa_flags;
-	__sighandler32_t	sa_handler;
-	sigset32_t		sa_mask;
-	unsigned int		sa_restorer;
-	int			sa_resv[1];     /* reserved */
-};
-
-/* IRIX compatible stack_t  */
-typedef struct sigaltstack32 {
-	s32 ss_sp;
-	__kernel_size_t32 ss_size;
-	int ss_flags;
-} stack32_t;
-
 extern void __put_sigset_unknown_nsig(void);
 extern void __get_sigset_unknown_nsig(void);
 
-static inline int put_sigset(const sigset_t *kbuf, sigset32_t *ubuf)
+static inline int put_sigset(const sigset_t *kbuf, sigset_t32 *ubuf)
 {
 	int err = 0;
 
@@ -86,7 +59,7 @@
 	return err;
 }
 
-static inline int get_sigset(sigset_t *kbuf, const sigset32_t *ubuf)
+static inline int get_sigset(sigset_t *kbuf, const sigset_t32 *ubuf)
 {
 	int err = 0;
 	unsigned long sig[4];
@@ -115,11 +88,11 @@
  */
 asmlinkage inline int sys32_sigsuspend(abi64_no_regargs, struct pt_regs regs)
 {
-	sigset32_t *uset;
+	sigset_t32 *uset;
 	sigset_t newset, saveset;
 
 	save_static(&regs);
-	uset = (sigset32_t *) regs.regs[4];
+	uset = (sigset_t32 *) regs.regs[4];
 	if (get_sigset(&newset, uset))
 		return -EFAULT;
 	sigdelsetmask(&newset, ~_BLOCKABLE);
@@ -142,17 +115,17 @@
 
 asmlinkage int sys32_rt_sigsuspend(abi64_no_regargs, struct pt_regs regs)
 {
-	sigset32_t *uset;
+	sigset_t32 *uset;
 	sigset_t newset, saveset;
         size_t sigsetsize;
 
 	save_static(&regs);
 	/* XXX Don't preclude handling different sized sigset_t's.  */
 	sigsetsize = regs.regs[5];
-	if (sigsetsize != sizeof(sigset32_t))
+	if (sigsetsize != sizeof(sigset_t32))
 		return -EINVAL;
 
-	uset = (sigset32_t *) regs.regs[4];
+	uset = (sigset_t32 *) regs.regs[4];
 	if (get_sigset(&newset, uset))
 		return -EFAULT;
 	sigdelsetmask(&newset, ~_BLOCKABLE);
@@ -795,7 +768,7 @@
 asmlinkage long sys_rt_sigprocmask(int how, sigset_t *set, sigset_t *oset,
 				   size_t sigsetsize);
 
-asmlinkage int sys32_rt_sigprocmask(int how, sigset32_t *set, sigset32_t *oset,
+asmlinkage int sys32_rt_sigprocmask(int how, sigset_t32 *set, sigset_t32 *oset,
 				    unsigned int sigsetsize)
 {
 	sigset_t old_set, new_set;
@@ -818,7 +791,7 @@
 
 asmlinkage long sys_rt_sigpending(sigset_t *set, size_t sigsetsize);
 
-asmlinkage int sys32_rt_sigpending(sigset32_t *uset, unsigned int sigsetsize)
+asmlinkage int sys32_rt_sigpending(sigset_t32 *uset, unsigned int sigsetsize)
 {
 	int ret;
 	sigset_t set;

--------------090906020704070304070501--


From Geert.Uytterhoeven@sonycom.com Mon Jan 13 16:13:23 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 13 Jan 2003 16:13:24 +0000 (GMT)
Received: from mail2.sonytel.be ([IPv6:::ffff:195.0.45.172]:8423 "EHLO
	mail.sonytel.be") by linux-mips.org with ESMTP id <S8226347AbTAMQNX>;
	Mon, 13 Jan 2003 16:13:23 +0000
Received: from vervain.sonytel.be (mail.sonytel.be [10.17.0.26])
	by mail.sonytel.be (8.9.0/8.8.6) with ESMTP id RAA19806
	for <linux-mips@linux-mips.org>; Mon, 13 Jan 2003 17:13:17 +0100 (MET)
Date: Mon, 13 Jan 2003 17:13:17 +0100 (MET)
From: Geert Uytterhoeven <geert@linux-m68k.org>
To: Linux/MIPS Development <linux-mips@linux-mips.org>
Subject: unaligned load in branch delay slot
Message-ID: <Pine.GSO.4.21.0301131704080.21279-100000@vervain.sonytel.be>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <Geert.Uytterhoeven@sonycom.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1143
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: geert@linux-m68k.org
Precedence: bulk
X-list: linux-mips


I'm seeing a crash in 2.4.20 in emulate_load_store_insn(), when accepting a TCP
connection (exact line number influenced by debug code):

Unhandled kernel unaligned access or invalid instruction in unaligned.c::emulate_load_store_insn, line 492:
$0 : 00000000 10008400 30000000 00000000 83c2a380 83d9f80e 838941c0 00000001
$8 : 00000016 c0a80002 c0a80001 00000016 83f326a4 83f326a8 83f326a0 00000000
$16: 83c2a43c 811af440 00000000 83c2a380 803da18c 00000000 00000000 00000000
$24: 00000000 2ac41330                   8039a000 8039baf8 a38415b4 8033eea4
Hi : 00000000
Lo : 00000140
epc  : 80346448    Not tainted
Status: 10008403
Cause : 00000010
Process swapper (pid: 0, stackpage=8039a000)
Stack:    00000000 00000000 00000000 00000000 00000000 00000000 00000000
 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
 00000000 00000000 00000000 00000000 00000000 00000000 00000000 8039a000
 00000001 810d0060 802dd370 00000000 00000000 8039bb70 00000000 8041a690
 803d2000 810c5de0 8041a620 810d0060 802dd370 80213fa4 810c41a0 8039bbc8
 8020ad50 ...
Call Trace:   [<802dd370>] [<802dd370>] [<80213fa4>] [<8020ad50>] [<802ea344>]
 [<802ea2fc>] [<80307e08>] [<802378f8>] [<8020a0d4>] [<8020a0d4>] [<802061d8>]
 [<802061d8>] [<8020a0d4>] [<8033eea4>] [<80346fbc>] [<80347060>] [<8034716c>]
 [<803476f4>] [<80329a50>] [<80326648>] [<8032952c>] [<80329ddc>] [<80329d98>]
 [<80329ddc>] [<8031700c>] [<80329790>] [<8031700c>] [<80316bb4>] [<803172b8>]
 [<802df95c>] [<8021bf30>] [<80317500>] [<80316ecc>] [<8021b810>] [<80379278>]
 [<8020ad50>] [<8020aeb0>] [<8020ae84>] [<80379228>] [<80204250>] ...

Code: 8cc30064  3c023000  00621824 <14600012> 8cb50010  8c840238  8c820004  90830000  00621007 
Kernel panic: Aiee, killing interrupt handler!
In interrupt handler - not syncing

803463f8 <tcp_v4_conn_request>:
803463f8:	27bdfe20 	addiu	sp,sp,-480
803463fc:	afb601d8 	sw	s6,472(sp)
80346400:	afb301cc 	sw	s3,460(sp)
80346404:	afb101c4 	sw	s1,452(sp)
80346408:	afbf01dc 	sw	ra,476(sp)
8034640c:	afb501d4 	sw	s5,468(sp)
80346410:	afb401d0 	sw	s4,464(sp)
80346414:	afb201c8 	sw	s2,456(sp)
80346418:	afb001c0 	sw	s0,448(sp)
8034641c:	00a08821 	move	s1,a1
80346420:	8ca50020 	lw	a1,32(a1)
80346424:	8e260028 	lw	a2,40(s1)
80346428:	8e320044 	lw	s2,68(s1)
8034642c:	8ca2000c 	lw	v0,12(a1)
80346430:	00809821 	move	s3,a0
80346434:	0000b021 	move	s6,zero
80346438:	afa201b8 	sw	v0,440(sp)
8034643c:	8cc30064 	lw	v1,100(a2)
80346440:	3c023000 	lui	v0,0x3000
80346444:	00621824 	and	v1,v1,v0
80346448:	14600012 	bnez	v1,80346494 <tcp_v4_conn_request+0x9c>
8034644c:	8cb50010 	lw	s5,16(a1)
                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
80346450:	8c840238 	lw	a0,568(a0)
80346454:	8c820004 	lw	v0,4(a0)
80346458:	90830000 	lbu	v1,0(a0)
8034645c:	00621007 	srav	v0,v0,v1

If I print the parameters at label `sigill' in emulate_load_store_insn(), I
get:

    pc 0x80346448 addr 0x83d9f81e ins 0x14600012

And emulate_load_store_insn() gets confused because 0x14600012 is not a
load/store. 0x14600012 is the branch instruction before the load, not the load
after the branch instruction! Note that bit 31 of cause (CAUSEF_BD) is not set.
Some more investigations showed that the branch is indeed not taken.

Apparently if an unaligned access happens right after a branch which is not
taking, epc points to the branch instruction, and CAUSEF_BD is not set
(technically speaking, this is not a branch delay, since the branch is not
taken :-). Is this expected behavior? The CPU is a VR4120A core.

As a workaround, I assume I can just test whether pc points to a branch
instruction, and increment pc if that's the case?

Thanks!

Gr{oetje,eeting}s,

						Geert

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

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


From uhler@mips.com Mon Jan 13 17:20:09 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 13 Jan 2003 17:20:10 +0000 (GMT)
Received: from ftp.mips.com ([IPv6:::ffff:206.31.31.227]:57551 "EHLO
	mx2.mips.com") by linux-mips.org with ESMTP id <S8226352AbTAMRUJ>;
	Mon, 13 Jan 2003 17:20:09 +0000
Received: from newman.mips.com (ns-dmz [206.31.31.225])
	by mx2.mips.com (8.12.5/8.12.5) with ESMTP id h0DHJm67017127;
	Mon, 13 Jan 2003 09:19:49 -0800 (PST)
Received: from uhler-linux.mips.com (uhler-linux [192.168.11.222])
	by newman.mips.com (8.9.3/8.9.0) with ESMTP id JAA10305;
	Mon, 13 Jan 2003 09:19:49 -0800 (PST)
Received: from uhler-linux.mips.com (uhler@localhost)
	by uhler-linux.mips.com (8.11.2/8.9.3) with ESMTP id h0DHJkG29389;
	Mon, 13 Jan 2003 09:19:46 -0800
Message-Id: <200301131719.h0DHJkG29389@uhler-linux.mips.com>
X-Authentication-Warning: uhler-linux.mips.com: uhler owned process doing -bs
X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4
To: Geert Uytterhoeven <geert@linux-m68k.org>
cc: Linux/MIPS Development <linux-mips@linux-mips.org>
cc: uhler@mips.com
Reply-To: uhler@mips.com
Subject: Re: unaligned load in branch delay slot 
In-reply-to: Your message of "Mon, 13 Jan 2003 17:13:17 +0100."
             <Pine.GSO.4.21.0301131704080.21279-100000@vervain.sonytel.be> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Mon, 13 Jan 2003 09:19:45 -0800
From: "Mike Uhler" <uhler@mips.com>
Return-Path: <uhler@mips.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1144
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: uhler@mips.com
Precedence: bulk
X-list: linux-mips


> If I print the parameters at label `sigill' in emulate_load_store_insn(), I
> get:
> 
>     pc 0x80346448 addr 0x83d9f81e ins 0x14600012
> 
> And emulate_load_store_insn() gets confused because 0x14600012 is not a
> load/store. 0x14600012 is the branch instruction before the load, not the load
> after the branch instruction! Note that bit 31 of cause (CAUSEF_BD) is not set.
> Some more investigations showed that the branch is indeed not taken.
> 
> Apparently if an unaligned access happens right after a branch which is not
> taking, epc points to the branch instruction, and CAUSEF_BD is not set
> (technically speaking, this is not a branch delay, since the branch is not
> taken :-). Is this expected behavior? The CPU is a VR4120A core.
> 
> As a workaround, I assume I can just test whether pc points to a branch
> instruction, and increment pc if that's the case?

Prior to the MIPS32/MIPS64 architecture definition, which requires that EPC
point at the branch and the Cause[BD] bit be set on any exception in the
branch delay slot, there were a few CPUs which interpreted the rules in the
manner that you describe.  I don't happen to have a VR4120A manual in front
of me, but the behavior you describe could easily be the case of this differnt
interpretation.

/gmu

-- 

  =*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
  Michael Uhler, VP, Systems, Architecture, and Software Products 
  MIPS Technologies, Inc.   Email: uhler@mips.com   Pager: uhler_p@mips.com
  1225 Charleston Road      Voice:  (650)567-5025   FAX:   (650)567-5225
  Mountain View, CA 94043   Mobile: (650)868-6870   Admin: (650)567-5085



From karsten@excalibur.cologne.de Mon Jan 13 17:55:17 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 13 Jan 2003 17:55:17 +0000 (GMT)
Received: from natsmtp01.webmailer.de ([IPv6:::ffff:192.67.198.81]:39659 "EHLO
	post.webmailer.de") by linux-mips.org with ESMTP
	id <S8226365AbTAMRzR>; Mon, 13 Jan 2003 17:55:17 +0000
Received: from excalibur.cologne.de (p508510D9.dip.t-dialin.net [80.133.16.217])
	by post.webmailer.de (8.9.3/8.8.7) with ESMTP id SAA10160;
	Mon, 13 Jan 2003 18:55:07 +0100 (MET)
Received: from karsten by excalibur.cologne.de with local (Exim 3.35 #1 (Debian))
	id 18Y8tL-0000DA-00; Mon, 13 Jan 2003 19:00:55 +0100
Date: Mon, 13 Jan 2003 19:00:53 +0100
From: Karsten Merker <karsten@excalibur.cologne.de>
To: linux-mips@linux-mips.org
Cc: Justin Pauley <jpauley@xwizards.com>
Subject: Re: Decstation 5000/25 with no TFTP
Message-ID: <20030113180053.GA432@excalibur.cologne.de>
Mail-Followup-To: Karsten Merker <karsten@excalibur.cologne.de>,
	linux-mips@linux-mips.org, Justin Pauley <jpauley@xwizards.com>
References: <1042432324.2735.42.camel@Opus> <Pine.GSO.3.96.1030113091209.22840B-100000@delta.ds2.pg.gda.pl>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Pine.GSO.3.96.1030113091209.22840B-100000@delta.ds2.pg.gda.pl>
User-Agent: Mutt/1.3.28i
X-No-Archive: yes
Return-Path: <karsten@excalibur.cologne.de>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1145
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: karsten@excalibur.cologne.de
Precedence: bulk
X-list: linux-mips

On Mon, Jan 13, 2003 at 09:27:04AM +0100, Maciej W. Rozycki wrote:
> On Sun, 12 Jan 2003, Justin Pauley wrote:
> 
> > I have a Decstation 5000/25 that I would like to install Linux onto.
> > However, because this particular firmware won't allow any TFTP transfers
> > over a meg I cannot find a solution. The decstation has ethernet and has
[SNIP]
>  You can use MOP to boot Linux (and probably any other) ELF images using
> mopd running on a Linux server.  I haven't heard of any DECstation model

As mopd requires an ELF image and the offical Debian netboot images
are tftpimages in ECOFF, you should try using MOP with 

http://people.debian.org/~merker/experimental_packages/bf-pre3.0.24-20021224/unpacked/mopimage-r3k-kn02

As URL for getting kernel and modules give

http://people.debian.org/~merker/experimental_packages/bf-pre3.0.24-20021224/unpacked/

to the installer. These are installer images built from the Debian
"boot-floppies" CVS and contain an important fix regarding the Personal
DECstation series, which is not in the last official release.

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 Geert.Uytterhoeven@sonycom.com Mon Jan 13 18:04:54 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 13 Jan 2003 18:04:55 +0000 (GMT)
Received: from mail2.sonytel.be ([IPv6:::ffff:195.0.45.172]:37536 "EHLO
	mail.sonytel.be") by linux-mips.org with ESMTP id <S8226369AbTAMSEy>;
	Mon, 13 Jan 2003 18:04:54 +0000
Received: from vervain.sonytel.be (mail.sonytel.be [10.17.0.26])
	by mail.sonytel.be (8.9.0/8.8.6) with ESMTP id TAA00817;
	Mon, 13 Jan 2003 19:04:35 +0100 (MET)
Date: Mon, 13 Jan 2003 19:04:36 +0100 (MET)
From: Geert Uytterhoeven <geert@linux-m68k.org>
To: Mike Uhler <uhler@mips.com>
cc: Linux/MIPS Development <linux-mips@linux-mips.org>
Subject: Re: unaligned load in branch delay slot 
In-Reply-To: <200301131719.h0DHJkG29389@uhler-linux.mips.com>
Message-ID: <Pine.GSO.4.21.0301131901500.21279-100000@vervain.sonytel.be>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <Geert.Uytterhoeven@sonycom.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1146
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: geert@linux-m68k.org
Precedence: bulk
X-list: linux-mips

On Mon, 13 Jan 2003, Mike Uhler wrote:
> > If I print the parameters at label `sigill' in emulate_load_store_insn(), I
> > get:
> > 
> >     pc 0x80346448 addr 0x83d9f81e ins 0x14600012
> > 
> > And emulate_load_store_insn() gets confused because 0x14600012 is not a
> > load/store. 0x14600012 is the branch instruction before the load, not the load
> > after the branch instruction! Note that bit 31 of cause (CAUSEF_BD) is not set.
> > Some more investigations showed that the branch is indeed not taken.
> > 
> > Apparently if an unaligned access happens right after a branch which is not
> > taking, epc points to the branch instruction, and CAUSEF_BD is not set
> > (technically speaking, this is not a branch delay, since the branch is not
> > taken :-). Is this expected behavior? The CPU is a VR4120A core.
> > 
> > As a workaround, I assume I can just test whether pc points to a branch
> > instruction, and increment pc if that's the case?
> 
> Prior to the MIPS32/MIPS64 architecture definition, which requires that EPC
> point at the branch and the Cause[BD] bit be set on any exception in the
> branch delay slot, there were a few CPUs which interpreted the rules in the
> manner that you describe.  I don't happen to have a VR4120A manual in front
> of me, but the behavior you describe could easily be the case of this differnt
> interpretation.

Thanks!

The following patch (against linux-mips-2.4.x CVS) cures my crash.

I don't know on which CPUs this may happen (need #ifdef CONFIG_CPU_VR41XX?),
nor whether all branch and jump instructions are affected (I included
everything that starts with a `b' or `j').

Index: arch/mips/kernel/unaligned.c
===================================================================
RCS file: /home/cvs/linux/arch/mips/kernel/unaligned.c,v
retrieving revision 1.15.2.14
diff -u -r1.15.2.14 unaligned.c
--- arch/mips/kernel/unaligned.c	6 Jan 2003 22:05:25 -0000	1.15.2.14
+++ arch/mips/kernel/unaligned.c	13 Jan 2003 18:01:26 -0000
@@ -103,6 +103,7 @@
 	/*
 	 * This load never faults.
 	 */
+retry:
 	__get_user(insn.word, (unsigned int *)pc);
 
 	switch (insn.i_format.opcode) {
@@ -134,6 +135,26 @@
 	case lbu_op:
 	case sb_op:
 		goto sigbus;
+
+	/*
+	 * On some CPUs, if an unaligned access happens in a branch delay slot
+	 * and the branch is not taken, EPC points at the branch instruction,
+	 * but the BD bit in the cause register is not set.
+	 */
+	case bcond_op:
+	case j_op:
+	case jal_op:
+	case beq_op:
+	case bne_op:
+	case blez_op:
+	case bgtz_op:
+	case beql_op:
+	case bnel_op:
+	case blezl_op:
+	case bgtzl_op:
+	case jalx_op:
+		pc += 4;
+		goto retry;
 
 	/*
 	 * The remaining opcodes are the ones that are really of interest.

Gr{oetje,eeting}s,

						Geert

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

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


From uhler@mips.com Mon Jan 13 20:12:52 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 13 Jan 2003 20:12:53 +0000 (GMT)
Received: from mx2.mips.com ([IPv6:::ffff:206.31.31.227]:57559 "EHLO
	mx2.mips.com") by linux-mips.org with ESMTP id <S8226378AbTAMUMw>;
	Mon, 13 Jan 2003 20:12:52 +0000
Received: from newman.mips.com (ns-dmz [206.31.31.225])
	by mx2.mips.com (8.12.5/8.12.5) with ESMTP id h0DKCW67018435;
	Mon, 13 Jan 2003 12:12:32 -0800 (PST)
Received: from uhler-linux.mips.com (uhler-linux [192.168.11.222])
	by newman.mips.com (8.9.3/8.9.0) with ESMTP id MAA07246;
	Mon, 13 Jan 2003 12:12:30 -0800 (PST)
Received: from uhler-linux.mips.com (uhler@localhost)
	by uhler-linux.mips.com (8.11.2/8.9.3) with ESMTP id h0DKCS631737;
	Mon, 13 Jan 2003 12:12:28 -0800
Message-Id: <200301132012.h0DKCS631737@uhler-linux.mips.com>
X-Authentication-Warning: uhler-linux.mips.com: uhler owned process doing -bs
X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4
To: Geert Uytterhoeven <geert@linux-m68k.org>
cc: Mike Uhler <uhler@mips.com>,
	Linux/MIPS Development <linux-mips@linux-mips.org>
cc: uhler@mips.com
Reply-To: uhler@mips.com
Subject: Re: unaligned load in branch delay slot 
In-reply-to: Your message of "Mon, 13 Jan 2003 19:04:36 +0100."
             <Pine.GSO.4.21.0301131901500.21279-100000@vervain.sonytel.be> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Mon, 13 Jan 2003 12:12:28 -0800
From: "Mike Uhler" <uhler@mips.com>
Return-Path: <uhler@mips.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1147
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: uhler@mips.com
Precedence: bulk
X-list: linux-mips


> 
> Thanks!
> 
> The following patch (against linux-mips-2.4.x CVS) cures my crash.
> 
> I don't know on which CPUs this may happen (need #ifdef CONFIG_CPU_VR41XX?),
> nor whether all branch and jump instructions are affected (I included
> everything that starts with a `b' or `j').

Since all MIPS jumps are unconditional, one can never have a non-taken
jump, so you can eliminate those from the patch.

/gmu

-- 

  =*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
  Michael Uhler, VP, Systems, Architecture, and Software Products 
  MIPS Technologies, Inc.   Email: uhler@mips.com   Pager: uhler_p@mips.com
  1225 Charleston Road      Voice:  (650)567-5025   FAX:   (650)567-5225
  Mountain View, CA 94043   Mobile: (650)868-6870   Admin: (650)567-5085



From gilad@riverhead.com Tue Jan 14 10:12:04 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 14 Jan 2003 10:12:04 +0000 (GMT)
Received: from mail.wanwall.com ([IPv6:::ffff:194.90.64.163]:31500 "EHLO
	mail.riverhead.com") by linux-mips.org with ESMTP
	id <S8225949AbTANKME>; Tue, 14 Jan 2003 10:12:04 +0000
Received: from GILAD (comp113.wanwall.com [10.0.0.113])
	by mail.riverhead.com (8.11.0/8.11.0) with SMTP id h0EAClv01441
	for <linux-mips@linux-mips.org>; Tue, 14 Jan 2003 12:12:48 +0200
X-RAV-AntiVirus: This e-mail has been scanned for viruses on host: mail.riverhead.com
From: "Gilad Benjamini" <gilad@riverhead.com>
To: <linux-mips@linux-mips.org>
Subject: insmod failure: "Unhandled relocation" errors
Date: Tue, 14 Jan 2003 12:06:46 +0200
Message-ID: <001801c2bbb4$a6177de0$7100000a@riverhead.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0019_01C2BBC5.69A04DE0"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Importance: Normal
Return-Path: <gilad@riverhead.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1148
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: gilad@riverhead.com
Precedence: bulk
X-list: linux-mips

This is a multi-part message in MIME format.

------=_NextPart_000_0019_01C2BBC5.69A04DE0
Content-Type: text/plain;
	charset="windows-1255"
Content-Transfer-Encoding: 7bit

Hi,
I've built,compiled and ran successfully a 64 bit kernel on my 
mips64 platform. Kernel was compiled with support for 32 bit binaries.

I am now trying to insert a module, a standard module from
the kernel tree, and get lots of errors such as:
"Unhandled relocation of type 18 for"
or
"Unhandled relocation of type 18 for <function_name>"

How can this be resolved ?

TIA



------=_NextPart_000_0019_01C2BBC5.69A04DE0
Content-Type: text/html;
	charset="windows-1255"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dwindows-1255">


<META content=3D"MSHTML 6.00.2800.1126" name=3DGENERATOR></HEAD>
<BODY>
<DIV><SPAN class=3D240080310-14012003><FONT face=3DArial=20
size=3D2>Hi,</FONT></SPAN></DIV>
<DIV><SPAN class=3D240080310-14012003><FONT face=3DArial size=3D2>I've =
built,compiled=20
and ran successfully a 64 bit kernel on my </FONT></SPAN></DIV>
<DIV><SPAN class=3D240080310-14012003><FONT face=3DArial size=3D2>mips64 =
platform.=20
Kernel was compiled with support for 32 bit =
binaries.</FONT></SPAN></DIV>
<DIV><SPAN class=3D240080310-14012003><FONT face=3DArial=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D240080310-14012003><FONT face=3DArial size=3D2>I am =
now trying to=20
insert a module, a standard module from</FONT></SPAN></DIV>
<DIV><SPAN class=3D240080310-14012003><FONT face=3DArial size=3D2>the =
kernel tree, and=20
get lots of errors such as:</FONT></SPAN></DIV>
<DIV><SPAN class=3D240080310-14012003><FONT face=3DArial =
size=3D2>"Unhandled=20
relocation of type 18 for"</FONT></SPAN></DIV>
<DIV><SPAN class=3D240080310-14012003><FONT face=3DArial=20
size=3D2>or</FONT></SPAN></DIV>
<DIV><SPAN class=3D240080310-14012003><FONT face=3DArial =
size=3D2>"Unhandled=20
relocation of type 18 for &lt;function_name&gt;"</FONT></SPAN></DIV>
<DIV><SPAN class=3D240080310-14012003><FONT face=3DArial=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D240080310-14012003><FONT face=3DArial size=3D2>How =
can this be=20
resolved ?</FONT></SPAN></DIV>
<DIV><SPAN class=3D240080310-14012003><FONT face=3DArial=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D240080310-14012003><FONT face=3DArial=20
size=3D2>TIA</FONT></SPAN></DIV>
<DIV><SPAN class=3D240080310-14012003></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D240080310-14012003><FONT face=3DArial=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D240080310-14012003><FONT face=3DArial=20
size=3D2></FONT></SPAN>&nbsp;</DIV></BODY></HTML>

------=_NextPart_000_0019_01C2BBC5.69A04DE0--


From amit_lubovsky@yahoo.com Tue Jan 14 13:28:36 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 14 Jan 2003 13:28:38 +0000 (GMT)
Received: from web14805.mail.yahoo.com ([IPv6:::ffff:216.136.224.221]:35332
	"HELO web14805.mail.yahoo.com") by linux-mips.org with SMTP
	id <S8224939AbTANN2g>; Tue, 14 Jan 2003 13:28:36 +0000
Message-ID: <20030114132824.75177.qmail@web14805.mail.yahoo.com>
Received: from [192.114.47.51] by web14805.mail.yahoo.com via HTTP; Tue, 14 Jan 2003 05:28:24 PST
Date: Tue, 14 Jan 2003 05:28:24 -0800 (PST)
From: amit lubovsky <amit_lubovsky@yahoo.com>
Subject: malta-5kc
To: mips-linux <linux-mips@linux-mips.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Return-Path: <amit_lubovsky@yahoo.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1149
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: amit_lubovsky@yahoo.com
Precedence: bulk
X-list: linux-mips

Hi,
I try to load a linux image to a malta-5kc board with
a hw debugger.

Before I load the image I load YAMON in order to
initialize the board.

This doesn't work and I have understood that I have to
set up some of the cpu registers to certain values
(like for command line parameters, etc.)

Could anyone help me with that?, which registers and
to what values?

Thanks,
Amit.


__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com

From ralf@linux-mips.org Tue Jan 14 17:06:02 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 14 Jan 2003 17:06:03 +0000 (GMT)
Received: from p508B634D.dip.t-dialin.net ([IPv6:::ffff:80.139.99.77]:41611
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8224939AbTANRGC>; Tue, 14 Jan 2003 17:06:02 +0000
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.11.6/8.11.6) id h0EH5q923779;
	Tue, 14 Jan 2003 18:05:52 +0100
Date: Tue, 14 Jan 2003 18:05:52 +0100
From: Ralf Baechle <ralf@linux-mips.org>
To: Gilad Benjamini <gilad@riverhead.com>
Cc: linux-mips@linux-mips.org
Subject: Re: insmod failure: "Unhandled relocation" errors
Message-ID: <20030114180551.A23742@linux-mips.org>
References: <001801c2bbb4$a6177de0$7100000a@riverhead.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5.1i
In-Reply-To: <001801c2bbb4$a6177de0$7100000a@riverhead.com>; from gilad@riverhead.com on Tue, Jan 14, 2003 at 12:06:46PM +0200
Return-Path: <ralf@linux-mips.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1150
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips

On Tue, Jan 14, 2003 at 12:06:46PM +0200, Gilad Benjamini wrote:

> I've built,compiled and ran successfully a 64 bit kernel on my 
> mips64 platform. Kernel was compiled with support for 32 bit binaries.
> 
> I am now trying to insert a module, a standard module from
> the kernel tree, and get lots of errors such as:
> "Unhandled relocation of type 18 for"
> or
> "Unhandled relocation of type 18 for <function_name>"
> 
> How can this be resolved ?

Modules are not supported on 64-bit kernel yet.

  Ralf

From mike.connors@ghs.com Tue Jan 14 17:16:36 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 14 Jan 2003 17:16:36 +0000 (GMT)
Received: from eta.ghs.com ([IPv6:::ffff:63.102.70.66]:46316 "EHLO eta.ghs.com")
	by linux-mips.org with ESMTP id <S8224939AbTANRQg>;
	Tue, 14 Jan 2003 17:16:36 +0000
Received: from blaze.ghs.com (blaze.ghs.com [192.67.158.233])
	by eta.ghs.com (8.10.2/8.10.2) with ESMTP id h0EHIb908894
	for <linux-mips@linux-mips.org>; Tue, 14 Jan 2003 09:18:37 -0800 (PST)
Received: from NOMAD (vpn016.ghs.com [10.239.157.16])
	by blaze.ghs.com (8.10.2+Sun/8.10.2+Sun) with ESMTP id h0EHIaX14841
	for <linux-mips@linux-mips.org>; Tue, 14 Jan 2003 09:18:36 -0800 (PST)
From: "Mike Connors" <mike.connors@ghs.com>
To: "'mips-linux'" <linux-mips@linux-mips.org>
Subject: RE: malta-5kc
Date: Tue, 14 Jan 2003 09:15:30 -0800
Organization: Green Hills Software
Message-ID: <001e01c2bbf0$8a5f9420$6401a8c0@NOMAD>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Importance: Normal
In-reply-to: <20030114132824.75177.qmail@web14805.mail.yahoo.com>
Return-Path: <mike.connors@ghs.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1151
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: mike.connors@ghs.com
Precedence: bulk
X-list: linux-mips

The easiest thing to do is have YAMON load the image, 
connect with your debugger and set a breakpoint at 
some starting point of the linux kernel, then enter 
the go command with the program arguments on the 
YAMON command line.  

The rest is debugger specific.  If you are using Green 
Hills Software's MULTI debugger, I can help you with 
the details.  If you are using MULTI and you give me a 
little time to figure it out, I could even give you a 
way to do it without YAMON. 

-- Mike 
--- 
Mike Connors			Green Hills Software, San Clemente 
Field Applications Engineer	131 Avenida Victoria 
mailto:mikec@ghs.com		San Clemente, CA  92672 
phone: 1-949-369-3950		
cell:  1-949-412-3951		fax: 1-949-369-3959 

Green Hills in the News: 

INTEGRITYR RTOS Flies In F-16 Fighter Jet 
	http://www.ghs.com/news/221213b.html 
Boeing Selects INTEGRITYR RTOS for B-1B Avionics Upgrade 
	http://www.ghs.com/news/221213b.html 
INTEGRITYR RTOS selected by Boeing's C-17 Globemaster III 
	http://www.ghs.com/news/221104b.html 

Green Hills Software Inc.	phone: 	1-805-965-6044 
30 West Sola Street		toll-free: 1-800-765-GREEN (4733) 
Santa Barbara, CA 93101		Tech-Support: 1-877-GHS-TECH (447-8324) 
http://www.ghs.com		Email Support: mailto:support@ghs.com 

> -----Original Message-----
> From: linux-mips-bounce@linux-mips.org 
> [mailto:linux-mips-bounce@linux-mips.org] On Behalf Of amit lubovsky
> Sent: Tuesday, January 14, 2003 5:28 AM
> To: mips-linux
> Subject: malta-5kc
> 
> 
> Hi,
> I try to load a linux image to a malta-5kc board with
> a hw debugger.
> 
> Before I load the image I load YAMON in order to
> initialize the board.
> 
> This doesn't work and I have understood that I have to
> set up some of the cpu registers to certain values
> (like for command line parameters, etc.)
> 
> Could anyone help me with that?, which registers and
> to what values?
> 
> Thanks,
> Amit.
> 
> 
> __________________________________________________
> Do you Yahoo!?
> Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
> http://mailplus.yahoo.com
> 
> 


From lindahl@keyresearch.com Tue Jan 14 19:09:59 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 14 Jan 2003 19:10:00 +0000 (GMT)
Received: from ppp-66-122-194-201.aonnetworks.com ([IPv6:::ffff:66.122.194.201]:21376
	"EHLO localhost.localdomain") by linux-mips.org with ESMTP
	id <S8224939AbTANTJ7>; Tue, 14 Jan 2003 19:09:59 +0000
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1])
	by localhost.localdomain (8.12.5/8.12.5) with ESMTP id h0EJEJl5001353
	for <linux-mips@linux-mips.org>; Tue, 14 Jan 2003 11:14:19 -0800
Received: (from lindahl@localhost)
	by localhost.localdomain (8.12.5/8.12.5/Submit) id h0EJEIxT001351
	for linux-mips@linux-mips.org; Tue, 14 Jan 2003 11:14:18 -0800
X-Authentication-Warning: localhost.localdomain: lindahl set sender to lindahl@keyresearch.com using -f
Date: Tue, 14 Jan 2003 11:14:18 -0800
From: Greg Lindahl <lindahl@keyresearch.com>
To: linux-mips@linux-mips.org
Subject: Re: insmod failure: "Unhandled relocation" errors
Message-ID: <20030114191417.GA1243@wumpus.internal.keyresearch.com>
Mail-Followup-To: linux-mips@linux-mips.org
References: <001801c2bbb4$a6177de0$7100000a@riverhead.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <001801c2bbb4$a6177de0$7100000a@riverhead.com>
User-Agent: Mutt/1.4i
Return-Path: <lindahl@keyresearch.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1152
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: lindahl@keyresearch.com
Precedence: bulk
X-list: linux-mips

On Tue, Jan 14, 2003 at 12:06:46PM +0200, Gilad Benjamini wrote:

> I am now trying to insert a module, a standard module from
> the kernel tree, and get lots of errors such as:
> "Unhandled relocation of type 18 for"
> or
> "Unhandled relocation of type 18 for <function_name>"

I'm impressed that it got this far -- let me guess, big endian?
Little endian didn't even get that far last time I tried it.

greg

From agx@sigxcpu.org Tue Jan 14 23:06:39 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 14 Jan 2003 23:06:39 +0000 (GMT)
Received: from honk1.physik.uni-konstanz.de ([IPv6:::ffff:134.34.144.71]:61857
	"EHLO honk1.physik.uni-konstanz.de") by linux-mips.org with ESMTP
	id <S8225198AbTANXGj>; Tue, 14 Jan 2003 23:06:39 +0000
Received: from bogon.sigxcpu.org (kons-d9bb5464.pool.mediaWays.net [217.187.84.100])
	by honk1.physik.uni-konstanz.de (Postfix) with ESMTP
	id 5E6E92BC2D; Wed, 15 Jan 2003 00:06:35 +0100 (CET)
Received: by bogon.sigxcpu.org (Postfix, from userid 1000)
	id 1FF114B45E; Wed, 15 Jan 2003 00:06:08 +0100 (CET)
Date: Wed, 15 Jan 2003 00:06:08 +0100
From: Guido Guenther <agx@sigxcpu.org>
To: libc-alpha@sources.redhat.com
Cc: linux-mips@linux-mips.org
Subject: [PATCH] INTERNAL_SYSCALL for linux-mips
Message-ID: <20030114230607.GH27645@bogon.ms20.nix>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="UFHRwCdBEJvubb2X"
Content-Disposition: inline
User-Agent: Mutt/1.4i
Return-Path: <agx@sigxcpu.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1153
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: agx@sigxcpu.org
Precedence: bulk
X-list: linux-mips


--UFHRwCdBEJvubb2X
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

Hi,
the attached patch brings mips up to date concerning the
{INTERNAL,INLINE}_SYSCALL macros. I'm aware that we can probably
save some more cycles by defining INLINE_SYSCALL directly and avoiding
the err variable, but I'd like to leave this asside until the
cancelation handling is fixed.
With the attached patch glibc passess all the tests it passes without it
and is able to "replicate itself" (compile glibc with a glibc installed
that uses this patch).
I'm cc'ing the linux-mips list for comments.
 -- Guido

P.S.: many thanks to Thiemo and aj for their explanations.

--UFHRwCdBEJvubb2X
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="inline-syscall-mips.diff"

2003-01-14  Guido Guenther  <agx@sigxcpu.org>

	* sysdeps/unix/sysv/linux/mips/sysdep.h
	(INTERNAL_SYSCALL, INTERNAL_SYSCALL_DECL, 
	INTERNAL_SYSCALL_ERRNO, INTERNAL_SYSCALL_ERROR_P,
	INLINE_SYSCALL): Define.

Index: sysdeps/unix/sysv/linux/mips/sysdep.h
===================================================================
RCS file: /cvs/glibc/libc/sysdeps/unix/sysv/linux/mips/sysdep.h,v
retrieving revision 1.2
diff -u -r1.2 sysdep.h
--- sysdeps/unix/sysv/linux/mips/sysdep.h	6 Jul 2001 04:56:18 -0000	1.2
+++ sysdeps/unix/sysv/linux/mips/sysdep.h	13 Jan 2003 20:35:27 -0000
@@ -33,4 +33,242 @@
 # define SYS_ify(syscall_name)	__NR_/**/syscall_name
 #endif
 
+#ifndef __ASSEMBLER__
+
+/* Define a macro which expands into the inline wrapper code for a system
+   call.  */
+#undef INLINE_SYSCALL
+#define INLINE_SYSCALL(name, nr, args...)                               \
+  ({ INTERNAL_SYSCALL_DECL(err);					\
+     long result_var = INTERNAL_SYSCALL (name, err, nr, args);      	\
+     if ( INTERNAL_SYSCALL_ERROR_P (result_var, err) )  		\
+       {                                                                \
+         __set_errno (INTERNAL_SYSCALL_ERRNO (result_var, err));      	\
+         result_var = -1L;                               		\
+       }                                                                \
+     result_var; })
+
+#undef INTERNAL_SYSCALL_DECL
+#define INTERNAL_SYSCALL_DECL(err) long err
+
+#undef INTERNAL_SYSCALL_ERROR_P
+#define INTERNAL_SYSCALL_ERROR_P(val, err)   ((long) (err))
+
+#undef INTERNAL_SYSCALL_ERRNO
+#define INTERNAL_SYSCALL_ERRNO(val, err)     (val)
+
+#undef INTERNAL_SYSCALL
+#define INTERNAL_SYSCALL(name, err, nr, args...) internal_syscall##nr(name, err, args)
+
+#define internal_syscall0(name, err, dummy...) 				\
+({ 									\
+	long _sys_result;						\
+									\
+	{								\
+	register long __v0 asm("$2"); 					\
+	register long __a3 asm("$7"); 					\
+	__asm__ volatile ( 						\
+	".set\tnoreorder\n\t" 						\
+	"li\t$2, %2\t\t\t# " #name "\n\t"				\
+	"syscall\n\t" 							\
+	".set reorder" 							\
+	: "=r" (__v0), "=r" (__a3) 					\
+	: "i" (SYS_ify(name))						\
+	: __SYSCALL_CLOBBERS); 						\
+	err = __a3;							\
+	_sys_result = __v0;						\
+	}								\
+	_sys_result;							\
+})
+
+#define internal_syscall1(name, err, arg1) 				\
+({ 									\
+	long _sys_result;						\
+									\
+	{								\
+	register long __v0 asm("$2"); 					\
+	register long __a0 asm("$4") = (long) arg1; 			\
+	register long __a3 asm("$7"); 					\
+	__asm__ volatile ( 						\
+	".set\tnoreorder\n\t" 						\
+	"li\t$2, %3\t\t\t# " #name "\n\t"				\
+	"syscall\n\t" 							\
+	".set reorder" 							\
+	: "=r" (__v0), "=r" (__a3) 					\
+	: "r" (__a0), "i" (SYS_ify(name)) 				\
+	: __SYSCALL_CLOBBERS); 						\
+	err = __a3;							\
+	_sys_result = __v0;						\
+	}								\
+	_sys_result;							\
+})
+
+#define internal_syscall2(name, err, arg1, arg2) 			\
+({ 									\
+	long _sys_result;						\
+									\
+	{								\
+	register long __v0 asm("$2"); 					\
+	register long __a0 asm("$4") = (long) arg1; 			\
+	register long __a1 asm("$5") = (long) arg2; 			\
+	register long __a3 asm("$7"); 					\
+	__asm__ volatile ( 						\
+	".set\tnoreorder\n\t" 						\
+	"li\t$2, %4\t\t\t# " #name "\n\t" 				\
+	"syscall\n\t" 							\
+	".set\treorder" 						\
+	: "=r" (__v0), "=r" (__a3) 					\
+	: "r" (__a0), "r" (__a1), "i" (SYS_ify(name))			\
+	: __SYSCALL_CLOBBERS); 						\
+	err = __a3;							\
+	_sys_result = __v0;						\
+	}								\
+	_sys_result;							\
+})
+
+#define internal_syscall3(name, err, arg1, arg2, arg3) 			\
+({ 									\
+	long _sys_result;						\
+									\
+	{								\
+	register long __v0 asm("$2"); 					\
+	register long __a0 asm("$4") = (long) arg1; 			\
+	register long __a1 asm("$5") = (long) arg2; 			\
+	register long __a2 asm("$6") = (long) arg3; 			\
+	register long __a3 asm("$7"); 					\
+	__asm__ volatile ( 						\
+	".set\tnoreorder\n\t" 						\
+	"li\t$2, %5\t\t\t# " #name "\n\t" 				\
+	"syscall\n\t" 							\
+	".set\treorder" 						\
+	: "=r" (__v0), "=r" (__a3) 					\
+	: "r" (__a0), "r" (__a1), "r" (__a2), "i" (SYS_ify(name)) 	\
+	: __SYSCALL_CLOBBERS); 						\
+	err = __a3;							\
+	_sys_result = __v0;						\
+	}								\
+	_sys_result;							\
+})
+
+#define internal_syscall4(name, err, arg1, arg2, arg3, arg4) 		\
+({ 									\
+	long _sys_result;						\
+									\
+	{								\
+	register long __v0 asm("$2"); 					\
+	register long __a0 asm("$4") = (long) arg1; 			\
+	register long __a1 asm("$5") = (long) arg2; 			\
+	register long __a2 asm("$6") = (long) arg3; 			\
+	register long __a3 asm("$7") = (long) arg4; 			\
+	__asm__ volatile ( 						\
+	".set\tnoreorder\n\t" 						\
+	"li\t$2, %5\t\t\t# " #name "\n\t" 				\
+	"syscall\n\t" 							\
+	".set\treorder" 						\
+	: "=r" (__v0), "+r" (__a3) 					\
+	: "r" (__a0), "r" (__a1), "r" (__a2), "i" (SYS_ify(name)) 	\
+	: __SYSCALL_CLOBBERS); 						\
+	err = __a3;							\
+	_sys_result = __v0;						\
+	}								\
+	_sys_result;							\
+})
+
+#define internal_syscall5(name, err, arg1, arg2, arg3, arg4, arg5) 	\
+({ 									\
+	long _sys_result;						\
+									\
+	{								\
+	register long __v0 asm("$2"); 					\
+	register long __a0 asm("$4") = (long) arg1; 			\
+	register long __a1 asm("$5") = (long) arg2; 			\
+	register long __a2 asm("$6") = (long) arg3; 			\
+	register long __a3 asm("$7") = (long) arg4; 			\
+	__asm__ volatile ( 						\
+	".set\tnoreorder\n\t" 						\
+	"lw\t$2, %6\n\t" 						\
+	"subu\t$29, 32\n\t" 						\
+	"sw\t$2, 16($29)\n\t" 						\
+	"li\t$2, %5\t\t\t# " #name "\n\t" 				\
+	"syscall\n\t" 							\
+	"addiu\t$29, 32\n\t" 						\
+	".set\treorder" 						\
+	: "=r" (__v0), "+r" (__a3) 					\
+	: "r" (__a0), "r" (__a1), "r" (__a2), "i" (SYS_ify(name)), 	\
+	  "m" ((long)arg5) 						\
+	: __SYSCALL_CLOBBERS); 						\
+	err = __a3;							\
+	_sys_result = __v0;						\
+	}								\
+	_sys_result;							\
+})
+
+#define internal_syscall6(name, err, arg1, arg2, arg3, arg4, arg5, arg6)\
+({ 									\
+	long _sys_result;						\
+									\
+	{								\
+	register long __v0 asm("$2"); 					\
+	register long __a0 asm("$4") = (long) arg1; 			\
+	register long __a1 asm("$5") = (long) arg2; 			\
+	register long __a2 asm("$6") = (long) arg3; 			\
+	register long __a3 asm("$7") = (long) arg4; 			\
+	__asm__ volatile ( 						\
+	".set\tnoreorder\n\t" 						\
+	"lw\t$2, %6\n\t" 						\
+	"lw\t$8, %7\n\t" 						\
+	"subu\t$29, 32\n\t" 						\
+	"sw\t$2, 16($29)\n\t" 						\
+	"sw\t$8, 20($29)\n\t" 						\
+	"li\t$2, %5\t\t\t# " #name "\n\t" 				\
+	"syscall\n\t" 							\
+	"addiu\t$29, 32\n\t" 						\
+	".set\treorder" 						\
+	: "=r" (__v0), "+r" (__a3) 					\
+	: "r" (__a0), "r" (__a1), "r" (__a2), "i" (SYS_ify(name)), 	\
+	  "m" ((long)arg5), "m" ((long)arg6)				\
+	: __SYSCALL_CLOBBERS); 						\
+	err = __a3;							\
+	_sys_result = __v0;						\
+	}								\
+	_sys_result;							\
+})
+
+#define internal_syscall7(name, err, arg1, arg2, arg3, arg4, arg5, arg6, arg7)\
+({ 									\
+	long _sys_result;						\
+									\
+	{								\
+	register long __v0 asm("$2"); 					\
+	register long __a0 asm("$4") = (long) arg1; 			\
+	register long __a1 asm("$5") = (long) arg2; 			\
+	register long __a2 asm("$6") = (long) arg3; 			\
+	register long __a3 asm("$7") = (long) arg4; 			\
+	__asm__ volatile ( 						\
+	".set\tnoreorder\n\t" 						\
+	"lw\t$2, %6\n\t" 						\
+	"lw\t$8, %7\n\t" 						\
+	"lw\t$9, %8\n\t" 						\
+	"subu\t$29, 32\n\t" 						\
+	"sw\t$2, 16($29)\n\t" 						\
+	"sw\t$8, 20($29)\n\t" 						\
+	"sw\t$9, 24($29)\n\t" 						\
+	"li\t$2, %5\t\t\t# " #name "\n\t" 				\
+	"syscall\n\t" 							\
+	"addiu\t$29, 32\n\t" 						\
+	".set\treorder" 						\
+	: "=r" (__v0), "+r" (__a3) 					\
+	: "r" (__a0), "r" (__a1), "r" (__a2), "i" (SYS_ify(name)), 	\
+	  "m" ((long)arg5), "m" ((long)arg6), "m" ((long)arg7)		\
+	: __SYSCALL_CLOBBERS); 						\
+	err = __a3;							\
+	_sys_result = __v0;						\
+	}								\
+	_sys_result;							\
+})
+
+#define __SYSCALL_CLOBBERS "$1", "$3", "$8", "$9", "$10", "$11", "$12", "$13", "$14", "$15", "$24", "$25"
+
+#endif /* __ASSEMBLER__ */
+
 #endif /* linux/mips/sysdep.h */

--UFHRwCdBEJvubb2X--

From kaos@ocs.com.au Tue Jan 14 23:34:44 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 14 Jan 2003 23:34:44 +0000 (GMT)
Received: from rj.sgi.com ([IPv6:::ffff:192.82.208.96]:58815 "EHLO rj.sgi.com")
	by linux-mips.org with ESMTP id <S8225198AbTANXeo>;
	Tue, 14 Jan 2003 23:34:44 +0000
Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130])
	by rj.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with SMTP id h0ELYnG8008633;
	Tue, 14 Jan 2003 13:34:49 -0800
Received: from kao2.melbourne.sgi.com (kao2.melbourne.sgi.com [134.14.55.180]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA14792; Wed, 15 Jan 2003 10:34:39 +1100
Received: by kao2.melbourne.sgi.com (Postfix, from userid 16331)
	id 71CA83000B8; Wed, 15 Jan 2003 10:34:38 +1100 (EST)
Received: from kao2.melbourne.sgi.com (localhost [127.0.0.1])
	by kao2.melbourne.sgi.com (Postfix) with ESMTP
	id 60D7585; Wed, 15 Jan 2003 10:34:38 +1100 (EST)
X-Mailer: exmh version 2.4 06/23/2000 with nmh-1.0.4
From: Keith Owens <kaos@ocs.com.au>
To: "Gilad Benjamini" <gilad@riverhead.com>
Cc: linux-mips@linux-mips.org
Subject: Re: insmod failure: "Unhandled relocation" errors 
In-reply-to: Your message of "Tue, 14 Jan 2003 12:06:46 +0200."
             <001801c2bbb4$a6177de0$7100000a@riverhead.com> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Wed, 15 Jan 2003 10:34:33 +1100
Message-ID: <9030.1042587273@kao2.melbourne.sgi.com>
Return-Path: <kaos@ocs.com.au>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1154
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: kaos@ocs.com.au
Precedence: bulk
X-list: linux-mips

On Tue, 14 Jan 2003 12:06:46 +0200, 
"Gilad Benjamini" <gilad@riverhead.com> wrote:
>I've built,compiled and ran successfully a 64 bit kernel on my 
>mips64 platform. Kernel was compiled with support for 32 bit binaries.
>
>I am now trying to insert a module, a standard module from
>the kernel tree, and get lots of errors such as:
>"Unhandled relocation of type 18 for"

Type 18 is R_MIPS_64.  modutils does not support 64 bit mips
at all, nobody has sent me any code to handle this architecture.

modutils needs obj/obj_mips64.c.  The config and makefiles have to be
tweaked to handle mips64, including combined 32/64 bit code, as for
sparc32/sparc64.  Does anybody who knows mips64 feel like contributing
the modutils code?


From drepper@redhat.com Wed Jan 15 01:02:47 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 15 Jan 2003 01:02:48 +0000 (GMT)
Received: from cpe-24-221-190-179.ca.sprintbbd.net ([IPv6:::ffff:24.221.190.179]:45762
	"EHLO myware.akkadia.org") by linux-mips.org with ESMTP
	id <S8225198AbTAOBCr>; Wed, 15 Jan 2003 01:02:47 +0000
Received: from redhat.com (myware.akkadia.org [192.168.7.70])
	(authenticated bits=0)
	by myware.akkadia.org (8.12.5/8.12.5) with ESMTP id h0F131YA009042;
	Tue, 14 Jan 2003 17:03:02 -0800
Message-ID: <3E24B345.3000408@redhat.com>
Date: Tue, 14 Jan 2003 17:03:01 -0800
From: Ulrich Drepper <drepper@redhat.com>
Organization: Red Hat, Inc.
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3b) Gecko/20030111
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Guido Guenther <agx@sigxcpu.org>
CC: libc-alpha@sources.redhat.com, linux-mips@linux-mips.org
Subject: Re: [PATCH] INTERNAL_SYSCALL for linux-mips
References: <20030114230607.GH27645@bogon.ms20.nix>
In-Reply-To: <20030114230607.GH27645@bogon.ms20.nix>
X-Enigmail-Version: 0.72.0.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Return-Path: <drepper@redhat.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1155
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: drepper@redhat.com
Precedence: bulk
X-list: linux-mips

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Guido Guenther wrote:
> the attached patch brings mips up to date concerning the
> {INTERNAL,INLINE}_SYSCALL macros.

I've applied the patch.  Thanks,

- -- 
- --------------.                        ,-.            444 Castro Street
Ulrich Drepper \    ,-----------------'   \ Mountain View, CA 94041 USA
Red Hat         `--' drepper at redhat.com `---------------------------
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQE+JLNF2ijCOnn/RHQRAnPxAKCTNJyDBtLmvZtP7Eq5Zf4d9F2GaQCglf3+
EX9+rGlNZUpvkcIR7aBl14U=
=OVjY
-----END PGP SIGNATURE-----


From ralf@linux-mips.org Wed Jan 15 12:15:51 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 15 Jan 2003 12:15:51 +0000 (GMT)
Received: from p508B634D.dip.t-dialin.net ([IPv6:::ffff:80.139.99.77]:2713
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225198AbTAOMPv>; Wed, 15 Jan 2003 12:15:51 +0000
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.11.6/8.11.6) id h0FCFoG27569
	for linux-mips@linux-mips.org; Wed, 15 Jan 2003 13:15:50 +0100
Date: Wed, 15 Jan 2003 13:15:50 +0100
From: Ralf Baechle <ralf@linux-mips.org>
To: linux-mips@linux-mips.org
Subject: Re: insmod failure: "Unhandled relocation" errors
Message-ID: <20030115131550.A27412@linux-mips.org>
References: <001801c2bbb4$a6177de0$7100000a@riverhead.com> <20030114191417.GA1243@wumpus.internal.keyresearch.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5.1i
In-Reply-To: <20030114191417.GA1243@wumpus.internal.keyresearch.com>; from lindahl@keyresearch.com on Tue, Jan 14, 2003 at 11:14:18AM -0800
Return-Path: <ralf@linux-mips.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1156
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips

On Tue, Jan 14, 2003 at 11:14:18AM -0800, Greg Lindahl wrote:

> > I am now trying to insert a module, a standard module from
> > the kernel tree, and get lots of errors such as:
> > "Unhandled relocation of type 18 for"
> > or
> > "Unhandled relocation of type 18 for <function_name>"
> 
> I'm impressed that it got this far -- let me guess, big endian?
> Little endian didn't even get that far last time I tried it.

The modules we also built with the wrong options which is the cause for
these specific error messages.  There was just no point mentioning these
because the actual showstopper was a 32-bit vs. 64-bit problem.

  Ralf

From ralf@linux-mips.org Wed Jan 15 12:24:58 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 15 Jan 2003 12:24:59 +0000 (GMT)
Received: from p508B634D.dip.t-dialin.net ([IPv6:::ffff:80.139.99.77]:10649
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225198AbTAOMY6>; Wed, 15 Jan 2003 12:24:58 +0000
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.11.6/8.11.6) id h0FCOlD27772;
	Wed, 15 Jan 2003 13:24:47 +0100
Date: Wed, 15 Jan 2003 13:24:47 +0100
From: Ralf Baechle <ralf@linux-mips.org>
To: Keith Owens <kaos@ocs.com.au>
Cc: Gilad Benjamini <gilad@riverhead.com>, linux-mips@linux-mips.org
Subject: Re: insmod failure: "Unhandled relocation" errors
Message-ID: <20030115132447.B27412@linux-mips.org>
References: <001801c2bbb4$a6177de0$7100000a@riverhead.com> <9030.1042587273@kao2.melbourne.sgi.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5.1i
In-Reply-To: <9030.1042587273@kao2.melbourne.sgi.com>; from kaos@ocs.com.au on Wed, Jan 15, 2003 at 10:34:33AM +1100
Return-Path: <ralf@linux-mips.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1157
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips

On Wed, Jan 15, 2003 at 10:34:33AM +1100, Keith Owens wrote:

> modutils needs obj/obj_mips64.c.  The config and makefiles have to be
> tweaked to handle mips64, including combined 32/64 bit code, as for
> sparc32/sparc64.  Does anybody who knows mips64 feel like contributing
> the modutils code?

Until recently the big problem with implementing modules support for mips64
was the complete unusability of binutils.  Compared to the complexity of
getting binutils to work what it takes to get modutils to work is plain
trivial ...

  Ralf

From jpauley@xwizards.com Wed Jan 15 12:45:24 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 15 Jan 2003 12:45:25 +0000 (GMT)
Received: from smtp02.infoave.net ([IPv6:::ffff:165.166.0.27]:46817 "EHLO
	smtp02.infoave.net") by linux-mips.org with ESMTP
	id <S8225198AbTAOMpY>; Wed, 15 Jan 2003 12:45:24 +0000
Received: from opus ([204.116.3.125])
 by SMTP00.InfoAve.Net (PMDF V6.1-1IA5 #38777)
 with ESMTP id <01KR98LSKQFW91A929@SMTP00.InfoAve.Net> for
 linux-mips@linux-mips.org; Wed, 15 Jan 2003 07:44:57 -0500 (EST)
Date: Wed, 15 Jan 2003 07:46:05 -0500
From: Justin Pauley <jpauley@xwizards.com>
Subject: MOPD
To: linux-mips@linux-mips.org
Message-id: <1042634769.3331.89.camel@Opus>
MIME-version: 1.0
X-Mailer: Ximian Evolution 1.0.8 (1.0.8-10)
Content-type: text/plain
Content-transfer-encoding: 7bit
Return-Path: <jpauley@xwizards.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1158
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: jpauley@xwizards.com
Precedence: bulk
X-list: linux-mips

Does anyone know where I can find out more information (than what is in
the man page) for MOPD. I would like to know how it works,etc. So I can
find out what I am doing wrong. Once again, if someone would like to
sell a Decstation with Linux installed please let me know.

Thanks a lot!
Justin




From ralf@linux-mips.org Wed Jan 15 12:58:04 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 15 Jan 2003 12:58:04 +0000 (GMT)
Received: from p508B634D.dip.t-dialin.net ([IPv6:::ffff:80.139.99.77]:40601
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225198AbTAOM6E>; Wed, 15 Jan 2003 12:58:04 +0000
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.11.6/8.11.6) id h0FCm8728283;
	Wed, 15 Jan 2003 13:48:08 +0100
Date: Wed, 15 Jan 2003 13:48:08 +0100
From: Ralf Baechle <ralf@linux-mips.org>
To: Guido Guenther <agx@sigxcpu.org>
Cc: libc-alpha@sources.redhat.com, linux-mips@linux-mips.org
Subject: Re: [PATCH] INTERNAL_SYSCALL for linux-mips
Message-ID: <20030115134808.C27412@linux-mips.org>
References: <20030114230607.GH27645@bogon.ms20.nix>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5.1i
In-Reply-To: <20030114230607.GH27645@bogon.ms20.nix>; from agx@sigxcpu.org on Wed, Jan 15, 2003 at 12:06:08AM +0100
Return-Path: <ralf@linux-mips.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1159
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips

On Wed, Jan 15, 2003 at 12:06:08AM +0100, Guido Guenther wrote:

> +	register long __v0 asm("$2"); 					\
> +	register long __a3 asm("$7"); 					\

The patch looks fine to me but as a word of warning - I'm using the same
code construct is also being used in the kernel but I've found it very
fragile wrt. misscompilation by gcc over the years ...

  Ralf

From hself@dcint.net Wed Jan 15 14:08:59 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 15 Jan 2003 14:09:00 +0000 (GMT)
Received: from [IPv6:::ffff:207.191.101.35] ([IPv6:::ffff:207.191.101.35]:16377
	"EHLO public.dcint.net") by linux-mips.org with ESMTP
	id <S8225198AbTAOOI7>; Wed, 15 Jan 2003 14:08:59 +0000
Received: from hoyt ([10.10.10.99])
	by public.dcint.net (8.9.3/8.9.3) with SMTP id IAA13143
	for <linux-mips@linux-mips.org>; Wed, 15 Jan 2003 08:08:54 -0600
Message-ID: <002201c2bc9f$a3b62380$630a0a0a@dcint.net>
From: "Hoyt Self" <hself@dcint.net>
To: <linux-mips@linux-mips.org>
Subject: 
Date: Wed, 15 Jan 2003 08:08:55 -0600
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_001F_01C2BC6D.590656C0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Return-Path: <hself@dcint.net>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1160
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: hself@dcint.net
Precedence: bulk
X-list: linux-mips

This is a multi-part message in MIME format.

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

unsubscribe linux-mips
------=_NextPart_000_001F_01C2BC6D.590656C0
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 http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2800.1126" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>unsubscribe =
linux-mips</FONT></DIV></BODY></HTML>

------=_NextPart_000_001F_01C2BC6D.590656C0--


From jbglaw@dvmwest.gt.owl.de Wed Jan 15 14:29:12 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 15 Jan 2003 14:29:13 +0000 (GMT)
Received: from dvmwest.gt.owl.de ([IPv6:::ffff:62.52.24.140]:64773 "EHLO
	dvmwest.gt.owl.de") by linux-mips.org with ESMTP
	id <S8225198AbTAOO3M>; Wed, 15 Jan 2003 14:29:12 +0000
Received: by dvmwest.gt.owl.de (Postfix, from userid 1001)
	id 083E74A8E9; Wed, 15 Jan 2003 15:29:09 +0100 (CET)
Date: Wed, 15 Jan 2003 15:29:09 +0100
From: Jan-Benedict Glaw <jbglaw@lug-owl.de>
To: linux-mips@linux-mips.org
Subject: Re: MOPD
Message-ID: <20030115142909.GY27441@lug-owl.de>
Mail-Followup-To: linux-mips@linux-mips.org
References: <1042634769.3331.89.camel@Opus>
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="7kD9y3RnPUgTZee0"
Content-Disposition: inline
In-Reply-To: <1042634769.3331.89.camel@Opus>
User-Agent: Mutt/1.4i
X-Operating-System: Linux mail 2.4.18 
x-gpg-fingerprint: 250D 3BCF 7127 0D8C A444  A961 1DBD 5E75 8399 E1BB
x-gpg-key: wwwkeys.de.pgp.net
Return-Path: <jbglaw@dvmwest.gt.owl.de>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1161
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: jbglaw@lug-owl.de
Precedence: bulk
X-list: linux-mips


--7kD9y3RnPUgTZee0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Wed, 2003-01-15 07:46:05 -0500, Justin Pauley <jpauley@xwizards.com>
wrote in message <1042634769.3331.89.camel@Opus>:
> Does anyone know where I can find out more information (than what is in
> the man page) for MOPD. I would like to know how it works,etc. So I can
> find out what I am doing wrong. Once again, if someone would like to
> sell a Decstation with Linux installed please let me know.

I've bootet a DS with mopd, but the mopd that comes with debian is
unuseable for that. Look for Maciej's mopd, which has ELF support. It
will correctly read an ELF linux kernel image.

MfG, JBG

--=20
   Jan-Benedict Glaw       jbglaw@lug-owl.de    . +49-172-7608481
   "Eine Freie Meinung in  einem Freien Kopf    | Gegen Zensur
    fuer einen Freien Staat voll Freier B=FCrger" | im Internet!
   Shell Script APT-Proxy: http://lug-owl.de/~jbglaw/software/ap2/

--7kD9y3RnPUgTZee0
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQE+JXA1Hb1edYOZ4bsRAhI5AKCFS9W0kqJjRAdxsAcldOks96L5jwCfcaev
C35oRz18AADPHku4Y2Cef+o=
=Jwoy
-----END PGP SIGNATURE-----

--7kD9y3RnPUgTZee0--

From jpauley@xwizards.com Wed Jan 15 23:40:45 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 15 Jan 2003 23:40:46 +0000 (GMT)
Received: from smtp02.infoave.net ([IPv6:::ffff:165.166.0.27]:16092 "EHLO
	smtp02.infoave.net") by linux-mips.org with ESMTP
	id <S8225210AbTAOXkp>; Wed, 15 Jan 2003 23:40:45 +0000
Received: from opus ([204.116.3.125])
 by SMTP00.InfoAve.Net (PMDF V6.1-1IA5 #38777)
 with ESMTP id <01KR9VGY9P2S91AB87@SMTP00.InfoAve.Net> for
 linux-mips@linux-mips.org; Wed, 15 Jan 2003 18:40:01 -0500 (EST)
Date: Wed, 15 Jan 2003 18:41:16 -0500
From: Justin Pauley <jpauley@xwizards.com>
Subject: MOPD problems
To: linux-mips@linux-mips.org
Message-id: <1042674081.2735.102.camel@Opus>
MIME-version: 1.0
X-Mailer: Ximian Evolution 1.0.8 (1.0.8-10)
Content-type: text/plain
Content-transfer-encoding: 7bit
Return-Path: <jpauley@xwizards.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1162
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: jpauley@xwizards.com
Precedence: bulk
X-list: linux-mips

I downloaded the mopd server and installed a bunch of the patches until
mopd compiled. I downloaded the mopimage and put it in my /tftpboot/mop
with the correct name. However, after running mop with "mopd -d eth0"
and then running "boot 3/mop" on my decstation nothing happens. However,
I have noticed that when I run a packet dumping software (etherreal) and
then I try it I get this on my mopd:

MOP DL 8:0:2b:2e:77:40   > ab:0:0:1:0:0      len   11 code 08 RPR
MOP DL 0:d0:9:f8:fc:a5   > 8:0:2b:2e:77:40   len    1 code 03 ASV
MOP DL 8:0:2b:2e:77:40   > 0:d0:9:f8:fc:a5   len   11 code 08 RPR
MOP DL 0:d0:9:f8:fc:a5   > 8:0:2b:2e:77:40   len 1058 code 02 MLD

This in my syslog:
Jan 15 18:30:47 opus mopd[18215]: 8:0:2b:2e:77:40 (1) Do you have
08002b2e7740? (Yes)
Jan 15 18:30:47 opus mopd[18215]: 8:0:2b:2e:77:40 Send me 08002b2e7740

but then my Decstation produces something similar to the following:

>> boot 3/mop

???
? PC: 0x.....
? CR: 0x....
? SR: 0x....
? VA: 0x0
? ER: 180....
? MER: 0x162....

and then returns back to the console ">>".
(note that the ... were added by me to replace a long line of
numbers/letters)


if you know of something I can try, please let me know.

Thanks,
Justin Pauley


From airlied@csn.ul.ie Thu Jan 16 01:05:11 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 16 Jan 2003 01:05:12 +0000 (GMT)
Received: from holly.csn.ul.ie ([IPv6:::ffff:136.201.105.4]:41909 "EHLO
	holly.csn.ul.ie") by linux-mips.org with ESMTP id <S8225210AbTAPBFL>;
	Thu, 16 Jan 2003 01:05:11 +0000
Received: from skynet.csn.ul.ie (skynet [136.201.105.2])
	by holly.csn.ul.ie (Postfix) with ESMTP
	id 21F853F4BC; Thu, 16 Jan 2003 01:06:57 +0000 (GMT)
Received: by skynet.csn.ul.ie (Postfix, from userid 2139)
	id 628BDE952; Thu, 16 Jan 2003 01:04:58 +0000 (GMT)
Received: from localhost (localhost [127.0.0.1])
	by skynet.csn.ul.ie (Postfix) with ESMTP
	id 50307777F; Thu, 16 Jan 2003 01:04:58 +0000 (GMT)
Date: Thu, 16 Jan 2003 01:04:58 +0000 (GMT)
From: Dave Airlie <airlied@csn.ul.ie>
X-X-Sender: airlied@skynet
To: Justin Pauley <jpauley@xwizards.com>
Cc: linux-mips@linux-mips.org
Subject: Re: MOPD problems
In-Reply-To: <1042674081.2735.102.camel@Opus>
Message-ID: <Pine.LNX.4.44.0301160103580.10229-100000@skynet>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <airlied@csn.ul.ie>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1163
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: airlied@csn.ul.ie
Precedence: bulk
X-list: linux-mips


sometimes a long time agao.. you needed to manually add the ethernet
address of the decstation to the arp table on the host machine..

arp -s <decstation_hostname> <ethernet_address>

give that a go...

Dave.

On Wed, 15 Jan 2003, Justin Pauley wrote:

> I downloaded the mopd server and installed a bunch of the patches until
> mopd compiled. I downloaded the mopimage and put it in my /tftpboot/mop
> with the correct name. However, after running mop with "mopd -d eth0"
> and then running "boot 3/mop" on my decstation nothing happens. However,
> I have noticed that when I run a packet dumping software (etherreal) and
> then I try it I get this on my mopd:
>
> MOP DL 8:0:2b:2e:77:40   > ab:0:0:1:0:0      len   11 code 08 RPR
> MOP DL 0:d0:9:f8:fc:a5   > 8:0:2b:2e:77:40   len    1 code 03 ASV
> MOP DL 8:0:2b:2e:77:40   > 0:d0:9:f8:fc:a5   len   11 code 08 RPR
> MOP DL 0:d0:9:f8:fc:a5   > 8:0:2b:2e:77:40   len 1058 code 02 MLD
>
> This in my syslog:
> Jan 15 18:30:47 opus mopd[18215]: 8:0:2b:2e:77:40 (1) Do you have
> 08002b2e7740? (Yes)
> Jan 15 18:30:47 opus mopd[18215]: 8:0:2b:2e:77:40 Send me 08002b2e7740
>
> but then my Decstation produces something similar to the following:
>
> >> boot 3/mop
>
> ???
> ? PC: 0x.....
> ? CR: 0x....
> ? SR: 0x....
> ? VA: 0x0
> ? ER: 180....
> ? MER: 0x162....
>
> and then returns back to the console ">>".
> (note that the ... were added by me to replace a long line of
> numbers/letters)
>
>
> if you know of something I can try, please let me know.
>
> Thanks,
> Justin Pauley
>
>

-- 
David Airlie, Software Engineer
http://www.skynet.ie/~airlied / airlied@skynet.ie
pam_smb / Linux DecStation / Linux VAX / ILUG person



From jpauley@xwizards.com Thu Jan 16 01:48:48 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 16 Jan 2003 01:48:49 +0000 (GMT)
Received: from smtp03.infoave.net ([IPv6:::ffff:165.166.0.28]:5587 "EHLO
	smtp03.infoave.net") by linux-mips.org with ESMTP
	id <S8225210AbTAPBss>; Thu, 16 Jan 2003 01:48:48 +0000
Received: from opus ([204.116.3.125])
 by SMTP00.InfoAve.Net (PMDF V6.1-1IA5 #38776)
 with ESMTP id <01KR9ZYJX2X294QV0I@SMTP00.InfoAve.Net> for
 linux-mips@linux-mips.org; Wed, 15 Jan 2003 20:48:40 -0500 (EST)
Date: Wed, 15 Jan 2003 20:50:01 -0500
From: Justin Pauley <jpauley@xwizards.com>
Subject: Re: MOPD problems
In-reply-to: <Pine.LNX.4.44.0301160103580.10229-100000@skynet>
To: Dave Airlie <airlied@csn.ul.ie>
Cc: linux-mips@linux-mips.org
Message-id: <1042681801.2735.108.camel@Opus>
MIME-version: 1.0
X-Mailer: Ximian Evolution 1.0.8 (1.0.8-10)
Content-type: text/plain
Content-transfer-encoding: 7bit
References: <Pine.LNX.4.44.0301160103580.10229-100000@skynet>
Return-Path: <jpauley@xwizards.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1164
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: jpauley@xwizards.com
Precedence: bulk
X-list: linux-mips

Sorry, but it didn't seem to work. For the decstation hostname I just
used "decstation" and added an entry into my /etc/hosts for the the IP
address I think it is. However, I am not sure exactly what ip address it
is nor do I know how to figure it out.

I figured out by turning on promiscuous mode I get the connection to my
box but the decstation still does the "???" thing as I mentioned before.
Any ideas are appreciated, and thank you Dave.

Justin

On Wed, 2003-01-15 at 20:04, Dave Airlie wrote:
> 
> sometimes a long time agao.. you needed to manually add the ethernet
> address of the decstation to the arp table on the host machine..
> 
> arp -s <decstation_hostname> <ethernet_address>
> 
> give that a go...
> 
> Dave.
> 
> On Wed, 15 Jan 2003, Justin Pauley wrote:
> 
> > I downloaded the mopd server and installed a bunch of the patches until
> > mopd compiled. I downloaded the mopimage and put it in my /tftpboot/mop
> > with the correct name. However, after running mop with "mopd -d eth0"
> > and then running "boot 3/mop" on my decstation nothing happens. However,
> > I have noticed that when I run a packet dumping software (etherreal) and
> > then I try it I get this on my mopd:
> >
> > MOP DL 8:0:2b:2e:77:40   > ab:0:0:1:0:0      len   11 code 08 RPR
> > MOP DL 0:d0:9:f8:fc:a5   > 8:0:2b:2e:77:40   len    1 code 03 ASV
> > MOP DL 8:0:2b:2e:77:40   > 0:d0:9:f8:fc:a5   len   11 code 08 RPR
> > MOP DL 0:d0:9:f8:fc:a5   > 8:0:2b:2e:77:40   len 1058 code 02 MLD
> >
> > This in my syslog:
> > Jan 15 18:30:47 opus mopd[18215]: 8:0:2b:2e:77:40 (1) Do you have
> > 08002b2e7740? (Yes)
> > Jan 15 18:30:47 opus mopd[18215]: 8:0:2b:2e:77:40 Send me 08002b2e7740
> >
> > but then my Decstation produces something similar to the following:
> >
> > >> boot 3/mop
> >
> > ???
> > ? PC: 0x.....
> > ? CR: 0x....
> > ? SR: 0x....
> > ? VA: 0x0
> > ? ER: 180....
> > ? MER: 0x162....
> >
> > and then returns back to the console ">>".
> > (note that the ... were added by me to replace a long line of
> > numbers/letters)
> >
> >
> > if you know of something I can try, please let me know.
> >
> > Thanks,
> > Justin Pauley
> >
> >
> 
> -- 
> David Airlie, Software Engineer
> http://www.skynet.ie/~airlied / airlied@skynet.ie
> pam_smb / Linux DecStation / Linux VAX / ILUG person
> 
> 



From airlied@csn.ul.ie Thu Jan 16 06:20:20 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 16 Jan 2003 06:20:21 +0000 (GMT)
Received: from holly.csn.ul.ie ([IPv6:::ffff:136.201.105.4]:16061 "EHLO
	holly.csn.ul.ie") by linux-mips.org with ESMTP id <S8225210AbTAPGUU>;
	Thu, 16 Jan 2003 06:20:20 +0000
Received: from skynet.csn.ul.ie (skynet [136.201.105.2])
	by holly.csn.ul.ie (Postfix) with ESMTP
	id AD8733F4B8; Thu, 16 Jan 2003 06:22:04 +0000 (GMT)
Received: by skynet.csn.ul.ie (Postfix, from userid 2139)
	id E4F51E952; Thu, 16 Jan 2003 06:20:13 +0000 (GMT)
Received: from localhost (localhost [127.0.0.1])
	by skynet.csn.ul.ie (Postfix) with ESMTP
	id E39517780; Thu, 16 Jan 2003 06:20:13 +0000 (GMT)
Date: Thu, 16 Jan 2003 06:20:13 +0000 (GMT)
From: Dave Airlie <airlied@csn.ul.ie>
X-X-Sender: airlied@skynet
To: Justin Pauley <jpauley@xwizards.com>
Cc: linux-mips@linux-mips.org
Subject: Re: MOPD problems
In-Reply-To: <1042681801.2735.108.camel@Opus>
Message-ID: <Pine.LNX.4.44.0301160619200.19198-100000@skynet>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <airlied@csn.ul.ie>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1165
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: airlied@csn.ul.ie
Precedence: bulk
X-list: linux-mips


Ah sorry I was thinking I think of another problem.. that you get later on
in the boot .. it shouldn't affect the mop load... you are using Maciej's
mopd? it is the only one known to work ..

Dave.

On Wed, 15 Jan 2003, Justin Pauley wrote:

> Sorry, but it didn't seem to work. For the decstation hostname I just
> used "decstation" and added an entry into my /etc/hosts for the the IP
> address I think it is. However, I am not sure exactly what ip address it
> is nor do I know how to figure it out.
>
> I figured out by turning on promiscuous mode I get the connection to my
> box but the decstation still does the "???" thing as I mentioned before.
> Any ideas are appreciated, and thank you Dave.
>
> Justin
>
> On Wed, 2003-01-15 at 20:04, Dave Airlie wrote:
> >
> > sometimes a long time agao.. you needed to manually add the ethernet
> > address of the decstation to the arp table on the host machine..
> >
> > arp -s <decstation_hostname> <ethernet_address>
> >
> > give that a go...
> >
> > Dave.
> >
> > On Wed, 15 Jan 2003, Justin Pauley wrote:
> >
> > > I downloaded the mopd server and installed a bunch of the patches until
> > > mopd compiled. I downloaded the mopimage and put it in my /tftpboot/mop
> > > with the correct name. However, after running mop with "mopd -d eth0"
> > > and then running "boot 3/mop" on my decstation nothing happens. However,
> > > I have noticed that when I run a packet dumping software (etherreal) and
> > > then I try it I get this on my mopd:
> > >
> > > MOP DL 8:0:2b:2e:77:40   > ab:0:0:1:0:0      len   11 code 08 RPR
> > > MOP DL 0:d0:9:f8:fc:a5   > 8:0:2b:2e:77:40   len    1 code 03 ASV
> > > MOP DL 8:0:2b:2e:77:40   > 0:d0:9:f8:fc:a5   len   11 code 08 RPR
> > > MOP DL 0:d0:9:f8:fc:a5   > 8:0:2b:2e:77:40   len 1058 code 02 MLD
> > >
> > > This in my syslog:
> > > Jan 15 18:30:47 opus mopd[18215]: 8:0:2b:2e:77:40 (1) Do you have
> > > 08002b2e7740? (Yes)
> > > Jan 15 18:30:47 opus mopd[18215]: 8:0:2b:2e:77:40 Send me 08002b2e7740
> > >
> > > but then my Decstation produces something similar to the following:
> > >
> > > >> boot 3/mop
> > >
> > > ???
> > > ? PC: 0x.....
> > > ? CR: 0x....
> > > ? SR: 0x....
> > > ? VA: 0x0
> > > ? ER: 180....
> > > ? MER: 0x162....
> > >
> > > and then returns back to the console ">>".
> > > (note that the ... were added by me to replace a long line of
> > > numbers/letters)
> > >
> > >
> > > if you know of something I can try, please let me know.
> > >
> > > Thanks,
> > > Justin Pauley
> > >
> > >
> >
> > --
> > David Airlie, Software Engineer
> > http://www.skynet.ie/~airlied / airlied@skynet.ie
> > pam_smb / Linux DecStation / Linux VAX / ILUG person
> >
> >
>
>
>

-- 
David Airlie, Software Engineer
http://www.skynet.ie/~airlied / airlied@skynet.ie
pam_smb / Linux DecStation / Linux VAX / ILUG person



From chetanb@ishoni.com Thu Jan 16 06:28:15 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 16 Jan 2003 06:28:15 +0000 (GMT)
Received: from rakshak.ishoni.co.in ([IPv6:::ffff:164.164.83.140]:40766 "EHLO
	arianne.in.ishoni.com") by linux-mips.org with ESMTP
	id <S8225210AbTAPG2P>; Thu, 16 Jan 2003 06:28:15 +0000
Received: from leonoid.in.ishoni.com (leonoid.in.ishoni.com [192.168.1.12])
	by arianne.in.ishoni.com (8.11.6/Ishonir2) with ESMTP id h0G6WpG32018
	for <linux-mips@linux-mips.org>; Thu, 16 Jan 2003 12:02:51 +0530
Received: by leonoid.in.ishoni.com with Internet Mail Service (5.5.2653.19)
	id <ZX2KGYVM>; Thu, 16 Jan 2003 12:01:53 +0530
Message-ID: <7CFD7CA8510CD6118F950002A519EA3003FB04E6@leonoid.in.ishoni.com>
From: Chetan B L <chetanb@ishoni.com>
To: "'linux-mips@linux-mips.org'" <linux-mips@linux-mips.org>
Subject: Performance measuring in MIPS R3000
Date: Thu, 16 Jan 2003 12:01:52 +0530
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Return-Path: <chetanb@ishoni.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1166
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: chetanb@ishoni.com
Precedence: bulk
X-list: linux-mips

Hi,
      I want to measure the time taken by any kernel function. 
Is  there anything like rdtsc indtruction in MIPS ?
I saw timepeg patch for measuring the same for Pentium , is there anything
similar to it for MIPS ?


Thanks
Chetan

From jbglaw@dvmwest.gt.owl.de Thu Jan 16 09:46:14 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 16 Jan 2003 09:46:15 +0000 (GMT)
Received: from dvmwest.gt.owl.de ([IPv6:::ffff:62.52.24.140]:13069 "EHLO
	dvmwest.gt.owl.de") by linux-mips.org with ESMTP
	id <S8225216AbTAPJqO>; Thu, 16 Jan 2003 09:46:14 +0000
Received: by dvmwest.gt.owl.de (Postfix, from userid 1001)
	id 42BAD4A8D5; Thu, 16 Jan 2003 10:46:12 +0100 (CET)
Date: Thu, 16 Jan 2003 10:46:12 +0100
From: Jan-Benedict Glaw <jbglaw@lug-owl.de>
To: linux-mips@linux-mips.org
Subject: Re: MOPD problems
Message-ID: <20030116094612.GJ27441@lug-owl.de>
Mail-Followup-To: linux-mips@linux-mips.org
References: <1042674081.2735.102.camel@Opus> <Pine.LNX.4.44.0301160103580.10229-100000@skynet>
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="03sphU6jKm9HdgU1"
Content-Disposition: inline
In-Reply-To: <Pine.LNX.4.44.0301160103580.10229-100000@skynet>
User-Agent: Mutt/1.4i
X-Operating-System: Linux mail 2.4.18 
x-gpg-fingerprint: 250D 3BCF 7127 0D8C A444  A961 1DBD 5E75 8399 E1BB
x-gpg-key: wwwkeys.de.pgp.net
Return-Path: <jbglaw@dvmwest.gt.owl.de>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1167
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: jbglaw@lug-owl.de
Precedence: bulk
X-list: linux-mips


--03sphU6jKm9HdgU1
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Thu, 2003-01-16 01:04:58 +0000, Dave Airlie <airlied@csn.ul.ie>
wrote in message <Pine.LNX.4.44.0301160103580.10229-100000@skynet>:
>=20
> sometimes a long time agao.. you needed to manually add the ethernet
> address of the decstation to the arp table on the host machine..
>=20
> arp -s <decstation_hostname> <ethernet_address>

MOP isn't an IP based protocol so it doesn't care about IP addresses. I
think you want to solve some problem while TFTP'ing something:-)

MfG, JBG

--=20
   Jan-Benedict Glaw       jbglaw@lug-owl.de    . +49-172-7608481
   "Eine Freie Meinung in  einem Freien Kopf    | Gegen Zensur
    fuer einen Freien Staat voll Freier B=FCrger" | im Internet!
   Shell Script APT-Proxy: http://lug-owl.de/~jbglaw/software/ap2/

--03sphU6jKm9HdgU1
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQE+Jn9jHb1edYOZ4bsRAqpvAJ40vNRwzZYla/WobPBhmRNChVCIwACgiFJM
zxt6huAPZc6VsRqq/hmp2xs=
=TWdM
-----END PGP SIGNATURE-----

--03sphU6jKm9HdgU1--

From jbglaw@dvmwest.gt.owl.de Thu Jan 16 09:47:01 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 16 Jan 2003 09:47:01 +0000 (GMT)
Received: from dvmwest.gt.owl.de ([IPv6:::ffff:62.52.24.140]:13581 "EHLO
	dvmwest.gt.owl.de") by linux-mips.org with ESMTP
	id <S8225216AbTAPJrB>; Thu, 16 Jan 2003 09:47:01 +0000
Received: by dvmwest.gt.owl.de (Postfix, from userid 1001)
	id 764214A8D5; Thu, 16 Jan 2003 10:47:00 +0100 (CET)
Date: Thu, 16 Jan 2003 10:47:00 +0100
From: Jan-Benedict Glaw <jbglaw@lug-owl.de>
To: linux-mips@linux-mips.org
Subject: Re: MOPD problems
Message-ID: <20030116094700.GK27441@lug-owl.de>
Mail-Followup-To: linux-mips@linux-mips.org
References: <1042674081.2735.102.camel@Opus>
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="kJMkLA1uPhjFFA+D"
Content-Disposition: inline
In-Reply-To: <1042674081.2735.102.camel@Opus>
User-Agent: Mutt/1.4i
X-Operating-System: Linux mail 2.4.18 
x-gpg-fingerprint: 250D 3BCF 7127 0D8C A444  A961 1DBD 5E75 8399 E1BB
x-gpg-key: wwwkeys.de.pgp.net
Return-Path: <jbglaw@dvmwest.gt.owl.de>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1168
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: jbglaw@lug-owl.de
Precedence: bulk
X-list: linux-mips


--kJMkLA1uPhjFFA+D
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Wed, 2003-01-15 18:41:16 -0500, Justin Pauley <jpauley@xwizards.com>
wrote in message <1042674081.2735.102.camel@Opus>:
> I downloaded the mopd server and installed a bunch of the patches until
> mopd compiled. I downloaded the mopimage and put it in my /tftpboot/mop
> with the correct name. However, after running mop with "mopd -d eth0"
> and then running "boot 3/mop" on my decstation nothing happens. However,
> I have noticed that when I run a packet dumping software (etherreal) and
> then I try it I get this on my mopd:
>=20
> MOP DL 8:0:2b:2e:77:40   > ab:0:0:1:0:0      len   11 code 08 RPR
> MOP DL 0:d0:9:f8:fc:a5   > 8:0:2b:2e:77:40   len    1 code 03 ASV
> MOP DL 8:0:2b:2e:77:40   > 0:d0:9:f8:fc:a5   len   11 code 08 RPR
> MOP DL 0:d0:9:f8:fc:a5   > 8:0:2b:2e:77:40   len 1058 code 02 MLD
>=20
> This in my syslog:
> Jan 15 18:30:47 opus mopd[18215]: 8:0:2b:2e:77:40 (1) Do you have
> 08002b2e7740? (Yes)
> Jan 15 18:30:47 opus mopd[18215]: 8:0:2b:2e:77:40 Send me 08002b2e7740
>=20
> but then my Decstation produces something similar to the following:
>=20
> >> boot 3/mop
>=20
> ???
> ? PC: 0x.....
> ? CR: 0x....
> ? SR: 0x....
> ? VA: 0x0
> ? ER: 180....
> ? MER: 0x162....
>=20
> and then returns back to the console ">>".
> (note that the ... were added by me to replace a long line of
> numbers/letters)

It doesn't really tell me much, but please try the ELF linux kernel
image instead of the MOP image once.

MfG, JBG

--=20
   Jan-Benedict Glaw       jbglaw@lug-owl.de    . +49-172-7608481
   "Eine Freie Meinung in  einem Freien Kopf    | Gegen Zensur
    fuer einen Freien Staat voll Freier B=FCrger" | im Internet!
   Shell Script APT-Proxy: http://lug-owl.de/~jbglaw/software/ap2/

--kJMkLA1uPhjFFA+D
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQE+Jn+UHb1edYOZ4bsRAk1uAJ0UukOmCylrsGe6blP//eovA+sLtQCdH03V
TqN43aX/LuSjL3SuuhNzCg8=
=lTX4
-----END PGP SIGNATURE-----

--kJMkLA1uPhjFFA+D--

From jpauley@xwizards.com Thu Jan 16 11:53:58 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 16 Jan 2003 11:53:58 +0000 (GMT)
Received: from smtp02.infoave.net ([IPv6:::ffff:165.166.0.27]:53242 "EHLO
	smtp02.infoave.net") by linux-mips.org with ESMTP
	id <S8224851AbTAPLx6> convert rfc822-to-8bit; Thu, 16 Jan 2003 11:53:58 +0000
Received: from opus ([204.116.3.125])
 by SMTP00.InfoAve.Net (PMDF V6.1-1IA5 #38776)
 with ESMTP id <01KRAL3JAVZ894ROUT@SMTP00.InfoAve.Net> for
 linux-mips@linux-mips.org; Thu, 16 Jan 2003 06:53:35 -0500 (EST)
Date: Thu, 16 Jan 2003 06:55:04 -0500
From: Justin Pauley <jpauley@xwizards.com>
Subject: Re: MOPD problems
In-reply-to: <20030116094612.GJ27441@lug-owl.de>
To: Jan-Benedict Glaw <jbglaw@lug-owl.de>
Cc: linux-mips@linux-mips.org
Message-id: <1042718104.2735.113.camel@Opus>
MIME-version: 1.0
X-Mailer: Ximian Evolution 1.0.8 (1.0.8-10)
Content-type: text/plain; charset=UTF-8
Content-transfer-encoding: 8BIT
References: <1042674081.2735.102.camel@Opus>
 <Pine.LNX.4.44.0301160103580.10229-100000@skynet>
 <20030116094612.GJ27441@lug-owl.de>
Return-Path: <jpauley@xwizards.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1169
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: jpauley@xwizards.com
Precedence: bulk
X-list: linux-mips

My firmware won't allow me to TFTP over 1 meg, mopd is my last choice.
Justin
On Thu, 2003-01-16 at 04:46, Jan-Benedict Glaw wrote:
> On Thu, 2003-01-16 01:04:58 +0000, Dave Airlie <airlied@csn.ul.ie>
> wrote in message <Pine.LNX.4.44.0301160103580.10229-100000@skynet>:
> > 
> > sometimes a long time agao.. you needed to manually add the ethernet
> > address of the decstation to the arp table on the host machine..
> > 
> > arp -s <decstation_hostname> <ethernet_address>
> 
> MOP isn't an IP based protocol so it doesn't care about IP addresses. I
> think you want to solve some problem while TFTP'ing something:-)
> 
> MfG, JBG
> 
> -- 
>    Jan-Benedict Glaw       jbglaw@lug-owl.de    . +49-172-7608481
>    "Eine Freie Meinung in  einem Freien Kopf    | Gegen Zensur
>     fuer einen Freien Staat voll Freier BÃ¼rger" | im Internet!
>    Shell Script APT-Proxy: http://lug-owl.de/~jbglaw/software/ap2/



From flo@rfc822.org Thu Jan 16 15:18:26 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 16 Jan 2003 15:18:26 +0000 (GMT)
Received: from noose.gt.owl.de ([IPv6:::ffff:62.52.19.4]:19716 "EHLO
	noose.gt.owl.de") by linux-mips.org with ESMTP id <S8225233AbTAPPS0>;
	Thu, 16 Jan 2003 15:18:26 +0000
Received: by noose.gt.owl.de (Postfix, from userid 10)
	id CD1AE25DF9; Thu, 16 Jan 2003 16:18:21 +0100 (CET)
Received: by paradigm.rfc822.org (Postfix, from userid 1000)
	id F3AFBB2AB; Thu, 16 Jan 2003 16:18:07 +0100 (CET)
Date: Thu, 16 Jan 2003 16:18:07 +0100
From: Florian Lohoff <flo@rfc822.org>
To: Chetan B L <chetanb@ishoni.com>
Cc: "'linux-mips@linux-mips.org'" <linux-mips@linux-mips.org>
Subject: Re: Performance measuring in MIPS R3000
Message-ID: <20030116151807.GI5410@paradigm.rfc822.org>
References: <7CFD7CA8510CD6118F950002A519EA3003FB04E6@leonoid.in.ishoni.com>
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="y96v7rNg6HAoELs5"
Content-Disposition: inline
In-Reply-To: <7CFD7CA8510CD6118F950002A519EA3003FB04E6@leonoid.in.ishoni.com>
User-Agent: Mutt/1.3.28i
Organization: rfc822 - pure communication
Return-Path: <flo@rfc822.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1170
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: flo@rfc822.org
Precedence: bulk
X-list: linux-mips


--y96v7rNg6HAoELs5
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Thu, Jan 16, 2003 at 12:01:52PM +0530, Chetan B L wrote:
> Hi,
>       I want to measure the time taken by any kernel function.=20
> Is  there anything like rdtsc indtruction in MIPS ?
> I saw timepeg patch for measuring the same for Pentium , is there anything
> similar to it for MIPS ?

Depending on the CPU - IIRC most R4k variants have something like this
and its sometimes used for generating Timer-Interrupts.

Flo
--=20
Florian Lohoff                  flo@rfc822.org             +49-5201-669912
                        Heisenberg may have been here.

--y96v7rNg6HAoELs5
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE+Js0vUaz2rXW+gJcRAsH8AJ9Jw16U/vfPSHOA3yC+lYmk+pB2+gCgtKLo
UnktJyhOGikbHxW5VCDfpxU=
=iF5C
-----END PGP SIGNATURE-----

--y96v7rNg6HAoELs5--

From yaelgilad@myrealbox.com Thu Jan 16 16:49:31 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 16 Jan 2003 16:49:32 +0000 (GMT)
Received: from smtp-send.myrealbox.com ([IPv6:::ffff:192.108.102.143]:7725
	"EHLO smtp-send.myrealbox.com") by linux-mips.org with ESMTP
	id <S8225233AbTAPQtb>; Thu, 16 Jan 2003 16:49:31 +0000
Received: from Crusty yaelgilad@smtp-send.myrealbox.com [194.90.64.161]
	by smtp-send.myrealbox.com with NetMail SMTP Agent $Revision:   3.22  $ on Novell NetWare;
	Thu, 16 Jan 2003 09:49:24 -0700
From: "Gilad Benjamini" <yaelgilad@myrealbox.com>
To: <linux-mips@linux-mips.org>
Subject: Getting Time Difference
Date: Thu, 16 Jan 2003 18:48:09 +0200
Message-ID: <ECEPLLMMNGHMFBLHCLMAGEGDDIAA.yaelgilad@myrealbox.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="windows-1255"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Return-Path: <yaelgilad@myrealbox.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1171
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: yaelgilad@myrealbox.com
Precedence: bulk
X-list: linux-mips

Hi,
I am porting code from a x86 platform.
That code uses rdtsc and cpu_khz to compute
the time difference between two events. Jiffies aren't good enough in this 
case.

Looking through header files I can find a few MIPS replacements.
What is the "right" one to use ?

What is the best way to change the code so it can compile
and run on both platforms ?


From lindahl@keyresearch.com Fri Jan 17 01:21:50 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 17 Jan 2003 01:21:51 +0000 (GMT)
Received: from ppp-66-122-194-201.aonnetworks.com ([IPv6:::ffff:66.122.194.201]:3972
	"EHLO localhost.localdomain") by linux-mips.org with ESMTP
	id <S8225240AbTAQBVu>; Fri, 17 Jan 2003 01:21:50 +0000
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1])
	by localhost.localdomain (8.12.5/8.12.5) with ESMTP id h0H1QiL7002069
	for <linux-mips@linux-mips.org>; Thu, 16 Jan 2003 17:26:44 -0800
Received: (from lindahl@localhost)
	by localhost.localdomain (8.12.5/8.12.5/Submit) id h0H1QiZx002067
	for linux-mips@linux-mips.org; Thu, 16 Jan 2003 17:26:44 -0800
X-Authentication-Warning: localhost.localdomain: lindahl set sender to lindahl@keyresearch.com using -f
Date: Thu, 16 Jan 2003 17:26:44 -0800
From: Greg Lindahl <lindahl@keyresearch.com>
To: linux-mips@linux-mips.org
Subject: Anyone running crashme?
Message-ID: <20030117012644.GA2058@wumpus.internal.keyresearch.com>
Mail-Followup-To: linux-mips@linux-mips.org
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.4i
Return-Path: <lindahl@keyresearch.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1172
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: lindahl@keyresearch.com
Precedence: bulk
X-list: linux-mips

I've been running crashme a little against Linux mips, and from the
bugs I immediately found I suspect that no one's been running it.
Crashme generates random bytes and then executes them, catching the
resulting signals and generating more random bytes. The random number
seed is provided by the user, so that problems are repeatable.

If you like debugging, you can find the source at:

http://people.delphiforums.com/gjc/crashme.html

-- greg





From jpauley@xwizards.com Fri Jan 17 02:09:41 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 17 Jan 2003 02:09:41 +0000 (GMT)
Received: from smtp02.infoave.net ([IPv6:::ffff:165.166.0.27]:63989 "EHLO
	smtp02.infoave.net") by linux-mips.org with ESMTP
	id <S8225240AbTAQCJl>; Fri, 17 Jan 2003 02:09:41 +0000
Received: from opus ([204.116.3.125])
 by SMTP00.InfoAve.Net (PMDF V6.1-1IA5 #38777)
 with ESMTP id <01KRBEZT1QGQ90XD8E@SMTP00.InfoAve.Net> for
 linux-mips@linux-mips.org; Thu, 16 Jan 2003 21:09:34 -0500 (EST)
Date: Thu, 16 Jan 2003 21:11:14 -0500
From: Justin Pauley <jpauley@xwizards.com>
Subject: Problems booting
To: linux-mips@linux-mips.org
Message-id: <1042769475.2735.161.camel@Opus>
MIME-version: 1.0
X-Mailer: Ximian Evolution 1.0.8 (1.0.8-10)
Content-type: text/plain
Content-transfer-encoding: 7bit
Return-Path: <jpauley@xwizards.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1173
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: jpauley@xwizards.com
Precedence: bulk
X-list: linux-mips

Well, MOPD works now! And I installed debian linux. However, now when i
try to boot with:
boot 3/rz0/vmlinux console=ttyS0 
I get the following:
delo V0.7 Copyright....
extfs_open returned Unknown ext2 error(2133571404)
Couldnt fetch config.file /etc/delo.cconf

Any ideas?
Thanks,
Justin




From henaldohzh@hotmail.com Fri Jan 17 03:32:23 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 17 Jan 2003 03:32:23 +0000 (GMT)
Received: from f143.law9.hotmail.com ([IPv6:::ffff:64.4.9.143]:16140 "EHLO
	hotmail.com") by linux-mips.org with ESMTP id <S8225240AbTAQDcX>;
	Fri, 17 Jan 2003 03:32:23 +0000
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Thu, 16 Jan 2003 19:32:12 -0800
Received: from 210.74.191.34 by lw9fd.law9.hotmail.msn.com with HTTP;
	Fri, 17 Jan 2003 03:32:12 GMT
X-Originating-IP: [210.74.191.34]
From: "" <henaldohzh@hotmail.com>
To: linux-mips@linux-mips.org
Subject: problem about porting kernel to mips`
Date: Fri, 17 Jan 2003 03:32:12 +0000
Mime-Version: 1.0
Content-Type: text/plain; charset=gb2312; format=flowed
Message-ID: <F143mF1IT18olkDTM9w00040789@hotmail.com>
X-OriginalArrivalTime: 17 Jan 2003 03:32:12.0397 (UTC) FILETIME=[05E0D9D0:01C2BDD9]
Return-Path: <henaldohzh@hotmail.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1174
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: henaldohzh@hotmail.com
Precedence: bulk
X-list: linux-mips

hi, all,
  So sorry to distrub you. 
  now, I am porting kernel to a board with vr4131 core. But when I run 
application, sometimes, kernel report bug in sched.c or traps.c. I debuged 
the kernel and found that problem is in_interrupt return 2(local_bh_irq is 
2). So am I puzzled. And sometimes,kernel report data unaligned. 
  Thanks very much for your help.

_________________________________________________________________
ÓëÁª»úµÄÅóÓÑ½øÐÐ½»Á÷£¬ÇëÊ¹ÓÃ MSN Messenger: http://messenger.msn.com/cn 


From karsten@excalibur.cologne.de Fri Jan 17 06:05:58 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 17 Jan 2003 06:05:59 +0000 (GMT)
Received: from natsmtp01.webmailer.de ([IPv6:::ffff:192.67.198.81]:45762 "EHLO
	post.webmailer.de") by linux-mips.org with ESMTP
	id <S8225248AbTAQGF6>; Fri, 17 Jan 2003 06:05:58 +0000
Received: from excalibur.cologne.de (p5085126C.dip.t-dialin.net [80.133.18.108])
	by post.webmailer.de (8.9.3/8.8.7) with ESMTP id HAA05638
	for <linux-mips@linux-mips.org>; Fri, 17 Jan 2003 07:05:48 +0100 (MET)
Received: from karsten by excalibur.cologne.de with local (Exim 3.35 #1 (Debian))
	id 18ZPiL-0000M7-00
	for <linux-mips@linux-mips.org>; Fri, 17 Jan 2003 07:10:49 +0100
Date: Fri, 17 Jan 2003 07:10:48 +0100
From: Karsten Merker <karsten@excalibur.cologne.de>
To: linux-mips@linux-mips.org
Subject: Re: Problems booting
Message-ID: <20030117061047.GA474@excalibur.cologne.de>
Mail-Followup-To: Karsten Merker <karsten@excalibur.cologne.de>,
	linux-mips@linux-mips.org
References: <1042769475.2735.161.camel@Opus>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <1042769475.2735.161.camel@Opus>
User-Agent: Mutt/1.3.28i
X-No-Archive: yes
Return-Path: <karsten@excalibur.cologne.de>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1175
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: karsten@excalibur.cologne.de
Precedence: bulk
X-list: linux-mips

On Thu, Jan 16, 2003 at 09:11:14PM -0500, Justin Pauley wrote:

> Well, MOPD works now! And I installed debian linux. However, now when i
> try to boot with:
> boot 3/rz0/vmlinux console=ttyS0 
> I get the following:
> delo V0.7 Copyright....
> extfs_open returned Unknown ext2 error(2133571404)
> Couldnt fetch config.file /etc/delo.cconf

Try just booting with "boot 3/rz0" without further parameters. Delo takes
its parameters a bit differently than e.g. Ultrixboot and if given no
parameters, it should use the default values from the installation process.
If this does not help: do you have /boot and /etc on the same partition? If
not, this might cause the problem. AFAIK delo cannot handle the config file
on one and the kernel on another partition. Flo, Thiemo?

To get the box booted, you can netboot the installed system with the image
from

http://people.debian.org/~merker/experimental_packages/bf-pre3.0.24-20021224/unpacked/r3k-kn02/linux.bin

which is an ELF kernel image that can be booted via MOP ("boot 3/mop
console=ttyS0" should do it).

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 kevink@mips.com Fri Jan 17 07:36:37 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 17 Jan 2003 07:36:37 +0000 (GMT)
Received: from ftp.mips.com ([IPv6:::ffff:206.31.31.227]:40878 "EHLO
	mx2.mips.com") by linux-mips.org with ESMTP id <S8225248AbTAQHgh>;
	Fri, 17 Jan 2003 07:36:37 +0000
Received: from newman.mips.com (ns-dmz [206.31.31.225])
	by mx2.mips.com (8.12.5/8.12.5) with ESMTP id h0H7aQ67013891;
	Thu, 16 Jan 2003 23:36:26 -0800 (PST)
Received: from grendel (grendel [192.168.236.16])
	by newman.mips.com (8.9.3/8.9.0) with SMTP id XAA25008;
	Thu, 16 Jan 2003 23:36:24 -0800 (PST)
Message-ID: <000f01c2bdfb$e2cb7220$10eca8c0@grendel>
From: "Kevin D. Kissell" <kevink@mips.com>
To: "Greg Lindahl" <lindahl@keyresearch.com>,
	<linux-mips@linux-mips.org>
References: <20030117012644.GA2058@wumpus.internal.keyresearch.com>
Subject: Re: Anyone running crashme?
Date: Fri, 17 Jan 2003 08:41:43 +0100
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4807.1700
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300
Return-Path: <kevink@mips.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1176
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: kevink@mips.com
Precedence: bulk
X-list: linux-mips

Actiually, we've been using crashme at MIPS
for several years now, both to torture the Linux 
kernel and to push our chip designs into unexpected 
corner cases.  We found a fair number of kernel
bugs, and fixed them in our internal sources
(snapshots are generally available under
ftp://ftp.mips.com/pub/linux/mips/kernel )
and have pushed our fixes out toward the
mainline distributions.  That's not to say that
they all get there.

Two things to watch out for: There is a class
of crashme misbehavior, usually manifest in
forked threads that do not terminate correctly
until the program is shut down, that arises not
from a kernel bug, but from a libc built with
downrev kernel headers.  And if you have a
CPU that supports EJTAG, you either need to
make sure that your boot ROM has code at the
EJTAG debug exception vector that jumps to the
EJTAG kseg0 pseudo-vector used by the Linux
kernel (well, *our* Linux kernel anyway ;-), 
or you need to put a filter in crashme to ensure 
that it does not generate EJTAG debug breakpoint 
instructions.

But I'm glad to see that someone else is using it.

----- Original Message ----- 
From: "Greg Lindahl" <lindahl@keyresearch.com>
To: <linux-mips@linux-mips.org>
Sent: Friday, January 17, 2003 2:26 AM
Subject: Anyone running crashme?


> I've been running crashme a little against Linux mips, and from the
> bugs I immediately found I suspect that no one's been running it.
> Crashme generates random bytes and then executes them, catching the
> resulting signals and generating more random bytes. The random number
> seed is provided by the user, so that problems are repeatable.
> 
> If you like debugging, you can find the source at:
> 
> http://people.delphiforums.com/gjc/crashme.html
> 
> -- greg
> 
> 
> 
> 
> 
> 

From ralf@linux-mips.org Fri Jan 17 12:56:23 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 17 Jan 2003 12:56:24 +0000 (GMT)
Received: from p508B625A.dip.t-dialin.net ([IPv6:::ffff:80.139.98.90]:20936
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225248AbTAQM4X>; Fri, 17 Jan 2003 12:56:23 +0000
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.11.6/8.11.6) id h0HCuJg08504;
	Fri, 17 Jan 2003 13:56:19 +0100
Date: Fri, 17 Jan 2003 13:56:19 +0100
From: Ralf Baechle <ralf@linux-mips.org>
To: Gilad Benjamini <yaelgilad@myrealbox.com>
Cc: linux-mips@linux-mips.org
Subject: Re: Getting Time Difference
Message-ID: <20030117135619.A8301@linux-mips.org>
References: <ECEPLLMMNGHMFBLHCLMAGEGDDIAA.yaelgilad@myrealbox.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5.1i
In-Reply-To: <ECEPLLMMNGHMFBLHCLMAGEGDDIAA.yaelgilad@myrealbox.com>; from yaelgilad@myrealbox.com on Thu, Jan 16, 2003 at 06:48:09PM +0200
Return-Path: <ralf@linux-mips.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1177
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips

On Thu, Jan 16, 2003 at 06:48:09PM +0200, Gilad Benjamini wrote:

> I am porting code from a x86 platform.
> That code uses rdtsc and cpu_khz to compute
> the time difference between two events. Jiffies aren't good enough in this 
> case.
> 
> Looking through header files I can find a few MIPS replacements.
> What is the "right" one to use ?
> 
> What is the best way to change the code so it can compile
> and run on both platforms ?

Try do_gettimeofday().

  Ralf

From ralf@linux-mips.org Fri Jan 17 13:09:06 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 17 Jan 2003 13:09:06 +0000 (GMT)
Received: from p508B625A.dip.t-dialin.net ([IPv6:::ffff:80.139.98.90]:45256
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225248AbTAQNJG>; Fri, 17 Jan 2003 13:09:06 +0000
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.11.6/8.11.6) id h0HD92L08800;
	Fri, 17 Jan 2003 14:09:02 +0100
Date: Fri, 17 Jan 2003 14:09:02 +0100
From: Ralf Baechle <ralf@linux-mips.org>
To: Chetan B L <chetanb@ishoni.com>
Cc: "'linux-mips@linux-mips.org'" <linux-mips@linux-mips.org>
Subject: Re: Performance measuring in MIPS R3000
Message-ID: <20030117140902.B8301@linux-mips.org>
References: <7CFD7CA8510CD6118F950002A519EA3003FB04E6@leonoid.in.ishoni.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5.1i
In-Reply-To: <7CFD7CA8510CD6118F950002A519EA3003FB04E6@leonoid.in.ishoni.com>; from chetanb@ishoni.com on Thu, Jan 16, 2003 at 12:01:52PM +0530
Return-Path: <ralf@linux-mips.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1178
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips

On Thu, Jan 16, 2003 at 12:01:52PM +0530, Chetan B L wrote:

>       I want to measure the time taken by any kernel function. 
> Is  there anything like rdtsc indtruction in MIPS ?
> I saw timepeg patch for measuring the same for Pentium , is there anything
> similar to it for MIPS ?

The subject of your mail is mentioning the R3000 which doesn't have any
kind of timer in the processor.  As already mentioned in my other posting
do_gettimeofday() is the portable timer interface providing the highest
accuracy.  But the R3000 processor itself doesn't provide any timers so
the precission of the clock will actually depend of the whatever timers
are provided by the rest of the system.  Hoever I doubt you're actually
using a true R3000 - the R3000 is an ~ 1988 vintage processor.  Later
R3000 processors frequently contain a suitable timer.

  Ralf

From jpauley@xwizards.com Sat Jan 18 16:33:02 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 18 Jan 2003 16:33:02 +0000 (GMT)
Received: from smtp03.infoave.net ([IPv6:::ffff:165.166.0.28]:39158 "EHLO
	smtp03.infoave.net") by linux-mips.org with ESMTP
	id <S8225259AbTARQdC>; Sat, 18 Jan 2003 16:33:02 +0000
Received: from opus ([204.116.3.125])
 by SMTP00.InfoAve.Net (PMDF V6.1-1IA5 #38776)
 with ESMTP id <01KRDNFL0C3294RGXQ@SMTP00.InfoAve.Net> for
 linux-mips@linux-mips.org; Sat, 18 Jan 2003 11:32:56 -0500 (EST)
Date: Sat, 18 Jan 2003 11:35:06 -0500
From: Justin Pauley <jpauley@xwizards.com>
Subject: Mopd Directions
To: linux-mips@linux-mips.org
Message-id: <1042907706.3331.206.camel@Opus>
MIME-version: 1.0
X-Mailer: Ximian Evolution 1.0.8 (1.0.8-10)
Content-type: text/plain
Content-transfer-encoding: 7bit
Return-Path: <jpauley@xwizards.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1179
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: jpauley@xwizards.com
Precedence: bulk
X-list: linux-mips

Thank you all so much for helping me get my linux installed. I now have
debian installed on my Decstation 5000/25 having used Mopd. I wrote down
all the information I would need if i needed to do this again and if you
would like you can send it out to other people who have my same problem.
The directions are at http://www.xwizards.com/MopLinuxDec.html 


Thank you all again,
Justin Pauley




From ica2_ts@csv.ica.uni-stuttgart.de Mon Jan 20 05:19:01 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 20 Jan 2003 05:19:02 +0000 (GMT)
Received: from iris1.csv.ica.uni-stuttgart.de ([IPv6:::ffff:129.69.118.2]:22055
	"EHLO iris1.csv.ica.uni-stuttgart.de") by linux-mips.org with ESMTP
	id <S8225197AbTATFTB>; Mon, 20 Jan 2003 05:19:01 +0000
Received: from rembrandt.csv.ica.uni-stuttgart.de ([129.69.118.42])
	by iris1.csv.ica.uni-stuttgart.de with esmtp (Exim 3.36 #2)
	id 18aUKp-000O2E-00; Mon, 20 Jan 2003 06:18:59 +0100
Received: from ica2_ts by rembrandt.csv.ica.uni-stuttgart.de with local (Exim 3.35 #1 (Debian))
	id 18aUKp-0006Ff-00; Mon, 20 Jan 2003 06:18:59 +0100
Date: Mon, 20 Jan 2003 06:18:59 +0100
To: linux-mips@linux-mips.org
Cc: Karsten Merker <karsten@excalibur.cologne.de>
Subject: Re: Problems booting
Message-ID: <20030120051859.GG14931@rembrandt.csv.ica.uni-stuttgart.de>
References: <1042769475.2735.161.camel@Opus> <20030117061047.GA474@excalibur.cologne.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20030117061047.GA474@excalibur.cologne.de>
User-Agent: Mutt/1.4i
From: Thiemo Seufer <ica2_ts@csv.ica.uni-stuttgart.de>
Return-Path: <ica2_ts@csv.ica.uni-stuttgart.de>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1180
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ica2_ts@csv.ica.uni-stuttgart.de
Precedence: bulk
X-list: linux-mips

Karsten Merker wrote:
> On Thu, Jan 16, 2003 at 09:11:14PM -0500, Justin Pauley wrote:
> 
> > Well, MOPD works now! And I installed debian linux. However, now when i
> > try to boot with:
> > boot 3/rz0/vmlinux console=ttyS0 
> > I get the following:
> > delo V0.7 Copyright....
> > extfs_open returned Unknown ext2 error(2133571404)

I believe this is fixed in my improved version of delo. If you aren't afraid
of raw source tarballs and want to try it out, it's available at
http://www.csv.ica.uni-stuttgart.de/homes/ths/linux-mips/delo/

> > Couldnt fetch config.file /etc/delo.cconf
> 
> Try just booting with "boot 3/rz0" without further parameters. Delo takes
> its parameters a bit differently than e.g. Ultrixboot and if given no
> parameters, it should use the default values from the installation process.
> If this does not help: do you have /boot and /etc on the same partition? If
> not, this might cause the problem. AFAIK delo cannot handle the config file
> on one and the kernel on another partition. Flo, Thiemo?

Yes, still true, even for my improved version of delo.


Thiemo

From macro@ds2.pg.gda.pl Mon Jan 20 16:10:37 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 20 Jan 2003 16:10:37 +0000 (GMT)
Received: from delta.ds2.pg.gda.pl ([IPv6:::ffff:213.192.72.1]:32700 "EHLO
	delta.ds2.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8225203AbTATQKh>; Mon, 20 Jan 2003 16:10:37 +0000
Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id RAA06703;
	Mon, 20 Jan 2003 17:10:41 +0100 (MET)
Date: Mon, 20 Jan 2003 17:10:41 +0100 (MET)
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To: Justin Pauley <jpauley@xwizards.com>
cc: linux-mips@linux-mips.org
Subject: Re: Mopd Directions
In-Reply-To: <1042907706.3331.206.camel@Opus>
Message-ID: <Pine.GSO.3.96.1030120170316.4801C-100000@delta.ds2.pg.gda.pl>
Organization: Technical University of Gdansk
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <macro@ds2.pg.gda.pl>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1181
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: macro@ds2.pg.gda.pl
Precedence: bulk
X-list: linux-mips

On Sat, 18 Jan 2003, Justin Pauley wrote:

> The directions are at http://www.xwizards.com/MopLinuxDec.html 

 You don't need to turn the promiscuous mode on, unless you have a strange
network card, for which there is no multicast support in the kernel.  You
probably don't want, either, as with a busy network the mode hurts
performance a lot, stealing processor's cycles for throwing useless frames
away.  The mopd daemon binds to multicast MAC addresses it's interested
in. 

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


From jsun@orion.mvista.com Mon Jan 20 19:44:10 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 20 Jan 2003 19:44:10 +0000 (GMT)
Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:250 "EHLO
	orion.mvista.com") by linux-mips.org with ESMTP id <S8225262AbTATToK>;
	Mon, 20 Jan 2003 19:44:10 +0000
Received: (from jsun@localhost)
	by orion.mvista.com (8.11.6/8.11.6) id h0KJi5001568;
	Mon, 20 Jan 2003 11:44:05 -0800
Date: Mon, 20 Jan 2003 11:44:05 -0800
From: Jun Sun <jsun@mvista.com>
To: linux-mips@linux-mips.org
Cc: jsun@mvista.com
Subject: Re: Anyone running crashme?
Message-ID: <20030120114405.T2100@mvista.com>
References: <20030117012644.GA2058@wumpus.internal.keyresearch.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <20030117012644.GA2058@wumpus.internal.keyresearch.com>; from lindahl@keyresearch.com on Thu, Jan 16, 2003 at 05:26:44PM -0800
Return-Path: <jsun@orion.mvista.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1182
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: jsun@mvista.com
Precedence: bulk
X-list: linux-mips


I have crashme running on several boards here.  The only problem
found is that kernel does not check for MDMX exception
for newer CPUs, which is already fixed in the tree.

Jun

On Thu, Jan 16, 2003 at 05:26:44PM -0800, Greg Lindahl wrote:
> I've been running crashme a little against Linux mips, and from the
> bugs I immediately found I suspect that no one's been running it.
> Crashme generates random bytes and then executes them, catching the
> resulting signals and generating more random bytes. The random number
> seed is provided by the user, so that problems are repeatable.
> 
> If you like debugging, you can find the source at:
> 
> http://people.delphiforums.com/gjc/crashme.html
> 
> -- greg
> 
> 
> 
> 
> 

From tpolgar@freehandsystems.com Mon Jan 20 19:44:29 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 20 Jan 2003 19:44:30 +0000 (GMT)
Received: from [IPv6:::ffff:66.221.142.1] ([IPv6:::ffff:66.221.142.1]:17643
	"EHLO bisque.propagation.net") by linux-mips.org with ESMTP
	id <S8225264AbTATToT>; Mon, 20 Jan 2003 19:44:19 +0000
Received: from freehandsystems.com (adsl-64-170-127-190.dsl.snfc21.pacbell.net [64.170.127.190])
	by bisque.propagation.net (8.11.6/8.8.5) with ESMTP id h0KJiFm00985
	for <linux-mips@linux-mips.org>; Mon, 20 Jan 2003 13:44:16 -0600
Message-ID: <3E2C518B.E1596B8B@freehandsystems.com>
Date: Mon, 20 Jan 2003 11:44:11 -0800
From: Tibor Polgar <tpolgar@freehandsystems.com>
X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: linux-mips@linux-mips.org
Subject: Is the CVS server down?
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Return-Path: <tpolgar@freehandsystems.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1183
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: tpolgar@freehandsystems.com
Precedence: bulk
X-list: linux-mips

I'm trying to get in to suck down the 2.4.19 tree but get:

> cvs -d :pserver:cvs@ftp.linux-mips.org:/home/cvs login
Logging in to :pserver:cvs@ftp.linux-mips.org:2401/home/cvs
CVS password: 
cvs [login aborted]: connect to ftp.linux-mips.org(62.254.210.162):2401
failed: Connection refused
> 

Per the website i'm using the password of "cvs" (without quotes).  Is it just
our site/firewall?

Thanks
Tibor

From jsimmons@infradead.org Mon Jan 20 19:48:25 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 20 Jan 2003 19:48:25 +0000 (GMT)
Received: from phoenix.infradead.org ([IPv6:::ffff:195.224.96.167]:19217 "EHLO
	phoenix.infradead.org") by linux-mips.org with ESMTP
	id <S8225264AbTATTsZ>; Mon, 20 Jan 2003 19:48:25 +0000
Received: from localhost.localdomain ([127.0.0.1] helo=localhost)
	by phoenix.infradead.org with esmtp (TLSv1:DES-CBC3-SHA:168)
	(Exim 4.10)
	id 18ahuB-0001b1-00; Mon, 20 Jan 2003 19:48:23 +0000
Date: Mon, 20 Jan 2003 19:48:23 +0000 (GMT)
From: James Simmons <jsimmons@infradead.org>
To: Tibor Polgar <tpolgar@freehandsystems.com>
cc: linux-mips@linux-mips.org
Subject: Re: Is the CVS server down?
In-Reply-To: <3E2C518B.E1596B8B@freehandsystems.com>
Message-ID: <Pine.LNX.4.44.0301201948110.6143-100000@phoenix.infradead.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <jsimmons@infradead.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1184
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: jsimmons@infradead.org
Precedence: bulk
X-list: linux-mips


No. I had the same experience.

On Mon, 20 Jan 2003, Tibor Polgar wrote:

> I'm trying to get in to suck down the 2.4.19 tree but get:
> 
> > cvs -d :pserver:cvs@ftp.linux-mips.org:/home/cvs login
> Logging in to :pserver:cvs@ftp.linux-mips.org:2401/home/cvs
> CVS password: 
> cvs [login aborted]: connect to ftp.linux-mips.org(62.254.210.162):2401
> failed: Connection refused
> > 
> 
> Per the website i'm using the password of "cvs" (without quotes).  Is it just
> our site/firewall?
> 
> Thanks
> Tibor
> 
> 


From jsun@orion.mvista.com Mon Jan 20 19:51:01 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 20 Jan 2003 19:51:02 +0000 (GMT)
Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:44029 "EHLO
	orion.mvista.com") by linux-mips.org with ESMTP id <S8225264AbTATTvB>;
	Mon, 20 Jan 2003 19:51:01 +0000
Received: (from jsun@localhost)
	by orion.mvista.com (8.11.6/8.11.6) id h0KJoxr01662;
	Mon, 20 Jan 2003 11:50:59 -0800
Date: Mon, 20 Jan 2003 11:50:59 -0800
From: Jun Sun <jsun@mvista.com>
To: Gilad Benjamini <yaelgilad@myrealbox.com>
Cc: linux-mips@linux-mips.org, jsun@mvista.com
Subject: Re: Getting Time Difference
Message-ID: <20030120115059.U2100@mvista.com>
References: <ECEPLLMMNGHMFBLHCLMAGEGDDIAA.yaelgilad@myrealbox.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <ECEPLLMMNGHMFBLHCLMAGEGDDIAA.yaelgilad@myrealbox.com>; from yaelgilad@myrealbox.com on Thu, Jan 16, 2003 at 06:48:09PM +0200
Return-Path: <jsun@orion.mvista.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1185
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: jsun@mvista.com
Precedence: bulk
X-list: linux-mips

On Thu, Jan 16, 2003 at 06:48:09PM +0200, Gilad Benjamini wrote:
> Hi,
> I am porting code from a x86 platform.
> That code uses rdtsc and cpu_khz to compute
> the time difference between two events. Jiffies aren't good enough in this 
> case.
> 
> Looking through header files I can find a few MIPS replacements.
> What is the "right" one to use ?
> 
> What is the best way to change the code so it can compile
> and run on both platforms ?
>

I assume you are doing this inside kernel for some performance
measurement.

In mvsita kernel we introduced an abstraction layer which consists
of the following:

readclock_init()
readclock()
clock_to_usecs()

For MIPS in general, we use the following implementation:

#define readclock_init()
#define readclock(low)   do {                           \
        db_assert(mips_cpu.options & MIPS_CPU_COUNTER); \
        low = read_32bit_cp0_register(CP0_COUNT);       \
        } while (0)     
#define clock_to_usecs(clocks) ((clocks) / ((mips_counter_frequency / 1000000)))

In mvl kernel we always calibrate mips_counter_frequency even if it
is not specified by board code.  This is different from the current
linux-mips.org tree.

Jun 

From macro@ds2.pg.gda.pl Mon Jan 20 20:00:20 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 20 Jan 2003 20:00:20 +0000 (GMT)
Received: from delta.ds2.pg.gda.pl ([IPv6:::ffff:213.192.72.1]:42435 "EHLO
	delta.ds2.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8225267AbTATUAU>; Mon, 20 Jan 2003 20:00:20 +0000
Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id VAA10886;
	Mon, 20 Jan 2003 21:00:22 +0100 (MET)
Date: Mon, 20 Jan 2003 21:00:21 +0100 (MET)
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To: James Simmons <jsimmons@infradead.org>
cc: Tibor Polgar <tpolgar@freehandsystems.com>,
	linux-mips@linux-mips.org
Subject: Re: Is the CVS server down?
In-Reply-To: <Pine.LNX.4.44.0301201948110.6143-100000@phoenix.infradead.org>
Message-ID: <Pine.GSO.3.96.1030120205855.4801J-100000@delta.ds2.pg.gda.pl>
Organization: Technical University of Gdansk
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <macro@ds2.pg.gda.pl>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1186
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: macro@ds2.pg.gda.pl
Precedence: bulk
X-list: linux-mips

On Mon, 20 Jan 2003, James Simmons wrote:

> No. I had the same experience.

 The server is intentionally down for a while.

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


From hch@infradead.org Mon Jan 20 20:15:35 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 20 Jan 2003 20:15:35 +0000 (GMT)
Received: from carisma.slowglass.com ([IPv6:::ffff:195.224.96.167]:32273 "EHLO
	phoenix.infradead.org") by linux-mips.org with ESMTP
	id <S8225270AbTATUPf>; Mon, 20 Jan 2003 20:15:35 +0000
Received: from hch by phoenix.infradead.org with local (Exim 4.10)
	id 18aiKS-0001jc-00; Mon, 20 Jan 2003 20:15:32 +0000
Date: Mon, 20 Jan 2003 20:15:31 +0000
From: Christoph Hellwig <hch@infradead.org>
To: Jun Sun <jsun@mvista.com>
Cc: Gilad Benjamini <yaelgilad@myrealbox.com>,
	linux-mips@linux-mips.org
Subject: Re: Getting Time Difference
Message-ID: <20030120201531.A6654@infradead.org>
References: <ECEPLLMMNGHMFBLHCLMAGEGDDIAA.yaelgilad@myrealbox.com> <20030120115059.U2100@mvista.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5.1i
In-Reply-To: <20030120115059.U2100@mvista.com>; from jsun@mvista.com on Mon, Jan 20, 2003 at 11:50:59AM -0800
Return-Path: <hch@infradead.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1187
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: hch@infradead.org
Precedence: bulk
X-list: linux-mips

On Mon, Jan 20, 2003 at 11:50:59AM -0800, Jun Sun wrote:
> I assume you are doing this inside kernel for some performance
> measurement.
> 
> In mvsita kernel we introduced an abstraction layer which consists
> of the following:

Do you have a pointer to the mvista tree (cvs/tarball/rpm/patch)?


From jsun@orion.mvista.com Mon Jan 20 20:19:57 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 20 Jan 2003 20:19:57 +0000 (GMT)
Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:41970 "EHLO
	orion.mvista.com") by linux-mips.org with ESMTP id <S8225272AbTATUT4>;
	Mon, 20 Jan 2003 20:19:56 +0000
Received: (from jsun@localhost)
	by orion.mvista.com (8.11.6/8.11.6) id h0KKJpr01742;
	Mon, 20 Jan 2003 12:19:51 -0800
Date: Mon, 20 Jan 2003 12:19:51 -0800
From: Jun Sun <jsun@mvista.com>
To: Christoph Hellwig <hch@infradead.org>
Cc: Gilad Benjamini <yaelgilad@myrealbox.com>,
	linux-mips@linux-mips.org, jsun@mvista.com
Subject: Re: Getting Time Difference
Message-ID: <20030120121951.V2100@mvista.com>
References: <ECEPLLMMNGHMFBLHCLMAGEGDDIAA.yaelgilad@myrealbox.com> <20030120115059.U2100@mvista.com> <20030120201531.A6654@infradead.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <20030120201531.A6654@infradead.org>; from hch@infradead.org on Mon, Jan 20, 2003 at 08:15:31PM +0000
Return-Path: <jsun@orion.mvista.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1188
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: jsun@mvista.com
Precedence: bulk
X-list: linux-mips

On Mon, Jan 20, 2003 at 08:15:31PM +0000, Christoph Hellwig wrote:
> On Mon, Jan 20, 2003 at 11:50:59AM -0800, Jun Sun wrote:
> > I assume you are doing this inside kernel for some performance
> > measurement.
> > 
> > In mvsita kernel we introduced an abstraction layer which consists
> > of the following:
> 
> Do you have a pointer to the mvista tree (cvs/tarball/rpm/patch)?
>

I don't think you can freely access it.  Check with our marketing people.
Most of the work though is submitted back to the community, which of course
could take quite a while to show up, or sometimes get rejected and never
show up.

Jun

From hch@infradead.org Mon Jan 20 20:29:41 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 20 Jan 2003 20:29:41 +0000 (GMT)
Received: from phoenix.infradead.org ([IPv6:::ffff:195.224.96.167]:41233 "EHLO
	phoenix.infradead.org") by linux-mips.org with ESMTP
	id <S8225276AbTATU3l>; Mon, 20 Jan 2003 20:29:41 +0000
Received: from hch by phoenix.infradead.org with local (Exim 4.10)
	id 18aiY6-000291-00; Mon, 20 Jan 2003 20:29:38 +0000
Date: Mon, 20 Jan 2003 20:29:38 +0000
From: Christoph Hellwig <hch@infradead.org>
To: Jun Sun <jsun@mvista.com>
Cc: Gilad Benjamini <yaelgilad@myrealbox.com>,
	linux-mips@linux-mips.org
Subject: Re: Getting Time Difference
Message-ID: <20030120202938.A8237@infradead.org>
References: <ECEPLLMMNGHMFBLHCLMAGEGDDIAA.yaelgilad@myrealbox.com> <20030120115059.U2100@mvista.com> <20030120201531.A6654@infradead.org> <20030120121951.V2100@mvista.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5.1i
In-Reply-To: <20030120121951.V2100@mvista.com>; from jsun@mvista.com on Mon, Jan 20, 2003 at 12:19:51PM -0800
Return-Path: <hch@infradead.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1189
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: hch@infradead.org
Precedence: bulk
X-list: linux-mips

On Mon, Jan 20, 2003 at 12:19:51PM -0800, Jun Sun wrote:
> I don't think you can freely access it.  Check with our marketing people.
> Most of the work though is submitted back to the community, which of course
> could take quite a while to show up, or sometimes get rejected and never
> show up.

That's not exactly a nice attitude :P

Maybe there's some mvista customer here who wants to use his/her right to
freely distribute it so I can add it to the other vendor trees at
kernelnewbies.org?


From ppopov@mvista.com Mon Jan 20 20:47:56 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 20 Jan 2003 20:47:56 +0000 (GMT)
Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:11251 "EHLO
	av.mvista.com") by linux-mips.org with ESMTP id <S8225276AbTATUr4>;
	Mon, 20 Jan 2003 20:47:56 +0000
Received: from zeus.mvista.com (av [127.0.0.1])
	by av.mvista.com (8.9.3/8.9.3) with ESMTP id MAA08137;
	Mon, 20 Jan 2003 12:47:09 -0800
Subject: Re: Getting Time Difference
From: Pete Popov <ppopov@mvista.com>
To: Christoph Hellwig <hch@infradead.org>
Cc: Jun Sun <jsun@mvista.com>,
	Gilad Benjamini <yaelgilad@myrealbox.com>,
	linux-mips@linux-mips.org
In-Reply-To: <20030120202938.A8237@infradead.org>
References: <ECEPLLMMNGHMFBLHCLMAGEGDDIAA.yaelgilad@myrealbox.com>
	 <20030120115059.U2100@mvista.com> <20030120201531.A6654@infradead.org>
	 <20030120121951.V2100@mvista.com>  <20030120202938.A8237@infradead.org>
Content-Type: text/plain
Organization: MontaVista Software
Message-Id: <1043095714.3030.94.camel@zeus.mvista.com>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.2.1 
Date: 20 Jan 2003 12:48:34 -0800
Content-Transfer-Encoding: 7bit
Return-Path: <ppopov@mvista.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1190
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ppopov@mvista.com
Precedence: bulk
X-list: linux-mips

On Mon, 2003-01-20 at 12:29, Christoph Hellwig wrote:
> On Mon, Jan 20, 2003 at 12:19:51PM -0800, Jun Sun wrote:
> > I don't think you can freely access it.  Check with our marketing people.
> > Most of the work though is submitted back to the community, which of course
> > could take quite a while to show up, or sometimes get rejected and never
> > show up.
> 
> That's not exactly a nice attitude :P

All of that work is submitted to the community. Jun was talking about
the internal source tree not being freely accessible.

> Maybe there's some mvista customer here who wants to use his/her right to
> freely distribute it so I can add it to the other vendor trees at
> kernelnewbies.org?

I think the fact that it's not in the community tree means that it was
submitted but not accepted. Not everything we do for customers is of
interest to the community at large, which is to be expected, but that's
the main reason why sometimes bits get lost and never make it there.

Pete



From macro@ds2.pg.gda.pl Mon Jan 20 21:47:18 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 20 Jan 2003 21:47:19 +0000 (GMT)
Received: from delta.ds2.pg.gda.pl ([IPv6:::ffff:213.192.72.1]:9158 "EHLO
	delta.ds2.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8225280AbTATVrS>; Mon, 20 Jan 2003 21:47:18 +0000
Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id WAA12617
	for <linux-mips@linux-mips.org>; Mon, 20 Jan 2003 22:47:29 +0100 (MET)
Date: Mon, 20 Jan 2003 22:47:29 +0100 (MET)
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
Reply-To: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To: linux-mips@linux-mips.org
Subject: [CFT] DECstation SCSI driver clean-ups
Message-ID: <Pine.GSO.3.96.1030120172610.4801E-100000@delta.ds2.pg.gda.pl>
Organization: Technical University of Gdansk
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <macro@ds2.pg.gda.pl>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1191
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: macro@ds2.pg.gda.pl
Precedence: bulk
X-list: linux-mips

Hello,

 Testing of the dec_esp.c driver in a 64-bit environment (thanks, Karsten
and Thiemo) uncovered a few incorrect assumptions present in the code
leading to kernel crashes or misoperation.  I decided it's the right
moment to clean the driver up a bit.  Thus I rewrote iomem handling
consistently, adopted the unified I/O ASIC interface, added appropriate
SSR locking and fixed iomem coherency handling.  There are minor fixes
scattered through the code as well. 

 I'm going to commit the changes in a few days, but having no SCSI devices
attached to my DECstations, I cannot test the code at all.  I'd prefer to
avoid a non-working driver in the CVS, so I would appreciate if someone
with a suitable setup could test the new code.  A patch follows.

 The single PMAZ-A limitation of the driver still applies, but it should
be fairly easy to relax in the next step.

  Maciej

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

patch-mips-2.4.20-20030112-dec_esp-ioasic-5
diff -up --recursive --new-file linux-mips-2.4.20-20030112.macro/arch/mips/dec/setup.c linux-mips-2.4.20-20030112/arch/mips/dec/setup.c
--- linux-mips-2.4.20-20030112.macro/arch/mips/dec/setup.c	2002-12-17 03:56:40.000000000 +0000
+++ linux-mips-2.4.20-20030112/arch/mips/dec/setup.c	2003-01-17 01:04:16.000000000 +0000
@@ -16,6 +16,7 @@
 #include <linux/console.h>
 #include <linux/init.h>
 #include <linux/module.h>
+#include <linux/spinlock.h>
 #include <linux/types.h>
 
 #include <asm/cpu.h>
@@ -46,6 +47,8 @@ extern void dec_intr_halt(int irq, void 
 
 extern asmlinkage void decstation_handle_int(void);
 
+spinlock_t ioasic_ssr_lock;
+
 volatile u32 *ioasic_base;
 unsigned long dec_kn_slot_size;
 
diff -up --recursive --new-file linux-mips-2.4.20-20030112.macro/drivers/net/declance.c linux-mips-2.4.20-20030112/drivers/net/declance.c
--- linux-mips-2.4.20-20030112.macro/drivers/net/declance.c	2002-07-25 02:58:09.000000000 +0000
+++ linux-mips-2.4.20-20030112/drivers/net/declance.c	2003-01-17 01:10:59.000000000 +0000
@@ -52,6 +52,7 @@
 #include <linux/module.h>
 #include <linux/netdevice.h>
 #include <linux/etherdevice.h>
+#include <linux/spinlock.h>
 #include <linux/stddef.h>
 #include <linux/string.h>
 
@@ -787,15 +788,23 @@ static int lance_open(struct net_device 
 		return -EAGAIN;
 	}
 	if (lp->dma_irq >= 0) {
+		unsigned long flags;
+
 		if (request_irq(lp->dma_irq, &lance_dma_merr_int, 0,
 				"lance error", dev)) {
 			free_irq(dev->irq, dev);
 			printk("lance: Can't get DMA IRQ %d\n", lp->dma_irq);
 			return -EAGAIN;
 		}
+
+		spin_lock_irqsave(&ioasic_ssr_lock, flags);
+
+		fast_mb();
 		/* Enable I/O ASIC LANCE DMA.  */
-		fast_wmb();
 		ioasic_write(SSR, ioasic_read(SSR) | LANCE_DMA_EN);
+
+		fast_mb();
+		spin_unlock_irqrestore(&ioasic_ssr_lock, flags);
 	}
 
 	status = init_restart_lance(lp);
@@ -821,9 +830,17 @@ static int lance_close(struct net_device
 	writereg(&ll->rdp, LE_C0_STOP);
 
 	if (lp->dma_irq >= 0) {
+		unsigned long flags;
+
+		spin_lock_irqsave(&ioasic_ssr_lock, flags);
+
+		fast_mb();
 		/* Disable I/O ASIC LANCE DMA.  */
 		ioasic_write(SSR, ioasic_read(SSR) & ~LANCE_DMA_EN);
+
 		fast_iob();
+		spin_unlock_irqrestore(&ioasic_ssr_lock, flags);
+
 		free_irq(lp->dma_irq, dev);
 	}
 	free_irq(dev->irq, dev);
diff -up --recursive --new-file linux-mips-2.4.20-20030112.macro/drivers/scsi/dec_esp.c linux-mips-2.4.20-20030112/drivers/scsi/dec_esp.c
--- linux-mips-2.4.20-20030112.macro/drivers/scsi/dec_esp.c	2002-12-04 03:57:01.000000000 +0000
+++ linux-mips-2.4.20-20030112/drivers/scsi/dec_esp.c	2003-01-17 16:04:20.000000000 +0000
@@ -17,6 +17,8 @@
  *            data.
  * 20001005	- Initialization fixes for 2.4.0-test9
  * 			  Florian Lohoff <flo@rfc822.org>
+ *
+ *	Copyright (C) 2002, 2003  Maciej W. Rozycki
  */
 
 #include <linux/kernel.h>
@@ -26,54 +28,48 @@
 #include <linux/slab.h>
 #include <linux/blk.h>
 #include <linux/proc_fs.h>
+#include <linux/spinlock.h>
 #include <linux/stat.h>
 
-#include "scsi.h"
-#include "hosts.h"
-#include "NCR53C9x.h"
-#include "dec_esp.h"
-
-#include <asm/irq.h>
 #include <asm/dma.h>
-
+#include <asm/irq.h>
 #include <asm/pgtable.h>
+#include <asm/system.h>
 
-#include <asm/dec/tc.h>
 #include <asm/dec/interrupts.h>
+#include <asm/dec/ioasic.h>
 #include <asm/dec/ioasic_addrs.h>
 #include <asm/dec/ioasic_ints.h>
 #include <asm/dec/machtype.h>
+#include <asm/dec/tc.h>
+
+#include "scsi.h"
+#include "hosts.h"
+#include "NCR53C9x.h"
+#include "dec_esp.h"
 
-#include <asm/system.h>
 
-/*
- * Once upon a time the pmaz code used to be working but
- * it hasn't been maintained for quite some time.
- * It isn't working anymore but I'll leave here as a
- * starting point. #define this an be prepared for tons
- * of warnings and errors :)
- */
 static int  dma_bytes_sent(struct NCR_ESP *esp, int fifo_count);
 static void dma_drain(struct NCR_ESP *esp);
 static int  dma_can_transfer(struct NCR_ESP *esp, Scsi_Cmnd * sp);
 static void dma_dump_state(struct NCR_ESP *esp);
-static void dma_init_read(struct NCR_ESP *esp, __u32 vaddress, int length);
-static void dma_init_write(struct NCR_ESP *esp, __u32 vaddress, int length);
+static void dma_init_read(struct NCR_ESP *esp, u32 vaddress, int length);
+static void dma_init_write(struct NCR_ESP *esp, u32 vaddress, int length);
 static void dma_ints_off(struct NCR_ESP *esp);
 static void dma_ints_on(struct NCR_ESP *esp);
 static int  dma_irq_p(struct NCR_ESP *esp);
 static int  dma_ports_p(struct NCR_ESP *esp);
-static void dma_setup(struct NCR_ESP *esp, __u32 addr, int count, int write);
+static void dma_setup(struct NCR_ESP *esp, u32 addr, int count, int write);
 static void dma_mmu_get_scsi_one(struct NCR_ESP *esp, Scsi_Cmnd * sp);
 static void dma_mmu_get_scsi_sgl(struct NCR_ESP *esp, Scsi_Cmnd * sp);
 static void dma_advance_sg(Scsi_Cmnd * sp);
 
 static void pmaz_dma_drain(struct NCR_ESP *esp);
-static void pmaz_dma_init_read(struct NCR_ESP *esp, __u32 vaddress, int length);
-static void pmaz_dma_init_write(struct NCR_ESP *esp, __u32 vaddress, int length);
+static void pmaz_dma_init_read(struct NCR_ESP *esp, u32 vaddress, int length);
+static void pmaz_dma_init_write(struct NCR_ESP *esp, u32 vaddress, int length);
 static void pmaz_dma_ints_off(struct NCR_ESP *esp);
 static void pmaz_dma_ints_on(struct NCR_ESP *esp);
-static void pmaz_dma_setup(struct NCR_ESP *esp, __u32 addr, int count, int write);
+static void pmaz_dma_setup(struct NCR_ESP *esp, u32 addr, int count, int write);
 static void pmaz_dma_mmu_get_scsi_one(struct NCR_ESP *esp, Scsi_Cmnd * sp);
 
 #define TC_ESP_RAM_SIZE 0x20000
@@ -84,7 +80,7 @@ static void pmaz_dma_mmu_get_scsi_one(st
 #define TC_ESP_DMAR_WRITE 0x80000000
 #define TC_ESP_DMA_ADDR(x) ((unsigned)(x) & TC_ESP_DMAR_MASK)
 
-__u32 esp_virt_buffer;
+u32 esp_virt_buffer;
 int scsi_current_length;
 
 volatile unsigned char cmd_buffer[16];
@@ -94,13 +90,6 @@ volatile unsigned char pmaz_cmd_buffer[1
 				 * via PIO.
 				 */
 
-volatile unsigned long *scsi_dma_ptr;
-volatile unsigned long *scsi_next_ptr;
-volatile unsigned long *scsi_scr;
-volatile unsigned long *ioasic_ssr;
-volatile unsigned long *scsi_sdr0;
-volatile unsigned long *scsi_sdr1;
-
 static void scsi_dma_merr_int(int, void *, struct pt_regs *);
 static void scsi_dma_err_int(int, void *, struct pt_regs *);
 static void scsi_dma_int(int, void *, struct pt_regs *);
@@ -121,13 +110,6 @@ int dec_esp_detect(Scsi_Host_Template * 
 		esp_dev = 0;
 		esp = esp_allocate(tpnt, (void *) esp_dev);
 
-		scsi_dma_ptr = (unsigned long *) (system_base + IOCTL + SCSI_DMA_P);
-		scsi_next_ptr = (unsigned long *) (system_base + IOCTL + SCSI_DMA_BP);
-		scsi_scr = (unsigned long *) (system_base + IOCTL + SCSI_SCR);
-		ioasic_ssr = (unsigned long *) (system_base + IOCTL + SSR);
-		scsi_sdr0 = (unsigned long *) (system_base + IOCTL + SCSI_SDR0);
-		scsi_sdr1 = (unsigned long *) (system_base + IOCTL + SCSI_SDR1);
-
 		/* Do command transfer with programmed I/O */
 		esp->do_pio_cmds = 1;
 
@@ -174,7 +156,7 @@ int dec_esp_detect(Scsi_Host_Template * 
 		esp->esp_command = (volatile unsigned char *) cmd_buffer;
 
 		/* get virtual dma address for command buffer */
-		esp->esp_command_dvma = (__u32) KSEG1ADDR((volatile unsigned char *) cmd_buffer);
+		esp->esp_command_dvma = virt_to_phys(cmd_buffer);
 
 		esp->irq = dec_interrupt[DEC_IRQ_ASC];
 
@@ -213,7 +195,7 @@ int dec_esp_detect(Scsi_Host_Template * 
 			mem_start = get_tc_base_addr(slot);
 
 			/* Store base addr into esp struct */
-			esp->slot = mem_start;
+			esp->slot = PHYSADDR(mem_start);
 
 			esp->dregs = 0;
 			esp->eregs = (struct ESP_regs *) (mem_start + DEC_SCSI_SREG);
@@ -223,7 +205,7 @@ int dec_esp_detect(Scsi_Host_Template * 
 			esp->esp_command = (volatile unsigned char *) pmaz_cmd_buffer;
 
 			/* get virtual dma address for command buffer */
-			esp->esp_command_dvma = (__u32) KSEG0ADDR((volatile unsigned char *) pmaz_cmd_buffer);
+			esp->esp_command_dvma = virt_to_phys(pmaz_cmd_buffer);
 
 			esp->cfreq = get_tc_speed();
 
@@ -303,40 +285,53 @@ static void scsi_dma_err_int(int irq, vo
 
 static void scsi_dma_int(int irq, void *dev_id, struct pt_regs *regs)
 {
+	u32 scsi_next_ptr;
+
+	scsi_next_ptr = ioasic_read(SCSI_DMA_P);
+
 	/* next page */
-	*scsi_next_ptr = ((*scsi_dma_ptr + PAGE_SIZE) & PAGE_MASK) << 3;
+	scsi_next_ptr = (((scsi_next_ptr >> 3) + PAGE_SIZE) & PAGE_MASK) << 3;
+	ioasic_write(SCSI_DMA_BP, scsi_next_ptr);
 	fast_iob();
 }
 
 static int dma_bytes_sent(struct NCR_ESP *esp, int fifo_count)
 {
-    return fifo_count;
+	return fifo_count;
 }
 
 static void dma_drain(struct NCR_ESP *esp)
 {
-	unsigned long nw = *scsi_scr;
-	unsigned short *p = (unsigned short *)KSEG1ADDR((*scsi_dma_ptr) >> 3);
+	u32 nw, data0, data1, scsi_data_ptr;
+	u16 *p;
+
+	nw = ioasic_read(SCSI_SCR);
 
-    /*
+	/*
 	 * Is there something in the dma buffers left?
-     */
+	 */
 	if (nw) {
+		scsi_data_ptr = ioasic_read(SCSI_DMA_P) >> 3;
+		p = phys_to_virt(scsi_data_ptr);
 		switch (nw) {
 		case 1:
-			*p = (unsigned short) *scsi_sdr0;
+			data0 = ioasic_read(SCSI_SDR0);
+			p[0] = data0 & 0xffff;
 			break;
 		case 2:
-			*p++ = (unsigned short) (*scsi_sdr0);
-			*p = (unsigned short) ((*scsi_sdr0) >> 16);
+			data0 = ioasic_read(SCSI_SDR0);
+			p[0] = data0 & 0xffff;
+			p[1] = (data0 >> 16) & 0xffff;
 			break;
 		case 3:
-			*p++ = (unsigned short) (*scsi_sdr0);
-			*p++ = (unsigned short) ((*scsi_sdr0) >> 16);
-			*p = (unsigned short) (*scsi_sdr1);
+			data0 = ioasic_read(SCSI_SDR0);
+			data1 = ioasic_read(SCSI_SDR1);
+			p[0] = data0 & 0xffff;
+			p[1] = (data0 >> 16) & 0xffff;
+			p[2] = data1 & 0xffff;
 			break;
 		default:
-			printk("Strange: %d words in dma buffer left\n", (int) nw);
+			printk("Strange: %d words in dma buffer left\n", nw);
 			break;
 		}
 	}
@@ -351,38 +346,72 @@ static void dma_dump_state(struct NCR_ES
 {
 }
 
-static void dma_init_read(struct NCR_ESP *esp, __u32 vaddress, int length)
+static void dma_init_read(struct NCR_ESP *esp, u32 vaddress, int length)
 {
+	u32 scsi_next_ptr, ioasic_ssr;
+	unsigned long flags;
+
 	if (vaddress & 3)
 		panic("dec_esp.c: unable to handle partial word transfers, yet...");
 
 	dma_cache_wback_inv((unsigned long) phys_to_virt(vaddress), length);
 
-	*ioasic_ssr &= ~SCSI_DMA_EN;
-	*scsi_scr = 0;
-	*scsi_dma_ptr = vaddress << 3;
+	spin_lock_irqsave(&ioasic_ssr_lock, flags);
+
+	fast_mb();
+	ioasic_ssr = ioasic_read(SSR);
+
+	ioasic_ssr &= ~SCSI_DMA_EN;
+	ioasic_write(SSR, ioasic_ssr);
+
+	fast_wmb();
+	ioasic_write(SCSI_SCR, 0);
+	ioasic_write(SCSI_DMA_P, vaddress << 3);
 
 	/* prepare for next page */
-	*scsi_next_ptr = ((vaddress + PAGE_SIZE) & PAGE_MASK) << 3;
-	*ioasic_ssr |= (SCSI_DMA_DIR | SCSI_DMA_EN);
+	scsi_next_ptr = ((vaddress + PAGE_SIZE) & PAGE_MASK) << 3;
+	ioasic_write(SCSI_DMA_BP, scsi_next_ptr);
+
+	ioasic_ssr |= (SCSI_DMA_DIR | SCSI_DMA_EN);
+	fast_wmb();
+	ioasic_write(SSR, ioasic_ssr);
+
 	fast_iob();
+	spin_unlock_irqrestore(&ioasic_ssr_lock, flags);
 }
 
-static void dma_init_write(struct NCR_ESP *esp, __u32 vaddress, int length)
+static void dma_init_write(struct NCR_ESP *esp, u32 vaddress, int length)
 {
+	u32 scsi_next_ptr, ioasic_ssr;
+	unsigned long flags;
+
 	if (vaddress & 3)
 		panic("dec_esp.c: unable to handle partial word transfers, yet...");
 
 	dma_cache_wback_inv((unsigned long) phys_to_virt(vaddress), length);
 
-	*ioasic_ssr &= ~(SCSI_DMA_DIR | SCSI_DMA_EN);
-	*scsi_scr = 0;
-	*scsi_dma_ptr = vaddress << 3;
+	spin_lock_irqsave(&ioasic_ssr_lock, flags);
+
+	fast_mb();
+	ioasic_ssr = ioasic_read(SSR);
+
+	ioasic_ssr &= ~(SCSI_DMA_DIR | SCSI_DMA_EN);
+	ioasic_write(SSR, ioasic_ssr);
+
+	fast_wmb();
+	ioasic_write(SCSI_SCR, 0);
+	ioasic_write(SCSI_DMA_P, vaddress << 3);
 
 	/* prepare for next page */
-	*scsi_next_ptr = ((vaddress + PAGE_SIZE) & PAGE_MASK) << 3;
-	*ioasic_ssr |= SCSI_DMA_EN;
+	scsi_next_ptr = ((vaddress + PAGE_SIZE) & PAGE_MASK) << 3;
+	ioasic_write(SCSI_DMA_BP, scsi_next_ptr);
+
+	ioasic_ssr |= SCSI_DMA_EN;
+	fast_wmb();
+	ioasic_write(SSR, ioasic_ssr);
+
 	fast_iob();
+	spin_unlock_irqrestore(&ioasic_ssr_lock, flags);
 }
 
 static void dma_ints_off(struct NCR_ESP *esp)
@@ -397,36 +426,32 @@ static void dma_ints_on(struct NCR_ESP *
 
 static int dma_irq_p(struct NCR_ESP *esp)
 {
-    return (esp->eregs->esp_status & ESP_STAT_INTR);
+	return (esp->eregs->esp_status & ESP_STAT_INTR);
 }
 
 static int dma_ports_p(struct NCR_ESP *esp)
 {
-/*
- * FIXME: what's this good for?
- */
+	/*
+	 * FIXME: what's this good for?
+	 */
 	return 1;
 }
 
-static void dma_setup(struct NCR_ESP *esp, __u32 addr, int count, int write)
+static void dma_setup(struct NCR_ESP *esp, u32 addr, int count, int write)
 {
-    /*
-     * On the Sparc, DMA_ST_WRITE means "move data from device to memory"
-     * so when (write) is true, it actually means READ!
-     */
-	if (write) {
-	dma_init_read(esp, addr, count);
-    } else {
-	dma_init_write(esp, addr, count);
-    }
+	/*
+	 * DMA_ST_WRITE means "move data from device to memory"
+	 * so when (write) is true, it actually means READ!
+	 */
+	if (write)
+		dma_init_read(esp, addr, count);
+	else
+		dma_init_write(esp, addr, count);
 }
 
-/*
- * These aren't used yet
- */
 static void dma_mmu_get_scsi_one(struct NCR_ESP *esp, Scsi_Cmnd * sp)
 {
-	sp->SCp.ptr = (char *)PHYSADDR(sp->SCp.buffer);
+	sp->SCp.ptr = (char *)virt_to_phys(sp->request_buffer);
 }
 
 static void dma_mmu_get_scsi_sgl(struct NCR_ESP *esp, Scsi_Cmnd * sp)
@@ -435,32 +460,33 @@ static void dma_mmu_get_scsi_sgl(struct 
 	struct scatterlist *sg = sp->SCp.buffer;
 
 	while (sz >= 0) {
-		sg[sz].dma_address = PHYSADDR(sg[sz].address);
+		sg[sz].dma_address = virt_to_phys(sg[sz].address);
 		sz--;
 	}
-	sp->SCp.ptr = (char *) ((unsigned long) sp->SCp.buffer->dma_address);
+	sp->SCp.ptr = (char *)(sp->SCp.buffer->dma_address);
 }
 
 static void dma_advance_sg(Scsi_Cmnd * sp)
 {
-	sp->SCp.ptr = (char *) ((unsigned long) sp->SCp.buffer->dma_address);
+	sp->SCp.ptr = (char *)(sp->SCp.buffer->dma_address);
 }
 
 static void pmaz_dma_drain(struct NCR_ESP *esp)
 {
-	memcpy((void *) (KSEG0ADDR(esp_virt_buffer)),
-		(void *) ( esp->slot + DEC_SCSI_SRAM + ESP_TGT_DMA_SIZE),
+	memcpy(phys_to_virt(esp_virt_buffer),
+		(void *)KSEG1ADDR(esp->slot + DEC_SCSI_SRAM + ESP_TGT_DMA_SIZE),
 		scsi_current_length);
 }
 
-static void pmaz_dma_init_read(struct NCR_ESP *esp, __u32 vaddress, int length)
+static void pmaz_dma_init_read(struct NCR_ESP *esp, u32 vaddress, int length)
 {
-	volatile int *dmareg = (volatile int *) (esp->slot + DEC_SCSI_DMAREG);
+	volatile u32 *dmareg =
+		(volatile u32 *)KSEG1ADDR(esp->slot + DEC_SCSI_DMAREG);
 
 	if (length > ESP_TGT_DMA_SIZE)
 		length = ESP_TGT_DMA_SIZE;
 
-	*dmareg = TC_ESP_DMA_ADDR(esp->slot + DEC_SCSI_SRAM + ESP_TGT_DMA_SIZE);
+	*dmareg = TC_ESP_DMA_ADDR(ESP_TGT_DMA_SIZE);
 
 	iob();
 
@@ -468,15 +494,16 @@ static void pmaz_dma_init_read(struct NC
 	scsi_current_length = length;
 }
 
-static void pmaz_dma_init_write(struct NCR_ESP *esp, __u32 vaddress, int length)
+static void pmaz_dma_init_write(struct NCR_ESP *esp, u32 vaddress, int length)
 {
-	volatile int *dmareg = (volatile int *) ( esp->slot + DEC_SCSI_DMAREG );
+	volatile u32 *dmareg =
+		(volatile u32 *)KSEG1ADDR(esp->slot + DEC_SCSI_DMAREG);
 
-	memcpy((void *)(esp->slot + DEC_SCSI_SRAM + ESP_TGT_DMA_SIZE),
-	       (void *)KSEG0ADDR(vaddress), length);
+	memcpy((void *)KSEG1ADDR(esp->slot + DEC_SCSI_SRAM + ESP_TGT_DMA_SIZE),
+	       phys_to_virt(vaddress), length);
 
-	*dmareg = TC_ESP_DMAR_WRITE |
-		TC_ESP_DMA_ADDR(esp->slot + DEC_SCSI_SRAM + ESP_TGT_DMA_SIZE);
+	wmb();
+	*dmareg = TC_ESP_DMAR_WRITE | TC_ESP_DMA_ADDR(ESP_TGT_DMA_SIZE);
 
 	iob();
 }
@@ -489,20 +516,19 @@ static void pmaz_dma_ints_on(struct NCR_
 {
 }
 
-static void pmaz_dma_setup(struct NCR_ESP *esp, __u32 addr, int count, int write)
+static void pmaz_dma_setup(struct NCR_ESP *esp, u32 addr, int count, int write)
 {
 	/*
-	 * On the Sparc, DMA_ST_WRITE means "move data from device to memory"
+	 * DMA_ST_WRITE means "move data from device to memory"
 	 * so when (write) is true, it actually means READ!
 	 */
-	if (write) {
+	if (write)
 		pmaz_dma_init_read(esp, addr, count);
-	} else {
+	else
 		pmaz_dma_init_write(esp, addr, count);
-	}
 }
 
 static void pmaz_dma_mmu_get_scsi_one(struct NCR_ESP *esp, Scsi_Cmnd * sp)
 {
-	sp->SCp.ptr = (char *)KSEG0ADDR((sp->request_buffer));
+	sp->SCp.ptr = (char *)virt_to_phys(sp->request_buffer);
 }
diff -up --recursive --new-file linux-mips-2.4.20-20030112.macro/include/asm-mips/dec/ioasic.h linux-mips-2.4.20-20030112/include/asm-mips/dec/ioasic.h
--- linux-mips-2.4.20-20030112.macro/include/asm-mips/dec/ioasic.h	2003-01-16 01:13:18.000000000 +0000
+++ linux-mips-2.4.20-20030112/include/asm-mips/dec/ioasic.h	2003-01-17 00:59:53.000000000 +0000
@@ -3,7 +3,7 @@
  *
  *	DEC I/O ASIC access operations.
  *
- *	Copyright (C) 2000, 2002  Maciej W. Rozycki
+ *	Copyright (C) 2000, 2002, 2003  Maciej W. Rozycki
  *
  *	This program is free software; you can redistribute it and/or
  *	modify it under the terms of the GNU General Public License
@@ -14,8 +14,11 @@
 #ifndef __ASM_DEC_IOASIC_H
 #define __ASM_DEC_IOASIC_H
 
+#include <linux/spinlock.h>
 #include <linux/types.h>
 
+extern spinlock_t ioasic_ssr_lock;
+
 extern volatile u32 *ioasic_base;
 
 static inline void ioasic_write(unsigned int reg, u32 v)
diff -up --recursive --new-file linux-mips-2.4.20-20030112.macro/include/asm-mips64/dec/ioasic.h linux-mips-2.4.20-20030112/include/asm-mips64/dec/ioasic.h
--- linux-mips-2.4.20-20030112.macro/include/asm-mips64/dec/ioasic.h	2002-05-14 02:57:37.000000000 +0000
+++ linux-mips-2.4.20-20030112/include/asm-mips64/dec/ioasic.h	2003-01-17 00:59:53.000000000 +0000
@@ -3,7 +3,7 @@
  *
  *	DEC I/O ASIC access operations.
  *
- *	Copyright (C) 2000, 2002  Maciej W. Rozycki
+ *	Copyright (C) 2000, 2002, 2003  Maciej W. Rozycki
  *
  *	This program is free software; you can redistribute it and/or
  *	modify it under the terms of the GNU General Public License
@@ -14,8 +14,11 @@
 #ifndef __ASM_DEC_IOASIC_H
 #define __ASM_DEC_IOASIC_H
 
+#include <linux/spinlock.h>
 #include <linux/types.h>
 
+extern spinlock_t ioasic_ssr_lock;
+
 extern volatile u32 *ioasic_base;
 
 static inline void ioasic_write(unsigned int reg, u32 v)



From tpolgar@freehandsystems.com Mon Jan 20 22:37:03 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 20 Jan 2003 22:37:04 +0000 (GMT)
Received: from [IPv6:::ffff:66.221.142.1] ([IPv6:::ffff:66.221.142.1]:29596
	"EHLO bisque.propagation.net") by linux-mips.org with ESMTP
	id <S8225282AbTATWhD>; Mon, 20 Jan 2003 22:37:03 +0000
Received: from freehandsystems.com (adsl-64-170-127-190.dsl.snfc21.pacbell.net [64.170.127.190])
	by bisque.propagation.net (8.11.6/8.8.5) with ESMTP id h0KMacM23859;
	Mon, 20 Jan 2003 16:36:38 -0600
Message-ID: <3E2C79F1.DE17268E@freehandsystems.com>
Date: Mon, 20 Jan 2003 14:36:33 -0800
From: Tibor Polgar <tpolgar@freehandsystems.com>
X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
CC: James Simmons <jsimmons@infradead.org>, linux-mips@linux-mips.org
Subject: Re: Is the CVS server down?
References: <Pine.GSO.3.96.1030120205855.4801J-100000@delta.ds2.pg.gda.pl>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Return-Path: <tpolgar@freehandsystems.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1192
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: tpolgar@freehandsystems.com
Precedence: bulk
X-list: linux-mips

>  The server is intentionally down for a while.
> 

CVSWeb is still up so i assume the place isn't down.  

Any chance you can throw a tarball my way then?  I urgently need to sync up
from a 2.4.17 MontaVista release in hopes of getting around an LCD
configuration problem.

If not, then any idea when it will be available again?

Thanks
Tibor

From airlied@csn.ul.ie Mon Jan 20 23:13:44 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 20 Jan 2003 23:13:45 +0000 (GMT)
Received: from holly.csn.ul.ie ([IPv6:::ffff:136.201.105.4]:52136 "EHLO
	holly.csn.ul.ie") by linux-mips.org with ESMTP id <S8225282AbTATXNo>;
	Mon, 20 Jan 2003 23:13:44 +0000
Received: from skynet.csn.ul.ie (skynet [136.201.105.2])
	by holly.csn.ul.ie (Postfix) with ESMTP
	id B59383F4AE; Mon, 20 Jan 2003 23:15:30 +0000 (GMT)
Received: by skynet.csn.ul.ie (Postfix, from userid 2139)
	id 3D05EE959; Mon, 20 Jan 2003 23:13:40 +0000 (GMT)
Received: from localhost (localhost [127.0.0.1])
	by skynet.csn.ul.ie (Postfix) with ESMTP
	id 338207779; Mon, 20 Jan 2003 23:13:40 +0000 (GMT)
Date: Mon, 20 Jan 2003 23:13:40 +0000 (GMT)
From: Dave Airlie <airlied@csn.ul.ie>
X-X-Sender: airlied@skynet
To: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
Cc: linux-mips@linux-mips.org
Subject: Re: [CFT] DECstation SCSI driver clean-ups
In-Reply-To: <Pine.GSO.3.96.1030120172610.4801E-100000@delta.ds2.pg.gda.pl>
Message-ID: <Pine.LNX.4.44.0301202312430.28219-100000@skynet>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <airlied@csn.ul.ie>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1193
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: airlied@csn.ul.ie
Precedence: bulk
X-list: linux-mips


>  I'm going to commit the changes in a few days, but having no SCSI devices
> attached to my DECstations, I cannot test the code at all.  I'd prefer to
> avoid a non-working driver in the CVS, so I would appreciate if someone
> with a suitable setup could test the new code.  A patch follows.
>
>  The single PMAZ-A limitation of the driver still applies, but it should
> be fairly easy to relax in the next step.

can someone try it on a 5000/200 if they have one also .. it's been a long
while since that code was written ... if it works on a PMAZ it'll probably
work on a 5000/200 anyways..

Dave.
>
>

-- 
David Airlie, Software Engineer
http://www.skynet.ie/~airlied / airlied@skynet.ie
pam_smb / Linux DecStation / Linux VAX / ILUG person



From ipv6_san@rediffmail.com Tue Jan 21 04:22:46 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 21 Jan 2003 04:22:47 +0000 (GMT)
Received: from webmail28.rediffmail.com ([IPv6:::ffff:203.199.83.38]:18390
	"HELO rediffmail.com") by linux-mips.org with SMTP
	id <S8225211AbTAUEWq>; Tue, 21 Jan 2003 04:22:46 +0000
Received: (qmail 13494 invoked by uid 510); 21 Jan 2003 04:30:50 -0000
Date: 21 Jan 2003 04:30:50 -0000
Message-ID: <20030121043050.13493.qmail@webmail28.rediffmail.com>
Received: from unknown (194.175.117.86) by rediffmail.com via HTTP; 21 jan 2003 04:30:50 -0000
MIME-Version: 1.0
From: "santosh kumar gowda" <ipv6_san@rediffmail.com>
Reply-To: "santosh kumar gowda" <ipv6_san@rediffmail.com>
To: linux-mips@linux-mips.org
Subject: Linux kernel for MIPS architecture
Content-type: text/plain;
	format=flowed
Content-Disposition: inline
Return-Path: <ipv6_san@rediffmail.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1194
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ipv6_san@rediffmail.com
Precedence: bulk
X-list: linux-mips

Hi,
I want to compile the entire Linux Kernel 2.4.20
for MIPS architecture.
I have mipsel-linux-gcc cross compiler.
Is this cross compiler enough or i need something else..??
Can any one suggest me from where to start with...??
What changes to be made in the Makefile..???

-San



From krishnakumar@naturesoft.net Tue Jan 21 07:00:21 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 21 Jan 2003 08:59:20 +0000 (GMT)
Received: from [IPv6:::ffff:203.145.184.221] ([IPv6:::ffff:203.145.184.221]:53765
	"EHLO naturesoft.net") by linux-mips.org with ESMTP
	id <S8225211AbTAUHAU> convert rfc822-to-8bit; Tue, 21 Jan 2003 07:00:20 +0000
Received: from [192.168.0.15] (helo=krishna.royalchallenge.com)
	by naturesoft.net with esmtp (Exim 3.35 #1)
	id 18asMm-0007BD-00; Tue, 21 Jan 2003 12:28:36 +0530
Content-Type: text/plain;
  charset="iso-8859-1"
From: "Krishnakumar. R" <krishnakumar@naturesoft.net>
Reply-To: krishnakumar@naturesoft.net
To: "santosh kumar gowda" <ipv6_san@rediffmail.com>
Subject: Re: Linux kernel for MIPS architecture
Date: Tue, 21 Jan 2003 12:28:47 +0530
User-Agent: KMail/1.4.1
References: <20030121043050.13493.qmail@webmail28.rediffmail.com>
In-Reply-To: <20030121043050.13493.qmail@webmail28.rediffmail.com>
Cc: linux-mips@linux-mips.org
MIME-Version: 1.0
Content-Transfer-Encoding: 8BIT
Message-Id: <200301211228.47766.krishnakumar@naturesoft.net>
Return-Path: <krishnakumar@naturesoft.net>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1195
X-Approved-By: ralf@linux-mips.org
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: krishnakumar@naturesoft.net
Precedence: bulk
X-list: linux-mips

Hi,

Change the following in the top level makefile

CROSS_COMPILE=mipsel-linux-
ARCH=mips


And change the link 
include/asm
of the top directory to point to
the asm-mips there.


Then try configuring and compiling the kernel
as usual.

Hope this helps
Regards
KK








On Tuesday 21 January 2003 10:00 am, you wrote:
> Hi,
> I want to compile the entire Linux Kernel 2.4.20
> for MIPS architecture.
> I have mipsel-linux-gcc cross compiler.
> Is this cross compiler enough or i need something else..??
> Can any one suggest me from where to start with...??
> What changes to be made in the Makefile..???
>
> -San


From Geert.Uytterhoeven@sonycom.com Tue Jan 21 10:49:49 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 21 Jan 2003 12:03:56 +0000 (GMT)
Received: from mail2.sonytel.be ([IPv6:::ffff:195.0.45.172]:47517 "EHLO
	mail.sonytel.be") by linux-mips.org with ESMTP id <S8225211AbTAUKtt>;
	Tue, 21 Jan 2003 10:49:49 +0000
Received: from vervain.sonytel.be (mail.sonytel.be [10.17.0.27])
	by mail.sonytel.be (8.9.0/8.8.6) with ESMTP id LAA01279;
	Tue, 21 Jan 2003 11:45:16 +0100 (MET)
Date: Tue, 21 Jan 2003 11:45:17 +0100 (MET)
From: Geert Uytterhoeven <geert@linux-m68k.org>
To: "Krishnakumar. R" <krishnakumar@naturesoft.net>
cc: santosh kumar gowda <ipv6_san@rediffmail.com>,
	Linux/MIPS Development <linux-mips@linux-mips.org>
Subject: Re: Linux kernel for MIPS architecture
In-Reply-To: <200301211228.47766.krishnakumar@naturesoft.net>
Message-ID: <Pine.GSO.4.21.0301211143430.24563-100000@vervain.sonytel.be>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <Geert.Uytterhoeven@sonycom.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1196
X-Approved-By: ralf@linux-mips.org
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: geert@linux-m68k.org
Precedence: bulk
X-list: linux-mips

On Tue, 21 Jan 2003, Krishnakumar. R wrote:
> Change the following in the top level makefile
> 
> CROSS_COMPILE=mipsel-linux-
> ARCH=mips

Or always say `make CROSS_COMPILE=mipsel-linux- ARCH=mips' instead of `make'.

> And change the link 
> include/asm
> of the top directory to point to
> the asm-mips there.

Changing the link is not necessay. `make config' will do that for you.

> Then try configuring and compiling the kernel
> as usual.

> On Tuesday 21 January 2003 10:00 am, you wrote:
> > I want to compile the entire Linux Kernel 2.4.20
> > for MIPS architecture.

And most probably you'll want to use the kernel source tree from Linux/MIPS
CVS, not the one on ftp.kernel.org.

Gr{oetje,eeting}s,

						Geert

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

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



From macro@ds2.pg.gda.pl Tue Jan 21 15:59:54 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 21 Jan 2003 15:59:55 +0000 (GMT)
Received: from delta.ds2.pg.gda.pl ([IPv6:::ffff:213.192.72.1]:28379 "EHLO
	delta.ds2.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8225218AbTAUP7y>; Tue, 21 Jan 2003 15:59:54 +0000
Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id QAA29579;
	Tue, 21 Jan 2003 16:59:57 +0100 (MET)
Date: Tue, 21 Jan 2003 16:59:56 +0100 (MET)
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To: Dave Airlie <airlied@csn.ul.ie>
cc: linux-mips@linux-mips.org
Subject: Re: [CFT] DECstation SCSI driver clean-ups
In-Reply-To: <Pine.LNX.4.44.0301202312430.28219-100000@skynet>
Message-ID: <Pine.GSO.3.96.1030121164054.24462D-100000@delta.ds2.pg.gda.pl>
Organization: Technical University of Gdansk
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <macro@ds2.pg.gda.pl>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1197
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: macro@ds2.pg.gda.pl
Precedence: bulk
X-list: linux-mips

On Mon, 20 Jan 2003, Dave Airlie wrote:

> >  The single PMAZ-A limitation of the driver still applies, but it should
> > be fairly easy to relax in the next step.
> 
> can someone try it on a 5000/200 if they have one also .. it's been a long
> while since that code was written ... if it works on a PMAZ it'll probably
> work on a 5000/200 anyways..

 The "discrete" PMAZ-A is identical to the "integrated" one, so if one
works, the other does too.  Changes that affect the PMAZ-A are as follows: 

1. Use bus (physical) addresses everywhere, except when doing PIO copying
between host memory and the board's SRAM. 

2. An additional write barrier is added before triggering board's DMA
transfer from the board's SRAM (a nop for R3k). 

So they are minimal enough for a single run-time check to suffice. 

 Anyway, testing a current kernel on the /200 would be a good thing. 

  Maciej

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


From jsun@orion.mvista.com Tue Jan 21 18:14:45 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 21 Jan 2003 18:14:45 +0000 (GMT)
Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:3316 "EHLO
	orion.mvista.com") by linux-mips.org with ESMTP id <S8224851AbTAUSOp>;
	Tue, 21 Jan 2003 18:14:45 +0000
Received: (from jsun@localhost)
	by orion.mvista.com (8.11.6/8.11.6) id h0LIDcZ16722;
	Tue, 21 Jan 2003 10:13:38 -0800
Date: Tue, 21 Jan 2003 10:13:38 -0800
From: Jun Sun <jsun@mvista.com>
To: Gilad Benjamini <gilad@riverhead.com>
Cc: Gilad Benjamini <yaelgilad@myrealbox.com>,
	linux-mips@linux-mips.org, jsun@mvista.com
Subject: Re: Getting Time Difference
Message-ID: <20030121101338.W2100@mvista.com>
References: <328392AA673C0A49B54DABA457E37DAA08C300@exchange>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <328392AA673C0A49B54DABA457E37DAA08C300@exchange>; from gilad@riverhead.com on Tue, Jan 21, 2003 at 07:48:57AM +0200
Return-Path: <jsun@orion.mvista.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1198
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: jsun@mvista.com
Precedence: bulk
X-list: linux-mips

On Tue, Jan 21, 2003 at 07:48:57AM +0200, Gilad Benjamini wrote:
> > In mvsita kernel we introduced an abstraction layer which consists
> > of the following:
> > 
> > readclock_init()
> > readclock()
> > clock_to_usecs()
> > 
> > For MIPS in general, we use the following implementation:
> > 
> > #define readclock_init()
> > #define readclock(low)   do {                           \
> >         db_assert(mips_cpu.options & MIPS_CPU_COUNTER); \
> >         low = read_32bit_cp0_register(CP0_COUNT);       \
> >         } while (0)     
> > #define clock_to_usecs(clocks) ((clocks) / 
> > ((mips_counter_frequency / 1000000)))
> > 
> 
> Thx.
> How would I go about doing readclock to a 64 bit variable ?
> The 32 bit can wrap around pretty fast in today's processors.
>

This interface is meant for short and precise kernel timing
measurement.  Wraping around once does not cause problem as
long as the elapsed clock cycles is less than 2^32.  That gives 
you about 40 secs max interval on a CPU with 100MHz counter
frequency.

Jun

From earlm@mips.com Tue Jan 21 22:32:36 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 21 Jan 2003 22:32:37 +0000 (GMT)
Received: from mx2.mips.com ([IPv6:::ffff:206.31.31.227]:30183 "EHLO
	mx2.mips.com") by linux-mips.org with ESMTP id <S8225222AbTAUWcg>;
	Tue, 21 Jan 2003 22:32:36 +0000
Received: from newman.mips.com (ns-dmz [206.31.31.225])
	by mx2.mips.com (8.12.5/8.12.5) with ESMTP id h0LMWO67005765
	for <linux-mips@linux-mips.org>; Tue, 21 Jan 2003 14:32:24 -0800 (PST)
Received: from xchange.mips.com (xchange [192.168.20.31])
	by newman.mips.com (8.9.3/8.9.0) with ESMTP id OAA28810
	for <linux-mips@linux-mips.org>; Tue, 21 Jan 2003 14:32:23 -0800 (PST)
Received: by xchange.mips.com with Internet Mail Service (5.5.2653.19)
	id <S30VVV1J>; Tue, 21 Jan 2003 14:30:10 -0800
Message-ID: <0C5F4C7A1E3ED51194E200508B2CE32A01B03295@xchange.mips.com>
From: "Mitchell, Earl" <earlm@mips.com>
To: "'linux-mips@linux-mips.org'" <linux-mips@linux-mips.org>
Subject: 
Date: Tue, 21 Jan 2003 14:30:09 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C2C19C.A7EB9B90"
Return-Path: <earlm@mips.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1199
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: earlm@mips.com
Precedence: bulk
X-list: linux-mips

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C2C19C.A7EB9B90
Content-Type: text/plain;
	charset="iso-8859-1"

subscribe linux-mips
 

------_=_NextPart_001_01C2C19C.A7EB9B90
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">


<meta name=3DProgId content=3DWord.Document>
<meta name=3DGenerator content=3D"Microsoft Word 10">
<meta name=3DOriginator content=3D"Microsoft Word 10">
<link rel=3DFile-List href=3D"cid:filelist.xml@01C2C159.D55DF570">
<!--[if gte mso 9]><xml>
 <o:OfficeDocumentSettings>
  <o:DoNotRelyOnCSS/>
 </o:OfficeDocumentSettings>
</xml><![endif]--><!--[if gte mso 9]><xml>
 <w:WordDocument>
  <w:SpellingState>Clean</w:SpellingState>
  <w:GrammarState>Clean</w:GrammarState>
  <w:DocumentKind>DocumentEmail</w:DocumentKind>
  <w:EnvelopeVis/>
  <w:Compatibility>
   <w:BreakWrappedTables/>
   <w:SnapToGridInCell/>
   <w:WrapTextWithPunct/>
   <w:UseAsianBreakRules/>
  </w:Compatibility>
  <w:BrowserLevel>MicrosoftInternetExplorer4</w:BrowserLevel>
 </w:WordDocument>
</xml><![endif]-->
<style>
<!--
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{mso-style-parent:"";
	margin:0in;
	margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:12.0pt;
	font-family:"Times New Roman";
	mso-fareast-font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;
	text-underline:single;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;
	text-underline:single;}
span.EmailStyle17
	{mso-style-type:personal-compose;
	mso-style-noshow:yes;
	mso-ansi-font-size:10.0pt;
	mso-bidi-font-size:10.0pt;
	font-family:Arial;
	mso-ascii-font-family:Arial;
	mso-hansi-font-family:Arial;
	mso-bidi-font-family:Arial;
	color:windowtext;}
span.SpellE
	{mso-style-name:"";
	mso-spl-e:yes;}
span.GramE
	{mso-style-name:"";
	mso-gram-e:yes;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;
	mso-header-margin:.5in;
	mso-footer-margin:.5in;
	mso-paper-source:0;}
div.Section1
	{page:Section1;}
-->
</style>
<!--[if gte mso 10]>
<style>
 /* Style Definitions */=20
 table.MsoNormalTable
	{mso-style-name:"Table Normal";
	mso-tstyle-rowband-size:0;
	mso-tstyle-colband-size:0;
	mso-style-noshow:yes;
	mso-style-parent:"";
	mso-padding-alt:0in 5.4pt 0in 5.4pt;
	mso-para-margin:0in;
	mso-para-margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:10.0pt;
	font-family:"Times New Roman";}
</style>
<![endif]-->
</head>

<body lang=3DEN-US link=3Dblue vlink=3Dpurple =
style=3D'tab-interval:.5in'>

<div class=3DSection1>

<p class=3DMsoNormal><span class=3DGramE><font size=3D2 =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial'>subscribe</span></font></sp=
an><font
size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial'> <span
class=3DSpellE>linux-mips</span><o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

</div>

</body>

</html>

------_=_NextPart_001_01C2C19C.A7EB9B90--

From jsun@orion.mvista.com Tue Jan 21 22:37:29 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 21 Jan 2003 22:37:30 +0000 (GMT)
Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:61181 "EHLO
	orion.mvista.com") by linux-mips.org with ESMTP id <S8225222AbTAUWh3>;
	Tue, 21 Jan 2003 22:37:29 +0000
Received: (from jsun@localhost)
	by orion.mvista.com (8.11.6/8.11.6) id h0LMbQC17344;
	Tue, 21 Jan 2003 14:37:26 -0800
Date: Tue, 21 Jan 2003 14:37:26 -0800
From: Jun Sun <jsun@mvista.com>
To: linux-mips@linux-mips.org
Cc: jsun@mvista.com
Subject: [RFC & PATCH]  fixing tlb flush race problem on smp
Message-ID: <20030121143726.C16939@mvista.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="AqsLC8rIMeq19msA"
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
Return-Path: <jsun@orion.mvista.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1200
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: jsun@mvista.com
Precedence: bulk
X-list: linux-mips


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


Many of us are aware of a hole in current TLB flushing code that
could cause processes using the same ASID for a SMP machine.

Actually there are several problems:

1) get_new_mmu_context() and following set_entryhi, etc are
not called automically in switch_mm() and active_mm().  If
an IPI happens and request to flush local tlb, bad things happen.

2) if local_flush_tlb_range() and local_flush_tlb_mm() are 
called from an IPI, they may call get_new_mmu_context() which
can bump up the ASID generation number with current active_mm
totally not aware of it.  Bad things will happen later.

3) during the time window after schedule() calling switch_mm()
before switch_to(), current->active_mm may be valid but does
really mean "current->active_mm" anymore.  This is because
the "current" process will soon become "prev".  The real active_mm
is actually "next->active_mm".  Because of this, it is not
enough for those two IPI'ed flushing routines to just check
again current->active_mm.  Long story made short - bad
things will happen.

It turns out that other arches have similar problems and solved
it in various ways.  Unfortunely I like none of them.

Here is one I am pretty happy with.  It is very small and efficient.
And conceptually it is clean too.  We basically keep the semantics
of ->mm and ->active_mm unchanged and only introduce a new bit
to mark which mm is the true owner of mmu hardware on a cpu.

The only downside is that cpu_vm_mask variable does not really
mean "mask for blocking IPI" in this approach.  It actually 
indicates whether current->active_mm is really active or not.  

Tested and passed the notorious fork/malloc test.

Let me know what you think.

Jun


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

diff -Nru link/arch/mips/mm/tlb-sb1.c.orig link/arch/mips/mm/tlb-sb1.c
--- link/arch/mips/mm/tlb-sb1.c.orig	Tue Jan 21 13:54:59 2003
+++ link/arch/mips/mm/tlb-sb1.c	Tue Jan 21 13:58:50 2003
@@ -172,9 +172,13 @@
 			}
 			write_c0_entryhi(oldpid);
 		} else {
-			get_new_mmu_context(mm, cpu);
-			if (mm == current->active_mm)
+			if (mm == current->active_mm) {
+				get_new_mmu_context(mm, cpu);
 				write_c0_entryhi(cpu_asid(cpu, mm));
+			} else {
+				/* drop the current context completely */
+				CPU_CONTEXT(cpu, mm) = 0;
+			}
 		}
 	}
 	__restore_flags(flags);
@@ -258,9 +262,12 @@
 	__save_and_cli(flags);
 	cpu = smp_processor_id();
 	if (cpu_context(cpu, mm) != 0) {
-		get_new_mmu_context(mm, smp_processor_id());
 		if (mm == current->active_mm) {
+			get_new_mmu_context(mm, smp_processor_id());
 			write_c0_entryhi(cpu_asid(cpu, mm));
+		} else {
+			/* drop the current context completely */
+			CPU_CONTEXT(cpu, mm) = 0;
 		}
 	}
 	__restore_flags(flags);
diff -Nru link/include/asm-mips/mmu_context.h.orig link/include/asm-mips/mmu_context.h
--- link/include/asm-mips/mmu_context.h.orig	Tue Jan 21 13:55:43 2003
+++ link/include/asm-mips/mmu_context.h	Tue Jan 21 14:01:19 2003
@@ -89,12 +89,25 @@
 static inline void switch_mm(struct mm_struct *prev, struct mm_struct *next,
                              struct task_struct *tsk, unsigned cpu)
 {
+	unsigned long flags;
+
+	__save_and_cli(flags);
+
 	/* Check if our ASID is of an older version and thus invalid */
 	if ((cpu_context(cpu, next) ^ asid_cache(cpu)) & ASID_VERSION_MASK)
 		get_new_mmu_context(next, cpu);
 
 	write_c0_entryhi(cpu_context(cpu, next));
 	TLBMISS_HANDLER_SETUP_PGD(next->pgd);
+
+	/*
+	 * Mark current->active_mm as not "active" anymore.
+	 * We don't want to mislead possible IPI tlb flush routines.
+	 */
+	clear_bit(cpu, &prev->cpu_vm_mask);
+	set_bit(cpu, &next->cpu_vm_mask);
+
+	__restore_flags(flags);
 }
 
 /*
@@ -112,11 +125,17 @@
 static inline void
 activate_mm(struct mm_struct *prev, struct mm_struct *next)
 {
+	unsigned long flags;
+
+	__save_and_cli(flags);
+
 	/* Unconditionally get a new ASID.  */
 	get_new_mmu_context(next, smp_processor_id());
 
 	write_c0_entryhi(cpu_context(smp_processor_id(), next));
 	TLBMISS_HANDLER_SETUP_PGD(next->pgd);
+	
+	__restore_flags(flags);
 }
 
 #endif /* _ASM_MMU_CONTEXT_H */

--AqsLC8rIMeq19msA--

From clausen@pureza.melbourne.sgi.com Wed Jan 22 07:30:57 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 22 Jan 2003 07:30:58 +0000 (GMT)
Received: from rj.SGI.COM ([IPv6:::ffff:192.82.208.96]:492 "EHLO rj.sgi.com")
	by linux-mips.org with ESMTP id <S8225229AbTAVHa5>;
	Wed, 22 Jan 2003 07:30:57 +0000
Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130])
	by rj.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with SMTP id h0M5V3G8006400
	for <@external-mail-relay.sgi.com:linux-mips@linux-mips.org>; Tue, 21 Jan 2003 21:31:04 -0800
Received: from pureza.melbourne.sgi.com (pureza.melbourne.sgi.com [134.14.55.244]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id SAA21283; Wed, 22 Jan 2003 18:30:53 +1100
Received: from pureza.melbourne.sgi.com (localhost.localdomain [127.0.0.1])
	by pureza.melbourne.sgi.com (8.12.5/8.12.5) with ESMTP id h0M7U6HJ008281;
	Wed, 22 Jan 2003 18:30:06 +1100
Received: (from clausen@localhost)
	by pureza.melbourne.sgi.com (8.12.5/8.12.5/Submit) id h0M7U682008279;
	Wed, 22 Jan 2003 18:30:06 +1100
Date: Wed, 22 Jan 2003 18:30:06 +1100
From: Andrew Clausen <clausen@melbourne.sgi.com>
To: linux-mips@linux-mips.org
Cc: gnb@melbourne.sgi.com
Subject: debian's mips userland on mips64
Message-ID: <20030122073006.GF6262@pureza.melbourne.sgi.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.4i
Return-Path: <clausen@pureza.melbourne.sgi.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1201
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: clausen@melbourne.sgi.com
Precedence: bulk
X-list: linux-mips

Hi all,

I'm playing with Debian on an Origin 200 (aka ip27 - 64-bit mips).
The current setup in the mips64-linux world is 64bit kernel +
32bit userland.  So, a mips64-linux kernel can be mostly run a
mips32-linux userland out of the box.

Unfortunately, this doesn't apply to strace, as this play with
the 64bit kernel's stack (eg: struct pt_regs), which is different in
mips32 and mips64.

So, I guess the solution is to hack (it's ugly as hell already...)
strace to detect and understand the 64 bit stack from a 32 bit
userland?

Cheers,
Andrew


From quintela@mandrakesoft.com Wed Jan 22 07:43:29 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 22 Jan 2003 07:43:29 +0000 (GMT)
Received: from cm19173.red.mundo-r.com ([IPv6:::ffff:213.60.19.173]:8986 "EHLO
	trasno.mitica") by linux-mips.org with ESMTP id <S8225229AbTAVHn2>;
	Wed, 22 Jan 2003 07:43:28 +0000
Received: by trasno.mitica (Postfix, from userid 1001)
	id 04C14B55B; Wed, 22 Jan 2003 08:43:26 +0100 (CET)
To: Jun Sun <jsun@mvista.com>
Cc: linux-mips@linux-mips.org
Subject: Re: [RFC & PATCH]  fixing tlb flush race problem on smp
X-Url: http://people.mandrakesoft.com/~quintela
From: Juan Quintela <quintela@mandrakesoft.com>
In-Reply-To: <20030121143726.C16939@mvista.com> (Jun Sun's message of "Tue,
 21 Jan 2003 14:37:26 -0800")
References: <20030121143726.C16939@mvista.com>
Date: Wed, 22 Jan 2003 08:43:26 +0100
Message-ID: <86bs297hpd.fsf@trasno.mitica>
User-Agent: Gnus/5.090012 (Oort Gnus v0.12) Emacs/21.2.92
 (i386-mandrake-linux-gnu)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Return-Path: <quintela@mandrakesoft.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1202
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: quintela@mandrakesoft.com
Precedence: bulk
X-list: linux-mips

>>>>> "jun" == Jun Sun <jsun@mvista.com> writes:

Hi
        just nickpitting.


jun> +		} else {
jun> +			/* drop the current context completely */
jun> +			CPU_CONTEXT(cpu, mm) = 0;
jun> }
jun> }
jun> __restore_flags(flags);

Perhaps creating a inline function for this, as the code is identical
in both branches?


jun> diff -Nru link/include/asm-mips/mmu_context.h.orig link/include/asm-mips/mmu_context.h
jun> --- link/include/asm-mips/mmu_context.h.orig	Tue Jan 21 13:55:43 2003
jun> +++ link/include/asm-mips/mmu_context.h	Tue Jan 21 14:01:19 2003
jun> @@ -89,12 +89,25 @@
jun> static inline void switch_mm(struct mm_struct *prev, struct mm_struct *next,
jun> struct task_struct *tsk, unsigned cpu)
jun> {
jun> +	unsigned long flags;
jun> +
jun> +	__save_and_cli(flags);

s/__save_and_cli()/local_irq_save()/

jun> +	__restore_flags(flags);

s/__restore_flags()/local_irq_restore()/

Same in the other occurence, please.

Later, Juan.

-- 
In theory, practice and theory are the same, but in practice they 
are different -- Larry McVoy

From hch@taclab54.munich.sgi.com Wed Jan 22 10:31:46 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 22 Jan 2003 10:31:47 +0000 (GMT)
Received: from tolkor.SGI.COM ([IPv6:::ffff:198.149.18.6]:24499 "EHLO
	tolkor.sgi.com") by linux-mips.org with ESMTP id <S8225229AbTAVKbq>;
	Wed, 22 Jan 2003 10:31:46 +0000
Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134])
	by tolkor.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h0MAdZkq025158
	for <linux-mips@linux-mips.org>; Wed, 22 Jan 2003 04:39:36 -0600
Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id EAA17725; Wed, 22 Jan 2003 04:31:33 -0600 (CST)
Received: from taclab54.munich.sgi.com (taclab54.munich.sgi.com [144.253.195.54]) by daisy-e236.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id EAA48958; Wed, 22 Jan 2003 04:31:32 -0600 (CST)
Received: (from hch@localhost)
	by taclab54.munich.sgi.com (8.11.6/8.11.6) id h0MHjed31508;
	Wed, 22 Jan 2003 12:45:40 -0500
Date: Wed, 22 Jan 2003 12:45:40 -0500
From: Christoph Hellwig <hch@sgi.com>
To: Andrew Clausen <clausen@melbourne.sgi.com>
Cc: linux-mips@linux-mips.org, gnb@melbourne.sgi.com
Subject: Re: debian's mips userland on mips64
Message-ID: <20030122124540.A31505@sgi.com>
References: <20030122073006.GF6262@pureza.melbourne.sgi.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5.1i
In-Reply-To: <20030122073006.GF6262@pureza.melbourne.sgi.com>; from clausen@melbourne.sgi.com on Wed, Jan 22, 2003 at 06:30:06PM +1100
Return-Path: <hch@taclab54.munich.sgi.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1203
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: hch@sgi.com
Precedence: bulk
X-list: linux-mips

On Wed, Jan 22, 2003 at 06:30:06PM +1100, Andrew Clausen wrote:
> Hi all,
> 
> I'm playing with Debian on an Origin 200 (aka ip27 - 64-bit mips).
> The current setup in the mips64-linux world is 64bit kernel +
> 32bit userland.  So, a mips64-linux kernel can be mostly run a
> mips32-linux userland out of the box.
> 
> Unfortunately, this doesn't apply to strace, as this play with
> the 64bit kernel's stack (eg: struct pt_regs), which is different in
> mips32 and mips64.
> 
> So, I guess the solution is to hack (it's ugly as hell already...)
> strace to detect and understand the 64 bit stack from a 32 bit
> userland?

I don't think so.  You should rather implement a sys32_ptrace and
reference it in the 32bit syscall vector.  Look at the version in
arch/ia64/ia32/sys_ia32.c for an example.


From ralf@linux-mips.org Wed Jan 22 12:45:21 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 22 Jan 2003 12:45:22 +0000 (GMT)
Received: from p508B799F.dip.t-dialin.net ([IPv6:::ffff:80.139.121.159]:13763
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225229AbTAVMpV>; Wed, 22 Jan 2003 12:45:21 +0000
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.11.6/8.11.6) id h0MCj6J13676;
	Wed, 22 Jan 2003 13:45:06 +0100
Date: Wed, 22 Jan 2003 13:45:06 +0100
From: Ralf Baechle <ralf@linux-mips.org>
To: Christoph Hellwig <hch@sgi.com>
Cc: Andrew Clausen <clausen@melbourne.sgi.com>,
	linux-mips@linux-mips.org, gnb@melbourne.sgi.com
Subject: Re: debian's mips userland on mips64
Message-ID: <20030122134506.A12847@linux-mips.org>
References: <20030122073006.GF6262@pureza.melbourne.sgi.com> <20030122124540.A31505@sgi.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5.1i
In-Reply-To: <20030122124540.A31505@sgi.com>; from hch@sgi.com on Wed, Jan 22, 2003 at 12:45:40PM -0500
Return-Path: <ralf@linux-mips.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1204
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips

On Wed, Jan 22, 2003 at 12:45:40PM -0500, Christoph Hellwig wrote:

> I don't think so.  You should rather implement a sys32_ptrace and
> reference it in the 32bit syscall vector.  Look at the version in
> arch/ia64/ia32/sys_ia32.c for an example.

There is a 32-bit ptrace compatibility syscall already and last I tried
it was working quite well for strace.

  Ralf

From hch@taclab54.munich.sgi.com Wed Jan 22 12:55:21 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 22 Jan 2003 12:55:22 +0000 (GMT)
Received: from [IPv6:::ffff:198.149.18.6] ([IPv6:::ffff:198.149.18.6]:3255
	"EHLO tolkor.sgi.com") by linux-mips.org with ESMTP
	id <S8225229AbTAVMzV>; Wed, 22 Jan 2003 12:55:21 +0000
Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [192.48.203.134])
	by tolkor.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id h0MD3Ckq026605;
	Wed, 22 Jan 2003 07:03:12 -0600
Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id GAA51502; Wed, 22 Jan 2003 06:55:13 -0600 (CST)
Received: from taclab54.munich.sgi.com (taclab54.munich.sgi.com [144.253.195.54]) by daisy-e236.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id GAA03246; Wed, 22 Jan 2003 06:55:11 -0600 (CST)
Received: (from hch@localhost)
	by taclab54.munich.sgi.com (8.11.6/8.11.6) id h0MK9Jn32216;
	Wed, 22 Jan 2003 15:09:19 -0500
Date: Wed, 22 Jan 2003 15:09:19 -0500
From: Christoph Hellwig <hch@sgi.com>
To: Ralf Baechle <ralf@linux-mips.org>
Cc: Christoph Hellwig <hch@sgi.com>,
	Andrew Clausen <clausen@melbourne.sgi.com>,
	linux-mips@linux-mips.org, gnb@melbourne.sgi.com
Subject: Re: debian's mips userland on mips64
Message-ID: <20030122150919.A32202@sgi.com>
References: <20030122073006.GF6262@pureza.melbourne.sgi.com> <20030122124540.A31505@sgi.com> <20030122134506.A12847@linux-mips.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5.1i
In-Reply-To: <20030122134506.A12847@linux-mips.org>; from ralf@linux-mips.org on Wed, Jan 22, 2003 at 01:45:06PM +0100
Return-Path: <hch@taclab54.munich.sgi.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1205
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: hch@sgi.com
Precedence: bulk
X-list: linux-mips

On Wed, Jan 22, 2003 at 01:45:06PM +0100, Ralf Baechle wrote:
> There is a 32-bit ptrace compatibility syscall already and last I tried
> it was working quite well for strace.

Indeed.  Didn't even check whether mips64 has it already implemented..


From lindahl@keyresearch.com Wed Jan 22 21:41:21 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 22 Jan 2003 21:41:22 +0000 (GMT)
Received: from 66-122-194-201.ded.pacbell.net ([IPv6:::ffff:66.122.194.201]:19328
	"EHLO localhost.localdomain") by linux-mips.org with ESMTP
	id <S8225240AbTAVVlV>; Wed, 22 Jan 2003 21:41:21 +0000
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1])
	by localhost.localdomain (8.12.5/8.12.5) with ESMTP id h0MLlbQE001119
	for <linux-mips@linux-mips.org>; Wed, 22 Jan 2003 13:47:38 -0800
Received: (from lindahl@localhost)
	by localhost.localdomain (8.12.5/8.12.5/Submit) id h0MLlbgM001117
	for linux-mips@linux-mips.org; Wed, 22 Jan 2003 13:47:37 -0800
X-Authentication-Warning: localhost.localdomain: lindahl set sender to lindahl@keyresearch.com using -f
Date: Wed, 22 Jan 2003 13:47:36 -0800
From: Greg Lindahl <lindahl@keyresearch.com>
To: linux-mips@linux-mips.org
Subject: Re: debian's mips userland on mips64
Message-ID: <20030122214736.GA1094@wumpus.internal.keyresearch.com>
Mail-Followup-To: linux-mips@linux-mips.org
References: <20030122073006.GF6262@pureza.melbourne.sgi.com> <20030122124540.A31505@sgi.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20030122124540.A31505@sgi.com>
User-Agent: Mutt/1.4i
Return-Path: <lindahl@keyresearch.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1206
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: lindahl@keyresearch.com
Precedence: bulk
X-list: linux-mips

On Wed, Jan 22, 2003 at 12:45:40PM -0500, Christoph Hellwig wrote:

> I don't think so.  You should rather implement a sys32_ptrace and
> reference it in the 32bit syscall vector.  Look at the version in
> arch/ia64/ia32/sys_ia32.c for an example.

This works as long as you aren't doing n32 - at some point we'll have
a mature enough toolchain to do that, and we're going to need to hack
up sys32_ptrace to do the right thing with the bigger fp register file...

-- greg



From gnb@melbourne.sgi.com Thu Jan 23 03:05:52 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 23 Jan 2003 03:05:53 +0000 (GMT)
Received: from rj.SGI.COM ([IPv6:::ffff:192.82.208.96]:42685 "EHLO rj.sgi.com")
	by linux-mips.org with ESMTP id <S8225240AbTAWDFw>;
	Thu, 23 Jan 2003 03:05:52 +0000
Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130])
	by rj.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with SMTP id h0N15uG8012753;
	Wed, 22 Jan 2003 17:05:57 -0800
Received: from melbourne.sgi.com (speed.melbourne.sgi.com [134.14.55.174]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id OAA00592; Thu, 23 Jan 2003 14:05:44 +1100
Message-ID: <3E2F5C08.444341D6@melbourne.sgi.com>
Date: Thu, 23 Jan 2003 14:05:44 +1100
From: Greg Banks <gnb@melbourne.sgi.com>
Organization: SGI Australian Software Group
X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.18-6mdk i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Christoph Hellwig <hch@sgi.com>
CC: Ralf Baechle <ralf@linux-mips.org>,
	Andrew Clausen <clausen@melbourne.sgi.com>,
	linux-mips@linux-mips.org
Subject: Re: debian's mips userland on mips64
References: <20030122073006.GF6262@pureza.melbourne.sgi.com> <20030122124540.A31505@sgi.com> <20030122134506.A12847@linux-mips.org> <20030122150919.A32202@sgi.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Return-Path: <gnb@melbourne.sgi.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1207
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: gnb@melbourne.sgi.com
Precedence: bulk
X-list: linux-mips

Christoph Hellwig wrote:
> 
> On Wed, Jan 22, 2003 at 01:45:06PM +0100, Ralf Baechle wrote:
> > There is a 32-bit ptrace compatibility syscall already and last I tried
> > it was working quite well for strace.
> 
> Indeed.  Didn't even check whether mips64 has it already implemented..

Actually 32bit strace on a 64bit kernel is working *most* of the time, so
there must be a 32bit ptrace syscall which is mostly working.  But...

1.  There is a problem with tracing rt_sigaction() where the signal set
    argument is being misinterpreted either in ptrace or strace.  The
    result is an application buffer overflow in strace which causes it
    to lose track of which processes it's tracing.  This may be entirely
    an strace issue but presumably it doesn't happen on 32bit kernels,
    so the fix (when Andrew figures it out) may require strace to know
    whether it's running on a 64bit kernel.

2.  At some point in the future there may well be 64bit executables which
    we will want to trace with the 32bit strace.  Possibly strace will
    need some sort of modification to dynamically detect whether the
    traced child is 64bit or 32bit.

I'd be very interested to know if anyone's tried running strace on
a mips64 kernel, in particular strace'ing the scp program.

Greg.
-- 
Greg Banks, R&D Software Engineer, SGI Australian Software Group.
I don't speak for SGI.

From ralf@linux-mips.org Thu Jan 23 05:04:25 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 23 Jan 2003 05:04:26 +0000 (GMT)
Received: from p508B6290.dip.t-dialin.net ([IPv6:::ffff:80.139.98.144]:57548
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8224847AbTAWFEZ>; Thu, 23 Jan 2003 05:04:25 +0000
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.11.6/8.11.6) id h0N54Jn20808;
	Thu, 23 Jan 2003 06:04:19 +0100
Date: Thu, 23 Jan 2003 06:04:19 +0100
From: Ralf Baechle <ralf@linux-mips.org>
To: Greg Banks <gnb@melbourne.sgi.com>
Cc: Christoph Hellwig <hch@sgi.com>,
	Andrew Clausen <clausen@melbourne.sgi.com>,
	linux-mips@linux-mips.org
Subject: Re: debian's mips userland on mips64
Message-ID: <20030123060419.B17280@linux-mips.org>
References: <20030122073006.GF6262@pureza.melbourne.sgi.com> <20030122124540.A31505@sgi.com> <20030122134506.A12847@linux-mips.org> <20030122150919.A32202@sgi.com> <3E2F5C08.444341D6@melbourne.sgi.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5.1i
In-Reply-To: <3E2F5C08.444341D6@melbourne.sgi.com>; from gnb@melbourne.sgi.com on Thu, Jan 23, 2003 at 02:05:44PM +1100
Return-Path: <ralf@linux-mips.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1208
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips

On Thu, Jan 23, 2003 at 02:05:44PM +1100, Greg Banks wrote:

> Actually 32bit strace on a 64bit kernel is working *most* of the time, so
> there must be a 32bit ptrace syscall which is mostly working.  But...
> 
> 1.  There is a problem with tracing rt_sigaction() where the signal set
>     argument is being misinterpreted either in ptrace or strace.  The
>     result is an application buffer overflow in strace which causes it
>     to lose track of which processes it's tracing.  This may be entirely
>     an strace issue but presumably it doesn't happen on 32bit kernels,
>     so the fix (when Andrew figures it out) may require strace to know
>     whether it's running on a 64bit kernel.

Strace source is pretty evil ...

> 2.  At some point in the future there may well be 64bit executables which
>     we will want to trace with the 32bit strace.  Possibly strace will
>     need some sort of modification to dynamically detect whether the
>     traced child is 64bit or 32bit.
> 
> I'd be very interested to know if anyone's tried running strace on
> a mips64 kernel, in particular strace'ing the scp program.

[...]
ioctl(2, TCGETS, 0x7fff7858)            = -1 EINVAL (Invalid argument)
rt_sigaction(SIGPIPE, {0x10000000, [], 0x4055f4}, {SIG_DFL}, 16) = 0
pipe([0, 0])                            = 3
pipe([268437928, 721805232])            = 5
pipe([720500616, 2147449192])           = 7
close(3)                                = 0
[...]

  Ralf

From clausen@pureza.melbourne.sgi.com Thu Jan 23 07:18:36 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 23 Jan 2003 07:18:36 +0000 (GMT)
Received: from rj.SGI.COM ([IPv6:::ffff:192.82.208.96]:43230 "EHLO rj.sgi.com")
	by linux-mips.org with ESMTP id <S8224847AbTAWHSg>;
	Thu, 23 Jan 2003 07:18:36 +0000
Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130])
	by rj.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with SMTP id h0N5IbG8031502
	for <@external-mail-relay.sgi.com:linux-mips@linux-mips.org>; Wed, 22 Jan 2003 21:18:37 -0800
Received: from pureza.melbourne.sgi.com (pureza.melbourne.sgi.com [134.14.55.244]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id SAA02259 for <linux-mips@linux-mips.org>; Thu, 23 Jan 2003 18:18:26 +1100
Received: from pureza.melbourne.sgi.com (localhost.localdomain [127.0.0.1])
	by pureza.melbourne.sgi.com (8.12.5/8.12.5) with ESMTP id h0N7Hsws001858
	for <linux-mips@linux-mips.org>; Thu, 23 Jan 2003 18:17:55 +1100
Received: (from clausen@localhost)
	by pureza.melbourne.sgi.com (8.12.5/8.12.5/Submit) id h0N7Hrxf001856
	for linux-mips@linux-mips.org; Thu, 23 Jan 2003 18:17:53 +1100
Date: Thu, 23 Jan 2003 18:17:53 +1100
From: Andrew Clausen <clausen@melbourne.sgi.com>
To: linux-mips@linux-mips.org
Subject: sigset_t32 broken?
Message-ID: <20030123071753.GA996@pureza.melbourne.sgi.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.4i
Return-Path: <clausen@pureza.melbourne.sgi.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1209
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: clausen@melbourne.sgi.com
Precedence: bulk
X-list: linux-mips

Hi all,

Cut&paste from linux/asm/mips64/signal.h:

#define _NSIG           128
#define _NSIG_BPW       64
#define _NSIG_WORDS     (_NSIG / _NSIG_BPW)

typedef struct {
        long sig[_NSIG_WORDS];
} sigset_t;

#define _NSIG32         128
#define _NSIG_BPW32     32
#define _NSIG_WORDS32   (_NSIG32 / _NSIG_BPW32)

typedef struct {
        long sig[_NSIG_WORDS32];
} sigset_t32;



Shouldn't those two long's be replaced with u64 and u32
respectively?  Is the second struct really meant to be twice the
size the first?

Cheers,
Andrew


From vivienc@nerim.net Thu Jan 23 09:59:07 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 23 Jan 2003 09:59:07 +0000 (GMT)
Received: from smtp-102.noc.nerim.net ([IPv6:::ffff:62.4.17.102]:58386 "EHLO
	mallaury.noc.nerim.net") by linux-mips.org with ESMTP
	id <S8224847AbTAWJ7H>; Thu, 23 Jan 2003 09:59:07 +0000
Received: from melkor (vivienc.net1.nerim.net [213.41.134.233])
	by mallaury.noc.nerim.net (Postfix) with ESMTP
	id 0E94462D01; Thu, 23 Jan 2003 10:59:05 +0100 (CET)
Received: from glaurung (helo=localhost)
	by melkor with local-esmtp (Exim 3.36 #1 (Debian))
	id 18be8w-0005tU-00; Thu, 23 Jan 2003 10:59:30 +0100
Date: Thu, 23 Jan 2003 10:59:29 +0100 (CET)
From: Vivien Chappelier <vivienc@nerim.net>
X-Sender: glaurung@melkor
To: Andrew Clausen <clausen@melbourne.sgi.com>
Cc: Ralf Baechle <ralf@oss.sgi.com>, linux-mips@linux-mips.org
Subject: Re: sigset_t32 broken?
In-Reply-To: <20030123071753.GA996@pureza.melbourne.sgi.com>
Message-ID: <Pine.LNX.4.21.0301231044270.22634-100000@melkor>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <vivienc@nerim.net>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1210
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: vivienc@nerim.net
Precedence: bulk
X-list: linux-mips

On Thu, 23 Jan 2003, Andrew Clausen wrote:

> Shouldn't those two long's be replaced with u64 and u32
> respectively?  Is the second struct really meant to be twice the
> size the first?

They should be the same size, otherwise sys32_rt_sigsuspend and
sys32_rt_sigaction will return EINVAL. As the comment says:
/* XXX: Don't preclude handling different sized sigset_t's.  */

I've posted a patch to fix that earlier this month (Monday 13 Jan
2003 "[2.5 PATCH] signal handling").

BTW, anyone working on mips64 2.5 kernel should have a look at my patch
set (http://www.linux-mips.org/~glaurung/O2/linux-2.5.47/patches-2.5.47.tar.gz)
for patches named "linux-mips-*.diff" as they might be relevant for other
machines than just the O2, and the more they are tested the better. A
README is provided to explain briefly what they (try to) fix.

regards,
Vivien.


From Adam_Kiepul@pmc-sierra.com Thu Jan 23 23:19:54 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 23 Jan 2003 23:19:55 +0000 (GMT)
Received: from mother.pmc-sierra.bc.ca ([IPv6:::ffff:216.241.224.12]:7552 "HELO
	mother.pmc-sierra.bc.ca") by linux-mips.org with SMTP
	id <S8224939AbTAWXTy>; Thu, 23 Jan 2003 23:19:54 +0000
Received: (qmail 29282 invoked by uid 104); 23 Jan 2003 23:19:44 -0000
Received: from Adam_Kiepul@pmc-sierra.com by mother by uid 101 with qmail-scanner-1.15 
 (uvscan: v4.1.40/v4244.  Clear:. 
 Processed in 0.441473 secs); 23 Jan 2003 23:19:44 -0000
Received: from unknown (HELO hymir.pmc-sierra.bc.ca) (134.87.114.120)
  by mother.pmc-sierra.bc.ca with SMTP; 23 Jan 2003 23:19:43 -0000
Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251])
	by hymir.pmc-sierra.bc.ca (jason/8.11.6) with ESMTP id h0NNJgQ29516
	for <linux-mips@linux-mips.org>; Thu, 23 Jan 2003 15:19:43 -0800 (PST)
Received: by bby1exi01 with Internet Mail Service (5.5.2656.59)
	id <DCPTRMH7>; Thu, 23 Jan 2003 15:19:42 -0800
Message-ID: <71690137A786F7428FF9670D47CB95ED10DF6F@SJE4EXM01>
From: Adam Kiepul <Adam_Kiepul@pmc-sierra.com>
To: "'linux-mips@linux-mips.org'" <linux-mips@linux-mips.org>
Subject: A question on Linux SMP and cache coherency
Date: Thu, 23 Jan 2003 15:17:25 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2656.59)
Content-Type: text/plain;
	charset="iso-8859-1"
Return-Path: <Adam_Kiepul@pmc-sierra.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1211
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: Adam_Kiepul@pmc-sierra.com
Precedence: bulk
X-list: linux-mips

Hi,

I would really appreciate if anyone could tell me whether Hardware-maintained cache coherency between processors is required for Linux SMP operation.
Thank you very much,

Adam Kiepul


From Adam_Kiepul@pmc-sierra.com Thu Jan 23 23:23:30 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 23 Jan 2003 23:23:31 +0000 (GMT)
Received: from father.pmc-sierra.bc.ca ([IPv6:::ffff:216.241.224.13]:47065
	"HELO father.pmc-sierra.bc.ca") by linux-mips.org with SMTP
	id <S8224939AbTAWXXa>; Thu, 23 Jan 2003 23:23:30 +0000
Received: (qmail 8189 invoked by uid 104); 23 Jan 2003 23:23:19 -0000
Received: from Adam_Kiepul@pmc-sierra.com by father by uid 101 with qmail-scanner-1.15 
 (uvscan: v4.1.40/v4244.  Clear:. 
 Processed in 0.424577 secs); 23 Jan 2003 23:23:19 -0000
Received: from unknown (HELO hymir.pmc-sierra.bc.ca) (134.87.114.120)
  by father.pmc-sierra.bc.ca with SMTP; 23 Jan 2003 23:23:18 -0000
Received: from bby1exi01.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251])
	by hymir.pmc-sierra.bc.ca (jason/8.11.6) with ESMTP id h0NNNIQ01764
	for <linux-mips@linux-mips.org>; Thu, 23 Jan 2003 15:23:18 -0800 (PST)
Received: by bby1exi01 with Internet Mail Service (5.5.2656.59)
	id <DCPTRMLB>; Thu, 23 Jan 2003 15:23:18 -0800
Message-ID: <71690137A786F7428FF9670D47CB95ED10DF71@SJE4EXM01>
From: Adam Kiepul <Adam_Kiepul@pmc-sierra.com>
To: "'linux-mips@linux-mips.org'" <linux-mips@linux-mips.org>
Subject: A question on Linux SMP and cache coherency
Date: Thu, 23 Jan 2003 15:21:01 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2656.59)
Content-Type: text/plain;
	charset="iso-8859-1"
Return-Path: <Adam_Kiepul@pmc-sierra.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1212
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: Adam_Kiepul@pmc-sierra.com
Precedence: bulk
X-list: linux-mips

	Hi,

	I would really appreciate if anyone could tell me whether Hardware-maintained cache coherency between processors is required for Linux SMP operation.
	Thank you very much,

	Adam Kiepul


From kaos@sgi.com Thu Jan 23 23:32:59 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 23 Jan 2003 23:32:59 +0000 (GMT)
Received: from mail.ocs.com.au ([IPv6:::ffff:203.34.97.2]:55046 "HELO
	mail.ocs.com.au") by linux-mips.org with SMTP id <S8224939AbTAWXc7>;
	Thu, 23 Jan 2003 23:32:59 +0000
Received: (qmail 24049 invoked from network); 23 Jan 2003 23:32:48 -0000
Received: from ocs3.intra.ocs.com.au (192.168.255.3)
  by mail.ocs.com.au with SMTP; 23 Jan 2003 23:32:48 -0000
Received: by ocs3.intra.ocs.com.au (Postfix, from userid 16331)
	id C99813000B8; Fri, 24 Jan 2003 10:32:38 +1100 (EST)
Received: from ocs3.intra.ocs.com.au (localhost [127.0.0.1])
	by ocs3.intra.ocs.com.au (Postfix) with ESMTP
	id 12B4D85; Fri, 24 Jan 2003 10:32:37 +1100 (EST)
X-Mailer: exmh version 2.4 06/23/2000 with nmh-1.0.4
From: Keith Owens <kaos@sgi.com>
To: Adam Kiepul <Adam_Kiepul@pmc-sierra.com>
Cc: "'linux-mips@linux-mips.org'" <linux-mips@linux-mips.org>
Subject: Re: A question on Linux SMP and cache coherency 
In-reply-to: Your message of "Thu, 23 Jan 2003 15:21:01 -0800."
             <71690137A786F7428FF9670D47CB95ED10DF71@SJE4EXM01> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Fri, 24 Jan 2003 10:32:31 +1100
Message-ID: <7650.1043364751@ocs3.intra.ocs.com.au>
Return-Path: <kaos@sgi.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1213
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: kaos@sgi.com
Precedence: bulk
X-list: linux-mips

On Thu, 23 Jan 2003 15:21:01 -0800, 
Adam Kiepul <Adam_Kiepul@pmc-sierra.com> wrote:
>	I would really appreciate if anyone could tell me whether Hardware-maintained cache coherency between processors is required for Linux SMP operation.

http://www.uwsg.iu.edu/hypermail/linux/kernel/0007.3/1220.html


From ralf@linux-mips.org Fri Jan 24 01:49:13 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 24 Jan 2003 01:49:14 +0000 (GMT)
Received: from p508B6290.dip.t-dialin.net ([IPv6:::ffff:80.139.98.144]:36827
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225245AbTAXBtB>; Fri, 24 Jan 2003 01:49:01 +0000
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.11.6/8.11.6) id h0O1ms221934;
	Fri, 24 Jan 2003 02:48:54 +0100
Date: Fri, 24 Jan 2003 02:48:54 +0100
From: Ralf Baechle <ralf@linux-mips.org>
To: Vivien Chappelier <vivienc@nerim.net>
Cc: Andrew Clausen <clausen@melbourne.sgi.com>,
	linux-mips@linux-mips.org
Subject: Re: sigset_t32 broken?
Message-ID: <20030124024854.B9031@linux-mips.org>
References: <20030123071753.GA996@pureza.melbourne.sgi.com> <Pine.LNX.4.21.0301231044270.22634-100000@melkor>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5.1i
In-Reply-To: <Pine.LNX.4.21.0301231044270.22634-100000@melkor>; from vivienc@nerim.net on Thu, Jan 23, 2003 at 10:59:29AM +0100
Return-Path: <ralf@linux-mips.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1214
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips

On Thu, Jan 23, 2003 at 10:59:29AM +0100, Vivien Chappelier wrote:

> > Shouldn't those two long's be replaced with u64 and u32
> > respectively?  Is the second struct really meant to be twice the
> > size the first?
> 
> They should be the same size, otherwise sys32_rt_sigsuspend and
> sys32_rt_sigaction will return EINVAL. As the comment says:
> /* XXX: Don't preclude handling different sized sigset_t's.  */
> 
> I've posted a patch to fix that earlier this month (Monday 13 Jan
> 2003 "[2.5 PATCH] signal handling").

Most of what your patch does is undoing an accidental commit of a signal
rework that wasn't yet supposed to go out.

  Ralf

From karsten@excalibur.cologne.de Fri Jan 24 14:09:18 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 24 Jan 2003 14:09:19 +0000 (GMT)
Received: from natsmtp00.webmailer.de ([IPv6:::ffff:192.67.198.74]:49140 "EHLO
	post.webmailer.de") by linux-mips.org with ESMTP
	id <S8225192AbTAXOJS>; Fri, 24 Jan 2003 14:09:18 +0000
Received: from excalibur.cologne.de (pD9E40690.dip.t-dialin.net [217.228.6.144])
	by post.webmailer.de (8.9.3/8.8.7) with ESMTP id PAA08581;
	Fri, 24 Jan 2003 15:08:51 +0100 (MET)
Received: from karsten by excalibur.cologne.de with local (Exim 3.35 #1 (Debian))
	id 18c4c8-0000BN-00; Fri, 24 Jan 2003 15:15:24 +0100
Date: Fri, 24 Jan 2003 15:15:24 +0100
From: Karsten Merker <karsten@excalibur.cologne.de>
To: linux-mips@linux-mips.org
Cc: tom@maisl.net
Subject: [PATCH] Cobalt interrupthandler fix
Message-ID: <20030124141524.GA685@excalibur.cologne.de>
Mail-Followup-To: Karsten Merker <karsten@excalibur.cologne.de>,
	linux-mips@linux-mips.org, tom@maisl.net
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="SkvwRMAIpAhPCcCJ"
Content-Disposition: inline
User-Agent: Mutt/1.3.28i
X-No-Archive: yes
Return-Path: <karsten@excalibur.cologne.de>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1215
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: karsten@excalibur.cologne.de
Precedence: bulk
X-list: linux-mips


--SkvwRMAIpAhPCcCJ
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

Hallo,

the Cobalt NASRaQ (as well as other RaQ models) has the problem of freezing
when there is activity on the serial port and on the ethernet at the same
time. Peter de Schrijver has tracked this down to a bug in the interrupt
handler. The handler currently does not check whether an interrupt is masked
and calls the handling routine for _every_ interrupt, not only for those
that are not masked out currently.

The following patch fixes this. Ralf, could you please apply the fix
to the CVS?

Regards,
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.

--SkvwRMAIpAhPCcCJ
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="cobalt-irqhandler.diff"

diff -Nur linux/arch/mips/cobalt/int-handler.S linux-cobalt/arch/mips/cobalt/int-handler.S
--- linux/arch/mips/cobalt/int-handler.S	Fri Sep 13 21:21:58 2002
+++ linux-cobalt/arch/mips/cobalt/int-handler.S	Tue Dec 31 22:26:18 2002
@@ -30,7 +30,9 @@
 		/*
 		 * Get pending Interrupts
 		 */
-		mfc0	s0,CP0_CAUSE	# get irq mask
+		mfc0	s0,CP0_CAUSE	# get raw irq status
+		mfc0	a0,CP0_STATUS	# get irq mask
+		and	s0,s0,a0	# compute masked irq status
 
 		andi	a0,s0,CAUSEF_IP2	/* Check for Galileo timer */
 		beq	a0,zero,1f

--SkvwRMAIpAhPCcCJ--

From ralf@linux-mips.org Fri Jan 24 14:31:47 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 24 Jan 2003 14:31:48 +0000 (GMT)
Received: from p508B6FCB.dip.t-dialin.net ([IPv6:::ffff:80.139.111.203]:5604
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225192AbTAXObr>; Fri, 24 Jan 2003 14:31:47 +0000
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.11.6/8.11.6) id h0OEVVt13856;
	Fri, 24 Jan 2003 15:31:31 +0100
Date: Fri, 24 Jan 2003 15:31:31 +0100
From: Ralf Baechle <ralf@linux-mips.org>
To: Adam Kiepul <Adam_Kiepul@pmc-sierra.com>
Cc: "'linux-mips@linux-mips.org'" <linux-mips@linux-mips.org>
Subject: Re: A question on Linux SMP and cache coherency
Message-ID: <20030124153131.A13615@linux-mips.org>
References: <71690137A786F7428FF9670D47CB95ED10DF6F@SJE4EXM01>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5.1i
In-Reply-To: <71690137A786F7428FF9670D47CB95ED10DF6F@SJE4EXM01>; from Adam_Kiepul@pmc-sierra.com on Thu, Jan 23, 2003 at 03:17:25PM -0800
Return-Path: <ralf@linux-mips.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1216
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips

On Thu, Jan 23, 2003 at 03:17:25PM -0800, Adam Kiepul wrote:

> I would really appreciate if anyone could tell me whether
> Hardware-maintained cache coherency between processors is required for
> Linux SMP operation.

(Sending just one copy of a posting is sufficient ...)

There have been imho fairly ridiculous attempts at constructing dual-core
SMPs for the use with Linux/MIPS by changing the kernel to 16kB page
size [1] and using write through-caches plus some extra hacks.  Needless
to say the solution is about as stupid as something can be and is probably
going to perform worse than a uniprocessor ...

  Ralf

[1] good idea for other reasons but completly stupid in this context

From hjl@lucon.org Fri Jan 24 18:49:33 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 24 Jan 2003 18:49:35 +0000 (GMT)
Received: from p508B6FCB.dip.t-dialin.net ([IPv6:::ffff:80.139.111.203]:31424
	"EHLO p508B6FCB.dip.t-dialin.net") by linux-mips.org with ESMTP
	id <S8225193AbTAXStd>; Fri, 24 Jan 2003 18:49:33 +0000
Received: from sccrmhc01.attbi.com ([IPv6:::ffff:204.127.202.61]:58820 "EHLO
	sccrmhc01.attbi.com") by ralf.linux-mips.org with ESMTP
	id <S869885AbTAXStb>; Fri, 24 Jan 2003 19:49:31 +0100
Received: from lucon.org (12-234-88-146.client.attbi.com[12.234.88.146])
          by sccrmhc01.attbi.com (sccrmhc01) with ESMTP
          id <2003012418490500100hohjie>; Fri, 24 Jan 2003 18:49:05 +0000
Received: by lucon.org (Postfix, from userid 1000)
	id 220FB2C67E; Fri, 24 Jan 2003 10:49:03 -0800 (PST)
Date: Fri, 24 Jan 2003 10:49:03 -0800
From: "H. J. Lu" <hjl@lucon.org>
To: GNU C Library <libc-alpha@sources.redhat.com>, gcc@gcc.gnu.org,
	Kenneth Albanowski <kjahds@kjahds.com>,
	Mat Hostetter <mat@lcs.mit.edu>, Warner Losh <imp@village.org>,
	linux-mips@linux-mips.org, Ron Guilmette <rfg@monkeys.com>,
	"Polstra; John" <linux-binutils-in@polstra.com>,
	Ralf Baechle <ralf@linux-mips.org>,
	Linas Vepstas <linas@linas.org>,
	Leonard Zubkoff <lnz@dandelion.com>,
	"Steven J. Hill" <sjhill@cotw.com>, linux-gcc@vger.kernel.org
Subject: The Linux binutils 2.13.90.0.18 is rleased
Message-ID: <20030124104903.A26314@lucon.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5.1i
Return-Path: <hjl@lucon.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1217
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: hjl@lucon.org
Precedence: bulk
X-list: linux-mips

This is the beta release of binutils 2.13.90.0.18 for Linux, which is
based on binutils 2003 0121 in CVS on sourecs.redhat.com plus various
changes. It is purely for Linux.

The Linux/mips support is added. You have to use

# rpm --target=[mips|mipsel] -ta binutils-xx.xx.xx.xx.xx.tar.gz

to build it. Or you can read mips/README in the source tree to apply
the mips patches and build it by hand.

FYI, the binutils man pages now are generated from the texinfo files
during the build. As the result, those man pages may be changed for
each build even if you only have done

# ..../configure ...
# make

That means you may have many failures on the man pages when you apply
the binutils diffs next time. Those failures can be safely ignored.
You should remove all those man pages from your source tree by

# find -name *.1 | xargs rm -f
# find -name *.1.rej | xargs rm -f
# find -name *.man | xargs rm -f
# find -name *.man.rej | xargs rm -f

Please report any bugs related to binutils 2.13.90.0.18 to hjl@lucon.org.

For arm-linux targets, there are some important differences in behaviour 
between these tools and binutils 2.9.1.0.x.  The linker emulation name has 
changed from elf32arm{26} to armelf_linux{26}.  Also, the "-p" flag must be 
passed with the linker when working with object files (or static libraries) 
created using older versions of the assembler.  If this flag is omitted the 
linker will silently generate bad output when given old input files.

To get the correct behaviour from gcc, amend the *link section of your specs 
file as follows:

*link:
%{h*} %{version:-v}    %{b} %{Wl,*:%*}    %{static:-Bstatic}    %{shared:-shared}    %{symbolic:-Bsymbolic}    %{rdynamic:-export-dynamic}    %{!dynamic-linker: -dynamic-linker /lib/ld-linux.so.2}    -X    %{mbig-endian:-EB} %{mapcs-26:-m armelf_linux26} %{!mapcs-26:-m armelf_linux} -p


Changes from binutils 2.13.90.0.16:

1. Update from binutils 2003 0121.
2. Fix an ia64 gas bug.
3. Fix some TLS bugs.
4. Fix some ELF/ppc bugs.
5. Fix an ELF/m68k bug.

2. Include /usr/bin/c++filt.
Changes from binutils 2.13.90.0.14:

1. Update from binutils 2002 1126.
2. Include /usr/bin/c++filt.
3. Fix "ld -r" with execption handling.

Changes from binutils 2.13.90.0.10:

1. Update from binutils 2002 1114.
2. Fix ELF/alpha bugs.
3. Fix an ELF/i386 assembler bug.

Changes from binutils 2.13.90.0.4:

1. Update from binutils 2002 1010.
2. More ELF/PPC linker bug fixes.
3. Fix an ELF/alpha linker bug.
4. Fix an ELF/sparc linker bug to support Solaris.
5. More TLS updates.

Changes from binutils 2.13.90.0.3:

1. Update from binutils 2002 0814.
2. Fix symbol versioning bugs for gcc 3.2.
3. Fix mips gas.

Changes from binutils 2.13.90.0.2:

1. Update from binutils 2002 0809.
2. Fix a mips gas compatibility bug.
3. Fix an x86 TLS bfd bug.
4. Fix an x86 PIC gas bug.
5. Improve symbol versioning support.

Changes from binutils 2.12.90.0.15:

1. Update from binutils 2002 0802.
2. Initial support for mips n32 ABI.
3. Fix some x86 TLS bugs.

Changes from binutils 2.12.90.0.14:

1. Update from binutils 2002 0717.
2. Fix an ia64 assembler bug.
3. Fix a symbol versioning bug.
4. You have to upgrade to modutils 2.4.19 or apply the modutils patch
enclosed here in order to support System.map generated by the new nm.

Changes from binutils 2.12.90.0.12:

1. Update from binutils 2002 0627.
2. Fix a linker bug which leads to the incorrect Linux 2.2 kernel.

Changes from binutils 2.12.90.0.11:

1. Update from binutils 2002 0618.
2. Fix a mips assembler bug.

Changes from binutils 2.12.90.0.9:

1. Update from binutils 2002 0608.
2. Fix an ELF/mips SHF_MERGE bug.

Changes from binutils 2.12.90.0.7:

1. Update from binutils 2002 0526.
2. Support "-z muldefs".

Changes from binutils 2.12.90.0.4:

1. Update from binutils 2002 0423.
2. ELF EH frame bug fix.
3. MIPS ELF visibility bug fix.

Changes from binutils 2.12.90.0.3:

1. Update from binutils 2002 0408.
2. Bug fixes for ELF/sparc.
3. Bug fixes for ELF/CRIS.

Changes from binutils 2.12.90.0.1:

1. Update from binutils 2002 0323.
2. Fix linking a.out relocatable files with ELF.
3. Fix a PPC altivec assembler bug.

Changes from binutils 2.11.93.0.2:

1. Update from binutils 2002 0307.
2. Add the .preinit_array/.init_array/.fini_array support.
3. Fix eh_frame.
4. Turn on combreloc by default.
5. Enable gprof for Linux/mips.

Changes from binutils 2.11.92.0.12.3:

1. Update from binutils 2002 0207.
2. Fix a weak symbol alpha linker bug for glibc.
3. More support for gcc 3.1.

Changes from binutils 2.11.92.0.12:

1. Fix a regression in 2.11.92.0.12 when linking with none-ELF object
files.

Changes from binutils 2.11.92.0.10:

1. Update from binutils 2001 1121.
2. Fix a linker symbol version bug for common symbols.
3. Update handling relocations against the discarded sections. You may
need to apply the kernel patch enclosed here to your kernel source. If
you still see things like

drivers/char/char.o(.data+0x46b4): undefined reference to `local symbols in discarded section .text.exit'

in the final kernel link, that means you have compiled a driver into
the kernel which has a reference to the symbol in a discarded section.
Kernel 2.4.17 or above should work fine.

4. Support "-march=xxx -mipsN" for mips gas if they are compatible.

Changes from binutils 2.11.92.0.7:

1. Update from binutils 2001 1021.
2. Fix the ELF/PPC linker.
3. Fix the ELF/cris linker.
4. Fix ELF strip.

Changes from binutils 2.11.92.0.5:

1. Update from binutils 2001 1016.
2. Fix all breakages introduced in 2.11.92.0.12.

Changes from binutils 2.11.90.0.31:

1. Update from binutils 2001 1005.
2. Support gcc 3.1 for ia64.
3. Support prelink for ELF/PPC.
4. Fix an ELF/x86 linker bug for Oracle.
5. Fix a weak symbol bug.
6. Support locale.

Changes from binutils 2.11.90.0.29:

1. Update from binutils 2001 0830.
2. Fix a mips linker bug.

Changes from binutils 2.11.90.0.27:

1. Update from binutils 2001 0827.
2. Fix an alpha assembler bug.
3. Fix an ia64 linker bug.
4. Fix a mips linker bug.
5. Support `-z combreloc|nocombreloc' in linker.

Changes from binutils 2.11.90.0.25:

1. Update from binutils 2001 0810.
2. Fix an x86 linker bug.

Changes from binutils 2.11.90.0.24:

1. Update from binutils 2001 0726.
2. Fix an x86 assembler bug.
3. "make check" in the windres test in binutils may call uudecode. We
are working on it.
4. "make check" fails the windres test in binutils if the i386/pe
is enabled in bfd. Fixed in the next release.
5. "make check" has 2 failures in the ld-selective test in ld on
Linux/alpha. They should be marked xfail. Fixed in the next release.

Changes from binutils 2.11.90.0.23:

1. Update from binutils 2001 0714.
2. Fix Sparc/ElF for Linux/sparc.
3. Fix Alpha/ELF for gcc 3.0.

Changes from binutils 2.11.90.0.19:

1. Update from binutils 2001 0706.
2. Fix objcopy/strip broken by accident.
3. Avoid COPY relocs on ia32.
4. Fix the ia64 assembler.
5. This release may not work on Linux/sparc due to the unaligned
relocation changes, which are not handled by all versions of glibc.
The current glibc in CVS on sourceware should be ok. The last known
working binutils for Linux/sparc is 2.11.90.0.8. We are working on it.

Changes from binutils 2.11.90.0.15:

1. Update from binutils 2001 0620.
2. Fix a static linking the PIC object files on ia32.
3. Add the verion script support for --export-dynamic. It can be used
to selectively export dynamic symbols from the executables.

Changes from binutils 2.11.90.0.8:

1. Update from binutils 2001 0610.
2. Fix a gas bug for gcc 3.0.

Changes from binutils 2.11.90.0.7:

1. Update from binutils 2001 0512.
2. Fix some P/III SSE 2 assembler bugs.
3. Fix DT_NEEDED and symbol version bugs.
4. Support hidden versioned symbols in DSOs.

Changes from binutils 2.11.90.0.6:

1. Update from binutils 2001 0427.
2. Fix the -Bsymbolic bug introduced in binutils 2.11.90.0.5.

Changes from binutils 2.11.90.0.5:

1. Update from binutils 2001 0425.
2. Update "ld --multilib-dir PATH".

Changes from binutils 2.11.90.0.4:

1. Update from binutils 2001 0414.
2. Fix an ia64 assembler bug.
3. Change Linux/MIPS to use the SVR4 MIPS ABI instead of the IRIX ABI.
since there are no supports for the IRIX ABI in glibc. The current
Linux/MIPS targets are elf64-tradlittlemips for little endian MIPS
instead of elf32-littlemips and elf64-tradbigmips for big endian MIPS
instead of elf32-bigmips. Glibc, gcc and kernel may have to be modified
for this change. 

Changes from binutils 2.11.90.0.1:

1. Update from binutils 2001 0401.
2. Fix a gas bug for the gcc from the CVS main trunk. It involves some
changes in gas. I compiled kernel 2.2.18, gcc and glibc under
Linux/ia32. The resulting binaries work fine. 
3. Fix the linker core dump on unsupported ELF binaries.

Changes from binutils 2.10.91.0.4:

1. Update from binutils 2001 0309.

Changes from binutils 2.10.91.0.2:

1. Update from binutils 2001 0223.
2. More ia64 bug fixes.

Changes from binutils 2.10.1.0.7:

1. Update from binutils 2001 0215.
2. More ia64 bug fixes. Support EFI and "ld -relax" on ia64.
3. Fix a weak definition, -Bsymbolic, non-PIC bug for ia32.

Changes from binutils 2.10.1.0.4:

1. Update from binutils 2001 0206.
2. Enable the IA64 support.
3. Now you need to use

# ld --oformat TARGET

instead of

# ld -oformat TARGET

The Linux kernel build may be affected. BTW

# ld --oformat TARGET

should work with all previous releases of binutils.

Changes from binutils 2.10.1.0.2:

1. Update from binutils 2000 1221.

Changes from binutils 2.10.0.33:

1. Update from binutils 2000 1119.
2. It has some symbol versioning related updates.

Changes from binutils 2.10.0.32:

1. Update from binutils 2000 1018.
2. A proper ELF/PPC visibility fix.
3. m68k-a.out is supposed to be fixed.

Changes from binutils 2.10.0.31:

1. Update from binutils 2000 1014.
2. An ELF/PPC weak symbol bug fix.
3. A new linkonce section name approach.
4. m68k-a.out is still broken. To be fixed.

Changes from binutils 2.10.0.29:

1. Update from binutils 2000 1011.
2. Back out the linkonce section name change so that C++ will work.
A different approach is being worked on.
3. m68k-a.out is known to be broken. To be fixed.

Changes from binutils 2.10.0.26:

1. Update from binutils 2000 1008.

Changes from binutils 2.10.0.24:

1. Update from binutils 2000 0907.

Changes from binutils 2.10.0.18:

1. Update from binutils 2000 0823. Fix DT_RPATH/DT_RUNPATH handling.
Fix the ELF/ia32 DSO not compiled with PIC.
2. Try to fix the ELF visibility bug on PPC with glibc 2.2.

Changes from binutils 2.10.0.12:

1. Update from binutils 2000 0720.
2. Fix the DT_NEEDED link bug.
3. Add the new DT_XXXX dynamic tags. Glibc 2.2 will use them at least
on libpthread.so.

Changes from binutils 2.10.0.9:

1. Update from binutils 2000 0701. Fix the parallel build in ld when PE
is enabled.

Changes from binutils 2.9.5.0.46:

1. Update from binutils 2000 0617. The demangler support for the new
g++ ABI. Minor fix for the ELF visibility. Fix linking non-ELF
relocatable object files under ELF with symbol versioning.
2. Support for linking PE relocatable object files under ia32/ELF.

Changes from binutils 2.9.5.0.42:

1. Update from binutils 2000 0604. The ELF visibility attribuite should
work correctly now.
2. The ia32 assembler has changed the way it assembles the "jmp"
instructions to the global symbols. The old assembler will optimize the
jump to the global symbol defined in the same source file so that no
relocation will be used. The new assembler will use relocation for
global jumps. It will mainly affect PIC asm code. The segment like

	.globl  __setjmp
__setjmp:
	...
	jmp __sigsetjmp
	...
	.globl __sigsetjmp
__sigsetjmp:

is no longer PIC safe since "jmp __sigsetjmp" jumps to a global symbol
and relocation will be used. Instead, it can be changed to

	.globl  __setjmp
__setjmp:
	...
	jmp sigsetjmp
	...
	.globl __sigsetjmp
__sigsetjmp:
sigsetjmp:

so that "jmp sigsetjmp" jumps to a local symbol and the new assembler
will optimize out the relocation.

Changes from binutils 2.9.5.0.41:

1. Update from binutils 2000 0512.
2. Add testsuite for ELF visibility.

Changes from binutils 2.9.5.0.37:

1. Update from binutils 2000 0502.
2. Support STV_HIDDEN and STV_INTERNAL.

Changes from binutils 2.9.5.0.35:

1. Update from binutils 2000 0418.
2. Fix an ld demangle style option bug.

Changes from binutils 2.9.5.0.34:

1. Update from binutils 2000 0412. Fix a relocation bug which affects
the Linux kernel compilation.
2. An ELF/PPC linker script update.

Changes from binutils 2.9.5.0.33:

1. Update from binutils 2000 0404. Fix the bug report bug.

Changes from binutils 2.9.5.0.32:

1. Update from binutils 2000 0403. Fix the 16bit ia32 assembler bug.

Changes from binutils 2.9.5.0.31:

1. Update from binutils 2000 0331. Fix the Linux/ARM assembler bug.
2. Fix a Debian assembler security bug.

Changes from binutils 2.9.5.0.29:

1. Update from binutils 2000 0319.
2. An ELF/alpha bug is fixed.

Changes from binutils 2.9.5.0.27:

1. Update from binutils 2000 0301.
2. A demangler bug is fixed.
3. A better fix for undefined symbols with -Bsymbolic when building
shared library.

Changes from binutils 2.9.5.0.24:

1. Update from binutils 2000 0204.
2. Added -taso to linker on alpha.
3. Fixed a -shared -Bsymbolic bug when PIC is not used.

Changes from binutils 2.9.5.0.22:

1. Update from binutils 2000 0113.
2. A symbol version bug is fixed.
3. A -Bsymbolic bug is fixed.

Changes from binutils 2.9.5.0.21:

1. Update from binutils 1999 1202.
2. Remove a MIPS/ELF change.
3. Enable SOM for HPPA.

Changes from binutils 2.9.5.0.19:

1. Update from binutils 1999 1122. An ia32 gas bug is fixed.

Changes from binutils 2.9.5.0.16:

1. Update from binutils 1999 1104.
2. i370 is changed to use EM_S370 and ELFOSABI_LINUX. Update readelf.
3. Fix Compaq's demangler support.

Changes from binutils 2.9.5.0.14:

1. Update from binutils 1999 1012. A gas bug which affects Linux 2.3.21
is fixed.
2. i370 update.
3. The new demangler code. You should use "--style=xxx" to select the
demnangle style instead of "--lang=xxx".

Changes from binutils 2.9.5.0.13:

1. Update from binutils 1999 0925.
2. Fix a -s and linker script bug.

Changes from binutils 2.9.5.0.12:

1. Update from binutils 1999 0922.
2. i370 update.

Changes from binutils 2.9.5.0.11:

1. Update from binutils 1999 0910. It fixed a PIC linker bug on ix86
   and sparc introduced in the last release.
2. i370 update.

Changes from binutils 2.9.5.0.10:

1. Update from binutils 1999 0906. It fixed a PIC linker bug on ix86
   and sparc.
2. Remove elf/hppa since it is WIP.

Changes from binutils 2.9.5.0.8:

1. Update from binutils 1999 0831. It allows spaces around '(' and ')'
   in x86 FP register names.

Changes from binutils 2.9.5.0.7:

1. Update from binutils 1999 0821.
2. Some MIPS changes.

Changes from binutils 2.9.5.0.6:

1. Update from binutils 1999 0813.
2. i370 update.

Changes from binutils 2.9.5.0.5:

1. Update from binutils 1999 0809. An ELF/Sparc ld bug is fixed.

Changes from binutils 2.9.5.0.4:

1. Update from binutils 1999 0806. A Solaris/Sparc gas bug is fixed.
2. Remove mips gas patches from binutils 2.9.1.0.25.

Changes from binutils 2.9.5.0.3:

1. Update from binutils 1999 0801.
2. Support for real mode x86 gcc.

Changes from binutils 2.9.4.0.8:

1. Update from binutils 1999 0719. A libc 5 related bug fix.
2. Fix a typo in mips gas.

Changes from binutils 2.9.4.0.7:

1. Update from binutils 1999 0710. A weak symbol bug

http://egcs.cygnus.com/ml/egcs-bugs/1999-07/msg00129.html

is fixed.

Changes from binutils 2.9.4.0.6:

1. Update from binutils 1999 0626.

Changes from binutils 2.9.4.0.5:

1. Update from binutils 1999 0620.
2. Remove my fwait fix and use the one in cvs.
3. Use "--only-section=section" instead of "--extract-section=section".
   for objcopy.

Changes from binutils 2.9.4.0.4:

1. Update from binutils 1999 0612.
2. Remove various temporary fixes of mine since those bugs are fixed
   now.

Changes from binutils 2.9.4.0.3:

1. Update from binutils 1999 0611.
2. Remove my ELF/Alpha bfd changes.
3. Use the local symbol copy fix in binutils 1999 0611.

Changes from binutils 2.9.4.0.2:

1. Update from binutils 1999 0607.
2. Remove my Sparc hacks.
3. Fix local symbol copy.

Changes from binutils 2.9.4.0.1:

1. Update from binutils 1999 0606.
2. Restore relocation overflow checking in binutils 2.9.1.0.25 so that
   Linux kernel can build.
3. Fix i370 for the new gas.

Changes from binutils 1999 0605:

1. Fix a -Bsymbolic bug for Linux/alpha.
2. Add ELF/i370.
3. Fix 8/16-bit relocations for i386.
4. Add --redefine-sym=old_form=new_form to objcopy.
5. Add "-j section" for objcopy.
6. Fix i386 disassembler for fwait.
7. Fix a Sparc asm bug.
8. Add Ada demangle support.
9. Fix MIPS/ELF bugs.
10. Add some vxworks suppport.
11. Fix a.out assembler.

The file list:

1. binutils-2.13.90.0.18.tar.gz. Source code.
2. binutils-2.13.90.0.16-2.13.90.0.18.diff.gz. Patch against the
   previous beta source code.
3. binutils-2.13.90.0.18-1.i386.rpm. IA-32 binary RPM for RedHat 7.3.

There is no separate source rpm. You can do

# rpm -ta binutils-2.13.90.0.18.tar.gz

to create both binary and source rpms.

The primary sites for the beta Linux binutils are:

1. http://ftp.kernel.org/pub/linux/devel/binutils/

Thanks.


H.J. Lu
hjl@lucon.org
01/24/2003
----
> On Mon, Jul 15, 2002 at 04:35:47PM +0930, Alan Modra wrote:
> > Something you might like to warn about in your next release..
> > 
> > The 2002-07-05 bfd change exposes a bug in modutils.  depmod scans the
> > output of nm for a `?' symbol type when looking for certain symbols.
> > nm used to return `?' for symbols in sections other than some standard
> > sections like .text and .data.  Now, nm returns a better guess as to
> > the symbol type.
> 

No, but it parses System.map, which is generated by nm.  This was in
modutils-2.4.16.  Fix follows.

diff -urp modutils-2.4.16.orig/depmod/depmod.c modutils-2.4.16/depmod/depmod.c
--- modutils-2.4.16.orig/depmod/depmod.c	2002-04-28 17:23:35.000000000 +0930
+++ modutils-2.4.16/depmod/depmod.c	2002-07-15 16:41:20.000000000 +0930
@@ -1060,12 +1060,9 @@ static int addksyms(char *file_syms)
 		if (!isspace(*line))	/* Adressless symbol? */
 			p = strtok(NULL, " \t\n");
 		/* The second word is either the symbol name or a type */
-		if (p && strlen(p) == 1) { /* System.map */
+		if (p && p[0] && !p[1]) { /* System.map */
 			is_mapfile = 1;
-			if (*p != '?')
-				p = NULL;
-			else
-				p = strtok(NULL, " \t\n");
+			p = strtok(NULL, " \t\n");
 		} else { /* /proc/ksyms copy */
 			if (p && strtok(NULL, " \t\n"))
 				p = NULL;
@@ -1083,7 +1080,7 @@ static int addksyms(char *file_syms)
 			if (!isspace(*line))	/* Adressless symbol? */
 				p = strtok(NULL, " \t\n");
 			if (is_mapfile) {
-				if (*p != '?')
+				if (!p || !p[0] || p[1])
 					continue;
 				p = strtok(NULL, " \t\n");
 				/* Sparc has symbols like '.div' that need to be


-- 
Alan Modra
IBM OzLabs - Linux Technology Centre

From ralf@linux-mips.org Sat Jan 25 02:30:07 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 25 Jan 2003 02:30:07 +0000 (GMT)
Received: from p508B6FCB.dip.t-dialin.net ([IPv6:::ffff:80.139.111.203]:5101
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225240AbTAYCaH>; Sat, 25 Jan 2003 02:30:07 +0000
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.11.6/8.11.6) id h0P2Tu024450;
	Sat, 25 Jan 2003 03:29:56 +0100
Date: Sat, 25 Jan 2003 03:29:56 +0100
From: Ralf Baechle <ralf@linux-mips.org>
To: Tibor Polgar <tpolgar@freehandsystems.com>
Cc: linux-mips@linux-mips.org
Subject: Re: Is the CVS server down?
Message-ID: <20030125032956.A23962@linux-mips.org>
References: <3E2C518B.E1596B8B@freehandsystems.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5.1i
In-Reply-To: <3E2C518B.E1596B8B@freehandsystems.com>; from tpolgar@freehandsystems.com on Mon, Jan 20, 2003 at 11:44:11AM -0800
Return-Path: <ralf@linux-mips.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1218
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips

On Mon, Jan 20, 2003 at 11:44:11AM -0800, Tibor Polgar wrote:

> > cvs -d :pserver:cvs@ftp.linux-mips.org:/home/cvs login
> Logging in to :pserver:cvs@ftp.linux-mips.org:2401/home/cvs
> CVS password: 
> cvs [login aborted]: connect to ftp.linux-mips.org(62.254.210.162):2401
> failed: Connection refused
> > 
> 
> Per the website i'm using the password of "cvs" (without quotes).  Is it just
> our site/firewall?

No.  A remote exploitable security hole has been discovered in the cvs
server code so I had to shutdown the server temporarily.  The service is
back since the whole hole has been plugged.

As for firewalls I'd like to mention that linux-mips.org is running with
ECN enabled.  That means sites still running broken firewalls such as
certain versions of the Cisco PIX may experience problems when using
certain linux-mips.org services such as active mode ftp and email.  Time
to upgrade the firewall, fixed versions are out since long and ECN has
become the law ...

  Ralf

From vivienc@nerim.net Sun Jan 26 01:57:33 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 26 Jan 2003 01:57:34 +0000 (GMT)
Received: from smtp-102.nerim.net ([IPv6:::ffff:62.4.16.102]:26381 "EHLO
	kraid.nerim.net") by linux-mips.org with ESMTP id <S8225200AbTAZB5d>;
	Sun, 26 Jan 2003 01:57:33 +0000
Received: from melkor (vivienc.net1.nerim.net [213.41.134.233])
	by kraid.nerim.net (Postfix) with ESMTP
	id 5BA8E40E2B; Sun, 26 Jan 2003 02:57:30 +0100 (CET)
Received: from glaurung (helo=localhost)
	by melkor with local-esmtp (Exim 3.36 #1 (Debian))
	id 18cc3l-00049Z-00; Sun, 26 Jan 2003 02:58:09 +0100
Date: Sun, 26 Jan 2003 02:58:09 +0100 (CET)
From: Vivien Chappelier <vivienc@nerim.net>
X-Sender: glaurung@melkor
To: Ralf Baechle <ralf@oss.sgi.com>
Cc: linux-mips@linux-mips.org
Subject: [PATCH 2.5] FPU
Message-ID: <Pine.LNX.4.21.0301260251300.15950-100000@melkor>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <vivienc@nerim.net>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1219
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: vivienc@nerim.net
Precedence: bulk
X-list: linux-mips

Hi,

	At various places in the 2.5 kernel, the fpu is accessed in
kernel mode with CU1 not set, causing an unexpected exception. This patch
makes sure FPU can be accessed by the kernel, though it may only
be a workaround. Any comment from someone with a better understanding of
the FPU access/context switching code?

Vivien.

--- include/asm-mips64/fpu.h	2002-12-11 20:44:20.000000000 +0100
+++ include/asm-mips64/fpu.h	2002-12-11 21:51:44.000000000 +0100
@@ -109,6 +109,7 @@
 
 static inline void save_fp(struct task_struct *tsk)
 {
+	enable_fpu();
 	if (mips_cpu.options & MIPS_CPU_FPU) 
 		_save_fp(tsk);
 }
--- include/asm-mips/fpu.h	2002-12-11 20:44:20.000000000 +0100
+++ include/asm-mips/fpu.h	2002-12-11 21:51:44.000000000 +0100
@@ -109,6 +109,7 @@
 
 static inline void save_fp(struct task_struct *tsk)
 {
+	enable_fpu();
 	if (mips_cpu.options & MIPS_CPU_FPU) 
 		_save_fp(tsk);
 }
--- arch/mips64/kernel/signal.c	2002-11-09 16:10:14.000000000 +0100
+++ arch/mips64/kernel/signal.c	2003-01-14 01:35:42.000000000 +0100
@@ -162,20 +162,19 @@
 
 	err |= __put_user(current->used_math, &sc->sc_used_math);
 
-	if (!current->used_math)
-		goto out;
+	if (current->used_math) {
+
+		/*
+		 * Save FPU state to signal context.
+		 * Signal handler will "inherit" current FPU state.
+		 */
 
-	/*
-	 * Save FPU state to signal context.  Signal handler will "inherit"
-	 * current FPU state.
-	 */
-	if (!is_fpu_owner()) {
 		own_fpu();
 		restore_fp(current);
+
+		err |= save_fp_context(sc);
 	}
-	err |= save_fp_context(sc);
 
-out:
 	return err;
 }
 
--- arch/mips/kernel/signal.c	2002-11-09 16:10:08.000000000 +0100
+++ arch/mips/kernel/signal.c	2003-01-14 01:36:41.000000000 +0100
@@ -313,20 +313,19 @@
 
 	err |= __put_user(current->used_math, &sc->sc_used_math);
 
-	if (!current->used_math)
-		goto out;
+	if (current->used_math) {
+
+		/* 
+		 * Save FPU state to signal context.
+		 * Signal handler will "inherit" current FPU state.
+		 */
 
-	/* 
-	 * Save FPU state to signal context.  Signal handler will "inherit"
-	 * current FPU state.
-	 */
-	if (!is_fpu_owner()) {
 		own_fpu();
 		restore_fp(current);
+
+		err |= save_fp_context(sc);
 	}
-	err |= save_fp_context(sc);
 
-out:
 	return err;
 }
 
--- arch/mips64/kernel/signal32.c	2002-11-09 16:10:14.000000000 +0100
+++ arch/mips64/kernel/signal32.c	2003-01-14 01:34:52.000000000 +0100
@@ -457,20 +430,19 @@
 
 	err |= __put_user(current->used_math, &sc->sc_used_math);
 
-	if (!current->used_math)
-		goto out;
+	if (current->used_math) {
+
+		/* 
+		 * Save FPU state to signal context.
+		 * Signal handler will "inherit" current FPU state.
+		 */
 
-	/* 
-	 * Save FPU state to signal context.  Signal handler will "inherit"
-	 * current FPU state.
-	 */
-	if (!is_fpu_owner()) {
 		own_fpu();
 		restore_fp(current);
+
+		err |= save_fp_context(sc);
 	}
-	err |= save_fp_context(sc);
 
-out:
 	return err;
 }
 


From vivienc@nerim.net Sun Jan 26 02:10:09 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 26 Jan 2003 02:10:10 +0000 (GMT)
Received: from smtp-102.nerim.net ([IPv6:::ffff:62.4.16.102]:33293 "EHLO
	kraid.nerim.net") by linux-mips.org with ESMTP id <S8225200AbTAZCKJ>;
	Sun, 26 Jan 2003 02:10:09 +0000
Received: from melkor (vivienc.net1.nerim.net [213.41.134.233])
	by kraid.nerim.net (Postfix) with ESMTP
	id 9A8C340E2A; Sun, 26 Jan 2003 03:10:06 +0100 (CET)
Received: from glaurung (helo=localhost)
	by melkor with local-esmtp (Exim 3.36 #1 (Debian))
	id 18ccFy-0004AH-00; Sun, 26 Jan 2003 03:10:46 +0100
Date: Sun, 26 Jan 2003 03:10:46 +0100 (CET)
From: Vivien Chappelier <vivienc@nerim.net>
X-Sender: glaurung@melkor
To: Ralf Baechle <ralf@oss.sgi.com>
Cc: linux-mips@linux-mips.org
Subject: [PATCH 2.5] PCI DMA fixes for non-coherent arch
Message-ID: <Pine.LNX.4.21.0301260303400.15950-100000@melkor>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <vivienc@nerim.net>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1220
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: vivienc@nerim.net
Precedence: bulk
X-list: linux-mips

Hi,

	Here's a patch to fix various bugs in the PCI DMA routines on
non-coherent archs:
	- when unmapped, a buffer should be flushed if PCI_DMA_FROMDEVICE
is set, which is not the opposite of PCI_DMA_TODEVICE (both can be set)
	- on non-coherent archs, DECLARE_PCI_UNMAP_ADDR and friends are
needed, since pci_unmap_{page,single} is not a nop
	- the scatter buffer offset was not added in pci_dma_sync_sg

Vivien.

--- include/asm-mips64/pci.h	2002-10-09 23:12:58.000000000 +0200
+++ include/asm-mips64/pci.h	2002-12-08 13:54:03.000000000 +0100
@@ -24,6 +24,8 @@
 #define PCIBIOS_MIN_IO		0x1000
 #define PCIBIOS_MIN_MEM		0x10000000
 
+struct pci_dev;
+
 static inline void pcibios_set_master(struct pci_dev *dev)
 {
 	/* No special bus mastering setup handling */
@@ -44,6 +46,7 @@
 #include <asm/scatterlist.h>
 #include <linux/string.h>
 #include <asm/io.h>
+#include <linux/pci.h>
 
 #if defined(CONFIG_DDB5074) || defined(CONFIG_DDB5476)
 #undef PCIBIOS_MIN_IO
@@ -52,8 +55,6 @@
 #define PCIBIOS_MIN_MEM		0x1000000
 #endif
 
-struct pci_dev;
-
 /*
  * The PCI address space does equal the physical memory address space.  The
  * networking and block device layers use this boolean for bounce buffer
@@ -141,17 +142,33 @@
 static inline void pci_unmap_single(struct pci_dev *hwdev, dma_addr_t dma_addr,
 				    size_t size, int direction)
 {
+	unsigned long addr;
+
 	if (direction == PCI_DMA_NONE)
 		BUG();
 
-	if (direction != PCI_DMA_TODEVICE) {
-		unsigned long addr;
+	if (direction == PCI_DMA_TODEVICE)
+		return; /* nothing to do */
 
-		addr = baddr_to_bus(hwdev->bus, dma_addr) + PAGE_OFFSET;
-		dma_cache_wback_inv(addr, size);
-	}
+	addr = baddr_to_bus(hwdev->bus, dma_addr) + PAGE_OFFSET;
+	dma_cache_wback_inv(addr, size);
 }
 
+#ifdef CONFIG_NONCOHERENT_IO
+/* pci_unmap_{single,page} is not a nop, thus... */
+#define DECLARE_PCI_UNMAP_ADDR(ADDR_NAME)	\
+	dma_addr_t ADDR_NAME;
+#define DECLARE_PCI_UNMAP_LEN(LEN_NAME)		\
+	__u32 LEN_NAME;
+#define pci_unmap_addr(PTR, ADDR_NAME)			\
+	((PTR)->ADDR_NAME)
+#define pci_unmap_addr_set(PTR, ADDR_NAME, VAL)		\
+	(((PTR)->ADDR_NAME) = (VAL))
+#define pci_unmap_len(PTR, LEN_NAME)			\
+	((PTR)->LEN_NAME)
+#define pci_unmap_len_set(PTR, LEN_NAME, VAL)		\
+	(((PTR)->LEN_NAME) = (VAL))
+#else
 /* pci_unmap_{page,single} is a nop so... */
 #define DECLARE_PCI_UNMAP_ADDR(ADDR_NAME)
 #define DECLARE_PCI_UNMAP_LEN(LEN_NAME)
@@ -159,6 +176,7 @@
 #define pci_unmap_addr_set(PTR, ADDR_NAME, VAL)	do { } while (0)
 #define pci_unmap_len(PTR, LEN_NAME)		(0)
 #define pci_unmap_len_set(PTR, LEN_NAME, VAL)	do { } while (0)
+#endif
 
 /*
  * pci_{map,unmap}_single_page maps a kernel page to a dma_addr_t. identical
@@ -182,15 +200,16 @@
 static inline void pci_unmap_page(struct pci_dev *hwdev, dma_addr_t dma_address,
 				  size_t size, int direction)
 {
+	unsigned long addr;
+
 	if (direction == PCI_DMA_NONE)
 		BUG();
 
-	if (direction != PCI_DMA_TODEVICE) {
-		unsigned long addr;
+	if (direction == PCI_DMA_TODEVICE)
+		return; /* nothing to do */
 
-		addr = baddr_to_bus(hwdev->bus, dma_address) + PAGE_OFFSET;
-		dma_cache_wback_inv(addr, size);
-	}
+	addr = baddr_to_bus(hwdev->bus, dma_address) + PAGE_OFFSET;
+	dma_cache_wback_inv(addr, size);
 }
 
 /*
@@ -301,9 +320,12 @@
 
 	/* Make sure that gcc doesn't leave the empty loop body.  */
 #ifdef CONFIG_NONCOHERENT_IO
-	for (i = 0; i < nelems; i++, sg++)
-		dma_cache_wback_inv((unsigned long)page_address(sg->page),
-		                    sg->length);
+	for (i = 0; i < nelems; i++, sg++) {
+		unsigned long addr;
+
+		addr = (unsigned long) page_address(sg->page);
+		dma_cache_wback_inv(addr + sg->offset, sg->length);
+	}
 #endif
 }
 #endif /* CONFIG_MAPPED_PCI_IO  */
--- include/asm-mips/pci.h	2002-10-09 23:12:58.000000000 +0200
+++ include/asm-mips/pci.h	2002-12-08 13:54:03.000000000 +0100
@@ -24,6 +24,8 @@
 #define PCIBIOS_MIN_IO		0x1000
 #define PCIBIOS_MIN_MEM		0x10000000
 
+struct pci_dev;
+
 static inline void pcibios_set_master(struct pci_dev *dev)
 {
 	/* No special bus mastering setup handling */
@@ -44,6 +46,7 @@
 #include <asm/scatterlist.h>
 #include <linux/string.h>
 #include <asm/io.h>
+#include <linux/pci.h>
 
 #if defined(CONFIG_DDB5074) || defined(CONFIG_DDB5476)
 #undef PCIBIOS_MIN_IO
@@ -52,8 +55,6 @@
 #define PCIBIOS_MIN_MEM		0x1000000
 #endif
 
-struct pci_dev;
-
 /*
  * The PCI address space does equal the physical memory address space.  The
  * networking and block device layers use this boolean for bounce buffer
@@ -141,17 +142,33 @@
 static inline void pci_unmap_single(struct pci_dev *hwdev, dma_addr_t dma_addr,
 				    size_t size, int direction)
 {
+	unsigned long addr;
+
 	if (direction == PCI_DMA_NONE)
 		BUG();
 
-	if (direction != PCI_DMA_TODEVICE) {
-		unsigned long addr;
+	if (direction == PCI_DMA_TODEVICE)
+		return; /* nothing to do */
 
-		addr = baddr_to_bus(hwdev->bus, dma_addr) + PAGE_OFFSET;
-		dma_cache_wback_inv(addr, size);
-	}
+	addr = baddr_to_bus(hwdev->bus, dma_addr) + PAGE_OFFSET;
+	dma_cache_wback_inv(addr, size);
 }
 
+#ifdef CONFIG_NONCOHERENT_IO
+/* pci_unmap_{single,page} is not a nop, thus... */
+#define DECLARE_PCI_UNMAP_ADDR(ADDR_NAME)	\
+	dma_addr_t ADDR_NAME;
+#define DECLARE_PCI_UNMAP_LEN(LEN_NAME)		\
+	__u32 LEN_NAME;
+#define pci_unmap_addr(PTR, ADDR_NAME)			\
+	((PTR)->ADDR_NAME)
+#define pci_unmap_addr_set(PTR, ADDR_NAME, VAL)		\
+	(((PTR)->ADDR_NAME) = (VAL))
+#define pci_unmap_len(PTR, LEN_NAME)			\
+	((PTR)->LEN_NAME)
+#define pci_unmap_len_set(PTR, LEN_NAME, VAL)		\
+	(((PTR)->LEN_NAME) = (VAL))
+#else
 /* pci_unmap_{page,single} is a nop so... */
 #define DECLARE_PCI_UNMAP_ADDR(ADDR_NAME)
 #define DECLARE_PCI_UNMAP_LEN(LEN_NAME)
@@ -159,6 +176,7 @@
 #define pci_unmap_addr_set(PTR, ADDR_NAME, VAL)	do { } while (0)
 #define pci_unmap_len(PTR, LEN_NAME)		(0)
 #define pci_unmap_len_set(PTR, LEN_NAME, VAL)	do { } while (0)
+#endif
 
 /*
  * pci_{map,unmap}_single_page maps a kernel page to a dma_addr_t. identical
@@ -182,15 +200,16 @@
 static inline void pci_unmap_page(struct pci_dev *hwdev, dma_addr_t dma_address,
 				  size_t size, int direction)
 {
+	unsigned long addr;
+
 	if (direction == PCI_DMA_NONE)
 		BUG();
 
-	if (direction != PCI_DMA_TODEVICE) {
-		unsigned long addr;
+	if (direction == PCI_DMA_TODEVICE)
+		return; /* nothing to do */
 
-		addr = baddr_to_bus(hwdev->bus, dma_address) + PAGE_OFFSET;
-		dma_cache_wback_inv(addr, size);
-	}
+	addr = baddr_to_bus(hwdev->bus, dma_address) + PAGE_OFFSET;
+	dma_cache_wback_inv(addr, size);
 }
 
 /*
@@ -301,9 +320,12 @@
 
 	/* Make sure that gcc doesn't leave the empty loop body.  */
 #ifdef CONFIG_NONCOHERENT_IO
-	for (i = 0; i < nelems; i++, sg++)
-		dma_cache_wback_inv((unsigned long)page_address(sg->page),
-		                    sg->length);
+	for (i = 0; i < nelems; i++, sg++) {
+		unsigned long addr;
+
+		addr = (unsigned long) page_address(sg->page);
+		dma_cache_wback_inv(addr + sg->offset, sg->length);
+	}
 #endif
 }
 #endif /* CONFIG_MAPPED_PCI_IO  */


From lindahl@keyresearch.com Sun Jan 26 03:35:54 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 26 Jan 2003 03:35:55 +0000 (GMT)
Received: from 12-234-88-56.client.attbi.com ([IPv6:::ffff:12.234.88.56]:61328
	"EHLO localhost.localdomain") by linux-mips.org with ESMTP
	id <S8225200AbTAZDfy>; Sun, 26 Jan 2003 03:35:54 +0000
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1])
	by localhost.localdomain (8.12.5/8.12.5) with ESMTP id h0Q3ZUOf004377
	for <linux-mips@linux-mips.org>; Sat, 25 Jan 2003 19:35:30 -0800
Received: (from lindahl@localhost)
	by localhost.localdomain (8.12.5/8.12.5/Submit) id h0Q3ZTBb004375
	for linux-mips@linux-mips.org; Sat, 25 Jan 2003 19:35:29 -0800
X-Authentication-Warning: localhost.localdomain: lindahl set sender to lindahl@keyresearch.com using -f
Date: Sat, 25 Jan 2003 19:35:29 -0800
From: Greg Lindahl <lindahl@keyresearch.com>
To: linux-mips@linux-mips.org
Subject: Re: [PATCH 2.5] FPU
Message-ID: <20030126033529.GA4296@greglaptop.attbi.com>
Mail-Followup-To: linux-mips@linux-mips.org
References: <Pine.LNX.4.21.0301260251300.15950-100000@melkor>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Pine.LNX.4.21.0301260251300.15950-100000@melkor>
User-Agent: Mutt/1.4i
Return-Path: <lindahl@keyresearch.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1221
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: lindahl@keyresearch.com
Precedence: bulk
X-list: linux-mips

On Sun, Jan 26, 2003 at 02:58:09AM +0100, Vivien Chappelier wrote:

> 	At various places in the 2.5 kernel, the fpu is accessed in
> kernel mode with CU1 not set, causing an unexpected exception.

Vivien,

One good way to start with 2.5 bugs is to compare the code to the 2.4
kernel. Often you can see places where bugs were fixed in 2.4 but the
fixes were not also made to the equivalent 2.5 code. This will keep
2.4 and 2.5 as close as possible, just like we want to keep the 64-bit
and 32-bit kernels as close as possible.

-- greg

From agx@sigxcpu.org Sun Jan 26 22:00:47 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 26 Jan 2003 22:00:48 +0000 (GMT)
Received: from honk1.physik.uni-konstanz.de ([IPv6:::ffff:134.34.144.71]:43719
	"EHLO honk1.physik.uni-konstanz.de") by linux-mips.org with ESMTP
	id <S8225209AbTAZWAr>; Sun, 26 Jan 2003 22:00:47 +0000
Received: from bogon.sigxcpu.org (kons-d9bb5466.pool.mediaWays.net [217.187.84.102])
	by honk1.physik.uni-konstanz.de (Postfix) with ESMTP
	id 3E0AB2BC2E; Sun, 26 Jan 2003 23:00:44 +0100 (CET)
Received: by bogon.sigxcpu.org (Postfix, from userid 1000)
	id 76B4F4B9AC; Sun, 26 Jan 2003 22:59:42 +0100 (CET)
Date: Sun, 26 Jan 2003 22:59:42 +0100
From: Guido Guenther <agx@sigxcpu.org>
To: gcc@gcc.gnu.org
Cc: linux-mips@linux-mips.org
Subject: optimizer problem in linux-mips gcc-3.2?
Message-ID: <20030126215942.GD14230@bogon.ms20.nix>
Mail-Followup-To: Guido Guenther <agx@sigxcpu.org>, gcc@gcc.gnu.org,
	linux-mips@linux-mips.org
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="jRHKVT23PllUwdXP"
Content-Disposition: inline
User-Agent: Mutt/1.4i
Return-Path: <agx@sigxcpu.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1222
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: agx@sigxcpu.org
Precedence: bulk
X-list: linux-mips


--jRHKVT23PllUwdXP
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

Hi,
glibc's string/tester and string/inl-tester fail when compiled with
Debian's "gcc version 3.2.2 20030109 (Debian prerelease)" on linux-mips
(big endian) and -O2 or -Os. I've tried to strip down the testcase as
far as possible and suspect that gcc miscompiles it. It works fine with
Debian's "gcc version 2.95.4 20011002" and with the above gcc-3.2.2 and
optimations turned off, -O3 and -O1:

foo@bar:~$ gcc --save-temps -O2 tester.c && ./a.out
memccpy flunked test 8
0x10000100 is abcdefghr should be abcdefgh
1 errors.

foo@bar:~$ gcc --save-temps -Os tester.c && ./a.out 
memccpy flunked test 8
0x10000100 is abcdefghr should be abcdefgh
1 errors.

foo@bar:~$ gcc --save-temps -O3 tester.c && ./a.out 
0x10000100 is abcdefgh should be abcdefgh
No errors.

foo@bar:~$ gcc --save-temps -O0 tester.c && ./a.out 
0x10000100 is abcdefgh should be abcdefgh
No errors.

foo@bar:~$ gcc -O1 tester.c && ./a.out 
0x100000f0 is abcdefgh should be abcdefgh
No errors.

I've attache the testcase and the assembler output for -O2. Any help
greatly appreciated.
Regards,
 -- Guido

--jRHKVT23PllUwdXP
Content-Type: text/x-csrc; charset=us-ascii
Content-Disposition: attachment; filename="tester.c"

#ifndef _GNU_SOURCE
#define _GNU_SOURCE
#endif

/* Make sure we don't test the optimized inline functions if we want to
   test the real implementation.  */
#if !defined DO_STRING_INLINES
#undef __USE_STRING_INLINES
#endif

#include <errno.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>

#ifndef HAVE_GNU_LD
#define _sys_nerr	sys_nerr
#define _sys_errlist	sys_errlist
#endif

#define	STREQ(a, b)	(strcmp((a), (b)) == 0)

const char *it = "memccpy";	/* Routine name for message routines. */
size_t errors = 0;

/* Complain if condition is not true.  */
static void
check (int thing, int number)
{
  if (!thing)
    {
      printf("flunked test %d\n", number);
      ++errors;
    }
}

/* Complain if first two args don't strcmp as equal.  */
static void
equal (const char *a, const char *b, int number)
{
  check(a != NULL && b != NULL && STREQ (a, b), number);
}

char one[50];
char two[50];

static void
test_memccpy (void)
{
  (void) strcpy(one, "abcdefgh");
  (void) strcpy(two, "horsefeathers");
  check(memccpy(two, one, 'f', 9) == two+6, 7);	/* Returned value. */
  equal(one, "abcdefgh", 8);		/* Source intact? */
  printf("%p is %s should be abcdefgh\n", one, one);
  equal(two, "abcdefeathers", 9);		/* Copy correct? */
}

int
main (void)
{
  int status;

  /* memccpy.  */
  test_memccpy ();

  if (errors == 0)
    {
      status = EXIT_SUCCESS;
      puts("No errors.");
    }
  else
    {
      status = EXIT_FAILURE;
      printf("%Zd errors.\n", errors);
    }

  return status;
}

--jRHKVT23PllUwdXP
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="tester-O2.s"

	.file	1 "tester.c"
	.section .mdebug.abi32
	.previous
	.abicalls
	.globl	it
	.rdata
	.align	2
$LC0:
	.ascii	"memccpy\000"
	.data
	.align	2
	.type	it,@object
	.size	it,4
it:
	.word	$LC0
	.globl	errors
	.align	2
	.type	errors,@object
	.size	errors,4
errors:
	.word	0
	.rdata
	.align	2
$LC1:
	.ascii	"flunked test %d\n\000"
	.text
	.align	2
	.ent	check
		.type		 check,@function
check:
	.frame	$sp,32,$31		# vars= 0, regs= 2/0, args= 16, extra= 8
	.mask	0x90000000,-4
	.fmask	0x00000000,0
	.set	noreorder
	.cpload	$25
	.set	reorder
	subu	$sp,$sp,32
	.cprestore 16
	move	$2,$4
	sw	$31,28($sp)
	la	$4,$LC1
	.set	noreorder
	.set	nomacro
	beq	$2,$0,$L3
	sw	$28,24($sp)
	.set	macro
	.set	reorder

$L1:
	lw	$31,28($sp)
	#nop
	.set	noreorder
	.set	nomacro
	j	$31
	addu	$sp,$sp,32
	.set	macro
	.set	reorder

$L3:
	la	$25,printf
	jal	$31,$25
	lw	$3,errors
	#nop
	addu	$3,$3,1
	sw	$3,errors
	j	$L1
	.end	check
	.align	2
	.ent	equal
		.type		 equal,@function
equal:
	.frame	$sp,40,$31		# vars= 0, regs= 4/0, args= 16, extra= 8
	.mask	0x90030000,-4
	.fmask	0x00000000,0
	.set	noreorder
	.cpload	$25
	.set	reorder
	subu	$sp,$sp,40
	.cprestore 16
	sw	$17,28($sp)
	sw	$16,24($sp)
	sw	$31,36($sp)
	sw	$28,32($sp)
	move	$17,$6
	.set	noreorder
	.set	nomacro
	beq	$4,$0,$L5
	move	$16,$0
	.set	macro
	.set	reorder

	beq	$5,$0,$L5
	la	$25,strcmp
	jal	$31,$25
	.set	noreorder
	.set	nomacro
	bne	$2,$0,$L6
	move	$4,$16
	.set	macro
	.set	reorder

	li	$16,1			# 0x1
$L5:
	move	$4,$16
$L6:
	move	$5,$17
	la	$25,check
	jal	$31,$25
	lw	$31,36($sp)
	lw	$17,28($sp)
	lw	$16,24($sp)
	#nop
	.set	noreorder
	.set	nomacro
	j	$31
	addu	$sp,$sp,40
	.set	macro
	.set	reorder

	.end	equal
	.rdata
	.align	2
$LC2:
	.ascii	"abcdefgh\000"
	.align	2
$LC3:
	.ascii	"horsefeathers\000"
	.align	2
$LC4:
	.ascii	"%p is %s should be abcdefgh\n\000"
	.align	2
$LC5:
	.ascii	"abcdefeathers\000"
	.text
	.align	2
	.ent	test_memccpy
		.type		 test_memccpy,@function
test_memccpy:
	.frame	$sp,48,$31		# vars= 0, regs= 5/0, args= 16, extra= 8
	.mask	0x90070000,-8
	.fmask	0x00000000,0
	.set	noreorder
	.cpload	$25
	.set	reorder
	subu	$sp,$sp,48
	.cprestore 16
	sw	$17,28($sp)
	sw	$16,24($sp)
	la	$17,two
	la	$16,one
	li	$7,9			# 0x9
	sw	$18,32($sp)
	li	$6,102			# 0x66
	la	$18,$LC2
	move	$4,$17
	move	$5,$16
	sw	$31,40($sp)
	lwl	$2,0($18)
	lwr	$2,3($18)
	lwl	$3,4($18)
	lwr	$3,7($18)
	lb	$8,8($18)
	swl	$2,0($16)
	swr	$2,3($16)
	swl	$3,4($16)
	swr	$3,7($16)
	la	$9,$LC3
	lwl	$2,0($9)
	lwr	$2,3($9)
	lwl	$3,4($9)
	lwr	$3,7($9)
	lwl	$8,8($9)
	lwr	$8,11($9)
	swl	$2,0($17)
	swr	$2,3($17)
	swl	$3,4($17)
	swr	$3,7($17)
	swl	$8,8($17)
	swr	$8,11($17)
	lb	$2,12($9)
	lb	$3,13($9)
	sb	$2,12($17)
	sb	$3,13($17)
	sb	$8,8($16)
	sw	$28,36($sp)
	la	$25,memccpy
	jal	$31,$25
	addu	$3,$17,6
	xor	$2,$2,$3
	sltu	$2,$2,1
	move	$4,$2
	li	$5,7			# 0x7
	la	$25,check
	jal	$31,$25
	move	$4,$16
	move	$5,$18
	li	$6,8			# 0x8
	la	$25,equal
	jal	$31,$25
	move	$5,$16
	move	$6,$16
	la	$4,$LC4
	la	$25,printf
	jal	$31,$25
	move	$4,$17
	la	$5,$LC5
	li	$6,9			# 0x9
	la	$25,equal
	jal	$31,$25
	lw	$31,40($sp)
	lw	$18,32($sp)
	lw	$17,28($sp)
	lw	$16,24($sp)
	#nop
	.set	noreorder
	.set	nomacro
	j	$31
	addu	$sp,$sp,48
	.set	macro
	.set	reorder

	.end	test_memccpy
	.rdata
	.align	2
$LC6:
	.ascii	"No errors.\000"
	.align	2
$LC7:
	.ascii	"%Zd errors.\n\000"
	.text
	.align	2
	.globl	main
	.ent	main
		.type		 main,@function
main:
	.frame	$sp,40,$31		# vars= 0, regs= 3/0, args= 16, extra= 8
	.mask	0x90010000,-8
	.fmask	0x00000000,0
	.set	noreorder
	.cpload	$25
	.set	reorder
	subu	$sp,$sp,40
	.cprestore 16
	sw	$16,24($sp)
	sw	$31,32($sp)
	sw	$28,28($sp)
	la	$25,test_memccpy
	jal	$31,$25
	lw	$2,errors
	la	$4,$LC6
	move	$5,$2
	.set	noreorder
	.set	nomacro
	bne	$2,$0,$L9
	move	$16,$0
	.set	macro
	.set	reorder

	la	$25,puts
	jal	$31,$25
$L10:
	move	$2,$16
	lw	$31,32($sp)
	lw	$16,24($sp)
	#nop
	.set	noreorder
	.set	nomacro
	j	$31
	addu	$sp,$sp,40
	.set	macro
	.set	reorder

$L9:
	la	$4,$LC7
	la	$25,printf
	jal	$31,$25
	.set	noreorder
	.set	nomacro
	j	$L10
	li	$16,1			# 0x1
	.set	macro
	.set	reorder

	.end	main

	.comm	one,50

	.comm	two,50
	.ident	"GCC: (GNU) 3.2.2 20030109 (Debian prerelease)"

--jRHKVT23PllUwdXP--

From vivienc@nerim.net Mon Jan 27 00:43:33 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 27 Jan 2003 00:43:34 +0000 (GMT)
Received: from smtp-102.nerim.net ([IPv6:::ffff:62.4.16.102]:33545 "EHLO
	kraid.nerim.net") by linux-mips.org with ESMTP id <S8225209AbTA0And>;
	Mon, 27 Jan 2003 00:43:33 +0000
Received: from melkor (vivienc.net1.nerim.net [213.41.134.233])
	by kraid.nerim.net (Postfix) with ESMTP
	id 9CDD640E29; Mon, 27 Jan 2003 01:43:30 +0100 (CET)
Received: from glaurung (helo=localhost)
	by melkor with local-esmtp (Exim 3.36 #1 (Debian))
	id 18cxNl-0001Um-00; Mon, 27 Jan 2003 01:44:13 +0100
Date: Mon, 27 Jan 2003 01:44:12 +0100 (CET)
From: Vivien Chappelier <vivienc@nerim.net>
X-Sender: glaurung@melkor
To: Ralf Baechle <ralf@linux-mips.org>
Cc: linux-mips@linux-mips.org
Subject: Re: sigset_t32 broken?
In-Reply-To: <20030124024854.B9031@linux-mips.org>
Message-ID: <Pine.LNX.4.21.0301270135210.3253-100000@melkor>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <vivienc@nerim.net>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1223
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: vivienc@nerim.net
Precedence: bulk
X-list: linux-mips

On Fri, 24 Jan 2003, Ralf Baechle wrote:
> Most of what your patch does is undoing an accidental commit of a signal
> rework that wasn't yet supposed to go out.

Maybe.. but current version is still wrong :) The type of the sig
array in the 32-bit compatibility struct sigset_t32 must be 32bit long,
i.e. unsigned int not unsigned long.
And I think unsigned describes the data better than signed, but that's a
matter of taste :) (coherent with the choice in asm-mips/signal.h).

Vivien.

--- include/asm-mips64/signal.h	2003-01-26 02:41:48.000000000 +0100
+++ include/asm-mips64/signal.h	2003-01-27 01:28:13.000000000 +0100
@@ -16,7 +16,7 @@
 #define _NSIG_WORDS	(_NSIG / _NSIG_BPW)
 
 typedef struct {
-	long sig[_NSIG_WORDS];
+	unsigned long sig[_NSIG_WORDS];
 } sigset_t;
 
 #define _NSIG32		128
@@ -24,7 +24,7 @@
 #define _NSIG_WORDS32	(_NSIG32 / _NSIG_BPW32)
 
 typedef struct {
-	long sig[_NSIG_WORDS32];
+	unsigned int sig[_NSIG_WORDS32];
 } sigset_t32;
 
 typedef unsigned long old_sigset_t;		/* at least 32 bits */


From ralf@linux-mips.org Mon Jan 27 06:28:58 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 27 Jan 2003 06:28:59 +0000 (GMT)
Received: from p508B6ED0.dip.t-dialin.net ([IPv6:::ffff:80.139.110.208]:51339
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225201AbTA0G26>; Mon, 27 Jan 2003 06:28:58 +0000
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.11.6/8.11.6) id h0R6Svc13704
	for linux-mips@linux-mips.org; Mon, 27 Jan 2003 07:28:57 +0100
Date: Mon, 27 Jan 2003 07:28:57 +0100
From: Ralf Baechle <ralf@linux-mips.org>
To: linux-mips@linux-mips.org
Subject: Re: CVS Update@-mips.org: linux
Message-ID: <20030127072857.A13629@linux-mips.org>
References: <20030126173616Z8225206-1272+297@linux-mips.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5.1i
In-Reply-To: <20030126173616Z8225206-1272+297@linux-mips.org>; from macro@linux-mips.org on Sun, Jan 26, 2003 at 05:36:11PM +0000
Return-Path: <ralf@linux-mips.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1224
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips

On Sun, Jan 26, 2003 at 05:36:11PM +0000, macro@linux-mips.org wrote:

> Modified files:
> 	include/asm-mips: Tag: linux_2_4 checksum.h 
> 	include/asm-mips64: Tag: linux_2_4 checksum.h 
> 
> Log message:
> 	Fix a restoration of assembler's settings in csum_ipv6_magic().

Wow, how did you catch this one - running IPv6?

  Ralf

From ebotcazou@libertysurf.fr Mon Jan 27 09:17:45 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 27 Jan 2003 09:17:46 +0000 (GMT)
Received: from mail.libertysurf.net ([IPv6:::ffff:213.36.80.91]:49959 "EHLO
	mail.libertysurf.net") by linux-mips.org with ESMTP
	id <S8225201AbTA0JRp>; Mon, 27 Jan 2003 09:17:45 +0000
Received: from localhost.localdomain (212.83.190.254) by mail.libertysurf.net (6.5.026)
        id 3DF56A5800679BD2; Mon, 27 Jan 2003 10:15:38 +0100
Content-Type: text/plain;
  charset="iso-8859-1"
From: Eric Botcazou <ebotcazou@libertysurf.fr>
To: Guido Guenther <agx@sigxcpu.org>
Subject: Re: optimizer problem in linux-mips gcc-3.2?
Date: Mon, 27 Jan 2003 10:14:41 +0100
User-Agent: KMail/1.4.3
Cc: gcc@gcc.gnu.org, linux-mips@linux-mips.org
References: <20030126215942.GD14230@bogon.ms20.nix>
In-Reply-To: <20030126215942.GD14230@bogon.ms20.nix>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Message-Id: <200301271014.41715.ebotcazou@libertysurf.fr>
Return-Path: <ebotcazou@libertysurf.fr>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1225
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ebotcazou@libertysurf.fr
Precedence: bulk
X-list: linux-mips

> glibc's string/tester and string/inl-tester fail when compiled with
> Debian's "gcc version 3.2.2 20030109 (Debian prerelease)" on linux-mips
> (big endian) and -O2 or -Os. I've tried to strip down the testcase as
> far as possible and suspect that gcc miscompiles it. It works fine with
> Debian's "gcc version 2.95.4 20011002" and with the above gcc-3.2.2 and
> optimations turned off, -O3 and -O1:

Fill in a bug report (see http://gcc.gnu.org/bugs.html).

-- 
Eric Botcazou

From Geert.Uytterhoeven@sonycom.com Mon Jan 27 09:19:57 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 27 Jan 2003 09:19:58 +0000 (GMT)
Received: from mail2.sonytel.be ([IPv6:::ffff:195.0.45.172]:64948 "EHLO
	mail.sonytel.be") by linux-mips.org with ESMTP id <S8225201AbTA0JT5>;
	Mon, 27 Jan 2003 09:19:57 +0000
Received: from vervain.sonytel.be (mail.sonytel.be [10.17.0.27])
	by mail.sonytel.be (8.9.0/8.8.6) with ESMTP id KAA09196;
	Mon, 27 Jan 2003 10:19:25 +0100 (MET)
Date: Mon, 27 Jan 2003 10:19:26 +0100 (MET)
From: Geert Uytterhoeven <geert@linux-m68k.org>
To: Vivien Chappelier <vivienc@nerim.net>
cc: Ralf Baechle <ralf@linux-mips.org>,
	Linux/MIPS Development <linux-mips@linux-mips.org>
Subject: Re: sigset_t32 broken?
In-Reply-To: <Pine.LNX.4.21.0301270135210.3253-100000@melkor>
Message-ID: <Pine.GSO.4.21.0301271019030.6130-100000@vervain.sonytel.be>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <Geert.Uytterhoeven@sonycom.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1226
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: geert@linux-m68k.org
Precedence: bulk
X-list: linux-mips

On Mon, 27 Jan 2003, Vivien Chappelier wrote:

> On Fri, 24 Jan 2003, Ralf Baechle wrote:
> > Most of what your patch does is undoing an accidental commit of a signal
> > rework that wasn't yet supposed to go out.
> 
> Maybe.. but current version is still wrong :) The type of the sig
> array in the 32-bit compatibility struct sigset_t32 must be 32bit long,
> i.e. unsigned int not unsigned long.
> And I think unsigned describes the data better than signed, but that's a
> matter of taste :) (coherent with the choice in asm-mips/signal.h).

Why not make it u32?

Gr{oetje,eeting}s,

						Geert

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

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


From macro@ds2.pg.gda.pl Mon Jan 27 12:04:16 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 27 Jan 2003 12:04:17 +0000 (GMT)
Received: from delta.ds2.pg.gda.pl ([IPv6:::ffff:213.192.72.1]:49624 "EHLO
	delta.ds2.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8225201AbTA0MEQ>; Mon, 27 Jan 2003 12:04:16 +0000
Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id NAA01425;
	Mon, 27 Jan 2003 13:04:26 +0100 (MET)
Date: Mon, 27 Jan 2003 13:04:26 +0100 (MET)
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To: Ralf Baechle <ralf@linux-mips.org>
cc: linux-mips@linux-mips.org
Subject: Re: CVS Update@-mips.org: linux
In-Reply-To: <20030127072857.A13629@linux-mips.org>
Message-ID: <Pine.GSO.3.96.1030127125225.1077A-100000@delta.ds2.pg.gda.pl>
Organization: Technical University of Gdansk
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <macro@ds2.pg.gda.pl>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1227
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: macro@ds2.pg.gda.pl
Precedence: bulk
X-list: linux-mips

On Mon, 27 Jan 2003, Ralf Baechle wrote:

> > Log message:
> > 	Fix a restoration of assembler's settings in csum_ipv6_magic().
> 
> Wow, how did you catch this one - running IPv6?

 I do run IPv6 -- I get to my 32-bit box with SSH over IPv6 just to make
sure I'll find more bugs (the previous one was the multicast filter). ;-) 
I even have ipv6.o as a module (which also triggered bugs in the past). 
Will have to try with the 64-bit box. ;-)))

 But this bug I've actually spotted studying compiler's diagnostic output
-- a "Macro instruction expanded into multiple instructions in a branch
delay slot" warning isn't normal for a .c file. 

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


From ZhouY.external@infineon.com Mon Jan 27 14:27:27 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 27 Jan 2003 14:27:28 +0000 (GMT)
Received: from smtp2.infineon.com ([IPv6:::ffff:194.175.117.77]:44423 "EHLO
	smtp2.infineon.com") by linux-mips.org with ESMTP
	id <S8225201AbTA0O11>; Mon, 27 Jan 2003 14:27:27 +0000
Received: from mucse011.eu.infineon.com (mucse011.ifx-mail1.com [172.29.27.228])
	by smtp2.infineon.com (8.12.2/8.12.2) with ESMTP id h0REPE2e012271
	for <linux-mips@linux-mips.org>; Mon, 27 Jan 2003 15:25:14 +0100 (MET)
Received: by mucse011.eu.infineon.com with Internet Mail Service (5.5.2653.19)
	id <DYMZYR1G>; Mon, 27 Jan 2003 15:27:21 +0100
Message-ID: <3A5A80BF651115469CA99C8928706CB603D7B2C2@mucse004.eu.infineon.com>
From: ZhouY.external@infineon.com
To: linux-mips@linux-mips.org
Subject: A problem about gprof
Date: Mon, 27 Jan 2003 15:27:16 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Return-Path: <ZhouY.external@infineon.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1228
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ZhouY.external@infineon.com
Precedence: bulk
X-list: linux-mips

Hi dear experts,
  In order to use the gprof in the SDE 5.02 toolchain, I compiled a program
with '-p' option but the compiler responsed with a error. I have checked the
startup assembly code crt0.sx. There is an address operation which need the
address of '_ecode'. Which library has the symbol '_ecode'?  Could you give
me a clue?
  Thanks in advance!

  Best regards,

  Yidan


PS. The following is the error messge:
sde-gcc -O -g -mcpu=4kc -mips32 -EB -mno-float  -DGNUSIM -D__SIM
'-Afloat(no)'
  -I../../kit/GSIM32B/../gnusim   -c    -DMCRT0 ../../kit/share/crt0.sx -o
mcrt0
.o
sde-gcc -g -p -mcpu=4kc -mips32 -EB -mno-float  -DGNUSIM -D__SIM
'-Afloat(no)'
  -I../../kit/GSIM32B/../gnusim   -c hello.c -o hello.o
sde-make[1]: Entering directory `/cygdrive/c/sde/sde/kit/GSIM32B'
sde-make[1]: Nothing to be done for `kit'.
sde-make[1]: Leaving directory `/cygdrive/c/sde/sde/kit/GSIM32B'
sde-gcc -mcpu=4kc -mips32 -EB -mno-float   -Ttext 80000400
-L../../kit/GSIM32B
../../kit/GSIM32B/ramstart.o mcrt0.o hello.o   -lc  -lram -lgcc -lc -le
-lram -l
c -lgcc ../../kit/GSIM32B/crtn.o -o ex1ram
mcrt0.o: In function `__fini':
/cygdrive/c/sde/sde/examples/helloworld/../../kit/share/crt0.sx(.text+0x60):
und
efined reference to `_ecode'
/cygdrive/c/sde/sde/examples/helloworld/../../kit/share/crt0.sx(.text+0x64):
und
efined reference to `_ecode'
collect2: ld returned 1 exit status
sde-make: *** [ex1ram] Error 1


From Todd.Smith@camc.org Mon Jan 27 14:32:02 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 27 Jan 2003 14:32:03 +0000 (GMT)
Received: from hnet1.camc.org ([IPv6:::ffff:206.193.127.2]:14525 "EHLO
	mail2.camcare.com") by linux-mips.org with ESMTP
	id <S8225209AbTA0OcC>; Mon, 27 Jan 2003 14:32:02 +0000
Received: from KES.camcare.com (IS~KES [10.10.95.4]) by mail2.camcare.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21)
	id DVDH2825; Mon, 27 Jan 2003 09:32:01 -0500
Received: by KES.camcare.com with Internet Mail Service (5.5.2650.21)
	id <D1M7RFC7>; Mon, 27 Jan 2003 09:31:54 -0500
Message-ID: <490E0430C3C72046ACF7F18B7CD76A2A568F70@KES.camcare.com>
From: "Smith, Todd" <Todd.Smith@camc.org>
To: linux-mips@linux-mips.org
Subject: You need help!
Date: Mon, 27 Jan 2003 09:31:48 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Return-Path: <Todd.Smith@camc.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1229
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: Todd.Smith@camc.org
Precedence: bulk
X-list: linux-mips

Hello Maciej,

You are sick and twisted but your testing plan will certainly find bugs. :)
My only question is how to tell the bugs from one package to the other. :)

Thanks for all of the hard work.

Todd Smith <todd.smith@camc.org>

-----Original Message-----
From: Maciej W. Rozycki [mailto:macro@ds2.pg.gda.pl]
Sent: Monday, January 27, 2003 7:04 AM
To: Ralf Baechle
Cc: linux-mips@linux-mips.org
Subject: Re: CVS Update@-mips.org: linux


On Mon, 27 Jan 2003, Ralf Baechle wrote:

> > Log message:
> > 	Fix a restoration of assembler's settings in csum_ipv6_magic().
> 
> Wow, how did you catch this one - running IPv6?

 I do run IPv6 -- I get to my 32-bit box with SSH over IPv6 just to make
sure I'll find more bugs (the previous one was the multicast filter). ;-) 
I even have ipv6.o as a module (which also triggered bugs in the past). 
Will have to try with the 64-bit box. ;-)))

 But this bug I've actually spotted studying compiler's diagnostic output
-- a "Macro instruction expanded into multiple instructions in a branch
delay slot" warning isn't normal for a .c file. 

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


From billcalaway@mailcity.com Mon Jan 27 14:38:01 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 27 Jan 2003 14:38:01 +0000 (GMT)
Received: from www1.mail.lycos.com ([IPv6:::ffff:209.202.220.140]:33273 "HELO
	mailcity.com") by linux-mips.org with SMTP id <S8225214AbTA0OiB>;
	Mon, 27 Jan 2003 14:38:01 +0000
Received: from Unknown/Local ([?.?.?.?]) by mailcity.com; Mon, 27 Jan 2003 14:37:32 -0000
To: linux-mips@linux-mips.org, ZhouY.external@infineon.com
Date: Mon, 27 Jan 2003 09:37:32 -0500
From: "Bill Calaway" <billcalaway@lycos.com>
Message-ID: <LIEEFDLGCJJLDBAA@mailcity.com>
Mime-Version: 1.0
X-Sent-Mail: on
Reply-To: billcalaway@lycos.com
X-Mailer: MailCity Service
X-Priority: 3
Subject: Re: A problem about gprof
X-Sender-Ip: 198.45.18.20
Organization: Lycos Mail  (http://www.mail.lycos.com:80)
Content-Type: text/plain; charset=us-ascii
Content-Language: en
Content-Length: 2053
Content-Transfer-Encoding: 7bit
Return-Path: <billcalaway@mailcity.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1230
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: billcalaway@lycos.com
Precedence: bulk
X-list: linux-mips

Often there are seperate precompiled versions of libraries that where compiled with profiling on.  For example, if you have glibc-profile installed you should change your -l into a -l_p.   Just a hunch, but check to see if you have a profiled version of the "e" library.

Bill Calaway
 
--

On Mon, 27 Jan 2003 15:27:16  
 ZhouY.external wrote:
>Hi dear experts,
>  In order to use the gprof in the SDE 5.02 toolchain, I compiled a program
>with '-p' option but the compiler responsed with a error. I have checked the
>startup assembly code crt0.sx. There is an address operation which need the
>address of '_ecode'. Which library has the symbol '_ecode'?  Could you give
>me a clue?
>  Thanks in advance!
>
>  Best regards,
>
>  Yidan
>
>
>PS. The following is the error messge:
>sde-gcc -O -g -mcpu=4kc -mips32 -EB -mno-float  -DGNUSIM -D__SIM
>'-Afloat(no)'
>  -I../../kit/GSIM32B/../gnusim   -c    -DMCRT0 ../../kit/share/crt0.sx -o
>mcrt0
>.o
>sde-gcc -g -p -mcpu=4kc -mips32 -EB -mno-float  -DGNUSIM -D__SIM
>'-Afloat(no)'
>  -I../../kit/GSIM32B/../gnusim   -c hello.c -o hello.o
>sde-make[1]: Entering directory `/cygdrive/c/sde/sde/kit/GSIM32B'
>sde-make[1]: Nothing to be done for `kit'.
>sde-make[1]: Leaving directory `/cygdrive/c/sde/sde/kit/GSIM32B'
>sde-gcc -mcpu=4kc -mips32 -EB -mno-float   -Ttext 80000400
>-L../../kit/GSIM32B
>../../kit/GSIM32B/ramstart.o mcrt0.o hello.o   -lc  -lram -lgcc -lc -le
>-lram -l
>c -lgcc ../../kit/GSIM32B/crtn.o -o ex1ram
>mcrt0.o: In function `__fini':
>/cygdrive/c/sde/sde/examples/helloworld/../../kit/share/crt0.sx(.text+0x60):
>und
>efined reference to `_ecode'
>/cygdrive/c/sde/sde/examples/helloworld/../../kit/share/crt0.sx(.text+0x64):
>und
>efined reference to `_ecode'
>collect2: ld returned 1 exit status
>sde-make: *** [ex1ram] Error 1
>
>
>


_____________________________________________________________
Get 25MB, POP3, Spam Filtering with LYCOS MAIL PLUS for $19.95/year.
http://login.mail.lycos.com/brandPage.shtml?pageId=plus&ref=lmtplus

From macro@ds2.pg.gda.pl Mon Jan 27 14:58:47 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 27 Jan 2003 14:58:48 +0000 (GMT)
Received: from delta.ds2.pg.gda.pl ([IPv6:::ffff:213.192.72.1]:17627 "EHLO
	delta.ds2.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8225217AbTA0O6r>; Mon, 27 Jan 2003 14:58:47 +0000
Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id PAA04159;
	Mon, 27 Jan 2003 15:58:52 +0100 (MET)
Date: Mon, 27 Jan 2003 15:58:51 +0100 (MET)
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
Reply-To: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To: "Smith, Todd" <Todd.Smith@camc.org>
cc: linux-mips@linux-mips.org
Subject: Re: You need help!
In-Reply-To: <490E0430C3C72046ACF7F18B7CD76A2A568F70@KES.camcare.com>
Message-ID: <Pine.GSO.3.96.1030127154326.1077F-100000@delta.ds2.pg.gda.pl>
Organization: Technical University of Gdansk
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <macro@ds2.pg.gda.pl>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1231
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: macro@ds2.pg.gda.pl
Precedence: bulk
X-list: linux-mips

Hello Todd,

> You are sick and twisted but your testing plan will certainly find bugs. :)

 That's my fate, I suppose.

> My only question is how to tell the bugs from one package to the other. :)

 Elementary, my dear Watson!

  Maciej

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


From jsun@orion.mvista.com Mon Jan 27 18:45:43 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 27 Jan 2003 18:45:44 +0000 (GMT)
Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:16625 "EHLO
	orion.mvista.com") by linux-mips.org with ESMTP id <S8225203AbTA0Spn>;
	Mon, 27 Jan 2003 18:45:43 +0000
Received: (from jsun@localhost)
	by orion.mvista.com (8.11.6/8.11.6) id h0RITTA24530;
	Mon, 27 Jan 2003 10:29:29 -0800
Date: Mon, 27 Jan 2003 10:29:29 -0800
From: Jun Sun <jsun@mvista.com>
To: Vivien Chappelier <vivienc@nerim.net>
Cc: Ralf Baechle <ralf@oss.sgi.com>, linux-mips@linux-mips.org,
	jsun@mvista.com
Subject: Re: [PATCH 2.5] FPU
Message-ID: <20030127102929.N11633@mvista.com>
References: <Pine.LNX.4.21.0301260251300.15950-100000@melkor>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <Pine.LNX.4.21.0301260251300.15950-100000@melkor>; from vivienc@nerim.net on Sun, Jan 26, 2003 at 02:58:09AM +0100
Return-Path: <jsun@orion.mvista.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1232
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: jsun@mvista.com
Precedence: bulk
X-list: linux-mips

On Sun, Jan 26, 2003 at 02:58:09AM +0100, Vivien Chappelier wrote:
> Hi,
> 
> 	At various places in the 2.5 kernel, the fpu is accessed in
> kernel mode with CU1 not set, causing an unexpected exception. This patch
> makes sure FPU can be accessed by the kernel, though it may only
> be a workaround. Any comment from someone with a better understanding of
> the FPU access/context switching code?
> 
> Vivien.
> 
> --- include/asm-mips64/fpu.h	2002-12-11 20:44:20.000000000 +0100
> +++ include/asm-mips64/fpu.h	2002-12-11 21:51:44.000000000 +0100
> @@ -109,6 +109,7 @@
>  
>  static inline void save_fp(struct task_struct *tsk)
>  {
> +	enable_fpu();
>  	if (mips_cpu.options & MIPS_CPU_FPU) 
>  		_save_fp(tsk);
>  }
> --- include/asm-mips/fpu.h	2002-12-11 20:44:20.000000000 +0100
> +++ include/asm-mips/fpu.h	2002-12-11 21:51:44.000000000 +0100
> @@ -109,6 +109,7 @@
>  
>  static inline void save_fp(struct task_struct *tsk)
>  {
> +	enable_fpu();
>  	if (mips_cpu.options & MIPS_CPU_FPU) 
>  		_save_fp(tsk);
>  }

The above two hunks seem to be right.

The following hunks are not right.  The checking for is_fpu_owner()
is meaningful.  If current process is FPU owner, you *don't* want to
do a restore which essentially wipe away the current FPU regsiter values
with an old snapshot of them.

I got a report saying save_fp_context() causes panic when current process
is FPU owner.  That tells me something is wrong in 2.5 that violates
that assumption that FPU is always enabled when current process is the
FPU owner.  I have it in my note and will look into it once I get to 2.5
work.  You are more than to look into it as well.  Meanwhile, just adding
a enable_fpu() to save_fp_context() should let you get rid of the crash.
(although I am afraid there might be other related bugs as this should
not be needed).

Jun

> --- arch/mips64/kernel/signal.c	2002-11-09 16:10:14.000000000 +0100
> +++ arch/mips64/kernel/signal.c	2003-01-14 01:35:42.000000000 +0100
> @@ -162,20 +162,19 @@
>  
>  	err |= __put_user(current->used_math, &sc->sc_used_math);
>  
> -	if (!current->used_math)
> -		goto out;
> +	if (current->used_math) {
> +
> +		/*
> +		 * Save FPU state to signal context.
> +		 * Signal handler will "inherit" current FPU state.
> +		 */
>  
> -	/*
> -	 * Save FPU state to signal context.  Signal handler will "inherit"
> -	 * current FPU state.
> -	 */
> -	if (!is_fpu_owner()) {
>  		own_fpu();
>  		restore_fp(current);
> +
> +		err |= save_fp_context(sc);
>  	}
> -	err |= save_fp_context(sc);
>  
> -out:
>  	return err;
>  }
>  
> --- arch/mips/kernel/signal.c	2002-11-09 16:10:08.000000000 +0100
> +++ arch/mips/kernel/signal.c	2003-01-14 01:36:41.000000000 +0100
> @@ -313,20 +313,19 @@
>  
>  	err |= __put_user(current->used_math, &sc->sc_used_math);
>  
> -	if (!current->used_math)
> -		goto out;
> +	if (current->used_math) {
> +
> +		/* 
> +		 * Save FPU state to signal context.
> +		 * Signal handler will "inherit" current FPU state.
> +		 */
>  
> -	/* 
> -	 * Save FPU state to signal context.  Signal handler will "inherit"
> -	 * current FPU state.
> -	 */
> -	if (!is_fpu_owner()) {
>  		own_fpu();
>  		restore_fp(current);
> +
> +		err |= save_fp_context(sc);
>  	}
> -	err |= save_fp_context(sc);
>  
> -out:
>  	return err;
>  }
>  
> --- arch/mips64/kernel/signal32.c	2002-11-09 16:10:14.000000000 +0100
> +++ arch/mips64/kernel/signal32.c	2003-01-14 01:34:52.000000000 +0100
> @@ -457,20 +430,19 @@
>  
>  	err |= __put_user(current->used_math, &sc->sc_used_math);
>  
> -	if (!current->used_math)
> -		goto out;
> +	if (current->used_math) {
> +
> +		/* 
> +		 * Save FPU state to signal context.
> +		 * Signal handler will "inherit" current FPU state.
> +		 */
>  
> -	/* 
> -	 * Save FPU state to signal context.  Signal handler will "inherit"
> -	 * current FPU state.
> -	 */
> -	if (!is_fpu_owner()) {
>  		own_fpu();
>  		restore_fp(current);
> +
> +		err |= save_fp_context(sc);
>  	}
> -	err |= save_fp_context(sc);
>  
> -out:
>  	return err;
>  }
>  
> 
> 

From cwu@deltartp.com Mon Jan 27 22:11:00 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 27 Jan 2003 22:11:01 +0000 (GMT)
Received: from mail.deltartp.com ([IPv6:::ffff:216.166.210.181]:62474 "EHLO
	dprn03.deltartp.com") by linux-mips.org with ESMTP
	id <S8225211AbTA0WLA>; Mon, 27 Jan 2003 22:11:00 +0000
Received: by dprn03.deltartp.com with Internet Mail Service (5.5.2653.19)
	id <DM946DJH>; Mon, 27 Jan 2003 16:53:38 -0500
Message-ID: <A4E787A2467EF849B00585F14C9005590689D3@dprn03.deltartp.com>
From: Chien-Lung Wu <cwu@deltartp.com>
To: "'linux-mips@linux-mips.org'" <linux-mips@linux-mips.org>
Subject: mips cross-compiler
Date: Mon, 27 Jan 2003 16:53:38 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Return-Path: <cwu@deltartp.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1233
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: cwu@deltartp.com
Precedence: bulk
X-list: linux-mips

Hi,
I am trying to install a mips-linux cross compiler on my linux box with
	target=mips-linux
	host=i686-linux

 I download the rpm files
	binutils-mips-linux-2.8.1-1-i386.rpm
	egcs-mips-linux-1.0.3a-2.i386.rpm
	glibc-2.1.95.1.mips.rpm
from ftp://oss.sgi.com/pub/linux/mips

When I use rpm comand to install binutils and egcs, they work fine.
	rpm -i binutils-mips-linux-2.8.1-1-i386.rpm
	rpm -i egcs-mips-linux-1.0.3a-2.i386.rpm

However, as I intsall the glibc with the rpm command:
	rpm -i glibc-2.1.95.1.mips.rpm

I got a confliction with glibc-common-2.2.4-13, since my native glibc is
2.2.4-13. Thus I cannot install glibc.

Can anybody show me how to install the cross-compiler correctly? (what is
the correct rpm command?)

More questions:
If I have native glibc, can I install another glibc for cross-compiler?
Can I install the binutils-mips-linux-2.8.1-1 to a specific path?  How?
( when I install them with rpm -i command, the executable files will go to
/usr/bin as default. Can I change that?)

Thanks for your help.

Chien-Lung

From quintela@mandrakesoft.com Mon Jan 27 22:30:39 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 27 Jan 2003 22:30:40 +0000 (GMT)
Received: from cm19173.red.mundo-r.com ([IPv6:::ffff:213.60.19.173]:57138 "EHLO
	trasno.mitica") by linux-mips.org with ESMTP id <S8225218AbTA0Waj>;
	Mon, 27 Jan 2003 22:30:39 +0000
Received: by trasno.mitica (Postfix, from userid 1001)
	id 1C5F8BA36; Mon, 27 Jan 2003 23:30:15 +0100 (CET)
To: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Vivien Chappelier <vivienc@nerim.net>,
	Ralf Baechle <ralf@linux-mips.org>,
	Linux/MIPS Development <linux-mips@linux-mips.org>
Subject: Re: sigset_t32 broken?
X-Url: http://people.mandrakesoft.com/~quintela
From: Juan Quintela <quintela@mandrakesoft.com>
In-Reply-To: <Pine.GSO.4.21.0301271019030.6130-100000@vervain.sonytel.be> (Geert
 Uytterhoeven's message of "Mon, 27 Jan 2003 10:19:26 +0100 (MET)")
References: <Pine.GSO.4.21.0301271019030.6130-100000@vervain.sonytel.be>
Date: Mon, 27 Jan 2003 23:30:15 +0100
Message-ID: <86smvez0nc.fsf@trasno.mitica>
User-Agent: Gnus/5.090012 (Oort Gnus v0.12) Emacs/21.2.92
 (i386-mandrake-linux-gnu)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Return-Path: <quintela@mandrakesoft.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1234
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: quintela@mandrakesoft.com
Precedence: bulk
X-list: linux-mips

>>>>> "geert" == Geert Uytterhoeven <geert@linux-m68k.org> writes:

geert> On Mon, 27 Jan 2003, Vivien Chappelier wrote:
>> On Fri, 24 Jan 2003, Ralf Baechle wrote:
>> > Most of what your patch does is undoing an accidental commit of a signal
>> > rework that wasn't yet supposed to go out.
>> 
>> Maybe.. but current version is still wrong :) The type of the sig
>> array in the 32-bit compatibility struct sigset_t32 must be 32bit long,
>> i.e. unsigned int not unsigned long.
>> And I think unsigned describes the data better than signed, but that's a
>> matter of taste :) (coherent with the choice in asm-mips/signal.h).

geert> Why not make it u32?

Nahh, that will make it clear indeed to stupid's like me :p

Later ,Juan.



-- 
In theory, practice and theory are the same, but in practice they 
are different -- Larry McVoy

From ldavies@agile.tv Tue Jan 28 00:52:14 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 28 Jan 2003 00:52:15 +0000 (GMT)
Received: from agile.dsl.onthenet.net ([IPv6:::ffff:203.144.28.2]:54303 "EHLO
	surfers.oz.agile.tv") by linux-mips.org with ESMTP
	id <S8225226AbTA1AwO>; Tue, 28 Jan 2003 00:52:14 +0000
Received: from agile.tv (tugun.oz.agile.tv [192.168.16.20])
	by surfers.oz.agile.tv (8.11.6/8.11.2) with ESMTP id h0S0pku05828;
	Tue, 28 Jan 2003 10:51:47 +1000
Message-ID: <3E35D422.5030101@agile.tv>
Date: Tue, 28 Jan 2003 10:51:46 +1000
From: Liam Davies <ldavies@agile.tv>
Reply-To: ldavies@agile.tv
Organization: AgileTV Corporation
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2) Gecko/20021203
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Karsten Merker <karsten@excalibur.cologne.de>
CC: linux-mips@linux-mips.org, tom@maisl.net,
	cobalt-22 <cobalt-22@devel.alal.com>
Subject: Re: [PATCH] Cobalt interrupthandler fix
References: <20030124141524.GA685@excalibur.cologne.de>
In-Reply-To: <20030124141524.GA685@excalibur.cologne.de>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Return-Path: <ldavies@agile.tv>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1235
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ldavies@agile.tv
Precedence: bulk
X-list: linux-mips

Karsten Merker wrote:
> Hallo,
> 
> the Cobalt NASRaQ (as well as other RaQ models) has the problem of freezing
> when there is activity on the serial port and on the ethernet at the same
> time. Peter de Schrijver has tracked this down to a bug in the interrupt
> handler. The handler currently does not check whether an interrupt is masked
> and calls the handling routine for _every_ interrupt, not only for those
> that are not masked out currently.
> 
> The following patch fixes this. Ralf, could you please apply the fix
> to the CVS?
Good find, applied to CVS. The patch works great here!


Liam


From jsun@orion.mvista.com Tue Jan 28 01:03:51 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 28 Jan 2003 01:03:51 +0000 (GMT)
Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:1777 "EHLO
	orion.mvista.com") by linux-mips.org with ESMTP id <S8225223AbTA1BDv>;
	Tue, 28 Jan 2003 01:03:51 +0000
Received: (from jsun@localhost)
	by orion.mvista.com (8.11.6/8.11.6) id h0S13k125346;
	Mon, 27 Jan 2003 17:03:46 -0800
Date: Mon, 27 Jan 2003 17:03:46 -0800
From: Jun Sun <jsun@mvista.com>
To: Juan Quintela <quintela@mandrakesoft.com>
Cc: linux-mips@linux-mips.org, jsun@mvista.com
Subject: Re: [RFC & PATCH]  fixing tlb flush race problem on smp
Message-ID: <20030127170346.S11633@mvista.com>
References: <20030121143726.C16939@mvista.com> <86bs297hpd.fsf@trasno.mitica>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="PmA2V3Z32TCmWXqI"
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <86bs297hpd.fsf@trasno.mitica>; from quintela@mandrakesoft.com on Wed, Jan 22, 2003 at 08:43:26AM +0100
Return-Path: <jsun@orion.mvista.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1236
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: jsun@mvista.com
Precedence: bulk
X-list: linux-mips


--PmA2V3Z32TCmWXqI
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline


Thanks, Juan.

I also find a stupid typo and a subtle hole in my original patch.
Here is an updated version, for 2.4/mips only.  If it looks ok, I 
will extend to other sub-arches/trees.

This new one is pretty nice in that all mmu related operations
are put into one file and it is much easier to ensure correctness
later.

Jun

--PmA2V3Z32TCmWXqI
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="030127-fix-smp-tlb-flush-holes.patch"

diff -Nru link/arch/mips/mm/tlb-sb1.c.orig link/arch/mips/mm/tlb-sb1.c
--- link/arch/mips/mm/tlb-sb1.c.orig	Tue Jan 21 13:54:59 2003
+++ link/arch/mips/mm/tlb-sb1.c	Mon Jan 27 16:58:54 2003
@@ -172,9 +172,7 @@
 			}
 			write_c0_entryhi(oldpid);
 		} else {
-			get_new_mmu_context(mm, cpu);
-			if (mm == current->active_mm)
-				write_c0_entryhi(cpu_asid(cpu, mm));
+			drop_mmu_context(mm, cpu);
 		}
 	}
 	__restore_flags(flags);
@@ -258,10 +256,7 @@
 	__save_and_cli(flags);
 	cpu = smp_processor_id();
 	if (cpu_context(cpu, mm) != 0) {
-		get_new_mmu_context(mm, smp_processor_id());
-		if (mm == current->active_mm) {
-			write_c0_entryhi(cpu_asid(cpu, mm));
-		}
+		drop_mmu_context(mm, cpu);
 	}
 	__restore_flags(flags);
 }
diff -Nru link/include/asm-mips/mmu_context.h.orig link/include/asm-mips/mmu_context.h
--- link/include/asm-mips/mmu_context.h.orig	Tue Jan 21 13:55:43 2003
+++ link/include/asm-mips/mmu_context.h	Mon Jan 27 16:56:44 2003
@@ -89,12 +89,25 @@
 static inline void switch_mm(struct mm_struct *prev, struct mm_struct *next,
                              struct task_struct *tsk, unsigned cpu)
 {
+	unsigned long flags;
+
+	local_irq_save(flags);
+
 	/* Check if our ASID is of an older version and thus invalid */
 	if ((cpu_context(cpu, next) ^ asid_cache(cpu)) & ASID_VERSION_MASK)
 		get_new_mmu_context(next, cpu);
 
 	write_c0_entryhi(cpu_context(cpu, next));
 	TLBMISS_HANDLER_SETUP_PGD(next->pgd);
+
+	/*
+	 * Mark current->active_mm as not "active" anymore.
+	 * We don't want to mislead possible IPI tlb flush routines.
+	 */
+	clear_bit(cpu, &prev->cpu_vm_mask);
+	set_bit(cpu, &next->cpu_vm_mask);
+
+	local_irq_restore(flags);
 }
 
 /*
@@ -112,11 +125,39 @@
 static inline void
 activate_mm(struct mm_struct *prev, struct mm_struct *next)
 {
+	unsigned long flags;
+
+	local_irq_save(flags);
+
 	/* Unconditionally get a new ASID.  */
 	get_new_mmu_context(next, smp_processor_id());
 
 	write_c0_entryhi(cpu_context(smp_processor_id(), next));
 	TLBMISS_HANDLER_SETUP_PGD(next->pgd);
+	
+	local_irq_restore(flags);
+}
+
+/*
+ * If mm is currently active_mm, we can't really drop it.  Instead,
+ * we will get a new one for it.
+ */
+static inline void
+drop_mmu_context(struct mm_struct *mm, unsigned cpu)
+{
+	unsigned long flags;
+
+	local_irq_save(flags);
+
+	if (test_bit(cpu, &mm->cpu_vm_mask))  {
+		get_new_mmu_context(mm, cpu);
+		set_entryhi(CPU_CONTEXT(cpu, mm) & 0xff);
+	} else {
+		/* will get a new context next time */
+		CPU_CONTEXT(cpu, mm) = 0;
+	}
+
+	local_irq_restore(flags);
 }
 
 #endif /* _ASM_MMU_CONTEXT_H */

--PmA2V3Z32TCmWXqI--

From ralf@linux-mips.org Tue Jan 28 02:39:10 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 28 Jan 2003 02:39:10 +0000 (GMT)
Received: from p508B65B9.dip.t-dialin.net ([IPv6:::ffff:80.139.101.185]:14489
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225223AbTA1CjK>; Tue, 28 Jan 2003 02:39:10 +0000
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.11.6/8.11.6) id h0S2d1Q24186;
	Tue, 28 Jan 2003 03:39:01 +0100
Date: Tue, 28 Jan 2003 03:39:01 +0100
From: Ralf Baechle <ralf@linux-mips.org>
To: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Mike Uhler <uhler@mips.com>,
	Linux/MIPS Development <linux-mips@linux-mips.org>
Subject: Re: unaligned load in branch delay slot
Message-ID: <20030128033901.A23492@linux-mips.org>
References: <200301131719.h0DHJkG29389@uhler-linux.mips.com> <Pine.GSO.4.21.0301131901500.21279-100000@vervain.sonytel.be>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5.1i
In-Reply-To: <Pine.GSO.4.21.0301131901500.21279-100000@vervain.sonytel.be>; from geert@linux-m68k.org on Mon, Jan 13, 2003 at 07:04:36PM +0100
Return-Path: <ralf@linux-mips.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1237
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips

On Mon, Jan 13, 2003 at 07:04:36PM +0100, Geert Uytterhoeven wrote:

> The following patch (against linux-mips-2.4.x CVS) cures my crash.
> 
> I don't know on which CPUs this may happen (need #ifdef CONFIG_CPU_VR41XX?),
> nor whether all branch and jump instructions are affected (I included
> everything that starts with a `b' or `j').

I'm suggesting this alternative patch below.  Comments?

  Ralf

diff -u -r1.4.2.1 branch.h
--- include/asm-mips/branch.h 7 May 2002 03:48:08 -0000
+++ include/asm-mips/branch.h 28 Jan 2003 02:34:12 -0000
@@ -8,11 +8,52 @@
 #ifndef _ASM_BRANCH_H
 #define _ASM_BRANCH_H
 
+#include <asm/inst.h>
 #include <asm/ptrace.h>
+#include <asm/uaccess.h>
+#include <asm/war.h>
 
 static inline int delay_slot(struct pt_regs *regs)
 {
-	return regs->cp0_cause & CAUSEF_BD;
+#ifdef BDSLOT_WAR
+	union mips_instruction insn;
+	mm_segment_t seg;
+#endif
+	int ds;
+
+	ds = regs->cp0_cause & CAUSEF_BD;
+	if (ds)
+		return ds;
+
+#ifdef BDSLOT_WAR
+	if (!user_mode(regs))
+		set_fs(KERNEL_DS);
+	__get_user(insn.word, (unsigned int *)regs->cp0_epc);
+	set_fs(seg);
+
+	switch (insn.i_format.opcode) {
+	/*
+	 * On some CPUs, if an unaligned access happens in a branch delay slot
+	 * and the branch is not taken, EPC points at the branch instruction,
+	 * but the BD bit in the cause register is not set.
+	 */
+	case bcond_op:
+	case j_op:
+	case jal_op:
+	case beq_op:
+	case bne_op:
+	case blez_op:
+	case bgtz_op:
+	case beql_op:
+	case bnel_op:
+	case blezl_op:
+	case bgtzl_op:
+	case jalx_op:
+		return 1;	
+	}
+#endif
+
+	return 0;
 }
 
 static inline unsigned long exception_epc(struct pt_regs *regs)
diff -u -r1.1.2.4 war.h
--- include/asm-mips/war.h 2 Oct 2002 19:42:04 -0000
+++ include/asm-mips/war.h 28 Jan 2003 02:34:13 -0000
@@ -84,4 +84,17 @@
 
 #endif
 
+#if !defined(CONFIG_CPU_MIPS32) && !defined(CONFIG_CPU_MIPS64)
+
+/*
+ * A bunch of CPUs predating the MIPS32 and MIPS64 specs do not always set
+ * the BD bit in c0_cause on an exception.  For those we need to look at
+ * the faulting instruction to deciede if we were faulting in a delay slot.
+ * There might be further CPUs where BD works as expected but for now we're
+ * paranoid.
+ */
+#define BDSLOT_WAR
+
+#endif
+
 #endif /* _ASM_WAR_H */

From jsun@orion.mvista.com Tue Jan 28 03:04:26 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 28 Jan 2003 03:04:27 +0000 (GMT)
Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:9978 "EHLO
	orion.mvista.com") by linux-mips.org with ESMTP id <S8225223AbTA1DE0>;
	Tue, 28 Jan 2003 03:04:26 +0000
Received: (from jsun@localhost)
	by orion.mvista.com (8.11.6/8.11.6) id h0S34Nw25713;
	Mon, 27 Jan 2003 19:04:23 -0800
Date: Mon, 27 Jan 2003 19:04:23 -0800
From: Jun Sun <jsun@mvista.com>
To: linux-mips@linux-mips.org
Cc: jsun@mvista.com
Subject: when does do_fpe() get called? (or when does FPE happen?)
Message-ID: <20030127190423.U11633@mvista.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
Return-Path: <jsun@orion.mvista.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1238
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: jsun@mvista.com
Precedence: bulk
X-list: linux-mips


Can someone enlighten me a little?  I am trying
to figure out what the FPU state should be (or can be) when
we are inside do_fpe() routine.

Jun

From ralf@linux-mips.org Tue Jan 28 03:37:51 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 28 Jan 2003 03:37:51 +0000 (GMT)
Received: from p508B65B9.dip.t-dialin.net ([IPv6:::ffff:80.139.101.185]:56985
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225223AbTA1Dhv>; Tue, 28 Jan 2003 03:37:51 +0000
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.11.6/8.11.6) id h0S3biG25823;
	Tue, 28 Jan 2003 04:37:44 +0100
Date: Tue, 28 Jan 2003 04:37:44 +0100
From: Ralf Baechle <ralf@linux-mips.org>
To: Jun Sun <jsun@mvista.com>
Cc: linux-mips@linux-mips.org
Subject: Re: when does do_fpe() get called? (or when does FPE happen?)
Message-ID: <20030128043744.A24686@linux-mips.org>
References: <20030127190423.U11633@mvista.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5.1i
In-Reply-To: <20030127190423.U11633@mvista.com>; from jsun@mvista.com on Mon, Jan 27, 2003 at 07:04:23PM -0800
Return-Path: <ralf@linux-mips.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1239
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips

On Mon, Jan 27, 2003 at 07:04:23PM -0800, Jun Sun wrote:

> Can someone enlighten me a little?  I am trying
> to figure out what the FPU state should be (or can be) when
> we are inside do_fpe() routine.

Checkout the various flags in $fcr31.  Whenever one of the enabled
exceptions is triggered we get to handle_fpe via do_fpe.  In addition
the unimplemented exception can also result in invocation of do_fpe.

  Ralf

From ipv6_san@rediffmail.com Tue Jan 28 04:31:09 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 28 Jan 2003 04:31:10 +0000 (GMT)
Received: from webmail29.rediffmail.com ([IPv6:::ffff:203.199.83.39]:60383
	"HELO rediffmail.com") by linux-mips.org with SMTP
	id <S8225194AbTA1EbJ>; Tue, 28 Jan 2003 04:31:09 +0000
Received: (qmail 13487 invoked by uid 510); 28 Jan 2003 04:38:05 -0000
Date: 28 Jan 2003 04:38:05 -0000
Message-ID: <20030128043805.13486.qmail@webmail29.rediffmail.com>
Received: from unknown (194.175.117.86) by rediffmail.com via HTTP; 28 jan 2003 04:38:05 -0000
MIME-Version: 1.0
From: "santosh kumar gowda" <ipv6_san@rediffmail.com>
Reply-To: "santosh kumar gowda" <ipv6_san@rediffmail.com>
To: cwu@deltartp.com
Cc: linux-mips@linux-mips.org
Subject: Re: mips cross-compiler
Content-type: text/plain;
	format=flowed
Content-Disposition: inline
Return-Path: <ipv6_san@rediffmail.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1240
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ipv6_san@rediffmail.com
Precedence: bulk
X-list: linux-mips

Upgrade your glibc to a recent version.
And installing the binutils-mips-linux-2.8.1-1
to a specific path, may result in problems.
I would suggest to compile at the given default
location and then move the executables to
/usr/bin. U will be able to access them everywhere.
Give it a try.

-Santosh
-----------------------------------
On Tue, 28 Jan 2003 Chien-Lung Wu wrote :
>Hi,
>I am trying to install a mips-linux cross compiler on my linux 
>box with
> 	target=mips-linux
> 	host=i686-linux
>
>  I download the rpm files
> 	binutils-mips-linux-2.8.1-1-i386.rpm
> 	egcs-mips-linux-1.0.3a-2.i386.rpm
> 	glibc-2.1.95.1.mips.rpm
> from ftp://oss.sgi.com/pub/linux/mips
>
>When I use rpm comand to install binutils and egcs, they work 
>fine.
> 	rpm -i binutils-mips-linux-2.8.1-1-i386.rpm
> 	rpm -i egcs-mips-linux-1.0.3a-2.i386.rpm
>
>However, as I intsall the glibc with the rpm command:
> 	rpm -i glibc-2.1.95.1.mips.rpm
>
>I got a confliction with glibc-common-2.2.4-13, since my native 
>glibc is
>2.2.4-13. Thus I cannot install glibc.
>
>Can anybody show me how to install the cross-compiler correctly? 
>(what is
>the correct rpm command?)
>
>More questions:
>If I have native glibc, can I install another glibc for 
>cross-compiler?
>Can I install the binutils-mips-linux-2.8.1-1 to a specific path?  
>How?
>( when I install them with rpm -i command, the executable files 
>will go to
>/usr/bin as default. Can I change that?)
>
>Thanks for your help.
>
>Chien-Lung
>



From ralf@linux-mips.org Tue Jan 28 06:47:07 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 28 Jan 2003 06:47:07 +0000 (GMT)
Received: from p508B65B9.dip.t-dialin.net ([IPv6:::ffff:80.139.101.185]:38811
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225194AbTA1GrH>; Tue, 28 Jan 2003 06:47:07 +0000
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.11.6/8.11.6) id h0S6l0s20718;
	Tue, 28 Jan 2003 07:47:00 +0100
Date: Tue, 28 Jan 2003 07:47:00 +0100
From: Ralf Baechle <ralf@linux-mips.org>
To: "Smith, Todd" <Todd.Smith@camc.org>
Cc: linux-mips@linux-mips.org
Subject: Re: You need help!
Message-ID: <20030128074700.A20541@linux-mips.org>
References: <490E0430C3C72046ACF7F18B7CD76A2A568F70@KES.camcare.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5.1i
In-Reply-To: <490E0430C3C72046ACF7F18B7CD76A2A568F70@KES.camcare.com>; from Todd.Smith@camc.org on Mon, Jan 27, 2003 at 09:31:48AM -0500
Return-Path: <ralf@linux-mips.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1241
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips

On Mon, Jan 27, 2003 at 09:31:48AM -0500, Smith, Todd wrote:

> Hello Maciej,
> 
> You are sick and twisted but your testing plan will certainly find bugs. :)
> My only question is how to tell the bugs from one package to the other. :)
> 
> Thanks for all of the hard work.

Now guess why linux-mips.org is running IPv6 :-)

>  I do run IPv6 -- I get to my 32-bit box with SSH over IPv6 just to make
> sure I'll find more bugs (the previous one was the multicast filter). ;-) 
> I even have ipv6.o as a module (which also triggered bugs in the past). 
> Will have to try with the 64-bit box. ;-)))
> 
>  But this bug I've actually spotted studying compiler's diagnostic output
> -- a "Macro instruction expanded into multiple instructions in a branch
> delay slot" warning isn't normal for a .c file. 

The plain C version btw. expands into the same machine instructions.  Of
course it was written on a MIPS so it's no coincidence it'll perform well
on MIPS :)

[root@dea mips64-linux]# host -a ftp.linux-mips.org
Trying "ftp.linux-mips.org"
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 53547
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 2, ADDITIONAL: 1

;; QUESTION SECTION:
;ftp.linux-mips.org.		IN	ANY

;; ANSWER SECTION:
ftp.linux-mips.org.	53172	IN	A	62.254.210.162
ftp.linux-mips.org.	53156	IN	AAAA	3ffe:8260:2028:fffe::1
[...]

There is some ongoing effort to put as many Linux servers on IPv6 as
possible.  And yes, it's caught bugs before.

Everybody's favorite bug is of course is caused by autoconf.  Various
packages only detect the precense of IPv6 if it's actually configured
so there's no more escape from IPv6 already ...

  Ralf

From ralf@linux-mips.org Tue Jan 28 06:56:16 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 28 Jan 2003 06:56:16 +0000 (GMT)
Received: from p508B65B9.dip.t-dialin.net ([IPv6:::ffff:80.139.101.185]:44955
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225194AbTA1G4Q>; Tue, 28 Jan 2003 06:56:16 +0000
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.11.6/8.11.6) id h0S6uAP20913;
	Tue, 28 Jan 2003 07:56:10 +0100
Date: Tue, 28 Jan 2003 07:56:10 +0100
From: Ralf Baechle <ralf@linux-mips.org>
To: Chien-Lung Wu <cwu@deltartp.com>
Cc: "'linux-mips@linux-mips.org'" <linux-mips@linux-mips.org>
Subject: Re: mips cross-compiler
Message-ID: <20030128075610.B20541@linux-mips.org>
References: <A4E787A2467EF849B00585F14C9005590689D3@dprn03.deltartp.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5.1i
In-Reply-To: <A4E787A2467EF849B00585F14C9005590689D3@dprn03.deltartp.com>; from cwu@deltartp.com on Mon, Jan 27, 2003 at 04:53:38PM -0500
Return-Path: <ralf@linux-mips.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1242
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips

On Mon, Jan 27, 2003 at 04:53:38PM -0500, Chien-Lung Wu wrote:

> from ftp://oss.sgi.com/pub/linux/mips

The Linux/MIPS project has moved to (guess ...) linux-mips.org.  oss
still contains a mirror of ftp.linux-mips.org but it's only updated
manually in irregular intervals.

> When I use rpm comand to install binutils and egcs, they work fine.
> 	rpm -i binutils-mips-linux-2.8.1-1-i386.rpm
> 	rpm -i egcs-mips-linux-1.0.3a-2.i386.rpm
> 
> However, as I intsall the glibc with the rpm command:
> 	rpm -i glibc-2.1.95.1.mips.rpm
> 
> I got a confliction with glibc-common-2.2.4-13, since my native glibc is
> 2.2.4-13. Thus I cannot install glibc.
> 
> Can anybody show me how to install the cross-compiler correctly? (what is
> the correct rpm command?)

Rpm just saved your system.  If you're installing this MIPS glibc into a
crosscompiler machine as it seems then keep your CDROM at hand for
reinstallation.  You will need it ...

> More questions:
> If I have native glibc, can I install another glibc for cross-compiler?

Sure, they have nothing in common.

> Can I install the binutils-mips-linux-2.8.1-1 to a specific path?  How?
> ( when I install them with rpm -i command, the executable files will go to
> /usr/bin as default. Can I change that?)

Only very few packages support that; these packages don't.

You will not be able to build a kernel with binutils 2.8.x or egcs 1.0.x.
The absolute minimum required to build a kernel is egcs 1.1.2 and
binutils 2.13.1 which you can download from ftp.linux-mips.org.  Cross-
compiling a kernel does not require the installation of a MIPS glibc on
the crosscompilation host.  If you're going to crosscompile application
software you'll need a much more recent gcc even.

  Ralf

From ralf@linux-mips.org Tue Jan 28 06:58:13 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 28 Jan 2003 06:58:14 +0000 (GMT)
Received: from p508B65B9.dip.t-dialin.net ([IPv6:::ffff:80.139.101.185]:47515
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225194AbTA1G6N>; Tue, 28 Jan 2003 06:58:13 +0000
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.11.6/8.11.6) id h0S6wBm20977;
	Tue, 28 Jan 2003 07:58:11 +0100
Date: Tue, 28 Jan 2003 07:58:11 +0100
From: Ralf Baechle <ralf@linux-mips.org>
To: ZhouY.external@infineon.com
Cc: linux-mips@linux-mips.org
Subject: Re: A problem about gprof
Message-ID: <20030128075811.C20541@linux-mips.org>
References: <3A5A80BF651115469CA99C8928706CB603D7B2C2@mucse004.eu.infineon.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5.1i
In-Reply-To: <3A5A80BF651115469CA99C8928706CB603D7B2C2@mucse004.eu.infineon.com>; from ZhouY.external@infineon.com on Mon, Jan 27, 2003 at 03:27:16PM +0100
Return-Path: <ralf@linux-mips.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1243
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips

On Mon, Jan 27, 2003 at 03:27:16PM +0100, ZhouY.external@infineon.com wrote:

>   In order to use the gprof in the SDE 5.02 toolchain, I compiled a program
> with '-p' option but the compiler responsed with a error. I have checked the
> startup assembly code crt0.sx. There is an address operation which need the
> address of '_ecode'. Which library has the symbol '_ecode'?  Could you give
> me a clue?

There is no crt0.something in Linux.  Seems your compiler is configured
for some obscure target.  Rebuild your compiler for mips-linux or
mipsel-linux as target.  Zero chance otherwise.

  Ralf

From ralf@linux-mips.org Tue Jan 28 07:00:29 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 28 Jan 2003 07:00:30 +0000 (GMT)
Received: from p508B65B9.dip.t-dialin.net ([IPv6:::ffff:80.139.101.185]:49307
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225194AbTA1HA3>; Tue, 28 Jan 2003 07:00:29 +0000
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.11.6/8.11.6) id h0S70Tf21036
	for linux-mips@linux-mips.org; Tue, 28 Jan 2003 08:00:29 +0100
Date: Tue, 28 Jan 2003 08:00:29 +0100
From: Ralf Baechle <ralf@linux-mips.org>
To: linux-mips@linux-mips.org
Subject: Re: debian's mips userland on mips64
Message-ID: <20030128080029.D20541@linux-mips.org>
References: <20030122073006.GF6262@pureza.melbourne.sgi.com> <20030122124540.A31505@sgi.com> <20030122214736.GA1094@wumpus.internal.keyresearch.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5.1i
In-Reply-To: <20030122214736.GA1094@wumpus.internal.keyresearch.com>; from lindahl@keyresearch.com on Wed, Jan 22, 2003 at 01:47:36PM -0800
Return-Path: <ralf@linux-mips.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1244
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips

On Wed, Jan 22, 2003 at 01:47:36PM -0800, Greg Lindahl wrote:

> > I don't think so.  You should rather implement a sys32_ptrace and
> > reference it in the 32bit syscall vector.  Look at the version in
> > arch/ia64/ia32/sys_ia32.c for an example.
> 
> This works as long as you aren't doing n32 - at some point we'll have
> a mature enough toolchain to do that, and we're going to need to hack
> up sys32_ptrace to do the right thing with the bigger fp register file...

Which I've done now.  Also works for native 64-bit code.

  Ralf

From victor@zaslavsky.org Tue Jan 28 07:41:51 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 28 Jan 2003 07:41:52 +0000 (GMT)
Received: from p508B65B9.dip.t-dialin.net ([IPv6:::ffff:80.139.101.185]:8146
	"EHLO p508B65B9.dip.t-dialin.net") by linux-mips.org with ESMTP
	id <S8225194AbTA1Hlv>; Tue, 28 Jan 2003 07:41:51 +0000
Received: from fep2.goldenlines.net.il ([IPv6:::ffff:212.117.129.202]:12691
	"EHLO fep2.012.net.il") by ralf.linux-mips.org with ESMTP
	id <S869813AbTA1Hlw>; Tue, 28 Jan 2003 08:41:52 +0100
Received: from NinaZ ([212.199.155.240]) by fep2.012.net.il with ESMTP
          id <20030128074132.XZDQ1458.fep2@NinaZ>
          for <linux-mips@linux-mips.org>; Tue, 28 Jan 2003 09:41:32 +0200
From: "Victor I. Zaslavsky" <victor@zaslavsky.org>
To: <linux-mips@linux-mips.org>
Subject: Cross compiler installation
Date: Tue, 28 Jan 2003 09:41:31 +0200
Message-ID: <000a01c2c6a0$acdb37b0$f09bc7d4@NinaZ>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_000B_01C2C6B1.706407B0"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Return-Path: <victor@zaslavsky.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1245
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: victor@zaslavsky.org
Precedence: bulk
X-list: linux-mips

This is a multi-part message in MIME format.

------=_NextPart_000_000B_01C2C6B1.706407B0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Hi folks,
 
I am looking for step-by-step instruction how to install cross compiler
for MIPS on my RedHat 8 Intel-based machine.
 
Any help will be very appreciated.
 
Thanks in advance,
Victor
 

------=_NextPart_000_000B_01C2C6B1.706407B0
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">


<meta name=3DProgId content=3DWord.Document>
<meta name=3DGenerator content=3D"Microsoft Word 10">
<meta name=3DOriginator content=3D"Microsoft Word 10">
<link rel=3DFile-List href=3D"cid:filelist.xml@01C2C6B1.6FE3B420">
<!--[if gte mso 9]><xml>
 <o:OfficeDocumentSettings>
  <o:DoNotRelyOnCSS/>
 </o:OfficeDocumentSettings>
</xml><![endif]--><!--[if gte mso 9]><xml>
 <w:WordDocument>
  <w:SpellingState>Clean</w:SpellingState>
  <w:GrammarState>Clean</w:GrammarState>
  <w:DocumentKind>DocumentEmail</w:DocumentKind>
  <w:EnvelopeVis/>
  <w:Compatibility>
   <w:ApplyBreakingRules/>
  </w:Compatibility>
  <w:BrowserLevel>MicrosoftInternetExplorer4</w:BrowserLevel>
 </w:WordDocument>
</xml><![endif]-->
<style>
<!--
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{mso-style-parent:"";
	margin:0in;
	margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:12.0pt;
	font-family:"Times New Roman";
	mso-fareast-font-family:"Times New Roman";
	mso-ansi-language:EN-US;
	mso-fareast-language:EN-US;}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;
	text-underline:single;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;
	text-underline:single;}
p.MsoAutoSig, li.MsoAutoSig, div.MsoAutoSig
	{margin:0in;
	margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:12.0pt;
	font-family:"Times New Roman";
	mso-fareast-font-family:"Times New Roman";}
span.EmailStyle17
	{mso-style-type:personal-compose;
	mso-style-noshow:yes;
	mso-ansi-font-size:10.0pt;
	mso-bidi-font-size:10.0pt;
	font-family:Arial;
	mso-ascii-font-family:Arial;
	mso-hansi-font-family:Arial;
	mso-bidi-font-family:Arial;
	color:windowtext;}
span.SpellE
	{mso-style-name:"";
	mso-spl-e:yes;}
span.GramE
	{mso-style-name:"";
	mso-gram-e:yes;}
@page Section1
	{size:8.5in 11.0in;
	margin:56.7pt 42.5pt 56.7pt 85.05pt;
	mso-header-margin:.5in;
	mso-footer-margin:.5in;
	mso-paper-source:0;}
div.Section1
	{page:Section1;}
-->
</style>
<!--[if gte mso 10]>
<style>
 /* Style Definitions */=20
 table.MsoNormalTable
	{mso-style-name:"Table Normal";
	mso-tstyle-rowband-size:0;
	mso-tstyle-colband-size:0;
	mso-style-noshow:yes;
	mso-style-parent:"";
	mso-padding-alt:0in 5.4pt 0in 5.4pt;
	mso-para-margin:0in;
	mso-para-margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:10.0pt;
	font-family:"Times New Roman";}
</style>
<![endif]-->
</head>

<body lang=3DRU link=3Dblue vlink=3Dpurple style=3D'tab-interval:.5in'>

<div class=3DSection1>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-US =
style=3D'font-size:
10.0pt;font-family:Arial'>Hi folks,<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-US =
style=3D'font-size:
10.0pt;font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-US =
style=3D'font-size:
10.0pt;font-family:Arial'>I am looking for step-by-step instruction how =
to
install cross compiler for MIPS on my <span class=3DSpellE>RedHat</span> =
8 Intel-based
machine.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-US =
style=3D'font-size:
10.0pt;font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-US =
style=3D'font-size:
10.0pt;font-family:Arial'>Any help will be <span =
class=3DGramE>very</span>
appreciated.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-US =
style=3D'font-size:
10.0pt;font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoAutoSig><font size=3D3 face=3D"Times New Roman"><span =
lang=3DEN-US
style=3D'font-size:12.0pt;mso-ansi-language:EN-US;mso-no-proof:yes'>Thank=
s in
advance,</span><span =
style=3D'mso-no-proof:yes'><o:p></o:p></span></font></p>

<p class=3DMsoAutoSig><font size=3D3 face=3D"Times New Roman"><span =
lang=3DEN-US
style=3D'font-size:12.0pt;mso-ansi-language:EN-US;mso-no-proof:yes'>Victo=
r</span><span
style=3D'mso-no-proof:yes'><o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
lang=3DEN-US
style=3D'font-size:12.0pt'><o:p>&nbsp;</o:p></span></font></p>

</div>

</body>

</html>

------=_NextPart_000_000B_01C2C6B1.706407B0--


From chris@cryptoapps.com Tue Jan 28 08:52:17 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 28 Jan 2003 08:52:18 +0000 (GMT)
Received: from mail.cryptoapps.com ([IPv6:::ffff:202.49.232.10]:55768 "EHLO
	iron-maiden.cryptoapps.com") by linux-mips.org with ESMTP
	id <S8225194AbTA1IwR>; Tue, 28 Jan 2003 08:52:17 +0000
Received: by iron-maiden.cryptoapps.com (Postfix, from userid 1000)
	id C588627969; Tue, 28 Jan 2003 00:52:10 -0800 (PST)
Date: Tue, 28 Jan 2003 00:52:10 -0800
From: Chris Zimman <chris@cryptoapps.com>
To: "Victor I. Zaslavsky" <victor@zaslavsky.org>
Cc: linux-mips@linux-mips.org
Subject: Re: Cross compiler installation
Message-ID: <20030128085210.GA27101@mail.cryptoapps.com>
Reply-To: Chris Zimman <chris@cryptoapps.com>
References: <000a01c2c6a0$acdb37b0$f09bc7d4@NinaZ>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <000a01c2c6a0$acdb37b0$f09bc7d4@NinaZ>
User-Agent: Mutt/1.4i
Return-Path: <chris@cryptoapps.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1246
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: chris@cryptoapps.com
Precedence: bulk
X-list: linux-mips

On Tue, Jan 28, 2003 at 09:41:31AM +0200, Victor I. Zaslavsky wrote:
> I am looking for step-by-step instruction how to install cross compiler
> for MIPS on my RedHat 8 Intel-based machine.

Here are a couple of links:

http://www.ltc.com/~brad/mips/mips-cross-toolchain/
http://www.linux-mips.org/toolchain.html

I'd recommend taking the time to read the notes, as the 
MIPS tool chains are a lot more fussy in my experience.

The SDE (www.algor.co.uk) appears to be temporarily 
unavailable (something about them being acquired by MIPS).

The FTP site (ftp.algor-uk.com) is still availble -- not 
sure for how long though.

--Chris

From Geert.Uytterhoeven@sonycom.com Tue Jan 28 09:30:26 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 28 Jan 2003 09:30:27 +0000 (GMT)
Received: from mail2.sonytel.be ([IPv6:::ffff:195.0.45.172]:36256 "EHLO
	mail.sonytel.be") by linux-mips.org with ESMTP id <S8225194AbTA1Ja0>;
	Tue, 28 Jan 2003 09:30:26 +0000
Received: from vervain.sonytel.be (mail.sonytel.be [10.17.0.26])
	by mail.sonytel.be (8.9.0/8.8.6) with ESMTP id KAA00884;
	Tue, 28 Jan 2003 10:30:19 +0100 (MET)
Date: Tue, 28 Jan 2003 10:30:20 +0100 (MET)
From: Geert Uytterhoeven <geert@linux-m68k.org>
To: Ralf Baechle <ralf@linux-mips.org>
cc: Mike Uhler <uhler@mips.com>,
	Linux/MIPS Development <linux-mips@linux-mips.org>
Subject: Re: unaligned load in branch delay slot
In-Reply-To: <20030128033901.A23492@linux-mips.org>
Message-ID: <Pine.GSO.4.21.0301281024060.9269-100000@vervain.sonytel.be>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <Geert.Uytterhoeven@sonycom.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1247
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: geert@linux-m68k.org
Precedence: bulk
X-list: linux-mips

On Tue, 28 Jan 2003, Ralf Baechle wrote:
> On Mon, Jan 13, 2003 at 07:04:36PM +0100, Geert Uytterhoeven wrote:
> > The following patch (against linux-mips-2.4.x CVS) cures my crash.
> > 
> > I don't know on which CPUs this may happen (need #ifdef CONFIG_CPU_VR41XX?),
> > nor whether all branch and jump instructions are affected (I included
> > everything that starts with a `b' or `j').
> 
> I'm suggesting this alternative patch below.  Comments?

I tried to write a simple user space test to identify which CPUs suffer from
this, but I wasn't able to trigger it from user space. Perhaps it happens in
kernel space only?

Or perhaps I made a silly mistake, here's the code I used:
--snip--------------------------------------------------------------------------
        .text
        .align  2
        .globl  probe
probe:
        .set    noreorder
        .set    nomacro
        beq     $4,$0,$L2
        lw      $2,0($5)
        j       $31
        nop
$L2:
        li      $2,-559087616                   # 0xffffffffdead0000
        ori     $2,$2,0xbeef
        j       $31
        nop
        .set    macro
        .set    reorder
--snip--------------------------------------------------------------------------
#include <stdio.h>

extern int probe(int a, char *p);

static int data[2] = { 0x01234567, 0x89abcdef };

int main(int argc, char *argv[])
{
    char *p = (char *)data;

    printf("Should print 0x01234567:               0x%08x\n", probe(1, p));
    printf("Should print 0xdeadbeef:               0x%08x\n", probe(0, p));
    printf("Should print 0x23456789 or 0xef012345: 0x%08x\n", probe(1, p+1));
    printf("Should print 0xdeadbeef:               0x%08x\n", probe(0, p+1));
    return 0;
}
--snip--------------------------------------------------------------------------

If it happens, I should get a SIGILL, right?

> diff -u -r1.4.2.1 branch.h
> --- include/asm-mips/branch.h 7 May 2002 03:48:08 -0000
> +++ include/asm-mips/branch.h 28 Jan 2003 02:34:12 -0000
> @@ -8,11 +8,52 @@
>  #ifndef _ASM_BRANCH_H
>  #define _ASM_BRANCH_H
>  
> +#include <asm/inst.h>
>  #include <asm/ptrace.h>
> +#include <asm/uaccess.h>
> +#include <asm/war.h>
>  
>  static inline int delay_slot(struct pt_regs *regs)
>  {
> -	return regs->cp0_cause & CAUSEF_BD;
> +#ifdef BDSLOT_WAR
> +	union mips_instruction insn;
> +	mm_segment_t seg;
> +#endif
> +	int ds;
> +
> +	ds = regs->cp0_cause & CAUSEF_BD;
> +	if (ds)
> +		return ds;
> +
> +#ifdef BDSLOT_WAR
> +	if (!user_mode(regs))
> +		set_fs(KERNEL_DS);
> +	__get_user(insn.word, (unsigned int *)regs->cp0_epc);
> +	set_fs(seg);

`seg' is never initialized?

> +	switch (insn.i_format.opcode) {
> +	/*
> +	 * On some CPUs, if an unaligned access happens in a branch delay slot
> +	 * and the branch is not taken, EPC points at the branch instruction,
> +	 * but the BD bit in the cause register is not set.
> +	 */
> +	case bcond_op:
> +	case j_op:
> +	case jal_op:
> +	case beq_op:
> +	case bne_op:
> +	case blez_op:
> +	case bgtz_op:
> +	case beql_op:
> +	case bnel_op:
> +	case blezl_op:
> +	case bgtzl_op:
> +	case jalx_op:
> +		return 1;	

I think you can remove the unconditional jumps, cfr. Mike's comments.

> +#if !defined(CONFIG_CPU_MIPS32) && !defined(CONFIG_CPU_MIPS64)
> +
> +/*
> + * A bunch of CPUs predating the MIPS32 and MIPS64 specs do not always set
> + * the BD bit in c0_cause on an exception.  For those we need to look at
> + * the faulting instruction to deciede if we were faulting in a delay slot.
> + * There might be further CPUs where BD works as expected but for now we're
> + * paranoid.
> + */
> +#define BDSLOT_WAR
> +
> +#endif

Isn't the Vr4120A core MIPS32?

Gr{oetje,eeting}s,

						Geert

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

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


From krishnakumar@naturesoft.net Tue Jan 28 08:20:19 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 28 Jan 2003 10:23:22 +0000 (GMT)
Received: from [IPv6:::ffff:203.145.184.221] ([IPv6:::ffff:203.145.184.221]:20996
	"EHLO naturesoft.net") by linux-mips.org with ESMTP
	id <S8225194AbTA1IUT> convert rfc822-to-8bit; Tue, 28 Jan 2003 08:20:19 +0000
Received: from [192.168.0.15] (helo=krishna.royalchallenge.com)
	by naturesoft.net with esmtp (Exim 3.35 #1)
	id 18dQwl-0000O1-00; Tue, 28 Jan 2003 13:48:19 +0530
Content-Type: text/plain;
  charset="iso-8859-1"
From: "Krishnakumar. R" <krishnakumar@naturesoft.net>
Reply-To: krishnakumar@naturesoft.net
To: "Victor I. Zaslavsky" <victor@zaslavsky.org>
Subject: Re: Cross compiler installation
Date: Tue, 28 Jan 2003 13:48:18 +0530
User-Agent: KMail/1.4.1
References: <000a01c2c6a0$acdb37b0$f09bc7d4@NinaZ>
In-Reply-To: <000a01c2c6a0$acdb37b0$f09bc7d4@NinaZ>
Cc: linux-mips@linux-mips.org
MIME-Version: 1.0
Content-Transfer-Encoding: 8BIT
Message-Id: <200301281348.18556.krishnakumar@naturesoft.net>
Return-Path: <krishnakumar@naturesoft.net>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1248
X-Approved-By: ralf@linux-mips.org
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: krishnakumar@naturesoft.net
Precedence: bulk
X-list: linux-mips


Hi,

Have a look 
http://www.ltc.com/~brad/mips/mipsel-linux-cross-toolchain-building.txt

Regards
KK



On Tuesday 28 January 2003 01:11 pm, you wrote:
> Hi folks,
>
> I am looking for step-by-step instruction how to install cross compiler
> for MIPS on my RedHat 8 Intel-based machine.
>
> Any help will be very appreciated.
>
> Thanks in advance,
> Victor


From ralf@linux-mips.org Tue Jan 28 10:33:21 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 28 Jan 2003 10:33:21 +0000 (GMT)
Received: from p508B65B9.dip.t-dialin.net ([IPv6:::ffff:80.139.101.185]:17310
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225194AbTA1KdV>; Tue, 28 Jan 2003 10:33:21 +0000
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.11.6/8.11.6) id h0SAXL125632
	for linux-mips@linux-mips.org; Tue, 28 Jan 2003 11:33:21 +0100
Date: Tue, 28 Jan 2003 11:33:21 +0100
From: Ralf Baechle <ralf@linux-mips.org>
To: linux-mips@linux-mips.org
Subject: Re: [PATCH 2.5] FPU
Message-ID: <20030128113321.E20541@linux-mips.org>
References: <Pine.LNX.4.21.0301260251300.15950-100000@melkor> <20030126033529.GA4296@greglaptop.attbi.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5.1i
In-Reply-To: <20030126033529.GA4296@greglaptop.attbi.com>; from lindahl@keyresearch.com on Sat, Jan 25, 2003 at 07:35:29PM -0800
Return-Path: <ralf@linux-mips.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1249
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips

On Sat, Jan 25, 2003 at 07:35:29PM -0800, Greg Lindahl wrote:

> One good way to start with 2.5 bugs is to compare the code to the 2.4
> kernel. Often you can see places where bugs were fixed in 2.4 but the
> fixes were not also made to the equivalent 2.5 code. This will keep
> 2.4 and 2.5 as close as possible, just like we want to keep the 64-bit
> and 32-bit kernels as close as possible.

While that is fundamentaly true in reality it's often made much harder
because the 2.4 and 2.5 codebases have diverged so much and will diverge
even more so.

  Ralf

From ralf@linux-mips.org Tue Jan 28 11:47:55 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 28 Jan 2003 11:47:56 +0000 (GMT)
Received: from p508B65B9.dip.t-dialin.net ([IPv6:::ffff:80.139.101.185]:10911
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225345AbTA1Lrz>; Tue, 28 Jan 2003 11:47:55 +0000
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.11.6/8.11.6) id h0SBloP27217;
	Tue, 28 Jan 2003 12:47:50 +0100
Date: Tue, 28 Jan 2003 12:47:50 +0100
From: Ralf Baechle <ralf@linux-mips.org>
To: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Mike Uhler <uhler@mips.com>,
	Linux/MIPS Development <linux-mips@linux-mips.org>
Subject: Re: unaligned load in branch delay slot
Message-ID: <20030128124750.A25956@linux-mips.org>
References: <20030128033901.A23492@linux-mips.org> <Pine.GSO.4.21.0301281024060.9269-100000@vervain.sonytel.be>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5.1i
In-Reply-To: <Pine.GSO.4.21.0301281024060.9269-100000@vervain.sonytel.be>; from geert@linux-m68k.org on Tue, Jan 28, 2003 at 10:30:20AM +0100
Return-Path: <ralf@linux-mips.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1250
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips

On Tue, Jan 28, 2003 at 10:30:20AM +0100, Geert Uytterhoeven wrote:

> If it happens, I should get a SIGILL, right?

Right.

Hmm...  If you can't reproduce this anymore I guess we should pull this
patch again?  Despite Mike basically acknowledging that such behaviour
exists I don't feel to well about applying patches for non-reproducable
processor behaviour and would rather prefer to wait until we believe to
know the full details.

?

> > +	set_fs(seg);
> 
> `seg' is never initialized?

Yep ...

> > +	case bcond_op:
> > +	case j_op:
> > +	case jal_op:
> > +	case beq_op:
> > +	case bne_op:
> > +	case blez_op:
> > +	case bgtz_op:
> > +	case beql_op:
> > +	case bnel_op:
> > +	case blezl_op:
> > +	case bgtzl_op:
> > +	case jalx_op:
> > +		return 1;	
> 
> I think you can remove the unconditional jumps, cfr. Mike's comments.

That's one of the points where I felt a bit unsafe about the extend of
the issue so I left the jumps in.  Anyway, why should it make a difference
if an instruction is conditional or not?

> Isn't the Vr4120A core MIPS32?

Vr4120 is MIPS III.

  Ralf

From Geert.Uytterhoeven@sonycom.com Tue Jan 28 12:27:47 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 28 Jan 2003 12:27:48 +0000 (GMT)
Received: from mail2.sonytel.be ([IPv6:::ffff:195.0.45.172]:17887 "EHLO
	mail.sonytel.be") by linux-mips.org with ESMTP id <S8225349AbTA1M1r>;
	Tue, 28 Jan 2003 12:27:47 +0000
Received: from vervain.sonytel.be (mail.sonytel.be [10.17.0.26])
	by mail.sonytel.be (8.9.0/8.8.6) with ESMTP id NAA14383;
	Tue, 28 Jan 2003 13:27:41 +0100 (MET)
Date: Tue, 28 Jan 2003 13:27:42 +0100 (MET)
From: Geert Uytterhoeven <geert@linux-m68k.org>
To: Ralf Baechle <ralf@linux-mips.org>
cc: Mike Uhler <uhler@mips.com>,
	Linux/MIPS Development <linux-mips@linux-mips.org>
Subject: Re: unaligned load in branch delay slot
In-Reply-To: <20030128124750.A25956@linux-mips.org>
Message-ID: <Pine.GSO.4.21.0301281315380.9269-100000@vervain.sonytel.be>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <Geert.Uytterhoeven@sonycom.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1251
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: geert@linux-m68k.org
Precedence: bulk
X-list: linux-mips

On Tue, 28 Jan 2003, Ralf Baechle wrote:
> On Tue, Jan 28, 2003 at 10:30:20AM +0100, Geert Uytterhoeven wrote:
> > If it happens, I should get a SIGILL, right?
> 
> Right.
> 
> Hmm...  If you can't reproduce this anymore I guess we should pull this
> patch again?  Despite Mike basically acknowledging that such behaviour

I cannot reproduce it in user space. I can still reproduce it in kernel space
when an incoming TCP connection is accepted:

| 8034d568 <tcp_v4_conn_request>:
| 8034d568:       27bdfe20        addiu   sp,sp,-480
| 8034d56c:       afb601d8        sw      s6,472(sp)
| 8034d570:       afb301cc        sw      s3,460(sp)
| 8034d574:       afb101c4        sw      s1,452(sp)
| 8034d578:       afbf01dc        sw      ra,476(sp)
| 8034d57c:       afb501d4        sw      s5,468(sp)
| 8034d580:       afb401d0        sw      s4,464(sp)
| 8034d584:       afb201c8        sw      s2,456(sp)
| 8034d588:       afb001c0        sw      s0,448(sp)
| 8034d58c:       00a08821        move    s1,a1
| 8034d590:       8ca50020        lw      a1,32(a1)
| 8034d594:       8e260028        lw      a2,40(s1)
| 8034d598:       8e320044        lw      s2,68(s1)
| 8034d59c:       8ca2000c        lw      v0,12(a1)
| 8034d5a0:       00809821        move    s3,a0
| 8034d5a4:       0000b021        move    s6,zero
| 8034d5a8:       afa201b8        sw      v0,440(sp)
| 8034d5ac:       8cc30064        lw      v1,100(a2)
| 8034d5b0:       3c023000        lui     v0,0x3000
| 8034d5b4:       00621824        and     v1,v1,v0
| 8034d5b8:       14600012        bnez    v1,8034d604 <tcp_v4_conn_request+0x9c>
| 8034d5bc:       8cb50010        lw      s5,16(a1)
                                  ^^^^^^^^^^^^^^^^^
This load may cause an unaligned address exception. Sometimes pc (after
correction based on the branch delay flag) points to 8034d5bc, sometimes it
points to 8034d5b8. In the latter case I found out that the branch was not
taken.

> exists I don't feel to well about applying patches for non-reproducable
> processor behaviour and would rather prefer to wait until we believe to
> know the full details.
> 
> > > +	case bcond_op:
> > > +	case j_op:
> > > +	case jal_op:
> > > +	case beq_op:
> > > +	case bne_op:
> > > +	case blez_op:
> > > +	case bgtz_op:
> > > +	case beql_op:
> > > +	case bnel_op:
> > > +	case blezl_op:
> > > +	case bgtzl_op:
> > > +	case jalx_op:
> > > +		return 1;	
> > 
> > I think you can remove the unconditional jumps, cfr. Mike's comments.
> 
> That's one of the points where I felt a bit unsafe about the extend of
> the issue so I left the jumps in.  Anyway, why should it make a difference
> if an instruction is conditional or not?

Jumps are always taken, and the behavior I saw happened when the branch was
untaken (cfr. above).

Gr{oetje,eeting}s,

						Geert

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

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


From macro@ds2.pg.gda.pl Tue Jan 28 12:29:52 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 28 Jan 2003 12:29:52 +0000 (GMT)
Received: from delta.ds2.pg.gda.pl ([IPv6:::ffff:213.192.72.1]:29163 "EHLO
	delta.ds2.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8225349AbTA1M3w>; Tue, 28 Jan 2003 12:29:52 +0000
Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id NAA23653;
	Tue, 28 Jan 2003 13:30:03 +0100 (MET)
Date: Tue, 28 Jan 2003 13:30:03 +0100 (MET)
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To: Ralf Baechle <ralf@linux-mips.org>
cc: Geert Uytterhoeven <geert@linux-m68k.org>,
	Mike Uhler <uhler@mips.com>,
	Linux/MIPS Development <linux-mips@linux-mips.org>
Subject: Re: unaligned load in branch delay slot
In-Reply-To: <20030128124750.A25956@linux-mips.org>
Message-ID: <Pine.GSO.3.96.1030128130651.22934A-100000@delta.ds2.pg.gda.pl>
Organization: Technical University of Gdansk
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <macro@ds2.pg.gda.pl>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1252
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: macro@ds2.pg.gda.pl
Precedence: bulk
X-list: linux-mips

On Tue, 28 Jan 2003, Ralf Baechle wrote:

> Hmm...  If you can't reproduce this anymore I guess we should pull this
> patch again?  Despite Mike basically acknowledging that such behaviour
> exists I don't feel to well about applying patches for non-reproducable
> processor behaviour and would rather prefer to wait until we believe to
> know the full details.

 Agreed, and I believe a run-time check would be better (and trivial as
well).  The (!MIPS32 && !MIPS64) approximation is too rough.

> > I think you can remove the unconditional jumps, cfr. Mike's comments.
> 
> That's one of the points where I felt a bit unsafe about the extend of
> the issue so I left the jumps in.  Anyway, why should it make a difference
> if an instruction is conditional or not?

 I think jumps cannot be non-taken... 

> > Isn't the Vr4120A core MIPS32?
> 
> Vr4120 is MIPS III.

 Actually I have a datasheet for the Vr4121 (which is a Vr4120 plus some
glue logic for specific peripherals) and it explicitly states whenever
cp0.EPC points to a preceding branch/jump of a faulting instruction, the
cp0.Cause.BD bit is set.  Maybe there is an errata sheet available.

 Additionally the processor is "nice" enough to implement the MIPS III ISA
(with the MIPS16 extension) except ll/sc, lld/scd, sigh...  So the
emulation would need to be ported to the 64-bit kernel if we were to
support this processor in the 64-bit mode. 

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


From ralf@linux-mips.org Tue Jan 28 12:54:59 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 28 Jan 2003 12:55:00 +0000 (GMT)
Received: from p508B65B9.dip.t-dialin.net ([IPv6:::ffff:80.139.101.185]:59295
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225349AbTA1My7>; Tue, 28 Jan 2003 12:54:59 +0000
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.11.6/8.11.6) id h0SCsrW32369;
	Tue, 28 Jan 2003 13:54:53 +0100
Date: Tue, 28 Jan 2003 13:54:53 +0100
From: Ralf Baechle <ralf@linux-mips.org>
To: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>,
	Mike Uhler <uhler@mips.com>,
	Linux/MIPS Development <linux-mips@linux-mips.org>
Subject: Re: unaligned load in branch delay slot
Message-ID: <20030128135453.B27977@linux-mips.org>
References: <20030128124750.A25956@linux-mips.org> <Pine.GSO.3.96.1030128130651.22934A-100000@delta.ds2.pg.gda.pl>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5.1i
In-Reply-To: <Pine.GSO.3.96.1030128130651.22934A-100000@delta.ds2.pg.gda.pl>; from macro@ds2.pg.gda.pl on Tue, Jan 28, 2003 at 01:30:03PM +0100
Return-Path: <ralf@linux-mips.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1253
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips

On Tue, Jan 28, 2003 at 01:30:03PM +0100, Maciej W. Rozycki wrote:

>  Actually I have a datasheet for the Vr4121 (which is a Vr4120 plus some
> glue logic for specific peripherals) and it explicitly states whenever
> cp0.EPC points to a preceding branch/jump of a faulting instruction, the
> cp0.Cause.BD bit is set.  Maybe there is an errata sheet available.

Honestly I'd not expect this to be documented in a NEC manual - they
basically look like the description of the processor core is the same for
basically all the Vr4xxx processors and SOCs.

>  Additionally the processor is "nice" enough to implement the MIPS III ISA
> (with the MIPS16 extension) except ll/sc, lld/scd, sigh...  So the
> emulation would need to be ported to the 64-bit kernel if we were to
> support this processor in the 64-bit mode. 

Maximum agreement on the "sigh" part ...

  Ralf

From jsun@orion.mvista.com Tue Jan 28 17:37:47 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 28 Jan 2003 17:37:48 +0000 (GMT)
Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:22771 "EHLO
	orion.mvista.com") by linux-mips.org with ESMTP id <S8225196AbTA1Rhr>;
	Tue, 28 Jan 2003 17:37:47 +0000
Received: (from jsun@localhost)
	by orion.mvista.com (8.11.6/8.11.6) id h0SHbhO26719;
	Tue, 28 Jan 2003 09:37:43 -0800
Date: Tue, 28 Jan 2003 09:37:42 -0800
From: Jun Sun <jsun@mvista.com>
To: Ralf Baechle <ralf@linux-mips.org>
Cc: linux-mips@linux-mips.org, jsun@mvista.com
Subject: Re: when does do_fpe() get called? (or when does FPE happen?)
Message-ID: <20030128093742.V11633@mvista.com>
References: <20030127190423.U11633@mvista.com> <20030128043744.A24686@linux-mips.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <20030128043744.A24686@linux-mips.org>; from ralf@linux-mips.org on Tue, Jan 28, 2003 at 04:37:44AM +0100
Return-Path: <jsun@orion.mvista.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1254
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: jsun@mvista.com
Precedence: bulk
X-list: linux-mips

On Tue, Jan 28, 2003 at 04:37:44AM +0100, Ralf Baechle wrote:
> On Mon, Jan 27, 2003 at 07:04:23PM -0800, Jun Sun wrote:
> 
> > Can someone enlighten me a little?  I am trying
> > to figure out what the FPU state should be (or can be) when
> > we are inside do_fpe() routine.
> 
> Checkout the various flags in $fcr31.  Whenever one of the enabled
> exceptions is triggered we get to handle_fpe via do_fpe.  In addition
> the unimplemented exception can also result in invocation of do_fpe.
>

So it seems safe to assume FPU should have been enabled when we get
here, right?

Jun

From ralf@linux-mips.org Tue Jan 28 17:45:33 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 28 Jan 2003 17:45:34 +0000 (GMT)
Received: from p508B65B9.dip.t-dialin.net ([IPv6:::ffff:80.139.101.185]:54179
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225299AbTA1Rpd>; Tue, 28 Jan 2003 17:45:33 +0000
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.11.6/8.11.6) id h0SHjTR30369;
	Tue, 28 Jan 2003 18:45:29 +0100
Date: Tue, 28 Jan 2003 18:45:29 +0100
From: Ralf Baechle <ralf@linux-mips.org>
To: Jun Sun <jsun@mvista.com>
Cc: linux-mips@linux-mips.org
Subject: Re: when does do_fpe() get called? (or when does FPE happen?)
Message-ID: <20030128184529.B29262@linux-mips.org>
References: <20030127190423.U11633@mvista.com> <20030128043744.A24686@linux-mips.org> <20030128093742.V11633@mvista.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5.1i
In-Reply-To: <20030128093742.V11633@mvista.com>; from jsun@mvista.com on Tue, Jan 28, 2003 at 09:37:42AM -0800
Return-Path: <ralf@linux-mips.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1255
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips

On Tue, Jan 28, 2003 at 09:37:42AM -0800, Jun Sun wrote:

> > > Can someone enlighten me a little?  I am trying
> > > to figure out what the FPU state should be (or can be) when
> > > we are inside do_fpe() routine.
> > 
> > Checkout the various flags in $fcr31.  Whenever one of the enabled
> > exceptions is triggered we get to handle_fpe via do_fpe.  In addition
> > the unimplemented exception can also result in invocation of do_fpe.
> >
> 
> So it seems safe to assume FPU should have been enabled when we get
> here, right?

Yes, otherwise we'd get a coprocessur unusable exception.

  Ralf

From jsun@orion.mvista.com Tue Jan 28 17:53:52 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 28 Jan 2003 17:53:53 +0000 (GMT)
Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:4345 "EHLO
	orion.mvista.com") by linux-mips.org with ESMTP id <S8225274AbTA1Rxw>;
	Tue, 28 Jan 2003 17:53:52 +0000
Received: (from jsun@localhost)
	by orion.mvista.com (8.11.6/8.11.6) id h0SHrlr26791;
	Tue, 28 Jan 2003 09:53:47 -0800
Date: Tue, 28 Jan 2003 09:53:47 -0800
From: Jun Sun <jsun@mvista.com>
To: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Linux/MIPS Development <linux-mips@linux-mips.org>, jsun@mvista.com
Subject: Re: unaligned load in branch delay slot
Message-ID: <20030128095347.W11633@mvista.com>
References: <Pine.GSO.4.21.0301131704080.21279-100000@vervain.sonytel.be>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <Pine.GSO.4.21.0301131704080.21279-100000@vervain.sonytel.be>; from geert@linux-m68k.org on Mon, Jan 13, 2003 at 05:13:17PM +0100
Return-Path: <jsun@orion.mvista.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1256
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: jsun@mvista.com
Precedence: bulk
X-list: linux-mips


Geert,

I had exactly the same problem with Vr4120A chip!

I have narrowed it down to be a hardware bug.  Basically under
certain conditions, BD flag won't get set.

You can verify that by inserting various number of "nop" just
before the faulting places and observe certain address alignment
would show/hide this bug.

Further more I wrote a standalone kernel code and could not
reproduce it, which means it requires more conditions than just
address alignment.

NEC Europe knows about this problem.  Not sure if they passed
it to Japan where the chip is designed.  Their engineers
even had difficulty to understand what I was talking about. 

(more sighs)


Jun

On Mon, Jan 13, 2003 at 05:13:17PM +0100, Geert Uytterhoeven wrote:
> 
> I'm seeing a crash in 2.4.20 in emulate_load_store_insn(), when accepting a TCP
> connection (exact line number influenced by debug code):
> 
> Unhandled kernel unaligned access or invalid instruction in unaligned.c::emulate_load_store_insn, line 492:
> $0 : 00000000 10008400 30000000 00000000 83c2a380 83d9f80e 838941c0 00000001
> $8 : 00000016 c0a80002 c0a80001 00000016 83f326a4 83f326a8 83f326a0 00000000
> $16: 83c2a43c 811af440 00000000 83c2a380 803da18c 00000000 00000000 00000000
> $24: 00000000 2ac41330                   8039a000 8039baf8 a38415b4 8033eea4
> Hi : 00000000
> Lo : 00000140
> epc  : 80346448    Not tainted
> Status: 10008403
> Cause : 00000010
> Process swapper (pid: 0, stackpage=8039a000)
> Stack:    00000000 00000000 00000000 00000000 00000000 00000000 00000000
>  00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
>  00000000 00000000 00000000 00000000 00000000 00000000 00000000 8039a000
>  00000001 810d0060 802dd370 00000000 00000000 8039bb70 00000000 8041a690
>  803d2000 810c5de0 8041a620 810d0060 802dd370 80213fa4 810c41a0 8039bbc8
>  8020ad50 ...
> Call Trace:   [<802dd370>] [<802dd370>] [<80213fa4>] [<8020ad50>] [<802ea344>]
>  [<802ea2fc>] [<80307e08>] [<802378f8>] [<8020a0d4>] [<8020a0d4>] [<802061d8>]
>  [<802061d8>] [<8020a0d4>] [<8033eea4>] [<80346fbc>] [<80347060>] [<8034716c>]
>  [<803476f4>] [<80329a50>] [<80326648>] [<8032952c>] [<80329ddc>] [<80329d98>]
>  [<80329ddc>] [<8031700c>] [<80329790>] [<8031700c>] [<80316bb4>] [<803172b8>]
>  [<802df95c>] [<8021bf30>] [<80317500>] [<80316ecc>] [<8021b810>] [<80379278>]
>  [<8020ad50>] [<8020aeb0>] [<8020ae84>] [<80379228>] [<80204250>] ...
> 
> Code: 8cc30064  3c023000  00621824 <14600012> 8cb50010  8c840238  8c820004  90830000  00621007 
> Kernel panic: Aiee, killing interrupt handler!
> In interrupt handler - not syncing
> 
> 803463f8 <tcp_v4_conn_request>:
> 803463f8:	27bdfe20 	addiu	sp,sp,-480
> 803463fc:	afb601d8 	sw	s6,472(sp)
> 80346400:	afb301cc 	sw	s3,460(sp)
> 80346404:	afb101c4 	sw	s1,452(sp)
> 80346408:	afbf01dc 	sw	ra,476(sp)
> 8034640c:	afb501d4 	sw	s5,468(sp)
> 80346410:	afb401d0 	sw	s4,464(sp)
> 80346414:	afb201c8 	sw	s2,456(sp)
> 80346418:	afb001c0 	sw	s0,448(sp)
> 8034641c:	00a08821 	move	s1,a1
> 80346420:	8ca50020 	lw	a1,32(a1)
> 80346424:	8e260028 	lw	a2,40(s1)
> 80346428:	8e320044 	lw	s2,68(s1)
> 8034642c:	8ca2000c 	lw	v0,12(a1)
> 80346430:	00809821 	move	s3,a0
> 80346434:	0000b021 	move	s6,zero
> 80346438:	afa201b8 	sw	v0,440(sp)
> 8034643c:	8cc30064 	lw	v1,100(a2)
> 80346440:	3c023000 	lui	v0,0x3000
> 80346444:	00621824 	and	v1,v1,v0
> 80346448:	14600012 	bnez	v1,80346494 <tcp_v4_conn_request+0x9c>
> 8034644c:	8cb50010 	lw	s5,16(a1)
>                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> 80346450:	8c840238 	lw	a0,568(a0)
> 80346454:	8c820004 	lw	v0,4(a0)
> 80346458:	90830000 	lbu	v1,0(a0)
> 8034645c:	00621007 	srav	v0,v0,v1
> 
> If I print the parameters at label `sigill' in emulate_load_store_insn(), I
> get:
> 
>     pc 0x80346448 addr 0x83d9f81e ins 0x14600012
> 
> And emulate_load_store_insn() gets confused because 0x14600012 is not a
> load/store. 0x14600012 is the branch instruction before the load, not the load
> after the branch instruction! Note that bit 31 of cause (CAUSEF_BD) is not set.
> Some more investigations showed that the branch is indeed not taken.
> 
> Apparently if an unaligned access happens right after a branch which is not
> taking, epc points to the branch instruction, and CAUSEF_BD is not set
> (technically speaking, this is not a branch delay, since the branch is not
> taken :-). Is this expected behavior? The CPU is a VR4120A core.
> 
> As a workaround, I assume I can just test whether pc points to a branch
> instruction, and increment pc if that's the case?
> 
> Thanks!
> 
> Gr{oetje,eeting}s,
> 
> 						Geert
> 
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
> 
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like that.
> 							    -- Linus Torvalds
> 
> 

From uhler@mips.com Tue Jan 28 19:49:13 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 28 Jan 2003 19:49:14 +0000 (GMT)
Received: from ftp.mips.com ([IPv6:::ffff:206.31.31.227]:51603 "EHLO
	mx2.mips.com") by linux-mips.org with ESMTP id <S8225196AbTA1TtN>;
	Tue, 28 Jan 2003 19:49:13 +0000
Received: from newman.mips.com (ns-dmz [206.31.31.225])
	by mx2.mips.com (8.12.5/8.12.5) with ESMTP id h0SJmt67013084;
	Tue, 28 Jan 2003 11:48:55 -0800 (PST)
Received: from uhler-linux.mips.com (uhler-linux [192.168.11.222])
	by newman.mips.com (8.9.3/8.9.0) with ESMTP id LAA25336;
	Tue, 28 Jan 2003 11:48:55 -0800 (PST)
Received: from uhler-linux.mips.com (uhler@localhost)
	by uhler-linux.mips.com (8.11.2/8.9.3) with ESMTP id h0SJmug29073;
	Tue, 28 Jan 2003 11:48:56 -0800
Message-Id: <200301281948.h0SJmug29073@uhler-linux.mips.com>
X-Authentication-Warning: uhler-linux.mips.com: uhler owned process doing -bs
X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4
To: Jun Sun <jsun@mvista.com>
cc: Geert Uytterhoeven <geert@linux-m68k.org>,
	Linux/MIPS Development <linux-mips@linux-mips.org>
cc: uhler@mips.com
Reply-To: uhler@mips.com
Subject: Re: unaligned load in branch delay slot 
In-reply-to: Your message of "Tue, 28 Jan 2003 09:53:47 PST."
             <20030128095347.W11633@mvista.com> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Tue, 28 Jan 2003 11:48:56 -0800
From: "Mike Uhler" <uhler@mips.com>
Return-Path: <uhler@mips.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1257
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: uhler@mips.com
Precedence: bulk
X-list: linux-mips


> 
> Geert,
> 
> I had exactly the same problem with Vr4120A chip!
> 
> I have narrowed it down to be a hardware bug.  Basically under
> certain conditions, BD flag won't get set.
> 
> You can verify that by inserting various number of "nop" just
> before the faulting places and observe certain address alignment
> would show/hide this bug.
> 
> Further more I wrote a standalone kernel code and could not
> reproduce it, which means it requires more conditions than just
> address alignment.
> 
> NEC Europe knows about this problem.  Not sure if they passed
> it to Japan where the chip is designed.  Their engineers
> even had difficulty to understand what I was talking about. 

Let me give the list some background on this to aid in understanding.

When the MIPS I Architecture was originally defined (back in
1984), it included the architecturally-visible branch delay slot
that exists in the architecture today.  The Coprocessor 0
EPC register was defined to be the PC at which to restart after
an exception or an interrupt.  However, because an exception or
interrupt could occur while attempting to execute the instruction
in a branch delay slot, EPC could not simply point at that
instruction, because if the branch or jump was taken, restarting
at the delay slot PC doesn't account for the taken branch/jump.
As such, the architecture was specified such that if an exception
or interrupt was detected while attempting to execution the
instruction in a branch delay slot, EPC was defined to receive
the PC of the branch, and the BD bit was set in the Coprocessor 0
Cause register.  Most implementations of the MIPS Architecture did
exactly this.

In a few implementations of the MIPS Architecture (and I can't confirm
nor deny that this is the case with the NEC VR 41xx chips - I simply don't
know), the implementors observed that the restart PC could, in fact,
be the PC of the instruction in the delay slot, but only if the preceding
branch was known to be not-taken.  Restarting a not-taken branch
at the branch is equivalent to restarting at the delay slot in
terms of PC flow.  Note that this assumes that restarting at the
branch would not cause a different decision on the restart as
on the original execution, and this is required by the architecture.

Since the MIPS architecture has no not-taken jump instructions, there
should never be a case in which EPC points at the delay slot of a
jump, nor should there ever be a case in which EPC points at the
delay slot of a taken branch.

In the MIPS32 and MIPS64 Architecture, we explicitly require that the
value in EPC point at the branch/jump and that the BD bit be set in
the Cause register if an exception is detected in the delay slot.
Our compliance testing tests for this, and there are no compliant
implementations of the MIPS32 or MIPS64 Architecture which will
cause EPC to point to the delay slot of the branch (subject, of coure,
to an obscure bug).

As I mentioned earlier, there are some number of implementations of
earlier versions of the MIPS Architecture which apparently have
decided to point EPC at the delay slot instruction in the case of
a not-taken branch.  I can't give you a list of such implementations
because they pre-date our formal MIPS32/MIPS64 compliance testing.
I would hope that the users manual and/or errata sheets for chips
that do this would mention this as an issue.

So, the proposed code that went by on this list earlier can almost
certainly remove the jumps (they are always taken), and only adjust
PC if the previous instruction was a branch.

One word of warning, however:  Note that branch delay slots are
defined as DYNAMIC, not STATIC instructions.  Consider the following
example:

	...
5:	b	20f
	nop
	...
10:	b	someplace
20:	instruction-that-causes-exception

If the PC flow goes executions the branch at label 10 and detects
an exception on the instruction at label 20, EPC should point at
label 10, and the BD bit in Cause should be set.  However, if the branch
at label 5, with the nop in its delay slot, goes directly to the
excepting instruction at label 20, that instruction IS NOT in a
branch delay slot (remember, it's a dynamic relationship, not a
static one), so EPC would point at label 20 and the BD bit in cause
would not be set.

If the patch assumes that one can look backward by one instruction
in the STATIC code to determine if the instruction is in a
delay slot, one can not have code that jumps directly to the
instruction following another branch, as this would cause the
code to assume that it was in the delay slot of the branch.

This is exactly the reason why the architecture is defined in the
way that it is.

If anyone has any other questions, let me know.

/gmu

-- 

  =*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
  Michael Uhler, VP, Systems, Architecture, and Software Products 
  MIPS Technologies, Inc.   Email: uhler@mips.com   Pager: uhler_p@mips.com
  1225 Charleston Road      Voice:  (650)567-5025   FAX:   (650)567-5225
  Mountain View, CA 94043   Mobile: (650)868-6870   Admin: (650)567-5085



From justinca@cs.cmu.edu Tue Jan 28 21:31:05 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 28 Jan 2003 21:31:05 +0000 (GMT)
Received: from GS256.SP.CS.CMU.EDU ([IPv6:::ffff:128.2.199.27]:22450 "HELO
	gs256.sp.cs.cmu.edu") by linux-mips.org with SMTP
	id <S8225196AbTA1VbF>; Tue, 28 Jan 2003 21:31:05 +0000
Subject: [OT] Re: unaligned load in branch delay slot
From: justinca@cs.cmu.edu
To: linux-mips@linux-mips.org
In-Reply-To: <200301281948.h0SJmug29073@uhler-linux.mips.com>
References: <200301281948.h0SJmug29073@uhler-linux.mips.com>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Organization: 
Message-Id: <1043789409.23571.12.camel@gs256.sp.cs.cmu.edu>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.2.1 
Date: 28 Jan 2003 16:30:09 -0500
Source-Info: Sender is really justinca+@gs256.sp.cs.cmu.edu
Return-Path: <justinca@cs.cmu.edu>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1258
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: justinca@cs.cmu.edu
Precedence: bulk
X-list: linux-mips

On Tue, 2003-01-28 at 14:48, Mike Uhler wrote:

> If the patch assumes that one can look backward by one instruction
> in the STATIC code to determine if the instruction is in a
> delay slot, one can not have code that jumps directly to the
> instruction following another branch, as this would cause the
> code to assume that it was in the delay slot of the branch.

A while back, when working on a different architecture that also had
branch delay slots, it took me a while to get my head around the
branch-in-a-delay-slot case, e.g.


10:  b 100
20:  b 30
30:  foo
...
100: bar

where the actual program flow would be

10
20
100
30

and instruction 100 would be considered to be in the delay slot of 20.

I was *very* happy when I first looked at MIPS to see that this was 
specified as unpredictable, even if it was pretty cool to be able to
make the CPU execute a single instruction in the middle of nowhere. 
Pointless, but cool.  :)

-Justin

From uhler@mips.com Tue Jan 28 21:40:17 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 28 Jan 2003 21:40:18 +0000 (GMT)
Received: from ftp.mips.com ([IPv6:::ffff:206.31.31.227]:22168 "EHLO
	mx2.mips.com") by linux-mips.org with ESMTP id <S8225196AbTA1VkR>;
	Tue, 28 Jan 2003 21:40:17 +0000
Received: from newman.mips.com (ns-dmz [206.31.31.225])
	by mx2.mips.com (8.12.5/8.12.5) with ESMTP id h0SLdm67013617;
	Tue, 28 Jan 2003 13:39:51 -0800 (PST)
Received: from uhler-linux.mips.com (uhler-linux [192.168.11.222])
	by newman.mips.com (8.9.3/8.9.0) with ESMTP id NAA00600;
	Tue, 28 Jan 2003 13:39:48 -0800 (PST)
Received: from uhler-linux.mips.com (uhler@localhost)
	by uhler-linux.mips.com (8.11.2/8.9.3) with ESMTP id h0SLdmf29392;
	Tue, 28 Jan 2003 13:39:48 -0800
Message-Id: <200301282139.h0SLdmf29392@uhler-linux.mips.com>
X-Authentication-Warning: uhler-linux.mips.com: uhler owned process doing -bs
X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4
To: justinca@cs.cmu.edu
cc: linux-mips@linux-mips.org
cc: uhler@mips.com
Reply-To: uhler@mips.com
Subject: Re: [OT] Re: unaligned load in branch delay slot 
In-reply-to: Your message of "28 Jan 2003 16:30:09 EST."
             <1043789409.23571.12.camel@gs256.sp.cs.cmu.edu> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Tue, 28 Jan 2003 13:39:48 -0800
From: "Mike Uhler" <uhler@mips.com>
Return-Path: <uhler@mips.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1259
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: uhler@mips.com
Precedence: bulk
X-list: linux-mips

> On Tue, 2003-01-28 at 14:48, Mike Uhler wrote:
> 
> > If the patch assumes that one can look backward by one instruction
> > in the STATIC code to determine if the instruction is in a
> > delay slot, one can not have code that jumps directly to the
> > instruction following another branch, as this would cause the
> > code to assume that it was in the delay slot of the branch.
> 
> A while back, when working on a different architecture that also had
> branch delay slots, it took me a while to get my head around the
> branch-in-a-delay-slot case, e.g.
> 
> 
> 10:  b 100
> 20:  b 30
> 30:  foo
> ...
> 100: bar
> 
> where the actual program flow would be
> 
> 10
> 20
> 100
> 30
> 
> and instruction 100 would be considered to be in the delay slot of 20.
> 
> I was *very* happy when I first looked at MIPS to see that this was 
> specified as unpredictable, even if it was pretty cool to be able to
> make the CPU execute a single instruction in the middle of nowhere. 
> Pointless, but cool.  :)

I presume that you're talking about Sparc, where such a construct is
used to execute a single instruction out of a table.  This is, in
fact, very, very unpredictable on a MIPS implementation, ranging from
reserved instruction, to branching to one of the two branch targets,
to wandering off into hyperspace.  So please do not assume that because
a particular implementation does something that all implementations
do the same thing. In this particular case, I can guarantee you that
you won't like the answer you get.

/gmu

-- 

  =*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
  Michael Uhler, VP, Systems, Architecture, and Software Products 
  MIPS Technologies, Inc.   Email: uhler@mips.com   Pager: uhler_p@mips.com
  1225 Charleston Road      Voice:  (650)567-5025   FAX:   (650)567-5225
  Mountain View, CA 94043   Mobile: (650)868-6870   Admin: (650)567-5085



From jsun@orion.mvista.com Wed Jan 29 01:26:43 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 29 Jan 2003 01:26:44 +0000 (GMT)
Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:63989 "EHLO
	orion.mvista.com") by linux-mips.org with ESMTP id <S8225234AbTA2B0n>;
	Wed, 29 Jan 2003 01:26:43 +0000
Received: (from jsun@localhost)
	by orion.mvista.com (8.11.6/8.11.6) id h0T1QV028031;
	Tue, 28 Jan 2003 17:26:31 -0800
Date: Tue, 28 Jan 2003 17:26:31 -0800
From: Jun Sun <jsun@mvista.com>
To: Vivien Chappelier <vivienc@nerim.net>
Cc: Ralf Baechle <ralf@oss.sgi.com>, linux-mips@linux-mips.org,
	jsun@mvista.com
Subject: Re: [PATCH 2.5] FPU
Message-ID: <20030128172631.E11633@mvista.com>
References: <Pine.LNX.4.21.0301260251300.15950-100000@melkor> <20030127102929.N11633@mvista.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <20030127102929.N11633@mvista.com>; from jsun@mvista.com on Mon, Jan 27, 2003 at 10:29:29AM -0800
Return-Path: <jsun@orion.mvista.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1260
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: jsun@mvista.com
Precedence: bulk
X-list: linux-mips

On Mon, Jan 27, 2003 at 10:29:29AM -0800, Jun Sun wrote:
> On Sun, Jan 26, 2003 at 02:58:09AM +0100, Vivien Chappelier wrote:
> > Hi,
> > 
> > 	At various places in the 2.5 kernel, the fpu is accessed in
> > kernel mode with CU1 not set, causing an unexpected exception. This patch
> > makes sure FPU can be accessed by the kernel, though it may only
> > be a workaround. Any comment from someone with a better understanding of
> > the FPU access/context switching code?
> > 
> > Vivien.
> > 
> > --- include/asm-mips64/fpu.h	2002-12-11 20:44:20.000000000 +0100
> > +++ include/asm-mips64/fpu.h	2002-12-11 21:51:44.000000000 +0100
> > @@ -109,6 +109,7 @@
> >  
> >  static inline void save_fp(struct task_struct *tsk)
> >  {
> > +	enable_fpu();
> >  	if (mips_cpu.options & MIPS_CPU_FPU) 
> >  		_save_fp(tsk);
> >  }
> > --- include/asm-mips/fpu.h	2002-12-11 20:44:20.000000000 +0100
> > +++ include/asm-mips/fpu.h	2002-12-11 21:51:44.000000000 +0100
> > @@ -109,6 +109,7 @@
> >  
> >  static inline void save_fp(struct task_struct *tsk)
> >  {
> > +	enable_fpu();
> >  	if (mips_cpu.options & MIPS_CPU_FPU) 
> >  		_save_fp(tsk);
> >  }
> 
> The above two hunks seem to be right.
>

There are two places which call save_fp().  Just verified that in
both places current process should be fpu owner and therefore
FPU *should* be enabled.

Basically whenever current process is fpu owner, the FPU should be
enabled.  Apparently something in 2.5 breaks that fundamental assumption.
Will look into it later.

Jun

From brad@parker.boston.ma.us Wed Jan 29 01:39:07 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 29 Jan 2003 01:39:08 +0000 (GMT)
Received: from h0000c06cf87e.ne.client2.attbi.com ([IPv6:::ffff:24.147.212.21]:59911
	"EHLO compaq.parker.boston.ma.us") by linux-mips.org with ESMTP
	id <S8225234AbTA2BjH>; Wed, 29 Jan 2003 01:39:07 +0000
Received: from p2.parker.boston.ma.us (p2 [192.245.5.16])
	by compaq.parker.boston.ma.us (8.11.6/8.11.6) with ESMTP id h0T1d3M06983;
	Tue, 28 Jan 2003 20:39:04 -0500
Received: from p2 (brad@localhost)
	by p2.parker.boston.ma.us (8.11.2/8.11.2) with ESMTP id h0T1d3R01891;
	Tue, 28 Jan 2003 20:39:03 -0500
Message-Id: <200301290139.h0T1d3R01891@p2.parker.boston.ma.us>
To: Geert Uytterhoeven <geert@linux-m68k.org>
cc: Ralf Baechle <ralf@linux-mips.org>, Mike Uhler <uhler@mips.com>,
	Linux/MIPS Development <linux-mips@linux-mips.org>
Subject: Re: unaligned load in branch delay slot 
In-Reply-To: Message from Geert Uytterhoeven <geert@linux-m68k.org> 
   of "Tue, 28 Jan 2003 13:27:42 +0100." <Pine.GSO.4.21.0301281315380.9269-100000@vervain.sonytel.be> 
Date: Tue, 28 Jan 2003 20:39:03 -0500
From: Brad Parker <brad@parker.boston.ma.us>
Return-Path: <brad@parker.boston.ma.us>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1261
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: brad@parker.boston.ma.us
Precedence: bulk
X-list: linux-mips


Geert Uytterhoeven wrote:
>On Tue, 28 Jan 2003, Ralf Baechle wrote:
>> On Tue, Jan 28, 2003 at 10:30:20AM +0100, Geert Uytterhoeven wrote:
>> > If it happens, I should get a SIGILL, right?
>> 
>> Right.
>> 
>> Hmm...  If you can't reproduce this anymore I guess we should pull this
>> patch again?  Despite Mike basically acknowledging that such behaviour
>
>I cannot reproduce it in user space. I can still reproduce it in kernel space
>when an incoming TCP connection is accepted:
>
>| 8034d568 <tcp_v4_conn_request>:

I had a problem in tcp_rcv_established() where this "if" would trigger
even though "th->syn" was zero:

...
	if (th->syn && !before(TCP_SKB_CB(skb)->seq, tp->rcv_nxt)) {
...

It turned out the tcp header was 'misaligned' after coming across a
usb link.  I never figured out why it was failing, but it was clearly
the emulation code which was doing the wrong thing.  This was on an
alchemy au1000 (MIPS32).

also in the kernel...

-brad

From long21st@yahoo.com Wed Jan 29 03:14:29 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 29 Jan 2003 03:14:30 +0000 (GMT)
Received: from web40408.mail.yahoo.com ([IPv6:::ffff:66.218.78.105]:6705 "HELO
	web40408.mail.yahoo.com") by linux-mips.org with SMTP
	id <S8225234AbTA2DO3>; Wed, 29 Jan 2003 03:14:29 +0000
Message-ID: <20030129031421.89385.qmail@web40408.mail.yahoo.com>
Received: from [157.165.41.125] by web40408.mail.yahoo.com via HTTP; Tue, 28 Jan 2003 19:14:21 PST
Date: Tue, 28 Jan 2003 19:14:21 -0800 (PST)
From: Long Li <long21st@yahoo.com>
Subject: Possible bug in gcc for mips?
To: linux-mips@linux-mips.org
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Return-Path: <long21st@yahoo.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1262
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: long21st@yahoo.com
Precedence: bulk
X-list: linux-mips

Hi,

I built a gcc 3.0.4 mips crosscompiler on redhat
7.1(binutils 2.11.2). I embedded some inline assembly
in the C code. This is what I did:

 //get SR Bit from Status Register
 register unsigned int status_reg;
 register unsigned int warm_reset, cold_reset;

 asm volatile ("mfc0 %0,$12" :: "r"(status_reg));

  if ((status_reg >> 20) & 0x1) {
	warm_reset++;
  }
  else {
     cold_reset++;
  }


I compiled and disassembly the output. This is what
shows in the disassembly:

00000000 <init>:
   0:	27bdfff0 	addiu	sp,sp,-16
   4:	afbe0008 	sw	s8,8(sp)
   8:	03a0f025 	move	s8,sp
   c:	8fc20004 	lw	v0,4(s8)
  10:	40026000 	mfc0	v0,t4
  14:	8fc30004 	lw	v1,4(s8)
  18:	00000000 	nop
  1c:	00031502 	srl	v0,v1,0x14
  20:	30420001 	andi	v0,v0,0x1
  24:	10400009 	beqz	v0,4c <init+0x4c>
  28:	00000000 	nop

You can see the condition depends on the value of v1,
which is loaded from the stack, instead of v0, which
is the expected status register.

Is this a possible bug or a feature for gcc 3.0.4?


Thanks a lot!


Long


__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com

From ralf@linux-mips.org Wed Jan 29 06:40:24 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 29 Jan 2003 06:40:25 +0000 (GMT)
Received: from p508B69C2.dip.t-dialin.net ([IPv6:::ffff:80.139.105.194]:20141
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225197AbTA2GkY>; Wed, 29 Jan 2003 06:40:24 +0000
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.11.6/8.11.6) id h0T6eAN14945;
	Wed, 29 Jan 2003 07:40:10 +0100
Date: Wed, 29 Jan 2003 07:40:10 +0100
From: Ralf Baechle <ralf@linux-mips.org>
To: Brad Parker <brad@parker.boston.ma.us>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>,
	Mike Uhler <uhler@mips.com>,
	Linux/MIPS Development <linux-mips@linux-mips.org>
Subject: Re: unaligned load in branch delay slot
Message-ID: <20030129074010.A7741@linux-mips.org>
References: <geert@linux-m68k.org> <200301290139.h0T1d3R01891@p2.parker.boston.ma.us>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5.1i
In-Reply-To: <200301290139.h0T1d3R01891@p2.parker.boston.ma.us>; from brad@parker.boston.ma.us on Tue, Jan 28, 2003 at 08:39:03PM -0500
Return-Path: <ralf@linux-mips.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1263
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips

On Tue, Jan 28, 2003 at 08:39:03PM -0500, Brad Parker wrote:

> I had a problem in tcp_rcv_established() where this "if" would trigger
> even though "th->syn" was zero:
> 
> ...
> 	if (th->syn && !before(TCP_SKB_CB(skb)->seq, tp->rcv_nxt)) {
> ...
> 
> It turned out the tcp header was 'misaligned' after coming across a
> usb link.  I never figured out why it was failing, but it was clearly
> the emulation code which was doing the wrong thing.  This was on an
> alchemy au1000 (MIPS32).

A few days ago I fixed a special case in cvs where the unaligned handler
was misshandling the special case where

	bxx	$r1, dest
	load	$r1, offset($r2)

both instruction are using the same register $r1 and the effective address
offset + $r2 was missaligned.  In that case the emulation code was
executing the load instruction first then using the loaded value to deciede
if the branch was taken.

I know the bug was hitting in the netfilter code but chances are there are
other places in the network code affected as well.

  Ralf

From ralf@linux-mips.org Wed Jan 29 07:13:00 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 29 Jan 2003 07:13:01 +0000 (GMT)
Received: from p508B69C2.dip.t-dialin.net ([IPv6:::ffff:80.139.105.194]:15278
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225197AbTA2HNA>; Wed, 29 Jan 2003 07:13:00 +0000
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.11.6/8.11.6) id h0T7Cv515613;
	Wed, 29 Jan 2003 08:12:57 +0100
Date: Wed, 29 Jan 2003 08:12:56 +0100
From: Ralf Baechle <ralf@linux-mips.org>
To: Long Li <long21st@yahoo.com>
Cc: linux-mips@linux-mips.org
Subject: Re: Possible bug in gcc for mips?
Message-ID: <20030129081256.B7741@linux-mips.org>
References: <20030129031421.89385.qmail@web40408.mail.yahoo.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5.1i
In-Reply-To: <20030129031421.89385.qmail@web40408.mail.yahoo.com>; from long21st@yahoo.com on Tue, Jan 28, 2003 at 07:14:21PM -0800
Return-Path: <ralf@linux-mips.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1264
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips

On Tue, Jan 28, 2003 at 07:14:21PM -0800, Long Li wrote:

> Subject: Possible bug in gcc for mips?

It's always possible to blame the tools for broken source.

>  asm volatile ("mfc0 %0,$12" :: "r"(status_reg));

Make that:

asm volatile ("mfc0 %0,$12" : "=r"(status_reg));

> Is this a possible bug or a feature for gcc 3.0.4?

Yes.  Broken source in, broken code out :-)

  Ralf

From ralf@linux-mips.org Wed Jan 29 07:28:36 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 29 Jan 2003 07:28:36 +0000 (GMT)
Received: from p508B69C2.dip.t-dialin.net ([IPv6:::ffff:80.139.105.194]:25518
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225197AbTA2H2g>; Wed, 29 Jan 2003 07:28:36 +0000
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.11.6/8.11.6) id h0T7SN015942;
	Wed, 29 Jan 2003 08:28:23 +0100
Date: Wed, 29 Jan 2003 08:28:23 +0100
From: Ralf Baechle <ralf@linux-mips.org>
To: Juan Quintela <quintela@mandrakesoft.com>
Cc: Jun Sun <jsun@mvista.com>, linux-mips@linux-mips.org
Subject: Re: [RFC & PATCH]  fixing tlb flush race problem on smp
Message-ID: <20030129082822.C7741@linux-mips.org>
References: <20030121143726.C16939@mvista.com> <86bs297hpd.fsf@trasno.mitica>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5.1i
In-Reply-To: <86bs297hpd.fsf@trasno.mitica>; from quintela@mandrakesoft.com on Wed, Jan 22, 2003 at 08:43:26AM +0100
Return-Path: <ralf@linux-mips.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1265
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips

On Wed, Jan 22, 2003 at 08:43:26AM +0100, Juan Quintela wrote:

> jun> +	__save_and_cli(flags);
> 
> s/__save_and_cli()/local_irq_save()/
> 
> jun> +	__restore_flags(flags);
> 
> s/__restore_flags()/local_irq_restore()/
> 
> Same in the other occurence, please.

I've already done this recently for large parts of arch/mips* and
include/asm-mips*.

  Ralf

From ralf@linux-mips.org Wed Jan 29 08:06:32 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 29 Jan 2003 08:06:32 +0000 (GMT)
Received: from p508B69C2.dip.t-dialin.net ([IPv6:::ffff:80.139.105.194]:60590
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225197AbTA2IGc>; Wed, 29 Jan 2003 08:06:32 +0000
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.11.6/8.11.6) id h0T86Rr16755;
	Wed, 29 Jan 2003 09:06:27 +0100
Date: Wed, 29 Jan 2003 09:06:27 +0100
From: Ralf Baechle <ralf@linux-mips.org>
To: Jun Sun <jsun@mvista.com>
Cc: Juan Quintela <quintela@mandrakesoft.com>,
	linux-mips@linux-mips.org
Subject: Re: [RFC & PATCH]  fixing tlb flush race problem on smp
Message-ID: <20030129090627.D7741@linux-mips.org>
References: <20030121143726.C16939@mvista.com> <86bs297hpd.fsf@trasno.mitica> <20030127170346.S11633@mvista.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5.1i
In-Reply-To: <20030127170346.S11633@mvista.com>; from jsun@mvista.com on Mon, Jan 27, 2003 at 05:03:46PM -0800
Return-Path: <ralf@linux-mips.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1266
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips

On Mon, Jan 27, 2003 at 05:03:46PM -0800, Jun Sun wrote:

> I also find a stupid typo and a subtle hole in my original patch.
> Here is an updated version, for 2.4/mips only.  If it looks ok, I 
> will extend to other sub-arches/trees.
> 
> This new one is pretty nice in that all mmu related operations
> are put into one file and it is much easier to ensure correctness
> later.

I like this one.

> +
> +	/*
> +	 * Mark current->active_mm as not "active" anymore.
> +	 * We don't want to mislead possible IPI tlb flush routines.
> +	 */
> +	clear_bit(cpu, &prev->cpu_vm_mask);
> +	set_bit(cpu, &next->cpu_vm_mask);
> +
> +	local_irq_restore(flags);

I don't think it's necessary to protect the clear_bit and set_bit operations
with local_irq_save ... local_irq_restore.

In addition because switch_mm is always called with interrupts enabled you
can simplify that to local_irq_disable ... local_irq_enable.

  Ralf

From skippie@skynet.be Wed Jan 29 10:06:55 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 29 Jan 2003 10:06:55 +0000 (GMT)
Received: from queen.kulnet.kuleuven.ac.be ([IPv6:::ffff:134.58.240.43]:51135
	"EHLO queen.kulnet.kuleuven.ac.be") by linux-mips.org with ESMTP
	id <S8225197AbTA2KGy>; Wed, 29 Jan 2003 10:06:54 +0000
Received: from crassus.kulnet.kuleuven.ac.be (queen [127.0.0.1])
	by queen.kulnet.kuleuven.ac.be (Postfix) with SMTP id 9227F1881E7
	for <linux-mips@linux-mips.org>; Wed, 29 Jan 2003 11:06:46 +0100 (CET)
Received: through eSafe SMTP Relay 1041503224; Wed Jan 29 11:06:46 2003
Received: from there (basecamp.kotnet.org [10.4.9.38])
	by crassus.kulnet.kuleuven.ac.be (Postfix) with SMTP id D2A6E13EC04
	for <linux-mips@linux-mips.org>; Wed, 29 Jan 2003 11:06:45 +0100 (CET)
Content-Type: text/plain;
  charset="iso-8859-1"
From: Skippie <skippie@skynet.be>
Reply-To: skippie@skynet.be
Organization: Xperience
To: linux-mips@linux-mips.org
Subject: XFree XZ support
Date: Wed, 29 Jan 2003 11:06:43 +0100
X-Mailer: KMail [version 1.3.2]
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Message-Id: <20030129100645.D2A6E13EC04@crassus.kulnet.kuleuven.ac.be>
Return-Path: <skippie@skynet.be>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1267
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: skippie@skynet.be
Precedence: bulk
X-list: linux-mips

hi,

I'm considdering installing debian on my SGI Indy
but I have a little question.

My indy has a R5000 cpu
and a XZ graphics card.

I cant find a conclusif answer if that graphics card is suppordet
on the newest XFree 4.2.1 server.

does anyone have experience installing X on a system whist this kind
of configuration?

thanks in advance.

Greetz
Skippie
-- 
mail: skippie@skynet.be

From agx@sigxcpu.org Wed Jan 29 10:58:14 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 29 Jan 2003 10:58:14 +0000 (GMT)
Received: from honk1.physik.uni-konstanz.de ([IPv6:::ffff:134.34.144.71]:9420
	"EHLO honk1.physik.uni-konstanz.de") by linux-mips.org with ESMTP
	id <S8225197AbTA2K6O>; Wed, 29 Jan 2003 10:58:14 +0000
Received: from bogon.sigxcpu.org (unknown [134.34.147.122])
	by honk1.physik.uni-konstanz.de (Postfix) with ESMTP id 1431F2BC2D
	for <linux-mips@linux-mips.org>; Wed, 29 Jan 2003 11:58:03 +0100 (CET)
Received: by bogon.sigxcpu.org (Postfix, from userid 1000)
	id A35284AF4B; Wed, 29 Jan 2003 11:55:55 +0100 (CET)
Date: Wed, 29 Jan 2003 11:55:55 +0100
From: Guido Guenther <agx@sigxcpu.org>
To: linux-mips@linux-mips.org
Subject: Re: XFree XZ support
Message-ID: <20030129105555.GL23999@bogon.ms20.nix>
Mail-Followup-To: Guido Guenther <agx@sigxcpu.org>,
	linux-mips@linux-mips.org
References: <20030129100645.D2A6E13EC04@crassus.kulnet.kuleuven.ac.be>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20030129100645.D2A6E13EC04@crassus.kulnet.kuleuven.ac.be>
User-Agent: Mutt/1.4i
Return-Path: <agx@sigxcpu.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1268
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: agx@sigxcpu.org
Precedence: bulk
X-list: linux-mips

Hi Skippie,
On Wed, Jan 29, 2003 at 11:06:43AM +0100, Skippie wrote:
> I'm considdering installing debian on my SGI Indy
> but I have a little question.
> 
> My indy has a R5000 cpu
> and a XZ graphics card.
> 
> I cant find a conclusif answer if that graphics card is suppordet
> on the newest XFree 4.2.1 server.
No. Help on getting this to work is appreciated.
 -- Guido

From skippie@skynet.be Wed Jan 29 13:15:50 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 29 Jan 2003 13:15:51 +0000 (GMT)
Received: from queen.kulnet.kuleuven.ac.be ([IPv6:::ffff:134.58.240.43]:60653
	"EHLO queen.kulnet.kuleuven.ac.be") by linux-mips.org with ESMTP
	id <S8225197AbTA2NPu>; Wed, 29 Jan 2003 13:15:50 +0000
Received: from crassus.kulnet.kuleuven.ac.be (queen [127.0.0.1])
	by queen.kulnet.kuleuven.ac.be (Postfix) with SMTP id 6734E1881DD
	for <linux-mips@linux-mips.org>; Wed, 29 Jan 2003 14:15:44 +0100 (CET)
Received: through eSafe SMTP Relay 1041503224; Wed Jan 29 14:15:43 2003
Received: from there (basecamp.kotnet.org [10.4.9.38])
	by crassus.kulnet.kuleuven.ac.be (Postfix) with SMTP id D9C3C13EC0A
	for <linux-mips@linux-mips.org>; Wed, 29 Jan 2003 14:15:42 +0100 (CET)
Content-Type: text/plain;
  charset="iso-8859-1"
X-KMail-Redirect-From: Skippie <skippie@skynet.be>
Subject: Re: XFree XZ support
From: Skippie <skippie@skynet.be> (by way of Skippie <skippie@skynet.be>)
Date: Wed, 29 Jan 2003 14:15:41 +0100
To: linux-mips@linux-mips.org
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Message-Id: <20030129131542.D9C3C13EC0A@crassus.kulnet.kuleuven.ac.be>
Return-Path: <skippie@skynet.be>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1269
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: skippie@skynet.be
Precedence: bulk
X-list: linux-mips

> Hi Skippie,
>
> On Wed, Jan 29, 2003 at 11:06:43AM +0100, Skippie wrote:
> > I'm considdering installing debian on my SGI Indy
> > but I have a little question.
> >
> > My indy has a R5000 cpu
> > and a XZ graphics card.
> >
> > I cant find a conclusif answer if that graphics card is suppordet
> > on the newest XFree 4.2.1 server.
>
> No. Help on getting this to work is appreciated.
>  -- Guido

could it than be possible to use fbdev for the xz card, or is this also
unsupported?

if it is possible, anny sugestions?

thanks

--
Greetz
Skippie
--
mail: skippie@skynet.be

From ralf@linux-mips.org Wed Jan 29 13:50:16 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 29 Jan 2003 13:50:16 +0000 (GMT)
Received: from p508B69C2.dip.t-dialin.net ([IPv6:::ffff:80.139.105.194]:30900
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225241AbTA2NuQ>; Wed, 29 Jan 2003 13:50:16 +0000
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.11.6/8.11.6) id h0TDo6E25774;
	Wed, 29 Jan 2003 14:50:06 +0100
Date: Wed, 29 Jan 2003 14:50:06 +0100
From: Ralf Baechle <ralf@linux-mips.org>
To: Skippie <skippie@skynet.be>
Cc: linux-mips@linux-mips.org
Subject: Re: XFree XZ support
Message-ID: <20030129145006.A25701@linux-mips.org>
References: <20030129131542.D9C3C13EC0A@crassus.kulnet.kuleuven.ac.be>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5.1i
In-Reply-To: <20030129131542.D9C3C13EC0A@crassus.kulnet.kuleuven.ac.be>; from skippie@skynet.be on Wed, Jan 29, 2003 at 02:15:41PM +0100
Return-Path: <ralf@linux-mips.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1270
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips

On Wed, Jan 29, 2003 at 02:15:41PM +0100, Skippie wrote:

> could it than be possible to use fbdev for the xz card, or is this also
> unsupported?

This is a card that's magnitudes too complex to support.  Even with docs
it was to hard.  Something as trivial as printing a character to the
screen involves writing firmware for the i860 processor(s) of the XZ.

  Ralf

From ralf@linux-mips.org Wed Jan 29 14:25:55 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 29 Jan 2003 14:25:55 +0000 (GMT)
Received: from p508B69C2.dip.t-dialin.net ([IPv6:::ffff:80.139.105.194]:61620
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225241AbTA2OZz>; Wed, 29 Jan 2003 14:25:55 +0000
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.11.6/8.11.6) id h0TEPht26540;
	Wed, 29 Jan 2003 15:25:43 +0100
Date: Wed, 29 Jan 2003 15:25:43 +0100
From: Ralf Baechle <ralf@linux-mips.org>
To: Mike Uhler <uhler@mips.com>
Cc: Jun Sun <jsun@mvista.com>,
	Geert Uytterhoeven <geert@linux-m68k.org>,
	Linux/MIPS Development <linux-mips@linux-mips.org>
Subject: Re: unaligned load in branch delay slot
Message-ID: <20030129152543.B25701@linux-mips.org>
References: <20030128095347.W11633@mvista.com> <200301281948.h0SJmug29073@uhler-linux.mips.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5.1i
In-Reply-To: <200301281948.h0SJmug29073@uhler-linux.mips.com>; from uhler@mips.com on Tue, Jan 28, 2003 at 11:48:56AM -0800
Return-Path: <ralf@linux-mips.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1271
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips

Mike,

On Tue, Jan 28, 2003 at 11:48:56AM -0800, Mike Uhler wrote:

> Let me give the list some background on this to aid in understanding.

Thanks for elaborating on this problem.

My workaround was trying so deal with a different problem so I'm going to
pull that patch again until the nature of Geert's problem is fully
understood.

  Ralf

From skippie@skynet.be Wed Jan 29 14:32:43 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 29 Jan 2003 14:32:44 +0000 (GMT)
Received: from queen.kulnet.kuleuven.ac.be ([IPv6:::ffff:134.58.240.43]:46227
	"EHLO queen.kulnet.kuleuven.ac.be") by linux-mips.org with ESMTP
	id <S8225241AbTA2Ocn>; Wed, 29 Jan 2003 14:32:43 +0000
Received: from crassus.kulnet.kuleuven.ac.be (queen [127.0.0.1])
	by queen.kulnet.kuleuven.ac.be (Postfix) with SMTP id 272971881AD
	for <linux-mips@linux-mips.org>; Wed, 29 Jan 2003 15:32:38 +0100 (CET)
Received: through eSafe SMTP Relay 1041503224; Wed Jan 29 15:32:38 2003
Received: from there (basecamp.kotnet.org [10.4.9.38])
	by crassus.kulnet.kuleuven.ac.be (Postfix) with SMTP id 8D59413EC09
	for <linux-mips@linux-mips.org>; Wed, 29 Jan 2003 15:32:37 +0100 (CET)
Content-Type: text/plain;
  charset="iso-8859-1"
X-KMail-Redirect-From: Skippie <skippie@skynet.be>
Subject: Re: XFree XZ support
From: Skippie <skippie@skynet.be> (by way of Skippie <skippie@skynet.be>)
Date: Wed, 29 Jan 2003 15:32:36 +0100
To: linux-mips@linux-mips.org
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Message-Id: <20030129143237.8D59413EC09@crassus.kulnet.kuleuven.ac.be>
Return-Path: <skippie@skynet.be>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1272
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: skippie@skynet.be
Precedence: bulk
X-list: linux-mips

> This is a card that's magnitudes too complex to support.  Even with docs
> it was to hard.  Something as trivial as printing a character to the
> screen involves writing firmware for the i860 processor(s) of the XZ.
>
>   Ralf

I will have to wait until there is Xfree support for this card.
(if this will ever be)

Thanks for all the reactions.

--
Greetz
Skippie
--
mail: skippie@skynet.be

From cwu@deltartp.com Wed Jan 29 21:14:01 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 29 Jan 2003 21:14:02 +0000 (GMT)
Received: from mail.deltartp.com ([IPv6:::ffff:216.166.210.181]:16395 "EHLO
	dprn03.deltartp.com") by linux-mips.org with ESMTP
	id <S8225248AbTA2VOB>; Wed, 29 Jan 2003 21:14:01 +0000
Received: by dprn03.deltartp.com with Internet Mail Service (5.5.2653.19)
	id <DM946JQ4>; Wed, 29 Jan 2003 15:56:43 -0500
Message-ID: <A4E787A2467EF849B00585F14C9005590689D6@dprn03.deltartp.com>
From: Chien-Lung Wu <cwu@deltartp.com>
To: "'linux-mips@linux-mips.org'" <linux-mips@linux-mips.org>
Subject: verify/test a new cross-compiler
Date: Wed, 29 Jan 2003 15:56:32 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Return-Path: <cwu@deltartp.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1273
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: cwu@deltartp.com
Precedence: bulk
X-list: linux-mips

Hi, 

I built a cross-compiler (mips-linux) on i686-linux host using
	binutil-2.13
	gcc-3.0
	glibc-2.2.3


Now the question is 
	how can I verify/test this cross-compiler work?

Are there any test-cases/methods I can download to verify it?
Thanks for your help.

Chien-Lung

From earlm@mips.com Wed Jan 29 21:49:19 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 29 Jan 2003 21:49:19 +0000 (GMT)
Received: from mx2.mips.com ([IPv6:::ffff:206.31.31.227]:63451 "EHLO
	mx2.mips.com") by linux-mips.org with ESMTP id <S8225248AbTA2VtT>;
	Wed, 29 Jan 2003 21:49:19 +0000
Received: from newman.mips.com (ns-dmz [206.31.31.225])
	by mx2.mips.com (8.12.5/8.12.5) with ESMTP id h0TLn667019942;
	Wed, 29 Jan 2003 13:49:07 -0800 (PST)
Received: from xchange.mips.com (xchange [192.168.20.31])
	by newman.mips.com (8.9.3/8.9.0) with ESMTP id NAA04263;
	Wed, 29 Jan 2003 13:49:08 -0800 (PST)
Received: by xchange.mips.com with Internet Mail Service (5.5.2653.19)
	id <S30VWH61>; Wed, 29 Jan 2003 13:46:45 -0800
Message-ID: <0C5F4C7A1E3ED51194E200508B2CE32A01B03304@xchange.mips.com>
From: "Mitchell, Earl" <earlm@mips.com>
To: "'Chien-Lung Wu'" <cwu@deltartp.com>,
	"'linux-mips@linux-mips.org'" <linux-mips@linux-mips.org>
Subject: RE: verify/test a new cross-compiler
Date: Wed, 29 Jan 2003 13:46:44 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Return-Path: <earlm@mips.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1274
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: earlm@mips.com
Precedence: bulk
X-list: linux-mips

Read this. May be different for cross-compiler.
These instructions assume native compiler I think.

http://gcc.gnu.org/install/test.html

-earlm

-----Original Message-----
From: Chien-Lung Wu [mailto:cwu@deltartp.com] 
Sent: Wednesday, January 29, 2003 12:57 PM
To: 'linux-mips@linux-mips.org'
Subject: verify/test a new cross-compiler

Hi, 

I built a cross-compiler (mips-linux) on i686-linux host using
	binutil-2.13
	gcc-3.0
	glibc-2.2.3


Now the question is 
	how can I verify/test this cross-compiler work?

Are there any test-cases/methods I can download to verify it?
Thanks for your help.

Chien-Lung

From ilya@gateway.total-knowledge.com Thu Jan 30 02:46:18 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 30 Jan 2003 02:46:19 +0000 (GMT)
Received: from 12-234-207-60.client.attbi.com ([IPv6:::ffff:12.234.207.60]:1757
	"HELO gateway.total-knowledge.com") by linux-mips.org with SMTP
	id <S8225251AbTA3CqS>; Thu, 30 Jan 2003 02:46:18 +0000
Received: (qmail 13601 invoked by uid 502); 30 Jan 2003 02:46:11 -0000
Date: Wed, 29 Jan 2003 18:46:11 -0800
From: ilya@theIlya.com
To: Skippie <skippie@skynet.be>
Cc: linux-mips@linux-mips.org
Subject: Re: XFree XZ support
Message-ID: <20030130024611.GG15214@gateway.total-knowledge.com>
References: <20030129143237.8D59413EC09@crassus.kulnet.kuleuven.ac.be>
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="Wtrm9ATX0sn6fFKv"
Content-Disposition: inline
In-Reply-To: <20030129143237.8D59413EC09@crassus.kulnet.kuleuven.ac.be>
User-Agent: Mutt/1.4i
Return-Path: <ilya@gateway.total-knowledge.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1275
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ilya@theIlya.com
Precedence: bulk
X-list: linux-mips


--Wtrm9ATX0sn6fFKv
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Hold it there. I thought Impacts are the ones with i860...
You were either lying to me back then, or now.

On Wed, Jan 29, 2003 at 03:32:36PM +0100, Skippie wrote:
> > This is a card that's magnitudes too complex to support.  Even with docs
> > it was to hard.  Something as trivial as printing a character to the
> > screen involves writing firmware for the i860 processor(s) of the XZ.
> >
> >   Ralf
>=20
> I will have to wait until there is Xfree support for this card.
> (if this will ever be)
>=20
> Thanks for all the reactions.
>=20
> --
> Greetz
> Skippie
> --
> mail: skippie@skynet.be
>=20

--Wtrm9ATX0sn6fFKv
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE+OJHy7sVBmHZT8w8RArQ5AJ9EK7K+bfCfwggxj5dkZb4lQGzooACfX8Vl
ocWdeDZtl1YjE80lWl8Qp4I=
=A+6r
-----END PGP SIGNATURE-----

--Wtrm9ATX0sn6fFKv--

From jormes@wideopenwest.com Thu Jan 30 21:29:18 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 30 Jan 2003 21:29:18 +0000 (GMT)
Received: from heffalump.fnal.gov ([IPv6:::ffff:131.225.9.20]:34255 "EHLO
	fnal.gov") by linux-mips.org with ESMTP id <S8225254AbTA3V3R>;
	Thu, 30 Jan 2003 21:29:17 +0000
Received: from ppd89948 ([131.225.55.68])
 by smtp.fnal.gov (PMDF V6.0-24 #37519) with ESMTP id
 <0H9J001CSQCS2Q@smtp.fnal.gov> for linux-mips@linux-mips.org; Thu,
 30 Jan 2003 15:29:16 -0600 (CST)
Date: Thu, 30 Jan 2003 15:29:16 -0600
From: Jason Ormes <jormes@wideopenwest.com>
Subject: compiling mips64 problem
To: linux-mips@linux-mips.org
Message-id: <002801c2c8a6$a41f3470$4437e183@fermi.win.fnal.gov>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-Mailer: Microsoft Outlook, Build 10.0.4024
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7bit
Importance: Normal
X-Priority: 3 (Normal)
X-MSMail-priority: Normal
Return-Path: <jormes@wideopenwest.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1276
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: jormes@wideopenwest.com
Precedence: bulk
X-list: linux-mips

Hello,

I downloaded and installed from ftp.linux-mips.org

binutils-mips64-linux-2.13.1-1.i386.rpm
egcs-mips64-linux-1.1.2-4.i386.rpm

I got the kernel from the cvs repository and configured it for a mips64
kernel.

When I try to build it I get 

arch/mips64/lib/memcpy.S: Assembler messages:
arch/mips64/lib/memcpy.S:220: Error: illegal operands `lw
t4,((4)*4)($5)'
arch/mips64/lib/memcpy.S:221: Error: illegal operands `lw
t7,((5)*4)($5)'
arch/mips64/lib/memcpy.S:230: Error: illegal operands `sw
t4,((-4)*4)($4)'
arch/mips64/lib/memcpy.S:231: Error: illegal operands `sw
t7,((-3)*4)($4)'
make[1]: *** [arch/mips64/lib/memcpy.o] Error 1

could someone throw me a bone and let me know what I'm doing wrong?

Jason Ormes



From long21st@yahoo.com Thu Jan 30 22:45:51 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 30 Jan 2003 22:45:51 +0000 (GMT)
Received: from web40414.mail.yahoo.com ([IPv6:::ffff:66.218.78.111]:159 "HELO
	web40414.mail.yahoo.com") by linux-mips.org with SMTP
	id <S8225256AbTA3Wpv>; Thu, 30 Jan 2003 22:45:51 +0000
Message-ID: <20030130224543.7903.qmail@web40414.mail.yahoo.com>
Received: from [157.165.41.125] by web40414.mail.yahoo.com via HTTP; Thu, 30 Jan 2003 14:45:43 PST
Date: Thu, 30 Jan 2003 14:45:43 -0800 (PST)
From: Long Li <long21st@yahoo.com>
Subject: How to get the c source code in disassembly?
To: linux-mips@linux-mips.org
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Return-Path: <long21st@yahoo.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1277
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: long21st@yahoo.com
Precedence: bulk
X-list: linux-mips

Hi, 

I am having a problem with intermixing the C source
code in the disassembly. I am using a MIPS
crosscompiler on Redhat 7.1, gcc-3.0.4,
binutils-2.11.2. When I compiled the C code, I added
the -g option, and then use 'objdump -Sd' to get the
disassembly. However, I did not see any C code mixed
with the assembly, as said in the objdump manual when
using -S option. Could you give me some help or
suggestions? 

Thanks a lot!


Long


__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com

From long21st@yahoo.com Thu Jan 30 23:11:34 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 30 Jan 2003 23:11:35 +0000 (GMT)
Received: from web40412.mail.yahoo.com ([IPv6:::ffff:66.218.78.109]:62260 "HELO
	web40412.mail.yahoo.com") by linux-mips.org with SMTP
	id <S8225256AbTA3XLe>; Thu, 30 Jan 2003 23:11:34 +0000
Message-ID: <20030130231119.65802.qmail@web40412.mail.yahoo.com>
Received: from [157.165.41.125] by web40412.mail.yahoo.com via HTTP; Thu, 30 Jan 2003 15:11:19 PST
Date: Thu, 30 Jan 2003 15:11:19 -0800 (PST)
From: Long Li <long21st@yahoo.com>
Subject: register declared variable for no optimization
To: linux-mips@linux-mips.org
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Return-Path: <long21st@yahoo.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1278
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: long21st@yahoo.com
Precedence: bulk
X-list: linux-mips

Hi,

I have a question on the GCC optimization. I am using
GCC3.0.4 MIPS crosscompiler on Redhat 7.1. In a
function I did the following:

init()
{
  register unsigned int temp;
      .
      .
  temp = devict.dev1.devtc
      .
} 

I compiled the code with optimization level 0 and
found something weird about the register variable
temp. This is shows in the disassembly file:

for temp = devict.dev1.devtc
    lui $3, 0xb801
    lw  $3, 28($3)

This is right since the CPU loads the
devict.dev1.devtc value from memory to the register 3.
However, after the above instructions, I found:

     nop
     sw $3, 0($30)
     lw $2, 0($30)

now the compiler asked the CPU to store the register
in the stack. However, I declared the variable as a
register, how come it still needs to go to the stack?
I compiled the same code with gcc-2.8.1, optimization
level 0, and did not find the same issue there. 

Why the gcc-3.0.4 did the weird stuff? Do I have to
use at least level 1 to make the register declared
work for it?

Thanks a lot!


Long

 


__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com

From kaos@sgi.com Fri Jan 31 00:27:46 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 31 Jan 2003 00:27:47 +0000 (GMT)
Received: from zok.sgi.com ([IPv6:::ffff:204.94.215.101]:17619 "EHLO
	zok.sgi.com") by linux-mips.org with ESMTP id <S8225256AbTAaA1q>;
	Fri, 31 Jan 2003 00:27:46 +0000
Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130])
	by zok.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with SMTP id h0UNYRKp018044;
	Thu, 30 Jan 2003 15:34:28 -0800
Received: from kao2.melbourne.sgi.com (kao2.melbourne.sgi.com [134.14.55.180]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA13878; Fri, 31 Jan 2003 11:27:40 +1100
Received: by kao2.melbourne.sgi.com (Postfix, from userid 16331)
	id 53B5A300087; Fri, 31 Jan 2003 11:27:40 +1100 (EST)
Received: from kao2.melbourne.sgi.com (localhost [127.0.0.1])
	by kao2.melbourne.sgi.com (Postfix) with ESMTP
	id 2A63A8F; Fri, 31 Jan 2003 11:27:40 +1100 (EST)
X-Mailer: exmh version 2.4 06/23/2000 with nmh-1.0.4
From: Keith Owens <kaos@sgi.com>
To: Long Li <long21st@yahoo.com>
Cc: linux-mips@linux-mips.org
Subject: Re: How to get the c source code in disassembly? 
In-reply-to: Your message of "Thu, 30 Jan 2003 14:45:43 -0800."
             <20030130224543.7903.qmail@web40414.mail.yahoo.com> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Fri, 31 Jan 2003 11:27:34 +1100
Message-ID: <27733.1043972854@kao2.melbourne.sgi.com>
Return-Path: <kaos@sgi.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1279
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: kaos@sgi.com
Precedence: bulk
X-list: linux-mips

On Thu, 30 Jan 2003 14:45:43 -0800 (PST), 
Long Li <long21st@yahoo.com> wrote:
>I am having a problem with intermixing the C source
>code in the disassembly. I am using a MIPS
>crosscompiler on Redhat 7.1, gcc-3.0.4,
>binutils-2.11.2. When I compiled the C code, I added
>the -g option, and then use 'objdump -Sd' to get the
>disassembly. However, I did not see any C code mixed
>with the assembly, as said in the objdump manual when
>using -S option. Could you give me some help or
>suggestions? 

objdump -S only works when the code is compiled with -g.  And sometimes
not even then, objdump -S is flaky for ia64, although that could be the
old gcc/binutils I have to use :(.


From ralf@linux-mips.org Fri Jan 31 02:20:56 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 31 Jan 2003 02:20:57 +0000 (GMT)
Received: from p508B5ED1.dip.t-dialin.net ([IPv6:::ffff:80.139.94.209]:30421
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225256AbTAaCU4>; Fri, 31 Jan 2003 02:20:56 +0000
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.11.6/8.11.6) id h0V2KqJ08008;
	Fri, 31 Jan 2003 03:20:52 +0100
Date: Fri, 31 Jan 2003 03:20:52 +0100
From: Ralf Baechle <ralf@linux-mips.org>
To: Long Li <long21st@yahoo.com>
Cc: linux-mips@linux-mips.org
Subject: Re: register declared variable for no optimization
Message-ID: <20030131032052.A7245@linux-mips.org>
References: <20030130231119.65802.qmail@web40412.mail.yahoo.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5.1i
In-Reply-To: <20030130231119.65802.qmail@web40412.mail.yahoo.com>; from long21st@yahoo.com on Thu, Jan 30, 2003 at 03:11:19PM -0800
Return-Path: <ralf@linux-mips.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1280
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips

On Thu, Jan 30, 2003 at 03:11:19PM -0800, Long Li wrote:

> Why the gcc-3.0.4 did the weird stuff? Do I have to
> use at least level 1 to make the register declared
> work for it?

Most modern C compilers simply ignore the register specifier because in
practice it would result in worse code and as for code quality the
result of -O0 are not of interest anyway.

Linux code must be optmized at least -O1 or it probably won't build or
work properly.

  Ralf

From ralf@linux-mips.org Fri Jan 31 09:48:23 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 31 Jan 2003 09:48:24 +0000 (GMT)
Received: from p508B5ED1.dip.t-dialin.net ([IPv6:::ffff:80.139.94.209]:18651
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225229AbTAaJsX>; Fri, 31 Jan 2003 09:48:23 +0000
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.11.6/8.11.6) id h0V9mE720685;
	Fri, 31 Jan 2003 10:48:15 +0100
Date: Fri, 31 Jan 2003 10:48:14 +0100
From: Ralf Baechle <ralf@linux-mips.org>
To: ilya@theIlya.com
Cc: Skippie <skippie@skynet.be>, linux-mips@linux-mips.org
Subject: Re: XFree XZ support
Message-ID: <20030131104814.A31631@linux-mips.org>
References: <20030129143237.8D59413EC09@crassus.kulnet.kuleuven.ac.be> <20030130024611.GG15214@gateway.total-knowledge.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5.1i
In-Reply-To: <20030130024611.GG15214@gateway.total-knowledge.com>; from ilya@theIlya.com on Wed, Jan 29, 2003 at 06:46:11PM -0800
Return-Path: <ralf@linux-mips.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1281
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips

On Wed, Jan 29, 2003 at 06:46:11PM -0800, ilya@theIlya.com wrote:

> Hold it there. I thought Impacts are the ones with i860...
> You were either lying to me back then, or now.

Watch your words.

The Reality series are using upto about a dozen i860s in the gfx pipeline.
XZ and Impact is a relativly simple gfx in comparison - I'm told there is
about a dozen different graphics platforms that share nothing but the
basic architecture and all are marketed as XZ.  I just hope that isn't
true ...

  Ralf

From ralf@linux-mips.org Fri Jan 31 09:50:05 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 31 Jan 2003 09:50:06 +0000 (GMT)
Received: from p508B5ED1.dip.t-dialin.net ([IPv6:::ffff:80.139.94.209]:20187
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225229AbTAaJuF>; Fri, 31 Jan 2003 09:50:05 +0000
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.11.6/8.11.6) id h0V9o3U21835;
	Fri, 31 Jan 2003 10:50:03 +0100
Date: Fri, 31 Jan 2003 10:50:03 +0100
From: Ralf Baechle <ralf@linux-mips.org>
To: Jason Ormes <jormes@wideopenwest.com>
Cc: linux-mips@linux-mips.org
Subject: Re: compiling mips64 problem
Message-ID: <20030131105003.B31631@linux-mips.org>
References: <002801c2c8a6$a41f3470$4437e183@fermi.win.fnal.gov>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5.1i
In-Reply-To: <002801c2c8a6$a41f3470$4437e183@fermi.win.fnal.gov>; from jormes@wideopenwest.com on Thu, Jan 30, 2003 at 03:29:16PM -0600
Return-Path: <ralf@linux-mips.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1282
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips

On Thu, Jan 30, 2003 at 03:29:16PM -0600, Jason Ormes wrote:

> could someone throw me a bone and let me know what I'm doing wrong?

Hey, a new problem, seems you were creative ;-)

What commands did you use to configure and compile this kernel?

  Ralf

From jormes@wideopenwest.com Fri Jan 31 14:11:40 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 31 Jan 2003 14:11:41 +0000 (GMT)
Received: from gtwy.nap.wideopenwest.com ([IPv6:::ffff:64.233.207.11]:50871
	"EHLO pop-1.dnv.wideopenwest.com") by linux-mips.org with ESMTP
	id <S8225262AbTAaOLk> convert rfc822-to-8bit; Fri, 31 Jan 2003 14:11:40 +0000
Received: from localhost.localdomain (s233-106-251.nap.wideopenwest.com [64.233.251.106])
	by pop-1.dnv.wideopenwest.com (8.11.6/8.11.6) with ESMTP id h0VEGDX10245;
	Fri, 31 Jan 2003 08:16:13 -0600
Content-Type: text/plain;
  charset="iso-8859-1"
From: Jason Ormes <jormes@wideopenwest.com>
Reply-To: jormes@wideopenwest.com
To: Ralf Baechle <ralf@linux-mips.org>
Subject: Re: compiling mips64 problem
Date: Fri, 31 Jan 2003 08:14:51 -0600
User-Agent: KMail/1.4.3
Cc: linux-mips@linux-mips.org
References: <002801c2c8a6$a41f3470$4437e183@fermi.win.fnal.gov> <20030131105003.B31631@linux-mips.org>
In-Reply-To: <20030131105003.B31631@linux-mips.org>
MIME-Version: 1.0
Content-Transfer-Encoding: 8BIT
Message-Id: <200301310814.51628.jormes@wideopenwest.com>
Return-Path: <jormes@wideopenwest.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1283
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: jormes@wideopenwest.com
Precedence: bulk
X-list: linux-mips

On Friday 31 January 2003 03:50 am, Ralf Baechle wrote:
> On Thu, Jan 30, 2003 at 03:29:16PM -0600, Jason Ormes wrote:
> > could someone throw me a bone and let me know what I'm doing wrong?
>
> Hey, a new problem, seems you were creative ;-)
>
> What commands did you use to configure and compile this kernel?
>
>   Ralf
well,

I went into the linux folder and did a make menuconfig.  I changed the cpu 
selection to mips64 and went to the kernel hacking section and turned on the 
are you using a cross compiler option.  exited and saved.

commands used after that were

make ARCH=mips64 dep
make ARCH=mips64 all



any thoughts?


From ralf@linux-mips.org Fri Jan 31 14:15:23 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 31 Jan 2003 14:15:24 +0000 (GMT)
Received: from p508B5ED1.dip.t-dialin.net ([IPv6:::ffff:80.139.94.209]:31454
	"EHLO dea.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225262AbTAaOPX>; Fri, 31 Jan 2003 14:15:23 +0000
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.11.6/8.11.6) id h0VEFJY14573;
	Fri, 31 Jan 2003 15:15:19 +0100
Date: Fri, 31 Jan 2003 15:15:19 +0100
From: Ralf Baechle <ralf@linux-mips.org>
To: Jason Ormes <jormes@wideopenwest.com>
Cc: linux-mips@linux-mips.org
Subject: Re: compiling mips64 problem
Message-ID: <20030131151519.B14518@linux-mips.org>
References: <002801c2c8a6$a41f3470$4437e183@fermi.win.fnal.gov> <20030131105003.B31631@linux-mips.org> <200301310814.51628.jormes@wideopenwest.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5.1i
In-Reply-To: <200301310814.51628.jormes@wideopenwest.com>; from jormes@wideopenwest.com on Fri, Jan 31, 2003 at 08:14:51AM -0600
Return-Path: <ralf@linux-mips.org>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1284
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips

On Fri, Jan 31, 2003 at 08:14:51AM -0600, Jason Ormes wrote:

> I went into the linux folder and did a make menuconfig.  I changed the cpu 
> selection to mips64 and went to the kernel hacking section and turned on the 
> are you using a cross compiler option.  exited and saved.
> 
> commands used after that were
> 
> make ARCH=mips64 dep
> make ARCH=mips64 all

make ARCH=mips64 menuconfig

  Ralf

From jormes@wideopenwest.com Fri Jan 31 14:53:03 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 31 Jan 2003 14:53:03 +0000 (GMT)
Received: from heffalump.fnal.gov ([IPv6:::ffff:131.225.9.20]:44284 "EHLO
	fnal.gov") by linux-mips.org with ESMTP id <S8225262AbTAaOxD>;
	Fri, 31 Jan 2003 14:53:03 +0000
Received: from ppd89948 ([131.225.55.68])
 by smtp.fnal.gov (PMDF V6.0-24 #37519) with ESMTP id
 <0H9L005MY2OCJT@smtp.fnal.gov>; Fri, 31 Jan 2003 08:53:00 -0600 (CST)
Date: Fri, 31 Jan 2003 08:53:00 -0600
From: Jason Ormes <jormes@wideopenwest.com>
Subject: RE: compiling mips64 problem
In-reply-to: <20030131151519.B14518@linux-mips.org>
To: 'Ralf Baechle' <ralf@linux-mips.org>
Cc: linux-mips@linux-mips.org
Message-id: <000201c2c938$72ebe910$4437e183@fermi.win.fnal.gov>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-Mailer: Microsoft Outlook, Build 10.0.4024
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7bit
Importance: Normal
X-Priority: 3 (Normal)
X-MSMail-priority: Normal
Return-Path: <jormes@wideopenwest.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1285
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: jormes@wideopenwest.com
Precedence: bulk
X-list: linux-mips

Hey that did it thanks.


-----Original Message-----
From: linux-mips-bounce@linux-mips.org
[mailto:linux-mips-bounce@linux-mips.org] On Behalf Of Ralf Baechle
Sent: Friday, January 31, 2003 8:15 AM
To: Jason Ormes
Cc: linux-mips@linux-mips.org
Subject: Re: compiling mips64 problem

On Fri, Jan 31, 2003 at 08:14:51AM -0600, Jason Ormes wrote:

> I went into the linux folder and did a make menuconfig.  I changed the
cpu 
> selection to mips64 and went to the kernel hacking section and turned
on the 
> are you using a cross compiler option.  exited and saved.
> 
> commands used after that were
> 
> make ARCH=mips64 dep
> make ARCH=mips64 all

make ARCH=mips64 menuconfig

  Ralf


From Kumba12345@aol.com Fri Jan 31 17:48:30 2003
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 31 Jan 2003 18:09:01 +0000 (GMT)
Received: from imo-d06.mx.aol.com ([IPv6:::ffff:205.188.157.38]:20717 "EHLO
	imo-d06.mx.aol.com") by linux-mips.org with ESMTP
	id <S8225262AbTAaRsa>; Fri, 31 Jan 2003 17:48:30 +0000
Received: from Kumba12345@aol.com
	by imo-d06.mx.aol.com (mail_out_v34.13.) id l.11e.1d78c204 (4238)
	 for <linux-mips@linux-mips.org>; Fri, 31 Jan 2003 12:48:16 -0500 (EST)
From: Kumba12345@aol.com
Message-ID: <11e.1d78c204.2b6c10e0@aol.com>
Date: Fri, 31 Jan 2003 12:48:16 EST
Subject: mips64 glitches
To: linux-mips@linux-mips.org
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Mailer: AOL 7.0 for Windows US sub 10634
Return-Path: <Kumba12345@aol.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 1286
X-Approved-By: ralf@linux-mips.org
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: Kumba12345@aol.com
Precedence: bulk
X-list: linux-mips

These might already be known, but just to be safe, I have two errors I ran 
into building and using a mips64 kernel on an SGI Indigo2 IP-22 system, R4400

First, it appears there's some unfriendliness between the Indy/Indigo2 
Watchdog and the egcs-mips64 compiler:

mips64-linux-gcc -D__KERNEL__ -I/usr/src/t/linux-2.4.20-mips/include -Wall 
-Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common 
-fomit-frame-pointer -mcpu=r8000 -mips4 -I 
/usr/src/t/linux-2.4.20-mips/include/asm/gcc -mabi=64 -G 0 -mno-abicalls 
-fno-pic -Wa,--trap -pipe -Wa,-32 -Wa,-mgp64   -nostdinc -iwithprefix include 
-DKBUILD_BASENAME=indydog  -c -o indydog.o indydog.c
indydog.c: In function `indydog_write':
indydog.c:124: internal error--unrecognizable insn:
(insn 206 61 58 (set (reg:SI 111)
        (reg/v:DI 89)) -1 (insn_list:REG_DEP_ANTI 54 (insn_list 61 (nil)))
    (nil))
../../gcc/toplev.c:1367: Internal compiler error in function fatal_insn
make[3]: *** [indydog.o] Error 1
make[3]: Leaving directory `/usr/src/t/linux-2.4.20-mips/drivers/char'
make[2]: *** [first_rule] Error 2
make[2]: Leaving directory `/usr/src/t/linux-2.4.20-mips/drivers/char'
make[1]: *** [_subdir_char] Error 2
make[1]: Leaving directory `/usr/src/t/linux-2.4.20-mips/drivers'
make: *** [_dir_drivers] Error 2


Second, After removing watchdog support and recompiling, I wound up with a 
compiled kernel.  Attempting to boot it made another error:

Exception: <vector=Normal>
Status register: 0x30044802<CU1,CU0,CH,IM7,IM4,IPL=???,MODE=KERNEL,EXL>
Cause register: 0x8028<CE=0,IP8,EXC=II>
Exception PC: 0x881ebeb4, Exception RA: 0x881ec4bc
Reserved Instruction exception, contents of PC = 0x62900b
Local I/O interrupt register 2: 0xc8 <EISA,SLOT0,SLOT1>
  Saved user regs in hex (&gpda 0xa8740e48, &_regs 0xa8741048):
  arg: a8740000 88200000 885fff80 88000000
  tmp: a8740000 88239dc8 0 88239e07 881dc000 a87ffc20 a8746f70 9fc5c274
  sve: a8740000 c12dc13a 0 c0f9138a 0 c0edd9c9 0 bf077b8a
  t8 a8740000 t9 c0dcea58 at 0 v0 c0f9138a v1 0 k1 3ff
  gp a8740000 fp abfb7d4f sp 4fd7ff27 ra cf31ffcf

PANIC: Unexpected exception

[Press reset or ENTER to restart.]


I used the linux-mips CVS 2_4 branch, pulled today, and the egcs-mips64 1.1.2 
compiler and it's associated binutils.  As for the kernel, I wonder if this 
has anything to do with the fact the kernel build passed -mcpu=r8000 when I'm 
running an R4400.  I was told mips64 IP22 support should be mostly 
functional, just it's been neglected for some time.

Anyways, if there is anymore information needed, please advise.  This system 
works wonderfully on a 32-bit kernel built off a vanilla + debian patch, but 
I wnated to try out mips64 on it just for kicks.

--Kumba

