telnet frrezing

[Darryl_15]

We are having a problem with our telnet sessions freezing on our 11.11 64bit server.Once the session freezes it will generally come back after a few minutes but not always. I have checked nettl and lanadmin for any errors and I am getting none. I also have checked the logs on our cisco switch and have found no errors/collisions/dropped packets or anything. All patches are up to date as of Dec 21st but the issue will not go away. Anyone have any ideas?

PPA Number = 1
Description = lan1 HP PCI 1000Base-T Release B.11.11.21
Type (value) = ethernet-csmacd(6)
MTU Size = 1500
Speed = 100000000
Station Address = 0x306ef474a1
Administration Status (value) = up(1)
Operation Status (value) = up(1)
Last Change = 781152
Inbound Octets = 264951920
Inbound Unicast Packets = 1438357
Inbound Non-Unicast Packets = 133502
Inbound Discards = 1
Inbound Errors = 0
Inbound Unknown Protocols = 5514
Outbound Octets = 310188578
Outbound Unicast Packets = 2666058
Outbound Non-Unicast Packets = 3622
Outbound Discards = 0
Outbound Errors = 0
Outbound Queue Length = 0
Specific = 655367
FCS Errors = 0
Single Collision Frames = 0
Multiple Collision Frames = 0
Deferred Transmissions = 0
Late Collisions = 0
Excessive Collisions = 0
Internal MAC Transmit Errors = 0
Carrier Sense Errors = 0
Frames Too Long = 0
Internal MAC Receive Errors = 0

[James R. Ferguson]

Hi:

See if you have PHNE_30695. It's a relatively recent patch that fixes "data flow hangs in kernel telnet..." and occasional high CPU consumption.

Regards!

...JRF...

[Darryl_15]

Yes already have that patch installed. If anything it caused the problem to worsen. I also removed patch PHNE_33313 as per HP recomendation thinking that it might have been a possible issue but again no luck.

[Victor Fridyev]

Hi,

Usually such a problem can be caused by name resolution. Look at your /etc/nsswitch.conf file. May be, there is a type of name resolution (NIS or DNS), which you either don't have on the server or it has problem iself.

HTH

[Bill Hassell]

Is telnet frozen or is the application frozen? That is really the question. Are the freezes always associated with an idle shell or do they only occur with a specific application? If there is nothing unique to the applications (or users, meaning PC type, emulator, network path, etc), you'll probably need Ethereal to trace a session.

[John Jimenez]

I am not the greatest expert, but I was leaning towards a name resolution too. If you are using Fully qualified name try using the IP address and see what happens.

[Darryl_15]

Thanks all but I have already tried the suggestions put forward here. I am at a loss as to why this is going on. If anyone has any more ideas it would be greatly appreciated. As per when it freezes it happens in the application and on the command line there is no difference. It also does not matter what terminal emulation used or telnet client used so it is definately leading me down the lines of an OS problem.

[James R. Ferguson]

Hi (again):

You mentioned that you removed PHNE_33313 per HP. The patch notes for PHNE_33313 note that "If PHNE_31091 and PHNE_33313 are removed, PHNE_33628 must also be removed.". Did you follow that too?

Regards!

...JRF...

[Darryl_15]

Hi James,

Yes that has been removed as well. I did use the cpm_collect.sh utility to check for updates and again no luck all is the way it should be. I am just trying again to go through the patch list to see if there are any old telnet patches I could possibly remove and see how that goes.

[Darryl_15]

Incase anyone is still monitoring this I have resolved the issue. Our progress database is not releasing buffer memory correctly which was causing us to run out of memory on the server for just a few milliseconds which was causing our telnet sessions to freeze. To fix the issue I had reduced the dbc_max_pct kernel parameter to 15% and the problem has been worked around. We are now just waiting on progress to supply us with a patch to fix the memory problems. Thanks for the help everyone.