I’ve been chasing a problem. I thought it was an issue with the driver I
am writing, but apparently not. I have duplicated this several times this
morning:
start up QNX (6.2.1 PE)
log in
spin
slay io-net
wait a while (maybe 10 minutes I think)
observe spin stop responding, and the cpu bar in the System Monitor pin at
100%. At this point many things work, but some things consistently hang. A
good example is qcc. pidin (which sometimes doesn’t work at this point,
but usually does) reveals that qcc is blocked on pid 1 with REPLY. This
isn’t so unusual (pidin reports the same thing when the system is normal),
but the fact that qcc hangs indefinitely is.
I have output from pidin from before and after, attached. I also have a
screenshot but it’s not much to see - just the cpu bar pinned and spin not
doing anything (like you could see that in a screenshot).
Can anyone else duplicate this?
Interestingly, if I start a new io-net process at first (before slaying
the original) and slay it, I have no problems. It’s not until I slay the
‘main’ io-net process that the problem occurs.
I had an xterm open once when I slayed io-net and the problem was
instantaneous instead of delayed several minutes. Suspecting X and/or
photon, I did the experiment in text mode and after a half hour the
problem had not manifested itself. So, I tried uninstalling X, and
performing the experiment again - same result as the text mode.
So, it must be related to X, eh?
slay XPhoton
before you “slay io-net” and see it you still have the problem.
BTW, we all know XPhoton (or X in general) relies on io-net,
so slaying io-net will probably upset XPhoton…
Hans Fugal <fugalh@byu.edu> wrote:
I’ve been chasing a problem. I thought it was an issue with the driver I
am writing, but apparently not. I have duplicated this several times this
morning:
start up QNX (6.2.1 PE)
log in
spin
slay io-net
wait a while (maybe 10 minutes I think)
observe spin stop responding, and the cpu bar in the System Monitor pin at
100%. At this point many things work, but some things consistently hang. A
good example is qcc. pidin (which sometimes doesn’t work at this point,
but usually does) reveals that qcc is blocked on pid 1 with REPLY. This
isn’t so unusual (pidin reports the same thing when the system is normal),
but the fact that qcc hangs indefinitely is.
I have output from pidin from before and after, attached. I also have a
screenshot but it’s not much to see - just the cpu bar pinned and spin not
doing anything (like you could see that in a screenshot).
Can anyone else duplicate this?
Interestingly, if I start a new io-net process at first (before slaying
the original) and slay it, I have no problems. It’s not until I slay the
‘main’ io-net process that the problem occurs.
I had an xterm open once when I slayed io-net and the problem was
instantaneous instead of delayed several minutes. Suspecting X and/or
photon, I did the experiment in text mode and after a half hour the
problem had not manifested itself. So, I tried uninstalling X, and
performing the experiment again - same result as the text mode.
So, it must be related to X, eh?
I have a bad habit of forgetting attachments.
On Thu, 15 May 2003 17:22:20 +0000, fli wrote:
slay XPhoton
before you “slay io-net” and see it you still have the problem.
Indeed, that prevents the problem. It also remedies the problem if you do
it the other way around.
BTW, we all know XPhoton (or X in general) relies on io-net,
so slaying io-net will probably upset XPhoton…
That was no surprise. (Although it took me off-guard when my xterm
disappeared the first time I slayed io-net. 
<fliu@mail.vipstage.com> wrote in message news:ba0icc$nbm$1@inn.qnx.com…
slay XPhoton
before you “slay io-net” and see it you still have the problem.
BTW, we all know XPhoton (or X in general) relies on io-net,
so slaying io-net will probably upset XPhoton…
Being a developer debuggin io-net/tcpip a lot, I know for fact that slay
io-net will make XPhoton running ready on priority 10. (pidin | grep READY
is your friend).
Normally you don’t realize this, but since QCC do it’s main work on
priority 9, you will find that out immediatly.
-xtang
Hans Fugal <> fugalh@byu.edu> > wrote:
I’ve been chasing a problem. I thought it was an issue with the driver I
am writing, but apparently not. I have duplicated this several times
this
morning:
start up QNX (6.2.1 PE)
log in
spin
slay io-net
wait a while (maybe 10 minutes I think)
observe spin stop responding, and the cpu bar in the System Monitor pin
at
100%. At this point many things work, but some things consistently hang.
A
good example is qcc. pidin (which sometimes doesn’t work at this point,
but usually does) reveals that qcc is blocked on pid 1 with REPLY. This
isn’t so unusual (pidin reports the same thing when the system is
normal),
but the fact that qcc hangs indefinitely is.
I have output from pidin from before and after, attached. I also have a
screenshot but it’s not much to see - just the cpu bar pinned and spin
not
doing anything (like you could see that in a screenshot).
Can anyone else duplicate this?
Interestingly, if I start a new io-net process at first (before slaying
the original) and slay it, I have no problems. It’s not until I slay the
‘main’ io-net process that the problem occurs.
I had an xterm open once when I slayed io-net and the problem was
instantaneous instead of delayed several minutes. Suspecting X and/or
photon, I did the experiment in text mode and after a half hour the
problem had not manifested itself. So, I tried uninstalling X, and
performing the experiment again - same result as the text mode.
So, it must be related to X, eh?