From agx@sigxcpu.org Tue Jun  1 00:08:08 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 01 Jun 2004 00:08:12 +0100 (BST)
Received: from honk1.physik.uni-konstanz.de ([IPv6:::ffff:134.34.140.224]:45264
	"EHLO honk1.physik.uni-konstanz.de") by linux-mips.org with ESMTP
	id <S8225264AbUEaXII>; Tue, 1 Jun 2004 00:08:08 +0100
Received: from localhost (localhost.localnet [127.0.0.1])
	by honk1.physik.uni-konstanz.de (Postfix) with ESMTP
	id 4E3772BC47; Tue,  1 Jun 2004 01:08:06 +0200 (CEST)
Received: from honk1.physik.uni-konstanz.de ([127.0.0.1])
	by localhost (honk [127.0.0.1]) (amavisd-new, port 10024) with ESMTP
	id 18006-20; Tue, 1 Jun 2004 01:08:02 +0200 (CEST)
Received: from bogon.sigxcpu.org (200-203-027-014.paemt7003.dsl.brasiltelecom.net.br [200.203.27.14])
	(using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits))
	(No client certificate requested)
	by honk1.physik.uni-konstanz.de (Postfix) with ESMTP
	id 060062BC46; Tue,  1 Jun 2004 01:08:01 +0200 (CEST)
Received: by bogon.sigxcpu.org (Postfix, from userid 1000)
	id 5A369404E; Mon, 31 May 2004 20:05:24 -0300 (BRT)
Date: Mon, 31 May 2004 20:05:24 -0300
From: Guido Guenther <agx@sigxcpu.org>
To: linux-mips@linux-mips.org
Cc: debian-toolchain@lists.debian.org
Subject: TLS register
Message-ID: <20040531230524.GB2785@bogon.ms20.nix>
Mail-Followup-To: Guido Guenther <agx@sigxcpu.org>,
	linux-mips@linux-mips.org, debian-toolchain@lists.debian.org
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="oC1+HKm2/end4ao3"
Content-Disposition: inline
User-Agent: Mutt/1.5.6i
X-Virus-Scanned: by amavisd-new-20030616-p7 (Debian) at honk.physik.uni-konstanz.de
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: 5226
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: agx@sigxcpu.org
Precedence: bulk
X-list: linux-mips


--oC1+HKm2/end4ao3
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Hi,
Now that gcc 3.4 has incompatible ABI changes (on o32 mostly affecting
mipsel) I've been discussing with Thiemo if I'd be the right point to
take this ABI change as a possibility to additionally reserve a TLS
register.=20
He suggested $24 (t8) another discussed possibility would be $27 (k1)
which is already abused by the PS/2 folks for ll/sc emulation.
Another possibility would be to reserve such a register only in the
n32/n64 ABIs and let o32 stay without __thread and TLS forever.
Any feedback welcome.
 -- Guido

--oC1+HKm2/end4ao3
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)

iD8DBQFAu7o0n88szT8+ZCYRAvgSAJ42KtGG2qSVpv7fa+JRgHSkl+9f8wCfVyNa
FsR4j3cbTB8k4VXQ/W4gwdE=
=p2ry
-----END PGP SIGNATURE-----

--oC1+HKm2/end4ao3--

From sjhill@realitydiluted.com Tue Jun  1 04:16:48 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 01 Jun 2004 04:16:52 +0100 (BST)
Received: from eth13.com-link.com ([IPv6:::ffff:208.242.241.164]:65446 "EHLO
	real.realitydiluted.com") by linux-mips.org with ESMTP
	id <S8224773AbUFADQs>; Tue, 1 Jun 2004 04:16:48 +0100
Received: from localhost ([127.0.0.1] helo=realitydiluted.com)
	by real.realitydiluted.com with esmtp (Exim 3.36 #1 (Debian))
	id 1BUzlS-0005BN-00; Mon, 31 May 2004 22:16:34 -0500
Message-ID: <40BBF555.6000600@realitydiluted.com>
Date: Mon, 31 May 2004 22:17:41 -0500
From: "Steven J. Hill" <sjhill@realitydiluted.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040528 Debian/1.6-7
X-Accept-Language: en
MIME-Version: 1.0
To: Guido Guenther <agx@sigxcpu.org>
CC: linux-mips@linux-mips.org, debian-toolchain@lists.debian.org
Subject: Re: TLS register
References: <20040531230524.GB2785@bogon.ms20.nix>
In-Reply-To: <20040531230524.GB2785@bogon.ms20.nix>
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: 5227
X-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

Guido Guenther wrote:
>
> He suggested $24 (t8) another discussed possibility would be $27 (k1)
> which is already abused by the PS/2 folks for ll/sc emulation.
> Another possibility would be to reserve such a register only in the
> n32/n64 ABIs and let o32 stay without __thread and TLS forever.
> Any feedback welcome.
>
I vote for $24 (t8). LL/SC emulation is an issue and I believe some of
the exception vectors, if not all of them indirectly depend on k1. It
would take a lot of work (and testing) to rewrite the exceptions to not
utilize k1 and it would probably be a nasty performance hit in many
cases. I agree with "Screw o32" and let's move forward.

-Steve

From rddunlap@osdl.org Tue Jun  1 04:24:56 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 01 Jun 2004 04:25:00 +0100 (BST)
Received: from fw.osdl.org ([IPv6:::ffff:65.172.181.6]:3240 "EHLO
	mail.osdl.org") by linux-mips.org with ESMTP id <S8224930AbUFADYz>;
	Tue, 1 Jun 2004 04:24:55 +0100
Received: from midway.verizon.net (build.pdx.osdl.net [172.20.1.2])
	by mail.osdl.org (8.11.6/8.11.6) with SMTP id i513Opr15187;
	Mon, 31 May 2004 20:24:52 -0700
Date: Mon, 31 May 2004 20:21:01 -0700
From: "Randy.Dunlap" <rddunlap@osdl.org>
To: linux-mips@linux-mips.org
Cc: ralf@gnu.org, rddunlap <rddunlap@osdl.org>
Subject: [PATCH] MIPS getdomainname() off by 1;
Message-Id: <20040531202101.4ace5e95.rddunlap@osdl.org>
Organization: OSDL
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: <rddunlap@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: 5228
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: rddunlap@osdl.org
Precedence: bulk
X-list: linux-mips


irix_getdomainname() max size appears to be off by 1;
other similar code in kernel uses __NEW_UTS_LEN as the max size,
and <domainname> includes an extra byte for the terminating
null character.

Does sysirix.c need to limit <len> to 63 instead of 64 for some
reason?


diffstat:=
 arch/mips/kernel/sysirix.c |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)


diff -Naurp ./arch/mips/kernel/sysirix.c~uts_len_off1 ./arch/mips/kernel/sysirix.c
--- ./arch/mips/kernel/sysirix.c~uts_len_off1	2004-05-31 13:58:24.000000000 -0700
+++ ./arch/mips/kernel/sysirix.c	2004-05-31 20:11:42.000000000 -0700
@@ -913,8 +913,8 @@ asmlinkage int irix_getdomainname(char *
 		return error;
 
 	down_read(&uts_sem);
-	if(len > (__NEW_UTS_LEN - 1))
-		len = __NEW_UTS_LEN - 1;
+	if (len > __NEW_UTS_LEN)
+		len = __NEW_UTS_LEN;
 	error = 0;
 	if (copy_to_user(name, system_utsname.domainname, len))
 		error = -EFAULT;

--
~Randy

From jurij@wooyd.org Tue Jun  1 06:23:23 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 01 Jun 2004 06:23:29 +0100 (BST)
Received: from ns2.dnsjunction.com ([IPv6:::ffff:216.193.201.5]:1801 "EHLO
	cuba.globat.com") by linux-mips.org with ESMTP id <S8224918AbUFAFXX>;
	Tue, 1 Jun 2004 06:23:23 +0100
Received: from stmaarten.globat.com (stmaarten.inside.globat.com [10.1.1.23])
	by cuba.globat.com (8.12.9p2/8.12.9) with SMTP id i515NEYk044389
	for <linux-mips@linux-mips.org>; Mon, 31 May 2004 22:23:14 -0700 (PDT)
	(envelope-from jurij@wooyd.org)
Received: (qmail 1334 invoked from network); 1 Jun 2004 05:20:06 -0000
Received: from d141-170-139.home.cgocable.net (HELO ?192.168.0.101?) (24.141.170.139)
  by stmaarten.globat.com with SMTP; 1 Jun 2004 05:20:06 -0000
Date: Tue, 1 Jun 2004 01:21:33 -0400 (EDT)
From: Jurij Smakov <jurij@wooyd.org>
Reply-To: jurij@wooyd.org
To: linux-mips@linux-mips.org
Subject: Indigo2 Power up for donation 
Message-ID: <Pine.LNX.4.58.0406010051020.9458@bobcat>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <jurij@wooyd.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: 5229
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: jurij@wooyd.org
Precedence: bulk
X-list: linux-mips

Hello,

[Please CC the replies to me, I am not on linux-mips list]

I have recently acquired an Indigo2 machine, which turned out to be the
IP26-based Power version, with 75 MHz R8000 processor. My main interest
was running Linux on it, however it seems like there is currently no
support for that particular machine due to its relative rarity and lack
of documentation. If there is any effort to make Linux run on it, I would
be glad to donate it to one of the linux-mips developers, who could
benefit from owning it, at no cost (modulo possible shipping charges from
Hamilton, Ontario, Canada). Machine has 128MB of RAM, 1GB SCSI hard drive
and is in good working condition.

Jurij Smakov                                        jurij@wooyd.org
Key: http://www.wooyd.org/pgpkey/                   KeyID: C99E03CC

From ralf@linux-mips.org Tue Jun  1 12:45:34 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 01 Jun 2004 12:48:18 +0100 (BST)
Received: from p508B68D7.dip.t-dialin.net ([IPv6:::ffff:80.139.104.215]:14370
	"EHLO mail.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225355AbUFALpe>; Tue, 1 Jun 2004 12:45:34 +0100
Received: from fluff.linux-mips.net (fluff.linux-mips.net [127.0.0.1])
	by mail.linux-mips.net (8.12.11/8.12.8) with ESMTP id i51BjWae025879;
	Tue, 1 Jun 2004 13:45:32 +0200
Received: (from ralf@localhost)
	by fluff.linux-mips.net (8.12.11/8.12.11/Submit) id i51BjVMV025878;
	Tue, 1 Jun 2004 13:45:31 +0200
Date: Tue, 1 Jun 2004 13:45:31 +0200
From: Ralf Baechle <ralf@linux-mips.org>
To: Jurij Smakov <jurij@wooyd.org>
Cc: linux-mips@linux-mips.org
Subject: Re: Indigo2 Power up for donation
Message-ID: <20040601114531.GA9148@linux-mips.org>
References: <Pine.LNX.4.58.0406010051020.9458@bobcat>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Pine.LNX.4.58.0406010051020.9458@bobcat>
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: 5230
X-Approved-By: ralf@linux-mips.org
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips

On Tue, Jun 01, 2004 at 01:21:33AM -0400, Jurij Smakov wrote:

> I have recently acquired an Indigo2 machine, which turned out to be the
> IP26-based Power version, with 75 MHz R8000 processor. My main interest
> was running Linux on it, however it seems like there is currently no
> support for that particular machine due to its relative rarity and lack
> of documentation. If there is any effort to make Linux run on it, I would
> be glad to donate it to one of the linux-mips developers, who could
> benefit from owning it, at no cost (modulo possible shipping charges from
> Hamilton, Ontario, Canada). Machine has 128MB of RAM, 1GB SCSI hard drive
> and is in good working condition.

Jurij,

to raise your optimism - a Polish developper recently managed to get the
the similar but more complex graphics of the Octane to work.  Another
core problem, the lack of freely available documentation for the R8000's
processor was also solved now that finally after solving the underlying
legal problem MIPS was able to give me permission to distribute
documentation for the system.  In short I believe now we have all the
necessary bits and pieces in order to support your Indigo 2 and need to
enter the "just do it" phase ...

  Ralf

From ralf@linux-mips.org Tue Jun  1 13:15:27 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 01 Jun 2004 13:22:48 +0100 (BST)
Received: from p508B68D7.dip.t-dialin.net ([IPv6:::ffff:80.139.104.215]:1572
	"EHLO mail.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225428AbUFAMP1>; Tue, 1 Jun 2004 13:15:27 +0100
Received: from fluff.linux-mips.net (fluff.linux-mips.net [127.0.0.1])
	by mail.linux-mips.net (8.12.11/8.12.8) with ESMTP id i51CFPSZ026555;
	Tue, 1 Jun 2004 14:15:25 +0200
Received: (from ralf@localhost)
	by fluff.linux-mips.net (8.12.11/8.12.11/Submit) id i51CFKY8026554;
	Tue, 1 Jun 2004 14:15:20 +0200
Date: Tue, 1 Jun 2004 14:15:20 +0200
From: Ralf Baechle <ralf@linux-mips.org>
To: Guido Guenther <agx@sigxcpu.org>, linux-mips@linux-mips.org,
	debian-toolchain@lists.debian.org
Subject: Re: TLS register
Message-ID: <20040601121520.GB25718@linux-mips.org>
References: <20040531230524.GB2785@bogon.ms20.nix>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20040531230524.GB2785@bogon.ms20.nix>
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: 5231
X-Approved-By: ralf@linux-mips.org
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips

On Mon, May 31, 2004 at 08:05:24PM -0300, Guido Guenther wrote:

> Hi,
> Now that gcc 3.4 has incompatible ABI changes (on o32 mostly affecting
> mipsel) I've been discussing with Thiemo if I'd be the right point to
> take this ABI change as a possibility to additionally reserve a TLS
> register. 
> He suggested $24 (t8) another discussed possibility would be $27 (k1)
> which is already abused by the PS/2 folks for ll/sc emulation.
> Another possibility would be to reserve such a register only in the
> n32/n64 ABIs and let o32 stay without __thread and TLS forever.

Sigh, we'e been through this really often enough.  Reserving a register
comes at a price so my approach was to implement a fast path in the
exception code.  I've benchmarked that long time ago; it had less than
half the overhead than normal syscall and such a function would be subject
to normal code optimizations so calls should be few only.  Alpha already
does something similar using their PAL code.

  Ralf

From kevink@mips.com Tue Jun  1 13:41:18 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 01 Jun 2004 13:41:23 +0100 (BST)
Received: from ftp.mips.com ([IPv6:::ffff:206.31.31.227]:41132 "EHLO
	mx2.mips.com") by linux-mips.org with ESMTP id <S8225304AbUFAMlS>;
	Tue, 1 Jun 2004 13:41:18 +0100
Received: from mercury.mips.com (ns-dmz [206.31.31.225])
	by mx2.mips.com (8.12.11/8.12.11) with ESMTP id i51CT80Z019069;
	Tue, 1 Jun 2004 05:29:08 -0700 (PDT)
Received: from grendel (grendel [192.168.236.16])
	by mercury.mips.com (8.12.11/8.12.11) with SMTP id i51CevD7020516;
	Tue, 1 Jun 2004 05:41:08 -0700 (PDT)
Message-ID: <047701c447d6$28aa9d60$10eca8c0@grendel>
From: "Kevin D. Kissell" <kevink@mips.com>
To: "Ralf Baechle" <ralf@linux-mips.org>,
	"Guido Guenther" <agx@sigxcpu.org>, <linux-mips@linux-mips.org>,
	<debian-toolchain@lists.debian.org>
References: <20040531230524.GB2785@bogon.ms20.nix> <20040601121520.GB25718@linux-mips.org>
Subject: Re: TLS register
Date: Tue, 1 Jun 2004 14:44:08 +0200
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.1409
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409
X-Scanned-By: MIMEDefang 2.39
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: 5232
X-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

> On Mon, May 31, 2004 at 08:05:24PM -0300, Guido Guenther wrote:
> 
> > Hi,
> > Now that gcc 3.4 has incompatible ABI changes (on o32 mostly affecting
> > mipsel) I've been discussing with Thiemo if I'd be the right point to
> > take this ABI change as a possibility to additionally reserve a TLS
> > register. 
> > He suggested $24 (t8) another discussed possibility would be $27 (k1)
> > which is already abused by the PS/2 folks for ll/sc emulation.
> > Another possibility would be to reserve such a register only in the
> > n32/n64 ABIs and let o32 stay without __thread and TLS forever.
> 
> Sigh, we'e been through this really often enough.  Reserving a register
> comes at a price so my approach was to implement a fast path in the
> exception code.  I've benchmarked that long time ago; it had less than
> half the overhead than normal syscall and such a function would be subject
> to normal code optimizations so calls should be few only.  Alpha already
> does something similar using their PAL code.

The overhead realtive to a normal syscall is much less interesting
to measure than the overhead relative to having the pointer already
in a register - after all, half of a whole lot of instructions is still a whole
lot of instructions.

As some, but perhaps not all of you know, MIPS is working on
multithreaded extensions to the instruction set architecture and
the hardware, which include the ability to create and destroy
parallel threads of executioon without OS intervention in the
"expected" case (and yes, I have thought about how Linux 
could support this, but I'm not gonna go into that here).
In such a framework, it would not be acceptable to do a
system call to get a TLS value.

I don't yet have an opinion as to whether we need to retrofit
things so that user-level multithreading is compatible with o32,
but I would comment that if we go for a TLS register, k1 may 
not be a very good option. The LL/SC emulation trick with k1 
works by virtue of k1 being *destroyed* by exceptions - it doesn't 
change its status as a register reserved for kernel use.

            Regards,

            Kevin K.

From macro@ds2.pg.gda.pl Tue Jun  1 15:28:43 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 01 Jun 2004 15:28:48 +0100 (BST)
Received: from jurand.ds.pg.gda.pl ([IPv6:::ffff:153.19.208.2]:4056 "EHLO
	jurand.ds.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8225326AbUFAO2n>; Tue, 1 Jun 2004 15:28:43 +0100
Received: by jurand.ds.pg.gda.pl (Postfix, from userid 1011)
	id 6A0F0475C5; Tue,  1 Jun 2004 16:28:37 +0200 (CEST)
Received: from localhost (localhost [127.0.0.1])
	by jurand.ds.pg.gda.pl (Postfix) with ESMTP
	id 58970474C5; Tue,  1 Jun 2004 16:28:37 +0200 (CEST)
Date: Tue, 1 Jun 2004 16:28:37 +0200 (CEST)
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To: "Kevin D. Kissell" <kevink@mips.com>
Cc: Ralf Baechle <ralf@linux-mips.org>,
	Guido Guenther <agx@sigxcpu.org>, linux-mips@linux-mips.org,
	debian-toolchain@lists.debian.org
Subject: Re: TLS register
In-Reply-To: <047701c447d6$28aa9d60$10eca8c0@grendel>
Message-ID: <Pine.LNX.4.55.0406011543020.29465@jurand.ds.pg.gda.pl>
References: <20040531230524.GB2785@bogon.ms20.nix> <20040601121520.GB25718@linux-mips.org>
 <047701c447d6$28aa9d60$10eca8c0@grendel>
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: 5233
X-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, 1 Jun 2004, Kevin D. Kissell wrote:

> > > Now that gcc 3.4 has incompatible ABI changes (on o32 mostly affecting
> > > mipsel) I've been discussing with Thiemo if I'd be the right point to
> > > take this ABI change as a possibility to additionally reserve a TLS
> > > register. 
> > > He suggested $24 (t8) another discussed possibility would be $27 (k1)
> > > which is already abused by the PS/2 folks for ll/sc emulation.
> > > Another possibility would be to reserve such a register only in the
> > > n32/n64 ABIs and let o32 stay without __thread and TLS forever.

 For Linux the n32/n64 ABIs can be considered being in the initial stage
of deployment, so backwards compatibility is a non-issue.  Whatever is
found to be the best solution may be accepted.  So the problem of defining
a TLS pointer exists for the o32 ABI only and given the existence of
MIPS32 ISA and its implementations ignoring the issue won't only affect
ancient (but still alive) hardware.

> > Sigh, we'e been through this really often enough.  Reserving a register
> > comes at a price so my approach was to implement a fast path in the
> > exception code.  I've benchmarked that long time ago; it had less than
> > half the overhead than normal syscall and such a function would be subject
> > to normal code optimizations so calls should be few only.  Alpha already
> > does something similar using their PAL code.

 It seems a reasonable balance, IMO.

> The overhead realtive to a normal syscall is much less interesting
> to measure than the overhead relative to having the pointer already
> in a register - after all, half of a whole lot of instructions is still a whole
> lot of instructions.

 The interesting factor is how much software really needs threading.  
AFAIK, the majority does not -- I can count threaded software I know of 
(but not necessarily use) using fingers of one hand.  That does not mean 
there are no niches that make use of that approach extensively -- they 
could see a benefit, but why to penalize the rest?

> As some, but perhaps not all of you know, MIPS is working on
> multithreaded extensions to the instruction set architecture and
> the hardware, which include the ability to create and destroy
> parallel threads of executioon without OS intervention in the
> "expected" case (and yes, I have thought about how Linux 
> could support this, but I'm not gonna go into that here).
> In such a framework, it would not be acceptable to do a
> system call to get a TLS value.

 Well, this is exactly a good counter-argument for having a TLS pointer in
a gp register.  I someone needs the fastest threading possible, then let
them use the right hardware (with the threading ASE) or accept the
inefficiency of hardware that predates the concept of threading.

> I don't yet have an opinion as to whether we need to retrofit
> things so that user-level multithreading is compatible with o32,
> but I would comment that if we go for a TLS register, k1 may 
> not be a very good option. The LL/SC emulation trick with k1 
> works by virtue of k1 being *destroyed* by exceptions - it doesn't 
> change its status as a register reserved for kernel use.

 Actually the trick has never found its way into the mainline, and perhaps
it's best to keep it outside as messing with the k registers is inherently
fragile.  Of course, this applies to a possibility to use one of them for
the TLS, too. ;-)

  Maciej

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

From sskowron@ET.PUT.Poznan.PL Tue Jun  1 16:09:12 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 01 Jun 2004 16:09:16 +0100 (BST)
Received: from europa.et.put.poznan.pl ([IPv6:::ffff:150.254.29.138]:30625
	"EHLO europa.et.put.poznan.pl") by linux-mips.org with ESMTP
	id <S8225326AbUFAPJM>; Tue, 1 Jun 2004 16:09:12 +0100
Received: from europa (europa.et.put.poznan.pl [150.254.29.138])
	by europa.et.put.poznan.pl (8.11.6+Sun/8.11.6) with ESMTP id i51F9Ab29986
	for <linux-mips@linux-mips.org>; Tue, 1 Jun 2004 17:09:10 +0200 (MET DST)
Received: from helios.et.put.poznan.pl ([150.254.29.65])
	by europa.et.put.poznan.pl (MailMonitor for SMTP v1.2.2 ) ;
	Tue, 1 Jun 2004 17:09:09 +0200 (MET DST)
Received: from localhost (sskowron@localhost)
	by helios.et.put.poznan.pl (8.11.6+Sun/8.11.6) with ESMTP id i51F99a27604
	for <linux-mips@linux-mips.org>; Tue, 1 Jun 2004 17:09:09 +0200 (MET DST)
X-Authentication-Warning: helios.et.put.poznan.pl: sskowron owned process doing -bs
Date: Tue, 1 Jun 2004 17:09:09 +0200 (MET DST)
From: Stanislaw Skowronek <sskowron@ET.PUT.Poznan.PL>
To: linux-mips@linux-mips.org
Subject: Re: Indigo2 Power up for donation
Message-ID: <Pine.GSO.4.10.10406011708210.27255-100000@helios.et.put.poznan.pl>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <sskowron@ET.PUT.Poznan.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: 5234
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: sskowron@ET.PUT.Poznan.PL
Precedence: bulk
X-list: linux-mips

To support the R8000, you would have to search for all references to
CKSEG0 and KSEG0. I would recommend my 64-bit patch to begin with, as it
provides support for kernel placed in XKPHYS 64-bit segment. Normal MIPS
kernels will not (AFAIK) run on the R8000. If anyone does this, I would be
interested in the results.

Stanislaw



From ddaney@avtrex.com Tue Jun  1 20:23:17 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 01 Jun 2004 20:23:21 +0100 (BST)
Received: from avtrex.com ([IPv6:::ffff:216.102.217.178]:64274 "EHLO
	avtrex.com") by linux-mips.org with ESMTP id <S8225769AbUFATXR>;
	Tue, 1 Jun 2004 20:23:17 +0100
Received: from avtrex.com ([192.168.0.111] RDNS failed) by avtrex.com with Microsoft SMTPSVC(5.0.2195.6713);
	 Tue, 1 Jun 2004 12:21:54 -0700
Message-ID: <40BCD754.9000803@avtrex.com>
Date: Tue, 01 Jun 2004 12:21:56 -0700
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: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
CC: "Kevin D. Kissell" <kevink@mips.com>,
	Ralf Baechle <ralf@linux-mips.org>,
	Guido Guenther <agx@sigxcpu.org>, linux-mips@linux-mips.org,
	debian-toolchain@lists.debian.org
Subject: Re: TLS register
References: <20040531230524.GB2785@bogon.ms20.nix> <20040601121520.GB25718@linux-mips.org> <047701c447d6$28aa9d60$10eca8c0@grendel> <Pine.LNX.4.55.0406011543020.29465@jurand.ds.pg.gda.pl>
In-Reply-To: <Pine.LNX.4.55.0406011543020.29465@jurand.ds.pg.gda.pl>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 01 Jun 2004 19:21:54.0036 (UTC) FILETIME=[B289B340:01C4480D]
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: 5235
X-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

Maciej W. Rozycki wrote:

>On Tue, 1 Jun 2004, Kevin D. Kissell wrote:
>
>  
>
>>>>Now that gcc 3.4 has incompatible ABI changes (on o32 mostly affecting
>>>>mipsel) I've been discussing with Thiemo if I'd be the right point to
>>>>take this ABI change as a possibility to additionally reserve a TLS
>>>>register. 
>>>>He suggested $24 (t8) another discussed possibility would be $27 (k1)
>>>>which is already abused by the PS/2 folks for ll/sc emulation.
>>>>Another possibility would be to reserve such a register only in the
>>>>n32/n64 ABIs and let o32 stay without __thread and TLS forever.
>>>>        
>>>>
>
> For Linux the n32/n64 ABIs can be considered being in the initial stage
>of deployment, so backwards compatibility is a non-issue.  Whatever is
>found to be the best solution may be accepted.  So the problem of defining
>a TLS pointer exists for the o32 ABI only and given the existence of
>MIPS32 ISA and its implementations ignoring the issue won't only affect
>ancient (but still alive) hardware.
>

There are MIPS32 ISA processors that are used in embedded devices that 
are far from "ancient" as some are only starting to enter the market, 
and are still in production.

For these types of devices it is not so important to maintain backwards 
compatibility with legacy tool chains and/or binary library code.  A new 
ABI very similar to o32 but with a TLS pointer in a register (perhaps 
"o32-tls") might be useful.
.
.
.

> The interesting factor is how much software really needs threading.  
>AFAIK, the majority does not -- I can count threaded software I know of 
>(but not necessarily use) using fingers of one hand.  That does not mean 
>there are no niches that make use of that approach extensively -- they 
>could see a benefit, but why to penalize the rest?
>
>  
>
Almost any non-trivial program written in java could benefit from faster 
TLS.  The java support in GCC-3.4 now allows us to write useful programs 
for MIPS in java.

David Daney.


From maksik@gmx.co.uk Wed Jun  2 07:59:40 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 02 Jun 2004 07:59:44 +0100 (BST)
Received: from skl1.ukl.uni-freiburg.de ([IPv6:::ffff:193.196.199.1]:61593
	"EHLO relay1.uniklinik-freiburg.de") by linux-mips.org with ESMTP
	id <S8225848AbUFBG7k>; Wed, 2 Jun 2004 07:59:40 +0100
Received: from wh85.ukl.uni-freiburg.de (ktl77.ukl.uni-freiburg.de [193.196.226.77])
	by relay1.uniklinik-freiburg.de (Email) with ESMTP
	id 6177E2F341; Wed,  2 Jun 2004 08:59:33 +0200 (CEST)
From: Max Zaitsev <maksik@gmx.co.uk>
Organization: Mutella Dev co.
To: kumba@gentoo.org
Subject: Re: help needed : cannot install linux on SGI O2 R5000
Date: Wed, 2 Jun 2004 08:59:36 +0200
User-Agent: KMail/1.5.3
References: <200405281210.05259.maksik@gmx.co.uk> <40B7ABCE.3070809@gentoo.org>
In-Reply-To: <40B7ABCE.3070809@gentoo.org>
Cc: linux-mips@linux-mips.org
MIME-Version: 1.0
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200406020859.36095.maksik@gmx.co.uk>
Return-Path: <maksik@gmx.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: 5237
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: maksik@gmx.co.uk
Precedence: bulk
X-list: linux-mips
Content-Length: 1106
Lines: 31

Hi Kumba,

thanks for your tips. Actually, I've got some progress (after I've realised 
why your kernels did not work) and found that the kernel from Glaurung 
(http://www.linux-mips.org/~glaurung/) has a framebuffer support and accepts 
the netboot root (initrd image) from your distribution. So I've proceeded 
building stage1 system, but got following errors while compiling GCC:
-----
Bootstrap comparison failure!
insn-recog.o differs
make[1]: *** [compare-lean] Error 1
make[1]: Leaving directory `/var/tmp/portage/gcc-3.3.3-r3/work/build/gcc'
make: *** [bootstrap-lean] Error 2

!!! ERROR: sys-devel/gcc-3.3.3-r3 failed.
!!! Function src_compile, Line 533, Exitcode 2
!!! (no error message)

gentoo-mips-20040426 portage #
-----
I'm not sure if this is the correct list to *complain* though. I'm also 
wondering if this can occur due to the version of kernel that I'm using.

Another question is more related to the gentoo philosophy: is it possible to 
make bootstrap script to only finish things that have not been finished, 
without repeating the whole thing before?

Thanks for your help,
Max



From savl@dev.rtsoft.ru Wed Jun  2 11:06:13 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 02 Jun 2004 11:06:17 +0100 (BST)
Received: from RT-soft-2.Moscow.itn.ru ([IPv6:::ffff:80.240.96.70]:26244 "HELO
	mail.dev.rtsoft.ru") by linux-mips.org with SMTP
	id <S8225852AbUFBKGN>; Wed, 2 Jun 2004 11:06:13 +0100
Received: (qmail 10310 invoked from network); 2 Jun 2004 10:06:06 -0000
Received: from unknown (HELO dev.rtsoft.ru) (192.168.1.199)
  by mail.dev.rtsoft.ru with SMTP; 2 Jun 2004 10:06:06 -0000
Message-ID: <40BDA692.50606@dev.rtsoft.ru>
Date: Wed, 02 Jun 2004 14:06:10 +0400
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: input_event for 64-bit kernel and 32-bit userland.
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: 5238
X-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: 1291
Lines: 34

Hi all,
I stuck in simple situation:
USB mouse (or keyboard). n64 kernel (2.4.20), n32 userland.

Userspace application tries to read "input_event" (16 bytes) from 
"/dev/input/event0" [ read(fd,&key_ev, sizeof(key_ev)) ],
input core driver treats "input_event" as 24 bytes structure. It is due 
to different size of  "timeval" (and finally  "long") in n64 kernel and 
n32 userland.

Application gets some garbage as mouse events . No solutions like "ioctl 
wrappers" applicable in this case.

I don't want to change any arch independent files, but can not find any
acceptable solution. It looks like headers "/usr/include/linux/input.h" 
in root file system and "/include/linux/input.h" in kernel should be the 
same,
 (All works fine as soon as I declare a new "input_event" structure in 
user application that corresponds in size to kernel
structure - but this is not acceptable).

Can anybody advice me what to do with the difference in "input_event"
structure sizes in o32/n32 userland and n64 kernel? Just a general 
approach that can be used when  driver's read/write operation treat some 
values as 64 bit while user application tries to read/write 32-bit 
values (based on the same headers).

Please, don't kick me if solution is simple and obvious.
---
Thanks,
Pavel Kiryukhin.




From jbglaw@dvmwest.gt.owl.de Wed Jun  2 11:55:35 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 02 Jun 2004 11:55:39 +0100 (BST)
Received: from dvmwest.gt.owl.de ([IPv6:::ffff:62.52.24.140]:47573 "EHLO
	dvmwest.gt.owl.de") by linux-mips.org with ESMTP
	id <S8225889AbUFBKzf>; Wed, 2 Jun 2004 11:55:35 +0100
Received: by dvmwest.gt.owl.de (Postfix, from userid 1001)
	id 7199C4B75F; Wed,  2 Jun 2004 12:55:31 +0200 (CEST)
Date: Wed, 2 Jun 2004 12:55:31 +0200
From: Jan-Benedict Glaw <jbglaw@lug-owl.de>
To: linux-mips@linux-mips.org
Subject: Re: input_event for 64-bit kernel and 32-bit userland.
Message-ID: <20040602105531.GN20632@lug-owl.de>
Mail-Followup-To: linux-mips@linux-mips.org
References: <40BDA692.50606@dev.rtsoft.ru>
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="53t+yOlxgLCdk6tE"
Content-Disposition: inline
In-Reply-To: <40BDA692.50606@dev.rtsoft.ru>
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.6i
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: 5240
X-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: 1406
Lines: 45


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

On Wed, 2004-06-02 14:06:10 +0400, Pavel Kiryukhin <savl@dev.rtsoft.ru>
wrote in message <40BDA692.50606@dev.rtsoft.ru>:

> Userspace application tries to read "input_event" (16 bytes) from=20
> "/dev/input/event0" [ read(fd,&key_ev, sizeof(key_ev)) ],
> input core driver treats "input_event" as 24 bytes structure. It is due=
=20
> to different size of  "timeval" (and finally  "long") in n64 kernel and=
=20
> n32 userland.

You'd probably Cc: that to LKML, too. That's an issue for all systems
running 64bit kernel with 32bit userland (eg. Ultra-Sparc, PPC64, IA64,
x86_64, ...).

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));

--53t+yOlxgLCdk6tE
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)

iD8DBQFAvbIjHb1edYOZ4bsRAgg8AJ9gfS4FhKgM9DZAvI4gzPtoQUQUcQCgkmZj
+tsU+2qkwz5z/raIPB22/K0=
=E3jQ
-----END PGP SIGNATURE-----

--53t+yOlxgLCdk6tE--

From manwithastinkydog@yahoo.com Wed Jun  2 13:33:57 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 02 Jun 2004 13:34:02 +0100 (BST)
Received: from web13309.mail.yahoo.com ([IPv6:::ffff:216.136.175.192]:24431
	"HELO web13309.mail.yahoo.com") by linux-mips.org with SMTP
	id <S8225875AbUFBMd5>; Wed, 2 Jun 2004 13:33:57 +0100
Message-ID: <20040602123346.58165.qmail@web13309.mail.yahoo.com>
Received: from [12.33.232.234] by web13309.mail.yahoo.com via HTTP; Wed, 02 Jun 2004 05:33:46 PDT
Date: Wed, 2 Jun 2004 05:33:46 -0700 (PDT)
From: Ken Giusti <manwithastinkydog@yahoo.com>
Subject: cat /proc/iomem crash +patch
To: linux-mips <linux-mips@linux-mips.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Return-Path: <manwithastinkydog@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: 5241
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: manwithastinkydog@yahoo.com
Precedence: bulk
X-list: linux-mips
Content-Length: 2055
Lines: 82

Hi,

I'm running 2.4 on a swarm card with 2Gig of memory.
I've got CONFIG_64BIT_PHYS_ADDR=y configured.  I get
the following memory map during boot:

Determined physical RAM map:
 memory: 0fe82e00 @ 00000000 (usable)
 memory: 1ffffe00 @ 80000000 (usable)
 memory: 0ffffe00 @ c0000000 (usable)
 memory: 3ffffe00 @ 100000000 (usable)

"cat"ing /proc/iomem would cause an oops.   I traced
this to setup.c::resource_init(), which was
incorrectly
truncating the start address of the 0x100000000 memory
entry to fit in a 32 bit ulong.  This would cause
the request_resource call to fail, triggering a bug
which would insert an invalid root node in the iomem
map. 

Here's a patch that works for me:

cvs diff: Diffing .
Index: setup.c
===================================================================
RCS file: /home/cvs/linux/arch/mips/kernel/setup.c,v
retrieving revision 1.168
diff -u -r1.168 setup.c
--- setup.c	8 Feb 2004 14:57:04 -0000	1.168
+++ setup.c	2 Jun 2004 12:24:37 -0000
@@ -382,7 +382,7 @@
 	 */
 	for (i = 0; i < boot_mem_map.nr_map; i++) {
 		struct resource *res;
-		unsigned long start, end;
+		phys_t start, end;
 
 		start = boot_mem_map.map[i].addr;
 		end = boot_mem_map.map[i].addr +
boot_mem_map.map[i].size - 1;
@@ -406,15 +406,16 @@
 		res->end = end;
 
 		res->flags = IORESOURCE_MEM | IORESOURCE_BUSY;
-		request_resource(&iomem_resource, res);
+		if (request_resource(&iomem_resource, res) == 0) {
 
-		/*
-		 *  We don't know which RAM region contains kernel
data,
-		 *  so we try it repeatedly and let the resource
manager
-		 *  test it.
-		 */
-		request_resource(res, &code_resource);
-		request_resource(res, &data_resource);
+			/*
+			 *  We don't know which RAM region contains kernel
data,
+			 *  so we try it repeatedly and let the resource
manager
+			 *  test it.
+			 */
+			request_resource(res, &code_resource);
+			request_resource(res, &data_resource);
+		}
 	}
 }

-K





	
		
__________________________________
Do you Yahoo!?
Friends.  Fun.  Try the all-new Yahoo! Messenger.
http://messenger.yahoo.com/ 

From maksik@gmx.co.uk Wed Jun  2 16:13:03 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 02 Jun 2004 16:13:08 +0100 (BST)
Received: from skl1.ukl.uni-freiburg.de ([IPv6:::ffff:193.196.199.1]:25817
	"EHLO relay1.uniklinik-freiburg.de") by linux-mips.org with ESMTP
	id <S8225934AbUFBPND>; Wed, 2 Jun 2004 16:13:03 +0100
Received: from wh85.ukl.uni-freiburg.de (ktl77.ukl.uni-freiburg.de [193.196.226.77])
	by relay1.uniklinik-freiburg.de (Email) with ESMTP
	id C67022F56A; Wed,  2 Jun 2004 17:12:57 +0200 (CEST)
From: Max Zaitsev <maksik@gmx.co.uk>
Organization: Mutella Dev co.
To: ilya@theIlya.com
Subject: Re: help needed : cannot install linux on SGI O2 R5000
Date: Wed, 2 Jun 2004 17:13:02 +0200
User-Agent: KMail/1.5.3
Cc: linux-mips@linux-mips.org
References: <200405281210.05259.maksik@gmx.co.uk> <200406020859.36095.maksik@gmx.co.uk> <20040602145831.GK6398@gateway.total-knowledge.com>
In-Reply-To: <20040602145831.GK6398@gateway.total-knowledge.com>
MIME-Version: 1.0
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200406021713.02541.maksik@gmx.co.uk>
Return-Path: <maksik@gmx.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: 5242
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: maksik@gmx.co.uk
Precedence: bulk
X-list: linux-mips
Content-Length: 1261
Lines: 29

Hi,

Ok, what I've decided to do is to try to pull the stage3 system and build the 
actual kernel with frame-buffer support while running glaurung's kernel 
(which was the only binary kernel that worked for me). Actually, glaurung's 
kernel is definitely not perfectly stable, I'm experiencing random hangs and 
oops time to time, but I thought it would be good enough for bootstrapping. 
Is it really?

Btw, the neither from Ilya's kernels did not work for me -- the recent one 
boots but hangs on busybox startup. The older ones either do not boot at all 
or crash during bootup. 

So, is there a way out? I did not try yet the binary kernels from Kumba, 
because they are built for a serial console and I don't have a cable so far. 
Honestly, looking for such a cable would be the last thing on my list...

Any advises would be greatly appreciated.

--Max

On Wednesday 02 June 2004 04:58 pm, ilya@theIlya.com wrote:
> Right - this is not correct list to complaint to about Gentoo installation
> problems. As for the problem - chances of getting bootstrap all the
> way to the end on glaurung's kernel are very slim due to broken RTC
> support (which is what bit you). Make gets rather confused, when
> time goes backwards, or in zig-zags and circles ;-)
>


From yuasa@hh.iij4u.or.jp Thu Jun  3 15:13:39 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 03 Jun 2004 15:13:44 +0100 (BST)
Received: from mo03.iij4u.or.jp ([IPv6:::ffff:210.130.0.20]:1014 "EHLO
	mo03.iij4u.or.jp") by linux-mips.org with ESMTP id <S8226285AbUFCONj>;
	Thu, 3 Jun 2004 15:13:39 +0100
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 XAA15470;
	Thu, 3 Jun 2004 23:13:34 +0900 (JST)
Received: 4UMDO00 id i53EDXl16268; Thu, 3 Jun 2004 23:13:34 +0900 (JST)
Received: 4UMRO00 id i53EDX625550; Thu, 3 Jun 2004 23:13:33 +0900 (JST)
	from stratos.frog (64.43.138.210.xn.2iij.net [210.138.43.64]) (authenticated)
Date: Thu, 3 Jun 2004 23:13:31 +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] fix atomic_sub_if_positive() and atomic64_sub_if_positive()
Message-Id: <20040603231331.46ac0070.yuasa@hh.iij4u.or.jp>
X-Mailer: Sylpheed version 0.9.11 (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: 5243
X-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

Hi Ralf,

I found the mistake about return value of atomic_sub_if_positive()  and atomic64_sub_if_positive().

Please apply this patch to v2.6 CVS tree.

Yoichi


diff -urN -X dontdiff linux-orig/include/asm-mips/atomic.h linux/include/asm-mips/atomic.h
--- linux-orig/include/asm-mips/atomic.h	Fri May 28 23:44:14 2004
+++ linux/include/asm-mips/atomic.h	Sun May 30 12:06:20 2004
@@ -228,7 +228,7 @@
 static __inline__ int atomic_sub_if_positive(int i, atomic_t * v)
 {
 	unsigned long flags;
-	int temp, result;
+	int temp;
 
 	spin_lock_irqsave(&atomic_lock, flags);
 	temp = v->counter;
@@ -237,7 +237,7 @@
 		v->counter = temp;
 	spin_unlock_irqrestore(&atomic_lock, flags);
 
-	return result;
+	return temp;
 }
 
 #endif /* CONFIG_CPU_HAS_LLSC */
@@ -511,7 +511,7 @@
 static __inline__ long atomic64_sub_if_positive(long i, atomic64_t * v)
 {
 	unsigned long flags;
-	long temp, result;
+	long temp;
 
 	spin_lock_irqsave(&atomic_lock, flags);
 	temp = v->counter;
@@ -520,7 +520,7 @@
 		v->counter = temp;
 	spin_unlock_irqrestore(&atomic_lock, flags);
 
-	return result;
+	return temp;
 }
 
 #endif /* CONFIG_CPU_HAS_LLDSCD */

From yuasa@hh.iij4u.or.jp Thu Jun  3 15:16:32 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 03 Jun 2004 15:16:37 +0100 (BST)
Received: from mo03.iij4u.or.jp ([IPv6:::ffff:210.130.0.20]:33526 "EHLO
	mo03.iij4u.or.jp") by linux-mips.org with ESMTP id <S8226298AbUFCOQc>;
	Thu, 3 Jun 2004 15:16:32 +0100
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 XAA15948;
	Thu, 3 Jun 2004 23:16:29 +0900 (JST)
Received: 4UMDO00 id i53EGTl16288; Thu, 3 Jun 2004 23:16:29 +0900 (JST)
Received: 4UMRO00 id i53EGS625840; Thu, 3 Jun 2004 23:16:29 +0900 (JST)
	from stratos.frog (64.43.138.210.xn.2iij.net [210.138.43.64]) (authenticated)
Date: Thu, 3 Jun 2004 23:16:27 +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]  fix vrc4173 base driver
Message-Id: <20040603231627.28e332cd.yuasa@hh.iij4u.or.jp>
X-Mailer: Sylpheed version 0.9.11 (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: 5244
X-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

Hi Ralf,

I found my mistake about vrc4173 base driver.

Please apply this patch to v2.6 CVS tree.

Yoichi

diff -urN -X dontdiff linux-orig/arch/mips/vr41xx/common/vrc4173.c linux/arch/mips/vr41xx/common/vrc4173.c
--- linux-orig/arch/mips/vr41xx/common/vrc4173.c	Thu May 27 08:14:29 2004
+++ linux/arch/mips/vr41xx/common/vrc4173.c	Mon May 31 00:51:02 2004
@@ -461,7 +461,7 @@
 	.name		= "NEC VRC4173",
 	.probe		= vrc4173_probe,
 	.remove		= vrc4173_remove,
-	.id_table	= vrc4173_table,
+	.id_table	= vrc4173_id_table,
 };
 
 static int __devinit vrc4173_init(void)
diff -urN -X dontdiff linux-orig/include/asm-mips/vr41xx/vrc4173.h linux/include/asm-mips/vr41xx/vrc4173.h
--- linux-orig/include/asm-mips/vr41xx/vrc4173.h	Thu May 27 08:14:44 2004
+++ linux/include/asm-mips/vr41xx/vrc4173.h	Mon May 31 00:50:13 2004
@@ -77,7 +77,7 @@
 /*
  * Clock Mask Unit
  */
-enum vrc4173_clock {
+typedef enum vrc4173_clock {
 	VRC4173_PIU_CLOCK,
 	VRC4173_KIU_CLOCK,
 	VRC4173_AIU_CLOCK,
@@ -98,7 +98,7 @@
 /*
  * General-Purpose I/O Unit
  */
-enum vrc4173_function {
+typedef enum vrc4173_function {
 	PS2_CHANNEL1,
 	PS2_CHANNEL2,
 	TOUCHPANEL,

From ralf@linux-mips.org Thu Jun  3 15:22:07 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 03 Jun 2004 15:22:55 +0100 (BST)
Received: from p508B7B0E.dip.t-dialin.net ([IPv6:::ffff:80.139.123.14]:37683
	"EHLO mail.linux-mips.net") by linux-mips.org with ESMTP
	id <S8226320AbUFCOWF>; Thu, 3 Jun 2004 15:22:05 +0100
Received: from fluff.linux-mips.net (fluff.linux-mips.net [127.0.0.1])
	by mail.linux-mips.net (8.12.11/8.12.8) with ESMTP id i53ELxiZ021202;
	Thu, 3 Jun 2004 16:22:00 +0200
Received: (from ralf@localhost)
	by fluff.linux-mips.net (8.12.11/8.12.11/Submit) id i53ELwO6021201;
	Thu, 3 Jun 2004 16:21:58 +0200
Date: Thu, 3 Jun 2004 16:21:58 +0200
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] fix atomic_sub_if_positive() and atomic64_sub_if_positive()
Message-ID: <20040603142158.GA21089@linux-mips.org>
References: <20040603231331.46ac0070.yuasa@hh.iij4u.or.jp>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20040603231331.46ac0070.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: 5245
X-Approved-By: ralf@linux-mips.org
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips

On Thu, Jun 03, 2004 at 11:13:31PM +0900, Yoichi Yuasa wrote:

> I found the mistake about return value of atomic_sub_if_positive() 
> and atomic64_sub_if_positive().

Applied,

  Ralf

From nayak_27@yahoo.com Thu Jun  3 15:32:00 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 03 Jun 2004 15:32:05 +0100 (BST)
Received: from web60703.mail.yahoo.com ([IPv6:::ffff:216.109.117.226]:56983
	"HELO web60703.mail.yahoo.com") by linux-mips.org with SMTP
	id <S8226341AbUFCOcA>; Thu, 3 Jun 2004 15:32:00 +0100
Message-ID: <20040603143153.42483.qmail@web60703.mail.yahoo.com>
Received: from [164.164.94.19] by web60703.mail.yahoo.com via HTTP; Thu, 03 Jun 2004 15:31:53 BST
Date: Thu, 3 Jun 2004 15:31:53 +0100 (BST)
From: =?iso-8859-1?q?Sujith=20Nayak?= <nayak_27@yahoo.com>
Subject: shared mem problem
To: linux-mips@linux-mips.org
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Return-Path: <nayak_27@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: 5246
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: nayak_27@yahoo.com
Precedence: bulk
X-list: linux-mips

Hi,
I am currently working on a board powered by a MIPS
processor, using Linux kernel 2.4.2. The problem that
I am facing is, whenever I create a shared memory
using shmget(), shmat(), etc. APIs, I always see that
the shared mem is created with 0 bytes. As a result
any access to it bombs the process.

Anyone has any idea, I will be grateful for your
response. I had a look at the patch-2.4.2-ac23, which
talks about the some shared mem lock up problem. But I
cannot apply the patch as it is because my customer
has pruned the kernel so much that the patch does not
apply right away.

Pl. help (by CCing your response to my mail id also).

Regards,

Sujeet


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

From jbglaw@dvmwest.gt.owl.de Thu Jun  3 21:30:08 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 03 Jun 2004 21:30:13 +0100 (BST)
Received: from dvmwest.gt.owl.de ([IPv6:::ffff:62.52.24.140]:902 "EHLO
	dvmwest.gt.owl.de") by linux-mips.org with ESMTP
	id <S8225985AbUFCUaI>; Thu, 3 Jun 2004 21:30:08 +0100
Received: by dvmwest.gt.owl.de (Postfix, from userid 1001)
	id 15F164B7A9; Thu,  3 Jun 2004 22:30:07 +0200 (CEST)
Date: Thu, 3 Jun 2004 22:30:07 +0200
From: Jan-Benedict Glaw <jbglaw@lug-owl.de>
To: linux-mips@linux-mips.org
Subject: Re: shared mem problem
Message-ID: <20040603203006.GZ20632@lug-owl.de>
Mail-Followup-To: linux-mips@linux-mips.org
References: <20040603143153.42483.qmail@web60703.mail.yahoo.com>
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="1ObBTuCXcSRzA7u8"
Content-Disposition: inline
In-Reply-To: <20040603143153.42483.qmail@web60703.mail.yahoo.com>
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.6i
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: 5247
X-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


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

On Thu, 2004-06-03 15:31:53 +0100, Sujith Nayak <nayak_27@yahoo.com>
wrote in message <20040603143153.42483.qmail@web60703.mail.yahoo.com>:
> Hi,
> I am currently working on a board powered by a MIPS
> processor, using Linux kernel 2.4.2. The problem that

Before doing anything else, you'd consider moving forward to current
2.4.x or even 2.6.x...

> I am facing is, whenever I create a shared memory
> using shmget(), shmat(), etc. APIs, I always see that
> the shared mem is created with 0 bytes. As a result
> any access to it bombs the process.
>=20
> Anyone has any idea, I will be grateful for your
> response. I had a look at the patch-2.4.2-ac23, which
> talks about the some shared mem lock up problem. But I
> cannot apply the patch as it is because my customer
> has pruned the kernel so much that the patch does not
> apply right away.

Then talk your customer (isn't that actually your vendor?) into putting
work into a newer kernel. Maybe you can diff you their changes agains a
2.4.2 from either linux-mips.org or 2.4.2 from Linus and try to
forward-port the changes to current 2.4.x or 2.6.x ...

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));

--1ObBTuCXcSRzA7u8
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)

iD8DBQFAv4pOHb1edYOZ4bsRAt6pAJ92cvp2Uekv8WLB/pNwGWXrO+xenwCfc2Ug
Qp1T7DNkT6b8KgZwz3ShOiM=
=+VFP
-----END PGP SIGNATURE-----

--1ObBTuCXcSRzA7u8--

From ralf@linux-mips.org Fri Jun  4 01:50:03 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 04 Jun 2004 01:52:55 +0100 (BST)
Received: from p508B7B0E.dip.t-dialin.net ([IPv6:::ffff:80.139.123.14]:6202
	"EHLO mail.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225997AbUFDAuD>; Fri, 4 Jun 2004 01:50:03 +0100
Received: from fluff.linux-mips.net (fluff.linux-mips.net [127.0.0.1])
	by mail.linux-mips.net (8.12.11/8.12.8) with ESMTP id i540o1NX001785;
	Fri, 4 Jun 2004 02:50:01 +0200
Received: (from ralf@localhost)
	by fluff.linux-mips.net (8.12.11/8.12.11/Submit) id i540o11M001784;
	Fri, 4 Jun 2004 02:50:01 +0200
Date: Fri, 4 Jun 2004 02:50:01 +0200
From: Ralf Baechle <ralf@linux-mips.org>
To: Sujith Nayak <nayak_27@yahoo.com>
Cc: linux-mips@linux-mips.org
Subject: Re: shared mem problem
Message-ID: <20040604005001.GA21250@linux-mips.org>
References: <20040603143153.42483.qmail@web60703.mail.yahoo.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20040603143153.42483.qmail@web60703.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: 5248
X-Approved-By: ralf@linux-mips.org
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ralf@linux-mips.org
Precedence: bulk
X-list: linux-mips

On Thu, Jun 03, 2004 at 03:31:53PM +0100, Sujith Nayak wrote:

> I am currently working on a board powered by a MIPS
> processor, using Linux kernel 2.4.2. The problem that
> I am facing is, whenever I create a shared memory
> using shmget(), shmat(), etc. APIs, I always see that
> the shared mem is created with 0 bytes. As a result
> any access to it bombs the process.
> 
> Anyone has any idea, I will be grateful for your
> response. I had a look at the patch-2.4.2-ac23, which
> talks about the some shared mem lock up problem. But I
> cannot apply the patch as it is because my customer
> has pruned the kernel so much that the patch does not
> apply right away.

This doesn't look like the fingerprint of any known problem.  Anyway,
discussing 2.4.2 bugs is pointless - you're missing over three years
worth of bugfixes.

  Ralf

From toch@dfpost.ru Fri Jun  4 08:49:28 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 04 Jun 2004 08:49:33 +0100 (BST)
Received: from dfpost.ru ([IPv6:::ffff:194.85.103.225]:6629 "EHLO
	mail.postwin.ru") by linux-mips.org with ESMTP id <S8225463AbUFDHt2>;
	Fri, 4 Jun 2004 08:49:28 +0100
Received: by mail.postwin.ru (Postfix, from userid 7896)
	id 36BA0844F8; Fri,  4 Jun 2004 11:48:17 +0400 (MSD)
Received: from dfpost.ru (unknown [192.168.9.4])
	by mail.postwin.ru (Postfix) with ESMTP id 1B2F5844F5
	for <linux-mips@linux-mips.org>; Fri,  4 Jun 2004 11:48:17 +0400 (MSD)
Message-ID: <40C029F5.3040506@dfpost.ru>
Date: Fri, 04 Jun 2004 11:51:17 +0400
From: Dmitriy Tochansky <toch@dfpost.ru>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7b) Gecko/20040421
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: linux-mips@linux-mips.org
Subject: bootloader
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Return-Path: <toch@dfpost.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: 5249
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: toch@dfpost.ru
Precedence: bulk
X-list: linux-mips

Hi!
Does anybody can advice me some bootloader for my Zinfandel(Db1500) board?

CU.

From tk@mycable.de Fri Jun  4 08:55:02 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 04 Jun 2004 08:55:06 +0100 (BST)
Received: from mail.oricom.de ([IPv6:::ffff:62.116.167.249]:50873 "EHLO
	oricom4.internetx.de") by linux-mips.org with ESMTP
	id <S8225472AbUFDHzC>; Fri, 4 Jun 2004 08:55:02 +0100
Received: from mycable.de (d003054.adsl.hansenet.de [80.171.3.54])
	(authenticated bits=0)
	by oricom4.internetx.de (8.12.8/8.12.8) with ESMTP id i547q5Kd025640;
	Fri, 4 Jun 2004 09:52:06 +0200
Message-ID: <40C02A6A.2040400@mycable.de>
Date: Fri, 04 Jun 2004 09:53:14 +0200
From: "Tiemo Krueger - mycable.de" <tk@mycable.de>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040421
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Dmitriy Tochansky <toch@dfpost.ru>
CC: linux-mips@linux-mips.org
Subject: Re: bootloader
References: <40C029F5.3040506@dfpost.ru>
In-Reply-To: <40C029F5.3040506@dfpost.ru>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Return-Path: <tk@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: 5250
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: tk@mycable.de
Precedence: bulk
X-list: linux-mips

Yamon should be in Flash of that board and start automatically...
If it doesn't start check the DIP Switches on the board for correct 
settings.
(little/big endian, and I think you can switch between the flashes)


Tiemo

Dmitriy Tochansky wrote:

> Hi!
> Does anybody can advice me some bootloader for my Zinfandel(Db1500) 
> board?
>
> CU.
>
>


From toch@dfpost.ru Fri Jun  4 09:07:16 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 04 Jun 2004 09:07:20 +0100 (BST)
Received: from dfpost.ru ([IPv6:::ffff:194.85.103.225]:61158 "EHLO
	mail.postwin.ru") by linux-mips.org with ESMTP id <S8225471AbUFDIHQ>;
	Fri, 4 Jun 2004 09:07:16 +0100
Received: by mail.postwin.ru (Postfix, from userid 7896)
	id B6105844F8; Fri,  4 Jun 2004 12:06:05 +0400 (MSD)
Received: from dfpost.ru (unknown [192.168.9.4])
	by mail.postwin.ru (Postfix) with ESMTP
	id 99EF2844F5; Fri,  4 Jun 2004 12:06:05 +0400 (MSD)
Message-ID: <40C02E21.8060009@dfpost.ru>
Date: Fri, 04 Jun 2004 12:09:05 +0400
From: Dmitriy Tochansky <toch@dfpost.ru>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7b) Gecko/20040421
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Tiemo Krueger - mycable.de" <tk@mycable.de>
Cc: linux-mips@linux-mips.org
Subject: Re: bootloader
References: <40C029F5.3040506@dfpost.ru> <40C02A6A.2040400@mycable.de>
In-Reply-To: <40C02A6A.2040400@mycable.de>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Return-Path: <toch@dfpost.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: 5251
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: toch@dfpost.ru
Precedence: bulk
X-list: linux-mips

Tiemo Krueger - mycable.de wrote:

> Yamon should be in Flash of that board and start automatically...
> If it doesn't start check the DIP Switches on the board for correct 
> settings.
> (little/big endian, and I think you can switch between the flashes)
>
>
> Tiemo
>
> Dmitriy Tochansky wrote:
> Does anybody can advice me some bootloader for my Zinfandel(Db1500) 
> board?
>
Oops! Sorry. :) I mean another bootloader insted YAMON. I need to load 
kernel from flash but not from LAN(tftp and etc). Can YAMON to do that?

CU

From tk@mycable.de Fri Jun  4 09:19:32 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 04 Jun 2004 09:19:36 +0100 (BST)
Received: from mail.oricom.de ([IPv6:::ffff:62.116.167.249]:58298 "EHLO
	oricom4.internetx.de") by linux-mips.org with ESMTP
	id <S8225471AbUFDITc>; Fri, 4 Jun 2004 09:19:32 +0100
Received: from mycable.de (d003054.adsl.hansenet.de [80.171.3.54])
	(authenticated bits=0)
	by oricom4.internetx.de (8.12.8/8.12.8) with ESMTP id i548GaKd026500;
	Fri, 4 Jun 2004 10:16:36 +0200
Message-ID: <40C03028.9090705@mycable.de>
Date: Fri, 04 Jun 2004 10:17:44 +0200
From: "Tiemo Krueger - mycable.de" <tk@mycable.de>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040421
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Dmitriy Tochansky <toch@dfpost.ru>
CC: linux-mips@linux-mips.org
Subject: Re: bootloader
References: <40C029F5.3040506@dfpost.ru> <40C02A6A.2040400@mycable.de> <40C02E21.8060009@dfpost.ru>
In-Reply-To: <40C02E21.8060009@dfpost.ru>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Return-Path: <tk@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: 5252
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: tk@mycable.de
Precedence: bulk
X-list: linux-mips

Yes, it can!
There are two options, use a kernel simply compiled for ram,
load it via tftp, cp it to an erased flashed area.
then you can start it by copying it to ram and jump to the start address 
inside the kernel.
the second more simple solution is to build a compressed kernel,
flash it e.g. to 0xbfd00000 and then simply go there for start.

Pls refer the Yamon help for any details, you can add a start variable 
to the Yamon
config which is executed after two seconds if you don't stop this with 
Ctrl-c via serial.

(set start 'go 0xbfd00000 root=/dev/mtdblock1' or whatever...)

Tiemo


Dmitriy Tochansky wrote:

> Tiemo Krueger - mycable.de wrote:
>
>> Yamon should be in Flash of that board and start automatically...
>> If it doesn't start check the DIP Switches on the board for correct 
>> settings.
>> (little/big endian, and I think you can switch between the flashes)
>>
>>
>> Tiemo
>>
>> Dmitriy Tochansky wrote:
>> Does anybody can advice me some bootloader for my Zinfandel(Db1500) 
>> board?
>>
> Oops! Sorry. :) I mean another bootloader insted YAMON. I need to load 
> kernel from flash but not from LAN(tftp and etc). Can YAMON to do that?
>
> CU
>
>


From toch@dfpost.ru Fri Jun  4 09:30:25 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 04 Jun 2004 09:30:30 +0100 (BST)
Received: from dfpost.ru ([IPv6:::ffff:194.85.103.225]:10472 "EHLO
	mail.postwin.ru") by linux-mips.org with ESMTP id <S8225471AbUFDIaZ>;
	Fri, 4 Jun 2004 09:30:25 +0100
Received: by mail.postwin.ru (Postfix, from userid 7896)
	id 093CD844F8; Fri,  4 Jun 2004 12:29:15 +0400 (MSD)
Received: from dfpost.ru (unknown [192.168.9.4])
	by mail.postwin.ru (Postfix) with ESMTP
	id E09DD844F5; Fri,  4 Jun 2004 12:29:14 +0400 (MSD)
Message-ID: <40C0338F.2050408@dfpost.ru>
Date: Fri, 04 Jun 2004 12:32:15 +0400
From: Dmitriy Tochansky <toch@dfpost.ru>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7b) Gecko/20040421
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Tiemo Krueger - mycable.de" <tk@mycable.de>
Cc: linux-mips@linux-mips.org
Subject: Re: bootloader
References: <40C029F5.3040506@dfpost.ru> <40C02A6A.2040400@mycable.de> <40C02E21.8060009@dfpost.ru> <40C03028.9090705@mycable.de>
In-Reply-To: <40C03028.9090705@mycable.de>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Return-Path: <toch@dfpost.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: 5253
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: toch@dfpost.ru
Precedence: bulk
X-list: linux-mips

Tiemo Krueger - mycable.de wrote:

> Yes, it can!
> There are two options, use a kernel simply compiled for ram,
> load it via tftp, cp it to an erased flashed area.
> then you can start it by copying it to ram and jump to the start 
> address inside the kernel.
> the second more simple solution is to build a compressed kernel,
> flash it e.g. to 0xbfd00000 and then simply go there for start.
>
> Pls refer the Yamon help for any details, you can add a start variable 
> to the Yamon
> config which is executed after two seconds if you don't stop this with 
> Ctrl-c via serial.
>
> (set start 'go 0xbfd00000 root=/dev/mtdblock1' or whatever...)
>
Yes I did it that way. :) Thanks.
So is there other nice loaders for this board?

CU

From wd@denx.de Fri Jun  4 09:32:34 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 04 Jun 2004 09:32:40 +0100 (BST)
Received: from mailout09.sul.t-online.com ([IPv6:::ffff:194.25.134.84]:12466
	"EHLO mailout09.sul.t-online.com") by linux-mips.org with ESMTP
	id <S8225477AbUFDIce>; Fri, 4 Jun 2004 09:32:34 +0100
Received: from fwd09.aul.t-online.de 
	by mailout09.sul.t-online.com with smtp 
	id 1BWA7m-000578-00; Fri, 04 Jun 2004 10:32:26 +0200
Received: from denx.de (rCFKYTZdge6sIWMWtT332Q7eFyAdCMuelMj3vAUUc3ZzMwi+K+iao+@[84.128.36.193]) by fmrl09.sul.t-online.com
	with esmtp id 1BWA7T-0Pg9Am0; Fri, 4 Jun 2004 10:32:07 +0200
Received: from atlas.denx.de (atlas.denx.de [10.0.0.14])
	by denx.de (Postfix) with ESMTP
	id A7B2A428C2; Fri,  4 Jun 2004 10:32:03 +0200 (MEST)
Received: by atlas.denx.de (Postfix, from userid 15)
	id 10811C109F; Fri,  4 Jun 2004 10:32:01 +0200 (MEST)
Received: from atlas.denx.de (localhost [127.0.0.1])
	by atlas.denx.de (Postfix) with ESMTP
	id 0D9AF13D6D0; Fri,  4 Jun 2004 10:32:01 +0200 (MEST)
To: Dmitriy Tochansky <toch@dfpost.ru>
Cc: linux-mips@linux-mips.org
From: Wolfgang Denk <wd@denx.de>
Subject: Re: bootloader 
X-Mailer: exmh version 1.6.4 10/10/1995
Mime-version: 1.0
Content-type: text/plain; charset=ISO-8859-1
Content-transfer-encoding: 8bit
In-reply-to: Your message of "Fri, 04 Jun 2004 11:51:17 +0400."
             <40C029F5.3040506@dfpost.ru> 
Date: Fri, 04 Jun 2004 10:31:56 +0200
Message-Id: <20040604083201.10811C109F@atlas.denx.de>
X-Seen: false
X-ID: rCFKYTZdge6sIWMWtT332Q7eFyAdCMuelMj3vAUUc3ZzMwi+K+iao+@t-dialin.net
Return-Path: <wd@denx.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: 5254
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: wd@denx.de
Precedence: bulk
X-list: linux-mips

In message <40C029F5.3040506@dfpost.ru> you wrote:
>
> Does anybody can advice me some bootloader for my Zinfandel(Db1500) board?

U-Boot?

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
Men don't talk peace unless they're ready to back it up with war.
	-- Col. Green, "The Savage Curtain", stardate 5906.4

From eokerson@texasconnect.net Fri Jun  4 16:39:36 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 04 Jun 2004 16:39:40 +0100 (BST)
Received: from dallas.texasconnect.net ([IPv6:::ffff:208.232.232.3]:32267 "EHLO
	dallas.texasconnect.net") by linux-mips.org with ESMTP
	id <S8225742AbUFDPjg>; Fri, 4 Jun 2004 16:39:36 +0100
Received: from dallas.texasconnect.net (dallas.texasconnect.net [208.232.232.3])
	by dallas.texasconnect.net (8.12.9/8.12.9) with ESMTP id i54FdVXC010999;
	Fri, 4 Jun 2004 10:39:31 -0500
Date: Fri, 4 Jun 2004 10:39:31 -0500 (CDT)
From: Ed Okerson <eokerson@texasconnect.net>
To: Dmitriy Tochansky <toch@dfpost.ru>
cc: linux-mips@linux-mips.org
Subject: Re: bootloader
In-Reply-To: <40C029F5.3040506@dfpost.ru>
Message-ID: <Pine.LNX.4.44.0406041038590.15478-100000@dallas.texasconnect.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <eokerson@texasconnect.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: 5255
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: eokerson@texasconnect.net
Precedence: bulk
X-list: linux-mips

I have the same board and I use U-Boot.

Ed

On Fri, 4 Jun 2004, Dmitriy Tochansky wrote:

> Hi!
> Does anybody can advice me some bootloader for my Zinfandel(Db1500) board?
>
> CU.
>


From tri.vukhac@sonycom.com Sat Jun  5 09:23:36 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 05 Jun 2004 09:23:40 +0100 (BST)
Received: from witte.sonytel.be ([IPv6:::ffff:80.88.33.193]:30879 "EHLO
	witte.sonytel.be") by linux-mips.org with ESMTP id <S8225763AbUFEIXg>;
	Sat, 5 Jun 2004 09:23:36 +0100
Received: from CAHOW (localhost [127.0.0.1])
	by witte.sonytel.be (8.12.10/8.12.10) with SMTP id i558MxXJ020080
	for <linux-mips@linux-mips.org>; Sat, 5 Jun 2004 10:23:25 +0200 (MEST)
Message-ID: <00a501c44ad6$2ffb4670$f304308a@CAHOW>
From: "VU Khac Tri \(Sony\)" <tri.vukhac@sonycom.com>
To: <linux-mips@linux-mips.org>
Subject: pcmcia on MIPS
Date: Sat, 5 Jun 2004 10:20:56 +0200
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.1409
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409
Return-Path: <tri.vukhac@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: 5256
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: tri.vukhac@sonycom.com
Precedence: bulk
X-list: linux-mips

Hi,
I am trying running pcmcia on mips and got some problem of memory mapping.
On mips, the memory windows start at the physical addresses that are higher
than 0x10000000. However, in the pcmcia code, i82365.c, I found that the
start address must be in the interval 0x000000-0xFFFFFF.
Does this mean that the linux pcmcia stack does not work on mips? What is
the correct sys_start value?
Kind regards,
Tri

=========
PCMCIA 3.2.7, i82365.c, i365_set_mem_map():

    if ((map > 4) || (mem->card_start > 0x3ffffff) ||
        (mem->sys_start > mem->sys_stop) || (mem->speed > 1000))
        return -EINVAL;
    if (!(s->flags & (IS_PCI|IS_CARDBUS)) &&
        ((mem->sys_start > 0xffffff) || (mem->sys_stop > 0xffffff)))
        return -EINVAL;









From kasyanov_ri@mail.ru Mon Jun  7 10:37:16 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 07 Jun 2004 10:37:21 +0100 (BST)
Received: from f16.mail.ru ([IPv6:::ffff:194.67.57.46]:4104 "EHLO f16.mail.ru")
	by linux-mips.org with ESMTP id <S8225533AbUFGJhQ>;
	Mon, 7 Jun 2004 10:37:16 +0100
Received: from mail by f16.mail.ru with local 
	id 1BXGZ7-000HT0-00
	for linux-mips@linux-mips.org; Mon, 07 Jun 2004 13:37:13 +0400
Received: from [80.240.102.213] by msg.mail.ru with HTTP;
	Mon, 07 Jun 2004 13:37:13 +0400
From: =?koi8-r?Q?=22?=romio kasyanov=?koi8-r?Q?=22=20?= 
	<kasyanov_ri@mail.ru>
To: linux-mips@linux-mips.org
Mime-Version: 1.0
X-Mailer: mPOP Web-Mail 2.19
X-Originating-IP: [80.240.102.213]
Date: Mon, 07 Jun 2004 13:37:13 +0400
Reply-To: =?koi8-r?Q?=22?=romio kasyanov=?koi8-r?Q?=22=20?= 
	  <kasyanov_ri@mail.ru>
Content-Type: text/plain; charset=koi8-r
Content-Transfer-Encoding: 8bit
Message-Id: <E1BXGZ7-000HT0-00.kasyanov_ri-mail-ru@f16.mail.ru>
Return-Path: <kasyanov_ri@mail.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: 5257
Subject: (no subject)
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: kasyanov_ri@mail.ru
Precedence: bulk
X-list: linux-mips

Hello!
Trying to port linux kernel 2_4_25 on dbaux1550.
This is my dump.Don't know from what to start.Please help.

CPU revision is: 03030200
Primary instruction cache 16kB, physically tagged, 4-way, linesize 32 bytes.
Primary data cache 16kB 4-way, linesize 32 bytes.
Linux version 2.4.25 (roman@storm) (gcc version 3.3.2) #6 Mon Jun 7 12:56:39 MS4
AMD Alchemy Au1550/Db1550 Board
Au1550 AA (PRId 03030200) @ 396MHZ
BCLK switching enabled!
Determined physical RAM map:
 memory: 0c000000 @ 00000000 (usable)
On node 0 totalpages: 49152
zone(0): 49152 pages.
zone(1): 0 pages.
zone(2): 0 pages.
Kernel command line:  console=ttyS0,115200 usb_ohci=base:0x14020000,len:0x100006
calculating r4koff... 003c6cc0(3960000)
CPU frequency 396.00 MHz
Console: colour dummy device 80x25
Calibrating delay loop... 395.67 BogoMIPS
Memory: 191136k/196608k available (1873k kernel code, 5472k reserved, 120k data)
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
Autoconfig PCI channel 0x80313938
Scanning bus 00, I/O 0x00000300:0x00100000, Mem 0x40000000:0x50000000
00:0b.0 Class 0002: 0007:0000 (rev 01)
        I/O at 0x00000300 [size=0x8]
        I/O at 0x00000308 [size=0x4]
        I/O at 0x00000310 [size=0x8]
        I/O at 0x00000318 [size=0x4]
        I/O at 0x00000400 [size=0x100]
remap_area_pte: page already exists
Break instruction in kernel code in traps.c::do_bp, line 591:
$0 : 00000000 1000fc00 00000024 00000000 80302818 00000001 00000001 80302830
$8 : 00000001 000006b2 0000068b 000006b2 80320000 80320000 80320000 ba2e8ba3
$16: 00000000 00103000 8034b018 00003000 00000005 00000000 000007d7 00000017
$24: ba2e8ba3 00000001                   8121a000 8121be78 00003000 80109b28
Hi : fffff61f
Lo : 0000034b
epc   : 80109b28    Not tainted
Status: 1000fc03
Cause : 00800024
PrId  : 03030200
Process swapper (pid: 1, stackpage=8121a000)
Stack:    00000000 00000000 bb77fd8c bb77fd8c bb77fd8d 00000000 00000000
 00000000 00000000 00000000 fffffff4 802f8800 c0103000 802f8800 00000004
 ffffd000 00000000 00103000 001fffff 00000001 00000000 00100000 00000005
 00000000 c0003000 00000000 00000010 00000000 8008c6b4 80109cac c0003000
 00000000 00000004 3fffd000 00000000 00100000 00000010 00000000 80340000
 80310000 ...
Call Trace:   [<80109cac>] [<801007b0>] [<801007b0>] [<80101e00>] [<80101da0>]
 [<80200118>] [<8015fad0>] [<801007b0>] [<801007c0>] [<80102188>] [<8010fb30>]
 [<801603b8>] [<80160394>] [<80102178>]

Code:
Kernel panic: Attempted to kill init!

From toch@dfpost.ru Mon Jun  7 12:29:26 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 07 Jun 2004 12:29:30 +0100 (BST)
Received: from dfpost.ru ([IPv6:::ffff:194.85.103.225]:46802 "EHLO
	mail.postwin.ru") by linux-mips.org with ESMTP id <S8225236AbUFGL30>;
	Mon, 7 Jun 2004 12:29:26 +0100
Received: by mail.postwin.ru (Postfix, from userid 7896)
	id EEB7B844F8; Mon,  7 Jun 2004 15:28:06 +0400 (MSD)
Received: from dfpost.ru (unknown [192.168.9.4])
	by mail.postwin.ru (Postfix) with ESMTP
	id DC227844F5; Mon,  7 Jun 2004 15:28:06 +0400 (MSD)
Message-ID: <40C4520B.2020400@dfpost.ru>
Date: Mon, 07 Jun 2004 15:31:23 +0400
From: Dmitriy Tochansky <toch@dfpost.ru>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7b) Gecko/20040421
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Ed Okerson <eokerson@texasconnect.net>
Cc: linux-mips@linux-mips.org
Subject: Re: bootloader
References: <Pine.LNX.4.44.0406041038590.15478-100000@dallas.texasconnect.net>
In-Reply-To: <Pine.LNX.4.44.0406041038590.15478-100000@dallas.texasconnect.net>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Return-Path: <toch@dfpost.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: 5258
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: toch@dfpost.ru
Precedence: bulk
X-list: linux-mips

Ed Okerson wrote:

>I have the same board and I use U-Boot.
>  
>
>>Hi!
>>Does anybody can advice me some bootloader for my Zinfandel(Db1500) board?
>>
>>CU.
>>    
>>
Had you any problems in compile it?


From eokerson@texasconnect.net Mon Jun  7 18:44:57 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 07 Jun 2004 18:45:01 +0100 (BST)
Received: from dallas.texasconnect.net ([IPv6:::ffff:208.232.232.3]:3593 "EHLO
	dallas.texasconnect.net") by linux-mips.org with ESMTP
	id <S8225229AbUFGRo5>; Mon, 7 Jun 2004 18:44:57 +0100
Received: from dallas.texasconnect.net (dallas.texasconnect.net [208.232.232.3])
	by dallas.texasconnect.net (8.12.9/8.12.9) with ESMTP id i57HimXC031501;
	Mon, 7 Jun 2004 12:44:48 -0500
Date: Mon, 7 Jun 2004 12:44:48 -0500 (CDT)
From: Ed Okerson <eokerson@texasconnect.net>
To: Dmitriy Tochansky <toch@dfpost.ru>
cc: linux-mips@linux-mips.org
Subject: Re: bootloader
In-Reply-To: <40C4520B.2020400@dfpost.ru>
Message-ID: <Pine.LNX.4.44.0406071243340.15478-100000@dallas.texasconnect.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <eokerson@texasconnect.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: 5259
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: eokerson@texasconnect.net
Precedence: bulk
X-list: linux-mips

On Mon, 7 Jun 2004, Dmitriy Tochansky wrote:

> Ed Okerson wrote:
>
> >I have the same board and I use U-Boot.
> >
> >>Hi!
> >>Does anybody can advice me some bootloader for my Zinfandel(Db1500) board?
> >>
> >>CU.
> >>
> >>
> Had you any problems in compile it?

It was somewhat difficult to get it working in little endian mode, but
once I did I submitted patches back to U-Boot and it should work fine now.

Ed Okerson


From jorik@hydrogen.boeventronie.net Tue Jun  8 13:54:41 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 08 Jun 2004 13:54:46 +0100 (BST)
Received: from hydrogen.boeventronie.net ([IPv6:::ffff:217.114.100.248]:28102
	"EHLO hydrogen.foonet") by linux-mips.org with ESMTP
	id <S8225242AbUFHMyl>; Tue, 8 Jun 2004 13:54:41 +0100
Received: from jorik by hydrogen.foonet with local (Exim 3.36 #1 (Debian))
	id 1BXg7h-0005Hk-00
	for <linux-mips@linux-mips.org>; Tue, 08 Jun 2004 14:54:37 +0200
Date: Tue, 8 Jun 2004 14:54:37 +0200
From: Jorik Jonker <linux-mips@boeventronie.net>
To: Linux MIPS <linux-mips@linux-mips.org>
Subject: VINO
Message-ID: <20040608125437.GC19965@hydrogen.boeventronie.net>
Mail-Followup-To: Linux MIPS <linux-mips@linux-mips.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.5.5.1+cvs20040105i
Return-Path: <jorik@hydrogen.boeventronie.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: 5260
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: linux-mips@boeventronie.net
Precedence: bulk
X-list: linux-mips

Hi,

I have been playing around a bit with my Indycam, but it seems that some work
needs to be done to get a nice picture. I've read that it has something to do
with clipping and that the brightness control register is silently ignored. I
happen to have an IRIX installtion on my Indy as well, and I tried finding
out how to read the VINO registers from IRIX, but with no luck.
I suppose that there must be some kernel-space piece of code to read the GIO
(?) memory around adress 0x00080000, but I am not able to figure out how to
do this in IRIX. Perhaps someone (with al little bit more kernel-hacking
experience) could guide me a little bit on doing this?
Are there other people beside ladis who are attemping to enhance the VINO
driver in the linux kernel, and if so, what are your findings?
I would really like to contribute to VINO development, but it's quite opaque
matter to me, as the VINO spec is quite unclear and I am not certain what's
exactly going wrong in the VINO driver.

regards,
-- 
Jorik Jonker
http://boeventronie.net/

From maksik@gmx.co.uk Tue Jun  8 14:17:23 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 08 Jun 2004 14:17:28 +0100 (BST)
Received: from skl1.ukl.uni-freiburg.de ([IPv6:::ffff:193.196.199.1]:1179 "EHLO
	relay1.uniklinik-freiburg.de") by linux-mips.org with ESMTP
	id <S8225249AbUFHNRX>; Tue, 8 Jun 2004 14:17:23 +0100
Received: from wh85.ukl.uni-freiburg.de (ktl77.ukl.uni-freiburg.de [193.196.226.77])
	by relay1.uniklinik-freiburg.de (Email) with ESMTP id 8A4672F2B8
	for <linux-mips@linux-mips.org>; Tue,  8 Jun 2004 15:17:11 +0200 (CEST)
From: Max Zaitsev <maksik@gmx.co.uk>
Organization: Mutella Dev co.
To: Linux MIPS <linux-mips@linux-mips.org>
Subject: howto compile bootable O2 kernel with FB support?
Date: Tue, 8 Jun 2004 15:17:15 +0200
User-Agent: KMail/1.5.3
MIME-Version: 1.0
Content-Type: text/plain;
  charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200406081517.15059.maksik@gmx.co.uk>
Return-Path: <maksik@gmx.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: 5261
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: maksik@gmx.co.uk
Precedence: bulk
X-list: linux-mips

Hi list,

can anybody give me quite a straightforward directions how to build or where 
to acquire a bootable IP32 kernel with framebuffer support? I've been trying 
to do that with both self-compilation using gcc 3.3 (stage3 from kumba) or 
cross-compile toolchain from linux-mips (gcc 2.95 & co) with no success. 
neither of my kernels was able to even start booting. The two possible 
scenarios I've observed were (a) quiet hang after displaying the entry point 
or (b) illegal instruction. 

Interestingly enough, I'm able to boot binary kernel from Vivien (http://
www.linux-mips.org/~glaurung/O2/linux-2.6.1/kernel/vmlinux64) or from Ilya 
(http://www.total-knowledge.com/progs/mips/kernels/vmlinux.64-20040315). 
However, kernel from Vivien has some problems and for Ilya's kernel I have 
neither sources/config nor modules... 

Now, let me formulate the question: I don't want a bleeding edge top 
performance feature-rich kernel, I just need something that works reasonably 
well, boots from the hard drive alone and has support for graphics. Is there 
something like that for r5000 o2 or it does not exists?

Regards,
Max


From toch@dfpost.ru Tue Jun  8 15:57:27 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 08 Jun 2004 15:57:31 +0100 (BST)
Received: from dfpost.ru ([IPv6:::ffff:194.85.103.225]:16082 "EHLO
	mail.postwin.ru") by linux-mips.org with ESMTP id <S8225268AbUFHO51>;
	Tue, 8 Jun 2004 15:57:27 +0100
Received: by mail.postwin.ru (Postfix, from userid 7896)
	id DFE14844F8; Tue,  8 Jun 2004 18:57:00 +0400 (MSD)
Received: from dfpost.ru (unknown [192.168.9.4])
	by mail.postwin.ru (Postfix) with ESMTP id C5B1D844F5
	for <linux-mips@linux-mips.org>; Tue,  8 Jun 2004 18:57:00 +0400 (MSD)
Message-ID: <40C5D44A.6060309@dfpost.ru>
Date: Tue, 08 Jun 2004 18:59:22 +0400
From: Dmitriy Tochansky <toch@dfpost.ru>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7b) Gecko/20040421
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: linux-mips@linux-mips.org
Subject: cannot branch to an undefined symbol
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Return-Path: <toch@dfpost.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: 5262
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: toch@dfpost.ru
Precedence: bulk
X-list: linux-mips

Hi!

What can I do to make this message dissapear when linking .S file?

CU

From nilanjan@genesis-microchip.com Tue Jun  8 17:34:00 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 08 Jun 2004 17:34:05 +0100 (BST)
Received: from [IPv6:::ffff:209.47.22.60] ([IPv6:::ffff:209.47.22.60]:26109
	"EHLO TOREXCL1.gmi.domain") by linux-mips.org with ESMTP
	id <S8225375AbUFHQeA>; Tue, 8 Jun 2004 17:34:00 +0100
Received: from INDIAEXCH.gmi.domain ([10.41.1.181]) by TOREXCL1.gmi.domain with Microsoft SMTPSVC(5.0.2195.6713);
	 Tue, 8 Jun 2004 12:33:57 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C44D76.63049A41"
Subject: kgdb
Date: Tue, 8 Jun 2004 22:03:53 +0530
Message-ID: <9A45247F1AEBB94189B16E7083981F93236136@INDIAEXCH.gmi.domain>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: kgdb
Thread-Index: AcRNdmMEYC9pjNU0RFSOGjsRK6nkXA==
From: "Nilanjan Roychowdhury" <nilanjan@genesis-microchip.com>
To: <linux-mips@linux-mips.org>
X-OriginalArrivalTime: 08 Jun 2004 16:33:57.0701 (UTC) FILETIME=[65773F50:01C44D76]
Return-Path: <nilanjan@genesis-microchip.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: 5263
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: nilanjan@genesis-microchip.com
Precedence: bulk
X-list: linux-mips

This is a multi-part message in MIME format.

------_=_NextPart_001_01C44D76.63049A41
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

When I go to the kgd site I don't see them specifying a kgdb port for =
MIPS.
Is there any stable port available ??
If yes do we sync it with every release of gdb ???
Regards,
Nilanjan
=20

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

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

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

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

<div class=3DSection1>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>When I go to the <span class=3DSpellE>kgd</span> site =
I don&#8217;t
see them specifying a <span class=3DSpellE>kgdb</span> port for =
MIPS.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Is there any stable port <span =
class=3DGramE>available ??</span><o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>If yes do we sync it with every release of <span
class=3DSpellE><span class=3DGramE>gdb</span></span><span class=3DGramE> =
???</span><o:p></o:p></span></font></p>

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

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

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

</div>

</body>

</html>
=00
------_=_NextPart_001_01C44D76.63049A41--

From ddaney@avtrex.com Tue Jun  8 17:52:53 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 08 Jun 2004 17:52:58 +0100 (BST)
Received: from avtrex.com ([IPv6:::ffff:216.102.217.178]:49849 "EHLO
	avtrex.com") by linux-mips.org with ESMTP id <S8225375AbUFHQwx>;
	Tue, 8 Jun 2004 17:52:53 +0100
Received: from avtrex.com ([192.168.0.111] RDNS failed) by avtrex.com with Microsoft SMTPSVC(5.0.2195.6713);
	 Tue, 8 Jun 2004 09:50:56 -0700
Message-ID: <40C5EE85.8020607@avtrex.com>
Date: Tue, 08 Jun 2004 09:51:17 -0700
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: Dmitriy Tochansky <toch@dfpost.ru>
CC: linux-mips@linux-mips.org
Subject: Re: cannot branch to an undefined symbol
References: <40C5D44A.6060309@dfpost.ru>
In-Reply-To: <40C5D44A.6060309@dfpost.ru>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 08 Jun 2004 16:50:56.0792 (UTC) FILETIME=[C4E43180:01C44D78]
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: 5264
X-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

Dmitriy Tochansky wrote:

> Hi!
>
> What can I do to make this message dissapear when linking .S file?
>
> CU
>
Is it linking or assembling that is the problem?  If it is assembling 
you could look at:

http://sources.redhat.com/ml/binutils/2004-04/msg00476.html

David Daney.


From ladis@linux-mips.org Tue Jun  8 23:57:54 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 08 Jun 2004 23:57:58 +0100 (BST)
Received: from smtp.seznam.cz ([IPv6:::ffff:212.80.76.43]:17571 "HELO
	smtp.seznam.cz") by linux-mips.org with SMTP id <S8225867AbUFHW5y>;
	Tue, 8 Jun 2004 23:57:54 +0100
Received: (qmail 13276 invoked from network); 8 Jun 2004 22:40:31 -0000
Received: from unknown (HELO umax645sx) (Ladislav.Michl@160.218.40.14)
  by smtp.seznam.cz with SMTP; 8 Jun 2004 22:40:31 -0000
Received: from ladis by umax645sx with local (Exim 3.36 #1 (Debian))
	id 1BXojj-0000i1-00
	for <linux-mips@linux-mips.org>; Wed, 09 Jun 2004 00:06:27 +0200
Date: Wed, 9 Jun 2004 00:06:04 +0200
To: Linux MIPS <linux-mips@linux-mips.org>
Subject: Re: VINO
Message-ID: <20040608220604.GA2578@umax645sx>
References: <20040608125437.GC19965@hydrogen.boeventronie.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20040608125437.GC19965@hydrogen.boeventronie.net>
User-Agent: Mutt/1.5.6+20040523i
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: 5265
X-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 Tue, Jun 08, 2004 at 02:54:37PM +0200, Jorik Jonker wrote:
> Hi,
> 
> I have been playing around a bit with my Indycam, but it seems that some work
> needs to be done to get a nice picture. I've read that it has something to do
> with clipping and that the brightness control register is silently ignored. I
> happen to have an IRIX installtion on my Indy as well, and I tried finding
> out how to read the VINO registers from IRIX, but with no luck.

Indeed, there's probably no easy way to read VINO registers from
userspace.

> I suppose that there must be some kernel-space piece of code to read the GIO
> (?) memory around adress 0x00080000, but I am not able to figure out how to
> do this in IRIX. Perhaps someone (with al little bit more kernel-hacking
> experience) could guide me a little bit on doing this?

That's right idea ((?) - EISA memory space)

> Are there other people beside ladis who are attemping to enhance the VINO
> driver in the linux kernel, and if so, what are your findings?
> I would really like to contribute to VINO development, but it's quite opaque
> matter to me, as the VINO spec is quite unclear and I am not certain what's
> exactly going wrong in the VINO driver.

If you're seriously considering to help with VINO development this link:
http://www.ac3.edu.au/SGI_Developer/books/DevDriver_PG/sgi_html/ch09.html
looks like a good starting point. It's easy, just write driver which
allows you to read VINO registers while capture in progress :)

	ladis

From ralf@linux-mips.org Wed Jun  9 00:54:09 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 09 Jun 2004 00:54:13 +0100 (BST)
Received: from p508B75AD.dip.t-dialin.net ([IPv6:::ffff:80.139.117.173]:22544
	"EHLO mail.linux-mips.net") by linux-mips.org with ESMTP
	id <S8224829AbUFHXyJ>; Wed, 9 Jun 2004 00:54:09 +0100
Received: from fluff.linux-mips.net (fluff.linux-mips.net [127.0.0.1])
	by mail.linux-mips.net (8.12.11/8.12.8) with ESMTP id i58Ns3ux003456;
	Wed, 9 Jun 2004 01:54:03 +0200
Received: (from ralf@localhost)
	by fluff.linux-mips.net (8.12.11/8.12.11/Submit) id i58Ns0Re003455;
	Wed, 9 Jun 2004 01:54:00 +0200
Date: Wed, 9 Jun 2004 01:54:00 +0200
From: Ralf Baechle <ralf@linux-mips.org>
To: Herbert Poetzl <herbert@13thfloor.at>
Cc: linux-mips@linux-mips.org
Subject: Re: linux-vserver syscall ...
Message-ID: <20040608235400.GA31706@linux-mips.org>
References: <20040524182915.GA27481@MAIL.13thfloor.at>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20040524182915.GA27481@MAIL.13thfloor.at>
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: 5266
X-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, May 24, 2004 at 08:29:15PM +0200, Herbert Poetzl wrote:

> obviously I forgot to ask you to reserve a
> syscall for linux-vserver, and I just discovered
> this as the currently used number (273) was used
> up by some other syscall (in 2.6.7-rc1) ...
> 
> so I'm asking you now, could you please reserve
> a syscall for this project, so that we do not
> need to change it on every new kernel release?
> 
> here is a list of currently reserved syscalls
> (for other archs) and some links to the project
> (in case you care)

Not really - other than the fact that I'm reluctant to reserve syscall
numbers for something that might never make it into the kernel so
usually i386 reserving a syscall is what convinces me ...

Due to the three support ABIs you actually get 3 syscall numbers even.
o32 gets 277, N64 236 and N32 240.  Patch is below.

  Ralf

Index: arch/mips/kernel/scall32-o32.S
===================================================================
RCS file: /home/cvs/linux/arch/mips/kernel/scall32-o32.S,v
retrieving revision 1.8
diff -u -r1.8 scall32-o32.S
--- arch/mips/kernel/scall32-o32.S	26 Apr 2004 15:06:10 -0000	1.8
+++ arch/mips/kernel/scall32-o32.S	8 Jun 2004 23:39:44 -0000
@@ -627,6 +627,7 @@
 	sys	sys_mq_timedreceive	5
 	sys	sys_mq_notify		2	/* 4275 */
 	sys	sys_mq_getsetattr	3
+	sys	sys_ni_syscall		0	/* sys_vserver */
 
 	.endm
 
Index: arch/mips/kernel/scall64-64.S
===================================================================
RCS file: /home/cvs/linux/arch/mips/kernel/scall64-64.S,v
retrieving revision 1.12
diff -u -r1.12 scall64-64.S
--- arch/mips/kernel/scall64-64.S	6 Jun 2004 02:12:38 -0000	1.12
+++ arch/mips/kernel/scall64-64.S	8 Jun 2004 23:39:44 -0000
@@ -447,3 +447,4 @@
 	PTR	sys_mq_timedreceive
 	PTR	sys_mq_notify
 	PTR	sys_mq_getsetattr		/* 5235 */
+	PTR	sys_ni_syscall			/* sys_vserver */
Index: arch/mips/kernel/scall64-n32.S
===================================================================
RCS file: /home/cvs/linux/arch/mips/kernel/scall64-n32.S,v
retrieving revision 1.11
diff -u -r1.11 scall64-n32.S
--- arch/mips/kernel/scall64-n32.S	6 Jun 2004 02:12:38 -0000	1.11
+++ arch/mips/kernel/scall64-n32.S	8 Jun 2004 23:39:44 -0000
@@ -357,3 +357,4 @@
 	PTR	compat_sys_mq_timedreceive
 	PTR	compat_sys_mq_notify
 	PTR	compat_sys_mq_getsetattr	/* 6239 */
+	PTR	sys_ni_syscall			/* sys_vserver */
Index: arch/mips/kernel/scall64-o32.S
===================================================================
RCS file: /home/cvs/linux/arch/mips/kernel/scall64-o32.S,v
retrieving revision 1.11
diff -u -r1.11 scall64-o32.S
--- arch/mips/kernel/scall64-o32.S	6 Jun 2004 02:12:38 -0000	1.11
+++ arch/mips/kernel/scall64-o32.S	8 Jun 2004 23:39:44 -0000
@@ -535,6 +535,7 @@
 	sys	compat_sys_mq_timedreceive 5
 	sys	compat_sys_mq_notify	2	/* 4275 */
 	sys	compat_sys_mq_getsetattr 3
+	sys	sys_ni_syscall		0	/* sys_vserver */
 
 	.endm
 
Index: include/asm-mips/unistd.h
===================================================================
RCS file: /home/cvs/linux/include/asm-mips/unistd.h,v
retrieving revision 1.62
diff -u -r1.62 unistd.h
--- include/asm-mips/unistd.h	6 Jun 2004 02:12:54 -0000	1.62
+++ include/asm-mips/unistd.h	8 Jun 2004 23:39:44 -0000
@@ -297,16 +297,17 @@
 #define __NR_mq_timedreceive		(__NR_Linux + 274)
 #define __NR_mq_notify			(__NR_Linux + 275)
 #define __NR_mq_getsetattr		(__NR_Linux + 276)
+#define __NR_vserver			(__NR_Linux + 277)
 
 /*
  * Offset of the last Linux o32 flavoured syscall
  */
-#define __NR_Linux_syscalls		276
+#define __NR_Linux_syscalls		277
 
 #endif /* _MIPS_SIM == _MIPS_SIM_ABI32 */
 
 #define __NR_O32_Linux			4000
-#define __NR_O32_Linux_syscalls		276
+#define __NR_O32_Linux_syscalls		277
 
 #if _MIPS_SIM == _MIPS_SIM_ABI64
 
@@ -550,16 +551,17 @@
 #define __NR_mq_timedreceive		(__NR_Linux + 233)
 #define __NR_mq_notify			(__NR_Linux + 234)
 #define __NR_mq_getsetattr		(__NR_Linux + 235)
+#define __NR_vserver			(__NR_Linux + 236)
 
 /*
  * Offset of the last Linux flavoured syscall
  */
-#define __NR_Linux_syscalls		235
+#define __NR_Linux_syscalls		236
 
 #endif /* _MIPS_SIM == _MIPS_SIM_ABI64 */
 
 #define __NR_64_Linux			5000
-#define __NR_64_Linux_syscalls		235
+#define __NR_64_Linux_syscalls		236
 
 #if _MIPS_SIM == _MIPS_SIM_NABI32
 
@@ -807,16 +809,17 @@
 #define __NR_mq_timedreceive		(__NR_Linux + 237)
 #define __NR_mq_notify			(__NR_Linux + 238)
 #define __NR_mq_getsetattr		(__NR_Linux + 239)
+#define __NR_vserver			(__NR_Linux + 240)
 
 /*
  * Offset of the last N32 flavoured syscall
  */
-#define __NR_Linux_syscalls		239
+#define __NR_Linux_syscalls		240
 
 #endif /* _MIPS_SIM == _MIPS_SIM_NABI32 */
 
 #define __NR_N32_Linux			6000
-#define __NR_N32_Linux_syscalls		239
+#define __NR_N32_Linux_syscalls		240
 
 #ifndef __ASSEMBLY__
 

From jorik@hydrogen.boeventronie.net Wed Jun  9 13:20:47 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 09 Jun 2004 13:20:51 +0100 (BST)
Received: from hydrogen.boeventronie.net ([IPv6:::ffff:217.114.100.248]:53723
	"EHLO hydrogen.foonet") by linux-mips.org with ESMTP
	id <S8224945AbUFIMUr>; Wed, 9 Jun 2004 13:20:47 +0100
Received: from jorik by hydrogen.foonet with local (Exim 3.36 #1 (Debian))
	id 1BY24U-0004pI-00
	for <linux-mips@linux-mips.org>; Wed, 09 Jun 2004 14:20:46 +0200
Date: Wed, 9 Jun 2004 14:20:46 +0200
From: Jorik Jonker <linux-mips@boeventronie.net>
To: Linux MIPS <linux-mips@linux-mips.org>
Subject: Re: VINO
Message-ID: <20040609122046.GB18364@hydrogen.boeventronie.net>
Mail-Followup-To: Linux MIPS <linux-mips@linux-mips.org>
References: <20040608125437.GC19965@hydrogen.boeventronie.net> <20040608220604.GA2578@umax645sx>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20040608220604.GA2578@umax645sx>
User-Agent: Mutt/1.5.5.1+cvs20040105i
Return-Path: <jorik@hydrogen.boeventronie.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: 5268
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: linux-mips@boeventronie.net
Precedence: bulk
X-list: linux-mips
Content-Length: 1057
Lines: 20

On Wed, Jun 09, 2004 at 12:06:04AM +0200, Ladislav Michl wrote:
> If you're seriously considering to help with VINO development this link:
> http://www.ac3.edu.au/SGI_Developer/books/DevDriver_PG/sgi_html/ch09.html
> looks like a good starting point. It's easy, just write driver which
> allows you to read VINO registers while capture in progress :)

Well, it seems not that easy for me. As I told, it's very opaque matter to
me; ie I already figured out that a kernel driver must be built but I really
have no clue on how to do this. For instance, I don't know what call (if
there exists any) should access that memory.
My plan was on writing a driver which allows me (through an ioctl to a special
device) to read/write to the VINO registers. I think I saw a driver example
in the DevDriver_PG which shows how to communicate through ioctl with
userspace (or kernelspace, depends on how you look at it), but the part where
I do the actual 'talking' to the VINO is matter I don't have any clue on how
to do that.

-- 
Jorik Jonker
http://boeventronie.net/

From r.zilli@ingredium.it Wed Jun  9 15:38:44 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 09 Jun 2004 15:38:48 +0100 (BST)
Received: from host195-84.pool217141.interbusiness.it ([IPv6:::ffff:217.141.84.195]:39182
	"EHLO pop.ingredium.it") by linux-mips.org with ESMTP
	id <S8225621AbUFIOio>; Wed, 9 Jun 2004 15:38:44 +0100
Received: (qmail 1849 invoked by uid 89); 9 Jun 2004 14:38:37 -0000
Message-ID: <20040609143837.1848.qmail@pop.ingredium.it>
From: "r.zilli" <r.zilli@ingredium.it>
To: linux-mips@linux-mips.org
Subject: HD Boot on Pb1500 Kernel 2.4.26
Date: Wed, 09 Jun 2004 16:38:37 +0200
Mime-Version: 1.0
Content-Type: text/plain; format=flowed; charset="utf-8"
Content-Transfer-Encoding: 7bit
Return-Path: <r.zilli@ingredium.it>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 5269
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: r.zilli@ingredium.it
Precedence: bulk
X-list: linux-mips
Content-Length: 250
Lines: 10

Hi, list 

i've successful patched the 2.4.26 with v4l support to get the saa7134 
driver support on Alchemy Pb1500. The driver for the HPT370 is ok but the 
ide channels are not scanned and hard disk are not recognized. 

Thanks for any help 

zr 


From herbert@13thfloor.at Wed Jun  9 15:44:27 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 09 Jun 2004 15:44:31 +0100 (BST)
Received: from MAIL.13thfloor.at ([IPv6:::ffff:212.16.62.51]:23941 "EHLO
	mail.13thfloor.at") by linux-mips.org with ESMTP
	id <S8224829AbUFIOo1>; Wed, 9 Jun 2004 15:44:27 +0100
Received: by mail.13thfloor.at (Postfix, from userid 1001)
	id 9B65851026A; Wed,  9 Jun 2004 16:44:22 +0200 (CEST)
Date: Wed, 9 Jun 2004 16:44:22 +0200
From: Herbert Poetzl <herbert@13thfloor.at>
To: Ralf Baechle <ralf@linux-mips.org>
Cc: linux-mips@linux-mips.org
Subject: Re: linux-vserver syscall ...
Message-ID: <20040609144422.GA24002@MAIL.13thfloor.at>
References: <20040524182915.GA27481@MAIL.13thfloor.at> <20040608235400.GA31706@linux-mips.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20040608235400.GA31706@linux-mips.org>
User-Agent: Mutt/1.4.1i
Return-Path: <herbert@13thfloor.at>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 5270
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: herbert@13thfloor.at
Precedence: bulk
X-list: linux-mips
Content-Length: 1001
Lines: 29

On Wed, Jun 09, 2004 at 01:54:00AM +0200, Ralf Baechle wrote:
> On Mon, May 24, 2004 at 08:29:15PM +0200, Herbert Poetzl wrote:
> 
> > obviously I forgot to ask you to reserve a
> > syscall for linux-vserver, and I just discovered
> > this as the currently used number (273) was used
> > up by some other syscall (in 2.6.7-rc1) ...
> > 
> > so I'm asking you now, could you please reserve
> > a syscall for this project, so that we do not
> > need to change it on every new kernel release?
> > 
> > here is a list of currently reserved syscalls
> > (for other archs) and some links to the project
> > (in case you care)
> 
> Not really - other than the fact that I'm reluctant to reserve syscall
> numbers for something that might never make it into the kernel so
> usually i386 reserving a syscall is what convinces me ...
> 
> Due to the three support ABIs you actually get 3 syscall numbers even.
> o32 gets 277, N64 236 and N32 240.  Patch is below.

thank you very much!

best,
Herbert

>   Ralf

From ralf@linux-mips.org Wed Jun  9 17:20:40 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 09 Jun 2004 17:20:44 +0100 (BST)
Received: from p508B6C63.dip.t-dialin.net ([IPv6:::ffff:80.139.108.99]:29210
	"EHLO mail.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225313AbUFIQUk>; Wed, 9 Jun 2004 17:20:40 +0100
Received: from fluff.linux-mips.net (fluff.linux-mips.net [127.0.0.1])
	by mail.linux-mips.net (8.12.11/8.12.8) with ESMTP id i59GKdIO028740;
	Wed, 9 Jun 2004 18:20:39 +0200
Received: (from ralf@localhost)
	by fluff.linux-mips.net (8.12.11/8.12.11/Submit) id i59GKc1I028739;
	Wed, 9 Jun 2004 18:20:38 +0200
Date: Wed, 9 Jun 2004 18:20:38 +0200
From: Ralf Baechle <ralf@linux-mips.org>
To: linux-mips@linux-mips.org
Subject: Anonymous CVS server offline again
Message-ID: <20040609162038.GA28419@linux-mips.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
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: 5271
X-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: 350
Lines: 9

today another bunch of exploitable security holes in CVS was published.
I therefore disabled anonymous access via pserver.  As a workaround
you can still use rsync to mirror the cvs archive, then do a checkout
or update from the mirror.  This may take some modification to the
CVS/Repository and CVS/Root files.

Sorry for the inconvenience,

  Ralf

From ppopov@mvista.com Wed Jun  9 17:27:14 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 09 Jun 2004 17:27:18 +0100 (BST)
Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:5884 "EHLO
	av.mvista.com") by linux-mips.org with ESMTP id <S8225313AbUFIQ1O>;
	Wed, 9 Jun 2004 17:27:14 +0100
Received: from [10.2.2.68] (av [127.0.0.1])
	by av.mvista.com (8.9.3/8.9.3) with ESMTP id JAA12600;
	Wed, 9 Jun 2004 09:27:01 -0700
Subject: Re: HD Boot on Pb1500 Kernel 2.4.26
From: Pete Popov <ppopov@mvista.com>
To: "r.zilli" <r.zilli@ingredium.it>
Cc: linux-mips@linux-mips.org
In-Reply-To: <20040609143837.1848.qmail@pop.ingredium.it>
References: <20040609143837.1848.qmail@pop.ingredium.it>
Content-Type: text/plain
Organization: 
Message-Id: <1086798549.15514.37.camel@thinkpad>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.2.2 (1.2.2-4) 
Date: 09 Jun 2004 09:29:09 -0700
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: 5272
X-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
Content-Length: 488
Lines: 15

On Wed, 2004-06-09 at 07:38, r.zilli wrote:
> Hi, list 
> 
> i've successful patched the 2.4.26 with v4l support to get the saa7134 
> driver support on Alchemy Pb1500. The driver for the HPT370 is ok but the 
> ide channels are not scanned and hard disk are not recognized. 
> 
> Thanks for any help 

2.4.25 was fine. I haven't tried 2.4.26 yet to see if anything broke
during the merge. You're just using the ide controller on the Pb1500,
not an external PCI controller, right?

Pete


From ddaney@avtrex.com Thu Jun 10 20:14:10 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 10 Jun 2004 20:14:15 +0100 (BST)
Received: from avtrex.com ([IPv6:::ffff:216.102.217.178]:17367 "EHLO
	avtrex.com") by linux-mips.org with ESMTP id <S8225769AbUFJTOK>;
	Thu, 10 Jun 2004 20:14:10 +0100
Received: from avtrex.com ([192.168.0.111] RDNS failed) by avtrex.com with Microsoft SMTPSVC(5.0.2195.6713);
	 Thu, 10 Jun 2004 12:11:56 -0700
Message-ID: <40C8B29B.3090501@avtrex.com>
Date: Thu, 10 Jun 2004 12:12:27 -0700
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: gcc@gcc.gnu.org, linux-mips@linux-mips.org
CC: java@gcc.gnu.org
Subject: [RFC] MIPS division by zero and libgcj...
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 10 Jun 2004 19:11:56.0741 (UTC) FILETIME=[CC3D7750:01C44F1E]
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: 5273
X-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

It appears that gcc configured for mipsel-linux will execute a "break 7" 
instruction on integer division by zero.

This causes the kernel (I am using 2.4.25) to send SIGTRAP.

Gcj when configured for this platform uses the -f-use-divide-subroutine 
option, causing it to never generate inline division instructions (nor 
the accompanying break 7), but instead call a runtime function that 
properly handles throwing ArithmeticException.

Q1:  Is this behavior (use of break 7 and SIGTRAP) part of some ABI 
specification?  I'll admit a bit of ignorance in this area.

Q2: Does anyone see any reason that libgcj should not be configured to 
handle the SIGTRAP and throw the ArithmeticException from the signal 
handler (similar to what is done on i386).

Q3: Will using SIGTRAP in this manner make debugging programs that 
divide things by zero very difficult to debug under gdb?

Q4: I appears that on the i386, a divide overflow causes SIGFPE.  Why 
doesn't the mips-linux kernel sent SIGFPE on "break 7"

Q5: prims.cc in libgcj implies that we should be handling SIGFPE to do 
all this.  If I make these changes, won't it be a little confusing that 
all references to SIGFPE are really SIGTRAP?


David Daney








From aph@redhat.com Thu Jun 10 20:33:33 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 10 Jun 2004 20:33:37 +0100 (BST)
Received: from cpc1-cmbg3-5-0-cust123.cmbg.cable.ntl.com ([IPv6:::ffff:81.96.64.123]:52934
	"EHLO cuddles.cambridge.redhat.com") by linux-mips.org with ESMTP
	id <S8225778AbUFJTdd>; Thu, 10 Jun 2004 20:33:33 +0100
Received: from redhat.com (localhost.localdomain [127.0.0.1])
	by cuddles.cambridge.redhat.com (8.12.8/8.12.8) with ESMTP id i5AJVmVL023902;
	Thu, 10 Jun 2004 20:31:58 +0100
Received: (from aph@localhost)
	by redhat.com (8.12.8/8.12.8/Submit) id i5AJVlGH023898;
	Thu, 10 Jun 2004 20:31:47 +0100
From: Andrew Haley <aph@redhat.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <16584.46883.332620.513805@cuddles.cambridge.redhat.com>
Date: Thu, 10 Jun 2004 20:31:47 +0100
To: David Daney <ddaney@avtrex.com>
Cc: gcc@gcc.gnu.org, linux-mips@linux-mips.org, java@gcc.gnu.org
Subject: [RFC] MIPS division by zero and libgcj...
In-Reply-To: <40C8B29B.3090501@avtrex.com>
References: <40C8B29B.3090501@avtrex.com>
X-Mailer: VM 7.14 under Emacs 21.3.50.1
Return-Path: <aph@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: 5275
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: aph@redhat.com
Precedence: bulk
X-list: linux-mips
Content-Length: 1700
Lines: 43

David Daney writes:
 > It appears that gcc configured for mipsel-linux will execute a "break 7" 
 > instruction on integer division by zero.

I thought that the MIPS never generated a hardware trap for division,
but instead there was an assembler macro that did the test for
overflow, and the "div" instruction actually generates this test
inline.  Maybe do a disassembly to check.

 > This causes the kernel (I am using 2.4.25) to send SIGTRAP.
 > 
 > Gcj when configured for this platform uses the -f-use-divide-subroutine 
 > option, causing it to never generate inline division instructions (nor 
 > the accompanying break 7), but instead call a runtime function that 
 > properly handles throwing ArithmeticException.
 > 
 > Q1:  Is this behavior (use of break 7 and SIGTRAP) part of some ABI 
 > specification?  I'll admit a bit of ignorance in this area.

See above.

 > Q2: Does anyone see any reason that libgcj should not be configured to 
 > handle the SIGTRAP and throw the ArithmeticException from the signal 
 > handler (similar to what is done on i386).

No, there's no reason not to do it.  You'll have to write some hairy
code to satisfy all the rules, though.

 > Q3: Will using SIGTRAP in this manner make debugging programs that 
 > divide things by zero very difficult to debug under gdb?

No.

 > Q4: I appears that on the i386, a divide overflow causes SIGFPE.  Why 
 > doesn't the mips-linux kernel sent SIGFPE on "break 7"
 > 
 > Q5: prims.cc in libgcj implies that we should be handling SIGFPE to do 
 > all this.  If I make these changes, won't it be a little confusing that 
 > all references to SIGFPE are really SIGTRAP?

Feel free to change the comments.  :-)

Andrew.

From aph@redhat.com Thu Jun 10 20:41:07 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 10 Jun 2004 20:41:11 +0100 (BST)
Received: from cpc1-cmbg3-5-0-cust123.cmbg.cable.ntl.com ([IPv6:::ffff:81.96.64.123]:59334
	"EHLO cuddles.cambridge.redhat.com") by linux-mips.org with ESMTP
	id <S8225773AbUFJTlH>; Thu, 10 Jun 2004 20:41:07 +0100
Received: from redhat.com (localhost.localdomain [127.0.0.1])
	by cuddles.cambridge.redhat.com (8.12.8/8.12.8) with ESMTP id i5AJdQVL023960;
	Thu, 10 Jun 2004 20:39:36 +0100
Received: (from aph@localhost)
	by redhat.com (8.12.8/8.12.8/Submit) id i5AJdP4I023956;
	Thu, 10 Jun 2004 20:39:25 +0100
From: Andrew Haley <aph@redhat.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <16584.47341.874148.879473@cuddles.cambridge.redhat.com>
Date: Thu, 10 Jun 2004 20:39:25 +0100
To: David Daney <ddaney@avtrex.com>, gcc@gcc.gnu.org,
	linux-mips@linux-mips.org, java@gcc.gnu.org
Subject: [RFC] MIPS division by zero and libgcj...
In-Reply-To: <16584.46883.332620.513805@cuddles.cambridge.redhat.com>
References: <40C8B29B.3090501@avtrex.com>
	<16584.46883.332620.513805@cuddles.cambridge.redhat.com>
X-Mailer: VM 7.14 under Emacs 21.3.50.1
Return-Path: <aph@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: 5276
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: aph@redhat.com
Precedence: bulk
X-list: linux-mips
Content-Length: 996
Lines: 31

Andrew Haley writes:
 > David Daney writes:
 >  > It appears that gcc configured for mipsel-linux will execute a "break 7" 
 >  > instruction on integer division by zero.
 > 
 > I thought that the MIPS never generated a hardware trap for division,
 > but instead there was an assembler macro that did the test for
 > overflow, and the "div" instruction actually generates this test
 > inline.  Maybe do a disassembly to check.

Here we are:

MIPS Dependent Features

--trap
--no-break

    automatically macro expands certain division and multiplication
    instructions to check for overflow and division by zero. This
    option causes to generate code to take a trap exception rather
    than a break exception when an error is detected. The trap
    instructions are only supported at Instruction Set Architecture
    level 2 and higher.

--break
--no-trap

    Generate code to take a break exception rather than a trap
    exception when an error is detected. This is the default.

Andrew.

From ddaney@avtrex.com Thu Jun 10 20:49:36 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 10 Jun 2004 20:49:40 +0100 (BST)
Received: from avtrex.com ([IPv6:::ffff:216.102.217.178]:18395 "EHLO
	avtrex.com") by linux-mips.org with ESMTP id <S8225773AbUFJTtg>;
	Thu, 10 Jun 2004 20:49:36 +0100
Received: from avtrex.com ([192.168.0.111] RDNS failed) by avtrex.com with Microsoft SMTPSVC(5.0.2195.6713);
	 Thu, 10 Jun 2004 12:47:29 -0700
Message-ID: <40C8BAF0.9070007@avtrex.com>
Date: Thu, 10 Jun 2004 12:48:00 -0700
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: Andrew Haley <aph@redhat.com>
CC: gcc@gcc.gnu.org, linux-mips@linux-mips.org, java@gcc.gnu.org
Subject: Re: [RFC] MIPS division by zero and libgcj...
References: <40C8B29B.3090501@avtrex.com> <16584.46883.332620.513805@cuddles.cambridge.redhat.com>
In-Reply-To: <16584.46883.332620.513805@cuddles.cambridge.redhat.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 10 Jun 2004 19:47:29.0878 (UTC) FILETIME=[C3B05760:01C44F23]
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: 5277
X-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: 1922
Lines: 55

Andrew Haley wrote:

>David Daney writes:
> > It appears that gcc configured for mipsel-linux will execute a "break 7" 
> > instruction on integer division by zero.
>
>I thought that the MIPS never generated a hardware trap for division,
>but instead there was an assembler macro that did the test for
>overflow, and the "div" instruction actually generates this test
>inline.  Maybe do a disassembly to check.
>  
>
MIPS div instructions never trap.  However I think that GCC always emits 
things like this when it cannot determine that the divisor is non zero:

        div     $0,$17,$16
        bne     $16,$0,1f
        nop
        break   7
1:
 

> > This causes the kernel (I am using 2.4.25) to send SIGTRAP.
> > 
> > Gcj when configured for this platform uses the -f-use-divide-subroutine 
> > option, causing it to never generate inline division instructions (nor 
> > the accompanying break 7), but instead call a runtime function that 
> > properly handles throwing ArithmeticException.
> > 
> > Q1:  Is this behavior (use of break 7 and SIGTRAP) part of some ABI 
> > specification?  I'll admit a bit of ignorance in this area.
>
>See above.
>
> > Q2: Does anyone see any reason that libgcj should not be configured to 
> > handle the SIGTRAP and throw the ArithmeticException from the signal 
> > handler (similar to what is done on i386).
>
>No, there's no reason not to do it.  You'll have to write some hairy
>code to satisfy all the rules, though.
>
What are the rules?  Are they more complicated then throw an 
ArithmeticException when the divisor is zero?

>
> > Q3: Will using SIGTRAP in this manner make debugging programs that 
> > divide things by zero very difficult to debug under gdb?
>
>No.
>  
>
I have not tried it.  But I think gdb uses "break" and SIGTRAP for 
breakpoints.  Is it possible to get gdb to pass the signal to the 
debugee, so that it could be handled by the runtime support?


From aph@redhat.com Thu Jun 10 20:59:41 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 10 Jun 2004 20:59:45 +0100 (BST)
Received: from cpc1-cmbg3-5-0-cust123.cmbg.cable.ntl.com ([IPv6:::ffff:81.96.64.123]:8135
	"EHLO cuddles.cambridge.redhat.com") by linux-mips.org with ESMTP
	id <S8225786AbUFJT7l>; Thu, 10 Jun 2004 20:59:41 +0100
Received: from redhat.com (localhost.localdomain [127.0.0.1])
	by cuddles.cambridge.redhat.com (8.12.8/8.12.8) with ESMTP id i5AJw1VL024113;
	Thu, 10 Jun 2004 20:58:11 +0100
Received: (from aph@localhost)
	by redhat.com (8.12.8/8.12.8/Submit) id i5AJw08f024109;
	Thu, 10 Jun 2004 20:58:00 +0100
From: Andrew Haley <aph@redhat.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <16584.48456.389968.903435@cuddles.cambridge.redhat.com>
Date: Thu, 10 Jun 2004 20:58:00 +0100
To: David Daney <ddaney@avtrex.com>
Cc: gcc@gcc.gnu.org, linux-mips@linux-mips.org, java@gcc.gnu.org
Subject: Re: [RFC] MIPS division by zero and libgcj...
In-Reply-To: <40C8BAF0.9070007@avtrex.com>
References: <40C8B29B.3090501@avtrex.com>
	<16584.46883.332620.513805@cuddles.cambridge.redhat.com>
	<40C8BAF0.9070007@avtrex.com>
X-Mailer: VM 7.14 under Emacs 21.3.50.1
Return-Path: <aph@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: 5278
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: aph@redhat.com
Precedence: bulk
X-list: linux-mips
Content-Length: 1161
Lines: 43

David Daney writes:
 > Andrew Haley wrote:
 > 
 > MIPS div instructions never trap.  However I think that GCC always emits 
 > things like this when it cannot determine that the divisor is non zero:
 > 
 >         div     $0,$17,$16
 >         bne     $16,$0,1f
 >         nop
 >         break   7
 > 1:
 >  
 > 

 > >No, there's no reason not to do it.  You'll have to write some hairy
 > >code to satisfy all the rules, though.
 > >
 > What are the rules?  Are they more complicated then throw an 
 > ArithmeticException when the divisor is zero?

Yes.  You also have to do

  if (dividend == (jint) 0x80000000L && divisor == -1)
    return dividend;
  
and not throw an exception.

 > > > Q3: Will using SIGTRAP in this manner make debugging programs that 
 > > > divide things by zero very difficult to debug under gdb?
 > >
 > >No.
 > >  
 > >
 > I have not tried it.  But I think gdb uses "break" and SIGTRAP for 
 > breakpoints.  Is it possible to get gdb to pass the signal to the 
 > debugee, so that it could be handled by the runtime support?

Well, gcj will generate either break or trap instructions.  You can
tell gdb to ignore either.

Andrew.



From ralf@linux-mips.org Thu Jun 10 21:27:59 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 10 Jun 2004 21:28:03 +0100 (BST)
Received: from p508B6474.dip.t-dialin.net ([IPv6:::ffff:80.139.100.116]:11307
	"EHLO mail.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225787AbUFJU17>; Thu, 10 Jun 2004 21:27:59 +0100
Received: from fluff.linux-mips.net (fluff.linux-mips.net [127.0.0.1])
	by mail.linux-mips.net (8.12.11/8.12.8) with ESMTP id i5AKRrZu011305;
	Thu, 10 Jun 2004 22:27:54 +0200
Received: (from ralf@localhost)
	by fluff.linux-mips.net (8.12.11/8.12.11/Submit) id i5AKRpRR011304;
	Thu, 10 Jun 2004 22:27:51 +0200
Date: Thu, 10 Jun 2004 22:27:51 +0200
From: Ralf Baechle <ralf@linux-mips.org>
To: Andrew Haley <aph@redhat.com>
Cc: David Daney <ddaney@avtrex.com>, gcc@gcc.gnu.org,
	linux-mips@linux-mips.org, java@gcc.gnu.org
Subject: Re: [RFC] MIPS division by zero and libgcj...
Message-ID: <20040610202751.GA5816@linux-mips.org>
References: <40C8B29B.3090501@avtrex.com> <16584.46883.332620.513805@cuddles.cambridge.redhat.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <16584.46883.332620.513805@cuddles.cambridge.redhat.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: 5279
X-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: 456
Lines: 11

On Thu, Jun 10, 2004 at 08:31:47PM +0100, Andrew Haley wrote:

> I thought that the MIPS never generated a hardware trap for division,
> but instead there was an assembler macro that did the test for
> overflow, and the "div" instruction actually generates this test
> inline.  Maybe do a disassembly to check.

Linux/MIPS's behaviour is consistent with all MIPS UNIX flavours I know
of both those following the SysV ABI and others such as Ultrix.

  Ralf

From ddaney@avtrex.com Thu Jun 10 21:32:52 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 10 Jun 2004 21:32:56 +0100 (BST)
Received: from avtrex.com ([IPv6:::ffff:216.102.217.178]:17117 "EHLO
	avtrex.com") by linux-mips.org with ESMTP id <S8225787AbUFJUcw>;
	Thu, 10 Jun 2004 21:32:52 +0100
Received: from avtrex.com ([192.168.0.111] RDNS failed) by avtrex.com with Microsoft SMTPSVC(5.0.2195.6713);
	 Thu, 10 Jun 2004 13:30:43 -0700
Message-ID: <40C8C512.2020607@avtrex.com>
Date: Thu, 10 Jun 2004 13:31:14 -0700
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: Andrew Haley <aph@redhat.com>
CC: gcc@gcc.gnu.org, linux-mips@linux-mips.org, java@gcc.gnu.org
Subject: Re: [RFC] MIPS division by zero and libgcj...
References: <40C8B29B.3090501@avtrex.com>	<16584.46883.332620.513805@cuddles.cambridge.redhat.com>	<40C8BAF0.9070007@avtrex.com> <16584.48456.389968.903435@cuddles.cambridge.redhat.com>
In-Reply-To: <16584.48456.389968.903435@cuddles.cambridge.redhat.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 10 Jun 2004 20:30:43.0868 (UTC) FILETIME=[CDD3CDC0:01C44F29]
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: 5280
X-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: 872
Lines: 36

Andrew Haley wrote:

>David Daney writes:
> > Andrew Haley wrote:
> > 
> > MIPS div instructions never trap.  However I think that GCC always emits 
> > things like this when it cannot determine that the divisor is non zero:
> > 
> >         div     $0,$17,$16
> >         bne     $16,$0,1f
> >         nop
> >         break   7
> > 1:
> >  
> > 
>
> > >No, there's no reason not to do it.  You'll have to write some hairy
> > >code to satisfy all the rules, though.
> > >
> > What are the rules?  Are they more complicated then throw an 
> > ArithmeticException when the divisor is zero?
>
>Yes.  You also have to do
>
>  if (dividend == (jint) 0x80000000L && divisor == -1)
>    return dividend;
>  
>and not throw an exception.
>
That is evidently what you have to do on i386.  MIPS gives the right 
answer without faulting (i.e. hitting the break 7).

David Daney.




From theansweriz42@hotmail.com Thu Jun 10 23:19:49 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 10 Jun 2004 23:19:53 +0100 (BST)
Received: from bay99-f42.bay99.hotmail.com ([IPv6:::ffff:65.54.175.42]:54538
	"EHLO hotmail.com") by linux-mips.org with ESMTP
	id <S8225774AbUFJWTt>; Thu, 10 Jun 2004 23:19:49 +0100
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC;
	 Thu, 10 Jun 2004 15:17:52 -0700
Received: from 209.243.128.191 by by99fd.bay99.hotmail.msn.com with HTTP;
	Thu, 10 Jun 2004 22:17:52 GMT
X-Originating-IP: [209.243.128.191]
X-Originating-Email: [theansweriz42@hotmail.com]
X-Sender: theansweriz42@hotmail.com
From: "S C" <theansweriz42@hotmail.com>
To: linux-mips@linux-mips.org
Subject: Kernel and monitor program
Date: Thu, 10 Jun 2004 22:17:52 +0000
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: <BAY99-F42680lFxUe9t00012257@hotmail.com>
X-OriginalArrivalTime: 10 Jun 2004 22:17:52.0782 (UTC) FILETIME=[C5C23AE0:01C44F38]
Return-Path: <theansweriz42@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: 5281
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: theansweriz42@hotmail.com
Precedence: bulk
X-list: linux-mips
Content-Length: 729
Lines: 18

Hello all,

Please pardon the newbie question, but I was wondering what a kernel in 
general expects a monitor program/bootloader like YAMON to do for it 
beforehand, if anything at all. I know the answer is very board specific, 
but if there are any generic things that a kernel expects ready for it 
before it starts running (caches initialized already? SDRAM control regs set 
up? Or maybe the kernel has no expectations at all?), I'd be grateful if 
someone could point them out.

TIA,
-S.

_________________________________________________________________
Watch the online reality show Mixed Messages with a friend and enter to win 
a trip to NY 
http://www.msnmessenger-download.click-url.com/go/onm00200497ave/direct/01/


From jsun@orion.mvista.com Thu Jun 10 23:26:56 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 10 Jun 2004 23:27:00 +0100 (BST)
Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:63222 "EHLO
	orion.mvista.com") by linux-mips.org with ESMTP id <S8225787AbUFJW04>;
	Thu, 10 Jun 2004 23:26:56 +0100
Received: from orion.mvista.com (localhost.localdomain [127.0.0.1])
	by orion.mvista.com (8.12.8/8.12.8) with ESMTP id i5AMQqx6019684;
	Thu, 10 Jun 2004 15:26:52 -0700
Received: (from jsun@localhost)
	by orion.mvista.com (8.12.8/8.12.8/Submit) id i5AMQqe5019683;
	Thu, 10 Jun 2004 15:26:52 -0700
Date: Thu, 10 Jun 2004 15:26:52 -0700
From: Jun Sun <jsun@mvista.com>
To: S C <theansweriz42@hotmail.com>
Cc: linux-mips@linux-mips.org, jsun@mvista.com
Subject: Re: Kernel and monitor program
Message-ID: <20040610152652.J10411@mvista.com>
References: <BAY99-F42680lFxUe9t00012257@hotmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <BAY99-F42680lFxUe9t00012257@hotmail.com>; from theansweriz42@hotmail.com on Thu, Jun 10, 2004 at 10:17:52PM +0000
Return-Path: <jsun@orion.mvista.com>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 5282
X-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: 943
Lines: 22

On Thu, Jun 10, 2004 at 10:17:52PM +0000, S C wrote:
> Hello all,
> 
> Please pardon the newbie question, but I was wondering what a kernel in 
> general expects a monitor program/bootloader like YAMON to do for it 
> beforehand, if anything at all. I know the answer is very board specific, 
> but if there are any generic things that a kernel expects ready for it 
> before it starts running (caches initialized already? SDRAM control regs set 
> up? Or maybe the kernel has no expectations at all?), I'd be grateful if 
> someone could point them out.

This is almost an FAQ.  (although I don't know if I am giving the
same answer each time ;0)

. initialize system RAM and its controller
. copy kernel to RAM (in normal cases, unless you do XIP)
. initialize and enable cache
. (optionally) pass some args to kernel
. (optionally) initial some board hw.  This is really a negotiation 
   between loader and linux board setup routine.

Jun

From ashok_kumar_ak@yahoo.com Fri Jun 11 12:49:55 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 11 Jun 2004 12:49:59 +0100 (BST)
Received: from web12006.mail.yahoo.com ([IPv6:::ffff:216.136.172.214]:46776
	"HELO web12006.mail.yahoo.com") by linux-mips.org with SMTP
	id <S8225924AbUFKLtz>; Fri, 11 Jun 2004 12:49:55 +0100
Message-ID: <20040611114948.22634.qmail@web12006.mail.yahoo.com>
Received: from [128.107.253.44] by web12006.mail.yahoo.com via HTTP; Fri, 11 Jun 2004 04:49:48 PDT
Date: Fri, 11 Jun 2004 04:49:48 -0700 (PDT)
From: "Ashok.A" <ashok_kumar_ak@yahoo.com>
Subject: Is "memory" clobber required for all inline asm which does atomic operation???
To: linux-mips@linux-mips.org
Cc: ashok_kumar_ak@yahoo.com
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Return-Path: <ashok_kumar_ak@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: 5283
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ashok_kumar_ak@yahoo.com
Precedence: bulk
X-list: linux-mips
Content-Length: 1189
Lines: 40

Hello Folks,

I am working on inline asm related staff. I couldn't
get proper answer for this question. So posting this
question here..... Expecting good response from you.

* Should we use "memory" clobber in *every* inline asm
  which does atomic operation? (In MIPS, 'll'/'sc'
  instructions are used to provide atomic operation)

As per my understanding, "memory" clobber will be
required for inline asm only if the corresponding
functions can be used to implement *lock* and *unlock*
primitives (or) memory modified by the inline asm
is *unknown*. Please correct me if I am wrong.

In the following URL, "memory" clobber has been
specified in the functions 'atomic_add_return' and
'atomic_sub_return'. But it is *not* specified in
the functions 'atomic_add' and 'atomic_sub'. WHY?

http://lxr.linux.no/source/include/asm-mips/atomic.h?v=2.6.5

Does it mean that 'atomic_add'/'atomic_sub' (which
returns 'void') can't be used to implement *lock*
and *unlock* primitives?

Please clarify it. Thanks in advance!

Expecting your responses ...

-AshokA


	
		
__________________________________
Do you Yahoo!?
Friends.  Fun.  Try the all-new Yahoo! Messenger.
http://messenger.yahoo.com/ 

From macro@ds2.pg.gda.pl Fri Jun 11 15:01:50 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 11 Jun 2004 15:01:54 +0100 (BST)
Received: from jurand.ds.pg.gda.pl ([IPv6:::ffff:153.19.208.2]:60357 "EHLO
	jurand.ds.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8225926AbUFKOBu>; Fri, 11 Jun 2004 15:01:50 +0100
Received: by jurand.ds.pg.gda.pl (Postfix, from userid 1011)
	id 1BBB14787C; Fri, 11 Jun 2004 16:01:43 +0200 (CEST)
Received: from localhost (localhost [127.0.0.1])
	by jurand.ds.pg.gda.pl (Postfix) with ESMTP
	id 045EE47833; Fri, 11 Jun 2004 16:01:42 +0200 (CEST)
Date: Fri, 11 Jun 2004 16:01:42 +0200 (CEST)
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To: David Daney <ddaney@avtrex.com>
Cc: gcc@gcc.gnu.org, linux-mips@linux-mips.org, java@gcc.gnu.org
Subject: Re: [RFC] MIPS division by zero and libgcj...
In-Reply-To: <40C8B29B.3090501@avtrex.com>
Message-ID: <Pine.LNX.4.55.0406111554420.13062@jurand.ds.pg.gda.pl>
References: <40C8B29B.3090501@avtrex.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: 5284
X-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: 981
Lines: 20

On Thu, 10 Jun 2004, David Daney wrote:

> It appears that gcc configured for mipsel-linux will execute a "break 7" 
> instruction on integer division by zero.
> 
> This causes the kernel (I am using 2.4.25) to send SIGTRAP.

 It looks like you have a problem in your configuration.  A "break 7"  
(or "teq <divisor>,$zero,7" -- but that's currently implemented in gas
only) is indeed emitted and exectuted in the case of division by zero, but
Linux has the ability to recognize this special break code and sends
SIGFPE instead.  There are actually two special codes defined, the other
being "6" for an overflow.  Both are handled by Linux, with si_code in
struct siginfo being set to FPE_INTDIV or FPE_INTOVF, respectively.  You
can handle this appropriately in a signal handler.

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

From ddaney@avtrex.com Fri Jun 11 16:36:02 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 11 Jun 2004 16:36:07 +0100 (BST)
Received: from avtrex.com ([IPv6:::ffff:216.102.217.178]:13896 "EHLO
	avtrex.com") by linux-mips.org with ESMTP id <S8225929AbUFKPgC>;
	Fri, 11 Jun 2004 16:36:02 +0100
Received: from avtrex.com ([192.168.0.111] RDNS failed) by avtrex.com with Microsoft SMTPSVC(5.0.2195.6713);
	 Fri, 11 Jun 2004 08:33:51 -0700
Message-ID: <40C9D101.3070001@avtrex.com>
Date: Fri, 11 Jun 2004 08:34:25 -0700
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: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
CC: gcc@gcc.gnu.org, linux-mips@linux-mips.org, java@gcc.gnu.org
Subject: Re: [RFC] MIPS division by zero and libgcj...
References: <40C8B29B.3090501@avtrex.com> <Pine.LNX.4.55.0406111554420.13062@jurand.ds.pg.gda.pl>
In-Reply-To: <Pine.LNX.4.55.0406111554420.13062@jurand.ds.pg.gda.pl>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 11 Jun 2004 15:33:51.0302 (UTC) FILETIME=[7F1FAE60:01C44FC9]
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: 5285
X-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: 1419
Lines: 42

Maciej W. Rozycki wrote:

>On Thu, 10 Jun 2004, David Daney wrote:
>
>  
>
>>It appears that gcc configured for mipsel-linux will execute a "break 7" 
>>instruction on integer division by zero.
>>
>>This causes the kernel (I am using 2.4.25) to send SIGTRAP.
>>    
>>
>
> It looks like you have a problem in your configuration.  A "break 7"  
>(or "teq <divisor>,$zero,7" -- but that's currently implemented in gas
>only) is indeed emitted and exectuted in the case of division by zero, but
>Linux has the ability to recognize this special break code and sends
>SIGFPE instead.  There are actually two special codes defined, the other
>being "6" for an overflow.  Both are handled by Linux, with si_code in
>struct siginfo being set to FPE_INTDIV or FPE_INTOVF, respectively.  You
>can handle this appropriately in a signal handler.
>
My kernel sources are from linux-mips.org, it is little-endian running on:

# cat /proc/cpuinfo
system type             : ATI-Xilleon
processor               : 0
cpu model               : MIPS 4Kc V0.7
BogoMIPS                : 299.00
wait instruction        : yes
microsecond timers      : yes
tlb_entries             : 16
extra interrupt vector  : yes
hardware watchpoint     : yes
VCED exceptions         : not available
VCEI exceptions         : not available

Could you point me to where in the kernel source this is handled?  I 
will try to see what when wrong.

David Daney.


From macro@ds2.pg.gda.pl Fri Jun 11 16:40:04 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 11 Jun 2004 16:40:08 +0100 (BST)
Received: from jurand.ds.pg.gda.pl ([IPv6:::ffff:153.19.208.2]:56739 "EHLO
	jurand.ds.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8225929AbUFKPkE>; Fri, 11 Jun 2004 16:40:04 +0100
Received: by jurand.ds.pg.gda.pl (Postfix, from userid 1011)
	id DC6BE4787C; Fri, 11 Jun 2004 17:39:57 +0200 (CEST)
Received: from localhost (localhost [127.0.0.1])
	by jurand.ds.pg.gda.pl (Postfix) with ESMTP
	id C376347485; Fri, 11 Jun 2004 17:39:57 +0200 (CEST)
Date: Fri, 11 Jun 2004 17:39:57 +0200 (CEST)
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To: David Daney <ddaney@avtrex.com>
Cc: gcc@gcc.gnu.org, linux-mips@linux-mips.org, java@gcc.gnu.org
Subject: Re: [RFC] MIPS division by zero and libgcj...
In-Reply-To: <40C9D101.3070001@avtrex.com>
Message-ID: <Pine.LNX.4.55.0406111737200.13062@jurand.ds.pg.gda.pl>
References: <40C8B29B.3090501@avtrex.com> <Pine.LNX.4.55.0406111554420.13062@jurand.ds.pg.gda.pl>
 <40C9D101.3070001@avtrex.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: 5286
X-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: 425
Lines: 12

On Fri, 11 Jun 2004, David Daney wrote:

> Could you point me to where in the kernel source this is handled?  I 
> will try to see what when wrong.

 For 2.4 it's arch/mips{,64}/kernel/traps.c, functions do_bp() and
do_tr().

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

From ddaney@avtrex.com Fri Jun 11 19:12:21 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 11 Jun 2004 19:12:27 +0100 (BST)
Received: from avtrex.com ([IPv6:::ffff:216.102.217.178]:56143 "EHLO
	avtrex.com") by linux-mips.org with ESMTP id <S8225934AbUFKSMV>;
	Fri, 11 Jun 2004 19:12:21 +0100
Received: from avtrex.com ([192.168.0.111] RDNS failed) by avtrex.com with Microsoft SMTPSVC(5.0.2195.6713);
	 Fri, 11 Jun 2004 11:10:09 -0700
Message-ID: <40C9F5A4.2050606@avtrex.com>
Date: Fri, 11 Jun 2004 11:10:44 -0700
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: [Patch]  / 0 should send SIGFPE not SIGTRAP...
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 11 Jun 2004 18:10:09.0958 (UTC) FILETIME=[553D0460:01C44FDF]
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: 5287
X-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: 472
Lines: 14

I am getting a SIGTRAP whenever an integer divide by 0 happens.  It 
should be sending SIGFPE.

It looks like kernel/traps.c is a little messed up.

The attached patch fixes it for me.

The decoding of the break instruction was selecting the wrong bits.  It 
looks like the trap instruction decoding was messed up also.  The patch 
fixes trap also, but I could not figure out how to get gcc to generate 
the trap form of division, so that part is untested.

David Daney.


From ddaney@avtrex.com Fri Jun 11 19:13:50 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 11 Jun 2004 19:13:54 +0100 (BST)
Received: from avtrex.com ([IPv6:::ffff:216.102.217.178]:5200 "EHLO avtrex.com")
	by linux-mips.org with ESMTP id <S8225467AbUFKSNu>;
	Fri, 11 Jun 2004 19:13:50 +0100
Received: from avtrex.com ([192.168.0.111] RDNS failed) by avtrex.com with Microsoft SMTPSVC(5.0.2195.6713);
	 Fri, 11 Jun 2004 11:11:39 -0700
Message-ID: <40C9F5FE.8030607@avtrex.com>
Date: Fri, 11 Jun 2004 11:12:14 -0700
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: Re: [Patch]  / 0 should send SIGFPE not SIGTRAP...
References: <40C9F5A4.2050606@avtrex.com>
In-Reply-To: <40C9F5A4.2050606@avtrex.com>
Content-Type: multipart/mixed;
 boundary="------------030201060104070501020203"
X-OriginalArrivalTime: 11 Jun 2004 18:11:39.0477 (UTC) FILETIME=[8A988850:01C44FDF]
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: 5288
X-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: 1660
Lines: 55

This is a multi-part message in MIME format.
--------------030201060104070501020203
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

It might help if I attached the patch.  Here it is...

David Daney wrote:

> I am getting a SIGTRAP whenever an integer divide by 0 happens.  It 
> should be sending SIGFPE.
>
> It looks like kernel/traps.c is a little messed up.
>
> The attached patch fixes it for me.
>
> The decoding of the break instruction was selecting the wrong bits.  
> It looks like the trap instruction decoding was messed up also.  The 
> patch fixes trap also, but I could not figure out how to get gcc to 
> generate the trap form of division, so that part is untested.
>
> David Daney.
>


--------------030201060104070501020203
Content-Type: text/plain;
 name="traps.diff"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="traps.diff"

--- ../linux-avtrex/linux/arch/mips/kernel/traps.c	2004-02-26 11:14:09.000000000 -0800
+++ arch/mips/kernel/traps.c	2004-06-11 10:13:59.000000000 -0700
@@ -598,7 +598,7 @@
 	 * code starts left to bit 16 instead to bit 6 in the opcode.
 	 * Gas is bug-compatible ...
 	 */
-	bcode = ((opcode >> 16) & ((1 << 20) - 1));
+	bcode = ((opcode >> 6) & ((1 << 20) - 1));
 
 	/*
 	 * (A short test says that IRIX 5.3 sends SIGTRAP for all break
@@ -633,7 +633,7 @@
 
 	/* Immediate versions don't provide a code.  */
 	if (!(opcode & OPCODE))
-		tcode = ((opcode >> 6) & ((1 << 20) - 1));
+		tcode = ((opcode >> 6) & ((1 << 10) - 1));
 
 	/*
 	 * (A short test says that IRIX 5.3 sends SIGTRAP for all trap

--------------030201060104070501020203--


From ddaney@avtrex.com Fri Jun 11 19:22:10 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 11 Jun 2004 19:22:14 +0100 (BST)
Received: from avtrex.com ([IPv6:::ffff:216.102.217.178]:24656 "EHLO
	avtrex.com") by linux-mips.org with ESMTP id <S8225467AbUFKSWK>;
	Fri, 11 Jun 2004 19:22:10 +0100
Received: from avtrex.com ([192.168.0.111] RDNS failed) by avtrex.com with Microsoft SMTPSVC(5.0.2195.6713);
	 Fri, 11 Jun 2004 11:19:57 -0700
Message-ID: <40C9F7F0.50501@avtrex.com>
Date: Fri, 11 Jun 2004 11:20:32 -0700
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, binutils@sources.redhat.com
Subject: Re: [Patch]  / 0 should send SIGFPE not SIGTRAP...
References: <40C9F5A4.2050606@avtrex.com> <40C9F5FE.8030607@avtrex.com>
In-Reply-To: <40C9F5FE.8030607@avtrex.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 11 Jun 2004 18:19:57.0543 (UTC) FILETIME=[B3775F70:01C44FE0]
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: 5289
X-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: 2244
Lines: 76

I guess I didn't fully read the comment above this section of code.

    /*
     * There is the ancient bug in the MIPS assemblers that the break
     * code starts left to bit 16 instead to bit 6 in the opcode.
     * Gas is bug-compatible ...
     */

I am using gcc-3.3.1/binutils-2.15.  With this toolchain, I get break 
instructions that comply with the MIPS documentation for break instructions:


00000000 <do_div>:
   0:   3c1c0000        lui     gp,0x0
   4:   279c0000        addiu   gp,gp,0
   8:   0399e021        addu    gp,gp,t9
   c:   0085001a        div     zero,a0,a1
  10:   14a00002        bnez    a1,1c <do_div+0x1c>
  14:   00000000        nop
  18:   000001cd        break   0x7
  1c:   00001012        mflo    v0
  20:   03e00008        jr      ra
  24:   00000000        nop
 

What to do?

David Daney

David Daney wrote:

> It might help if I attached the patch.  Here it is...
>
> David Daney wrote:
>
>> I am getting a SIGTRAP whenever an integer divide by 0 happens.  It 
>> should be sending SIGFPE.
>>
>> It looks like kernel/traps.c is a little messed up.
>>
>> The attached patch fixes it for me.
>>
>> The decoding of the break instruction was selecting the wrong bits.  
>> It looks like the trap instruction decoding was messed up also.  The 
>> patch fixes trap also, but I could not figure out how to get gcc to 
>> generate the trap form of division, so that part is untested.
>>
>> David Daney.
>>
>
>------------------------------------------------------------------------
>
>--- ../linux-avtrex/linux/arch/mips/kernel/traps.c	2004-02-26 11:14:09.000000000 -0800
>+++ arch/mips/kernel/traps.c	2004-06-11 10:13:59.000000000 -0700
>@@ -598,7 +598,7 @@
> 	 * code starts left to bit 16 instead to bit 6 in the opcode.
> 	 * Gas is bug-compatible ...
> 	 */
>-	bcode = ((opcode >> 16) & ((1 << 20) - 1));
>+	bcode = ((opcode >> 6) & ((1 << 20) - 1));
> 
> 	/*
> 	 * (A short test says that IRIX 5.3 sends SIGTRAP for all break
>@@ -633,7 +633,7 @@
> 
> 	/* Immediate versions don't provide a code.  */
> 	if (!(opcode & OPCODE))
>-		tcode = ((opcode >> 6) & ((1 << 20) - 1));
>+		tcode = ((opcode >> 6) & ((1 << 10) - 1));
> 
> 	/*
> 	 * (A short test says that IRIX 5.3 sends SIGTRAP for all trap
>  
>



From macro@ds2.pg.gda.pl Fri Jun 11 20:12:57 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 11 Jun 2004 20:13:01 +0100 (BST)
Received: from jurand.ds.pg.gda.pl ([IPv6:::ffff:153.19.208.2]:16563 "EHLO
	jurand.ds.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8225937AbUFKTM5>; Fri, 11 Jun 2004 20:12:57 +0100
Received: by jurand.ds.pg.gda.pl (Postfix, from userid 1011)
	id F11A647889; Fri, 11 Jun 2004 21:12:49 +0200 (CEST)
Received: from localhost (localhost [127.0.0.1])
	by jurand.ds.pg.gda.pl (Postfix) with ESMTP
	id 3CEAB47833; Fri, 11 Jun 2004 21:12:49 +0200 (CEST)
Date: Fri, 11 Jun 2004 21:12:49 +0200 (CEST)
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To: David Daney <ddaney@avtrex.com>
Cc: Ralf Baechle <ralf@linux-mips.org>, linux-mips@linux-mips.org,
	binutils@sources.redhat.com
Subject: Re: [Patch]  / 0 should send SIGFPE not SIGTRAP...
In-Reply-To: <40C9F7F0.50501@avtrex.com>
Message-ID: <Pine.LNX.4.55.0406112039040.13062@jurand.ds.pg.gda.pl>
References: <40C9F5A4.2050606@avtrex.com> <40C9F5FE.8030607@avtrex.com>
 <40C9F7F0.50501@avtrex.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: 5290
X-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: 2254
Lines: 57

On Fri, 11 Jun 2004, David Daney wrote:

> I guess I didn't fully read the comment above this section of code.
> 
>     /*
>      * There is the ancient bug in the MIPS assemblers that the break
>      * code starts left to bit 16 instead to bit 6 in the opcode.
>      * Gas is bug-compatible ...
>      */
> 
> I am using gcc-3.3.1/binutils-2.15.  With this toolchain, I get break 
> instructions that comply with the MIPS documentation for break instructions:

 Well, I did some research and I'm afraid it dates back to a commit from
2000-12-01, when a different interpretation of "break" was introduced for
the MIPS32/64 ISA.  So the interpretation of the "break" instruction
depends on the "-march" setting and moreover, only for instructions
requested explicitly.  For ones emitted implicitly as a result of division
and multiplication macros, the interpretation is always the "traditional"
one (the "c" vs the "B" code).

> 00000000 <do_div>:
>    0:   3c1c0000        lui     gp,0x0
>    4:   279c0000        addiu   gp,gp,0
>    8:   0399e021        addu    gp,gp,t9
>    c:   0085001a        div     zero,a0,a1
>   10:   14a00002        bnez    a1,1c <do_div+0x1c>
>   14:   00000000        nop
>   18:   000001cd        break   0x7
>   1c:   00001012        mflo    v0
>   20:   03e00008        jr      ra
>   24:   00000000        nop
>  
> 
> What to do?

1. I think Linux can intercept both the "traditional" and MIPS32/64 values
-- break codes are not used that extensively this would risk running out
of them.  The set of known ones can be seen in <asm/break.h>.  However,
this won't aid userland trying to interpret code (there may be none such, 
though).

2. Gas should definitely use the codes consistently.  And it's a pity the
ABI got broken -- I think another mnemonic should have been chosen for the
correct implementation of "break", available to any ISA.

3. GCC should probably use traps for anything above MIPS I, anyway.  
Perhaps with an option, like for gas, to select the alternative.

4. Perhaps something else.

  Maciej

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

From cgd@broadcom.com Fri Jun 11 20:28:03 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 11 Jun 2004 20:28:08 +0100 (BST)
Received: from mms2.broadcom.com ([IPv6:::ffff:63.70.210.59]:44817 "EHLO
	mms2.broadcom.com") by linux-mips.org with ESMTP
	id <S8225937AbUFKT2D>; Fri, 11 Jun 2004 20:28:03 +0100
Received: from 63.70.210.1 by mms2.broadcom.com with ESMTP (Broadcom
 SMTP Relay (MMS v5.6.0)); Fri, 11 Jun 2004 12:27:41 -0700
X-Server-Uuid: 011F2A72-58F1-4BCE-832F-B0D661E896E8
Received: from mail-sj1-5.sj.broadcom.com (mail-sj1-5.sj.broadcom.com
 [10.16.128.236]) by mon-irva-11.broadcom.com (8.9.1/8.9.1) with ESMTP
 id MAA08073; Fri, 11 Jun 2004 12:27:05 -0700 (PDT)
Received: from ldt-sj3-010.sj.broadcom.com (ldt-sj3-010 [10.21.64.10])
 by mail-sj1-5.sj.broadcom.com (8.12.9/8.12.9/SSF) with ESMTP id
 i5BJRbov003592; Fri, 11 Jun 2004 12:27:37 -0700 (PDT)
Received: (from cgd@localhost) by ldt-sj3-010.sj.broadcom.com (
 8.11.6/8.9.3) id i5BJRbm24661; Fri, 11 Jun 2004 12:27:37 -0700
X-Authentication-Warning: ldt-sj3-010.sj.broadcom.com: cgd set sender to
 cgd@broadcom.com using -f
To: macro@ds2.pg.gda.pl
cc: "David Daney" <ddaney@avtrex.com>,
	"Ralf Baechle" <ralf@linux-mips.org>, linux-mips@linux-mips.org,
	binutils@sources.redhat.com
Subject: Re: [Patch]  / 0 should send SIGFPE not SIGTRAP...
References: <40C9F5A4.2050606@avtrex.com> <40C9F5FE.8030607@avtrex.com>
 <40C9F7F0.50501@avtrex.com>
 <Pine.LNX.4.55.0406112039040.13062@jurand.ds.pg.gda.pl>
 <mailpost.1086981251.16853@news-sj1-1>
From: cgd@broadcom.com
Date: 11 Jun 2004 12:27:37 -0700
In-Reply-To: <mailpost.1086981251.16853@news-sj1-1>
Message-ID: <yov57juduc7q.fsf@ldt-sj3-010.sj.broadcom.com>
User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2
MIME-Version: 1.0
X-WSS-ID: 6CD4D8261T08499415-01-01
Content-Type: text/plain;
 charset=us-ascii
Content-Transfer-Encoding: 7bit
Return-Path: <cgd@broadcom.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: 5291
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: cgd@broadcom.com
Precedence: bulk
X-list: linux-mips
Content-Length: 1077
Lines: 28

At Fri, 11 Jun 2004 19:14:11 +0000 (UTC), "Maciej W. Rozycki" wrote:
> 2. Gas should definitely use the codes consistently.  And it's a pity the
> ABI got broken -- I think another mnemonic should have been chosen for the
> correct implementation of "break", available to any ISA.

in retrospect, the 'B' variation probably wasn't the greatest idea.

If it were removed (leaving 'c' and 'c','q' variations), I don't know
that any real harm would occur.

It may be very confusing to people who expect that the break code will
translate into the instruction in an obvious way, and obviously it
would mess up use of 20-bit codes, but i don't know how prevalent that
is.

Unfortunately, at this point, Linux should probably accept the
divide-by-zero code in both locations.


(Really, from day one, assemblers probably should have accepted a
20-bit code.  I just checked my copy of the Kane r2000/r3000 book, and
it was 20-bit all the way back then.  If i had to guess, i'd guess
that gas was copying a non-gnu assembler's behaviour.  In any case,
water under the bridge.)



cgd


From macro@ds2.pg.gda.pl Fri Jun 11 20:50:41 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 11 Jun 2004 20:50:45 +0100 (BST)
Received: from jurand.ds.pg.gda.pl ([IPv6:::ffff:153.19.208.2]:47829 "EHLO
	jurand.ds.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8225937AbUFKTul>; Fri, 11 Jun 2004 20:50:41 +0100
Received: by jurand.ds.pg.gda.pl (Postfix, from userid 1011)
	id 40FD3475C5; Fri, 11 Jun 2004 21:50:35 +0200 (CEST)
Received: from localhost (localhost [127.0.0.1])
	by jurand.ds.pg.gda.pl (Postfix) with ESMTP
	id 2943745837; Fri, 11 Jun 2004 21:50:35 +0200 (CEST)
Date: Fri, 11 Jun 2004 21:50:35 +0200 (CEST)
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To: cgd@broadcom.com
Cc: David Daney <ddaney@avtrex.com>,
	Ralf Baechle <ralf@linux-mips.org>, linux-mips@linux-mips.org,
	binutils@sources.redhat.com
Subject: Re: [Patch]  / 0 should send SIGFPE not SIGTRAP...
In-Reply-To: <yov57juduc7q.fsf@ldt-sj3-010.sj.broadcom.com>
Message-ID: <Pine.LNX.4.55.0406112133380.13062@jurand.ds.pg.gda.pl>
References: <40C9F5A4.2050606@avtrex.com> <40C9F5FE.8030607@avtrex.com>
 <40C9F7F0.50501@avtrex.com> <Pine.LNX.4.55.0406112039040.13062@jurand.ds.pg.gda.pl>
 <mailpost.1086981251.16853@news-sj1-1> <yov57juduc7q.fsf@ldt-sj3-010.sj.broadcom.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: 5292
X-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: 1639
Lines: 39

On Fri, 11 Jun 2004 cgd@broadcom.com wrote:

> > 2. Gas should definitely use the codes consistently.  And it's a pity the
> > ABI got broken -- I think another mnemonic should have been chosen for the
> > correct implementation of "break", available to any ISA.
> 
> in retrospect, the 'B' variation probably wasn't the greatest idea.

 I guess it may be useful for something to have 20-bit codes available.  
Though except these few special cases, breaks tend to be inserted at the
run time, so it's the interested software that decides how to interpret
them, not gas.

> It may be very confusing to people who expect that the break code will
> translate into the instruction in an obvious way, and obviously it
> would mess up use of 20-bit codes, but i don't know how prevalent that
> is.

 I was surprised at first, too.

> Unfortunately, at this point, Linux should probably accept the
> divide-by-zero code in both locations.

 I think that's not a big trouble for Linux -- the path is rare and not
critical for performance.

> (Really, from day one, assemblers probably should have accepted a
> 20-bit code.  I just checked my copy of the Kane r2000/r3000 book, and
> it was 20-bit all the way back then.  If i had to guess, i'd guess
> that gas was copying a non-gnu assembler's behaviour.  In any case,
> water under the bridge.)

 Definitely they should have.  It's bug-compatibility with the original
MIPS assembler, I'm told.

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

From ddaney@avtrex.com Fri Jun 11 21:52:39 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 11 Jun 2004 21:52:44 +0100 (BST)
Received: from avtrex.com ([IPv6:::ffff:216.102.217.178]:40792 "EHLO
	avtrex.com") by linux-mips.org with ESMTP id <S8225949AbUFKUwj>;
	Fri, 11 Jun 2004 21:52:39 +0100
Received: from avtrex.com ([192.168.0.111] RDNS failed) by avtrex.com with Microsoft SMTPSVC(5.0.2195.6713);
	 Fri, 11 Jun 2004 13:50:26 -0700
Message-ID: <40CA1B35.6010603@avtrex.com>
Date: Fri, 11 Jun 2004 13:51:01 -0700
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: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
CC: cgd@broadcom.com, Ralf Baechle <ralf@linux-mips.org>,
	linux-mips@linux-mips.org, binutils@sources.redhat.com
Subject: Re: [Patch]  / 0 should send SIGFPE not SIGTRAP...
References: <40C9F5A4.2050606@avtrex.com> <40C9F5FE.8030607@avtrex.com> <40C9F7F0.50501@avtrex.com> <Pine.LNX.4.55.0406112039040.13062@jurand.ds.pg.gda.pl> <mailpost.1086981251.16853@news-sj1-1> <yov57juduc7q.fsf@ldt-sj3-010.sj.broadcom.com> <Pine.LNX.4.55.0406112133380.13062@jurand.ds.pg.gda.pl>
In-Reply-To: <Pine.LNX.4.55.0406112133380.13062@jurand.ds.pg.gda.pl>
Content-Type: multipart/mixed;
 boundary="------------050705030308070603060308"
X-OriginalArrivalTime: 11 Jun 2004 20:50:26.0155 (UTC) FILETIME=[B8F03BB0:01C44FF5]
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: 5293
X-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: 2863
Lines: 100

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

Maciej W. Rozycki wrote:

>On Fri, 11 Jun 2004 cgd@broadcom.com wrote:
>  
>
>>Unfortunately, at this point, Linux should probably accept the
>>divide-by-zero code in both locations.
>>    
>>
>
> I think that's not a big trouble for Linux -- the path is rare and not
>critical for performance.
>
>  
>
How about the attached (lightly tested) patch?

David Daney.

--------------050705030308070603060308
Content-Type: text/plain;
 name="traps.diff"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="traps.diff"

*** ../linux-avtrex/linux/arch/mips/kernel/traps.c	2004-02-26 11:14:09.000000000 -0800
--- arch/mips/kernel/traps.c	2004-06-11 13:43:00.000000000 -0700
***************
*** 597,615 ****
  	 * There is the ancient bug in the MIPS assemblers that the break
  	 * code starts left to bit 16 instead to bit 6 in the opcode.
  	 * Gas is bug-compatible ...
! 	 */
! 	bcode = ((opcode >> 16) & ((1 << 20) - 1));
! 
! 	/*
  	 * (A short test says that IRIX 5.3 sends SIGTRAP for all break
  	 * insns, even for break codes that indicate arithmetic failures.
  	 * Weird ...)
  	 * But should we continue the brokenness???  --macro
  	 */
  	switch (bcode) {
! 	case 6:
! 	case 7:
! 		if (bcode == 7)
  			info.si_code = FPE_INTDIV;
  		else
  			info.si_code = FPE_INTOVF;
--- 597,621 ----
  	 * There is the ancient bug in the MIPS assemblers that the break
  	 * code starts left to bit 16 instead to bit 6 in the opcode.
  	 * Gas is bug-compatible ...
! 	 *
  	 * (A short test says that IRIX 5.3 sends SIGTRAP for all break
  	 * insns, even for break codes that indicate arithmetic failures.
  	 * Weird ...)
  	 * But should we continue the brokenness???  --macro
+          *
+          * It seems some assemblers (binutils-2.15 for example) assemble
+          * break correctly.  So we check for the break code in either
+          * position.
+          *
  	 */
+ 
+ 	bcode = ((opcode >> 6) & ((1 << 20) - 1));
  	switch (bcode) {
! 	case 0x0006:
! 	case 0x0007:
!         case 0x1800: /* 6 << 10 */
!         case 0x1c00: /* 7 << 10 */
! 		if (bcode == 0x7 || bcode == 0x1c00)
  			info.si_code = FPE_INTDIV;
  		else
  			info.si_code = FPE_INTOVF;
***************
*** 633,639 ****
  
  	/* Immediate versions don't provide a code.  */
  	if (!(opcode & OPCODE))
! 		tcode = ((opcode >> 6) & ((1 << 20) - 1));
  
  	/*
  	 * (A short test says that IRIX 5.3 sends SIGTRAP for all trap
--- 639,645 ----
  
  	/* Immediate versions don't provide a code.  */
  	if (!(opcode & OPCODE))
! 		tcode = ((opcode >> 6) & ((1 << 10) - 1));
  
  	/*
  	 * (A short test says that IRIX 5.3 sends SIGTRAP for all trap

--------------050705030308070603060308--


From ddaney@avtrex.com Fri Jun 11 22:12:37 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 11 Jun 2004 22:12:41 +0100 (BST)
Received: from avtrex.com ([IPv6:::ffff:216.102.217.178]:33113 "EHLO
	avtrex.com") by linux-mips.org with ESMTP id <S8225953AbUFKVMh>;
	Fri, 11 Jun 2004 22:12:37 +0100
Received: from avtrex.com ([192.168.0.111] RDNS failed) by avtrex.com with Microsoft SMTPSVC(5.0.2195.6713);
	 Fri, 11 Jun 2004 14:10:23 -0700
Message-ID: <40CA1FE3.9030507@avtrex.com>
Date: Fri, 11 Jun 2004 14:10:59 -0700
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: David Daney <ddaney@avtrex.com>
CC: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>, cgd@broadcom.com,
	Ralf Baechle <ralf@linux-mips.org>, linux-mips@linux-mips.org,
	binutils@sources.redhat.com
Subject: Re: [Patch] (revised patch) / 0 should send SIGFPE not SIGTRAP 
References: <40C9F5A4.2050606@avtrex.com> <40C9F5FE.8030607@avtrex.com> <40C9F7F0.50501@avtrex.com> <Pine.LNX.4.55.0406112039040.13062@jurand.ds.pg.gda.pl> <mailpost.1086981251.16853@news-sj1-1> <yov57juduc7q.fsf@ldt-sj3-010.sj.broadcom.com> <Pine.LNX.4.55.0406112133380.13062@jurand.ds.pg.gda.pl> <40CA1B35.6010603@avtrex.com>
In-Reply-To: <40CA1B35.6010603@avtrex.com>
Content-Type: multipart/mixed;
 boundary="------------020506050403020700000207"
X-OriginalArrivalTime: 11 Jun 2004 21:10:23.0998 (UTC) FILETIME=[82E891E0:01C44FF8]
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: 5294
X-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: 3032
Lines: 103

This is a multi-part message in MIME format.
--------------020506050403020700000207
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

David Daney wrote:

> How about the attached (lightly tested) patch?
>
I will quit sending patches after this one.  It is equivalent to the 
previous version, except it uses the symbolic names of the break codes 
instead of the numeric values.

David Daney.



--------------020506050403020700000207
Content-Type: text/plain;
 name="traps.diff"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="traps.diff"

*** ../linux-avtrex/linux/arch/mips/kernel/traps.c	2004-02-26 11:14:09.000000000 -0800
--- arch/mips/kernel/traps.c	2004-06-11 14:04:52.000000000 -0700
***************
*** 38,43 ****
--- 38,44 ----
  #include <asm/traps.h>
  #include <asm/uaccess.h>
  #include <asm/mmu_context.h>
+ #include <asm/break.h>
  
  extern asmlinkage void handle_mod(void);
  extern asmlinkage void handle_tlbl(void);
***************
*** 597,615 ****
  	 * There is the ancient bug in the MIPS assemblers that the break
  	 * code starts left to bit 16 instead to bit 6 in the opcode.
  	 * Gas is bug-compatible ...
! 	 */
! 	bcode = ((opcode >> 16) & ((1 << 20) - 1));
! 
! 	/*
  	 * (A short test says that IRIX 5.3 sends SIGTRAP for all break
  	 * insns, even for break codes that indicate arithmetic failures.
  	 * Weird ...)
  	 * But should we continue the brokenness???  --macro
  	 */
  	switch (bcode) {
! 	case 6:
! 	case 7:
! 		if (bcode == 7)
  			info.si_code = FPE_INTDIV;
  		else
  			info.si_code = FPE_INTOVF;
--- 598,622 ----
  	 * There is the ancient bug in the MIPS assemblers that the break
  	 * code starts left to bit 16 instead to bit 6 in the opcode.
  	 * Gas is bug-compatible ...
! 	 *
  	 * (A short test says that IRIX 5.3 sends SIGTRAP for all break
  	 * insns, even for break codes that indicate arithmetic failures.
  	 * Weird ...)
  	 * But should we continue the brokenness???  --macro
+          *
+          * It seems some assemblers (binutils-2.15 for example) assemble
+          * break correctly.  So we check for the break code in either
+          * position.
+          *
  	 */
+ 
+ 	bcode = ((opcode >> 6) & ((1 << 20) - 1));
  	switch (bcode) {
! 	case BRK_OVERFLOW:
! 	case BRK_DIVZERO:
!         case BRK_OVERFLOW << 10:
!         case BRK_DIVZERO << 10:
! 		if (bcode == BRK_DIVZERO || bcode == (BRK_DIVZERO << 10))
  			info.si_code = FPE_INTDIV;
  		else
  			info.si_code = FPE_INTOVF;
***************
*** 633,639 ****
  
  	/* Immediate versions don't provide a code.  */
  	if (!(opcode & OPCODE))
! 		tcode = ((opcode >> 6) & ((1 << 20) - 1));
  
  	/*
  	 * (A short test says that IRIX 5.3 sends SIGTRAP for all trap
--- 640,646 ----
  
  	/* Immediate versions don't provide a code.  */
  	if (!(opcode & OPCODE))
! 		tcode = ((opcode >> 6) & ((1 << 10) - 1));
  
  	/*
  	 * (A short test says that IRIX 5.3 sends SIGTRAP for all trap

--------------020506050403020700000207--


From charles.eidsness@ieee.org Sat Jun 12 17:31:02 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 12 Jun 2004 17:31:06 +0100 (BST)
Received: from fep01-mail.bloor.is.net.cable.rogers.com ([IPv6:::ffff:66.185.86.71]:2899
	"EHLO fep01-mail.bloor.is.net.cable.rogers.com") by linux-mips.org
	with ESMTP id <S8225984AbUFLQbC>; Sat, 12 Jun 2004 17:31:02 +0100
Received: from ieee.org ([24.157.59.167]) by web01-imail.rogers.com
          (InterMail vM.5.01.05.12 201-253-122-126-112-20020820) with ESMTP
          id <20040612162906.BAES278675.web01-imail.rogers.com@ieee.org>
          for <linux-mips@linux-mips.org>; Sat, 12 Jun 2004 12:29:06 -0400
Message-ID: <40CB2FAF.3050807@ieee.org>
Date: Sat, 12 Jun 2004 12:30:39 -0400
From: Charles Eidsness <charles.eidsness@ieee.org>
Reply-To: charles.eidsness@ieee.org
User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: linux-mips@linux-mips.org
Subject: Au1000 AC97 ALSA Driver
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Authentication-Info: Submitted using SMTP AUTH PLAIN at web01-imail.rogers.com from [24.157.59.167] using ID <charles.eidsness@rogers.com> at Sat, 12 Jun 2004 12:29:04 -0400
Return-Path: <charles.eidsness@ieee.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: 5295
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: charles.eidsness@ieee.org
Precedence: bulk
X-list: linux-mips

I've been working on an ALSA driver for the Au1000 processor AC'97 port. 
Specifically for the DBAu1000 Merlot eval card. It seems to be working 
in OSS emulation mode, I'm having a few problems setting up my system to 
work in ALSA native mode, and it contains only a minimum of features. 
i.e. it's still a work in progress, but I thought there may be someone 
else out there interested in it.

I've posted a patch that should add a mips sub-directory in the sound 
directory of the 2.6.6 kernel and add an au1000 sound option to the 
kernel configuration menu here: 
http://members.rogers.com/charles.eidsness/au1000_alsa.patch

Alternately you can find just the source code here:
http://members.rogers.com/charles.eidsness/au1000.c

Cheers,
Charles


From dennis@pcde.inka.de Sun Jun 13 01:07:32 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 13 Jun 2004 01:07:36 +0100 (BST)
Received: from quechua.inka.de ([IPv6:::ffff:193.197.184.2]:56234 "EHLO
	mail.inka.de") by linux-mips.org with ESMTP id <S8225238AbUFMAHc>;
	Sun, 13 Jun 2004 01:07:32 +0100
Received: from pcde.inka.de (uucp@[127.0.0.1])
	by mail.inka.de with uucp (rmailwrap 0.5) 
	id 1BZIX4-0000EE-00; Sun, 13 Jun 2004 02:07:30 +0200
Received: by aton.pcde.inka.de (Postfix, from userid 1001)
	id 428761E5C7; Sun, 13 Jun 2004 02:04:52 +0200 (CEST)
Date: Sun, 13 Jun 2004 02:04:52 +0200
From: Dennis Grevenstein <dennis@pcde.inka.de>
To: linux-mips@linux-mips.org
Subject: network problems with cobalt raq2
Message-ID: <20040613000452.GA3861@aton.pcde.inka.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.4.1i
Return-Path: <dennis@pcde.inka.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: 5296
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: dennis@pcde.inka.de
Precedence: bulk
X-list: linux-mips

Hi,

I've got some problems with my raq2. I want to set up the machine
as an internet gateway, because it can be perfectly silent if
you change that little fan.
The problem is that network performance is extremely bad.
I can transfer about 1MB/s at the very best. When it runs as
a masquerading router for my internal network performance
goes down even more. I can now ftp about 64kb/s to the raq.
Of course, I didn't expect that this little CPU would be a killer
router, but:
tessa:~# uptime
 02:01:21 up 55 min,  1 user,  load average: 0.00, 0.00, 0.00

There is essentially no load.This machine is about 95% idle.

I'm running Debian and the standard 2.4.26-r5k-cobalt.
I could not compile the current CVS kernel, but any hints
are greatly appreciated.

TIA
Dennis

-- 
de-moc-ra-cy (di mok' ra see) n.
Three wolves and a sheep voting on what's for dinner.

From pete_popov@yahoo.com Sun Jun 13 06:04:41 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 13 Jun 2004 06:04:46 +0100 (BST)
Received: from smtp808.mail.sc5.yahoo.com ([IPv6:::ffff:66.163.168.187]:49062
	"HELO smtp808.mail.sc5.yahoo.com") by linux-mips.org with SMTP
	id <S8224915AbUFMFEl>; Sun, 13 Jun 2004 06:04:41 +0100
Received: from unknown (HELO ?10.2.2.68?) (ppopov@pacbell.net@63.194.214.47 with plain)
  by smtp808.mail.sc5.yahoo.com with SMTP; 13 Jun 2004 05:04:34 -0000
Subject: Re: Au1000 AC97 ALSA Driver
From: Pete Popov <pete_popov@yahoo.com>
To: charles.eidsness@ieee.org
Cc: linux-mips@linux-mips.org
In-Reply-To: <40CB2FAF.3050807@ieee.org>
References: <40CB2FAF.3050807@ieee.org>
Content-Type: text/plain
Organization: 
Message-Id: <1087103071.1432.3.camel@thinkpad>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.2.2 (1.2.2-4) 
Date: 12 Jun 2004 22:04:31 -0700
Content-Transfer-Encoding: 7bit
Return-Path: <pete_popov@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: 5297
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: pete_popov@yahoo.com
Precedence: bulk
X-list: linux-mips

On Sat, 2004-06-12 at 09:30, Charles Eidsness wrote:
> I've been working on an ALSA driver for the Au1000 processor AC'97 port. 
> Specifically for the DBAu1000 Merlot eval card. It seems to be working 
> in OSS emulation mode, I'm having a few problems setting up my system to 
> work in ALSA native mode, and it contains only a minimum of features. 
> i.e. it's still a work in progress, but I thought there may be someone 
> else out there interested in it.
> 
> I've posted a patch that should add a mips sub-directory in the sound 
> directory of the 2.6.6 kernel and add an au1000 sound option to the 
> kernel configuration menu here: 
> http://members.rogers.com/charles.eidsness/au1000_alsa.patch
> 
> Alternately you can find just the source code here:
> http://members.rogers.com/charles.eidsness/au1000.c

Great -- let me know when the driver is ready to be checked in :)

Pete


From geert@linux-m68k.org Sun Jun 13 09:33:50 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 13 Jun 2004 09:34:01 +0100 (BST)
Received: from witte.sonytel.be ([IPv6:::ffff:80.88.33.193]:14244 "EHLO
	witte.sonytel.be") by linux-mips.org with ESMTP id <S8225287AbUFMIdu>;
	Sun, 13 Jun 2004 09:33:50 +0100
Received: from waterleaf.sonytel.be (localhost [127.0.0.1])
	by witte.sonytel.be (8.12.10/8.12.10) with ESMTP id i5D8XDXK017736;
	Sun, 13 Jun 2004 10:33:13 +0200 (MEST)
Date: Sun, 13 Jun 2004 10:33:13 +0200 (MEST)
From: Geert Uytterhoeven <geert@linux-m68k.org>
To: David Daney <ddaney@avtrex.com>
cc: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>, cgd@broadcom.com,
	Ralf Baechle <ralf@linux-mips.org>,
	Linux/MIPS Development <linux-mips@linux-mips.org>,
	binutils@sources.redhat.com
Subject: Re: [Patch] (revised patch) / 0 should send SIGFPE not SIGTRAP 
In-Reply-To: <40CA1FE3.9030507@avtrex.com>
Message-ID: <Pine.GSO.4.58.0406131032350.85@waterleaf.sonytel.be>
References: <40C9F5A4.2050606@avtrex.com> <40C9F5FE.8030607@avtrex.com>
 <40C9F7F0.50501@avtrex.com> <Pine.LNX.4.55.0406112039040.13062@jurand.ds.pg.gda.pl>
 <mailpost.1086981251.16853@news-sj1-1> <yov57juduc7q.fsf@ldt-sj3-010.sj.broadcom.com>
 <Pine.LNX.4.55.0406112133380.13062@jurand.ds.pg.gda.pl> <40CA1B35.6010603@avtrex.com>
 <40CA1FE3.9030507@avtrex.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: 5299
X-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: 649
Lines: 20

On Fri, 11 Jun 2004, David Daney wrote:
> David Daney wrote:
> > How about the attached (lightly tested) patch?
> >
> I will quit sending patches after this one.  It is equivalent to the
> previous version, except it uses the symbolic names of the break codes
> instead of the numeric values.

Please send one more, where you use `diff -up' :-)

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 MAILER-DAEMON Sun Jun 13 21:37:03 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 13 Jun 2004 21:37:09 +0100 (BST)
Received: from mk-smarthost-5.mail.uk.tiscali.com ([IPv6:::ffff:212.74.114.43]:61456
	"EHLO mk-smarthost-5.mail.uk.tiscali.com") by linux-mips.org
	with ESMTP id <S8225905AbUFMUhD>; Sun, 13 Jun 2004 21:37:03 +0100
Received: from mk-cpfront-11.mail.uk.tiscali.com ([212.74.114.54]:33601 helo=mk-cpfrontend.uk.tiscali.com)
	by mk-smarthost-5.mail.uk.tiscali.com with esmtp (Exim 4.30)
	id 1BZbip-0006TT-5E
	for linux-mips@linux-mips.org; Sun, 13 Jun 2004 21:36:55 +0100
Received: by mk-cpfrontend.uk.tiscali.com (7.0.024.3-1) id 40C7289C0059185B for linux-mips@linux-mips.org; Sun, 13 Jun 2004 20:36:56 +0000
From: Mail Delivery Service <postmaster@uk.tiscali.com>
Subject: Delivery Status Notification
To: linux-mips@linux-mips.org
Date: Sun, 13 Jun 2004 20:36:55 +0000
Message-ID: <40C7289C00591858@mk-cpfrontend-11.mail.uk.tiscali.com>
MIME-Version: 1.0
Content-Type: Multipart/Report; report-type=delivery-status; boundary="========/40C7289C00591857/mk-cpfrontend.uk.tiscali.com"
Return-Path: <>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 5300
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: postmaster@uk.tiscali.com
Precedence: bulk
X-list: linux-mips

This multi-part MIME message contains a Delivery Status Notification.
If you can see this text, your mail client may not be able to understand MIME
formatted messages or DSNs (see RFC 2045 through 2049 for general MIME
information and RFC 1891 through 1894 for DSN specific information).

--========/40C7289C00591857/mk-cpfrontend.uk.tiscali.com
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 8bit

 - These recipients of your message have been processed by the mail server:
captain.carrott@lineone.net; Failed; 5.2.2 (mailbox full)



--========/40C7289C00591857/mk-cpfrontend.uk.tiscali.com
Content-Type: Message/Delivery-Status

Reporting-MTA: dns; mk-cpfrontend.uk.tiscali.com
Received-from-MTA: dns; lsanca1-ar1-4-12-013-080.dsl-verizon.net (4.12.13.80)
Arrival-Date: Sun, 13 Jun 2004 20:36:55 +0000

Final-Recipient: rfc822; captain.carrott@lineone.net
Action: Failed
Status: 5.2.2 (mailbox full)

--========/40C7289C00591857/mk-cpfrontend.uk.tiscali.com
Content-Type: Message/RFC822

Return-Path: <linux-mips@linux-mips.org>
Received: from lsanca1-ar1-4-12-013-080.dsl-verizon.net (4.12.13.80) by mk-cpfrontend.uk.tiscali.com (7.0.024.3-1)
        id 40C7289C00591857 for captain.carrott@lineone.net; Sun, 13 Jun 2004 20:36:55 +0000
Received: from 175.30.45.132 by 4.12.13.80; Sun, 13 Jun 2004 18:34:21 -0300
Message-ID: <YTLLYROPUPPLUVLJVFXZGUY@msn.com>
From: "admin@ns.edu.gu" <eug@rigel.infonex.com>
Reply-To: "skrishnan@navini.com" <edi@ka.linux.de>
To: captain.carrott@lineone.net
Subject: http://finance.yahoo.com/q?s=CFGC.PK
Date: Mon, 14 Jun 2004 00:31:21 +0300
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="--00153862427203101"
X-Priority: 3
X-MSMail-Priority: Normal

----00153862427203101
Content-Type: text/plain;
Content-Transfer-Encoding: base64

ICAgICAgICAgICBHcmVhdCBBbm5vdW5jZW1lbnQgZnJvbSBTQldMDQoNClNCV2wgSGFzIEJl
ZW4gR3JhbnRlZCBBbm90aGVyIEZDQyAyM0dIeiBPcGVyYXRpbmcgTGljZW5zZSBpbiBMYXMg
VmVnYXMNCg0KICAgICAgICAgICAgICAgICAgICAgICAgIEdST1VORCBCUkVBS0lORyBORVdT
DQogICAgICAgICAgIA0KU0JXbCBIYXMgQmVlbiBHcmFudGVkIEFub3RoZXIgRkNDIDIzR0h6
IE9wZXJhdGluZyBMaWNlbnNlIGluIExhcyBWZWdhcw0KDQoNClJlYWQgdGhlIG5ld3MgYmVs
b3cgLSBXZSBiZWxpZXZlIHRoaXMgZXhjaXRpbmcgbmV3cyBpbiBhZGRpdGlvbiB0byB0aGUg
YmlnIFBSDQpjYW1wYWlnbiBpbiB0aGUgbmV4dCA1IGRheXMgd2lsbCBtYWtlIFNCV0wgbW92
ZSB1cCBhbmQgdXAgYW5kIHVwLi4uLg0KDQogICAgICAgICAgICAgICAgDQogIEV4cGVjdCBI
dWdlIENvdmVyYWdlIC0gV2UgYmVsaWV2ZSB0aGlzIHN0b2NrIHdpbGwgRXhwbG9kZSBvbiBN
b25kYXkgSnVuZSAxMHRoDQoNCg0KU0JXTCB3aWxsIGJlIHByb2ZpbGVkIGluIDEwLTE1IGlu
dmVzdG9yIG5ld3NsZXR0ZXJzIG92ZXIgdGhlIHdlZWtlbmQuLiBBY3QgdG9kYXkgYW5kDQpz
ZWN1cmUgeW91ciBwb3NpdGlvbiBUb2RheQ0KDQoNCis+Kz4rPiBDb21wYW55IFByb2ZpbGUg
DQoNClNreUJyaWRnZSBXaXJlbGVzcyBJbmMuIA0KU3ltYm9sOiBCQjogU0JXTA0KQ3VycmVu
dCBQcmljZTogJDAuMDMNCg0KSW4gb3VyIG9waW5pb24gdGhlIHN0b2NrIHByaWNlIGNvdWxk
IGdvIHRvICQwLjEzIC0gMC4xNCBpbiB0aGUgbmV4dCAzLTUgZGF5cw0KSW4gb3VyIG9waW5p
b24gdGhlIHN0b2NrIHByaWNlIGNvdWxkIGdvIHRvICQwLjE2IC0gMC4xOCBpbiB0aGUgbmV4
dCAxMCAgZGF5cw0KDQpSZWFkIHRoZSBleGNpdGluZyBuZXdzIGJlbG93DQoNCi0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0NCg0KU2t5QnJpZGdlIFdpcmVsZXNzIEluYy4gaXMgcG9zaXRpb25lZCB0
byBwcm9kdWNlIHNvbGlkIGdyb3d0aCwgcmFwaWRseSBpbmNyZWFzaW5nIHJldmVudWVzIGFu
ZCBpbXByZXNzaXZlIHNoYXJlIHZhbHVlIGdhaW5zLiBGb2N1c2VkIG9uIEhpZ2ggR3Jvd3Ro
IEFyZWFzIGluIEhpZ2ggR3Jvd3RoIFNlY3RvcnMsIHRoZSBjb21wYW55IGlzIGZvY3VzZWQg
b24gaGlnaC1zcGVlZCBmaXhlZCB3aXJlbGVzcyBJbnRlcm5ldCBhY2Nlc3MgdG8gYnVzaW5l
c3NlcyBhbmQgY29tbXVuaXRpZXMgaW4gc29tZSBvZiB0aGUgbmF0aW9uJ3MgZmFzdGVzdC1n
cm93aW5nIG1ldHJvcG9saXRhbiBtYXJrZXRzLCB3aXRoIGluaXRpYWwgZWZmb3J0cyBpbiBM
YXMgVmVnYXMsIGEgdmVyeSBkeW5hbWljIG1hcmtldC4gV2lyZWxlc3Mgc2VydmljZSBhbGxv
d3MgY3VzdG9tZXJzIHRvIHVzZSB0aGUgSW50ZXJuZXQgYXQgc3BlZWRzIHVwIHRvIDUwIHRp
bWVzIGZhc3RlciB0aGFuIHRvZGF5J3MgZGlhbC11cCBtb2RlbXMuIEFzIHRoZSBkZXNpcmUg
Zm9yIG1vcmUgaW5mb3JtYXRpb24sIGNvbW11bmljYXRpb24gYW5kIGVudGVydGFpbm1lbnQg
Z3Jvd3MsIHNvIGRvZXMgdGhlIG5lZWQgZm9yIHNvbHV0aW9ucyB0byBwcm92aWRlIHRoZXNl
IHNlcnZpY2VzIGF0IGhpZ2ggc3BlZWQgYW5kIGF0IGFuIGFjY2VwdGFibGUgY29zdC4gU2t5
QnJpZGdlIFdpcmVsZXNzIGZpeGVkIHdpcmVsZXNzIGJyb2FkYmFuZCBhY2Nlc3MgcHJvdmlk
ZXMganVzdCB0aGF0LCBvZmZlcmluZyBzb2x1dGlvbnMgdGhhdCBtZWV0IHRoZSByZXF1aXJl
bWVudHMgb2YgYnVzaW5lc3NlcyBhbmQgZW50ZXJwcmlzZXMgYWxpa2UsIGF0IGEgZnJhY3Rp
b24gb2YgdGhlIGNvc3Qgb2Ygd2lyZWxpbmUgVC0xIGRhdGEgY29ubmVjdGlvbnMsIGFuZCBj
YW4gYmUgaW5zdGFsbGVkIGFuZCBvcGVyYXRpb25hbCBpbiBhIG11Y2ggc2hvcnRlciB0aW1l
IHRoYW4gb3RoZXIgZGF0YSBzb2x1dGlvbnMuIFdpcmVsZXNzIHJlcHJlc2VudHMgb25lIG9m
IHRvZGF5J3MgZmFzdGVzdC1ncm93aW5nIGluZHVzdHJ5IHNlY3RvcnMuIE5vIGFzc3VyYW5j
ZSBjYW4gYmUgbWFkZSB0aGF0IFNreUJyaWRnZSBXaXJlbGVzcyB3aWxsIGFjY29tcGxpc2gg
aXRzIGdvYWxzLiANCg0KDQoNCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09DQogICAg
ICAqIE5FV1MgUkVMRUFTRSAgKiANCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09DQoN
CkxBUyBWRUdBUywgSnVuIDgsIDIwMDQgKEJVU0lORVNTIFdJUkUpIC0tIFNreUJyaWRnZSBX
aXJlbGVzcyBJbmMuIChTQldMKSBhbm5vdW5jZWQgdGhlIEZDQyBoYXMgZ3JhbnRlZCB0aGUg
Y29tcGFueSBhbm90aGVyIDIzR0h6IG9wZXJhdGluZyBsaWNlbnNlIHRvIGNvbnRpbnVlIHRo
ZSBleHBhbnNpb24gb2YgaXRzIGhpZ2gtc3BlZWQgd2lyZWxlc3MgYmFja2JvbmUgaW4gTGFz
IFZlZ2FzLiBUaGlzIDIzR0h6IGZyZXF1ZW5jeSBvcGVyYXRpbmcgbGljZW5zZSB3aWxsIGFs
bG93IGZvciBhIG1vcmUgcmVsaWFibGUgbmV0d29yayBiYWNrYm9uZSB0cmFuc3BvcnQsIGFz
IHdlbGwgYXMgaW5jcmVhc2UgbmV0d29yayBjYXBhY2l0eSBncmVhdGx5IGJ5IGFsbG93aW5n
IGFkZGl0aW9uYWwgQWNjZXNzIFBvaW50cyB0byBiZSBpbnN0YWxsZWQgYXQgdGhlIHZhcmlv
dXMgc2l0ZXMgU2t5QnJpZGdlIFdpcmVsZXNzIEluYy4gaGFzIGFyb3VuZCBMYXMgVmVnYXMu
IEphc29uIE5laWJlcmdlciwgU2t5QnJpZGdlIFdpcmVsZXNzIEluYy4gcHJlc2lkZW50LCBz
dGF0ZWQsICJUaGlzIDIzR0h6IGJhY2tib25lIGNvbm5lY3Rpb24gd2lsbCByZXBsYWNlIGFu
IHVubGljZW5zZWQgYW5kIGxvd2VyIGNhcGFjaXR5IGxpbmsgYmV0d2VlbiB0aGUgc2l0ZSBh
dCB0aGUgTGFzIFZlZ2FzIEhpbHRvbiBhbmQgb3VyIEZyb250aWVyIFJhZGlvIHNpdGUgaW4g
dGhlIHNvdXRoIHNlY3Rpb24gb2YgTGFzIFZlZ2FzLiIgSGUgZnVydGhlciBhZGRlZCwgIldp
dGggdGhpcyBsaWNlbnNlIGluIHBsYWNlIHdlIHdpbGwgYmUgaW5zdGFsbGluZyB0aGUgbmV4
dCAyM0dIeiBQcm94aW0gVHN1bmFtaSByYWRpb3Mgd2l0aGluIHRoZSBuZXh0IDE1IHRvIDMw
IGRheXMsIGFuZCB3aWxsIGJlIGFkZGluZyBhZGRpdGlvbmFsIEFjY2VzcyBQb2ludHMgdG8g
dGhlc2Ugc2l0ZXMsIGZvciBpbmNyZWFzZWQgY3VzdG9tZXIgY2FwYWNpdHkuIiANCg0KDQoN
Cj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09DQor
Pis+Kz4gRElTQ0xBSU1FUiANCg0KSW5mb3JtYXRpb24gd2l0aGluIHRoaXMgZW1haWwgY29u
dGFpbnMgImZvcndhcmQgbG9va2luZyBzdGF0ZW1lbnRzIiB3aXRoaW4gdGhlIG1lYW5pbmcg
b2YgU2VjdGlvbiAyN0Egb2YgdGhlIFNlY3VyaXRpZXMgQWN0IG9mIDE5MzMgYW5kIFNlY3Rp
b24gMjFCIG9mIHRoZSBTZWN1cml0aWVzIEV4Y2hhbmdlIEFjdCBvZiAxOTM0LiBBbnkgc3Rh
dGVtZW50cyB0aGF0IGV4cHJlc3Mgb3IgaW52b2x2ZSBkaXNjdXNzaW9ucyB3aXRoIHJlc3Bl
Y3QgdG8gcHJlZGljdGlvbnMsIGdvYWxzLCBleHBlY3RhdGlvbnMsIGJlbGllZnMsIHBsYW5z
LCBwcm9qZWN0aW9ucywgb2JqZWN0aXZlcywgYXNzdW1wdGlvbnMgb3IgZnV0dXJlIGV2ZW50
cyBvciBwZXJmb3JtYW5jZSBhcmUgbm90IHN0YXRlbWVudHMgb2YgaGlzdG9yaWNhbCBmYWN0
IGFuZCBtYXkgYmUgImZvcndhcmQgbG9va2luZyBzdGF0ZW1lbnRzLiINCiANCkZvcndhcmQg
bG9va2luZyBzdGF0ZW1lbnRzIGFyZSBiYXNlZCBvbiBleHBlY3RhdGlvbnMsIGVzdGltYXRl
cyBhbmQgcHJvamVjdGlvbnMgYXQgdGhlIHRpbWUgdGhlIHN0YXRlbWVudHMgYXJlIG1hZGUg
dGhhdCBpbnZvbHZlIGEgbnVtYmVyIG9mIHJpc2tzIGFuZCB1bmNlcnRhaW50aWVzIHdoaWNo
IGNvdWxkIGNhdXNlIGFjdHVhbCByZXN1bHRzIG9yIGV2ZW50cyB0byBkaWZmZXIgbWF0ZXJp
YWxseSBmcm9tIHRob3NlIHByZXNlbnRseSBhbnRpY2lwYXRlZC4gRm9yd2FyZCBsb29raW5n
IHN0YXRlbWVudHMgaW4gdGhpcyBhY3Rpb24gbWF5IGJlIGlkZW50aWZpZWQgdGhyb3VnaCB0
aGUgdXNlIG9mIHdvcmRzIHN1Y2ggYXM6ICJpbiBvdXIgb3BpbmlvbiIsInByb2plY3RzIiwg
ImZvcmVzZWUiLCAiZXhwZWN0cyIsICJlc3RpbWF0ZXMsIiAiYmVsaWV2ZXMsIiAidW5kZXJz
dGFuZHMiICJ3aWxsLCIgInBhcnQgb2Y6ICJhbnRpY2lwYXRlcywiIG9yIHRoYXQgYnkgc3Rh
dGVtZW50cyBpbmRpY2F0aW5nIGNlcnRhaW4gYWN0aW9ucyAibWF5LCIgImNvdWxkLCIgb3Ig
Im1pZ2h0IiBvY2N1ci4gQWxsIGluZm9ybWF0aW9uIHByb3ZpZGVkIHdpdGhpbiB0aGlzIGVt
YWlsIHBlcnRhaW5pbmcgdG8gaW52ZXN0aW5nLCBzdG9ja3MsIHNlY3VyaXRpZXMgbXVzdCBi
ZSB1bmRlcnN0b29kIGFzIGluZm9ybWF0aW9uIHByb3ZpZGVkIGFuZCBub3QgaW52ZXN0bWVu
dCBhZHZpY2UuIHdlIGFkdmlzZSBhbGwgcmVhZGVycyBhbmQgc3Vic2NyaWJlcnMgdG8gc2Vl
ayBhZHZpY2UgZnJvbSBhIHJlZ2lzdGVyZWQgcHJvZmVzc2lvbmFsIHNlY3VyaXRpZXMgcmVw
cmVzZW50YXRpdmUgYmVmb3JlIGRlY2lkaW5nIHRvIHRyYWRlIGluIHN0b2NrcyBmZWF0dXJl
ZCB3aXRoaW4gdGhpcyBlbWFpbC4gTm9uZSBvZiB0aGUgbWF0ZXJpYWwgd2l0aGluIHRoaXMg
cmVwb3J0IHNoYWxsIGJlIGNvbnN0cnVlZCBhcyBhbnkga2luZCBvZiBpbnZlc3RtZW50IGFk
dmljZS4gUGxlYXNlIGhhdmUgaW4gbWluZCB0aGF0IHRoZSBpbnRlcnByZXRhdGlvbiBvZiB0
aGUgd2l0ZXIgb2YgdGhpcyBuZXdzbGV0dGVyIGFib3V0IHRoZSBuZXdzIHB1Ymxpc2hlZCBi
eSB0aGUgY29tcGFueSBkb2VzIG5vdCByZXByZXNlbnQgdGhlIGNvbXBhbnkgb2ZmaWNpYWwg
c3RhdGVtZW50IGFuZCBpbiBmYWN0IG1heSBkaWZmZXIgZnJvbSB0aGUgcmVhbCBtZWFuaW5n
IG9mIHdoYXQgdGhlIG5ld3MgcmVsZWFzZSBtZWFudCB0byBzYXkuIFBsZWFzZSByZWFkIHRo
ZSBuZXdzIHJlbGVhc2UgYnkgeW91cnNlbGYgYW5kIGp1ZGdlIGJ5IHlvdXJzZWxmIGFib3V0
IHRoZSBkZXRhaWxzIGluIGl0Lg0KIA0KSW4gY29tcGxpYW5jZSB3aXRoIFNlY3Rpb24gMTco
YiksIHdlIGRpc2Nsb3NlIHRoZSBob2xkaW5nIG9mIFNCV0wgc2hhcmVzIHByaW9yIHRvIHRo
ZSBwdWJsaWNhdGlvbiBvZiB0aGlzIHJlcG9ydC4gQmUgYXdhcmUgb2YgYW4gaW5oZXJlbnQg
Y29uZmxpY3Qgb2YgaW50ZXJlc3QgcmVzdWx0aW5nIGZyb20gc3VjaCBob2xkaW5ncyBkdWUg
dG8gb3VyIGludGVudCB0byBwcm9maXQgZnJvbSB0aGUgbGlxdWlkYXRpb24gb2YgdGhlc2Ug
c2hhcmVzLiBTaGFyZXMgbWF5IGJlIHNvbGQgYXQgYW55IHRpbWUsIGV2ZW4gYWZ0ZXIgcG9z
aXRpdmUgc3RhdGVtZW50cyBoYXZlIGJlZW4gbWFkZSByZWdhcmRpbmcgdGhlIGFib3ZlIGNv
bXBhbnkuIFNpbmNlIHdlIG93biBzaGFyZXMsIHRoZXJlIGlzIGFuIGluaGVyZW50IGNvbmZs
aWN0IG9mIGludGVyZXN0IGluIG91ciBzdGF0ZW1lbnRzIGFuZCBvcGluaW9ucy4gUmVhZGVy
cyBvZiB0aGlzIHB1YmxpY2F0aW9uIGFyZSBjYXV0aW9uZWQgbm90IHRvIHBsYWNlIHVuZHVl
IHJlbGlhbmNlIG9uIGZvcndhcmQtbG9va2luZyBzdGF0ZW1lbnRzLCB3aGljaCBhcmUgYmFz
ZWQgb24gY2VydGFpbiBhc3N1bXB0aW9ucyBhbmQgZXhwZWN0YXRpb25zIGludm9sdmluZyB2
YXJpb3VzIHJpc2tzIGFuZCB1bmNlcnRhaW50aWVzLCB0aGF0IGNvdWxkIGNhdXNlIHJlc3Vs
dHMgdG8gZGlmZmVyIG1hdGVyaWFsbHkgZnJvbSB0aG9zZSBzZXQgZm9ydGggaW4gdGhlIGZv
cndhcmQtIGxvb2tpbmcgc3RhdGVtZW50cy4gDQoNClBsZWFzZSBiZSBhZHZpc2VkIHRoYXQg
bm90aGluZyB3aXRoaW4gdGhpcyBlbWFpbCBzaGFsbCBjb25zdGl0dXRlIGEgc29saWNpdGF0
aW9uIG9yIGFuIG9mZmVyIHRvIGJ1eSBvciBzZWxsIGFueSBzZWN1cml0eSBtZW50aW9uZWQg
aGVyZWluLiBUaGlzIG5ld3NsZXR0ZXIgaXMgbmVpdGhlciBhIHJlZ2lzdGVyZWQgaW52ZXN0
bWVudCBhZHZpc29yIG5vciBhZmZpbGlhdGVkIHdpdGggYW55IGJyb2tlciBvciBkZWFsZXIu
IEFsbCBzdGF0ZW1lbnRzIG1hZGUgYXJlIG91ciBleHByZXNzIG9waW5pb24gb25seSBhbmQg
c2hvdWxkIGJlIHRyZWF0ZWQgYXMgc3VjaC4gV2UgbWF5IG93biwgYnV5IGFuZCBzZWxsIGFu
eSBzZWN1cml0aWVzIG1lbnRpb25lZCBhdCBhbnkgdGltZS4gVGhpcyByZXBvcnQgaW5jbHVk
ZXMgZm9yd2FyZC1sb29raW5nIHN0YXRlbWVudHMgd2l0aGluIHRoZSBtZWFuaW5nIG9mIFRo
ZSBQcml2YXRlIFNlY3VyaXRpZXMgTGl0aWdhdGlvbiBSZWZvcm0gQWN0IG9mIDE5OTUuIFRo
ZXNlIHN0YXRlbWVudHMgbWF5IGluY2x1ZGUgdGVybXMgYXMgImV4cGVjdCIsICJiZWxpZXZl
IiwgIm1heSIsICJ3aWxsIiwgIm1vdmUiLCJ1bmRlcnZhbHVlZCIgYW5kICJpbnRlbmQiIG9y
IHNpbWlsYXIgdGVybXMuIFRoaXMgbmV3c2xldHRlciB3YXMgcGFpZCAkMTI1MDAgZnJvbSB0
aGlyZCBwYXJ0eSB0byBzZW5kIHRoaXMgcmVwb3J0LiBQTEVBU0UgRE8gWU9VUiBPV04gRFVF
IERJTElHRU5DRSBCRUZPUkUgSU5WRVNUSU5HIElOIEFOWSBQUk9GSUxFRCBDT01QQU5ZLiBZ
b3UgbWF5IGxvc2UgbW9uZXkgZnJvbSBpbnZlc3RpbmcgaW4gUGVubnkgU3RvY2tzLiANCi0t
LS0tLS0tLS0tLS0tLS0tLS0tLQ0K

----00153862427203101--


--========/40C7289C00591857/mk-cpfrontend.uk.tiscali.com--


From mailgateway@airtransat.com Sun Jun 13 22:02:25 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 13 Jun 2004 22:02:30 +0100 (BST)
Received: from pop.airtransat.com ([IPv6:::ffff:207.96.246.197]:35479 "EHLO
	atymxunix02.airtransat.com") by linux-mips.org with ESMTP
	id <S8225905AbUFMVCZ>; Sun, 13 Jun 2004 22:02:25 +0100
Received: from airtransat.com (esafe.airtransat.com [10.11.20.5])
	by atymxunix02.airtransat.com (8.11.6+Sun/8.11.6) with SMTP id i5DL2G513207
	for <linux-mips@linux-mips.org>; Sun, 13 Jun 2004 17:02:17 -0400 (EDT)
Date: Sun, 13 Jun 2004 17:02:17 -0400 (EDT)
Message-Id: <200406132102.i5DL2G513207@atymxunix02.airtransat.com>
To: linux-mips@linux-mips.org
From: mailgateway@airtransat.com
Subject: Returned mail: unreachable recipients: guru@airtransat.com,joanne@airtransat.com,jody@airtransat.com
MIME-Version: 1.0
Content-Type: multipart/report; report-type=delivery-status;
	boundary="NextMessagePart_002_59468_374863/1087160498.1087166792"
Return-Path: <mailgateway@airtransat.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: 5301
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: mailgateway@airtransat.com
Precedence: bulk
X-list: linux-mips

--NextMessagePart_002_59468_374863/1087160498.1087166792
Content-type: text/plain

The original message was received at Sun Jun 13 17:01:12 2004
Likely reason for failure: 550 5.1.1 <jody@airtransat.com>... User unknown
_____________________________________________________________



--NextMessagePart_002_59468_374863/1087160498.1087166792
content-type: message/delivery-status

Reporting-MTA: dns; mailgateway@airtransat.com

Final-Recipient: RFC822;guru@airtransat.com,joanne@airtransat.com,jody@airtransat.com
Action: failed
Status: 5.0.0 (permanent failure)
Diagnostic-Code: smtp;550 5.1.1 <jody@airtransat.com>... User unknown

--NextMessagePart_002_59468_374863/1087160498.1087166792
Content-type: message/rfc822

Received: through eSafe SMTP Relay 1087142342; Sun Jun 13 17:01:34 2004
Received: from 186.2.126.128 by 68.145.23.177; Sun, 13 Jun 2004 20:56:24 -0100
Message-ID: <AJGPRPHZBDEMXBBWXWHBLJRQA@msn.com>
From: "contacts@lencom.com" <arlinmat@fem.unicamp.br>
Reply-To: "woszcz17@o2.pl" <s.shepard@hill.com>
To: guru@airtransat.com, joanne@airtransat.com, jody@airtransat.com
Subject: 512 West 12th Avenue
Date: Sun, 13 Jun 2004 19:01:24 -0300
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="--444559853917708754"
X-Priority: 3
X-MSMail-Priority: Normal

----444559853917708754
Content-Type: text/plain;
Content-Transfer-Encoding: base64

ICAgICAgICAgICBHcmVhdCBBbm5vdW5jZW1lbnQgZnJvbSBTQldMDQoNClNCV2wgSGFzIEJlZW4g
R3JhbnRlZCBBbm90aGVyIEZDQyAyM0dIeiBPcGVyYXRpbmcgTGljZW5zZSBpbiBMYXMgVmVnYXMN
Cg0KICAgICAgICAgICAgICAgICAgICAgICAgIEdST1VORCBCUkVBS0lORyBORVdTDQogICAgICAg
ICAgIA0KU0JXbCBIYXMgQmVlbiBHcmFudGVkIEFub3RoZXIgRkNDIDIzR0h6IE9wZXJhdGluZyBM
aWNlbnNlIGluIExhcyBWZWdhcw0KDQoNClJlYWQgdGhlIG5ld3MgYmVsb3cgLSBXZSBiZWxpZXZl
IHRoaXMgZXhjaXRpbmcgbmV3cyBpbiBhZGRpdGlvbiB0byB0aGUgYmlnIFBSDQpjYW1wYWlnbiBp
biB0aGUgbmV4dCA1IGRheXMgd2lsbCBtYWtlIFNCV0wgbW92ZSB1cCBhbmQgdXAgYW5kIHVwLi4u
Lg0KDQogICAgICAgICAgICAgICAgDQogIEV4cGVjdCBIdWdlIENvdmVyYWdlIC0gV2UgYmVsaWV2
ZSB0aGlzIHN0b2NrIHdpbGwgRXhwbG9kZSBvbiBNb25kYXkgSnVuZSAxMHRoDQoNCg0KU0JXTCB3
aWxsIGJlIHByb2ZpbGVkIGluIDEwLTE1IGludmVzdG9yIG5ld3NsZXR0ZXJzIG92ZXIgdGhlIHdl
ZWtlbmQuLiBBY3QgdG9kYXkgYW5kDQpzZWN1cmUgeW91ciBwb3NpdGlvbiBUb2RheQ0KDQoNCis+
Kz4rPiBDb21wYW55IFByb2ZpbGUgDQoNClNreUJyaWRnZSBXaXJlbGVzcyBJbmMuIA0KU3ltYm9s
OiBCQjogU0JXTA0KQ3VycmVudCBQcmljZTogJDAuMDMNCg0KSW4gb3VyIG9waW5pb24gdGhlIHN0
b2NrIHByaWNlIGNvdWxkIGdvIHRvICQwLjEzIC0gMC4xNCBpbiB0aGUgbmV4dCAzLTUgZGF5cw0K
SW4gb3VyIG9waW5pb24gdGhlIHN0b2NrIHByaWNlIGNvdWxkIGdvIHRvICQwLjE2IC0gMC4xOCBp
biB0aGUgbmV4dCAxMCAgZGF5cw0KDQpSZWFkIHRoZSBleGNpdGluZyBuZXdzIGJlbG93DQoNCi0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0NCg0KU2t5QnJpZGdlIFdpcmVsZXNzIEluYy4gaXMgcG9zaXRpb25lZCB0
byBwcm9kdWNlIHNvbGlkIGdyb3d0aCwgcmFwaWRseSBpbmNyZWFzaW5nIHJldmVudWVzIGFuZCBp
bXByZXNzaXZlIHNoYXJlIHZhbHVlIGdhaW5zLiBGb2N1c2VkIG9uIEhpZ2ggR3Jvd3RoIEFyZWFz
IGluIEhpZ2ggR3Jvd3RoIFNlY3RvcnMsIHRoZSBjb21wYW55IGlzIGZvY3VzZWQgb24gaGlnaC1z
cGVlZCBmaXhlZCB3aXJlbGVzcyBJbnRlcm5ldCBhY2Nlc3MgdG8gYnVzaW5lc3NlcyBhbmQgY29t
bXVuaXRpZXMgaW4gc29tZSBvZiB0aGUgbmF0aW9uJ3MgZmFzdGVzdC1ncm93aW5nIG1ldHJvcG9s
aXRhbiBtYXJrZXRzLCB3aXRoIGluaXRpYWwgZWZmb3J0cyBpbiBMYXMgVmVnYXMsIGEgdmVyeSBk
eW5hbWljIG1hcmtldC4gV2lyZWxlc3Mgc2VydmljZSBhbGxvd3MgY3VzdG9tZXJzIHRvIHVzZSB0
aGUgSW50ZXJuZXQgYXQgc3BlZWRzIHVwIHRvIDUwIHRpbWVzIGZhc3RlciB0aGFuIHRvZGF5J3Mg
ZGlhbC11cCBtb2RlbXMuIEFzIHRoZSBkZXNpcmUgZm9yIG1vcmUgaW5mb3JtYXRpb24sIGNvbW11
bmljYXRpb24gYW5kIGVudGVydGFpbm1lbnQgZ3Jvd3MsIHNvIGRvZXMgdGhlIG5lZWQgZm9yIHNv
bHV0aW9ucyB0byBwcm92aWRlIHRoZXNlIHNlcnZpY2VzIGF0IGhpZ2ggc3BlZWQgYW5kIGF0IGFu
IGFjY2VwdGFibGUgY29zdC4gU2t5QnJpZGdlIFdpcmVsZXNzIGZpeGVkIHdpcmVsZXNzIGJyb2Fk
YmFuZCBhY2Nlc3MgcHJvdmlkZXMganVzdCB0aGF0LCBvZmZlcmluZyBzb2x1dGlvbnMgdGhhdCBt
ZWV0IHRoZSByZXF1aXJlbWVudHMgb2YgYnVzaW5lc3NlcyBhbmQgZW50ZXJwcmlzZXMgYWxpa2Us
IGF0IGEgZnJhY3Rpb24gb2YgdGhlIGNvc3Qgb2Ygd2lyZWxpbmUgVC0xIGRhdGEgY29ubmVjdGlv
bnMsIGFuZCBjYW4gYmUgaW5zdGFsbGVkIGFuZCBvcGVyYXRpb25hbCBpbiBhIG11Y2ggc2hvcnRl
ciB0aW1lIHRoYW4gb3RoZXIgZGF0YSBzb2x1dGlvbnMuIFdpcmVsZXNzIHJlcHJlc2VudHMgb25l
IG9mIHRvZGF5J3MgZmFzdGVzdC1ncm93aW5nIGluZHVzdHJ5IHNlY3RvcnMuIE5vIGFzc3VyYW5j
ZSBjYW4gYmUgbWFkZSB0aGF0IFNreUJyaWRnZSBXaXJlbGVzcyB3aWxsIGFjY29tcGxpc2ggaXRz
IGdvYWxzLiANCg0KDQoNCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09DQogICAgICAqIE5F
V1MgUkVMRUFTRSAgKiANCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09DQoNCkxBUyBWRUdB
UywgSnVuIDgsIDIwMDQgKEJVU0lORVNTIFdJUkUpIC0tIFNreUJyaWRnZSBXaXJlbGVzcyBJbmMu
IChTQldMKSBhbm5vdW5jZWQgdGhlIEZDQyBoYXMgZ3JhbnRlZCB0aGUgY29tcGFueSBhbm90aGVy
IDIzR0h6IG9wZXJhdGluZyBsaWNlbnNlIHRvIGNvbnRpbnVlIHRoZSBleHBhbnNpb24gb2YgaXRz
IGhpZ2gtc3BlZWQgd2lyZWxlc3MgYmFja2JvbmUgaW4gTGFzIFZlZ2FzLiBUaGlzIDIzR0h6IGZy
ZXF1ZW5jeSBvcGVyYXRpbmcgbGljZW5zZSB3aWxsIGFsbG93IGZvciBhIG1vcmUgcmVsaWFibGUg
bmV0d29yayBiYWNrYm9uZSB0cmFuc3BvcnQsIGFzIHdlbGwgYXMgaW5jcmVhc2UgbmV0d29yayBj
YXBhY2l0eSBncmVhdGx5IGJ5IGFsbG93aW5nIGFkZGl0aW9uYWwgQWNjZXNzIFBvaW50cyB0byBi
ZSBpbnN0YWxsZWQgYXQgdGhlIHZhcmlvdXMgc2l0ZXMgU2t5QnJpZGdlIFdpcmVsZXNzIEluYy4g
aGFzIGFyb3VuZCBMYXMgVmVnYXMuIEphc29uIE5laWJlcmdlciwgU2t5QnJpZGdlIFdpcmVsZXNz
IEluYy4gcHJlc2lkZW50LCBzdGF0ZWQsICJUaGlzIDIzR0h6IGJhY2tib25lIGNvbm5lY3Rpb24g
d2lsbCByZXBsYWNlIGFuIHVubGljZW5zZWQgYW5kIGxvd2VyIGNhcGFjaXR5IGxpbmsgYmV0d2Vl
biB0aGUgc2l0ZSBhdCB0aGUgTGFzIFZlZ2FzIEhpbHRvbiBhbmQgb3VyIEZyb250aWVyIFJhZGlv
IHNpdGUgaW4gdGhlIHNvdXRoIHNlY3Rpb24gb2YgTGFzIFZlZ2FzLiIgSGUgZnVydGhlciBhZGRl
ZCwgIldpdGggdGhpcyBsaWNlbnNlIGluIHBsYWNlIHdlIHdpbGwgYmUgaW5zdGFsbGluZyB0aGUg
bmV4dCAyM0dIeiBQcm94aW0gVHN1bmFtaSByYWRpb3Mgd2l0aGluIHRoZSBuZXh0IDE1IHRvIDMw
IGRheXMsIGFuZCB3aWxsIGJlIGFkZGluZyBhZGRpdGlvbmFsIEFjY2VzcyBQb2ludHMgdG8gdGhl
c2Ugc2l0ZXMsIGZvciBpbmNyZWFzZWQgY3VzdG9tZXIgY2FwYWNpdHkuIiANCg0KDQoNCj09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09DQorPis+Kz4gRElT
Q0xBSU1FUiANCg0KSW5mb3JtYXRpb24gd2l0aGluIHRoaXMgZW1haWwgY29udGFpbnMgImZvcndh
cmQgbG9va2luZyBzdGF0ZW1lbnRzIiB3aXRoaW4gdGhlIG1lYW5pbmcgb2YgU2VjdGlvbiAyN0Eg
b2YgdGhlIFNlY3VyaXRpZXMgQWN0IG9mIDE5MzMgYW5kIFNlY3Rpb24gMjFCIG9mIHRoZSBTZWN1
cml0aWVzIEV4Y2hhbmdlIEFjdCBvZiAxOTM0LiBBbnkgc3RhdGVtZW50cyB0aGF0IGV4cHJlc3Mg
b3IgaW52b2x2ZSBkaXNjdXNzaW9ucyB3aXRoIHJlc3BlY3QgdG8gcHJlZGljdGlvbnMsIGdvYWxz
LCBleHBlY3RhdGlvbnMsIGJlbGllZnMsIHBsYW5zLCBwcm9qZWN0aW9ucywgb2JqZWN0aXZlcywg
YXNzdW1wdGlvbnMgb3IgZnV0dXJlIGV2ZW50cyBvciBwZXJmb3JtYW5jZSBhcmUgbm90IHN0YXRl
bWVudHMgb2YgaGlzdG9yaWNhbCBmYWN0IGFuZCBtYXkgYmUgImZvcndhcmQgbG9va2luZyBzdGF0
ZW1lbnRzLiINCiANCkZvcndhcmQgbG9va2luZyBzdGF0ZW1lbnRzIGFyZSBiYXNlZCBvbiBleHBl
Y3RhdGlvbnMsIGVzdGltYXRlcyBhbmQgcHJvamVjdGlvbnMgYXQgdGhlIHRpbWUgdGhlIHN0YXRl
bWVudHMgYXJlIG1hZGUgdGhhdCBpbnZvbHZlIGEgbnVtYmVyIG9mIHJpc2tzIGFuZCB1bmNlcnRh
aW50aWVzIHdoaWNoIGNvdWxkIGNhdXNlIGFjdHVhbCByZXN1bHRzIG9yIGV2ZW50cyB0byBkaWZm
ZXIgbWF0ZXJpYWxseSBmcm9tIHRob3NlIHByZXNlbnRseSBhbnRpY2lwYXRlZC4gRm9yd2FyZCBs
b29raW5nIHN0YXRlbWVudHMgaW4gdGhpcyBhY3Rpb24gbWF5IGJlIGlkZW50aWZpZWQgdGhyb3Vn
aCB0aGUgdXNlIG9mIHdvcmRzIHN1Y2ggYXM6ICJpbiBvdXIgb3BpbmlvbiIsInByb2plY3RzIiwg
ImZvcmVzZWUiLCAiZXhwZWN0cyIsICJlc3RpbWF0ZXMsIiAiYmVsaWV2ZXMsIiAidW5kZXJzdGFu
ZHMiICJ3aWxsLCIgInBhcnQgb2Y6ICJhbnRpY2lwYXRlcywiIG9yIHRoYXQgYnkgc3RhdGVtZW50
cyBpbmRpY2F0aW5nIGNlcnRhaW4gYWN0aW9ucyAibWF5LCIgImNvdWxkLCIgb3IgIm1pZ2h0IiBv
Y2N1ci4gQWxsIGluZm9ybWF0aW9uIHByb3ZpZGVkIHdpdGhpbiB0aGlzIGVtYWlsIHBlcnRhaW5p
bmcgdG8gaW52ZXN0aW5nLCBzdG9ja3MsIHNlY3VyaXRpZXMgbXVzdCBiZSB1bmRlcnN0b29kIGFz
IGluZm9ybWF0aW9uIHByb3ZpZGVkIGFuZCBub3QgaW52ZXN0bWVudCBhZHZpY2UuIHdlIGFkdmlz
ZSBhbGwgcmVhZGVycyBhbmQgc3Vic2NyaWJlcnMgdG8gc2VlayBhZHZpY2UgZnJvbSBhIHJlZ2lz
dGVyZWQgcHJvZmVzc2lvbmFsIHNlY3VyaXRpZXMgcmVwcmVzZW50YXRpdmUgYmVmb3JlIGRlY2lk
aW5nIHRvIHRyYWRlIGluIHN0b2NrcyBmZWF0dXJlZCB3aXRoaW4gdGhpcyBlbWFpbC4gTm9uZSBv
ZiB0aGUgbWF0ZXJpYWwgd2l0aGluIHRoaXMgcmVwb3J0IHNoYWxsIGJlIGNvbnN0cnVlZCBhcyBh
bnkga2luZCBvZiBpbnZlc3RtZW50IGFkdmljZS4gUGxlYXNlIGhhdmUgaW4gbWluZCB0aGF0IHRo
ZSBpbnRlcnByZXRhdGlvbiBvZiB0aGUgd2l0ZXIgb2YgdGhpcyBuZXdzbGV0dGVyIGFib3V0IHRo
ZSBuZXdzIHB1Ymxpc2hlZCBieSB0aGUgY29tcGFueSBkb2VzIG5vdCByZXByZXNlbnQgdGhlIGNv
bXBhbnkgb2ZmaWNpYWwgc3RhdGVtZW50IGFuZCBpbiBmYWN0IG1heSBkaWZmZXIgZnJvbSB0aGUg
cmVhbCBtZWFuaW5nIG9mIHdoYXQgdGhlIG5ld3MgcmVsZWFzZSBtZWFudCB0byBzYXkuIFBsZWFz
ZSByZWFkIHRoZSBuZXdzIHJlbGVhc2UgYnkgeW91cnNlbGYgYW5kIGp1ZGdlIGJ5IHlvdXJzZWxm
IGFib3V0IHRoZSBkZXRhaWxzIGluIGl0Lg0KIA0KSW4gY29tcGxpYW5jZSB3aXRoIFNlY3Rpb24g
MTcoYiksIHdlIGRpc2Nsb3NlIHRoZSBob2xkaW5nIG9mIFNCV0wgc2hhcmVzIHByaW9yIHRvIHRo
ZSBwdWJsaWNhdGlvbiBvZiB0aGlzIHJlcG9ydC4gQmUgYXdhcmUgb2YgYW4gaW5oZXJlbnQgY29u
ZmxpY3Qgb2YgaW50ZXJlc3QgcmVzdWx0aW5nIGZyb20gc3VjaCBob2xkaW5ncyBkdWUgdG8gb3Vy
IGludGVudCB0byBwcm9maXQgZnJvbSB0aGUgbGlxdWlkYXRpb24gb2YgdGhlc2Ugc2hhcmVzLiBT
aGFyZXMgbWF5IGJlIHNvbGQgYXQgYW55IHRpbWUsIGV2ZW4gYWZ0ZXIgcG9zaXRpdmUgc3RhdGVt
ZW50cyBoYXZlIGJlZW4gbWFkZSByZWdhcmRpbmcgdGhlIGFib3ZlIGNvbXBhbnkuIFNpbmNlIHdl
IG93biBzaGFyZXMsIHRoZXJlIGlzIGFuIGluaGVyZW50IGNvbmZsaWN0IG9mIGludGVyZXN0IGlu
IG91ciBzdGF0ZW1lbnRzIGFuZCBvcGluaW9ucy4gUmVhZGVycyBvZiB0aGlzIHB1YmxpY2F0aW9u
IGFyZSBjYXV0aW9uZWQgbm90IHRvIHBsYWNlIHVuZHVlIHJlbGlhbmNlIG9uIGZvcndhcmQtbG9v
a2luZyBzdGF0ZW1lbnRzLCB3aGljaCBhcmUgYmFzZWQgb24gY2VydGFpbiBhc3N1bXB0aW9ucyBh
bmQgZXhwZWN0YXRpb25zIGludm9sdmluZyB2YXJpb3VzIHJpc2tzIGFuZCB1bmNlcnRhaW50aWVz
LCB0aGF0IGNvdWxkIGNhdXNlIHJlc3VsdHMgdG8gZGlmZmVyIG1hdGVyaWFsbHkgZnJvbSB0aG9z
ZSBzZXQgZm9ydGggaW4gdGhlIGZvcndhcmQtIGxvb2tpbmcgc3RhdGVtZW50cy4gDQoNClBsZWFz
ZSBiZSBhZHZpc2VkIHRoYXQgbm90aGluZyB3aXRoaW4gdGhpcyBlbWFpbCBzaGFsbCBjb25zdGl0
dXRlIGEgc29saWNpdGF0aW9uIG9yIGFuIG9mZmVyIHRvIGJ1eSBvciBzZWxsIGFueSBzZWN1cml0
eSBtZW50aW9uZWQgaGVyZWluLiBUaGlzIG5ld3NsZXR0ZXIgaXMgbmVpdGhlciBhIHJlZ2lzdGVy
ZWQgaW52ZXN0bWVudCBhZHZpc29yIG5vciBhZmZpbGlhdGVkIHdpdGggYW55IGJyb2tlciBvciBk
ZWFsZXIuIEFsbCBzdGF0ZW1lbnRzIG1hZGUgYXJlIG91ciBleHByZXNzIG9waW5pb24gb25seSBh
bmQgc2hvdWxkIGJlIHRyZWF0ZWQgYXMgc3VjaC4gV2UgbWF5IG93biwgYnV5IGFuZCBzZWxsIGFu
eSBzZWN1cml0aWVzIG1lbnRpb25lZCBhdCBhbnkgdGltZS4gVGhpcyByZXBvcnQgaW5jbHVkZXMg
Zm9yd2FyZC1sb29raW5nIHN0YXRlbWVudHMgd2l0aGluIHRoZSBtZWFuaW5nIG9mIFRoZSBQcml2
YXRlIFNlY3VyaXRpZXMgTGl0aWdhdGlvbiBSZWZvcm0gQWN0IG9mIDE5OTUuIFRoZXNlIHN0YXRl
bWVudHMgbWF5IGluY2x1ZGUgdGVybXMgYXMgImV4cGVjdCIsICJiZWxpZXZlIiwgIm1heSIsICJ3
aWxsIiwgIm1vdmUiLCJ1bmRlcnZhbHVlZCIgYW5kICJpbnRlbmQiIG9yIHNpbWlsYXIgdGVybXMu
IFRoaXMgbmV3c2xldHRlciB3YXMgcGFpZCAkMTI1MDAgZnJvbSB0aGlyZCBwYXJ0eSB0byBzZW5k
IHRoaXMgcmVwb3J0LiBQTEVBU0UgRE8gWU9VUiBPV04gRFVFIERJTElHRU5DRSBCRUZPUkUgSU5W
RVNUSU5HIElOIEFOWSBQUk9GSUxFRCBDT01QQU5ZLiBZb3UgbWF5IGxvc2UgbW9uZXkgZnJvbSBp
bnZlc3RpbmcgaW4gUGVubnkgU3RvY2tzLiANCi0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0K

----444559853917708754--


--NextMessagePart_002_59468_374863/1087160498.1087166792--


From ppopov@mvista.com Mon Jun 14 07:01:10 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 14 Jun 2004 07:01:13 +0100 (BST)
Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:18932 "EHLO
	av.mvista.com") by linux-mips.org with ESMTP id <S8224898AbUFNGBK>;
	Mon, 14 Jun 2004 07:01:10 +0100
Received: from [10.2.2.63] (av [127.0.0.1])
	by av.mvista.com (8.9.3/8.9.3) with ESMTP id XAA09205;
	Sun, 13 Jun 2004 23:00:57 -0700
Subject: Re: HD Boot on Pb1500 Kernel 2.4.26
From: Pete Popov <ppopov@mvista.com>
To: "r.zilli" <r.zilli@ingredium.it>
Cc: linux-mips@linux-mips.org
In-Reply-To: <20040609143837.1848.qmail@pop.ingredium.it>
References: <20040609143837.1848.qmail@pop.ingredium.it>
Content-Type: text/plain
Organization: 
Message-Id: <1087192850.1666.1.camel@thinkpad>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.2.2 (1.2.2-4) 
Date: 13 Jun 2004 23:00:50 -0700
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: 5302
X-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 Wed, 2004-06-09 at 07:38, r.zilli wrote:
> Hi, list 
> 
> i've successful patched the 2.4.26 with v4l support to get the saa7134 
> driver support on Alchemy Pb1500. The driver for the HPT370 is ok but the 
> ide channels are not scanned and hard disk are not recognized. 

I just tried stock 2.4.26 from linux-mips on the Db1500 and the IDE
works fine for me. The Pb1500 should work as well. Try a stock kernel
without any additional patches you may be working on to make sure that's
not the problem.

Pete


From jospehchan@yahoo.com.tw Mon Jun 14 12:56:40 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 14 Jun 2004 12:56:47 +0100 (BST)
Received: from web16612.mail.tpe.yahoo.com ([IPv6:::ffff:202.1.236.102]:36980
	"HELO web16612.mail.tpe.yahoo.com") by linux-mips.org with SMTP
	id <S8225195AbUFNL4k>; Mon, 14 Jun 2004 12:56:40 +0100
Message-ID: <20040614115631.17040.qmail@web16612.mail.tpe.yahoo.com>
Received: from [61.66.243.2] by web16612.mail.tpe.yahoo.com via HTTP; Mon, 14 Jun 2004 19:56:31 CST
Date: Mon, 14 Jun 2004 19:56:31 +0800 (CST)
From: =?big5?q?jospehchan?= <jospehchan@yahoo.com.tw>
Subject: "No such device" with PCI card
To: linux-mips@linux-mips.org
MIME-Version: 1.0
Content-Type: text/plain; charset=big5
Content-Transfer-Encoding: 8bit
Return-Path: <jospehchan@yahoo.com.tw>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 5303
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: jospehchan@yahoo.com.tw
Precedence: bulk
X-list: linux-mips

Hi all,
  I'm new in MIPS. 
  Recently, I encountered a strange problem. 
  That is when I plugged in a USB1.1 PCI card on my
MIPS machine.
  When I load "usb-uhci" modules, the system returns
"Init_modules: No such device".
  But checking "lspci", I can see the device's ID of
the USB PCI card.
  Is there anything I missed? Any suggestion or advice
is appreciated. 
  Thanks.
  

-----------------------------------------------------------------
Yahoo!©_¼¯Messenger6.0
«H½c·f°t§Y®É³q, ·¾³q¼Ö½ìµL½a! 
http://tw.messenger.yahoo.com/

From macro@ds2.pg.gda.pl Mon Jun 14 13:52:58 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 14 Jun 2004 13:53:02 +0100 (BST)
Received: from jurand.ds.pg.gda.pl ([IPv6:::ffff:153.19.208.2]:63903 "EHLO
	jurand.ds.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8225525AbUFNMw6>; Mon, 14 Jun 2004 13:52:58 +0100
Received: by jurand.ds.pg.gda.pl (Postfix, from userid 1011)
	id A4E1047833; Mon, 14 Jun 2004 14:52:50 +0200 (CEST)
Received: from localhost (localhost [127.0.0.1])
	by jurand.ds.pg.gda.pl (Postfix) with ESMTP
	id 8064D474C5; Mon, 14 Jun 2004 14:52:50 +0200 (CEST)
Date: Mon, 14 Jun 2004 14:52:50 +0200 (CEST)
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: David Daney <ddaney@avtrex.com>, cgd@broadcom.com,
	Ralf Baechle <ralf@linux-mips.org>,
	Linux/MIPS Development <linux-mips@linux-mips.org>,
	binutils@sources.redhat.com
Subject: Re: [Patch] (revised patch) / 0 should send SIGFPE not SIGTRAP 
In-Reply-To: <Pine.GSO.4.58.0406131032350.85@waterleaf.sonytel.be>
Message-ID: <Pine.LNX.4.55.0406141446510.29984@jurand.ds.pg.gda.pl>
References: <40C9F5A4.2050606@avtrex.com> <40C9F5FE.8030607@avtrex.com>
 <40C9F7F0.50501@avtrex.com> <Pine.LNX.4.55.0406112039040.13062@jurand.ds.pg.gda.pl>
 <mailpost.1086981251.16853@news-sj1-1> <yov57juduc7q.fsf@ldt-sj3-010.sj.broadcom.com>
 <Pine.LNX.4.55.0406112133380.13062@jurand.ds.pg.gda.pl> <40CA1B35.6010603@avtrex.com>
 <40CA1FE3.9030507@avtrex.com> <Pine.GSO.4.58.0406131032350.85@waterleaf.sonytel.be>
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: 5304
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: macro@ds2.pg.gda.pl
Precedence: bulk
X-list: linux-mips

On Sun, 13 Jun 2004, Geert Uytterhoeven wrote:

> Please send one more, where you use `diff -up' :-)

 No need to -- I've reimplemented it a bit differently meanwhile.  Any 
objections to the following changes?

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

patch-mips-2.4.26-20040531-mips-bp-tr-0
diff -up --recursive --new-file linux-mips-2.4.26-20040531.macro/arch/mips/kernel/traps.c linux-mips-2.4.26-20040531/arch/mips/kernel/traps.c
--- linux-mips-2.4.26-20040531.macro/arch/mips/kernel/traps.c	2004-03-13 03:56:44.000000000 +0000
+++ linux-mips-2.4.26-20040531/arch/mips/kernel/traps.c	2004-06-13 20:24:32.000000000 +0000
@@ -9,7 +9,7 @@
  * Copyright (C) 1999 Silicon Graphics, Inc.
  * Kevin D. Kissell, kevink@mips.com and Carsten Langgaard, carstenl@mips.com
  * Copyright (C) 2000, 01 MIPS Technologies, Inc.
- * Copyright (C) 2002, 2003  Maciej W. Rozycki
+ * Copyright (C) 2002, 2003, 2004  Maciej W. Rozycki
  */
 #include <linux/config.h>
 #include <linux/init.h>
@@ -22,6 +22,7 @@
 
 #include <asm/bootinfo.h>
 #include <asm/branch.h>
+#include <asm/break.h>
 #include <asm/cpu.h>
 #include <asm/fpu.h>
 #include <asm/cachectl.h>
@@ -596,9 +597,12 @@ asmlinkage void do_bp(struct pt_regs *re
 	/*
 	 * There is the ancient bug in the MIPS assemblers that the break
 	 * code starts left to bit 16 instead to bit 6 in the opcode.
-	 * Gas is bug-compatible ...
+	 * Gas is bug-compatible, but not always, grrr...
+	 * We handle both cases with a simple heuristics.  --macro
 	 */
-	bcode = ((opcode >> 16) & ((1 << 20) - 1));
+	bcode = ((opcode >> 6) & ((1 << 20) - 1));
+	if (bcode < (1 << 10))
+		bcode <<= 10;
 
 	/*
 	 * (A short test says that IRIX 5.3 sends SIGTRAP for all break
@@ -607,9 +611,9 @@ asmlinkage void do_bp(struct pt_regs *re
 	 * But should we continue the brokenness???  --macro
 	 */
 	switch (bcode) {
-	case 6:
-	case 7:
-		if (bcode == 7)
+	case BRK_OVERFLOW << 10:
+	case BRK_DIVZERO << 10:
+		if (bcode == (BRK_DIVZERO << 10))
 			info.si_code = FPE_INTDIV;
 		else
 			info.si_code = FPE_INTOVF;
@@ -633,7 +637,7 @@ asmlinkage void do_tr(struct pt_regs *re
 
 	/* Immediate versions don't provide a code.  */
 	if (!(opcode & OPCODE))
-		tcode = ((opcode >> 6) & ((1 << 20) - 1));
+		tcode = ((opcode >> 6) & ((1 << 10) - 1));
 
 	/*
 	 * (A short test says that IRIX 5.3 sends SIGTRAP for all trap
@@ -642,9 +646,9 @@ asmlinkage void do_tr(struct pt_regs *re
 	 * But should we continue the brokenness???  --macro
 	 */
 	switch (tcode) {
-	case 6:
-	case 7:
-		if (tcode == 7)
+	case BRK_OVERFLOW:
+	case BRK_DIVZERO:
+		if (tcode == BRK_DIVZERO)
 			info.si_code = FPE_INTDIV;
 		else
 			info.si_code = FPE_INTOVF;
diff -up --recursive --new-file linux-mips-2.4.26-20040531.macro/arch/mips64/kernel/traps.c linux-mips-2.4.26-20040531/arch/mips64/kernel/traps.c
--- linux-mips-2.4.26-20040531.macro/arch/mips64/kernel/traps.c	2004-03-13 03:56:45.000000000 +0000
+++ linux-mips-2.4.26-20040531/arch/mips64/kernel/traps.c	2004-06-13 20:26:01.000000000 +0000
@@ -9,7 +9,7 @@
  * Copyright (C) 1999 Silicon Graphics, Inc.
  * Kevin D. Kissell, kevink@mips.com and Carsten Langgaard, carstenl@mips.com
  * Copyright (C) 2000, 01 MIPS Technologies, Inc.
- * Copyright (C) 2002, 2003  Maciej W. Rozycki
+ * Copyright (C) 2002, 2003, 2004  Maciej W. Rozycki
  */
 #include <linux/config.h>
 #include <linux/init.h>
@@ -22,6 +22,7 @@
 
 #include <asm/bootinfo.h>
 #include <asm/branch.h>
+#include <asm/break.h>
 #include <asm/cpu.h>
 #include <asm/fpu.h>
 #include <asm/module.h>
@@ -606,9 +607,12 @@ asmlinkage void do_bp(struct pt_regs *re
 	/*
 	 * There is the ancient bug in the MIPS assemblers that the break
 	 * code starts left to bit 16 instead to bit 6 in the opcode.
-	 * Gas is bug-compatible ...
+	 * Gas is bug-compatible, but not always, grrr...
+	 * We handle both cases with a simple heuristics.  --macro
 	 */
-	bcode = ((opcode >> 16) & ((1 << 20) - 1));
+	bcode = ((opcode >> 6) & ((1 << 20) - 1));
+	if (bcode < (1 << 10))
+		bcode <<= 10;
 
 	/*
 	 * (A short test says that IRIX 5.3 sends SIGTRAP for all break
@@ -617,9 +621,9 @@ asmlinkage void do_bp(struct pt_regs *re
 	 * But should we continue the brokenness???  --macro
 	 */
 	switch (bcode) {
-	case 6:
-	case 7:
-		if (bcode == 7)
+	case BRK_OVERFLOW << 10:
+	case BRK_DIVZERO << 10:
+		if (bcode == (BRK_DIVZERO << 10))
 			info.si_code = FPE_INTDIV;
 		else
 			info.si_code = FPE_INTOVF;
@@ -643,7 +647,7 @@ asmlinkage void do_tr(struct pt_regs *re
 
 	/* Immediate versions don't provide a code.  */
 	if (!(opcode & OPCODE))
-		tcode = ((opcode >> 6) & ((1 << 20) - 1));
+		tcode = ((opcode >> 6) & ((1 << 10) - 1));
 
 	/*
 	 * (A short test says that IRIX 5.3 sends SIGTRAP for all trap
@@ -652,9 +656,9 @@ asmlinkage void do_tr(struct pt_regs *re
 	 * But should we continue the brokenness???  --macro
 	 */
 	switch (tcode) {
-	case 6:
-	case 7:
-		if (tcode == 7)
+	case BRK_OVERFLOW:
+	case BRK_DIVZERO:
+		if (tcode == BRK_DIVZERO)
 			info.si_code = FPE_INTDIV;
 		else
 			info.si_code = FPE_INTOVF;

From jbglaw@dvmwest.gt.owl.de Mon Jun 14 15:27:34 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 14 Jun 2004 15:27:39 +0100 (BST)
Received: from dvmwest.gt.owl.de ([IPv6:::ffff:62.52.24.140]:41138 "EHLO
	dvmwest.gt.owl.de") by linux-mips.org with ESMTP
	id <S8225534AbUFNO1e>; Mon, 14 Jun 2004 15:27:34 +0100
Received: by dvmwest.gt.owl.de (Postfix, from userid 1001)
	id 2AECA4B7CF; Mon, 14 Jun 2004 16:27:30 +0200 (CEST)
Date: Mon, 14 Jun 2004 16:27:30 +0200
From: Jan-Benedict Glaw <jbglaw@lug-owl.de>
To: linux-mips@linux-mips.org
Subject: Re: "No such device" with PCI card
Message-ID: <20040614142730.GQ20632@lug-owl.de>
Mail-Followup-To: linux-mips@linux-mips.org
References: <20040614115631.17040.qmail@web16612.mail.tpe.yahoo.com>
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="znSQlxigGrTagauB"
Content-Disposition: inline
In-Reply-To: <20040614115631.17040.qmail@web16612.mail.tpe.yahoo.com>
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.6i
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: 5305
X-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


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

On Mon, 2004-06-14 19:56:31 +0800, jospehchan <jospehchan@yahoo.com.tw>
wrote in message <20040614115631.17040.qmail@web16612.mail.tpe.yahoo.com>:
> Hi all,
>   I'm new in MIPS.=20
>   Recently, I encountered a strange problem.=20
>   That is when I plugged in a USB1.1 PCI card on my
> MIPS machine.
>   When I load "usb-uhci" modules, the system returns
> "Init_modules: No such device".
>   But checking "lspci", I can see the device's ID of
> the USB PCI card.
>   Is there anything I missed? Any suggestion or advice
> is appreciated.=20

lspci tells you vendor and device id. These IDs need to be told to the
driver. Because the uhci driver uses:

static const struct pci_device_id uhci_pci_ids[] =3D { {
        /* handle any USB UHCI controller */
        PCI_DEVICE_CLASS(((PCI_CLASS_SERIAL_USB << 8) | 0x00), ~0),
        .driver_data =3D  (unsigned long) &uhci_driver,
        }, { /* end: all zeroes */ }
};

I think your device is just broken (and doesn't tell it's a USB host).
If you think it's really driven by uhci (and not by ohci), then stick
your device IDs into that table, or add those dynamically by echo'ing
them to /sys/bus/pci/drivers/uhci_hcd/new_id. You need sysfs mounted to
/sys, though.

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));

--znSQlxigGrTagauB
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)

iD8DBQFAzbXSHb1edYOZ4bsRAn9hAJ9oUiYsGsqAb2uUAqC/U7b+eQvpwwCfS2Z7
py25SbLG8WHzkBaoArjF7FU=
=KuIN
-----END PGP SIGNATURE-----

--znSQlxigGrTagauB--

From tbm@cyrius.com Mon Jun 14 18:19:34 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 14 Jun 2004 18:19:39 +0100 (BST)
Received: from sorrow.cyrius.com ([IPv6:::ffff:65.19.161.204]:27147 "EHLO
	sorrow.cyrius.com") by linux-mips.org with ESMTP
	id <S8225768AbUFNRTe>; Mon, 14 Jun 2004 18:19:34 +0100
Received: by sorrow.cyrius.com (Postfix, from userid 10)
	id B782664D3A; Mon, 14 Jun 2004 17:19:30 +0000 (UTC)
Received: by deprecation.cyrius.com (Postfix, from userid 1000)
	id C3D4FFFCF; Mon, 14 Jun 2004 18:17:51 +0100 (BST)
Date: Mon, 14 Jun 2004 18:17:51 +0100
From: Martin Michlmayr <tbm@cyrius.com>
To: Dennis Grevenstein <dennis@pcde.inka.de>
Cc: linux-mips@linux-mips.org
Subject: Re: network problems with cobalt raq2
Message-ID: <20040614171751.GA383@deprecation.cyrius.com>
References: <20040613000452.GA3861@aton.pcde.inka.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20040613000452.GA3861@aton.pcde.inka.de>
User-Agent: Mutt/1.5.6+20040523i
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: 5306
X-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

* Dennis Grevenstein <dennis@pcde.inka.de> [2004-06-13 02:04]:
> I can transfer about 1MB/s at the very best. When it runs as
> a masquerading router for my internal network performance

I just tested on my RaQ2 and I get up to 2500kB/s via FTP.  This is
in my LAN with a 100 MBit switch.

Which network device do you use (the first or second)?  What's your
setup?  Do you get such low rates also when you simply do FTP without
any masquerading or other stuff?
-- 
Martin Michlmayr
tbm@cyrius.com

From jsun@mvista.com Tue Jun 15 00:02:56 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 15 Jun 2004 00:03:00 +0100 (BST)
Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:54010 "EHLO
	orion.mvista.com") by linux-mips.org with ESMTP id <S8225929AbUFNXC4>;
	Tue, 15 Jun 2004 00:02:56 +0100
Received: from orion.mvista.com (localhost.localdomain [127.0.0.1])
	by orion.mvista.com (8.12.8/8.12.8) with ESMTP id i5EN2s4O019311;
	Mon, 14 Jun 2004 16:02:54 -0700
Received: (from jsun@localhost)
	by orion.mvista.com (8.12.8/8.12.8/Submit) id i5EN2rr2019310;
	Mon, 14 Jun 2004 16:02:53 -0700
Date: Mon, 14 Jun 2004 16:02:53 -0700
From: Jun Sun <jsun@mvista.com>
To: linux-mips@linux-mips.org
Cc: jsun@mvista.com
Subject: opening at Monta Vista Software (Sunnyvale, CA)
Message-ID: <20040614160253.G16872@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: 5307
X-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


Sorry to abuse the list one more time, but this list is such a
suitable place for this ad that it makes posting to any other
places dull. :)

We have an opening in linux/mips kernel area.  Generally the work
will involve kernel porting, driver development and other
montavista linux related features.  Ask me for more details.

This position is for experienced or senior developers.  And it
is located in Sunnyvale, CA.

Thanks.

Jun

From jospehchan@yahoo.com.tw Tue Jun 15 03:02:12 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 15 Jun 2004 03:02:19 +0100 (BST)
Received: from web16612.mail.tpe.yahoo.com ([IPv6:::ffff:202.1.236.102]:56892
	"HELO web16612.mail.tpe.yahoo.com") by linux-mips.org with SMTP
	id <S8225990AbUFOCCM>; Tue, 15 Jun 2004 03:02:12 +0100
Message-ID: <20040615020159.56838.qmail@web16612.mail.tpe.yahoo.com>
Received: from [61.66.243.2] by web16612.mail.tpe.yahoo.com via HTTP; Tue, 15 Jun 2004 10:01:59 CST
Date: Tue, 15 Jun 2004 10:01:59 +0800 (CST)
From: =?big5?q?jospehchan?= <jospehchan@yahoo.com.tw>
Subject: Re: "No such device" with PCI card
To: linux-mips@linux-mips.org
Cc: jbglaw@lug-owl.de
MIME-Version: 1.0
Content-Type: text/plain; charset=big5
Content-Transfer-Encoding: 8bit
Return-Path: <jospehchan@yahoo.com.tw>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 5308
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: jospehchan@yahoo.com.tw
Precedence: bulk
X-list: linux-mips

>lspci tells you vendor and device id. These IDs need
to be told to the
>driver. Because the uhci driver uses:

>static const struct pci_device_id uhci_pci_ids[] = {
{
>        /* handle any USB UHCI controller */
>        PCI_DEVICE_CLASS(((PCI_CLASS_SERIAL_USB << 8)
| 0x00), ~0),
>        .driver_data =  (unsigned long) &uhci_driver,
>        }, { /* end: all zeroes */ }
>};

>I think your device is just broken (and doesn't tell
it's a USB host).
>If you think it's really driven by uhci (and not by
ohci), then stick
>your device IDs into that table, or add those
dynamically by echo'ing
them to /sys/bus/pci/drivers/uhci_hcd/new_id. >You
need sysfs mounted to
/sys, though.

I also tried other PCI cards. (Such as PCI LAN card or
Philips USB PCI card)
After loading the 8139too or usb-uhci module, the same
problem still happened.
So I doubt that something missed when configuring the
kernel.
BTW, how to mount the sysfs to /sys?
I can not find the sysfs file system in kernel
configuration.

The following is my kernel config file. Any
comment/suggestion, Thanks in advance.

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

#
# Code maturity level options
#
CONFIG_EXPERIMENTAL=y

#
# Machine selection
#
# CONFIG_ACER_PICA_61 is not set
# CONFIG_ALGOR_P4032 is not set
# CONFIG_BAGET_MIPS is not set
# CONFIG_DECSTATION is not set
# CONFIG_DDB5074 is not set
# CONFIG_MIPS_EV96100 is not set
# CONFIG_MIPS_EV64120 is not set
# CONFIG_MIPS_ATLAS is not set
# CONFIG_MIPS_MALTA is not set
# CONFIG_NINO is not set
# CONFIG_ADI_6680 is not set
CONFIG_ADI_6843=y
# CONFIG_MIPS_MAGNUM_4000 is not set
# CONFIG_MOMENCO_OCELOT is not set
# CONFIG_DDB5476 is not set
# CONFIG_DDB5477 is not set
# CONFIG_OLIVETTI_M700 is not set
# CONFIG_SGI_IP22 is not set
# CONFIG_SNI_RM200_PCI is not set
# CONFIG_MIPS_ITE8172 is not set
# CONFIG_MIPS_IVR is not set
# CONFIG_MIPS_PB1000 is not set
CONFIG_RWSEM_GENERIC_SPINLOCK=y
# CONFIG_RWSEM_XCHGADD_ALGORITHM is not set
# CONFIG_MCA is not set
# CONFIG_SBUS is not set
CONFIG_PCI=y
# CONFIG_ISA is not set
CONFIG_NEW_TIME_C=y
CONFIG_NEW_IRQ=y
# CONFIG_ISA is not set
# CONFIG_EISA is not set
# CONFIG_I8259 is not set

#
# Loadable module support
#
CONFIG_MODULES=y
CONFIG_MODVERSIONS=y
CONFIG_KMOD=y

#
# CPU selection
#
# CONFIG_CPU_R3000 is not set
CONFIG_CPU_LX4189=y
# CONFIG_CPU_R6000 is not set
# CONFIG_CPU_VR41XX is not set
# CONFIG_CPU_R4300 is not set
# CONFIG_CPU_R4X00 is not set
# CONFIG_CPU_R5000 is not set
# CONFIG_CPU_R5432 is not set
# CONFIG_CPU_RM7000 is not set
# CONFIG_CPU_NEVADA is not set
# CONFIG_CPU_R10000 is not set
# CONFIG_CPU_SB1 is not set
# CONFIG_CPU_MIPS32 is not set
# CONFIG_CPU_MIPS64 is not set
# CONFIG_CPU_ADVANCED is not set
# CONFIG_CPU_HAS_LLSC is not set
# CONFIG_CPU_HAS_LLDSCD is not set
CONFIG_CPU_HAS_WB=y

#
# General setup
#
# CONFIG_CPU_LITTLE_ENDIAN is not set
CONFIG_KCORE_ELF=y
CONFIG_ELF_KERNEL=y
# CONFIG_BINFMT_IRIX is not set
# CONFIG_FORWARD_KEYBOARD is not set
# CONFIG_BINFMT_AOUT is not set
CONFIG_BINFMT_ELF=y
# CONFIG_BINFMT_MISC is not set
CONFIG_NET=y
CONFIG_PCI_NAMES=y
# CONFIG_HOTPLUG is not set
# CONFIG_PCMCIA is not set
CONFIG_SYSVIPC=y
# CONFIG_BSD_PROCESS_ACCT is not set
CONFIG_SYSCTL=y

#
# Memory Technology Devices (MTD)
#
CONFIG_MTD=y
# CONFIG_MTD_DEBUG is not set
CONFIG_MTD_PARTITIONS=y
# CONFIG_MTD_REDBOOT_PARTS is not set
# CONFIG_MTD_CHAR is not set
CONFIG_MTD_BLOCK=y
# CONFIG_FTL is not set
# CONFIG_NFTL is not set

#
# RAM/ROM/Flash chip drivers
#
# CONFIG_MTD_CFI is not set
# CONFIG_MTD_JEDECPROBE is not set
# CONFIG_MTD_GEN_PROBE is not set
# CONFIG_MTD_CFI_INTELEXT is not set
# CONFIG_MTD_CFI_AMDSTD is not set
# CONFIG_MTD_RAM is not set
# CONFIG_MTD_ROM is not set
# CONFIG_MTD_ABSENT is not set
CONFIG_MTD_OBSOLETE_CHIPS=y
CONFIG_MTD_AMDSTD=y
# CONFIG_MTD_SHARP is not set
# CONFIG_MTD_JEDEC is not set

#
# Mapping drivers for chip access
#
# CONFIG_MTD_PHYSMAP is not set
# CONFIG_MTD_CSTM_MIPS_IXX is not set
# CONFIG_MTD_OCELOT is not set
# CONFIG_ADI_6680_FLASH is not set
CONFIG_ADI_6843_FLASH=y

#
# Self-contained MTD device drivers
#
# CONFIG_MTD_PMC551 is not set
# CONFIG_MTD_SLRAM is not set
# CONFIG_MTD_MTDRAM is not set
# CONFIG_MTD_BLKMTD is not set
# CONFIG_MTD_DOC1000 is not set
# CONFIG_MTD_DOC2000 is not set
# CONFIG_MTD_DOC2001 is not set
# CONFIG_MTD_DOCPROBE is not set

#
# NAND Flash Device Drivers
#
# CONFIG_MTD_NAND is not set

#
# Parallel port support
#
# CONFIG_PARPORT 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_BLK_DEV_DAC960 is not set
CONFIG_BLK_DEV_LOOP=y
CONFIG_BLK_DEV_NBD=y
CONFIG_BLK_DEV_RAM=y
CONFIG_BLK_DEV_RAM_SIZE=4096
CONFIG_BLK_DEV_INITRD=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=y
CONFIG_PACKET_MMAP=y
CONFIG_NETLINK=y
CONFIG_RTNETLINK=y
CONFIG_NETLINK_DEV=y
CONFIG_NETFILTER=y
# CONFIG_NETFILTER_DEBUG is not set
CONFIG_FILTER=y
CONFIG_UNIX=y
CONFIG_INET=y
CONFIG_IP_MULTICAST=y
# CONFIG_IP_ADVANCED_ROUTER is not set
CONFIG_IP_PNP=y
# CONFIG_IP_PNP_DHCP is not set
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 is not set
# CONFIG_SYN_COOKIES is not set

#
#   IP: Netfilter Configuration
#
# CONFIG_IP_NF_CONNTRACK is not set
# CONFIG_IP_NF_QUEUE is not set
CONFIG_IP_NF_IPTABLES=y
# CONFIG_IP_NF_MATCH_LIMIT is not set
# CONFIG_IP_NF_MATCH_MAC is not set
# CONFIG_IP_NF_MATCH_MARK is not set
# CONFIG_IP_NF_MATCH_MULTIPORT is not set
# CONFIG_IP_NF_MATCH_TOS is not set
# CONFIG_IP_NF_MATCH_LENGTH is not set
# CONFIG_IP_NF_MATCH_TTL is not set
# CONFIG_IP_NF_MATCH_TCPMSS is not set
# CONFIG_IP_NF_MATCH_UNCLEAN is not set
# CONFIG_IP_NF_MATCH_OWNER is not set
CONFIG_IP_NF_FILTER=y
CONFIG_IP_NF_TARGET_REJECT=y
CONFIG_IP_NF_TARGET_MIRROR=y
# CONFIG_IP_NF_MANGLE is not set
# CONFIG_IP_NF_TARGET_LOG is not set
# CONFIG_IP_NF_TARGET_TCPMSS is not set
# CONFIG_IPV6 is not set
# CONFIG_KHTTPD is not set
# CONFIG_ATM is not set
# CONFIG_VLAN_8021Q is not set
# CONFIG_IPX is not set
# CONFIG_ATALK 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

#
# 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=m
CONFIG_BLK_DEV_SD=m
CONFIG_SD_EXTRA_DEVS=40
# CONFIG_CHR_DEV_ST is not set
# CONFIG_CHR_DEV_OSST is not set
# CONFIG_BLK_DEV_SR is not set
# CONFIG_CHR_DEV_SG is not set
# CONFIG_SCSI_DEBUG_QUEUES is not set
# CONFIG_SCSI_MULTI_LUN is not set
# CONFIG_SCSI_CONSTANTS is not set
# CONFIG_SCSI_LOGGING is not set

#
# SCSI low-level drivers
#
# CONFIG_BLK_DEV_3W_XXXX_RAID is not set
# 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_AIC7XXX 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_BUSLOGIC is not set
# CONFIG_SCSI_CPQFCTS 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_NCR53C406A is not set
# CONFIG_SCSI_NCR53C7xx is not set
# CONFIG_SCSI_SYM53C8XX_2 is not set
# CONFIG_SCSI_NCR53C8XX is not set
# CONFIG_SCSI_SYM53C8XX 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_QLOGIC_ISP is not set
# CONFIG_SCSI_QLOGIC_FC is not set
# CONFIG_SCSI_QLOGIC_1280 is not set
# CONFIG_SCSI_SIM710 is not set
# CONFIG_SCSI_SYM53C416 is not set
# CONFIG_SCSI_DC390T is not set
# CONFIG_SCSI_T128 is not set
# CONFIG_SCSI_U14_34F is not set
# CONFIG_SCSI_DEBUG is not set

#
# I2O device support
#
# CONFIG_I2O is not set
# CONFIG_I2O_PCI is not set
# CONFIG_I2O_BLOCK is not set
# CONFIG_I2O_LAN is not set
# CONFIG_I2O_SCSI is not set
# CONFIG_I2O_PROC 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_HAPPYMEAL is not set
# CONFIG_SUNBMAC is not set
# CONFIG_SUNQE is not set
# CONFIG_SUNLANCE is not set
# CONFIG_SUNGEM is not set
# CONFIG_ETH_SIERRA is not set
CONFIG_ETH_NETPRO_SIERRA=y
# 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_HP100 is not set
# CONFIG_NET_ISA is not set
CONFIG_NET_PCI=y
# CONFIG_PCNET32 is not set
# CONFIG_ADAPTEC_STARFIRE is not set
# CONFIG_APRICOT is not set
# CONFIG_CS89x0 is not set
# CONFIG_TULIP is not set
# CONFIG_DE4X5 is not set
# CONFIG_DGRS is not set
# CONFIG_DM9102 is not set
# CONFIG_EEPRO100 is not set
# CONFIG_LNE390 is not set
# CONFIG_FEALNX is not set
# CONFIG_NATSEMI is not set
# CONFIG_NE2K_PCI is not set
# CONFIG_NE3210 is not set
# CONFIG_ES3210 is not set
# CONFIG_8139CP is not set
CONFIG_8139TOO=m
# CONFIG_8139TOO_PIO is not set
# CONFIG_8139TOO_TUNE_TWISTER is not set
# CONFIG_8139TOO_8129 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_VIA_RHINE_MMIO is not set
# CONFIG_WINBOND_840 is not set
# CONFIG_LAN_SAA9730 is not set
# CONFIG_NET_POCKET is not set

#
# Ethernet (1000 Mbit)
#
# CONFIG_ACENIC is not set
# CONFIG_DL2K 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_SK98LIN 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=y
# CONFIG_STRIP is not set
# CONFIG_WAVELAN is not set
# CONFIG_ARLAN is not set
# CONFIG_AIRONET4500 is not set
# CONFIG_AIRONET4500_NONCS is not set
# CONFIG_AIRONET4500_PROC is not set
# CONFIG_AIRO is not set
CONFIG_NET_WIRELESS=y

#
# 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

#
# Old CD-ROM drivers (not SCSI, not IDE)
#
# CONFIG_CD_NO_IDESCSI is not set

#
# Character devices
#
# CONFIG_VT is not set
CONFIG_SERIAL_IR=m
# CONFIG_LG_IR is not set
# CONFIG_SONY_DVD is not set
CONFIG_SONY_VCR=y
# CONFIG_SONY_TV is not set
CONFIG_SERIAL=y
CONFIG_SERIAL_CONSOLE=y
# CONFIG_SERIAL_EXTENDED is not set
# CONFIG_SERIAL_NONSTANDARD is not set
# CONFIG_UNIX98_PTYS is not set

#
# I2C support
#
# CONFIG_I2C is not set

#
# Mice
#
# CONFIG_BUSMOUSE is not set
# CONFIG_MOUSE is not set

#
# Joysticks
#
# CONFIG_INPUT_GAMEPORT is not set
# CONFIG_QIC02_TAPE is not set

#
# Watchdog Cards
#
# CONFIG_WATCHDOG is not set
# CONFIG_INTEL_RNG is not set
# CONFIG_NVRAM is not set
# CONFIG_RTC 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
# CONFIG_DRM is not set

#
# Multimedia devices
#
# CONFIG_VIDEO_DEV is not set

#
# File systems
#
# CONFIG_QUOTA is not set
# CONFIG_AUTOFS_FS is not set
# CONFIG_AUTOFS4_FS is not set
# 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_BFS_FS is not set
# CONFIG_EXT3_FS is not set
# CONFIG_JBD is not set
# CONFIG_JBD_DEBUG is not set
CONFIG_FAT_FS=m
CONFIG_MSDOS_FS=m
# 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=y
CONFIG_JFFS2_FS_DEBUG=0
# CONFIG_CRAMFS is not set
# CONFIG_TMPFS is not set
# CONFIG_RAMFS is not set
# CONFIG_ISO9660_FS is not set
# CONFIG_JOLIET is not set
# CONFIG_ZISOFS 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 is not set
# 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

#
# Network File Systems
#
# CONFIG_CODA_FS is not set
# CONFIG_INTERMEZZO_FS is not set
CONFIG_NFS_FS=y
CONFIG_NFS_V3=y
# CONFIG_ROOT_NFS is not set
CONFIG_NFSD=y
# CONFIG_NFSD_V3 is not set
CONFIG_SUNRPC=y
CONFIG_LOCKD=y
CONFIG_LOCKD_V4=y
# CONFIG_SMB_FS 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
# CONFIG_ZLIB_FS_INFLATE is not set

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

#
# Native Language Support
#
CONFIG_NLS_DEFAULT="iso8859-1"
# CONFIG_NLS_CODEPAGE_437 is not set
# CONFIG_NLS_CODEPAGE_737 is not set
# CONFIG_NLS_CODEPAGE_775 is not set
# CONFIG_NLS_CODEPAGE_850 is not set
# CONFIG_NLS_CODEPAGE_852 is not set
# 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_1251 is not set
# CONFIG_NLS_ISO8859_1 is not set
# CONFIG_NLS_ISO8859_2 is not set
# 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 is not set
# CONFIG_NLS_KOI8_R is not set
# CONFIG_NLS_KOI8_U is not set
# CONFIG_NLS_UTF8 is not set

#
# USB support
#
CONFIG_USB=m
# CONFIG_USB_DEBUG is not set
CONFIG_USB_DEVICEFS=y
# CONFIG_USB_BANDWIDTH is not set
# CONFIG_USB_LONG_TIMEOUT is not set
CONFIG_USB_UHCI=m
# CONFIG_USB_UHCI_ALT is not set
# CONFIG_USB_OHCI is not set
# CONFIG_USB_AUDIO is not set
# CONFIG_USB_BLUETOOTH is not set
CONFIG_USB_STORAGE=m
# CONFIG_USB_STORAGE_DEBUG is not set
# CONFIG_USB_STORAGE_DATAFAB is not set
# CONFIG_USB_STORAGE_FREECOM is not set
# CONFIG_USB_STORAGE_ISD200 is not set
# CONFIG_USB_STORAGE_DPCM is not set
# CONFIG_USB_STORAGE_HP8200e is not set
# CONFIG_USB_STORAGE_SDDR09 is not set
# CONFIG_USB_STORAGE_JUMPSHOT is not set
# CONFIG_USB_ACM is not set
# CONFIG_USB_PRINTER is not set
# CONFIG_USB_DC2XX is not set
# CONFIG_USB_MDC800 is not set
# CONFIG_USB_SCANNER is not set
# CONFIG_USB_MICROTEK is not set
# CONFIG_USB_HPUSBSCSI is not set
# CONFIG_USB_PEGASUS is not set
# CONFIG_USB_KAWETH is not set
# CONFIG_USB_CATC is not set
# CONFIG_USB_CDCETHER is not set
# CONFIG_USB_USBNET is not set
# CONFIG_USB_USS720 is not set

#
# USB Serial Converter support
#
# CONFIG_USB_SERIAL is not set
# CONFIG_USB_SERIAL_GENERIC is not set
# CONFIG_USB_SERIAL_BELKIN is not set
# CONFIG_USB_SERIAL_WHITEHEAT is not set
# CONFIG_USB_SERIAL_DIGI_ACCELEPORT is not set
# CONFIG_USB_SERIAL_EMPEG is not set
# CONFIG_USB_SERIAL_FTDI_SIO is not set
# CONFIG_USB_SERIAL_VISOR is not set
# CONFIG_USB_SERIAL_IR is not set
# CONFIG_USB_SERIAL_EDGEPORT is not set
# CONFIG_USB_SERIAL_KEYSPAN_PDA is not set
# CONFIG_USB_SERIAL_KEYSPAN is not set
# CONFIG_USB_SERIAL_KEYSPAN_USA28 is not set
# CONFIG_USB_SERIAL_KEYSPAN_USA28X is not set
# CONFIG_USB_SERIAL_KEYSPAN_USA28XA is not set
# CONFIG_USB_SERIAL_KEYSPAN_USA28XB is not set
# CONFIG_USB_SERIAL_KEYSPAN_USA19 is not set
# CONFIG_USB_SERIAL_KEYSPAN_USA18X is not set
# CONFIG_USB_SERIAL_KEYSPAN_USA19W is not set
# CONFIG_USB_SERIAL_KEYSPAN_USA49W is not set
# CONFIG_USB_SERIAL_MCT_U232 is not set
# CONFIG_USB_SERIAL_PL2303 is not set
# CONFIG_USB_SERIAL_CYBERJACK is not set
# CONFIG_USB_SERIAL_XIRCOM is not set
# CONFIG_USB_SERIAL_OMNINET is not set
# CONFIG_USB_RIO500 is not set

#
# Input core support
#
# CONFIG_INPUT is not set
# CONFIG_INPUT_KEYBDEV is not set
# CONFIG_INPUT_MOUSEDEV is not set
# CONFIG_INPUT_JOYDEV is not set
# CONFIG_INPUT_EVDEV is not set

#
# Kernel hacking
#
CONFIG_CROSSCOMPILE=y
CONFIG_REMOTE_DEBUG=y
# CONFIG_GDB_CONSOLE is not set
# CONFIG_LL_DEBUG is not set
# CONFIG_MAGIC_SYSRQ is not set
# CONFIG_MIPS_UNCACHED is not set
*********


-----------------------------------------------------------------
Yahoo!©_¼¯Messenger6.0
«H½c·f°t§Y®É³q, ·¾³q¼Ö½ìµL½a! 
http://tw.messenger.yahoo.com/

From dennis@pcde.inka.de Tue Jun 15 03:02:38 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 15 Jun 2004 03:02:46 +0100 (BST)
Received: from quechua.inka.de ([IPv6:::ffff:193.197.184.2]:54201 "EHLO
	mail.inka.de") by linux-mips.org with ESMTP id <S8226000AbUFOCCU>;
	Tue, 15 Jun 2004 03:02:20 +0100
Received: from pcde.inka.de (uucp@[127.0.0.1])
	by mail.inka.de with uucp (rmailwrap 0.5) 
	id 1Ba3HF-0005XF-00; Tue, 15 Jun 2004 04:02:17 +0200
Received: by aton.pcde.inka.de (Postfix, from userid 1001)
	id E085A1E5C7; Tue, 15 Jun 2004 03:22:10 +0200 (CEST)
Date: Tue, 15 Jun 2004 03:22:10 +0200
From: Dennis Grevenstein <dennis@pcde.inka.de>
To: Martin Michlmayr <tbm@cyrius.com>
Cc: linux-mips@linux-mips.org
Subject: Re: network problems with cobalt raq2
Message-ID: <20040615012210.GA23531@aton.pcde.inka.de>
References: <20040613000452.GA3861@aton.pcde.inka.de> <20040614171751.GA383@deprecation.cyrius.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20040614171751.GA383@deprecation.cyrius.com>
User-Agent: Mutt/1.4.1i
Return-Path: <dennis@pcde.inka.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: 5309
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: dennis@pcde.inka.de
Precedence: bulk
X-list: linux-mips

Hi,

On Mon, Jun 14, 2004 at 06:17:51PM +0100, Martin Michlmayr wrote:

> I just tested on my RaQ2 and I get up to 2500kB/s via FTP.  This is
> in my LAN with a 100 MBit switch.

Hmm. Maybe this is really the maximum...
 
> Which network device do you use (the first or second)?  What's your
> setup?  Do you get such low rates also when you simply do FTP without
> any masquerading or other stuff?

Okay. This is the current state:
I could finally compile the current CVS kernel + the Cobalt
patches from http://www.colonel-panic.org/cobalt-mips/
The Raq2 is now running 2.6.7-rc3. With this upgrade
everything got bettter, but it's still not perfect.
With the standard Debian ftpd connections begin with about
2.5MB/s, but then drop to 1.37MB/s. Using vsftpd it's
similar, but the transfer rate doesn't drop so much.
I can get about 1.67MB/s. There is no real difference
whether firewalling/masquerading is used at the same time
or not. I'm just a bit confused because I was told by
another Raq2 owner that he could get transfer rates of about
6 or 7MB/s using the current CVS kernel. I did all my
tests by transferring the ungzipped gcc-3.4.0 tarball.
That's 182MB. The nice thing is that I can now
transfer a big file via ftp without killing the whole
machine. With 2.4.26 beginning an ftp transfer made
all other connections unuseable. Outgoing SSH
connections dropped down so much that I could wait
for every typed character to appear. Maybe it's
a good idea to file a Debian bug report. Their
standard kernel seems to be problematic.

Anyway, the network problems didn't go away completely.
I had one "almost" network freeze with the new kernel
resulting in lots of dropped packages and transfer rates
similar to what I described in my first mail. Restarting
the network solved this.

tessa:~# ifconfig eth0 
eth0      Link encap:Ethernet  HWaddr 00:10:E0:00:31:F5  
          inet addr:192.168.2.10  Bcast:192.168.2.255  Mask:255.255.255.0
          inet6 addr: fe80::210:e0ff:fe00:31f5/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:4314429 errors:2 dropped:10412 overruns:0 frame:5
          TX packets:3013429 errors:23 dropped:0 overruns:4 carrier:19
          collisions:0 txqueuelen:1000 
          RX bytes:1151870219 (1.0 GiB)  TX bytes:1305479776 (1.2 GiB)
          Interrupt:19 

My current setup is like this: I have connected eth0 to
a 100Mbit switch and eth1 to a gateway router via 10MBit.
The box has about 1 day uptime now and works stable at
the moment. I'm waiting for the next network freeze...

ANother thing worth noting is that after upgrading to 2.6.7-rc3
I have the same problem with "df" that was described on this
list before: 
tessa:~# df 
Filesystem           1K-blocks      Used Available Use% Mounted on
df: `/': Invalid argument
df: `/proc': Invalid argument
df: `/sys': Invalid argument
df: `/dev/pts': Invalid argument
df: `/dev/shm': Invalid argument
df: `/boot': Invalid argument
df: `/export': Invalid argument

strace gives the same info as it was described in the past.

All in all, I'm very interested in any possible improvement.
I need a low cost server that is silent enough that I can
sleep in the same room and this Cobalt seems like a very
good candidate (after replacing the small fan of course).
thanks for your help.

mfg
Dennis

P.S.
I'm not on the list. I'm reading this list via a web-gateway.

-- 
de-moc-ra-cy (di mok' ra see) n.
Three wolves and a sheep voting on what's for dinner.

From dom@kilimandjaro.dyndns.org Tue Jun 15 10:03:07 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 15 Jun 2004 10:03:11 +0100 (BST)
Received: from kilimandjaro.dyndns.org ([IPv6:::ffff:212.43.221.157]:5436 "HELO
	kilimandjaro.dyndns.org") by linux-mips.org with SMTP
	id <S8225296AbUFOJDH>; Tue, 15 Jun 2004 10:03:07 +0100
Received: by kilimandjaro.dyndns.org (Postfix, from userid 500)
	id 35D231F7864; Tue, 15 Jun 2004 11:02:59 +0200 (CEST)
Received: from saperlipopette ([127.0.0.1] helo=kilimandjaro.dyndns.org)
	by saperlipopette with esmtp (Exim 4.22)
	id 1Ba9qA-0003NW-T6; Tue, 15 Jun 2004 11:02:46 +0200
Message-ID: <40CEBB36.1030707@kilimandjaro.dyndns.org>
Date: Tue, 15 Jun 2004 11:02:46 +0200
From: Dominique Quatravaux <dom@kilimandjaro.dyndns.org>
User-Agent: Mozilla Thunderbird 0.4 (X11/20040306)
X-Accept-Language: fr, en
MIME-Version: 1.0
To: jospehchan <jospehchan@yahoo.com.tw>
Cc: linux-mips@linux-mips.org, jbglaw@lug-owl.de
Subject: Re: "No such device" with PCI card
References: <20040615020159.56838.qmail@web16612.mail.tpe.yahoo.com>
In-Reply-To: <20040615020159.56838.qmail@web16612.mail.tpe.yahoo.com>
X-Enigmail-Version: 0.83.2.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: text/plain; charset=Big5
Content-Transfer-Encoding: 7bit
Return-Path: <dom@kilimandjaro.dyndns.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: 5310
X-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@kilimandjaro.dyndns.org
Precedence: bulk
X-list: linux-mips

jospehchan wrote:

>
> After loading the 8139too or usb-uhci module, the same problem
> still happened. So I doubt that something missed when configuring
> the kernel.

Sorry, but your diagnosis is not quite correct. I'm guessing you are
new to Linux kernel programming, device drivers etc (BTW, Jan-Benedict
suggested you *modify* your kernel source then recompile). Why not try
and get your USB PCI card working on a Linux PC computer first? That
would get most of your questions sorted out without compositing them
with MIPS issues. Then come back on this list and knowing that "it
works on i386" we could help you crossing the little gap remaining.
(Right now it's not even clear whether your USB card is supported by
Linux at all!)

Not to mean that this list is not ready to provide assistance to you
:-) but the MIPS platform still has rough edges, and better suited for
hardcore programmers to date. I know that because I've jumped through
those hoops myself before: I bought a desktop PCI Alpha computer
almost a decade ago and suffered no end of a pain on it :-). This was
a fun and teaching experience, sure - but also a frustrating one at times.

> BTW, how to mount the sysfs to /sys? I can not find the sysfs file
> system in kernel configuration.


As root, type:

mkdir /sys # Ignore error if already
# exists
mount /sys /sys -t sysfs

Then read up on the "Linux 2.6 device driver model":
Documentation/driver-model/* in the kernel source, and
http://lwn.net/Articles/31185/

-- 
<< Tout n'y est pas parfait, mais on y honore certainement les
jardiniers >>

Dominique Quatravaux <dom@kilimandjaro.dyndns.org>



From jospehchan@yahoo.com.tw Tue Jun 15 11:27:18 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 15 Jun 2004 11:27:22 +0100 (BST)
Received: from web16604.mail.tpe.yahoo.com ([IPv6:::ffff:202.1.236.94]:11159
	"HELO web16604.mail.tpe.yahoo.com") by linux-mips.org with SMTP
	id <S8225717AbUFOK1S>; Tue, 15 Jun 2004 11:27:18 +0100
Message-ID: <20040615102708.42219.qmail@web16604.mail.tpe.yahoo.com>
Received: from [61.66.243.2] by web16604.mail.tpe.yahoo.com via HTTP; Tue, 15 Jun 2004 18:27:08 CST
Date: Tue, 15 Jun 2004 18:27:08 +0800 (CST)
From: =?big5?q?jospehchan?= <jospehchan@yahoo.com.tw>
Subject: Re: "No such device" with PCI card
To: Dominique Quatravaux <dom@kilimandjaro.dyndns.org>
Cc: linux-mips@linux-mips.org, jbglaw@lug-owl.de
In-Reply-To: <40CEBB36.1030707@kilimandjaro.dyndns.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=big5
Content-Transfer-Encoding: 8bit
Return-Path: <jospehchan@yahoo.com.tw>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 5311
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: jospehchan@yahoo.com.tw
Precedence: bulk
X-list: linux-mips

Hi Dominique,
Thanks for your suggestion and help.
I've tried my VIA VT6212L USB2.0 PCI card on other
Linux system(x86 based) (RedHat 7.2 + kernel 2.4.16). 
And it works fine under kernel 2.4.16 with an USB
patch from kernel 2.4.26.
So I migrated the system to MIPS, but I was stuck by
this problem.
Altough I'm not familiar with device driver, but I
will try Jan-Benedict's suggestion.

BRs, 
 Joseph

<dom@kilimandjaro.dyndns.org> ªº°T®§¡G> jospehchan
wrote:
> 
> >
> > After loading the 8139too or usb-uhci module, the
> same problem
> > still happened. So I doubt that something missed
> when configuring the kernel.
> 
> Sorry, but your diagnosis is not quite correct. I'm
> guessing you are
> new to Linux kernel programming, device drivers etc
> (BTW, Jan-Benedict
> suggested you *modify* your kernel source then
> recompile). Why not try
> and get your USB PCI card working on a Linux PC
> computer first? That
> would get most of your questions sorted out without
> compositing them
> with MIPS issues. Then come back on this list and
> knowing that "it
> works on i386" we could help you crossing the little
> gap remaining.
> (Right now it's not even clear whether your USB card
> is supported by
> Linux at all!)
> 
> Not to mean that this list is not ready to provide
> assistance to you
> :-) but the MIPS platform still has rough edges, and
> better suited for
> hardcore programmers to date. I know that because
> I've jumped through
> those hoops myself before: I bought a desktop PCI
> Alpha computer
> almost a decade ago and suffered no end of a pain on
> it :-). This was
> a fun and teaching experience, sure - but also a
> frustrating one at times.
> 
> > BTW, how to mount the sysfs to /sys? I can not
> find the sysfs file
> > system in kernel configuration.
> 
> 
> As root, type:
> 
> mkdir /sys # Ignore error if already
> # exists
> mount /sys /sys -t sysfs
> 
> Then read up on the "Linux 2.6 device driver model":
> Documentation/driver-model/* in the kernel source,
> and
> http://lwn.net/Articles/31185/
> 
> -- 
> << Tout n'y est pas parfait, mais on y honore
> certainement les
> jardiniers >>
> 
> Dominique Quatravaux <dom@kilimandjaro.dyndns.org>
> 
>  

-----------------------------------------------------------------
Yahoo!©_¼¯Messenger6.0
«H½c·f°t§Y®É³q, ·¾³q¼Ö½ìµL½a! 
http://tw.messenger.yahoo.com/

From jbglaw@dvmwest.gt.owl.de Tue Jun 15 11:39:00 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 15 Jun 2004 11:39:05 +0100 (BST)
Received: from dvmwest.gt.owl.de ([IPv6:::ffff:62.52.24.140]:41940 "EHLO
	dvmwest.gt.owl.de") by linux-mips.org with ESMTP
	id <S8225717AbUFOKjA>; Tue, 15 Jun 2004 11:39:00 +0100
Received: by dvmwest.gt.owl.de (Postfix, from userid 1001)
	id 4AC564B770; Tue, 15 Jun 2004 12:38:59 +0200 (CEST)
Date: Tue, 15 Jun 2004 12:38:59 +0200
From: Jan-Benedict Glaw <jbglaw@lug-owl.de>
To: linux-mips@linux-mips.org
Subject: Re: "No such device" with PCI card
Message-ID: <20040615103859.GC20632@lug-owl.de>
Mail-Followup-To: linux-mips@linux-mips.org
References: <40CEBB36.1030707@kilimandjaro.dyndns.org> <20040615102708.42219.qmail@web16604.mail.tpe.yahoo.com>
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="bSFom/N6fjApd2mh"
Content-Disposition: inline
In-Reply-To: <20040615102708.42219.qmail@web16604.mail.tpe.yahoo.com>
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.6i
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: 5312
X-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


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

On Tue, 2004-06-15 18:27:08 +0800, jospehchan <jospehchan@yahoo.com.tw>
wrote in message <20040615102708.42219.qmail@web16604.mail.tpe.yahoo.com>:
> Hi Dominique,
> Thanks for your suggestion and help.
> I've tried my VIA VT6212L USB2.0 PCI card on other
> Linux system(x86 based) (RedHat 7.2 + kernel 2.4.16).=20
> And it works fine under kernel 2.4.16 with an USB
> patch from kernel 2.4.26.
> So I migrated the system to MIPS, but I was stuck by
> this problem.
> Altough I'm not familiar with device driver, but I
> will try Jan-Benedict's suggestion.

Before I get mixed up by pure confusion, let's put all the facts on the
table:

- What kind of MIPS system do you use *exactly*? What board? Which
  kernel version? From where did you get your sources.

  Some hint right here:
  	- If this isn't a very current 2.6.x CVS checkout from
	  linux-mips.org, you'd consider getting that. I won't recommend
	  anything else (possibly MVista has better ported kernels for
	  some specific boards?).

- A USB2.0 card is IMHO driven by the ehci driver, but I may be wrong.
  I'm not exactly a regular USB user...

- Do you have output of "lspci", "lspci -v", "lspci -n", "lspci -vn" and
  "lspci -nxxx" at your hand, once from your i386 test machine, once
  from the MIPS board? Right, those commands mostly give the same
  output, but each style eases reading for specific values:)

- Does your MOPS board have working on-board PCI devices? These don't
  neccessarily have a PCI plug as you know them from add-on cards,
  because they're directly built into the chipset. For instance, does
  your board have onboard IDE interfaces?

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));

--bSFom/N6fjApd2mh
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)

iD8DBQFAztHDHb1edYOZ4bsRAkMoAKCRxdfj831z8SQLRzPCtl4np0H64ACfZHhR
GmgNbgLmZqfMOCDb0fIcbdA=
=zuj2
-----END PGP SIGNATURE-----

--bSFom/N6fjApd2mh--

From suresh@mistralsoftware.com Tue Jun 15 12:24:55 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 15 Jun 2004 12:24:59 +0100 (BST)
Received: from mistral-243-146-ban.mistralsoftware.com ([IPv6:::ffff:203.196.146.243]:29927
	"EHLO Mistralsoftware.com") by linux-mips.org with ESMTP
	id <S8225806AbUFOLYz>; Tue, 15 Jun 2004 12:24:55 +0100
Received: from sarge ([192.168.13.230])
	by mistralsoftware.com (mistralsoftware.com [192.168.10.12])
	(MDaemon.PRO.v7.1.0.R)
	with ESMTP id md50000234653.msg
	for <linux-mips@linux-mips.org>; Tue, 15 Jun 2004 16:57:23 +0530
Subject: PCMCIA VR4131
From: "Suresh. R" <suresh@mistralsoftware.com>
Reply-To: suresh@mistralsoftware.com
To: linux-mips@linux-mips.org
Content-Type: text/plain
Organization: Mistral Software, Bangalore
Message-Id: <1087299491.2974.8.camel@sarge>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.4.6 
Date: Tue, 15 Jun 2004 17:08:12 +0530
Content-Transfer-Encoding: 7bit
X-Spam-Processed: mistralsoftware.com, Tue, 15 Jun 2004 16:57:23 +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
X-MDAV-Processed: mistralsoftware.com, Tue, 15 Jun 2004 16:57:32 +0530
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: 5313
X-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,
  I am modifying the PCMCIA driver (linux 2.4.18 for mips) to make it
work it with the Richo controller(RF5C296). I made some hack and now the
driver is able to detect the type of controller and also the cardmgr is
detecting the type of the card plugged in properly(and properly
inserting the module for that card). But then (I am right now just
trying to make the CF storage card work with the kernel) when I load all
the modules and then run cardmgr and insert the card, I am getting the
following message. 

ide0: ports already in use, skipping probe

This messages keeps repeating for some time and then it stops saying the
resource is busy.

The pcmcia driver is right now working in the polling mode. Please help
me, if someone has done it before. I just modified the MEM base and IO
base and now outb and inb are reading from that location. So I think the
CIS is being read properly. What could be wrong ?.

Thanks in advance

Regards
Suresh



-- 
 .''`.     Suresh. R <suresh@mylug.org>
: :'  :    Proud Debian User
`. `'`
  `-  Debian - when you have better things to do than fixing a system



From macro@ds2.pg.gda.pl Tue Jun 15 14:57:41 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 15 Jun 2004 14:57:46 +0100 (BST)
Received: from jurand.ds.pg.gda.pl ([IPv6:::ffff:153.19.208.2]:31419 "EHLO
	jurand.ds.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8225841AbUFON5l>; Tue, 15 Jun 2004 14:57:41 +0100
Received: by jurand.ds.pg.gda.pl (Postfix, from userid 1011)
	id 09FD2478A3; Tue, 15 Jun 2004 15:57:29 +0200 (CEST)
Received: from localhost (localhost [127.0.0.1])
	by jurand.ds.pg.gda.pl (Postfix) with ESMTP
	id E09F445837; Tue, 15 Jun 2004 15:57:29 +0200 (CEST)
Date: Tue, 15 Jun 2004 15:57:29 +0200 (CEST)
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To: Ralf Baechle <ralf@linux-mips.org>
Cc: "Bradley D. LaRonde" <brad@laronde.org>, linux-mips@linux-mips.org
Subject: Re: inconsistent operand constraints in 'asm' in unaligned.h:66
 using gcc 3.4
In-Reply-To: <20040423131445.GA16274@linux-mips.org>
Message-ID: <Pine.LNX.4.55.0406151552500.22664@jurand.ds.pg.gda.pl>
References: <06d601c428e2$3ba1dcc0$8d01010a@prefect>
 <Pine.LNX.4.55.0404231454120.14494@jurand.ds.pg.gda.pl>
 <20040423131445.GA16274@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: 5314
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: macro@ds2.pg.gda.pl
Precedence: bulk
X-list: linux-mips

On Fri, 23 Apr 2004, Ralf Baechle wrote:

> >  Ralf, I can see 2.6 already does the right thing -- I suppose you won't
> > mind me backporting (copying?) it?
> 
> I certainly won't.  I think the 2.4 implementation was originally written
> necessary upto egcs 1.0 which were generating correct but very inefficient
> code for __attribute((packed)).

 I've applied the following changes, which update the files to the
corresponding one from 2.6, modulo trivial formatting fixes.

 We may consider renaming function arguments to something less
Alpha-specific in the future. ;-)

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

patch-mips-2.4.26-20040531-mips-unaligned-1
diff -up --recursive --new-file linux-mips-2.4.26-20040531.macro/include/asm-mips/unaligned.h linux-mips-2.4.26-20040531/include/asm-mips/unaligned.h
--- linux-mips-2.4.26-20040531.macro/include/asm-mips/unaligned.h	2002-08-06 02:58:21.000000000 +0000
+++ linux-mips-2.4.26-20040531/include/asm-mips/unaligned.h	2004-06-14 20:53:34.000000000 +0000
@@ -3,157 +3,142 @@
  * License.  See the file "COPYING" in the main directory of this archive
  * for more details.
  *
- * Copyright (C) 1996, 1999, 2000 by Ralf Baechle
- * Copyright (C) 1999, 2000 Silicon Graphics, Inc.
+ * Copyright (C) 1996, 1999, 2000, 2001, 2003 by Ralf Baechle
+ * Copyright (C) 1999, 2000, 2001 Silicon Graphics, Inc.
  */
 #ifndef _ASM_UNALIGNED_H
 #define _ASM_UNALIGNED_H
 
-extern void __get_unaligned_bad_length(void);
-extern void __put_unaligned_bad_length(void);
+#include <linux/types.h>
 
 /*
- * Load double unaligned.
+ * get_unaligned - get value from possibly mis-aligned location
+ * @ptr: pointer to value
+ *
+ * This macro should be used for accessing values larger in size than
+ * single bytes at locations that are expected to be improperly aligned,
+ * e.g. retrieving a u16 value from a location not u16-aligned.
  *
- * This could have been implemented in plain C like IA64 but egcs 1.0.3a
- * inflates this to 23 instructions ...
+ * Note that unaligned accesses can be very expensive on some architectures.
  */
-static inline unsigned long long __ldq_u(const unsigned long long * __addr)
-{
-	unsigned long long __res;
+#define get_unaligned(ptr) \
+	((__typeof__(*(ptr)))__get_unaligned((ptr), sizeof(*(ptr))))
 
-	__asm__("ulw\t%0, %1\n\t"
-		"ulw\t%D0, 4+%1"
-		: "=&r" (__res)
-		: "m" (*__addr));
-
-	return __res;
-}
+/*
+ * put_unaligned - put value to a possibly mis-aligned location
+ * @val: value to place
+ * @ptr: pointer to location
+ *
+ * This macro should be used for placing values larger in size than
+ * single bytes at locations that are expected to be improperly aligned,
+ * e.g. writing a u16 value to a location not u16-aligned.
+ *
+ * Note that unaligned accesses can be very expensive on some architectures.
+ */
+#define put_unaligned(x,ptr) \
+	__put_unaligned((__u64)(x), (ptr), sizeof(*(ptr)))
 
 /*
- * Load word unaligned.
+ * This is a silly but good way to make sure that
+ * the get/put functions are indeed always optimized,
+ * and that we use the correct sizes.
  */
-static inline unsigned long __ldl_u(const unsigned int * __addr)
-{
-	unsigned long __res;
+extern void bad_unaligned_access_length(void);
 
-	__asm__("ulw\t%0,%1"
-		: "=&r" (__res)
-		: "m" (*__addr));
+/*
+ * EGCS 1.1 knows about arbitrary unaligned loads.  Define some
+ * packed structures to talk about such things with.
+ */
 
-	return __res;
-}
+struct __una_u64 { __u64 x __attribute__((packed)); };
+struct __una_u32 { __u32 x __attribute__((packed)); };
+struct __una_u16 { __u16 x __attribute__((packed)); };
 
 /*
- * Load halfword unaligned.
+ * Elemental unaligned loads
  */
-static inline unsigned long __ldw_u(const unsigned short * __addr)
+
+static inline __u64 __uldq(const __u64 * r11)
 {
-	unsigned long __res;
+	const struct __una_u64 *ptr = (const struct __una_u64 *) r11;
+	return ptr->x;
+}
 
-	__asm__("ulh\t%0,%1"
-		: "=&r" (__res)
-		: "m" (*__addr));
+static inline __u32 __uldl(const __u32 * r11)
+{
+	const struct __una_u32 *ptr = (const struct __una_u32 *) r11;
+	return ptr->x;
+}
 
-	return __res;
+static inline __u16 __uldw(const __u16 * r11)
+{
+	const struct __una_u16 *ptr = (const struct __una_u16 *) r11;
+	return ptr->x;
 }
 
 /*
- * Store doubleword ununaligned.
+ * Elemental unaligned stores
  */
-static inline void __stq_u(unsigned long __val, unsigned long long * __addr)
+
+static inline void __ustq(__u64 r5, __u64 * r11)
 {
-	__asm__("usw\t%1, %0\n\t"
-		"usw\t%D1, 4+%0"
-		: "=m" (*__addr)
-		: "r" (__val));
+	struct __una_u64 *ptr = (struct __una_u64 *) r11;
+	ptr->x = r5;
 }
 
-/*
- * Store long ununaligned.
- */
-static inline void __stl_u(unsigned long __val, unsigned int * __addr)
+static inline void __ustl(__u32 r5, __u32 * r11)
 {
-	__asm__("usw\t%1, %0"
-		: "=m" (*__addr)
-		: "r" (__val));
+	struct __una_u32 *ptr = (struct __una_u32 *) r11;
+	ptr->x = r5;
 }
 
-/*
- * Store word ununaligned.
- */
-static inline void __stw_u(unsigned long __val, unsigned short * __addr)
+static inline void __ustw(__u16 r5, __u16 * r11)
 {
-	__asm__("ush\t%1, %0"
-		: "=m" (*__addr)
-		: "r" (__val));
+	struct __una_u16 *ptr = (struct __una_u16 *) r11;
+	ptr->x = r5;
 }
 
-/*
- * get_unaligned - get value from possibly mis-aligned location
- * @ptr: pointer to value
- *
- * This macro should be used for accessing values larger in size than
- * single bytes at locations that are expected to be improperly aligned,
- * e.g. retrieving a u16 value from a location not u16-aligned.
- *
- * Note that unaligned accesses can be very expensive on some architectures.
- */
-#define get_unaligned(ptr)						\
-({									\
-	__typeof__(*(ptr)) __val;					\
-									\
-	switch (sizeof(*(ptr))) {					\
-	case 1:								\
-		__val = *(const unsigned char *)ptr;			\
-		break;							\
-	case 2:								\
-		__val = __ldw_u((const unsigned short *)ptr);		\
-		break;							\
-	case 4:								\
-		__val = __ldl_u((const unsigned int *)ptr);		\
-		break;							\
-	case 8:								\
-		__val = __ldq_u((const unsigned long long *)ptr);	\
-		break;							\
-	default:							\
-		__get_unaligned_bad_length();				\
-		break;							\
-	}								\
-									\
-	__val;								\
-})
+static inline __u64 __get_unaligned(const void *ptr, size_t size)
+{
+	__u64 val;
 
-/*
- * put_unaligned - put value to a possibly mis-aligned location
- * @val: value to place
- * @ptr: pointer to location
- *
- * This macro should be used for placing values larger in size than
- * single bytes at locations that are expected to be improperly aligned,
- * e.g. writing a u16 value to a location not u16-aligned.
- *
- * Note that unaligned accesses can be very expensive on some architectures.
- */
-#define put_unaligned(val,ptr)						\
-do {									\
-	switch (sizeof(*(ptr))) {					\
-	case 1:								\
-		*(unsigned char *)(ptr) = (val);			\
-		break;							\
-	case 2:								\
-		__stw_u(val, (unsigned short *)(ptr));			\
-		break;							\
-	case 4:								\
-		__stl_u(val, (unsigned int *)(ptr));			\
-		break;							\
-	case 8:								\
-		__stq_u(val, (unsigned long long *)(ptr));		\
-		break;							\
-	default:							\
-		__put_unaligned_bad_length();				\
-		break;							\
-	}								\
-} while(0)
+	switch (size) {
+	case 1:
+		val = *(const __u8 *)ptr;
+		break;
+	case 2:
+		val = __uldw((const __u16 *)ptr);
+		break;
+	case 4:
+		val = __uldl((const __u32 *)ptr);
+		break;
+	case 8:
+		val = __uldq((const __u64 *)ptr);
+		break;
+	default:
+		bad_unaligned_access_length();
+	}
+	return val;
+}
+
+static inline void __put_unaligned(__u64 val, void *ptr, size_t size)
+{
+	switch (size) {
+	      case 1:
+		*(__u8 *)ptr = (val);
+	        break;
+	      case 2:
+		__ustw(val, (__u16 *)ptr);
+		break;
+	      case 4:
+		__ustl(val, (__u32 *)ptr);
+		break;
+	      case 8:
+		__ustq(val, (__u64 *)ptr);
+		break;
+	      default:
+	    	bad_unaligned_access_length();
+	}
+}
 
 #endif /* _ASM_UNALIGNED_H */
diff -up --recursive --new-file linux-mips-2.4.26-20040531.macro/include/asm-mips64/unaligned.h linux-mips-2.4.26-20040531/include/asm-mips64/unaligned.h
--- linux-mips-2.4.26-20040531.macro/include/asm-mips64/unaligned.h	2002-10-02 17:22:56.000000000 +0000
+++ linux-mips-2.4.26-20040531/include/asm-mips64/unaligned.h	2004-06-14 20:53:34.000000000 +0000
@@ -3,152 +3,142 @@
  * License.  See the file "COPYING" in the main directory of this archive
  * for more details.
  *
- * Copyright (C) 1996, 1999, 2000, 2001 by Ralf Baechle
+ * Copyright (C) 1996, 1999, 2000, 2001, 2003 by Ralf Baechle
  * Copyright (C) 1999, 2000, 2001 Silicon Graphics, Inc.
  */
 #ifndef _ASM_UNALIGNED_H
 #define _ASM_UNALIGNED_H
 
-extern void __get_unaligned_bad_length(void);
-extern void __put_unaligned_bad_length(void);
+#include <linux/types.h>
 
 /*
- * Load quad unaligned.
+ * get_unaligned - get value from possibly mis-aligned location
+ * @ptr: pointer to value
+ *
+ * This macro should be used for accessing values larger in size than
+ * single bytes at locations that are expected to be improperly aligned,
+ * e.g. retrieving a u16 value from a location not u16-aligned.
+ *
+ * Note that unaligned accesses can be very expensive on some architectures.
  */
-static inline unsigned long __ldq_u(const unsigned long * __addr)
-{
-	unsigned long __res;
-
-	__asm__("uld\t%0,%1"
-		: "=&r" (__res)
-		: "m" (*__addr));
+#define get_unaligned(ptr) \
+	((__typeof__(*(ptr)))__get_unaligned((ptr), sizeof(*(ptr))))
 
-	return __res;
-}
+/*
+ * put_unaligned - put value to a possibly mis-aligned location
+ * @val: value to place
+ * @ptr: pointer to location
+ *
+ * This macro should be used for placing values larger in size than
+ * single bytes at locations that are expected to be improperly aligned,
+ * e.g. writing a u16 value to a location not u16-aligned.
+ *
+ * Note that unaligned accesses can be very expensive on some architectures.
+ */
+#define put_unaligned(x,ptr) \
+	__put_unaligned((__u64)(x), (ptr), sizeof(*(ptr)))
 
 /*
- * Load long unaligned.
+ * This is a silly but good way to make sure that
+ * the get/put functions are indeed always optimized,
+ * and that we use the correct sizes.
  */
-static inline unsigned long __ldl_u(const unsigned int * __addr)
-{
-	unsigned long __res;
+extern void bad_unaligned_access_length(void);
 
-	__asm__("ulw\t%0,%1"
-		: "=&r" (__res)
-		: "m" (*__addr));
+/*
+ * EGCS 1.1 knows about arbitrary unaligned loads.  Define some
+ * packed structures to talk about such things with.
+ */
 
-	return __res;
-}
+struct __una_u64 { __u64 x __attribute__((packed)); };
+struct __una_u32 { __u32 x __attribute__((packed)); };
+struct __una_u16 { __u16 x __attribute__((packed)); };
 
 /*
- * Load word unaligned.
+ * Elemental unaligned loads
  */
-static inline unsigned long __ldw_u(const unsigned short * __addr)
+
+static inline __u64 __uldq(const __u64 * r11)
 {
-	unsigned long __res;
+	const struct __una_u64 *ptr = (const struct __una_u64 *) r11;
+	return ptr->x;
+}
 
-	__asm__("ulh\t%0,%1"
-		: "=&r" (__res)
-		: "m" (*__addr));
+static inline __u32 __uldl(const __u32 * r11)
+{
+	const struct __una_u32 *ptr = (const struct __una_u32 *) r11;
+	return ptr->x;
+}
 
-	return __res;
+static inline __u16 __uldw(const __u16 * r11)
+{
+	const struct __una_u16 *ptr = (const struct __una_u16 *) r11;
+	return ptr->x;
 }
 
 /*
- * Store quad unaligned.
+ * Elemental unaligned stores
  */
-static inline void __stq_u(unsigned long __val, unsigned long * __addr)
+
+static inline void __ustq(__u64 r5, __u64 * r11)
 {
-	__asm__("usd\t%1, %0"
-		: "=m" (*__addr)
-		: "r" (__val));
+	struct __una_u64 *ptr = (struct __una_u64 *) r11;
+	ptr->x = r5;
 }
 
-/*
- * Store long unaligned.
- */
-static inline void __stl_u(unsigned long __val, unsigned int * __addr)
+static inline void __ustl(__u32 r5, __u32 * r11)
 {
-	__asm__("usw\t%1, %0"
-		: "=m" (*__addr)
-		: "r" (__val));
+	struct __una_u32 *ptr = (struct __una_u32 *) r11;
+	ptr->x = r5;
 }
 
-/*
- * Store word unaligned.
- */
-static inline void __stw_u(unsigned long __val, unsigned short * __addr)
+static inline void __ustw(__u16 r5, __u16 * r11)
 {
-	__asm__("ush\t%1, %0"
-		: "=m" (*__addr)
-		: "r" (__val));
+	struct __una_u16 *ptr = (struct __una_u16 *) r11;
+	ptr->x = r5;
 }
 
-/*
- * get_unaligned - get value from possibly mis-aligned location
- * @ptr: pointer to value
- *
- * This macro should be used for accessing values larger in size than
- * single bytes at locations that are expected to be improperly aligned,
- * e.g. retrieving a u16 value from a location not u16-aligned.
- *
- * Note that unaligned accesses can be very expensive on some architectures.
- */
-#define get_unaligned(ptr)						\
-({									\
-	__typeof__(*(ptr)) __val;					\
-									\
-	switch (sizeof(*(ptr))) {					\
-	case 1:								\
-		__val = *(const unsigned char *)(ptr);			\
-		break;							\
-	case 2:								\
-		__val = __ldw_u((const unsigned short *)(ptr));		\
-		break;							\
-	case 4:								\
-		__val = __ldl_u((const unsigned int *)(ptr));		\
-		break;							\
-	case 8:								\
-		__val = __ldq_u((const unsigned long *)(ptr));		\
-		break;							\
-	default:							\
-		__get_unaligned_bad_length();				\
-		break;							\
-	}								\
-									\
-	__val;								\
-})
+static inline __u64 __get_unaligned(const void *ptr, size_t size)
+{
+	__u64 val;
 
-/*
- * put_unaligned - put value to a possibly mis-aligned location
- * @val: value to place
- * @ptr: pointer to location
- *
- * This macro should be used for placing values larger in size than
- * single bytes at locations that are expected to be improperly aligned,
- * e.g. writing a u16 value to a location not u16-aligned.
- *
- * Note that unaligned accesses can be very expensive on some architectures.
- */
-#define put_unaligned(val,ptr)						\
-do {									\
-	switch (sizeof(*(ptr))) {					\
-	case 1:								\
-		*(unsigned char *)(ptr) = (val);			\
-		break;							\
-	case 2:								\
-		__stw_u((val), (unsigned short *)(ptr));		\
-		break;							\
-	case 4:								\
-		__stl_u((val), (unsigned int *)(ptr));			\
-		break;							\
-	case 8:								\
-		__stq_u((val), (unsigned long long *)(ptr));		\
-		break;							\
-	default:							\
-		__put_unaligned_bad_length();				\
-		break;							\
-	}								\
-} while(0)
+	switch (size) {
+	case 1:
+		val = *(const __u8 *)ptr;
+		break;
+	case 2:
+		val = __uldw((const __u16 *)ptr);
+		break;
+	case 4:
+		val = __uldl((const __u32 *)ptr);
+		break;
+	case 8:
+		val = __uldq((const __u64 *)ptr);
+		break;
+	default:
+		bad_unaligned_access_length();
+	}
+	return val;
+}
+
+static inline void __put_unaligned(__u64 val, void *ptr, size_t size)
+{
+	switch (size) {
+	      case 1:
+		*(__u8 *)ptr = (val);
+	        break;
+	      case 2:
+		__ustw(val, (__u16 *)ptr);
+		break;
+	      case 4:
+		__ustl(val, (__u32 *)ptr);
+		break;
+	      case 8:
+		__ustq(val, (__u64 *)ptr);
+		break;
+	      default:
+	    	bad_unaligned_access_length();
+	}
+}
 
 #endif /* _ASM_UNALIGNED_H */

From yuasa@hh.iij4u.or.jp Tue Jun 15 15:01:07 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 15 Jun 2004 15:01:12 +0100 (BST)
Received: from mo02.iij4u.or.jp ([IPv6:::ffff:210.130.0.19]:4583 "EHLO
	mo02.iij4u.or.jp") by linux-mips.org with ESMTP id <S8225841AbUFOOBH>;
	Tue, 15 Jun 2004 15:01:07 +0100
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 XAA11569;
	Tue, 15 Jun 2004 23:01:01 +0900 (JST)
Received: 4UMDO00 id i5FE10B21708; Tue, 15 Jun 2004 23:01:01 +0900 (JST)
Received: 4UMRO01 id i5FE0vS02170; Tue, 15 Jun 2004 23:00:58 +0900 (JST)
	from stratos (64.43.138.210.xn.2iij.net [210.138.43.64]) (authenticated)
Date: Tue, 15 Jun 2004 23:00:56 +0900
From: Yoichi Yuasa <yuasa@hh.iij4u.or.jp>
To: suresh@mistralsoftware.com
Cc: linux-mips@linux-mips.org
Subject: Re: PCMCIA VR4131
Message-Id: <20040615230056.2480e18f.yuasa@hh.iij4u.or.jp>
In-Reply-To: <1087299491.2974.8.camel@sarge>
References: <1087299491.2974.8.camel@sarge>
X-Mailer: Sylpheed version 0.9.11 (GTK+ 1.2.10; i386-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: 5315
X-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

Hi

On Tue, 15 Jun 2004 17:08:12 +0530
"Suresh. R" <suresh@mistralsoftware.com> wrote:

> Hi,
>   I am modifying the PCMCIA driver (linux 2.4.18 for mips) to make it
> work it with the Richo controller(RF5C296). I made some hack and now the
> driver is able to detect the type of controller and also the cardmgr is
> detecting the type of the card plugged in properly(and properly
> inserting the module for that card). But then (I am right now just
> trying to make the CF storage card work with the kernel) when I load all
> the modules and then run cardmgr and insert the card, I am getting the
> following message. 
> 
> ide0: ports already in use, skipping probe
> 
> This messages keeps repeating for some time and then it stops saying the
> resource is busy.

What did you set ioport range in your config.opts?

> The pcmcia driver is right now working in the polling mode. Please help
> me, if someone has done it before. I just modified the MEM base and IO
> base and now outb and inb are reading from that location. So I think the
> CIS is being read properly. What could be wrong ?.

Yoichi

From jsun@mvista.com Wed Jun 16 03:10:29 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 16 Jun 2004 03:10:33 +0100 (BST)
Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:14578 "EHLO
	orion.mvista.com") by linux-mips.org with ESMTP id <S8226048AbUFPCK3>;
	Wed, 16 Jun 2004 03:10:29 +0100
Received: from orion.mvista.com (localhost.localdomain [127.0.0.1])
	by orion.mvista.com (8.12.8/8.12.8) with ESMTP id i5G2AO4O029564;
	Tue, 15 Jun 2004 19:10:24 -0700
Received: (from jsun@localhost)
	by orion.mvista.com (8.12.8/8.12.8/Submit) id i5G2ANvO029563;
	Tue, 15 Jun 2004 19:10:23 -0700
Date: Tue, 15 Jun 2004 19:10:23 -0700
From: Jun Sun <jsun@mvista.com>
To: linux-kernel@vger.kernel.org, linux-mips@linux-mips.org
Cc: jsun@mvista.com
Subject: [PATCH] make ps2 mouse work ...
Message-ID: <20040615191023.G28403@mvista.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="FCuugMFkClbJLl1L"
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: 5316
X-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


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


I found this problem on a MIPS machine.  The problem is 
likely to happen on other register-rich RISC arches too.

cmdcnt needs to be volatile since it is modified by
irq routine and read by normal process context.

Jun

--FCuugMFkClbJLl1L
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="040615.a-psmouse-cmdcnt-volatile.patch"

diff -Nru linux/drivers/input/mouse/psmouse.h.orig linux/drivers/input/mouse/psmouse.h
--- linux/drivers/input/mouse/psmouse.h.orig	2004-04-16 15:28:47.000000000 -0700
+++ linux/drivers/input/mouse/psmouse.h	2004-06-15 18:51:53.000000000 -0700
@@ -40,7 +40,7 @@
 	char *name;
 	unsigned char cmdbuf[8];
 	unsigned char packet[8];
-	unsigned char cmdcnt;
+	volatile unsigned char cmdcnt;
 	unsigned char pktcnt;
 	unsigned char type;
 	unsigned char model;

--FCuugMFkClbJLl1L--

From akpm@osdl.org Wed Jun 16 04:57:22 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 16 Jun 2004 04:57:26 +0100 (BST)
Received: from fw.osdl.org ([IPv6:::ffff:65.172.181.6]:61862 "EHLO
	mail.osdl.org") by linux-mips.org with ESMTP id <S8224791AbUFPD5W>;
	Wed, 16 Jun 2004 04:57:22 +0100
Received: from bix (build.pdx.osdl.net [172.20.1.2])
	by mail.osdl.org (8.11.6/8.11.6) with SMTP id i5G3v0r06879;
	Tue, 15 Jun 2004 20:57:00 -0700
Date: Tue, 15 Jun 2004 20:56:11 -0700
From: Andrew Morton <akpm@osdl.org>
To: Jun Sun <jsun@mvista.com>
Cc: linux-kernel@vger.kernel.org, linux-mips@linux-mips.org,
	jsun@mvista.com
Subject: Re: [PATCH] make ps2 mouse work ...
Message-Id: <20040615205611.1e9cbfcc.akpm@osdl.org>
In-Reply-To: <20040615191023.G28403@mvista.com>
References: <20040615191023.G28403@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: <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: 5317
X-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 found this problem on a MIPS machine.  The problem is 
> likely to happen on other register-rich RISC arches too.
> 
> cmdcnt needs to be volatile since it is modified by
> irq routine and read by normal process context.

volatile is not the preferred way to fix this up.  This points at either a
locking error in the psmouse driver or a missing "memory" thingy in the
mips port somewhere.

Please describe the bug which led to this patch.  Where was it getting stuck?


From bhavyashree@tataelxsi.co.in Wed Jun 16 08:06:24 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 16 Jun 2004 08:06:29 +0100 (BST)
Received: from vmail.vsnl.com ([IPv6:::ffff:203.199.113.69]:24282 "EHLO
	vmail.vsnl.com") by linux-mips.org with ESMTP id <S8225236AbUFPHGY>;
	Wed, 16 Jun 2004 08:06:24 +0100
Received: from bhavyashree ([127.0.0.1])
 by vmail.vsnl.com (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14
 2003)) with SMTP id <0HZE00DW43QENJ@vmail.vsnl.com> for
 linux-mips@linux-mips.org; Wed, 16 Jun 2004 12:36:15 +0530 (IST)
Received: from ([tataelxsi.co.in (203.197.168.145)])
 by vmail.vsnl.com	(InterScan E-Mail VirusWall Unix); Wed,
 16 Jun 2004 12:36:15 +0530 (IST)
Date: Wed, 16 Jun 2004 12:36:14 +0530
From: Bhavyashree <bhavyashree@tataelxsi.co.in>
Subject: Cross compiler tool chain
To: linux-mips@linux-mips.org
Reply-to: bhavyashree@tataelxsi.co.in
Message-id: <002601c45370$6a221e80$e301090a@telxsi.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0)
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 7BIT
Importance: Normal
X-Priority: 3 (Normal)
X-MSMail-priority: Normal
Return-Path: <bhavyashree@tataelxsi.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: 5318
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: bhavyashree@tataelxsi.co.in
Precedence: bulk
X-list: linux-mips

hi,
  I am new to mips. Please let me know from where cani get mips-linux tool
chain package. i am not able to download it from linux-mips.org. where else
it is available.

thanks and regards,
sri



From ppopov@mvista.com Wed Jun 16 08:16:01 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 16 Jun 2004 08:16:06 +0100 (BST)
Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:21492 "EHLO
	av.mvista.com") by linux-mips.org with ESMTP id <S8225236AbUFPHQB>;
	Wed, 16 Jun 2004 08:16:01 +0100
Received: from [10.2.2.63] (av [127.0.0.1])
	by av.mvista.com (8.9.3/8.9.3) with ESMTP id AAA21863;
	Wed, 16 Jun 2004 00:15:54 -0700
Subject: Re: Cross compiler tool chain
From: Pete Popov <ppopov@mvista.com>
To: bhavyashree@tataelxsi.co.in
Cc: linux-mips@linux-mips.org
In-Reply-To: <002601c45370$6a221e80$e301090a@telxsi.com>
References: <002601c45370$6a221e80$e301090a@telxsi.com>
Content-Type: text/plain
Organization: 
Message-Id: <1087370135.10067.11.camel@thinkpad>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.2.2 (1.2.2-4) 
Date: 16 Jun 2004 00:15:36 -0700
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: 5319
X-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 Wed, 2004-06-16 at 00:06, Bhavyashree wrote:
> hi,
>   I am new to mips. Please let me know from where cani get mips-linux tool
> chain package. i am not able to download it from linux-mips.org. where else
> it is available.

Embedded Edge put a new toolchain on their web site:

http://www.embeddededge.com/downloads/amd-alchemy/

There one for x86 and one for ppc host.


Pete

> 
> thanks and regards,
> sri
> 
> 
> 


From vojtech@suse.cz Wed Jun 16 13:12:38 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 16 Jun 2004 13:12:43 +0100 (BST)
Received: from gprs187-64.eurotel.cz ([IPv6:::ffff:160.218.187.64]:64128 "EHLO
	midnight.ucw.cz") by linux-mips.org with ESMTP id <S8225544AbUFPMMi>;
	Wed, 16 Jun 2004 13:12:38 +0100
Received: by midnight.ucw.cz (Postfix, from userid 502)
	id D7C7374312; Wed, 16 Jun 2004 14:11:49 +0200 (CEST)
Date: Wed, 16 Jun 2004 14:11:49 +0200
From: Vojtech Pavlik <vojtech@suse.cz>
To: Andrew Morton <akpm@osdl.org>
Cc: Jun Sun <jsun@mvista.com>, linux-kernel@vger.kernel.org,
	linux-mips@linux-mips.org
Subject: Re: [PATCH] make ps2 mouse work ...
Message-ID: <20040616121149.GA9325@ucw.cz>
References: <20040615191023.G28403@mvista.com> <20040615205611.1e9cbfcc.akpm@osdl.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20040615205611.1e9cbfcc.akpm@osdl.org>
User-Agent: Mutt/1.4.1i
Return-Path: <vojtech@suse.cz>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 5320
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: vojtech@suse.cz
Precedence: bulk
X-list: linux-mips

On Tue, Jun 15, 2004 at 08:56:11PM -0700, Andrew Morton wrote:

> > I found this problem on a MIPS machine.  The problem is 
> > likely to happen on other register-rich RISC arches too.
> > 
> > cmdcnt needs to be volatile since it is modified by
> > irq routine and read by normal process context.
> 
> volatile is not the preferred way to fix this up.  This points at either a
> locking error in the psmouse driver or a missing "memory" thingy in the
> mips port somewhere.
> 
> Please describe the bug which led to this patch.  Where was it getting stuck?

My current BK tree has this fixed using atomic bitfields, which do
compilation and memory barriers. I plan to sync it to Linus post 2.6.7.

-- 
Vojtech Pavlik
SuSE Labs, SuSE CR

From jsun@mvista.com Wed Jun 16 18:04:49 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 16 Jun 2004 18:04:53 +0100 (BST)
Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:52723 "EHLO
	orion.mvista.com") by linux-mips.org with ESMTP id <S8225617AbUFPREt>;
	Wed, 16 Jun 2004 18:04:49 +0100
Received: from orion.mvista.com (localhost.localdomain [127.0.0.1])
	by orion.mvista.com (8.12.8/8.12.8) with ESMTP id i5GH4l4O032121;
	Wed, 16 Jun 2004 10:04:47 -0700
Received: (from jsun@localhost)
	by orion.mvista.com (8.12.8/8.12.8/Submit) id i5GH4kfo032120;
	Wed, 16 Jun 2004 10:04:46 -0700
Date: Wed, 16 Jun 2004 10:04:46 -0700
From: Jun Sun <jsun@mvista.com>
To: Vojtech Pavlik <vojtech@suse.cz>
Cc: Andrew Morton <akpm@osdl.org>, linux-kernel@vger.kernel.org,
	linux-mips@linux-mips.org, jsun@mvista.com
Subject: Re: [PATCH] make ps2 mouse work ...
Message-ID: <20040616100446.J28403@mvista.com>
References: <20040615191023.G28403@mvista.com> <20040615205611.1e9cbfcc.akpm@osdl.org> <20040616121149.GA9325@ucw.cz>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <20040616121149.GA9325@ucw.cz>; from vojtech@suse.cz on Wed, Jun 16, 2004 at 02:11:49PM +0200
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: 5321
X-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, Jun 16, 2004 at 02:11:49PM +0200, Vojtech Pavlik wrote:
> On Tue, Jun 15, 2004 at 08:56:11PM -0700, Andrew Morton wrote:
> 
> > > I found this problem on a MIPS machine.  The problem is 
> > > likely to happen on other register-rich RISC arches too.
> > > 
> > > cmdcnt needs to be volatile since it is modified by
> > > irq routine and read by normal process context.
> > 
> > volatile is not the preferred way to fix this up.  This points at either a
> > locking error in the psmouse driver or a missing "memory" thingy in the
> > mips port somewhere.
> > 
> > Please describe the bug which led to this patch.  Where was it getting stuck?
> 
> My current BK tree has this fixed using atomic bitfields, which do
> compilation and memory barriers. I plan to sync it to Linus post 2.6.7.
> 

Can you post the patch here?  I am sure many people are eagerly waiting
for the right fix.  Plus there will be extra pairs of eyes to exam the fix.

Jun

From vojtech@suse.cz Wed Jun 16 18:57:47 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 16 Jun 2004 18:57:52 +0100 (BST)
Received: from gprs187-64.eurotel.cz ([IPv6:::ffff:160.218.187.64]:29314 "EHLO
	midnight.ucw.cz") by linux-mips.org with ESMTP id <S8225732AbUFPR5r>;
	Wed, 16 Jun 2004 18:57:47 +0100
Received: by midnight.ucw.cz (Postfix, from userid 502)
	id 7CE2974312; Wed, 16 Jun 2004 19:58:11 +0200 (CEST)
Date: Wed, 16 Jun 2004 19:58:11 +0200
From: Vojtech Pavlik <vojtech@suse.cz>
To: Jun Sun <jsun@mvista.com>
Cc: Andrew Morton <akpm@osdl.org>, linux-kernel@vger.kernel.org,
	linux-mips@linux-mips.org
Subject: Re: [PATCH] make ps2 mouse work ...
Message-ID: <20040616175811.GB15401@ucw.cz>
References: <20040615191023.G28403@mvista.com> <20040615205611.1e9cbfcc.akpm@osdl.org> <20040616121149.GA9325@ucw.cz> <20040616100446.J28403@mvista.com>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="AqsLC8rIMeq19msA"
Content-Disposition: inline
In-Reply-To: <20040616100446.J28403@mvista.com>
User-Agent: Mutt/1.4.1i
Return-Path: <vojtech@suse.cz>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 5322
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: vojtech@suse.cz
Precedence: bulk
X-list: linux-mips


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

On Wed, Jun 16, 2004 at 10:04:46AM -0700, Jun Sun wrote:
> On Wed, Jun 16, 2004 at 02:11:49PM +0200, Vojtech Pavlik wrote:
> > On Tue, Jun 15, 2004 at 08:56:11PM -0700, Andrew Morton wrote:
> > 
> > > > I found this problem on a MIPS machine.  The problem is 
> > > > likely to happen on other register-rich RISC arches too.
> > > > 
> > > > cmdcnt needs to be volatile since it is modified by
> > > > irq routine and read by normal process context.
> > > 
> > > volatile is not the preferred way to fix this up.  This points at either a
> > > locking error in the psmouse driver or a missing "memory" thingy in the
> > > mips port somewhere.
> > > 
> > > Please describe the bug which led to this patch.  Where was it getting stuck?
> > 
> > My current BK tree has this fixed using atomic bitfields, which do
> > compilation and memory barriers. I plan to sync it to Linus post 2.6.7.
> > 
> 
> Can you post the patch here?  I am sure many people are eagerly waiting
> for the right fix.  Plus there will be extra pairs of eyes to exam the fix.

Sure. Here it is.

-- 
Vojtech Pavlik
SuSE Labs, SuSE CR

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

You can pull this changeset from:
	bk://kernel.bkbits.net/vojtech/input

===================================================================

ChangeSet@1.1726.55.1, 2004-05-31 15:11:41+02:00, vojtech@suse.cz
  input: Explicit variable access rules for psmouse.c, using bitops.


 mouse/psmouse-base.c |  129 +++++++++++++++++++++++++++++++--------------------
 mouse/psmouse.h      |    9 ++-
 3 files changed, 87 insertions(+), 53 deletions(-)

===================================================================

diff -Nru a/drivers/input/mouse/psmouse-base.c b/drivers/input/mouse/psmouse-base.c
--- a/drivers/input/mouse/psmouse-base.c	2004-06-16 19:56:46 +02:00
+++ b/drivers/input/mouse/psmouse-base.c	2004-06-16 19:56:46 +02:00
@@ -142,34 +142,45 @@
 			printk(KERN_WARNING "psmouse.c: bad data from KBC -%s%s\n",
 				flags & SERIO_TIMEOUT ? " timeout" : "",
 				flags & SERIO_PARITY ? " bad parity" : "");
-		if (psmouse->acking) {
-			psmouse->ack = -1;
-			psmouse->acking = 0;
-		}
-		psmouse->pktcnt = 0;
+		psmouse->nak = 1;
+		clear_bit(PSMOUSE_FLAG_ACK, &psmouse->flags);
+		clear_bit(PSMOUSE_FLAG_CMD,  &psmouse->flags);
 		goto out;
 	}
 
-	if (psmouse->acking) {
+	if (test_bit(PSMOUSE_FLAG_ACK, &psmouse->flags))
 		switch (data) {
 			case PSMOUSE_RET_ACK:
-				psmouse->ack = 1;
+				psmouse->nak = 0;
+				clear_bit(PSMOUSE_FLAG_ACK, &psmouse->flags);
+				goto out;
 				break;
 			case PSMOUSE_RET_NAK:
-				psmouse->ack = -1;
-				break;
+				psmouse->nak = 1;
+				clear_bit(PSMOUSE_FLAG_ACK, &psmouse->flags);
+				goto out;
 			default:
-				psmouse->ack = 1;	/* Workaround for mice which don't ACK the Get ID command */
-				if (psmouse->cmdcnt)
-					psmouse->cmdbuf[--psmouse->cmdcnt] = data;
-				break;
+				psmouse->nak = 0;	/* Workaround for mice which don't ACK the Get ID command */
+				clear_bit(PSMOUSE_FLAG_ACK, &psmouse->flags);
+				if (!test_bit(PSMOUSE_FLAG_CMD, &psmouse->flags))
+					goto out;
+
 		}
-		psmouse->acking = 0;
-		goto out;
-	}
 
-	if (psmouse->cmdcnt) {
-		psmouse->cmdbuf[--psmouse->cmdcnt] = data;
+	if (test_bit(PSMOUSE_FLAG_CMD, &psmouse->flags)) {
+
+		psmouse->cmdcnt--;
+		psmouse->cmdbuf[psmouse->cmdcnt] = data;
+
+		if (psmouse->cmdcnt == 1) {
+			if (data != 0xab && data != 0xac)
+				clear_bit(PSMOUSE_FLAG_ID, &psmouse->flags);
+			clear_bit(PSMOUSE_FLAG_CMD1, &psmouse->flags);
+		}
+
+		if (!psmouse->cmdcnt)
+			clear_bit(PSMOUSE_FLAG_CMD, &psmouse->flags);
+
 		goto out;
 	}
 
@@ -242,18 +253,15 @@
 
 static int psmouse_sendbyte(struct psmouse *psmouse, unsigned char byte)
 {
-	int timeout = 10000; /* 100 msec */
-	psmouse->ack = 0;
-	psmouse->acking = 1;
+	int timeout = 200000; /* 200 msec */
 
-	if (serio_write(psmouse->serio, byte)) {
-		psmouse->acking = 0;
+	set_bit(PSMOUSE_FLAG_ACK, &psmouse->flags);
+	if (serio_write(psmouse->serio, byte))
 		return -1;
-	}
-
-	while (!psmouse->ack && timeout--) udelay(10);
+	while (test_bit(PSMOUSE_FLAG_ACK, &psmouse->flags) && timeout--) udelay(1);
+	clear_bit(PSMOUSE_FLAG_ACK, &psmouse->flags);
 
-	return -(psmouse->ack <= 0);
+	return -psmouse->nak;
 }
 
 /*
@@ -271,46 +279,62 @@
 	psmouse->cmdcnt = receive;
 
 	if (command == PSMOUSE_CMD_RESET_BAT)
-                timeout = 4000000; /* 4 sec */
+		timeout = 4000000; /* 4 sec */
 
-	/* initialize cmdbuf with preset values from param */
-	if (receive)
-	   for (i = 0; i < receive; i++)
-		psmouse->cmdbuf[(receive - 1) - i] = param[i];
+	if (receive && param)
+		for (i = 0; i < receive; i++)
+			psmouse->cmdbuf[(receive - 1) - i] = param[i];
+
+	if (receive) {
+		set_bit(PSMOUSE_FLAG_CMD, &psmouse->flags);
+		set_bit(PSMOUSE_FLAG_CMD1, &psmouse->flags);
+		set_bit(PSMOUSE_FLAG_ID, &psmouse->flags);
+	}
 
 	if (command & 0xff)
-		if (psmouse_sendbyte(psmouse, command & 0xff))
-			return (psmouse->cmdcnt = 0) - 1;
+		if (psmouse_sendbyte(psmouse, command & 0xff)) {
+			clear_bit(PSMOUSE_FLAG_CMD, &psmouse->flags);
+			return -1;
+		}
 
 	for (i = 0; i < send; i++)
-		if (psmouse_sendbyte(psmouse, param[i]))
-			return (psmouse->cmdcnt = 0) - 1;
+		if (psmouse_sendbyte(psmouse, param[i])) {
+			clear_bit(PSMOUSE_FLAG_CMD, &psmouse->flags);
+			return -1;
+		}
 
-	while (psmouse->cmdcnt && timeout--) {
+	while (test_bit(PSMOUSE_FLAG_CMD, &psmouse->flags) && timeout--) {
 
-		if (psmouse->cmdcnt == 1 && command == PSMOUSE_CMD_RESET_BAT &&
-				timeout > 100000) /* do not run in a endless loop */
-			timeout = 100000; /* 1 sec */
-
-		if (psmouse->cmdcnt == 1 && command == PSMOUSE_CMD_GETID &&
-		    psmouse->cmdbuf[1] != 0xab && psmouse->cmdbuf[1] != 0xac) {
-			psmouse->cmdcnt = 0;
-			break;
+		if (!test_bit(PSMOUSE_FLAG_CMD1, &psmouse->flags)) {
+		    
+			if (command == PSMOUSE_CMD_RESET_BAT && timeout > 100000)
+				timeout = 100000;
+
+			if (command == PSMOUSE_CMD_GETID && !test_bit(PSMOUSE_FLAG_ID, &psmouse->flags)) {
+				clear_bit(PSMOUSE_FLAG_CMD, &psmouse->flags);
+				psmouse->cmdcnt = 0;
+				break;
+			}
 		}
 
 		udelay(1);
 	}
 
-	for (i = 0; i < receive; i++)
-		param[i] = psmouse->cmdbuf[(receive - 1) - i];
+	clear_bit(PSMOUSE_FLAG_CMD, &psmouse->flags);
+
+	if (param)
+		for (i = 0; i < receive; i++)
+			param[i] = psmouse->cmdbuf[(receive - 1) - i];
+
+	if (command == PSMOUSE_CMD_RESET_BAT && psmouse->cmdcnt == 1)
+		return 0;
 
 	if (psmouse->cmdcnt)
-		return (psmouse->cmdcnt = 0) - 1;
+		return -1;
 
 	return 0;
 }
 
-
 /*
  * psmouse_sliced_command() sends an extended PS/2 command to the mouse
  * using sliced syntax, understood by advanced devices, such as Logitech
@@ -735,7 +759,12 @@
 	}
 
 	psmouse->state = PSMOUSE_CMD_MODE;
-	psmouse->acking = psmouse->cmdcnt = psmouse->pktcnt = psmouse->out_of_sync = 0;
+
+	clear_bit(PSMOUSE_FLAG_ACK, &psmouse->flags);
+	clear_bit(PSMOUSE_FLAG_CMD,  &psmouse->flags);
+
+	psmouse->pktcnt = psmouse->out_of_sync = 0;
+
 	if (psmouse->reconnect) {
 	       if (psmouse->reconnect(psmouse))
 			return -1;
diff -Nru a/drivers/input/mouse/psmouse.h b/drivers/input/mouse/psmouse.h
--- a/drivers/input/mouse/psmouse.h	2004-06-16 19:56:46 +02:00
+++ b/drivers/input/mouse/psmouse.h	2004-06-16 19:56:46 +02:00
@@ -22,6 +22,11 @@
 #define PSMOUSE_ACTIVATED	1
 #define PSMOUSE_IGNORE		2
 
+#define PSMOUSE_FLAG_ACK	0	/* Waiting for ACK/NAK */
+#define PSMOUSE_FLAG_CMD	1	/* Waiting for command to finish */
+#define PSMOUSE_FLAG_CMD1	2	/* First byte of command response */
+#define PSMOUSE_FLAG_ID		3	/* First byte is not keyboard ID */
+
 /* psmouse protocol handler return codes */
 typedef enum {
 	PSMOUSE_BAD_DATA,
@@ -54,11 +59,11 @@
 	unsigned long last;
 	unsigned long out_of_sync;
 	unsigned char state;
-	char acking;
-	volatile char ack;
+	unsigned char nak;
 	char error;
 	char devname[64];
 	char phys[32];
+	unsigned long flags;
 
 	psmouse_ret_t (*protocol_handler)(struct psmouse *psmouse, struct pt_regs *regs); 
 	int (*reconnect)(struct psmouse *psmouse);

--AqsLC8rIMeq19msA--

From ralf@linux-mips.org Thu Jun 17 13:31:33 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 17 Jun 2004 13:31:36 +0100 (BST)
Received: from p508B769B.dip.t-dialin.net ([IPv6:::ffff:80.139.118.155]:49709
	"EHLO mail.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225393AbUFQMbd>; Thu, 17 Jun 2004 13:31:33 +0100
Received: from fluff.linux-mips.net (fluff.linux-mips.net [127.0.0.1])
	by mail.linux-mips.net (8.12.11/8.12.8) with ESMTP id i5HCVQmk018649;
	Thu, 17 Jun 2004 14:31:27 +0200
Received: (from ralf@localhost)
	by fluff.linux-mips.net (8.12.11/8.12.11/Submit) id i5HCVQkn018648;
	Thu, 17 Jun 2004 14:31:26 +0200
Date: Thu, 17 Jun 2004 14:31:26 +0200
From: Ralf Baechle <ralf@linux-mips.org>
To: Stanislaw Skowronek <sskowron@ET.PUT.Poznan.PL>
Cc: linux-mips@linux-mips.org
Subject: Re: CONFIG_MDULES patch
Message-ID: <20040617123126.GA18274@linux-mips.org>
References: <Pine.GSO.4.10.10405151618380.26862-200000@helios.et.put.poznan.pl>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Pine.GSO.4.10.10405151618380.26862-200000@helios.et.put.poznan.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: 5323
X-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, May 15, 2004 at 04:19:43PM +0200, Stanislaw Skowronek wrote:

> This is a patch for the (insignificant) bug I found some time ago and
> posted this morning.

The higher powers didn't like your patch.  Last night I've checked in a
patch for this problem which has already been approved from upstream.
Let me know if this works for you.

  Ralf

From lunix@comcast.net Thu Jun 17 16:39:24 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 17 Jun 2004 16:39:28 +0100 (BST)
Received: from rwcrmhc13.comcast.net ([IPv6:::ffff:204.127.198.39]:29164 "EHLO
	rwcrmhc13.comcast.net") by linux-mips.org with ESMTP
	id <S8225548AbUFQPjY>; Thu, 17 Jun 2004 16:39:24 +0100
Received: from [192.168.1.3] (c-24-6-196-202.client.comcast.net[24.6.196.202])
          by comcast.net (rwcrmhc13) with SMTP
          id <2004061715391701500t078ne>; Thu, 17 Jun 2004 15:39:17 +0000
Subject: CVS access
From: Prasanth Kumar <lunix@comcast.net>
To: linux-mips@linux-mips.org
Content-Type: text/plain
Date: Thu, 17 Jun 2004 08:39:16 -0700
Message-Id: <1087486756.3789.4.camel@localhost.localdomain>
Mime-Version: 1.0
X-Mailer: Evolution 1.5.9.1 (1.5.9.1-2) 
Content-Transfer-Encoding: 7bit
Return-Path: <lunix@comcast.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: 5324
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: lunix@comcast.net
Precedence: bulk
X-list: linux-mips

I'm trying to cross compile a Linux MIPS kernel on my x86 system to put
into an embedded board. I'm encountering some problems with compilation
of the stock kernels 2.4.x and 2.6.x from kernel.org. Perhaps the ones
on linux-mips.org are easier to compile. However I cannot get CVS access
following the directions on the linux-mips.org website. It says
authorization failed. Am I doing something incorrectly?

[bubba]$ cvs -d :pserver:cvs@ftp.linux-mips.org:/home/cvs loginLogging
in to :pserver:cvs@ftp.linux-mips.org:2401/home/cvs
CVS password:
cvs login: authorization failed: server ftp.linux-mips.org rejected
access to /home/cvs for user cvs

-- 
Regards,
Prasanth



From sjhill@realitydiluted.com Thu Jun 17 16:43:27 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 17 Jun 2004 16:43:31 +0100 (BST)
Received: from eth13.com-link.com ([IPv6:::ffff:208.242.241.164]:53481 "EHLO
	real.realitydiluted.com") by linux-mips.org with ESMTP
	id <S8225548AbUFQPn1>; Thu, 17 Jun 2004 16:43:27 +0100
Received: from sjhill by real.realitydiluted.com with local (Exim 3.36 #1 (Debian))
	id 1Baz2y-0002at-00; Thu, 17 Jun 2004 10:43:24 -0500
Subject: Re: CVS access
In-Reply-To: <1087486756.3789.4.camel@localhost.localdomain>
To: Prasanth Kumar <lunix@comcast.net>
Date: Thu, 17 Jun 2004 10:43:24 -0500 (CDT)
CC: linux-mips@linux-mips.org
X-Mailer: ELM [version 2.4ME+ PL100 (25)]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII
Message-Id: <E1Baz2y-0002at-00@real.realitydiluted.com>
From: sjhill@realitydiluted.com
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: 5325
X-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

> I'm trying to cross compile a Linux MIPS kernel on my x86 system to put
> into an embedded board. I'm encountering some problems with compilation
> of the stock kernels 2.4.x and 2.6.x from kernel.org. Perhaps the ones
> on linux-mips.org are easier to compile. However I cannot get CVS access
> following the directions on the linux-mips.org website. It says
> authorization failed. Am I doing something incorrectly?
> 
There was a vulnerability found in CVS, so Ralf shut down CVS access
until he could find an appropriate fix.

-Steve

From jbglaw@dvmwest.gt.owl.de Thu Jun 17 17:32:09 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 17 Jun 2004 17:32:13 +0100 (BST)
Received: from dvmwest.gt.owl.de ([IPv6:::ffff:62.52.24.140]:52670 "EHLO
	dvmwest.gt.owl.de") by linux-mips.org with ESMTP
	id <S8225826AbUFQQcJ>; Thu, 17 Jun 2004 17:32:09 +0100
Received: by dvmwest.gt.owl.de (Postfix, from userid 1001)
	id 208374B6E3; Thu, 17 Jun 2004 18:32:07 +0200 (CEST)
Date: Thu, 17 Jun 2004 18:32:07 +0200
From: Jan-Benedict Glaw <jbglaw@lug-owl.de>
To: linux-mips@linux-mips.org
Subject: Re: CVS access
Message-ID: <20040617163206.GQ20632@lug-owl.de>
Mail-Followup-To: linux-mips@linux-mips.org
References: <1087486756.3789.4.camel@localhost.localdomain>
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="VKuXy7C2ZpXslCZ2"
Content-Disposition: inline
In-Reply-To: <1087486756.3789.4.camel@localhost.localdomain>
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.6i
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: 5326
X-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


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

On Thu, 2004-06-17 08:39:16 -0700, Prasanth Kumar <lunix@comcast.net>
wrote in message <1087486756.3789.4.camel@localhost.localdomain>:
>=20
> [bubba]$ cvs -d :pserver:cvs@ftp.linux-mips.org:/home/cvs loginLogging
> in to :pserver:cvs@ftp.linux-mips.org:2401/home/cvs
> CVS password:
> cvs login: authorization failed: server ftp.linux-mips.org rejected
> access to /home/cvs for user cvs

pserver seems running (shouldn't it been sho^Wut down due to
vulnerabilities?).

But to help you: You'd rsync the whole CVS repo to a local machine and
then check-out locally. Oh, kernel.org vanilla kernels won't really
compile nor boot, I guess. All development is done here...

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));

--VKuXy7C2ZpXslCZ2
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)

iD8DBQFA0ceGHb1edYOZ4bsRAqPbAJ9bFQAfdZtVfKVrtNUJTR80ccs/9ACeLt5t
+pgzVb7O1uJaRXU3+v2e0Z4=
=3qEr
-----END PGP SIGNATURE-----

--VKuXy7C2ZpXslCZ2--

From kumba@gentoo.org Thu Jun 17 19:53:35 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 17 Jun 2004 19:53:39 +0100 (BST)
Received: from rwcrmhc11.comcast.net ([IPv6:::ffff:204.127.198.35]:163 "EHLO
	rwcrmhc11.comcast.net") by linux-mips.org with ESMTP
	id <S8225938AbUFQSxf>; Thu, 17 Jun 2004 19:53:35 +0100
Received: from gentoo.org (pcp04939029pcs.waldrf01.md.comcast.net[68.48.72.58])
          by comcast.net (rwcrmhc11) with ESMTP
          id <2004061718532501300gleg5e>
          (Authid: kumba12345);
          Thu, 17 Jun 2004 18:53:25 +0000
Message-ID: <40D1E976.5010204@gentoo.org>
Date: Thu, 17 Jun 2004 14:56:54 -0400
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.6) Gecko/20040113
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: linux-mips@linux-mips.org
Subject: Re: CVS access
References: <1087486756.3789.4.camel@localhost.localdomain> <20040617163206.GQ20632@lug-owl.de>
In-Reply-To: <20040617163206.GQ20632@lug-owl.de>
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: 5327
X-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

Jan-Benedict Glaw wrote:

> pserver seems running (shouldn't it been sho^Wut down due to
> vulnerabilities?).
> 
> But to help you: You'd rsync the whole CVS repo to a local machine and
> then check-out locally. Oh, kernel.org vanilla kernels won't really
> compile nor boot, I guess. All development is done here...

Ralf updated the CVS packages on lmo.org and reactivated the CVS 
anoncvs.  I checked out 2.6.7 yesterday via it, so it's definitely working.


--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 brian@murphy.dk Thu Jun 17 21:08:28 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 17 Jun 2004 21:08:32 +0100 (BST)
Received: from port535.ds1-van.adsl.cybercity.dk ([IPv6:::ffff:217.157.140.228]:37233
	"EHLO valis.murphy.dk") by linux-mips.org with ESMTP
	id <S8225995AbUFQUI2>; Thu, 17 Jun 2004 21:08:28 +0100
Received: from murphy.dk (brm@brian.localnet [10.0.0.2])
	by valis.murphy.dk (8.12.7/8.12.7/Debian-2) with ESMTP id i5HK8Mao031369;
	Thu, 17 Jun 2004 22:08:22 +0200
Message-ID: <40D1FA36.80800@murphy.dk>
Date: Thu, 17 Jun 2004 22:08:22 +0200
From: Brian Murphy <brian@murphy.dk>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040413 Debian/1.6-5
X-Accept-Language: en
MIME-Version: 1.0
To: Ralf Baechle <ralf@linux-mips.org>, linux-mips@linux-mips.org
Subject: Swap and 2.6
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Return-Path: <brian@murphy.dk>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 5328
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: brian@murphy.dk
Precedence: bulk
X-list: linux-mips

Hi,
 I have been using the swap patch posted here by Kumba on 27/5/2004
and it seeems to work, why has it not been merged? Is it incorrect?
Without it swapon segfaults and enabling swap is impossible.

/Brian

From kumba@gentoo.org Thu Jun 17 22:44:33 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 17 Jun 2004 22:44:37 +0100 (BST)
Received: from sccrmhc12.comcast.net ([IPv6:::ffff:204.127.202.56]:43490 "EHLO
	sccrmhc12.comcast.net") by linux-mips.org with ESMTP
	id <S8226055AbUFQVod>; Thu, 17 Jun 2004 22:44:33 +0100
Received: from gentoo.org (pcp04939029pcs.waldrf01.md.comcast.net[68.48.72.58])
          by comcast.net (sccrmhc12) with ESMTP
          id <2004061721442601200ho9ane>
          (Authid: kumba12345);
          Thu, 17 Jun 2004 21:44:26 +0000
Message-ID: <40D2118C.5020506@gentoo.org>
Date: Thu, 17 Jun 2004 17:47:56 -0400
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.6) Gecko/20040113
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: linux-mips@linux-mips.org
Subject: Re: Swap and 2.6
References: <40D1FA36.80800@murphy.dk>
In-Reply-To: <40D1FA36.80800@murphy.dk>
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: 5329
X-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

Brian Murphy wrote:

> Hi,
> I have been using the swap patch posted here by Kumba on 27/5/2004
> and it seeems to work, why has it not been merged? Is it incorrect?
> Without it swapon segfaults and enabling swap is impossible.
> 
> /Brian

It does seem to work for me on my R5K machines.

My only oddity so far is I'm unsure if it runs on R4x00 machines or 
Indigo2's.  My I2 lacks a framebuffer, and ip22zilog is shot dead in 
2.6.x, so It's near impossible to tell whether I get a successful boot 
or not on the machine.  I'm confident Peter's patch works for the most 
part, but if anyone w/ an I2 R4x00 machine and Newport can test 
2.6.5/.6/.7 + patch and let me know if it boots or not, I'd be 
interested.  Right now, I'm not able to boot anything past 2.6.4 on said 
machine, and have no idea how to capture all the boot info from the 
kernel startup through userland (netconsole didn't seem to work when I 
last tried it).


--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 jospehchan@yahoo.com.tw Fri Jun 18 03:42:04 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 18 Jun 2004 03:42:12 +0100 (BST)
Received: from web16605.mail.tpe.yahoo.com ([IPv6:::ffff:202.1.236.95]:45162
	"HELO web16605.mail.tpe.yahoo.com") by linux-mips.org with SMTP
	id <S8224827AbUFRCmE>; Fri, 18 Jun 2004 03:42:04 +0100
Message-ID: <20040618024155.35970.qmail@web16605.mail.tpe.yahoo.com>
Received: from [61.66.243.2] by web16605.mail.tpe.yahoo.com via HTTP; Fri, 18 Jun 2004 10:41:55 CST
Date: Fri, 18 Jun 2004 10:41:55 +0800 (CST)
From: =?big5?q?jospehchan?= <jospehchan@yahoo.com.tw>
Subject: Re: "No such device" with PCI card
To: linux-mips@linux-mips.org
Cc: jbglaw@lug-owl.de
In-Reply-To: <40CEBB36.1030707@kilimandjaro.dyndns.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=big5
Content-Transfer-Encoding: 8bit
Return-Path: <jospehchan@yahoo.com.tw>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 5330
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: jospehchan@yahoo.com.tw
Precedence: bulk
X-list: linux-mips

Hi Jan-Benedict,
 Thanks. Please refer to the follownig replies. 

- What kind of MIPS system do you use *exactly*? What
board? Which
  kernel version? From where did you get your sources.

>>>The MIPS system is R3000 and uses an ADI Media
Adapter MB.
The kernel is 2.4.16 from the vendor and plus an USB
patch which backported from kernel 2.4.26.


- A USB2.0 card is IMHO driven by the ehci driver, but
I may be wrong.
  I'm not exactly a regular USB user...

>>>Yes, you're right. But the USB2.0 card also can be
driven by usb-uhci if ehci-hcd is not loaded.
In the my problem, I can load the usbcore, but both of
usb-uhci and ehci-hcd can not be loaded. 

- Do you have output of "lspci", "lspci -v", "lspci
-n", "lspci -vn" and
  "lspci -nxxx" at your hand, once from your i386 test
machine, once
  from the MIPS board? Right, those commands mostly
give the same
  output, but each style eases reading for specific
values:)

>>> MIPS
# lspci
00:00.0 Class 0c03: 1106:3038 (rev 61)
# lspci -v
00:00.0 Class 0c03: 1106:3038 (rev 61)
        Subsystem: 1106:3038
        Flags: bus master, medium devsel, latency 22,
IRQ 4
        I/O ports at <ignored>
        Capabilities: [80] Power Management version 2

# lspci -n
00:00.0 Class 0c03: 1106:3038 (rev 61)
# lspci -vn
00:00.0 Class 0c03: 1106:3038 (rev 61)
        Subsystem: 1106:3038
        Flags: bus master, medium devsel, latency 22,
IRQ 4
        I/O ports at <ignored>
        Capabilities: [80] Power Management version 2

# lspci -nxxx
00:00.0 Class 0c03: 1106:3038 (rev 61)
00: 06 11 38 30 47 01 10 02 61 00 03 0c 00 16 80 00
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: e1 fc 00 00 00 00 00 00 00 00 00 00 06 11 38 30
30: 00 00 00 00 80 00 00 00 00 00 00 00 04 01 00 00
40: 40 10 03 00 00 00 00 00 00 08 00 00 00 00 00 00
50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
60: 10 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
80: 01 00 0a 7e 00 00 00 00 00 00 00 00 00 00 00 00
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
c0: 00 20 00 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
f0: 00 00 00 00 00 00 00 03 00 00 00 00 00 00 00 00


>>> i386 (RH7.2, kernel 2.4.16 plus USB patch from
kernel 2.4.26)
#lspci 
00:14.0 USB Controller: VIA Technologies, Inc. UHCI
USB (rev 61)
00:14.1 USB Controller: VIA Technologies, Inc. UHCI
USB (rev 61)
00:14.2 USB Controller: VIA Technologies, Inc.:
Unknown device 3104 (rev 62)

#lspci -v
00:14.0 USB Controller: VIA Technologies, Inc. UHCI
USB (rev 61) (prog-if 00 [UHCI])
	Subsystem: VIA Technologies, Inc. UHCI USB
	Flags: bus master, medium devsel, latency 32, IRQ 11
	I/O ports at e400 [size=32]
	Capabilities: [80] Power Management version 2

00:14.1 USB Controller: VIA Technologies, Inc. UHCI
USB (rev 61) (prog-if 00 [UHCI])
	Subsystem: VIA Technologies, Inc. UHCI USB
	Flags: bus master, medium devsel, latency 32, IRQ 5
	I/O ports at e800 [size=32]
	Capabilities: [80] Power Management version 2

00:14.2 USB Controller: VIA Technologies, Inc.:
Unknown device 3104 (rev 62) (prog-if 20)
	Subsystem: VIA Technologies, Inc.: Unknown device
3104
	Flags: bus master, medium devsel, latency 32, IRQ 5
	Memory at ee003000 (32-bit, non-prefetchable)
[size=256]
	Capabilities: [80] Power Management version 2

#lspci -n 
00:14.0 Class 0c03: 1106:3038 (rev 61)
00:14.1 Class 0c03: 1106:3038 (rev 61)
00:14.2 Class 0c03: 1106:3104 (rev 62)

#lspci -vn
00:14.0 Class 0c03: 1106:3038 (rev 61)
	Subsystem: 1106:3038
	Flags: bus master, medium devsel, latency 32, IRQ 11
	I/O ports at e400 [size=32]
	Capabilities: [80] Power Management version 2

00:14.1 Class 0c03: 1106:3038 (rev 61)
	Subsystem: 1106:3038
	Flags: bus master, medium devsel, latency 32, IRQ 5
	I/O ports at e800 [size=32]
	Capabilities: [80] Power Management version 2

00:14.2 Class 0c03: 1106:3104 (rev 62) (prog-if 20)
	Subsystem: 1106:3104
	Flags: bus master, medium devsel, latency 32, IRQ 5
	Memory at ee003000 (32-bit, non-prefetchable)
[size=256]
	Capabilities: [80] Power Management version 2

#lspci -nxxx
00:14.0 Class 0c03: 1106:3038 (rev 61)
00: 06 11 38 30 07 00 10 02 61 00 03 0c 08 20 80 00
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 01 e4 00 00 00 00 00 00 00 00 00 00 06 11 38 30
30: 00 00 00 00 80 00 00 00 00 00 00 00 0b 01 00 00
40: 40 10 03 00 00 00 00 00 00 0b 00 00 00 00 00 00
50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
60: 10 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
80: 01 00 c2 ff 00 00 00 00 00 00 00 00 00 00 00 00
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
c0: 00 20 00 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
f0: 00 00 00 00 00 00 00 03 00 00 00 00 00 00 00 00

00:14.1 Class 0c03: 1106:3038 (rev 61)
00: 06 11 38 30 07 00 10 02 61 00 03 0c 08 20 80 00
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 01 e8 00 00 00 00 00 00 00 00 00 00 06 11 38 30
30: 00 00 00 00 80 00 00 00 00 00 00 00 05 02 00 00
40: 40 10 03 00 00 00 00 00 00 0b 00 00 00 00 00 00
50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
60: 10 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
80: 01 00 c2 ff 00 00 00 00 00 00 00 00 00 00 00 00
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
c0: 00 20 00 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
f0: 00 00 00 00 00 00 00 03 00 00 00 00 00 00 00 00

00:14.2 Class 0c03: 1106:3104 (rev 62)
00: 06 11 04 31 07 00 10 02 62 20 03 0c 08 20 80 00
10: 00 30 00 ee 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 06 11 04 31
30: 00 00 00 00 80 00 00 00 00 00 00 00 05 03 00 00
40: 00 00 03 00 00 00 00 00 a0 20 00 09 00 00 ff ff
50: 00 5a 00 80 00 00 00 00 04 0b 88 88 53 00 00 00
60: 20 20 01 00 00 00 00 00 01 00 00 00 00 00 00 c0
70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
80: 01 00 c2 ff 00 00 00 00 00 00 00 00 00 00 00 00
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
f0: 00 00 00 00 00 00 00 03 00 00 00 00 00 00 00 00


- Does your MOPS board have working on-board PCI
devices? These don't
  neccessarily have a PCI plug as you know them from
add-on cards,
  because they're directly built into the chipset. For
instance, does
  your board have onboard IDE interfaces?
  
  >>>No, the PCI device can not work, such as (Realtek
8139 LAN card, Philips and VIA USB 2.0 card)
  But there is a mini-PCI device seems workable,
because it's driver can be loaded.
  


-----------------------------------------------------------------
Yahoo!©_¼¯Messenger6.0
«H½c·f°t§Y®É³q, ·¾³q¼Ö½ìµL½a! 
http://tw.messenger.yahoo.com/

From jbglaw@dvmwest.gt.owl.de Fri Jun 18 07:19:31 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 18 Jun 2004 07:19:36 +0100 (BST)
Received: from dvmwest.gt.owl.de ([IPv6:::ffff:62.52.24.140]:16331 "EHLO
	dvmwest.gt.owl.de") by linux-mips.org with ESMTP
	id <S8224986AbUFRGTb>; Fri, 18 Jun 2004 07:19:31 +0100
Received: by dvmwest.gt.owl.de (Postfix, from userid 1001)
	id 683F84B7C1; Fri, 18 Jun 2004 08:19:28 +0200 (CEST)
Date: Fri, 18 Jun 2004 08:19:28 +0200
From: Jan-Benedict Glaw <jbglaw@lug-owl.de>
To: linux-mips@linux-mips.org
Subject: Re: "No such device" with PCI card
Message-ID: <20040618061927.GU20632@lug-owl.de>
Mail-Followup-To: linux-mips@linux-mips.org
References: <40CEBB36.1030707@kilimandjaro.dyndns.org> <20040618024155.35970.qmail@web16605.mail.tpe.yahoo.com>
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="a6tHM5hUJNv0E1sG"
Content-Disposition: inline
In-Reply-To: <20040618024155.35970.qmail@web16605.mail.tpe.yahoo.com>
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.6i
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: 5331
X-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


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

On Fri, 2004-06-18 10:41:55 +0800, jospehchan <jospehchan@yahoo.com.tw>
wrote in message <20040618024155.35970.qmail@web16605.mail.tpe.yahoo.com>:
> Hi Jan-Benedict,
>  Thanks. Please refer to the follownig replies.=20

(By the way, think about changing you email client's configuration...)

> - What kind of MIPS system do you use *exactly*? What
> board? Which
>   kernel version? From where did you get your sources.
>=20
> >>>The MIPS system is R3000 and uses an ADI Media
> Adapter MB.
> The kernel is 2.4.16 from the vendor and plus an USB
> patch which backported from kernel 2.4.26.

First off, I didn't easily find information for that board...

Then, porting direction was wrong. You want to diff out vendor's changes
ontop vanilla 2.4.16 (probably they've started off the mvista or the
linux-mips.org kernel) and port *those* to current 2.4.x (of same
vendor, preferring linux-mips.org ...). If they only added drivers and
bootup-code for that board, just port that over to 2.6.x.

Sounds like the vendor did make linux waddle on that board and never
cared for it again :(

> - A USB2.0 card is IMHO driven by the ehci driver, but
> I may be wrong.
>   I'm not exactly a regular USB user...
>=20
> >>>Yes, you're right. But the USB2.0 card also can be
> driven by usb-uhci if ehci-hcd is not loaded.
> In the my problem, I can load the usbcore, but both of
> usb-uhci and ehci-hcd can not be loaded.=20

I'd guess usb-core has nothing else to do than to accept loaded host and
client drivers, so it should just load and do nothing. I guess they just
broke the whole PCI interface in some way or another (weren't there
general MIPS bugs at that time in 2.4.x? Even with endianess? It's so
long ago...)

> - Do you have output of "lspci", "lspci -v", "lspci
> -n", "lspci -vn" and
>   "lspci -nxxx" at your hand, once from your i386 test
> machine, once
>   from the MIPS board? Right, those commands mostly
> give the same
>   output, but each style eases reading for specific
> values:)
>=20
> >>> MIPS
> # lspci
> 00:00.0 Class 0c03: 1106:3038 (rev 61)

Only *one* PCI device? I'm shocked...

	1106:	VIA
	3038:	USB

> # lspci -v
> 00:00.0 Class 0c03: 1106:3038 (rev 61)
>         Subsystem: 1106:3038
>         Flags: bus master, medium devsel, latency 22, IRQ 4
>         I/O ports at <ignored>
>         Capabilities: [80] Power Management version 2

Seems the device didn't get any I/O assigned. Of course, that won't
fly. Depending on what's expected, either Linux' PCI core should assign
I/O for devices, or the board's firmware.

> # lspci -n

> >>> i386 (RH7.2, kernel 2.4.16 plus USB patch from kernel 2.4.26)

Dito, quite outdated:)

> #lspci=20
> 00:14.0 USB Controller: VIA Technologies, Inc. UHCI USB (rev 61)
> 00:14.1 USB Controller: VIA Technologies, Inc. UHCI USB (rev 61)
> 00:14.2 USB Controller: VIA Technologies, Inc.: Unknown device 3104 (rev =
62)

So on the MIPS board, there's only *one* single device, but on your
i386 machine, this board registers as three separate subdevices? Sounds
there's something seriously broken in the MIPS PCI code as of 2.4.16...

But *that* doesn't make me wonder:)


> #lspci -v
> 00:14.0 USB Controller: VIA Technologies, Inc. UHCI
> USB (rev 61) (prog-if 00 [UHCI])
> 	Subsystem: VIA Technologies, Inc. UHCI USB
> 	Flags: bus master, medium devsel, latency 32, IRQ 11
> 	I/O ports at e400 [size=3D32]
> 	Capabilities: [80] Power Management version 2
>=20
> 00:14.1 USB Controller: VIA Technologies, Inc. UHCI
> USB (rev 61) (prog-if 00 [UHCI])
> 	Subsystem: VIA Technologies, Inc. UHCI USB
> 	Flags: bus master, medium devsel, latency 32, IRQ 5
> 	I/O ports at e800 [size=3D32]
> 	Capabilities: [80] Power Management version 2
>=20
> 00:14.2 USB Controller: VIA Technologies, Inc.:
> Unknown device 3104 (rev 62) (prog-if 20)
> 	Subsystem: VIA Technologies, Inc.: Unknown device 3104
> 	Flags: bus master, medium devsel, latency 32, IRQ 5
> 	Memory at ee003000 (32-bit, non-prefetchable) [size=3D256]
> 	Capabilities: [80] Power Management version 2

Also, if you're asked for output, please don't cut it down to what you
think is useful or related. For sure, your i386 PC as well as your MIPS
box *does* indeed have more PCI devices than only the USB card.

> #lspci -vn
> 00:14.0 Class 0c03: 1106:3038 (rev 61)
> 	Subsystem: 1106:3038
> 	Flags: bus master, medium devsel, latency 32, IRQ 11
> 	I/O ports at e400 [size=3D32]
> 	Capabilities: [80] Power Management version 2

See? On your PeeCee, it got I/O resources assigned.

>=20
> - Does your MOPS board have working on-board PCI
> devices? These don't
>   neccessarily have a PCI plug as you know them from
> add-on cards,
>   because they're directly built into the chipset. For
> instance, does
>   your board have onboard IDE interfaces?
>  =20
>   >>>No, the PCI device can not work, such as (Realtek
> 8139 LAN card, Philips and VIA USB 2.0 card)
>   But there is a mini-PCI device seems workable,
> because it's driver can be loaded.

Does it have any PCI attached devices (modulo the USB card)?

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));

--a6tHM5hUJNv0E1sG
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)

iD8DBQFA0olvHb1edYOZ4bsRAv7GAJ9Swqo77Xs1+l2dINR4og1R1uBSnwCcDtB5
gKi3+JlzaUxllUUDlc812JI=
=yGN1
-----END PGP SIGNATURE-----

--a6tHM5hUJNv0E1sG--

From frederic@archimix.com Fri Jun 18 07:31:28 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 18 Jun 2004 07:31:33 +0100 (BST)
Received: from smtp9.wanadoo.fr ([IPv6:::ffff:193.252.22.22]:5223 "EHLO
	mwinf0901.wanadoo.fr") by linux-mips.org with ESMTP
	id <S8224989AbUFRGb2>; Fri, 18 Jun 2004 07:31:28 +0100
Received: from kaladim.ath.cx (AMontpellier-203-1-4-200.w80-14.abo.wanadoo.fr [80.14.105.200])
	by mwinf0901.wanadoo.fr (SMTP Server) with ESMTP id B87EB1800254
	for <linux-mips@linux-mips.org>; Fri, 18 Jun 2004 08:31:21 +0200 (CEST)
From: =?iso-8859-1?q?H=E9brard_Fr=E9d=E9ric?= <frederic@archimix.com>
Reply-To: frederic@archimix.com
To: linux-mips@linux-mips.org
Subject: linux on a R5000 Indy
Date: Fri, 18 Jun 2004 08:31:42 +0200
User-Agent: KMail/1.6.1
MIME-Version: 1.0
Content-Disposition: inline
Content-Type: Text/Plain;
  charset="us-ascii"
Content-Transfer-Encoding: 7bit
Message-Id: <200406180831.43916.frederic@archimix.com>
Return-Path: <frederic@archimix.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: 5332
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: frederic@archimix.com
Precedence: bulk
X-list: linux-mips

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

hello all,
I would like to install linux on my indy R5000.
witch kind of package do you think I need ?
thx in advance
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFA0oxOp74YsN85LJ0RAnuiAKDKrOo+j+EKTAX83IOT1PAJ01uFagCeM51x
vuDKOpE7XIY66wux32nNwYw=
=taq2
-----END PGP SIGNATURE-----

From jsun@mvista.com Fri Jun 18 18:05:32 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 18 Jun 2004 18:05:37 +0100 (BST)
Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:60407 "EHLO
	orion.mvista.com") by linux-mips.org with ESMTP id <S8225206AbUFRRFc>;
	Fri, 18 Jun 2004 18:05:32 +0100
Received: from orion.mvista.com (localhost.localdomain [127.0.0.1])
	by orion.mvista.com (8.12.8/8.12.8) with ESMTP id i5IH5U4O003395;
	Fri, 18 Jun 2004 10:05:30 -0700
Received: (from jsun@localhost)
	by orion.mvista.com (8.12.8/8.12.8/Submit) id i5IH5Ujw003394;
	Fri, 18 Jun 2004 10:05:30 -0700
Date: Fri, 18 Jun 2004 10:05:30 -0700
From: Jun Sun <jsun@mvista.com>
To: linux-mips@linux-mips.org
Cc: jsun@mvista.com
Subject: Re: "No such device" with PCI card
Message-ID: <20040618100530.B3142@mvista.com>
References: <40CEBB36.1030707@kilimandjaro.dyndns.org> <20040618024155.35970.qmail@web16605.mail.tpe.yahoo.com> <20040618061927.GU20632@lug-owl.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <20040618061927.GU20632@lug-owl.de>; from jbglaw@lug-owl.de on Fri, Jun 18, 2004 at 08:19:28AM +0200
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: 5333
X-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 Fri, Jun 18, 2004 at 08:19:28AM +0200, Jan-Benedict Glaw wrote:
> On Fri, 2004-06-18 10:41:55 +0800, jospehchan <jospehchan@yahoo.com.tw>
> wrote in message <20040618024155.35970.qmail@web16605.mail.tpe.yahoo.com>:
> > Hi Jan-Benedict,
> >  Thanks. Please refer to the follownig replies. 
> 
> (By the way, think about changing you email client's configuration...)
> 
> > - What kind of MIPS system do you use *exactly*? What
> > board? Which
> >   kernel version? From where did you get your sources.
> > 
> > >>>The MIPS system is R3000 and uses an ADI Media
> > Adapter MB.
> > The kernel is 2.4.16 from the vendor and plus an USB
> > patch which backported from kernel 2.4.26.
> 
> First off, I didn't easily find information for that board...
> 
> Then, porting direction was wrong. You want to diff out vendor's changes
> ontop vanilla 2.4.16 (probably they've started off the mvista or the
> linux-mips.org kernel) and port *those* to current 2.4.x (of same
> vendor, preferring linux-mips.org ...). 

Not from mvista for sure.  We never released a kernel based on 2.4.16.
Also never heard of the board.

Jun

From ralf@linux-mips.org Sat Jun 19 21:09:25 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 19 Jun 2004 21:09:29 +0100 (BST)
Received: from p508B79F9.dip.t-dialin.net ([IPv6:::ffff:80.139.121.249]:14944
	"EHLO mail.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225363AbUFSUJZ>; Sat, 19 Jun 2004 21:09:25 +0100
Received: from fluff.linux-mips.net (fluff.linux-mips.net [127.0.0.1])
	by mail.linux-mips.net (8.12.11/8.12.8) with ESMTP id i5JK9OZN022442
	for <linux-mips@linux-mips.org>; Sat, 19 Jun 2004 22:09:24 +0200
Received: (from ralf@localhost)
	by fluff.linux-mips.net (8.12.11/8.12.11/Submit) id i5JK9NfH022441
	for linux-mips@linux-mips.org; Sat, 19 Jun 2004 22:09:23 +0200
Date: Sat, 19 Jun 2004 22:09:23 +0200
From: Ralf Baechle <ralf@linux-mips.org>
To: linux-mips@linux-mips.org
Subject: Dummy keyboard driver
Message-ID: <20040619200923.GA22409@linux-mips.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
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: 5334
X-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

Is there still a need for the dummy keyboard driver?  Right now DUMMY_KEYB
is being set for a bunch of platforms without having any effect so I take
to mean we can remove dummy_keyb.c.

  Ralf

From jbglaw@dvmwest.gt.owl.de Sat Jun 19 23:38:32 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 19 Jun 2004 23:38:37 +0100 (BST)
Received: from dvmwest.gt.owl.de ([IPv6:::ffff:62.52.24.140]:12677 "EHLO
	dvmwest.gt.owl.de") by linux-mips.org with ESMTP
	id <S8225363AbUFSWic>; Sat, 19 Jun 2004 23:38:32 +0100
Received: by dvmwest.gt.owl.de (Postfix, from userid 1001)
	id 167C54B7D4; Sun, 20 Jun 2004 00:38:30 +0200 (CEST)
Date: Sun, 20 Jun 2004 00:38:30 +0200
From: Jan-Benedict Glaw <jbglaw@lug-owl.de>
To: linux-mips@linux-mips.org
Subject: Re: Dummy keyboard driver
Message-ID: <20040619223829.GD20632@lug-owl.de>
Mail-Followup-To: linux-mips@linux-mips.org
References: <20040619200923.GA22409@linux-mips.org>
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="AH02zKoZ2h96gqbS"
Content-Disposition: inline
In-Reply-To: <20040619200923.GA22409@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.6i
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: 5335
X-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


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

On Sat, 2004-06-19 22:09:23 +0200, Ralf Baechle <ralf@linux-mips.org>
wrote in message <20040619200923.GA22409@linux-mips.org>:
> Is there still a need for the dummy keyboard driver?  Right now DUMMY_KEYB
> is being set for a bunch of platforms without having any effect so I take
> to mean we can remove dummy_keyb.c.

I (vax 2.6.x tree) don't even have that file, and there shouldn't be no
need for any kind of dummy keyboard. Either there's at least one
keyboard attached (multiple are fine, though), you get input. No
keyboard (driver), no input. Simple.

Just drop it.

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));

--AH02zKoZ2h96gqbS
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)

iD8DBQFA1MBlHb1edYOZ4bsRAgabAJ9rQiz4+C2BHwCPsNimi38sMG00gQCbBNgo
TCUOvzla71YB9ffpNqtJzyQ=
=gTWq
-----END PGP SIGNATURE-----

--AH02zKoZ2h96gqbS--

From ralf@linux-mips.org Sun Jun 20 01:03:50 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 20 Jun 2004 01:03:54 +0100 (BST)
Received: from p508B79F9.dip.t-dialin.net ([IPv6:::ffff:80.139.121.249]:55394
	"EHLO mail.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225363AbUFTADu>; Sun, 20 Jun 2004 01:03:50 +0100
Received: from fluff.linux-mips.net (fluff.linux-mips.net [127.0.0.1])
	by mail.linux-mips.net (8.12.11/8.12.8) with ESMTP id i5K03nIZ028093
	for <linux-mips@linux-mips.org>; Sun, 20 Jun 2004 02:03:49 +0200
Received: (from ralf@localhost)
	by fluff.linux-mips.net (8.12.11/8.12.11/Submit) id i5K03m84028092
	for linux-mips@linux-mips.org; Sun, 20 Jun 2004 02:03:48 +0200
Date: Sun, 20 Jun 2004 02:03:48 +0200
From: Ralf Baechle <ralf@linux-mips.org>
To: linux-mips@linux-mips.org
Subject: Re: Dummy keyboard driver
Message-ID: <20040620000348.GB23498@linux-mips.org>
References: <20040619200923.GA22409@linux-mips.org> <20040619223829.GD20632@lug-owl.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20040619223829.GD20632@lug-owl.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: 5336
X-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, Jun 20, 2004 at 12:38:30AM +0200, Jan-Benedict Glaw wrote:

> On Sat, 2004-06-19 22:09:23 +0200, Ralf Baechle <ralf@linux-mips.org>
> wrote in message <20040619200923.GA22409@linux-mips.org>:
> > Is there still a need for the dummy keyboard driver?  Right now DUMMY_KEYB
> > is being set for a bunch of platforms without having any effect so I take
> > to mean we can remove dummy_keyb.c.
> 
> I (vax 2.6.x tree) don't even have that file, and there shouldn't be no
> need for any kind of dummy keyboard. Either there's at least one
> keyboard attached (multiple are fine, though), you get input. No
> keyboard (driver), no input. Simple.
> 
> Just drop it.

I don't think the original reason for it still exists and even if it
was it'd need to be rewritten and moved so I'm removing it now.

  Ralf

From jbglaw@dvmwest.gt.owl.de Sun Jun 20 11:11:55 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 20 Jun 2004 11:12:00 +0100 (BST)
Received: from dvmwest.gt.owl.de ([IPv6:::ffff:62.52.24.140]:13966 "EHLO
	dvmwest.gt.owl.de") by linux-mips.org with ESMTP
	id <S8224945AbUFTKLz>; Sun, 20 Jun 2004 11:11:55 +0100
Received: by dvmwest.gt.owl.de (Postfix, from userid 1001)
	id 4EF514B7CD; Sun, 20 Jun 2004 12:11:53 +0200 (CEST)
Date: Sun, 20 Jun 2004 12:11:53 +0200
From: Jan-Benedict Glaw <jbglaw@lug-owl.de>
To: linux-mips@linux-mips.org
Subject: Re: Dummy keyboard driver
Message-ID: <20040620101153.GH20632@lug-owl.de>
Mail-Followup-To: linux-mips@linux-mips.org
References: <20040619200923.GA22409@linux-mips.org> <20040619223829.GD20632@lug-owl.de> <20040620000348.GB23498@linux-mips.org>
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="RtZTDqy7cLeWP9t+"
Content-Disposition: inline
In-Reply-To: <20040620000348.GB23498@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.6i
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: 5337
X-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


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

On Sun, 2004-06-20 02:03:48 +0200, Ralf Baechle <ralf@linux-mips.org>
wrote in message <20040620000348.GB23498@linux-mips.org>:
> On Sun, Jun 20, 2004 at 12:38:30AM +0200, Jan-Benedict Glaw wrote:
> > On Sat, 2004-06-19 22:09:23 +0200, Ralf Baechle <ralf@linux-mips.org>
> > wrote in message <20040619200923.GA22409@linux-mips.org>:
> > I (vax 2.6.x tree) don't even have that file, and there shouldn't be no
> > need for any kind of dummy keyboard. Either there's at least one
> > keyboard attached (multiple are fine, though), you get input. No
> > keyboard (driver), no input. Simple.
> >=20
> > Just drop it.
>=20
> I don't think the original reason for it still exists and even if it
> was it'd need to be rewritten and moved so I'm removing it now.

Right. Looong ago, you had to have keyboard driver if you had CONFIG_VT
switched on (because tty/vt core then referenced some functions for key
mapping and LED status setting), but those times are gone.

Today's dummy keyboard actually *is* the whole Input API. I think the
"direct" way of pumping data into tty/vt core went away around 2.6.1 (or
around that), when the parisc team ported their HIL and ps2-keyboard
drivers to Input API drivers or serio adaptors.

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));

--RtZTDqy7cLeWP9t+
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)

iD8DBQFA1WLoHb1edYOZ4bsRAkkKAKCD+QseG8vGz/6YN2Wj6fhJgdsI1gCdGC8E
QauB8edarDyS/cckG3gX6RI=
=5q8n
-----END PGP SIGNATURE-----

--RtZTDqy7cLeWP9t+--

From kumba@gentoo.org Mon Jun 21 07:06:27 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 21 Jun 2004 07:06:32 +0100 (BST)
Received: from sccrmhc13.comcast.net ([IPv6:::ffff:204.127.202.64]:8326 "EHLO
	sccrmhc13.comcast.net") by linux-mips.org with ESMTP
	id <S8224841AbUFUGG1>; Mon, 21 Jun 2004 07:06:27 +0100
Received: from [192.168.1.4] (pcp04939029pcs.waldrf01.md.comcast.net[68.48.72.58])
          by comcast.net (sccrmhc13) with ESMTP
          id <20040621060621016008v3pme>
          (Authid: kumba12345);
          Mon, 21 Jun 2004 06:06:21 +0000
Message-ID: <40D67BBC.4020901@gentoo.org>
Date: Mon, 21 Jun 2004 02:10:04 -0400
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.7) Gecko/20040616
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: linux-mips@linux-mips.org
Subject: [PATCH] Fix O2/IP32 compile time glitch
X-Enigmail-Version: 0.84.1.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: multipart/mixed;
 boundary="------------030104080105030204060803"
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: 5338
X-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

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

Seems somewhere between 2.6.6 and 2.6.7, something happened that makes 
IP32's build die in drivers/char/rtc.c when trying to reference 
MACEISA_RTC_IRQ.  The attached patch fixes it.


--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

--------------030104080105030204060803
Content-Type: text/plain;
 name="mipscvs-2.6.7-maceisa_rtc_irq-fix.patch"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="mipscvs-2.6.7-maceisa_rtc_irq-fix.patch"

--- include/asm-mips/mach-ip32/mc146818rtc.h.orig	2004-06-21 00:47:35.931657976 -0400
+++ include/asm-mips/mach-ip32/mc146818rtc.h	2004-06-21 00:47:50.704412176 -0400
@@ -13,6 +13,7 @@
 
 #include <asm/io.h>
 #include <asm/ip32/mace.h>
+#include <asm/ip32/ip32_ints.h>
 
 #define RTC_PORT(x)	(0x70 + (x))
 #define RTC_IRQ		MACEISA_RTC_IRQ

--------------030104080105030204060803--

From YQuirion@tranzyme.com Mon Jun 21 14:10:19 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 21 Jun 2004 14:10:24 +0100 (BST)
Received: from neptune-e.tranzyme.com ([IPv6:::ffff:132.210.158.201]:161 "EHLO
	neptune.tranzyme.com") by linux-mips.org with ESMTP
	id <S8225413AbUFUNKT> convert rfc822-to-8bit; Mon, 21 Jun 2004 14:10:19 +0100
Received: from mercure.tranzyme.com (dcsher01.tranzyme.com [192.168.1.3])
	by neptune.tranzyme.com (8.12.10/8.12.10) with ESMTP id i5LDA9CO022607
	for <linux-mips@linux-mips.org>; Mon, 21 Jun 2004 09:10:10 -0400
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 8BIT
Subject: Linux on O2
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Date: Mon, 21 Jun 2004 09:10:15 -0400
Message-ID: <C94F931D92788D4EBD498B740AA5F7E106B0AB@dcsher01.tranzyme.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Linux on O2
thread-index: AcRXkRJ83bCvy5xjQSGLjT1HxuVtew==
From: "Yanick Quirion" <YQuirion@tranzyme.com>
To: <linux-mips@linux-mips.org>
X-NK-Spam-Status: Ce message n'est pas du SPAM, (Score: 0, Requis: 5)
X-NK-Spam-Version: SpamAssassin version 2.63
X-Scanned-By: MIMEDefang 2.43
Return-Path: <YQuirion@tranzyme.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: 5339
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: YQuirion@tranzyme.com
Precedence: bulk
X-list: linux-mips

Dear all,

I want to install linux on an SGI O2. Could you tell me if it's possible to install linux on this system:

CPU: MIPS R12000 Processor Chip Revision: 2.3
FPU: MIPS R12010 Floating Point Chip Revision: 0.0
1 300 MHZ IP32 Processor
Main memory size: 384 Mbytes
Secondary unified instruction/data cache size: 1 Mbyte on Processor 0
Instruction cache size: 32 Kbytes
Data cache size: 32 Kbytes
FLASH PROM version 4.17
Integral SCSI controller 0: Version ADAPTEC 7880
  Disk drive: unit 2 on SCSI controller 0
  CDROM: unit 4 on SCSI controller 0
Integral SCSI controller 1: Version ADAPTEC 7880
On-board serial ports: tty1
On-board serial ports: tty2
On-board EPP/ECP parallel port
CRM graphics installed
Integral Ethernet: ec0, version 1
Iris Audio Processor: version A3 revision 0
Video: MVP unit 0 version 1.4
 with no AV Card or Camera.
Vice: TRE


If it's possible, where I can get cdrom ISO's?

Thank you

Regards,
_______________
Yanick Quirion
Network & System Administrator
Tranzyme Pharma Inc.
 
(819) 820-6840 (phone)
(819) 820-6855 (direct)
(819) 820-6841 (fax)
(819) 570-6855 (mobile)
 
YQuirion@tranzyme.com
www.tranzymepharma.com
www.tranzyme.com
 


From pf@net.alphadv.de Mon Jun 21 15:26:43 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 21 Jun 2004 15:26:52 +0100 (BST)
Received: from mail.alphastar.de ([IPv6:::ffff:194.59.236.179]:53001 "EHLO
	mail.alphastar.de") by linux-mips.org with ESMTP
	id <S8225274AbUFUO0n>; Mon, 21 Jun 2004 15:26:43 +0100
Received: from Snailmail (62.158.202.138)
          by mail.alphastar.de with MERCUR Mailserver (v4.02.28 MTIxLTIxODAtNjY2OA==)
          for <linux-mips@linux-mips.org>; Mon, 21 Jun 2004 16:25:16 +0200
Received: from Opal.Peter (pf@Opal.Peter [192.168.1.1])
	by SNaIlmail.Peter (8.12.6/8.12.6/Sendmail/Linux 2.0.32) with ESMTP id i5LEKw0S000958;
	Mon, 21 Jun 2004 16:20:59 +0200
Received: from localhost (pf@localhost)
	by Opal.Peter (8.9.3/8.9.3/Sendmail/Linux 2.2.5-15) with ESMTP id QAA17154;
	Mon, 21 Jun 2004 16:20:48 +0200
Date: Mon, 21 Jun 2004 16:20:48 +0200 (CEST)
From: Peter Fuerst <pf@net.alphadv.de>
To: Kumba <kumba@gentoo.org>
cc: linux-mips@linux-mips.org
Subject: ip22zilog resurrection
In-Reply-To: <40D2118C.5020506@gentoo.org>
Message-ID: <Pine.LNX.4.21.0406211607490.17140-200000@Opal.Peter>
MIME-Version: 1.0
Content-Type: MULTIPART/MIXED; BOUNDARY="-1463811839-1947110491-1087827648=:17140"
Reply-To: pf@net.alphadv.de
Return-Path: <pf@net.alphadv.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: 5340
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: pf@net.alphadv.de
Precedence: bulk
X-list: linux-mips

  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.

---1463811839-1947110491-1087827648=:17140
Content-Type: TEXT/PLAIN; charset=US-ASCII


Hello !

Switch back the channels according to PROM/documentation/case numbering,
do some other small changes (patch attached), and you should have serial
console available again.

However, i couldn't test this fully. On my IP28, when entering userland
in 2.6 (no matter whether /sbin/init or /bin/sh), the output in the
console-window becomes slower and slower, asymptotically reaching a
standstill, before the login prompt appears (while the machine still can
be ping'ed over ethernet without degradation)  :-(

Good luck

peter



On Thu, 17 Jun 2004, Kumba wrote:

> Date: Thu, 17 Jun 2004 17:47:56 -0400
> From: Kumba <kumba@gentoo.org>
> To: linux-mips@linux-mips.org
> Subject: Re: Swap and 2.6
> 
> ..., and ip22zilog is shot dead in 
> 2.6.x, ...
> 
> --Kumba


---1463811839-1947110491-1087827648=:17140
Content-Type: TEXT/PLAIN; charset=US-ASCII; name="ip22zilog.diff"
Content-Transfer-Encoding: BASE64
Content-ID: <Pine.LNX.4.21.0406211620480.17140@Opal.Peter>
Content-Description: 
Content-Disposition: attachment; filename="ip22zilog.diff"

ZGlmZiAtTmF1ciBsaW51eC0yLjYueC1jdnN3ZWIvYXJjaC9taXBzL3NnaS1p
cDIyL2lwMjItc2V0dXAuYyBsaW51eC0yLjYueC1sb2NhbC9hcmNoL21pcHMv
c2dpLWlwMjIvaXAyMi1zZXR1cC5jDQotLS0gbGludXgtMi42LngtY3Zzd2Vi
L2FyY2gvbWlwcy9zZ2ktaXAyMi9pcDIyLXNldHVwLmMJVGh1IEFwciAyOSAx
NDozNzoxMCAyMDA0DQorKysgbGludXgtMi42LngtbG9jYWwvYXJjaC9taXBz
L3NnaS1pcDIyL2lwMjItc2V0dXAuYwlXZWQgSnVuIDE2IDIzOjIzOjA3IDIw
MDQNCkBAIC05OSw2ICs5OSw5IEBADQogCQkJc3RyY3B5KG9wdGlvbnMsIGJh
dWQpOw0KIAkJYWRkX3ByZWZlcnJlZF9jb25zb2xlKCJ0dHlTIiwgKihjdHlw
ZSArIDEpID09ICcyJyA/IDEgOiAwLA0KIAkJCQkgICAgICBiYXVkID8gb3B0
aW9ucyA6IE5VTEwpOw0KKyNpZmRlZiBDT05GSUdfU0VSSUFMX0lQMjJfWklM
T0dfQ09OU09MRQ0KKwkJc2VyaWFsX2NvbnNvbGUgPSAqKGN0eXBlICsgMSkg
PT0gJzInID8gMiA6IDE7DQorI2VuZGlmDQogCX0gZWxzZSBpZiAoIWN0eXBl
IHx8ICpjdHlwZSAhPSAnZycpIHsNCiAJCS8qIFVzZSBBUkMgaWYgd2UgZG9u
J3Qgd2FudCBzZXJpYWwgKCdkJykgb3IgTmV3cG9ydCAoJ2cnKS4gKi8NCiAJ
CXByb21fZmxhZ3MgfD0gUFJPTV9GTEFHX1VTRV9BU19DT05TT0xFOw0KQEAg
LTE1MCwzICsxNTMsNyBAQA0KIH0NCiANCiBlYXJseV9pbml0Y2FsbChpcDIy
X3NldHVwKTsNCisvKg0KKyAqIFJldmlzaW9uIDEuMzgsIFRodSBBcHIgMjkg
MTQ6Mzc6MTAgMjAwNCBVVEMNCisgKiBXZWQgSnVuIDE2IDIzOjIzOjA3IDIw
MDQNCisgKi8NCmRpZmYgLU5hdXIgbGludXgtMi42LngtY3Zzd2ViL2RyaXZl
cnMvc2VyaWFsL2lwMjJ6aWxvZy5jIGxpbnV4LTIuNi54LWxvY2FsL2RyaXZl
cnMvc2VyaWFsL2lwMjJ6aWxvZy5jDQotLS0gbGludXgtMi42LngtY3Zzd2Vi
L2RyaXZlcnMvc2VyaWFsL2lwMjJ6aWxvZy5jCVR1ZSBEZWMgMjMgMTY6MDI6
MTMgMjAwMw0KKysrIGxpbnV4LTIuNi54LWxvY2FsL2RyaXZlcnMvc2VyaWFs
L2lwMjJ6aWxvZy5jCVdlZCBKdW4gMTYgMjM6MjI6MzcgMjAwNA0KQEAgLTYy
LDcgKzYyLDcgQEANCiAjZGVmaW5lIE5VTV9JUDIyWklMT0cJMQ0KICNkZWZp
bmUgTlVNX0NIQU5ORUxTCShOVU1fSVAyMlpJTE9HICogMikNCiANCi0jZGVm
aW5lIFpTX0NMT0NLCQk0OTE1MjAwIC8qIFppbG9nIGlucHV0IGNsb2NrIHJh
dGUuICovDQorI2RlZmluZSBaU19DTE9DSwkJMzY3MjAwMAkvKiBaaWxvZyBp
bnB1dCBjbG9jayByYXRlICovDQogI2RlZmluZSBaU19DTE9DS19ESVZJU09S
CTE2ICAgICAgLyogRGl2aXNvciB0aGlzIGRyaXZlciB1c2VzLiAqLw0KIA0K
IC8qDQpAQCAtOTU1LDYgKzk1NSw3IEBADQogCS5kcml2ZXJfbmFtZQk9CSJ0
dHlTIiwNCiAJLmRldmZzX25hbWUJPQkidHR5LyIsDQogCS5tYWpvcgkJPQlU
VFlfTUFKT1IsDQorCS5kZXZfbmFtZQk9CSJ0dHlTIiwNCiB9Ow0KIA0KIHN0
YXRpYyB2b2lkICogX19pbml0IGFsbG9jX29uZV90YWJsZSh1bnNpZ25lZCBs
b25nIHNpemUpDQpAQCAtMTE2OSw4ICsxMTcwLDExIEBADQogCQlpZiAoIWlw
MjJ6aWxvZ19jaGlwX3JlZ3NbY2hpcF0pIHsNCiAJCQlpcDIyemlsb2dfY2hp
cF9yZWdzW2NoaXBdID0gcnAgPSBnZXRfenMoY2hpcCk7DQogDQotCQkJdXBb
KGNoaXAgKiAyKSArIDBdLnBvcnQubWVtYmFzZSA9IChjaGFyICopICZycC0+
Y2hhbm5lbEE7DQotCQkJdXBbKGNoaXAgKiAyKSArIDFdLnBvcnQubWVtYmFz
ZSA9IChjaGFyICopICZycC0+Y2hhbm5lbEI7DQorCQkJdXBbKGNoaXAgKiAy
KSArIDBdLnBvcnQubWVtYmFzZSA9IChjaGFyICopICZycC0+Y2hhbm5lbEI7
DQorCQkJdXBbKGNoaXAgKiAyKSArIDFdLnBvcnQubWVtYmFzZSA9IChjaGFy
ICopICZycC0+Y2hhbm5lbEE7DQorDQorCQkJdXBbKGNoaXAgKiAyKSArIDBd
LnBvcnQubWFwYmFzZSA9IENQSFlTQUREUigmcnAtPmNoYW5uZWxCKTsNCisJ
CQl1cFsoY2hpcCAqIDIpICsgMV0ucG9ydC5tYXBiYXNlID0gQ1BIWVNBRERS
KCZycC0+Y2hhbm5lbEEpOw0KIAkJfQ0KIA0KIAkJLyogQ2hhbm5lbCBBICov
DQpAQCAtMTMwNSwzICsxMzA5LDcgQEANCiBNT0RVTEVfQVVUSE9SKCJSYWxm
IEJhZWNobGUgPHJhbGZAbGludXgtbWlwcy5vcmc+Iik7DQogTU9EVUxFX0RF
U0NSSVBUSU9OKCJTR0kgWmlsb2cgc2VyaWFsIHBvcnQgZHJpdmVyIik7DQog
TU9EVUxFX0xJQ0VOU0UoIkdQTCIpOw0KKy8qDQorICogUmV2aXNpb24gMS4x
MSwgVHVlIERlYyAyMyAxNjowMjoxMyAyMDAzIFVUQw0KKyAqIFdlZCBKdW4g
MTYgMjM6MjI6MzcgMjAwNCAoMTA4NzQyMDk1NykNCisgKi8NCg==
---1463811839-1947110491-1087827648=:17140--

From yuasa@hh.iij4u.or.jp Mon Jun 21 17:33:31 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 21 Jun 2004 17:33:39 +0100 (BST)
Received: from mo02.iij4u.or.jp ([IPv6:::ffff:210.130.0.19]:61131 "EHLO
	mo02.iij4u.or.jp") by linux-mips.org with ESMTP id <S8225355AbUFUQdb>;
	Mon, 21 Jun 2004 17:33:31 +0100
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 BAA20657;
	Tue, 22 Jun 2004 01:33:26 +0900 (JST)
Received: 4UMDO00 id i5LGXPM10744; Tue, 22 Jun 2004 01:33:26 +0900 (JST)
Received: 4UMRO00 id i5LGXNL25228; Tue, 22 Jun 2004 01:33:24 +0900 (JST)
	from stratos (64.43.138.210.xn.2iij.net [210.138.43.64]) (authenticated)
Date: Tue, 22 Jun 2004 01:33:22 +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] vr41xx: remove Eagle support
Message-Id: <20040622013322.0273fadb.yuasa@hh.iij4u.or.jp>
X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; i386-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: 5341
X-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

Hi Ralf,

NEC Eagle is obsolete hardware.
We have Victor MP-C30x as similar hardware,
I'm going to continue support of Victor MP-C30x and I decided to drop NEC Eagle.

Please apply this patch to v2.6 CVS tree.

Yoichi

diff -urN -X dontdiff linux-orig/arch/mips/Kconfig linux/arch/mips/Kconfig
--- linux-orig/arch/mips/Kconfig	Sun Jun 20 10:35:39 2004
+++ linux/arch/mips/Kconfig	Tue Jun 22 00:59:30 2004
@@ -91,13 +91,6 @@
 	select IRQ_CPU
 	select ISA
 
-config NEC_EAGLE
-	bool "Support for NEC Eagle/Hawk board"
-	select DMA_NONCOHERENT
-	select IRQ_CPU
-	depends on MACH_VR41XX
-	select HW_HAS_PCI
-
 config TANBAC_TB0226
 	bool "Support for TANBAC TB0226 (Mbase)"
 	depends on MACH_VR41XX
@@ -885,7 +878,7 @@
 
 config CPU_LITTLE_ENDIAN
 	bool "Generate little endian code"
-	default y if ACER_PICA_61 || CASIO_E55 || DDB5074 || DDB5476 || DDB5477 || MACH_DECSTATION || HP_LASERJET || IBM_WORKPAD || LASAT || MIPS_COBALT || MIPS_ITE8172 || MIPS_IVR || SOC_AU1X00 || NEC_OSPREY || NEC_EAGLE || OLIVETTI_M700 || SNI_RM200_PCI || VICTOR_MPC30X || ZAO_CAPCELLA
+	default y if ACER_PICA_61 || CASIO_E55 || DDB5074 || DDB5476 || DDB5477 || MACH_DECSTATION || HP_LASERJET || IBM_WORKPAD || LASAT || MIPS_COBALT || MIPS_ITE8172 || MIPS_IVR || SOC_AU1X00 || NEC_OSPREY || OLIVETTI_M700 || SNI_RM200_PCI || VICTOR_MPC30X || ZAO_CAPCELLA
 	default n if BAGET_MIPS || MIPS_EV64120 || MIPS_EV96100 || MOMENCO_OCELOT || MOMENCO_OCELOT_G || SGI_IP22 || SGI_IP27 || SGI_IP32 || TOSHIBA_JMR3927
 	help
 	  Some MIPS machines can be configured for either little or big endian
diff -urN -X dontdiff linux-orig/arch/mips/configs/eagle_defconfig linux/arch/mips/configs/eagle_defconfig
--- linux-orig/arch/mips/configs/eagle_defconfig	Sun Jun 20 10:35:41 2004
+++ linux/arch/mips/configs/eagle_defconfig	Thu Jan  1 09:00:00 1970
@@ -1,750 +0,0 @@
-#
-# 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_POSIX_MQUEUE is not set
-# CONFIG_BSD_PROCESS_ACCT is not set
-CONFIG_SYSCTL=y
-# CONFIG_AUDIT is not set
-CONFIG_LOG_BUF_SHIFT=14
-CONFIG_HOTPLUG=y
-# 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
-CONFIG_IOSCHED_CFQ=y
-# CONFIG_CC_OPTIMIZE_FOR_SIZE is not set
-
-#
-# 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=y
-# CONFIG_CASIO_E55 is not set
-# CONFIG_IBM_WORKPAD is not set
-CONFIG_NEC_EAGLE=y
-# CONFIG_TANBAC_TB0226 is not set
-# CONFIG_TANBAC_TB0229 is not set
-# CONFIG_VICTOR_MPC30X is not set
-# CONFIG_ZAO_CAPCELLA is not set
-CONFIG_PCI_VR41XX=y
-CONFIG_VRC4173=y
-# 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_MIPS_ITE8172 is not set
-# CONFIG_MIPS_ATLAS 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_SGI_IP22 is not set
-# CONFIG_SGI_IP32 is not set
-# CONFIG_SOC_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_CPU_LITTLE_ENDIAN=y
-CONFIG_IRQ_CPU=y
-CONFIG_MIPS_L1_CACHE_SHIFT=5
-# CONFIG_FB 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=y
-# 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_8KB is not set
-# CONFIG_PAGE_SIZE_16KB is not set
-# CONFIG_PAGE_SIZE_64KB is not set
-# CONFIG_CPU_ADVANCED is not set
-CONFIG_CPU_HAS_SYNC=y
-# CONFIG_PREEMPT is not set
-# CONFIG_DEBUG_SPINLOCK_SLEEP is not set
-
-#
-# Bus options (PCI, PCMCIA, EISA, ISA, TC)
-#
-CONFIG_HW_HAS_PCI=y
-CONFIG_PCI=y
-CONFIG_PCI_LEGACY_PROC=y
-CONFIG_PCI_NAMES=y
-CONFIG_MMU=y
-
-#
-# PCMCIA/CardBus support
-#
-CONFIG_PCMCIA=y
-# CONFIG_PCMCIA_DEBUG is not set
-# CONFIG_YENTA is not set
-# CONFIG_I82092 is not set
-# CONFIG_TCIC is not set
-# CONFIG_PCMCIA_VRC4173 is not set
-
-#
-# PCI Hotplug Support
-#
-# CONFIG_HOTPLUG_PCI is not set
-
-#
-# Executable file formats
-#
-CONFIG_BINFMT_ELF=y
-# CONFIG_BINFMT_MISC is not set
-CONFIG_TRAD_SIGNALS=y
-
-#
-# Device Drivers
-#
-
-#
-# Generic Driver Options
-#
-# CONFIG_FW_LOADER is not set
-
-#
-# Memory Technology Devices (MTD)
-#
-CONFIG_MTD=y
-# CONFIG_MTD_DEBUG is not set
-# CONFIG_MTD_PARTITIONS is not set
-# CONFIG_MTD_CONCAT is not set
-
-#
-# User Modules And Translation Layers
-#
-CONFIG_MTD_CHAR=y
-CONFIG_MTD_BLOCK=y
-# CONFIG_FTL is not set
-# CONFIG_NFTL is not set
-# CONFIG_INFTL is not set
-
-#
-# RAM/ROM/Flash chip drivers
-#
-CONFIG_MTD_CFI=y
-# CONFIG_MTD_JEDECPROBE is not set
-CONFIG_MTD_GEN_PROBE=y
-CONFIG_MTD_CFI_ADV_OPTIONS=y
-CONFIG_MTD_CFI_NOSWAP=y
-# CONFIG_MTD_CFI_BE_BYTE_SWAP is not set
-# CONFIG_MTD_CFI_LE_BYTE_SWAP is not set
-# CONFIG_MTD_CFI_GEOMETRY is not set
-CONFIG_MTD_CFI_INTELEXT=y
-# CONFIG_MTD_CFI_AMDSTD is not set
-# CONFIG_MTD_CFI_STAA is not set
-# CONFIG_MTD_RAM is not set
-# CONFIG_MTD_ROM is not set
-# CONFIG_MTD_ABSENT is not set
-# CONFIG_MTD_OBSOLETE_CHIPS is not set
-
-#
-# Mapping drivers for chip access
-#
-# CONFIG_MTD_COMPLEX_MAPPINGS is not set
-CONFIG_MTD_PHYSMAP=y
-CONFIG_MTD_PHYSMAP_START=0x1c000000
-CONFIG_MTD_PHYSMAP_LEN=0x2000000
-CONFIG_MTD_PHYSMAP_BUSWIDTH=4
-
-#
-# Self-contained MTD device drivers
-#
-# CONFIG_MTD_PMC551 is not set
-# CONFIG_MTD_SLRAM is not set
-# CONFIG_MTD_MTDRAM is not set
-# CONFIG_MTD_BLKMTD is not set
-
-#
-# Disk-On-Chip Device Drivers
-#
-# CONFIG_MTD_DOC2000 is not set
-# CONFIG_MTD_DOC2001 is not set
-# CONFIG_MTD_DOC2001PLUS is not set
-
-#
-# NAND Flash Device Drivers
-#
-# CONFIG_MTD_NAND is not set
-
-#
-# Parallel port support
-#
-# CONFIG_PARPORT is not set
-
-#
-# Plug and Play support
-#
-
-#
-# 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_CARMEL is not set
-# CONFIG_BLK_DEV_RAM is not set
-# CONFIG_LBD is not set
-
-#
-# ATA/ATAPI/MFM/RLL support
-#
-CONFIG_IDE=y
-CONFIG_BLK_DEV_IDE=y
-
-#
-# Please see Documentation/ide.txt for help/info on IDE drives
-#
-CONFIG_BLK_DEV_IDEDISK=y
-CONFIG_IDEDISK_MULTI_MODE=y
-CONFIG_BLK_DEV_IDECS=y
-# CONFIG_BLK_DEV_IDECD is not set
-# CONFIG_BLK_DEV_IDETAPE is not set
-# CONFIG_BLK_DEV_IDEFLOPPY is not set
-# CONFIG_IDE_TASK_IOCTL is not set
-CONFIG_IDE_TASKFILE_IO=y
-
-#
-# IDE chipset support/bugfixes
-#
-CONFIG_IDE_GENERIC=y
-# CONFIG_BLK_DEV_IDEPCI is not set
-# CONFIG_IDE_ARM is not set
-# CONFIG_BLK_DEV_IDEDMA is not set
-# CONFIG_IDEDMA_AUTO is not set
-# CONFIG_BLK_DEV_HD 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
-#
-# CONFIG_IEEE1394 is not set
-
-#
-# I2O device support
-#
-# CONFIG_I2O is not set
-
-#
-# Networking support
-#
-CONFIG_NET=y
-
-#
-# Networking options
-#
-CONFIG_PACKET=y
-CONFIG_PACKET_MMAP=y
-CONFIG_NETLINK_DEV=y
-CONFIG_UNIX=y
-CONFIG_NET_KEY=y
-CONFIG_INET=y
-CONFIG_IP_MULTICAST=y
-# CONFIG_IP_ADVANCED_ROUTER is not set
-CONFIG_IP_PNP=y
-# CONFIG_IP_PNP_DHCP is not set
-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_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_NETFILTER is not set
-CONFIG_XFRM=y
-# CONFIG_XFRM_USER is not set
-
-#
-# SCTP Configuration (EXPERIMENTAL)
-#
-# CONFIG_IP_SCTP is not set
-# CONFIG_ATM is not set
-# CONFIG_BRIDGE is not set
-# CONFIG_VLAN_8021Q is not set
-# CONFIG_DECNET 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_NETPOLL is not set
-# CONFIG_NET_POLL_CONTROLLER is not set
-# CONFIG_HAMRADIO is not set
-# CONFIG_IRDA is not set
-# CONFIG_BT is not set
-CONFIG_NETDEVICES=y
-# 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
-
-#
-# ARCnet devices
-#
-# CONFIG_ARCNET is not set
-
-#
-# Ethernet (10 or 100Mbit)
-#
-CONFIG_NET_ETHERNET=y
-# CONFIG_MII is not set
-# 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 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_SK98LIN is not set
-# CONFIG_TIGON3 is not set
-
-#
-# Ethernet (10000 Mbit)
-#
-# CONFIG_IXGB is not set
-# CONFIG_S2IO is not set
-
-#
-# Token Ring devices
-#
-# CONFIG_TR is not set
-
-#
-# Wireless LAN (non-hamradio)
-#
-# CONFIG_NET_RADIO is not set
-
-#
-# PCMCIA network device support
-#
-CONFIG_NET_PCMCIA=y
-# CONFIG_PCMCIA_3C589 is not set
-# CONFIG_PCMCIA_3C574 is not set
-CONFIG_PCMCIA_FMVJ18X=y
-CONFIG_PCMCIA_PCNET=m
-# CONFIG_PCMCIA_NMCLAN is not set
-# CONFIG_PCMCIA_SMC91C92 is not set
-# CONFIG_PCMCIA_XIRC2PS is not set
-# CONFIG_PCMCIA_AXNET is not set
-
-#
-# Wan interfaces
-#
-# CONFIG_WAN is not set
-# CONFIG_FDDI is not set
-# CONFIG_HIPPI is not set
-# CONFIG_PPP is not set
-# CONFIG_SLIP is not set
-# CONFIG_SHAPER is not set
-# CONFIG_NETCONSOLE is not set
-
-#
-# ISDN subsystem
-#
-# CONFIG_ISDN 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=y
-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_CS is not set
-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_LEGACY_PTYS=y
-CONFIG_LEGACY_PTY_COUNT=256
-# CONFIG_QIC02_TAPE is not set
-
-#
-# IPMI
-#
-# CONFIG_IPMI_HANDLER is not set
-
-#
-# Watchdog Cards
-#
-CONFIG_WATCHDOG=y
-# CONFIG_WATCHDOG_NOWAYOUT is not set
-
-#
-# Watchdog Device Drivers
-#
-# CONFIG_SOFT_WATCHDOG is not set
-
-#
-# PCI-based Watchdog Cards
-#
-# CONFIG_PCIPCWATCHDOG is not set
-# CONFIG_WDTPCI is not set
-# CONFIG_RTC is not set
-# CONFIG_GEN_RTC 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
-# CONFIG_DRM is not set
-
-#
-# PCMCIA character devices
-#
-# CONFIG_SYNCLINK_CS is not set
-# CONFIG_RAW_DRIVER is not set
-
-#
-# I2C support
-#
-# CONFIG_I2C is not set
-
-#
-# Misc devices
-#
-
-#
-# 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
-
-#
-# USB Gadget Support
-#
-# 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=y
-
-#
-# 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_SYSFS=y
-# CONFIG_DEVFS_FS is not set
-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_HFSPLUS_FS is not set
-# CONFIG_BEFS_FS is not set
-# CONFIG_BFS_FS is not set
-# CONFIG_EFS_FS is not set
-CONFIG_JFFS_FS=y
-CONFIG_JFFS_FS_VERBOSE=0
-CONFIG_JFFS2_FS=y
-CONFIG_JFFS2_FS_DEBUG=0
-# CONFIG_JFFS2_FS_NAND is not set
-# 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 is not set
-# CONFIG_NFS_V4 is not set
-# CONFIG_NFS_DIRECTIO is not set
-CONFIG_NFSD=y
-# CONFIG_NFSD_V3 is not set
-# CONFIG_NFSD_TCP is not set
-CONFIG_ROOT_NFS=y
-CONFIG_LOCKD=y
-CONFIG_EXPORTFS=y
-CONFIG_SUNRPC=y
-# CONFIG_RPCSEC_GSS_KRB5 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_AFS_FS is not set
-
-#
-# Partition Types
-#
-# CONFIG_PARTITION_ADVANCED is not set
-CONFIG_MSDOS_PARTITION=y
-
-#
-# Native Language Support
-#
-# CONFIG_NLS is not set
-
-#
-# Kernel hacking
-#
-CONFIG_CROSSCOMPILE=y
-CONFIG_CMDLINE=""
-# CONFIG_DEBUG_KERNEL is not set
-
-#
-# Security options
-#
-# CONFIG_SECURITY is not set
-
-#
-# Cryptographic options
-#
-CONFIG_CRYPTO=y
-CONFIG_CRYPTO_HMAC=y
-CONFIG_CRYPTO_NULL=y
-# CONFIG_CRYPTO_MD4 is not set
-# CONFIG_CRYPTO_MD5 is not set
-# CONFIG_CRYPTO_SHA1 is not set
-# CONFIG_CRYPTO_SHA256 is not set
-CONFIG_CRYPTO_SHA512=y
-# CONFIG_CRYPTO_DES is not set
-# CONFIG_CRYPTO_BLOWFISH is not set
-CONFIG_CRYPTO_TWOFISH=y
-# CONFIG_CRYPTO_SERPENT is not set
-CONFIG_CRYPTO_AES=y
-# CONFIG_CRYPTO_CAST5 is not set
-# CONFIG_CRYPTO_CAST6 is not set
-# CONFIG_CRYPTO_ARC4 is not set
-CONFIG_CRYPTO_DEFLATE=y
-CONFIG_CRYPTO_MICHAEL_MIC=y
-CONFIG_CRYPTO_CRC32C=m
-# CONFIG_CRYPTO_TEST is not set
-
-#
-# Library routines
-#
-CONFIG_CRC32=y
-CONFIG_LIBCRC32C=m
-CONFIG_ZLIB_INFLATE=y
-CONFIG_ZLIB_DEFLATE=y
diff -urN -X dontdiff linux-orig/arch/mips/pci/Makefile linux/arch/mips/pci/Makefile
--- linux-orig/arch/mips/pci/Makefile	Sun Jun  6 12:40:24 2004
+++ linux/arch/mips/pci/Makefile	Tue Jun 22 00:58:38 2004
@@ -39,7 +39,6 @@
 obj-$(CONFIG_MOMENCO_OCELOT)	+= fixup-ocelot.o pci-ocelot.o
 obj-$(CONFIG_MOMENCO_OCELOT_C)	+= fixup-ocelot-c.o pci-ocelot-c.o
 obj-$(CONFIG_MOMENCO_OCELOT_G)	+= fixup-ocelot-g.o ops-gt64240.o pci-ocelot-g.o
-obj-$(CONFIG_NEC_EAGLE)		+= fixup-eagle.o ops-vrc4173.o
 obj-$(CONFIG_PMC_YOSEMITE)	+= fixup-yosemite.o ops-titan.o ops-titan-ht.o \
 				   pci-yosemite.o
 obj-$(CONFIG_SGI_IP27)		+= pci-ip27.o
diff -urN -X dontdiff linux-orig/arch/mips/pci/fixup-eagle.c linux/arch/mips/pci/fixup-eagle.c
--- linux-orig/arch/mips/pci/fixup-eagle.c	Fri Feb 20 00:49:46 2004
+++ linux/arch/mips/pci/fixup-eagle.c	Thu Jan  1 09:00:00 1970
@@ -1,60 +0,0 @@
-/*
- * arch/mips/vr41xx/nec-eagle/pci_fixup.c
- *
- * The NEC Eagle/Hawk Board specific PCI fixups.
- *
- * Author: Yoichi Yuasa <you@mvista.com, or source@mvista.com>
- *
- * 2001-2002,2004 (c) MontaVista, Software, Inc. This file is licensed under
- * the terms of the GNU General Public License version 2. This program
- * is licensed "as is" without any warranty of any kind, whether express
- * or implied.
- */
-#include <linux/init.h>
-#include <linux/pci.h>
-
-#include <asm/vr41xx/eagle.h>
-#include <asm/vr41xx/vrc4173.h>
-
-/*
- * Shortcuts
- */
-#define INTA	CP_INTA_IRQ
-#define INTB	CP_INTB_IRQ
-#define INTC	CP_INTC_IRQ
-#define INTD	CP_INTD_IRQ
-#define PCMCIA1	VRC4173_PCMCIA1_IRQ
-#define PCMCIA2	VRC4173_PCMCIA2_IRQ
-#define LAN	LANINTA_IRQ
-#define SLOT	PCISLOT_IRQ
-
-static char irq_tab_eagle[][5] __initdata = {
- [ 8] = { 0,    INTA, INTB, INTC, INTD },
- [ 9] = { 0,    INTD, INTA, INTB, INTC },
- [10] = { 0,    INTC, INTD, INTA, INTB },
- [12] = { 0, PCMCIA1,    0,    0,    0 },
- [13] = { 0, PCMCIA2,    0,    0,    0 },
- [28] = { 0,     LAN,    0,    0,    0 },
- [29] = { 0,    SLOT, INTB, INTC, INTD },
-};
-
-/*
- * This is a multifunction device.
- */
-static char irq_func_tab[] __initdata = {
-	VRC4173_CASCADE_IRQ,
-	VRC4173_AC97_IRQ,
-	VRC4173_USB_IRQ
-};
-
-int __init pcibios_map_irq(struct pci_dev *dev, u8 slot, u8 pin)
-{
-	if (slot == 30)
-		return irq_func_tab[PCI_FUNC(dev->devfn)];
-
-	return irq_tab_eagle[slot][pin];
-}
-
-struct pci_fixup pcibios_fixups[] __initdata = {
-	{	.pass = 0,	},
-};
diff -urN -X dontdiff linux-orig/arch/mips/pci/ops-vrc4173.c linux/arch/mips/pci/ops-vrc4173.c
--- linux-orig/arch/mips/pci/ops-vrc4173.c	Fri Jun 13 23:19:56 2003
+++ linux/arch/mips/pci/ops-vrc4173.c	Thu Jan  1 09:00:00 1970
@@ -1,120 +0,0 @@
-/*
- * FILE NAME
- *	arch/mips/vr41xx/nec-eagle/vrc4173.c
- *
- * BRIEF MODULE DESCRIPTION
- *	Pre-setup for NEC VRC4173.
- *
- * Author: Yoichi Yuasa
- *         yyuasa@mvista.com or source@mvista.com
- *
- * Copyright 2001,2002 MontaVista Software Inc.
- *
- *  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 SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESS OR IMPLIED
- *  WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
- *  MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.
- *  IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT,
- *  INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING,
- *  BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS
- *  OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
- *  ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR
- *  TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE
- *  USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
- *
- *  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.,
- *  675 Mass Ave, Cambridge, MA 02139, USA.
- */
-#include <linux/init.h>
-#include <linux/pci.h>
-#include <linux/module.h>
-
-#include <asm/io.h>
-#include <asm/vr41xx/eagle.h>
-#include <asm/vr41xx/vrc4173.h>
-
-#define PCI_CONFIG_ADDR	KSEG1ADDR(0x0f000c18)
-#define PCI_CONFIG_DATA	KSEG1ADDR(0x0f000c14)
-
-static inline void config_writeb(u8 reg, u8 val)
-{
-	u32 data;
-	int shift;
-
-	writel((1UL << 0x1e) | (reg & 0xfc), PCI_CONFIG_ADDR);
-	data = readl(PCI_CONFIG_DATA);
-
-	shift = (reg & 3) << 3;
-	data &= ~(0xff << shift);
-	data |= (((u32) val) << shift);
-
-	writel(data, PCI_CONFIG_DATA);
-}
-
-static inline u16 config_readw(u8 reg)
-{
-	u32 data;
-
-	writel(((1UL << 30) | (reg & 0xfc)), PCI_CONFIG_ADDR);
-	data = readl(PCI_CONFIG_DATA);
-
-	return (u16) (data >> ((reg & 2) << 3));
-}
-
-static inline u32 config_readl(u8 reg)
-{
-	writel(((1UL << 30) | (reg & 0xfc)), PCI_CONFIG_ADDR);
-
-	return readl(PCI_CONFIG_DATA);
-}
-
-static inline void config_writel(u8 reg, u32 val)
-{
-	writel((1UL << 0x1e) | (reg & 0xfc), PCI_CONFIG_ADDR);
-	writel(val, PCI_CONFIG_DATA);
-}
-
-void __init vrc4173_preinit(void)
-{
-	u32 cmdsts, base;
-	u16 cmu_mask;
-
-
-	if ((config_readw(PCI_VENDOR_ID) == PCI_VENDOR_ID_NEC) &&
-	    (config_readw(PCI_DEVICE_ID) == PCI_DEVICE_ID_NEC_VRC4173)) {
-		/*
-		 * Initialized NEC VRC4173 Bus Control Unit
-		 */
-		cmdsts = config_readl(PCI_COMMAND);
-		config_writel(PCI_COMMAND,
-			      cmdsts |
-			      PCI_COMMAND_IO |
-			      PCI_COMMAND_MEMORY | PCI_COMMAND_MASTER);
-
-		config_writeb(PCI_LATENCY_TIMER, 0x80);
-
-		config_writel(PCI_BASE_ADDRESS_0, VR41XX_PCI_IO_START);
-		base = config_readl(PCI_BASE_ADDRESS_0);
-		base &= PCI_BASE_ADDRESS_IO_MASK;
-		config_writeb(0x40, 0x01);
-
-		/* CARDU1 IDSEL = AD12, CARDU2 IDSEL = AD13 */
-		config_writeb(0x41, 0);
-
-		cmu_mask = 0x1000;
-		outw(cmu_mask, base + 0x040);
-		cmu_mask |= 0x0800;
-		outw(cmu_mask, base + 0x040);
-
-		outw(0x000f, base + 0x042);	/* Soft reset of CMU */
-		cmu_mask |= 0x05e0;
-		outw(cmu_mask, base + 0x040);
-		cmu_mask = inw(base + 0x040);	/* dummy read */
-		outw(0x0000, base + 0x042);
-	}
-}
diff -urN -X dontdiff linux-orig/arch/mips/vr41xx/nec-eagle/Makefile linux/arch/mips/vr41xx/nec-eagle/Makefile
--- linux-orig/arch/mips/vr41xx/nec-eagle/Makefile	Thu Feb 26 00:23:50 2004
+++ linux/arch/mips/vr41xx/nec-eagle/Makefile	Thu Jan  1 09:00:00 1970
@@ -1,10 +0,0 @@
-#
-# Makefile for the NEC Eagle/Hawk specific parts of the kernel
-#
-# Author: Yoichi Yuasa
-#         yyuasa@mvista.com or source@mvista.com
-#
-# Copyright 2001,2002 MontaVista Software Inc.
-#
-
-obj-y			+= irq.o setup.o
diff -urN -X dontdiff linux-orig/arch/mips/vr41xx/nec-eagle/irq.c linux/arch/mips/vr41xx/nec-eagle/irq.c
--- linux-orig/arch/mips/vr41xx/nec-eagle/irq.c	Thu Feb 26 07:05:00 2004
+++ linux/arch/mips/vr41xx/nec-eagle/irq.c	Thu Jan  1 09:00:00 1970
@@ -1,190 +0,0 @@
-/*
- *  irq.c,  Interrupt routines for the NEC Eagle/Hawk board.
- *
- *  Copyright (C) 2002  MontaVista Software, Inc.
- *    Author: Yoichi Yuasa <yyuasa@mvista.com, or source@mvista.com>
- *  Copyright (C) 2004  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
- */
-/*
- * Changes:
- *  MontaVista Software Inc. <yyuasa@mvista.com> or <source@mvista.com>
- *  - New creation, NEC Eagle is supported.
- *  - Added support for NEC Hawk.
- *
- *  Yoichi Yuasa <yuasa@hh.iij4u.or.jp>
- *  - Changed from board_irq_init to driver module.
- */
-#include <linux/config.h>
-#include <linux/init.h>
-#include <linux/interrupt.h>
-#include <linux/module.h>
-#include <linux/types.h>
-
-#include <asm/io.h>
-#include <asm/vr41xx/eagle.h>
-
-MODULE_DESCRIPTION("IRQ module driver for NEC Eagle/Hawk");
-MODULE_AUTHOR("Yoichi Yuasa <yyuasa@mvista.com>");
-MODULE_LICENSE("GPL");
-
-static void enable_pciint_irq(unsigned int irq)
-{
-	uint8_t val;
-
-	val = readb(NEC_EAGLE_PCIINTMSKREG);
-	val |= (uint8_t)1 << (irq - PCIINT_IRQ_BASE);
-	writeb(val, NEC_EAGLE_PCIINTMSKREG);
-}
-
-static void disable_pciint_irq(unsigned int irq)
-{
-	uint8_t val;
-
-	val = readb(NEC_EAGLE_PCIINTMSKREG);
-	val &= ~((uint8_t)1 << (irq - PCIINT_IRQ_BASE));
-	writeb(val, NEC_EAGLE_PCIINTMSKREG);
-}
-
-static unsigned int startup_pciint_irq(unsigned int irq)
-{
-	enable_pciint_irq(irq);
-	return 0; /* never anything pending */
-}
-
-#define shutdown_pciint_irq	disable_pciint_irq
-#define ack_pciint_irq		disable_pciint_irq
-
-static void end_pciint_irq(unsigned int irq)
-{
-	if (!(irq_desc[irq].status & (IRQ_DISABLED | IRQ_INPROGRESS)))
-		enable_pciint_irq(irq);
-}
-
-static struct hw_interrupt_type pciint_irq_type = {
-	.typename	= "PCIINT",
-	.startup	= startup_pciint_irq,
-	.shutdown 	= shutdown_pciint_irq,
-	.enable       	= enable_pciint_irq,
-	.disable	= disable_pciint_irq,
-	.ack		= ack_pciint_irq,
-	.end		= end_pciint_irq,
-};
-
-static void enable_sdbint_irq(unsigned int irq)
-{
-	uint8_t val;
-
-	val = readb(NEC_EAGLE_SDBINTMSK);
-	val |= (uint8_t)1 << (irq - SDBINT_IRQ_BASE);
-	writeb(val, NEC_EAGLE_SDBINTMSK);
-}
-
-static void disable_sdbint_irq(unsigned int irq)
-{
-	uint8_t val;
-
-	val = readb(NEC_EAGLE_SDBINTMSK);
-	val &= ~((uint8_t)1 << (irq - SDBINT_IRQ_BASE));
-	writeb(val, NEC_EAGLE_SDBINTMSK);
-}
-
-static unsigned int startup_sdbint_irq(unsigned int irq)
-{
-	enable_sdbint_irq(irq);
-	return 0; /* never anything pending */
-}
-
-#define shutdown_sdbint_irq	disable_sdbint_irq
-#define ack_sdbint_irq		disable_sdbint_irq
-
-static void end_sdbint_irq(unsigned int irq)
-{
-	if (!(irq_desc[irq].status & (IRQ_DISABLED | IRQ_INPROGRESS)))
-		enable_sdbint_irq(irq);
-}
-
-static struct hw_interrupt_type sdbint_irq_type = {
-	.typename	= "SDBINT",
-	.startup	= startup_sdbint_irq,
-	.shutdown	= shutdown_sdbint_irq,
-	.enable		= enable_sdbint_irq,
-	.disable	= disable_sdbint_irq,
-	.ack		= ack_sdbint_irq,
-	.end		= end_sdbint_irq,
-};
-
-static int eagle_get_irq_number(int irq)
-{
-	uint8_t sdbint, pciint;
-	int i;
-
-	sdbint = readb(NEC_EAGLE_SDBINT);
-	sdbint &= (NEC_EAGLE_SDBINT_DEG | NEC_EAGLE_SDBINT_ENUM |
-	           NEC_EAGLE_SDBINT_SIO1INT | NEC_EAGLE_SDBINT_SIO2INT |
-	           NEC_EAGLE_SDBINT_PARINT);
-	pciint = readb(NEC_EAGLE_PCIINTREG);
-	pciint &= (NEC_EAGLE_PCIINT_CP_INTA | NEC_EAGLE_PCIINT_CP_INTB |
-	           NEC_EAGLE_PCIINT_CP_INTC | NEC_EAGLE_PCIINT_CP_INTD |
-	           NEC_EAGLE_PCIINT_LANINT);
-
-	for (i = 1; i < 6; i++)
-		if (sdbint & (0x01 << i))
-			return SDBINT_IRQ_BASE + i;
-
-	for (i = 0; i < 5; i++)
-		if (pciint & (0x01 << i))
-			return PCIINT_IRQ_BASE + i;
-
-	return -EINVAL;
-}
-
-static int __devinit eagle_irq_init(void)
-{
-	int i, retval;
-
-	writeb(0, NEC_EAGLE_SDBINTMSK);
-	writeb(0, NEC_EAGLE_PCIINTMSKREG);
-
-	vr41xx_set_irq_trigger(PCISLOT_PIN, TRIGGER_LEVEL, SIGNAL_THROUGH);
-	vr41xx_set_irq_level(PCISLOT_PIN, LEVEL_HIGH);
-
-	vr41xx_set_irq_trigger(FPGA_PIN, TRIGGER_LEVEL, SIGNAL_THROUGH);
-	vr41xx_set_irq_level(FPGA_PIN, LEVEL_HIGH);
-
-	vr41xx_set_irq_trigger(DCD_PIN, TRIGGER_EDGE, SIGNAL_HOLD);
-	vr41xx_set_irq_level(DCD_PIN, LEVEL_LOW);
-
-	for (i = SDBINT_IRQ_BASE; i <= SDBINT_IRQ_LAST; i++)
-		irq_desc[i].handler = &sdbint_irq_type;
-
-	for (i = PCIINT_IRQ_BASE; i <= PCIINT_IRQ_LAST; i++)
-		irq_desc[i].handler = &pciint_irq_type;
-
-	retval = vr41xx_cascade_irq(FPGA_CASCADE_IRQ, eagle_get_irq_number);
-	if (retval != 0)
-		printk(KERN_ERR "eagle: Cannot cascade IRQ %d\n", FPGA_CASCADE_IRQ);
-
-	return retval;
-}
-
-static void __devexit eagle_irq_exit(void)
-{
-	free_irq(FPGA_CASCADE_IRQ, NULL);
-}
-
-module_init(eagle_irq_init);
-module_exit(eagle_irq_exit);
diff -urN -X dontdiff linux-orig/arch/mips/vr41xx/nec-eagle/setup.c linux/arch/mips/vr41xx/nec-eagle/setup.c
--- linux-orig/arch/mips/vr41xx/nec-eagle/setup.c	Thu Apr 29 10:42:49 2004
+++ linux/arch/mips/vr41xx/nec-eagle/setup.c	Thu Jan  1 09:00:00 1970
@@ -1,97 +0,0 @@
-/*
- * arch/mips/vr41xx/nec-eagle/setup.c
- *
- * Setup for the NEC Eagle/Hawk board.
- *
- * Author: Yoichi Yuasa <yyuasa@mvista.com, or source@mvista.com>
- *
- * 2001-2004 (c) MontaVista, Software, Inc. This file is licensed under
- * the terms of the GNU General Public License version 2. This program
- * is licensed "as is" without any warranty of any kind, whether express
- * or implied.
- */
-#include <linux/config.h>
-#include <linux/ioport.h>
-
-#include <asm/io.h>
-#include <asm/pci_channel.h>
-#include <asm/vr41xx/eagle.h>
-
-#ifdef CONFIG_PCI
-
-extern void vrc4173_preinit(void);
-
-static struct resource vr41xx_pci_io_resource = {
-	"PCI I/O space",
-	VR41XX_PCI_IO_START,
-	VR41XX_PCI_IO_END,
-	IORESOURCE_IO
-};
-
-static struct resource vr41xx_pci_mem_resource = {
-	"PCI memory space",
-	VR41XX_PCI_MEM_START,
-	VR41XX_PCI_MEM_END,
-	IORESOURCE_MEM
-};
-
-extern struct pci_ops vr41xx_pci_ops;
-
-struct pci_controller vr41xx_controller = {
-	.pci_ops	= &vr41xx_pci_ops,
-	.io_resource	= &vr41xx_pci_io_resource,
-	.mem_resource	= &vr41xx_pci_mem_resource,
-};
-
-struct vr41xx_pci_address_space vr41xx_pci_mem1 = {
-	VR41XX_PCI_MEM1_BASE,
-	VR41XX_PCI_MEM1_MASK,
-	IO_MEM1_RESOURCE_START
-};
-
-struct vr41xx_pci_address_space vr41xx_pci_mem2 = {
-	VR41XX_PCI_MEM2_BASE,
-	VR41XX_PCI_MEM2_MASK,
-	IO_MEM2_RESOURCE_START
-};
-
-struct vr41xx_pci_address_space vr41xx_pci_io = {
-	VR41XX_PCI_IO_BASE,
-	VR41XX_PCI_IO_MASK,
-	IO_PORT_RESOURCE_START
-};
-
-static struct vr41xx_pci_address_map pci_address_map = {
-	&vr41xx_pci_mem1,
-	&vr41xx_pci_mem2,
-	&vr41xx_pci_io
-};
-#endif
-
-const char *get_system_type(void)
-{
-	return "NEC SDB-VR4122/VR4131(Eagle/Hawk)";
-}
-
-static int nec_eagle_setup(void)
-{
-	set_io_port_base(IO_PORT_BASE);
-	ioport_resource.start = IO_PORT_RESOURCE_START;
-	ioport_resource.end = IO_PORT_RESOURCE_END;
-
-#ifdef CONFIG_SERIAL_8250
-	vr41xx_select_siu_interface(SIU_RS232C, IRDA_NONE);
-	vr41xx_siu_init();
-	vr41xx_dsiu_init();
-#endif
-
-#ifdef CONFIG_PCI
-	vr41xx_pciu_init(&pci_address_map);
-
-	vrc4173_preinit();
-#endif
-
-	return 0;
-}
-
-early_initcall(nec_eagle_setup);
diff -urN -X dontdiff linux-orig/include/asm-mips/vr41xx/eagle.h linux/include/asm-mips/vr41xx/eagle.h
--- linux-orig/include/asm-mips/vr41xx/eagle.h	Mon Mar 24 00:01:42 2003
+++ linux/include/asm-mips/vr41xx/eagle.h	Thu Jan  1 09:00:00 1970
@@ -1,265 +0,0 @@
-/*
- * FILE NAME
- *	include/asm-mips/vr41xx/eagle.h
- *
- * BRIEF MODULE DESCRIPTION
- *	Include file for NEC Eagle board.
- *
- * Author: MontaVista Software, Inc.
- *         yyuasa@mvista.com or source@mvista.com
- *
- * Copyright 2001-2003 MontaVista Software Inc.
- *
- *  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 SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESS OR IMPLIED
- *  WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
- *  MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.
- *  IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT,
- *  INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING,
- *  BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS
- *  OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
- *  ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR
- *  TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE
- *  USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
- *
- *  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.,
- *  675 Mass Ave, Cambridge, MA 02139, USA.
- */
-#ifndef __NEC_EAGLE_H
-#define __NEC_EAGLE_H
-
-#include <asm/addrspace.h>
-#include <asm/vr41xx/vr41xx.h>
-
-/*
- * Board specific address mapping
- */
-#define VR41XX_PCI_MEM1_BASE		0x10000000
-#define VR41XX_PCI_MEM1_SIZE		0x04000000
-#define VR41XX_PCI_MEM1_MASK		0x7c000000
-
-#define VR41XX_PCI_MEM2_BASE		0x14000000
-#define VR41XX_PCI_MEM2_SIZE		0x02000000
-#define VR41XX_PCI_MEM2_MASK		0x7e000000
-
-#define VR41XX_PCI_IO_BASE		0x16000000
-#define VR41XX_PCI_IO_SIZE		0x02000000
-#define VR41XX_PCI_IO_MASK		0x7e000000
-
-#define VR41XX_PCI_IO_START		0x01000000
-#define VR41XX_PCI_IO_END		0x01ffffff
-
-#define VR41XX_PCI_MEM_START		0x12000000
-#define VR41XX_PCI_MEM_END		0x15ffffff
-
-#define IO_PORT_BASE			KSEG1ADDR(VR41XX_PCI_IO_BASE)
-#define IO_PORT_RESOURCE_START		0
-#define IO_PORT_RESOURCE_END		VR41XX_PCI_IO_SIZE
-#define IO_MEM1_RESOURCE_START		VR41XX_PCI_MEM1_BASE
-#define IO_MEM1_RESOURCE_END		(VR41XX_PCI_MEM1_BASE + VR41XX_PCI_MEM1_SIZE)
-#define IO_MEM2_RESOURCE_START		VR41XX_PCI_MEM2_BASE
-#define IO_MEM2_RESOURCE_END		(VR41XX_PCI_MEM2_BASE + VR41XX_PCI_MEM2_SIZE)
-
-/*
- * General-Purpose I/O Pin Number
- */
-#define VRC4173_PIN			1
-#define PCISLOT_PIN			4
-#define FPGA_PIN			5
-#define DCD_PIN				15
-
-/*
- * Interrupt Number
- */
-#define VRC4173_CASCADE_IRQ		GIU_IRQ(VRC4173_PIN)
-#define PCISLOT_IRQ			GIU_IRQ(PCISLOT_PIN)
-#define FPGA_CASCADE_IRQ		GIU_IRQ(FPGA_PIN)
-#define DCD_IRQ				GIU_IRQ(DCD_PIN)
-
-#define SDBINT_IRQ_BASE			88
-#define SDBINT_IRQ(x)			(SDBINT_IRQ_BASE + (x))
-/* RFU */
-#define DEG_IRQ				SDBINT_IRQ(1)
-#define ENUM_IRQ			SDBINT_IRQ(2)
-#define SIO1INT_IRQ			SDBINT_IRQ(3)
-#define SIO2INT_IRQ			SDBINT_IRQ(4)
-#define PARINT_IRQ			SDBINT_IRQ(5)
-#define SDBINT_IRQ_LAST			PARINT_IRQ
-
-#define PCIINT_IRQ_BASE			96
-#define PCIINT_IRQ(x)			(PCIINT_IRQ_BASE + (x))
-#define CP_INTA_IRQ			PCIINT_IRQ(0)
-#define CP_INTB_IRQ			PCIINT_IRQ(1)
-#define CP_INTC_IRQ			PCIINT_IRQ(2)
-#define CP_INTD_IRQ			PCIINT_IRQ(3)
-#define LANINTA_IRQ			PCIINT_IRQ(4)
-#define PCIINT_IRQ_LAST			LANINTA_IRQ
-
-/*
- * On board Devices I/O Mapping
- */
-#define NEC_EAGLE_SIO1RB		KSEG1ADDR(0x0DFFFEC0)
-#define NEC_EAGLE_SIO1TH		KSEG1ADDR(0x0DFFFEC0)
-#define NEC_EAGLE_SIO1IE		KSEG1ADDR(0x0DFFFEC2)
-#define NEC_EAGLE_SIO1IID		KSEG1ADDR(0x0DFFFEC4)
-#define NEC_EAGLE_SIO1FC		KSEG1ADDR(0x0DFFFEC4)
-#define NEC_EAGLE_SIO1LC		KSEG1ADDR(0x0DFFFEC6)
-#define NEC_EAGLE_SIO1MC		KSEG1ADDR(0x0DFFFEC8)
-#define NEC_EAGLE_SIO1LS		KSEG1ADDR(0x0DFFFECA)
-#define NEC_EAGLE_SIO1MS		KSEG1ADDR(0x0DFFFECC)
-#define NEC_EAGLE_SIO1SC		KSEG1ADDR(0x0DFFFECE)
-
-#define NEC_EAGLE_SIO2TH		KSEG1ADDR(0x0DFFFED0)
-#define NEC_EAGLE_SIO2IE		KSEG1ADDR(0x0DFFFED2)
-#define NEC_EAGLE_SIO2IID		KSEG1ADDR(0x0DFFFED4)
-#define NEC_EAGLE_SIO2FC		KSEG1ADDR(0x0DFFFED4)
-#define NEC_EAGLE_SIO2LC		KSEG1ADDR(0x0DFFFED6)
-#define NEC_EAGLE_SIO2MC		KSEG1ADDR(0x0DFFFED8)
-#define NEC_EAGLE_SIO2LS		KSEG1ADDR(0x0DFFFEDA)
-#define NEC_EAGLE_SIO2MS		KSEG1ADDR(0x0DFFFEDC)
-#define NEC_EAGLE_SIO2SC		KSEG1ADDR(0x0DFFFEDE)
-
-#define NEC_EAGLE_PIOPP_DATA		KSEG1ADDR(0x0DFFFEE0)
-#define NEC_EAGLE_PIOPP_STATUS		KSEG1ADDR(0x0DFFFEE2)
-#define NEC_EAGLE_PIOPP_CNT		KSEG1ADDR(0x0DFFFEE4)
-#define NEC_EAGLE_PIOPP_EPPADDR		KSEG1ADDR(0x0DFFFEE6)
-#define NEC_EAGLE_PIOPP_EPPDATA0	KSEG1ADDR(0x0DFFFEE8)
-#define NEC_EAGLE_PIOPP_EPPDATA1	KSEG1ADDR(0x0DFFFEEA)
-#define NEC_EAGLE_PIOPP_EPPDATA2	KSEG1ADDR(0x0DFFFEEC)
-
-#define NEC_EAGLE_PIOECP_DATA		KSEG1ADDR(0x0DFFFEF0)
-#define NEC_EAGLE_PIOECP_CONFIG		KSEG1ADDR(0x0DFFFEF2)
-#define NEC_EAGLE_PIOECP_EXTCNT		KSEG1ADDR(0x0DFFFEF4)
-
-/*
- *  FLSHCNT Register
- */
-#define NEC_EAGLE_FLSHCNT		KSEG1ADDR(0x0DFFFFA0)
-#define NEC_EAGLE_FLSHCNT_FRDY		0x80
-#define NEC_EAGLE_FLSHCNT_VPPE		0x40
-#define NEC_EAGLE_FLSHCNT_WP2		0x01
-
-/*
- * FLSHBANK Register
- */
-#define NEC_EAGLE_FLSHBANK		KSEG1ADDR(0x0DFFFFA4)
-#define NEC_EAGLE_FLSHBANK_S_BANK2	0x40
-#define NEC_EAGLE_FLSHBANK_S_BANK1	0x20
-#define NEC_EAGLE_FLSHBANK_BNKQ4	0x10
-#define NEC_EAGLE_FLSHBANK_BNKQ3	0x08
-#define NEC_EAGLE_FLSHBANK_BNKQ2	0x04
-#define NEC_EAGLE_FLSHBANK_BNKQ1	0x02
-#define NEC_EAGLE_FLSHBANK_BNKQ0	0x01
-
-/*
- * SWITCH Setting Register
- */
-#define NEC_EAGLE_SWTCHSET		KSEG1ADDR(0x0DFFFFA8)
-#define NEC_EAGLE_SWTCHSET_DP2SW4	0x80
-#define NEC_EAGLE_SWTCHSET_DP2SW3	0x40
-#define NEC_EAGLE_SWTCHSET_DP2SW2	0x20
-#define NEC_EAGLE_SWTCHSET_DP2SW1	0x10
-#define NEC_EAGLE_SWTCHSET_DP1SW4	0x08
-#define NEC_EAGLE_SWTCHSET_DP1SW3	0x04
-#define NEC_EAGLE_SWTCHSET_DP1SW2	0x02
-#define NEC_EAGLE_SWTCHSET_DP1SW1	0x01
-
-/*
- * PPT Parallel Port Device Controller
- */
-#define NEC_EAGLE_PPT_WRITE_DATA	KSEG1ADDR(0x0DFFFFB0)
-#define NEC_EAGLE_PPT_READ_DATA		KSEG1ADDR(0x0DFFFFB2)
-#define NEC_EAGLE_PPT_CNT		KSEG1ADDR(0x0DFFFFB4)
-#define NEC_EAGLE_PPT_CNT2		KSEG1ADDR(0x0DFFFFB4)
-
-/* Control Register */
-#define NEC_EAGLE_PPT_INTMSK		0x20
-#define NEC_EAGLE_PPT_PARIINT		0x10
-#define NEC_EAGLE_PPT_SELECTIN		0x08
-#define NEC_EAGLE_PPT_INIT		0x04
-#define NEC_EAGLE_PPT_AUTOFD		0x02
-#define NEC_EAGLE_PPT_STROBE		0x01
-
-/* Control Rgister 2 */
-#define NEC_EAGLE_PPT_PAREN		0x80
-#define NEC_EAGLE_PPT_AUTOEN		0x20
-#define NEC_EAGLE_PPT_BUSY		0x10
-#define NEC_EAGLE_PPT_ACK		0x08
-#define NEC_EAGLE_PPT_PE		0x04
-#define NEC_EAGLE_PPT_SELECT		0x02
-#define NEC_EAGLE_PPT_FAULT		0x01
-
-/*
- * LEDWR Register
- */
-#define NEC_EAGLE_LEDWR1		KSEG1ADDR(0x0DFFFFC0)
-#define NEC_EAGLE_LEDWR2		KSEG1ADDR(0x0DFFFFC4)
-
-/*
- * SDBINT Register
- */
-#define NEC_EAGLE_SDBINT		KSEG1ADDR(0x0DFFFFD0)
-#define NEC_EAGLE_SDBINT_PARINT		0x20
-#define NEC_EAGLE_SDBINT_SIO2INT	0x10
-#define NEC_EAGLE_SDBINT_SIO1INT	0x08
-#define NEC_EAGLE_SDBINT_ENUM		0x04
-#define NEC_EAGLE_SDBINT_DEG		0x02
-
-/*
- * SDB INTMSK Register
- */
-#define NEC_EAGLE_SDBINTMSK		KSEG1ADDR(0x0DFFFFD4)
-#define NEC_EAGLE_SDBINTMSK_MSKPAR	0x20
-#define NEC_EAGLE_SDBINTMSK_MSKSIO2	0x10
-#define NEC_EAGLE_SDBINTMSK_MSKSIO1	0x08
-#define NEC_EAGLE_SDBINTMSK_MSKENUM	0x04
-#define NEC_EAGLE_SDBINTMSK_MSKDEG	0x02
-
-/*
- * RSTREG Register
- */
-#define NEC_EAGLE_RSTREG		KSEG1ADDR(0x0DFFFFD8)
-#define NEC_EAGLE_RST_RSTSW		0x02
-#define NEC_EAGLE_RST_LEDOFF		0x01
-
-/*
- * PCI INT Rgister
- */
-#define NEC_EAGLE_PCIINTREG		KSEG1ADDR(0x0DFFFFDC)
-#define NEC_EAGLE_PCIINT_LANINT		0x10
-#define NEC_EAGLE_PCIINT_CP_INTD	0x08
-#define NEC_EAGLE_PCIINT_CP_INTC	0x04
-#define NEC_EAGLE_PCIINT_CP_INTB	0x02
-#define NEC_EAGLE_PCIINT_CP_INTA	0x01
-
-/*
- * PCI INT Mask Register
- */
-#define NEC_EAGLE_PCIINTMSKREG		KSEG1ADDR(0x0DFFFFE0)
-#define NEC_EAGLE_PCIINTMSK_MSKLANINT	0x10
-#define NEC_EAGLE_PCIINTMSK_MSKCP_INTD	0x08
-#define NEC_EAGLE_PCIINTMSK_MSKCP_INTC	0x04
-#define NEC_EAGLE_PCIINTMSK_MSKCP_INTB	0x02
-#define NEC_EAGLE_PCIINTMSK_MSKCP_INTA	0x01
-
-/*
- * CLK Division Register
- */
-#define NEC_EAGLE_CLKDIV		KSEG1ADDR(0x0DFFFFE4)
-#define NEC_EAGLE_CLKDIV_PCIDIV1	0x10
-#define NEC_EAGLE_CLKDIV_PCIDIV0	0x08
-#define NEC_EAGLE_CLKDIV_VTDIV2		0x04
-#define NEC_EAGLE_CLKDIV_VTDIV1		0x02
-#define NEC_EAGLE_CLKDIV_VTDIV0		0x01
-
-/*
- * Source Revision Register
- */
-#define NEC_EAGLE_REVISION		KSEG1ADDR(0x0DFFFFE8)
-
-#endif /* __NEC_EAGLE_H */

From maksik@gmx.co.uk Tue Jun 22 15:04:20 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 22 Jun 2004 15:04:24 +0100 (BST)
Received: from skl1.ukl.uni-freiburg.de ([IPv6:::ffff:193.196.199.1]:27559
	"EHLO relay1.uniklinik-freiburg.de") by linux-mips.org with ESMTP
	id <S8225457AbUFVOEU>; Tue, 22 Jun 2004 15:04:20 +0100
Received: from ktl77.ukl.uni-freiburg.de (ktl77.ukl.uni-freiburg.de [193.196.226.77])
	by relay1.uniklinik-freiburg.de (Email) with ESMTP id 03B2F2F4B7
	for <linux-mips@linux-mips.org>; Tue, 22 Jun 2004 16:04:15 +0200 (CEST)
From: Max Zaitsev <maksik@gmx.co.uk>
Organization: Mutella Dev co.
To: linux-mips <linux-mips@linux-mips.org>
Subject: booting SGI O2 from HD
Date: Tue, 22 Jun 2004 16:04:18 +0200
User-Agent: KMail/1.6.2
MIME-Version: 1.0
Content-Disposition: inline
Content-Type: text/plain;
  charset="us-ascii"
Content-Transfer-Encoding: 7bit
Message-Id: <200406221604.18306.maksik@gmx.co.uk>
Return-Path: <maksik@gmx.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: 5342
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: maksik@gmx.co.uk
Precedence: bulk
X-list: linux-mips

Hi!

Looks like it is not quite easy to make the o2 box to boot from the hard 
drive... I have tried both volume header solution (kernel crashes) and 
arcboot-0.3.8.1 (just prints some numbers and hangs without any further 
output, even without printing out the entry point). I've compiled arcboot 
with gcc-3.3.3 from the stage3 tarball available from kumba. Do I have to 
tweak some compile flags or do I need patches to arcboot? Or can somebody put 
out a working binary boot image per chance? 

Regards,
Max

From ralf@linux-mips.org Tue Jun 22 16:32:59 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 22 Jun 2004 16:33:03 +0100 (BST)
Received: from p508B7102.dip.t-dialin.net ([IPv6:::ffff:80.139.113.2]:42779
	"EHLO mail.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225489AbUFVPc7>; Tue, 22 Jun 2004 16:32:59 +0100
Received: from fluff.linux-mips.net (fluff.linux-mips.net [127.0.0.1])
	by mail.linux-mips.net (8.12.11/8.12.8) with ESMTP id i5MFWr6N006537;
	Tue, 22 Jun 2004 17:32:53 +0200
Received: (from ralf@localhost)
	by fluff.linux-mips.net (8.12.11/8.12.11/Submit) id i5MFWqhd006536;
	Tue, 22 Jun 2004 17:32:52 +0200
Date: Tue, 22 Jun 2004 17:32:52 +0200
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] vr41xx: remove Eagle support
Message-ID: <20040622153252.GA6504@linux-mips.org>
References: <20040622013322.0273fadb.yuasa@hh.iij4u.or.jp>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20040622013322.0273fadb.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: 5343
X-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, Jun 22, 2004 at 01:33:22AM +0900, Yoichi Yuasa wrote:

> NEC Eagle is obsolete hardware.
> We have Victor MP-C30x as similar hardware,
> I'm going to continue support of Victor MP-C30x and I decided to drop NEC Eagle.
> 
> Please apply this patch to v2.6 CVS tree.

Nobody who wants to raise a veto and take over maintenance?

  Ralf

From yuasa@hh.iij4u.or.jp Tue Jun 22 17:05:40 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 22 Jun 2004 17:05:45 +0100 (BST)
Received: from mo03.iij4u.or.jp ([IPv6:::ffff:210.130.0.20]:49911 "EHLO
	mo03.iij4u.or.jp") by linux-mips.org with ESMTP id <S8225479AbUFVQFk>;
	Tue, 22 Jun 2004 17:05:40 +0100
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 BAA21222;
	Wed, 23 Jun 2004 01:05:36 +0900 (JST)
Received: 4UMDO00 id i5MG5ZH24655; Wed, 23 Jun 2004 01:05:36 +0900 (JST)
Received: 4UMRO01 id i5MG5YO05449; Wed, 23 Jun 2004 01:05:34 +0900 (JST)
	from stratos (64.43.138.210.xn.2iij.net [210.138.43.64]) (authenticated)
Date: Wed, 23 Jun 2004 01:05:34 +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] vr41xx: remove Eagle support
Message-Id: <20040623010534.23c7ab45.yuasa@hh.iij4u.or.jp>
In-Reply-To: <20040622153252.GA6504@linux-mips.org>
References: <20040622013322.0273fadb.yuasa@hh.iij4u.or.jp>
	<20040622153252.GA6504@linux-mips.org>
X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; i386-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: 5344
X-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 Tue, 22 Jun 2004 17:32:52 +0200
Ralf Baechle <ralf@linux-mips.org> wrote:

> On Tue, Jun 22, 2004 at 01:33:22AM +0900, Yoichi Yuasa wrote:
> 
> > NEC Eagle is obsolete hardware.
> > We have Victor MP-C30x as similar hardware,
> > I'm going to continue support of Victor MP-C30x and I decided to drop NEC Eagle.
> > 
> > Please apply this patch to v2.6 CVS tree.
> 
> Nobody who wants to raise a veto and take over maintenance?

As far as I know, NEC Eagle was sold only in Japan.

Yoichi

From geert@linux-m68k.org Tue Jun 22 17:19:27 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 22 Jun 2004 17:19:33 +0100 (BST)
Received: from witte.sonytel.be ([IPv6:::ffff:80.88.33.193]:10701 "EHLO
	witte.sonytel.be") by linux-mips.org with ESMTP id <S8225479AbUFVQT1>;
	Tue, 22 Jun 2004 17:19:27 +0100
Received: from waterleaf.sonytel.be (localhost [127.0.0.1])
	by witte.sonytel.be (8.12.10/8.12.10) with ESMTP id i5MGJNXK005806;
	Tue, 22 Jun 2004 18:19:23 +0200 (MEST)
Date: Tue, 22 Jun 2004 18:19:23 +0200 (MEST)
From: Geert Uytterhoeven <geert@linux-m68k.org>
To: Yoichi Yuasa <yuasa@hh.iij4u.or.jp>
cc: Ralf Baechle <ralf@linux-mips.org>,
	Linux/MIPS Development <linux-mips@linux-mips.org>
Subject: Re: [PATCH] vr41xx: remove Eagle support
In-Reply-To: <20040623010534.23c7ab45.yuasa@hh.iij4u.or.jp>
Message-ID: <Pine.GSO.4.58.0406221818340.29076@waterleaf.sonytel.be>
References: <20040622013322.0273fadb.yuasa@hh.iij4u.or.jp>
 <20040622153252.GA6504@linux-mips.org> <20040623010534.23c7ab45.yuasa@hh.iij4u.or.jp>
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: 5345
X-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 Wed, 23 Jun 2004, Yoichi Yuasa wrote:
> On Tue, 22 Jun 2004 17:32:52 +0200
> Ralf Baechle <ralf@linux-mips.org> wrote:
> > On Tue, Jun 22, 2004 at 01:33:22AM +0900, Yoichi Yuasa wrote:
> > > NEC Eagle is obsolete hardware.
> > > We have Victor MP-C30x as similar hardware,
> > > I'm going to continue support of Victor MP-C30x and I decided to drop NEC Eagle.
> > >
> > > Please apply this patch to v2.6 CVS tree.
> >
> > Nobody who wants to raise a veto and take over maintenance?
>
> As far as I know, NEC Eagle was sold only in Japan.

Which doesn't mean all boards are currently located in Japan... (Yes, we have
one at work in Brussels ;-)

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 a.voropay@vmb-service.ru Tue Jun 22 17:23:22 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 22 Jun 2004 17:23:26 +0100 (BST)
Received: from smtp.vmb-service.ru ([IPv6:::ffff:80.73.198.33]:46477 "EHLO
	smtp.vmb-service.ru") by linux-mips.org with ESMTP
	id <S8225479AbUFVQXW>; Tue, 22 Jun 2004 17:23:22 +0100
Received: from office.vmb-service.ru ([80.73.192.47]:44045 "EHLO ALEC")
	by Altair with ESMTP id <S1166865AbUFVQXN>;
	Tue, 22 Jun 2004 20:23:13 +0400
Reply-To: <a.voropay@vmb-service.ru>
From: "Alexander Voropay" <a.voropay@vmb-service.ru>
To: <linux-mips@linux-mips.org>
Subject: Howto run Linux on ACER PICA 61
Date: Tue, 22 Jun 2004 20:23:57 +0400
Organization: VMB-Service
Message-ID: <01d701c45875$5205b460$0200000a@ALEC>
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.4024
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4927.1200
Return-Path: <a.voropay@vmb-service.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: 5346
X-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.voropay@vmb-service.ru
Precedence: bulk
X-list: linux-mips

Hi!

 I've just got (for free :) an ancient MIPS ACER PICA 61 motherboard.

 Can anyone help/guide me to run Linux-MIPS on this machine ?
Is it still possible to run Linux on this architecture ?

 The motherboard is old (~1993) and it is very difficult to find
any documentations... AFAIK, this is version of ARC MIPS.
(mipsel)


 This is Full-size AT board, AT power supply, 5 ISA slots, 8 SIMM
slots. The CPU is PACEMIPS R4000-50Mhz (x2=100 internal ???) by
Performance Semiconductor Corp.. NatSemi Ethernet/AUI onboard.
No IDE connector. One additional slot is not ISA, but maked as
IO an contains SCSI/Floppy/Serial/Perallel/Mice card. Another slot
is like reversed EISA (double) and marked as VIO (locabus video?).
Unfortunately, the original videocard is lost. :( However it works fine
with old CirrusLogic VGA card in ISA slot (old ISA Trident 8900/9000
does not works).




St.Petersburg, Russia
--
-=AV=- 


From ralf@linux-mips.org Tue Jun 22 17:32:40 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 22 Jun 2004 17:32:44 +0100 (BST)
Received: from p508B7102.dip.t-dialin.net ([IPv6:::ffff:80.139.113.2]:35612
	"EHLO mail.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225479AbUFVQck>; Tue, 22 Jun 2004 17:32:40 +0100
Received: from fluff.linux-mips.net (fluff.linux-mips.net [127.0.0.1])
	by mail.linux-mips.net (8.12.11/8.12.8) with ESMTP id i5MGWYQx007898;
	Tue, 22 Jun 2004 18:32:34 +0200
Received: (from ralf@localhost)
	by fluff.linux-mips.net (8.12.11/8.12.11/Submit) id i5MGWV5x007894;
	Tue, 22 Jun 2004 18:32:31 +0200
Date: Tue, 22 Jun 2004 18:32:31 +0200
From: Ralf Baechle <ralf@linux-mips.org>
To: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Yoichi Yuasa <yuasa@hh.iij4u.or.jp>,
	Linux/MIPS Development <linux-mips@linux-mips.org>
Subject: Re: [PATCH] vr41xx: remove Eagle support
Message-ID: <20040622163231.GA7387@linux-mips.org>
References: <20040622013322.0273fadb.yuasa@hh.iij4u.or.jp> <20040622153252.GA6504@linux-mips.org> <20040623010534.23c7ab45.yuasa@hh.iij4u.or.jp> <Pine.GSO.4.58.0406221818340.29076@waterleaf.sonytel.be>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Pine.GSO.4.58.0406221818340.29076@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: 5347
X-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, Jun 22, 2004 at 06:19:23PM +0200, Geert Uytterhoeven wrote:

> Which doesn't mean all boards are currently located in Japan... (Yes, we have
> one at work in Brussels ;-)

<salespitch>

I see, we have a volunteer :-)

</salespitch>

  Ralf

From geert@linux-m68k.org Tue Jun 22 19:07:30 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 22 Jun 2004 19:07:34 +0100 (BST)
Received: from witte.sonytel.be ([IPv6:::ffff:80.88.33.193]:1949 "EHLO
	witte.sonytel.be") by linux-mips.org with ESMTP id <S8225489AbUFVSH3>;
	Tue, 22 Jun 2004 19:07:29 +0100
Received: from waterleaf.sonytel.be (localhost [127.0.0.1])
	by witte.sonytel.be (8.12.10/8.12.10) with ESMTP id i5MI7PXK015584;
	Tue, 22 Jun 2004 20:07:26 +0200 (MEST)
Date: Tue, 22 Jun 2004 20:07:25 +0200 (MEST)
From: Geert Uytterhoeven <geert@linux-m68k.org>
To: Ralf Baechle <ralf@linux-mips.org>
cc: Yoichi Yuasa <yuasa@hh.iij4u.or.jp>,
	Linux/MIPS Development <linux-mips@linux-mips.org>
Subject: Re: [PATCH] vr41xx: remove Eagle support
In-Reply-To: <20040622163231.GA7387@linux-mips.org>
Message-ID: <Pine.GSO.4.58.0406222007050.29076@waterleaf.sonytel.be>
References: <20040622013322.0273fadb.yuasa@hh.iij4u.or.jp>
 <20040622153252.GA6504@linux-mips.org> <20040623010534.23c7ab45.yuasa@hh.iij4u.or.jp>
 <Pine.GSO.4.58.0406221818340.29076@waterleaf.sonytel.be>
 <20040622163231.GA7387@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: 5348
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: geert@linux-m68k.org
Precedence: bulk
X-list: linux-mips

On Tue, 22 Jun 2004, Ralf Baechle wrote:
> On Tue, Jun 22, 2004 at 06:19:23PM +0200, Geert Uytterhoeven wrote:
> > Which doesn't mean all boards are currently located in Japan... (Yes, we have
> > one at work in Brussels ;-)
>
> <salespitch>
>
> I see, we have a volunteer :-)
>
> </salespitch>

But I have to admit we never tried to run Linux on it...

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 ralf@linux-mips.org Tue Jun 22 20:38:40 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 22 Jun 2004 20:38:45 +0100 (BST)
Received: from p508B7102.dip.t-dialin.net ([IPv6:::ffff:80.139.113.2]:48926
	"EHLO mail.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225624AbUFVTik>; Tue, 22 Jun 2004 20:38:40 +0100
Received: from fluff.linux-mips.net (fluff.linux-mips.net [127.0.0.1])
	by mail.linux-mips.net (8.12.11/8.12.8) with ESMTP id i5MJcdlS011804;
	Tue, 22 Jun 2004 21:38:39 +0200
Received: (from ralf@localhost)
	by fluff.linux-mips.net (8.12.11/8.12.11/Submit) id i5MJcdDD011803;
	Tue, 22 Jun 2004 21:38:39 +0200
Date: Tue, 22 Jun 2004 21:38:39 +0200
From: Ralf Baechle <ralf@linux-mips.org>
To: Alexander Voropay <a.voropay@vmb-service.ru>
Cc: linux-mips@linux-mips.org
Subject: Re: Howto run Linux on ACER PICA 61
Message-ID: <20040622193839.GA7082@linux-mips.org>
References: <01d701c45875$5205b460$0200000a@ALEC>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <01d701c45875$5205b460$0200000a@ALEC>
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: 5349
X-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, Jun 22, 2004 at 08:23:57PM +0400, Alexander Voropay wrote:

>  I've just got (for free :) an ancient MIPS ACER PICA 61 motherboard.
> 
>  Can anyone help/guide me to run Linux-MIPS on this machine ?
> Is it still possible to run Linux on this architecture ?
> 
>  The motherboard is old (~1993) and it is very difficult to find
> any documentations... AFAIK, this is version of ARC MIPS.
> (mipsel)
> 
> 
>  This is Full-size AT board, AT power supply, 5 ISA slots, 8 SIMM
> slots. The CPU is PACEMIPS R4000-50Mhz (x2=100 internal ???) by
> Performance Semiconductor Corp.. NatSemi Ethernet/AUI onboard.
> No IDE connector. One additional slot is not ISA, but maked as
> IO an contains SCSI/Floppy/Serial/Perallel/Mice card. Another slot
> is like reversed EISA (double) and marked as VIO (locabus video?).
> Unfortunately, the original videocard is lost. :(

Great.  Because that was a S3 968 video card which for it's time was
delivering quite a nice performance.

> However it works fine with old CirrusLogic VGA card in ISA slot (old
> ISA Trident 8900/9000 does not works).

Linux has code for this system but it's suffering from severe bitrot.
I still have the documents here so I could help you a bit if you were
willing to resurrect the kernel - which should be relativly easy, also
due to the system's similarity to another, somewhat better supported
system, the Olivetti M700-10.

  Ralf

From macro@ds2.pg.gda.pl Tue Jun 22 22:30:55 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 22 Jun 2004 22:31:00 +0100 (BST)
Received: from jurand.ds.pg.gda.pl ([IPv6:::ffff:153.19.208.2]:13731 "EHLO
	jurand.ds.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8225720AbUFVVaz>; Tue, 22 Jun 2004 22:30:55 +0100
Received: by jurand.ds.pg.gda.pl (Postfix, from userid 1011)
	id 7C4E647831; Tue, 22 Jun 2004 23:30:48 +0200 (CEST)
Received: from localhost (localhost [127.0.0.1])
	by jurand.ds.pg.gda.pl (Postfix) with ESMTP
	id 631AB4762E; Tue, 22 Jun 2004 23:30:48 +0200 (CEST)
Date: Tue, 22 Jun 2004 23:30:48 +0200 (CEST)
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To: cgd@broadcom.com
Cc: David Daney <ddaney@avtrex.com>,
	Ralf Baechle <ralf@linux-mips.org>, linux-mips@linux-mips.org,
	binutils@sources.redhat.com
Subject: Re: [Patch]  / 0 should send SIGFPE not SIGTRAP...
In-Reply-To: <yov57juduc7q.fsf@ldt-sj3-010.sj.broadcom.com>
Message-ID: <Pine.LNX.4.55.0406222304340.23178@jurand.ds.pg.gda.pl>
References: <40C9F5A4.2050606@avtrex.com> <40C9F5FE.8030607@avtrex.com>
 <40C9F7F0.50501@avtrex.com> <Pine.LNX.4.55.0406112039040.13062@jurand.ds.pg.gda.pl>
 <mailpost.1086981251.16853@news-sj1-1> <yov57juduc7q.fsf@ldt-sj3-010.sj.broadcom.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: 5350
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: macro@ds2.pg.gda.pl
Precedence: bulk
X-list: linux-mips

On Fri, 11 Jun 2004 cgd@broadcom.com wrote:

> in retrospect, the 'B' variation probably wasn't the greatest idea.
> 
> If it were removed (leaving 'c' and 'c','q' variations), I don't know
> that any real harm would occur.
> 
> It may be very confusing to people who expect that the break code will
> translate into the instruction in an obvious way, and obviously it
> would mess up use of 20-bit codes, but i don't know how prevalent that
> is.
> 
> Unfortunately, at this point, Linux should probably accept the
> divide-by-zero code in both locations.
> 
> 
> (Really, from day one, assemblers probably should have accepted a
> 20-bit code.  I just checked my copy of the Kane r2000/r3000 book, and
> it was 20-bit all the way back then.  If i had to guess, i'd guess
> that gas was copying a non-gnu assembler's behaviour.  In any case,
> water under the bridge.)

 As it's at least annoying to have different break codes for divisions 
expanded by gcc explicitly and ones created implicitly by gas, here's the 
most reasonable (IMO) approach to fix that.  I think it should have been 
implemented this way originally (if at all).

gas/testsuite/:
2004-06-22  Maciej W. Rozycki  <macro@ds2.pg.gda.pl>

	* gas/mips/break20.s: Test the "break20" alias.
	* gas/mips/break20.d: Results for the test.
	* gas/mips/mips32.s: Replace "break" with "break20".
	* gas/mips/set-arch.s: Likewise.
	* gas/mips/mips32.d: Adjust for the new output.
	* gas/mips/set-arch.d: Likewise.

opcodes/:
2004-06-22  Maciej W. Rozycki  <macro@ds2.pg.gda.pl>

	* mips-opc.c (mips_builtin_opcodes): Replace the MIPS32 ISA 
	specific "break" encoding with a "break20" alias accepted for any 
	ISA.

 I decided to give a precedence to "break x,y" over "break20 z" to avoid 
perhaps a bit surprising output in `objdump'.

 The question is: does anyone know of possible troubles with this change?  
Chances are someone depends on the current semantics for
-march=mips32/mips64, but that's fragile anyway as building with a
different setting results in different code.

 Or should we get rid of the 20-bit "break" completely?  The two-argument
version provides the same functionality, although the 10-bit codes to be
used do not map to the 20-bit equivalent "optically" very well.  
Especially if decimal notation is used.

 Note the same problem appears to be the case with "sdbbp".  It could be
handled similarly, but given the limited use of "sdbbp" for
non-MIPS32/MIPS64 ISAs it may not be worth the hassle.  I see no problem
writing a similar fix if desired, though.

  Maciej

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

binutils-2.15.91-20040615-mips-break20.patch
diff -up --recursive --new-file binutils-2.15.91-20040615.macro/gas/testsuite/gas/mips/break20.d binutils-2.15.91-20040615/gas/testsuite/gas/mips/break20.d
--- binutils-2.15.91-20040615.macro/gas/testsuite/gas/mips/break20.d	2003-05-08 03:25:31.000000000 +0000
+++ binutils-2.15.91-20040615/gas/testsuite/gas/mips/break20.d	2004-06-17 21:03:30.000000000 +0000
@@ -10,9 +10,13 @@ Disassembly of section .text:
 0+0008 <[^>]*> break	0x14
 0+000c <[^>]*> break	0x14,0x28
 0+0010 <[^>]*> break	0x3ff,0x3ff
-0+0014 <[^>]*> sdbbp
-0+0018 <[^>]*> sdbbp
-0+001c <[^>]*> sdbbp	0x14
-0+0020 <[^>]*> sdbbp	0x14,0x28
-0+0024 <[^>]*> sdbbp	0x3ff,0x3ff
+0+0014 <[^>]*> break
+0+0018 <[^>]*> break	0x0,0x14
+0+001c <[^>]*> break	0x14,0x28
+0+0020 <[^>]*> break	0x3ff,0x3ff
+0+0024 <[^>]*> sdbbp
+0+0028 <[^>]*> sdbbp
+0+002c <[^>]*> sdbbp	0x14
+0+0030 <[^>]*> sdbbp	0x14,0x28
+0+0034 <[^>]*> sdbbp	0x3ff,0x3ff
 	...
diff -up --recursive --new-file binutils-2.15.91-20040615.macro/gas/testsuite/gas/mips/break20.s binutils-2.15.91-20040615/gas/testsuite/gas/mips/break20.s
--- binutils-2.15.91-20040615.macro/gas/testsuite/gas/mips/break20.s	1999-08-10 14:24:45.000000000 +0000
+++ binutils-2.15.91-20040615/gas/testsuite/gas/mips/break20.s	2004-06-17 19:57:51.000000000 +0000
@@ -6,6 +6,11 @@ foo:	
 	break	20,40
 	break	1023,1023
 	
+	break20	0
+	break20	20
+	break20	20520
+	break20	1048575
+
 	sdbbp
 	sdbbp	0
 	sdbbp	20
diff -up --recursive --new-file binutils-2.15.91-20040615.macro/gas/testsuite/gas/mips/mips32.d binutils-2.15.91-20040615/gas/testsuite/gas/mips/mips32.d
--- binutils-2.15.91-20040615.macro/gas/testsuite/gas/mips/mips32.d	2003-05-08 03:25:35.000000000 +0000
+++ binutils-2.15.91-20040615/gas/testsuite/gas/mips/mips32.d	2004-06-17 21:15:04.000000000 +0000
@@ -48,7 +48,7 @@ Disassembly of section .text:
 0+0098 <[^>]*> 4359e260 	wait	0x56789
 0+009c <[^>]*> 0000000d 	break
 0+00a0 <[^>]*> 0000000d 	break
-0+00a4 <[^>]*> 0048d14d 	break	0x12345
+0+00a4 <[^>]*> 0048d14d 	break	0x48,0x345
 0+00a8 <[^>]*> 7000003f 	sdbbp
 0+00ac <[^>]*> 7000003f 	sdbbp
 0+00b0 <[^>]*> 7159e27f 	sdbbp	0x56789
diff -up --recursive --new-file binutils-2.15.91-20040615.macro/gas/testsuite/gas/mips/mips32.s binutils-2.15.91-20040615/gas/testsuite/gas/mips/mips32.s
--- binutils-2.15.91-20040615.macro/gas/testsuite/gas/mips/mips32.s	2002-09-05 03:25:40.000000000 +0000
+++ binutils-2.15.91-20040615/gas/testsuite/gas/mips/mips32.s	2004-06-17 21:13:22.000000000 +0000
@@ -62,7 +62,7 @@ text_label:
       # different.
       break
       break   0                       # disassembles without code
-      break   0x12345
+      break20 0x12345
       sdbbp
       sdbbp   0                       # disassembles without code
       sdbbp   0x56789
diff -up --recursive --new-file binutils-2.15.91-20040615.macro/gas/testsuite/gas/mips/set-arch.d binutils-2.15.91-20040615/gas/testsuite/gas/mips/set-arch.d
--- binutils-2.15.91-20040615.macro/gas/testsuite/gas/mips/set-arch.d	2003-10-01 03:25:36.000000000 +0000
+++ binutils-2.15.91-20040615/gas/testsuite/gas/mips/set-arch.d	2004-06-17 21:17:46.000000000 +0000
@@ -160,7 +160,7 @@ Disassembly of section \.text:
 00000260 <[^>]*> 4359e260 	wait	0x56789
 00000264 <[^>]*> 0000000d 	break
 00000268 <[^>]*> 0000000d 	break
-0000026c <[^>]*> 0048d14d 	break	0x12345
+0000026c <[^>]*> 0048d14d 	break	0x48,0x345
 00000270 <[^>]*> 7000003f 	sdbbp
 00000274 <[^>]*> 7000003f 	sdbbp
 00000278 <[^>]*> 7159e27f 	sdbbp	0x56789
diff -up --recursive --new-file binutils-2.15.91-20040615.macro/gas/testsuite/gas/mips/set-arch.s binutils-2.15.91-20040615/gas/testsuite/gas/mips/set-arch.s
--- binutils-2.15.91-20040615.macro/gas/testsuite/gas/mips/set-arch.s	2003-06-29 19:41:33.000000000 +0000
+++ binutils-2.15.91-20040615/gas/testsuite/gas/mips/set-arch.s	2004-06-17 21:18:01.000000000 +0000
@@ -204,7 +204,7 @@ text_label:	
 	# different.
 	break
 	break   0                       # disassembles without code
-	break   0x12345
+	break20 0x12345
 	sdbbp
 	sdbbp   0                       # disassembles without code
 	sdbbp   0x56789
diff -up --recursive --new-file binutils-2.15.91-20040615.macro/opcodes/mips-opc.c binutils-2.15.91-20040615/opcodes/mips-opc.c
--- binutils-2.15.91-20040615.macro/opcodes/mips-opc.c	2003-11-19 04:25:23.000000000 +0000
+++ binutils-2.15.91-20040615/opcodes/mips-opc.c	2004-06-17 19:46:23.000000000 +0000
@@ -274,9 +274,9 @@ const struct mips_opcode mips_builtin_op
 {"bnel",    "s,t,p",	0x54000000, 0xfc000000,	CBL|RD_s|RD_t, 		I2|T3	},
 {"bnel",    "s,I,p",	0,    (int) M_BNEL_I,	INSN_MACRO,		I2|T3	},
 {"break",   "",		0x0000000d, 0xffffffff,	TRAP,			I1	},
-{"break",   "B",        0x0000000d, 0xfc00003f, TRAP,           	I32     },
 {"break",   "c",	0x0000000d, 0xfc00ffff,	TRAP,			I1	},
 {"break",   "c,q",	0x0000000d, 0xfc00003f,	TRAP,			I1	},
+{"break20", "B",        0x0000000d, 0xfc00003f, TRAP,           	I1      },
 {"c.f.d",   "S,T",	0x46200030, 0xffe007ff,	RD_S|RD_T|WR_CC|FP_D,	I1	},
 {"c.f.d",   "M,S,T",    0x46200030, 0xffe000ff, RD_S|RD_T|WR_CC|FP_D,   I4|I32	},
 {"c.f.s",   "S,T",      0x46000030, 0xffe007ff, RD_S|RD_T|WR_CC|FP_S,   I1      },

From sjhill@realitydiluted.com Wed Jun 23 04:28:39 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 23 Jun 2004 04:28:51 +0100 (BST)
Received: from eth13.com-link.com ([IPv6:::ffff:208.242.241.164]:48564 "EHLO
	real.realitydiluted.com") by linux-mips.org with ESMTP
	id <S8224772AbUFWD2j>; Wed, 23 Jun 2004 04:28:39 +0100
Received: from localhost ([127.0.0.1] helo=realitydiluted.com)
	by real.realitydiluted.com with esmtp (Exim 3.36 #1 (Debian))
	id 1BcyRB-0007Ec-00
	for <linux-mips@linux-mips.org>; Tue, 22 Jun 2004 22:28:37 -0500
Message-ID: <40D8F950.2050308@realitydiluted.com>
Date: Tue, 22 Jun 2004 22:30:24 -0500
From: "Steven J. Hill" <sjhill@realitydiluted.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040528 Debian/1.6-7
X-Accept-Language: en
MIME-Version: 1.0
To: linux-mips@linux-mips.org
Subject: MIPS assembly document...
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: 5351
X-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

Hey guys.

Is there a nice little pocket MIPS assembly reference card
with R3000 and/or R4000 instructions on it? I know the ARM
architecture has something like this, but I have never seen
(or I missed) anything on MIPS or SGI ftp sites anywhere.
Anything?

-Steve

From ralf@linux-mips.org Wed Jun 23 10:59:18 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 23 Jun 2004 10:59:22 +0100 (BST)
Received: from p508B70C5.dip.t-dialin.net ([IPv6:::ffff:80.139.112.197]:21800
	"EHLO mail.linux-mips.net") by linux-mips.org with ESMTP
	id <S8224954AbUFWJ7S>; Wed, 23 Jun 2004 10:59:18 +0100
Received: from fluff.linux-mips.net (fluff.linux-mips.net [127.0.0.1])
	by mail.linux-mips.net (8.12.11/8.12.8) with ESMTP id i5N9xGkL014474;
	Wed, 23 Jun 2004 11:59:16 +0200
Received: (from ralf@localhost)
	by fluff.linux-mips.net (8.12.11/8.12.11/Submit) id i5N9xFac014473;
	Wed, 23 Jun 2004 11:59:15 +0200
Date: Wed, 23 Jun 2004 11:59:15 +0200
From: Ralf Baechle <ralf@linux-mips.org>
To: "Steven J. Hill" <sjhill@realitydiluted.com>
Cc: linux-mips@linux-mips.org
Subject: Re: MIPS assembly document...
Message-ID: <20040623095915.GA13999@linux-mips.org>
References: <40D8F950.2050308@realitydiluted.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <40D8F950.2050308@realitydiluted.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: 5352
X-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, Jun 22, 2004 at 10:30:24PM -0500, Steven J. Hill wrote:

> Is there a nice little pocket MIPS assembly reference card
> with R3000 and/or R4000 instructions on it? I know the ARM
> architecture has something like this, but I have never seen
> (or I missed) anything on MIPS or SGI ftp sites anywhere.
> Anything?

See MIPS Run has a pretty complete listing of all instructions of even
the most exotic MIPS variants but I guess that's a little to long to
qualify as pocket reference.

  Ralf

From a.voropay@vmb-service.ru Wed Jun 23 11:00:13 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 23 Jun 2004 11:00:17 +0100 (BST)
Received: from smtp.vmb-service.ru ([IPv6:::ffff:80.73.198.33]:50112 "EHLO
	smtp.vmb-service.ru") by linux-mips.org with ESMTP
	id <S8224954AbUFWKAN>; Wed, 23 Jun 2004 11:00:13 +0100
Received: from office.vmb-service.ru ([80.73.192.47]:16145 "EHLO ALEC")
	by Altair with ESMTP id <S1166518AbUFWJ75>;
	Wed, 23 Jun 2004 13:59:57 +0400
Reply-To: <a.voropay@vmb-service.ru>
From: "Alexander Voropay" <a.voropay@vmb-service.ru>
To: "'Steven J. Hill'" <sjhill@realitydiluted.com>,
	<linux-mips@linux-mips.org>
Subject: RE: MIPS assembly document...
Date: Wed, 23 Jun 2004 14:00:42 +0400
Organization: VMB-Service
Message-ID: <024c01c45908$f2008fb0$0200000a@ALEC>
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.4024
In-Reply-To: <40D8F950.2050308@realitydiluted.com>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4927.1200
Return-Path: <a.voropay@vmb-service.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: 5353
X-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.voropay@vmb-service.ru
Precedence: bulk
X-list: linux-mips

Steven J. Hill wrote:

>Is there a nice little pocket MIPS assembly reference card
>with R3000 and/or R4000 instructions on it?

 The MIPS instructions is very simply, so it is possible
to tead it in hex without reference card ;-)

* IDT Assembler Software Reference Guide Vol. 2
3. CPU Instruction Reference
4. CPU Instructions Encoding
http://www1.idt.com/pcms/documents.taf?catID=121&docTypeID=25&mode=byTit
le
http://www1.idt.com/pcms/tempDocs/79RC32355_MA_92629.pdf

P.S. See:
http://chortle.ccsu.edu/AssemblyTutorial/tutorialContents.html
http://myrkraverk.afraid.org/PlayStation/EmotionEngine/

--
-=AV=-


From ddaney@avtrex.com Wed Jun 23 20:33:02 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 23 Jun 2004 20:33:07 +0100 (BST)
Received: from avtrex.com ([IPv6:::ffff:216.102.217.178]:52424 "EHLO
	avtrex.com") by linux-mips.org with ESMTP id <S8225716AbUFWTdC>;
	Wed, 23 Jun 2004 20:33:02 +0100
Received: from avtrex.com ([192.168.0.111] RDNS failed) by avtrex.com with Microsoft SMTPSVC(5.0.2195.6713);
	 Wed, 23 Jun 2004 12:32:26 -0700
Message-ID: <40D9DA3E.3040107@avtrex.com>
Date: Wed, 23 Jun 2004 12:30:06 -0700
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: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
CC: cgd@broadcom.com, Ralf Baechle <ralf@linux-mips.org>,
	linux-mips@linux-mips.org, binutils@sources.redhat.com
Subject: Re: [Patch]  / 0 should send SIGFPE not SIGTRAP...
References: <40C9F5A4.2050606@avtrex.com> <40C9F5FE.8030607@avtrex.com> <40C9F7F0.50501@avtrex.com> <Pine.LNX.4.55.0406112039040.13062@jurand.ds.pg.gda.pl> <mailpost.1086981251.16853@news-sj1-1> <yov57juduc7q.fsf@ldt-sj3-010.sj.broadcom.com> <Pine.LNX.4.55.0406222304340.23178@jurand.ds.pg.gda.pl>
In-Reply-To: <Pine.LNX.4.55.0406222304340.23178@jurand.ds.pg.gda.pl>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 23 Jun 2004 19:32:26.0681 (UTC) FILETIME=[D0B62A90:01C45958]
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: 5354
X-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

Maciej W. Rozycki wrote:

>On Fri, 11 Jun 2004 cgd@broadcom.com wrote:
>
>  
>
>>in retrospect, the 'B' variation probably wasn't the greatest idea.
>>
>>If it were removed (leaving 'c' and 'c','q' variations), I don't know
>>that any real harm would occur.
>>
>>It may be very confusing to people who expect that the break code will
>>translate into the instruction in an obvious way, and obviously it
>>would mess up use of 20-bit codes, but i don't know how prevalent that
>>is.
>>
>>Unfortunately, at this point, Linux should probably accept the
>>divide-by-zero code in both locations.
>>
>>
>>(Really, from day one, assemblers probably should have accepted a
>>20-bit code.  I just checked my copy of the Kane r2000/r3000 book, and
>>it was 20-bit all the way back then.  If i had to guess, i'd guess
>>that gas was copying a non-gnu assembler's behaviour.  In any case,
>>water under the bridge.)
>>    
>>
>
> As it's at least annoying to have different break codes for divisions 
>expanded by gcc explicitly and ones created implicitly by gas, here's the 
>most reasonable (IMO) approach to fix that.  I think it should have been 
>implemented this way originally (if at all).
>
>gas/testsuite/:
>2004-06-22  Maciej W. Rozycki  <macro@ds2.pg.gda.pl>
>
>	* gas/mips/break20.s: Test the "break20" alias.
>	* gas/mips/break20.d: Results for the test.
>	* gas/mips/mips32.s: Replace "break" with "break20".
>	* gas/mips/set-arch.s: Likewise.
>	* gas/mips/mips32.d: Adjust for the new output.
>	* gas/mips/set-arch.d: Likewise.
>
>opcodes/:
>2004-06-22  Maciej W. Rozycki  <macro@ds2.pg.gda.pl>
>
>	* mips-opc.c (mips_builtin_opcodes): Replace the MIPS32 ISA 
>	specific "break" encoding with a "break20" alias accepted for any 
>	ISA.
>
>  
>
.
.
.
Just out of curiosity, do you propose this patch in lieu of the patch to 
Linux's traps.c?

Or would you do both?

It seems like both would be best, as there are already "broken" binutils 
floating around out there.

Also nobody has objected to the kernel patch...

David Daney.




From macro@ds2.pg.gda.pl Wed Jun 23 20:38:41 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 23 Jun 2004 20:38:45 +0100 (BST)
Received: from jurand.ds.pg.gda.pl ([IPv6:::ffff:153.19.208.2]:37089 "EHLO
	jurand.ds.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8225743AbUFWTil>; Wed, 23 Jun 2004 20:38:41 +0100
Received: by jurand.ds.pg.gda.pl (Postfix, from userid 1011)
	id D3536474C5; Wed, 23 Jun 2004 21:38:32 +0200 (CEST)
Received: from localhost (localhost [127.0.0.1])
	by jurand.ds.pg.gda.pl (Postfix) with ESMTP
	id C78C044CD0; Wed, 23 Jun 2004 21:38:32 +0200 (CEST)
Date: Wed, 23 Jun 2004 21:38:32 +0200 (CEST)
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To: David Daney <ddaney@avtrex.com>
Cc: cgd@broadcom.com, Ralf Baechle <ralf@linux-mips.org>,
	linux-mips@linux-mips.org, binutils@sources.redhat.com
Subject: Re: [Patch]  / 0 should send SIGFPE not SIGTRAP...
In-Reply-To: <40D9DA3E.3040107@avtrex.com>
Message-ID: <Pine.LNX.4.55.0406232136580.11815@jurand.ds.pg.gda.pl>
References: <40C9F5A4.2050606@avtrex.com> <40C9F5FE.8030607@avtrex.com>
 <40C9F7F0.50501@avtrex.com> <Pine.LNX.4.55.0406112039040.13062@jurand.ds.pg.gda.pl>
 <mailpost.1086981251.16853@news-sj1-1> <yov57juduc7q.fsf@ldt-sj3-010.sj.broadcom.com>
 <Pine.LNX.4.55.0406222304340.23178@jurand.ds.pg.gda.pl> <40D9DA3E.3040107@avtrex.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: 5355
X-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, 23 Jun 2004, David Daney wrote:

> Just out of curiosity, do you propose this patch in lieu of the patch to 
> Linux's traps.c?
> 
> Or would you do both?

 Both.

> It seems like both would be best, as there are already "broken" binutils 
> floating around out there.

 And broken binaries.

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

From rsandifo@redhat.com Thu Jun 24 11:40:11 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 24 Jun 2004 11:40:16 +0100 (BST)
Received: from mx1.redhat.com ([IPv6:::ffff:66.187.233.31]:15059 "EHLO
	mx1.redhat.com") by linux-mips.org with ESMTP id <S8225722AbUFXKkL>;
	Thu, 24 Jun 2004 11:40:11 +0100
Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254])
	by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i5OAdje1019773;
	Thu, 24 Jun 2004 06:39:45 -0400
Received: from localhost (mail@vpn50-12.rdu.redhat.com [172.16.50.12])
	by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i5OAdh020462;
	Thu, 24 Jun 2004 06:39:43 -0400
Received: from rsandifo by localhost with local (Exim 3.35 #1)
	id 1BdRdu-0002UQ-00; Thu, 24 Jun 2004 11:39:42 +0100
To: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
Cc: cgd@broadcom.com, David Daney <ddaney@avtrex.com>,
	Ralf Baechle <ralf@linux-mips.org>, linux-mips@linux-mips.org,
	binutils@sources.redhat.com
Subject: Re: [Patch]  / 0 should send SIGFPE not SIGTRAP...
References: <40C9F5A4.2050606@avtrex.com> <40C9F5FE.8030607@avtrex.com>
	<40C9F7F0.50501@avtrex.com>
	<Pine.LNX.4.55.0406112039040.13062@jurand.ds.pg.gda.pl>
	<mailpost.1086981251.16853@news-sj1-1>
	<yov57juduc7q.fsf@ldt-sj3-010.sj.broadcom.com>
	<Pine.LNX.4.55.0406222304340.23178@jurand.ds.pg.gda.pl>
From: Richard Sandiford <rsandifo@redhat.com>
Date: Thu, 24 Jun 2004 11:39:42 +0100
In-Reply-To: <Pine.LNX.4.55.0406222304340.23178@jurand.ds.pg.gda.pl> (Maciej
 W. Rozycki's message of "Tue, 22 Jun 2004 23:30:48 +0200 (CEST)")
Message-ID: <87y8mdgryp.fsf@redhat.com>
User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Return-Path: <rsandifo@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: 5356
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: rsandifo@redhat.com
Precedence: bulk
X-list: linux-mips

"Maciej W. Rozycki" <macro@ds2.pg.gda.pl> writes:
>  Or should we get rid of the 20-bit "break" completely?  The two-argument
> version provides the same functionality, although the 10-bit codes to be
> used do not map to the 20-bit equivalent "optically" very well.  
> Especially if decimal notation is used.

I notice no-one's really responded to this question yet.  FWIW, on gut
instinct, I'd personally prefer to drop the 20-bit break than introduce
a new, non-standard name for it.

Just an opinion though.  I won't argue against anyone saying different. ;)

Richard

From ypresente@mrv.com Thu Jun 24 13:42:07 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 24 Jun 2004 13:42:11 +0100 (BST)
Received: from apollo.nbase.co.il ([IPv6:::ffff:194.90.137.2]:36626 "EHLO
	apollo.nbase.co.il") by linux-mips.org with ESMTP
	id <S8225763AbUFXMmH>; Thu, 24 Jun 2004 13:42:07 +0100
Received: from mrv.com ([194.90.136.133]) by apollo.nbase.co.il
          (Post.Office MTA v3.1.2 release (PO205-101c)
          ID# 0-44418U200L2S100) with ESMTP id AAA1464
          for <linux-mips@linux-mips.org>; Thu, 24 Jun 2004 15:50:03 +0200
Message-ID: <40DACD33.60801@mrv.com>
Date: Thu, 24 Jun 2004 15:46:43 +0300
From: ypresente@mrv.com (Yaron Presente)
Organization: MRV International
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01
X-Accept-Language: en-us, en, he
MIME-Version: 1.0
To: linux-mips@linux-mips.org
Subject: non-contiguous physical memory
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Return-Path: <ypresente@mrv.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: 5357
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ypresente@mrv.com
Precedence: bulk
X-list: linux-mips

Hi all,
I'm running montavista linux (2.4.18_mvl30-malta-mips_fp_le) on a board 
that has 2 memory banks of physical memory.
1. 32MB from physical address 0x00000000
2. 16MB from physical address 0x20000000

Currently I can only access the first bank (by add_memory_region(0, 32 
<< 20, BOOT_MEM_RAM) in prom_init() ).
I tried the obvious solution of adding another region at 0x20000000 
(add_memory_region(0x20000000, 16 << 20, BOOT_MEM_RAM))
but that didn't seem to work. I've also tried to add a BOOT_MEM_RESERVED 
region in between the regions in order to create a seemingly contiguous 
memory, with no success.
My questions are:
Is it possible to access the second bank as well under MIPS ?
Is there a way to define a "hole" in the physical memory?
Do I have to use CONFIG_DISCONTIGMEM ? is it fully supported ?
Thanks for your help,

-- 
Yaron Presente
MRV International
Direct   : 972-4-9936237
Fax      : 972-4-9890564
Email   : ypresente@mrv.com
www.mrv.com





From macro@ds2.pg.gda.pl Thu Jun 24 19:34:51 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 24 Jun 2004 19:34:55 +0100 (BST)
Received: from jurand.ds.pg.gda.pl ([IPv6:::ffff:153.19.208.2]:20689 "EHLO
	jurand.ds.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8225781AbUFXSev>; Thu, 24 Jun 2004 19:34:51 +0100
Received: by jurand.ds.pg.gda.pl (Postfix, from userid 1011)
	id 84E3D475C0; Thu, 24 Jun 2004 20:34:44 +0200 (CEST)
Received: from localhost (localhost [127.0.0.1])
	by jurand.ds.pg.gda.pl (Postfix) with ESMTP
	id 794424622B; Thu, 24 Jun 2004 20:34:44 +0200 (CEST)
Date: Thu, 24 Jun 2004 20:34:44 +0200 (CEST)
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To: Richard Sandiford <rsandifo@redhat.com>
Cc: cgd@broadcom.com, David Daney <ddaney@avtrex.com>,
	Ralf Baechle <ralf@linux-mips.org>, linux-mips@linux-mips.org,
	binutils@sources.redhat.com
Subject: Re: [Patch]  / 0 should send SIGFPE not SIGTRAP...
In-Reply-To: <87y8mdgryp.fsf@redhat.com>
Message-ID: <Pine.LNX.4.55.0406242031020.8569@jurand.ds.pg.gda.pl>
References: <40C9F5A4.2050606@avtrex.com> <40C9F5FE.8030607@avtrex.com>
 <40C9F7F0.50501@avtrex.com> <Pine.LNX.4.55.0406112039040.13062@jurand.ds.pg.gda.pl>
 <mailpost.1086981251.16853@news-sj1-1> <yov57juduc7q.fsf@ldt-sj3-010.sj.broadcom.com>
 <Pine.LNX.4.55.0406222304340.23178@jurand.ds.pg.gda.pl> <87y8mdgryp.fsf@redhat.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: 5358
X-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, 24 Jun 2004, Richard Sandiford wrote:

> >  Or should we get rid of the 20-bit "break" completely?  The two-argument
> > version provides the same functionality, although the 10-bit codes to be
> > used do not map to the 20-bit equivalent "optically" very well.  
> > Especially if decimal notation is used.
> 
> I notice no-one's really responded to this question yet.  FWIW, on gut
> instinct, I'd personally prefer to drop the 20-bit break than introduce
> a new, non-standard name for it.

 Well, this is essentially what the patch does.  Or do you mean: "drop it
and if anyone screams, consider an alternative?"  I'd find it acceptable,
actually, but it's not my opinion that really matters here.

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

From cgd@broadcom.com Thu Jun 24 19:47:32 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 24 Jun 2004 19:47:36 +0100 (BST)
Received: from mms1.broadcom.com ([IPv6:::ffff:63.70.210.58]:61968 "EHLO
	mms1.broadcom.com") by linux-mips.org with ESMTP
	id <S8225781AbUFXSrc>; Thu, 24 Jun 2004 19:47:32 +0100
Received: from 63.70.210.1 by mms1.broadcom.com with ESMTP (Broadcom
 SMTP Relay (MMS v5.6.0)); Thu, 24 Jun 2004 11:46:59 -0700
X-Server-Uuid: 97B92932-364A-4474-92D6-5CFE9C59AD14
Received: from mail-sj1-5.sj.broadcom.com (mail-sj1-5.sj.broadcom.com
 [10.16.128.236]) by mon-irva-11.broadcom.com (8.9.1/8.9.1) with ESMTP
 id LAA03858; Thu, 24 Jun 2004 11:46:20 -0700 (PDT)
Received: from ldt-sj3-010.sj.broadcom.com (ldt-sj3-010 [10.21.64.10])
 by mail-sj1-5.sj.broadcom.com (8.12.9/8.12.9/SSF) with ESMTP id
 i5OIkrov009252; Thu, 24 Jun 2004 11:46:54 -0700 (PDT)
Received: (from cgd@localhost) by ldt-sj3-010.sj.broadcom.com (
 8.11.6/8.9.3) id i5OIkrA10130; Thu, 24 Jun 2004 11:46:53 -0700
X-Authentication-Warning: ldt-sj3-010.sj.broadcom.com: cgd set sender to
 cgd@broadcom.com using -f
To: macro@ds2.pg.gda.pl
cc: "Richard Sandiford" <rsandifo@redhat.com>,
	"David Daney" <ddaney@avtrex.com>,
	"Ralf Baechle" <ralf@linux-mips.org>, linux-mips@linux-mips.org,
	binutils@sources.redhat.com
Subject: Re: [Patch]  / 0 should send SIGFPE not SIGTRAP...
References: <40C9F5A4.2050606@avtrex.com> <40C9F5FE.8030607@avtrex.com>
 <40C9F7F0.50501@avtrex.com>
 <Pine.LNX.4.55.0406112039040.13062@jurand.ds.pg.gda.pl>
 <mailpost.1086981251.16853@news-sj1-1>
 <yov57juduc7q.fsf@ldt-sj3-010.sj.broadcom.com>
 <Pine.LNX.4.55.0406222304340.23178@jurand.ds.pg.gda.pl>
 <87y8mdgryp.fsf@redhat.com>
 <Pine.LNX.4.55.0406242031020.8569@jurand.ds.pg.gda.pl>
 <mailpost.1088102121.25381@news-sj1-1>
From: cgd@broadcom.com
Date: 24 Jun 2004 11:46:53 -0700
In-Reply-To: <mailpost.1088102121.25381@news-sj1-1>
Message-ID: <yov5eko4okte.fsf@ldt-sj3-010.sj.broadcom.com>
Lines: 6
User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2
MIME-Version: 1.0
X-WSS-ID: 6CC5FE292QW12723715-01-01
Content-Type: text/plain;
 charset=us-ascii
Content-Transfer-Encoding: 7bit
Return-Path: <cgd@broadcom.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: 5359
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: cgd@broadcom.com
Precedence: bulk
X-list: linux-mips

At Thu, 24 Jun 2004 18:35:21 +0000 (UTC), "Maciej W. Rozycki" wrote:
>  Well, this is essentially what the patch does.  Or do you mean: "drop it
> and if anyone screams, consider an alternative?"  I'd find it acceptable,
> actually, but it's not my opinion that really matters here.

(it's fine w/ me.)


From ralf@linux-mips.org Fri Jun 25 00:31:32 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 25 Jun 2004 00:31:37 +0100 (BST)
Received: from p508B6ABC.dip.t-dialin.net ([IPv6:::ffff:80.139.106.188]:2633
	"EHLO mail.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225796AbUFXXbc>; Fri, 25 Jun 2004 00:31:32 +0100
Received: from fluff.linux-mips.net (fluff.linux-mips.net [127.0.0.1])
	by mail.linux-mips.net (8.12.11/8.12.8) with ESMTP id i5ONVV8d016199;
	Fri, 25 Jun 2004 01:31:31 +0200
Received: (from ralf@localhost)
	by fluff.linux-mips.net (8.12.11/8.12.11/Submit) id i5ONVUYh016198;
	Fri, 25 Jun 2004 01:31:30 +0200
Date: Fri, 25 Jun 2004 01:31:30 +0200
From: Ralf Baechle <ralf@linux-mips.org>
To: Yaron Presente <ypresente@mrv.com>
Cc: linux-mips@linux-mips.org
Subject: Re: non-contiguous physical memory
Message-ID: <20040624233130.GA15158@linux-mips.org>
References: <40DACD33.60801@mrv.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <40DACD33.60801@mrv.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: 5360
X-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, Jun 24, 2004 at 03:46:43PM +0300, Yaron Presente wrote:

> I'm running montavista linux (2.4.18_mvl30-malta-mips_fp_le) on a board 
> that has 2 memory banks of physical memory.
> 1. 32MB from physical address 0x00000000
> 2. 16MB from physical address 0x20000000
> 
> Currently I can only access the first bank (by add_memory_region(0, 32 
> << 20, BOOT_MEM_RAM) in prom_init() ).
> I tried the obvious solution of adding another region at 0x20000000 
> (add_memory_region(0x20000000, 16 << 20, BOOT_MEM_RAM))
> but that didn't seem to work. I've also tried to add a BOOT_MEM_RESERVED 
> region in between the regions in order to create a seemingly contiguous 
> memory, with no success.
> My questions are:
> Is it possible to access the second bank as well under MIPS ?
> Is there a way to define a "hole" in the physical memory?
> Do I have to use CONFIG_DISCONTIGMEM ? is it fully supported ?
> Thanks for your help,

Your initial approach was nearly right - you can solve the problem of
holes in the memory map as long as they're small enough by only adding
the available regions with add_memory_region().  Typically uses for
this are small holes due to memory in use by firmware, for example.

Now, in your case the whole isn't small.  In fact, with 480MB it's big ;-)
What Linux will try to do is to allocate the mem_map array for the
entire memory range from 0x0 - 0x21000000, that's 528MB.  mem_map contains
one page per 4k page; each entry is 64 bytes in size for 32-bit kernels
so that makes a total size for mem_map[] of 8.25MB of which just 768kB are
actually being used.

Just to make life a little bit more misserable memory 32-bit kernels can
only use memory above the 512MB boundary as highmem.

CONFIG_DISCONTIGMEM can solve this problem - but Linux/MIPS really doesn't
much an attempt to make that easy to use.  Right now only a single MIPS
system is using CONFIG_DISCONTIGMEM and that system is using it in
combination with CONFIG_NUMA which is quite an additional complication.

With CONFIG_DISCONTIGMEM there will be no more mem_map[] array. Instead
there will be one such array for each memory region which means you'll
loose a bit of performance due to additional complexity but you'll save
all the wasted memory.

  Ralf

From jsun@mvista.com Fri Jun 25 00:45:53 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 25 Jun 2004 00:45:57 +0100 (BST)
Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:10991 "EHLO
	orion.mvista.com") by linux-mips.org with ESMTP id <S8225609AbUFXXpx>;
	Fri, 25 Jun 2004 00:45:53 +0100
Received: from orion.mvista.com (localhost.localdomain [127.0.0.1])
	by orion.mvista.com (8.12.8/8.12.8) with ESMTP id i5ONjp4O001493;
	Thu, 24 Jun 2004 16:45:51 -0700
Received: (from jsun@localhost)
	by orion.mvista.com (8.12.8/8.12.8/Submit) id i5ONjpT5001492;
	Thu, 24 Jun 2004 16:45:51 -0700
Date: Thu, 24 Jun 2004 16:45:51 -0700
From: Jun Sun <jsun@mvista.com>
To: linux-mips@linux-mips.org
Cc: jsun@mvista.com
Subject: IDE woos in BE mode 2.6 kernel
Message-ID: <20040624164551.H29225@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: 5361
X-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


Anybody has tried IDE disks in big endian mode with 2.6 kernel?
I seem to have troubles with Malta board.

Current malta board has CONFIG_SWAP_IO_SPACE defined and therefore
all inw, inl and their friends are byte-swapped in BE mode.  As a
results all IDE IO ops (such as ide_inw, etc) do swapping too.

A quick experiement shows those IDE IO ops should not do swapping.
Anybody knows why?

Apparently fixing the above is not enough.  I either encountered
failure to read partition table or having DMA error.  Any clues
here?

I suppose this problem really should exist for other arches
with BE support.  Anybody knows how other arches deal with this?

Thanks.

Jun

From geert@linux-m68k.org Fri Jun 25 09:45:07 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 25 Jun 2004 09:45:11 +0100 (BST)
Received: from witte.sonytel.be ([IPv6:::ffff:80.88.33.193]:31658 "EHLO
	witte.sonytel.be") by linux-mips.org with ESMTP id <S8225237AbUFYIpH>;
	Fri, 25 Jun 2004 09:45:07 +0100
Received: from waterleaf.sonytel.be (localhost [127.0.0.1])
	by witte.sonytel.be (8.12.10/8.12.10) with ESMTP id i5P8j3XK025858;
	Fri, 25 Jun 2004 10:45:03 +0200 (MEST)
Date: Fri, 25 Jun 2004 10:45:03 +0200 (MEST)
From: Geert Uytterhoeven <geert@linux-m68k.org>
To: Jun Sun <jsun@mvista.com>
cc: Linux/MIPS Development <linux-mips@linux-mips.org>
Subject: Re: IDE woos in BE mode 2.6 kernel
In-Reply-To: <20040624164551.H29225@mvista.com>
Message-ID: <Pine.GSO.4.58.0406251044140.23072@waterleaf.sonytel.be>
References: <20040624164551.H29225@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: 5362
X-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 Thu, 24 Jun 2004, Jun Sun wrote:
> I suppose this problem really should exist for other arches
> with BE support.  Anybody knows how other arches deal with this?

My Amiga is happily running 2.6.7 and doesn't have problems with IDE, so m68k
is not affected.

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 atti@ugyvitelszolgaltato.hu Fri Jun 25 10:42:01 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 25 Jun 2004 10:42:07 +0100 (BST)
Received: from adsl215141.vnet.hu ([IPv6:::ffff:62.77.215.141]:49995 "HELO
	wukifi.ugyvitelszolgaltato.hu") by linux-mips.org with SMTP
	id <S8225237AbUFYJmB>; Fri, 25 Jun 2004 10:42:01 +0100
Received: (qmail 4083 invoked from network); 25 Jun 2004 09:41:48 -0000
Received: from unknown (HELO ugyvitelszolgaltato.hu) (193.80.82.9)
  by 193.80.82.16 with SMTP; 25 Jun 2004 09:41:48 -0000
Received: (qmail 17641 invoked by uid 1001); 25 Jun 2004 09:41:36 -0000
Date: Fri, 25 Jun 2004 11:41:36 +0200
From: Attila Szabo <trial@ugyvitelszolgaltato.hu>
To: linux-mips@linux-mips.org
Subject: X on indy
Message-ID: <20040625094136.GA16856@csola.ugyvitelszolgaltato.hu>
Mail-Followup-To: linux-mips@linux-mips.org
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-2
Content-Disposition: inline
Organization: Ugyvitelszolgaltato Kft.
X-OS: Linux 2.4.22-ac4, Debian Sarge
X-Sys: MSI K7D Master, 2x1500+ MP, 512 Mb, 120Gb
X-WM: Blackbox 0.62
User-Agent: Mutt/1.5.5.1+cvs20040105i
Return-Path: <atti@ugyvitelszolgaltato.hu>
X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0)
X-Orcpt: rfc822;linux-mips@linux-mips.org
Original-Recipient: rfc822;linux-mips@linux-mips.org
X-archive-position: 5363
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: trial@ugyvitelszolgaltato.hu
Precedence: bulk
X-list: linux-mips

Hi,

is the newport driver accelerated in debian sarge's 4.3.0.1 X or
have to patch and compile ?

thanks
-- 

A t t i l a :: trial@ugyvitelszolgaltato.hu :: S z a b o


From ladis@linux-mips.org Fri Jun 25 10:54:32 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 25 Jun 2004 10:54:36 +0100 (BST)
Received: from smtp.seznam.cz ([IPv6:::ffff:212.80.76.43]:18100 "HELO
	smtp.seznam.cz") by linux-mips.org with SMTP id <S8225237AbUFYJyc>;
	Fri, 25 Jun 2004 10:54:32 +0100
Received: (qmail 18088 invoked from network); 25 Jun 2004 09:54:24 -0000
Received: from unknown (HELO umax645sx) (Ladislav.Michl@62.77.73.195)
  by smtp.seznam.cz with SMTP; 25 Jun 2004 09:54:24 -0000
Received: from ladis by umax645sx with local (Exim 3.36 #1 (Debian))
	id 1BdnPc-0001Ho-00; Fri, 25 Jun 2004 11:54:24 +0200
Date: Fri, 25 Jun 2004 11:54:24 +0200
To: linux-mips@linux-mips.org
Cc: Attila Szabo <trial@ugyvitelszolgaltato.hu>
Subject: Re: X on indy
Message-ID: <20040625095424.GA4913@umax645sx>
References: <20040625094136.GA16856@csola.ugyvitelszolgaltato.hu>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20040625094136.GA16856@csola.ugyvitelszolgaltato.hu>
User-Agent: Mutt/1.5.6+20040523i
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: 5364
X-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 Fri, Jun 25, 2004 at 11:41:36AM +0200, Attila Szabo wrote:
> Hi,
> 
> is the newport driver accelerated in debian sarge's 4.3.0.1 X or
> have to patch and compile ?

It's not that easy, you have to patch, _hack_ and compile ;)
Try to contact patch author for help, but don't expect too much, I have
no news from him since last summer.

	ladis

From ypresente@mrv.com Sun Jun 27 09:00:59 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 27 Jun 2004 09:01:04 +0100 (BST)
Received: from apollo.nbase.co.il ([IPv6:::ffff:194.90.137.2]:28434 "EHLO
	apollo.nbase.co.il") by linux-mips.org with ESMTP
	id <S8224986AbUF0IA7>; Sun, 27 Jun 2004 09:00:59 +0100
Received: from mrv.com ([194.90.136.133]) by apollo.nbase.co.il
          (Post.Office MTA v3.1.2 release (PO205-101c)
          ID# 0-44418U200L2S100) with ESMTP id AAA1631;
          Sun, 27 Jun 2004 11:08:52 +0200
Message-ID: <40DE7FF2.2030801@mrv.com>
Date: Sun, 27 Jun 2004 11:06:10 +0300
From: ypresente@mrv.com (Yaron Presente)
Organization: MRV International
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01
X-Accept-Language: en-us, en, he
MIME-Version: 1.0
To: Ralf Baechle <ralf@linux-mips.org>
CC: linux-mips@linux-mips.org
Subject: Re: non-contiguous physical memory
References: <40DACD33.60801@mrv.com> <20040624233130.GA15158@linux-mips.org>
Content-Type: multipart/alternative;
 boundary="------------020000080504060009010609"
Return-Path: <ypresente@mrv.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: 5366
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: ypresente@mrv.com
Precedence: bulk
X-list: linux-mips
Content-Length: 6412
Lines: 167


--------------020000080504060009010609
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Ralf,
Thanks for your help.
We've found out that the board can address more then 32MB in the lower 
bank, so for simplicity reasons,
I think that we just won't use the higher bank.
Yaron

Ralf Baechle wrote:

>On Thu, Jun 24, 2004 at 03:46:43PM +0300, Yaron Presente wrote:
>
>  
>
>>I'm running montavista linux (2.4.18_mvl30-malta-mips_fp_le) on a board 
>>that has 2 memory banks of physical memory.
>>1. 32MB from physical address 0x00000000
>>2. 16MB from physical address 0x20000000
>>
>>Currently I can only access the first bank (by add_memory_region(0, 32 
>><< 20, BOOT_MEM_RAM) in prom_init() ).
>>I tried the obvious solution of adding another region at 0x20000000 
>>(add_memory_region(0x20000000, 16 << 20, BOOT_MEM_RAM))
>>but that didn't seem to work. I've also tried to add a BOOT_MEM_RESERVED 
>>region in between the regions in order to create a seemingly contiguous 
>>memory, with no success.
>>My questions are:
>>Is it possible to access the second bank as well under MIPS ?
>>Is there a way to define a "hole" in the physical memory?
>>Do I have to use CONFIG_DISCONTIGMEM ? is it fully supported ?
>>Thanks for your help,
>>    
>>
>
>Your initial approach was nearly right - you can solve the problem of
>holes in the memory map as long as they're small enough by only adding
>the available regions with add_memory_region().  Typically uses for
>this are small holes due to memory in use by firmware, for example.
>
>Now, in your case the whole isn't small.  In fact, with 480MB it's big ;-)
>What Linux will try to do is to allocate the mem_map array for the
>entire memory range from 0x0 - 0x21000000, that's 528MB.  mem_map contains
>one page per 4k page; each entry is 64 bytes in size for 32-bit kernels
>so that makes a total size for mem_map[] of 8.25MB of which just 768kB are
>actually being used.
>
>Just to make life a little bit more misserable memory 32-bit kernels can
>only use memory above the 512MB boundary as highmem.
>
>CONFIG_DISCONTIGMEM can solve this problem - but Linux/MIPS really doesn't
>much an attempt to make that easy to use.  Right now only a single MIPS
>system is using CONFIG_DISCONTIGMEM and that system is using it in
>combination with CONFIG_NUMA which is quite an additional complication.
>
>With CONFIG_DISCONTIGMEM there will be no more mem_map[] array. Instead
>there will be one such array for each memory region which means you'll
>loose a bit of performance due to additional complexity but you'll save
>all the wasted memory.
>
>  Ralf
> This mail arrived via mail.mrv.com
>
> 
>************************************************************************************
>This footnote confirms that this email message has been scanned by
>PineApp Mail-SeCure for the presence of malicious code, vandals & computer viruses.
>************************************************************************************
>
>  
>




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

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <title></title>
</head>
<body>
Ralf,<br>
Thanks for your help. <br>
We've found out that the board can address more then 32MB in the lower bank,
so for simplicity reasons,<br>
I think that we just won't use the higher bank.<br>
Yaron<br>
<br>
Ralf Baechle wrote:<br>
<blockquote type="cite" cite="mid20040624233130.GA15158@linux-mips.org">
  <pre wrap="">On Thu, Jun 24, 2004 at 03:46:43PM +0300, Yaron Presente wrote:

  </pre>
  <blockquote type="cite">
    <pre wrap="">I'm running montavista linux (2.4.18_mvl30-malta-mips_fp_le) on a board 
that has 2 memory banks of physical memory.
1. 32MB from physical address 0x00000000
2. 16MB from physical address 0x20000000

Currently I can only access the first bank (by add_memory_region(0, 32 
&lt;&lt; 20, BOOT_MEM_RAM) in prom_init() ).
I tried the obvious solution of adding another region at 0x20000000 
(add_memory_region(0x20000000, 16 &lt;&lt; 20, BOOT_MEM_RAM))
but that didn't seem to work. I've also tried to add a BOOT_MEM_RESERVED 
region in between the regions in order to create a seemingly contiguous 
memory, with no success.
My questions are:
Is it possible to access the second bank as well under MIPS ?
Is there a way to define a "hole" in the physical memory?
Do I have to use CONFIG_DISCONTIGMEM ? is it fully supported ?
Thanks for your help,
    </pre>
  </blockquote>
  <pre wrap=""><!---->
Your initial approach was nearly right - you can solve the problem of
holes in the memory map as long as they're small enough by only adding
the available regions with add_memory_region().  Typically uses for
this are small holes due to memory in use by firmware, for example.

Now, in your case the whole isn't small.  In fact, with 480MB it's big ;-)
What Linux will try to do is to allocate the mem_map array for the
entire memory range from 0x0 - 0x21000000, that's 528MB.  mem_map contains
one page per 4k page; each entry is 64 bytes in size for 32-bit kernels
so that makes a total size for mem_map[] of 8.25MB of which just 768kB are
actually being used.

Just to make life a little bit more misserable memory 32-bit kernels can
only use memory above the 512MB boundary as highmem.

CONFIG_DISCONTIGMEM can solve this problem - but Linux/MIPS really doesn't
much an attempt to make that easy to use.  Right now only a single MIPS
system is using CONFIG_DISCONTIGMEM and that system is using it in
combination with CONFIG_NUMA which is quite an additional complication.

With CONFIG_DISCONTIGMEM there will be no more mem_map[] array. Instead
there will be one such array for each memory region which means you'll
loose a bit of performance due to additional complexity but you'll save
all the wasted memory.

  Ralf
 This mail arrived via mail.mrv.com

 
************************************************************************************
This footnote confirms that this email message has been scanned by
PineApp Mail-SeCure for the presence of malicious code, vandals &amp; computer viruses.
************************************************************************************

  </pre>
</blockquote>
<pre class="moz-signature" cols="$mailwrapcol">


</pre>
<br>
</body>
</html>

--------------020000080504060009010609--


From macro@linux-mips.org Mon Jun 28 14:12:38 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 28 Jun 2004 14:12:44 +0100 (BST)
Received: from jurand.ds.pg.gda.pl ([IPv6:::ffff:153.19.208.2]:46024 "EHLO
	jurand.ds.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8225285AbUF1NMi>; Mon, 28 Jun 2004 14:12:38 +0100
Received: by jurand.ds.pg.gda.pl (Postfix, from userid 1011)
	id 8CCC449D0A; Mon, 28 Jun 2004 15:12:27 +0200 (CEST)
Received: from localhost (localhost [127.0.0.1])
	by jurand.ds.pg.gda.pl (Postfix) with ESMTP
	id 7B23C47C5C; Mon, 28 Jun 2004 15:12:27 +0200 (CEST)
Date: Mon, 28 Jun 2004 15:12:27 +0200 (CEST)
From: "Maciej W. Rozycki" <macro@linux-mips.org>
To: Ralf Baechle <ralf@linux-mips.org>
Cc: linux-mips@linux-mips.org
Subject: Re: [patch] Prevent dead code/data removal with gcc 3.4
In-Reply-To: <20040213145316.GA23810@linux-mips.org>
Message-ID: <Pine.LNX.4.55.0406281509170.23162@jurand.ds.pg.gda.pl>
References: <Pine.LNX.4.55.0402131453360.15042@jurand.ds.pg.gda.pl>
 <20040213145316.GA23810@linux-mips.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <macro@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: 5367
X-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@linux-mips.org
Precedence: bulk
X-list: linux-mips

On Fri, 13 Feb 2004, Ralf Baechle wrote:

> It is possible that gcc changes one of the registers before save_static
> and I can't imagine there's a reliable way to fix this in the inline
> version.

 Here's an updated version.  It's been checked with gcc 3.5.0, but it
should work just fine back to 2.95 at least.  OK to apply?

  Maciej

patch-mips-2.4.26-20040531-mips-save-static-gcc3-1
diff -up --recursive --new-file linux-mips-2.4.26-20040531.macro/arch/mips/kernel/signal.c linux-mips-2.4.26-20040531/arch/mips/kernel/signal.c
--- linux-mips-2.4.26-20040531.macro/arch/mips/kernel/signal.c	2004-03-03 03:57:09.000000000 +0000
+++ linux-mips-2.4.26-20040531/arch/mips/kernel/signal.c	2004-06-26 17:12:28.000000000 +0000
@@ -6,8 +6,10 @@
  * Copyright (C) 1991, 1992  Linus Torvalds
  * Copyright (C) 1994 - 1999  Ralf Baechle
  * Copyright (C) 1999 Silicon Graphics, Inc.
+ * Copyright (C) 2004  Maciej W. Rozycki
  */
 #include <linux/config.h>
+#include <linux/compiler.h>
 #include <linux/sched.h>
 #include <linux/mm.h>
 #include <linux/smp.h>
@@ -76,7 +78,9 @@ int copy_siginfo_to_user(siginfo_t *to, 
  * Atomically swap in the new signal mask, and wait for a signal.
  */
 save_static_function(sys_sigsuspend);
-static_unused int _sys_sigsuspend(struct pt_regs regs)
+static int _sys_sigsuspend(struct pt_regs regs)
+	__asm__("_sys_sigsuspend") __attribute_used__;
+static int _sys_sigsuspend(struct pt_regs regs)
 {
 	sigset_t *uset, saveset, newset;
 
@@ -102,7 +106,9 @@ static_unused int _sys_sigsuspend(struct
 }
 
 save_static_function(sys_rt_sigsuspend);
-static_unused int _sys_rt_sigsuspend(struct pt_regs regs)
+static int _sys_rt_sigsuspend(struct pt_regs regs)
+	__asm__("_sys_rt_sigsuspend") __attribute_used__;
+static int _sys_rt_sigsuspend(struct pt_regs regs)
 {
 	sigset_t *unewset, saveset, newset;
         size_t sigsetsize;
diff -up --recursive --new-file linux-mips-2.4.26-20040531.macro/arch/mips/kernel/syscall.c linux-mips-2.4.26-20040531/arch/mips/kernel/syscall.c
--- linux-mips-2.4.26-20040531.macro/arch/mips/kernel/syscall.c	2003-04-01 02:56:50.000000000 +0000
+++ linux-mips-2.4.26-20040531/arch/mips/kernel/syscall.c	2004-06-26 17:14:46.000000000 +0000
@@ -5,6 +5,7 @@
  *
  * Copyright (C) 1995 - 2000 by Ralf Baechle
  * Copyright (C) 2000 Silicon Graphics, Inc.
+ * Copyright (C) 2004  Maciej W. Rozycki
  *
  * TODO:  Implement the compatibility syscalls.
  *        Don't waste that much memory for empty entries in the syscall
@@ -158,7 +159,9 @@ sys_mmap2(unsigned long addr, unsigned l
 }
 
 save_static_function(sys_fork);
-static_unused int _sys_fork(struct pt_regs regs)
+static int _sys_fork(struct pt_regs regs)
+	__asm__("_sys_fork") __attribute_used__;
+static int _sys_fork(struct pt_regs regs)
 {
 	int res;
 
@@ -168,7 +171,9 @@ static_unused int _sys_fork(struct pt_re
 
 
 save_static_function(sys_clone);
-static_unused int _sys_clone(struct pt_regs regs)
+static int _sys_clone(struct pt_regs regs)
+	__asm__("_sys_clone") __attribute_used__;
+static int _sys_clone(struct pt_regs regs)
 {
 	unsigned long clone_flags;
 	unsigned long newsp;
diff -up --recursive --new-file linux-mips-2.4.26-20040531.macro/arch/mips64/kernel/signal.c linux-mips-2.4.26-20040531/arch/mips64/kernel/signal.c
--- linux-mips-2.4.26-20040531.macro/arch/mips64/kernel/signal.c	2004-03-03 03:57:12.000000000 +0000
+++ linux-mips-2.4.26-20040531/arch/mips64/kernel/signal.c	2004-06-26 17:19:15.000000000 +0000
@@ -6,8 +6,10 @@
  * Copyright (C) 1991, 1992  Linus Torvalds
  * Copyright (C) 1994 - 2000  Ralf Baechle
  * Copyright (C) 1999, 2000 Silicon Graphics, Inc.
+ * Copyright (C) 2004  Maciej W. Rozycki
  */
 #include <linux/config.h>
+#include <linux/compiler.h>
 #include <linux/sched.h>
 #include <linux/mm.h>
 #include <linux/smp.h>
@@ -75,7 +77,9 @@ int copy_siginfo_to_user(siginfo_t *to, 
  * Atomically swap in the new signal mask, and wait for a signal.
  */
 save_static_function(sys_rt_sigsuspend);
-static_unused int _sys_rt_sigsuspend(abi64_no_regargs, struct pt_regs regs)
+static int _sys_rt_sigsuspend(abi64_no_regargs, struct pt_regs regs)
+	__asm__("_sys_rt_sigsuspend") __attribute_used__;
+static int _sys_rt_sigsuspend(abi64_no_regargs, struct pt_regs regs)
 {
 	sigset_t *unewset, saveset, newset;
         size_t sigsetsize;
diff -up --recursive --new-file linux-mips-2.4.26-20040531.macro/arch/mips64/kernel/signal32.c linux-mips-2.4.26-20040531/arch/mips64/kernel/signal32.c
--- linux-mips-2.4.26-20040531.macro/arch/mips64/kernel/signal32.c	2004-03-04 03:57:04.000000000 +0000
+++ linux-mips-2.4.26-20040531/arch/mips64/kernel/signal32.c	2004-06-26 17:19:06.000000000 +0000
@@ -6,7 +6,9 @@
  * Copyright (C) 1991, 1992  Linus Torvalds
  * Copyright (C) 1994 - 2000  Ralf Baechle
  * Copyright (C) 1999, 2000 Silicon Graphics, Inc.
+ * Copyright (C) 2004  Maciej W. Rozycki
  */
+#include <linux/compiler.h>
 #include <linux/sched.h>
 #include <linux/mm.h>
 #include <linux/smp.h>
@@ -127,7 +129,9 @@ static inline int get_sigset(sigset_t *k
  * Atomically swap in the new signal mask, and wait for a signal.
  */
 save_static_function(sys32_sigsuspend);
-static_unused int _sys32_sigsuspend(abi64_no_regargs, struct pt_regs regs)
+static int _sys32_sigsuspend(abi64_no_regargs, struct pt_regs regs)
+	__asm__("_sys32_sigsuspend") __attribute_used__;
+static int _sys32_sigsuspend(abi64_no_regargs, struct pt_regs regs)
 {
 	sigset32_t *uset;
 	sigset_t newset, saveset;
@@ -154,7 +158,9 @@ static_unused int _sys32_sigsuspend(abi6
 }
 
 save_static_function(sys32_rt_sigsuspend);
-static_unused int _sys32_rt_sigsuspend(abi64_no_regargs, struct pt_regs regs)
+static int _sys32_rt_sigsuspend(abi64_no_regargs, struct pt_regs regs)
+	__asm__("_sys32_rt_sigsuspend") __attribute_used__;
+static int _sys32_rt_sigsuspend(abi64_no_regargs, struct pt_regs regs)
 {
 	sigset32_t *uset;
 	sigset_t newset, saveset;
diff -up --recursive --new-file linux-mips-2.4.26-20040531.macro/arch/mips64/kernel/syscall.c linux-mips-2.4.26-20040531/arch/mips64/kernel/syscall.c
--- linux-mips-2.4.26-20040531.macro/arch/mips64/kernel/syscall.c	2004-03-10 03:57:00.000000000 +0000
+++ linux-mips-2.4.26-20040531/arch/mips64/kernel/syscall.c	2004-06-26 17:21:08.000000000 +0000
@@ -6,7 +6,9 @@
  * Copyright (C) 1995 - 2000, 2001 by Ralf Baechle
  * Copyright (C) 1999, 2000 Silicon Graphics, Inc.
  * Copyright (C) 2001 MIPS Technologies, Inc.
+ * Copyright (C) 2004  Maciej W. Rozycki
  */
+#include <linux/compiler.h>
 #include <linux/errno.h>
 #include <linux/linkage.h>
 #include <linux/mm.h>
@@ -151,7 +153,9 @@ out:
 }
 
 save_static_function(sys_fork);
-static_unused int _sys_fork(abi64_no_regargs, struct pt_regs regs)
+static int _sys_fork(abi64_no_regargs, struct pt_regs regs)
+	__asm__("_sys_fork") __attribute_used__;
+static int _sys_fork(abi64_no_regargs, struct pt_regs regs)
 {
 	int res;
 
@@ -160,7 +164,9 @@ static_unused int _sys_fork(abi64_no_reg
 }
 
 save_static_function(sys_clone);
-static_unused int _sys_clone(abi64_no_regargs, struct pt_regs regs)
+static int _sys_clone(abi64_no_regargs, struct pt_regs regs)
+	__asm__("_sys_clone") __attribute_used__;
+static int _sys_clone(abi64_no_regargs, struct pt_regs regs)
 {
 	unsigned long clone_flags;
 	unsigned long newsp;
diff -up --recursive --new-file linux-mips-2.4.26-20040531.macro/include/asm-mips/ptrace.h linux-mips-2.4.26-20040531/include/asm-mips/ptrace.h
--- linux-mips-2.4.26-20040531.macro/include/asm-mips/ptrace.h	2004-02-09 04:30:14.000000000 +0000
+++ linux-mips-2.4.26-20040531/include/asm-mips/ptrace.h	2004-06-26 17:30:45.000000000 +0000
@@ -4,6 +4,7 @@
  * for more details.
  *
  * Copyright (C) 1994, 1995, 1996, 1997, 1998, 1999, 2000 by Ralf Baechle
+ * Copyright (C) 2004  Maciej W. Rozycki
  *
  * Machine dependent structs and defines to help the user use
  * the ptrace system call.
@@ -64,12 +65,10 @@ __asm__ (                               
         "sw\t$22,"__str(PT_R22)"($29)\n\t"                              \
         "sw\t$23,"__str(PT_R23)"($29)\n\t"                              \
         "sw\t$30,"__str(PT_R30)"($29)\n\t"                              \
+	"j\t_" #symbol "\n\t"						\
         ".end\t" #symbol "\n\t"                                         \
         ".size\t" #symbol",. - " #symbol)
 
-/* Used in declaration of save_static functions.  */
-#define static_unused static __attribute__((unused))
-
 #endif /* !__ASSEMBLY__ */
 
 /* Arbitrarily choose the same ptrace numbers as used by the Sparc code. */
diff -up --recursive --new-file linux-mips-2.4.26-20040531.macro/include/asm-mips64/ptrace.h linux-mips-2.4.26-20040531/include/asm-mips64/ptrace.h
--- linux-mips-2.4.26-20040531.macro/include/asm-mips64/ptrace.h	2004-01-26 03:35:56.000000000 +0000
+++ linux-mips-2.4.26-20040531/include/asm-mips64/ptrace.h	2004-06-26 17:30:15.000000000 +0000
@@ -5,6 +5,7 @@
  *
  * Copyright (C) 1994, 95, 96, 97, 98, 99, 2000 by Ralf Baechle
  * Copyright (C) 1999, 2000 Silicon Graphics, Inc.
+ * Copyright (C) 2004  Maciej W. Rozycki
  */
 #ifndef _ASM_PTRACE_H
 #define _ASM_PTRACE_H
@@ -61,12 +62,10 @@ __asm__ (                               
         "sd\t$22,"__str(PT_R22)"($29)\n\t"                              \
         "sd\t$23,"__str(PT_R23)"($29)\n\t"                              \
         "sd\t$30,"__str(PT_R30)"($29)\n\t"                              \
+	"j\t_" #symbol "\n\t"						\
         ".end\t" #symbol "\n\t"                                         \
         ".size\t" #symbol",. - " #symbol)
 
-/* Used in declaration of save_static functions.  */
-#define static_unused static __attribute__((unused))
-
 #define abi64_no_regargs						\
 	unsigned long __dummy0,						\
 	unsigned long __dummy1,						\

From macro@linux-mips.org Mon Jun 28 14:25:12 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 28 Jun 2004 14:25:19 +0100 (BST)
Received: from jurand.ds.pg.gda.pl ([IPv6:::ffff:153.19.208.2]:9163 "EHLO
	jurand.ds.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8225285AbUF1NZM>; Mon, 28 Jun 2004 14:25:12 +0100
Received: by jurand.ds.pg.gda.pl (Postfix, from userid 1011)
	id BAAFD47392; Mon, 28 Jun 2004 15:25:04 +0200 (CEST)
Received: from localhost (localhost [127.0.0.1])
	by jurand.ds.pg.gda.pl (Postfix) with ESMTP
	id AC27544F05; Mon, 28 Jun 2004 15:25:04 +0200 (CEST)
Date: Mon, 28 Jun 2004 15:25:04 +0200 (CEST)
From: "Maciej W. Rozycki" <macro@linux-mips.org>
To: Ralf Baechle <ralf@linux-mips.org>
Cc: linux-mips@linux-mips.org
Subject: [patch] Incorrect mapping of serial ports to lines
Message-ID: <Pine.LNX.4.55.0406281513120.23162@jurand.ds.pg.gda.pl>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <macro@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: 5368
X-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@linux-mips.org
Precedence: bulk
X-list: linux-mips

Hello,

 Onboard PC-compatible serial ports of the 8250 family are expected to be
assigned to lines 0 - 3.  Unfortunately for MIPS this is not guaranteed as
EXTRA_SERIAL_PORT_DEFNS and HUB6_SERIAL_PORT_DFNS precede
STD_SERIAL_PORT_DEFNS on the port list and their definitions change
depending on CONFIG_SERIAL_MANY_PORTS and CONFIG_HUB6 which are user
settable.  As a result, they may get different assignments depending on
configuration -- e.g. my last build for the Malta board resulted in its
onboard ports being assigned to lines 28 and 29.

 This can be fixed with a correct ordering of entries on the port list, 
like the following.  OK to apply?

  Maciej

patch-mips-2.4.26-20040531-mips-serial-0
diff -up --recursive --new-file linux-mips-2.4.26-20040531.macro/include/asm-mips/serial.h linux-mips-2.4.26-20040531/include/asm-mips/serial.h
--- linux-mips-2.4.26-20040531.macro/include/asm-mips/serial.h	2004-06-13 23:16:56.000000000 +0000
+++ linux-mips-2.4.26-20040531/include/asm-mips/serial.h	2004-06-27 12:49:23.000000000 +0000
@@ -5,6 +5,7 @@
  *
  * Copyright (C) 1999 by Ralf Baechle
  * Copyright (C) 1999, 2000 Silicon Graphics, Inc.
+ * Copyright (C) 2004  Maciej W. Rozycki
  */
 #ifndef _ASM_SERIAL_H
 #define _ASM_SERIAL_H
@@ -410,14 +411,25 @@
 #define DDB5477_SERIAL_PORT_DEFNS
 #endif
 
+/*
+ * The order matters here and should be as follows:
+ *
+ * 1. STD_SERIAL_PORT_DEFNS
+ * 2. board-specific ports (please keep sorted)
+ * 3. EXTRA_SERIAL_PORT_DEFNS
+ * 4. HUB6_SERIAL_PORT_DFNS
+ *
+ * otherwise serial line numbers may change across
+ * kernel builds if configuration changes. --macro
+ */
 #define SERIAL_PORT_DFNS			\
+	STD_SERIAL_PORT_DEFNS			\
+						\
 	ATLAS_SERIAL_PORT_DEFNS			\
 	AU1000_SERIAL_PORT_DEFNS		\
 	COBALT_SERIAL_PORT_DEFNS		\
 	DDB5477_SERIAL_PORT_DEFNS		\
 	EV96100_SERIAL_PORT_DEFNS		\
-	EXTRA_SERIAL_PORT_DEFNS			\
-	HUB6_SERIAL_PORT_DFNS			\
 	ITE_SERIAL_PORT_DEFNS           	\
 	IVR_SERIAL_PORT_DEFNS           	\
 	JAZZ_SERIAL_PORT_DEFNS			\
@@ -426,8 +438,10 @@
 	MOMENCO_OCELOT_C_SERIAL_PORT_DEFNS	\
 	MOMENCO_JAGUAR_ATX_SERIAL_PORT_DEFNS	\
 	SEAD_SERIAL_PORT_DEFNS			\
-	STD_SERIAL_PORT_DEFNS			\
 	TITAN_SERIAL_PORT_DEFNS			\
-	TXX927_SERIAL_PORT_DEFNS
+	TXX927_SERIAL_PORT_DEFNS		\
+						\
+	EXTRA_SERIAL_PORT_DEFNS			\
+	HUB6_SERIAL_PORT_DFNS
 
 #endif /* _ASM_SERIAL_H */
diff -up --recursive --new-file linux-mips-2.4.26-20040531.macro/include/asm-mips64/serial.h linux-mips-2.4.26-20040531/include/asm-mips64/serial.h
--- linux-mips-2.4.26-20040531.macro/include/asm-mips64/serial.h	2003-12-18 03:57:25.000000000 +0000
+++ linux-mips-2.4.26-20040531/include/asm-mips64/serial.h	2004-06-27 12:52:51.000000000 +0000
@@ -5,6 +5,7 @@
  *
  * Copyright (C) 1999 by Ralf Baechle
  * Copyright (C) 1999, 2000 Silicon Graphics, Inc.
+ * Copyright (C) 2004  Maciej W. Rozycki
  */
 #ifndef _ASM_SERIAL_H
 #define _ASM_SERIAL_H
@@ -146,12 +147,22 @@
 #define IP27_SERIAL_PORT_DEFNS
 #endif /* CONFIG_SGI_IP27 */
 
+/*
+ * The order matters here and should be as follows:
+ *
+ * 1. STD_SERIAL_PORT_DEFNS
+ * 2. board-specific ports (please keep sorted)
+ *
+ * otherwise serial line numbers may change across
+ * kernel builds if configuration changes. --macro
+ */
 #define SERIAL_PORT_DFNS				\
+	STD_SERIAL_PORT_DEFNS				\
+							\
 	IP27_SERIAL_PORT_DEFNS				\
 	MOMENCO_OCELOT_C_SERIAL_PORT_DEFNS		\
 	MOMENCO_JAGUAR_ATX_SERIAL_PORT_DEFNS		\
 	SEAD_SERIAL_PORT_DEFNS				\
-	STD_SERIAL_PORT_DEFNS				\
 	TITAN_SERIAL_PORT_DEFNS
 
 #define RS_TABLE_SIZE	64

From macro@linux-mips.org Mon Jun 28 14:46:35 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 28 Jun 2004 14:46:41 +0100 (BST)
Received: from jurand.ds.pg.gda.pl ([IPv6:::ffff:153.19.208.2]:55760 "EHLO
	jurand.ds.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8225285AbUF1Nqf>; Mon, 28 Jun 2004 14:46:35 +0100
Received: by jurand.ds.pg.gda.pl (Postfix, from userid 1011)
	id 5E230474C5; Mon, 28 Jun 2004 15:46:29 +0200 (CEST)
Received: from localhost (localhost [127.0.0.1])
	by jurand.ds.pg.gda.pl (Postfix) with ESMTP
	id 47A4545837; Mon, 28 Jun 2004 15:46:29 +0200 (CEST)
Date: Mon, 28 Jun 2004 15:46:29 +0200 (CEST)
From: "Maciej W. Rozycki" <macro@linux-mips.org>
To: cgd@broadcom.com
Cc: Richard Sandiford <rsandifo@redhat.com>,
	David Daney <ddaney@avtrex.com>,
	Ralf Baechle <ralf@linux-mips.org>, linux-mips@linux-mips.org,
	binutils@sources.redhat.com
Subject: Re: [Patch]  / 0 should send SIGFPE not SIGTRAP...
In-Reply-To: <yov5eko4okte.fsf@ldt-sj3-010.sj.broadcom.com>
Message-ID: <Pine.LNX.4.55.0406281532530.23162@jurand.ds.pg.gda.pl>
References: <40C9F5A4.2050606@avtrex.com> <40C9F5FE.8030607@avtrex.com>
 <40C9F7F0.50501@avtrex.com> <Pine.LNX.4.55.0406112039040.13062@jurand.ds.pg.gda.pl>
 <mailpost.1086981251.16853@news-sj1-1> <yov57juduc7q.fsf@ldt-sj3-010.sj.broadcom.com>
 <Pine.LNX.4.55.0406222304340.23178@jurand.ds.pg.gda.pl> <87y8mdgryp.fsf@redhat.com>
 <Pine.LNX.4.55.0406242031020.8569@jurand.ds.pg.gda.pl> <mailpost.1088102121.25381@news-sj1-1>
 <yov5eko4okte.fsf@ldt-sj3-010.sj.broadcom.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <macro@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: 5369
X-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@linux-mips.org
Precedence: bulk
X-list: linux-mips

On Thu, 24 Jun 2004 cgd@broadcom.com wrote:

> >  Well, this is essentially what the patch does.  Or do you mean: "drop it
> > and if anyone screams, consider an alternative?"  I'd find it acceptable,
> > actually, but it's not my opinion that really matters here.
> 
> (it's fine w/ me.)

 Here's an updated patch I use currently in case this is the solution to
be agreed upon.

opcodes/:
2004-06-28  Maciej W. Rozycki  <macro@linux-mips.org>

	* mips-opc.c (mips_builtin_opcodes): Remove the MIPS32 
	ISA-specific "break" encoding.

gas/testsuite/:
2004-06-28  Maciej W. Rozycki  <macro@linux-mips.org>

	* gas/mips/mips32.s: Adjust for the unified "break" syntax.
	* gas/mips/set-arch.s: Likewise.
	* gas/mips/mips32.d: Adjust for the new output.
	* gas/mips/set-arch.d: Likewise.

  Maciej

binutils-2.15.91-20040625-mips-break20.patch
diff -up --recursive --new-file binutils-2.15.91-20040625.macro/gas/testsuite/gas/mips/mips32.d binutils-2.15.91-20040625/gas/testsuite/gas/mips/mips32.d
--- binutils-2.15.91-20040625.macro/gas/testsuite/gas/mips/mips32.d	2003-05-08 03:25:35.000000000 +0000
+++ binutils-2.15.91-20040625/gas/testsuite/gas/mips/mips32.d	2004-06-17 21:15:04.000000000 +0000
@@ -48,7 +48,7 @@ Disassembly of section .text:
 0+0098 <[^>]*> 4359e260 	wait	0x56789
 0+009c <[^>]*> 0000000d 	break
 0+00a0 <[^>]*> 0000000d 	break
-0+00a4 <[^>]*> 0048d14d 	break	0x12345
+0+00a4 <[^>]*> 0048d14d 	break	0x48,0x345
 0+00a8 <[^>]*> 7000003f 	sdbbp
 0+00ac <[^>]*> 7000003f 	sdbbp
 0+00b0 <[^>]*> 7159e27f 	sdbbp	0x56789
diff -up --recursive --new-file binutils-2.15.91-20040625.macro/gas/testsuite/gas/mips/mips32.s binutils-2.15.91-20040625/gas/testsuite/gas/mips/mips32.s
--- binutils-2.15.91-20040625.macro/gas/testsuite/gas/mips/mips32.s	2002-09-05 03:25:40.000000000 +0000
+++ binutils-2.15.91-20040625/gas/testsuite/gas/mips/mips32.s	2004-06-26 12:41:17.000000000 +0000
@@ -58,11 +58,13 @@ text_label:
       wait    0                       # disassembles without code
       wait    0x56789
 
-      # Instructions in previous ISAs or CPUs which are now slightly
-      # different.
+      # Instructions that used to have compatibility problems.
       break
       break   0                       # disassembles without code
-      break   0x12345
+      break   0x48,0x345
+
+      # Instructions in previous ISAs or CPUs which are now slightly
+      # different.
       sdbbp
       sdbbp   0                       # disassembles without code
       sdbbp   0x56789
diff -up --recursive --new-file binutils-2.15.91-20040625.macro/gas/testsuite/gas/mips/set-arch.d binutils-2.15.91-20040625/gas/testsuite/gas/mips/set-arch.d
--- binutils-2.15.91-20040625.macro/gas/testsuite/gas/mips/set-arch.d	2003-10-01 03:25:36.000000000 +0000
+++ binutils-2.15.91-20040625/gas/testsuite/gas/mips/set-arch.d	2004-06-17 21:17:46.000000000 +0000
@@ -160,7 +160,7 @@ Disassembly of section \.text:
 00000260 <[^>]*> 4359e260 	wait	0x56789
 00000264 <[^>]*> 0000000d 	break
 00000268 <[^>]*> 0000000d 	break
-0000026c <[^>]*> 0048d14d 	break	0x12345
+0000026c <[^>]*> 0048d14d 	break	0x48,0x345
 00000270 <[^>]*> 7000003f 	sdbbp
 00000274 <[^>]*> 7000003f 	sdbbp
 00000278 <[^>]*> 7159e27f 	sdbbp	0x56789
diff -up --recursive --new-file binutils-2.15.91-20040625.macro/gas/testsuite/gas/mips/set-arch.s binutils-2.15.91-20040625/gas/testsuite/gas/mips/set-arch.s
--- binutils-2.15.91-20040625.macro/gas/testsuite/gas/mips/set-arch.s	2003-06-29 19:41:33.000000000 +0000
+++ binutils-2.15.91-20040625/gas/testsuite/gas/mips/set-arch.s	2004-06-26 12:42:22.000000000 +0000
@@ -200,11 +200,13 @@ text_label:	
 	wait    0                       # disassembles without code
 	wait    0x56789
 
-	# Instructions in previous ISAs or CPUs which are now slightly
-	# different.
+	# Instructions that used to have compatibility problems.
 	break
 	break   0                       # disassembles without code
-	break   0x12345
+	break   0x48,0x345
+
+	# Instructions in previous ISAs or CPUs which are now slightly
+	# different.
 	sdbbp
 	sdbbp   0                       # disassembles without code
 	sdbbp   0x56789
diff -up --recursive --new-file binutils-2.15.91-20040625.macro/opcodes/mips-opc.c binutils-2.15.91-20040625/opcodes/mips-opc.c
--- binutils-2.15.91-20040625.macro/opcodes/mips-opc.c	2003-11-19 04:25:23.000000000 +0000
+++ binutils-2.15.91-20040625/opcodes/mips-opc.c	2004-06-26 12:42:46.000000000 +0000
@@ -274,7 +274,6 @@ const struct mips_opcode mips_builtin_op
 {"bnel",    "s,t,p",	0x54000000, 0xfc000000,	CBL|RD_s|RD_t, 		I2|T3	},
 {"bnel",    "s,I,p",	0,    (int) M_BNEL_I,	INSN_MACRO,		I2|T3	},
 {"break",   "",		0x0000000d, 0xffffffff,	TRAP,			I1	},
-{"break",   "B",        0x0000000d, 0xfc00003f, TRAP,           	I32     },
 {"break",   "c",	0x0000000d, 0xfc00ffff,	TRAP,			I1	},
 {"break",   "c,q",	0x0000000d, 0xfc00003f,	TRAP,			I1	},
 {"c.f.d",   "S,T",	0x46200030, 0xffe007ff,	RD_S|RD_T|WR_CC|FP_D,	I1	},

From cgd@broadcom.com Mon Jun 28 16:19:56 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 28 Jun 2004 16:20:01 +0100 (BST)
Received: from mms3.broadcom.com ([IPv6:::ffff:63.70.210.38]:40207 "EHLO
	mms3.broadcom.com") by linux-mips.org with ESMTP
	id <S8225370AbUF1PT4>; Mon, 28 Jun 2004 16:19:56 +0100
Received: from 63.70.210.1 by mms3.broadcom.com with ESMTP (Broadcom
 SMTP Relay (MMS v5.6.0)); Mon, 28 Jun 2004 08:19:42 -0700
X-Server-Uuid: 8D569F9F-42CF-4602-970D-AACC4BD5D310
Received: from mail-sj1-5.sj.broadcom.com (mail-sj1-5.sj.broadcom.com
 [10.16.128.236]) by mon-irva-11.broadcom.com (8.9.1/8.9.1) with ESMTP
 id IAA03384; Mon, 28 Jun 2004 08:19:05 -0700 (PDT)
From: cgd@broadcom.com
Received: from mail-sj1-2.sj.broadcom.com (mail-sj1-2 [10.16.128.232])
 by mail-sj1-5.sj.broadcom.com (8.12.9/8.12.9/SSF) with ESMTP id
 i5SFJcov027982; Mon, 28 Jun 2004 08:19:38 -0700 (PDT)
Received: (from cgd@localhost) by mail-sj1-2.sj.broadcom.com (
 8.9.1/SJ8.9.1) id IAA29663; Mon, 28 Jun 2004 08:19:38 -0700 (PDT)
Date: Mon, 28 Jun 2004 08:19:38 -0700 (PDT)
Message-ID: <200406281519.IAA29663@mail-sj1-2.sj.broadcom.com>
To: cgd@broadcom.com, macro@linux-mips.org
Subject: Re: [Patch]  / 0 should send SIGFPE not SIGTRAP...
cc: binutils@sources.redhat.com, ddaney@avtrex.com,
	linux-mips@linux-mips.org, ralf@linux-mips.org, rsandifo@redhat.com
MIME-Version: 1.0
X-WSS-ID: 6CFEE8872EC5817646-01-01
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Return-Path: <cgd@broadcom.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: 5370
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: cgd@broadcom.com
Precedence: bulk
X-list: linux-mips

personally, i'd make the comment on the 'break' testcase in mips32.s a bit
clearer and more explicit.  e.g. "for a while, break for mips32 
took a 20 bit code.  But that was incompatible and caused problems, so
now it's back to the old 10 bit code, or two comma-separated 10 bit codes."

Otherwise, people might look and say "huh?"


chris


From macro@linux-mips.org Mon Jun 28 16:36:31 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 28 Jun 2004 16:36:35 +0100 (BST)
Received: from jurand.ds.pg.gda.pl ([IPv6:::ffff:153.19.208.2]:900 "EHLO
	jurand.ds.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8225428AbUF1Pgb>; Mon, 28 Jun 2004 16:36:31 +0100
Received: by jurand.ds.pg.gda.pl (Postfix, from userid 1011)
	id 133B749D0A; Mon, 28 Jun 2004 17:36:24 +0200 (CEST)
Received: from localhost (localhost [127.0.0.1])
	by jurand.ds.pg.gda.pl (Postfix) with ESMTP
	id F34AA47C5C; Mon, 28 Jun 2004 17:36:24 +0200 (CEST)
Date: Mon, 28 Jun 2004 17:36:24 +0200 (CEST)
From: "Maciej W. Rozycki" <macro@linux-mips.org>
To: cgd@broadcom.com
Cc: binutils@sources.redhat.com, ddaney@avtrex.com,
	linux-mips@linux-mips.org, ralf@linux-mips.org, rsandifo@redhat.com
Subject: Re: [Patch]  / 0 should send SIGFPE not SIGTRAP...
In-Reply-To: <200406281519.IAA29663@mail-sj1-2.sj.broadcom.com>
Message-ID: <Pine.LNX.4.55.0406281734560.23162@jurand.ds.pg.gda.pl>
References: <200406281519.IAA29663@mail-sj1-2.sj.broadcom.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <macro@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: 5371
X-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@linux-mips.org
Precedence: bulk
X-list: linux-mips

On Mon, 28 Jun 2004 cgd@broadcom.com wrote:

> personally, i'd make the comment on the 'break' testcase in mips32.s a bit
> clearer and more explicit.  e.g. "for a while, break for mips32 
> took a 20 bit code.  But that was incompatible and caused problems, so
> now it's back to the old 10 bit code, or two comma-separated 10 bit codes."

 No problem.

> Otherwise, people might look and say "huh?"

 ;-)

From ralf@linux-mips.org Tue Jun 29 00:59:09 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 29 Jun 2004 00:59:14 +0100 (BST)
Received: from p508B7E89.dip.t-dialin.net ([IPv6:::ffff:80.139.126.137]:13334
	"EHLO mail.linux-mips.net") by linux-mips.org with ESMTP
	id <S8224914AbUF1X7J>; Tue, 29 Jun 2004 00:59:09 +0100
Received: from fluff.linux-mips.net (fluff.linux-mips.net [127.0.0.1])
	by mail.linux-mips.net (8.12.11/8.12.8) with ESMTP id i5SNx8n8007443;
	Tue, 29 Jun 2004 01:59:08 +0200
Received: (from ralf@localhost)
	by fluff.linux-mips.net (8.12.11/8.12.11/Submit) id i5SNx8D0007442;
	Tue, 29 Jun 2004 01:59:08 +0200
Date: Tue, 29 Jun 2004 01:59:08 +0200
From: Ralf Baechle <ralf@linux-mips.org>
To: "Maciej W. Rozycki" <macro@linux-mips.org>
Cc: linux-mips@linux-mips.org
Subject: Re: [patch] Incorrect mapping of serial ports to lines
Message-ID: <20040628235908.GC5736@linux-mips.org>
References: <Pine.LNX.4.55.0406281513120.23162@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.0406281513120.23162@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: 5372
X-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, Jun 28, 2004 at 03:25:04PM +0200, Maciej W. Rozycki wrote:

>  Onboard PC-compatible serial ports of the 8250 family are expected to be
> assigned to lines 0 - 3.  Unfortunately for MIPS this is not guaranteed as
> EXTRA_SERIAL_PORT_DEFNS and HUB6_SERIAL_PORT_DFNS precede
> STD_SERIAL_PORT_DEFNS on the port list and their definitions change
> depending on CONFIG_SERIAL_MANY_PORTS and CONFIG_HUB6 which are user
> settable.  As a result, they may get different assignments depending on
> configuration -- e.g. my last build for the Malta board resulted in its
> onboard ports being assigned to lines 28 and 29.
> 
>  This can be fixed with a correct ordering of entries on the port list, 
> like the following.  OK to apply?

Yep, having STD_SERIAL_PORT_DEFNS after EXTRA_SERIAL_PORT_DEFNS was
unintentional.  The idea was to have to have all the system-specific at
the start of the list or we get fun on all system that may have on-board
serials which should receive the lowest numbers and any (E)ISA serial cards
at the end, so my suggestion for fixing this would look a little different:

#define SERIAL_PORT_DFNS                                \
        COBALT_SERIAL_PORT_DEFNS                        \
        DDB5477_SERIAL_PORT_DEFNS                       \
        EV96100_SERIAL_PORT_DEFNS                       \
        IP32_SERIAL_PORT_DEFNS                          \
        ITE_SERIAL_PORT_DEFNS                           \
        IVR_SERIAL_PORT_DEFNS                           \
        JAZZ_SERIAL_PORT_DEFNS                          \
        MOMENCO_OCELOT_G_SERIAL_PORT_DEFNS              \
        MOMENCO_OCELOT_C_SERIAL_PORT_DEFNS              \
        MOMENCO_OCELOT_SERIAL_PORT_DEFNS                \
        TXX927_SERIAL_PORT_DEFNS                        \
        AU1000_SERIAL_PORT_DEFNS			\
							\
        STD_SERIAL_PORT_DEFNS                           \
	EXTRA_SERIAL_PORT_DEFNS				\
        HUB6_SERIAL_PORT_DFNS                           \

Comments?

 Ralf

From taoyong2002cncq@yahoo.com.cn Tue Jun 29 02:16:17 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 29 Jun 2004 02:20:45 +0100 (BST)
Received: from smtp106.mail.sc5.yahoo.com ([IPv6:::ffff:66.163.169.226]:53438
	"HELO smtp106.mail.sc5.yahoo.com") by linux-mips.org with SMTP
	id <S8225739AbUF2BQR>; Tue, 29 Jun 2004 02:16:17 +0100
Received: from unknown (HELO ime?ty) (taoyong2002cncq@61.186.188.72 with login)
  by smtp106.mail.sc5.yahoo.com with SMTP; 29 Jun 2004 01:14:34 -0000
Date: Tue, 29 Jun 2004 09:14:31 +0800
From: "taoyong" <taoyong2002cncq@yahoo.com.cn>
Reply-To: taoyong2002cncq@yahoo.com.cn
To: "linux-mips" <linux-mips@linux-mips.org>
Subject: Onetouch Touchscreen RS232 driver in Hardhat Linux ?
Organization: cqu-swcims
X-mailer: Foxmail 5.0 beta2 [cn]
Mime-Version: 1.0
Content-Type: text/plain;
	charset="gb2312"
Content-Transfer-Encoding: 7bit
Message-Id: <20040629011617Z8225739-1530+4713@linux-mips.org>
Return-Path: <taoyong2002cncq@yahoo.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: 5373
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: taoyong2002cncq@yahoo.com.cn
Precedence: bulk
X-list: linux-mips

Hi linux-mips,
    
       We use the PB1000 board, and now need to add a touchscreen to the board. The touchscreen is Onetouch (RS232). We have got the driver in Linux ,which is for PC REDHAT Linux and XFree 86. The GUI we use  is Microwindows, we need to add the touchscreen to it. Have someone have the same experience? Would you please give me some advices?    





Best regards,

> Yong Tao 
> Insitute of Manufacture Engineering of Chongqing University,
> Chongqing,
> China 
> 400030
> tel:(+8623)65111224-108
>     (+86)13752931429





From jbglaw@dvmwest.gt.owl.de Tue Jun 29 07:19:48 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 29 Jun 2004 07:19:53 +0100 (BST)
Received: from dvmwest.gt.owl.de ([IPv6:::ffff:62.52.24.140]:60807 "EHLO
	dvmwest.gt.owl.de") by linux-mips.org with ESMTP
	id <S8225273AbUF2GTs>; Tue, 29 Jun 2004 07:19:48 +0100
Received: by dvmwest.gt.owl.de (Postfix, from userid 1001)
	id A88A34B802; Tue, 29 Jun 2004 08:19:46 +0200 (CEST)
Date: Tue, 29 Jun 2004 08:19:46 +0200
From: Jan-Benedict Glaw <jbglaw@lug-owl.de>
To: linux-mips <linux-mips@linux-mips.org>
Subject: Re: Onetouch Touchscreen RS232 driver in Hardhat Linux ?
Message-ID: <20040629061946.GI20632@lug-owl.de>
Mail-Followup-To: linux-mips <linux-mips@linux-mips.org>
References: <20040629011617Z8225739-1530+4713@linux-mips.org>
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="6MpC4B+GiwQmKOrv"
Content-Disposition: inline
In-Reply-To: <20040629011617Z8225739-1530+4713@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.6i
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: 5374
X-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


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

On Tue, 2004-06-29 09:14:31 +0800, taoyong <taoyong2002cncq@yahoo.com.cn>
wrote in message <20040629011617Z8225739-1530+4713@linux-mips.org>:
> Hi linux-mips,
>    =20
>        We use the PB1000 board, and now need to add a touchscreen
> to the board. The touchscreen is Onetouch (RS232). We have got the
> driver in Linux ,which is for PC REDHAT Linux and XFree 86. The GUI
> we use  is Microwindows, we need to add the touchscreen to it. Have
> someone have the same experience? Would you please give me some
> advices?
[Please limit line length to about 70 chars to save *me* time for
reformatting, thanks]

Well, googling for it revealed there's source code for the driver
available, eg. at ftp://ftp.gnudd.com/pub/onetouch/onetouch-1.2.tar.gz .

However, if your vendor is only smart enough to point you to binaries,
you'd probably think about using another product for your application.

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));

--6MpC4B+GiwQmKOrv
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)

iD8DBQFA4QoCHb1edYOZ4bsRAohCAJ9LsLU57BJvLckOyzK4i7lkzP0gFgCfbXmm
VMq5KbgFqzwU7x4BdXRq/6o=
=j1Of
-----END PGP SIGNATURE-----

--6MpC4B+GiwQmKOrv--

From vksavl@cityline.ru Tue Jun 29 09:12:52 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 29 Jun 2004 09:12:56 +0100 (BST)
Received: from barbuda.mtu.ru ([IPv6:::ffff:195.34.32.115]:45323 "EHLO
	Hueymiccailhuitl.MTU.ru") by linux-mips.org with ESMTP
	id <S8225464AbUF2IMw>; Tue, 29 Jun 2004 09:12:52 +0100
Received: from ppp153-29.dialup.mtu-net.ru (ppp153-29.dialup.mtu-net.ru [62.118.153.29])
	by Hueymiccailhuitl.MTU.ru (Postfix) with ESMTP id 2007817EDE1
	for <linux-mips@linux-mips.org>; Tue, 29 Jun 2004 12:12:48 +0400 (MSD)
	(envelope-from vksavl@cityline.ru)
Date: Tue, 29 Jun 2004 12:13:10 +0400
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: <18410893433.20040629121310@cityline.ru>
To: linux-mips <linux-mips@linux-mips.org>
Subject: JTAG on BCM94704
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: 5375
X-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

Hello linux-mips,
Can anybody recommend me ICE probe suitable for JTAG debugging of Broadcom BCM94704CPCI target (BCM4704 chip)?
-- 
Thanks,
 Pavel Kiryukhin
                           mailto:vksavl@cityline.ru


From wd@denx.de Tue Jun 29 11:33:37 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 29 Jun 2004 11:33:41 +0100 (BST)
Received: from mailout09.sul.t-online.com ([IPv6:::ffff:194.25.134.84]:20689
	"EHLO mailout09.sul.t-online.com") by linux-mips.org with ESMTP
	id <S8225535AbUF2Kdh>; Tue, 29 Jun 2004 11:33:37 +0100
Received: from fwd07.aul.t-online.de 
	by mailout09.sul.t-online.com with smtp 
	id 1BfFXq-000120-03; Tue, 29 Jun 2004 12:08:54 +0200
Received: from denx.de (bLi0b6Zc8e60QnoWmM4anoPnkCp87-+hmjbZBtS7Eh9r8dn0gries6@[217.235.227.93]) by fmrl07.sul.t-online.com
	with esmtp id 1BfFWM-1mJMQK0; Tue, 29 Jun 2004 12:07:22 +0200
Received: from atlas.denx.de (atlas.denx.de [10.0.0.14])
	by denx.de (Postfix) with ESMTP
	id A2737424CC; Tue, 29 Jun 2004 12:07:21 +0200 (MEST)
Received: by atlas.denx.de (Postfix, from userid 15)
	id A7A8BC109F; Tue, 29 Jun 2004 12:07:13 +0200 (MEST)
Received: from atlas.denx.de (localhost [127.0.0.1])
	by atlas.denx.de (Postfix) with ESMTP
	id A5B8313D6E2; Tue, 29 Jun 2004 12:07:13 +0200 (MEST)
To: Pavel Kiryukhin <vksavl@cityline.ru>
Cc: linux-mips <linux-mips@linux-mips.org>
From: Wolfgang Denk <wd@denx.de>
Subject: Re: JTAG on BCM94704 
X-Mailer: exmh version 1.6.4 10/10/1995
Mime-version: 1.0
Content-type: text/plain; charset=ISO-8859-1
Content-transfer-encoding: 8bit
In-reply-to: Your message of "Tue, 29 Jun 2004 12:13:10 +0400."
             <18410893433.20040629121310@cityline.ru> 
Date: Tue, 29 Jun 2004 12:07:08 +0200
Message-Id: <20040629100713.A7A8BC109F@atlas.denx.de>
X-Seen: false
X-ID: bLi0b6Zc8e60QnoWmM4anoPnkCp87-+hmjbZBtS7Eh9r8dn0gries6@t-dialin.net
Return-Path: <wd@denx.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: 5376
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: wd@denx.de
Precedence: bulk
X-list: linux-mips

In message <18410893433.20040629121310@cityline.ru> you wrote:
>
> Can anybody recommend me ICE probe suitable for JTAG debugging of Broadcom BCM94704CPCI target (BCM4704 chip)?

Abatron BDI2000

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
Things that try to look like things often do look  more  like  things
than things. Well-known fact.       - Terry Pratchett, _Wyrd Sisters_

From macro@linux-mips.org Tue Jun 29 12:57:41 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 29 Jun 2004 12:57:45 +0100 (BST)
Received: from jurand.ds.pg.gda.pl ([IPv6:::ffff:153.19.208.2]:35221 "EHLO
	jurand.ds.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8225203AbUF2L5l>; Tue, 29 Jun 2004 12:57:41 +0100
Received: by jurand.ds.pg.gda.pl (Postfix, from userid 1011)
	id 5DB37475C1; Tue, 29 Jun 2004 13:57:34 +0200 (CEST)
Received: from localhost (localhost [127.0.0.1])
	by jurand.ds.pg.gda.pl (Postfix) with ESMTP
	id 4AAF7474EF; Tue, 29 Jun 2004 13:57:34 +0200 (CEST)
Date: Tue, 29 Jun 2004 13:57:34 +0200 (CEST)
From: "Maciej W. Rozycki" <macro@linux-mips.org>
To: Ralf Baechle <ralf@linux-mips.org>
Cc: linux-mips@linux-mips.org
Subject: Re: [patch] Incorrect mapping of serial ports to lines
In-Reply-To: <20040628235908.GC5736@linux-mips.org>
Message-ID: <Pine.LNX.4.55.0406291345590.31801@jurand.ds.pg.gda.pl>
References: <Pine.LNX.4.55.0406281513120.23162@jurand.ds.pg.gda.pl>
 <20040628235908.GC5736@linux-mips.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <macro@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: 5377
X-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@linux-mips.org
Precedence: bulk
X-list: linux-mips

On Tue, 29 Jun 2004, Ralf Baechle wrote:

> Yep, having STD_SERIAL_PORT_DEFNS after EXTRA_SERIAL_PORT_DEFNS was
> unintentional.  The idea was to have to have all the system-specific at
> the start of the list or we get fun on all system that may have on-board
> serials which should receive the lowest numbers and any (E)ISA serial cards
> at the end, so my suggestion for fixing this would look a little different:
> 
> #define SERIAL_PORT_DFNS                                \
>         COBALT_SERIAL_PORT_DEFNS                        \
>         DDB5477_SERIAL_PORT_DEFNS                       \
>         EV96100_SERIAL_PORT_DEFNS                       \
>         IP32_SERIAL_PORT_DEFNS                          \
>         ITE_SERIAL_PORT_DEFNS                           \
>         IVR_SERIAL_PORT_DEFNS                           \
>         JAZZ_SERIAL_PORT_DEFNS                          \
>         MOMENCO_OCELOT_G_SERIAL_PORT_DEFNS              \
>         MOMENCO_OCELOT_C_SERIAL_PORT_DEFNS              \
>         MOMENCO_OCELOT_SERIAL_PORT_DEFNS                \
>         TXX927_SERIAL_PORT_DEFNS                        \
>         AU1000_SERIAL_PORT_DEFNS			\

 Hmm, why is Au1000 at the end -- does the system have others from the
list above, too?

 Also you've removed a few system-specific ports -- why?

> 							\
>         STD_SERIAL_PORT_DEFNS                           \
> 	EXTRA_SERIAL_PORT_DEFNS				\
>         HUB6_SERIAL_PORT_DFNS                           \
> 
> Comments?

 That's a bit troublesome for the Malta board which has both a pair of
PC-compatible serial ports which are expected to be lines 0 and 1 and an
Atlas serial port, which is expected to be line 2.  The Atlas port on the
Malta board isn't handled by Linux right now, but I plan to fix it.  Are
there systems that have both PC-compatible ports and system-specific ones
and expect them to be mapped in the reverse order?

 AFAIK, PC-compatible serial ports on PCI cards get mapped dynamically to
lines above this standard list.  I don't know about EISA boards, but it
would be consistent to handle them the same way, i.e. I'd propose to fix
the driver in this case.

  Maciej

From geert@linux-m68k.org Tue Jun 29 13:09:46 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 29 Jun 2004 13:09:50 +0100 (BST)
Received: from witte.sonytel.be ([IPv6:::ffff:80.88.33.193]:7138 "EHLO
	witte.sonytel.be") by linux-mips.org with ESMTP id <S8225203AbUF2MJq>;
	Tue, 29 Jun 2004 13:09:46 +0100
Received: from waterleaf.sonytel.be (localhost [127.0.0.1])
	by witte.sonytel.be (8.12.10/8.12.10) with ESMTP id i5TC9bXK016761;
	Tue, 29 Jun 2004 14:09:37 +0200 (MEST)
Date: Tue, 29 Jun 2004 14:09:36 +0200 (MEST)
From: Geert Uytterhoeven <geert@linux-m68k.org>
To: "Maciej W. Rozycki" <macro@linux-mips.org>
cc: Ralf Baechle <ralf@linux-mips.org>,
	Linux/MIPS Development <linux-mips@linux-mips.org>
Subject: Re: [patch] Incorrect mapping of serial ports to lines
In-Reply-To: <Pine.LNX.4.55.0406291345590.31801@jurand.ds.pg.gda.pl>
Message-ID: <Pine.GSO.4.58.0406291408020.29058@waterleaf.sonytel.be>
References: <Pine.LNX.4.55.0406281513120.23162@jurand.ds.pg.gda.pl>
 <20040628235908.GC5736@linux-mips.org> <Pine.LNX.4.55.0406291345590.31801@jurand.ds.pg.gda.pl>
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: 5378
X-ecartis-version: Ecartis v1.0.0
Sender: linux-mips-bounce@linux-mips.org
Errors-to: linux-mips-bounce@linux-mips.org
X-original-sender: geert@linux-m68k.org
Precedence: bulk
X-list: linux-mips

On Tue, 29 Jun 2004, Maciej W. Rozycki wrote:
>  That's a bit troublesome for the Malta board which has both a pair of
> PC-compatible serial ports which are expected to be lines 0 and 1 and an
> Atlas serial port, which is expected to be line 2.  The Atlas port on the
> Malta board isn't handled by Linux right now, but I plan to fix it.  Are
> there systems that have both PC-compatible ports and system-specific ones
> and expect them to be mapped in the reverse order?

The NEC DDB Vrc-5074 (and probably the other DDB variants as well) has one
serial port in the Nile 4 host bridge, and 2 serial ports in the Super I/O.

To me it sounds the most logical if the one in the Nile 4 is ttyS0.

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 ladis@linux-mips.org Tue Jun 29 14:42:25 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 29 Jun 2004 14:42:29 +0100 (BST)
Received: from smtp.seznam.cz ([IPv6:::ffff:212.80.76.43]:6548 "HELO
	smtp.seznam.cz") by linux-mips.org with SMTP id <S8225551AbUF2NmZ>;
	Tue, 29 Jun 2004 14:42:25 +0100
Received: (qmail 306 invoked from network); 29 Jun 2004 13:42:13 -0000
Received: from unknown (HELO umax645sx) (Ladislav.Michl@160.218.40.4)
  by smtp.seznam.cz with SMTP; 29 Jun 2004 13:42:13 -0000
Received: from ladis by umax645sx with local (Exim 3.36 #1 (Debian))
	id 1BfIsJ-0000nK-00; Tue, 29 Jun 2004 15:42:15 +0200
Date: Tue, 29 Jun 2004 15:42:14 +0200
To: Linux MIPS <linux-mips@linux-mips.org>
Cc: Jorik Jonker <linux-mips@boeventronie.net>
Subject: Re: VINO
Message-ID: <20040629134213.GA2968@umax645sx>
References: <20040608125437.GC19965@hydrogen.boeventronie.net> <20040608220604.GA2578@umax645sx> <20040609122046.GB18364@hydrogen.boeventronie.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20040609122046.GB18364@hydrogen.boeventronie.net>
User-Agent: Mutt/1.5.6+20040523i
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: 5379
X-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 Wed, Jun 09, 2004 at 02:20:46PM +0200, Jorik Jonker wrote:
> Well, it seems not that easy for me. As I told, it's very opaque matter to
> me; ie I already figured out that a kernel driver must be built but I really
> have no clue on how to do this. For instance, I don't know what call (if
> there exists any) should access that memory.

PHYS_TO_K1 macro from <sys/mips_addrspace.h> does the trick. Just use
something like:

#define VINO_BASE 0x00080000
unsigned int reg = * (unsigned int *) PHYS_TO_K1(VINO_BASE + ofs);

Note that VINO registers are 64bit, but only lower 32bits are relevant for
us (the only exception is valid bit in descriptor cache register, which
is not important in this case). Please refer to VINO Design
Specification for more details:
ftp://ftp.linux-mips.org/pub/linux/mips/doc/indy/vino/

> My plan was on writing a driver which allows me (through an ioctl to a special
> device) to read/write to the VINO registers. I think I saw a driver example
> in the DevDriver_PG which shows how to communicate through ioctl with
> userspace (or kernelspace, depends on how you look at it), but the part where
> I do the actual 'talking' to the VINO is matter I don't have any clue on how
> to do that.

I hope you'll find time to make your plan reality.

Best regars,
	ladis

From macro@linux-mips.org Tue Jun 29 14:49:17 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 29 Jun 2004 14:49:21 +0100 (BST)
Received: from jurand.ds.pg.gda.pl ([IPv6:::ffff:153.19.208.2]:33190 "EHLO
	jurand.ds.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8225551AbUF2NtR>; Tue, 29 Jun 2004 14:49:17 +0100
Received: by jurand.ds.pg.gda.pl (Postfix, from userid 1011)
	id F2834474EF; Tue, 29 Jun 2004 15:49:11 +0200 (CEST)
Received: from localhost (localhost [127.0.0.1])
	by jurand.ds.pg.gda.pl (Postfix) with ESMTP
	id DFA2947485; Tue, 29 Jun 2004 15:49:11 +0200 (CEST)
Date: Tue, 29 Jun 2004 15:49:11 +0200 (CEST)
From: "Maciej W. Rozycki" <macro@linux-mips.org>
To: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Ralf Baechle <ralf@linux-mips.org>,
	Linux/MIPS Development <linux-mips@linux-mips.org>
Subject: Re: [patch] Incorrect mapping of serial ports to lines
In-Reply-To: <Pine.GSO.4.58.0406291408020.29058@waterleaf.sonytel.be>
Message-ID: <Pine.LNX.4.55.0406291546480.31801@jurand.ds.pg.gda.pl>
References: <Pine.LNX.4.55.0406281513120.23162@jurand.ds.pg.gda.pl>
 <20040628235908.GC5736@linux-mips.org> <Pine.LNX.4.55.0406291345590.31801@jurand.ds.pg.gda.pl>
 <Pine.GSO.4.58.0406291408020.29058@waterleaf.sonytel.be>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <macro@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: 5380
X-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@linux-mips.org
Precedence: bulk
X-list: linux-mips

On Tue, 29 Jun 2004, Geert Uytterhoeven wrote:

> The NEC DDB Vrc-5074 (and probably the other DDB variants as well) has one
> serial port in the Nile 4 host bridge, and 2 serial ports in the Super I/O.
> 
> To me it sounds the most logical if the one in the Nile 4 is ttyS0.

 Then we need to find a way to make the order configurable somehow.

From ralf@linux-mips.org Tue Jun 29 16:03:21 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 29 Jun 2004 16:03:26 +0100 (BST)
Received: from p508B7BFA.dip.t-dialin.net ([IPv6:::ffff:80.139.123.250]:8992
	"EHLO mail.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225733AbUF2PDV>; Tue, 29 Jun 2004 16:03:21 +0100
Received: from fluff.linux-mips.net (fluff.linux-mips.net [127.0.0.1])
	by mail.linux-mips.net (8.12.11/8.12.8) with ESMTP id i5TF3I8T026014;
	Tue, 29 Jun 2004 17:03:18 +0200
Received: (from ralf@localhost)
	by fluff.linux-mips.net (8.12.11/8.12.11/Submit) id i5TF3H4M026013;
	Tue, 29 Jun 2004 17:03:17 +0200
Date: Tue, 29 Jun 2004 17:03:16 +0200
From: Ralf Baechle <ralf@linux-mips.org>
To: "Maciej W. Rozycki" <macro@linux-mips.org>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>,
	Linux/MIPS Development <linux-mips@linux-mips.org>
Subject: Re: [patch] Incorrect mapping of serial ports to lines
Message-ID: <20040629150316.GB23741@linux-mips.org>
References: <Pine.LNX.4.55.0406281513120.23162@jurand.ds.pg.gda.pl> <20040628235908.GC5736@linux-mips.org> <Pine.LNX.4.55.0406291345590.31801@jurand.ds.pg.gda.pl> <Pine.GSO.4.58.0406291408020.29058@waterleaf.sonytel.be> <Pine.LNX.4.55.0406291546480.31801@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.0406291546480.31801@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: 5381
X-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, Jun 29, 2004 at 03:49:11PM +0200, Maciej W. Rozycki wrote:
> Date: Tue, 29 Jun 2004 15:49:11 +0200 (CEST)
> From: "Maciej W. Rozycki" <macro@linux-mips.org>
> To: Geert Uytterhoeven <geert@linux-m68k.org>
> Cc: Ralf Baechle <ralf@linux-mips.org>,
> 	Linux/MIPS Development <linux-mips@linux-mips.org>
> Subject: Re: [patch] Incorrect mapping of serial ports to lines
> Content-Type: TEXT/PLAIN; charset=US-ASCII
> 
> On Tue, 29 Jun 2004, Geert Uytterhoeven wrote:
> 
> > The NEC DDB Vrc-5074 (and probably the other DDB variants as well) has one
> > serial port in the Nile 4 host bridge, and 2 serial ports in the Super I/O.
> > 
> > To me it sounds the most logical if the one in the Nile 4 is ttyS0.
> 
>  Then we need to find a way to make the order configurable somehow.

How about you leave CONFIG_HAVE_STD_PC_SERIAL_PORT disabled for Malta then
and supply your own MALTA_SERIAL_PORT_DEFNS instead then?  That would
require some small changes to no longer nest the CONFIG_SERIAL_MANY_PORTS
ifdef inside CONFIG_HAVE_STD_PC_SERIAL_PORT - about as below.

  Ralf

Index: include/asm-mips/serial.h
===================================================================
RCS file: /home/cvs/linux/include/asm-mips/serial.h,v
retrieving revision 1.23.2.18
diff -u -r1.23.2.18 serial.h
--- include/asm-mips/serial.h	18 Dec 2003 01:51:37 -0000	1.23.2.18
+++ include/asm-mips/serial.h	29 Jun 2004 14:56:06 -0000
@@ -184,6 +184,18 @@
 #define TXX927_SERIAL_PORT_DEFNS
 #endif
 
+#ifdef CONFIG_MIPS_MALTA
+#define MALTA_SERIAL_PORT_DEFNS			\
+	/* UART CLK   PORT IRQ     FLAGS        */			\
+	{ 0, BASE_BAUD, 0x3F8, 4, STD_COM_FLAGS },	/* ttyS0 */	\
+	{ 0, BASE_BAUD, 0x2F8, 3, STD_COM_FLAGS },	/* ttyS1 */	\
+	{ ...  extra Malta blurb goes here },		/* ttyS2 */	\
+	{ ...  extra Malta blurb goes here },		/* ttyS3 */	\
+
+#else /* CONFIG_MIPS_MALTA */
+#define MALTA_SERIAL_PORT_DEFNS
+#endif /* CONFIG_MIPS_MALTA */
+
 #ifdef CONFIG_HAVE_STD_PC_SERIAL_PORT
 #define STD_SERIAL_PORT_DEFNS			\
 	/* UART CLK   PORT IRQ     FLAGS        */			\
@@ -192,6 +204,10 @@
 	{ 0, BASE_BAUD, 0x3E8, 4, STD_COM_FLAGS },	/* ttyS2 */	\
 	{ 0, BASE_BAUD, 0x2E8, 3, STD_COM4_FLAGS },	/* ttyS3 */
 
+#else /* CONFIG_HAVE_STD_PC_SERIAL_PORTS */
+#define STD_SERIAL_PORT_DEFNS
+#endif /* CONFIG_HAVE_STD_PC_SERIAL_PORTS */
+
 #ifdef CONFIG_SERIAL_MANY_PORTS
 #define EXTRA_SERIAL_PORT_DEFNS			\
 	{ 0, BASE_BAUD, 0x1A0, 9, FOURPORT_FLAGS }, 	/* ttyS4 */	\
@@ -226,11 +242,6 @@
 #define EXTRA_SERIAL_PORT_DEFNS
 #endif /* CONFIG_SERIAL_MANY_PORTS */
 
-#else /* CONFIG_HAVE_STD_PC_SERIAL_PORTS */
-#define STD_SERIAL_PORT_DEFNS
-#define EXTRA_SERIAL_PORT_DEFNS
-#endif /* CONFIG_HAVE_STD_PC_SERIAL_PORTS */
-
 /* You can have up to four HUB6's in the system, but I've only
  * included two cards here for a total of twelve ports.
  */
@@ -416,18 +427,20 @@
 	COBALT_SERIAL_PORT_DEFNS		\
 	DDB5477_SERIAL_PORT_DEFNS		\
 	EV96100_SERIAL_PORT_DEFNS		\
-	EXTRA_SERIAL_PORT_DEFNS			\
-	HUB6_SERIAL_PORT_DFNS			\
 	ITE_SERIAL_PORT_DEFNS           	\
 	IVR_SERIAL_PORT_DEFNS           	\
 	JAZZ_SERIAL_PORT_DEFNS			\
+	MALTA_SERIAL_PORT_DEFNS			\
 	MOMENCO_OCELOT_SERIAL_PORT_DEFNS	\
 	MOMENCO_OCELOT_G_SERIAL_PORT_DEFNS	\
 	MOMENCO_OCELOT_C_SERIAL_PORT_DEFNS	\
 	MOMENCO_JAGUAR_ATX_SERIAL_PORT_DEFNS	\
 	SEAD_SERIAL_PORT_DEFNS			\
-	STD_SERIAL_PORT_DEFNS			\
 	TITAN_SERIAL_PORT_DEFNS			\
-	TXX927_SERIAL_PORT_DEFNS
+	TXX927_SERIAL_PORT_DEFNS		\
+						\
+	STD_SERIAL_PORT_DEFNS			\
+	EXTRA_SERIAL_PORT_DEFNS			\
+	HUB6_SERIAL_PORT_DFNS			\
 
 #endif /* _ASM_SERIAL_H */

From jsun@mvista.com Tue Jun 29 23:13:22 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 29 Jun 2004 23:13:26 +0100 (BST)
Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:56307 "EHLO
	orion.mvista.com") by linux-mips.org with ESMTP id <S8225800AbUF2WNW>;
	Tue, 29 Jun 2004 23:13:22 +0100
Received: from orion.mvista.com (localhost.localdomain [127.0.0.1])
	by orion.mvista.com (8.12.8/8.12.8) with ESMTP id i5TMDE4O010296;
	Tue, 29 Jun 2004 15:13:14 -0700
Received: (from jsun@localhost)
	by orion.mvista.com (8.12.8/8.12.8/Submit) id i5TMDDjY010295;
	Tue, 29 Jun 2004 15:13:13 -0700
Date: Tue, 29 Jun 2004 15:13:13 -0700
From: Jun Sun <jsun@mvista.com>
To: "Maciej W. Rozycki" <macro@linux-mips.org>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>,
	Ralf Baechle <ralf@linux-mips.org>,
	Linux/MIPS Development <linux-mips@linux-mips.org>,
	jsun@mvista.com
Subject: Re: [patch] Incorrect mapping of serial ports to lines
Message-ID: <20040629151313.E6498@mvista.com>
References: <Pine.LNX.4.55.0406281513120.23162@jurand.ds.pg.gda.pl> <20040628235908.GC5736@linux-mips.org> <Pine.LNX.4.55.0406291345590.31801@jurand.ds.pg.gda.pl> <Pine.GSO.4.58.0406291408020.29058@waterleaf.sonytel.be> <Pine.LNX.4.55.0406291546480.31801@jurand.ds.pg.gda.pl>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <Pine.LNX.4.55.0406291546480.31801@jurand.ds.pg.gda.pl>; from macro@linux-mips.org on Tue, Jun 29, 2004 at 03:49:11PM +0200
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: 5382
X-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, Jun 29, 2004 at 03:49:11PM +0200, Maciej W. Rozycki wrote:
> On Tue, 29 Jun 2004, Geert Uytterhoeven wrote:
> 
> > The NEC DDB Vrc-5074 (and probably the other DDB variants as well) has one
> > serial port in the Nile 4 host bridge, and 2 serial ports in the Super I/O.
> > 
> > To me it sounds the most logical if the one in the Nile 4 is ttyS0.
> 
>  Then we need to find a way to make the order configurable somehow.

This is why I favor run-time serial port configuration.  My view
(maybe a little dramatic) is to remove all static serial port definition
and push them into board setup routine.  asm/serial.h only needs
to define the number serial lines, which itself could be configurable.

Jun

From macro@linux-mips.org Tue Jun 29 23:43:54 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 29 Jun 2004 23:43:58 +0100 (BST)
Received: from jurand.ds.pg.gda.pl ([IPv6:::ffff:153.19.208.2]:42651 "EHLO
	jurand.ds.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8225800AbUF2Wnx>; Tue, 29 Jun 2004 23:43:53 +0100
Received: by jurand.ds.pg.gda.pl (Postfix, from userid 1011)
	id A40CB3E6; Wed, 30 Jun 2004 00:43:47 +0200 (CEST)
Received: from localhost (localhost [127.0.0.1])
	by jurand.ds.pg.gda.pl (Postfix) with ESMTP
	id 938B4316; Wed, 30 Jun 2004 00:43:47 +0200 (CEST)
Date: Wed, 30 Jun 2004 00:43:47 +0200 (CEST)
From: "Maciej W. Rozycki" <macro@linux-mips.org>
To: Jun Sun <jsun@mvista.com>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>,
	Ralf Baechle <ralf@linux-mips.org>,
	Linux/MIPS Development <linux-mips@linux-mips.org>
Subject: Re: [patch] Incorrect mapping of serial ports to lines
In-Reply-To: <20040629151313.E6498@mvista.com>
Message-ID: <Pine.LNX.4.55.0406300022290.31801@jurand.ds.pg.gda.pl>
References: <Pine.LNX.4.55.0406281513120.23162@jurand.ds.pg.gda.pl>
 <20040628235908.GC5736@linux-mips.org> <Pine.LNX.4.55.0406291345590.31801@jurand.ds.pg.gda.pl>
 <Pine.GSO.4.58.0406291408020.29058@waterleaf.sonytel.be>
 <Pine.LNX.4.55.0406291546480.31801@jurand.ds.pg.gda.pl> <20040629151313.E6498@mvista.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <macro@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: 5383
X-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@linux-mips.org
Precedence: bulk
X-list: linux-mips

On Tue, 29 Jun 2004, Jun Sun wrote:

> This is why I favor run-time serial port configuration.  My view

 Well, that's certainly a reasonable long-time strategy.

> (maybe a little dramatic) is to remove all static serial port definition
> and push them into board setup routine.  asm/serial.h only needs

 I'm not sure that is the right way of doing it -- note that one problem
is serial drivers can be built as modules and inserted at the run time.

 I haven't looked into the serial I/O subsystem of 2.6, yet, so I don't
know if it offers any support for different wirings of the same U(S)ART.  
In theory I think the most reasonable approach it would be to provide
system-specific frontends to a generic backend for a given U(S)ART (like
an 8250-compatible).  The frontends would handle address mapping, DMA if
available, etc. and be a way to deal with system-specific quirks.

> to define the number serial lines, which itself could be configurable.

 I don't think there needs to be any arbitrary limit here.  With hot-plug
PCI and similar setups ports can appear and disappear from a system at any
time, so the associated resources should be allocated dynamically anyway.

  Maciej

From ralf@linux-mips.org Tue Jun 29 23:49:35 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 29 Jun 2004 23:49:39 +0100 (BST)
Received: from p508B7BFA.dip.t-dialin.net ([IPv6:::ffff:80.139.123.250]:35877
	"EHLO mail.linux-mips.net") by linux-mips.org with ESMTP
	id <S8225800AbUF2Wtf>; Tue, 29 Jun 2004 23:49:35 +0100
Received: from fluff.linux-mips.net (fluff.linux-mips.net [127.0.0.1])
	by mail.linux-mips.net (8.12.11/8.12.8) with ESMTP id i5TMnXO5011398;
	Wed, 30 Jun 2004 00:49:33 +0200
Received: (from ralf@localhost)
	by fluff.linux-mips.net (8.12.11/8.12.11/Submit) id i5TMnWFC011397;
	Wed, 30 Jun 2004 00:49:32 +0200
Date: Wed, 30 Jun 2004 00:49:32 +0200
From: Ralf Baechle <ralf@linux-mips.org>
To: Jun Sun <jsun@mvista.com>
Cc: "Maciej W. Rozycki" <macro@linux-mips.org>,
	Geert Uytterhoeven <geert@linux-m68k.org>,
	Linux/MIPS Development <linux-mips@linux-mips.org>
Subject: Re: [patch] Incorrect mapping of serial ports to lines
Message-ID: <20040629224932.GA10375@linux-mips.org>
References: <Pine.LNX.4.55.0406281513120.23162@jurand.ds.pg.gda.pl> <20040628235908.GC5736@linux-mips.org> <Pine.LNX.4.55.0406291345590.31801@jurand.ds.pg.gda.pl> <Pine.GSO.4.58.0406291408020.29058@waterleaf.sonytel.be> <Pine.LNX.4.55.0406291546480.31801@jurand.ds.pg.gda.pl> <20040629151313.E6498@mvista.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20040629151313.E6498@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: 5384
X-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, Jun 29, 2004 at 03:13:13PM -0700, Jun Sun wrote:

> > > The NEC DDB Vrc-5074 (and probably the other DDB variants as well) has one
> > > serial port in the Nile 4 host bridge, and 2 serial ports in the Super I/O.
> > > 
> > > To me it sounds the most logical if the one in the Nile 4 is ttyS0.
> > 
> >  Then we need to find a way to make the order configurable somehow.
> 
> This is why I favor run-time serial port configuration.  My view
> (maybe a little dramatic) is to remove all static serial port definition
> and push them into board setup routine.  asm/serial.h only needs
> to define the number serial lines, which itself could be configurable.

<asm/serial.h> is on it's way out of the kernel - it's only a question of
time until either the current maintainer of the serial driver or somebody
with more time at hands will eleminate it.  And serial.h was always only
meant to handle the kind of serial interfaces of which you just have to
know that they're there because probing for it isn't possible.  Something
which these days is getting increasingly more rare thanks to PCI.

What I really wouldn't like to see is the runtime registration for all
the legacy serial stuff that possibly could be plugged into some board
be duplicated into half a dozen of systems ...

  Ralf

From jsun@mvista.com Wed Jun 30 01:15:40 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 30 Jun 2004 01:15:45 +0100 (BST)
Received: from gateway-1237.mvista.com ([IPv6:::ffff:12.44.186.158]:31473 "EHLO
	orion.mvista.com") by linux-mips.org with ESMTP id <S8225260AbUF3APk>;
	Wed, 30 Jun 2004 01:15:40 +0100
Received: from orion.mvista.com (localhost.localdomain [127.0.0.1])
	by orion.mvista.com (8.12.8/8.12.8) with ESMTP id i5U0Fb4O011144;
	Tue, 29 Jun 2004 17:15:37 -0700
Received: (from jsun@localhost)
	by orion.mvista.com (8.12.8/8.12.8/Submit) id i5U0Fbnq011143;
	Tue, 29 Jun 2004 17:15:37 -0700
Date: Tue, 29 Jun 2004 17:15:37 -0700
From: Jun Sun <jsun@mvista.com>
To: Ralf Baechle <ralf@linux-mips.org>
Cc: "Maciej W. Rozycki" <macro@linux-mips.org>,
	Geert Uytterhoeven <geert@linux-m68k.org>,
	Linux/MIPS Development <linux-mips@linux-mips.org>,
	jsun@mvista.com
Subject: Re: [patch] Incorrect mapping of serial ports to lines
Message-ID: <20040629171537.F6498@mvista.com>
References: <Pine.LNX.4.55.0406281513120.23162@jurand.ds.pg.gda.pl> <20040628235908.GC5736@linux-mips.org> <Pine.LNX.4.55.0406291345590.31801@jurand.ds.pg.gda.pl> <Pine.GSO.4.58.0406291408020.29058@waterleaf.sonytel.be> <Pine.LNX.4.55.0406291546480.31801@jurand.ds.pg.gda.pl> <20040629151313.E6498@mvista.com> <20040629224932.GA10375@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: <20040629224932.GA10375@linux-mips.org>; from ralf@linux-mips.org on Wed, Jun 30, 2004 at 12:49:32AM +0200
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: 5385
X-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, Jun 30, 2004 at 12:49:32AM +0200, Ralf Baechle wrote:
> On Tue, Jun 29, 2004 at 03:13:13PM -0700, Jun Sun wrote:
> 
> > > > The NEC DDB Vrc-5074 (and probably the other DDB variants as well) has one
> > > > serial port in the Nile 4 host bridge, and 2 serial ports in the Super I/O.
> > > > 
> > > > To me it sounds the most logical if the one in the Nile 4 is ttyS0.
> > > 
> > >  Then we need to find a way to make the order configurable somehow.
> > 
> > This is why I favor run-time serial port configuration.  My view
> > (maybe a little dramatic) is to remove all static serial port definition
> > and push them into board setup routine.  asm/serial.h only needs
> > to define the number serial lines, which itself could be configurable.
> 
> <asm/serial.h> is on it's way out of the kernel - it's only a question of
> time until either the current maintainer of the serial driver or somebody
> with more time at hands will eleminate it.  And serial.h was always only
> meant to handle the kind of serial interfaces of which you just have to
> know that they're there because probing for it isn't possible.  Something
> which these days is getting increasingly more rare thanks to PCI.
> 
> What I really wouldn't like to see is the runtime registration for all
> the legacy serial stuff that possibly could be plugged into some board
> be duplicated into half a dozen of systems ...
> 

No fear really.  You can still provide STD_SERIAL_PORT in the asm/serial.h
where each individual board simply does a registration for each line
defined there.  You might even provide some inline function for 
doing so in asm/serial.h.

The big advantage of this scheme is that the board-level complexity is not 
exposed to MIPS arch layer.  So when it is time for a board to die, one
does not have to clean up a dozen or so common files like asm/serial.h file.

Of course it also offers complete control over the ordering of serial
ports to the board.

See arch/mips/vr4181/common/serial.c for a simple example of run-time
registeration.  I believe a couple of other boards are doing this too.

Jun

From geert@linux-m68k.org Wed Jun 30 09:07:14 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 30 Jun 2004 09:07:18 +0100 (BST)
Received: from witte.sonytel.be ([IPv6:::ffff:80.88.33.193]:15794 "EHLO
	witte.sonytel.be") by linux-mips.org with ESMTP id <S8225274AbUF3IHO>;
	Wed, 30 Jun 2004 09:07:14 +0100
Received: from waterleaf.sonytel.be (localhost [127.0.0.1])
	by witte.sonytel.be (8.12.10/8.12.10) with ESMTP id i5U87BXK012814;
	Wed, 30 Jun 2004 10:07:11 +0200 (MEST)
Date: Wed, 30 Jun 2004 10:07:11 +0200 (MEST)
From: Geert Uytterhoeven <geert@linux-m68k.org>
To: "Maciej W. Rozycki" <macro@linux-mips.org>
cc: Jun Sun <jsun@mvista.com>, Ralf Baechle <ralf@linux-mips.org>,
	Linux/MIPS Development <linux-mips@linux-mips.org>
Subject: Re: [patch] Incorrect mapping of serial ports to lines
In-Reply-To: <Pine.LNX.4.55.0406300022290.31801@jurand.ds.pg.gda.pl>
Message-ID: <Pine.GSO.4.58.0406301006340.20130@waterleaf.sonytel.be>
References: <Pine.LNX.4.55.0406281513120.23162@jurand.ds.pg.gda.pl>
 <20040628235908.GC5736@linux-mips.org> <Pine.LNX.4.55.0406291345590.31801@jurand.ds.pg.gda.pl>
 <Pine.GSO.4.58.0406291408020.29058@waterleaf.sonytel.be>
 <Pine.LNX.4.55.0406291546480.31801@jurand.ds.pg.gda.pl> <20040629151313.E6498@mvista.com>
 <Pine.LNX.4.55.0406300022290.31801@jurand.ds.pg.gda.pl>
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: 5386
X-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 Wed, 30 Jun 2004, Maciej W. Rozycki wrote:
> On Tue, 29 Jun 2004, Jun Sun wrote:
> > This is why I favor run-time serial port configuration.  My view
>
>  Well, that's certainly a reasonable long-time strategy.
>
> > (maybe a little dramatic) is to remove all static serial port definition
> > and push them into board setup routine.  asm/serial.h only needs
>
>  I'm not sure that is the right way of doing it -- note that one problem
> is serial drivers can be built as modules and inserted at the run time.

The same is true for whatever other type of device (SCSI, IDE, Ethernet, ...).
And depending on the order of module loading, the order of the devices will
change.

Gr{oetje,eeting}s,

						Geert

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

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

From macro@linux-mips.org Wed Jun 30 13:10:50 2004
Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 30 Jun 2004 13:10:54 +0100 (BST)
Received: from jurand.ds.pg.gda.pl ([IPv6:::ffff:153.19.208.2]:41673 "EHLO
	jurand.ds.pg.gda.pl") by linux-mips.org with ESMTP
	id <S8225456AbUF3MKt>; Wed, 30 Jun 2004 13:10:49 +0100
Received: by jurand.ds.pg.gda.pl (Postfix, from userid 1011)
	id 2EC824762F; Wed, 30 Jun 2004 14:10:43 +0200 (CEST)
Received: from localhost (localhost [127.0.0.1])
	by jurand.ds.pg.gda.pl (Postfix) with ESMTP
	id 1AF8E44CD0; Wed, 30 Jun 2004 14:10:43 +0200 (CEST)
Date: Wed, 30 Jun 2004 14:10:43 +0200 (CEST)
From: "Maciej W. Rozycki" <macro@linux-mips.org>
To: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Jun Sun <jsun@mvista.com>, Ralf Baechle <ralf@linux-mips.org>,
	Linux/MIPS Development <linux-mips@linux-mips.org>
Subject: Re: [patch] Incorrect mapping of serial ports to lines
In-Reply-To: <Pine.GSO.4.58.0406301006340.20130@waterleaf.sonytel.be>
Message-ID: <Pine.LNX.4.55.0406301408010.31801@jurand.ds.pg.gda.pl>
References: <Pine.LNX.4.55.0406281513120.23162@jurand.ds.pg.gda.pl>
 <20040628235908.GC5736@linux-mips.org> <Pine.LNX.4.55.0406291345590.31801@jurand.ds.pg.gda.pl>
 <Pine.GSO.4.58.0406291408020.29058@waterleaf.sonytel.be>
 <Pine.LNX.4.55.0406291546480.31801@jurand.ds.pg.gda.pl> <20040629151313.E6498@mvista.com>
 <Pine.LNX.4.55.0406300022290.31801@jurand.ds.pg.gda.pl>
 <Pine.GSO.4.58.0406301006340.20130@waterleaf.sonytel.be>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Return-Path: <macro@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: 5387
X-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@linux-mips.org
Precedence: bulk
X-list: linux-mips

On Wed, 30 Jun 2004, Geert Uytterhoeven wrote:

> > > (maybe a little dramatic) is to remove all static serial port definition
> > > and push them into board setup routine.  asm/serial.h only needs
> >
> >  I'm not sure that is the right way of doing it -- note that one problem
> > is serial drivers can be built as modules and inserted at the run time.
> 
> The same is true for whatever other type of device (SCSI, IDE, Ethernet, ...).

 Yes and sensible drivers handle it correctly.  A classical example is the 
8390.c Ethernet driver with its various frontends.

> And depending on the order of module loading, the order of the devices will
> change.

 And given the order is fully configurable, it's actually a good thing.

  Maciej