[jan-jaap]

I'm trying to restore this ancient machine (a 4D/70 GT) to working order. When I got it, it wasn't functional. It may even have been used as a parts donor.

But I got past the obvious, like the malfunctioning power supply and broken fans. The machine will power up and POST:



I can boot it in single user mode to a login prompt on the graphics console. But when I try to boot to the standard NeWS or X11 login, I get a bus error on an address related to the GM1 board and the machine panics.

I tried swapping the IP4 CPU board and the GM1 board. No result. I do not have any other spare parts for this machine.

I pulled the GT graphics boards, and installed them in a PowerSeries. That is, all of them except the GM1 board, because a PowerSeries has a different backplane and requires a GM2 board. The result is a PowerSeries GTX. It works and doesn't suffer from pixel errors. It passes the Field diagnostics. So the GE4, RM1 and RV boards of the GT graphics card set should be good.

The Professional IRIS itself passes the 'ide' diagnostics, but those do not exercise the graphics. But I think the IP4 CPU board(s) should be good too.

This only leaves the GM1 Geometry Manager board.

I have a hard time believing I somehow have two GM1 boards broken in exactly the same way. I suspect an incompatibility between the system firmware revision and the GT graphics board set. There are four EPROM chips on the IP4 board: 070-0093-010, 070-0094-010, 070-0095-010 and 070-0096-010. The PROM version is:

Code:

Version 4D1-3.1 PROM IP4 OPT Thu Dec 8 16:12:10 PST 1988 SGI

This predates the GT graphics. I do not have the older 'G' graphics to confirm, and parts for this machine are not easily found (to put it mildly).

So, how to proceed? I can see a few options:

• Someone has a Professional IRIS which works or used to work. We compare part numbers, and possibly eliminate my suspected incompatibility.
  
• Someone has an IP4 CPU board with later firmware than mine. We dump it and I try again.
  
• If someone knows someone who has one of these, please forward me their email address. There are very few people left who have one of these things.
  
• I'm open to suggestions.
  

Help!

[dexter1]

Hey Jan-Jaap,

I believe we have had this topic on Nekochan forum a while ago. But if the GT boardset is generally okay, we need to find an IP4.
From Alex Corda's FAQ you need a 12.5 MHz R2000. But i guess you aren't picky and would be happy with anything.

I remember several years ago the shop VT100 in The Hague, who had a blue-hat twin-tower in the window of the store. No idea where that critter went. Also, no idea where that shop went as well They had some groovy vintage stuff.

From Gerhard's site this snippet is interesting: "Apparently Clover 1 graphics subsystems were common on 4D/50, 4D/60 and 4D/70 systems while Clover 2 was usually found in the newer 4D/70, 4D/80 and 4D/85."
So this seems to indicate that the GT was delivered with newer 4D/70 systems, and therefore your assesment of a PROM version difference seems plausible.

Any luck with memory tests on the GT diagnostics port?

[jan-jaap]

Hey Jan-Jaap,

I believe we have had this topic on Nekochan forum a while ago. But if the GT boardset is generally okay, we need to find an IP4.
From Alex Corda's FAQ you need a 12.5 MHz R2000. But i guess you aren't picky and would be happy with anything.

I remember several years ago the shop VT100 in The Hague, who had a blue-hat twin-tower in the window of the store. No idea where that critter went. Also, no idea where that shop went as well They had some groovy vintage stuff.

From Gerhard's site this snippet is interesting: "Apparently Clover 1 graphics subsystems were common on 4D/50, 4D/60 and 4D/70 systems while Clover 2 was usually found in the newer 4D/70, 4D/80 and 4D/85."
So this seems to indicate that the GT was delivered with newer 4D/70 systems, and therefore your assesment of a PROM version difference seems plausible.

Any luck with memory tests on the GT diagnostics port?

I think VT100 disappeared years ago. Blue tophat means VGX so that was probably a PowerSeries. I've got enough of those

