Sys Console can't communicate with HP 9000

[Guest_imported]

I hope that this is not just another-dumb-cable-story, but here is my problem:

When my HP 9000/800 L-3000 server running HP-UX 11 was installed back in September, it did NOT come with a system console. I've been using it via telnet sessions, and holding my breath the couple of times that I have had to re-boot.

The system console finally was ordered and arrived two days ago. It's a C1099A HP terminal, which the documentation touts as being "Hewlett-Packards latest terminal for HP9000 and HP3000 systems. It can be used as the system console...". It's ready-to-go DEFAULTS are to serve as a system console for an HP9000/HP3000. Should be a piece of cake, right?

As it did not come with the DB-9/FEMALE to RS-232/MALE datacomm cable needed, I simply rummaged around and produced the equivalent, which I connected between the HP-9000 and the terminal. The cable coming from the HP9000 is clearly labeled "CONSOLE" and is coming from the correct port that is documented in the "Basic Cable Connections: L-Class Enterprise Server" documentation. The port that I am using from the terminal is the one that is documented as being the default when using as the system console, the EIA port. This is just too easy ... except I get nothing whatsoever on the terminal when I try to communicate with the host.

The only other clue is that the cable is IDEALLY supposed to be a "standard datacomm cable HP p/n 40242G". Goodness knows, I have tried every variation in my cable configuration, introducting null modem connections, etc., with no results.

Can anyone lend some insight?... Thanks in advance...

 

[trunix]

Is there a getty login process running on the console port ?

 

[Guest_imported]

Yep; a "ps -ef | grep getty" yields:

root 1853 1 0 Nov 28 console 0:00 /usr/sbin/getty console console

 

[patel]

Check the communication speed on console. It should be 9600bps

Patel

 

[Guest_imported]

Alas, 9600 baud is indeed one of those ready-to-go defaults on the console. Like I have stated, this is so easy and simple, it just can't not work ... except it doesn't...

 

[trunix]

Do you by any chance have a loopback connector ?
If so plug it in the back of the console and anything you type should be echoed on the screen.
If thats ok, then put the loopback conector on the other end of the cable and try again. If this works, then you know that your vdu and cable are ok.

Ideally you need a data breakout box to see exactly what is happening. This will show if data is being transmitted.

Do you have a comms / network engineer ? Should be able to help you with this.

 

[unixqueen]

Why don't you try killing the getty, it will respawn, it has been running since before you attached the monitor.....

Clare

 

[unixqueen]

Hi

I've just remembered that I've seen this before but it was a rare scenario, the sys admin has gone into GSP with a cntr-b and not come back out with a co to return to console and rebooted remotely. This the console was in gsp mode. The only was to clear was to reset the gsp using the gsp reset button on the core I/O board.
The other thing that sprung to mind was that L class terminals should be in VT100 mode, the instructions of how to put it in are in

http://www.docs.hp.com.

Clare

 

[Guest_imported]

I don't have a loopback connector nor breakout box, but I will try the latest ideas. Thanks, will report back...

 

[Guest_imported]

Here is a big clue that I have discovered: If (via SAM) I attempt to get a list of devices (ioscan), there is a "hang" that continues indefinintely (well, for a couple of days anyway, before I kill -9 the attempted ioscan and SAM process).

I half-way suspect that this entire problem would cure itself if I simply do a shutdown with auto-reboot. Of course, if I am wrong and if there is a problem that prevents a clean boot, then I am really in deep yogurt, since I don't have a working system console.

I guess it all boils down to Clint Eastwood's quotable quote: "Do ya feel lucky? Well, do ya??"

I will probably do a shutdown with auto-reboot over the (slow) holiday period. Will report back on what happens....

Thanks for all the responses to my query. And everyone, have a good holiday.

 

[Guest_imported]

Alas, it turned out to indeed be "just another-dumb-cable-story". The officially correct HP cable (p/n 40242G) had been ordered and came in over the Christmas break. I attached it, and voila -- one working system console.

Thanks for all the good suggestions, I think it's good to go through such an exercise every now and then, will certainly pay off at some point for someone.

Happy New Year to all!