No keyboard response after boot

[Fred Cray]

I am not a VMS administrator so...
This is a system that is maintained by Siemens in our environment.
We have clustered ES45's with VMS V7.3-2 and firmware V6.5. One of the systems after booting does not allow keyboard input. I know the keyboard is working because I typed B to boot the thing. Siemens does not know what the problem is, any ideas?

[Steven Schweda]

> [...] does not allow keyboard input. [...]

What does this mean? What do you see? (And
on what do you see it?)

> [...] the keyboard [...]

This is a workstation-like keyboard (with a
graphics display)? Or is it a serial
terminal? Where is it connected?

[EdgarZamora]

It probably did not finish booting and is hung somewhere in SYSTARTUP.

[Fred Cray]

This is a console keyboard using the PS2 port on the server. The system boots fine without error and gets to the point where you would normally just press enter to get a logon prompt.

[Steven Schweda]

It's like pulling teeth.

> [...] What do you see? (And
> on what do you see it?)

My psychic powers are, sadly, quite weak.
Are you looking at a DECwindows CDE-like New
Desktop login window, or a flashing cursor
after some text, or what?

> [...] gets to the point where you would
> normally just press enter to get a logon
> prompt.

And what was the last thing it said?

> [...] after booting [...]

So it does come up and join the cluster, and
is accessible from the network, with only the
console keyboard+display not working?

[Fred Cray]

Just what I said. This system is not using DECWindows. It is for a Siemens Pharmacy system, text only messages during boot, messages of processes starting successfully. The console is configure for text terminal access. Can't get to the prompt that usuallaly looks like this:
Username:

Cursor is just flashing. It is as if the OS is not recognizing the keyboard but I know the hardware is because I used it at the P00>> prompt.

[Hoff · Accepted solution]

My first guess would be that something here is hanging onto the OPA0: console port.

With the terminal device allocated, the login processing won't start. LOGINOUT is activated in response to input on an unallocated device, after all.

There have been various applications which have left the console allocated. OPA0: could trigger this, and there's a sequence involving SHARE privilege that can lead to some pain. Older and un-ECO'd OPCOM has been known to trigger this on various OpenVMS releases; to leave a dangling console allocation.

Access the system via network or via a serial console -- and you should switch to and should be using a serial console if you're not using DECwindows on the graphics console -- and see if any processes have OPA0: allocated.

And y'all might want to get some help in to look at this (either with or around the Siemens folks), as debugging these cases remotely and sans any access isn't easy. And get the console port moved over to the serial port, and get the RMC online, and connect up a DECserver or terminal emulator or such. (The Glass TTY is a tedious interface to use, at best, and even if you remember to have it set to use VT52 emulation.)

Stephen Hoffman
HoffmanLabs LLC

[Fred Cray]

Thank you Stephen. I will run this by Siemens.

Fred

[DECxchange]

Hello,
I guess I'll answer your question with a thousand questions ;).

Is the system booted up now? When that system booted, did you get the accounting info at the end and did it say "login interactive limit ..."? Can you login to that system from another terminal? Not the cluster, but that particular system. If you do a show cluster command from another terminal at the VMS prompt, does it list that cmoputer as part of the cluster?

Before it booted, when you typed b for boot, did it echo the b to its monitor? Were you able to type console commands at that console? Before you booted it, did you check to see whether the console was graphics or serial by typing show console at the >>> prompt?

Why did you have to boot that system? Was it down for a hardware problem or a software upgrade? Anyway, maybe you don't want to answer the last three questions for business reasons.

Let's go from there. It's hard to answer a hardware question like this without either standing there or having somebody standing there and trying different things.

[Steven Schweda]

> I guess I'll answer your question with a
> thousand questions ;).

I wish you luck. It took me three messages
just to get "not using DECWindows".

> It's hard to answer a hardware question
> like this [...]

It can be. Some people make it easier than
others.

[Troodon]

I've had this problem on many systems.

In my experience, hitting the "halt" button, then continuing will either free up the console, or cause an immediate crash after the "continue" is typed with an "SMP"-type crash.

There does seem to be a wedge of some of the time when DecWindows does not start. This is why I recommend installing DecWindows when you have keyboard and mouse attached, even if you don't use them.

[Fred Cray]

Working with Siemens, we took into consideration most of the information in these threads and ruled out most of them.
We did determine that the problem is something in the startup but not sure what. The work around is booting just the OS then manually starting the logical systems.
Thanks for the input.

[Fred Cray]

-