installation problem.

installation problem.

[Ulf Carlsson]

Hello, sorry that I'm asking.. don't know if this is a support mailing
list.
I have been trying to install linux on my indy today. First I tried to use
the ext2 partition, /dev/sdb1, with no success. THe kernel says:

sdb : sector size 0 reperted, assuming 512.
SCSI device sdb: hdwr sector= 512 bytes. Sectors= 1  [0 MB] [0.0 GB]

I did mke2fs as the documentation told me and that one succeded. How do I
setup the partittion table?
Well. I tested NFS instead and that worked atleast better. I could mount
root filesystem over nfs. But here is some strange errors I get:

VFS: Mounted root(nfs filesystem).
Unable to handle kernel paging request at virtual address 00010005, epc ==
8804d248, ra == 8804d514
Warning: bad magic number for tty struct (04:00) in release_dev

When I press enter, I get this:

Unable to handle kernel paging request at virtual address 00000000, epc ==
880c8730, ra == 880c8700
Aiee, killing interrupt handler

And after that is the computer (ofcourse) absolutely dead.

I'm using kernel 2.1.55 (from linux.sgi.com). Are there any newer versions
of the kernel (precompiled)? Do you recommend me to download the
crosscompile package and compile 2.1.88? Or, can't someone send me a
better kernel, or tell me where to get it (support for IRIX file system
doesn't matter)?

Best regards,
Ulf Carlsson.

-----------------------------------------
-     grimsy - http://grimsy.ml.org     -
-----------------------------------------

Re: installation problem.

[Alex deVries]

On Wed, 25 Feb 1998, Ulf Carlsson wrote:
> 
> Hello, sorry that I'm asking.. don't know if this is a support mailing
> list.
> I have been trying to install linux on my indy today. First I tried to use
> the ext2 partition, /dev/sdb1, with no success. THe kernel says:
> 
> sdb : sector size 0 reperted, assuming 512.
> SCSI device sdb: hdwr sector= 512 bytes. Sectors= 1  [0 MB] [0.0 GB]

Hm.  The 0 MB is what's worrisome, since the kernel doesn't know what kind
of disk you have.  Can you partition and format that disk properly under
Irix?

I'd certainly suggest you use a different kernel.  Uh, I think there's a
.82 kernel kicking around on ftp.linux.sgi.com.  If not, I'll make sure
there is.

- Alex

Re: installation problem.

[Ulf Carlsson]

On Wed, 25 Feb 1998, Alex deVries wrote:

> > sdb : sector size 0 reperted, assuming 512.
> > SCSI device sdb: hdwr sector= 512 bytes. Sectors= 1  [0 MB] [0.0 GB]
> 
> Hm.  The 0 MB is what's worrisome, since the kernel doesn't know what kind
> of disk you have.  Can you partition and format that disk properly under
> Irix?

Hmm.. I have dropped the harddrive in the floor once :)

Well, I get the same error message from the kernel with sda. (those lines
are identical.. the sda error message is just above the sdb's).

Can't you please tell me how to partition and format a disk in irix? I
have no real experience of irix, got this indy last week. But I
have ofcourse been using linux for a long time :) 

I could use mke2fs from irix, no errer messages at all. That proves at
least that the harddrive atleast is alive and kicking. 

> I'd certainly suggest you use a different kernel.  Uh, I think there's a
> .82 kernel kicking around on ftp.linux.sgi.com.  If not, I'll make sure
> there is.

I think I'll try the linux-magnum thing. Do you know what this is? I can't
find any information about it, but it seems to be the latest version.

Maybe this new version solves all my problems.

-----------------------------------------
-     grimsy - http://grimsy.ml.org     -
-----------------------------------------

Re: installation problem.

[Masashi Sasahara/笹原正司]

> I'd certainly suggest you use a different kernel.  Uh, I think there's a
> .82 kernel kicking around on ftp.linux.sgi.com.  If not, I'll make sure
> there is.

  I'm using pre-compiled .72 kernel in
ftp://ftp.linux.sgi.com/pub/test, which is working fine on my
Irix box. However I couldn't find .82.

  BTW, How can I get the kernel source for Linux/SGI? Do I need
to get from CVS tree?  I tried to compile the source .72 but, at
least, include/asm-mips is not synchronized.

-Masashi Sasahara

Re: installation problem.

[Alex deVries]

