Socklet dies

on node1 in our qnx4 network Socket dies about once a week. I have dump files of Socket and named with the same timestamp. There seems to be no related traceentry on that time. sin ver shows Socket 4.25H Jul 30 1999. Anyone wants to look at the dump files? What more info should i collect?

Previously, Horst Hannappel wrote in qdn.public.qnx4:

on node1 in our qnx4 network Socket dies about once a week. I have dump files of Socket and named with the same timestamp. There seems to be no related traceentry on that time. sin ver shows Socket 4.25H Jul 30 1999. Anyone wants to look at the dump files? What more info should i collect?

is anyone able to help?

Do you have a quics account?? If you do, can you upload them there and let
me know when you’ve done so. If not, how large are they?

Heather


Horst Hannappel <Horst.Hannappel@mbs-software.de> wrote:

Previously, Horst Hannappel wrote in qdn.public.qnx4:
on node1 in our qnx4 network Socket dies about once a week. I have dump files of Socket and named with the same timestamp. There seems to be no related traceentry on that time. sin ver shows Socket 4.25H Jul 30 1999. Anyone wants to look at the dump files? What more info should i collect?


is anyone able to help?

Previously, Heather Kilgour wrote in qdn.public.qnx4:

Do you have a quics account?? If you do, can you upload them there and let

uploaded to ~hhannappel.

me know when you’ve done so. If not, how large are they?

Heather


Horst Hannappel <> Horst.Hannappel@mbs-software.de> > wrote:
Previously, Horst Hannappel wrote in qdn.public.qnx4:
on node1 in our qnx4 network Socket dies about once a week. I have dump files of Socket and named with the same timestamp. There seems to be no related traceentry on that time. sin ver shows Socket 4.25H Jul 30 1999. Anyone wants to look at the dump files? What more info should i collect?


is anyone able to help?
\

Hello,

The dmp file did not provide enough detail… I have placed a debug
Socket.g in your quics account. Please download this and follow these
steps:

  1. run it as 'Socket.g -dnosegv … ’
  2. change your trace severity to 7 ‘tracectrl -s7’
  3. hit Socket with a SIGUSR1 - ‘slay Socket.g’ – this will cause the driver
    to log more detail to the trace buffer.

When it dies, please upload your dmp file, output from your trace file and
a ‘sin ver’.

As well, is this problem something that can be duplicated easily??

Thanks,
Heather


Horst Hannappel <Horst.Hannappel@mbs-software.de> wrote:

Previously, Heather Kilgour wrote in qdn.public.qnx4:
Do you have a quics account?? If you do, can you upload them there and let

uploaded to ~hhannappel.

me know when you’ve done so. If not, how large are they?

Heather


Horst Hannappel <> Horst.Hannappel@mbs-software.de> > wrote:
Previously, Horst Hannappel wrote in qdn.public.qnx4:
on node1 in our qnx4 network Socket dies about once a week. I have dump files of Socket and named with the same timestamp. There seems to be no related traceentry on that time. sin ver shows Socket 4.25H Jul 30 1999. Anyone wants to look at the dump files? What more info should i collect?


is anyone able to help?
\

Previously, Heather Kilgour wrote in qdn.public.qnx4:

Hello,

The dmp file did not provide enough detail… I have placed a debug
Socket.g in your quics account. Please download this and follow these
steps:

  1. run it as 'Socket.g -dnosegv … ’
  2. change your trace severity to 7 ‘tracectrl -s7’
  3. hit Socket with a SIGUSR1 - ‘slay Socket.g’ – this will cause the driver
    to log more detail to the trace buffer.

When it dies, please upload your dmp file, output from your trace file and
a ‘sin ver’.

i will do that.

As well, is this problem something that can be duplicated easily??

it only happens on our node 1 which is our central server in our qnx network. It is the one that shold run all the time and the problem only occurs once a week. It might happen on other nodes and go unnoticed.

Thanks,
Heather


Horst Hannappel <> Horst.Hannappel@mbs-software.de> > wrote:
Previously, Heather Kilgour wrote in qdn.public.qnx4:
Do you have a quics account?? If you do, can you upload them there and let

uploaded to ~hhannappel.

me know when you’ve done so. If not, how large are they?

Heather


Horst Hannappel <> Horst.Hannappel@mbs-software.de> > wrote:
Previously, Horst Hannappel wrote in qdn.public.qnx4:
on node1 in our qnx4 network Socket dies about once a week. I have dump files of Socket and named with the same timestamp. There seems to be no related traceentry on that time. sin ver shows Socket 4.25H Jul 30 1999. Anyone wants to look at the dump files? What more info should i collect?


is anyone able to help?


\

Previously, Horst Hannappel wrote in qdn.public.qnx4:

Previously, Heather Kilgour wrote in qdn.public.qnx4:

