Proc32 crash

Hi

I got the following kernel dump when trying to execute “ping qnx5” (my node
5) from a NT Phindows pterm window on qnx2 (my node 2):

Version 425.L Feb 15 2001 Technical Support: +1 (613) 591-0941
Proc fault 1, ldt 100 sys/Proc32; fault e+0
cd:eip=5:89c1 ss:esp=d:f7c0f50 efl=12097 ds=d es=d fs=0 gs=0
eax/44b2 ebx/3ba05c69 ecx/1eb4d81 edx/1 esi/0 edi/1 ebp/f7c0f5c
Stack (d:f7c0f50)
08544536 01eb4d81 00021601 0f7c0fa0 00003820 0000a26c 00008a48 00003820
0000a26c 00008000 08544536 00008c04 000202f0 00000000 00000000 00000000
3ba05c69 00000001 00000001 00000001 0f7c0fb8 00000000 00005969 000202f0
00008fd5 0000000a 0f7c0fe8 00005969 0000000b 00003822 0f7c0fd0 000057aa
Process Entry (addr 6050)
00000000 00000001 00000000 00000001 00000000 00000000 30020207 00001e1e
00005844 0100000d 00006108 ffffffff 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000501 000d0005 00007118 00000000 00000002
00000022 00000000 00000220 0000c140 00000000 00000000 0001f0a0 00000000
00000000 00000000 00000000 ffff0001 00000000 00000000 00000000
TRAP:
cs/00f0 ss/00f8 ds/00f8 es/00f8 fs/0000 gs/0000 ldt/0100
edi/0000000e esi/00006050 ebp/00001500 ebx/000060ec edx/000000f8
ecx/000000f8 ezx/00000780 eip/0000712b esp/000014e4 psw/00002003

Can anyone tell me anything more about the crash based on the above info?
I’m running this on a Compaq Deskpro.

Ouput from sin ver on qnx2:

PROGRAM NAME VERSION DATE
sys/Proc32 Proc 4.25L Feb 15 2001
sys/Proc32 Slib16 4.23G Oct 04 1996
sys/Slib32 Slib32 4.24B Aug 12 1997
/bin/Fsys Fsys32 4.24V Feb 18 2000
/bin/Fsys Floppy 4.24B Aug 19 1997
/bin/Fsys IDE 4.24B Jun 09 1998
//2/bin/Dev32 Dev32 4.23G Oct 04 1996
//2/bin/Pipe Pipe 4.23A Feb 26 1996
//2/bin/Dev32.ser Dev32.ser 4.23I Jun 27 1997
//2/bin/Dev32.ser Dev32.ser 4.23I Jun 27 1997
//2/bin/Dev32.ansi Dev32.ansi 4.23H Nov 21 1996
//2/bin/Dev32.par Dev32.par 4.25A Jan 08 2001
//2/bin/Dev32.pty Dev32.pty 4.23G Oct 04 1996
//2/bin/Fsys.eide eide 4.25A Feb 09 2000
//2/bin/Iso9660fsys Iso9660fsys 4.23D Mar 20 2000
//2/bin/Net Net 4.25C Aug 30 1999
//2/bin/Net.ether509 Net.ether509 4.24A Jun 26 1998
//2//usr/ucb/Socklet Socklet 4.25H Jul 30 1999
//2/
/bin/phfontpfr Photon Font 1.14H Jan 17 2001
//2/*/photon/bin/Photon Photon 1.14B Sep 03 1999

Output from sin info on qnx2:
Node CPU Machine Speed Memory Ticksize Display
Flags
2 686/687 PCI 26980 46882k/66711k 10.0ms VGA
Color -3P±---------8P

Heapp Heapf Heapl Heapn Hands Names Sessions Procs Timers Nodes Virtual
0 0 22400 0 64 100 64 500 125 7 16M/
75M

Boot from Hard at Sep 13 09:40 Locators: 2 4 5 1

Thanks in advance,
P-O Håkansson

“P-O Hakansson” <par-olof.hakansson@gambro.com> wrote:

