[aphelion]

I have an Indy with a 133MHz R4600.  I recently upgraded it--or attempted to--to 256MB of RAM, from the 32 it came to me with.  The RAM is all recognized by the system--at least, hinv in the PROM monitor reports 256MB--but when I try to start an IRIX installation, after it boots into the miniroot and mounts the target partition, it dies with:

Code:

PANIC: IRIX Killed due to internal Error
        at PC:0x881032f4 ep:0x887f1ce8
[Press reset to restart the machine.]

On the off chance that it was a cosmic ray flipping a bit or something, I tried a couple more times, but the same thing happened (although unfortunately, I did not take note of whether the PC and ep values were the same each time).  I did also try with half the RAM removed (the RAM in bank 1, since it's easier to remove), and it at least progressed to the "Inst>" prompt, but I'm under the impression that the more RAM, the better, where later versions of IRIX are concerned, so I didn't proceed.  Instead, I ran IDE from the 6.5.22 overlay 1 disc, and after a while, it started producing screenfuls of identical ECC exceptions, culminating in "ERROR: Failure detected on the CPU base board.":

   

It took some time to get to this point, although I don't know how much, if it's even relevant (I left the room to go do something else once I saw that it was going to take a while to get any output other than the "SGI Version 6.5 IP22 IDE field" banner, hardware inventory, and spinner).

Is this error accurate, or could faulty memory cause IDE to detect a CPU failure?  Also, when I first installed the RAM, hinv only reported 128MB, so I removed and reinstalled the RAM in bank 1 and then all 256MB were detected (I'd forgotten how fiddly those old SIMM slots could be)--could this potentially have shorted and fried something?

[weblacky]

Hi,
In all this you asked about bad RAM causing this but did you ever put back your original 32MB if RAM and then see what happens?

I did not see that in your description. Indy requires FPM PARITY memory and I’m unsure about ECC, I’ve had various issues but perhaps it’s fine.

Please put back the original parts and see what happens. If the same thing happens then the RAM was not the cause and you have something else going on.

[aphelion]

It...had not occurred to me to reinstall the original 32MB, no.  Or maybe it had and I subconsciously rejected it out of hand because I have delicate programmer's fingers and the clips on those SIMM slots are slightly painful.     Either way, I'll try that and report back.

The new RAM is FPM parity RAM, though, at least according to the eBay listing I bought it from.  I've not looked up part numbers to verify, but given that there are nine chips on each SIMM I'm assuming it does have parity, and presumably the fact that the machine boots at all would indicate that it is FPM.  I said "ECC exception" because part of the message from IDE was "Exception: <vector=ECC>", although it also says "parity error" in several other places ("ECC/Parity ERROR on the SysAD bus", "CPU Parity Error Interrupt", etc.)

[robespierre]

The SysAD bus is the MIPS link between the processor and the memory controllers. Errors in DRAM shouldn't cause that problem, although it could trigger it based on the range of addresses of the installed memory.
I believe the diagnostic is accurate that there is a problem on the main board, but it could also be on the processor module or the connectors between them.

[aphelion]

All right, with the original 32MB reinstalled, diagnostics complete with no ECC/parity errors, but instead "ERROR:  Failure detected in SCSI (CTLR#0: device 1 ).".  However, I also replaced the original hard drive with a SCSI2SD, so I suspect the SCSI2SD is just not emulating a hard drive in precisely the way that the diagnostics expect (I double-checked, and I do have "Enable Parity" and "Enable SCSI2 Mode" turned on on the SCSI2SD).

I reinstalled the original 32MB in bank 0, but I switched it over to bank 1 and am now rerunning the diagnostics, admittedly mostly for shits and giggles and I guess on the off chance that 32MB will extend far enough into the address space to trigger the problem.  If it doesn't, maybe I can run it with 128MB in bank 0 and 32 in bank 1?  (I'm assuming you can't mix heterogeneous capacities of RAM in a single bank--and I'm not sure I'd have the patience to try even if you could.)

---

Second diagnostics run was already most of the way through when I made this post... it just finished, with the same SCSI error, but no memory/CPU errors.

[weblacky]

All right, with the original 32MB reinstalled, diagnostics complete with no ECC/parity errors, but instead "ERROR:  Failure detected in SCSI (CTLR#0: device 1 ).".  However, I also replaced the original hard drive with a SCSI2SD, so I suspect the SCSI2SD is just not emulating a hard drive in precisely the way that the diagnostics expect (I double-checked, and I do have "Enable Parity" and "Enable SCSI2 Mode" turned on on the SCSI2SD).

I reinstalled the original 32MB in bank 0, but I switched it over to bank 1 and am now rerunning the diagnostics, admittedly mostly for shits and giggles and I guess on the off chance that 32MB will extend far enough into the address space to trigger the problem.  If it doesn't, maybe I can run it with 128MB in bank 0 and 32 in bank 1?  (I'm assuming you can't mix heterogeneous capacities of RAM in a single bank--and I'm not sure I'd have the patience to try even if you could.)

---

Second diagnostics run was already most of the way through when I made this post...  it just finished, with the same SCSI error, but no memory/CPU errors.

Use this as a starting point: https://github.com/callahan-44/sgivfo/bl...6_Indy.xml

Each 4 consecutive RAM slots is a "BANK", hence two BANKs and YES you can of course use different SIMMs between BANKS as long as you stick with the rule of four of a kind in each BANK.  So all RAM in a BANK must be identical, another bank of course does not needs to be identical in any way to another BANK of RAM.  So you can of course try 32MB and 128MB, filling both BANKS.

[aphelion]

Each 4 consecutive RAM slots is a "BANK", hence two BANKs and YES you can of course use different SIMMs between BANKS as long as you stick with the rule of four of a kind in each BANK.  So all RAM in a BANK must be identical, another bank of course does not needs to be identical in any way to another BANK of RAM.  So you can of course try 32MB and 128MB, filling both BANKS.

Right, that's what I figured--that each bank has to be homogeneous (all four slots filled with 32MB modules, or with 8MB modules, but not a mix of the two) but that the two banks don't both have to be the same size.

I looked at those SCSI2SD settings--I have a v5.2, not a v6, so I think some of them don't apply.  I did have termination turned on, which I didn't realize was wrong, so I turned that off; I already had parity and SCSI2 turned on, so I left those as-is; and I turned on "respond to short SCSI selection pulses" and set the startup delay to 6 seconds as in the XML file.  Reran diagnostics and still got the SCSI error...  but anecdotally it has seemed to work fine; I've actually successfully installed IRIX on it once already, but, well, it was "successful" in that I didn't encounter any disk errors but I think I managed to exclude some required libraries, because X would start, but 4Dwm wouldn't once I logged in (although the terminal would, and when I tried to run 4Dwm from the shell it complained of missing libraries--this was before I added more RAM so I don't think it is related to potential memory corruption/bus issues). I think that's a topic for a different subforum if I can't manage to work it out on my own, though...

[weblacky]

To quickly check that you don’t have a damaged SCSI cable (happens) you can just get a standard 50-pin narrow SCSI ribbon cable and plug it into the mainboard.

Just make sure you have either a terminator at the end of the cable or turn on proper termination on the last device on the chain (bus).

The OEM SCSI cable gets manhandled pretty well and some people just aren’t gentle with it. You may have a slight, scratch, nick, abrasion, whatever on the cable that causes issues.

Just try a generic SCSI first to check that first (easy test). If that doesn’t get it then I’d start to worry.