Ultra 60 OBP

Paul,

This could be anything across the full spectrum

of a minor frustration through to a potentially expensive repair.

Is this a workstation that's been recently functional?

Or is this a box that you're just touching for the first time?

Begin with the following:

At the OK prompt do ...

OK setenv auto-boot? false <enter>

OK reset-all <enter>

The system will reboot and automatically stop at OBP for you.

You can then try your probe of the SCSI bus without any 'garbage' bootup data in the way.

That would be the minor frustrating oversight I mentioned above.

If it continues to hang, then you may just have a failed drive.

Shut down and disconnect the optical drive and all hard disks.

Power it up and try the probe once again.

If that finally works, and cleanly shows only the integrated controller(s),

then the issue is that one of the drives is locking up the bus.

Re-install them one at a time to figure out which drive is the culprit.

If the system still hangs while the drives are absent,

then it's likely you have an issue with the systemboard.

That would be the other end of possibilities -- the expensive one.

My vote is that you just have a dead drive.

--

When you've completed your triage, you can set the auto-boot variable back to true.

rukbata at 2007-7-12 2:29:30 >

Perhaps it is time to push the workstation through a DIAG POST.

You will need to be connected to it on TTYa, from another system,

as all information will go out that console connection and not out through any graphics card.

The keyboard is likely disabled during the procedure, at least until it completes POST and enters OBP.

If you need it, the OBP 3.x Command Reference Manual is available at:

http://docs.sun.com/app/docs/doc/806-1377-10?q=openboot+command+reference

Re-install everything back into the chassis,and then ...

You would leave auto-boot? at `false`,

you change the diag-device variable to `disk`,

you change the diag-level variable to `max`,

and you change the diag-switch? variable to `true`.

When you next power it on, the system will be pushed through an extensive POST.

Low level components will be examined very closely.

That includes cpu(s), DIMMs, controller chipsets, data busses, and more.

Again, all the results will stream out the TTYa console.

Capture it as a text file to the system you've connected to that port,

and you may find the culprit.

rukbata at 2007-7-12 2:29:30 >