Extraneous/garbage "A" Characters Printing to the Console

[Beth Richardson]

Hi All,

I am having an annoying problem with consoles on two of my systems. When I log on to the MP and go to the console, “A” characters repeatedly print on the display. An “A” seems to be printed to the screen about once every 6 seconds. It is not sent back to the system when I hit a carriage return, but it makes typing in commands painful, especially when I have to backspace, because I can see the “A” on the line, but the system does not recognize that it is there. And, if I leave the console long enough, it just slowly fills up with "A" characters. The problem does not occur in the MP (unless, of course, I go to the console). The problem occurs on the LAN console, the Web console, and when I physically attach a console to the “console” connector on the server.

A few months ago, we received four used systems. The problem is occurring on two of these systems. The other two don’t have this problem, and none of our other systems have this problem. The four "new-to-us" used systems are rp7410s running HP-UX 11.11.

The characters begin to appear as soon as I am transferred from the MP to the console (in other words, after typing “co” at the Main MP menu). They even appear in the login fields before I login:

sys1 [HP Release B.11.11] (see /etc/issue)
Console Login: Abeth
Password: AA

Another example:
sys1> ps -ef A| grep something

And, another:
sys1>AAAAA

Does anyone have any ideas about how to solve this problem?

Thanks in advance,
Beth

[Stephen Keane]

Can you run "stty -a" on one console that is displaying the problem and one that isn't and compare/contrast the results? Also what is running on the console "ps -tconsole" in each case?

[Bill Hassell]

Sounds very much like a rogue process being scheduled with at, inittab or it is running by itself with a sleep 6. Since it is running even before login, the process is writing to /dev/console (which unfortunately any user can do). Since you said the system was used, did you re-install from CDs? If not, you've just inherited all the problems of the previous owner, not something I would ever put into production.

One other possibility: is the console plugged into the console port and not the UPS port? The UPS port may have the UPS daeamon trying to communicate on thart port...or the UPS daemin may have been pointed to the console rather than the UPS port.

[Beth Richardson]

Stephen,

Here is the information you requested (and thanks for the help)... Nothing jumped out at me, but maybe you will see something.

Problem System 1:
sys1>stty -a
speed 9600 baud; line = 0;
rows = 0; columns = 0
min = 4; time = 0;
intr = ^C; quit = ^\; erase = ^H; kill = ^U
eof = ^D; eol = ^@; eol2 = ^@; swtch = ^@
stop = ^S; start = ^Q; susp = ^Z; dsusp
werase ; lnext
-parenb -parodd cs8 -cstopb hupcl cread clocal -loblk -crts
-ignbrk brkint ignpar -parmrk -inpck istrip -inlcr -igncr icrnl -iuclc
ixon ixany ixoff -imaxbel -rtsxoff -ctsxon -ienqak
isig icanon -iexten -xcase echo echoe echok -echonl -noflsh
-echoctl -echoprt -echoke -flusho -pendin
opost -olcuc onlcr -ocrnl -onocr -onlret -ofill -ofdel â tostop

sys1> ps A-tconsoleA
PID TTY TIME COMMAND
1663 console 0:00 ksh
6033 console 0:00 ps

Non-problem System 2:
sys2> stty -a
speed 9600 baud; line = 0;
rows = 0; columns = 0
min = 4; time = 0;
intr = ^C; quit = ^\; erase = ^H; kill = ^U
eof = ^D; eol = ^@; eol2 = ^@; swtch = ^@
stop = ^S; start = ^Q; susp ; dsusp
werase ; lnext
-parenb -parodd cs8 -cstopb hupcl cread clocal -loblk -crts
-ignbrk brkint ignpar -parmrk -inpck istrip -inlcr -igncr icrnl -iuclc
ixon ixany ixoff -imaxbel -rtsxoff -ctsxon -ienqak
isig icanon -iexten -xcase echo echoe echok -echonl -noflsh
-echoctl -echoprt -echoke -flusho -pendin
opost -olcuc onlcr -ocrnl -onocr -onlret -ofill -ofdel â tostop

sys2>ps -tconsole
PID TTY TIME COMMAND
12896 console 0:00 ksh
23551 console 0:00 ps

[Beth Richardson]

Hi Bill,

