"Kernel stack not valid" during system startup's SYSMAN IO AUTO

[Volker Halle]

Trying again...

Volker.

[Galen Tackett]

Volker,

It looks like you forgot to attach the attachment.

(I do this all the time too.)

Galen

[Volker Halle]

Galen,

I did provide the attachment, but then did a 'preview' and 'edit'. Looks like the attachment got lost by this operation...

Volker.

[Galen Tackett]

It does not look like firmware is the cause of the problem. It crashes with V6.2 firmware just as it does wit V7.2.

I didn't try the crash program yet. Maybe later today. I don't want to interfere with software testing that uses the machine most of the day.

[Galen Tackett]

Volker,

The krnlstknv crash that ensues from running your program does do a restart, then produce a crash dump and a clue file. So we know that mechanism is okay. But for some reason our problem doesn't do a restart. It just does a reboot.

Is there any chance that the problem with resolution not changing is related? (See my original post.)

How early in system startup does the krnlstknv crash handling code get set up? Should it have happened before execution of VMS$DEVICE_STARTUP.COM, or does it happen later?

The only thing I know to try next is to swap the Oxygen VX1 card into another DS10. But that will have to wait until our testing cycle is complete.

[Volker Halle]

Galen,

the console firmware (when it detects an unexpected CPU HALT) will check the HWRPB (Hardware Restart Parameter Block). If it has been clobbered/overwritten, it won't do a RESTART but a BOOT...

Volker.

[Galen Tackett]

Maybe the HWRPB is getting clobbered.

Would there be any point in examining (from console mode) the HWRPB after the crash halt and comparing it to the HWRPB on the live system? If so I can try it, if you can tell me how to find the HWRPB.

[Volker Halle]

Galen,

you can find (and format) the basic HWRPB using

SDA> read sysdef
SDA> form @exe$gpq_hwrpb/type=hwrpb

The total size of the HWRPB and all it's sub-structures is 0x0900 byte - you won't want to dump and compare it all ;-(

Especially look for the HWRPB$IQ_CHKSUM field.

Volker.

[Galen Tackett]

You know the expression, "Here today, gone tomorrow?"

Well this problem now fits that description--though actually I'd have to say, "Here yesterday, gone today."

That's right. The system boots normally now, without me changing a thing.

I have to wonder about the Oxygen card. Working normally, after it initializes during VMS$DEVICE_CONFIG the screen font has become bigger one.

When I was having the krnlstknv, this was not the case. But I wonder if this is cause or effect.

[Galen Tackett]

The problem went away by itself.