From dimitri@sonycom.com Fri Jan  2 14:59:44 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 02 Jan 2004 14:59:45 +0000 (GMT)
Received: from witte.sonytel.be ([IPv6:::ffff:80.88.33.193]:13820 "EHLO
	witte.sonytel.be") by linux-mips.org with ESMTP id <S8225424AbUABO7o>;
	Fri, 2 Jan 2004 14:59:44 +0000
Received: from teasel.sonytel.be (localhost [127.0.0.1])
	by witte.sonytel.be (8.12.10/8.12.10) with ESMTP id i02ExfQF008258
	for <linux-mips@linux-mips.org>; Fri, 2 Jan 2004 15:59:41 +0100 (MET)
Received: (from dimitri@localhost)
	by teasel.sonytel.be (8.9.3+Sun/8.9.3) id PAA13447
	for linux-mips@linux-mips.org; Fri, 2 Jan 2004 15:59:41 +0100 (MET)
Date: Fri, 2 Jan 2004 15:59:41 +0100
From: Dimitri Torfs <dimitri@sonycom.com>
To: linux-mips@linux-mips.org
Subject: access_ok and CONFIG_MIPS32 for 2.6
Message-ID: <20040102145941.GA13426@sonycom.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.4.1i
Return-Path: <dimitri@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: 3860
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: dimitri@sonycom.com
Precedence: bulk
X-list: linux-mips

Hi,

  the mask used in access_ok to check the validity of an address range
  evaluates to -TASK_SIZE for user processes. In case of
  CONFIG_MIPS32, TASK_SIZE is defined as 0x7fff8000UL, so -TASK_SIZE
  evaluates to 0x80008000, making access_ok return false for all
  addresses with bit 15 and 31 set. Surely the mask should be 0x80000000. 

  Does anybody know why TASK_SIZE is set to 0x7fff8000 and not
  0x80000000 ?


  Dimitri 


-- 
Dimitri Torfs             |  NSCE 
dimitri.torfs@sonycom.com |  Sint Stevens Woluwestraat 55
tel: +32 2 2908451        |  1130 Brussel
fax: +32 2 7262686        |  Belgium


From ralf@linux-mips.org Fri Jan  2 19:44:04 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 02 Jan 2004 19:44:05 +0000 (GMT)
Received: from p508B6B8A.dip.t-dialin.net ([IPv6:::ffff:80.139.107.138]:10377
	"EHLO mail.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225317AbUABToE>; Fri, 2 Jan 2004 19:44:04 +0000
Received: from dea.linux-mips.net (localhost [127.0.0.1])
	by mail.linux-mips.net (8.12.8/8.12.8) with ESMTP id i02Ji3a5031863;
	Fri, 2 Jan 2004 20:44:03 +0100
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.12.8/8.12.8/Submit) id i02Ji3j6031862;
	Fri, 2 Jan 2004 20:44:03 +0100
Date: Fri, 2 Jan 2004 20:44:03 +0100
From: Ralf Baechle <ralf@linux-mips.org>
To: Dimitri Torfs <dimitri@sonycom.com>
Cc: linux-mips@linux-mips.org
Subject: Re: access_ok and CONFIG_MIPS32 for 2.6
Message-ID: <20040102194403.GB31092@linux-mips.org>
References: <20040102145941.GA13426@sonycom.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20040102145941.GA13426@sonycom.com>
User-Agent: Mutt/1.4.1i
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: 3861
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 02, 2004 at 03:59:41PM +0100, Dimitri Torfs wrote:

>   the mask used in access_ok to check the validity of an address range
>   evaluates to -TASK_SIZE for user processes. In case of
>   CONFIG_MIPS32, TASK_SIZE is defined as 0x7fff8000UL, so -TASK_SIZE
>   evaluates to 0x80008000, making access_ok return false for all
>   addresses with bit 15 and 31 set. Surely the mask should be 0x80000000. 
> 
>   Does anybody know why TASK_SIZE is set to 0x7fff8000 and not
>   0x80000000 ?

There is a weird special case were 32-bit code running on a 64-bit kernel
with c0_status.ux set will behave differently than on a 32-bit processor
or with c0_status.ux clear.  The workaround for 64-bit kernels is to
leave the top 32kB of the 2GB user virtual address space unused.  For
sake of symmetry we do this on both 32-bit and 64-bit kernels.

  Ralf

From karthik_96cse@yahoo.com Sun Jan  4 09:09:25 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 04 Jan 2004 09:09:38 +0000 (GMT)
Received: from web10102.mail.yahoo.com ([IPv6:::ffff:216.136.130.52]:53366
	"HELO web10102.mail.yahoo.com") by linux-mips.org with SMTP
	id <S8225254AbUADJJZ>; Sun, 4 Jan 2004 09:09:25 +0000
Message-ID: <20040104090922.35955.qmail@web10102.mail.yahoo.com>
Received: from [128.107.253.43] by web10102.mail.yahoo.com via HTTP; Sun, 04 Jan 2004 09:09:22 GMT
Date: Sun, 4 Jan 2004 09:09:22 +0000 (GMT)
From: =?iso-8859-1?q?karthikeyan=20natarajan?= <karthik_96cse@yahoo.com>
Subject: Regarding the LL & SC instructions
To: linux-mips@linux-mips.org
In-Reply-To: <Pine.LNX.4.55.0312221342180.27237@jurand.ds.pg.gda.pl>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Return-Path: <karthik_96cse@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: 3863
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: karthik_96cse@yahoo.com
Precedence: bulk
X-list: linux-mips
Content-Length: 613
Lines: 21

Hi All,

    Seems that LL & SC instrutions operate on a 'word'
data.
    Can we use the same instructions to do a atomic
increment on a 'byte' data. If not, are there any
specific instructions to operate on a byte data?
(Like, LLD & SCD for doubleword data) or else, any 
method to achieve this using the LL & SC instr?

Thanks much,
-karthi


=====
The expert at anything was once a beginner

________________________________________________________________________
Yahoo! Messenger - Communicate instantly..."Ping" 
your friends today! Download Messenger Now 
http://uk.messenger.yahoo.com/download/index.html

From anemo@mba.ocn.ne.jp Sun Jan  4 12:01:29 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 04 Jan 2004 12:01:29 +0000 (GMT)
Received: from mba.ocn.ne.jp ([IPv6:::ffff:210.190.142.172]:15353 "HELO
	smtp.mba.ocn.ne.jp") by linux-mips.org with SMTP
	id <S8225259AbUADMB3>; Sun, 4 Jan 2004 12:01:29 +0000
Received: from localhost (p2085-ipad28funabasi.chiba.ocn.ne.jp [220.107.201.85])
	by smtp.mba.ocn.ne.jp (Postfix) with ESMTP
	id 1874D584D; Sun,  4 Jan 2004 21:01:25 +0900 (JST)
Date: Sun, 04 Jan 2004 21:05:32 +0900 (JST)
Message-Id: <20040104.210532.74756709.anemo@mba.ocn.ne.jp>
To: ralf@linux-mips.org
Cc: dimitri@sonycom.com, linux-mips@linux-mips.org
Subject: Re: access_ok and CONFIG_MIPS32 for 2.6
From: Atsushi Nemoto <anemo@mba.ocn.ne.jp>
In-Reply-To: <20040102194403.GB31092@linux-mips.org>
References: <20040102145941.GA13426@sonycom.com>
	<20040102194403.GB31092@linux-mips.org>
X-Fingerprint: 6ACA 1623 39BD 9A94 9B1A  B746 CA77 FE94 2874 D52F
X-Pgp-Public-Key: http://wwwkeys.pgp.net/pks/lookup?op=get&search=0x2874D52F
X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.0 (HANANOEN)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Return-Path: <anemo@mba.ocn.ne.jp>
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: 3864
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: anemo@mba.ocn.ne.jp
Precedence: bulk
X-list: linux-mips
Content-Length: 2355
Lines: 75

>>>>> On Fri, 2 Jan 2004 20:44:03 +0100, Ralf Baechle <ralf@linux-mips.org> said:

>> Does anybody know why TASK_SIZE is set to 0x7fff8000 and not
>> 0x80000000 ?

ralf> There is a weird special case were 32-bit code running on a
ralf> 64-bit kernel with c0_status.ux set will behave differently than
ralf> on a 32-bit processor or with c0_status.ux clear.  The
ralf> workaround for 64-bit kernels is to leave the top 32kB of the
ralf> 2GB user virtual address space unused.  For sake of symmetry we
ralf> do this on both 32-bit and 64-bit kernels.

Then, access_ok in 2.6 tree is broken, isn't it?

2.4 mips:
#define TASK_SIZE	0x7fff8000UL
#define USER_DS		((mm_segment_t) { (unsigned long) -1L })

2.4 mips64:
#define TASK_SIZE32	   0x7fff8000UL
#define TASK_SIZE	0x10000000000UL
#define USER_DS		((mm_segment_t) { -TASK_SIZE })

2.6:
#ifdef CONFIG_MIPS32
#define TASK_SIZE	0x7fff8000UL
#else
#define TASK_SIZE32	0x7fff8000UL
#define TASK_SIZE	0x10000000000UL
#endif
#define USER_DS		((mm_segment_t) { -TASK_SIZE })

It seems there should be another definition of USER_DS for
CONFIG_MIPS32 in 2.6.


BTW, there are another problems in uaccess.h as I wrote in
http://www.linux-mips.org/archives/linux-mips/2003-09/msg00035.html.

First, 2.4 mips64 __ua_size is broken.

2.4 mips:
#define __ua_size(size)							\
	(__builtin_constant_p(size) && (signed long) (size) > 0 ? 0 : (size))
2.4 mips64:
#define __ua_size(size)							\
	((__builtin_constant_p(size) && (size)) > 0 ? 0 : (size))
2.6:
#define __ua_size(size)							\
	((__builtin_constant_p(size) && (signed long) (size) > 0) ? 0 : (size))

2.4 mips and 2.6 are identical except for parenthesis.


Second, __access_ok for 64bit kernel is broken both 2.4 and 2.6.  It
returns 0 if 'addr' + 'size' == TASK_SIZE (which should be OK).

2.4 mips64:
#define __access_ok(addr, size, mask)					\
	(((mask) & ((addr) | ((addr) + (size)) | __ua_size(size))) == 0)
2.6:
#define __access_ok(addr, size, mask)					\
	(((signed long)((mask) & ((addr) | ((addr) + (size)) | __ua_size(size)))) == 0)

I think these macros should be:

2.4 mips64:
#define __access_ok(addr, size, mask)					\
	(((mask) & ((addr) | ((addr) + (size) - 1) | __ua_size(size))) == 0)
2.6:
#define __access_ok(addr, size, mask)					\
	(((signed long)((mask) & ((addr) | ((addr) + (size) - 1) | __ua_size(size)))) == 0)

---
Atsushi Nemoto

From dimitri@sonycom.com Sun Jan  4 21:03:31 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 04 Jan 2004 21:03:32 +0000 (GMT)
Received: from witte.sonytel.be ([IPv6:::ffff:80.88.33.193]:3565 "EHLO
	witte.sonytel.be") by linux-mips.org with ESMTP id <S8225341AbUADVDb>;
	Sun, 4 Jan 2004 21:03:31 +0000
Received: from teasel.sonytel.be (localhost [127.0.0.1])
	by witte.sonytel.be (8.12.10/8.12.10) with ESMTP id i04L3QQF008202;
	Sun, 4 Jan 2004 22:03:27 +0100 (MET)
Received: (from dimitri@localhost)
	by teasel.sonytel.be (8.9.3+Sun/8.9.3) id WAA15510;
	Sun, 4 Jan 2004 22:03:27 +0100 (MET)
Date: Sun, 4 Jan 2004 22:03:27 +0100
From: Dimitri Torfs <dimitri@sonycom.com>
To: Atsushi Nemoto <anemo@mba.ocn.ne.jp>, ralf@linux-mips.org
Cc: linux-mips@linux-mips.org
Subject: Re: access_ok and CONFIG_MIPS32 for 2.6
Message-ID: <20040104210327.GA15475@sonycom.com>
References: <20040102145941.GA13426@sonycom.com> <20040102194403.GB31092@linux-mips.org> <20040104.210532.74756709.anemo@mba.ocn.ne.jp>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20040104.210532.74756709.anemo@mba.ocn.ne.jp>
User-Agent: Mutt/1.4.1i
Return-Path: <dimitri@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: 3865
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: dimitri@sonycom.com
Precedence: bulk
X-list: linux-mips
Content-Length: 3307
Lines: 113

On Sun, Jan 04, 2004 at 09:05:32PM +0900, Atsushi Nemoto wrote:
> >>>>> On Fri, 2 Jan 2004 20:44:03 +0100, Ralf Baechle <ralf@linux-mips.org> said:
> 
> >> Does anybody know why TASK_SIZE is set to 0x7fff8000 and not
> >> 0x80000000 ?
> 
> ralf> There is a weird special case were 32-bit code running on a
> ralf> 64-bit kernel with c0_status.ux set will behave differently than
> ralf> on a 32-bit processor or with c0_status.ux clear.  The
> ralf> workaround for 64-bit kernels is to leave the top 32kB of the
> ralf> 2GB user virtual address space unused.  For sake of symmetry we
> ralf> do this on both 32-bit and 64-bit kernels.
> 
> Then, access_ok in 2.6 tree is broken, isn't it?
> 
> It seems there should be another definition of USER_DS for
> CONFIG_MIPS32 in 2.6.

Yes, I'm setting USER_DS to 0x80000000 for CONFIG_MIPS32:


--- linux-mips-2.6.orig/include/asm-mips/uaccess.h	2003-11-30 13:59:06.000000000 +0100
+++ linux.work/include/asm-mips/uaccess.h	2004-01-04 21:22:23.000000000 +0100
@@ -42,7 +42,12 @@
 #endif /* CONFIG_MIPS64 */
 
 #define KERNEL_DS	((mm_segment_t) { 0UL })
+
+#ifdef CONFIG_MIPS32
+#define USER_DS		((mm_segment_t) { 0x80000000UL })
+#else
 #define USER_DS		((mm_segment_t) { -TASK_SIZE })
+#endif
 
 #define VERIFY_READ    0
 #define VERIFY_WRITE   1


The USER_DS mask is also used in scall32-o32.S, scall64-64.S and
scall64-032.S. It think it would be cleaner if we replace there also
the ">= 0" check with the "== 0" check and add the correct size as you
suggested:


--- linux-mips-2.6.orig/arch/mips/kernel/scall64-64.S	2003-10-11 00:58:55.000000000 +0200
+++ linux.work/arch/mips/kernel/scall64-64.S	2004-01-04 21:45:45.000000000 +0100
@@ -119,10 +119,10 @@
 	bnez	v0, bad_alignment
 
 	LONG_L	v1, TI_ADDR_LIMIT($28)		# in legal address range?
-	LONG_ADDIU	a0, a1, 4
+	LONG_ADDIU	a0, a1, 3 
 	or	a0, a0, a1
 	and	a0, a0, v1
-	bltz	a0, bad_address
+	bnez	a0, bad_address
 
 #ifdef CONFIG_CPU_HAS_LLSC
 	/* Ok, this is the ll/sc case.  World is sane :-)  */


--- linux-mips-2.6.orig/arch/mips/kernel/scall32-o32.S	2003-08-26 02:28:51.000000000 +0200
+++ linux.work/arch/mips/kernel/scall32-o32.S	2004-01-04 21:48:39.000000000 +0100
@@ -187,10 +187,10 @@
 	bnez	v0, bad_alignment
 
 	lw	v1, TI_ADDR_LIMIT($28)		# in legal address range?
-	addiu	a0, a1, 4
+	addiu	a0, a1, 3 
 	or	a0, a0, a1
 	and	a0, a0, v1
-	bltz	a0, bad_address
+	bnez	a0, bad_address
 
 #ifdef CONFIG_CPU_HAS_LLSC
 	/* Ok, this is the ll/sc case.  World is sane :-)  */
@@ -280,11 +280,11 @@
 	bnez	v0, sigsegv
 
 	addu	v0, t0, 16			# v0 = usp + 16
-	addu	t1, v0, 12			# 3 32-bit arguments
+	addu	t1, v0, 11			# 3 32-bit arguments
 	lw	v1, TI_ADDR_LIMIT($28)
 	or	v0, v0, t1
 	and	v1, v1, v0
-	bltz	v1, efault
+	bnez	v1, efault
 
 	move	a0, a1				# shift argument registers
 	move	a1, a2



--- linux-mips-2.6.orig/arch/mips/kernel/scall64-64.S	2003-10-11 00:58:55.000000000 +0200
+++ linux.work/arch/mips/kernel/scall64-64.S	2004-01-04 21:45:45.000000000 +0100
@@ -119,10 +119,10 @@
 	bnez	v0, bad_alignment
 
 	LONG_L	v1, TI_ADDR_LIMIT($28)		# in legal address range?
-	LONG_ADDIU	a0, a1, 4
+	LONG_ADDIU	a0, a1, 3 
 	or	a0, a0, a1
 	and	a0, a0, v1
-	bltz	a0, bad_address
+	bnez	a0, bad_address
 
 #ifdef CONFIG_CPU_HAS_LLSC
 	/* Ok, this is the ll/sc case.  World is sane :-)  */



Dimitri


From kevink@mips.com Sun Jan  4 21:46:34 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 04 Jan 2004 21:46:35 +0000 (GMT)
Received: from ftp.mips.com ([IPv6:::ffff:206.31.31.227]:58241 "EHLO
	mx2.mips.com") by linux-mips.org with ESMTP id <S8225341AbUADVqe>;
	Sun, 4 Jan 2004 21:46:34 +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 i04Le6CE001490;
	Sun, 4 Jan 2004 13:40:06 -0800 (PST)
Received: from grendel (grendel [192.168.236.16])
	by newman.mips.com (8.9.3/8.9.0) with SMTP id NAA25605;
	Sun, 4 Jan 2004 13:46:19 -0800 (PST)
Message-ID: <001701c3d30c$4d0223c0$10eca8c0@grendel>
From: "Kevin D. Kissell" <kevink@mips.com>
To: "karthikeyan natarajan" <karthik_96cse@yahoo.com>,
	<linux-mips@linux-mips.org>
References: <20040104090922.35955.qmail@web10102.mail.yahoo.com>
Subject: Re: Regarding the LL & SC instructions
Date: Sun, 4 Jan 2004 22:47:06 +0100
Organization: MIPS Technologies Inc.
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
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: 3866
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
Content-Length: 1308
Lines: 38

You can modify any, all, or none of the bytes in a word loaded/stored
with LL/SC.  What you *can't* do is independently  LL/SC individual 
bytes within the same memory word, but operationally, this is of little
consequence.  If you want to atomically modify a byte, you LL the word
containing the byte, modify the byte in question, and SC the word.
If the SC succeeds, all is as you wish.  If the SC fails, you need to
retry the whole sequence.

----- Original Message ----- 
From: "karthikeyan natarajan" <karthik_96cse@yahoo.com>
To: <linux-mips@linux-mips.org>
Sent: Sunday, January 04, 2004 10:09
Subject: Regarding the LL & SC instructions


> Hi All,
> 
>     Seems that LL & SC instrutions operate on a 'word'
> data.
>     Can we use the same instructions to do a atomic
> increment on a 'byte' data. If not, are there any
> specific instructions to operate on a byte data?
> (Like, LLD & SCD for doubleword data) or else, any 
> method to achieve this using the LL & SC instr?
> 
> Thanks much,
> -karthi
> 
> 
> =====
> The expert at anything was once a beginner
> 
> ________________________________________________________________________
> Yahoo! Messenger - Communicate instantly..."Ping" 
> your friends today! Download Messenger Now 
> http://uk.messenger.yahoo.com/download/index.html
> 
> 

From anemo@mba.ocn.ne.jp Mon Jan  5 01:03:38 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 05 Jan 2004 01:03:39 +0000 (GMT)
Received: from topsns.toshiba-tops.co.jp ([IPv6:::ffff:202.230.225.5]:16146
	"HELO topsns.toshiba-tops.co.jp") by linux-mips.org with SMTP
	id <S8225239AbUAEBDi>; Mon, 5 Jan 2004 01:03:38 +0000
Received: from no.name.available by topsns.toshiba-tops.co.jp
          via smtpd (for mail.linux-mips.org [62.254.210.162]) with SMTP; 5 Jan 2004 01:04:21 UT
Received: from localhost (fragile [172.17.28.65])
	by srd2sd.toshiba-tops.co.jp (8.12.10/8.12.10) with ESMTP id i051431x017671;
	Mon, 5 Jan 2004 10:04:06 +0900 (JST)
	(envelope-from anemo@mba.ocn.ne.jp)
Date: Mon, 05 Jan 2004 10:04:29 +0900 (JST)
Message-Id: <20040105.100429.74756139.nemoto@toshiba-tops.co.jp>
To: macro@ds2.pg.gda.pl
Cc: ralf@linux-mips.org, linux-mips@linux-mips.org
Subject: Re: [patch] 2.4: Support for newer gcc/gas options
From: Atsushi Nemoto <anemo@mba.ocn.ne.jp>
In-Reply-To: <Pine.LNX.4.55.0312161822240.8262@jurand.ds.pg.gda.pl>
References: <Pine.LNX.4.55.0312161822240.8262@jurand.ds.pg.gda.pl>
X-Fingerprint: 6ACA 1623 39BD 9A94 9B1A  B746 CA77 FE94 2874 D52F
X-Pgp-Public-Key: http://wwwkeys.pgp.net/pks/lookup?op=get&search=0x2874D52F
X-Mailer: Mew version 2.2 on Emacs 21.2 / Mule 5.0 (SAKAKI)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Return-Path: <anemo@mba.ocn.ne.jp>
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: 3867
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: anemo@mba.ocn.ne.jp
Precedence: bulk
X-list: linux-mips
Content-Length: 922
Lines: 24

>>>>> On Tue, 16 Dec 2003 22:33:41 +0100 (CET), "Maciej W. Rozycki" <macro@ds2.pg.gda.pl> said:
macro>  ifdef CONFIG_CPU_TX39XX
macro> -GCCFLAGS	+= -mcpu=r3000 -mips1
macro> +GCCFLAGS	+= $(call set_gccflags,r3000,mips1,r3000,mips1,mips1)
macro>  endif

Recent tools have -march=r3900 option.  Now we can use this without
hitting old tool users.  Please apply this patch.  Thank you.

diff -u linux-mips/arch/mips/Makefile linux/arch/mips/Makefile 
--- linux-mips/arch/mips/Makefile	Mon Jan  5 08:37:51 2004
+++ linux/arch/mips/Makefile	Mon Jan  5 09:50:06 2004
@@ -107,7 +107,7 @@
 GCCFLAGS	+= $(call set_gccflags,r3000,mips1,r3000,mips1,mips1)
 endif
 ifdef CONFIG_CPU_TX39XX
-GCCFLAGS	+= $(call set_gccflags,r3000,mips1,r3000,mips1,mips1)
+GCCFLAGS	+= $(call set_gccflags,r3900,mips1,r3000,mips1,mips1)
 endif
 ifdef CONFIG_CPU_R6000
 GCCFLAGS	+= $(call set_gccflags,r6000,mips2,r6000,mips2,mips2) \

---
Atsushi Nemoto

From yuasa@hh.iij4u.or.jp Tue Jan  6 06:45:57 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 06 Jan 2004 06:46:02 +0000 (GMT)
Received: from mo02.iij4u.or.jp ([IPv6:::ffff:210.130.0.19]:26572 "EHLO
	mo02.iij4u.or.jp") by linux-mips.org with ESMTP id <S8225405AbUAFGp5>;
	Tue, 6 Jan 2004 06:45:57 +0000
Received: from mdo01.iij4u.or.jp (mdo01.iij4u.or.jp [210.130.0.171])
	by mo02.iij4u.or.jp (8.8.8/MFO1.5) with ESMTP id PAA15609;
	Tue, 6 Jan 2004 15:45:54 +0900 (JST)
Received: 4UMDO01 id i066jrF04737; Tue, 6 Jan 2004 15:45:53 +0900 (JST)
Received: 4UMRO01 id i066jq411433; Tue, 6 Jan 2004 15:45:53 +0900 (JST)
	from rally.montavista.co.jp (sonicwall.montavista.co.jp [202.232.97.131]) (authenticated)
Date: Tue, 6 Jan 2004 15:45:52 +0900
From: Yoichi Yuasa <yuasa@hh.iij4u.or.jp>
To: Ralf Baechle <ralf@linux-mips.org>
Cc: yuasa@hh.iij4u.or.jp, linux-mips <linux-mips@linux-mips.org>
Subject: [PATCH][2.6] fixed the file name of an include file for
 pci-vr41xx.c
Message-Id: <20040106154552.6650d4ff.yuasa@hh.iij4u.or.jp>
X-Mailer: Sylpheed version 0.9.8a (GTK+ 1.2.10; i686-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Return-Path: <yuasa@hh.iij4u.or.jp>
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: 3868
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: yuasa@hh.iij4u.or.jp
Precedence: bulk
X-list: linux-mips
Content-Length: 544
Lines: 21

Hello Ralf,

I made a patch for pci-vr41xx.c.
This patch fixes the file name of an include file.

Please apply this patch.

Yoichi

diff -urN -X dontdiff linux-orig/arch/mips/pci/pci-vr41xx.c linux/arch/mips/pci/pci-vr41xx.c
--- linux-orig/arch/mips/pci/pci-vr41xx.c	2003-06-13 23:19:56.000000000 +0900
+++ linux/arch/mips/pci/pci-vr41xx.c	2004-01-06 15:24:11.000000000 +0900
@@ -49,7 +49,7 @@
 #include <asm/pci_channel.h>
 #include <asm/vr41xx/vr41xx.h>
 
-#include "pciu.h"
+#include "pci-vr41xx.h"
 
 extern unsigned long vr41xx_vtclock;
 

From macro@ds2.pg.gda.pl Tue Jan  6 15:24:29 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 06 Jan 2004 15:24:30 +0000 (GMT)
Received: from jurand.ds.pg.gda.pl ([IPv6:::ffff:153.19.208.2]:1992 "EHLO
	jurand.ds.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8224991AbUAFPY3>; Tue, 6 Jan 2004 15:24:29 +0000
Received: by jurand.ds.pg.gda.pl (Postfix, from userid 1011)
	id 478944C3A7; Tue,  6 Jan 2004 16:24:25 +0100 (CET)
Received: from localhost (localhost [127.0.0.1])
	by jurand.ds.pg.gda.pl (Postfix) with ESMTP
	id 30FE04C386; Tue,  6 Jan 2004 16:24:25 +0100 (CET)
Date: Tue, 6 Jan 2004 16:24:25 +0100 (CET)
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To: Atsushi Nemoto <anemo@mba.ocn.ne.jp>
Cc: ralf@linux-mips.org, linux-mips@linux-mips.org
Subject: Re: [patch] 2.4: Support for newer gcc/gas options
In-Reply-To: <20040105.100429.74756139.nemoto@toshiba-tops.co.jp>
Message-ID: <Pine.LNX.4.55.0401061622580.5272@jurand.ds.pg.gda.pl>
References: <Pine.LNX.4.55.0312161822240.8262@jurand.ds.pg.gda.pl>
 <20040105.100429.74756139.nemoto@toshiba-tops.co.jp>
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: 3869
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
Content-Length: 495
Lines: 12

On Mon, 5 Jan 2004, Atsushi Nemoto wrote:

> Recent tools have -march=r3900 option.  Now we can use this without
> hitting old tool users.  Please apply this patch.  Thank you.

 Thanks -- this is now in as obviously correct.  I wonder why there is
that naming inconsistency: r3900 vs tx3900...

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

From macro@ds2.pg.gda.pl Tue Jan  6 15:30:58 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 06 Jan 2004 15:30:59 +0000 (GMT)
Received: from jurand.ds.pg.gda.pl ([IPv6:::ffff:153.19.208.2]:1738 "EHLO
	jurand.ds.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8224991AbUAFPau>; Tue, 6 Jan 2004 15:30:50 +0000
Received: by jurand.ds.pg.gda.pl (Postfix, from userid 1011)
	id B452B4C3A7; Tue,  6 Jan 2004 16:30:48 +0100 (CET)
Received: from localhost (localhost [127.0.0.1])
	by jurand.ds.pg.gda.pl (Postfix) with ESMTP
	id 9D64F473D8; Tue,  6 Jan 2004 16:30:48 +0100 (CET)
Date: Tue, 6 Jan 2004 16:30:48 +0100 (CET)
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To: Atsushi Nemoto <anemo@mba.ocn.ne.jp>
Cc: ralf@linux-mips.org, linux-mips@linux-mips.org
Subject: Re: [patch] 2.4: Support for newer gcc/gas options
In-Reply-To: <Pine.LNX.4.55.0312231403110.27594@jurand.ds.pg.gda.pl>
Message-ID: <Pine.LNX.4.55.0401061625200.5272@jurand.ds.pg.gda.pl>
References: <Pine.LNX.4.55.0312161822240.8262@jurand.ds.pg.gda.pl>
 <20031223.220213.74756743.anemo@mba.ocn.ne.jp>
 <Pine.LNX.4.55.0312231403110.27594@jurand.ds.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: 3870
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
Content-Length: 738
Lines: 20

On Tue, 23 Dec 2003, Maciej W. Rozycki wrote:

> > With MIPS3 ISA, handle_adel_int will be:
> > 
> > 8002630c <handle_adel_int> 40284000 	dmfc0	t0,$8
> > 80026310 <handle_adel_int+0x4> 00000000 	nop
> > 80026314 <handle_adel_int+0x8> ffa800a4 	sd	t0,164(sp)
> > 
> > which is wrong for 32bit kernel.
> 
>  Which clearly indicates it should be selected with the CONFIG_MIPS32 (or 
> CONFIG_MIPS64) option.

 I can see Ralf has fixed the problem, by using the ABI as the criterion 
used in conditionals.  This is better yet -- thanks Ralf.

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

From joe@jorrit.de Tue Jan  6 16:39:33 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 06 Jan 2004 16:39:37 +0000 (GMT)
Received: from ns1.xeneris.net ([IPv6:::ffff:195.49.173.97]:50404 "HELO
	superfix.xeneris.net") by linux-mips.org with SMTP
	id <S8225198AbUAFQjd>; Tue, 6 Jan 2004 16:39:33 +0000
Received: (qmail 9609 invoked by uid 64014); 6 Jan 2004 16:39:35 -0000
Received: from joe@jorrit.de by superfix by uid 64011 with qmail-scanner-1.15 
 (clamscan: 0.54. spamassassin: 2.50-cvs.  Clear:. 
 Processed in 0.525807 secs); 06 Jan 2004 16:39:35 -0000
Received: from localhost (HELO jupiter.planets) (127.0.0.1)
  by localhost with SMTP; 6 Jan 2004 16:39:35 -0000
Received: from joe by jupiter.planets with local (Exim 3.36 #1 (Debian))
	id 1AduEn-0001ur-00; Tue, 06 Jan 2004 17:39:25 +0100
Date: Tue, 6 Jan 2004 17:39:25 +0100
From: =?iso-8859-1?Q?J=F6?= Fahlke <jorrit@jorrit.de>
To: Linux on Mips Mailinglist <linux-mips@linux-mips.org>
Subject: Assembler error in arch/mips/kernel/entry.S
Message-ID: <20040106163925.GA7342@fsk.uni-heidelberg.de>
Mail-Followup-To: =?iso-8859-1?Q?J=F6?= Fahlke <jorrit@jorrit.de>,
	Linux on Mips Mailinglist <linux-mips@linux-mips.org>
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="d6Gm4EdcadzBjdND"
Content-Disposition: inline
User-Agent: Mutt/1.5.4i
Return-Path: <joe@jorrit.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: 3871
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: jorrit@jorrit.de
Precedence: bulk
X-list: linux-mips
Content-Length: 2396
Lines: 67


--d6Gm4EdcadzBjdND
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

[Please Cc me on replys]

Hi!

Trying to compile current cvs with CONFIG_PREEMT I get:

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
  AS      arch/mips/kernel/entry.o
arch/mips/kernel/entry.S: Assembler messages:
arch/mips/kernel/entry.S:55: Error: illegal operands `beqz restore_all'
arch/mips/kernel/entry.S:56: Error: unrecognized opcode `if (in_exception_p=
ath)'
arch/mips/kernel/entry.S:57: Error: unrecognized opcode `goto restore_all'
arch/mips/kernel/entry.S:58: Error: absolute expression required `li'
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

The corresponding code looks like this:

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
        beqz    restore_all
        if (in_exception_path)
                goto restore_all;
        li      t0, PREEMPT_ACTIVE
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Can someone please fix this?  My very limitet assembler knowledge
gives me an idea whats wrong, but I don't know how to fix it.

Meanwhile I'll try compiling without CONFIG_PREEMT.

Thanks,
J=C3=B6.

--=20
Interpunktion, Orthographie und Grammatik der Email ist frei erfunden.
Eine =EF=BF=BDbereinstimmung mit aktuellen oder ehemaligen Regeln w=C3=A4re=
 rein
zuf=C3=A4llig und ist nicht beabsichtigt.

--d6Gm4EdcadzBjdND
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

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

iD8DBQE/+uS89pw8d07v1OsRAmEdAJ0YBbOrGQoM82MlrHHUWGENRM24cQCfa7ju
R0KYVrEHuPzN2S7Uew2m/aM=
=iERP
-----END PGP SIGNATURE-----

--d6Gm4EdcadzBjdND--

From ica2_ts@csv.ica.uni-stuttgart.de Tue Jan  6 18:15:00 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 06 Jan 2004 18:15:04 +0000 (GMT)
Received: from iris1.csv.ica.uni-stuttgart.de ([IPv6:::ffff:129.69.118.2]:34105
	"EHLO iris1.csv.ica.uni-stuttgart.de") by linux-mips.org with ESMTP
	id <S8225302AbUAFSPA>; Tue, 6 Jan 2004 18:15:00 +0000
Received: from rembrandt.csv.ica.uni-stuttgart.de ([129.69.118.42])
	by iris1.csv.ica.uni-stuttgart.de with esmtp
	id 1AdvjE-00026I-00; Tue, 06 Jan 2004 19:14:56 +0100
Received: from ica2_ts by rembrandt.csv.ica.uni-stuttgart.de with local (Exim 3.35 #1 (Debian))
	id 1AdvjE-0003cb-00; Tue, 06 Jan 2004 19:14:56 +0100
Date: Tue, 6 Jan 2004 19:14:56 +0100
To: =?iso-8859-1?Q?J=F6?= Fahlke <jorrit@jorrit.de>
Cc: Linux on Mips Mailinglist <linux-mips@linux-mips.org>,
	Ralf Baechle <ralf@linux-mips.org>
Subject: Re: Assembler error in arch/mips/kernel/entry.S
Message-ID: <20040106181456.GH13721@rembrandt.csv.ica.uni-stuttgart.de>
References: <20040106163925.GA7342@fsk.uni-heidelberg.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20040106163925.GA7342@fsk.uni-heidelberg.de>
User-Agent: Mutt/1.5.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: 3872
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
Content-Length: 1124
Lines: 36

Jö Fahlke wrote:
[snip]
> ======================================================================
>         beqz    restore_all
>         if (in_exception_path)
>                 goto restore_all;
>         li      t0, PREEMPT_ACTIVE
> ======================================================================
> 
> Can someone please fix this?  My very limitet assembler knowledge
> gives me an idea whats wrong, but I don't know how to fix it.

The appended guesswork may help.


Thiemo


Index: entry.S
===================================================================
RCS file: /home/cvs/linux/arch/mips/kernel/entry.S,v
retrieving revision 1.58
diff -u -p -r1.58 entry.S
--- entry.S     30 Oct 2003 01:50:28 -0000      1.58
+++ entry.S     6 Jan 2004 18:11:23 -0000
@@ -52,9 +52,7 @@ ENTRY(resume_kernel)
 need_resched:
        LONG_L  t0, TI_FLAGS($28)
        andi    t1, t0, _TIF_NEED_RESCHED
-       beqz    restore_all
-       if (in_exception_path)
-               goto restore_all;
+       beqz    t1, restore_all
        li      t0, PREEMPT_ACTIVE
        sw      t0, TI_PRE_COUNT($28)
        local_irq_enable t0

From joe@jorrit.de Tue Jan  6 19:21:16 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 06 Jan 2004 19:21:17 +0000 (GMT)
Received: from ns1.xeneris.net ([IPv6:::ffff:195.49.173.97]:31106 "HELO
	superfix.xeneris.net") by linux-mips.org with SMTP
	id <S8224954AbUAFTVQ>; Tue, 6 Jan 2004 19:21:16 +0000
Received: (qmail 684 invoked by uid 64014); 6 Jan 2004 19:21:19 -0000
Received: from joe@jorrit.de by superfix by uid 64011 with qmail-scanner-1.15 
 (clamscan: 0.54. spamassassin: 2.50-cvs.  Clear:. 
 Processed in 0.58116 secs); 06 Jan 2004 19:21:19 -0000
Received: from localhost (HELO jupiter.planets) (127.0.0.1)
  by localhost with SMTP; 6 Jan 2004 19:21:18 -0000
Received: from joe by jupiter.planets with local (Exim 3.36 #1 (Debian))
	id 1AdwlI-00024J-00; Tue, 06 Jan 2004 20:21:08 +0100
Date: Tue, 6 Jan 2004 20:21:08 +0100
From: =?iso-8859-1?Q?J=F6?= Fahlke <jorrit@jorrit.de>
To: Thiemo Seufer <ica2_ts@csv.ica.uni-stuttgart.de>
Cc: Linux on Mips Mailinglist <linux-mips@linux-mips.org>,
	Ralf Baechle <ralf@linux-mips.org>
Subject: Re: Assembler error in arch/mips/kernel/entry.S
Message-ID: <20040106192107.GB7342@fsk.uni-heidelberg.de>
Mail-Followup-To: =?iso-8859-1?Q?J=F6?= Fahlke <jorrit@jorrit.de>,
	Thiemo Seufer <ica2_ts@csv.ica.uni-stuttgart.de>,
	Linux on Mips Mailinglist <linux-mips@linux-mips.org>,
	Ralf Baechle <ralf@linux-mips.org>
References: <20040106163925.GA7342@fsk.uni-heidelberg.de> <20040106181456.GH13721@rembrandt.csv.ica.uni-stuttgart.de>
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="TakKZr9L6Hm6aLOc"
Content-Disposition: inline
In-Reply-To: <20040106181456.GH13721@rembrandt.csv.ica.uni-stuttgart.de>
User-Agent: Mutt/1.5.4i
Return-Path: <joe@jorrit.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: 3873
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: jorrit@jorrit.de
Precedence: bulk
X-list: linux-mips
Content-Length: 1452
Lines: 45


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

Am Di,  6. Jan 2004, 19:14:56 +0100 schrieb Thiemo Seufer:
> -       beqz    restore_all
> -       if (in_exception_path)
> -               goto restore_all;
> +       beqz    t1, restore_all
>         li      t0, PREEMPT_ACTIVE

Thanks, that helped a bit, but still I get:

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
  AS      arch/mips/kernel/entry.o
arch/mips/kernel/entry.S: Assembler messages:
arch/mips/kernel/entry.S:56: Error: absolute expression required `li'
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

J=F6.

--=20
oil -- operation iraqi liberation
http://www.mo.tecsamples.de/mahnwache/index.html

--TakKZr9L6Hm6aLOc
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

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

iD8DBQE/+wqj9pw8d07v1OsRAsoAAKCtaeZyi0oqRVp+XyqAKOwwq1KYAgCggu4Y
VJTwZfQe5NoJpH50faPfhcs=
=b+0/
-----END PGP SIGNATURE-----

--TakKZr9L6Hm6aLOc--

From dimitri@sonycom.com Tue Jan  6 20:58:04 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 06 Jan 2004 20:58:05 +0000 (GMT)
Received: from witte.sonytel.be ([IPv6:::ffff:80.88.33.193]:21135 "EHLO
	witte.sonytel.be") by linux-mips.org with ESMTP id <S8224954AbUAFU6C>;
	Tue, 6 Jan 2004 20:58:02 +0000
Received: from teasel.sonytel.be (localhost [127.0.0.1])
	by witte.sonytel.be (8.12.10/8.12.10) with ESMTP id i06KvwQF006888;
	Tue, 6 Jan 2004 21:57:58 +0100 (MET)
Received: (from dimitri@localhost)
	by teasel.sonytel.be (8.9.3+Sun/8.9.3) id VAA19546;
	Tue, 6 Jan 2004 21:57:59 +0100 (MET)
Date: Tue, 6 Jan 2004 21:57:59 +0100
From: Dimitri Torfs <dimitri@sonycom.com>
To: ralf@linux-mips.org
Cc: linux-mips@linux-mips.org
Subject: [PATCH][2.6] Fix Makefiles for CONFIG_EMBEDDED_RAMDISK
Message-ID: <20040106205758.GA19525@sonycom.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.4.1i
Return-Path: <dimitri@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: 3874
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: dimitri@sonycom.com
Precedence: bulk
X-list: linux-mips
Content-Length: 1807
Lines: 64

Hi,

  here are patches that fix the arch/mips/Makefile and
  arch/mips/ramdisk/Makefile when an embedded ramdisk image needs to
  be included through the CONFIG_EMBEDDED_RAMDISK option.


--- linux-mips-2.6.orig/arch/mips/Makefile	2004-01-06 21:17:57.000000000 +0100
+++ linux.work/arch/mips/Makefile	2004-01-06 21:43:33.000000000 +0100
@@ -187,13 +187,11 @@
 
 #
 # ramdisk/initrd support
-# You need a compressed ramdisk image, named ramdisk.gz in
-# arch/mips/ramdisk
+# You need a compressed ramdisk image, named
+# CONFIG_EMBEDDED_RAMDISK_IMAGE. Relative pathnames 
+# are relative to arch/mips/ramdisk/.
 #
-ifdef CONFIG_EMBEDDED_RAMDISK
-CORE_FILES	+= arch/mips/ramdisk/ramdisk.o
-SUBDIRS		+= arch/mips/ramdisk
-endif
+core-$(CONFIG_EMBEDDED_RAMDISK)	+= arch/mips/ramdisk/
 
 #
 # Firmware support



--- linux-mips-2.6.orig/arch/mips/ramdisk/Makefile	2003-07-29 16:26:23.000000000 +0200
+++ linux.work/arch/mips/ramdisk/Makefile	2004-01-06 21:40:50.000000000 +0100
@@ -2,8 +2,19 @@
 # Makefile for a ramdisk image
 #
 
+obj-y += ramdisk.o
+
+
 O_FORMAT = $(shell $(OBJDUMP) -i | head -n 2 | grep elf32)
-img = $(CONFIG_EMBEDDED_RAMDISK_IMAGE)
-ramdisk.o: $(subst ",,$(img)) ld.script
-	echo "O_FORMAT:  " $(O_FORMAT)
-	$(LD) -T ld.script -b binary --oformat $(O_FORMAT) -o $@ $(img)
+img := $(subst ",,$(CONFIG_EMBEDDED_RAMDISK_IMAGE))
+# add $(src) when $(img) is relative
+img := $(subst $(src)//,/,$(src)/$(img))
+
+quiet_cmd_ramdisk = LD      $@
+define cmd_ramdisk
+	$(LD) -T $(src)/ld.script -b binary --oformat $(O_FORMAT) -o $@ $(img)
+endef
+
+$(obj)/ramdisk.o: $(img) $(src)/ld.script
+	$(call cmd,ramdisk)
+


-- 
Dimitri Torfs             |  NSCE 
dimitri.torfs@sonycom.com |  Sint Stevens Woluwestraat 55
tel: +32 2 2908451        |  1130 Brussel
fax: +32 2 7262686        |  Belgium


From yuasa@hh.iij4u.or.jp Wed Jan  7 03:55:15 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 07 Jan 2004 03:55:18 +0000 (GMT)
Received: from mo02.iij4u.or.jp ([IPv6:::ffff:210.130.0.19]:63983 "EHLO
	mo02.iij4u.or.jp") by linux-mips.org with ESMTP id <S8225367AbUAGDzP>;
	Wed, 7 Jan 2004 03:55:15 +0000
Received: from mdo00.iij4u.or.jp (mdo00.iij4u.or.jp [210.130.0.170])
	by mo02.iij4u.or.jp (8.8.8/MFO1.5) with ESMTP id MAA26448;
	Wed, 7 Jan 2004 12:55:10 +0900 (JST)
Received: 4UMDO00 id i073tAr07336; Wed, 7 Jan 2004 12:55:10 +0900 (JST)
Received: 4UMRO00 id i073t9a18785; Wed, 7 Jan 2004 12:55:09 +0900 (JST)
	from rally.montavista.co.jp (sonicwall.montavista.co.jp [202.232.97.131]) (authenticated)
Date: Wed, 7 Jan 2004 12:55:09 +0900
From: Yoichi Yuasa <yuasa@hh.iij4u.or.jp>
To: Ralf Baechle <ralf@linux-mips.org>
Cc: yuasa@hh.iij4u.or.jp, linux-mips <linux-mips@linux-mips.org>
Subject: [PATCH][2.6] add smp.h in processor.h
Message-Id: <20040107125509.34cfa9db.yuasa@hh.iij4u.or.jp>
X-Mailer: Sylpheed version 0.9.8a (GTK+ 1.2.10; i686-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Return-Path: <yuasa@hh.iij4u.or.jp>
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: 3875
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: yuasa@hh.iij4u.or.jp
Precedence: bulk
X-list: linux-mips
Content-Length: 588
Lines: 22

Hello Ralf,

I made a patch for header file of 2.6.

smp_processor_id() is defined in smp.h.
We need adding #include <linux/smp.h> in processor.h.

Please apply this patch.

Yoichi

diff -urN -X dontdiff linux-orig/include/asm-mips/processor.h linux/include/asm-mips/processor.h
--- linux-orig/include/asm-mips/processor.h	2003-12-04 10:52:06.000000000 +0900
+++ linux/include/asm-mips/processor.h	2004-01-07 12:24:25.000000000 +0900
@@ -13,6 +13,7 @@
 
 #include <linux/config.h>
 #include <linux/cache.h>
+#include <linux/smp.h>
 #include <linux/threads.h>
 
 #include <asm/cachectl.h>

From ralf@linux-mips.org Wed Jan  7 05:28:39 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 07 Jan 2004 05:28:40 +0000 (GMT)
Received: from p508B4F41.dip.t-dialin.net ([IPv6:::ffff:80.139.79.65]:25506
	"EHLO mail.linux-mips.net") by linux-mips.org with ESMTP
	id <S8224934AbUAGF2j>; Wed, 7 Jan 2004 05:28:39 +0000
Received: from dea.linux-mips.net (localhost [127.0.0.1])
	by mail.linux-mips.net (8.12.8/8.12.8) with ESMTP id i075SVa5007293;
	Wed, 7 Jan 2004 06:28:32 +0100
Received: (from ralf@localhost)
	by dea.linux-mips.net (8.12.8/8.12.8/Submit) id i075STI1007289;
	Wed, 7 Jan 2004 06:28:29 +0100
Date: Wed, 7 Jan 2004 06:28:29 +0100
From: Ralf Baechle <ralf@linux-mips.org>
To: Yoichi Yuasa <yuasa@hh.iij4u.or.jp>
Cc: linux-mips <linux-mips@linux-mips.org>
Subject: Re: [PATCH][2.6] add smp.h in processor.h
Message-ID: <20040107052829.GB29672@linux-mips.org>
References: <20040107125509.34cfa9db.yuasa@hh.iij4u.or.jp>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20040107125509.34cfa9db.yuasa@hh.iij4u.or.jp>
User-Agent: Mutt/1.4.1i
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: 3876
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
Content-Length: 467
Lines: 13

On Wed, Jan 07, 2004 at 12:55:09PM +0900, Yoichi Yuasa wrote:

> I made a patch for header file of 2.6.
> 
> smp_processor_id() is defined in smp.h.
> We need adding #include <linux/smp.h> in processor.h.

<linux/smp.h> pulls in a fairly large number of other header files which
is why no Linux architecture includes <linux/smp.h> in <asm/processor.h>.
So instead please include the file directly into your code.  In which .c
file you're hitting the problem?

  Ralf

From yuasa@hh.iij4u.or.jp Wed Jan  7 06:42:22 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 07 Jan 2004 06:42:23 +0000 (GMT)
Received: from mo02.iij4u.or.jp ([IPv6:::ffff:210.130.0.19]:37335 "EHLO
	mo02.iij4u.or.jp") by linux-mips.org with ESMTP id <S8224950AbUAGGmW>;
	Wed, 7 Jan 2004 06:42:22 +0000
Received: from mdo00.iij4u.or.jp (mdo00.iij4u.or.jp [210.130.0.170])
	by mo02.iij4u.or.jp (8.8.8/MFO1.5) with ESMTP id PAA24743;
	Wed, 7 Jan 2004 15:42:17 +0900 (JST)
Received: 4UMDO00 id i076gHr08948; Wed, 7 Jan 2004 15:42:17 +0900 (JST)
Received: 4UMRO01 id i076gGH05546; Wed, 7 Jan 2004 15:42:16 +0900 (JST)
	from rally.montavista.co.jp (sonicwall.montavista.co.jp [202.232.97.131]) (authenticated)
Date: Wed, 7 Jan 2004 15:42:16 +0900
From: Yoichi Yuasa <yuasa@hh.iij4u.or.jp>
To: Ralf Baechle <ralf@linux-mips.org>
Cc: yuasa@hh.iij4u.or.jp, linux-mips@linux-mips.org
Subject: Re: [PATCH][2.6] add smp.h in processor.h
Message-Id: <20040107154216.77967c1e.yuasa@hh.iij4u.or.jp>
In-Reply-To: <20040107052829.GB29672@linux-mips.org>
References: <20040107125509.34cfa9db.yuasa@hh.iij4u.or.jp>
	<20040107052829.GB29672@linux-mips.org>
X-Mailer: Sylpheed version 0.9.8a (GTK+ 1.2.10; i686-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Return-Path: <yuasa@hh.iij4u.or.jp>
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: 3877
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: yuasa@hh.iij4u.or.jp
Precedence: bulk
X-list: linux-mips
Content-Length: 4511
Lines: 119

On Wed, 7 Jan 2004 06:28:29 +0100
Ralf Baechle <ralf@linux-mips.org> wrote:

> On Wed, Jan 07, 2004 at 12:55:09PM +0900, Yoichi Yuasa wrote:
> 
> > I made a patch for header file of 2.6.
> > 
> > smp_processor_id() is defined in smp.h.
> > We need adding #include <linux/smp.h> in processor.h.
> 
> <linux/smp.h> pulls in a fairly large number of other header files which
> is why no Linux architecture includes <linux/smp.h> in <asm/processor.h>.
> So instead please include the file directly into your code.  In which .c
> file you're hitting the problem?

OK, I made a patch for same problem about vr41xx.
Please apply this patch.

Yoichi

diff -urN -X dontdiff linux-orig/arch/mips/vr41xx/common/bcu.c linux/arch/mips/vr41xx/common/bcu.c
--- linux-orig/arch/mips/vr41xx/common/bcu.c	2003-12-16 10:56:22.000000000 +0900
+++ linux/arch/mips/vr41xx/common/bcu.c	2004-01-07 15:09:06.000000000 +0900
@@ -40,6 +40,7 @@
  *  - Added support for NEC VR4133.
  */
 #include <linux/init.h>
+#include <linux/smp.h>
 #include <linux/types.h>
 
 #include <asm/cpu.h>
diff -urN -X dontdiff linux-orig/arch/mips/vr41xx/common/cmu.c linux/arch/mips/vr41xx/common/cmu.c
--- linux-orig/arch/mips/vr41xx/common/cmu.c	2003-10-31 11:29:18.000000000 +0900
+++ linux/arch/mips/vr41xx/common/cmu.c	2004-01-07 15:09:19.000000000 +0900
@@ -40,6 +40,7 @@
  *  - Added support for NEC VR4133.
  */
 #include <linux/init.h>
+#include <linux/smp.h>
 #include <linux/types.h>
 
 #include <asm/cpu.h>
diff -urN -X dontdiff linux-orig/arch/mips/vr41xx/common/giu.c linux/arch/mips/vr41xx/common/giu.c
--- linux-orig/arch/mips/vr41xx/common/giu.c	2003-12-16 10:56:22.000000000 +0900
+++ linux/arch/mips/vr41xx/common/giu.c	2004-01-07 15:09:36.000000000 +0900
@@ -42,6 +42,7 @@
 #include <linux/init.h>
 #include <linux/irq.h>
 #include <linux/kernel.h>
+#include <linux/smp.h>
 #include <linux/types.h>
 
 #include <asm/cpu.h>
diff -urN -X dontdiff linux-orig/arch/mips/vr41xx/common/icu.c linux/arch/mips/vr41xx/common/icu.c
--- linux-orig/arch/mips/vr41xx/common/icu.c	2003-12-16 10:56:22.000000000 +0900
+++ linux/arch/mips/vr41xx/common/icu.c	2004-01-07 15:09:52.000000000 +0900
@@ -43,6 +43,7 @@
 #include <linux/init.h>
 #include <linux/interrupt.h>
 #include <linux/irq.h>
+#include <linux/smp.h>
 #include <linux/types.h>
 
 #include <asm/cpu.h>
diff -urN -X dontdiff linux-orig/arch/mips/vr41xx/common/rtc.c linux/arch/mips/vr41xx/common/rtc.c
--- linux-orig/arch/mips/vr41xx/common/rtc.c	2003-12-02 04:32:01.000000000 +0900
+++ linux/arch/mips/vr41xx/common/rtc.c	2004-01-07 15:10:26.000000000 +0900
@@ -19,6 +19,7 @@
  */
 #include <linux/init.h>
 #include <linux/irq.h>
+#include <linux/smp.h>
 #include <linux/types.h>
 
 #include <asm/io.h>
diff -urN -X dontdiff linux-orig/arch/mips/vr41xx/common/serial.c linux/arch/mips/vr41xx/common/serial.c
--- linux-orig/arch/mips/vr41xx/common/serial.c	2003-10-31 11:29:18.000000000 +0900
+++ linux/arch/mips/vr41xx/common/serial.c	2004-01-07 15:10:13.000000000 +0900
@@ -42,6 +42,7 @@
 #include <linux/init.h>
 #include <linux/types.h>
 #include <linux/serial.h>
+#include <linux/smp.h>
 
 #include <asm/addrspace.h>
 #include <asm/cpu.h>
diff -urN -X dontdiff linux-orig/arch/mips/vr41xx/tanbac-tb0226/init.c linux/arch/mips/vr41xx/tanbac-tb0226/init.c
--- linux-orig/arch/mips/vr41xx/tanbac-tb0226/init.c	2003-11-25 15:28:19.000000000 +0900
+++ linux/arch/mips/vr41xx/tanbac-tb0226/init.c	2004-01-07 15:10:42.000000000 +0900
@@ -15,6 +15,7 @@
  */
 #include <linux/init.h>
 #include <linux/kernel.h>
+#include <linux/smp.h>
 #include <linux/string.h>
 
 #include <asm/bootinfo.h>
diff -urN -X dontdiff linux-orig/arch/mips/vr41xx/tanbac-tb0229/init.c linux/arch/mips/vr41xx/tanbac-tb0229/init.c
--- linux-orig/arch/mips/vr41xx/tanbac-tb0229/init.c	2003-11-25 15:28:19.000000000 +0900
+++ linux/arch/mips/vr41xx/tanbac-tb0229/init.c	2004-01-07 15:10:57.000000000 +0900
@@ -20,6 +20,7 @@
 #include <linux/init.h>
 #include <linux/kernel.h>
 #include <linux/sched.h>
+#include <linux/smp.h>
 #include <linux/string.h>
 
 #include <asm/bootinfo.h>
diff -urN -X dontdiff linux-orig/arch/mips/vr41xx/zao-capcella/init.c linux/arch/mips/vr41xx/zao-capcella/init.c
--- linux-orig/arch/mips/vr41xx/zao-capcella/init.c	2003-11-25 15:28:19.000000000 +0900
+++ linux/arch/mips/vr41xx/zao-capcella/init.c	2004-01-07 15:11:09.000000000 +0900
@@ -15,6 +15,7 @@
  */
 #include <linux/init.h>
 #include <linux/kernel.h>
+#include <linux/smp.h>
 #include <linux/string.h>
 
 #include <asm/bootinfo.h>

From jbglaw@dvmwest.gt.owl.de Wed Jan  7 06:42:55 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 07 Jan 2004 06:42:56 +0000 (GMT)
Received: from dvmwest.gt.owl.de ([IPv6:::ffff:62.52.24.140]:947 "EHLO
	dvmwest.gt.owl.de") by linux-mips.org with ESMTP
	id <S8225245AbUAGGmW>; Wed, 7 Jan 2004 06:42:22 +0000
Received: by dvmwest.gt.owl.de (Postfix, from userid 1001)
	id 0F0FD4B492; Wed,  7 Jan 2004 07:42:18 +0100 (CET)
Date: Wed, 7 Jan 2004 07:42:18 +0100
From: Jan-Benedict Glaw <jbglaw@lug-owl.de>
To: Linux-Mips <linux-mips@linux-mips.org>
Subject: Re: What toolchain for vr4181
Message-ID: <20040107064218.GJ14285@lug-owl.de>
Mail-Followup-To: Linux-Mips <linux-mips@linux-mips.org>
References: <Pine.GSO.4.21.0310091320000.7430-100000@waterleaf.sonytel.be> <Pine.GSO.4.21.0312282120390.2325-100000@waterleaf.sonytel.be>
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="qhD8kUEc5MK9MdKG"
Content-Disposition: inline
In-Reply-To: <Pine.GSO.4.21.0312282120390.2325-100000@waterleaf.sonytel.be>
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
User-Agent: Mutt/1.5.4i
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: 3878
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
Content-Length: 1380
Lines: 45


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

On Sun, 2003-12-28 21:30:17 +0100, Geert Uytterhoeven <geert@linux-m68k.org>
wrote in message <Pine.GSO.4.21.0312282120390.2325-100000@waterleaf.sonytel=
=2Ebe>:
> BTW, I'd still really like to have some scripts so I can install (from bi=
nary
> or from sources) Debian binaries in my home dir on a Red Hat or Solaris b=
ox.
> Wishful thinking?

Well, 'dpkg-deb -x' does the unpacking, which should be enough for most
of the simple packages. But I can't just come up with a "general"
solution except...

Hmmm. Maybe you can use debootstrap for this purpose.

MfG, JBG

--=20
   Jan-Benedict Glaw       jbglaw@lug-owl.de    . +49-172-7608481
   "Eine Freie Meinung in  einem Freien Kopf    | Gegen Zensur | Gegen Krieg
    fuer einen Freien Staat voll Freier B=FCrger" | im Internet! |   im Ira=
k!
   ret =3D do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TC=
PA));

--qhD8kUEc5MK9MdKG
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

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

iD8DBQE/+6pKHb1edYOZ4bsRAtdJAJ98Ywh1UEUl+DNItd5K+h4zHpp+DQCfd7CW
KaTlZkIswPExH2c2fdH2/n8=
=3hGa
-----END PGP SIGNATURE-----

--qhD8kUEc5MK9MdKG--

From charlieb-linux-mips@e-smith.com Wed Jan  7 20:44:43 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 07 Jan 2004 20:44:46 +0000 (GMT)
Received: from mail.e-smith.com ([IPv6:::ffff:216.191.234.126]:12295 "HELO
	nssg.mitel.com") by linux-mips.org with SMTP id <S8225223AbUAGUon>;
	Wed, 7 Jan 2004 20:44:43 +0000
Received: (qmail 16703 invoked by uid 404); 7 Jan 2004 20:44:33 -0000
Received: from charlieb-linux-mips@e-smith.com by tripe.nssg.mitel.com with qmail-scanner; 07 Jan 2004 15:44:33 -0000
Received: from allspice-core.nssg.mitel.com (HELO e-smith.com) (10.33.16.12)
  by tripe.nssg.mitel.com (10.33.17.11) with SMTP; 07 Jan 2004 20:44:33 -0000
Received: (qmail 7373 invoked by uid 5008); 7 Jan 2004 20:44:32 -0000
Received: from localhost (sendmail-bs@127.0.0.1)
  by localhost with SMTP; 7 Jan 2004 20:44:32 -0000
Date: Wed, 7 Jan 2004 15:44:32 -0500 (EST)
From: Charlie Brady <charlieb-linux-mips@e-smith.com>
X-X-Sender: charlieb@allspice.nssg.mitel.com
To: Dimitri Torfs <dimitri@sonycom.com>
cc: linux-mips@linux-mips.org
Subject: Re: [PATCH][2.6] Fix Makefiles for CONFIG_EMBEDDED_RAMDISK
In-Reply-To: <20040106205758.GA19525@sonycom.com>
Message-ID: <Pine.LNX.4.44.0401071543430.1954-100000@allspice.nssg.mitel.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <charlieb-linux-mips@e-smith.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: 3879
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: charlieb-linux-mips@e-smith.com
Precedence: bulk
X-list: linux-mips
Content-Length: 318
Lines: 12


On Tue, 6 Jan 2004, Dimitri Torfs wrote:

>   here are patches that fix the arch/mips/Makefile and
>   arch/mips/ramdisk/Makefile when an embedded ramdisk image needs to
>   be included through the CONFIG_EMBEDDED_RAMDISK option.

I'm curious as to why this is a mips specific feature. Does anyone know?

--
Charlie


From anemo@mba.ocn.ne.jp Thu Jan  8 14:15:42 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 08 Jan 2004 14:15:43 +0000 (GMT)
Received: from mba.ocn.ne.jp ([IPv6:::ffff:210.190.142.172]:15074 "HELO
	smtp.mba.ocn.ne.jp") by linux-mips.org with SMTP
	id <S8225215AbUAHOPm>; Thu, 8 Jan 2004 14:15:42 +0000
Received: from localhost (p4063-ipad32funabasi.chiba.ocn.ne.jp [221.189.136.63])
	by smtp.mba.ocn.ne.jp (Postfix) with ESMTP
	id C82AB577C; Thu,  8 Jan 2004 23:15:38 +0900 (JST)
Date: Thu, 08 Jan 2004 23:20:00 +0900 (JST)
Message-Id: <20040108.232000.59460880.anemo@mba.ocn.ne.jp>
To: linux-mips@linux-mips.org, ralf@linux-mips.org
Subject: show_regs fix in 2.4
From: Atsushi Nemoto <anemo@mba.ocn.ne.jp>
X-Fingerprint: 6ACA 1623 39BD 9A94 9B1A  B746 CA77 FE94 2874 D52F
X-Pgp-Public-Key: http://wwwkeys.pgp.net/pks/lookup?op=get&search=0x2874D52F
X-Mailer: Mew version 2.2 on Emacs 20.7 / Mule 4.0 (HANANOEN)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Return-Path: <anemo@mba.ocn.ne.jp>
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: 3880
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: anemo@mba.ocn.ne.jp
Precedence: bulk
X-list: linux-mips
Content-Length: 648
Lines: 20

Cut'n paste error in 2.4 arch/mips/kernel/traps.c.  Please apply.

Index: traps.c
===================================================================
RCS file: /home/cvs/linux/arch/mips/kernel/traps.c,v
retrieving revision 1.99.2.62
diff -u -r1.99.2.62 traps.c
--- traps.c	15 Dec 2003 20:13:36 -0000	1.99.2.62
+++ traps.c	8 Jan 2004 14:07:41 -0000
@@ -237,7 +237,7 @@
 	 */
 	printk("epc   : %08lx    %s\n", regs->cp0_epc, print_tainted());
 	printk("Status: %08lx\n", regs->cp0_status);
-	printk("epc   : %08lx\n", regs->cp0_cause);
+	printk("Cause : %08lx\n", regs->cp0_cause);
 	printk("PrId  : %08x\n", read_c0_prid());
 }
 
---
Atsushi Nemoto

From yuasa@hh.iij4u.or.jp Thu Jan  8 17:26:01 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 08 Jan 2004 17:26:03 +0000 (GMT)
Received: from mo03.iij4u.or.jp ([IPv6:::ffff:210.130.0.20]:12027 "EHLO
	mo03.iij4u.or.jp") by linux-mips.org with ESMTP id <S8225216AbUAHR0B>;
	Thu, 8 Jan 2004 17:26:01 +0000
Received: from mdo01.iij4u.or.jp (mdo01.iij4u.or.jp [210.130.0.171])
	by mo03.iij4u.or.jp (8.8.8/MFO1.5) with ESMTP id CAA29136;
	Fri, 9 Jan 2004 02:25:58 +0900 (JST)
Received: 4UMDO01 id i08HPve03782; Fri, 9 Jan 2004 02:25:57 +0900 (JST)
Received: 4UMRO01 id i08HPuf05835; Fri, 9 Jan 2004 02:25:56 +0900 (JST)
	from stratos.frog (64.43.138.210.xn.2iij.net [210.138.43.64]) (authenticated)
Date: Fri, 9 Jan 2004 02:25:54 +0900
From: Yoichi Yuasa <yuasa@hh.iij4u.or.jp>
To: Ralf Baechle <ralf@linux-mips.org>
Cc: yuasa@hh.iij4u.or.jp, linux-mips <linux-mips@linux-mips.org>
Subject: [PATCH][2.4] cache workaround for VR4131
Message-Id: <20040109022554.49768c94.yuasa@hh.iij4u.or.jp>
X-Mailer: Sylpheed version 0.9.8a (GTK+ 1.2.10; i686-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Return-Path: <yuasa@hh.iij4u.or.jp>
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: 3881
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: yuasa@hh.iij4u.or.jp
Precedence: bulk
X-list: linux-mips
Content-Length: 3152
Lines: 112

Hello Ralf,

I made a patch for cache workaround of VR4131.
This patch moves cache workaround to common part from board dependence part.

Please apply this patch.

Yoichi
diff -urN -X dontdiff linux-orig/arch/mips/mm/c-r4k.c linux/arch/mips/mm/c-r4k.c
--- linux-orig/arch/mips/mm/c-r4k.c	Mon Jan  5 17:22:07 2004
+++ linux/arch/mips/mm/c-r4k.c	Fri Jan  9 01:52:45 2004
@@ -701,6 +701,13 @@
 	case CPU_VR4133:
 		write_c0_config(config & ~CONF_EB);
 	case CPU_VR4131:
+		/* Workaround for cache instruction bug of VR4131 */
+		if (c->processor_id == 0x0c80U || c->processor_id == 0x0c81U ||
+		    c->processor_id == 0x0c82U) {
+			config &= ~0x00000030U;
+			config |= 0x00410000U;
+			write_c0_config(config);
+		}
 		icache_size = 1 << (10 + ((config & CONF_IC) >> 9));
 		c->icache.linesz = 16 << ((config & CONF_IB) >> 5);
 		c->icache.ways = 2;
diff -urN -X dontdiff linux-orig/arch/mips/vr41xx/tanbac-tb0226/init.c linux/arch/mips/vr41xx/tanbac-tb0226/init.c
--- linux-orig/arch/mips/vr41xx/tanbac-tb0226/init.c	Tue Apr 15 01:31:39 2003
+++ linux/arch/mips/vr41xx/tanbac-tb0226/init.c	Fri Jan  9 01:52:45 2004
@@ -32,7 +32,6 @@
 
 void __init prom_init(int argc, char **argv, unsigned long magic, int *prom_vec)
 {
-	u32 config;
 	int i;
 
 	/*
@@ -46,17 +45,6 @@
 
 	mips_machgroup = MACH_GROUP_NEC_VR41XX;
 	mips_machtype = MACH_TANBAC_TB0226;
-
-	switch (current_cpu_data.processor_id) {
-	case PRID_VR4131_REV1_2:
-		config = read_c0_config();
-		config &= ~0x00000030UL;
-		config |= 0x00410000UL;
-		write_c0_config(config);
-		break;
-	default:
-		break;
-	}
 }
 
 void __init prom_free_prom_memory (void)
diff -urN -X dontdiff linux-orig/arch/mips/vr41xx/tanbac-tb0229/init.c linux/arch/mips/vr41xx/tanbac-tb0229/init.c
--- linux-orig/arch/mips/vr41xx/tanbac-tb0229/init.c	Thu May 22 06:36:53 2003
+++ linux/arch/mips/vr41xx/tanbac-tb0229/init.c	Fri Jan  9 01:52:45 2004
@@ -37,7 +37,6 @@
 
 void __init prom_init(int argc, char **argv, unsigned long magic, int *prom_vec)
 {
-	u32 config;
 	int i;
 
 	/*
@@ -51,17 +50,6 @@
 
 	mips_machgroup = MACH_GROUP_NEC_VR41XX;
 	mips_machtype = MACH_TANBAC_TB0229;
-
-	switch (current_cpu_data.processor_id) {
-	case PRID_VR4131_REV1_2:
-		config = read_c0_config();
-		config &= ~0x00000030UL;
-		config |= 0x00410000UL;
-		write_c0_config(config);
-		break;
-	default:
-		break;
-	}
 }
 
 void __init prom_free_prom_memory (void)
diff -urN -X dontdiff linux-orig/arch/mips/vr41xx/zao-capcella/init.c linux/arch/mips/vr41xx/zao-capcella/init.c
--- linux-orig/arch/mips/vr41xx/zao-capcella/init.c	Tue Apr 15 01:31:39 2003
+++ linux/arch/mips/vr41xx/zao-capcella/init.c	Fri Jan  9 01:52:45 2004
@@ -32,7 +32,6 @@
 
 void __init prom_init(int argc, char **argv, unsigned long magic, int *prom_vec)
 {
-	u32 config;
 	int i;
 
 	/*
@@ -46,17 +45,6 @@
 
 	mips_machgroup = MACH_GROUP_NEC_VR41XX;
 	mips_machtype = MACH_ZAO_CAPCELLA;
-
-	switch (current_cpu_data.processor_id) {
-	case PRID_VR4131_REV1_2:
-		config = read_c0_config();
-		config &= ~0x00000030UL;
-		config |= 0x00410000UL;
-		write_c0_config(config);
-		break;
-	default:
-		break;
-	}
 }
 
 void __init prom_free_prom_memory (void)

From yuasa@hh.iij4u.or.jp Thu Jan  8 23:22:16 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 08 Jan 2004 23:22:17 +0000 (GMT)
Received: from mo02.iij4u.or.jp ([IPv6:::ffff:210.130.0.19]:24036 "EHLO
	mo02.iij4u.or.jp") by linux-mips.org with ESMTP id <S8225228AbUAHXWQ>;
	Thu, 8 Jan 2004 23:22:16 +0000
Received: from mdo01.iij4u.or.jp (mdo01.iij4u.or.jp [210.130.0.171])
	by mo02.iij4u.or.jp (8.8.8/MFO1.5) with ESMTP id IAA02786;
	Fri, 9 Jan 2004 08:22:12 +0900 (JST)
Received: 4UMDO01 id i08NMCC05667; Fri, 9 Jan 2004 08:22:12 +0900 (JST)
Received: 4UMRO00 id i08NMBs03712; Fri, 9 Jan 2004 08:22:11 +0900 (JST)
	from stratos.frog (64.43.138.210.xn.2iij.net [210.138.43.64]) (authenticated)
Date: Fri, 9 Jan 2004 08:22:06 +0900
From: Yoichi Yuasa <yuasa@hh.iij4u.or.jp>
To: Ralf Baechle <ralf@linux-mips.org>
Cc: yuasa@hh.iij4u.or.jp, linux-mips <linux-mips@linux-mips.org>
Subject: [PATCH][2.6] cache workaround for VR4131
Message-Id: <20040109082206.429ff300.yuasa@hh.iij4u.or.jp>
X-Mailer: Sylpheed version 0.9.8a (GTK+ 1.2.10; i686-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Return-Path: <yuasa@hh.iij4u.or.jp>
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: 3882
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: yuasa@hh.iij4u.or.jp
Precedence: bulk
X-list: linux-mips
Content-Length: 3109
Lines: 114

Hello Ralf,

I made a patch for cache workaround of VR4131 for 2.6 too.
This patch moves cache workaround to common part from board dependence part.

Please apply this patch.

Yoichi

diff -urN -X dontdiff linux-orig/arch/mips/mm/c-r4k.c linux/arch/mips/mm/c-r4k.c
--- linux-orig/arch/mips/mm/c-r4k.c	Mon Jan  5 17:27:29 2004
+++ linux/arch/mips/mm/c-r4k.c	Fri Jan  9 08:09:17 2004
@@ -707,6 +707,13 @@
 	case CPU_VR4133:
 		write_c0_config(config & ~CONF_EB);
 	case CPU_VR4131:
+		/* Workaround for cache instruction bug of VR4131 */
+		if (c->processor_id == 0x0c80U || c->processor_id == 0x0c81U ||
+		    c->processor_id == 0x0c82U) {
+			config &= ~0x00000030U;
+			config |= 0x00410000U;
+			write_c0_config(config);
+		}
 		icache_size = 1 << (10 + ((config & CONF_IC) >> 9));
 		c->icache.linesz = 16 << ((config & CONF_IB) >> 5);
 		c->icache.ways = 2;
diff -urN -X dontdiff linux-orig/arch/mips/vr41xx/tanbac-tb0226/init.c linux/arch/mips/vr41xx/tanbac-tb0226/init.c
--- linux-orig/arch/mips/vr41xx/tanbac-tb0226/init.c	Tue Nov 18 12:34:23 2003
+++ linux/arch/mips/vr41xx/tanbac-tb0226/init.c	Fri Jan  9 08:09:18 2004
@@ -33,7 +33,6 @@
 {
 	int argc = fw_arg0;
 	char **argv = (char **) fw_arg1;
-	u32 config;
 	int i;
 
 	/*
@@ -47,17 +46,6 @@
 
 	mips_machgroup = MACH_GROUP_NEC_VR41XX;
 	mips_machtype = MACH_TANBAC_TB0226;
-
-	switch (current_cpu_data.processor_id) {
-	case PRID_VR4131_REV1_2:
-		config = read_c0_config();
-		config &= ~0x00000030UL;
-		config |= 0x00410000UL;
-		write_c0_config(config);
-		break;
-	default:
-		break;
-	}
 }
 
 unsigned long __init prom_free_prom_memory(void)
diff -urN -X dontdiff linux-orig/arch/mips/vr41xx/tanbac-tb0229/init.c linux/arch/mips/vr41xx/tanbac-tb0229/init.c
--- linux-orig/arch/mips/vr41xx/tanbac-tb0229/init.c	Tue Nov 18 12:34:23 2003
+++ linux/arch/mips/vr41xx/tanbac-tb0229/init.c	Fri Jan  9 08:09:18 2004
@@ -38,7 +38,6 @@
 {
 	int argc = fw_arg0;
 	char **argv = (char **) fw_arg1;
-	u32 config;
 	int i;
 
 	/*
@@ -52,17 +51,6 @@
 
 	mips_machgroup = MACH_GROUP_NEC_VR41XX;
 	mips_machtype = MACH_TANBAC_TB0229;
-
-	switch (current_cpu_data.processor_id) {
-	case PRID_VR4131_REV1_2:
-		config = read_c0_config();
-		config &= ~0x00000030UL;
-		config |= 0x00410000UL;
-		write_c0_config(config);
-		break;
-	default:
-		break;
-	}
 }
 
 unsigned long __init prom_free_prom_memory(void)
diff -urN -X dontdiff linux-orig/arch/mips/vr41xx/zao-capcella/init.c linux/arch/mips/vr41xx/zao-capcella/init.c
--- linux-orig/arch/mips/vr41xx/zao-capcella/init.c	Tue Nov 18 12:34:23 2003
+++ linux/arch/mips/vr41xx/zao-capcella/init.c	Fri Jan  9 08:09:18 2004
@@ -33,7 +33,6 @@
 {
 	int argc = fw_arg0;
 	char **argv = (char **) fw_arg1;
-	u32 config;
 	int i;
 
 	/*
@@ -47,17 +46,6 @@
 
 	mips_machgroup = MACH_GROUP_NEC_VR41XX;
 	mips_machtype = MACH_ZAO_CAPCELLA;
-
-	switch (current_cpu_data.processor_id) {
-	case PRID_VR4131_REV1_2:
-		config = read_c0_config();
-		config &= ~0x00000030UL;
-		config |= 0x00410000UL;
-		write_c0_config(config);
-		break;
-	default:
-		break;
-	}
 }
 
 unsigned long __init prom_free_prom_memory(void)


From ralf@linux-mips.org Fri Jan  9 07:20:20 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 09 Jan 2004 07:20:20 +0000 (GMT)
Received: from p508B6890.dip.t-dialin.net ([IPv6:::ffff:80.139.104.144]:28558
	"EHLO mail.linux-mips.net") by linux-mips.org with ESMTP
	id <S8224948AbUAIHUU>; Fri, 9 Jan 2004 07:20:20 +0000
Received: from fluff.linux-mips.net (fluff.linux-mips.net [127.0.0.1])
	by mail.linux-mips.net (8.12.8/8.12.8) with ESMTP id i097KIfY002142
	for <linux-mips@linux-mips.org>; Fri, 9 Jan 2004 08:20:19 +0100
Received: (from ralf@localhost)
	by fluff.linux-mips.net (8.12.8/8.12.8/Submit) id i097KIgp002141
	for linux-mips@linux-mips.org; Fri, 9 Jan 2004 08:20:18 +0100
Resent-Message-Id: <200401090720.i097KIgp002141@fluff.linux-mips.net>
Date: Fri, 9 Jan 2004 08:06:15 +0100
From: Ralf Baechle <ralf@linux-mips.org>
To: Yoichi Yuasa <yuasa@hh.iij4u.or.jp>
Cc: linux-mips <linux-mips@linux-mips.org>
Subject: Re: [PATCH][2.4] cache workaround for VR4131
Message-ID: <20040109070615.GA1576@linux-mips.org>
References: <20040109022554.49768c94.yuasa@hh.iij4u.or.jp>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20040109022554.49768c94.yuasa@hh.iij4u.or.jp>
User-Agent: Mutt/1.4i
Resent-From: ralf@linux-mips.org
Resent-Date: Fri, 9 Jan 2004 08:20:18 +0100
Resent-To: linux-mips@linux-mips.org
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: 3883
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
Content-Length: 394
Lines: 12

On Fri, Jan 09, 2004 at 02:25:54AM +0900, Yoichi Yuasa wrote:

> I made a patch for cache workaround of VR4131.
> This patch moves cache workaround to common part from board dependence part.
> 
> Please apply this patch.

Applied - but please keep arch/mips/mm/c-r4k.c and arch/mips64/mm/c-r4k.c
in sync; the same applies to many other files that are identical in both
mips and mips64.

  Ralf

From ralf@linux-mips.org Fri Jan  9 07:36:56 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 09 Jan 2004 07:36:57 +0000 (GMT)
Received: from p508B6890.dip.t-dialin.net ([IPv6:::ffff:80.139.104.144]:47758
	"EHLO mail.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225242AbUAIHg4>; Fri, 9 Jan 2004 07:36:56 +0000
Received: from fluff.linux-mips.net (fluff.linux-mips.net [127.0.0.1])
	by mail.linux-mips.net (8.12.8/8.12.8) with ESMTP id i097atfY002486;
	Fri, 9 Jan 2004 08:36:55 +0100
Received: (from ralf@localhost)
	by fluff.linux-mips.net (8.12.8/8.12.8/Submit) id i097arpu002483;
	Fri, 9 Jan 2004 08:36:53 +0100
Date: Fri, 9 Jan 2004 08:36:53 +0100
From: Ralf Baechle <ralf@linux-mips.org>
To: Atsushi Nemoto <anemo@mba.ocn.ne.jp>
Cc: linux-mips@linux-mips.org
Subject: Re: show_regs fix in 2.4
Message-ID: <20040109073653.GA2468@linux-mips.org>
References: <20040108.232000.59460880.anemo@mba.ocn.ne.jp>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20040108.232000.59460880.anemo@mba.ocn.ne.jp>
User-Agent: Mutt/1.4i
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: 3884
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
Content-Length: 159
Lines: 7

On Thu, Jan 08, 2004 at 11:20:00PM +0900, Atsushi Nemoto wrote:

> Cut'n paste error in 2.4 arch/mips/kernel/traps.c.  Please apply.

Thanks, applied.

  Ralf

From ralf@linux-mips.org Fri Jan  9 07:40:56 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 09 Jan 2004 07:40:56 +0000 (GMT)
Received: from p508B6890.dip.t-dialin.net ([IPv6:::ffff:80.139.104.144]:53390
	"EHLO mail.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225259AbUAIHk4>; Fri, 9 Jan 2004 07:40:56 +0000
Received: from fluff.linux-mips.net (fluff.linux-mips.net [127.0.0.1])
	by mail.linux-mips.net (8.12.8/8.12.8) with ESMTP id i097epfY002599;
	Fri, 9 Jan 2004 08:40:51 +0100
Received: (from ralf@localhost)
	by fluff.linux-mips.net (8.12.8/8.12.8/Submit) id i097ep7u002598;
	Fri, 9 Jan 2004 08:40:51 +0100
Date: Fri, 9 Jan 2004 08:40:51 +0100
From: Ralf Baechle <ralf@linux-mips.org>
To: Yoichi Yuasa <yuasa@hh.iij4u.or.jp>
Cc: linux-mips@linux-mips.org
Subject: Re: [PATCH][2.6] add smp.h in processor.h
Message-ID: <20040109074051.GA2558@linux-mips.org>
References: <20040107125509.34cfa9db.yuasa@hh.iij4u.or.jp> <20040107052829.GB29672@linux-mips.org> <20040107154216.77967c1e.yuasa@hh.iij4u.or.jp>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20040107154216.77967c1e.yuasa@hh.iij4u.or.jp>
User-Agent: Mutt/1.4i
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: 3885
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
Content-Length: 432
Lines: 13

On Wed, Jan 07, 2004 at 03:42:16PM +0900, Yoichi Yuasa wrote:

> > <linux/smp.h> pulls in a fairly large number of other header files which
> > is why no Linux architecture includes <linux/smp.h> in <asm/processor.h>.
> > So instead please include the file directly into your code.  In which .c
> > file you're hitting the problem?
> 
> OK, I made a patch for same problem about vr41xx.
> Please apply this patch.

Applied,

  Ralf

From anemo@mba.ocn.ne.jp Fri Jan  9 08:42:46 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 09 Jan 2004 08:42:47 +0000 (GMT)
Received: from topsns.toshiba-tops.co.jp ([IPv6:::ffff:202.230.225.5]:37925
	"HELO topsns.toshiba-tops.co.jp") by linux-mips.org with SMTP
	id <S8225242AbUAIImq>; Fri, 9 Jan 2004 08:42:46 +0000
Received: from no.name.available by topsns.toshiba-tops.co.jp
          via smtpd (for mail.linux-mips.org [62.254.210.162]) with SMTP; 9 Jan 2004 08:43:31 UT
Received: from localhost (fragile [172.17.28.65])
	by srd2sd.toshiba-tops.co.jp (8.12.10/8.12.10) with ESMTP id i098hM1x029985;
	Fri, 9 Jan 2004 17:43:23 +0900 (JST)
	(envelope-from anemo@mba.ocn.ne.jp)
Date: Fri, 09 Jan 2004 17:43:53 +0900 (JST)
Message-Id: <20040109.174353.26978826.nemoto@toshiba-tops.co.jp>
To: linux-mips@linux-mips.org, ralf@linux-mips.org
Subject: CONFIG_MAGIC_SYSRQ and CONFIG_DUMMY_KEYB
From: Atsushi Nemoto <anemo@mba.ocn.ne.jp>
X-Fingerprint: 6ACA 1623 39BD 9A94 9B1A  B746 CA77 FE94 2874 D52F
X-Pgp-Public-Key: http://wwwkeys.pgp.net/pks/lookup?op=get&search=0x2874D52F
X-Mailer: Mew version 2.2 on Emacs 21.2 / Mule 5.0 (SAKAKI)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Return-Path: <anemo@mba.ocn.ne.jp>
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: 3886
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: anemo@mba.ocn.ne.jp
Precedence: bulk
X-list: linux-mips
Content-Length: 600
Lines: 19

The 2.4 kernel could not be built with both CONFIG_MAGIC_SYSRQ and
CONFIG_DUMMY_KEYB enabled.  This configuration should be possible
since we can use Magic SysRq with serial driver.

Here is a patch.

diff -u linux-mips/drivers/char/dummy_keyb.c linux/drivers/char/dummy_keyb.c
--- linux-mips/drivers/char/dummy_keyb.c	Thu Jun 12 10:14:55 2003
+++ linux/drivers/char/dummy_keyb.c	Fri Jan  9 17:28:37 2004
@@ -140,3 +140,7 @@
 {
 	printk("Dummy keyboard driver installed.\n");
 }
+#ifdef CONFIG_MAGIC_SYSRQ
+unsigned char kbd_sysrq_key;
+unsigned char kbd_sysrq_xlate[128];
+#endif
---
Atsushi Nemoto

From yuasa@hh.iij4u.or.jp Fri Jan  9 08:51:01 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 09 Jan 2004 08:51:04 +0000 (GMT)
Received: from mo02.iij4u.or.jp ([IPv6:::ffff:210.130.0.19]:24567 "EHLO
	mo02.iij4u.or.jp") by linux-mips.org with ESMTP id <S8225242AbUAIIvB>;
	Fri, 9 Jan 2004 08:51:01 +0000
Received: from mdo00.iij4u.or.jp (mdo00.iij4u.or.jp [210.130.0.170])
	by mo02.iij4u.or.jp (8.8.8/MFO1.5) with ESMTP id RAA21557;
	Fri, 9 Jan 2004 17:50:58 +0900 (JST)
Received: 4UMDO00 id i098owJ03213; Fri, 9 Jan 2004 17:50:58 +0900 (JST)
Received: 4UMRO00 id i098ovN08185; Fri, 9 Jan 2004 17:50:57 +0900 (JST)
	from rally.montavista.co.jp (sonicwall.montavista.co.jp [202.232.97.131]) (authenticated)
Date: Fri, 9 Jan 2004 17:50:57 +0900
From: Yoichi Yuasa <yuasa@hh.iij4u.or.jp>
To: Ralf Baechle <ralf@linux-mips.org>
Cc: yuasa@hh.iij4u.or.jp, linux-mips@linux-mips.org
Subject: Re: [PATCH][2.4] cache workaround for VR4131
Message-Id: <20040109175057.5774b2b7.yuasa@hh.iij4u.or.jp>
In-Reply-To: <20040109070615.GA1576@linux-mips.org>
References: <20040109022554.49768c94.yuasa@hh.iij4u.or.jp>
	<20040109070615.GA1576@linux-mips.org>
X-Mailer: Sylpheed version 0.9.8a (GTK+ 1.2.10; i686-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Return-Path: <yuasa@hh.iij4u.or.jp>
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: 3887
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: yuasa@hh.iij4u.or.jp
Precedence: bulk
X-list: linux-mips
Content-Length: 522
Lines: 19

On Fri, 9 Jan 2004 08:06:15 +0100
Ralf Baechle <ralf@linux-mips.org> wrote:

> On Fri, Jan 09, 2004 at 02:25:54AM +0900, Yoichi Yuasa wrote:
> 
> > I made a patch for cache workaround of VR4131.
> > This patch moves cache workaround to common part from board dependence part.
> > 
> > Please apply this patch.
> 
> Applied - but please keep arch/mips/mm/c-r4k.c and arch/mips64/mm/c-r4k.c
> in sync; the same applies to many other files that are identical in both
> mips and mips64.

Oops, I'm sorry.

and Thanks,

Yoichi

From ralf@linux-mips.org Fri Jan  9 08:53:36 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 09 Jan 2004 08:53:37 +0000 (GMT)
Received: from p508B6890.dip.t-dialin.net ([IPv6:::ffff:80.139.104.144]:63119
	"EHLO mail.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225266AbUAIIxg>; Fri, 9 Jan 2004 08:53:36 +0000
Received: from fluff.linux-mips.net (fluff.linux-mips.net [127.0.0.1])
	by mail.linux-mips.net (8.12.8/8.12.8) with ESMTP id i098rYfY017081;
	Fri, 9 Jan 2004 09:53:34 +0100
Received: (from ralf@localhost)
	by fluff.linux-mips.net (8.12.8/8.12.8/Submit) id i098rYaT017080;
	Fri, 9 Jan 2004 09:53:34 +0100
Date: Fri, 9 Jan 2004 09:53:34 +0100
From: Ralf Baechle <ralf@linux-mips.org>
To: Atsushi Nemoto <anemo@mba.ocn.ne.jp>
Cc: linux-mips@linux-mips.org
Subject: Re: CONFIG_MAGIC_SYSRQ and CONFIG_DUMMY_KEYB
Message-ID: <20040109085334.GA16940@linux-mips.org>
References: <20040109.174353.26978826.nemoto@toshiba-tops.co.jp>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20040109.174353.26978826.nemoto@toshiba-tops.co.jp>
User-Agent: Mutt/1.4i
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: 3888
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
Content-Length: 301
Lines: 11

On Fri, Jan 09, 2004 at 05:43:53PM +0900, Atsushi Nemoto wrote:

> The 2.4 kernel could not be built with both CONFIG_MAGIC_SYSRQ and
> CONFIG_DUMMY_KEYB enabled.  This configuration should be possible
> since we can use Magic SysRq with serial driver.
> 
> Here is a patch.

Thanks, applied.

  Ralf

From ralf@linux-mips.org Fri Jan  9 08:58:18 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 09 Jan 2004 08:58:19 +0000 (GMT)
Received: from p508B6890.dip.t-dialin.net ([IPv6:::ffff:80.139.104.144]:3984
	"EHLO mail.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225266AbUAII6S>; Fri, 9 Jan 2004 08:58:18 +0000
Received: from fluff.linux-mips.net (fluff.linux-mips.net [127.0.0.1])
	by mail.linux-mips.net (8.12.8/8.12.8) with ESMTP id i098wDfY017184;
	Fri, 9 Jan 2004 09:58:13 +0100
Received: (from ralf@localhost)
	by fluff.linux-mips.net (8.12.8/8.12.8/Submit) id i098w9e1017180;
	Fri, 9 Jan 2004 09:58:09 +0100
Date: Fri, 9 Jan 2004 09:58:09 +0100
From: Ralf Baechle <ralf@linux-mips.org>
To: Yoichi Yuasa <yuasa@hh.iij4u.or.jp>
Cc: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>, ppopov@mvista.com,
	linux-mips@linux-mips.org
Subject: Re: defconfigs
Message-ID: <20040109085809.GB16940@linux-mips.org>
References: <1072069822.1927.9.camel@localhost.localdomain> <Pine.LNX.4.55.0312221420510.27237@jurand.ds.pg.gda.pl> <20031222233316.48e4c0b5.yuasa@hh.iij4u.or.jp>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20031222233316.48e4c0b5.yuasa@hh.iij4u.or.jp>
User-Agent: Mutt/1.4i
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: 3889
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
Content-Length: 597
Lines: 15

On Mon, Dec 22, 2003 at 11:33:16PM +0900, Yoichi Yuasa wrote:

> > > How about if I create an arch/mips/configs directory and move all
> > > defconfig files there?  I know we've talked about this in the past and I
> > > don't remember any good reasons for not doing it?
> > 
> >  Except the plain "defconfig" file wants to keep sitting in arch/mips to
> > be picked up by configuration scripts.
> 
> I think it's means like arch/ppc/configs.

Well, I moved all the files to arch/mips/defconfigs/.  Guess I should
shorten the names now that they're in a subdir, a patch for another day :-)

  Ralf

From ralf@linux-mips.org Fri Jan  9 09:07:28 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 09 Jan 2004 09:07:29 +0000 (GMT)
Received: from p508B6890.dip.t-dialin.net ([IPv6:::ffff:80.139.104.144]:11408
	"EHLO mail.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225266AbUAIJH2>; Fri, 9 Jan 2004 09:07:28 +0000
Received: from fluff.linux-mips.net (fluff.linux-mips.net [127.0.0.1])
	by mail.linux-mips.net (8.12.8/8.12.8) with ESMTP id i0997OfY017369;
	Fri, 9 Jan 2004 10:07:24 +0100
Received: (from ralf@localhost)
	by fluff.linux-mips.net (8.12.8/8.12.8/Submit) id i0997Lon017368;
	Fri, 9 Jan 2004 10:07:21 +0100
Date: Fri, 9 Jan 2004 10:07:21 +0100
From: Ralf Baechle <ralf@linux-mips.org>
To: Charlie Brady <charlieb-linux-mips@e-smith.com>
Cc: Dimitri Torfs <dimitri@sonycom.com>, linux-mips@linux-mips.org
Subject: Re: [PATCH][2.6] Fix Makefiles for CONFIG_EMBEDDED_RAMDISK
Message-ID: <20040109090721.GC16940@linux-mips.org>
References: <20040106205758.GA19525@sonycom.com> <Pine.LNX.4.44.0401071543430.1954-100000@allspice.nssg.mitel.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Pine.LNX.4.44.0401071543430.1954-100000@allspice.nssg.mitel.com>
User-Agent: Mutt/1.4i
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: 3890
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
Content-Length: 468
Lines: 12

On Wed, Jan 07, 2004 at 03:44:32PM -0500, Charlie Brady wrote:

> >   here are patches that fix the arch/mips/Makefile and
> >   arch/mips/ramdisk/Makefile when an embedded ramdisk image needs to
> >   be included through the CONFIG_EMBEDDED_RAMDISK option.
> 
> I'm curious as to why this is a mips specific feature. Does anyone know?

There's little machine dependence as you noticed; just the linker script
would need to be fixed as it's hardwired to mips.

  Ralf

From hch@lst.de Fri Jan  9 15:01:25 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 09 Jan 2004 15:01:25 +0000 (GMT)
Received: from verein.lst.de ([IPv6:::ffff:212.34.189.10]:58011 "EHLO
	mail.lst.de") by linux-mips.org with ESMTP id <S8224863AbUAIPBZ>;
	Fri, 9 Jan 2004 15:01:25 +0000
Received: from verein.lst.de (localhost [127.0.0.1])
	by mail.lst.de (8.12.3/8.12.3/Debian-6.6) with ESMTP id i09F1Hst021565
	(version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO);
	Fri, 9 Jan 2004 16:01:17 +0100
Received: (from hch@localhost)
	by verein.lst.de (8.12.3/8.12.3/Debian-6.6) id i09F1Brv021563;
	Fri, 9 Jan 2004 16:01:11 +0100
Date: Fri, 9 Jan 2004 16:01:11 +0100
From: Christoph Hellwig <hch@lst.de>
To: Ralf Baechle <ralf@linux-mips.org>
Cc: Yoichi Yuasa <yuasa@hh.iij4u.or.jp>,
	"Maciej W. Rozycki" <macro@ds2.pg.gda.pl>, ppopov@mvista.com,
	linux-mips@linux-mips.org
Subject: Re: defconfigs
Message-ID: <20040109150111.GA21531@lst.de>
References: <1072069822.1927.9.camel@localhost.localdomain> <Pine.LNX.4.55.0312221420510.27237@jurand.ds.pg.gda.pl> <20031222233316.48e4c0b5.yuasa@hh.iij4u.or.jp> <20040109085809.GB16940@linux-mips.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20040109085809.GB16940@linux-mips.org>
User-Agent: Mutt/1.3.28i
X-Spam-Score: -5 () EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_MUTT
X-Scanned-By: MIMEDefang 2.33 (www . roaringpenguin . com / mimedefang)
Return-Path: <hch@lst.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: 3891
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@lst.de
Precedence: bulk
X-list: linux-mips
Content-Length: 381
Lines: 9

On Fri, Jan 09, 2004 at 09:58:09AM +0100, Ralf Baechle wrote:
> > I think it's means like arch/ppc/configs.
> 
> Well, I moved all the files to arch/mips/defconfigs/.  Guess I should
> shorten the names now that they're in a subdir, a patch for another day :-)

Well, the arch/$FOO/configs/ name gets picked up automatically by
make oldconfig, so I think it's the better choice..


From dimitri@sonycom.com Fri Jan  9 22:01:57 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 09 Jan 2004 22:01:58 +0000 (GMT)
Received: from witte.sonytel.be ([IPv6:::ffff:80.88.33.193]:51102 "EHLO
	witte.sonytel.be") by linux-mips.org with ESMTP id <S8225269AbUAIWB5>;
	Fri, 9 Jan 2004 22:01:57 +0000
Received: from teasel.sonytel.be (localhost [127.0.0.1])
	by witte.sonytel.be (8.12.10/8.12.10) with ESMTP id i09M1mQF014512;
	Fri, 9 Jan 2004 23:01:48 +0100 (MET)
Received: (from dimitri@localhost)
	by teasel.sonytel.be (8.9.3+Sun/8.9.3) id XAA03360;
	Fri, 9 Jan 2004 23:01:49 +0100 (MET)
Date: Fri, 9 Jan 2004 23:01:48 +0100
From: Dimitri Torfs <dimitri@sonycom.com>
To: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
Cc: linux-mips@linux-mips.org
Subject: Re: Support for newer gcc/gas options
Message-ID: <20040109220148.GA3314@sonycom.com>
References: <20031223114644.GA5458@sonycom.com> <Pine.LNX.4.55.0312231303030.27594@jurand.ds.pg.gda.pl>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Pine.LNX.4.55.0312231303030.27594@jurand.ds.pg.gda.pl>
User-Agent: Mutt/1.4.1i
Return-Path: <dimitri@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: 3892
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: dimitri@sonycom.com
Precedence: bulk
X-list: linux-mips
Content-Length: 1485
Lines: 42

On Tue, Dec 23, 2003 at 01:05:29PM +0100, Maciej W. Rozycki wrote:
> On Tue, 23 Dec 2003, Dimitri Torfs wrote:
> 
> >   I just upgraded to the arch/mips/Makefile which adds support for newer
> >   gcc/gas options. I now get the warning
> > 
> >   "cc1: warning: The -march option is incompatible to -mipsN and therefore
> > +ignored."
> > 
> >   when compiling. I have the CONFIG_CPU_VR41XX option set, which sets
> >   the c-flags to:
> > 
> >   "-I /home/dimitri/work/linux/include/asm/gcc -G 0 -mno-abicalls
> >   -fno-pic -pipe  -finline-limit=100000 -mabi=32 -march=r4100 -mips3
> >   -Wa,-32 -Wa,-march=r4100 -Wa,-mips3 -Wa,--trap"
> > 
> >   I suppose that for the newer gcc versions only -march= should be
> >   set (I'm using gcc-3.2.2) ?
> 
>  Thanks for the report -- I suppose we can remove "-mips" whenever
> "-mabi=" is supported by gcc.  I'll do an update in January after I am 
> back from vacation.

Tried removing the -mips3 gcc option => -D_MIPS_ISA=_MIPS_ISA_MIPS1 is
set. I think it might be better to use "-mtune=<cpu> -mipsN". That
seems to set the correct options, without any warnings (using gcc
3.2.2). After having carefully read the gcc documentation (again)
regarding the MIPS options, I think that's the way to go for newer
gcc's as well. If anyone has already tried ?



Dimitri



-- 
Dimitri Torfs       |  NSCE 
dimitri@sonycom.com |  The Corporate Village
tel: +32 2 7008541  |  Da Vincilaan 7 - D1 
fax: +32 2 7008622  |  B-1935 Zaventem - Belgium


From jsun@mvista.com Fri Jan  9 23:39:01 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 09 Jan 2004 23:39:02 +0000 (GMT)
Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:9460 "EHLO
	orion.mvista.com") by linux-mips.org with ESMTP id <S8225269AbUAIXjB>;
	Fri, 9 Jan 2004 23:39:01 +0000
Received: (from jsun@localhost)
	by orion.mvista.com (8.11.6/8.11.6) id i09Ncv522283;
	Fri, 9 Jan 2004 15:38:57 -0800
Date: Fri, 9 Jan 2004 15:38:57 -0800
From: Jun Sun <jsun@mvista.com>
To: linux-mips@linux-mips.org
Cc: jsun@mvista.com
Subject: [PATCH] only setup kseg0 coherency after flush_cache_all ...
Message-ID: <20040109153857.I24193@mvista.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="7iMSBzlTiPOCCT2k"
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
Return-Path: <jsun@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: 3893
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
Content-Length: 872
Lines: 40


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


The change is needed to make CONFIG_MIPS_UNCACHED work.
Otherwise you end up with accessing stale data right after
switching off cache.

If no objections, I will check it in later.

Jun


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

diff -Nru arch/mips/mm/c-r4k.c.orig arch/mips/mm/c-r4k.c
--- arch/mips/mm/c-r4k.c.orig	Mon Jan  5 10:33:35 2004
+++ arch/mips/mm/c-r4k.c	Fri Jan  9 15:32:18 2004
@@ -1031,7 +1031,6 @@
 
 	probe_pcache();
 	setup_scache();
-	coherency_setup();
 
 	if (c->dcache.sets * c->dcache.ways > PAGE_SIZE)
 		c->dcache.flags |= MIPS_CACHE_ALIASES;
@@ -1073,6 +1072,7 @@
 #endif
 
 	__flush_cache_all();
+	coherency_setup();
 
 	build_clear_page();
 	build_copy_page();

--7iMSBzlTiPOCCT2k--

From ica2_ts@csv.ica.uni-stuttgart.de Sat Jan 10 01:19:45 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 10 Jan 2004 01:19:47 +0000 (GMT)
Received: from iris1.csv.ica.uni-stuttgart.de ([IPv6:::ffff:129.69.118.2]:6747
	"EHLO iris1.csv.ica.uni-stuttgart.de") by linux-mips.org with ESMTP
	id <S8225276AbUAJBTp>; Sat, 10 Jan 2004 01:19:45 +0000
Received: from rembrandt.csv.ica.uni-stuttgart.de ([129.69.118.42])
	by iris1.csv.ica.uni-stuttgart.de with esmtp
	id 1Af7md-0008KS-00; Sat, 10 Jan 2004 02:19:23 +0100
Received: from ica2_ts by rembrandt.csv.ica.uni-stuttgart.de with local (Exim 3.35 #1 (Debian))
	id 1Af7mc-0006LS-00; Sat, 10 Jan 2004 02:19:22 +0100
Date: Sat, 10 Jan 2004 02:19:22 +0100
To: Dimitri Torfs <dimitri@sonycom.com>
Cc: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>,
	linux-mips@linux-mips.org
Subject: Re: Support for newer gcc/gas options
Message-ID: <20040110011922.GA14930@rembrandt.csv.ica.uni-stuttgart.de>
References: <20031223114644.GA5458@sonycom.com> <Pine.LNX.4.55.0312231303030.27594@jurand.ds.pg.gda.pl> <20040109220148.GA3314@sonycom.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20040109220148.GA3314@sonycom.com>
User-Agent: Mutt/1.5.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: 3894
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
Content-Length: 835
Lines: 20

Dimitri Torfs wrote:
[snip]
> >  Thanks for the report -- I suppose we can remove "-mips" whenever
> > "-mabi=" is supported by gcc.  I'll do an update in January after I am 
> > back from vacation.
> 
> Tried removing the -mips3 gcc option => -D_MIPS_ISA=_MIPS_ISA_MIPS1 is
> set. I think it might be better to use "-mtune=<cpu> -mipsN". That
> seems to set the correct options, without any warnings (using gcc
> 3.2.2). After having carefully read the gcc documentation (again)
> regarding the MIPS options, I think that's the way to go for newer
> gcc's as well. If anyone has already tried ?

The supposed way is to use -mabi=FOO -march=BAR, where BAR can also be
e.g. "mips3". This will choose the proper (probably generic) architecture
as well as the ISA defines. Btw, the ISA defines aren't used in the
kernel anymore.


Thiemo

From a.nielsen@optushome.com.au Sat Jan 10 05:05:58 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 10 Jan 2004 05:05:59 +0000 (GMT)
Received: from mail007.syd.optusnet.com.au ([IPv6:::ffff:211.29.132.55]:23528
	"EHLO mail007.syd.optusnet.com.au") by linux-mips.org with ESMTP
	id <S8224945AbUAJFF6>; Sat, 10 Jan 2004 05:05:58 +0000
Received: from korath.adamsrealm.net.au (c210-49-87-133.rochd3.qld.optusnet.com.au [210.49.87.133])
	by mail007.syd.optusnet.com.au (8.11.6p2/8.11.6) with ESMTP id i0A55rH14308
	for <linux-mips@linux-mips.org>; Sat, 10 Jan 2004 16:05:53 +1100
From: Adam Nielsen <a.nielsen@optushome.com.au>
To: linux-mips@linux-mips.org
Subject: Running Linux on an NCD HMX X-Terminal
Date: Sat, 10 Jan 2004 15:05:04 +1000
User-Agent: KMail/1.5
MIME-Version: 1.0
Content-Type: text/plain;
  charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200401101505.04453@korath>
Return-Path: <a.nielsen@optushome.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: 3895
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: a.nielsen@optushome.com.au
Precedence: bulk
X-list: linux-mips
Content-Length: 1722
Lines: 41

Hi,

I've got a few old NCD HMX X-Terminals and I'd like to see if I could get 
Linux running on them.  The reason I ask is that the units boot an ELF image 
over the network, and when running readelf on the image it appears than the 
terminals have an R3000 processor:

$ readelf -h Xncdhmx 
ELF Header:
  Magic:   7f 45 4c 46 01 02 01 00 00 00 00 00 00 00 00 00 
  Class:                             ELF32
  Data:                              2's complement, big endian
  Version:                           1 (current)
  OS/ABI:                            UNIX - System V
  ABI Version:                       0
  Type:                              EXEC (Executable file)
  Machine:                           MIPS R3000
  Version:                           0x1
  Entry point address:               0x40020000
  Start of program headers:          52 (bytes into file)
  Start of section headers:          2625644 (bytes into file)
  Flags:                             0x0
  Size of this header:               52 (bytes)
  Size of program headers:           32 (bytes)
  Number of program headers:         1
  Size of section headers:           40 (bytes)
  Number of section headers:         7
  Section header string table index: 6

Does anyone know what my chances would be of getting a Linux kernel on it?  I 
found a couple of precompiled MIPS kernel images (one was ELF32 but the other 
was ELF64), however when I tried to boot them the terminal simply said "Load 
address out of range" and aborted.  I was using the precompiled images 
because I really want to know whether it'll work before I go to the trouble 
of installing all the cross-compilation tools.

Any info would be greatly appreciated!

Thanks,
Adam.


From dimitri@sonycom.com Sat Jan 10 08:03:14 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 10 Jan 2004 08:03:15 +0000 (GMT)
Received: from witte.sonytel.be ([IPv6:::ffff:80.88.33.193]:50059 "EHLO
	witte.sonytel.be") by linux-mips.org with ESMTP id <S8225200AbUAJIDO>;
	Sat, 10 Jan 2004 08:03:14 +0000
Received: from zebra.sonytel.be (localhost [127.0.0.1])
	by witte.sonytel.be (8.12.10/8.12.10) with ESMTP id i0A83AQF014892;
	Sat, 10 Jan 2004 09:03:10 +0100 (MET)
Received: from dimitri by zebra.sonytel.be with local (Exim 3.35 #1 )
	id 1AfE5Q-0007ZW-00; Sat, 10 Jan 2004 09:03:12 +0100
Date: Sat, 10 Jan 2004 09:03:12 +0100
From: Dimitri Torfs <dimitri@sonycom.com>
To: Thiemo Seufer <ica2_ts@csv.ica.uni-stuttgart.de>
Cc: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>,
	linux-mips@linux-mips.org
Subject: Re: Support for newer gcc/gas options
Message-ID: <20040110080312.GA28970@sonycom.com>
References: <20031223114644.GA5458@sonycom.com> <Pine.LNX.4.55.0312231303030.27594@jurand.ds.pg.gda.pl> <20040109220148.GA3314@sonycom.com> <20040110011922.GA14930@rembrandt.csv.ica.uni-stuttgart.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20040110011922.GA14930@rembrandt.csv.ica.uni-stuttgart.de>
User-Agent: Mutt/1.3.28i
Return-Path: <dimitri@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: 3896
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: dimitri@sonycom.com
Precedence: bulk
X-list: linux-mips
Content-Length: 766
Lines: 28

On Sat, Jan 10, 2004 at 02:19:22AM +0100, Thiemo Seufer wrote:
> [snip]
> The supposed way is to use -mabi=FOO -march=BAR, where BAR can also be
> e.g. "mips3". 

The -march=mipsN is from gcc-3.3 and higher, right ? 

> This will choose the proper (probably generic) architecture
> as well as the ISA defines. 

I expected, when using -march=r4100, that MIPS3 would be used. That was
apparently not the case (is this maybe a bug in gcc-3.2.2 ?).

> Btw, the ISA defines aren't used in the
> kernel anymore.

Well, asm-mips/asm.h still contains some #ifdef's based on the
_MIPS_ISA. 


Dimitri

-- 
Dimitri Torfs       |  NSCE 
dimitri@sonycom.com |  The Corporate Village
tel: +32 2 7008541  |  Da Vincilaan 7 - D1 
fax: +32 2 7008622  |  B-1935 Zaventem - Belgium


From brad@heeltoe.com Sat Jan 10 12:40:33 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 10 Jan 2004 12:40:34 +0000 (GMT)
Received: from gateway.heeltoe.com ([IPv6:::ffff:66.134.219.32]:8251 "HELO
	gateway.heeltoe.com") by linux-mips.org with SMTP
	id <S8225235AbUAJMkd>; Sat, 10 Jan 2004 12:40:33 +0000
Received: (qmail 17053 invoked from network); 10 Jan 2004 12:40:26 -0000
Received: from mwave.heeltoe.com (192.245.4.20)
  by clunker.heeltoe.com with SMTP; 10 Jan 2004 12:40:26 -0000
Received: from mwave (brad@localhost)
	by mwave.heeltoe.com (8.11.6/8.11.6) with ESMTP id i0ACePX01584;
	Sat, 10 Jan 2004 07:40:25 -0500
Message-Id: <200401101240.i0ACePX01584@mwave.heeltoe.com>
X-Mailer: exmh version 2.4 06/23/2000 with nmh-1.0.4
To: Adam Nielsen <a.nielsen@optushome.com.au>
cc: linux-mips@linux-mips.org
Subject: Re: Running Linux on an NCD HMX X-Terminal 
In-Reply-To: Message from Adam Nielsen <a.nielsen@optushome.com.au> 
   of "Sat, 10 Jan 2004 15:05:04 +1000." <200401101505.04453@korath> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Sat, 10 Jan 2004 07:40:25 -0500
From: Brad Parker <brad@heeltoe.com>
Return-Path: <brad@heeltoe.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: 3897
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@heeltoe.com
Precedence: bulk
X-list: linux-mips
Content-Length: 871
Lines: 24


Adam Nielsen wrote:
...
>Does anyone know what my chances would be of getting a Linux kernel on it?  I 
>found a couple of precompiled MIPS kernel images (one was ELF32 but the other 
>was ELF64), however when I tried to boot them the terminal simply said "Load 
>address out of range" and aborted.  I was using the precompiled images 
>because I really want to know whether it'll work before I go to the trouble 
>of installing all the cross-compilation tools.

I brought up linux on the PPC403 version of an NCD x-terminal.  As I recall I
had to write program to hack the elf header to get kernels to load.

The project is at http://sourceforge.net/projects/explora-linux/

And the program to hack the kernel elf file is 

http://cvs.sourceforge.net/viewcvs.py/explora-linux/ncdhack/ncdhack.c

You may get lucky and find they used the same format for MIPS...

-brad



From a.nielsen@optushome.com.au Sun Jan 11 02:05:21 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 11 Jan 2004 02:05:22 +0000 (GMT)
Received: from mail006.syd.optusnet.com.au ([IPv6:::ffff:211.29.132.63]:12690
	"EHLO mail006.syd.optusnet.com.au") by linux-mips.org with ESMTP
	id <S8224936AbUAKCFV>; Sun, 11 Jan 2004 02:05:21 +0000
Received: from korath.adamsrealm.net.au (c210-49-87-133.rochd3.qld.optusnet.com.au [210.49.87.133])
	by mail006.syd.optusnet.com.au (8.11.6p2/8.11.6) with ESMTP id i0B25F620960
	for <linux-mips@linux-mips.org>; Sun, 11 Jan 2004 13:05:16 +1100
From: Adam Nielsen <a.nielsen@optushome.com.au>
To: linux-mips@linux-mips.org
Subject: Re: Running Linux on an NCD HMX X-Terminal
Date: Sun, 11 Jan 2004 12:04:23 +1000
User-Agent: KMail/1.5
References: <200401101240.i0ACePX01584@mwave.heeltoe.com>
In-Reply-To: <200401101240.i0ACePX01584@mwave.heeltoe.com>
MIME-Version: 1.0
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200401111204.23752@korath>
Return-Path: <a.nielsen@optushome.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: 3898
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: a.nielsen@optushome.com.au
Precedence: bulk
X-list: linux-mips
Content-Length: 1239
Lines: 27

> I brought up linux on the PPC403 version of an NCD x-terminal.  As I recall
> I had to write program to hack the elf header to get kernels to load.
> The project is at http://sourceforge.net/projects/explora-linux/

Hmm...this looks interesting!

> You may get lucky and find they used the same format for MIPS...

Well I am hopeful, given that they use the same manual for the HMX and the 
Explora, but running ncdhack on the kernel didn't seem to have any effect :-(

I did try some fiddling with the ELF files, just to see what would happen (but 
not having any experience with this, I was just guessing ;-))  The load 
address for the proper boot image is 0x40020000 but the kernel is 0x88002000 
which I think is partly why it doesn't work.  If I shrink the ELF file a 
little by removing a couple of the sections (by telling objcopy to ignore 
them) *and* I change the load address to 0x40020000 then the xterm actually 
downloads the image but then gives a "File corrupted CRC error" just as it 
goes to boot it.

I'm not sure why that happens, because manipulating the file properly with 
objcopy should adjust any CRC checksums accordingly.  I wonder whether the 
xterm is checking that the image is 'official'?

Cheers,
Adam.


From karthik_96cse@yahoo.com Sun Jan 11 12:48:33 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 11 Jan 2004 12:48:34 +0000 (GMT)
Received: from web10103.mail.yahoo.com ([IPv6:::ffff:216.136.130.53]:65451
	"HELO web10103.mail.yahoo.com") by linux-mips.org with SMTP
	id <S8224988AbUAKMsd>; Sun, 11 Jan 2004 12:48:33 +0000
Message-ID: <20040111124828.71884.qmail@web10103.mail.yahoo.com>
Received: from [128.107.253.43] by web10103.mail.yahoo.com via HTTP; Sun, 11 Jan 2004 12:48:28 GMT
Date: Sun, 11 Jan 2004 12:48:28 +0000 (GMT)
From: =?iso-8859-1?q?karthikeyan=20natarajan?= <karthik_96cse@yahoo.com>
Subject: How to configure the cache size in r4000
To: linux-mips@linux-mips.org
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Return-Path: <karthik_96cse@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: 3899
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: karthik_96cse@yahoo.com
Precedence: bulk
X-list: linux-mips
Content-Length: 1105
Lines: 29

Hi All,

    The cache size is modified by setting the IC/DC
bits in the 'config' register. Seems they are set only
by the hardware during the processor reset. And also,
those bits are mentioned as read only bits..
   Could you please let me know how can we instruct 
the hardware to do so. Can we do this via s/w?.

Thanks,
-karthi

=====
The expert at anything was once a beginner
                  ______________________________
                 /                              \
             O  /      Karthikeyan.N             \
           O   |       Chennai, India.            |
    `\|||/'     \    Mobile: +919884104346       /
     (o o)       \                              /
_ ooO (_) Ooo____________________________________
_____|_____|_____|_____|_____|_____|_____|_____|_
__|_____|_____|_____|_____|_____|_____|_____|____
_____|_____|_____|_____|_____|_____|_____|_____|_

________________________________________________________________________
Yahoo! Messenger - Communicate instantly..."Ping" 
your friends today! Download Messenger Now 
http://uk.messenger.yahoo.com/download/index.html

From yuasa@hh.iij4u.or.jp Sun Jan 11 14:13:19 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 11 Jan 2004 14:13:23 +0000 (GMT)
Received: from mo03.iij4u.or.jp ([IPv6:::ffff:210.130.0.20]:20200 "EHLO
	mo03.iij4u.or.jp") by linux-mips.org with ESMTP id <S8225234AbUAKONT>;
	Sun, 11 Jan 2004 14:13:19 +0000
Received: from mdo01.iij4u.or.jp (mdo01.iij4u.or.jp [210.130.0.171])
	by mo03.iij4u.or.jp (8.8.8/MFO1.5) with ESMTP id XAA01350;
	Sun, 11 Jan 2004 23:13:15 +0900 (JST)
Received: 4UMDO01 id i0BEDFb01086; Sun, 11 Jan 2004 23:13:15 +0900 (JST)
Received: 4UMRO00 id i0BEDEC19163; Sun, 11 Jan 2004 23:13:14 +0900 (JST)
	from stratos.frog (64.43.138.210.xn.2iij.net [210.138.43.64]) (authenticated)
Date: Sun, 11 Jan 2004 23:13:10 +0900
From: Yoichi Yuasa <yuasa@hh.iij4u.or.jp>
To: Ralf Baechle <ralf@linux-mips.org>
Cc: yuasa@hh.iij4u.or.jp, linux-mips <linux-mips@linux-mips.org>
Subject: [PATCH][2.4] change registers name for vr41xx
Message-Id: <20040111231310.38a679fc.yuasa@hh.iij4u.or.jp>
X-Mailer: Sylpheed version 0.9.8a (GTK+ 1.2.10; i686-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Return-Path: <yuasa@hh.iij4u.or.jp>
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: 3900
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: yuasa@hh.iij4u.or.jp
Precedence: bulk
X-list: linux-mips
Content-Length: 8892
Lines: 271

Hello Ralf,

I made a patch for vr41xx of 2.4.

Although the old register name is using CPU as the base,
it is not dependent on CPU in practice.
This patch corrects the name depending on the CPU name.

Please apply this patch.

Yoichi

diff -urN -X dontdiff linux-orig/arch/mips/vr41xx/common/bcu.c linux/arch/mips/vr41xx/common/bcu.c
--- linux-orig/arch/mips/vr41xx/common/bcu.c	Wed Dec  3 01:37:03 2003
+++ linux/arch/mips/vr41xx/common/bcu.c	Sun Jan 11 22:08:37 2004
@@ -45,8 +45,8 @@
 #include <asm/cpu.h>
 #include <asm/io.h>
 
-#define VR4111_CLKSPEEDREG	KSEG1ADDR(0x0b000014)
-#define VR4122_CLKSPEEDREG	KSEG1ADDR(0x0f000014)
+#define CLKSPEEDREG_TYPE1	KSEG1ADDR(0x0b000014)
+#define CLKSPEEDREG_TYPE2	KSEG1ADDR(0x0f000014)
  #define CLKSP(x)		((x) & 0x001f)
  #define CLKSP_VR4133(x)	((x) & 0x0007)
 
@@ -77,10 +77,10 @@
 {
 	switch (current_cpu_data.cputype) {
 	case CPU_VR4111:
-	case CPU_VR4121: return readw(VR4111_CLKSPEEDREG);
+	case CPU_VR4121: return readw(CLKSPEEDREG_TYPE1);
 	case CPU_VR4122:
 	case CPU_VR4131:
-	case CPU_VR4133: return readw(VR4122_CLKSPEEDREG);
+	case CPU_VR4133: return readw(CLKSPEEDREG_TYPE2);
 	default:
 		printk(KERN_INFO "Unexpected CPU of NEC VR4100 series\n");
 		break;
diff -urN -X dontdiff linux-orig/arch/mips/vr41xx/common/cmu.c linux/arch/mips/vr41xx/common/cmu.c
--- linux-orig/arch/mips/vr41xx/common/cmu.c	Fri Oct 31 11:28:40 2003
+++ linux/arch/mips/vr41xx/common/cmu.c	Sun Jan 11 22:08:37 2004
@@ -46,33 +46,33 @@
 #include <asm/io.h>
 #include <asm/vr41xx/vr41xx.h>
 
-#define VR4111_CMUCLKMSK	KSEG1ADDR(0x0b000060)
-#define VR4122_CMUCLKMSK	KSEG1ADDR(0x0f000060)
- #define MSKPIU			0x0001
- #define MSKSIU			0x0002
- #define MSKAIU			0x0004
- #define MSKKIU			0x0008
- #define MSKFIR			0x0010
- #define MSKDSIU		0x0820
- #define MSKCSI			0x0040
- #define MSKPCIU		0x0080
- #define MSKSSIU		0x0100
- #define MSKSHSP		0x0200
- #define MSKFFIR		0x0400
- #define MSKSCSI		0x1000
- #define MSKPPCIU		0x2000
-#define VR4133_CMUCLKMSK2	KSEG1ADDR(0x0f000064)
- #define MSKCEU			0x0001
- #define MSKMAC0		0x0002
- #define MSKMAC1		0x0004
+#define CMUCLKMSK_TYPE1	KSEG1ADDR(0x0b000060)
+#define CMUCLKMSK_TYPE2	KSEG1ADDR(0x0f000060)
+ #define MSKPIU		0x0001
+ #define MSKSIU		0x0002
+ #define MSKAIU		0x0004
+ #define MSKKIU		0x0008
+ #define MSKFIR		0x0010
+ #define MSKDSIU	0x0820
+ #define MSKCSI		0x0040
+ #define MSKPCIU	0x0080
+ #define MSKSSIU	0x0100
+ #define MSKSHSP	0x0200
+ #define MSKFFIR	0x0400
+ #define MSKSCSI	0x1000
+ #define MSKPPCIU	0x2000
+#define CMUCLKMSK2	KSEG1ADDR(0x0f000064)
+ #define MSKCEU		0x0001
+ #define MSKMAC0	0x0002
+ #define MSKMAC1	0x0004
 
 static u32 vr41xx_cmu_base;
 static u16 cmuclkmsk, cmuclkmsk2;
 
 #define read_cmuclkmsk()	readw(vr41xx_cmu_base)
-#define read_cmuclkmsk2()	readw(VR4133_CMUCLKMSK2)
+#define read_cmuclkmsk2()	readw(CMUCLKMSK2)
 #define write_cmuclkmsk()	writew(cmuclkmsk, vr41xx_cmu_base)
-#define write_cmuclkmsk2()	writew(cmuclkmsk2, VR4133_CMUCLKMSK2)
+#define write_cmuclkmsk2()	writew(cmuclkmsk2, CMUCLKMSK2)
 
 void vr41xx_clock_supply(unsigned int clock)
 {
@@ -205,14 +205,14 @@
 	switch (current_cpu_data.cputype) {
         case CPU_VR4111:
         case CPU_VR4121:
-                vr41xx_cmu_base = VR4111_CMUCLKMSK;
+                vr41xx_cmu_base = CMUCLKMSK_TYPE1;
                 break;
         case CPU_VR4122:
         case CPU_VR4131:
-                vr41xx_cmu_base = VR4122_CMUCLKMSK;
+                vr41xx_cmu_base = CMUCLKMSK_TYPE2;
                 break;
         case CPU_VR4133:
-                vr41xx_cmu_base = VR4122_CMUCLKMSK;
+                vr41xx_cmu_base = CMUCLKMSK_TYPE2;
 		cmuclkmsk2 = read_cmuclkmsk2();
                 break;
 	default:
diff -urN -X dontdiff linux-orig/arch/mips/vr41xx/common/giu.c linux/arch/mips/vr41xx/common/giu.c
--- linux-orig/arch/mips/vr41xx/common/giu.c	Thu Dec 18 00:58:12 2003
+++ linux/arch/mips/vr41xx/common/giu.c	Sun Jan 11 22:08:37 2004
@@ -48,8 +48,8 @@
 #include <asm/io.h>
 #include <asm/vr41xx/vr41xx.h>
 
-#define VR4111_GIUIOSELL	KSEG1ADDR(0x0b000100)
-#define VR4122_GIUIOSELL	KSEG1ADDR(0x0f000140)
+#define GIUIOSELL_TYPE1	KSEG1ADDR(0x0b000100)
+#define GIUIOSELL_TYPE2	KSEG1ADDR(0x0f000140)
 
 #define GIUIOSELL	0x00
 #define GIUIOSELH	0x02
@@ -280,12 +280,12 @@
 	switch (current_cpu_data.cputype) {
 	case CPU_VR4111:
 	case CPU_VR4121:
-		giu_base = VR4111_GIUIOSELL;
+		giu_base = GIUIOSELL_TYPE1;
 		break;
 	case CPU_VR4122:
 	case CPU_VR4131:
 	case CPU_VR4133:
-		giu_base = VR4122_GIUIOSELL;
+		giu_base = GIUIOSELL_TYPE2;
 		break;
 	default:
 		panic("GIU: Unexpected CPU of NEC VR4100 series");
diff -urN -X dontdiff linux-orig/arch/mips/vr41xx/common/icu.c linux/arch/mips/vr41xx/common/icu.c
--- linux-orig/arch/mips/vr41xx/common/icu.c	Thu Dec 18 00:58:12 2003
+++ linux/arch/mips/vr41xx/common/icu.c	Sun Jan 11 22:08:37 2004
@@ -67,11 +67,11 @@
 static unsigned char sysint2_assign[16] = {
 	2, 0, 3, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 };
 
-#define VR4111_SYSINT1REG	KSEG1ADDR(0x0b000080)
-#define VR4111_SYSINT2REG	KSEG1ADDR(0x0b000200)
+#define SYSINT1REG_TYPE1	KSEG1ADDR(0x0b000080)
+#define SYSINT2REG_TYPE1	KSEG1ADDR(0x0b000200)
 
-#define VR4122_SYSINT1REG	KSEG1ADDR(0x0f000080)
-#define VR4122_SYSINT2REG	KSEG1ADDR(0x0f0000a0)
+#define SYSINT1REG_TYPE2	KSEG1ADDR(0x0f000080)
+#define SYSINT2REG_TYPE2	KSEG1ADDR(0x0f0000a0)
 
 #define SYSINT1REG	0x00
 #define INTASSIGN0	0x04
@@ -292,14 +292,14 @@
 	switch (current_cpu_data.cputype) {
 	case CPU_VR4111:
 	case CPU_VR4121:
-		icu1_base = VR4111_SYSINT1REG;
-		icu2_base = VR4111_SYSINT2REG;
+		icu1_base = SYSINT1REG_TYPE1;
+		icu2_base = SYSINT2REG_TYPE1;
 		break;
 	case CPU_VR4122:
 	case CPU_VR4131:
 	case CPU_VR4133:
-		icu1_base = VR4122_SYSINT1REG;
-		icu2_base = VR4122_SYSINT2REG;
+		icu1_base = SYSINT1REG_TYPE2;
+		icu2_base = SYSINT2REG_TYPE2;
 		break;
 	default:
 		panic("Unexpected CPU of NEC VR4100 series");
diff -urN -X dontdiff linux-orig/arch/mips/vr41xx/common/rtc.c linux/arch/mips/vr41xx/common/rtc.c
--- linux-orig/arch/mips/vr41xx/common/rtc.c	Tue Dec  2 04:31:49 2003
+++ linux/arch/mips/vr41xx/common/rtc.c	Sun Jan 11 22:08:37 2004
@@ -40,11 +40,11 @@
 #define REMAINDER_PER_SEC	(CLOCK_TICK_RATE - (CYCLES_PER_JIFFY * HZ))
 #define CYCLES_PER_100USEC	((CLOCK_TICK_RATE + (10000 / 2)) / 10000)
 
-#define VR4111_ETIMELREG	KSEG1ADDR(0x0b0000c0)
-#define VR4111_TCLKLREG		KSEG1ADDR(0x0b0001c0)
+#define ETIMELREG_TYPE1		KSEG1ADDR(0x0b0000c0)
+#define TCLKLREG_TYPE1		KSEG1ADDR(0x0b0001c0)
 
-#define VR4122_ETIMELREG	KSEG1ADDR(0x0f000100)
-#define VR4122_TCLKLREG		KSEG1ADDR(0x0f000120)
+#define ETIMELREG_TYPE2		KSEG1ADDR(0x0f000100)
+#define TCLKLREG_TYPE2		KSEG1ADDR(0x0f000120)
 
 /* RTC 1 registers */
 #define ETIMELREG		0x00
@@ -265,14 +265,14 @@
 	switch (current_cpu_data.cputype) {
 	case CPU_VR4111:
 	case CPU_VR4121:
-		rtc1_base = VR4111_ETIMELREG;
-		rtc2_base = VR4111_TCLKLREG;
+		rtc1_base = ETIMELREG_TYPE1;
+		rtc2_base = TCLKLREG_TYPE1;
 		break;
 	case CPU_VR4122:
 	case CPU_VR4131:
 	case CPU_VR4133:
-		rtc1_base = VR4122_ETIMELREG;
-		rtc2_base = VR4122_TCLKLREG;
+		rtc1_base = ETIMELREG_TYPE2;
+		rtc2_base = TCLKLREG_TYPE2;
 		break;
 	default:
 		panic("Unexpected CPU of NEC VR4100 series");
diff -urN -X dontdiff linux-orig/arch/mips/vr41xx/common/serial.c linux/arch/mips/vr41xx/common/serial.c
--- linux-orig/arch/mips/vr41xx/common/serial.c	Fri Oct 31 11:28:41 2003
+++ linux/arch/mips/vr41xx/common/serial.c	Sun Jan 11 22:08:37 2004
@@ -49,12 +49,12 @@
 #include <asm/vr41xx/vr41xx.h>
 
 /* VR4111 and VR4121 SIU Registers */
-#define VR4111_SIURB		KSEG1ADDR(0x0c000000)
-#define VR4111_SIUIRSEL		KSEG1ADDR(0x0c000008)
+#define SIURB_TYPE1		KSEG1ADDR(0x0c000000)
+#define SIUIRSEL_TYPE1		KSEG1ADDR(0x0c000008)
 
-/* VR4122 and VR4131 SIU Registers */
-#define VR4122_SIURB		KSEG1ADDR(0x0f000800)
-#define VR4122_SIUIRSEL		KSEG1ADDR(0x0f000808)
+/* VR4122, VR4131 and VR4133 SIU Registers */
+#define SIURB_TYPE2		KSEG1ADDR(0x0f000800)
+#define SIUIRSEL_TYPE2		KSEG1ADDR(0x0f000808)
 
  #define USE_RS232C		0x00
  #define USE_IRDA		0x01
@@ -101,12 +101,12 @@
 	switch (current_cpu_data.cputype) {
 	case CPU_VR4111:
 	case CPU_VR4121:
-		writew(val, VR4111_SIUIRSEL);
+		writew(val, SIUIRSEL_TYPE1);
 		break;
 	case CPU_VR4122:
 	case CPU_VR4131:
 	case CPU_VR4133:
-		writew(val, VR4122_SIUIRSEL);
+		writew(val, SIUIRSEL_TYPE2);
 		break;
 	default:
 		printk(KERN_INFO "Unexpected CPU of NEC VR4100 series\n");
@@ -129,12 +129,12 @@
 	switch (current_cpu_data.cputype) {
 	case CPU_VR4111:
 	case CPU_VR4121:
-		s.iomem_base = (unsigned char *)VR4111_SIURB;
+		s.iomem_base = (unsigned char *)SIURB_TYPE1;
 		break;
 	case CPU_VR4122:
 	case CPU_VR4131:
 	case CPU_VR4133:
-		s.iomem_base = (unsigned char *)VR4122_SIURB;
+		s.iomem_base = (unsigned char *)SIURB_TYPE2;
 		break;
 	default:
 		panic("Unexpected CPU of NEC VR4100 series");

From yuasa@hh.iij4u.or.jp Sun Jan 11 14:19:40 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 11 Jan 2004 14:19:41 +0000 (GMT)
Received: from mo03.iij4u.or.jp ([IPv6:::ffff:210.130.0.20]:17897 "EHLO
	mo03.iij4u.or.jp") by linux-mips.org with ESMTP id <S8225234AbUAKOTk>;
	Sun, 11 Jan 2004 14:19:40 +0000
Received: from mdo00.iij4u.or.jp (mdo00.iij4u.or.jp [210.130.0.170])
	by mo03.iij4u.or.jp (8.8.8/MFO1.5) with ESMTP id XAA01878;
	Sun, 11 Jan 2004 23:19:38 +0900 (JST)
Received: 4UMDO00 id i0BEJbL23914; Sun, 11 Jan 2004 23:19:37 +0900 (JST)
Received: 4UMRO00 id i0BEJaC19565; Sun, 11 Jan 2004 23:19:37 +0900 (JST)
	from stratos.frog (64.43.138.210.xn.2iij.net [210.138.43.64]) (authenticated)
Date: Sun, 11 Jan 2004 23:19:32 +0900
From: Yoichi Yuasa <yuasa@hh.iij4u.or.jp>
To: Ralf Baechle <ralf@linux-mips.org>
Cc: yuasa@hh.iij4u.or.jp, linux-mips <linux-mips@linux-mips.org>
Subject: [PATCH][2.6] change registers name for vr41xx
Message-Id: <20040111231932.2b2b26d9.yuasa@hh.iij4u.or.jp>
X-Mailer: Sylpheed version 0.9.8a (GTK+ 1.2.10; i686-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Return-Path: <yuasa@hh.iij4u.or.jp>
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: 3901
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: yuasa@hh.iij4u.or.jp
Precedence: bulk
X-list: linux-mips
Content-Length: 8892
Lines: 271

Hello Ralf,

I made a patch for vr41xx of 2.6.

Although the old register name is using CPU as the base,
it is not dependent on CPU in practice.
This patch corrects the name depending on the CPU name.

Please apply this patch.

Yoichi

diff -urN -X dontdiff linux-orig/arch/mips/vr41xx/common/bcu.c linux/arch/mips/vr41xx/common/bcu.c
--- linux-orig/arch/mips/vr41xx/common/bcu.c	Sat Jan 10 19:43:13 2004
+++ linux/arch/mips/vr41xx/common/bcu.c	Sun Jan 11 22:09:01 2004
@@ -46,8 +46,8 @@
 #include <asm/cpu.h>
 #include <asm/io.h>
 
-#define VR4111_CLKSPEEDREG	KSEG1ADDR(0x0b000014)
-#define VR4122_CLKSPEEDREG	KSEG1ADDR(0x0f000014)
+#define CLKSPEEDREG_TYPE1	KSEG1ADDR(0x0b000014)
+#define CLKSPEEDREG_TYPE2	KSEG1ADDR(0x0f000014)
  #define CLKSP(x)		((x) & 0x001f)
  #define CLKSP_VR4133(x)	((x) & 0x0007)
 
@@ -78,10 +78,10 @@
 {
 	switch (current_cpu_data.cputype) {
 	case CPU_VR4111:
-	case CPU_VR4121: return readw(VR4111_CLKSPEEDREG);
+	case CPU_VR4121: return readw(CLKSPEEDREG_TYPE1);
 	case CPU_VR4122:
 	case CPU_VR4131:
-	case CPU_VR4133: return readw(VR4122_CLKSPEEDREG);
+	case CPU_VR4133: return readw(CLKSPEEDREG_TYPE2);
 	default:
 		printk(KERN_INFO "Unexpected CPU of NEC VR4100 series\n");
 		break;
diff -urN -X dontdiff linux-orig/arch/mips/vr41xx/common/cmu.c linux/arch/mips/vr41xx/common/cmu.c
--- linux-orig/arch/mips/vr41xx/common/cmu.c	Sat Jan 10 19:43:13 2004
+++ linux/arch/mips/vr41xx/common/cmu.c	Sun Jan 11 22:09:01 2004
@@ -47,33 +47,33 @@
 #include <asm/io.h>
 #include <asm/vr41xx/vr41xx.h>
 
-#define VR4111_CMUCLKMSK	KSEG1ADDR(0x0b000060)
-#define VR4122_CMUCLKMSK	KSEG1ADDR(0x0f000060)
- #define MSKPIU			0x0001
- #define MSKSIU			0x0002
- #define MSKAIU			0x0004
- #define MSKKIU			0x0008
- #define MSKFIR			0x0010
- #define MSKDSIU		0x0820
- #define MSKCSI			0x0040
- #define MSKPCIU		0x0080
- #define MSKSSIU		0x0100
- #define MSKSHSP		0x0200
- #define MSKFFIR		0x0400
- #define MSKSCSI		0x1000
- #define MSKPPCIU		0x2000
-#define VR4133_CMUCLKMSK2	KSEG1ADDR(0x0f000064)
- #define MSKCEU			0x0001
- #define MSKMAC0		0x0002
- #define MSKMAC1		0x0004
+#define CMUCLKMSK_TYPE1	KSEG1ADDR(0x0b000060)
+#define CMUCLKMSK_TYPE2	KSEG1ADDR(0x0f000060)
+ #define MSKPIU		0x0001
+ #define MSKSIU		0x0002
+ #define MSKAIU		0x0004
+ #define MSKKIU		0x0008
+ #define MSKFIR		0x0010
+ #define MSKDSIU	0x0820
+ #define MSKCSI		0x0040
+ #define MSKPCIU	0x0080
+ #define MSKSSIU	0x0100
+ #define MSKSHSP	0x0200
+ #define MSKFFIR	0x0400
+ #define MSKSCSI	0x1000
+ #define MSKPPCIU	0x2000
+#define CMUCLKMSK2	KSEG1ADDR(0x0f000064)
+ #define MSKCEU		0x0001
+ #define MSKMAC0	0x0002
+ #define MSKMAC1	0x0004
 
 static u32 vr41xx_cmu_base;
 static u16 cmuclkmsk, cmuclkmsk2;
 
 #define read_cmuclkmsk()	readw(vr41xx_cmu_base)
-#define read_cmuclkmsk2()	readw(VR4133_CMUCLKMSK2)
+#define read_cmuclkmsk2()	readw(CMUCLKMSK2)
 #define write_cmuclkmsk()	writew(cmuclkmsk, vr41xx_cmu_base)
-#define write_cmuclkmsk2()	writew(cmuclkmsk2, VR4133_CMUCLKMSK2)
+#define write_cmuclkmsk2()	writew(cmuclkmsk2, CMUCLKMSK2)
 
 void vr41xx_clock_supply(unsigned int clock)
 {
@@ -206,14 +206,14 @@
 	switch (current_cpu_data.cputype) {
         case CPU_VR4111:
         case CPU_VR4121:
-                vr41xx_cmu_base = VR4111_CMUCLKMSK;
+                vr41xx_cmu_base = CMUCLKMSK_TYPE1;
                 break;
         case CPU_VR4122:
         case CPU_VR4131:
-                vr41xx_cmu_base = VR4122_CMUCLKMSK;
+                vr41xx_cmu_base = CMUCLKMSK_TYPE2;
                 break;
         case CPU_VR4133:
-                vr41xx_cmu_base = VR4122_CMUCLKMSK;
+                vr41xx_cmu_base = CMUCLKMSK_TYPE2;
 		cmuclkmsk2 = read_cmuclkmsk2();
                 break;
 	default:
diff -urN -X dontdiff linux-orig/arch/mips/vr41xx/common/giu.c linux/arch/mips/vr41xx/common/giu.c
--- linux-orig/arch/mips/vr41xx/common/giu.c	Sat Jan 10 19:43:13 2004
+++ linux/arch/mips/vr41xx/common/giu.c	Sun Jan 11 22:09:01 2004
@@ -49,8 +49,8 @@
 #include <asm/io.h>
 #include <asm/vr41xx/vr41xx.h>
 
-#define VR4111_GIUIOSELL	KSEG1ADDR(0x0b000100)
-#define VR4122_GIUIOSELL	KSEG1ADDR(0x0f000140)
+#define GIUIOSELL_TYPE1	KSEG1ADDR(0x0b000100)
+#define GIUIOSELL_TYPE2	KSEG1ADDR(0x0f000140)
 
 #define GIUIOSELL	0x00
 #define GIUIOSELH	0x02
@@ -281,12 +281,12 @@
 	switch (current_cpu_data.cputype) {
 	case CPU_VR4111:
 	case CPU_VR4121:
-		giu_base = VR4111_GIUIOSELL;
+		giu_base = GIUIOSELL_TYPE1;
 		break;
 	case CPU_VR4122:
 	case CPU_VR4131:
 	case CPU_VR4133:
-		giu_base = VR4122_GIUIOSELL;
+		giu_base = GIUIOSELL_TYPE2;
 		break;
 	default:
 		panic("GIU: Unexpected CPU of NEC VR4100 series");
diff -urN -X dontdiff linux-orig/arch/mips/vr41xx/common/icu.c linux/arch/mips/vr41xx/common/icu.c
--- linux-orig/arch/mips/vr41xx/common/icu.c	Sat Jan 10 19:43:13 2004
+++ linux/arch/mips/vr41xx/common/icu.c	Sun Jan 11 22:09:01 2004
@@ -68,11 +68,11 @@
 static unsigned char sysint2_assign[16] = {
 	2, 0, 3, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 };
 
-#define VR4111_SYSINT1REG	KSEG1ADDR(0x0b000080)
-#define VR4111_SYSINT2REG	KSEG1ADDR(0x0b000200)
+#define SYSINT1REG_TYPE1	KSEG1ADDR(0x0b000080)
+#define SYSINT2REG_TYPE1	KSEG1ADDR(0x0b000200)
 
-#define VR4122_SYSINT1REG	KSEG1ADDR(0x0f000080)
-#define VR4122_SYSINT2REG	KSEG1ADDR(0x0f0000a0)
+#define SYSINT1REG_TYPE2	KSEG1ADDR(0x0f000080)
+#define SYSINT2REG_TYPE2	KSEG1ADDR(0x0f0000a0)
 
 #define SYSINT1REG	0x00
 #define INTASSIGN0	0x04
@@ -293,14 +293,14 @@
 	switch (current_cpu_data.cputype) {
 	case CPU_VR4111:
 	case CPU_VR4121:
-		icu1_base = VR4111_SYSINT1REG;
-		icu2_base = VR4111_SYSINT2REG;
+		icu1_base = SYSINT1REG_TYPE1;
+		icu2_base = SYSINT2REG_TYPE1;
 		break;
 	case CPU_VR4122:
 	case CPU_VR4131:
 	case CPU_VR4133:
-		icu1_base = VR4122_SYSINT1REG;
-		icu2_base = VR4122_SYSINT2REG;
+		icu1_base = SYSINT1REG_TYPE2;
+		icu2_base = SYSINT2REG_TYPE2;
 		break;
 	default:
 		panic("Unexpected CPU of NEC VR4100 series");
diff -urN -X dontdiff linux-orig/arch/mips/vr41xx/common/rtc.c linux/arch/mips/vr41xx/common/rtc.c
--- linux-orig/arch/mips/vr41xx/common/rtc.c	Sat Jan 10 19:43:13 2004
+++ linux/arch/mips/vr41xx/common/rtc.c	Sun Jan 11 22:09:01 2004
@@ -39,11 +39,11 @@
 #define REMAINDER_PER_SEC	(CLOCK_TICK_RATE - (CYCLES_PER_JIFFY * HZ))
 #define CYCLES_PER_100USEC	((CLOCK_TICK_RATE + (10000 / 2)) / 10000)
 
-#define VR4111_ETIMELREG	KSEG1ADDR(0x0b0000c0)
-#define VR4111_TCLKLREG		KSEG1ADDR(0x0b0001c0)
+#define ETIMELREG_TYPE1		KSEG1ADDR(0x0b0000c0)
+#define TCLKLREG_TYPE1		KSEG1ADDR(0x0b0001c0)
 
-#define VR4122_ETIMELREG	KSEG1ADDR(0x0f000100)
-#define VR4122_TCLKLREG		KSEG1ADDR(0x0f000120)
+#define ETIMELREG_TYPE2		KSEG1ADDR(0x0f000100)
+#define TCLKLREG_TYPE2		KSEG1ADDR(0x0f000120)
 
 /* RTC 1 registers */
 #define ETIMELREG		0x00
@@ -264,14 +264,14 @@
 	switch (current_cpu_data.cputype) {
 	case CPU_VR4111:
 	case CPU_VR4121:
-		rtc1_base = VR4111_ETIMELREG;
-		rtc2_base = VR4111_TCLKLREG;
+		rtc1_base = ETIMELREG_TYPE1;
+		rtc2_base = TCLKLREG_TYPE1;
 		break;
 	case CPU_VR4122:
 	case CPU_VR4131:
 	case CPU_VR4133:
-		rtc1_base = VR4122_ETIMELREG;
-		rtc2_base = VR4122_TCLKLREG;
+		rtc1_base = ETIMELREG_TYPE2;
+		rtc2_base = TCLKLREG_TYPE2;
 		break;
 	default:
 		panic("Unexpected CPU of NEC VR4100 series");
diff -urN -X dontdiff linux-orig/arch/mips/vr41xx/common/serial.c linux/arch/mips/vr41xx/common/serial.c
--- linux-orig/arch/mips/vr41xx/common/serial.c	Sat Jan 10 19:43:13 2004
+++ linux/arch/mips/vr41xx/common/serial.c	Sun Jan 11 22:09:01 2004
@@ -50,12 +50,12 @@
 #include <asm/vr41xx/vr41xx.h>
 
 /* VR4111 and VR4121 SIU Registers */
-#define VR4111_SIURB		KSEG1ADDR(0x0c000000)
-#define VR4111_SIUIRSEL		KSEG1ADDR(0x0c000008)
+#define SIURB_TYPE1		KSEG1ADDR(0x0c000000)
+#define SIUIRSEL_TYPE1		KSEG1ADDR(0x0c000008)
 
-/* VR4122 and VR4131 SIU Registers */
-#define VR4122_SIURB		KSEG1ADDR(0x0f000800)
-#define VR4122_SIUIRSEL		KSEG1ADDR(0x0f000808)
+/* VR4122, VR4131 and VR4133 SIU Registers */
+#define SIURB_TYPE2		KSEG1ADDR(0x0f000800)
+#define SIUIRSEL_TYPE2		KSEG1ADDR(0x0f000808)
 
  #define USE_RS232C		0x00
  #define USE_IRDA		0x01
@@ -102,12 +102,12 @@
 	switch (current_cpu_data.cputype) {
 	case CPU_VR4111:
 	case CPU_VR4121:
-		writew(val, VR4111_SIUIRSEL);
+		writew(val, SIUIRSEL_TYPE1);
 		break;
 	case CPU_VR4122:
 	case CPU_VR4131:
 	case CPU_VR4133:
-		writew(val, VR4122_SIUIRSEL);
+		writew(val, SIUIRSEL_TYPE2);
 		break;
 	default:
 		printk(KERN_INFO "Unexpected CPU of NEC VR4100 series\n");
@@ -130,12 +130,12 @@
 	switch (current_cpu_data.cputype) {
 	case CPU_VR4111:
 	case CPU_VR4121:
-		s.iomem_base = (unsigned char *)VR4111_SIURB;
+		s.iomem_base = (unsigned char *)SIURB_TYPE1;
 		break;
 	case CPU_VR4122:
 	case CPU_VR4131:
 	case CPU_VR4133:
-		s.iomem_base = (unsigned char *)VR4122_SIURB;
+		s.iomem_base = (unsigned char *)SIURB_TYPE2;
 		break;
 	default:
 		panic("Unexpected CPU of NEC VR4100 series");

From yuasa@hh.iij4u.or.jp Mon Jan 12 13:44:11 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 12 Jan 2004 13:44:14 +0000 (GMT)
Received: from mo02.iij4u.or.jp ([IPv6:::ffff:210.130.0.19]:44512 "EHLO
	mo02.iij4u.or.jp") by linux-mips.org with ESMTP id <S8224916AbUALNoL>;
	Mon, 12 Jan 2004 13:44:11 +0000
Received: from mdo00.iij4u.or.jp (mdo00.iij4u.or.jp [210.130.0.170])
	by mo02.iij4u.or.jp (8.8.8/MFO1.5) with ESMTP id WAA10108;
	Mon, 12 Jan 2004 22:44:05 +0900 (JST)
Received: 4UMDO00 id i0CDi4A03337; Mon, 12 Jan 2004 22:44:04 +0900 (JST)
Received: 4UMRO01 id i0CDi3F28152; Mon, 12 Jan 2004 22:44:04 +0900 (JST)
	from stratos.frog (64.43.138.210.xn.2iij.net [210.138.43.64]) (authenticated)
Date: Mon, 12 Jan 2004 22:44:02 +0900
From: Yoichi Yuasa <yuasa@hh.iij4u.or.jp>
To: Ralf Baechle <ralf@linux-mips.org>
Cc: yuasa@hh.iij4u.or.jp, linux-mips <linux-mips@linux-mips.org>
Subject: [PATCH][2.4] Update FrameBuffer for ITE IT8181
Message-Id: <20040112224402.6210545c.yuasa@hh.iij4u.or.jp>
X-Mailer: Sylpheed version 0.9.8a (GTK+ 1.2.10; i686-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Return-Path: <yuasa@hh.iij4u.or.jp>
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: 3902
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: yuasa@hh.iij4u.or.jp
Precedence: bulk
X-list: linux-mips
Content-Length: 279
Lines: 12

Hello Ralf,

I updated the patch for ITE IT8181 driver.

  http://www.hh.iij4u.or.jp/~yuasa/linux-vr/v2.4/it8181fb-v24.diff

This driver is used for ITE 8172G board and IBM WorkPad z50.

This patch exists for linux_2_4 tag of linux-mips.org CVS.
Please apply this patch.

Yoichi

From ralf@linux-mips.org Mon Jan 12 16:57:25 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 12 Jan 2004 16:57:26 +0000 (GMT)
Received: from p508B5C87.dip.t-dialin.net ([IPv6:::ffff:80.139.92.135]:56448
	"EHLO mail.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225329AbUALQ5Z>; Mon, 12 Jan 2004 16:57:25 +0000
Received: from fluff.linux-mips.net (fluff.linux-mips.net [127.0.0.1])
	by mail.linux-mips.net (8.12.8/8.12.8) with ESMTP id i0CGvOfB023557;
	Mon, 12 Jan 2004 17:57:24 +0100
Received: (from ralf@localhost)
	by fluff.linux-mips.net (8.12.8/8.12.8/Submit) id i0CGvO1D023556;
	Mon, 12 Jan 2004 17:57:24 +0100
Date: Mon, 12 Jan 2004 17:57:24 +0100
From: Ralf Baechle <ralf@linux-mips.org>
To: karthikeyan natarajan <karthik_96cse@yahoo.com>
Cc: linux-mips@linux-mips.org
Subject: Re: How to configure the cache size in r4000
Message-ID: <20040112165724.GA16126@linux-mips.org>
References: <20040111124828.71884.qmail@web10103.mail.yahoo.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20040111124828.71884.qmail@web10103.mail.yahoo.com>
User-Agent: Mutt/1.4i
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: 3903
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
Content-Length: 508
Lines: 13

On Sun, Jan 11, 2004 at 12:48:28PM +0000, karthikeyan natarajan wrote:

>     The cache size is modified by setting the IC/DC
> bits in the 'config' register. Seems they are set only
> by the hardware during the processor reset. And also,
> those bits are mentioned as read only bits..
>    Could you please let me know how can we instruct 
> the hardware to do so. Can we do this via s/w?.

You can't.  These bits are hardwired to indicate the cache size which is
8k per primary cache on the R4000.

  Ralf

From bunk@fs.tum.de Tue Jan 13 01:52:06 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 13 Jan 2004 01:52:06 +0000 (GMT)
Received: from hermes.fachschaften.tu-muenchen.de ([IPv6:::ffff:129.187.202.12]:21456
	"HELO hermes.fachschaften.tu-muenchen.de") by linux-mips.org
	with SMTP id <S8225349AbUAMBwG>; Tue, 13 Jan 2004 01:52:06 +0000
Received: (qmail 3083 invoked from network); 13 Jan 2004 01:49:21 -0000
Received: from mimas.fachschaften.tu-muenchen.de (129.187.202.58)
  by hermes.fachschaften.tu-muenchen.de with QMQP; 13 Jan 2004 01:49:21 -0000
Date: Tue, 13 Jan 2004 02:52:02 +0100
From: Adrian Bunk <bunk@fs.tum.de>
To: ralf@gnu.org
Cc: linux-mips@linux-mips.org, linux-kernel@vger.kernel.org
Subject: [2.6 patch] fix DECSTATION depends
Message-ID: <20040113015202.GE9677@fs.tum.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.4.1i
Return-Path: <bunk@fs.tum.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: 3904
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: bunk@fs.tum.de
Precedence: bulk
X-list: linux-mips
Content-Length: 807
Lines: 28

Hi Ralf,

it seems the following is required in Linus' tree to get correct depends 
for DECSTATION:

--- linux-2.6.1-mm2/arch/mips/Kconfig.old	2004-01-13 02:33:53.000000000 +0100
+++ linux-2.6.1-mm2/arch/mips/Kconfig	2004-01-13 02:36:04.000000000 +0100
@@ -51,7 +51,7 @@
 
 config DECSTATION
 	bool "Support for DECstations"
-	depends on MIPS32 || EXPERIMENTAL
+	depends on MIPS32 && EXPERIMENTAL
 	---help---
 	  This enables support for DEC's MIPS based workstations.  For details
 	  see the Linux/MIPS FAQ on <http://oss.sgi.com/mips/> and the


cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed


From ralf@linux-mips.org Tue Jan 13 02:30:32 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 13 Jan 2004 02:30:33 +0000 (GMT)
Received: from p508B5C87.dip.t-dialin.net ([IPv6:::ffff:80.139.92.135]:54917
	"EHLO mail.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225353AbUAMCac>; Tue, 13 Jan 2004 02:30:32 +0000
Received: from fluff.linux-mips.net (fluff.linux-mips.net [127.0.0.1])
	by mail.linux-mips.net (8.12.8/8.12.8) with ESMTP id i0D2STfB027160;
	Tue, 13 Jan 2004 03:28:29 +0100
Received: (from ralf@localhost)
	by fluff.linux-mips.net (8.12.8/8.12.8/Submit) id i0D2SQrK027159;
	Tue, 13 Jan 2004 03:28:26 +0100
Date: Tue, 13 Jan 2004 03:28:26 +0100
From: Ralf Baechle <ralf@linux-mips.org>
To: Adrian Bunk <bunk@fs.tum.de>
Cc: linux-mips@linux-mips.org, linux-kernel@vger.kernel.org
Subject: Re: [2.6 patch] fix DECSTATION depends
Message-ID: <20040113022826.GC1646@linux-mips.org>
References: <20040113015202.GE9677@fs.tum.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20040113015202.GE9677@fs.tum.de>
User-Agent: Mutt/1.4i
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: 3905
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
Content-Length: 183
Lines: 8

On Tue, Jan 13, 2004 at 02:52:02AM +0100, Adrian Bunk wrote:

> it seems the following is required in Linus' tree to get correct depends 
> for DECSTATION:

Thanks,  applied.

  Ralf

From ndf@ghs.com Tue Jan 13 02:35:04 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 13 Jan 2004 02:35:05 +0000 (GMT)
Received: from eta.ghs.com ([IPv6:::ffff:63.102.70.66]:44004 "EHLO eta.ghs.com")
	by linux-mips.org with ESMTP id <S8225353AbUAMCfE>;
	Tue, 13 Jan 2004 02:35:04 +0000
Received: from blaze.ghs.com (blaze.ghs.com [192.67.158.233])
	by eta.ghs.com (8.12.10/8.12.10) with ESMTP id i0D2Yx6t017835
	for <linux-mips@linux-mips.org>; Mon, 12 Jan 2004 18:34:59 -0800 (PST)
Received: from zcar.ghs.com (zcar.ghs.com [192.67.158.60])
	by blaze.ghs.com (8.12.9/8.12.9) with ESMTP id i0D2Yw9w008107;
	Mon, 12 Jan 2004 18:34:58 -0800 (PST)
Date: Mon, 12 Jan 2004 18:34:57 -0800 (PST)
From: Nathan Field <ndf@ghs.com>
To: linux-mips@linux-mips.org
Subject: ptrace induced instruction cache bug?
Message-ID: <Pine.LNX.4.44.0401121806240.1969-300000@zcar.ghs.com>
MIME-Version: 1.0
Content-Type: MULTIPART/MIXED; BOUNDARY="1136671902-820035827-1073961297=:1969"
Return-Path: <ndf@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: 3906
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: ndf@ghs.com
Precedence: bulk
X-list: linux-mips
Content-Length: 21985
Lines: 394

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.
  Send mail to mime@docserver.cac.washington.edu for more info.

--1136671902-820035827-1073961297=:1969
Content-Type: TEXT/PLAIN; charset=US-ASCII

I'm writing a debugger that uses the Linux ptrace API for process control
and I think I've found a bug in ptrace in MIPS Linux. The specific
situation that breaks horribly with my debugger is quite complex, so I
wrote a little testbed to show the problem. The code and a sample Makefile
are attached. You can build the example for x86 or MIPS. I have some
things in there for PPC but I haven't ported it fully yet. Basically the
problem seems to be that writing a breakpoint (instruction 0xd), running 
to the breakpoint, replacing the breakpoint with the original instruction 
and then resuming sometimes results in the process halting on the same 
address, even though there isn't a breakpoint there anymore. If you resume 
again, or wait for a "while" after removing the breakpoint everything 
works fine. I believe the problem is probably linked to some sort of 
problem with the kernel not flushing the instruction cache, but that's 
just a guess.

I've encountered problems in ptrace like this with other architectures
before. If anyone wants to take my ptrace test code and make it part of
some kernel validation system please do. The code was whipped up fairly 
quickly so you might want to clean it up. I've verified that when it is 
run slowly enough it works fine.

I'd guess that this problem has been fixed in later versions of the 
kernel. If anyone can point me to a 2.4 release with this fixed I'd like 
to know about it. I tried building the cvs checkout but the build failed. 
It looks like I'll need a newer toolchain than the one I got from 
MontaVista[1].

I'm using a stock MontaVista distribution for the MIPS Malta 4Kc in big
endian mode, downloaded from their site a couple of days ago. I recompiled
the kernel with the arch/mips/configs/defconfig-malta, but haven't changed 
any options yet. Since that could be hard to classify here are some 
details about my system:

$ uname -a
Linux 192.67.158.75 2.4.17_mvl21 #8 Wed Jan 7 18:19:32 PST 2004 mips unknown

gcc version:
19) ./mips_fp_be-gcc -v
./mips_fp_be-gcc: Actual path = 
'/space1/opt/hardhat/previewkit/mips/fp_be/bin/'        Actual name = 
'mips_fp_be-gcc'
        Invoking 
/space1/opt/hardhat/previewkit/mips/fp_be/bin/../lib/gcc-lib/mips-hardhat-linux/2.95.3/mips_fp_be-gcc
Reading specs from 
/space1/opt/hardhat/previewkit/mips/fp_be/bin/../lib/gcc-lib/mips-hardhat-linux/2.95.3/specs
gcc version 2.95.3 20010315 (release/MontaVista)

$ cat /proc/cpuinfo
processor               : 0
cpu model               : MIPS 4Kc V0.5
BogoMIPS                : 124.51
wait instruction        : no
microsecond timers      : yes
extra interrupt vector  : yes
hardware watchpoint     : yes
VCED exceptions         : not available
VCEI exceptions         : not available

	Any help would be greatly appreciated,

	nathan

[1] Here's the error I get building the linux-mips.org cvs kernel. I don't 
know why it's trying to build a ramfs component, I only have ext2, /proc, 
/dev/pts, NFS, and NFS as root enabled. I've also diabled ramdisk support 
(CONFIG_BLK_DEV_RAM):

make[1]: `arch/mips/kernel/offset.s' is up to date.
make[1]: `arch/mips/kernel/reg.s' is up to date.
  CHK     include/linux/compile.h
  AS      usr/initramfs_data.o
usr/initramfs_data.S: Assembler messages:
usr/initramfs_data.S:29: Error: Unknown pseudo-op:  `.incbin'
make[1]: *** [usr/initramfs_data.o] Error 1
make: *** [usr] Error 2



-- 
Nathan Field (ndf@ghs.com)			          All gone.

But the trouble with analogies is that analogies are like goldfish:
sometimes they have nothing to do with the topic at hand.
        -- Crispin (from a posting to the Bugtraq mailing list)

--1136671902-820035827-1073961297=:1969
Content-Type: TEXT/PLAIN; charset=US-ASCII; name="simpledebugger.c"
Content-Transfer-Encoding: BASE64
Content-ID: <Pine.LNX.4.44.0401121834570.1969@zcar.ghs.com>
Content-Description: 
Content-Disposition: attachment; filename="simpledebugger.c"

I2lmbmRlZiBUQVJHRVRfQVJDSA0KIyAgZXJyb3IgWW91IG11c3QgZGVmaW5l
IGEgVEFSR0VUX0FSQ0guDQojZW5kaWYNCg0KI2RlZmluZSBYODYgICAxDQoj
ZGVmaW5lIE1JUFMgIDINCiNkZWZpbmUgUFBDICAgMw0KDQojaWYoVEFSR0VU
X0FSQ0g9PVg4NikNCiMgIGRlZmluZSBORUVEX1RPX0FESlVTVF9BRlRFUl9C
UF9ISVQNCiMgIGRlZmluZSBCUkVBS1BPSU5UX0lOU1RSVUNUSU9OIDB4Y2MN
CiMgIGRlZmluZSBCUkVBS1BPSU5UX1NJWkUgMQ0KI2VsaWYoVEFSR0VUX0FS
Q0g9PU1JUFMpDQojICBkZWZpbmUgQlJFQUtQT0lOVF9JTlNUUlVDVElPTiAw
eDAwMDAwMDBkDQojICBkZWZpbmUgQlJFQUtQT0lOVF9TSVpFIDQNCiNlbGlm
KFRBUkdFVF9BUkNIPT1QUEMpDQojICBkZWZpbmUgQlJFQUtQT0lOVF9JTlNU
UlVDVElPTiAweDdmZTAwMDA4DQojICBkZWZpbmUgQlJFQUtQT0lOVF9TSVpF
IDQNCiNlbHNlDQojICBlcnJvciBVbnN1cHBvcnRlZCBhcmNoLg0KI2VuZGlm
DQoNCiNkZWZpbmUgSVRFUkFUSU9OUyAxMDANCg0KDQovKiAtLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tICovDQoNCg0KI2RlZmluZSBTVUNDRVNTIDENCiNkZWZpbmUg
RkFJTFVSRSAwDQoNCg0KLyogLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSAqLw0KDQoN
CiNpbmNsdWRlIDxzdGRpby5oPg0KI2luY2x1ZGUgPHN0ZGludC5oPg0KI2lu
Y2x1ZGUgPHVuaXN0ZC5oPg0KI2luY2x1ZGUgPGVycm5vLmg+DQojaW5jbHVk
ZSA8c2lnbmFsLmg+DQojaW5jbHVkZSA8c3lzL3R5cGVzLmg+DQojaW5jbHVk
ZSA8c3lzL3dhaXQuaD4NCiNpbmNsdWRlIDxzeXMvc2VsZWN0Lmg+DQojaW5j
bHVkZSA8c3lzL3B0cmFjZS5oPg0KI2luY2x1ZGUgPGFzbS9wdHJhY2UuaD4N
Cg0KDQovKiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tICovDQoNCg0Kc3RhdGljIHZv
aWQgZGVidWdnZWRQcm9ncmFtKCk7DQpzdGF0aWMgdm9pZCBwYXJlbnRQcm9j
ZXNzKGludCBwaWQpOw0Kc3RhdGljIHZvaWQgc3RhcnRUcmFjZShjaGFyICpw
cm9nbmFtZSk7DQoNCi8qIEZ1bmN0aW9ucyB3ZSBzZXQgYnJlYWtwb2ludHMg
b24uICovDQppbnQgbWFpbihpbnQgYXJnYywgY2hhciAqYXJndltdKTsNCnN0
YXRpYyBpbnQgZG9Tb21ldGhpbmdGdW5jKCk7DQpzdGF0aWMgaW50IGRvU29t
ZXRoaW5nRWxzZUZ1bmMoKTsNCg0KDQoNCi8qIC0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0gKi8NCg0KDQovKiogVGhpcyBwcm9ncmFtIGlzIGEgdGVzdCBiZWQgdG8g
ZmluZCBidWdzIGluIExpbnV4IHB0cmFjZQ0KICogaW1wbGVtZW50YXRpb25z
LiAgSXQgc3RhcnRzIGJ5IGZvcmtpbmcuIFRoZSBjaGlsZCBwcm9jZXNzIGRv
ZXMgYQ0KICogUFRSQUNFX1RSQUNFTUUgYW5kIHRoZW4gYW4gZXhlYyBvZiBp
dHNlbGYgd2l0aCBzcGVjaWFsDQogKiBhcmd1bWVudHMuIFdoZW4gaXQgc3Rh
cnRzIHVwIGFnYWluIGl0IHRoZW4gcnVucyB0aGUgZGVidWdnZWRQcm9ncmFt
DQogKiBmdW5jdGlvbi4gVGhlIHBhcmVudCBkb2VzIHNvbWUgZGVidWdnaW5n
IG9wZXJhdGlvbnMgdG8gdGVzdA0KICogcHRyYWNlLiAqLw0KaW50IG1haW4o
aW50IGFyZ2MsIGNoYXIgKmFyZ3ZbXSkNCnsNCiAgICBpbnQgcGlkOw0KDQog
ICAgaWYoIChhcmdjID09IDIpICYmICFzdHJjbXAoInRyYWNlZF9wcm9ncmFt
IiwgYXJndlsxXSkgKSB7DQoJZGVidWdnZWRQcm9ncmFtKCk7DQoJZXhpdCgw
KTsNCiAgICB9IGVsc2UgaWYoYXJnYyAhPSAxKSB7DQoJZnByaW50ZihzdGRl
cnIsICJSdW4gdGhpcyBwcm9ncmFtIHdpdGggbm8gYXJndW1lbnRzLlxuIik7
DQoJZXhpdCgxKTsNCiAgICB9DQoNCiAgICBwaWQgPSBmb3JrKCk7DQoNCiAg
ICBpZihwaWQgPT0gMCkgew0KCXN0YXJ0VHJhY2UoYXJndlswXSk7DQoJLyog
U2hvdWxkIG5ldmVyIGdldCBoZXJlLiAqLw0KCWV4aXQoMSk7DQogICAgfSBl
bHNlIHsNCglmcHJpbnRmKHN0ZGVyciwgIkFkZHJlc3Mgb2Y6XHRtYWluXHRc
dFx0OiAweCV4XG4iLCAodWludDMyX3QpbWFpbik7DQoJZnByaW50ZihzdGRl
cnIsICJBZGRyZXNzIG9mOlx0ZG9Tb21ldGhpbmdGdW5jXHRcdDogMHgleFxu
IiwNCgkJKHVpbnQzMl90KWRvU29tZXRoaW5nRnVuYyk7DQoJZnByaW50Zihz
dGRlcnIsICJBZGRyZXNzIG9mOlx0ZG9Tb21ldGhpbmdFbHNlRnVuY1x0OiAw
eCV4XG4iLA0KCQkodWludDMyX3QpZG9Tb21ldGhpbmdFbHNlRnVuYyk7DQoN
CglwYXJlbnRQcm9jZXNzKHBpZCk7DQogICAgfQ0KDQogICAgcmV0dXJuIDA7
DQp9DQoNCg0KLyogLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSAqLw0KDQoNCnN0YXRp
YyBpbnQgc29tZV9udW1iZXIgPSAwOw0KDQovKiBTZXQgYSBicmVha3BvaW50
IG9uIHRoaXMgZnVuY3Rpb24uICovDQpzdGF0aWMgaW50IGRvU29tZXRoaW5n
RnVuYygpDQp7DQogICAgcmV0dXJuICsrc29tZV9udW1iZXI7DQp9DQoNCnN0
YXRpYyB2b2lkIGRvU3lzdGVtQ2FsbCgpDQp7DQogICAgLyogU2VsZWN0IHNl
ZW1zIGxpa2UgYSBnb29kIHN5c3RlbSBjYWxsIHRvIGRvLiAqLw0KICAgIHN0
cnVjdCB0aW1ldmFsIHRpbWVvdXQ7DQogICAgdGltZW91dC50dl9zZWMgPSAw
Ow0KICAgIHRpbWVvdXQudHZfdXNlYyA9IDE7DQogICAgc2VsZWN0KDAsIDAs
IDAsIDAsICZ0aW1lb3V0KTsNCn0NCg0KLyogU2V0IGJyZWFrcG9pbnQgb24g
dGhpcyBmdW5jdGlvbi4gKi8NCnN0YXRpYyBpbnQgZG9Tb21ldGhpbmdFbHNl
RnVuYygpDQp7DQogICAgcmV0dXJuICsrc29tZV9udW1iZXI7DQp9DQoNCi8q
IFRoaXMgaXMgdGhlICJtZWF0IiBvZiB0aGUgcHJvZ3JhbSB3aGljaCBnZXRz
IGRlYnVnZ2VkLiBTaW5jZSBJIHVzZQ0KICogYSBjb21iaW5hdGlvbiBvZiBQ
VFJBQ0VfQ09OVCBhbmQgUFRSQUNFX1NZU0NBTEwgaXQncyBpbXBvcnRhbnQg
dGhhdA0KICogdGhpcyBwcm9ncmFtIG9ubHkgZG8gc3lzdGVtIGNhbGxzIGlu
IHZlcnkgc3BlY2lmaWMgc2l0dWF0aW9ucywgaW4NCiAqIHBhcnRpY3VsYXIg
b25seSBiZXR3ZWVuIHRoZSB0d28gZG9Tb21ldGhpbmcqIGZ1bmN0aW9ucy4g
Ki8NCnN0YXRpYyB2b2lkIGRlYnVnZ2VkUHJvZ3JhbSgpDQp7DQogICAgaW50
IGk7DQogICAgZm9yKGk9MDsgaTxJVEVSQVRJT05TOyArK2kpIHsNCglkb1Nv
bWV0aGluZ0Z1bmMoKTsNCglwcmludGYoImRlYnVnZ2VkUHJvZ3JhbTogRG9p
bmcgaXRlcmF0aW9uICVkLlxuIiwgaSk7DQoJZG9TeXN0ZW1DYWxsKCk7DQoJ
ZG9Tb21ldGhpbmdFbHNlRnVuYygpOw0KICAgIH0NCiAgICBwcmludGYoImRl
YnVnZ2VkUHJvZ3JhbTogRmluaXNoZWQuXG4iKTsNCn0NCg0KDQovKiAtLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tICovDQoNCg0Kdm9pZCBmYWlsdXJlKGNvbnN0IGNo
YXIgKm1zZykNCnsNCiAgICBmcHJpbnRmKHN0ZGVyciwgbXNnKTsNCiAgICBl
eGl0KDEpOw0KfQ0KDQpzdGF0aWMgdm9pZCBzdGFydFRyYWNlKGNoYXIgKnBy
b2duYW1lKQ0Kew0KICAgIGNoYXIgKmFyZ3ZbXSA9IHtwcm9nbmFtZSwgInRy
YWNlZF9wcm9ncmFtIiwgTlVMTH07DQogICAgcHRyYWNlKFBUUkFDRV9UUkFD
RU1FLCAwLCAwLCAwKTsNCiAgICBleGVjdihwcm9nbmFtZSwgYXJndik7DQog
ICAgcGVycm9yKCJDaGlsZCBmYWlsZWQgdG8gZXhlY3YiKTsNCn0NCg0KLyog
cHRyYWNlIHJlYWRzL3dyaXRlcyBpbiA0IGJ5dGUgYmxvY2tzLCBzbyB3ZSBu
ZWVkIHRvIGJlIGFsaWduZWQgdG8gNA0KICogYnl0ZSBib3VuZGFyaWVzLiAq
Lw0Kc3RhdGljIGludCBhZGRyQWxpZ25lZCh1aW50MzJfdCBhZGRyKQ0Kew0K
ICAgIGlmKCAoYWRkciAmIDMpID09IDApIHsNCglyZXR1cm4gU1VDQ0VTUzsN
CiAgICB9IGVsc2Ugew0KCXJldHVybiBGQUlMVVJFOw0KICAgIH0NCn0NCg0K
c3RhdGljIHVpbnQzMl90IHJlYWRQQyhpbnQgcGlkKQ0Kew0KI2lmKFRBUkdF
VF9BUkNIPT1YODYpDQogICAgdWludDMyX3QgclsxN107IC8qIDE3IHJlZ2lz
dGVycyBvbiB4ODYgKi8NCiAgICBpZihwdHJhY2UoUFRSQUNFX0dFVFJFR1Ms
IHBpZCwgMCwgKGNoYXIgKikmciwgMCkgPT0gMCkgew0KCXJldHVybiByWzEy
XTsNCiAgICB9DQojZWxzZQ0KICAgIC8qIGFzbS1taXBzL3B0cmFjZS5oIE1J
UFMgZ2l2ZXMgdXMgYSBQQyBkZWZpbmUgZm9yIHRoZSBvZmZzZXQuICovDQog
ICAgdWludDMyX3QgdmFsID0gcHRyYWNlKFBUUkFDRV9QRUVLVVNFUiwgcGlk
LCBQQywgMCwgMCk7DQogICAgaWYoICh2YWwgIT0gLTEpIHx8IChlcnJubyA9
PSAwKSApIHsNCglyZXR1cm4gdmFsOw0KICAgIH0NCiNlbmRpZg0KICAgIHBl
cnJvcigiRmFpbGVkIHRvIHJlYWQgUEMuXG4iKTsNCiAgICBleGl0KDEpOw0K
ICAgIHJldHVybiAweEZGRkZGRkZGOw0KfQ0KDQpzdGF0aWMgdm9pZCB3cml0
ZVBDKGludCBwaWQsIHVpbnQzMl90IG5ld3BjKQ0Kew0KI2lmKFRBUkdFVF9B
UkNIPT1YODYpDQogICAgdWludDMyX3QgclsxN107DQogICAgaWYocHRyYWNl
KFBUUkFDRV9HRVRSRUdTLCBwaWQsIDAsIChjaGFyKikmciwgMCkgIT0gMCkg
ew0KCWZhaWx1cmUoIlVuYWJsZSB0byBnZXQgcmVnaXN0ZXJzIHRvIHdyaXRl
IG5ldyBQQy5cbiIpOw0KICAgIH0NCiAgICByWzEyXSA9IG5ld3BjOw0KICAg
IGlmKHB0cmFjZShQVFJBQ0VfU0VUUkVHUywgcGlkLCAwLCAoY2hhciopJnIs
IDApICE9IDApIHsNCglmYWlsdXJlKCJGYWlsZWQgdG8gd3JpdGUgcmVnaXN0
ZXJzIHdoZW4gYWRqdXN0aW5nIFBDLlxuIik7DQogICAgfQ0KI2VsaWYoVEFS
R0VUX0FSQ0g9PU1JUFMpDQogICAgLyogYXNtLW1pcHMvcHRyYWNlLmggTUlQ
UyBnaXZlcyB1cyBhIFBDIGRlZmluZSBmb3IgdGhlIG9mZnNldC4gKi8NCiAg
ICBpZihwdHJhY2UoUFRSQUNFX1BPS0VVU0VSLCBwaWQsIFBDLCBuZXdwYywg
MCkgIT0gMCkgew0KCWZhaWx1cmUoIkZhaWxlZCB0byB3cml0ZSBQQy5cbiIp
Ow0KICAgIH0NCiNlbHNlDQojICBlcnJvciBVbnN1cHBvcnRlZCBhcmNoLg0K
I2VuZGlmDQp9DQoNCnN0YXRpYyB1aW50MzJfdCBhZGp1c3RGb3JCcChpbnQg
cGlkLCB1aW50MzJfdCBjdXJwYykNCnsNCiNpZmRlZiBORUVEX1RPX0FESlVT
VF9BRlRFUl9CUF9ISVQNCiAgICB1aW50MzJfdCBuZXdwYzsNCiAgICBpZihj
dXJwYyAtIEJSRUFLUE9JTlRfU0laRSA9PSAodWludDMyX3QpbWFpbikgew0K
CW5ld3BjID0gY3VycGMgLSBCUkVBS1BPSU5UX1NJWkU7DQogICAgfSBlbHNl
IGlmKGN1cnBjIC0gQlJFQUtQT0lOVF9TSVpFID09ICh1aW50MzJfdClkb1Nv
bWV0aGluZ0Z1bmMpIHsNCgluZXdwYyA9IGN1cnBjIC0gQlJFQUtQT0lOVF9T
SVpFOw0KICAgIH0gZWxzZSBpZihjdXJwYyAtIEJSRUFLUE9JTlRfU0laRSA9
PSAodWludDMyX3QpZG9Tb21ldGhpbmdFbHNlRnVuYykgew0KCW5ld3BjID0g
Y3VycGMgLSBCUkVBS1BPSU5UX1NJWkU7DQogICAgfSBlbHNlIHsNCglyZXR1
cm4gY3VycGM7DQogICAgfQ0KICAgIHdyaXRlUEMocGlkLCBuZXdwYyk7DQog
ICAgcmV0dXJuIG5ld3BjOw0KI2Vsc2UNCiAgICByZXR1cm4gY3VycGM7DQoj
ZW5kaWYNCn0NCg0Kc3RhdGljIGludCByZWFkV29yZChpbnQgcGlkLCB1aW50
MzJfdCBhbGlnbmVkX2FkZHIsIHVpbnQzMl90ICp2YWwpDQp7DQogICAgKnZh
bCA9IHB0cmFjZShQVFJBQ0VfUEVFS0RBVEEsIHBpZCwgYWxpZ25lZF9hZGRy
LCAwKTsNCiAgICBpZiggKCp2YWwgPT0gMHhGRkZGRkZGRikgJiYgKGVycm5v
ICE9IDApICkgew0KCS8qIFRoZSB2YWx1ZSBjb3VsZCBiZSAtMSwgc28gY2hl
Y2sgZXJybm8gdG8gc2VlIGlmIHRoZXJlIHdhcyBhDQoJICogZmFpbHVyZS4g
Ki8NCglyZXR1cm4gRkFJTFVSRTsNCiAgICB9IGVsc2Ugew0KCXJldHVybiBT
VUNDRVNTOw0KICAgIH0NCn0NCg0Kc3RhdGljIGludCB3cml0ZVdvcmQoaW50
IHBpZCwgdWludDMyX3QgYWxpZ25lZF9hZGRyLCB1aW50MzJfdCB2YWwpDQp7
DQogICAgaWYocHRyYWNlKFBUUkFDRV9QT0tFREFUQSwgcGlkLCBhbGlnbmVk
X2FkZHIsIHZhbCkgPT0gLTEpIHsNCglyZXR1cm4gRkFJTFVSRTsNCiAgICB9
IGVsc2Ugew0KCXJldHVybiBTVUNDRVNTOw0KICAgIH0NCn0NCg0KLyogU3dh
cCBhIHZhbHVlICgxIGJ5dGUgb3IgNCkgd2l0aCB0aGUgY3VycmVudCB2YWx1
ZSBpbiB0aGUgZ2l2ZW4NCiAqIGxvY2F0aW9uLiAgV29ya3Mgd2l0aCB1bmFs
aWduZWQgYWRkcmVzc2VzICh3aGljaCBzaG91bGQgb25seSBoYXBwZW4NCiAq
IG9uIHg4NikuICovDQpzdGF0aWMgaW50IHN3YXBNZW1vcnkoaW50IHBpZCwg
dWludDMyX3QgYWRkciwgaW50IHNpemUsDQoJCSAgICAgIHVpbnQzMl90IG5l
d192YWwsIHVpbnQzMl90ICpvbGRfdmFsKQ0Kew0KICAgIGlmKGFkZHJBbGln
bmVkKGFkZHIpKSB7DQoJLyogU2ltcGxlIGNhc2UsIDQgYnl0ZSwgYWxpZ25l
ZCBhZGRyZXNzLiAqLw0KCWlmKHJlYWRXb3JkKHBpZCwgYWRkciwgb2xkX3Zh
bCkgIT0gU1VDQ0VTUykNCgkgICAgZmFpbHVyZSgiRmFpbGVkIHRvIHJlYWQg
d29yZCB3aGlsZSBzd2FwcGluZyBtZW1vcnkuXG4iKTsNCglzd2l0Y2goc2l6
ZSkgew0KCWNhc2UgMToNCiNpZmRlZiBMSVRUTEVfRU5ESUFODQoJICAgIG5l
d192YWwgPSAobmV3X3ZhbCAmIDB4MDAwMDAwRkYpIHwgKCpvbGRfdmFsICYg
MHhGRkZGRkYwMCk7DQoJICAgICpvbGRfdmFsID0gKm9sZF92YWwgJiAweDAw
MDAwMEZGOw0KI2Vsc2UgLyogYmlnIGVuZGlhbiBhcmNoICovDQogICAgICAg
ICAgICBuZXdfdmFsID0gKG5ld192YWwgPDwgMjQpIHwgKCpvbGRfdmFsICYg
MHgwMEZGRkZGRik7DQogICAgICAgICAgICAqb2xkX3ZhbCA9ICpvbGRfdmFs
ID4+IDI0Ow0KI2VuZGlmDQoJICAgIGJyZWFrOw0KCWNhc2UgNDoNCgkgICAg
YnJlYWs7DQoJZGVmYXVsdDoNCgkgICAgZmFpbHVyZSgiVW5zdXBwb3J0ZWQg
bWVtb3J5IHN3YXAgc2l6ZS5cbiIpOyANCgl9DQoJaWYod3JpdGVXb3JkKHBp
ZCwgYWRkciwgbmV3X3ZhbCkgIT0gU1VDQ0VTUykNCgkgICAgZmFpbHVyZSgi
RmFpbGVkIHRvIHdyaXRlIHdvcmQgd2hpbGUgc3dhcHBpbmcgbWVtb3J5Llxu
Iik7DQoJcmV0dXJuIFNVQ0NFU1M7DQogICAgfSBlbHNlIHsNCgkvLyBVbmFs
aWduZWQgYWRkcmVzcywgZG8gZWFjaCBieXRlIGluIHR1cm4gcmVjdXJzaXZs
eS4NCglpbnQgaTsNCgl1aW50MzJfdCBvbGRfcGFydGlhbDsNCglmb3IoaT0w
OyBpPHNpemU7ICsraSkgew0KCSAgICBvbGRfcGFydGlhbCA9IDA7DQoJICAg
IGlmKHN3YXBNZW1vcnkocGlkLCBhZGRyICsgKDIqaSksIDEsIG5ld192YWw8
PChpKjgpLCAmb2xkX3BhcnRpYWwpICE9IFNVQ0NFU1MpDQoJCWZhaWx1cmUo
IkZhaWxlZCB3aGlsZSBkb2luZyByZWN1cnNpdmUgc3dhcE1lbW9yeS5cbiIp
Ow0KCSAgICAqb2xkX3ZhbCA9ICpvbGRfdmFsICYgKG9sZF9wYXJ0aWFsIDw8
IChpKjgpKTsNCgl9DQoJcmV0dXJuIFNVQ0NFU1M7DQogICAgfQ0KfQ0KDQpz
dGF0aWMgdm9pZCBwYXJlbnRQcm9jZXNzKGludCBwaWQpDQp7DQogICAgaW50
IGk7DQogICAgaW50IHJldDsNCiAgICBpbnQgc3RhdHVzOw0KICAgIC8qIFVz
ZWQgdG8gc3RvcmUgaW5zdHJ1Y3Rpb24gd2hlcmUgdGhlIGJyZWFrcG9pbnQg
d2FzDQogICAgICogaW5zdGFsbGVkLiAqLw0KICAgIHVpbnQzMl90IGluc3Q7
DQogICAgdWludDMyX3QgdGVtcDsNCg0KICAgIHByaW50ZigicGFyZW50UHJv
Y2VzczogQmVnaW5uaW5nIGRlYnVnZ2luZyBvZiBjaGlsZCAlZC5cbiIsIHBp
ZCk7DQoNCiAgICAvKiBXYWl0IGZvciBwcm9jZXNzIHRvIGV4ZWMsIHdlIHdp
bGwgZ2V0IGEgU0lHVFJBUA0KICAgICAqIG5vdGlmaWNhdGlvbi4gKi8NCiAg
ICByZXQgPSB3YWl0cGlkKHBpZCwgJnN0YXR1cywgMCk7DQogICAgaWYocmV0
ICE9IHBpZCkgZmFpbHVyZSgid2FpdHBpZCB0byBmaW5kIGV4ZWMgZmFpbGVk
LlxuIik7DQoNCiAgICBpZighV0lGU1RPUFBFRChzdGF0dXMpIHx8IChXU1RP
UFNJRyhzdGF0dXMpICE9IFNJR1RSQVApKQ0KCWZhaWx1cmUoIkRpZCBub3Qg
Z2V0IGV4cGVjdGVkIFNJR1RSQVAgZm9yIGV4ZWMuXG4iKTsNCg0KICAgIC8q
IFNldCBicmVha3BvaW50IG9uIG1haW4uICovDQogICAgaWYoc3dhcE1lbW9y
eShwaWQsICh1aW50MzJfdCltYWluLCBCUkVBS1BPSU5UX1NJWkUsDQoJCSAg
QlJFQUtQT0lOVF9JTlNUUlVDVElPTiwgJmluc3QpICE9IFNVQ0NFU1MpDQoJ
ZmFpbHVyZSgiRmFpbGVkIHRvIGluc3RhbGwgYnJlYWtwb2ludCBvbiBtYWlu
LlxuIik7DQoNCiAgICAvKiBSZXN1bWUgcHJvY2Vzcy4gKi8NCiAgICBwdHJh
Y2UoUFRSQUNFX0NPTlQsIHBpZCwgMCwgMCk7DQoNCiAgICAvKiBXYWl0IGZv
ciBwcm9jZXNzIHRvIGhpdCBicmVha3BvaW50LCB3ZSB3aWxsIGdldCBhIFNJ
R1RSQVANCiAgICAgKiBub3RpZmljYXRpb24uICovDQogICAgcmV0ID0gd2Fp
dHBpZChwaWQsICZzdGF0dXMsIDApOw0KDQogICAgaWYoIVdJRlNUT1BQRUQo
c3RhdHVzKSkgew0KCWZhaWx1cmUoIlN0YXR1cyBpbmRpY2F0ZXMgdGhhdCBw
cm9jZXNzIGlzIG5vdCBzdG9wcGVkIG9uIG1haW4uXG4iKTsNCiAgICB9DQoN
CiAgICBpZihXU1RPUFNJRyhzdGF0dXMpICE9IFNJR1RSQVApIHsNCglmcHJp
bnRmKHN0ZGVyciwgIkZhaWx1cmUgYXR0ZW1wdGluZyB0byBoaXQgbWFpbi5c
biIpOw0KCWZwcmludGYoc3RkZXJyLCAiRGlkIG5vdCBnZXQgU0lHVFJBUCwg
Z290OiAlZC5cbiIsIFdTVE9QU0lHKHN0YXR1cykpOw0KCWZwcmludGYoc3Rk
ZXJyLCAiQ3VycmVudCBQQyBpczogMHgleC5cbiIsIHJlYWRQQyhwaWQpKTsN
CglleGl0KDEpOw0KICAgIH0NCg0KICAgIC8qIE1ha2Ugc3VyZSB3ZSBzdG9w
cGVkIG9uIHRoZSBicmVha3BvaW50LiAqLw0KICAgIGlmKGFkanVzdEZvckJw
KHBpZCwgcmVhZFBDKHBpZCkpICE9ICh1aW50MzJfdCltYWluKSB7DQoJZmFp
bHVyZSgiRGlkIG5vdCBzdG9wIG9uIG1haW4uXG4iKTsNCiAgICB9DQoNCiAg
ICAvKiBSZW1vdmUgYnJlYWtwb2ludCBvbiBtYWluLiAqLw0KICAgIGlmKHN3
YXBNZW1vcnkocGlkLCAodWludDMyX3QpbWFpbiwgQlJFQUtQT0lOVF9TSVpF
LA0KCQkgIGluc3QsICZ0ZW1wKSAhPSBTVUNDRVNTKQ0KCWZhaWx1cmUoIkZh
aWxlZCB0byByZW1vdmUgYnJlYWtwb2ludCBvbiBtYWluLlxuIik7DQoNCiAg
ICBmb3IoaT0wOyBpPElURVJBVElPTlM7ICsraSkgew0KCS8qIFNldCBicmVh
a3BvaW50IG9uIGRvU29tZXRoaW5nRnVuYy4gKi8NCglpZihzd2FwTWVtb3J5
KHBpZCwgKHVpbnQzMl90KWRvU29tZXRoaW5nRnVuYywgQlJFQUtQT0lOVF9T
SVpFLA0KCQkgICAgICBCUkVBS1BPSU5UX0lOU1RSVUNUSU9OLCAmaW5zdCkg
IT0gU1VDQ0VTUykNCgkgICAgZmFpbHVyZSgiRmFpbGVkIHRvIGluc3RhbGwg
YnJlYWtwb2ludCBvbiBkb1NvbWV0aGluZ0Z1bmMuXG4iKTsNCg0KCS8qIFJl
c3VtZSBwcm9jZXNzLiAqLw0KCXB0cmFjZShQVFJBQ0VfU1lTQ0FMTCwgcGlk
LCAwLCAwKTsNCg0KCS8qIFdhaXQgZm9yIHByb2Nlc3MgdG8gaGl0IGJyZWFr
cG9pbnQsIHdlIHdpbGwgZ2V0IGEgU0lHVFJBUA0KCSAqIG5vdGlmaWNhdGlv
bi4gKi8NCglyZXQgPSB3YWl0cGlkKHBpZCwgJnN0YXR1cywgMCk7DQoNCglp
ZighV0lGU1RPUFBFRChzdGF0dXMpIHx8IChXU1RPUFNJRyhzdGF0dXMpICE9
IFNJR1RSQVApKQ0KCSAgICBmYWlsdXJlKCJEaWQgbm90IGdldCBleHBlY3Rl
ZCBTSUdUUkFQIGZvciBoaXR0aW5nIGJyZWFrcG9pbnQuXG4iKTsNCg0KCWlm
KCFXSUZTVE9QUEVEKHN0YXR1cykpIHsNCgkgICAgZmFpbHVyZSgiU3RhdHVz
IGluZGljYXRlcyB0aGF0IHByb2Nlc3MgaXMgbm90IHN0b3BwZWQuXG4iKTsN
Cgl9DQoNCglpZihXU1RPUFNJRyhzdGF0dXMpICE9IFNJR1RSQVApIHsNCgkg
ICAgZnByaW50ZihzdGRlcnIsICJGYWlsdXJlIGF0dGVtcHRpbmcgdG8gaGl0
IGRvU29tZXRoaW5nRnVuYy5cbiIpOw0KCSAgICBmcHJpbnRmKHN0ZGVyciwg
IkRpZCBub3QgZ2V0IGV4cGVjdGVkIFNJR1RSQVAsIGdvdDogJWQuXG4iLCBX
U1RPUFNJRyhzdGF0dXMpKTsNCgkgICAgZnByaW50ZihzdGRlcnIsICJDdXJy
ZW50IFBDIGlzOiAweCV4LlxuIiwgcmVhZFBDKHBpZCkpOw0KCSAgICBleGl0
KDEpOw0KCX0NCg0KCS8qIE1ha2Ugc3VyZSB3ZSBzdG9wcGVkIG9uIHRoZSBi
cmVha3BvaW50LiAqLw0KCWlmKGFkanVzdEZvckJwKHBpZCwgcmVhZFBDKHBp
ZCkpICE9ICh1aW50MzJfdClkb1NvbWV0aGluZ0Z1bmMpIHsNCgkgICAgZnBy
aW50ZihzdGRlcnIsICJQQyBpcyBub3QgMHgleCwgaXQgaXM6IDB4JXguXG4i
LCAodWludDMyX3QpZG9Tb21ldGhpbmdGdW5jLA0KCQkgICAgcmVhZFBDKHBp
ZCkpOw0KCSAgICBmYWlsdXJlKCJEaWQgbm90IHN0b3Agb24gZG9Tb21ldGhp
bmdGdW5jLlxuIik7DQoJfQ0KDQoJLyogUmVtb3ZlIGJyZWFrcG9pbnQgb24g
ZG9Tb21ldGhpbmdGdW5jLiAqLw0KCWlmKHN3YXBNZW1vcnkocGlkLCAodWlu
dDMyX3QpZG9Tb21ldGhpbmdGdW5jLCBCUkVBS1BPSU5UX1NJWkUsDQoJCSAg
ICAgIGluc3QsICZ0ZW1wKSAhPSBTVUNDRVNTKQ0KCSAgICBmYWlsdXJlKCJG
YWlsZWQgdG8gcmVtb3ZlIGJyZWFrcG9pbnQgb24gZG9Tb21ldGhpbmdGdW5j
LlxuIik7DQoNCg0KCS8qIFNldCBicmVha3BvaW50IG9uIGRvU29tZXRoaW5n
RWxzZUZ1bmMuICovDQoJaWYoc3dhcE1lbW9yeShwaWQsICh1aW50MzJfdClk
b1NvbWV0aGluZ0Vsc2VGdW5jLCBCUkVBS1BPSU5UX1NJWkUsDQoJCSAgICAg
IEJSRUFLUE9JTlRfSU5TVFJVQ1RJT04sICZpbnN0KSAhPSBTVUNDRVNTKQ0K
CSAgICBmYWlsdXJlKCJGYWlsZWQgdG8gaW5zdGFsbCBicmVha3BvaW50IG9u
IGRvU29tZXRoaW5nRWxzZUZ1bmMuXG4iKTsNCg0KCS8qIFJlc3VtZSBwcm9j
ZXNzLiAqLw0KCXB0cmFjZShQVFJBQ0VfQ09OVCwgcGlkLCAwLCAwKTsNCg0K
CS8qIFdhaXQgZm9yIHByb2Nlc3MgdG8gaGl0IGJyZWFrcG9pbnQsIHdlIHdp
bGwgZ2V0IGEgU0lHVFJBUA0KCSAqIG5vdGlmaWNhdGlvbi4gKi8NCglyZXQg
PSB3YWl0cGlkKHBpZCwgJnN0YXR1cywgMCk7DQoNCglpZihyZXQgIT0gcGlk
KSB7DQoJICAgIGZhaWx1cmUoIlJldHVybiBmcm9tIHdhaXRwaWQgaW5kaWNh
dGVzIGVycm9yIG9yIHRoYXQgcHJvY2VzcyBpcyBzdGlsbCBydW5uaW5nLlxu
Iik7DQoJfQ0KDQoJaWYoIVdJRlNUT1BQRUQoc3RhdHVzKSkgew0KCSAgICBm
YWlsdXJlKCJTdGF0dXMgaW5kaWNhdGVzIHRoYXQgcHJvY2VzcyBpcyBub3Qg
c3RvcHBlZC5cbiIpOw0KCX0NCg0KCWlmKFdTVE9QU0lHKHN0YXR1cykgIT0g
U0lHVFJBUCkgew0KCSAgICBmcHJpbnRmKHN0ZGVyciwgIkZhaWx1cmUgYXR0
ZW1wdGluZyB0byBoaXQgZG9Tb21ldGhpbmdFbHNlRnVuYy5cbiIpOw0KCSAg
ICBmcHJpbnRmKHN0ZGVyciwgIkRpZCBub3QgZ2V0IGV4cGVjdGVkIFNJR1RS
QVAsIGdvdDogJWQuXG4iLCBXU1RPUFNJRyhzdGF0dXMpKTsNCgkgICAgZnBy
aW50ZihzdGRlcnIsICJDdXJyZW50IFBDIGlzOiAweCV4LlxuIiwgcmVhZFBD
KHBpZCkpOw0KCSAgICBleGl0KDEpOw0KCX0NCg0KCS8qIE1ha2Ugc3VyZSB3
ZSBzdG9wcGVkIG9uIHRoZSBicmVha3BvaW50LiAqLw0KCWlmKGFkanVzdEZv
ckJwKHBpZCwgcmVhZFBDKHBpZCkpICE9ICh1aW50MzJfdClkb1NvbWV0aGlu
Z0Vsc2VGdW5jKSB7DQoJICAgIGZwcmludGYoc3RkZXJyLCAiUEMgaXMgbm90
IDB4JXgsIGl0IGlzOiAweCV4LlxuIiwgKHVpbnQzMl90KWRvU29tZXRoaW5n
RWxzZUZ1bmMsDQoJCSAgICByZWFkUEMocGlkKSk7DQoJICAgIGZhaWx1cmUo
IkRpZCBub3Qgc3RvcCBvbiBkb1NvbWV0aGluZ0Vsc2VGdW5jLlxuIik7DQoJ
fQ0KDQoJLyogUmVtb3ZlIGJyZWFrcG9pbnQgb24gZG9Tb21ldGhpbmdFbHNl
RnVuYy4gKi8NCglpZihzd2FwTWVtb3J5KHBpZCwgKHVpbnQzMl90KWRvU29t
ZXRoaW5nRWxzZUZ1bmMsIEJSRUFLUE9JTlRfU0laRSwNCgkJICAgICAgaW5z
dCwgJnRlbXApICE9IFNVQ0NFU1MpDQoJICAgIGZhaWx1cmUoIkZhaWxlZCB0
byByZW1vdmUgYnJlYWtwb2ludCBvbiBkb1NvbWV0aGluZ0Vsc2VGdW5jLlxu
Iik7DQogICAgfQ0KDQogICAgLyogUmVzdW1lIHByb2Nlc3MgdG8gbGV0IGl0
IGNvbXBsZXRlLiAqLw0KICAgIHB0cmFjZShQVFJBQ0VfQ09OVCwgcGlkLCAw
LCAwKTsNCg0KICAgIHJldCA9IHdhaXRwaWQocGlkLCAmc3RhdHVzLCAwKTsN
Cg0KICAgIGlmKCFXSUZFWElURUQoc3RhdHVzKSkgew0KCWZhaWx1cmUoIkRl
YnVnZ2VkIHByb2dyYW0gZmFpbGVkIHRvIGV4aXQgYXQgZXhwZWN0ZWQgdGlt
ZS5cbiIpOw0KICAgIH0NCg0KICAgIHByaW50ZigicGFyZW50UHJvY2Vzczog
U2hvdWxkIGhhdmUgaGl0IGFsbCBicCdzLCBjaGlsZCBzaG91bGQgaGF2ZSBl
eGl0ZWQuXG4iKTsNCn0NCg==
--1136671902-820035827-1073961297=:1969
Content-Type: TEXT/PLAIN; charset=US-ASCII; name=Makefile
Content-Transfer-Encoding: BASE64
Content-ID: <Pine.LNX.4.44.0401121834571.1969@zcar.ghs.com>
Content-Description: 
Content-Disposition: attachment; filename=Makefile

Q0NfTUFMVEFfRUI9L2hvbWUvemNhcjEvb3B0L2hhcmRoYXQvcHJldmlld2tp
dC9taXBzL2ZwX2JlL2Jpbi9taXBzX2ZwX2JlLWdjYw0KTUFMVEFfREVGSU5F
Uz0tRFRBUkdFVF9BUkNIPU1JUFMNCg0KDQpEQkxJTks9ZGJsaW5rIC0tc2Nh
bl9zb3VyY2UgLWF1dG9fdHJhbnNsYXRlIA0KDQpDRkxBR1M9LWcgLVdhbGwN
Cg0KDQoNClRBUkdFVFM9c2ltcGxlZGVidWdnZXJfbWFsdGFfZWINCg0KYWxs
OiAkKFRBUkdFVFMpDQoNCnNpbXBsZWRlYnVnZ2VyX21hbHRhX2ViOiBzaW1w
bGVkZWJ1Z2dlci5jDQoJJChDQ19NQUxUQV9FQikgJChNQUxUQV9ERUZJTkVT
KSAkKENGTEFHUykgLW8gJEAgJDwNCgkkKERCTElOSykgJEANCg0KY2xlYW46
DQoJcm0gLXJmICp+IGNvcmUqICoubyBvYmpzDQoNCmNsb2JiZXI6IGNsZWFu
DQoJcm0gLWYgJChUQVJHRVRTKSAkKFRBUkdFVFMpLioNCg==
--1136671902-820035827-1073961297=:1969--

From macro@ds2.pg.gda.pl Tue Jan 13 06:08:14 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 13 Jan 2004 06:08:16 +0000 (GMT)
Received: from jurand.ds.pg.gda.pl ([IPv6:::ffff:153.19.208.2]:36262 "EHLO
	jurand.ds.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8224858AbUAMGIO>; Tue, 13 Jan 2004 06:08:14 +0000
Received: by jurand.ds.pg.gda.pl (Postfix, from userid 1011)
	id CFAE54C3A9; Mon, 12 Jan 2004 13:51:55 +0100 (CET)
Received: from localhost (localhost [127.0.0.1])
	by jurand.ds.pg.gda.pl (Postfix) with ESMTP
	id BF42847B90; Mon, 12 Jan 2004 13:51:55 +0100 (CET)
Date: Mon, 12 Jan 2004 13:51:55 +0100 (CET)
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To: =?iso-8859-1?q?karthikeyan=20natarajan?= <karthik_96cse@yahoo.com>
Cc: linux-mips@linux-mips.org
Subject: Re: How to configure the cache size in r4000
In-Reply-To: <20040111124828.71884.qmail@web10103.mail.yahoo.com>
Message-ID: <Pine.LNX.4.55.0401121345490.21851@jurand.ds.pg.gda.pl>
References: <20040111124828.71884.qmail@web10103.mail.yahoo.com>
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: 3907
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
Content-Length: 776
Lines: 17

On Sun, 11 Jan 2004, [iso-8859-1] karthikeyan natarajan wrote:

>     The cache size is modified by setting the IC/DC
> bits in the 'config' register. Seems they are set only
> by the hardware during the processor reset. And also,
> those bits are mentioned as read only bits..

 You cannot modify the size of the primary caches -- the values are
hardwired to the amount of cache available in the processor (8kB+8kB for
the original R4000).  However, if you take appropriate precautions, you
can alter the line sizes of the caches by modifying appropriate bits of
cp0.config.

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

From brederlo@informatik.uni-tuebingen.de Tue Jan 13 11:28:50 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 13 Jan 2004 11:28:51 +0000 (GMT)
Received: from mx5.Informatik.Uni-Tuebingen.De ([IPv6:::ffff:134.2.12.32]:4038
	"EHLO mx5.informatik.uni-tuebingen.de") by linux-mips.org with ESMTP
	id <S8225294AbUAML2u>; Tue, 13 Jan 2004 11:28:50 +0000
Received: from localhost (loopback [127.0.0.1])
	by mx5.informatik.uni-tuebingen.de (Postfix) with ESMTP id C418F133
	for <linux-mips@linux-mips.org>; Tue, 13 Jan 2004 12:28:44 +0100 (NFT)
Received: from mx5.informatik.uni-tuebingen.de ([127.0.0.1])
 by localhost (mx5 [127.0.0.1]) (amavisd-new, port 10024) with ESMTP
 id 29886-05 for <linux-mips@linux-mips.org>;
 Tue, 13 Jan 2004 12:28:43 +0100 (NFT)
Received: from dual (semeai.Informatik.Uni-Tuebingen.De [134.2.15.66])
	by mx5.informatik.uni-tuebingen.de (Postfix) with ESMTP id D7C33121
	for <linux-mips@linux-mips.org>; Tue, 13 Jan 2004 12:28:42 +0100 (NFT)
Received: from mrvn by dual with local (Exim 3.36 #1 (Debian))
	id 1AgMio-0005UW-00
	for <linux-mips@linux-mips.org>; Tue, 13 Jan 2004 12:28:34 +0100
To: linux-mips@linux-mips.org
Subject: Patch for MyCable XXS1500 for 2.4.24-pre1
From: Goswin von Brederlow <brederlo@informatik.uni-tuebingen.de>
Date: 13 Jan 2004 12:28:34 +0100
Message-ID: <878ykcm6jh.fsf@mrvn.homelinux.org>
User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Reasonable Discussion)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Virus-Scanned: by amavisd-new (McAfee AntiVirus) at informatik.uni-tuebingen.de
Return-Path: <brederlo@informatik.uni-tuebingen.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: 3909
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: brederlo@informatik.uni-tuebingen.de
Precedence: bulk
X-list: linux-mips
Content-Length: 1084
Lines: 25

Hi,

I found a minor flaw in 2.4.24-pre1 for my X-Mas present.
In 2.4.21 there where two more boards present then in
2.4.24-pre1:
#define MACH_XXS1500            6       /* Au1500-based eval board */
#define MACH_MTX1               7       /* 4G MTX-1 Au1500-based board */

I have an XXS1500 and can confirm that the kernel compiles and works
with the patch below.

MfG
        Goswin
----------------------------------------------------------------------
mips:/usr/src# diff -Nurd linux-2.4.24-pre1-cvs/include/asm/bootinfo.h.old linux-2.4.24-pre1-cvs/include/asm/bootinfo.h
--- linux-2.4.24-pre1-cvs/include/asm/bootinfo.h.old    Tue Jan 13 12:24:27 2004
+++ linux-2.4.24-pre1-cvs/include/asm/bootinfo.h        Tue Jan 13 12:24:44 2004
@@ -176,6 +176,7 @@
 #define MACH_DB1000            3       /* Au1000-based eval board */
 #define MACH_DB1100            4       /* Au1100-based eval board */
 #define MACH_DB1500            5       /* Au1500-based eval board */
+#define MACH_XXS1500            6       /* MyCable XSS1500 board */
 
 /*
  * Valid machtype for group NEC_VR41XX

From brederlo@informatik.uni-tuebingen.de Tue Jan 13 12:29:23 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 13 Jan 2004 12:29:24 +0000 (GMT)
Received: from mx5.Informatik.Uni-Tuebingen.De ([IPv6:::ffff:134.2.12.32]:18887
	"EHLO mx5.informatik.uni-tuebingen.de") by linux-mips.org with ESMTP
	id <S8224941AbUAMM3X>; Tue, 13 Jan 2004 12:29:23 +0000
Received: from localhost (loopback [127.0.0.1])
	by mx5.informatik.uni-tuebingen.de (Postfix) with ESMTP id 9156A121
	for <linux-mips@linux-mips.org>; Tue, 13 Jan 2004 13:29:17 +0100 (NFT)
Received: from mx3.informatik.uni-tuebingen.de ([134.2.12.26])
 by localhost (mx5 [134.2.12.32]) (amavisd-new, port 10024) with ESMTP
 id 30934-03 for <linux-mips@linux-mips.org>;
 Tue, 13 Jan 2004 13:29:16 +0100 (NFT)
Received: from dual (semeai [134.2.15.66])
	by mx3.informatik.uni-tuebingen.de (Postfix) with ESMTP id 6490A134
	for <linux-mips@linux-mips.org>; Tue, 13 Jan 2004 13:29:15 +0100 (NFT)
Received: from mrvn by dual with local (Exim 3.36 #1 (Debian))
	id 1AgNfP-0005bL-00
	for <linux-mips@linux-mips.org>; Tue, 13 Jan 2004 13:29:07 +0100
To: linux-mips@linux-mips.org
Subject: Test and hello
From: Goswin von Brederlow <brederlo@informatik.uni-tuebingen.de>
Date: 13 Jan 2004 13:29:06 +0100
Message-ID: <87y8sckp65.fsf@mrvn.homelinux.org>
User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Reasonable Discussion)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Virus-Scanned: by amavisd-new (McAfee AntiVirus) at informatik.uni-tuebingen.de
Return-Path: <brederlo@informatik.uni-tuebingen.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: 3910
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: brederlo@informatik.uni-tuebingen.de
Precedence: bulk
X-list: linux-mips
Content-Length: 57
Lines: 6

Hi,

test, test, can anyone read me?

MfG
        Goswin

From macro@ds2.pg.gda.pl Tue Jan 13 13:07:58 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 13 Jan 2004 13:07:59 +0000 (GMT)
Received: from jurand.ds.pg.gda.pl ([IPv6:::ffff:153.19.208.2]:45488 "EHLO
	jurand.ds.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8224941AbUAMNH6>; Tue, 13 Jan 2004 13:07:58 +0000
Received: by jurand.ds.pg.gda.pl (Postfix, from userid 1011)
	id 3AC474C175; Tue, 13 Jan 2004 14:07:54 +0100 (CET)
Received: from localhost (localhost [127.0.0.1])
	by jurand.ds.pg.gda.pl (Postfix) with ESMTP
	id 2CFF0129A; Tue, 13 Jan 2004 14:07:54 +0100 (CET)
Date: Tue, 13 Jan 2004 14:07:54 +0100 (CET)
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To: Ralf Baechle <ralf@linux-mips.org>
Cc: Adrian Bunk <bunk@fs.tum.de>, linux-mips@linux-mips.org,
	linux-kernel@vger.kernel.org
Subject: Re: [2.6 patch] fix DECSTATION depends
In-Reply-To: <20040113022826.GC1646@linux-mips.org>
Message-ID: <Pine.LNX.4.55.0401131401300.21962@jurand.ds.pg.gda.pl>
References: <20040113015202.GE9677@fs.tum.de> <20040113022826.GC1646@linux-mips.org>
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: 3911
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
Content-Length: 667
Lines: 20

On Tue, 13 Jan 2004, Ralf Baechle wrote:

> > it seems the following is required in Linus' tree to get correct depends 
> > for DECSTATION:
> 
> Thanks,  applied.

 The dependency was intentional: stable for 32-bit, experimental for
64-bit.  I'm reverting the change immediately.  Please always contact me
before applying non-obvious changes for the DECstation.

 If there's anything wrong with the depends, it should be fixed elsewhere.  
Details, please.

  Maciej

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

From drow@crack.them.org Tue Jan 13 15:01:12 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 13 Jan 2004 15:01:13 +0000 (GMT)
Received: from nevyn.them.org ([IPv6:::ffff:66.93.172.17]:49332 "EHLO
	nevyn.them.org") by linux-mips.org with ESMTP id <S8225315AbUAMPBM>;
	Tue, 13 Jan 2004 15:01:12 +0000
Received: from drow by nevyn.them.org with local (Exim 4.30 #1 (Debian))
	id 1AgQ2W-0000Zh-Pn; Tue, 13 Jan 2004 10:01:08 -0500
Date: Tue, 13 Jan 2004 10:01:08 -0500
From: Daniel Jacobowitz <dan@debian.org>
To: Nathan Field <ndf@ghs.com>
Cc: linux-mips@linux-mips.org
Subject: Re: ptrace induced instruction cache bug?
Message-ID: <20040113150108.GA7144@nevyn.them.org>
References: <Pine.LNX.4.44.0401121806240.1969-300000@zcar.ghs.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Pine.LNX.4.44.0401121806240.1969-300000@zcar.ghs.com>
User-Agent: Mutt/1.5.1i
Return-Path: <drow@crack.them.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: 3912
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: dan@debian.org
Precedence: bulk
X-list: linux-mips
Content-Length: 2299
Lines: 41

On Mon, Jan 12, 2004 at 06:34:57PM -0800, Nathan Field wrote:
> I'm writing a debugger that uses the Linux ptrace API for process control
> and I think I've found a bug in ptrace in MIPS Linux. The specific
> situation that breaks horribly with my debugger is quite complex, so I
> wrote a little testbed to show the problem. The code and a sample Makefile
> are attached. You can build the example for x86 or MIPS. I have some
> things in there for PPC but I haven't ported it fully yet. Basically the
> problem seems to be that writing a breakpoint (instruction 0xd), running 
> to the breakpoint, replacing the breakpoint with the original instruction 
> and then resuming sometimes results in the process halting on the same 
> address, even though there isn't a breakpoint there anymore. If you resume 
> again, or wait for a "while" after removing the breakpoint everything 
> works fine. I believe the problem is probably linked to some sort of 
> problem with the kernel not flushing the instruction cache, but that's 
> just a guess.

It sounds reasonable.  I've encountered this problem in the past also,
but never with the Pro 2.1 / MIPS release which is what you're using. 
I don't see anything obviously wrong with your test code, either.

> I'd guess that this problem has been fixed in later versions of the 
> kernel. If anyone can point me to a 2.4 release with this fixed I'd like 
> to know about it. I tried building the cvs checkout but the build failed. 
> It looks like I'll need a newer toolchain than the one I got from 
> MontaVista[1].
> 
> I'm using a stock MontaVista distribution for the MIPS Malta 4Kc in big
> endian mode, downloaded from their site a couple of days ago. I recompiled
> the kernel with the arch/mips/configs/defconfig-malta, but haven't changed 
> any options yet. Since that could be hard to classify here are some 
> details about my system:

Yes, you will need a newer toolchain.  Honestly, I'm baffled as to why
a Pro 2.1 toolchain was available from our web site at all, unless you
got it via an old product subscription... it should have been Pro 3.0,
which uses GCC 3.2 and a more recent binutils.  But I don't have any
control over these things :)

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

From yuasa@hh.iij4u.or.jp Tue Jan 13 15:57:24 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 13 Jan 2004 15:57:28 +0000 (GMT)
Received: from mo02.iij4u.or.jp ([IPv6:::ffff:210.130.0.19]:5582 "EHLO
	mo02.iij4u.or.jp") by linux-mips.org with ESMTP id <S8225545AbUAMP5X>;
	Tue, 13 Jan 2004 15:57:23 +0000
Received: from mdo01.iij4u.or.jp (mdo01.iij4u.or.jp [210.130.0.171])
	by mo02.iij4u.or.jp (8.8.8/MFO1.5) with ESMTP id AAA13386;
	Wed, 14 Jan 2004 00:57:18 +0900 (JST)
Received: 4UMDO01 id i0DFvI623510; Wed, 14 Jan 2004 00:57:18 +0900 (JST)
Received: 4UMRO00 id i0DFvHV01273; Wed, 14 Jan 2004 00:57:17 +0900 (JST)
	from stratos.frog (64.43.138.210.xn.2iij.net [210.138.43.64]) (authenticated)
Date: Wed, 14 Jan 2004 00:57:13 +0900
From: Yoichi Yuasa <yuasa@hh.iij4u.or.jp>
To: Ralf Baechle <ralf@linux-mips.org>
Cc: yuasa@hh.iij4u.or.jp, linux-mips <linux-mips@linux-mips.org>
Subject: [PATCH][2.4] Update NEC VRC4171's base  functions for VR4100 series
Message-Id: <20040114005713.492b2aa0.yuasa@hh.iij4u.or.jp>
X-Mailer: Sylpheed version 0.9.8a (GTK+ 1.2.10; i686-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Return-Path: <yuasa@hh.iij4u.or.jp>
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: 3913
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: yuasa@hh.iij4u.or.jp
Precedence: bulk
X-list: linux-mips
Content-Length: 6087
Lines: 196

Hello Ralf,

I updated the patch for VRC4171's base functions.
The VRC4171 is companion chip for NEC VR4111 and VR4121.

This patch exists for linux_2_4 tag of linux-mips.org CVS.
Please apply this patch.

Yoichi

diff -urN -X dontdiff linux-orig/arch/mips/config-shared.in linux/arch/mips/config-shared.in
--- linux-orig/arch/mips/config-shared.in	Sun Jan 11 10:17:13 2004
+++ linux/arch/mips/config-shared.in	Tue Jan 13 23:04:31 2004
@@ -56,6 +56,9 @@
 bool 'Support for Globespan IVR board' CONFIG_MIPS_IVR
 bool 'Support for Hewlett Packard LaserJet board' CONFIG_HP_LASERJET
 bool 'Support for IBM WorkPad z50' CONFIG_IBM_WORKPAD
+if [ "$CONFIG_IBM_WORKPAD" = "y" ]; then
+   tristate '  NEC VRC4171 support' CONFIG_VRC4171
+fi
 bool 'Support for LASAT Networks platforms' CONFIG_LASAT
 if [ "$CONFIG_LASAT" = "y" ]; then
    tristate '  PICVUE LCD display driver' CONFIG_PICVUE
diff -urN -X dontdiff linux-orig/arch/mips/vr41xx/common/Makefile linux/arch/mips/vr41xx/common/Makefile
--- linux-orig/arch/mips/vr41xx/common/Makefile	Wed Dec  3 01:37:03 2003
+++ linux/arch/mips/vr41xx/common/Makefile	Tue Jan 13 23:04:31 2004
@@ -14,10 +14,11 @@
 
 obj-y := bcu.o cmu.o giu.o icu.o int-handler.o ksyms.o reset.o rtc.o
 
-export-objs := ksyms.o vrc4173.o
+export-objs := ksyms.o vrc4171.o vrc4173.o
 
 obj-$(CONFIG_PCI)		+= pciu.o
 obj-$(CONFIG_SERIAL)		+= serial.o
+obj-$(CONFIG_VRC4171)		+= vrc4171.o
 obj-$(CONFIG_VRC4173)		+= vrc4173.o
 obj-$(subst m,y,$(CONFIG_IDE))	+= ide.o
 
diff -urN -X dontdiff linux-orig/arch/mips/vr41xx/common/vrc4171.c linux/arch/mips/vr41xx/common/vrc4171.c
--- linux-orig/arch/mips/vr41xx/common/vrc4171.c	Thu Jan  1 09:00:00 1970
+++ linux/arch/mips/vr41xx/common/vrc4171.c	Tue Jan 13 23:04:31 2004
@@ -0,0 +1,106 @@
+/*
+ *  vrc4171.c, NEC VRC4171 base driver.
+ *
+ *  Copyright (C) 2003  Yoichi Yuasa <yuasa@hh.iij4u.or.jp>
+ *
+ *  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.
+ *
+ *  This program is distributed in the hope that it will be useful,
+ *  but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *  GNU General Public License for more details.
+ *
+ *  You should have received a copy of the GNU General Public License
+ *  along with this program; if not, write to the Free Software
+ *  Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
+ */
+#include <linux/init.h>
+#include <linux/ioport.h>
+#include <linux/module.h>
+#include <linux/types.h>
+
+#include <asm/io.h>
+#include <asm/vr41xx/vrc4171.h>
+
+MODULE_DESCRIPTION("NEC VRC4171 base driver");
+MODULE_AUTHOR("Yoichi Yuasa <yuasa@hh.iij4u.or.jp>");
+MODULE_LICENSE("GPL");
+
+EXPORT_SYMBOL_GPL(vrc4171_get_irq_status);
+EXPORT_SYMBOL_GPL(vrc4171_set_multifunction_pin);
+
+#define CONFIGURATION1		0x05fe
+ #define SLOTB_CONFIG		0xc000
+ #define SLOTB_NONE		0x0000
+ #define SLOTB_PCCARD		0x4000
+ #define SLOTB_CF		0x8000
+ #define SLOTB_FLASHROM		0xc000
+
+#define CONFIGURATION2		0x05fc
+#define INTERRUPT_STATUS	0x05fa
+#define PCS_CONTROL		0x05ee
+#define GPIO_DATA		PCS_CONTROL
+#define PCS0_UPPER_START	0x05ec
+#define PCS0_LOWER_START	0x05ea
+#define PCS0_UPPER_STOP		0x05e8
+#define PCS0_LOWER_STOP		0x05e6
+#define PCS1_UPPER_START	0x05e4
+#define PCS1_LOWER_START	0x05e2
+#define PCS1_UPPER_STOP		0x05de
+#define PCS1_LOWER_STOP		0x05dc
+
+#define VRC4171_REGS_BASE	PCS1_LOWER_STOP
+#define VRC4171_REGS_SIZE	0x24
+
+uint16_t vrc4171_get_irq_status(void)
+{
+	return inw(INTERRUPT_STATUS);
+}
+
+void vrc4171_set_multifunction_pin(int config)
+{
+	uint16_t config1;
+
+	config1 = inw(CONFIGURATION1);
+	config1 &= ~SLOTB_CONFIG;
+
+	switch (config) {
+	case SLOTB_IS_NONE:
+		config1 |= SLOTB_NONE;
+		break;
+	case SLOTB_IS_PCCARD:
+		config1 |= SLOTB_PCCARD;
+		break;
+	case SLOTB_IS_CF:
+		config1 |= SLOTB_CF;
+		break;
+	case SLOTB_IS_FLASHROM:
+		config1 |= SLOTB_FLASHROM;
+		break;
+	default:
+		break;
+	}
+
+	outw(config1, CONFIGURATION1);
+}
+
+static int __devinit vrc4171_init(void)
+{
+	if (request_region(VRC4171_REGS_BASE, VRC4171_REGS_SIZE, "NEC VRC4171") == NULL)
+		return -EBUSY;
+
+	printk(KERN_INFO "NEC VRC4171 base driver\n");
+
+	return 0;
+}
+
+static void __devexit vrc4171_exit(void)
+{
+	release_region(VRC4171_REGS_BASE, VRC4171_REGS_SIZE);
+}
+
+module_init(vrc4171_init);
+module_exit(vrc4171_exit);
diff -urN -X dontdiff linux-orig/include/asm-mips/vr41xx/vrc4171.h linux/include/asm-mips/vr41xx/vrc4171.h
--- linux-orig/include/asm-mips/vr41xx/vrc4171.h	Thu Jan  1 09:00:00 1970
+++ linux/include/asm-mips/vr41xx/vrc4171.h	Tue Jan 13 23:04:31 2004
@@ -0,0 +1,43 @@
+/*
+ *  vrc4171.h, Include file for NEC VRC4171.
+ *
+ *  Copyright (C) 2003  Yoichi Yuasa <yuasa@hh.iij4u.or.jp>
+ *
+ *  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.
+ *
+ *  This program is distributed in the hope that it will be useful,
+ *  but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *  GNU General Public License for more details.
+ *
+ *  You should have received a copy of the GNU General Public License
+ *  along with this program; if not, write to the Free Software
+ *  Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
+ */
+#ifndef __NEC_VRC4171_H 
+#define __NEC_VRC4171_H 
+
+/*
+ * Configuration 1
+ */
+enum {
+	SLOTB_IS_NONE,       
+	SLOTB_IS_PCCARD,
+	SLOTB_IS_CF,
+	SLOTB_IS_FLASHROM
+};
+
+extern void vrc4171_set_multifunction_pin(int config);
+
+/*
+ * Interrupt Status Mask
+ */
+#define IRQ_A	0x02
+#define IRQ_B	0x04
+
+extern uint16_t vrc4171_get_irq_status(void);
+
+#endif /* __NEC_VRC4171_H */

From yuasa@hh.iij4u.or.jp Tue Jan 13 15:58:57 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 13 Jan 2004 15:59:01 +0000 (GMT)
Received: from mo03.iij4u.or.jp ([IPv6:::ffff:210.130.0.20]:11220 "EHLO
	mo03.iij4u.or.jp") by linux-mips.org with ESMTP id <S8225545AbUAMP65>;
	Tue, 13 Jan 2004 15:58:57 +0000
Received: from mdo00.iij4u.or.jp (mdo00.iij4u.or.jp [210.130.0.170])
	by mo03.iij4u.or.jp (8.8.8/MFO1.5) with ESMTP id AAA18226;
	Wed, 14 Jan 2004 00:58:51 +0900 (JST)
Received: 4UMDO00 id i0DFwp916363; Wed, 14 Jan 2004 00:58:51 +0900 (JST)
Received: 4UMRO00 id i0DFwoV01362; Wed, 14 Jan 2004 00:58:50 +0900 (JST)
	from stratos.frog (64.43.138.210.xn.2iij.net [210.138.43.64]) (authenticated)
Date: Wed, 14 Jan 2004 00:58:46 +0900
From: Yoichi Yuasa <yuasa@hh.iij4u.or.jp>
To: Ralf Baechle <ralf@linux-mips.org>
Cc: yuasa@hh.iij4u.or.jp, linux-mips <linux-mips@linux-mips.org>
Subject: [PATCH][2.6] Update NEC VRC4171's base  functions for VR4100 series
Message-Id: <20040114005846.739bf5f8.yuasa@hh.iij4u.or.jp>
X-Mailer: Sylpheed version 0.9.8a (GTK+ 1.2.10; i686-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Return-Path: <yuasa@hh.iij4u.or.jp>
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: 3914
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: yuasa@hh.iij4u.or.jp
Precedence: bulk
X-list: linux-mips
Content-Length: 5763
Lines: 191

Hello Ralf,

I updated the patch for VRC4171's base functions.

This patch exists for HEAD of linux-mips.org CVS.
Please apply this patch.

Yoichi

diff -urN -X dontdiff linux-orig/arch/mips/Kconfig linux/arch/mips/Kconfig
--- linux-orig/arch/mips/Kconfig	Tue Jan 13 22:22:15 2004
+++ linux/arch/mips/Kconfig	Tue Jan 13 23:07:34 2004
@@ -743,6 +743,10 @@
 	depends on ZAO_CAPCELLA || VICTOR_MPC30X || SIBYTE_SB1xxx_SOC || NEC_EAGLE || NEC_OSPREY || DDB5477 || CASIO_E55 || TANBAC_TB0226 || TANBAC_TB0229
 	default y
 
+config VRC4171
+	tristate "NEC VRC4171 Support"
+	depends on IBM_WORKPAD
+
 config VRC4173
 	tristate "NEC VRC4173 Support"
 	depends on NEC_EAGLE || VICTOR_MPC30X
diff -urN -X dontdiff linux-orig/arch/mips/vr41xx/common/Makefile linux/arch/mips/vr41xx/common/Makefile
--- linux-orig/arch/mips/vr41xx/common/Makefile	Wed Dec  3 01:39:04 2003
+++ linux/arch/mips/vr41xx/common/Makefile	Tue Jan 13 23:07:35 2004
@@ -4,6 +4,7 @@
 
 obj-y				+= bcu.o cmu.o giu.o icu.o int-handler.o ksyms.o reset.o rtc.o
 obj-$(CONFIG_SERIAL_8250)	+= serial.o
+obj-$(CONFIG_VRC4171)		+= vrc4171.o
 obj-$(CONFIG_VRC4173)		+= vrc4173.o
 
 EXTRA_AFLAGS := $(CFLAGS)
diff -urN -X dontdiff linux-orig/arch/mips/vr41xx/common/vrc4171.c linux/arch/mips/vr41xx/common/vrc4171.c
--- linux-orig/arch/mips/vr41xx/common/vrc4171.c	Thu Jan  1 09:00:00 1970
+++ linux/arch/mips/vr41xx/common/vrc4171.c	Tue Jan 13 23:07:35 2004
@@ -0,0 +1,106 @@
+/*
+ *  vrc4171.c, NEC VRC4171 base driver.
+ *
+ *  Copyright (C) 2003  Yoichi Yuasa <yuasa@hh.iij4u.or.jp>
+ *
+ *  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.
+ *
+ *  This program is distributed in the hope that it will be useful,
+ *  but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *  GNU General Public License for more details.
+ *
+ *  You should have received a copy of the GNU General Public License
+ *  along with this program; if not, write to the Free Software
+ *  Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
+ */
+#include <linux/init.h>
+#include <linux/ioport.h>
+#include <linux/module.h>
+#include <linux/types.h>
+
+#include <asm/io.h>
+#include <asm/vr41xx/vrc4171.h>
+
+MODULE_DESCRIPTION("NEC VRC4171 base driver");
+MODULE_AUTHOR("Yoichi Yuasa <yuasa@hh.iij4u.or.jp>");
+MODULE_LICENSE("GPL");
+
+EXPORT_SYMBOL_GPL(vrc4171_get_irq_status);
+EXPORT_SYMBOL_GPL(vrc4171_set_multifunction_pin);
+
+#define CONFIGURATION1		0x05fe
+ #define SLOTB_CONFIG		0xc000
+ #define SLOTB_NONE		0x0000
+ #define SLOTB_PCCARD		0x4000
+ #define SLOTB_CF		0x8000
+ #define SLOTB_FLASHROM		0xc000
+
+#define CONFIGURATION2		0x05fc
+#define INTERRUPT_STATUS	0x05fa
+#define PCS_CONTROL		0x05ee
+#define GPIO_DATA		PCS_CONTROL
+#define PCS0_UPPER_START	0x05ec
+#define PCS0_LOWER_START	0x05ea
+#define PCS0_UPPER_STOP		0x05e8
+#define PCS0_LOWER_STOP		0x05e6
+#define PCS1_UPPER_START	0x05e4
+#define PCS1_LOWER_START	0x05e2
+#define PCS1_UPPER_STOP		0x05de
+#define PCS1_LOWER_STOP		0x05dc
+
+#define VRC4171_REGS_BASE	PCS1_LOWER_STOP
+#define VRC4171_REGS_SIZE	0x24
+
+uint16_t vrc4171_get_irq_status(void)
+{
+	return inw(INTERRUPT_STATUS);
+}
+
+void vrc4171_set_multifunction_pin(int config)
+{
+	uint16_t config1;
+
+	config1 = inw(CONFIGURATION1);
+	config1 &= ~SLOTB_CONFIG;
+
+	switch (config) {
+	case SLOTB_IS_NONE:
+		config1 |= SLOTB_NONE;
+		break;
+	case SLOTB_IS_PCCARD:
+		config1 |= SLOTB_PCCARD;
+		break;
+	case SLOTB_IS_CF:
+		config1 |= SLOTB_CF;
+		break;
+	case SLOTB_IS_FLASHROM:
+		config1 |= SLOTB_FLASHROM;
+		break;
+	default:
+		break;
+	}
+
+	outw(config1, CONFIGURATION1);
+}
+
+static int __devinit vrc4171_init(void)
+{
+	if (request_region(VRC4171_REGS_BASE, VRC4171_REGS_SIZE, "NEC VRC4171") == NULL)
+		return -EBUSY;
+
+	printk(KERN_INFO "NEC VRC4171 base driver\n");
+
+	return 0;
+}
+
+static void __devexit vrc4171_exit(void)
+{
+	release_region(VRC4171_REGS_BASE, VRC4171_REGS_SIZE);
+}
+
+module_init(vrc4171_init);
+module_exit(vrc4171_exit);
diff -urN -X dontdiff linux-orig/include/asm-mips/vr41xx/vrc4171.h linux/include/asm-mips/vr41xx/vrc4171.h
--- linux-orig/include/asm-mips/vr41xx/vrc4171.h	Thu Jan  1 09:00:00 1970
+++ linux/include/asm-mips/vr41xx/vrc4171.h	Tue Jan 13 23:07:35 2004
@@ -0,0 +1,43 @@
+/*
+ *  vrc4171.h, Include file for NEC VRC4171.
+ *
+ *  Copyright (C) 2003  Yoichi Yuasa <yuasa@hh.iij4u.or.jp>
+ *
+ *  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.
+ *
+ *  This program is distributed in the hope that it will be useful,
+ *  but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *  GNU General Public License for more details.
+ *
+ *  You should have received a copy of the GNU General Public License
+ *  along with this program; if not, write to the Free Software
+ *  Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
+ */
+#ifndef __NEC_VRC4171_H 
+#define __NEC_VRC4171_H 
+
+/*
+ * Configuration 1
+ */
+enum {
+	SLOTB_IS_NONE,       
+	SLOTB_IS_PCCARD,
+	SLOTB_IS_CF,
+	SLOTB_IS_FLASHROM
+};
+
+extern void vrc4171_set_multifunction_pin(int config);
+
+/*
+ * Interrupt Status Mask
+ */
+#define IRQ_A	0x02
+#define IRQ_B	0x04
+
+extern uint16_t vrc4171_get_irq_status(void);
+
+#endif /* __NEC_VRC4171_H */

From ralf@linux-mips.org Tue Jan 13 16:35:51 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 13 Jan 2004 16:35:52 +0000 (GMT)
Received: from p508B5C01.dip.t-dialin.net ([IPv6:::ffff:80.139.92.1]:45193
	"EHLO mail.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225315AbUAMQfv>; Tue, 13 Jan 2004 16:35:51 +0000
Received: from fluff.linux-mips.net (fluff.linux-mips.net [127.0.0.1])
	by mail.linux-mips.net (8.12.8/8.12.8) with ESMTP id i0DGZlWI005333;
	Tue, 13 Jan 2004 17:35:47 +0100
Received: (from ralf@localhost)
	by fluff.linux-mips.net (8.12.8/8.12.8/Submit) id i0DGZi3X005332;
	Tue, 13 Jan 2004 17:35:44 +0100
Date: Tue, 13 Jan 2004 17:35:43 +0100
From: Ralf Baechle <ralf@linux-mips.org>
To: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
Cc: karthikeyan natarajan <karthik_96cse@yahoo.com>,
	linux-mips@linux-mips.org
Subject: Re: How to configure the cache size in r4000
Message-ID: <20040113163543.GA31459@linux-mips.org>
References: <20040111124828.71884.qmail@web10103.mail.yahoo.com> <Pine.LNX.4.55.0401121345490.21851@jurand.ds.pg.gda.pl>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Pine.LNX.4.55.0401121345490.21851@jurand.ds.pg.gda.pl>
User-Agent: Mutt/1.4i
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: 3915
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
Content-Length: 1236
Lines: 27

On Mon, Jan 12, 2004 at 01:51:55PM +0100, Maciej W. Rozycki wrote:

> >     The cache size is modified by setting the IC/DC
> > bits in the 'config' register. Seems they are set only
> > by the hardware during the processor reset. And also,
> > those bits are mentioned as read only bits..
> 
>  You cannot modify the size of the primary caches -- the values are
> hardwired to the amount of cache available in the processor (8kB+8kB for
> the original R4000).  However, if you take appropriate precautions, you
> can alter the line sizes of the caches by modifying appropriate bits of
> cp0.config.

On some systems that's a dangerous and won't work due to some issue with
the memory controller.  That's why Linux supports all possible combinations
instead of reconfiguring caches.  Of course there's also the hope that
developers of a system did configure the cache for the optimal performance.

The one system I recall where reconfiguring is not possible are certain
revs of MIPS Magnum 4000 / MIPS Millenium / Olivetti M700-10 but I'm
convinced there are others.

If reconfiguring is possible 32-byte D-cache and I-Cache lines are probably
the optimum for non-tiny systems.  For the L2 cache I'd guess 64 or 128
byte lines.

  Ralf

From ralf@linux-mips.org Tue Jan 13 16:41:04 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 13 Jan 2004 16:41:05 +0000 (GMT)
Received: from p508B5C01.dip.t-dialin.net ([IPv6:::ffff:80.139.92.1]:50825
	"EHLO mail.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225315AbUAMQlE>; Tue, 13 Jan 2004 16:41:04 +0000
Received: from fluff.linux-mips.net (fluff.linux-mips.net [127.0.0.1])
	by mail.linux-mips.net (8.12.8/8.12.8) with ESMTP id i0DGf1WI005432;
	Tue, 13 Jan 2004 17:41:01 +0100
Received: (from ralf@localhost)
	by fluff.linux-mips.net (8.12.8/8.12.8/Submit) id i0DGf1NF005431;
	Tue, 13 Jan 2004 17:41:01 +0100
Date: Tue, 13 Jan 2004 17:41:01 +0100
From: Ralf Baechle <ralf@linux-mips.org>
To: Goswin von Brederlow <brederlo@informatik.uni-tuebingen.de>
Cc: linux-mips@linux-mips.org
Subject: Re: Test and hello
Message-ID: <20040113164101.GC31459@linux-mips.org>
References: <87y8sckp65.fsf@mrvn.homelinux.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <87y8sckp65.fsf@mrvn.homelinux.org>
User-Agent: Mutt/1.4i
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: 3916
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
Content-Length: 177
Lines: 7

On Tue, Jan 13, 2004 at 01:29:06PM +0100, Goswin von Brederlow wrote:

> test, test, can anyone read me?

My general reaction on test emails is to improve spam filters.

  Ralf

From ralf@linux-mips.org Tue Jan 13 16:41:40 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 13 Jan 2004 16:41:40 +0000 (GMT)
Received: from p508B5C01.dip.t-dialin.net ([IPv6:::ffff:80.139.92.1]:52617
	"EHLO mail.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225315AbUAMQlk>; Tue, 13 Jan 2004 16:41:40 +0000
Received: from fluff.linux-mips.net (fluff.linux-mips.net [127.0.0.1])
	by mail.linux-mips.net (8.12.8/8.12.8) with ESMTP id i0DGdZWI005404;
	Tue, 13 Jan 2004 17:39:35 +0100
Received: (from ralf@localhost)
	by fluff.linux-mips.net (8.12.8/8.12.8/Submit) id i0DGdYIf005403;
	Tue, 13 Jan 2004 17:39:34 +0100
Date: Tue, 13 Jan 2004 17:39:34 +0100
From: Ralf Baechle <ralf@linux-mips.org>
To: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
Cc: Adrian Bunk <bunk@fs.tum.de>, linux-mips@linux-mips.org,
	linux-kernel@vger.kernel.org
Subject: Re: [2.6 patch] fix DECSTATION depends
Message-ID: <20040113163934.GB31459@linux-mips.org>
References: <20040113015202.GE9677@fs.tum.de> <20040113022826.GC1646@linux-mips.org> <Pine.LNX.4.55.0401131401300.21962@jurand.ds.pg.gda.pl>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Pine.LNX.4.55.0401131401300.21962@jurand.ds.pg.gda.pl>
User-Agent: Mutt/1.4i
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: 3917
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
Content-Length: 506
Lines: 16

On Tue, Jan 13, 2004 at 02:07:54PM +0100, Maciej W. Rozycki wrote:

> 
> > > it seems the following is required in Linus' tree to get correct depends 
> > > for DECSTATION:
> > 
> > Thanks,  applied.
> 
>  The dependency was intentional: stable for 32-bit, experimental for
> 64-bit.  I'm reverting the change immediately.  Please always contact me
> before applying non-obvious changes for the DECstation.

Well, this one seemed to be obvious but sometimes things are not what
they seem to be ...

  Ralf

From macro@ds2.pg.gda.pl Tue Jan 13 16:48:21 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 13 Jan 2004 16:48:22 +0000 (GMT)
Received: from jurand.ds.pg.gda.pl ([IPv6:::ffff:153.19.208.2]:64678 "EHLO
	jurand.ds.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8225315AbUAMQsV>; Tue, 13 Jan 2004 16:48:21 +0000
Received: by jurand.ds.pg.gda.pl (Postfix, from userid 1011)
	id B05CB4C3BC; Tue, 13 Jan 2004 17:48:17 +0100 (CET)
Received: from localhost (localhost [127.0.0.1])
	by jurand.ds.pg.gda.pl (Postfix) with ESMTP
	id 9B8F947831; Tue, 13 Jan 2004 17:48:17 +0100 (CET)
Date: Tue, 13 Jan 2004 17:48:17 +0100 (CET)
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To: Ralf Baechle <ralf@linux-mips.org>
Cc: karthikeyan natarajan <karthik_96cse@yahoo.com>,
	linux-mips@linux-mips.org
Subject: Re: How to configure the cache size in r4000
In-Reply-To: <20040113163543.GA31459@linux-mips.org>
Message-ID: <Pine.LNX.4.55.0401131741390.3158@jurand.ds.pg.gda.pl>
References: <20040111124828.71884.qmail@web10103.mail.yahoo.com>
 <Pine.LNX.4.55.0401121345490.21851@jurand.ds.pg.gda.pl>
 <20040113163543.GA31459@linux-mips.org>
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: 3918
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
Content-Length: 1428
Lines: 32

On Tue, 13 Jan 2004, Ralf Baechle wrote:

> >  You cannot modify the size of the primary caches -- the values are
> > hardwired to the amount of cache available in the processor (8kB+8kB for
> > the original R4000).  However, if you take appropriate precautions, you
> > can alter the line sizes of the caches by modifying appropriate bits of
> > cp0.config.
> 
> On some systems that's a dangerous and won't work due to some issue with
> the memory controller.  That's why Linux supports all possible combinations
> instead of reconfiguring caches.  Of course there's also the hope that
> developers of a system did configure the cache for the optimal performance.

 Plus there are processor errata related to certain values of line sizes.

> If reconfiguring is possible 32-byte D-cache and I-Cache lines are probably
> the optimum for non-tiny systems.  For the L2 cache I'd guess 64 or 128
> byte lines.

 Well, reconfiguring the line size of the L2 cache is system-specific and 
the size is most likely hardwired.

 BTW, the DECstation uses 16-byte lines for the D-cache and the I-Cache
and 32-byte lines for the S-cache.  With the S-cache size at 1MB and up to
480MB of RAM does it qualify as a tiny system? ;-)

  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 Tue Jan 13 17:02:37 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 13 Jan 2004 17:02:38 +0000 (GMT)
Received: from jurand.ds.pg.gda.pl ([IPv6:::ffff:153.19.208.2]:46761 "EHLO
	jurand.ds.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8225315AbUAMRC0>; Tue, 13 Jan 2004 17:02:26 +0000
Received: by jurand.ds.pg.gda.pl (Postfix, from userid 1011)
	id 658794C3A9; Tue, 13 Jan 2004 18:02:22 +0100 (CET)
Received: from localhost (localhost [127.0.0.1])
	by jurand.ds.pg.gda.pl (Postfix) with ESMTP
	id 519D947607; Tue, 13 Jan 2004 18:02:22 +0100 (CET)
Date: Tue, 13 Jan 2004 18:02:22 +0100 (CET)
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To: Ralf Baechle <ralf@linux-mips.org>
Cc: Adrian Bunk <bunk@fs.tum.de>, linux-mips@linux-mips.org,
	linux-kernel@vger.kernel.org
Subject: Re: [2.6 patch] fix DECSTATION depends
In-Reply-To: <20040113163934.GB31459@linux-mips.org>
Message-ID: <Pine.LNX.4.55.0401131752380.3158@jurand.ds.pg.gda.pl>
References: <20040113015202.GE9677@fs.tum.de> <20040113022826.GC1646@linux-mips.org>
 <Pine.LNX.4.55.0401131401300.21962@jurand.ds.pg.gda.pl>
 <20040113163934.GB31459@linux-mips.org>
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: 3919
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
Content-Length: 828
Lines: 21

On Tue, 13 Jan 2004, Ralf Baechle wrote:

> >  The dependency was intentional: stable for 32-bit, experimental for
> > 64-bit.  I'm reverting the change immediately.  Please always contact me
> > before applying non-obvious changes for the DECstation.
> 
> Well, this one seemed to be obvious but sometimes things are not what
> they seem to be ...

 Hmm, a change of semantics wouldn't qualify as obvious for me...

 I admit this construct may seem surprising at first sight when compared
to many other uses of EXPERIMENTAL -- the equivalent more verbose syntax
used for 2.4 leaves no doubt about the intent, though.

  Maciej

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

From dan@quicklogic.com Tue Jan 13 17:21:10 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 13 Jan 2004 17:21:13 +0000 (GMT)
Received: from host-65-122-203-2.quicklogic.com ([IPv6:::ffff:65.122.203.2]:12429
	"EHLO mail.Quicklogic.com") by linux-mips.org with ESMTP
	id <S8225256AbUAMRVK>; Tue, 13 Jan 2004 17:21:10 +0000
Received: from quicklogic.com
	([192.168.1.153])
	by mail.Quicklogic.com; Tue, 13 Jan 2004 09:23:47 -0800
Message-ID: <4004295F.9060104@quicklogic.com>
Date: Tue, 13 Jan 2004 12:22:39 -0500
From: Dan Aizenstros <dan@quicklogic.com>
Organization: QuickLogic Canada
User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.5b) Gecko/20030901 Thunderbird/0.2
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: linux-mips@linux-mips.org
Subject: Re: CVS Update@-mips.org: linux
References: <20040113080926Z8225270-16706+2387@linux-mips.org>
In-Reply-To: <20040113080926Z8225270-16706+2387@linux-mips.org>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Return-Path: <dan@quicklogic.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: 3920
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: dan@quicklogic.com
Precedence: bulk
X-list: linux-mips

Hello,

You broke any build that does not define CONFIG_SERIAL_AU1X00
by adding an #error in the include/asm-mips/serial.h file.

-- Dan A.

ppopov@linux-mips.org wrote:

> CVSROOT:	/home/cvs
> Module name:	linux
> Changes by:	ppopov@ftp.linux-mips.org	04/01/13 08:09:22
> 
> Modified files:
> 	arch/mips      : Kconfig Makefile 
> 	arch/mips/au1000/common: clocks.c dbg_io.c dma.c irq.c pci.c 
> 	                         power.c puts.c reset.c setup.c time.c 
> 	arch/mips/au1000/pb1500: board_setup.c irqmap.c 
> 	arch/mips/configs: pb1500_defconfig 
> 	drivers/net    : au1000_eth.c 
> 	drivers/serial : au1x00_uart.c 
> 	include/asm-mips: serial.h 
> Added files:
> 	include/asm-mips/mach-au1x00: au1000.h au1000_dma.h 
> 	                              au1000_gpio.h au1000_pcmcia.h 
> 	                              au1000_usbdev.h 
> 	include/asm-mips/mach-db1x00: db1x00.h 
> 	include/asm-mips/mach-pb1x00: pb1000.h pb1100.h pb1500.h 
> Removed files:
> 	include/asm-mips: au1000.h au1000_dma.h au1000_gpio.h 
> 	                  au1000_pcmcia.h au1000_usbdev.h db1x00.h 
> 	                  pb1000.h pb1100.h pb1500.h 
> 
> Log message:
> 	- moved .h files to appropriate include/asm-mips/mach-xxxx directories
> 	- fixed .c files to pick up new .h path name
> 	- fixed the serial console
> 
> 


From bunk@fs.tum.de Tue Jan 13 17:27:58 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 13 Jan 2004 17:27:59 +0000 (GMT)
Received: from hermes.fachschaften.tu-muenchen.de ([IPv6:::ffff:129.187.202.12]:58088
	"HELO hermes.fachschaften.tu-muenchen.de") by linux-mips.org
	with SMTP id <S8225336AbUAMR16>; Tue, 13 Jan 2004 17:27:58 +0000
Received: (qmail 22352 invoked from network); 13 Jan 2004 17:25:12 -0000
Received: from mimas.fachschaften.tu-muenchen.de (129.187.202.58)
  by hermes.fachschaften.tu-muenchen.de with QMQP; 13 Jan 2004 17:25:12 -0000
Date: Tue, 13 Jan 2004 18:27:51 +0100
From: Adrian Bunk <bunk@fs.tum.de>
To: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
Cc: Ralf Baechle <ralf@linux-mips.org>, linux-mips@linux-mips.org,
	linux-kernel@vger.kernel.org
Subject: Re: [2.6 patch] fix DECSTATION depends
Message-ID: <20040113172751.GN9677@fs.tum.de>
References: <20040113015202.GE9677@fs.tum.de> <20040113022826.GC1646@linux-mips.org> <Pine.LNX.4.55.0401131401300.21962@jurand.ds.pg.gda.pl>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Pine.LNX.4.55.0401131401300.21962@jurand.ds.pg.gda.pl>
User-Agent: Mutt/1.4.1i
Return-Path: <bunk@fs.tum.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: 3921
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: bunk@fs.tum.de
Precedence: bulk
X-list: linux-mips

On Tue, Jan 13, 2004 at 02:07:54PM +0100, Maciej W. Rozycki wrote:
> On Tue, 13 Jan 2004, Ralf Baechle wrote:
> 
> > > it seems the following is required in Linus' tree to get correct depends 
> > > for DECSTATION:
> > 
> > Thanks,  applied.
> 
>  The dependency was intentional: stable for 32-bit, experimental for
> 64-bit.  I'm reverting the change immediately.  Please always contact me
> before applying non-obvious changes for the DECstation.
> 
>  If there's anything wrong with the depends, it should be fixed elsewhere.  
> Details, please.

Does -mabi=64 really work on any DECstation?

AFAIK none of the R2000, R3x00 and the R4x00 do support the 64bit ABI.

>   Maciej

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed


From brederlo@informatik.uni-tuebingen.de Tue Jan 13 18:08:02 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 13 Jan 2004 18:08:02 +0000 (GMT)
Received: from mx5.Informatik.Uni-Tuebingen.De ([IPv6:::ffff:134.2.12.32]:48330
	"EHLO mx5.informatik.uni-tuebingen.de") by linux-mips.org with ESMTP
	id <S8225336AbUAMSIC>; Tue, 13 Jan 2004 18:08:02 +0000
Received: from localhost (loopback [127.0.0.1])
	by mx5.informatik.uni-tuebingen.de (Postfix) with ESMTP
	id DDC8C132; Tue, 13 Jan 2004 19:07:55 +0100 (NFT)
Received: from mx5.informatik.uni-tuebingen.de ([127.0.0.1])
 by localhost (mx5 [127.0.0.1]) (amavisd-new, port 10024) with ESMTP
 id 29728-05; Tue, 13 Jan 2004 19:07:54 +0100 (NFT)
Received: from dual (semeai.Informatik.Uni-Tuebingen.De [134.2.15.66])
	by mx5.informatik.uni-tuebingen.de (Postfix) with ESMTP
	id 2C553121; Tue, 13 Jan 2004 19:07:53 +0100 (NFT)
Received: from mrvn by dual with local (Exim 3.36 #1 (Debian))
	id 1AgSx6-0006Oq-00; Tue, 13 Jan 2004 19:07:44 +0100
To: linux-mips@linux-mips.org
Cc: ppopov@mvista.com
Subject: Kernel oops on XXS1500 in au1000eth.c
From: Goswin von Brederlow <brederlo@informatik.uni-tuebingen.de>
Date: 13 Jan 2004 19:07:44 +0100
Message-ID: <87lloblo27.fsf@mrvn.homelinux.org>
Lines: 60
User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Reasonable Discussion)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Virus-Scanned: by amavisd-new (McAfee AntiVirus) at informatik.uni-tuebingen.de
Return-Path: <brederlo@informatik.uni-tuebingen.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: 3922
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: brederlo@informatik.uni-tuebingen.de
Precedence: bulk
X-list: linux-mips

Hi,

when compiling a kernel for my XXS1500 I allways ended up with a
kernel oops in the network driver (au1000eth.c).

Finaly I checked the actual kernel source the running kernel was build
from and found "CONFIG_BCM5222_DUAL_PHY" was set. Setting that solves
the oops.

Maybe that could be caught in some way and prevented.

MfG
        Goswin

----------------------------------------------------------------------
Start = 0x80274040, range = (0x80100000,0x802bbfff), format = SREC

Linux NET4.0 for Linux 2.4
Based upon Swansea University Computer Society NET3.039
Initializing RT netlink socket
Starting kswapd
pty: 256 Unix98 ptys configured
Serial driver version 1.01 (2001-02-08) with no serial options enabled
ttyS00 at 0xb1100000 (irq = 0) is a 16550
ttyS01 at 0xb1200000 (irq = 1) is a 16550
ttyS02 at 0xb1300000 (irq = 2) is a 16550
ttyS03 at 0xb1400000 (irq = 3) is a 16550
Generic MIPS RTC Driver v1.0
RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize
loop: loaded (max 8 devices)
au1000eth.c:1.4 ppopov@mvista.com
eth0: Au1x Ethernet found at 0xb1500000, irq 28
eth0: Broadcom BCM5222 10/100 BaseT PHY at phy address 0
eth0: Using Broadcom BCM5222 10/100 BaseT PHY as default
eth1: Au1x Ethernet found at 0xb1510000, irq 29
Unable to handle kernel paging request at virtual address 00000000, epc == 801c0
Oops in fault.c::do_page_fault, line 206:
$0 : 00000000 1000fc00 00000000 001e3000 802597c8 0000001f 00000001 00000013
$8 : 810cc800 b1510018 000011e0 802a1434 00000004 ba2e8ba3 1000fc01 00000002
$16: 8029f940 802db12c 00000001 00000020 810cc800 810cc9e4 810cc960 802b4cf4
$24: ffffffff 00000001                   802e4000 802e5ed8 0000ffff 801c5b60
Hi : 000304cc
Lo : ecaf8000
epc   : 801c5c10    Not tainted
Status: 1000fc03
epc   : 00800008
PrId  : 01030200
Process swapper (pid: 1, stackpage=802e4000)
Stack:    b1510000 801196ac 802598b8 810cc800 8029f940 802db12c 00000001
 810cc960 810cc800 810cc9e4 810cc9f4 b1510000 0000001d 801c63a0 80259890
 810cc800 b1510000 0000001d 87000266 00001123 00000001 802db12c 00000001
 04000000 00000000 00000000 00000000 00000000 8008aa54 80287dac 80287c80
 80287c6c 00000000 00000000 8028e530 8028e55c 00010f00 802746ec 80122ed8
 8028100c ...
Call Trace:   [<801196ac>] [<802598b8>] [<801c63a0>] [<80259890>] [<80122ed8>]
 [<8025b9cc>] [<801007c4>] [<801007d4>] [<801007c4>] [<801047d4>] [<80111e94>]
 [<8016125c>] [<80161220>] [<801047c4>]

Code: 8c420004  3c048026  248497c8 <8c460000> 0c044dc1  02802821  0807171f  000
Kernel panic: Attempted to kill init!

From ppopov@mvista.com Tue Jan 13 18:21:43 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 13 Jan 2004 18:21:44 +0000 (GMT)
Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:45307 "EHLO
	av.mvista.com") by linux-mips.org with ESMTP id <S8225336AbUAMSVn>;
	Tue, 13 Jan 2004 18:21:43 +0000
Received: from zeus.mvista.com (av [127.0.0.1])
	by av.mvista.com (8.9.3/8.9.3) with ESMTP id KAA28217;
	Tue, 13 Jan 2004 10:21:37 -0800
Subject: Re: Kernel oops on XXS1500 in au1000eth.c
From: Pete Popov <ppopov@mvista.com>
To: Goswin von Brederlow <brederlo@informatik.uni-tuebingen.de>
Cc: Linux MIPS mailing list <linux-mips@linux-mips.org>
In-Reply-To: <87lloblo27.fsf@mrvn.homelinux.org>
References: <87lloblo27.fsf@mrvn.homelinux.org>
Content-Type: text/plain
Organization: MontaVista Software
Message-Id: <1074018143.21864.13.camel@zeus.mvista.com>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.2.4 
Date: 13 Jan 2004 10:22:24 -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: 3923
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 Tue, 2004-01-13 at 10:07, Goswin von Brederlow wrote:
> Hi,
> 
> when compiling a kernel for my XXS1500 I allways ended up with a
> kernel oops in the network driver (au1000eth.c).
> 
> Finaly I checked the actual kernel source the running kernel was build
> from and found "CONFIG_BCM5222_DUAL_PHY" was set. Setting that solves
> the oops.
> 
> Maybe that could be caught in some way and prevented.

Well, the kernel shouldn't be crashing but as far as the BCM dual phy
thing -- I'm not sure how to detect it at run time without knowing ahead
of time that we've got one.  I admittedly haven't spent too much time
thinking about this problem but I didn't see an easy way to handle it.

Pete

> MfG
>         Goswin
> 
> ----------------------------------------------------------------------
> Start = 0x80274040, range = (0x80100000,0x802bbfff), format = SREC
> 
> Linux NET4.0 for Linux 2.4
> Based upon Swansea University Computer Society NET3.039
> Initializing RT netlink socket
> Starting kswapd
> pty: 256 Unix98 ptys configured
> Serial driver version 1.01 (2001-02-08) with no serial options enabled
> ttyS00 at 0xb1100000 (irq = 0) is a 16550
> ttyS01 at 0xb1200000 (irq = 1) is a 16550
> ttyS02 at 0xb1300000 (irq = 2) is a 16550
> ttyS03 at 0xb1400000 (irq = 3) is a 16550
> Generic MIPS RTC Driver v1.0
> RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize
> loop: loaded (max 8 devices)
> au1000eth.c:1.4 ppopov@mvista.com
> eth0: Au1x Ethernet found at 0xb1500000, irq 28
> eth0: Broadcom BCM5222 10/100 BaseT PHY at phy address 0
> eth0: Using Broadcom BCM5222 10/100 BaseT PHY as default
> eth1: Au1x Ethernet found at 0xb1510000, irq 29
> Unable to handle kernel paging request at virtual address 00000000, epc == 801c0
> Oops in fault.c::do_page_fault, line 206:
> $0 : 00000000 1000fc00 00000000 001e3000 802597c8 0000001f 00000001 00000013
> $8 : 810cc800 b1510018 000011e0 802a1434 00000004 ba2e8ba3 1000fc01 00000002
> $16: 8029f940 802db12c 00000001 00000020 810cc800 810cc9e4 810cc960 802b4cf4
> $24: ffffffff 00000001                   802e4000 802e5ed8 0000ffff 801c5b60
> Hi : 000304cc
> Lo : ecaf8000
> epc   : 801c5c10    Not tainted
> Status: 1000fc03
> epc   : 00800008
> PrId  : 01030200
> Process swapper (pid: 1, stackpage=802e4000)
> Stack:    b1510000 801196ac 802598b8 810cc800 8029f940 802db12c 00000001
>  810cc960 810cc800 810cc9e4 810cc9f4 b1510000 0000001d 801c63a0 80259890
>  810cc800 b1510000 0000001d 87000266 00001123 00000001 802db12c 00000001
>  04000000 00000000 00000000 00000000 00000000 8008aa54 80287dac 80287c80
>  80287c6c 00000000 00000000 8028e530 8028e55c 00010f00 802746ec 80122ed8
>  8028100c ...
> Call Trace:   [<801196ac>] [<802598b8>] [<801c63a0>] [<80259890>] [<80122ed8>]
>  [<8025b9cc>] [<801007c4>] [<801007d4>] [<801007c4>] [<801047d4>] [<80111e94>]
>  [<8016125c>] [<80161220>] [<801047c4>]
> 
> Code: 8c420004  3c048026  248497c8 <8c460000> 0c044dc1  02802821  0807171f  000
> Kernel panic: Attempted to kill init!
> 
> 


From ndf@ghs.com Tue Jan 13 18:35:08 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 13 Jan 2004 18:35:10 +0000 (GMT)
Received: from eta.ghs.com ([IPv6:::ffff:63.102.70.66]:50938 "EHLO eta.ghs.com")
	by linux-mips.org with ESMTP id <S8225232AbUAMSfI>;
	Tue, 13 Jan 2004 18:35:08 +0000
Received: from blaze.ghs.com (blaze.ghs.com [192.67.158.233])
	by eta.ghs.com (8.12.10/8.12.10) with ESMTP id i0DIZ4kp002096;
	Tue, 13 Jan 2004 10:35:04 -0800 (PST)
Received: from zcar.ghs.com (zcar.ghs.com [192.67.158.60])
	by blaze.ghs.com (8.12.9/8.12.9) with ESMTP id i0DIZ39w007460;
	Tue, 13 Jan 2004 10:35:03 -0800 (PST)
Date: Tue, 13 Jan 2004 10:35:04 -0800 (PST)
From: Nathan Field <ndf@ghs.com>
To: Daniel Jacobowitz <dan@debian.org>
cc: linux-mips@linux-mips.org
Subject: Re: ptrace induced instruction cache bug?
In-Reply-To: <20040113150108.GA7144@nevyn.them.org>
Message-ID: <Pine.LNX.4.44.0401131029410.1969-100000@zcar.ghs.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <ndf@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: 3924
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: ndf@ghs.com
Precedence: bulk
X-list: linux-mips

> It sounds reasonable.  I've encountered this problem in the past also,
> but never with the Pro 2.1 / MIPS release which is what you're using.  
> I don't see anything obviously wrong with your test code, either.
	So... is there a fix for this?

> Yes, you will need a newer toolchain.  Honestly, I'm baffled as to why a
> Pro 2.1 toolchain was available from our web site at all, unless you got
> it via an old product subscription... it should have been Pro 3.0, which
> uses GCC 3.2 and a more recent binutils.  But I don't have any control
> over these things :)
	I downloaded it about 5 days ago from:
http://www.mvista.com/previewkit/index.html

Could I get a preview kit of your 3.0 release for a Malta 4Kc board?

	nathan

-- 
Nathan Field (ndf@ghs.com)			          All gone.

But the trouble with analogies is that analogies are like goldfish:
sometimes they have nothing to do with the topic at hand.
        -- Crispin (from a posting to the Bugtraq mailing list)


From brederlo@informatik.uni-tuebingen.de Tue Jan 13 18:37:24 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 13 Jan 2004 18:37:27 +0000 (GMT)
Received: from mx5.Informatik.Uni-Tuebingen.De ([IPv6:::ffff:134.2.12.32]:7371
	"EHLO mx5.informatik.uni-tuebingen.de") by linux-mips.org with ESMTP
	id <S8225349AbUAMShY>; Tue, 13 Jan 2004 18:37:24 +0000
Received: from localhost (loopback [127.0.0.1])
	by mx5.informatik.uni-tuebingen.de (Postfix) with ESMTP
	id 0A0E0132; Tue, 13 Jan 2004 19:37:18 +0100 (NFT)
Received: from mx5.informatik.uni-tuebingen.de ([127.0.0.1])
 by localhost (mx5 [127.0.0.1]) (amavisd-new, port 10024) with ESMTP
 id 30756-01; Tue, 13 Jan 2004 19:37:16 +0100 (NFT)
Received: from dual (semeai.Informatik.Uni-Tuebingen.De [134.2.15.66])
	by mx5.informatik.uni-tuebingen.de (Postfix) with ESMTP
	id 89084121; Tue, 13 Jan 2004 19:37:15 +0100 (NFT)
Received: from mrvn by dual with local (Exim 3.36 #1 (Debian))
	id 1AgTPY-0006UX-00; Tue, 13 Jan 2004 19:37:08 +0100
To: Pete Popov <ppopov@mvista.com>
Cc: Goswin von Brederlow <brederlo@informatik.uni-tuebingen.de>,
	Linux MIPS mailing list <linux-mips@linux-mips.org>
Subject: Re: Kernel oops on XXS1500 in au1000eth.c
References: <87lloblo27.fsf@mrvn.homelinux.org>
	<1074018143.21864.13.camel@zeus.mvista.com>
From: Goswin von Brederlow <brederlo@informatik.uni-tuebingen.de>
Date: 13 Jan 2004 19:37:08 +0100
In-Reply-To: <1074018143.21864.13.camel@zeus.mvista.com>
Message-ID: <87d69nlmp7.fsf@mrvn.homelinux.org>
Lines: 32
User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Reasonable Discussion)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Virus-Scanned: by amavisd-new (McAfee AntiVirus) at informatik.uni-tuebingen.de
Return-Path: <brederlo@informatik.uni-tuebingen.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: 3925
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: brederlo@informatik.uni-tuebingen.de
Precedence: bulk
X-list: linux-mips

Pete Popov <ppopov@mvista.com> writes:

> On Tue, 2004-01-13 at 10:07, Goswin von Brederlow wrote:
> > Hi,
> > 
> > when compiling a kernel for my XXS1500 I allways ended up with a
> > kernel oops in the network driver (au1000eth.c).
> > 
> > Finaly I checked the actual kernel source the running kernel was build
> > from and found "CONFIG_BCM5222_DUAL_PHY" was set. Setting that solves
> > the oops.
> > 
> > Maybe that could be caught in some way and prevented.
> 
> Well, the kernel shouldn't be crashing but as far as the BCM dual phy
> thing -- I'm not sure how to detect it at run time without knowing ahead
> of time that we've got one.  I admittedly haven't spent too much time
> thinking about this problem but I didn't see an easy way to handle it.
> 
> Pete

Maybe some

if (mach == MACH_XXS1500) ...

construct? The MACH_XXS1500 must be good for something.

Hopefully MyCable will change the name when they design a new board
with a different network thing.

MfG
        Goswin

From drow@crack.them.org Tue Jan 13 20:59:06 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 13 Jan 2004 20:59:07 +0000 (GMT)
Received: from nevyn.them.org ([IPv6:::ffff:66.93.172.17]:8888 "EHLO
	nevyn.them.org") by linux-mips.org with ESMTP id <S8225365AbUAMU7G>;
	Tue, 13 Jan 2004 20:59:06 +0000
Received: from drow by nevyn.them.org with local (Exim 4.30 #1 (Debian))
	id 1AgVco-0004VO-5X; Tue, 13 Jan 2004 15:58:58 -0500
Date: Tue, 13 Jan 2004 15:58:58 -0500
From: Daniel Jacobowitz <dan@debian.org>
To: Nathan Field <ndf@ghs.com>
Cc: linux-mips@linux-mips.org
Subject: Re: ptrace induced instruction cache bug?
Message-ID: <20040113205858.GA17260@nevyn.them.org>
References: <20040113150108.GA7144@nevyn.them.org> <Pine.LNX.4.44.0401131029410.1969-100000@zcar.ghs.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Pine.LNX.4.44.0401131029410.1969-100000@zcar.ghs.com>
User-Agent: Mutt/1.5.1i
Return-Path: <drow@crack.them.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: 3926
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: dan@debian.org
Precedence: bulk
X-list: linux-mips

On Tue, Jan 13, 2004 at 10:35:04AM -0800, Nathan Field wrote:
> > It sounds reasonable.  I've encountered this problem in the past also,
> > but never with the Pro 2.1 / MIPS release which is what you're using.  
> > I don't see anything obviously wrong with your test code, either.
> 	So... is there a fix for this?

Usually a missing cache flush, as you surmised :)  But I don't know of
any that were missing in that version.

> > Yes, you will need a newer toolchain.  Honestly, I'm baffled as to why a
> > Pro 2.1 toolchain was available from our web site at all, unless you got
> > it via an old product subscription... it should have been Pro 3.0, which
> > uses GCC 3.2 and a more recent binutils.  But I don't have any control
> > over these things :)
> 	I downloaded it about 5 days ago from:
> http://www.mvista.com/previewkit/index.html
> 
> Could I get a preview kit of your 3.0 release for a Malta 4Kc board?

Let me inquire as to why we're distributing old ones.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

From kph@cisco.com Tue Jan 13 21:03:49 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 13 Jan 2004 21:03:50 +0000 (GMT)
Received: from adsl-66-123-66-42.dsl.pltn13.pacbell.net ([IPv6:::ffff:66.123.66.42]:18569
	"EHLO stella-blue.herbertphamily.com") by linux-mips.org with ESMTP
	id <S8225365AbUAMVDt>; Tue, 13 Jan 2004 21:03:49 +0000
Received: from [192.168.1.8] (shakedown.herbertphamily.com [192.168.1.8])
	(authenticated bits=0)
	by stella-blue.herbertphamily.com (8.12.8/8.12.8) with ESMTP id i0DL3j0M016956
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for <linux-mips@linux-mips.org>; Tue, 13 Jan 2004 13:03:45 -0800
Subject: How stable is 2.6 on a SB1250 processor?
From: Kevin Paul Herbert <kph@cisco.com>
To: linux-mips@linux-mips.org
Content-Type: text/plain
Organization: cisco Systems, Inc.
Message-Id: <1074027809.20636.91.camel@shakedown>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.2.2 (1.2.2-5) 
Date: 13 Jan 2004 13:03:30 -0800
Content-Transfer-Encoding: 7bit
Return-Path: <kph@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: 3927
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: kph@cisco.com
Precedence: bulk
X-list: linux-mips

I'm working on bringing up the 2.6 kernel on a board using the SB1250
processor, and I have a problem in userland that I'm wondering if anyone
else has seen.

I built a simple test program for userland, which just uses the write()
syscall to say hello world. This is statically linked, and it works
under a 2.4 kernel. Under 2.6, I get no output. My guess is that an
exception is occuring, the signal gets back to my test program, and it
is looping.

I've written a simple assembly language hello world program which does
the exact same thing... write() syscall and I get my hello world.

My next task is to get kgdb working on this board so I can do some
better debugging, but I was wondering if anyone else has seen this
problem, or for that matter whether the SB1 processor support is
expected to work at all.

Thanks for any help,

Kevin


-- 
Kevin Paul Herbert <kph@cisco.com>
cisco Systems, Inc.


From ppopov@mvista.com Tue Jan 13 21:08:43 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 13 Jan 2004 21:08:45 +0000 (GMT)
Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:21750 "EHLO
	av.mvista.com") by linux-mips.org with ESMTP id <S8225365AbUAMVIn>;
	Tue, 13 Jan 2004 21:08:43 +0000
Received: from zeus.mvista.com (av [127.0.0.1])
	by av.mvista.com (8.9.3/8.9.3) with ESMTP id NAA03805;
	Tue, 13 Jan 2004 13:08:36 -0800
Subject: Re: How stable is 2.6 on a SB1250 processor?
From: Pete Popov <ppopov@mvista.com>
To: Kevin Paul Herbert <kph@cisco.com>
Cc: Linux MIPS mailing list <linux-mips@linux-mips.org>
In-Reply-To: <1074027809.20636.91.camel@shakedown>
References: <1074027809.20636.91.camel@shakedown>
Content-Type: text/plain
Organization: MontaVista Software
Message-Id: <1074028164.21857.120.camel@zeus.mvista.com>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.2.4 
Date: 13 Jan 2004 13:09:25 -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: 3928
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


I think userland is still broken. Ralf was working on the access_ok
problem the last time I talked to him.

Pete

On Tue, 2004-01-13 at 13:03, Kevin Paul Herbert wrote:
> I'm working on bringing up the 2.6 kernel on a board using the SB1250
> processor, and I have a problem in userland that I'm wondering if anyone
> else has seen.
> 
> I built a simple test program for userland, which just uses the write()
> syscall to say hello world. This is statically linked, and it works
> under a 2.4 kernel. Under 2.6, I get no output. My guess is that an
> exception is occuring, the signal gets back to my test program, and it
> is looping.
> 
> I've written a simple assembly language hello world program which does
> the exact same thing... write() syscall and I get my hello world.
> 
> My next task is to get kgdb working on this board so I can do some
> better debugging, but I was wondering if anyone else has seen this
> problem, or for that matter whether the SB1 processor support is
> expected to work at all.
> 
> Thanks for any help,
> 
> Kevin
> 


From dimitri@sonycom.com Tue Jan 13 21:45:25 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 13 Jan 2004 21:45:26 +0000 (GMT)
Received: from witte.sonytel.be ([IPv6:::ffff:80.88.33.193]:18087 "EHLO
	witte.sonytel.be") by linux-mips.org with ESMTP id <S8225375AbUAMVpZ>;
	Tue, 13 Jan 2004 21:45:25 +0000
Received: from zebra.sonytel.be (localhost [127.0.0.1])
	by witte.sonytel.be (8.12.10/8.12.10) with ESMTP id i0DLiqQF002310;
	Tue, 13 Jan 2004 22:44:52 +0100 (MET)
Received: from dimitri by zebra.sonytel.be with local (Exim 3.35 #1 )
	id 1AgWLG-0000jo-00; Tue, 13 Jan 2004 22:44:54 +0100
Date: Tue, 13 Jan 2004 22:44:54 +0100
To: Pete Popov <ppopov@mvista.com>, kph@cisco.com
Cc: Linux MIPS mailing list <linux-mips@linux-mips.org>
Subject: Re: How stable is 2.6 on a SB1250 processor?
Message-ID: <20040113214454.GA2737@sonycom.com>
References: <1074027809.20636.91.camel@shakedown> <1074028164.21857.120.camel@zeus.mvista.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <1074028164.21857.120.camel@zeus.mvista.com>
User-Agent: Mutt/1.3.28i
From: Dimitri Torfs <dimitri@sonycom.com>
Return-Path: <dimitri@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: 3929
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: dimitri@sonycom.com
Precedence: bulk
X-list: linux-mips

On Tue, Jan 13, 2004 at 01:09:25PM -0800, Pete Popov wrote:
> 
> I think userland is still broken. Ralf was working on the access_ok
> problem the last time I talked to him.
> 

Yes, if it's a 32-bit kernel then it's definitely broken. You might want
to check out
http://www.linux-mips.org/archives/linux-mips/2004-01/msg00000.html.

After that fix, user space stuff started to work for me.

Dimitri


-- 
Dimitri Torfs       |  NSCE 
dimitri@sonycom.com |  The Corporate Village
tel: +32 2 7008541  |  Da Vincilaan 7 - D1 
fax: +32 2 7008622  |  B-1935 Zaventem - Belgium


From charlieb-linux-mips@e-smith.com Tue Jan 13 22:00:39 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 13 Jan 2004 22:00:40 +0000 (GMT)
Received: from mail.e-smith.com ([IPv6:::ffff:216.191.234.126]:51727 "HELO
	nssg.mitel.com") by linux-mips.org with SMTP id <S8225379AbUAMWAj>;
	Tue, 13 Jan 2004 22:00:39 +0000
Received: (qmail 27696 invoked by uid 404); 13 Jan 2004 22:00:28 -0000
Received: from charlieb-linux-mips@e-smith.com by tripe.nssg.mitel.com with qmail-scanner; 13 Jan 2004 17:00:27 -0000
Received: from allspice-core.nssg.mitel.com (HELO e-smith.com) (10.33.16.12)
  by tripe.nssg.mitel.com (10.33.17.11) with SMTP; 13 Jan 2004 22:00:27 -0000
Received: (qmail 1845 invoked by uid 5008); 13 Jan 2004 22:00:27 -0000
Received: from localhost (sendmail-bs@127.0.0.1)
  by localhost with SMTP; 13 Jan 2004 22:00:27 -0000
Date: Tue, 13 Jan 2004 17:00:27 -0500 (EST)
From: Charlie Brady <charlieb-linux-mips@e-smith.com>
X-X-Sender: charlieb@allspice.nssg.mitel.com
To: linux-mips@linux-mips.org
Subject: Broadcom 4702?
Message-ID: <Pine.LNX.4.44.0401131655350.20844-100000@allspice.nssg.mitel.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <charlieb-linux-mips@e-smith.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: 3930
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: charlieb-linux-mips@e-smith.com
Precedence: bulk
X-list: linux-mips


I haven't found signs of it in the archives, but is anyone aware of any 
efforts to fold in Broadcom's support for their 4702 processor, as used in 
Wireless gateways such as the Linksys WRT54G? Source code for their kernel 
port can be found here:

  http://www.linksys.com/support/gpl.asp

Would someone from Broadcom prefer to provide the patches?

--
Charlie


From jsun@mvista.com Tue Jan 13 22:28:06 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 13 Jan 2004 22:28:09 +0000 (GMT)
Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:38645 "EHLO
	orion.mvista.com") by linux-mips.org with ESMTP id <S8225382AbUAMW2G>;
	Tue, 13 Jan 2004 22:28:06 +0000
Received: (from jsun@localhost)
	by orion.mvista.com (8.11.6/8.11.6) id i0DMS2T29438;
	Tue, 13 Jan 2004 14:28:02 -0800
Date: Tue, 13 Jan 2004 14:28:02 -0800
From: Jun Sun <jsun@mvista.com>
To: Charlie Brady <charlieb-linux-mips@e-smith.com>
Cc: linux-mips@linux-mips.org, jsun@mvista.com
Subject: Re: Broadcom 4702?
Message-ID: <20040113142802.M11733@mvista.com>
References: <Pine.LNX.4.44.0401131655350.20844-100000@allspice.nssg.mitel.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <Pine.LNX.4.44.0401131655350.20844-100000@allspice.nssg.mitel.com>; from charlieb-linux-mips@e-smith.com on Tue, Jan 13, 2004 at 05:00:27PM -0500
Return-Path: <jsun@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: 3931
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 13, 2004 at 05:00:27PM -0500, Charlie Brady wrote:
> 
> I haven't found signs of it in the archives, but is anyone aware of any 
> efforts to fold in Broadcom's support for their 4702 processor, as used in 
> Wireless gateways such as the Linksys WRT54G? Source code for their kernel 
> port can be found here:
> 
>   http://www.linksys.com/support/gpl.asp
> 
> Would someone from Broadcom prefer to provide the patches?
> 

Mvista is in the process of supporting bcm4704, which should be close to
bcm4702.  If there is much interest, we can push the patch out to 
the linux-mips.org tree.

Jun

From jsun@mvista.com Tue Jan 13 22:31:43 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 13 Jan 2004 22:31:43 +0000 (GMT)
Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:25335 "EHLO
	orion.mvista.com") by linux-mips.org with ESMTP id <S8225382AbUAMWbn>;
	Tue, 13 Jan 2004 22:31:43 +0000
Received: (from jsun@localhost)
	by orion.mvista.com (8.11.6/8.11.6) id i0DMVb529459;
	Tue, 13 Jan 2004 14:31:37 -0800
Date: Tue, 13 Jan 2004 14:31:37 -0800
From: Jun Sun <jsun@mvista.com>
To: Dimitri Torfs <dimitri@sonycom.com>
Cc: Pete Popov <ppopov@mvista.com>, kph@cisco.com,
	Linux MIPS mailing list <linux-mips@linux-mips.org>,
	jsun@mvista.com
Subject: Re: How stable is 2.6 on a SB1250 processor?
Message-ID: <20040113143137.N11733@mvista.com>
References: <1074027809.20636.91.camel@shakedown> <1074028164.21857.120.camel@zeus.mvista.com> <20040113214454.GA2737@sonycom.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <20040113214454.GA2737@sonycom.com>; from dimitri@sonycom.com on Tue, Jan 13, 2004 at 10:44:54PM +0100
Return-Path: <jsun@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: 3932
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 13, 2004 at 10:44:54PM +0100, Dimitri Torfs wrote:
> On Tue, Jan 13, 2004 at 01:09:25PM -0800, Pete Popov wrote:
> > 
> > I think userland is still broken. Ralf was working on the access_ok
> > problem the last time I talked to him.
> > 
> 
> Yes, if it's a 32-bit kernel then it's definitely broken. You might want
> to check out
> http://www.linux-mips.org/archives/linux-mips/2004-01/msg00000.html.
> 
> After that fix, user space stuff started to work for me.
> 

Yes, that is a temporary fix for the problem.

bcm1250 PCI still have issues though.  I have not looked into it.

What is troubling me most is either rockhopper nor malta works on 2.6.
With rockhopper I had to disable cache in order to run.  I
suspect there is something fundamental still not quite right, possibly
only affecting cache noncoherent systems.

More debugging fun ...

Jun

From ralf@linux-mips.org Tue Jan 13 22:46:07 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 13 Jan 2004 22:46:08 +0000 (GMT)
Received: from p508B5C01.dip.t-dialin.net ([IPv6:::ffff:80.139.92.1]:40320
	"EHLO mail.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225382AbUAMWqH>; Tue, 13 Jan 2004 22:46:07 +0000
Received: from fluff.linux-mips.net (fluff.linux-mips.net [127.0.0.1])
	by mail.linux-mips.net (8.12.8/8.12.8) with ESMTP id i0DMjwDs006132;
	Tue, 13 Jan 2004 23:45:58 +0100
Received: (from ralf@localhost)
	by fluff.linux-mips.net (8.12.8/8.12.8/Submit) id i0DMjqAM006131;
	Tue, 13 Jan 2004 23:45:52 +0100
Date: Tue, 13 Jan 2004 23:45:52 +0100
From: Ralf Baechle <ralf@linux-mips.org>
To: Jun Sun <jsun@mvista.com>
Cc: Dimitri Torfs <dimitri@sonycom.com>,
	Pete Popov <ppopov@mvista.com>, kph@cisco.com,
	Linux MIPS mailing list <linux-mips@linux-mips.org>
Subject: Re: How stable is 2.6 on a SB1250 processor?
Message-ID: <20040113224552.GA6001@linux-mips.org>
References: <1074027809.20636.91.camel@shakedown> <1074028164.21857.120.camel@zeus.mvista.com> <20040113214454.GA2737@sonycom.com> <20040113143137.N11733@mvista.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20040113143137.N11733@mvista.com>
User-Agent: Mutt/1.4i
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: 3933
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 13, 2004 at 02:31:37PM -0800, Jun Sun wrote:

> What is troubling me most is either rockhopper nor malta works on 2.6.

I have a success report with 2.6 on Malta from yesterday.  I'll check if
any patching was required but I'm interested in your Malta's configuration.

  Ralf

From jsun@mvista.com Tue Jan 13 23:02:29 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 13 Jan 2004 23:02:31 +0000 (GMT)
Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:60401 "EHLO
	orion.mvista.com") by linux-mips.org with ESMTP id <S8225382AbUAMXC3>;
	Tue, 13 Jan 2004 23:02:29 +0000
Received: (from jsun@localhost)
	by orion.mvista.com (8.11.6/8.11.6) id i0DN2RA30011;
	Tue, 13 Jan 2004 15:02:27 -0800
Date: Tue, 13 Jan 2004 15:02:27 -0800
From: Jun Sun <jsun@mvista.com>
To: Ralf Baechle <ralf@linux-mips.org>
Cc: Dimitri Torfs <dimitri@sonycom.com>,
	Pete Popov <ppopov@mvista.com>, kph@cisco.com,
	Linux MIPS mailing list <linux-mips@linux-mips.org>,
	jsun@mvista.com
Subject: Re: How stable is 2.6 on a SB1250 processor?
Message-ID: <20040113150227.O11733@mvista.com>
References: <1074027809.20636.91.camel@shakedown> <1074028164.21857.120.camel@zeus.mvista.com> <20040113214454.GA2737@sonycom.com> <20040113143137.N11733@mvista.com> <20040113224552.GA6001@linux-mips.org>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="1UWUbFP1cBYEclgG"
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <20040113224552.GA6001@linux-mips.org>; from ralf@linux-mips.org on Tue, Jan 13, 2004 at 11:45:52PM +0100
Return-Path: <jsun@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: 3934
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


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

On Tue, Jan 13, 2004 at 11:45:52PM +0100, Ralf Baechle wrote:
> On Tue, Jan 13, 2004 at 02:31:37PM -0800, Jun Sun wrote:
> 
> > What is troubling me most is either rockhopper nor malta works on 2.6.
> 
> I have a success report with 2.6 on Malta from yesterday.  I'll check if
> any patching was required but I'm interested in your Malta's configuration.
> 

Here is the config I am using ... with access_ok() fix.

Jun

--1UWUbFP1cBYEclgG
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename=".config"

#
# Automatically generated make config: don't edit
#
CONFIG_MIPS=y
# CONFIG_MIPS64 is not set
# CONFIG_64BIT is not set
CONFIG_MIPS32=y

#
# Code maturity level options
#
CONFIG_EXPERIMENTAL=y
CONFIG_CLEAN_COMPILE=y
CONFIG_STANDALONE=y
CONFIG_BROKEN_ON_SMP=y

#
# General setup
#
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
# CONFIG_BSD_PROCESS_ACCT is not set
CONFIG_SYSCTL=y
CONFIG_LOG_BUF_SHIFT=14
# CONFIG_IKCONFIG is not set
CONFIG_EMBEDDED=y
CONFIG_KALLSYMS=y
CONFIG_FUTEX=y
CONFIG_EPOLL=y
CONFIG_IOSCHED_NOOP=y
CONFIG_IOSCHED_AS=y
CONFIG_IOSCHED_DEADLINE=y

#
# Loadable module support
#
CONFIG_MODULES=y
CONFIG_MODULE_UNLOAD=y
# CONFIG_MODULE_FORCE_UNLOAD is not set
CONFIG_OBSOLETE_MODPARM=y
CONFIG_MODVERSIONS=y
CONFIG_KMOD=y

#
# Machine selection
#
# CONFIG_MACH_JAZZ is not set
# CONFIG_BAGET_MIPS is not set
# CONFIG_MACH_VR41XX is not set
# CONFIG_TOSHIBA_JMR3927 is not set
# CONFIG_MIPS_COBALT is not set
# CONFIG_MACH_DECSTATION is not set
# CONFIG_MIPS_EV64120 is not set
# CONFIG_MIPS_EV96100 is not set
# CONFIG_MIPS_IVR is not set
# CONFIG_LASAT is not set
# CONFIG_HP_LASERJET is not set
# CONFIG_MIPS_ITE8172 is not set
# CONFIG_MIPS_ATLAS is not set
CONFIG_MIPS_MALTA=y
# CONFIG_MIPS_SEAD is not set
# CONFIG_MOMENCO_OCELOT is not set
# CONFIG_MOMENCO_OCELOT_G is not set
# CONFIG_MOMENCO_OCELOT_C is not set
# CONFIG_MOMENCO_JAGUAR_ATX is not set
# CONFIG_PMC_YOSEMITE is not set
# CONFIG_DDB5074 is not set
# CONFIG_DDB5476 is not set
# CONFIG_DDB5477 is not set
# CONFIG_NEC_OSPREY is not set
# CONFIG_SGI_IP22 is not set
# CONFIG_SGI_IP32 is not set
# CONFIG_MACH_AU1X00 is not set
# CONFIG_SIBYTE_SB1xxx_SOC is not set
# CONFIG_SNI_RM200_PCI is not set
# CONFIG_TOSHIBA_RBTX4927 is not set
CONFIG_RWSEM_GENERIC_SPINLOCK=y
CONFIG_HAVE_DEC_LOCK=y
CONFIG_DMA_NONCOHERENT=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_I8259=y
CONFIG_MIPS_BONITO64=y
CONFIG_MIPS_MSC=y
CONFIG_CPU_LITTLE_ENDIAN=y
CONFIG_MIPS_BOARDS_GEN=y
CONFIG_MIPS_GT64120=y
CONFIG_SWAP_IO_SPACE=y
CONFIG_BOOT_ELF32=y
CONFIG_MIPS_L1_CACHE_SHIFT=5
# CONFIG_FB is not set
CONFIG_HAVE_STD_PC_SERIAL_PORT=y

#
# CPU selection
#
CONFIG_CPU_MIPS32=y
# CONFIG_CPU_MIPS64 is not set
# CONFIG_CPU_R3000 is not set
# CONFIG_CPU_TX39XX is not set
# CONFIG_CPU_VR41XX is not set
# CONFIG_CPU_R4300 is not set
# CONFIG_CPU_R4X00 is not set
# CONFIG_CPU_TX49XX is not set
# CONFIG_CPU_R5000 is not set
# CONFIG_CPU_R5432 is not set
# CONFIG_CPU_R6000 is not set
# CONFIG_CPU_NEVADA is not set
# CONFIG_CPU_R8000 is not set
# CONFIG_CPU_R10000 is not set
# CONFIG_CPU_RM7000 is not set
# CONFIG_CPU_RM9000 is not set
# CONFIG_CPU_SB1 is not set
CONFIG_PAGE_SIZE_4KB=y
# CONFIG_PAGE_SIZE_16KB is not set
# CONFIG_PAGE_SIZE_64KB is not set
CONFIG_CPU_HAS_PREFETCH=y
# CONFIG_VTAG_ICACHE is not set
# CONFIG_64BIT_PHYS_ADDR is not set
# CONFIG_CPU_ADVANCED is not set
CONFIG_CPU_HAS_LLSC=y
CONFIG_CPU_HAS_SYNC=y
# CONFIG_PREEMPT is not set
# CONFIG_DEBUG_INFO is not set
# CONFIG_DEBUG_SPINLOCK is not set
# CONFIG_DEBUG_SPINLOCK_SLEEP is not set

#
# Bus options (PCI, PCMCIA, EISA, ISA, TC)
#
CONFIG_PCI=y
CONFIG_PCI_LEGACY_PROC=y
CONFIG_PCI_NAMES=y
CONFIG_MMU=y
# CONFIG_HOTPLUG is not set

#
# Executable file formats
#
CONFIG_BINFMT_ELF=y
# CONFIG_BINFMT_MISC is not set
CONFIG_TRAD_SIGNALS=y

#
# MIPS initrd options
#
CONFIG_EMBEDDED_RAMDISK=y
CONFIG_EMBEDDED_RAMDISK_IMAGE="ramdisk.gz"

#
# Device Drivers
#

#
# Generic Driver Options
#

#
# Memory Technology Devices (MTD)
#
# CONFIG_MTD is not set

#
# Parallel port support
#
# CONFIG_PARPORT is not set

#
# Plug and Play support
#
# CONFIG_PNP is not set

#
# Block devices
#
# CONFIG_BLK_DEV_FD is not set
# CONFIG_BLK_CPQ_DA is not set
# CONFIG_BLK_CPQ_CISS_DA is not set
# CONFIG_BLK_DEV_DAC960 is not set
# CONFIG_BLK_DEV_UMEM is not set
# CONFIG_BLK_DEV_LOOP is not set
# CONFIG_BLK_DEV_NBD is not set
CONFIG_BLK_DEV_RAM=y
CONFIG_BLK_DEV_RAM_SIZE=16384
CONFIG_BLK_DEV_INITRD=y
# CONFIG_LBD is not set

#
# ATA/ATAPI/MFM/RLL support
#
# CONFIG_IDE is not set

#
# SCSI device support
#
# CONFIG_SCSI is not set

#
# Multi-device support (RAID and LVM)
#
# CONFIG_MD is not set

#
# Fusion MPT device support
#

#
# IEEE 1394 (FireWire) support (EXPERIMENTAL)
#
# CONFIG_IEEE1394 is not set

#
# I2O device support
#
# CONFIG_I2O is not set

#
# Networking support
#
CONFIG_NET=y

#
# Networking options
#
# CONFIG_PACKET is not set
CONFIG_NETLINK_DEV=y
CONFIG_UNIX=y
CONFIG_NET_KEY=y
CONFIG_INET=y
# CONFIG_IP_MULTICAST is not set
# CONFIG_IP_ADVANCED_ROUTER is not set
CONFIG_IP_PNP=y
CONFIG_IP_PNP_DHCP=y
CONFIG_IP_PNP_BOOTP=y
# CONFIG_IP_PNP_RARP is not set
# CONFIG_NET_IPIP is not set
# CONFIG_NET_IPGRE is not set
# CONFIG_ARPD is not set
# CONFIG_INET_ECN is not set
# CONFIG_SYN_COOKIES is not set
# CONFIG_INET_AH is not set
# CONFIG_INET_ESP is not set
# CONFIG_INET_IPCOMP is not set
# CONFIG_IPV6 is not set
# CONFIG_DECNET is not set
# CONFIG_BRIDGE is not set
# CONFIG_NETFILTER is not set
CONFIG_XFRM=y
# CONFIG_XFRM_USER is not set

#
# SCTP Configuration (EXPERIMENTAL)
#
CONFIG_IPV6_SCTP__=y
# CONFIG_IP_SCTP is not set
# CONFIG_ATM is not set
# CONFIG_VLAN_8021Q is not set
# CONFIG_LLC2 is not set
# CONFIG_IPX is not set
# CONFIG_ATALK is not set
# CONFIG_X25 is not set
# CONFIG_LAPB is not set
# CONFIG_NET_DIVERT is not set
# CONFIG_ECONET is not set
# CONFIG_WAN_ROUTER is not set
# CONFIG_NET_FASTROUTE is not set
# CONFIG_NET_HW_FLOWCONTROL is not set

#
# QoS and/or fair queueing
#
# CONFIG_NET_SCHED is not set

#
# Network testing
#
# CONFIG_NET_PKTGEN is not set
CONFIG_NETDEVICES=y

#
# ARCnet devices
#
# CONFIG_ARCNET is not set
# CONFIG_DUMMY is not set
# CONFIG_BONDING is not set
# CONFIG_EQUALIZER is not set
# CONFIG_TUN is not set
# CONFIG_ETHERTAP is not set

#
# Ethernet (10 or 100Mbit)
#
CONFIG_NET_ETHERNET=y
CONFIG_MII=y
# CONFIG_HAPPYMEAL is not set
# CONFIG_SUNGEM is not set
# CONFIG_NET_VENDOR_3COM is not set

#
# Tulip family network device support
#
# CONFIG_NET_TULIP is not set
# CONFIG_HP100 is not set
CONFIG_NET_PCI=y
CONFIG_PCNET32=y
# CONFIG_AMD8111_ETH is not set
# CONFIG_ADAPTEC_STARFIRE is not set
# CONFIG_B44 is not set
# CONFIG_DGRS is not set
# CONFIG_EEPRO100 is not set
# CONFIG_E100 is not set
# CONFIG_FEALNX is not set
# CONFIG_NATSEMI is not set
# CONFIG_NE2K_PCI is not set
# CONFIG_8139CP is not set
# CONFIG_8139TOO is not set
# CONFIG_SIS900 is not set
# CONFIG_EPIC100 is not set
# CONFIG_SUNDANCE is not set
# CONFIG_TLAN is not set
# CONFIG_VIA_RHINE is not set
# CONFIG_LAN_SAA9730 is not set

#
# Ethernet (1000 Mbit)
#
# CONFIG_ACENIC is not set
# CONFIG_DL2K is not set
# CONFIG_E1000 is not set
# CONFIG_NS83820 is not set
# CONFIG_HAMACHI is not set
# CONFIG_YELLOWFIN is not set
# CONFIG_R8169 is not set
# CONFIG_SIS190 is not set
# CONFIG_SK98LIN is not set
# CONFIG_TIGON3 is not set

#
# Ethernet (10000 Mbit)
#
# CONFIG_IXGB is not set
# CONFIG_FDDI is not set
# CONFIG_HIPPI is not set
# CONFIG_PPP is not set
# CONFIG_SLIP is not set

#
# Wireless LAN (non-hamradio)
#
# CONFIG_NET_RADIO is not set

#
# Token Ring devices
#
# CONFIG_TR is not set
# CONFIG_RCPCI is not set
# CONFIG_SHAPER is not set

#
# Wan interfaces
#
# CONFIG_WAN is not set

#
# Amateur Radio support
#
# CONFIG_HAMRADIO is not set

#
# IrDA (infrared) support
#
# CONFIG_IRDA is not set

#
# Bluetooth support
#
# CONFIG_BT is not set

#
# ISDN subsystem
#
# CONFIG_ISDN_BOOL is not set

#
# Telephony Support
#
# CONFIG_PHONE is not set

#
# Input device support
#
CONFIG_INPUT=y

#
# Userland interfaces
#
CONFIG_INPUT_MOUSEDEV=y
CONFIG_INPUT_MOUSEDEV_PSAUX=y
CONFIG_INPUT_MOUSEDEV_SCREEN_X=1024
CONFIG_INPUT_MOUSEDEV_SCREEN_Y=768
# CONFIG_INPUT_JOYDEV is not set
# CONFIG_INPUT_TSDEV is not set
# CONFIG_INPUT_EVDEV is not set
# CONFIG_INPUT_EVBUG is not set

#
# Input I/O drivers
#
# CONFIG_GAMEPORT is not set
CONFIG_SOUND_GAMEPORT=y
CONFIG_SERIO=y
# CONFIG_SERIO_I8042 is not set
CONFIG_SERIO_SERPORT=y
# CONFIG_SERIO_CT82C710 is not set
# CONFIG_SERIO_PCIPS2 is not set

#
# Input Device Drivers
#
# CONFIG_INPUT_KEYBOARD is not set
# CONFIG_INPUT_MOUSE is not set
# CONFIG_INPUT_JOYSTICK is not set
# CONFIG_INPUT_TOUCHSCREEN is not set
# CONFIG_INPUT_MISC is not set

#
# Character devices
#
CONFIG_VT=y
CONFIG_VT_CONSOLE=y
CONFIG_HW_CONSOLE=y
# CONFIG_SERIAL_NONSTANDARD is not set

#
# Serial drivers
#
CONFIG_SERIAL_8250=y
CONFIG_SERIAL_8250_CONSOLE=y
CONFIG_SERIAL_8250_NR_UARTS=4
# CONFIG_SERIAL_8250_EXTENDED is not set

#
# Non-8250 serial port support
#
CONFIG_SERIAL_CORE=y
CONFIG_SERIAL_CORE_CONSOLE=y
CONFIG_UNIX98_PTYS=y
CONFIG_UNIX98_PTY_COUNT=256

#
# I2C support
#
# CONFIG_I2C is not set

#
# I2C Algorithms
#

#
# I2C Hardware Bus support
#

#
# I2C Hardware Sensors Chip support
#
# CONFIG_I2C_SENSOR is not set

#
# Mice
#
# CONFIG_BUSMOUSE is not set
# CONFIG_QIC02_TAPE is not set

#
# IPMI
#
# CONFIG_IPMI_HANDLER is not set

#
# Watchdog Cards
#
# CONFIG_WATCHDOG is not set
# CONFIG_NVRAM is not set
CONFIG_RTC=y
# CONFIG_DTLK is not set
# CONFIG_R3964 is not set
# CONFIG_APPLICOM is not set

#
# Ftape, the floppy tape device driver
#
# CONFIG_FTAPE is not set
# CONFIG_AGP is not set
# CONFIG_DRM is not set
# CONFIG_RAW_DRIVER is not set

#
# Multimedia devices
#
# CONFIG_VIDEO_DEV is not set

#
# Digital Video Broadcasting Devices
#
# CONFIG_DVB is not set

#
# Graphics support
#

#
# Console display driver support
#
# CONFIG_VGA_CONSOLE is not set
# CONFIG_MDA_CONSOLE is not set
CONFIG_DUMMY_CONSOLE=y

#
# Sound
#
# CONFIG_SOUND is not set

#
# USB support
#
# CONFIG_USB is not set
# CONFIG_USB_GADGET is not set

#
# File systems
#
CONFIG_EXT2_FS=y
# CONFIG_EXT2_FS_XATTR is not set
# CONFIG_EXT3_FS is not set
# CONFIG_JBD is not set
# CONFIG_REISERFS_FS is not set
# CONFIG_JFS_FS is not set
# CONFIG_XFS_FS is not set
# CONFIG_MINIX_FS is not set
# CONFIG_ROMFS_FS is not set
# CONFIG_QUOTA is not set
CONFIG_AUTOFS_FS=y
# CONFIG_AUTOFS4_FS is not set

#
# CD-ROM/DVD Filesystems
#
# CONFIG_ISO9660_FS is not set
# CONFIG_UDF_FS is not set

#
# DOS/FAT/NT Filesystems
#
# CONFIG_FAT_FS is not set
# CONFIG_NTFS_FS is not set

#
# Pseudo filesystems
#
CONFIG_PROC_FS=y
CONFIG_PROC_KCORE=y
# CONFIG_DEVFS_FS is not set
CONFIG_DEVPTS_FS=y
CONFIG_DEVPTS_FS_XATTR=y
CONFIG_DEVPTS_FS_SECURITY=y
# CONFIG_TMPFS is not set
# CONFIG_HUGETLB_PAGE is not set
CONFIG_RAMFS=y

#
# Miscellaneous filesystems
#
# CONFIG_ADFS_FS is not set
# CONFIG_AFFS_FS is not set
# CONFIG_HFS_FS is not set
# CONFIG_BEFS_FS is not set
# CONFIG_BFS_FS is not set
CONFIG_EFS_FS=y
# CONFIG_CRAMFS is not set
# CONFIG_VXFS_FS is not set
# CONFIG_HPFS_FS is not set
# CONFIG_QNX4FS_FS is not set
# CONFIG_SYSV_FS is not set
# CONFIG_UFS_FS is not set

#
# Network File Systems
#
CONFIG_NFS_FS=y
CONFIG_NFS_V3=y
# CONFIG_NFS_V4 is not set
# CONFIG_NFS_DIRECTIO is not set
CONFIG_NFSD=y
CONFIG_NFSD_V3=y
# CONFIG_NFSD_V4 is not set
# CONFIG_NFSD_TCP is not set
CONFIG_ROOT_NFS=y
CONFIG_LOCKD=y
CONFIG_LOCKD_V4=y
CONFIG_EXPORTFS=y
CONFIG_SUNRPC=y
# CONFIG_SUNRPC_GSS is not set
# CONFIG_SMB_FS is not set
# CONFIG_CIFS is not set
# CONFIG_NCP_FS is not set
# CONFIG_CODA_FS is not set
# CONFIG_INTERMEZZO_FS is not set
# CONFIG_AFS_FS is not set

#
# Partition Types
#
# CONFIG_PARTITION_ADVANCED is not set
CONFIG_MSDOS_PARTITION=y

#
# Kernel hacking
#
CONFIG_CROSSCOMPILE=y
CONFIG_DEBUG_KERNEL=y
# CONFIG_KGDB is not set
# CONFIG_RUNTIME_DEBUG is not set
# CONFIG_MAGIC_SYSRQ is not set
CONFIG_MIPS_UNCACHED=y

#
# Security options
#
# CONFIG_SECURITY is not set

#
# Cryptographic options
#
# CONFIG_CRYPTO is not set

#
# Library routines
#
CONFIG_CRC32=y

--1UWUbFP1cBYEclgG--

From sagarwal10@hotmail.com Wed Jan 14 06:36:47 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 14 Jan 2004 06:36:50 +0000 (GMT)
Received: from bay10-f117.bay10.hotmail.com ([IPv6:::ffff:64.4.37.117]:41746
	"EHLO hotmail.com") by linux-mips.org with ESMTP
	id <S8225240AbUANGgr>; Wed, 14 Jan 2004 06:36:47 +0000
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Tue, 13 Jan 2004 22:36:39 -0800
Received: from 63.203.69.252 by by10fd.bay10.hotmail.msn.com with HTTP;
	Wed, 14 Jan 2004 06:36:39 GMT
X-Originating-IP: [63.203.69.252]
X-Originating-Email: [sagarwal10@hotmail.com]
X-Sender: sagarwal10@hotmail.com
From: "Samuel Agarwal" <sagarwal10@hotmail.com>
To: linux-mips@linux-mips.org, linuxppc-embedded@lists.linuxppc.org
Subject: Intel Pro 82546 chipset performance
Date: Wed, 14 Jan 2004 06:36:39 +0000
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: <BAY10-F117sntMQN8zy00008864@hotmail.com>
X-OriginalArrivalTime: 14 Jan 2004 06:36:39.0628 (UTC) FILETIME=[C3FFC8C0:01C3DA68]
Return-Path: <sagarwal10@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: 3935
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: sagarwal10@hotmail.com
Precedence: bulk
X-list: linux-mips

Hi

We're trying to use the Intel Pro 1000 adapters with the 82546 chipset
for a packet switching application. Has anyone investigated performance
on this chipset? With minimum sized ethernet frames, the maximum throughput
I can get is about 1 million packets per second (versus a 1.4 mill for line 
rate
on a gigethernet) and it looks that performance is skewed towards receiving
traffic (rather than sending out).

If anyone has any opinions or thoughts I'd appreciate them. It's hard to
get information out of Intel.

_________________________________________________________________
Find out everything you need to know about Las Vegas here for that getaway.  
http://special.msn.com/msnbc/vivalasvegas.armx


From jr@mycable.de Wed Jan 14 08:08:49 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 14 Jan 2004 08:08:50 +0000 (GMT)
Received: from mail.oricom.de ([IPv6:::ffff:62.116.167.108]:35490 "EHLO
	oricom4.internetx.de") by linux-mips.org with ESMTP
	id <S8225240AbUANIIt>; Wed, 14 Jan 2004 08:08:49 +0000
Received: from mycable.de (p5086BBEF.dip.t-dialin.net [80.134.187.239])
	(authenticated bits=0)
	by oricom4.internetx.de (8.12.8/8.12.8) with ESMTP id i0E86roK023728;
	Wed, 14 Jan 2004 09:06:54 +0100
Message-ID: <4004F8C3.5080500@mycable.de>
Date: Wed, 14 Jan 2004 09:07:31 +0100
From: Joerg Ritter <jr@mycable.de>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Goswin von Brederlow <brederlo@informatik.uni-tuebingen.de>
CC: Linux MIPS mailing list <linux-mips@linux-mips.org>
Subject: Re: Kernel oops on XXS1500 in au1000eth.c
References: <87lloblo27.fsf@mrvn.homelinux.org>	<1074018143.21864.13.camel@zeus.mvista.com> <87d69nlmp7.fsf@mrvn.homelinux.org>
In-Reply-To: <87d69nlmp7.fsf@mrvn.homelinux.org>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Return-Path: <jr@mycable.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: 3936
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: jr@mycable.de
Precedence: bulk
X-list: linux-mips

> 
> Maybe some
> 
> if (mach == MACH_XXS1500) ...
> 
> construct? The MACH_XXS1500 must be good for something.
> 
> Hopefully MyCable will change the name when they design a new board
> with a different network thing.
> 

We will...

Greetings
Joerg


-- 

-------------------------------------------------------
Joerg Ritter        Tel: +49 48 73 90 10 866
mycable GmbH        Fax: +49 48 73 90 19 76
Boeker Stieg 43
D-24613 Aukrug      eMail: jr@mycable.de
-------------------------------------------------------


From macro@ds2.pg.gda.pl Wed Jan 14 12:01:28 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 14 Jan 2004 12:01:32 +0000 (GMT)
Received: from jurand.ds.pg.gda.pl ([IPv6:::ffff:153.19.208.2]:44257 "EHLO
	jurand.ds.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8225337AbUANMB2>; Wed, 14 Jan 2004 12:01:28 +0000
Received: by jurand.ds.pg.gda.pl (Postfix, from userid 1011)
	id B33394C15E; Wed, 14 Jan 2004 13:01:25 +0100 (CET)
Received: from localhost (localhost [127.0.0.1])
	by jurand.ds.pg.gda.pl (Postfix) with ESMTP
	id 9ED9D44F05; Wed, 14 Jan 2004 13:01:25 +0100 (CET)
Date: Wed, 14 Jan 2004 13:01:25 +0100 (CET)
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To: Adrian Bunk <bunk@fs.tum.de>
Cc: Ralf Baechle <ralf@linux-mips.org>, linux-mips@linux-mips.org,
	linux-kernel@vger.kernel.org
Subject: Re: [2.6 patch] fix DECSTATION depends
In-Reply-To: <20040113172751.GN9677@fs.tum.de>
Message-ID: <Pine.LNX.4.55.0401141230400.1436@jurand.ds.pg.gda.pl>
References: <20040113015202.GE9677@fs.tum.de> <20040113022826.GC1646@linux-mips.org>
 <Pine.LNX.4.55.0401131401300.21962@jurand.ds.pg.gda.pl> <20040113172751.GN9677@fs.tum.de>
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: 3937
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, 13 Jan 2004, Adrian Bunk wrote:

> Does -mabi=64 really work on any DECstation?
> 
> AFAIK none of the R2000, R3x00 and the R4x00 do support the 64bit ABI.

 Well, the R4000 and the R4400 implement the MIPS3 ISA (the R4000 was
actually first to implement it) and are thus obviously 64-bit processors.  
And I'm actually using a 64-bit kernel on my R4k DECstations routinely --
currently I'm torturing it on my 5000/260 with gcc 3.4 bootstraps and it
seems quite happy -- it appears rock-solid.

 The problem is the official kernel would work fine for a 64-bit
DECstation if it had an R4400 rev.2.0 or later.  I haven't heard of any
having such a processor -- the ones I have and the others reported by
poeple have either an R4000 rev.3.0 or an R4400 rev.1.0.  These processors
have errata that lead to erroneous behavior in a few common 64-bit
operations (according to the errata sheet, the R4000 actually has a
serious 32-bit erratum as well, but I haven't been able to trigger it
yet).  I have implemented appropriate workarounds (available upon
request), but they require changes not only to Linux, but to gcc and gas
as well.  I'm preparing to merge the changes to the tools -- hence my
current gcc 3.4 effort -- but until then the 64-bit port has to be marked
as experimental (marking R4000 and R4400 processor selections as such for
64-bit operation would be more accurate, but currently we don't have a
separate setting for them).

 See also arch/mips/dec/prom/call_o32.S for the only chunk of explicit
support code for 64-bit operation for the DECstation -- everything else
just works as is (modulo possible protability bugs in drivers).

 Going back to the subject -- what's the problem with dependencies?

  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 Wed Jan 14 15:25:36 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 14 Jan 2004 15:25:37 +0000 (GMT)
Received: from jurand.ds.pg.gda.pl ([IPv6:::ffff:153.19.208.2]:27063 "EHLO
	jurand.ds.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8225357AbUANPZf>; Wed, 14 Jan 2004 15:25:35 +0000
Received: by jurand.ds.pg.gda.pl (Postfix, from userid 1011)
	id 4B8464BE10; Wed, 14 Jan 2004 16:25:33 +0100 (CET)
Received: from localhost (localhost [127.0.0.1])
	by jurand.ds.pg.gda.pl (Postfix) with ESMTP
	id 3BCA244F39; Wed, 14 Jan 2004 16:25:33 +0100 (CET)
Date: Wed, 14 Jan 2004 16:25:33 +0100 (CET)
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To: Dan Aizenstros <dan@quicklogic.com>, Pete Popov <ppopov@mvista.com>
Cc: linux-mips@linux-mips.org
Subject: Re: CVS Update@-mips.org: linux
In-Reply-To: <4004295F.9060104@quicklogic.com>
Message-ID: <Pine.LNX.4.55.0401141623210.9549@jurand.ds.pg.gda.pl>
References: <20040113080926Z8225270-16706+2387@linux-mips.org>
 <4004295F.9060104@quicklogic.com>
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: 3938
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, 13 Jan 2004, Dan Aizenstros wrote:

> You broke any build that does not define CONFIG_SERIAL_AU1X00
> by adding an #error in the include/asm-mips/serial.h file.
> 
> -- Dan A.
> 
> ppopov@linux-mips.org wrote:
> 
> > CVSROOT:	/home/cvs
> > Module name:	linux
> > Changes by:	ppopov@ftp.linux-mips.org	04/01/13 08:09:22

 Thanks for the report.  It looks like a typo.  I've removed the #error
statement -- Pete please check if that's what's intended.

  Maciej

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

From nmckee@telogy.com Wed Jan 14 15:59:31 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 14 Jan 2004 15:59:31 +0000 (GMT)
Received: from [IPv6:::ffff:209.116.120.7] ([IPv6:::ffff:209.116.120.7]:2317
	"EHLO tnint11.telogy.design.ti.com") by linux-mips.org with ESMTP
	id <S8225393AbUANP7b>; Wed, 14 Jan 2004 15:59:31 +0000
Received: by tnint11.telogy.design.ti.com with Internet Mail Service (5.5.2653.19)
	id <Z8T14LDD>; Wed, 14 Jan 2004 10:58:42 -0500
Message-ID: <37A3C2F21006D611995100B0D0F9B73C04F11125@tnint11.telogy.design.ti.com>
From: "Zajerko-McKee, Nick" <nmckee@telogy.com>
To: linux-mips@linux-mips.org
Subject: Correct assembler/compiler options for 4KC core?
Date: Wed, 14 Jan 2004 10:58:32 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
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: 3939
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

Hi,

I'm trying to use the following opcodes: movz, movn, clo, clz, madd, msub on
both a 4KC and 4KeC core. What gas options should I use to get the above
opcodes to work (mips4?  mips32?)  How would one link against closed source
libraries that were compiled for mips2?  Is there a list of what opcodes
correspond to the various ISA's and gas flags?  The best reference I saw was
from fsf that just mentions the -mips1/-mips2/-mips3/-mips4.  I did notice
in the latest gas docs -march option, but I don't see that available in my
toolchain.  I'm running on a development system with gas 2.9.5 and gcc 2.96.

TIA,

Nick Zajerko-McKee

From ica2_ts@csv.ica.uni-stuttgart.de Wed Jan 14 16:50:30 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 14 Jan 2004 16:50:32 +0000 (GMT)
Received: from iris1.csv.ica.uni-stuttgart.de ([IPv6:::ffff:129.69.118.2]:48395
	"EHLO iris1.csv.ica.uni-stuttgart.de") by linux-mips.org with ESMTP
	id <S8225342AbUANQua>; Wed, 14 Jan 2004 16:50:30 +0000
Received: from rembrandt.csv.ica.uni-stuttgart.de ([129.69.118.42])
	by iris1.csv.ica.uni-stuttgart.de with esmtp
	id 1AgoDq-0005LN-00; Wed, 14 Jan 2004 17:50:26 +0100
Received: from ica2_ts by rembrandt.csv.ica.uni-stuttgart.de with local (Exim 3.35 #1 (Debian))
	id 1AgoDp-0007iI-00; Wed, 14 Jan 2004 17:50:25 +0100
Date: Wed, 14 Jan 2004 17:50:25 +0100
To: "Zajerko-McKee, Nick" <nmckee@telogy.com>
Cc: linux-mips@linux-mips.org
Subject: Re: Correct assembler/compiler options for 4KC core?
Message-ID: <20040114165025.GB22218@rembrandt.csv.ica.uni-stuttgart.de>
References: <37A3C2F21006D611995100B0D0F9B73C04F11125@tnint11.telogy.design.ti.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <37A3C2F21006D611995100B0D0F9B73C04F11125@tnint11.telogy.design.ti.com>
User-Agent: Mutt/1.5.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: 3940
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

Zajerko-McKee, Nick wrote:
> Hi,
> 
> I'm trying to use the following opcodes: movz, movn, clo, clz, madd, msub on
> both a 4KC and 4KeC core. What gas options should I use to get the above
> opcodes to work (mips4?  mips32?)

With a modern toolchain: -march=mips32.

> How would one link against closed source
> libraries that were compiled for mips2?

This will just work if you use a recent binutils version, and if the
libraries are O32 ABI conformant.

> Is there a list of what opcodes
> correspond to the various ISA's and gas flags?  The best reference I saw was
> from fsf that just mentions the -mips1/-mips2/-mips3/-mips4. I did notice
> in the latest gas docs -march option,

-mips32 is retained as an alias for -march=mips32.

> but I don't see that available in my
> toolchain.  I'm running on a development system with gas 2.9.5 and gcc 2.96.

gas 2.9.5 is _very_ old. It might be possible to use "-mips4 -mgp32" for
movn, movz, but I'm not sure if this actually works. For the other opcodes
the toolchain is just too old.


Thiemo

From ralf@linux-mips.org Wed Jan 14 17:02:13 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 14 Jan 2004 17:02:13 +0000 (GMT)
Received: from p508B5F0A.dip.t-dialin.net ([IPv6:::ffff:80.139.95.10]:59789
	"EHLO mail.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225405AbUANRCN>; Wed, 14 Jan 2004 17:02:13 +0000
Received: from fluff.linux-mips.net (fluff.linux-mips.net [127.0.0.1])
	by mail.linux-mips.net (8.12.8/8.12.8) with ESMTP id i0EH03Ds026382;
	Wed, 14 Jan 2004 18:00:03 +0100
Received: (from ralf@localhost)
	by fluff.linux-mips.net (8.12.8/8.12.8/Submit) id i0EH0195026381;
	Wed, 14 Jan 2004 18:00:01 +0100
Date: Wed, 14 Jan 2004 18:00:01 +0100
From: Ralf Baechle <ralf@linux-mips.org>
To: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
Cc: Adrian Bunk <bunk@fs.tum.de>, linux-mips@linux-mips.org
Subject: Re: [2.6 patch] fix DECSTATION depends
Message-ID: <20040114170001.GA20227@linux-mips.org>
References: <20040113015202.GE9677@fs.tum.de> <20040113022826.GC1646@linux-mips.org> <Pine.LNX.4.55.0401131401300.21962@jurand.ds.pg.gda.pl> <20040113172751.GN9677@fs.tum.de> <Pine.LNX.4.55.0401141230400.1436@jurand.ds.pg.gda.pl>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Pine.LNX.4.55.0401141230400.1436@jurand.ds.pg.gda.pl>
User-Agent: Mutt/1.4i
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: 3941
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 14, 2004 at 01:01:25PM +0100, Maciej W. Rozycki wrote:

>  The problem is the official kernel would work fine for a 64-bit
> DECstation if it had an R4400 rev.2.0 or later.  I haven't heard of any
> having such a processor -- the ones I have and the others reported by
> poeple have either an R4000 rev.3.0 or an R4400 rev.1.0.  These processors
> have errata that lead to erroneous behavior in a few common 64-bit
> operations (according to the errata sheet, the R4000 actually has a
> serious 32-bit erratum as well, but I haven't been able to trigger it
> yet).  I have implemented appropriate workarounds (available upon
> request), but they require changes not only to Linux, but to gcc and gas
> as well.  I'm preparing to merge the changes to the tools -- hence my
> current gcc 3.4 effort -- but until then the 64-bit port has to be marked
> as experimental (marking R4000 and R4400 processor selections as such for
> 64-bit operation would be more accurate, but currently we don't have a
> separate setting for them).
> 
>  See also arch/mips/dec/prom/call_o32.S for the only chunk of explicit
> support code for 64-bit operation for the DECstation -- everything else
> just works as is (modulo possible protability bugs in drivers).
> 
>  Going back to the subject -- what's the problem with dependencies?

Nothing.  It was looking like you meant something else and me and Adrian
got trapped by that.  Feel free to change it back to what it was but
maybe "depends on MIPS32 || (MIPS64 && EXPERIMENTAL)" is less ambigous?

  Ralf

From dkesselr@mmc.atmel.com Wed Jan 14 17:07:35 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 14 Jan 2004 17:07:38 +0000 (GMT)
Received: from 66-152-54-2.ded.btitelecom.net ([IPv6:::ffff:66.152.54.2]:35737
	"EHLO mmc.atmel.com") by linux-mips.org with ESMTP
	id <S8225414AbUANRHf>; Wed, 14 Jan 2004 17:07:35 +0000
Received: from ares.mmc.atmel.com (ares.mmc.atmel.com [10.127.240.37])
	by mmc.atmel.com (8.9.3/8.9.3) with ESMTP id MAA08534;
	Wed, 14 Jan 2004 12:07:23 -0500 (EST)
Received: from localhost (dkesselr@localhost)
	by ares.mmc.atmel.com (8.9.3/8.9.3) with ESMTP id MAA13945;
	Wed, 14 Jan 2004 12:07:22 -0500 (EST)
X-Authentication-Warning: ares.mmc.atmel.com: dkesselr owned process doing -bs
Date: Wed, 14 Jan 2004 12:07:22 -0500 (EST)
From: David Kesselring <dkesselr@mmc.atmel.com>
To: Thiemo Seufer <ica2_ts@csv.ica.uni-stuttgart.de>
cc: "Zajerko-McKee, Nick" <nmckee@telogy.com>,
	<linux-mips@linux-mips.org>
Subject: Re: Correct assembler/compiler options for 4KC core?
In-Reply-To: <20040114165025.GB22218@rembrandt.csv.ica.uni-stuttgart.de>
Message-ID: <Pine.GSO.4.44.0401141200460.13057-100000@ares.mmc.atmel.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <dkesselr@mmc.atmel.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: 3942
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: dkesselr@mmc.atmel.com
Precedence: bulk
X-list: linux-mips

If 2.95 is too old for him, where should he(and I) get the latest stable
packages. It seems like the MIPS environment is varied and there are
toolchains for various processors in different locations. Is the toolchain
and binutils for 4k/5k processors on the linux-mips.org ftp site?
Is the correct gcc 3.2.xx? Will it build 2.4.2x that is in linux-mips cvs?
Will it build 2.6? Will it build 64bit kernels? It would be nice if
someone in the know could create a chart or add the info to readme or
howto on linux-mips.org site.
Thanks for sharing what you know.
David


On Wed, 14 Jan 2004, Thiemo Seufer wrote:

> Zajerko-McKee, Nick wrote:
> > Hi,
> >
> > I'm trying to use the following opcodes: movz, movn, clo, clz, madd, msub on
> > both a 4KC and 4KeC core. What gas options should I use to get the above
> > opcodes to work (mips4?  mips32?)
>
> With a modern toolchain: -march=mips32.
>
> > How would one link against closed source
> > libraries that were compiled for mips2?
>
> This will just work if you use a recent binutils version, and if the
> libraries are O32 ABI conformant.
>
> > Is there a list of what opcodes
> > correspond to the various ISA's and gas flags?  The best reference I saw was
> > from fsf that just mentions the -mips1/-mips2/-mips3/-mips4. I did notice
> > in the latest gas docs -march option,
>
> -mips32 is retained as an alias for -march=mips32.
>
> > but I don't see that available in my
> > toolchain.  I'm running on a development system with gas 2.9.5 and gcc 2.96.
>
> gas 2.9.5 is _very_ old. It might be possible to use "-mips4 -mgp32" for
> movn, movz, but I'm not sure if this actually works. For the other opcodes
> the toolchain is just too old.
>
>
> Thiemo
>

David Kesselring
Atmel MMC
dkesselr@mmc.atmel.com
919-462-6587


From macro@ds2.pg.gda.pl Wed Jan 14 17:24:30 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 14 Jan 2004 17:24:39 +0000 (GMT)
Received: from jurand.ds.pg.gda.pl ([IPv6:::ffff:153.19.208.2]:10221 "EHLO
	jurand.ds.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8225413AbUANRYa>; Wed, 14 Jan 2004 17:24:30 +0000
Received: by jurand.ds.pg.gda.pl (Postfix, from userid 1011)
	id 7AAB54C3A8; Wed, 14 Jan 2004 18:24:25 +0100 (CET)
Received: from localhost (localhost [127.0.0.1])
	by jurand.ds.pg.gda.pl (Postfix) with ESMTP
	id 57C464C15E; Wed, 14 Jan 2004 18:24:25 +0100 (CET)
Date: Wed, 14 Jan 2004 18:24:25 +0100 (CET)
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To: Ralf Baechle <ralf@linux-mips.org>
Cc: Adrian Bunk <bunk@fs.tum.de>, linux-mips@linux-mips.org
Subject: Re: [2.6 patch] fix DECSTATION depends
In-Reply-To: <20040114170001.GA20227@linux-mips.org>
Message-ID: <Pine.LNX.4.55.0401141808470.9549@jurand.ds.pg.gda.pl>
References: <20040113015202.GE9677@fs.tum.de> <20040113022826.GC1646@linux-mips.org>
 <Pine.LNX.4.55.0401131401300.21962@jurand.ds.pg.gda.pl> <20040113172751.GN9677@fs.tum.de>
 <Pine.LNX.4.55.0401141230400.1436@jurand.ds.pg.gda.pl>
 <20040114170001.GA20227@linux-mips.org>
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: 3943
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, 14 Jan 2004, Ralf Baechle wrote:

> >  Going back to the subject -- what's the problem with dependencies?
> 
> Nothing.  It was looking like you meant something else and me and Adrian
> got trapped by that.  Feel free to change it back to what it was but
> maybe "depends on MIPS32 || (MIPS64 && EXPERIMENTAL)" is less ambigous?

 I thought the construct triggered a problem elsewhere and the change was
supposed to work it around.  I'm pretty surprised you've forgotten I
ported the DECstation code to 64 bits -- it's already over a year and a
half since I did the first boot.

 I feel a bit hesitant about changing the expression, but perhaps I may
add a comment to the help text, on why it's experimental for 64-bit.  I
suspect hardly anyone will notice, though -- if built with unpatched tools
and run on a problematic processor the kernel complains and refuses to run
asking to contact <linux-mips@linux-mips.org> and nobody did that yet...

  Maciej

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

From ppopov@mvista.com Wed Jan 14 17:34:55 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 14 Jan 2004 17:34:55 +0000 (GMT)
Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:55795 "EHLO
	av.mvista.com") by linux-mips.org with ESMTP id <S8225413AbUANRez>;
	Wed, 14 Jan 2004 17:34:55 +0000
Received: from mvista.com (av [127.0.0.1])
	by av.mvista.com (8.9.3/8.9.3) with ESMTP id JAA05303;
	Wed, 14 Jan 2004 09:34:43 -0800
Message-ID: <40057DB2.7030505@mvista.com>
Date: Wed, 14 Jan 2004 09:34:42 -0800
From: Pete Popov <ppopov@mvista.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031007
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
CC: Dan Aizenstros <dan@quicklogic.com>, linux-mips@linux-mips.org
Subject: Re: CVS Update@-mips.org: linux
References: <20040113080926Z8225270-16706+2387@linux-mips.org> <4004295F.9060104@quicklogic.com> <Pine.LNX.4.55.0401141623210.9549@jurand.ds.pg.gda.pl>
In-Reply-To: <Pine.LNX.4.55.0401141623210.9549@jurand.ds.pg.gda.pl>
Content-Type: text/plain; charset=us-ascii; format=flowed
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: 3944
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

Maciej W. Rozycki wrote:

>On Tue, 13 Jan 2004, Dan Aizenstros wrote:
>
>  
>
>>You broke any build that does not define CONFIG_SERIAL_AU1X00
>>by adding an #error in the include/asm-mips/serial.h file.
>>
>>-- Dan A.
>>
>>ppopov@linux-mips.org wrote:
>>
>>    
>>
>>>CVSROOT:	/home/cvs
>>>Module name:	linux
>>>Changes by:	ppopov@ftp.linux-mips.org	04/01/13 08:09:22
>>>      
>>>
>
> Thanks for the report.  It looks like a typo.  I've removed the #error
>statement -- Pete please check if that's what's intended.
>  
>
Sorry, typo. Thanks for removing it.

Pete


From mdharm@momenco.com Wed Jan 14 18:32:37 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 14 Jan 2004 18:32:37 +0000 (GMT)
Received: from jeeves.momenco.com ([IPv6:::ffff:64.169.228.99]:29966 "EHLO 
	host099.momenco.com") by linux-mips.org with ESMTP
	id <S8225419AbUANSch>; Wed, 14 Jan 2004 18:32:37 +0000
Received: from BULLDOG (natbox.momenco.com [64.169.228.98])
	by  host099.momenco.com (8.11.6/8.11.6) with ESMTP id i0EIWZM13042;
	Wed, 14 Jan 2004 10:32:35 -0800
From: "Matthew Dharm" <mdharm@momenco.com>
To: "'Samuel Agarwal'" <sagarwal10@hotmail.com>,
	<linux-mips@linux-mips.org>, <linuxppc-embedded@lists.linuxppc.org>
Subject: RE: Intel Pro 82546 chipset performance
Date: Wed, 14 Jan 2004 10:32:32 -0800
Organization: Momentum Computer, Inc.
Message-ID: <001101c3dacc$c5e182a0$7200a8c0@internal.momenco.com>
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.4510
In-Reply-To: <BAY10-F117sntMQN8zy00008864@hotmail.com>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Importance: Normal
Return-Path: <mdharm@momenco.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: 3945
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: mdharm@momenco.com
Precedence: bulk
X-list: linux-mips

We use this chip (actually, the entire family) on many of our products (PPC,
x86, and MIPS).

Our data indicates that the chip can sustain wire-saturation with minimum
size packets.  However, many CPUs cannot keep up with the load created by
interrupts coming in at that rate.

There are probably some driver enhancements (interrupt combining, etc.)
which could be made to improve the situation.  But it's not a silicon
problem.

Matt

--
Matthew D. Dharm                            Senior Software Designer
Momentum Computer Inc.                      1815 Aston Ave.  Suite 107
(760) 431-8663 X-115                        Carlsbad, CA 92008-7310
Momentum Works For You                      www.momenco.com


> -----Original Message-----
> From: linux-mips-bounce@linux-mips.org 
> [mailto:linux-mips-bounce@linux-mips.org] On Behalf Of Samuel Agarwal
> Sent: Tuesday, January 13, 2004 10:37 PM
> To: linux-mips@linux-mips.org; linuxppc-embedded@lists.linuxppc.org
> Subject: Intel Pro 82546 chipset performance
> 
> 
> Hi
> 
> We're trying to use the Intel Pro 1000 adapters with the 
> 82546 chipset for a packet switching application. Has anyone 
> investigated performance on this chipset? With minimum sized 
> ethernet frames, the maximum throughput I can get is about 1 
> million packets per second (versus a 1.4 mill for line 
> rate
> on a gigethernet) and it looks that performance is skewed 
> towards receiving traffic (rather than sending out).
> 
> If anyone has any opinions or thoughts I'd appreciate them. 
> It's hard to get information out of Intel.
> 
> _________________________________________________________________
> Find out everything you need to know about Las Vegas here for 
> that getaway.  
> http://special.msn.com/msnbc/vivalasvegas.armx
> 
> 



From kph@cisco.com Wed Jan 14 19:09:45 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 14 Jan 2004 19:09:46 +0000 (GMT)
Received: from adsl-66-123-66-42.dsl.pltn13.pacbell.net ([IPv6:::ffff:66.123.66.42]:10123
	"EHLO stella-blue.herbertphamily.com") by linux-mips.org with ESMTP
	id <S8225073AbUANTJp>; Wed, 14 Jan 2004 19:09:45 +0000
Received: from [192.168.1.8] (shakedown.herbertphamily.com [192.168.1.8])
	(authenticated bits=0)
	by stella-blue.herbertphamily.com (8.12.8/8.12.8) with ESMTP id i0EJ9Y0M001105
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 14 Jan 2004 11:09:34 -0800
Subject: Re: How stable is 2.6 on a SB1250 processor?
From: Kevin Paul Herbert <kph@cisco.com>
To: Jun Sun <jsun@mvista.com>
Cc: Dimitri Torfs <dimitri@sonycom.com>,
	Pete Popov <ppopov@mvista.com>,
	Linux MIPS mailing list <linux-mips@linux-mips.org>
In-Reply-To: <20040113143137.N11733@mvista.com>
References: <1074027809.20636.91.camel@shakedown>
	 <1074028164.21857.120.camel@zeus.mvista.com>
	 <20040113214454.GA2737@sonycom.com>  <20040113143137.N11733@mvista.com>
Content-Type: text/plain
Organization: cisco Systems, Inc.
Message-Id: <1074107359.31877.14.camel@shakedown>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.2.2 (1.2.2-5) 
Date: 14 Jan 2004 11:09:21 -0800
Content-Transfer-Encoding: 7bit
Return-Path: <kph@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: 3946
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: kph@cisco.com
Precedence: bulk
X-list: linux-mips

Thanks for the tips. I incorporated Dmitri's patches to uaccess.h and
the syscall handlers and got usermode to come up correctly.

I'm aware of the SB1250 PCI problems and will be addressing that after I
get a few more on-board peripherals working. I've got my own fairly
complex PCI subsystem to port from 2.4 (hotplug, many bridges,
hypertransport configuration) and the main thing that I need from the
core SB1250 support is the ability to generate configuration cycles.
Because of the way the hardware works, I have to program all the bridges
myself (the ROM firmware does not do this for me).

I'll be sure to send patches to the list for anything I fix in the core
SB1250 PCI support.

Thanks again for the tips,

Kevin


-- 
Kevin Paul Herbert <kph@cisco.com>
cisco Systems, Inc.


From echristo@redhat.com Wed Jan 14 20:27:31 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 14 Jan 2004 20:27:32 +0000 (GMT)
Received: from mx2.redhat.com ([IPv6:::ffff:66.187.237.31]:28937 "EHLO
	mx2.redhat.com") by linux-mips.org with ESMTP id <S8225421AbUANU1b>;
	Wed, 14 Jan 2004 20:27:31 +0000
Received: from int-mx2.corp.redhat.com (int-mx2.corp.redhat.com [172.16.27.26])
	by mx2.redhat.com (8.11.6/8.11.6) with ESMTP id i0EK5jl23882;
	Wed, 14 Jan 2004 15:05:45 -0500
Received: from potter.sfbay.redhat.com (potter.sfbay.redhat.com [172.16.27.15])
	by int-mx2.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i0EKRCM29418;
	Wed, 14 Jan 2004 15:27:12 -0500
Received: from [192.168.123.101] (vpn50-25.rdu.redhat.com [172.16.50.25])
	by potter.sfbay.redhat.com (8.11.6/8.11.6) with ESMTP id i0EKRAO22982;
	Wed, 14 Jan 2004 12:27:10 -0800
Subject: Re: Correct assembler/compiler options for 4KC core?
From: Eric Christopher <echristo@redhat.com>
To: David Kesselring <dkesselr@mmc.atmel.com>
Cc: Thiemo Seufer <ica2_ts@csv.ica.uni-stuttgart.de>,
	"Zajerko-McKee, Nick" <nmckee@telogy.com>,
	linux-mips@linux-mips.org
In-Reply-To: <Pine.GSO.4.44.0401141200460.13057-100000@ares.mmc.atmel.com>
References: <Pine.GSO.4.44.0401141200460.13057-100000@ares.mmc.atmel.com>
Content-Type: text/plain
Message-Id: <1074111949.6191.2.camel@dzur.sfbay.redhat.com>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.4.5 (1.4.5-7) 
Date: Wed, 14 Jan 2004 12:25:49 -0800
Content-Transfer-Encoding: 7bit
Return-Path: <echristo@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: 3947
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: echristo@redhat.com
Precedence: bulk
X-list: linux-mips

On Wed, 2004-01-14 at 09:07, David Kesselring wrote:
> If 2.95 is too old for him, where should he(and I) get the latest stable
> packages. It seems like the MIPS environment is varied and there are
> toolchains for various processors in different locations. Is the toolchain
> and binutils for 4k/5k processors on the linux-mips.org ftp site?
> Is the correct gcc 3.2.xx? Will it build 2.4.2x that is in linux-mips cvs?
> Will it build 2.6? Will it build 64bit kernels? It would be nice if
> someone in the know could create a chart or add the info to readme or
> howto on linux-mips.org site.

A few answers:

a) -march=4kc for mainline gcc. there's an old dfa description for that
processor (not in the codebase, but I can be convinced to make it
available - I'm not as happy with it as with others) and hey, if the
option exists might as well use it.

b) IMO gcc.gnu.org for the gcc sources. sources.redhat.com for the
binutils sources. these will build 64bit kernels afaik. i've only tested
on an sb1250 and that is using the kernel sources from broadcom.

-eric

-- 
Eric Christopher <echristo@redhat.com>


From charlieb-linux-mips@e-smith.com Wed Jan 14 20:49:18 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 14 Jan 2004 20:49:22 +0000 (GMT)
Received: from mail.e-smith.com ([IPv6:::ffff:216.191.234.126]:24581 "HELO
	nssg.mitel.com") by linux-mips.org with SMTP id <S8225421AbUANUtS>;
	Wed, 14 Jan 2004 20:49:18 +0000
Received: (qmail 28568 invoked by uid 404); 14 Jan 2004 20:49:10 -0000
Received: from charlieb-linux-mips@e-smith.com by tripe.nssg.mitel.com with qmail-scanner; 14 Jan 2004 15:49:10 -0000
Received: from allspice-core.nssg.mitel.com (HELO e-smith.com) (10.33.16.12)
  by tripe.nssg.mitel.com (10.33.17.11) with SMTP; 14 Jan 2004 20:49:09 -0000
Received: (qmail 27921 invoked by uid 5008); 14 Jan 2004 20:49:09 -0000
Received: from localhost (sendmail-bs@127.0.0.1)
  by localhost with SMTP; 14 Jan 2004 20:49:09 -0000
Date: Wed, 14 Jan 2004 15:49:09 -0500 (EST)
From: Charlie Brady <charlieb-linux-mips@e-smith.com>
X-X-Sender: charlieb@allspice.nssg.mitel.com
To: Jun Sun <jsun@mvista.com>
cc: linux-mips@linux-mips.org
Subject: Re: Broadcom 4702?
In-Reply-To: <20040113142802.M11733@mvista.com>
Message-ID: <Pine.LNX.4.44.0401141546230.21734-100000@allspice.nssg.mitel.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <charlieb-linux-mips@e-smith.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: 3948
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: charlieb-linux-mips@e-smith.com
Precedence: bulk
X-list: linux-mips


On Tue, 13 Jan 2004, Jun Sun wrote:

> Mvista is in the process of supporting bcm4704, which should be close to
> bcm4702.  If there is much interest, we can push the patch out to 
> the linux-mips.org tree.

I'm certain that there'd be people make use of the code if you put it 
there.

I've noticed that Broadcom have patched binutils and gcc, to work around 
some hardware bugs. Have you found that necessary with the bcm4704?

--
Charlie


From jimt@vivato.net Wed Jan 14 21:05:33 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 14 Jan 2004 21:05:33 +0000 (GMT)
Received: from exchange.mabuhaynetworks.com ([IPv6:::ffff:206.169.233.186]:8854
	"EHLO exchange.vivato.net") by linux-mips.org with ESMTP
	id <S8225424AbUANVFd>; Wed, 14 Jan 2004 21:05:33 +0000
Received: from [192.168.30.126] ([192.168.30.126]) by exchange.vivato.net with Microsoft SMTPSVC(5.0.2195.6713);
	 Wed, 14 Jan 2004 13:05:25 -0800
In-Reply-To: <Pine.LNX.4.44.0401141546230.21734-100000@allspice.nssg.mitel.com>
References: <Pine.LNX.4.44.0401141546230.21734-100000@allspice.nssg.mitel.com>
Mime-Version: 1.0 (Apple Message framework v609)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <61324177-46D5-11D8-9715-000393C30E1E@vivato.net>
Content-Transfer-Encoding: 7bit
Cc: Jun Sun <jsun@mvista.com>, linux-mips@linux-mips.org
From: Jim Thompson <jimt@vivato.net>
Subject: Re: Broadcom 4702?
Date: Wed, 14 Jan 2004 13:05:28 -0800
To: Charlie Brady <charlieb-linux-mips@e-smith.com>
X-Mailer: Apple Mail (2.609)
X-OriginalArrivalTime: 14 Jan 2004 21:05:25.0440 (UTC) FILETIME=[21677C00:01C3DAE2]
Return-Path: <jimt@vivato.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: 3949
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: jimt@vivato.net
Precedence: bulk
X-list: linux-mips


My question is why these patches, which are subject to GPL (it is 
binutils and gcc, after all), haven't been released.

On Jan 14, 2004, at 12:49 PM, Charlie Brady wrote:

>
> On Tue, 13 Jan 2004, Jun Sun wrote:
>
>> Mvista is in the process of supporting bcm4704, which should be close 
>> to
>> bcm4702.  If there is much interest, we can push the patch out to
>> the linux-mips.org tree.
>
> I'm certain that there'd be people make use of the code if you put it
> there.
>
> I've noticed that Broadcom have patched binutils and gcc, to work 
> around
> some hardware bugs. Have you found that necessary with the bcm4704?
>
> --
> Charlie
>
>


From jsun@mvista.com Wed Jan 14 21:18:52 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 14 Jan 2004 21:18:52 +0000 (GMT)
Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:57849 "EHLO
	orion.mvista.com") by linux-mips.org with ESMTP id <S8225424AbUANVSw>;
	Wed, 14 Jan 2004 21:18:52 +0000
Received: (from jsun@localhost)
	by orion.mvista.com (8.11.6/8.11.6) id i0ELIno14350;
	Wed, 14 Jan 2004 13:18:49 -0800
Date: Wed, 14 Jan 2004 13:18:49 -0800
From: Jun Sun <jsun@mvista.com>
To: Charlie Brady <charlieb-linux-mips@e-smith.com>
Cc: linux-mips@linux-mips.org, jsun@mvista.com
Subject: Re: Broadcom 4702?
Message-ID: <20040114131849.C13471@mvista.com>
References: <20040113142802.M11733@mvista.com> <Pine.LNX.4.44.0401141546230.21734-100000@allspice.nssg.mitel.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <Pine.LNX.4.44.0401141546230.21734-100000@allspice.nssg.mitel.com>; from charlieb-linux-mips@e-smith.com on Wed, Jan 14, 2004 at 03:49:09PM -0500
Return-Path: <jsun@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: 3950
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 Wed, Jan 14, 2004 at 03:49:09PM -0500, Charlie Brady wrote:
> 
> On Tue, 13 Jan 2004, Jun Sun wrote:
> 
> > Mvista is in the process of supporting bcm4704, which should be close to
> > bcm4702.  If there is much interest, we can push the patch out to 
> > the linux-mips.org tree.
> 
> I'm certain that there'd be people make use of the code if you put it 
> there.
> 
> I've noticed that Broadcom have patched binutils and gcc, to work around 
> some hardware bugs. Have you found that necessary with the bcm4704?
> 

Not to my knowledge.

Jun

From alan@lxorguk.ukuu.org.uk Wed Jan 14 21:19:13 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 14 Jan 2004 21:19:13 +0000 (GMT)
Received: from crosslink-village-512-1.bc.nu ([IPv6:::ffff:81.2.110.254]:4256
	"EHLO dhcp23.swansea.linux.org.uk") by linux-mips.org with ESMTP
	id <S8225431AbUANVTB>; Wed, 14 Jan 2004 21:19:01 +0000
Received: from dhcp23.swansea.linux.org.uk (localhost.localdomain [127.0.0.1])
	by dhcp23.swansea.linux.org.uk (8.12.10/8.12.10) with ESMTP id i0ELFr0r000486;
	Wed, 14 Jan 2004 21:15:53 GMT
Received: (from alan@localhost)
	by dhcp23.swansea.linux.org.uk (8.12.10/8.12.10/Submit) id i0ELFpgL000484;
	Wed, 14 Jan 2004 21:15:51 GMT
X-Authentication-Warning: dhcp23.swansea.linux.org.uk: alan set sender to alan@lxorguk.ukuu.org.uk using -f
Subject: Re: Broadcom 4702?
From: Alan Cox <alan@lxorguk.ukuu.org.uk>
To: Jim Thompson <jimt@vivato.net>
Cc: Charlie Brady <charlieb-linux-mips@e-smith.com>,
	Jun Sun <jsun@mvista.com>, linux-mips@linux-mips.org
In-Reply-To: <61324177-46D5-11D8-9715-000393C30E1E@vivato.net>
References: <Pine.LNX.4.44.0401141546230.21734-100000@allspice.nssg.mitel.com>
	 <61324177-46D5-11D8-9715-000393C30E1E@vivato.net>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Message-Id: <1074114950.403.8.camel@dhcp23.swansea.linux.org.uk>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.4.5 (1.4.5-7) 
Date: Wed, 14 Jan 2004 21:15:51 +0000
Return-Path: <alan@lxorguk.ukuu.org.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: 3951
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: alan@lxorguk.ukuu.org.uk
Precedence: bulk
X-list: linux-mips

On Mer, 2004-01-14 at 21:05, Jim Thompson wrote:
> My question is why these patches, which are subject to GPL (it is 
> binutils and gcc, after all), haven't been released.

There is no obligation for anyone to provide the source except to those
they provide the binaries. They just can't stop those people then 
redistributing it.



From jimt@vivato.net Wed Jan 14 21:42:06 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 14 Jan 2004 21:42:07 +0000 (GMT)
Received: from exchange.mabuhaynetworks.com ([IPv6:::ffff:206.169.233.186]:54938
	"EHLO exchange.vivato.net") by linux-mips.org with ESMTP
	id <S8225431AbUANVmG>; Wed, 14 Jan 2004 21:42:06 +0000
Received: from [192.168.30.126] ([192.168.30.126]) by exchange.vivato.net with Microsoft SMTPSVC(5.0.2195.6713);
	 Wed, 14 Jan 2004 13:41:59 -0800
In-Reply-To: <1074114950.403.8.camel@dhcp23.swansea.linux.org.uk>
References: <Pine.LNX.4.44.0401141546230.21734-100000@allspice.nssg.mitel.com> <61324177-46D5-11D8-9715-000393C30E1E@vivato.net> <1074114950.403.8.camel@dhcp23.swansea.linux.org.uk>
Mime-Version: 1.0 (Apple Message framework v609)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <7CB2EF32-46DA-11D8-9715-000393C30E1E@vivato.net>
Content-Transfer-Encoding: 7bit
Cc: Jun Sun <jsun@mvista.com>, linux-mips@linux-mips.org,
	Charlie Brady <charlieb-linux-mips@e-smith.com>
From: Jim Thompson <jimt@vivato.net>
Subject: Re: Broadcom 4702?
Date: Wed, 14 Jan 2004 13:42:01 -0800
To: Alan Cox <alan@lxorguk.ukuu.org.uk>
X-Mailer: Apple Mail (2.609)
X-OriginalArrivalTime: 14 Jan 2004 21:41:59.0207 (UTC) FILETIME=[3CFDC370:01C3DAE7]
Return-Path: <jimt@vivato.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: 3952
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: jimt@vivato.net
Precedence: bulk
X-list: linux-mips


I have binaries.  I asked.  I was told "no".

On Jan 14, 2004, at 1:15 PM, Alan Cox wrote:

> On Mer, 2004-01-14 at 21:05, Jim Thompson wrote:
>> My question is why these patches, which are subject to GPL (it is
>> binutils and gcc, after all), haven't been released.
>
> There is no obligation for anyone to provide the source except to those
> they provide the binaries. They just can't stop those people then
> redistributing it.
>
>


From charlieb-linux-mips@e-smith.com Wed Jan 14 21:50:09 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 14 Jan 2004 21:50:09 +0000 (GMT)
Received: from mail.e-smith.com ([IPv6:::ffff:216.191.234.126]:62731 "HELO
	nssg.mitel.com") by linux-mips.org with SMTP id <S8225431AbUANVuJ>;
	Wed, 14 Jan 2004 21:50:09 +0000
Received: (qmail 8163 invoked by uid 404); 14 Jan 2004 21:50:02 -0000
Received: from charlieb-linux-mips@e-smith.com by tripe.nssg.mitel.com with qmail-scanner; 14 Jan 2004 16:50:02 -0000
Received: from allspice-core.nssg.mitel.com (HELO e-smith.com) (10.33.16.12)
  by tripe.nssg.mitel.com (10.33.17.11) with SMTP; 14 Jan 2004 21:50:02 -0000
Received: (qmail 5720 invoked by uid 5008); 14 Jan 2004 21:50:02 -0000
Received: from localhost (sendmail-bs@127.0.0.1)
  by localhost with SMTP; 14 Jan 2004 21:50:02 -0000
Date: Wed, 14 Jan 2004 16:50:02 -0500 (EST)
From: Charlie Brady <charlieb-linux-mips@e-smith.com>
X-X-Sender: charlieb@allspice.nssg.mitel.com
To: Jim Thompson <jimt@vivato.net>
cc: linux-mips@linux-mips.org
Subject: Broadcom gcc/binutils changes (was Re: Broadcom 4702?)
In-Reply-To: <61324177-46D5-11D8-9715-000393C30E1E@vivato.net>
Message-ID: <Pine.LNX.4.44.0401141648000.21734-100000@allspice.nssg.mitel.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <charlieb-linux-mips@e-smith.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: 3953
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: charlieb-linux-mips@e-smith.com
Precedence: bulk
X-list: linux-mips


On Wed, 14 Jan 2004, Jim Thompson wrote:

> My question is why these patches, which are subject to GPL (it is 
> binutils and gcc, after all), haven't been released.

They have, which is why I know about them, and what they do. See URL in my 
post which started this thread.

[What's released is unfortunately a tarball, not a patch. More work for 
us, I guess.]

--
Charlie


From charlieb-linux-mips@e-smith.com Wed Jan 14 22:00:35 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 14 Jan 2004 22:00:35 +0000 (GMT)
Received: from mail.e-smith.com ([IPv6:::ffff:216.191.234.126]:5389 "HELO
	nssg.mitel.com") by linux-mips.org with SMTP id <S8225431AbUANWAf>;
	Wed, 14 Jan 2004 22:00:35 +0000
Received: (qmail 10276 invoked by uid 404); 14 Jan 2004 22:00:28 -0000
Received: from charlieb-linux-mips@e-smith.com by tripe.nssg.mitel.com with qmail-scanner; 14 Jan 2004 17:00:28 -0000
Received: from allspice-core.nssg.mitel.com (HELO e-smith.com) (10.33.16.12)
  by tripe.nssg.mitel.com (10.33.17.11) with SMTP; 14 Jan 2004 22:00:28 -0000
Received: (qmail 7776 invoked by uid 5008); 14 Jan 2004 22:00:28 -0000
Received: from localhost (sendmail-bs@127.0.0.1)
  by localhost with SMTP; 14 Jan 2004 22:00:28 -0000
Date: Wed, 14 Jan 2004 17:00:28 -0500 (EST)
From: Charlie Brady <charlieb-linux-mips@e-smith.com>
X-X-Sender: charlieb@allspice.nssg.mitel.com
To: Jim Thompson <jimt@vivato.net>
cc: linux-mips@linux-mips.org
Subject: Broadcom gcc/binutils mods (Re: Broadcom 4702?)
In-Reply-To: <7CB2EF32-46DA-11D8-9715-000393C30E1E@vivato.net>
Message-ID: <Pine.LNX.4.44.0401141652010.21734-100000@allspice.nssg.mitel.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <charlieb-linux-mips@e-smith.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: 3954
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: charlieb-linux-mips@e-smith.com
Precedence: bulk
X-list: linux-mips


On Wed, 14 Jan 2004, Jim Thompson wrote:

> I have binaries.  I asked.  I was told "no".

They got better. Or more accurately, Linksys/Cisco got better for them.

See WRT54G/tools-src/gnu-20010422/ in wrt54g.1.42.3.tar.gz

Trendware, Buffalo and Belkin from busybox's Hall of Shame all ship linux
based wireless routers using Broadcom CPUs, with no source available:

http://www.busybox.net/shame.html

I suspect that Broadcom should share a large part of the [bl,sh]ame.

--
Charlie


From hjl@lucon.org Wed Jan 14 22:30:13 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 14 Jan 2004 22:30:14 +0000 (GMT)
Received: from sccrmhc11.comcast.net ([IPv6:::ffff:204.127.202.55]:41116 "EHLO
	sccrmhc11.comcast.net") by linux-mips.org with ESMTP
	id <S8225271AbUANWaN>; Wed, 14 Jan 2004 22:30:13 +0000
Received: from lucon.org ([24.6.43.109]) by comcast.net (sccrmhc11) with ESMTP
          id <2004011422300601100la0sge>; Wed, 14 Jan 2004 22:30:06 +0000
Received: by lucon.org (Postfix, from userid 1000)
	id 9954B649CC; Wed, 14 Jan 2004 14:30:04 -0800 (PST)
Date: Wed, 14 Jan 2004 14:30:04 -0800
From: "H. J. Lu" <hjl@lucon.org>
To: linux-gcc@vger.kernel.org,
	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, Ralf Baechle <ralf@linux-mips.org>,
	Linas Vepstas <linas@linas.org>,
	"Steven J. Hill" <sjhill@realitydiluted.com>
Subject: The Linux binutils 2.14.90.0.8 is released
Message-ID: <20040114223004.GA6313@lucon.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.4.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: 3955
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.14.90.0.8 for Linux, which is
based on binutils 2004 0114 in CVS on sources.redhat.com plus various
changes. It is purely for Linux.

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

If you don't use

# rpmbuild -ta binutils-xx.xx.xx.xx.xx.tar.gz

to compile the Linux binutils, please read patches/README in source
tree to apply Linux patches.

Changes from binutils 2.14.90.0.7:

1. Update from binutils 2004 0114.
2. Fixed an ia64 assembler unwind table bug. 
3. Better handle IPF linker relaxation overflow.
4. Fixed misc PPC bugs.

Changes from binutils 2.14.90.0.6:

1. Update from binutils 2003 1029.
2. Allow type changes for undefined symbols.
3. Fix EH frame optimization.
4. Fix the check for undefined versioned symbol with wildcard.
5. Support generating code for Itanium.
6. Detect and warn bad symbol index.
7. Update IPF assemebler DV check.

Changes from binutils 2.14.90.0.5:

1. Update from binutils 2003 0820.
2. No longer use section names for ELF section types nor flags.
3. Fix some ELF/IA64 linker bugs.
4. Fix some ELF/ppc bugs.
5. Add archive support to readelf.

Changes from binutils 2.14.90.0.4.1:

1. Update from binutils 2003 0722.
2. Fix an ELF/mips linker bug.
3. Fix an ELF/hpppa linker bug.
4. Fix an ELF/ia64 assembler bug.
5. Fix a linkonce support with C++ debug.
6. A new working C++ demangler.
7. Various alpha, mips, ia64, ... bug fixes.
8. Support for the current gcc and glibc.

Changes from binutils 2.14.90.0.4:
 
1. Fix an ia64 assembler hint@pause bug.
2. Support Intel Precott New Instructions.

Changes from binutils 2.14.90.0.3:

1. Work around the brain dead libtool.

Changes from binutils 2.14.90.0.2:

1. Update from binutils 2003 0523.
2. Fix 2 ELF visibility bugs.
3. Fix ELF/ppc linker bugs.

Changes from binutils 2.14.90.0.1:

1. Update from binutils 2003 0515.
2. Fix various ELF visibility bugs.
3. Fix some ia64 linker bugs.
4. Add more IAS compatibilities to ia64 assembler.

Changes from binutils 2.13.90.0.20:

1. Update from binutils 2003 0505.
2. Fix various ELF visibility bugs.
3. Fix some ia64 linker bugs.
4. Fix some ia64 assembler bugs.
5. Add some IAS compatibilities to ia64 assembler.
6. Fix ELF common symbol alignment.
7. Fix ELF weak symbol handling.

Changes from binutils 2.13.90.0.18:

1. Update from binutils 2003 0319.
2. Fix an ia64 linker brl relaxation bug.
3. Fix some ELF/ppc linker bugs.

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.

The file list:

1. binutils-2.14.90.0.8.tar.gz. Source code.
2. binutils-2.14.90.0.7-2.14.90.0.8.diff.gz. Patch against the
   previous beta source code.
3. binutils-2.14.90.0.8-1.i386.rpm. IA-32 binary RPM for RedHat EL 3.
4. binutils-2.14.90.0.8-1.ia64.rpm. IA-64 binary RPM for RedHat EL 3.

There is no separate source rpm. You can do

# rpmbuild -ta binutils-2.14.90.0.8.tar.gz

to create both binary and source rpms.

The primary sites for the beta Linux binutils are:

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

Thanks.


H.J. Lu
hjl@lucon.org
01/14/2004

From alan@lxorguk.ukuu.org.uk Wed Jan 14 22:56:58 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 14 Jan 2004 22:56:59 +0000 (GMT)
Received: from crosslink-village-512-1.bc.nu ([IPv6:::ffff:81.2.110.254]:35232
	"EHLO dhcp23.swansea.linux.org.uk") by linux-mips.org with ESMTP
	id <S8225271AbUANW46>; Wed, 14 Jan 2004 22:56:58 +0000
Received: from dhcp23.swansea.linux.org.uk (localhost.localdomain [127.0.0.1])
	by dhcp23.swansea.linux.org.uk (8.12.10/8.12.10) with ESMTP id i0EMrs0r000938;
	Wed, 14 Jan 2004 22:53:54 GMT
Received: (from alan@localhost)
	by dhcp23.swansea.linux.org.uk (8.12.10/8.12.10/Submit) id i0EMrrYw000936;
	Wed, 14 Jan 2004 22:53:53 GMT
X-Authentication-Warning: dhcp23.swansea.linux.org.uk: alan set sender to alan@lxorguk.ukuu.org.uk using -f
Subject: Re: Broadcom 4702?
From: Alan Cox <alan@lxorguk.ukuu.org.uk>
To: Jim Thompson <jimt@vivato.net>
Cc: Jun Sun <jsun@mvista.com>, linux-mips@linux-mips.org,
	Charlie Brady <charlieb-linux-mips@e-smith.com>
In-Reply-To: <7CB2EF32-46DA-11D8-9715-000393C30E1E@vivato.net>
References: <Pine.LNX.4.44.0401141546230.21734-100000@allspice.nssg.mitel.com>
	 <61324177-46D5-11D8-9715-000393C30E1E@vivato.net>
	 <1074114950.403.8.camel@dhcp23.swansea.linux.org.uk>
	 <7CB2EF32-46DA-11D8-9715-000393C30E1E@vivato.net>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Message-Id: <1074120339.866.1.camel@dhcp23.swansea.linux.org.uk>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.4.5 (1.4.5-7) 
Date: Wed, 14 Jan 2004 22:53:53 +0000
Return-Path: <alan@lxorguk.ukuu.org.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: 3956
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: alan@lxorguk.ukuu.org.uk
Precedence: bulk
X-list: linux-mips

On Mer, 2004-01-14 at 21:42, Jim Thompson wrote:
> I have binaries.  I asked.  I was told "no".

Please report that to the Free Software Foundation. If Broadcom provided
you the binaries and refused to provide you the source they are in
violation of license and the FSF as copyright holder will be happy to
take a (*polite* initially) hammer to their toenails...

Also beware of stupid support people. Some of them come preprogrammed
with "you cant have the source" and you have to go via their managers
for GPL stuff.


From ndf@ghs.com Wed Jan 14 23:36:59 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 14 Jan 2004 23:37:00 +0000 (GMT)
Received: from eta.ghs.com ([IPv6:::ffff:63.102.70.66]:56263 "EHLO eta.ghs.com")
	by linux-mips.org with ESMTP id <S8225446AbUANXg7>;
	Wed, 14 Jan 2004 23:36:59 +0000
Received: from blaze.ghs.com (blaze.ghs.com [192.67.158.233])
	by eta.ghs.com (8.12.10/8.12.10) with ESMTP id i0ENatkp019865;
	Wed, 14 Jan 2004 15:36:55 -0800 (PST)
Received: from zcar.ghs.com (zcar.ghs.com [192.67.158.60])
	by blaze.ghs.com (8.12.9/8.12.9) with ESMTP id i0ENas9u007219;
	Wed, 14 Jan 2004 15:36:54 -0800 (PST)
Date: Wed, 14 Jan 2004 15:36:54 -0800 (PST)
From: Nathan Field <ndf@ghs.com>
To: Daniel Jacobowitz <dan@debian.org>
cc: linux-mips@linux-mips.org
Subject: Re: ptrace induced instruction cache bug?
In-Reply-To: <20040113205858.GA17260@nevyn.them.org>
Message-ID: <Pine.LNX.4.44.0401141441370.1969-100000@zcar.ghs.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <ndf@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: 3957
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: ndf@ghs.com
Precedence: bulk
X-list: linux-mips

> On Tue, Jan 13, 2004 at 10:35:04AM -0800, Nathan Field wrote:
> > > It sounds reasonable.  I've encountered this problem in the past also,
> > > but never with the Pro 2.1 / MIPS release which is what you're using.  
> > > I don't see anything obviously wrong with your test code, either.
> > 	So... is there a fix for this?
> 
> Usually a missing cache flush, as you surmised :)  But I don't know of
> any that were missing in that version.
	So I looked into this and found that in ptrace.c:access_process_vm 
if I added a (obviously inefficient) flush_cache_all() into:

		if (write) {
			memcpy(maddr + offset, buf, bytes);
#ifdef CONFIG_SUPERH
			flush_dcache_page(page);
#endif
			flush_page_to_ram(page);
			flush_icache_page(vma, page);
			/* [ndf] I know this is not efficient, but it 
			 * makes it work. */
+++			flush_cache_all();
		} else {
			memcpy(buf, maddr + offset, bytes);
			flush_page_to_ram(page);
		}

then my ptrace test suite works. Looking at the status of the cache with 
my debugger while I step over various lines I see the entry for my address 
in the data cache in set 8, way 2. I step over flush_page_to_ram and it's 
still there. When I step over my call to flush_cache_all I see that the 
entry has moved to set 8, way 3. Unfortunatly there doesn't seem to be a 
"dirty" bit in the cache status bits, so I can't prove what's going wrong 
by looking at the contents of the data cache as I step over the various 
cache flushing functions. I'd guess that the address that I want flushed 
moving around when I call flush_cache_all indicates that it really is 
being flushed (and then filled again by a later memory access), but I 
don't know the details of how the data cache is supposed to operate.

	Anyway, I'd guess that flush_page_to_ram ->
mips32_flush_page_to_ram_pc -> blast_dcache_page doesn't work on the MIPS
Malta board. Given how frequently it seems to be used that seems unlikely. 
At this point the board does what I want it to for my testing purposes, 
but something isn't quite right.

	nathan

> 
> > > Yes, you will need a newer toolchain.  Honestly, I'm baffled as to why a
> > > Pro 2.1 toolchain was available from our web site at all, unless you got
> > > it via an old product subscription... it should have been Pro 3.0, which
> > > uses GCC 3.2 and a more recent binutils.  But I don't have any control
> > > over these things :)
> > 	I downloaded it about 5 days ago from:
> > http://www.mvista.com/previewkit/index.html
> > 
> > Could I get a preview kit of your 3.0 release for a Malta 4Kc board?
> 
> Let me inquire as to why we're distributing old ones.
> 
> 

-- 
Nathan Field (ndf@ghs.com)			          All gone.

But the trouble with analogies is that analogies are like goldfish:
sometimes they have nothing to do with the topic at hand.
        -- Crispin (from a posting to the Bugtraq mailing list)


From jsun@mvista.com Thu Jan 15 00:07:40 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 15 Jan 2004 00:07:40 +0000 (GMT)
Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:33524 "EHLO
	orion.mvista.com") by linux-mips.org with ESMTP id <S8225272AbUAOAHk>;
	Thu, 15 Jan 2004 00:07:40 +0000
Received: (from jsun@localhost)
	by orion.mvista.com (8.11.6/8.11.6) id i0F07Tx16030;
	Wed, 14 Jan 2004 16:07:29 -0800
Date: Wed, 14 Jan 2004 16:07:29 -0800
From: Jun Sun <jsun@mvista.com>
To: Nathan Field <ndf@ghs.com>
Cc: Daniel Jacobowitz <dan@debian.org>, linux-mips@linux-mips.org,
	jsun@mvista.com
Subject: Re: ptrace induced instruction cache bug?
Message-ID: <20040114160729.D13471@mvista.com>
References: <20040113205858.GA17260@nevyn.them.org> <Pine.LNX.4.44.0401141441370.1969-100000@zcar.ghs.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <Pine.LNX.4.44.0401141441370.1969-100000@zcar.ghs.com>; from ndf@ghs.com on Wed, Jan 14, 2004 at 03:36:54PM -0800
Return-Path: <jsun@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: 3958
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 Wed, Jan 14, 2004 at 03:36:54PM -0800, Nathan Field wrote:
> > On Tue, Jan 13, 2004 at 10:35:04AM -0800, Nathan Field wrote:
> > > > It sounds reasonable.  I've encountered this problem in the past also,
> > > > but never with the Pro 2.1 / MIPS release which is what you're using.  
> > > > I don't see anything obviously wrong with your test code, either.
> > > 	So... is there a fix for this?
> > 
> > Usually a missing cache flush, as you surmised :)  But I don't know of
> > any that were missing in that version.
> 	So I looked into this and found that in ptrace.c:access_process_vm 
> if I added a (obviously inefficient) flush_cache_all() into:
> 
> 		if (write) {
> 			memcpy(maddr + offset, buf, bytes);
> #ifdef CONFIG_SUPERH
> 			flush_dcache_page(page);
> #endif
> 			flush_page_to_ram(page);
> 			flush_icache_page(vma, page);
> 			/* [ndf] I know this is not efficient, but it 
> 			 * makes it work. */
> +++			flush_cache_all();
> 		} else {
> 			memcpy(buf, maddr + offset, bytes);
> 			flush_page_to_ram(page);
> 		}
> 
> then my ptrace test suite works. Looking at the status of the cache with 
> my debugger while I step over various lines I see the entry for my address 
> in the data cache in set 8, way 2. I step over flush_page_to_ram and it's 
> still there. When I step over my call to flush_cache_all I see that the 
> entry has moved to set 8, way 3. Unfortunatly there doesn't seem to be a 
> "dirty" bit in the cache status bits, so I can't prove what's going wrong 
> by looking at the contents of the data cache as I step over the various 
> cache flushing functions. I'd guess that the address that I want flushed 
> moving around when I call flush_cache_all indicates that it really is 
> being flushed (and then filled again by a later memory access), but I 
> don't know the details of how the data cache is supposed to operate.
> 
> 	Anyway, I'd guess that flush_page_to_ram ->
> mips32_flush_page_to_ram_pc -> blast_dcache_page doesn't work on the MIPS
> Malta board. Given how frequently it seems to be used that seems unlikely. 
> At this point the board does what I want it to for my testing purposes, 
> but something isn't quite right.
> 

There are too many things related to cache are wrong in 2.4.17.  For example,

. flush_page_indexed() is not right for multi-way cache
. when you map user pages into kernel, you are sufferring potential cache
  aliasing problem (BTW, we still suffer from this right now to a less degree)
. flush_page_to_ram() has a broken semantic, because it is not clear whether
  the area mapped into user virt spaces should be flushed or not
...

In short, it is not worth your time to fix old bugs.  Last time I checked
malta was working fine around 2.4.21.  It shouldn't be too hard to get
it working again in the latest 2.4 branch.

Jun

From ndf@ghs.com Thu Jan 15 00:22:08 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 15 Jan 2004 00:22:09 +0000 (GMT)
Received: from eta.ghs.com ([IPv6:::ffff:63.102.70.66]:46836 "EHLO eta.ghs.com")
	by linux-mips.org with ESMTP id <S8225272AbUAOAWI>;
	Thu, 15 Jan 2004 00:22:08 +0000
Received: from blaze.ghs.com (blaze.ghs.com [192.67.158.233])
	by eta.ghs.com (8.12.10/8.12.10) with ESMTP id i0F0M6kp025134;
	Wed, 14 Jan 2004 16:22:06 -0800 (PST)
Received: from zcar.ghs.com (zcar.ghs.com [192.67.158.60])
	by blaze.ghs.com (8.12.9/8.12.9) with ESMTP id i0F0M19u016727;
	Wed, 14 Jan 2004 16:22:01 -0800 (PST)
Date: Wed, 14 Jan 2004 16:22:01 -0800 (PST)
From: Nathan Field <ndf@ghs.com>
To: Jun Sun <jsun@mvista.com>
cc: Daniel Jacobowitz <dan@debian.org>, <linux-mips@linux-mips.org>
Subject: Re: ptrace induced instruction cache bug?
In-Reply-To: <20040114160729.D13471@mvista.com>
Message-ID: <Pine.LNX.4.44.0401141619110.1969-100000@zcar.ghs.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <ndf@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: 3959
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: ndf@ghs.com
Precedence: bulk
X-list: linux-mips

> There are too many things related to cache are wrong in 2.4.17.  For
> example,
> 
> . flush_page_indexed() is not right for multi-way cache
> . when you map user pages into kernel, you are sufferring potential cache
>   aliasing problem (BTW, we still suffer from this right now to a less degree)
> . flush_page_to_ram() has a broken semantic, because it is not clear whether
>   the area mapped into user virt spaces should be flushed or not
> ...
> 
> In short, it is not worth your time to fix old bugs.  Last time I
> checked malta was working fine around 2.4.21.  It shouldn't be too hard
> to get it working again in the latest 2.4 branch.
	Is this the 2.4.21 from ftp.kernel.org, or do I need to get 
specific patches to get it to work? I looked at the cvs tree but it's 
currently a 2.6 release. Should I just check out the linux_2_4_branch 
version from linux-mips.org?

	nathan

-- 
Nathan Field (ndf@ghs.com)			          All gone.

But the trouble with analogies is that analogies are like goldfish:
sometimes they have nothing to do with the topic at hand.
        -- Crispin (from a posting to the Bugtraq mailing list)


From jsun@mvista.com Thu Jan 15 00:39:22 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 15 Jan 2004 00:39:23 +0000 (GMT)
Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:39663 "EHLO
	orion.mvista.com") by linux-mips.org with ESMTP id <S8225255AbUAOAjW>;
	Thu, 15 Jan 2004 00:39:22 +0000
Received: (from jsun@localhost)
	by orion.mvista.com (8.11.6/8.11.6) id i0F0dKa16163;
	Wed, 14 Jan 2004 16:39:20 -0800
Date: Wed, 14 Jan 2004 16:39:20 -0800
From: Jun Sun <jsun@mvista.com>
To: linux-mips@linux-mips.org, linux-kernel@vger.kernel.org
Cc: jsun@mvista.com
Subject: [BUG] 2.6.1/MIPS - missing cache flushing when user program returns pages to kernel
Message-ID: <20040114163920.E13471@mvista.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="IJpNTDwzlM2Ie8A6"
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
Return-Path: <jsun@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: 3960
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


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


I have been chasing a nasty memory corruption bug on my MIPS box with
2.6.1 kernel.  In the end it appears the following sequence has
happened:

1. userland gets a page and writes some stuff to it, which dirties
   data cache.  In my case, it is actually doing a sys_read() into
   that page.  See my kgdb trace attached in the end.

2. userland returns this page to kernel *without* any cache flushing,
   i.e., the dcache is still dirty.

3. kernel calls kmalloc() to get a block from this page.

4. the dirty dcache is written back to physical memory some time later,
   corrupting the kernel data.

It seems to me the problem is that we should do a cache flush 
for all the pages returned to kernel during step 2.

I attached a hack which solves my problem but I am not sure if it is
most appropriate.  It looks like the affected user region (start, end)
can span over multiple vma areas.  If so, the fix will only flush the first
area.

Also, it is hard to find an appropriate place to do the flushing
The new 2.6 mm is a confusing maze to me.  I hope someone more
knowledgable can come up with a more decent fix for this problem.

BTW, it appears in 2.4 we are doing this flushing in do_zap_page_range()
where we call a flush_cache_range(mm, start, end).

Jun

P.S., Here is the stack trace when dirty data is written to user page:

$8 = 0x2aac3000
(gdb) p/x kaddr 
$9 = 0x811a3880 
(gdb) bt
#0  both_aligned () at arch/mips/lib/memcpy.S:222
#1  0xffffffff8014351c in file_read_actor (desc=0x87fd1dd0, page=0x8102c178,
    offset=0, size=2717) at mm/filemap.c:754
#2  0xffffffff80143088 in do_generic_mapping_read (mapping=0x803e3168,
    ra=0x87fe8868, filp=0x87fe8820, ppos=0x87fe8840, desc=0x87fd1dd0, 
    actor=0x80143480 <file_read_actor>) at mm/filemap.c:658
#3  0xffffffff801437a0 in __generic_file_aio_read (iocb=0x80143480,
    iov=0x811a3880, nr_segs=1, ppos=0x87fe8840) at fs.h:1334
#4  0xffffffff80143884 in generic_file_read (filp=0x61697265,
    buf=0xcccccccd <Address 0xcccccccd out of bounds>, count=715927552,
    ppos=0xa9d) at mm/filemap.c:877
#5  0xffffffff80162688 in vfs_read (file=0x87fe8820,
    buf=0x2aac3000 "# /etc/inittab: init(8) configuration.\n# $Id: inittab,v 1.8 1998/05/10 10:37:50 miquels Exp $\n\n# The default runlevel.\nid:3:initdefault:\n\n# Boot-time system configuration/initialization script.\n# This"..., 
    count=4096, pos=0x87fe8840) at fs/read_write.c:213
#6  0xffffffff80162918 in sys_read (fd=715929728, 
    buf=0x2aac3000 "# /etc/inittab: init(8) configuration.\n# $Id: inittab,v 1.8 1998/05/10 10:37:50 miquels Exp $\n\n# The default runlevel.\nid:3:initdefault:\n\n# Boot-time system configuration/initialization script.\n# This"..., 
    count=4096) at fs/read_write.c:278

It appears I lost the stack trace when kernel finds data corruption.  It is somewhere
inside d_splice_alias() where inode->i_dentry, happens to be at 0x811a3880, has
a wrong value instead of the expected 0.


--IJpNTDwzlM2Ie8A6
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="missing-cache-flush-on-return-user-page.patch"

diff -Nru linux/mm/mmap.c.orig linux/mm/mmap.c
--- linux/mm/mmap.c.orig	Mon Jan 12 16:31:22 2004
+++ linux/mm/mmap.c	Wed Jan 14 14:22:20 2004
@@ -1134,6 +1134,8 @@
 	struct mmu_gather *tlb;
 	unsigned long nr_accounted = 0;
 
+	flush_cache_range(vma, start, end);
+
 	lru_add_drain();
 	tlb = tlb_gather_mmu(mm, 0);
 	unmap_vmas(&tlb, mm, vma, start, end, &nr_accounted);

--IJpNTDwzlM2Ie8A6--

From jsun@mvista.com Thu Jan 15 00:40:23 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 15 Jan 2004 00:40:23 +0000 (GMT)
Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:55791 "EHLO
	orion.mvista.com") by linux-mips.org with ESMTP id <S8225255AbUAOAkW>;
	Thu, 15 Jan 2004 00:40:22 +0000
Received: (from jsun@localhost)
	by orion.mvista.com (8.11.6/8.11.6) id i0F0eBT16181;
	Wed, 14 Jan 2004 16:40:11 -0800
Date: Wed, 14 Jan 2004 16:40:11 -0800
From: Jun Sun <jsun@mvista.com>
To: Nathan Field <ndf@ghs.com>
Cc: Daniel Jacobowitz <dan@debian.org>, linux-mips@linux-mips.org,
	jsun@mvista.com
Subject: Re: ptrace induced instruction cache bug?
Message-ID: <20040114164011.F13471@mvista.com>
References: <20040114160729.D13471@mvista.com> <Pine.LNX.4.44.0401141619110.1969-100000@zcar.ghs.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <Pine.LNX.4.44.0401141619110.1969-100000@zcar.ghs.com>; from ndf@ghs.com on Wed, Jan 14, 2004 at 04:22:01PM -0800
Return-Path: <jsun@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: 3961
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 Wed, Jan 14, 2004 at 04:22:01PM -0800, Nathan Field wrote:
> > There are too many things related to cache are wrong in 2.4.17.  For
> > example,
> > 
> > . flush_page_indexed() is not right for multi-way cache
> > . when you map user pages into kernel, you are sufferring potential cache
> >   aliasing problem (BTW, we still suffer from this right now to a less degree)
> > . flush_page_to_ram() has a broken semantic, because it is not clear whether
> >   the area mapped into user virt spaces should be flushed or not
> > ...
> > 
> > In short, it is not worth your time to fix old bugs.  Last time I
> > checked malta was working fine around 2.4.21.  It shouldn't be too hard
> > to get it working again in the latest 2.4 branch.
> 	Is this the 2.4.21 from ftp.kernel.org, or do I need to get 
> specific patches to get it to work? I looked at the cvs tree but it's 
> currently a 2.6 release. Should I just check out the linux_2_4_branch 
> version from linux-mips.org?
> 

Yes.  "linux_2_4" branch to be exact.

Jun

From jsun@mvista.com Thu Jan 15 01:04:01 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 15 Jan 2004 01:04:01 +0000 (GMT)
Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:8695 "EHLO
	orion.mvista.com") by linux-mips.org with ESMTP id <S8225255AbUAOBEB>;
	Thu, 15 Jan 2004 01:04:01 +0000
Received: (from jsun@localhost)
	by orion.mvista.com (8.11.6/8.11.6) id i0F13tn16299;
	Wed, 14 Jan 2004 17:03:55 -0800
Date: Wed, 14 Jan 2004 17:03:55 -0800
From: Jun Sun <jsun@mvista.com>
To: Jim Thompson <jimt@vivato.net>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>, linux-mips@linux-mips.org,
	Charlie Brady <charlieb-linux-mips@e-smith.com>,
	jsun@mvista.com
Subject: Re: Broadcom 4702?
Message-ID: <20040114170355.G13471@mvista.com>
References: <Pine.LNX.4.44.0401141546230.21734-100000@allspice.nssg.mitel.com> <61324177-46D5-11D8-9715-000393C30E1E@vivato.net> <1074114950.403.8.camel@dhcp23.swansea.linux.org.uk> <7CB2EF32-46DA-11D8-9715-000393C30E1E@vivato.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <7CB2EF32-46DA-11D8-9715-000393C30E1E@vivato.net>; from jimt@vivato.net on Wed, Jan 14, 2004 at 01:42:01PM -0800
Return-Path: <jsun@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: 3962
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 Wed, Jan 14, 2004 at 01:42:01PM -0800, Jim Thompson wrote:
> 
> I have binaries.  I asked.  I was told "no".
> 
> On Jan 14, 2004, at 1:15 PM, Alan Cox wrote:
> 
> > On Mer, 2004-01-14 at 21:05, Jim Thompson wrote:
> >> My question is why these patches, which are subject to GPL (it is
> >> binutils and gcc, after all), haven't been released.
> >
> > There is no obligation for anyone to provide the source except to those
> > they provide the binaries. They just can't stop those people then
> > redistributing it.
> >

Since we are on this subject, I am curious if I buy a Cisco's router
whether it is considered that Cisco distributs the binaries to me
and whether I can demand for the source code if they are GPL'ed software.

I can see arguments go either way.  Do open source community and
industry have some concensus on this issue?

Jun


From akpm@osdl.org Thu Jan 15 01:12:06 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 15 Jan 2004 01:12:07 +0000 (GMT)
Received: from fw.osdl.org ([IPv6:::ffff:65.172.181.6]:22765 "EHLO
	mail.osdl.org") by linux-mips.org with ESMTP id <S8225255AbUAOBMG>;
	Thu, 15 Jan 2004 01:12:06 +0000
Received: from akpm.pao.digeo.com (build.pdx.osdl.net [172.20.1.2])
	by mail.osdl.org (8.11.6/8.11.6) with SMTP id i0F1BXo23771;
	Wed, 14 Jan 2004 17:11:33 -0800
Date: Wed, 14 Jan 2004 17:12:52 -0800
From: Andrew Morton <akpm@osdl.org>
To: Jun Sun <jsun@mvista.com>
Cc: linux-mips@linux-mips.org, linux-kernel@vger.kernel.org,
	jsun@mvista.com, Russell King <rmk@arm.linux.org.uk>
Subject: Re: [BUG] 2.6.1/MIPS - missing cache flushing when user program
 returns pages to kernel
Message-Id: <20040114171252.4d873c51.akpm@osdl.org>
In-Reply-To: <20040114163920.E13471@mvista.com>
References: <20040114163920.E13471@mvista.com>
X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.10; i586-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Return-Path: <akpm@osdl.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: 3963
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: akpm@osdl.org
Precedence: bulk
X-list: linux-mips

Jun Sun <jsun@mvista.com> wrote:
>
> I have been chasing a nasty memory corruption bug on my MIPS box with
> 2.6.1 kernel.  In the end it appears the following sequence has
> happened:
> 
> 1. userland gets a page and writes some stuff to it, which dirties
>    data cache.  In my case, it is actually doing a sys_read() into
>    that page.  See my kgdb trace attached in the end.
> 
> 2. userland returns this page to kernel *without* any cache flushing,
>    i.e., the dcache is still dirty.
> 
> 3. kernel calls kmalloc() to get a block from this page.
> 
> 4. the dirty dcache is written back to physical memory some time later,
>    corrupting the kernel data.
> 
> It seems to me the problem is that we should do a cache flush 
> for all the pages returned to kernel during step 2.
> 
> I attached a hack which solves my problem but I am not sure if it is
> most appropriate.  It looks like the affected user region (start, end)
> can span over multiple vma areas.  If so, the fix will only flush the first
> area.
> 
> Also, it is hard to find an appropriate place to do the flushing
> The new 2.6 mm is a confusing maze to me.  I hope someone more
> knowledgable can come up with a more decent fix for this problem.
> 
> BTW, it appears in 2.4 we are doing this flushing in do_zap_page_range()
> where we call a flush_cache_range(mm, start, end).

That flush_cache_range was removed between 2.5.67 and 2.5.68.  If you put
it back, does it fix the problem?

It seems from Russell's words here, MIPS should be flushing in
tlb_start_vma().

I think that's wrong, really.  We've discussed this before and decided that
these flushing operations should be open-coded in the main .c file rather
than embedded in arch functions which happen to undocumentedly do other
stuff.


# --------------------------------------------
# 03/04/14	rmk@arm.linux.org.uk	1.1017
# [PATCH] flush_cache_mm in zap_page_range
# 
# unmap_vmas() eventually calls tlb_start_vma(), where most architectures
# flush caches as necessary.  The flush here seems to make the
# flush_cache_range() in zap_page_range() redundant, and therefore can be
# removed.
# --------------------------------------------
#
diff -Nru a/mm/memory.c b/mm/memory.c
--- a/mm/memory.c	Wed Jan 14 17:09:07 2004
+++ b/mm/memory.c	Wed Jan 14 17:09:07 2004
@@ -601,7 +601,6 @@
 
 	lru_add_drain();
 	spin_lock(&mm->page_table_lock);
-	flush_cache_range(vma, address, end);
 	tlb = tlb_gather_mmu(mm, 0);
 	unmap_vmas(&tlb, mm, vma, address, end, &nr_accounted);
 	tlb_finish_mmu(tlb, address, end);


From akpm@osdl.org Thu Jan 15 01:28:58 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 15 Jan 2004 01:28:59 +0000 (GMT)
Received: from fw.osdl.org ([IPv6:::ffff:65.172.181.6]:49288 "EHLO
	mail.osdl.org") by linux-mips.org with ESMTP id <S8225453AbUAOB26>;
	Thu, 15 Jan 2004 01:28:58 +0000
Received: from akpm.pao.digeo.com (build.pdx.osdl.net [172.20.1.2])
	by mail.osdl.org (8.11.6/8.11.6) with SMTP id i0F1SRo26782;
	Wed, 14 Jan 2004 17:28:27 -0800
Date: Wed, 14 Jan 2004 17:29:46 -0800
From: Andrew Morton <akpm@osdl.org>
To: jsun@mvista.com, linux-mips@linux-mips.org,
	linux-kernel@vger.kernel.org, rmk@arm.linux.org.uk
Subject: Re: [BUG] 2.6.1/MIPS - missing cache flushing when user program
 returns pages to kernel
Message-Id: <20040114172946.03e54706.akpm@osdl.org>
In-Reply-To: <20040114171252.4d873c51.akpm@osdl.org>
References: <20040114163920.E13471@mvista.com>
	<20040114171252.4d873c51.akpm@osdl.org>
X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.10; i586-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Return-Path: <akpm@osdl.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: 3964
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: akpm@osdl.org
Precedence: bulk
X-list: linux-mips

Andrew Morton <akpm@osdl.org> wrote:
>
> I think that's wrong, really.  We've discussed this before and decided that
> these flushing operations should be open-coded in the main .c file rather
> than embedded in arch functions which happen to undocumentedly do other
> stuff.

err, OK, I give up.  Lots of architectures do the cache flush in
tlb_start_vma().  I guess mips may as well do the same.


From jsun@mvista.com Thu Jan 15 01:40:15 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 15 Jan 2004 01:40:16 +0000 (GMT)
Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:57595 "EHLO
	orion.mvista.com") by linux-mips.org with ESMTP id <S8225278AbUAOBkP>;
	Thu, 15 Jan 2004 01:40:15 +0000
Received: (from jsun@localhost)
	by orion.mvista.com (8.11.6/8.11.6) id i0F1eCe16920;
	Wed, 14 Jan 2004 17:40:12 -0800
Date: Wed, 14 Jan 2004 17:40:12 -0800
From: Jun Sun <jsun@mvista.com>
To: Andrew Morton <akpm@osdl.org>
Cc: linux-mips@linux-mips.org, linux-kernel@vger.kernel.org,
	rmk@arm.linux.org.uk, jsun@mvista.com
Subject: Re: [BUG] 2.6.1/MIPS - missing cache flushing when user program returns pages to kernel
Message-ID: <20040114174012.H13471@mvista.com>
References: <20040114163920.E13471@mvista.com> <20040114171252.4d873c51.akpm@osdl.org> <20040114172946.03e54706.akpm@osdl.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <20040114172946.03e54706.akpm@osdl.org>; from akpm@osdl.org on Wed, Jan 14, 2004 at 05:29:46PM -0800
Return-Path: <jsun@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: 3965
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 Wed, Jan 14, 2004 at 05:29:46PM -0800, Andrew Morton wrote:
> Andrew Morton <akpm@osdl.org> wrote:
> >
> > I think that's wrong, really.  We've discussed this before and decided that
> > these flushing operations should be open-coded in the main .c file rather
> > than embedded in arch functions which happen to undocumentedly do other
> > stuff.
> 
> err, OK, I give up.  Lots of architectures do the cache flush in
> tlb_start_vma().  I guess mips may as well do the same.
> 

Looking at my tree (which is from linux-mips.org), it appears
arm, sparc, sparc64, and sh have tlb_start_vma() defined to call
cache flushing.

What exactly does tlb_start_vma()/tlb_end_vma() mean?  There is
only one invocation instance, which is significant enough to infer
the meaning.  :)
 
BTW, either my original hack or putting a cache flush in tlb_start_vma()
solves my problem.  They are really doing the same thing, just at
different places. 

Jun

From charlieb-linux-mips@e-smith.com Thu Jan 15 03:39:17 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 15 Jan 2004 03:39:26 +0000 (GMT)
Received: from mail.e-smith.com ([IPv6:::ffff:216.191.234.126]:1296 "HELO
	nssg.mitel.com") by linux-mips.org with SMTP id <S8225460AbUAODjR>;
	Thu, 15 Jan 2004 03:39:17 +0000
Received: (qmail 6811 invoked by uid 404); 15 Jan 2004 03:39:09 -0000
Received: from charlieb-linux-mips@e-smith.com by tripe.nssg.mitel.com with qmail-scanner; 14 Jan 2004 22:39:09 -0000
Received: from allspice-core.nssg.mitel.com (HELO e-smith.com) (10.33.16.12)
  by tripe.nssg.mitel.com (10.33.17.11) with SMTP; 15 Jan 2004 03:39:09 -0000
Received: (qmail 22142 invoked by uid 5008); 15 Jan 2004 03:39:09 -0000
Received: from localhost (sendmail-bs@127.0.0.1)
  by localhost with SMTP; 15 Jan 2004 03:39:09 -0000
Date: Wed, 14 Jan 2004 22:39:09 -0500 (EST)
From: Charlie Brady <charlieb-linux-mips@e-smith.com>
X-X-Sender: charlieb@allspice.nssg.mitel.com
To: Jun Sun <jsun@mvista.com>
cc: linux-mips@linux-mips.org
Subject: Re: Broadcom 4702?
In-Reply-To: <20040114170355.G13471@mvista.com>
Message-ID: <Pine.LNX.4.44.0401142235300.17500-100000@allspice.nssg.mitel.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <charlieb-linux-mips@e-smith.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: 3966
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: charlieb-linux-mips@e-smith.com
Precedence: bulk
X-list: linux-mips


On Wed, 14 Jan 2004, Jun Sun wrote:

> Since we are on this subject, I am curious if I buy a Cisco's router
> whether it is considered that Cisco distributs the binaries to me
> and whether I can demand for the source code if they are GPL'ed software.

You don't need to demand the source code to Cisco/linksys's linux based 
wireless routers. It's available for download from the URL I provided at 
the start of the thread.

> I can see arguments go either way.  Do open source community and
> industry have some concensus on this issue?

Please read the various licenses (GPL and other), and consult your lawyer.
And if you want a definitive answer (in your jurisdiction) get the license 
tested in Court (and subsequent Appeals Courts). :-)

--
Charlie


From davem@redhat.com Thu Jan 15 06:23:30 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 15 Jan 2004 06:23:31 +0000 (GMT)
Received: from rth.ninka.net ([IPv6:::ffff:216.101.162.244]:3712 "EHLO
	rth.ninka.net") by linux-mips.org with ESMTP id <S8224893AbUAOGXa>;
	Thu, 15 Jan 2004 06:23:30 +0000
Received: from rth.ninka.net (localhost.localdomain [127.0.0.1])
	by rth.ninka.net (8.12.10/8.12.10) with SMTP id i0F6NGX6011727;
	Wed, 14 Jan 2004 22:23:16 -0800
Date: Wed, 14 Jan 2004 22:23:16 -0800
From: "David S. Miller" <davem@redhat.com>
To: Jun Sun <jsun@mvista.com>
Cc: akpm@osdl.org, linux-mips@linux-mips.org,
	linux-kernel@vger.kernel.org, rmk@arm.linux.org.uk, jsun@mvista.com
Subject: Re: [BUG] 2.6.1/MIPS - missing cache flushing when user program
 returns pages to kernel
Message-Id: <20040114222316.25276f12.davem@redhat.com>
In-Reply-To: <20040114174012.H13471@mvista.com>
References: <20040114163920.E13471@mvista.com>
	<20040114171252.4d873c51.akpm@osdl.org>
	<20040114172946.03e54706.akpm@osdl.org>
	<20040114174012.H13471@mvista.com>
X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.10; i386-redhat-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Return-Path: <davem@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: 3967
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: davem@redhat.com
Precedence: bulk
X-list: linux-mips

On Wed, 14 Jan 2004 17:40:12 -0800
Jun Sun <jsun@mvista.com> wrote:

> Looking at my tree (which is from linux-mips.org), it appears
> arm, sparc, sparc64, and sh have tlb_start_vma() defined to call
> cache flushing.

Correct, in fact every platform where cache flushing matters
at all (ie. where flush_cache_*() routines actually need to
flush a cpu cache), they should have tlb_start_vma() do such
a flush.

> What exactly does tlb_start_vma()/tlb_end_vma() mean?  There is
> only one invocation instance, which is significant enough to infer
> the meaning.  :)

When the kernel unmaps a mmap region of a process (either for the
sake of munmap() or tearing down all mapping during exit()) tlb_start_vma()
is called, the page table mappings in the region are torn down one by
one, then a tlb_end_vma() call is made.

At the top level, ie. whoever invokes unmap_page_range(), there will
be a tlb_gather_mmu() call.

In order to properly optimize the cache flushes, most platforms do the
following:

1) The tlb->fullmm boolean keeps trap of whether this is just a munmap()
   unmapping operation (if zero) or a full address space teardown
   (if non-zero).

2) In the full address space teardown case, and thus tlb->fullmm is
   non-zero, the top level will do the explict flush_cache_mm()
   (see mm/mmap.c:exit_mmap()), therefore the tlb_start_vma()
   implementation need not do the flush, otherwise it does.

   This is why sparc64 and friends implement it like this:

#define tlb_start_vma(tlb, vma) \
do {    if (!(tlb)->fullmm)     \
                flush_cache_range(vma, vma->vm_start, vma->vm_end); \
} while (0)

Hope this clears things up.

Someone should probably take what I just wrote, expand and organize it,
then add such content to Documentation/cachetlb.txt

From dom@mips.com Thu Jan 15 09:10:40 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 15 Jan 2004 09:10:41 +0000 (GMT)
Received: from alg145.algor.co.uk ([IPv6:::ffff:62.254.210.145]:26891 "EHLO
	dmz.algor.co.uk") by linux-mips.org with ESMTP id <S8225198AbUAOJKk>;
	Thu, 15 Jan 2004 09:10:40 +0000
Received: from alg158.algor.co.uk ([62.254.210.158] helo=olympia.mips.com)
	by dmz.algor.co.uk with esmtp (Exim 3.35 #1 (Debian))
	id 1Ah3Ro-0001mu-00; Thu, 15 Jan 2004 09:05:52 +0000
Received: from olympia.mips.com ([192.168.192.128] helo=doms-laptop.algor.co.uk)
	by olympia.mips.com with esmtp (Exim 3.36 #1 (Debian))
	id 1Ah3W4-0002JS-00; Thu, 15 Jan 2004 09:10:17 +0000
From: Dominic Sweetman <dom@mips.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <16390.22845.838720.511263@doms-laptop.algor.co.uk>
Date: Thu, 15 Jan 2004 09:11:25 +0000
To: Charlie Brady <charlieb-linux-mips@e-smith.com>
Cc: Jun Sun <jsun@mvista.com>, linux-mips@linux-mips.org
Subject: Re: Broadcom 4702?
In-Reply-To: <Pine.LNX.4.44.0401142235300.17500-100000@allspice.nssg.mitel.com>
References: <20040114170355.G13471@mvista.com>
	<Pine.LNX.4.44.0401142235300.17500-100000@allspice.nssg.mitel.com>
X-Mailer: VM 7.07 under 21.4 (patch 10) "Military Intelligence (RC5 Windows)" XEmacs Lucid
X-MTUK-Scanner: Found to be clean
X-MTUK-SpamCheck: not spam, SpamAssassin (score=-4.9, required 4, BAYES_00)
Return-Path: <dom@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: 3968
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, 14 Jan 2004, Jun Sun wrote:
> 
> > Since we are on this subject, I am curious if I buy a Cisco's router
> > whether it is considered that Cisco distributs the binaries to me
> > and whether I can demand for the source code if they are GPL'ed software.
> ...
> > I can see arguments go either way.  Do open source community and
> > industry have some concensus on this issue?

Charlie replied...

> Please read the various licenses (GPL and other), and consult your
> lawyer.  And if you want a definitive answer (in your jurisdiction)
> get the license tested in Court (and subsequent Appeals Courts). :-)

But Jun Sun asked whether distribution of a binary in a ROM inside a
black box might not really count as distribution.  I don't think you
need a lawyer to resolve that.  If the software was a computer game
(for example) I can't quite see its commercial owners smiling
indulgently and saying "it's only a ROM, carry on...", and I don't see
them having trouble over their position in court.

So yes, binary code distributed in a black box is still distributed,
and if it was GPL software you are entitled to the source code.  It's
sensible of Cisco to put it quietly on a web site somewhere.

--
Dominic Sweetman
(not necessarily the view of MIPS Technologies)



From ralf@linux-mips.org Thu Jan 15 09:39:46 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 15 Jan 2004 09:39:48 +0000 (GMT)
Received: from p508B5EC9.dip.t-dialin.net ([IPv6:::ffff:80.139.94.201]:5650
	"EHLO mail.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225198AbUAOJjq>; Thu, 15 Jan 2004 09:39:46 +0000
Received: from fluff.linux-mips.net (fluff.linux-mips.net [127.0.0.1])
	by mail.linux-mips.net (8.12.8/8.12.8) with ESMTP id i0F9ddDs011629
	for <linux-mips@linux-mips.org>; Thu, 15 Jan 2004 10:39:39 +0100
Received: (from ralf@localhost)
	by fluff.linux-mips.net (8.12.8/8.12.8/Submit) id i0F9dd4m011628
	for linux-mips@linux-mips.org; Thu, 15 Jan 2004 10:39:39 +0100
Date: Thu, 15 Jan 2004 10:39:39 +0100
From: Ralf Baechle <ralf@linux-mips.org>
To: linux-mips@linux-mips.org
Subject: Re: CVS Update@-mips.org: linux
Message-ID: <20040115093939.GA11029@linux-mips.org>
References: <20040115062800Z8225198-9616+139@linux-mips.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20040115062800Z8225198-9616+139@linux-mips.org>
User-Agent: Mutt/1.4i
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: 3969
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 15, 2004 at 06:27:55AM +0000, ppopov@linux-mips.org wrote:

> Log message:
> 	Sync up latest 2.4 Au1x board files with 2.6. Not all drivers are
> 	synced up yet.

Excellent :-)

  Ralf

From ralf@linux-mips.org Thu Jan 15 09:48:52 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 15 Jan 2004 09:48:53 +0000 (GMT)
Received: from p508B5EC9.dip.t-dialin.net ([IPv6:::ffff:80.139.94.201]:14098
	"EHLO mail.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225272AbUAOJsw>; Thu, 15 Jan 2004 09:48:52 +0000
Received: from fluff.linux-mips.net (fluff.linux-mips.net [127.0.0.1])
	by mail.linux-mips.net (8.12.8/8.12.8) with ESMTP id i0F9moDs011805;
	Thu, 15 Jan 2004 10:48:50 +0100
Received: (from ralf@localhost)
	by fluff.linux-mips.net (8.12.8/8.12.8/Submit) id i0F9mnb2011804;
	Thu, 15 Jan 2004 10:48:49 +0100
Date: Thu, 15 Jan 2004 10:48:49 +0100
From: Ralf Baechle <ralf@linux-mips.org>
To: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
Cc: karthikeyan natarajan <karthik_96cse@yahoo.com>,
	linux-mips@linux-mips.org
Subject: Re: How to configure the cache size in r4000
Message-ID: <20040115094849.GC11029@linux-mips.org>
References: <20040111124828.71884.qmail@web10103.mail.yahoo.com> <Pine.LNX.4.55.0401121345490.21851@jurand.ds.pg.gda.pl> <20040113163543.GA31459@linux-mips.org> <Pine.LNX.4.55.0401131741390.3158@jurand.ds.pg.gda.pl>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Pine.LNX.4.55.0401131741390.3158@jurand.ds.pg.gda.pl>
User-Agent: Mutt/1.4i
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: 3970
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 13, 2004 at 05:48:17PM +0100, Maciej W. Rozycki wrote:

>  BTW, the DECstation uses 16-byte lines for the D-cache and the I-Cache
> and 32-byte lines for the S-cache.  With the S-cache size at 1MB and up to
> 480MB of RAM does it qualify as a tiny system? ;-)

Does it run on two AAA batteries ;-)

  Ralf

From ralf@linux-mips.org Thu Jan 15 11:31:00 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 15 Jan 2004 11:31:01 +0000 (GMT)
Received: from p508B5EC9.dip.t-dialin.net ([IPv6:::ffff:80.139.94.201]:38931
	"EHLO mail.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225366AbUAOLbA>; Thu, 15 Jan 2004 11:31:00 +0000
Received: from fluff.linux-mips.net (fluff.linux-mips.net [127.0.0.1])
	by mail.linux-mips.net (8.12.8/8.12.8) with ESMTP id i0FBUsDs014568;
	Thu, 15 Jan 2004 12:30:54 +0100
Received: (from ralf@localhost)
	by fluff.linux-mips.net (8.12.8/8.12.8/Submit) id i0FBUrqm014567;
	Thu, 15 Jan 2004 12:30:53 +0100
Date: Thu, 15 Jan 2004 12:30:53 +0100
From: Ralf Baechle <ralf@linux-mips.org>
To: Yoichi Yuasa <yuasa@hh.iij4u.or.jp>
Cc: linux-mips <linux-mips@linux-mips.org>
Subject: Re: [PATCH][2.4] Update NEC VRC4171's base  functions for VR4100 series
Message-ID: <20040115113053.GA14304@linux-mips.org>
References: <20040114005713.492b2aa0.yuasa@hh.iij4u.or.jp>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20040114005713.492b2aa0.yuasa@hh.iij4u.or.jp>
User-Agent: Mutt/1.4i
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: 3971
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 14, 2004 at 12:57:13AM +0900, Yoichi Yuasa wrote:

> I updated the patch for VRC4171's base functions.
> The VRC4171 is companion chip for NEC VR4111 and VR4121.
> 
> This patch exists for linux_2_4 tag of linux-mips.org CVS.
> Please apply this patch.

I applied both 2.4 and 2.6 versions.

  Ralf

From macro@ds2.pg.gda.pl Thu Jan 15 13:31:29 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 15 Jan 2004 13:31:30 +0000 (GMT)
Received: from jurand.ds.pg.gda.pl ([IPv6:::ffff:153.19.208.2]:63120 "EHLO
	jurand.ds.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8224850AbUAONb3>; Thu, 15 Jan 2004 13:31:29 +0000
Received: by jurand.ds.pg.gda.pl (Postfix, from userid 1011)
	id B8A574C175; Thu, 15 Jan 2004 14:31:26 +0100 (CET)
Received: from localhost (localhost [127.0.0.1])
	by jurand.ds.pg.gda.pl (Postfix) with ESMTP
	id A76AC474E9; Thu, 15 Jan 2004 14:31:26 +0100 (CET)
Date: Thu, 15 Jan 2004 14:31:26 +0100 (CET)
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To: Ralf Baechle <ralf@linux-mips.org>
Cc: karthikeyan natarajan <karthik_96cse@yahoo.com>,
	linux-mips@linux-mips.org
Subject: Re: How to configure the cache size in r4000
In-Reply-To: <20040115094849.GC11029@linux-mips.org>
Message-ID: <Pine.LNX.4.55.0401151414080.17864@jurand.ds.pg.gda.pl>
References: <20040111124828.71884.qmail@web10103.mail.yahoo.com>
 <Pine.LNX.4.55.0401121345490.21851@jurand.ds.pg.gda.pl>
 <20040113163543.GA31459@linux-mips.org> <Pine.LNX.4.55.0401131741390.3158@jurand.ds.pg.gda.pl>
 <20040115094849.GC11029@linux-mips.org>
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: 3972
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, 15 Jan 2004, Ralf Baechle wrote:

> >  BTW, the DECstation uses 16-byte lines for the D-cache and the I-Cache
> > and 32-byte lines for the S-cache.  With the S-cache size at 1MB and up to
> > 480MB of RAM does it qualify as a tiny system? ;-)
> 
> Does it run on two AAA batteries ;-)

 Well, not even on three ones... ;-)

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

From rathann@icm.edu.pl Thu Jan 15 14:14:44 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 15 Jan 2004 14:14:45 +0000 (GMT)
Received: from gw.icm.edu.pl ([IPv6:::ffff:212.87.0.39]:19559 "EHLO
	atol.icm.edu.pl") by linux-mips.org with ESMTP id <S8225364AbUAOOOn>;
	Thu, 15 Jan 2004 14:14:43 +0000
Received: from rekin.icm.edu.pl (rekin.icm.edu.pl [192.168.1.132])
	by atol.icm.edu.pl (8.12.6/8.12.6/rzm-4.6/icm) with ESMTP id i0FEES4p010804
	for <linux-mips@linux-mips.org>; Thu, 15 Jan 2004 15:14:28 +0100 (CET)
Received: from rathann by rekin.icm.edu.pl with local (Exim 3.35 #1 (Debian))
	id 1Ah8GR-000896-00
	for <linux-mips@linux-mips.org>; Thu, 15 Jan 2004 15:14:27 +0100
Date: Thu, 15 Jan 2004 15:14:27 +0100
From: "Dominik 'Rathann' Mierzejewski" <rathann@icm.edu.pl>
To: linux-mips@linux-mips.org
Subject: Current 2.4 CVS (2.4.24-pre2) doesn't boot on SGI Indy
Message-ID: <20040115141427.GA28546@icm.edu.pl>
Mail-Followup-To: linux-mips@linux-mips.org
References: <20040111124828.71884.qmail@web10103.mail.yahoo.com> <Pine.LNX.4.55.0401121345490.21851@jurand.ds.pg.gda.pl> <20040113163543.GA31459@linux-mips.org> <Pine.LNX.4.55.0401131741390.3158@jurand.ds.pg.gda.pl> <20040115094849.GC11029@linux-mips.org> <Pine.LNX.4.55.0401151414080.17864@jurand.ds.pg.gda.pl>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="0OAP2g/MAC+5xKAE"
Content-Disposition: inline
In-Reply-To: <Pine.LNX.4.55.0401151414080.17864@jurand.ds.pg.gda.pl>
User-Agent: Mutt/1.3.28i
Return-Path: <rathann@icm.edu.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: 3973
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: rathann@icm.edu.pl
Precedence: bulk
X-list: linux-mips


--0OAP2g/MAC+5xKAE
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

Hello, list.

I've just compiled it and it won't boot properly. It hangs at
...
Freeing unused kernel memory (72k)

.config attached.

I'm booting with arcboot. 2.4.22 (from the same CVS, but earlier)
boots fine.

# arcboot.conf
#
label=linux
  image=/boot/vmlinux-2.4.24-pre2
  append="root=/dev/sda1"

label=linux-2.4.22
  image=/boot/vmlinux-2.4.22
  append="root=/dev/sda1"

label=linux-deb
  image=/boot/vmlinux-2.4.19-r4k-ip22
  append="root=/dev/sda1"

% cat /etc/fstab 
/dev/sda1               /               ext2    defaults        1 1
/dev/sda2               swap            swap    defaults        0 0
none                    /proc           proc    defaults        0 0
none                    /dev/shm        tmpfs   defaults        0 0
none                    /dev/pts        devpts  gid=5,mode=620  0 0

Any clues?

-- 
Dominik 'Rathann' Mierzejewski <rathann@icm.edu.pl>                                                 
Interdisciplinary Centre for Mathematical and Computational Modelling                               
Warsaw University  |  http://www.icm.edu.pl  |  tel. +48 (22) 5540810                               

--0OAP2g/MAC+5xKAE
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename=".config"

#
# Automatically generated by make menuconfig: don't edit
#
CONFIG_MIPS=y
CONFIG_MIPS32=y
# CONFIG_MIPS64 is not set

#
# Code maturity level options
#
CONFIG_EXPERIMENTAL=y

#
# Loadable module support
#
CONFIG_MODULES=y
# CONFIG_MODVERSIONS is not set
CONFIG_KMOD=y

#
# Machine selection
#
# CONFIG_ACER_PICA_61 is not set
# CONFIG_MIPS_BOSPORUS is not set
# CONFIG_MIPS_MIRAGE is not set
# CONFIG_MIPS_DB1000 is not set
# CONFIG_MIPS_DB1100 is not set
# CONFIG_MIPS_DB1500 is not set
# CONFIG_MIPS_PB1000 is not set
# CONFIG_MIPS_PB1100 is not set
# CONFIG_MIPS_PB1500 is not set
# CONFIG_MIPS_HYDROGEN3 is not set
# CONFIG_MIPS_PB1550 is not set
# CONFIG_MIPS_XXS1500 is not set
# CONFIG_MIPS_MTX1 is not set
# CONFIG_COGENT_CSB250 is not set
# CONFIG_BAGET_MIPS is not set
# CONFIG_CASIO_E55 is not set
# CONFIG_MIPS_COBALT is not set
# CONFIG_DECSTATION is not set
# CONFIG_MIPS_EV64120 is not set
# CONFIG_MIPS_EV96100 is not set
# CONFIG_MIPS_IVR is not set
# CONFIG_HP_LASERJET is not set
# CONFIG_IBM_WORKPAD is not set
# CONFIG_LASAT is not set
# CONFIG_MIPS_ITE8172 is not set
# CONFIG_MIPS_ATLAS is not set
# CONFIG_MIPS_MAGNUM_4000 is not set
# CONFIG_MIPS_MALTA is not set
# CONFIG_MIPS_SEAD is not set
# CONFIG_MOMENCO_OCELOT is not set
# CONFIG_MOMENCO_OCELOT_G is not set
# CONFIG_MOMENCO_OCELOT_C is not set
# CONFIG_MOMENCO_JAGUAR_ATX is not set
# CONFIG_PMC_YOSEMITE is not set
# CONFIG_DDB5074 is not set
# CONFIG_DDB5476 is not set
# CONFIG_DDB5477 is not set
# CONFIG_NEC_OSPREY is not set
# CONFIG_NEC_EAGLE is not set
# CONFIG_OLIVETTI_M700 is not set
# CONFIG_NINO is not set
CONFIG_SGI_IP22=y
# CONFIG_SGI_IP27 is not set
# CONFIG_SIBYTE_SB1xxx_SOC is not set
# CONFIG_SNI_RM200_PCI is not set
# CONFIG_TANBAC_TB0226 is not set
# CONFIG_TANBAC_TB0229 is not set
# CONFIG_TOSHIBA_JMR3927 is not set
# CONFIG_TOSHIBA_RBTX4927 is not set
# CONFIG_VICTOR_MPC30X is not set
# CONFIG_ZAO_CAPCELLA is not set
# CONFIG_HIGHMEM is not set
CONFIG_RWSEM_GENERIC_SPINLOCK=y
# CONFIG_RWSEM_XCHGADD_ALGORITHM is not set
CONFIG_ARC32=y
CONFIG_ARC_PROMLIB=y
CONFIG_BOARD_SCACHE=y
CONFIG_BOOT_ELF32=y
# CONFIG_SWAP_IO_SPACE_W is not set
CONFIG_SWAP_IO_SPACE_L=y
CONFIG_IRQ_CPU=y
CONFIG_L1_CACHE_SHIFT=5
CONFIG_NEW_TIME_C=y
CONFIG_NONCOHERENT_IO=y
CONFIG_PC_KEYB=y
# CONFIG_MIPS_AU1000 is not set

#
# CPU selection
#
# CONFIG_CPU_MIPS32 is not set
# CONFIG_CPU_MIPS64 is not set
# CONFIG_CPU_R3000 is not set
# CONFIG_CPU_TX39XX is not set
# CONFIG_CPU_VR41XX is not set
# CONFIG_CPU_R4300 is not set
CONFIG_CPU_R4X00=y
# CONFIG_CPU_TX49XX is not set
# CONFIG_CPU_R5000 is not set
# CONFIG_CPU_R5432 is not set
# CONFIG_CPU_R6000 is not set
# CONFIG_CPU_NEVADA is not set
# CONFIG_CPU_R8000 is not set
# CONFIG_CPU_R10000 is not set
# CONFIG_CPU_RM7000 is not set
# CONFIG_CPU_RM9000 is not set
# CONFIG_CPU_SB1 is not set
CONFIG_PAGE_SIZE_4KB=y
# CONFIG_PAGE_SIZE_16KB is not set
# CONFIG_PAGE_SIZE_64KB is not set
# CONFIG_64BIT_PHYS_ADDR is not set
# CONFIG_CPU_ADVANCED is not set
CONFIG_CPU_HAS_LLSC=y
CONFIG_CPU_HAS_LLDSCD=y
# CONFIG_CPU_HAS_WB is not set
CONFIG_CPU_HAS_SYNC=y

#
# General setup
#
# CONFIG_CPU_LITTLE_ENDIAN is not set
CONFIG_BINFMT_IRIX=y
CONFIG_ARC_CONSOLE=y
CONFIG_NET=y
# CONFIG_EISA is not set
# CONFIG_PCI is not set
# CONFIG_ISA is not set
# CONFIG_TC is not set
# CONFIG_MCA is not set
# CONFIG_SBUS is not set
# CONFIG_HOTPLUG is not set
# CONFIG_PCMCIA is not set
# CONFIG_HOTPLUG_PCI is not set
CONFIG_SYSVIPC=y
CONFIG_BSD_PROCESS_ACCT=y
CONFIG_SYSCTL=y
CONFIG_KCORE_ELF=y
# CONFIG_KCORE_AOUT is not set
# CONFIG_BINFMT_AOUT is not set
CONFIG_BINFMT_ELF=y
# CONFIG_MIPS32_COMPAT is not set
# CONFIG_MIPS32_O32 is not set
# CONFIG_MIPS32_N32 is not set
# CONFIG_BINFMT_ELF32 is not set
CONFIG_BINFMT_MISC=m
# CONFIG_OOM_KILLER is not set

#
# Memory Technology Devices (MTD)
#
# CONFIG_MTD is not set

#
# Parallel port support
#
CONFIG_PARPORT=m
# CONFIG_PARPORT_PC is not set
# CONFIG_PARPORT_AMIGA is not set
# CONFIG_PARPORT_MFC3 is not set
# CONFIG_PARPORT_ATARI is not set
# CONFIG_PARPORT_GSC is not set
# CONFIG_PARPORT_SUNBPP is not set
CONFIG_PARPORT_IP22=m
# CONFIG_PARPORT_OTHER is not set
# CONFIG_PARPORT_1284 is not set

#
# Plug and Play configuration
#
CONFIG_PNP=m
# CONFIG_ISAPNP is not set

#
# Block devices
#
# CONFIG_BLK_DEV_FD is not set
# CONFIG_BLK_DEV_XD is not set
# CONFIG_PARIDE is not set
# CONFIG_BLK_CPQ_DA is not set
# CONFIG_BLK_CPQ_CISS_DA is not set
# CONFIG_CISS_SCSI_TAPE is not set
# CONFIG_CISS_MONITOR_THREAD is not set
# CONFIG_BLK_DEV_DAC960 is not set
# CONFIG_BLK_DEV_UMEM is not set
CONFIG_BLK_DEV_LOOP=m
# CONFIG_BLK_DEV_NBD is not set
# CONFIG_BLK_DEV_RAM is not set
# CONFIG_BLK_DEV_INITRD is not set
CONFIG_BLK_STATS=y

#
# Multi-device support (RAID and LVM)
#
# CONFIG_MD is not set
# CONFIG_BLK_DEV_MD is not set
# CONFIG_MD_LINEAR is not set
# CONFIG_MD_RAID0 is not set
# CONFIG_MD_RAID1 is not set
# CONFIG_MD_RAID5 is not set
# CONFIG_MD_MULTIPATH is not set
# CONFIG_BLK_DEV_LVM is not set

#
# Networking options
#
CONFIG_PACKET=m
CONFIG_PACKET_MMAP=y
CONFIG_NETLINK_DEV=y
# CONFIG_NETFILTER is not set
CONFIG_FILTER=y
CONFIG_UNIX=m
CONFIG_INET=y
CONFIG_IP_MULTICAST=y
# CONFIG_IP_ADVANCED_ROUTER is not set
CONFIG_IP_PNP=y
CONFIG_IP_PNP_DHCP=y
CONFIG_IP_PNP_BOOTP=y
# CONFIG_IP_PNP_RARP is not set
# CONFIG_NET_IPIP is not set
# CONFIG_NET_IPGRE is not set
# CONFIG_IP_MROUTE is not set
# CONFIG_ARPD is not set
CONFIG_INET_ECN=y
CONFIG_SYN_COOKIES=y
# CONFIG_IPV6 is not set
# CONFIG_KHTTPD is not set

#
#    SCTP Configuration (EXPERIMENTAL)
#
CONFIG_IPV6_SCTP__=y
# CONFIG_IP_SCTP is not set
# CONFIG_ATM is not set
# CONFIG_VLAN_8021Q is not set
# CONFIG_IPX is not set
# CONFIG_ATALK is not set

#
# Appletalk devices
#
# CONFIG_DEV_APPLETALK is not set
# CONFIG_DECNET is not set
# CONFIG_BRIDGE is not set
# CONFIG_X25 is not set
# CONFIG_LAPB is not set
# CONFIG_LLC is not set
# CONFIG_NET_DIVERT is not set
# CONFIG_ECONET is not set
# CONFIG_WAN_ROUTER is not set
# CONFIG_NET_FASTROUTE is not set
# CONFIG_NET_HW_FLOWCONTROL is not set

#
# QoS and/or fair queueing
#
# CONFIG_NET_SCHED is not set

#
# Network testing
#
# CONFIG_NET_PKTGEN is not set

#
# Telephony Support
#
# CONFIG_PHONE is not set
# CONFIG_PHONE_IXJ is not set
# CONFIG_PHONE_IXJ_PCMCIA is not set

#
# ATA/IDE/MFM/RLL support
#
# CONFIG_IDE is not set
# CONFIG_BLK_DEV_IDE_MODES is not set
# CONFIG_BLK_DEV_HD is not set

#
# SCSI support
#
CONFIG_SCSI=y
CONFIG_BLK_DEV_SD=y
CONFIG_SD_EXTRA_DEVS=40
# CONFIG_CHR_DEV_ST is not set
# CONFIG_CHR_DEV_OSST is not set
CONFIG_BLK_DEV_SR=m
# CONFIG_BLK_DEV_SR_VENDOR is not set
CONFIG_SR_EXTRA_DEVS=2
CONFIG_CHR_DEV_SG=m
# CONFIG_SCSI_DEBUG_QUEUES is not set
# CONFIG_SCSI_MULTI_LUN is not set
CONFIG_SCSI_CONSTANTS=y
# CONFIG_SCSI_LOGGING is not set

#
# SCSI low-level drivers
#
CONFIG_SGIWD93_SCSI=y
# CONFIG_SCSI_7000FASST is not set
# CONFIG_SCSI_ACARD is not set
# CONFIG_SCSI_AHA152X is not set
# CONFIG_SCSI_AHA1542 is not set
# CONFIG_SCSI_AHA1740 is not set
# CONFIG_SCSI_AACRAID is not set
# CONFIG_SCSI_AIC7XXX is not set
# CONFIG_SCSI_AIC79XX is not set
# CONFIG_SCSI_AIC7XXX_OLD is not set
# CONFIG_SCSI_DPT_I2O is not set
# CONFIG_SCSI_ADVANSYS is not set
# CONFIG_SCSI_IN2000 is not set
# CONFIG_SCSI_AM53C974 is not set
# CONFIG_SCSI_MEGARAID is not set
# CONFIG_SCSI_MEGARAID2 is not set
# CONFIG_SCSI_BUSLOGIC is not set
# CONFIG_SCSI_DMX3191D is not set
# CONFIG_SCSI_DTC3280 is not set
# CONFIG_SCSI_EATA is not set
# CONFIG_SCSI_EATA_DMA is not set
# CONFIG_SCSI_EATA_PIO is not set
# CONFIG_SCSI_FUTURE_DOMAIN is not set
# CONFIG_SCSI_GDTH is not set
# CONFIG_SCSI_GENERIC_NCR5380 is not set
# CONFIG_SCSI_INITIO is not set
# CONFIG_SCSI_INIA100 is not set
# CONFIG_SCSI_PPA is not set
# CONFIG_SCSI_IMM is not set
# CONFIG_SCSI_NCR53C406A is not set
# CONFIG_SCSI_NCR53C7xx is not set
# CONFIG_SCSI_PAS16 is not set
# CONFIG_SCSI_PCI2000 is not set
# CONFIG_SCSI_PCI2220I is not set
# CONFIG_SCSI_PSI240I is not set
# CONFIG_SCSI_QLOGIC_FAS is not set
# CONFIG_SCSI_SIM710 is not set
# CONFIG_SCSI_SYM53C416 is not set
# CONFIG_SCSI_T128 is not set
# CONFIG_SCSI_U14_34F is not set
# CONFIG_SCSI_NSP32 is not set
# CONFIG_SCSI_DEBUG is not set

#
# Fusion MPT device support
#
# CONFIG_FUSION is not set
# CONFIG_FUSION_BOOT is not set
# CONFIG_FUSION_ISENSE is not set
# CONFIG_FUSION_CTL is not set
# CONFIG_FUSION_LAN is not set

#
# Network device support
#
CONFIG_NETDEVICES=y

#
# ARCnet devices
#
# CONFIG_ARCNET is not set
# CONFIG_DUMMY is not set
# CONFIG_BONDING is not set
# CONFIG_EQUALIZER is not set
# CONFIG_TUN is not set
# CONFIG_ETHERTAP is not set

#
# Ethernet (10 or 100Mbit)
#
CONFIG_NET_ETHERNET=y
# CONFIG_SUNLANCE is not set
# CONFIG_SUNBMAC is not set
# CONFIG_SUNQE is not set
# CONFIG_SUNGEM is not set
# CONFIG_NET_VENDOR_3COM is not set
# CONFIG_LANCE is not set
# CONFIG_NET_VENDOR_SMC is not set
# CONFIG_NET_VENDOR_RACAL is not set
# CONFIG_NET_ISA is not set
# CONFIG_NET_PCI is not set
# CONFIG_NET_POCKET is not set
CONFIG_SGISEEQ=m

#
# Ethernet (1000 Mbit)
#
# CONFIG_ACENIC is not set
# CONFIG_DL2K is not set
# CONFIG_E1000 is not set
# CONFIG_MYRI_SBUS is not set
# CONFIG_NS83820 is not set
# CONFIG_HAMACHI is not set
# CONFIG_YELLOWFIN is not set
# CONFIG_R8169 is not set
# CONFIG_SK98LIN is not set
# CONFIG_TIGON3 is not set
# CONFIG_FDDI is not set
# CONFIG_HIPPI is not set
# CONFIG_PLIP is not set
# CONFIG_PPP is not set
# CONFIG_SLIP is not set

#
# Wireless LAN (non-hamradio)
#
# CONFIG_NET_RADIO is not set

#
# Token Ring devices
#
# CONFIG_TR is not set
# CONFIG_NET_FC is not set
# CONFIG_RCPCI is not set
# CONFIG_SHAPER is not set

#
# Wan interfaces
#
# CONFIG_WAN is not set

#
# Amateur Radio support
#
# CONFIG_HAMRADIO is not set

#
# IrDA (infrared) support
#
# CONFIG_IRDA is not set

#
# ISDN subsystem
#
# CONFIG_ISDN is not set

#
# Input core support
#
CONFIG_INPUT=m
CONFIG_INPUT_KEYBDEV=m
CONFIG_INPUT_MOUSEDEV=m
CONFIG_INPUT_MOUSEDEV_SCREEN_X=1024
CONFIG_INPUT_MOUSEDEV_SCREEN_Y=768
# CONFIG_INPUT_JOYDEV is not set
# CONFIG_INPUT_EVDEV is not set
# CONFIG_INPUT_UINPUT is not set

#
# Character devices
#
CONFIG_VT=y
CONFIG_VT_CONSOLE=y
# CONFIG_SERIAL is not set
# CONFIG_SERIAL_EXTENDED is not set
# CONFIG_SERIAL_NONSTANDARD is not set
CONFIG_UNIX98_PTYS=y
CONFIG_UNIX98_PTY_COUNT=256
# CONFIG_PRINTER is not set
# CONFIG_PPDEV is not set
# CONFIG_TIPAR is not set

#
# I2C support
#
CONFIG_I2C=m
CONFIG_I2C_ALGOBIT=m
# CONFIG_I2C_PHILIPSPAR is not set
# CONFIG_I2C_ELV is not set
# CONFIG_I2C_VELLEMAN is not set
# CONFIG_SCx200_I2C is not set
# CONFIG_SCx200_ACB is not set
# CONFIG_I2C_ALGOPCF is not set
CONFIG_I2C_ALGO_SGI=m
CONFIG_I2C_CHARDEV=m
CONFIG_I2C_PROC=m

#
# Mice
#
# CONFIG_BUSMOUSE is not set
CONFIG_MOUSE=y
CONFIG_PSMOUSE=y
# CONFIG_82C710_MOUSE is not set
# CONFIG_PC110_PAD is not set
# CONFIG_MK712_MOUSE is not set

#
# Joysticks
#
# CONFIG_INPUT_GAMEPORT is not set
# CONFIG_INPUT_NS558 is not set
# CONFIG_INPUT_LIGHTNING is not set
# CONFIG_INPUT_PCIGAME is not set
# CONFIG_INPUT_CS461X is not set
# CONFIG_INPUT_EMU10K1 is not set
# CONFIG_INPUT_SERIO is not set
# CONFIG_INPUT_SERPORT is not set
# CONFIG_INPUT_ANALOG is not set
# CONFIG_INPUT_A3D is not set
# CONFIG_INPUT_ADI is not set
# CONFIG_INPUT_COBRA is not set
# CONFIG_INPUT_GF2K is not set
# CONFIG_INPUT_GRIP is not set
# CONFIG_INPUT_INTERACT is not set
# CONFIG_INPUT_TMDC is not set
# CONFIG_INPUT_SIDEWINDER is not set
# CONFIG_INPUT_IFORCE_USB is not set
# CONFIG_INPUT_IFORCE_232 is not set
# CONFIG_INPUT_WARRIOR is not set
# CONFIG_INPUT_MAGELLAN is not set
# CONFIG_INPUT_SPACEORB is not set
# CONFIG_INPUT_SPACEBALL is not set
# CONFIG_INPUT_STINGER is not set
# CONFIG_INPUT_DB9 is not set
# CONFIG_INPUT_GAMECON is not set
# CONFIG_INPUT_TURBOGRAFX is not set
# CONFIG_QIC02_TAPE is not set
# CONFIG_IPMI_HANDLER is not set
# CONFIG_IPMI_PANIC_EVENT is not set
# CONFIG_IPMI_DEVICE_INTERFACE is not set
# CONFIG_IPMI_KCS is not set
# CONFIG_IPMI_WATCHDOG is not set

#
# Watchdog Cards
#
CONFIG_WATCHDOG=y
# CONFIG_WATCHDOG_NOWAYOUT is not set
# CONFIG_ACQUIRE_WDT is not set
# CONFIG_ADVANTECH_WDT is not set
# CONFIG_ALIM1535_WDT is not set
# CONFIG_ALIM7101_WDT is not set
# CONFIG_SC520_WDT is not set
# CONFIG_PCWATCHDOG is not set
# CONFIG_EUROTECH_WDT is not set
# CONFIG_IB700_WDT is not set
# CONFIG_WAFER_WDT is not set
# CONFIG_I810_TCO is not set
# CONFIG_MIXCOMWD is not set
# CONFIG_60XX_WDT is not set
# CONFIG_SC1200_WDT is not set
# CONFIG_SCx200_WDT is not set
# CONFIG_SOFT_WATCHDOG is not set
# CONFIG_W83877F_WDT is not set
# CONFIG_WDT is not set
# CONFIG_WDTPCI is not set
# CONFIG_MACHZ_WDT is not set
CONFIG_INDYDOG=m
# CONFIG_AMD7XX_TCO is not set
# CONFIG_SCx200_GPIO is not set
# CONFIG_AMD_PM768 is not set
# CONFIG_NVRAM is not set
# CONFIG_RTC is not set
CONFIG_MIPS_RTC=m
# CONFIG_DS1286 is not set
# CONFIG_DTLK is not set
# CONFIG_R3964 is not set
# CONFIG_APPLICOM is not set

#
# Ftape, the floppy tape device driver
#
# CONFIG_FTAPE is not set
# CONFIG_AGP is not set

#
# Direct Rendering Manager (XFree86 DRI support)
#
# CONFIG_DRM is not set

#
# File systems
#
CONFIG_QUOTA=y
# CONFIG_QFMT_V2 is not set
CONFIG_AUTOFS_FS=m
CONFIG_AUTOFS4_FS=m
# CONFIG_REISERFS_FS is not set
# CONFIG_REISERFS_CHECK is not set
# CONFIG_REISERFS_PROC_INFO is not set
# CONFIG_ADFS_FS is not set
# CONFIG_ADFS_FS_RW is not set
# CONFIG_AFFS_FS is not set
# CONFIG_HFS_FS is not set
# CONFIG_HFSPLUS_FS is not set
# CONFIG_BEFS_FS is not set
# CONFIG_BEFS_DEBUG is not set
# CONFIG_BFS_FS is not set
CONFIG_EXT3_FS=y
CONFIG_JBD=y
# CONFIG_JBD_DEBUG is not set
CONFIG_FAT_FS=m
# CONFIG_MSDOS_FS is not set
# CONFIG_UMSDOS_FS is not set
CONFIG_VFAT_FS=m
# CONFIG_EFS_FS is not set
# CONFIG_JFFS_FS is not set
# CONFIG_JFFS2_FS is not set
# CONFIG_CRAMFS is not set
# CONFIG_TMPFS is not set
CONFIG_RAMFS=y
CONFIG_ISO9660_FS=m
CONFIG_JOLIET=y
# CONFIG_ZISOFS is not set
# CONFIG_JFS_FS is not set
# CONFIG_JFS_DEBUG is not set
# CONFIG_JFS_STATISTICS is not set
# CONFIG_MINIX_FS is not set
# CONFIG_VXFS_FS is not set
# CONFIG_NTFS_FS is not set
# CONFIG_NTFS_RW is not set
# CONFIG_HPFS_FS is not set
CONFIG_PROC_FS=y
# CONFIG_DEVFS_FS is not set
# CONFIG_DEVFS_MOUNT is not set
# CONFIG_DEVFS_DEBUG is not set
CONFIG_DEVPTS_FS=y
# CONFIG_QNX4FS_FS is not set
# CONFIG_QNX4FS_RW is not set
# CONFIG_ROMFS_FS is not set
CONFIG_EXT2_FS=y
# CONFIG_SYSV_FS is not set
# CONFIG_UDF_FS is not set
# CONFIG_UDF_RW is not set
# CONFIG_UFS_FS is not set
# CONFIG_UFS_FS_WRITE is not set
CONFIG_XFS_FS=m
CONFIG_XFS_QUOTA=y
# CONFIG_XFS_RT is not set
# CONFIG_XFS_TRACE is not set
# CONFIG_XFS_DEBUG is not set

#
# Network File Systems
#
# CONFIG_CODA_FS is not set
# CONFIG_INTERMEZZO_FS is not set
CONFIG_NFS_FS=m
CONFIG_NFS_V3=y
# CONFIG_NFS_DIRECTIO is not set
# CONFIG_ROOT_NFS is not set
CONFIG_NFSD=m
CONFIG_NFSD_V3=y
# CONFIG_NFSD_TCP is not set
CONFIG_SUNRPC=m
CONFIG_LOCKD=m
CONFIG_LOCKD_V4=y
CONFIG_SMB_FS=m
# CONFIG_SMB_NLS_DEFAULT is not set
# CONFIG_NCP_FS is not set
# CONFIG_NCPFS_PACKET_SIGNING is not set
# CONFIG_NCPFS_IOCTL_LOCKING is not set
# CONFIG_NCPFS_STRONG is not set
# CONFIG_NCPFS_NFS_NS is not set
# CONFIG_NCPFS_OS2_NS is not set
# CONFIG_NCPFS_SMALLDOS is not set
# CONFIG_NCPFS_NLS is not set
# CONFIG_NCPFS_EXTRAS is not set
# CONFIG_ZISOFS_FS is not set

#
# Partition Types
#
CONFIG_PARTITION_ADVANCED=y
# CONFIG_ACORN_PARTITION is not set
# CONFIG_OSF_PARTITION is not set
# CONFIG_AMIGA_PARTITION is not set
# CONFIG_ATARI_PARTITION is not set
# CONFIG_MAC_PARTITION is not set
CONFIG_MSDOS_PARTITION=y
# CONFIG_BSD_DISKLABEL is not set
# CONFIG_MINIX_SUBPARTITION is not set
# CONFIG_SOLARIS_X86_PARTITION is not set
# CONFIG_UNIXWARE_DISKLABEL is not set
# CONFIG_LDM_PARTITION is not set
CONFIG_SGI_PARTITION=y
# CONFIG_ULTRIX_PARTITION is not set
# CONFIG_SUN_PARTITION is not set
# CONFIG_EFI_PARTITION is not set
CONFIG_SMB_NLS=y
CONFIG_NLS=y

#
# Native Language Support
#
CONFIG_NLS_DEFAULT="iso8859-1"
CONFIG_NLS_CODEPAGE_437=m
# CONFIG_NLS_CODEPAGE_737 is not set
# CONFIG_NLS_CODEPAGE_775 is not set
CONFIG_NLS_CODEPAGE_850=m
CONFIG_NLS_CODEPAGE_852=m
# CONFIG_NLS_CODEPAGE_855 is not set
# CONFIG_NLS_CODEPAGE_857 is not set
# CONFIG_NLS_CODEPAGE_860 is not set
# CONFIG_NLS_CODEPAGE_861 is not set
# CONFIG_NLS_CODEPAGE_862 is not set
# CONFIG_NLS_CODEPAGE_863 is not set
# CONFIG_NLS_CODEPAGE_864 is not set
# CONFIG_NLS_CODEPAGE_865 is not set
# CONFIG_NLS_CODEPAGE_866 is not set
# CONFIG_NLS_CODEPAGE_869 is not set
# CONFIG_NLS_CODEPAGE_936 is not set
# CONFIG_NLS_CODEPAGE_950 is not set
# CONFIG_NLS_CODEPAGE_932 is not set
# CONFIG_NLS_CODEPAGE_949 is not set
# CONFIG_NLS_CODEPAGE_874 is not set
# CONFIG_NLS_ISO8859_8 is not set
CONFIG_NLS_CODEPAGE_1250=m
CONFIG_NLS_CODEPAGE_1251=m
CONFIG_NLS_ISO8859_1=m
CONFIG_NLS_ISO8859_2=m
# CONFIG_NLS_ISO8859_3 is not set
# CONFIG_NLS_ISO8859_4 is not set
# CONFIG_NLS_ISO8859_5 is not set
# CONFIG_NLS_ISO8859_6 is not set
# CONFIG_NLS_ISO8859_7 is not set
# CONFIG_NLS_ISO8859_9 is not set
# CONFIG_NLS_ISO8859_13 is not set
# CONFIG_NLS_ISO8859_14 is not set
CONFIG_NLS_ISO8859_15=m
# CONFIG_NLS_KOI8_R is not set
# CONFIG_NLS_KOI8_U is not set
CONFIG_NLS_UTF8=m

#
# Multimedia devices
#
CONFIG_VIDEO_DEV=m

#
# Video For Linux
#
CONFIG_VIDEO_PROC_FS=y
# CONFIG_I2C_PARPORT is not set
# CONFIG_VIDEO_BT848 is not set
# CONFIG_VIDEO_PMS is not set
# CONFIG_VIDEO_BWQCAM is not set
# CONFIG_VIDEO_CQCAM is not set
# CONFIG_VIDEO_CPIA is not set
# CONFIG_VIDEO_SAA5249 is not set
# CONFIG_TUNER_3036 is not set
CONFIG_VIDEO_VINO=m
# CONFIG_VIDEO_STRADIS is not set
# CONFIG_VIDEO_ZORAN is not set
# CONFIG_VIDEO_ZORAN_BUZ is not set
# CONFIG_VIDEO_ZORAN_DC10 is not set
# CONFIG_VIDEO_ZORAN_LML33 is not set
# CONFIG_VIDEO_ZR36120 is not set
# CONFIG_VIDEO_MEYE is not set

#
# Radio Adapters
#
# CONFIG_RADIO_GEMTEK_PCI is not set
# CONFIG_RADIO_MAXIRADIO is not set
# CONFIG_RADIO_MAESTRO is not set
# CONFIG_RADIO_MIROPCM20 is not set

#
# Console drivers
#
# CONFIG_VGA_CONSOLE is not set
CONFIG_SGI_NEWPORT_CONSOLE=y
CONFIG_FONT_8x16=y
CONFIG_DUMMY_CONSOLE=y
# CONFIG_MDA_CONSOLE is not set

#
# Frame-buffer support
#
# CONFIG_FB is not set

#
# Sound
#
CONFIG_SOUND=m
# CONFIG_SOUND_ALI5455 is not set
# CONFIG_SOUND_BT878 is not set
# CONFIG_SOUND_CMPCI is not set
# CONFIG_SOUND_EMU10K1 is not set
# CONFIG_MIDI_EMU10K1 is not set
# CONFIG_SOUND_FUSION is not set
# CONFIG_SOUND_CS4281 is not set
# CONFIG_SOUND_ES1370 is not set
# CONFIG_SOUND_ES1371 is not set
# CONFIG_SOUND_ESSSOLO1 is not set
# CONFIG_SOUND_MAESTRO is not set
# CONFIG_SOUND_MAESTRO3 is not set
# CONFIG_SOUND_FORTE is not set
# CONFIG_SOUND_ICH is not set
# CONFIG_SOUND_RME96XX is not set
# CONFIG_SOUND_SONICVIBES is not set
CONFIG_SOUND_HAL2=m
# CONFIG_SOUND_TRIDENT is not set
# CONFIG_SOUND_MSNDCLAS is not set
# CONFIG_SOUND_MSNDPIN is not set
# CONFIG_SOUND_VIA82CXXX is not set
# CONFIG_MIDI_VIA82CXXX is not set
# CONFIG_SOUND_OSS is not set
# CONFIG_SOUND_TVMIXER is not set
# CONFIG_SOUND_AD1980 is not set
# CONFIG_SOUND_WM97XX is not set

#
# USB support
#
# CONFIG_USB is not set

#
# Support for USB gadgets
#
# CONFIG_USB_GADGET is not set

#
# Bluetooth support
#
# CONFIG_BLUEZ is not set

#
# Kernel hacking
#
# CONFIG_CROSSCOMPILE is not set
# CONFIG_RUNTIME_DEBUG is not set
# CONFIG_KGDB is not set
# CONFIG_GDB_CONSOLE is not set
# CONFIG_DEBUG_INFO is not set
CONFIG_MAGIC_SYSRQ=y
# CONFIG_MIPS_UNCACHED is not set
CONFIG_LOG_BUF_SHIFT=0

#
# Cryptographic options
#
# CONFIG_CRYPTO is not set

#
# Library routines
#
CONFIG_CRC32=m
CONFIG_ZLIB_INFLATE=m
CONFIG_ZLIB_DEFLATE=m

--0OAP2g/MAC+5xKAE--

From rathann@icm.edu.pl Thu Jan 15 14:20:54 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 15 Jan 2004 14:20:55 +0000 (GMT)
Received: from gw.icm.edu.pl ([IPv6:::ffff:212.87.0.39]:18787 "EHLO
	atol.icm.edu.pl") by linux-mips.org with ESMTP id <S8224850AbUAOOUy>;
	Thu, 15 Jan 2004 14:20:54 +0000
Received: from rekin.icm.edu.pl (rekin.icm.edu.pl [192.168.1.132])
	by atol.icm.edu.pl (8.12.6/8.12.6/rzm-4.6/icm) with ESMTP id i0FEKg4p019298
	for <linux-mips@linux-mips.org>; Thu, 15 Jan 2004 15:20:43 +0100 (CET)
Received: from rathann by rekin.icm.edu.pl with local (Exim 3.35 #1 (Debian))
	id 1Ah8MU-0008C9-00
	for <linux-mips@linux-mips.org>; Thu, 15 Jan 2004 15:20:42 +0100
Date: Thu, 15 Jan 2004 15:20:41 +0100
From: "Dominik 'Rathann' Mierzejewski" <rathann@icm.edu.pl>
To: linux-mips@linux-mips.org
Subject: Re: Current 2.4 CVS (2.4.24-pre2) doesn't boot on SGI Indy
Message-ID: <20040115142041.GA31453@icm.edu.pl>
Mail-Followup-To: linux-mips@linux-mips.org
References: <20040115141427.GA28546@icm.edu.pl>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="/9DWx/yDrRhgMJTb"
Content-Disposition: inline
In-Reply-To: <20040115141427.GA28546@icm.edu.pl>
User-Agent: Mutt/1.3.28i
Return-Path: <rathann@icm.edu.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: 3974
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: rathann@icm.edu.pl
Precedence: bulk
X-list: linux-mips


--/9DWx/yDrRhgMJTb
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

Sorry for messing up the thread.
Additional info: dmesg log from successful 2.4.22 boot, attached.

-- 
Dominik 'Rathann' Mierzejewski <rathann@icm.edu.pl>                                                 
Interdisciplinary Centre for Mathematical and Computational Modelling                               
Warsaw University  |  http://www.icm.edu.pl  |  tel. +48 (22) 5540810                               

--/9DWx/yDrRhgMJTb
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename=dmesg

ARCH: SGI-IP22
PROMLIB: ARC firmware Version 1 Revision 10
CPU revision is: 00002020
FPU revision is: 00002020
Primary instruction cache 16kB, physically tagged, 2-way, linesize 32 bytes.
Primary data cache 16kB 2-way, linesize 32 bytes.
Linux version 2.4.22 (dominik@indy0) (gcc version 3.3.1 20030626 (Debian prerelease)) #1 Thu Sep 25 15:11:35 CEST 2003
MC: SGI memory controller Revision 3
MC: Probing memory configuration:
 bank0:  32M @ 08000000
 bank1:  32M @ 0a000000
Determined physical RAM map:
 memory: 04000000 @ 08000000 (usable)
On node 0 totalpages: 49152
zone(0): 49152 pages.
zone(1): 0 pages.
zone(2): 0 pages.
Kernel command line: root=/dev/sda1 auto
Calibrating system timer... 665000 [133.0000 MHz CPU]
Using 66.500 MHz high precision timer.
NG1: Revision 6, 8 bitplanes, REX3 revision B, VC2 revision A, xmap9 revision A, cmap revision D, bt445 revision D
NG1: Screensize 1280x1024
Console: colour SGI Newport 160x64
Calibrating delay loop... 132.71 BogoMIPS
Memory: 61712k/65536k available (1328k kernel code, 3824k reserved, 100k data, 72k init, 0k highmem)
Dentry cache hash table entries: 32768 (order: 6, 262144 bytes)
Inode cache hash table entries: 16384 (order: 5, 131072 bytes)
Mount cache hash table entries: 512 (order: 0, 4096 bytes)
Buffer cache hash table entries: 16384 (order: 4, 65536 bytes)
Page-cache hash table entries: 65536 (order: 6, 262144 bytes)
Checking for 'wait' instruction...  available.
POSIX conformance testing by UNIFIX
Linux NET4.0 for Linux 2.4
Based upon Swansea University Computer Society NET3.039
Initializing RT netlink socket
Starting kswapd
VFS: Disk quotas vdquot_6.5.1
Journalled Block Device driver loaded
pty: 256 Unix98 ptys configured
DS1286 Real Time Clock Driver v1.0
SCSI subsystem driver Revision: 1.00
wd33c93-0: chip=WD33c93B/13 no_sync=0xff no_dma=0 debug_flags=0x00
           setup_args=,,,,,,,,,
           Version 1.25 - 09/Jul/1997, Compiled Sep 25 2003 at 15:38:35
scsi0 : SGI WD93
 sending SDTR 010301410csync_xfer=3c  Vendor: SAMSUNG   Model: WN34324U (gm031)  Rev: 0105
  Type:   Direct-Access                      ANSI SCSI revision: 02
Attached scsi disk sda at scsi0, channel 0, id 1, lun 0
SCSI device sda: 8438976 512-byte hdwr sectors (4321 MB)
Partition check:
 sda: sda1 sda2 sda3 sda4
NET4: Linux TCP/IP 1.0 for NET4.0
IP Protocols: ICMP, UDP, TCP, IGMP
IP: routing cache hash table of 2048 buckets, 16Kbytes
TCP: Hash tables configured (established 16384 bind 32768)
kjournald starting.  Commit interval 5 seconds
EXT3-fs: mounted filesystem with ordered data mode.
VFS: Mounted root (ext3 filesystem) readonly.
Freeing unused kernel memory: 72k freed
NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
Adding Swap: 524276k swap-space (priority -1)
EXT3 FS 2.4-0.9.19, 19 August 2002 on sd(8,1), internal journal

--/9DWx/yDrRhgMJTb--

From martyausmainz@gmx.de Thu Jan 15 17:22:15 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 15 Jan 2004 17:22:16 +0000 (GMT)
Received: from pop.gmx.net ([IPv6:::ffff:213.165.64.20]:16576 "HELO
	mail.gmx.net") by linux-mips.org with SMTP id <S8225366AbUAORWP>;
	Thu, 15 Jan 2004 17:22:15 +0000
Received: (qmail 3654 invoked by uid 65534); 15 Jan 2004 17:22:09 -0000
Received: from p62.246.39.146.tisdip.tiscali.de (EHLO localhost) (62.246.39.146)
  by mail.gmx.net (mp021) with SMTP; 15 Jan 2004 18:22:09 +0100
X-Authenticated: #6306349
Received: by localhost (Postfix, from userid 1002)
	id 1D3132A98D; Thu, 15 Jan 2004 18:19:36 +0100 (CET)
Received: from localhost (localhost [127.0.0.1])
	by localhost (Postfix) with ESMTP
	id EFA742A98C; Thu, 15 Jan 2004 18:19:36 +0100 (CET)
Date: Thu, 15 Jan 2004 18:19:36 +0100 (CET)
From: Martin Boehme <martyausmainz@gmx.de>
X-Sender: martyausmainz@www.marty44.net
To: Dominik 'Rathann' Mierzejewski <rathann@icm.edu.pl>
Cc: linux-mips@linux-mips.org
Subject: Re: Current 2.4 CVS (2.4.24-pre2) doesn't boot on SGI Indy
In-Reply-To: <20040115141427.GA28546@icm.edu.pl>
Message-ID: <Pine.LNX.4.21.0401151816540.3511-100000@www.marty44.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <martyausmainz@gmx.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: 3975
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: martyausmainz@gmx.de
Precedence: bulk
X-list: linux-mips

Hello,

is your indy a R4k?
If so, I had the same problems. On R5k it works.
There was some talking and some updates of R4k last two weeks. Look in the archives.
Well, let's wait for the next commit to the offical kernel tree.

marty


On Thu, 15 Jan 2004, Dominik 'Rathann' Mierzejewski wrote:
> I've just compiled it and it won't boot properly. It hangs at
> ...
> Freeing unused kernel memory (72k)


From jsun@mvista.com Thu Jan 15 18:03:38 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 15 Jan 2004 18:03:39 +0000 (GMT)
Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:17658 "EHLO
	orion.mvista.com") by linux-mips.org with ESMTP id <S8225464AbUAOSDi>;
	Thu, 15 Jan 2004 18:03:38 +0000
Received: (from jsun@localhost)
	by orion.mvista.com (8.11.6/8.11.6) id i0FI3Uo18508;
	Thu, 15 Jan 2004 10:03:30 -0800
Date: Thu, 15 Jan 2004 10:03:30 -0800
From: Jun Sun <jsun@mvista.com>
To: "David S. Miller" <davem@redhat.com>
Cc: linux-mips@linux-mips.org, jsun@mvista.com
Subject: Re: [BUG] 2.6.1/MIPS - missing cache flushing when user program returns pages to kernel
Message-ID: <20040115100330.C18368@mvista.com>
References: <20040114163920.E13471@mvista.com> <20040114171252.4d873c51.akpm@osdl.org> <20040114172946.03e54706.akpm@osdl.org> <20040114174012.H13471@mvista.com> <20040114222316.25276f12.davem@redhat.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="HlL+5n6rz5pIUxbD"
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <20040114222316.25276f12.davem@redhat.com>; from davem@redhat.com on Wed, Jan 14, 2004 at 10:23:16PM -0800
Return-Path: <jsun@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: 3976
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


--HlL+5n6rz5pIUxbD
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline


Looks the right fix is to add cache flush to tlb_start_vma().
See the patch attached.  Unless someone objects, I will check it
later.

BTW, I really don't like the function naming of tlb_start_vma()
and tbl_end_vma(). :)

Jun

On Wed, Jan 14, 2004 at 10:23:16PM -0800, David S. Miller wrote:
> On Wed, 14 Jan 2004 17:40:12 -0800
> Jun Sun <jsun@mvista.com> wrote:
> 
> > Looking at my tree (which is from linux-mips.org), it appears
> > arm, sparc, sparc64, and sh have tlb_start_vma() defined to call
> > cache flushing.
> 
> Correct, in fact every platform where cache flushing matters
> at all (ie. where flush_cache_*() routines actually need to
> flush a cpu cache), they should have tlb_start_vma() do such
> a flush.
> 
> > What exactly does tlb_start_vma()/tlb_end_vma() mean?  There is
> > only one invocation instance, which is significant enough to infer
> > the meaning.  :)
> 
> When the kernel unmaps a mmap region of a process (either for the
> sake of munmap() or tearing down all mapping during exit()) tlb_start_vma()
> is called, the page table mappings in the region are torn down one by
> one, then a tlb_end_vma() call is made.
> 
> At the top level, ie. whoever invokes unmap_page_range(), there will
> be a tlb_gather_mmu() call.
> 
> In order to properly optimize the cache flushes, most platforms do the
> following:
> 
> 1) The tlb->fullmm boolean keeps trap of whether this is just a munmap()
>    unmapping operation (if zero) or a full address space teardown
>    (if non-zero).
> 
> 2) In the full address space teardown case, and thus tlb->fullmm is
>    non-zero, the top level will do the explict flush_cache_mm()
>    (see mm/mmap.c:exit_mmap()), therefore the tlb_start_vma()
>    implementation need not do the flush, otherwise it does.
> 
>    This is why sparc64 and friends implement it like this:
> 
> #define tlb_start_vma(tlb, vma) \
> do {    if (!(tlb)->fullmm)     \
>                 flush_cache_range(vma, vma->vm_start, vma->vm_end); \
> } while (0)
> 
> Hope this clears things up.
> 
> Someone should probably take what I just wrote, expand and organize it,
> then add such content to Documentation/cachetlb.txt
> 

--HlL+5n6rz5pIUxbD
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="real-fix.patch"

diff -Nru linux/include/asm-mips/tlb.h.orig linux/include/asm-mips/tlb.h
--- linux/include/asm-mips/tlb.h.orig	Thu Oct 31 08:35:52 2002
+++ linux/include/asm-mips/tlb.h	Thu Jan 15 10:02:14 2004
@@ -2,9 +2,14 @@
 #define __ASM_TLB_H
 
 /*
- * MIPS doesn't need any special per-pte or per-vma handling..
+ * MIPS doesn't need any special per-pte or per-vma handling, except
+ * we need to flush cache for area to be unmapped.
  */
-#define tlb_start_vma(tlb, vma) do { } while (0)
+#define tlb_start_vma(tlb, vma) 				\
+	do {							\
+		if (!tlb->fullmm)				\
+			flush_cache_range(vma, vma->vm_start, vma->vm_end); \
+	}  while (0)
 #define tlb_end_vma(tlb, vma) do { } while (0)
 #define __tlb_remove_tlb_entry(tlb, ptep, address) do { } while (0)
 

--HlL+5n6rz5pIUxbD--

From charlieb-linux-mips@e-smith.com Thu Jan 15 18:53:27 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 15 Jan 2004 18:53:28 +0000 (GMT)
Received: from mail.e-smith.com ([IPv6:::ffff:216.191.234.126]:41746 "HELO
	nssg.mitel.com") by linux-mips.org with SMTP id <S8224992AbUAOSx1>;
	Thu, 15 Jan 2004 18:53:27 +0000
Received: (qmail 19409 invoked by uid 404); 15 Jan 2004 18:53:18 -0000
Received: from charlieb-linux-mips@e-smith.com by tripe.nssg.mitel.com with qmail-scanner; 15 Jan 2004 13:53:18 -0000
Received: from allspice-core.nssg.mitel.com (HELO e-smith.com) (10.33.16.12)
  by tripe.nssg.mitel.com (10.33.17.11) with SMTP; 15 Jan 2004 18:53:18 -0000
Received: (qmail 4499 invoked by uid 5008); 15 Jan 2004 18:53:18 -0000
Received: from localhost (sendmail-bs@127.0.0.1)
  by localhost with SMTP; 15 Jan 2004 18:53:18 -0000
Date: Thu, 15 Jan 2004 13:53:18 -0500 (EST)
From: Charlie Brady <charlieb-linux-mips@e-smith.com>
X-X-Sender: charlieb@allspice.nssg.mitel.com
To: linux-mips@linux-mips.org
Subject: Re: Broadcom 4702?
In-Reply-To: <Pine.LNX.4.44.0401131655350.20844-100000@allspice.nssg.mitel.com>
Message-ID: <Pine.LNX.4.44.0401151343460.17500-100000@allspice.nssg.mitel.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <charlieb-linux-mips@e-smith.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: 3977
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: charlieb-linux-mips@e-smith.com
Precedence: bulk
X-list: linux-mips


On Tue, 13 Jan 2004, Charlie Brady wrote:

> I haven't found signs of it in the archives, but is anyone aware of any 
> efforts to fold in Broadcom's support for their 4702 processor, as used in 
> Wireless gateways such as the Linksys WRT54G?

FWIW, there was some mention of this on lkml.

http://testing.lkml.org/slashdot.php?mid=313689

Looks like it may have quickly been put in the "Too Hard" basket. The 
bulk of the 15Mb patch, however, is not a port per se, but addition of 
kdbg and XFS, so there won't be anywhere near that much real work.

Here's an important one, however, which I alluded to yesterday:

+ifdef CONFIG_BCM4710
+GCCFLAGS       += -m4710a0kern
 endif

I haven't tried building and running a kernel built without the gcc 
workarounds, so I don't know whether they are only required for early 
silicon. My guess would be not. Is there anyone from Broadcom here who 
knows or can find out?

--
Charlie


From kph@cisco.com Thu Jan 15 19:01:10 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 15 Jan 2004 19:01:10 +0000 (GMT)
Received: from adsl-66-123-66-42.dsl.pltn13.pacbell.net ([IPv6:::ffff:66.123.66.42]:7821
	"EHLO stella-blue.herbertphamily.com") by linux-mips.org with ESMTP
	id <S8225467AbUAOTBK>; Thu, 15 Jan 2004 19:01:10 +0000
Received: from [192.168.1.8] (shakedown.herbertphamily.com [192.168.1.8])
	(authenticated bits=0)
	by stella-blue.herbertphamily.com (8.12.8/8.12.8) with ESMTP id i0FJ150M008130
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for <linux-mips@linux-mips.org>; Thu, 15 Jan 2004 11:01:06 -0800
Subject: [Patch] SB1 cache exception handler fails to compile
	[arch/mips/mm/cex-sb1.S]
From: Kevin Paul Herbert <kph@cisco.com>
To: linux-mips@linux-mips.org
Content-Type: text/plain
Organization: cisco Systems, Inc.
Message-Id: <1074193246.24675.19.camel@shakedown>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.2.2 (1.2.2-5) 
Date: 15 Jan 2004 11:00:58 -0800
Content-Transfer-Encoding: 7bit
Return-Path: <kph@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: 3978
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: kph@cisco.com
Precedence: bulk
X-list: linux-mips

The recent update to arch/mips/mm/cex-sb1.S (1.13) adds an include for
<asm/processor.h> unnecessarily. This include file defines C structs and
the like which the assembler chokes upon.

Kevin
-- 
Kevin Paul Herbert <kph@cisco.com>
cisco Systems, Inc.


Index: arch/mips/mm/cex-sb1.S
===================================================================
RCS file: /home/cvs/linux/arch/mips/mm/cex-sb1.S,v
retrieving revision 1.13
diff -u -r1.13 cex-sb1.S
--- arch/mips/mm/cex-sb1.S	14 Jan 2004 18:46:21 -0000	1.13
+++ arch/mips/mm/cex-sb1.S	15 Jan 2004 18:55:28 -0000
@@ -23,7 +23,6 @@
 #include <asm/mipsregs.h>
 #include <asm/stackframe.h>
 #include <asm/cacheops.h>
-#include <asm/processor.h>
 #include <asm/sibyte/board.h>
 
 #define C0_ERRCTL     $26             /* CP0: Error info */




From kph@cisco.com Thu Jan 15 19:08:27 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 15 Jan 2004 19:08:27 +0000 (GMT)
Received: from adsl-66-123-66-42.dsl.pltn13.pacbell.net ([IPv6:::ffff:66.123.66.42]:8077
	"EHLO stella-blue.herbertphamily.com") by linux-mips.org with ESMTP
	id <S8225467AbUAOTI1>; Thu, 15 Jan 2004 19:08:27 +0000
Received: from [192.168.1.8] (shakedown.herbertphamily.com [192.168.1.8])
	(authenticated bits=0)
	by stella-blue.herbertphamily.com (8.12.8/8.12.8) with ESMTP id i0FJ8N0M008154
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for <linux-mips@linux-mips.org>; Thu, 15 Jan 2004 11:08:25 -0800
Subject: [PATCH][2.6]Fix compiler warnings on long long constants in SB1250
	build
From: Kevin Paul Herbert <kph@cisco.com>
To: linux-mips@linux-mips.org
Content-Type: text/plain
Organization: cisco Systems, Inc.
Message-Id: <1074193693.24675.22.camel@shakedown>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.2.2 (1.2.2-5) 
Date: 15 Jan 2004 11:08:16 -0800
Content-Transfer-Encoding: 7bit
Return-Path: <kph@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: 3979
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: kph@cisco.com
Precedence: bulk
X-list: linux-mips

The following patch corrects warnings in arch/mips/mm/cerr-sb1.c and
arch/mips/sibyte/sb1250/irq.c for "long long" constants.

Kevin
-- 
Kevin Paul Herbert <kph@cisco.com>
cisco Systems, Inc.

Index: arch/mips/mm/cerr-sb1.c
===================================================================
RCS file: /home/cvs/linux/arch/mips/mm/cerr-sb1.c,v
retrieving revision 1.11
diff -u -r1.11 cerr-sb1.c
--- arch/mips/mm/cerr-sb1.c	18 Nov 2003 01:17:46 -0000	1.11
+++ arch/mips/mm/cerr-sb1.c	15 Jan 2004 19:05:31 -0000
@@ -251,14 +251,14 @@
 
 /* Masks to select bits for Hamming parity, mask_72_64[i] for bit[i] */
 static const uint64_t mask_72_64[8] = {
-	0x0738C808099264FFL,
-	0x38C808099264FF07L,
-	0xC808099264FF0738L,
-	0x08099264FF0738C8L,
-	0x099264FF0738C808L,
-	0x9264FF0738C80809L,
-	0x64FF0738C8080992L,
-	0xFF0738C808099264L
+	0x0738C808099264FFLL,
+	0x38C808099264FF07LL,
+	0xC808099264FF0738LL,
+	0x08099264FF0738C8LL,
+	0x099264FF0738C808LL,
+	0x9264FF0738C80809LL,
+	0x64FF0738C8080992LL,
+	0xFF0738C808099264LL
 };
 
 /* Calculate the parity on a range of bits */
@@ -330,9 +330,9 @@
 				    ((lru >> 4) & 0x3),
 				    ((lru >> 6) & 0x3));
 		}
-		va = (taglo & 0xC0000FFFFFFFE000) | addr;
+		va = (taglo & 0xC0000FFFFFFFE000LL) | addr;
 		if ((taglo & (1 << 31)) && (((taglo >> 62) & 0x3) == 3))
-			va |= 0x3FFFF00000000000;
+			va |= 0x3FFFF00000000000LL;
 		valid = ((taghi >> 29) & 1);
 		if (valid) {
 			tlo_tmp = taglo & 0xfff3ff;
@@ -473,7 +473,7 @@
 		: "r" ((way << 13) | addr));
 
 		taglo = ((unsigned long long)taglohi << 32) | taglolo;
-		pa = (taglo & 0xFFFFFFE000) | addr;
+		pa = (taglo & 0xFFFFFFE000LL) | addr;
 		if (way == 0) {
 			lru = (taghi >> 14) & 0xff;
 			prom_printf("[Bank %d Set 0x%02x]  LRU > %d %d %d %d > MRU\n",
Index: arch/mips/sibyte/sb1250/irq.c
===================================================================
RCS file: /home/cvs/linux/arch/mips/sibyte/sb1250/irq.c,v
retrieving revision 1.26
diff -u -r1.26 irq.c
--- arch/mips/sibyte/sb1250/irq.c	10 Nov 2003 17:51:49 -0000	1.26
+++ arch/mips/sibyte/sb1250/irq.c	15 Jan 2004 19:05:32 -0000
@@ -365,9 +365,9 @@
 					 (K_INT_MBOX_0 << 3)));
 
 	/* Clear the mailboxes.  The firmware may leave them dirty */
-	__raw_writeq(0xffffffffffffffff,
+	__raw_writeq(0xffffffffffffffffLL,
 		     IOADDR(A_IMR_REGISTER(0, R_IMR_MAILBOX_CLR_CPU)));
-	__raw_writeq(0xffffffffffffffff,
+	__raw_writeq(0xffffffffffffffffLL,
 		     IOADDR(A_IMR_REGISTER(1, R_IMR_MAILBOX_CLR_CPU)));
 
 	/* Mask everything except the mailbox registers for both cpus */




From linville@lvl7.com Thu Jan 15 19:14:17 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 15 Jan 2004 19:14:18 +0000 (GMT)
Received: from mail.lvl7.com ([IPv6:::ffff:66.21.69.202]:41645 "EHLO
	lvl7ser4.lvl7.com") by linux-mips.org with ESMTP
	id <S8225470AbUAOTOR>; Thu, 15 Jan 2004 19:14:17 +0000
Received: from savage.dyndns.pengo.lvl7.com (grantc-cd310vm [192.168.77.181]) by lvl7ser4.lvl7.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55)
	id C7DFXPDC; Thu, 15 Jan 2004 14:17:25 -0500
Received: from lvl7.com (localhost.localdomain [127.0.0.1])
	by savage.dyndns.pengo.lvl7.com (8.11.6/8.11.6) with ESMTP id i0FJE9X17410;
	Thu, 15 Jan 2004 14:14:10 -0500
Message-ID: <4006E67F.7010906@lvl7.com>
Date: Thu, 15 Jan 2004 14:14:07 -0500
From: "John W. Linville" <linville@lvl7.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3.1) Gecko/20030425
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Charlie Brady <charlieb-linux-mips@e-smith.com>
CC: linux-mips@linux-mips.org
Subject: Re: Broadcom 4702?
References: <Pine.LNX.4.44.0401151343460.17500-100000@allspice.nssg.mitel.com>
In-Reply-To: <Pine.LNX.4.44.0401151343460.17500-100000@allspice.nssg.mitel.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Return-Path: <linville@lvl7.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: 3980
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: linville@lvl7.com
Precedence: bulk
X-list: linux-mips

Charlie Brady wrote:

>+ifdef CONFIG_BCM4710
>+GCCFLAGS       += -m4710a0kern
> endif
>
>I haven't tried building and running a kernel built without the gcc 
>workarounds, so I don't know whether they are only required for early 
>  
>
I don't know about the 4710 or 4702 (I haven't got around to that yet), 
but the 4704 doesn't seem to need any special flags for building the 
kernel (or anything else).

Of course, YMMV...

John

-- 
John W. Linville
LVL7 Systems, Inc.



From jsun@mvista.com Thu Jan 15 19:22:03 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 15 Jan 2004 19:22:04 +0000 (GMT)
Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:1533 "EHLO
	orion.mvista.com") by linux-mips.org with ESMTP id <S8225470AbUAOTWD>;
	Thu, 15 Jan 2004 19:22:03 +0000
Received: (from jsun@localhost)
	by orion.mvista.com (8.11.6/8.11.6) id i0FJM1C21272;
	Thu, 15 Jan 2004 11:22:01 -0800
Date: Thu, 15 Jan 2004 11:22:01 -0800
From: Jun Sun <jsun@mvista.com>
To: linux-mips@linux-mips.org
Cc: jsun@mvista.com
Subject: [PATCH 2.6] DEBUG_INFO, KGDB and etc...
Message-ID: <20040115112201.E18368@mvista.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="cmJC7u66zC7hs+87"
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
Return-Path: <jsun@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: 3981
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


--cmJC7u66zC7hs+87
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline


This patch adds the missing "-g" gcc option when kgdb is configure.
Clean up some debugging related options (DEBUG_INFO really should
go under KGDB and depends its not being selected)

If no objection, will check it in later.

And yes, the good news is that kgdb works in 2.6.

Jun

--cmJC7u66zC7hs+87
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename=junk1

diff -Nru link/arch/mips/Makefile.orig link/arch/mips/Makefile
--- link/arch/mips/Makefile.orig	Thu Jan 15 10:55:57 2004
+++ link/arch/mips/Makefile	Thu Jan 15 10:59:19 2004
@@ -60,6 +60,7 @@
 LDFLAGS_vmlinux			+= -G 0 -static # -N
 MODFLAGS			+= -mlong-calls
 
+cflags-$(CONFIG_DEBUG_INFO)     += -g
 cflags-$(CONFIG_SB1XXX_CORELIS)	+= -mno-sched-prolog -fno-omit-frame-pointer
 
 check_warning = $(shell if $(CC) $(1) -c -o /dev/null -xc /dev/null > /dev/null 2>&1; then echo "$(1)"; else echo "$(2)"; fi)
diff -Nru link/arch/mips/Kconfig.orig link/arch/mips/Kconfig
--- link/arch/mips/Kconfig.orig	Thu Jan 15 10:55:57 2004
+++ link/arch/mips/Kconfig	Thu Jan 15 11:12:23 2004
@@ -1233,23 +1233,6 @@
 	  This allows applications to run more reliably even when the system is
 	  under load.
 
-config DEBUG_INFO
-	bool "Compile the kernel with debug info"
-	depends on DEBUG_KERNEL
-	default y if KGDB
-	help
-	  If you say Y here the resulting kernel image will include
-	  debugging info resulting in a larger kernel image.
-	  Say Y here only if you plan to use gdb to debug the kernel.
-	  If you don't debug the kernel, you can say N.
-
-config SB1XXX_CORELIS
-	bool "Corelis Debugger"
-	depends on SIBYTE_SB1xxx_SOC && DEBUG_INFO
-	help
-	  Select compile flags that produce code that can be processed by the
-	  Corelis mksym utility and UDB Emulator.
-
 config DEBUG_SPINLOCK
 	bool "Spinlock debugging"
 	depends on DEBUG_KERNEL
@@ -1471,6 +1454,7 @@
 config KGDB
 	bool "Remote GDB kernel debugging"
 	depends on DEBUG_KERNEL
+	select DEBUG_INFO
 	help
 	  If you say Y here, it will be possible to remotely debug the MIPS
 	  kernel using gdb. This enlarges your kernel image disk size by
@@ -1486,6 +1470,23 @@
 	  would like kernel messages to be formatted into GDB $O packets so
 	  that GDB prints them as program output, say 'Y'.
 
+config DEBUG_INFO
+	bool "Compile the kernel with debug info"
+	depends on DEBUG_KERNEL && !KGDB
+	default y if KGDB
+	help
+	  If you say Y here the resulting kernel image will include
+	  debugging info resulting in a larger kernel image.
+	  Say Y here only if you plan to use gdb to debug the kernel.
+	  If you don't debug the kernel, you can say N.
+
+config SB1XXX_CORELIS
+	bool "Corelis Debugger"
+	depends on SIBYTE_SB1xxx_SOC && DEBUG_INFO
+	help
+	  Select compile flags that produce code that can be processed by the
+	  Corelis mksym utility and UDB Emulator.
+
 config RUNTIME_DEBUG
 	bool "Enable run-time debugging"
 	depends on DEBUG_KERNEL

--cmJC7u66zC7hs+87--

From kph@cisco.com Thu Jan 15 19:57:45 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 15 Jan 2004 19:57:50 +0000 (GMT)
Received: from adsl-66-123-66-42.dsl.pltn13.pacbell.net ([IPv6:::ffff:66.123.66.42]:13709
	"EHLO stella-blue.herbertphamily.com") by linux-mips.org with ESMTP
	id <S8225470AbUAOT5p>; Thu, 15 Jan 2004 19:57:45 +0000
Received: from [192.168.1.8] (shakedown.herbertphamily.com [192.168.1.8])
	(authenticated bits=0)
	by stella-blue.herbertphamily.com (8.12.8/8.12.8) with ESMTP id i0FJvg0M008394
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 15 Jan 2004 11:57:43 -0800
Subject: Re: [PATCH 2.6] DEBUG_INFO, KGDB and etc...
From: Kevin Paul Herbert <kph@cisco.com>
To: Jun Sun <jsun@mvista.com>
Cc: linux-mips@linux-mips.org
In-Reply-To: <20040115112201.E18368@mvista.com>
References: <20040115112201.E18368@mvista.com>
Content-Type: text/plain
Organization: cisco Systems, Inc.
Message-Id: <1074196652.24675.28.camel@shakedown>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.2.2 (1.2.2-5) 
Date: 15 Jan 2004 11:57:35 -0800
Content-Transfer-Encoding: 7bit
Return-Path: <kph@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: 3982
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: kph@cisco.com
Precedence: bulk
X-list: linux-mips

In the top level makefile, there is already:

	ifdef CONFIG_DEBUG_INFO
	CFLAGS		+= -g
	endif

I don't see why you need to add it to arch/mips/Makefile. Your Kconfig
changes seem fine though.

Kevin

On Thu, 2004-01-15 at 11:22, Jun Sun wrote:
> This patch adds the missing "-g" gcc option when kgdb is configure.
> Clean up some debugging related options (DEBUG_INFO really should
> go under KGDB and depends its not being selected)
> 
> If no objection, will check it in later.
> 
> And yes, the good news is that kgdb works in 2.6.
> 
> Jun
-- 
Kevin Paul Herbert <kph@cisco.com>
cisco Systems, Inc.


From charlieb-linux-mips@e-smith.com Thu Jan 15 20:08:37 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 15 Jan 2004 20:08:48 +0000 (GMT)
Received: from mail.e-smith.com ([IPv6:::ffff:216.191.234.126]:32779 "HELO
	nssg.mitel.com") by linux-mips.org with SMTP id <S8225470AbUAOUIh>;
	Thu, 15 Jan 2004 20:08:37 +0000
Received: (qmail 2628 invoked by uid 404); 15 Jan 2004 20:08:31 -0000
Received: from charlieb-linux-mips@e-smith.com by tripe.nssg.mitel.com with qmail-scanner; 15 Jan 2004 15:08:30 -0000
Received: from allspice-core.nssg.mitel.com (HELO e-smith.com) (10.33.16.12)
  by tripe.nssg.mitel.com (10.33.17.11) with SMTP; 15 Jan 2004 20:08:30 -0000
Received: (qmail 20592 invoked by uid 5008); 15 Jan 2004 20:08:30 -0000
Received: from localhost (sendmail-bs@127.0.0.1)
  by localhost with SMTP; 15 Jan 2004 20:08:30 -0000
Date: Thu, 15 Jan 2004 15:08:30 -0500 (EST)
From: Charlie Brady <charlieb-linux-mips@e-smith.com>
X-X-Sender: charlieb@allspice.nssg.mitel.com
To: "John W. Linville" <linville@lvl7.com>
cc: linux-mips@linux-mips.org
Subject: Broadcom gcc changes (was Re: Broadcom 4702?)
In-Reply-To: <4006E67F.7010906@lvl7.com>
Message-ID: <Pine.LNX.4.44.0401151442590.17500-100000@allspice.nssg.mitel.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <charlieb-linux-mips@e-smith.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: 3983
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: charlieb-linux-mips@e-smith.com
Precedence: bulk
X-list: linux-mips


On Thu, 15 Jan 2004, John W. Linville wrote:

> Charlie Brady wrote:
> 
> >+ifdef CONFIG_BCM4710
> >+GCCFLAGS       += -m4710a0kern
> > endif
> >
> >I haven't tried building and running a kernel built without the gcc 
> >workarounds, so I don't know whether they are only required for early 
> >  
> >
> I don't know about the 4710 or 4702 (I haven't got around to that yet), 
> but the 4704 doesn't seem to need any special flags for building the 
> kernel (or anything else).

The acid test is not whether the kernel builds, but whether it runs 
correctly under all circumstances :-)

Here's some of the gcc changes, to give you all a feel for what changes 
they've made.

--- gcc-3.0/gcc/config/mips/mips.h      2001-06-14 16:42:18.000000000 
-0400
+++ WRT54G/tools-src/gnu-20010422/gcc/config/mips/mips.h        2003-10-10 
15:15:14.000000000 -0400
@@ -214,6 +214,7 @@
 #define MASK_UNINIT_CONST_IN_RODATA \
                           0x01000000   /* Store uninitialized
                                           consts in rodata */
+#define MASK_NO4710A0     0x02000000   /* WA_BCM4710A0: Don't work-around 
BCM4710A0 CPU bugs */
                                                                                                                                                             
                                        /* Debug switches, not documented 
*/
 #define MASK_DEBUG     0               /* unused */
@@ -310,6 +311,9 @@
 #define TARGET_NO_CHECK_ZERO_DIV (target_flags & MASK_NO_CHECK_ZERO_DIV)
 #define TARGET_CHECK_RANGE_DIV  (target_flags & MASK_CHECK_RANGE_DIV)
                                                                                                                                                             
+/* WA_BCM4710A0 */
+#define TARGET_4710A0          !(target_flags & MASK_NO4710A0)
+
 /* This is true if we must enable the assembly language file switching
    code.  */
                                                                                                                                                             
@@ -423,6 +427,12 @@
      N_("Work around early 4300 hardware bug")},                       \
   {"no-fix4300",         -MASK_4300_MUL_FIX,                           \
      N_("Don't work around early 4300 hardware bug")},                 \
+  {"4710a0",            -MASK_NO4710A0,                                \
+     N_("Work around BCM4710A0 hardware bugs")},                       \
+  {"no-4710a0",                  MASK_NO4710A0,                                
\
+     N_("Don't work around BCM4710A0 hardware bugs")},                 \
+  {"4710a0kern",         MASK_NO4710A0,                                \
+     N_("Don't work around BCM4710A0 hardware bugs")},                 \
   {"4650",               MASK_MAD | MASK_SINGLE_FLOAT,                 \
      N_("Optimize for 4650")},                                         \
   {"3900",               MASK_MIPS3900,                                \
@@ -590,7 +600,8 @@
                                 )
                                                                                                                                                             
 /* ISA has branch likely instructions (eg. mips2). */
-#define ISA_HAS_BRANCHLIKELY   (mips_isa != 1)
+/* WA_BCM4710A0 */
+#define ISA_HAS_BRANCHLIKELY   (mips_isa != 1 && !TARGET_4710A0)

 /* ISA has the conditional move instructions introduced in mips4. */
 #define ISA_HAS_CONDMOVE        (mips_isa == 4                         \
@@ -784,7 +795,7 @@
 /* GAS_ASM_SPEC is passed when using gas, rather than the MIPS
    assembler.  */
                                                                                                                                                             
-#define GAS_ASM_SPEC "%{mcpu=*} %{m4650} %{mmad:-m4650} %{m3900} %{v} 
%{mgp32} %{mgp64}"
+#define GAS_ASM_SPEC "%{mcpu=*} %{m4650} %{m4710a0} %{m4710a0kern} 
%{mmad:-m4650} %{m3900} %{v} %{mgp32} %{mgp64}"
                                                                                                                                                             
 /* TARGET_ASM_SPEC is used to select either MIPS_AS_ASM_SPEC or
                                                                                                                                                             
...

And so we all have some idea where they started from:

--- gcc-3.0/gcc/version.c       2001-06-17 15:44:25.000000000 -0400
+++ WRT54G/tools-src/gnu-20010422/gcc/version.c 2003-10-10 
15:15:11.000000000 -0400
@@ -1,4 +1,4 @@
 #include "gansidecl.h"
 #include "version.h"
                                                                                                                                                             
-const char *const version_string = "3.0";
+const char *const version_string = "3.0 20010422 (prerelease) with 
bcm4710a0 modifications";


--
Charlie


From sjhill@realitydiluted.com Thu Jan 15 20:19:03 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 15 Jan 2004 20:19:04 +0000 (GMT)
Received: from real.realitydiluted.com ([IPv6:::ffff:208.242.241.164]:21158
	"EHLO real.realitydiluted.com") by linux-mips.org with ESMTP
	id <S8225475AbUAOUTD>; Thu, 15 Jan 2004 20:19:03 +0000
Received: from localhost ([127.0.0.1] helo=realitydiluted.com)
	by real.realitydiluted.com with esmtp (Exim 3.36 #1 (Debian))
	id 1AhDx9-0004UV-00; Thu, 15 Jan 2004 14:18:55 -0600
Message-ID: <4006F5A9.2040602@realitydiluted.com>
Date: Thu, 15 Jan 2004 15:18:49 -0500
From: "Steven J. Hill" <sjhill@realitydiluted.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031107 Debian/1.5-3
X-Accept-Language: en
MIME-Version: 1.0
To: Charlie Brady <charlieb-linux-mips@e-smith.com>
CC: "John W. Linville" <linville@lvl7.com>, linux-mips@linux-mips.org
Subject: Re: Broadcom gcc changes (was Re: Broadcom 4702?)
References: <Pine.LNX.4.44.0401151442590.17500-100000@allspice.nssg.mitel.com>
In-Reply-To: <Pine.LNX.4.44.0401151442590.17500-100000@allspice.nssg.mitel.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Return-Path: <sjhill@realitydiluted.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: 3984
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: sjhill@realitydiluted.com
Precedence: bulk
X-list: linux-mips

Charlie Brady wrote:
> 
> Here's some of the gcc changes, to give you all a feel for what changes 
> they've made.
> 
> --- gcc-3.0/gcc/config/mips/mips.h      2001-06-14 16:42:18.000000000 
> -0400
> +++ WRT54G/tools-src/gnu-20010422/gcc/config/mips/mips.h        2003-10-10 
> 15:15:14.000000000 -0400
> @@ -214,6 +214,7 @@

The change simply disables the compiler from emitting branch likely
instructions when compiler userspace code. Branch likely instructions
are allowed when compiling kernel code.

-Steve


From linville@lvl7.com Thu Jan 15 20:25:33 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 15 Jan 2004 20:25:33 +0000 (GMT)
Received: from mail.lvl7.com ([IPv6:::ffff:66.21.69.202]:55981 "EHLO
	lvl7ser4.lvl7.com") by linux-mips.org with ESMTP
	id <S8225470AbUAOUZd>; Thu, 15 Jan 2004 20:25:33 +0000
Received: from savage.dyndns.pengo.lvl7.com (grantc-cd310vm [192.168.77.181]) by lvl7ser4.lvl7.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55)
	id C7DFXPHP; Thu, 15 Jan 2004 15:28:41 -0500
Received: from lvl7.com (localhost.localdomain [127.0.0.1])
	by savage.dyndns.pengo.lvl7.com (8.11.6/8.11.6) with ESMTP id i0FKPPX17643;
	Thu, 15 Jan 2004 15:25:26 -0500
Message-ID: <4006F735.7020905@lvl7.com>
Date: Thu, 15 Jan 2004 15:25:25 -0500
From: "John W. Linville" <linville@lvl7.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3.1) Gecko/20030425
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Charlie Brady <charlieb-linux-mips@e-smith.com>
CC: linux-mips@linux-mips.org
Subject: Re: Broadcom gcc changes (was Re: Broadcom 4702?)
References: <Pine.LNX.4.44.0401151442590.17500-100000@allspice.nssg.mitel.com>
In-Reply-To: <Pine.LNX.4.44.0401151442590.17500-100000@allspice.nssg.mitel.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Return-Path: <linville@lvl7.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: 3985
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: linville@lvl7.com
Precedence: bulk
X-list: linux-mips

Charlie Brady wrote:

>On Thu, 15 Jan 2004, John W. Linville wrote:
>  
>
>>I don't know about the 4710 or 4702 (I haven't got around to that yet), 
>>but the 4704 doesn't seem to need any special flags for building the 
>>kernel (or anything else).
>>    
>>
>
>The acid test is not whether the kernel builds, but whether it runs 
>correctly under all circumstances :-)
>
Of course.  But, "all circumstances" is difficult to test... :-)

The BCM4704 kernels that I've been building seem to be running find, so 
far.  Hopefully they will continue to do so... :-)

John

-- 
John W. Linville
LVL7 Systems, Inc.



From alan@lxorguk.ukuu.org.uk Thu Jan 15 21:36:27 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 15 Jan 2004 21:36:30 +0000 (GMT)
Received: from crosslink-village-512-1.bc.nu ([IPv6:::ffff:81.2.110.254]:13985
	"EHLO dhcp23.swansea.linux.org.uk") by linux-mips.org with ESMTP
	id <S8225477AbUAOVg1>; Thu, 15 Jan 2004 21:36:27 +0000
Received: from dhcp23.swansea.linux.org.uk (localhost.localdomain [127.0.0.1])
	by dhcp23.swansea.linux.org.uk (8.12.10/8.12.10) with ESMTP id i0FLXH0r002767;
	Thu, 15 Jan 2004 21:33:19 GMT
Received: (from alan@localhost)
	by dhcp23.swansea.linux.org.uk (8.12.10/8.12.10/Submit) id i0FLXEBg002765;
	Thu, 15 Jan 2004 21:33:14 GMT
X-Authentication-Warning: dhcp23.swansea.linux.org.uk: alan set sender to alan@lxorguk.ukuu.org.uk using -f
Subject: Re: Broadcom 4702?
From: Alan Cox <alan@lxorguk.ukuu.org.uk>
To: Dominic Sweetman <dom@mips.com>
Cc: Charlie Brady <charlieb-linux-mips@e-smith.com>,
	Jun Sun <jsun@mvista.com>, linux-mips@linux-mips.org
In-Reply-To: <16390.22845.838720.511263@doms-laptop.algor.co.uk>
References: <20040114170355.G13471@mvista.com>
	 <Pine.LNX.4.44.0401142235300.17500-100000@allspice.nssg.mitel.com>
	 <16390.22845.838720.511263@doms-laptop.algor.co.uk>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Message-Id: <1074202392.2753.2.camel@dhcp23.swansea.linux.org.uk>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.4.5 (1.4.5-7) 
Date: Thu, 15 Jan 2004 21:33:13 +0000
Return-Path: <alan@lxorguk.ukuu.org.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: 3986
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: alan@lxorguk.ukuu.org.uk
Precedence: bulk
X-list: linux-mips

On Iau, 2004-01-15 at 09:11, Dominic Sweetman wrote:
> So yes, binary code distributed in a black box is still distributed,
> and if it was GPL software you are entitled to the source code.  It's
> sensible of Cisco to put it quietly on a web site somewhere.

This is actually one reason some embedded people have concerns about the
GPL. It isnt providing the code, its how to handle the offer/provision
when the product in question is a tea maker or some appliance where it
isnt natural to ship say an accompanying CD of windows drivers.


From jsun@mvista.com Thu Jan 15 22:09:57 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 15 Jan 2004 22:09:58 +0000 (GMT)
Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:64497 "EHLO
	orion.mvista.com") by linux-mips.org with ESMTP id <S8225480AbUAOWJ5>;
	Thu, 15 Jan 2004 22:09:57 +0000
Received: (from jsun@localhost)
	by orion.mvista.com (8.11.6/8.11.6) id i0FM9rK21655;
	Thu, 15 Jan 2004 14:09:53 -0800
Date: Thu, 15 Jan 2004 14:09:53 -0800
From: Jun Sun <jsun@mvista.com>
To: Kevin Paul Herbert <kph@cisco.com>
Cc: linux-mips@linux-mips.org, jsun@mvista.com
Subject: Re: [PATCH 2.6] DEBUG_INFO, KGDB and etc...
Message-ID: <20040115140953.F18368@mvista.com>
References: <20040115112201.E18368@mvista.com> <1074196652.24675.28.camel@shakedown>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="UFHRwCdBEJvubb2X"
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <1074196652.24675.28.camel@shakedown>; from kph@cisco.com on Thu, Jan 15, 2004 at 11:57:35AM -0800
Return-Path: <jsun@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: 3987
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


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

On Thu, Jan 15, 2004 at 11:57:35AM -0800, Kevin Paul Herbert wrote:
> In the top level makefile, there is already:
> 
> 	ifdef CONFIG_DEBUG_INFO
> 	CFLAGS		+= -g
> 	endif
> 
> I don't see why you need to add it to arch/mips/Makefile. Your Kconfig
> changes seem fine though.
> 

That is right.  Thanks for catching this.

The original problem started when KGDB did not cause "-g" to be included.
I simply looked at 2.4 and cooked the patch.  

The corrected patch is attached.

Jun

--UFHRwCdBEJvubb2X
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename=junk1

diff -Nru link/arch/mips/Kconfig.orig link/arch/mips/Kconfig
--- link/arch/mips/Kconfig.orig	Thu Jan 15 10:55:57 2004
+++ link/arch/mips/Kconfig	Thu Jan 15 11:12:23 2004
@@ -1233,23 +1233,6 @@
 	  This allows applications to run more reliably even when the system is
 	  under load.
 
-config DEBUG_INFO
-	bool "Compile the kernel with debug info"
-	depends on DEBUG_KERNEL
-	default y if KGDB
-	help
-	  If you say Y here the resulting kernel image will include
-	  debugging info resulting in a larger kernel image.
-	  Say Y here only if you plan to use gdb to debug the kernel.
-	  If you don't debug the kernel, you can say N.
-
-config SB1XXX_CORELIS
-	bool "Corelis Debugger"
-	depends on SIBYTE_SB1xxx_SOC && DEBUG_INFO
-	help
-	  Select compile flags that produce code that can be processed by the
-	  Corelis mksym utility and UDB Emulator.
-
 config DEBUG_SPINLOCK
 	bool "Spinlock debugging"
 	depends on DEBUG_KERNEL
@@ -1471,6 +1454,7 @@
 config KGDB
 	bool "Remote GDB kernel debugging"
 	depends on DEBUG_KERNEL
+	select DEBUG_INFO
 	help
 	  If you say Y here, it will be possible to remotely debug the MIPS
 	  kernel using gdb. This enlarges your kernel image disk size by
@@ -1486,6 +1470,23 @@
 	  would like kernel messages to be formatted into GDB $O packets so
 	  that GDB prints them as program output, say 'Y'.
 
+config DEBUG_INFO
+	bool "Compile the kernel with debug info"
+	depends on DEBUG_KERNEL && !KGDB
+	default y if KGDB
+	help
+	  If you say Y here the resulting kernel image will include
+	  debugging info resulting in a larger kernel image.
+	  Say Y here only if you plan to use gdb to debug the kernel.
+	  If you don't debug the kernel, you can say N.
+
+config SB1XXX_CORELIS
+	bool "Corelis Debugger"
+	depends on SIBYTE_SB1xxx_SOC && DEBUG_INFO
+	help
+	  Select compile flags that produce code that can be processed by the
+	  Corelis mksym utility and UDB Emulator.
+
 config RUNTIME_DEBUG
 	bool "Enable run-time debugging"
 	depends on DEBUG_KERNEL

--UFHRwCdBEJvubb2X--

From ilya@gateway.total-knowledge.com Thu Jan 15 22:46:34 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 15 Jan 2004 22:46:35 +0000 (GMT)
Received: from alpha.total-knowledge.com ([IPv6:::ffff:209.157.135.102]:15572
	"EHLO alpha.total-knowledge.com") by linux-mips.org with ESMTP
	id <S8225480AbUAOWqe>; Thu, 15 Jan 2004 22:46:34 +0000
Received: (qmail 15090 invoked from network); 15 Jan 2004 22:28:23 -0000
Received: from unknown (HELO gateway.total-knowledge.com) (12.234.207.60)
  by alpha.total-knowledge.com with DES-CBC3-SHA encrypted SMTP; 15 Jan 2004 22:28:23 -0000
Received: (qmail 16995 invoked by uid 502); 15 Jan 2004 14:46:27 -0800
Date: Thu, 15 Jan 2004 14:46:27 -0800
From: ilya@theIlya.com
To: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: linux-mips@linux-mips.org
Subject: Re: Broadcom 4702?
Message-ID: <20040115224627.GC12702@gateway.total-knowledge.com>
References: <20040114170355.G13471@mvista.com> <Pine.LNX.4.44.0401142235300.17500-100000@allspice.nssg.mitel.com> <16390.22845.838720.511263@doms-laptop.algor.co.uk> <1074202392.2753.2.camel@dhcp23.swansea.linux.org.uk>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <1074202392.2753.2.camel@dhcp23.swansea.linux.org.uk>
User-Agent: Mutt/1.5.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: 3988
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

I don't really see any problem with that. I think providing it
on web site and listing URL somewhere in manual should be more then
enough.
IANAL, of course.

	Ilya.

On Thu, Jan 15, 2004 at 09:33:13PM +0000, Alan Cox wrote:
> This is actually one reason some embedded people have concerns about the
> GPL. It isnt providing the code, its how to handle the offer/provision
> when the product in question is a tea maker or some appliance where it
> isnt natural to ship say an accompanying CD of windows drivers.
> 
> 

From rathann@icm.edu.pl Thu Jan 15 23:17:44 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 15 Jan 2004 23:17:45 +0000 (GMT)
Received: from gw.icm.edu.pl ([IPv6:::ffff:212.87.0.39]:63810 "EHLO
	atol.icm.edu.pl") by linux-mips.org with ESMTP id <S8225480AbUAOXRo>;
	Thu, 15 Jan 2004 23:17:44 +0000
Received: from rekin.icm.edu.pl (rekin.icm.edu.pl [192.168.1.132])
	by atol.icm.edu.pl (8.12.6/8.12.6/rzm-4.6/icm) with ESMTP id i0FNHV4p020769
	for <linux-mips@linux-mips.org>; Fri, 16 Jan 2004 00:17:31 +0100 (CET)
Received: from rathann by rekin.icm.edu.pl with local (Exim 3.35 #1 (Debian))
	id 1AhGk4-0001jD-00
	for <linux-mips@linux-mips.org>; Fri, 16 Jan 2004 00:17:36 +0100
Date: Fri, 16 Jan 2004 00:17:36 +0100
From: "Dominik 'Rathann' Mierzejewski" <rathann@icm.edu.pl>
To: linux-mips@linux-mips.org
Subject: Re: Current 2.4 CVS (2.4.24-pre2) doesn't boot on SGI Indy
Message-ID: <20040115231735.GA6619@icm.edu.pl>
Mail-Followup-To: linux-mips@linux-mips.org
References: <20040115141427.GA28546@icm.edu.pl> <Pine.LNX.4.21.0401151816540.3511-100000@www.marty44.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Pine.LNX.4.21.0401151816540.3511-100000@www.marty44.net>
User-Agent: Mutt/1.3.28i
Return-Path: <rathann@icm.edu.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: 3989
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: rathann@icm.edu.pl
Precedence: bulk
X-list: linux-mips

On Thu, Jan 15, 2004 at 06:19:36PM +0100, Martin Boehme wrote:
> Hello,
> 
> is your indy a R4k?

Yes, it's an R4600@133MHz.

> If so, I had the same problems. On R5k it works.
> There was some talking and some updates of R4k last two weeks. Look in
> the archives.
> Well, let's wait for the next commit to the offical kernel tree.

Well, it appears something has been broken during the last 2 months.
Good to know I'm not alone in this.

-- 
Dominik 'Rathann' Mierzejewski <rathann@icm.edu.pl>                                                 
Interdisciplinary Centre for Mathematical and Computational Modelling                               
Warsaw University  |  http://www.icm.edu.pl  |  tel. +48 (22) 5540810                               

From yuasa@hh.iij4u.or.jp Thu Jan 15 23:37:08 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 15 Jan 2004 23:37:10 +0000 (GMT)
Received: from mo03.iij4u.or.jp ([IPv6:::ffff:210.130.0.20]:30162 "EHLO
	mo03.iij4u.or.jp") by linux-mips.org with ESMTP id <S8225480AbUAOXhI>;
	Thu, 15 Jan 2004 23:37:08 +0000
Received: from mdo01.iij4u.or.jp (mdo01.iij4u.or.jp [210.130.0.171])
	by mo03.iij4u.or.jp (8.8.8/MFO1.5) with ESMTP id IAA11655;
	Fri, 16 Jan 2004 08:37:03 +0900 (JST)
Received: 4UMDO01 id i0FNb3g20055; Fri, 16 Jan 2004 08:37:03 +0900 (JST)
Received: 4UMRO01 id i0FNb1u26097; Fri, 16 Jan 2004 08:37:02 +0900 (JST)
	from stratos.frog (64.43.138.210.xn.2iij.net [210.138.43.64]) (authenticated)
Date: Fri, 16 Jan 2004 08:36:56 +0900
From: Yoichi Yuasa <yuasa@hh.iij4u.or.jp>
To: Ralf Baechle <ralf@linux-mips.org>
Cc: yuasa@hh.iij4u.or.jp, linux-mips <linux-mips@linux-mips.org>
Subject: [PATCH][2.4] Update NEC VRC4171 PCMCIA driver
Message-Id: <20040116083656.0bcde721.yuasa@hh.iij4u.or.jp>
X-Mailer: Sylpheed version 0.9.8a (GTK+ 1.2.10; i686-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Return-Path: <yuasa@hh.iij4u.or.jp>
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: 3990
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: yuasa@hh.iij4u.or.jp
Precedence: bulk
X-list: linux-mips

Hello Ralf,

I also updated the patch for VRC4171 PCMCIA driver.

The VRC4171 is companion chip for NEC VR4111 and VR4121.
The VRC4171 includes in the PCMCIA controller.

This patch exists for linux_2_4 tag of linux-mips.org CVS.
Please apply this patch.

Yoichi

diff -urN -X dontdiff linux-orig/drivers/pcmcia/Config.in linux/drivers/pcmcia/Config.in
--- linux-orig/drivers/pcmcia/Config.in	Sun Dec 21 10:27:50 2003
+++ linux/drivers/pcmcia/Config.in	Fri Jan 16 08:04:34 2004
@@ -40,6 +40,9 @@
    if [ "$CONFIG_SIBYTE_SB1xxx_SOC" = "y" ]; then
       dep_bool '  SiByte PCMCIA support' CONFIG_PCMCIA_SIBYTE $CONFIG_PCMCIA $CONFIG_BLK_DEV_IDE_SIBYTE
    fi
+   if [ "$CONFIG_VRC4171" = "y" -o "$CONFIG_VRC4171" = "m" ]; then
+      dep_tristate '  NEC VRC4171 Card Controllers support' CONFIG_PCMCIA_VRC4171 $CONFIG_PCMCIA
+   fi
    if [ "$CONFIG_VRC4173" = "y" -o "$CONFIG_VRC4173" = "m" ]; then
       dep_tristate '  NEC VRC4173 CARDU support' CONFIG_PCMCIA_VRC4173 $CONFIG_PCMCIA
    fi
diff -urN -X dontdiff linux-orig/drivers/pcmcia/Makefile linux/drivers/pcmcia/Makefile
--- linux-orig/drivers/pcmcia/Makefile	Tue Jul 15 01:14:06 2003
+++ linux/drivers/pcmcia/Makefile	Fri Jan 16 08:04:34 2004
@@ -89,6 +89,7 @@
 sa1100_cs-objs-$(CONFIG_SA1100_XP860)		+= sa1100_xp860.o sa1111_generic.o
 sa1100_cs-objs-$(CONFIG_SA1100_YOPY)		+= sa1100_yopy.o
 
+obj-$(CONFIG_PCMCIA_VRC4171)	+= vrc4171_card.o
 obj-$(CONFIG_PCMCIA_VRC4173)	+= vrc4173_cardu.o
 
 include $(TOPDIR)/Rules.make
diff -urN -X dontdiff linux-orig/drivers/pcmcia/vrc4171_card.c linux/drivers/pcmcia/vrc4171_card.c
--- linux-orig/drivers/pcmcia/vrc4171_card.c	Thu Jan  1 09:00:00 1970
+++ linux/drivers/pcmcia/vrc4171_card.c	Fri Jan 16 08:04:34 2004
@@ -0,0 +1,886 @@
+/*
+ * vrc4171_card.c, NEC VRC4171 Card Controller driver for Socket Services.
+ *
+ * Copyright (C) 2003  Yoichi Yuasa <yuasa@hh.iij4u.or.jp>
+ *
+ *  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.
+ *
+ *  This program is distributed in the hope that it will be useful,
+ *  but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *  GNU General Public License for more details.
+ *
+ *  You should have received a copy of the GNU General Public License
+ *  along with this program; if not, write to the Free Software
+ *  Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
+ */
+#include <linux/init.h>
+#include <linux/ioport.h>
+#include <linux/irq.h>
+#include <linux/module.h>
+#include <linux/spinlock.h>
+#include <linux/sched.h>
+#include <linux/types.h>
+
+#include <asm/io.h>
+#include <asm/vr41xx/vrc4171.h>
+
+#include <pcmcia/ss.h>
+
+#include "i82365.h"
+
+MODULE_DESCRIPTION("NEC VRC4171 Card Controllers driver for Socket Services");
+MODULE_AUTHOR("Yoichi Yuasa <yuasa@hh.iij4u.or.jp>");
+MODULE_LICENSE("GPL");
+
+#define CARD_MAX_SLOTS		2
+#define CARD_SLOTA		0
+#define CARD_SLOTB		1
+#define CARD_SLOTB_OFFSET	0x40
+
+#define CARD_MEM_START		0x10000000
+#define CARD_MEM_END		0x13ffffff
+#define CARD_MAX_MEM_OFFSET	0x3ffffff
+#define CARD_MAX_MEM_SPEED	1000
+
+#define CARD_CONTROLLER_INDEX	0x03e0
+#define CARD_CONTROLLER_DATA	0x03e1
+#define CARD_CONTROLLER_SIZE	2
+ /* Power register */
+  #define VPP_GET_VCC		0x01
+  #define POWER_ENABLE		0x10
+ #define CARD_VOLTAGE_SENSE	0x1f
+  #define VCC_3VORXV_CAPABLE	0x00
+  #define VCC_XV_ONLY		0x01
+  #define VCC_3V_CAPABLE	0x02
+  #define VCC_5V_ONLY		0x03
+ #define CARD_VOLTAGE_SELECT	0x2f
+  #define VCC_3V		0x01
+  #define VCC_5V		0x00
+  #define VCC_XV		0x02
+  #define VCC_STATUS_3V		0x02
+  #define VCC_STATUS_5V		0x01
+  #define VCC_STATUS_XV		0x03
+ #define GLOBAL_CONTROL		0x1e
+  #define EXWRBK		0x04
+  #define IRQPM_EN		0x08
+  #define CLRPMIRQ		0x10
+
+#define IO_MAX_MAPS	2
+#define MEM_MAX_MAPS	5
+
+enum {
+	SLOTB_PROBE = 0,
+	SLOTB_NOPROBE_IO,
+	SLOTB_NOPROBE_MEM,
+	SLOTB_NOPROBE_ALL
+};
+
+typedef struct vrc4171_socket {
+	int noprobe;
+	void (*handler)(void *, unsigned int);
+	void *info;
+	socket_cap_t cap;
+	spinlock_t event_lock;
+	uint16_t events;
+	struct socket_info_t *pcmcia_socket;
+	struct tq_struct tq_task;
+	char name[24];
+	int csc_irq;
+	int io_irq;
+} vrc4171_socket_t;
+
+static vrc4171_socket_t vrc4171_sockets[CARD_MAX_SLOTS];
+static int vrc4171_slotb = SLOTB_IS_NONE;
+static unsigned int vrc4171_irq;
+static uint16_t vrc4171_irq_mask = 0xdeb8;
+
+extern struct socket_info_t *pcmcia_register_socket(int slot,
+                                                    struct pccard_operations *vtable,
+                                                    int use_bus_pm);
+extern void pcmcia_unregister_socket(struct socket_info_t *s);
+
+static inline uint8_t exca_read_byte(int slot, uint8_t index)
+{
+	if (slot == CARD_SLOTB)
+		index += CARD_SLOTB_OFFSET;
+
+	outb(index, CARD_CONTROLLER_INDEX);
+	return inb(CARD_CONTROLLER_DATA);
+}
+
+static inline uint16_t exca_read_word(int slot, uint8_t index)
+{
+	uint16_t data;
+
+	if (slot == CARD_SLOTB)
+		index += CARD_SLOTB_OFFSET;
+
+	outb(index++, CARD_CONTROLLER_INDEX);
+	data = inb(CARD_CONTROLLER_DATA);
+
+	outb(index, CARD_CONTROLLER_INDEX);
+	data |= ((uint16_t)inb(CARD_CONTROLLER_DATA)) << 8;
+
+	return data;
+}
+
+static inline uint8_t exca_write_byte(int slot, uint8_t index, uint8_t data)
+{
+	if (slot == CARD_SLOTB)
+		index += CARD_SLOTB_OFFSET;
+
+	outb(index, CARD_CONTROLLER_INDEX);
+	outb(data, CARD_CONTROLLER_DATA);
+
+	return data;
+}
+
+static inline uint16_t exca_write_word(int slot, uint8_t index, uint16_t data)
+{
+	if (slot == CARD_SLOTB)
+		index += CARD_SLOTB_OFFSET;
+
+	outb(index++, CARD_CONTROLLER_INDEX);
+	outb(data, CARD_CONTROLLER_DATA);
+
+	outb(index, CARD_CONTROLLER_INDEX);
+	outb((uint8_t)(data >> 8), CARD_CONTROLLER_DATA);
+
+	return data;
+}
+
+static inline int search_nonuse_irq(void)
+{
+	int i;
+
+	for (i = 0; i < 16; i++) {
+		if (vrc4171_irq_mask & (1 << i)) {
+			vrc4171_irq_mask &= ~(1 << i);
+			return i;
+		}
+	}
+
+	return -1;
+}
+
+static int pccard_init(unsigned int slot)
+{
+	vrc4171_socket_t *socket = &vrc4171_sockets[slot];
+
+	socket->cap.features |= SS_CAP_PCCARD | SS_CAP_PAGE_REGS;
+	socket->cap.irq_mask = 0;
+	socket->cap.pci_irq = vrc4171_irq;
+	socket->cap.map_size = 0x1000;
+	socket->events = 0;
+	spin_lock_init(socket->event_lock);
+	socket->csc_irq = search_nonuse_irq();
+	socket->io_irq = search_nonuse_irq();
+
+	return 0;
+}
+
+static int pccard_suspend(unsigned int slot)
+{
+	return -EINVAL;
+}
+
+static int pccard_register_callback(unsigned int slot,
+                                    void (*handler)(void *, unsigned int),
+                                    void *info)
+{
+	vrc4171_socket_t *socket;
+
+	if (slot >= CARD_MAX_SLOTS)
+		return -EINVAL;
+
+	socket = &vrc4171_sockets[slot];
+
+	socket->handler = handler;
+	socket->info = info;
+
+	if (handler)
+		MOD_INC_USE_COUNT;
+	else
+		MOD_DEC_USE_COUNT;
+
+	return 0;
+}
+
+static int pccard_inquire_socket(unsigned int slot, socket_cap_t *cap)
+{
+	vrc4171_socket_t *socket;
+
+	if (slot >= CARD_MAX_SLOTS || cap == NULL)
+		return -EINVAL;
+
+	socket = &vrc4171_sockets[slot];
+
+	*cap = socket->cap;
+
+	return 0;
+}
+
+static int pccard_get_status(unsigned int slot, u_int *value)
+{
+	uint8_t status, sense;
+	u_int val = 0;
+
+	if (slot >= CARD_MAX_SLOTS || value == NULL)
+		return -EINVAL;
+
+	status = exca_read_byte(slot, I365_STATUS);
+	if (exca_read_byte(slot, I365_INTCTL) & I365_PC_IOCARD) {
+		if (status & I365_CS_STSCHG)
+			val |= SS_STSCHG;
+	} else {
+		if (!(status & I365_CS_BVD1))
+			val |= SS_BATDEAD;
+		else if ((status & (I365_CS_BVD1 | I365_CS_BVD2)) == I365_CS_BVD1)
+			val |= SS_BATWARN;
+	}
+	if ((status & I365_CS_DETECT) == I365_CS_DETECT)
+		val |= SS_DETECT;
+	if (status & I365_CS_WRPROT)
+		val |= SS_WRPROT;
+	if (status & I365_CS_READY)
+		val |= SS_READY;
+	if (status & I365_CS_POWERON)
+		val |= SS_POWERON;
+
+	sense = exca_read_byte(slot, CARD_VOLTAGE_SENSE);
+	switch (sense) {
+	case VCC_3VORXV_CAPABLE:
+		val |= SS_3VCARD | SS_XVCARD;
+		break;
+	case VCC_XV_ONLY:
+		val |= SS_XVCARD;
+		break;
+	case VCC_3V_CAPABLE:
+		val |= SS_3VCARD;
+		break;
+	default:
+		/* 5V only */
+		break;
+	}
+
+	*value = val;
+
+	return 0;
+}
+
+static inline u_char get_Vcc_value(uint8_t voltage)
+{
+	switch (voltage) {
+	case VCC_STATUS_3V:
+		return 33;
+	case VCC_STATUS_5V:
+		return 50;
+	default:
+		break;
+	}
+
+	return 0;
+}
+
+static inline u_char get_Vpp_value(uint8_t power, u_char Vcc)
+{
+	if ((power & 0x03) == 0x01 || (power & 0x03) == 0x02)
+		return Vcc;
+
+	return 0;
+}
+
+static int pccard_get_socket(unsigned int slot, socket_state_t *state)
+{
+	vrc4171_socket_t *socket;
+	uint8_t power, voltage, control, cscint;
+
+	if (slot >= CARD_MAX_SLOTS || state == NULL)
+		return -EINVAL;
+
+	socket = &vrc4171_sockets[slot];
+
+	power = exca_read_byte(slot, I365_POWER);
+	voltage = exca_read_byte(slot, CARD_VOLTAGE_SELECT);
+
+	state->Vcc = get_Vcc_value(voltage);
+	state->Vpp = get_Vpp_value(power, state->Vcc);
+
+	state->flags = 0;
+	if (power & POWER_ENABLE)
+		state->flags |= SS_PWR_AUTO;
+	if (power & I365_PWR_OUT)
+		state->flags |= SS_OUTPUT_ENA;
+
+	control = exca_read_byte(slot, I365_INTCTL);
+	if (control & I365_PC_IOCARD)
+		state->flags |= SS_IOCARD;
+	if (!(control & I365_PC_RESET))
+		state->flags |= SS_RESET;
+
+        cscint = exca_read_byte(slot, I365_CSCINT);
+	state->csc_mask = 0;
+	if (state->flags & SS_IOCARD) {
+		if (cscint & I365_CSC_STSCHG)
+			state->flags |= SS_STSCHG;
+	} else {
+		if (cscint & I365_CSC_BVD1)  
+			state->csc_mask |= SS_BATDEAD;
+		if (cscint & I365_CSC_BVD2)  
+			state->csc_mask |= SS_BATWARN;
+	}
+	if (cscint & I365_CSC_READY)
+		state->csc_mask |= SS_READY;
+	if (cscint & I365_CSC_DETECT)
+		state->csc_mask |= SS_DETECT;
+
+	return 0;
+}
+
+static inline uint8_t set_Vcc_value(u_char Vcc)
+{
+	switch (Vcc) {
+	case 33:
+		return VCC_3V;
+	case 50:
+		return VCC_5V;
+	}
+
+	/* Small voltage is chosen for safety. */
+	return VCC_3V;
+}
+
+static int pccard_set_socket(unsigned int slot, socket_state_t *state)
+{
+	vrc4171_socket_t *socket;
+	uint8_t voltage, power, control, cscint;
+
+	if (slot >= CARD_MAX_SLOTS ||
+	    (state->Vpp != state->Vcc && state->Vpp != 0) ||
+	    (state->Vcc != 50 && state->Vcc != 33 && state->Vcc != 0))
+		return -EINVAL;
+
+	socket = &vrc4171_sockets[slot];
+
+	spin_lock_irq(&socket->event_lock);
+
+	voltage = set_Vcc_value(state->Vcc);
+	exca_write_byte(slot, CARD_VOLTAGE_SELECT, voltage);
+
+	power = POWER_ENABLE;
+	if (state->Vpp == state->Vcc)
+		power |= VPP_GET_VCC;
+	if (state->flags & SS_OUTPUT_ENA)
+		power |= I365_PWR_OUT;
+	exca_write_byte(slot, I365_POWER, power);
+
+	control = 0;
+	if (state->io_irq != 0)
+		control |= socket->io_irq;
+	if (state->flags & SS_IOCARD)
+		control |= I365_PC_IOCARD;
+	if (state->flags & SS_RESET)
+		control	&= ~I365_PC_RESET;
+	else
+		control |= I365_PC_RESET;
+	exca_write_byte(slot, I365_INTCTL, control);
+
+        cscint = 0;
+        exca_write_byte(slot, I365_CSCINT, cscint);
+	exca_read_byte(slot, I365_CSC);	/* clear CardStatus change */
+	if (state->csc_mask != 0)
+		cscint |= socket->csc_irq << 8;
+	if (state->flags & SS_IOCARD) {
+		if (state->csc_mask & SS_STSCHG)
+			cscint |= I365_CSC_STSCHG;
+	} else {
+		if (state->csc_mask & SS_BATDEAD)
+			cscint |= I365_CSC_BVD1;
+		if (state->csc_mask & SS_BATWARN)
+			cscint |= I365_CSC_BVD2;
+	}
+	if (state->csc_mask & SS_READY)
+		cscint |= I365_CSC_READY;
+	if (state->csc_mask & SS_DETECT)
+		cscint |= I365_CSC_DETECT;
+        exca_write_byte(slot, I365_CSCINT, cscint);
+
+	spin_unlock_irq(&socket->event_lock);
+
+	return 0;
+}
+
+static int pccard_get_io_map(unsigned int slot, struct pccard_io_map *io)
+{
+	vrc4171_socket_t *socket;
+	uint8_t ioctl, addrwin;
+	u_char map;
+
+	if (slot >= CARD_MAX_SLOTS || io == NULL ||
+	    io->map >= IO_MAX_MAPS)
+		return -EINVAL;
+
+	socket = &vrc4171_sockets[slot];
+	map = io->map;
+
+	io->start = exca_read_word(slot, I365_IO(map)+I365_W_START);
+	io->stop = exca_read_word(slot, I365_IO(map)+I365_W_STOP);
+
+	ioctl = exca_read_byte(slot, I365_IOCTL);
+	if (io->flags & I365_IOCTL_WAIT(map))
+		io->speed = 1;
+	else
+		io->speed = 0;
+
+	io->flags = 0;
+	if (ioctl & I365_IOCTL_16BIT(map))
+		io->flags |= MAP_16BIT;
+	if (ioctl & I365_IOCTL_IOCS16(map))
+		io->flags |= MAP_AUTOSZ;
+	if (ioctl & I365_IOCTL_0WS(map))
+		io->flags |= MAP_0WS;
+
+	addrwin = exca_read_byte(slot, I365_ADDRWIN);
+	if (addrwin & I365_ENA_IO(map))
+		io->flags |= MAP_ACTIVE;
+
+	return 0;
+}
+
+static int pccard_set_io_map(unsigned int slot, struct pccard_io_map *io)
+{
+	vrc4171_socket_t *socket;
+	uint8_t ioctl, addrwin;
+	u_char map;
+
+	if (slot >= CARD_MAX_SLOTS ||
+	    io == NULL || io->map >= IO_MAX_MAPS ||
+	    io->start > 0xffff || io->stop > 0xffff || io->start > io->stop)
+		return -EINVAL;
+
+	socket = &vrc4171_sockets[slot];
+	map = io->map;
+
+	addrwin = exca_read_byte(slot, I365_ADDRWIN);
+	if (addrwin & I365_ENA_IO(map)) {
+		addrwin &= ~I365_ENA_IO(map);
+		exca_write_byte(slot, I365_ADDRWIN, addrwin);
+	}
+
+	exca_write_word(slot, I365_IO(map)+I365_W_START, io->start);
+	exca_write_word(slot, I365_IO(map)+I365_W_STOP, io->stop);
+
+	ioctl = 0;
+	if (io->speed > 0)
+		ioctl |= I365_IOCTL_WAIT(map);
+	if (io->flags & MAP_16BIT)
+		ioctl |= I365_IOCTL_16BIT(map);
+	if (io->flags & MAP_AUTOSZ)
+		ioctl |= I365_IOCTL_IOCS16(map);
+	if (io->flags & MAP_0WS)
+		ioctl |= I365_IOCTL_0WS(map);
+	exca_write_byte(slot, I365_IOCTL, ioctl);
+
+	if (io->flags & MAP_ACTIVE) {
+		addrwin |= I365_ENA_IO(map);
+		exca_write_byte(slot, I365_ADDRWIN, addrwin);
+	}
+
+	return 0;
+}
+
+static int pccard_get_mem_map(unsigned int slot, struct pccard_mem_map *mem)
+{
+	vrc4171_socket_t *socket;
+	uint8_t addrwin;
+	u_long start, stop;
+	u_int offset;
+	u_char map;
+
+	if (slot >= CARD_MAX_SLOTS || mem == NULL || mem->map >= MEM_MAX_MAPS)
+		return -EINVAL;
+
+	socket = &vrc4171_sockets[slot];
+	map = mem->map;
+
+	mem->flags = 0;
+	mem->speed = 0;
+
+	addrwin = exca_read_byte(slot, I365_ADDRWIN);
+	if (addrwin & I365_ENA_MEM(map))
+		mem->flags |= MAP_ACTIVE;
+
+	start = exca_read_word(slot, I365_MEM(map)+I365_W_START);
+	if (start & I365_MEM_16BIT)
+		mem->flags |= MAP_16BIT;
+	mem->sys_start = (start & 0x3fffUL) << 12;
+
+	stop = exca_read_word(slot, I365_MEM(map)+I365_W_STOP);
+	if (start & I365_MEM_WS0)
+		mem->speed += 1;
+	if (start & I365_MEM_WS1)
+		mem->speed += 2;
+	mem->sys_stop = ((stop & 0x3fffUL) << 12) + 0xfffUL;
+
+	offset = exca_read_word(slot, I365_MEM(map)+I365_W_OFF);
+	if (offset & I365_MEM_REG)
+		mem->flags |= MAP_ATTRIB;
+	if (offset & I365_MEM_WRPROT)
+		mem->flags |= MAP_WRPROT;
+	mem->card_start = (offset & 0x3fffUL) << 12;
+
+	mem->sys_start += CARD_MEM_START;
+	mem->sys_stop += CARD_MEM_START;
+
+	return 0;
+}
+
+static int pccard_set_mem_map(unsigned int slot, struct pccard_mem_map *mem)
+{
+	vrc4171_socket_t *socket;
+	uint16_t start, stop, offset;
+	uint8_t addrwin;
+	u_char map;
+
+	if (slot >= CARD_MAX_SLOTS ||
+	    mem == NULL || mem->map >= MEM_MAX_MAPS ||
+	    mem->sys_start < CARD_MEM_START || mem->sys_start > CARD_MEM_END ||
+	    mem->sys_stop < CARD_MEM_START || mem->sys_stop > CARD_MEM_END ||
+	    mem->sys_start > mem->sys_stop ||
+	    mem->card_start > CARD_MAX_MEM_OFFSET ||
+	    mem->speed > CARD_MAX_MEM_SPEED)
+		return -EINVAL;
+
+	socket = &vrc4171_sockets[slot];
+	map = mem->map;
+
+	addrwin = exca_read_byte(slot, I365_ADDRWIN);
+	if (addrwin & I365_ENA_MEM(map)) {
+		addrwin &= ~I365_ENA_MEM(map);
+		exca_write_byte(slot, I365_ADDRWIN, addrwin);
+	}
+
+	start = (mem->sys_start >> 12) & 0x3fff;
+	if (mem->flags & MAP_16BIT)
+		start |= I365_MEM_16BIT;
+	exca_write_word(slot, I365_MEM(map)+I365_W_START, start);
+
+	stop = (mem->sys_stop >> 12) & 0x3fff;
+	switch (mem->speed) {
+	case 0:
+		break;
+	case 1:
+		stop |= I365_MEM_WS0;
+		break;
+	case 2:
+		stop |= I365_MEM_WS1;
+		break;
+	default:
+		stop |= I365_MEM_WS0 | I365_MEM_WS1;
+		break;
+	}
+	exca_write_word(slot, I365_MEM(map)+I365_W_STOP, stop);
+
+	offset = (mem->card_start >> 12) & 0x3fff;
+	if (mem->flags & MAP_ATTRIB)
+		offset |= I365_MEM_REG;
+	if (mem->flags & MAP_WRPROT)
+		offset |= I365_MEM_WRPROT;
+	exca_write_word(slot, I365_MEM(map)+I365_W_OFF, offset);
+
+	if (mem->flags & MAP_ACTIVE) {
+		addrwin |= I365_ENA_MEM(map);
+		exca_write_byte(slot, I365_ADDRWIN, addrwin);
+	}
+
+	return 0;
+}
+
+static void pccard_proc_setup(unsigned int slot, struct proc_dir_entry *base)
+{          
+}
+
+static struct pccard_operations vrc4171_pccard_operations = {
+	.init			= pccard_init,
+	.suspend		= pccard_suspend,
+	.register_callback	= pccard_register_callback,
+	.inquire_socket		= pccard_inquire_socket,
+	.get_status		= pccard_get_status,
+	.get_socket		= pccard_get_socket,
+	.set_socket		= pccard_set_socket,
+	.get_io_map		= pccard_get_io_map,
+	.set_io_map		= pccard_set_io_map,
+	.get_mem_map		= pccard_get_mem_map,
+	.set_mem_map		= pccard_set_mem_map,
+	.proc_setup		= pccard_proc_setup,
+};
+
+static void pccard_bh(void *data)
+{
+	vrc4171_socket_t *socket = (vrc4171_socket_t *)data;
+	uint16_t events;
+
+	spin_lock_irq(&socket->event_lock);
+	events = socket->events;
+	socket->events = 0;
+	spin_unlock_irq(&socket->event_lock);
+ 
+	if (socket->handler)
+		socket->handler(socket->info, events);
+}
+
+static inline uint16_t get_events(int slot)
+{
+	uint16_t events = 0;
+	uint8_t status, csc;
+
+	status = exca_read_byte(slot, I365_STATUS);
+	csc = exca_read_byte(slot, I365_CSC);
+
+	if (exca_read_byte(slot, I365_INTCTL) & I365_PC_IOCARD) {
+		if ((csc & I365_CSC_STSCHG) && (status & I365_CS_STSCHG))
+			events |= SS_STSCHG;
+	} else {
+		if (csc & (I365_CSC_BVD1 | I365_CSC_BVD2)) {
+			if (!(status & I365_CS_BVD1))
+				events |= SS_BATDEAD;
+			else if ((status & (I365_CS_BVD1 | I365_CS_BVD2)) == I365_CS_BVD1)
+				events |= SS_BATWARN;
+		}
+	}
+	if ((csc & I365_CSC_READY) && (status & I365_CS_READY))
+		events |= SS_READY;
+	if ((csc & I365_CSC_DETECT) && ((status & I365_CS_DETECT) == I365_CS_DETECT))
+		events |= SS_DETECT;
+
+	return events;
+}
+
+static void pccard_status_change(int slot, vrc4171_socket_t *socket)
+{
+	uint16_t events;
+
+	socket->tq_task.routine = pccard_bh;
+	socket->tq_task.data = socket;
+
+	events = get_events(slot);
+	if (events) {
+		spin_lock(&socket->event_lock);
+		socket->events |= events;
+		spin_unlock(&socket->event_lock);
+		schedule_task(&socket->tq_task);
+	}
+}
+
+static void pccard_interrupt(int irq, void *dev_id, struct pt_regs *regs)
+{
+	vrc4171_socket_t *socket;
+	uint16_t status;
+
+	status = vrc4171_get_irq_status();
+	if (status & IRQ_A) {
+		socket = &vrc4171_sockets[CARD_SLOTA];
+		if (socket->noprobe == SLOTB_PROBE) {
+			if (status & (1 << socket->csc_irq))
+				pccard_status_change(CARD_SLOTA, socket);
+		}
+	}
+
+	if (status & IRQ_B) {
+		socket = &vrc4171_sockets[CARD_SLOTB];
+		if (socket->noprobe == SLOTB_PROBE) {
+			if (status & (1 << socket->csc_irq))
+				pccard_status_change(CARD_SLOTB, socket);
+		}
+	}
+}
+
+static inline void reserve_using_irq(int slot)
+{
+	unsigned int irq;
+
+	irq = exca_read_byte(slot, I365_INTCTL);
+	irq &= 0x0f;
+	vrc4171_irq_mask &= ~(1 << irq);
+
+	irq = exca_read_byte(slot, I365_CSCINT);
+	irq = (irq & 0xf0) >> 4;
+	vrc4171_irq_mask &= ~(1 << irq);
+}
+
+static int __devinit vrc4171_add_socket(int slot)
+{
+	vrc4171_socket_t *socket;
+
+	if (slot >= CARD_MAX_SLOTS)
+		return -EINVAL;
+
+	socket = &vrc4171_sockets[slot];
+	if (socket->noprobe != SLOTB_PROBE) {
+		uint8_t addrwin;
+
+		switch (socket->noprobe) {
+		case SLOTB_NOPROBE_MEM:
+			addrwin = exca_read_byte(slot, I365_ADDRWIN);
+			addrwin &= 0x1f;
+			exca_write_byte(slot, I365_ADDRWIN, addrwin);
+			break;
+		case SLOTB_NOPROBE_IO:
+			addrwin = exca_read_byte(slot, I365_ADDRWIN);
+			addrwin &= 0xc0;
+			exca_write_byte(slot, I365_ADDRWIN, addrwin);
+			break;
+		default:
+			break;
+		}
+
+		reserve_using_irq(slot);
+
+		return 0;
+	}
+
+	sprintf(socket->name, "NEC VRC4171 Card Slot %1c", 'A' + slot);
+
+	socket->pcmcia_socket = pcmcia_register_socket(slot, &vrc4171_pccard_operations, 1);
+	if (socket->pcmcia_socket == NULL)
+		return -ENOMEM;
+
+	exca_write_byte(slot, I365_ADDRWIN, 0);
+
+	exca_write_byte(slot, GLOBAL_CONTROL, 0);
+
+	return 0;
+}
+
+static void vrc4171_remove_socket(int slot)
+{
+	vrc4171_socket_t *socket;
+
+	if (slot >= CARD_MAX_SLOTS)
+		return;
+
+	socket = &vrc4171_sockets[slot];
+
+	if (socket->pcmcia_socket != NULL) {
+		pcmcia_unregister_socket(socket->pcmcia_socket);
+		socket->pcmcia_socket = NULL;
+	}
+}
+
+static int __devinit vrc4171_card_setup(char *options)
+{
+	if (options == NULL || *options == '\0')
+		return 0;
+
+	if (strncmp(options, "irq:", 4) == 0) {
+		int irq;
+		options += 4;
+		irq = simple_strtoul(options, &options, 0);
+		if (irq >= 0 && irq < NR_IRQS)
+			vrc4171_irq = irq;
+
+		if (*options != ',')
+			return 0;
+		options++;
+	}
+
+	if (strncmp(options, "slota:", 6) == 0) {
+		options += 6;
+		if (*options != '\0') {
+			if (strncmp(options, "noprobe", 7) == 0) {
+				vrc4171_sockets[CARD_SLOTA].noprobe = 1;
+				options += 7;
+			}
+
+			if (*options != ',')
+				return 0;
+			options++;
+		} else
+			return 0;
+
+	}
+
+	if (strncmp(options, "slotb:", 6) == 0) {
+		options += 6;
+		if (*options != '\0') {
+			if (strncmp(options, "pccard", 6) == 0) {
+				vrc4171_slotb = SLOTB_IS_PCCARD;
+				options += 6;
+			} else if (strncmp(options, "cf", 2) == 0) {
+				vrc4171_slotb = SLOTB_IS_CF;
+				options += 2;
+			} else if (strncmp(options, "flashrom", 8) == 0) {
+				vrc4171_slotb = SLOTB_IS_FLASHROM;
+				options += 8;
+			} else if (strncmp(options, "none", 4) == 0) {
+				vrc4171_slotb = SLOTB_IS_NONE;
+				options += 4;
+			}
+
+			if (*options != ',')
+				return 0;
+			options++;
+
+			if ( strncmp(options, "memnoprobe", 10) == 0)
+				vrc4171_sockets[CARD_SLOTB].noprobe = SLOTB_NOPROBE_MEM;
+			if ( strncmp(options, "ionoprobe", 9) == 0)
+				vrc4171_sockets[CARD_SLOTB].noprobe = SLOTB_NOPROBE_IO;
+			if ( strncmp(options, "noprobe", 7) == 0)
+				vrc4171_sockets[CARD_SLOTB].noprobe = SLOTB_NOPROBE_ALL;
+		}
+	}
+
+	return 0;
+}
+
+__setup("vrc4171_card=", vrc4171_card_setup);
+
+static int __devinit vrc4171_card_init(void)
+{
+	int retval, slot;
+
+	vrc4171_set_multifunction_pin(vrc4171_slotb);
+
+	if (request_region(CARD_CONTROLLER_INDEX, CARD_CONTROLLER_SIZE,
+	                       "NEC VRC4171 Card Controller") == NULL)
+		return -EBUSY;
+
+	for (slot = 0; slot < CARD_MAX_SLOTS; slot++) {
+		if (slot == CARD_SLOTB && vrc4171_slotb == SLOTB_IS_NONE)
+			break;
+
+		retval = vrc4171_add_socket(slot);
+		if (retval != 0)
+			return retval;
+	}
+
+	retval = request_irq(vrc4171_irq, pccard_interrupt, SA_SHIRQ,
+	                     "NEC VRC4171 Card Controller", vrc4171_sockets);
+	if (retval < 0) {
+		for (slot = 0; slot < CARD_MAX_SLOTS; slot++)
+			vrc4171_remove_socket(slot);
+
+		return retval;
+	}
+
+	printk(KERN_INFO "NEC VRC4171 Card Controller, connected to IRQ %d\n", vrc4171_irq);
+
+	return 0;
+}
+
+static void __devexit vrc4171_card_exit(void)
+{
+	int slot;
+
+	for (slot = 0; slot < CARD_MAX_SLOTS; slot++)
+		vrc4171_remove_socket(slot);
+
+	release_region(CARD_CONTROLLER_INDEX, CARD_CONTROLLER_SIZE);
+}
+
+module_init(vrc4171_card_init);
+module_exit(vrc4171_card_exit);

From yuasa@hh.iij4u.or.jp Thu Jan 15 23:38:33 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 15 Jan 2004 23:38:35 +0000 (GMT)
Received: from mo02.iij4u.or.jp ([IPv6:::ffff:210.130.0.19]:36816 "EHLO
	mo02.iij4u.or.jp") by linux-mips.org with ESMTP id <S8225480AbUAOXid>;
	Thu, 15 Jan 2004 23:38:33 +0000
Received: from mdo00.iij4u.or.jp (mdo00.iij4u.or.jp [210.130.0.170])
	by mo02.iij4u.or.jp (8.8.8/MFO1.5) with ESMTP id IAA07221;
	Fri, 16 Jan 2004 08:38:27 +0900 (JST)
Received: 4UMDO00 id i0FNcRc12575; Fri, 16 Jan 2004 08:38:27 +0900 (JST)
Received: 4UMRO01 id i0FNcQu26180; Fri, 16 Jan 2004 08:38:26 +0900 (JST)
	from stratos.frog (64.43.138.210.xn.2iij.net [210.138.43.64]) (authenticated)
Date: Fri, 16 Jan 2004 08:38:21 +0900
From: Yoichi Yuasa <yuasa@hh.iij4u.or.jp>
To: Ralf Baechle <ralf@linux-mips.org>
Cc: yuasa@hh.iij4u.or.jp, linux-mips <linux-mips@linux-mips.org>
Subject: [PATCH][2.6] Update NEC VRC4171 PCMCIA driver
Message-Id: <20040116083821.6b65c69f.yuasa@hh.iij4u.or.jp>
X-Mailer: Sylpheed version 0.9.8a (GTK+ 1.2.10; i686-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Return-Path: <yuasa@hh.iij4u.or.jp>
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: 3991
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: yuasa@hh.iij4u.or.jp
Precedence: bulk
X-list: linux-mips

Hello Ralf,

I also updated the patch for VRC4171 PCMCIA driver.

This patch exists for HEAD of linux-mips.org CVS.
Please apply this patch.

Yoichi

diff -urN -X dontdiff linux-orig/drivers/pcmcia/Kconfig linux/drivers/pcmcia/Kconfig
--- linux-orig/drivers/pcmcia/Kconfig	Fri Jan 16 01:21:24 2004
+++ linux/drivers/pcmcia/Kconfig	Fri Jan 16 08:05:00 2004
@@ -121,6 +121,10 @@
 	bool
 	default y if ISA && !ARCH_SA1100 && !ARCH_CLPS711X
 
+config PCMCIA_VRC4171
+	tristate "NEC VRC4171 Card Controllers support"
+	depends on VRC4171 && PCMCIA
+
 config PCMCIA_VRC4173
 	tristate "NEC VRC4173 CARDU support"
 	depends on CPU_VR41XX && PCI && PCMCIA
diff -urN -X dontdiff linux-orig/drivers/pcmcia/Makefile linux/drivers/pcmcia/Makefile
--- linux-orig/drivers/pcmcia/Makefile	Fri Jan 16 01:21:24 2004
+++ linux/drivers/pcmcia/Makefile	Fri Jan 16 08:05:00 2004
@@ -11,6 +11,7 @@
 obj-$(CONFIG_HD64465_PCMCIA)		+= hd64465_ss.o
 obj-$(CONFIG_PCMCIA_SA1100)		+= sa1100_cs.o
 obj-$(CONFIG_PCMCIA_SA1111)		+= sa1111_cs.o
+obj-$(CONFIG_PCMCIA_VRC4171)		+= vrc4171_card.o
 obj-$(CONFIG_PCMCIA_VRC4173)		+= vrc4173_cardu.o
 
 pcmcia_core-objs-y				:= cistpl.o rsrc_mgr.o bulkmem.o cs.o
diff -urN -X dontdiff linux-orig/drivers/pcmcia/vrc4171_card.c linux/drivers/pcmcia/vrc4171_card.c
--- linux-orig/drivers/pcmcia/vrc4171_card.c	Thu Jan  1 09:00:00 1970
+++ linux/drivers/pcmcia/vrc4171_card.c	Fri Jan 16 08:05:01 2004
@@ -0,0 +1,885 @@
+/*
+ * vrc4171_card.c, NEC VRC4171 Card Controller driver for Socket Services.
+ *
+ * Copyright (C) 2003  Yoichi Yuasa <yuasa@hh.iij4u.or.jp>
+ *
+ *  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.
+ *
+ *  This program is distributed in the hope that it will be useful,
+ *  but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *  GNU General Public License for more details.
+ *
+ *  You should have received a copy of the GNU General Public License
+ *  along with this program; if not, write to the Free Software
+ *  Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
+ */
+#include <linux/init.h>
+#include <linux/ioport.h>
+#include <linux/irq.h>
+#include <linux/module.h>
+#include <linux/spinlock.h>
+#include <linux/sched.h>
+#include <linux/types.h>
+
+#include <asm/io.h>
+#include <asm/vr41xx/vrc4171.h>
+
+#include <pcmcia/ss.h>
+
+#include "i82365.h"
+
+MODULE_DESCRIPTION("NEC VRC4171 Card Controllers driver for Socket Services");
+MODULE_AUTHOR("Yoichi Yuasa <yuasa@hh.iij4u.or.jp>");
+MODULE_LICENSE("GPL");
+
+#define CARD_MAX_SLOTS		2
+#define CARD_SLOTA		0
+#define CARD_SLOTB		1
+#define CARD_SLOTB_OFFSET	0x40
+
+#define CARD_MEM_START		0x10000000
+#define CARD_MEM_END		0x13ffffff
+#define CARD_MAX_MEM_OFFSET	0x3ffffff
+#define CARD_MAX_MEM_SPEED	1000
+
+#define CARD_CONTROLLER_INDEX	0x03e0
+#define CARD_CONTROLLER_DATA	0x03e1
+#define CARD_CONTROLLER_SIZE	2
+ /* Power register */
+  #define VPP_GET_VCC		0x01
+  #define POWER_ENABLE		0x10
+ #define CARD_VOLTAGE_SENSE	0x1f
+  #define VCC_3VORXV_CAPABLE	0x00
+  #define VCC_XV_ONLY		0x01
+  #define VCC_3V_CAPABLE	0x02
+  #define VCC_5V_ONLY		0x03
+ #define CARD_VOLTAGE_SELECT	0x2f
+  #define VCC_3V		0x01
+  #define VCC_5V		0x00
+  #define VCC_XV		0x02
+  #define VCC_STATUS_3V		0x02
+  #define VCC_STATUS_5V		0x01
+  #define VCC_STATUS_XV		0x03
+ #define GLOBAL_CONTROL		0x1e
+  #define EXWRBK		0x04
+  #define IRQPM_EN		0x08
+  #define CLRPMIRQ		0x10
+
+#define IO_MAX_MAPS	2
+#define MEM_MAX_MAPS	5
+
+enum {
+	SLOTB_PROBE = 0,
+	SLOTB_NOPROBE_IO,
+	SLOTB_NOPROBE_MEM,
+	SLOTB_NOPROBE_ALL
+};
+
+typedef struct vrc4171_socket {
+	int noprobe;
+	void (*handler)(void *, unsigned int);
+	void *info;
+	socket_cap_t cap;
+	spinlock_t event_lock;
+	uint16_t events;
+	struct socket_info_t *pcmcia_socket;
+	struct work_struct tq_work;
+	char name[24];
+	int csc_irq;
+	int io_irq;
+} vrc4171_socket_t;
+
+static vrc4171_socket_t vrc4171_sockets[CARD_MAX_SLOTS];
+static int vrc4171_slotb = SLOTB_IS_NONE;
+static unsigned int vrc4171_irq;
+static uint16_t vrc4171_irq_mask = 0xdeb8;
+
+extern struct socket_info_t *pcmcia_register_socket(int slot,
+                                                    struct pccard_operations *vtable,
+                                                    int use_bus_pm);
+extern void pcmcia_unregister_socket(struct socket_info_t *s);
+
+static inline uint8_t exca_read_byte(int slot, uint8_t index)
+{
+	if (slot == CARD_SLOTB)
+		index += CARD_SLOTB_OFFSET;
+
+	outb(index, CARD_CONTROLLER_INDEX);
+	return inb(CARD_CONTROLLER_DATA);
+}
+
+static inline uint16_t exca_read_word(int slot, uint8_t index)
+{
+	uint16_t data;
+
+	if (slot == CARD_SLOTB)
+		index += CARD_SLOTB_OFFSET;
+
+	outb(index++, CARD_CONTROLLER_INDEX);
+	data = inb(CARD_CONTROLLER_DATA);
+
+	outb(index, CARD_CONTROLLER_INDEX);
+	data |= ((uint16_t)inb(CARD_CONTROLLER_DATA)) << 8;
+
+	return data;
+}
+
+static inline uint8_t exca_write_byte(int slot, uint8_t index, uint8_t data)
+{
+	if (slot == CARD_SLOTB)
+		index += CARD_SLOTB_OFFSET;
+
+	outb(index, CARD_CONTROLLER_INDEX);
+	outb(data, CARD_CONTROLLER_DATA);
+
+	return data;
+}
+
+static inline uint16_t exca_write_word(int slot, uint8_t index, uint16_t data)
+{
+	if (slot == CARD_SLOTB)
+		index += CARD_SLOTB_OFFSET;
+
+	outb(index++, CARD_CONTROLLER_INDEX);
+	outb(data, CARD_CONTROLLER_DATA);
+
+	outb(index, CARD_CONTROLLER_INDEX);
+	outb((uint8_t)(data >> 8), CARD_CONTROLLER_DATA);
+
+	return data;
+}
+
+static inline int search_nonuse_irq(void)
+{
+	int i;
+
+	for (i = 0; i < 16; i++) {
+		if (vrc4171_irq_mask & (1 << i)) {
+			vrc4171_irq_mask &= ~(1 << i);
+			return i;
+		}
+	}
+
+	return -1;
+}
+
+static int pccard_init(unsigned int slot)
+{
+	vrc4171_socket_t *socket = &vrc4171_sockets[slot];
+
+	socket->cap.features |= SS_CAP_PCCARD | SS_CAP_PAGE_REGS;
+	socket->cap.irq_mask = 0;
+	socket->cap.pci_irq = vrc4171_irq;
+	socket->cap.map_size = 0x1000;
+	socket->events = 0;
+	spin_lock_init(socket->event_lock);
+	socket->csc_irq = search_nonuse_irq();
+	socket->io_irq = search_nonuse_irq();
+
+	return 0;
+}
+
+static int pccard_suspend(unsigned int slot)
+{
+	return -EINVAL;
+}
+
+static int pccard_register_callback(unsigned int slot,
+                                    void (*handler)(void *, unsigned int),
+                                    void *info)
+{
+	vrc4171_socket_t *socket;
+
+	if (slot >= CARD_MAX_SLOTS)
+		return -EINVAL;
+
+	socket = &vrc4171_sockets[slot];
+
+	socket->handler = handler;
+	socket->info = info;
+
+	if (handler)
+		MOD_INC_USE_COUNT;
+	else
+		MOD_DEC_USE_COUNT;
+
+	return 0;
+}
+
+static int pccard_inquire_socket(unsigned int slot, socket_cap_t *cap)
+{
+	vrc4171_socket_t *socket;
+
+	if (slot >= CARD_MAX_SLOTS || cap == NULL)
+		return -EINVAL;
+
+	socket = &vrc4171_sockets[slot];
+
+	*cap = socket->cap;
+
+	return 0;
+}
+
+static int pccard_get_status(unsigned int slot, u_int *value)
+{
+	uint8_t status, sense;
+	u_int val = 0;
+
+	if (slot >= CARD_MAX_SLOTS || value == NULL)
+		return -EINVAL;
+
+	status = exca_read_byte(slot, I365_STATUS);
+	if (exca_read_byte(slot, I365_INTCTL) & I365_PC_IOCARD) {
+		if (status & I365_CS_STSCHG)
+			val |= SS_STSCHG;
+	} else {
+		if (!(status & I365_CS_BVD1))
+			val |= SS_BATDEAD;
+		else if ((status & (I365_CS_BVD1 | I365_CS_BVD2)) == I365_CS_BVD1)
+			val |= SS_BATWARN;
+	}
+	if ((status & I365_CS_DETECT) == I365_CS_DETECT)
+		val |= SS_DETECT;
+	if (status & I365_CS_WRPROT)
+		val |= SS_WRPROT;
+	if (status & I365_CS_READY)
+		val |= SS_READY;
+	if (status & I365_CS_POWERON)
+		val |= SS_POWERON;
+
+	sense = exca_read_byte(slot, CARD_VOLTAGE_SENSE);
+	switch (sense) {
+	case VCC_3VORXV_CAPABLE:
+		val |= SS_3VCARD | SS_XVCARD;
+		break;
+	case VCC_XV_ONLY:
+		val |= SS_XVCARD;
+		break;
+	case VCC_3V_CAPABLE:
+		val |= SS_3VCARD;
+		break;
+	default:
+		/* 5V only */
+		break;
+	}
+
+	*value = val;
+
+	return 0;
+}
+
+static inline u_char get_Vcc_value(uint8_t voltage)
+{
+	switch (voltage) {
+	case VCC_STATUS_3V:
+		return 33;
+	case VCC_STATUS_5V:
+		return 50;
+	default:
+		break;
+	}
+
+	return 0;
+}
+
+static inline u_char get_Vpp_value(uint8_t power, u_char Vcc)
+{
+	if ((power & 0x03) == 0x01 || (power & 0x03) == 0x02)
+		return Vcc;
+
+	return 0;
+}
+
+static int pccard_get_socket(unsigned int slot, socket_state_t *state)
+{
+	vrc4171_socket_t *socket;
+	uint8_t power, voltage, control, cscint;
+
+	if (slot >= CARD_MAX_SLOTS || state == NULL)
+		return -EINVAL;
+
+	socket = &vrc4171_sockets[slot];
+
+	power = exca_read_byte(slot, I365_POWER);
+	voltage = exca_read_byte(slot, CARD_VOLTAGE_SELECT);
+
+	state->Vcc = get_Vcc_value(voltage);
+	state->Vpp = get_Vpp_value(power, state->Vcc);
+
+	state->flags = 0;
+	if (power & POWER_ENABLE)
+		state->flags |= SS_PWR_AUTO;
+	if (power & I365_PWR_OUT)
+		state->flags |= SS_OUTPUT_ENA;
+
+	control = exca_read_byte(slot, I365_INTCTL);
+	if (control & I365_PC_IOCARD)
+		state->flags |= SS_IOCARD;
+	if (!(control & I365_PC_RESET))
+		state->flags |= SS_RESET;
+
+        cscint = exca_read_byte(slot, I365_CSCINT);
+	state->csc_mask = 0;
+	if (state->flags & SS_IOCARD) {
+		if (cscint & I365_CSC_STSCHG)
+			state->flags |= SS_STSCHG;
+	} else {
+		if (cscint & I365_CSC_BVD1)  
+			state->csc_mask |= SS_BATDEAD;
+		if (cscint & I365_CSC_BVD2)  
+			state->csc_mask |= SS_BATWARN;
+	}
+	if (cscint & I365_CSC_READY)
+		state->csc_mask |= SS_READY;
+	if (cscint & I365_CSC_DETECT)
+		state->csc_mask |= SS_DETECT;
+
+	return 0;
+}
+
+static inline uint8_t set_Vcc_value(u_char Vcc)
+{
+	switch (Vcc) {
+	case 33:
+		return VCC_3V;
+	case 50:
+		return VCC_5V;
+	}
+
+	/* Small voltage is chosen for safety. */
+	return VCC_3V;
+}
+
+static int pccard_set_socket(unsigned int slot, socket_state_t *state)
+{
+	vrc4171_socket_t *socket;
+	uint8_t voltage, power, control, cscint;
+
+	if (slot >= CARD_MAX_SLOTS ||
+	    (state->Vpp != state->Vcc && state->Vpp != 0) ||
+	    (state->Vcc != 50 && state->Vcc != 33 && state->Vcc != 0))
+		return -EINVAL;
+
+	socket = &vrc4171_sockets[slot];
+
+	spin_lock_irq(&socket->event_lock);
+
+	voltage = set_Vcc_value(state->Vcc);
+	exca_write_byte(slot, CARD_VOLTAGE_SELECT, voltage);
+
+	power = POWER_ENABLE;
+	if (state->Vpp == state->Vcc)
+		power |= VPP_GET_VCC;
+	if (state->flags & SS_OUTPUT_ENA)
+		power |= I365_PWR_OUT;
+	exca_write_byte(slot, I365_POWER, power);
+
+	control = 0;
+	if (state->io_irq != 0)
+		control |= socket->io_irq;
+	if (state->flags & SS_IOCARD)
+		control |= I365_PC_IOCARD;
+	if (state->flags & SS_RESET)
+		control	&= ~I365_PC_RESET;
+	else
+		control |= I365_PC_RESET;
+	exca_write_byte(slot, I365_INTCTL, control);
+
+        cscint = 0;
+        exca_write_byte(slot, I365_CSCINT, cscint);
+	exca_read_byte(slot, I365_CSC);	/* clear CardStatus change */
+	if (state->csc_mask != 0)
+		cscint |= socket->csc_irq << 8;
+	if (state->flags & SS_IOCARD) {
+		if (state->csc_mask & SS_STSCHG)
+			cscint |= I365_CSC_STSCHG;
+	} else {
+		if (state->csc_mask & SS_BATDEAD)
+			cscint |= I365_CSC_BVD1;
+		if (state->csc_mask & SS_BATWARN)
+			cscint |= I365_CSC_BVD2;
+	}
+	if (state->csc_mask & SS_READY)
+		cscint |= I365_CSC_READY;
+	if (state->csc_mask & SS_DETECT)
+		cscint |= I365_CSC_DETECT;
+        exca_write_byte(slot, I365_CSCINT, cscint);
+
+	spin_unlock_irq(&socket->event_lock);
+
+	return 0;
+}
+
+static int pccard_get_io_map(unsigned int slot, struct pccard_io_map *io)
+{
+	vrc4171_socket_t *socket;
+	uint8_t ioctl, addrwin;
+	u_char map;
+
+	if (slot >= CARD_MAX_SLOTS || io == NULL ||
+	    io->map >= IO_MAX_MAPS)
+		return -EINVAL;
+
+	socket = &vrc4171_sockets[slot];
+	map = io->map;
+
+	io->start = exca_read_word(slot, I365_IO(map)+I365_W_START);
+	io->stop = exca_read_word(slot, I365_IO(map)+I365_W_STOP);
+
+	ioctl = exca_read_byte(slot, I365_IOCTL);
+	if (io->flags & I365_IOCTL_WAIT(map))
+		io->speed = 1;
+	else
+		io->speed = 0;
+
+	io->flags = 0;
+	if (ioctl & I365_IOCTL_16BIT(map))
+		io->flags |= MAP_16BIT;
+	if (ioctl & I365_IOCTL_IOCS16(map))
+		io->flags |= MAP_AUTOSZ;
+	if (ioctl & I365_IOCTL_0WS(map))
+		io->flags |= MAP_0WS;
+
+	addrwin = exca_read_byte(slot, I365_ADDRWIN);
+	if (addrwin & I365_ENA_IO(map))
+		io->flags |= MAP_ACTIVE;
+
+	return 0;
+}
+
+static int pccard_set_io_map(unsigned int slot, struct pccard_io_map *io)
+{
+	vrc4171_socket_t *socket;
+	uint8_t ioctl, addrwin;
+	u_char map;
+
+	if (slot >= CARD_MAX_SLOTS ||
+	    io == NULL || io->map >= IO_MAX_MAPS ||
+	    io->start > 0xffff || io->stop > 0xffff || io->start > io->stop)
+		return -EINVAL;
+
+	socket = &vrc4171_sockets[slot];
+	map = io->map;
+
+	addrwin = exca_read_byte(slot, I365_ADDRWIN);
+	if (addrwin & I365_ENA_IO(map)) {
+		addrwin &= ~I365_ENA_IO(map);
+		exca_write_byte(slot, I365_ADDRWIN, addrwin);
+	}
+
+	exca_write_word(slot, I365_IO(map)+I365_W_START, io->start);
+	exca_write_word(slot, I365_IO(map)+I365_W_STOP, io->stop);
+
+	ioctl = 0;
+	if (io->speed > 0)
+		ioctl |= I365_IOCTL_WAIT(map);
+	if (io->flags & MAP_16BIT)
+		ioctl |= I365_IOCTL_16BIT(map);
+	if (io->flags & MAP_AUTOSZ)
+		ioctl |= I365_IOCTL_IOCS16(map);
+	if (io->flags & MAP_0WS)
+		ioctl |= I365_IOCTL_0WS(map);
+	exca_write_byte(slot, I365_IOCTL, ioctl);
+
+	if (io->flags & MAP_ACTIVE) {
+		addrwin |= I365_ENA_IO(map);
+		exca_write_byte(slot, I365_ADDRWIN, addrwin);
+	}
+
+	return 0;
+}
+
+static int pccard_get_mem_map(unsigned int slot, struct pccard_mem_map *mem)
+{
+	vrc4171_socket_t *socket;
+	uint8_t addrwin;
+	u_long start, stop;
+	u_int offset;
+	u_char map;
+
+	if (slot >= CARD_MAX_SLOTS || mem == NULL || mem->map >= MEM_MAX_MAPS)
+		return -EINVAL;
+
+	socket = &vrc4171_sockets[slot];
+	map = mem->map;
+
+	mem->flags = 0;
+	mem->speed = 0;
+
+	addrwin = exca_read_byte(slot, I365_ADDRWIN);
+	if (addrwin & I365_ENA_MEM(map))
+		mem->flags |= MAP_ACTIVE;
+
+	start = exca_read_word(slot, I365_MEM(map)+I365_W_START);
+	if (start & I365_MEM_16BIT)
+		mem->flags |= MAP_16BIT;
+	mem->sys_start = (start & 0x3fffUL) << 12;
+
+	stop = exca_read_word(slot, I365_MEM(map)+I365_W_STOP);
+	if (start & I365_MEM_WS0)
+		mem->speed += 1;
+	if (start & I365_MEM_WS1)
+		mem->speed += 2;
+	mem->sys_stop = ((stop & 0x3fffUL) << 12) + 0xfffUL;
+
+	offset = exca_read_word(slot, I365_MEM(map)+I365_W_OFF);
+	if (offset & I365_MEM_REG)
+		mem->flags |= MAP_ATTRIB;
+	if (offset & I365_MEM_WRPROT)
+		mem->flags |= MAP_WRPROT;
+	mem->card_start = (offset & 0x3fffUL) << 12;
+
+	mem->sys_start += CARD_MEM_START;
+	mem->sys_stop += CARD_MEM_START;
+
+	return 0;
+}
+
+static int pccard_set_mem_map(unsigned int slot, struct pccard_mem_map *mem)
+{
+	vrc4171_socket_t *socket;
+	uint16_t start, stop, offset;
+	uint8_t addrwin;
+	u_char map;
+
+	if (slot >= CARD_MAX_SLOTS ||
+	    mem == NULL || mem->map >= MEM_MAX_MAPS ||
+	    mem->sys_start < CARD_MEM_START || mem->sys_start > CARD_MEM_END ||
+	    mem->sys_stop < CARD_MEM_START || mem->sys_stop > CARD_MEM_END ||
+	    mem->sys_start > mem->sys_stop ||
+	    mem->card_start > CARD_MAX_MEM_OFFSET ||
+	    mem->speed > CARD_MAX_MEM_SPEED)
+		return -EINVAL;
+
+	socket = &vrc4171_sockets[slot];
+	map = mem->map;
+
+	addrwin = exca_read_byte(slot, I365_ADDRWIN);
+	if (addrwin & I365_ENA_MEM(map)) {
+		addrwin &= ~I365_ENA_MEM(map);
+		exca_write_byte(slot, I365_ADDRWIN, addrwin);
+	}
+
+	start = (mem->sys_start >> 12) & 0x3fff;
+	if (mem->flags & MAP_16BIT)
+		start |= I365_MEM_16BIT;
+	exca_write_word(slot, I365_MEM(map)+I365_W_START, start);
+
+	stop = (mem->sys_stop >> 12) & 0x3fff;
+	switch (mem->speed) {
+	case 0:
+		break;
+	case 1:
+		stop |= I365_MEM_WS0;
+		break;
+	case 2:
+		stop |= I365_MEM_WS1;
+		break;
+	default:
+		stop |= I365_MEM_WS0 | I365_MEM_WS1;
+		break;
+	}
+	exca_write_word(slot, I365_MEM(map)+I365_W_STOP, stop);
+
+	offset = (mem->card_start >> 12) & 0x3fff;
+	if (mem->flags & MAP_ATTRIB)
+		offset |= I365_MEM_REG;
+	if (mem->flags & MAP_WRPROT)
+		offset |= I365_MEM_WRPROT;
+	exca_write_word(slot, I365_MEM(map)+I365_W_OFF, offset);
+
+	if (mem->flags & MAP_ACTIVE) {
+		addrwin |= I365_ENA_MEM(map);
+		exca_write_byte(slot, I365_ADDRWIN, addrwin);
+	}
+
+	return 0;
+}
+
+static void pccard_proc_setup(unsigned int slot, struct proc_dir_entry *base)
+{          
+}
+
+static struct pccard_operations vrc4171_pccard_operations = {
+	.init			= pccard_init,
+	.suspend		= pccard_suspend,
+	.register_callback	= pccard_register_callback,
+	.inquire_socket		= pccard_inquire_socket,
+	.get_status		= pccard_get_status,
+	.get_socket		= pccard_get_socket,
+	.set_socket		= pccard_set_socket,
+	.get_io_map		= pccard_get_io_map,
+	.set_io_map		= pccard_set_io_map,
+	.get_mem_map		= pccard_get_mem_map,
+	.set_mem_map		= pccard_set_mem_map,
+	.proc_setup		= pccard_proc_setup,
+};
+
+static void pccard_bh(void *data)
+{
+	vrc4171_socket_t *socket = (vrc4171_socket_t *)data;
+	uint16_t events;
+
+	spin_lock_irq(&socket->event_lock);
+	events = socket->events;
+	socket->events = 0;
+	spin_unlock_irq(&socket->event_lock);
+ 
+	if (socket->handler)
+		socket->handler(socket->info, events);
+}
+
+static inline uint16_t get_events(int slot)
+{
+	uint16_t events = 0;
+	uint8_t status, csc;
+
+	status = exca_read_byte(slot, I365_STATUS);
+	csc = exca_read_byte(slot, I365_CSC);
+
+	if (exca_read_byte(slot, I365_INTCTL) & I365_PC_IOCARD) {
+		if ((csc & I365_CSC_STSCHG) && (status & I365_CS_STSCHG))
+			events |= SS_STSCHG;
+	} else {
+		if (csc & (I365_CSC_BVD1 | I365_CSC_BVD2)) {
+			if (!(status & I365_CS_BVD1))
+				events |= SS_BATDEAD;
+			else if ((status & (I365_CS_BVD1 | I365_CS_BVD2)) == I365_CS_BVD1)
+				events |= SS_BATWARN;
+		}
+	}
+	if ((csc & I365_CSC_READY) && (status & I365_CS_READY))
+		events |= SS_READY;
+	if ((csc & I365_CSC_DETECT) && ((status & I365_CS_DETECT) == I365_CS_DETECT))
+		events |= SS_DETECT;
+
+	return events;
+}
+
+static void pccard_status_change(int slot, vrc4171_socket_t *socket)
+{
+	uint16_t events;
+
+	INIT_WORK(&socket->tq_work, pccard_bh, socket);
+
+	events = get_events(slot);
+	if (events) {
+		spin_lock(&socket->event_lock);
+		socket->events |= events;
+		spin_unlock(&socket->event_lock);
+		schedule_work(&socket->tq_task);
+	}
+}
+
+static void pccard_interrupt(int irq, void *dev_id, struct pt_regs *regs)
+{
+	vrc4171_socket_t *socket;
+	uint16_t status;
+
+	status = vrc4171_get_irq_status();
+	if (status & IRQ_A) {
+		socket = &vrc4171_sockets[CARD_SLOTA];
+		if (socket->noprobe == SLOTB_PROBE) {
+			if (status & (1 << socket->csc_irq))
+				pccard_status_change(CARD_SLOTA, socket);
+		}
+	}
+
+	if (status & IRQ_B) {
+		socket = &vrc4171_sockets[CARD_SLOTB];
+		if (socket->noprobe == SLOTB_PROBE) {
+			if (status & (1 << socket->csc_irq))
+				pccard_status_change(CARD_SLOTB, socket);
+		}
+	}
+}
+
+static inline void reserve_using_irq(int slot)
+{
+	unsigned int irq;
+
+	irq = exca_read_byte(slot, I365_INTCTL);
+	irq &= 0x0f;
+	vrc4171_irq_mask &= ~(1 << irq);
+
+	irq = exca_read_byte(slot, I365_CSCINT);
+	irq = (irq & 0xf0) >> 4;
+	vrc4171_irq_mask &= ~(1 << irq);
+}
+
+static int __devinit vrc4171_add_socket(int slot)
+{
+	vrc4171_socket_t *socket;
+
+	if (slot >= CARD_MAX_SLOTS)
+		return -EINVAL;
+
+	socket = &vrc4171_sockets[slot];
+	if (socket->noprobe != SLOTB_PROBE) {
+		uint8_t addrwin;
+
+		switch (socket->noprobe) {
+		case SLOTB_NOPROBE_MEM:
+			addrwin = exca_read_byte(slot, I365_ADDRWIN);
+			addrwin &= 0x1f;
+			exca_write_byte(slot, I365_ADDRWIN, addrwin);
+			break;
+		case SLOTB_NOPROBE_IO:
+			addrwin = exca_read_byte(slot, I365_ADDRWIN);
+			addrwin &= 0xc0;
+			exca_write_byte(slot, I365_ADDRWIN, addrwin);
+			break;
+		default:
+			break;
+		}
+
+		reserve_using_irq(slot);
+
+		return 0;
+	}
+
+	sprintf(socket->name, "NEC VRC4171 Card Slot %1c", 'A' + slot);
+
+	socket->pcmcia_socket = pcmcia_register_socket(slot, &vrc4171_pccard_operations, 1);
+	if (socket->pcmcia_socket == NULL)
+		return -ENOMEM;
+
+	exca_write_byte(slot, I365_ADDRWIN, 0);
+
+	exca_write_byte(slot, GLOBAL_CONTROL, 0);
+
+	return 0;
+}
+
+static void vrc4171_remove_socket(int slot)
+{
+	vrc4171_socket_t *socket;
+
+	if (slot >= CARD_MAX_SLOTS)
+		return;
+
+	socket = &vrc4171_sockets[slot];
+
+	if (socket->pcmcia_socket != NULL) {
+		pcmcia_unregister_socket(socket->pcmcia_socket);
+		socket->pcmcia_socket = NULL;
+	}
+}
+
+static int __devinit vrc4171_card_setup(char *options)
+{
+	if (options == NULL || *options == '\0')
+		return 0;
+
+	if (strncmp(options, "irq:", 4) == 0) {
+		int irq;
+		options += 4;
+		irq = simple_strtoul(options, &options, 0);
+		if (irq >= 0 && irq < NR_IRQS)
+			vrc4171_irq = irq;
+
+		if (*options != ',')
+			return 0;
+		options++;
+	}
+
+	if (strncmp(options, "slota:", 6) == 0) {
+		options += 6;
+		if (*options != '\0') {
+			if (strncmp(options, "noprobe", 7) == 0) {
+				vrc4171_sockets[CARD_SLOTA].noprobe = 1;
+				options += 7;
+			}
+
+			if (*options != ',')
+				return 0;
+			options++;
+		} else
+			return 0;
+
+	}
+
+	if (strncmp(options, "slotb:", 6) == 0) {
+		options += 6;
+		if (*options != '\0') {
+			if (strncmp(options, "pccard", 6) == 0) {
+				vrc4171_slotb = SLOTB_IS_PCCARD;
+				options += 6;
+			} else if (strncmp(options, "cf", 2) == 0) {
+				vrc4171_slotb = SLOTB_IS_CF;
+				options += 2;
+			} else if (strncmp(options, "flashrom", 8) == 0) {
+				vrc4171_slotb = SLOTB_IS_FLASHROM;
+				options += 8;
+			} else if (strncmp(options, "none", 4) == 0) {
+				vrc4171_slotb = SLOTB_IS_NONE;
+				options += 4;
+			}
+
+			if (*options != ',')
+				return 0;
+			options++;
+
+			if ( strncmp(options, "memnoprobe", 10) == 0)
+				vrc4171_sockets[CARD_SLOTB].noprobe = SLOTB_NOPROBE_MEM;
+			if ( strncmp(options, "ionoprobe", 9) == 0)
+				vrc4171_sockets[CARD_SLOTB].noprobe = SLOTB_NOPROBE_IO;
+			if ( strncmp(options, "noprobe", 7) == 0)
+				vrc4171_sockets[CARD_SLOTB].noprobe = SLOTB_NOPROBE_ALL;
+		}
+	}
+
+	return 0;
+}
+
+__setup("vrc4171_card=", vrc4171_card_setup);
+
+static int __devinit vrc4171_card_init(void)
+{
+	int retval, slot;
+
+	vrc4171_set_multifunction_pin(vrc4171_slotb);
+
+	if (request_region(CARD_CONTROLLER_INDEX, CARD_CONTROLLER_SIZE,
+	                       "NEC VRC4171 Card Controller") == NULL)
+		return -EBUSY;
+
+	for (slot = 0; slot < CARD_MAX_SLOTS; slot++) {
+		if (slot == CARD_SLOTB && vrc4171_slotb == SLOTB_IS_NONE)
+			break;
+
+		retval = vrc4171_add_socket(slot);
+		if (retval != 0)
+			return retval;
+	}
+
+	retval = request_irq(vrc4171_irq, pccard_interrupt, SA_SHIRQ,
+	                     "NEC VRC4171 Card Controller", vrc4171_sockets);
+	if (retval < 0) {
+		for (slot = 0; slot < CARD_MAX_SLOTS; slot++)
+			vrc4171_remove_socket(slot);
+
+		return retval;
+	}
+
+	printk(KERN_INFO "NEC VRC4171 Card Controller, connected to IRQ %d\n", vrc4171_irq);
+
+	return 0;
+}
+
+static void __devexit vrc4171_card_exit(void)
+{
+	int slot;
+
+	for (slot = 0; slot < CARD_MAX_SLOTS; slot++)
+		vrc4171_remove_socket(slot);
+
+	release_region(CARD_CONTROLLER_INDEX, CARD_CONTROLLER_SIZE);
+}
+
+module_init(vrc4171_card_init);
+module_exit(vrc4171_card_exit);

From kumba@gentoo.org Fri Jan 16 01:02:01 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 16 Jan 2004 01:02:01 +0000 (GMT)
Received: from sccrmhc12.comcast.net ([IPv6:::ffff:204.127.202.56]:28041 "EHLO
	sccrmhc12.comcast.net") by linux-mips.org with ESMTP
	id <S8224991AbUAPBCB>; Fri, 16 Jan 2004 01:02:01 +0000
Received: from gentoo.org (pcp04939029pcs.waldrf01.md.comcast.net[68.48.72.58])
          by comcast.net (sccrmhc12) with SMTP
          id <200401160101540120029lpre>
          (Authid: kumba12345);
          Fri, 16 Jan 2004 01:01:54 +0000
Message-ID: <4007386F.80207@gentoo.org>
Date: Thu, 15 Jan 2004 20:03:43 -0500
From: Kumba <kumba@gentoo.org>
Reply-To: kumba@gentoo.org
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: linux-mips@linux-mips.org
Subject: Re: Current 2.4 CVS (2.4.24-pre2) doesn't boot on SGI Indy
References: <20040115141427.GA28546@icm.edu.pl> <Pine.LNX.4.21.0401151816540.3511-100000@www.marty44.net> <20040115231735.GA6619@icm.edu.pl>
In-Reply-To: <20040115231735.GA6619@icm.edu.pl>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Return-Path: <kumba@gentoo.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: 3992
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: kumba@gentoo.org
Precedence: bulk
X-list: linux-mips

Dominik 'Rathann' Mierzejewski wrote:
> Well, it appears something has been broken during the last 2 months.
> Good to know I'm not alone in this.

I have a 2.4.23 kernel I used from a 20031128 CVS snapshot that works 
fine, but a 2.4.23 20031214 snapshot didn't work (on an R4400@250MHz 
I2), so likely the problem was introduced sometime between those dates. 
  Might help for tracking down the issue.


--Kumba

-- 
"Such is oft the course of deeds that move the wheels of the world: 
small hands do them because they must, while the eyes of the great are 
elsewhere."  --Elrond


From jsun@mvista.com Fri Jan 16 01:26:05 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 16 Jan 2004 01:26:05 +0000 (GMT)
Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:10997 "EHLO
	orion.mvista.com") by linux-mips.org with ESMTP id <S8225489AbUAPB0F>;
	Fri, 16 Jan 2004 01:26:05 +0000
Received: (from jsun@localhost)
	by orion.mvista.com (8.11.6/8.11.6) id i0G1Q2h30472;
	Thu, 15 Jan 2004 17:26:02 -0800
Date: Thu, 15 Jan 2004 17:26:02 -0800
From: Jun Sun <jsun@mvista.com>
To: Kumba <kumba@gentoo.org>
Cc: linux-mips@linux-mips.org, jsun@mvista.com
Subject: Re: Current 2.4 CVS (2.4.24-pre2) doesn't boot on SGI Indy
Message-ID: <20040115172602.H18368@mvista.com>
References: <20040115141427.GA28546@icm.edu.pl> <Pine.LNX.4.21.0401151816540.3511-100000@www.marty44.net> <20040115231735.GA6619@icm.edu.pl> <4007386F.80207@gentoo.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <4007386F.80207@gentoo.org>; from kumba@gentoo.org on Thu, Jan 15, 2004 at 08:03:43PM -0500
Return-Path: <jsun@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: 3993
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 15, 2004 at 08:03:43PM -0500, Kumba wrote:
> Dominik 'Rathann' Mierzejewski wrote:
> > Well, it appears something has been broken during the last 2 months.
> > Good to know I'm not alone in this.
> 
> I have a 2.4.23 kernel I used from a 20031128 CVS snapshot that works 
> fine, but a 2.4.23 20031214 snapshot didn't work (on an R4400@250MHz 
> I2), so likely the problem was introduced sometime between those dates. 
>   Might help for tracking down the issue.
> 

If you like to know what changes had been made during that period,
you may find my tracking tool useful.  Just select the 2.4 branch
and enter the date range, it will give you all the changes in 
patch format.  So you can also find out who is the lamer! :)

http://linux.junsun.net/xcvs/xcvs_linux_mips

Please be gentle to my little poor server.  This really should be
hosted on linux-mips.org or some other real servers.  Any volunteers?

Jun

From suresh@mistralsoftware.com Fri Jan 16 07:25:24 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 16 Jan 2004 07:25:25 +0000 (GMT)
Received: from mistral-243-146-ban.mistralsoftware.com ([IPv6:::ffff:203.196.146.243]:9795
	"EHLO Mistralsoftware.com") by linux-mips.org with ESMTP
	id <S8224954AbUAPHZY>; Fri, 16 Jan 2004 07:25:24 +0000
Received: from mistralsoftware.com ([192.168.13.230])
	(authenticated user suresh@mistralsoftware.com)
	by mistralsoftware.com (mistralsoftware.com [192.168.10.12])
	(MDaemon.PRO.v6.8.5.R)
	with ESMTP id 40-md50000000011.tmp
	for <linux-mips@linux-mips.org>; Fri, 16 Jan 2004 13:11:46 +0530
Message-ID: <40079391.7080301@mistralsoftware.com>
Date: Fri, 16 Jan 2004 13:02:33 +0530
From: "Suresh. R" <suresh@mistralsoftware.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: linux-mips@linux-mips.org
Subject: VR4131 - MQ1132 - UPD63335
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Authenticated-Sender: suresh@mistralsoftware.com
X-Spam-Processed: mistralsoftware.com, Fri, 16 Jan 2004 13:11:46 +0530
	(not processed: message from valid local sender)
X-MDRemoteIP: 192.168.13.230
X-Return-Path: suresh@mistralsoftware.com
X-MDaemon-Deliver-To: linux-mips@linux-mips.org
Return-Path: <suresh@mistralsoftware.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: 3994
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: suresh@mistralsoftware.com
Precedence: bulk
X-list: linux-mips

Hi,
   This might be a very basic question, but I am very new to this field. 
So please help me.

I am writing a linux device driver for UPD63335 audio codec. Its 
controlled through the MQ1132 co-processor. The VR4131 is the processor. 
The memory of MQ1132 is mapped to the processor memory in Kseg1 (0xA000 
0000 onwards) which the manual says is TLB Unmapped region. Now my 
question is is it necessary to map this region before using it in Linux. 
Actually I have WinCE code for my reference. In that code the programmer 
is mapping the region using Virtual Cpoy and Virtual Alloc. Is it 
necessary to do that or Can I directly address the memory locatoin.

Please help

Thanks in advance

Regards
Suresh


From geert@linux-m68k.org Fri Jan 16 09:49:04 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 16 Jan 2004 09:49:05 +0000 (GMT)
Received: from witte.sonytel.be ([IPv6:::ffff:80.88.33.193]:156 "EHLO
	witte.sonytel.be") by linux-mips.org with ESMTP id <S8224954AbUAPJtE>;
	Fri, 16 Jan 2004 09:49:04 +0000
Received: from waterleaf.sonytel.be (localhost [127.0.0.1])
	by witte.sonytel.be (8.12.10/8.12.10) with ESMTP id i0G9mxoi022181;
	Fri, 16 Jan 2004 10:49:00 +0100 (MET)
Date: Fri, 16 Jan 2004 10:49:00 +0100 (MET)
From: Geert Uytterhoeven <geert@linux-m68k.org>
To: "Suresh. R" <suresh@mistralsoftware.com>
cc: Linux/MIPS Development <linux-mips@linux-mips.org>
Subject: Re: VR4131 - MQ1132 - UPD63335
In-Reply-To: <40079391.7080301@mistralsoftware.com>
Message-ID: <Pine.GSO.4.58.0401161047480.14892@waterleaf.sonytel.be>
References: <40079391.7080301@mistralsoftware.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <geert@linux-m68k.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: 3995
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 Fri, 16 Jan 2004, Suresh. R wrote:
> I am writing a linux device driver for UPD63335 audio codec. Its
> controlled through the MQ1132 co-processor. The VR4131 is the processor.
> The memory of MQ1132 is mapped to the processor memory in Kseg1 (0xA000
> 0000 onwards) which the manual says is TLB Unmapped region. Now my
> question is is it necessary to map this region before using it in Linux.
> Actually I have WinCE code for my reference. In that code the programmer
> is mapping the region using Virtual Cpoy and Virtual Alloc. Is it
> necessary to do that or Can I directly address the memory locatoin.

From the Linux kernel, you can access all memory at 0xa0000000 'till 0xbfffffff
directly.

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 kevink@mips.com Fri Jan 16 10:08:20 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 16 Jan 2004 10:08:21 +0000 (GMT)
Received: from ftp.mips.com ([IPv6:::ffff:206.31.31.227]:11143 "EHLO
	mx2.mips.com") by linux-mips.org with ESMTP id <S8224954AbUAPKIU>;
	Fri, 16 Jan 2004 10:08:20 +0000
Received: from newman.mips.com (ns-dmz [206.31.31.225])
	by mx2.mips.com (8.12.10/8.12.10) with ESMTP id i0GA1XX6005084;
	Fri, 16 Jan 2004 02:01:33 -0800 (PST)
Received: from grendel (grendel [192.168.236.16])
	by newman.mips.com (8.9.3/8.9.0) with SMTP id CAA21101;
	Fri, 16 Jan 2004 02:08:10 -0800 (PST)
Message-ID: <014a01c3dc18$c92b74a0$10eca8c0@grendel>
From: "Kevin D. Kissell" <kevink@mips.com>
To: "Suresh. R" <suresh@mistralsoftware.com>,
	<linux-mips@linux-mips.org>
References: <40079391.7080301@mistralsoftware.com>
Subject: Re: VR4131 - MQ1132 - UPD63335
Date: Fri, 16 Jan 2004 11:09:09 +0100
Organization: MIPS Technologies Inc.
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
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: 3996
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

If I recall correctly, WinCE runs drivers and system services in User mode,
so any memory-mapped I/O would need to be set-up explicitly in the virtual 
address space.  As Geert has pointed out, so long as it's in that first 512MB,
a Linux driver running in Kernel mode can access it directly via Kseg1 (or
Kseg0, if you wanted to be able to cache the data).

----- Original Message ----- 
From: "Suresh. R" <suresh@mistralsoftware.com>
To: <linux-mips@linux-mips.org>
Sent: Friday, January 16, 2004 8:32
Subject: VR4131 - MQ1132 - UPD63335


> Hi,
>    This might be a very basic question, but I am very new to this field. 
> So please help me.
> 
> I am writing a linux device driver for UPD63335 audio codec. Its 
> controlled through the MQ1132 co-processor. The VR4131 is the processor. 
> The memory of MQ1132 is mapped to the processor memory in Kseg1 (0xA000 
> 0000 onwards) which the manual says is TLB Unmapped region. Now my 
> question is is it necessary to map this region before using it in Linux. 
> Actually I have WinCE code for my reference. In that code the programmer 
> is mapping the region using Virtual Cpoy and Virtual Alloc. Is it 
> necessary to do that or Can I directly address the memory locatoin.
> 
> Please help
> 
> Thanks in advance
> 
> Regards
> Suresh
> 
> 
> 

From rathann@icm.edu.pl Fri Jan 16 11:51:08 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 16 Jan 2004 11:51:09 +0000 (GMT)
Received: from gw.icm.edu.pl ([IPv6:::ffff:212.87.0.39]:35881 "EHLO
	atol.icm.edu.pl") by linux-mips.org with ESMTP id <S8225507AbUAPLvI>;
	Fri, 16 Jan 2004 11:51:08 +0000
Received: from rekin.icm.edu.pl (rekin.icm.edu.pl [192.168.1.132])
	by atol.icm.edu.pl (8.12.6/8.12.6/rzm-4.6/icm) with ESMTP id i0GBot4p006342
	for <linux-mips@linux-mips.org>; Fri, 16 Jan 2004 12:50:56 +0100 (CET)
Received: from rathann by rekin.icm.edu.pl with local (Exim 3.35 #1 (Debian))
	id 1AhSV3-0004nB-00
	for <linux-mips@linux-mips.org>; Fri, 16 Jan 2004 12:50:53 +0100
Date: Fri, 16 Jan 2004 12:50:53 +0100
From: "Dominik 'Rathann' Mierzejewski" <rathann@icm.edu.pl>
To: linux-mips@linux-mips.org
Subject: Re: Current 2.4 CVS (2.4.24-pre2) doesn't boot on SGI Indy
Message-ID: <20040116115053.GA18099@icm.edu.pl>
Mail-Followup-To: linux-mips@linux-mips.org
References: <20040115141427.GA28546@icm.edu.pl> <Pine.LNX.4.21.0401151816540.3511-100000@www.marty44.net> <20040115231735.GA6619@icm.edu.pl> <4007386F.80207@gentoo.org> <20040115172602.H18368@mvista.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20040115172602.H18368@mvista.com>
User-Agent: Mutt/1.3.28i
Return-Path: <rathann@icm.edu.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: 3997
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: rathann@icm.edu.pl
Precedence: bulk
X-list: linux-mips

On Thu, Jan 15, 2004 at 05:26:02PM -0800, Jun Sun wrote:
> On Thu, Jan 15, 2004 at 08:03:43PM -0500, Kumba wrote:
> > Dominik 'Rathann' Mierzejewski wrote:
[...] 
> > I have a 2.4.23 kernel I used from a 20031128 CVS snapshot that works 
> > fine, but a 2.4.23 20031214 snapshot didn't work (on an R4400@250MHz 
> > I2), so likely the problem was introduced sometime between those dates. 
> >   Might help for tracking down the issue.

Thanks, that'll be useful.

> If you like to know what changes had been made during that period,
> you may find my tracking tool useful.  Just select the 2.4 branch
> and enter the date range, it will give you all the changes in 
> patch format.  So you can also find out who is the lamer! :)
> 
> http://linux.junsun.net/xcvs/xcvs_linux_mips

Excellent tool! Thank you very much. I'll try and identify the offending
patch today.

-- 
Dominik 'Rathann' Mierzejewski <rathann@icm.edu.pl>                                                 
Interdisciplinary Centre for Mathematical and Computational Modelling                               
Warsaw University  |  http://www.icm.edu.pl  |  tel. +48 (22) 5540810                               

From hch@lst.de Fri Jan 16 12:34:00 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 16 Jan 2004 12:34:04 +0000 (GMT)
Received: from verein.lst.de ([IPv6:::ffff:212.34.189.10]:4569 "EHLO
	mail.lst.de") by linux-mips.org with ESMTP id <S8224893AbUAPMeA>;
	Fri, 16 Jan 2004 12:34:00 +0000
Received: from verein.lst.de (localhost [127.0.0.1])
	by mail.lst.de (8.12.3/8.12.3/Debian-6.6) with ESMTP id i0GCXre6013050
	(version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO);
	Fri, 16 Jan 2004 13:33:53 +0100
Received: (from hch@localhost)
	by verein.lst.de (8.12.3/8.12.3/Debian-6.6) id i0GCXqOw013048;
	Fri, 16 Jan 2004 13:33:52 +0100
Date: Fri, 16 Jan 2004 13:33:52 +0100
From: Christoph Hellwig <hch@lst.de>
To: Yoichi Yuasa <yuasa@hh.iij4u.or.jp>
Cc: Ralf Baechle <ralf@linux-mips.org>,
	linux-mips <linux-mips@linux-mips.org>
Subject: Re: [PATCH][2.6] Update NEC VRC4171 PCMCIA driver
Message-ID: <20040116123352.GA13006@lst.de>
References: <20040116083821.6b65c69f.yuasa@hh.iij4u.or.jp>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20040116083821.6b65c69f.yuasa@hh.iij4u.or.jp>
User-Agent: Mutt/1.3.28i
X-Spam-Score: -4.901 () BAYES_00
X-Scanned-By: MIMEDefang 2.39
Return-Path: <hch@lst.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: 3998
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@lst.de
Precedence: bulk
X-list: linux-mips

On Fri, Jan 16, 2004 at 08:38:21AM +0900, Yoichi Yuasa wrote:
> +static int pccard_register_callback(unsigned int slot,
> +                                    void (*handler)(void *, unsigned int),
> +                                    void *info)
> +{
> +	vrc4171_socket_t *socket;
> +
> +	if (slot >= CARD_MAX_SLOTS)
> +		return -EINVAL;
> +
> +	socket = &vrc4171_sockets[slot];
> +
> +	socket->handler = handler;
> +	socket->info = info;
> +
> +	if (handler)
> +		MOD_INC_USE_COUNT;
> +	else
> +		MOD_DEC_USE_COUNT;
> +
> +	return 0;
> +}

This is most certainly wrong.  Module refcounting handling has moved one
layer up in 2.6.


From bruno.randolf@4g-systems.biz Fri Jan 16 14:16:22 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 16 Jan 2004 14:16:32 +0000 (GMT)
Received: from moutng.kundenserver.de ([IPv6:::ffff:212.227.126.177]:2517 "EHLO
	moutng.kundenserver.de") by linux-mips.org with ESMTP
	id <S8225208AbUAPOQW> convert rfc822-to-8bit; Fri, 16 Jan 2004 14:16:22 +0000
Received: from [212.227.126.160] (helo=mrelayng.kundenserver.de)
	by moutng.kundenserver.de with esmtp (Exim 3.35 #1)
	id 1AhUlo-0000OW-00
	for linux-mips@linux-mips.org; Fri, 16 Jan 2004 15:16:20 +0100
Received: from [80.129.131.133] (helo=create.4g)
	by mrelayng.kundenserver.de with asmtp (Exim 3.35 #1)
	id 1AhUlo-0002ec-00
	for linux-mips@linux-mips.org; Fri, 16 Jan 2004 15:16:20 +0100
From: Bruno Randolf <bruno.randolf@4g-systems.biz>
Organization: 4G Systems
To: linux-mips <linux-mips@linux-mips.org>
Subject: hang in setup_irq
Date: Fri, 16 Jan 2004 15:16:19 +0100
User-Agent: KMail/1.5.3
MIME-Version: 1.0
Content-Type: Text/Plain;
  charset="us-ascii"
Content-Transfer-Encoding: 8BIT
Content-Description: clearsigned data
Content-Disposition: inline
Message-Id: <200401161516.19386.bruno.randolf@4g-systems.biz>
X-Provags-ID: kundenserver.de abuse@kundenserver.de auth:d41044fba7cf33548d8f98fdbdd6d515
Return-Path: <bruno.randolf@4g-systems.biz>
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: 3999
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: bruno.randolf@4g-systems.biz
Precedence: bulk
X-list: linux-mips

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

hello!

i have a mtx-1 system (mipsel kernel 2.4.21) with 2 mini-pci prism2 cards, 
both sharing the same interrupt. everything works fine when i power on
the system.

but when i reboot (without removing the power), the initialization of the 
driver (hostap) hangs in the function setup_irq before 
spin_unlock_irqrestore. this does not happen when the cards have seperate 
irqs or with only one card. what could be the problem?

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

iD8DBQFAB/Izfg2jtUL97G4RAiWKAJ0ctq3ixQWapHor5q3e8rtcwJNtDwCfS/Is
CV5n5t3W5MUpaGXcyaV0vvw=
=E7lR
-----END PGP SIGNATURE-----


From a.nielsen@optushome.com.au Sat Jan 17 07:11:47 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 17 Jan 2004 07:11:48 +0000 (GMT)
Received: from mail013.syd.optusnet.com.au ([IPv6:::ffff:211.29.132.67]:38373
	"EHLO mail013.syd.optusnet.com.au") by linux-mips.org with ESMTP
	id <S8225216AbUAQHLr>; Sat, 17 Jan 2004 07:11:47 +0000
Received: from korath.adamsrealm.net.au (c210-49-87-133.rochd3.qld.optusnet.com.au [210.49.87.133])
	by mail013.syd.optusnet.com.au (8.11.6p2/8.11.6) with ESMTP id i0H7Bde29937
	for <linux-mips@linux-mips.org>; Sat, 17 Jan 2004 18:11:41 +1100
From: Adam Nielsen <a.nielsen@optushome.com.au>
To: linux-mips@linux-mips.org
Subject: Trouble compiling MIPS cross-compiler
Date: Sat, 17 Jan 2004 17:11:34 +1000
User-Agent: KMail/1.5
MIME-Version: 1.0
Content-Type: text/plain;
  charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200401171711.34964@korath>
Return-Path: <a.nielsen@optushome.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: 4000
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: a.nielsen@optushome.com.au
Precedence: bulk
X-list: linux-mips

Hi,

I've been following the instructions in the FAQ on linux-mips.org but when I 
go to compile ecgs-1.1.2, half way through I get this error:

as: unrecognized option `-O2'
make[3]: *** [libgcc2.a] Error 1
make[3]: Leaving directory `/home/adam/toinstall/egcs-1.1.2/gcc'

I can post more of the error messages if you need them.  I tried upgrading my 
host binutils as well, but that didn't make a difference.  If I run 
"mips-linux-as -O2" it works, but just "as -O2" gives that same error.  
They're both the same versions now:

$ as -v -O2
GNU assembler version 2.14 (i686-pc-linux-gnu) using BFD version 2.14 20030612
as: unrecognized option `-O2'

$ mips-linux-as -v -O2
GNU assembler version 2.14 (mips-linux) using BFD version 2.14 20030612

Does anyone know how to fix this problem?

Thanks,
Adam.


From a.nielsen@optushome.com.au Sat Jan 17 07:37:05 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 17 Jan 2004 07:37:05 +0000 (GMT)
Received: from mail008.syd.optusnet.com.au ([IPv6:::ffff:211.29.132.212]:33221
	"EHLO mail008.syd.optusnet.com.au") by linux-mips.org with ESMTP
	id <S8225216AbUAQHhF>; Sat, 17 Jan 2004 07:37:05 +0000
Received: from korath.adamsrealm.net.au (c210-49-87-133.rochd3.qld.optusnet.com.au [210.49.87.133])
	by mail008.syd.optusnet.com.au (8.11.6p2/8.11.6) with ESMTP id i0H7ard10318
	for <linux-mips@linux-mips.org>; Sat, 17 Jan 2004 18:36:58 +1100
From: Adam Nielsen <a.nielsen@optushome.com.au>
To: linux-mips@linux-mips.org
Subject: Re: Trouble compiling MIPS cross-compiler
Date: Sat, 17 Jan 2004 17:36:49 +1000
User-Agent: KMail/1.5
References: <200401171711.34964@korath>
In-Reply-To: <200401171711.34964@korath>
MIME-Version: 1.0
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200401171736.49803@korath>
Return-Path: <a.nielsen@optushome.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: 4001
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: a.nielsen@optushome.com.au
Precedence: bulk
X-list: linux-mips

> as: unrecognized option `-O2'

Ok, I just worked out the problem - or at least I discovered a workaround.  If 
I run:

	./configure --prefix=/usr/local [...]

then I get the error during compilation, but if instead I run

	./configure --prefix=/usr [...]

then it appears to work perfectly...!

No idea what's going on, but at least it works and hopefully it won't 
overwrite my existing compiler when I install it ;-)

Cheers,
Adam.


From ralf@linux-mips.org Sat Jan 17 12:20:35 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 17 Jan 2004 12:20:38 +0000 (GMT)
Received: from p508B6259.dip.t-dialin.net ([IPv6:::ffff:80.139.98.89]:47685
	"EHLO mail.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225217AbUAQMUf>; Sat, 17 Jan 2004 12:20:35 +0000
Received: from fluff.linux-mips.net (fluff.linux-mips.net [127.0.0.1])
	by mail.linux-mips.net (8.12.8/8.12.8) with ESMTP id i0HCKN4P023609;
	Sat, 17 Jan 2004 13:20:23 +0100
Received: (from ralf@localhost)
	by fluff.linux-mips.net (8.12.8/8.12.8/Submit) id i0HCKMWt023607;
	Sat, 17 Jan 2004 13:20:22 +0100
Date: Sat, 17 Jan 2004 13:20:22 +0100
From: Ralf Baechle <ralf@linux-mips.org>
To: "Suresh. R" <suresh@mistralsoftware.com>
Cc: linux-mips@linux-mips.org
Subject: Re: VR4131 - MQ1132 - UPD63335
Message-ID: <20040117122022.GD5288@linux-mips.org>
References: <40079391.7080301@mistralsoftware.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <40079391.7080301@mistralsoftware.com>
User-Agent: Mutt/1.4.1i
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: 4002
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 16, 2004 at 01:02:33PM +0530, Suresh. R wrote:

>   This might be a very basic question, but I am very new to this field. 
> So please help me.
> 
> I am writing a linux device driver for UPD63335 audio codec. Its 
> controlled through the MQ1132 co-processor. The VR4131 is the processor. 
> The memory of MQ1132 is mapped to the processor memory in Kseg1 (0xA000 
> 0000 onwards) which the manual says is TLB Unmapped region. Now my 
> question is is it necessary to map this region before using it in Linux. 
> Actually I have WinCE code for my reference. In that code the programmer 
> is mapping the region using Virtual Cpoy and Virtual Alloc. Is it 
> necessary to do that or Can I directly address the memory locatoin.

Generally a driver under Linux maps a device in it's initialization
routine with a bit of code like

#define FOO_BASE	0x12340000UL		/* physical address */
#define FOO_SIZE	0x00001000UL

...
	struct foo_regs *base;

	base = ioremap(0x1234, FOO_SIZE);
	if (!base) {
		/* Failed, game over  */
		harakiri();
		...
	}

	/* Success, make it blink ... */
	foo->blinkenlight = 42;
...
	/* Done, unmap before exiting.
	unmap(base);
...

This removes all knowledge about how a particular architecture handles
mappings from the driver and therefore is generally the prefered way in
Linux.

Linux/MIPS optimize the case where an unmapped area can be used, so no
runtime overhead at all.

  Ralf

From jbglaw@dvmwest.gt.owl.de Sat Jan 17 12:51:44 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 17 Jan 2004 12:51:45 +0000 (GMT)
Received: from dvmwest.gt.owl.de ([IPv6:::ffff:62.52.24.140]:5267 "EHLO
	dvmwest.gt.owl.de") by linux-mips.org with ESMTP
	id <S8225207AbUAQMvo>; Sat, 17 Jan 2004 12:51:44 +0000
Received: by dvmwest.gt.owl.de (Postfix, from userid 1001)
	id 0D3F04B4C4; Sat, 17 Jan 2004 13:51:43 +0100 (CET)
Date: Sat, 17 Jan 2004 13:51:42 +0100
From: Jan-Benedict Glaw <jbglaw@lug-owl.de>
To: linux-mips@linux-mips.org
Subject: Re: VR4131 - MQ1132 - UPD63335
Message-ID: <20040117125142.GX14285@lug-owl.de>
Mail-Followup-To: linux-mips@linux-mips.org
References: <40079391.7080301@mistralsoftware.com> <20040117122022.GD5288@linux-mips.org>
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="uRsQmhdkrfa52i5R"
Content-Disposition: inline
In-Reply-To: <20040117122022.GD5288@linux-mips.org>
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
User-Agent: Mutt/1.5.4i
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: 4003
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


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

On Sat, 2004-01-17 13:20:22 +0100, Ralf Baechle <ralf@linux-mips.org>
wrote in message <20040117122022.GD5288@linux-mips.org>:
> #define FOO_BASE	0x12340000UL		/* physical address */
                        ^^^^^^^^^^
> #define FOO_SIZE	0x00001000UL
>=20
> 	base =3D ioremap(0x1234, FOO_SIZE);
                       ^^^^^^
Not FOO_BASE?

MfG, JBG

--=20
   Jan-Benedict Glaw       jbglaw@lug-owl.de    . +49-172-7608481
   "Eine Freie Meinung in  einem Freien Kopf    | Gegen Zensur | Gegen Krieg
    fuer einen Freien Staat voll Freier B=FCrger" | im Internet! |   im Ira=
k!
   ret =3D do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TC=
PA));

--uRsQmhdkrfa52i5R
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

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

iD8DBQFACS/eHb1edYOZ4bsRAtUNAJ9SuDW/acDt/nxtzGM0SzFJEx+GXwCdHHQ3
DSE4gTXcXqKvafd9FIBx+Xo=
=ZqUZ
-----END PGP SIGNATURE-----

--uRsQmhdkrfa52i5R--

From tbm@cyrius.com Sat Jan 17 15:24:16 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 17 Jan 2004 15:24:17 +0000 (GMT)
Received: from bangpath.uucico.de ([IPv6:::ffff:195.71.9.197]:37386 "EHLO
	bangpath.uucico.de") by linux-mips.org with ESMTP
	id <S8225225AbUAQPYQ> convert rfc822-to-8bit; Sat, 17 Jan 2004 15:24:16 +0000
Received: by bangpath.uucico.de (Postfix, from userid 10)
	id 5670926BB6; Sat, 17 Jan 2004 16:24:15 +0100 (CET)
Received: by deprecation.cyrius.com (Postfix, from userid 1000)
	id 167E3FEFB; Sat, 17 Jan 2004 15:24:10 +0000 (GMT)
Date: Sat, 17 Jan 2004 15:24:10 +0000
From: Martin Michlmayr <tbm@cyrius.com>
To: linux-mips@linux-mips.org
Subject: Current CVS oopses on Broadcom SWARM
Message-ID: <20040117152410.GA29432@deprecation.cyrius.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: 8BIT
User-Agent: Mutt/1.5.5.1+cvs20040105i
Return-Path: <tbm@cyrius.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: 4004
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: tbm@cyrius.com
Precedence: bulk
X-list: linux-mips

At the end of December, Ralf made some "prototype cleanup for 2.4" [1]
which left the SB1250 code uncompilable.  On January 5th, a fix for
this was checked in [2].  Unfortunately, this fix does not work - the
kernel oopses during boot.  The code now looks likes this (in the
past, the return value of prom_boot_secondary was checked and the loop
left when prom_boot_secondary was successful):

                do {

                        /* Iterate until we find a CPU that comes up */
                        cur_cpu++;
                        prom_boot_secondary(cur_cpu,
                                            (unsigned long)p + KERNEL_STACK_SIZE - 32,
                                            (unsigned long)p);
                } while (cur_cpu < NR_CPUS);
                __cpu_number_map[cur_cpu] = i;
                __cpu_logical_map[i] = cur_cpu;

Basically, what this means is that on a SWARM board with 1 physical
CPU, this loop is ran through 32 times (the default of NR_CPUS).
prom_boot_secondary works for the first time, and fails for the 31 CPUs
which don't exist.  At the end, cur_cpu is 32 -- although it should
really be 1.  The kernel oopses a little bit later:


Device eth0:  hwaddr 00-02-4C-FE-0D-08, ipaddr 192.168.1.10, mask 255.255.255.0
        gateway 192.168.1.1, nameserver 131.111.8.42, domain cyrius.com
*** command status = 0
CFE> boot -elf 192.168.1.1:sibylifconfig eth0 -autoboot -elf 192.168.1.1:sibyl
Loader:elf Filesys:tftp Dev:eth0 File:192.168.1.1:sibyl Options:(null)
Loading: 0x0000000020000000/71104 0x00000000200115c0/248 Entry at 0x0000000020000000
Closing network.
Starting program at 0x0000000020000000
SiByte Loader, version 2.4.2
Built on Jan 16 2004
Network device 'eth0' configured
Getting configuration file tftp:192.168.1.1:sibyl.conf...
Config file retrieved.
Available configurations:
  hda
  nfsroot
Boot which configuration [hda]: 
Loading kernel (ELF32):
    1643520@0x80100000
    196608@0x80292000
done
Set up command line arguments to: root=/dev/hda1
Setting up initial prom_init arguments
Cleaning up state...
Transferring control to the kernel.
Kernel entry point is at 0x80294040
Broadcom SiByte BCM1250 B2 @ 800 MHz (SB1 rev 2)
Board type: SiByte BCM91250A (SWARM)
CPU revision is: 01040102
FPU revision is: 000f0102
Linux version 2.4.24-pre2 (tbm@deprecation) (gcc version 3.2.3 20030221 (Debian prerelease)) #6 SMP Fri Jan 16 22:06:34 GMT 2004
swarm setup: M41T81 RTC detected.
This kernel optimized for board runs with CFE
Determined physical RAM map:
 memory: 0fe8ae00 @ 00000000 (usable)
On node 0 totalpages: 65162
zone(0): 65162 pages.
zone(1): 0 pages.
zone(2): 0 pages.
Kernel command line: root=/dev/hda1
Calibrating delay loop... 532.48 BogoMIPS
Memory: 254680k/260648k available (1605k kernel code, 5968k reserved, 96k data, 64k init, 0k highmem)
Dentry cache hash table entries: 32768 (order: 6, 262144 bytes)
Inode cache hash table entries: 16384 (order: 5, 131072 bytes)
Mount cache hash table entries: 512 (order: 0, 4096 bytes)
Buffer cache hash table entries: 16384 (order: 4, 65536 bytes)
Page-cache hash table entries: 65536 (order: 6, 262144 bytes)
Checking for 'wait' instruction...  unavailable.
POSIX conformance testing by UNIFIX
Detected 2 available CPU(s)
Starting CPU 1... cfe_start_cpu(2) returned -1
Slave cpu booted successfully
cfe_start_cpu(3) returned -1
cfe_start_cpu(4) returned -1
cfe_start_cpu(5) returned -1
cfe_start_cpu(6) returned -1
cfe_start_cpu(7) returned -1
cfe_start_cpu(8) returned -1
cfe_start_cpu(9) returned -1
cfe_start_cpu(10) returned -1
cfe_start_cpu(11) returned -1
cfe_start_cpu(12) returned -1
cfe_start_cpu(13) returned -1
cfe_start_cpu(14) returned -1
cfe_start_cpu(15) returned -1
cfe_start_cpu(16) returned -1
cfe_start_cpu(17) returned -1
cfe_start_cpu(18) returned -1
cfe_start_cpu(19) returned -1
cfe_start_cpu(20) returned -1
cfe_start_cpu(21) returned -1
cfe_start_cpu(22) returned -1
cfe_start_cpu(23) returned -1
cfe_start_cpu(24) returned -1
cfe_start_cpu(25) returned -1
cfe_start_cpu(26) returned -1
cfe_start_cpu(27) returned -1
cfe_start_cpu(28) returned -1
cfe_start_cpu(29) returned -1
cfe_start_cpu(30) returned -1
cfe_start_cpu(31) returned -1
cfe_start_cpu(32) returned -1
Waiting on wait_init_idle (map = 0x2)
All processors have done init_idle
PCI: Probing PCI hardware on host bus 0.
PCI: 00:01.0: class 600 doesn't match header type 01. Ignoring class.
Linux NET4.0 for Linux 2.4
Based upon Swansea University Computer Society NET3.039
Initializing RT netlink socket
Unable to handle kernel paging request at virtual address 00000050, epc == 8010dd44, ra == 80110540
Oops in fault.c::do_page_fault, line 206:
$0 : 00000000 802e0000 8fe80000 00000000 802a5460 00000020 00000000 00000001
$8 : 802c39f4 00000000 8fe80000 80358000 ffffffff 00000016 802afdcc ffffffff
$16: 802a5060 ffffffff 00000000 00000065 802a3090 8036fe98 00000000 00000000
$24: 802b5864 802c3970                   8036e000 8036fde8 8036fde8 80110540
Hi : 00000000
Lo : 00000c20
epc   : 8010dd44    Not tainted
Status: 10001f02
Cause : 00808008
PrId  : 01040102
Process swapper (pid: 1, stackpage=8036e000)
Stack:    802a3090 8036fe98 00000000 8feb52e8 802a5020 10001f01 80358000
 00000002 8036fe10 80110540 80358000 fffffff4 803584e4 00000700 803584e4
 00000700 8ff97538 80111d38 8018a2c4 8018a268 00000024 00000000 80358000
 8036fe98 00000000 8036fe70 00000010 00002180 00000700 802a3090 80124374
 200116d8 8ff977f8 8fe95dc0 8ffc4ab0 8feb52e8 80107af8 802804fc 0000000f
 00000000 ...
Call Trace:   [<80110540>] [<80111d38>] [<8018a2c4>] [<8018a268>] [<80124374>]
 [<80107af8>] [<802804fc>] [<801081b0>] [<801893bc>] [<80189364>] [<801891b4>]
 [<8018a2c4>] [<8018a268>] [<8018a068>] [<80189364>] [<8015b58c>] [<80124374>]
 [<80111734>] [<80102aa0>] [<801007fc>] [<80111734>] [<80124718>] [<8027edc0>]
 [<801007fc>] [<80100840>] [<80113750>] [<80102ab0>] [<80111734>] [<8016a4e8>]
 [<8016a4c4>] [<80102aa0>]

Code: ad420014  0804373f  00000000 <8cc40050> 30620010  14400011  240dffff  5460002e  8d6200c8 
Kernel panic: Attempted to kill init!
 <0>Rebooting in 5 seconds..

----- End forwarded message -----

[1] http://linux.junsun.net/xcvs/xcvs_linux_mips/patches/6344.patch
[2] http://linux.junsun.net/xcvs/xcvs_linux_mips/patches/6390.patch
-- 
Martin Michlmayr
tbm@cyrius.com

From ica2_ts@csv.ica.uni-stuttgart.de Sat Jan 17 16:27:55 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 17 Jan 2004 16:27:56 +0000 (GMT)
Received: from iris1.csv.ica.uni-stuttgart.de ([IPv6:::ffff:129.69.118.2]:13870
	"EHLO iris1.csv.ica.uni-stuttgart.de") by linux-mips.org with ESMTP
	id <S8225225AbUAQQ1z>; Sat, 17 Jan 2004 16:27:55 +0000
Received: from rembrandt.csv.ica.uni-stuttgart.de ([129.69.118.42])
	by iris1.csv.ica.uni-stuttgart.de with esmtp
	id 1AhtIf-0001Qc-00
	for <linux-mips@linux-mips.org>; Sat, 17 Jan 2004 17:27:53 +0100
Received: from ica2_ts by rembrandt.csv.ica.uni-stuttgart.de with local (Exim 3.35 #1 (Debian))
	id 1AhtIf-0003m3-00
	for <linux-mips@linux-mips.org>; Sat, 17 Jan 2004 17:27:53 +0100
Date: Sat, 17 Jan 2004 17:27:53 +0100
To: linux-mips@linux-mips.org
Subject: Re: Trouble compiling MIPS cross-compiler
Message-ID: <20040117162753.GC22218@rembrandt.csv.ica.uni-stuttgart.de>
References: <200401171711.34964@korath> <200401171736.49803@korath>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <200401171736.49803@korath>
User-Agent: Mutt/1.5.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: 4005
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

Adam Nielsen wrote:
> > as: unrecognized option `-O2'
> 
> Ok, I just worked out the problem - or at least I discovered a workaround.  If 
> I run:
> 
> 	./configure --prefix=/usr/local [...]
> 
> then I get the error during compilation, but if instead I run
> 
> 	./configure --prefix=/usr [...]
> 
> then it appears to work perfectly...!
> 
> No idea what's going on, but at least it works and hopefully it won't 
> overwrite my existing compiler when I install it ;-)

IIRC you need to configure with AS=mips-linux-as.


Thiemo

From ralf@linux-mips.org Sat Jan 17 16:33:59 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 17 Jan 2004 16:34:01 +0000 (GMT)
Received: from p508B6259.dip.t-dialin.net ([IPv6:::ffff:80.139.98.89]:43348
	"EHLO mail.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225225AbUAQQd7>; Sat, 17 Jan 2004 16:33:59 +0000
Received: from fluff.linux-mips.net (fluff.linux-mips.net [127.0.0.1])
	by mail.linux-mips.net (8.12.8/8.12.8) with ESMTP id i0HGXv4P027198;
	Sat, 17 Jan 2004 17:33:57 +0100
Received: (from ralf@localhost)
	by fluff.linux-mips.net (8.12.8/8.12.8/Submit) id i0HGXtGR027197;
	Sat, 17 Jan 2004 17:33:55 +0100
Date: Sat, 17 Jan 2004 17:33:55 +0100
From: Ralf Baechle <ralf@linux-mips.org>
To: Adam Nielsen <a.nielsen@optushome.com.au>
Cc: linux-mips@linux-mips.org
Subject: Re: Trouble compiling MIPS cross-compiler
Message-ID: <20040117163355.GE5288@linux-mips.org>
References: <200401171711.34964@korath> <200401171736.49803@korath>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <200401171736.49803@korath>
User-Agent: Mutt/1.4.1i
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: 4006
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 17, 2004 at 05:36:49PM +1000, Adam Nielsen wrote:

> 	./configure --prefix=/usr [...]
> 
> then it appears to work perfectly...!
> 
> No idea what's going on, but at least it works and hopefully it won't 
> overwrite my existing compiler when I install it ;-)

gcc and binutils must be installed with the same prefix or gcc will not
find the target as and fallback to the native tools which of course
won't work at all as you saw.

In your other mail you mentioned you were using gcc 1.1.2; I recommend
gcc 2.95.4 instead.  gcc 1.1.2 needs a few workarounds in the kernel
source in particular for 64-bit kernels and I've removed all of them
around 2003-05-16 (in the Linux 2.4.20 age) so I'm not sure if egcs 1.1.2
will still work.  Sympthom are compiler core dumps.  Newer doesn't harm ...

  Ralf

From ralf@linux-mips.org Sat Jan 17 16:35:40 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 17 Jan 2004 16:35:40 +0000 (GMT)
Received: from p508B6259.dip.t-dialin.net ([IPv6:::ffff:80.139.98.89]:51540
	"EHLO mail.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225225AbUAQQfk>; Sat, 17 Jan 2004 16:35:40 +0000
Received: from fluff.linux-mips.net (fluff.linux-mips.net [127.0.0.1])
	by mail.linux-mips.net (8.12.8/8.12.8) with ESMTP id i0HGZc4P027240;
	Sat, 17 Jan 2004 17:35:38 +0100
Received: (from ralf@localhost)
	by fluff.linux-mips.net (8.12.8/8.12.8/Submit) id i0HGZcn1027239;
	Sat, 17 Jan 2004 17:35:38 +0100
Date: Sat, 17 Jan 2004 17:35:38 +0100
From: Ralf Baechle <ralf@linux-mips.org>
To: Thiemo Seufer <ica2_ts@csv.ica.uni-stuttgart.de>
Cc: linux-mips@linux-mips.org
Subject: Re: Trouble compiling MIPS cross-compiler
Message-ID: <20040117163538.GF5288@linux-mips.org>
References: <200401171711.34964@korath> <200401171736.49803@korath> <20040117162753.GC22218@rembrandt.csv.ica.uni-stuttgart.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20040117162753.GC22218@rembrandt.csv.ica.uni-stuttgart.de>
User-Agent: Mutt/1.4.1i
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: 4007
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 17, 2004 at 05:27:53PM +0100, Thiemo Seufer wrote:

> > No idea what's going on, but at least it works and hopefully it won't 
> > overwrite my existing compiler when I install it ;-)
> 
> IIRC you need to configure with AS=mips-linux-as.

gcc uses as from the tools by default, then falls back to as in $PATH if
that fails.  So if you have to set the AS variable that's kludging around
the real problem.

  Ralf

From a.nielsen@optushome.com.au Sun Jan 18 01:19:24 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 18 Jan 2004 01:19:25 +0000 (GMT)
Received: from mail012.syd.optusnet.com.au ([IPv6:::ffff:211.29.132.66]:16097
	"EHLO mail012.syd.optusnet.com.au") by linux-mips.org with ESMTP
	id <S8225214AbUARBTY>; Sun, 18 Jan 2004 01:19:24 +0000
Received: from korath.adamsrealm.net.au (c210-49-87-133.rochd3.qld.optusnet.com.au [210.49.87.133])
	by mail012.syd.optusnet.com.au (8.11.6p2/8.11.6) with ESMTP id i0I1JJS14381
	for <linux-mips@linux-mips.org>; Sun, 18 Jan 2004 12:19:20 +1100
From: Adam Nielsen <a.nielsen@optushome.com.au>
To: linux-mips@linux-mips.org
Subject: Re: Trouble compiling MIPS cross-compiler
Date: Sun, 18 Jan 2004 11:19:15 +1000
User-Agent: KMail/1.5
References: <200401171711.34964@korath> <200401171736.49803@korath> <20040117163355.GE5288@linux-mips.org>
In-Reply-To: <20040117163355.GE5288@linux-mips.org>
MIME-Version: 1.0
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200401181119.15234@korath>
Return-Path: <a.nielsen@optushome.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: 4008
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: a.nielsen@optushome.com.au
Precedence: bulk
X-list: linux-mips

> In your other mail you mentioned you were using gcc 1.1.2; I recommend
> gcc 2.95.4 instead.  gcc 1.1.2 needs a few workarounds in the kernel
> source in particular for 64-bit kernels and I've removed all of them
> around 2003-05-16 (in the Linux 2.4.20 age) so I'm not sure if egcs 1.1.2
> will still work.  Sympthom are compiler core dumps.  Newer doesn't harm ...

Yes, I saw that in the kernel docs but I tried it anyway since that's the 
version used in the FAQ.  I ended up getting another error though, and 
upgrading to gcc 2.95.3 (couldn't find .4) didn't help:

/usr/mips-linux/bin/as: unrecognized option `-mcpu=r3000'

I saw that this option was removed a while back, so I guess downgrading the 
binutils is the only way to go (or upgrading gcc, but I got a ton of errors 
compiling 3.3.2 so I guess that doesn't work...)

I'll try an older version of the binutils and see if that fixes it.  Thanks 
for your help!

Cheers,
Adam.


From a.nielsen@optushome.com.au Sun Jan 18 01:54:32 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 18 Jan 2004 01:54:32 +0000 (GMT)
Received: from mail007.syd.optusnet.com.au ([IPv6:::ffff:211.29.132.55]:37536
	"EHLO mail007.syd.optusnet.com.au") by linux-mips.org with ESMTP
	id <S8225536AbUARByc>; Sun, 18 Jan 2004 01:54:32 +0000
Received: from korath.adamsrealm.net.au (c210-49-87-133.rochd3.qld.optusnet.com.au [210.49.87.133])
	by mail007.syd.optusnet.com.au (8.11.6p2/8.11.6) with ESMTP id i0I1sQB09579
	for <linux-mips@linux-mips.org>; Sun, 18 Jan 2004 12:54:27 +1100
From: Adam Nielsen <a.nielsen@optushome.com.au>
To: linux-mips@linux-mips.org
Subject: Re: Trouble compiling MIPS cross-compiler
Date: Sun, 18 Jan 2004 11:54:22 +1000
User-Agent: KMail/1.5
References: <200401171711.34964@korath> <20040117163355.GE5288@linux-mips.org> <200401181119.15234@korath>
In-Reply-To: <200401181119.15234@korath>
MIME-Version: 1.0
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200401181154.22007@korath>
Return-Path: <a.nielsen@optushome.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: 4009
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: a.nielsen@optushome.com.au
Precedence: bulk
X-list: linux-mips

> I'll try an older version of the binutils and see if that fixes it.

Well, I downgraded to binutils 2.13.2.1 and it got past the -mcpu error, but 
now I get this error instead (I'm compiling a stock 2.6.0 kernel with gcc 
2.95.3):

include/asm/sgidefs.h:18: #error Use a Linux compiler or give up.

followed by hundreds of other various errors.  So I'm stuck again ;-)  Any 
ideas?  I'm guessing I need to get a newer compiler...?

Cheers,
Adam.


From yuasa@hh.iij4u.or.jp Sun Jan 18 02:53:38 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 18 Jan 2004 02:53:39 +0000 (GMT)
Received: from mo02.iij4u.or.jp ([IPv6:::ffff:210.130.0.19]:10442 "EHLO
	mo02.iij4u.or.jp") by linux-mips.org with ESMTP id <S8225214AbUARCxi>;
	Sun, 18 Jan 2004 02:53:38 +0000
Received: from mdo01.iij4u.or.jp (mdo01.iij4u.or.jp [210.130.0.171])
	by mo02.iij4u.or.jp (8.8.8/MFO1.5) with ESMTP id LAA08099;
	Sun, 18 Jan 2004 11:53:28 +0900 (JST)
Received: 4UMDO01 id i0I2rRY11278; Sun, 18 Jan 2004 11:53:27 +0900 (JST)
Received: 4UMRO00 id i0I2rOj29259; Sun, 18 Jan 2004 11:53:25 +0900 (JST)
	from stratos.frog (64.43.138.210.xn.2iij.net [210.138.43.64]) (authenticated)
Date: Sun, 18 Jan 2004 11:53:21 +0900
From: Yoichi Yuasa <yuasa@hh.iij4u.or.jp>
To: Christoph Hellwig <hch@lst.de>
Cc: yuasa@hh.iij4u.or.jp, ralf@linux-mips.org,
	linux-mips@linux-mips.org
Subject: Re: [PATCH][2.6] Update NEC VRC4171 PCMCIA driver
Message-Id: <20040118115321.5ab75e5e.yuasa@hh.iij4u.or.jp>
In-Reply-To: <20040116123352.GA13006@lst.de>
References: <20040116083821.6b65c69f.yuasa@hh.iij4u.or.jp>
	<20040116123352.GA13006@lst.de>
X-Mailer: Sylpheed version 0.9.8a (GTK+ 1.2.10; i686-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Return-Path: <yuasa@hh.iij4u.or.jp>
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: 4010
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: yuasa@hh.iij4u.or.jp
Precedence: bulk
X-list: linux-mips

On Fri, 16 Jan 2004 13:33:52 +0100
Christoph Hellwig <hch@lst.de> wrote:

> On Fri, Jan 16, 2004 at 08:38:21AM +0900, Yoichi Yuasa wrote:
> > +static int pccard_register_callback(unsigned int slot,
> > +                                    void (*handler)(void *, unsigned int),
> > +                                    void *info)
> > +{
> > +	vrc4171_socket_t *socket;
> > +
> > +	if (slot >= CARD_MAX_SLOTS)
> > +		return -EINVAL;
> > +
> > +	socket = &vrc4171_sockets[slot];
> > +
> > +	socket->handler = handler;
> > +	socket->info = info;
> > +
> > +	if (handler)
> > +		MOD_INC_USE_COUNT;
> > +	else
> > +		MOD_DEC_USE_COUNT;
> > +
> > +	return 0;
> > +}
> 
> This is most certainly wrong.  Module refcounting handling has moved one
> layer up in 2.6.
> 

Oops, I sent old one.
Wait a moment.

Yoichi

From ralf@linux-mips.org Sun Jan 18 03:46:09 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 18 Jan 2004 03:46:17 +0000 (GMT)
Received: from p508B6259.dip.t-dialin.net ([IPv6:::ffff:80.139.98.89]:25724
	"EHLO mail.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225214AbUARDqJ>; Sun, 18 Jan 2004 03:46:09 +0000
Received: from fluff.linux-mips.net (fluff.linux-mips.net [127.0.0.1])
	by mail.linux-mips.net (8.12.8/8.12.8) with ESMTP id i0I3k84P019665;
	Sun, 18 Jan 2004 04:46:08 +0100
Received: (from ralf@localhost)
	by fluff.linux-mips.net (8.12.8/8.12.8/Submit) id i0I3k7Vu019664;
	Sun, 18 Jan 2004 04:46:07 +0100
Date: Sun, 18 Jan 2004 04:46:07 +0100
From: Ralf Baechle <ralf@linux-mips.org>
To: Adam Nielsen <a.nielsen@optushome.com.au>
Cc: linux-mips@linux-mips.org
Subject: Re: Trouble compiling MIPS cross-compiler
Message-ID: <20040118034607.GB1347@linux-mips.org>
References: <200401171711.34964@korath> <20040117163355.GE5288@linux-mips.org> <200401181119.15234@korath> <200401181154.22007@korath>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <200401181154.22007@korath>
User-Agent: Mutt/1.4.1i
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: 4011
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 18, 2004 at 11:54:22AM +1000, Adam Nielsen wrote:

> > I'll try an older version of the binutils and see if that fixes it.
> 
> Well, I downgraded to binutils 2.13.2.1 and it got past the -mcpu error, but 
> now I get this error instead (I'm compiling a stock 2.6.0 kernel with gcc 
> 2.95.3):
> 
> include/asm/sgidefs.h:18: #error Use a Linux compiler or give up.
> 
> followed by hundreds of other various errors.  So I'm stuck again ;-)  Any 
> ideas?  I'm guessing I need to get a newer compiler...?

No, a Linux compiler, not the one from the corn flakes package ;-)

  Ralf

From echristo@redhat.com Sun Jan 18 04:15:54 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 18 Jan 2004 04:15:54 +0000 (GMT)
Received: from mx2.redhat.com ([IPv6:::ffff:66.187.237.31]:24849 "EHLO
	mx2.redhat.com") by linux-mips.org with ESMTP id <S8224948AbUAREPy>;
	Sun, 18 Jan 2004 04:15:54 +0000
Received: from int-mx2.corp.redhat.com (int-mx2.corp.redhat.com [172.16.27.26])
	by mx2.redhat.com (8.11.6/8.11.6) with ESMTP id i0I3qPO15875;
	Sat, 17 Jan 2004 22:52:25 -0500
Received: from potter.sfbay.redhat.com (potter.sfbay.redhat.com [172.16.27.15])
	by int-mx2.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i0I4FmM03076;
	Sat, 17 Jan 2004 23:15:48 -0500
Received: from [192.168.123.101] (vpn26-3.sfbay.redhat.com [172.16.26.3])
	by potter.sfbay.redhat.com (8.11.6/8.11.6) with ESMTP id i0I4Flb12623;
	Sat, 17 Jan 2004 20:15:47 -0800
Subject: Re: Trouble compiling MIPS cross-compiler
From: Eric Christopher <echristo@redhat.com>
To: Adam Nielsen <a.nielsen@optushome.com.au>
Cc: linux-mips@linux-mips.org
In-Reply-To: <200401181119.15234@korath>
References: <200401171711.34964@korath> <200401171736.49803@korath>
	 <20040117163355.GE5288@linux-mips.org>  <200401181119.15234@korath>
Content-Type: text/plain
Message-Id: <1074399252.3602.8.camel@dzur.sfbay.redhat.com>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.4.5 (1.4.5-7) 
Date: Sat, 17 Jan 2004 20:14:12 -0800
Content-Transfer-Encoding: 7bit
Return-Path: <echristo@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: 4012
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: echristo@redhat.com
Precedence: bulk
X-list: linux-mips


> 
> /usr/mips-linux/bin/as: unrecognized option `-mcpu=r3000'
> 
> I saw that this option was removed a while back, so I guess downgrading the 
> binutils is the only way to go (or upgrading gcc, but I got a ton of errors 
> compiling 3.3.2 so I guess that doesn't work...)
> 

You do? What errors? How'd you build the toolchain?

At any rate, I'm using gcc and binutils HEAD to build quite a few
things. The last kernel I have is from broadcom (sibyte division) and
rebuilt and booted on the swarm board. (In fact, the compiler also
bootstraps on the board).

-eric

-- 
Eric Christopher <echristo@redhat.com>


From a.nielsen@optushome.com.au Sun Jan 18 05:10:53 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 18 Jan 2004 05:10:53 +0000 (GMT)
Received: from mail018.syd.optusnet.com.au ([IPv6:::ffff:211.29.132.72]:36033
	"EHLO mail018.syd.optusnet.com.au") by linux-mips.org with ESMTP
	id <S8225230AbUARFKx>; Sun, 18 Jan 2004 05:10:53 +0000
Received: from korath.adamsrealm.net.au (c210-49-87-133.rochd3.qld.optusnet.com.au [210.49.87.133])
	by mail018.syd.optusnet.com.au (8.11.6p2/8.11.6) with ESMTP id i0I5Ae506746;
	Sun, 18 Jan 2004 16:10:41 +1100
From: Adam Nielsen <a.nielsen@optushome.com.au>
To: Eric Christopher <echristo@redhat.com>
Subject: Re: Trouble compiling MIPS cross-compiler
Date: Sun, 18 Jan 2004 15:10:35 +1000
User-Agent: KMail/1.5
Cc: linux-mips@linux-mips.org
References: <200401171711.34964@korath> <200401181119.15234@korath> <1074399252.3602.8.camel@dzur.sfbay.redhat.com>
In-Reply-To: <1074399252.3602.8.camel@dzur.sfbay.redhat.com>
MIME-Version: 1.0
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200401181510.35686@korath>
Return-Path: <a.nielsen@optushome.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: 4013
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: a.nielsen@optushome.com.au
Precedence: bulk
X-list: linux-mips

> You do? What errors? How'd you build the toolchain?

I was just following the linux-mips.org FAQ for building a cross compiler.  
The errors were something to do with missing headers (pthread.h among others) 
so I tried configuring gcc with --disable-threads as suggested in a post 
Google found, and so far that seems to be working...except just as I wrote 
that it came up with this:

/usr/mips-linux/bin/ld: cannot open crti.o: No such file or directory

Now I see why it says on the FAQ that building a cross compiler has always 
been the hardest step - it's certainly a lot harder than you'd expect (at 
least for a cross-compiler newbie like me ;-))  I was thinking it would be a 
simple matter of compiling a few programs in a certain order and that'd be 
it, but it seems that there are huge differences between versions - the 
instructions use ecgs-1.1.2 and binutils-2.13.2.1, but to compile linux-2.6.0 
you need newer than ecgs-1.1.2, but using gcc-3.x means upgrading to 
binutils-2.14, but then when you've done that gcc-3.x won't compile so you 
try gcc-2.95.3 instead, but that means you have to go back to 
binutils-2.13.2.1 but then gcc-2.95.3 is still too old to compile the kernel, 
so you *need* gcc-3.x but that won't compile...grrr!!! ;-)

Cheers,
Adam.


From echristo@redhat.com Sun Jan 18 05:32:42 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 18 Jan 2004 05:32:42 +0000 (GMT)
Received: from mx2.redhat.com ([IPv6:::ffff:66.187.237.31]:20241 "EHLO
	mx2.redhat.com") by linux-mips.org with ESMTP id <S8225230AbUARFcm>;
	Sun, 18 Jan 2004 05:32:42 +0000
Received: from int-mx2.corp.redhat.com (int-mx2.corp.redhat.com [172.16.27.26])
	by mx2.redhat.com (8.11.6/8.11.6) with ESMTP id i0I59EO19288;
	Sun, 18 Jan 2004 00:09:14 -0500
Received: from potter.sfbay.redhat.com (potter.sfbay.redhat.com [172.16.27.15])
	by int-mx2.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i0I5WbM07335;
	Sun, 18 Jan 2004 00:32:37 -0500
Received: from [192.168.123.101] (vpn26-3.sfbay.redhat.com [172.16.26.3])
	by potter.sfbay.redhat.com (8.11.6/8.11.6) with ESMTP id i0I5Wab13972;
	Sat, 17 Jan 2004 21:32:36 -0800
Subject: Re: Trouble compiling MIPS cross-compiler
From: Eric Christopher <echristo@redhat.com>
To: Adam Nielsen <a.nielsen@optushome.com.au>
Cc: linux-mips@linux-mips.org
In-Reply-To: <200401181510.35686@korath>
References: <200401171711.34964@korath> <200401181119.15234@korath>
	 <1074399252.3602.8.camel@dzur.sfbay.redhat.com> <200401181510.35686@korath>
Content-Type: text/plain
Message-Id: <1074403859.3602.10.camel@dzur.sfbay.redhat.com>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.4.5 (1.4.5-7) 
Date: Sat, 17 Jan 2004 21:31:00 -0800
Content-Transfer-Encoding: 7bit
Return-Path: <echristo@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: 4014
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: echristo@redhat.com
Precedence: bulk
X-list: linux-mips

On Sat, 2004-01-17 at 21:10, Adam Nielsen wrote:
> > You do? What errors? How'd you build the toolchain?
> 

Try this:

http://www.kegel.com/crosstool/

-eric

-- 
Eric Christopher <echristo@redhat.com>


From kumba@gentoo.org Sun Jan 18 05:34:45 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 18 Jan 2004 05:34:45 +0000 (GMT)
Received: from sccrmhc13.comcast.net ([IPv6:::ffff:204.127.202.64]:54914 "EHLO
	sccrmhc13.comcast.net") by linux-mips.org with ESMTP
	id <S8225230AbUARFep>; Sun, 18 Jan 2004 05:34:45 +0000
Received: from gentoo.org (pcp04939029pcs.waldrf01.md.comcast.net[68.48.72.58])
          by comcast.net (sccrmhc13) with SMTP
          id <2004011805343801600gc6t9e>
          (Authid: kumba12345);
          Sun, 18 Jan 2004 05:34:38 +0000
Message-ID: <400A1B5F.6010307@gentoo.org>
Date: Sun, 18 Jan 2004 00:36:31 -0500
From: Kumba <kumba@gentoo.org>
Reply-To: kumba@gentoo.org
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: linux-mips@linux-mips.org
Subject: Re: Trouble compiling MIPS cross-compiler
References: <200401171711.34964@korath> <200401181119.15234@korath> <1074399252.3602.8.camel@dzur.sfbay.redhat.com> <200401181510.35686@korath>
In-Reply-To: <200401181510.35686@korath>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Return-Path: <kumba@gentoo.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: 4015
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: kumba@gentoo.org
Precedence: bulk
X-list: linux-mips

Adam Nielsen wrote:

> I was just following the linux-mips.org FAQ for building a cross compiler.  
> The errors were something to do with missing headers (pthread.h among others) 
> so I tried configuring gcc with --disable-threads as suggested in a post 
> Google found, and so far that seems to be working...except just as I wrote 
> that it came up with this:
> 
> /usr/mips-linux/bin/ld: cannot open crti.o: No such file or directory
> 
> Now I see why it says on the FAQ that building a cross compiler has always 
> been the hardest step - it's certainly a lot harder than you'd expect (at 
> least for a cross-compiler newbie like me ;-))  I was thinking it would be a 
> simple matter of compiling a few programs in a certain order and that'd be 
> it, but it seems that there are huge differences between versions - the 
> instructions use ecgs-1.1.2 and binutils-2.13.2.1, but to compile linux-2.6.0 
> you need newer than ecgs-1.1.2, but using gcc-3.x means upgrading to 
> binutils-2.14, but then when you've done that gcc-3.x won't compile so you 
> try gcc-2.95.3 instead, but that means you have to go back to 
> binutils-2.13.2.1 but then gcc-2.95.3 is still too old to compile the kernel, 
> so you *need* gcc-3.x but that won't compile...grrr!!! ;-)

I can't guarantee the below will work for you, but it has produced a 
cross-compiler on my sparc64 machine (I now use an i686->mips 
cross-compiler), but the instructions should be easily adaptable.

The commands assume you are building in a separate build directory in 
the source tree (i.e. glibc-x.y.z/buildhere/).

I'd recommend the following:
binutils-2.14.90.0.7 (or you can try the latest .8 release, it has some 
more mips fixes in it)
glibc-2.3.2 (or 2.3.1)
gcc-3.3.2

CVS snaps of latest gcc/glibc/binutils may also work as well.


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

# ${myARCH}: Target Architecture
# ${myHOST}: Build Architecture
# ${myDEST}: Install location
# ${myXTRA}: Arch-specific flags to build glibc with


export myARCH=mips-unknown-linux-gnu
export myHOST=sparc-unknown-linux-gnu
export myDEST=/home/crossdev/mips
export myXTRA="-mips3 -mabi=32"

--- binutils ---
../configure \
	--target=${myARCH} --host=${myHOST} \
	--prefix=${myDEST} --enable-shared \
	--enable-64-bit-bfd \
&& make && make install


--- kernel headers ---
cd ${myDEST}
cp -r /usr/include/* ${myDEST}/include/
rm -Rf ${myDEST}/include/linux
rm -Rf ${myDEST}/include/asm*
cp -r /usr/src/linux/include/linux ${myDEST}/include
cp -r /usr/src/linux/include/asm-$(echo ${myARCH} | cut -d- -f1) 
${myDEST}/include
cp -r /usr/src/linux/include/asm-generic ${myDEST}/include
ln -s ${myDEST}/include/asm-$(echo ${myARCH} | cut -d- -f1) 
${myDEST}/include/asm


--- gcc-bootstrap ---
../configure \
	--prefix=${myDEST} --host=${myHOST} \
	--target=${myARCH} --with-newlib \
	--disable-shared --disable-threads \
	--enable-languages=c --disable-multilib \
	--without-headers \
&& make && make install


--- glibc ---
CC="${myARCH}-gcc" CFLAGS="-O2 ${myXTRA}" \
	../configure \
		--prefix=${myDEST} --host=${myARCH} \
		--build=${myHOST} --without-tls \
		--without-__thread \
		--enable-add-ons=linuxthreads \
		--enable-kernel=2.4.0 --with-gd=no \
		--without-cvs --disable-profile \
		--with-headers="${myDEST}/include" \
	&& make && make install


--- gcc-full ---
../configure \
	--prefix=${myDEST} --target=${myARCH} \
	--host=${myHOST} --disable-multilib \
	--enable-shared --enable-languages="c,c++,ada,f77,objc" \
	--enable-nls --without-included-gettext \
	--with-system-zlib --enable-threads=posix \
	--enable-long-long --disable-checking \
	--enable-cstdio=stdio \
	--enable-clocale=generic \
	--enable-__cxa_atexit \
	--enable-version-specific-runtime-libs \
	--with-local-prefix=${prefix}/local \
	--with-libs="${myDEST}/lib" \
	--with-headers="${myDEST}/${myARCH}/include" \
&& make && make install



--Kumba

-- 
"Such is oft the course of deeds that move the wheels of the world: 
small hands do them because they must, while the eyes of the great are 
elsewhere."  --Elrond


From a.nielsen@optushome.com.au Sun Jan 18 06:46:13 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 18 Jan 2004 06:46:14 +0000 (GMT)
Received: from mail012.syd.optusnet.com.au ([IPv6:::ffff:211.29.132.66]:37601
	"EHLO mail012.syd.optusnet.com.au") by linux-mips.org with ESMTP
	id <S8225228AbUARGqN>; Sun, 18 Jan 2004 06:46:13 +0000
Received: from korath.adamsrealm.net.au (c210-49-87-133.rochd3.qld.optusnet.com.au [210.49.87.133])
	by mail012.syd.optusnet.com.au (8.11.6p2/8.11.6) with ESMTP id i0I6k9S17922
	for <linux-mips@linux-mips.org>; Sun, 18 Jan 2004 17:46:09 +1100
From: Adam Nielsen <a.nielsen@optushome.com.au>
To: linux-mips@linux-mips.org
Subject: Re: Trouble compiling MIPS cross-compiler
Date: Sun, 18 Jan 2004 16:46:04 +1000
User-Agent: KMail/1.5
References: <200401171711.34964@korath> <200401181510.35686@korath> <400A1B5F.6010307@gentoo.org>
In-Reply-To: <400A1B5F.6010307@gentoo.org>
MIME-Version: 1.0
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200401181646.04740@korath>
Return-Path: <a.nielsen@optushome.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: 4016
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: a.nielsen@optushome.com.au
Precedence: bulk
X-list: linux-mips

> I'd recommend the following:
> binutils-2.14.90.0.7 (or you can try the latest .8 release, it has some
> more mips fixes in it)
> ...
> gcc-3.3.2

Thanks for all the info!  Well, I tried building gcc-3.3.2 with your options 
and that worked (hooray!) but I couldn't find binutils-2.14.90.0.7, the 
closest I could see was 2.14 so I used that.  It all compiled ok, but now 
when I go to compile the kernel I get this error:

cc1: error: invalid option `cpu=r3000'

If I copy the command line and change -mcpu to -march then it works fine, but 
this isn't happening automatically for some reason.  Any ideas?  (I tried 
downgrading to binutils-2.13.xxx but it still gave the error, so I'm guessing 
it's a gcc problem - oh how much easier life would be if they didn't remove 
the -mcpu option somewhere along the way ;-))

Cheers,
Adam.


From echristo@redhat.com Sun Jan 18 06:58:37 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 18 Jan 2004 06:58:37 +0000 (GMT)
Received: from mx2.redhat.com ([IPv6:::ffff:66.187.237.31]:28690 "EHLO
	mx2.redhat.com") by linux-mips.org with ESMTP id <S8225228AbUARG6h>;
	Sun, 18 Jan 2004 06:58:37 +0000
Received: from int-mx2.corp.redhat.com (int-mx2.corp.redhat.com [172.16.27.26])
	by mx2.redhat.com (8.11.6/8.11.6) with ESMTP id i0I6Z9O23224;
	Sun, 18 Jan 2004 01:35:09 -0500
Received: from potter.sfbay.redhat.com (potter.sfbay.redhat.com [172.16.27.15])
	by int-mx2.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i0I6wWM11989;
	Sun, 18 Jan 2004 01:58:32 -0500
Received: from [192.168.123.101] (vpn26-3.sfbay.redhat.com [172.16.26.3])
	by potter.sfbay.redhat.com (8.11.6/8.11.6) with ESMTP id i0I6wVb15290;
	Sat, 17 Jan 2004 22:58:31 -0800
Subject: Re: Trouble compiling MIPS cross-compiler
From: Eric Christopher <echristo@redhat.com>
To: Adam Nielsen <a.nielsen@optushome.com.au>
Cc: linux-mips@linux-mips.org
In-Reply-To: <200401181646.04740@korath>
References: <200401171711.34964@korath> <200401181510.35686@korath>
	 <400A1B5F.6010307@gentoo.org>  <200401181646.04740@korath>
Content-Type: text/plain
Message-Id: <1074409013.3602.16.camel@dzur.sfbay.redhat.com>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.4.5 (1.4.5-7) 
Date: Sat, 17 Jan 2004 22:56:54 -0800
Content-Transfer-Encoding: 7bit
Return-Path: <echristo@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: 4017
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: echristo@redhat.com
Precedence: bulk
X-list: linux-mips


> If I copy the command line and change -mcpu to -march then it works fine, but 
> this isn't happening automatically for some reason.  Any ideas?  (I tried 
> downgrading to binutils-2.13.xxx but it still gave the error, so I'm guessing 
> it's a gcc problem - oh how much easier life would be if they didn't remove 
> the -mcpu option somewhere along the way ;-))

Actually, I removed it :)

If you'd like the rant behind it I'll mail it privately.

Anyhow, I've been trying to push for the kernel to use either

a) -march depending on whatever cpu is specified
b) -mtune otherwise (this will generate generic code and then tune for
something)

heck. if you do nothing you'll get mips1 code. It should really default
to mips2 (for things like, say, atomic operations), but no one has made
the change and I don't feel strongly enough since I'm using a 64-bit cpu
and n32 :)

-eric

-- 
Eric Christopher <echristo@redhat.com>


From kumba@gentoo.org Sun Jan 18 07:16:56 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 18 Jan 2004 07:16:57 +0000 (GMT)
Received: from sccrmhc12.comcast.net ([IPv6:::ffff:204.127.202.56]:16859 "EHLO
	sccrmhc12.comcast.net") by linux-mips.org with ESMTP
	id <S8225228AbUARHQ4>; Sun, 18 Jan 2004 07:16:56 +0000
Received: from gentoo.org (pcp04939029pcs.waldrf01.md.comcast.net[68.48.72.58])
          by comcast.net (sccrmhc12) with SMTP
          id <200401180716500120028aife>
          (Authid: kumba12345);
          Sun, 18 Jan 2004 07:16:50 +0000
Message-ID: <400A3353.6050903@gentoo.org>
Date: Sun, 18 Jan 2004 02:18:43 -0500
From: Kumba <kumba@gentoo.org>
Reply-To: kumba@gentoo.org
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: linux-mips@linux-mips.org
Subject: Re: Trouble compiling MIPS cross-compiler
References: <200401171711.34964@korath> <200401181510.35686@korath> <400A1B5F.6010307@gentoo.org> <200401181646.04740@korath>
In-Reply-To: <200401181646.04740@korath>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Return-Path: <kumba@gentoo.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: 4018
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: kumba@gentoo.org
Precedence: bulk
X-list: linux-mips

Adam Nielsen wrote:

> Thanks for all the info!  Well, I tried building gcc-3.3.2 with your options 
> and that worked (hooray!) but I couldn't find binutils-2.14.90.0.7, the 
> closest I could see was 2.14 so I used that.  It all compiled ok, but now 
> when I go to compile the kernel I get this error:
> 
> cc1: error: invalid option `cpu=r3000'

http://www.kernel.org/pub/linux/devel/binutils/

The 2.14.90.0.X series of binutils is a linux-only release maintained by 
HJ Lu, while the 2.14 version is more or less the official GNU version.

As for the kernel, -mcpu was deprecated in gcc-3.2.x, and totally 
removed in gcc-3.3.x.  You'll want to use the -march option (or 
-mips[1234] as a synonym), although if you use a recent kernel source 
tree off linux-mips anoncvs, selecting the right CPU/Machinetype in 
menuconfig will supply the proper -march/-mipsX commands to the 
compiler.  You'll also want to pass something like this:

make ARCH=mips CROSS_COMPILE=mips-unknown-linux-gnu- <target>

Note: CROSS_COMPILE needs to be set to the CHOST the cross compiler was 
built with, in my cases, I use the extended CHOST form.  The more common 
form is mips[el]-linux (or mips64[el]-linux)

For 2.4, if you want a mips64 kernel, pass ARCH=mips64.  For 2.6, pass 
ARCH=mips and select 64-bit mode in menuconfig (or oldconfig or xconfig)


--Kumba

-- 
"Such is oft the course of deeds that move the wheels of the world: 
small hands do them because they must, while the eyes of the great are 
elsewhere."  --Elrond


From echristo@redhat.com Sun Jan 18 07:19:41 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 18 Jan 2004 07:19:41 +0000 (GMT)
Received: from mx2.redhat.com ([IPv6:::ffff:66.187.237.31]:17415 "EHLO
	mx2.redhat.com") by linux-mips.org with ESMTP id <S8225228AbUARHTl>;
	Sun, 18 Jan 2004 07:19:41 +0000
Received: from int-mx2.corp.redhat.com (int-mx2.corp.redhat.com [172.16.27.26])
	by mx2.redhat.com (8.11.6/8.11.6) with ESMTP id i0I6uFO24266;
	Sun, 18 Jan 2004 01:56:15 -0500
Received: from potter.sfbay.redhat.com (potter.sfbay.redhat.com [172.16.27.15])
	by int-mx2.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i0I7JcM13238;
	Sun, 18 Jan 2004 02:19:38 -0500
Received: from [192.168.123.101] (vpn26-3.sfbay.redhat.com [172.16.26.3])
	by potter.sfbay.redhat.com (8.11.6/8.11.6) with ESMTP id i0I7Jbb15858;
	Sat, 17 Jan 2004 23:19:37 -0800
Subject: Re: Trouble compiling MIPS cross-compiler
From: Eric Christopher <echristo@redhat.com>
To: kumba@gentoo.org
Cc: linux-mips@linux-mips.org
In-Reply-To: <400A3353.6050903@gentoo.org>
References: <200401171711.34964@korath> <200401181510.35686@korath>
	 <400A1B5F.6010307@gentoo.org> <200401181646.04740@korath>
	 <400A3353.6050903@gentoo.org>
Content-Type: text/plain
Message-Id: <1074410279.3602.18.camel@dzur.sfbay.redhat.com>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.4.5 (1.4.5-7) 
Date: Sat, 17 Jan 2004 23:17:59 -0800
Content-Transfer-Encoding: 7bit
Return-Path: <echristo@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: 4019
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: echristo@redhat.com
Precedence: bulk
X-list: linux-mips


> -mips[1234] as a synonym), although if you use a recent kernel source 
> tree off linux-mips anoncvs, selecting the right CPU/Machinetype in 
> menuconfig will supply the proper -march/-mipsX commands to the 
> compiler.  You'll also want to pass something like this:

Hey, cool. Glad to hear that.

-eric

-- 
Eric Christopher <echristo@redhat.com>


From ica2_ts@csv.ica.uni-stuttgart.de Sun Jan 18 07:28:26 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 18 Jan 2004 07:28:26 +0000 (GMT)
Received: from iris1.csv.ica.uni-stuttgart.de ([IPv6:::ffff:129.69.118.2]:37684
	"EHLO iris1.csv.ica.uni-stuttgart.de") by linux-mips.org with ESMTP
	id <S8225228AbUARH20>; Sun, 18 Jan 2004 07:28:26 +0000
Received: from rembrandt.csv.ica.uni-stuttgart.de ([129.69.118.42])
	by iris1.csv.ica.uni-stuttgart.de with esmtp
	id 1Ai7M9-0000rz-00
	for <linux-mips@linux-mips.org>; Sun, 18 Jan 2004 08:28:25 +0100
Received: from ica2_ts by rembrandt.csv.ica.uni-stuttgart.de with local (Exim 3.35 #1 (Debian))
	id 1Ai7M8-0007LH-00
	for <linux-mips@linux-mips.org>; Sun, 18 Jan 2004 08:28:24 +0100
Date: Sun, 18 Jan 2004 08:28:24 +0100
To: linux-mips@linux-mips.org
Subject: Re: Trouble compiling MIPS cross-compiler
Message-ID: <20040118072824.GU22218@rembrandt.csv.ica.uni-stuttgart.de>
References: <200401171711.34964@korath> <200401181510.35686@korath> <400A1B5F.6010307@gentoo.org> <200401181646.04740@korath> <1074409013.3602.16.camel@dzur.sfbay.redhat.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <1074409013.3602.16.camel@dzur.sfbay.redhat.com>
User-Agent: Mutt/1.5.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: 4020
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

Eric Christopher wrote:
> 
> > If I copy the command line and change -mcpu to -march then it works fine, but 
> > this isn't happening automatically for some reason.  Any ideas?  (I tried 
> > downgrading to binutils-2.13.xxx but it still gave the error, so I'm guessing 
> > it's a gcc problem - oh how much easier life would be if they didn't remove 
> > the -mcpu option somewhere along the way ;-))
> 
> Actually, I removed it :)
> 
> If you'd like the rant behind it I'll mail it privately.
> 
> Anyhow, I've been trying to push for the kernel to use either
> 
> a) -march depending on whatever cpu is specified

AFAICS current CVS defaults to that (modulo changing it immediately
afterwards to the generic base arch by an superfluous -mipsX option).

> b) -mtune otherwise (this will generate generic code and then tune for
> something)

Actually, -mtune=r3900 breaks the "generic" part due to an assembler bug
(and did so for a long time).


Thiemo

From zhufeng@koretide.com.cn Sun Jan 18 07:33:59 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 18 Jan 2004 07:33:59 +0000 (GMT)
Received: from p508B7A82.dip.t-dialin.net ([IPv6:::ffff:80.139.122.130]:22218
	"EHLO p508B7A82.dip.t-dialin.net") by linux-mips.org with ESMTP
	id <S8225228AbUARHd7>; Sun, 18 Jan 2004 07:33:59 +0000
Received: from [IPv6:::ffff:210.22.155.234] ([IPv6:::ffff:210.22.155.234]:56765
	"EHLO mail.koretide.com.cn") by linux-mips.net with ESMTP
	id <S868646AbUARHd5>; Sun, 18 Jan 2004 08:33:57 +0100
Received: from zfeng (tu214024.tsinghua.edu.cn [166.111.214.24])
	(authenticated)
	by mail.koretide.com.cn (8.11.6/8.11.6) with ESMTP id i0I7T3f05087
	for <linux-mips@linux-mips.org>; Sun, 18 Jan 2004 15:29:03 +0800
From: "??\(zhufeng\)" <zhufeng@koretide.com.cn>
To: <linux-mips@linux-mips.org>
Subject: Unscribe this maillist.
Date: Sun, 18 Jan 2004 15:35:53 +0800
Message-ID: <MHEOIAELPBMEEADNOIJPIEIKCDAA.zhufeng@koretide.com.cn>
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 IMO, Build 9.0.2416 (9.0.2910.0)
In-Reply-To: <20040118072824.GU22218@rembrandt.csv.ica.uni-stuttgart.de>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Return-Path: <zhufeng@koretide.com.cn>
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: 4021
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: zhufeng@koretide.com.cn
Precedence: bulk
X-list: linux-mips

Unscribe this maillist,thank you .


From a.nielsen@optushome.com.au Sun Jan 18 08:04:43 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 18 Jan 2004 08:04:44 +0000 (GMT)
Received: from mail009.syd.optusnet.com.au ([IPv6:::ffff:211.29.132.64]:29338
	"EHLO mail009.syd.optusnet.com.au") by linux-mips.org with ESMTP
	id <S8225228AbUARIEn>; Sun, 18 Jan 2004 08:04:43 +0000
Received: from korath.adamsrealm.net.au (c210-49-87-133.rochd3.qld.optusnet.com.au [210.49.87.133])
	by mail009.syd.optusnet.com.au (8.11.6p2/8.11.6) with ESMTP id i0I84a129645
	for <linux-mips@linux-mips.org>; Sun, 18 Jan 2004 19:04:39 +1100
From: Adam Nielsen <a.nielsen@optushome.com.au>
To: linux-mips@linux-mips.org
Subject: Re: Trouble compiling MIPS cross-compiler
Date: Sun, 18 Jan 2004 18:04:31 +1000
User-Agent: KMail/1.5
References: <200401171711.34964@korath> <200401181646.04740@korath> <400A3353.6050903@gentoo.org>
In-Reply-To: <400A3353.6050903@gentoo.org>
MIME-Version: 1.0
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200401181804.31114@korath>
Return-Path: <a.nielsen@optushome.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: 4022
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: a.nielsen@optushome.com.au
Precedence: bulk
X-list: linux-mips

> As for the kernel, -mcpu was deprecated in gcc-3.2.x, and totally 
> removed in gcc-3.3.x.  You'll want to use the -march option (or 
> -mips[1234] as a synonym), although if you use a recent kernel source 
> tree off linux-mips anoncvs, selecting the right CPU/Machinetype in 
> menuconfig will supply the proper -march/-mipsX commands to the 
> compiler.

Oh ok then - so what should I do to actually compile a MIPS kernel?  I'd 
rather not have to download an entirely separate kernel source, so should I 
just go back to gcc-3.1.1 that supports -mcpu?

Will kernel 2.6.1 or whatever's next work properly in this respect?  I realise 
that there are plenty of valid reasons for removing -mcpu, but it does create 
a big headache for us users, who just want the darn thing to 'go' ;-)

> You'll also want to pass something like this:
> make ARCH=mips CROSS_COMPILE=mips-unknown-linux-gnu- <target>

Oh ok - yes, I sort of guessed how to do this as it wasn't written anywhere, 
and I used "mips-linux" for everything so all should be well there.

At any rate, I think I'll have to call it a day - it's way too much of a 
hassle just to get a working MIPS cross-compiler, and with all the hoops you 
have to jump through I haven't got any patience left :-(

Thanks for all your help everyone,
Adam.


From kumba@gentoo.org Sun Jan 18 08:11:20 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 18 Jan 2004 08:11:21 +0000 (GMT)
Received: from sccrmhc13.comcast.net ([IPv6:::ffff:204.127.202.64]:52131 "EHLO
	sccrmhc13.comcast.net") by linux-mips.org with ESMTP
	id <S8225228AbUARILU>; Sun, 18 Jan 2004 08:11:20 +0000
Received: from gentoo.org (pcp04939029pcs.waldrf01.md.comcast.net[68.48.72.58])
          by comcast.net (sccrmhc13) with SMTP
          id <2004011808111401600gc9t7e>
          (Authid: kumba12345);
          Sun, 18 Jan 2004 08:11:14 +0000
Message-ID: <400A4014.2070703@gentoo.org>
Date: Sun, 18 Jan 2004 03:13:08 -0500
From: Kumba <kumba@gentoo.org>
Reply-To: kumba@gentoo.org
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: linux-mips@linux-mips.org
Subject: Re: Trouble compiling MIPS cross-compiler
References: <200401171711.34964@korath> <200401181646.04740@korath> <400A3353.6050903@gentoo.org> <200401181804.31114@korath>
In-Reply-To: <200401181804.31114@korath>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Return-Path: <kumba@gentoo.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: 4023
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: kumba@gentoo.org
Precedence: bulk
X-list: linux-mips

Adam Nielsen wrote:


> Oh ok then - so what should I do to actually compile a MIPS kernel?  I'd 
> rather not have to download an entirely separate kernel source, so should I 
> just go back to gcc-3.1.1 that supports -mcpu?
> 
> Will kernel 2.6.1 or whatever's next work properly in this respect?  I realise 
> that there are plenty of valid reasons for removing -mcpu, but it does create 
> a big headache for us users, who just want the darn thing to 'go' ;-)

Get the anonymous cvs info for the linux-mips CVS server from the 
linux-mips.org homepage.  That's the source you want to use for mips 
kernels.  For 2.4, you'll need to checkout the linux_2_4 tag, otherwise 
HEAD will give you 2.6 source.

If you are using a setup that relies on -mcpu, I'd look more at changing 
the setup to use something else, since -mcpu is deprecated in gcc for 
mips for all newer toolchains from 3.3 and beyond.


--Kumba

-- 
"Such is oft the course of deeds that move the wheels of the world: 
small hands do them because they must, while the eyes of the great are 
elsewhere."  --Elrond


From dimitri@sonycom.com Sun Jan 18 09:23:21 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 18 Jan 2004 09:23:22 +0000 (GMT)
Received: from witte.sonytel.be ([IPv6:::ffff:80.88.33.193]:65514 "EHLO
	witte.sonytel.be") by linux-mips.org with ESMTP id <S8225228AbUARJXV>;
	Sun, 18 Jan 2004 09:23:21 +0000
Received: from teasel.sonytel.be (localhost [127.0.0.1])
	by witte.sonytel.be (8.12.10/8.12.10) with ESMTP id i0I9NKw1000626
	for <linux-mips@linux-mips.org>; Sun, 18 Jan 2004 10:23:20 +0100 (MET)
Received: (from dimitri@localhost)
	by teasel.sonytel.be (8.9.3+Sun/8.9.3) id KAA22075
	for linux-mips@linux-mips.org; Sun, 18 Jan 2004 10:23:19 +0100 (MET)
Date: Sun, 18 Jan 2004 10:23:19 +0100
From: Dimitri Torfs <dimitri@sonycom.com>
To: linux-mips@linux-mips.org
Subject: Re: VR4131 - MQ1132 - UPD63335
Message-ID: <20040118092318.GA22052@sonycom.com>
References: <40079391.7080301@mistralsoftware.com> <20040117122022.GD5288@linux-mips.org> <20040117125142.GX14285@lug-owl.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20040117125142.GX14285@lug-owl.de>
User-Agent: Mutt/1.4.1i
Return-Path: <dimitri@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: 4024
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: dimitri@sonycom.com
Precedence: bulk
X-list: linux-mips

On Sat, Jan 17, 2004 at 01:51:42PM +0100, Jan-Benedict Glaw wrote:
> On Sat, 2004-01-17 13:20:22 +0100, Ralf Baechle <ralf@linux-mips.org>
> wrote in message <20040117122022.GD5288@linux-mips.org>:
> > #define FOO_BASE	0x12340000UL		/* physical address */
>                         ^^^^^^^^^^
> > #define FOO_SIZE	0x00001000UL
> > 
> > 	base = ioremap(0x1234, FOO_SIZE);
>                        ^^^^^^
> Not FOO_BASE?
> 

And it's better to use writel/readl and friends on thingies returned by
ioremap:

      struct foo_regs* foo = ioremap(FOO_BASE, FOO_SIZE);
      ...      
      writel(42, &foo->blinkenlight);


Dimitri


-- 
Dimitri Torfs       |  NSCE 
dimitri@sonycom.com |  The Corporate Village
tel: +32 2 7008541  |  Da Vincilaan 7 - D1 
fax: +32 2 7008622  |  B-1935 Zaventem - Belgium


From geert@linux-m68k.org Sun Jan 18 10:05:41 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 18 Jan 2004 10:05:42 +0000 (GMT)
Received: from witte.sonytel.be ([IPv6:::ffff:80.88.33.193]:2958 "EHLO
	witte.sonytel.be") by linux-mips.org with ESMTP id <S8225228AbUARKFl>;
	Sun, 18 Jan 2004 10:05:41 +0000
Received: from waterleaf.sonytel.be (localhost [127.0.0.1])
	by witte.sonytel.be (8.12.10/8.12.10) with ESMTP id i0IA5dw2003939;
	Sun, 18 Jan 2004 11:05:40 +0100 (MET)
Date: Sun, 18 Jan 2004 11:05:37 +0100 (MET)
From: Geert Uytterhoeven <geert@linux-m68k.org>
To: Adam Nielsen <a.nielsen@optushome.com.au>
cc: Linux/MIPS Development <linux-mips@linux-mips.org>
Subject: Re: Trouble compiling MIPS cross-compiler
In-Reply-To: <200401181804.31114@korath>
Message-ID: <Pine.GSO.4.58.0401181102370.2808@waterleaf.sonytel.be>
References: <200401171711.34964@korath> <200401181646.04740@korath>
 <400A3353.6050903@gentoo.org> <200401181804.31114@korath>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <geert@linux-m68k.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: 4025
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 Sun, 18 Jan 2004, Adam Nielsen wrote:
> At any rate, I think I'll have to call it a day - it's way too much of a
> hassle just to get a working MIPS cross-compiler, and with all the hoops you
> have to jump through I haven't got any patience left :-(

If you have Debian (use at least testing, not stable):
  - apt-get install toolchain-source
  - Follow the instructions in /usr/share/doc/toolchain-source/README

and you'll have a cross-compiler for whatever supported architecture in less
than an hour (depending on the speed of your host machine, of course).

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 echristo@redhat.com Sun Jan 18 19:42:56 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 18 Jan 2004 19:42:57 +0000 (GMT)
Received: from mx2.redhat.com ([IPv6:::ffff:66.187.237.31]:61961 "EHLO
	mx2.redhat.com") by linux-mips.org with ESMTP id <S8225226AbUARTm4>;
	Sun, 18 Jan 2004 19:42:56 +0000
Received: from int-mx2.corp.redhat.com (int-mx2.corp.redhat.com [172.16.27.26])
	by mx2.redhat.com (8.11.6/8.11.6) with ESMTP id i0IJJPO31300;
	Sun, 18 Jan 2004 14:19:25 -0500
Received: from potter.sfbay.redhat.com (potter.sfbay.redhat.com [172.16.27.15])
	by int-mx2.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i0IJgjM28851;
	Sun, 18 Jan 2004 14:42:45 -0500
Received: from [192.168.123.101] (vpn26-3.sfbay.redhat.com [172.16.26.3])
	by potter.sfbay.redhat.com (8.11.6/8.11.6) with ESMTP id i0IJgib32757;
	Sun, 18 Jan 2004 11:42:44 -0800
Subject: Re: Trouble compiling MIPS cross-compiler
From: Eric Christopher <echristo@redhat.com>
To: Thiemo Seufer <ica2_ts@csv.ica.uni-stuttgart.de>
Cc: linux-mips@linux-mips.org
In-Reply-To: <20040118072824.GU22218@rembrandt.csv.ica.uni-stuttgart.de>
References: <200401171711.34964@korath> <200401181510.35686@korath>
	 <400A1B5F.6010307@gentoo.org> <200401181646.04740@korath>
	 <1074409013.3602.16.camel@dzur.sfbay.redhat.com>
	 <20040118072824.GU22218@rembrandt.csv.ica.uni-stuttgart.de>
Content-Type: text/plain
Message-Id: <1074454861.310.0.camel@dzur.sfbay.redhat.com>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.4.5 (1.4.5-7) 
Date: Sun, 18 Jan 2004 11:41:02 -0800
Content-Transfer-Encoding: 7bit
Return-Path: <echristo@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: 4026
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: echristo@redhat.com
Precedence: bulk
X-list: linux-mips


> > b) -mtune otherwise (this will generate generic code and then tune for
> > something)
> 
> Actually, -mtune=r3900 breaks the "generic" part due to an assembler bug
> (and did so for a long time).

Hard to fix it if I don't know about it :)

What's the bug?

-eric

-- 
Eric Christopher <echristo@redhat.com>


From dimitri@sonycom.com Sun Jan 18 19:50:09 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 18 Jan 2004 19:50:10 +0000 (GMT)
Received: from witte.sonytel.be ([IPv6:::ffff:80.88.33.193]:15834 "EHLO
	witte.sonytel.be") by linux-mips.org with ESMTP id <S8225226AbUARTuJ>;
	Sun, 18 Jan 2004 19:50:09 +0000
Received: from teasel.sonytel.be (localhost [127.0.0.1])
	by witte.sonytel.be (8.12.10/8.12.10) with ESMTP id i0IJo7w1018508
	for <linux-mips@linux-mips.org>; Sun, 18 Jan 2004 20:50:08 +0100 (MET)
Received: (from dimitri@localhost)
	by teasel.sonytel.be (8.9.3+Sun/8.9.3) id UAA22663
	for linux-mips@linux-mips.org; Sun, 18 Jan 2004 20:50:06 +0100 (MET)
Date: Sun, 18 Jan 2004 20:50:06 +0100
From: Dimitri Torfs <dimitri@sonycom.com>
To: linux-mips@linux-mips.org
Subject: DMA_NONCOHERENT and dma_map_single
Message-ID: <20040118195006.GA22616@sonycom.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.4.1i
Return-Path: <dimitri@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: 4027
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: dimitri@sonycom.com
Precedence: bulk
X-list: linux-mips

Hi,

  dma_map_single() is supposed to be called on a buffer that exactly
  starts and ends on a cacheline boundary, otherwise "bad things"
  (e.g. overwrite of data that was written by device, ...) (especially
  on dma non-coherent systems) may happen. 

  So what should be done when dma_map_single is not called
  with a sane (ptr, size) argument ?

    - is the driver (caller) considered buggy and should we return a 0
      return-value ?
    - is the driver (caller) considered buggy but we do the mapping
      anyway, hoping that the driver has not/will not touched/touch
      the boundary cachelines ?
    - should we take appropriate actions to make sure the
      cache-effects do not come into play (e.g. by using some kind of
      bounce buffer) ?


  Dimitri

-- 
Dimitri Torfs       |  NSCE 
dimitri@sonycom.com |  The Corporate Village
tel: +32 2 7008541  |  Da Vincilaan 7 - D1 
fax: +32 2 7008622  |  B-1935 Zaventem - Belgium


From ralf@linux-mips.org Sun Jan 18 23:05:37 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 18 Jan 2004 23:05:37 +0000 (GMT)
Received: from p508B7A82.dip.t-dialin.net ([IPv6:::ffff:80.139.122.130]:32840
	"EHLO mail.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225474AbUARXFY>; Sun, 18 Jan 2004 23:05:24 +0000
Received: from fluff.linux-mips.net (fluff.linux-mips.net [127.0.0.1])
	by mail.linux-mips.net (8.12.8/8.12.8) with ESMTP id i0IN5M4P003483;
	Mon, 19 Jan 2004 00:05:22 +0100
Received: (from ralf@localhost)
	by fluff.linux-mips.net (8.12.8/8.12.8/Submit) id i0IN5J4W003482;
	Mon, 19 Jan 2004 00:05:19 +0100
Date: Mon, 19 Jan 2004 00:05:19 +0100
From: Ralf Baechle <ralf@linux-mips.org>
To: Dimitri Torfs <dimitri@sonycom.com>
Cc: linux-mips@linux-mips.org
Subject: Re: DMA_NONCOHERENT and dma_map_single
Message-ID: <20040118230519.GA31919@linux-mips.org>
References: <20040118195006.GA22616@sonycom.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20040118195006.GA22616@sonycom.com>
User-Agent: Mutt/1.4.1i
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: 4028
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 18, 2004 at 08:50:06PM +0100, Dimitri Torfs wrote:

>   dma_map_single() is supposed to be called on a buffer that exactly
>   starts and ends on a cacheline boundary, otherwise "bad things"
>   (e.g. overwrite of data that was written by device, ...) (especially
>   on dma non-coherent systems) may happen. 
> 
>   So what should be done when dma_map_single is not called
>   with a sane (ptr, size) argument ?
> 
>     - is the driver (caller) considered buggy and should we return a 0
>       return-value ?
>     - is the driver (caller) considered buggy but we do the mapping
>       anyway, hoping that the driver has not/will not touched/touch
>       the boundary cachelines ?

The driver is considered buggy;  dma_map_single's behaviour is undefined so
it's perfectly ok if it paints neighbour's cat pink ;-)

>     - should we take appropriate actions to make sure the
>       cache-effects do not come into play (e.g. by using some kind of
>       bounce buffer) ?

Technically bounce buffers can be handled inside dma_map_single & co but
it's not a good idea.  Better set the appropriate flags so higher levels
can allocate memory with the appropriate GFP_* flags and thereby hopefully
avoid overly frequent buffer bouncing.

  Ralf

From yaelgilad@myrealbox.com Sun Jan 18 23:16:18 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 18 Jan 2004 23:16:19 +0000 (GMT)
Received: from smtp-send.myrealbox.com ([IPv6:::ffff:192.108.102.143]:52346
	"EHLO smtp-send.myrealbox.com") by linux-mips.org with ESMTP
	id <S8225226AbUARXQS> convert rfc822-to-8bit; Sun, 18 Jan 2004 23:16:18 +0000
Received: from yaelgilad [82.166.46.79] by myrealbox.com
	with NetMail ModWeb Module; Sun, 18 Jan 2004 23:16:20 +0000
Subject: "-G" optimizations
From: "Gilad Benjamini" <yaelgilad@myrealbox.com>
To: linux-mips@linux-mips.org
Date: Sun, 18 Jan 2004 23:16:20 +0000
X-Mailer: NetMail ModWeb Module
X-Sender: yaelgilad
MIME-Version: 1.0
Message-ID: <1074467780.c913e0a0yaelgilad@myrealbox.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8BIT
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: 4029
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,
If I understand correctly, "-G" flag tells gcc that
static variables below a certain size are placed
in a small area that allows easier access to them by
avoiding the two step load.
Ralf's reply to a question on the same issue I posted
a year ago, implied that this optimization is not
available in mips kernel.
Is it ?

I ran into an existing project where the kernel
was compiled with "-G0" while a module was compiled
with "-G8".
Is this a legal combination ?
If it isn't, what could the implications be ?
TIA



From ralf@linux-mips.org Mon Jan 19 06:24:18 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 19 Jan 2004 06:24:18 +0000 (GMT)
Received: from p508B617B.dip.t-dialin.net ([IPv6:::ffff:80.139.97.123]:35682
	"EHLO mail.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225200AbUASGYS>; Mon, 19 Jan 2004 06:24:18 +0000
Received: from fluff.linux-mips.net (fluff.linux-mips.net [127.0.0.1])
	by mail.linux-mips.net (8.12.8/8.12.8) with ESMTP id i0J6OH4P010336;
	Mon, 19 Jan 2004 07:24:17 +0100
Received: (from ralf@localhost)
	by fluff.linux-mips.net (8.12.8/8.12.8/Submit) id i0J6OGJf010335;
	Mon, 19 Jan 2004 07:24:16 +0100
Date: Mon, 19 Jan 2004 07:24:16 +0100
From: Ralf Baechle <ralf@linux-mips.org>
To: Gilad Benjamini <yaelgilad@myrealbox.com>
Cc: linux-mips@linux-mips.org
Subject: Re: "-G" optimizations
Message-ID: <20040119062416.GB31919@linux-mips.org>
References: <1074467780.c913e0a0yaelgilad@myrealbox.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <1074467780.c913e0a0yaelgilad@myrealbox.com>
User-Agent: Mutt/1.4.1i
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: 4030
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 18, 2004 at 11:16:20PM +0000, Gilad Benjamini wrote:

> was compiled with "-G0" while a module was compiled
> with "-G8".
> Is this a legal combination ?
> If it isn't, what could the implications be ?

It's never legal.  The -G option addresses data relative to $28 but Linux
uses it already to store the current pointer.

  Ralf

From karthik_96cse@yahoo.com Mon Jan 19 07:42:21 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 19 Jan 2004 07:42:22 +0000 (GMT)
Received: from web10106.mail.yahoo.com ([IPv6:::ffff:216.136.130.56]:60278
	"HELO web10106.mail.yahoo.com") by linux-mips.org with SMTP
	id <S8225266AbUASHmV>; Mon, 19 Jan 2004 07:42:21 +0000
Message-ID: <20040119074219.15886.qmail@web10106.mail.yahoo.com>
Received: from [128.107.253.43] by web10106.mail.yahoo.com via HTTP; Mon, 19 Jan 2004 07:42:19 GMT
Date: Mon, 19 Jan 2004 07:42:19 +0000 (GMT)
From: =?iso-8859-1?q?karthikeyan=20natarajan?= <karthik_96cse@yahoo.com>
Subject: In r4k, where does PC point to?
To: linux-mips@linux-mips.org
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Return-Path: <karthik_96cse@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: 4032
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: karthik_96cse@yahoo.com
Precedence: bulk
X-list: linux-mips
Content-Length: 1102
Lines: 31

Hi All,

    Basically, the PC points to the next instruction
to
be executed. But, in R4k, there are 8 instructions
getting executed in parallel. Where does the PC point
to? My understanding is that PC points to the next 
instruction that will be entered into the pipeline.
    Please correct me if i am wrong..

Thanks,
-karthi


=====
The expert at anything was once a beginner
                  ______________________________
                 /                              \
             O  /      Karthikeyan.N             \
           O   |       Chennai, India.            |
    `\|||/'     \    Mobile: +919884104346       /
     (o o)       \                              /
_ ooO (_) Ooo____________________________________
_____|_____|_____|_____|_____|_____|_____|_____|_
__|_____|_____|_____|_____|_____|_____|_____|____
_____|_____|_____|_____|_____|_____|_____|_____|_

________________________________________________________________________
Yahoo! Messenger - Communicate instantly..."Ping" 
your friends today! Download Messenger Now 
http://uk.messenger.yahoo.com/download/index.html

From ralf@linux-mips.org Mon Jan 19 12:58:26 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 19 Jan 2004 12:58:26 +0000 (GMT)
Received: from p508B617B.dip.t-dialin.net ([IPv6:::ffff:80.139.97.123]:30473
	"EHLO mail.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225531AbUASM60>; Mon, 19 Jan 2004 12:58:26 +0000
Received: from fluff.linux-mips.net (fluff.linux-mips.net [127.0.0.1])
	by mail.linux-mips.net (8.12.8/8.12.8) with ESMTP id i0JCwKex007180;
	Mon, 19 Jan 2004 13:58:20 +0100
Received: (from ralf@localhost)
	by fluff.linux-mips.net (8.12.8/8.12.8/Submit) id i0JCwIr4007179;
	Mon, 19 Jan 2004 13:58:18 +0100
Date: Mon, 19 Jan 2004 13:58:18 +0100
From: Ralf Baechle <ralf@linux-mips.org>
To: Christoph Hellwig <hch@lst.de>
Cc: Yoichi Yuasa <yuasa@hh.iij4u.or.jp>,
	linux-mips <linux-mips@linux-mips.org>
Subject: Re: [PATCH][2.6] Update NEC VRC4171 PCMCIA driver
Message-ID: <20040119125818.GD6312@linux-mips.org>
References: <20040116083821.6b65c69f.yuasa@hh.iij4u.or.jp> <20040116123352.GA13006@lst.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20040116123352.GA13006@lst.de>
User-Agent: Mutt/1.4.1i
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: 4033
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
Content-Length: 330
Lines: 10

On Fri, Jan 16, 2004 at 01:33:52PM +0100, Christoph Hellwig wrote:

> This is most certainly wrong.  Module refcounting handling has moved one
> layer up in 2.6.

To be fair with Yoichi - MIPS has no module support yet in 2.6, it'll need
to be rewritten from scratch so Yoichi didn't have a chance to really
test this ...

  Ralf

From ralf@linux-mips.org Mon Jan 19 14:50:19 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 19 Jan 2004 14:50:20 +0000 (GMT)
Received: from p508B617B.dip.t-dialin.net ([IPv6:::ffff:80.139.97.123]:63754
	"EHLO mail.linux-mips.net") by linux-mips.org with ESMTP
	id <S8224914AbUASOuT>; Mon, 19 Jan 2004 14:50:19 +0000
Received: from fluff.linux-mips.net (fluff.linux-mips.net [127.0.0.1])
	by mail.linux-mips.net (8.12.8/8.12.8) with ESMTP id i0JEoIex009492;
	Mon, 19 Jan 2004 15:50:18 +0100
Received: (from ralf@localhost)
	by fluff.linux-mips.net (8.12.8/8.12.8/Submit) id i0JEoHnU009491;
	Mon, 19 Jan 2004 15:50:17 +0100
Date: Mon, 19 Jan 2004 15:50:17 +0100
From: Ralf Baechle <ralf@linux-mips.org>
To: karthikeyan natarajan <karthik_96cse@yahoo.com>
Cc: linux-mips@linux-mips.org
Subject: Re: In r4k, where does PC point to?
Message-ID: <20040119145017.GA9141@linux-mips.org>
References: <20040119074219.15886.qmail@web10106.mail.yahoo.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20040119074219.15886.qmail@web10106.mail.yahoo.com>
User-Agent: Mutt/1.4.1i
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: 4034
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 19, 2004 at 07:42:19AM +0000, karthikeyan natarajan wrote:

>     Basically, the PC points to the next instruction
> to
> be executed. But, in R4k, there are 8 instructions
> getting executed in parallel. Where does the PC point
> to? My understanding is that PC points to the next 
> instruction that will be entered into the pipeline.
>     Please correct me if i am wrong..

The fact that instructions are issued in a pipeline is not visible in
the EPC value.

  Ralf

From dom@mips.com Mon Jan 19 14:57:26 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 19 Jan 2004 14:57:27 +0000 (GMT)
Received: from alg145.algor.co.uk ([IPv6:::ffff:62.254.210.145]:522 "EHLO
	dmz.algor.co.uk") by linux-mips.org with ESMTP id <S8224914AbUASO50>;
	Mon, 19 Jan 2004 14:57:26 +0000
Received: from alg158.algor.co.uk ([62.254.210.158] helo=olympia.mips.com)
	by dmz.algor.co.uk with esmtp (Exim 3.35 #1 (Debian))
	id 1AialS-0002tb-00; Mon, 19 Jan 2004 14:52:30 +0000
Received: from gladsmuir.algor.co.uk ([172.20.192.66] helo=gladsmuir.mips.com)
	by olympia.mips.com with esmtp (Exim 3.36 #1 (Debian))
	id 1Aiaq1-0000F3-00; Mon, 19 Jan 2004 14:57:13 +0000
From: Dominic Sweetman <dom@mips.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <16395.61512.498041.811385@gladsmuir.mips.com>
Date: Mon, 19 Jan 2004 14:57:12 +0000
To: Ralf Baechle <ralf@linux-mips.org>
Cc: karthikeyan natarajan <karthik_96cse@yahoo.com>,
	linux-mips@linux-mips.org
Subject: Re: In r4k, where does PC point to?
In-Reply-To: <20040119145017.GA9141@linux-mips.org>
References: <20040119074219.15886.qmail@web10106.mail.yahoo.com>
	<20040119145017.GA9141@linux-mips.org>
X-Mailer: VM 6.92 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid
X-MTUK-Scanner: Found to be clean
X-MTUK-SpamCheck: not spam, SpamAssassin (score=-4.864, required 4, AWL,
	BAYES_00)
Return-Path: <dom@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: 4035
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


> >     Basically, the PC points to the next instruction
> > to
> > be executed. But, in R4k, there are 8 instructions
> > getting executed in parallel. Where does the PC point
> > to? My understanding is that PC points to the next 
> > instruction that will be entered into the pipeline.
> >     Please correct me if i am wrong..

Ralf Baechle (ralf@linux-mips.org) writes:
 
> The fact that instructions are issued in a pipeline is not visible in
> the EPC value.

Which is true, but perhaps a bit cryptic given the question.

A MIPS CPU does not have a register called "PC".  In the MIPS
architecture, "PC" is just slang meaning "the address of this
instruction" - and only makes any sense if you're prepared to say
WHICH instruction you mean.

There IS a register called "EPC" (for "exception PC").  When you
take any kind of exception, it's the address of the first instruction
which didn't get run because the CPU took the exception instead.  So
EPC tells you where to jump back to after the exception handler runs.

Did any of that make any sense?

--
Dominic Sweetman
MIPS Technologies.





From karthik_96cse@yahoo.com Mon Jan 19 15:14:05 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 19 Jan 2004 15:14:06 +0000 (GMT)
Received: from web10106.mail.yahoo.com ([IPv6:::ffff:216.136.130.56]:4015 "HELO
	web10106.mail.yahoo.com") by linux-mips.org with SMTP
	id <S8225222AbUASPOF>; Mon, 19 Jan 2004 15:14:05 +0000
Message-ID: <20040119151403.71569.qmail@web10106.mail.yahoo.com>
Received: from [128.107.253.43] by web10106.mail.yahoo.com via HTTP; Mon, 19 Jan 2004 15:14:03 GMT
Date: Mon, 19 Jan 2004 15:14:03 +0000 (GMT)
From: =?iso-8859-1?q?karthikeyan=20natarajan?= <karthik_96cse@yahoo.com>
Subject: Re: In r4k, where does PC point to?
To: Dominic Sweetman <dom@mips.com>, Ralf Baechle <ralf@linux-mips.org>
Cc: linux-mips@linux-mips.org
In-Reply-To: <16395.61512.498041.811385@gladsmuir.mips.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Return-Path: <karthik_96cse@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: 4036
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: karthik_96cse@yahoo.com
Precedence: bulk
X-list: linux-mips

Hi Dominic Sweetman,

> > >     Basically, the PC points to the next
> instruction
> > > to
> > > be executed. But, in R4k, there are 8
> instructions
> > > getting executed in parallel. Where does the PC
> point
> > > to? My understanding is that PC points to the
> next 
> > > instruction that will be entered into the
> pipeline.
> > >     Please correct me if i am wrong..
> 
> Ralf Baechle (ralf@linux-mips.org) writes:
>  
> > The fact that instructions are issued in a
> pipeline is not visible in
> > the EPC value.
> 
> Which is true, but perhaps a bit cryptic given the
> question.
> 
> A MIPS CPU does not have a register called "PC".  In

In the r4k user manual, it is mentioned that there is
a special register PC in the core CPU (other than the 
HI & LO special registers). Could you please let me 
know the purpose of this register?

Thanks,
-karthi

> the MIPS
> architecture, "PC" is just slang meaning "the
> address of this
> instruction" - and only makes any sense if you're
> prepared to say
> WHICH instruction you mean.
> 
> There IS a register called "EPC" (for "exception
> PC").  When you
> take any kind of exception, it's the address of the
> first instruction
> which didn't get run because the CPU took the
> exception instead.  So
> EPC tells you where to jump back to after the
> exception handler runs.
> 
> Did any of that make any sense?
> 
> --
> Dominic Sweetman
> MIPS Technologies.
> 
> 
> 
>  

=====
The expert at anything was once a beginner
                  ______________________________
                 /                              \
             O  /      Karthikeyan.N             \
           O   |       Chennai, India.            |
    `\|||/'     \    Mobile: +919884104346       /
     (o o)       \                              /
_ ooO (_) Ooo____________________________________
_____|_____|_____|_____|_____|_____|_____|_____|_
__|_____|_____|_____|_____|_____|_____|_____|____
_____|_____|_____|_____|_____|_____|_____|_____|_

________________________________________________________________________
Yahoo! Messenger - Communicate instantly..."Ping" 
your friends today! Download Messenger Now 
http://uk.messenger.yahoo.com/download/index.html

From ralf@linux-mips.org Mon Jan 19 15:22:16 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 19 Jan 2004 15:22:16 +0000 (GMT)
Received: from p508B617B.dip.t-dialin.net ([IPv6:::ffff:80.139.97.123]:26379
	"EHLO mail.linux-mips.net") by linux-mips.org with ESMTP
	id <S8224914AbUASPWQ>; Mon, 19 Jan 2004 15:22:16 +0000
Received: from fluff.linux-mips.net (fluff.linux-mips.net [127.0.0.1])
	by mail.linux-mips.net (8.12.8/8.12.8) with ESMTP id i0JFMFex010119;
	Mon, 19 Jan 2004 16:22:15 +0100
Received: (from ralf@localhost)
	by fluff.linux-mips.net (8.12.8/8.12.8/Submit) id i0JFMEpK010118;
	Mon, 19 Jan 2004 16:22:14 +0100
Date: Mon, 19 Jan 2004 16:22:14 +0100
From: Ralf Baechle <ralf@linux-mips.org>
To: karthikeyan natarajan <karthik_96cse@yahoo.com>
Cc: Dominic Sweetman <dom@mips.com>, linux-mips@linux-mips.org
Subject: Re: In r4k, where does PC point to?
Message-ID: <20040119152214.GA9933@linux-mips.org>
References: <16395.61512.498041.811385@gladsmuir.mips.com> <20040119151403.71569.qmail@web10106.mail.yahoo.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20040119151403.71569.qmail@web10106.mail.yahoo.com>
User-Agent: Mutt/1.4.1i
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: 4037
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 19, 2004 at 03:14:03PM +0000, karthikeyan natarajan wrote:

> > Which is true, but perhaps a bit cryptic given the
> > question.
> > 
> > A MIPS CPU does not have a register called "PC".  In
> 
> In the r4k user manual, it is mentioned that there is
> a special register PC in the core CPU (other than the 
> HI & LO special registers). Could you please let me 
> know the purpose of this register?

Obviously the CPU needs to know where to fetch the next instruction from
or for computing the destination address of branch and jump instructions
or the value to put into the programmer visible EPC and ErrorEPC registers
etc.  The PC register is an internal register that isn't visible to the
programmer.

  Ralf

From karthik_96cse@yahoo.com Mon Jan 19 15:45:41 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 19 Jan 2004 15:45:50 +0000 (GMT)
Received: from web10108.mail.yahoo.com ([IPv6:::ffff:216.136.130.58]:29802
	"HELO web10108.mail.yahoo.com") by linux-mips.org with SMTP
	id <S8224914AbUASPpl>; Mon, 19 Jan 2004 15:45:41 +0000
Message-ID: <20040119154538.92376.qmail@web10108.mail.yahoo.com>
Received: from [128.107.253.43] by web10108.mail.yahoo.com via HTTP; Mon, 19 Jan 2004 15:45:38 GMT
Date: Mon, 19 Jan 2004 15:45:38 +0000 (GMT)
From: =?iso-8859-1?q?karthikeyan=20natarajan?= <karthik_96cse@yahoo.com>
Subject: Re: In r4k, where does PC point to?
To: Ralf Baechle <ralf@linux-mips.org>
Cc: Dominic Sweetman <dom@mips.com>, linux-mips@linux-mips.org
In-Reply-To: <20040119152214.GA9933@linux-mips.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Return-Path: <karthik_96cse@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: 4038
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: karthik_96cse@yahoo.com
Precedence: bulk
X-list: linux-mips

Hi Ralf,

> > > Which is true, but perhaps a bit cryptic given
> the
> > > question.
> > > 
> > > A MIPS CPU does not have a register called "PC".
>  In
> > 
> > In the r4k user manual, it is mentioned that there
> is
> > a special register PC in the core CPU (other than
> the 
> > HI & LO special registers). Could you please let
> me 
> > know the purpose of this register?
> 
> Obviously the CPU needs to know where to fetch the
> next instruction from

So the PC points to the next instruction to be
fetched,
but it is not visible to the programmer..

> or for computing the destination address of branch
> and jump instructions
> or the value to put into the programmer visible EPC
> and ErrorEPC registers

Am curious to know, how the PC register can be used to

locate the instruction which caused the exception as 
the exception can happen at any one of the eight 
pipeline stages..

Thanks much,
-karthi


> etc.  The PC register is an internal register that
> isn't visible to the
> programmer.

So the bottom line here is PC is internal register and

the EPC is visible to the programmer.. 


Thanks,
-karthi
 
>   Ralf
>  

=====
The expert at anything was once a beginner
                  ______________________________
                 /                              \
             O  /      Karthikeyan.N             \
           O   |       Chennai, India.            |
    `\|||/'     \    Mobile: +919884104346       /
     (o o)       \                              /
_ ooO (_) Ooo____________________________________
_____|_____|_____|_____|_____|_____|_____|_____|_
__|_____|_____|_____|_____|_____|_____|_____|____
_____|_____|_____|_____|_____|_____|_____|_____|_

________________________________________________________________________
Yahoo! Messenger - Communicate instantly..."Ping" 
your friends today! Download Messenger Now 
http://uk.messenger.yahoo.com/download/index.html

From dom@mips.com Mon Jan 19 16:30:33 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 19 Jan 2004 16:30:34 +0000 (GMT)
Received: from alg145.algor.co.uk ([IPv6:::ffff:62.254.210.145]:12042 "EHLO
	dmz.algor.co.uk") by linux-mips.org with ESMTP id <S8225545AbUASQad>;
	Mon, 19 Jan 2004 16:30:33 +0000
Received: from alg158.algor.co.uk ([62.254.210.158] helo=olympia.mips.com)
	by dmz.algor.co.uk with esmtp (Exim 3.35 #1 (Debian))
	id 1AicDZ-00042p-00; Mon, 19 Jan 2004 16:25:37 +0000
Received: from gladsmuir.algor.co.uk ([172.20.192.66] helo=gladsmuir.mips.com)
	by olympia.mips.com with esmtp (Exim 3.36 #1 (Debian))
	id 1AicHr-0003ZL-00; Mon, 19 Jan 2004 16:30:03 +0000
From: Dominic Sweetman <dom@mips.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <16396.1546.496342.570908@gladsmuir.mips.com>
Date: Mon, 19 Jan 2004 16:30:02 +0000
To: =?iso-8859-1?q?karthikeyan=20natarajan?= <karthik_96cse@yahoo.com>
Cc: Dominic Sweetman <dom@mips.com>,
	Ralf Baechle <ralf@linux-mips.org>, linux-mips@linux-mips.org
Subject: Re: In r4k, where does PC point to?
In-Reply-To: <20040119151403.71569.qmail@web10106.mail.yahoo.com>
References: <16395.61512.498041.811385@gladsmuir.mips.com>
	<20040119151403.71569.qmail@web10106.mail.yahoo.com>
X-Mailer: VM 6.92 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid
X-MTUK-Scanner: Found to be clean
X-MTUK-SpamCheck: not spam, SpamAssassin (score=-4.865, required 4, AWL,
	BAYES_00)
Return-Path: <dom@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: 4039
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


Karthi,

One more try:

> > A MIPS CPU does not have a register called "PC".  In...
> 
> In the r4k user manual, it is mentioned that there is
> a special register PC in the core CPU (other than the 
> HI & LO special registers).

OK, by "register" I mean strictly something which is
software-visible - like "$2" or the coprocessor-zero register called
"EPC".

There is no PC register in my sense, and if you've found a manual
claiming that one exists, that manual is wrong - send me URL and
tell me how to find this text.

--
Dominic




From karthik_96cse@yahoo.com Mon Jan 19 16:49:59 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 19 Jan 2004 16:49:59 +0000 (GMT)
Received: from web10102.mail.yahoo.com ([IPv6:::ffff:216.136.130.52]:22797
	"HELO web10102.mail.yahoo.com") by linux-mips.org with SMTP
	id <S8225550AbUASQt7>; Mon, 19 Jan 2004 16:49:59 +0000
Message-ID: <20040119164956.7067.qmail@web10102.mail.yahoo.com>
Received: from [128.107.253.43] by web10102.mail.yahoo.com via HTTP; Mon, 19 Jan 2004 16:49:56 GMT
Date: Mon, 19 Jan 2004 16:49:56 +0000 (GMT)
From: =?iso-8859-1?q?karthikeyan=20natarajan?= <karthik_96cse@yahoo.com>
Subject: Re: In r4k, where does PC point to?
To: Dominic Sweetman <dom@mips.com>
Cc: Ralf Baechle <ralf@linux-mips.org>, linux-mips@linux-mips.org
In-Reply-To: <16396.1546.496342.570908@gladsmuir.mips.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Return-Path: <karthik_96cse@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: 4040
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: karthik_96cse@yahoo.com
Precedence: bulk
X-list: linux-mips

Hi Dominic,

    Thanks for your comment.. replies inline..

> One more try:
> 
> > > A MIPS CPU does not have a register called "PC".
>  In...
> > 
> > In the r4k user manual, it is mentioned that there
> is
> > a special register PC in the core CPU (other than
> the 
> > HI & LO special registers).
> 
> OK, by "register" I mean strictly something which is
> software-visible - like "$2" or the coprocessor-zero
> register called
> "EPC".
> 
> There is no PC register in my sense, and if you've
> found a manual
> claiming that one exists, that manual is wrong -
> send me URL and
> tell me how to find this text.

Here is the link..
http://www.cag.lcs.mit.edu/raw/documents/R4400_Uman_book_Ed2.pdf


    The documentation about the PC is present in the
chapter-1 under the section "CPU Register Overview".

    Please let me know whether this manual is correct.

Thanks much,
-karthi

> --
> Dominic
> 
> 
>  

=====
The expert at anything was once a beginner
                  ______________________________
                 /                              \
             O  /      Karthikeyan.N             \
           O   |       Chennai, India.            |
    `\|||/'     \    Mobile: +919884104346       /
     (o o)       \                              /
_ ooO (_) Ooo____________________________________
_____|_____|_____|_____|_____|_____|_____|_____|_
__|_____|_____|_____|_____|_____|_____|_____|____
_____|_____|_____|_____|_____|_____|_____|_____|_

________________________________________________________________________
Yahoo! Messenger - Communicate instantly..."Ping" 
your friends today! Download Messenger Now 
http://uk.messenger.yahoo.com/download/index.html

From dom@mips.com Mon Jan 19 17:09:01 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 19 Jan 2004 17:09:02 +0000 (GMT)
Received: from alg145.algor.co.uk ([IPv6:::ffff:62.254.210.145]:17162 "EHLO
	dmz.algor.co.uk") by linux-mips.org with ESMTP id <S8225547AbUASRIo>;
	Mon, 19 Jan 2004 17:08:44 +0000
Received: from alg158.algor.co.uk ([62.254.210.158] helo=olympia.mips.com)
	by dmz.algor.co.uk with esmtp (Exim 3.35 #1 (Debian))
	id 1AicoW-0004Xt-00; Mon, 19 Jan 2004 17:03:48 +0000
Received: from gladsmuir.algor.co.uk ([172.20.192.66] helo=gladsmuir.mips.com)
	by olympia.mips.com with esmtp (Exim 3.36 #1 (Debian))
	id 1Aicsv-0004C7-00; Mon, 19 Jan 2004 17:08:21 +0000
From: Dominic Sweetman <dom@mips.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <16396.3844.762068.691269@gladsmuir.mips.com>
Date: Mon, 19 Jan 2004 17:08:20 +0000
To: =?iso-8859-1?q?karthikeyan=20natarajan?= <karthik_96cse@yahoo.com>
Cc: Ralf Baechle <ralf@linux-mips.org>,
	Dominic Sweetman <dom@mips.com>, linux-mips@linux-mips.org
Subject: Re: In r4k, where does PC point to?
In-Reply-To: <20040119154538.92376.qmail@web10108.mail.yahoo.com>
References: <20040119152214.GA9933@linux-mips.org>
	<20040119154538.92376.qmail@web10108.mail.yahoo.com>
X-Mailer: VM 6.92 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid
X-MTUK-Scanner: Found to be clean
X-MTUK-SpamCheck: not spam, SpamAssassin (score=-4.866, required 4, AWL,
	BAYES_00)
Return-Path: <dom@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: 4041
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


> Am curious to know, how the PC register can be used to
> locate the instruction which caused the exception as 
> the exception can happen at any one of the eight 
> pipeline stages..

You can't, of course, because there isn't a "PC register".  But now I
understand your question...

Most MIPS implementations actually respond to all exceptions at the
same pipe-stage.  (If you took exceptions when you first noticed them,
an early-stage event like a I-side TLBmiss might happen before a
D-side TLBmiss for an instruction which is earlier in the instruction
stream... and that would be bad.  We're pretending this is a
sequential processor).

So exception conditions detected early in the pipe set a flag which is
then carried down the pipeline and always looked at in the same stage.

The choice of which stage to do this is somewhat implementation
dependent; it wants to be the last stage where you can find out that
an exception is needed.  Generally that will be about the same time as
you'd access the D-cache (you may get exceptions when you're
translating the D-address).

So there needs to be a way to figure out the address where the
instruction currently at the "X" pipestage came from.  You need that
for exceptions; but you also need it (for example) when executing a
'jal' instruction and figuring out the return address.

A conceptually simple way to do this is to carry the instruction's
address along the pipeline with it, in case you need it.  But
sometimes CPU designers do something more complicated to save the
storage.

> Here is the link..
> http://www.cag.lcs.mit.edu/raw/documents/R4400_Uman_book_Ed2.pdf
> 
> The documentation about the PC is present in the chapter-1 under the
> section "CPU Register Overview".
> 
> Please let me know whether this manual is correct.

Ah, that book.  That picture is nonsense, really.  Sorry, that
happens!

--
Dominic Sweetman
MIPS Technologies.


From bob@diamond.demon.co.uk Mon Jan 19 18:01:11 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 19 Jan 2004 18:01:12 +0000 (GMT)
Received: from diamond.demon.co.uk ([IPv6:::ffff:158.152.18.76]:52458 "EHLO
	basil.diamond.local") by linux-mips.org with ESMTP
	id <S8225074AbUASSBL> convert rfc822-to-8bit; Mon, 19 Jan 2004 18:01:11 +0000
Received: from localhost (localhost [127.0.0.1])
	by basil.diamond.local (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id i0JI6RtO011714
	for <linux-mips@linux-mips.org>; Mon, 19 Jan 2004 18:06:29 GMT
From: Bob Lees <bob@diamond.demon.co.uk>
Organization: Diamond Consulting Services Ltd
To: linux-mips@linux-mips.org
Subject: au1100 usb support
Date: Mon, 19 Jan 2004 18:06:27 +0000
User-Agent: KMail/1.5.4
MIME-Version: 1.0
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 8BIT
Content-Disposition: inline
Message-Id: <200401191806.27381.bob@diamond.demon.co.uk>
Return-Path: <bob@diamond.demon.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: 4042
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: bob@diamond.demon.co.uk
Precedence: bulk
X-list: linux-mips

OK I'm missing something somewhere

I am trying to get the usb host controller to work on an AU1100 board (the 
Aurora board from DSP Design) and it isn't initialising the host controller.

From looking at the usb host code it appears that the only interface supported 
is via pci, but this processor/board doesn't have pci.

A previous kernel based on 2.4.17 had the concept of CONFIG_USB_NON_PCI_OHCI 
which appears to have disappeared.  This generated a pseudo pci interface.

Help, any idea where I should be looking.
-- 
Bob Lees
Diamond Consulting Services Ltd
Aylesbury, Bucks, HP17 8UG
Phone: +44 (0) 1296 747667
Fax: +44 (0) 1296 747557
email: bob@diamond.demon.co.uk


From ppopov@mvista.com Mon Jan 19 18:23:05 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 19 Jan 2004 18:23:06 +0000 (GMT)
Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:24049 "EHLO
	av.mvista.com") by linux-mips.org with ESMTP id <S8225222AbUASSXF>;
	Mon, 19 Jan 2004 18:23:05 +0000
Received: from mvista.com (av [127.0.0.1])
	by av.mvista.com (8.9.3/8.9.3) with ESMTP id KAA26461;
	Mon, 19 Jan 2004 10:22:59 -0800
Message-ID: <400BB003.8000605@mvista.com>
Date: Mon, 19 Jan 2004 02:22:59 -0800
From: Pete Popov <ppopov@mvista.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031007
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Bob Lees <bob@diamond.demon.co.uk>
CC: linux-mips@linux-mips.org
Subject: Re: au1100 usb support
References: <200401191806.27381.bob@diamond.demon.co.uk>
In-Reply-To: <200401191806.27381.bob@diamond.demon.co.uk>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
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: 4043
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

Bob Lees wrote:

>OK I'm missing something somewhere
>
>I am trying to get the usb host controller to work on an AU1100 board (the 
>Aurora board from DSP Design) and it isn't initialising the host controller.
>
>From looking at the usb host code it appears that the only interface supported 
>is via pci, but this processor/board doesn't have pci.
>
>A previous kernel based on 2.4.17 had the concept of CONFIG_USB_NON_PCI_OHCI 
>which appears to have disappeared.  This generated a pseudo pci interface.
>
>Help, any idea where I should be looking.
>  
>
I assume you're working with the linux-mips.org kernel?  Take a look at 
the readme at ftp.linux-mips.org:/pub/linux/mips/people/ppopov.  You're 
missing the usb non-pci patch.

Pete


From jsun@mvista.com Mon Jan 19 19:05:08 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 19 Jan 2004 19:05:08 +0000 (GMT)
Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:22525 "EHLO
	orion.mvista.com") by linux-mips.org with ESMTP id <S8224914AbUASTFI>;
	Mon, 19 Jan 2004 19:05:08 +0000
Received: (from jsun@localhost)
	by orion.mvista.com (8.11.6/8.11.6) id i0JJ57C16395;
	Mon, 19 Jan 2004 11:05:07 -0800
Date: Mon, 19 Jan 2004 11:05:06 -0800
From: Jun Sun <jsun@mvista.com>
To: linux-mips@linux-mips.org
Cc: jsun@mvista.com
Subject: [ralf@linux-mips.org: CVS Update@-mips.org: linux]
Message-ID: <20040119110506.C14131@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@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: 4044
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


This check-in seems to break malta build.

arch/mips/mips-boards/malta/malta_int.c: In function `mips_pcibios_iack':
arch/mips/mips-boards/malta/malta_int.c:63: error: `MIPS_REVISION_CORID_CORE_FPGA2' undeclared (first use in this function)
arch/mips/mips-boards/malta/malta_int.c:63: error: (Each undeclared identifier is reported only once
...

Jun

----- Forwarded message from ralf@linux-mips.org -----

X-Sieve: CMU Sieve 2.2
Delivered-To: jsun@mvista.com
From: ralf@linux-mips.org
To: linux-cvs@linux-mips.org
Subject: CVS Update@-mips.org: linux 
Date: Mon, 19 Jan 2004 16:47:25 +0000
X-archive-position: 3587
X-ecartis-version: Ecartis v1.0.0
Errors-to: linux-cvs-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
Reply-to: linux-mips@linux-mips.org
X-list: linux-cvs
X-Spam-Status: No, hits=-1.1 required=5.0
	tests=AWL,BAYES_30,NO_REAL_NAME
	version=2.55
X-Spam-Level: 
X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp)


CVSROOT:	/home/cvs
Module name:	linux
Changes by:	ralf@ftp.linux-mips.org	04/01/19 16:47:25

Modified files:
	arch/mips/mips-boards/malta: malta_int.c malta_setup.c 

Log message:
	More Malta updates.



----- End forwarded message -----

From ralf@linux-mips.org Mon Jan 19 19:20:58 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 19 Jan 2004 19:20:58 +0000 (GMT)
Received: from p508B617B.dip.t-dialin.net ([IPv6:::ffff:80.139.97.123]:26127
	"EHLO mail.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225074AbUASTU6>; Mon, 19 Jan 2004 19:20:58 +0000
Received: from fluff.linux-mips.net (fluff.linux-mips.net [127.0.0.1])
	by mail.linux-mips.net (8.12.8/8.12.8) with ESMTP id i0JJKvex015421;
	Mon, 19 Jan 2004 20:20:57 +0100
Received: (from ralf@localhost)
	by fluff.linux-mips.net (8.12.8/8.12.8/Submit) id i0JJKuhX015420;
	Mon, 19 Jan 2004 20:20:56 +0100
Date: Mon, 19 Jan 2004 20:20:56 +0100
From: Ralf Baechle <ralf@linux-mips.org>
To: Jun Sun <jsun@mvista.com>
Cc: linux-mips@linux-mips.org
Subject: Re: [ralf@linux-mips.org: CVS Update@-mips.org: linux]
Message-ID: <20040119192056.GA11512@linux-mips.org>
References: <20040119110506.C14131@mvista.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20040119110506.C14131@mvista.com>
User-Agent: Mutt/1.4.1i
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: 4045
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 19, 2004 at 11:05:06AM -0800, Jun Sun wrote:

> arch/mips/mips-boards/malta/malta_int.c: In function `mips_pcibios_iack':
> arch/mips/mips-boards/malta/malta_int.c:63: error: `MIPS_REVISION_CORID_CORE_FPGA2' undeclared (first use in this function)
> arch/mips/mips-boards/malta/malta_int.c:63: error: (Each undeclared identifier is reported only once
> ...

You're too fast :-)

Just wait until I'm done comitting everything ...

  Ralf

From vksavl@cityline.ru Mon Jan 19 19:54:45 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 19 Jan 2004 19:54:45 +0000 (GMT)
Received: from hueytecuilhuitl.mtu.ru ([IPv6:::ffff:195.34.32.123]:63495 "HELO
	hueymiccailhuitl.mtu.ru") by linux-mips.org with SMTP
	id <S8225532AbUASTyp>; Mon, 19 Jan 2004 19:54:45 +0000
Received: from ppp158-154.dialup.mtu-net.ru (ppp158-154.dialup.mtu-net.ru [62.118.158.154])
	by hueymiccailhuitl.mtu.ru (Postfix) with ESMTP id A9B7818714E
	for <linux-mips@linux-mips.org>; Mon, 19 Jan 2004 22:54:41 +0300 (MSK)
	(envelope-from vksavl@cityline.ru)
Date: Mon, 19 Jan 2004 22:55:48 +0300
From: Pavel Kiryukhin <vksavl@cityline.ru>
X-Mailer: The Bat! (v1.60q)
Reply-To: Pavel Kiryukhin <vksavl@cityline.ru>
X-Priority: 3 (Normal)
Message-ID: <1852455000.20040119225548@cityline.ru>
To: linux-mips@linux-mips.org
Subject: sys32_sched_getaffinity
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Return-Path: <vksavl@cityline.ru>
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: 4046
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: vksavl@cityline.ru
Precedence: bulk
X-list: linux-mips

Hi,

could anybody give some comments on the following code in 2.4.x -
2.6.1.

sys_sched_getaffinity [kernel/sched.c] on success returns the size of
cpumask_t, which is obviously positive value.

while

sys32_sched_getaffinity [arch/mips/kernel/linux32.c] expect 0 as
successful return from sys_sched_getaffinity.

Would
  if (ret > 0) {
be more correct than
  if (ret == 0) {
in sys32_sched_getaffinity?
-- 
Best regards,
 Pavel Kiryukhin                          mailto:vksavl@cityline.ru


From hero@tango.eidologic.de Mon Jan 19 20:31:58 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 19 Jan 2004 20:31:58 +0000 (GMT)
Received: from tango.eidologic.de ([IPv6:::ffff:217.172.179.146]:57748 "EHLO
	tango.eidologic.de") by linux-mips.org with ESMTP
	id <S8225546AbUASUb6>; Mon, 19 Jan 2004 20:31:58 +0000
Received: (from hero@localhost)
	by tango.eidologic.de (8.11.6/8.11.6/Slowlaris 9) id i0JKVsU26705
	for linux-mips@linux-mips.org; Mon, 19 Jan 2004 21:31:54 +0100
Date: Mon, 19 Jan 2004 21:31:54 +0100
From: Heiko Ronsdorf <hero@tango.eidologic.de>
To: linux-mips@linux-mips.org
Subject: [PATCH][2.4.24] Indy IP22 compile fixes
Message-ID: <20040119213154.A30538@tango.eidologic.de>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="+QahgC5+KEYLbs62"
Content-Disposition: inline
User-Agent: Mutt/1.3.22.1i
Return-Path: <hero@tango.eidologic.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: 4047
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: hero@tango.eidologic.de
Precedence: bulk
X-list: linux-mips


--+QahgC5+KEYLbs62
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

Hi list,

I was not able to compile 2.4.24 vanilla for my Indy IP22 without
these modifications. Please apply.

Please CC me, because I am not on the list.

bye,

	Heiko

--
To err is human, to forgive, beyond the scope of the (Operating) System.

--+QahgC5+KEYLbs62
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="elf.h.patch"

--- linux-2.4.24/include/asm-mips/elf.h.orig	Sat Jan 17 23:13:00 2004
+++ linux-2.4.24/include/asm-mips/elf.h	Sat Jan 17 23:16:56 2004
@@ -18,6 +18,11 @@
 #define EF_MIPS_ARCH_5      0x40000000  /* -mips5 code.  */
 #define EF_MIPS_ARCH_32     0x50000000  /* MIPS32 code.  */
 #define EF_MIPS_ARCH_64     0x60000000  /* MIPS64 code.  */
+
+/* Flags in the e_flags field of the header */
+#define EF_MIPS_ABI2        0x00000020
+#define EF_MIPS_ABI         0x0000f000
+
 /* The ABI of a file. */
 #define EF_MIPS_ABI_O32     0x00001000  /* O32 ABI.  */
 #define EF_MIPS_ABI_O64     0x00002000  /* O32 extended for 64 bit.  */

--+QahgC5+KEYLbs62
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="sgiseeq.c.patch"

--- linux-2.4.24/drivers/net/sgiseeq.c.orig	Sat Jan 17 22:13:21 2004
+++ linux-2.4.24/drivers/net/sgiseeq.c	Sat Jan 17 22:13:40 2004
@@ -31,8 +31,8 @@
 #include <linux/etherdevice.h>
 #include <linux/skbuff.h>
 
-#include <asm/sgi/sgihpc.h>
-#include <asm/sgi/sgint23.h>
+#include <asm/sgi/hpc3.h>
+#include <asm/sgi/ip22.h>
 #include <asm/sgialib.h>
 
 #include "sgiseeq.h"

--+QahgC5+KEYLbs62--

From ladis@linux-mips.org Mon Jan 19 21:51:49 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 19 Jan 2004 21:51:49 +0000 (GMT)
Received: from p014.as-l005.contactel.cz ([IPv6:::ffff:212.65.198.14]:43268
	"EHLO kopretinka") by linux-mips.org with ESMTP id <S8225269AbUASVvt>;
	Mon, 19 Jan 2004 21:51:49 +0000
Received: from ladis by kopretinka with local (Exim 3.36 #1 (Debian))
	id 1AihJ6-0007n8-00; Mon, 19 Jan 2004 22:51:40 +0100
Date: Mon, 19 Jan 2004 22:51:38 +0100
To: Heiko Ronsdorf <hero@tango.eidologic.de>
Cc: linux-mips@linux-mips.org
Subject: Re: [PATCH][2.4.24] Indy IP22 compile fixes
Message-ID: <20040119215138.GA29907@kopretinka>
References: <20040119213154.A30538@tango.eidologic.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20040119213154.A30538@tango.eidologic.de>
User-Agent: Mutt/1.5.4i
From: Ladislav Michl <ladis@linux-mips.org>
Return-Path: <ladis@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: 4048
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@linux-mips.org
Precedence: bulk
X-list: linux-mips

On Mon, Jan 19, 2004 at 09:31:54PM +0100, Heiko Ronsdorf wrote:
> Hi list,
> 
> I was not able to compile 2.4.24 vanilla for my Indy IP22 without
> these modifications. Please apply.

There's no need to apply this patch. Please wait until mips port will
be synced again.

	ladis

From bob@diamond.demon.co.uk Mon Jan 19 22:33:42 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 19 Jan 2004 22:33:43 +0000 (GMT)
Received: from diamond.demon.co.uk ([IPv6:::ffff:158.152.18.76]:62188 "EHLO
	basil.diamond.local") by linux-mips.org with ESMTP
	id <S8224914AbUASWdm>; Mon, 19 Jan 2004 22:33:42 +0000
Received: from localhost (localhost [127.0.0.1])
	by basil.diamond.local (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id i0JMd2tO013397;
	Mon, 19 Jan 2004 22:39:04 GMT
From: Bob Lees <bob@diamond.demon.co.uk>
Organization: Diamond Consulting Services Ltd
To: Pete Popov <ppopov@mvista.com>
Subject: Re: au1100 usb support
Date: Mon, 19 Jan 2004 22:39:02 +0000
User-Agent: KMail/1.5.4
Cc: linux-mips@linux-mips.org
References: <200401191806.27381.bob@diamond.demon.co.uk> <400BB003.8000605@mvista.com>
In-Reply-To: <400BB003.8000605@mvista.com>
MIME-Version: 1.0
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200401192239.02283.bob@diamond.demon.co.uk>
Return-Path: <bob@diamond.demon.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: 4049
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: bob@diamond.demon.co.uk
Precedence: bulk
X-list: linux-mips

Correct assumption.  Thank you for the pointer, unfortunately both the usb 
non-pci and zboot patches for 2.4.24 are only rw by the owner, there is no 
world read access.  Can this be changed, pretty please:)

Thanks

Bob
On Monday 19 January 2004 10:22, Pete Popov wrote:
> Bob Lees wrote:
> >OK I'm missing something somewhere
> >
> >I am trying to get the usb host controller to work on an AU1100 board (the
> >Aurora board from DSP Design) and it isn't initialising the host
> > controller.
>
> From looking at the usb host code it appears that the only interface
> supported
>
> >is via pci, but this processor/board doesn't have pci.
> >
> >A previous kernel based on 2.4.17 had the concept of
> > CONFIG_USB_NON_PCI_OHCI which appears to have disappeared.  This
> > generated a pseudo pci interface.
> >
> >Help, any idea where I should be looking.
>
> I assume you're working with the linux-mips.org kernel?  Take a look at
> the readme at ftp.linux-mips.org:/pub/linux/mips/people/ppopov.  You're
> missing the usb non-pci patch.
>
> Pete

-- 
Bob Lees
Diamond Consulting Services Ltd
Aylesbury, Bucks, HP17 8UG
Phone: +44 (0) 1296 747667
Fax: +44 (0) 1296 747557
email: bob@diamond.demon.co.uk


From ppopov@mvista.com Mon Jan 19 22:37:12 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 19 Jan 2004 22:37:12 +0000 (GMT)
Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:11248 "EHLO
	av.mvista.com") by linux-mips.org with ESMTP id <S8224914AbUASWhM>;
	Mon, 19 Jan 2004 22:37:12 +0000
Received: from [10.2.2.30] (av [127.0.0.1])
	by av.mvista.com (8.9.3/8.9.3) with ESMTP id OAA09317;
	Mon, 19 Jan 2004 14:36:20 -0800
Subject: Re: au1100 usb support
From: Pete Popov <ppopov@mvista.com>
To: Bob Lees <bob@diamond.demon.co.uk>
Cc: linux-mips@linux-mips.org
In-Reply-To: <200401192239.02283.bob@diamond.demon.co.uk>
References: <200401191806.27381.bob@diamond.demon.co.uk>
	 <400BB003.8000605@mvista.com>  <200401192239.02283.bob@diamond.demon.co.uk>
Content-Type: text/plain
Organization: 
Message-Id: <1074551771.3054.2.camel@localhost.localdomain>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.2.2 (1.2.2-4) 
Date: 19 Jan 2004 14:36:12 -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: 4050
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, 2004-01-19 at 14:39, Bob Lees wrote:
> Correct assumption.  Thank you for the pointer, unfortunately both the usb 
> non-pci and zboot patches for 2.4.24 are only rw by the owner, there is no 
> world read access.  Can this be changed, pretty please:)

Done, thanks for pointing this out.

Pete

> 
> Thanks
> 
> Bob
> On Monday 19 January 2004 10:22, Pete Popov wrote:
> > Bob Lees wrote:
> > >OK I'm missing something somewhere
> > >
> > >I am trying to get the usb host controller to work on an AU1100 board (the
> > >Aurora board from DSP Design) and it isn't initialising the host
> > > controller.
> >
> > From looking at the usb host code it appears that the only interface
> > supported
> >
> > >is via pci, but this processor/board doesn't have pci.
> > >
> > >A previous kernel based on 2.4.17 had the concept of
> > > CONFIG_USB_NON_PCI_OHCI which appears to have disappeared.  This
> > > generated a pseudo pci interface.
> > >
> > >Help, any idea where I should be looking.
> >
> > I assume you're working with the linux-mips.org kernel?  Take a look at
> > the readme at ftp.linux-mips.org:/pub/linux/mips/people/ppopov.  You're
> > missing the usb non-pci patch.
> >
> > Pete


From ralf@linux-mips.org Mon Jan 19 23:16:30 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 19 Jan 2004 23:16:30 +0000 (GMT)
Received: from p508B617B.dip.t-dialin.net ([IPv6:::ffff:80.139.97.123]:55314
	"EHLO mail.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225532AbUASXQa>; Mon, 19 Jan 2004 23:16:30 +0000
Received: from fluff.linux-mips.net (fluff.linux-mips.net [127.0.0.1])
	by mail.linux-mips.net (8.12.8/8.12.8) with ESMTP id i0JNGSex031396;
	Tue, 20 Jan 2004 00:16:28 +0100
Received: (from ralf@localhost)
	by fluff.linux-mips.net (8.12.8/8.12.8/Submit) id i0JNGSi7031395;
	Tue, 20 Jan 2004 00:16:28 +0100
Date: Tue, 20 Jan 2004 00:16:28 +0100
From: Ralf Baechle <ralf@linux-mips.org>
To: Ladislav Michl <ladis@linux-mips.org>
Cc: Heiko Ronsdorf <hero@tango.eidologic.de>, linux-mips@linux-mips.org
Subject: Re: [PATCH][2.4.24] Indy IP22 compile fixes
Message-ID: <20040119231628.GA30416@linux-mips.org>
References: <20040119213154.A30538@tango.eidologic.de> <20040119215138.GA29907@kopretinka>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20040119215138.GA29907@kopretinka>
User-Agent: Mutt/1.4.1i
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: 4051
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 19, 2004 at 10:51:38PM +0100, Ladislav Michl wrote:

> > Hi list,
> > 
> > I was not able to compile 2.4.24 vanilla for my Indy IP22 without
> > these modifications. Please apply.
> 
> There's no need to apply this patch. Please wait until mips port will
> be synced again.

In fact Marcelo already had all the patches then he decieded to screw
versin numbering entirely and throw out a 2.4.24 without everything he
previously already had accepted for .24.

  Ralf

From ralf@linux-mips.org Tue Jan 20 00:29:24 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 20 Jan 2004 00:29:24 +0000 (GMT)
Received: from p508B617B.dip.t-dialin.net ([IPv6:::ffff:80.139.97.123]:61459
	"EHLO mail.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225475AbUATA3Y>; Tue, 20 Jan 2004 00:29:24 +0000
Received: from fluff.linux-mips.net (fluff.linux-mips.net [127.0.0.1])
	by mail.linux-mips.net (8.12.8/8.12.8) with ESMTP id i0K0RMex007100;
	Tue, 20 Jan 2004 01:27:22 +0100
Received: (from ralf@localhost)
	by fluff.linux-mips.net (8.12.8/8.12.8/Submit) id i0K0RMxA007099;
	Tue, 20 Jan 2004 01:27:22 +0100
Date: Tue, 20 Jan 2004 01:27:22 +0100
From: Ralf Baechle <ralf@linux-mips.org>
To: Pavel Kiryukhin <vksavl@cityline.ru>
Cc: linux-mips@linux-mips.org
Subject: Re: sys32_sched_getaffinity
Message-ID: <20040120002721.GA6933@linux-mips.org>
References: <1852455000.20040119225548@cityline.ru>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <1852455000.20040119225548@cityline.ru>
User-Agent: Mutt/1.4.1i
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: 4052
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 19, 2004 at 10:55:48PM +0300, Pavel Kiryukhin wrote:

> could anybody give some comments on the following code in 2.4.x -
> 2.6.1.
> 
> sys_sched_getaffinity [kernel/sched.c] on success returns the size of
> cpumask_t, which is obviously positive value.
> 
> while
> 
> sys32_sched_getaffinity [arch/mips/kernel/linux32.c] expect 0 as
> successful return from sys_sched_getaffinity.

Wrong question.  The question should be why does the MIPS kernel not use
the generic 32-bit compatibility functions?  It now does, I just changed
that.

  Ralf

From Wei.Liu@esstech.com Tue Jan 20 01:07:43 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 20 Jan 2004 01:07:43 +0000 (GMT)
Received: from [IPv6:::ffff:209.172.108.133] ([IPv6:::ffff:209.172.108.133]:52884
	"HELO [209.172.108.133]") by linux-mips.org with SMTP
	id <S8225474AbUATBHn>; Tue, 20 Jan 2004 01:07:43 +0000
Received: from essmail.esstech.com by [209.172.108.133]
          via smtpd (for mail.linux-mips.org [62.254.210.162]) with SMTP; Mon, 19 Jan 2004 17:07:42 -0800
Received: from wliupc ([172.18.13.106]) by ess2kmail.essnet.com with Microsoft SMTPSVC(5.0.2195.5329);
	 Mon, 19 Jan 2004 17:07:34 -0800
Message-ID: <002d01c3def2$cbc76480$6a0d12ac@ess>
From: "wei liu" <wei.liu@esstech.com>
To: <linux-mips@linux-mips.org>
Subject: unaligned problem in linux2.4.18?
Date: Mon, 19 Jan 2004 17:14:47 -0800
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_002A_01C3DEAF.BD71C9E0"
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
X-OriginalArrivalTime: 20 Jan 2004 01:07:34.0455 (UTC) FILETIME=[C96FFC70:01C3DEF1]
Return-Path: <Wei.Liu@esstech.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: 4053
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: wei.liu@esstech.com
Precedence: bulk
X-list: linux-mips

This is a multi-part message in MIME format.

------=_NextPart_000_002A_01C3DEAF.BD71C9E0
Content-Type: text/plain;
	charset="gb2312"
Content-Transfer-Encoding: quoted-printable

I'm using mips-4kc core and try to port linux2.4.18. When kernel starts, =
it display the following OOP
Unhandled kernel unaligned access in =
unaligned.c:emulate_load_store_insn, line 3
51:
$0 : 00000000 801d0000 ffd82b0b 00000001 fff60ac0 0000000b 80237ef8 =
00000001
$8 : 1000fc00 1000001f 0000001d 12e09bff 00ffffff a0e00010 000000ff =
00000018
$16: 801d64e4 00000000 80002adc 00000004 bfd5a450 00000005 00000004 =
b3ff0000
$24: a0000000 800a1e4c                   80236000 80237eb0 bfc00598 =
80009aa4
Hi : 00000005
Lo : 80010fb8
epc  : 8000993c    Not tainted
Status: 1000fc02
Cause : 10800010
Process=FFg=FF=FF4=FF=FF=FF=FF[9=FF=FF5=FF=FF=FF=FF=FF (pid: -143232658, =
stackpage=3D80234000)
Stack: 5a24a5ab 2e29b637 30313233 34353637 80009aa4 63646566 30313233 =
34353637
       38396162 63646566 10801000 80092d54 000088c9 0000003e 80010b98 =
00353637
       80092960 34353637 000008c5 ffffffff 000088c9 80010c58 1000fc01 =
ffffc000
       00000000 1000fc01 00000000 00000001 00000000 00000000 00000000 =
00000000
       12e01e6c 801d2d59 00000001 12e09bff 00ffffff a0e00010 00000005 =
00000004 b
3ff0000
$24: a0000000 80231a26                   80230000 80231a50 bfc00598 =
80009aa4
Hi : 00000005
Lo : 80010fb8
epc  : 8000993c    Not tainted
Status: 1000fc02
Status: 1000fc02
It is ok with linux2.4.3, any suggestion?

------=_NextPart_000_002A_01C3DEAF.BD71C9E0
Content-Type: text/html;
	charset="gb2312"
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=3Dgb2312">
<META content=3D"MSHTML 6.00.2600.0" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT size=3D2>I'm using mips-4kc core and try to port linux2.4.18. =
When=20
kernel starts, it display the following OOP</FONT></DIV>
<DIV><FONT size=3D2>Unhandled kernel unaligned access in=20
unaligned.c:emulate_load_store_insn, line 3<BR>51:<BR>$0 : 00000000 =
801d0000=20
ffd82b0b 00000001 fff60ac0 0000000b 80237ef8 00000001<BR>$8 : 1000fc00 =
1000001f=20
0000001d 12e09bff 00ffffff a0e00010 000000ff 00000018<BR>$16: 801d64e4 =
00000000=20
80002adc 00000004 bfd5a450 00000005 00000004 b3ff0000<BR>$24: a0000000=20
800a1e4c&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
80236000 80237eb0 bfc00598 80009aa4<BR>Hi : 00000005<BR>Lo :=20
80010fb8<BR>epc&nbsp; : 8000993c&nbsp;&nbsp;&nbsp; Not =
tainted<BR>Status:=20
1000fc02<BR>Cause : =
10800010<BR>Process=FFg=FF=FF4=FF=FF=FF=FF[9=FF=FF5=FF=FF=FF=FF=FF (pid: =
-143232658,=20
stackpage=3D80234000)<BR>Stack: 5a24a5ab 2e29b637 30313233 34353637 =
80009aa4=20
63646566 30313233 34353637<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
38396162=20
63646566 10801000 80092d54 000088c9 0000003e 80010b98=20
00353637<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 80092960 34353637 =
000008c5=20
ffffffff 000088c9 80010c58 1000fc01=20
ffffc000<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 00000000 1000fc01 =
00000000=20
00000001 00000000 00000000 00000000=20
00000000<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 12e01e6c 801d2d59 =
00000001=20
12e09bff 00ffffff a0e00010 00000005 00000004 b<BR>3ff0000<BR>$24: =
a0000000=20
80231a26&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
80230000 80231a50 bfc00598 80009aa4<BR>Hi : 00000005<BR>Lo :=20
80010fb8<BR>epc&nbsp; : 8000993c&nbsp;&nbsp;&nbsp; Not =
tainted<BR>Status:=20
1000fc02<BR>Status: 1000fc02<BR>It is ok with linux2.4.3, any=20
suggestion?</FONT></DIV></BODY></HTML>

------=_NextPart_000_002A_01C3DEAF.BD71C9E0--


From macro@ds2.pg.gda.pl Tue Jan 20 12:13:49 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 20 Jan 2004 12:13:49 +0000 (GMT)
Received: from jurand.ds.pg.gda.pl ([IPv6:::ffff:153.19.208.2]:20690 "EHLO
	jurand.ds.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8225226AbUATMNt>; Tue, 20 Jan 2004 12:13:49 +0000
Received: by jurand.ds.pg.gda.pl (Postfix, from userid 1011)
	id 1DFFA4C3BB; Tue, 20 Jan 2004 13:13:43 +0100 (CET)
Received: from localhost (localhost [127.0.0.1])
	by jurand.ds.pg.gda.pl (Postfix) with ESMTP
	id 1253B47810; Tue, 20 Jan 2004 13:13:43 +0100 (CET)
Date: Tue, 20 Jan 2004 13:13:43 +0100 (CET)
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To: Ralf Baechle <ralf@linux-mips.org>
Cc: Ladislav Michl <ladis@linux-mips.org>,
	Heiko Ronsdorf <hero@tango.eidologic.de>,
	linux-mips@linux-mips.org
Subject: Re: [PATCH][2.4.24] Indy IP22 compile fixes
In-Reply-To: <20040119231628.GA30416@linux-mips.org>
Message-ID: <Pine.LNX.4.55.0401201307190.12841@jurand.ds.pg.gda.pl>
References: <20040119213154.A30538@tango.eidologic.de> <20040119215138.GA29907@kopretinka>
 <20040119231628.GA30416@linux-mips.org>
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: 4054
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, 20 Jan 2004, Ralf Baechle wrote:

> In fact Marcelo already had all the patches then he decieded to screw
> versin numbering entirely and throw out a 2.4.24 without everything he
> previously already had accepted for .24.

 Well, the action was justified and it's our (?) business we sync to
Marcelo early.  Anyway, there's 2.4.25-pre6 out there, so there's no
problem fixing numbering.  Or is there?

-- 
+  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 20 12:35:18 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 20 Jan 2004 12:35:18 +0000 (GMT)
Received: from p508B6B36.dip.t-dialin.net ([IPv6:::ffff:80.139.107.54]:25629
	"EHLO mail.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225203AbUATMfS>; Tue, 20 Jan 2004 12:35:18 +0000
Received: from fluff.linux-mips.net (fluff.linux-mips.net [127.0.0.1])
	by mail.linux-mips.net (8.12.8/8.12.8) with ESMTP id i0KCZ8ex017564;
	Tue, 20 Jan 2004 13:35:08 +0100
Received: (from ralf@localhost)
	by fluff.linux-mips.net (8.12.8/8.12.8/Submit) id i0KCZ6La017563;
	Tue, 20 Jan 2004 13:35:06 +0100
Date: Tue, 20 Jan 2004 13:35:06 +0100
From: Ralf Baechle <ralf@linux-mips.org>
To: wei liu <wei.liu@esstech.com>
Cc: linux-mips@linux-mips.org
Subject: Re: unaligned problem in linux2.4.18?
Message-ID: <20040120123506.GA17208@linux-mips.org>
References: <002d01c3def2$cbc76480$6a0d12ac@ess>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <002d01c3def2$cbc76480$6a0d12ac@ess>
User-Agent: Mutt/1.4.1i
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: 4055
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 19, 2004 at 05:14:47PM -0800, wei liu wrote:

> I'm using mips-4kc core and try to port linux2.4.18. When kernel starts, it display the following OOP

An oops message is pretty usless unless decoded by ksymoops.  To make
matters worse, a crash in the unaligned handler is most probably just
sympthom of a problem elsewhere so having a decoded oops isn't necesarily
sufficient information to find the problem.

  Ralf

From macro@ds2.pg.gda.pl Tue Jan 20 12:37:18 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 20 Jan 2004 12:37:18 +0000 (GMT)
Received: from jurand.ds.pg.gda.pl ([IPv6:::ffff:153.19.208.2]:61659 "EHLO
	jurand.ds.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8225305AbUATMhS>; Tue, 20 Jan 2004 12:37:18 +0000
Received: by jurand.ds.pg.gda.pl (Postfix, from userid 1011)
	id 0CD7B4C3A9; Tue, 20 Jan 2004 13:37:17 +0100 (CET)
Received: from localhost (localhost [127.0.0.1])
	by jurand.ds.pg.gda.pl (Postfix) with ESMTP
	id 0138E4B4FE; Tue, 20 Jan 2004 13:37:16 +0100 (CET)
Date: Tue, 20 Jan 2004 13:37:16 +0100 (CET)
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To: Dimitri Torfs <dimitri@sonycom.com>
Cc: linux-mips@linux-mips.org
Subject: Re: Support for newer gcc/gas options
In-Reply-To: <Pine.LNX.4.55.0312231303030.27594@jurand.ds.pg.gda.pl>
Message-ID: <Pine.LNX.4.55.0401201332080.12841@jurand.ds.pg.gda.pl>
References: <20031223114644.GA5458@sonycom.com>
 <Pine.LNX.4.55.0312231303030.27594@jurand.ds.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: 4056
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, 23 Dec 2003, Maciej W. Rozycki wrote:

> >   "cc1: warning: The -march option is incompatible to -mipsN and therefore
> > +ignored."
> > 
> >   when compiling. I have the CONFIG_CPU_VR41XX option set, which sets
> >   the c-flags to:
> > 
> >   "-I /home/dimitri/work/linux/include/asm/gcc -G 0 -mno-abicalls
> >   -fno-pic -pipe  -finline-limit=100000 -mabi=32 -march=r4100 -mips3
> >   -Wa,-32 -Wa,-march=r4100 -Wa,-mips3 -Wa,--trap"
> > 
> >   I suppose that for the newer gcc versions only -march= should be
> >   set (I'm using gcc-3.2.2) ?
> 
>  Thanks for the report -- I suppose we can remove "-mips" whenever
> "-mabi=" is supported by gcc.  I'll do an update in January after I am 
> back from vacation.

 It took a bit longer than I planned, sorry.  Anyway, here are two
functionally equivalent patches, for 2.4 and the head, that remove an ISA
specification if a tool supports "-march=" and "-mabi=" at the same time.  
Please try the appropriate one.

  Maciej

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

patch-mips-2.4.23-20031209-mabi-2
diff -up --recursive --new-file linux-mips-2.4.23-20031209.macro/arch/mips/Makefile linux-mips-2.4.23-20031209/arch/mips/Makefile
--- linux-mips-2.4.23-20031209.macro/arch/mips/Makefile	2003-12-22 02:35:03.000000000 +0000
+++ linux-mips-2.4.23-20031209/arch/mips/Makefile	2004-01-20 08:13:20.000000000 +0000
@@ -98,6 +98,12 @@ while :; do \
 	gas_abi=; gas_opt=; gas_cpu=; gas_isa=; \
 	break; \
 done; \
+if test "$gcc_opt" = -march && test -n "$gcc_abi"; then \
+	gcc_isa=; \
+fi; \
+if test "$gas_opt" = -Wa,-march && test -n "$gas_abi"; then \
+	gas_isa=; \
+fi; \
 echo $$gcc_abi $$gcc_opt$$gcc_cpu $$gcc_isa $$gas_abi $$gas_opt$$gas_cpu $$gas_isa)
 
 #
diff -up --recursive --new-file linux-mips-2.4.23-20031209.macro/arch/mips64/Makefile linux-mips-2.4.23-20031209/arch/mips64/Makefile
--- linux-mips-2.4.23-20031209.macro/arch/mips64/Makefile	2003-12-22 02:32:44.000000000 +0000
+++ linux-mips-2.4.23-20031209/arch/mips64/Makefile	2004-01-20 08:13:28.000000000 +0000
@@ -87,6 +87,12 @@ while :; do \
 	gas_opt=; gas_cpu=; gas_isa=; \
 	break; \
 done; \
+if test "$gcc_opt" = -march; then \
+	gcc_isa=; \
+fi; \
+if test "$gas_opt" = -Wa,-march; then \
+	gas_isa=; \
+fi; \
 echo $$gcc_opt$$gcc_cpu $$gcc_isa $$gas_opt$$gas_cpu $$gas_isa)
 
 #

patch-mips-2.6.0-20040108-mabi-2
diff -up --recursive --new-file linux-mips-2.6.0-20040108.macro/arch/mips/Makefile linux-mips-2.6.0-20040108/arch/mips/Makefile
--- linux-mips-2.6.0-20040108.macro/arch/mips/Makefile	2004-01-07 04:56:39.000000000 +0000
+++ linux-mips-2.6.0-20040108/arch/mips/Makefile	2004-01-20 08:13:49.000000000 +0000
@@ -111,6 +111,12 @@ done; \
 if test x$(gcc-abi) != x$(gas-abi); then \
 	gas_abi="-Wa,-$(gas-abi) -Wa,-mgp$(gcc-abi)"; \
 fi; \
+if test "$gcc_opt" = -march && test -n "$gcc_abi"; then \
+	gcc_isa=; \
+fi; \
+if test "$gas_opt" = -Wa,-march && test -n "$gas_abi"; then \
+	gas_isa=; \
+fi; \
 echo $$gcc_abi $$gcc_opt$$gcc_cpu $$gcc_isa $$gas_abi $$gas_opt$$gas_cpu $$gas_isa)
 
 #

From ica2_ts@csv.ica.uni-stuttgart.de Tue Jan 20 12:45:25 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 20 Jan 2004 12:45:26 +0000 (GMT)
Received: from iris1.csv.ica.uni-stuttgart.de ([IPv6:::ffff:129.69.118.2]:13131
	"EHLO iris1.csv.ica.uni-stuttgart.de") by linux-mips.org with ESMTP
	id <S8225305AbUATMpZ>; Tue, 20 Jan 2004 12:45:25 +0000
Received: from rembrandt.csv.ica.uni-stuttgart.de ([129.69.118.42])
	by iris1.csv.ica.uni-stuttgart.de with esmtp
	id 1AivFv-0003w2-00; Tue, 20 Jan 2004 13:45:19 +0100
Received: from ica2_ts by rembrandt.csv.ica.uni-stuttgart.de with local (Exim 3.35 #1 (Debian))
	id 1AivFu-0008S0-00; Tue, 20 Jan 2004 13:45:18 +0100
Date: Tue, 20 Jan 2004 13:45:18 +0100
To: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
Cc: linux-mips@linux-mips.org
Subject: Re: Support for newer gcc/gas options
Message-ID: <20040120124518.GY22218@rembrandt.csv.ica.uni-stuttgart.de>
References: <20031223114644.GA5458@sonycom.com> <Pine.LNX.4.55.0312231303030.27594@jurand.ds.pg.gda.pl> <Pine.LNX.4.55.0401201332080.12841@jurand.ds.pg.gda.pl>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Pine.LNX.4.55.0401201332080.12841@jurand.ds.pg.gda.pl>
User-Agent: Mutt/1.5.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: 4057
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

Maciej W. Rozycki wrote:
[snip]
>  It took a bit longer than I planned, sorry.  Anyway, here are two
> functionally equivalent patches, for 2.4 and the head, that remove an ISA
> specification if a tool supports "-march=" and "-mabi=" at the same time.  

FYI:
A test for the existence of -march= should be enough, -mabi= was
implemented earlier. OTOH, it does no harm to check both.


Thiemo

From macro@ds2.pg.gda.pl Tue Jan 20 12:59:31 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 20 Jan 2004 12:59:31 +0000 (GMT)
Received: from jurand.ds.pg.gda.pl ([IPv6:::ffff:153.19.208.2]:18912 "EHLO
	jurand.ds.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8225222AbUATM7b>; Tue, 20 Jan 2004 12:59:31 +0000
Received: by jurand.ds.pg.gda.pl (Postfix, from userid 1011)
	id DBF5D4C3BC; Tue, 20 Jan 2004 13:59:29 +0100 (CET)
Received: from localhost (localhost [127.0.0.1])
	by jurand.ds.pg.gda.pl (Postfix) with ESMTP
	id C8979477ED; Tue, 20 Jan 2004 13:59:29 +0100 (CET)
Date: Tue, 20 Jan 2004 13:59:29 +0100 (CET)
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To: Thiemo Seufer <ica2_ts@csv.ica.uni-stuttgart.de>
Cc: linux-mips@linux-mips.org
Subject: Re: Support for newer gcc/gas options
In-Reply-To: <20040120124518.GY22218@rembrandt.csv.ica.uni-stuttgart.de>
Message-ID: <Pine.LNX.4.55.0401201351000.12841@jurand.ds.pg.gda.pl>
References: <20031223114644.GA5458@sonycom.com>
 <Pine.LNX.4.55.0312231303030.27594@jurand.ds.pg.gda.pl>
 <Pine.LNX.4.55.0401201332080.12841@jurand.ds.pg.gda.pl>
 <20040120124518.GY22218@rembrandt.csv.ica.uni-stuttgart.de>
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: 4058
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, 20 Jan 2004, Thiemo Seufer wrote:

> >  It took a bit longer than I planned, sorry.  Anyway, here are two
> > functionally equivalent patches, for 2.4 and the head, that remove an ISA
> > specification if a tool supports "-march=" and "-mabi=" at the same time.  
> 
> FYI:
> A test for the existence of -march= should be enough, -mabi= was
> implemented earlier. OTOH, it does no harm to check both.

 Well, FWIW my port of gcc 2.95.4 supports -march= (by aliasing it to
-mcpu=, but the option is passed down to gas as is) to cooperate with
current binutils, but its support for -mabi= varies depending on the
configuration: mips64el-linux-gcc does support the option, but
mipsel-linux-gcc does not.  I suppose others may also want to have -march=
support in 2.95.4 for binutils compatibility, especially as AFAICS 2.95.4
has a huge speed advantage over later versions of gcc.

  Maciej

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

From rathann@icm.edu.pl Tue Jan 20 13:06:35 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 20 Jan 2004 13:06:36 +0000 (GMT)
Received: from gw.icm.edu.pl ([IPv6:::ffff:212.87.0.39]:52632 "EHLO
	atol.icm.edu.pl") by linux-mips.org with ESMTP id <S8225316AbUATNGf>;
	Tue, 20 Jan 2004 13:06:35 +0000
Received: from rekin.icm.edu.pl (rekin.icm.edu.pl [192.168.1.132])
	by atol.icm.edu.pl (8.12.6/8.12.6/rzm-4.6/icm) with ESMTP id i0KD6NCM000049
	for <linux-mips@linux-mips.org>; Tue, 20 Jan 2004 14:06:23 +0100 (CET)
Received: from rathann by rekin.icm.edu.pl with local (Exim 3.35 #1 (Debian))
	id 1AivaM-0006gv-00
	for <linux-mips@linux-mips.org>; Tue, 20 Jan 2004 14:06:26 +0100
Date: Tue, 20 Jan 2004 14:06:26 +0100
From: "Dominik 'Rathann' Mierzejewski" <rathann@icm.edu.pl>
To: linux-mips@linux-mips.org
Subject: Re: Current 2.4 CVS (2.4.24-pre2) doesn't boot on SGI Indy
Message-ID: <20040120130625.GA24435@icm.edu.pl>
Mail-Followup-To: linux-mips@linux-mips.org
References: <20040115141427.GA28546@icm.edu.pl> <Pine.LNX.4.21.0401151816540.3511-100000@www.marty44.net> <20040115231735.GA6619@icm.edu.pl> <4007386F.80207@gentoo.org> <20040115172602.H18368@mvista.com> <20040116115053.GA18099@icm.edu.pl>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20040116115053.GA18099@icm.edu.pl>
User-Agent: Mutt/1.3.28i
Return-Path: <rathann@icm.edu.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: 4059
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: rathann@icm.edu.pl
Precedence: bulk
X-list: linux-mips

On Fri, Jan 16, 2004 at 12:50:53PM +0100, Dominik 'Rathann' Mierzejewski wrote:
> On Thu, Jan 15, 2004 at 05:26:02PM -0800, Jun Sun wrote:
> > On Thu, Jan 15, 2004 at 08:03:43PM -0500, Kumba wrote:
> > > Dominik 'Rathann' Mierzejewski wrote:
> [...] 
> > > I have a 2.4.23 kernel I used from a 20031128 CVS snapshot that works 
> > > fine, but a 2.4.23 20031214 snapshot didn't work (on an R4400@250MHz 
> > > I2), so likely the problem was introduced sometime between those dates. 
> > >   Might help for tracking down the issue.
> 
> Thanks, that'll be useful.

OK, I've narrowed it down to sometime between 20031205 and 20031214, but
since there were no commits between 20031204 and 20031211, it has to be one
of these:

6242 2003/12/11 01:29:17 linux_2_4 ralf Fix a bunch of long standing bugs and performance clear_page issues: - Fi .....
6244 2003/12/11 15:36:14 linux_2_4 macro Remove a superfluous initializer.
6245 2003/12/11 15:41:09 linux_2_4 macro Conditionalize console ioctls appropriately.
6246 2003/12/11 16:06:48 linux_2_4 macro Initrd support for DECstations; by Thiemo Seufer.
6248 2003/12/11 16:07:24 linux_2_4 ladis PI1 parport update: * don't intialize twice when compiled in * place P .....
6250 2003/12/11 16:25:43 linux_2_4 macro Force the 4kB page size for processors that do not support other sizes. D .....
6252 2003/12/11 16:39:41 linux_2_4 macro Formatting fixes plus an error code correction; by Thiemo Seufer.
6254 2003/12/11 20:47:12 linux_2_4 ralf Fix a bunch of long standing bugs and performance copy_page issues: - Fix .....
6256 2003/12/11 21:07:56 linux_2_4 ralf Three basically identical copies of pgd_init are 2.0 too much ...
6257 2003/12/11 21:25:25 linux_2_4 ralf pg-r3k.c has become just the trivial case of pg-r4k.c so zap it.
6258 2003/12/11 22:57:23 linux_2_4 ralf Fix stupid dependency ...
6259 2003/12/11 22:59:09 linux_2_4 ralf Rebuild.
6262 2003/12/13 05:03:21 linux_2_4 ralf semaphore.o is an exporting object.
6263 2003/12/13 05:33:38 linux_2_4 ralf Add sound ioctls.

Still searching...

Cheers,

-- 
Dominik 'Rathann' Mierzejewski <rathann@icm.edu.pl>                                                 
Interdisciplinary Centre for Mathematical and Computational Modelling                               
Warsaw University  |  http://www.icm.edu.pl  |  tel. +48 (22) 5540810                               

From kip.r2@free.fr Tue Jan 20 13:10:34 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 20 Jan 2004 13:10:35 +0000 (GMT)
Received: from postfix4-1.free.fr ([IPv6:::ffff:213.228.0.62]:5507 "EHLO
	postfix4-1.free.fr") by linux-mips.org with ESMTP
	id <S8225474AbUATNKe>; Tue, 20 Jan 2004 13:10:34 +0000
Received: from imp3-l.free.fr (imp3-l.free.fr [213.228.0.204])
	by postfix4-1.free.fr (Postfix) with ESMTP id 657E26D34B
	for <linux-mips@linux-mips.org>; Tue, 20 Jan 2004 14:10:31 +0100 (CET)
Received: by imp3-l.free.fr (Postfix, from userid 33)
	id 589E51786B; Tue, 20 Jan 2004 14:10:31 +0100 (MET)
Received: from gw-sjo1.sc.philips.com (gw-sjo1.sc.philips.com [63.194.140.131]) 
	by imp3-l.free.fr (IMP) with HTTP 
	for <kip.r2@imap.free.fr>; Tue, 20 Jan 2004 14:10:31 +0100
Message-ID: <1074604231.400d28c7389a5@imp3-l.free.fr>
Date: Tue, 20 Jan 2004 14:10:31 +0100
From: kip.r2@free.fr
To: linux-mips@linux-mips.org
Subject: MIPS PR3940
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
User-Agent: Internet Messaging Program (IMP) 3.2.1
Return-Path: <kip.r2@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: 4060
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: kip.r2@free.fr
Precedence: bulk
X-list: linux-mips

Hi all,
I was wondering if anybody has already work with this processor. I'm expected 
to make real-time applications on that platform. Do you think it is possible?
Yann


From deepfire@sic-elvis.zel.ru Tue Jan 20 13:44:06 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 20 Jan 2004 13:44:07 +0000 (GMT)
Received: from [IPv6:::ffff:212.5.174.154] ([IPv6:::ffff:212.5.174.154]:15498
	"EHLO zelcom.ru") by linux-mips.org with ESMTP id <S8225305AbUATNoG>;
	Tue, 20 Jan 2004 13:44:06 +0000
Received: from Pony.ns.zel.ru (70-com-st.gorcom.ru [212.45.15.70] (may be forged))
	by zelcom.ru (8.12.4/8.12.4) with ESMTP id i0KDi0Tq013760
	for <linux-mips@linux-mips.org>; Tue, 20 Jan 2004 16:44:02 +0300
Received: from mailserver sic-elvis
	=?ISO-8859-1?Q?=1Cby?= Pony.ns.zel.ru with =?ISO-8859-1?Q?ESMTP=1C?= id i0KDfx9U056010
	for <linux-mips@linux-mips.org.KAV>; Tue, 20 Jan 2004 16:41:59 +0300 (MSK)
	(envelope-from deepfire@sic-elvis.zel.ru)
Received: from mailserver sic-elvis
	by Pony.ns.zel.ru with ESMTP id i0KDfw9U056001
	for <linux-mips@linux-mips.org>; Tue, 20 Jan 2004 16:41:58 +0300 (MSK)
	(envelope-from deepfire@sic-elvis.zel.ru)
Date: Tue, 20 Jan 2004 16:42:46 +0300
Message-ID: <87fzeaviqx.wl@canopus.ns.zel.ru>
From: Samium Gromoff <deepfire@sic-elvis.zel.ru>
To: linux-mips@linux-mips.org
Subject: a shared cache_op() macros?
References: <87hdyqvjh2.wl@canopus.ns.zel.ru>
User-Agent: Wanderlust/2.10.1 (Watching The Wheels) SEMI/1.14.5 (Awara-Onsen) FLIM/1.14.5 (Demachiyanagi) APEL/10.6 Emacs/21.3 (i386-pc-linux-gnu) MULE/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen")
Content-Type: text/plain; charset=US-ASCII
Return-Path: <deepfire@sic-elvis.zel.ru>
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: 4061
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: deepfire@sic-elvis.zel.ru
Precedence: bulk
X-list: linux-mips


While pondering for some generic mips cache initialisation routines, i have found
a precious cache_op() macro in mm/r5k-sc.c.

And the question is, why isn`t it shared amongst all of the implementations
which could make use of it?

regards, Samium Gromoff



From ralf@linux-mips.org Tue Jan 20 13:49:47 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 20 Jan 2004 13:49:47 +0000 (GMT)
Received: from p508B6B36.dip.t-dialin.net ([IPv6:::ffff:80.139.107.54]:30238
	"EHLO mail.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225203AbUATNtr>; Tue, 20 Jan 2004 13:49:47 +0000
Received: from fluff.linux-mips.net (fluff.linux-mips.net [127.0.0.1])
	by mail.linux-mips.net (8.12.8/8.12.8) with ESMTP id i0KDnjex024978;
	Tue, 20 Jan 2004 14:49:45 +0100
Received: (from ralf@localhost)
	by fluff.linux-mips.net (8.12.8/8.12.8/Submit) id i0KDni8B024971;
	Tue, 20 Jan 2004 14:49:44 +0100
Date: Tue, 20 Jan 2004 14:49:44 +0100
From: Ralf Baechle <ralf@linux-mips.org>
To: Samium Gromoff <deepfire@sic-elvis.zel.ru>
Cc: linux-mips@linux-mips.org
Subject: Re: a shared cache_op() macros?
Message-ID: <20040120134944.GA24044@linux-mips.org>
References: <87hdyqvjh2.wl@canopus.ns.zel.ru> <87fzeaviqx.wl@canopus.ns.zel.ru>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <87fzeaviqx.wl@canopus.ns.zel.ru>
User-Agent: Mutt/1.4.1i
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: 4062
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 20, 2004 at 04:42:46PM +0300, Samium Gromoff wrote:

> While pondering for some generic mips cache initialisation routines, i
> have found a precious cache_op() macro in mm/r5k-sc.c.
> 
> And the question is, why isn`t it shared amongst all of the implementations
> which could make use of it?
> 
> regards, Samium Gromoff

You're looking at an ancient tree; this has long been done.

  Ralf

From deepfire@sic-elvis.zel.ru Tue Jan 20 13:57:20 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 20 Jan 2004 13:57:20 +0000 (GMT)
Received: from [IPv6:::ffff:212.5.174.154] ([IPv6:::ffff:212.5.174.154]:29578
	"EHLO zelcom.ru") by linux-mips.org with ESMTP id <S8225316AbUATN5U>;
	Tue, 20 Jan 2004 13:57:20 +0000
Received: from Pony.ns.zel.ru (70-com-st.gorcom.ru [212.45.15.70] (may be forged))
	by zelcom.ru (8.12.4/8.12.4) with ESMTP id i0KDvETq015672
	for <linux-mips@linux-mips.org>; Tue, 20 Jan 2004 16:57:15 +0300
Received: from mailserver sic-elvis
	=?ISO-8859-1?Q?=1Cby?= Pony.ns.zel.ru with =?ISO-8859-1?Q?ESMTP=1C?= id i0KDtF9U056120
	for <linux-mips@linux-mips.org.KAV>; Tue, 20 Jan 2004 16:55:15 +0300 (MSK)
	(envelope-from deepfire@sic-elvis.zel.ru)
Received: from mailserver sic-elvis
	by Pony.ns.zel.ru with ESMTP id i0KDtE9U056102;
	Tue, 20 Jan 2004 16:55:14 +0300 (MSK)
	(envelope-from deepfire@sic-elvis.zel.ru)
Date: Tue, 20 Jan 2004 16:56:07 +0300
Message-ID: <87ektuvi4o.wl@canopus.ns.zel.ru>
From: Samium Gromoff <deepfire@sic-elvis.zel.ru>
To: Ralf Baechle <ralf@linux-mips.org>
Cc: Samium Gromoff <deepfire@sic-elvis.zel.ru>,
	linux-mips@linux-mips.org
Subject: Re: a shared cache_op() macros?
In-Reply-To: <20040120134944.GA24044@linux-mips.org>
References: <87hdyqvjh2.wl@canopus.ns.zel.ru>
	<87fzeaviqx.wl@canopus.ns.zel.ru>
	<20040120134944.GA24044@linux-mips.org>
User-Agent: Wanderlust/2.10.1 (Watching The Wheels) SEMI/1.14.5 (Awara-Onsen) FLIM/1.14.5 (Demachiyanagi) APEL/10.6 Emacs/21.3 (i386-pc-linux-gnu) MULE/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen")
Content-Type: text/plain; charset=US-ASCII
Return-Path: <deepfire@sic-elvis.zel.ru>
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: 4063
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: deepfire@sic-elvis.zel.ru
Precedence: bulk
X-list: linux-mips

At Tue, 20 Jan 2004 14:49:44 +0100,
Ralf Baechle wrote:
> 
> On Tue, Jan 20, 2004 at 04:42:46PM +0300, Samium Gromoff wrote:
> 
> > While pondering for some generic mips cache initialisation routines, i
> > have found a precious cache_op() macro in mm/r5k-sc.c.
> > 
> > And the question is, why isn`t it shared amongst all of the implementations
> > which could make use of it?
> > 
> > regards, Samium Gromoff
> 
> You're looking at an ancient tree; this has long been done.

Well, yes, it`s 2.4.20 :-)

>   Ralf

regards, Samium Gromoff



From ralf@linux-mips.org Tue Jan 20 13:59:46 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 20 Jan 2004 13:59:47 +0000 (GMT)
Received: from p508B6B36.dip.t-dialin.net ([IPv6:::ffff:80.139.107.54]:40990
	"EHLO mail.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225203AbUATN7q>; Tue, 20 Jan 2004 13:59:46 +0000
Received: from fluff.linux-mips.net (fluff.linux-mips.net [127.0.0.1])
	by mail.linux-mips.net (8.12.8/8.12.8) with ESMTP id i0KDxiex025205;
	Tue, 20 Jan 2004 14:59:44 +0100
Received: (from ralf@localhost)
	by fluff.linux-mips.net (8.12.8/8.12.8/Submit) id i0KDxiXu025204;
	Tue, 20 Jan 2004 14:59:44 +0100
Date: Tue, 20 Jan 2004 14:59:44 +0100
From: Ralf Baechle <ralf@linux-mips.org>
To: kip.r2@free.fr
Cc: linux-mips@linux-mips.org
Subject: Re: MIPS PR3940
Message-ID: <20040120135944.GA25099@linux-mips.org>
References: <1074604231.400d28c7389a5@imp3-l.free.fr>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <1074604231.400d28c7389a5@imp3-l.free.fr>
User-Agent: Mutt/1.4.1i
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: 4064
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 20, 2004 at 02:10:31PM +0100, kip.r2@free.fr wrote:

> Hi all,
> I was wondering if anybody has already work with this processor. I'm expected 
> to make real-time applications on that platform. Do you think it is possible?

Forgive I'm too lazy to download documents but in case it's not working
yet it won't be hard to get Linux to work.

Realtime - depend what exactly you need.

  Ralf

From brederlo@informatik.uni-tuebingen.de Tue Jan 20 14:17:42 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 20 Jan 2004 14:17:42 +0000 (GMT)
Received: from mx5.Informatik.Uni-Tuebingen.De ([IPv6:::ffff:134.2.12.32]:403
	"EHLO mx5.informatik.uni-tuebingen.de") by linux-mips.org with ESMTP
	id <S8225474AbUATORm>; Tue, 20 Jan 2004 14:17:42 +0000
Received: from localhost (loopback [127.0.0.1])
	by mx5.informatik.uni-tuebingen.de (Postfix) with ESMTP
	id C7AEE123; Tue, 20 Jan 2004 15:17:33 +0100 (NFT)
Received: from mx5.informatik.uni-tuebingen.de ([127.0.0.1])
 by localhost (mx5 [127.0.0.1]) (amavisd-new, port 10024) with ESMTP
 id 22818-05; Tue, 20 Jan 2004 15:17:32 +0100 (NFT)
Received: from dual (semeai.Informatik.Uni-Tuebingen.De [134.2.15.66])
	by mx5.informatik.uni-tuebingen.de (Postfix) with ESMTP
	id D941B113; Tue, 20 Jan 2004 15:17:31 +0100 (NFT)
Received: from mrvn by dual with local (Exim 3.36 #1 (Debian))
	id 1Aiwh8-00014B-00; Tue, 20 Jan 2004 15:17:30 +0100
To: linux-mips@linux-mips.org
Cc: debian-mips@lists.debian.org
Subject: Need .config files for Debians kernel-image-2.4.24-mips(el)
From: Goswin von Brederlow <brederlo@informatik.uni-tuebingen.de>
Date: 20 Jan 2004 15:17:30 +0100
Message-ID: <878yk21z7p.fsf@mrvn.homelinux.org>
Lines: 28
User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Reasonable Discussion)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Virus-Scanned: by amavisd-new (McAfee AntiVirus) at informatik.uni-tuebingen.de
Return-Path: <brederlo@informatik.uni-tuebingen.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: 4065
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: brederlo@informatik.uni-tuebingen.de
Precedence: bulk
X-list: linux-mips

Hi,

I'm putting together a kernel image package for debian mips and
mipsel.

To build actual usefull images I need to know what hardware the
different subarchitectures have by default and which they can have.

Example:

My XXS1500 has onboard ethernet, sound, usb, flash card, smart card.
The usualy boot method would be from flash or nfs-root. My .config has
support for the flash, ethernet, initrd and nfs-root buildin but the
sound and usb as modules.

The .config should have only boot devices buildin and everything
supported for the subarch as modules. That way everyone can boot but
the memory footprint is kept reasonably low.



If you are unsure about what all is supported on your subarch or if
you only have a .config specialised to your needs send me that anyway
with a little note saying so. I can compare different .configs and
merge them or fix things when another user complains.

MfG
        Goswin

From agx@sigxcpu.org Tue Jan 20 14:43:15 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 20 Jan 2004 14:43:15 +0000 (GMT)
Received: from honk1.physik.uni-konstanz.de ([IPv6:::ffff:134.34.140.224]:58847
	"EHLO honk1.physik.uni-konstanz.de") by linux-mips.org with ESMTP
	id <S8225474AbUATOnP>; Tue, 20 Jan 2004 14:43:15 +0000
Received: from localhost (localhost [127.0.0.1])
	by honk1.physik.uni-konstanz.de (Postfix) with ESMTP
	id 7FA372BC42; Tue, 20 Jan 2004 15:43:13 +0100 (CET)
Received: from honk1.physik.uni-konstanz.de ([127.0.0.1])
 by localhost (honk [127.0.0.1:10024]) (amavisd-new) with ESMTP id 23859-08;
 Tue, 20 Jan 2004 15:42:51 +0100 (CET)
Received: from bogon.sigxcpu.org (bogon.physik.uni-konstanz.de [134.34.147.122])
	by honk1.physik.uni-konstanz.de (Postfix) with ESMTP
	id 2CDDE2BC3C; Tue, 20 Jan 2004 15:42:51 +0100 (CET)
Received: by bogon.sigxcpu.org (Postfix, from userid 1000)
	id 0D30A4198; Tue, 20 Jan 2004 15:42:13 +0100 (CET)
Date: Tue, 20 Jan 2004 15:42:12 +0100
From: Guido Guenther <agx@debian.org>
To: Goswin von Brederlow <brederlo@informatik.uni-tuebingen.de>
Cc: linux-mips@linux-mips.org, debian-mips@lists.debian.org
Subject: Re: Need .config files for Debians kernel-image-2.4.24-mips(el)
Message-ID: <20040120144212.GA7046@bogon.ms20.nix>
Mail-Followup-To: Guido Guenther <agx@debian.org>,
	Goswin von Brederlow <brederlo@informatik.uni-tuebingen.de>,
	linux-mips@linux-mips.org, debian-mips@lists.debian.org
References: <878yk21z7p.fsf@mrvn.homelinux.org>
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="45Z9DzgjV8m4Oswq"
Content-Disposition: inline
In-Reply-To: <878yk21z7p.fsf@mrvn.homelinux.org>
User-Agent: Mutt/1.5.5.1+cvs20040105i
X-Virus-Scanned: by amavisd-new-20021227-p2 (Debian)
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: 4066
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@debian.org
Precedence: bulk
X-list: linux-mips


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

On Tue, Jan 20, 2004 at 03:17:30PM +0100, Goswin von Brederlow wrote:
> I'm putting together a kernel image package for debian mips and
> mipsel.
We already have that (we're at 2.4.22 currently, look for
kernel-patch-2.4.X-mips). Please don't add new packages, you're welcome
to take over the current packages however.
 -- Guido

--45Z9DzgjV8m4Oswq
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

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

iD8DBQFADT5En88szT8+ZCYRAsGBAJ9OqXX/D2t1JlJqrm29hnveR8ctFQCfabIy
SrepEH47ZVhtc1aNQtbdR9c=
=+S0a
-----END PGP SIGNATURE-----

--45Z9DzgjV8m4Oswq--

From brederlo@informatik.uni-tuebingen.de Tue Jan 20 16:23:55 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 20 Jan 2004 16:23:56 +0000 (GMT)
Received: from mx5.Informatik.Uni-Tuebingen.De ([IPv6:::ffff:134.2.12.32]:10900
	"EHLO mx5.informatik.uni-tuebingen.de") by linux-mips.org with ESMTP
	id <S8225437AbUATQXz>; Tue, 20 Jan 2004 16:23:55 +0000
Received: from localhost (loopback [127.0.0.1])
	by mx5.informatik.uni-tuebingen.de (Postfix) with ESMTP
	id A3883128; Tue, 20 Jan 2004 17:23:45 +0100 (NFT)
Received: from mx5.informatik.uni-tuebingen.de ([127.0.0.1])
 by localhost (mx5 [127.0.0.1]) (amavisd-new, port 10024) with ESMTP
 id 43238-03; Tue, 20 Jan 2004 17:23:44 +0100 (NFT)
Received: from dual (semeai.Informatik.Uni-Tuebingen.De [134.2.15.66])
	by mx5.informatik.uni-tuebingen.de (Postfix) with ESMTP
	id 62AC9113; Tue, 20 Jan 2004 17:23:43 +0100 (NFT)
Received: from mrvn by dual with local (Exim 3.36 #1 (Debian))
	id 1AiyfE-0001Qo-00; Tue, 20 Jan 2004 17:23:40 +0100
To: Guido Guenther <agx@debian.org>
Cc: linux-mips@linux-mips.org, debian-mips@lists.debian.org
Subject: Re: Need .config files for Debians kernel-image-2.4.24-mips(el)
References: <878yk21z7p.fsf@mrvn.homelinux.org>
	<20040120144212.GA7046@bogon.ms20.nix>
From: Goswin von Brederlow <brederlo@informatik.uni-tuebingen.de>
Date: 20 Jan 2004 17:23:39 +0100
In-Reply-To: <20040120144212.GA7046@bogon.ms20.nix>
Message-ID: <874quq1tdg.fsf@mrvn.homelinux.org>
Lines: 46
User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Reasonable Discussion)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Virus-Scanned: by amavisd-new (McAfee AntiVirus) at informatik.uni-tuebingen.de
Return-Path: <brederlo@informatik.uni-tuebingen.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: 4067
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: brederlo@informatik.uni-tuebingen.de
Precedence: bulk
X-list: linux-mips

Guido Guenther <agx@debian.org> writes:

> On Tue, Jan 20, 2004 at 03:17:30PM +0100, Goswin von Brederlow wrote:
> > I'm putting together a kernel image package for debian mips and
> > mipsel.
> We already have that (we're at 2.4.22 currently, look for
> kernel-patch-2.4.X-mips). Please don't add new packages, you're welcome
> to take over the current packages however.
>  -- Guido

I saw that and am updating it. I was planing of sending you a patch
when its done and working. If you feel your time is running short
(when isn't it) I would rather do a comaintainership then taking it
over completly. Since I'm not a DD yet, still in the NM queue, I would
need a sponsor for the package anyway. Something as important as the
kernel should be cared for my more than one person to minimize
reaction times to security exploits.


While working on the upgrade I came across some questions:

Is the kernel-patch-2.4.22-mips relative to the debian kernel source
or the vanilla source? And is the result (after patching) the mips cvs
or cvs merged with the debian patch? And should that be done that way
again?

I tried a dry run on the debian patch on top of the mips cvs and saw a
few conflicts. Merging the two would be some more work.

Apart from updating the patch (vanila->mips cvs, testing if it gives
any conflicts now) I added my own system XXS1500 board from MyCable to
the configs and added the kernel-image deb and udebs to the control
file. No major changes yet.

Have you thought about dropping the udebs and letting debian-installer
build -di udebs the way it does for several other arches now?

[
1 out of 17 hunks FAILED -- saving rejects to file arch/mips64/kernel/ioctl32.c.rej

So I guess the source to patch from includes the debian patch. Now I
only need to know what the result should be, i.e. pure cvs or merged?
]

MfG
        Goswin

From rathann@icm.edu.pl Tue Jan 20 16:28:10 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 20 Jan 2004 16:28:10 +0000 (GMT)
Received: from gw.icm.edu.pl ([IPv6:::ffff:212.87.0.39]:62503 "EHLO
	atol.icm.edu.pl") by linux-mips.org with ESMTP id <S8225442AbUATQ2K>;
	Tue, 20 Jan 2004 16:28:10 +0000
Received: from rekin.icm.edu.pl (rekin.icm.edu.pl [192.168.1.132])
	by atol.icm.edu.pl (8.12.6/8.12.6/rzm-4.6/icm) with ESMTP id i0KGRwCM028999
	for <linux-mips@linux-mips.org>; Tue, 20 Jan 2004 17:27:58 +0100 (CET)
Received: from rathann by rekin.icm.edu.pl with local (Exim 3.35 #1 (Debian))
	id 1AiyjR-0007lC-00
	for <linux-mips@linux-mips.org>; Tue, 20 Jan 2004 17:28:01 +0100
Date: Tue, 20 Jan 2004 17:28:01 +0100
From: "Dominik 'Rathann' Mierzejewski" <rathann@icm.edu.pl>
To: linux-mips@linux-mips.org
Subject: Re: Current 2.4 CVS (2.4.24-pre2) doesn't boot on SGI Indy
Message-ID: <20040120162800.GA29792@icm.edu.pl>
Mail-Followup-To: linux-mips@linux-mips.org
References: <20040115141427.GA28546@icm.edu.pl> <Pine.LNX.4.21.0401151816540.3511-100000@www.marty44.net> <20040115231735.GA6619@icm.edu.pl> <4007386F.80207@gentoo.org> <20040115172602.H18368@mvista.com> <20040116115053.GA18099@icm.edu.pl> <20040120130625.GA24435@icm.edu.pl>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20040120130625.GA24435@icm.edu.pl>
User-Agent: Mutt/1.3.28i
Return-Path: <rathann@icm.edu.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: 4068
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: rathann@icm.edu.pl
Precedence: bulk
X-list: linux-mips

On Tue, Jan 20, 2004 at 02:06:26PM +0100, Dominik 'Rathann' Mierzejewski wrote:
[...]
> OK, I've narrowed it down to sometime between 20031205 and 20031214, but
> since there were no commits between 20031204 and 20031211, it has to be one
> of these:
> 
> 6242 2003/12/11 01:29:17 linux_2_4 ralf Fix a bunch of long standing bugs
> and performance clear_page issues: - Fi .....
[...] 
> Still searching...

Found it! After applying the above patch, the kernel no longer goes
past the "Freeing unused kernel memory" stage. So for now I'm sticking
with the 20031205 kernel.

HTH & HAND

-- 
Dominik 'Rathann' Mierzejewski <rathann@icm.edu.pl>                                                 
Interdisciplinary Centre for Mathematical and Computational Modelling                               
Warsaw University  |  http://www.icm.edu.pl  |  tel. +48 (22) 5540810                               

From ica2_ts@csv.ica.uni-stuttgart.de Tue Jan 20 16:47:30 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 20 Jan 2004 16:47:31 +0000 (GMT)
Received: from iris1.csv.ica.uni-stuttgart.de ([IPv6:::ffff:129.69.118.2]:10573
	"EHLO iris1.csv.ica.uni-stuttgart.de") by linux-mips.org with ESMTP
	id <S8225437AbUATQra>; Tue, 20 Jan 2004 16:47:30 +0000
Received: from rembrandt.csv.ica.uni-stuttgart.de ([129.69.118.42])
	by iris1.csv.ica.uni-stuttgart.de with esmtp
	id 1Aiz2E-0006Ev-00; Tue, 20 Jan 2004 17:47:26 +0100
Received: from ica2_ts by rembrandt.csv.ica.uni-stuttgart.de with local (Exim 3.35 #1 (Debian))
	id 1Aiz2E-0000qz-00; Tue, 20 Jan 2004 17:47:26 +0100
Date: Tue, 20 Jan 2004 17:47:26 +0100
To: Goswin von Brederlow <brederlo@informatik.uni-tuebingen.de>
Cc: Guido Guenther <agx@debian.org>, linux-mips@linux-mips.org,
	debian-mips@lists.debian.org
Subject: Re: Need .config files for Debians kernel-image-2.4.24-mips(el)
Message-ID: <20040120164726.GA22218@rembrandt.csv.ica.uni-stuttgart.de>
References: <878yk21z7p.fsf@mrvn.homelinux.org> <20040120144212.GA7046@bogon.ms20.nix> <874quq1tdg.fsf@mrvn.homelinux.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <874quq1tdg.fsf@mrvn.homelinux.org>
User-Agent: Mutt/1.5.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: 4069
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

Goswin von Brederlow wrote:
[snip]
> While working on the upgrade I came across some questions:
> 
> Is the kernel-patch-2.4.22-mips relative to the debian kernel source
> or the vanilla source?

It'S relative to the debian kernel source package.

> And is the result (after patching) the mips cvs
> or cvs merged with the debian patch? And should that be done that way
> again?

AFAIK mips cvs plus (usually generic) debian fixes.

[snip]
> Have you thought about dropping the udebs and letting debian-installer
> build -di udebs the way it does for several other arches now?

The decstations still use the -udeb flavour.


Thiemo

From pypark@nayna.com Tue Jan 20 17:01:58 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 20 Jan 2004 17:01:59 +0000 (GMT)
Received: from ip66-106-155-114.z155-106-66.customer.algx.net ([IPv6:::ffff:66.106.155.114]:22551
	"EHLO atomant.nayna.com") by linux-mips.org with ESMTP
	id <S8225437AbUATRB6>; Tue, 20 Jan 2004 17:01:58 +0000
Received: by atomant.nayna.com with Internet Mail Service (5.5.2653.19)
	id <R91WCXDB>; Tue, 20 Jan 2004 08:59:47 -0800
Message-ID: <DFDD2BC6A4D8D711B8980090279CF95B0176FF@atomant.nayna.com>
From: "Young Chul Park (Patrick)" <pypark@nayna.com>
To: "'jsun@junsun.net'" <jsun@junsun.net>,
	"'linux-mips@linux-mips.org'" <linux-mips@linux-mips.org>
Subject: Linux on Monta-Vista DB88E6318 board carsh
Date: Tue, 20 Jan 2004 08:59:47 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Return-Path: <pypark@nayna.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: 4070
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: pypark@nayna.com
Precedence: bulk
X-list: linux-mips

Hi,
I am Patrick of Nayna networks.
( Board name DB-88E6318 and CPU type MIPS - 5KC )

Now I am trying to boot Linux 2.4.18 ( Marvell-Monta Vista Distribution. )
I am using NFS Root mount  and it normally mounted as I posted it.
after that. problems are happen.
After nfsroot mounted , automatically init procedures in busybox are
executed.
I saw that there was some discussion between  Atifa_Kheel@yahoo.com and
mips-org.
It's similar symtoms but not much help.
In attached screenshot, For debugging purpose, I put this kind of strings
like
==========================================
!!/dev/console!!
!!!! Inside find_next_zero_bit
 !!!
 good /dev/console
!!!! Inside find_next_zero_bit !!!

 next_fd = 2 in fcntl<4>!!!! Inside find_next_zero_bit !!!

 next_fd = 3 in fcntl
 in do_execve /sbin/init
 retval = 1
 in do_execve /etc/init
 retval = 1
 in do_execve /bin/init!!!! Insid
e find_next_zero_bit !!!
Using ELF interpreter /lib/ld.so.1
!!/etc/ld.so.preload!!
==================================================

In busybox main routines, It tries to detect real console and reads the
inittab ( Nothing else just call rc.sysinit )
and inside rc.sysinit, just tries to mount proc ... ( and consecutively
necessary command are listed )
and after that suddenly crashed. 

Anybody who have some tips, I appreciate in advance.

Regards
Patrick

ps] We tried gcc version 2.91.66  and 3.2.2 also. but same as upon.

=====================================================================
MIPSBoot-> go a0400000
## Starting application at 0xa0400000 ...
1
 PRID_IMP_5KC
32MB SDRAM auto-detected (High Decode Address 0x1f)
platformRevision = 2 (Firehawk DB-88E6318 Rev 3.0)
CPU revision is: 0101810a
FPU revision is: 0003810a
Primary instruction cache 16kb, linesize 32 bytes (4 ways)
Primary data cache 8kb, linesize 32 bytes (2 ways)
Linux version 2.4.18-MIPS-01.01 (root@mips-build) (gcc version egcs-2.91.66
1999
0314 (egcs-1.1.2 release)) #69 Mon Jan 19 20:30:06 EST 2004
Determined physical RAM map:
 memory: 01dfffff @ 00000000 (usable)
On node 0 totalpages: 7679
zone(0): 7679 pages.
zone(1): 0 pages.
zone(2): 0 pages.
Kernel command line: console=ttyS1,38400 noinitrd root=/dev/nfs
nfsroot=172.16.1
.210:/home/mips/rootfs
ip=172.16.200.200:172.16.1.210:172.16.0.1:255.255.0.0:rgp
:eth0:
Calibrating delay loop... 255.59 BogoMIPS
calibrating MIPS CPU counter frequency ... 128012730 Hz
Memory: 28468k/30716k available (1397k kernel code, 2248k reserved, 152k
data, 7
6k init, 0k highmem)
Dentry-cache hash table entries: 4096 (order: 3, 32768 bytes)
Inode-cache hash table entries: 2048 (order: 2, 16384 bytes)
Mount-cache hash table entries: 512 (order: 0, 4096 bytes)
Buffer-cache hash table entries: 1024 (order: 0, 4096 bytes)
Page-cache hash table entries: 8192 (order: 3, 32768 bytes)
Checking for 'wait' instruction...  unavailable.
POSIX conformance testing by UNIFIX
Autoconfig PCI channel 0x80199ac8
Scanning bus 00, I/O 0x15000000:0x16000001, Mem 0x16000000:0x18000001
00:08.0 Class 0200: 8086:1229 (rev 08)
        Mem at 0x16000000 [size=0x1000]
        I/O at 0x15000000 [size=0x40]
        Mem at 0x16100000 [size=0x100000]
pcibios_fixup_irqs: slot=8
Linux NET4.0 for Linux 2.4
Based upon Swansea University Computer Society NET3.039
Initializing RT netlink socket
Starting kswapd
LMNpty: 256 Unix98 ptys configured
Serial driver version 5.05c (2001-07-08) with MANY_PORTS SHARE_IRQ
SERIAL_PCI en
abled
ttyS00 at 0xb400c840x (irq = 23) is a 16550A
ttyS01 at 0xb400c8c0x (irq = 24) is a 16550A
rtc: I/O port 112 is not free.
block: 64 slots per queue, batch=16
RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize
loop: loaded (max 8 devices)
eepro100.c:v1.09j-t 9/29/99 Donald Becker
http://www.scyld.com/network/eepro100.
html
eepro100.c: $Revision: 1.1.1.1 $ 2000/11/17 Modified by Andrey V. Savochkin
<saw
@saw.sw.com.sg> and others
eth0: PCI device 8086:1229, 00:D0:B7:1C:BA:37, IRQ 48.
  Board assembly 721383-008, Physical connectors present: RJ45
  Primary interface chip i82555 PHY #1.
  General self-test: passed.
  Serial sub-system self-test: passed.
  Internal registers self-test: passed.
  ROM checksum self-test: passed (0x04f4518b).
boot_remap register = 0x1fc00000
Probing MTD devices at address 0x1e000000 (0x1000000 in size)
Creating 2 MTD partitions on "MV-88E6318 flash":
0x00000000-0x00200000 : "MV-88E6318 kernel partition"
0x00200000-0x01000000 : "MV-88E6318 file-system partition"
NET4: Linux TCP/IP 1.0 for NET4.0
IP Protocols: ICMP, UDP, TCP
IP: routing cache hash table of 512 buckets, 4Kbytes
TCP: Hash tables configured (established 2048 bind 2048)
IP-Config: Complete:
      device=eth0, addr=172.16.200.200, mask=255.255.0.0, gw=172.16.0.1,
     host=rgp, domain=, nis-domain=(none),
     bootserver=172.16.1.210, rootserver=172.16.1.210, rootpath=
NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
Root-NFS: Mounting /home/mips/rootfs on server 172.16.1.210 as root
Root-NFS:     rsize = 4096, wsize = 4096, timeo = 7, retrans = 3
Root-NFS:     acreg (min,max) = (3,60), acdir (min,max) = (30,60)
Root-NFS:     nfsd port = -1, mountd port = 0, flags = 00000200
Root-NFS: IPPROTO = UDP <5>Looking up port of RPC 100003/2 on 172.16.1.210
Root-NFS: Portmapper on server returned 2049 as nfsd port
Looking up port of RPC 100005/1 on 172.16.1.210
Root-NFS: mountd port is 32855
NFS:      nfs_mount(ac1001d2:/home/mips/rootfs)
VFS: Mounted root (nfs filesystem).
Freeing unused kernel memory: 76k freed

!!/dev/console!!
cfo = 801790c4!!!! Inside find_next_zero_bit
 !!!
 good /dev/console
!!!! Inside find_next_zero_bit !!!

 next_fd = 2 in fcntl<4>!!!! Inside find_next_zero_bit !!!

 next_fd = 3 in fcntl
 in do_execve /sbin/init
 retval = 1
 in do_execve /etc/init
 retval = 1
 in do_execve /bin/init!!!! Insid
e find_next_zero_bit !!!
Using ELF interpreter /lib/ld.so.1
!!/etc/ld.so.preload!!
!!!! Inside find_next_zero_bit !!!
out_err /etc/ld.so.preload

 good /etc/ld.so.preload

!!/etc/ld.so.cache!!
!!!! Inside find_next_zero_bit
 !!!
out_err /etc/ld.so.cache

 good /etc/ld.so.cache

!!/lib/libc.so.6!!
!!!! Inside find_next_zero_bit
 !!!
 good /lib/libc.so.6

!!/dev/console!!
!!!! Inside find_next_zero_bit
 !!!
 good /dev/console

!!/etc/localtime!!
!!!! Inside find_next_zero_bit
 !!!
out_err /etc/localtime

 good /etc/localtime
!!!! Inside find_next_zero_bit !!
!
!!/dev/console!!
!!!! Inside find_next_zero_bit
 !!!
 good /dev/console
serial console detected.  Disabling virtual terminals.
!!!! Inside find_next_zero_bit !!
!
!!!! Inside find_next_zero_bit !!!
!!/dev/console!!
!!!! Inside find_next_zero_bit
 !!!
 good /dev/console
init started:  BusyBox v0.60.3 (2002.12.19-11:07+0000) multi-call binary

!!/etc/inittab!!
!!!! Inside find_next_zero_bit
 !!!
 good /etc/inittab

!!/dev/console!!
!!!! Inside find_next_zero_bit
 !!!
 good /dev/console
!!!! Inside find_next_zero_bit !!!

<4>!!!! Inside find_next_zero_bit !!!

!!!! Inside
find_next_zero_bit !!!
 in do_execve /etc/rc.sysinit!!!!
 Inside find_next_zero_bit !!!
Using ELF interpreter /lib/ld.so.1
!!/etc/ld.so.preload!!
!!!! Inside find_next_zero_bit
 !!!
out_err /etc/ld.so.preload
 good /etc/ld.so.preload

!!/etc/ld.so.cache!!
Kernel unaligned instruction access in unaligned.c:do_ade, line 407:
$0 : 00000000 30001000 00000001 00000001 80133ea8 00000001 00000001 00000001
$8 : 8019ad80 00001000 80172000 00000003 00000000 00000000 8019a98e 00000000
$16: 2aac00f4 80172000 00000001 1000001f ffffffe8 00000000 00000000 7fff7278
$24: 00000000 2aabd430                   810a4000 810a5ed0 00403784 80034470
Hi : 00000000
Lo : 00000000
epc  : 80034468    Not tainted
Status: 30001003
Cause : 80808010
Process EUR (pid: 10, stackpage=810a4000)
Stack: 80133ea4 00000001 00000001 00000001 2aac00f4 80172000 00000001
00000000
       80172000 2ab01b78 00000000 7fff7278 80034758 8003477c 80133f2c
00000001
       00000001 00000001 ffffffff ffffffff 00000001 2ab01788 00403784
800068e8
       7fff7b78 7fff7778 7fff7d78 00000000 ffffffff 00000000 00000000
2ab01790
       00000fa5 00000002 2aac00f4 00000000 00000001 00000000 81010100
00000001
       00000000 ...
Call Trace:
Code: 0000a821  3c048013  24843ea8 <0c003fa4> 8e65001c  3c048013  24843eb4
0c00
3fa4  8e65000c
Unable to handle kernel paging request at virtual address 2ab01b80, epc ==
8008e
db0, ra == 8001381c
Oops in fault.c:do_page_fault, line 205:
$0 : 00000000 80180000 00000001 00000002 00000019 00000000 00000200 81d8e000
$8 : 81079d50 30001001 810a5c90 00000000 00000000 00000000 8019a989 fffffffe
$16: 801621c0 2ab01b78 810a4264 ffffffff 80131040 0000000b 00000000 7fff7278
$24: ffffffff 810a5c47                   810a4000 810a5d70 00403784 8001381c
Hi : 00000000
Lo : 00000020
epc  : 8008edb0    Not tainted
Status: 30001003
Cause : 00808008
Process EUR (pid: 10, stackpage=810a4000)
Stack: 8000dee4 810a5d98 00403784 80004a60 801621c0 00000197 810a4000
801310f8
       8001381c 00809000 ffffffe8 00000000 00000000 7fff7278 8012e9e8
00000197
       810a5e20 1000001f ffffffe8 00000000 80004a60 80004a44 8012da60
00000001
       00000001 00000020 2aac00f4 810a5e20 00000001 80004a80 00000005
810a5e10
       8018ac88 00001bcf 80006ea4 8019ad80 00001bd0 0000003e 0000003c
00000001
       2aac00f4 ...
Call Trace:
Code: 8e510000  12200054  2413ffff <8e250008> 10b3004a  00a03021  04a10002
00a0
1021  24a27fff
Unable to handle kernel paging request at virtual address 2ab01b80, epc ==
8008e
db0, ra == 8001381c
Oops in fault.c:do_page_fault, line 205:
$0 : 00000000 30001000 00000001 00000000 00000000 30001001 00000000 0000249e
$8 : ffffffff 0000000a 810a5aaa 00000000 00000000 00000000 8019a989 fffffffe
$16: 00000000 2ab01b78 810a4264 ffffffff 80131040 0000000b 00000000 7fff7278
$24: ffffffff 810a5a67                   810a4000 810a5b90 0
=======================================================================

From savl@dev.rtsoft.ru Tue Jan 20 17:39:07 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 20 Jan 2004 17:39:07 +0000 (GMT)
Received: from RT-soft-2.Moscow.itn.ru ([IPv6:::ffff:80.240.96.70]:47335 "HELO
	mail.dev.rtsoft.ru") by linux-mips.org with SMTP
	id <S8225554AbUATRjH>; Tue, 20 Jan 2004 17:39:07 +0000
Received: (qmail 17281 invoked from network); 20 Jan 2004 17:18:22 -0000
Received: from unknown (HELO dev.rtsoft.ru) (192.168.1.132)
  by mail.dev.rtsoft.ru with SMTP; 20 Jan 2004 17:18:22 -0000
Message-ID: <400D6877.1000105@dev.rtsoft.ru>
Date: Tue, 20 Jan 2004 20:42:15 +0300
From: Pavel Kiryukhin <savl@dev.rtsoft.ru>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: linux-mips@linux-mips.org
Subject: __MIPSEL__ in sys32_rt_sigtimedwait
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Return-Path: <savl@dev.rtsoft.ru>
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: 4071
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: savl@dev.rtsoft.ru
Precedence: bulk
X-list: linux-mips

Hi all,
my question - does endiannes matters in sigset translation in 
sys32_rt_sigtimedwait (arch/mips/signal32.c)?

===================
@@ -827,18 +827,10 @@
         return -EFAULT;
 
     switch (_NSIG_WORDS) {
-#ifdef __MIPSEB__
     case 4: these.sig[3] = these32.sig[6] | (((long)these32.sig[7]) << 32);
     case 3: these.sig[2] = these32.sig[4] | (((long)these32.sig[5]) << 32);
     case 2: these.sig[1] = these32.sig[2] | (((long)these32.sig[3]) << 32);
     case 1: these.sig[0] = these32.sig[0] | (((long)these32.sig[1]) << 32);
-#endif
-#ifdef __MIPSEL__
-    case 4: these.sig[3] = these32.sig[7] | (((long)these32.sig[6]) << 32);
-    case 3: these.sig[2] = these32.sig[5] | (((long)these32.sig[4]) << 32);
-    case 2: these.sig[1] = these32.sig[3] | (((long)these32.sig[2]) << 32);
-    case 1: these.sig[0] = these32.sig[1] | (((long)these32.sig[0]) << 32);
-#endif
     }
 
     /*
===================
Regards,
Pavel Kiryukhin



From jsun@mvista.com Tue Jan 20 18:22:08 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 20 Jan 2004 18:22:08 +0000 (GMT)
Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:27637 "EHLO
	orion.mvista.com") by linux-mips.org with ESMTP id <S8225442AbUATSWI>;
	Tue, 20 Jan 2004 18:22:08 +0000
Received: (from jsun@localhost)
	by orion.mvista.com (8.11.6/8.11.6) id i0KIM5Q07510;
	Tue, 20 Jan 2004 10:22:05 -0800
Date: Tue, 20 Jan 2004 10:22:05 -0800
From: Jun Sun <jsun@mvista.com>
To: "Young Chul Park (Patrick)" <pypark@nayna.com>
Cc: "'linux-mips@linux-mips.org'" <linux-mips@linux-mips.org>,
	jsun@mvista.com
Subject: Re: Linux on Monta-Vista DB88E6318 board carsh
Message-ID: <20040120102205.B6816@mvista.com>
References: <DFDD2BC6A4D8D711B8980090279CF95B0176FF@atomant.nayna.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <DFDD2BC6A4D8D711B8980090279CF95B0176FF@atomant.nayna.com>; from pypark@nayna.com on Tue, Jan 20, 2004 at 08:59:47AM -0800
Return-Path: <jsun@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: 4072
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 20, 2004 at 08:59:47AM -0800, Young Chul Park (Patrick) wrote:
> Hi,
> I am Patrick of Nayna networks.
> ( Board name DB-88E6318 and CPU type MIPS - 5KC )
> 
> Now I am trying to boot Linux 2.4.18 ( Marvell-Monta Vista Distribution. )

AFAIK, montavista never supported DB-88E6318.  This is probably Mvrvell's
release.

Jun

From ralf@linux-mips.org Tue Jan 20 18:32:19 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 20 Jan 2004 18:32:19 +0000 (GMT)
Received: from p508B6B36.dip.t-dialin.net ([IPv6:::ffff:80.139.107.54]:40482
	"EHLO mail.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225566AbUATScT>; Tue, 20 Jan 2004 18:32:19 +0000
Received: from fluff.linux-mips.net (fluff.linux-mips.net [127.0.0.1])
	by mail.linux-mips.net (8.12.8/8.12.8) with ESMTP id i0KIW6ex006298;
	Tue, 20 Jan 2004 19:32:06 +0100
Received: (from ralf@localhost)
	by fluff.linux-mips.net (8.12.8/8.12.8/Submit) id i0KIVvE8006288;
	Tue, 20 Jan 2004 19:31:57 +0100
Date: Tue, 20 Jan 2004 19:31:57 +0100
From: Ralf Baechle <ralf@linux-mips.org>
To: Pavel Kiryukhin <savl@dev.rtsoft.ru>
Cc: linux-mips@linux-mips.org
Subject: Re: __MIPSEL__ in sys32_rt_sigtimedwait
Message-ID: <20040120183157.GB5495@linux-mips.org>
References: <400D6877.1000105@dev.rtsoft.ru>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <400D6877.1000105@dev.rtsoft.ru>
User-Agent: Mutt/1.4.1i
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: 4073
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 20, 2004 at 08:42:15PM +0300, Pavel Kiryukhin wrote:

> Hi all,
> my question - does endiannes matters in sigset translation in 
> sys32_rt_sigtimedwait (arch/mips/signal32.c)?

Think about where bit 33 ends for a big endian machine with an without
the conversion.

  Ralf

From drow@crack.them.org Tue Jan 20 19:39:24 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 20 Jan 2004 19:39:24 +0000 (GMT)
Received: from nevyn.them.org ([IPv6:::ffff:66.93.172.17]:50319 "EHLO
	nevyn.them.org") by linux-mips.org with ESMTP id <S8225559AbUATTjY>;
	Tue, 20 Jan 2004 19:39:24 +0000
Received: from drow by nevyn.them.org with local (Exim 4.30 #1 (Debian))
	id 1Aj1iY-0007kl-PL; Tue, 20 Jan 2004 14:39:18 -0500
Date: Tue, 20 Jan 2004 14:39:18 -0500
From: Daniel Jacobowitz <dan@debian.org>
To: Ralf Baechle <ralf@linux-mips.org>
Cc: Pavel Kiryukhin <savl@dev.rtsoft.ru>, linux-mips@linux-mips.org
Subject: Re: __MIPSEL__ in sys32_rt_sigtimedwait
Message-ID: <20040120193918.GA2108@nevyn.them.org>
References: <400D6877.1000105@dev.rtsoft.ru> <20040120183157.GB5495@linux-mips.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20040120183157.GB5495@linux-mips.org>
User-Agent: Mutt/1.5.1i
Return-Path: <drow@crack.them.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: 4074
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: dan@debian.org
Precedence: bulk
X-list: linux-mips

On Tue, Jan 20, 2004 at 07:31:57PM +0100, Ralf Baechle wrote:
> On Tue, Jan 20, 2004 at 08:42:15PM +0300, Pavel Kiryukhin wrote:
> 
> > Hi all,
> > my question - does endiannes matters in sigset translation in 
> > sys32_rt_sigtimedwait (arch/mips/signal32.c)?
> 
> Think about where bit 33 ends for a big endian machine with an without
> the conversion.

No, I'm pretty sure Pavel's right.

-#ifdef __MIPSEB__
    case 1: these.sig[0] = these32.sig[0] | (((long)these32.sig[1]) << 32);
-#endif
-#ifdef __MIPSEL__
-    case 1: these.sig[0] = these32.sig[1] | (((long)these32.sig[0]) << 32);
-#endif

Consider a 64-bit sigset.  32-bit userland, 64-bit kernel.  Here's a
userland sigset with signal 33 set, only, on a little endian target.
Word 1, least significant bit, right?

byte address in memory
	1	2	3	4	5	6	7	8
val	0	0	0	0	0	0	0	1

Obviously, as a 64-bit integer the sigset looks different.  There it's
supposed to be 1 << (33 - 1).
val	0	0	0	1	0	0	0	0

So the correct algorithm to convert a userspace sigset to a kernel
sigset is to shift the second word left 32 bits, and leave the first
word right aligned, and or them together.  Which is what using the
__MIPSEB__ case does.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

From dimitri@sonycom.com Tue Jan 20 20:40:33 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 20 Jan 2004 20:40:34 +0000 (GMT)
Received: from witte.sonytel.be ([IPv6:::ffff:80.88.33.193]:65489 "EHLO
	witte.sonytel.be") by linux-mips.org with ESMTP id <S8225559AbUATUkd>;
	Tue, 20 Jan 2004 20:40:33 +0000
Received: from teasel.sonytel.be (localhost [127.0.0.1])
	by witte.sonytel.be (8.12.10/8.12.10) with ESMTP id i0KKeTw1006574;
	Tue, 20 Jan 2004 21:40:29 +0100 (MET)
Received: (from dimitri@localhost)
	by teasel.sonytel.be (8.9.3+Sun/8.9.3) id VAA09656;
	Tue, 20 Jan 2004 21:40:28 +0100 (MET)
Date: Tue, 20 Jan 2004 21:40:28 +0100
From: Dimitri Torfs <dimitri@sonycom.com>
To: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
Cc: linux-mips@linux-mips.org
Subject: Re: Support for newer gcc/gas options
Message-ID: <20040120204026.GA9470@sonycom.com>
References: <20031223114644.GA5458@sonycom.com> <Pine.LNX.4.55.0312231303030.27594@jurand.ds.pg.gda.pl> <Pine.LNX.4.55.0401201332080.12841@jurand.ds.pg.gda.pl>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Pine.LNX.4.55.0401201332080.12841@jurand.ds.pg.gda.pl>
User-Agent: Mutt/1.4.1i
Return-Path: <dimitri@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: 4075
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: dimitri@sonycom.com
Precedence: bulk
X-list: linux-mips

On Tue, Jan 20, 2004 at 01:37:16PM +0100, Maciej W. Rozycki wrote:
> 
>  It took a bit longer than I planned, sorry.  Anyway, here are two
> functionally equivalent patches, for 2.4 and the head, that remove an ISA
> specification if a tool supports "-march=" and "-mabi=" at the same time.  
> Please try the appropriate one.
> 

Tried the head one, it had some typos (patch follows). Unfortunately, as I wrote
earlier, gcc-3.2 doesn't set the ISA correctly when using -march=, so
it doesn't work for 3.2. 


--- linux-mips-2.6.orig/arch/mips/Makefile	2004-01-06 21:17:57.000000000 +0100
+++ linux.work/arch/mips/Makefile	2004-01-20 21:14:12.000000000 +0100
@@ -111,6 +111,12 @@
 if test x$(gcc-abi) != x$(gas-abi); then \
 	gas_abi="-Wa,-$(gas-abi) -Wa,-mgp$(gcc-abi)"; \
 fi; \
+if test "$$gcc_opt" = -march= && test -n "$$gcc_abi"; then \
+	gcc_isa=; \
+fi; \
+if test "$$gas_opt" = -Wa,-march= && test -n "$$gas_abi"; then \
+	gas_isa=; \
+fi; \
 echo $$gcc_abi $$gcc_opt$$gcc_cpu $$gcc_isa $$gas_abi $$gas_opt$$gas_cpu $$gas_isa)
 
 #


-- 
Dimitri Torfs       |  NSCE 
dimitri@sonycom.com |  The Corporate Village
tel: +32 2 7008541  |  Da Vincilaan 7 - D1 
fax: +32 2 7008622  |  B-1935 Zaventem - Belgium


From macro@ds2.pg.gda.pl Wed Jan 21 13:47:20 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 21 Jan 2004 13:47:21 +0000 (GMT)
Received: from jurand.ds.pg.gda.pl ([IPv6:::ffff:153.19.208.2]:8899 "EHLO
	jurand.ds.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8224915AbUAUNrU>; Wed, 21 Jan 2004 13:47:20 +0000
Received: by jurand.ds.pg.gda.pl (Postfix, from userid 1011)
	id 005D24C3D6; Wed, 21 Jan 2004 14:47:17 +0100 (CET)
Received: from localhost (localhost [127.0.0.1])
	by jurand.ds.pg.gda.pl (Postfix) with ESMTP
	id E300F47A62; Wed, 21 Jan 2004 14:47:17 +0100 (CET)
Date: Wed, 21 Jan 2004 14:47:17 +0100 (CET)
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To: Daniel Jacobowitz <dan@debian.org>
Cc: Ralf Baechle <ralf@linux-mips.org>,
	Pavel Kiryukhin <savl@dev.rtsoft.ru>, linux-mips@linux-mips.org
Subject: Re: __MIPSEL__ in sys32_rt_sigtimedwait
In-Reply-To: <20040120193918.GA2108@nevyn.them.org>
Message-ID: <Pine.LNX.4.55.0401211414040.11137@jurand.ds.pg.gda.pl>
References: <400D6877.1000105@dev.rtsoft.ru> <20040120183157.GB5495@linux-mips.org>
 <20040120193918.GA2108@nevyn.them.org>
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: 4077
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
Content-Length: 2022
Lines: 61

On Tue, 20 Jan 2004, Daniel Jacobowitz wrote:

> No, I'm pretty sure Pavel's right.
> 
> -#ifdef __MIPSEB__
>     case 1: these.sig[0] = these32.sig[0] | (((long)these32.sig[1]) << 32);
> -#endif
> -#ifdef __MIPSEL__
> -    case 1: these.sig[0] = these32.sig[1] | (((long)these32.sig[0]) << 32);
> -#endif
> 
> Consider a 64-bit sigset.  32-bit userland, 64-bit kernel.  Here's a
> userland sigset with signal 33 set, only, on a little endian target.
> Word 1, least significant bit, right?

 Right, but...

> byte address in memory
> 	1	2	3	4	5	6	7	8
> val	0	0	0	0	0	0	0	1

... this is incorrect -- it would be right for big-endian; word #1, bit #1
for little-endian is:

byte address in memory
	1	2	3	4	5	6	7	8
val	0	0	0	0	1	0	0	0


> Obviously, as a 64-bit integer the sigset looks different.  There it's
> supposed to be 1 << (33 - 1).
> val	0	0	0	1	0	0	0	0

 Again, for little-endian it should actually be:

val	0	0	0	0	1	0	0	0

i.e. the whole operation is actually a no-op, except that the 64-bit
vector is assured to be properly aligned for doubleword accesses.

 As a side note -- that's the reason certain C code portability problems
related to the width of the machine word only get actually discovered when
problematic software is run on a big-endian processor.  I've been hit by
this property once -- I was porting a 16-bit program and it appeared to
run just fine on both a 32-bit (i386) and a 64-bit (Alpha) little-endian
CPU, but when run on a 32-bit big-endian one (SPARC) I discovered a few
more bits to be cleaned up.

> So the correct algorithm to convert a userspace sigset to a kernel
> sigset is to shift the second word left 32 bits, and leave the first
> word right aligned, and or them together.  Which is what using the
> __MIPSEB__ case does.

 But this conclusion is of course right.

  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 Wed Jan 21 14:09:14 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 21 Jan 2004 14:09:15 +0000 (GMT)
Received: from jurand.ds.pg.gda.pl ([IPv6:::ffff:153.19.208.2]:8137 "EHLO
	jurand.ds.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8224915AbUAUOJO>; Wed, 21 Jan 2004 14:09:14 +0000
Received: by jurand.ds.pg.gda.pl (Postfix, from userid 1011)
	id 982644C3BC; Wed, 21 Jan 2004 15:09:12 +0100 (CET)
Received: from localhost (localhost [127.0.0.1])
	by jurand.ds.pg.gda.pl (Postfix) with ESMTP
	id 1CE904787B; Wed, 21 Jan 2004 15:09:12 +0100 (CET)
Date: Wed, 21 Jan 2004 15:09:12 +0100 (CET)
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To: Dimitri Torfs <dimitri@sonycom.com>
Cc: linux-mips@linux-mips.org
Subject: Re: Support for newer gcc/gas options
In-Reply-To: <20040120204026.GA9470@sonycom.com>
Message-ID: <Pine.LNX.4.55.0401211449170.11137@jurand.ds.pg.gda.pl>
References: <20031223114644.GA5458@sonycom.com>
 <Pine.LNX.4.55.0312231303030.27594@jurand.ds.pg.gda.pl>
 <Pine.LNX.4.55.0401201332080.12841@jurand.ds.pg.gda.pl> <20040120204026.GA9470@sonycom.com>
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: 4078
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
Content-Length: 1650
Lines: 36

On Tue, 20 Jan 2004, Dimitri Torfs wrote:

> >  It took a bit longer than I planned, sorry.  Anyway, here are two
> > functionally equivalent patches, for 2.4 and the head, that remove an ISA
> > specification if a tool supports "-march=" and "-mabi=" at the same time.  
> > Please try the appropriate one.
> 
> Tried the head one, it had some typos (patch follows). Unfortunately, as I wrote

 Oops, thanks for the correction -- as I still have only gcc 2.95.4, I
wasn't able to see the typos immediately.

> earlier, gcc-3.2 doesn't set the ISA correctly when using -march=, so
> it doesn't work for 3.2. 

 But do we care of the ISA?  I don't think so -- it's just a leftover from
the days the MIPS world was less complicated.  If gcc 3.2 correctly emits
code for the selected processor and obeys the selected ABI, then
everything is fine.  Are the binaries correct?  If so, I'd like to apply
the patch.

 The few remaining bits in <asm/asm.h> that still depend on _MIPS_ISA
should be rewritten to make use of appropriate CONFIG_CPU_HAS_* settings.  
Or perhaps we can just scrap them -- nothing uses them at all (and current
gcc is able to emit conditional move instructions itself).  OTOH, for
hand-coded assembly it might be a good idea to put them into gas as macros
-- similarly to what gas does for the Alpha for certain instructions that
are only available with later architecture revisions.  I'll work on it in
some spare time.

  Maciej

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

From dimitri@sonycom.com Wed Jan 21 14:51:57 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 21 Jan 2004 14:51:58 +0000 (GMT)
Received: from witte.sonytel.be ([IPv6:::ffff:80.88.33.193]:43214 "EHLO
	witte.sonytel.be") by linux-mips.org with ESMTP id <S8224915AbUAUOv5>;
	Wed, 21 Jan 2004 14:51:57 +0000
Received: from teasel.sonytel.be (localhost [127.0.0.1])
	by witte.sonytel.be (8.12.10/8.12.10) with ESMTP id i0LEpMw1010434;
	Wed, 21 Jan 2004 15:51:22 +0100 (MET)
Received: (from dimitri@localhost)
	by teasel.sonytel.be (8.9.3+Sun/8.9.3) id PAA14329;
	Wed, 21 Jan 2004 15:51:20 +0100 (MET)
Date: Wed, 21 Jan 2004 15:51:20 +0100
From: Dimitri Torfs <dimitri@sonycom.com>
To: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
Cc: linux-mips@linux-mips.org
Subject: Re: Support for newer gcc/gas options
Message-ID: <20040121145120.GA14288@sonycom.com>
References: <20031223114644.GA5458@sonycom.com> <Pine.LNX.4.55.0312231303030.27594@jurand.ds.pg.gda.pl> <Pine.LNX.4.55.0401201332080.12841@jurand.ds.pg.gda.pl> <20040120204026.GA9470@sonycom.com> <Pine.LNX.4.55.0401211449170.11137@jurand.ds.pg.gda.pl>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Pine.LNX.4.55.0401211449170.11137@jurand.ds.pg.gda.pl>
User-Agent: Mutt/1.4.1i
Return-Path: <dimitri@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: 4079
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: dimitri@sonycom.com
Precedence: bulk
X-list: linux-mips
Content-Length: 1393
Lines: 36

On Wed, Jan 21, 2004 at 03:09:12PM +0100, Maciej W. Rozycki wrote:
> On Tue, 20 Jan 2004, Dimitri Torfs wrote:
> 
> > >  It took a bit longer than I planned, sorry.  Anyway, here are two
> > > functionally equivalent patches, for 2.4 and the head, that remove an ISA
> > > specification if a tool supports "-march=" and "-mabi=" at the same time.  
> > > Please try the appropriate one.
> > 
> > Tried the head one, it had some typos (patch follows). Unfortunately, as I wrote
> 
>  Oops, thanks for the correction -- as I still have only gcc 2.95.4, I
> wasn't able to see the typos immediately.
> 
> > earlier, gcc-3.2 doesn't set the ISA correctly when using -march=, so
> > it doesn't work for 3.2. 
> 
>  But do we care of the ISA?  I don't think so -- it's just a leftover from
> the days the MIPS world was less complicated.  If gcc 3.2 correctly emits
> code for the selected processor and obeys the selected ABI, then
> everything is fine.  Are the binaries correct?  If so, I'd like to apply
> the patch.

I actually had problems compiling when the -mips3 was not set. The
compiler choked on compiling some empty file, if I remember correctly.
I will try again later to see what exactly went wrong.

Dimitri



-- 
Dimitri Torfs       |  NSCE 
dimitri@sonycom.com |  The Corporate Village
tel: +32 2 7008541  |  Da Vincilaan 7 - D1 
fax: +32 2 7008622  |  B-1935 Zaventem - Belgium


From drow@crack.them.org Wed Jan 21 15:22:53 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 21 Jan 2004 15:22:53 +0000 (GMT)
Received: from nevyn.them.org ([IPv6:::ffff:66.93.172.17]:9111 "EHLO
	nevyn.them.org") by linux-mips.org with ESMTP id <S8225320AbUAUPWx>;
	Wed, 21 Jan 2004 15:22:53 +0000
Received: from drow by nevyn.them.org with local (Exim 4.30 #1 (Debian))
	id 1AjKBr-0000Ll-BV; Wed, 21 Jan 2004 10:22:47 -0500
Date: Wed, 21 Jan 2004 10:22:47 -0500
From: Daniel Jacobowitz <dan@debian.org>
To: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
Cc: Ralf Baechle <ralf@linux-mips.org>,
	Pavel Kiryukhin <savl@dev.rtsoft.ru>, linux-mips@linux-mips.org
Subject: Re: __MIPSEL__ in sys32_rt_sigtimedwait
Message-ID: <20040121152247.GA1308@nevyn.them.org>
References: <400D6877.1000105@dev.rtsoft.ru> <20040120183157.GB5495@linux-mips.org> <20040120193918.GA2108@nevyn.them.org> <Pine.LNX.4.55.0401211414040.11137@jurand.ds.pg.gda.pl>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Pine.LNX.4.55.0401211414040.11137@jurand.ds.pg.gda.pl>
User-Agent: Mutt/1.5.1i
Return-Path: <drow@crack.them.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: 4080
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: dan@debian.org
Precedence: bulk
X-list: linux-mips
Content-Length: 2472
Lines: 71

On Wed, Jan 21, 2004 at 02:47:17PM +0100, Maciej W. Rozycki wrote:
> On Tue, 20 Jan 2004, Daniel Jacobowitz wrote:
> 
> > No, I'm pretty sure Pavel's right.
> > 
> > -#ifdef __MIPSEB__
> >     case 1: these.sig[0] = these32.sig[0] | (((long)these32.sig[1]) << 32);
> > -#endif
> > -#ifdef __MIPSEL__
> > -    case 1: these.sig[0] = these32.sig[1] | (((long)these32.sig[0]) << 32);
> > -#endif
> > 
> > Consider a 64-bit sigset.  32-bit userland, 64-bit kernel.  Here's a
> > userland sigset with signal 33 set, only, on a little endian target.
> > Word 1, least significant bit, right?
> 
>  Right, but...
> 
> > byte address in memory
> > 	1	2	3	4	5	6	7	8
> > val	0	0	0	0	0	0	0	1
> 
> ... this is incorrect -- it would be right for big-endian; word #1, bit #1
> for little-endian is:
> 
> byte address in memory
> 	1	2	3	4	5	6	7	8
> val	0	0	0	0	1	0	0	0
> 
> 
> > Obviously, as a 64-bit integer the sigset looks different.  There it's
> > supposed to be 1 << (33 - 1).
> > val	0	0	0	1	0	0	0	0
> 
>  Again, for little-endian it should actually be:
> 
> val	0	0	0	0	1	0	0	0
> 
> i.e. the whole operation is actually a no-op, except that the 64-bit
> vector is assured to be properly aligned for doubleword accesses.

Re-reading what I wrote, the above was actually supposed to be a
big-endian example.  D'oh!  If you pretend I wrote "big endian" up at
the top, then it makes sense.

>  As a side note -- that's the reason certain C code portability problems
> related to the width of the machine word only get actually discovered when
> problematic software is run on a big-endian processor.  I've been hit by
> this property once -- I was porting a 16-bit program and it appeared to
> run just fine on both a 32-bit (i386) and a 64-bit (Alpha) little-endian
> CPU, but when run on a 32-bit big-endian one (SPARC) I discovered a few
> more bits to be cleaned up.
> 
> > So the correct algorithm to convert a userspace sigset to a kernel
> > sigset is to shift the second word left 32 bits, and leave the first
> > word right aligned, and or them together.  Which is what using the
> > __MIPSEB__ case does.
> 
>  But this conclusion is of course right.
> 
>   Maciej
> 
> -- 
> +  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
> +--------------------------------------------------------------+
> +        e-mail: macro@ds2.pg.gda.pl, PGP key available        +
> 

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

From savl@dev.rtsoft.ru Wed Jan 21 16:20:39 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 21 Jan 2004 16:20:48 +0000 (GMT)
Received: from RT-soft-2.Moscow.itn.ru ([IPv6:::ffff:80.240.96.70]:17295 "HELO
	mail.dev.rtsoft.ru") by linux-mips.org with SMTP
	id <S8225333AbUAUQUj>; Wed, 21 Jan 2004 16:20:39 +0000
Received: (qmail 32552 invoked from network); 21 Jan 2004 15:59:47 -0000
Received: from unknown (HELO dev.rtsoft.ru) (192.168.1.132)
  by mail.dev.rtsoft.ru with SMTP; 21 Jan 2004 15:59:47 -0000
Message-ID: <400EA795.3030200@dev.rtsoft.ru>
Date: Wed, 21 Jan 2004 19:23:49 +0300
From: Pavel Kiryukhin <savl@dev.rtsoft.ru>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: linux-mips@linux-mips.org
CC: Pavel Kiryukhin <savl@dev.rtsoft.ru>
Subject: sys32_rt_sigtimedwait - new question
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Return-Path: <savl@dev.rtsoft.ru>
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: 4081
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: savl@dev.rtsoft.ru
Precedence: bulk
X-list: linux-mips
Content-Length: 816
Lines: 20

Hi,
concerning endiannes checking in sys32_rt_sigtimedwait:
just let me note that we have get_sigset and put_sigset that are used in 
sys32_rt_[sigaction,  sigprocmask, sigpending ...] in signal32.c.
Thise functions does not use endian check. Don't know if we can use 
get_sigset in sys32_rt_sigtimedwait.

But I have another question about sys32_rt_sigtimedwait:
We can see the comment about "brainfarting competition". Based on this 
comment only part of sigset is copied from user space to kernel. Why 
signals greater than 64 should not be handled?
If we look at sys32_rt_sigtimedwait in ppc64/kernel/signal32.c or 
sparc64/sys_sparc32.c we can see that full sigset (compat_sigset_t) is 
copied from user while in mips compat_old_sigset is copied. Why it is 
different in MIPS?
-------
Regards
Pavel Kiryukhin



From Wei.Liu@esstech.com Wed Jan 21 18:08:09 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 21 Jan 2004 18:08:09 +0000 (GMT)
Received: from [IPv6:::ffff:209.172.108.133] ([IPv6:::ffff:209.172.108.133]:63864
	"HELO [209.172.108.133]") by linux-mips.org with SMTP
	id <S8225348AbUAUSIJ>; Wed, 21 Jan 2004 18:08:09 +0000
Received: from essmail.esstech.com by [209.172.108.133]
          via smtpd (for mail.linux-mips.org [62.254.210.162]) with SMTP; Wed, 21 Jan 2004 10:08:08 -0800
Received: from wliupc ([172.18.13.106]) by ess2kmail.essnet.com with Microsoft SMTPSVC(5.0.2195.5329);
	 Wed, 21 Jan 2004 10:08:00 -0800
Message-ID: <000e01c3e04a$52f38a80$6a0d12ac@ess>
From: "wei liu" <wei.liu@esstech.com>
To: <linux-mips@linux-mips.org>
Subject: is there any cache problem with 4kc core?
Date: Wed, 21 Jan 2004 10:13:51 -0800
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_000B_01C3E007.44A717A0"
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
X-OriginalArrivalTime: 21 Jan 2004 18:08:00.0471 (UTC) FILETIME=[81665E70:01C3E049]
Return-Path: <Wei.Liu@esstech.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: 4082
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: wei.liu@esstech.com
Precedence: bulk
X-list: linux-mips
Content-Length: 1797
Lines: 52

This is a multi-part message in MIME format.

------=_NextPart_000_000B_01C3E007.44A717A0
Content-Type: text/plain;
	charset="gb2312"
Content-Transfer-Encoding: quoted-printable

I met a crash problem when trying linux2.4.18 on 4kc board. When the =
kernel starts thread to run function init, it will crash, showing =
Unhandled kernel unaligned access in =
unaligned.c:emulate_load_store_insn, line 3
51:
while it is ok for me to run linux2.4.3

Following is chip detail.
CPU revision is: 00018004
Primary instruction cache 8kb, linesize 16 bytes (2 ways)
Primary data cache 8kb, linesize 16 bytes (2 ways)
Linux version 2.4.18-MIPS-01.01 (gcc version 3.0)=20


------=_NextPart_000_000B_01C3E007.44A717A0
Content-Type: text/html;
	charset="gb2312"
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=3Dgb2312">
<META content=3D"MSHTML 6.00.2600.0" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT size=3D2>I met a crash problem when trying linux2.4.18 on 4kc =
board.=20
When the kernel starts thread to run function init, it will crash, =
showing=20
Unhandled kernel unaligned access in =
unaligned.c:emulate_load_store_insn, line=20
3<BR>51:</FONT></DIV>
<DIV><FONT size=3D2>while it is ok for me to run linux2.4.3</FONT></DIV>
<DIV><FONT size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT size=3D2>Following is chip detail.</FONT></DIV>
<DIV><FONT size=3D2>CPU revision is: 00018004<BR>Primary instruction =
cache 8kb,=20
linesize 16 bytes (2 ways)<BR>Primary data cache 8kb, linesize 16 bytes =
(2=20
ways)<BR>Linux version 2.4.18-MIPS-01.01 (gcc version 3.0)=20
<BR></DIV></FONT></BODY></HTML>

------=_NextPart_000_000B_01C3E007.44A717A0--


From dimitri@sonycom.com Wed Jan 21 18:35:56 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 21 Jan 2004 18:35:56 +0000 (GMT)
Received: from witte.sonytel.be ([IPv6:::ffff:80.88.33.193]:59523 "EHLO
	witte.sonytel.be") by linux-mips.org with ESMTP id <S8224987AbUAUSf4>;
	Wed, 21 Jan 2004 18:35:56 +0000
Received: from teasel.sonytel.be (localhost [127.0.0.1])
	by witte.sonytel.be (8.12.10/8.12.10) with ESMTP id i0LIZrw1007880;
	Wed, 21 Jan 2004 19:35:53 +0100 (MET)
Received: (from dimitri@localhost)
	by teasel.sonytel.be (8.9.3+Sun/8.9.3) id TAA21510;
	Wed, 21 Jan 2004 19:35:51 +0100 (MET)
Date: Wed, 21 Jan 2004 19:35:51 +0100
From: Dimitri Torfs <dimitri@sonycom.com>
To: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
Cc: linux-mips@linux-mips.org
Subject: Re: Support for newer gcc/gas options
Message-ID: <20040121183551.GA21411@sonycom.com>
References: <20031223114644.GA5458@sonycom.com> <Pine.LNX.4.55.0312231303030.27594@jurand.ds.pg.gda.pl> <Pine.LNX.4.55.0401201332080.12841@jurand.ds.pg.gda.pl> <20040120204026.GA9470@sonycom.com> <Pine.LNX.4.55.0401211449170.11137@jurand.ds.pg.gda.pl> <20040121145120.GA14288@sonycom.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20040121145120.GA14288@sonycom.com>
User-Agent: Mutt/1.4.1i
Return-Path: <dimitri@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: 4083
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: dimitri@sonycom.com
Precedence: bulk
X-list: linux-mips
Content-Length: 1478
Lines: 36

On Wed, Jan 21, 2004 at 03:51:20PM +0100, Dimitri Torfs wrote:
> On Wed, Jan 21, 2004 at 03:09:12PM +0100, Maciej W. Rozycki wrote:
> >  But do we care of the ISA?  I don't think so -- it's just a leftover from
> > the days the MIPS world was less complicated.  If gcc 3.2 correctly emits
> > code for the selected processor and obeys the selected ABI, then
> > everything is fine.  Are the binaries correct?  If so, I'd like to apply
> > the patch.
> 
> I actually had problems compiling when the -mips3 was not set. The
> compiler choked on compiling some empty file, if I remember correctly.
> I will try again later to see what exactly went wrong.

Compiler choked on the first file it tries to compile: gcc added
-mips1 automatically to the as command line which conflicts with the
-Wa,--trap option:

/usr/local/lib/gcc-lib/mips-linux/3.2.2/../../../../mips-linux/bin/as
 -G 0 -O2 -g0 -32 -march=r4100 -v -mips1 -non_shared -32 -march=r4100
 --trap -o scripts/.tmp_empty.o -
Assembler messages:
Error: trap exception not supported at ISA 1

Removing the line which unsets the gas_isa option makes it work again:
/usr/local/lib/gcc-lib/mips-linux/3.2.2/../../../../mips-linux/bin/as
-G 0 -O2 -g0 -32 -march=r4100 -v -mips1 -non_shared -32 -march=r4100
-mips3 --trap -o scripts/.tmp_empty.o

Dimitri


-- 
Dimitri Torfs       |  NSCE 
dimitri@sonycom.com |  The Corporate Village
tel: +32 2 7008541  |  Da Vincilaan 7 - D1 
fax: +32 2 7008622  |  B-1935 Zaventem - Belgium


From rpalani2@yahoo.com Wed Jan 21 19:16:29 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 21 Jan 2004 19:16:30 +0000 (GMT)
Received: from web21601.mail.yahoo.com ([IPv6:::ffff:66.163.169.176]:52659
	"HELO web21601.mail.yahoo.com") by linux-mips.org with SMTP
	id <S8224987AbUAUTQ3>; Wed, 21 Jan 2004 19:16:29 +0000
Message-ID: <20040121191627.27460.qmail@web21601.mail.yahoo.com>
Received: from [206.31.31.3] by web21601.mail.yahoo.com via HTTP; Wed, 21 Jan 2004 11:16:27 PST
Date: Wed, 21 Jan 2004 11:16:27 -0800 (PST)
From: Rajesh Palani <rpalani2@yahoo.com>
Subject: Re: MIPS PR3940
To: Ralf Baechle <ralf@linux-mips.org>, kip.r2@free.fr
Cc: linux-mips@linux-mips.org
In-Reply-To: <20040120135944.GA25099@linux-mips.org>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="0-1356285352-1074712587=:27386"
Return-Path: <rpalani2@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: 4084
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: rpalani2@yahoo.com
Precedence: bulk
X-list: linux-mips
Content-Length: 1902
Lines: 35

--0-1356285352-1074712587=:27386
Content-Type: text/plain; charset=us-ascii

I had worked on porting Linux on this processor a while ago.  I am not sure if the port is available outside of Philips.
 
-Rajesh

Ralf Baechle <ralf@linux-mips.org> wrote:
On Tue, Jan 20, 2004 at 02:10:31PM +0100, kip.r2@free.fr wrote:

> Hi all,
> I was wondering if anybody has already work with this processor. I'm expected 
> to make real-time applications on that platform. Do you think it is possible?

Forgive I'm too lazy to download documents but in case it's not working
yet it won't be hard to get Linux to work.

Realtime - depend what exactly you need.

Ralf


---------------------------------
Do you Yahoo!?
Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes
--0-1356285352-1074712587=:27386
Content-Type: text/html; charset=us-ascii

<DIV>I had worked on porting Linux on this processor a while ago.&nbsp; I am not sure if the port is available outside of Philips.</DIV>
<DIV>&nbsp;</DIV>
<DIV>-Rajesh<BR><BR><B><I>Ralf Baechle &lt;ralf@linux-mips.org&gt;</I></B> wrote:</DIV>
<BLOCKQUOTE class=replbq style="BORDER-LEFT: #1010ff 2px solid; MARGIN-LEFT: 5px; PADDING-LEFT: 5px">On Tue, Jan 20, 2004 at 02:10:31PM +0100, kip.r2@free.fr wrote:<BR><BR>&gt; Hi all,<BR>&gt; I was wondering if anybody has already work with this processor. I'm expected <BR>&gt; to make real-time applications on that platform. Do you think it is possible?<BR><BR>Forgive I'm too lazy to download documents but in case it's not working<BR>yet it won't be hard to get Linux to work.<BR><BR>Realtime - depend what exactly you need.<BR><BR>Ralf<BR></BLOCKQUOTE><p><hr SIZE=1>
Do you Yahoo!?<br>
Yahoo! Hotjobs: <a href="http://pa.yahoo.com/*http://us.rd.yahoo.com/hotjobs/mail_footer_email/evt=21482/*http://hotjobs.sweepstakes.yahoo.com/signingbonus">Enter the "Signing Bonus" Sweepstakes</a>
--0-1356285352-1074712587=:27386--

From ddaney@avtrex.com Wed Jan 21 20:08:57 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 21 Jan 2004 20:08:58 +0000 (GMT)
Received: from avtrex.com ([IPv6:::ffff:216.102.217.178]:26083 "EHLO
	avtrex.com") by linux-mips.org with ESMTP id <S8224987AbUAUUI5>;
	Wed, 21 Jan 2004 20:08:57 +0000
Received: from avtrex.com ([192.168.0.111] RDNS failed) by avtrex.com with Microsoft SMTPSVC(5.0.2195.6713);
	 Wed, 21 Jan 2004 12:08:53 -0800
Message-ID: <400EDC24.3080309@avtrex.com>
Date: Wed, 21 Jan 2004 12:08:04 -0800
From: David Daney <ddaney@avtrex.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.1) Gecko/20031030
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Ralf Baechle <ralf@linux-mips.org>
CC: Andrew Haley <aph@redhat.com>, Andreas Tobler <toa@pop.agri.ch>,
	Geoffrey Keating <geoffk@apple.com>,
	gcc-patches <gcc-patches@gcc.gnu.org>,
	Andrew Pinski <pinskia@physics.uc.edu>,
	Eric Christopher <echristo@redhat.com>,
	Richard Henderson <rth@redhat.com>, linux-mips@linux-mips.org
Subject: Re: [RFC]: MD_FALLBACK_FRAME_STATE_FOR macro for darwin PPC
References: <400D9173.7010508@pop.agri.ch>	<7809AEC4-4B8A-11D8-83EB-000A95B1F520@apple.com>	<400E3C5C.3060001@pop.agri.ch>	<400EC5B4.6020402@avtrex.com>	<400ED0D9.20704@pop.agri.ch>	<400ED4DE.6080601@avtrex.com> <16398.55568.933882.591110@cuddles.cambridge.redhat.com>
In-Reply-To: <16398.55568.933882.591110@cuddles.cambridge.redhat.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 21 Jan 2004 20:08:53.0074 (UTC) FILETIME=[6449C320:01C3E05A]
Return-Path: <ddaney@avtrex.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: 4085
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: ddaney@avtrex.com
Precedence: bulk
X-list: linux-mips
Content-Length: 1926
Lines: 68

Andrew Haley wrote:

>David Daney writes:
> > Andreas Tobler wrote:
> > 
> > > David Daney wrote:
> > >
> > >
> > >> I know next to nothing about PPC ABIs, but are any of these floating 
> > >> point registers?
> > >
> > >
> > > There are, yes.
> > >
> > >> Are there any call saved FP registers in this ABI? and if so are you 
> > >> restoring them.  Although I don't think that the unwinder uses 
> > >> floating point, it seems that restoring call saved FP registers is a 
> > >> good idea if you are not already doing it.
> > >
> > >
> > > Well, here I expect the advise from the experts, I have floats around 
> > > and I may try to restore them.
> > >
> > > But, I need some guidance here.
> > 
> > When I did the MD_FALLBACK_FRAME_STATE_FOR for mips/linux I did not 
> > handle floating point either as the problem did not occur to me until 
> > after I checked in the code.
> > 
> > However after thinking about it and posting:
> > 
> > http://gcc.gnu.org/ml/gcc/2003-10/msg00972.html
> > 
> > I learned that this is a real issue.
> > 
> > I may be about ready to do some more mips/linux work soon and may 
> > revisit MD_FALLBACK_FRAME_STATE_FOR.  Because in its current state it 
> > seems to be incomplete.
>
>You only need to restore what has been saved.  Looking at
>/usr/src/linux-2.4/arch/mips/kernel/signal.c, it seems that there is a
>call to save_fp_context().  However, this is only executed if
>(current->used_math) is set; you mustn't restore any fp registers if
>the process hasn't saved the fp state.
>
>There is a field called sc_used_math in the sigcontext struct.  I
>think this tells you what you need to know.  But I am not a kernel
>hacker...
>
>Andrew.
>  
>
Ralf,

Is this all true?

Perhaps you could shed some light on what really needs to be done in the 
MIPS/linux case.

Also what should be done in the case of mips 4Kc core where there is 
only software floating point?

David Daney.






From nlarson@Crossroads.com Wed Jan 21 21:58:31 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 21 Jan 2004 21:58:31 +0000 (GMT)
Received: from email.crossroads.com ([IPv6:::ffff:65.68.235.6]:26756 "HELO
	email.crossroads.com") by linux-mips.org with SMTP
	id <S8225506AbUAUV6b> convert rfc822-to-8bit; Wed, 21 Jan 2004 21:58:31 +0000
Received: from HQMAILNODE1.COMMSTOR.Crossroads.com ([10.5.1.42]) by email.crossroads.com with Microsoft SMTPSVC(5.0.2195.6713);
	 Wed, 21 Jan 2004 15:58:24 -0600
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 8BIT
Subject: How to add more memory?
Date: Wed, 21 Jan 2004 15:58:24 -0600
Message-ID: <CFD808D1D39ACB47ABFF586D484CC52EADE212@hqmailnode1.commstor.crossroads.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: How to add more memory?
Thread-Index: AcPgagduokXno7WkRMilFLIIHpgaow==
From: "Nils Larson" <nlarson@Crossroads.com>
To: <linux-mips@linux-mips.org>
X-OriginalArrivalTime: 21 Jan 2004 21:58:25.0161 (UTC) FILETIME=[B18EA790:01C3E069]
Return-Path: <nlarson@Crossroads.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: 4086
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: nlarson@Crossroads.com
Precedence: bulk
X-list: linux-mips
Content-Length: 605
Lines: 17

Hi,
We currently have a mips platform running Linux with 256MB of
RAM starting at 0x8000_0000. We would like to add an additional
1GB of RAM, maybe starting at 0x4000_0000, that would be used
for user apps (user virtual memory). The memory map is:
0x8000_0000 - 256MB RAM
0xA000_0000 - uncached version of the same 256MB
0xB000_0000 - PCI memory windows.
This is a diskless setup booting from a ramdisk.
So, the (sort of newbie) questions are:
1. How do we tell Linux to use the new memory?
2. Is this feasible?
3. Is there a better way to add more memory?
We need more space for user data.
Thanks,
Nils


From pypark@nayna.com Wed Jan 21 22:21:15 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 21 Jan 2004 22:21:16 +0000 (GMT)
Received: from ip66-106-155-114.z155-106-66.customer.algx.net ([IPv6:::ffff:66.106.155.114]:52757
	"EHLO atomant.nayna.com") by linux-mips.org with ESMTP
	id <S8224987AbUAUWVP>; Wed, 21 Jan 2004 22:21:15 +0000
Received: by atomant.nayna.com with Internet Mail Service (5.5.2653.19)
	id <R91WCYYZ>; Wed, 21 Jan 2004 14:19:05 -0800
Message-ID: <DFDD2BC6A4D8D711B8980090279CF95B017708@atomant.nayna.com>
From: "Young Chul Park (Patrick)" <pypark@nayna.com>
To: "'linux-mips@linux-mips.org'" <linux-mips@linux-mips.org>,
	"'linux-mips@ftp.linux-mips.org'" <linux-mips@ftp.linux-mips.org>
Subject: Linux 2.4.18 MIPS (5KC) Crash after rc.sysinit
Date: Wed, 21 Jan 2004 14:19:05 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Return-Path: <pypark@nayna.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: 4087
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: pypark@nayna.com
Precedence: bulk
X-list: linux-mips
Content-Length: 7808
Lines: 193

Hi,

My name is Patrick and I facing an issue with Linux kernel
2.4.18 on a MIPS board (5KC CPU).

We have built a Linux 2.4.18 kernel using the sources downloaded
from mips.com. I am using NFS Root and is successfuly mounted 
(see below). We are also using "busybox" in place of "init".
The "init" is being invoked which in turn reads the inittab file
and executes the rc.sysinit script via "execl".

At this point we encounter a kernel panic and it crashes. Our
debugging has shown that at some stage during the execl() system
call the "current->files" pointer is corrupted. 

The root file system looks okay and this behavior happens by
execing any command from init. We have turned on some tracing
in the kernel to show the corrupted memory location..

Does anybody have any idea on what this might be ?  I looked for
any relevent patches but could not see any. 

Thanks in advance.

Regards
Patrick

PS - We tried gcc version 2.91.66  and 3.2.2 also. but with same result.

=====================================================================
MIPSBoot-> go a0400000
## Starting application at 0xa0400000 ...
 PRID_IMP_5KC
32MB SDRAM auto-detected (High Decode Address 0x1f)
platformRevision = 2 (Firehawk DB-88E6318 Rev 3.0)
CPU revision is: 0101810a
FPU revision is: 0003810a
Primary instruction cache 16kb, linesize 32 bytes (4 ways)
Primary data cache 8kb, linesize 32 bytes (2 ways)
Linux version 2.4.18-MIPS-01.01 (root@mips-build) (gcc version egcs-2.91.66
1999
0314 (egcs-1.1.2 release)) #69 Mon Jan 19 20:30:06 EST 2004
Determined physical RAM map:
 memory: 01dfffff @ 00000000 (usable)
On node 0 totalpages: 7679
zone(0): 7679 pages.
zone(1): 0 pages.
zone(2): 0 pages.
Kernel command line: console=ttyS1,38400 noinitrd root=/dev/nfs
nfsroot=172.16.1
.210:/home/mips/rootfs
ip=172.16.200.200:172.16.1.210:172.16.0.1:255.255.0.0:rgp
:eth0:
Calibrating delay loop... 255.59 BogoMIPS
calibrating MIPS CPU counter frequency ... 128012730 Hz
Memory: 28468k/30716k available (1397k kernel code, 2248k reserved, 152k
data, 7
6k init, 0k highmem)
Dentry-cache hash table entries: 4096 (order: 3, 32768 bytes)
Inode-cache hash table entries: 2048 (order: 2, 16384 bytes)
Mount-cache hash table entries: 512 (order: 0, 4096 bytes)
Buffer-cache hash table entries: 1024 (order: 0, 4096 bytes)
Page-cache hash table entries: 8192 (order: 3, 32768 bytes)
Checking for 'wait' instruction...  unavailable.
POSIX conformance testing by UNIFIX
Autoconfig PCI channel 0x80199ac8
Scanning bus 00, I/O 0x15000000:0x16000001, Mem 0x16000000:0x18000001
00:08.0 Class 0200: 8086:1229 (rev 08)
        Mem at 0x16000000 [size=0x1000]
        I/O at 0x15000000 [size=0x40]
        Mem at 0x16100000 [size=0x100000]
pcibios_fixup_irqs: slot=8
Linux NET4.0 for Linux 2.4
Based upon Swansea University Computer Society NET3.039
Initializing RT netlink socket
Starting kswapd
LMNpty: 256 Unix98 ptys configured
Serial driver version 5.05c (2001-07-08) with MANY_PORTS SHARE_IRQ
SERIAL_PCI en
abled
ttyS00 at 0xb400c840x (irq = 23) is a 16550A
ttyS01 at 0xb400c8c0x (irq = 24) is a 16550A
rtc: I/O port 112 is not free.
block: 64 slots per queue, batch=16
RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize
loop: loaded (max 8 devices)
eepro100.c:v1.09j-t 9/29/99 Donald Becker
http://www.scyld.com/network/eepro100.
html
eepro100.c: $Revision: 1.1.1.1 $ 2000/11/17 Modified by Andrey V. Savochkin
<saw
@saw.sw.com.sg> and others
eth0: PCI device 8086:1229, 00:D0:B7:1C:BA:37, IRQ 48.
  Board assembly 721383-008, Physical connectors present: RJ45
  Primary interface chip i82555 PHY #1.
  General self-test: passed.
  Serial sub-system self-test: passed.
  Internal registers self-test: passed.
  ROM checksum self-test: passed (0x04f4518b).
boot_remap register = 0x1fc00000
Probing MTD devices at address 0x1e000000 (0x1000000 in size)
Creating 2 MTD partitions on "MV-88E6318 flash":
0x00000000-0x00200000 : "MV-88E6318 kernel partition"
0x00200000-0x01000000 : "MV-88E6318 file-system partition"
NET4: Linux TCP/IP 1.0 for NET4.0
IP Protocols: ICMP, UDP, TCP
IP: routing cache hash table of 512 buckets, 4Kbytes
TCP: Hash tables configured (established 2048 bind 2048)
IP-Config: Complete:
      device=eth0, addr=172.16.200.200, mask=255.255.0.0, gw=172.16.0.1,
     host=rgp, domain=, nis-domain=(none),
     bootserver=172.16.1.210, rootserver=172.16.1.210, rootpath=
NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
Root-NFS: Mounting /home/mips/rootfs on server 172.16.1.210 as root
Root-NFS:     rsize = 4096, wsize = 4096, timeo = 7, retrans = 3
Root-NFS:     acreg (min,max) = (3,60), acdir (min,max) = (30,60)
Root-NFS:     nfsd port = -1, mountd port = 0, flags = 00000200
Root-NFS: IPPROTO = UDP <5>Looking up port of RPC 100003/2 on 172.16.1.210
Root-NFS: Portmapper on server returned 2049 as nfsd port
Looking up port of RPC 100005/1 on 172.16.1.210
Root-NFS: mountd port is 32855
NFS:      nfs_mount(ac1001d2:/home/mips/rootfs)
VFS: Mounted root (nfs filesystem).
Freeing unused kernel memory: 76k freed
serial console detected.  Disabling virtual terminals.
init started:  BusyBox v0.60.3 (2002.12.19-11:07+0000) multi-call binary

Kernel unaligned instruction access in unaligned.c:do_ade, line 407:
$0 : 00000000 30001000 00000001 00000001 80133ea8 00000001 00000001 00000001
$8 : 8019ad80 00001000 80172000 00000003 00000000 00000000 8019a98e 00000000
$16: 2aac00f4 80172000 00000001 1000001f ffffffe8 00000000 00000000 7fff7278
$24: 00000000 2aabd430                   810a4000 810a5ed0 00403784 80034470
Hi : 00000000
Lo : 00000000
epc  : 80034468    Not tainted
Status: 30001003
Cause : 80808010
Process EUR (pid: 10, stackpage=810a4000)
Stack: 80133ea4 00000001 00000001 00000001 2aac00f4 80172000 00000001
00000000
       80172000 2ab01b78 00000000 7fff7278 80034758 8003477c 80133f2c
00000001
       00000001 00000001 ffffffff ffffffff 00000001 2ab01788 00403784
800068e8
       7fff7b78 7fff7778 7fff7d78 00000000 ffffffff 00000000 00000000
2ab01790
       00000fa5 00000002 2aac00f4 00000000 00000001 00000000 81010100
00000001
       00000000 ...
Call Trace:
Code: 0000a821  3c048013  24843ea8 <0c003fa4> 8e65001c  3c048013  24843eb4
0c00
3fa4  8e65000c
Unable to handle kernel paging request at virtual address 2ab01b80, epc ==
8008e
db0, ra == 8001381c
Oops in fault.c:do_page_fault, line 205:
$0 : 00000000 80180000 00000001 00000002 00000019 00000000 00000200 81d8e000
$8 : 81079d50 30001001 810a5c90 00000000 00000000 00000000 8019a989 fffffffe
$16: 801621c0 2ab01b78 810a4264 ffffffff 80131040 0000000b 00000000 7fff7278
$24: ffffffff 810a5c47                   810a4000 810a5d70 00403784 8001381c
Hi : 00000000
Lo : 00000020
epc  : 8008edb0    Not tainted
Status: 30001003
Cause : 00808008
Process EUR (pid: 10, stackpage=810a4000)
Stack: 8000dee4 810a5d98 00403784 80004a60 801621c0 00000197 810a4000
801310f8
       8001381c 00809000 ffffffe8 00000000 00000000 7fff7278 8012e9e8
00000197
       810a5e20 1000001f ffffffe8 00000000 80004a60 80004a44 8012da60
00000001
       00000001 00000020 2aac00f4 810a5e20 00000001 80004a80 00000005
810a5e10
       8018ac88 00001bcf 80006ea4 8019ad80 00001bd0 0000003e 0000003c
00000001
       2aac00f4 ...
Call Trace:
Code: 8e510000  12200054  2413ffff <8e250008> 10b3004a  00a03021  04a10002
00a0
1021  24a27fff
Unable to handle kernel paging request at virtual address 2ab01b80, epc ==
8008e
db0, ra == 8001381c
Oops in fault.c:do_page_fault, line 205:
$0 : 00000000 30001000 00000001 00000000 00000000 30001001 00000000 0000249e
$8 : ffffffff 0000000a 810a5aaa 00000000 00000000 00000000 8019a989 fffffffe
$16: 00000000 2ab01b78 810a4264 ffffffff 80131040 0000000b 00000000 7fff7278
$24: ffffffff 810a5a67                   810a4000 810a5b90 0

=====================================================================


From jsun@mvista.com Wed Jan 21 22:27:01 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 21 Jan 2004 22:27:10 +0000 (GMT)
Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:16894 "EHLO
	orion.mvista.com") by linux-mips.org with ESMTP id <S8224987AbUAUW1B>;
	Wed, 21 Jan 2004 22:27:01 +0000
Received: (from jsun@localhost)
	by orion.mvista.com (8.11.6/8.11.6) id i0LMQvl30699;
	Wed, 21 Jan 2004 14:26:57 -0800
Date: Wed, 21 Jan 2004 14:26:57 -0800
From: Jun Sun <jsun@mvista.com>
To: David Daney <ddaney@avtrex.com>
Cc: Ralf Baechle <ralf@linux-mips.org>, Andrew Haley <aph@redhat.com>,
	Andreas Tobler <toa@pop.agri.ch>,
	Geoffrey Keating <geoffk@apple.com>,
	gcc-patches <gcc-patches@gcc.gnu.org>,
	Andrew Pinski <pinskia@physics.uc.edu>,
	Eric Christopher <echristo@redhat.com>,
	Richard Henderson <rth@redhat.com>, linux-mips@linux-mips.org,
	jsun@mvista.com
Subject: Re: [RFC]: MD_FALLBACK_FRAME_STATE_FOR macro for darwin PPC
Message-ID: <20040121142657.B29705@mvista.com>
References: <400D9173.7010508@pop.agri.ch> <7809AEC4-4B8A-11D8-83EB-000A95B1F520@apple.com> <400E3C5C.3060001@pop.agri.ch> <400EC5B4.6020402@avtrex.com> <400ED0D9.20704@pop.agri.ch> <400ED4DE.6080601@avtrex.com> <16398.55568.933882.591110@cuddles.cambridge.redhat.com> <400EDC24.3080309@avtrex.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <400EDC24.3080309@avtrex.com>; from ddaney@avtrex.com on Wed, Jan 21, 2004 at 12:08:04PM -0800
Return-Path: <jsun@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: 4088
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
Content-Length: 3308
Lines: 93

On Wed, Jan 21, 2004 at 12:08:04PM -0800, David Daney wrote:
> Andrew Haley wrote:
> 
> >David Daney writes:
> > > Andreas Tobler wrote:
> > > 
> > > > David Daney wrote:
> > > >
> > > >
> > > >> I know next to nothing about PPC ABIs, but are any of these floating 
> > > >> point registers?
> > > >
> > > >
> > > > There are, yes.
> > > >
> > > >> Are there any call saved FP registers in this ABI? and if so are you 
> > > >> restoring them.  Although I don't think that the unwinder uses 
> > > >> floating point, it seems that restoring call saved FP registers is a 
> > > >> good idea if you are not already doing it.
> > > >
> > > >
> > > > Well, here I expect the advise from the experts, I have floats around 
> > > > and I may try to restore them.
> > > >
> > > > But, I need some guidance here.
> > > 
> > > When I did the MD_FALLBACK_FRAME_STATE_FOR for mips/linux I did not 
> > > handle floating point either as the problem did not occur to me until 
> > > after I checked in the code.
> > > 
> > > However after thinking about it and posting:
> > > 
> > > http://gcc.gnu.org/ml/gcc/2003-10/msg00972.html
> > > 
> > > I learned that this is a real issue.
> > > 
> > > I may be about ready to do some more mips/linux work soon and may 
> > > revisit MD_FALLBACK_FRAME_STATE_FOR.  Because in its current state it 
> > > seems to be incomplete.
> >
> >You only need to restore what has been saved.  Looking at
> >/usr/src/linux-2.4/arch/mips/kernel/signal.c, it seems that there is a
> >call to save_fp_context().  However, this is only executed if
> >(current->used_math) is set; you mustn't restore any fp registers if
> >the process hasn't saved the fp state.
> >
> >There is a field called sc_used_math in the sigcontext struct.  I
> >think this tells you what you need to know.  But I am not a kernel
> >hacker...
> >
> >Andrew.
> >  
> >
> Ralf,
> 
> Is this all true?
> 
> Perhaps you could shed some light on what really needs to be done in the 
> MIPS/linux case.
> 
> Also what should be done in the case of mips 4Kc core where there is 
> only software floating point?
> 

I wrote those code.  Here are some bits which might be helpful.

. If a CPU does not a hw FPU, a software emulator is used.  A bunch of 
  functions defined in asm-mips/fpu.h attempts to abstract away the difference
  between a CPU with hw fpu or not.

. Regarding FPU status, a process in one of the three states (when not in 
  signal handling context)
	a. have not used FPU yet (current->used_math == 0)
	b. have used FPU but not the current hw FPU owner 
	c. have use FPU and is the current hw FPU owner

  (in the case of emulated FPU case, there is no FPU ownder at any time)

. When setting a signal frame, we treat those three cases differently:

	for case a), do nothing (no saving or what so ever)
	for case b), current replaces current FPU owner (which implies
 		possible FPU saving of current owner and restoring FPU
		registers from current thread structure to FPU hw)
		And then we save FPU registers into signal context.
	for case c), we save FPU registers into signal context.

. When returning from signal handling, 
	for case a), we forciably loose CPU (even if sig handler has used it)
	for case b) and c) we become the FPU owner (i.e., restoring FPU
		registers from signal context area)

Jun

From jsun@mvista.com Wed Jan 21 22:38:00 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 21 Jan 2004 22:38:00 +0000 (GMT)
Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:58610 "EHLO
	orion.mvista.com") by linux-mips.org with ESMTP id <S8225571AbUAUWiA>;
	Wed, 21 Jan 2004 22:38:00 +0000
Received: (from jsun@localhost)
	by orion.mvista.com (8.11.6/8.11.6) id i0LMbr430733;
	Wed, 21 Jan 2004 14:37:53 -0800
Date: Wed, 21 Jan 2004 14:37:53 -0800
From: Jun Sun <jsun@mvista.com>
To: Nils Larson <nlarson@Crossroads.com>
Cc: linux-mips@linux-mips.org, jsun@mvista.com
Subject: Re: How to add more memory?
Message-ID: <20040121143753.C29705@mvista.com>
References: <CFD808D1D39ACB47ABFF586D484CC52EADE212@hqmailnode1.commstor.crossroads.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <CFD808D1D39ACB47ABFF586D484CC52EADE212@hqmailnode1.commstor.crossroads.com>; from nlarson@Crossroads.com on Wed, Jan 21, 2004 at 03:58:24PM -0600
Return-Path: <jsun@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: 4089
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
Content-Length: 1045
Lines: 30

On Wed, Jan 21, 2004 at 03:58:24PM -0600, Nils Larson wrote:
> Hi,
> We currently have a mips platform running Linux with 256MB of
> RAM starting at 0x8000_0000. We would like to add an additional
> 1GB of RAM, maybe starting at 0x4000_0000, that would be used
> for user apps (user virtual memory). The memory map is:
> 0x8000_0000 - 256MB RAM
> 0xA000_0000 - uncached version of the same 256MB
> 0xB000_0000 - PCI memory windows.
> This is a diskless setup booting from a ramdisk.
> So, the (sort of newbie) questions are:
> 1. How do we tell Linux to use the new memory?
> 2. Is this feasible?
> 3. Is there a better way to add more memory?
> We need more space for user data.
> Thanks,
> Nils
> 

People have done this before in 2.4 with CONFIG_HIGHMEM.  
See arch/mips/sibyte/cfe/setup.c for more details.

However, if the CPU suffers from virtual aliasing problem, I
think this won't work at all.

I think that is pretty much only way to get more RAM 
in 32bit system.  With 64bit kernel of course you don't have
any problems at all.

Jun

From jsun@mvista.com Thu Jan 22 00:20:34 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 22 Jan 2004 00:20:34 +0000 (GMT)
Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:16373 "EHLO
	orion.mvista.com") by linux-mips.org with ESMTP id <S8225571AbUAVAUd>;
	Thu, 22 Jan 2004 00:20:33 +0000
Received: (from jsun@localhost)
	by orion.mvista.com (8.11.6/8.11.6) id i0M0KWQ01655;
	Wed, 21 Jan 2004 16:20:32 -0800
Date: Wed, 21 Jan 2004 16:20:32 -0800
From: Jun Sun <jsun@mvista.com>
To: linux-mips@linux-mips.org
Cc: jsun@mvista.com
Subject: [PATCH 2.6] set up conswitchp when CONFIG_VT is set
Message-ID: <20040121162032.F29705@mvista.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="V0207lvV8h4k8FAm"
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
Return-Path: <jsun@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: 4090
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
Content-Length: 2800
Lines: 97


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


conswitchp needs to be set whenever CONFIG_VT is selected.
Currently this job is done individually by each board in its setup
routine, often in a wrong way.

The right thing to do is to set the pointer in the common code
and remove almost two dozens of duplicated and often wrong settings.

The attached patch is for illustration only.  The removal of board settings
is not complete.

Comments?  Objections and cheers are equally welcome. :)

Jun

--V0207lvV8h4k8FAm
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="dummy_console.patch"

diff -Nru linux/arch/mips/ddb5xxx/ddb5074/setup.c.orig linux/arch/mips/ddb5xxx/ddb5074/setup.c
--- linux/arch/mips/ddb5xxx/ddb5074/setup.c.orig	Mon Jan  5 10:33:34 2004
+++ linux/arch/mips/ddb5xxx/ddb5074/setup.c	Wed Jan 21 16:03:33 2004
@@ -10,7 +10,6 @@
 #include <linux/kernel.h>
 #include <linux/kdev_t.h>
 #include <linux/types.h>
-#include <linux/console.h>
 #include <linux/sched.h>
 #include <linux/pci.h>
 #include <linux/ide.h>
@@ -113,10 +112,6 @@
 	ddb_set_pmr(DDB_PCIINIT0, DDB_PCICMD_IO, 0, 0x10);
 	ddb_set_pmr(DDB_PCIINIT1, DDB_PCICMD_MEM, DDB_PCI_MEM_BASE , 0x10);
 
-#ifdef CONFIG_FB
-	conswitchp = &dummy_con;
-#endif
-
 	/* Reboot on panic */
 	panic_timeout = 180;
 }
diff -Nru linux/arch/mips/ddb5xxx/ddb5476/setup.c.orig linux/arch/mips/ddb5xxx/ddb5476/setup.c
--- linux/arch/mips/ddb5xxx/ddb5476/setup.c.orig	Mon Jan  5 10:33:34 2004
+++ linux/arch/mips/ddb5xxx/ddb5476/setup.c	Wed Jan 21 16:03:50 2004
@@ -10,7 +10,6 @@
 #include <linux/kernel.h>
 #include <linux/kdev_t.h>
 #include <linux/types.h>
-#include <linux/console.h>
 #include <linux/sched.h>
 #include <linux/pci.h>
 
@@ -166,10 +165,6 @@
 	/* [jsun] we need to set BAR0 so that SDRAM 0 appears at 0x0 in PCI */
 	/* *(long*)0xbfa00218 = 0x8; */
 
-#ifdef CONFIG_FB
-	conswitchp = &dummy_con;
-#endif
-
 	/* board initialization stuff */
 	ddb5476_board_init();
 }
diff -Nru linux/arch/mips/kernel/setup.c.orig linux/arch/mips/kernel/setup.c
--- linux/arch/mips/kernel/setup.c.orig	Tue Nov 18 10:01:24 2003
+++ linux/arch/mips/kernel/setup.c	Wed Jan 21 16:00:47 2004
@@ -32,6 +32,7 @@
 #include <linux/kdev_t.h>
 #include <linux/root_dev.h>
 #include <linux/highmem.h>
+#include <linux/console.h>
 
 #include <asm/addrspace.h>
 #include <asm/bootinfo.h>
@@ -471,6 +472,15 @@
 	set_c0_status(ST0_CU0|ST0_KX|ST0_SX|ST0_FR);
 #endif
 
+#ifdef CONFIG_VT
+#if defined(CONFIG_VGA_CONSOLE)
+        conswitchp = &vga_con;
+#elif defined(CONFIG_DUMMY_CONSOLE)
+        conswitchp = &dummy_con;
+#endif
+#endif
+
+	/* call board setup routine */
 	do_earlyinitcalls();
 
 	strlcpy(command_line, arcs_cmdline, sizeof(command_line));

--V0207lvV8h4k8FAm--

From ralf@linux-mips.org Thu Jan 22 00:33:00 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 22 Jan 2004 00:33:01 +0000 (GMT)
Received: from p508B5B9C.dip.t-dialin.net ([IPv6:::ffff:80.139.91.156]:53305
	"EHLO mail.linux-mips.net") by linux-mips.org with ESMTP
	id <S8224936AbUAVAdA>; Thu, 22 Jan 2004 00:33:00 +0000
Received: from fluff.linux-mips.net (fluff.linux-mips.net [127.0.0.1])
	by mail.linux-mips.net (8.12.8/8.12.8) with ESMTP id i0M0Wxex015914
	for <linux-mips@linux-mips.org>; Thu, 22 Jan 2004 01:32:59 +0100
Received: (from ralf@localhost)
	by fluff.linux-mips.net (8.12.8/8.12.8/Submit) id i0M0WxfZ015913
	for linux-mips@linux-mips.org; Thu, 22 Jan 2004 01:32:59 +0100
Resent-Message-Id: <200401220032.i0M0WxfZ015913@fluff.linux-mips.net>
Received: from fluff.linux-mips.net (fluff.linux-mips.net [127.0.0.1])
	by mail.linux-mips.net (8.12.8/8.12.8) with ESMTP id i0M0SSex015814
	for <nlarson@Crossroads.com>; Thu, 22 Jan 2004 01:28:28 +0100
Received: (from ralf@localhost)
	by fluff.linux-mips.net (8.12.8/8.12.8/Submit) id i0M0SRcf015813
	for nlarson@Crossroads.com; Thu, 22 Jan 2004 01:28:27 +0100
Date: Thu, 22 Jan 2004 01:28:27 +0100
From: Ralf Baechle <ralf@linux-mips.org>
To: Nils Larson <nlarson@Crossroads.com>
Subject: Re: How to add more memory?
Message-ID: <20040122002827.GA10415@linux-mips.org>
References: <CFD808D1D39ACB47ABFF586D484CC52EADE212@hqmailnode1.commstor.crossroads.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CFD808D1D39ACB47ABFF586D484CC52EADE212@hqmailnode1.commstor.crossroads.com>
User-Agent: Mutt/1.4.1i
Resent-From: ralf@linux-mips.org
Resent-Date: Thu, 22 Jan 2004 01:32:59 +0100
Resent-To: linux-mips@linux-mips.org
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: 4091
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
Content-Length: 964
Lines: 22

On Wed, Jan 21, 2004 at 03:58:24PM -0600, Nils Larson wrote:

> We currently have a mips platform running Linux with 256MB of
> RAM starting at 0x8000_0000. We would like to add an additional
> 1GB of RAM, maybe starting at 0x4000_0000, that would be used
> for user apps (user virtual memory). The memory map is:
> 0x8000_0000 - 256MB RAM
> 0xA000_0000 - uncached version of the same 256MB
> 0xB000_0000 - PCI memory windows.
> This is a diskless setup booting from a ramdisk.
> So, the (sort of newbie) questions are:
> 1. How do we tell Linux to use the new memory?
> 2. Is this feasible?
> 3. Is there a better way to add more memory?
> We need more space for user data.

I wrote the highmem code for Linux/MIPS.  It's currently limited
to processor configurations that don't suffer from virtual aliases but
that limitation can be removed; depending of your application and hardware
that may be anywhere from trivial to hard.   What is your processor?

  Ralf

From narendrasankar@yahoo.com Thu Jan 22 01:06:51 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 22 Jan 2004 01:08:48 +0000 (GMT)
Received: from smtp015.mail.yahoo.com ([IPv6:::ffff:216.136.173.59]:23981 "HELO
	smtp015.mail.yahoo.com") by linux-mips.org with SMTP
	id <S8224936AbUAVBGv>; Thu, 22 Jan 2004 01:06:51 +0000
Received: from unknown (HELO 192.168.0.100) (narendrasankar@67.119.11.4 with plain)
  by smtp015.mail.yahoo.com with SMTP; 22 Jan 2004 01:06:49 -0000
From: Narendra Sankar <narendrasankar@yahoo.com>
Reply-To: narendrasankar@yahoo.com
To: linux-mips@linux-mips.org
Subject: Error building for rm5231 due to multiple page size support
Date: Wed, 21 Jan 2004 16:14:13 -0800
User-Agent: KMail/1.5.94
MIME-Version: 1.0
Content-Disposition: inline
Message-Id: <200401211051.03411.narendrasankar@yahoo.com>
Content-Type: text/plain;
  charset="us-ascii"
Content-Transfer-Encoding: 7bit
Return-Path: <narendrasankar@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: 4092
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: narendrasankar@yahoo.com
Precedence: bulk
X-list: linux-mips
Content-Length: 1858
Lines: 42

hi

I am trying to build the 2.4 32-bit (both HEAD and 2_4_23) kernel for the 
rm5231 cpu - both the cobalt and the ite8172 configurations (just using the 
default configurations from arch/mips/). I get the 
following error due to the changes made to support multiple page sizes. 
Looking at the code, this probably affects all configurations except for the 
ones that use MIPS32 (it seems that these configurations - for example the 
malta, actually do not ever use _PTE_T_LOG2) which include tlbex-mips32.S. 
The code from offset.c 
seems to generate a offset.h which has _PTE_T_LOG2 defined to be $2. Here is 
the snippet from the offset.h -

#define _PGD_T_LOG2    $2
#define _PMD_T_LOG2    $2
#define _PTE_T_LOG2    $2
  

mipsel-linux-gcc -D__ASSEMBLY__ -D__KERNEL__ 
-I/home/naren/lnxsrc/linux-2.4.23/linux/include 
-I /home/naren/lnxsrc/linux-2.4.23/linux/include/asm/gcc -G 0 -mno-abicalls 
-fno-pic -pipe   -mcpu=r5000 -mips2 -Wa,--trap   -c -o tlbex-r4k.o 
tlbex-r4k.S
tlbex-r4k.S: Assembler messages:
tlbex-r4k.S:178: Error: Instruction srl requires absolute expression
tlbex-r4k.S:178: Warning: Improper shift amount (4294967295)
tlbex-r4k.S:206: Error: Instruction srl requires absolute expression
tlbex-r4k.S:206: Warning: Improper shift amount (4294967295)
tlbex-r4k.S:242: Error: Instruction srl requires absolute expression
tlbex-r4k.S:242: Warning: Improper shift amount (4294967295)
tlbex-r4k.S:274: Error: Instruction srl requires absolute expression
tlbex-r4k.S:274: Warning: Improper shift amount (4294967295)
tlbex-r4k.S:465: Error: Instruction srl requires absolute expression
tlbex-r4k.S:493: Error: Instruction srl requires absolute expression
tlbex-r4k.S:520: Error: Instruction srl requires absolute expression
make[2]: *** [tlbex-r4k.o] Error 1


Is something wrong with the code, or with my configuration?

Thanks
Naren Sankar

From ica2_ts@csv.ica.uni-stuttgart.de Thu Jan 22 01:18:31 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 22 Jan 2004 01:18:31 +0000 (GMT)
Received: from iris1.csv.ica.uni-stuttgart.de ([IPv6:::ffff:129.69.118.2]:57692
	"EHLO iris1.csv.ica.uni-stuttgart.de") by linux-mips.org with ESMTP
	id <S8224936AbUAVBSb>; Thu, 22 Jan 2004 01:18:31 +0000
Received: from rembrandt.csv.ica.uni-stuttgart.de ([129.69.118.42])
	by iris1.csv.ica.uni-stuttgart.de with esmtp
	id 1AjTUJ-0007Ha-00; Thu, 22 Jan 2004 02:18:27 +0100
Received: from ica2_ts by rembrandt.csv.ica.uni-stuttgart.de with local (Exim 3.35 #1 (Debian))
	id 1AjTUJ-0006DX-00; Thu, 22 Jan 2004 02:18:27 +0100
Date: Thu, 22 Jan 2004 02:18:27 +0100
To: Narendra Sankar <narendrasankar@yahoo.com>
Cc: linux-mips@linux-mips.org
Subject: Re: Error building for rm5231 due to multiple page size support
Message-ID: <20040122011827.GA23173@rembrandt.csv.ica.uni-stuttgart.de>
References: <200401211051.03411.narendrasankar@yahoo.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <200401211051.03411.narendrasankar@yahoo.com>
User-Agent: Mutt/1.5.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: 4093
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
Content-Length: 2106
Lines: 47

Narendra Sankar wrote:
> hi
> 
> I am trying to build the 2.4 32-bit (both HEAD and 2_4_23) kernel for the 
> rm5231 cpu - both the cobalt and the ite8172 configurations (just using the 
> default configurations from arch/mips/). I get the 
> following error due to the changes made to support multiple page sizes. 
> Looking at the code, this probably affects all configurations except for the 
> ones that use MIPS32 (it seems that these configurations - for example the 
> malta, actually do not ever use _PTE_T_LOG2) which include tlbex-mips32.S. 
> The code from offset.c 
> seems to generate a offset.h which has _PTE_T_LOG2 defined to be $2. Here is 
> the snippet from the offset.h -
> 
> #define _PGD_T_LOG2    $2
> #define _PMD_T_LOG2    $2
> #define _PTE_T_LOG2    $2
>   
> 
> mipsel-linux-gcc -D__ASSEMBLY__ -D__KERNEL__ 
> -I/home/naren/lnxsrc/linux-2.4.23/linux/include 
> -I /home/naren/lnxsrc/linux-2.4.23/linux/include/asm/gcc -G 0 -mno-abicalls 
> -fno-pic -pipe   -mcpu=r5000 -mips2 -Wa,--trap   -c -o tlbex-r4k.o 
> tlbex-r4k.S
> tlbex-r4k.S: Assembler messages:
> tlbex-r4k.S:178: Error: Instruction srl requires absolute expression
> tlbex-r4k.S:178: Warning: Improper shift amount (4294967295)
> tlbex-r4k.S:206: Error: Instruction srl requires absolute expression
> tlbex-r4k.S:206: Warning: Improper shift amount (4294967295)
> tlbex-r4k.S:242: Error: Instruction srl requires absolute expression
> tlbex-r4k.S:242: Warning: Improper shift amount (4294967295)
> tlbex-r4k.S:274: Error: Instruction srl requires absolute expression
> tlbex-r4k.S:274: Warning: Improper shift amount (4294967295)
> tlbex-r4k.S:465: Error: Instruction srl requires absolute expression
> tlbex-r4k.S:493: Error: Instruction srl requires absolute expression
> tlbex-r4k.S:520: Error: Instruction srl requires absolute expression
> make[2]: *** [tlbex-r4k.o] Error 1
> 
> 
> Is something wrong with the code, or with my configuration?

The new gcc options selection code in arch/mips/Makefile seems to
erraneously filter out -finline-limit=100000, which prevents the
misgeneration of offset.h.


Thiemo

From ndf@ghs.com Thu Jan 22 02:32:35 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 22 Jan 2004 02:32:35 +0000 (GMT)
Received: from eta.ghs.com ([IPv6:::ffff:63.102.70.66]:43007 "EHLO eta.ghs.com")
	by linux-mips.org with ESMTP id <S8225581AbUAVCcf>;
	Thu, 22 Jan 2004 02:32:35 +0000
Received: from blaze.ghs.com (blaze.ghs.com [192.67.158.233])
	by eta.ghs.com (8.12.10/8.12.10) with ESMTP id i0M2WOh5019175;
	Wed, 21 Jan 2004 18:32:25 -0800 (PST)
Received: from zcar.ghs.com (zcar.ghs.com [192.67.158.60])
	by blaze.ghs.com (8.12.9/8.12.9) with ESMTP id i0M2WNBe021044;
	Wed, 21 Jan 2004 18:32:23 -0800 (PST)
Date: Wed, 21 Jan 2004 18:32:23 -0800 (PST)
From: Nathan Field <ndf@ghs.com>
To: Kumba <kumba@gentoo.org>
cc: linux-mips@linux-mips.org
Subject: Solving the cross-compiler issue (Was: Trouble compiling MIPS
 cross-compiler)
In-Reply-To: <400A1B5F.6010307@gentoo.org>
Message-ID: <Pine.LNX.4.44.0401211633240.31973-101000@zcar.ghs.com>
MIME-Version: 1.0
Content-Type: MULTIPART/MIXED; BOUNDARY="1136671902-1409114875-1074738743=:31973"
Return-Path: <ndf@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: 4094
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: ndf@ghs.com
Precedence: bulk
X-list: linux-mips
Content-Length: 11745
Lines: 223

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.
  Send mail to mime@docserver.cac.washington.edu for more info.

--1136671902-1409114875-1074738743=:31973
Content-Type: TEXT/PLAIN; charset=US-ASCII

This email is a bit long so here's the short version:
	Building cross tools is basically impossible without knowledge 
which isn't available on the www.linux-mips.org web site
	glibc seems to have obvious syntax errors and won't even compile
	The prebuilt tools referenced in the FAQ are so out of date 
they're useless
	Even tools provided by various commercial Linux vendors are out of 
date (at least what MontaVista lets us see in their preview kits)
	This could all be solved if someone wrote a script to do all the 
work which contains all the logic necessary to get a known set of tools to 
build

I've written a script which will do all the work, but because there are 
failures in building glibc it doesn't work. If someone could help me get 
my script to work it could be used to update the cross compile section of 
the FAQ. The script as it stands is attached. It needs some configuration 
(which is why it exits by default), but if you're trying to build a cross 
compiler you'd better have at least some knowledge of what you're doing.

Here's what it does:
	it wgets specific versions of binutils, gcc and glibc
	it sets some environment variables
	it uncompresses and builds the tools in the "correct" sequence 
with the correct options

There are 2 problems with this script:
	1. It references a specific binutils snapshot which will probably 
go away in a few days
	2. It doesn't f'ing work

That said, here's where things are breaking:

I'm also trying to build a newer cross toolchain since MontaVista doesn't
seem to provide one recent enough to even build the linux_2_4 branch from
the linux-mips cvs repository (it builds, but when I run it on my Malta
board it crashes immediately). I'm coming up against problems that just
seem stupidly obvious... Enough ranting though, here are the details.

Kumba suggested using:
> I'd recommend the following:
> binutils-2.14.90.0.7 (or you can try the latest .8 release, it has some 
> more mips fixes in it)
> glibc-2.3.2 (or 2.3.1)
> gcc-3.3.2
	I couldn't find a version of binutils like that, so I grabbed 
yesterdays snapshot, which builds and runs fine. Then I built the gcc 
bootstrap fine. Then I tried building glibc-2.3.2. That failed when it got 
to stdio-common/sscanf. The declaration of sscanf:

sscanf (s, format)
     const char *s;
     const char *format;

Doesn't match the function, and it should be:

sscanf (const char *s, const char *format, ...)

Does no one even bother to test to see if these things compile before they 
are released? I've had similar syntax error type problems when building 
several older (2.2.x) versions of glibc for PPC.

Anyway, after I fixed that I now get a link failure:

/space1/ndf/linux/mips/tools/glibc-build/elf/ld.so.1: undefined reference 
to `elf_machine_rela.7'

The command which generates this is:

mips-linux-gcc -nostdlib -nostartfiles -o 
/space1/ndf/linux/mips/tools/glibc-build/iconv/iconvconfig  
-Wl,-dynamic-linker=/space1/ndf/demos/malta_linux_reference/embedded/tools/lib/ld.so.1    
/space1/ndf/linux/mips/tools/glibc-build/csu/crt1.o 
/space1/ndf/linux/mips/tools/glibc-build/csu/crti.o `mips-linux-gcc 
--print-file-name=crtbegin.o` 
/space1/ndf/linux/mips/tools/glibc-build/iconv/iconvconfig.o 
/space1/ndf/linux/mips/tools/glibc-build/iconv/strtab.o 
/space1/ndf/linux/mips/tools/glibc-build/iconv/xmalloc.o  
-Wl,-rpath-link=/space1/ndf/linux/mips/tools/glibc-build:/space1/ndf/linux/mips/tools/glibc-build/math:/space1/ndf/linux/mips/tools/glibc-build/elf:/space1/ndf/linux/mips/tools/glibc-build/dlfcn:/space1/ndf/linux/mips/tools/glibc-build/nss:/space1/ndf/linux/mips/tools/glibc-build/nis:/space1/ndf/linux/mips/tools/glibc-build/rt:/space1/ndf/linux/mips/tools/glibc-build/resolv:/space1/ndf/linux/mips/tools/glibc-build/crypt:/space1/ndf/linux/mips/tools/glibc-build/linuxthreads 
/space1/ndf/linux/mips/tools/glibc-build/libc.so.6 
/space1/ndf/linux/mips/tools/glibc-build/libc_nonshared.a -lgcc 
`mips-linux-gcc --print-file-name=crtend.o` 
/space1/ndf/linux/mips/tools/glibc-build/csu/crtn.o
/space1/ndf/linux/mips/tools/glibc-build/elf/ld.so.1: undefined reference 
to `elf_machine_rela.7'

Interestingly when I try glibc 2.3.1 I get the same syntax error in sscanf 
but the linker complains about elf_machine_rela, without the .7.

It would be wonderful if I could get some help on this. It seems like a
chicken and egg problem which will only get worse as more and more people
try to build the 2.6 kernels.

	nathan

PS. This script is totally ripped off of Kumba's script which he submitted 
earlier. I've just added stuff to try to automate *everything*.

-- 
Nathan Field (ndf@ghs.com)			          All gone.

But the trouble with analogies is that analogies are like goldfish:
sometimes they have nothing to do with the topic at hand.
        -- Crispin (from a posting to the Bugtraq mailing list)


--1136671902-1409114875-1074738743=:31973
Content-Type: APPLICATION/x-sh; name="build_tools.sh"
Content-Transfer-Encoding: BASE64
Content-ID: <Pine.LNX.4.44.0401211832230.31973@zcar.ghs.com>
Content-Description: 
Content-Disposition: attachment; filename="build_tools.sh"

IyEvYmluL3NoCgojIFRoaXMgc2NyaXB0IGlzIGJhc2VkIG9uIGEgc2NyaXB0
IHBvc3RlZCB0byBsaW51eC1taXBzQGxpbnV4LW1pcHMub3JnCiMgYnkgS3Vt
YmEgPGt1bWJhQGdlbnRvby5vcmc+LiBJdCBpcyBpbnRlbmRlZCB0byBjb250
YWluIGFsbCBsb2dpYwojIG5lY2Vzc2FyeSB0byBidWlsZCBhIExpbnV4IE1J
UFMgdG9vbGNoYWluLiBUaGlzIHNlZW1zIHRvIGJlIGEgdmVyeQojIGNvbW1v
biBpc3N1ZSBvbiB0aGUgbWFpbGluZyBsaXN0LgoKZWNobyAiWW91IG11c3Qg
Zmlyc3Qgc2V0dXAgdGhlIGVudmlyb25tZW50IHZhcmlhYmxlcyBmb3IgeW91
ciBjb25maWd1cmF0aW9uLiIKZXhpdCAxCgpleHBvcnQgbXlBUkNIPW1pcHMt
bGludXgKZXhwb3J0IG15SE9TVD1pMzg2LWxpbnV4CmV4cG9ydCBteURFU1Q9
L3NwYWNlMS9uZGYvZGVtb3MvbWFsdGFfbGludXhfcmVmZXJlbmNlL2VtYmVk
ZGVkL3Rvb2xzCmV4cG9ydCBteVhUUkE9Ii1taXBzMiIKZXhwb3J0IG15T1JJ
R0hFQURFUlM9L2hvbWUvemNhcjEvbmRmL2RlbW9zL21hbHRhX2xpbnV4X3Jl
ZmVyZW5jZS9lbWJlZGRlZC9uZnNyb290X2ZpbGVzeXN0ZW0vdXNyL2luY2x1
ZGUKZXhwb3J0IG15S0VSTkVMU1JDPS9ob21lL3pjYXIxL25kZi9kZW1vcy9t
YWx0YV9saW51eF9yZWZlcmVuY2UvZW1iZWRkZWQvbGludXgtMi40LjE3X212
bDIxCmV4cG9ydCBQQVRIPSR7bXlERVNUfS9iaW46JFBBVEgKCgojIE5laXRo
ZXIgdmVyc2lvbiB3b3JrcywgYnV0IHlvdSBjYW4gdHJ5IGVpdGhlciBpZiB5
b3Ugd2FudC4KI2V4cG9ydCBHTElCQ19WRVI9Mi4zLjEKZXhwb3J0IEdMSUJD
X1ZFUj0yLjMuMgoKCmlmIFsgISAtZiBzc2NhbmYuY19maXhlZCBdOyB0aGVu
CiAgIyBUaGUgZGVjbGFyYXRpb24gb2Ygc3NjYW5mIGlzIHdyb25nLCBjaGFu
Z2UgaXQgdG86CiAgIyBpbnQgc3NjYW5mIChjb25zdCBjaGFyICpzLCBjb25z
dCBjaGFyICpmb3JtYXQsIC4uLikKICAjIGFuZCBwdXQgaW50byBhIGZpbGUg
c3NjYW5mLmNfZml4ZWQgaW4gdGhlIHRvcGxldmVsIGRpcmVjdG9yeS4KICBl
Y2hvICJZb3UgbXVzdCBzdXBwbHkgYSBmaXhlZCB2ZXJzaW9uIG9mIHRoZSBz
c2NhbmYuYyBmaWxlIGZvciBnbGliYyIKICBlY2hvICJpbiBnbGliYy0ke0dM
SUJDX1ZFUn0vc3RkaW8tY29tbW9uLiIKICBleGl0IDEKZmkKCgplY2hvICJc
blxuXG4qKioqIERPV05MT0FESU5HIFNPVVJDRSAqKioqXG5cblxuXG4iCmlm
IFsgISAtZiBiaW51dGlscy0wNDAxMjEudGFyLmJ6MiBdOyB0aGVuCiAgd2dl
dCBmdHA6Ly9zb3VyY2VzLnJlZGhhdC5jb20vcHViL2JpbnV0aWxzL3NuYXBz
aG90cy9iaW51dGlscy0wNDAxMjEudGFyLmJ6MgpmaQppZiBbICEgLWYgZ2Nj
LTMuMy4yLnRhci5neiBdOyB0aGVuCiAgd2dldCBmdHA6Ly9mdHAuZ251Lm9y
Zy9nbnUvZ2NjLTMuMy4yLnRhci5negpmaQppZiBbICEgLWYgZ2xpYmMtJHtH
TElCQ19WRVJ9LnRhci5neiBdOyB0aGVuCiAgd2dldCBmdHA6Ly9mdHAuZ251
Lm9yZy9nbnUvZ2xpYmMvZ2xpYmMtJHtHTElCQ19WRVJ9LnRhci5negpmaQpp
ZiBbICEgLWYgZ2xpYmMtbGludXh0aHJlYWRzLSR7R0xJQkNfVkVSfS50YXIu
Z3ogXTsgdGhlbgogIHdnZXQgZnRwOi8vZnRwLmdudS5vcmcvZ251L2dsaWJj
L2dsaWJjLWxpbnV4dGhyZWFkcy0ke0dMSUJDX1ZFUn0udGFyLmd6CmZpCgoK
ZWNobyAiXG5cblxuKioqKiAgTUFLSU5HIEJJTlVUSUxTICoqKipcblxuXG5c
biIKcm0gLXJmIGJpbnV0aWxzLTA0MDEyMQp0YXIgeGpmIGJpbnV0aWxzLTA0
MDEyMS50YXIuYnoyCmNkIGJpbnV0aWxzLTA0MDEyMQouL2NvbmZpZ3VyZSBc
CiAgICAgICAgLS10YXJnZXQ9JHtteUFSQ0h9IC0taG9zdD0ke215SE9TVH0g
XAogICAgICAgIC0tcHJlZml4PSR7bXlERVNUfSAtLWVuYWJsZS1zaGFyZWQg
XAogICAgICAgIC0tZW5hYmxlLTY0LWJpdC1iZmQgXAomJiBtYWtlICYmIG1h
a2UgaW5zdGFsbApjZCAuLgoKCmVjaG8gIlxuXG5cbioqKiogU0VUVElORyBV
UCBLRVJORUwgSEVBREVSUyAqKioqXG5cblxuXG4iCmNwIC1yICR7bXlPUklH
SEVBREVSU30vKiAke215REVTVH0vaW5jbHVkZS8Kcm0gLVJmICR7bXlERVNU
fS9pbmNsdWRlL2xpbnV4CnJtIC1SZiAke215REVTVH0vaW5jbHVkZS9hc20q
CmNwIC1yICR7bXlLRVJORUxTUkN9L2luY2x1ZGUvbGludXggJHtteURFU1R9
L2luY2x1ZGUKY3AgLXIgJHtteUtFUk5FTFNSQ30vaW5jbHVkZS9hc20tJChl
Y2hvICR7bXlBUkNIfSB8IGN1dCAtZC0gLWYxKSAke215REVTVH0vaW5jbHVk
ZQpjcCAtciAke215S0VSTkVMU1JDfS9pbmNsdWRlL2FzbS1nZW5lcmljICR7
bXlERVNUfS9pbmNsdWRlCmxuIC1zICR7bXlERVNUfS9pbmNsdWRlL2FzbS0k
KGVjaG8gJHtteUFSQ0h9IHwgY3V0IC1kLSAtZjEpICR7bXlERVNUfS9pbmNs
dWRlL2FzbSAKCgplY2hvICJcblxuXG4qKioqIERPSU5HIEdDQyBCT09UU1RS
QVAgKioqKlxuXG5cblxuIgppZiBbICEgLWQgZ2NjLTMuMy4yIF07IHRoZW4K
ICB0YXIgeHpmIGdjYy0zLjMuMi50YXIuZ3oKZmkKcm0gLXJmIGdjYy1idWls
ZC1ib290c3RyYXAKbWtkaXIgZ2NjLWJ1aWxkLWJvb3RzdHJhcApjZCBnY2Mt
YnVpbGQtYm9vdHN0cmFwCnRpbWUgLi4vZ2NjLTMuMy4yL2NvbmZpZ3VyZSBc
CiAgICAgICAgLS1wcmVmaXg9JHtteURFU1R9IC0taG9zdD0ke215SE9TVH0g
XAogICAgICAgIC0tdGFyZ2V0PSR7bXlBUkNIfSAtLXdpdGgtbmV3bGliIFwK
ICAgICAgICAtLWRpc2FibGUtc2hhcmVkIC0tZGlzYWJsZS10aHJlYWRzIFwK
ICAgICAgICAtLWVuYWJsZS1sYW5ndWFnZXM9YyAtLWRpc2FibGUtbXVsdGls
aWIgXAogICAgICAgIC0td2l0aG91dC1oZWFkZXJzIFwKJiYgbWFrZSAmJiBt
YWtlIGluc3RhbGwKY2QgLi4KCgplY2hvICJcblxuXG4qKioqIEJVSUxESU5H
IEdMSUJDICoqKipcblxuXG5cbiIKaWYgWyAhIC1kIGdsaWJjLSR7R0xJQkNf
VkVSfSBdOyB0aGVuCiAgdGFyIHh6ZiBnbGliYy0ke0dMSUJDX1ZFUn0udGFy
Lmd6CiAgZWNobyAiUGF0Y2hpbmcgYnJva2VuIHNzY2FuZi5jLiIKICBjcCBz
c2NhbmYuY19maXhlZCBnbGliYy0ke0dMSUJDX1ZFUn0vc3RkaW8tY29tbW9u
L3NzY2FuZi5jCmZpCmlmIFsgISAtZCBnbGliYy0ke0dMSUJDX1ZFUn0vbGlu
dXh0aHJlYWRzIF07IHRoZW4KICBjZCBnbGliYy0ke0dMSUJDX1ZFUn0KICB0
YXIgeHpmIC4uL2dsaWJjLWxpbnV4dGhyZWFkcy0ke0dMSUJDX1ZFUn0udGFy
Lmd6CiAgY2QgLi4KZmkKcm0gLXJmIGdsaWJjLWJ1aWxkCm1rZGlyIGdsaWJj
LWJ1aWxkCmNkIGdsaWJjLWJ1aWxkCnRpbWUgQ0M9IiR7bXlBUkNIfS1nY2Mi
IENGTEFHUz0iLU8yICR7bXlYVFJBfSIgQVM9IiR7bXlBUkNIfS1hcyIgXAoJ
TEQ9IiR7bXlBUkNIfS1sZCIgXAogICAgICAgIC4uL2dsaWJjLSR7R0xJQkNf
VkVSfS9jb25maWd1cmUgXAogICAgICAgICAgICAgICAgLS1wcmVmaXg9JHtt
eURFU1R9IC0taG9zdD0ke215QVJDSH0gXAogICAgICAgICAgICAgICAgLS1i
dWlsZD0ke215SE9TVH0gLS13aXRob3V0LXRscyBcCiAgICAgICAgICAgICAg
ICAtLXdpdGhvdXQtX190aHJlYWQgXAogICAgICAgICAgICAgICAgLS1lbmFi
bGUtYWRkLW9ucz1saW51eHRocmVhZHMgXAogICAgICAgICAgICAgICAgLS1l
bmFibGUta2VybmVsPTIuNC4wIC0td2l0aC1nZD1ubyBcCiAgICAgICAgICAg
ICAgICAtLXdpdGhvdXQtY3ZzIC0tZGlzYWJsZS1wcm9maWxlIFwKICAgICAg
ICAgICAgICAgIC0td2l0aC1oZWFkZXJzPSIke215REVTVH0vaW5jbHVkZSIg
XAogICAgICAgICYmIG1ha2UgJiYgbWFrZSBpbnN0YWxsCmNkIC4uCgoKIyBU
aGlzIGhhcyBub3QgYmVlbiB0ZXN0ZWQgYmVjYXVzZSB0aGUgZ2xpYmMgYnVp
bGQgZmFpbHMuCiNlY2hvICJcblxuXG4qKioqIEJVSUxESU5HIEZVTEwgR0ND
ICoqKipcblxuXG5cbiIKI3JtIC1yZiBnY2MtYnVpbGQtZnVsbAojbWtkaXIg
Z2NjLWJ1aWxkLWZ1bGwKI2NkIGdjYy1idWlsZC1mdWxsCiN0aW1lIC4uL2dj
Yy0zLjMuMi9jb25maWd1cmUgXAojICAgICAgICAtLXByZWZpeD0ke215REVT
VH0gLS10YXJnZXQ9JHtteUFSQ0h9IFwKIyAgICAgICAgLS1ob3N0PSR7bXlI
T1NUfSAtLWRpc2FibGUtbXVsdGlsaWIgXAojICAgICAgICAtLWVuYWJsZS1z
aGFyZWQgLS1lbmFibGUtbGFuZ3VhZ2VzPSJjLGMrKyxhZGEsZjc3LG9iamMi
IFwKIyAgICAgICAgLS1lbmFibGUtbmxzIC0td2l0aG91dC1pbmNsdWRlZC1n
ZXR0ZXh0IFwKIyAgICAgICAgLS13aXRoLXN5c3RlbS16bGliIC0tZW5hYmxl
LXRocmVhZHM9cG9zaXggXAojICAgICAgICAtLWVuYWJsZS1sb25nLWxvbmcg
LS1kaXNhYmxlLWNoZWNraW5nIFwKIyAgICAgICAgLS1lbmFibGUtY3N0ZGlv
PXN0ZGlvIFwKIyAgICAgICAgLS1lbmFibGUtY2xvY2FsZT1nZW5lcmljIFwK
IyAgICAgICAgLS1lbmFibGUtX19jeGFfYXRleGl0IFwKIyAgICAgICAgLS1l
bmFibGUtdmVyc2lvbi1zcGVjaWZpYy1ydW50aW1lLWxpYnMgXAojICAgICAg
ICAtLXdpdGgtbG9jYWwtcHJlZml4PSR7cHJlZml4fS9sb2NhbCBcCiMgICAg
ICAgIC0td2l0aC1saWJzPSIke215REVTVH0vbGliIiBcCiMgICAgICAgIC0t
d2l0aC1oZWFkZXJzPSIke215REVTVH0vJHtteUFSQ0h9L2luY2x1ZGUiIFwK
IyYmIG1ha2UgJiYgbWFrZSBpbnN0YWxsCiNjZCAuLgo=
--1136671902-1409114875-1074738743=:31973--

From ica2_ts@csv.ica.uni-stuttgart.de Thu Jan 22 04:08:00 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 22 Jan 2004 04:08:01 +0000 (GMT)
Received: from iris1.csv.ica.uni-stuttgart.de ([IPv6:::ffff:129.69.118.2]:5726
	"EHLO iris1.csv.ica.uni-stuttgart.de") by linux-mips.org with ESMTP
	id <S8224936AbUAVEIA>; Thu, 22 Jan 2004 04:08:00 +0000
Received: from rembrandt.csv.ica.uni-stuttgart.de ([129.69.118.42])
	by iris1.csv.ica.uni-stuttgart.de with esmtp
	id 1AjW8N-0000KE-00; Thu, 22 Jan 2004 05:07:59 +0100
Received: from ica2_ts by rembrandt.csv.ica.uni-stuttgart.de with local (Exim 3.35 #1 (Debian))
	id 1AjW8N-0006ou-00; Thu, 22 Jan 2004 05:07:59 +0100
Date: Thu, 22 Jan 2004 05:07:59 +0100
To: linux-mips@linux-mips.org
Cc: Ralf Baechle <ralf@linux-mips.org>
Subject: [PATCH, 2.4] Fix bad check_gcc order for mips64, make offset.h creation more robust
Message-ID: <20040122040759.GB23173@rembrandt.csv.ica.uni-stuttgart.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.5.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: 4095
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
Content-Length: 2360
Lines: 61

Hallo All,

current 2.4 64bit kernels fail to build for newer toolchains because
the -finline-limit=100000 option is ignored. The symptom is some bogus
offset.h content which stops the build in arch/mips64/mm/tlbex-r4k.S.

This patch fixes it by moving check_gcc in front of its first use,
it also removes some stale files if offset.h needs to be regenerated.


Thiemo


Index: arch/mips/Makefile
===================================================================
RCS file: /home/cvs/linux/arch/mips/Makefile,v
retrieving revision 1.78.2.50
diff -a -d -u -p -r1.78.2.50 Makefile
--- arch/mips/Makefile	11 Jan 2004 00:11:35 -0000	1.78.2.50
+++ arch/mips/Makefile	22 Jan 2004 03:18:57 -0000
@@ -746,5 +746,6 @@ archmrproper:
 archdep:
 	if [ ! -f $(TOPDIR)/include/asm-$(ARCH)/offset.h ]; then \
 		touch $(TOPDIR)/include/asm-$(ARCH)/offset.h; \
+		$(MAKE) -C arch/mips/tools clean; \
 	fi;
 	@$(MAKEBOOT) dep
Index: arch/mips64/Makefile
===================================================================
RCS file: /home/cvs/linux/arch/mips64/Attic/Makefile,v
retrieving revision 1.22.2.43
diff -a -d -u -p -r1.22.2.43 Makefile
--- arch/mips64/Makefile	3 Jan 2004 02:07:52 -0000	1.22.2.43
+++ arch/mips64/Makefile	22 Jan 2004 03:19:23 -0000
@@ -26,6 +26,9 @@ ifdef CONFIG_CROSSCOMPILE
 CROSS_COMPILE	= $(tool-prefix)
 endif
 
+check_gcc = $(shell if $(CC) $(1) -S -o /dev/null -xc /dev/null > /dev/null 2>&1; then echo "$(1)"; else echo "$(2)"; fi)
+check_gas = $(shell if $(CC) $(1) -Wa,-Z -c -o /dev/null -xassembler /dev/null > /dev/null 2>&1; then echo "$(1)"; else echo "$(2)"; fi)
+
 #
 # The ELF GCC uses -G 0 -mabicalls -fpic as default.  We don't need PIC
 # code in the kernel since it only slows down the whole thing.  For the
@@ -49,9 +52,6 @@ GCCFLAGS	+= -mno-sched-prolog -fno-omit-
 endif
 endif
 
-check_gcc = $(shell if $(CC) $(1) -S -o /dev/null -xc /dev/null > /dev/null 2>&1; then echo "$(1)"; else echo "$(2)"; fi)
-check_gas = $(shell if $(CC) $(1) -Wa,-Z -c -o /dev/null -xassembler /dev/null > /dev/null 2>&1; then echo "$(1)"; else echo "$(2)"; fi)
-
 #
 # Use: $(call set_gccflags,<cpu0>,<isa0>,<cpu1>,<isa1>)
 #
@@ -402,5 +406,6 @@ archmrproper:
 archdep:
 	if [ ! -f $(TOPDIR)/include/asm-$(ARCH)/offset.h ]; then \
 		touch $(TOPDIR)/include/asm-$(ARCH)/offset.h; \
+		$(MAKE) -C arch/mips/tools clean; \
 	fi;
 	@$(MAKEBOOT) dep

From karthik_96cse@yahoo.com Thu Jan 22 07:24:09 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 22 Jan 2004 07:24:10 +0000 (GMT)
Received: from web10102.mail.yahoo.com ([IPv6:::ffff:216.136.130.52]:21128
	"HELO web10102.mail.yahoo.com") by linux-mips.org with SMTP
	id <S8225254AbUAVHYJ>; Thu, 22 Jan 2004 07:24:09 +0000
Message-ID: <20040122072407.11156.qmail@web10102.mail.yahoo.com>
Received: from [128.107.253.43] by web10102.mail.yahoo.com via HTTP; Thu, 22 Jan 2004 07:24:07 GMT
Date: Thu, 22 Jan 2004 07:24:07 +0000 (GMT)
From: =?iso-8859-1?q?karthikeyan=20natarajan?= <karthik_96cse@yahoo.com>
Subject: Doubt in timer interrupt
To: linux-mips@linux-mips.org
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Return-Path: <karthik_96cse@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: 4096
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: karthik_96cse@yahoo.com
Precedence: bulk
X-list: linux-mips
Content-Length: 1232
Lines: 33

Hi All,

  In R4000 & descendent processors, interrupt number 7
is being used for internal timer interrupt. From this
i understand that the timer interrupt is also maskable
when the IE bit in status register is cleared. If 
somebody mask this interrupt for a long time 
erroneously, then won't there be a problem in 
maintaining the system time?
    Please correct me if i am wrong..

Does the system time is maintained via NMI?
   
Thanks in advance,
-karthi

=====
The expert at anything was once a beginner
                  ______________________________
                 /                              \
             O  /      Karthikeyan.N             \
           O   |       Chennai, India.            |
    `\|||/'     \    Mobile: +919884104346       /
     (o o)       \                              /
_ ooO (_) Ooo____________________________________
_____|_____|_____|_____|_____|_____|_____|_____|_
__|_____|_____|_____|_____|_____|_____|_____|____
_____|_____|_____|_____|_____|_____|_____|_____|_

________________________________________________________________________
Yahoo! Messenger - Communicate instantly..."Ping" 
your friends today! Download Messenger Now 
http://uk.messenger.yahoo.com/download/index.html

From mdharm@host099.momenco.com Thu Jan 22 07:41:42 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 22 Jan 2004 07:41:42 +0000 (GMT)
Received: from jeeves.momenco.com ([IPv6:::ffff:64.169.228.99]:24334 "EHLO 
	host099.momenco.com") by linux-mips.org with ESMTP
	id <S8225254AbUAVHlm>; Thu, 22 Jan 2004 07:41:42 +0000
Received: (from mdharm@localhost)
	by  host099.momenco.com (8.11.6/8.11.6) id i0M7fda24599;
	Wed, 21 Jan 2004 23:41:39 -0800
Date: Wed, 21 Jan 2004 23:41:38 -0800
From: Matthew Dharm <mdharm@momenco.com>
To: karthikeyan natarajan <karthik_96cse@yahoo.com>
Cc: linux-mips@linux-mips.org
Subject: Re: Doubt in timer interrupt
Message-ID: <20040121234138.A24587@momenco.com>
References: <20040122072407.11156.qmail@web10102.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: <20040122072407.11156.qmail@web10102.mail.yahoo.com>; from karthik_96cse@yahoo.com on Thu, Jan 22, 2004 at 07:24:07AM +0000
Organization: Momentum Computer, Inc.
X-Copyright: (C) 2004 Matthew Dharm, all rights reserved.
Return-Path: <mdharm@host099.momenco.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: 4097
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: mdharm@momenco.com
Precedence: bulk
X-list: linux-mips
Content-Length: 1626
Lines: 45

As with any timer interrupt, if you mask it too long you'll lose time.

Generally, masking interrupts via the IE bit is a bad idea.

Matt

On Thu, Jan 22, 2004 at 07:24:07AM +0000, karthikeyan natarajan wrote:
> Hi All,
> 
>   In R4000 & descendent processors, interrupt number 7
> is being used for internal timer interrupt. From this
> i understand that the timer interrupt is also maskable
> when the IE bit in status register is cleared. If 
> somebody mask this interrupt for a long time 
> erroneously, then won't there be a problem in 
> maintaining the system time?
>     Please correct me if i am wrong..
> 
> Does the system time is maintained via NMI?
>    
> Thanks in advance,
> -karthi
> 
> =====
> The expert at anything was once a beginner
>                   ______________________________
>                  /                              \
>              O  /      Karthikeyan.N             \
>            O   |       Chennai, India.            |
>     `\|||/'     \    Mobile: +919884104346       /
>      (o o)       \                              /
> _ ooO (_) Ooo____________________________________
> _____|_____|_____|_____|_____|_____|_____|_____|_
> __|_____|_____|_____|_____|_____|_____|_____|____
> _____|_____|_____|_____|_____|_____|_____|_____|_
> 
> ________________________________________________________________________
> Yahoo! Messenger - Communicate instantly..."Ping" 
> your friends today! Download Messenger Now 
> http://uk.messenger.yahoo.com/download/index.html

-- 
Matthew Dharm                              Work: mdharm@momenco.com
Senior Software Designer, Momentum Computer


From dom@mips.com Thu Jan 22 08:42:54 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 22 Jan 2004 08:42:54 +0000 (GMT)
Received: from alg145.algor.co.uk ([IPv6:::ffff:62.254.210.145]:9235 "EHLO
	dmz.algor.co.uk") by linux-mips.org with ESMTP id <S8225254AbUAVImy>;
	Thu, 22 Jan 2004 08:42:54 +0000
Received: from alg158.algor.co.uk ([62.254.210.158] helo=olympia.mips.com)
	by dmz.algor.co.uk with esmtp (Exim 3.35 #1 (Debian))
	id 1AjaLY-0002eC-00; Thu, 22 Jan 2004 08:37:52 +0000
Received: from olympia.mips.com ([192.168.192.128] helo=doms-laptop.algor.co.uk)
	by olympia.mips.com with esmtp (Exim 3.36 #1 (Debian))
	id 1AjaQ9-0004Oi-00; Thu, 22 Jan 2004 08:42:38 +0000
From: Dominic Sweetman <dom@mips.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <16399.36167.575161.386963@doms-laptop.algor.co.uk>
Date: Thu, 22 Jan 2004 08:43:51 +0000
To: =?iso-8859-1?q?karthikeyan=20natarajan?= <karthik_96cse@yahoo.com>
Cc: linux-mips@linux-mips.org
Subject: Re: Doubt in timer interrupt
In-Reply-To: <20040122072407.11156.qmail@web10102.mail.yahoo.com>
References: <20040122072407.11156.qmail@web10102.mail.yahoo.com>
X-Mailer: VM 7.07 under 21.4 (patch 10) "Military Intelligence (RC5 Windows)" XEmacs Lucid
X-MTUK-Scanner: Found to be clean
X-MTUK-SpamCheck: not spam, SpamAssassin (score=-4.838, required 4, AWL,
	BAYES_00)
Return-Path: <dom@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: 4098
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
Content-Length: 809
Lines: 27


Karthi,

>   In R4000 & descendent processors, interrupt number 7
> is being used for internal timer interrupt. From this
> i understand that the timer interrupt is also maskable
> when the IE bit in status register is cleared. If 
> somebody mask this interrupt for a long time 
> erroneously, then won't there be a problem in 
> maintaining the system time?

Yes, there may be a long delay.  So the standard way of using the
onchip counter to generate a periodic interrupt is that the counter
itself is allowed to free-run, keeping accurate time.

The 'Compare' register is then incremented by a fixed amount.

So long as the interrupt is not delayed by a whole tick, this keeps
perfect time.

I'm sure this is described in "See MIPS Run" - do you have a copy?

--
Dominic Sweetman
MIPS Technologies Inc



From aravindforl@yahoo.co.in Thu Jan 22 09:16:25 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 22 Jan 2004 09:16:26 +0000 (GMT)
Received: from web8206.mail.in.yahoo.com ([IPv6:::ffff:203.199.70.75]:54314
	"HELO web8206.mail.in.yahoo.com") by linux-mips.org with SMTP
	id <S8225254AbUAVJQZ>; Thu, 22 Jan 2004 09:16:25 +0000
Message-ID: <20040122091618.91012.qmail@web8206.mail.in.yahoo.com>
Received: from [202.41.227.188] by web8206.mail.in.yahoo.com via HTTP; Thu, 22 Jan 2004 09:16:18 GMT
Date: Thu, 22 Jan 2004 09:16:18 +0000 (GMT)
From: =?iso-8859-1?q?Arravind=20babu?= <aravindforl@yahoo.co.in>
Subject: Doubt on gdbserver
To: linux-mips@linux-mips.org
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="0-203697124-1074762978=:88192"
Content-Transfer-Encoding: 8bit
Return-Path: <aravindforl@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: 4099
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: aravindforl@yahoo.co.in
Precedence: bulk
X-list: linux-mips
Content-Length: 1477
Lines: 29

--0-203697124-1074762978=:88192
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

Hi all,
 
   I am new to this mailing list.I have one doubt related to gdbserver.I want to debug applications remotely using gdb server.My host is normal intel processsor and my target is mips core.So to debug applications on mips i am planning to implement gdbserver on the target.How to do that one?Is there any document related to this?
 
Thanks in advance,
Aravind.
 
 

Yahoo! India Mobile: Ringtones, Wallpapers, Picture Messages and more.Download now.
--0-203697124-1074762978=:88192
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

<DIV>Hi all,</DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;&nbsp; I am new to this mailing list.I have one doubt related to gdbserver.I want to debug applications remotely using gdb server.My host is normal intel processsor and my target is mips core.So to debug applications on mips i am planning to implement gdbserver on the target.How to do that one?Is there any document related to this?</DIV>
<DIV>&nbsp;</DIV>
<DIV>Thanks in advance,</DIV>
<DIV>Aravind.</DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV><p><font face=arial size=-1>
<a href="http://in.mobile.yahoo.com" target="_blank"><b>Yahoo! India Mobile</a>:</b> Ringtones, Wallpapers, Picture Messages and more.
<font face=arial size=-1>Download <a href="http://in.mobile.yahoo.com" target="_blank"><b>now</a></b>.</font>
--0-203697124-1074762978=:88192--

From karthik_96cse@yahoo.com Thu Jan 22 09:27:43 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 22 Jan 2004 09:27:44 +0000 (GMT)
Received: from web10105.mail.yahoo.com ([IPv6:::ffff:216.136.130.55]:52827
	"HELO web10105.mail.yahoo.com") by linux-mips.org with SMTP
	id <S8225254AbUAVJ1n>; Thu, 22 Jan 2004 09:27:43 +0000
Message-ID: <20040122092738.52844.qmail@web10105.mail.yahoo.com>
Received: from [128.107.253.43] by web10105.mail.yahoo.com via HTTP; Thu, 22 Jan 2004 09:27:38 GMT
Date: Thu, 22 Jan 2004 09:27:38 +0000 (GMT)
From: =?iso-8859-1?q?karthikeyan=20natarajan?= <karthik_96cse@yahoo.com>
Subject: Re: Doubt in timer interrupt
To: Dominic Sweetman <dom@mips.com>
Cc: linux-mips@linux-mips.org
In-Reply-To: <16399.36167.575161.386963@doms-laptop.algor.co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Return-Path: <karthik_96cse@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: 4100
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: karthik_96cse@yahoo.com
Precedence: bulk
X-list: linux-mips
Content-Length: 1931
Lines: 66

Hi Dominic Sweetman,

    Thanks much for your inputs..

> >   In R4000 & descendent processors, interrupt
> number 7
> > is being used for internal timer interrupt. From
> this
> > i understand that the timer interrupt is also
> maskable
> > when the IE bit in status register is cleared. If 
> > somebody mask this interrupt for a long time 
> > erroneously, then won't there be a problem in 
> > maintaining the system time?
> 
> Yes, there may be a long delay.  So the standard way
> of using the
> onchip counter to generate a periodic interrupt is
> that the counter
> itself is allowed to free-run, keeping accurate
> time.
> 
> The 'Compare' register is then incremented by a
> fixed amount.
> 
> So long as the interrupt is not delayed by a whole
> tick, this keeps
> perfect time.
> 
> I'm sure this is described in "See MIPS Run" - do
> you have a copy?

    Yes, i have a copy. Have just started reading
this book.. I yet to get into the deep waters of the
MIPS..

    May i know the purpose of the NMI interrupt and
in what way it differ from the timer interrupt.

Thanks much,
-karthi
 
> --
> Dominic Sweetman
> MIPS Technologies Inc
> 
> 
>  

=====
The expert at anything was once a beginner
                  ______________________________
                 /                              \
             O  /      Karthikeyan.N             \
           O   |       Chennai, India.            |
    `\|||/'     \    Mobile: +919884104346       /
     (o o)       \                              /
_ ooO (_) Ooo____________________________________
_____|_____|_____|_____|_____|_____|_____|_____|_
__|_____|_____|_____|_____|_____|_____|_____|____
_____|_____|_____|_____|_____|_____|_____|_____|_

________________________________________________________________________
Yahoo! Messenger - Communicate instantly..."Ping" 
your friends today! Download Messenger Now 
http://uk.messenger.yahoo.com/download/index.html

From geert@linux-m68k.org Thu Jan 22 09:53:01 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 22 Jan 2004 09:53:02 +0000 (GMT)
Received: from witte.sonytel.be ([IPv6:::ffff:80.88.33.193]:14992 "EHLO
	witte.sonytel.be") by linux-mips.org with ESMTP id <S8225254AbUAVJxB>;
	Thu, 22 Jan 2004 09:53:01 +0000
Received: from waterleaf.sonytel.be (localhost [127.0.0.1])
	by witte.sonytel.be (8.12.10/8.12.10) with ESMTP id i0M9qxw2011386;
	Thu, 22 Jan 2004 10:53:00 +0100 (MET)
Date: Thu, 22 Jan 2004 10:52:59 +0100 (MET)
From: Geert Uytterhoeven <geert@linux-m68k.org>
To: Jun Sun <jsun@mvista.com>
cc: Linux/MIPS Development <linux-mips@linux-mips.org>
Subject: Re: [PATCH 2.6] set up conswitchp when CONFIG_VT is set
In-Reply-To: <20040121162032.F29705@mvista.com>
Message-ID: <Pine.GSO.4.58.0401221052100.1408@waterleaf.sonytel.be>
References: <20040121162032.F29705@mvista.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <geert@linux-m68k.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: 4101
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
Content-Length: 1240
Lines: 39

On Wed, 21 Jan 2004, Jun Sun wrote:
> conswitchp needs to be set whenever CONFIG_VT is selected.
> Currently this job is done individually by each board in its setup
> routine, often in a wrong way.
>
> The right thing to do is to set the pointer in the common code
> and remove almost two dozens of duplicated and often wrong settings.
>
> The attached patch is for illustration only.  The removal of board settings
> is not complete.
>
> Comments?  Objections and cheers are equally welcome. :)

| --- linux/arch/mips/kernel/setup.c.orig	Tue Nov 18 10:01:24 2003
| +++ linux/arch/mips/kernel/setup.c	Wed Jan 21 16:00:47 2004
| @@ -471,6 +472,15 @@
|  	set_c0_status(ST0_CU0|ST0_KX|ST0_SX|ST0_FR);
|  #endif
|
| +#ifdef CONFIG_VT
| +#if defined(CONFIG_VGA_CONSOLE)
| +        conswitchp = &vga_con;
| +#elif defined(CONFIG_DUMMY_CONSOLE)
| +        conswitchp = &dummy_con;
| +#endif
| +#endif

Isn't the #ifdef CONFIG_VT superfluous?

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 anemo@mba.ocn.ne.jp Thu Jan 22 10:31:02 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 22 Jan 2004 10:31:02 +0000 (GMT)
Received: from topsns.toshiba-tops.co.jp ([IPv6:::ffff:202.230.225.5]:22534
	"HELO topsns.toshiba-tops.co.jp") by linux-mips.org with SMTP
	id <S8225353AbUAVKbC>; Thu, 22 Jan 2004 10:31:02 +0000
Received: from no.name.available by topsns.toshiba-tops.co.jp
          via smtpd (for mail.linux-mips.org [62.254.210.162]) with SMTP; 22 Jan 2004 10:31:51 UT
Received: from localhost (fragile [172.17.28.65])
	by srd2sd.toshiba-tops.co.jp (8.12.10/8.12.10) with ESMTP id i0MAVg1x067812;
	Thu, 22 Jan 2004 19:31:42 +0900 (JST)
	(envelope-from anemo@mba.ocn.ne.jp)
Date: Thu, 22 Jan 2004 19:32:27 +0900 (JST)
Message-Id: <20040122.193227.28780052.nemoto@toshiba-tops.co.jp>
To: ralf@linux-mips.org
Cc: dimitri@sonycom.com, linux-mips@linux-mips.org
Subject: Re: access_ok and CONFIG_MIPS32 for 2.6
From: Atsushi Nemoto <anemo@mba.ocn.ne.jp>
In-Reply-To: <20040104210327.GA15475@sonycom.com>
	<20040122024529Z8224936-9616+669@linux-mips.org>
	<20040104.210532.74756709.anemo@mba.ocn.ne.jp>
References: <20040102194403.GB31092@linux-mips.org>
	<20040104.210532.74756709.anemo@mba.ocn.ne.jp>
	<20040104210327.GA15475@sonycom.com>
X-Fingerprint: 6ACA 1623 39BD 9A94 9B1A  B746 CA77 FE94 2874 D52F
X-Pgp-Public-Key: http://wwwkeys.pgp.net/pks/lookup?op=get&search=0x2874D52F
X-Mailer: Mew version 2.2 on Emacs 21.2 / Mule 5.0 (SAKAKI)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Return-Path: <anemo@mba.ocn.ne.jp>
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: 4102
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: anemo@mba.ocn.ne.jp
Precedence: bulk
X-list: linux-mips
Content-Length: 1352
Lines: 37

>>>>> On Sun, 4 Jan 2004 22:03:27 +0100, Dimitri Torfs <dimitri@sonycom.com> said:
>> It seems there should be another definition of USER_DS for
>> CONFIG_MIPS32 in 2.6.

dimitri> Yes, I'm setting USER_DS to 0x80000000 for CONFIG_MIPS32:

Now we can see this fix in CVS 2.6 tree (Thank you, Ralf).

Then, how about this one?

>>>>> On Sun, 04 Jan 2004 21:05:32 +0900 (JST), Atsushi Nemoto <anemo@mba.ocn.ne.jp> said:
> Second, __access_ok for 64bit kernel is broken both 2.4 and 2.6.  It
> returns 0 if 'addr' + 'size' == TASK_SIZE (which should be OK).
> 
> 2.4 mips64:
> #define __access_ok(addr, size, mask)					\
> 	(((mask) & ((addr) | ((addr) + (size)) | __ua_size(size))) == 0)
> 2.6:
> #define __access_ok(addr, size, mask)					\
> 	(((signed long)((mask) & ((addr) | ((addr) + (size)) | __ua_size(size)))) == 0)
> 
> I think these macros should be:
> 
> 2.4 mips64:
> #define __access_ok(addr, size, mask)					\
> 	(((mask) & ((addr) | ((addr) + (size) - 1) | __ua_size(size))) == 0)
> 2.6:
> #define __access_ok(addr, size, mask)					\
> 	(((signed long)((mask) & ((addr) | ((addr) + (size) - 1) | __ua_size(size)))) == 0)


For example, currently, access_ok(0xfffffff000UL, 0x1000) will return
0.  This must be legal (and this is a real problem for n64 mount
syscall which may grab user stack.  See copy_mount_option()).

---
Atsushi Nemoto

From ralf@linux-mips.org Thu Jan 22 12:28:39 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 22 Jan 2004 12:28:39 +0000 (GMT)
Received: from p508B765F.dip.t-dialin.net ([IPv6:::ffff:80.139.118.95]:9027
	"EHLO mail.linux-mips.net") by linux-mips.org with ESMTP
	id <S8224908AbUAVM2j>; Thu, 22 Jan 2004 12:28:39 +0000
Received: from fluff.linux-mips.net (fluff.linux-mips.net [127.0.0.1])
	by mail.linux-mips.net (8.12.8/8.12.8) with ESMTP id i0MCSaex013114;
	Thu, 22 Jan 2004 13:28:36 +0100
Received: (from ralf@localhost)
	by fluff.linux-mips.net (8.12.8/8.12.8/Submit) id i0MCSXZq013113;
	Thu, 22 Jan 2004 13:28:33 +0100
Date: Thu, 22 Jan 2004 13:28:32 +0100
From: Ralf Baechle <ralf@linux-mips.org>
To: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Jun Sun <jsun@mvista.com>,
	Linux/MIPS Development <linux-mips@linux-mips.org>
Subject: Re: [PATCH 2.6] set up conswitchp when CONFIG_VT is set
Message-ID: <20040122122832.GA4482@linux-mips.org>
References: <20040121162032.F29705@mvista.com> <Pine.GSO.4.58.0401221052100.1408@waterleaf.sonytel.be>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Pine.GSO.4.58.0401221052100.1408@waterleaf.sonytel.be>
User-Agent: Mutt/1.4.1i
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: 4103
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
Content-Length: 498
Lines: 17

On Thu, Jan 22, 2004 at 10:52:59AM +0100, Geert Uytterhoeven wrote:

> | +#ifdef CONFIG_VT
> | +#if defined(CONFIG_VGA_CONSOLE)
> | +        conswitchp = &vga_con;
> | +#elif defined(CONFIG_DUMMY_CONSOLE)
> | +        conswitchp = &dummy_con;
> | +#endif
> | +#endif
> 
> Isn't the #ifdef CONFIG_VT superfluous?

No; if CONFIG_VT is undefined conswitchp is undefined also; DUMMY_CONSOLE
however is still selectable if CONFIG_VT is off so there could be
unsatisfied references to consitchp.

  ralf

From geert@linux-m68k.org Thu Jan 22 12:33:01 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 22 Jan 2004 12:33:01 +0000 (GMT)
Received: from witte.sonytel.be ([IPv6:::ffff:80.88.33.193]:21894 "EHLO
	witte.sonytel.be") by linux-mips.org with ESMTP id <S8224908AbUAVMdB>;
	Thu, 22 Jan 2004 12:33:01 +0000
Received: from waterleaf.sonytel.be (localhost [127.0.0.1])
	by witte.sonytel.be (8.12.10/8.12.10) with ESMTP id i0MCWww2025974;
	Thu, 22 Jan 2004 13:32:58 +0100 (MET)
Date: Thu, 22 Jan 2004 13:32:58 +0100 (MET)
From: Geert Uytterhoeven <geert@linux-m68k.org>
To: Ralf Baechle <ralf@linux-mips.org>
cc: Jun Sun <jsun@mvista.com>,
	Linux/MIPS Development <linux-mips@linux-mips.org>
Subject: Re: [PATCH 2.6] set up conswitchp when CONFIG_VT is set
In-Reply-To: <20040122122832.GA4482@linux-mips.org>
Message-ID: <Pine.GSO.4.58.0401221331160.1408@waterleaf.sonytel.be>
References: <20040121162032.F29705@mvista.com> <Pine.GSO.4.58.0401221052100.1408@waterleaf.sonytel.be>
 <20040122122832.GA4482@linux-mips.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <geert@linux-m68k.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: 4104
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
Content-Length: 1145
Lines: 32

On Thu, 22 Jan 2004, Ralf Baechle wrote:
> On Thu, Jan 22, 2004 at 10:52:59AM +0100, Geert Uytterhoeven wrote:
> > | +#ifdef CONFIG_VT
> > | +#if defined(CONFIG_VGA_CONSOLE)
> > | +        conswitchp = &vga_con;
> > | +#elif defined(CONFIG_DUMMY_CONSOLE)
> > | +        conswitchp = &dummy_con;
> > | +#endif
> > | +#endif
> >
> > Isn't the #ifdef CONFIG_VT superfluous?
>
> No; if CONFIG_VT is undefined conswitchp is undefined also; DUMMY_CONSOLE
> however is still selectable if CONFIG_VT is off so there could be
> unsatisfied references to consitchp.

DUMMY_CONSOLE can be set in drivers/video/console/Kconfig only.
drivers/video/console/Kconfig is included by drivers/video/Kconfig only, and
its inclusion depends on VT.
Hence the #ifdef CONFIG_VT is superfluous, unless the above isn't true for the
MIPS tree (I checked plain 2.6.1).

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 BlakesleeS@embeddedplanet.com Thu Jan 22 14:57:58 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 22 Jan 2004 14:57:58 +0000 (GMT)
Received: from adsl-67-38-239-110.dsl.bcvloh.ameritech.net ([IPv6:::ffff:67.38.239.110]:48335
	"EHLO mail.embeddedplanet.com") by linux-mips.org with ESMTP
	id <S8225382AbUAVO55>; Thu, 22 Jan 2004 14:57:57 +0000
Received: by ORION with Internet Mail Service (5.5.2653.19)
	id <DMF94XTA>; Thu, 22 Jan 2004 09:59:07 -0500
Message-ID: <D73A25AA6E54D511AD74009027B1110F5BB016@ORION>
From: Steven Blakeslee <BlakesleeS@embeddedplanet.com>
To: "'linux-mips@linux-mips.org'" <linux-mips@linux-mips.org>
Subject: which distribution to use?
Date: Thu, 22 Jan 2004 09:59:06 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Return-Path: <BlakesleeS@embeddedplanet.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: 4105
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: BlakesleeS@embeddedplanet.com
Precedence: bulk
X-list: linux-mips
Content-Length: 299
Lines: 7

I was hoping someone could recommend which MIPS Distributions to use to
cross compile a MIPS kernel.  The host computer is x86 running Redhat and
the target is an Embedded MIPS system.  The distrubtions that I was looking
at seem to be for a mips system running Redhat.

Thank you,
Steve Blakeslee 

From macro@ds2.pg.gda.pl Thu Jan 22 16:10:25 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 22 Jan 2004 16:10:26 +0000 (GMT)
Received: from jurand.ds.pg.gda.pl ([IPv6:::ffff:153.19.208.2]:23523 "EHLO
	jurand.ds.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8225379AbUAVQKZ>; Thu, 22 Jan 2004 16:10:25 +0000
Received: by jurand.ds.pg.gda.pl (Postfix, from userid 1011)
	id 79BAC478A5; Thu, 22 Jan 2004 17:10:23 +0100 (CET)
Received: from localhost (localhost [127.0.0.1])
	by jurand.ds.pg.gda.pl (Postfix) with ESMTP
	id 661DC47626; Thu, 22 Jan 2004 17:10:23 +0100 (CET)
Date: Thu, 22 Jan 2004 17:10:23 +0100 (CET)
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To: Dimitri Torfs <dimitri@sonycom.com>
Cc: linux-mips@linux-mips.org
Subject: Re: Support for newer gcc/gas options
In-Reply-To: <20040121183551.GA21411@sonycom.com>
Message-ID: <Pine.LNX.4.55.0401221700510.16353@jurand.ds.pg.gda.pl>
References: <20031223114644.GA5458@sonycom.com>
 <Pine.LNX.4.55.0312231303030.27594@jurand.ds.pg.gda.pl>
 <Pine.LNX.4.55.0401201332080.12841@jurand.ds.pg.gda.pl> <20040120204026.GA9470@sonycom.com>
 <Pine.LNX.4.55.0401211449170.11137@jurand.ds.pg.gda.pl> <20040121145120.GA14288@sonycom.com>
 <20040121183551.GA21411@sonycom.com>
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: 4106
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
Content-Length: 4393
Lines: 106

On Wed, 21 Jan 2004, Dimitri Torfs wrote:

> Compiler choked on the first file it tries to compile: gcc added
> -mips1 automatically to the as command line which conflicts with the
> -Wa,--trap option:
> 
> /usr/local/lib/gcc-lib/mips-linux/3.2.2/../../../../mips-linux/bin/as
>  -G 0 -O2 -g0 -32 -march=r4100 -v -mips1 -non_shared -32 -march=r4100
>  --trap -o scripts/.tmp_empty.o -
> Assembler messages:
> Error: trap exception not supported at ISA 1
> 
> Removing the line which unsets the gas_isa option makes it work again:
> /usr/local/lib/gcc-lib/mips-linux/3.2.2/../../../../mips-linux/bin/as
> -G 0 -O2 -g0 -32 -march=r4100 -v -mips1 -non_shared -32 -march=r4100
> -mips3 --trap -o scripts/.tmp_empty.o

 Thanks for digging into it.  Actually after fixing the typos I've noticed
gcc 2.95.4 always implies the ISA from the ABI unless overridden and
-mabi=64 implies -mips4, so it bails out with -march/-mcpu set to
something like r4600.  This also proves the uncertainity about what's
passed to gas and so far including an ISA specification in gas settings is
tolerable if carefully chosen.  So here's a set of new updates -- now the
ISA specifier is removed from gcc flags only if it actually works and the
ISA specifier for gas is untouched.

 Hopefully this is the last attempt.  Please try it.

  Maciej

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

patch-mips-2.4.23-20031209-mabi-8
diff -up --recursive --new-file linux-mips-2.4.23-20031209.macro/arch/mips/Makefile linux-mips-2.4.23-20031209/arch/mips/Makefile
--- linux-mips-2.4.23-20031209.macro/arch/mips/Makefile	2003-12-22 02:35:03.000000000 +0000
+++ linux-mips-2.4.23-20031209/arch/mips/Makefile	2004-01-21 23:53:31.000000000 +0000
@@ -98,6 +98,11 @@ while :; do \
 	gas_abi=; gas_opt=; gas_cpu=; gas_isa=; \
 	break; \
 done; \
+if test "$$gcc_opt" = -march= && test -n "$$gcc_abi"; then \
+	$(CC) $$gcc_abi $$gcc_opt$$gcc_cpu -S -o /dev/null \
+		-xc /dev/null > /dev/null 2>&1 && \
+		gcc_isa=; \
+fi; \
 echo $$gcc_abi $$gcc_opt$$gcc_cpu $$gcc_isa $$gas_abi $$gas_opt$$gas_cpu $$gas_isa)
 
 #
diff -up --recursive --new-file linux-mips-2.4.23-20031209.macro/arch/mips64/Makefile linux-mips-2.4.23-20031209/arch/mips64/Makefile
--- linux-mips-2.4.23-20031209.macro/arch/mips64/Makefile	2003-12-22 02:32:44.000000000 +0000
+++ linux-mips-2.4.23-20031209/arch/mips64/Makefile	2004-01-21 23:53:25.000000000 +0000
@@ -37,7 +37,7 @@ endif
 # crossformat linking we rely on the elf2ecoff tool for format conversion.
 #
 GCCFLAGS	:= -I $(TOPDIR)/include/asm/gcc
-GCCFLAGS	+= -mabi=64 -G 0 -mno-abicalls -fno-pic -Wa,--trap -pipe
+GCCFLAGS	+= -G 0 -mno-abicalls -fno-pic -Wa,--trap -pipe
 GCCFLAGS	+= $(call check_gcc, -finline-limit=100000,)
 LINKFLAGS	+= -G 0 -static # -N
 MODFLAGS	+= -mlong-calls
@@ -76,6 +76,7 @@ while :; do \
 	done; \
 	break; \
 done; \
+gcc_abi=-mabi=64; \
 gcc_cpu=$$cpu; gcc_isa=$$isa; \
 gas_cpu=$$cpu; gas_isa=-Wa,$$isa; \
 while :; do \
@@ -87,7 +88,12 @@ while :; do \
 	gas_opt=; gas_cpu=; gas_isa=; \
 	break; \
 done; \
-echo $$gcc_opt$$gcc_cpu $$gcc_isa $$gas_opt$$gas_cpu $$gas_isa)
+if test "$$gcc_opt" = -march=; then \
+	$(CC) $$gcc_abi $$gcc_opt$$gcc_cpu -S -o /dev/null \
+		-xc /dev/null > /dev/null 2>&1 && \
+		gcc_isa=; \
+fi; \
+echo $$gcc_abi $$gcc_opt$$gcc_cpu $$gcc_isa $$gas_opt$$gas_cpu $$gas_isa)
 
 #
 # CPU-dependent compiler/assembler options for optimization.

patch-mips-2.6.0-20040108-mabi-8
diff -up --recursive --new-file linux-mips-2.6.0-20040108.macro/arch/mips/Makefile linux-mips-2.6.0-20040108/arch/mips/Makefile
--- linux-mips-2.6.0-20040108.macro/arch/mips/Makefile	2004-01-07 04:56:39.000000000 +0000
+++ linux-mips-2.6.0-20040108/arch/mips/Makefile	2004-01-21 23:53:58.000000000 +0000
@@ -108,9 +108,14 @@ while :; do \
 	gas_abi=; gas_opt=; gas_cpu=; gas_isa=; \
 	break; \
 done; \
-if test x$(gcc-abi) != x$(gas-abi); then \
+if test "$(gcc-abi)" != "$(gas-abi)"; then \
 	gas_abi="-Wa,-$(gas-abi) -Wa,-mgp$(gcc-abi)"; \
 fi; \
+if test "$$gcc_opt" = -march= && test -n "$$gcc_abi"; then \
+	$(CC) $$gcc_abi $$gcc_opt$$gcc_cpu -S -o /dev/null \
+		-xc /dev/null > /dev/null 2>&1 && \
+		gcc_isa=; \
+fi; \
 echo $$gcc_abi $$gcc_opt$$gcc_cpu $$gcc_isa $$gas_abi $$gas_opt$$gas_cpu $$gas_isa)
 
 #

From sjhill@realitydiluted.com Thu Jan 22 16:15:55 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 22 Jan 2004 16:15:55 +0000 (GMT)
Received: from eth13.com-link.com ([IPv6:::ffff:208.242.241.164]:41927 "EHLO
	real.realitydiluted.com") by linux-mips.org with ESMTP
	id <S8225379AbUAVQPz>; Thu, 22 Jan 2004 16:15:55 +0000
Received: from localhost ([127.0.0.1] helo=realitydiluted.com)
	by real.realitydiluted.com with esmtp (Exim 3.36 #1 (Debian))
	id 1AjhUo-0008FE-00; Thu, 22 Jan 2004 10:15:54 -0600
Message-ID: <400FF736.9070305@realitydiluted.com>
Date: Thu, 22 Jan 2004 11:15:50 -0500
From: "Steven J. Hill" <sjhill@realitydiluted.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031107 Debian/1.5-3
X-Accept-Language: en
MIME-Version: 1.0
To: "Young Chul Park (Patrick)" <pypark@nayna.com>
CC: "'linux-mips@linux-mips.org'" <linux-mips@linux-mips.org>
Subject: Re: Linux 2.4.18 MIPS (5KC) Crash after rc.sysinit
References: <DFDD2BC6A4D8D711B8980090279CF95B017708@atomant.nayna.com>
In-Reply-To: <DFDD2BC6A4D8D711B8980090279CF95B017708@atomant.nayna.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Return-Path: <sjhill@realitydiluted.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: 4107
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: sjhill@realitydiluted.com
Precedence: bulk
X-list: linux-mips
Content-Length: 119
Lines: 5

PLEASE! Provide the symbols for your crash dump!!! We cannot
help you if you just give us plain hex values!!!

-Steve


From ilya@theIlya.com Thu Jan 22 16:33:52 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 22 Jan 2004 16:33:52 +0000 (GMT)
Received: from [IPv6:::ffff:66.151.148.199] ([IPv6:::ffff:66.151.148.199]:7687
	"EHLO eagle.qarbon.com") by linux-mips.org with ESMTP
	id <S8225379AbUAVQdw>; Thu, 22 Jan 2004 16:33:52 +0000
Received: (qmail 13589 invoked from network); 22 Jan 2004 16:33:41 -0000
Received: from unknown (HELO iluxa.qarbon.com) (ilya@192.168.2.44)
  by eagle.qarbon.com with RC4-MD5 encrypted SMTP; 22 Jan 2004 16:33:41 -0000
Subject: Re: Linux 2.4.18 MIPS (5KC) Crash after rc.sysinit
From: "Ilya A. Volynets-Evenbakh" <ilya@theIlya.com>
To: "Steven J. Hill" <sjhill@realitydiluted.com>
Cc: "Young Chul Park (Patrick)" <pypark@nayna.com>,
	"'linux-mips@linux-mips.org'" <linux-mips@linux-mips.org>
In-Reply-To: <400FF736.9070305@realitydiluted.com>
References: <DFDD2BC6A4D8D711B8980090279CF95B017708@atomant.nayna.com>
	 <400FF736.9070305@realitydiluted.com>
Content-Type: text/plain
Organization: Total Knowledge
Message-Id: <1074789220.6096.104.camel@iluxa.qarbon.com>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.4.5 
Date: Thu, 22 Jan 2004 08:33:41 -0800
Content-Transfer-Encoding: 7bit
Return-Path: <ilya@theIlya.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: 4108
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
Content-Length: 315
Lines: 14

Should we add this runt to Oops output?
;-)
On Thu, 2004-01-22 at 08:15, Steven J. Hill wrote:
> PLEASE! Provide the symbols for your crash dump!!! We cannot
> help you if you just give us plain hex values!!!
> 
> -Steve
> 
-- 
Ilya Volynets
Total Knowledge
Chief Technology Officer
http://www.total-knowledge.com


From drow@crack.them.org Thu Jan 22 20:12:17 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 22 Jan 2004 20:12:18 +0000 (GMT)
Received: from nevyn.them.org ([IPv6:::ffff:66.93.172.17]:49826 "EHLO
	nevyn.them.org") by linux-mips.org with ESMTP id <S8224954AbUAVUMR>;
	Thu, 22 Jan 2004 20:12:17 +0000
Received: from drow by nevyn.them.org with local (Exim 4.30 #1 (Debian))
	id 1AjlBR-0006ar-Q8; Thu, 22 Jan 2004 15:12:09 -0500
Date: Thu, 22 Jan 2004 15:12:09 -0500
From: Daniel Jacobowitz <dan@debian.org>
To: Nathan Field <ndf@ghs.com>
Cc: Kumba <kumba@gentoo.org>, linux-mips@linux-mips.org
Subject: Re: Solving the cross-compiler issue (Was: Trouble compiling MIPS cross-compiler)
Message-ID: <20040122201209.GA11587@nevyn.them.org>
References: <400A1B5F.6010307@gentoo.org> <Pine.LNX.4.44.0401211633240.31973-101000@zcar.ghs.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Pine.LNX.4.44.0401211633240.31973-101000@zcar.ghs.com>
User-Agent: Mutt/1.5.1i
Return-Path: <drow@crack.them.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: 4109
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: dan@debian.org
Precedence: bulk
X-list: linux-mips
Content-Length: 2084
Lines: 52

On Wed, Jan 21, 2004 at 06:32:23PM -0800, Nathan Field wrote:
> This email is a bit long so here's the short version:
> 	Building cross tools is basically impossible without knowledge 
> which isn't available on the www.linux-mips.org web site
> 	glibc seems to have obvious syntax errors and won't even compile
> 	The prebuilt tools referenced in the FAQ are so out of date 
> they're useless
> 	Even tools provided by various commercial Linux vendors are out of 
> date (at least what MontaVista lets us see in their preview kits)

Try a different preview kit.  I'm told that some of the MIPS preview
kits were updated for 3.0 and some weren't, and that's all I know about
that.

> 	This could all be solved if someone wrote a script to do all the 
> work which contains all the logic necessary to get a known set of tools to 
> build
> 
> I've written a script which will do all the work, but because there are 

You _HAVE_ looked at crosstool, right?  Which does all of this, and
does work?

> sscanf (s, format)
>      const char *s;
>      const char *format;
> 
> Doesn't match the function, and it should be:
> 
> sscanf (const char *s, const char *format, ...)
> 
> Does no one even bother to test to see if these things compile before they 
> are released? I've had similar syntax error type problems when building 
> several older (2.2.x) versions of glibc for PPC.

Come on, think.  Glibc 2.3.2 was released before GCC 3.3.  It built at
the time; if you use GCC 3.2 that will compile.  If you want to use GCC
3.3, then use a newer CVS snapshot of glibc.  Which I recommend, but is
still not for the faint of heart.  If you're just trying to build a
kernel as you said later, why are you building glibc anyway?

> Anyway, after I fixed that I now get a link failure:
> 
> /space1/ndf/linux/mips/tools/glibc-build/elf/ld.so.1: undefined reference 
> to `elf_machine_rela.7'

Google will be delighted to explain the controversy of
-finline-limit-10000 to you.  Or use crosstool :)

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

From kumba@gentoo.org Thu Jan 22 20:30:14 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 22 Jan 2004 20:30:15 +0000 (GMT)
Received: from rwcrmhc11.comcast.net ([IPv6:::ffff:204.127.198.35]:18917 "EHLO
	rwcrmhc11.comcast.net") by linux-mips.org with ESMTP
	id <S8225581AbUAVUaO>; Thu, 22 Jan 2004 20:30:14 +0000
Received: from gentoo.org (pcp04939029pcs.waldrf01.md.comcast.net[68.48.72.58])
          by comcast.net (rwcrmhc11) with SMTP
          id <20040122203007013008n8iae>
          (Authid: kumba12345);
          Thu, 22 Jan 2004 20:30:07 +0000
Message-ID: <4010334A.5050500@gentoo.org>
Date: Thu, 22 Jan 2004 15:32:10 -0500
From: Kumba <kumba@gentoo.org>
Reply-To: kumba@gentoo.org
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: linux-mips@linux-mips.org
Subject: Re: Solving the cross-compiler issue (Was: Trouble compiling MIPS
 cross-compiler)
References: <Pine.LNX.4.44.0401211633240.31973-101000@zcar.ghs.com>
In-Reply-To: <Pine.LNX.4.44.0401211633240.31973-101000@zcar.ghs.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Return-Path: <kumba@gentoo.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: 4110
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: kumba@gentoo.org
Precedence: bulk
X-list: linux-mips
Content-Length: 4533
Lines: 116

Nathan Field wrote:

> This email is a bit long so here's the short version:
> 	Building cross tools is basically impossible without knowledge 
> which isn't available on the www.linux-mips.org web site
> 	glibc seems to have obvious syntax errors and won't even compile
> 	The prebuilt tools referenced in the FAQ are so out of date 
> they're useless
> 	Even tools provided by various commercial Linux vendors are out of 
> date (at least what MontaVista lets us see in their preview kits)
> 	This could all be solved if someone wrote a script to do all the 
> work which contains all the logic necessary to get a known set of tools to 
> build
> 
> I've written a script which will do all the work, but because there are 
> failures in building glibc it doesn't work. If someone could help me get 
> my script to work it could be used to update the cross compile section of 
> the FAQ. The script as it stands is attached. It needs some configuration 
> (which is why it exits by default), but if you're trying to build a cross 
> compiler you'd better have at least some knowledge of what you're doing.
> 
> Here's what it does:
> 	it wgets specific versions of binutils, gcc and glibc
> 	it sets some environment variables
> 	it uncompresses and builds the tools in the "correct" sequence 
> with the correct options
> 
> There are 2 problems with this script:
> 	1. It references a specific binutils snapshot which will probably 
> go away in a few days
> 	2. It doesn't f'ing work
> 
> That said, here's where things are breaking:
> 
> I'm also trying to build a newer cross toolchain since MontaVista doesn't
> seem to provide one recent enough to even build the linux_2_4 branch from
> the linux-mips cvs repository (it builds, but when I run it on my Malta
> board it crashes immediately). I'm coming up against problems that just
> seem stupidly obvious... Enough ranting though, here are the details.
> 

I also coded my own cross-compiler script, which is partially integrated 
with gentoo's package management system, portage.  It uses the portage 
API to determine the most recent version, download, and patch sources, 
then the script takes over the building process.  It's not flawless, but 
it does work for generating mips[el] cross-compilers on i686 and 
linux-sparc64 hosts (among other targets).

If anyone runs gentoo, it's available as sys-devel/crossdev in the 
portage tree.


> Kumba suggested using:
> 
>>I'd recommend the following:
>>binutils-2.14.90.0.7 (or you can try the latest .8 release, it has some 
>>more mips fixes in it)
>>glibc-2.3.2 (or 2.3.1)
>>gcc-3.3.2
> 
> 	I couldn't find a version of binutils like that, so I grabbed 
> yesterdays snapshot, which builds and runs fine. Then I built the gcc 
> bootstrap fine. Then I tried building glibc-2.3.2. That failed when it got 
> to stdio-common/sscanf. The declaration of sscanf:

That version of binutils is a linux-only release maintained by HJ Lu. 
He even announces new versions to this list.  You can find all the 
versions of this specific branch of binutils at:
http://www.kernel.org/pub/linux/devel/binutils/


> sscanf (s, format)
>      const char *s;
>      const char *format;
> 
> Doesn't match the function, and it should be:
> 
> sscanf (const char *s, const char *format, ...)
> 
> Does no one even bother to test to see if these things compile before they 
> are released? I've had similar syntax error type problems when building 
> several older (2.2.x) versions of glibc for PPC.

This was a bug in early versions of glibc I believe, and is fixed in any 
modern glibc checkout you do from the libc-alpha CVS.


> Anyway, after I fixed that I now get a link failure:
> 
> /space1/ndf/linux/mips/tools/glibc-build/elf/ld.so.1: undefined reference 
> to `elf_machine_rela.7'
> 
> The command which generates this is:

[snip]

> Interestingly when I try glibc 2.3.1 I get the same syntax error in sscanf 
> but the linker complains about elf_machine_rela, without the .7.
> 
> It would be wonderful if I could get some help on this. It seems like a
> chicken and egg problem which will only get worse as more and more people
> try to build the 2.6 kernels.

Another glibc bug, also fixed in modern CVS.  The patch that does fix 
the issue is here:
http://honk.physik.uni-konstanz.de/linux-mips/glibc/patches/applied/elf-machine-rela-mips.dpatch



--Kumba

-- 
"Such is oft the course of deeds that move the wheels of the world: 
small hands do them because they must, while the eyes of the great are 
elsewhere."  --Elrond


From ralf@linux-mips.org Thu Jan 22 22:18:27 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 22 Jan 2004 22:18:28 +0000 (GMT)
Received: from p508B765F.dip.t-dialin.net ([IPv6:::ffff:80.139.118.95]:61514
	"EHLO mail.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225588AbUAVWS1>; Thu, 22 Jan 2004 22:18:27 +0000
Received: from fluff.linux-mips.net (fluff.linux-mips.net [127.0.0.1])
	by mail.linux-mips.net (8.12.8/8.12.8) with ESMTP id i0MMIPex024472;
	Thu, 22 Jan 2004 23:18:25 +0100
Received: (from ralf@localhost)
	by fluff.linux-mips.net (8.12.8/8.12.8/Submit) id i0MMIK8D024471;
	Thu, 22 Jan 2004 23:18:20 +0100
Date: Thu, 22 Jan 2004 23:18:20 +0100
From: Ralf Baechle <ralf@linux-mips.org>
To: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Jun Sun <jsun@mvista.com>,
	Linux/MIPS Development <linux-mips@linux-mips.org>
Subject: Re: [PATCH 2.6] set up conswitchp when CONFIG_VT is set
Message-ID: <20040122221820.GA23391@linux-mips.org>
References: <20040121162032.F29705@mvista.com> <Pine.GSO.4.58.0401221052100.1408@waterleaf.sonytel.be> <20040122122832.GA4482@linux-mips.org> <Pine.GSO.4.58.0401221331160.1408@waterleaf.sonytel.be>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Pine.GSO.4.58.0401221331160.1408@waterleaf.sonytel.be>
User-Agent: Mutt/1.4.1i
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: 4111
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
Content-Length: 487
Lines: 12

On Thu, Jan 22, 2004 at 01:32:58PM +0100, Geert Uytterhoeven wrote:

> DUMMY_CONSOLE can be set in drivers/video/console/Kconfig only.
> drivers/video/console/Kconfig is included by drivers/video/Kconfig only, and
> its inclusion depends on VT.
> Hence the #ifdef CONFIG_VT is superfluous, unless the above isn't true for the
> MIPS tree (I checked plain 2.6.1).

A few systems used to hardwire CONFIG_DUMMY_CONSOLE in their Config.in /
Kconfig.  Seem that has been fixed, good.

  Ralf

From jsun@mvista.com Thu Jan 22 22:44:08 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 22 Jan 2004 22:44:08 +0000 (GMT)
Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:765 "EHLO
	orion.mvista.com") by linux-mips.org with ESMTP id <S8225581AbUAVWoH>;
	Thu, 22 Jan 2004 22:44:07 +0000
Received: (from jsun@localhost)
	by orion.mvista.com (8.11.6/8.11.6) id i0MMi5i23622;
	Thu, 22 Jan 2004 14:44:05 -0800
Date: Thu, 22 Jan 2004 14:44:05 -0800
From: Jun Sun <jsun@mvista.com>
To: Ralf Baechle <ralf@linux-mips.org>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>,
	Linux/MIPS Development <linux-mips@linux-mips.org>,
	jsun@mvista.com
Subject: Re: [PATCH 2.6] set up conswitchp when CONFIG_VT is set
Message-ID: <20040122144405.C3573@mvista.com>
References: <20040121162032.F29705@mvista.com> <Pine.GSO.4.58.0401221052100.1408@waterleaf.sonytel.be> <20040122122832.GA4482@linux-mips.org> <Pine.GSO.4.58.0401221331160.1408@waterleaf.sonytel.be> <20040122221820.GA23391@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: <20040122221820.GA23391@linux-mips.org>; from ralf@linux-mips.org on Thu, Jan 22, 2004 at 11:18:20PM +0100
Return-Path: <jsun@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: 4112
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
Content-Length: 1073
Lines: 28

On Thu, Jan 22, 2004 at 11:18:20PM +0100, Ralf Baechle wrote:
> On Thu, Jan 22, 2004 at 01:32:58PM +0100, Geert Uytterhoeven wrote:
> 
> > DUMMY_CONSOLE can be set in drivers/video/console/Kconfig only.
> > drivers/video/console/Kconfig is included by drivers/video/Kconfig only, and
> > its inclusion depends on VT.
> > Hence the #ifdef CONFIG_VT is superfluous, unless the above isn't true for the
> > MIPS tree (I checked plain 2.6.1).
> 
> A few systems used to hardwire CONFIG_DUMMY_CONSOLE in their Config.in /
> Kconfig.  Seem that has been fixed, good.
> 

You are both right.  

In the end conswitchp needs to be set if and only if CONFIG_VT is set.  
From this regard, I think it is OK to leave this config there even if 
not all that useful given current code.

OK, I admit.  I already checked it in that way :0  If anyone is seriously
mad, I can take it out.  It does not really matter.  What really
matters is we repealed another unnecessary tax on board part.

Jun

PS. the tax repealling thing is really learned from our governer Arnold
Schwarzenegger ....


From ddaney@avtrex.com Thu Jan 22 23:20:09 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 22 Jan 2004 23:20:10 +0000 (GMT)
Received: from avtrex.com ([IPv6:::ffff:216.102.217.178]:3940 "EHLO avtrex.com")
	by linux-mips.org with ESMTP id <S8225592AbUAVXUJ>;
	Thu, 22 Jan 2004 23:20:09 +0000
Received: from avtrex.com ([192.168.0.111] RDNS failed) by avtrex.com with Microsoft SMTPSVC(5.0.2195.6713);
	 Thu, 22 Jan 2004 15:20:06 -0800
Message-ID: <40105A6F.3060009@avtrex.com>
Date: Thu, 22 Jan 2004 15:19:11 -0800
From: David Daney <ddaney@avtrex.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.1) Gecko/20031030
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: linux-mips@linux-mips.org
Subject: Lossage do to #ifndef __ASSEMBLY__ in mipsregs.h
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 22 Jan 2004 23:20:06.0115 (UTC) FILETIME=[452AA330:01C3E13E]
Return-Path: <ddaney@avtrex.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: 4113
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: ddaney@avtrex.com
Precedence: bulk
X-list: linux-mips
Content-Length: 1881
Lines: 66

I am using gcc 3.3.1 to compile the linux_2_4 kernel obtained from cvs a 
couple of days ago.

My gcc defines these assemble related macros:

[daney@dl xilleon]$ mipsel-linux-gcc -D__KERNEL__ 
-I/newdisk/programs/linux-mips.org/linux/include -Wall 
-Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common 
-fomit-frame-pointer -I 
/newdisk/programs/linux-mips.org/linux/include/asm/gcc -G 0 
-mno-abicalls -fno-pic -finline-limit=100000 -mabi=32 -march=mips32 
-mips32 -Wa,-32 -Wa,-march=mips32 -Wa,-mips32 -Wa,--trap  
-DLINUX_RAM_START=0x80100000 -dM -E -c xilleonIRQ.S | grep ASS
#define __ASSEMBLER__ 1
#define LANGUAGE_ASSEMBLY 1
#define __LANGUAGE_ASSEMBLY 1
#define __LANGUAGE_ASSEMBLY__ 1
#define _LANGUAGE_ASSEMBLY 1

Now in mipsregs.h we have:
.
.
.
#ifndef __ASSEMBLY__
.
.
.

So I get a ton of errors trying to assemble the file.

Now back on 2002/06/27 we have:

===================================================================
RCS file: /home/cvs/linux/include/asm-mips/mipsregs.h,v
retrieving revision 1.30.2.8
retrieving revision 1.30.2.9
diff -u -p -r1.30.2.8 -r1.30.2.9
--- linux/include/asm-mips/mipsregs.h	2002/06/27 09:53:37	1.30.2.8
+++ linux/include/asm-mips/mipsregs.h	2002/06/27 14:21:23	1.30.2.9
@@ -445,7 +445,7 @@
 #define CEB_KERNEL	2	/* Count events in kernel mode EXL = ERL = 0 */
 #define CEB_EXL		1	/* Count events with EXL = 1, ERL = 0 */
 
-#ifndef _LANGUAGE_ASSEMBLY
+#ifndef __ASSEMBLY__
 
 /*
  * Functions to access the r10k performance counter and control registers
@@ -1023,6 +1023,6 @@ do {									\
 		__disable_fpu();					\
 } while (0)
 
-#endif /* !defined (_LANGUAGE_ASSEMBLY) */
+#endif /* !__ASSEMBLY__ */
 
 #endif /* _ASM_MIPSREGS_H */

Why the change?

I will fix my local mipsregs.h so that I can continue, but it seems like 
the sources in CVS should be changed to allow gcc 3.3.1 to work.

David Daney.




From ica2_ts@csv.ica.uni-stuttgart.de Thu Jan 22 23:56:23 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 22 Jan 2004 23:56:23 +0000 (GMT)
Received: from iris1.csv.ica.uni-stuttgart.de ([IPv6:::ffff:129.69.118.2]:50279
	"EHLO iris1.csv.ica.uni-stuttgart.de") by linux-mips.org with ESMTP
	id <S8225592AbUAVX4X>; Thu, 22 Jan 2004 23:56:23 +0000
Received: from rembrandt.csv.ica.uni-stuttgart.de ([129.69.118.42])
	by iris1.csv.ica.uni-stuttgart.de with esmtp
	id 1AjogN-00030T-00; Fri, 23 Jan 2004 00:56:19 +0100
Received: from ica2_ts by rembrandt.csv.ica.uni-stuttgart.de with local (Exim 3.35 #1 (Debian))
	id 1AjogN-0000K5-00; Fri, 23 Jan 2004 00:56:19 +0100
Date: Fri, 23 Jan 2004 00:56:19 +0100
To: David Daney <ddaney@avtrex.com>
Cc: linux-mips@linux-mips.org
Subject: Re: Lossage do to #ifndef __ASSEMBLY__ in mipsregs.h
Message-ID: <20040122235619.GR23173@rembrandt.csv.ica.uni-stuttgart.de>
References: <40105A6F.3060009@avtrex.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <40105A6F.3060009@avtrex.com>
User-Agent: Mutt/1.5.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: 4114
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
Content-Length: 574
Lines: 21

David Daney wrote:
> I am using gcc 3.3.1 to compile the linux_2_4 kernel obtained from cvs a 
> couple of days ago.
[snip]
> -#endif /* !defined (_LANGUAGE_ASSEMBLY) */
> +#endif /* !__ASSEMBLY__ */
> 
> #endif /* _ASM_MIPSREGS_H */
> 
> Why the change?

__ASSEMBLY__ is defined by the Linux build system in order to have a
compiler independent test.

> I will fix my local mipsregs.h so that I can continue, but it seems like 
> the sources in CVS should be changed to allow gcc 3.3.1 to work.

It works here (for my configs). Your linux tree seems to be broken.


Thiemo

From ddaney@avtrex.com Fri Jan 23 00:03:24 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 23 Jan 2004 00:03:25 +0000 (GMT)
Received: from avtrex.com ([IPv6:::ffff:216.102.217.178]:60006 "EHLO
	avtrex.com") by linux-mips.org with ESMTP id <S8225592AbUAWADY>;
	Fri, 23 Jan 2004 00:03:24 +0000
Received: from avtrex.com ([192.168.0.111] RDNS failed) by avtrex.com with Microsoft SMTPSVC(5.0.2195.6713);
	 Thu, 22 Jan 2004 16:03:20 -0800
Message-ID: <40106492.6050400@avtrex.com>
Date: Thu, 22 Jan 2004 16:02:26 -0800
From: David Daney <ddaney@avtrex.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.1) Gecko/20031030
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Thiemo Seufer <ica2_ts@csv.ica.uni-stuttgart.de>
CC: linux-mips@linux-mips.org
Subject: Re: Lossage do to #ifndef __ASSEMBLY__ in mipsregs.h
References: <40105A6F.3060009@avtrex.com> <20040122235619.GR23173@rembrandt.csv.ica.uni-stuttgart.de>
In-Reply-To: <20040122235619.GR23173@rembrandt.csv.ica.uni-stuttgart.de>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 23 Jan 2004 00:03:20.0481 (UTC) FILETIME=[4F877910:01C3E144]
Return-Path: <ddaney@avtrex.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: 4115
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: ddaney@avtrex.com
Precedence: bulk
X-list: linux-mips
Content-Length: 870
Lines: 46

Thiemo Seufer wrote:

>David Daney wrote:
>  
>
>>I am using gcc 3.3.1 to compile the linux_2_4 kernel obtained from cvs a 
>>couple of days ago.
>>    
>>
>[snip]
>  
>
>>-#endif /* !defined (_LANGUAGE_ASSEMBLY) */
>>+#endif /* !__ASSEMBLY__ */
>>
>>#endif /* _ASM_MIPSREGS_H */
>>
>>Why the change?
>>    
>>
>
>__ASSEMBLY__ is defined by the Linux build system in order to have a
>compiler independent test.
>
I am starting to understand this.

>
>  
>
>>I will fix my local mipsregs.h so that I can continue, but it seems like 
>>the sources in CVS should be changed to allow gcc 3.3.1 to work.
>>    
>>
>
>It works here (for my configs). Your linux tree seems to be broken.
>
>
>Thiemo
>  
>
I am porting my BSP from 2.4.18 to the latest, and it seems I may have 
some Makefile incompatibility.  So I withdraw my criticism of 
defined(__ASSEMBLY__).

David Daney


From dom@mips.com Fri Jan 23 08:18:02 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 23 Jan 2004 08:18:02 +0000 (GMT)
Received: from alg145.algor.co.uk ([IPv6:::ffff:62.254.210.145]:56326 "EHLO
	dmz.algor.co.uk") by linux-mips.org with ESMTP id <S8225255AbUAWISC>;
	Fri, 23 Jan 2004 08:18:02 +0000
Received: from alg158.algor.co.uk ([62.254.210.158] helo=olympia.mips.com)
	by dmz.algor.co.uk with esmtp (Exim 3.35 #1 (Debian))
	id 1AjwR0-0001DK-00; Fri, 23 Jan 2004 08:12:58 +0000
Received: from olympia.mips.com ([192.168.192.128] helo=doms-laptop.algor.co.uk)
	by olympia.mips.com with esmtp (Exim 3.36 #1 (Debian))
	id 1AjwVY-0007cD-00; Fri, 23 Jan 2004 08:17:40 +0000
From: Dominic Sweetman <dom@mips.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <16400.55534.330161.302962@doms-laptop.algor.co.uk>
Date: Fri, 23 Jan 2004 08:18:54 +0000
To: =?iso-8859-1?q?karthikeyan=20natarajan?= <karthik_96cse@yahoo.com>
Cc: Dominic Sweetman <dom@mips.com>, linux-mips@linux-mips.org
Subject: Re: Doubt in timer interrupt
In-Reply-To: <20040122092738.52844.qmail@web10105.mail.yahoo.com>
References: <16399.36167.575161.386963@doms-laptop.algor.co.uk>
	<20040122092738.52844.qmail@web10105.mail.yahoo.com>
X-Mailer: VM 7.07 under 21.4 (patch 10) "Military Intelligence (RC5 Windows)" XEmacs Lucid
X-MTUK-Scanner: Found to be clean
X-MTUK-SpamCheck: not spam, SpamAssassin (score=-4.812, required 4, AWL,
	BAYES_00)
Return-Path: <dom@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: 4116
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
Content-Length: 424
Lines: 17


Karthi,

>     May i know the purpose of the NMI interrupt and
> in what way it differ from the timer interrupt.

On MIPS CPUs the NMI is a sort of second-class reset.  You could use
it for debugging and the kind of last-ditch everything-is-dead
watchdog interrupt you might use in a high-availability system.

Most systems don't connect it to anything.

It's not for use for regular device interrupts at all.

--
Dominic


From nlarson@Crossroads.com Fri Jan 23 15:14:55 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 23 Jan 2004 15:14:55 +0000 (GMT)
Received: from email.crossroads.com ([IPv6:::ffff:65.68.235.6]:9725 "HELO
	email.crossroads.com") by linux-mips.org with SMTP
	id <S8225397AbUAWPOz> convert rfc822-to-8bit; Fri, 23 Jan 2004 15:14:55 +0000
Received: from HQMAILNODE1.COMMSTOR.Crossroads.com ([10.5.1.42]) by email.crossroads.com with Microsoft SMTPSVC(5.0.2195.6713);
	 Fri, 23 Jan 2004 09:14:44 -0600
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 8BIT
Subject: RE: How to add more memory?
Date: Fri, 23 Jan 2004 09:14:44 -0600
Message-ID: <CFD808D1D39ACB47ABFF586D484CC52EADE218@hqmailnode1.commstor.crossroads.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: How to add more memory?
Thread-Index: AcPgf14Yc5fMqYhiQmSZ9n1ldpapWQBQqyjA
From: "Nils Larson" <nlarson@Crossroads.com>
To: "Ralf Baechle" <ralf@linux-mips.org>, <linux-mips@linux-mips.org>
X-OriginalArrivalTime: 23 Jan 2004 15:14:44.0621 (UTC) FILETIME=[A1D10BD0:01C3E1C3]
Return-Path: <nlarson@Crossroads.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: 4117
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: nlarson@Crossroads.com
Precedence: bulk
X-list: linux-mips
Content-Length: 1486
Lines: 40

Ralf,
That's for responding.
We're using the RM7000A on one platform and the RM7065C on another.
Also, how exactly does highmem work? I can't seem to find a description
of how highmem works (without reading code). I've read comments about hits
on performance using this. How much of a hit is it? Is it 
possible to DMA to this memory?
Thanks,
Nils

-----Original Message-----
From: Ralf Baechle [mailto:ralf@linux-mips.org]
Sent: Wednesday, January 21, 2004 6:28 PM
To: Nils Larson
Subject: Re: How to add more memory?


On Wed, Jan 21, 2004 at 03:58:24PM -0600, Nils Larson wrote:

> We currently have a mips platform running Linux with 256MB of
> RAM starting at 0x8000_0000. We would like to add an additional
> 1GB of RAM, maybe starting at 0x4000_0000, that would be used
> for user apps (user virtual memory). The memory map is:
> 0x8000_0000 - 256MB RAM
> 0xA000_0000 - uncached version of the same 256MB
> 0xB000_0000 - PCI memory windows.
> This is a diskless setup booting from a ramdisk.
> So, the (sort of newbie) questions are:
> 1. How do we tell Linux to use the new memory?
> 2. Is this feasible?
> 3. Is there a better way to add more memory?
> We need more space for user data.

I wrote the highmem code for Linux/MIPS.  It's currently limited
to processor configurations that don't suffer from virtual aliases but
that limitation can be removed; depending of your application and hardware
that may be anywhere from trivial to hard.   What is your processor?

  Ralf


From rathann@icm.edu.pl Fri Jan 23 16:14:23 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 23 Jan 2004 16:14:31 +0000 (GMT)
Received: from gw.icm.edu.pl ([IPv6:::ffff:212.87.0.39]:5476 "EHLO
	atol.icm.edu.pl") by linux-mips.org with ESMTP id <S8225342AbUAWQOX>;
	Fri, 23 Jan 2004 16:14:23 +0000
Received: from rekin.icm.edu.pl (rekin.icm.edu.pl [192.168.1.132])
	by atol.icm.edu.pl (8.12.6/8.12.6/rzm-4.6/icm) with ESMTP id i0NGEACM032313
	for <linux-mips@linux-mips.org>; Fri, 23 Jan 2004 17:14:10 +0100 (CET)
Received: from rathann by rekin.icm.edu.pl with local (Exim 3.35 #1 (Debian))
	id 1Ak3wg-0006Ec-00
	for <linux-mips@linux-mips.org>; Fri, 23 Jan 2004 17:14:10 +0100
Date: Fri, 23 Jan 2004 17:14:10 +0100
From: "Dominik 'Rathann' Mierzejewski" <rathann@icm.edu.pl>
To: linux-mips@linux-mips.org
Subject: Re: Current 2.4 CVS (2.4.24-pre2) doesn't boot on SGI Indy
Message-ID: <20040123161410.GC20047@icm.edu.pl>
Mail-Followup-To: linux-mips@linux-mips.org
References: <20040115141427.GA28546@icm.edu.pl> <Pine.LNX.4.21.0401151816540.3511-100000@www.marty44.net> <20040115231735.GA6619@icm.edu.pl> <4007386F.80207@gentoo.org> <20040115172602.H18368@mvista.com> <20040116115053.GA18099@icm.edu.pl> <20040120130625.GA24435@icm.edu.pl> <20040120162800.GA29792@icm.edu.pl>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20040120162800.GA29792@icm.edu.pl>
User-Agent: Mutt/1.3.28i
Return-Path: <rathann@icm.edu.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: 4118
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: rathann@icm.edu.pl
Precedence: bulk
X-list: linux-mips
Content-Length: 1003
Lines: 21

On Tue, Jan 20, 2004 at 05:28:01PM +0100, Dominik 'Rathann' Mierzejewski wrote:
> On Tue, Jan 20, 2004 at 02:06:26PM +0100, Dominik 'Rathann' Mierzejewski wrote:
> [...]
> > OK, I've narrowed it down to sometime between 20031205 and 20031214, but
> > since there were no commits between 20031204 and 20031211, it has to be one
> > of these:
> > 
> > 6242 2003/12/11 01:29:17 linux_2_4 ralf Fix a bunch of long standing bugs
> > and performance clear_page issues: - Fi .....
> [...] 
> 
> Found it! After applying the above patch, the kernel no longer goes
> past the "Freeing unused kernel memory" stage. So for now I'm sticking
> with the 20031205 kernel.

Could someone please look into this?

-- 
Dominik 'Rathann' Mierzejewski <rathann@icm.edu.pl>                                                 
Interdisciplinary Centre for Mathematical and Computational Modelling                               
Warsaw University  |  http://www.icm.edu.pl  |  tel. +48 (22) 5540810                               

From macro@ds2.pg.gda.pl Fri Jan 23 16:50:19 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 23 Jan 2004 16:50:20 +0000 (GMT)
Received: from jurand.ds.pg.gda.pl ([IPv6:::ffff:153.19.208.2]:24805 "EHLO
	jurand.ds.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8225342AbUAWQuT>; Fri, 23 Jan 2004 16:50:19 +0000
Received: by jurand.ds.pg.gda.pl (Postfix, from userid 1011)
	id EBF8D4BE10; Fri, 23 Jan 2004 17:50:17 +0100 (CET)
Received: from localhost (localhost [127.0.0.1])
	by jurand.ds.pg.gda.pl (Postfix) with ESMTP
	id DC9C6478A8; Fri, 23 Jan 2004 17:50:17 +0100 (CET)
Date: Fri, 23 Jan 2004 17:50:17 +0100 (CET)
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To: sjhill@linux-mips.org
Cc: linux-mips@linux-mips.org
Subject: Re: CVS Update@-mips.org: linux 
In-Reply-To: <20040123142002Z8225342-9616+728@linux-mips.org>
Message-ID: <Pine.LNX.4.55.0401231747490.3223@jurand.ds.pg.gda.pl>
References: <20040123142002Z8225342-9616+728@linux-mips.org>
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: 4119
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
Content-Length: 433
Lines: 15

On Fri, 23 Jan 2004 sjhill@linux-mips.org wrote:

> Modified files:
> 	include/asm-mips64: Tag: linux_2_4 cpu.h 

 The difference was deliberate.

> 	arch/mips64/kernel: Tag: linux_2_4 proc.c 

 You've downgraded ISO C initializers.

-- 
+  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 23 17:03:02 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 23 Jan 2004 17:03:03 +0000 (GMT)
Received: from jurand.ds.pg.gda.pl ([IPv6:::ffff:153.19.208.2]:23530 "EHLO
	jurand.ds.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8225419AbUAWRDC>; Fri, 23 Jan 2004 17:03:02 +0000
Received: by jurand.ds.pg.gda.pl (Postfix, from userid 1011)
	id 50D87478A8; Fri, 23 Jan 2004 18:03:01 +0100 (CET)
Received: from localhost (localhost [127.0.0.1])
	by jurand.ds.pg.gda.pl (Postfix) with ESMTP
	id 3A4A344A4C; Fri, 23 Jan 2004 18:03:01 +0100 (CET)
Date: Fri, 23 Jan 2004 18:03:01 +0100 (CET)
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To: sjhill@linux-mips.org
Cc: linux-mips@linux-mips.org
Subject: Re: CVS Update@-mips.org: linux 
In-Reply-To: <20040123165755Z8225342-9616+749@linux-mips.org>
Message-ID: <Pine.LNX.4.55.0401231801230.3223@jurand.ds.pg.gda.pl>
References: <20040123165755Z8225342-9616+749@linux-mips.org>
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: 4120
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
Content-Length: 423
Lines: 14

On Fri, 23 Jan 2004 sjhill@linux-mips.org wrote:

> Modified files:
> 	include/asm-mips64: Tag: linux_2_4 cpu.h 
> 
> Log message:
> 	Revert change *sigh*.

 But the advantage is now I know 2.6 needs to be fixed -- thanks.

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

From bridget@stretchinc.com Fri Jan 23 17:32:45 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 23 Jan 2004 17:32:45 +0000 (GMT)
Received: from sccrmhc12.comcast.net ([IPv6:::ffff:204.127.202.56]:32227 "EHLO
	sccrmhc12.comcast.net") by linux-mips.org with ESMTP
	id <S8225342AbUAWRcp>; Fri, 23 Jan 2004 17:32:45 +0000
Received: from stretchinc.com (c-24-6-127-138.client.comcast.net[24.6.127.138])
          by comcast.net (sccrmhc12) with SMTP
          id <2004012317323801200296t6e>; Fri, 23 Jan 2004 17:32:38 +0000
Message-ID: <401159BF.6000002@stretchinc.com>
Date: Fri, 23 Jan 2004 09:28:31 -0800
From: Bridget McNamara-Yeager <bridget@stretchinc.com>
User-Agent: Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: linux-mips@linux-mips.org
Subject: Unscribe this mail list
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Return-Path: <bridget@stretchinc.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: 4121
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: bridget@stretchinc.com
Precedence: bulk
X-list: linux-mips
Content-Length: 75
Lines: 5

Unscribe this mail list.  This is a second request from me, thank you.





From jiahanchen@yahoo.com Fri Jan 23 18:03:32 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 23 Jan 2004 18:03:32 +0000 (GMT)
Received: from web40801.mail.yahoo.com ([IPv6:::ffff:66.218.78.178]:5920 "HELO
	web40801.mail.yahoo.com") by linux-mips.org with SMTP
	id <S8225426AbUAWSDc>; Fri, 23 Jan 2004 18:03:32 +0000
Message-ID: <20040123180324.6255.qmail@web40801.mail.yahoo.com>
Received: from [12.39.100.98] by web40801.mail.yahoo.com via HTTP; Fri, 23 Jan 2004 10:03:24 PST
Date: Fri, 23 Jan 2004 10:03:24 -0800 (PST)
From: Jiahan Chen <jiahanchen@yahoo.com>
Subject: Re: Unscribe this mail list
To: linux-mips@linux-mips.org
In-Reply-To: <401159BF.6000002@stretchinc.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Return-Path: <jiahanchen@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: 4122
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: jiahanchen@yahoo.com
Precedence: bulk
X-list: linux-mips
Content-Length: 472
Lines: 20


I have sent to this address and management address for
un-subscription before, however, nothing happens.

The Maillist management person: Please take an action now!
Thank you!
 
--- Bridget McNamara-Yeager <bridget@stretchinc.com> wrote:
> Unscribe this mail list.  This is a second request from me, thank you.
> 
> 
> 
> 
> 


__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free web site building tool. Try it!
http://webhosting.yahoo.com/ps/sb/

From kumba@gentoo.org Fri Jan 23 18:10:22 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 23 Jan 2004 18:10:22 +0000 (GMT)
Received: from rwcrmhc13.comcast.net ([IPv6:::ffff:204.127.198.39]:32989 "EHLO
	rwcrmhc13.comcast.net") by linux-mips.org with ESMTP
	id <S8225426AbUAWSKW>; Fri, 23 Jan 2004 18:10:22 +0000
Received: from gentoo.org (pcp04939029pcs.waldrf01.md.comcast.net[68.48.72.58])
          by comcast.net (rwcrmhc13) with SMTP
          id <2004012318101501500kd6h6e>
          (Authid: kumba12345);
          Fri, 23 Jan 2004 18:10:15 +0000
Message-ID: <40116403.8020003@gentoo.org>
Date: Fri, 23 Jan 2004 13:12:19 -0500
From: Kumba <kumba@gentoo.org>
Reply-To: kumba@gentoo.org
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: linux-mips@linux-mips.org
Subject: Re: Unscribe this mail list
References: <20040123180324.6255.qmail@web40801.mail.yahoo.com>
In-Reply-To: <20040123180324.6255.qmail@web40801.mail.yahoo.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Return-Path: <kumba@gentoo.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: 4123
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: kumba@gentoo.org
Precedence: bulk
X-list: linux-mips
Content-Length: 553
Lines: 20

Jiahan Chen wrote:

> I have sent to this address and management address for
> un-subscription before, however, nothing happens.
> 
> The Maillist management person: Please take an action now!
> Thank you!

If you people would *read* the website, you'd learn how to unsubscribe 
from this ML.  It's the 21st century now, everything's automated these 
days.  (*hint* *hint*)


--Kumba

-- 
"Such is oft the course of deeds that move the wheels of the world: 
small hands do them because they must, while the eyes of the great are 
elsewhere."  --Elrond


From ilya@total-knowledge.com Fri Jan 23 20:13:18 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 23 Jan 2004 20:13:18 +0000 (GMT)
Received: from [IPv6:::ffff:66.151.148.199] ([IPv6:::ffff:66.151.148.199]:35593
	"EHLO eagle.qarbon.com") by linux-mips.org with ESMTP
	id <S8225457AbUAWUNS>; Fri, 23 Jan 2004 20:13:18 +0000
Received: (qmail 23799 invoked from network); 23 Jan 2004 20:13:07 -0000
Received: from unknown (HELO iluxa.qarbon.com) (192.168.2.44)
  by eagle.qarbon.com with RC4-MD5 encrypted SMTP; 23 Jan 2004 20:13:07 -0000
Subject: Re: Unscribe this mail list
From: "Ilya A. Volynets-Evenbakh" <ilya@total-knowledge.com>
To: Jiahan Chen <jiahanchen@yahoo.com>
Cc: linux-mips@linux-mips.org
In-Reply-To: <20040123180324.6255.qmail@web40801.mail.yahoo.com>
References: <20040123180324.6255.qmail@web40801.mail.yahoo.com>
Content-Type: text/plain
Organization: Total Knowledge
Message-Id: <1074888787.4847.21.camel@iluxa.qarbon.com>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.4.5 
Date: Fri, 23 Jan 2004 12:13:07 -0800
Content-Transfer-Encoding: 7bit
Return-Path: <ilya@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: 4124
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@total-knowledge.com
Precedence: bulk
X-list: linux-mips
Content-Length: 425
Lines: 13

Why isn't there a punishment for being stupid?

On Fri, 2004-01-23 at 10:03, Jiahan Chen wrote:
> I have sent to this address and management address for
> un-subscription before, however, nothing happens.
> 
> The Maillist management person: Please take an action now!
> Thank you!
>  
> --- Bridget McNamara-Yeager <bridget@stretchinc.com> wrote:
> > Unscribe this mail list.  This is a second request from me, thank you.



From jsun@mvista.com Sat Jan 24 02:24:43 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 24 Jan 2004 02:24:44 +0000 (GMT)
Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:34031 "EHLO
	orion.mvista.com") by linux-mips.org with ESMTP id <S8225597AbUAXCYn>;
	Sat, 24 Jan 2004 02:24:43 +0000
Received: (from jsun@localhost)
	by orion.mvista.com (8.11.6/8.11.6) id i0O2Oab00668;
	Fri, 23 Jan 2004 18:24:36 -0800
Date: Fri, 23 Jan 2004 18:24:36 -0800
From: Jun Sun <jsun@mvista.com>
To: linux-mips@linux-mips.org
Cc: jsun@mvista.com
Subject: [PATCH 2.6] 32bit module support
Message-ID: <20040123182436.C27362@mvista.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="BXVAT5kNtrzKuDFl"
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
Return-Path: <jsun@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: 4125
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
Content-Length: 5988
Lines: 232


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


I have not done extensive tests yet, but this patch appears to 
be working.  I'd appreciate people giving it a try and let me 
know how it goes.

There is one worrisome "FIXME" in that file, which is not clear
to me.  Ralf?

Jun

--BXVAT5kNtrzKuDFl
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="module-32bit.patch"

diff -Nru linux/arch/mips/kernel/module-elf32.c.orig linux/arch/mips/kernel/module-elf32.c
--- linux/arch/mips/kernel/module-elf32.c.orig	Fri Jul 25 15:49:23 2003
+++ linux/arch/mips/kernel/module-elf32.c	Fri Jan 23 17:58:42 2004
@@ -23,14 +23,11 @@
 #include <linux/string.h>
 #include <linux/kernel.h>
 
-struct mips_hi16 {
-	struct mips_hi16 *next;
+struct mips_hilo16 {
 	Elf32_Addr *addr;
 	Elf32_Addr value;
 };
 
-static struct mips_hi16 *mips_hi16_list;
-
 #if 0
 #define DEBUGP printk
 #else
@@ -78,6 +75,35 @@
 	return 0;
 }
 
+/*
+ * For the hi16, we should set ((AHL+S) - (short)(AHL+S)) >> 16
+ * For the lo16, we should set (AHL+S) & 0xffff
+ * where 
+ * 	AHL = (AHI << 16 ) + (short)ALO
+ * whereis
+ * 	AHI = *(hi16 instr loc) & 0xffff	// before reloc
+ * 	ALO = *(lo16 instr loc) & 0xffff	// before reloc
+ */
+#define	U32_TO_SHORT(x)	(((x & 0xffff) ^ 0x8000) - 0x8000)
+static void relocate_hilo16(struct mips_hilo16 *hi, struct mips_hilo16 *lo)
+{
+	u32 AHI, ALO, AHL_S, res_hi, res_lo;
+
+	AHI = *(hi->addr) & 0xffff;
+	ALO = *(lo->addr) & 0xffff;
+	AHL_S = (AHI << 16) + U32_TO_SHORT(ALO) + hi->value;
+
+	res_lo = AHL_S & 0xffff;
+	res_hi = (AHL_S >> 16) + ((res_lo & 0x8000)==0 ? 0 : 1);
+	res_hi &= 0xffff;
+
+	*hi->addr = (*hi->addr & ~0xffff) | res_hi;
+	*lo->addr = (*lo->addr & ~0xffff) | res_lo;
+}
+
+#undef KERN_ERR
+#define KERN_ERR
+
 int apply_relocate(Elf32_Shdr *sechdrs,
 		   const char *strtab,
 		   unsigned int symindex,
@@ -85,19 +111,20 @@
 		   struct module *me)
 {
 	unsigned int i;
-	Elf32_Rel *rel = (void *)sechdrs[relsec].sh_offset;
+	Elf32_Rel *rel = (void *)sechdrs[relsec].sh_addr;
 	Elf32_Sym *sym;
 	uint32_t *location;
 	Elf32_Addr v;
+	struct mips_hilo16 hi16, lo16;
 
 	DEBUGP("Applying relocate section %u to %u\n", relsec,
 	       sechdrs[relsec].sh_info);
 	for (i = 0; i < sechdrs[relsec].sh_size / sizeof(*rel); i++) {
 		/* This is where to make the change */
-		location = (void *)sechdrs[sechdrs[relsec].sh_info].sh_offset
+		location = (void *)sechdrs[sechdrs[relsec].sh_info].sh_addr
 			+ rel[i].r_offset;
 		/* This is the symbol it is referring to */
-		sym = (Elf32_Sym *)sechdrs[symindex].sh_offset
+		sym = (Elf32_Sym *)sechdrs[symindex].sh_addr
 			+ ELF32_R_SYM(rel[i].r_info);
 		if (!sym->st_value) {
 			printk(KERN_WARNING "%s: Unknown symbol %s\n",
@@ -116,99 +143,52 @@
 			break;
 
 		case R_MIPS_26:
-			if (v % 4)
+			if (v % 4) {
 				printk(KERN_ERR
 				       "module %s: dangerous relocation\n",
 				       me->name);
 				return -ENOEXEC;
+			}
 			if ((v & 0xf0000000) !=
-			    (((unsigned long)location + 4) & 0xf0000000))
+			    (((unsigned long)location + 4) & 0xf0000000)) {
 				printk(KERN_ERR
 				       "module %s: relocation overflow\n",
 				       me->name);
 				return -ENOEXEC;
+			}
 			*location = (*location & ~0x03ffffff) |
 			            ((*location + (v >> 2)) & 0x03ffffff);
 			break;
 
-		case R_MIPS_HI16: {
-			struct mips_hi16 *n;
-
+		case R_MIPS_HI16: 
 			/*
 			 * We cannot relocate this one now because we don't
 			 * know the value of the carry we need to add.  Save
 			 * the information, and let LO16 do the actual
 			 * relocation.
 			 */
-			n = (struct mips_hi16 *) kmalloc(sizeof *n, GFP_KERNEL);
-			n->addr = location;
-			n->value = v;
-			n->next = mips_hi16_list;
-			mips_hi16_list = n;
+			hi16.addr = location;
+			hi16.value = v;
 			break;
-		}
-
-		case R_MIPS_LO16: {
-			unsigned long insnlo = *location;
-			Elf32_Addr val, vallo;
-
-			/* Sign extend the addend we extract from the lo insn.  */
-			vallo = ((insnlo & 0xffff) ^ 0x8000) - 0x8000;
-
-			if (mips_hi16_list != NULL) {
-				struct mips_hi16 *l;
-
-				l = mips_hi16_list;
-				while (l != NULL) {
-					struct mips_hi16 *next;
-					unsigned long insn;
-
-					/*
-					 * The value for the HI16 had best be
-					 * the same.
-					 */
-					printk(KERN_ERR "module %s: dangerous "
-					       "relocation\n", me->name);
-					return -ENOEXEC;
-
-					/*
-					 * Do the HI16 relocation.  Note that
-					 * we actually don't need to know
-					 * anything about the LO16 itself,
-					 * except where to find the low 16 bits
-					 * of the addend needed by the LO16.
-					 */
-					insn = *l->addr;
-					val = ((insn & 0xffff) << 16) + vallo;
-					val += v;
-
-					/*
-					 * Account for the sign extension that
-					 * will happen in the low bits.
-					 */
-					val = ((val >> 16) + ((val & 0x8000) !=
-					      0)) & 0xffff;
-
-					insn = (insn & ~0xffff) | val;
-					*l->addr = insn;
-
-					next = l->next;
-					kfree(l);
-					l = next;
-				}
-
-				mips_hi16_list = NULL;
-			}
 
+		case R_MIPS_LO16: 
 			/*
-			 * Ok, we're done with the HI16 relocs.  Now deal with
-			 * the LO16.
+			 * This lo16 entry must have the same value as
+			 * the preceeding or last hi16 entry.
 			 */
-			val = v + vallo;
-			insnlo = (insnlo & ~0xffff) | (val & 0xffff);
-			*location = insnlo;
+			if (v != hi16.value) {
+				printk(KERN_ERR "module %s: HI16/LO16 value mistmatch : %08x vs %08x\n", 
+						me->name,
+						hi16.value,
+						v); 
+				return -ENOEXEC;
+			}
+
+			lo16.addr = location;
+			lo16.value = v;
+
+			relocate_hilo16(&hi16, &lo16);
 			break;
-		}
 
 		default:
 			printk(KERN_ERR "module %s: Unknown relocation: %u\n",
@@ -225,6 +205,9 @@
 		       unsigned int relsec,
 		       struct module *me)
 {
+	if (sechdrs[relsec].sh_size == 0)
+		return 0;
+
 	printk(KERN_ERR "module %s: ADD RELOCATION unsupported\n",
 	       me->name);
 	return -ENOEXEC;

--BXVAT5kNtrzKuDFl--

From repp0017@tc.umn.edu Sun Jan 25 06:37:16 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 25 Jan 2004 06:37:17 +0000 (GMT)
Received: from mhub-w5.tc.umn.edu ([IPv6:::ffff:160.94.160.35]:27389 "EHLO
	mhub-w5.tc.umn.edu") by linux-mips.org with ESMTP
	id <S8224952AbUAYGhQ>; Sun, 25 Jan 2004 06:37:16 +0000
Received: from [134.84.95.9] by mhub-w5.tc.umn.edu with ESMTP; Sun, 25 Jan 2004 00:37:14 -0600
Subject: [PATCH] Enable compilation on MIPS with gcc-3.3
From: Matthew Reppert <repp0017@tc.umn.edu>
To: ralf@gnu.org
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-m+b5o9WFFgCCWNILpxmK"
Message-Id: <1075012630.5829.333.camel@minerva>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.4.5 
Date: Sun, 25 Jan 2004 00:37:10 -0600
Return-Path: <repp0017@tc.umn.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: 4127
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: repp0017@tc.umn.edu
Precedence: bulk
X-list: linux-mips
Content-Length: 5338
Lines: 132


--=-m+b5o9WFFgCCWNILpxmK
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

Hi,

arch/mips/Makefile uses gcc's -mcpu=3D flag to pass subarchitecture
selection choices to gcc. -mcpu=3D was deprecated in gcc 3.1, and has
been removed as of gcc 3.3. We need to use -march=3D for gcc 3.x (where
x >=3D 3), but some versions of gcc don't understand -march=3D (namely
2.95.x, which some people still use.)

This patch introduces a variable in arch/mips/makefile, gcc-tune-flag,
which is "cpu" if gcc understands -mcpu and "arch" if it doesn't, and
uses it to build the -mcpu=3D/-march=3D bits in CFLAGS for each processor
type.

Matt


diff -puN arch/mips/Makefile~mips-arch arch/mips/Makefile
--- linux-2.6.2-rc1-mm2_mips/arch/mips/Makefile~mips-arch	2004-01-25 00:13:=
03.295170984 -0600
+++ linux-2.6.2-rc1-mm2_mips-arashi/arch/mips/Makefile	2004-01-25 00:23:39.=
594438792 -0600
@@ -38,6 +38,8 @@ ifdef CONFIG_CROSSCOMPILE
 CROSS_COMPILE		:=3D $(tool-prefix)
 endif
=20
+gcc-tune-flag		=3D $(shell if $(CC) -dumpspecs | grep mcpu; then echo cpu;=
 else echo arch; fi)
+
 #
 # GCC uses -G 0 -mabicalls -fpic as default.  We don't want PIC in the ker=
nel
 # code since it only slows down the whole thing.  At some point we might m=
ake
@@ -75,49 +77,49 @@ check_warning =3D $(shell if $(CC) $(1) -c
 #                A kernel built those options will only work on hardware w=
hich
 #                actually supports this ISA.
 #
-cflags-$(CONFIG_CPU_R3000)	+=3D -mcpu=3Dr3000
+cflags-$(CONFIG_CPU_R3000)	+=3D -$(gcc-tune-flag)=3Dr3000
 32bit-isa-$(CONFIG_CPU_R3000)	+=3D -mips1
 64bit-isa-$(CONFIG_CPU_R3000)	+=3D -mboom
-cflags-$(CONFIG_CPU_TX39XX)	+=3D -mcpu=3Dr3000
+cflags-$(CONFIG_CPU_TX39XX)	+=3D -$(gcc-tune-flag)=3Dr3000
 32bit-isa-$(CONFIG_CPU_TX39XX)	+=3D -mips1
 64bit-isa-$(CONFIG_CPU_TX39XX)	+=3D -mboom
-cflags-$(CONFIG_CPU_R6000)	+=3D -mcpu=3Dr6000
+cflags-$(CONFIG_CPU_R6000)	+=3D -$(gcc-tune-flag)=3Dr6000
 32bit-isa-$(CONFIG_CPU_R6000)	+=3D -mips2 -Wa,--trap
 64bit-isa-$(CONFIG_CPU_R6000)	+=3D -mboom -Wa,--trap
-cflags-$(CONFIG_CPU_R4300)	+=3D -mcpu=3Dr4300
+cflags-$(CONFIG_CPU_R4300)	+=3D -$(gcc-tune-flag)=3Dr4300
 32bit-isa-$(CONFIG_CPU_R4300)	+=3D -mips2 -Wa,--trap
 64bit-isa-$(CONFIG_CPU_R4300)	+=3D -mips3 -Wa,--trap
-cflags-$(CONFIG_CPU_VR41XX)	+=3D -mcpu=3Dr4600
+cflags-$(CONFIG_CPU_VR41XX)	+=3D -$(gcc-tune-flag)=3Dr4600
 32bit-isa-$(CONFIG_CPU_VR41XX)	+=3D -mips2 -Wa,--trap
 64bit-isa-$(CONFIG_CPU_VR41XX)	+=3D -mips3 -Wa,--trap
-cflags-$(CONFIG_CPU_R4X00)	+=3D -mcpu=3Dr4600
+cflags-$(CONFIG_CPU_R4X00)	+=3D -$(gcc-tune-flag)=3Dr4600
 32bit-isa-$(CONFIG_CPU_R4X00)	+=3D -mips2 -Wa,--trap
 64bit-isa-$(CONFIG_CPU_R4X00)	+=3D -mips3 -Wa,--trap
-cflags-$(CONFIG_CPU_MIPS32)	+=3D $(call check_gcc, -mtune=3Dmips32, -mcpu=
=3Dr4600)
+cflags-$(CONFIG_CPU_MIPS32)	+=3D $(call check_gcc, -mtune=3Dmips32, -$(gcc=
-tune-flag)=3Dr4600)
 32bit-isa-$(CONFIG_CPU_MIPS32)	+=3D $(call check_gcc, -mips32 -mabi=3D32, =
-mips2) -Wa,--trap
 64bit-isa-$(CONFIG_CPU_MIPS32)	+=3D -mboom
 cflags-$(CONFIG_CPU_MIPS64)	+=3D=20
 32bit-isa-$(CONFIG_CPU_MIPS64)	+=3D $(call check_gcc, -mips32, -mips2) -Wa=
,--trap
 64bit-isa-$(CONFIG_CPU_MIPS64)	+=3D $(call check_gcc, -mips64, -mips4) -Wa=
,--trap
-cflags-$(CONFIG_CPU_R5000)	+=3D -mcpu=3Dr8000
+cflags-$(CONFIG_CPU_R5000)	+=3D -$(gcc-tune-flag)=3Dr8000
 32bit-isa-$(CONFIG_CPU_R5000)	+=3D -mips2 -Wa,--trap
 64bit-isa-$(CONFIG_CPU_R5000)	+=3D -mips4 -Wa,--trap
-cflags-$(CONFIG_CPU_R5432)	+=3D -mcpu=3Dr5000
+cflags-$(CONFIG_CPU_R5432)	+=3D -$(gcc-tune-flag)=3Dr5000
 32bit-isa-$(CONFIG_CPU_R5432)	+=3D -mips1 -Wa,--trap
 64bit-isa-$(CONFIG_CPU_R5432)	+=3D -mips3 -Wa,--trap
-cflags-$(CONFIG_CPU_NEVADA)	+=3D -mcpu=3Dr8000 -mmad
+cflags-$(CONFIG_CPU_NEVADA)	+=3D -$(gcc-tune-flag)=3Dr8000 -mmad
 32bit-isa-$(CONFIG_CPU_NEVADA)	+=3D -mips2 -Wa,--trap
 64bit-isa-$(CONFIG_CPU_NEVADA)	+=3D -mips3 -Wa,--trap
-cflags-$(CONFIG_CPU_RM7000)	+=3D $(call check_gcc, -mcpu=3Dr7000, -mcpu=3D=
r5000)
+cflags-$(CONFIG_CPU_RM7000)	+=3D $(call check_gcc, -$(gcc-tune-flag)=3Dr70=
00, -$(gcc-tune-flag)=3Dr5000)
 32bit-isa-$(CONFIG_CPU_RM7000)	+=3D -mips2 -Wa,--trap
 64bit-isa-$(CONFIG_CPU_RM7000)	+=3D -mips4 -Wa,--trap
-cflags-$(CONFIG_CPU_SB1)	+=3D $(call check_gcc, -mcpu=3Dsb1, -mcpu=3Dr8000=
)
+cflags-$(CONFIG_CPU_SB1)	+=3D $(call check_gcc, -$(gcc-tune-flag)=3Dsb1, -=
$(gcc-tune-flag)=3Dr8000)
 32bit-isa-$(CONFIG_CPU_SB1)	+=3D $(call check_gcc, -mips32, -mips2) -Wa,--=
trap
 64bit-isa-$(CONFIG_CPU_SB1)	+=3D $(call check_gcc, -mips64, -mips4) -Wa,--=
trap
-cflags-$(CONFIG_CPU_R8000)	+=3D -mcpu=3Dr8000
+cflags-$(CONFIG_CPU_R8000)	+=3D -$(gcc-tune-flag)=3Dr8000
 32bit-isa-$(CONFIG_CPU_R8000)	+=3D -mips2 -Wa,--trap
 64bit-isa-$(CONFIG_CPU_R8000)	+=3D -mips4 -Wa,--trap
-cflags-$(CONFIG_CPU_R10000)	+=3D -mcpu=3Dr8000
+cflags-$(CONFIG_CPU_R10000)	+=3D -$(gcc-tune-flag)=3Dr8000
 32bit-isa-$(CONFIG_CPU_R10000)	+=3D -mips2 -Wa,--trap
 64bit-isa-$(CONFIG_CPU_R10000)	+=3D -mips4 -Wa,--trap
=20

_


--=-m+b5o9WFFgCCWNILpxmK
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part

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

iD8DBQBAE2QWA9ZcCXfrOTMRAh56AKChXZkilrABXcZ66fuoFY85tZ4vBACdE2fp
ezOngSPpxGvEsiRWnYfUzsc=
=dgsN
-----END PGP SIGNATURE-----

--=-m+b5o9WFFgCCWNILpxmK--


From ralf@linux-mips.org Sun Jan 25 13:46:54 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 25 Jan 2004 13:46:54 +0000 (GMT)
Received: from p508B7347.dip.t-dialin.net ([IPv6:::ffff:80.139.115.71]:54891
	"EHLO mail.linux-mips.net") by linux-mips.org with ESMTP
	id <S8224916AbUAYNqy>; Sun, 25 Jan 2004 13:46:54 +0000
Received: from fluff.linux-mips.net (fluff.linux-mips.net [127.0.0.1])
	by mail.linux-mips.net (8.12.8/8.12.8) with ESMTP id i0PDkqex018642;
	Sun, 25 Jan 2004 14:46:52 +0100
Received: (from ralf@localhost)
	by fluff.linux-mips.net (8.12.8/8.12.8/Submit) id i0PDkpLS018641;
	Sun, 25 Jan 2004 14:46:51 +0100
Date: Sun, 25 Jan 2004 14:46:51 +0100
From: Ralf Baechle <ralf@linux-mips.org>
To: Jun Sun <jsun@mvista.com>
Cc: linux-mips@linux-mips.org
Subject: Re: [PATCH 2.6] 32bit module support
Message-ID: <20040125134651.GA8209@linux-mips.org>
References: <20040123182436.C27362@mvista.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20040123182436.C27362@mvista.com>
User-Agent: Mutt/1.4.1i
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: 4128
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
Content-Length: 238
Lines: 9

On Fri, Jan 23, 2004 at 06:24:36PM -0800, Jun Sun wrote:

> There is one worrisome "FIXME" in that file, which is not clear
> to me.  Ralf?

That comment was copied over from i386.  It it works for them it must be
good for us ;-)

  Ralf

From drow@crack.them.org Sun Jan 25 17:04:08 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 25 Jan 2004 17:04:09 +0000 (GMT)
Received: from nevyn.them.org ([IPv6:::ffff:66.93.172.17]:57017 "EHLO
	nevyn.them.org") by linux-mips.org with ESMTP id <S8225237AbUAYREI>;
	Sun, 25 Jan 2004 17:04:08 +0000
Received: from drow by nevyn.them.org with local (Exim 4.30 #1 (Debian))
	id 1Aknfr-0002r9-Gt; Sun, 25 Jan 2004 12:03:51 -0500
Date: Sun, 25 Jan 2004 12:03:51 -0500
From: Daniel Jacobowitz <drow@mvista.com>
To: Andi Kleen <ak@suse.de>
Cc: Jan Hubicka <jh@suse.cz>, echristo@redhat.com, hubicka@ucw.cz,
	eager@mvista.com, gcc@gcc.gnu.org, linux-mips@linux-mips.org
Subject: Re: GCC-3.4 reorders asm() with -O2
Message-ID: <20040125170351.GA10938@nevyn.them.org>
Mail-Followup-To: Andi Kleen <ak@suse.de>, Jan Hubicka <jh@suse.cz>,
	echristo@redhat.com, hubicka@ucw.cz, eager@mvista.com,
	gcc@gcc.gnu.org, linux-mips@linux-mips.org
References: <4011C72C.613E25@mvista.com> <20040124011955.GA12040@nevyn.them.org> <20040124012303.GJ32288@atrey.karlin.mff.cuni.cz> <20040124050849.GB14951@nevyn.them.org> <1075009125.3649.0.camel@dzur.sfbay.redhat.com> <20040125100514.GA8810@kam.mff.cuni.cz> <20040125164758.79373419.ak@suse.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20040125164758.79373419.ak@suse.de>
User-Agent: Mutt/1.5.1i
Return-Path: <drow@crack.them.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: 4129
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: drow@mvista.com
Precedence: bulk
X-list: linux-mips
Content-Length: 1077
Lines: 29

On Sun, Jan 25, 2004 at 04:47:58PM +0100, Andi Kleen wrote:
> On Sun, 25 Jan 2004 11:05:14 +0100
> Jan Hubicka <jh@suse.cz> wrote:
> 
> > > 
> > > > 
> > > > For x86 it does.  For MIPS I'm quite sure it doesn't - well, it will
> > > > compile, but not work.
> > > 
> > > but, unlike x86 this is hardly a surprise on a daily basis.
> > 
> > I think Andi has sollution that shall fix the other architectures in the
> > kernel too.
> 
> If it's the same problem that broke i386: Current bitkeeper should sort the exception tables
> and fix it. It's actually done with a patch from Paul Mackerras. Of course it could be a different
> issue too that's breaking MIPS.

It is.  Ralf already knows about the problem, I think - we leave
markers outside of functions which define an entry point, save some
additional registers to the stack, and try to fall through to the
following function.  If the function gets emitted elsewhere, obviously,
we've lost :)

[This is save_static_function...]

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

From ralf@linux-mips.org Sun Jan 25 18:26:49 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 25 Jan 2004 18:26:49 +0000 (GMT)
Received: from p508B7347.dip.t-dialin.net ([IPv6:::ffff:80.139.115.71]:21628
	"EHLO mail.linux-mips.net") by linux-mips.org with ESMTP
	id <S8224950AbUAYS0t>; Sun, 25 Jan 2004 18:26:49 +0000
Received: from fluff.linux-mips.net (fluff.linux-mips.net [127.0.0.1])
	by mail.linux-mips.net (8.12.8/8.12.8) with ESMTP id i0PIQkex025076;
	Sun, 25 Jan 2004 19:26:46 +0100
Received: (from ralf@localhost)
	by fluff.linux-mips.net (8.12.8/8.12.8/Submit) id i0PIQh4c025075;
	Sun, 25 Jan 2004 19:26:43 +0100
Date: Sun, 25 Jan 2004 19:26:43 +0100
From: Ralf Baechle <ralf@linux-mips.org>
To: Andi Kleen <ak@suse.de>, Jan Hubicka <jh@suse.cz>,
	echristo@redhat.com, hubicka@ucw.cz, eager@mvista.com,
	gcc@gcc.gnu.org, linux-mips@linux-mips.org
Subject: Re: GCC-3.4 reorders asm() with -O2
Message-ID: <20040125182643.GA25020@linux-mips.org>
References: <4011C72C.613E25@mvista.com> <20040124011955.GA12040@nevyn.them.org> <20040124012303.GJ32288@atrey.karlin.mff.cuni.cz> <20040124050849.GB14951@nevyn.them.org> <1075009125.3649.0.camel@dzur.sfbay.redhat.com> <20040125100514.GA8810@kam.mff.cuni.cz> <20040125164758.79373419.ak@suse.de> <20040125170351.GA10938@nevyn.them.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20040125170351.GA10938@nevyn.them.org>
User-Agent: Mutt/1.4.1i
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: 4130
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
Content-Length: 591
Lines: 15

On Sun, Jan 25, 2004 at 12:03:51PM -0500, Daniel Jacobowitz wrote:

> It is.  Ralf already knows about the problem, I think - we leave
> markers outside of functions which define an entry point, save some
> additional registers to the stack, and try to fall through to the
> following function.  If the function gets emitted elsewhere, obviously,
> we've lost :)
> 
> [This is save_static_function...]

I only recently fixed the problem with the save_static() inline function
which of course was fragile, speculating on the compiler doing the
right thing ...  I'll cook up a fix ...

  Ralf

From dimitri@sonycom.com Sun Jan 25 19:17:34 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 25 Jan 2004 19:17:35 +0000 (GMT)
Received: from witte.sonytel.be ([IPv6:::ffff:80.88.33.193]:49838 "EHLO
	witte.sonytel.be") by linux-mips.org with ESMTP id <S8225397AbUAYTRe>;
	Sun, 25 Jan 2004 19:17:34 +0000
Received: from teasel.sonytel.be (localhost [127.0.0.1])
	by witte.sonytel.be (8.12.10/8.12.10) with ESMTP id i0PJHSw1000239;
	Sun, 25 Jan 2004 20:17:29 +0100 (MET)
Received: (from dimitri@localhost)
	by teasel.sonytel.be (8.9.3+Sun/8.9.3) id UAA18288;
	Sun, 25 Jan 2004 20:17:27 +0100 (MET)
Date: Sun, 25 Jan 2004 20:17:26 +0100
From: Dimitri Torfs <dimitri@sonycom.com>
To: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
Cc: linux-mips@linux-mips.org
Subject: Re: Support for newer gcc/gas options
Message-ID: <20040125191726.GA18263@sonycom.com>
References: <20031223114644.GA5458@sonycom.com> <Pine.LNX.4.55.0312231303030.27594@jurand.ds.pg.gda.pl> <Pine.LNX.4.55.0401201332080.12841@jurand.ds.pg.gda.pl> <20040120204026.GA9470@sonycom.com> <Pine.LNX.4.55.0401211449170.11137@jurand.ds.pg.gda.pl> <20040121145120.GA14288@sonycom.com> <20040121183551.GA21411@sonycom.com> <Pine.LNX.4.55.0401221700510.16353@jurand.ds.pg.gda.pl>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Pine.LNX.4.55.0401221700510.16353@jurand.ds.pg.gda.pl>
User-Agent: Mutt/1.4.1i
Return-Path: <dimitri@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: 4131
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: dimitri@sonycom.com
Precedence: bulk
X-list: linux-mips
Content-Length: 903
Lines: 25

On Thu, Jan 22, 2004 at 05:10:23PM +0100, Maciej W. Rozycki wrote:
> 
>  Thanks for digging into it.  Actually after fixing the typos I've noticed
> gcc 2.95.4 always implies the ISA from the ABI unless overridden and
> -mabi=64 implies -mips4, so it bails out with -march/-mcpu set to
> something like r4600.  This also proves the uncertainity about what's
> passed to gas and so far including an ISA specification in gas settings is
> tolerable if carefully chosen.  So here's a set of new updates -- now the
> ISA specifier is removed from gcc flags only if it actually works and the
> ISA specifier for gas is untouched.
> 
>  Hopefully this is the last attempt.  Please try it.
> 

Ok for me (tested the HEAD one).

Dimitri


-- 
Dimitri Torfs       |  NSCE 
dimitri@sonycom.com |  The Corporate Village
tel: +32 2 7008541  |  Da Vincilaan 7 - D1 
fax: +32 2 7008622  |  B-1935 Zaventem - Belgium


From ak@suse.de Sun Jan 25 19:28:18 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 25 Jan 2004 19:28:19 +0000 (GMT)
Received: from ns.suse.de ([IPv6:::ffff:195.135.220.2]:40930 "EHLO
	Cantor.suse.de") by linux-mips.org with ESMTP id <S8224950AbUAYT2S>;
	Sun, 25 Jan 2004 19:28:18 +0000
Received: from Hermes.suse.de (Hermes.suse.de [195.135.221.8])
	(using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits))
	(No client certificate requested)
	by Cantor.suse.de (Postfix) with ESMTP
	id 044B7A2E8E; Sun, 25 Jan 2004 20:28:15 +0100 (CET)
Date: Sun, 25 Jan 2004 20:28:07 +0100
From: Andi Kleen <ak@suse.de>
To: Ralf Baechle <ralf@linux-mips.org>
Cc: jh@suse.cz, echristo@redhat.com, hubicka@ucw.cz, eager@mvista.com,
	gcc@gcc.gnu.org, linux-mips@linux-mips.org
Subject: Re: GCC-3.4 reorders asm() with -O2
Message-Id: <20040125202807.2d786115.ak@suse.de>
In-Reply-To: <20040125182643.GA25020@linux-mips.org>
References: <4011C72C.613E25@mvista.com>
	<20040124011955.GA12040@nevyn.them.org>
	<20040124012303.GJ32288@atrey.karlin.mff.cuni.cz>
	<20040124050849.GB14951@nevyn.them.org>
	<1075009125.3649.0.camel@dzur.sfbay.redhat.com>
	<20040125100514.GA8810@kam.mff.cuni.cz>
	<20040125164758.79373419.ak@suse.de>
	<20040125170351.GA10938@nevyn.them.org>
	<20040125182643.GA25020@linux-mips.org>
X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.10; i686-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Return-Path: <ak@suse.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: 4132
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: ak@suse.de
Precedence: bulk
X-list: linux-mips
Content-Length: 740
Lines: 20

On Sun, 25 Jan 2004 19:26:43 +0100
Ralf Baechle <ralf@linux-mips.org> wrote:

> On Sun, Jan 25, 2004 at 12:03:51PM -0500, Daniel Jacobowitz wrote:
> 
> > It is.  Ralf already knows about the problem, I think - we leave
> > markers outside of functions which define an entry point, save some
> > additional registers to the stack, and try to fall through to the
> > following function.  If the function gets emitted elsewhere, obviously,
> > we've lost :)
> > 
> > [This is save_static_function...]
> 
> I only recently fixed the problem with the save_static() inline function
> which of course was fragile, speculating on the compiler doing the
> right thing ...  I'll cook up a fix ...

You can always use __attribute__((noinline))

-Andi

From ralf@linux-mips.org Mon Jan 26 12:10:49 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 26 Jan 2004 12:10:50 +0000 (GMT)
Received: from p508B5D28.dip.t-dialin.net ([IPv6:::ffff:80.139.93.40]:5187
	"EHLO mail.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225220AbUAZMKt>; Mon, 26 Jan 2004 12:10:49 +0000
Received: from fluff.linux-mips.net (fluff.linux-mips.net [127.0.0.1])
	by mail.linux-mips.net (8.12.8/8.12.8) with ESMTP id i0QCAkex012175
	for <linux-mips@linux-mips.org>; Mon, 26 Jan 2004 13:10:46 +0100
Received: (from ralf@localhost)
	by fluff.linux-mips.net (8.12.8/8.12.8/Submit) id i0QCAkAB012174
	for linux-mips@linux-mips.org; Mon, 26 Jan 2004 13:10:46 +0100
Resent-Message-Id: <200401261210.i0QCAkAB012174@fluff.linux-mips.net>
Received: from fluff.linux-mips.net (fluff.linux-mips.net [127.0.0.1])
	by mail.linux-mips.net (8.12.8/8.12.8) with ESMTP id i0Q8aoex008348;
	Mon, 26 Jan 2004 09:36:50 +0100
Received: (from ralf@localhost)
	by fluff.linux-mips.net (8.12.8/8.12.8/Submit) id i0Q8alg3008347;
	Mon, 26 Jan 2004 09:36:47 +0100
Date: Mon, 26 Jan 2004 09:36:47 +0100
From: Ralf Baechle <ralf@linux-mips.org>
To: Andi Kleen <ak@suse.de>
Cc: jh@suse.cz, echristo@redhat.com, hubicka@ucw.cz, eager@mvista.com,
	gcc@gcc.gnu.org, linux-mips@linux-mips.org
Subject: Re: GCC-3.4 reorders asm() with -O2
Message-ID: <20040126083647.GA28612@linux-mips.org>
References: <4011C72C.613E25@mvista.com> <20040124011955.GA12040@nevyn.them.org> <20040124012303.GJ32288@atrey.karlin.mff.cuni.cz> <20040124050849.GB14951@nevyn.them.org> <1075009125.3649.0.camel@dzur.sfbay.redhat.com> <20040125100514.GA8810@kam.mff.cuni.cz> <20040125164758.79373419.ak@suse.de> <20040125170351.GA10938@nevyn.them.org> <20040125182643.GA25020@linux-mips.org> <20040125202807.2d786115.ak@suse.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20040125202807.2d786115.ak@suse.de>
User-Agent: Mutt/1.4.1i
Resent-From: ralf@linux-mips.org
Resent-Date: Mon, 26 Jan 2004 13:10:46 +0100
Resent-To: linux-mips@linux-mips.org
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: 4133
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
Content-Length: 1247
Lines: 26

On Sun, Jan 25, 2004 at 08:28:07PM +0100, Andi Kleen wrote:

> > > It is.  Ralf already knows about the problem, I think - we leave
> > > markers outside of functions which define an entry point, save some
> > > additional registers to the stack, and try to fall through to the
> > > following function.  If the function gets emitted elsewhere, obviously,
> > > we've lost :)
> > > 
> > > [This is save_static_function...]
> > 
> > I only recently fixed the problem with the save_static() inline function
> > which of course was fragile, speculating on the compiler doing the
> > right thing ...  I'll cook up a fix ...
> 
> You can always use __attribute__((noinline))

Not in this particular case.   save_static's purpose was saving all
caller saved registers into the stack so they can be accessed via the
usual struct pt_regs pointer and to make that work it to be inline before
any change of these registers.  That was a small optimization but it also
was fragile so I removed that.  save_static_function was meant to be
used immediately preceeding a syscall's C function and served the same
purpose.  As the implementation ``knew'' gcc wasn't going to move around
the code just falling though worked fine but again that was fragile.

  Ralf

From macro@ds2.pg.gda.pl Mon Jan 26 16:31:12 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 26 Jan 2004 16:31:13 +0000 (GMT)
Received: from jurand.ds.pg.gda.pl ([IPv6:::ffff:153.19.208.2]:17043 "EHLO
	jurand.ds.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8225251AbUAZQbM>; Mon, 26 Jan 2004 16:31:12 +0000
Received: by jurand.ds.pg.gda.pl (Postfix, from userid 1011)
	id D97314C174; Mon, 26 Jan 2004 17:31:07 +0100 (CET)
Received: from localhost (localhost [127.0.0.1])
	by jurand.ds.pg.gda.pl (Postfix) with ESMTP
	id C2E8B477F0; Mon, 26 Jan 2004 17:31:07 +0100 (CET)
Date: Mon, 26 Jan 2004 17:31:07 +0100 (CET)
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To: Dominik 'Rathann' Mierzejewski <rathann@icm.edu.pl>,
	Ralf Baechle <ralf@linux-mips.org>
Cc: linux-mips@linux-mips.org
Subject: [patch] pg-r4k.c bugs for R4600 rev.2.0
In-Reply-To: <20040123161410.GC20047@icm.edu.pl>
Message-ID: <Pine.LNX.4.55.0401261659540.14505@jurand.ds.pg.gda.pl>
References: <20040115141427.GA28546@icm.edu.pl>
 <Pine.LNX.4.21.0401151816540.3511-100000@www.marty44.net>
 <20040115231735.GA6619@icm.edu.pl> <4007386F.80207@gentoo.org>
 <20040115172602.H18368@mvista.com> <20040116115053.GA18099@icm.edu.pl>
 <20040120130625.GA24435@icm.edu.pl> <20040120162800.GA29792@icm.edu.pl>
 <20040123161410.GC20047@icm.edu.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: 4134
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
Content-Length: 8043
Lines: 216

On Fri, 23 Jan 2004, Dominik 'Rathann' Mierzejewski wrote:

> > > 6242 2003/12/11 01:29:17 linux_2_4 ralf Fix a bunch of long standing bugs
> > > and performance clear_page issues: - Fi .....
> > [...] 
> > 
> > Found it! After applying the above patch, the kernel no longer goes
> > past the "Freeing unused kernel memory" stage. So for now I'm sticking
> > with the 20031205 kernel.
> 
> Could someone please look into this?

 There are a few bugs in arch/mips*/mm/pg-r4k.c and one of them affects 
your system:

> ARCH: SGI-IP22
> PROMLIB: ARC firmware Version 1 Revision 10
> CPU revision is: 00002020
> FPU revision is: 00002020
> Primary instruction cache 16kB, physically tagged, 2-way, linesize 32 bytes.
> Primary data cache 16kB 2-way, linesize 32 bytes.
> Linux version 2.4.22 (dominik@indy0) (gcc version 3.3.1 20030626 (Debian
> prerelease)) #1 Thu Sep 25 15:11:35 CEST 2003

This is an R4600 rev.2.0 which has a D-cache erratum that is worked around 
in these files.  Unfortunately, the work around corrupts the $at register 
that is assumed to be initialized and used afterwards elsewhere.  Since 
the functions affected are called with the assumption of the usual ABI 
convention, there's plenty of temporary registers to use and I propose to 
reserve $at for use as a local scratch register.  Here is a patch.  It 
should fix the problems for you.

 I have two other fixes for the file -- you might try them as well, as
I've only tested all three of them together, because of a different
configuration of the system I've used.  They fix a problem with R4k
systems with a secondary cache and a coprocessor 0 hazard with R4000/R4400
systems with primary caches only.

 Ralf, OK to apply this one?

  Maciej

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

patch-mips-2.4.24-pre2-20040116-mips-pg-r4k-5
diff -up --recursive --new-file linux-mips-2.4.24-pre2-20040116.macro/arch/mips/mm/pg-r4k.c linux-mips-2.4.24-pre2-20040116/arch/mips/mm/pg-r4k.c
--- linux-mips-2.4.24-pre2-20040116.macro/arch/mips/mm/pg-r4k.c	2004-01-03 03:56:38.000000000 +0000
+++ linux-mips-2.4.24-pre2-20040116/arch/mips/mm/pg-r4k.c	2004-01-26 12:09:56.000000000 +0000
@@ -96,7 +96,7 @@ static inline void __build_load_reg(int 
 	else
 		mi.i_format.opcode     = lw_op;
 	mi.i_format.rs         = 5;		/* $a1 */
-	mi.i_format.rt         = reg;		/* $zero */
+	mi.i_format.rt         = reg;		/* $reg */
 	mi.i_format.simmediate = load_offset;
 
 	load_offset += (cpu_has_64bit_registers ? 8 : 4);
@@ -197,7 +197,7 @@ static inline void __build_store_reg(int
 	reg_size               = 8;
 #endif
 	mi.i_format.rs         = 4;		/* $a0 */
-	mi.i_format.rt         = reg;		/* $zero */
+	mi.i_format.rt         = reg;		/* $reg */
 	mi.i_format.simmediate = store_offset;
 
 	store_offset += reg_size;
@@ -218,7 +218,7 @@ static inline void build_store_reg(int r
 	__build_store_reg(reg);
 }
 
-static inline void build_addiu_at_a0(unsigned long offset)
+static inline void build_addiu_a2_a0(unsigned long offset)
 {
 	union mips_instruction mi;
 
@@ -226,7 +226,7 @@ static inline void build_addiu_at_a0(uns
 
 	mi.i_format.opcode     = cpu_has_64bit_addresses ? daddiu_op : addiu_op;
 	mi.i_format.rs         = 4;		/* $a0 */
-	mi.i_format.rt         = 1;		/* $at */
+	mi.i_format.rt         = 6;		/* $a2 */
 	mi.i_format.simmediate = offset;
 
 	*epc++ = mi.word;
@@ -269,7 +269,7 @@ static inline void build_bne(unsigned in
 	union mips_instruction mi;
 
 	mi.i_format.opcode = bne_op;
-	mi.i_format.rs     = 1;			/* $at */
+	mi.i_format.rs     = 6;			/* $a2 */
 	mi.i_format.rt     = 4;			/* $a0 */
 	mi.i_format.simmediate = dest - epc - 1;
 
@@ -313,7 +313,7 @@ void __init build_clear_page(void)
 		}
 	}
 
-	build_addiu_at_a0(PAGE_SIZE - (cpu_has_prefetch ? pref_offset_clear : 0));
+	build_addiu_a2_a0(PAGE_SIZE - (cpu_has_prefetch ? pref_offset_clear : 0));
 
 	if (R4600_V2_HIT_CACHEOP_WAR && ((read_c0_prid() & 0xfff0) == 0x2020)) {
 		*epc++ = 0x40026000;		/* mfc0    $v0, $12	*/
@@ -352,7 +352,7 @@ dest = epc;
 	 build_store_reg(0);
 
 	if (cpu_has_prefetch && pref_offset_clear) {
-		build_addiu_at_a0(pref_offset_clear);
+		build_addiu_a2_a0(pref_offset_clear);
 	dest = epc;
 		__build_store_reg(0);
 		__build_store_reg(0);
@@ -382,7 +382,7 @@ void __init build_copy_page(void)
 {
 	epc = (unsigned int *) &copy_page_array;
 
-	build_addiu_at_a0(PAGE_SIZE - (cpu_has_prefetch ? pref_offset_copy : 0));
+	build_addiu_a2_a0(PAGE_SIZE - (cpu_has_prefetch ? pref_offset_copy : 0));
 
 	if (R4600_V2_HIT_CACHEOP_WAR && ((read_c0_prid() & 0xfff0) == 0x2020)) {
 		*epc++ = 0x40026000;		/* mfc0    $v0, $12	*/
@@ -438,7 +438,7 @@ dest = epc;
 	 build_store_reg(11);
 
 	if (cpu_has_prefetch && pref_offset_copy) {
-		build_addiu_at_a0(pref_offset_copy);
+		build_addiu_a2_a0(pref_offset_copy);
 	dest = epc;
 		__build_load_reg( 8);
 		__build_load_reg( 9);
diff -up --recursive --new-file linux-mips-2.4.24-pre2-20040116.macro/arch/mips64/mm/pg-r4k.c linux-mips-2.4.24-pre2-20040116/arch/mips64/mm/pg-r4k.c
--- linux-mips-2.4.24-pre2-20040116.macro/arch/mips64/mm/pg-r4k.c	2004-01-03 03:56:46.000000000 +0000
+++ linux-mips-2.4.24-pre2-20040116/arch/mips64/mm/pg-r4k.c	2004-01-26 12:09:56.000000000 +0000
@@ -96,7 +96,7 @@ static inline void __build_load_reg(int 
 	else
 		mi.i_format.opcode     = lw_op;
 	mi.i_format.rs         = 5;		/* $a1 */
-	mi.i_format.rt         = reg;		/* $zero */
+	mi.i_format.rt         = reg;		/* $reg */
 	mi.i_format.simmediate = load_offset;
 
 	load_offset += (cpu_has_64bit_registers ? 8 : 4);
@@ -197,7 +197,7 @@ static inline void __build_store_reg(int
 	reg_size               = 8;
 #endif
 	mi.i_format.rs         = 4;		/* $a0 */
-	mi.i_format.rt         = reg;		/* $zero */
+	mi.i_format.rt         = reg;		/* $reg */
 	mi.i_format.simmediate = store_offset;
 
 	store_offset += reg_size;
@@ -218,7 +218,7 @@ static inline void build_store_reg(int r
 	__build_store_reg(reg);
 }
 
-static inline void build_addiu_at_a0(unsigned long offset)
+static inline void build_addiu_a2_a0(unsigned long offset)
 {
 	union mips_instruction mi;
 
@@ -226,7 +226,7 @@ static inline void build_addiu_at_a0(uns
 
 	mi.i_format.opcode     = cpu_has_64bit_addresses ? daddiu_op : addiu_op;
 	mi.i_format.rs         = 4;		/* $a0 */
-	mi.i_format.rt         = 1;		/* $at */
+	mi.i_format.rt         = 6;		/* $a2 */
 	mi.i_format.simmediate = offset;
 
 	*epc++ = mi.word;
@@ -269,7 +269,7 @@ static inline void build_bne(unsigned in
 	union mips_instruction mi;
 
 	mi.i_format.opcode = bne_op;
-	mi.i_format.rs     = 1;			/* $at */
+	mi.i_format.rs     = 6;			/* $a2 */
 	mi.i_format.rt     = 4;			/* $a0 */
 	mi.i_format.simmediate = dest - epc - 1;
 
@@ -313,7 +313,7 @@ void __init build_clear_page(void)
 		}
 	}
 
-	build_addiu_at_a0(PAGE_SIZE - (cpu_has_prefetch ? pref_offset_clear : 0));
+	build_addiu_a2_a0(PAGE_SIZE - (cpu_has_prefetch ? pref_offset_clear : 0));
 
 	if (R4600_V2_HIT_CACHEOP_WAR && ((read_c0_prid() & 0xfff0) == 0x2020)) {
 		*epc++ = 0x40026000;		/* mfc0    $v0, $12	*/
@@ -352,7 +352,7 @@ dest = epc;
 	 build_store_reg(0);
 
 	if (cpu_has_prefetch && pref_offset_clear) {
-		build_addiu_at_a0(pref_offset_clear);
+		build_addiu_a2_a0(pref_offset_clear);
 	dest = epc;
 		__build_store_reg(0);
 		__build_store_reg(0);
@@ -382,7 +382,7 @@ void __init build_copy_page(void)
 {
 	epc = (unsigned int *) &copy_page_array;
 
-	build_addiu_at_a0(PAGE_SIZE - (cpu_has_prefetch ? pref_offset_copy : 0));
+	build_addiu_a2_a0(PAGE_SIZE - (cpu_has_prefetch ? pref_offset_copy : 0));
 
 	if (R4600_V2_HIT_CACHEOP_WAR && ((read_c0_prid() & 0xfff0) == 0x2020)) {
 		*epc++ = 0x40026000;		/* mfc0    $v0, $12	*/
@@ -438,7 +438,7 @@ dest = epc;
 	 build_store_reg(11);
 
 	if (cpu_has_prefetch && pref_offset_copy) {
-		build_addiu_at_a0(pref_offset_copy);
+		build_addiu_a2_a0(pref_offset_copy);
 	dest = epc;
 		__build_load_reg( 8);
 		__build_load_reg( 9);

From macro@ds2.pg.gda.pl Mon Jan 26 16:55:26 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 26 Jan 2004 16:55:27 +0000 (GMT)
Received: from jurand.ds.pg.gda.pl ([IPv6:::ffff:153.19.208.2]:8874 "EHLO
	jurand.ds.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8225305AbUAZQz0>; Mon, 26 Jan 2004 16:55:26 +0000
Received: by jurand.ds.pg.gda.pl (Postfix, from userid 1011)
	id 1143447831; Mon, 26 Jan 2004 17:55:24 +0100 (CET)
Received: from localhost (localhost [127.0.0.1])
	by jurand.ds.pg.gda.pl (Postfix) with ESMTP
	id 02604477F0; Mon, 26 Jan 2004 17:55:23 +0100 (CET)
Date: Mon, 26 Jan 2004 17:55:23 +0100 (CET)
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To: Ralf Baechle <ralf@linux-mips.org>
Cc: linux-mips@linux-mips.org
Subject: [patch] pg-r4k.c bugs for R4k systems with a secondary cache
Message-ID: <Pine.LNX.4.55.0401261731370.26076@jurand.ds.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: 4135
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
Content-Length: 5969
Lines: 173

Ralf,

 This patch fixes a bug in build_cdex() that makes the function invoke the
Create Dirty Exclusive command for the D-cache when a secondary cache is
present.  This is unnecessary as the Create Dirty Exclusive command for
the S-cache acts upon the D-cache appropriately and (for reasons yet to be
investigated) using the command on the D-cache directly leads to memory
corruption on my R4400SC system.  With the patch the system appears
stable.

 The patch also removes references to has_scache which currently disable 
code for the S-cache line size of 128 bytes as the variable is always 0.

 OK to apply?

  Maciej

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

patch-mips-2.4.24-pre2-20040116-mips-pg-r4k-scache-0
diff -up --recursive --new-file linux-mips-2.4.24-pre2-20040116.macro/arch/mips/mm/pg-r4k.c linux-mips-2.4.24-pre2-20040116/arch/mips/mm/pg-r4k.c
--- linux-mips-2.4.24-pre2-20040116.macro/arch/mips/mm/pg-r4k.c	2004-01-03 03:56:38.000000000 +0000
+++ linux-mips-2.4.24-pre2-20040116/arch/mips/mm/pg-r4k.c	2004-01-26 12:13:22.000000000 +0000
@@ -67,7 +67,6 @@ static int pref_offset_copy  __initdata 
 static unsigned int pref_src_mode __initdata;
 static unsigned int pref_dst_mode __initdata;
 
-static int has_scache __initdata = 0;
 static int load_offset __initdata = 0;
 static int store_offset __initdata = 0;
 
@@ -130,16 +129,20 @@ static inline void build_cdex(void)
 {
 	union mips_instruction mi;
 
-	if (cpu_has_cache_cdex_s &&
-	    !(store_offset & (cpu_scache_line_size() - 1))) {
+	if (cpu_has_cache_cdex_s) {
+		if (!(store_offset & (cpu_scache_line_size() - 1))) {
 
-		mi.c_format.opcode     = cache_op;
-		mi.c_format.rs         = 4;	/* $a0 */
-		mi.c_format.c_op       = 3;	/* Create Dirty Exclusive */
-		mi.c_format.cache      = 3;	/* Secondary Data Cache */
-		mi.c_format.simmediate = store_offset;
+			mi.c_format.opcode     = cache_op;
+			mi.c_format.rs         = 4;	/* $a0 */
+			mi.c_format.c_op       = 3;	/* Create Dirty
+							   Exclusive */
+			mi.c_format.cache      = 3;	/* Secondary Data
+							   Cache */
+			mi.c_format.simmediate = store_offset;
 
 		*epc++ = mi.word;
+		}
+		return;
 	}
 
 	if (store_offset & (cpu_dcache_line_size() - 1))
@@ -332,7 +335,7 @@ dest = epc;
 	build_store_reg(0);
 	build_store_reg(0);
 	build_store_reg(0);
-	if (has_scache && cpu_scache_line_size() == 128) {
+	if (cpu_scache_line_size() == 128) {
 		build_store_reg(0);
 		build_store_reg(0);
 		build_store_reg(0);
@@ -341,7 +344,7 @@ dest = epc;
 	build_addiu_a0(2 * store_offset);
 	build_store_reg(0);
 	build_store_reg(0);
-	if (has_scache && cpu_scache_line_size() == 128) {
+	if (cpu_scache_line_size() == 128) {
 		build_store_reg(0);
 		build_store_reg(0);
 		build_store_reg(0);
@@ -405,7 +408,7 @@ dest = epc;
 	build_store_reg( 9);
 	build_store_reg(10);
 	build_store_reg(11);
-	if (has_scache && cpu_scache_line_size() == 128) {
+	if (cpu_scache_line_size() == 128) {
 		build_load_reg( 8);
 		build_load_reg( 9);
 		build_load_reg(10);
@@ -424,7 +427,7 @@ dest = epc;
 	build_store_reg( 8);
 	build_store_reg( 9);
 	build_store_reg(10);
-	if (has_scache && cpu_scache_line_size() == 128) {
+	if (cpu_scache_line_size() == 128) {
 		build_store_reg(11);
 		build_load_reg( 8);
 		build_load_reg( 9);
diff -up --recursive --new-file linux-mips-2.4.24-pre2-20040116.macro/arch/mips64/mm/pg-r4k.c linux-mips-2.4.24-pre2-20040116/arch/mips64/mm/pg-r4k.c
--- linux-mips-2.4.24-pre2-20040116.macro/arch/mips64/mm/pg-r4k.c	2004-01-03 03:56:46.000000000 +0000
+++ linux-mips-2.4.24-pre2-20040116/arch/mips64/mm/pg-r4k.c	2004-01-26 12:13:22.000000000 +0000
@@ -67,7 +67,6 @@ static int pref_offset_copy  __initdata 
 static unsigned int pref_src_mode __initdata;
 static unsigned int pref_dst_mode __initdata;
 
-static int has_scache __initdata = 0;
 static int load_offset __initdata = 0;
 static int store_offset __initdata = 0;
 
@@ -130,16 +129,20 @@ static inline void build_cdex(void)
 {
 	union mips_instruction mi;
 
-	if (cpu_has_cache_cdex_s &&
-	    !(store_offset & (cpu_scache_line_size() - 1))) {
+	if (cpu_has_cache_cdex_s) {
+		if (!(store_offset & (cpu_scache_line_size() - 1))) {
 
-		mi.c_format.opcode     = cache_op;
-		mi.c_format.rs         = 4;	/* $a0 */
-		mi.c_format.c_op       = 3;	/* Create Dirty Exclusive */
-		mi.c_format.cache      = 3;	/* Secondary Data Cache */
-		mi.c_format.simmediate = store_offset;
+			mi.c_format.opcode     = cache_op;
+			mi.c_format.rs         = 4;	/* $a0 */
+			mi.c_format.c_op       = 3;	/* Create Dirty
+							   Exclusive */
+			mi.c_format.cache      = 3;	/* Secondary Data
+							   Cache */
+			mi.c_format.simmediate = store_offset;
 
 		*epc++ = mi.word;
+		}
+		return;
 	}
 
 	if (store_offset & (cpu_dcache_line_size() - 1))
@@ -332,7 +335,7 @@ dest = epc;
 	build_store_reg(0);
 	build_store_reg(0);
 	build_store_reg(0);
-	if (has_scache && cpu_scache_line_size() == 128) {
+	if (cpu_scache_line_size() == 128) {
 		build_store_reg(0);
 		build_store_reg(0);
 		build_store_reg(0);
@@ -341,7 +344,7 @@ dest = epc;
 	build_addiu_a0(2 * store_offset);
 	build_store_reg(0);
 	build_store_reg(0);
-	if (has_scache && cpu_scache_line_size() == 128) {
+	if (cpu_scache_line_size() == 128) {
 		build_store_reg(0);
 		build_store_reg(0);
 		build_store_reg(0);
@@ -405,7 +408,7 @@ dest = epc;
 	build_store_reg( 9);
 	build_store_reg(10);
 	build_store_reg(11);
-	if (has_scache && cpu_scache_line_size() == 128) {
+	if (cpu_scache_line_size() == 128) {
 		build_load_reg( 8);
 		build_load_reg( 9);
 		build_load_reg(10);
@@ -424,7 +427,7 @@ dest = epc;
 	build_store_reg( 8);
 	build_store_reg( 9);
 	build_store_reg(10);
-	if (has_scache && cpu_scache_line_size() == 128) {
+	if (cpu_scache_line_size() == 128) {
 		build_store_reg(11);
 		build_load_reg( 8);
 		build_load_reg( 9);

From ralf@linux-mips.org Mon Jan 26 17:01:00 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 26 Jan 2004 17:01:00 +0000 (GMT)
Received: from p508B5D28.dip.t-dialin.net ([IPv6:::ffff:80.139.93.40]:20564
	"EHLO mail.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225251AbUAZRBA>; Mon, 26 Jan 2004 17:01:00 +0000
Received: from fluff.linux-mips.net (fluff.linux-mips.net [127.0.0.1])
	by mail.linux-mips.net (8.12.8/8.12.8) with ESMTP id i0QH0Wex017574;
	Mon, 26 Jan 2004 18:00:32 +0100
Received: (from ralf@localhost)
	by fluff.linux-mips.net (8.12.8/8.12.8/Submit) id i0QH0SXr017573;
	Mon, 26 Jan 2004 18:00:28 +0100
Date: Mon, 26 Jan 2004 18:00:28 +0100
From: Ralf Baechle <ralf@linux-mips.org>
To: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
Cc: "Dominik 'Rathann' Mierzejewski" <rathann@icm.edu.pl>,
	linux-mips@linux-mips.org
Subject: Re: [patch] pg-r4k.c bugs for R4600 rev.2.0
Message-ID: <20040126170028.GA15176@linux-mips.org>
References: <20040115141427.GA28546@icm.edu.pl> <Pine.LNX.4.21.0401151816540.3511-100000@www.marty44.net> <20040115231735.GA6619@icm.edu.pl> <4007386F.80207@gentoo.org> <20040115172602.H18368@mvista.com> <20040116115053.GA18099@icm.edu.pl> <20040120130625.GA24435@icm.edu.pl> <20040120162800.GA29792@icm.edu.pl> <20040123161410.GC20047@icm.edu.pl> <Pine.LNX.4.55.0401261659540.14505@jurand.ds.pg.gda.pl>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Pine.LNX.4.55.0401261659540.14505@jurand.ds.pg.gda.pl>
User-Agent: Mutt/1.4.1i
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: 4136
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
Content-Length: 621
Lines: 16

On Mon, Jan 26, 2004 at 05:31:07PM +0100, Maciej W. Rozycki wrote:

>  I have two other fixes for the file -- you might try them as well, as
> I've only tested all three of them together, because of a different
> configuration of the system I've used.  They fix a problem with R4k
> systems with a secondary cache and a coprocessor 0 hazard with R4000/R4400
> systems with primary caches only.
> 
>  Ralf, OK to apply this one?

Looks good, so please feel free to apply.

I just bent the kernel for my R4600 v2.0 machine (RM200) into shape again
and will test it later; will let you know if there's any problems.

  Ralf

From macro@ds2.pg.gda.pl Mon Jan 26 17:12:44 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 26 Jan 2004 17:12:45 +0000 (GMT)
Received: from jurand.ds.pg.gda.pl ([IPv6:::ffff:153.19.208.2]:60849 "EHLO
	jurand.ds.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8225251AbUAZRMo>; Mon, 26 Jan 2004 17:12:44 +0000
Received: by jurand.ds.pg.gda.pl (Postfix, from userid 1011)
	id 6598C4C174; Mon, 26 Jan 2004 18:12:43 +0100 (CET)
Received: from localhost (localhost [127.0.0.1])
	by jurand.ds.pg.gda.pl (Postfix) with ESMTP
	id 58BBF4BEF0; Mon, 26 Jan 2004 18:12:43 +0100 (CET)
Date: Mon, 26 Jan 2004 18:12:43 +0100 (CET)
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To: Ralf Baechle <ralf@linux-mips.org>
Cc: linux-mips@linux-mips.org
Subject: [patch] pg-r4k.c cp0 hazards for R4000/R4400
Message-ID: <Pine.LNX.4.55.0401261755460.26076@jurand.ds.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: 4137
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
Content-Length: 9004
Lines: 270

Ralf,

 The R4000/R4400 has a coprocessor 0 hazard when a P-cache operation is
less than two non-load, non-cache instructions apart from a store to the
same line.  For processors without a secondary cache, the code in pg-r4k.c
currently issues a Create Dirty Exclusive D-cache operation and then
immediately executes consecutive stores to the same line, therefore 
fulfilling the conditions for the hazard.

 The following patch changes the problematic operations to be performed on 
the cache line following the one to be written immediately.  It is safe to 
do so, because the cache operations are only a performance hint and are 
not required for data coherency.  However it is essential not to bypass 
the end of the page, so the trailing area of the page is excluded from 
these cache operation, similarly to what has already been done for 
prefetching.

 Actually, I'd like to optimize the functions a bit further, specifically 
to avoid multiple cacheops to the same line (if you don't mind), but 
currently I'd like to apply this change to assure correct operation.  As I 
have no non-SC R4000/R4400 system, this was untested, but perhaps studying 
the problem covered by the -scache patch sent previously will show if the 
hazard is indeed avoided.

 The patch also increases the buffers a bit for three reasons:

1. copy_page_array is already too small for the 128-byte S-cache line 
case. ;-)

2. The trail for non-SC R4000/R4400 increases buffer consumption and I was 
too lazy to calculate the requirements.

3. The planned optimization will likely require a little bit more space as 
well.

BTW, I was unable to reproduce your instruction count calculation for the
prefetch case; other results seem OK.

 OK to apply?

  Maciej

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

patch-mips-2.4.24-pre2-20040116-mips-pg-r4k-hazard-7
diff -up --recursive --new-file linux-mips-2.4.24-pre2-20040116.macro/arch/mips/mm/pg-r4k.c linux-mips-2.4.24-pre2-20040116/arch/mips/mm/pg-r4k.c
--- linux-mips-2.4.24-pre2-20040116.macro/arch/mips/mm/pg-r4k.c	2004-01-26 16:05:38.000000000 +0000
+++ linux-mips-2.4.24-pre2-20040116/arch/mips/mm/pg-r4k.c	2004-01-26 16:06:21.000000000 +0000
@@ -34,7 +34,7 @@
  * With prefetching, 16 byte strides			0xa0 bytes
  */
 
-static unsigned int clear_page_array[0xa0 / 4];
+static unsigned int clear_page_array[0x100 / 4];
 
 void clear_page(void * page) __attribute__((alias("clear_page_array")));
 
@@ -46,7 +46,7 @@ void clear_page(void * page) __attribute
  * R4600 v2.0:						0x84 bytes
  * With prefetching, 16 byte strides			0xb8 bytes
  */
-static unsigned int copy_page_array[0xb8 / 4];
+static unsigned int copy_page_array[0x100 / 4];
 
 void copy_page(void *to, void *from) __attribute__((alias("copy_page_array")));
 
@@ -159,7 +159,7 @@ static inline void build_cdex(void)
 	mi.c_format.rs         = 4;		/* $a0 */
 	mi.c_format.c_op       = 3;		/* Create Dirty Exclusive */
 	mi.c_format.cache      = 1;		/* Data Cache */
-	mi.c_format.simmediate = store_offset;
+	mi.c_format.simmediate = store_offset + cpu_dcache_line_size();
 
 	*epc++ = mi.word;
 }
@@ -300,6 +300,8 @@ static inline void build_jr_ra(void)
 
 void __init build_clear_page(void)
 {
+	int lead_size, loop_size;
+
 	epc = (unsigned int *) &clear_page_array;
 
 	if (cpu_has_prefetch) {
@@ -316,7 +318,20 @@ void __init build_clear_page(void)
 		}
 	}
 
-	build_addiu_a2_a0(PAGE_SIZE - (cpu_has_prefetch ? pref_offset_clear : 0));
+	if (cpu_has_prefetch)
+		lead_size = PAGE_SIZE - pref_offset_clear;
+	else if (cpu_has_cache_cdex_p && !cpu_has_cache_cdex_s) {
+		loop_size = 4;
+		if (cpu_has_64bit_registers)
+			loop_size *= 2;
+		loop_size *= 8;
+		if (loop_size < cpu_dcache_line_size())
+			loop_size = cpu_dcache_line_size();
+		lead_size = PAGE_SIZE - loop_size;
+	} else
+		lead_size = PAGE_SIZE;
+
+	build_addiu_a2_a0(lead_size);
 
 	if (R4600_V2_HIT_CACHEOP_WAR && ((read_c0_prid() & 0xfff0) == 0x2020)) {
 		*epc++ = 0x40026000;		/* mfc0    $v0, $12	*/
@@ -354,8 +369,8 @@ dest = epc;
 	build_bne(dest);
 	 build_store_reg(0);
 
-	if (cpu_has_prefetch && pref_offset_clear) {
-		build_addiu_a2_a0(pref_offset_clear);
+	if (lead_size < PAGE_SIZE) {
+		build_addiu_a2_a0(PAGE_SIZE - lead_size);
 	dest = epc;
 		__build_store_reg(0);
 		__build_store_reg(0);
@@ -383,9 +398,26 @@ dest = epc;
 
 void __init build_copy_page(void)
 {
+	int lead_size, loop_size;
+
 	epc = (unsigned int *) &copy_page_array;
 
-	build_addiu_a2_a0(PAGE_SIZE - (cpu_has_prefetch ? pref_offset_copy : 0));
+	if (cpu_has_prefetch)
+		lead_size = PAGE_SIZE - pref_offset_copy;
+	else if (cpu_has_cache_cdex_p && !cpu_has_cache_cdex_s) {
+		loop_size = 4;
+#ifdef CONFIG_MIPS64
+		loop_size *= 2;
+#endif
+		loop_size *= 8;
+		if (loop_size < cpu_dcache_line_size())
+			loop_size = cpu_dcache_line_size();
+		lead_size = PAGE_SIZE - loop_size;
+	} else
+		lead_size = PAGE_SIZE;
+
+	build_addiu_a2_a0(lead_size);
+
 
 	if (R4600_V2_HIT_CACHEOP_WAR && ((read_c0_prid() & 0xfff0) == 0x2020)) {
 		*epc++ = 0x40026000;		/* mfc0    $v0, $12	*/
@@ -440,8 +472,8 @@ dest = epc;
 	build_bne(dest);
 	 build_store_reg(11);
 
-	if (cpu_has_prefetch && pref_offset_copy) {
-		build_addiu_a2_a0(pref_offset_copy);
+	if (lead_size < PAGE_SIZE) {
+		build_addiu_a2_a0(PAGE_SIZE - lead_size);
 	dest = epc;
 		__build_load_reg( 8);
 		__build_load_reg( 9);
diff -up --recursive --new-file linux-mips-2.4.24-pre2-20040116.macro/arch/mips64/mm/pg-r4k.c linux-mips-2.4.24-pre2-20040116/arch/mips64/mm/pg-r4k.c
--- linux-mips-2.4.24-pre2-20040116.macro/arch/mips64/mm/pg-r4k.c	2004-01-26 16:05:38.000000000 +0000
+++ linux-mips-2.4.24-pre2-20040116/arch/mips64/mm/pg-r4k.c	2004-01-26 16:06:21.000000000 +0000
@@ -34,7 +34,7 @@
  * With prefetching, 16 byte strides			0xa0 bytes
  */
 
-static unsigned int clear_page_array[0xa0 / 4];
+static unsigned int clear_page_array[0x100 / 4];
 
 void clear_page(void * page) __attribute__((alias("clear_page_array")));
 
@@ -46,7 +46,7 @@ void clear_page(void * page) __attribute
  * R4600 v2.0:						0x84 bytes
  * With prefetching, 16 byte strides			0xb8 bytes
  */
-static unsigned int copy_page_array[0xb8 / 4];
+static unsigned int copy_page_array[0x100 / 4];
 
 void copy_page(void *to, void *from) __attribute__((alias("copy_page_array")));
 
@@ -159,7 +159,7 @@ static inline void build_cdex(void)
 	mi.c_format.rs         = 4;		/* $a0 */
 	mi.c_format.c_op       = 3;		/* Create Dirty Exclusive */
 	mi.c_format.cache      = 1;		/* Data Cache */
-	mi.c_format.simmediate = store_offset;
+	mi.c_format.simmediate = store_offset + cpu_dcache_line_size();
 
 	*epc++ = mi.word;
 }
@@ -300,6 +300,8 @@ static inline void build_jr_ra(void)
 
 void __init build_clear_page(void)
 {
+	int lead_size, loop_size;
+
 	epc = (unsigned int *) &clear_page_array;
 
 	if (cpu_has_prefetch) {
@@ -316,7 +318,20 @@ void __init build_clear_page(void)
 		}
 	}
 
-	build_addiu_a2_a0(PAGE_SIZE - (cpu_has_prefetch ? pref_offset_clear : 0));
+	if (cpu_has_prefetch)
+		lead_size = PAGE_SIZE - pref_offset_clear;
+	else if (cpu_has_cache_cdex_p && !cpu_has_cache_cdex_s) {
+		loop_size = 4;
+		if (cpu_has_64bit_registers)
+			loop_size *= 2;
+		loop_size *= 8;
+		if (loop_size < cpu_dcache_line_size())
+			loop_size = cpu_dcache_line_size();
+		lead_size = PAGE_SIZE - loop_size;
+	} else
+		lead_size = PAGE_SIZE;
+
+	build_addiu_a2_a0(lead_size);
 
 	if (R4600_V2_HIT_CACHEOP_WAR && ((read_c0_prid() & 0xfff0) == 0x2020)) {
 		*epc++ = 0x40026000;		/* mfc0    $v0, $12	*/
@@ -354,8 +369,8 @@ dest = epc;
 	build_bne(dest);
 	 build_store_reg(0);
 
-	if (cpu_has_prefetch && pref_offset_clear) {
-		build_addiu_a2_a0(pref_offset_clear);
+	if (lead_size < PAGE_SIZE) {
+		build_addiu_a2_a0(PAGE_SIZE - lead_size);
 	dest = epc;
 		__build_store_reg(0);
 		__build_store_reg(0);
@@ -383,9 +398,26 @@ dest = epc;
 
 void __init build_copy_page(void)
 {
+	int lead_size, loop_size;
+
 	epc = (unsigned int *) &copy_page_array;
 
-	build_addiu_a2_a0(PAGE_SIZE - (cpu_has_prefetch ? pref_offset_copy : 0));
+	if (cpu_has_prefetch)
+		lead_size = PAGE_SIZE - pref_offset_copy;
+	else if (cpu_has_cache_cdex_p && !cpu_has_cache_cdex_s) {
+		loop_size = 4;
+#ifdef CONFIG_MIPS64
+		loop_size *= 2;
+#endif
+		loop_size *= 8;
+		if (loop_size < cpu_dcache_line_size())
+			loop_size = cpu_dcache_line_size();
+		lead_size = PAGE_SIZE - loop_size;
+	} else
+		lead_size = PAGE_SIZE;
+
+	build_addiu_a2_a0(lead_size);
+
 
 	if (R4600_V2_HIT_CACHEOP_WAR && ((read_c0_prid() & 0xfff0) == 0x2020)) {
 		*epc++ = 0x40026000;		/* mfc0    $v0, $12	*/
@@ -440,8 +472,8 @@ dest = epc;
 	build_bne(dest);
 	 build_store_reg(11);
 
-	if (cpu_has_prefetch && pref_offset_copy) {
-		build_addiu_a2_a0(pref_offset_copy);
+	if (lead_size < PAGE_SIZE) {
+		build_addiu_a2_a0(PAGE_SIZE - lead_size);
 	dest = epc;
 		__build_load_reg( 8);
 		__build_load_reg( 9);

From macro@ds2.pg.gda.pl Mon Jan 26 18:08:36 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 26 Jan 2004 18:08:37 +0000 (GMT)
Received: from jurand.ds.pg.gda.pl ([IPv6:::ffff:153.19.208.2]:18132 "EHLO
	jurand.ds.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8225317AbUAZSIg>; Mon, 26 Jan 2004 18:08:36 +0000
Received: by jurand.ds.pg.gda.pl (Postfix, from userid 1011)
	id 8202D4C3C9; Mon, 26 Jan 2004 19:08:35 +0100 (CET)
Received: from localhost (localhost [127.0.0.1])
	by jurand.ds.pg.gda.pl (Postfix) with ESMTP
	id 660F04C3C3; Mon, 26 Jan 2004 19:08:35 +0100 (CET)
Date: Mon, 26 Jan 2004 19:08:35 +0100 (CET)
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To: Dimitri Torfs <dimitri@sonycom.com>,
	Ralf Baechle <ralf@linux-mips.org>
Cc: linux-mips@linux-mips.org
Subject: Re: Support for newer gcc/gas options
In-Reply-To: <20040125191726.GA18263@sonycom.com>
Message-ID: <Pine.LNX.4.55.0401261906410.26076@jurand.ds.pg.gda.pl>
References: <20031223114644.GA5458@sonycom.com>
 <Pine.LNX.4.55.0312231303030.27594@jurand.ds.pg.gda.pl>
 <Pine.LNX.4.55.0401201332080.12841@jurand.ds.pg.gda.pl> <20040120204026.GA9470@sonycom.com>
 <Pine.LNX.4.55.0401211449170.11137@jurand.ds.pg.gda.pl> <20040121145120.GA14288@sonycom.com>
 <20040121183551.GA21411@sonycom.com> <Pine.LNX.4.55.0401221700510.16353@jurand.ds.pg.gda.pl>
 <20040125191726.GA18263@sonycom.com>
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: 4138
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
Content-Length: 3827
Lines: 94

On Sun, 25 Jan 2004, Dimitri Torfs wrote:

> >  Thanks for digging into it.  Actually after fixing the typos I've noticed
> > gcc 2.95.4 always implies the ISA from the ABI unless overridden and
> > -mabi=64 implies -mips4, so it bails out with -march/-mcpu set to
> > something like r4600.  This also proves the uncertainity about what's
> > passed to gas and so far including an ISA specification in gas settings is
> > tolerable if carefully chosen.  So here's a set of new updates -- now the
> > ISA specifier is removed from gcc flags only if it actually works and the
> > ISA specifier for gas is untouched.
> > 
> >  Hopefully this is the last attempt.  Please try it.
> 
> Ok for me (tested the HEAD one).

 Thanks.  Ralf, OK to apply these?

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

patch-mips-2.4.23-20031209-mabi-8
diff -up --recursive --new-file linux-mips-2.4.23-20031209.macro/arch/mips/Makefile linux-mips-2.4.23-20031209/arch/mips/Makefile
--- linux-mips-2.4.23-20031209.macro/arch/mips/Makefile	2003-12-22 02:35:03.000000000 +0000
+++ linux-mips-2.4.23-20031209/arch/mips/Makefile	2004-01-21 23:53:31.000000000 +0000
@@ -98,6 +98,11 @@ while :; do \
 	gas_abi=; gas_opt=; gas_cpu=; gas_isa=; \
 	break; \
 done; \
+if test "$$gcc_opt" = -march= && test -n "$$gcc_abi"; then \
+	$(CC) $$gcc_abi $$gcc_opt$$gcc_cpu -S -o /dev/null \
+		-xc /dev/null > /dev/null 2>&1 && \
+		gcc_isa=; \
+fi; \
 echo $$gcc_abi $$gcc_opt$$gcc_cpu $$gcc_isa $$gas_abi $$gas_opt$$gas_cpu $$gas_isa)
 
 #
diff -up --recursive --new-file linux-mips-2.4.23-20031209.macro/arch/mips64/Makefile linux-mips-2.4.23-20031209/arch/mips64/Makefile
--- linux-mips-2.4.23-20031209.macro/arch/mips64/Makefile	2003-12-22 02:32:44.000000000 +0000
+++ linux-mips-2.4.23-20031209/arch/mips64/Makefile	2004-01-21 23:53:25.000000000 +0000
@@ -37,7 +37,7 @@ endif
 # crossformat linking we rely on the elf2ecoff tool for format conversion.
 #
 GCCFLAGS	:= -I $(TOPDIR)/include/asm/gcc
-GCCFLAGS	+= -mabi=64 -G 0 -mno-abicalls -fno-pic -Wa,--trap -pipe
+GCCFLAGS	+= -G 0 -mno-abicalls -fno-pic -Wa,--trap -pipe
 GCCFLAGS	+= $(call check_gcc, -finline-limit=100000,)
 LINKFLAGS	+= -G 0 -static # -N
 MODFLAGS	+= -mlong-calls
@@ -76,6 +76,7 @@ while :; do \
 	done; \
 	break; \
 done; \
+gcc_abi=-mabi=64; \
 gcc_cpu=$$cpu; gcc_isa=$$isa; \
 gas_cpu=$$cpu; gas_isa=-Wa,$$isa; \
 while :; do \
@@ -87,7 +88,12 @@ while :; do \
 	gas_opt=; gas_cpu=; gas_isa=; \
 	break; \
 done; \
-echo $$gcc_opt$$gcc_cpu $$gcc_isa $$gas_opt$$gas_cpu $$gas_isa)
+if test "$$gcc_opt" = -march=; then \
+	$(CC) $$gcc_abi $$gcc_opt$$gcc_cpu -S -o /dev/null \
+		-xc /dev/null > /dev/null 2>&1 && \
+		gcc_isa=; \
+fi; \
+echo $$gcc_abi $$gcc_opt$$gcc_cpu $$gcc_isa $$gas_opt$$gas_cpu $$gas_isa)
 
 #
 # CPU-dependent compiler/assembler options for optimization.


patch-mips-2.6.0-20040108-mabi-8
diff -up --recursive --new-file linux-mips-2.6.0-20040108.macro/arch/mips/Makefile linux-mips-2.6.0-20040108/arch/mips/Makefile
--- linux-mips-2.6.0-20040108.macro/arch/mips/Makefile	2004-01-07 04:56:39.000000000 +0000
+++ linux-mips-2.6.0-20040108/arch/mips/Makefile	2004-01-21 23:53:58.000000000 +0000
@@ -108,9 +108,14 @@ while :; do \
 	gas_abi=; gas_opt=; gas_cpu=; gas_isa=; \
 	break; \
 done; \
-if test x$(gcc-abi) != x$(gas-abi); then \
+if test "$(gcc-abi)" != "$(gas-abi)"; then \
 	gas_abi="-Wa,-$(gas-abi) -Wa,-mgp$(gcc-abi)"; \
 fi; \
+if test "$$gcc_opt" = -march= && test -n "$$gcc_abi"; then \
+	$(CC) $$gcc_abi $$gcc_opt$$gcc_cpu -S -o /dev/null \
+		-xc /dev/null > /dev/null 2>&1 && \
+		gcc_isa=; \
+fi; \
 echo $$gcc_abi $$gcc_opt$$gcc_cpu $$gcc_isa $$gas_abi $$gas_opt$$gas_cpu $$gas_isa)
 
 #

From philt@pioneer-pdt.com Mon Jan 26 20:10:06 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 26 Jan 2004 20:10:16 +0000 (GMT)
Received: from [IPv6:::ffff:207.215.131.7] ([IPv6:::ffff:207.215.131.7]:583
	"EHLO mail.pioneer-pdt.com") by linux-mips.org with ESMTP
	id <S8225361AbUAZUKG>; Mon, 26 Jan 2004 20:10:06 +0000
Received: from 127.0.0.1 (localhost.pioneer-pdt.com [127.0.0.1])
	by dummy.domain.name (Postfix) with SMTP id 05B5D9D833
	for <linux-mips@linux-mips.org>; Mon, 26 Jan 2004 12:06:33 -0800 (PST)
Received: from philt.pioneer-pdt.com (unknown [172.30.2.110])
	by mail.pioneer-pdt.com (Postfix) with ESMTP id 0621C9D828
	for <linux-mips@linux-mips.org>; Mon, 26 Jan 2004 12:06:27 -0800 (PST)
From: Patrick Hilt <philt@pioneer-pdt.com>
Organization: Pioneer
To: linux-mips@linux-mips.org
Subject: Reconfiguring chip select
Date: Mon, 26 Jan 2004 11:05:26 -0800
User-Agent: KMail/1.5.3
MIME-Version: 1.0
Content-Type: Multipart/Mixed;
  boundary="Boundary-00=_2TWFAJEHj8zvHrb"
Message-Id: <200401261105.26379.philt@pioneer-pdt.com>
Return-Path: <philt@pioneer-pdt.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: 4139
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: philt@pioneer-pdt.com
Precedence: bulk
X-list: linux-mips
Content-Length: 223833
Lines: 7840


--Boundary-00=_2TWFAJEHj8zvHrb
Content-Type: text/plain;
  charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Hello!
Hope everybody is doing well... even though it's Monday ;-)...

I'm working on a broadcom mips platform and I'm having a little bit of trouble 
with dynamically reconfiguring a chip select register. After the boot loader 
launches the kernel, I need to reconfigure the chip select register for CS0 
from 1FC0 0009 to 1900 000B. I actually got that to work without too much 
hassle.
Now the real problem, to jump back to the boot loader when "rebooting", I have 
reset the CS config register to it's original value before jumping. When I do 
that I get an oops (in init) from the kernel.

Does anyone have any suggestions on where best to place that reconfiguration 
code or how best to go about this whole business.

Thanks a lot in advance,

Patrick

PS: oops message and symbol table attached...


--Boundary-00=_2TWFAJEHj8zvHrb
Content-Type: text/plain;
  charset="us-ascii";
  name="System.map"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename="System.map"

00000000 A _binary_ramdisk_gz_start
004663b9 A _binary_ramdisk_gz_end
004663b9 A _binary_ramdisk_gz_size
80001000 T _ftext
8000240c T except_vec2_generic
80002434 T except_vec4
8000243c T except_vec_ejtag_debug
80002444 T ejtag_debug_handler
800025fc t ejtag_return
80002608 T except_vec_nmi
80002610 T nmi_handler
800027a4 T kernel_entry
800027a4 T stext
800027a4 T _stext
80003000 T swapper_pg_dir
80004000 T empty_bad_page
80005000 T empty_bad_page_table
80006000 T invalid_pte_table
80008000 t dummy
80008000 t rest_init
8000802c t do_linuxrc
80008120 t prepare_namespace
800082e4 t init
80008480 T __compute_return_epc
80008790 T cpu_idle
800087f8 T exit_thread
80008858 T flush_thread
800088b8 T copy_thread
80008a24 T dump_fpu
80008a88 T dump_thread
80008b84 T kernel_thread
80008bec T get_wchan
80008cf0 T copy_siginfo_to_user
80008dd8 T sys_sigsuspend
80008dfc t _sys_sigsuspend
80008f70 T sys_rt_sigsuspend
80008f94 t _sys_rt_sigsuspend
80009120 T sys_sigaction
80009294 T sys_sigaltstack
800092c8 t restore_sigcontext
80009614 T sys_sigreturn
80009780 T sys_rt_sigreturn
800098fc T do_signal
80009d84 t sigorsets
80009dc8 t has_pending_signals
80009e1c t restore_thread_fp_context
8000a138 t setup_frame
8000a2a8 t setup_rt_frame
8000a488 t setup_sigcontext
8000a7fc t save_thread_fp_context
8000ab20 T ret_from_fork
8000ab40 t tracesys_exit
8000ab50 T ret_from_exception
8000ab50 T ret_from_irq
8000ab68 t reschedule
8000ab70 T ret_from_sys_call
8000aba4 T restore_all
8000ac64 t signal_return
8000aca0 T spurious_interrupt
8000acc0 T handle_adel
8000ad8c T handle_adel_int
8000adc0 T handle_ades
8000ae8c T handle_ades_int
8000aec0 T handle_ibe
8000af8c T handle_ibe_int
8000afc0 T handle_dbe
8000b08c T handle_dbe_int
8000b0c0 T handle_bp
8000b18c T handle_bp_int
8000b1c0 T handle_ri
8000b28c T handle_ri_int
8000b2c0 T handle_cpu
8000b38c T handle_cpu_int
8000b3c0 T handle_ov
8000b48c T handle_ov_int
8000b4c0 T handle_tr
8000b58c T handle_tr_int
8000b5c0 T handle_fpe
8000b68c T handle_fpe_int
8000b6e0 T handle_watch
8000b7ac T handle_watch_int
8000b7e0 T handle_mcheck
8000b8ac T handle_mcheck_int
8000b8e0 T handle_reserved
8000b9ac T handle_reserved_int
8000b9e0 T show_stack
8000bab8 T show_trace
8000bc20 T show_trace_task
8000bc3c T show_code
8000bcd0 T show_regs
8000be28 T show_registers
8000be88 T __die
8000bf3c T __die_if_kernel
8000bf68 T __declare_dbe_table
8000bf70 t default_be_board_handler
8000c024 T do_ibe
8000c048 T do_dbe
8000c06c T do_ov
8000c0c4 T do_fpe
8000c178 T do_bp
8000c22c T do_tr
8000c2ec T do_ri
8000c388 T do_cpu
8000c4c0 T do_watch
8000c4e8 T do_mcheck
8000c504 T do_reserved
8000c520 T cache_parity_error
8000c6e0 T ejtag_exception_handler
8000c764 T nmi_exception_handler
8000c7a0 T set_except_vector
8000c830 t search_dbe_table
8000c950 T ptrace_disable
8000c958 T sys_ptrace
8000cf68 T syscall_trace
8000cfe0 T sys_vm86
8000cff0 T sys_ioperm
8000cff8 T sys_iopl
8000d000 T machine_restart
8000d024 T machine_halt
8000d048 T machine_power_off
8000d070 T __up
8000d0ac T __down
8000d160 T __down_interruptible
8000d284 T __down_trylock
8000d300 T r3081_wait
8000d318 T r39xx_wait
8000d330 T r4k_wait
8000d33c t check_wait
8000d3e0 t cpu_probe
8000da84 t parse_mem_cmdline
8000dbf0 T sys_pipe
8000dc34 T old_mmap
8000dd18 T sys_mmap2
8000dde4 T sys_fork
8000de08 t _sys_fork
8000de40 T sys_clone
8000de64 t _sys_clone
8000dea8 T sys_execve
8000df2c T sys_uname
8000df80 T sys_olduname
8000e048 T sys_syscall
8000e1e0 T bad_stack
8000e1f0 T _sys_sysmips
8000e358 T sys_cachectl
8000e360 T sys_pause
8000e390 T sys_ipc
8000e5e0 T handle_sys
8000e6a8 t stack_done
8000e6e0 T o32_ret_from_sys_call
8000e70c t restore_all
8000e770 t signal_return
8000e7b8 t o32_reschedule
8000e7c8 t trace_a_syscall
8000e834 t stackargs
8000e894 t bad_stack
8000e8ac t illegal_syscall
8000e8c0 T mips_atomic_set
8000e944 t no_mem
8000e94c t bad_address
8000e954 t bad_alignment
8000e95c T sys_sysmips
8000e980 T do_ade
8000ea58 t emulate_load_store_insn
8000ecb0 T _save_fp_context
8000ed08 T _restore_fp_context
8000ed58 t fault
8000ed60 T resume
8000edf8 T lazy_fpu_switch
8000eeb4 T save_fp
8000ef00 T restore_fp
8000ef50 T init_fpu
8000efc0 T no_action
8000efc8 t enable_none
8000efd0 t startup_none
8000efd8 t disable_none
8000efe0 t ack_none
8000f008 T get_irq_list
8000f184 T handle_IRQ_event
8000f280 T disable_irq
8000f350 T enable_irq
8000f440 T do_IRQ
8000f55c T request_irq
8000f648 T free_irq
8000f760 T probe_irq_on
8000f9e8 T probe_irq_mask
8000fb08 T probe_irq_off
8000fc28 T setup_irq
8000fd88 t parse_hex_value
8000fe54 t prof_cpu_mask_read_proc
8000fe90 t prof_cpu_mask_write_proc
8000fee4 t register_irq_proc
8000ff98 T init_irq_proc
80010030 T disable_irq_nosync
800100e0 t null_rtc_get_time
800100ec t null_rtc_set_time
800100f4 T do_gettimeofday
800101e0 T do_settimeofday
800102bc T null_gettimeoffset
800102c4 T fixed_rate_gettimeoffset
800102f8 T calibrate_div32_gettimeoffset
80010408 T calibrate_div64_gettimeoffset
80010498 T local_timer_interrupt
80010520 T timer_interrupt
80010674 T ll_timer_interrupt
800106f0 T ll_local_timer_interrupt
8001076c T to_tm
80010920 t show_cpuinfo
80010bcc t c_start
80010bd8 t c_next
80010c10 t c_stop
80010c20 T pci_alloc_consistent
80010cec T pci_free_consistent
80010d40 T search_exception_table
80010e30 T sys_cacheflush
80010e58 T do_check_pgt_cache
80010f4c T show_mem
800110b0 T free_initrd_mem
80011188 T free_initmem
80011278 T si_meminfo
800112e0 t remap_area_pages
800114a4 T __ioremap
80011634 T iounmap
80011680 t remap_area_pte
80011780 T bust_spinlocks
800117e8 T do_page_fault
80011b80 T mips32_clear_page_dc
80011bf4 T mips32_clear_page_sc
80011c68 T mips32_copy_page_dc
80011cd0 T mips32_copy_page_sc
80011d38 T pgd_init
80011d80 t no_sc_noop
80011d88 T bcm_inv_rac_all
80011db8 t mips32_flush_cache_range_sc
80011fe0 t mips32_flush_cache_range_pc
800120cc t mips32_flush_cache_mm_sc
800121d8 t mips32_flush_cache_mm_pc
800122c4 t mips32_flush_cache_page_sc
80012414 t mips32_flush_cache_page_pc
8001254c t mips32_flush_page_to_ram_sc
80012584 t mips32_flush_page_to_ram_pc
800125d0 t mips32_flush_icache_page_s
800125d8 t mips32_flush_icache_range
800125fc t mips32_flush_icache_page
8001266c t mips32_dma_cache_wback_inv_pc
80012718 t mips32_dma_cache_wback_inv_sc
80012778 t mips32_dma_cache_inv_pc
8001287c t mips32_dma_cache_inv_sc
800128dc t mips32_dma_cache_wback
800128f4 t mips32_flush_cache_sigtramp
80012924 t mips32_flush_icache_all
80012980 t mips32_flush_cache_all_sc
80012a80 t mips32_flush_cache_all_pc
80012b60 T local_flush_tlb_all
80012c74 T local_flush_tlb_mm
80012d44 T local_flush_tlb_range
80012f30 T local_flush_tlb_page
80013048 T update_mmu_cache
800131c0 T handle_tlbl
800131c0 t invalid_tlbl
80013244 t nopage_tlbl
80013340 T handle_tlbs
800133c8 t nopage_tlbs
800134e0 T handle_mod
80013560 t nowrite_mod
80013660 T scheduling_functions_start_here
8001367c t reschedule_idle
80013758 t process_timeout
80013784 T schedule_timeout
80013864 T schedule_tail
80013890 T schedule
80013d0c T __wake_up
80013e0c T __wake_up_sync
80013f0c T complete
80014008 T wait_for_completion
80014124 T interruptible_sleep_on
800141f0 T interruptible_sleep_on_timeout
800142c4 T sleep_on
80014390 T sleep_on_timeout
80014464 T scheduling_functions_end_here
80014480 T sys_nice
80014514 t setscheduler
80014724 T sys_sched_setscheduler
8001474c T sys_sched_setparam
8001477c T sys_sched_getscheduler
80014810 T sys_sched_getparam
800148e8 T sys_sched_yield
80014998 T sys_sched_get_priority_max
800149d4 T sys_sched_get_priority_min
80014a10 T sys_sched_rr_get_interval
80014b58 t show_task
80014d1c T render_sigset_t
80014e10 T show_state
80014e88 T reparent_to_init
80014fc8 T daemonize
80015068 T wake_up_process
80015094 t ffz
80015110 t try_to_wake_up
800151f0 T get_dma_list
80015280 T request_dma
800152d8 T free_dma
80015360 T add_wait_queue
800153d4 T add_wait_queue_exclusive
80015444 T remove_wait_queue
800154a0 t get_pid
80015628 t mm_init
8001572c T mm_alloc
80015784 T mmput
80015894 T mm_release
800158bc t copy_mm
80015a10 T copy_fs_struct
80015b54 t count_open_files
80015b94 t copy_files
80015de0 T do_fork
800165b8 T __mmdrop
8001663c t dget
800166b0 t dup_mmap
800168e0 t default_handler
80016964 t lookup_exec_domain
80016a58 T register_exec_domain
80016ab0 T unregister_exec_domain
80016af8 T __set_personality
80016c1c T get_exec_domain_list
80016cb4 T sys_personality
80016d10 T panic
80016e64 T print_tainted
80016f00 T do_syslog
8001741c T sys_syslog
80017470 t __call_console_drivers
80017504 t _call_console_drivers
8001757c t call_console_drivers
800176f0 t emit_log_char
8001777c T printk
800179d0 T acquire_console_sem
80017a68 T release_console_sem
80017ba0 T console_conditional_schedule
80017be0 T console_print
80017c08 T console_unblank
80017c7c T register_console
80017ee4 T unregister_console
80017f88 T tty_write_message
80017ff0 T inter_module_register
80018134 T inter_module_unregister
8001820c T inter_module_get
800182a8 T inter_module_get_request
800182f8 T inter_module_put
800183c0 T sys_create_module
80018594 T sys_init_module
80018e20 T try_inc_mod_count
80018e64 T sys_delete_module
800190f4 t qm_modules
80019264 t qm_deps
80019460 t qm_refs
80019614 t qm_symbols
8001983c t qm_info
80019908 T sys_query_module
80019b00 T sys_get_kernel_syms
80019ccc T find_module
80019d34 T free_module
80019e8c T get_module_list
8001a298 t s_start
8001a348 t s_next
8001a3cc t s_stop
8001a408 t s_show
8001a4a0 T release_task
8001a584 T session_of_pgrp
8001a5d8 t will_become_orphaned_pgrp
8001a664 T is_orphaned_pgrp
8001a680 T put_files_struct
8001a7cc T exit_files
8001a7f8 T put_fs_struct
8001a918 T exit_fs
8001aa44 T start_lazy_tlb
8001aa6c T end_lazy_tlb
8001ab28 T exit_mm
8001aba8 t exit_notify
8001af1c T do_exit
8001b1d0 T complete_and_exit
8001b1f4 T sys_exit
8001b208 T sys_wait4
8001b5fc T sys_waitpid
8001b618 t unhash_process
8001b710 t tvtojiffies
8001b764 t jiffiestotv
8001b7b8 T do_getitimer
8001b864 T sys_getitimer
8001b8dc T it_real_fn
8001b93c T do_setitimer
8001ba4c T sys_setitimer
8001bb20 T sys_sysinfo
8001bcf0 T sys_time
8001bd4c T sys_stime
8001be28 T sys_gettimeofday
8001bec4 T do_sys_settimeofday
8001bfbc T sys_settimeofday
8001c06c T do_adjtimex
8001c5e8 T sys_adjtimex
8001c690 T do_softirq
8001c814 T raise_softirq
8001c8cc T open_softirq
8001c8e8 T __tasklet_schedule
8001c9ac T __tasklet_hi_schedule
8001ca70 t tasklet_action
8001cbc4 t tasklet_hi_action
8001cd18 T tasklet_init
8001cd30 T tasklet_kill
8001cdfc t bh_action
8001ce88 T init_bh
8001cec0 T remove_bh
8001cf08 T __run_task_queue
8001cfe8 t ksoftirqd
8001d0c0 T cpu_raise_softirq
8001d130 t do_resource_list
8001d200 T get_resource_list
8001d25c t __request_resource
8001d2dc t __release_resource
8001d314 T request_resource
8001d344 T release_resource
8001d360 T check_resource
8001d3ac t find_resource
8001d4e4 T allocate_resource
8001d560 T __request_region
8001d62c T __check_region
8001d678 T __release_region
8001d720 T do_sysctl
8001d85c T sys_sysctl
8001d8d4 t test_perm
8001d940 t parse_table
8001dab8 T do_sysctl_strategy
8001dc9c T register_sysctl_table
8001dd44 T unregister_sysctl_table
8001dd8c t register_proc_table
8001defc t unregister_proc_table
8001dfb4 t do_rw_proc
8001e07c t proc_readsys
8001e0b4 t proc_writesys
8001e0ec t proc_sys_permission
8001e108 T proc_dostring
8001e368 t proc_doutsstring
8001e430 t do_proc_dointvec
8001e8b0 T proc_dointvec
8001e8dc T proc_dointvec_bset
8001e94c T proc_dointvec_minmax
8001ed94 t do_proc_doulongvec_minmax
8001f24c T proc_doulongvec_minmax
8001f278 T proc_doulongvec_ms_jiffies_minmax
8001f2a8 T proc_dointvec_jiffies
8001f2d4 T sysctl_string
8001f4b4 T sysctl_intvec
8001f58c T sysctl_jiffies
8001f6d0 T sys_acct
8001f6e0 T sys_capget
8001f83c t cap_set_pg
8001f890 t cap_set_all
8001f8f0 T sys_capset
8001fb60 T ptrace_check_attach
8001fba4 T ptrace_attach
8001fdf8 T ptrace_detach
8001ff0c T access_process_vm
800200bc T ptrace_readdata
800201a0 T ptrace_writedata
800202a0 T init_timervecs
8002032c T add_timer
800203e0 T mod_timer
80020474 T del_timer
800204e4 T tqueue_bh
8002051c T immediate_bh
80020554 t second_overflow
8002086c t update_wall_time_one_tick
80020970 t update_wall_time
800209ec T update_one_process
80020b38 T update_process_times
80020c34 t count_active_tasks
80020c84 T timer_bh
80020de4 T do_timer
80020ea8 T sys_alarm
80020ef0 T sys_getpid
80020ef8 T sys_getppid
80020f04 T sys_getuid
80020f0c T sys_geteuid
80020f14 T sys_getgid
80020f1c T sys_getegid
80020f24 T sys_gettid
80020f2c T sys_nanosleep
80021160 t internal_add_timer
80021264 t run_timer_list
80021470 T free_uid
800214cc T alloc_uid
80021600 t next_signal
80021670 t flush_sigqueue
800216fc T flush_signals
80021720 T exit_sighand
800217c0 T flush_signal_handlers
8002182c T block_all_signals
80021884 T unblock_all_signals
80021934 t collect_signal
80021b28 T dequeue_signal
80021c30 t rm_from_queue
80021d28 t rm_sig_from_queue
80021d44 T bad_signal
80021dec t signal_type
80021e60 t ignored_signal
80021ec4 t handle_stop_signal
80021f68 t send_signal
80022144 t deliver_signal
800221dc T send_sig_info
80022308 T force_sig_info
80022440 T kill_pg_info
800224f0 T kill_sl_info
800225ac t kill_something_info
8002270c T send_sig
80022734 T force_sig
80022754 T kill_pg
80022780 T kill_sl
800227ac T kill_proc
80022820 t wake_up_parent
8002286c T do_notify_parent
80022930 T notify_parent
8002294c T sys_rt_sigprocmask
80022bbc T do_sigpending
80022c84 T sys_rt_sigpending
80022ca0 T sys_rt_sigtimedwait
8002302c T sys_kill
8002306c T sys_rt_sigqueueinfo
80023138 T do_sigaction
80023320 T do_sigaltstack
80023448 T sys_sigpending
80023464 T sys_sigprocmask
80023624 T sys_rt_sigaction
800236fc T sys_sgetmask
80023704 T sys_ssetmask
800237dc T kill_proc_info
80023848 t ffz
800238ac t sigorsets
800238f0 t sigandsets
80023934 t signandsets
80023988 t recalc_sigpending
800239f0 T notifier_chain_register
80023a34 T notifier_chain_unregister
80023a6c T notifier_call_chain
80023ae0 T register_reboot_notifier
80023b08 T unregister_reboot_notifier
80023b30 T sys_ni_syscall
80023b38 t proc_sel
80023bb8 T sys_setpriority
80023d30 T sys_getpriority
80023de8 T sys_reboot
80023ff0 t deferred_cad
80024020 T ctrl_alt_del
8002406c T sys_setregid
80024198 T sys_setgid
80024280 t set_user
8002433c T sys_setreuid
800244ec T sys_setuid
80024614 T sys_setresuid
800247ac T sys_getresuid
80024828 T sys_setresgid
80024958 T sys_getresgid
800249d4 T sys_setfsuid
80024ac4 T sys_setfsgid
80024b60 T sys_times
80024bd4 T sys_setpgid
80024cf0 T sys_getpgid
80024d58 T sys_getpgrp
80024d60 T sys_getsid
80024dc8 T sys_setsid
80024e2c T sys_getgroups
80024e9c T sys_setgroups
80024f28 t supplemental_group_member
80024f5c T in_group_p
80024f8c T in_egroup_p
80024fbc T sys_newuname
8002507c T sys_sethostname
80025164 T sys_gethostname
80025224 T sys_setdomainname
8002530c T sys_getrlimit
8002537c T sys_old_getrlimit
80025418 T sys_setrlimit
8002550c T getrusage
80025790 T sys_getrusage
800257d0 T sys_umask
800257f8 T sys_prctl
800258e4 t cap_emulate_setxuid
80025970 T exec_usermodehelper
80025b8c t exec_modprobe
80025c38 T request_module
80025f60 t ____call_usermodehelper
80025fa0 t __call_usermodehelper
80025fe4 T call_usermodehelper
800260d8 T dev_probe_lock
80026124 T dev_probe_unlock
80026170 t use_init_fs_context
800264f0 t need_keventd
80026534 T current_is_keventd
80026574 T schedule_task
8002664c t context_thread
80026900 T flush_scheduled_tasks
80026988 T start_context_thread
800269d0 t put_unused_fd
80026a20 T __free_pte
80026ac0 T check_pgt_cache
80026ae8 T clear_page_tables
80026bfc T copy_page_range
80026e6c T zap_page_range
80026fdc t follow_page
80027094 T get_user_pages
80027338 T map_user_kiobuf
8002748c T mark_dirty_kiobuf
80027528 T unmap_kiobuf
800275cc T lock_kiovec
80027750 T unlock_kiovec
8002780c T zeromap_page_range
80027a80 T remap_page_range
80027d34 t do_wp_page
8002804c t vmtruncate_list
800280e0 T vmtruncate
80028284 T swapin_readahead
80028308 t do_swap_page
800284e8 t do_anonymous_page
80028688 t do_no_page
80028864 T handle_mm_fault
800289ac T __pmd_alloc
80028a1c T pte_alloc
80028b34 T make_pages_present
80028c28 t zap_pte_range
80028db0 T vm_enough_memory
80028e64 T lock_vma_mappings
80028e6c T unlock_vma_mappings
80028e74 T sys_brk
80028fb8 t find_vma_prepare
80029038 t __vma_link
80029118 t vma_merge
80029260 T do_mmap_pgoff
800297dc T get_unmapped_area
80029940 T find_vma
800299c0 T find_vma_prev
80029ab0 T find_extend_vma
80029bd0 t unmap_fixup
80029dc0 t free_pgtables
80029e8c T do_munmap
8002a190 T sys_munmap
8002a1fc T do_brk
8002a43c T build_mmap_rb
8002a4b4 T exit_mmap
8002a654 T __insert_vm_struct
8002a6fc T insert_vm_struct
8002a7e0 t add_page_to_hash_queue
8002a868 T __remove_inode_page
8002a964 T remove_inode_page
8002a9c4 T set_page_dirty
8002aa4c T invalidate_inode_pages
8002ab34 t do_flushpage
8002ab74 t truncate_complete_page
8002abfc t truncate_list_pages
8002ae00 T truncate_inode_pages
8002aeb0 t invalidate_list_pages2
8002afd8 T invalidate_inode_pages2
8002b040 t do_buffer_fdatasync
8002b144 T generic_buffer_fdatasync
8002b238 T fail_writepage
8002b2ac T filemap_fdatasync
8002b3ec T filemap_fdatawait
8002b4c8 T add_to_page_cache_locked
8002b5bc T add_to_page_cache
8002b674 T add_to_page_cache_unique
8002b750 t page_cache_read
8002b878 t read_cluster_nonblocking
8002b920 T ___wait_on_page
8002b9f4 T unlock_page
8002ba9c t __lock_page
8002bb88 T lock_page
8002bbcc T __find_get_page
8002bc1c T find_trylock_page
8002bcb4 t __find_lock_page_helper
8002bd90 T __find_lock_page
8002bdac T find_or_create_page
8002bf08 T grab_cache_page
8002bf24 T grab_cache_page_nowait
8002c054 t generic_file_readahead
8002c23c T mark_page_accessed
8002c2b8 T do_generic_file_read
8002c7e0 t generic_file_direct_IO
8002ca8c T file_read_actor
8002cb00 T generic_file_read
8002cc98 t file_send_actor
8002cd74 T sys_sendfile
8002cfdc t do_readahead
8002d0c8 T sys_readahead
8002d160 t nopage_sequential_readahead
8002d338 T filemap_nopage
8002d648 T filemap_sync
8002d758 T generic_file_mmap
8002d7e4 t msync_interval
8002d944 T sys_msync
8002da88 t madvise_fixup_start
8002dbf8 t madvise_fixup_end
8002dd68 t madvise_fixup_middle
8002df9c t madvise_behavior
8002e060 t madvise_willneed
8002e244 t madvise_dontneed
8002e284 t madvise_vma
8002e2e4 T sys_madvise
8002e41c t mincore_page
8002e4b0 t mincore_vma
8002e608 T sys_mincore
8002e75c T read_cache_page
8002e864 T generic_file_write
8002f0c4 T remove_suid
8002f144 t invalidate_this_page2
8002f270 t filemap_sync_pmd_range
8002f410 t __read_cache_page
8002f548 t filemap_sync_pte
8002f620 t change_protection
8002f77c t mprotect_fixup
8002fa10 T sys_mprotect
8002fc40 t change_pte_range
8002fd24 t mprotect_fixup_start
8002fec0 t mprotect_fixup_middle
800300c0 t mlock_fixup
80030360 t do_mlock
800304a0 T sys_mlock
80030560 T sys_munlock
800305d8 t do_mlockall
80030694 T sys_mlockall
80030734 T sys_munlockall
80030778 t mlock_fixup_middle
80030970 t move_one_page
80030a10 t move_page_tables
80030b20 T do_mremap
80030e58 T sys_mremap
80030edc t get_one_pte
80030f98 t move_vma
80031380 T vmfree_area_pages
80031484 T get_vm_area
80031558 T vfree
800315ec T __vmalloc
80031744 T remap_page_array
80031880 T vread
8003192c T vwrite
800319d0 T vmalloc_area_pages
800319ec t free_area_pte
80031b5c t alloc_area_pmd
80031c3c t _vmalloc_area_pages
80031db0 t alloc_area_pte
80031ef0 t kmem_cache_estimate
80031f9c t kmem_slab_destroy
800320d4 T kmem_cache_create
800325b0 t __kmem_cache_shrink
800326a4 T kmem_cache_shrink
8003270c T kmem_cache_destroy
800328d0 t kmem_cache_grow
80032ca8 T kmem_cache_alloc
80032cc4 T kmalloc
80032d2c T kmem_cache_free
80032d94 T kmem_cache_zalloc
80032ddc T kfree
80032e70 T kmem_find_general_cachep
80032ebc T kmem_cache_reap
800331cc t proc_getdata
800334d0 T slabinfo_read_proc
80033544 T slabinfo_write_proc
8003354c t __kmem_cache_alloc
80033718 t kmem_cache_free_one
800337f0 T activate_page
8003380c T lru_cache_add
800338f0 T __lru_cache_del
80033990 T lru_cache_del
800339ac t activate_page_nolock
80033ad0 t swap_out
80033c18 t shrink_cache
800340d0 t refill_inactive
800342a4 t shrink_caches
80034380 T try_to_free_pages
80034404 t check_classzone_need_balance
80034444 t kswapd_balance_pgdat
80034528 t kswapd_balance
80034570 t kswapd_can_sleep_pgdat
800345c0 t kswapd_can_sleep
80034604 T kswapd
800346f8 t swap_out_mm
800348e0 t swap_out_pmd
80034a88 t try_to_swap_out
80034cb0 t rw_swap_page_base
80034e20 T rw_swap_page
80034f18 T rw_swap_page_nolock
80035060 t __free_pages_ok
80035588 t rmqueue
800359fc T _alloc_pages
80035a2c t balance_classzone
80035d98 T __alloc_pages
80035fcc T __get_free_pages
80036008 T get_zeroed_page
8003604c T __free_pages
800360a0 T free_pages
800360e8 T nr_free_pages
80036130 T nr_free_buffer_pages
80036180 T start_aggressive_readahead
800361dc T show_free_areas_core
800363ac T show_free_areas
800363d0 t build_zonelists
80036530 t swap_writepage
8003657c T show_swap_cache_info
800365c8 T add_to_swap_cache
80036734 T __delete_from_swap_cache
800367f0 T delete_from_swap_cache
80036878 T free_page_and_swap_cache
800368ec T lookup_swap_cache
80036974 T read_swap_cache_async
80036a90 T get_swap_page
80036bf0 t swap_info_get
80036d14 t swap_info_put
80036d1c t swap_entry_free
80036d80 T swap_free
80036dd0 t exclusive_swap_page
80036e64 T can_share_swap_page
80036f34 T remove_exclusive_swap_page
80037084 T free_swap_and_cache
80037184 t unuse_vma
80037250 t unuse_process
800372c8 t find_next_to_unuse
80037328 t try_to_unuse
80037718 T sys_swapoff
80037a1c T get_swaparea_info
80037c98 T is_swap_partition
80037cec T sys_swapon
80038458 T si_swapinfo
8003851c T swap_duplicate
80038634 T swap_count
80038710 T get_swaphandle_info
80038844 T valid_swaphandles
800388f8 t scan_swap_map
80038a80 t unuse_pgd
80038c3c t unuse_pte
80038d00 T alloc_pages_node
80038d40 t int_sqrt
80038d84 t badness
80038e94 t select_bad_process
80038f28 T oom_kill_task
80038f98 t oom_kill
80039030 T out_of_memory
800390e0 t shmem_recalc_inode
8003912c t shmem_swp_entry
800391d0 t shmem_free_swp
8003924c t shmem_truncate
80039364 t shmem_delete_inode
800393e8 t shmem_clear_swp
8003945c t shmem_unuse_inode
80039588 T shmem_unuse
800395fc t shmem_writepage
800397c0 t shmem_getpage_locked
80039b3c t shmem_getpage
80039ca4 T shmem_nopage
80039d04 T shmem_lock
80039da0 t shmem_mmap
80039e08 T shmem_get_inode
80039f9c t shmem_set_size
80039ff0 t shmem_file_write
8003a410 t do_shmem_file_read
8003a55c t shmem_file_read
8003a5cc t shmem_statfs
8003a618 t shmem_lookup
8003a650 t shmem_mknod
8003a708 t shmem_mkdir
8003a750 t shmem_create
8003a770 t shmem_link
8003a84c t shmem_empty
8003a898 t shmem_unlink
8003a8dc t shmem_rmdir
8003a93c t shmem_rename
8003a9dc t shmem_symlink
8003abcc t shmem_readlink_inline
8003abec t shmem_follow_link_inline
8003ac14 t shmem_readlink
8003aca0 t shmem_follow_link
8003ad0c t shmem_parse_options
8003b028 t shmem_remount_fs
8003b0a0 T shmem_sync_file
8003b0a8 t shmem_read_super
8003b1ec T shmem_file_setup
8003b368 T shmem_zero_setup
8003b3f4 t shmem_truncate_indirect
8003b50c t shmem_truncate_direct
8003b630 T vfs_statfs
8003b6ac T sys_statfs
8003b75c T sys_fstatfs
8003b7fc T do_truncate
8003b8d4 T sys_truncate
8003b8f4 T sys_ftruncate
8003b91c T sys_truncate64
8003b938 T sys_ftruncate64
8003b954 T sys_utime
8003ba5c T sys_utimes
8003bb40 T sys_access
8003bc70 T sys_chdir
8003bdf8 T sys_fchdir
8003bf48 T sys_chroot
8003c0fc T sys_fchmod
8003c1ac T sys_chmod
8003c258 t chown_common
8003c354 T sys_chown
8003c3c4 T sys_lchown
8003c434 T sys_fchown
8003c498 T filp_open
8003c4fc T dentry_open
8003c740 T get_unused_fd
8003c8f4 T sys_open
8003ca34 T sys_creat
8003ca54 T filp_close
8003caf4 T sys_close
8003cba0 T sys_vhangup
8003cbf8 T generic_file_open
8003cc3c t do_sys_truncate
8003ce44 t do_sys_ftruncate
8003d010 T generic_read_dir
8003d018 T generic_file_llseek
8003d100 T no_llseek
8003d10c T default_llseek
8003d1bc T sys_lseek
8003d270 T sys_llseek
8003d370 T sys_read
8003d4f0 T sys_write
8003d674 t do_readv_writev
8003d994 T sys_readv
8003da34 T sys_writev
8003dad4 T sys_pread
8003dc58 T sys_pwrite
8003dde0 T get_device_list
8003de88 t get_chrfops
8003e00c T register_chrdev
8003e0ac T unregister_chrdev
8003e120 T chrdev_open
8003e198 T kdevname
8003e1e0 T cdevname
8003e248 t sock_no_open
8003e250 T init_special_inode
8003e320 T get_empty_filp
8003e498 T init_private_file
8003e52c T fput
8003e6c8 T fget
8003e714 T put_filp
8003e77c T file_move
8003e7b0 T fs_may_remount_ro
8003e820 T _write_buffer
8003e90c T unlock_buffer
8003e994 T __wait_on_buffer
8003ea94 T end_buffer_io_sync
8003eb0c t write_locked_buffers
8003eb64 t write_some_buffers
8003ecf0 t write_unlocked_buffers
8003ed44 t wait_for_buffers
8003ee64 t wait_for_locked_buffers
8003eeb4 T sync_buffers
8003ef34 T fsync_super
8003f020 T fsync_no_super
8003f058 T fsync_dev
8003f0a0 T sync_dev
8003f0bc T sys_sync
8003f0dc T file_fsync
8003f1b4 T sys_fsync
8003f2e8 T sys_fdatasync
8003f41c t __insert_into_lru_list
8003f500 t __remove_from_lru_list
8003f590 t __remove_from_queues
8003f5cc t remove_from_queues
8003f5e8 T get_hash_table
8003f694 T buffer_insert_inode_queue
8003f6d8 T buffer_insert_inode_data_queue
8003f71c t __remove_inode_queue
8003f734 T inode_has_buffers
8003f760 T invalidate_bdev
8003f970 T __invalidate_buffers
8003f9c0 t free_more_memory
8003fa3c T init_buffer
8003fa4c t end_buffer_io_async
8003fbb8 T fsync_inode_buffers
8003fd98 T fsync_inode_data_buffers
8003ff78 T osync_inode_buffers
80040040 T osync_inode_data_buffers
80040108 T invalidate_inode_buffers
800401a0 T getblk
80040218 t balance_dirty_state
800402b8 T balance_dirty
80040310 T __mark_buffer_dirty
80040368 T mark_buffer_dirty
800403c8 T set_buffer_flushtime
800403e4 t __refile_buffer
80040470 T refile_buffer
8004048c T __brelse
800404dc T __bforget
80040538 T bread
800405dc t __put_unused_buffer_head
8004068c T put_unused_buffer_head
800406a8 T get_unused_buffer_head
80040774 T set_bh_page
800407e8 t create_buffers
800408fc t discard_buffer
80040a30 T try_to_release_page
80040adc T discard_bh_page
80040bbc T create_empty_buffers
80040c70 t unmap_underlying_metadata
80040d24 t __block_write_full_page
80041044 t __block_prepare_write
800413e4 t __block_commit_write
80041558 T block_read_full_page
80041820 T generic_cont_expand
8004197c T cont_prepare_write
80041be0 T block_prepare_write
80041c44 T block_commit_write
80041c7c T generic_commit_write
80041d24 T block_truncate_page
80041f20 T block_write_full_page
80042044 T writeout_one_page
800420e4 T waitfor_one_page
80042168 T generic_block_bmap
8004219c T generic_direct_IO
80042374 t end_buffer_io_kiobuf
800423e8 t wait_kio
800424ac T brw_kiovec
80042858 T brw_page
800429a4 T block_symlink
80042ae8 t grow_dev_page
80042bf8 t hash_page_buffers
80042d18 t grow_buffers
80042ee4 t sync_page_buffers
80043038 T try_to_free_buffers
800431b4 T show_buffers
8004320c T wakeup_bdflush
80043234 t sync_old_buffers
80043294 T block_sync_page
800432d0 T sys_bdflush
800433cc T bdflush
80043500 T kupdate
8004373c T set_buffer_async_io
80043764 T __mark_dirty
80043794 t write_buffer_locked
80043880 t get_filesystem
800438b8 t put_filesystem
800438f0 t find_filesystem
80043950 T register_filesystem
800439c4 T unregister_filesystem
80043a08 t fs_index
80043aa4 t fs_name
80043b64 t fs_maxindex
80043b88 T sys_sysfs
80043c08 T get_filesystem_list
80043c98 T get_fs_type
80043d2c t alloc_super
80043e68 t grab_super
80043f1c t insert_super
80043f78 t remove_super
80044034 T drop_super
80044080 T sync_supers
8004427c T get_super
8004430c T sys_ustat
800443fc t read_super
80044584 T get_unnamed_dev
800445e0 T put_unnamed_dev
8004466c t get_sb_bdev
80044994 t get_sb_nodev
80044a0c t get_sb_single
80044bdc T kill_super
80044da0 T do_remount_sb
80044f0c T do_kern_mount
800450ec T kern_mount
80045120 t max_block
800451c4 t blkdev_size
8004520c t kill_bdev
80045248 T set_blocksize
800453a8 t blkdev_get_block
80045414 t blkdev_direct_IO
80045440 t blkdev_writepage
80045464 t blkdev_readpage
8004548c t blkdev_prepare_write
800454bc t blkdev_commit_write
800454e0 t block_llseek
800455d8 t __block_fsync
80045660 t block_fsync
80045680 t bd_read_super
80045794 t init_once
80045804 t bdfind
80045850 T bdget
800459b0 T bdput
80045a8c T bd_acquire
80045b4c T bd_forget
80045b84 T get_blkdev_list
80045c20 T get_blkfops
80045c94 T register_blkdev
80045d34 T unregister_blkdev
80045da4 T check_disk_change
80045e78 T ioctl_by_bdev
80045ed0 t do_open
800460f4 T blkdev_get
80046188 T blkdev_open
800461d4 T blkdev_put
8004636c T blkdev_close
8004638c t blkdev_ioctl
800463c8 T bdevname
80046430 t init_once
80046494 t cdfind
800464e0 T cdget
800465c0 T cdput
80046620 t cp_old_stat
80046730 t cp_new_stat
8004688c T sys_stat
80046924 T sys_newstat
800469bc T sys_lstat
80046a54 T sys_newlstat
80046aec T sys_fstat
80046b8c T sys_newfstat
80046c2c T sys_readlink
80046d00 t cp_new_stat64
80046e68 T sys_stat64
80046f00 T sys_lstat64
80046f98 T sys_fstat64
80047040 T register_binfmt
80047094 T unregister_binfmt
800470d4 T sys_uselib
80047230 t count
80047294 T copy_strings
80047484 T copy_strings_kernel
800474b0 T put_dirty_page
800475d0 T setup_arg_pages
8004772c T open_exec
8004783c T kernel_read
800478a4 t exec_mmap
80047a1c T flush_old_exec
80047d14 T prepare_binprm
80047e20 T compute_creds
80047fa0 T remove_arg_zero
8004800c T search_binary_handler
80048268 T do_execve
8004848c T set_binfmt
80048504 T do_coredump
8004868c t flush_old_files
80048740 T pipe_wait
80048818 t pipe_read
80048ae0 t pipe_write
80048e44 t pipe_lseek
80048e50 t bad_pipe_r
80048e58 t bad_pipe_w
80048e60 t pipe_ioctl
80048ea4 t pipe_poll
80048f3c t pipe_release
80049048 t pipe_read_release
80049068 t pipe_write_release
80049088 t pipe_rdwr_release
800490b0 t pipe_read_open
8004914c t pipe_write_open
800491e8 t pipe_rdwr_open
800492c0 T pipe_new
8004937c t pipefs_delete_dentry
80049384 t get_pipe_inode
8004945c T do_pipe
800497c0 t pipefs_statfs
800497e4 t pipefs_read_super
800498f0 T getname
800499d4 T vfs_permission
80049b38 T permission
80049b84 T get_write_access
80049bb4 T deny_write_access
80049bf0 T path_release
80049c50 t cached_lookup
80049cd4 t real_lookup
80049e5c T follow_up
80049f70 T follow_down
8004a030 T link_path_walk
8004a6d0 T path_walk
8004a6f0 t __emul_lookup_dentry
8004a858 T set_fs_altroot
8004a8d4 T path_init
8004aa98 T lookup_hash
8004ab8c T lookup_one_len
8004ac28 T __user_walk
8004acc0 T vfs_create
8004ae00 T open_namei
8004b4cc t lookup_create
8004b5a0 T vfs_mknod
8004b73c T sys_mknod
8004b934 T vfs_mkdir
8004ba74 T sys_mkdir
8004bbc8 t d_unhash
8004bc7c T vfs_rmdir
8004bf44 T sys_rmdir
8004c0c4 T vfs_unlink
8004c2ac T sys_unlink
8004c43c T vfs_symlink
8004c578 T sys_symlink
8004c6d8 T vfs_link
8004c84c T sys_link
8004ca00 T vfs_rename_dir
8004cfa4 T vfs_rename_other
8004d370 T vfs_rename
8004d440 T sys_rename
8004d4ec T vfs_readlink
8004d594 T vfs_follow_link
8004d730 t page_getlink
8004d7d8 T page_readlink
8004d858 T page_follow_link
8004da14 t dget
8004da88 t triple_down
8004dbc0 t follow_dotdot
8004dd78 t do_rename
8004e030 t expand_files
8004e0b4 t locate_fd
8004e20c t dupfd
8004e300 T sys_dup2
8004e460 T sys_dup
8004e49c t setfl
8004e600 t do_fcntl
8004e89c T sys_fcntl
8004e914 T sys_fcntl64
8004e9ec t send_sigio_to_task
8004eb10 T send_sigio
8004ec2c T fasync_helper
8004ed5c T __kill_fasync
8004ee14 T kill_fasync
8004ee30 t file_ioctl
8004efc8 T sys_ioctl
8004f2a0 T vfs_readdir
8004f404 T dcache_readdir
8004f5dc t fillonedir
8004f6b8 T old_readdir
8004f730 t filldir
8004f844 T sys_getdents
8004f900 t filldir64
8004fa78 T sys_getdents64
8004fb50 T poll_freewait
8004fbcc T __pollwait
8004fca8 t max_select_fd
8004fdbc T do_select
80050014 t select_bits_alloc
80050040 t select_bits_free
8005005c T sys_select
800503b0 t do_pollfd
800504a4 t do_poll
800505c4 T sys_poll
80050910 t get_fd_set
800509a0 t wait_for_partner
800509f4 t wake_up_partner
80050a18 t fifo_open
80050d70 t locks_alloc_lock
80050dc8 T locks_init_lock
80050e38 t init_once
80050e68 T locks_copy_lock
80050ef4 t flock_make_lock
80050f84 t assign_type
80050fa0 t flock_to_posix_lock
800510b0 t flock64_to_posix_lock
80051224 t lease_alloc
8005134c t locks_delete_block
8005138c t locks_insert_block
80051448 t locks_wake_up_blocks
8005152c t locks_insert_lock
8005158c t locks_delete_lock
800516d0 t locks_conflict
80051724 t posix_locks_conflict
800517f8 t flock_locks_conflict
80051860 t interruptible_sleep_on_locked
80051908 t locks_block_on
80051950 t locks_block_on_timeout
8005199c T posix_test_lock
80051a10 T posix_locks_deadlock
80051a94 T locks_mandatory_locked
80051ae4 T locks_mandatory_area
80051d18 t flock_lock_file
80051f30 T posix_lock_file
800524f8 T __get_lease
80052770 T lease_get_mtime
800527b0 T fcntl_getlease
800527e4 t lease_modify
800528a0 T fcntl_setlease
80052b5c T sys_flock
80052c30 T fcntl_getlk
80052e5c T fcntl_setlk
80053094 T fcntl_getlk64
8005326c T fcntl_setlk64
800534a4 T locks_remove_posix
800535e0 T locks_remove_flock
80053660 T posix_block_lock
8005367c T posix_unblock_lock
800536b0 t lock_get_status
80053930 t move_lock_status
800539e8 T get_locks_status
80053b34 T lock_may_read
80053c00 T lock_may_write
80053cc4 t locks_free_lock
80053d70 T dput
80053f54 T d_invalidate
80053ffc T dget_locked
80054060 T d_find_alias
800540f4 T d_prune_aliases
800541b4 T prune_dcache
800543b4 T shrink_dcache_sb
800545b0 T have_submounts
80054618 t select_parent
800546b0 T shrink_dcache_parent
800546f0 T shrink_dcache_memory
80054748 T d_alloc
80054908 T d_instantiate
8005498c T d_alloc_root
80054a0c T d_lookup
80054b8c T d_validate
80054c90 T d_delete
80054d28 T d_rehash
80054dd8 T d_move
80054f38 T __d_path
800550d4 T sys_getcwd
80055348 T is_subdir
80055368 T d_genocide
800553f4 T find_inode_number
800554d4 t init_buffer_head
80055530 t destroy_inode
8005558c t init_once
80055670 T __mark_inode_dirty
80055730 t __wait_on_inode
800557bc T sync_inodes_sb
80055930 T sync_unlocked_inodes
800559b0 t get_super_to_sync
80055a44 T sync_inodes
80055ab4 t try_to_sync_unused_inodes
80055b74 T write_inode_now
80055ce4 T generic_osync_inode
80055dcc T clear_inode
80055f18 t dispose_list
80055fbc t invalidate_list
800560c8 T invalidate_inodes
80056168 T invalidate_device
800561f4 T prune_icache
8005634c T shrink_icache_memory
800563a4 t find_inode
80056450 t clean_inode
80056500 T get_empty_inode
800565a8 t get_new_inode
8005676c T iunique
8005682c T igrab
800568d4 T icreate
80056a38 T unlock_new_inode
80056a70 T iget4
80056c48 T insert_inode_hash
80056cac T remove_inode_hash
80056cc8 T iput
80056f88 T force_delete
80056fa0 T bmap
80056fdc T update_atime
8005705c t __sync_one
80057200 T inode_change_ok
800573dc T inode_setattr
80057510 t setattr_mask
80057580 T notify_change
80057740 t bad_follow_link
800577d0 t return_EIO
800577d8 T make_bad_inode
80057810 T is_bad_inode
80057830 T alloc_fd_array
80057874 T free_fd_array
800578d0 T expand_fd_array
80057a24 T alloc_fdset
80057a74 T free_fdset
80057ae4 T expand_fdset
80057cf0 T end_kio_request
80057d70 t kiobuf_init
80057db8 T alloc_kiobuf_bhs
80057e60 T free_kiobuf_bhs
80057eac T alloc_kiovec
80057f64 T free_kiovec
80058000 T expand_kiobuf
800580bc T kiobuf_wait_for_io
80058190 t redo_inode_mask
800581c0 T fcntl_dirnotify
80058374 T __inode_dir_notify
80058490 T sys_nfsservctl
800584a0 T alloc_vfsmnt
80058520 T free_vfsmnt
8005856c T set_devname
800585e8 T lookup_mnt
80058654 t check_mnt
80058684 t detach_mnt
800586e8 t attach_mnt
80058820 t next_mnt
8005885c t clone_mnt
8005892c T __mntput
80058970 t m_start
80058a20 t m_next
80058a60 t m_stop
80058aac t show_vfsmnt
80058e90 T may_umount
80058eac T umount_tree
80058fc8 t do_umount
80059144 T sys_umount
80059244 T sys_oldumount
80059260 t mount_is_safe
80059294 t copy_tree
80059390 T graft_tree
80059528 t do_loopback
800596fc t do_remount
800597ec t do_move_mount
80059ab0 t do_add_mount
80059dac t copy_mount_options
80059e84 T do_mount
8005a040 T sys_mount
8005a140 t chroot_fs_refs
8005a38c T sys_pivot_root
8005a7a0 t rootfs_lookup
8005a7d8 t rootfs_read_super
8005a890 T seq_open
8005a914 T seq_read
8005ad28 t traverse
8005af50 T seq_lseek
8005b0f0 T seq_release
8005b124 T seq_escape
8005b244 T seq_printf
8005b2d0 t xattr_alloc
8005b32c t xattr_free
8005b368 t setxattr
8005b4c8 T sys_setxattr
8005b550 T sys_lsetxattr
8005b5d8 T sys_fsetxattr
8005b654 t getxattr
8005b790 T sys_getxattr
8005b810 T sys_lgetxattr
8005b890 T sys_fgetxattr
8005b904 t listxattr
8005b9f4 T sys_listxattr
8005ba64 T sys_llistxattr
8005bad4 T sys_flistxattr
8005bb38 t removexattr
8005bbc4 T sys_removexattr
8005bc24 T sys_lremovexattr
8005bc84 T sys_fremovexattr
8005bce0 t validate_quotactl
8005bec8 T sys_quotactl
8005c340 t load_script
8005c610 t set_brk
8005c658 t padzero
8005c6b4 t create_elf_tables
8005c998 t load_elf_interp
8005cd00 t load_aout_interp
8005ce7c t load_elf_binary
8005da6c t load_elf_library
8005dcec t dump_write
8005dd24 t dump_seek
8005dda0 t notesize
8005ddec t writenote
8005dec0 t elf_core_dump
8005e7ac t ffz
8005e810 T de_get
8005e838 T de_put
8005e8c4 t proc_delete_inode
8005e944 t proc_read_inode
8005e95c t proc_statfs
8005e988 t parse_options
8005eafc T proc_get_inode
8005ec7c T proc_read_super
8005ed70 t proc_root_lookup
8005edec t proc_root_readdir
8005ee70 t proc_fd_link
8005ef2c t proc_exe_link
8005f074 t proc_cwd_link
8005f160 t proc_root_link
8005f24c t proc_pid_environ
8005f2cc t proc_pid_cmdline
8005f3e8 t proc_check_root
8005f56c t proc_permission
8005f5ac t pid_maps_read
8005f5ec t proc_info_read
8005f764 t mem_open
8005f774 t mem_read
8005f944 t proc_pid_follow_link
8005f9f0 t do_proc_readlink
8005fb90 t proc_pid_readlink
8005fc94 t proc_readfd
8005fee4 t proc_base_readdir
800600b8 t task_dumpable
800600d4 t proc_pid_make_inode
800601f0 t pid_fd_revalidate
800601f8 t pid_base_revalidate
80060238 t pid_delete_dentry
80060240 t proc_lookupfd
80060418 t proc_base_lookup
80060658 t proc_self_readlink
800606b8 t proc_self_follow_link
800606f8 T proc_pid_lookup
8006095c T proc_pid_delete_inode
800609b8 t get_pid_list
80060a1c T proc_pid_readdir
80060bd0 T proc_match
80060c20 t proc_file_read
80060e44 t proc_file_write
80060e84 t proc_file_lseek
80060f14 t xlate_proc_name
80060fc8 t make_inode_number
80061058 t proc_readlink
8006107c t proc_follow_link
800610a4 t proc_delete_dentry
800610ac T proc_lookup
80061194 T proc_readdir
80061358 t proc_register
80061438 t proc_kill_inodes
800614d0 t proc_create
800615ac T proc_symlink
80061654 T proc_mknod
800616b8 T proc_mkdir
8006171c T create_proc_entry
800617d4 T free_proc_entry
80061838 T remove_proc_entry
80061980 t collect_sigign_sigcatch
80061a44 T proc_pid_status
80061cc4 T proc_pid_stat
80061fb0 t statm_pgd_range
800620c0 T proc_pid_statm
8006226c t proc_pid_maps_get_line
800624d8 T proc_pid_read_maps
80062744 t task_name
800627d0 t task_mem
800628dc t statm_pte_range
80062a70 t kmsg_open
80062a94 t kmsg_release
80062abc t kmsg_read
80062ad8 t kmsg_poll
80062b40 t tty_drivers_read_proc
80062db0 t tty_ldiscs_read_proc
80062eec T proc_tty_register_driver
80062f68 T proc_tty_unregister_driver
80062fb0 t proc_calc_metrics
80062ff8 t loadavg_read_proc
80063118 t uptime_read_proc
80063204 t meminfo_read_proc
800634a8 t version_read_proc
80063534 t cpuinfo_open
8006355c t modules_read_proc
800635c4 t ksyms_open
800635ec t kstat_read_proc
8006389c t devices_read_proc
80063904 t partitions_read_proc
8006393c t interrupts_read_proc
800639a4 t filesystems_read_proc
80063a0c t dma_read_proc
80063a74 t ioports_read_proc
80063aec t cmdline_read_proc
80063b6c t locks_read_proc
80063ba4 t execdomains_read_proc
80063c0c t swaps_read_proc
80063c74 t memory_read_proc
80063cec t read_profile
80063e10 t write_profile
80063e50 t mounts_open
80063e78 t create_seq_entry
80063eb0 t open_kcore
80063ee0 t get_kcore_size
80063f74 t notesize
80063fc0 t storenote
80064084 t elf_kcore_store_hdr
8006436c t read_kcore
800647d0 T disk_name
800649dc T add_gd_partition
80064a6c t check_partition
80064c84 T devfs_register_partitions
80064c8c T register_disk
80064cbc T grok_partitions
80064e4c T read_dev_sector
80064f40 t partition_name
80064f5c t extended_partition
8006521c t solaris_x86_partition
80065224 t bsd_partition
8006522c t netbsd_partition
80065234 t openbsd_partition
8006523c t unixware_partition
80065244 t minix_partition
8006524c t handle_ide_mess
80065254 T msdos_partition
800655f0 t is_extended_partition
80065630 T ext2_get_group_desc
800656d4 t read_block_bitmap
8006579c t __load_block_bitmap
80065968 T ext2_free_blocks
80065e00 T ext2_new_block
80066a28 T ext2_count_free_blocks
80066a34 T ext2_group_sparse
80066b30 T ext2_bg_has_super
80066b78 T ext2_bg_num_gdb
80066bd0 T ext2_count_free
80066c40 t ext2_commit_chunk
80066cf8 t ext2_check_page
80066f54 t ext2_get_page
8006700c t ext2_readdir
800672a0 T ext2_find_entry
8006740c T ext2_dotdot
8006745c T ext2_inode_by_name
8006749c T ext2_set_link
800675cc T ext2_add_link
80067870 T ext2_delete_entry
800679c0 T ext2_make_empty
80067b38 T ext2_empty_dir
80067c70 t ext2_release_file
80067cb0 T ext2_sync_file
80067cd0 T ext2_fsync_inode
80067d60 t read_inode_bitmap
80067df8 t load_inode_bitmap
80067fd0 T ext2_free_inode
8006822c t find_group_dir
80068344 t find_group_other
80068474 T ext2_new_inode
800688d0 T ext2_count_free_inodes
800688e0 T ext2_put_inode
800688fc T ext2_delete_inode
800689c0 T ext2_discard_prealloc
800689f8 t ext2_alloc_block
80068aa4 t ext2_block_to_path
80068bbc t ext2_get_branch
80068d08 t ext2_alloc_branch
80068f90 t ext2_get_block
800692d4 t ext2_writepage
800692f8 t ext2_readpage
80069320 t ext2_prepare_write
80069350 t ext2_bmap
80069374 t ext2_direct_IO
800693a0 t ext2_find_shared
80069538 t ext2_free_branches
80069664 T ext2_truncate
80069ab8 T ext2_read_inode
80069f34 t ext2_update_inode
8006a380 T ext2_write_inode
8006a39c T ext2_sync_inode
8006a3b8 t ext2_splice_branch
8006a5cc t ext2_free_data
8006a6b0 T ext2_ioctl
8006a950 t ext2_lookup
8006a9dc t ext2_create
8006aab4 t ext2_mknod
8006ab8c t ext2_symlink
8006ad1c t ext2_link
8006ae08 t ext2_mkdir
8006af68 t ext2_unlink
8006afec t ext2_rmdir
8006b0a0 t ext2_rename
8006b2f0 T ext2_error
8006b450 T ext2_panic
8006b4f8 T ext2_warning
8006b570 T ext2_update_dynamic_rev
8006b5d0 T ext2_put_super
8006b6f0 t parse_options
8006be44 t ext2_setup_super
8006bfc4 t ext2_check_descriptors
8006c0f0 t ext2_max_size
8006c254 T ext2_read_super
8006c9bc t ext2_commit_super
8006c9f4 t ext2_sync_super
8006ca64 T ext2_write_super
8006cad0 T ext2_remount
8006cc24 T ext2_statfs
8006cd54 t ffz
8006cdc0 t ext2_readlink
8006cde0 t ext2_follow_link
8006ce10 T zlib_fs_adler32
8006cfa0 T zlib_fs_inflate_blocks_reset
8006d038 T zlib_fs_inflate_blocks_new
8006d094 T zlib_fs_inflate_blocks
8006daa4 T zlib_fs_inflate_blocks_free
8006dac4 T zlib_fs_inflate_set_dictionary
8006db08 T zlib_fs_inflate_blocks_sync_point
8006db20 T zlib_fs_inflate_codes_new
8006db40 T zlib_fs_inflate_codes
8006e26c T zlib_fs_inflate_codes_free
8006e280 T zlib_fs_inflate_fast
8006e6b0 T zlib_fs_inflate_workspacesize
8006e6b8 T zlib_fs_inflateReset
8006e724 T zlib_fs_inflateEnd
8006e790 T zlib_fs_inflateInit2_
8006e8a0 T zlib_fs_inflateInit_
8006e8c4 T zlib_fs_inflate
8006ee04 T zlib_fs_inflateSync
8006ef30 T zlib_fs_inflateSyncPoint
8006ef80 t huft_build
8006f4dc T zlib_fs_inflate_trees_bits
8006f590 T zlib_fs_inflate_trees_dynamic
8006f750 T zlib_fs_inflate_trees_fixed
8006f790 T zlib_fs_inflate_flush
8006f940 t get_cramfs_inode
8006faac t cramfs_read
8006fdb4 t cramfs_read_super
8007016c t cramfs_statfs
800701ac t cramfs_readdir
80070390 t cramfs_lookup
8007055c t cramfs_readpage
80070760 T cramfs_uncompress_block
80070864 T cramfs_uncompress_init
80070904 T cramfs_uncompress_exit
80070960 t nfs_readdir_filler
80070b14 t nfs_do_filldir
80070ca4 t nfs_readdir
80070e18 t nfs_lookup_revalidate
80071068 t nfs_dentry_delete
800710c8 t nfs_dentry_iput
8007110c t nfs_lookup
8007121c t nfs_instantiate
8007126c t nfs_create
80071388 t nfs_mknod
800714b0 t nfs_mkdir
800715cc t nfs_rmdir
80071654 t nfs_sillyrename
80071858 t nfs_safe_remove
800719dc t nfs_unlink
80071a88 t nfs_symlink
80071c38 t nfs_link
80071d28 t nfs_rename
80071f70 T nfs_permission
800720d0 t readdir_search_pagecache
800721a8 t uncached_readdir
80072394 t find_dirent_page
800724b4 t find_dirent
800725d0 t nfs_file_flush
80072688 t nfs_file_read
80072790 t nfs_file_mmap
8007286c t nfs_fsync
800728f8 t nfs_prepare_write
80072914 t nfs_commit_write
80072930 t nfs_sync_page
8007297c t nfs_file_write
80072a84 T nfs_lock
80072d80 T nfs_reqlist_init
80072e50 T nfs_reqlist_exit
80072ee0 T nfs_reqlist_alloc
80072f5c T nfs_reqlist_free
80072f98 t nfs_flushd
800730e4 t nfs_flushd_exit
80073130 t nfs_read_inode
800731b0 t nfs_write_inode
800731e0 t nfs_delete_inode
80073260 t nfs_clear_inode
80073288 t nfs_put_super
80073308 t nfs_umount_begin
80073330 t nfs_get_root
800733a0 T nfs_read_super
80073e18 t nfs_statfs
80074068 t nfs_show_options
80074290 T nfs_zap_caches
80074330 t nfs_invalidate_inode
8007436c t nfs_fill_inode
80074518 t nfs_find_actor
800745e0 T nfs_inode_is_stale
80074694 T nfs_fhget
80074720 t __nfs_fhget
8007480c T nfs_notify_change
800749f8 T nfs_wait_on_inode
80074b94 T nfs_revalidate
80074c00 T nfs_open
80074c88 T nfs_release
80074ce8 T __nfs_revalidate_inode
80074f44 T __nfs_refresh_inode
80075400 t nfs_xdr_enc_void
80075418 t nfs_xdr_fhandle
800754b4 t nfs_xdr_sattrargs
80075580 t nfs_xdr_diropargs
80075654 t nfs_xdr_readargs
80075864 t nfs_xdr_readres
80075a20 t nfs_xdr_writeargs
80075c2c t nfs_xdr_createargs
80075d14 t nfs_xdr_renameargs
80075e88 t nfs_xdr_linkargs
80075fe4 t nfs_xdr_symlinkargs
800760dc t nfs_xdr_readdirargs
8007625c t nfs_xdr_readdirres
800763f4 T nfs_decode_dirent
80076510 t nfs_xdr_dec_void
80076518 t nfs_xdr_stat
8007656c t nfs_xdr_attrstat
800765d8 t nfs_xdr_diropres
80076700 t nfs_xdr_readlinkargs
800767fc t nfs_xdr_readlinkres
8007692c t nfs_xdr_writeres
80076954 t nfs_xdr_statfsres
80076bac T nfs_stat_to_errno
80076c48 t xdr_decode_fattr
80077028 t xdr_encode_sattr
80077200 T nfs_create_request
800773ec T nfs_release_request
80077580 T nfs_list_add_request
80077640 T nfs_wait_on_request
800777b4 T nfs_coalesce_requests
8007790c t nfs_scan_forward
80077ae0 T nfs_scan_lru
80077b50 T nfs_scan_lru_timeout
80077bdc T nfs_scan_list
80077da4 t nfs_try_to_free_pages
80077ef4 T nfs_init_nfspagecache
80077f40 T nfs_destroy_nfspagecache
80077f80 t nfs_proc_get_root
8007803c t nfs_proc_getattr
800780f4 t nfs_proc_setattr
800781b8 t nfs_proc_lookup
8007829c t nfs_proc_readlink
80078360 t nfs_proc_read
800784b4 t nfs_proc_write
80078634 t nfs_proc_create
8007871c t nfs_proc_mknod
800788f0 t nfs_proc_remove
800789c0 t nfs_proc_unlink_setup
80078a40 t nfs_proc_unlink_done
80078a9c t nfs_proc_rename
80078b94 t nfs_proc_link
80078c70 t nfs_proc_symlink
80078d6c t nfs_proc_mkdir
80078e58 t nfs_proc_rmdir
80078f28 t nfs_proc_readdir
80079000 t nfs_proc_statfs
800790d0 t nfs_readdata_release
800790f4 t nfs_readpage_sync
80079358 t nfs_readpage_async
80079468 t nfs_read_rpcsetup
800795fc t nfs_async_read_error
80079768 t nfs_pagein_one
800798d4 T nfs_pagein_list
80079984 T nfs_scan_lru_read_timeout
800799c8 T nfs_scan_lru_read
80079a0c t nfs_scan_read
80079a90 T nfs_pagein_inode
80079b0c t nfs_readpage_result
80079ddc T nfs_readpage
80079f3c T nfs_init_readpagecache
80079f88 T nfs_destroy_readpagecache
80079fd0 t nfs_symlink_filler
8007a054 t nfs_getlink
8007a0d4 t nfs_readlink
8007a158 t nfs_follow_link
8007a1c0 t nfs_put_unlinkdata
8007a248 t nfs_async_unlink_init
8007a300 t nfs_async_unlink_done
8007a3b4 t nfs_async_unlink_release
8007a3d0 T nfs_async_unlink
8007a52c T nfs_complete_unlink
8007a630 t nfs_writedata_release
8007a654 t nfs_writepage_sync
8007a98c t nfs_writepage_async
8007ab2c T nfs_writepage
8007aca8 t region_locked
8007adc0 t nfs_find_request
8007ae18 t nfs_wait_on_requests
8007af10 T nfs_scan_lru_dirty_timeout
8007af54 T nfs_scan_lru_dirty
8007af98 t nfs_scan_dirty
8007b014 T nfs_scan_lru_commit_timeout
8007b088 T nfs_scan_lru_commit
8007b0fc t nfs_scan_commit
8007b178 t nfs_update_request
8007b558 t nfs_strategy
8007b5cc T nfs_flush_incompatible
8007b684 T nfs_updatepage
8007ba24 t nfs_write_rpcsetup
8007bbbc t nfs_flush_one
8007bed0 T nfs_flush_list
8007c0ec t nfs_writeback_done
8007c614 t nfs_commit_rpcsetup
8007c784 T nfs_commit_list
8007ca24 t nfs_commit_done
8007cde4 T nfs_flush_file
8007ce70 T nfs_commit_file
8007ceec T nfs_sync_file
8007cfd8 T nfs_init_writepagecache
8007d024 T nfs_destroy_writepagecache
8007d064 t nfs_inode_remove_request
8007d140 t nfs3_rpc_wrapper
8007d1e4 t nfs3_proc_get_root
8007d2a0 t nfs3_proc_getattr
8007d358 t nfs3_proc_setattr
8007d430 t nfs3_proc_lookup
8007d59c t nfs3_proc_access
8007d738 t nfs3_proc_readlink
8007d83c t nfs3_proc_read
8007d990 t nfs3_proc_write
8007db08 t nfs3_proc_create
8007ddd0 t nfs3_proc_remove
8007dedc t nfs3_proc_unlink_setup
8007df68 t nfs3_proc_unlink_done
8007dfc0 t nfs3_proc_rename
8007e138 t nfs3_proc_link
8007e294 t nfs3_proc_symlink
8007e3d4 t nfs3_proc_mkdir
8007e4f4 t nfs3_proc_rmdir
8007e600 t nfs3_proc_readdir
8007e7b8 t nfs3_proc_mknod
8007e944 t nfs3_proc_statfs
8007ea40 t nfs3_xdr_enc_void
8007ea58 t nfs3_xdr_fhandle
8007eae0 t nfs3_xdr_sattrargs
8007ec30 t nfs3_xdr_diropargs
8007ecdc t nfs3_xdr_accessargs
8007eda4 t nfs3_xdr_readargs
8007ef70 t nfs3_xdr_writeargs
8007f158 t nfs3_xdr_createargs
8007f26c t nfs3_xdr_mkdirargs
8007f324 t nfs3_xdr_symlinkargs
8007f3ec t nfs3_xdr_mknodargs
8007f530 t nfs3_xdr_renameargs
8007f634 t nfs3_xdr_linkargs
8007f72c t nfs3_xdr_readdirargs
8007f91c t nfs3_xdr_readdirres
8007fba0 T nfs3_decode_dirent
8007fed4 t nfs3_xdr_commitargs
80080000 t nfs3_xdr_dec_void
80080008 t nfs3_xdr_attrstat
80080074 t nfs3_xdr_wccstat
800801e4 t nfs3_xdr_lookupres
8008033c t nfs3_xdr_accessres
80080414 t nfs3_xdr_readlinkargs
80080510 t nfs3_xdr_readlinkres
80080654 t nfs3_xdr_readres
8008085c t nfs3_xdr_writeres
80080a30 t nfs3_xdr_createres
80080c80 t nfs3_xdr_renameres
80080ec0 t nfs3_xdr_linkres
8008105c t nfs3_xdr_fsstatres
800813f4 t nfs3_xdr_fsinfores
80081670 t nfs3_xdr_pathconfres
80081780 t nfs3_xdr_commitres
80081900 t xdr_decode_time3
80081984 t xdr_decode_fattr
80081e94 t xdr_encode_sattr
800820f0 T nlmclnt_block
80082204 T nlmclnt_grant
800822dc t nlmclnt_mark_reclaim
80082350 T nlmclnt_recovery
80082480 t reclaimer
800825e0 T nlmclnt_setgrantargs
800826b4 T nlmclnt_freegrantargs
800826e0 T nlmclnt_proc
80082c28 T nlmclnt_alloc_call
80082cc0 T nlmclnt_call
80082f24 T nlmsvc_async_call
80082ff8 T nlmclnt_async_call
80083140 t nlmclnt_test
800831b4 t nlmclnt_insert_lock_callback
800831d0 t nlmclnt_remove_lock_callback
8008320c t nlmclnt_lock
80083320 T nlmclnt_reclaim
80083478 t nlmclnt_unlock
80083510 t nlmclnt_unlock_callback
800835e0 T nlmclnt_cancel
800838b4 t nlmclnt_cancel_callback
800839e8 t nlm_stat_to_errno
80083a80 T nlmclnt_lookup_host
80083aac T nlmsvc_lookup_host
80083ad8 T nlm_lookup_host
80083ec8 T nlm_bind_host
80084128 T nlm_rebind_host
800841ac T nlm_get_host
80084234 T nlm_release_host
8008429c T nlm_shutdown_hosts
80084480 t nlm_gc_hosts
80084670 t set_grace_period
800846f8 t lockd
80084b24 T lockd_up
80084cf4 T lockd_down
80084ee0 t nlmsvc_insert_block
80084ff4 t nlmsvc_remove_block
80085048 t nlmsvc_lookup_block
8008521c t nlmsvc_delete_block
8008539c T nlmsvc_traverse_blocks
800854bc T nlmsvc_lock
8008581c T nlmsvc_testlock
80085950 T nlmsvc_unlock
80085a00 T nlmsvc_cancel_blocked
80085b14 t nlmsvc_notify_blocked
80085c28 t nlmsvc_grant_blocked
80085e50 t nlmsvc_grant_callback
80085fc8 T nlmsvc_grant_reply
800861f8 T nlmsvc_retry_blocked
80086314 t nlmsvc_create_block
80086480 T nlmsvc_share_file
800865c0 T nlmsvc_unshare_file
8008667c T nlmsvc_traverse_shares
80086730 t cast_to_nlm
80086798 t nlmsvc_retrieve_args
800868f4 t nlmsvc_proc_null
80086934 t nlmsvc_proc_test
80086a6c t nlmsvc_proc_lock
80086bb4 t nlmsvc_proc_cancel
80086ce8 t nlmsvc_proc_unlock
80086e1c t nlmsvc_proc_granted
80086ee8 t nlmsvc_proc_test_msg
80086f6c t nlmsvc_proc_lock_msg
80086ff0 t nlmsvc_proc_cancel_msg
80087074 t nlmsvc_proc_unlock_msg
800870f8 t nlmsvc_proc_granted_msg
8008717c t nlmsvc_proc_share
800872bc t nlmsvc_proc_unshare
800873f4 t nlmsvc_proc_nm_lock
80087468 t nlmsvc_proc_free_all
800874ac t nlmsvc_proc_sm_notify
80087640 t nlmsvc_callback
80087734 t nlmsvc_callback_exit
800877a0 T nlm_lookup_file
80087b28 t nlm_traverse_locks
80087c8c t nlm_traverse_files
80087e9c T nlm_release_file
80088050 T nlmsvc_mark_resources
80088098 T nlmsvc_free_host_resources
8008810c T nlmsvc_invalidate_client
80088190 t nsm_mon_unmon
8008826c T nsm_monitor
80088308 T nsm_unmonitor
800883a4 t nsm_create
80088448 t xdr_error
80088450 t xdr_encode_mon
800886d4 t xdr_decode_stat_res
8008877c t xdr_decode_stat
800887b0 t nlm_encode_lock
80088abc t nlm_encode_testres
80088d54 T nlmsvc_decode_testargs
80088e98 T nlmsvc_encode_testres
80088ef4 T nlmsvc_decode_lockargs
800890d8 T nlmsvc_decode_cancargs
80089248 T nlmsvc_decode_unlockargs
80089354 T nlmsvc_decode_shareargs
800895e4 T nlmsvc_encode_shareres
800896ac T nlmsvc_encode_res
80089770 T nlmsvc_decode_notify
8008980c T nlmsvc_decode_reboot
800898b0 T nlmsvc_decode_res
800899d0 T nlmsvc_decode_void
800899f0 T nlmsvc_encode_void
80089a14 t nlmclt_encode_void
80089a2c t nlmclt_decode_void
80089a34 t nlmclt_encode_testargs
80089b14 t nlmclt_decode_testres
80089d70 t nlmclt_encode_lockargs
80089ec4 t nlmclt_encode_cancargs
80089fb8 t nlmclt_encode_unlockargs
8008a07c t nlmclt_encode_res
8008a134 t nlmclt_encode_testres
8008a188 t nlmclt_decode_res
8008a27c T nlm_procname
8008a2ac t nlm_decode_lock
8008a4f0 t nlm4_decode_cookie
8008a5a4 t nlm4_encode_cookie
8008a624 t nlm4_decode_fh
8008a6e8 t nlm4_encode_fh
8008a774 t nlm4_decode_oh
8008a790 t nlm4_encode_oh
8008a7ac t nlm4_decode_lock
8008a9c8 t nlm4_encode_lock
8008abd8 t nlm4_encode_testres
8008aedc t xdr_argsize_check
8008aefc t xdr_ressize_check
8008af20 T nlm4svc_decode_testargs
8008afcc T nlm4svc_encode_testres
8008b018 T nlm4svc_decode_lockargs
8008b178 T nlm4svc_decode_cancargs
8008b258 T nlm4svc_decode_unlockargs
8008b2c4 T nlm4svc_decode_shareargs
8008b3f8 T nlm4svc_encode_shareres
8008b458 T nlm4svc_encode_res
8008b4b0 T nlm4svc_decode_notify
8008b53c T nlm4svc_decode_reboot
8008b5d0 T nlm4svc_decode_res
8008b650 T nlm4svc_decode_void
8008b66c T nlm4svc_encode_void
8008b688 t nlm4clt_encode_void
8008b6a0 t nlm4clt_decode_void
8008b6a8 t nlm4clt_encode_testargs
8008b73c t nlm4clt_decode_testres
8008b9f0 t nlm4clt_encode_lockargs
8008bae8 t nlm4clt_encode_cancargs
8008bb94 t nlm4clt_encode_unlockargs
8008bc08 t nlm4clt_encode_res
8008bc70 t nlm4clt_encode_testres
8008bcc4 t nlm4clt_decode_res
8008bd30 t nlm4svc_retrieve_args
8008bea4 t nlm4svc_proc_null
8008bee4 t nlm4svc_proc_test
8008c010 t nlm4svc_proc_lock
8008c14c t nlm4svc_proc_cancel
8008c274 t nlm4svc_proc_unlock
8008c39c t nlm4svc_proc_granted
8008c468 t nlm4svc_proc_test_msg
8008c4ec t nlm4svc_proc_lock_msg
8008c570 t nlm4svc_proc_cancel_msg
8008c5f4 t nlm4svc_proc_unlock_msg
8008c678 t nlm4svc_proc_granted_msg
8008c6fc t nlm4svc_proc_share
8008c830 t nlm4svc_proc_unshare
8008c95c t nlm4svc_proc_nm_lock
8008c9d0 t nlm4svc_proc_free_all
8008ca14 t nlm4svc_proc_sm_notify
8008cba8 t nlm4svc_callback
8008ccac t nlm4svc_callback_exit
8008cd20 t romfs_checksum
8008cd7c t romfs_read_super
8008cf60 t romfs_statfs
8008cf9c t romfs_strnlen
8008d110 t romfs_copyfrom
8008d260 t romfs_readdir
8008d490 t romfs_lookup
8008d6e8 t romfs_readpage
8008d83c t romfs_read_inode
8008dac0 T ipc_findkey
8008db04 t grow_ary
8008dbcc T ipc_addid
8008dca4 T ipc_rmid
8008dd9c T ipc_alloc
8008ddd8 T ipc_free
8008de0c T ipcperms
8008dee8 T kernel_to_ipc64_perm
8008df24 T ipc64_perm_to_ipc_perm
8008df60 T ipc_parse_version
8008df90 t newque
8008e084 t free_msg
8008e0cc t load_msg
8008e224 t store_msg
8008e300 t ss_wakeup
8008e35c t expunge_all
8008e3b4 t freeque
8008e488 T sys_msgget
8008e620 T sys_msgctl
8008eb74 t testmsg
8008ebf0 T pipelined_send
8008ecd0 T sys_msgsnd
8008ef94 T sys_msgrcv
8008f394 t sysvipc_msg_read_proc
8008f5d4 T convert_mode
8008f610 t copy_msqid_to_user
8008f75c t copy_msqid_from_user
8008f840 t newary
8008f96c T sys_semget
8008fb48 t sem_revalidate
8008fbfc t try_atomic_semop
8008fda4 t update_queue
8008fe78 t count_semncnt
8008fee0 t count_semzcnt
8008ff48 t freeary
8008fff8 t copy_semid_to_user
800900bc T semctl_nolock
80090344 T semctl_main
8009079c T semctl_down
80090908 T sys_semctl
80090a50 t freeundos
80090ab8 t alloc_undo
80090bb0 T sys_semop
80091028 T sem_exit
80091260 t sysvipc_sem_read_proc
80091484 t copy_semid_from_user
80091540 t shm_open
800915f8 t shm_destroy
80091664 t shm_close
800917b4 t shm_mmap
80091898 t newseg
80091a48 T sys_shmget
80091c08 t shm_get_stat
80091cc4 T sys_shmctl
800923c4 T sys_shmat
80092714 T sys_shmdt
800927c8 t sysvipc_shm_read_proc
80092a08 t copy_shmid_to_user
80092aec t copy_shmid_from_user
80092ba4 t copy_shminfo_to_user
80092c70 t isBranchInstr
80092d04 t cop1Emulate
80093554 T do_dsemulret
80093628 t mips_dsemul
80093710 t fpemu_dp_recip
80093760 t fpemu_dp_rsqrt
800937bc t fpemu_sp_recip
800937fc t fpemu_sp_rsqrt
80093844 t fpemu_sp_madd
80093934 t fpemu_sp_msub
80093a24 t fpemu_sp_nmadd
80093b30 t fpemu_sp_nmsub
80093c3c t fpemu_dp_madd
80093d4c t fpemu_dp_msub
80093e5c t fpemu_dp_nmadd
80093f98 t fpemu_dp_nmsub
800940d4 t fpux_emu
80094668 t fpu_emu
80095070 T fpu_emulator_cop1Handler
80095230 T ieee754dp_floor
800952e8 T ieee754dp_ceil
800953a0 T ieee754dp_trunc
800953f0 T ieee754dp_dump
800956e0 T ieee754sp_dump
80095900 T ieee754dp_class
80095970 T ieee754dp_isnan
80095998 T ieee754dp_issnan
800959b8 T ieee754dp_xcpt
80095a44 T ieee754dp_nanxcpt
80095b8c T ieee754dp_bestnan
80095bec t get_rounding
80095cc0 T ieee754dp_format
80096330 T ieee754sp_class
80096388 T ieee754sp_isnan
800963ac T ieee754sp_issnan
800963c4 T ieee754sp_xcpt
80096438 T ieee754sp_nanxcpt
8009655c T ieee754sp_bestnan
80096588 t get_rounding
8009660c T ieee754sp_format
80096b60 T ieee754si_xcpt
80096bd0 T ieee754di_xcpt
80096c60 T ieee754_xcpt
80096ca0 T ieee754dp_frexp
80096e60 T ieee754dp_modf
80097200 T ieee754dp_div
800978e0 T ieee754dp_mul
80098000 T ieee754dp_sub
80098840 T ieee754dp_add
80098ff0 T ieee754dp_fsp
80099310 T ieee754dp_cmp
80099740 T ieee754dp_logb
800998f0 T ieee754dp_scalb
80099af0 T ieee754dp_ldexp
80099b30 T ieee754dp_finite
80099b4c T ieee754dp_copysign
80099b9c T ieee754dp_neg
80099db4 T ieee754dp_abs
80099fc0 T ieee754dp_tint
8009a42c T ieee754dp_tuns
8009a4d0 T ieee754dp_fint
8009a67c T ieee754dp_funs
8009a700 T ieee754dp_tlong
8009ab9c T ieee754dp_tulong
8009ac50 T ieee754dp_flong
8009aee8 T ieee754dp_fulong
8009af70 T ieee754sp_frexp
8009b0b0 T ieee754sp_modf
8009b2b0 T ieee754sp_div
8009b7f0 T ieee754sp_mul
8009bce0 T ieee754sp_sub
8009c270 T ieee754sp_add
8009c790 T ieee754sp_fdp
8009cbd0 T ieee754sp_cmp
8009cf50 T ieee754sp_logb
8009d0a0 T ieee754sp_scalb
8009d224 T ieee754sp_ldexp
8009d260 T ieee754sp_finite
8009d274 T ieee754sp_copysign
8009d2b4 T ieee754sp_neg
8009d478 T ieee754sp_abs
8009d630 T ieee754sp_tint
8009d950 T ieee754sp_tuns
8009d9c0 T ieee754sp_fint
8009db4c T ieee754sp_funs
8009dbc0 T ieee754sp_tlong
8009e080 T ieee754sp_tulong
8009e100 T ieee754sp_flong
8009e394 T ieee754sp_fulong
8009e410 T ieee754dp_sqrt
8009eb30 T ieee754sp_sqrt
8009ee10 T fpu_emulator_init_fpu
8009ee74 T fpu_emulator_save_context
8009eee8 T fpu_emulator_restore_context
8009ef60 t do_write_mem
8009efe0 t read_mem
8009f094 t write_mem
8009f104 t mmap_mem
8009f1cc t read_kmem
8009f360 t write_kmem
8009f4d8 t read_null
8009f4e0 t write_null
8009f4e8 t read_zero
8009f624 t mmap_zero
8009f684 t write_full
8009f68c t null_lseek
8009f6a0 t memory_lseek
8009f710 t open_port
8009f740 t memory_open
8009f818 t read_zero_pagealigned
8009f990 t alloc_tty_struct
8009f9d8 t _tty_make_name
8009fa54 T tty_name
8009fa80 t check_tty_count
8009fb48 T tty_register_ldisc
8009fbf8 t tty_set_ldisc
8009fe94 T get_tty_driver
8009fef8 T tty_check_change
8009ff80 t hung_up_tty_read
8009ff9c t hung_up_tty_write
8009ffb8 t hung_up_tty_poll
8009ffc0 t hung_up_tty_ioctl
8009ffdc T do_tty_hangup
800a037c T tty_hangup
800a0398 T tty_vhangup
800a03b4 T tty_hung_up_p
800a03cc T disassociate_ctty
800a04d0 T wait_for_keypress
800a0500 T stop_tty
800a058c T start_tty
800a0664 t tty_read
800a0790 t tty_write
800a08e0 t down_tty_sem
800a092c t up_tty_sem
800a0978 t init_dev
800a0edc t release_mem
800a0fe0 t release_dev
800a15b0 t tty_open
800a18a8 t tty_release
800a18c8 t tty_poll
800a1994 t tty_fasync
800a1ae8 t tiocsti
800a1b9c t tiocgwinsz
800a1bf4 t tiocswinsz
800a1cd0 t tioccons
800a1d5c t fionbio
800a1db0 t tiocsctty
800a1e8c t tiocgpgrp
800a1ed8 t tiocspgrp
800a1fa4 t tiocgsid
800a1ffc t tiocttygstruct
800a2050 t tiocsetd
800a20a0 t send_break
800a2120 T tty_ioctl
800a2648 t __do_SAK
800a2784 T do_SAK
800a27b8 t flush_to_ldisc
800a292c T tty_get_baud_rate
800a29ec T tty_flip_buffer_push
800a2aa8 t initialize_tty_struct
800a2bd8 T tty_default_put_char
800a2c04 T tty_register_devfs
800a2c0c T tty_unregister_devfs
800a2c14 T tty_register_driver
800a2d20 T tty_unregister_driver
800a2e84 T tty_paranoia_check
800a2f0c t do_tty_write
800a30f0 t check_unthrottle
800a314c t reset_buffer_flags
800a31ec T n_tty_flush_buffer
800a324c T n_tty_chars_in_buffer
800a32d8 t opost
800a34d0 t opost_block
800a36fc t echo_char
800a3798 t eraser
800a3cbc t n_tty_receive_room
800a3cfc t n_tty_receive_buf
800a41cc T is_ignored
800a4220 t n_tty_set_termios
800a46b0 t n_tty_close
800a46f4 t n_tty_open
800a47a4 t read_chan
800a4e70 t write_chan
800a50a8 t normal_poll
800a523c t put_tty_queue
800a52c8 t n_tty_receive_char
800a5b58 t copy_from_read_buf
800a5ce0 T tty_wait_until_sent
800a5dc4 t unset_locked_termios
800a5eec t change_termios
800a6158 t set_termios
800a63ac t get_termio
800a6480 t inq_canon
800a64fc t get_sgflags
800a6554 t get_sgttyb
800a65d4 t set_sgflags
800a666c t set_sgttyb
800a675c t get_ltchars
800a67e0 t set_ltchars
800a687c T send_prio_char
800a691c T n_tty_ioctl
800a6eb0 T raw_open
800a70c4 T raw_release
800a7188 T raw_ctl_ioctl
800a7454 T raw_read
800a748c T raw_write
800a74c4 t rw_raw_dev
800a7880 t pty_close
800a79b0 t pty_unthrottle
800a7a30 t pty_write
800a7c24 t pty_write_room
800a7c6c t pty_chars_in_buffer
800a7ce0 t pty_set_lock
800a7d5c t pty_bsd_ioctl
800a7dac t pty_flush_buffer
800a7e28 t pty_open
800a7f40 t pty_set_termios
800a7f70 t misc_read_proc
800a8090 t misc_open
800a83c4 T misc_register
800a85c4 T misc_deregister
800a86e0 t create_entropy_store
800a8810 t clear_entropy_store
800a884c t free_entropy_store
800a8890 t add_entropy_words
800a89dc t credit_entropy_store
800a8a18 T batch_entropy_store
800a8b44 t batch_entropy_process
800a8c84 t add_timer_randomness
800a8d70 T add_keyboard_randomness
800a8db0 T add_mouse_randomness
800a8dd8 T add_interrupt_randomness
800a8e20 T add_blkdev_randomness
800a8e8c t SHATransform
800a903c t extract_entropy
800a93c8 T get_random_bytes
800a9438 t init_std_data
800a94e4 T rand_initialize_irq
800a955c T rand_initialize_blkdev
800a95d0 t random_read
800a9734 t urandom_read
800a9758 t random_poll
800a9820 t random_write
800a992c t random_ioctl
800a9cc4 T generate_random_uuid
800a9d10 t change_poolsize
800a9d94 t proc_do_poolsize
800a9e1c t poolsize_strategy
800a9ed0 t proc_do_uuid
800a9ffc t uuid_strategy
800aa104 t sysctl_init_random
800aa140 t halfMD4Transform
800aa53c T secure_tcp_sequence_number
800aa658 T secure_ip_id
800aa6d0 t serial_in
800aa6ec t serial_out
800aa704 t rs_stop
800aa778 t rs_start
800aa82c t rs_sched_event
800aa910 t receive_chars
800aab18 t transmit_chars
800aac40 t rs_interrupt_single
800aad50 t do_serial_bh
800aad88 t do_softint
800aae0c t rs_timer
800aafb0 t figure_IRQ_timeout
800ab024 t startup
800ab364 t shutdown
800ab55c t change_speed
800ab820 t rs_put_char
800ab90c t rs_flush_chars
800ab98c t rs_write
800abcc0 t rs_write_room
800abcdc t rs_chars_in_buffer
800abcf4 t rs_flush_buffer
800abda4 t rs_send_xchar
800abde8 t rs_throttle
800abe94 t rs_unthrottle
800abf24 t get_serial_info
800ac014 t set_serial_info
800ac4f8 t get_modem_info
800ac54c t set_modem_info
800ac554 t do_autoconfig
800ac5e4 t rs_break
800ac5ec t rs_ioctl
800ac89c t rs_set_termios
800ac8ec t rs_close
800acbf8 t rs_wait_until_sent
800acd08 t rs_hangup
800acd8c t block_til_ready
800ad128 t get_async_struct
800ad288 t rs_open
800ad550 T rs_read_proc
800ad690 t show_serial_version
800ad6e0 t detect_uart_irq
800ad710 t autoconfig
800ad7b8 T register_serial
800ad7c0 T unregister_serial
800ad7c8 t serial_console_device
800ad7dc t brcm_serial_console_write
800ad960 t brcm_serial_console_wait_key
800ada00 t line_info
800adc10 t __blk_cleanup_queue
800adca0 T blk_cleanup_queue
800add14 T blk_queue_headactive
800add1c T blk_queue_make_request
800add24 t ll_back_merge_fn
800add70 t ll_front_merge_fn
800addbc t ll_merge_requests_fn
800ade0c t generic_plug_device
800aded0 T generic_unplug_device
800adf5c t blk_init_free_list
800ae068 T blk_init_queue
800ae160 t __get_request_wait
800ae2b4 T is_read_only
800ae300 T set_device_ro
800ae370 t attempt_merge
800ae4dc t __make_request
800aecdc T generic_make_request
800aeecc T submit_bh
800aefb0 T ll_rw_block
800af294 T end_that_request_first
800af398 T end_that_request_last
800af45c T blk_get_queue
800af4ac T drive_stat_acct
800af5b4 T blkdev_release_request
800af650 t disk_index
800af6c0 T add_partition
800af874 T del_partition
800af9b0 T blkpg_ioctl
800afab0 T blk_ioctl
800affc0 T add_gendisk
800b000c T del_gendisk
800b0068 T get_gendisk
800b00c0 T get_partition_list
800b0230 T elevator_linus_merge
800b0378 T elevator_linus_merge_cleanup
800b03a8 T elevator_linus_merge_req
800b03c4 T elevator_noop_merge
800b0478 T elevator_noop_merge_cleanup
800b0480 T elevator_noop_merge_req
800b0488 T blkelvget_ioctl
800b04f4 T blkelvset_ioctl
800b0564 T elevator_init
800b05b0 T bh_rq_in_between
800b0630 t ramdisk_updatepage
800b06fc t ramdisk_readpage
800b0734 t ramdisk_prepare_write
800b0778 t ramdisk_commit_write
800b0780 t rd_blkdev_pagecache_IO
800b090c t rd_make_request
800b09c4 t rd_ioctl
800b0bd0 t initrd_read
800b0c70 t initrd_release
800b0cdc t rd_open
800b0da4 t huft_build
800b1320 t huft_free
800b1358 t inflate_codes
800b1954 t inflate_stored
800b1bcc t inflate_fixed
800b1d70 t inflate_dynamic
800b2598 t inflate_block
800b2744 t inflate
800b2830 t makecrc
800b28dc t gunzip
800b3140 t transfer_none
800b318c t transfer_xor
800b31f8 t none_status
800b320c t xor_status
800b3224 t compute_loop_size
800b32b4 t figure_loop_size
800b32f8 t lo_send
800b35d0 t lo_read_actor
800b36f0 t lo_receive
800b377c t do_bh_filebacked
800b3858 t loop_put_buffer
800b38b0 t loop_add_bh
800b3954 t loop_get_bh
800b39b4 t loop_end_io_transfer
800b3a84 t loop_get_buffer
800b3c0c t loop_make_request
800b3f58 t loop_thread
800b4288 t loop_set_fd
800b44dc t loop_release_xfer
800b4570 t loop_init_xfer
800b4610 t loop_clr_fd
800b47c8 t loop_set_status
800b498c t loop_get_status
800b4af4 t lo_ioctl
800b4dc8 t lo_open
800b4f04 t lo_release
800b5024 T loop_register_transfer
800b5060 T loop_unregister_transfer
800b5144 T loop_exit
800b51b0 t alloc_netdev
800b5274 t init_alloc_dev
800b52fc t init_netdev
800b5418 T init_etherdev
800b5444 T alloc_etherdev
800b5470 t eth_mac_addr
800b54b4 t eth_change_mtu
800b54d4 T ether_setup
800b5588 T register_netdev
800b5630 T unregister_netdev
800b5670 t loopback_xmit
800b57d4 t get_stats
800b57e0 t ppp_open
800b580c t ppp_release
800b5888 t ppp_read
800b58b8 t ppp_file_read
800b5ac4 t ppp_write
800b5ae0 t ppp_file_write
800b5cf0 t ppp_poll
800b5d8c t ppp_ioctl
800b6580 t ppp_unattached_ioctl
800b67e8 t ppp_start_xmit
800b6af0 t ppp_net_stats
800b6afc t ppp_net_ioctl
800b6c6c t ppp_net_init
800b6cc4 t ppp_xmit_process
800b6eac t ppp_send_frame
800b7448 t ppp_push
800b7598 t ppp_mp_explode
800b7ac0 t ppp_channel_push
800b7d98 T ppp_input
800b807c T ppp_input_error
800b81bc t ppp_receive_frame
800b827c t ppp_receive_error
800b82bc t ppp_receive_nonmp_frame
800b88f4 t ppp_decompress_frame
800b8b5c t ppp_receive_mp_frame
800b8e5c t ppp_mp_insert
800b8eb0 t ppp_mp_reconstruct
800b9238 T ppp_register_channel
800b9330 T ppp_channel_index
800b933c T ppp_unit_number
800b93c4 T ppp_unregister_channel
800b94d4 T ppp_output_wakeup
800b94fc t ppp_set_compress
800b97d0 t ppp_ccp_peek
800b99e4 t ppp_ccp_closed
800b9a7c t find_comp_entry
800b9ac0 T ppp_register_compressor
800b9b3c T ppp_unregister_compressor
800b9b94 t find_compressor
800b9bc0 t ppp_get_stats
800b9c84 t ppp_create_interface
800b9ef0 t init_ppp_file
800b9f34 t ppp_destroy_interface
800ba328 t ppp_find_unit
800ba36c t ppp_find_channel
800ba3b0 t ppp_connect_channel
800ba61c t ppp_disconnect_channel
800ba78c t ppp_destroy_channel
800ba950 T slhc_init
800baaf4 T slhc_free
800bab58 t encode
800bab94 t pull16
800babc0 t decode
800babfc T slhc_compress
800bb394 T slhc_uncompress
800bbaa8 T slhc_remember
800bbd24 T slhc_toss
800bbd40 T slhc_i_status
800bbd7c T slhc_o_status
800bbde0 t ppp_asynctty_open
800bbeac t ppp_asynctty_close
800bbf68 t ppp_asynctty_read
800bbf70 t ppp_asynctty_write
800bbf78 t ppp_asynctty_ioctl
800bc104 t ppp_asynctty_poll
800bc10c t ppp_asynctty_room
800bc114 t ppp_asynctty_receive
800bc1d0 t ppp_asynctty_wakeup
800bc230 t ppp_async_ioctl
800bc584 t ppp_async_encode
800bc90c t ppp_async_send
800bc97c t ppp_async_push
800bcc0c t ppp_async_flush_output
800bcd00 t ppp_async_input
800bd0d4 t async_lcp_peek
800bd260 t process_input_packet
800bd500 t ppp_print_hex
800bd560 t ppp_print_char
800bd5b8 t ppp_print_buffer
800bd6a4 t ppp_sync_open
800bd768 t ppp_sync_close
800bd824 t ppp_sync_read
800bd82c t ppp_sync_write
800bd834 t ppp_synctty_ioctl
800bd9c0 t ppp_sync_poll
800bd9c8 t ppp_sync_room
800bd9d0 t ppp_sync_receive
800bda8c t ppp_sync_wakeup
800bdaec t ppp_sync_ioctl
800bde40 t ppp_sync_txmunge
800be134 t ppp_sync_send
800be1d4 t ppp_sync_push
800be438 t ppp_sync_flush_output
800be528 t ppp_sync_input
800be7f8 t skb_push
800be860 T deflateInit_
800be89c T deflateInit2_
800beb54 T deflateSetDictionary
800becc4 T deflateReset
800bed70 T deflateParams
800bee9c t putShortMSB
800beecc t flush_pending
800bef80 T deflate
800bf300 T deflateEnd
800bf404 T deflateCopy
800bf654 T deflateOutputPending
800bf670 t read_buf
800bf71c t lm_init
800bf7d0 t longest_match
800bf9d0 t fill_window
800bfb88 t deflate_stored
800bfd50 t deflate_fast
800c008c t deflate_slow
800c04bc t tr_static_init
800c07a0 T _tr_init
800c081c t init_block
800c0880 t pqdownheap
800c0994 t gen_bitlen
800c0c08 t gen_codes
800c0cb8 t build_tree
800c0f78 t scan_tree
800c1080 t send_tree
800c1600 t build_bl_tree
800c1698 t send_all_trees
800c1980 T _tr_stored_block
800c1a60 T _tr_stored_type_only
800c1af4 T _tr_align
800c1dc0 T _tr_flush_block
800c2070 T _tr_tally
800c2210 t compress_block
800c2694 t set_data_type
800c271c t bi_reverse
800c2740 t bi_flush
800c27d8 t bi_windup
800c2850 t copy_block
800c2914 T inflateReset
800c2970 T inflateEnd
800c29e8 T inflateInit2_
800c2b10 T inflateInit_
800c2b34 T inflate
800c30c8 T inflateSetDictionary
800c3194 T inflateIncomp
800c31d4 T inflateSync
800c3310 T inflate_blocks_reset
800c33e8 T inflate_blocks_new
800c34a0 T inflate_blocks
800c415c T inflate_blocks_free
800c41b0 T inflate_set_dictionary
800c41f4 T inflate_addhistory
800c4344 T inflate_packet_flush
800c4368 t huft_build
800c491c T inflate_trees_bits
800c49c4 T inflate_trees_dynamic
800c4b8c t falloc
800c4bac T inflate_trees_fixed
800c4db4 T inflate_trees_free
800c4e28 T inflate_codes_new
800c4e9c T inflate_codes
800c55ac T inflate_codes_free
800c55d4 T inflate_flush
800c5784 T inflate_fast
800c5b40 T zlibVersion
800c5b4c T adler32
800c5cd4 t zfree
800c5d40 t zalloc
800c5d8c t zalloc_init
800c5e04 t z_comp_free
800c5e3c t z_comp_alloc
800c5f78 t z_comp_init
800c601c t z_comp_reset
800c6040 t z_compress
800c6208 t z_comp_stats
800c6250 t z_decomp_free
800c6288 t z_decomp_alloc
800c63a4 t z_decomp_init
800c6450 t z_decomp_reset
800c6474 t z_decompress
800c66e0 t z_incomp
800c67f0 t bsd_clear
800c6824 t bsd_check
800c68f0 t bsd_comp_stats
800c6934 t bsd_reset
800c6960 t bsd_free
800c69c4 t bsd_alloc
800c6b4c t bsd_comp_alloc
800c6b68 t bsd_decomp_alloc
800c6b84 t bsd_init
800c6c8c t bsd_comp_init
800c6cb0 t bsd_decomp_init
800c6cd8 t bsd_compress
800c70e4 t bsd_incomp
800c7108 t bsd_decompress
800c7530 T autoirq_setup
800c7554 T autoirq_report
800c75a0 T add_mtd_device
800c7730 T del_mtd_device
800c785c T register_mtd_user
800c7988 T unregister_mtd_user
800c7a78 T get_mtd_device
800c7bc8 T put_mtd_device
800c7cbc T default_mtd_writev
800c7dd0 T default_mtd_readv
800c7ee4 t mtd_read_proc
800c80a0 t part_read
800c81bc t part_point
800c8288 t part_unpoint
800c82cc t part_read_ecc
800c83b4 t part_read_oob
800c8480 t part_read_user_prot_reg
800c84bc t part_read_fact_prot_reg
800c84f8 t part_write
800c862c t part_write_ecc
800c8728 t part_write_oob
800c880c t part_write_user_prot_reg
800c8848 t part_writev
800c8918 t part_readv
800c89d0 t part_writev_ecc
800c8a58 t part_readv_ecc
800c8acc t part_erase
800c8b2c t part_lock
800c8bcc t part_unlock
800c8c6c t part_sync
800c8c90 t part_suspend
800c8cb4 t part_resume
800c8cd8 T del_mtd_partitions
800c8d7c T add_mtd_partitions
800c9338 T get_partition_parser
800c93e4 T register_mtd_parser
800c9408 T deregister_mtd_parser
800c9420 T parse_mtd_partitions
800c9570 t mtd_lseek
800c9648 t mtd_open
800c971c t mtd_close
800c9774 t mtd_read
800c994c t mtd_write
800c9b64 t mtd_erase_callback
800c9b88 t mtd_ioctl
800ca280 t erase_callback
800ca2a4 t erase_write
800ca3f4 t write_cached_data
800ca450 t do_cached_write
800ca624 t do_cached_read
800ca77c t mtdblock_readsect
800ca7b4 t mtdblock_writesect
800ca848 t mtdblock_open
800ca93c t mtdblock_release
800caa30 t mtdblock_flush
800caaf8 t mtdblock_add_mtd
800cab98 t mtdblock_remove_dev
800cabd0 t do_blktrans_request
800cad04 t mtd_blktrans_thread
800cb030 t mtd_blktrans_request
800cb05c T blktrans_open
800cb2a0 T blktrans_release
800cb4a8 t mtd_blktrans_rrpart
800cb644 t blktrans_ioctl
800cb98c T add_mtd_blktrans_dev
800cbc6c T del_mtd_blktrans_dev
800cbdb4 T blktrans_notify_remove
800cbe60 T blktrans_notify_add
800cbec8 T register_mtd_blktrans
800cc208 T deregister_mtd_blktrans
800cc3a0 T register_mtd_chip_driver
800cc3c4 T unregister_mtd_chip_driver
800cc3d8 t get_mtd_chip_driver
800cc474 T do_map_probe
800cc54c T map_destroy
800cc5d0 t cfi_probe_chip
800ccc48 t cfi_chip_setup
800cd0e8 T cfi_probe
800cd10c t cfi_build_cmd
800cd190 t cfi_read
800cd1f4 t cfi_write
800cd2c0 T cfi_read_pri
800cd4bc T cfi_fixup
800cd558 t cfi_build_cmd
800cd5dc t cfi_write
800cd6b0 T cfi_cmdset_0020
800cd798 t cfi_staa_setup
800cdb1c t cfi_staa_read
800cdc70 t cfi_staa_write_buffers
800cdde8 t cfi_staa_writev
800ce094 t cfi_staa_erase_varsize
800ce30c t cfi_staa_sync
800ce520 t cfi_staa_lock
800ce69c t cfi_staa_unlock
800ce714 t cfi_staa_suspend
800ce8c4 t cfi_staa_resume
800cea7c t cfi_staa_destroy
800ceab0 t cfi_build_cmd
800ceb34 t do_read_onechip
800cf630 t do_write_buffer
800d0710 t do_erase_oneblock
800d14e4 t do_lock_oneblock
800d1d10 t do_unlock_oneblock
800d253c t cfi_udelay
800d25f0 t fixup_amd_bootblock
800d2668 T cfi_cmdset_0002
800d28e4 t cfi_amdstd_setup
800d2d28 t get_chip
800d3388 t put_chip
800d34fc t cfi_amdstd_read
800d3758 t cfi_amdstd_secsi_read
800d3878 t do_write_oneword
800d409c t cfi_amdstd_write_words
800d48b4 t cfi_amdstd_write_buffers
800d4aa8 t cfi_amdstd_varsize_frob
800d4dc4 t cfi_amdstd_erase_varsize
800d4e38 t cfi_amdstd_erase_chip
800d4ec0 t cfi_amdstd_sync
800d50d4 t cfi_amdstd_suspend
800d5284 t cfi_amdstd_resume
800d5458 t do_xxlock_oneblock
800d5660 t cfi_amdstd_lock_varsize
800d56a8 t cfi_amdstd_unlock_varsize
800d56f0 t cfi_amdstd_destroy
800d5740 t cfi_build_cmd
800d57c4 t cfi_write
800d5890 t cfi_udelay
800d5940 t cfi_spin_unlock
800d598c t do_read_secsi_onechip
800d5d0c t do_write_buffer
800d6934 t do_erase_chip
800d7118 t do_erase_oneblock
800d79a0 t fixup_st_m28w320ct
800d79b8 t fixup_st_m28w320cb
800d79e0 T cfi_cmdset_0001
800d7b54 t cfi_intelext_setup
800d7f20 t get_chip
800d861c t put_chip
800d886c t do_point_onechip
800d89e8 t cfi_intelext_point
800d8b74 t cfi_intelext_unpoint
800d8cbc t cfi_intelext_read
800d8f6c t cfi_intelext_read_prot_reg
800d9218 t cfi_intelext_read_user_prot_reg
800d929c t cfi_intelext_read_fact_prot_reg
800d9318 t do_write_oneword_tight
800d9b74 t do_write_oneword_orig
800d9f7c t cfi_intelext_write_words
800da33c t cfi_intelext_write_buffers
800da530 t cfi_intelext_varsize_frob
800da84c t do_erase_oneblock
800db450 t cfi_intelext_erase_varsize
800db4c4 t cfi_intelext_sync
800db5b8 t do_xxlock_oneblock
800dbb60 t cfi_intelext_lock
800dbb90 t cfi_intelext_unlock
800dbbc0 t cfi_intelext_suspend
800dbcc4 t cfi_intelext_resume
800dbe34 t cfi_intelext_destroy
800dbe84 t cfi_build_cmd
800dbf08 t cfi_udelay
800dbfb8 t do_write_buffer
800dcf30 T mtd_do_chip_probe
800dcfc0 t genprobe_ident_chips
800dd2bc t genprobe_new_chip
800dd454 t check_cmd_set
800dd5c0 t cfi_jedec_setup
800dd7c8 t jedec_probe_chip
800de138 T jedec_probe
800de15c t cfi_build_cmd
800de1e0 t cfi_write
800de2ac t jedec_match
800de640 T map_rom_probe
800de74c t maprom_read
800de790 t maprom_nop
800de798 t maprom_write
800de7c0 t mr_proto1_set_vpp
800de804 T physmap_set_partitions
800de820 T move_addr_to_kernel
800de890 T move_addr_to_user
800de92c t sockfs_statfs
800de950 t sockfs_read_super
800dea54 t sockfs_delete_dentry
800dea5c t sock_map_fd
800dec74 T sockfd_lookup
800ded1c T sock_alloc
800dedc0 t sock_no_open
800dedc8 T sock_release
800dee58 T sock_sendmsg
800def34 T sock_recvmsg
800df054 t sock_lseek
800df060 t sock_read
800df0e0 t sock_write
800df180 t sock_sendpage
800df1ec T sock_readv_writev
800df28c t sock_readv
800df2e8 t sock_writev
800df344 t sock_ioctl
800df370 t sock_poll
800df3a4 t sock_mmap
800df3d8 t sock_close
800df42c t sock_fasync
800df710 T sock_wake_async
800df7d4 T sock_create
800df930 T sys_socket
800df980 T sys_socketpair
800dfac4 T sys_bind
800dfb50 T sys_listen
800dfbb8 T sys_accept
800dfcc4 T sys_connect
800dfd54 T sys_getsockname
800dfde8 T sys_getpeername
800dfe7c T sys_sendto
800dff70 T sys_send
800dff90 T sys_recvfrom
800e00a0 T sys_recv
800e00c0 T sys_setsockopt
800e017c T sys_getsockopt
800e0230 T sys_shutdown
800e0290 T sys_sendmsg
800e0494 T sys_recvmsg
800e067c T sock_fcntl
800e06c4 T sys_socketcall
800e08ac T sock_register
800e0918 T sock_unregister
800e0940 T socket_get_info
800e09f0 t sock_set_timeout
800e0abc T sock_setsockopt
800e10c4 T sock_getsockopt
800e154c T sk_alloc
800e15d0 T sk_free
800e163c T sock_wfree
800e16c4 T sock_rfree
800e16e8 T sock_wmalloc
800e1784 T sock_rmalloc
800e1808 T sock_kmalloc
800e18a4 T sock_kfree_s
800e18ec t sock_wait_for_wmem
800e19e8 T sock_alloc_send_pskb
800e1c20 T sock_alloc_send_skb
800e1c48 T __lock_sock
800e1d20 T __release_sock
800e1d7c T sklist_remove_socket
800e1e44 T sklist_insert_socket
800e1ec0 t sklist_destroy_timer
800e1ee0 T sklist_destroy_socket
800e2064 T sock_no_release
800e206c T sock_no_bind
800e2074 T sock_no_connect
800e207c T sock_no_socketpair
800e2084 T sock_no_accept
800e208c T sock_no_getname
800e2094 T sock_no_poll
800e209c T sock_no_ioctl
800e20a4 T sock_no_listen
800e20ac T sock_no_shutdown
800e20b4 T sock_no_setsockopt
800e20bc T sock_no_getsockopt
800e20c4 T sock_no_fcntl
800e213c T sock_no_sendmsg
800e2144 T sock_no_recvmsg
800e214c T sock_no_mmap
800e2154 T sock_no_sendpage
800e21c0 T sock_def_wakeup
800e2204 T sock_def_error_report
800e2280 T sock_def_readable
800e22fc T sock_def_write_space
800e23bc T sock_def_destruct
800e23ec T sock_init_data
800e24f0 T skb_over_panic
800e2550 T skb_under_panic
800e25b0 T alloc_skb
800e2848 t skb_drop_fraglist
800e28b4 t skb_clone_fraglist
800e28f0 t skb_release_data
800e29b4 T kfree_skbmem
800e2a80 T __kfree_skb
800e2b80 T skb_clone
800e2da0 t copy_skb_header
800e2e84 T skb_copy
800e2fcc T skb_linearize
800e3170 T pskb_copy
800e333c T pskb_expand_head
800e35a4 T skb_realloc_headroom
800e3668 T skb_copy_expand
800e378c T ___pskb_trim
800e397c T __pskb_pull_tail
800e3d30 T skb_copy_bits
800e3f34 T skb_checksum
800e41bc T skb_copy_and_csum_bits
800e4470 T skb_copy_and_csum_dev
800e4574 t skb_headerinit
800e45e0 T verify_iovec
800e46c8 T memcpy_toiovec
800e4778 T memcpy_tokerneliovec
800e480c T memcpy_fromiovec
800e48c8 T memcpy_fromiovecend
800e49a0 T csum_partial_copy_fromiovecend
800e4c40 t wait_for_packet
800e4da8 T skb_recv_datagram
800e4f64 T skb_free_datagram
800e4fac T skb_copy_datagram
800e4fd4 T skb_copy_datagram_iovec
800e51d0 T skb_copy_and_csum_datagram
800e54b8 T skb_copy_and_csum_datagram_iovec
800e5600 T datagram_poll
800e572c t csum_and_copy_to_user
800e57d0 t scm_fp_copy
800e58e0 T __scm_destroy
800e5954 T __scm_send
800e5bb4 T put_cmsg
800e5cc4 T scm_detach_fds
800e5f70 T scm_fp_dup
800e6030 T dev_add_pack
800e60f4 T dev_remove_pack
800e6220 T netdev_boot_setup_add
800e62e4 T netdev_boot_setup_check
800e63bc T __dev_get_by_name
800e6420 T dev_get_by_name
800e6458 T dev_get
800e6478 T __dev_get_by_index
800e64ac T dev_get_by_index
800e64e4 T dev_getbyhwaddr
800e65e4 T dev_alloc_name
800e66ac T dev_alloc
800e6748 T netdev_state_change
800e67a4 T dev_load
800e680c t default_rebuild_header
800e6884 T dev_open
800e698c T dev_close
800e6a6c T register_netdevice_notifier
800e6a94 T unregister_netdevice_notifier
800e6abc T dev_queue_xmit_nit
800e6bd0 T skb_checksum_help
800e6cf0 T dev_queue_xmit
800e7058 t get_sample_stats
800e70dc T netif_rx
800e72cc t deliver_to_old_ones
800e73d4 t net_tx_action
800e7530 T net_call_rx_atomic
800e7594 t net_rx_action
800e7988 T register_gifconf
800e79b0 t dev_ifname
800e7a6c t dev_ifconf
800e7bb4 t sprintf_stats
800e7ce4 t dev_get_info
800e7dd4 t dev_proc_stats
800e7ea0 T netdev_set_master
800e8034 T dev_set_promiscuity
800e80c0 T dev_set_allmulti
800e8114 T dev_change_flags
800e8278 t dev_ifsioc
800e8728 T dev_ioctl
800e8a88 T dev_new_index
800e8ad8 T register_netdevice
800e8c90 T netdev_finish_unregister
800e8d7c T unregister_netdevice
800e9078 t net_run_sbin_hotplug
800e9130 t __dev_mc_upload
800e9180 T dev_mc_upload
800e91e4 T dev_mc_delete
800e9364 T dev_mc_add
800e9550 T dev_mc_discard
800e961c t dev_mc_read_proc
800e9830 t dst_run_gc
800e991c t dst_discard
800e9968 t dst_blackhole
800e99b4 T dst_alloc
800e9aa0 T __dst_free
800e9bb8 T dst_destroy
800e9cfc t dst_dev_event
800e9ef0 t neigh_blackhole
800e9f3c T neigh_rand_reach_time
800e9f78 t neigh_forced_gc
800ea0f4 t neigh_del_timer
800ea16c t pneigh_queue_purge
800ea284 T neigh_ifdown
800ea4e0 t neigh_alloc
800ea628 T neigh_lookup
800ea738 T neigh_create
800ea9d4 T pneigh_lookup
800eabc8 T pneigh_delete
800ead08 t pneigh_ifdown
800eadd8 T neigh_destroy
800eb058 t neigh_suspect
800eb090 t neigh_connect
800eb0c8 t neigh_sync
800eb178 t neigh_periodic_timer
800eb31c t neigh_timer_handler
800eb5b0 T __neigh_event_send
800eb8d4 T neigh_update
800ebcb8 T neigh_event_ns
800ebd9c t neigh_hh_init
800ebed8 T neigh_compat_output
800ebfd4 T neigh_resolve_output
800ec24c T neigh_connected_output
800ec3b0 t neigh_proxy_process
800ec544 T pneigh_enqueue
800ec6a4 T neigh_parms_alloc
800ec7d0 T neigh_parms_release
800ec8c8 T neigh_table_init
800ec9c8 T neigh_table_clear
800eca74 T neigh_delete
800ecc20 T neigh_add
800ecec8 t neigh_fill_info
800ed1fc t neigh_dump_table
800ed394 T neigh_dump_info
800ed470 T neigh_sysctl_register
800ed610 T neigh_sysctl_unregister
800ed650 t neigh_update_hhs
800ed710 T rtnl_lock
800ed75c T rtnl_unlock
800ed7dc T rtattr_parse
800ed8c0 T __rta_fill
800ed9b0 T rtnetlink_send
800eda5c T rtnetlink_put_metrics
800edbd4 t rtnetlink_fill_ifinfo
800ee014 T rtnetlink_dump_ifinfo
800ee0c0 T rtnetlink_dump_all
800ee1b4 T rtmsg_ifinfo
800ee28c t rtnetlink_done
800ee294 t rtnetlink_rcv
800ee5e8 t rtnetlink_event
800ee660 t rtnetlink_rcv_msg
800ee980 T net_random
800ee9cc T net_srandom
800ee9f8 T net_ratelimit
800eeb30 T eth_header
800eec60 T eth_rebuild_header
800eecd8 T eth_type_trans
800eedf8 T eth_header_parse
800eee24 T eth_header_cache
800eeeac T eth_header_cache_update
800eeee0 t p8023_datalink_header
800eef18 T make_8023_client
800eef5c T destroy_8023_client
800eef80 T qdisc_restart
800ef0ec t dev_watchdog
800ef204 t dev_watchdog_init
800ef220 T __netdev_watchdog_up
800ef28c t dev_watchdog_up
800ef2f0 t dev_watchdog_down
800ef380 t noop_enqueue
800ef3cc t noop_dequeue
800ef3d4 t noop_requeue
800ef44c t pfifo_fast_enqueue
800ef520 t pfifo_fast_dequeue
800ef594 t pfifo_fast_requeue
800ef5f4 t pfifo_fast_reset
800ef700 t pfifo_fast_init
800ef728 T qdisc_create_dflt
800ef800 T qdisc_reset
800ef834 T qdisc_destroy
800ef8d8 T dev_activate
800ef9d8 T dev_deactivate
800efa9c T dev_init_scheduler
800efb24 T dev_shutdown
800efc00 t netlink_sock_destruct
800efdac t netlink_table_grab
800efeac t netlink_insert
800effcc t netlink_remove
800f0094 t netlink_create
800f01b0 t netlink_release
800f0398 t netlink_autobind
800f04d0 t netlink_bind
800f05a8 t netlink_connect
800f067c t netlink_getname
800f06cc t netlink_overrun
800f0718 T netlink_unicast
800f0adc T netlink_broadcast
800f0e2c T netlink_set_err
800f0ed8 t netlink_sendmsg
800f117c t netlink_recvmsg
800f1348 T netlink_data_ready
800f13f4 T netlink_kernel_create
800f14ac t netlink_destroy_callback
800f1514 t netlink_dump
800f17cc T netlink_dump_start
800f1938 T netlink_ack
800f1a88 t netlink_read_proc
800f1c10 T in_ntoa
800f1c64 T in_aton
800f1d30 t rt_cache_get_info
800f1fb0 t rt_cache_stat_get_info
800f2088 t rt_check_expire
800f2284 t rt_run_flush
800f2394 T rt_cache_flush
800f2518 t rt_garbage_collect
800f29a4 t rt_intern_hash
800f2d60 T rt_bind_peer
800f2e04 t ip_select_fb_ident
800f2ea4 T __ip_select_ident
800f2f90 t rt_del
800f3080 T ip_rt_redirect
800f3638 t ipv4_negative_advice
800f3708 T ip_rt_send_redirect
800f3840 t ip_error
800f3948 T ip_rt_frag_needed
800f3bf8 T ip_rt_update_pmtu
800f3c80 t ipv4_dst_check
800f3ca8 t ipv4_dst_reroute
800f3cb0 t ipv4_dst_destroy
800f3cdc t ipv4_link_failure
800f3d40 t ip_rt_bug
800f3df0 T ip_rt_get_source
800f3f10 t rt_set_nexthop
800f402c t ip_route_input_mc
800f4308 T ip_route_input_slow
800f49c4 T ip_route_input
800f4b84 T ip_route_output_slow
800f53e0 T ip_route_output_key
800f55c8 t rt_fill_info
800f5a58 T inet_rtm_getroute
800f5d24 T ip_rt_dump
800f5f6c T ip_rt_multicast_event
800f5f88 t ipv4_sysctl_rtcache_flush
800f5fc4 t ipv4_sysctl_rtcache_flush_strategy
800f6028 t inet_putpeer
800f60e0 t unlink_from_unused
800f6178 t peer_avl_rebalance
800f62c4 t unlink_from_pool
800f6500 t cleanup_once
800f6634 T inet_getpeer
800f6918 t peer_check_expire
800f6a8c t inet_putpeer
800f6b40 t fold_prot_inuse
800f6b48 T afinet_get_info
800f6c94 t fold_field
800f6cbc T snmp_get_info
800f6eb4 T netstat_get_info
800f6fa0 T inet_add_protocol
800f7064 T inet_del_protocol
800f71d0 T ip_call_ra_chain
800f72e8 t ip_run_ipprot
800f73a0 T ip_local_deliver
800f73e4 T ip_rcv
800f7698 t ip_local_deliver_finish
800f7884 t ip_rcv_finish
800f7b30 t ip_frag_destroy
800f7c44 t ip_evictor
800f7df0 t ip_expire
800f7f74 t ip_frag_intern
800f8038 t ip_frag_create
800f8130 t ip_frag_queue
800f85cc t ip_frag_reasm
800f89f8 T ip_defrag
800f8be0 T ip_forward
800f8ea0 T ip_options_build
800f90f0 T ip_options_echo
800f9490 T ip_options_fragment
800f9580 T ip_options_compile
800f9b80 T ip_options_undo
800f9cc0 T ip_options_get
800f9e0c T ip_forward_options
800f9fd8 T ip_options_rcv_srr
800fa1e0 t ip_dev_loopback_xmit
800fa2a0 T ip_build_and_send_pkt
800fa564 T ip_mc_output
800fa6c8 T ip_output
800fa740 T ip_queue_xmit
800faa60 t ip_build_xmit_slow
800fb090 T ip_build_xmit
800fb514 T ip_fragment
800fba20 t ip_reply_glue_bits
800fbb28 T ip_send_reply
800fbc8c T ip_send_check
800fbd14 T ip_finish_output
800fbd40 t ip_finish_output2
800fbec0 t ip_queue_xmit2
800fc250 t ip_cmsg_recv_pktinfo
800fc2ac t ip_cmsg_recv_ttl
800fc2e4 t ip_cmsg_recv_tos
800fc314 t ip_cmsg_recv_opts
800fc358 T ip_cmsg_recv_retopts
800fc3dc T ip_cmsg_recv
800fc4c0 T ip_cmsg_send
800fc5f4 T ip_ra_control
800fc854 T ip_icmp_error
800fca90 T ip_local_error
800fcd20 T ip_recv_error
800fd004 T ip_setsockopt
800fd858 T ip_getsockopt
800fe080 T tcp_mem_schedule
800fe310 T __tcp_mem_reclaim
800fe394 T tcp_rfree
800fe3c4 T tcp_poll
800fe570 T tcp_write_space
800fe644 T tcp_ioctl
800fe8d4 T tcp_listen_start
800fea9c t tcp_listen_stop
800fed98 t wait_for_tcp_connect
800fefe0 t wait_for_tcp_memory
800ff2fc t tcp_error
800ff388 T do_tcp_sendpages
800ffd28 T tcp_sendpage
800ffeb4 T tcp_sendmsg
80100f1c t tcp_recv_urg
80101028 t cleanup_rbuf
801011b0 t tcp_data_wait
8010137c t tcp_prequeue_process
80101474 T tcp_recvmsg
80101e08 t tcp_close_state
80101f48 T tcp_shutdown
80101fa8 T tcp_destroy_sock
80102274 T tcp_close
80102be0 T tcp_disconnect
80102fe4 t wait_for_connect
801031d4 T tcp_accept
8010345c T tcp_setsockopt
80103a28 T tcp_getsockopt
80103fd4 t __skb_dequeue
80104010 t tcp_reset_xmit_timer
8010410c t tcp_cwnd_validate
80104180 t tcp_incr_quickack
801041cc T tcp_enter_quickack_mode
801041fc t tcp_fixup_sndbuf
80104240 t __tcp_grow_window
801042d4 t tcp_fixup_rcvbuf
80104340 t tcp_init_buffer_space
80104480 t tcp_clamp_window
801045a8 t tcp_event_data_recv
801047b8 T tcp_update_metrics
801049d4 T tcp_init_cwnd
80104a44 t tcp_init_metrics
80104bdc t tcp_update_reordering
80104c5c t tcp_sacktag_write_queue
801052f4 T tcp_clear_retrans
80105314 T tcp_enter_loss
80105528 t tcp_check_sack_reneging
801055e4 t tcp_time_to_recover
80105828 t tcp_check_reno_reordering
80105890 t tcp_add_reno_sack
80105900 t tcp_remove_reno_sacks
80105990 t tcp_mark_head_lost
80105aa4 t tcp_update_scoreboard
80105c08 t tcp_cwnd_down
80105c84 t tcp_undo_cwr
80105d30 t tcp_try_undo_recovery
80105e54 t tcp_try_undo_dsack
80105eb0 t tcp_try_undo_partial
80105fa8 t tcp_try_undo_loss
801060a4 t tcp_try_to_open
801061ec t tcp_fastretrans_alert
8010675c t tcp_ack_saw_tstamp
801067b8 t tcp_ack_no_tstamp
80106814 t tcp_clean_rtx_queue
80106b54 t tcp_ack_probe
80106bbc t tcp_ack_update_window
80106d14 t tcp_ack
801070c8 T tcp_parse_options
801073a8 t tcp_disordered_ack
8010747c t tcp_reset
801075d4 t tcp_fin
801078a4 t tcp_send_dupack
801079bc t tcp_sack_maybe_coalesce
80107ab4 t tcp_sack_new_ofo_skb
80107c0c t tcp_sack_remove
80107d30 t tcp_ofo_queue
80107fc8 t tcp_data_queue
80108c20 t tcp_collapse
8010907c t tcp_collapse_ofo_queue
80109144 t tcp_prune_queue
80109364 T tcp_cwnd_application_limited
801093f4 t tcp_new_space
801094c4 t __tcp_data_snd_check
8010956c t tcp_check_urg
80109738 t tcp_copy_to_iovec
80109828 t __tcp_checksum_complete_user
80109900 T tcp_rcv_established
8010a11c t tcp_rcv_synsent_state_process
8010a6a4 T tcp_rcv_state_process
8010b0ec t tcp_reset_xmit_timer
8010b1e8 t tcp_initialize_rcv_mss
8010b24c t tcp_measure_rcv_mss
8010b2f0 t tcp_rtt_estimator
8010b3f0 t tcp_fast_parse_options
8010b4cc t tcp_urg
8010b610 t tcp_advertise_mss
8010b640 t tcp_cwnd_restart
8010b724 T tcp_transmit_skb
8010bc5c T tcp_send_skb
8010be68 T tcp_push_one
8010bf54 t skb_split
8010c1d8 t tcp_fragment
8010c56c T tcp_sync_mss
8010c5f4 T tcp_write_xmit
8010c8d4 T __tcp_select_window
8010c9ec t tcp_retrans_try_collapse
8010ccec T tcp_simple_retransmit
8010cea0 T tcp_retransmit_skb
8010d1e8 T tcp_xmit_retransmit_queue
8010d578 T tcp_send_fin
8010d764 T tcp_send_active_reset
8010d848 T tcp_send_synack
8010d9fc T tcp_make_synack
8010dd68 T tcp_connect
8010e120 T tcp_send_delayed_ack
8010e234 T tcp_send_ack
8010e30c t tcp_xmit_probe_skb
8010e3a8 T tcp_write_wakeup
8010e5b4 T tcp_send_probe0
8010e67c t tcp_reset_xmit_timer
8010e778 t tcp_initialize_rcv_mss
8010e7dc t TCP_ECN_send
8010e870 t tcp_cwnd_validate
8010e8e4 t tcp_build_and_update_options
8010ea78 t tcp_syn_build_options
8010eba0 t tcp_select_initial_window
8010ed40 t tcp_moderate_sndbuf
8010ed90 T tcp_init_xmit_timers
8010ede8 T tcp_clear_xmit_timers
8010eec8 t tcp_write_err
8010eff8 t tcp_out_of_resources
8010f208 t tcp_orphan_retries
8010f248 t tcp_write_timeout
8010f3b8 t tcp_delack_timer
8010f60c t tcp_probe_timer
8010f6f0 t tcp_retransmit_timer
8010f9ec t tcp_write_timer
8010fb30 t tcp_synack_timer
8010fd68 T tcp_delete_keepalive_timer
8010fdc0 T tcp_reset_keepalive_timer
8010fe14 T tcp_set_keepalive
8010fe80 t tcp_keepalive_timer
80110198 t tcp_reset_xmit_timer
801102a0 T tcp_bucket_create
80110310 t tcp_v4_get_port
8011061c T tcp_put_port
801106d4 T tcp_listen_wlock
801107c4 t tcp_v4_hash
80110838 T tcp_unhash
80110930 t __tcp_v4_lookup_listener
801109b4 t tcp_v4_check_established
80110ce0 T tcp_v4_hash_connecting
80110db8 T tcp_v4_connect
80111144 t tcp_v4_search_req
80111210 t tcp_v4_synq_add
801112bc T tcp_v4_err
80111970 T tcp_v4_send_check
80111ab4 t tcp_v4_send_reset
80111c98 t tcp_v4_send_ack
80111edc t tcp_v4_timewait_ack
80111f54 t tcp_v4_or_send_ack
80111f8c t tcp_v4_route_req
8011209c t tcp_v4_send_synack
80112200 t tcp_v4_or_free
80112230 T tcp_v4_conn_request
8011271c T tcp_v4_syn_recv_sock
801128dc t tcp_v4_hnd_req
80112ae8 t tcp_v4_checksum_init
80112ce8 T tcp_v4_do_rcv
80112e68 T tcp_v4_rcv
801134c8 t __tcp_v4_rehash
80113504 t tcp_v4_reselect_saddr
801136ec T tcp_v4_rebuild_header
80113880 t v4_addr2sockaddr
8011389c T tcp_v4_remember_stamp
80113988 T tcp_v4_tw_remember_stamp
80113a1c t tcp_v4_init_sock
80113b10 t tcp_v4_destroy_sock
80113d40 t get_openreq
80113dfc t get_tcp_sock
80113fd4 t get_timewait_sock
8011408c T tcp_get_info
80114570 T tcp_inherit_port
801145fc T __tcp_put_port
80114664 T tcp_v4_lookup_listener
80114710 T tcp_v4_lookup
801147e0 t inet_putpeer
80114894 t tcp_initialize_rcv_mss
801148f8 t tcp_prequeue
80114a6c t __tcp_v4_hash
80114b98 t __tcp_v4_lookup_established
80114cc4 t tcp_reset_xmit_timer
80114dc0 T tcp_timewait_kill
80114e98 T tcp_timewait_state_process
80115284 t __tcp_tw_hashdance
80115394 T tcp_time_wait
80115698 t tcp_twkill
801157d4 T tcp_tw_deschedule
80115870 T tcp_tw_schedule
80115a88 t tcp_twcal_tick
80115c40 T tcp_create_openreq_child
80116018 T tcp_check_req
801163f4 T tcp_child_process
801164e0 t tcpdiag_fill
80116c08 t tcpdiag_get_exact
80116dc4 T bitstring_match
80116e8c T tcpdiag_bc_run
80117080 T valid_cc
801170c4 T tcpdiag_bc_audit
801171f0 T tcpdiag_dump
801176c4 t tcpdiag_dump_done
801176cc t tcpdiag_rcv
801178d0 t raw_v4_hash
80117994 t raw_v4_unhash
80117a44 T __raw_v4_lookup
80117ab0 T raw_v4_input
80117be8 T raw_err
80117d40 t raw_rcv_skb
80117f04 T raw_rcv
80117f88 t raw_getfrag
80117fac t raw_getrawfrag
801180f0 t raw_sendmsg
80118440 t raw_close
80118474 t raw_bind
80118558 T raw_recvmsg
801186dc t raw_init
80118700 t raw_seticmpfilter
8011875c t raw_geticmpfilter
80118800 t raw_setsockopt
8011885c t raw_getsockopt
801188b8 t raw_ioctl
80118984 t get_raw_sock
80118a24 T raw_get_info
80118b80 t udp_v4_get_port
80118ea0 t udp_v4_hash
80118ed0 t udp_v4_unhash
80118f84 T udp_v4_lookup_longway
80119060 T udp_err
80119248 t udp_check
801192b0 t udp_getfrag
801193d0 t udp_getfrag_nosum
8011943c T udp_sendmsg
801198f0 T udp_ioctl
801199c4 T udp_recvmsg
80119cb4 T udp_connect
80119ee8 T udp_disconnect
80119f78 t udp_close
80119f94 t udp_queue_rcv_skb
8011a114 t udp_v4_mcast_deliver
8011a330 t udp_checksum_init
8011a444 T udp_rcv
8011a7b4 t get_udp_sock
8011a878 T udp_get_info
8011a9d4 T udp_v4_lookup
8011aa20 T arp_mc_map
8011ab14 t arp_hash
8011ab44 t arp_constructor
8011acf0 t arp_error_report
8011ad74 t arp_solicit
8011aed4 t arp_filter
8011af9c t arp_set_predefined
8011b03c T arp_find
8011b268 T arp_bind_neighbour
8011b328 T arp_send
8011b5cc t parp_redo
8011b5ec T arp_rcv
8011bbcc T arp_req_set
8011be1c t arp_state_to_flags
8011be4c t arp_req_get
8011bf70 T arp_req_delete
8011c0f4 T arp_ioctl
8011c310 t arp_get_info
8011c6e0 T arp_ifdown
8011c710 t icmp_xmit_lock_bh
8011c720 t icmp_xmit_unlock_bh
8011c730 T xrlim_allow
8011c790 t icmp_out_count
8011c810 t icmp_glue_bits
8011c8c8 t icmp_reply
8011cacc T icmp_send
8011cf24 t icmp_unreach
8011d248 t icmp_redirect
8011d300 t icmp_echo
8011d368 t icmp_timestamp
8011d4e0 t icmp_address
8011d4e8 t icmp_address_reply
8011d6a0 t icmp_discard
8011d6a8 T icmp_rcv
8011d8f0 t inet_alloc_ifa
8011d94c T in_dev_finish_destroy
8011da2c T inetdev_init
8011dc64 t inetdev_destroy
8011de28 T inet_addr_onlink
8011de9c t inet_del_ifa
8011e160 t inet_insert_ifa
8011e3f4 t inet_set_ifa
8011e580 T inetdev_by_index
8011e5c8 T inet_ifa_byprefix
8011e6f0 T inet_rtm_deladdr
8011e8b4 T inet_rtm_newaddr
8011eb60 T devinet_ioctl
8011f358 t inet_gifconf
8011f478 T inet_select_addr
8011f584 T register_inetaddr_notifier
8011f5ac T unregister_inetaddr_notifier
8011f5d4 t inetdev_event
8011f838 t inet_fill_ifaddr
8011fb1c t inet_dump_ifaddr
8011fc2c t rtmsg_ifa
8011fd18 T inet_forward_change
8011fd74 t devinet_sysctl_forward
8011fe10 t devinet_sysctl_register
8011ff68 t devinet_sysctl_unregister
8011ffa8 t ffz
80120010 T inet_sock_destruct
80120270 T inet_sock_release
8012033c T inet_setsockopt
8012036c T inet_getsockopt
8012039c t inet_autobind
80120598 T inet_listen
80120740 t inet_create
801209ec T inet_release
80120a60 t inet_bind
80120d64 T inet_dgram_connect
80120e00 t inet_wait_for_connect
80120fdc T inet_stream_connect
80121300 T inet_accept
801214e8 t inet_getname
80121564 T inet_recvmsg
801215bc T inet_sendmsg
80121630 T inet_shutdown
80121878 t inet_ioctl
80121b50 T inet_register_protosw
80121c60 T inet_unregister_protosw
80121cf0 t ip_ma_put
80121d68 t ip_mc_filter_add
80121dbc t ip_mc_filter_del
80121e10 t igmp_group_dropped
80121e48 t igmp_group_added
80121e84 T ip_mc_inc_group
80122024 T ip_mc_dec_group
80122198 T ip_mc_down
8012226c T ip_mc_up
80122340 T ip_mc_destroy_dev
801224b8 t ip_mc_find_dev
801225bc T ip_mc_join_group
80122800 T ip_mc_leave_group
80122938 T ip_mc_drop_socket
80122a08 T ip_check_mc
80122a40 t ipv4_sysctl_forward
80122aa8 t ipv4_sysctl_forward_strategy
80122b20 T fib_flush
80122b84 t fib_get_procinfo
80122c8c T ip_dev_find
80122d70 T inet_addr_type
80122e4c T fib_validate_source
801230f8 T ip_rt_ioctl
80123280 t inet_check_attr
801232d8 T inet_rtm_delroute
80123390 T inet_rtm_newroute
80123448 T inet_dump_fib
80123570 t fib_magic
801236c0 t fib_add_ifaddr
8012385c t fib_del_ifaddr
80123a40 t fib_disable_ip
80123a98 t fib_inetaddr_event
80123b20 t fib_netdev_event
80123bc0 T free_fib_info
80123c6c T fib_release_info
80123d0c T ip_fib_check_default
80123d70 T fib_nh_match
80123df8 t fib_check_nh
80124084 T fib_create_info
801244cc T fib_semantic_match
801245a0 T __fib_res_prefsrc
801245c8 T fib_dump_info
80124904 T fib_convert_rtentry
80124d68 T fib_sync_down
80124e18 t fib_flag_trans
80124e58 T fib_node_get_info
80124f70 t ffz
80124fe0 t fn_free_node
80125018 t fn_new_zone
801251d4 t fn_hash_lookup
80125338 t fib_detect_death
80125444 t fn_hash_select_default
801256f4 t fn_hash_insert
80125bac t fn_hash_delete
80125ef4 t fn_hash_flush
8012603c t fn_hash_get_info
8012616c t fn_hash_dump
80126360 t rtmsg_fib
801264f0 t pnp_get_info
80126650 t unix_mkname
801266fc t __unix_remove_socket
80126760 t __unix_insert_socket
801267e8 t __unix_find_socket_byname
80126878 t unix_find_socket_byinode
801268e0 t unix_write_space
80126978 t unix_dgram_disconnected
80126ab8 t unix_sock_destructor
80126c90 t unix_release_sock
80126f94 t unix_listen
80127054 t unix_create1
80127164 t unix_create
801271ec t unix_release
8012721c t unix_autobind
80127408 t unix_find_other
80127558 t unix_bind
80127928 t unix_dgram_connect
80127a94 t unix_wait_for_peer
80127b60 t unix_stream_connect
80127fa8 t unix_socketpair
80128038 t unix_accept
80128150 t unix_getname
80128244 t unix_detach_fds
801282b8 t unix_destruct_fds
80128324 t unix_attach_fds
801283a0 t unix_dgram_sendmsg
80128860 t unix_stream_sendmsg
80128c4c t unix_copy_addr
80128c98 t unix_dgram_recvmsg
80128e08 t unix_stream_data_wait
80128f0c t unix_stream_recvmsg
8012943c t unix_shutdown
80129594 t unix_ioctl
80129658 t unix_poll
80129728 t unix_read_proc
80129950 T unix_inflight
801299d0 T unix_notinflight
80129a50 T unix_gc
80129ee0 T unix_sysctl_register
80129f0c T unix_sysctl_unregister
80129f30 T packet_sock_destruct
80129ff8 t packet_rcv_spkt
8012a238 t packet_sendmsg_spkt
8012a4c0 t packet_rcv
8012a7a4 t packet_sendmsg
8012aad8 t packet_release
8012ad44 t packet_do_bind
8012af50 t packet_bind_spkt
8012b01c t packet_bind
8012b0f8 t packet_create
8012b32c t packet_recvmsg
8012b480 t packet_getname_spkt
8012b55c t packet_getname
8012b63c t packet_dev_mc
8012b6c8 t packet_dev_mclist
8012b738 t packet_mc_add
8012b8ac t packet_mc_drop
8012b9d0 t packet_flush_mclist
8012baac t packet_setsockopt
8012bb58 T packet_getsockopt
8012bcd8 t packet_notifier
8012be60 t packet_ioctl
8012c228 t packet_read_proc
8012c3c0 T rpc_create_client
8012c5a4 T rpc_shutdown_client
8012c67c T rpc_destroy_client
8012c70c T rpc_release_client
8012c7b0 t rpc_default_callback
8012c7b8 T rpc_clnt_sigmask
8012c8ec T rpc_clnt_sigunmask
8012c9b4 T rpc_call_sync
8012caa4 T rpc_call_async
8012cb8c T rpc_call_setup
8012cc40 T rpc_restart_call
8012cc8c t call_reserve
8012cd70 t call_reserveresult
8012cec8 t call_allocate
8012cfe4 t call_encode
8012d138 t call_bind
8012d1c4 t call_reconnect
8012d27c t child_reconnect
8012d2b8 t child_reconnect_status
8012d2e0 t call_transmit
8012d38c t call_status
8012d520 t call_timeout
8012d720 t call_decode
8012d964 t call_refresh
8012d9e0 t call_refreshresult
8012da50 t call_header
8012db50 t call_verify
8012ded0 t xprt_lock_write
8012dfc4 t xprt_release_write
8012e044 t xprt_recvmsg
8012e1a4 t xprt_adjust_cwnd
8012e360 T xprt_adjust_timeout
8012e45c t xprt_close
8012e4ec t xprt_disconnect
8012e564 T xprt_reconnect
8012e8ac t xprt_reconn_status
8012e914 t csum_partial_copy_to_page_cache
8012eb04 t udp_data_ready
8012ed38 t tcp_input_record
8012ee90 T xprt_tcp_pending
8012ef08 t xprt_remove_pending
8012ef8c T __rpciod_tcp_dispatcher
8012f03c t tcp_data_ready
8012f17c t tcp_state_change
8012f2d8 t tcp_write_space
8012f400 t udp_write_space
8012f4f4 t xprt_timer
8012f584 T xprt_transmit
8012f6c8 t do_xprt_transmit
8012f95c T xprt_receive
8012f9e0 T xprt_reserve
8012fb40 t xprt_reserve_status
8012fbf0 t xprt_request_init
8012fce0 T xprt_release
8012fe00 T xprt_default_timeout
8012fe38 T xprt_set_timeout
8012fe60 t xprt_setup
801300bc t xprt_bind_socket
801301b0 t xprt_create_socket
8013030c T xprt_create_proto
801303c0 T xprt_shutdown
8013042c T xprt_clear_backlog
8013049c T xprt_destroy
80130504 t xprt_sendmsg
80130700 t xprt_lookup_rqst
80130810 t tcp_read_fraghdr
80130958 t tcp_read_xid
80130a44 t tcp_read_request
80130bec t tcp_read_discard
80130cb0 t xprt_append_pending
80130d74 t xprt_remove_pending_next
80130e20 t rpc_run_timer
80130ed0 T rpc_add_timer
80130ffc T rpc_add_wait_queue
80131148 T rpc_remove_wait_queue
8013122c T rpciod_wake_up
80131290 t __rpc_sleep_on
80131554 T rpc_sleep_on
801315b8 T rpc_sleep_locked
80131630 t __rpc_wake_up_task
801317f8 t __rpc_default_timer
80131850 T rpc_wake_up_task
801318c4 T rpc_wake_up_next
80131988 T rpc_wake_up
80131a1c T rpc_wake_up_status
80131ab4 T __rpc_lock_task
80131ae0 T rpc_unlock_task
80131b78 T rpc_delay
80131bb0 t __rpc_atrun
80131bd0 t __rpc_execute
80131fcc T rpc_execute
8013206c t __rpc_schedule
801322a8 T rpc_allocate
801323f8 T rpc_free
80132448 T rpc_init_task
801325a4 t rpc_default_free_task
801325f4 T rpc_new_task
801326f4 T rpc_release_task
80132970 t rpc_child_exit
80132a1c T rpc_new_child
80132a78 T rpc_run_child
80132b34 T rpc_killall_tasks
80132bdc t rpciod
80132fa0 t rpciod_killall
801330d4 T rpciod_up
80133260 T rpciod_down
801334dc T rpc_show_tasks
801335a8 t __rpc_append_list
801335d8 t rpc_make_runnable
801337b0 T rpcauth_register
801337ec T rpcauth_unregister
8013382c T rpcauth_create
80133880 T rpcauth_destroy
801338a4 T rpcauth_init_credcache
801338e8 T rpcauth_free_credcache
801339f8 t rpcauth_gc_credcache
80133b70 T rpcauth_insert_credcache
80133bb0 t rpcauth_lookup_credcache
80133cb8 t rpcauth_remove_credcache
80133d04 T rpcauth_lookupcred
80133d68 T rpcauth_bindcred
80133de8 T rpcauth_matchcred
80133e58 T rpcauth_holdcred
80133ed4 T put_rpccred
80133fd8 T rpcauth_unbindcred
8013404c T rpcauth_marshcred
801340dc T rpcauth_checkverf
80134164 T rpcauth_refreshcred
801341e0 T rpcauth_invalcred
80134250 T rpcauth_uptodatecred
80134280 t nul_create
80134314 t nul_destroy
80134370 t nul_create_cred
801343bc t nul_destroy_cred
801343d8 t nul_match
801343e0 t nul_marshal
80134408 t nul_refresh
80134414 t nul_validate
801344d0 t unx_create
80134560 t unx_destroy
801345bc t unx_create_cred
801346d0 T authunix_fake_cred
80134778 t unx_destroy_cred
80134794 t unx_match
80134880 t unx_marshal
80134b90 t unx_refresh
80134bb0 t unx_validate
80134c90 T svc_create
80134d40 T svc_destroy
80134dfc T svc_init_buffer
80134e68 T svc_release_buffer
80134e94 T svc_create_thread
80134f7c T svc_exit_thread
80135000 T svc_register
801351b4 T svc_process
80135890 t svc_sock_enqueue
80135a3c T svc_wake_up
80135aec t svc_sendto
80135bec t svc_recv_available
80135c34 t svc_recvfrom
80135d38 t svc_udp_data_ready
80135e2c t svc_udp_recvfrom
80136034 t svc_udp_sendto
801360c8 t svc_udp_init
801360f8 t svc_tcp_listen_data_ready
801361fc t svc_tcp_state_change
801362f0 t svc_tcp_data_ready
801363d8 t svc_tcp_accept
801366b4 t svc_tcp_recvfrom
801369ec t svc_tcp_sendto
80136aa8 t svc_tcp_init
80136b88 T svc_recv
80137038 T svc_drop
80137088 T svc_send
80137184 t svc_setup_socket
80137380 t svc_create_socket
80137510 T svc_delete_socket
801376e8 T svc_makesock
80137778 t svc_sock_received
80137864 t svc_sock_accepted
80137934 t svc_sock_release
80137aa0 T svc_authenticate
80137b90 T svc_auth_register
80137bc8 T svc_auth_unregister
80137bec t svcauth_null
80137d18 t svcauth_unix
80137f70 T rpc_getport
801380cc t pmap_getport_done
80138180 T rpc_register
801382d4 t pmap_create
80138364 t xdr_error
8013836c t xdr_encode_mapping
801384b0 t xdr_decode_port
801384d0 t xdr_decode_bool
80138510 T xdr_encode_netobj
801385ac T xdr_decode_netobj_fixed
80138628 T xdr_decode_netobj
80138684 T xdr_encode_array
801386f8 T xdr_encode_string
8013873c T xdr_decode_string
801387fc T xdr_decode_string_inplace
80138858 T xdr_shift_iovec
80138914 T xdr_zero_iovec
801389c0 T rpc_proc_read
80138b80 T svc_proc_read
80138d5c T rpc_proc_register
80138de4 T rpc_proc_unregister
80138e08 T svc_proc_register
80138e90 T svc_proc_unregister
80138eb4 T rpc_proc_init
80138f28 T rpc_proc_exit
80138f90 T rpc_register_sysctl
80138ff4 T rpc_unregister_sysctl
80139030 t proc_dodebug
80139360 t small_csumcpy
80139420 T csum_partial
8013943c t hwor