On Wed, 25 Feb 1998, Masashi Sasahara/[ISO-2022-JP] ^[$B:{86@5;J^[(B wrote:
> > I'd certainly suggest you use a different kernel.  Uh, I think there's a
> > .82 kernel kicking around on ftp.linux.sgi.com.  If not, I'll make sure
> > there is.
>   I'm using pre-compiled .72 kernel in
> ftp://ftp.linux.sgi.com/pub/test, which is working fine on my
> Irix box. However I couldn't find .82.

Aiyee.  I meant 72, not 82.  I was working on upversioning it to 82 at one
point but never finished.

>   BTW, How can I get the kernel source for Linux/SGI? Do I need
> to get from CVS tree?  I tried to compile the source .72 but, at
> least, include/asm-mips is not synchronized.

Yup, you need to get it from the CVS.

- Alex

Re: installation problem.

[Mike Shaver]

Masashi Sasahara/^[$B:{86@5;J^[(B wrote:
>   BTW, How can I get the kernel source for Linux/SGI? Do I need
> to get from CVS tree?  I tried to compile the source .72 but, at
> least, include/asm-mips is not synchronized.

I've done an export of the current tree to
ftp://ftp.linux.sgi.com/pub/test/kernel-980225.tar.gz .

Mike

-- 
954380.35 933158.02

Re: installation problem.

[Ulf Carlsson]

On Wed, 25 Feb 1998, Mike Shaver wrote:

> I've done an export of the current tree to
> ftp://ftp.linux.sgi.com/pub/test/kernel-980225.tar.gz .

Great, but can't someone put a precompiled _new_ kernel somewhere on
ftp.linux.sgi.com since everyone can't crosscompile?

-----------------------------------------
-     grimsy - http://grimsy.ml.org     -
-----------------------------------------

Re: installation problem.

[Mike Shaver]

Ulf Carlsson wrote:
> Great, but can't someone put a precompiled _new_ kernel somewhere on
> ftp.linux.sgi.com since everyone can't crosscompile?

My xcompiler setup got removed to make space for the sanitized
communicator source free, but I'll clear that out and reinstall it later
today.  In the meantime, could someone else build that tarball?  Alex?

Mike

-- 
957293.37 935819.57

Re: installation problem.

[Masashi Sasahara/笹原正司]

> > I've done an export of the current tree to
> > ftp://ftp.linux.sgi.com/pub/test/kernel-980225.tar.gz .

  Great, Great! Thank you very muxh, Mike. I really appreciate
your quick response.


> Great, but can't someone put a precompiled _new_ kernel somewhere on
> ftp.linux.sgi.com since everyone can't crosscompile?

  Isn't it the one I got? (I mean, vmlinux-indy-2.1.72.tar.gz)

Tks,

-Masashi Sasahara

Re: installation problem.

[Alex deVries]

On Wed, 25 Feb 1998, Mike Shaver wrote:
> Ulf Carlsson wrote:
> > Great, but can't someone put a precompiled _new_ kernel somewhere on
> > ftp.linux.sgi.com since everyone can't crosscompile?
> My xcompiler setup got removed to make space for the sanitized
> communicator source free, but I'll clear that out and reinstall it later
> today.  In the meantime, could someone else build that tarball?  Alex?

I'm not going to get into the xcompiler unless I have to, and I don't.

But, there are .72 binaries in:
ftp://ftp.linux.sgi.com/pub/test/

There's two different onces; vmlinux-indy-2.1.72.tar.gz for machines with
an scache; vmlinux-indy-noL2-2.1.72.tar.gz for those without L2.

Uh, I *think* they work.  If they don't let me know and I'll compile one.  

- alex

Re: installation problem.

[Alex deVries]

On Wed, 25 Feb 1998, Ulf Carlsson wrote:
> On Wed, 25 Feb 1998, Alex deVries wrote:
> > > sdb : sector size 0 reperted, assuming 512.
> > > SCSI device sdb: hdwr sector= 512 bytes. Sectors= 1  [0 MB] [0.0 GB]
> > Hm.  The 0 MB is what's worrisome, since the kernel doesn't know what kind
> > of disk you have.  Can you partition and format that disk properly under
> > Irix?
> 
> Hmm.. I have dropped the harddrive in the floor once :)

Who hasn't? :)

> Well, I get the same error message from the kernel with sda. (those lines
> are identical.. the sda error message is just above the sdb's).

Yup.  It sounds like it's a SCSI driver problem.  Are you getting the
error message now with .72?

> Can't you please tell me how to partition and format a disk in irix? I
> have no real experience of irix, got this indy last week. But I
> have ofcourse been using linux for a long time :) 

You need to use fx, or that cutesy graphical tool that's on the menus.

NB: the latest release on ftp.linux.sgi.com is 2.1.72, not 2.1.82 as I'd
mentioned earlier.  Too many numbers...

- Alex

Re: installation problem.

[Mike Shaver]

Ulf Carlsson wrote:
> It's also very strange that the kernel doesn't detect my scsi harddrives
> correctly (I have reported these error messages earlier). I tested fx, and
> fx detected them correctly. I get the same error with my orginal sgi
> harddrive which obviously works, since irix doesn't have any problems with
> it.

Oh...is that drive SCSI id 7?  I had problems with one of my drives
(which was happy under IRIX) until I changed the id to something other
than 7.
 
> I'll take a look in the kernel source and try to figure out what's causing
> that kernel paging error.

You want to run mips-linux-objdump to get a function+offset (or, if that
kernel was compiled -g, line number info) for the fault, and then we can
try to debug it.

Mike

Re: installation problem.

[Ulf Carlsson]

> But, there are .72 binaries in:
> ftp://ftp.linux.sgi.com/pub/test/

Sorry it's my fault (my big fool). Assumed all the .tar.gz files were
sources, forgot checking the sizes.

Well, the .72 binary didn't boot at all. I got "black screen". But .67
gets atleast so far that it mounts my root filesystem (over nfs). But
directly after that I recieve these errors (same as under .55, but this
kernel prints the message more than one time):

Unable to handle kernel paging request at virtual address 000013f0, epc ==
8803ff14, ra == 88040680
Aiee, killing interrupt handler

That message is printed out about ten times with different
values for epc and ra and virtual address.
Do you have any idea what's causing this mess?

It's also very strange that the kernel doesn't detect my scsi harddrives
correctly (I have reported these error messages earlier). I tested fx, and
fx detected them correctly. I get the same error with my orginal sgi
harddrive which obviously works, since irix doesn't have any problems with
it.

I'll take a look in the kernel source and try to figure out what's causing
that kernel paging error.

/Ulf Carlsson

Re: installation problem.

[Ulf Carlsson]

On Wed, 25 Feb 1998, Mike Shaver wrote:

> Ulf Carlsson wrote:
> > It's also very strange that the kernel doesn't detect my scsi harddrives
> > correctly (I have reported these error messages earlier). I tested fx, and
> > fx detected them correctly. I get the same error with my orginal sgi
> > harddrive which obviously works, since irix doesn't have any problems with
> > it.
> 
> Oh...is that drive SCSI id 7?  I had problems with one of my drives
> (which was happy under IRIX) until I changed the id to something other
> than 7.

No, one drive is at id 4 and one at id 6.

Have I forgot to do something? I used the Disk Manager from the menu to
partition my scsi drive. Then I used mke2fs /dev/dsk/dks0d6s7. Is that the
corrected procedure?

> > I'll take a look in the kernel source and try to figure out what's causing
> > that kernel paging error.
> 
> You want to run mips-linux-objdump to get a function+offset (or, if that
> kernel was compiled -g, line number info) for the fault, and then we can
> try to debug it.

Is mips-linux-objdump in the binutils package?

/Ulf Carlsson

Re: installation problem.

[Ulf Carlsson]

Hello again.

I'm getting pretty tired. No progress at all. Is my configuration special
in any way?

System: IP22
Processor: 100 Mhz R4000, with FPU
Primary I-cache size: 8 kbytes
Primary d-cache size: 8 kbytes
Secondary cache size: 1024 Kbytes
Memory size: 32 Mbytes
Graphics: Indy 8-bit
SCSI Disk: scsi(0)disk(4)
SCSI Disk: scsi(0)disk(6)

Are not all indys almost identical? It's very strange IMO that .72 hangs
before it prints anything on the screen. I think I've tested almost
everything by now.

Those harddrive problems don't matter right now. It's possible to run over
nfs so.. it's the kernel paging error which is the problem.

I am not blaming you SGI/Linux developers for creating a bad system in any
way. It would have been really nice if it worked :)

What will I do?

/Ulf Carlsson

Re: installation problem.

[Ulf Carlsson]

Hello again.

I'm getting pretty tired. No progress at all. Is my configuration special
in any way?

System: IP22
Processor: 100 Mhz R4000, with FPU
Primary I-cache size: 8 kbytes
Primary d-cache size: 8 kbytes
Secondary cache size: 1024 Kbytes
Memory size: 32 Mbytes
Graphics: Indy 8-bit
SCSI Disk: scsi(0)disk(4)
SCSI Disk: scsi(0)disk(6)

Are not all indys almost identical? It's very strange IMO that .72 hangs
before it prints anything on the screen. I think I've tested almost
everything by now.

Those harddrive problems don't matter right now. It's possible to run over
nfs so.. it's the kernel paging error which is the problem. I think this
error might be caused by my pc, because I don't get that error when the
network is down or the pc is shut down, but I can't boot when the pc is
down because I'm using nfs root system. Maybe the pc sends out signals on
the network which sgi linux can't handle (just a thought).

I am not blaming you SGI/Linux developers for creating a bad system in any
way. It would have been really nice if it worked :)

What will I do?

/Ulf Carlsson

Re: installation problem.

[Ulf Carlsson]

On Wed, 25 Feb 1998, Mike Shaver wrote:

> Oh...is that drive SCSI id 7?

They were 4 (irix) and 6 (linux) before, but I've changed them to 2 and
5 now. No difference.

/Ulf Carlsson

Re: installation problem.

[William J. Earl]

Ulf Carlsson writes:
 > Hello again.
 > 
 > I'm getting pretty tired. No progress at all. Is my configuration special
 > in any way?
 > 
 > System: IP22
 > Processor: 100 Mhz R4000, with FPU
 > Primary I-cache size: 8 kbytes
 > Primary d-cache size: 8 kbytes
 > Secondary cache size: 1024 Kbytes
 > Memory size: 32 Mbytes
 > Graphics: Indy 8-bit
 > SCSI Disk: scsi(0)disk(4)
 > SCSI Disk: scsi(0)disk(6)
 > 
 > Are not all indys almost identical? It's very strange IMO that .72 hangs
 > before it prints anything on the screen. I think I've tested almost
 > everything by now.
...

     No, there are many different CPU types for the Indy, in order
of appearance:

	R4000PC, 100 MHZ
	R4000SC, 100 MHZ
	R4600PC, 100 and 133 MHZ
	R4400SC, 150 and 200 MHZ
	R4600SC, 133 MHZ
	R5000PC, 150 and 180 MHZ
	R5000SC, 180 MHZ

In the above, "PC" means that there is no secondary cache and "SC"
means that there is.  The R4000 and R4400 are functionally very similar, except
for cache size.  The R4600 and R5000 are also similar, but with
a very different cache organization from the R4000 and R4400.  Various
revision of the processors (and more than one revision was shipped
for each processor) have different errata, so the kernel must work around
various processor errata according to the processor type and revision.
As I understand it, the currently checked-in source must be recompiled
to provide R4600/R5000 PC and SC versions for Indy, and those versions
may not be fully tested on all R4000 and R4400 revisions.  In the not
distant future, a single kernel will likely support all the processors,
as does the IRIX kernel, but that is more work than just selecting
the processor type at compile time.

Re: installation problem.

[Thomas Bogendoerfer]

> As I understand it, the currently checked-in source must be recompiled
> to provide R4600/R5000 PC and SC versions for Indy, and those versions
> may not be fully tested on all R4000 and R4400 revisions.  In the not
> distant future, a single kernel will likely support all the processors,
> as does the IRIX kernel, but that is more work than just selecting
> the processor type at compile time.

the R4000PC part of the .72 current works at least on my Magnum clone. But
I've got an error report, that my kernel doesn't work on a Magnum with a
R4000SC. So I guess it's really related to the processor handling in the
kernel.

Thomas.

-- 
See, you not only have to be a good coder to create a system like Linux,
you have to be a sneaky bastard too ;-)
                   [Linus Torvalds in <4rikft$7g5@linux.cs.Helsinki.FI>]

Re: installation problem.

[Alistair Lambie]

William J. Earl wrote:
> 
> Ulf Carlsson writes:
>  > Hello again.
>  >
>  > I'm getting pretty tired. No progress at all. Is my configuration special
>  > in any way?
>  >
>  > System: IP22
>  > Processor: 100 Mhz R4000, with FPU
>  > Primary I-cache size: 8 kbytes
>  > Primary d-cache size: 8 kbytes
>  > Secondary cache size: 1024 Kbytes
>  > Memory size: 32 Mbytes
>  > Graphics: Indy 8-bit
>  > SCSI Disk: scsi(0)disk(4)
>  > SCSI Disk: scsi(0)disk(6)
>  >
>  > Are not all indys almost identical? It's very strange IMO that .72 hangs
>  > before it prints anything on the screen. I think I've tested almost
>  > everything by now.
> ...
> 

Wouldn't be a pre newport graphics machine would it?  Has this been tried?  Just
a thought.

Cheers, Alistair

>      No, there are many different CPU types for the Indy, in order
> of appearance:
> 
>         R4000PC, 100 MHZ
>         R4000SC, 100 MHZ
>         R4600PC, 100 and 133 MHZ
>         R4400SC, 150 and 200 MHZ
>         R4600SC, 133 MHZ
>         R5000PC, 150 and 180 MHZ
>         R5000SC, 180 MHZ
> 
> In the above, "PC" means that there is no secondary cache and "SC"
> means that there is.  The R4000 and R4400 are functionally very similar, except
> for cache size.  The R4600 and R5000 are also similar, but with
> a very different cache organization from the R4000 and R4400.  Various
> revision of the processors (and more than one revision was shipped
> for each processor) have different errata, so the kernel must work around
> various processor errata according to the processor type and revision.
> As I understand it, the currently checked-in source must be recompiled
> to provide R4600/R5000 PC and SC versions for Indy, and those versions
> may not be fully tested on all R4000 and R4400 revisions.  In the not
> distant future, a single kernel will likely support all the processors,
> as does the IRIX kernel, but that is more work than just selecting
> the processor type at compile time.

-- 
Alistair Lambie                         alambie@wellington.sgi.com
Silicon Graphics New Zealand                SGI Voicemail: 2431455
Level 5, Cigna House,                           Ph: +64-4-494 6325
40 Mercer St, Wellington, NZ                   Fax: +64-4-494 6321

Re: installation problem.

[William J. Earl]

Alistair Lambie writes:
 > William J. Earl wrote:
 > > 
 > > Ulf Carlsson writes:
 > >  > Hello again.
 > >  >
 > >  > I'm getting pretty tired. No progress at all. Is my configuration special
 > >  > in any way?
 > >  >
 > >  > System: IP22
 > >  > Processor: 100 Mhz R4000, with FPU
 > >  > Primary I-cache size: 8 kbytes
 > >  > Primary d-cache size: 8 kbytes
 > >  > Secondary cache size: 1024 Kbytes
 > >  > Memory size: 32 Mbytes
 > >  > Graphics: Indy 8-bit
 > >  > SCSI Disk: scsi(0)disk(4)
 > >  > SCSI Disk: scsi(0)disk(6)
 > >  >
 > >  > Are not all indys almost identical? It's very strange IMO that .72 hangs
 > >  > before it prints anything on the screen. I think I've tested almost
 > >  > everything by now.
 > > ...
 > > 
 > 
 > Wouldn't be a pre newport graphics machine would it?  Has this been tried?  Just
 > a thought.
...

     No, "Graphics: Indy 8-bit" is Newport.  Is this really the "SC" kernel for Indy,
not the "PC" kernel?

Re: installation problem.

[ralf]

On Thu, Feb 26, 1998 at 11:41:26AM +0100, Ulf Carlsson wrote:

> Hello again.
> 
> I'm getting pretty tired. No progress at all. Is my configuration special
> in any way?
> 
> System: IP22
> Processor: 100 Mhz R4000, with FPU
> Primary I-cache size: 8 kbytes
> Primary d-cache size: 8 kbytes
> Secondary cache size: 1024 Kbytes

So this must be a R4000SC CPU.  The CPU support code for it is buggy, that's
why it it's working.

Fixes probably coming next week; as think are looking I'll have a hell lot
of time again by then.

  Ralf

Re: installation problem.

[ralf]

On Thu, Feb 26, 1998 at 09:34:05AM -0800, William J. Earl wrote:

> for cache size.  The R4600 and R5000 are also similar, but with
> a very different cache organization from the R4000 and R4400.  Various
> revision of the processors (and more than one revision was shipped
> for each processor) have different errata, so the kernel must work around
> various processor errata according to the processor type and revision.

In case of the R4000 we still have some work to do with respect to the
errata stuff.

> As I understand it, the currently checked-in source must be recompiled
> to provide R4600/R5000 PC and SC versions for Indy, and those versions
> may not be fully tested on all R4000 and R4400 revisions.  In the not
> distant future, a single kernel will likely support all the processors,
> as does the IRIX kernel, but that is more work than just selecting
> the processor type at compile time.

The code in the CVS archive is plain buggy for certain configurations.
Given the number of possible configurations possible everything else but
a single kernel binary would be braindead.  Especially because the price
we have to pay for a single Indy binary isn't that high.

  Ralf

Re: installation problem.

[Ulf Carlsson]

On Thu, 26 Feb 1998 ralf@uni-koblenz.de wrote:

> > System: IP22
> > Processor: 100 Mhz R4000, with FPU
> > Primary I-cache size: 8 kbytes
> > Primary d-cache size: 8 kbytes
> > Secondary cache size: 1024 Kbytes
> 
> So this must be a R4000SC CPU.  The CPU support code for it is buggy, that's
> why it it's working.

It's _not_ working. And I would like to know why it isn't working.  (ok, I
understand what you mean, sorry :)  Well, this is not a big problem for me
anyway. The .68 kernel works. The main problem is the one with the
harddrives (detecting them, but with the size of 0Mb, and the kernel can't
read the partition tables), and the one with the kernel paging request it
can't handle. Any ideas? 

> Fixes probably coming next week; as think are looking I'll have a hell lot
> of time again by then.

Great, next week.. (feels like one year).

/Ulf Carlsson.

-----------------------------------------
-     grimsy - http://grimsy.ml.org     -
-----------------------------------------

Re: installation problem.

[Ulf Carlsson]

On Fri, 27 Feb 1998, Alistair Lambie wrote:

> William J. Earl wrote:
> >  > System: IP22
> >  > Processor: 100 Mhz R4000, with FPU
> >  > Primary I-cache size: 8 kbytes
> >  > Primary d-cache size: 8 kbytes
> >  > Secondary cache size: 1024 Kbytes
> >  > Memory size: 32 Mbytes
> >  > Graphics: Indy 8-bit
> >  > SCSI Disk: scsi(0)disk(4)
> >  > SCSI Disk: scsi(0)disk(6)
> >  >
> >  > Are not all indys almost identical? It's very strange IMO that .72 hangs
> >  > before it prints anything on the screen. I think I've tested almost
> >  > everything by now.
> 
> Wouldn't be a pre newport graphics machine would it?  Has this been tried?  Just
> a thought.

Pre newport, what's that? Do you mean that I'm the only one with this
configuration trying to run SGI/Linux, darn... thought this was one of the
most common configurations of the Indy.

/ulf

-----------------------------------------
-     grimsy - http://grimsy.ml.org     -
-----------------------------------------

Re: installation problem.

[ralf]

On Fri, Feb 27, 1998 at 02:47:48PM +0100, Ulf Carlsson wrote:

> > > System: IP22
> > > Processor: 100 Mhz R4000, with FPU
> > > Primary I-cache size: 8 kbytes
> > > Primary d-cache size: 8 kbytes
> > > Secondary cache size: 1024 Kbytes
> > 
> > So this must be a R4000SC CPU.  The CPU support code for it is buggy, that's
> > why it it's working.
> 
> It's _not_ working. And I would like to know why it isn't working.  (ok, I

The exact bug is that one of the cache maintenance routines in
include/asm-mips/r4kcache.h uses there wrong cachop for flushing the
cache.

> understand what you mean, sorry :)  Well, this is not a big problem for me
> anyway. The .68 kernel works. The main problem is the one with the
           
.68 isn't supposed to work.  The memory is laid out such that the buggy
cache routine has a bit less of effect.

> harddrives (detecting them, but with the size of 0Mb, and the kernel can't
> read the partition tables), and the one with the kernel paging request it
> can't handle. Any ideas? 

Should all be the cache effect.

> > Fixes probably coming next week; as think are looking I'll have a hell lot
> > of time again by then.
> 
> Great, next week.. (feels like one year).

Next week starts tonite.  Linux/MIPS industries going back online ...

  Ralf  (Getting coffee and milk ...)

Re: installation problem.

[Alex deVries]

On Fri, 27 Feb 1998, Ulf Carlsson wrote:
> On Fri, 27 Feb 1998, Alistair Lambie wrote:
> > William J. Earl wrote:
> > >  > Are not all indys almost identical? It's very strange IMO that .72 hangs
> > >  > before it prints anything on the screen. I think I've tested almost
> > >  > everything by now.

Ah, I think I know the problem.  There are some problems with the .72 make
depend which screws up the console.  The version that's uploaded may not
have the console compiled in properly.  That should be clear from the
config file that' sin the tar.gz file.

I could quite easily get you a binary that does have it compiled in. If I
don't have it on linus by tomorrow, pester me.

Been there, done that.

I might think about doing the update to .89, but I don't want to try to do
what anybody else is doing, since 10 Alex hours = 1 Ralf hour.  But, my
other projects with GTK and RPM are kind of at a standstill because of
waiting for others to release components and sorting out endless loops of
design logic.  So, maybe I'll take a stab at it.

- Alex

Re: installation problem.

[Ulf Carlsson]

On Fri, 27 Feb 1998 ralf@uni-koblenz.de wrote:

> The exact bug is that one of the cache maintenance routines in
> include/asm-mips/r4kcache.h uses there wrong cachop for flushing the
> cache.

Oh.

> > understand what you mean, sorry :)  Well, this is not a big problem for me
> > anyway. The .68 kernel works. The main problem is the one with the
>            
> .68 isn't supposed to work.  The memory is laid out such that the buggy
> cache routine has a bit less of effect.

Hm, ok. But why is .68 on ftp.linux.sgi.com if it doesn't work, or isn't
even supposed to work?

> > harddrives (detecting them, but with the size of 0Mb, and the kernel can't
> > read the partition tables), and the one with the kernel paging request it
> > can't handle. Any ideas? 
> 
> Should all be the cache effect.

Doesn't it work for your?

I have some questions concerning the MIPS/Linux project. I think the FAQ
on the homepage is obsolete (sorry, you must have answered these questions
100 times by now :)

Is it possible to use MIPS/Linux yet, or is it too buggy? How much of the
X code is done? Are any of the SGI special devices, such as the cool
functions on the video card supported yet? Which kernel runs
linux.sgi.com (this one seems to be quite stable).

Maybe I'll join the project (if you allow me to). I don't know if I have
the time right now, quite busy programming for a demo project.

/Ulf Carlsson

-----------------------------------------
-     grimsy - http://grimsy.ml.org     -
-----------------------------------------

Re: installation problem.

[ralf]

On Sat, Feb 28, 1998 at 12:42:15AM +0100, Ulf Carlsson wrote:

> On Fri, 27 Feb 1998 ralf@uni-koblenz.de wrote:
> 
> > The exact bug is that one of the cache maintenance routines in
> > include/asm-mips/r4kcache.h uses there wrong cachop for flushing the
> > cache.
> 
> Oh.
> 
> > > understand what you mean, sorry :)  Well, this is not a big problem for me
> > > anyway. The .68 kernel works. The main problem is the one with the
> >            
> > .68 isn't supposed to work.  The memory is laid out such that the buggy
> > cache routine has a bit less of effect.
> 
> Hm, ok. But why is .68 on ftp.linux.sgi.com if it doesn't work, or isn't
> even supposed to work?

It's only supposed to fail for your configuration.

> > > harddrives (detecting them, but with the size of 0Mb, and the kernel can't
> > > read the partition tables), and the one with the kernel paging request it
> > > can't handle. Any ideas? 
> > 
> > Should all be the cache effect.
> 
> Doesn't it work for your?

Since I'm doing the thing it will always work for my hardware (hint, hint ...)

> I have some questions concerning the MIPS/Linux project. I think the FAQ
> on the homepage is obsolete (sorry, you must have answered these questions
> 100 times by now :)
> 
> Is it possible to use MIPS/Linux yet, or is it too buggy? How much of the

It's good for month of uptime.  Some apps are not that reliable.

> X code is done? Are any of the SGI special devices, such as the cool
> functions on the video card supported yet? Which kernel runs

Linux supports what god wanted to be supported, text mode :-)

> linux.sgi.com (this one seems to be quite stable).

It's called IRIX :-)

(And yes, the machine had over half a year uptime.  The IRIX developers on
the list will apreciate your praise :-)

  Ralf

Re: installation problem.

[Alex deVries]

On Sat, 28 Feb 1998, Ulf Carlsson wrote:
> On Fri, 27 Feb 1998 ralf@uni-koblenz.de wrote:
> Hm, ok. But why is .68 on ftp.linux.sgi.com if it doesn't work, or isn't
> even supposed to work?

Really, because we're not making a very big point of ensuring that the ftp
site is up to date and accurate.  Same with the FAQ.  Yes, we should do a
better job at this, feel free to help out.

> Doesn't it work for your?

Definitely.  Alex3.med.iacnet.com works very well, and it really doesn't
every crash.  Certainly some of it could use some work (like partitioning,
modules, X, etc), but glibc, networking, etc are all there.

> Is it possible to use MIPS/Linux yet, or is it too buggy? How much of the
> X code is done? Are any of the SGI special devices, such as the cool

Miguel?  What's up with X exactly?  Are you short on hw specs?

- Alex

Re: installation problem.

[ralf]

On Fri, Feb 27, 1998 at 07:17:28PM -0500, Alex deVries wrote:

> Miguel?  What's up with X exactly?  Are you short on hw specs?

It's more that days tend to have only 48 hours ...

  Ralf

Re: installation problem.

[Miguel de Icaza]

> Is it possible to use MIPS/Linux yet, or is it too buggy? How much of the
> X code is done? Are any of the SGI special devices, such as the cool
> functions on the video card supported yet? Which kernel runs
> linux.sgi.com (this one seems to be quite stable).

There is little code for the free X11 server written.  I can send my
bits to whoever wants them (they are based on what the kernel supports
for the IRIX X emulation, so we will end up supporting a scheme very
similar to what the IRIX X server has).

Miguel.

Re: installation problem.

[Miguel de Icaza]

> > Is it possible to use MIPS/Linux yet, or is it too buggy? How much of the
> > X code is done? Are any of the SGI special devices, such as the cool
> 
> Miguel?  What's up with X exactly?  Are you short on hw specs?

No.  I am short on time.

I am rushing for a beta release of the gnome desktop thingie and until
then I am pretty busy.

For those who do not know: gnome is a user-friendly desktop that aims
at easing the usage of Unix computers.

Gnome provides a user friendly desktop, and aims at providing a
component framework for building large applications (components
modeled pretty much after microsoft's active-x, but we are using CORBA
for gluing stuff together instead of COM).  For more information
check: http://www.gnome.org and feel free to contribute to the
effort. 

Back to the X server: here is the status: the X server starts up on my
machine very happilly, but crashes the kernel sometime when clients
connect.  Not all clients crash the kernel, just some of them (if you
run an xterm or emacs you will crash the kernel). 

These are remote applications, so it is a fault in the Xserver support
in the kernel.  This happens in graphics mode, so if the kernel is
printing out a nice panic message, it never reaches the screen. 

What should be done to debug this is: inside panic() we need to
restore text mode manually (trivial to figure out from the sources,
there is some routine there) and figure out where the crash happened. 

Now, what might make debugging this a pain is that you require the
an Indy that is configured just like mine :-), as when I was doing the
X server code, I rushed to hardcode the inventory return code to
whatever my machine had, so you better have a newport that supports
24-bpp or you need to change the inventory bits (or better yet, fix
the inventory code) :-).

