Proc: Lost reply across net freeing reply_blk

I’ve got a QNX 4.25 system that is periodically outputting to the
console the following:

Proc: lost reply across net, freeing reply_blk local pid 002E

It looks like the local pid is nameloc.

Any clues what the problem is

Thanks,


Rich Hemmenway
Ortho Clinical Diagnostics: Johnson & Johnson

What I believe is happening is process (pid=002E) is reply blocked
on a process that is not responding. It’s timed out, and the process
is being freed from a reply-blocked state.

If it’s nameloc, it’s probably trying to communicate with a node that
is not responding, and now it’s giving up.

Heather

Rich Hemmenway <rhemmenw@ocdus.jnj.com> wrote:

I’ve got a QNX 4.25 system that is periodically outputting to the
console the following:

Proc: lost reply across net, freeing reply_blk local pid 002E

It looks like the local pid is nameloc.

Any clues what the problem is

Thanks,



Rich Hemmenway
Ortho Clinical Diagnostics: Johnson & Johnson

Previously, Rich Hemmenway wrote in qdn.public.qnx4:

I’ve got a QNX 4.25 system that is periodically outputting to the
console the following:

Proc: lost reply across net, freeing reply_blk local pid 002E

When you Reply(), you don’t block, so there is no network failure
return code for Reply(). However, the reply may not be deliverable.
In which case whos waiting for the error? This usually means you’re
losing packets on your network, or perhaps just disconnected a
machine at the “right” time.

Sam


Sam Roberts (sam@cogent.ca), Cogent Real-Time Systems (www.cogent.ca)

We are going to observe a similiar problem just right now. One of our
computers connected with Ethernet is not reachable normally looking from the
point of our server node 1 (destination node seems to be blocked), but can
be observed fine from another Ethernet Node.
And - fortunatelly? - node 1 is talking about “lost reply across net”. So,
whenever destination node isn’t visible for nameloc or any other task this
message will appear at Proc’s debug console and help you excersising what’s
the matter is.

Regards
M.Koehler

Rich Hemmenway <rhemmenw@ocdus.jnj.com> schrieb in im Newsbeitrag:
39B52B4B.85CF582F@ocdus.jnj.com

I’ve got a QNX 4.25 system that is periodically outputting to the
console the following:

Proc: lost reply across net, freeing reply_blk local pid 002E

It looks like the local pid is nameloc.

Any clues what the problem is

Thanks,


Rich Hemmenway
Ortho Clinical Diagnostics: Johnson & Johnson

We had a similar thing happening to a couple of our systems. We had 3
terminal actually logging into the main server and running an application.
On occasion we would get a session dropped and this message. We got around
it by putting the nodes we were interested in on a private network w/o
TCP/IP on it. This solution isn’t necessarily the best, but it did work for
us.

Matt Blackburn

“Martin Koehler” <software@pcds.de> wrote in message
news:8p8gun$cqs$1@inn.qnx.com

We are going to observe a similiar problem just right now. One of our
computers connected with Ethernet is not reachable normally looking from
the
point of our server node 1 (destination node seems to be blocked), but can
be observed fine from another Ethernet Node.
And - fortunatelly? - node 1 is talking about “lost reply across net”. So,
whenever destination node isn’t visible for nameloc or any other task this
message will appear at Proc’s debug console and help you excersising
what’s
the matter is.

Regards
M.Koehler

Rich Hemmenway <> rhemmenw@ocdus.jnj.com> > schrieb in im Newsbeitrag:
39B52B4B.85CF582F@ocdus.jnj.com> …
I’ve got a QNX 4.25 system that is periodically outputting to the
console the following:

Proc: lost reply across net, freeing reply_blk local pid 002E

It looks like the local pid is nameloc.

Any clues what the problem is

Thanks,


Rich Hemmenway
Ortho Clinical Diagnostics: Johnson & Johnson

“Martin Koehler” <software@pcds.de> writes:

We are going to observe a similiar problem just right now. One of our
computers connected with Ethernet is not reachable normally looking from the
point of our server node 1 (destination node seems to be blocked), but can
be observed fine from another Ethernet Node.
And - fortunatelly? - node 1 is talking about “lost reply across net”. So,
whenever destination node isn’t visible for nameloc or any other task this
message will appear at Proc’s debug console and help you excersising what’s
the matter is.

Whenever I have seen this, it has been an Ethernet hardware failure.
Try changing the Ethernet cards in all of the machines on the network,
one at a time, and see if the problem goes away.

Cheers,
Andrew


Andrew Thomas, President, Cogent Real-Time Systems Inc.
2430 Meadowpine Boulevard, Suite 105, Mississauga, Ontario, Canada L5N 6S2
Email: andrew@cogent.ca WWW: http://www.cogent.ca