Question

Attached with this mail is a copy of “sin” that I took
recently. If you look for the process called “poll” there are three
hyphens in the block column. WHenever this happens the server stops
sending and receiving data from some remote location. We dont know why
this happen in fact we dont even know the meaning of that. The only way
out of it is to re boot the server which cannot be done very often. I
would appreciate your feed back on it.

Thanks
Lalit Agarwal


SID PID PROGRAM PRI STATE BLK CODE DATA
– – Microkernel — ----- — 12976 0
0 1 /boot/sys/Proc32 30f READY — 122k 3559k
0 2 /boot/sys/Slib32 10r RECV 0 53k 4096
0 4 /bin/Fsys 10r RECV 0 77k 9539k
0 5 /bin/Fsys.aha7scsi 22r RECV 0 57k 262k
0 8 idle 0r READY — 0 40k
0 16 //1/bin/Dev32 24f RECV 0 32k 94k
0 21 //1/bin/Pipe 10r RECV 0 16k 32k
0 23 //1/bin/Dev32.ser 20r RECV 0 16k 24k
0 24 //1/bin/Dev32.ser 20r RECV 0 16k 24k
0 25 //1/bin/Dev32.ansi 20r RECV 0 40k 49k
0 30 //1/bin/Dev32.pty 20r RECV 0 12k 57k
0 33 //1/bin/Fsys.eide 22r RECV 0 61k 114k
0 34 //1/bin/Iso9660fsys 10o RECV 0 28k 61k
0 38 //1/bin/Fsys.floppy 10o RECV 0 20k 40k
0 43 //1/bin/Net 23r RECV 0 32k 73k
0 46 //1/bin/Net.tulip 20r RECV 0 69k 131k
0 52 //1/bin/nameloc 20o RECV 0 6144 20k
0 53 //1/bin/nameloc 20o REPLY 0 6144 16k
0 58 //1//usr/ucb/Socklet 10r RECV 0 114k 245k
0 70 //1/
/usr/ucb/routed 10o RECV 73 49k 45k
0 71 //1//usr/ucb/inetd 10o RECV 76 36k 32k
0 80 //1/bin/cron 10o RECV 0 24k 20k
0 82 //1/
/usr/bin/syslogd 10o RECV 0 36k 32k
0 83 //1/bin/dumper 29o RECV 0 16k 20k
2 90 //1//fdi/eqn/Dev.eqn 21r RECV 0 65k 671k
2 92 //1/bin/Dev32 24f RECV 0 32k 94k
2 95 //1/bin/Dev32 24f RECV 0 32k 94k
3 103 //1/usr/bin/ems 10o REPLY 58 46k 368k
0 112 //1/bin/tinit 10o WAIT -1 5461 28k
0 113 //1/bin/tinit 10o WAIT -1 5461 28k
0 114 //1/bin/tinit 10o WAIT -1 5461 28k
3 116 //1/
/bin/dbsrv50 10o RECV 0 860k 2920k
4 120 //1/bin/modem 10o RECV 121 2560 12k
7 126 //1/bin/modem 10o RECV 127 2560 12k
8 128 //1/bin/modem 10o RECV 129 2560 16k
9 130 //1/bin/modem 10o RECV 131 2560 12k
12 140 //1//photon/bin/Photon 12r RECV 0 28k 49k
0 144 //1/
/bin/phfontpfr 10r RECV 0 106k 380k
0 145 //1//drivers/s3bios.ms 10o RECV 0 40k 28k
0 147 //1/
/drivers/Pg.s3 12r REPLY 140 118k 139k
0 152 //1/bin/Input 12o RECV 0 30k 28k
0 155 //1/bin/Input 10o RECV 0 30k 4096
13 175 //1//photon/bin/pwm 10o RECV 0 40k 69k
14 190 //1/
/photon/bin/pdm 10o RECV 0 67k 2981k
3 219 //1/usr/bin/fioserver 10o RECV 0 49k 307k
3 227 //1/usr/bin/pcc 10o RECV 0 86k 278k
3 235 //1/usr/bin/poll 8r READY — 20k 28k
3 246 //1/usr/bin/gblcast 10o RECV 0 28k 28k
3 266 //1/usr/bin/cosserver 10o REPLY 58 28k 36k
3 275 //1/usr/bin/ems 10o RECV 0 46k 507k
3 354 //1/usr/bin/cos 9r RECV 0 81k 204k
18 922 //1/bin/SMBfsys 15r RECV 0 57k 45k
10 2236 //1/bin/modem 10o RECV 2237 2560 12k
3 2453 //1/usr/bin/cosserver 10o REPLY 0 28k 36k
14 3659 //1//photon/bin/pterm 10o RECV 0 16k 102k
1 3851 //1/bin/Fsys.dos 10o RECV 0 102k 90k
6 4270 //1/bin/modem 10o RECV 4272 2560 12k
5 4751 //1/bin/modem 10o RECV 4756 2560 12k
11 4758 //1/bin/modem 10o RECV 4759 2560 12k
3 4971 //1/usr/bin/cosserver 10o REPLY 0 28k 204k
3 4978 //1/usr/bin/ems 10o RECV 0 46k 507k
0 5257 //1/
/bin/phrelay 10o RECV 0 53k 184k
15 5281 //1//photon/bin/Photon 10r RECV 0 28k 69k
16 5304 //1/
/photon/bin/pwm 10o RECV 0 40k 86k
17 5324 //1//photon/bin/pdm 10o RECV 0 67k 2981k
17 5337 //1/
/photon/bin/pterm 10o RECV 0 16k 188k
19 5341 //1/bin/ksh 10o WAIT -1 31k 36k
17 5473 //1//photon/bin/pfm 10o RECV 0 81k 262k
20 5504 //1/qnx4/vedit/vedit 9o READY — 151k 339k
21 5510 //1/qnx4/vedit/vedit 9o READY — 151k 339k
19 5706 //1/usr/bin/elvis 10o REPLY 16 94k 65k
22 5711 //1/bin/ksh 10o WAIT -1 31k 36k
22 5718 //1/bin/less 10o REPLY 16 126k 86k
17 5720 //1/
/photon/bin/pterm 10o RECV 0 16k 188k
23 5736 //1/bin/ksh 10o WAIT -1 31k 36k
23 5739 //1/bin/sin 10o REPLY 1 45k 49k