Getting the X server to run is trivial: just strace your X server in
IRIX and copy all of the files that are refereced by the X server.

Then create the special files in /dev with the major/minors that are
documented in the kernel and voila!

best gnoming wishes, 
Miguel.

Re: installation problem.

[Ariel Faigon]

:
:On Fri, 27 Feb 1998 ralf@uni-koblenz.de wrote:
:
:> .68 isn't supposed to work.  The memory is laid out such that the buggy
:> cache routine has a bit less of effect.
:
:Hm, ok. But why is .68 on ftp.linux.sgi.com if it doesn't work, or isn't
:even supposed to work?
:
We really need someone who runs linux and understands the details
to clean up the web site and make sure the FAQ is current and
the precompiled kernels are stable and those that are bad
are deleted etc.

If you vounteer, please send me your ssh public key and I
give you an account on *.linux.sgi.com in no time  :-)


:
:I have some questions concerning the MIPS/Linux project. I think the FAQ
:on the homepage is obsolete (sorry, you must have answered these questions
:100 times by now :)
:
:Is it possible to use MIPS/Linux yet, or is it too buggy? How much of the
:X code is done? Are any of the SGI special devices, such as the cool
:functions on the video card supported yet? Which kernel runs
:linux.sgi.com (this one seems to be quite stable).
:
Linux on SGI Indy's is quite stable once it boots.  We have about
five or so users that use it daily as their development platform.
We seem to have some problems with some HW configs but not enough
installed base to figure all this out.  Maybe now that Ralf is
back we may see some progress.  Ralf is an amazing MIPS and Linux
hacker, we probably need someone else who is less of a hacker but
more of a documenter to take charge of the web site.