This system came to me as a 4D/50 GT, so it had an 8MHz IP4 (030-0121-001). I later bought a 12.5MHz IP4 CPU board (030-0011-001), so from a 4D/70. Both have the same firmware part#: 070-009x-010. The photo on Gerhard Lenerz site shows an IP4 from a 4D/50 with 070-009x-009 firmware, apparently that system has "G" graphics.

Here are some photos, beware they are 2MB each:

IP4 w./ 8MHz R2000 (4D/50), part# 030-0121-001



IP4 w./ 12.5MHz R2000 (4D/70), part# 030-0011-001


There are also a lot of jumpers on these boards. My 4D/50 board seems to match the board on Gerhard Lenerz site.

I didn't connect to the GM1 diagnostics port yet. Tried that once with a VGX and I didn't get very far.

[CB_HK]

There are also a lot of jumpers on these boards. My 4D/50 board seems to match the board on Gerhard Lenerz site.

I didn't connect to the GM1 diagnostics port yet. Tried that once with a VGX and I didn't get very far.

While I have absolutely no expertise in this area (and its debatable what I do have when it comes to SGI) I would say that hooking up to the diagnostics port should at the very least let you know if the board itself is alive and if it's having any particular issues. When I hook up to my VGXT setup I can see all the boards going through their boot phase and I get a pass indication. Not sure if that's completely applicable to your case but it could at least help narrow things down a tiny bit more. Not sure if you had any trouble when you tried it yourself--I used the standard SGI terminal settings.

I hope someone here is able to get you the info you need. That's a really cool machine and I'd love to see it up and running.

[jan-jaap]

By popular demand: the GM monitor

Upon power-on it spits this out. Takes only a fraction of a second:

Code:

PASS: GM UART okay; about to test the first location in DRAM.
PASS: GM DRAM okay; about to initialize DRAM global variables.

