PHNE_23456

[graham_7]

hi,

I'm working with a deployed system that uses 4 * hp-ux 11 machines running a CORBA application. I read that there are issues with patch PHNE_23456 wrt TCP-IP and bogus data being sent to server. Can anyone tell me if they know how to reproduce this problem on a consistent basis or even have information on the bug synopsis if one exists. So far I have 4 machines...three have this patch and they crash intermittently and the remaining host does not have this patch and has never crashed. Seems too much of a coincidence to me.


anyways, if anyknow know how I can consistently cause the problem to manifest itself i'd be in a position to start testing it.

also, if anyone knows what the recommended patch level needed to replace this, I'd be keen to get my hands on it. The "working" host has just PHNE_21667 installed, I'm thinking of rolling the other machines back to this level if it's safe to do so.

sorry about the lack of detail here but I have no trace info at hand and this has just come to light.


thanks much for all/any help.

regards

GrahamO

[melvyn burnard]

PHNE_23456 does have known issues causing panics. The superseding patches also have known issues, and these will be fixed in the new patch due out early May timeframe, PHNE_26771 is the number I believe.

Until then, it may be better for you to do as you suggest and back out 23456. Be aware that you may need to check on dependencies to back out any that may need doing.

[Clemens van Everdingen]

Hi,

PHNE_21667 is not a patch related to PHNE_23456 !

You should check which s700_800 11.00 cumulative ARPA Transport patch is on your system.

But before you do anything like rolling back I would advise you to use Ignite to baqckup your current system status (VG00).

If you da not have the latest version use this link to get the B.3.6 version of Ignite:

http://www.software.hp.com/products/IUX/

Regards,
C.

P.S. if we know which patch is on the other working systems, we can come up with a solution to roll back.

[Trond Haugen]

PHNE_23456 can exhibit a problem with data loss over TCP/IP connections when the client side of the TCP/IP connection sends a small amount of data and then immediately closes the connection.
The behavior is corrected in PHNE_25423, which was released
01/12/12 BUT that patch has a warning regarding panic.
When this behavior occurs, a Data Page fault panic occurs with the one of the following routines at the top of the stack:

- tcp_wput+0x58
- tcp_rsrv_comm+0x18
- tcp_icmp_error+0x38

So like Malvyn suggests the solution is due in May and you have the option to remove PHNE_23456 while waiting.

Regards,
Tron

[graham_7]

Geez, this forum kicks ass! Thanks much for the replies for far.

The only patches installed on the working host is PHNE_21767 which somebody mentioned is not ARPA related (thanks for that).

The broken host has

PHNE_20436
PHNE_21767
PHNE_22397
PHNE_23456
PHNE_25423

Last night it was restarted with just

PHNE_20436
PHNE_21767
PHNE_22937

installed and the hang occured again (gRRRR). I'm checking whether any of these patches relate to ARPA now and if any of them come with warnings. If anybody has any notions I'd love to hear them.

Thanks much...this forum lark is the best.

GrahamO

PS I did remember to score points BTW :)

[Tom Geudens]

Hi,
Just for the record.
Installing PHNE_23456 is definitely NOT a good idea. In our environment it kicks up hell with Control-M.

Regards,
Tom

[Clemens van Everdingen]

Graham,

I think it's the best idea to rall back all the arpa patches till you are left with PHNE_21767

But PHNE_22937 is a non existing patch, and I think this should be PHNE_22397.

Be carefull rolling back these patches.

Another suggestion:

If you have a software contract with HP, let them do a dump analysis from the crash dumps.
Might point completly in this direction, but just to be sure.

I hate nothing more than a production system that keeps crashing.

Good luck,
C.