:Maybe I'll join the project (if you allow me to). I don't know if I have
:the time right now, quite busy programming for a demo project.
:
You'll be blessed if you join.

-- 
Peace, Ariel

Re: installation problem.

[Ariel Faigon]

:
:On Fri, 27 Feb 1998 ralf@uni-koblenz.de wrote:
:
:> .68 isn't supposed to work.  The memory is laid out such that the buggy
:> cache routine has a bit less of effect.
:
:Hm, ok. But why is .68 on ftp.linux.sgi.com if it doesn't work, or isn't
:even supposed to work?
:
We really need someone who runs linux and understands the details
to clean up the web site and make sure the FAQ is current and
the precompiled kernels are stable and those that are bad
are deleted etc.

If you vounteer, please send me your ssh public key and I
give you an account on *.linux.sgi.com in no time  :-)


:
:I have some questions concerning the MIPS/Linux project. I think the FAQ
:on the homepage is obsolete (sorry, you must have answered these questions
:100 times by now :)
:
:Is it possible to use MIPS/Linux yet, or is it too buggy? How much of the
:X code is done? Are any of the SGI special devices, such as the cool
:functions on the video card supported yet? Which kernel runs
:linux.sgi.com (this one seems to be quite stable).
:
Linux on SGI Indy's is quite stable once it boots.  We have about
five or so users that use it daily as their development platform.
We seem to have some problems with some HW configs but not enough
installed base to figure all this out.  Maybe now that Ralf is
back we may see some progress.  Ralf is an amazing MIPS and Linux
hacker, we probably need someone else who is less of a hacker but
more of a documenter to take charge of the web site.

