[rmpfyf]

So, I've inherited an Octane around ~25 SCSI drives of data that I need to consolidate on elsewhere prior to wiping all drives and finding the green beast a new home. I have fond memories of SGI hardware as an engineering student and an Octane was always a sort of a dream machine.

Managed to tar and ftp the root disk somewhere else, then wiped it, and went through a hell of a time getting fresh IRIX installed but we now have 6.5.22 running.

So the troubles - last night the mouse stopped working, and today on boot I get a post error for the keyboard. All were working fine 24 hours ago. I don't think it's the devices themselves. When the mouse stopped functioning putting it in the keyboard port wouldn't get it going again (I wasn't too concerned as I was telnet'ing into it). Now I can't even get into it.

The machine is older I think - 2x R10k 225MHz, 2x ESI, RAD audio, 256MB RAM, PCI shoehorn with XTALKPCI card installed. There are some manually patched traces on the main board. 

On boot the PCI board doesn't seem to do much before the OS comes up so the PS/2 ports on it are unfortuantely not useful to get this baby beyond POST.

Any help appreciated. Keen to see it come alive again. If there's any way of subverting POST it'd be super ideal.

[Irinikus]

If you can get into the machine via serial console, try entering the command monitor in the prom and typing "resetenv" that might help. Also make sure that the PS/2 plugs are pressed firmly into the sockets, as these machines will automatically go into a non-graphical console mode if they don't detect a keyboard and mouse on startup.

If the "resetenv" command doesn't help, try typing "setenv console g" in the command monitor in the prom to set it to a graphical mode.

[rmpfyf]

If you can get into the machine via serial console, try entering the command monitor in the prom and typing "resetenv" that might help. Also make sure that the PS/2 plugs are pressed firmly into the sockets, as these machines will automatically go into a non-graphical console mode if they don't detect a keyboard and mouse on startup.

If the "resetenv" command doesn't help, try typing "setenv console g" in the command monitor in the prom to set it to a graphical mode.

Hey thanks for responding (you post some very useful vids - thank you)

So to serial in - get a hold of a null cable?

When you suggest a non-graphical console mode - do you mean that it should be visible on my network? The behaviour is odd - it really won't get beyond an error message (which I assume is POST). 

The mouse gets power but doesn't register any movement. Tested on a Windows machine, works OK.

They keyboard might have gone to the Big Peripheral House In The Sky - can't get a numlock light to come on in any OS. Going to try another one.

So just for clarity - if it errors out on finding a keyboard I should be able to serial in, ol-skool 9600 baud on the first serial connector, and try to reset the environment from there. Maybe there's some boot flags to let it proceed headless, even. 

I understood OK?

[Irinikus]

Hey thanks for responding (you post some very useful vids - thank you)

So to serial in - get a hold of a null cable?

So just for clarity - if it errors out on finding a keyboard I should be able to serial in, ol-skool 9600 baud on the first serial connector, and try to reset the environment from there. Maybe there's some boot flags to let it proceed headless, even. 

I understood OK?

Thanks!!!

Correct, you'll need to get a null modem cable and go in via the first serial port.

From there you should be able to see any error messages that come up as it POST's and you should be able to access the prom menu, which will give you access to the command monitor.

[rmpfyf]

Hey thanks for responding (you post some very useful vids - thank you)

So to serial in - get a hold of a null cable?

So just for clarity - if it errors out on finding a keyboard I should be able to serial in, ol-skool 9600 baud on the first serial connector, and try to reset the environment from there. Maybe there's some boot flags to let it proceed headless, even. 

I understood OK?

Thanks!!!

Correct, you'll need to get a null modem cable and go in via the first serial port.

From there you should be able to see any error messages that come up as it POST's and you should be able to access the prom menu, which will give you access to the command monitor.

Alright. I'll fetch a null cable tomorrow, it's one of those things I'd kept for 20 years and then threw out not thinking I'd ever need it again

[weblacky]

While by no means definitive, some thoughts. 

Please don’t mix mouse and keyboard PS/2 - they were designed at different times in IBM PC history, have different protocols, cannot be hot-plugged, and are not interchangeable.  Even on PCs the PS/2 port would be specially marked for allowing both kinds of peripherals, if it did.  All the same, on SGIs especially, things that look like PS/2 aren’t always the same or safe. Please go by the labels/marking near each port.

My initial impression is, you may have a failing power supply or a failing/shorted 5v line.  I only say that because most SGI mainboards seems to run off 3.3v and 12v for 3.5” hdd.  5v was often used just for peripherals and PCI cards (5v-type keyed of course).  PS/2 ports specifically run off of 5v. 

The fact that they worked the day before lends credibility to that idea as the voltage drops from say 4.9v to say maybe 4.5v, the peripherals would likely be under the 5v limit and basically receive no power (insufficient voltage).  There is a max draw limit on PS/2 as well, so current cannot just increase to compensate to any limit.

If you feel brave. Look up the mouse PS/2 pinout and carefully (at your own risk) use a multimeter to check the voltage between the ground& 5v power pins on a PS/2 port. You may find them out of tolerance.  If they are within 5.4v-4.7v, I’d assume they are ok, higher/lower would be bad. 

If out of tolerance that would explain your problem. 

Let us know,

[rmpfyf]

While by no means definitive, some thoughts. 

Please don’t mix mouse and keyboard PS/2 - they were designed at different times in IBM PC history, have different protocols, cannot be hot-plugged, and are not interchangeable.  Even on PCs the PS/2 port would be specially marked for allowing both kinds of peripherals, if it did.  All the same, on SGIs especially, things that look like PS/2 aren’t always the same or safe. Please go by the labels/marking near each port.