Loading PP ucode Version:  @(#) PEAPOD 1.2 pp microcode assembler - 6/20/87
Wed Dec  9 16:59:30 1987 user unknown revision(1.74)

PASS: PP SRAM okay.
PASS: GM SRAM Word Count register okay.
PROM diags completed.

Prom revision Thu Jan 14 17:09:34 PST 1988.

Clearing power-on Host interrupt (level 6).

Clearing power-on Retrace interrupt (level 5).

Clearing power-on Fifo interrupt (level 4).

Clearing power-on PP interrupt (level 2).

gm>

Let's get some help:

Code:

gm>  ?
        GM monitor commands (default for optional size {b|w|l} is word)

b{s|d|q} [addr]         Set, delete, or query breakpoints.

c       Continue a program at the current pc.

d{b|w|l} [addr1][addr2][count]
        Dumps memory by bytes, words, or longs, from addr1 to addr2;
        the dump may be repeated count times.

e{b|w|l} [address][actions]
        Queries and/or sets memory beginning at the given address,
        in byte, word, or long format.

f{b|w|l} [addr1][addr2][data][increment][count]
        Fills memory as bytes, words, or longs, from addr1 to addr2,
        using data as the fill value, optionally incremented by increment;
        the fill may be repeated count times.

g [address][arguments]
        Go: program execution will begin at address (if given) or at the
        current pc: arguments (if given) will be passed to the program.

Type <cr> to continue, <q> to return to the monitor: 

h       This help message is printed.

q       Quit: Forces a hard reset.

r       Dumps 68020 processor registers (data, address, pc, sr).

s       Single-step the suspended program.

t [test mask][addr1][addr2][count]
        Tests memory from addr1 to addr2;
        the tests may be repeated count times.  The possible tests are:

        Mask bit 0 - All 0 Test
        Mask bit 1 - All 1 Test
        Mask bit 2 - Alternate All 0/All 1
        Mask bit 3 - Alternate 55555555/AAAAAAAA
        Mask bit 4 - Forward Address Test
        Mask bit 5 - Backwards Address Test
        Mask bit 6 - Marching Ones Test
        Mask bit 7 - Marching Zeros Test

Type <cr> to continue, <q> to return to the monitor: 

u       A suspended program's stack is unwound and printed out.

z[addr] Disassemble memory, starting at the specified address.

gm>

I tried 'q' which resets the GM and 'r' which dumps some hex numbers. Lacking any other documentation, this isn't going anywhere.
Oh, the memory test works:

Code:

gm> t ff
Defaulting to infinite DRAM test.
Testing memory from 0x9803F000 to 0x980FEFFC
01234567
PASS: memory test mask 0xFF (pass 1)
01234567
PASS: memory test mask 0xFF (pass 2)
01234567
PASS: memory test mask 0xFF (pass 3)
01234567
PASS: memory test mask 0xFF (pass 4)
01234567
(... etc ...)

---

The host side. I started it with the keyboard, mouse disconnected in order to force console on serial and avoid a crash on bootup. Then start X11 manually (IRIX 4.0.5). This causes the crash:

Code:

IRIS 3# /usr/gfx/startgfx
Sent SIGHUP to xdm
IRIS 4# Bus Error: Parity Error Bits: 0x0:  physaddr:0x1DF0000C

PANIC: KERNEL FAULT
PC: 0x8001FD1C ep:800FE198
EXC code:28, `Data Bus Error '
Bad addr: 0x10019000, cause: 0x3000041C<CE1,CE0,IP3>
sr: 0xF804<IM7,IM6,IM5,IM4,IM3,IEp>


dumping to dev 0x1621 at block 48798, numpages 4095
................................................................
dump completed

This was with the 12 MHz IP4 board installed (4D/70):

Code:

1 12 MHZ IP4 Processor
FPU: MIPS R2010 VLSI Floating Point Chip Revision: 2.0
CPU: MIPS R2000 Processor Chip Revision: 5.0
On-board serial ports: 4
Data cache size: 32 Kbytes
Instruction cache size: 64 Kbytes
Main memory size: 16 Mbytes
ENP-10 Ethernet controller: enp0, firmware version 4 (SGI)
GT Graphics option installed
Disk drive: unit 1 on SCSI controller 0
Integral SCSI controller 0: Version WD33C93

Interestingly, the GM1 monitor output lists "Dec '87 / Jan '88" as creation date, which suggests that my IP4 PROM (from Dec '88) should work.

I wonder what's going on here. I'll double check the backplane VME jumpers, but the boards are installed as documented in the Hardware Developer's Handbook: (1) IP4, (2) ENET, (8) GE, (9) GM, (10) RM, (11) RV, (12) RM. There's nothing like missing bulkhead covers or unused cables to suggest that more cards were installed at some point.

[jan-jaap]

I ran dbx on the vmcore of the kernel crash and got:

Code:

____ Trace & Exception Frame Registers _________________________________________

SP=800fe030 fp=0 pc=800284f0
>  0 syncreboot(0x0, 0x0, 0x0, 0x0, 0x800fe070, 0xc001) ["prf.c":709, 0x800284ec]
   1 icmn_err(0x0, 0x0, 0x0, 0x0, 0xc001, 0x80028dd8) ["prf.c":197, 0x80026344]
   2 cmn_err(0x0, 0x0, 0x0, 0x0, 0x800fe198, 0x1c) ["prf.c":84, 0x80025ffc]
   3 panicregs(0x0, 0x0, 0x0, 0x0, 0x800fc3c4, 0x3000141c) ["trap.c":171, 0x80028dd4]
   4 k_trap(0x0, 0x0, 0x0, 0x0, 0x1df00000, 0xa0000000) ["trap.c":291, 0x8002915c]
   5 .trap.trap(0x0, 0x0, 0x0, 0x0, 0x1, 0x0) ["trap.c":326, 0x800291d4]
found VEC_trap, using trap frame to find next function

  0: 800fe198 ffffb0a0 0000f804 3000141c
  4: 00000001 00000000 540be400 00000010
  8: 00000000 0000ff34 00000400 9805f000
 12: 00000000 801213a8 20000038 20000030
 16: ff87c700 0000000c 1df0000c 00000006
 20: bf840003 1df00000 a0000000 800fb2a0
 24: ffffb0a0 0000ff34 ffffec0c bdf0000c
 28: 8001fc88 00000000 ffffec0c 0000fc01
 32: 800fe244 00000000 8001fd00 0000f804
 36: 9805f000 00000000 10012000 3000141c
 40: 8001fd1c 00000000 8001eaf8
 Frame Pointer 0x800fe244 pc 0x80018b58
   6 vme_dispatch(0x0, 0x0, 0x0, 0x0, 0x801213a8, 0x8001fbd8) ["IP4.c":292, 0x8001fd18]
   7 vme_intr(0xff34, 0xffffec0c, 0xbdf0000c, 0x8001fc88, 0x156, 0x80347ab8) ["IP4.c":261, 0x8001fc9c]
   8 intr(0xff34, 0xffffec0c, 0xbdf0000c, 0x8001fc88, 0x0, 0x0) ["IP4.c":196, 0x8001fbd4]
   9 VEC_int(0xff34, 0xffffec0c, 0xbdf0000c, 0x8001fc88, 0xffffffff, 0xffff0000) ["IP4.O/clocore.s":3313, 0x80018998]

I'm crashing in a VME interrupt handler. Had a look at the backplane jumpers for VME IACK and VMA BG (bus grant) and they were not at all like  "this old SGI" documents. Changed them to be exactly like the 4D FAQ, even moved the ENET card to slot 6, and it doesn't crash anymore!

Unfortunately, it also still doesn't start the graphics desktop  :(  Starting from the graphics console (textport), it simply blanks the display when it should start the graphics login screen. Login using serial console or telnet works. I'm getting closer, but no cigar yet ...

[CB_HK]

I ran dbx on the vmcore of the kernel crash and got:

Code:

____ Trace & Exception Frame Registers _________________________________________

SP=800fe030 fp=0 pc=800284f0
>  0 syncreboot(0x0, 0x0, 0x0, 0x0, 0x800fe070, 0xc001) ["prf.c":709, 0x800284ec]
   1 icmn_err(0x0, 0x0, 0x0, 0x0, 0xc001, 0x80028dd8) ["prf.c":197, 0x80026344]
   2 cmn_err(0x0, 0x0, 0x0, 0x0, 0x800fe198, 0x1c) ["prf.c":84, 0x80025ffc]
   3 panicregs(0x0, 0x0, 0x0, 0x0, 0x800fc3c4, 0x3000141c) ["trap.c":171, 0x80028dd4]
   4 k_trap(0x0, 0x0, 0x0, 0x0, 0x1df00000, 0xa0000000) ["trap.c":291, 0x8002915c]
   5 .trap.trap(0x0, 0x0, 0x0, 0x0, 0x1, 0x0) ["trap.c":326, 0x800291d4]
found VEC_trap, using trap frame to find next function

  0: 800fe198 ffffb0a0 0000f804 3000141c
  4: 00000001 00000000 540be400 00000010
  8: 00000000 0000ff34 00000400 9805f000
 12: 00000000 801213a8 20000038 20000030
 16: ff87c700 0000000c 1df0000c 00000006
 20: bf840003 1df00000 a0000000 800fb2a0
 24: ffffb0a0 0000ff34 ffffec0c bdf0000c
 28: 8001fc88 00000000 ffffec0c 0000fc01
 32: 800fe244 00000000 8001fd00 0000f804
 36: 9805f000 00000000 10012000 3000141c
 40: 8001fd1c 00000000 8001eaf8
 Frame Pointer 0x800fe244 pc 0x80018b58
   6 vme_dispatch(0x0, 0x0, 0x0, 0x0, 0x801213a8, 0x8001fbd8) ["IP4.c":292, 0x8001fd18]
   7 vme_intr(0xff34, 0xffffec0c, 0xbdf0000c, 0x8001fc88, 0x156, 0x80347ab8) ["IP4.c":261, 0x8001fc9c]
   8 intr(0xff34, 0xffffec0c, 0xbdf0000c, 0x8001fc88, 0x0, 0x0) ["IP4.c":196, 0x8001fbd4]
   9 VEC_int(0xff34, 0xffffec0c, 0xbdf0000c, 0x8001fc88, 0xffffffff, 0xffff0000) ["IP4.O/clocore.s":3313, 0x80018998]

I'm crashing in a VME interrupt handler. Had a look at the backplane jumpers for VME IACK and VMA BG (bus grant) and they were not at all like  "this old SGI" documents. Changed them to be exactly like the 4D FAQ, even moved the ENET card to slot 6, and it doesn't crash anymore!

Unfortunately, it also still doesn't start the graphics desktop  :(  Starting from the graphics console (textport), it simply blanks the display when it should start the graphics login screen. Login using serial console or telnet works. I'm getting closer, but no cigar yet ...

Awesome! I'm glad to see that you've been able to solve that issue.

As for the lack of graphic console, this may be a silly idea, but does the system need an "install" for the new graphics boards? I've read that IRIX will throw a fit if you swap out graphics systems and don't force a new kernel build so that it knows what graphics are installed and how to address them. No doubt you're familiar with that already--just wanted to mention it.

Good luck!

[jan-jaap]

As for the lack of graphic console, this may be a silly idea, but does the system need an "install" for the new graphics boards? I've read that IRIX will throw a fit if you swap out graphics systems and don't force a new kernel build so that it knows what graphics are installed and how to address them. No doubt you're familiar with that already--just wanted to mention it.

Good luck!

I think it has everything, after all it never had a problem detecting the boards. They always were in 'hinv'.

I have the feeling I still have an interrupt problem because the system is extremely sluggish while idle. I know it's only a 12 MHz CPU but I think it wasn't quite that unresponsive earlier on.

The problem is I bought a defective system some years ago, from an era before people would discuss things like this on the open internet. The only documentation is "This Old SGI" a.k.a. the 4D Faq, written by someone who admits he pieced together his own system from scrap bits, some posts in Usenet archives, and the Hardware Developer Handbook. And they disagree.

So, step #1: examine what we have.
I have a 12-slot twin tower Professional IRIS. It was known-defective: the PSU made terrible noises, one of the blowers was defective. It has the pink/purple top hat of a Professional IRIS with "B" or "G" graphics.



Inside: a GT graphics card set with burnt out RM1 raster managers, and an 8MHz IP4 CPU card. You could say this is a 4D/50 'B' or 'G', upgraded to GT later. Could also be that the system died and someone pulled the original graphics boards to save another system, leaving this system with a dead GT board set. Additionally, this is a photo of the backplane jumper positions:



Which brings us to step #2: analysis.
First of all, I've pretty much neglected VME jumpers so far. I've had PowerSeries for nearly 20 years, added VME boards in them several times and never touched a VME jumper. As long as you install boards left-to-right it "just works". In these systems, the main system bus is the "PowerPath" bus which connects CPU, MEM, IO and GFX boards. The VME bus is a secondary bus, bridged to the system by the IO board. You cannot screw up the core of the system with bad VME configuration because it's not on the VME bus to begin with. With the Professional IRIS, the VME bus *is* the system bus so there is no room for error.

This is what the Hardware Developer Handbook (HDH) has to say:



As I read this, some of the VME signals pass through every card as they are daisy chained on the bus, and when no card is present these signals have to be jumpered or the signal won't be passed along. Additionally, this is how the boards are supposed to be installed, again the Hardware developer Handbook:



Now, look at the jumpers as they were before. VME slots 2 .. 5 are jumpered, so should be empty. But there is an ENET card in slot #2 (correct position). Slots 6 and 7 are not jumpered but also no card was present, which means the VME IACK and BG signals will not reach slot 8 and beyond. This is unfortunate, because that's where the graphics are ... My system doesn't have ESDI, only SCSI, so I do not expect anything in slot #3.

Looking at it like this, it's no surprise I had some problems 

Which brings me to step 3: making it work

Initially, I removed the jumpers from slot 2, and jumpered slot 6 and 7. This fixed my kernel crash (yay!). I have windowsystem and xdm chkconfig-ed 'on', but startgfx would now result in periodic messages about a FIFO timeout while being more than half full (or similar). On to the 4D Faq, which says this: http://archive.irix.cc/thisoldsgi/#backplane

Note two things:

1. "The rule of thumb for most VME systems is to install backplane jumpers in unused slots. The only exception to this rule for the 4D appears to be for the GE4 card." 
   
2. The ENET card is in slot 6, which has a different VME P2 connection to the CPU card than slot 2.
   

So, jumpered the GE slot (slot 8). I can somewhat explain why this might be necessary: the host (IP4) does not communicate with the GE4 directly, but through the GM1 board. GE and GM are connected at the front side by an interconnect. It quite is possible the GE uses the VME P1, P2 connectors only for power, and only talks to the GM via the front side interconnect, and via VME P3 to the RM/RV boards. With the GE in slot 8 and GM in slot 9, you'd have to jumper 8 to reach 9 from the CPU (in slot 1).

This resulted in the behavior I described yesterday: startgfx blanks the screen but nothing else happens. No crashes, no FIFO messages. Sluggish. Better, but not quite there yet. I did try another screen, btw.

So finally, I moved ENET to slot 6 and adjusted the jumpers to match that. This didn't result in any changes. Oh, ethernet works in both slots, I can transfer files to/from the network.

So that's where I am. I think the solution is in the jumpers. I think I still have a problem with interrupts because the system is sluggish while idle. I cannot match the original jumper settings to anything documented by either the HDH or the 4Dfaq. Not even if you'd imagine the system with 'B' or 'G' graphics installed which the tophat skins suggests it once had.

I have a spare GM and IP4 to play with, possibly another GE, but I'm pretty sure the rest of the GFX boards are good since they tested good in a PowerSeries. There's only a finite number of jumper positions, even if I get creative with jumpers in the GFX slots.

But what would be most helpful is if someone with a similar system would stand up and tell me how their backplane is jumpered. You don't need to touch the cardcage for that, the jumpers are on the reverse side (the front side of the system). Just remove the front skin panel and open the card cage front panel.

NB: it could even be there's a problem with my PROM monitor (NVRAM) settings. NVRAM is dead on this thing; I have to toggle values in every time it's powered on. I use these values:

Code:

netaddr=192.0.2.1
dbaud=9600
rbaud=1200
bootfile=dksc(0,1,8)sash
bootmode=m
console=G
root=dks0d1s0
keybd=df
monitor=60
sync_on_green=y
diskless=0
path=dksc(0,1,8)
dbootfile=/stand/ide

Using a value like 'h' for 'monitor' (like an Indy) results in a message about an incorrect 'monitor' value when you run startgfx, so it absolutely checks these values. 'unsetenv monitor' in PROM results in the PROM setting it to '60' so I assume it's the default. My PowerSeries seem to use that value too.

[Jacques]

I'm the least qualified person to comment on this, but this just shouts software rather than hardware to me...?

Does 4.05 have a complete gfx subsystem set installed by default? I'm thinking VPro / IMPACT driver scenario in 6.5...?

And...have you checked in at Mood Indigo forum? There are still some folks floating around there...

Btw - really good thread, could happuily sit down with popcorn and a beer and watch it unfold!  

[jan-jaap]

It's alive !
I took the HDH text to the letter and jumpered all slots except 1 (IP4), 6 (ENET) and 9 (GM1)

This didn't change anything, but because I had the console set to 'd' I captured the FIFO message:

Code:

WARNING: Graphics timeout (FIFO still > half full)!

Google gives exactly one hit: someone who complained that his graphics had died.
So I exchanged the one board I had my doubts about from the beginning: the GM1. And it worked



As you can see I still have work to do, but at least I have a working system so it'll be worth it.



Thanks guys, I'll go have a beer now