:Maybe I'll join the project (if you allow me to). I don't know if I have
:the time right now, quite busy programming for a demo project.
:
You'll be blessed if you join.

-- 
Peace, Ariel

Re: installation problem.

[Ulf Carlsson]

On Fri, 27 Feb 1998, Ariel Faigon wrote:

> We really need someone who runs linux and understands the details
> to clean up the web site and make sure the FAQ is current and
> the precompiled kernels are stable and those that are bad
> are deleted etc.
> If you vounteer, please send me your ssh public key and I
> give you an account on *.linux.sgi.com in no time  :-)

Well, I could done that. I have only one programming project right now and
this isn't even programming, just writing a FAQ and updating a homepage. 
There are still some reasons why I can't help you with this right now: 

1. I know almost nothing about MIPS/Linux. Well, as soon as it boots for
   me will I study all its advantages and disadvantages.
2. My internet connection is not very fast. Only modem at home. Well, I
   have a faster connection at school, but you know. Serving a ftp
   with 10mb kernels is not a job for me. (well, I may take charge of the
   www site some day in the (near?) future).

> Linux on SGI Indy's is quite stable once it boots.  We have about
> five or so users that use it daily as their development platform.
Developing MIPS/Linux or developing something else?
How many MIPS/Linux are there right now? 10? 50? 100?

