Bugcheck code = 0000036C: PROCGONE, Process not in system

[FernandoML]

Hi all,
I reboot both nodes of a cluster just to verify they worked fine before moving to a new Data Center.
After booting from SAN I get on both nodes the same error:

**** OpenVMS Alpha Operating System V7.1 - BUGCHECK ****
** Bugcheck code = 0000036C: PROCGONE, Process not in system
** Crash CPU: 01 Primary CPU: 00 Active CPUs: 00000003
**** Starting compressed selective memory dump ........ COMPLETE
SYSTEM SHUTDOWN COMPLETE

Halted CPU 0

Halt code = 5
P00>>>

Can anyone help how to troubleshoot this problem? No hardware errors on disks, just on tapes since months.

Thanks in advanced,
Fernando.

[Hoff · Accepted solution]

PROCGONE covers a gazillion different cases of failures early in the bootstrap. Load the ECO kits up to current, seriously consider an upgrade to the current release, then ring up HP. There's often a code left in register R0 that can sometimes help identify the trigger, and HP will have a list of the various R0 codes that can be seen on OpenVMS Alpha V7.1. There are a variety of FC patches for known FC SAN bugs; these bugs have cropped up at seemingly random times.

As much for grins as anything else, I'd try the same sequence with OpenVMS Alpha V8.3, too.

[FernandoML]

Hoff,
Thank you for your quick response.
We are thinking of reinstalling/upgrading from original CD. Maybe this could repair any corrupt file concerning licensing that makes impossible to boot from disks.

This system is new for us as part of a recent support contract that involves many other intel systems and we know it has never been updated. I'm afraid no HP support is "alive" but I will tray to ring them.

This is an AlphaServer 800, How can we get the code left in register R0?

Thanks again.

[Hoff]

[[[We are thinking of reinstalling/upgrading from original CD. Maybe this could repair any corrupt file concerning licensing that makes impossible to boot from disks.]]]

Ah; OK. I'd (incorrectly) inferred this was an existing and known system that had started tipping over, and not a new-to-you system.

As for the corrupt file, that's not the approach I'd look for first. PROCGONE can be all over the map; fragmentation, problems accessing disks, volume label collisions in a cluster, all sorts of stuff.

And licensing failures don't typically overlap with PROCGONE; I've never seen that combination.

Do look at the configuration for the FC SAN here first, and most definitely do not use whatever random bits were found on the box if this is a new-to-you and fresh box. Load it fresh. With existing bits found on a system disk, who knows what might happen.

If it's an existing box that was managed and run for a specific task and you're now adopting support for the box, then re-installation probably isn't appropriate as a first step. Start with the FC SAN configuration and diagnosing the R0 and mayhap an AUTOGEN pass and do load the current ECO kits and work from there.

[[[This is an AlphaServer 800, How can we get the code left in register R0?]]]

Old gear. Ok.

The value in register R0 usually displayed as part of the spewed mass of characters displayed during the crash. It may well be stored in the crashdump, too; I've not confirmed the PROCGONE code ends up written there, as the displayed value during the crash is much more directly visible.

[Duncan Morris]

Fernando,

Welcome to the itrc OpenVMS forum!

Are you sure that this really is an AlphaServer 800?

Your crash report show that there are 2 CPUs on this system - but the AS800 is a single processor system!!!

"Crash CPU: 01 Primary CPU: 00 Active CPUs: 00000003"

You might try booting

>>> boot -flags 0,30000

and post the results in an attachment.
There may be a clue in the output.


Has this system ever been booted from a SAN disk before? I seem to recall that fibre channel support only came in with VMS V7.2, so I am surprised to see you saying that you are booting from a SAN.

Duncan

[FernandoML]

Yes, you noted already it's new for me. ;-(

I know MA8000 SAN systems this is an older one but serial console management is very similar. When showing disks, units and connections everything seems to be ok.

Controllers are HSZ50 model.

This system has always booted from shared storage (Storageworks for both nodes with scsi connections) so It is a DAS not a SAN (Sorry!)

Look at the attached phone pic. There is a code at the end of the crash, after "halt code = 5" as follows:
PC = ffffffff80083ee0

We tried to boot -fl 0,1 but with same results.

Now I cannot post the results cause I have no direct access to console right now (23:00 PM) here in Spain. Tomorrow I will follow your guidelines.

Fernando.

[Hoff]

Ok; the JPG image shows the PROCGONE is occurring just after the second processor is launched, and shows two processors in the configuration.

That's already very odd, as the AlphaServer 800 that was mentioned earlier is a uniprocessor.

You're going to want to specifically identify the processor here, and more of the configuration involved here. (One cause of PROCGONE is an attempt to boot a processor on a release that lacks support for same, for instance.)

There are AlphaServer 8200 and AlphaServer 8400 class boxes; there are unfortunately a gazillion similar-named systems around.

With the Alpha SRM console, some combination of SHOW CONFIG and SHOW DEVICE or such (at the >>> prompt) usually elucidates sufficient identifying information.

[FernandoML]

Ok. I dont remember output of show config or show device but I will bring it here tomorrow.

Thanks again.

[Jur van der Burg]

You can get full console output (including R0) by setting bit 1 in the parameter DUMPSTYLE. So you can do a conversational boot (boot -flags 0,1) en set DUMPSTYLE to 11 (9 is the default). This will show you the contents of R0 after the crash.

Jur.

[Willem Grooters]

Just for clearification:

What would happen if a uni-processor system (AS800) would boot from a system disk of a multi-CPU-system (AS8x00)?

For if multiple processors are expected according the system parameter file(s), it's obvious something may go wrong if that processor does not exist.

If that is true: are you booting from the right disk or system root?