Partial Success Report

Partial Success Report

[Jeff Coffin]

Hi All, 

I've been reading this list for the past many months as I slowly and
infrequently try to bring a dead Indy R5000 back to life, then get
Linux up on it.  The box had a dead disk and still has a bad graphics
board, but I've managed to get IRIX installed and operational on one
disk, another one installed and fx'd from IRIX; all from the serial
console (minicom) and remote X on my x86 Linux (RedHat 5.1) box.

I think there's something very wrong with the gfx card 'cause when I
try to start X under IRIX it complains about a failed context switch
and loops with the same error message for a few iterations, then
hangs. (Sorry I don't have the message with me, it's at home.  I can
post tonight it if it's relevant)

Last night I got the HardHat kernel to boot via the bootp method
described in the Howto and, as expected from the experiences of
Richard Hartensveld, it hung looking for a console.  I then grabbed
newer kernels (2.1.116 and 2.1.121) from the /pub/test on the ftp
server and attmepted to get them loaded by the same mechanism, but
both of them hang after loading via tftp.

I don't know where to go from here, so I'm looking for ideas.  Hinv
and the boot log from the hardhat kernel boot are below.

I'm thinking about removing the gfx board entirely and seeing if that
has any effect, will that do me any good?

Any help or suggestions would be appreciated.


--jeff


>> hinv
              System: IP22
           Processor: 180 Mhz R5000, with FPU
Primary I-cache size: 32 Kbytes
Primary D-cache size: 32 Kbytes
Secondary cache size: 512 Kbytes
         Memory size: 64 Mbytes
            Graphics: GR3-XZ
           SCSI Disk: scsi(0)disk(2)
           SCSI Disk: scsi(0)disk(3)
               Audio: Iris Audio Processor: version A2 revision 4.1.0



boot:
Command Monitor.  Type "exit" to return to the menu.
>> $linux
72912+9440+3024+331696+23768d+3644+5808 entry: 0x8bf9a950
Setting $netaddr to 192.168.0.30 (from server lil)
Obtaining /vmlinux from server lil
PROMLIB: SGI ARCS firmware Version 1 Revision 10
PROMLIB: Total free ram 64270336 bytes (62764K,61MB)
ARCH: SGI-IP22
CPU: MIPS-R5000 FPU<MIPS-R5000FPC> ICACHE DCACHE SCACHE
Loading R4000 MMU routines.
CPU revision is: 00002310.
Primary instruction cache 32kb, linesize 32 bytes)
Primary data cache 32kb, linesize 32 bytes)
Linux version 2.1.100 (root@alex3.med.iacnet.com) (gcc version 2.7.2) #29 Thu J8
MC: SGI memory controller Revision 3
R4600/R5000 SCACHE size 512K, linesize 32 bytes.
calculating r4koff... 000dbda6(900518)
zs0: console input
zs0: console I/O
Calibrating delay loop... 179.81 BogoMIPS
Memory: 60444k/196196k available (1216k kernel code, 2684k data)
Swansea University Computer Society NET3.039 for Linux 2.1
NET3: Unix domain sockets 0.16 for Linux NET3.038.
Swansea University Computer Society TCP/IP for NET3.037
IP Protocols: ICMP, UDP, TCP
Checking for 'wait' instruction...  available.
POSIX conformance testing by UNIFIX
Starting kswapd v 1.5
Adv: about to run setup()
initialize_kbd: Keyboard reset failed, no ACK
SGI Zilog8530 serial driver version 1.00
Keyboard timeout
Keyboard timeout
tty00 at 0xbfbd9838 (irq = 21) is a Zilog8530
tty01 at 0xbfbd9830 (irq = 21) is a Zilog8530
Ramdisk driver initialized : 16 ramdisks of 4096K size
loop: registered device at major 7
WD93: Driver version 1.25 compiled on Jul  7 1998 at 16:59:57
 debug_flags=0x00
wd33c93-0: chip=WD33c93B/13 no_sync=0xff no_dma=0scsi0 : SGI WD93
scsi : 1 host.
 sending SDTR 0103013f0csync_xfer=2c  Vendor: SGI       Model: IBM DORS-32160  D
  Type:   Direct-Access                      ANSI SCSI revision: 02