> We seem to have some problems with some HW configs but not enough
> installed base to figure all this out.  Maybe now that Ralf is
> back we may see some progress.  Ralf is an amazing MIPS and Linux
> hacker, we probably need someone else who is less of a hacker but
> more of a documenter to take charge of the web site.
How many coders are there for MIPS/Linux, just Ralf?

> You'll be blessed if you join.
As I said I have to install the funky shit first of all. :-)

- grimsy

Re: installation problem.

[Ariel Faigon]

:
:> Linux on SGI Indy's is quite stable once it boots.  We have about
:> five or so users that use it daily as their development platform.
:Developing MIPS/Linux or developing something else?
:How many MIPS/Linux are there right now? 10? 50? 100?
:
I would assume around 10... but I don't know for sure, really.
There have been many more downloads.  We are still virtual console
(no X) dependent and a few Indy devices (such as sound) are not
supported.

:> We seem to have some problems with some HW configs but not enough
:> installed base to figure all this out.  Maybe now that Ralf is
:> back we may see some progress.  Ralf is an amazing MIPS and Linux
:> hacker, we probably need someone else who is less of a hacker but
:> more of a documenter to take charge of the web site.
:How many coders are there for MIPS/Linux, just Ralf?
:
Ralf, Miguel, Mike Shaver, Alex deVries, Thomas Bogendoerfer,
Alan Cox.  There have been a few more in the past, but most have
a real job too so they are working on this on and off...