“lalit” <lalit@engrs.unl.edu> wrote in message
news:39B69F6F.B08B3F2E@engrs.unl.edu

Attached with this mail is a copy of “sin” that I took
recently. If you look for the process called “poll” there are three
hyphens in the block column. WHenever this happens the server stops
sending and receiving data from some remote location. We dont know why
this happen in fact we dont even know the meaning of that. The only way
out of it is to re boot the server which cannot be done very often. I
would appreciate your feed back on it.

Thanks
Lalit Agarwal



0 8 idle 0r READY — 0 40k
3 235 //1/usr/bin/poll 8r READY — 20k 28k
20 5504 //1/qnx4/vedit/vedit 9o READY — 151k 339k
21 5510 //1/qnx4/vedit/vedit 9o READY — 151k 339k

The ready state means you program is READY to run but
cannot because somebody else is using the CPU. You cannot
even CTR-C it because it can’t even run to process the CTRL-C

It seems the process using the CPU is vedit (running ready also).
Vedit can be in this state if you close the pterm window without
cleanly exiting from vedit ( the latest release of vedit 5,16 fix that I
beleive).

So if you slay vedit, the cpu should become available for poll.

The priority of vedit (9) is cause by the automatic decay of priority
when a process uses the CPU for more then time slice.

Hope that helps.

Mario

Hey Mario! That helps and it works just fine. Thanks a lot. Now I get it that
the vedit is causing all this problem. When I use vedit for a considerable
size file, it just hangs and I close the window and thats when I think the
process did not get killed and spoiled the process on the lower priority.
what is the release 5, 16 that you were talking about? Please let me know and
thanks a lot again.

Lalit

Mario Charest wrote:

“lalit” <> lalit@engrs.unl.edu> > wrote in message
news:> 39B69F6F.B08B3F2E@engrs.unl.edu> …
Attached with this mail is a copy of “sin” that I took
recently. If you look for the process called “poll” there are three
hyphens in the block column. WHenever this happens the server stops
sending and receiving data from some remote location. We dont know why
this happen in fact we dont even know the meaning of that. The only way
out of it is to re boot the server which cannot be done very often. I
would appreciate your feed back on it.

Thanks
Lalit Agarwal



0 8 idle 0r READY — 0 40k
3 235 //1/usr/bin/poll 8r READY — 20k 28k
20 5504 //1/qnx4/vedit/vedit 9o READY — 151k 339k
21 5510 //1/qnx4/vedit/vedit 9o READY — 151k 339k


The ready state means you program is READY to run but
cannot because somebody else is using the CPU. You cannot
even CTR-C it because it can’t even run to process the CTRL-C

It seems the process using the CPU is vedit (running ready also).
Vedit can be in this state if you close the pterm window without
cleanly exiting from vedit ( the latest release of vedit 5,16 fix that I
beleive).

So if you slay vedit, the cpu should become available for poll.

The priority of vedit (9) is cause by the automatic decay of priority
when a process uses the CPU for more then time slice.

Hope that helps.

Mario

“lalit” <lalit@engrs.unl.edu> wrote in message
news:39B6ABC2.B6AB0684@engrs.unl.edu

Hey Mario! That helps and it works just fine. Thanks a lot.

Glad I could help, makes me feel better when I’m having a bad week :wink:

Now I get it that the vedit is causing all this problem. When I use vedit
for a considerable
size file, it just hangs and I close the window and thats when I think the
process did not get killed and spoiled the process on the lower priority.

When that happen go in another window and slay vedit. If there are
multiple vedit slay will ask you if you want to slay each vedit
one by one. To know which one is the right one, slay will display
the terminal connect to the process. In your case that will
be the /dev/ttypX name that will be in the windows title where
vedit is runing.

what is the release 5, 16 that you were talking about?

Please let me know and thanks a lot again.

The latest is 5.16 and you can download it free from
http://www.vedit.com/unix.htm#qnx

Hey Mario! Thanks man… I really appreciate your help. You dont know what great
help you have been. I got the relase 5.16 and it works fine now without harming
other lower priority processes. Thanks again :slight_smile:

Lalit

Mario Charest wrote:

“lalit” <> lalit@engrs.unl.edu> > wrote in message
news:> 39B6ABC2.B6AB0684@engrs.unl.edu> …
Hey Mario! That helps and it works just fine. Thanks a lot.

Glad I could help, makes me feel better when I’m having a bad week > :wink:

Now I get it that the vedit is causing all this problem. When I use vedit
for a considerable
size file, it just hangs and I close the window and thats when I think the
process did not get killed and spoiled the process on the lower priority.

When that happen go in another window and slay vedit. If there are
multiple vedit slay will ask you if you want to slay each vedit
one by one. To know which one is the right one, slay will display
the terminal connect to the process. In your case that will
be the /dev/ttypX name that will be in the windows title where
vedit is runing.

what is the release 5, 16 that you were talking about?

Please let me know and thanks a lot again.


The latest is 5.16 and you can download it free from
http://www.vedit.com/unix.htm#qnx