'sin ve' be hung up, do you know why?

Surprise!

when I run ‘sin ve’ on a QNX 4.25 machine, the following message list and
the process sin hung up.

/home/user$sin ve
PROGRAM NAME VERSION DATE
sys/Proc32 Proc 4.25H Oct 15 1998
sys/Proc32 Slib16 4.23G Oct 04 1996
sys/Slib32 Slib32 4.24B Aug 12 1997
/bin/Fsys Fsys32 4.24S Jul 16 1998
/bin/Fsys Floppy 4.24B Aug 19 1997
/bin/Fsys.eide eide 4.24M May 13 1998
//2/bin/Dev32 Dev32 4.23G Oct 04 1996
//2/bin/Dev32.ansi Dev32.ansi 4.23H Nov 21 1996
//2/bin/Dev32.ser Dev32.ser 4.23I Jun 27 1997
//2/bin/Dev32.par Dev.par 4.26 Feb 24 2000
//2/bin/Dev32.pty Dev32.pty 4.23G Oct 04 1996
//2/bin/Mouse Mouse 4.24A Aug 22 1997
//2/bin/Pipe Pipe 4.23A Feb 26 1996
//2/bin/Net Net 4.25C Aug 30 1999
//2/bin/Net.ether82557 Net.ether825 4.25G Feb 17 2000
//2/*/usr/ucb/Socklet Socklet 4.25C Aug 19 1998

Then, on other terminal, I run other sin process and see the following info:

/home/user$sin -n2
SID PID PROGRAM PRI STATE BLK CODE DATA
– – Microkernel — ----- — 12976 0
0 1 sys/Proc32 30f READY — 122k 573k
0 2 sys/Slib32 10r RECV 0 53k 4096
0 4 /bin/Fsys 22r RECV 0 77k 18747k
0 5 /bin/Fsys.eide 22r RECV 0 61k 110k
0 8 idle 0r READY — 0 40k
0 16 //2/bin/Dev32 24f RECV 0 32k 106k
0 19 //2/bin/Dev32.ansi 20r RECV 0 40k 135k
0 21 //2/bin/Dev32.ser 20r RECV 0 16k 32k
0 22 //2/bin/Dev32.par 9o RECV 0 8192 20k
0 23 //2/bin/Dev32.pty 20r RECV 0 12k 32k
0 28 //2/bin/Mouse 10o RECV 0 16k 20k
0 31 //2/bin/Fsys.floppy 10o RECV 0 20k 40k
0 32 //2/bin/Pipe 10r RECV 0 16k 32k
0 38 //2/bin/Net 23r READY — 32k 73k
0 40 //2/bin/Net.ether82557 20r RECV 0 40k 176k
0 45 //2/bin/nameloc 20o RECV 0 6144 20k
0 46 //2/bin/nameloc 20o REPLY 0 6144 16k
0 48 //2/bin/netboot 10o RECV 53 32k 40k
0 55 //2/bin/Dev.csp256 10o RECV 0 20k 20k
0 57 //2/bin/tinit 10o WAIT -1 16k 28k
0 62 //2//usr/ucb/Socklet 10r RECV 0 114k 172k
0 70 //2/
/usr/bin/syslogd 10o RECV 0 36k 32k
0 74 //2//usr/ucb/inetd 10o RECV 75 36k 32k
1 80 //2/bin/ksh 10o WAIT -1 9420 45k
0 147 //2/
/usr/ucb/telnetd 10o RECV 151 13k 53k
2 149 //2/bin/ksh 10o WAIT -1 9420 45k
1 169 //2/home/185/rht/rhtls 18f RECV 0 32k 20k
1 175 //2/home/185/rht/rhtvp 18f RECV 0 102k 49k
1 177 //2//185/rht/rhtrdsp 18f RECV 0 36k 106k
3 303 //2/bin/ksh 10o WAIT -1 9420 45k
0 322 //2/
/usr/ucb/telnetd 10o RECV 326 13k 53k
4 324 //2/bin/ksh 10o WAIT -1 9420 49k
0 372 //2//usr/ucb/telnetd 10o RECV 376 13k 53k
5 374 //2/bin/ksh 10o WAIT -1 9420 45k
6 411 //2/bin/ksh 10o WAIT -1 9420 45k
7 449 //2/bin/ksh 10o REPLY 16 9420 45k
6 653 //2/home/185/ivr 10o RECV 0 79k 172k
8 845 //2/bin/ksh 10o WAIT -1 9420 45k
9 1743 //2/bin/ksh 10o REPLY 16 9420 45k
3 2800 //2/home/185/Dev.vp 16o REPLY 175 4505 24k
1 3160 //2/home/185/COMM 10o RECV 0 34k 49k
1 4662 //2/home/185/MAINT 10o RECV 0 36k 32k
1 4669 //2/home/185/MAINT 10o SEM 5 36k 8192
1 4675 //2/home/185/ACD 10o RECV 0 47k 167k
1 4677 //2/home/185/ACD 10o SEM 43 47k 167k
1 4687 //2/home/185/TRS 10o RECV 0 53k 32k
1 4692 //2/home/185/swp 10o RECV 0 53k 32k
1 4693 //2/home/185/MONI 10o RECV 0 57k 36k
1 4702 //2/home/185/COMM 10o SEM 47 34k 49k
1 4723 //2/home/185/EPH 10o RECV 0 57k 36k
3 4738 //2/home/185/Dev.vp 16o RECV 0 4505 24k
3 4739 //2/home/185/Dev.vp 16o SEM 57 4505 24k
6 4751 //2/home/185/ivr 10o SEM 61 79k 172k
2 4791 //2/home/185/cp_256 10o RECV 0 131k 45k
2 4792 //2/home/185/cp_256 10o SEM 51 131k 286k
4 4813 //2/
/185/conf256.soft 10o RECV 0 139k 57k
5 4826 //2/home/185/ccs256_p 10o RECV 0 106k 196k
5 4828 //2/home/185/ccs256_p 10o SEM 65 106k 196k
8 4845 //2/home/185/infw 10o REPLY 62 69k 24k
3 4853 //2/home/185/Dev.vp 16o REPLY 175 4505 24k
3 4854 //2/home/185/Dev.vp 16o REPLY 175 4505 24k
3 4855 //2/home/185/Dev.vp 16o REPLY 175 4505 24k
3 5192 //2/home/185/Dev.vp 16o RECV 0 4505 24k
3 11680 //2/home/185/Dev.vp 16o RECV 0 4505 24k
3 12218 //2/home/185/Dev.vp 16o RECV 0 4505 24k
3 12968 //2/home/185/Dev.vp 16o RECV 0 4505 24k
0 31691 //2/*/usr/ucb/telnetd 10o RECV 31695 13k 53k
10 31693 //2/bin/ksh 10o WAIT -1 9420 45k
10 31751 //2/bin/sin 10o REPLY 5192 45k 49k
/home/user$