-- 
Peace, Ariel

Re: installation problem.

[Ariel Faigon]

:
:> Linux on SGI Indy's is quite stable once it boots.  We have about
:> five or so users that use it daily as their development platform.
:Developing MIPS/Linux or developing something else?
:How many MIPS/Linux are there right now? 10? 50? 100?
:
I would assume around 10... but I don't know for sure, really.
There have been many more downloads.  We are still virtual console
(no X) dependent and a few Indy devices (such as sound) are not
supported.

:> We seem to have some problems with some HW configs but not enough
:> installed base to figure all this out.  Maybe now that Ralf is
:> back we may see some progress.  Ralf is an amazing MIPS and Linux
:> hacker, we probably need someone else who is less of a hacker but
:> more of a documenter to take charge of the web site.
:How many coders are there for MIPS/Linux, just Ralf?
:
Ralf, Miguel, Mike Shaver, Alex deVries, Thomas Bogendoerfer,
Alan Cox.  There have been a few more in the past, but most have
a real job too so they are working on this on and off...

-- 
Peace, Ariel

Re: installation problem.

[Ulf Carlsson]

On Fri, 27 Feb 1998, Ariel Faigon wrote:

> Ralf, Miguel, Mike Shaver, Alex deVries, Thomas Bogendoerfer,
> Alan Cox.  There have been a few more in the past, but most have
> a real job too so they are working on this on and off...

So, how do you get money if you don't have a job?

- grimsy

Re: installation problem.

[Alan Cox]

> Alan Cox.  There have been a few more in the past, but most have
> a real job too so they are working on this on and off...

SGIwise Im sort of stuck at the moment waiting for things to appear. If someone
can get me/email me the PS/2 mouse docs for the indy I'll attack that if
Miguel is still having it lock up on him

Re: installation problem.

[Michael Hill]

Ulf Carlsson writes:
 > On Fri, 27 Feb 1998, Ariel Faigon wrote:
 > 
 > > Ralf, Miguel, Mike Shaver, Alex deVries, Thomas Bogendoerfer,
 > > Alan Cox.  There have been a few more in the past, but most have
 > > a real job too so they are working on this on and off...
 > 
 > So, how do you get money if you don't have a job?

If someone would post a response to the list, I could free up some time with 
two weeks' notice.

Mike
-- 
Michael Hill
Toronto, Canada
mdhill@interlog.com

Re: installation problem.

[ralf]

On Sat, Feb 28, 1998 at 04:23:41PM +0000, Alan Cox wrote:

> > Alan Cox.  There have been a few more in the past, but most have
> > a real job too so they are working on this on and off...
> 
> SGIwise Im sort of stuck at the moment waiting for things to appear. If someone
> can get me/email me the PS/2 mouse docs for the indy I'll attack that if
> Miguel is still having it lock up on him

Basically the Indy PS/2 hardware is the same as on PCs, it's just that both
mouse and keyboard are using the same interrupt and we therefore need some
special magic.  When cleaning up in the keyboard driver I somehow lost the
PS/2 magic stuff that calls aux_interrupt().  Old CVS kernel versions
should have that stuff still in the keyboard code.

  Ralf

Re: installation problem.

[ralf]

On Sat, Feb 28, 1998 at 11:35:01AM -0500, Michael Hill wrote:

> Ulf Carlsson writes:
>  > On Fri, 27 Feb 1998, Ariel Faigon wrote:
>  > 
>  > > Ralf, Miguel, Mike Shaver, Alex deVries, Thomas Bogendoerfer,
>  > > Alan Cox.  There have been a few more in the past, but most have
>  > > a real job too so they are working on this on and off...
>  > 
>  > So, how do you get money if you don't have a job?
> 
> If someone would post a response to the list, I could free up some time with 
> two weeks' notice.