Hello,

The dmp file did not provide enough detail… I have placed a debug
Socket.g in your quics account. Please download this and follow these
steps:

  1. run it as 'Socket.g -dnosegv … ’
  2. change your trace severity to 7 ‘tracectrl -s7’
  3. hit Socket with a SIGUSR1 - ‘slay Socket.g’ – this will cause the driver
    to log more detail to the trace buffer.

When it dies, please upload your dmp file, output from your trace file and
a ‘sin ver’.


i will do that.

dump and “sin ver” are there, trace will follow soon.

As well, is this problem something that can be duplicated easily??


it only happens on our node 1 which is our central server in our qnx network. It is the one that shold run all the time and the problem only occurs once a week. It might happen on other nodes and go unnoticed.

Thanks,
Heather


Horst Hannappel <> Horst.Hannappel@mbs-software.de> > wrote:
Previously, Heather Kilgour wrote in qdn.public.qnx4:
Do you have a quics account?? If you do, can you upload them there and let

uploaded to ~hhannappel.

me know when you’ve done so. If not, how large are they?

Heather


Horst Hannappel <> Horst.Hannappel@mbs-software.de> > wrote:
Previously, Horst Hannappel wrote in qdn.public.qnx4:
on node1 in our qnx4 network Socket dies about once a week. I have dump files of Socket and named with the same timestamp. There seems to be no related traceentry on that time. sin ver shows Socket 4.25H Jul 30 1999. Anyone wants to look at the dump files? What more info should i collect?


is anyone able to help?




\

Previously, Horst Hannappel wrote in qdn.public.qnx4:

Previously, Horst Hannappel wrote in qdn.public.qnx4:
Previously, Heather Kilgour wrote in qdn.public.qnx4:

Hello,

The dmp file did not provide enough detail… I have placed a debug
Socket.g in your quics account. Please download this and follow these
steps:

  1. run it as 'Socket.g -dnosegv … ’
  2. change your trace severity to 7 ‘tracectrl -s7’
  3. hit Socket with a SIGUSR1 - ‘slay Socket.g’ – this will cause the driver
    to log more detail to the trace buffer.

When it dies, please upload your dmp file, output from your trace file and
a ‘sin ver’.


i will do that.



dump and “sin ver” are there, trace will follow soon.

trace_29 is there.

i took an snapshot of the console where Socket was startet. It’s called ditto1. There are
messages related to nfs that might be the reason for our problem.

As well, is this problem something that can be duplicated easily??


it only happens on our node 1 which is our central server in our qnx network. It is the one that shold run all the time and the problem only occurs once a week. It might happen on other nodes and go unnoticed.

Thanks,
Heather


Horst Hannappel <> Horst.Hannappel@mbs-software.de> > wrote:
Previously, Heather Kilgour wrote in qdn.public.qnx4:
Do you have a quics account?? If you do, can you upload them there and let

uploaded to ~hhannappel.

me know when you’ve done so. If not, how large are they?

Heather


Horst Hannappel <> Horst.Hannappel@mbs-software.de> > wrote:
Previously, Horst Hannappel wrote in qdn.public.qnx4:
on node1 in our qnx4 network Socket dies about once a week. I have dump files of Socket and named with the same timestamp. There seems to be no related traceentry on that time. sin ver shows Socket 4.25H Jul 30 1999. Anyone wants to look at the dump files? What more info should i collect?


is anyone able to help?






\

Previously, Horst Hannappel wrote in qdn.public.qnx4:

Previously, Horst Hannappel wrote in qdn.public.qnx4:
Previously, Horst Hannappel wrote in qdn.public.qnx4:
Previously, Heather Kilgour wrote in qdn.public.qnx4:

Hello,

The dmp file did not provide enough detail… I have placed a debug
Socket.g in your quics account. Please download this and follow these
steps:

  1. run it as 'Socket.g -dnosegv … ’
  2. change your trace severity to 7 ‘tracectrl -s7’
  3. hit Socket with a SIGUSR1 - ‘slay Socket.g’ – this will cause the driver
    to log more detail to the trace buffer.

When it dies, please upload your dmp file, output from your trace file and
a ‘sin ver’.


i will do that.



dump and “sin ver” are there, trace will follow soon.

trace_29 is there.

i took an snapshot of the console where Socket was startet. It’s called ditto1. There are
messages related to nfs that might be the reason for our problem.

any news on this? It died again this weekend.

As well, is this problem something that can be duplicated easily??


it only happens on our node 1 which is our central server in our qnx network. It is the one that shold run all the time and the problem only occurs once a week. It might happen on other nodes and go unnoticed.

Thanks,
Heather


Horst Hannappel <> Horst.Hannappel@mbs-software.de> > wrote:
Previously, Heather Kilgour wrote in qdn.public.qnx4:
Do you have a quics account?? If you do, can you upload them there and let