I had already compared inittabs on the systems due to some other posting I had seen on the forum. The only major difference that I noticed between the good pool and the bad pool was the following:
cim1:3456:respawn:/opt/wbem/sbin/cimserverd ("good" systems have it, "bad" ones don't)

I came to the conclusion that this didn't impact the problem.

When I physically attach a console to the server, I attach it to the "console" attachment on the A6144 connector that I attach to the MP serial port on the server.


The "used" systems replace 4 N4000s that we had. We took make_net_recovery images of the N4000 systems and then dropped these images onto the rp7410s. Thus, I believe that anything we could have "inherited" is now gone.

Also, you made mention of UPS. A coworker set up some kind of UPS monitoring. The bad systems have the A6144 connector attached to the MP serial port on the server. The UPS connection is then attached to the UPS serial port on the UPS. In our configuration, we have sys1 and sys 2 using one UPS, and sys3 and sys4 using another UPS. sys1 and sys3 (both "bad" systems) have the serial connection to the UPS serial port from the A6144 connector on the MP serial port.

Based on your comments, I am starting to suspect the UPS connection and the monitoring. Here is some additional information:
bad-sys1> ps -ef | gArep -i ups
root 9 0 0 Sep 1 ? 0:00 supsched
root 1981 1 0 Sep 1 ? 0:03 /opt/upsmgr/proxy/bin/upsagt
root 1949 1 0 Sep 1 ? 0:01 /opt/upsmgr/client/bin/upsmgrcagt
root 2672 1 0 Sep 1 ? 5:41 /opt/upsmgr/manager/bin/upsmgrmon
root 1982 1981 0 Sep 1 ? 6:55 ptupsd -d/dev/tty0p0 -n0
root 2551 1 0 Sep 1 ? 0:10 /bin/sh /opt/upsmgr/manager/bin/upsmgrstart -b



good-sys2>ps -ef | grep -i ups
root 9 0 0 Sep 1 ? 0:00 supsched
root 2867 1 0 Sep 1 ? 0:03 /opt/upsmgr/client/bin/upsmgrcagt

Thanks,
Beth

[Torsten.]

Hi Beth,

you wrote you cloned the system using a backup of the N4000 and restore it to the rp7410.

This isn't a good idea at all.

Took this from the ignite docs:

...
With very different architecture types, for instance npars capable systems vs. non-npars capable systems, some software may not be configured correctly if the golden images or recovery archives used for cloning were created on non-npars capable systems; the reverse is true also
...

This might be the cause for some problems.

But anway, check if the UPS software is using the correct device files.

[Stephen Keane]

Look at /etc/ups_conf to see which port the UPS daemon is running against.

Should say something like

upstty:/dev/tty1p0 # Port 2 for UPS rs-232

Try writing something to that port

echo "Hello" > /dev/tty1p0

It SHOULDN'T come out on the console. If it does your device file is probably wrong.

[Beth Richardson]

Hi Stephen,

Thanks for the detailed pointer.

sys1> more /etc/ups_conf
shutdown_delay_mins:1
shutdown_timeout_mins:5
upstty:/dev/tty0p1

sys1> echo "arrrrrgggh" > /dev/tty0p1


Seems like this is not the problem. But, I am learning some handy things from you folks...

Regards,
ABeAAAAthAAAAAAAAAAAAAAAA...

[Torsten.]

you wrote your UPS software config some posts above:
...
root 1982 1981 0 Sep 1 ? 6:55 ptupsd -d/dev/tty0p0 -n0
...

do the test again using /dev/tty0p0

[Beth Richardson]

Hi Torsten,

I think you are on the same track as I am. I think that the tty is set in a two different places. The /etc/ups_conf shows /dev/tty0p1. However, a ups-related process shows /dev/tty0p0 (ptupsd -d/dev/tty0p0 -n0). I believe that this is the HP PowerTrust daemon. Using /opt/upsmgr/proxy/bin/setup, I see that UPS configuration is:
UPS-ID: 1, Daemon: ptupsd, Device: /dev/tty0p0, IdentName:

So, I am inclined to believe that this is the problem.

And, per your suggestion (thanks), entering the following on a non-console login:
echo "arrrgggh" > /dev/tty0p0

results in the following on the consoles screen:
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAarrrgggh

At this point, I feel that I need to reset the UPS configuration via the setup program above (or some other way).

I will let you know how it turns out.

Thank you,
Beth