Indy R5K 6.5.22 Install issues - Printable Version
+- IRIX Network Forums (//forums.irixnet.org)
+-- Forum: SGI/MIPS (//forums.irixnet.org/forum-3.html)
+--- Forum: Beginners' Questions/Tips (//forums.irixnet.org/forum-6.html)
+--- Thread: Indy R5K 6.5.22 Install issues (/thread-4406.html)
+- IRIX Network Forums (//forums.irixnet.org)
+-- Forum: SGI/MIPS (//forums.irixnet.org/forum-3.html)
+--- Forum: Beginners' Questions/Tips (//forums.irixnet.org/forum-6.html)
+--- Thread: Indy R5K 6.5.22 Install issues (/thread-4406.html)
RE: Indy R5K 6.5.22 Install issues - Avante3000 - 11-24-2024
One weird thing I ran into was involving memory, my indy has both banks of memory populated. one bank is 32mb and the other is 64mb. when installing 6.5.22 with both banks populated I get the usual "Illegal instruction", with only the 32mb bank I get the same "illegal instruction". But with only the 64mb bank I get "Read TLB Miss". despite that, I ran memtest in the IDE using all the different combinations of memory and all the tests passed
RE: Indy R5K 6.5.22 Install issues - weblacky - 11-24-2024
Is each bank of memory (4 slots) the same exact chip? Can you post the sticker numbers/model for me? I'll check compatibility at least.
I'm going to assume you've read the manual of not only the memory type which has to be non-EDO fast page 72 pin SIMM memory @ 60 or 70 ns WITH PARITY, but that each of the bank of four has to be identically mapped and size chips, preferably the exact duplicate chip per four slots. The bank you start with is closest to the power supply.
Also while the manual doesn't say I know that other SGI's talk about having the largest modules go first. So you might also want to try your larger density modules in bank zero and the lower density ones in bank one.
If you're mixing & matching chips of the same density please provide all information, textually.
RE: Indy R5K 6.5.22 Install issues - Avante3000 - 11-24-2024
each bank of memory has all the same memory module, the 64MB modules in bank 0 and 32mb in bank 1. Bank 0 uses Toshiba THM364020BSG-70, and Bank 1 uses Toshiba THM3620C0ASG-70. It seems like the memory and hard drive was the only thing messed with by whichever previous owner
RE: Indy R5K 6.5.22 Install issues - weblacky - 11-24-2024
(11-24-2024, 05:09 AM)Avante3000 Wrote: each bank of memory has all the same memory module, the 64MB modules in bank 0 and 32mb in bank 1. Bank 0 uses Toshiba THM364020BSG-70, and Bank 1 uses Toshiba THM3620C0ASG-70. It seems like the memory and hard drive was the only thing messed with by whichever previous owner
Basic JEDEC pinout looks fine to me:
https://www.datasheetarchive.com/datasheet/265d000f6cd17fe1?type=O&term=thm3620c
https://www.datasheetarchive.com/datasheet/1f1c000e7071ffe3?type=O&term=THM364020
The only thing that's odd is the actual signal pins aren't in the same order. These modules are labeled as PS/2 type modules but I don't believe they actually are special IBM PS/2 SIMM modules. Because there's since presence detect is in the right place.
RE: Indy R5K 6.5.22 Install issues - Avante3000 - 11-24-2024
I decided to switch to using LOVE for the network install, and it turns out LOVE gives you much more info on what is being transferred. when the install is started, the indy asks for the file "sa" and it begins to transfer and completes the transfer. than it requests unix.IP22. which begins to transfer. But not long after it says "transfer completed prematurely". after that message. the screen on my indy changes to having the IRIX text in the bottom right corner and immediately kernel faults as usual. So it seems like something is causing the transfer of the miniroot to fail, and it tries to run but the data is incomplete
RE: Indy R5K 6.5.22 Install issues - weblacky - 11-24-2024
(11-24-2024, 08:37 PM)Avante3000 Wrote: I decided to switch to using LOVE for the network install, and it turns out LOVE gives you much more info on what is being transferred. when the install is started, the indy asks for the file "sa" and it begins to transfer and completes the transfer. than it requests unix.IP22. which begins to transfer. But not long after it says "transfer completed prematurely". after that message. the screen on my indy changes to having the IRIX text in the bottom right corner and immediately kernel faults as usual. So it seems like something is causing the transfer of the miniroot to fail, and it tries to run but the data is incomplete
This MIGHT be network switch issue! Can you try to make/or get an adapter on Amazon or manually crimp an ethernet cable to create a cross-over cable and directly link both the Indy and and your Windows machine directly. See if the TFTP transfer works then. If need be, manually switch your PC to 10baseT...you may need to try half and instead of full duplex if you still have issues.
Sounds like a network flow control issue.
Just to elaborate more, a lot of recent consumer network switches actually have terrible 10baseT support. Even though they might say it in the front, some of them actually omitted as a way of telling you they don't support at all. I physically seen two switches for home use where 10Mb ethernet didn't actually function correctly. I think this is what's happening with you. You can try an older more basic 10/100 switch but it would probably be easier just to directly cable the two for the purpose of loading the OS.
RE: Indy R5K 6.5.22 Install issues - Avante3000 - 11-27-2024
I did some extra troubleshooting tonight, doing all the recommended network related fixes did not work, though I was able to somehow find compatible memory inside one of my 486 PCs and I tried that out too but same issues. so I would say that network and memory has been ruled out as a issue. but I decided to try serial, a very janky way to connect to serial but it works. everytime I turn on the indy I am greeted with "Data path test failed" and "RTC Path test failed", which I am absolutely clueless about. Though I took the opportunity to do more troubleshooting so I pulled the graphics boards and tried again, same issues. So the graphics boards are also ruled out as an issue
RE: Indy R5K 6.5.22 Install issues - Raion - 11-27-2024
I've mostly stayed out of this thread because I've been really busy but I wanted to comment on a couple things:
1. The system won't boot without graphics.
2. Have you ever replaced the real-time clock? That could be part of your problem (NIC needs to have proper MAC address to boot into miniroot)
3. It sounds to me like a ram issue. The system uses 16 bit SIMMs and they are in banks of four. Do you have to remove an entire bank to test it. What sounds like happening is it's copying the mini root and unable to commit that over to the scuzzy drive. It could also obviously be a drive failure (did you properly partition it first?)
RE: Indy R5K 6.5.22 Install issues - robespierre - 11-27-2024
(11-27-2024, 02:21 PM)Raion Wrote: 1. The system won't boot without graphics.It should.
Quote:2. Have you ever replaced the real-time clock? That could be part of your problem (NIC needs to have proper MAC address to boot into miniroot)Ding. The Indy has no serial ROM and stores its MAC address in the Timekeeper's battery-backed memory.
Quote:3. It sounds to me like a ram issue. The system uses 16 bit SIMMs and they are in banks of four. Do you have to remove an entire bank to test it. What sounds like happening is it's copying the mini root and unable to commit that over to the scuzzy drive. It could also obviously be a drive failure (did you properly partition it first?)The Indy and Indigo2 use standard 72-pin parity FPM DRAMs, which are 36 bits per word. Each bank comprises four matching SIMMs, which must be 70 ns or faster.
A "Data Path error" concerns the memory controller, I think. But the OP said that the hardware tests passed, which is confusing.
RE: Indy R5K 6.5.22 Install issues - Raion - 11-27-2024
Interesting because every one of the systems that I've had never booted without graphics attached, the Challenge S units utilize a separate scsi riser.
I would imagine that the memory is at fault before the controller is. It's possible the hardware test is not checking every bit of the memory and there's only a couple bits of one of the sticks that is at fault but you won't be able to know that until you replace an entire bank