Detected scsi disk sda at scsi0, channel 0, id 2, lun 0
 sending SDTR 0103013f0csync_xfer=2c  Vendor: SEAGATE   Model: ST31055N        2
  Type:   Direct-Access                      ANSI SCSI revision: 02
Detected scsi disk sdb at scsi0, channel 0, id 3, lun 0
scsi : detected 2 SCSI disks total.
SCSI device sda: hdwr sector= 512 bytes. Sectors= 4197405 [2049 MB] [2.0 GB]
SCSI device sdb: hdwr sector= 512 bytes. Sectors= 2069860 [1010 MB] [1.0 GB]
sgiseeq.c: David S. Miller (dm@engr.sgi.com)
eth0: SGI Seeq8003 08:00:69:0a:43:7c
Sending BOOTP requests.... OK
IP-Config: Got BOOTP answer from 192.168.0.20, my address is 192.168.0.30
Partition check:
 sda: sda1 sda2 sda3 sda4
 sdb: sdb1 sdb2 sdb3 sdb4 sdb5 sdb6
Looking up port of RPC 100003/2 on 192.168.0.20
Looking up port of RPC 100005/1 on 192.168.0.20
VFS: Mounted root (nfs filesystem).
Adv: done running setup()
Freeing unused kernel memory: 44k freed
Warning: unable to open an initial console
                                     

Re: Partial Success Report

[Ulf Carlsson]

Hello,

> Last night I got the HardHat kernel to boot via the bootp method
> described in the Howto and, as expected from the experiences of
> Richard Hartensveld, it hung looking for a console.  I then grabbed
> newer kernels (2.1.116 and 2.1.121) from the /pub/test on the ftp
> server and attmepted to get them loaded by the same mechanism, but
> both of them hang after loading via tftp.

It *should* find an initial console if you have mounted the root filesystem from
the hardhat CD correctly. 

You can probably install hardhat on a i386 box in your local network if you
want, and boot directly into an already installed hardhat via nfs-root. That
hardhat default installer is _very_ annoying, it crashes all the time.. (signal
11, out of memory etc..), I don't know if this would solve your problems - but
it helped me... :)
Give the --root <rootdir> option to rpm, and install the needed rpms from the cd

> I don't know where to go from here, so I'm looking for ideas.  Hinv
> and the boot log from the hardhat kernel boot are below.
> 
> I'm thinking about removing the gfx board entirely and seeing if that
> has any effect, will that do me any good?

It would probably not make much difference, "Warning: unable to open an initial
console" isn't caused by a gfx board neither an old kernel, but from an
incorrect /dev/console.

I'm currently running hardhat diskless, I'm only using the IRIX harddrive when
I boot (the bootp command is loaded from the harddrive).

- Ulf

Re: Partial Success Report

[Jeff Coffin]

Ulf Carlsson <grim@zigzegv.ml.org> writes:

> It *should* find an initial console if you have mounted the root
> filesystem from the hardhat CD correctly. 

Maybe that's the problem, it all *looks* right.  Is this the case for
the harthat kernel as well as the 2.1.116 and 2.1.121 versions off the
FTP server?

Let's see if I have this straight:

from the PROM, it I do

boot bootp():/vmlinux

and NFS is configured properly (more or less as per the HowTo) on the
i386 box, the kernel will boot and find the NFS root filesystem as
configured in exports or do I need to pass the kernel the nfsroot
param to get it to properly mount the install root?

> It would probably not make much difference, "Warning: unable to open
> an initial console" isn't caused by a gfx board neither an old
> kernel, but from an incorrect /dev/console. 

That's what I thought.  I was speculating that the hardware trouble
was causing the kerel hangs.

> I'm currently running hardhat diskless, I'm only using the IRIX
> harddrive when I boot (the bootp command is loaded from the
> harddrive). 

