Problem with Opa0 on Alpha 1000 4/200

[Guillou_2]

Hi,

I have several Alphaserver 1000 4/200 with OpenVMS 6.2 and we experience sometime problem with the console system Opa0 (vt520).
The device is blocked with a black screen and a blinking cursor in a corner.

To solve the problem we have to reboot the server.

Someone can help me with this problem?

Regards

Steph.

[Volker Halle]

Steph,

does the system otherwise work, i.e. can you login via DECnet/TELNET/LAT ? If so, what is the state of OPA0 (SHOW DEV/FULL OPA0) ?

Was a user logged in on the terminal ? Can you type CTRL/Q ? Does Reset Communication on the VT520 help ?

Do you think it's a problem with the system or just the console port HW/SW ?

Volker.

[Robert_Boyd]

And what if you power cycle the display?

[Guillou_2]

Hi,

Login via decnet, telnet and lat works and the system is ok.

Noone works on this VT and I doesn't think that the display is "frozen" by a ctrl/s.

Power cycle the console doesn't solve the problem.

How can i reset the communication on the vt?

you can find in attachment the result of a show dev/full opa0. The device has a lot of error.

Steph.

[Volker Halle]

Steph,

errors on OPA0: ? Did you check the cable and the connectors ?

Can you write to OPA0: ? Does the text appear on the VT520 ?

$ REPLY/TERM=OPA0: "HELLO"
or
$ OPEN/WRITE x OPA0:
$ WRITE x "HELLO"
$ CLOSE x

To reset communications, you need to enter the setup menue: F3 -> Actions -> Clear Communications

Does the VT520 work normally for a while after you've rebooted the Alpha ? If you login and do a SHO TERM, you are on OPA0:, right ?

If the VT520 (or the console port) seems to 'hang', can you connect another terminal or laptop serial port and get any response from OPA0: ?

Volker.

[Wim Van den Wyngaert]

When logged in on the node, do
$ sh us/fu/int/noclus

If someone is logged in on terminal OPA0: then the console was in use. You can see what program he started with sh proc/con/id=x and stop the process with stop/id=x.

Wim

[faris_3]

Hi,

This type of Opa0: are often due to multiple processes with the SHARE privilege who access the console.

Otherwise you may try to enable error logging on OPA0:
$ set dev /error opa0:

There had been some problems around 2000 with OPA0: hangs in 6.2 but i don't remember if it was fixed by a new image or by installing the V6.1 sys$opdriver.

Anyway have you installed the latest opdr ?

"o Operators at console see timeout errors under heavy usage."

http://ftp.support.compaq.com.au/pub/ecoinfo/ecoinfo/556.htm

[Wim Van den Wyngaert]

Also check if control-p is still reacting.
Once had a machine that was still reacting but didn't show anything, so be carefull. Test after control-p if telnet is still possible to the node.

Wim

[Guillou_2]

Hi thanks all for your help

Nobody is connected to Opa0.

If I try to send a message on the console using "open/write" I get a "device timeout"
and with "reply/term" nothing appears to the screen

Clearing communication with the setup menu of the VT doesn't solve the problem.

After a server reboot, the console worked during few days, I can connect on it, with SHOW TERM I can see that I am on Opa0.

Nothing is logged in errlog when the problem occurs despite enabling error logging .

Patches ALPOPDR04_062 and ALPOPCO01_062 are installed.

Other idea?

Regards

Steph

[Vladimir Fabecic]

Did you upgrade console firmware recently?
Long time ago (1999) I upgraded all customer's alpha servers to firmware 5.1. Just one alpha server (AS 1000) made problems simular to yours.
I downgraded this alpha server to firmware 3.6 and server worked OK. This alpha server is dead now and I don't know if it was the real reason of problem.
This AS1000 worked OK for few years.

On how many AS1000 you have the same problem?
When did it happen first time?

[Guillou_2]

I have two Alpha 1000 with this kind of problem, no firmware upgrade was done recently.Firmware version is V5.4-101 on both.

I can't remember special event that would have triggered this problem.

regards

Steph

[Vladimir Fabecic]

Do you have >>> prompt after pressing HALT button?

[Allan Bowman]

You might want to try running a "keep-alive" DCL script from OPA0 immediately after a reboot. It can just be a simple loop that displays the time once a minute. This way you will be able to tell exactly when it stops working, and possibly make it keep working. See if the behavior is the same on the two consoles with the problem.

If this happens to be a valid workaround, you'll want to make the script a little fancier and shift the output a few characters for each display line so you don't get any screen burn.

Allan in Atlanta

[Volker Halle]

Steph,

another alternative would just achieve the opposite:

Do not issue any IOs to the console port OPA0: by SET TERM/NOBROADCAST/PERM OPA0:

Volker.

[Antoniov.]

Hi Guillou,
when console is unavaiable, do you see noowner after sho term opa0?
I remember, openVMS V6.2 had a problem when some process crashed while was writing on console. Opa0 was locked by noowner until system rebooted.
In my mind you have to disable all messages to console, such as operator.

Antonio
http://it.openvms.org

[Guillou_2]

Thanks all for your help

If I disable broadcasting on Opa0, will I still receive on system console information about startup, shutdown, crash, alarm from audit process, etc?

regards

Steph

[Ian Miller.]

"If I disable broadcasting on Opa0, will I still receive on system console information about startup, shutdown, crash, alarm from audit process, etc?"

No.