I don’t know what’s wrong. I can see that sin process(PID 31751) was REPLY
blocked by porcess 5192. But what cause it? Pls help me get out it. Thank
you.

Any reply will be appreciated.


Cheers,

-Eric Zhou
2eric@21cn.com

Eric Zhou <2Eric@21cn.com> wrote:

I don’t know what’s wrong. I can see that sin process(PID 31751) was REPLY
blocked by porcess 5192. But what cause it? Pls help me get out it. Thank
you.

Dev.vp is setup to be a ‘server’ using qnx_pflags(), but does not seem to be handling
system version messages properly.

i don’t think Dev.vp is something QSSL ships, so it is probably either a third party product
or something you (your company) wrote itself.

Mike Taillon <miket@qnx.com> wrote in message
news:8sfgt6$e4b$2@nntp.qnx.com

Dev.vp is setup to be a ‘server’ using qnx_pflags(), but does not seem to
be handling
system version messages properly.

Dev.vp is not a server, it just a client, the server is rhtvp (process 175).

the rhtvp process is a driver of Brooktruck Voice Card.

i don’t think Dev.vp is something QSSL ships, so it is probably either a
third party product
or something you (your company) wrote itself.

Yea, Dev.vp just is a program writen by myself, that’s using qnx_ioctl()

function to do something with ‘rhtvp’.

I don’t know what can cause that the ‘sin ve’ hung up, while ‘sin in’,
‘sin fd’ or ‘sin rt’, etc. working properly.

Thank you for your reply.

-Eric Zhou

“Eric Zhou” <2Eric@21cn.com> wrote in message
news:8sg85k$6av$1@inn.qnx.com

Mike Taillon <> miket@qnx.com> > wrote in message
news:8sfgt6$e4b$> 2@nntp.qnx.com> …

Dev.vp is setup to be a ‘server’ using qnx_pflags(), but does not seem
to
be handling
system version messages properly.

Dev.vp is not a server, it just a client, the server is rhtvp (process
175).
the rhtvp process is a driver of Brooktruck Voice Card.

i don’t think Dev.vp is something QSSL ships, so it is probably either a
third party product
or something you (your company) wrote itself.

Yea, Dev.vp just is a program writen by myself, that’s using qnx_ioctl()
function to do something with ‘rhtvp’.

I don’t know what can cause that the ‘sin ve’ hung up, while ‘sin in’,
‘sin fd’ or ‘sin rt’, etc. working properly.

When you do sin fd or sin rt a message is send to Proc32 to get the

information.
But when you sin ver, a message is sent to every program that has the server
flag
set via qnx_pflags. So your program is receiving a message (a your request)
that you are not replying to.

Thank you for your reply.

-Eric Zhou

Thank you Mike and Mario.

Now I got the point, I’ll contact with Brooktrout Tech. for their help.

-Eric Zhou


Mario Charest <mcz@videotron.ca> wrote in message
news:8sheps$e85$3@inn.qnx.com

“Eric Zhou” <> 2Eric@21cn.com> > wrote in message
news:8sg85k$6av$> 1@inn.qnx.com> …

Mike Taillon <> miket@qnx.com> > wrote in message
news:8sfgt6$e4b$> 2@nntp.qnx.com> …

Dev.vp is setup to be a ‘server’ using qnx_pflags(), but does not
seem
to
be handling
system version messages properly.

Dev.vp is not a server, it just a client, the server is rhtvp (process
175).
the rhtvp process is a driver of Brooktruck Voice Card.

i don’t think Dev.vp is something QSSL ships, so it is probably either
a
third party product
or something you (your company) wrote itself.

Yea, Dev.vp just is a program writen by myself, that’s using qnx_ioctl()
function to do something with ‘rhtvp’.

I don’t know what can cause that the ‘sin ve’ hung up, while ‘sin in’,
‘sin fd’ or ‘sin rt’, etc. working properly.

When you do sin fd or sin rt a message is send to Proc32 to get the
information.
But when you sin ver, a message is sent to every program that has the
server
flag
set via qnx_pflags. So your program is receiving a message (a your
request)
that you are not replying to.

Thank you for your reply.

-Eric Zhou
\