My initial impression is, you may have a failing power supply or a failing/shorted 5v line.  I only say that because most SGI mainboards seems to run off 3.3v and 12v for 3.5” hdd.  5v was often used just for peripherals and PCI cards (5v-type keyed of course).  PS/2 ports specifically run off of 5v. 

The fact that they worked the day before lends credibility to that idea as the voltage drops from say 4.9v to say maybe 4.5v, the peripherals would likely be under the 5v limit and basically receive no power (insufficient voltage).  There is a max draw limit on PS/2 as well, so current cannot just increase to compensate to any limit.

If you feel brave. Look up the mouse PS/2 pinout and carefully (at your own risk) use a multimeter to check the voltage between the ground& 5v power pins on a PS/2 port. You may find them out of tolerance.  If they are within 5.4v-4.7v, I’d assume they are ok, higher/lower would be bad. 

If out of tolerance that would explain your problem. 

Let us know,

Thank you for this, it'd make a lot of sense. I had suspected power as the keyboard failed when I booted it with three HDDs (I have 25 or so I need to get data off of).

I pulled out the good multimeter for this - a calibrated Fluke - 5.1VDC on both PS/2's across pins 3/4. Assuming it's not the PSU, then :( 

I've been using relatively cheap-ish mouse/kb for this though. The mouse seems to work on a PC, the keyboard doesn't anymore. I'll find another keyboard and see about a second mouse.

Anything else I should be checking? I could get a scope in a few weeks and check the clock signal.

[weblacky]

Well, that's really odd. I can only find one reference to an Octane Keyboard failure: http://archive.irixnet.org/apocrypha/nek...ist/1.html

If your keyboard no longer works...well then it no longer works. It's worth trying another PS/2 keyboard. However, I'm wondering if there wasn't an overdraw issue? Or perhaps a protection component has prematurely gone (Cap or Diode designed to protect the mainboard from peripherals). I ASSUME the PS/2 ports are controlled by a single IC/circuit. I also assume that if you're keyboard is gone...it may have actually taken out the PS/2 ports in some way. You might want to check those signal pins as you suggested to see what's even coming out of them.

I would go two routes, either do the Null modem (disconnected Mouse/Keyboard) method to work with a terminal in the OS and get the data recovery job done, worry about this later. Or pull the motherboard and multimeter diode check-through the PS/2 Data and clock pins to see if there is a Semiconductor protection diode (or debounce cap) on the other side...or if there is nothing, open short.

The above link "seems" to imply they are pretty resilient and another keyboard may work fine. I'd still try it. I've been using 2003-ish PS/2 MS keyboard and mouse sets on my SGIs, work great.

Looks like your situation has been somewhat documented by others, I'd try simple peripherals. Wired (not USB) Mice and keyboard. Optical mice should be fine (I use them).

Let us know what happens.

[rmpfyf]

Well, that's really odd.  I can only find one reference to an Octane Keyboard failure: http://archive.irixnet.org/apocrypha/nek...ist/1.html

If your keyboard no longer works...well then it no longer works.  It's worth trying another PS/2 keyboard.  However, I'm wondering if there wasn't an overdraw issue?  Or perhaps a protection component has prematurely gone (Cap or Diode designed to protect the mainboard from peripherals).  I ASSUME the PS/2 ports are controlled by a single IC/circuit.  I also assume that if you're keyboard is gone...it may have actually taken out the PS/2 ports in some way.  You might want to check those signal pins as you suggested to see what's even coming out of them.

I would go two routes, either do the Null modem (disconnected Mouse/Keyboard) method to work with a terminal in the OS and get the data recovery job done, worry about this later.  Or pull the motherboard and multimeter diode check-through the PS/2 Data and clock pins to see if there is a Semiconductor protection diode (or debounce cap) on the other side...or if there is nothing, open short.

The above link "seems" to imply they are pretty resilient and another keyboard may work fine.  I'd still try it.  I've been using 2003-ish PS/2 MS keyboard and mouse sets on my SGIs, work great. 

Looks like your situation has been somewhat documented by others, I'd try simple peripherals.  Wired (not USB) Mice and keyboard.  Optical mice should be fine (I use them).

Let us know what happens.

Team I'm feeling a bit stupid. I have a null cable hooked up to my PC, I'm running minicom and I do get text though I'm unable to input anything and the line formatting is terrible. I'm using minicom under Ubuntu. I'm missing something obvious. Help? What's everyone using here?

Using 9600 8n1. I feel I have something wrong in line breaks or similar.

[weblacky]

That should be correct, however I’m one of those people that insists you need to use a real null
Modem cable - all lines correctly hooked up, not just three wires. I’ve had perfect success over the years on SGI terminal connections with two things in mind.

1. Fully pinned out Null modem cable, configured for hardware flow control on the PC terminal.
2. Use a laptop with a Real serial port, unless you know you’re using a FTDI/prolific USB-to-rs323 chipset that definitely uses hardware signaling and doesn’t fake it.

Most USB to serial adapters are pinned out to use hardware flow control incorrectly. I make sure when I find an adapter at a used PC store or something that it check the online GPS community for complaints against the adapter. External GPS receivers are still one of the few devices that often require hardware flow control pins and adapters that cannot do that won’t work.


Otherwise your settings should work: https://wiki.preterhuman.net/Headless