From owner-linux-mips@oss.sgi.com Tue Aug  1 01:44:48 2000
Received:  by oss.sgi.com id <S42321AbQHAIoi>;
	Tue, 1 Aug 2000 01:44:38 -0700
Received: from delta.ds2.pg.gda.pl ([153.19.144.1]:912 "EHLO
        delta.ds2.pg.gda.pl") by oss.sgi.com with ESMTP id <S42236AbQHAIoK>;
	Tue, 1 Aug 2000 01:44:10 -0700
Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id KAA08460;
	Tue, 1 Aug 2000 10:43:02 +0200 (MET DST)
Date:   Tue, 1 Aug 2000 10:42:59 +0200 (MET DST)
From:   "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To:     Dan Aizenstros <dan@vcubed.com>
cc:     linux-mips@oss.sgi.com
Subject: Re: Binutils-2.10
In-Reply-To: <3985FC8A.70E449C6@vcubed.com>
Message-ID: <Pine.GSO.3.96.1000801103259.7120A-100000@delta.ds2.pg.gda.pl>
Organization: Technical University of Gdansk
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing

On Mon, 31 Jul 2000, Dan Aizenstros wrote:

> Thanks for the help.  I was able to build binutils-2.10 after
> generating the headers as you described.

 Good.

> The reason I expect the patch to change generated files is
> because the normal make does not generate them and the files
> are included in the binutils-2.10.tar.bz2 file.  They are also
> in CVS.  Why are generated files in CVS or the binary distribution
> if you have to generate them?

 To save people the trouble many generated files are included by default. 
There is no need to regenerate them if respective sources remain unchanged
and they may need special tools.  They include Makefile.in, config.h.in,
aclocal.m4, Makefile, configure files, as well as .info files and sources
built by lex and yacc.

> I thought all I would have to do is a ./configure; make; make install

 All built sources are usually regenerated if needed during build (that's
true for most automake-generated Makefiles; for others, the maintainer has
to take care to place appropriate rules inti Makefiles himself).  You
might need to enable the maintainer mode for certain programs, though, as
someone already pointed out.

> after I applied the patches.  Maybe you could add the need to generate
> files on your binutils-2.10 web page.

 I am planning to release RPM packages -- all necessary bits are in spec
files.  I might add a separate note, though.

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


From owner-linux-mips@oss.sgi.com Tue Aug  1 16:57:12 2000
Received:  by oss.sgi.com id <S42332AbQHAX5C>;
	Tue, 1 Aug 2000 16:57:02 -0700
Received: from deliverator.sgi.com ([204.94.214.10]:46386 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S42236AbQHAX4a>;
	Tue, 1 Aug 2000 16:56:30 -0700
Received: from nodin.corp.sgi.com (nodin.corp.sgi.com [192.26.51.193]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id QAA20020
	for <linux-mips@oss.sgi.com>; Tue, 1 Aug 2000 16:48:18 -0700 (PDT)
	mail_from (jsun@mvista.com)
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by nodin.corp.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) via ESMTP id QAA44641 for <linux-mips@oss.sgi.com>; Tue, 1 Aug 2000 16:54:04 -0700 (PDT)
Received: from sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id QAA33429
	for <linux@engr.sgi.com>;
	Tue, 1 Aug 2000 16:52:32 -0700 (PDT)
	mail_from (jsun@mvista.com)
Received: from hermes.mvista.com (gateway-490.mvista.com [63.192.220.206]) 
	by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam:
       SGI does not authorize the use of its proprietary
       systems or networks for unsolicited or bulk email
       from the Internet.) 
	via ESMTP id QAA03734
	for <linux@engr.sgi.com>; Tue, 1 Aug 2000 16:52:31 -0700 (PDT)
	mail_from (jsun@mvista.com)
Received: from mvista.com (IDENT:jsun@orion.mvista.com [10.0.0.75])
	by hermes.mvista.com (8.9.3/8.9.3) with ESMTP id QAA12032;
	Tue, 1 Aug 2000 16:52:26 -0700
Message-ID: <398762B9.D8507860@mvista.com>
Date:   Tue, 01 Aug 2000 16:52:25 -0700
From:   Jun Sun <jsun@mvista.com>
X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.12-20b i586)
X-Accept-Language: en
MIME-Version: 1.0
To:     linux@cthulhu.engr.sgi.com, linux-mips@fnet.fr, ralf@oss.sgi.com
Subject: PROPOSAL : multi-way cache support in Linux/MIPS
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing

Ralf,

I have got NEC DDB5476 running stable enough that I am comfortable to
check in
my code.  Will you take it?

Assuming the answer is yes, there are several issues regarding checking
in.
I will bring them up one by one.

The first issue is multi-way cache support.  DDB5476 uses R5432 CPU
which
has two-way set-associative cache.  The problematic part is the
index-based cache operations in r4xxcache.h does not cover all ways in a
set.

I think this is a problem in general.  So far I have seen MIPS
processors with
2-way, 4-way and 8-way sets.  And I have seen them using ether least-
significant-addressing-bits or most-significant-addressing-bits
within a cache line to select ways.

Here is my proposal :

. introduce two variables,
        cache_num_ways - number of ways in a set
        cache_way_selection_offset - the offset added to the address to
select
                next cache line in the same set.  For LSBs addressing,
it is
                equal to 1.  For MSBs addressing, it is equal to
                cache_line_size / cache_num_ways.  (It can potentially
take
                care of some future weired way-selection scheme as long
as
                the offset is uniform)

. These variables are initialized in cpu_probe().

  (Alternatively, I think we should have cpu_info table, that contains
all
   these cpu information.  Then a general routine can fill in the based
on
   the cpu id.  This can get rid of a bunch of ugly switch/case
statements.)

. in the include/asm/r4kcache.h file, all Index-based cache operation
needs
  to changed like the following (for illustration only; need
optimization) :

-----
        while(start < end) {
                cache16_unroll32(start,Index_Writeback_Inv_D);
                start += 0x200;
        }
+++++
        while(start < end) {
                for (i=0; i< cache_num_ways; i++) {
                        cache16_unroll32(start +
i*cache_way_selection_offset,
                                         Index_Writeback_Inv_D);
                }
                start += 0x200;
        }
=====

What do you think?  If it is OK, I can do the patch.  The cpu_info table
is a nice wish, but I don't think I know enough to do that job yet.

Jun

From owner-linux-mips@oss.sgi.com Wed Aug  2 01:29:39 2000
Received:  by oss.sgi.com id <S42240AbQHBI3a>;
	Wed, 2 Aug 2000 01:29:30 -0700
Received: from deliverator.sgi.com ([204.94.214.10]:49784 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S42236AbQHBI3B>;
	Wed, 2 Aug 2000 01:29:01 -0700
Received: from nodin.corp.sgi.com (nodin.corp.sgi.com [192.26.51.193]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id BAA26641
	for <linux-mips@oss.sgi.com>; Wed, 2 Aug 2000 01:20:57 -0700 (PDT)
	mail_from (kevink@mips.com)
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by nodin.corp.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) via ESMTP id BAA03600 for <linux-mips@oss.sgi.com>; Wed, 2 Aug 2000 01:26:44 -0700 (PDT)
Received: from sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id BAA96327
	for <linux@cthulhu.engr.sgi.com>;
	Wed, 2 Aug 2000 01:25:12 -0700 (PDT)
	mail_from (kevink@mips.com)
Received: from mx.mips.com (mx.mips.com [206.31.31.226]) 
	by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam:
       SGI does not authorize the use of its proprietary
       systems or networks for unsolicited or bulk email
       from the Internet.) 
	via ESMTP id BAA04082
	for <linux@cthulhu.engr.sgi.com>; Wed, 2 Aug 2000 01:25:10 -0700 (PDT)
	mail_from (kevink@mips.com)
Received: from newman.mips.com (ns-dmz [206.31.31.225])
	by mx.mips.com (8.9.3/8.9.0) with ESMTP id BAA29838;
	Wed, 2 Aug 2000 01:23:56 -0700 (PDT)
Received: from Ulysses (ulysses [192.168.236.13])
	by newman.mips.com (8.9.3/8.9.0) with SMTP id BAA15451;
	Wed, 2 Aug 2000 01:23:52 -0700 (PDT)
Message-ID: <008601bffc5b$6714c0a0$0deca8c0@Ulysses>
From:   "Kevin D. Kissell" <kevink@mips.com>
To:     "Jun Sun" <jsun@mvista.com>, <linux@cthulhu.engr.sgi.com>,
        <linux-mips@fnet.fr>, <ralf@oss.sgi.com>
Subject: Re: PROPOSAL : multi-way cache support in Linux/MIPS
Date:   Wed, 2 Aug 2000 10:26:38 +0200
MIME-Version: 1.0
Content-Type: multipart/mixed;
	boundary="----=_NextPart_000_0083_01BFFC6C.24323180"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3110.1
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing

This is a multi-part message in MIME format.

------=_NextPart_000_0083_01BFFC6C.24323180
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Rather than re-invent the wheel, please consider the
cache descriptor data structures we developed at
MIPS to deal with this problem.  I believe that the
updated cache.h file, and maybe even the cpu_probe.c
file, was checked into the 2.2 repository at SGI long ago.
There are also a set of initialisation and invalidation routines
that key off the cache descriptor structure, but those aren't
in the SGI  repository (though anyone can get them from
ftp.mips.com or www.paralogos.com).  The CPU probe
logic (also on those sites, and already integrated
into several variants because it also supports setting
up state needed by the software FPU emulation)
is table-based, and for each PrID value, there is
a template for the cache characteristics, which
can either be taken "as is" or probed, depending
on a flag in the descriptor.  Since the number of
"ways" cannot always be determined by probing,
if the number of ways is specified, it is preserved
even if a cache probe is performed.   I won't attach the
full set of cache probe routines (which would only confuse
things), but here is the cache data structure definition
and the CPU descriptor template table that we use.

            Regads,

            Kevin K.

-----Original Message-----
From: Jun Sun <jsun@mvista.com>
To: linux@cthulhu.engr.sgi.com <linux@cthulhu.engr.sgi.com>;
linux-mips@fnet.fr <linux-mips@fnet.fr>; ralf@oss.sgi.com <ralf@oss.sgi.com>
Date: Wednesday, August 02, 2000 2:01 AM
Subject: PROPOSAL : multi-way cache support in Linux/MIPS


>Ralf,
>
>I have got NEC DDB5476 running stable enough that I am comfortable to
>check in
>my code.  Will you take it?
>
>Assuming the answer is yes, there are several issues regarding checking
>in.
>I will bring them up one by one.
>
>The first issue is multi-way cache support.  DDB5476 uses R5432 CPU
>which
>has two-way set-associative cache.  The problematic part is the
>index-based cache operations in r4xxcache.h does not cover all ways in a
>set.
>
>I think this is a problem in general.  So far I have seen MIPS
>processors with
>2-way, 4-way and 8-way sets.  And I have seen them using ether least-
>significant-addressing-bits or most-significant-addressing-bits
>within a cache line to select ways.
>
>Here is my proposal :
>
>. introduce two variables,
>        cache_num_ways - number of ways in a set
>        cache_way_selection_offset - the offset added to the address to
>select
>                next cache line in the same set.  For LSBs addressing,
>it is
>                equal to 1.  For MSBs addressing, it is equal to
>                cache_line_size / cache_num_ways.  (It can potentially
>take
>                care of some future weired way-selection scheme as long
>as
>                the offset is uniform)
>
>. These variables are initialized in cpu_probe().
>
>  (Alternatively, I think we should have cpu_info table, that contains
>all
>   these cpu information.  Then a general routine can fill in the based
>on
>   the cpu id.  This can get rid of a bunch of ugly switch/case
>statements.)
>
>. in the include/asm/r4kcache.h file, all Index-based cache operation
>needs
>  to changed like the following (for illustration only; need
>optimization) :
>
>-----
>        while(start < end) {
>                cache16_unroll32(start,Index_Writeback_Inv_D);
>                start += 0x200;
>        }
>+++++
>        while(start < end) {
>                for (i=0; i< cache_num_ways; i++) {
>                        cache16_unroll32(start +
>i*cache_way_selection_offset,
>                                         Index_Writeback_Inv_D);
>                }
>                start += 0x200;
>        }
>=====
>
>What do you think?  If it is OK, I can do the patch.  The cpu_info table
>is a nice wish, but I don't think I know enough to do that job yet.
>
>Jun

------=_NextPart_000_0083_01BFFC6C.24323180
Content-Type: application/octet-stream;
	name="cache.h"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="cache.h"

LyoKICogaW5jbHVkZS9hc20tbWlwcy9jYWNoZS5oCiAqLwovKioqKioqKioqKioqKioqKioqKioq
KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioKICog
IDcgRGVjLCAxOTk5LgogKiAgQWRkZWQgZGVmaW5pdGlvbiBvZiBjYWNoZSBkZXNjcmlwdG9yIHN0
cnVjdHVyZS4KICoKICogIEtldmluIEQuIEtpc3NlbGwsIGtldmlua0BtaXBzLmNvbQogKiAgQ29w
eXJpZ2h0IChDKSAxOTk5IE1JUFMgVGVjaG5vbG9naWVzLCBJbmMuICBBbGwgcmlnaHRzIHJlc2Vy
dmVkLgogKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq
KioqKioqKioqKioqKioqKioqKioqKi8KCiNpZm5kZWYgX19BU01fTUlQU19DQUNIRV9ICiNkZWZp
bmUgX19BU01fTUlQU19DQUNIRV9ICgojaWZuZGVmIF9MQU5HVUFHRV9BU1NFTUJMWQovKgogKiBE
ZXNjcmlwdG9yIGZvciBhIGNhY2hlCiAqLwoKc3RydWN0IGNhY2hlX2Rlc2MgewogICAgICAgIGlu
dCBsaW5lc3o7CiAgICAgICAgaW50IHNldHM7CiAgICAgICAgaW50IHdheXM7CiAgICAgICAgaW50
IGZsYWdzOyAgICAgIC8qIERldGFpbHMgbGlrZSB3cml0ZSB0aHJ1L2JhY2ssIGNvaGVyZW50LCBl
dGMuICovCn07CgojZW5kaWYKLyoKICogRmxhZyBkZWZpbml0aW9ucwogKi8KCiNkZWZpbmUgTUlQ
U19DQUNIRV9ORUVEU19DT05GSUcJMHgwMDAwMDAwMQojZGVmaW5lIE1JUFNfQ0FDSEVfVklSVFVB
TAkweDAwMDAwMDAyICAvKiBWaXJ0dWFsbHkgdGFnZ2VkICovCgovKiBieXRlcyBwZXIgTDEgY2Fj
aGUgbGluZSAqLwoKLyogCiAqIEl0IHdvdWxkIGJlIG5pY2UgdG8gbWFrZSB0aGlzIGR5bmFtaWMs
IAogKiBiYXNlZCBvbiBtaXBzX2NwdS5kY2FjaGUubGluZXN6LCBidXQKICogaXQgaXMgdXNlZCBm
b3IgZml4ZWQtc2l6ZSBzdHJ1Y3R1cmUgYWxsb2NhdGlvbi4KICogU2V0IHRvIGtub3duIG1heGlt
dW0gZm9yIE1JUFMgYXJjaGl0ZWN0dXJlLCAzMiBieXRlcy4KICovCgojZGVmaW5lICAgICAgICBM
MV9DQUNIRV9CWVRFUyAgMzIKCgojZGVmaW5lICAgICAgICBMMV9DQUNIRV9BTElHTih4KSAgICAg
ICAoKCh4KSsoTDFfQ0FDSEVfQllURVMtMSkpJn4oTDFfQ0FDSEVfQllURVMtMSkpCgojZGVmaW5l
ICAgICAgICBTTVBfQ0FDSEVfQllURVMgTDFfQ0FDSEVfQllURVMKCiNlbmRpZiAvKiBfX0FTTV9N
SVBTX0NBQ0hFX0ggKi8K

------=_NextPart_000_0083_01BFFC6C.24323180
Content-Type: application/octet-stream;
	name="cpu.h"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="cpu.h"

LyogJElkOiBjcHUuaCx2IDEuNSAyMDAwLzAyLzE2IDIxOjQ2OjI5IGtldmluayBFeHAgJAogKiBj
cHUuaDogVmFsdWVzIG9mIHRoZSBQUklkIHJlZ2lzdGVyIHVzZWQgdG8gbWF0Y2ggdXAKICogICAg
ICAgIHZhcmlvdXMgTUlQUyBjcHUgdHlwZXMuCiAqCiAqIENvcHlyaWdodCAoQykgMTk5NiBEYXZp
ZCBTLiBNaWxsZXIgKGRtQGVuZ3Iuc2dpLmNvbSkKICoKICovCi8qKioqKioqKioqKioqKioqKioq
KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKgog
KiAgNyBEZWMsIDE5OTkuCiAqICBBZGRlZCA0S0MgYW5kIDVLQyBQUl9JRCBjb2RlcywgYW5kIGRl
ZmluZWQgbWlwc19jcHUgZGF0YSBzdHJ1Y3R1cmUKICogIGFuZCBmaWVsZCBlbmNvZGluZ3MuCiAq
CiAqICBLZXZpbiBELiBLaXNzZWxsLCBrZXZpbmtAbWlwcy5jb20KICogIENvcHlyaWdodCAoQykg
MTk5OSBNSVBTIFRlY2hub2xvZ2llcywgSW5jLiAgQWxsIHJpZ2h0cyByZXNlcnZlZC4KICoqKioq
KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq
KioqKioqKioqKiovCgojaWZuZGVmIF9NSVBTX0NQVV9ICiNkZWZpbmUgX01JUFNfQ1BVX0gKCi8q
CiAqIEFzc2lnbmVkIHZhbHVlcyBmb3IgdGhlIHByb2R1Y3QgSUQgcmVnaXN0ZXIuICBJbiBvcmRl
ciB0byBkZXRlY3QgYQogKiBjZXJ0YWluIENQVSB0eXBlIGV4YWN0bHkgZXZlbnR1YWxseSBhZGRp
dGlvbmFsIHJlZ2lzdGVycyBtYXkgbmVlZCB0bwogKiBiZSBleGFtaW5lZC4KICovCiNkZWZpbmUg
UFJJRF9JTVBfUjIwMDAgICAgMHgwMTAwCiNkZWZpbmUgUFJJRF9JTVBfUjMwMDAgICAgMHgwMjAw
CiNkZWZpbmUgUFJJRF9JTVBfUjYwMDAgICAgMHgwMzAwCiNkZWZpbmUgUFJJRF9JTVBfUjQwMDAg
ICAgMHgwNDAwCiNkZWZpbmUgUFJJRF9JTVBfUjYwMDBBICAgMHgwNjAwCiNkZWZpbmUgUFJJRF9J
TVBfUjEwMDAwICAgMHgwOTAwCiNkZWZpbmUgUFJJRF9JTVBfUjQzMDAgICAgMHgwYjAwCiNkZWZp
bmUgUFJJRF9JTVBfUjgwMDAgICAgMHgxMDAwCiNkZWZpbmUgUFJJRF9JTVBfUjQ2MDAgICAgMHgy
MDAwCiNkZWZpbmUgUFJJRF9JTVBfUjQ3MDAgICAgMHgyMTAwCiNkZWZpbmUgUFJJRF9JTVBfUjQ2
NDAgICAgMHgyMjAwCiNkZWZpbmUgUFJJRF9JTVBfUjQ2NTAgICAgMHgyMjAwCQkvKiBTYW1lIGFz
IFI0NjQwICovCiNkZWZpbmUgUFJJRF9JTVBfUjUwMDAgICAgMHgyMzAwCiNkZWZpbmUgUFJJRF9J
TVBfU09OSUMgICAgMHgyNDAwCiNkZWZpbmUgUFJJRF9JTVBfTUFHSUMgICAgMHgyNTAwCiNkZWZp
bmUgUFJJRF9JTVBfUk03MDAwICAgMHgyNzAwCiNkZWZpbmUgUFJJRF9JTVBfTkVWQURBICAgMHgy
ODAwCQkvKiBSTTUyNjAgPz8/ICovCiNkZWZpbmUgUFJJRF9JTVBfNEtDICAgICAgMHg4MDAwCiNk
ZWZpbmUgUFJJRF9JTVBfNUtDICAgICAgMHg4MTAwCgojZGVmaW5lIFBSSURfSU1QX1VOS05PV04g
IDB4ZmYwMAoKI2RlZmluZSBQUklEX1JFVl9SNDQwMCAgICAweDAwNDAKI2RlZmluZSBQUklEX1JF
Vl9SMzAwMEEgICAweDAwMzAKI2RlZmluZSBQUklEX1JFVl9SMzAwMCAgICAweDAwMjAKI2RlZmlu
ZSBQUklEX1JFVl9SMjAwMEEgICAweDAwMTAKCgojaW5jbHVkZSA8YXNtL2NhY2hlLmg+CgojaWZu
ZGVmICBfTEFOR1VBR0VfQVNTRU1CTFkKLyoKICogQ2FwYWJpbGl0eSBhbmQgZmVhdHVyZSBkZXNj
cmlwdG9yIHN0cnVjdHVyZSBmb3IgTUlQUyBDUFUKICovCgpzdHJ1Y3QgbWlwc19jcHUgewoJdW5z
aWduZWQgaW50IHByb2Nlc3Nvcl9pZDsKCXVuc2lnbmVkIGludCBjcHV0eXBlOwkJLyogT2xkICJt
aXBzX2NwdXR5cGUiIGNvZGUgKi8KCWludCBpc2FfbGV2ZWw7CglpbnQgb3B0aW9uczsKCWludCB0
bGJzaXplOwoJc3RydWN0IGNhY2hlX2Rlc2MgaWNhY2hlOwkvKiBQcmltYXJ5IEktY2FjaGUgKi8K
CXN0cnVjdCBjYWNoZV9kZXNjIGRjYWNoZTsJLyogUHJpbWFyeSBEIG9yIGNvbWJpbmVkIEkvRCBj
YWNoZSAqLwoJc3RydWN0IGNhY2hlX2Rlc2Mgc2NhY2hlOwkvKiBTZWNvbmRhcnkgY2FjaGUgKi8K
CXN0cnVjdCBjYWNoZV9kZXNjIHRjYWNoZTsJLyogVGVydGlhcnkvc3BsaXQgc2Vjb25kYXJ5IGNh
Y2hlICovCn07CgojZW5kaWYKCi8qCiAqIElTQSBMZXZlbCBlbmNvZGluZ3MgCiAqLwoKI2RlZmlu
ZSBNSVBTX0NQVV9JU0FfSQkJMHgwMDAwMDAwMQojZGVmaW5lIE1JUFNfQ1BVX0lTQV9JSQkJMHgw
MDAwMDAwMgojZGVmaW5lIE1JUFNfQ1BVX0lTQV9JSUkJMHgwMDAwMDAwMwojZGVmaW5lIE1JUFNf
Q1BVX0lTQV9JVgkJMHgwMDAwMDAwNAojZGVmaW5lIE1JUFNfQ1BVX0lTQV9WCQkweDAwMDAwMDA1
CiNkZWZpbmUgTUlQU19DUFVfSVNBX00zMgkweDAwMDAwMDIwCiNkZWZpbmUgTUlQU19DUFVfSVNB
X002NAkweDAwMDAwMDQwCgovKgogKiBDUFUgT3B0aW9uIGVuY29kaW5ncyAKICovIAoKI2RlZmlu
ZSBNSVBTX0NQVV9UTEIJMHgwMDAwMDAwMQkvKiBDUFUgaGFzIFRMQiAqLwovKiBMZWF2ZSBhIHNw
YXJlIGJpdCBmb3IgdmFyaWFudCBNTVUgdHlwZXMuLi4gKi8KI2RlZmluZSBNSVBTX0NQVV80S0VY
CTB4MDAwMDAwMDQJLyogIlI0SyIgZXhjZXB0aW9uIG1vZGVsICovCiNkZWZpbmUgTUlQU19DUFVf
NEtUTEIJMHgwMDAwMDAwOAkvKiAiUjRLIiBUTEIgaGFuZGxlciAqLwojZGVmaW5lIE1JUFNfQ1BV
X0ZQVQkweDAwMDAwMDEwCS8qIENQVSBoYXMgRlBVICovCiNkZWZpbmUgTUlQU19DUFVfMzJGUFIJ
MHgwMDAwMDAyMAkvKiAzMiBkYmwuIHByZWMuIEZQIHJlZ2lzdGVycyAqLwojZGVmaW5lIE1JUFNf
Q1BVX0NPVU5URVIgMHgwMDAwMDA0MAkvKiBDeWNsZSBjb3VudC9jb21wYXJlICovCiNkZWZpbmUg
TUlQU19DUFVfV0FUQ0gJMHgwMDAwMDA4MAkvKiB3YXRjaHBvaW50IHJlZ2lzdGVycyAqLwojZGVm
aW5lIE1JUFNfQ1BVX01JUFMxNgkweDAwMDAwMTAwCS8qIGNvZGUgY29tcHJlc3Npb24gKi8KI2Rl
ZmluZSBNSVBTX0NQVV9ESVZFQwkweDAwMDAwMjAwCS8qIGRlZGljYXRlZCBpbnRlcnJ1cHQgdmVj
dG9yICovCiNkZWZpbmUgTUlQU19DUFVfVkNFCTB4MDAwMDA0MDAJLyogdmlydC4gY29oZXJlbmNl
IGNvbmZsaWN0IHBvc3NpYmxlICovCiNkZWZpbmUgTUlQU19DUFVfQ0FDSEVfQ0RFWCAweDAwMDAw
ODAwCS8qIENyZWF0ZV9EaXJ0eV9FeGNsdXNpdmUgQ0FDSEUgb3AgKi8KCiNlbmRpZiAvKiAhKF9N
SVBTX0NQVV9IKSAqLwo=

------=_NextPart_000_0083_01BFFC6C.24323180
Content-Type: application/octet-stream;
	name="cpu_probe.c"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="cpu_probe.c"

LyogJElkOiBjcHVfcHJvYmUuYyx2IDEuMTEgMjAwMC8wNy8wNyAwOTowMjozNiBjYXJzdGVubCBF
eHAgJCAKICoKICogY3B1X3Byb2JlLmMKICoKICogS2V2aW4gRC4gS2lzc2VsbCwga2V2aW5rQG1p
cHMuY29tCiAqIENvcHlyaWdodCAoQykgMTk5OSwyMDAwIE1JUFMgVGVjaG5vbG9naWVzLCBJbmMu
ICBBbGwgcmlnaHRzIHJlc2VydmVkLgogKgogKiAjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj
IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMKICoKICogIFRoaXMg
cHJvZ3JhbSBpcyBmcmVlIHNvZnR3YXJlOyB5b3UgY2FuIGRpc3RyaWJ1dGUgaXQgYW5kL29yIG1v
ZGlmeSBpdAogKiAgdW5kZXIgdGhlIHRlcm1zIG9mIHRoZSBHTlUgR2VuZXJhbCBQdWJsaWMgTGlj
ZW5zZSAoVmVyc2lvbiAyKSBhcwogKiAgcHVibGlzaGVkIGJ5IHRoZSBGcmVlIFNvZnR3YXJlIEZv
dW5kYXRpb24uCiAqCiAqICBUaGlzIHByb2dyYW0gaXMgZGlzdHJpYnV0ZWQgaW4gdGhlIGhvcGUg
aXQgd2lsbCBiZSB1c2VmdWwsIGJ1dCBXSVRIT1VUCiAqICBBTlkgV0FSUkFOVFk7IHdpdGhvdXQg
ZXZlbiB0aGUgaW1wbGllZCB3YXJyYW50eSBvZiBNRVJDSEFOVEFCSUxJVFkgb3IKICogIEZJVE5F
U1MgRk9SIEEgUEFSVElDVUxBUiBQVVJQT1NFLiAgU2VlIHRoZSBHTlUgR2VuZXJhbCBQdWJsaWMg
TGljZW5zZQogKiAgZm9yIG1vcmUgZGV0YWlscy4KICoKICogIFlvdSBzaG91bGQgaGF2ZSByZWNl
aXZlZCBhIGNvcHkgb2YgdGhlIEdOVSBHZW5lcmFsIFB1YmxpYyBMaWNlbnNlIGFsb25nCiAqICB3
aXRoIHRoaXMgcHJvZ3JhbTsgaWYgbm90LCB3cml0ZSB0byB0aGUgRnJlZSBTb2Z0d2FyZSBGb3Vu
ZGF0aW9uLCBJbmMuLAogKiAgNTkgVGVtcGxlIFBsYWNlIC0gU3VpdGUgMzMwLCBCb3N0b24gTUEg
MDIxMTEtMTMwNywgVVNBLgogKgogKiAjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj
IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMKICoKICogQyBjb2RlLCBjYWxs
ZWQgZnJvbSBzdGFydHVwIHZlY3RvciB0byBkZWNvZGUgdGhlIENQVSBjb25maWd1cmF0aW9uIGFu
ZCAKICogc2V0IHVwIHRoZSBtaXBzX2NwdSBkYXRhIHN0cnVjdHVyZSwgdXNlZCBieSB0aGUga2Vy
bmVsIHRvIGFic3RyYWN0IG91dCAKICogbW9zdCBpbXBsZW1lbnRhdGlvbiBvcHRpb25zIG9mIE1J
UFMgQ1BVcy4KICoKICovCgojaW5jbHVkZSA8YXNtL2NwdS5oPgojaW5jbHVkZSA8YXNtL2Jvb3Rp
bmZvLmg+CiNpbmNsdWRlIDxhc20vaW5pdC5oPgoKI2luY2x1ZGUgPGxpbnV4L2NvbmZpZy5oPgoK
I2lmZGVmIENPTkZJR19DUFVfTUlQUzMyCmV4dGVybiB2b2lkIG1pcHMzMl9jcHVfcHJvYmUodW5z
aWduZWQgaW50IHByX2lkKTsKI2VuZGlmCgovKiBkZWNsYXJhdGlvbiBvZiB0aGUgZ2xvYmFsIHN0
cnVjdCAqLwpzdHJ1Y3QgbWlwc19jcHUgbWlwc19jcHUgPSB7UFJJRF9JTVBfVU5LTk9XTiwgQ1BV
X1VOS05PV04sIDAsIDAsIDAsCgkJCQl7MCwwLDAsMH0sIHswLDAsMCwwfSwgezAsMCwwLDB9LCB7
MCwwLDAsMH19OwoKLyogU2hvcnRjdXQgZm9yIGFzc2VtYmxlciBhY2Nlc3MgdG8gbWlwc19jcHUu
b3B0aW9ucyAqLwoKaW50ICpjcHVvcHRpb25zID0gJm1pcHNfY3B1Lm9wdGlvbnM7CgovKgogKiBD
YW5uZWQgZGVzY3JpcHRvcnMgb2YgTUlQUyBDUFVzLiBOb3RlIHRoYXQgZm9yIHRoZSBjb2RlIGJl
bG93CiAqIHRvIGZ1bmN0aW9uIGNvcnJlY3RseSwgYSBnZW5lcmljIGRlc2NyaXB0aW9uIHdpdGgg
YSBwcm9jZXNzb3JfaWQKICogdmFsdWUgd2l0aCBubyBpbXBsZW1lbnRhdGlvbiBiaXRzIHNldCBt
dXN0IGZvbGxvdyBhbnkgZGVzY3JpcHRpb25zCiAqIG9mIGRpc3RpbmN0IHZhcmlhbnQgcmV2aXN0
aW9ucywgaS5lLiBSNDAwMCBtdXN0IHByZWNlZGUgUjQ0MDAsCiAqIFIzMDAwIG11c3QgcHJlY2Vk
ZSBSMzAwMEEuICBNYW55IENQVXMgYXJlIG5vdCByZWZsZWN0ZWQgaW4KICogdGhlIGxpc3QuICBO
ZXcgZW50cmllcyByZXF1aXJlIHRoZSBhZGR0aW9uIG9mIFBSX0lEIHJlZ2lzdGVyCiAqIGRhdGEg
aW4gYXNtL2NwdS5oIGFuZCBhc3NpZ25tZW50IG9mIGEgQ1BVXyBjb2RlIGluIGFzbS9ib290aW5m
by5oLgogKiBUaGUgbWlwc19jcHUgc3RydWN0dXJlIGlzIGRlZmluZWQgaW4gYXNtL2NwdS5oIGFu
ZCBhc20vY2FjaGUuaC4KICovCgovKgogKiBTb21lIG9wdGlvbnMgYXJlIGNvbW1vbiBhY3Jvc3Mg
YWxsIFI0MDAwIGRlcml2YXRpdmVzCiAqLwoKI2RlZmluZSBSNEtfT1BUUyAoTUlQU19DUFVfVExC
IHwgTUlQU19DUFVfNEtFWCB8IE1JUFNfQ1BVXzRLVExCIFwKCQl8IE1JUFNfQ1BVX0NPVU5URVIg
fCBNSVBTX0NQVV9DQUNIRV9DREVYICkKCnN0YXRpYyBzdHJ1Y3QgbWlwc19jcHUgX19pbml0ZGF0
YSBtaXBzX2NwdV90ZW1wbGF0ZVtdID0gewoJLyogUjIwMDAgKi8KCXsgUFJJRF9JTVBfUjIwMDAs
IAkvKiBQUl9JRCByZWdpc3RlciB2YWx1ZSAqLwoJICBDUFVfUjIwMDAsIAkJLyogS2VybmVsIGlu
dGVybmFsIENQVSBpZGVudGlmaWVyICovCgkgIE1JUFNfQ1BVX0lTQV9JLCAJLyogTUlQUyBJU0Eg
bGV2ZWwgKi8KCSAgTUlQU19DUFVfVExCLCAJLyogRmxhZ3MgZm9yIGltcGxlbWVudGF0aW9uIG9w
dGlvbnMgKi8KCSAgMzIsCQkJLyogTnVtYmVyIG9mIFRMQiBlbnRyaWVzICovCgkgIHswLDAsMCww
fSwgCQkvKiBJLWNhY2hlIGxpbmUgc2l6ZSwgI3NldHMsICN3YXlzLCBmbGFncyAqLwoJICB7MCww
LDAsTUlQU19DQUNIRV9ORUVEU19DT05GSUd9LCAvKiBVbmlmaWVkL0QtY2FjaGUgZGVzY3JpcHRv
ciAqLwoJICB7MCwwLDAsMH0sIAkJLyogUy1jYWNoZSBkZXNjcmlwdG9yICovCgkgIHswLDAsMCww
fX0sCQkvKiBUZXJ0aWFyeSBjYWNoZSBkZXNjcmlwdG9yICovCgkvKiBNSVBTIDRLYyAqLwoJeyBQ
UklEX0lNUF80S0MsIENQVV80S0MsICBNSVBTX0NQVV9JU0FfTTMyLCBNSVBTX0NQVV9UTEIgfCAK
CSAgICAgICAgTUlQU19DUFVfNEtFWCB8IE1JUFNfQ1BVXzRLVExCIHwgTUlQU19DUFVfQ09VTlRF
UiB8IAoJICAgICAgICBNSVBTX0NQVV9ESVZFQyB8IE1JUFNfQ1BVX1dBVENILCAxNiwgCgkgICAg
ICAgIHsxNiwgMjU2LCA0LCAwfSwgezE2LCAyNTYsIDQsIDB9LCB7MCwwLDAsMH0sIHswLDAsMCww
fX0sCgkvKiBNSVBTIDVLYyAqLwoJeyBQUklEX0lNUF81S0MsIENQVV81S0MsICBNSVBTX0NQVV9J
U0FfTTY0LCBNSVBTX0NQVV9UTEIgfCAKCSAgICAgICAgTUlQU19DUFVfNEtFWCB8IE1JUFNfQ1BV
XzRLVExCIHwgTUlQU19DUFVfQ09VTlRFUiB8IAoJICAgICAgICBNSVBTX0NQVV9ESVZFQyB8IE1J
UFNfQ1BVX1dBVENILCAzMiwKCSAgICAgICAgezMyLCAxMjgsIDQsIDB9LCB7MzIsIDEyOCwgNCwg
MH0sIHswLDAsMCwwfSwgezAsMCwwLDB9fSwKCS8qIFIzMDAwICovCgl7IFBSSURfSU1QX1IzMDAw
LCBDUFVfUjMwMDAsIE1JUFNfQ1BVX0lTQV9JLCBNSVBTX0NQVV9UTEIsIDMyLAoJCXswLCAwLCAw
LCAwfSwgezAsIDAsIDAsIE1JUFNfQ0FDSEVfTkVFRFNfQ09ORklHfSwgCgkJezAsMCwwLDB9LCB7
MCwwLDAsMH19LAoJLyogUjMwMDBBICovCgl7IFBSSURfSU1QX1IzMDAwIHwgUFJJRF9SRVZfUjMw
MDBBLCBDUFVfUjMwMDBBLCAKCQlNSVBTX0NQVV9JU0FfSSwgTUlQU19DUFVfVExCLCAzMiwKCQl7
MCwgMCwgMCwgMH0sIHswLCAwLCAwLCBNSVBTX0NBQ0hFX05FRURTX0NPTkZJR30sIAoJCXswLDAs
MCwwfSwgezAsMCwwLDB9fSwKCS8qIFI2MDAwICovCgl7IFBSSURfSU1QX1I2MDAwLCBDUFVfUjYw
MDAsIE1JUFNfQ1BVX0lTQV9JSSwgCgkJTUlQU19DUFVfVExCIHwgTUlQU19DUFVfRlBVLCAzMiwK
CQl7MCwgMCwgMCwgMH0sIHswLCAwLCAwLCBNSVBTX0NBQ0hFX05FRURTX0NPTkZJR30sIAoJCXsw
LDAsMCwwfSwgezAsMCwwLDB9fSwKCS8qIFI2MDAwQSAqLwoJeyBQUklEX0lNUF9SNjAwMEEsIENQ
VV9SNjAwMEEsIE1JUFNfQ1BVX0lTQV9JSSwgCgkJTUlQU19DUFVfVExCIHwgTUlQU19DUFVfRlBV
LCAzMiwKCQl7MCwgMCwgMCwgMH0sIHswLCAwLCAwLCBNSVBTX0NBQ0hFX05FRURTX0NPTkZJR30s
IAoJCXswLDAsMCwwfSwgezAsMCwwLDB9fSwKCS8qIFI0MDAwU0MgKi8KCXsgUFJJRF9JTVBfUjQw
MDAsIENQVV9SNDAwMFNDLCBNSVBTX0NQVV9JU0FfSUlJLCAKCSAgICBSNEtfT1BUUyB8IE1JUFNf
Q1BVX0ZQVSB8IE1JUFNfQ1BVXzMyRlBSIAoJICAgIHwgTUlQU19DUFVfV0FUQ0ggfCBNSVBTX0NQ
VV9WQ0UsIDQ4LAoJCXswLCAwLCAxLCBNSVBTX0NBQ0hFX05FRURTX0NPTkZJR30sIAoJCXswLCAw
LCAxLCBNSVBTX0NBQ0hFX05FRURTX0NPTkZJR30sCgkJezAsMCwxLE1JUFNfQ0FDSEVfTkVFRFNf
Q09ORklHfSwgezAsMCwwLDB9fSwKCS8qIFI0NDAwU0MgKi8KCXsgUFJJRF9JTVBfUjQwMDAgfCBQ
UklEX1JFVl9SNDQwMCwgQ1BVX1I0NDAwU0MsIE1JUFNfQ1BVX0lTQV9JSUksIAoJICAgIFI0S19P
UFRTIHwgTUlQU19DUFVfRlBVIHwgTUlQU19DUFVfMzJGUFIgCgkgICAgfCBNSVBTX0NQVV9XQVRD
SCB8IE1JUFNfQ1BVX1ZDRSwgNDgsCgkJezAsIDAsIDEsIE1JUFNfQ0FDSEVfTkVFRFNfQ09ORklH
fSwgCgkJezAsIDAsIDEsIE1JUFNfQ0FDSEVfTkVFRFNfQ09ORklHfSwKCQl7MCwwLDEsIE1JUFNf
Q0FDSEVfTkVFRFNfQ09ORklHfSwgezAsMCwwLDB9fSwKCS8qIFI0MzAwICovCgl7IFBSSURfSU1Q
X1I0MzAwLCBDUFVfUjQzMDAsIE1JUFNfQ1BVX0lTQV9JSUksIAoJICAgIFI0S19PUFRTIHwgTUlQ
U19DUFVfRlBVIHwgTUlQU19DUFVfMzJGUFIgfCBNSVBTX0NQVV9XQVRDSCwgMzIsCgkJezMyLCA1
MTIsIDEsIE1JUFNfQ0FDSEVfTkVFRFNfQ09ORklHfSwgCgkJezE2LCA1MTIsIDEsIE1JUFNfQ0FD
SEVfTkVFRFNfQ09ORklHfSwgCgkJezAsMCwwLDB9LCB7MCwwLDAsMH19LAoJLyogUjQ2MDAgKi8K
CXsgUFJJRF9JTVBfUjQ2MDAsIENQVV9SNDYwMCwgTUlQU19DUFVfSVNBX0lJSSwgCgkgICAgUjRL
X09QVFMgfCBNSVBTX0NQVV9GUFUsIDQ4LAoJCXszMiwgMTI4LCAyLCBNSVBTX0NBQ0hFX05FRURT
X0NPTkZJR30sIAoJCXszMiwgMTI4LCAyLCBNSVBTX0NBQ0hFX05FRURTX0NPTkZJR30sIAoJCXsw
LDAsMCwwfSwgezAsMCwwLDB9fSwKCS8qIFI0NjUwICovCgl7IFBSSURfSU1QX1I0NjUwLCBDUFVf
UjQ2NTAsIE1JUFNfQ1BVX0lTQV9JSUksIAoJICAgIFI0S19PUFRTIHwgTUlQU19DUFVfRlBVLCA0
OCwKCQl7MzIsIDEyOCwgMiwgTUlQU19DQUNIRV9ORUVEU19DT05GSUd9LCAKCQl7MzIsIDEyOCwg
MiwgTUlQU19DQUNIRV9ORUVEU19DT05GSUd9LCAKCQl7MCwwLDAsMH0sIHswLDAsMCwwfX0sCgkv
KiBSNDcwMCAqLwoJeyBQUklEX0lNUF9SNDcwMCwgQ1BVX1I0NzAwLCBNSVBTX0NQVV9JU0FfSUlJ
LCAKCSAgICBSNEtfT1BUUyB8IE1JUFNfQ1BVX0ZQVSB8IE1JUFNfQ1BVXzMyRlBSLCA0OCwKCQl7
MzIsIDI1NiwgMiwgTUlQU19DQUNIRV9ORUVEU19DT05GSUd9LCAKCQl7MzIsIDI1NiwgMiwgTUlQ
U19DQUNIRV9ORUVEU19DT05GSUd9LCAKCQl7MCwwLDAsMH0sIHswLDAsMCwwfX0sCgkvKiBSNTAw
MCAqLwoJeyBQUklEX0lNUF9SNTAwMCwgQ1BVX1I1MDAwLCBNSVBTX0NQVV9JU0FfSVYsIAoJICAg
IFI0S19PUFRTIHwgTUlQU19DUFVfRlBVIHwgTUlQU19DUFVfMzJGUFIsIDQ4LAoJCXszMiwgNTEy
LCAyLCBNSVBTX0NBQ0hFX05FRURTX0NPTkZJR30sIAoJCXszMiwgNTEyLCAyLCBNSVBTX0NBQ0hF
X05FRURTX0NPTkZJR30sCgkJezAsMCwwLE1JUFNfQ0FDSEVfTkVFRFNfQ09ORklHfSwgezAsMCww
LDB9fSwKCS8qIFI1Mnh4LiBDYWNoZSBzaXplIHZhcmllcyB3aXRoIHJldmlzaW9uICovCgl7IFBS
SURfSU1QX05FVkFEQSwgQ1BVX05FVkFEQSwgTUlQU19DUFVfSVNBX0lWLCAKCSAgICBSNEtfT1BU
UyB8IE1JUFNfQ1BVX0ZQVSB8IE1JUFNfQ1BVXzMyRlBSIHwgTUlQU19DUFVfRElWRUMsIDQ4LAoJ
CXswLCAwLCAyLCBNSVBTX0NBQ0hFX05FRURTX0NPTkZJR30sIHswLCAwLCAyLCBNSVBTX0NBQ0hF
X05FRURTX0NPTkZJR30sCgkJezAsMCwwLDB9LCB7MCwwLDAsMH19LAoJLyogUjgwMDAgLSBoYXMg
d2llcmQgVExCOiAzLXdheSB4IDEyOCAqLwoJeyBQUklEX0lNUF9SODAwMCwgQ1BVX1I4MDAwLCBN
SVBTX0NQVV9JU0FfSVYsIAoJICAgIE1JUFNfQ1BVX1RMQiB8IE1JUFNfQ1BVXzRLRVggfCBNSVBT
X0NQVV9GUFUgfCBNSVBTX0NQVV8zMkZQUiwgMzg0LAoJCXszMiwgNTEyLCAxLCBNSVBTX0NBQ0hF
X1ZJUlRVQUx9LCB7MzIsIDUxMiwgMSwgMH0sCgkJezAsMCwwLE1JUFNfQ0FDSEVfTkVFRFNfQ09O
RklHfSwgezAsMCwwLDB9fSwKCS8qIFIxMDAwMCAqLwoJeyBQUklEX0lNUF9SMTAwMDAsIENQVV9S
MTAwMDAsIE1JUFNfQ1BVX0lTQV9JViwgCgkgICAgTUlQU19DUFVfVExCIHwgTUlQU19DUFVfNEtF
WCB8IE1JUFNfQ1BVX0ZQVSAKCSAgICB8IE1JUFNfQ1BVXzMyRlBSIHwgTUlQU19DUFVfQ09VTlRF
UiB8IE1JUFNfQ1BVX1dBVENILCA2NCwKCQl7MzIsIDUxMiwgMiwgMH0sIHszMiwgNTEyLCAyLCAw
fSwgCgkJezAsMCwwLE1JUFNfQ0FDSEVfTkVFRFNfQ09ORklHfSwgezAsMCwwLDB9fSwKfTsKCi8q
CiAqIFRoaXMgZnVuY3Rpb24gaXMgcnVubmluZyBvbiB0aGUgYm9vdCBwcm9tIHN0YWNrLiBJdCBz
aG91bGQKICogbWluaW1pemUgdXNlIG9mIGR5bmFtaWMgdmFyaWFibGVzIGFuZCBjYWxsIGFuIGFi
c29sdXRlCiAqIG1pbmltdW0gb2Ygb3RoZXIgZnVuY3Rpb25zLgogKi8KCl9faW5pdGZ1bmModm9p
ZCBtaXBzX2NwdV9wcm9iZSh1bnNpZ25lZCBpbnQgcHJfaWQpKQp7CglpbnQgaTsKCiNpZmRlZiBD
T05GSUdfQ1BVX01JUFMzMgoJLyoKCSAqIElmIGhpZ2gtb3JkZXIgaGFsZndvcmQgbm9uLXplcm8s
IHVzZSBNSVBTMzIgbWVjaGFuaXNtCgkgKi8KCWlmKChwcl9pZCA+PiAxNikgIT0gMCkgewoJCW1p
cHMzMl9jcHVfcHJvYmUocHJfaWQpOwoJCXJldHVybjsKCX0KI2VuZGlmCgoJLyoKCSAqIElmIG9s
ZCBlbmNvZGluZyBzY2hlbWUgYW5kIENQVSBpbiB0YWJsZSwgZmluZCBhbmQgY29weS4KCSAqCgkg
KiBGaXJzdCB0cnkgZm9yIG1hdGNoIGluY2x1ZGluZyByZXZpc2lvbiBudW1iZXIKCSAqLwoKCWZv
cihpPTA7IG1pcHNfY3B1X3RlbXBsYXRlW2ldLnByb2Nlc3Nvcl9pZCAhPSAwOyBpKyspIHsKCQlp
ZihtaXBzX2NwdV90ZW1wbGF0ZVtpXS5wcm9jZXNzb3JfaWQgPT0gcHJfaWQpIHsKCQkJbWVtY3B5
KCZtaXBzX2NwdSwgJm1pcHNfY3B1X3RlbXBsYXRlW2ldLAoJCQkJc2l6ZW9mKHN0cnVjdCBtaXBz
X2NwdSkpOwoJCQlyZXR1cm47CgkJfQoJfQoKCS8qCgkgKiBUaGF0IGZhaWxpbmcsIGxvb2sgZm9y
IG1hdGNoIG9uIGltcGxlbWVudGF0aW9uIG9ubHkKCSAqLwoKCWZvcihpPTA7IG1pcHNfY3B1X3Rl
bXBsYXRlW2ldLnByb2Nlc3Nvcl9pZCAhPSAwOyBpKyspIHsKCQlpZigobWlwc19jcHVfdGVtcGxh
dGVbaV0ucHJvY2Vzc29yX2lkICYgUFJJRF9JTVBfVU5LTk9XTikKCQkgICAgPT0gKHByX2lkICYg
UFJJRF9JTVBfVU5LTk9XTikpIHsKCQkJbWVtY3B5KCZtaXBzX2NwdSwgJm1pcHNfY3B1X3RlbXBs
YXRlW2ldLAoJCQkJc2l6ZW9mKHN0cnVjdCBtaXBzX2NwdSkpOwoJCQlyZXR1cm47CgkJfQoJfQoK
CS8qCgkgKiBPdGhlcndpc2UgQ1BVIGlzIHVua25vd24gLSBhbGwgYmV0cyBhcmUgb2ZmCgkgKi8K
CgltaXBzX2NwdS5wcm9jZXNzb3JfaWQgPSBwcl9pZDsKCW1pcHNfY3B1LmNwdXR5cGUgPSBDUFVf
VU5LTk9XTjsKCW1pcHNfY3B1Lm9wdGlvbnMgPSAwOwoJbWlwc19jcHUuaWNhY2hlLmZsYWdzID0g
TUlQU19DQUNIRV9ORUVEU19DT05GSUc7CgltaXBzX2NwdS5kY2FjaGUuZmxhZ3MgPSBNSVBTX0NB
Q0hFX05FRURTX0NPTkZJRzsKCW1pcHNfY3B1LnNjYWNoZS5mbGFncyA9IE1JUFNfQ0FDSEVfTkVF
RFNfQ09ORklHOwoJcmV0dXJuOwp9Cgo=

------=_NextPart_000_0083_01BFFC6C.24323180--


From owner-linux-mips@oss.sgi.com Wed Aug  2 10:09:53 2000
Received:  by oss.sgi.com id <S42244AbQHBRJn>;
	Wed, 2 Aug 2000 10:09:43 -0700
Received: from pneumatic-tube.sgi.com ([204.94.214.22]:47115 "EHLO
        pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP
	id <S42225AbQHBRJO>; Wed, 2 Aug 2000 10:09:14 -0700
Received: from nodin.corp.sgi.com (nodin.corp.sgi.com [192.26.51.193]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id KAA04140
	for <linux-mips@oss.sgi.com>; Wed, 2 Aug 2000 10:14:38 -0700 (PDT)
	mail_from (jsun@mvista.com)
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by nodin.corp.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) via ESMTP id KAA87606 for <linux-mips@oss.sgi.com>; Wed, 2 Aug 2000 10:08:11 -0700 (PDT)
Received: from sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id KAA72901
	for <linux@cthulhu.engr.sgi.com>;
	Wed, 2 Aug 2000 10:06:26 -0700 (PDT)
	mail_from (jsun@mvista.com)
Received: from hermes.mvista.com (gateway-490.mvista.com [63.192.220.206]) 
	by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam:
       SGI does not authorize the use of its proprietary
       systems or networks for unsolicited or bulk email
       from the Internet.) 
	via ESMTP id KAA02205
	for <linux@cthulhu.engr.sgi.com>; Wed, 2 Aug 2000 10:06:17 -0700 (PDT)
	mail_from (jsun@mvista.com)
Received: from mvista.com (IDENT:jsun@orion.mvista.com [10.0.0.75])
	by hermes.mvista.com (8.9.3/8.9.3) with ESMTP id KAA14494;
	Wed, 2 Aug 2000 10:05:58 -0700
Message-ID: <398854F5.EB3E73D6@mvista.com>
Date:   Wed, 02 Aug 2000 10:05:57 -0700
From:   Jun Sun <jsun@mvista.com>
X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.12-20b i586)
X-Accept-Language: en
MIME-Version: 1.0
To:     "Kevin D. Kissell" <kevink@mips.com>
CC:     linux@cthulhu.engr.sgi.com, linux-mips@fnet.fr, ralf@oss.sgi.com
Subject: Re: PROPOSAL : multi-way cache support in Linux/MIPS
References: <008601bffc5b$6714c0a0$0deca8c0@Ulysses>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing


Kevin,

This looks great, something exactly I was hoping for!

A couple of questions :

. What about the actual cache operation routines (flush_cache_page,
...)?  Are they divided into R4xxx, R3xx, etc?  I guess I am curious how
the code is organized.

. Your structure gives the number of ways, but no info about how to
select a way.  How would do an index-based cache operation?  It seems to
me you probably need something like cache_way_selection_offset in the
cpu table.

Jun

"Kevin D. Kissell" wrote:
> 
> Rather than re-invent the wheel, please consider the
> cache descriptor data structures we developed at
> MIPS to deal with this problem.  I believe that the
> updated cache.h file, and maybe even the cpu_probe.c
> file, was checked into the 2.2 repository at SGI long ago.
> There are also a set of initialisation and invalidation routines
> that key off the cache descriptor structure, but those aren't
> in the SGI  repository (though anyone can get them from
> ftp.mips.com or www.paralogos.com).  The CPU probe
> logic (also on those sites, and already integrated
> into several variants because it also supports setting
> up state needed by the software FPU emulation)
> is table-based, and for each PrID value, there is
> a template for the cache characteristics, which
> can either be taken "as is" or probed, depending
> on a flag in the descriptor.  Since the number of
> "ways" cannot always be determined by probing,
> if the number of ways is specified, it is preserved
> even if a cache probe is performed.   I won't attach the
> full set of cache probe routines (which would only confuse
> things), but here is the cache data structure definition
> and the CPU descriptor template table that we use.
> 

...

From owner-linux-mips@oss.sgi.com Wed Aug  2 11:14:14 2000
Received:  by oss.sgi.com id <S42284AbQHBSOE>;
	Wed, 2 Aug 2000 11:14:04 -0700
Received: from pneumatic-tube.sgi.com ([204.94.214.22]:39960 "EHLO
        pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP
	id <S42282AbQHBSNo>; Wed, 2 Aug 2000 11:13:44 -0700
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id LAA05838
	for <linux-mips@oss.sgi.com>; Wed, 2 Aug 2000 11:19:05 -0700 (PDT)
	mail_from (dom@mudchute.algor.co.uk)
Received: from sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id LAA42365
	for <linux@engr.sgi.com>;
	Wed, 2 Aug 2000 11:12:45 -0700 (PDT)
	mail_from (dom@mudchute.algor.co.uk)
Received: from kenton.algor.co.uk (kenton.algor.co.uk [193.117.190.25]) 
	by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam:
       SGI does not authorize the use of its proprietary
       systems or networks for unsolicited or bulk email
       from the Internet.) 
	via ESMTP id LAA02652
	for <linux@engr.sgi.com>; Wed, 2 Aug 2000 11:12:43 -0700 (PDT)
	mail_from (dom@mudchute.algor.co.uk)
Received: from mudchute.algor.co.uk (dom@mudchute.algor.co.uk [193.117.190.19])
	by kenton.algor.co.uk (8.8.8/8.8.8) with ESMTP id TAA01458;
	Wed, 2 Aug 2000 19:12:38 +0100 (GMT/BST)
Received: (from dom@localhost)
	by mudchute.algor.co.uk (8.8.5/8.8.5) id TAA11550;
	Wed, 2 Aug 2000 19:12:34 +0100 (BST)
Date:   Wed, 2 Aug 2000 19:12:34 +0100 (BST)
Message-Id: <200008021812.TAA11550@mudchute.algor.co.uk>
From:   Dominic Sweetman <dom@algor.co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
To:     Jun Sun <jsun@mvista.com>
Cc:     linux@cthulhu.engr.sgi.com, linux-mips@fnet.fr, ralf@oss.sgi.com
Subject: Re: PROPOSAL : multi-way cache support in Linux/MIPS
In-Reply-To: <398762B9.D8507860@mvista.com>
References: <398762B9.D8507860@mvista.com>
X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing


Jun Sun (jsun@mvista.com) writes:

> The first issue is multi-way cache support.  DDB5476 uses R5432 CPU
> which has two-way set-associative cache.  The problematic part is
> the index-based cache operations in r4xxcache.h does not cover all
> ways in a set.
> 
> I think this is a problem in general.  So far I have seen MIPS
> processors with 2-way, 4-way and 8-way sets.  And I have seen them
> using ether least- significant-addressing-bits or
> most-significant-addressing-bits within a cache line to select ways.

So far as I know the Vr5432 is the only CPU to do anything so silly as
using the lowest index bits to select the "way".  Certainly most CPUs
put the "way" bits above the cache-store-index; and MIPS now require
it to be done like that for MIPS32 and MIPS64 compatible parts.

The MS-selects-way organisation permits the cache to be initialised
without the software ever needing to know how many ways it has (just
crank the index up, but being careful about the tendency to recycle
the same way when pre-filling cache data).

Cache maintenance should always use "hit" type instructions, and you
don't need to know the cache organisation for those, even with the
Vr5432. 

I suggest you should implement the don't-care method, and then have a
cpu_info-driven special case for the unique and deprecated Vr5432.

Dominic Sweetman
Algorithmics Ltd
dom@algor.co.uk

From owner-linux-mips@oss.sgi.com Wed Aug  2 11:15:14 2000
Received:  by oss.sgi.com id <S42225AbQHBSPE>;
	Wed, 2 Aug 2000 11:15:04 -0700
Received: from pneumatic-tube.sgi.com ([204.94.214.22]:61720 "EHLO
        pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP
	id <S42282AbQHBSOl>; Wed, 2 Aug 2000 11:14:41 -0700
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id LAA04652
	for <linux-mips@oss.sgi.com>; Wed, 2 Aug 2000 11:20:05 -0700 (PDT)
	mail_from (kevink@mips.com)
Received: from sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id LAA95454
	for <linux@cthulhu.engr.sgi.com>;
	Wed, 2 Aug 2000 11:13:54 -0700 (PDT)
	mail_from (kevink@mips.com)
Received: from mx.mips.com (mx.mips.com [206.31.31.226]) 
	by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam:
       SGI does not authorize the use of its proprietary
       systems or networks for unsolicited or bulk email
       from the Internet.) 
	via ESMTP id LAA02909
	for <linux@cthulhu.engr.sgi.com>; Wed, 2 Aug 2000 11:13:54 -0700 (PDT)
	mail_from (kevink@mips.com)
Received: from newman.mips.com (ns-dmz [206.31.31.225])
	by mx.mips.com (8.9.3/8.9.0) with ESMTP id LAA03103;
	Wed, 2 Aug 2000 11:12:42 -0700 (PDT)
Received: from Ulysses (ulysses [192.168.236.13])
	by newman.mips.com (8.9.3/8.9.0) with SMTP id LAA28193;
	Wed, 2 Aug 2000 11:12:42 -0700 (PDT)
Message-ID: <01ac01bffcad$a767c240$0deca8c0@Ulysses>
From:   "Kevin D. Kissell" <kevink@mips.com>
To:     "Jun Sun" <jsun@mvista.com>
Cc:     <linux@cthulhu.engr.sgi.com>, <linux-mips@fnet.fr>,
        <ralf@oss.sgi.com>
Subject: Re: PROPOSAL : multi-way cache support in Linux/MIPS
Date:   Wed, 2 Aug 2000 20:15:24 +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 4.72.3110.1
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing

-->A couple of questions :
>
>. What about the actual cache operation routines (flush_cache_page,
>...)?  Are they divided into R4xxx, R3xx, etc?  I guess I am curious how
>the code is organized.

We kept pretty much the existing 2.2 structure for these things.
We created the module "r4k.c" in arch/mips/mm which was
essentially parallel to the old r4xx0.c module, but which implemented
the various TLB and cache functions (a) using the information in
the mips_cpu structure wherever it made sense and (b) in ways
that are fully compatible with the "MIPS32" ISA+CP0 model
as well as with the original R4000 family and its descendants.
It's possible to write code that is compatible with an R4000 but
not MIPS32, and vice versa, but they are 99% identical.  

>. Your structure gives the number of ways, but no info about how to
>select a way.  How would do an index-based cache operation?  It seems to
>me you probably need something like cache_way_selection_offset in the
>cpu table.


The MIPS32 spec for the CACHE instruction gives a trivial
mapping from sets/ways/linesize into CACHE instruction
operands.  In fact, the same technique works for most pre
MIPS32 multi-way caches as well.  The only exception that
comes to mind is the R10000.  If one wanted to support the
R10K or other oddball CACHE-implementations in this
system, I would suggest adding a  MIPS_CACHE_R10KWAYSEL 
or some flag to the flags field of the cache descriptor,
and tweaking any routines that need to select indices 
(such a routine to hunt down and kill all possible virtual 
aliases of an address) to handle the special case.

The primitives in Linux 2.2 did not require much knowedge 
of multi-way caches as such - they could all be implemented
either using hit-based CACHE operations, or by cycling
through all possible indices using knowledge of the total
size and the line size.  But the newer synthesizable MIPS
cores allow cache configurations to be "dialed in" in ways
that the old code could not handle.  The CPUs themselves
can be interrogated to determine the line size/nways/nsets
geometry, so we mirror that in the Linux code and use those
parameters to compute total size, way size, etc.  The 
PrID-based lookup table and the dynamic probe routines
are there to allow older parts to use the same mechanisms.

            Regards,

            Kevin K.


From owner-linux-mips@oss.sgi.com Wed Aug  2 11:36:23 2000
Received:  by oss.sgi.com id <S42285AbQHBSgD>;
	Wed, 2 Aug 2000 11:36:03 -0700
Received: from pneumatic-tube.sgi.com ([204.94.214.22]:4636 "EHLO
        pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP
	id <S42282AbQHBSff>; Wed, 2 Aug 2000 11:35:35 -0700
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id LAA08923
	for <linux-mips@oss.sgi.com>; Wed, 2 Aug 2000 11:40:58 -0700 (PDT)
	mail_from (kevink@mips.com)
Received: from sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id LAA23562
	for <linux@cthulhu.engr.sgi.com>;
	Wed, 2 Aug 2000 11:34:47 -0700 (PDT)
	mail_from (kevink@mips.com)
Received: from mx.mips.com (mx.mips.com [206.31.31.226]) 
	by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam:
       SGI does not authorize the use of its proprietary
       systems or networks for unsolicited or bulk email
       from the Internet.) 
	via ESMTP id LAA00027
	for <linux@cthulhu.engr.sgi.com>; Wed, 2 Aug 2000 11:34:46 -0700 (PDT)
	mail_from (kevink@mips.com)
Received: from newman.mips.com (ns-dmz [206.31.31.225])
	by mx.mips.com (8.9.3/8.9.0) with ESMTP id LAA03354;
	Wed, 2 Aug 2000 11:33:34 -0700 (PDT)
Received: from Ulysses (ulysses [192.168.236.13])
	by newman.mips.com (8.9.3/8.9.0) with SMTP id LAA29718;
	Wed, 2 Aug 2000 11:33:34 -0700 (PDT)
Message-ID: <01c901bffcb0$922057a0$0deca8c0@Ulysses>
From:   "Kevin D. Kissell" <kevink@mips.com>
To:     "Dominic Sweetman" <dom@algor.co.uk>, "Jun Sun" <jsun@mvista.com>
Cc:     <linux@cthulhu.engr.sgi.com>, <linux-mips@fnet.fr>,
        <ralf@oss.sgi.com>
Subject: Re: PROPOSAL : multi-way cache support in Linux/MIPS
Date:   Wed, 2 Aug 2000 20:36:17 +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 4.72.3110.1
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing

Dom Sweetman writes:
>So far as I know the Vr5432 is the only CPU to do anything so silly as
>using the lowest index bits to select the "way". 

Alas, the R10000 does the same silly thing, and while you
and I might not consider such a venerable processor interesting
for new embedded MIPS/Linux designs, our friends who
are trying to replace IRIX with Linux on their SGI boxes
are going to have to deal with them for a little while longer.

>The MS-selects-way organisation permits the cache to be initialised
>without the software ever needing to know how many ways it has (just
>crank the index up, but being careful about the tendency to recycle
>the same way when pre-filling cache data).

Which is why MIPS belatedly documented it as the "correct"
way to design a multiway cache...

>Cache maintenance should always use "hit" type instructions, and you
>don't need to know the cache organisation for those, even with the
>Vr5432.

The counterargument to *always* using "hit" ops is that they
generate TLB traffic and TLB refills, which some people
find annoying to allow for and in any case time consuming.


            Regards,

            Kevin K.



From owner-linux-mips@oss.sgi.com Wed Aug  2 14:41:54 2000
Received:  by oss.sgi.com id <S42294AbQHBVlo>;
	Wed, 2 Aug 2000 14:41:44 -0700
Received: from deliverator.sgi.com ([204.94.214.10]:25137 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S42290AbQHBVlM>;
	Wed, 2 Aug 2000 14:41:12 -0700
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id OAA18989
	for <linux-mips@oss.sgi.com>; Wed, 2 Aug 2000 14:33:07 -0700 (PDT)
	mail_from (jsun@mvista.com)
Received: from sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id OAA58583
	for <linux@engr.sgi.com>;
	Wed, 2 Aug 2000 14:40:11 -0700 (PDT)
	mail_from (jsun@mvista.com)
Received: from hermes.mvista.com (gateway-490.mvista.com [63.192.220.206]) 
	by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam:
       SGI does not authorize the use of its proprietary
       systems or networks for unsolicited or bulk email
       from the Internet.) 
	via ESMTP id OAA06345
	for <linux@engr.sgi.com>; Wed, 2 Aug 2000 14:40:04 -0700 (PDT)
	mail_from (jsun@mvista.com)
Received: from mvista.com (IDENT:jsun@orion.mvista.com [10.0.0.75])
	by hermes.mvista.com (8.9.3/8.9.3) with ESMTP id OAA25892;
	Wed, 2 Aug 2000 14:38:52 -0700
Message-ID: <398894EC.233BB004@mvista.com>
Date:   Wed, 02 Aug 2000 14:38:52 -0700
From:   Jun Sun <jsun@mvista.com>
X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.12-20b i586)
X-Accept-Language: en
MIME-Version: 1.0
To:     Dominic Sweetman <dom@algor.co.uk>
CC:     linux@cthulhu.engr.sgi.com, linux-mips@fnet.fr, ralf@oss.sgi.com
Subject: Re: PROPOSAL : multi-way cache support in Linux/MIPS
References: <398762B9.D8507860@mvista.com> <200008021812.TAA11550@mudchute.algor.co.uk>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing

Dominic Sweetman wrote:
> 
> Jun Sun (jsun@mvista.com) writes:
> 
> > The first issue is multi-way cache support.  DDB5476 uses R5432 CPU
> > which has two-way set-associative cache.  The problematic part is
> > the index-based cache operations in r4xxcache.h does not cover all
> > ways in a set.
> >
> > I think this is a problem in general.  So far I have seen MIPS
> > processors with 2-way, 4-way and 8-way sets.  And I have seen them
> > using ether least- significant-addressing-bits or
> > most-significant-addressing-bits within a cache line to select ways.
> 
> So far as I know the Vr5432 is the only CPU to do anything so silly as
> using the lowest index bits to select the "way". 

Actually Sony's R4500 uses the same low bits mechanism.

> Cache maintenance should always use "hit" type instructions, and you
> don't need to know the cache organisation for those, even with the
> Vr5432.
> 

Ideally - but no in reality.  Linux stills uses index-operations a lot.

Theorically, indexed flush is faster if the flushing are is bigger than
the cache size.

> I suggest you should implement the don't-care method, and then have a
> cpu_info-driven special case for the unique and deprecated Vr5432.
> 

If Vr5432 is really that unique, I think that is probably best way, at
least for now.

Jun

From owner-linux-mips@oss.sgi.com Wed Aug  2 14:52:24 2000
Received:  by oss.sgi.com id <S42296AbQHBVwO>;
	Wed, 2 Aug 2000 14:52:14 -0700
Received: from deliverator.sgi.com ([204.94.214.10]:20788 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S42290AbQHBVvi>;
	Wed, 2 Aug 2000 14:51:38 -0700
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id OAA20421
	for <linux-mips@oss.sgi.com>; Wed, 2 Aug 2000 14:43:34 -0700 (PDT)
	mail_from (jsun@mvista.com)
Received: from sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id OAA99309
	for <linux@cthulhu.engr.sgi.com>;
	Wed, 2 Aug 2000 14:50:50 -0700 (PDT)
	mail_from (jsun@mvista.com)
Received: from hermes.mvista.com (gateway-490.mvista.com [63.192.220.206]) 
	by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam:
       SGI does not authorize the use of its proprietary
       systems or networks for unsolicited or bulk email
       from the Internet.) 
	via ESMTP id OAA04469
	for <linux@cthulhu.engr.sgi.com>; Wed, 2 Aug 2000 14:50:39 -0700 (PDT)
	mail_from (jsun@mvista.com)
Received: from mvista.com (IDENT:jsun@orion.mvista.com [10.0.0.75])
	by hermes.mvista.com (8.9.3/8.9.3) with ESMTP id OAA26491;
	Wed, 2 Aug 2000 14:50:19 -0700
Message-ID: <3988979B.D264F549@mvista.com>
Date:   Wed, 02 Aug 2000 14:50:19 -0700
From:   Jun Sun <jsun@mvista.com>
X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.12-20b i586)
X-Accept-Language: en
MIME-Version: 1.0
To:     "Kevin D. Kissell" <kevink@mips.com>
CC:     linux@cthulhu.engr.sgi.com, linux-mips@fnet.fr, ralf@oss.sgi.com
Subject: Re: PROPOSAL : multi-way cache support in Linux/MIPS
References: <01ac01bffcad$a767c240$0deca8c0@Ulysses>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing

"Kevin D. Kissell" wrote:
> It's possible to write code that is compatible with an R4000 but
> not MIPS32, and vice versa, but they are 99% identical.
> 

Kevin,

Is that possible you can list the 1% difference here?  

I have always been confused by MIPS32/MIPS64 vs R3000/R4000/etc.  (And
on top of it, there is also MIPS I, II, III, IV, etc...).  I am sure I
am not the only one.

If you can give an pointer that will clarify names, that would be good
too.


Jun

From owner-linux-mips@oss.sgi.com Wed Aug  2 15:44:03 2000
Received:  by oss.sgi.com id <S42300AbQHBWnx>;
	Wed, 2 Aug 2000 15:43:53 -0700
Received: from pneumatic-tube.sgi.com ([204.94.214.22]:24124 "EHLO
        pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP
	id <S42290AbQHBWn2>; Wed, 2 Aug 2000 15:43:28 -0700
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id PAA09939
	for <linux-mips@oss.sgi.com>; Wed, 2 Aug 2000 15:48:51 -0700 (PDT)
	mail_from (kevink@mips.com)
Received: from sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id PAA83501
	for <linux@cthulhu.engr.sgi.com>;
	Wed, 2 Aug 2000 15:42:40 -0700 (PDT)
	mail_from (kevink@mips.com)
Received: from mx.mips.com (mx.mips.com [206.31.31.226]) 
	by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam:
       SGI does not authorize the use of its proprietary
       systems or networks for unsolicited or bulk email
       from the Internet.) 
	via ESMTP id PAA06846
	for <linux@cthulhu.engr.sgi.com>; Wed, 2 Aug 2000 15:42:39 -0700 (PDT)
	mail_from (kevink@mips.com)
Received: from newman.mips.com (ns-dmz [206.31.31.225])
	by mx.mips.com (8.9.3/8.9.0) with ESMTP id PAA05710;
	Wed, 2 Aug 2000 15:41:27 -0700 (PDT)
Received: from Ulysses (ulysses [192.168.236.13])
	by newman.mips.com (8.9.3/8.9.0) with SMTP id PAA06909;
	Wed, 2 Aug 2000 15:41:27 -0700 (PDT)
Message-ID: <027f01bffcd3$3279b800$0deca8c0@Ulysses>
From:   "Kevin D. Kissell" <kevink@mips.com>
To:     "Jun Sun" <jsun@mvista.com>
Cc:     <linux@cthulhu.engr.sgi.com>, <linux-mips@fnet.fr>,
        <ralf@oss.sgi.com>
Subject: Re: PROPOSAL : multi-way cache support in Linux/MIPS
Date:   Thu, 3 Aug 2000 00:44:17 +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 4.72.3110.1
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing

>> It's possible to write code that is compatible with an R4000 but
>> not MIPS32, and vice versa, but they are 99% identical.
>
>Is that possible you can list the 1% difference here?  
>
>I have always been confused by MIPS32/MIPS64 vs R3000/R4000/etc.  (And
>on top of it, there is also MIPS I, II, III, IV, etc...).  I am sure I
>am not the only one.


MIPS I, II, III, IV, and V are ISAs, instruction-set architectures.
R3000, R4000, R5000, R6000, R7000, R8000 et. al.
are microprocessor designs that conform (more-or-less)
to one of those ISAs.   The ISAs were defined in such a
way as to be strict supersets of one another.  Any MIPS
processor can run MIPS I code.  Any MIPS IV processor
can run MIPS I, II, III, and IV code, etc.  To oversimplify
slightly:

MIPS I - basic 32-bit RISC ISA
MIPS II - add branch-likely and Test instructions
MIPS III - add 64-bit address and 64-bit data support
MIPS IV - add FP MAC, Prefetch
MIPS V - add "paired single" SIMD FP instructions

As defined by MIPS in the beginning, the ISA - i.e. MIPS I, 
MIPS II, etc. - described the machine as seen from the 
standpoint of a user-mode application program.  The 
CP0 instructions and registers weren't considered a part 
of it.  This gave chip designers a lot of freedom and OS
writers a lot of headaches.  The R8000, for example, was
the first MIPS IV CPU, and is 100% (well, maybe 99.99%)
compatible with the MIPS IV R10000 at the user binary level.
But while the R10000 has a CP0 organization that is
a straightforward extrapolation of the R4000 - they
wanted it to run NT, after all - the R8000 is just bizzare.

Another problem with the way things had been done
in the MIPS I/II/III days was that, due to the strict supersetting
rules, any new feature had to ride on the back of all the
other cool new features that came before it.  As a specific
example, PREFetch is a MIPS IV instruction. But MIPS IV 
implies MIPS III, and MIPS III implies a 64-bit CPU.  So a 
32-bit CPU supporting prefetch, which is a fairly obviously 
useful thing, does not fit neatly into the model.  So...

When MIPS Technologies spun back out of SGI, one of
the first things that was done was to set about defining
standard architectures for 32 and 64-bit CPUs that
solved these problems.  These new standard architectures
are "MIPS32" and "MIPS64".   These architectures include
both the ISA and the privileged resource architecture, or
PRA, so that CP0 is finally standardised - with some amount
of permitted subsetting and implementation-specific details
allowed, just the same.  The MIPS32 ISA includes features
from MIPS I, II, III, IV, and V, as well as some stuff like
integer MADD, MSUB, CLZ, and CLO that had never
made it into the standard user mode ISA.  But MIPS32
has no 64-bit operations.  MIPS64 is the full-blown 64-bit 
MIPS I-V+ ISA plus a PRA that is a strict superset of the 
MIPS32 PRA.

So, to get back to Linux, a MIPS32 part can *almost*
run the standard MIPS R4K kernel.  Almost.  What had
to be fixed was essentially:

    - ensuring that TLB initialization and invalidation never
       write identical (even though invalid) entries to the TLB.
       MIPS32 parts are allowed to complain about that, and
       some of them do.
    - ensuring that no 64-bit instructions are ever used.  This
       necessitated my rewriting the semaphore support code.
    - eliminating certain assumptions about the relationship
       between cache size, line size, and associativity.

Note that none of this stuff is incompatible with an R4xxx
or an R5xxx, its just a matter of being a little more generic.
And of course the flip side is that we don't use prefetch,
MADD, or CLZ in the kernel either, because the MIPS III-IV
parts can't handle them (well, OK, some of them can).

            Hope this helps,

            Keivn K.


From owner-linux-mips@oss.sgi.com Wed Aug  2 16:13:04 2000
Received:  by oss.sgi.com id <S42302AbQHBXMx>;
	Wed, 2 Aug 2000 16:12:53 -0700
Received: from deliverator.sgi.com ([204.94.214.10]:2635 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S42290AbQHBXMa>;
	Wed, 2 Aug 2000 16:12:30 -0700
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id QAA00891
	for <linux-mips@oss.sgi.com>; Wed, 2 Aug 2000 16:04:25 -0700 (PDT)
	mail_from (jsun@mvista.com)
Received: from sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id QAA93251
	for <linux@cthulhu.engr.sgi.com>;
	Wed, 2 Aug 2000 16:11:34 -0700 (PDT)
	mail_from (jsun@mvista.com)
Received: from hermes.mvista.com (gateway-490.mvista.com [63.192.220.206]) 
	by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam:
       SGI does not authorize the use of its proprietary
       systems or networks for unsolicited or bulk email
       from the Internet.) 
	via ESMTP id QAA04382
	for <linux@cthulhu.engr.sgi.com>; Wed, 2 Aug 2000 16:11:07 -0700 (PDT)
	mail_from (jsun@mvista.com)
Received: from mvista.com (IDENT:jsun@orion.mvista.com [10.0.0.75])
	by hermes.mvista.com (8.9.3/8.9.3) with ESMTP id QAA30268;
	Wed, 2 Aug 2000 16:10:43 -0700
Message-ID: <3988AA72.5C342E1D@mvista.com>
Date:   Wed, 02 Aug 2000 16:10:43 -0700
From:   Jun Sun <jsun@mvista.com>
X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.12-20b i586)
X-Accept-Language: en
MIME-Version: 1.0
To:     "Kevin D. Kissell" <kevink@mips.com>
CC:     linux@cthulhu.engr.sgi.com, linux-mips@fnet.fr, ralf@oss.sgi.com
Subject: Re: PROPOSAL : multi-way cache support in Linux/MIPS
References: <027f01bffcd3$3279b800$0deca8c0@Ulysses>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing


That certainly helps a lot.  Thanks, Kevin.


"Kevin D. Kissell" wrote:
...
> 
> So, to get back to Linux, a MIPS32 part can *almost*
> run the standard MIPS R4K kernel.  Almost.  What had

Still one more question.  If I understand correctly, the 4Km and 4Kp are
MIPS32 CPUs.  However, they don't have TLBs.  Right?  Without TLBs, I
don't suppose Linux will run ...

Jun

From owner-linux-mips@oss.sgi.com Wed Aug  2 16:35:33 2000
Received:  by oss.sgi.com id <S42290AbQHBXfY>;
	Wed, 2 Aug 2000 16:35:24 -0700
Received: from deliverator.sgi.com ([204.94.214.10]:12370 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S42245AbQHBXfG>;
	Wed, 2 Aug 2000 16:35:06 -0700
Received: from nodin.corp.sgi.com (nodin.corp.sgi.com [192.26.51.193]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id QAA03693
	for <linux-mips@oss.sgi.com>; Wed, 2 Aug 2000 16:27:01 -0700 (PDT)
	mail_from (ralf@oss.sgi.com)
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by nodin.corp.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) via ESMTP id QAA89506 for <linux-mips@oss.sgi.com>; Wed, 2 Aug 2000 16:34:03 -0700 (PDT)
Received: from sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id QAA99875
	for <linux@cthulhu.engr.sgi.com>;
	Wed, 2 Aug 2000 16:32:30 -0700 (PDT)
	mail_from (ralf@oss.sgi.com)
Received: from u-100.karlsruhe.ipdial.viaginterkom.de (u-100.karlsruhe.ipdial.viaginterkom.de [62.180.19.100]) 
	by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam:
       SGI does not authorize the use of its proprietary
       systems or networks for unsolicited or bulk email
       from the Internet.) 
	via ESMTP id QAA08996
	for <linux@cthulhu.engr.sgi.com>; Wed, 2 Aug 2000 16:32:25 -0700 (PDT)
	mail_from (ralf@oss.sgi.com)
Received: (ralf@lappi) by lappi.waldorf-gmbh.de id <S869096AbQHBXbz>;
        Thu, 3 Aug 2000 01:31:55 +0200
Date:   Thu, 3 Aug 2000 01:31:55 +0200
From:   Ralf Baechle <ralf@oss.sgi.com>
To:     Jun Sun <jsun@mvista.com>
Cc:     "Kevin D. Kissell" <kevink@mips.com>, linux@cthulhu.engr.sgi.com,
        linux-mips@fnet.fr
Subject: Re: PROPOSAL : multi-way cache support in Linux/MIPS
Message-ID: <20000803013155.A2097@bacchus.dhis.org>
References: <027f01bffcd3$3279b800$0deca8c0@Ulysses> <3988AA72.5C342E1D@mvista.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0.1i
In-Reply-To: <3988AA72.5C342E1D@mvista.com>; from jsun@mvista.com on Wed, Aug 02, 2000 at 04:10:43PM -0700
X-Accept-Language: de,en,fr
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing

On Wed, Aug 02, 2000 at 04:10:43PM -0700, Jun Sun wrote:

> > So, to get back to Linux, a MIPS32 part can *almost*
> > run the standard MIPS R4K kernel.  Almost.  What had
> 
> Still one more question.  If I understand correctly, the 4Km and 4Kp are
> MIPS32 CPUs.  However, they don't have TLBs.  Right?  Without TLBs, I
> don't suppose Linux will run ...

There is ``Microcontroller Linux'' aka uclinux available at www.uclinux.org.
It could be ported to TLB-less processors.  You'd loose some of the
important functionality of the standard Linux, including some source
compatibility.

  Ralf

From owner-linux-mips@oss.sgi.com Thu Aug  3 08:26:48 2000
Received:  by oss.sgi.com id <S42308AbQHCP0i>;
	Thu, 3 Aug 2000 08:26:38 -0700
Received: from deliverator.sgi.com ([204.94.214.10]:51290 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S42210AbQHCP0H>;
	Thu, 3 Aug 2000 08:26:07 -0700
Received: from nodin.corp.sgi.com (nodin.corp.sgi.com [192.26.51.193]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id IAA11056
	for <linux-mips@oss.sgi.com>; Thu, 3 Aug 2000 08:17:59 -0700 (PDT)
	mail_from (rblander@math.uwaterloo.ca)
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by nodin.corp.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) via ESMTP id IAA13376 for <linux-mips@oss.sgi.com>; Thu, 3 Aug 2000 08:25:01 -0700 (PDT)
Received: from sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id IAA06305
	for <linux@cthulhu.engr.sgi.com>;
	Thu, 3 Aug 2000 08:23:22 -0700 (PDT)
	mail_from (rblander@math.uwaterloo.ca)
Received: from math.uwaterloo.ca (math.uwaterloo.ca [129.97.140.144]) 
	by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam:
       SGI does not authorize the use of its proprietary
       systems or networks for unsolicited or bulk email
       from the Internet.) 
	via ESMTP id IAA00384
	for <linux@cthulhu.engr.sgi.com>; Thu, 3 Aug 2000 08:23:21 -0700 (PDT)
	mail_from (rblander@math.uwaterloo.ca)
Received: (from rblander@localhost)
	by math.uwaterloo.ca (8.8.8/8.8.8) id LAA32197;
	Thu, 3 Aug 2000 11:21:59 -0400 (EDT)
Date:   Thu, 3 Aug 2000 11:21:59 -0400 (EDT)
From:   "Robyn Landers [MFCF]" <rblander@math.uwaterloo.ca>
Message-Id: <200008031521.LAA32197@math.uwaterloo.ca>
To:     linux-mips@fnet.fr, linux@cthulhu.engr.sgi.com
Subject: Origin 2000 help
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing

Hi folks,

I hear from Ralf B. that somebody out there has got
Linux working on the Origin 2000 platform.
Please contact me about it.
Thanks.


-- Robyn Landers
rblanders@math.uwaterloo.ca		(519) 888-4567 x2030
( [ihnp4|decvax|allegra|utzoo]!watmath!rblanders rblanders@watmath.UUCP :-)
Math Faculty Computing Facility, University of Waterloo, Ontario, Canada

From owner-linux-mips@oss.sgi.com Thu Aug  3 08:36:58 2000
Received:  by oss.sgi.com id <S42309AbQHCPgu>;
	Thu, 3 Aug 2000 08:36:50 -0700
Received: from jester.ti.com ([192.94.94.1]:48085 "EHLO jester.ti.com")
	by oss.sgi.com with ESMTP id <S42210AbQHCPgT>;
	Thu, 3 Aug 2000 08:36:19 -0700
Received: from dlep7.itg.ti.com ([157.170.134.103])
	by jester.ti.com (8.10.1/8.10.1) with ESMTP id e73FYhX12723
	for <linux-mips@oss.sgi.com>; Thu, 3 Aug 2000 10:34:43 -0500 (CDT)
Received: from dlep7.itg.ti.com (localhost [127.0.0.1])
	by dlep7.itg.ti.com (8.9.3/8.9.3) with ESMTP id KAA16079
	for <linux-mips@oss.sgi.com>; Thu, 3 Aug 2000 10:35:35 -0500 (CDT)
Received: from dlep3.itg.ti.com (dlep3.itg.ti.com [157.170.188.62])
	by dlep7.itg.ti.com (8.9.3/8.9.3) with ESMTP id KAA16072
	for <linux-mips@oss.sgi.com>; Thu, 3 Aug 2000 10:35:35 -0500 (CDT)
Received: from ti.com (IDENT:bbrown@bbrown.sc.ti.com [158.218.100.168])
	by dlep3.itg.ti.com (8.9.3/8.9.3) with ESMTP id KAA05522
	for <linux-mips@oss.sgi.com>; Thu, 3 Aug 2000 10:35:41 -0500 (CDT)
Message-ID: <39899191.DE5F555D@ti.com>
Date:   Thu, 03 Aug 2000 09:36:49 -0600
From:   Brady Brown <bbrown@ti.com>
Organization: Texas Instruments
X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14-5.0 i686)
X-Accept-Language: en
MIME-Version: 1.0
To:     SGI news group <linux-mips@oss.sgi.com>
Subject: GLIBC version?
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing

I am updating from a 2.2.12 kernel to 2.4 on a MIPS32 little endian
architecture and have been trying to natively compile some new binaries
with no luck. It appears that my problem is an outdated glibc
(2.0.7-20). What glibc and glibc-devel versions are recommended for 2.4
and where do I find them?
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Brady Brown (bbrown@ti.com)       Work:(801)619-6103
Texas Instruments: Broadband Access Group
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~



From owner-linux-mips@oss.sgi.com Thu Aug  3 12:43:29 2000
Received:  by oss.sgi.com id <S42313AbQHCTnU>;
	Thu, 3 Aug 2000 12:43:20 -0700
Received: from deliverator.sgi.com ([204.94.214.10]:37425 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S42311AbQHCTm7>;
	Thu, 3 Aug 2000 12:42:59 -0700
Received: from nodin.corp.sgi.com (nodin.corp.sgi.com [192.26.51.193]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id MAA20503
	for <linux-mips@oss.sgi.com>; Thu, 3 Aug 2000 12:34:48 -0700 (PDT)
	mail_from (ulfc@calypso.engr.sgi.com)
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by nodin.corp.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) via ESMTP id MAA89295 for <linux-mips@oss.sgi.com>; Thu, 3 Aug 2000 12:41:50 -0700 (PDT)
Received: from calypso.engr.sgi.com (calypso.engr.sgi.com [163.154.5.113])
	by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id MAA86267;
	Thu, 3 Aug 2000 12:40:17 -0700 (PDT)
	mail_from (ulfc@calypso.engr.sgi.com)
Received: by calypso.engr.sgi.com (Postfix, from userid 37984)
	id 9A4D4A7875; Thu,  3 Aug 2000 12:38:43 -0700 (PDT)
To:     "Robyn Landers [MFCF]" <rblander@math.uwaterloo.ca>
Cc:     linux-mips@fnet.fr, linux@cthulhu.engr.sgi.com
Subject: Re: Origin 2000 help
References: <200008031521.LAA32197@math.uwaterloo.ca>
From:   Ulf Carlsson <ulfc@calypso.engr.sgi.com>
Date:   03 Aug 2000 12:38:43 -0700
In-Reply-To: "Robyn Landers [MFCF]"'s message of "Thu, 3 Aug 2000 11:21:59 -0400 (EDT)"
Message-ID: <6ovittiuocc.fsf@calypso.engr.sgi.com>
Lines:  18
X-Mailer: Gnus v5.7/Emacs 20.5
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing

Hi Robyn,

> I hear from Ralf B. that somebody out there has got
> Linux working on the Origin 2000 platform.

You can read about it at:

http://oss.sgi.com/projects/LinuxScalability/

I don't think anyone has written any complete instructions for getting
it running.  You could use a normal 32-bit Indy filesystem with a
MIPS64 kernel compiled from the Linux/MIPS CVS tree at oss.sgi.com.

The tools we use are located at:

ftp://oss.sgi.com/pub/linux/mips/crossdev/i386-linux/mips64-linux/

Ulf

From owner-linux-mips@oss.sgi.com Sat Aug  5 02:10:17 2000
Received:  by oss.sgi.com id <S42361AbQHEJKH>;
	Sat, 5 Aug 2000 02:10:07 -0700
Received: from pneumatic-tube.sgi.com ([204.94.214.22]:29447 "EHLO
        pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP
	id <S42228AbQHEJJx>; Sat, 5 Aug 2000 02:09:53 -0700
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id CAA00706; Sat, 5 Aug 2000 02:15:19 -0700 (PDT)
	mail_from (ezsooco7jle@aol.com)
From:   ezsooco7jle@aol.com
Received: from sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id CAA59175;
	Sat, 5 Aug 2000 02:09:05 -0700 (PDT)
	mail_from (ezsooco7jle@aol.com)
Received: from sv1.nl-zeus.or.jp (sv1.nl-zeus.or.jp [210.196.253.66]) 
	by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam:
       SGI does not authorize the use of its proprietary
       systems or networks for unsolicited or bulk email
       from the Internet.) 
	via SMTP id CAA05733; Sat, 5 Aug 2000 02:09:04 -0700 (PDT)
	mail_from (ezsooco7jle@aol.com)
Received: from 8848.net (sdn-ar-002flspetP222.dialsprint.net [168.191.80.238]) by sv1.nl-zeus.or.jp (SMI-8.6/3.4W2) with SMTP id SAA21060; Sat, 5 Aug 2000 18:13:59 +0900
Message-ID: <000033993769$00003745$00007107@mail.www.yu>
To:     <Undisclosed.Recipients@sv1.nl-zeus.or.jp>
Subject: Looking For A Great Home Based Business?
Date:   Sat, 05 Aug 2000 04:41:09 -0400
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Mircosoft Outlook Express 5.0
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing

Tired of the 40 X 40 X 40 Plan? You know: 

Work 40 hours per week for someone else for 40 years, then receive a 40% reduction in pay! 

Is working for a "boss" too demeaning and unrewarding? 

Are you sick of depending on a job with too little pay and too many hours with no personal reward and even less future?

If you're determined to retire in the next 2 - 5 years with enough income to have REAL Financial Independence and Freedom, and are not afraid to work for it, I can help you.

I am looking for people with a Good Work Ethic and extraordinary Desire to Earn at Least $10,000 per Month Working From Home!

NO SPECIAL SKILLS OR EXPERIENCE REQUIRED. We will give you all the training and personal support you will need to ensure your success!

This LEGITIMATE HOME-BASED INCOME OPPORTUNITY can put you back in Control of your Time, Your Finances, and Your Life!

If you've tried other opportunities in the past that have failed to live up to their promises, THIS IS DIFFERENT THAN ANYTHING ELSE YOU'VE SEEN!

THIS IS NOT A GET-RICH-QUICK SCHEME!

YOUR FINANCIAL PAST DOES NOT HAVE TO BE YOUR FINANCIAL FUTURE!

CALL ONLY IF YOU ARE SERIOUS!

1-800-457-0481 (Free, 24 hour, 2 minute recorded message)

DON'T GO TO SLEEP WITHOUT LISTENING TO THIS!

"All our dreams can come true - if we have the courage to pursue them" - Walt Disney



To be removed from future mailings, send an email to:  nope_02@yahoo.com and type "Remove" in the subject line.
















Tired of the 40 X 40 X 40 Plan? You know: 

Work 40 hours per week for someone else for 40 years, then receive a 40% reduction in pay! 

Is working for a "boss" too demeaning and unrewarding? 

Are you sick of depending on a job with too little pay and too many hours with no personal reward and even less future?






From owner-linux-mips@oss.sgi.com Sat Aug  5 16:15:04 2000
Received:  by oss.sgi.com id <S42366AbQHEXOy>;
	Sat, 5 Aug 2000 16:14:54 -0700
Received: from deliverator.sgi.com ([204.94.214.10]:23823 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S42228AbQHEXOU>;
	Sat, 5 Aug 2000 16:14:20 -0700
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id QAA09427
	for <linux-mips@oss.sgi.com>; Sat, 5 Aug 2000 16:06:16 -0700 (PDT)
	mail_from (philloc@janus.lsd.ornl.gov)
Received: from sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id QAA81498
	for <linux@cthulhu.engr.sgi.com>;
	Sat, 5 Aug 2000 16:13:32 -0700 (PDT)
	mail_from (philloc@janus.lsd.ornl.gov)
Received: from janus.lsd.ornl.gov (janus.lsd.ornl.gov [160.91.102.96]) 
	by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam:
       SGI does not authorize the use of its proprietary
       systems or networks for unsolicited or bulk email
       from the Internet.) 
	via ESMTP id QAA05973
	for <linux@cthulhu.engr.sgi.com>; Sat, 5 Aug 2000 16:13:15 -0700 (PDT)
	mail_from (philloc@janus.lsd.ornl.gov)
Received: from localhost (philloc@localhost)
	by janus.lsd.ornl.gov (8.9.3/8.9.3) with ESMTP id TAA00954;
	Sat, 5 Aug 2000 19:13:15 -0400
Date:   Sat, 5 Aug 2000 19:13:15 -0400 (EDT)
From:   phil <philloc@janus.lsd.ornl.gov>
Reply-To: i15@ornl.gov
To:     linux-fbdev@vuser.vu.union.edu
cc:     linux@cthulhu.engr.sgi.com
Subject: SGI VW 540, fbdev and pot pourii of faults and evidence..:-)
Message-ID: <Pine.LNX.4.21.0008051851230.943-100000@janus.lsd.ornl.gov>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing

	Hi Folks,

I have presented below a small list of "features" with the SGI kernel
driver for fbdev (no particular order) , and would like to know if any of
the symptoms, indicate general frame buffer problems, or specific hardware
implementation issues.

I would also like to ask, if SGI is likely to make the hardware specs OSS
(for cobalt etc.), so that those with the skill (this is not my forte, but
I will try...), can stabilise this otherwise competent port.

1. After boot , no matter what video mode one is in, the text console is
zippy. After using X (or changing modes using fbset) the text scrolling is
*painfully* slow. There is no apparent difference in the kernel mechanism
when switching, so is it just the boot state that works?



2.In X(4.01)  all video modes (800x600,1024x768,1280x1024,1600x1200) work
in 8 bit and 16 bit colour.

In Depth 24 (-fbbpp 32) , 1280x1024 is stable, but tinted green.

In Depth 24 (-fbbpp 32) , 1600x1200 is "shivering, left-right", and
tinted green.


	Empirical observations (i.e. writing known patterns to the
/dev/fb0 device) indicate that SGI reverse RGB for 888 format, compared to
RGB565. That is red offset=0, green=8,blue=16 rather than red=24 etc.. I
have reversed the assignment in the "var" structure (in sgivwfb_set_var )
and in setcolreg the offsets are used, but to no effect. What else needs
changing?


	Kind Regards

	PHiL


From owner-linux-mips@oss.sgi.com Sun Aug  6 08:13:50 2000
Received:  by oss.sgi.com id <S42247AbQHFPNj>;
	Sun, 6 Aug 2000 08:13:39 -0700
Received: from [204.94.214.10] ([204.94.214.10]:8272 "EHLO deliverator.sgi.com")
	by oss.sgi.com with ESMTP id <S42228AbQHFPNL>;
	Sun, 6 Aug 2000 08:13:11 -0700
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id HAA14152
	for <linux-mips@oss.sgi.com>; Sun, 6 Aug 2000 07:41:07 -0700 (PDT)
	mail_from (flo@rfc822.org)
Received: from sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id HAA56089
	for <linux@cthulhu.engr.sgi.com>;
	Sun, 6 Aug 2000 07:48:15 -0700 (PDT)
	mail_from (flo@rfc822.org)
Received: from noose.gt.owl.de (noose.gt.owl.de [62.52.19.4]) 
	by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam:
       SGI does not authorize the use of its proprietary
       systems or networks for unsolicited or bulk email
       from the Internet.) 
	via ESMTP id HAA04331
	for <linux@cthulhu.engr.sgi.com>; Sun, 6 Aug 2000 07:48:13 -0700 (PDT)
	mail_from (flo@rfc822.org)
Received: by noose.gt.owl.de (Postfix, from userid 10)
	id 64ADF7F4; Sun,  6 Aug 2000 16:50:13 +0200 (CEST)
Received: by paradigm.rfc822.org (Postfix, from userid 1000)
	id 0C4D58FF5; Fri,  4 Aug 2000 20:56:08 +0200 (CEST)
Date:   Fri, 4 Aug 2000 20:56:08 +0200
From:   Florian Lohoff <flo@rfc822.org>
To:     Geert Uytterhoeven <geert@linux-m68k.org>
Cc:     =?iso-8859-1?Q?=B1=E8=C7=D1=BC=BA?= <khs@digital-digital.com>,
        linux@cthulhu.engr.sgi.com, linux-mips@fnet.fr
Subject: Re: IGS5050 Driver
Message-ID: <20000804205608.A313@paradigm.rfc822.org>
References: <000001bff6fe$34021120$8d19ebcb@khs> <Pine.LNX.4.10.10007271423280.434-100000@cassiopeia.home>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
User-Agent: Mutt/1.0.1i
In-Reply-To: <Pine.LNX.4.10.10007271423280.434-100000@cassiopeia.home>; from geert@linux-m68k.org on Thu, Jul 27, 2000 at 02:26:02PM +0200
Organization: rfc822 - pure communication
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing

On Thu, Jul 27, 2000 at 02:26:02PM +0200, Geert Uytterhoeven wrote:
> On Wed, 26 Jul 2000, [ks_c_5601-1987] ±èÇÑ?º wrote:
> > I want to know that there is a IGS5050 Grpahic chip driver for linux-mips.
> > If yes, where is the driver files?
> 
> linux/drivers/video/cyber2000fb.c is a driver for the IGS CyberPro 2000, 2010
> and 5000 in the NetWinder, which has an ARM CPU. If the 5050 is sufficient
> compatible with the 5000 it should not be too difficult to get cyber2000fb to
> work on the 5050 on the MIPS.

When back from Canada i will start working on that beast - I have 100
SetTopBoxes with the 5000/5050 Combination (Video and Audio Controller).
(These are x86 based)

The IGS People seem to be quiet helpful - I mailed them concerning
Documentation and got a LARGE pdf back for this Chip.

Flo
-- 
Florian Lohoff		flo@rfc822.org		      	+49-5201-669912
     "If you're not having fun right now, you're wasting your time."


From owner-linux-mips@oss.sgi.com Sun Aug  6 08:14:09 2000
Received:  by oss.sgi.com id <S42228AbQHFPNu>;
	Sun, 6 Aug 2000 08:13:50 -0700
Received: from tomts2.bellnexxia.net ([209.226.175.140]:60907 "EHLO
        tomts2-srv.bellnexxia.net") by oss.sgi.com with ESMTP
	id <S42236AbQHFPNR>; Sun, 6 Aug 2000 08:13:17 -0700
Received: from free.fr ([216.208.215.83]) by tomts2-srv.bellnexxia.net
          (InterMail vM.4.01.03.00 201-229-121) with ESMTP
          id <20000806150248.JMRO8045.tomts2-srv.bellnexxia.net@free.fr>;
          Sun, 6 Aug 2000 11:02:48 -0400
Message-ID: <398D7E42.88D4005E@free.fr>
Date:   Sun, 06 Aug 2000 15:03:30 +0000
From:   Famille Chauvat <famille.chauvat@free.fr>
X-Mailer: Mozilla 4.7 [en] (X11; U; Linux 2.2.9-27mdk i686)
X-Accept-Language: fr-FR, en
MIME-Version: 1.0
To:     Florian Lohoff <flo@rfc822.org>
CC:     linux-mips@oss.sgi.com
Subject: Re: [Install trouble]
References: <39847F16.543AA232@free.fr> <20000804210304.C313@paradigm.rfc822.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing

Hi Florian,

Thanks for your response. Humm, I don't know how to boot with rw support...
And, Keith M Wesolowski, see messages in this thread, modify the kernel to
have a ramdisk support.
>>>> Keith M Wesolowski
>>>> I've uploaded a new kernel, dated 0731, which should have the necessary support.
>>>>
That what I don't understand, except a lot of another things :-), is how it
runs. You know, I took a lot of things on internet, I read a lot of papers,
perhaps not those I had to, and I've never ask to support or not the
ramdisk. So my question is, how the kernel I took doesn't support something
I never asked for. I'm not sure to be very clear :-)

With the new kernel I have, I've a new trouble. After the partition step, a
message "mount failed, bad address" appears and I 've to reboot. Of course,
the next time I'ld the same things. Any suggestion, any help, would be very
appreciate.
Btw, if you know someone of your team or friends who speak french, it could
be better, for me, to explain what going wrong.

Philippe

From owner-linux-mips@oss.sgi.com Sun Aug  6 08:14:49 2000
Received:  by oss.sgi.com id <S42256AbQHFPOk>;
	Sun, 6 Aug 2000 08:14:40 -0700
Received: from noose.gt.owl.de ([62.52.19.4]:36620 "HELO noose.gt.owl.de")
	by oss.sgi.com with SMTP id <S42254AbQHFPOX>;
	Sun, 6 Aug 2000 08:14:23 -0700
Received: by noose.gt.owl.de (Postfix, from userid 10)
	id 86F1A7F5; Sun,  6 Aug 2000 16:50:13 +0200 (CEST)
Received: by paradigm.rfc822.org (Postfix, from userid 1000)
	id 590408FF5; Fri,  4 Aug 2000 20:58:16 +0200 (CEST)
Date:   Fri, 4 Aug 2000 20:58:16 +0200
From:   Florian Lohoff <flo@rfc822.org>
To:     Keith M Wesolowski <wesolows@foobazco.org>
Cc:     linux-mips@oss.sgi.com
Subject: Re: sgi prom console
Message-ID: <20000804205816.B313@paradigm.rfc822.org>
References: <20000726215416.A18398@foobazco.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
User-Agent: Mutt/1.0.1i
In-Reply-To: <20000726215416.A18398@foobazco.org>; from wesolows@foobazco.org on Wed, Jul 26, 2000 at 09:54:16PM -0700
Organization: rfc822 - pure communication
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing

On Wed, Jul 26, 2000 at 09:54:16PM -0700, Keith M Wesolowski wrote:
> 
> This patch gets the sgi prom console outputting again, and eliminates
> the "cannot open initial console" error. Unfortunately, all output
> from userland goes to the serial port, not the the prom console.
> Looking at the code, this isn't at all surprising; the prom console
> pretends to be 4,64, ttyS0. It's quite beyond me how the prom console
> could ever have worked for userland.

It never has :) - There is a major difference between the console
for the Kernel (Really called console in the kernel) and a TTY. The
TTY implementation for the Prom Console has never been done from what
i see in the code - Although this would be quiet helpful to do
a full implementation for a TTY as we than had the possibility to
boot the Indigo2 etc with Framebuffer/Keyboard.

Flo
-- 
Florian Lohoff		flo@rfc822.org		      	+49-5201-669912
     "If you're not having fun right now, you're wasting your time."


From owner-linux-mips@oss.sgi.com Sun Aug  6 08:15:09 2000
Received:  by oss.sgi.com id <S42254AbQHFPOu>;
	Sun, 6 Aug 2000 08:14:50 -0700
Received: from noose.gt.owl.de ([62.52.19.4]:36876 "HELO noose.gt.owl.de")
	by oss.sgi.com with SMTP id <S42236AbQHFPOX>;
	Sun, 6 Aug 2000 08:14:23 -0700
Received: by noose.gt.owl.de (Postfix, from userid 10)
	id ACC5E7F6; Sun,  6 Aug 2000 16:50:13 +0200 (CEST)
Received: by paradigm.rfc822.org (Postfix, from userid 1000)
	id 049028FF5; Fri,  4 Aug 2000 21:03:04 +0200 (CEST)
Date:   Fri, 4 Aug 2000 21:03:04 +0200
From:   Florian Lohoff <flo@rfc822.org>
To:     Famille Chauvat <famille.chauvat@free.fr>
Cc:     linux-mips@oss.sgi.com
Subject: Re: [Install trouble]
Message-ID: <20000804210304.C313@paradigm.rfc822.org>
References: <39847F16.543AA232@free.fr>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
User-Agent: Mutt/1.0.1i
In-Reply-To: <39847F16.543AA232@free.fr>; from famille.chauvat@free.fr on Sun, Jul 30, 2000 at 07:16:38PM +0000
Organization: rfc822 - pure communication
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing

On Sun, Jul 30, 2000 at 07:16:38PM +0000, Famille Chauvat wrote:
> Hello,
> 
> I'm working with an Indy station and the corresponding kernel.
> On the bootp() step, i got a message:
> >>>>>>>
> 
> creating 100k of ramdisk space... done
> mounting /tmp from ramdisk... failed
> 
> I can't recover from this.
> <<<<<<<

Probably this is a kernel with no ramdisk support ?  Ah wait - No - 
You have booted the kernel with a read-only root - Which means - When
mounting /tmp i tries to write /etc/mtab which is read-only - Try
to append "rw" to your prom console boot line

Flo
-- 
Florian Lohoff		flo@rfc822.org		      	+49-5201-669912
     "If you're not having fun right now, you're wasting your time."


From owner-linux-mips@oss.sgi.com Mon Aug  7 05:27:28 2000
Received:  by oss.sgi.com id <S42185AbQHGM1S>;
	Mon, 7 Aug 2000 05:27:18 -0700
Received: from jarre.otscorp.com ([203.44.145.48]:43785 "EHLO shorts.cx")
	by oss.sgi.com with ESMTP id <S42183AbQHGM0q>;
	Mon, 7 Aug 2000 05:26:46 -0700
Received: from jarre.house (ndf@jarre.house [192.168.10.1])
	by shorts.cx (8.11.0/8.11.0) with ESMTP id e77CShG09064
	for <linux-mips@oss.sgi.com>; Mon, 7 Aug 2000 22:28:43 +1000
Date:   Mon, 7 Aug 2000 22:27:03 +1000 (EST)
From:   Nathan Fraser <ndf@shorts.cx>
X-Sender: ndf@jarre.house
To:     linux-mips@oss.sgi.com
Subject: Re: [Install trouble] : mount failed: bad address
Message-ID: <Pine.LNX.4.20.0008072030210.4379-100000@jarre.house>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing

....
>> creating 100k of ramdisk space... done
>> mounting /tmp from ramdisk... failed
>> 
>> I can't recover from this.
>> <<<<<<<

> Probably this is a kernel with no ramdisk support ?  Ah wait - No - 
> You have booted the kernel with a read-only root - Which means - When
> mounting /tmp i tries to write /etc/mtab which is read-only - Try
> to append "rw" to your prom console boot line

I just tried installing with vmlinux-000804-IP22-4400 and
hardhat-sgi-5.1.tar.gz - i get the same error as soon as the drive is
formatted and is mounted (ie: mount failed: bad address)

my boot command was (minor variations of):

boot bootp():/vmlinux root=/dev/nfs rw /home/tftboot/mipseb

The root fs is mounted via nfs ok read-write which i verified by writing a
file to it.. As far as i can tell the redhat installer is all working ok..
it just can't mount the newly formatted partition (or even an irix
formatted efs partition).

Is there a 'better' kernel to use to get the base system installed? Or am
i making some sort of stoopid installation mistake? The kernel that came
in the hardhat tarball failed with:

Looking up port of RPC 100003/2 on 192.168.10.30
page fault from irq

then locked up toally :( Sometimes it would not even print the 'q'.

The nfs is being served from a pc with slackware 7 / linux 2.2.16 / dhcp
2.0 / nfs: Universal NFS Server 2.2beta47. oh yeah.. and setenv netaddr 0
prior to boot... was a big help :)

I was trying to install to the second hard drive: /dev/sdb1 (under linux). 

my hinv:

Iris Audio Processor: version A2 revision 4.1.0
1 200 MHZ IP22 Processor
FPU: MIPS R4010 Floating Point Chip Revision: 0.0
CPU: MIPS R4400 Processor Chip Revision: 6.0
On-board serial ports: 2
On-board bi-directional parallel port
Data cache size: 16 Kbytes
Instruction cache size: 16 Kbytes
Secondary unified instruction/data cache size: 1 Mbyte
Main memory size: 128 Mbytes
Integral ISDN: Basic Rate Interface unit 0, revision 1.0
Integral Ethernet: ec0, version 1
Integral SCSI controller 0: Version WD33C93B, revision D
Disk drive: unit 2 on SCSI controller 0
Disk drive: unit 1 on SCSI controller 0
Graphics board: Indy 24-bit
Vino video: unit 0, revision 0, IndyCam connected

Any pointers would be greatly appreciated! 


From owner-linux-mips@oss.sgi.com Mon Aug  7 08:28:51 2000
Received:  by oss.sgi.com id <S42188AbQHGP2l>;
	Mon, 7 Aug 2000 08:28:41 -0700
Received: from delta.ds2.pg.gda.pl ([153.19.144.1]:19128 "EHLO
        delta.ds2.pg.gda.pl") by oss.sgi.com with ESMTP id <S42183AbQHGP2O>;
	Mon, 7 Aug 2000 08:28:14 -0700
Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id RAA04367;
	Mon, 7 Aug 2000 17:22:54 +0200 (MET DST)
Date:   Mon, 7 Aug 2000 17:22:54 +0200 (MET DST)
From:   "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
Reply-To: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To:     Ralf Baechle <ralf@uni-koblenz.de>,
        Harald Koerfgen <Harald.Koerfgen@home.ivm.de>
cc:     Craig P Prescott <prescott@phys.ufl.edu>, linux-mips@fnet.fr,
        linux-mips@oss.sgi.com
Subject: High resolution timer support for I/O ASIC DECstations
Message-ID: <Pine.GSO.3.96.1000807165501.3044B-100000@delta.ds2.pg.gda.pl>
Organization: Technical University of Gdansk
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing

Hi,

 Following is a patch that implements a high resolution timer for I/O ASIC
DECstations, i.e. it provides a do_fast_gettimeoffset() function that is
suitable for R3K-based machines (that do not have a cycle counter within
the CPU).  Also a proper do_div() macro is included.  There are also a few
small cleanups and enhancements in the related code.

 This change makes my NTP daemon particularly happy -- a dispersion of
0.02 when synchronizing with a remote server is really nice.  An X server
would benefit, too, if we had one. 

 I'd like to encourage everyone interested to test these changes as much
as possible.  Also if anyone knows of a better division algorithm than the
one I used for do_div64_32(), I'd be glad to hear of it.  If nothing wrong
pops up, these changes should be included in the official tree, I believe. 

 Comments are welcomed, as usually.

  Maciej

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

diff -u --recursive --new-file linux-mips-2.4.0-test5-20000731.macro/arch/mips/Makefile linux-mips-2.4.0-test5-20000731/arch/mips/Makefile
--- linux-mips-2.4.0-test5-20000731.macro/arch/mips/Makefile	Thu Jul 13 04:26:16 2000
+++ linux-mips-2.4.0-test5-20000731/arch/mips/Makefile	Sat Aug  5 17:45:33 2000
@@ -35,7 +35,7 @@
 # machines may also.  Since BFD is incredibly buggy with respect to
 # crossformat linking we rely on the elf2ecoff tool for format conversion.
 #
-CFLAGS		+= -G 0 -mno-abicalls -fno-pic
+GCCFLAGS	:= -G 0 -mno-abicalls -fno-pic
 LINKFLAGS	+= -static -G 0
 MODFLAGS	+= -mlong-calls
 
@@ -47,31 +47,40 @@
 # CPU-dependent compiler/assembler options for optimization.
 #
 ifdef CONFIG_CPU_R3000
-CFLAGS		:= $(CFLAGS) -mcpu=r3000 -mips1
+GCCFLAGS	+= -mcpu=r3000 -mips1
 endif
 ifdef CONFIG_CPU_R6000
-CFLAGS		:= $(CFLAGS) -mcpu=r6000 -mips2 -Wa,--trap
+GCCFLAGS	+= -mcpu=r6000 -mips2 -Wa,--trap
 endif
 ifdef CONFIG_CPU_R4300
-CFLAGS		:= $(CFLAGS) -mcpu=r4300 -mips2 -Wa,--trap
+GCCFLAGS	+= -mcpu=r4300 -mips2 -Wa,--trap
 endif
 ifdef CONFIG_CPU_R4X00
-CFLAGS		:= $(CFLAGS) -mcpu=r4600 -mips2 -Wa,--trap
+GCCFLAGS	+= -mcpu=r4600 -mips2 -Wa,--trap
 endif
 ifdef CONFIG_CPU_R5000
-CFLAGS		:= $(CFLAGS) -mcpu=r8000 -mips2 -Wa,--trap
+GCCFLAGS	+= -mcpu=r8000 -mips2 -Wa,--trap
 endif
 ifdef CONFIG_CPU_NEVADA
-CFLAGS		:= $(CFLAGS) -mcpu=r8000 -mips2 -Wa,--trap -mmad
+GCCFLAGS	+= -mcpu=r8000 -mips2 -Wa,--trap -mmad
 endif
 ifdef CONFIG_CPU_R8000
-CFLAGS		:= $(CFLAGS) -mcpu=r8000 -mips2 -Wa,--trap
+GCCFLAGS	+= -mcpu=r8000 -mips2 -Wa,--trap
 endif
 ifdef CONFIG_CPU_R10000
-CFLAGS		:= $(CFLAGS) -mcpu=r8000 -mips2 -Wa,--trap
+GCCFLAGS	+= -mcpu=r8000 -mips2 -Wa,--trap
 endif
 
 #
+# The pipe options is bad for my low-mem machine
+# Uncomment this if you want this.
+#
+GCCFLAGS	+= -pipe
+
+CFLAGS		+= $(GCCFLAGS)
+AFLAGS		+= $(GCCFLAGS)
+
+#
 # Board-dependent options and extra files
 #
 ifdef CONFIG_ALGOR_P4032
@@ -168,12 +177,6 @@
 ifdef LOADADDR
 LINKFLAGS     += -Ttext $(word 1,$(LOADADDR))
 endif
-
-#
-# The pipe options is bad for my low-mem machine
-# Uncomment this if you want this.
-#
-CFLAGS		+= -pipe
 
 HEAD := arch/mips/kernel/head.o arch/mips/kernel/init_task.o
 
diff -u --recursive --new-file linux-mips-2.4.0-test5-20000731.macro/arch/mips/dec/Makefile linux-mips-2.4.0-test5-20000731/arch/mips/dec/Makefile
--- linux-mips-2.4.0-test5-20000731.macro/arch/mips/dec/Makefile	Tue Mar 28 04:26:06 2000
+++ linux-mips-2.4.0-test5-20000731/arch/mips/dec/Makefile	Sat Aug  5 17:24:35 2000
@@ -7,9 +7,9 @@
 #
 
 .S.s:
-	$(CPP) $(CFLAGS) $< -o $*.s
+	$(CPP) $(AFLAGS) -traditional -o $*.o $<
 .S.o:
-	$(CC) $(CFLAGS) -c $< -o $*.o
+	$(CC) $(AFLAGS) -traditional -c -o $*.o $<
 
 all: dec.o
 O_TARGET := dec.o
diff -u --recursive --new-file linux-mips-2.4.0-test5-20000731.macro/arch/mips/dec/int-handler.S linux-mips-2.4.0-test5-20000731/arch/mips/dec/int-handler.S
--- linux-mips-2.4.0-test5-20000731.macro/arch/mips/dec/int-handler.S	Tue Mar 28 04:26:06 2000
+++ linux-mips-2.4.0-test5-20000731/arch/mips/dec/int-handler.S	Sat Aug  5 15:31:37 2000
@@ -2,6 +2,7 @@
  * arch/mips/dec/int-handler.S
  *
  * Copyright (C) 1995, 1996, 1997 Paul M. Antoine and Harald Koerfgen
+ * Copyright (C) 2000  Maciej W. Rozycki
  *
  * Written by Ralf Baechle and Andreas Busse, modified for DECStation
  * support by Paul Antoine and Harald Koerfgen.
@@ -16,6 +17,11 @@
 #include <asm/stackframe.h>
 #include <asm/addrspace.h>
 
+#include <asm/dec/kn01.h>
+#include <asm/dec/kn02.h>
+#include <asm/dec/kn02xa.h>
+#include <asm/dec/kn03.h>
+#include <asm/dec/ioasic_addrs.h>
 #include <asm/dec/interrupts.h>
 
 
@@ -164,10 +170,10 @@
 /*
  * Handle "IRQ Controller" Interrupts
  * Masked Interrupts are still visible and have to be masked "by hand".
- * %hi(KN02_CSR_ADDR) does not work so all addresses are hardcoded :-(.
  */
 		EXPORT(kn02_io_int)
-kn02_io_int:	lui	t0,0xbff0		# get interrupt status and mask
+kn02_io_int:					# 3max
+		lui	t0,KN02_CSR_ADDR>>16	# get interrupt status and mask
 		lw	t0,(t0)
 		la	t1,asic_mask_tbl
 		move	t3,t0
@@ -176,17 +182,20 @@
 		 and	t0,t3			# mask out allowed ones
 
 		EXPORT(kn03_io_int)
-kn03_io_int:	lui	t2,0xbf84		# upper part of IOASIC Address
-		lw	t0,0x0110(t2)		# get status: IOASIC isr
-		lw	t3,0x0120(t2)		# get mask:   IOASIC isrm
+kn03_io_int:					# 3max+
+		lui	t2,KN03_IOASIC_BASE>>16	# upper part of IOASIC Address
+		lw	t0,SIR(t2)		# get status: IOASIC isr
+		lw	t3,SIMR(t2)		# get mask:   IOASIC isrm
 		la	t1,asic_mask_tbl
 		b	find_int
 		 and	t0,t3			# mask out allowed ones
 
-		EXPORT(kn02ba_io_int)
-kn02ba_io_int:	lui	t2,0xbc04		
-		lw	t0,0x0110(t2)		# IOASIC isr, works for maxine also
-		lw	t3,0x0120(t2)		# IOASIC isrm
+		EXPORT(kn02xa_io_int)
+kn02xa_io_int:					# 3min/maxine
+		lui	t2,KN02XA_IOASIC_BASE>>16		
+						# upper part of IOASIC Address
+		lw	t0,SIR(t2)		# get status: IOASIC isr
+		lw	t3,SIMR(t2)		# get mask:   IOASIC isrm
 		la	t1,asic_mask_tbl
 		and	t0,t3
 
diff -u --recursive --new-file linux-mips-2.4.0-test5-20000731.macro/arch/mips/dec/irq.c linux-mips-2.4.0-test5-20000731/arch/mips/dec/irq.c
--- linux-mips-2.4.0-test5-20000731.macro/arch/mips/dec/irq.c	Tue Mar 28 04:26:06 2000
+++ linux-mips-2.4.0-test5-20000731/arch/mips/dec/irq.c	Sat Aug  5 18:40:27 2000
@@ -27,10 +27,6 @@
 
 #include <asm/dec/interrupts.h>
 
-extern volatile unsigned int *isr;	/* address of the interrupt status register     */
-extern volatile unsigned int *imr;	/* address of the interrupt mask register       */
-extern decint_t dec_interrupt[NR_INTS];
-
 irq_cpustat_t irq_stat [NR_CPUS];
 
 unsigned int local_bh_count[NR_CPUS];
diff -u --recursive --new-file linux-mips-2.4.0-test5-20000731.macro/arch/mips/dec/setup.c linux-mips-2.4.0-test5-20000731/arch/mips/dec/setup.c
--- linux-mips-2.4.0-test5-20000731.macro/arch/mips/dec/setup.c	Tue Mar 28 04:26:06 2000
+++ linux-mips-2.4.0-test5-20000731/arch/mips/dec/setup.c	Sat Aug  5 18:49:00 2000
@@ -6,6 +6,7 @@
  * for more details.
  *
  * Copyright (C) 1998 Harald Koerfgen
+ * Copyright (C) 2000 Maciej W. Rozycki
  */
 #include <linux/sched.h>
 #include <linux/interrupt.h>
@@ -22,6 +23,8 @@
 #include <asm/dec/kn02.h>
 #include <asm/dec/kn02xa.h>
 #include <asm/dec/kn03.h>
+#include <asm/dec/ioasic.h>
+#include <asm/dec/ioasic_addrs.h>
 #include <asm/dec/ioasic_ints.h>
 
 extern asmlinkage void decstation_handle_int(void);
@@ -33,14 +36,14 @@
 void dec_init_kn02ca(void);
 void dec_init_kn03(void);
 
-char *dec_rtc_base = (char *) KN01_RTC_BASE;	/* Assume DS2100/3100 initially */
+char *dec_rtc_base = (void *) KN01_RTC_BASE;	/* Assume DS2100/3100 initially */
+
+volatile unsigned int *ioasic_base;
 
 decint_t dec_interrupt[NR_INTS];
 
-/* 
+/*
  * Information regarding the IRQ Controller
- *
- * isr and imr are also hardcoded for different machines in int_handler.S
  */
 
 volatile unsigned int *isr = 0L;	/* address of the interrupt status register     */
@@ -206,8 +209,8 @@
      * Setup some memory addresses. FIXME: probably incomplete!
      */
     dec_rtc_base = (char *) KN02_RTC_BASE;
-    isr = (volatile unsigned int *) KN02_CSR_ADDR;
-    imr = (volatile unsigned int *) KN02_CSR_ADDR;
+    isr = (void *) KN02_CSR_ADDR;
+    imr = (void *) KN02_CSR_ADDR;
 
     /*
      * Setup IOASIC interrupt
@@ -275,16 +278,17 @@
     /*
      * Setup some memory addresses.
      */
+    ioasic_base = (void *) KN02XA_IOASIC_BASE;
     dec_rtc_base = (char *) KN02XA_RTC_BASE;
-    isr = (volatile unsigned int *) KN02XA_SIR_ADDR;
-    imr = (volatile unsigned int *) KN02XA_SIRM_ADDR;
+    isr = (void *) KN02XA_IOASIC_REG(SIR);
+    imr = (void *) KN02XA_IOASIC_REG(SIMR);
 
     /*
      * Setup IOASIC interrupt
      */
     cpu_mask_tbl[0] = IE_IRQ3;
     cpu_irq_nr[0] = -1;
-    cpu_ivec_tbl[0] = kn02ba_io_int;
+    cpu_ivec_tbl[0] = kn02xa_io_int;
     *imr = 0;
 
     /*
@@ -355,14 +359,15 @@
     /*
      * Setup some memory addresses. FIXME: probably incomplete!
      */
+    ioasic_base = (void *) KN02XA_IOASIC_BASE;
     dec_rtc_base = (char *) KN02XA_RTC_BASE;
-    isr = (volatile unsigned int *) KN02XA_SIR_ADDR;
-    imr = (volatile unsigned int *) KN02XA_SIRM_ADDR;
+    isr = (void *) KN02XA_IOASIC_REG(SIR);
+    imr = (void *) KN02XA_IOASIC_REG(SIMR);
 
     /*
      * Setup IOASIC interrupt
      */
-    cpu_ivec_tbl[1] = kn02ba_io_int;
+    cpu_ivec_tbl[1] = kn02xa_io_int;
     cpu_irq_nr[1] = -1;
     cpu_mask_tbl[1] = IE_IRQ3;
     *imr = 0;
@@ -430,9 +435,10 @@
     /*
      * Setup some memory addresses. FIXME: probably incomplete!
      */
+    ioasic_base = (void *) KN03_IOASIC_BASE;
     dec_rtc_base = (char *) KN03_RTC_BASE;
-    isr = (volatile unsigned int *) KN03_SIR_ADDR;
-    imr = (volatile unsigned int *) KN03_SIRM_ADDR;
+    isr = (void *) KN03_IOASIC_REG(SIR);
+    imr = (void *) KN03_IOASIC_REG(SIMR);
 
     /*
      * Setup IOASIC interrupt
diff -u --recursive --new-file linux-mips-2.4.0-test5-20000731.macro/arch/mips/dec/time.c linux-mips-2.4.0-test5-20000731/arch/mips/dec/time.c
--- linux-mips-2.4.0-test5-20000731.macro/arch/mips/dec/time.c	Wed Jul 12 04:25:56 2000
+++ linux-mips-2.4.0-test5-20000731/arch/mips/dec/time.c	Sat Aug  5 19:19:57 2000
@@ -1,8 +1,9 @@
 
 /*
- *  linux/arch/mips/kernel/time.c
+ *  linux/arch/mips/dec/time.c
  *
  *  Copyright (C) 1991, 1992, 1995  Linus Torvalds
+ *  Copyright (C) 2000  Maciej W. Rozycki
  *
  * This file contains the time handling details for PC-style clocks as
  * found in some MIPS systems.
@@ -21,10 +22,15 @@
 #include <asm/mipsregs.h>
 #include <asm/io.h>
 #include <asm/irq.h>
+#include <asm/dec/machtype.h>
+#include <asm/dec/ioasic.h>
+#include <asm/dec/ioasic_addrs.h>
 
 #include <linux/mc146818rtc.h>
 #include <linux/timex.h>
 
+#include <asm/div64.h>
+
 extern volatile unsigned long wall_jiffies;
 extern rwlock_t xtime_lock;
 
@@ -36,12 +42,22 @@
 
 /* This is for machines which generate the exact clock. */
 #define USECS_PER_JIFFY (1000000/HZ)
+#define USECS_PER_JIFFY_FRAC (0x100000000*1000000/HZ&0xffffffff)
 
 /* Cycle counter value at the previous timer interrupt.. */
 
 static unsigned int timerhi = 0, timerlo = 0;
 
 /*
+ * Cached "1/(clocks per usec)*2^32" value.
+ * It has to be recalculated once each jiffy.
+ */
+static unsigned long cached_quotient = 0;
+
+/* Last jiffy when do_fast_gettimeoffset() was called. */
+static unsigned long last_jiffies = 0;
+
+/*
  * On MIPS only R4000 and better have a cycle counter.
  *
  * FIXME: Does playing with the RP bit in c0_status interfere with this code?
@@ -50,45 +66,34 @@
 {
 	u32 count;
 	unsigned long res, tmp;
-
-	/* Last jiffy when do_fast_gettimeoffset() was called. */
-	static unsigned long last_jiffies = 0;
 	unsigned long quotient;
 
-	/*
-	 * Cached "1/(clocks per usec)*2^32" value.
-	 * It has to be recalculated once each jiffy.
-	 */
-	static unsigned long cached_quotient = 0;
-
 	tmp = jiffies;
 
 	quotient = cached_quotient;
 
-	if (tmp && last_jiffies != tmp) {
-		last_jiffies = tmp;
-		__asm__(".set\tnoreorder\n\t"
-			".set\tnoat\n\t"
-			".set\tmips3\n\t"
-			"lwu\t%0,%2\n\t"
-			"dsll32\t$1,%1,0\n\t"
-			"or\t$1,$1,%0\n\t"
-			"ddivu\t$0,$1,%3\n\t"
-			"mflo\t$1\n\t"
-			"dsll32\t%0,%4,0\n\t"
-			"nop\n\t"
-			"ddivu\t$0,%0,$1\n\t"
-			"mflo\t%0\n\t"
-			".set\tmips0\n\t"
-			".set\tat\n\t"
-			".set\treorder"
-			:"=&r"(quotient)
-			:"r"(timerhi),
-			"m"(timerlo),
-			"r"(tmp),
-			"r"(USECS_PER_JIFFY)
-			:"$1");
+	if (last_jiffies != tmp) {
+	    last_jiffies = tmp;
+	    if (last_jiffies != 0) {
+		unsigned long r0;
+		__asm__(".set	push\n\t"
+			".set	mips3\n\t"
+			"lwu	%0,%3\n\t"
+			"dsll32	%1,%2,0\n\t"
+			"or	%1,%1,%0\n\t"
+			"ddivu	$0,%1,%4\n\t"
+			"mflo	%1\n\t"
+			"dsll32	%0,%5,0\n\t"
+			"or	%0,%0,%6\n\t"
+			"ddivu	$0,%0,%1\n\t"
+			"mflo	%0\n\t"
+			".set	pop"
+			: "=&r" (quotient), "=&r" (r0)
+			: "r" (timerhi), "m" (timerlo),
+			  "r" (tmp), "r" (USECS_PER_JIFFY),
+			  "r" (USECS_PER_JIFFY_FRAC));
 		cached_quotient = quotient;
+	    }
 	}
 	/* Get last timer tick in absolute kernel time */
 	count = read_32bit_cp0_register(CP0_COUNT);
@@ -97,11 +102,9 @@
 	count -= timerlo;
 //printk("count: %08lx, %08lx:%08lx\n", count, timerhi, timerlo);
 
-	__asm__("multu\t%1,%2\n\t"
-		"mfhi\t%0"
-		:"=r"(res)
-		:"r"(count),
-		"r"(quotient));
+	__asm__("multu	%2,%3"
+		: "=l" (tmp), "=h" (res)
+		: "r" (count), "r" (quotient));
 
 	/*
 	 * Due to possible jiffies inconsistencies, we need to check 
@@ -113,6 +116,47 @@
 	return res;
 }
 
+static unsigned long do_ioasic_gettimeoffset(void)
+{
+	u32 count;
+	unsigned long res, tmp;
+	unsigned long quotient;
+
+	tmp = jiffies;
+
+	quotient = cached_quotient;
+
+	if (last_jiffies != tmp) {
+		last_jiffies = tmp;
+		if (last_jiffies != 0) {
+			unsigned long r0;
+			do_div64_32(r0, timerhi, timerlo, tmp);
+			do_div64_32(quotient, USECS_PER_JIFFY,
+				    USECS_PER_JIFFY_FRAC, r0);
+			cached_quotient = quotient;
+		}
+	}
+	/* Get last timer tick in absolute kernel time */
+	count = ioasic_read(FCTR);
+
+	/* .. relative to previous jiffy (32 bits is enough) */
+	count -= timerlo;
+//printk("count: %08x, %08x:%08x\n", count, timerhi, timerlo);
+
+	__asm__("multu	%2,%3"
+		: "=l" (tmp), "=h" (res)
+		: "r" (count), "r" (quotient));
+
+	/*
+	 * Due to possible jiffies inconsistencies, we need to check
+	 * the result so that we'll get a timer that is monotonic.
+	 */
+	if (res >= USECS_PER_JIFFY)
+        	res = USECS_PER_JIFFY - 1;
+
+	return res;
+}
+
 /* This function must be called with interrupts disabled 
  * It was inspired by Steve McCanne's microtime-i386 for BSD.  -- jrs
  * 
@@ -170,8 +214,8 @@
 	tv->tv_usec += do_gettimeoffset();
 
 	/*
-	 * xtime is atomically updated in timer_bh. lost_ticks is
-	 * nonzero if the timer bottom half hasnt executed yet.
+	 * xtime is atomically updated in timer_bh. jiffies - wall_jiffies
+	 * is nonzero if the timer bottom half hasnt executed yet.
 	 */
 	if (jiffies - wall_jiffies)
 		tv->tv_usec += USECS_PER_JIFFY;
@@ -309,11 +353,12 @@
 	read_lock(&xtime_lock);
 	if (time_state != TIME_BAD && xtime.tv_sec > last_rtc_update + 660 &&
 	    xtime.tv_usec > 500000 - (tick >> 1) &&
-	    xtime.tv_usec < 500000 + (tick >> 1))
+	    xtime.tv_usec < 500000 + (tick >> 1)) {
 		if (set_rtc_mmss(xtime.tv_sec) == 0)
 			last_rtc_update = xtime.tv_sec;
 		else
 			last_rtc_update = xtime.tv_sec - 600;	/* do it again in 60 s */
+	}
 	/* As we return to user mode fire off the other CPU schedulers.. this is
 	   basically because we don't yet share IRQ's around. This message is
 	   rigged to be safe on the 386 - basically it's a hack, so don't look
@@ -334,16 +379,42 @@
 	timerhi += (count < timerlo);	/* Wrap around */
 	timerlo = count;
 
+	if (jiffies == ~0) {
+		/*
+		 * If jiffies is to overflow in this timer_interrupt we must
+		 * update the timer[hi]/[lo] to make do_fast_gettimeoffset()
+		 * quotient calc still valid. -arca
+		 */
+		write_32bit_cp0_register(CP0_COUNT, 0);
+		timerhi = timerlo = 0;
+	}
+
 	timer_interrupt(irq, dev_id, regs);
+}
+
+static void ioasic_timer_interrupt(int irq, void *dev_id, struct pt_regs *regs)
+{
+	unsigned int count;
+
+	/*
+	 * The free-running counter is 32 bit which is good for about
+	 * 2 minutes, 50 seconds at possible count rates of upto 25MHz.
+	 */
+	count = ioasic_read(FCTR);
+	timerhi += (count < timerlo);	/* Wrap around */
+	timerlo = count;
 
-	if (!jiffies) {
+	if (jiffies == ~0) {
 		/*
-		 * If jiffies has overflowed in this timer_interrupt we must
+		 * If jiffies is to overflow in this timer_interrupt we must
 		 * update the timer[hi]/[lo] to make do_fast_gettimeoffset()
 		 * quotient calc still valid. -arca
 		 */
+		ioasic_write(FCTR, 0);
 		timerhi = timerlo = 0;
 	}
+
+	timer_interrupt(irq, dev_id, regs);
 }
 
 /* Converts Gregorian date to seconds since 1970-01-01 00:00:00.
@@ -473,6 +544,10 @@
 		write_32bit_cp0_register(CP0_COUNT, 0);
 		do_gettimeoffset = do_fast_gettimeoffset;
 		irq0.handler = r4k_timer_interrupt;
-	}
+	} else if (IOASIC) {
+		ioasic_write(FCTR, 0);
+		do_gettimeoffset = do_ioasic_gettimeoffset;
+		irq0.handler = ioasic_timer_interrupt;
+        }
 	board_time_init(&irq0);
 }
diff -u --recursive --new-file linux-mips-2.4.0-test5-20000731.macro/include/asm-mips/addrspace.h linux-mips-2.4.0-test5-20000731/include/asm-mips/addrspace.h
--- linux-mips-2.4.0-test5-20000731.macro/include/asm-mips/addrspace.h	Tue Mar 28 04:27:19 2000
+++ linux-mips-2.4.0-test5-20000731/include/asm-mips/addrspace.h	Sat Aug  5 18:04:53 2000
@@ -4,6 +4,7 @@
  * for more details.
  *
  * Copyright (C) 1996 by Ralf Baechle
+ * Copyright (C) 2000 by Maciej W. Rozycki
  *
  * Defitions for the address spaces of the MIPS CPUs.
  */
@@ -22,20 +23,35 @@
 /*
  * Returns the kernel segment base of a given address
  */
+#ifndef __ASSEMBLY__
 #define KSEGX(a)                (((unsigned long)(a)) & 0xe0000000)
+#else
+#define KSEGX(a)                ((a) & 0xe0000000)
+#endif
 
 /*
  * Returns the physical address of a KSEG0/KSEG1 address
  */
+#ifndef __ASSEMBLY__
 #define PHYSADDR(a)		(((unsigned long)(a)) & 0x1fffffff)
+#else
+#define PHYSADDR(a)		((a) & 0x1fffffff)
+#endif
 
 /*
  * Map an address to a certain kernel segment
  */
+#ifndef __ASSEMBLY__
 #define KSEG0ADDR(a)		((__typeof__(a))(((unsigned long)(a) & 0x1fffffff) | KSEG0))
 #define KSEG1ADDR(a)		((__typeof__(a))(((unsigned long)(a) & 0x1fffffff) | KSEG1))
 #define KSEG2ADDR(a)		((__typeof__(a))(((unsigned long)(a) & 0x1fffffff) | KSEG2))
 #define KSEG3ADDR(a)		((__typeof__(a))(((unsigned long)(a) & 0x1fffffff) | KSEG3))
+#else
+#define KSEG0ADDR(a)		(((a) & 0x1fffffff) | KSEG0)
+#define KSEG1ADDR(a)		(((a) & 0x1fffffff) | KSEG1)
+#define KSEG2ADDR(a)		(((a) & 0x1fffffff) | KSEG2)
+#define KSEG3ADDR(a)		(((a) & 0x1fffffff) | KSEG3)
+#endif
 
 /*
  * Memory segments (64bit kernel mode addresses)
diff -u --recursive --new-file linux-mips-2.4.0-test5-20000731.macro/include/asm-mips/dec/interrupts.h linux-mips-2.4.0-test5-20000731/include/asm-mips/dec/interrupts.h
--- linux-mips-2.4.0-test5-20000731.macro/include/asm-mips/dec/interrupts.h	Tue Mar 28 04:27:23 2000
+++ linux-mips-2.4.0-test5-20000731/include/asm-mips/dec/interrupts.h	Sat Aug  5 19:25:54 2000
@@ -36,7 +36,7 @@
 
 #define NR_INTS	11
 
-#ifndef _LANGUAGE_ASSEMBLY
+#ifndef __ASSEMBLY__
 /*
  * Data structure to hide the differences between the DECstation Interrupts
  *
@@ -50,6 +50,12 @@
 	unsigned int	iemask;		/* enabling interrupts in IRQ Controller	*/
 } decint_t;
 
+extern volatile unsigned int *isr;
+				/* address of the interrupt status register  */
+extern volatile unsigned int *imr;
+				/* address of the interrupt mask register    */
+extern decint_t dec_interrupt[NR_INTS];
+
 /*
  * Interrupt table structure to hide differences between different
  * systems such.
@@ -68,7 +74,7 @@
 extern void	dec_intr_rtc(void);
 
 extern void	kn02_io_int(void);
-extern void	kn02ba_io_int(void);
+extern void	kn02xa_io_int(void);
 extern void	kn03_io_int(void);
 
 extern void	intr_halt(void);
diff -u --recursive --new-file linux-mips-2.4.0-test5-20000731.macro/include/asm-mips/dec/ioasic.h linux-mips-2.4.0-test5-20000731/include/asm-mips/dec/ioasic.h
--- linux-mips-2.4.0-test5-20000731.macro/include/asm-mips/dec/ioasic.h	Thu Jan  1 00:00:00 1970
+++ linux-mips-2.4.0-test5-20000731/include/asm-mips/dec/ioasic.h	Sat Aug  5 17:07:15 2000
@@ -0,0 +1,24 @@
+/*
+ *  linux/asm-mips/dec/ioasic.h
+ *
+ *  Copyright (C) 2000  Maciej W. Rozycki
+ *
+ *  DEC I/O ASIC access operations.
+ */
+
+#ifndef __ASM_DEC_IOASIC_H
+#define __ASM_DEC_IOASIC_H
+
+extern volatile unsigned int *ioasic_base;
+
+extern inline void ioasic_write(unsigned int reg, unsigned int v)
+{
+	ioasic_base[reg / 4] = v;
+}
+
+extern inline unsigned int ioasic_read(unsigned int reg)
+{
+	return ioasic_base[reg / 4];
+}
+
+#endif /* __ASM_DEC_IOASIC_H */
diff -u --recursive --new-file linux-mips-2.4.0-test5-20000731.macro/include/asm-mips/dec/ioasic_addrs.h linux-mips-2.4.0-test5-20000731/include/asm-mips/dec/ioasic_addrs.h
--- linux-mips-2.4.0-test5-20000731.macro/include/asm-mips/dec/ioasic_addrs.h	Tue Mar 28 04:27:23 2000
+++ linux-mips-2.4.0-test5-20000731/include/asm-mips/dec/ioasic_addrs.h	Sat Aug  5 14:48:14 2000
@@ -17,25 +17,25 @@
 
 #define CHUNK_SIZE 0x00040000
 
-#define SYSTEM_ROM 	00*CHUNK_SIZE 		/* ??? */
-#define IOCTL 		01*CHUNK_SIZE 
-#define ESAR 		02*CHUNK_SIZE 
-#define LANCE 		03*CHUNK_SIZE 
-#define SCC0 		04*CHUNK_SIZE 
-#define VDAC_HI		05*CHUNK_SIZE		/* maxine only */
-#define SCC1 		06*CHUNK_SIZE 
-#define VDAC_LO		07*CHUNK_SIZE		/* maxine only */
-#define TOY 		08*CHUNK_SIZE 
-#define ISDN 		09*CHUNK_SIZE		/* maxine only */
-#define ERRADDR		09*CHUNK_SIZE 		/* 3maxplus only */
-#define CHKSYN 		10*CHUNK_SIZE 		/* 3maxplus only */
-#define ACCESS_BUS	10*CHUNK_SIZE 		/* maxine only */
-#define MCR 		11*CHUNK_SIZE 		/* 3maxplus only */
-#define FLOPPY 		11*CHUNK_SIZE 		/* maxine only */
-#define SCSI 		12*CHUNK_SIZE
-#define FLOPPY_DMA 	13*CHUNK_SIZE 		/* maxine only */
-#define SCSI_DMA 	14*CHUNK_SIZE 
-#define RESERVED_4 	15*CHUNK_SIZE 
+#define SYSTEM_ROM 	(00*CHUNK_SIZE)		/* ??? */
+#define IOCTL 		(01*CHUNK_SIZE)
+#define ESAR 		(02*CHUNK_SIZE)
+#define LANCE 		(03*CHUNK_SIZE)
+#define SCC0 		(04*CHUNK_SIZE)
+#define VDAC_HI		(05*CHUNK_SIZE)		/* maxine only */
+#define SCC1 		(06*CHUNK_SIZE)
+#define VDAC_LO		(07*CHUNK_SIZE)		/* maxine only */
+#define TOY 		(08*CHUNK_SIZE)
+#define ISDN 		(09*CHUNK_SIZE)		/* maxine only */
+#define ERRADDR		(09*CHUNK_SIZE)		/* 3maxplus only */
+#define CHKSYN 		(10*CHUNK_SIZE)		/* 3maxplus only */
+#define ACCESS_BUS	(10*CHUNK_SIZE)		/* maxine only */
+#define MCR 		(11*CHUNK_SIZE)		/* 3maxplus only */
+#define FLOPPY 		(11*CHUNK_SIZE)		/* maxine only */
+#define SCSI 		(12*CHUNK_SIZE)
+#define FLOPPY_DMA 	(13*CHUNK_SIZE)		/* maxine only */
+#define SCSI_DMA 	(14*CHUNK_SIZE)
+#define RESERVED_4 	(15*CHUNK_SIZE)
 
 /*
  * Offsets for IOCTL registers (relative to (system_base + IOCTL))
@@ -56,6 +56,7 @@
 #define SSR		0x100			/* System Support Register */
 #define SIR		0x110			/* System Interrupt Register */
 #define SIMR		0x120			/* System Interrupt Mask Register */
+#define FCTR		0x1e0			/* Free-Running Counter */
 
 /*
  * Handle partial word SCSI DMA transfers
diff -u --recursive --new-file linux-mips-2.4.0-test5-20000731.macro/include/asm-mips/dec/kn02xa.h linux-mips-2.4.0-test5-20000731/include/asm-mips/dec/kn02xa.h
--- linux-mips-2.4.0-test5-20000731.macro/include/asm-mips/dec/kn02xa.h	Tue Mar 28 04:27:23 2000
+++ linux-mips-2.4.0-test5-20000731/include/asm-mips/dec/kn02xa.h	Sat Aug  5 15:35:24 2000
@@ -9,6 +9,7 @@
  *
  * Copyright (C) 1995,1996 by Paul M. Antoine, some code and definitions
  * are by curteousy of Chris Fraser.
+ * Copyright (C) 2000  Maciej W. Rozycki
  *
  * These are addresses which have to be known early in the boot process.
  * For other addresses refer to tc.h ioasic_addrs.h and friends.
@@ -19,16 +20,12 @@
 #include <asm/addrspace.h>
 
 /*
- * Motherboard regs (kseg1 addresses)
- */
-#define KN02XA_SSR_ADDR		KSEG1ADDR(0x1c040100)	/* system control & status reg */
-#define KN02XA_SIR_ADDR		KSEG1ADDR(0x1c040110)	/* system interrupt reg */
-#define KN02XA_SIRM_ADDR	KSEG1ADDR(0x1c040120)	/* system interrupt mask reg */
-
-/*
  * Some port addresses...
  * FIXME: these addresses are incomplete and need tidying up!
  */
-#define KN02XA_RTC_BASE	(KSEG1ADDR(0x1c000000 + 0x200000)) /* ASIC + SL8 */
+#define KN02XA_IOASIC_BASE	KSEG1ADDR(0x1c040000)	/* I/O ASIC */
+#define KN02XA_RTC_BASE		KSEG1ADDR(0x1e000000)	/* RTC */
+
+#define KN02XA_IOASIC_REG(r)	(KN02XA_IOASIC_BASE+(r))
 
 #endif /* __ASM_MIPS_DEC_KN02XA_H */
diff -u --recursive --new-file linux-mips-2.4.0-test5-20000731.macro/include/asm-mips/dec/kn03.h linux-mips-2.4.0-test5-20000731/include/asm-mips/dec/kn03.h
--- linux-mips-2.4.0-test5-20000731.macro/include/asm-mips/dec/kn03.h	Tue Mar 28 04:27:23 2000
+++ linux-mips-2.4.0-test5-20000731/include/asm-mips/dec/kn03.h	Sat Aug  5 15:35:31 2000
@@ -8,6 +8,7 @@
  *
  * Copyright (C) 1995,1996 by Paul M. Antoine, some code and definitions
  * are by curteousy of Chris Fraser.
+ * Copyright (C) 2000  Maciej W. Rozycki
  *
  * These are addresses which have to be known early in the boot process.
  * For other addresses refer to tc.h ioasic_addrs.h and friends.
@@ -18,16 +19,12 @@
 #include <asm/addrspace.h>
 
 /*
- * Motherboard regs (kseg1 addresses)
- */
-#define KN03_SSR_ADDR	KSEG1ADDR(0x1f840100)	/* system control & status reg */
-#define KN03_SIR_ADDR	KSEG1ADDR(0x1f840110)	/* system interrupt reg */
-#define KN03_SIRM_ADDR	KSEG1ADDR(0x1f840120)	/* system interrupt mask reg */
-
-/*
  * Some port addresses...
  * FIXME: these addresses are incomplete and need tidying up!
  */
-#define KN03_RTC_BASE	(KSEG1ADDR(0x1f800000 + 0x200000)) /* ASIC + SL8 */
+#define KN03_IOASIC_BASE	KSEG1ADDR(0x1f840000)	/* I/O ASIC */
+#define KN03_RTC_BASE		KSEG1ADDR(0x1fa00000)	/* RTC */
+
+#define KN03_IOASIC_REG(r)	(KN03_IOASIC_BASE+(r))
 
 #endif /* __ASM_MIPS_DEC_KN03_H */
diff -u --recursive --new-file linux-mips-2.4.0-test5-20000731.macro/include/asm-mips/div64.h linux-mips-2.4.0-test5-20000731/include/asm-mips/div64.h
--- linux-mips-2.4.0-test5-20000731.macro/include/asm-mips/div64.h	Tue Mar 28 04:27:19 2000
+++ linux-mips-2.4.0-test5-20000731/include/asm-mips/div64.h	Sun Aug  6 05:22:36 2000
@@ -1,4 +1,7 @@
-/* $Id: div64.h,v 1.1 2000/01/28 23:18:43 ralf Exp $
+/*
+ * include/asm-mips/div64.h
+ * 
+ * Copyright (C) 2000  Maciej W. Rozycki
  *
  * This file is subject to the terms and conditions of the GNU General Public
  * License.  See the file "COPYING" in the main directory of this archive
@@ -7,14 +10,104 @@
 #ifndef _ASM_DIV64_H
 #define _ASM_DIV64_H
 
+#include <asm/sgidefs.h>
+
 /*
- * Hey, we're already 64-bit, no
- * need to play games..
+ * No traps on overflows for any of these...
  */
-#define do_div(n,base) ({ \
-	int __res; \
-	__res = ((unsigned long) n) % (unsigned) base; \
-	n = ((unsigned long) n) / (unsigned) base; \
-	__res; })
+
+#if (_MIPS_ISA == _MIPS_ISA_MIPS1) || (_MIPS_ISA == _MIPS_ISA_MIPS2)
+
+#define do_div64_32(res, high, low, base) ({ \
+	unsigned long __quot, __mod; \
+	unsigned long __cf, __tmp, __i; \
+	\
+	__asm__(".set	push\n\t" \
+		".set	noat\n\t" \
+		".set	noreorder\n\t" \
+		"b	1f\n\t" \
+		" li	%4,0x21\n" \
+		"0:\n\t" \
+		"sll	$1,%0,0x1\n\t" \
+		"srl	%3,%0,0x1f\n\t" \
+		"or	%0,$1,$2\n\t" \
+		"sll	%1,%1,0x1\n\t" \
+		"sll	%2,%2,0x1\n" \
+		"1:\n\t" \
+		"bnez	%3,2f\n\t" \
+		"sltu	$2,%0,%z5\n\t" \
+		"bnez	$2,3f\n\t" \
+		"2:\n\t" \
+		" addiu	%4,%4,-1\n\t" \
+		"subu	%0,%0,%z5\n\t" \
+		"addiu	%2,%2,1\n" \
+		"3:\n\t" \
+		"bnez	%4,0b\n\t" \
+		" srl	$2,%1,0x1f\n\t" \
+		".set	pop" \
+		: "=&r" (__mod), "=&r" (__tmp), "=&r" (__quot), "=&r" (__cf), \
+		  "=&r" (__i) \
+		: "Jr" (base), "0" (high), "1" (low), "2" (0), "3" (0) \
+		/* Aarrgh!  Ran out of gcc's limit on constraints... */ \
+		: "$1", "$2"); \
+	\
+	(res) = __quot; \
+	__mod; })
+
+#define do_div(n, base) ({ \
+	unsigned long long __quot; \
+	unsigned long __upper, __low, __high, __mod; \
+	\
+	__quot = (n); \
+	__high = __quot >> 32; \
+	__low = __quot; \
+	__upper = __high; \
+	\
+	if (__high) \
+		__asm__("divu	$0,%z2,%z3" \
+			: "=h" (__upper), "=l" (__high) \
+			: "Jr" (__high), "Jr" (base)); \
+	\
+	__mod = do_div64_32(__low, __upper, __low, base); \
+	\
+	__quot = __high; \
+	__quot = __quot << 32 | __low; \
+	(n) = __quot; \
+	__mod; })
+
+#else
+
+#define do_div64_32(res, high, low, base) ({ \
+	unsigned long __quot, __mod, __r0; \
+	\
+	__asm__("dsll32	%2,%z3,0\n\t" \
+		"or	%2,%2,%z4\n\t" \
+		"ddivu	$0,%2,%z5" \
+		: "=h" (__mod), "=l" (__quot), "=&r" (__r0) \
+		: "Jr" (high), "Jr" (low), "Jr" (base)); \
+	\
+	(res) = __quot; \
+	__mod; })
+
+#define do_div(n, base) ({ \
+	unsigned long long __quot; \
+	unsigned long __mod, __r0; \
+	\
+	__quot = (n); \
+	\
+	__asm__("dsll32	%2,%M3,0\n\t" \
+		"or	%2,%2,%L3\n\t" \
+		"ddivu	$0,%2,%z4\n\t" \
+		"mflo	%L1\n\t" \
+		"dsra32	%M1,%L1,0\n\t" \
+		"dsll32	%L1,%L1,0\n\t" \
+		"dsra32	%L1,%L1,0" \
+		: "=h" (__mod), "=r" (__quot), "=&r" (__r0) \
+		: "r" (n), "Jr" (base)); \
+	\
+	(n) = __quot; \
+	__mod; })
+
+#endif
 
 #endif /* _ASM_DIV64_H */


From owner-linux-mips@oss.sgi.com Mon Aug  7 08:31:21 2000
Received:  by oss.sgi.com id <S42190AbQHGPbL>;
	Mon, 7 Aug 2000 08:31:11 -0700
Received: from rotor.chem.unr.edu ([134.197.32.176]:22027 "EHLO
        rotor.chem.unr.edu") by oss.sgi.com with ESMTP id <S42183AbQHGPa5>;
	Mon, 7 Aug 2000 08:30:57 -0700
Received: (from wesolows@localhost)
	by rotor.chem.unr.edu (8.9.3/8.9.3) id IAA32547;
	Mon, 7 Aug 2000 08:30:02 -0700
Date:   Mon, 7 Aug 2000 08:30:02 -0700
From:   Keith M Wesolowski <wesolows@chem.unr.edu>
To:     Nathan Fraser <ndf@shorts.cx>
Cc:     linux-mips@oss.sgi.com
Subject: Re: [Install trouble] : mount failed: bad address
Message-ID: <20000807083002.A32048@chem.unr.edu>
References: <Pine.LNX.4.20.0008072030210.4379-100000@jarre.house>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2i
In-Reply-To: <Pine.LNX.4.20.0008072030210.4379-100000@jarre.house>; from ndf@shorts.cx on Mon, Aug 07, 2000 at 10:27:03PM +1000
X-Complaints-To: postmaster@chem.unr.edu
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing

On Mon, Aug 07, 2000 at 10:27:03PM +1000, Nathan Fraser wrote:

> I just tried installing with vmlinux-000804-IP22-4400 and
> hardhat-sgi-5.1.tar.gz - i get the same error as soon as the drive is
> formatted and is mounted (ie: mount failed: bad address)

I wonder if the DeadRat installer is using peecee style partition
tables. If so, then this is probably the source of the trouble. The
kernels I build, as you can see from the .config, don't support those,
only SGI style disklabels. If the fdisk in the installer doesn't
support that, then it won't work. It does seem odd though that you
couldn't mount an existing EFS filesystem.

There are also several problems with older fdisks; indeed, I think you
still need one of my patches for the current one to work properly.

The dated kernels I'm posting there are CVS from the 2.3/2.4 tree,
built with a CVS compiler and binutils. I wouldn't go using those on a
lark. For something as old as Hard Hat, maybe try the 2.2 kernel
instead.

I must admit to being the one person on this list who has never even
attempted to install Hard Hat, though, so maybe I don't know what I'm
talking about. :)

-- 
Keith M Wesolowski			wesolows@chem.unr.edu
University of Nevada			http://www.chem.unr.edu
Chemistry Department Systems and Network Administrator

From owner-linux-mips@oss.sgi.com Mon Aug  7 08:52:40 2000
Received:  by oss.sgi.com id <S42185AbQHGPwa>;
	Mon, 7 Aug 2000 08:52:30 -0700
Received: from delta.ds2.pg.gda.pl ([153.19.144.1]:28344 "EHLO
        delta.ds2.pg.gda.pl") by oss.sgi.com with ESMTP id <S42183AbQHGPwT>;
	Mon, 7 Aug 2000 08:52:19 -0700
Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id RAA04707;
	Mon, 7 Aug 2000 17:47:37 +0200 (MET DST)
Date:   Mon, 7 Aug 2000 17:47:36 +0200 (MET DST)
From:   "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
Reply-To: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To:     Ralf Baechle <ralf@uni-koblenz.de>,
        Harald Koerfgen <Harald.Koerfgen@home.ivm.de>
cc:     Craig P Prescott <prescott@phys.ufl.edu>, linux-mips@fnet.fr,
        linux-mips@oss.sgi.com
Subject: A workaround to DEC's RTC year weirdness
Message-ID: <Pine.GSO.3.96.1000807172634.3044D-100000@delta.ds2.pg.gda.pl>
Organization: Technical University of Gdansk
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing

Hi,

 Following is a patch that is an ultimate attempt to make the RTC's year
work for DECstations.  It uses an extra BBU RAM's location to store the
real year and the original year is used only as a reference, to make
incrementing work.  Changes address the handling of leap years, too.  The
two only drawbacks of the patch are as follows:

- there has to be at least a single RTC update during a year, as that's
the only situation the real year gets written into the BBU RAM,

- if a machine is powered down long enough the firmware decides to reset
contents the RTC, there is no other way to recover than to set time again. 

 I've tested various dates on my machine and the changes proved to work. 
The current implementation is expected to work until 2255 -- at about 220,
we'll have to change our epoch.

 The changes involved are not transparent, though.  I've used the last BBU
RAM's location that appears to be unused on my 3max+ (it's apparently true
for the preceding one, too).  The firmware wouldn't change either of bytes
no matter what I invoked (the "d" command excluded, of course) and what I
wrote into them.  I couldn't test Ultrix and OSF/1 interoperability
though.  Neither could I test other machines. 

 There appears to be some uncertainity on years permitted by the firmware,
too.  The original code quoted 70, 71 and 72 are permitted.  My system
permits 72 and 73 and also the original setting of the epoch suggests it
is true.  Therefore I strongly encourage everyone interested to test the
code as much as possible.

 Apart from interoperability issues, changes are rather straightforward.

 Comments are welcomed, as usual.

  Maciej

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

diff -u --recursive --new-file linux-mips-2.4.0-test5-20000731.macro/arch/mips/dec/time.c linux-mips-2.4.0-test5-20000731/arch/mips/dec/time.c
--- linux-mips-2.4.0-test5-20000731.macro/arch/mips/dec/time.c	Wed Jul 12 04:25:56 2000
+++ linux-mips-2.4.0-test5-20000731/arch/mips/dec/time.c	Sun Aug  6 14:24:55 2000
@@ -424,7 +424,7 @@
 
 void __init time_init(void)
 {
-	unsigned int year, mon, day, hour, min, sec;
+	unsigned int year, mon, day, hour, min, sec, real_year;
 	int i;
 
 	/* The Linux interpretation of the CMOS clock register contents:
@@ -457,10 +457,12 @@
 	}
 	/*
 	 * The DECstation RTC is used as a TOY (Time Of Year).
-	 * The PROM will reset the year to either '70, '71 or '72.
-	 * This hack will only work until Dec 31 2001.
+	 * The PROM will reset the year to either '72 or '73.
+	 * Therefore we store the real year separately, in one
+	 * of unused BBU RAM locations.
 	 */
-	year += 1928;
+	real_year = CMOS_READ(RTC_DEC_YEAR);
+	year += real_year - 72 + 2000;
 
 	write_lock_irq(&xtime_lock);
 	xtime.tv_sec = mktime(year, mon, day, hour, min, sec);
diff -u --recursive --new-file linux-mips-2.4.0-test5-20000731.macro/drivers/char/rtc.c linux-mips-2.4.0-test5-20000731/drivers/char/rtc.c
--- linux-mips-2.4.0-test5-20000731.macro/drivers/char/rtc.c	Mon Jul 24 04:26:06 2000
+++ linux-mips-2.4.0-test5-20000731/drivers/char/rtc.c	Sun Aug  6 14:22:34 2000
@@ -39,9 +39,10 @@
  *	1.10a	Andrea Arcangeli: Alpha updates
  *	1.10b	Andrew Morton: SMP lock fix
  *	1.10c	Cesar Barros: SMP locking fixes and cleanup
+ *	1.10d	Maciej W. Rozycki: Handle DECstation's year weirdness.
  */
 
-#define RTC_VERSION		"1.10c"
+#define RTC_VERSION		"1.10d"
 
 #define RTC_IO_EXTENT	0x10	/* Only really two ports, but...	*/
 
@@ -366,6 +367,9 @@
 		unsigned char mon, day, hrs, min, sec, leap_yr;
 		unsigned char save_control, save_freq_select;
 		unsigned int yrs;
+#ifdef CONFIG_DECSTATION
+		unsigned int real_yrs;
+#endif
 
 		if (!capable(CAP_SYS_TIME))
 			return -EACCES;
@@ -399,6 +403,20 @@
 			return -EINVAL;
 
 		spin_lock_irq(&rtc_lock);
+#ifdef CONFIG_DECSTATION
+		real_yrs = yrs;
+		yrs = 72;
+
+		/*
+		 * We want to keep the year set to 73 until March
+		 * for non-leap years, so that Feb, 29th is handled
+		 * correctly.
+		 */
+		if (!leap_yr && mon < 3) {
+			real_yrs--;
+			yrs = 73;
+		}
+#endif
 		if (!(CMOS_READ(RTC_CONTROL) & RTC_DM_BINARY)
 		    || RTC_ALWAYS_BCD) {
 			if (yrs > 169) {
@@ -421,6 +439,9 @@
 		save_freq_select = CMOS_READ(RTC_FREQ_SELECT);
 		CMOS_WRITE((save_freq_select|RTC_DIV_RESET2), RTC_FREQ_SELECT);
 
+#ifdef CONFIG_DECSTATION
+		CMOS_WRITE(real_yrs, RTC_DEC_YEAR);
+#endif
 		CMOS_WRITE(yrs, RTC_YEAR);
 		CMOS_WRITE(mon, RTC_MONTH);
 		CMOS_WRITE(day, RTC_DAY_OF_MONTH);
@@ -474,7 +495,7 @@
 		spin_unlock_irq(&rtc_lock);
 		return 0;
 	}
-#elif !defined(CONFIG_DECSTATION)
+#endif
 	case RTC_EPOCH_READ:	/* Read the epoch.	*/
 	{
 		return put_user (epoch, (unsigned long *)arg);
@@ -493,7 +514,6 @@
 		epoch = arg;
 		return 0;
 	}
-#endif
 	default:
 		return -EINVAL;
 	}
@@ -696,11 +716,11 @@
 	if (year > 20 && year < 48) {
 		epoch = 1980;
 		guess = "ARC console";
-	} else if (year >= 48 && year < 70) {
+	} else if (year >= 48 && year < 72) {
 		epoch = 1952;
 		guess = "Digital UNIX";
-	} else if (year >= 70 && year < 100) {
-		epoch = 1928;
+	} else if (year >= 72 && year < 74) {
+		epoch = 2000;
 		guess = "Digital DECstation";
 	}
 	if (guess)
@@ -904,6 +924,9 @@
 {
 	unsigned long uip_watchdog = jiffies;
 	unsigned char ctrl;
+#ifdef CONFIG_DECSTATION
+	unsigned int real_year;
+#endif
 
 	/*
 	 * read RTC once any update in progress is done. The update
@@ -932,6 +955,9 @@
 	rtc_tm->tm_mday = CMOS_READ(RTC_DAY_OF_MONTH);
 	rtc_tm->tm_mon = CMOS_READ(RTC_MONTH);
 	rtc_tm->tm_year = CMOS_READ(RTC_YEAR);
+#ifdef CONFIG_DECSTATION
+	real_year = CMOS_READ(RTC_DEC_YEAR);
+#endif
 	ctrl = CMOS_READ(RTC_CONTROL);
 	spin_unlock_irq(&rtc_lock);
 
@@ -944,6 +970,10 @@
 		BCD_TO_BIN(rtc_tm->tm_mon);
 		BCD_TO_BIN(rtc_tm->tm_year);
 	}
+
+#ifdef CONFIG_DECSTATION
+	rtc_tm->tm_year += real_year - 72;
+#endif
 
 	/*
 	 * Account for differences between how the RTC uses the values
diff -u --recursive --new-file linux-mips-2.4.0-test5-20000731.macro/include/asm-mips/mc146818rtc.h linux-mips-2.4.0-test5-20000731/include/asm-mips/mc146818rtc.h
--- linux-mips-2.4.0-test5-20000731.macro/include/asm-mips/mc146818rtc.h	Wed Aug  2 06:29:06 2000
+++ linux-mips-2.4.0-test5-20000731/include/asm-mips/mc146818rtc.h	Sat Aug  5 08:19:07 2000
@@ -48,4 +48,8 @@
 #define RTC_IRQ	8
 #endif
 
+#ifdef CONFIG_DECSTATION
+#define RTC_DEC_YEAR	0x3f	/* Where we store the real year on DECs.  */
+#endif
+
 #endif /* _ASM_MC146818RTC_H */



From owner-linux-mips@oss.sgi.com Mon Aug  7 09:01:40 2000
Received:  by oss.sgi.com id <S42192AbQHGQBa>;
	Mon, 7 Aug 2000 09:01:30 -0700
Received: from delta.ds2.pg.gda.pl ([153.19.144.1]:32184 "EHLO
        delta.ds2.pg.gda.pl") by oss.sgi.com with ESMTP id <S42183AbQHGQBG>;
	Mon, 7 Aug 2000 09:01:06 -0700
Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id RAA04813;
	Mon, 7 Aug 2000 17:56:52 +0200 (MET DST)
Date:   Mon, 7 Aug 2000 17:56:52 +0200 (MET DST)
From:   "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To:     Ralf Baechle <ralf@uni-koblenz.de>,
        Harald Koerfgen <Harald.Koerfgen@home.ivm.de>
cc:     Craig P Prescott <prescott@phys.ufl.edu>, linux-mips@fnet.fr,
        linux-mips@oss.sgi.com
Subject: BREAK and magic SysRq handling for Z8530
Message-ID: <Pine.GSO.3.96.1000807174812.3044E-100000@delta.ds2.pg.gda.pl>
Organization: Technical University of Gdansk
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing

Hi,

 It appears our current Z8530 driver lacks BREAK support.  It also has the
unfortunate side effect magic SysRq wouldn't work either, if we had it. 
Not anymore!  The following patch adds both features to our Z8530 driver. 
It also allows the magic SysRq hack to be compiled-in (i.e. no more
linking errors) even if no virtual terminal driver is build, which is
suitable for certain configurations, including mine.

 Comments are welcomed, as usually.

  Maciej

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

diff -u --recursive --new-file linux-mips-2.4.0-test5-20000731.macro/drivers/char/keyboard.c linux-mips-2.4.0-test5-20000731/drivers/char/keyboard.c
--- linux-mips-2.4.0-test5-20000731.macro/drivers/char/keyboard.c	Thu Feb 24 05:26:36 2000
+++ linux-mips-2.4.0-test5-20000731/drivers/char/keyboard.c	Sun Aug  6 09:15:46 2000
@@ -158,7 +158,6 @@
 
 #ifdef CONFIG_MAGIC_SYSRQ
 static int sysrq_pressed;
-int sysrq_enabled = 1;
 #endif
 
 static struct pm_dev *pm_kbd = NULL;
diff -u --recursive --new-file linux-mips-2.4.0-test5-20000731.macro/drivers/char/serial.c linux-mips-2.4.0-test5-20000731/drivers/char/serial.c
--- linux-mips-2.4.0-test5-20000731.macro/drivers/char/serial.c	Mon Jul 24 04:26:06 2000
+++ linux-mips-2.4.0-test5-20000731/drivers/char/serial.c	Sun Aug  6 09:21:03 2000
@@ -597,7 +597,8 @@
 				printk("handling break....");
 #endif
 #if defined(CONFIG_SERIAL_CONSOLE) && defined(CONFIG_MAGIC_SYSRQ) && !defined(MODULE)
-				if (info->line == sercons.index) {
+				if (info->line == sercons.index
+				    && sysrq_enabled) {
 					if (!break_pressed) {
 						break_pressed = jiffies;
 						goto ignore_char;
diff -u --recursive --new-file linux-mips-2.4.0-test5-20000731.macro/drivers/char/sysrq.c linux-mips-2.4.0-test5-20000731/drivers/char/sysrq.c
--- linux-mips-2.4.0-test5-20000731.macro/drivers/char/sysrq.c	Tue Mar 28 04:26:29 2000
+++ linux-mips-2.4.0-test5-20000731/drivers/char/sysrq.c	Sun Aug  6 09:17:58 2000
@@ -33,6 +33,8 @@
 /* Machine specific power off function */
 void (*sysrq_power_off)(void) = NULL;
 
+int sysrq_enabled = 1;
+
 EXPORT_SYMBOL(sysrq_power_off);
 
 /* Send a signal to all user processes */
diff -u --recursive --new-file linux-mips-2.4.0-test5-20000731.macro/drivers/sbus/char/sunkbd.c linux-mips-2.4.0-test5-20000731/drivers/sbus/char/sunkbd.c
--- linux-mips-2.4.0-test5-20000731.macro/drivers/sbus/char/sunkbd.c	Sat Jul 15 04:26:34 2000
+++ linux-mips-2.4.0-test5-20000731/drivers/sbus/char/sunkbd.c	Sun Aug  6 09:16:21 2000
@@ -177,9 +177,6 @@
 static struct pt_regs * pt_regs;
 
 #ifdef CONFIG_MAGIC_SYSRQ
-#ifndef CONFIG_PCI
-int sysrq_enabled = 1;
-#endif
 unsigned char sun_sysrq_xlate[128] =
 	"\0\0\0\0\0\201\202\212\203\213\204\214\205\0\206\0"	/* 0x00 - 0x0f */
 	"\207\210\211\0\0\0\0\0\0\0\0\0\0\03312"		/* 0x10 - 0x1f */
diff -u --recursive --new-file linux-mips-2.4.0-test5-20000731.macro/drivers/tc/zs.c linux-mips-2.4.0-test5-20000731/drivers/tc/zs.c
--- linux-mips-2.4.0-test5-20000731.macro/drivers/tc/zs.c	Sat Jul  8 04:26:53 2000
+++ linux-mips-2.4.0-test5-20000731/drivers/tc/zs.c	Sun Aug  6 13:34:43 2000
@@ -6,6 +6,7 @@
  *
  * DECstation changes
  * Copyright (C) 1998 Harald Koerfgen (Harald.Koerfgen@home.ivm.de)
+ * Copyright (C) 2000 Maciej W. Rozycki (macro@ds2.pg.gda.pl)
  *
  * For the rest of the code the original Copyright applies:
  * Copyright (C) 1996 Paul Mackerras (Paul.Mackerras@cs.anu.edu.au)
@@ -50,6 +51,9 @@
 #ifdef CONFIG_KGDB
 #include <asm/kgdb.h>
 #endif
+#ifdef CONFIG_MAGIC_SYSRQ
+#include <linux/sysrq.h>
+#endif
 
 #include "zs.h"
 
@@ -75,6 +79,10 @@
 #ifdef CONFIG_SERIAL_CONSOLE
 static struct console sercons;
 #endif
+#if defined(CONFIG_SERIAL_CONSOLE) && defined(CONFIG_MAGIC_SYSRQ) \
+    && !defined(MODULE)
+static unsigned long break_pressed; /* break, really ... */
+#endif
 
 #ifdef CONFIG_KGDB
 struct dec_zschannel *zs_kgdbchan;
@@ -302,6 +310,8 @@
  * -----------------------------------------------------------------------
  */
 
+static int tty_break;	/* Set whenever BREAK condition is detected.  */
+
 /*
  * This routine is used by the interrupt handler to schedule
  * processing in the software interrupt portion of the driver.
@@ -320,7 +330,7 @@
 	struct tty_struct *tty = info->tty;
 	unsigned char ch, stat, flag;
 
-	while ((read_zsreg(info->zs_channel, 0) & Rx_CH_AV) != 0) {
+	while ((read_zsreg(info->zs_channel, R0) & Rx_CH_AV) != 0) {
 
 		stat = read_zsreg(info->zs_channel, R1);
 		ch = read_zsdata(info->zs_channel);
@@ -330,13 +340,53 @@
 			if (ch == 0x03 || ch == '$')
 				breakpoint();
 			if (stat & (Rx_OVR|FRM_ERR|PAR_ERR))
-				write_zsreg(info->zs_channel, 0, ERR_RES);
+				write_zsreg(info->zs_channel, R0, ERR_RES);
 			return;
 		}
 #endif
 		if (!tty)
 			continue;
 
+		if (tty_break) {
+			tty_break = 0;
+#if defined(CONFIG_SERIAL_CONSOLE) && defined(CONFIG_MAGIC_SYSRQ) && !defined(MODULE)
+			if (info->line == sercons.index && sysrq_enabled) {
+				if (!break_pressed) {
+					break_pressed = jiffies;
+					goto ignore_char;
+				}
+				break_pressed = 0;
+			}
+#endif
+			flag = TTY_BREAK;
+			if (info->flags & ZILOG_SAK)
+				do_SAK(tty);
+		} else {
+			if (stat & Rx_OVR) {
+				flag = TTY_OVERRUN;
+			} else if (stat & FRM_ERR) {
+				flag = TTY_FRAME;
+			} else if (stat & PAR_ERR) {
+				flag = TTY_PARITY;
+			} else
+				flag = 0;
+			if (flag)
+				/* reset the error indication */
+				write_zsreg(info->zs_channel, R0, ERR_RES);
+		}
+
+#if defined(CONFIG_SERIAL_CONSOLE) && defined(CONFIG_MAGIC_SYSRQ) && !defined(MODULE)
+		if (break_pressed && info->line == sercons.index) {
+			if (ch != 0 &&
+			    time_before(jiffies, break_pressed + HZ*5)) {
+				handle_sysrq(ch, regs, NULL, NULL);
+				break_pressed = 0;
+				goto ignore_char;
+			}
+			break_pressed = 0;
+		}
+#endif
+
 		if (tty->flip.count >= TTY_FLIPBUF_SIZE) {
 			static int flip_buf_ovf;
 			++flip_buf_ovf;
@@ -348,26 +398,17 @@
 			if (flip_max_cnt < tty->flip.count)
 				flip_max_cnt = tty->flip.count;
 		}
-		if (stat & Rx_OVR) {
-			flag = TTY_OVERRUN;
-		} else if (stat & FRM_ERR) {
-			flag = TTY_FRAME;
-		} else if (stat & PAR_ERR) {
-			flag = TTY_PARITY;
-		} else
-			flag = 0;
-		if (flag)
-			/* reset the error indication */
-			write_zsreg(info->zs_channel, 0, ERR_RES);
+
 		*tty->flip.flag_buf_ptr++ = flag;
 		*tty->flip.char_buf_ptr++ = ch;
+	ignore_char:
 	}
 	tty_flip_buffer_push(tty);
 }
 
 static void transmit_chars(struct dec_serial *info)
 {
-	if ((read_zsreg(info->zs_channel, 0) & Tx_BUF_EMP) == 0)
+	if ((read_zsreg(info->zs_channel, R0) & Tx_BUF_EMP) == 0)
 		return;
 	info->tx_active = 0;
 
@@ -380,7 +421,7 @@
 	}
 
 	if ((info->xmit_cnt <= 0) || info->tty->stopped || info->tx_stopped) {
-		write_zsreg(info->zs_channel, 0, RES_Tx_P);
+		write_zsreg(info->zs_channel, R0, RES_Tx_P);
 		return;
 	}
 	/* Send char */
@@ -395,15 +436,22 @@
 
 static _INLINE_ void status_handle(struct dec_serial *info)
 {
-	unsigned char status;
+	unsigned char stat;
 
 	/* Get status from Read Register 0 */
-	status = read_zsreg(info->zs_channel, 0);
+	stat = read_zsreg(info->zs_channel, R0);
+
+	if (stat & BRK_ABRT) {
+#ifdef SERIAL_DEBUG_INTR
+		printk("handling break....");
+#endif
+		tty_break = 1;
+	}
 
 	/* FIXEM: Check for DCD transitions */
-	if (((status ^ info->read_reg_zero) & DCD) != 0
+	if (((stat ^ info->read_reg_zero) & DCD) != 0
 	    && info->tty && !C_CLOCAL(info->tty)) {
-		if (status & DCD) {
+		if (stat & DCD) {
 			wake_up_interruptible(&info->open_wait);
 		} else if (!(info->flags & ZILOG_CALLOUT_ACTIVE)) {
 			if (info->tty)
@@ -420,7 +468,7 @@
 		 * The DCD bit doesn't seem to be inverted
 		 * like this.
 		 */
-		if ((status & CTS) != 0) {
+		if ((stat & CTS) != 0) {
 			if (info->tx_stopped) {
 				info->tx_stopped = 0;
 				if (!info->tx_active)
@@ -432,8 +480,8 @@
 	}
 
 	/* Clear status condition... */
-	write_zsreg(info->zs_channel, 0, RES_EXT_INT);
-	info->read_reg_zero = status;
+	write_zsreg(info->zs_channel, R0, RES_EXT_INT);
+	info->read_reg_zero = stat;
 }
 
 /*
@@ -459,7 +507,7 @@
 		shift = 0;	/* Channel B */
 
 	for (;;) {
-		zs_intreg = read_zsreg(info->zs_chan_a, 3) >> shift; 
+		zs_intreg = read_zsreg(info->zs_chan_a, R3) >> shift; 
 		if ((zs_intreg & CHAN_IRQMASK) == 0)
 			break;
 


From owner-linux-mips@oss.sgi.com Mon Aug  7 10:46:19 2000
Received:  by oss.sgi.com id <S42205AbQHGRqA>;
	Mon, 7 Aug 2000 10:46:00 -0700
Received: from rotor.chem.unr.edu ([134.197.32.176]:46859 "EHLO
        rotor.chem.unr.edu") by oss.sgi.com with ESMTP id <S42190AbQHGRpk>;
	Mon, 7 Aug 2000 10:45:40 -0700
Received: (from wesolows@localhost)
	by rotor.chem.unr.edu (8.9.3/8.9.3) id KAA05058;
	Mon, 7 Aug 2000 10:44:56 -0700
Date:   Mon, 7 Aug 2000 10:44:55 -0700
From:   Keith M Wesolowski <wesolows@chem.unr.edu>
To:     linuxce-devel@linuxce.org, linux-mips@oss.sgi.com
Subject: Starting point for a wchan patch
Message-ID: <20000807104455.B3164@chem.unr.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2i
X-Complaints-To: postmaster@chem.unr.edu
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing

Hi,

This patch is a first attempt at a fix for the wchan BUG. It uses the
stack unwinder from the oops tracer. Unfortunately the results it
returns are often incorrect and even insane. I'm just hoping maybe it
will trigger someone's thinking in the right direction; it's obviously
nowhere near usable-quality.

Index: arch/mips/kernel/process.c
===================================================================
RCS file: /cvs/linux/arch/mips/kernel/process.c,v
retrieving revision 1.20
diff -u -r1.20 process.c
--- arch/mips/kernel/process.c	2000/07/11 02:32:10	1.20
+++ arch/mips/kernel/process.c	2000/08/04 23:36:32
@@ -197,6 +197,9 @@
 {
 	unsigned long schedule_frame;
 	unsigned long pc;
+	unsigned int *sp;
+	extern char _stext, _etext;
+	unsigned long kstart, kend;
 
 	if (!p || p == current || p->state == TASK_RUNNING)
 		return 0;
@@ -212,9 +215,21 @@
 		schedule_frame = ((unsigned long *)p->thread.reg30)[9];
 		return ((unsigned long *)schedule_frame)[16];
 	}
-	if (pc >= first_sched && pc < last_sched) {
-		printk(KERN_DEBUG "Bug in %s\n", __FUNCTION__);
+	sp = (unsigned int *)p->thread.reg29;
+	kstart = (unsigned long) &_stext;
+	kend = (unsigned long) &_etext;
+	if (pc < first_sched || pc >= last_sched)
+		goto out;
+        while ((unsigned long) sp & (PAGE_SIZE -1)) {
+                unsigned long addr;
+		if (!__get_user (addr, sp++))
+			if (addr > kstart && addr < kend) {
+				/* Could be a valid caller */
+				pc = addr;
+				if (pc < first_sched || pc >= last_sched)
+					goto out;
+			}
 	}
-
+out:
 	return pc;
 }


How's that for a crock, huh? :)

-- 
Keith M Wesolowski			wesolows@chem.unr.edu
University of Nevada			http://www.chem.unr.edu
Chemistry Department Systems and Network Administrator

From owner-linux-mips@oss.sgi.com Mon Aug  7 14:50:01 2000
Received:  by oss.sgi.com id <S42226AbQHGVtk>;
	Mon, 7 Aug 2000 14:49:40 -0700
Received: from jarre.otscorp.com ([203.44.145.48]:55561 "EHLO shorts.cx")
	by oss.sgi.com with ESMTP id <S42190AbQHGVtU>;
	Mon, 7 Aug 2000 14:49:20 -0700
Received: from pikachu.house (ndf@pikachu.house [192.168.10.30])
	by shorts.cx (8.11.0/8.11.0) with ESMTP id e77Lp2G09428;
	Tue, 8 Aug 2000 07:51:02 +1000
Date:   Tue, 8 Aug 2000 07:51:00 +1000 (EST)
From:   Nathan Fraser <ndf@shorts.cx>
X-Sender: ndf@pikachu.house
To:     Keith M Wesolowski <wesolows@chem.unr.edu>
cc:     linux-mips@oss.sgi.com
Subject: Re: [Install trouble] : mount failed: bad address
In-Reply-To: <20000807083002.A32048@chem.unr.edu>
Message-ID: <Pine.LNX.4.21.0008080746310.9414-100000@pikachu.house>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing


well if there is a way to get kernel, base system, vi and gcc going
without using redhat I'd be VERY interested to hear :)

On Mon, 7 Aug 2000, Keith M Wesolowski wrote:

> On Mon, Aug 07, 2000 at 10:27:03PM +1000, Nathan Fraser wrote:
> 
> > I just tried installing with vmlinux-000804-IP22-4400 and
> > hardhat-sgi-5.1.tar.gz - i get the same error as soon as the drive is
> > formatted and is mounted (ie: mount failed: bad address)
> 
> I wonder if the DeadRat installer is using peecee style partition
> tables. If so, then this is probably the source of the trouble. The
> kernels I build, as you can see from the .config, don't support those,
> only SGI style disklabels. If the fdisk in the installer doesn't
> support that, then it won't work. It does seem odd though that you
> couldn't mount an existing EFS filesystem.
> 
> There are also several problems with older fdisks; indeed, I think you
> still need one of my patches for the current one to work properly.
> 
> The dated kernels I'm posting there are CVS from the 2.3/2.4 tree,
> built with a CVS compiler and binutils. I wouldn't go using those on a
> lark. For something as old as Hard Hat, maybe try the 2.2 kernel
> instead.
> 
> I must admit to being the one person on this list who has never even
> attempted to install Hard Hat, though, so maybe I don't know what I'm
> talking about. :)
> 
> -- 
> Keith M Wesolowski			wesolows@chem.unr.edu
> University of Nevada			http://www.chem.unr.edu
> Chemistry Department Systems and Network Administrator
> 


From owner-linux-mips@oss.sgi.com Mon Aug  7 14:58:01 2000
Received:  by oss.sgi.com id <S42231AbQHGV5v>;
	Mon, 7 Aug 2000 14:57:51 -0700
Received: from smtpe.casema.net ([195.96.96.172]:42000 "HELO smtpe.casema.net")
	by oss.sgi.com with SMTP id <S42190AbQHGV5g>;
	Mon, 7 Aug 2000 14:57:36 -0700
Received: (qmail 32638 invoked from network); 7 Aug 2000 21:57:04 -0000
Received: from unknown (HELO penguin.nl) (195.96.116.1)
  by smtpe.casema.net with SMTP; 7 Aug 2000 21:57:04 -0000
Message-ID: <398F31FD.8C50931A@penguin.nl>
Date:   Tue, 08 Aug 2000 00:02:38 +0200
From:   Richard <richardh@penguin.nl>
X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.2.15 i686)
X-Accept-Language: en
MIME-Version: 1.0
To:     linux-mips@oss.sgi.com
Subject: mailinglist 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing

hi,

how do i get of this mailing list? i've tried about everything.

Richard


From owner-linux-mips@oss.sgi.com Tue Aug  8 13:56:47 2000
Received:  by oss.sgi.com id <S42271AbQHHU4h>;
	Tue, 8 Aug 2000 13:56:37 -0700
Received: from nilpferd.fachschaften.tu-muenchen.de ([129.187.176.79]:28153
        "HELO nilpferd.fachschaften.tu-muenchen.de") by oss.sgi.com with SMTP
	id <S42218AbQHHU4H>; Tue, 8 Aug 2000 13:56:07 -0700
Received: (qmail 1747 invoked from network); 8 Aug 2000 20:55:35 -0000
Received: from neptun.fachschaften.tu-muenchen.de (129.187.176.23)
  by nilpferd.fachschaften.tu-muenchen.de with SMTP; 8 Aug 2000 20:55:35 -0000
Date:   Tue, 8 Aug 2000 22:55:34 +0200 (CEST)
From:   Adrian Bunk <bunk@fs.tum.de>
X-Sender: bunk@neptun.fachschaften.tu-muenchen.de
To:     linux-mips@oss.sgi.com
Subject: Problem with recent mips kernel from CVS
Message-ID: <Pine.NEB.4.21.0008082252310.10793-100000@neptun.fachschaften.tu-muenchen.de>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing

Hi,

I wasn't able to configure the kernel 2.4.0-test6-pre7 from CVS without
creating the (empty) file linux/drivers/mtd/Config.in . After I created
this file, configuring worked.

cu,
Adrian

-- 
A "No" uttered from deepest conviction is better and greater than a
"Yes" merely uttered to please, or what is worse, to avoid trouble.
                -- Mahatma Ghandi


From owner-linux-mips@oss.sgi.com Tue Aug  8 15:05:08 2000
Received:  by oss.sgi.com id <S42274AbQHHWEu>;
	Tue, 8 Aug 2000 15:04:50 -0700
Received: from noose.gt.owl.de ([62.52.19.4]:17678 "HELO noose.gt.owl.de")
	by oss.sgi.com with SMTP id <S42218AbQHHWEW>;
	Tue, 8 Aug 2000 15:04:22 -0700
Received: by noose.gt.owl.de (Postfix, from userid 10)
	id 4184C7F7; Wed,  9 Aug 2000 00:05:52 +0200 (CEST)
Received: by paradigm.rfc822.org (Postfix, from userid 1000)
	id E632A8FF5; Mon,  7 Aug 2000 10:16:20 +0200 (CEST)
Date:   Mon, 7 Aug 2000 10:16:20 +0200
From:   Florian Lohoff <flo@rfc822.org>
To:     Famille Chauvat <famille.chauvat@free.fr>
Cc:     linux-mips@oss.sgi.com
Subject: Re: [Install trouble]
Message-ID: <20000807101620.B302@paradigm.rfc822.org>
References: <39847F16.543AA232@free.fr> <20000804210304.C313@paradigm.rfc822.org> <398D7E42.88D4005E@free.fr>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
User-Agent: Mutt/1.0.1i
In-Reply-To: <398D7E42.88D4005E@free.fr>; from famille.chauvat@free.fr on Sun, Aug 06, 2000 at 03:03:30PM +0000
Organization: rfc822 - pure communication
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing

On Sun, Aug 06, 2000 at 03:03:30PM +0000, Famille Chauvat wrote:
> Hi Florian,
> 
> Thanks for your response. Humm, I don't know how to boot with rw support...
> And, Keith M Wesolowski, see messages in this thread, modify the kernel to
> have a ramdisk support.

Look into /usr/src/linux/Documentation 

Booting with an "rw" root you just have to append "rw" to the command
line you boot with ...

> That what I don't understand, except a lot of another things :-), is how it
> runs. You know, I took a lot of things on internet, I read a lot of papers,
> perhaps not those I had to, and I've never ask to support or not the
> ramdisk. So my question is, how the kernel I took doesn't support something
> I never asked for. I'm not sure to be very clear :-)

Not the kernel uses it - The installer does - The installer tries
to create a /tmp filesystem in a ramdisk to proceed installation.
When there is no ramdisk support the /tmp filesystem creation will fail.

> With the new kernel I have, I've a new trouble. After the partition step, a
> message "mount failed, bad address" appears and I 've to reboot. Of course,
> the next time I'ld the same things. Any suggestion, any help, would be very
> appreciate.

No idea

> Btw, if you know someone of your team or friends who speak french, it could
> be better, for me, to explain what going wrong.

Sorry - Cant help you :)

Flo
-- 
Florian Lohoff		flo@rfc822.org		      	+49-5201-669912
     "If you're not having fun right now, you're wasting your time."


From owner-linux-mips@oss.sgi.com Wed Aug  9 01:02:00 2000
Received:  by oss.sgi.com id <S42216AbQHIIBv>;
	Wed, 9 Aug 2000 01:01:51 -0700
Received: from t111.niisi.ras.ru ([193.232.173.111]:41524 "EHLO
        t111.niisi.ras.ru") by oss.sgi.com with ESMTP id <S42215AbQHIIB1>;
	Wed, 9 Aug 2000 01:01:27 -0700
Received: from t06.niisi.ras.ru (t06.niisi.ras.ru [193.232.173.6])
	by t111.niisi.ras.ru (8.9.1/8.9.1) with ESMTP id MAA32540;
	Wed, 9 Aug 2000 12:00:06 +0400
Received: (from uucp@localhost) by t06.niisi.ras.ru (8.7.6/8.7.3) with UUCP id LAA09694; Wed, 9 Aug 2000 11:49:30 +0400
Received: from niisi.msk.ru (t34 [193.232.173.34]) by niisi.msk.ru (8.8.8/8.8.8) with ESMTP id LAA17229; Wed, 9 Aug 2000 11:56:19 +0400 (MSD)
Message-ID: <39911193.672C7E59@niisi.msk.ru>
Date:   Wed, 09 Aug 2000 12:08:51 +0400
From:   "Gleb O. Raiko" <raiko@niisi.msk.ru>
Organization: NIISI RAN
X-Mailer: Mozilla 4.72 [en] (WinNT; I)
X-Accept-Language: en,ru
MIME-Version: 1.0
To:     "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
CC:     Ralf Baechle <ralf@uni-koblenz.de>,
        Harald Koerfgen <Harald.Koerfgen@home.ivm.de>,
        Craig P Prescott <prescott@phys.ufl.edu>, linux-mips@fnet.fr,
        linux-mips@oss.sgi.com
Subject: Re: BREAK and magic SysRq handling for Z8530
References: <Pine.GSO.3.96.1000807174812.3044E-100000@delta.ds2.pg.gda.pl>
Content-Type: text/plain; charset=koi8-r
Content-Transfer-Encoding: 7bit
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing

Maciej,

"Maciej W. Rozycki" wrote:
> 
> Hi,
> 
>  It appears our current Z8530 driver lacks BREAK support.  It also has the
> unfortunate side effect magic SysRq wouldn't work either, if we had it.
> Not anymore!  The following patch adds both features to our Z8530 driver.
> It also allows the magic SysRq hack to be compiled-in (i.e. no more
> linking errors) even if no virtual terminal driver is build, which is
> suitable for certain configurations, including mine.
> 

Have you tested the patch? The problem isn't in the patch itself, but as
I see the zs driver is broken for a long time. At least, I used to patch
heavily this driver for my Baget taht has 2 zs chips on board. Harald
has the plans to implement new version of the driver, but I guess he is
busy all the time. Or have I missed a cleanup of the driver ?

Also, changes in sunkbd.c, keyboard.c, and serial.c isn't a good idea.
:-)

Regards,
Gleb.

From owner-linux-mips@oss.sgi.com Wed Aug  9 02:49:43 2000
Received:  by oss.sgi.com id <S42224AbQHIJtc>;
	Wed, 9 Aug 2000 02:49:32 -0700
Received: from delta.ds2.pg.gda.pl ([153.19.144.1]:27846 "EHLO
        delta.ds2.pg.gda.pl") by oss.sgi.com with ESMTP id <S42196AbQHIJtH>;
	Wed, 9 Aug 2000 02:49:07 -0700
Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id LAA11527;
	Wed, 9 Aug 2000 11:38:37 +0200 (MET DST)
Date:   Wed, 9 Aug 2000 11:38:37 +0200 (MET DST)
From:   "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To:     "Gleb O. Raiko" <raiko@niisi.msk.ru>
cc:     Ralf Baechle <ralf@uni-koblenz.de>,
        Harald Koerfgen <Harald.Koerfgen@home.ivm.de>,
        Craig P Prescott <prescott@phys.ufl.edu>, linux-mips@fnet.fr,
        linux-mips@oss.sgi.com
Subject: Re: BREAK and magic SysRq handling for Z8530
In-Reply-To: <39911193.672C7E59@niisi.msk.ru>
Message-ID: <Pine.GSO.3.96.1000809110212.11080A-100000@delta.ds2.pg.gda.pl>
Organization: Technical University of Gdansk
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing

Gleb,

> Have you tested the patch? The problem isn't in the patch itself, but as

 Sure I did, to an extent I was able to.  No problems noticed.

> I see the zs driver is broken for a long time. At least, I used to patch
> heavily this driver for my Baget taht has 2 zs chips on board. Harald

 Well, the driver seems to work good enough for now to use a serial
console.  And the SysRq support is an absolute must when trying to debug a
locked-up kernel -- the lack of this support is a sign for me nobody is
currently working on DECstations at the moment. 

> has the plans to implement new version of the driver, but I guess he is
> busy all the time. Or have I missed a cleanup of the driver ?

 Hmm, I haven't noticed any, either.  Fixing the driver is actually on my
TODO list -- all the 8530 drivers present in Linux currently need to be
merged into a single one.  Also DMA and synchronous mode support has to be
implemented.  It's not on the top of my list, though.

> Also, changes in sunkbd.c, keyboard.c, and serial.c isn't a good idea.
> :-)

 It's actually the reverse. ;-)  Without these (oh well, sunkbd.c is for
completeness, indeed) you cannot compile-in the magic SysRq support if you
do not include the virtual terminal driver.  This is an unnecessary
limitation -- I don't want the VT (well, actually I would, if I had a
driver for my console, but I haven't, yet). 

 Such changes actually went into the Linus' 2.4.0-test6-pre* (but not mine
-- someone overtook me, and he also missed one bit ;-) ).

  Maciej

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


From owner-linux-mips@oss.sgi.com Wed Aug  9 14:36:04 2000
Received:  by oss.sgi.com id <S42276AbQHIVfp>;
	Wed, 9 Aug 2000 14:35:45 -0700
Received: from u-22.karlsruhe.ipdial.viaginterkom.de ([62.180.19.22]:37125
        "EHLO u-22.karlsruhe.ipdial.viaginterkom.de") by oss.sgi.com
	with ESMTP id <S42278AbQHIVf2>; Wed, 9 Aug 2000 14:35:28 -0700
Received: (ralf@lappi) by lappi.waldorf-gmbh.de id <S868928AbQHIJGQ>;
        Wed, 9 Aug 2000 11:06:16 +0200
Date:   Wed, 9 Aug 2000 11:06:16 +0200
From:   Ralf Baechle <ralf@oss.sgi.com>
To:     Adrian Bunk <bunk@fs.tum.de>
Cc:     linux-mips@oss.sgi.com
Subject: Re: Problem with recent mips kernel from CVS
Message-ID: <20000809110616.A9918@bacchus.dhis.org>
References: <Pine.NEB.4.21.0008082252310.10793-100000@neptun.fachschaften.tu-muenchen.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0.1i
In-Reply-To: <Pine.NEB.4.21.0008082252310.10793-100000@neptun.fachschaften.tu-muenchen.de>; from bunk@fs.tum.de on Tue, Aug 08, 2000 at 10:55:34PM +0200
X-Accept-Language: de,en,fr
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing

On Tue, Aug 08, 2000 at 10:55:34PM +0200, Adrian Bunk wrote:

> I wasn't able to configure the kernel 2.4.0-test6-pre7 from CVS without
> creating the (empty) file linux/drivers/mtd/Config.in . After I created
> this file, configuring worked.

Strange.  The current pre8 kernel has this file and it should be 3331 bytes.
Just try cvs update.

  Ralf

From owner-linux-mips@oss.sgi.com Wed Aug  9 14:36:14 2000
Received:  by oss.sgi.com id <S42281AbQHIVgF>;
	Wed, 9 Aug 2000 14:36:05 -0700
Received: from u-22.karlsruhe.ipdial.viaginterkom.de ([62.180.19.22]:37125
        "EHLO u-22.karlsruhe.ipdial.viaginterkom.de") by oss.sgi.com
	with ESMTP id <S42279AbQHIVfa>; Wed, 9 Aug 2000 14:35:30 -0700
Received: (ralf@lappi) by lappi.waldorf-gmbh.de id <S868943AbQHIQN5>;
        Wed, 9 Aug 2000 18:13:57 +0200
Date:   Wed, 9 Aug 2000 18:13:57 +0200
From:   Ralf Baechle <ralf@oss.sgi.com>
To:     "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
Cc:     "Gleb O. Raiko" <raiko@niisi.msk.ru>,
        Ralf Baechle <ralf@uni-koblenz.de>,
        Harald Koerfgen <Harald.Koerfgen@home.ivm.de>,
        Craig P Prescott <prescott@phys.ufl.edu>, linux-mips@fnet.fr,
        linux-mips@oss.sgi.com
Subject: Re: BREAK and magic SysRq handling for Z8530
Message-ID: <20000809181357.B10906@bacchus.dhis.org>
References: <39911193.672C7E59@niisi.msk.ru> <Pine.GSO.3.96.1000809110212.11080A-100000@delta.ds2.pg.gda.pl>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0.1i
In-Reply-To: <Pine.GSO.3.96.1000809110212.11080A-100000@delta.ds2.pg.gda.pl>; from macro@ds2.pg.gda.pl on Wed, Aug 09, 2000 at 11:38:37AM +0200
X-Accept-Language: de,en,fr
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing

On Wed, Aug 09, 2000 at 11:38:37AM +0200, Maciej W. Rozycki wrote:

>  It's actually the reverse. ;-)  Without these (oh well, sunkbd.c is for
> completeness, indeed) you cannot compile-in the magic SysRq support if you
> do not include the virtual terminal driver.  This is an unnecessary
> limitation -- I don't want the VT (well, actually I would, if I had a
> driver for my console, but I haven't, yet). 
> 
>  Such changes actually went into the Linus' 2.4.0-test6-pre* (but not mine
> -- someone overtook me, and he also missed one bit ;-) ).

That probably where Prumpf's changes; I recently discussed various problem
with SysRq with him.  I guess he only tried to fix the HP part of the
problem.

  Ralf

From owner-linux-mips@oss.sgi.com Wed Aug  9 16:09:16 2000
Received:  by oss.sgi.com id <S42277AbQHIXI7>;
	Wed, 9 Aug 2000 16:08:59 -0700
Received: from pneumatic-tube.sgi.com ([204.94.214.22]:3435 "EHLO
        pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP
	id <S42259AbQHIXId>; Wed, 9 Aug 2000 16:08:33 -0700
Received: from cthulhu.engr.sgi.com (gate3-relay.engr.sgi.com [130.62.1.234]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id QAA01436
	for <linux-mips@oss.sgi.com>; Wed, 9 Aug 2000 16:13:58 -0700 (PDT)
	mail_from (jsimmons@acsu.buffalo.edu)
Received: from sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id QAA04515
	for <linux@cthulhu.engr.sgi.com>;
	Wed, 9 Aug 2000 16:07:38 -0700 (PDT)
	mail_from (jsimmons@acsu.buffalo.edu)
Received: from mailrelay.acsu.buffalo.edu (mailrelay.acsu.buffalo.edu [128.205.7.101]) 
	by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam:
       SGI does not authorize the use of its proprietary
       systems or networks for unsolicited or bulk email
       from the Internet.) 
	via SMTP id QAA04543
	for <linux@cthulhu.engr.sgi.com>; Wed, 9 Aug 2000 16:07:19 -0700 (PDT)
	mail_from (jsimmons@acsu.buffalo.edu)
Received: (qmail 1772 invoked from network); 9 Aug 2000 23:07:16 -0000
Received: from ubppp233-118.dialin.buffalo.edu (128.205.233.118)
  by mailrelay with SMTP; 9 Aug 2000 23:07:16 -0000
Date:   Wed, 9 Aug 2000 19:17:02 -0400 (EDT)
From:   James Simmons <jsimmons@acsu.buffalo.edu>
X-Sender: jsimmons@maxwell.futurevision.com
To:     i15@ornl.gov
cc:     linux-fbdev@vuser.vu.union.edu, linux@cthulhu.engr.sgi.com
Subject: Re: [linux-fbdev] SGI VW 540, fbdev and pot pourii of faults and
 evidence..:-)
In-Reply-To: <Pine.LNX.4.21.0008051851230.943-100000@janus.lsd.ornl.gov>
Message-ID: <Pine.LNX.4.10.10008091913570.1534-100000@maxwell.futurevision.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing


> I would also like to ask, if SGI is likely to make the hardware specs OSS
> (for cobalt etc.), so that those with the skill (this is not my forte, but
> I will try...), can stabilise this otherwise competent port.

Nope. SGI no longer supports Visual Workstations with linux. I don't even
know if they support Visual Workstatiosn period. It would be nice if they
did release the specs anyways :-)

> 1. After boot , no matter what video mode one is in, the text console is
> zippy. After using X (or changing modes using fbset) the text scrolling is
> *painfully* slow. There is no apparent difference in the kernel mechanism
> when switching, so is it just the boot state that works?

Which X server?  Sounds like the X server is doing the naughty.

> 	Empirical observations (i.e. writing known patterns to the
> /dev/fb0 device) indicate that SGI reverse RGB for 888 format, compared to
> RGB565. That is red offset=0, green=8,blue=16 rather than red=24 etc.. I
> have reversed the assignment in the "var" structure (in sgivwfb_set_var )
> and in setcolreg the offsets are used, but to no effect. What else needs
> changing?

Have a patch for this? Can you post it?

----------------------------------------------------------------------------
Innovation, innovate, and the concept of doing what everyone else did 20
years ago are registered trademarks of Microsoft Corporation. Other
buzzwords, euphemisms, and blatant lies are trademarks of their respective
owners.

James Simmons  [jsimmons@linux-fbdev.org]               ____/| 
fbdev/console/gfx developer                             \ o.O| 
http://www.linux-fbdev.org                               =(_)= 
http://linuxgfx.sourceforge.net                            U
http://linuxconsole.sourceforge.net


From owner-linux-mips@oss.sgi.com Wed Aug  9 16:30:56 2000
Received:  by oss.sgi.com id <S42279AbQHIXau>;
	Wed, 9 Aug 2000 16:30:50 -0700
Received: from pneumatic-tube.sgi.com ([204.94.214.22]:41325 "EHLO
        pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP
	id <S42259AbQHIXaF>; Wed, 9 Aug 2000 16:30:05 -0700
Received: from cthulhu.engr.sgi.com (gate3-relay.engr.sgi.com [130.62.1.234]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id QAA01685
	for <linux-mips@oss.sgi.com>; Wed, 9 Aug 2000 16:35:16 -0700 (PDT)
	mail_from (philloc@tigger.ccs.ornl.gov)
From:   philloc@tigger.ccs.ornl.gov
Received: from sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id QAA50004
	for <linux@cthulhu.engr.sgi.com>;
	Wed, 9 Aug 2000 16:28:57 -0700 (PDT)
	mail_from (philloc@tigger.ccs.ornl.gov)
Received: from tigger.ccs.ornl.gov (tigger.ccs.ornl.gov [134.167.16.90]) 
	by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam:
       SGI does not authorize the use of its proprietary
       systems or networks for unsolicited or bulk email
       from the Internet.) 
	via ESMTP id QAA06032
	for <linux@cthulhu.engr.sgi.com>; Wed, 9 Aug 2000 16:28:48 -0700 (PDT)
	mail_from (philloc@tigger.ccs.ornl.gov)
Received: from localhost (philloc@localhost)
	by tigger.ccs.ornl.gov (8.9.1/8.9.1) with ESMTP id TAA27407;
	Wed, 9 Aug 2000 19:28:08 -0400 (EDT)
Date:   Wed, 9 Aug 2000 19:28:07 -0400
Reply-To: i15@ornl.gov
To:     James Simmons <jsimmons@acsu.buffalo.edu>
cc:     linux-fbdev@vuser.vu.union.edu, linux@cthulhu.engr.sgi.com
Subject: Re: [linux-fbdev] SGI VW 540, fbdev and pot pourii of faults and
 evidence..:-)
In-Reply-To: <Pine.LNX.4.10.10008091913570.1534-100000@maxwell.futurevision.com>
Message-ID: <Pine.SGI.4.10.10008091908170.26870-100000@tigger.ccs.ornl.gov>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing

	Hi,
> 
> > I would also like to ask, if SGI is likely to make the hardware specs OSS
> > (for cobalt etc.), so that those with the skill (this is not my forte, but
> > I will try...), can stabilise this otherwise competent port.
> 
> Nope. SGI no longer supports Visual Workstations with linux. I don't even
> know if they support Visual Workstatiosn period. It would be nice if they
> did release the specs anyways :-)
	They support it on WindozeNT etc... I was toying with the idea of 
running VMware just to see what the X server will do under NT.


	Anyone from SGI care to comment on why SGI has not released the
specs to reasonable attention, since they are unable to help port? 

As complex as the hardware is, the SGI guys did a pretty good job on the
"hacks" they put in, so I am sure the specs would make it a breeze to port
:-)

> 
> > 1. After boot , no matter what video mode one is in, the text console is
> > zippy. After using X (or changing modes using fbset) the text scrolling is
> > *painfully* slow. There is no apparent difference in the kernel mechanism
> > when switching, so is it just the boot state that works?
> 
> Which X server?  Sounds like the X server is doing the naughty.
	Oh not even X. X is fine in fact (with the exception it shivers
and is tinted green in 32bit 1600x1200, and tinted green in 32bit 
1280x1024 , but fine in 8-16bit for all modes).

	The problems is: 

	machine boots. Text scrolling fine, no matter what I set it to
in the kernel (in 8bit colour that is. 16bit and I lose the fonts). If you
then fbset to ANY mode (say 800x600x8), and then do "ls -l", it is very
slow. Now I have stared at the kernel for a bit, and the only thing that
strikes me, is that on boot the frambuffer is initialised etc.., and it is
possible that the hardware is in some sort of "bios" mode, which plays
nice with the framebuffer. After boot, we switch the mode etc... but
something is not tripped, or the kernel/video uses a different set of
routines.

	I suppose I should ask, anyone else see this behaviour?

> 
> > 	Empirical observations (i.e. writing known patterns to the
> > /dev/fb0 device) indicate that SGI reverse RGB for 888 format, compared to
> > RGB565. That is red offset=0, green=8,blue=16 rather than red=24 etc.. I
> > have reversed the assignment in the "var" structure (in sgivwfb_set_var )
> > and in setcolreg the offsets are used, but to no effect. What else needs
> > changing?
> 
> Have a patch for this? Can you post it?

	If you want, but it has no effect, as bemusing as that sounds. I
could post the framebuffer test program (generates a framebuffer-file full
of "regular" colours, so you can deduce the settings visually- very nasty
hack).


	Oh BTW, kernel is 2.2.13 with all SGI patches (before they yanked
the OSS site),and a few mods of my own to get it to compile(inthe setup
rotuines).

	Hey as an aside, anyone know how to "uncompress" a "vmlinuz"
kernel to a "vmlinux"? SGI had posted a kernel or 2 , but always in the
"vmlinuz" format. To the best of my knowledge cannot be booted
on the VW 540.

	
	Finally, I looked at rewriting the visw_apic.c code upto 2.4 , to
the new format. It looks do-able, but I know little about this, and I do
not know if anyone else has had a hack yet.


	Cheers for now

	PHiL


From owner-linux-mips@oss.sgi.com Wed Aug  9 17:31:16 2000
Received:  by oss.sgi.com id <S42280AbQHJAbH>;
	Wed, 9 Aug 2000 17:31:07 -0700
Received: from smtp13.bellglobal.com ([204.101.251.52]:25508 "EHLO
        smtp13.bellglobal.com") by oss.sgi.com with ESMTP id <S42259AbQHJAae>;
	Wed, 9 Aug 2000 17:30:34 -0700
Received: from free.fr (Quebec-City-ppp29135.qc.sympatico.ca [216.208.213.189])
	by smtp13.bellglobal.com (8.8.5/8.8.5) with ESMTP id UAA06870;
	Wed, 9 Aug 2000 20:33:56 -0400 (EDT)
Message-ID: <3991F7A3.FFC55F85@free.fr>
Date:   Thu, 10 Aug 2000 00:30:27 +0000
From:   Famille Chauvat <famille.chauvat@free.fr>
X-Mailer: Mozilla 4.7 [en] (X11; U; Linux 2.2.9-27mdk i686)
X-Accept-Language: fr-FR, en
MIME-Version: 1.0
To:     Nathan Fraser <ndf@shorts.cx>
CC:     linux-mips@oss.sgi.com
Subject: Re: [Install trouble] : mount failed: bad address
References: <Pine.LNX.4.21.0008080746310.9414-100000@pikachu.house>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing

Please, don't keep it for yourself....
Philippe.

From owner-linux-mips@oss.sgi.com Wed Aug  9 18:13:17 2000
Received:  by oss.sgi.com id <S42285AbQHJBNH>;
	Wed, 9 Aug 2000 18:13:07 -0700
Received: from [204.94.214.10] ([204.94.214.10]:24145 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S42283AbQHJBMp>;
	Wed, 9 Aug 2000 18:12:45 -0700
Received: from nodin.corp.sgi.com (nodin.corp.sgi.com [192.26.51.193]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id SAA17147
	for <linux-mips@oss.sgi.com>; Wed, 9 Aug 2000 18:02:59 -0700 (PDT)
	mail_from (jsun@mvista.com)
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by nodin.corp.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) via ESMTP id SAA53981 for <linux-mips@oss.sgi.com>; Wed, 9 Aug 2000 18:10:02 -0700 (PDT)
Received: from sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id SAA35592
	for <linux@engr.sgi.com>;
	Wed, 9 Aug 2000 18:08:25 -0700 (PDT)
	mail_from (jsun@mvista.com)
Received: from hermes.mvista.com (gateway-490.mvista.com [63.192.220.206]) 
	by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam:
       SGI does not authorize the use of its proprietary
       systems or networks for unsolicited or bulk email
       from the Internet.) 
	via ESMTP id SAA07442
	for <linux@engr.sgi.com>; Wed, 9 Aug 2000 18:08:16 -0700 (PDT)
	mail_from (jsun@mvista.com)
Received: from mvista.com (IDENT:jsun@orion.mvista.com [10.0.0.75])
	by hermes.mvista.com (8.9.3/8.9.3) with ESMTP id SAA17369;
	Wed, 9 Aug 2000 18:08:14 -0700
Message-ID: <3992007C.49050FC@mvista.com>
Date:   Wed, 09 Aug 2000 18:08:12 -0700
From:   Jun Sun <jsun@mvista.com>
X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.12-20b i586)
X-Accept-Language: en
MIME-Version: 1.0
To:     linux@cthulhu.engr.sgi.com, linux-mips@fnet.fr
Subject: bug in the latest cache code?
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing


Ralf,

I spent the last a few days to track down a problem where /sbin/init
hangs forever.  It turns out, I believe, to be a bug introduced in the
recent cache code change.

A new function, r4k_flush_icache_page_i32(), was added recently.  It
calls blast_icache32_page(), which uses Hit cache operations to flush
cache.  Unfortunately, that will generate TLB fault if virtual address
is not present in TLB.  Under certain conditions,
r4k_flush_icache_page_i32() will be called in the middle of handling a
page fault, and it will then generate the same page fault again with
cache hit operation.  This causes a deadlock (on current->mm->mmap_sem).

I read the previous version of code.  The fix seems to be using the
indexed cache operation.  Here is the fix, and apparently it fixes the
problem on my board.

Jun

-----------

static void
r4k_flush_icache_page_i32(struct vm_area_struct *vma, struct page *page,
                      unsigned long address)
{
        if (!(vma->vm_flags & VM_EXEC))
                return;

-        blast_icache32_page(address);
+        address = KSEG0 + (address & PAGE_MASK & (dcache_size - 1));
+        blast_icache32_page_indexed(address);
}

From owner-linux-mips@oss.sgi.com Wed Aug  9 19:39:08 2000
Received:  by oss.sgi.com id <S42201AbQHJCi6>;
	Wed, 9 Aug 2000 19:38:58 -0700
Received: from pneumatic-tube.sgi.com ([204.94.214.22]:29816 "EHLO
        pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP
	id <S42199AbQHJCiZ>; Wed, 9 Aug 2000 19:38:25 -0700
Received: from nodin.corp.sgi.com (nodin.corp.sgi.com [192.26.51.193]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id TAA06431
	for <linux-mips@oss.sgi.com>; Wed, 9 Aug 2000 19:43:57 -0700 (PDT)
	mail_from (nemoto@toshiba-tops.co.jp)
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by nodin.corp.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) via ESMTP id TAA12238 for <linux-mips@oss.sgi.com>; Wed, 9 Aug 2000 19:37:22 -0700 (PDT)
Received: from deliverator.sgi.com (deliverator.sgi.com [150.166.91.37])
	by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id TAA46148
	for <linux@engr.sgi.com>;
	Wed, 9 Aug 2000 19:35:50 -0700 (PDT)
	mail_from (nemoto@toshiba-tops.co.jp)
Received: from fwgate.toshiba-tops.co.jp (fwgate.toshiba-tops.co.jp [202.230.225.20]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via SMTP id TAA24432
	for <linux@engr.sgi.com>; Wed, 9 Aug 2000 19:28:12 -0700 (PDT)
	mail_from (nemoto@toshiba-tops.co.jp)
Received: from topsms by fwgate.toshiba-tops.co.jp
          via smtpd (for deliverator.sgi.com [204.94.214.10]) with SMTP; 10 Aug 2000 02:35:46 UT
Received: from srd2sd.toshiba-tops.co.jp (gw-chiba7.toshiba-tops.co.jp [172.17.244.27])
	by newms.toshiba-tops.co.jp (8.9.3/3.7W-MailExchenger) with ESMTP id LAA02650;
	Thu, 10 Aug 2000 11:30:37 +0900 (JST)
Received: by srd2sd.toshiba-tops.co.jp (8.9.3/3.5Wbeta-srd2sd) with ESMTP
	id LAA89823; Thu, 10 Aug 2000 11:30:37 +0900 (JST)
To:     jsun@mvista.com
Cc:     linux@cthulhu.engr.sgi.com, linux-mips@fnet.fr
Subject: Re: bug in the latest cache code?
From:   Atsushi Nemoto <nemoto@toshiba-tops.co.jp>
In-Reply-To: <3992007C.49050FC@mvista.com>
References: <3992007C.49050FC@mvista.com>
X-Mailer: Mew version 1.94.1 on Emacs 20.5 / Mule 4.0 (HANANOEN)
X-Fingerprint: EC 9D B9 17 2E 89 D2 25  CE F5 5D 3D 12 29 2A AD
X-Pgp-Public-Key: http://pgp.nic.ad.jp/cgi-bin/pgpsearchkey.pl?op=get&search=0xB6D728B1
Organization: TOSHIBA Personal Computer System Corporation
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <20000810113036S.nemoto@toshiba-tops.co.jp>
Date:   Thu, 10 Aug 2000 11:30:36 +0900
X-Dispatcher: imput version 990905(IM130)
Lines:  25
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing

>>>>> On Wed, 09 Aug 2000 18:08:12 -0700, Jun Sun <jsun@mvista.com> said:
jsun> A new function, r4k_flush_icache_page_i32(), was added recently.
jsun> It calls blast_icache32_page(), which uses Hit cache operations
jsun> to flush cache.  Unfortunately, that will generate TLB fault if
jsun> virtual address is not present in TLB.  Under certain
jsun> conditions, r4k_flush_icache_page_i32() will be called in the
jsun> middle of handling a page fault, and it will then generate the
jsun> same page fault again with cache hit operation.  This causes a
jsun> deadlock (on current->mm->mmap_sem).

To my knowlege, if the vierual address is not present in TLB, cache
hit operation generates TLB refill exception, not TLB invalid
exception.  After the TLB refill excepsion, the cache instruction can
continue execution without a page fault (no deadlock).

I met the same deadlock problem on my r3k (with r4k-like cache) board
with 2.2.12 based kernel.  I doubted my TLB/cache codes first, but the
real cause was in vt.c.  _kd_mksound() modifies TLB refill handler
code if mips_io_port_base == 0xa0000000.  Modifing the #if-line near
_kd_mksound() fixed my problem.

Hope this helps.

---
Atsushi Nemoto

From owner-linux-mips@oss.sgi.com Wed Aug  9 20:44:29 2000
Received:  by oss.sgi.com id <S42208AbQHJDoT>;
	Wed, 9 Aug 2000 20:44:19 -0700
Received: from jarre.otscorp.com ([203.44.145.48]:8459 "EHLO shorts.cx")
	by oss.sgi.com with ESMTP id <S42199AbQHJDoE>;
	Wed, 9 Aug 2000 20:44:04 -0700
Received: from jarre.house (ndf@jarre.house [192.168.10.1])
	by shorts.cx (8.11.0/8.11.0) with ESMTP id e7A3kXs12327;
	Thu, 10 Aug 2000 13:46:33 +1000
Date:   Thu, 10 Aug 2000 13:46:22 +1000 (EST)
From:   Nathan Fraser <ndf@shorts.cx>
X-Sender: ndf@jarre.house
To:     Famille Chauvat <famille.chauvat@free.fr>
cc:     linux-mips@oss.sgi.com
Subject: Re: [Install trouble] : mount failed: bad address
In-Reply-To: <3991F7A3.FFC55F85@free.fr>
Message-ID: <Pine.LNX.4.20.0008101342100.1188-100000@jarre.house>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing

i just used the indy sound kernel:

vmlinux-indy-sound-2.2.1-990526.tgz

from the testing directory and the install worked fine. After the install
all works swell...

Props to Ulf for the alsa driver! it works GREAT!

On Thu, 10 Aug 2000, Famille Chauvat wrote:

> Please, don't keep it for yourself....
> Philippe.
> 


From owner-linux-mips@oss.sgi.com Thu Aug 10 10:40:28 2000
Received:  by oss.sgi.com id <S42203AbQHJRkJ>;
	Thu, 10 Aug 2000 10:40:09 -0700
Received: from u-173.karlsruhe.ipdial.viaginterkom.de ([62.180.19.173]:6404
        "EHLO u-173.karlsruhe.ipdial.viaginterkom.de") by oss.sgi.com
	with ESMTP id <S42202AbQHJRji>; Thu, 10 Aug 2000 10:39:38 -0700
Received: (ralf@lappi) by lappi.waldorf-gmbh.de id <S868787AbQHJRi6>;
        Thu, 10 Aug 2000 19:38:58 +0200
Date:   Thu, 10 Aug 2000 19:38:58 +0200
From:   Ralf Baechle <ralf@uni-koblenz.de>
To:     Jun Sun <jsun@mvista.com>
Cc:     linux-mips@oss.sgi.com, linux-mips@fnet.fr,
        linux-mips@vger.rutgers.edu
Subject: Re: bug in the latest cache code?
Message-ID: <20000810193858.A1478@bacchus.dhis.org>
References: <3992007C.49050FC@mvista.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0.1i
In-Reply-To: <3992007C.49050FC@mvista.com>; from jsun@mvista.com on Wed, Aug 09, 2000 at 06:08:12PM -0700
X-Accept-Language: de,en,fr
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing

On Wed, Aug 09, 2000 at 06:08:12PM -0700, Jun Sun wrote:

> I spent the last a few days to track down a problem where /sbin/init
> hangs forever.  It turns out, I believe, to be a bug introduced in the
> recent cache code change.
> 
> A new function, r4k_flush_icache_page_i32(), was added recently.  It
> calls blast_icache32_page(), which uses Hit cache operations to flush
> cache.  Unfortunately, that will generate TLB fault if virtual address
> is not present in TLB.  Under certain conditions,
> r4k_flush_icache_page_i32() will be called in the middle of handling a
> page fault, and it will then generate the same page fault again with
> cache hit operation.  This causes a deadlock (on current->mm->mmap_sem).
> 
> I read the previous version of code.  The fix seems to be using the
> indexed cache operation.  Here is the fix, and apparently it fixes the
> problem on my board.

I can see how this may happen and will take care of fixing this one.

We really want to avoid using index operations.  Unlike what the comment
in the kernel code suggest they do overly flush caches which is pretty
expensive.

  Ralf

From owner-linux-mips@oss.sgi.com Thu Aug 10 10:51:58 2000
Received:  by oss.sgi.com id <S42213AbQHJRvt>;
	Thu, 10 Aug 2000 10:51:49 -0700
Received: from gateway-490.mvista.com ([63.192.220.206]:64503 "EHLO
        hermes.mvista.com") by oss.sgi.com with ESMTP id <S42202AbQHJRvc>;
	Thu, 10 Aug 2000 10:51:32 -0700
Received: from mvista.com (IDENT:jsun@orion.mvista.com [10.0.0.75])
	by hermes.mvista.com (8.9.3/8.9.3) with ESMTP id KAA04609;
	Thu, 10 Aug 2000 10:50:28 -0700
Message-ID: <3992EB64.8F2587A6@mvista.com>
Date:   Thu, 10 Aug 2000 10:50:28 -0700
From:   Jun Sun <jsun@mvista.com>
X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.12-20b i586)
X-Accept-Language: en
MIME-Version: 1.0
To:     Ralf Baechle <ralf@uni-koblenz.de>
CC:     linux-mips@oss.sgi.com, linux-mips@fnet.fr,
        linux-mips@vger.rutgers.edu
Subject: Re: bug in the latest cache code?
References: <3992007C.49050FC@mvista.com> <20000810193858.A1478@bacchus.dhis.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing

Ralf Baechle wrote:
> 
> On Wed, Aug 09, 2000 at 06:08:12PM -0700, Jun Sun wrote:
> 
> > I spent the last a few days to track down a problem where /sbin/init
> > hangs forever.  It turns out, I believe, to be a bug introduced in the
> > recent cache code change.
> >
> > A new function, r4k_flush_icache_page_i32(), was added recently.  It
> > calls blast_icache32_page(), which uses Hit cache operations to flush
> > cache.  Unfortunately, that will generate TLB fault if virtual address
> > is not present in TLB.  Under certain conditions,
> > r4k_flush_icache_page_i32() will be called in the middle of handling a
> > page fault, and it will then generate the same page fault again with
> > cache hit operation.  This causes a deadlock (on current->mm->mmap_sem).
> >
> > I read the previous version of code.  The fix seems to be using the
> > indexed cache operation.  Here is the fix, and apparently it fixes the
> > problem on my board.
> 
> I can see how this may happen and will take care of fixing this one.
> 

Thanks.

Below is the stack trace and some of my notes on this problem.  Hope
this helps.

I agree we should not use index operation abusively, but this is pretty
serious problem.  I don't think we can fix it easily without changing
the arch-independent part of kernel.

Jun

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

more traces :
the page fault is caused r4k_flush_icache_page_i32(), the first cache
(Hit_....) operation.

call stack when current->mm->sem has already been taken but
        r4k_flush_icache_page_i32() is still called.

#0  jsun_bug () at r4xx0.c:1971
#1  0x8009aa60 in r4k_flush_icache_page_i32 (vma=0x811401e0,
page=0x810476c0,
    address=263607008) at r4xx0.c:1986
#2  0x800b0320 in do_no_page (mm=0x81142080, vma=0x811401e0,
address=263607008,
    write_access=0, page_table=0x811fed94) at memory.c:1162
#3  0x800b0508 in handle_mm_fault (mm=0x81142080, vma=0x811401e0,
    address=263607008, write_access=0) at memory.c:1202
#4  0x80094118 in do_page_fault (regs=0x81127f30, write=0,
address=263607008)
    at fault.c:93
#5  0x8008ce98 in handle_tlbl () at r4k_misc.S:154

(263607008 = 0xfb652e0)

The epc for #5 tlbl fault is 0xfb652e0, which means it is a page fault
for
the next instruction.

****

annotated calling trace :

handle_tlbl (in asm) - arch/mips/kernel/r4k_misc.S
    do_page_fault - arch/mips/mm/fault.c
        after check it is a good area
        swtich (handle_mm_fault(....) )  - line 93
            [not visiable to gdb
            handle_mm_fault(...)  - mm/memory.c ]
                alloc pte
                handle_pte_fault(...)
                    check about the page and
                    do_no_page(...)  - mm/memory.c
                        /* do a bunch of stuff but TLB entry
			   for the new page is not built yet */
                        flush_page_to_ram(new_page);
                        flush_icache_page(...)
                          ( = r4k_flush_icache_page_i32) ;
                                ==> jsun_bug()

From owner-linux-mips@oss.sgi.com Fri Aug 11 00:55:21 2000
Received:  by oss.sgi.com id <S42212AbQHKHzL>;
	Fri, 11 Aug 2000 00:55:11 -0700
Received: from deliverator.sgi.com ([204.94.214.10]:5705 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S42202AbQHKHyk>;
	Fri, 11 Aug 2000 00:54:40 -0700
Received: from nodin.corp.sgi.com (nodin.corp.sgi.com [192.26.51.193]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id AAA16218
	for <linux-mips@oss.sgi.com>; Fri, 11 Aug 2000 00:46:35 -0700 (PDT)
	mail_from (shm@cthulhu.engr.sgi.com)
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by nodin.corp.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) via ESMTP id AAA07490 for <linux-mips@oss.sgi.com>; Fri, 11 Aug 2000 00:52:24 -0700 (PDT)
Received: from tantrik.engr.sgi.com (tantrik.engr.sgi.com [130.62.52.189])
	by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id AAA31668;
	Fri, 11 Aug 2000 00:50:52 -0700 (PDT)
	mail_from (shm@cthulhu.engr.sgi.com)
Received: from localhost (shm@localhost) by tantrik.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id AAA33097; Fri, 11 Aug 2000 00:50:52 -0700 (PDT)
Date:   Fri, 11 Aug 2000 00:50:51 -0700
From:   Shrijeet Mukherjee <shm@cthulhu.engr.sgi.com>
cc:     linux-fbdev@vuser.vu.union.edu,
        Linux porting team <linux@cthulhu.engr.sgi.com>
Subject: Re: [linux-fbdev] SGI VW 540, fbdev and pot pourii of faults and
 evidence..:-)
In-Reply-To: <Pine.SGI.4.10.10008091908170.26870-100000@tigger.ccs.ornl.gov>
Message-ID: <Pine.SGI.4.21.0008110042220.232700-100000@tantrik.engr.sgi.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
To:     unlisted-recipients:; (no To-header on input)
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing

On Wed, 9 Aug 2000 philloc@tigger.ccs.ornl.gov wrote:

>	Hi,
>> 
>> > I would also like to ask, if SGI is likely to make the hardware specs OSS
>> > (for cobalt etc.), so that those with the skill (this is not my forte, but
>> > I will try...), can stabilise this otherwise competent port.
>> 
>> Nope. SGI no longer supports Visual Workstations with linux. I don't even
>> know if they support Visual Workstatiosn period. It would be nice if they
>> did release the specs anyways :-)
>	They support it on WindozeNT etc... I was toying with the idea of 
>running VMware just to see what the X server will do under NT.
>

So just to make the statement sound right. SGI never officially supported
linux on the Visual Workstation 320. The current line of the Visual
Workstation family, the 230, 330 and 530 all do and will support highly
accelerated OpenGL under linux.

>
>	Anyone from SGI care to comment on why SGI has not released the
>specs to reasonable attention, since they are unable to help port? 
>
>As complex as the hardware is, the SGI guys did a pretty good job on the
>"hacks" they put in, so I am sure the specs would make it a breeze to port
>:-)
>

Actually a "port" is not that simple. The real problem for opening up the
driver port that we worked on, is that there are critical parts of SGI
driver mode IP in there that we are not ready to open source at this
point. Given that, the software is the best "spec" and documentation we
have at this point .. this is a real issue.

>> 
>> > 1. After boot , no matter what video mode one is in, the text console is
>> > zippy. After using X (or changing modes using fbset) the text scrolling is
>> > *painfully* slow. There is no apparent difference in the kernel mechanism
>> > when switching, so is it just the boot state that works?
>> 
>> Which X server?  Sounds like the X server is doing the naughty.
>	Oh not even X. X is fine in fact (with the exception it shivers
>and is tinted green in 32bit 1600x1200, and tinted green in 32bit 
>1280x1024 , but fine in 8-16bit for all modes).
>

I remember there being some issue about stuff being ABGR or some strange
format in some cases, which was screwing things up. Is this happening only
under WindowMaker or was it Enlightenment .. some window manager was
causing problems since it used X BLT's ..


>	The problems is: 
>
>	machine boots. Text scrolling fine, no matter what I set it to
>in the kernel (in 8bit colour that is. 16bit and I lose the fonts). If you
>then fbset to ANY mode (say 800x600x8), and then do "ls -l", it is very
>slow. Now I have stared at the kernel for a bit, and the only thing that
>strikes me, is that on boot the frambuffer is initialised etc.., and it is
>possible that the hardware is in some sort of "bios" mode, which plays
>nice with the framebuffer. After boot, we switch the mode etc... but
>something is not tripped, or the kernel/video uses a different set of
>routines.
>
>	I suppose I should ask, anyone else see this behaviour?
>
>> 
>> > 	Empirical observations (i.e. writing known patterns to the
>> > /dev/fb0 device) indicate that SGI reverse RGB for 888 format, compared to
>> > RGB565. That is red offset=0, green=8,blue=16 rather than red=24 etc.. I
>> > have reversed the assignment in the "var" structure (in sgivwfb_set_var )
>> > and in setcolreg the offsets are used, but to no effect. What else needs
>> > changing?
>> 

Hope this helps some. 

-- 
--------------------------------------------------------------------------
Shrijeet Mukherjee,    		        MTS Advanced Graphics, SGI
http://reality.sgi.com/shm_engr     	phone: 650-933-5312
email: shm@sgi.com, shrijeet@hotmail.com
--------------------------------------------------------------------------
Where there is a will, there is a way. If a way cannot be found, 
it is the will that is suspect ..                                   -- shm 


From owner-linux-mips@oss.sgi.com Fri Aug 11 18:51:11 2000
Received:  by oss.sgi.com id <S42202AbQHLBuv>;
	Fri, 11 Aug 2000 18:50:51 -0700
Received: from deliverator.sgi.com ([204.94.214.10]:2632 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S42199AbQHLBuc>;
	Fri, 11 Aug 2000 18:50:32 -0700
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id SAA07047
	for <linux-mips@oss.sgi.com>; Fri, 11 Aug 2000 18:42:56 -0700 (PDT)
	mail_from (aboyanic@gloose.scis.cowan.edu.au)
From:   aboyanic@gloose.scis.cowan.edu.au
Received: from sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id SAA76663
	for <linux@cthulhu.engr.sgi.com>;
	Fri, 11 Aug 2000 18:50:13 -0700 (PDT)
	mail_from (aboyanic@gloose.scis.cowan.edu.au)
Received: from gloose.scis.cowan.edu.au ([139.230.35.235]) 
	by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam:
       SGI does not authorize the use of its proprietary
       systems or networks for unsolicited or bulk email
       from the Internet.) 
	via ESMTP id SAA02871
	for <linux@cthulhu.engr.sgi.com>; Fri, 11 Aug 2000 18:49:47 -0700 (PDT)
	mail_from (aboyanic@gloose.scis.cowan.edu.au)
Received: from localhost (aboyanic@localhost)
	by gloose.scis.cowan.edu.au (8.9.3/8.9.3) with ESMTP id JAA04497
	for <linux@cthulhu.engr.sgi.com>; Sat, 12 Aug 2000 09:56:01 +0400
Date:   Sat, 12 Aug 2000 09:56:01 +0400 (MSD)
To:     linux@cthulhu.engr.sgi.com
Subject: Old Clunkers
Message-ID: <Pine.LNX.4.20.0008120950120.3024-100000@gloose.scis.cowan.edu.au>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing
Content-Length: 942
Lines: 19


Hi, I'm interested in looking into porting to some of the more antique
machines. I have recently aquired a Power 4D-210 with 256mb ram. The
machine still functions but no chance of an OS for it Irix 5.3. I'm
experianced at  linux & NetBSD porting to the Sun platform and this will
be my first attempt at anything with SGI hardware. I'm looking for
expressions of interest from other people out there that preferably have
access to anything from the Power 4D range still working and with a little
time to spare. If you have a broken machine and are still interested
please let me know and we can discuss techniques for getting it working.

To anyone reading this from SGI. Any chance of getting some of the bus
architecture, or any other specs on the older Power 4D systems? Apart 
from various web pages on the machines I am almost completely bumbling 
around in the dark.

Regs Alastair Boyanich
Edith Cowan University (Western Australia)


From owner-linux-mips@oss.sgi.com Sat Aug 12 19:48:34 2000
Received:  by oss.sgi.com id <S42243AbQHMCsY>;
	Sat, 12 Aug 2000 19:48:24 -0700
Received: from pneumatic-tube.sgi.com ([204.94.214.22]:54625 "EHLO
        pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP
	id <S42207AbQHMCsH>; Sat, 12 Aug 2000 19:48:07 -0700
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id TAA08993
	for <linux-mips@oss.sgi.com>; Sat, 12 Aug 2000 19:54:09 -0700 (PDT)
	mail_from (greatates@fasttrec.com)
From:   greatates@fasttrec.com
Received: from sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id TAA05203;
	Sat, 12 Aug 2000 19:47:47 -0700 (PDT)
	mail_from (greatates@fasttrec.com)
Received: from www.fasttrec.com (sdn-ar-002mnminnP271.dialsprint.net [206.133.127.73]) 
	by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam:
       SGI does not authorize the use of its proprietary
       systems or networks for unsolicited or bulk email
       from the Internet.) 
	via SMTP id TAA07226; Sat, 12 Aug 2000 19:47:44 -0700 (PDT)
	mail_from (greatates@fasttrec.com)
Subject: ADV: Great Rate Insurance!!
Date:   Sat, 12 Aug 2000 18:13:46
Message-Id: <301.752911.322545@www.fasttrec.com>
To:     unlisted-recipients:; (no To-header on input)
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing
Content-Length: 633
Lines: 25

To be removed from our mailing list, please visit
http://www.supersitescentral.com/bestrates/remove.html

Tired of Paying HIGH Prices for Term Insurance?
Find Out What Your Life Insurance Should Really Cost!

Visit http://www.supersitescentral.com/bestrates NOW!

We are a national brokerage tracking the prices of
top insurance companies in America.  We also
specialize in markets for all types of tobacco users
as well  as those who have medical impairments/
conditions.  You can lock in guaranteed low rates for
up to 30-years.

For more information visit http://www.supersitescentral.com/bestrates
without delay!
 
 
 
 
 
 
 
 

From owner-linux-mips@oss.sgi.com Sun Aug 13 08:17:55 2000
Received:  by oss.sgi.com id <S42228AbQHMPRf>;
	Sun, 13 Aug 2000 08:17:35 -0700
Received: from pneumatic-tube.sgi.com ([204.94.214.22]:2671 "EHLO
        pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP
	id <S42207AbQHMPR3>; Sun, 13 Aug 2000 08:17:29 -0700
Received: from cthulhu.engr.sgi.com (gate3-relay.engr.sgi.com [130.62.1.234]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id IAA06004
	for <linux-mips@oss.sgi.com>; Sun, 13 Aug 2000 08:23:34 -0700 (PDT)
	mail_from (alan@lxorguk.ukuu.org.uk)
Received: from sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id IAA49623
	for <linux@cthulhu.engr.sgi.com>;
	Sun, 13 Aug 2000 08:17:07 -0700 (PDT)
	mail_from (alan@lxorguk.ukuu.org.uk)
Received: from the-village.bc.nu (lightning.swansea.uk.linux.org [194.168.151.1]) 
	by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam:
       SGI does not authorize the use of its proprietary
       systems or networks for unsolicited or bulk email
       from the Internet.) 
	via ESMTP id IAA08644
	for <linux@cthulhu.engr.sgi.com>; Sun, 13 Aug 2000 08:17:00 -0700 (PDT)
	mail_from (alan@lxorguk.ukuu.org.uk)
Received: from alan by the-village.bc.nu with local (Exim 2.12 #1)
	id 13NzPH-0001bK-00; Sun, 13 Aug 2000 16:10:35 +0100
Subject: Re: [linux-fbdev] SGI VW 540, fbdev and pot pourii of faults and
To:     i15@ornl.gov
Date:   Sun, 13 Aug 2000 16:10:31 +0100 (BST)
Cc:     jsimmons@acsu.buffalo.edu (James Simmons),
        linux-fbdev@vuser.vu.union.edu, linux@cthulhu.engr.sgi.com
In-Reply-To: <Pine.SGI.4.10.10008091908170.26870-100000@tigger.ccs.ornl.gov> from "philloc@tigger.ccs.ornl.gov" at Aug 09, 2000 07:28:07 PM
X-Mailer: ELM [version 2.5 PL1]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <E13NzPH-0001bK-00@the-village.bc.nu>
From:   Alan Cox <alan@lxorguk.ukuu.org.uk>
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing
Content-Length: 499
Lines: 13

> 	Anyone from SGI care to comment on why SGI has not released the
> specs to reasonable attention, since they are unable to help port? 

Try getting the sources for the 3d driver and graphics components on their
current workstation.

> 	Hey as an aside, anyone know how to "uncompress" a "vmlinuz"
> kernel to a "vmlinux"? SGI had posted a kernel or 2 , but always in the
> "vmlinuz" format. To the best of my knowledge cannot be booted
> on the VW 540.

gzip -d <vmlinuz >vmlinux should be fine.


From owner-linux-mips@oss.sgi.com Mon Aug 14 03:02:16 2000
Received:  by oss.sgi.com id <S42290AbQHNKCG>;
	Mon, 14 Aug 2000 03:02:06 -0700
Received: from deliverator.sgi.com ([204.94.214.10]:54385 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S42271AbQHNKBp>;
	Mon, 14 Aug 2000 03:01:45 -0700
Received: from nodin.corp.sgi.com (nodin.corp.sgi.com [192.26.51.193]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id CAA17190
	for <linux-mips@oss.sgi.com>; Mon, 14 Aug 2000 02:54:10 -0700 (PDT)
	mail_from (tkwriter@vanc.igs.net)
From:   tkwriter@vanc.igs.net
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by nodin.corp.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) via ESMTP id DAA92714 for <linux-mips@oss.sgi.com>; Mon, 14 Aug 2000 03:01:14 -0700 (PDT)
Received: from sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id CAA73929;
	Mon, 14 Aug 2000 02:58:24 -0700 (PDT)
	mail_from (tkwriter@vanc.igs.net)
Received: from buddy.pacificcoast.net (buddy.pacificcoast.net [216.86.100.2]) 
	by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam:
       SGI does not authorize the use of its proprietary
       systems or networks for unsolicited or bulk email
       from the Internet.) 
	via ESMTP id CAA09340; Mon, 14 Aug 2000 02:58:23 -0700 (PDT)
	mail_from (tkwriter@vanc.igs.net)
Received: from pacificcoast.net (bct140-107.gen.pacificcoast.net [209.53.140.107])
	by buddy.pacificcoast.net (8.9.1a/8.9.1) with SMTP id BAA31993;
	Mon, 14 Aug 2000 01:43:44 -0700
Date:   Mon, 14 Aug 2000 01:43:44 -0700
Message-Id: <200008140843.BAA31993@buddy.pacificcoast.net>
Reply-To: tkwriter@vanc.igs.net
To:     tkwriter@vanc.igs.net
Subject: Documentation Specialist Seeking Contract Work
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing
Content-Length: 1573
Lines: 38

Documentation Specialists Seeking Contract Work - Technical Writing, 
graphics, Robohelp, HTML, SGML, etc. 

Senior technical writers, project leaders and electronic documentation 
specialists seek contract work. Clients have included companies such 
as Microsoft and Koch Petroleum. Excellent communication skills, able 
to work with all levels of the company from programmers to CEO.  
Excellent background in technical, marketing and creative writing.
Familiar with educational material as well as e-commerce.  
Writing samples, full resume and references available on request.

Experience in creating both published and online documentation.

REQUIRED:

Prefer Corp to Corp Sole relationship directly with the client. 
Agents are also welcome in the same capacity.

Production is done at our facility.  We are fully equipped. 

PLEASE REPLY ONLY BY PHONE
Contact - Casey Lea - 

TO INQUIRE ABOUT SERVICES, AVAILABILITY, OR TO CONFIRM REMOVAL FROM OUR LIST 
CALL 604-685-8348 PST

Rates: Fees are charged by the hour or by the project.  

-------------------
This message is sent in compliance of the new e-mail bill: SECTION 301. Per Section 301, Paragraph (a)(2)(C) of S. 1618, 

http://www.senate.gov/~murkowski/commercialemail/S771index.html___________________________________________________________
This Message was Composed by a user of Extractor Pro '98 Bulk E- Mail Software. If 
you wish to be removed from this advertiser's future mailings, please reply 
with the subject "Remove" and this software will automatically block you 
from their future mailings.



From owner-linux-mips@oss.sgi.com Mon Aug 14 04:41:36 2000
Received:  by oss.sgi.com id <S42289AbQHNLlQ>;
	Mon, 14 Aug 2000 04:41:16 -0700
Received: from delta.ds2.pg.gda.pl ([153.19.144.1]:53495 "EHLO
        delta.ds2.pg.gda.pl") by oss.sgi.com with ESMTP id <S42186AbQHNLkw>;
	Mon, 14 Aug 2000 04:40:52 -0700
Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id NAA17800;
	Mon, 14 Aug 2000 13:39:48 +0200 (MET DST)
Date:   Mon, 14 Aug 2000 13:39:47 +0200 (MET DST)
From:   "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
Reply-To: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To:     Ralf Baechle <ralf@uni-koblenz.de>,
        Harald Koerfgen <Harald.Koerfgen@home.ivm.de>
cc:     Craig P Prescott <prescott@phys.ufl.edu>, linux-mips@fnet.fr,
        linux-mips@oss.sgi.com
Subject: NTP support code updates
Message-ID: <Pine.GSO.3.96.1000814132107.7256R-100000@delta.ds2.pg.gda.pl>
Organization: Technical University of Gdansk
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing
Content-Length: 5912
Lines: 161

Hi,

 Wondering why my RTC's time drifts away when the NTP daemon is running I
discovered to my surprise that our NTP support code is still of 2.0
vintage and simply does not work.  As a result set_rtc_mmss() does not get
called at all.

 The following patch updates the relevant code for both MIPS and MIPS64
to match the rest of the kernel.  I've only tested the DEC path but
changes are straightforward and should work for all variations.

 [Hmm, now my dispersion changes between 1 and 0.1 -- the set_rtc_mmss() 
function resets the RTC's divider and as a result further timer interrupts
do not arrive exactly at the right time.  This probably cannot be avoided
(apart from by disabling set_rtc_mmss()) but the code needs to be updated
regardless.]

 Comments are welcomed, as usually.

  Maciej

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

diff -u --recursive --new-file linux-mips-2.4.0-test5-20000731.macro/arch/mips/baget/time.c linux-mips-2.4.0-test5-20000731/arch/mips/baget/time.c
--- linux-mips-2.4.0-test5-20000731.macro/arch/mips/baget/time.c	Tue Mar 28 04:26:01 2000
+++ linux-mips-2.4.0-test5-20000731/arch/mips/baget/time.c	Sat Aug 12 21:47:26 2000
@@ -76,21 +76,22 @@
 
 void do_gettimeofday(struct timeval *tv)
 {
-        unsigned long flags;
+	unsigned long flags;
 
-        save_and_cli(flags);
-        *tv = xtime;
-        restore_flags(flags);
+	save_and_cli(flags);
+	*tv = xtime;
+	restore_flags(flags);
 }
 
 void do_settimeofday(struct timeval *tv)
 {
-        unsigned long flags;
+	unsigned long flags;
   
-        save_and_cli(flags);
-        xtime = *tv;
-        time_state = TIME_BAD;
-        time_maxerror = MAXPHASE;
-        time_esterror = MAXPHASE;
-        restore_flags(flags);
-} 
+	save_and_cli(flags);
+	xtime = *tv;
+	time_adjust = 0;		/* stop active adjtime() */
+	time_status |= STA_UNSYNC;
+	time_maxerror = NTP_PHASE_LIMIT;
+	time_esterror = NTP_PHASE_LIMIT;
+	restore_flags(flags);
+}
diff -u --recursive --new-file linux-mips-2.4.0-test5-20000731.macro/arch/mips/dec/time.c linux-mips-2.4.0-test5-20000731/arch/mips/dec/time.c
--- linux-mips-2.4.0-test5-20000731.macro/arch/mips/dec/time.c	Wed Jul 12 04:25:56 2000
+++ linux-mips-2.4.0-test5-20000731/arch/mips/dec/time.c	Sat Aug 12 21:58:23 2000
@@ -187,6 +187,7 @@
 void do_settimeofday(struct timeval *tv)
 {
 	write_lock_irq(&xtime_lock);
+
 	/* This is revolting. We need to set the xtime.tv_usec
 	 * correctly. However, the value in this location is
 	 * is value at the last tick.
@@ -199,10 +200,13 @@
 		tv->tv_usec += 1000000;
 		tv->tv_sec--;
 	}
+
 	xtime = *tv;
-	time_state = TIME_BAD;
-	time_maxerror = MAXPHASE;
-	time_esterror = MAXPHASE;
+	time_adjust = 0;		/* stop active adjtime() */
+	time_status |= STA_UNSYNC;
+	time_maxerror = NTP_PHASE_LIMIT;
+	time_esterror = NTP_PHASE_LIMIT;
+
 	write_unlock_irq(&xtime_lock);
 }
 
@@ -307,13 +311,15 @@
 	 * called as close as possible to 500 ms before the new second starts.
 	 */
 	read_lock(&xtime_lock);
-	if (time_state != TIME_BAD && xtime.tv_sec > last_rtc_update + 660 &&
-	    xtime.tv_usec > 500000 - (tick >> 1) &&
-	    xtime.tv_usec < 500000 + (tick >> 1)) {
+	if ((time_status & STA_UNSYNC) == 0
+	    && xtime.tv_sec > last_rtc_update + 660
+	    && xtime.tv_usec >= 500000 - tick / 2
+	    && xtime.tv_usec <= 500000 + tick / 2) {
 		if (set_rtc_mmss(xtime.tv_sec) == 0)
 			last_rtc_update = xtime.tv_sec;
 		else
-			last_rtc_update = xtime.tv_sec - 600;	/* do it again in 60 s */
+			/* do it again in 60 s */
+			last_rtc_update = xtime.tv_sec - 600;
	}
 	/* As we return to user mode fire off the other CPU schedulers.. this is
 	   basically because we don't yet share IRQ's around. This message is
diff -u --recursive --new-file linux-mips-2.4.0-test5-20000731.macro/arch/mips/sgi/kernel/indy_timer.c linux-mips-2.4.0-test5-20000731/arch/mips/sgi/kernel/indy_timer.c
--- linux-mips-2.4.0-test5-20000731.macro/arch/mips/sgi/kernel/indy_timer.c	Tue Mar 28 04:26:13 2000
+++ linux-mips-2.4.0-test5-20000731/arch/mips/sgi/kernel/indy_timer.c	Sat Aug 12 21:25:13 2000
@@ -290,8 +290,9 @@
 {
 	write_lock_irq(&xtime_lock);
 	xtime = *tv;
-	time_state = TIME_BAD;
-	time_maxerror = MAXPHASE;
-	time_esterror = MAXPHASE;
+	time_adjust = 0;		/* stop active adjtime() */
+	time_status |= STA_UNSYNC;
+	time_maxerror = NTP_PHASE_LIMIT;
+	time_esterror = NTP_PHASE_LIMIT;
 	write_unlock_irq(&xtime_lock);
 }
diff -u --recursive --new-file linux-mips-2.4.0-test5-20000731.macro/arch/mips64/sgi-ip22/ip22-timer.c linux-mips-2.4.0-test5-20000731/arch/mips64/sgi-ip22/ip22-timer.c
--- linux-mips-2.4.0-test5-20000731.macro/arch/mips64/sgi-ip22/ip22-timer.c	Mon Mar 27 04:26:15 2000
+++ linux-mips-2.4.0-test5-20000731/arch/mips64/sgi-ip22/ip22-timer.c	Sat Aug 12 21:32:29 2000
@@ -288,8 +288,9 @@
 {
 	write_lock_irq(&xtime_lock);
 	xtime = *tv;
-	time_state = TIME_BAD;
-	time_maxerror = MAXPHASE;
-	time_esterror = MAXPHASE;
+	time_adjust = 0;		/* stop active adjtime() */
+	time_status |= STA_UNSYNC;
+	time_maxerror = NTP_PHASE_LIMIT;
+	time_esterror = NTP_PHASE_LIMIT;
 	write_unlock_irq(&xtime_lock);
 }
diff -u --recursive --new-file linux-mips-2.4.0-test5-20000731.macro/arch/mips64/sgi-ip27/ip27-timer.c linux-mips-2.4.0-test5-20000731/arch/mips64/sgi-ip27/ip27-timer.c
--- linux-mips-2.4.0-test5-20000731.macro/arch/mips64/sgi-ip27/ip27-timer.c	Thu Jul 13 04:26:16 2000
+++ linux-mips-2.4.0-test5-20000731/arch/mips64/sgi-ip27/ip27-timer.c	Sat Aug 12 21:33:21 2000
@@ -206,9 +206,9 @@
 
 	xtime = *tv;
 	time_adjust = 0;		/* stop active adjtime() */
-	time_state = TIME_BAD;
-	time_maxerror = MAXPHASE;
-	time_esterror = MAXPHASE;
+	time_status |= STA_UNSYNC;
+	time_maxerror = NTP_PHASE_LIMIT;
+	time_esterror = NTP_PHASE_LIMIT;
 	write_unlock_irq(&xtime_lock);
 }
 


From owner-linux-mips@oss.sgi.com Mon Aug 14 05:16:06 2000
Received:  by oss.sgi.com id <S42291AbQHNMP4>;
	Mon, 14 Aug 2000 05:15:56 -0700
Received: from delta.ds2.pg.gda.pl ([153.19.144.1]:2040 "EHLO
        delta.ds2.pg.gda.pl") by oss.sgi.com with ESMTP id <S42186AbQHNMPi>;
	Mon, 14 Aug 2000 05:15:38 -0700
Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id OAA18734;
	Mon, 14 Aug 2000 14:15:22 +0200 (MET DST)
Date:   Mon, 14 Aug 2000 14:15:21 +0200 (MET DST)
From:   "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
Reply-To: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To:     Ralf Baechle <ralf@uni-koblenz.de>,
        Harald Koerfgen <Harald.Koerfgen@home.ivm.de>
cc:     Craig P Prescott <prescott@phys.ufl.edu>, linux-mips@fnet.fr,
        linux-mips@oss.sgi.com
Subject: Non-contiguous memory support
Message-ID: <Pine.GSO.3.96.1000814133957.7256S-100000@delta.ds2.pg.gda.pl>
Organization: Technical University of Gdansk
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing
Content-Length: 33289
Lines: 1131

Hi,

 Following is a patch that provides support for non-contiguous memory. 
This is needed at least for MS02-based DECstations in mixed memory
configurations, where 24MB holes exist between 8MB memory modules.

 I decided to write it in a generic way, hence the code is common to all
MIPS platforms, removing tons of now unnecessary duplicate code.  It's
modelled after the E820 memory support for i386 and provides similar
functionality, i.e. platform-specific backends can obtain a memory map in
a system-dependent fashion and register it with the generic code.  Later,
the map may get either accepted or overridden by a command line providing
a series of "mem=<size>@<start>" statements.  The latter may be useful for
developers to avoid pulling away memory modules to get specific memory
configurations tested (e.g. low memory performance).

 The generic code registers the memory map in '/proc/iomem' just like it
happens for other platforms -- here is an example output from my machine:

$ cat /proc/iomem
00000000-067fffff : System RAM
  00040000-00298e7f : Kernel code
  002ac0a0-00344b0f : Kernel data
08000000-087fffff : System RAM
0a000000-0a7fffff : System RAM
0c000000-0c7fffff : System RAM

Eventually all memory-mapped resources should get registered there, but
this is something for a start. 

 The code from arc/memory.c to place the bootmem allocator bitmap in the
largest area available got removed.  The bitmap gets always placed right
above the kernel.  I don't really think it should really matter, but if it
did, I may add this code in a generic way (people interested in such
machines, please make comments).

 I removed orion/misc.c completely instead of rewriting it --
orion/setup.c contains everything the former did and more. 

 I tried to fix every system supported, but a few look weird -- they do
not provide prom_init(), thus I am not sure how they even can be started
by kernel/setup.c.  As a result their memory initialization code remains
intact (non-existent?).  That aside, the memory initialization should look
fairly sane now.  The DEC path was tested as usual -- others did not.  If
there are any specific questions about some part of the code, I am looking
forward to read them.

 Comments are welcomed, as usually.

  Maciej

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

diff -u --recursive --new-file linux-mips-2.4.0-test5-20000731.macro/arch/mips/arc/cmdline.c linux-mips-2.4.0-test5-20000731/arch/mips/arc/cmdline.c
--- linux-mips-2.4.0-test5-20000731.macro/arch/mips/arc/cmdline.c	Tue Mar 28 04:26:00 2000
+++ linux-mips-2.4.0-test5-20000731/arch/mips/arc/cmdline.c	Sun Aug 13 12:14:21 2000
@@ -14,7 +14,7 @@
 
 /* #define DEBUG_CMDLINE */
 
-char arcs_cmdline[CL_SIZE];
+char arcs_cmdline[COMMAND_LINE_SIZE];
 
 char * __init prom_getcmdline(void)
 {
diff -u --recursive --new-file linux-mips-2.4.0-test5-20000731.macro/arch/mips/arc/memory.c linux-mips-2.4.0-test5-20000731/arch/mips/arc/memory.c
--- linux-mips-2.4.0-test5-20000731.macro/arch/mips/arc/memory.c	Wed Jul  5 04:25:46 2000
+++ linux-mips-2.4.0-test5-20000731/arch/mips/arc/memory.c	Sun Aug 13 20:37:39 2000
@@ -47,31 +47,25 @@
 	"LoadedProgram",
 	"FirmwareTemporary",
 	"FirmwarePermanent",
-	"FreeContigiuous"
+	"FreeContiguous"
 };
 #define mtypes(a) (prom_flags & PROM_FLAG_ARCS) ? arcs_mtypes[a.arcs] : arc_mtypes[a.arc]
 #endif
 
-static struct prom_pmemblock pblocks[PROM_MAX_PMEMBLOCKS];
-
-#define MEMTYPE_DONTUSE   0
-#define MEMTYPE_PROM      1
-#define MEMTYPE_FREE      2
-
 static inline int memtype_classify_arcs (union linux_memtypes type)
 {
 	switch (type.arcs) {
 	case arcs_fcontig:
 	case arcs_free:
-		return MEMTYPE_FREE;
+		return BOOT_MEM_RAM;
 	case arcs_atmp:
-		return MEMTYPE_PROM;
+		return BOOT_MEM_ROM_DATA;
 	case arcs_eblock:
 	case arcs_rvpage:
 	case arcs_bmem:
 	case arcs_prog:
 	case arcs_aperm:
-		return MEMTYPE_DONTUSE;
+		return BOOT_MEM_RESERVED;
 	default:
 		BUG();
 	}
@@ -83,15 +77,15 @@
 	switch (type.arc) {
 	case arc_free:
 	case arc_fcontig:
-		return MEMTYPE_FREE;
+		return BOOT_MEM_RAM;
 	case arc_atmp:
-		return MEMTYPE_PROM;
+		return BOOT_MEM_ROM_DATA;
 	case arc_eblock:
 	case arc_rvpage:
 	case arc_bmem:
 	case arc_prog:
 	case arc_aperm:
-		return MEMTYPE_DONTUSE;
+		return BOOT_MEM_RESERVED;
 	default:
 		BUG();
 	}
@@ -106,50 +100,13 @@
 	return memtype_classify_arc(type);
 }
 
-static inline unsigned long find_max_low_pfn(void)
-{
-	struct prom_pmemblock *p, *highest;
-	unsigned long pfn;
-
-	p = pblocks;
-	highest = 0;
-	while (p->size != 0) {
-		if (!highest || p->base > highest->base)
-			highest = p;
-		p++;
-	}
-
-	pfn = (highest->base + highest->size) >> PAGE_SHIFT;
-#ifdef DEBUG
-	prom_printf("find_max_low_pfn: 0x%lx pfns.\n", pfn);
-#endif
-	return pfn;
-}
-
-static inline struct prom_pmemblock *find_largest_memblock(void)
-{
-	struct prom_pmemblock *p, *largest;
-
-	p = pblocks;
-	largest = 0;
-	while (p->size != 0) {
-		if (!largest || p->size > largest->size)
-			largest = p;
-		p++;
-	}
-
-	return largest;
-}
-
 void __init prom_meminit(void)
 {
-	struct prom_pmemblock *largest;
-	unsigned long bootmap_size;
 	struct linux_mdesc *p;
-	int totram;
-	int i = 0;
 
 #ifdef DEBUG
+	int i = 0;
+
 	prom_printf("ARCS MEMORY DESCRIPTOR dump:\n");
 	p = ArcGetMemoryDescriptor(PROM_NULL_MDESC);
 	while(p) {
@@ -160,77 +117,37 @@
 	}
 #endif
 
-	totram = 0;
-	i = 0;
 	p = PROM_NULL_MDESC;
 	while ((p = ArcGetMemoryDescriptor(p))) {
-		pblocks[i].type = prom_memtype_classify(p->type);
-		pblocks[i].base = p->base << PAGE_SHIFT;
-		pblocks[i].size = p->pages << PAGE_SHIFT;
-
-		switch (pblocks[i].type) {
-		case MEMTYPE_FREE:
-			totram += pblocks[i].size;
-#ifdef DEBUG
-			prom_printf("free_chunk[%d]: base=%08lx size=%x\n",
-				    i, pblocks[i].base,
-				    pblocks[i].size);
-#endif
-			i++;
-			break;
-		case MEMTYPE_PROM:
-#ifdef DEBUG
-			prom_printf("prom_chunk[%d]: base=%08lx size=%x\n",
-				    i, pblocks[i].base,
-				    pblocks[i].size);
-#endif
-			i++;
-			break;
-		default:
-			break;
-		}
-	}
-	pblocks[i].size = 0;
-
-	max_low_pfn = find_max_low_pfn();
-
-	largest = find_largest_memblock();
-	bootmap_size = init_bootmem(largest->base >> PAGE_SHIFT, max_low_pfn);
+		unsigned long base, size;
+		long type;
 
-	for (i = 0; pblocks[i].size; i++)
-		if (pblocks[i].type == MEMTYPE_FREE)
-			free_bootmem(pblocks[i].base, pblocks[i].size);
+		base = __pa(p->base << PAGE_SHIFT);	/* Fix up from KSEG0 */
+		size = p->pages << PAGE_SHIFT;
+		type = prom_memtype_classify(p->type);
 
-	/* This test is simpleminded.  It will fail if the bootmem bitmap
-	   falls into multiple adjacent ARC memory areas.  */
-	if (bootmap_size > largest->size) {
-		prom_printf("CRITIAL: overwriting PROM data.\n");
-		BUG();
+		add_memory_region(base, pages, type);
 	}
-
-	/* Reserve the memory bootmap itself */
-	reserve_bootmem(largest->base, bootmap_size);
-
-	printk("PROMLIB: Total free ram %dK / %dMB.\n",
-	       totram >> 10, totram >> 20);
 }
 
 void __init
 prom_free_prom_memory (void)
 {
+	int i;
 	struct prom_pmemblock *p;
 	unsigned long freed = 0;
 	unsigned long addr;
 
-	for (p = pblocks; p->size != 0; p++) {
-		if (p->type != MEMTYPE_PROM)
+	for (i = 0; i < boot_mem_map.nr_map; i++) {
+		if (boot_mem_map.map[i].type != BOOT_MEM_ROM_DATA)
 			continue;
 
-		addr = PAGE_OFFSET + p->base;
-		while (addr < p->base + p->size) {
-			ClearPageReserved(mem_map + MAP_NR(addr));
-			set_page_count(mem_map + MAP_NR(addr), 1);
-			free_page(addr);
+		addr = boot_mem_map.map[i].addr;
+		while (addr < boot_mem_map.map[i].addr
+			      + boot_mem_map.map[i].size) {
+			ClearPageReserved(mem_map + MAP_NR(__va(addr)));
+			set_page_count(mem_map + MAP_NR(__va(addr)), 1);
+			free_page(__va(addr));
 			addr += PAGE_SIZE;
 			freed += PAGE_SIZE;
 		}
diff -u --recursive --new-file linux-mips-2.4.0-test5-20000731.macro/arch/mips/baget/prom/init.c linux-mips-2.4.0-test5-20000731/arch/mips/baget/prom/init.c
--- linux-mips-2.4.0-test5-20000731.macro/arch/mips/baget/prom/init.c	Tue Mar 28 04:26:02 2000
+++ linux-mips-2.4.0-test5-20000731/arch/mips/baget/prom/init.c	Sun Aug 13 20:24:28 2000
@@ -8,7 +8,7 @@
 #include <linux/init.h>
 #include <asm/bootinfo.h>
 
-char arcs_cmdline[CL_SIZE];
+char arcs_cmdline[COMMAND_LINE_SIZE];
 
 int __init prom_init(unsigned int mem_upper)
 {
@@ -17,10 +17,6 @@
 	mips_machtype   = MACH_UNKNOWN;
 	arcs_cmdline[0] = 0;
 	return 0;
-}
-
-void __init prom_fixup_mem_map(unsigned long start, unsigned long end)
-{
 }
 
 void prom_free_prom_memory (void)
diff -u --recursive --new-file linux-mips-2.4.0-test5-20000731.macro/arch/mips/ddb5074/prom.c linux-mips-2.4.0-test5-20000731/arch/mips/ddb5074/prom.c
--- linux-mips-2.4.0-test5-20000731.macro/arch/mips/ddb5074/prom.c	Thu May 11 04:26:44 2000
+++ linux-mips-2.4.0-test5-20000731/arch/mips/ddb5074/prom.c	Sun Aug 13 20:24:58 2000
@@ -15,18 +15,11 @@
 #include <asm/bootinfo.h>
 
 
-char arcs_cmdline[CL_SIZE];
-
-extern char _end;
-
-#define PFN_UP(x)	(((x) + PAGE_SIZE-1) >> PAGE_SHIFT)
-#define PFN_ALIGN(x)	(((unsigned long)(x) + (PAGE_SIZE - 1)) & PAGE_MASK)
-
+char arcs_cmdline[COMMAND_LINE_SIZE];
 
 void __init prom_init(const char *s)
 {
     int i = 0;
-    unsigned long mem_size, free_start, free_end, start_pfn, bootmap_size;
 
 //  _serinit();
 
@@ -37,24 +30,9 @@
 
     mips_machgroup = MACH_GROUP_NEC_DDB;
     mips_machtype = MACH_NEC_DDB5074;
-    /* 64 MB non-upgradable */
-    mem_size = 64 << 20;
-
-    free_start = PHYSADDR(PFN_ALIGN(&_end));
-    free_end = mem_size;
-    start_pfn = PFN_UP((unsigned long)&_end);
 
-    /* Register all the contiguous memory with the bootmem allocator
-       and free it.  Be careful about the bootmem freemap.  */
-    bootmap_size = init_bootmem(start_pfn, mem_size >> PAGE_SHIFT);
-
-    /* Free the entire available memory after the _end symbol.  */
-    free_start += bootmap_size;
-    free_bootmem(free_start, free_end-free_start);
-}
-
-void __init prom_fixup_mem_map(unsigned long start, unsigned long end)
-{
+    /* 64 MB non-upgradable */
+    add_memory_region(0, 64 << 20, BOOT_MEM_RAM);
 }
 
 void __init prom_free_prom_memory(void)
diff -u --recursive --new-file linux-mips-2.4.0-test5-20000731.macro/arch/mips/ddb5074/setup.c linux-mips-2.4.0-test5-20000731/arch/mips/ddb5074/setup.c
--- linux-mips-2.4.0-test5-20000731.macro/arch/mips/ddb5074/setup.c	Wed Jun 21 04:26:38 2000
+++ linux-mips-2.4.0-test5-20000731/arch/mips/ddb5074/setup.c	Sun Aug 13 18:40:51 2000
@@ -118,11 +118,6 @@
     panic_timeout = 180;
 }
 
-int __init page_is_ram(unsigned long pagenr)
-{
-    return 1;
-}
-
 
 #define USE_NILE4_SERIAL	0
 
diff -u --recursive --new-file linux-mips-2.4.0-test5-20000731.macro/arch/mips/dec/prom/cmdline.c linux-mips-2.4.0-test5-20000731/arch/mips/dec/prom/cmdline.c
--- linux-mips-2.4.0-test5-20000731.macro/arch/mips/dec/prom/cmdline.c	Tue Mar 28 04:26:06 2000
+++ linux-mips-2.4.0-test5-20000731/arch/mips/dec/prom/cmdline.c	Sun Aug 13 16:54:47 2000
@@ -19,7 +19,7 @@
 extern int (*prom_printf)(char *, ...);
 #endif
 
-char arcs_cmdline[CL_SIZE];
+char arcs_cmdline[COMMAND_LINE_SIZE];
 
 void __init prom_init_cmdline(int argc, char **argv, unsigned long magic)
 {
diff -u --recursive --new-file linux-mips-2.4.0-test5-20000731.macro/arch/mips/dec/prom/memory.c linux-mips-2.4.0-test5-20000731/arch/mips/dec/prom/memory.c
--- linux-mips-2.4.0-test5-20000731.macro/arch/mips/dec/prom/memory.c	Mon Jul 10 04:26:02 2000
+++ linux-mips-2.4.0-test5-20000731/arch/mips/dec/prom/memory.c	Sun Aug 13 20:49:47 2000
@@ -2,6 +2,7 @@
  * memory.c: memory initialisation code.
  *
  * Copyright (C) 1998 Harald Koerfgen, Frieder Streffer and Paul M. Antoine
+ * Copyright (C) 2000 Maciej W. Rozycki
  *
  * $Id: memory.c,v 1.3 1999/10/09 00:00:58 ralf Exp $
  */
@@ -14,6 +15,8 @@
 #include <asm/addrspace.h>
 #include <asm/page.h>
 
+#include <asm/bootinfo.h>
+
 #include <asm/dec/machtype.h>
 
 #include "prom.h"
@@ -33,11 +36,6 @@
 
 volatile unsigned long mem_err = 0;	/* So we know an error occured */
 
-extern char _end;
-
-#define PFN_UP(x)	(((x) + PAGE_SIZE-1) >> PAGE_SHIFT)
-#define PFN_ALIGN(x)	(((unsigned long)(x) + (PAGE_SIZE - 1)) & PAGE_MASK)
-
 /*
  * Probe memory in 4MB chunks, waiting for an error to tell us we've fallen
  * off the end of real memory.  Only suitable for the 2100/3100's (PMAX).
@@ -45,7 +43,7 @@
 
 #define CHUNK_SIZE 0x400000
 
-unsigned long __init pmax_get_memory_size(void)
+static void __init pmax_setup_memory_region(void)
 {
 	volatile unsigned char *memory_page, dummy;
 	char	old_handler[0x80];
@@ -66,17 +64,19 @@
 		dummy = *memory_page;
 	}
 	memcpy((void *)(KSEG0 + 0x80), &old_handler, 0x80);
-	return (unsigned long)memory_page - KSEG1 - CHUNK_SIZE;
+
+	add_memory_region(0, (unsigned long)memory_page - KSEG1 - CHUNK_SIZE,
+			  BOOT_MEM_RAM);
 }
 
 /*
  * Use the REX prom calls to get hold of the memory bitmap, and thence
  * determine memory size.
  */
-unsigned long __init rex_get_memory_size(void)
+static void __init rex_setup_memory_region(void)
 {
 	int i, bitmap_size;
-	unsigned long mem_size = 0;
+	unsigned long mem_start = 0, mem_size = 0;
 	memmap *bm;
 
 	/* some free 64k */
@@ -88,40 +88,24 @@
 		/* FIXME: very simplistically only add full sets of pages */
 		if (bm->bitmap[i] == 0xff)
 			mem_size += (8 * bm->pagesize);
+		else if (!mem_size)
+			mem_start += (8 * bm->pagesize);
+		else {
+			add_memory_region(mem_start, mem_size, BOOT_MEM_RAM);
+			mem_start += mem_size + (8 * bm->pagesize);
+			mem_size = 0;
+		}
 	}
-
-	return (mem_size);
+	if (mem_size)
+		add_memory_region(mem_start, mem_size, BOOT_MEM_RAM);
 }
 
 void __init prom_meminit(unsigned int magic)
 {
-	unsigned long free_start, free_end, start_pfn, bootmap_size;
-	unsigned long mem_size = 0;
-
 	if (magic != REX_PROM_MAGIC)
-		mem_size = pmax_get_memory_size();
+		pmax_setup_memory_region();
 	else
-		mem_size = rex_get_memory_size();
-
-	free_start = PHYSADDR(PFN_ALIGN(&_end));
-	free_end = mem_size;
-	start_pfn = PFN_UP((unsigned long)&_end);
-
-#ifdef PROM_DEBUG
-	prom_printf("free_start: 0x%08x\n", free_start);
-	prom_printf("free_end: 0x%08x\n", free_end);
-	prom_printf("start_pfn: 0x%08x\n", start_pfn);
-#endif
-
-	/* Register all the contiguous memory with the bootmem allocator
-	   and free it.  Be careful about the bootmem freemap.  */
-	bootmap_size = init_bootmem(start_pfn, mem_size >> PAGE_SHIFT);
-	free_bootmem(free_start + bootmap_size, free_end - free_start - bootmap_size);
-}
-
-int __init page_is_ram(unsigned long pagenr)
-{
-        return 1;
+		rex_setup_memory_region();
 }
 
 void prom_free_prom_memory (void)
diff -u --recursive --new-file linux-mips-2.4.0-test5-20000731.macro/arch/mips/jazz/setup.c linux-mips-2.4.0-test5-20000731/arch/mips/jazz/setup.c
--- linux-mips-2.4.0-test5-20000731.macro/arch/mips/jazz/setup.c	Tue Mar 28 04:26:07 2000
+++ linux-mips-2.4.0-test5-20000731/arch/mips/jazz/setup.c	Sun Aug 13 18:42:14 2000
@@ -80,11 +80,6 @@
 	i8259_setup_irq(2, &irq2);
 }
 
-int __init page_is_ram(unsigned long pagenr)
-{
-	return 1;
-}
-
 void __init jazz_setup(void)
 {
 	add_wired_entry (0x02000017, 0x03c00017, 0xe0000000, PM_64K);
diff -u --recursive --new-file linux-mips-2.4.0-test5-20000731.macro/arch/mips/kernel/Makefile linux-mips-2.4.0-test5-20000731/arch/mips/kernel/Makefile
--- linux-mips-2.4.0-test5-20000731.macro/arch/mips/kernel/Makefile	Tue Jul 11 04:26:06 2000
+++ linux-mips-2.4.0-test5-20000731/arch/mips/kernel/Makefile	Sun Aug 13 12:23:32 2000
@@ -6,8 +6,10 @@
 # unless it's something special (ie not a .c file).
 #
 
+.S.s:
+	$(CPP) $(AFLAGS) $< -o $*.o
 .S.o:
-	$(CC) $(CFLAGS) -c $< -o $*.o
+	$(CC) $(AFLAGS) -c $< -o $*.o
 
 all:	kernel.o head.o init_task.o
 EXTRA_ASFLAGS = -mips3 -mcpu=r4000
diff -u --recursive --new-file linux-mips-2.4.0-test5-20000731.macro/arch/mips/kernel/setup.c linux-mips-2.4.0-test5-20000731/arch/mips/kernel/setup.c
--- linux-mips-2.4.0-test5-20000731.macro/arch/mips/kernel/setup.c	Tue Jul 11 04:26:06 2000
+++ linux-mips-2.4.0-test5-20000731/arch/mips/kernel/setup.c	Sun Aug 13 20:48:28 2000
@@ -6,6 +6,7 @@
  * Copyright (C) 1995  Linus Torvalds
  * Copyright (C) 1995, 1996, 1997, 1998  Ralf Baechle
  * Copyright (C) 1996  Stoned Elipot
+ * Copyright (C) 2000  Maciej W. Rozycki
  */
 #include <linux/config.h>
 #include <linux/errno.h>
@@ -99,12 +100,14 @@
 unsigned long mips_machtype = MACH_UNKNOWN;
 unsigned long mips_machgroup = MACH_GROUP_UNKNOWN;
 
+struct boot_mem_map boot_mem_map;
+
 unsigned char aux_device_present;
-extern int _end;
+extern char _ftext, _etext, _fdata, _edata, _end;
 
-static char command_line[CL_SIZE] = { 0, };
-       char saved_command_line[CL_SIZE];
-extern char arcs_cmdline[CL_SIZE];
+static char command_line[COMMAND_LINE_SIZE];
+       char saved_command_line[COMMAND_LINE_SIZE];
+extern char arcs_cmdline[COMMAND_LINE_SIZE];
 
 /*
  * The board specific setup routine sets irq_setup to point to a board
@@ -130,6 +133,9 @@
 extern asmlinkage void start_kernel(void);
 extern int prom_init(int, char **, char **, int *);
 
+static struct resource code_resource = { "Kernel code" };
+static struct resource data_resource = { "Kernel data" };
+
 /*
  * Probe whether cpu has config register by trying to play with
  * alternate cache bit and see whether it matters.
@@ -251,6 +257,97 @@
 	panic("Unknown machtype in init_IRQ");
 }
 
+void __init add_memory_region(unsigned long start, unsigned long size,
+			      long type)
+{
+	int x = boot_mem_map.nr_map;
+
+	if (x == BOOT_MEM_MAP_MAX) {
+		printk("Ooops! Too many entries in the memory map!\n");
+		return;
+	}
+
+	boot_mem_map.map[x].addr = start;
+	boot_mem_map.map[x].size = size;
+	boot_mem_map.map[x].type = type;
+	boot_mem_map.nr_map++;
+}
+
+static void __init print_memory_map(void)
+{
+	int i;
+
+	for (i = 0; i < boot_mem_map.nr_map; i++) {
+		printk(" memory: %08lx @ %08lx ",
+			boot_mem_map.map[i].size, boot_mem_map.map[i].addr);
+		switch (boot_mem_map.map[i].type) {
+		case BOOT_MEM_RAM:
+			printk("(usable)\n");
+			break;
+		case BOOT_MEM_ROM_DATA:
+			printk("(ROM data)\n");
+			break;
+		case BOOT_MEM_RESERVED:
+			printk("(reserved)\n");
+			break;
+		default:
+			printk("type %lu\n", boot_mem_map.map[i].type);
+			break;
+		}
+	}
+}
+
+static inline void parse_mem_cmdline(void)
+{
+	char c = ' ', *to = command_line, *from = saved_command_line;
+	unsigned long start_at, mem_size;
+	int len = 0;
+	int usermem = 0;
+
+	printk("Determined physical RAM map:\n");
+	print_memory_map();
+
+	for (;;) {
+		/*
+		 * "mem=XXX[kKmM]" defines a memory region from
+		 * 0 to <XXX>, overriding the determined size.
+		 * "mem=XXX[KkmM]@YYY[KkmM]" defines a memory region from
+		 * <YYY> to <YYY>+<XXX>, overriding the determined size.
+		 */
+		if (c == ' ' && !memcmp(from, "mem=", 4)) {
+			if (to != command_line)
+				to--;
+			/*
+			 * If a user specifies memory size, we
+			 * blow away any automatically generated
+			 * size.
+			 */
+			if (usermem == 0) {
+				boot_mem_map.nr_map = 0;
+				usermem = 1;
+			}
+			mem_size = memparse(from + 4, &from);
+			if (*from == '@')
+				start_at = memparse(from + 1, &from);
+			else
+				start_at = 0;
+			add_memory_region(start_at, mem_size, BOOT_MEM_RAM);
+		}
+		c = *(from++);
+		if (!c)
+			break;
+		if (COMMAND_LINE_SIZE <= ++len)
+			break;
+		*(to++) = c;
+	}
+	*to = '\0';
+
+	if (usermem) {
+		printk("User-defined physical RAM map:\n");
+		print_memory_map();
+	}
+}
+
 void __init setup_arch(char **cmdline_p)
 {
 	void baget_setup(void);
@@ -263,6 +360,10 @@
 	void ddb_setup(void);
 	void orion_setup(void);
 
+	unsigned long bootmap_size;
+	unsigned long start_pfn, max_pfn;
+	int i;
+
 	/* Save defaults for configuration-dependent routines.  */
 	irq_setup = default_irq_setup;
 
@@ -327,12 +428,88 @@
 		panic("Unsupported architecture");
 	}
 
-        strncpy (command_line, arcs_cmdline, CL_SIZE);
-	memcpy(saved_command_line, command_line, CL_SIZE);
-	saved_command_line[CL_SIZE-1] = '\0';
-
+	strncpy(command_line, arcs_cmdline, sizeof command_line);
+	command_line[sizeof command_line - 1] = 0;
+	strcpy(saved_command_line, command_line);
 	*cmdline_p = command_line;
 
+	parse_mem_cmdline();
+
+#define PFN_UP(x)	(((x) + PAGE_SIZE - 1) >> PAGE_SHIFT)
+#define PFN_DOWN(x)	((x) >> PAGE_SHIFT)
+#define PFN_PHYS(x)	((x) << PAGE_SHIFT)
+
+	/*
+	 * Partially used pages are not usable - thus
+	 * we are rounding upwards.
+	 */
+	start_pfn = PFN_UP(__pa(&_end));
+
+	/* Find the highest page frame number we have available.  */
+	max_pfn = 0;
+	for (i = 0; i < boot_mem_map.nr_map; i++) {
+		unsigned long start, end;
+
+		if (boot_mem_map.map[i].type != BOOT_MEM_RAM)
+			continue;
+
+		start = PFN_UP(boot_mem_map.map[i].addr);
+		end = PFN_DOWN(boot_mem_map.map[i].addr
+		      + boot_mem_map.map[i].size);
+
+		if (start >= end)
+			continue;
+		if (end > max_pfn)
+			max_pfn = end;
+	}
+
+	/* Initialize the boot-time allocator.  */
+	bootmap_size = init_bootmem(start_pfn, max_pfn);
+
+	/*
+	 * Register fully available low RAM pages with the bootmem allocator.
+	 */
+	for (i = 0; i < boot_mem_map.nr_map; i++) {
+		unsigned long curr_pfn, last_pfn, size;
+
+		/*
+		 * Reserve usable memory.
+		 */
+		if (boot_mem_map.map[i].type != BOOT_MEM_RAM)
+			continue;
+
+		/*
+		 * We are rounding up the start address of usable memory:
+		 */
+		curr_pfn = PFN_UP(boot_mem_map.map[i].addr);
+		if (curr_pfn >= max_pfn)
+			continue;
+		if (curr_pfn < start_pfn)
+			curr_pfn = start_pfn;
+
+		/*
+		 * ... and at the end of the usable range downwards:
+		 */
+		last_pfn = PFN_DOWN(boot_mem_map.map[i].addr
+				    + boot_mem_map.map[i].size);
+
+		if (last_pfn > max_pfn)
+			last_pfn = max_pfn;
+
+		/*
+		 * ... finally, did all the rounding and playing
+		 * around just make the area go away?
+		 */
+		if (last_pfn <= curr_pfn)
+			continue;
+
+		size = last_pfn - curr_pfn;
+		free_bootmem(PFN_PHYS(curr_pfn), PFN_PHYS(size));
+	}
+
+	/* Reserve the bootmap memory.  */
+	reserve_bootmem(PFN_PHYS(start_pfn), bootmap_size);
+
 #ifdef CONFIG_BLK_DEV_INITRD
 #error "Fixme, I'm broken."
 	tmp = (((unsigned long)&_end + PAGE_SIZE-1) & PAGE_MASK) - 8;
@@ -354,6 +531,41 @@
 #endif
 
 	paging_init();
+
+	code_resource.start = virt_to_bus(&_ftext);
+	code_resource.end = virt_to_bus(&_etext) - 1;
+	data_resource.start = virt_to_bus(&_fdata);
+	data_resource.end = virt_to_bus(&_edata) - 1;
+
+	/*
+	 * Request address space for all standard RAM.
+	 */
+	for (i = 0; i < boot_mem_map.nr_map; i++) {
+		struct resource *res;
+
+		res = alloc_bootmem(sizeof(struct resource));
+		switch (boot_mem_map.map[i].type) {
+		case BOOT_MEM_RAM:
+		case BOOT_MEM_ROM_DATA:
+			res->name = "System RAM";
+			break;
+		case BOOT_MEM_RESERVED:
+		default:
+			res->name = "reserved";
+		}
+		res->start = boot_mem_map.map[i].addr;
+		res->end = res->start + boot_mem_map.map[i].size - 1;
+		res->flags = IORESOURCE_MEM | IORESOURCE_BUSY;
+		request_resource(&iomem_resource, res);
+
+		/*
+		 *  We dont'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);
+	}
 }
 
 void r3081_wait(void) 
diff -u --recursive --new-file linux-mips-2.4.0-test5-20000731.macro/arch/mips/mm/init.c linux-mips-2.4.0-test5-20000731/arch/mips/mm/init.c
--- linux-mips-2.4.0-test5-20000731.macro/arch/mips/mm/init.c	Mon Jul  3 04:25:56 2000
+++ linux-mips-2.4.0-test5-20000731/arch/mips/mm/init.c	Sun Aug 13 20:25:18 2000
@@ -41,7 +41,6 @@
 
 static unsigned long totalram_pages = 0;
 
-extern void prom_fixup_mem_map(unsigned long start, unsigned long end);
 extern void prom_free_prom_memory(void);
 
 
@@ -270,7 +269,30 @@
 	free_area_init(zones_size);
 }
 
-extern int page_is_ram(unsigned long pagenr);
+#define PFN_UP(x)	(((x) + PAGE_SIZE - 1) >> PAGE_SHIFT)
+#define PFN_DOWN(x)	((x) >> PAGE_SHIFT)
+
+static inline int page_is_ram(unsigned long pagenr)
+{
+	int i;
+
+	for (i = 0; i < boot_mem_map.nr_map; i++) {
+		unsigned long addr, end;
+
+		if (boot_mem_map.map[i].type != BOOT_MEM_RAM)
+			/* not usable memory */
+			continue;
+
+		addr = PFN_UP(boot_mem_map.map[i].addr);
+		end = PFN_DOWN(boot_mem_map.map[i].addr
+			       + boot_mem_map.map[i].size);
+
+		if (pagenr >= addr && pagenr < end)
+			return 1;
+	}
+
+	return 0;
+}
 
 void __init mem_init(void)
 {
diff -u --recursive --new-file linux-mips-2.4.0-test5-20000731.macro/arch/mips/orion/misc.c linux-mips-2.4.0-test5-20000731/arch/mips/orion/misc.c
--- linux-mips-2.4.0-test5-20000731.macro/arch/mips/orion/misc.c	Tue Jul 11 04:26:06 2000
+++ linux-mips-2.4.0-test5-20000731/arch/mips/orion/misc.c	Thu Jan  1 00:00:00 1970
@@ -1,102 +0,0 @@
-/*
- * Catch-all for Orion-specify code that doesn't fit easily elsewhere.
- *   -- Cort
- */
-
-#include <linux/config.h>
-#include <linux/errno.h>
-#include <linux/hdreg.h>
-#include <linux/init.h>
-#include <linux/ioport.h>
-#include <linux/sched.h>
-#include <linux/kernel.h>
-#include <linux/mm.h>
-#include <linux/stddef.h>
-#include <linux/string.h>
-#include <linux/unistd.h>
-#include <linux/ptrace.h>
-#include <linux/malloc.h>
-#include <linux/user.h>
-#include <linux/utsname.h>
-#include <linux/a.out.h>
-#include <linux/tty.h>
-#ifdef CONFIG_BLK_DEV_RAM
-#include <linux/blk.h>
-#endif
-#include <linux/ide.h>
-#ifdef CONFIG_RTC
-#include <linux/timex.h>
-#endif
-
-#include <asm/asm.h>
-#include <asm/bootinfo.h>
-#include <asm/cachectl.h>
-#include <asm/io.h>
-#include <asm/stackframe.h>
-#include <asm/system.h>
-#include <asm/cpu.h>
-#include <linux/sched.h>
-#include <linux/bootmem.h>
-#include <asm/addrspace.h>
-#include <asm/bootinfo.h>
-#include <asm/mc146818rtc.h>
-
-char arcs_cmdline[CL_SIZE] = {0, };
-extern int _end;
-
-static unsigned char orion_rtc_read_data(unsigned long addr)
-{
-	return 0;
-}
-
-static void orion_rtc_write_data(unsigned char data, unsigned long addr)
-{
-}
-
-static int orion_rtc_bcd_mode(void)
-{
-	return 0;
-}
-
-struct rtc_ops orion_rtc_ops = {
-	&orion_rtc_read_data,
-	&orion_rtc_write_data,
-	&orion_rtc_bcd_mode
-};
-
-extern void InitCIB(void);
-extern void InitQpic(void);
-extern void InitCupid(void);
-
-void __init orion_setup(void)
-{
-	InitCIB();
-	InitQpic();
-	InitCupid();
-}
-
-#define PFN_UP(x)	(((x) + PAGE_SIZE-1) >> PAGE_SHIFT)
-#define PFN_ALIGN(x)	(((unsigned long)(x) + (PAGE_SIZE - 1)) & PAGE_MASK)
-
-
-
-int orion_sysinit(void)
-{
-	unsigned long mem_size, free_start, free_end, start_pfn, bootmap_size;
-	
-	mips_machgroup = MACH_GROUP_ORION;
-	/* 64 MB non-upgradable */
-	mem_size = 32 << 20;
-	
-	free_start = PHYSADDR(PFN_ALIGN(&_end));
-	free_end = mem_size;
-	start_pfn = PFN_UP((unsigned long)&_end);
-	
-	/* Register all the contiguous memory with the bootmem allocator
-	   and free it.  Be careful about the bootmem freemap.  */
-	bootmap_size = init_bootmem(start_pfn, mem_size >> PAGE_SHIFT);
-	
-	/* Free the entire available memory after the _end symbol.  */
-	free_start += bootmap_size;
-	free_bootmem(free_start, free_end-free_start);
-}
diff -u --recursive --new-file linux-mips-2.4.0-test5-20000731.macro/arch/mips/orion/setup.c linux-mips-2.4.0-test5-20000731/arch/mips/orion/setup.c
--- linux-mips-2.4.0-test5-20000731.macro/arch/mips/orion/setup.c	Tue Jul 11 04:26:06 2000
+++ linux-mips-2.4.0-test5-20000731/arch/mips/orion/setup.c	Sun Aug 13 18:57:53 2000
@@ -42,8 +42,7 @@
 #include <asm/mc146818rtc.h>
 #include <asm/orion.h>
 
-char arcs_cmdline[CL_SIZE] = { "console=ttyS0,19200" };
-extern int _end;
+char arcs_cmdline[COMMAND_LINE_SIZE] = { "console=ttyS0,19200" };
 
 static unsigned char orion_rtc_read_data(unsigned long addr)
 {
@@ -83,45 +82,18 @@
 	InitCupid();
 }
 
-#define PFN_UP(x)	(((x) + PAGE_SIZE-1) >> PAGE_SHIFT)
-#define PFN_ALIGN(x)	(((unsigned long)(x) + (PAGE_SIZE - 1)) & PAGE_MASK)
-
-unsigned long mem_size;
 int __init prom_init(int a, char **b, char **c, int *d)
 {
-	unsigned long free_start, free_end, start_pfn, bootmap_size;
 	extern unsigned long orion_initrd_start[], orion_initrd_size;
 
 	mips_machgroup = MACH_GROUP_ORION;
+
 	/* 64 MB non-upgradable */
-	mem_size = 64 << 20;
-	
-	free_start = PHYSADDR(PFN_ALIGN(&_end));
-	free_end = mem_size;
-	start_pfn = PFN_UP((unsigned long)&_end);
-	
-	/* Register all the contiguous memory with the bootmem allocator
-	   and free it.  Be careful about the bootmem freemap.  */
-	bootmap_size = init_bootmem(start_pfn, mem_size >> PAGE_SHIFT);
-	
-	/* Free the entire available memory after the _end symbol.  */
-	free_start += bootmap_size;
-	free_bootmem(free_start, free_end-free_start);
-
-	initrd_start = (ulong)orion_initrd_start;
-	initrd_end = (ulong)orion_initrd_start + (ulong)orion_initrd_size;
-	initrd_below_start_ok = 1;
+	add_memory_region(0, 64 << 20, BOOT_MEM_RAM);
 
 	return 0;
 }
 
 void prom_free_prom_memory (void)
 {
-}
-
-int page_is_ram(unsigned long pagenr)
-{
-	if ( pagenr < (mem_size >> PAGE_SHIFT) )
-		return 1;
-	return 0;
 }
diff -u --recursive --new-file linux-mips-2.4.0-test5-20000731.macro/arch/mips/sgi/kernel/setup.c linux-mips-2.4.0-test5-20000731/arch/mips/sgi/kernel/setup.c
--- linux-mips-2.4.0-test5-20000731.macro/arch/mips/sgi/kernel/setup.c	Mon Jul 24 04:26:01 2000
+++ linux-mips-2.4.0-test5-20000731/arch/mips/sgi/kernel/setup.c	Sun Aug 13 18:48:39 2000
@@ -128,15 +128,6 @@
 #endif
 }
 
-int __init page_is_ram(unsigned long pagenr)
-{
-	if (pagenr < MAP_NR(PAGE_OFFSET + 0x2000UL))
-		return 1;
-	if (pagenr > MAP_NR(PAGE_OFFSET + 0x08002000))
-		return 1;
-	return 0;
-}
-
 void (*board_time_init)(struct irqaction *irq);
 
 static unsigned long dosample(volatile unsigned char *tcwp,
diff -u --recursive --new-file linux-mips-2.4.0-test5-20000731.macro/arch/mips/sni/setup.c linux-mips-2.4.0-test5-20000731/arch/mips/sni/setup.c
--- linux-mips-2.4.0-test5-20000731.macro/arch/mips/sni/setup.c	Wed Jun 21 04:26:41 2000
+++ linux-mips-2.4.0-test5-20000731/arch/mips/sni/setup.c	Sun Aug 13 18:48:47 2000
@@ -101,11 +101,6 @@
 	printk("%s.\n", boardtype);
 }
 
-int __init page_is_ram(unsigned long pagenr)
-{
-	return 1;
-}
-
 void __init sni_rm200_pci_setup(void)
 {
 #if 0 /* XXX Tag me deeper  */
diff -u --recursive --new-file linux-mips-2.4.0-test5-20000731.macro/include/asm-mips/bootinfo.h linux-mips-2.4.0-test5-20000731/include/asm-mips/bootinfo.h
--- linux-mips-2.4.0-test5-20000731.macro/include/asm-mips/bootinfo.h	Tue Jul 11 04:26:27 2000
+++ linux-mips-2.4.0-test5-20000731/include/asm-mips/bootinfo.h	Sun Aug 13 20:04:00 2000
@@ -1,4 +1,4 @@
-/* $Id: bootinfo.h,v 1.11 2000/03/06 11:14:32 raiko Exp $
+/* $Id: bootinfo.h,v 2.11 2000/03/06 11:14:32 raiko Exp $
  *
  * bootinfo.h -- Definition of the Linux/MIPS boot information structure
  *
@@ -155,9 +155,14 @@
         "R6000A", "R8000", "R10000", "R4300", "R4650", "R4700", "R5000",     \
         "R5000A", "R4640", "Nevada" }
 
-#define CL_SIZE      (80)
+#define COMMAND_LINE_SIZE	256
 
-#ifndef _LANGUAGE_ASSEMBLY
+#define BOOT_MEM_MAP_MAX	32
+#define BOOT_MEM_RAM		1
+#define BOOT_MEM_ROM_DATA	2
+#define BOOT_MEM_RESERVED	3
+
+#ifndef __ASSEMBLY__
 
 /*
  * Some machine parameters passed by the bootloaders. 
@@ -191,6 +196,24 @@
 extern unsigned long mips_machgroup;
 extern unsigned long mips_tlb_entries;
 
-#endif /* _LANGUAGE_ASSEMBLY */
+/*
+ * A memory map that's built upon what was determined
+ * or specified on the command line.
+ */
+struct boot_mem_map {
+	int nr_map;
+	struct {
+		unsigned long addr;	/* start of memory segment */
+		unsigned long size;	/* size of memory segment */
+		long type;		/* type of memory segment */
+	} map[BOOT_MEM_MAP_MAX];
+};
+
+extern struct boot_mem_map boot_mem_map;
+
+extern void add_memory_region(unsigned long start, unsigned long size,
+			      long type);
+
+#endif /* !__ASSEMBLY__ */
 
 #endif /* __ASM_MIPS_BOOTINFO_H */
diff -u --recursive --new-file linux-mips-2.4.0-test5-20000731.macro/include/asm-mips/sgialib.h linux-mips-2.4.0-test5-20000731/include/asm-mips/sgialib.h
--- linux-mips-2.4.0-test5-20000731.macro/include/asm-mips/sgialib.h	Tue Mar 28 04:27:20 2000
+++ linux-mips-2.4.0-test5-20000731/include/asm-mips/sgialib.h	Sun Aug 13 20:29:14 2000
@@ -30,28 +30,12 @@
 /* Generic printf() using ARCS console I/O. */
 extern void prom_printf(char *fmt, ...);
 
-/* Memory descriptor management. */
-#define PROM_MAX_PMEMBLOCKS    32
-struct prom_pmemblock {
-	unsigned long base; /* Within KSEG0. */
-	unsigned int size;  /* In bytes. */
-        unsigned int type;  /* free or prom memory */
-};
-
-/* Get next memory descriptor after CURR, returns first descriptor
- * in chain is CURR is NULL.
- */
-extern struct linux_mdesc *prom_getmdesc(struct linux_mdesc *curr);
 #define PROM_NULL_MDESC   ((struct linux_mdesc *) 0)
 
 /* Called by prom_init to setup the physical memory pmemblock
  * array.
  */
 extern void prom_meminit(void);
-extern void prom_fixup_mem_map(unsigned long start_mem, unsigned long end_mem);
-
-/* Returns pointer to PROM physical memory block array. */
-extern struct prom_pmemblock *prom_getpblock_array(void);
 
 /* PROM device tree library routines. */
 #define PROM_NULL_COMPONENT ((pcomponent *) 0)


From owner-linux-mips@oss.sgi.com Tue Aug 15 06:21:59 2000
Received:  by oss.sgi.com id <S42306AbQHONVu>;
	Tue, 15 Aug 2000 06:21:50 -0700
Received: from pneumatic-tube.sgi.com ([204.94.214.22]:38177 "EHLO
        pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP
	id <S42303AbQHONVc>; Tue, 15 Aug 2000 06:21:32 -0700
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id GAA04703
	for <linux-mips@oss.sgi.com>; Tue, 15 Aug 2000 06:27:40 -0700 (PDT)
	mail_from (dom@mudchute.algor.co.uk)
Received: from sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id GAA46414
	for <linux@cthulhu.engr.sgi.com>;
	Tue, 15 Aug 2000 06:21:12 -0700 (PDT)
	mail_from (dom@mudchute.algor.co.uk)
Received: from waterloo.algor.co.uk (waterloo.algor.co.uk [193.117.190.13]) 
	by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam:
       SGI does not authorize the use of its proprietary
       systems or networks for unsolicited or bulk email
       from the Internet.) 
	via ESMTP id GAA01403
	for <linux@cthulhu.engr.sgi.com>; Tue, 15 Aug 2000 06:21:03 -0700 (PDT)
	mail_from (dom@mudchute.algor.co.uk)
Received: from kenton.algor.co.uk (root@kenton.algor.co.uk [62.254.210.199])
	by waterloo.algor.co.uk (8.8.5/8.8.8) with ESMTP id OAA19202;
	Tue, 15 Aug 2000 14:19:27 +0100 (BST)
Received: from mudchute.algor.co.uk (dom@mudchute.algor.co.uk [62.254.210.251])
	by kenton.algor.co.uk (8.9.3/8.8.8) with ESMTP id MAA07956;
	Tue, 15 Aug 2000 12:13:10 +0100 (GMT/BST)
Received: (from dom@localhost)
	by mudchute.algor.co.uk (8.8.5/8.8.5) id LAA11816;
	Tue, 15 Aug 2000 11:52:20 +0100 (BST)
Date:   Tue, 15 Aug 2000 11:52:20 +0100 (BST)
Message-Id: <200008151052.LAA11816@mudchute.algor.co.uk>
From:   Dominic Sweetman <dom@algor.co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
To:     Alorithmics Contacts <dom@algor.co.uk>
Subject: Algorithmics Ltd of England have moved
X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing
Content-Length: 827
Lines: 26


First, apologies to the many of you who aren't interested.  I have no
practical way of cleaning my list of 1000+ email contacts any
further.  I'll keep this brief, and if you have no interest in the new
location of Algorithmics Ltd of England, please delete it now.

  New address:
     The Fruit Farm, Ely Road, Chittering, CAMBS CB5 9PH, ENGLAND

  New phone: 
     +44 1223 706200

  New fax:
     +44 1223 706250

  No change to email addresses or internet names (though our IP
     addresses have changed, but only the very techy will notice).

We have redirects on our old address and phone numbers, but propagate
this change as quickly as you can.

-- 
Dominic Sweetman
Algorithmics Ltd
The Fruit Farm, Ely Road, Chittering, CAMBS CB5 9PH, ENGLAND
phone: +44 1223 706200 / fax: +44 1223 706250 / http://www.algor.co.uk

From owner-linux-mips@oss.sgi.com Mon Aug 21 20:56:25 2000
Received:  by oss.sgi.com id <S42288AbQHVD4P>;
	Mon, 21 Aug 2000 20:56:15 -0700
Received: from deliverator.sgi.com ([204.94.214.10]:2845 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S42207AbQHVDzy>;
	Mon, 21 Aug 2000 20:55:54 -0700
Received: from cthulhu.engr.sgi.com (gate3-relay.engr.sgi.com [130.62.1.234]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id UAA26755
	for <linux-mips@oss.sgi.com>; Mon, 21 Aug 2000 20:48:11 -0700 (PDT)
	mail_from (adi@mr-happy.com)
Received: from sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id UAA44868
	for <linux@cthulhu.engr.sgi.com>;
	Mon, 21 Aug 2000 20:55:31 -0700 (PDT)
	mail_from (adi@mr-happy.com)
Received: from brainguy.tc.mtu.edu (brainguy.tc.mtu.edu [141.219.5.85]) 
	by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam:
       SGI does not authorize the use of its proprietary
       systems or networks for unsolicited or bulk email
       from the Internet.) 
	via ESMTP id UAA09725
	for <linux@cthulhu.engr.sgi.com>; Mon, 21 Aug 2000 20:55:29 -0700 (PDT)
	mail_from (adi@mr-happy.com)
Received: from crow.mr-happy.com (crow.mr-happy.com [172.19.3.81])
	by brainguy.tc.mtu.edu (Postfix) with ESMTP
	id D811C1A196; Mon, 21 Aug 2000 23:55:22 -0400 (EDT)
Received: by crow.mr-happy.com (Postfix, from userid 22448)
	id CEF418D58; Mon, 21 Aug 2000 23:55:20 -0400 (EDT)
Date:   Mon, 21 Aug 2000 22:55:20 -0500
From:   Andy Isaacson <adi@mr-happy.com>
To:     James Simmons <jsimmons@acsu.buffalo.edu>, i15@ornl.gov
Cc:     linux-fbdev@vuser.vu.union.edu, linux@cthulhu.engr.sgi.com
Subject: Re: [linux-fbdev] SGI VW 540, fbdev and pot pourii of faults and evidence..:-)
Message-ID: <20000821225520.A25330@mr-happy.com>
References: <Pine.LNX.4.10.10008091913570.1534-100000@maxwell.futurevision.com> <Pine.SGI.4.10.10008091908170.26870-100000@tigger.ccs.ornl.gov> <Pine.LNX.4.21.0008051851230.943-100000@janus.lsd.ornl.gov> <Pine.LNX.4.10.10008091913570.1534-100000@maxwell.futurevision.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.4i
In-Reply-To: <Pine.LNX.4.10.10008091913570.1534-100000@maxwell.futurevision.com>; from jsimmons@acsu.buffalo.edu on Wed, Aug 09, 2000 at 07:17:02PM -0400
X-PGP-Fingerprint: 48 01 21 E2 D4 E4 68 D1  B8 DF 39 B2 AF A3 16 B9
X-PGP-Key-URL: http://web.mr-happy.com/~adi/pgp.txt
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing
Content-Length: 1366
Lines: 29

On Wed, Aug 09, 2000 at 07:17:02PM -0400, James Simmons wrote:
> > I would also like to ask, if SGI is likely to make the hardware specs OSS
> > (for cobalt etc.), so that those with the skill (this is not my forte, but
> > I will try...), can stabilise this otherwise competent port.
> 
> Nope. SGI no longer supports Visual Workstations with linux. I don't even
> know if they support Visual Workstatiosn period. It would be nice if they
> did release the specs anyways :-)

SGI never did support the Visual Workstation 540 and 320 in Linux.
There did exist some code, but it was never a formal SGI product.

On Wed, Aug 09, 2000 at 07:28:07PM -0400, philloc@tigger.ccs.ornl.gov wrote:
> 	Anyone from SGI care to comment on why SGI has not released the
> specs to reasonable attention, since they are unable to help port? 

I don't speak for SGI, but in the past I think they said that the
specs basically do not exist in a releasable form.  Basically, the
hardware developers and software developers worked in the same hallway
and the development was of the form "hey Joe, how do I program the
zapbot to do foobaz?"

OK, maybe that's not quite accurate, but the result is that there are
no plans to release specs.

-andy
-- 
Andy Isaacson <adi@mr-happy.com> http://web.mr-happy.com/~adi/
I want to buy your broken laptop! http://web.mr-happy.com/~adi/laptop.html

From owner-linux-mips@oss.sgi.com Tue Aug 22 04:22:48 2000
Received:  by oss.sgi.com id <S42312AbQHVLWi>;
	Tue, 22 Aug 2000 04:22:38 -0700
Received: from noose.gt.owl.de ([62.52.19.4]:54276 "HELO noose.gt.owl.de")
	by oss.sgi.com with SMTP id <S42304AbQHVLWU>;
	Tue, 22 Aug 2000 04:22:20 -0700
Received: by noose.gt.owl.de (Postfix, from userid 10)
	id 8BD7E7DD; Tue, 22 Aug 2000 13:25:38 +0200 (CEST)
Received: by paradigm.rfc822.org (Postfix, from userid 1000)
	id 0A5AC8FF5; Tue, 22 Aug 2000 13:21:48 +0200 (CEST)
Date:   Tue, 22 Aug 2000 13:21:47 +0200
From:   Florian Lohoff <flo@rfc822.org>
To:     linux-mips@oss.sgi.com
Subject: VCE exception
Message-ID: <20000822132147.D6784@paradigm.rfc822.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
User-Agent: Mutt/1.0.1i
Organization: rfc822 - pure communication
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing
Content-Length: 2725
Lines: 85

Hi,
i am still seeing a lot of VCE exceptions on my R4k Decstations
and on the SGI Indigo2 - On my Decstation 5000/260 there are
around 300 VCEI exceptions a second which is VERY much.

I am now trying to understand the cause of these Exceptions.

As i understand from the Books a VCE is taken when on an
access to the Second level cache its detected that there is already
a copy of this data in the Primary Cache but its accessed through
a different P-Cache line as its Virtually indexed and the same
data is accessed through a different Virtual address.

As i understand this correct isnt it normal to have this kind
of exception (for instructions) as we are dealing with shared
librarys which might be mapped to different virtual addresses for each
process.

The books now say - We should delete/invalidate the old location
on the Primary cache and update the PIdx in the Second level cache.

[builder@resume builder]$ uptime
11:07am  up 20:51,  1 user,  load average: 1.01, 1.10, 1.10
[builder@resume builder]$ cat /proc/cpuinfo 
cpu			: MIPS
cpu model		: R4000SC V6.0
system type		: SGI Indy
BogoMIPS		: 124.93
byteorder		: big endian
unaligned accesses	: 97
wait instruction	: no
microsecond timers	: no
extra interrupt vector	: no
hardware watchpoint	: yes
VCED exceptions		: 17367628
VCEI exceptions		: 10243032

This is an uptime of 75060 seconds - 136 VCEI/s and 231 VCED/s

builder@repeat:~$ uptime
cat   7:59am  up 3 days, 19:26,  1 user,  load average: 1.17, 1.06, 1.08
builder@repeat:~$ cat /proc/cpuinfo 
cpu			: MIPS
cpu model		: R4000SC V3.0
system type		: Digital DECstation 5000/1xx
BogoMIPS		: 49.81
byteorder		: little endian
unaligned accesses	: 45
wait instruction	: no
microsecond timers	: yes
extra interrupt vector	: no
hardware watchpoint	: yes
VCED exceptions		: 56724062
VCEI exceptions		: 36117905

329160 seconds uptime - 172 VCED/s and 109 VCEI/s 

Both machines were busy nearly all there uptime compiling debian packages.

[flo@reconfig flo]$ cat /proc/cpuinfo 
cpu			: MIPS
cpu model		: R4400SC V4.0
system type		: Digital DECstation 5000/2x0
BogoMIPS		: 59.90
byteorder		: little endian
unaligned accesses	: 0
wait instruction	: no
microsecond timers	: yes
extra interrupt vector	: no
hardware watchpoint	: yes
VCED exceptions		: 753186
VCEI exceptions		: 1557460
[flo@reconfig flo]$ uptime
  6:55pm  up 12:04,  2 users,  load average: 1.08, 1.06, 1.05
[flo@reconfig flo]$ 

43440 Seconds uptime  - 35 VCEI/s - 17 VCED/s  - On this last
machine i have seen >300 VCEI/s second on an mostly idle machine.
This last machine was idle for most of the uptime ...

Flo
-- 
Florian Lohoff		flo@rfc822.org		      	+49-5201-669912
      "Write only memory - Oops. Time for my medication again ..."


From owner-linux-mips@oss.sgi.com Tue Aug 22 08:32:59 2000
Received:  by oss.sgi.com id <S42307AbQHVPct>;
	Tue, 22 Aug 2000 08:32:49 -0700
Received: from deliverator.sgi.com ([204.94.214.10]:34169 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S42304AbQHVPcj>;
	Tue, 22 Aug 2000 08:32:39 -0700
Received: from cthulhu.engr.sgi.com (gate3-relay.engr.sgi.com [130.62.1.234]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id IAA14762
	for <linux-mips@oss.sgi.com>; Tue, 22 Aug 2000 08:25:02 -0700 (PDT)
	mail_from (jsimmons@acsu.buffalo.edu)
Received: from sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id IAA85401
	for <linux@cthulhu.engr.sgi.com>;
	Tue, 22 Aug 2000 08:32:21 -0700 (PDT)
	mail_from (jsimmons@acsu.buffalo.edu)
Received: from xena.acsu.buffalo.edu (xena.acsu.buffalo.edu [128.205.7.121]) 
	by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam:
       SGI does not authorize the use of its proprietary
       systems or networks for unsolicited or bulk email
       from the Internet.) 
	via SMTP id IAA09760
	for <linux@cthulhu.engr.sgi.com>; Tue, 22 Aug 2000 08:32:20 -0700 (PDT)
	mail_from (jsimmons@acsu.buffalo.edu)
Received: (qmail 18878 invoked from network); 22 Aug 2000 15:32:18 -0000
Received: from ubppp233-237.dialin.buffalo.edu (jsimmons@128.205.233.237)
  by xena.acsu.buffalo.edu with SMTP; 22 Aug 2000 15:32:18 -0000
Date:   Tue, 22 Aug 2000 11:43:15 -0400 (EDT)
From:   James Simmons <jsimmons@acsu.buffalo.edu>
X-Sender: jsimmons@maxwell.futurevision.com
To:     Andy Isaacson <adi@mr-happy.com>
cc:     i15@ornl.gov, linux-fbdev@vuser.vu.union.edu,
        linux@cthulhu.engr.sgi.com
Subject: Re: [linux-fbdev] SGI VW 540, fbdev and pot pourii of faults and
 evidence..:-)
In-Reply-To: <20000821225520.A25330@mr-happy.com>
Message-ID: <Pine.LNX.4.10.10008221138450.664-100000@maxwell.futurevision.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing
Content-Length: 1004
Lines: 21


> On Wed, Aug 09, 2000 at 07:28:07PM -0400, philloc@tigger.ccs.ornl.gov wrote:
> > 	Anyone from SGI care to comment on why SGI has not released the
> > specs to reasonable attention, since they are unable to help port? 
> 
> I don't speak for SGI, but in the past I think they said that the
> specs basically do not exist in a releasable form.  Basically, the
> hardware developers and software developers worked in the same hallway
> and the development was of the form "hey Joe, how do I program the
> zapbot to do foobaz?"

Actually you are right. The lack of docs internally in SGI has caused this
problem. This also has had the bad side effect of when they lose a
critical employee then no one else has a clue on how it program it. You
have to start from scratch. 

[OT]. This actually happend to M$ as well. One person wrote they entire
registery for win95. He left the company and when it came time to port it
to win2000 no one understood how it worked. So they had to rewrite it from
scratch. 


From owner-linux-mips@oss.sgi.com Tue Aug 22 08:56:29 2000
Received:  by oss.sgi.com id <S42308AbQHVP4T>;
	Tue, 22 Aug 2000 08:56:19 -0700
Received: from pneumatic-tube.sgi.com ([204.94.214.22]:26679 "EHLO
        pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP
	id <S42304AbQHVPzy>; Tue, 22 Aug 2000 08:55:54 -0700
Received: from nodin.corp.sgi.com (nodin.corp.sgi.com [192.26.51.193]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id JAA02807
	for <linux-mips@oss.sgi.com>; Tue, 22 Aug 2000 09:02:10 -0700 (PDT)
	mail_from (shm@cthulhu.engr.sgi.com)
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by nodin.corp.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) via ESMTP id IAA28242 for <linux-mips@oss.sgi.com>; Tue, 22 Aug 2000 08:55:23 -0700 (PDT)
Received: from tantrik.engr.sgi.com (tantrik.engr.sgi.com [130.62.52.189])
	by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id IAA95466;
	Tue, 22 Aug 2000 08:53:50 -0700 (PDT)
	mail_from (shm@cthulhu.engr.sgi.com)
Received: from localhost (shm@localhost) by tantrik.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id IAA64683; Tue, 22 Aug 2000 08:53:49 -0700 (PDT)
Date:   Tue, 22 Aug 2000 08:53:49 -0700
From:   Shrijeet Mukherjee <shm@cthulhu.engr.sgi.com>
cc:     linux-fbdev@vuser.vu.union.edu,
        Linux porting team <linux@cthulhu.engr.sgi.com>
Subject: Re: [linux-fbdev] SGI VW 540, fbdev and pot pourii of faults and
 evidence..:-)
In-Reply-To: <Pine.LNX.4.10.10008221138450.664-100000@maxwell.futurevision.com>
Message-ID: <Pine.SGI.4.21.0008220847450.264415-100000@tantrik.engr.sgi.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
To:     unlisted-recipients:; (no To-header on input)
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing
Content-Length: 2078
Lines: 45

On Tue, 22 Aug 2000, James Simmons wrote:

JS>> I don't speak for SGI, but in the past I think they said that the
JS>> specs basically do not exist in a releasable form.  Basically, the
JS>> hardware developers and software developers worked in the same hallway
JS>> and the development was of the form "hey Joe, how do I program the
JS>> zapbot to do foobaz?"
JS>
JS>Actually you are right. The lack of docs internally in SGI has caused this
JS>problem. This also has had the bad side effect of when they lose a
JS>critical employee then no one else has a clue on how it program it. You
JS>have to start from scratch. 
JS>

Well as I have tried to explain in the past the situation is not as cut
and dry as all that. For most hardware systems, well written driver code
is a good place to start. (in fact al of the internal port to linux for
the 320 was done without formal docs, or the engg's to talk to)

The real problem is that the 320 gfx family uses a SGI style
high-performance which is different from the AGP style approach that the
other guys use. Porting this to linux .. or more than knowing how the
hardware works .. since we need to port a very complicated mechanism, for
which linux may not have obvious and ready replacements.

On top of that .. there are potentially Intellectual Property issues with
the management style. Thus the concerns with just releasing the specs.

Since this is a recurring question, are there people on this list that are
personally motivated to try and port this system over ?

Std Disclaimer: I am not speaking for SGI .. all opinions expressed here
and mine and mine alone.

Thanx

-- 
--------------------------------------------------------------------------
Shrijeet Mukherjee,    		        Advanced Graphics, SGI
http://reality.sgi.com/shm_engr     	phone: 650-933-5312
email: shm@sgi.com, shrijeet@hotmail.com
--------------------------------------------------------------------------
Where there is a will, there is a way. If a way cannot be found, 
it is the will that is suspect ..                                   -- shm 


From owner-linux-mips@oss.sgi.com Tue Aug 22 09:29:19 2000
Received:  by oss.sgi.com id <S42313AbQHVQ3J>;
	Tue, 22 Aug 2000 09:29:09 -0700
Received: from deliverator.sgi.com ([204.94.214.10]:34319 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S42304AbQHVQ3A>;
	Tue, 22 Aug 2000 09:29:00 -0700
Received: from cthulhu.engr.sgi.com (gate3-relay.engr.sgi.com [130.62.1.234]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id JAA22613
	for <linux-mips@oss.sgi.com>; Tue, 22 Aug 2000 09:21:23 -0700 (PDT)
	mail_from (ehab@aia067.aia.rwth-aachen.de)
Received: from sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id JAA22893;
	Tue, 22 Aug 2000 09:28:41 -0700 (PDT)
	mail_from (ehab@aia067.aia.RWTH-Aachen.DE)
Received: from aia067.aia.RWTH-Aachen.DE (aia067.aia.RWTH-Aachen.DE [134.130.140.67]) 
	by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam:
       SGI does not authorize the use of its proprietary
       systems or networks for unsolicited or bulk email
       from the Internet.) 
	via ESMTP id JAA01932; Tue, 22 Aug 2000 09:28:37 -0700 (PDT)
	mail_from (ehab@aia067.aia.RWTH-Aachen.DE)
Received: from localhost (localhost [[UNIX: localhost]])
	by aia067.aia.RWTH-Aachen.DE (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) id SAA08887;
	Tue, 22 Aug 2000 18:28:30 +0200
From:   Ehab Fares <ehab@aia.rwth-aachen.de>
To:     Shrijeet Mukherjee <shm@cthulhu.engr.sgi.com>
Subject: Re: [linux-fbdev] SGI VW 540, fbdev... and other stuff
Date:   Tue, 22 Aug 2000 17:59:43 +0200
X-Mailer: KMail [version 1.0.28]
Content-Type: text/plain
Cc:     linux-fbdev@vuser.vu.union.edu,
        Linux porting team <linux@cthulhu.engr.sgi.com>
References: <Pine.SGI.4.21.0008220847450.264415-100000@tantrik.engr.sgi.com>
In-Reply-To: <Pine.SGI.4.21.0008220847450.264415-100000@tantrik.engr.sgi.com>
MIME-Version: 1.0
Message-Id: <00082218283000.08755@aia067>
Content-Transfer-Encoding: 8bit
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing
Content-Length: 2113
Lines: 43

On Tue, 22 Aug 2000, Shrijeet Mukherjee wrote:
> Well as I have tried to explain in the past the situation is not as cut
> and dry as all that. For most hardware systems, well written driver code
> is a good place to start. (in fact al of the internal port to linux for
> the 320 was done without formal docs, or the engg's to talk to)
> 
> The real problem is that the 320 gfx family uses a SGI style
> high-performance which is different from the AGP style approach that the
> other guys use. Porting this to linux .. or more than knowing how the
> hardware works .. since we need to port a very complicated mechanism, for
> which linux may not have obvious and ready replacements.
> 
> On top of that .. there are potentially Intellectual Property issues with
> the management style. Thus the concerns with just releasing the specs.
> 
> Since this is a recurring question, are there people on this list that are
> personally motivated to try and port this system over ?
> 
We are using a 540 system with the top configuration (4 processors, 2GB Ram and
the flat panel 1600SW). We are certainly motivated to get linux and the
X-Server working  poperly. As already posted in this mailing list the X-server
is not the only problem. I therefore would suggest to start collecting all the
problems that should be solved and look for people interested in working on
the port.  

The problems we have are:
1) new kernels simply wouldn'[t boot the machine. I got the machine working
with  the 2.2.10 patched kernel. All the four processors are working.
2) We have only 960 MB Ram of the installed 2GB working.
3) strange behaviour of the keyboard.
4) the parallel port is not working. (we haven't tested the rest of the ports)
5) very poor X performance with hangs every now and then which is probably
because of the X-Server.

Are there other people having similar or other problems and interested in
solving them? Is there anyone who have the experience or knowledge of that
system (and linux) who can help?

I personally would like to help but need some information and
details as I'm not a kernel hacker. 

Ehab.


From owner-linux-mips@oss.sgi.com Tue Aug 22 16:55:31 2000
Received:  by oss.sgi.com id <S42318AbQHVXzL>;
	Tue, 22 Aug 2000 16:55:11 -0700
Received: from gateway-490.mvista.com ([63.192.220.206]:25847 "EHLO
        hermes.mvista.com") by oss.sgi.com with ESMTP id <S42304AbQHVXy4>;
	Tue, 22 Aug 2000 16:54:56 -0700
Received: from mvista.com (IDENT:ppopov@zeus.mvista.com [10.0.0.112])
	by hermes.mvista.com (8.9.3/8.9.3) with ESMTP id QAA31010
	for <linux-mips@oss.sgi.com>; Tue, 22 Aug 2000 16:54:56 -0700
Message-ID: <39A3123A.477D5BFA@mvista.com>
Date:   Tue, 22 Aug 2000 16:52:26 -0700
From:   Pete Popov <ppopov@mvista.com>
Organization: Monta Vista Software
X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.12-20b i586)
X-Accept-Language: en
MIME-Version: 1.0
To:     "linux-mips@oss.sgi.com" <linux-mips@oss.sgi.com>
Subject: indigo2
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing
Content-Length: 220
Lines: 8


Does anyone know where I can get hardware documentation for the Indigo2?
I'm interested in the hardware memory map and what's on the board
itself, such as ethernet controller, the serial ports, rtc, etc.

Thanks,

Pete

From owner-linux-mips@oss.sgi.com Wed Aug 23 07:05:26 2000
Received:  by oss.sgi.com id <S42345AbQHWOFG>;
	Wed, 23 Aug 2000 07:05:06 -0700
Received: from deliverator.sgi.com ([204.94.214.10]:46451 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S42344AbQHWOEn>;
	Wed, 23 Aug 2000 07:04:43 -0700
Received: from nodin.corp.sgi.com (nodin.corp.sgi.com [192.26.51.193]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id GAA14937
	for <linux-mips@oss.sgi.com>; Wed, 23 Aug 2000 06:57:07 -0700 (PDT)
	mail_from (subhashs@bom3.vsnl.net.in)
Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by nodin.corp.sgi.com (980427.SGI.8.8.8/980728.SGI.AUTOCF) via ESMTP id HAA78809 for <linux-mips@oss.sgi.com>; Wed, 23 Aug 2000 07:04:12 -0700 (PDT)
Received: from sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id HAA49466
	for <linux@cthulhu.engr.sgi.com>;
	Wed, 23 Aug 2000 07:02:40 -0700 (PDT)
	mail_from (subhashs@bom3.vsnl.net.in)
Received: from bom4.vsnl.net.in (bom4.vsnl.net.in [202.54.4.116]) 
	by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam:
       SGI does not authorize the use of its proprietary
       systems or networks for unsolicited or bulk email
       from the Internet.) 
	via ESMTP id HAA01200
	for <linux@cthulhu.engr.sgi.com>; Wed, 23 Aug 2000 07:02:37 -0700 (PDT)
	mail_from (subhashs@bom3.vsnl.net.in)
Received: from vsnl (unknown [203.199.79.72])
	by bom4.vsnl.net.in (Postfix) with SMTP
	id 87EFB2CEA; Wed, 23 Aug 2000 19:31:37 +0500 (GMT+0500)
Message-ID: <00a801c00d0b$14ec3680$0664a8c0@vsnl.net.in>
Reply-To: "Comfort@vsnl.com" <subhashs@bom3.vsnl.net.in>
From:   "Comfort@vsnl.com" <subhashs@bom3.vsnl.net.in>
To:     <Undisclosed-Recipient:;@bom4.vsnl.net.in>
Subject: Free Registraion @ WorldAirConditioners.com [ & 17 other Industry Specific Portals )
Date:   Wed, 23 Aug 2000 19:32:29 +0530
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_009E_01C00D38.E087CDE0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2615.200
X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2615.200
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing
Content-Length: 10027
Lines: 229

This is a multi-part message in MIME format.

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

Dear Sir,=20
    We are pleased to announce the Soft launch of  following 18 =
comprehensive industry specific portals on Home & Electronic =
Appliances,{Manufacturers, Distributors, Dealers and users of Finished =
goods and Raw materials } for Free Registraion.=20

WorldAirCoolers.com        WorldAirPurifiers.com      =
WorldAirConditioners.com               =20
WorldCookingSystems.com    WorldDishWashers.com       =
WorldElectricIrons.com=20
WorldElectricFans.com      WorldFoodProcessors.com    =
WorldHeatingAppliances.com          =20
WorldMicrowaveOvens.com    WorldMusicSystems.com      =
WorldRefrigerators.com             =20
WorldWashingMachines.com   WorldWaterPurifiers.com    =
WorldWaterDispensers.com             =20
WorldWaterHeaters.com      WorldVacuumCleaners.com    =
World-Televisions.com
=20
    We would  request you to see the Demostration of Live Launch and =
Show Room of  Super Tower Fan. This would also help you to decide to =
launch and display your products at these forums for global exposure.
Show Room :       http://www.worldelectricfans.com/product.htm

Live Launch :       http://www.worldelectricfans.com/launch.htm



These portals have been developed for providing following features :

  a.. Meeting ground for buyers & suppliers of finished goods & raw =
materials of home and electronic appliances.
  b.. Meeting ground for manufacturers, distributors, dealers, CFAs =
offering/looking various business/trade opportunities.
  c.. Meeting ground for employers & employees in home and electronic =
appliance industry.
  d.. Auctions, Bargains Bulk-deals Clubs & tender opportunities.
  e.. Virtual showrooms for various products.
  f.. Facilitation centres for customer/visitor.
These portals are being advertised & promoted worldwide to ensure =
maximum target audience participation, to promote the cause of the =
industry in general and its members in particular. You are requested to =
visit concerned portals to see their utility for yourself and to =
Register your organisation Free for reaping the benefit out of this =
unique and great opportunity.

=20

Requesting your participation with Regards,

    * If  you  feel you have received this  message by mistake and do  =
not wish to receive  further emails from WorldAllProducts.com, please =
respond to this email by putting "Please Remove" in the subject line,so =
that your name can be removed from this list.=20



=20


------=_NextPart_000_009E_01C00D38.E087CDE0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type><BASE=20
href=3Dfile://C:\WINDOWS\Desktop\><!DOCTYPE HTML PUBLIC "-//W3C//DTD =
HTML 4.0 Transitional//EN">
<META content=3D"MSHTML 5.00.2614.3500" name=3DGENERATOR>
<STYLE></STYLE>

<META content=3D"MSHTML 5.00.2919.6307" name=3DGENERATOR>
<META content=3D"MSHTML 5.00.2919.6307" name=3DGENERATOR>
<META content=3D"MSHTML 5.00.2919.6307" name=3DGENERATOR>
<META content=3D"MSHTML 5.00.2919.6307" name=3DGENERATOR>
<META content=3D"MSHTML 5.00.2919.6307" name=3DGENERATOR>
<META content=3D"MSHTML 5.00.2919.6307" name=3DGENERATOR>
<META content=3D"MSHTML 5.00.2919.6307" name=3DGENERATOR>
<META content=3D"MSHTML 5.00.2919.6307" name=3DGENERATOR></HEAD>
<BODY bgColor=3D#ffffff>
<DIV><B>Dear Sir,</B> </DIV>
<P><FONT size=3D4><FONT size=3D3>&nbsp;&nbsp;&nbsp; We are&nbsp;pleased =
to announce=20
the <STRONG>Soft launch </STRONG>of&nbsp; following 18 comprehensive =
industry=20
specific portals on Home&nbsp;&amp; Electronic =
Appliances,{</FONT></FONT><FONT=20
size=3D4><FONT size=3D3>Manufacturers, Distributors, Dealers and users =
of Finished=20
goods and Raw materials } for </FONT></FONT><FONT size=3D4><FONT=20
size=3D3><STRONG>Free Registraion. </STRONG></FONT></FONT></P><PRE><A =
href=3D"http://www.worldaircoolers.com/">WorldAirCoolers.com</A>&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<A =
href=3D"http://www.worldairpurifiers.com/">WorldAirPurifiers.com</A>&nbsp=
;&nbsp;    <A =
href=3D"http://www.worldairconditioners.com/">WorldAirConditioners.com</A=
>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;</PRE><PRE><A =
href=3D"http://www.worldcookingsystems.com/">WorldCookingSystems.com</A>&=
nbsp;&nbsp;&nbsp;&nbsp;<A =
href=3D"http://www.worlddishwashers.com/">WorldDishWashers.com</A>&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <A =
href=3D"http://www.worldelectricirons.com/">WorldElectricIrons.com</A>&nb=
sp;</PRE><PRE><A =
href=3D"http://www.worldelectricfans.com/">WorldElectricFans.com</A>&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp; <A =
href=3D"http://www.worldfoodprocessors.com/">WorldFoodProcessors.com</A>&=
nbsp;&nbsp;&nbsp;&nbsp;<A =
href=3D"http://www.worldheatingappliances.com/">WorldHeatingAppliances.co=
m</A>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</=
PRE><PRE><A =
href=3D"http://www.worldmicrowaveovens.com/">WorldMicrowaveOvens.com</A>&=
nbsp;&nbsp;&nbsp;&nbsp;<A =
href=3D"http://www.worldmusicsystems.com/">WorldMusicSystems.com</A>&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp; <A =
href=3D"http://www.worldrefrigerators.com/">WorldRefrigerators.com</A>&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p; </PRE><PRE><A =
href=3D"http://www.worldwashingmachines.com/">WorldWashingMachines.com</A=
>&nbsp;&nbsp;&nbsp;<A =
href=3D"http://www.worldwaterpurifiers.com/">WorldWaterPurifiers.com</A>&=
nbsp;&nbsp;&nbsp;&nbsp;<A =
href=3D"http://www.worldwaterdispensers.com/">WorldWaterDispensers.com</A=
>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp; </PRE><PRE><A =
href=3D"http://www.worldwaterheaters.com/">WorldWaterHeaters.com</A>&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp; <A =
href=3D"http://www.worldvacuumcleaners.com/">WorldVacuumCleaners.com</A>&=
nbsp;&nbsp;&nbsp;&nbsp;<A =
href=3D"http://www.world-televisions.com/">World-Televisions.com</A></PRE=
><PRE>&nbsp;</PRE><PRE>&nbsp;&nbsp;&nbsp; We would&nbsp; request you to =
see the Demostration of Live Launch&nbsp;and Show Room&nbsp;of&nbsp; =
Super Tower Fan.&nbsp;This would also help you to decide to launch and =
display your products at these forums for global exposure.</PRE>
<P align=3Djustify><STRONG>Show Room =
:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
</STRONG><A=20
href=3D"http://www.worldelectricfans.com/product.htm"><STRONG>http://www.=
worldelectricfans.com/product.htm</STRONG></A><A=20
href=3D"http://www.worldelectricfans.com/inter_showroom.htm"></A></P>
<P><STRONG>Live Launch :&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;</STRONG><A =

href=3D"http://www.worldelectricfans.com/launch.htm"><STRONG>http://www.w=
orldelectricfans.com/launch.htm</STRONG></A></P>
<P>&nbsp;</P>
<P><STRONG><U>These portals have been developed for providing following =
features=20
</U>:</STRONG></P>
<UL>
  <LI>
  <DIV align=3Djustify>Meeting ground for buyers &amp; suppliers of =
finished goods=20
  &amp; raw materials of home and electronic appliances.</DIV>
  <LI>
  <DIV align=3Djustify>Meeting ground for manufacturers, distributors, =
dealers,=20
  CFAs offering/looking various business/trade opportunities.</DIV>
  <LI>
  <DIV align=3Djustify>Meeting ground for employers &amp; employees in =
home and=20
  electronic appliance industry.</DIV>
  <LI>
  <DIV align=3Djustify>Auctions, Bargains Bulk-deals Clubs &amp; tender=20
  opportunities.</DIV>
  <LI>
  <DIV align=3Djustify>Virtual showrooms for various products.</DIV>
  <LI>
  <DIV align=3Djustify>Facilitation centres for =
customer/visitor.</DIV></LI></UL>
<P>These portals are being advertised &amp; promoted worldwide to ensure =
maximum=20
target audience participation, to promote the cause of the industry in =
general=20
and its members in particular. You are requested to visit concerned =
portals to=20
see their utility for yourself and to <STRONG>R</STRONG><FONT=20
color=3D#800080><FONT color=3D#0000ff><STRONG>egister</STRONG></FONT> =
</FONT>your=20
organisation <STRONG>F</STRONG><FONT =
color=3D#000080><STRONG>ree</STRONG>=20
</FONT>for reaping the benefit out of this unique and great =
opportunity.</P>
<P><FONT size=3D2><FONT size=3D2>&nbsp;</FONT></P>
<P></FONT>Requesting your participation with Regards,<FONT face=3DArial=20
size=3D2><FONT color=3D#800080><FONT color=3D#800000 face=3D"Tempus Sans =
ITC"=20
size=3D5><STRONG></STRONG></FONT></FONT></FONT></P>
<P><FONT face=3DArial size=3D2><FONT color=3D#800080><FONT =
color=3D#800000=20
face=3D"Tempus Sans ITC" size=3D5><STRONG>&nbsp;&nbsp;&nbsp; =
</STRONG><FONT=20
color=3D#0000ff =
size=3D6>*</FONT><STRONG>&nbsp;</STRONG></FONT></FONT></FONT><FONT=20
face=3DArial size=3D2><FONT color=3D#800000><FONT face=3D"Courier =
New">If<FONT=20
face=3DArial size=3D2><FONT face=3D"Courier New"></FONT></FONT>&nbsp; =
you<FONT=20
face=3DArial size=3D2><FONT face=3D"Courier New"></FONT></FONT>&nbsp; =
feel you have=20
received this&nbsp; message&nbsp;by mistake and do&nbsp; not wish to=20
receive&nbsp; further emails from&nbsp;</FONT></FONT><FONT =
face=3DArial><FONT=20
color=3D#800000 face=3D"Courier New"><FONT=20
color=3D#000000><STRONG>WorldAllProducts.com</STRONG></FONT>, please =
respond to=20
this email by putting <STRONG><FONT color=3D#000000>"Please=20
Remove</FONT></STRONG>" in the subject line,</FONT></FONT><FONT =
face=3DArial><FONT=20
color=3D#800000 face=3D"Courier New">so that your name can be removed =
from this=20
list.</FONT><FONT face=3D"Courier New"><FONT color=3D#800000>=20
<BR></FONT></P></FONT><FONT color=3D#800080></FONT>
<P align=3Dleft><FONT face=3D"Times New Roman"><FONT=20
face=3D"Times New Roman"><BR><FONT=20
face=3D"Courier =
New">&nbsp;</FONT></FONT></FONT></P></FONT></FONT></BODY></HTML>

------=_NextPart_000_009E_01C00D38.E087CDE0--


From owner-linux-mips@oss.sgi.com Wed Aug 23 07:51:56 2000
Received:  by oss.sgi.com id <S42307AbQHWOvq>;
	Wed, 23 Aug 2000 07:51:46 -0700
Received: from noose.gt.owl.de ([62.52.19.4]:28431 "HELO noose.gt.owl.de")
	by oss.sgi.com with SMTP id <S42288AbQHWOv1>;
	Wed, 23 Aug 2000 07:51:27 -0700
Received: by noose.gt.owl.de (Postfix, from userid 10)
	id 8C12A7F7; Wed, 23 Aug 2000 16:54:51 +0200 (CEST)
Received: by paradigm.rfc822.org (Postfix, from userid 1000)
	id 636FB8FF5; Wed, 23 Aug 2000 16:50:52 +0200 (CEST)
Date:   Wed, 23 Aug 2000 16:50:52 +0200
From:   Florian Lohoff <flo@rfc822.org>
To:     Pete Popov <ppopov@mvista.com>
Cc:     "linux-mips@oss.sgi.com" <linux-mips@oss.sgi.com>
Subject: Re: indigo2
Message-ID: <20000823165051.I2501@paradigm.rfc822.org>
References: <39A3123A.477D5BFA@mvista.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
User-Agent: Mutt/1.0.1i
In-Reply-To: <39A3123A.477D5BFA@mvista.com>; from ppopov@mvista.com on Tue, Aug 22, 2000 at 04:52:26PM -0700
Organization: rfc822 - pure communication
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing
Content-Length: 574
Lines: 14

On Tue, Aug 22, 2000 at 04:52:26PM -0700, Pete Popov wrote:
> Does anyone know where I can get hardware documentation for the Indigo2?
> I'm interested in the hardware memory map and what's on the board
> itself, such as ethernet controller, the serial ports, rtc, etc.

Most of the stuff from the Indy should be true also. It should also
be reconstructable from the Kernel source - AFAIK there is no documentation
available for the Indigo2.

Flo
-- 
Florian Lohoff		flo@rfc822.org		      	+49-5201-669912
      "Write only memory - Oops. Time for my medication again ..."


From owner-linux-mips@oss.sgi.com Wed Aug 23 09:25:16 2000
Received:  by oss.sgi.com id <S42288AbQHWQZG>;
	Wed, 23 Aug 2000 09:25:06 -0700
Received: from deliverator.sgi.com ([204.94.214.10]:18716 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S42333AbQHWQYd>;
	Wed, 23 Aug 2000 09:24:33 -0700
Received: from ledzep.cray.com (ledzep.americas.sgi.com [137.38.226.97]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id JAA01631
	for <linux-mips@oss.sgi.com>; Wed, 23 Aug 2000 09:16:26 -0700 (PDT)
	mail_from (bcasavan@sgi.com)
Received: from daisy-e185.americas.sgi.com (daisy.mw.cray.com [128.162.185.214]) by ledzep.cray.com (SGI-SGI-8.9.3/craymail-smart-nospam1.0) with ESMTP id LAA33067; Wed, 23 Aug 2000 11:21:31 -0500 (CDT)
Received: from kzerza.americas.sgi.com (kzerza.americas.sgi.com [128.162.191.33]) by daisy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.6) with ESMTP id LAA63247; Wed, 23 Aug 2000 11:21:31 -0500 (CDT)
Received: from localhost by kzerza.americas.sgi.com (SGI-8.9.3/SGI-client-1.6c) via ESMTP id LAA52022; Wed, 23 Aug 2000 11:21:30 -0500 (CDT)
Date:   Wed, 23 Aug 2000 11:21:30 -0500
From:   Brent Casavant <bcasavan@sgi.com>
X-Sender: bcasavan@kzerza.americas.sgi.com
Reply-To: Brent Casavant <bcasavan@sgi.com>
To:     linux-mips@oss.sgi.com
cc:     Pete Popov <ppopov@mvista.com>
Subject: Re: indigo2
In-Reply-To: <20000823165051.I2501@paradigm.rfc822.org>
Message-ID: <Pine.SGI.4.21.0008231120070.57618-100000@kzerza.americas.sgi.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing
Content-Length: 885
Lines: 26

On Wed, 23 Aug 2000, Florian Lohoff wrote:

> On Tue, Aug 22, 2000 at 04:52:26PM -0700, Pete Popov wrote:
> > Does anyone know where I can get hardware documentation for the Indigo2?
> > I'm interested in the hardware memory map and what's on the board
> > itself, such as ethernet controller, the serial ports, rtc, etc.
> 
> Most of the stuff from the Indy should be true also. It should also
> be reconstructable from the Kernel source - AFAIK there is no documentation
> available for the Indigo2.

There are quite a few Indy documents available at:

	ftp://oss.sgi.com/pub/linux/mips/doc/indy/

I've been led to believe that Indigo^2 and Indy are close enough to
eachother that this sort of documentation may be all you need.

Hope that helps,
Brent

-- 
Brent Casavant            bcasavan@sgi.com
Kernel Engineer           http://reality.sgi.com/bcasavan
Silicon Graphics, Inc.


From owner-linux-mips@oss.sgi.com Wed Aug 23 09:27:35 2000
Received:  by oss.sgi.com id <S42346AbQHWQ10>;
	Wed, 23 Aug 2000 09:27:26 -0700
Received: from deliverator.sgi.com ([204.94.214.10]:61724 "EHLO
        deliverator.sgi.com") by oss.sgi.com with ESMTP id <S42333AbQHWQ1G>;
	Wed, 23 Aug 2000 09:27:06 -0700
Received: from cthulhu.engr.sgi.com (gate3-relay.engr.sgi.com [130.62.1.234]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id JAA01998
	for <linux-mips@oss.sgi.com>; Wed, 23 Aug 2000 09:18:59 -0700 (PDT)
	mail_from (gnava@sirio.tecmor.mx)
Received: from sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id JAA14686
	for <linux@engr.sgi.com>;
	Wed, 23 Aug 2000 09:26:19 -0700 (PDT)
	mail_from (gnava@sirio.tecmor.mx)
Received: from sirio.tecmor.mx (sirio.tecmor.mx [200.33.171.1]) 
	by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam:
       SGI does not authorize the use of its proprietary
       systems or networks for unsolicited or bulk email
       from the Internet.) 
	via ESMTP id JAA09759
	for <linux@engr.sgi.com>; Wed, 23 Aug 2000 09:25:43 -0700 (PDT)
	mail_from (gnava@sirio.tecmor.mx)
Received: from localhost (gnava@localhost)
	by sirio.tecmor.mx (8.9.3/8.9.3) with ESMTP id KAA16761
	for <linux@engr.sgi.com>; Wed, 23 Aug 2000 10:33:48 -0500
Date:   Wed, 23 Aug 2000 10:33:48 -0500 (CDT)
From:   Gabriel Nava Vazquez <gnava@sirio.tecmor.mx>
To:     linux@cthulhu.engr.sgi.com
Subject: XFree86 in Indy
Message-ID: <Pine.LNX.4.21.0008231031450.16640-200000@sirio.tecmor.mx>
MIME-Version: 1.0
Content-Type: MULTIPART/Mixed; BOUNDARY="8323328-1100244579-967044400=:16640"
Content-ID: <Pine.LNX.4.21.0008231031451.16640@sirio.tecmor.mx>
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing
Content-Length: 5899
Lines: 113

  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.

--8323328-1100244579-967044400=:16640
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-ID: <Pine.LNX.4.21.0008231031452.16640@sirio.tecmor.mx>


Hello

I have linux installed in an Indy and i installed XFree86 following
all the instructions.

When i execute xinit or startx, everything seems to be ok, the display
jumps to tty7 but there is not image.  If i check the terminal from i
executed x11, there is no messages about errors, and if y do a ps x, 
there are all the process alive (x, xterm, etc).

Can you help me? Do you have any experience with the xserver?

Thanks

Ing. Gabriel Nava
Instituto Tecnologico de Morelia, 
Mexico

--8323328-1100244579-967044400=:16640
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII; NAME=xlog
Content-Transfer-Encoding: BASE64
Content-ID: <Pine.LNX.4.21.0008231026400.16640@sirio.tecmor.mx>
Content-Description: xserver log
Content-Disposition: ATTACHMENT; FILENAME=xlog

DQoNClhGcmVlODYgVmVyc2lvbiA0LjAuMSAvIFggV2luZG93IFN5c3RlbQ0K
KHByb3RvY29sIFZlcnNpb24gMTEsIHJldmlzaW9uIDAsIHZlbmRvciByZWxl
YXNlIDY0MDApDQpSZWxlYXNlIERhdGU6IDEgSnVseSAyMDAwDQoJSWYgdGhl
IHNlcnZlciBpcyBvbGRlciB0aGFuIDYtMTIgbW9udGhzLCBvciBpZiB5b3Vy
IGNhcmQgaXMgbmV3ZXINCgl0aGFuIHRoZSBhYm92ZSBkYXRlLCBsb29rIGZv
ciBhIG5ld2VyIHZlcnNpb24gYmVmb3JlIHJlcG9ydGluZw0KCXByb2JsZW1z
LiAgKHNlZSBodHRwOi8vd3d3LlhGcmVlODYuT3JnL0ZBUSkNCk9wZXJhdGlu
ZyBTeXN0ZW06IExpbnV4IDIuMi4xMyBtaXBzIFtFTEZdIA0KKD09KSBMb2cg
ZmlsZTogIi92YXIvbG9nL1hGcmVlODYuMC5sb2ciLCBUaW1lOiBUdWUgQXVn
IDIyIDE2OjU4OjQ0IDIwMDANCig9PSkgVXNpbmcgY29uZmlnIGZpbGU6ICIv
ZXRjL1gxMS9YRjg2Q29uZmlnIg0KTWFya2VyczogKC0tKSBwcm9iZWQsICgq
KikgZnJvbSBjb25maWcgZmlsZSwgKD09KSBkZWZhdWx0IHNldHRpbmcsDQog
ICAgICAgICAoKyspIGZyb20gY29tbWFuZCBsaW5lLCAoISEpIG5vdGljZSwg
KElJKSBpbmZvcm1hdGlvbmFsLA0KICAgICAgICAgKFdXKSB3YXJuaW5nLCAo
RUUpIGVycm9yLCAoPz8pIHVua25vd24uDQooPT0pIFNlcnZlckxheW91dCAi
c2ltcGxlIGxheW91dCINCigqKikgfC0tPlNjcmVlbiAiU2NyZWVuIDEiICgw
KQ0KKCoqKSB8ICAgfC0tPk1vbml0b3IgIlNHSSBHRE0xN2UxMSINCigqKikg
fCAgIHwtLT5EZXZpY2UgIk5ld3BvcnQgR3JhcGhpY3MiDQooKiopIHwtLT5J
bnB1dCBEZXZpY2UgIk1vdXNlMSINCigqKikgfC0tPklucHV0IERldmljZSAi
S2V5Ym9hcmQxIg0KKFdXKSBUaGUgZGlyZWN0b3J5ICIvdXNyL1gxMVI2L2xp
Yi9YMTEvZm9udHMvVHlwZTEvIiBkb2VzIG5vdCBleGlzdC4NCglFbnRyeSBk
ZWxldGVkIGZyb20gZm9udCBwYXRoLg0KKFdXKSBUaGUgZGlyZWN0b3J5ICIv
dXNyL1gxMVI2L2xpYi9YMTEvZm9udHMvU3BlZWRvLyIgZG9lcyBub3QgZXhp
c3QuDQoJRW50cnkgZGVsZXRlZCBmcm9tIGZvbnQgcGF0aC4NCigqKikgRm9u
dFBhdGggc2V0IHRvICIvdXNyL1gxMVI2L2xpYi9YMTEvZm9udHMvbG9jYWwv
LC91c3IvWDExUjYvbGliL1gxMS9mb250cy9taXNjLywvdXNyL1gxMVI2L2xp
Yi9YMTEvZm9udHMvNzVkcGkvOnVuc2NhbGVkLC91c3IvWDExUjYvbGliL1gx
MS9mb250cy8xMDBkcGkvOnVuc2NhbGVkLC91c3IvWDExUjYvbGliL1gxMS9m
b250cy9DSUQvLC91c3IvWDExUjYvbGliL1gxMS9mb250cy83NWRwaS8sL3Vz
ci9YMTFSNi9saWIvWDExL2ZvbnRzLzEwMGRwaS8iDQooKiopIFJnYlBhdGgg
c2V0IHRvICIvdXNyL1gxMVI2L2xpYi9YMTEvcmdiIg0KKC0tKSB1c2luZyBW
VCBudW1iZXIgNw0KDQooRUUpIE5vIE9TIFBDSSBzdXBwb3J0IGF2YWlsYWJs
ZQ0KKElJKSB2NGwgZHJpdmVyIGZvciBWaWRlbzRMaW51eA0KKElJKSBOZXdw
b3J0OiBkcml2ZXIgZm9yIE5ld3BvcnQgR3JhcGhpY3MgQ2FyZDogWEwNCigq
KikgTmV3cG9ydCgwKTogRGVwdGggOCwgKC0tKSBmcmFtZWJ1ZmZlciBicHAg
OA0KKD09KSBOZXdwb3J0KDApOiBEZWZhdWx0IHZpc3VhbCBpcyBQc2V1ZG9D
b2xvcg0KKD09KSBOZXdwb3J0KDApOiBVc2luZyBnYW1tYSBjb3JyZWN0aW9u
ICgxLjAsIDEuMCwgMS4wKQ0KKC0tKSBOZXdwb3J0KDApOiBOZXdwb3J0IEdy
YXBoaWNzIEJvYXJkIHJldmlzaW9uIDYsIGNtYXAgcmV2aXNpb24gRA0KKC0t
KSBOZXdwb3J0KDApOiBOZXdwb3J0IGhhcyA4IGJpdHBsYW5lcw0KKD09KSBO
ZXdwb3J0KDApOiBVc2luZyBTVyBjdXJzb3INCihJSSkgTmV3cG9ydCgwKTog
U0dJIEdETTE3ZTExOiBVc2luZyBoc3luYyByYW5nZSBvZiAgMzAuMDAtIDgy
LjAwIGtIeg0KKElJKSBOZXdwb3J0KDApOiBTR0kgR0RNMTdlMTE6IFVzaW5n
IHZyZWZyZXNoIHJhbmdlIG9mICA1MC4wMC0xMjAuMDAgSHoNCihJSSkgTmV3
cG9ydCgwKTogQ2xvY2sgcmFuZ2U6ICAxMC4wMCB0byAzMDAuMDAgTUh6DQoo
V1cpIE5ld3BvcnQoMCk6IE1vZGUgIjEyODB4OTYwIiBkZWxldGVkIChoc3lu
YyBvdXQgb2YgcmFuZ2UpDQooV1cpIE5ld3BvcnQoMCk6IE1vZGUgIjEyODB4
MTAyNCIgZGVsZXRlZCAoaHN5bmMgb3V0IG9mIHJhbmdlKQ0KKFdXKSBOZXdw
b3J0KDApOiBNb2RlICIxNjAweDEyMDAiIGRlbGV0ZWQgKGluc3VmZmljaWVu
dCBtZW1vcnkgZm9yIG1vZGUpDQooV1cpIE5ld3BvcnQoMCk6IE1vZGUgIjE2
MDB4MTIwMCIgZGVsZXRlZCAoaW5zdWZmaWNpZW50IG1lbW9yeSBmb3IgbW9k
ZSkNCihXVykgTmV3cG9ydCgwKTogTW9kZSAiMTYwMHgxMjAwIiBkZWxldGVk
IChpbnN1ZmZpY2llbnQgbWVtb3J5IGZvciBtb2RlKQ0KKFdXKSBOZXdwb3J0
KDApOiBNb2RlICIxNjAweDEyMDAiIGRlbGV0ZWQgKGluc3VmZmljaWVudCBt
ZW1vcnkgZm9yIG1vZGUpDQooV1cpIE5ld3BvcnQoMCk6IE1vZGUgIjE2MDB4
MTIwMCIgZGVsZXRlZCAoaW5zdWZmaWNpZW50IG1lbW9yeSBmb3IgbW9kZSkN
CihXVykgTmV3cG9ydCgwKTogTW9kZSAiMTc5MngxMzQ0IiBkZWxldGVkIChp
bnN1ZmZpY2llbnQgbWVtb3J5IGZvciBtb2RlKQ0KKFdXKSBOZXdwb3J0KDAp
OiBNb2RlICIxNzkyeDEzNDQiIGRlbGV0ZWQgKGluc3VmZmljaWVudCBtZW1v
cnkgZm9yIG1vZGUpDQooV1cpIE5ld3BvcnQoMCk6IE1vZGUgIjE4NTZ4MTM5
MiIgZGVsZXRlZCAoaW5zdWZmaWNpZW50IG1lbW9yeSBmb3IgbW9kZSkNCihX
VykgTmV3cG9ydCgwKTogTW9kZSAiMTg1NngxMzkyIiBkZWxldGVkIChpbnN1
ZmZpY2llbnQgbWVtb3J5IGZvciBtb2RlKQ0KKFdXKSBOZXdwb3J0KDApOiBN
b2RlICIxOTIweDE0NDAiIGRlbGV0ZWQgKGluc3VmZmljaWVudCBtZW1vcnkg
Zm9yIG1vZGUpDQooV1cpIE5ld3BvcnQoMCk6IE1vZGUgIjE5MjB4MTQ0MCIg
ZGVsZXRlZCAoaW5zdWZmaWNpZW50IG1lbW9yeSBmb3IgbW9kZSkNCigtLSkg
TmV3cG9ydCgwKTogVmlydHVhbCBzaXplIGlzIDEyODB4MTAyNCAocGl0Y2gg
MTI4MCkNCigqKikgTmV3cG9ydCgwKTogRGVmYXVsdCBtb2RlICIxMjgweDEw
MjQiOiAxMzUuMCBNSHosIDgwLjAga0h6LCA3NS4wIEh6DQooPT0pIE5ld3Bv
cnQoMCk6IERQSSBzZXQgdG8gKDc1LCA3NSkNCig9PSkgTmV3cG9ydCgwKTog
QmFja2luZyBzdG9yZSBkaXNhYmxlZA0KKFdXKSBOZXdwb3J0KDApOiBPcHRp
b24gIlNpbGtlbm1vdXNlIiBpcyBub3QgdXNlZA0KUEVYRXh0ZW5zaW9uSW5p
dDogQ291bGRuJ3Qgb3BlbiBkZWZhdWx0IFBFWCBmb250IGZpbGUgIFJvbWFu
X00NCigqKikgTW91c2UxOiBQcm90b2NvbDogIlBTLzIiDQooKiopIE1vdXNl
MTogQ29yZSBQb2ludGVyDQooPT0pIE1vdXNlMTogQnV0dG9uczogMw0KKElJ
KSBLZXlib2FyZCAiS2V5Ym9hcmQxIiBoYW5kbGVkIGJ5IGxlZ2FjeSBkcml2
ZXINCihJSSkgWElOUFVUOiBBZGRpbmcgZXh0ZW5kZWQgaW5wdXQgZGV2aWNl
ICJNb3VzZTEiICh0eXBlOiBNT1VTRSkNCg0K
--8323328-1100244579-967044400=:16640--

From owner-linux-mips@oss.sgi.com Wed Aug 23 13:01:26 2000
Received:  by oss.sgi.com id <S42353AbQHWUBQ>;
	Wed, 23 Aug 2000 13:01:16 -0700
Received: from sgigate.SGI.COM ([204.94.209.1]:2091 "EHLO gate-sgigate.sgi.com")
	by oss.sgi.com with ESMTP id <S42333AbQHWUAn>;
	Wed, 23 Aug 2000 13:00:43 -0700
Received: (ralf@lappi) by lappi.waldorf-gmbh.de id <S868972AbQHWT45>;
        Wed, 23 Aug 2000 12:56:57 -0700
Date:   Wed, 23 Aug 2000 12:56:57 -0700
From:   Ralf Baechle <ralf@oss.sgi.com>
To:     Kanoj Sarcar <kanoj@oss.sgi.com>
Cc:     linux-mips@oss.sgi.com
Subject: Re: CVS Update@oss.sgi.com: linux
Message-ID: <20000823125657.A1008@bacchus.dhis.org>
References: <20000823172400Z42326-31375+197@oss.sgi.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0.1i
In-Reply-To: <20000823172400Z42326-31375+197@oss.sgi.com>; from kanoj@oss.sgi.com on Wed, Aug 23, 2000 at 10:23:50AM -0700
X-Accept-Language: de,en,fr
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing
Content-Length: 389
Lines: 11

On Wed, Aug 23, 2000 at 10:23:50AM -0700, Kanoj Sarcar wrote:

> Log message:
> 	Make prom_printf() functional on IP27s. And prom_printf() is not an
> 	init function, it needs to be around during regular system usage.

On my system after the first TLB flush all PROM functions are no longer
usable since the function pointer point to mapped space.  Similar for
other ARC machines.

  Ralf

From owner-linux-mips@oss.sgi.com Wed Aug 23 16:15:18 2000
Received:  by oss.sgi.com id <S42327AbQHWXPI>;
	Wed, 23 Aug 2000 16:15:08 -0700
Received: from pneumatic-tube.sgi.com ([204.94.214.22]:15709 "EHLO
        pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP
	id <S42324AbQHWXOp>; Wed, 23 Aug 2000 16:14:45 -0700
Received: from google.engr.sgi.com (google.engr.sgi.com [163.154.10.145]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id QAA01181; Wed, 23 Aug 2000 16:20:32 -0700 (PDT)
	mail_from (kanoj@google.engr.sgi.com)
Received: (from kanoj@localhost)
	by google.engr.sgi.com (SGI-8.9.3/8.9.3) id QAA92824;
	Wed, 23 Aug 2000 16:12:58 -0700 (PDT)
From:   Kanoj Sarcar <kanoj@google.engr.sgi.com>
Message-Id: <200008232312.QAA92824@google.engr.sgi.com>
Subject: Re: CVS Update@oss.sgi.com: linux
To:     ralf@oss.sgi.com (Ralf Baechle)
Date:   Wed, 23 Aug 2000 16:12:58 -0700 (PDT)
Cc:     kanoj@oss.sgi.com (Kanoj Sarcar), linux-mips@oss.sgi.com
In-Reply-To: <20000823125657.A1008@bacchus.dhis.org> from "Ralf Baechle" at Aug 23, 2000 12:56:57 PM
X-Mailer: ELM [version 2.5 PL2]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing
Content-Length: 649
Lines: 20

> 
> On Wed, Aug 23, 2000 at 10:23:50AM -0700, Kanoj Sarcar wrote:
> 
> > Log message:
> > 	Make prom_printf() functional on IP27s. And prom_printf() is not an
> > 	init function, it needs to be around during regular system usage.
> 
> On my system after the first TLB flush all PROM functions are no longer
> usable since the function pointer point to mapped space.  Similar for
> other ARC machines.
> 
>   Ralf
> 

I can see how the IP27 can have access to prom functions after init.
Not sure how arc behaves on other machines, but I guess if you really
wanted to use arc prom functions after init, you could take steps to
ensure that ...

Kanoj

From owner-linux-mips@oss.sgi.com Thu Aug 24 00:32:39 2000
Received:  by oss.sgi.com id <S42346AbQHXHc3>;
	Thu, 24 Aug 2000 00:32:29 -0700
Received: from pneumatic-tube.sgi.com ([204.94.214.22]:55305 "EHLO
        pneumatic-tube.sgi.com") by oss.sgi.com with ESMTP
	id <S42285AbQHXHcG>; Thu, 24 Aug 2000 00:32:06 -0700
Received: from cthulhu.engr.sgi.com (gate3-relay.engr.sgi.com [130.62.1.234]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id AAA00029
	for <linux-mips@oss.sgi.com>; Thu, 24 Aug 2000 00:37:53 -0700 (PDT)
	mail_from (agx@gandalf.physik.uni-konstanz.de)
Received: from sgi.com (sgi.engr.sgi.com [192.26.80.37])
	by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF)
	via ESMTP id AAA93347
	for <linux@cthulhu.engr.sgi.com>;
	Thu, 24 Aug 2000 00:31:19 -0700 (PDT)
	mail_from (agx@gandalf.physik.uni-konstanz.de)
Received: from gandalf.physik.uni-konstanz.de (gandalf.physik.uni-konstanz.de [134.34.144.30]) 
	by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam:
       SGI does not authorize the use of its proprietary
       systems or networks for unsolicited or bulk email
       from the Internet.) 
	via ESMTP id AAA04923
	for <linux@cthulhu.engr.sgi.com>; Thu, 24 Aug 2000 00:31:16 -0700 (PDT)
	mail_from (agx@gandalf.physik.uni-konstanz.de)
Received: from bilbo.physik.uni-konstanz.de [134.34.144.31] 
	by gandalf.physik.uni-konstanz.de with esmtp (Exim 2.05 #1 (Debian))
	id 13RrTT-00048W-00; Thu, 24 Aug 2000 09:30:55 +0200
Received: from agx by bilbo.physik.uni-konstanz.de with local (Exim 2.05 #1 (Debian))
	id 13RrTT-0007p6-00; Thu, 24 Aug 2000 09:30:55 +0200
Date:   Thu, 24 Aug 2000 09:30:55 +0200
From:   Guido Guenther <guido.guenther@gmx.net>
To:     Gabriel Nava Vazquez <gnava@sirio.tecmor.mx>
Cc:     linux@cthulhu.engr.sgi.com
Subject: Re: XFree86 in Indy
Message-ID: <20000824093055.B30018@bilbo.physik.uni-konstanz.de>
Mail-Followup-To: Gabriel Nava Vazquez <gnava@sirio.tecmor.mx>,
	linux@cthulhu.engr.sgi.com
References: <Pine.LNX.4.21.0008231031450.16640-200000@sirio.tecmor.mx>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
User-Agent: Mutt/1.0i
In-Reply-To: <Pine.LNX.4.21.0008231031450.16640-200000@sirio.tecmor.mx>; from gnava@sirio.tecmor.mx on Wed, Aug 23, 2000 at 10:33:48AM -0500
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing
Content-Length: 738
Lines: 27

Try adding:
Option     "shadowfb" "yes"
to the device section of your XF86Config file.
 -- Guido

On Wed, Aug 23, 2000 at 10:33:48AM -0500, Gabriel Nava Vazquez wrote:
> 
> Hello
> 
> I have linux installed in an Indy and i installed XFree86 following
> all the instructions.
> 
> When i execute xinit or startx, everything seems to be ok, the display
> jumps to tty7 but there is not image.  If i check the terminal from i
> executed x11, there is no messages about errors, and if y do a ps x, 
> there are all the process alive (x, xterm, etc).
> 
> Can you help me? Do you have any experience with the xserver?
> 
> Thanks
> 
> Ing. Gabriel Nava
> Instituto Tecnologico de Morelia, 
> Mexico

-- 
GPG-Public Key: finger agx@debian.org

From owner-linux-mips@oss.sgi.com Fri Aug 25 02:04:55 2000
Received:  by oss.sgi.com id <S42311AbQHYJEg>;
	Fri, 25 Aug 2000 02:04:36 -0700
Received: from delta.ds2.pg.gda.pl ([153.19.144.1]:58763 "EHLO
        delta.ds2.pg.gda.pl") by oss.sgi.com with ESMTP id <S42304AbQHYJEF>;
	Fri, 25 Aug 2000 02:04:05 -0700
Received: from localhost by delta.ds2.pg.gda.pl (8.9.3/8.9.3) with SMTP id LAA08056;
	Fri, 25 Aug 2000 11:02:58 +0200 (MET DST)
Date:   Fri, 25 Aug 2000 11:02:57 +0200 (MET DST)
From:   "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
To:     linux-mips@fnet.fr, linux-mips@oss.sgi.com
cc:     Arnaldo Carvalho de Melo <acme@conectiva.com.br>
Subject: [PATCH] dz.c: cleanups, getting rid of panic and suser (fwd)
Message-ID: <Pine.GSO.3.96.1000825110048.7175B-100000@delta.ds2.pg.gda.pl>
Organization: Technical University of Gdansk
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing
Content-Length: 5573
Lines: 187

Hi,

 Here is what I got from linux-kernel today.  I thought someone might be
interested.

  Maciej

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

---------- Forwarded message ----------
Message-ID: <20000824194303.B3047@conectiva.com.br>
Date: Thu, 24 Aug 2000 19:43:03 -0300
From: Arnaldo Carvalho de Melo <acme@conectiva.com.br>
To: "Olivier A.D.Lebaillif" <olivier.lebaillif@ifrsys.com>
Cc: linux-kernel@vger.kernel.org
Subject: [PATCH] dz.c: cleanups, getting rid of panic and suser

Hi,

   Please take a look and consider applying.

                        - Arnaldo

--- linux-2.4.0-test7/drivers/char/dz.c	Mon Jun 26 22:03:05 2000
+++ linux-2.4.0-test7.acme/drivers/char/dz.c	Thu Aug 24 19:41:53 2000
@@ -17,6 +17,10 @@
  *  
  * Parts (C) 1999 David Airlie, airlied@linux.ie 
  * [07-SEP-99] Bugfixes 
+ *
+ * Arnaldo Carvalho de Melo <acme@conectiva.com.br> 08/23/2000
+ * - get rid of verify_area, panics and suser, using !capable(CAP_SYS_ADMIN) now
+ * - include missing restore_flags in dz_init
  */
 
 #define DEBUG_DZ 1
@@ -844,14 +848,16 @@
   struct dz_serial old_info;
   int retval = 0;
 
+  if (!capable(CAP_SYS_ADMIN))
+    return -EPERM;
+
   if (!new_info)
     return -EFAULT;
 
-  copy_from_user (&new_serial, new_info, sizeof(new_serial));
-  old_info = *info;
+  if (copy_from_user(&new_serial, new_info, sizeof(new_serial)))
+	  return -EFAULT;
 
-  if (!suser())
-    return -EPERM;
+  old_info = *info;
 
   if (info->count > 1)
     return -EBUSY;
@@ -919,7 +925,6 @@
 
 static int dz_ioctl (struct tty_struct *tty, struct file *file, unsigned int cmd, unsigned long arg)
 {
-  int error;
   struct dz_serial * info = (struct dz_serial *)tty->driver_data;
   int retval;
 
@@ -949,40 +954,30 @@
     return 0;
 
   case TIOCGSOFTCAR:
-    error = verify_area (VERIFY_WRITE, (void *)arg, sizeof(long));
-    if (error)
-      return error;
-    put_user (C_CLOCAL(tty) ? 1 : 0, (unsigned long *)arg);
-    return 0;
+    return put_user (C_CLOCAL(tty) ? 1 : 0, (unsigned long *)arg);
 
   case TIOCSSOFTCAR:
-    error = get_user (arg, (unsigned long *)arg);
-    if (error)
-      return error;
+    if (get_user (arg, (unsigned long *)arg))
+	    return -EFAULT;
     tty->termios->c_cflag = ((tty->termios->c_cflag & ~CLOCAL) | (arg ? CLOCAL : 0));
     return 0;
 
   case TIOCGSERIAL:
-    error = verify_area (VERIFY_WRITE, (void *)arg, sizeof(struct serial_struct));
-    if (error)
-      return error;
+    if (verify_area (VERIFY_WRITE, (void *)arg, sizeof(struct serial_struct)))
+	    return -EFAULT;
     return get_serial_info (info, (struct serial_struct *)arg);
 
   case TIOCSSERIAL:
     return set_serial_info (info, (struct serial_struct *) arg);
 
   case TIOCSERGETLSR: /* Get line status register */
-    error = verify_area (VERIFY_WRITE, (void *)arg, sizeof(unsigned int));
-    if (error)
-      return error;
-    else
-      return get_lsr_info (info, (unsigned int *)arg);
+    if (verify_area (VERIFY_WRITE, (void *)arg, sizeof(unsigned int)))
+	    return -EFAULT;
+    return get_lsr_info (info, (unsigned int *)arg);
 
   case TIOCSERGSTRUCT:
-    error = verify_area (VERIFY_WRITE, (void *)arg, sizeof(struct dz_serial));
-    if (error)
-      return error;
-    copy_to_user((struct dz_serial *)arg, info, sizeof(struct dz_serial));
+    if (copy_to_user((struct dz_serial *)arg, info, sizeof(struct dz_serial)))
+	    return -EFAULT;
     return 0;
     
   default:
@@ -1290,7 +1285,7 @@
 
 int __init dz_init(void)
 {
-  int i, flags;
+  int i, flags, ret;
   struct dz_serial *info;
 
   /* Setup base handler, and timer table. */
@@ -1340,10 +1335,16 @@
   callout_driver.major = TTYAUX_MAJOR;
   callout_driver.subtype = SERIAL_TYPE_CALLOUT;
 
-  if (tty_register_driver (&serial_driver))
-    panic("Couldn't register serial driver\n");
-  if (tty_register_driver (&callout_driver))
-    panic("Couldn't register callout driver\n");
+  ret = tty_register_driver (&serial_driver);
+  if (ret) {
+	printk(KERN_ERR "Couldn't register serial driver\n");
+	return ret;
+  }
+  ret = tty_register_driver (&callout_driver);
+  if (ret) {
+	printk(KERN_ERR "Couldn't register callout driver\n");
+	goto cleanup_serial_driver;
+  }
   save_flags(flags); cli();
  
   for (i=0; i < DZ_NB_PORT;  i++)  
@@ -1376,8 +1377,10 @@
 
     /* If we are pointing to address zero then punt - not correctly
        set up in setup.c to handle this. */
-    if (! info->port)
+    if (!info->port) {
+      restore_flags(flags);
       return 0;
+    }
 
     printk("ttyS%02d at 0x%04x (irq = %d)\n", info->line, info->port, SERIAL);
   }
@@ -1396,12 +1399,17 @@
      is updated... in request_irq - to immediatedly obliterate
      it is unwise. */
   restore_flags(flags);
- 
 
-  if (request_irq (SERIAL, dz_interrupt, SA_INTERRUPT, "DZ", lines[0]))
-    panic ("Unable to register DZ interrupt\n");
+  if (request_irq (SERIAL, dz_interrupt, SA_INTERRUPT, "DZ", lines[0])) {
+    printk(KERN_ERR "Unable to register DZ interrupt\n");
+    ret = -EBUSY;
+    goto cleanup_callout_driver;
+  }
  
   return 0;
+cleanup_callout_driver:	tty_unregister_driver(&callout_driver);
+cleanup_serial_driver:	tty_unregister_driver(&serial_driver);
+  return ret;
 }
 
 #ifdef CONFIG_SERIAL_CONSOLE
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/


From owner-linux-mips@oss.sgi.com Fri Aug 25 13:20:18 2000
Received:  by oss.sgi.com id <S42339AbQHYUUI>;
	Fri, 25 Aug 2000 13:20:08 -0700
Received: from noose.gt.owl.de ([62.52.19.4]:41740 "HELO noose.gt.owl.de")
	by oss.sgi.com with SMTP id <S42310AbQHYUTf>;
	Fri, 25 Aug 2000 13:19:35 -0700
Received: by noose.gt.owl.de (Postfix, from userid 10)
	id 0E30A80E; Fri, 25 Aug 2000 22:22:35 +0200 (CEST)
Received: by paradigm.rfc822.org (Postfix, from userid 1000)
	id 23BBF8FF5; Fri, 25 Aug 2000 22:16:20 +0200 (CEST)
Date:   Fri, 25 Aug 2000 22:16:20 +0200
From:   Florian Lohoff <flo@rfc822.org>
To:     linux-mips@oss.sgi.com
Subject: no controlling tty on mipsel
Message-ID: <20000825221620.A1280@paradigm.rfc822.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
User-Agent: Mutt/1.0.1i
Organization: rfc822 - pure communication
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing
Content-Length: 496
Lines: 22

Hi,
with the declinux root and the glibc 2.0.6-5lm (Current rpm)
i get the following error on BOTH decstations i have up and
running (Both R4000)

[flo@reconfig most]$ scp *.deb *.changes root@repeat.rfc822.org:/ftp.rfc822.org/packages
You have no controlling tty.  Cannot read passphrase.

lost connection

[flo@reconfig most]$ tty
/dev/ttyp0

Hmmm ... 

Ideas ?

Flo
-- 
Florian Lohoff		flo@rfc822.org		      	+49-5201-669912
      "Write only memory - Oops. Time for my medication again ..."


From owner-linux-mips@oss.sgi.com Fri Aug 25 15:41:11 2000
Received:  by oss.sgi.com id <S42349AbQHYWlB>;
	Fri, 25 Aug 2000 15:41:01 -0700
Received: from gatekeep.ti.com ([192.94.94.61]:50081 "EHLO gatekeep.ti.com")
	by oss.sgi.com with ESMTP id <S42310AbQHYWkg>;
	Fri, 25 Aug 2000 15:40:36 -0700
Received: from dlep7.itg.ti.com ([157.170.134.103])
	by gatekeep.ti.com (8.11.0/8.11.0) with ESMTP id e7PMdkD20982
	for <linux-mips@oss.sgi.com>; Fri, 25 Aug 2000 17:39:46 -0500 (CDT)
Received: from dlep7.itg.ti.com (localhost [127.0.0.1])
	by dlep7.itg.ti.com (8.9.3/8.9.3) with ESMTP id RAA03998
	for <linux-mips@oss.sgi.com>; Fri, 25 Aug 2000 17:39:38 -0500 (CDT)
Received: from dlep4.itg.ti.com (dlep4.itg.ti.com [157.170.188.63])
	by dlep7.itg.ti.com (8.9.3/8.9.3) with ESMTP id RAA03994
	for <linux-mips@oss.sgi.com>; Fri, 25 Aug 2000 17:39:38 -0500 (CDT)
Received: from ti.com (reddwarf.sc.ti.com [158.218.100.143])
	by dlep4.itg.ti.com (8.9.3/8.9.3) with ESMTP id RAA04323
	for <linux-mips@oss.sgi.com>; Fri, 25 Aug 2000 17:39:45 -0500 (CDT)
Message-ID: <39A6F826.D444E0@ti.com>
Date:   Fri, 25 Aug 2000 16:50:15 -0600
From:   Jeff Harrell <jharrell@ti.com>
X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14-5.0 i686)
X-Accept-Language: en
MIME-Version: 1.0
To:     linux-mips@oss.sgi.com
Subject: Question concerning discontinuities in memory map.
Content-Type: multipart/mixed;
 boundary="------------E8D716CD92D021741AC0D7DA"
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing
Content-Length: 6652
Lines: 164

This is a multi-part message in MIME format.
--------------E8D716CD92D021741AC0D7DA
Content-Type: multipart/alternative;
 boundary="------------BC3CC499A711E3C100153003"


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

I have a question concerning a discontinuity in my memory map.  The
development board that I am
working on currently has the start of its SDRAM at 0x14000000 (physical
memory).  It looks like a
lot of the code is written under the assumption that the base of the
kernel will be at 0x80000000.  I
have had to modify several sections of code to handle this discontinuity
with respect to max_low_pfn,
high_memory, num_physpages  max_mapnr, and low (/arch/mips/mm/init.c).
These variables seem
to use the PAGE_SHIFT variable to locate the start of that page in
physical memory: (e.g.,   max_mapnr
<< PAGE_SHIFT).  It looks like a lot of the problem stems from
max_low_pfn.  In init_bootmem_core:

----8<  snippet from init_bootmem_core ( mm/bootmem.c) 8<----------

     static unsigned long __init init_bootmem_core (bootmem_data_t
     *bdata,
               unsigned long mapstart, unsigned long start,
     unsigned long end)
       {
               unsigned long mapsize = ((end - start)+7)/8;

               mapsize = (mapsize + (sizeof(long) - 1UL)) &
     ~(sizeof(long) - 1UL);
               bdata->node_bootmem_map = phys_to_virt(mapstart <<
     PAGE_SHIFT);
               bdata->node_boot_start = (start << PAGE_SHIFT);
               bdata->node_low_pfn = end;
       ...

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

the mapsize is defined by end-start, where start is the _end
(kernel_end) + bootmap_size.
therefore it looks like end should represent the end of memory (i.e.
SDRAM).  In our case
this is 0x15FFFFFF (i.e. 32M).  If I let the rest of the kernel process
max_low_pfn and the
associated variable normally,  the paging routines will calculate that I
have 335M of memory!
I seem to be chasing this problem through the kernel.  Is there a
central place in the code that
would handle the offset properly?  I don't think I have caught all of
the implications of this change
yet because I am still failing in the paging routines.  Any information
that is available on how this
can be accomplished would be greatly appreciated.

Thanks,
Jeff

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



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

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
I have a question concerning a discontinuity in my memory map.&nbsp; The
development board that I am
<br>working on currently has the start of its SDRAM at 0x14000000 (physical
memory).&nbsp; It looks like a
<br>lot of the code is written under the assumption that the base of the
kernel will be at 0x80000000.&nbsp; I
<br>have had to modify several sections of code to handle this discontinuity
with respect to max_low_pfn,
<br>high_memory, num_physpages&nbsp; max_mapnr, and low (/arch/mips/mm/init.c).&nbsp;
These variables seem
<br>to use the PAGE_SHIFT variable to locate the start of that page in
physical memory: (e.g.,&nbsp;&nbsp; max_mapnr
<br>&lt;&lt; PAGE_SHIFT).&nbsp; It looks like a lot of the problem stems
from max_low_pfn.&nbsp; In init_bootmem_core:
<p>----8&lt;&nbsp; snippet from init_bootmem_core ( mm/bootmem.c) 8&lt;----------
<blockquote><font size=-1>static unsigned long __init init_bootmem_core
(bootmem_data_t *bdata,</font>
<br><font size=-1>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
unsigned long mapstart, unsigned long start, unsigned long end)</font>
<br><font size=-1>&nbsp; {</font>
<br><font size=-1>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
unsigned long mapsize = ((end - start)+7)/8;</font>
<br><font size=-1>&nbsp;</font>
<br><font size=-1>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
mapsize = (mapsize + (sizeof(long) - 1UL)) &amp; ~(sizeof(long) - 1UL);</font>
<br><font size=-1>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
bdata->node_bootmem_map = phys_to_virt(mapstart &lt;&lt; PAGE_SHIFT);</font>
<br><font size=-1>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
bdata->node_boot_start = (start &lt;&lt; PAGE_SHIFT);</font>
<br><font size=-1>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
bdata->node_low_pfn = end;</font>
<br><font size=-1>&nbsp; ...</font></blockquote>
----------------------------------------------------
<p>the mapsize is defined by end-start, where start is the _end (kernel_end)
+ bootmap_size.
<br>therefore it looks like end should represent the end of memory (i.e.
SDRAM).&nbsp; In our case
<br>this is 0x15FFFFFF (i.e. 32M).&nbsp; If I let the rest of the kernel
process max_low_pfn and the
<br>associated variable normally,&nbsp; the paging routines will calculate
that I have 335M of memory!
<br>I seem to be chasing this problem through the kernel.&nbsp; Is there
a central place in the code that
<br>would handle the offset properly?&nbsp; I don't think I have caught
all of the implications of this change
<br>yet because I am still failing in the paging routines.&nbsp; Any information
that is available on how this
<br>can be accomplished would be greatly appreciated.
<p>Thanks,
<br>Jeff
<pre>--&nbsp;
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Jeff Harrell&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Work:&nbsp; (801) 619-6104&nbsp;
Broadband Access group/TI&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Cell:&nbsp; (801) 597-6268&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
jharrell@ti.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~</pre>
&nbsp;</html>

--------------BC3CC499A711E3C100153003--

--------------E8D716CD92D021741AC0D7DA
Content-Type: text/x-vcard; charset=us-ascii;
 name="jharrell.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Jeff Harrell
Content-Disposition: attachment;
 filename="jharrell.vcf"

begin:vcard 
n:Harrell;Jeff
tel;cell:(801) 597-6268
tel;fax:(801) 619-6150
tel;work:(801) 619-6104
x-mozilla-html:TRUE
url:http://www.ti.com
org:Broadband Access Group
version:2.1
email;internet:jharrell@ti.com
title:Texas Instruments
adr;quoted-printable:;;170 West Election Rd. Suite 100	=0D=0AMS 4106		;Draper;Utah;84020-6410;USA
x-mozilla-cpt:;0
fn:Jeff Harrell
end:vcard

--------------E8D716CD92D021741AC0D7DA--


From owner-linux-mips@oss.sgi.com Sat Aug 26 13:08:00 2000
Received:  by oss.sgi.com id <S42228AbQHZUHu>;
	Sat, 26 Aug 2000 13:07:50 -0700
Received: from noose.gt.owl.de ([62.52.19.4]:2833 "HELO noose.gt.owl.de")
	by oss.sgi.com with SMTP id <S42225AbQHZUHR>;
	Sat, 26 Aug 2000 13:07:17 -0700
Received: by noose.gt.owl.de (Postfix, from userid 10)
	id 14833822; Sat, 26 Aug 2000 22:10:27 +0200 (CEST)
Received: by paradigm.rfc822.org (Postfix, from userid 1000)
	id 802E38FF5; Sat, 26 Aug 2000 22:06:08 +0200 (CEST)
Date:   Sat, 26 Aug 2000 22:06:08 +0200
From:   Florian Lohoff <flo@rfc822.org>
To:     linux-mips@oss.sgi.com
Subject: decstation boot loader
Message-ID: <20000826220608.J3009@paradigm.rfc822.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
User-Agent: Mutt/1.0.1i
Organization: rfc822 - pure communication
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing
Content-Length: 1458
Lines: 36

Hi,
i sat down a couple of hours and had a look at current possibilities
of booting the decstations from HD. I am not much further than
i was was before - And now i got a couple of questions probably one
of the more specialised mips hackers might answer.

- The bootblock of the decstation might contain up to 51 extents
  to load from the disks.

  1. Do these extents refer to the start of the disk or the start
     of the probably first partition.

  2. Do i have to set a checksum in the bootblock or does the checksom
     only apply to the disklabel

  3. What binarys is the bootloader able to load. From the BSD sources
     i guess its only raw instructions.

  4. Does the MS-DOS disklabel and the DEC bootblock interfer in any
     kind that its impossible to have a diskloader with MS-DOS Disklabels 

I rewrote the bootprep.c today to play around with loading different binarys.
I added the honor of partition information meaning - The new (i call
it writeboot) looks at the start of the partition and calculates
the extents relativ to the start of the disk. But still i dont get any
results. When trying to boot those partitions with any kind of combination
the prompt only returns to the prom command line.

I thought of a bootloader much like the silo - Capable of reading
an ext2 filesystem via libext2 etc.

Flo
-- 
Florian Lohoff		flo@rfc822.org		      	+49-5201-669912
      "Write only memory - Oops. Time for my medication again ..."


From owner-linux-mips@oss.sgi.com Sun Aug 27 05:55:55 2000
Received:  by oss.sgi.com id <S42254AbQH0Mzq>;
	Sun, 27 Aug 2000 05:55:46 -0700
Received: from noose.gt.owl.de ([62.52.19.4]:33811 "HELO noose.gt.owl.de")
	by oss.sgi.com with SMTP id <S42253AbQH0MzU>;
	Sun, 27 Aug 2000 05:55:20 -0700
Received: by noose.gt.owl.de (Postfix, from userid 10)
	id 5B74F826; Sun, 27 Aug 2000 14:58:34 +0200 (CEST)
Received: by paradigm.rfc822.org (Postfix, from userid 1000)
	id E21678FF5; Sun, 27 Aug 2000 14:54:13 +0200 (CEST)
Date:   Sun, 27 Aug 2000 14:54:13 +0200
From:   Florian Lohoff <flo@rfc822.org>
To:     linux-mips@oss.sgi.com
Subject: Decstation 5000/150 hangs in Delayloop (2.4.0-test6)
Message-ID: <20000827145413.A306@paradigm.rfc822.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
User-Agent: Mutt/1.0.1i
Organization: rfc822 - pure communication
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing
Content-Length: 1810
Lines: 52


Hi,
i think something broke between 2.4.0-test3-pre7 and 2.4.0-test6
for the Decstation 5000/150 - The Register DUMP is of the
Prom when i pressed reset.

The same kernel Image works fine on my Decstation 5000/260 which
is an R4400 instead of R4000.

BTW: 2.4.0-test6-pre8 oopses after SCSI 

-------------------------------------------------------------------
KN04 V2.1k    (PC: 0xbfc0075c, SP: 0x83739de8)

This DECstation is a DS5000/1xx
Loading R4000 MMU routines.
CPU revision is: 00000430
Primary instruction cache 8kb, linesize 16 bytes.
Primary data cache 8kb, linesize 16 bytes.
Secondary cache sized at 1024K linesize 32 bytes.
Linux version 2.4.0-test6 (flo@slimer.rfc822.org) (gcc version egcs-2.90.29 980515 (egcs-1.0.3 release)) #3 Sun Aug 27 10:37:34 GMT 2000
On node 0 totalpages: 16384
zone(0): 16384 pages.
zone(1): 0 pages.
zone(2): 0 pages.
Kernel command line: root=/dev/sda2 console=ttyS2
Calibrating delay loop... 
???
? PC:  0xbfc0075c <vtr=NMI/SR>
? CR:  0x00000000 <CE=0,EXC=INT>
? SR:  0x00510006 <BEV,SR,DE,IPL=8,MODE=KNL,ERL,EXL>
? CFG: 0x00410242 <SB=8W,SC=Y,IC=8K,DC=8K,IB=4W,DB=4W,K0=UNC>
? 
? MB_CS:  0x003f8000 <FW,MSK=1F,EE,ECC=0>
? MB_INT: 0x101f0000 <>
? 
? SIR:  0x00000001
? SIRM: 0x00000000
? 
? at:0002FF00 a2:000024F6 t3:A0000000 s0:00000008 s5:FFFFFFFF k1:FFFE27FD
? v0:BFDC0000 a3:0000003C t4:00000000 s1:80040584 s6:801683B0 gp:80046000
? v1:00000000 t0:A0015CC4 t5:00000000 s2:FFFFFFFF s7:80047F80 sp:80047F80
? a0:FFFFFFFF t1:A002FF00 t6:8017CDB4 s3:FFFFFFFF t8:00000016 fp:7E7D2BFF
? a1:00000021 t2:FFFFFFFF t7:10012001 s4:FFFFFFFF t9:00000F00 ra:BFC0068C
-----------------------------------------------------------------------


Flo
-- 
Florian Lohoff		flo@rfc822.org		      	+49-5201-669912
      "Write only memory - Oops. Time for my medication again ..."


From owner-linux-mips@oss.sgi.com Sun Aug 27 10:20:38 2000
Received:  by oss.sgi.com id <S42281AbQH0RU2>;
	Sun, 27 Aug 2000 10:20:28 -0700
Received: from mail.ivm.net ([62.204.1.4]:3954 "EHLO mail.ivm.net")
	by oss.sgi.com with ESMTP id <S42253AbQH0RT6>;
	Sun, 27 Aug 2000 10:19:58 -0700
Received: from franz.no.dom (port89.duesseldorf.ivm.de [195.247.65.89])
	by mail.ivm.net (8.8.8/8.8.8) with ESMTP id TAA07373;
	Sun, 27 Aug 2000 19:19:06 +0200
X-To:   linux-mips@oss.sgi.com
Message-ID: <XFMail.000827191949.Harald.Koerfgen@home.ivm.de>
X-Mailer: XFMail 1.4.0 on Linux
X-Priority: 3 (Normal)
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
In-Reply-To: <20000826220608.J3009@paradigm.rfc822.org>
Date:   Sun, 27 Aug 2000 19:19:49 +0200 (CEST)
Reply-To: Harald Koerfgen <Harald.Koerfgen@home.ivm.de>
Organization: none
From:   Harald Koerfgen <Harald.Koerfgen@home.ivm.de>
To:     Florian Lohoff <flo@rfc822.org>
Subject: RE: decstation boot loader
Cc:     linux-mips@oss.sgi.com
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing
Content-Length: 2059
Lines: 52

Hi Flo,

On 26-Aug-00 Florian Lohoff wrote:
> i sat down a couple of hours and had a look at current possibilities
> of booting the decstations from HD. I am not much further than
> i was was before - And now i got a couple of questions probably one
> of the more specialised mips hackers might answer.
> 
> - The bootblock of the decstation might contain up to 51 extents
>   to load from the disks.
>
>   1. Do these extents refer to the start of the disk or the start
>      of the probably first partition.

The PROM knows nothing about partitions or such so these extends refer obviously
to the start of the disk.
 
>   2. Do i have to set a checksum in the bootblock or does the checksom
>      only apply to the disklabel

The PROM doesn't even know anything about a checksum.
 
>   3. What binarys is the bootloader able to load. From the BSD sources
>      i guess its only raw instructions.

Yes. "mipsel-linux-objcopy --output-target=binary" is your friend.
 
>   4. Does the MS-DOS disklabel and the DEC bootblock interfer in any
>      kind that its impossible to have a diskloader with MS-DOS Disklabels 

No, that should work as long as the the the boot map is short enough not to
overwrite the partition information.
 
> I rewrote the bootprep.c today to play around with loading different binarys.
> I added the honor of partition information meaning - The new (i call
> it writeboot) looks at the start of the partition and calculates
> the extents relativ to the start of the disk. But still i dont get any
> results. When trying to boot those partitions with any kind of combination
> the prompt only returns to the prom command line.

I have successfully booted Linux kernels with bootprep. Depending on the code you
want to load, for example a second stage bootloader, you may need to adjust
"boot_block->loadAddr" and "boot_block->execAddr".
 
> I thought of a bootloader much like the silo - Capable of reading
> an ext2 filesystem via libext2 etc.

That's what I always wanted to do but I never found the time...

-- 
Regards,
Harald

From owner-linux-mips@oss.sgi.com Sun Aug 27 10:40:08 2000
Received:  by oss.sgi.com id <S42399AbQH0Rj6>;
	Sun, 27 Aug 2000 10:39:58 -0700
Received: from noose.gt.owl.de ([62.52.19.4]:2573 "HELO noose.gt.owl.de")
	by oss.sgi.com with SMTP id <S42253AbQH0Rjb>;
	Sun, 27 Aug 2000 10:39:31 -0700
Received: by noose.gt.owl.de (Postfix, from userid 10)
	id E130E82E; Sun, 27 Aug 2000 19:42:45 +0200 (CEST)
Received: by paradigm.rfc822.org (Postfix, from userid 1000)
	id 7AA688FF5; Sun, 27 Aug 2000 19:38:20 +0200 (CEST)
Date:   Sun, 27 Aug 2000 19:38:20 +0200
From:   Florian Lohoff <flo@rfc822.org>
To:     Harald Koerfgen <Harald.Koerfgen@home.ivm.de>
Cc:     linux-mips@oss.sgi.com
Subject: Re: decstation boot loader
Message-ID: <20000827193820.B325@paradigm.rfc822.org>
References: <20000826220608.J3009@paradigm.rfc822.org> <XFMail.000827191949.Harald.Koerfgen@home.ivm.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
User-Agent: Mutt/1.0.1i
In-Reply-To: <XFMail.000827191949.Harald.Koerfgen@home.ivm.de>; from Harald.Koerfgen@home.ivm.de on Sun, Aug 27, 2000 at 07:19:49PM +0200
Organization: rfc822 - pure communication
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing
Content-Length: 2211
Lines: 67

On Sun, Aug 27, 2000 at 07:19:49PM +0200, Harald Koerfgen wrote:
> 
> The PROM knows nothing about partitions or such so these extends refer
> obviously to the start of the disk.
> 

Good

> 
> Yes. "mipsel-linux-objcopy --output-target=binary" is your friend.
>  

Even worse ...

Compilation - Relocation - Stripping - 

start.b: start.r
        objcopy --remove-section=.bss \
                --remove-section=.data \
                --remove-section=.reginfo \
                --remove-section=.mdebug \
                --output-target=binary start.r start.b 

start.r: start.o
        ld -Ttext=0x80020000 -Tdata=0x80020000 -Tbss=0x80020000 \
                start.o -o start.r

start.o: start.S        
        gcc -fomit-frame-pointer -G 0 -mno-abicalls -fno-pic -c start.S


> >   4. Does the MS-DOS disklabel and the DEC bootblock interfer in any
> >      kind that its impossible to have a diskloader with MS-DOS Disklabels 
> 
> No, that should work as long as the the the boot map is short enough not to
> overwrite the partition information.
>  

Does that mean that the limit of the boot_map in the bootprep
is arbitrary and the DEC firmware bootloader would continue
read/process boot_maps in the whole first block ?

> I have successfully booted Linux kernels with bootprep. Depending on
> the code you want to load, for example a second stage bootloader, you
> may need to adjust "boot_block->loadAddr" and "boot_block->execAddr".

Yep - I guessed so - loadAddr hasnt changed but i guess execAddr
needs to point to kernel_entry ...

> > I thought of a bootloader much like the silo - Capable of reading
> > an ext2 filesystem via libext2 etc.
> 
> That's what I always wanted to do but I never found the time...

:) - Well see - I got someone else i donated a Decstation to
whom i gave the first goal of writing a boot loader for the donation :)

The problem right now which i have is that i cant seem to load
ANYTHING - Not raw instructions not elf not ecoff - Even simplest
instruction like a tight loop (Wouldnt go back into prom)
dont seem to get executed. 

Flo
-- 
Florian Lohoff		flo@rfc822.org		      	+49-5201-669912
      "Write only memory - Oops. Time for my medication again ..."


From owner-linux-mips@oss.sgi.com Sun Aug 27 12:16:08 2000
Received:  by oss.sgi.com id <S42404AbQH0TP7>;
	Sun, 27 Aug 2000 12:15:59 -0700
Received: from tomts8.bellnexxia.net ([209.226.175.52]:53721 "EHLO
        tomts8-srv.bellnexxia.net") by oss.sgi.com with ESMTP
	id <S42253AbQH0TPg>; Sun, 27 Aug 2000 12:15:36 -0700
Received: from free.fr ([206.172.229.9]) by tomts8-srv.bellnexxia.net
          (InterMail vM.4.01.03.00 201-229-121) with ESMTP
          id <20000827191458.NDZN29984.tomts8-srv.bellnexxia.net@free.fr>;
          Sun, 27 Aug 2000 15:14:58 -0400
Message-ID: <39A93106.A025454E@free.fr>
Date:   Sun, 27 Aug 2000 15:17:26 +0000
From:   Famille Chauvat <famille.chauvat@free.fr>
X-Mailer: Mozilla 4.7 [en] (X11; U; Linux 2.2.9-27mdk i686)
X-Accept-Language: fr-FR, en
MIME-Version: 1.0
To:     Nathan Fraser <ndf@shorts.cx>
CC:     linux-mips@oss.sgi.com
Subject: Re: [Install trouble] : mount failed: bad address
References: <Pine.LNX.4.20.0008101342100.1188-100000@jarre.house>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing
Content-Length: 238
Lines: 10

Hi,

I just finish to install Linux on the Indy and everythings looks
fine...except:

- how can I boot without a DHCP server. When I try to do that, a message
about the boot partition explain that I cannot do this.

Thanks a lot
Philippe

From owner-linux-mips@oss.sgi.com Sun Aug 27 15:36:39 2000
Received:  by oss.sgi.com id <S42405AbQH0WgU>;
	Sun, 27 Aug 2000 15:36:20 -0700
Received: from utenti.global-italianet.it ([194.184.55.137]:61457 "HELO
        server2.global-italianet.it") by oss.sgi.com with SMTP
	id <S42253AbQH0Wf5>; Sun, 27 Aug 2000 15:35:57 -0700
Received: from smtp.indiatimes.com [209.69.67.137] by server2.global-italianet.it
  (SMTPD32-4.04) id AD5B2E0120; Sun, 27 Aug 2000 23:59:39 +03d00
Message-Id: <knvqxu.nvmpxqpxotuxwlmt@smtp.indiatimes.com>
To:     gettripfree3@hotmail.com
Date:   Sun, 27 Aug 2000 17:58:20 -0500
From:   lounis2@yahoo.com
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7BIT
Subject: FREE 3 Day Trip to Paradise & Deluxe Hotel
Reply-To:  lounis2@yahoo.com
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing
Content-Length: 566
Lines: 18

WEALTH IN THE NEW MILLENNIUM

The Internet and new technology are creating more 7 Figure ($1,000,000)
incomes than any time in history.  If you feel you are not being paid
what your worth, please visit our web site.  The information is FREE.

HUGE COMPENSATION AVAILABLE!
This is your chance to get in on the ground floor of the
Multi-Billion-Dollar Home Based Business Revolution.

PLUS, RECEIVE A COMPLIMENTARY GIFT WHEN VISITING OUR WEB SITE.

http://216.199.83.15/ <-- Click Here For FREE Vacation



To Be Removed from out list send email to jaban92@yahoo.com


From owner-linux-mips@oss.sgi.com Mon Aug 28 16:40:13 2000
Received:  by oss.sgi.com id <S42415AbQH1XkE>;
	Mon, 28 Aug 2000 16:40:04 -0700
Received: from saturn.mikemac.com ([216.99.199.88]:18489 "EHLO mikemac.com")
	by oss.sgi.com with ESMTP id <S42401AbQH1Xjf>;
	Mon, 28 Aug 2000 16:39:35 -0700
Received: from Saturn (localhost [127.0.0.1]) by mikemac.com (8.8.7/8.7.3) with ESMTP id QAA00056 for <linux-mips@oss.sgi.com>; Mon, 28 Aug 2000 16:39:04 -0700
Message-Id: <200008282339.QAA00056@mikemac.com>
To:     linux-mips@oss.sgi.com
Subject: PCMCIA memory window
Date:   Mon, 28 Aug 2000 16:39:03 -0700
From:   Mike McDonald <mikemac@mikemac.com>
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing
Content-Length: 240
Lines: 9


  Where should the PCMCIA memory window be mapped to? I have no ISA
bus so the default 0xc0000-0xfffff isn't appropriate. I do have PCI
working and it's mapped at 0xB0000000 to 0xB6000000.

  Thanks,

  Mike McDonald
  mikemac@mikemac.com

From owner-linux-mips@oss.sgi.com Thu Aug 31 15:47:54 2000
Received:  by oss.sgi.com id <S42377AbQHaWrn>;
	Thu, 31 Aug 2000 15:47:43 -0700
Received: from noose.gt.owl.de ([62.52.19.4]:55300 "HELO noose.gt.owl.de")
	by oss.sgi.com with SMTP id <S42238AbQHaWrg>;
	Thu, 31 Aug 2000 15:47:36 -0700
Received: by noose.gt.owl.de (Postfix, from userid 10)
	id 971867F8; Fri,  1 Sep 2000 00:51:42 +0200 (CEST)
Received: by paradigm.rfc822.org (Postfix, from userid 1000)
	id 3E61F8FF5; Fri,  1 Sep 2000 00:46:13 +0200 (CEST)
Date:   Fri, 1 Sep 2000 00:46:13 +0200
From:   Florian Lohoff <flo@rfc822.org>
To:     linux-mips@oss.sgi.com
Subject: crash in r4k_dma_cache_wback_inv_pc on r5k on bootup
Message-ID: <20000901004612.A314@paradigm.rfc822.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
User-Agent: Mutt/1.0.1i
Organization: rfc822 - pure communication
Sender: owner-linux-mips@oss.sgi.com
Precedence: bulk
Return-Path: <owner-linux-mips@oss.sgi.com>
X-Orcpt: rfc822;linux-mips-outgoing
Content-Length: 2809
Lines: 85

Hi,
i just got a System.map and objectdump handy while the r5k crashed :)


Unable to ... at ... 00000008, epc == 880182e4, ra == 88156db0


880182a8:   bcb50000        cache   0x15,0($a1)
880182ac:   14a2fffe        bne     $a1,$v0,880182a8 <r4k_dma_cache_wback_inv_pc+80>
880182b0:   00a42821        addu    $a1,$a1,$a0
880182b4:   40086000        mfc0    $t0,$12
880182b8:   3409ff00        li      $t1,0xff00
880182bc:   01094024        and     $t0,$t0,$t1
880182c0:   00094827        nor     $t1,$zero,$t1
880182c4:   00c93024        and     $a2,$a2,$t1
880182c8:   00c83025        or      $a2,$a2,$t0
880182cc:   40866000        mtc0    $a2,$12
...
880182dc:   3c028819        lui     $v0,0x8819
880182e0:   8c429dc4        lw      $v0,-25148($v0)
880182e4:   8c420008        lw      $v0,8($v0)      <------
880182e8:   02002021        move    $a0,$s0
880182ec:   0040f809        jalr    $v0
880182f0:   02202821        move    $a1,$s1
880182f4:   8fbf0018        lw      $ra,24($sp)
880182f8:   8fb10014        lw      $s1,20($sp)
880182fc:   8fb00010        lw      $s0,16($sp)
88018300:   03e00008        jr      $ra
88018304:   27bd0020        addiu   $sp,$sp,32

It seems "bcops" is at 0x0 which is - aehm - bogus ?

Between 20000601 (Random date) and today r4xx0.c has changed
this way:

---------------------------------------------------------------
-static void no_sc_noop(void) {}
-
-static struct bcache_ops no_sc_ops = {
-       (void *)no_sc_noop, (void *)no_sc_noop,
-       (void *)no_sc_noop, (void *)no_sc_noop
-};
 
-struct bcache_ops *bcops = &no_sc_ops;
+DECLARE_BCOPS;
---------------------------------------------------------------

And DECLARE_BCOPS is defined in include/asm-mips/bcache.h as

---------------------------------------------------------------
#define DECLARE_BCOPS struct bcache_ops *bcops
---------------------------------------------------------------

Which is not the same - There are no "noops" suddenly
and it seems this doesnt get initialized correctly
at all and bcops stays "0" although in the normal
codepath in arch/mips/sgi/kernel/setup.c contains


    255 
    256         /* Now enable boardcaches, if any. */
    257         indy_sc_init();
    258 

Which itself is arm/mips/sgi/kernel/indy_sc.c

    221 void __init indy_sc_init(void)
    222 {
    223         if (indy_sc_probe()) {
    224                 indy_sc_enable();
    225                 bcops = &indy_sc_ops;
    226         }
    227 }

But it doesnt seem indy_sc_probe is "true" for R5k machines.

This might be all of the problem with r5k machines ... We only
ran with the "noop" bcache functions and now the r5k is
not running with any function :)

Flo
-- 
Florian Lohoff		flo@rfc822.org		      	+49-5201-669912
      "Write only memory - Oops. Time for my medication again ..."