[vladio]

I sent a Maya scene to render on my Onyx2 and noticed I only had 6 cpu's active, 8 are installed. I went back to the console and it appears I might have some bad memory that's disabling the cpu's. I wasn't able to copy/paste from the console so I typed this out, hopefully I didn't miss something.

Code:

DIAG RESULTS:
/hw/module/1/slot/n1/node/mem: MEMBANK(S) 6 disabled
reason: Bank 6: some DIMMs failed mem test.
/hw/module/1/slot/n2/node/cpu/0: CPU A disabled
Reason: PROM copied to memory (bank 0) is bad.
/hw/module/1/slot/n2/node/cpu/1: CPU B disabled
Reason: PROM copied to memory (bank 0) is bad.
/hw/module/1/slot/n2/node/mem: MEMBANK(S) 1 disabled
Reason: Bank 1: Some DIMMS failed mem test.

   
The system shows 15GB active, It's been a while, if I remember correctly there's 16GB installed. 

Should I pull node 1 and try reseating the memory? Any other suggestions?

When I check the node led's it appears that node 2 is the node that's inop.

[img][/img]

[MrWeedster]

Reseating is always an option

[vladio]

Reseating is always an option

I'm def going to try tomorrow but I'm unsure which node to pull. From the log it says node1 but the led's on the node boards look like node 2 is inop.

I pulled node 2 yesterday and reseated all the memory, I assumed it was the problem child by the led's that are lit.

[jan-jaap]

Reseating is always an option

I'm def going to try tomorrow but I'm unsure which node to pull. From the log it says node1 but the led's on the node boards look like node 2 is inop.

I pulled node 2 yesterday and reseated all the memory, I assumed it was the problem child by the led's that are lit.

You can often revive disabled DIMMs by cleaning the contact edges of the DIMMs with a cotton swab with some alcohol, but you're not going to 'revive' an XIO compression connector by 'reseating' it, unless maybe by tightening the hex screws on a really loose connection. Also, I've never seen the interconnects between the CPUs and nodeboards go bad. I would leave the CPUs well alone, clean the memory (all of it, if you have the time, because this will repeat itself with another bank). You have to manually re-enable the CPUs and memory from the PROM prompt ('enableall' or 'enable all') and reset. With a little luck, the memory and CPUs will stay enabled.

By the time it's all supposed to work again, you can do a run of 'extra heavy' boot time diagnostics to make sure. The amount of diagnostics is selected on a DIP switch bank on the MSC, refer to https://wiki.preterhuman.net/MSC#DIP_Switch_Settings If you go for 'Manufacturing diagnostics' you need to hook up the console to the DB9 near the power breaker on the back, 'Heavy diagnostics' is more or less the same but talks over the regular console port.

[vladio]

You can often revive disabled DIMMs by cleaning the contact edges of the DIMMs with a cotton swab with some alcohol, but you're not going to 'revive' an XIO compression connector by 'reseating' it, unless maybe by tightening the hex screws on a really loose connection. Also, I've never seen the interconnects between the CPUs and nodeboards go bad. I would leave the CPUs well alone, clean the memory (all of it, if you have the time, because this will repeat itself with another bank). You have to manually re-enable the CPUs and memory from the PROM prompt ('enableall' or 'enable all') and reset. With a little luck, the memory and CPUs will stay enabled.

By the time it's all supposed to work again, you can do a run of 'extra heavy' boot time diagnostics to make sure. The amount of diagnostics is selected on a DIP switch bank on the MSC, refer to https://wiki.preterhuman.net/MSC#DIP_Switch_Settings If you go for 'Manufacturing diagnostics' you need to hook up the console to the DB9 near the power breaker on the back, 'Heavy diagnostics' is more or less the same but talks over the regular console port.

Thanks for the suggestion. Are the nodes numbered 0-3 or 1-4? In the OS I've seen them as 0-3 but on the back they're physically labeled 1-4. I guess I'm asking which module to pull... by the led's it's the second from the right but that's labeled node 2. If I pull that node will it boot without it? I was thinking I could pull it, boot and see if I get the same error.

[Irinikus]

I'm sure you can pull the node without error, if you move the fourth node into it's place. (Maybe try swapping the positions of node's 3 and 4 to see if the problem transfers.) If you take a look at an Onyx2 desk side that only has one node, it's simply fitted with a blank in the second CPU node slot.

[indy99]

If the memory is still marked as disabled after you've tried the helpful suggestions mentioned above, you may want to clearing the Power-On Diagnostic logs stored by the PROM.  

Each time your Onyx2 or other SGI quasi big iron of the era is powered up or fully rebooted, by default the PROM runs a Power-On Diagnostic (POD) routine. Hardware that fails the diagnostic is disabled at the PROM level, and remains disabled until repaired/replaced and re-enabled  To complete the repair process the record of the failed hardware may need to be purged from the POD logs.

Enter POD mode from the PROM command line by entering "pod", then:
"go cac"
"clearalllogs"
"initalllogs"
"flush"
"reset" <the system will reset>
When it restarts, go back into the PROM monitor and try "enableall", "update". and "reset" again.

With 16GB of memory you should expect expect the manually invoked POD tests to take some time.   The 'POD' command line isn't exceptionally verbose, so staring at a blank screen and/or blinking cursor while you have a cup of coffee (or two) wouldn't be out of the ordinary.