I got the following kernel dump when trying to execute “ping qnx5” (my node
5) from a NT Phindows pterm window on qnx2 (my node 2):

Do you mean you have a phindows session with a terminal telneted to QNX2, which
in turn is doing a “ping qnx5”?

Version 425.L Feb 15 2001 Technical Support: +1 (613) 591-0941
Proc fault 1, ldt 100 sys/Proc32; fault e+0
cd:eip=5:89c1 ss:esp=d:f7c0f50 efl=12097 ds=d es=d fs=0 gs=0
eax/44b2 ebx/3ba05c69 ecx/1eb4d81 edx/1 esi/0 edi/1 ebp/f7c0f5c
Stack (d:f7c0f50)
08544536 01eb4d81 00021601 0f7c0fa0 00003820 0000a26c 00008a48 00003820
0000a26c 00008000 08544536 00008c04 000202f0 00000000 00000000 00000000
3ba05c69 00000001 00000001 00000001 0f7c0fb8 00000000 00005969 000202f0
00008fd5 0000000a 0f7c0fe8 00005969 0000000b 00003822 0f7c0fd0 000057aa
Process Entry (addr 6050)
00000000 00000001 00000000 00000001 00000000 00000000 30020207 00001e1e
00005844 0100000d 00006108 ffffffff 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000501 000d0005 00007118 00000000 00000002
00000022 00000000 00000220 0000c140 00000000 00000000 0001f0a0 00000000
00000000 00000000 00000000 ffff0001 00000000 00000000 00000000
TRAP:
cs/00f0 ss/00f8 ds/00f8 es/00f8 fs/0000 gs/0000 ldt/0100
edi/0000000e esi/00006050 ebp/00001500 ebx/000060ec edx/000000f8
ecx/000000f8 ezx/00000780 eip/0000712b esp/000014e4 psw/00002003

Can anyone tell me anything more about the crash based on the above info?
I’m running this on a Compaq Deskpro.

It seems to be dying in some timer relate code. Did this just start happening?
Can you reproduce the problem each time? What happens if use the IP address
of the machine instead?


Ouput from sin ver on qnx2:

Do you mean QNX4?

-Adam
amallory@qnx.com

Hi
“Operating System for Tech Supp” <os@qnx.com> wrote in message
news:9nqhfe$6jg$4@nntp.qnx.com

“P-O Hakansson” <> par-olof.hakansson@gambro.com> > wrote:

I got the following kernel dump when trying to execute “ping qnx5” (my
node
5) from a NT Phindows pterm window on qnx2 (my node 2):

Do you mean you have a phindows session with a terminal telneted to QNX2,
which
in turn is doing a “ping qnx5”?
Sorry for the confusion. What I meant to write was that I was sitting at my

NT PC with a Phindows session running. In that Phindows session I had 5-6
pterm windows, in one of those windows I wrote “ping qnx5”. “qnx5” is the
network name for my #5 QNX4 node. “qnx2” is the network name for node #2 of
my QNX4 PCs.

Can anyone tell me anything more about the crash based on the above
info?
I’m running this on a Compaq Deskpro.

It seems to be dying in some timer relate code. Did this just start
happening?
Can you reproduce the problem each time? What happens if use the IP
address
of the machine instead?
This was an isolated incident, I don’t think I can reproduce it. I’ve used

ping many times with no problems.

My concern is that we will be using QNX4 in a medical device, if someone
could explain this crash I would be much calmer.

While I’m at it, could you please offer any comments regarding my post
September 10th in the “Computer locks up” thread? I also posted on that
subject back in May, but there were no comments.
Our IT-department tells me that there might be something “fishy” in parts of
our network. Still, I think the entire PC should not be allowed to lock-up
because of this. It is highly repeatable, it will happen sooner or later
when a QNX4 PC is hooked up to the network in that lab. In the same lab
Windows PCs run without problem. I’m not comfortable developing a medical
device that is likely to be hooked up to a hospital network, knowing that it
locks up in our own lab!

Can you tell me of the best ways you can think of to hopefully get some
trace information to help understand my lock up problem?

Thanks in advance,
P-O Håkansson