uploaded to ~hhannappel.

me know when you’ve done so. If not, how large are they?

Heather


Horst Hannappel <> Horst.Hannappel@mbs-software.de> > wrote:
Previously, Horst Hannappel wrote in qdn.public.qnx4:
on node1 in our qnx4 network Socket dies about once a week. I have dump files of Socket and named with the same timestamp. There seems to be no related traceentry on that time. sin ver shows Socket 4.25H Jul 30 1999. Anyone wants to look at the dump files? What more info should i collect?


is anyone able to help?








\

any news?

Previously, Horst Hannappel wrote in qdn.public.qnx4:

Previously, Horst Hannappel wrote in qdn.public.qnx4:
Previously, Horst Hannappel wrote in qdn.public.qnx4:
Previously, Horst Hannappel wrote in qdn.public.qnx4:
Previously, Heather Kilgour wrote in qdn.public.qnx4:

Hello,

The dmp file did not provide enough detail… I have placed a debug
Socket.g in your quics account. Please download this and follow these
steps:

  1. run it as 'Socket.g -dnosegv … ’
  2. change your trace severity to 7 ‘tracectrl -s7’
  3. hit Socket with a SIGUSR1 - ‘slay Socket.g’ – this will cause the driver
    to log more detail to the trace buffer.

When it dies, please upload your dmp file, output from your trace file and
a ‘sin ver’.


i will do that.



dump and “sin ver” are there, trace will follow soon.

trace_29 is there.

i took an snapshot of the console where Socket was startet. It’s called ditto1. There are
messages related to nfs that might be the reason for our problem.

any news on this? It died again this weekend.



As well, is this problem something that can be duplicated easily??


it only happens on our node 1 which is our central server in our qnx network. It is the one that shold run all the time and the problem only occurs once a week. It might happen on other nodes and go unnoticed.

Thanks,
Heather


Horst Hannappel <> Horst.Hannappel@mbs-software.de> > wrote:
Previously, Heather Kilgour wrote in qdn.public.qnx4:
Do you have a quics account?? If you do, can you upload them there and let

uploaded to ~hhannappel.

me know when you’ve done so. If not, how large are they?

Heather


Horst Hannappel <> Horst.Hannappel@mbs-software.de> > wrote:
Previously, Horst Hannappel wrote in qdn.public.qnx4:
on node1 in our qnx4 network Socket dies about once a week. I have dump files of Socket and named with the same timestamp. There seems to be no related traceentry on that time. sin ver shows Socket 4.25H Jul 30 1999. Anyone wants to look at the dump files? What more info should i collect?


is anyone able to help?










\

Sorry, we are still looking into this…




any news?

Previously, Horst Hannappel wrote in qdn.public.qnx4:
Previously, Horst Hannappel wrote in qdn.public.qnx4:
Previously, Horst Hannappel wrote in qdn.public.qnx4:
Previously, Horst Hannappel wrote in qdn.public.qnx4:
Previously, Heather Kilgour wrote in qdn.public.qnx4:

Hello,

The dmp file did not provide enough detail… I have placed a debug
Socket.g in your quics account. Please download this and follow these
steps:

  1. run it as 'Socket.g -dnosegv … ’
  2. change your trace severity to 7 ‘tracectrl -s7’
  3. hit Socket with a SIGUSR1 - ‘slay Socket.g’ – this will cause the driver
    to log more detail to the trace buffer.

When it dies, please upload your dmp file, output from your trace file and
a ‘sin ver’.


i will do that.



dump and “sin ver” are there, trace will follow soon.

trace_29 is there.

i took an snapshot of the console where Socket was startet. It’s called ditto1. There are
messages related to nfs that might be the reason for our problem.

any news on this? It died again this weekend.



As well, is this problem something that can be duplicated easily??


it only happens on our node 1 which is our central server in our qnx network. It is the one that shold run all the time and the problem only occurs once a week. It might happen on other nodes and go unnoticed.

Thanks,
Heather


Horst Hannappel <> Horst.Hannappel@mbs-software.de> > wrote:
Previously, Heather Kilgour wrote in qdn.public.qnx4:
Do you have a quics account?? If you do, can you upload them there and let

uploaded to ~hhannappel.

me know when you’ve done so. If not, how large are they?

Heather


Horst Hannappel <> Horst.Hannappel@mbs-software.de> > wrote:
Previously, Horst Hannappel wrote in qdn.public.qnx4:
on node1 in our qnx4 network Socket dies about once a week. I have dump files of Socket and named with the same timestamp. There seems to be no related traceentry on that time. sin ver shows Socket 4.25H Jul 30 1999. Anyone wants to look at the dump files? What more info should i collect?


is anyone able to help?










\