The MIPS embedded market is large enough to give you a living on the base
of Linux/MIPS.  I wouldn't dare to say that about the Linux for SGI market
yet ...  The big problem is just finding the initial customers.  Living on
the base of Linux is however getting easier and easier.  About half of my
income the last year was based directly or indirectly on Linux and it's
getting more.  And yes, it's good enough to afford non-rusty cars ;-)

  Ralf

Re: installation problem.

[Alex deVries]

On Sat, 28 Feb 1998, Ulf Carlsson wrote:
> 1. I know almost nothing about MIPS/Linux. Well, as soon as it boots for
>    me will I study all its advantages and disadvantages.
> 2. My internet connection is not very fast. Only modem at home. Well, I
>    have a faster connection at school, but you know. Serving a ftp
>    with 10mb kernels is not a job for me. (well, I may take charge of the
>    www site some day in the (near?) future).

That's where SGI comes in nicely, providing us all with ftp.linux.sgi.com.

I actually have some unfinished HOWTO docs you're welcome to have, but the
problem with them is that we haven't really realized a viable installation
method yet.  Still gotta get the initrd stuff running...

- Alex

Re: installation problem.

[Ulf Carlsson]

On Sat, 28 Feb 1998, Alex deVries wrote:

> On Sat, 28 Feb 1998, Ulf Carlsson wrote:
> > 1. I know almost nothing about MIPS/Linux. Well, as soon as it boots for
> >    me will I study all its advantages and disadvantages.
> > 2. My internet connection is not very fast. Only modem at home. Well, I
> >    have a faster connection at school, but you know. Serving a ftp
> >    with 10mb kernels is not a job for me. (well, I may take charge of the
> >    www site some day in the (near?) future).
> 
> That's where SGI comes in nicely, providing us all with ftp.linux.sgi.com.
> 
> I actually have some unfinished HOWTO docs you're welcome to have, but the
> problem with them is that we haven't really realized a viable installation
> method yet.  Still gotta get the initrd stuff running...
> 
> - Alex

I have been trying to catch up this mailing list today. Reading all the
postings since the beginning, very interesting. Can't you please send over
your HOWTO docs and let me see them? I think the hack of the mklinux
installation tool did its job excellent. I have nothing to complain of. 

-Ulf

Re: installation problem.

[Ulf Carlsson]

Evening.

How's it going with the bug in include/asm-mips/r4kcache.h?
I read the source file, but I didn't understand anything, you know - it's
azzemblur ;-).

- Ulf

installation problem

[Charles Lepple]

After successfully (though not uneventfully ;-) installing HardHat on an
Indy/r5k, I am now faced with the quandry of installing to another
nearly identical machine. The only difference is that the second
machine's IRIX partitions were blown away when I tried to use fdisk (no,
I didn't finish reading the installation instructions at this point...).

All of the SGI employees out there are probably saying, "Reinstall
IRIX", but (it's a long story) I'd rather do this the Linux way. Any
suggestions? I looked at the prom man page, and I can get the box to
boot the kernel with a 'setenv diskless y' and 'setenv OSLoader
/var/boot/vmlinux' (and then some... I'm not in front of the machine at
the moment). However, with the IRIX dhcp_bootp daemon, I can't seem to
set the suggested nfs root partition, and now that sash is gone, I can't
seem to get command line parameters to work anymore (vmlinux is the
OSLoader, and it's not doing the sash thing), and hence, the kernel
won't boot.

Since I have the other machine up and running, is it possible to 'clone'
the disk with dd? Or will it not catch all of the disk label header
stuff needed to recognize partitions?

Also, on the working machine, is there a better way to boot it than
telling it to 'boot bootp():vmlinux' each time? Again, working with one
disk per machine, IRIX is gone (but I didn't blow sash away on this
one).

If this means that we need some tools to write to the disk headers (ie,
a SGI-aware fdisk, or something to put files into the disk label
directory (similar to the way sash and ide are stored)), I'd be
interested in talking to someone who can get to the information
necessary to do this. (I'm still looking at booting from a CD, but since
most of the working CD-ROM drives are in use, that may wait.)

--
Charles Lepple
System Administrator, Virginia Tech EE Workstation Labs
clepple@ee.vt.edu || http://www.foo.tho.org/charles/

Re: installation problem

[William J. Earl]

Charles Lepple writes:
 > After successfully (though not uneventfully ;-) installing HardHat on an
 > Indy/r5k, I am now faced with the quandry of installing to another
 > nearly identical machine. The only difference is that the second
 > machine's IRIX partitions were blown away when I tried to use fdisk (no,
 > I didn't finish reading the installation instructions at this point...).
 > 
 > All of the SGI employees out there are probably saying, "Reinstall
 > IRIX", but (it's a long story) I'd rather do this the Linux way. Any
 > suggestions? I looked at the prom man page, and I can get the box to
 > boot the kernel with a 'setenv diskless y' and 'setenv OSLoader
 > /var/boot/vmlinux' (and then some... I'm not in front of the machine at
 > the moment). However, with the IRIX dhcp_bootp daemon, I can't seem to
 > set the suggested nfs root partition, and now that sash is gone, I can't
 > seem to get command line parameters to work anymore (vmlinux is the
 > OSLoader, and it's not doing the sash thing), and hence, the kernel
 > won't boot.

      Try 

	boot -f bootp()boothost:vmlinux xxx yyy

where boothost is the host from which you want ot boot, and
xxx and yyy are your vmlinux options.  The "-f" avoids using OSLoader.

...
 > Also, on the working machine, is there a better way to boot it than
 > telling it to 'boot bootp():vmlinux' each time? Again, working with one
 > disk per machine, IRIX is gone (but I didn't blow sash away on this
 > one).

      You should be able to do something like:

	setenv -p OSLoadPartition bootp()
	setenv -p OSLoadFilename :vmlinux
	setenv -p OSLoadOptions auto
	setenv -p AutoLoad Y	

Without the system partition, you might be able to do

	setenv -p SystemPartition bootp()
	setenv -p OSLoader :vmlinux