Not from the PROM?  How does that work?  (I'm new to SGI's and getting
IRIX up at all from just a CD and a new hard drive was a "learning
experience") 

I'll play with it some more tonight or tomorrow when i have the time.

Thanks for the suggestions.


--jeff

Re: Partial Success Report

[Ulf Carlsson]

On Thu, Oct 15, 1998 at 04:46:29PM -0700, Jeff Coffin wrote:

> > It would probably not make much difference, "Warning: unable to open
> > an initial console" isn't caused by a gfx board neither an old
> > kernel, but from an incorrect /dev/console. 
> 
> That's what I thought.  I was speculating that the hardware trouble
> was causing the kerel hangs.

Are we sure that the XZ chipset you have is supported? Get a newport one :)

> > I'm currently running hardhat diskless, I'm only using the IRIX
> > harddrive when I boot (the bootp command is loaded from the
> > harddrive). 
> 
> Not from the PROM?  How does that work?  (I'm new to SGI's and getting
> IRIX up at all from just a CD and a new hard drive was a "learning
> experience") 

I thought the bootp command was loaded from the IRIX partition, because it
didn't work when I removed the IRIX harddrive, atleast it didn't with my old
PROM.  It claimed that it couldn't find the bootp() command - maybe I'm out of
my mind, I'll check next time I remove the cover...

- Ulf

XZ

[Jeremy John Welling]

Are XZ graphics supported? 

Re: Partial Success Report

[ralf]

On Fri, Oct 16, 1998 at 09:46:59PM +0200, Ulf Carlsson wrote:

> I thought the bootp command was loaded from the IRIX partition, because it
> didn't work when I removed the IRIX harddrive, atleast it didn't with my old
> PROM.  It claimed that it couldn't find the bootp() command - maybe I'm out of
> my mind, I'll check next time I remove the cover...

bootp() is just a ARC filename which is either interpreted by the PROM
command interpreter or by sash where sash afaik is nothing other than the
PROMs compiled with special flags.

  Ralf

Re: Partial Success Report

[Thomas Bogendoerfer]

On Thu, Oct 15, 1998 at 01:50:31PM -0700, Jeff Coffin wrote:
> Last night I got the HardHat kernel to boot via the bootp method
> described in the Howto and, as expected from the experiences of
> Richard Hartensveld, it hung looking for a console.

Could you please lookup major and minor number of /dev/console on
your root filesystem ? It should be major 5 and minor 2 to work
properly with the serial console.

>  I then grabbed
> newer kernels (2.1.116 and 2.1.121) from the /pub/test on the ftp
> server and attmepted to get them loaded by the same mechanism, but
> both of them hang after loading via tftp.

please try to boot these kernels with bootp()/vmlinux console=ttyS0 (also
try ttyS1) and a terminal hooked up to one of the serial ports (in .116
ttyS0 is port 2 and ttyS1 is port 1; I've changed that in .121, but I'm not
sure if this fix is already in the precompiled kernel). It's possible, 
that I've messed up the card detection so, that it panics, when there is 
no newport installed.

Thomas.

-- 
   This device has completely bogus header. Compaq scores again :-|
It's a host bridge, but it should be called ghost bridge instead ;^)
                                        [Martin `MJ' Mares on linux-kernel]

Re: XZ

[Thomas Bogendoerfer]

On Fri, Oct 16, 1998 at 09:15:22PM -0400, Jeremy John Welling wrote:
> Are XZ graphics supported? 

If XZ isn't another name for newport, then no.

Thomas.

-- 
   This device has completely bogus header. Compaq scores again :-|
It's a host bridge, but it should be called ghost bridge instead ;^)
                                        [Martin `MJ' Mares on linux-kernel]

Re: XZ

[ralf]

On Sat, Oct 17, 1998 at 11:17:25AM +0200, Thomas Bogendoerfer wrote:

> If XZ isn't another name for newport, then no.

XL is the official name for the Newport.

  Ralf

Re: Partial Success Report

[Ulf Carlsson]

On Sat, Oct 17, 1998 at 04:01:48AM +0200, ralf@uni-koblenz.de wrote:
> On Fri, Oct 16, 1998 at 09:46:59PM +0200, Ulf Carlsson wrote:
> 
> bootp() is just a ARC filename which is either interpreted by the PROM
> command interpreter or by sash where sash afaik is nothing other than the
> PROMs compiled with special flags.

The command 'boot bootp():' requires a harddrive, but I can run 'bootp():'
diskless. Does the 'boot' part of the command tell the PROM to use sash?

- Ulf

Re: XZ

[George Kyriazis]

In a previous episode, ralf@uni-koblenz.de claimed:
> On Sat, Oct 17, 1998 at 11:17:25AM +0200, Thomas Bogendoerfer wrote:
> 
> > If XZ isn't another name for newport, then no.
> 
> XL is the official name for the Newport.
> 
I am not familiar with what Linux exactly is ported on, but my guess would be
only Newport.

XZ is a non-Newport based card for Indy.  XZ has more-or-less the same
internal architecture as Elan/Extreme, so it's probably a safe bet that
is it not supported.

  --george
-- 
-----------------------------------------------------------------------------
George Kyriazis  | Silicon Graphics, Inc., 8U-590 |  kyriazis@sgi.com
                 | 2011 N. Shoreline Blvd.        |  650-933-2828
                 | Mt. View, CA 94043             | 

Re: XZ

[ralf]

On Sun, Oct 18, 1998 at 10:32:26AM -0700, George Kyriazis wrote:

> In a previous episode, ralf@uni-koblenz.de claimed:
> > On Sat, Oct 17, 1998 at 11:17:25AM +0200, Thomas Bogendoerfer wrote:
> > 
> > > If XZ isn't another name for newport, then no.
> > 
> > XL is the official name for the Newport.
> > 
> I am not familiar with what Linux exactly is ported on, but my guess would be
> only Newport.
> 
> XZ is a non-Newport based card for Indy.  XZ has more-or-less the same
> internal architecture as Elan/Extreme, so it's probably a safe bet that
> is it not supported.

Correct.

  Ralf

Re: Partial Success Report

[William J. Earl]

ralf@uni-koblenz.de writes:
 > On Fri, Oct 16, 1998 at 09:46:59PM +0200, Ulf Carlsson wrote:
 > 
 > > I thought the bootp command was loaded from the IRIX partition, because it
 > > didn't work when I removed the IRIX harddrive, atleast it didn't with my old
 > > PROM.  It claimed that it couldn't find the bootp() command - maybe I'm out of
 > > my mind, I'll check next time I remove the cover...
 > 
 > bootp() is just a ARC filename which is either interpreted by the PROM
 > command interpreter or by sash where sash afaik is nothing other than the
 > PROMs compiled with special flags.

       That is, bootp() is part of a path.  There is no bootp command.

       sash, unlike most PROMs, has one or more (read-only) disk file
systems bound into it.  On Indy, older sash versions can read efs volumes,
and newer ones can also read xfs volumes.

Re: XZ

[William J. Earl]

ralf@uni-koblenz.de writes:
 > On Sat, Oct 17, 1998 at 11:17:25AM +0200, Thomas Bogendoerfer wrote:
 > 
 > > If XZ isn't another name for newport, then no.
 > 
 > XL is the official name for the Newport.

    XZ is one of the variants of the Elan/Extreme series of cards,
which have one or more geometry engines on the card.  The geometry
engines need microcode downloaded for full functionality, and the
interfaces are not externally documented, so it is hard to build
linux support without access to the IRIX source for reference.

Re: Partial Success Report

[William J. Earl]

Ulf Carlsson writes:
 > On Sat, Oct 17, 1998 at 04:01:48AM +0200, ralf@uni-koblenz.de wrote:
 > > On Fri, Oct 16, 1998 at 09:46:59PM +0200, Ulf Carlsson wrote:
 > > 
 > > bootp() is just a ARC filename which is either interpreted by the PROM
 > > command interpreter or by sash where sash afaik is nothing other than the
 > > PROMs compiled with special flags.
 > 
 > The command 'boot bootp():' requires a harddrive, but I can run 'bootp():'
 > diskless. Does the 'boot' part of the command tell the PROM to use sash?

      Try

	boot -f bootp():

This avoids trying to load sash.

Re: XZ

[Fernando D. Mato Mira]

At 05:15 PM 10/18/98 -0700, you wrote:
>    XZ is one of the variants of the Elan/Extreme series of cards,
>which have one or more geometry engines on the card.  The geometry
>engines need microcode downloaded for full functionality, and the
>interfaces are not externally documented, so it is hard to build
>linux support without access to the IRIX source for reference.

What about just getting the console running (no X server)?
How do GR2 (Indigo Elan) and GR3 (Indigo II Elan) differ in terms of
programming?



Fernando D. Mato Mira                    
Real-Time SW Eng & Networking            
Advanced Systems Engineering Division
CSEM - Centre Suisse d'Electronique et de
Microtechnique                                 
Jaquet-Droz 1                         email:  matomira@acm.org
CH-2007 Neuchatel                       tel: +41 (32) 720-5157
Switzerland                             FAX: +41 (32) 720-5720

<http://www.csemne.ch/>www.csem.ch                  <http://www.vrai.com/>w
ww.vrai.com              
<http://ligwww.epfl.ch/matomira.html>http://ligwww.epfl.ch/matomira.html  

Re: XZ

[George Kyriazis]

In a previous episode, Fernando D. Mato Mira claimed:
> At 05:15 PM 10/18/98 -0700, you wrote:
> >    XZ is one of the variants of the Elan/Extreme series of cards,
> >which have one or more geometry engines on the card.  The geometry
> >engines need microcode downloaded for full functionality, and the
> >interfaces are not externally documented, so it is hard to build
> >linux support without access to the IRIX source for reference.
> 
> What about just getting the console running (no X server)?
> How do GR2 (Indigo Elan) and GR3 (Indigo II Elan) differ in terms of
> programming?
> 
I did some asking around.  Here's what I found:

* In order to do anything, you have to download microcode.

* The monitor PROM downloads a mini-microcode that could be used.  I am
  not sure what the entry points look like to the PROM.  I think this
  is the safest bet.

* The full-functioning microcode (that does 3d) is downloaded at boot
  time before the X server initializes.
 
* The people that I asked are not clear about the programming differences
  between GR2 and GR3.  Certainly they are the same for OpenGL-level
  programming.  My guess is that there are differences in the CPU interfacing
  and video back end.  User-level code is the same, but kernel initialization
  and management code may be different.

* Getting things up and running on a GR-type (Express) architecture is 
  definetely more difficult than Newport.

* Documentation will be hard to find.  Documentation for programming the
  microcoded engines, even harder.  You could, of course, use the existing
  microcode.

  --george
-- 
-----------------------------------------------------------------------------
George Kyriazis  | Silicon Graphics, Inc., 8U-590 |  kyriazis@sgi.com
                 | 2011 N. Shoreline Blvd.        |  650-933-2828
                 | Mt. View, CA 94043             | 

Re: XZ

[George Kyriazis]

In a previous episode, Fernando D. Mato Mira claimed:
> At 05:15 PM 10/18/98 -0700, you wrote:
> >    XZ is one of the variants of the Elan/Extreme series of cards,
> >which have one or more geometry engines on the card.  The geometry
> >engines need microcode downloaded for full functionality, and the
> >interfaces are not externally documented, so it is hard to build
> >linux support without access to the IRIX source for reference.
> 
> What about just getting the console running (no X server)?
> How do GR2 (Indigo Elan) and GR3 (Indigo II Elan) differ in terms of
> programming?
> 
I did some asking around.  Here's what I found:

* In order to do anything, you have to download microcode.

* The monitor PROM downloads a mini-microcode that could be used.  I am
  not sure what the entry points look like to the PROM.  I think this
  is the safest bet.

* The full-functioning microcode (that does 3d) is downloaded at boot
  time before the X server initializes.
 
* The people that I asked are not clear about the programming differences
  between GR2 and GR3.  Certainly they are the same for OpenGL-level
  programming.  My guess is that there are differences in the CPU interfacing
  and video back end.  User-level code is the same, but kernel initialization
  and management code may be different.

* Getting things up and running on a GR-type (Express) architecture is 
  definetely more difficult than Newport.

* Documentation will be hard to find.  Documentation for programming the
  microcoded engines, even harder.  You could, of course, use the existing
  microcode.

  --george
-- 
-----------------------------------------------------------------------------
George Kyriazis  | Silicon Graphics, Inc., 8U-590 |  kyriazis@sgi.com
                 | 2011 N. Shoreline Blvd.        |  650-933-2828
                 | Mt. View, CA 94043             | 

Re: XZ

[ralf]

On Mon, Oct 19, 1998 at 12:53:40PM -0700, George Kyriazis wrote:

> * The monitor PROM downloads a mini-microcode that could be used.  I am
>   not sure what the entry points look like to the PROM.  I think this
>   is the safest bet.

> * Documentation will be hard to find.  Documentation for programming the
>   microcoded engines, even harder.  You could, of course, use the existing
>   microcode.

For now that looks like the best strategy.  Anyway, as step one all we
want is text output.  This can be achived by using the ARC firmware.
That may be slow, but it's working and it gives us an instant driver for
any number of console devices people might have come up with in the past.
The Sparc guys, btw already have a prom console driver.

  Ralf

Re: Partial Success Report

[Jeff Coffin]

Fogot to CC the list on this....

Thomas Bogendoerfer <tsbogend@alpha.franken.de> writes:

> Could you please lookup major and minor number of /dev/console on
> your root filesystem ? It should be major 5 and minor 2 to work
> properly with the serial console.

I fixed it, do I need to change systty too perhps?:

[root@lil dev]# ls -l
total 0
crw-------   1 root     disk       5,   2 Oct 21 13:25 console
crw-------   1 root     disk       4,   0 May 11 08:48 console.dist
crw-rw-r--   1 root     root       1,   3 May 11 08:48 null
brw-r-----   1 root     disk       1,   1 May 11 08:48 ram
crw-------   1 root     disk       4,   0 May 11 08:48 systty
crw-------   1 root     root       4,   1 May 11 08:48 tty1
crw-------   1 root     root       4,   2 May 11 08:48 tty2
crw-------   1 root     root       4,   3 May 11 08:48 tty3
crw-------   1 root     root       4,   4 May 11 08:48 tty4
crw-------   1 root     root       4,   5 May 11 08:48 tty5

> please try to boot these kernels with bootp()/vmlinux console=ttyS0 (also
> try ttyS1) and a terminal hooked up to one of the serial ports (in .116
> ttyS0 is port 2 and ttyS1 is port 1; I've changed that in .121, but I'm not
> sure if this fix is already in the precompiled kernel). It's possible, 
> that I've messed up the card detection so, that it panics, when there is 
> no newport installed.

Nope, didn't work.  The 116 kernel makes the power light blink red to
green ad infinitum and the 121 version appears to load, but the
console is elsewhere.  I'm using port 1 for the serial connection
(it's setup thusly in the PROM)

The default kernel still boots OK and appears to mount the nfsroot:

Looking up port of RPC 100003/2 on 192.168.0.20
Looking up port of RPC 100005/1 on 192.168.0.20
VFS: Mounted root (nfs filesystem).
Adv: done running setup() 

but then nothing....                                                     

BTW, I'm doing the whole thing from a serial console (minicom).  The
gfx card doesn't work from IRIX either.  One of these days I'll
replace it, but it's not real high on my list of things to buy for
$200+.


--jeff

Re: Partial Success Report

[Thomas Bogendoerfer]

On Wed, Oct 21, 1998 at 05:56:11PM -0700, Jeff Coffin wrote:
> > Could you please lookup major and minor number of /dev/console on
> > your root filesystem ? It should be major 5 and minor 2 to work
> > properly with the serial console.
> 
> I fixed it, do I need to change systty too perhps?:

no, but I've got major and minor wrong. It's major 5 and minor 1.

Thomas.

-- 
   This device has completely bogus header. Compaq scores again :-|
It's a host bridge, but it should be called ghost bridge instead ;^)
                                        [Martin `MJ' Mares on linux-kernel]