AlphaServer 800 OPA0 Doesn't Accept Input

[rbarlow]

I was doing some work on a AlphaServer 800 connected via the OPA0 console port when all of a sudden it wasn't accepting any input. I rebooted to the >>> prompt and could see the init messages appear in my session but it still doesn't accept input.

I've tried reseting my session and swaping the cables. I rebooted it again and let OpenVMS come up and connected via TELNET and executed the following:

$ show dev opa0 /full

Terminal OPA0:, device type unknown, is online, record-oriented device, carriage
control.

Error count 0 Operations completed 98
Owner process "" Owner UIC [SYSTEM]
Owner process ID 00000000 Dev Prot S:RWPL,O:RWPL,G,W
Reference count 0 Default buffer size 80

Does anybody have any thoughts of what to try?

[Steven Schweda]

> [...] connected via the OPA0 console port
> [...]

_What_ is connected to the OPA0 console port?
Which port is that? (How many does it have?)

> [...] I rebooted to the >>> prompt [...]

_Shut_down_ to the ">>>" prompt, or rebooted?

> [...] it still doesn't accept input.

If you shut down, so that you actually get a
">>>" prompt, does it work?

What, exactly, does "doesn't accept input"
mean? Characters put in don't echo back?
Commands don't work? ???

[rbarlow]

PC running a serial terminal emulator connected to the OPA0 console port. It receives output messages to the screen but does not accept keyboard input (no echo, no commands).

[Hoff]

Connect the console serial line to the other COM port on the AlphaServer 800 series box and try your tests again, and call us back.

The console connection via COM2 does get a little weird, and switching and remaining on COM1 works rather better here. Here's a related discussion, and with some terminal settings and such:

http://labs.hoffmanlabs.com/node/995

If you haven't been swapping ports around on the box, then there may be a lower-level problem with the port or the console or such. Try power-cycling the box, but it wouldn't be a stretch to have some sort of a hardware problem on a box this old. Also look at reloading the SRM firmware, too.

And this also might not be the first time that a (I presume) Microsoft Windows box or a Windows terminal emulator has lost its place when performing serial I/O, either. Reboot the client.

[marsh_1]

..console set to graphics ?

fwiw

[rbarlow]

The console is set to serial.

However, it doesn't matter because even when OpenVMS is booted, it doesn't accept keyboard input either.

[Steven Schweda]

> PC running a serial terminal emulator [...]

And you've tested this stuff? (Connect pins
2 and 3 at the far end of the cable?)

> However, it doesn't matter [...]

If you knew what mattered, then you probably
wouldn't be here.

Trying to decide between a hardware problem
and a software problem seems to me to be a
reasonable course. But if you don't care,
...

[rbarlow]

What I meant is that I didn't think that was relavent because I still receive messages on the screen at both the >>> and OS levels, but then again I could always be mistaken :-)

I found another connector and connected via the COM2 port and everything worked fine.

At this point I'm thinking it's a hardware issue with that COM1 port. Thanks for all the quick replies and suggestions!