Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations strongm on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

TTYHOG OVER-RUN in error log 2

Status
Not open for further replies.

mkharris

Technical User
Nov 20, 2000
104
GB
I have client sessions using telnet, which are now aborting,and which produce TTYHOG OVER-RUN in the error log. This has started happening after a move from an SP Silver thin node to an M80, which also meant upgrading my 4.3.3 maintenance level from 04 to 06.

My question is, whether anyone else has had a similar problem, and how they resolved it. I am also trying to get a solution through IBM, but this has involved several days of trying different 'no' permutations, and we don't seem to be getting anywhere... |-I

Thanks in advance
Mark
 
These are usually caused by noise on the line, or incorrect config of devices. Check config of devices u are using telnet sessions.
 
I have since discovered that this problem only happens through telnet. On the IBM website, there is an APAR - IY14872 - that suggests this is related to the -a flag for telnetd, specified in /etc/inetd.conf. They suggest removing the flag and refreshing inetd. ( The man page for telnetd has no mention of this flag, but apparently it is for efficient streaming by use of kernel buffers. ) I don't know if there is a performance hit with this, as I haven't attempted a removal - our live users have become a bit irritated by the inconvenience of the 'fixes' we have attempted so far :-( . I'll post an update once I've sorted it out.
 
mkharris,

Check out APAR IY87978 - this is in relation to AIX 4.3.2 and system hangs. I have removed the "-a" flag from all systems.

Now a bit about tty hogs:

In AIX data coming into a serial port is taken by the device
driver and stored into a buffer in the kernel (called the ihog)
which by default is 512 bytes in size. The data is stored in this
buffer until a user process comes along and reads the data. However,
if data (noise, actual data, etc.) comes into the serial port but
no user process comes along to read it and data continues to come in,
then the buffer fills and is flushed and the error you are seeing is
logged.

1) If there is a process reading the data, then it is generally a flow
control problem - the data is coming in but filling the buffer
faster than the process can come along and read it.

2) If there is no process running, then either whatever is attached to
the serial port is sending data that nothing tries to read or there is
line noise.

You can reduce the number of occurrences of the error by increasing
the size of the ihog buffer from 512 bytes to a larger size:

stty ihog 2048 \< /dev/tty\#\#

If your situation is 1) then this may resolve the problem. If the
situation is 2) then this will only decrease the frequency at which
the error occurs since more &quot;noise&quot; can come in on the port before
the buffer has to be flushed and the error logged.
Verify that you are running the latest maintenance level, specially
bos.rte.tty and devices.tty.rte. Also verify flow control settings.

Good luck

PSD
HAMCP Specialist
 
Useful advice - thank you. I'll have a look at that APAR, and the next thing to try ( today ), will be removing the &quot;-a&quot; flag.
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top