I have RTP installed on your basic Compaq. It generally works well. Most
of the work I do on the system is done via a telnet connection. It
appears that inetd, or something related to network services, goes down
under circumstances I don’t understand.
What I observe is that Neutrino will sometimes stop responding to
requests to initiate telnet sessions. When this happens, existing telnet
sessions will be closed and no further sessions will be startable until
the system is rebooted. I suspect that killing some process and
restarting may be sufficient, but I haven’t tried to figure out if it is
or which processes those would be.
Sometimes other tcp services (e.g. ping responses) will go down with
telnet. Usually, I am able to find that io-net has dumped core when this
happens, although I don’t know how to get useful information from a core
file for io-net.
I’ve not been able to find any reasonable correlation to any other
network activity which may trigger these behaviors. Has anyone else seen
behavior similar to what I’m seeing? Does anyone have a suggestion of
what may be happening or how I might get Neutrino to help me figure out
why it doesn’t like my network?
Thanks in advance,
Eric
Can you describe which network services you’re using.
- which driver(s)
- which stack
- qnet?
- ppp?
Eric Berdahl <berdahl@intelligentparadigm.com> wrote:
: I have RTP installed on your basic Compaq. It generally works well. Most
: of the work I do on the system is done via a telnet connection. It
: appears that inetd, or something related to network services, goes down
: under circumstances I don’t understand.
: What I observe is that Neutrino will sometimes stop responding to
: requests to initiate telnet sessions. When this happens, existing telnet
: sessions will be closed and no further sessions will be startable until
: the system is rebooted. I suspect that killing some process and
: restarting may be sufficient, but I haven’t tried to figure out if it is
: or which processes those would be.
: Sometimes other tcp services (e.g. ping responses) will go down with
: telnet. Usually, I am able to find that io-net has dumped core when this
: happens, although I don’t know how to get useful information from a core
: file for io-net.
: I’ve not been able to find any reasonable correlation to any other
: network activity which may trigger these behaviors. Has anyone else seen
: behavior similar to what I’m seeing? Does anyone have a suggestion of
: what may be happening or how I might get Neutrino to help me figure out
: why it doesn’t like my network?
: Thanks in advance,
: Eric
In article <912s30$d60$1@nntp.qnx.com>, Sean Boudreau <seanb@qnx.com>
wrote:
Can you describe which network services you’re using.
I don’t know which driver is controlling it (and I’m not sure how to
figure that out) but the ethernet card is from Accton Technology Corp.
From “pci -v” (at a time when the system is properly functioning):
Class = Network (Ethernet)
Vendor ID = 1113h, Accton Technology Corporation
Device ID = 1211h, Unknown Unknown
PCI index = 0h
Class Codes = 020000h
Revision ID = 10h
Bus number = 0
Device number = 4
Function num = 0
Status Reg = 200h
Command Reg = 7h
Header type = 0h Single-function
BIST = 0h Build-in-self-test not supported
Latency Timer = 42h
Cache Line Size= 0h
IO Address = 2000h length 128 enabled
Mem Address = 50900000h 32bit length 128 enabled
Subsystem Vendor ID = 1113h
Subsystem ID = 1211h
Max Lat = 64ns
Min Gnt = 32ns
PCI Int Pin = INT A
Interrupt line = 10
In terms of “network services”, I am using th inetd.conf from the RTP
installation. I have not modified it. For that matter, I haven’t changed
any of the default configuration files.
I believe I’m using the tiny stack. io-net is started with the following
arguments:
io-net -pttcpip -ppppmgr -drtl pci=0
I am not using qnet.
I am not using ppp. All my network is through a 10BaseT hardwire into my
LAN (and, thereby to the rest of the world). The machine has a static IP
address (i.e. not DHCP).
Does this help suggest what may be happening?
Eric
The tiny stack in patch A fixes a bug where connection requests
on a particular port would be ignored after a dup SYN was received.
This could explain why telnet requests sometime are ignored.
Slaying and restarting inetd should fix this until the patch is
released, or you could run the large stack.
As to why io-net is core dumping, I’m not sure yet. The info
you provided helps narrow it down a little.
-seanb
Eric Berdahl <berdahl@intelligentparadigm.com> wrote:
: In article <912s30$d60$1@nntp.qnx.com>, Sean Boudreau <seanb@qnx.com>
: wrote:
:> Can you describe which network services you’re using.
:> - which driver(s)
: I don’t know which driver is controlling it (and I’m not sure how to
: figure that out) but the ethernet card is from Accton Technology Corp.
: From “pci -v” (at a time when the system is properly functioning):
: Class = Network (Ethernet)
: Vendor ID = 1113h, Accton Technology Corporation
: Device ID = 1211h, Unknown Unknown
: PCI index = 0h
: Class Codes = 020000h
: Revision ID = 10h
: Bus number = 0
: Device number = 4
: Function num = 0
: Status Reg = 200h
: Command Reg = 7h
: Header type = 0h Single-function
: BIST = 0h Build-in-self-test not supported
: Latency Timer = 42h
: Cache Line Size= 0h
: IO Address = 2000h length 128 enabled
: Mem Address = 50900000h 32bit length 128 enabled
: Subsystem Vendor ID = 1113h
: Subsystem ID = 1211h
: Max Lat = 64ns
: Min Gnt = 32ns
: PCI Int Pin = INT A
: Interrupt line = 10
: In terms of “network services”, I am using th inetd.conf from the RTP
: installation. I have not modified it. For that matter, I haven’t changed
: any of the default configuration files.
:> - which stack
: I believe I’m using the tiny stack. io-net is started with the following
: arguments:
: io-net -pttcpip -ppppmgr -drtl pci=0
:> - qnet?
: I am not using qnet.
:> - ppp?
: I am not using ppp. All my network is through a 10BaseT hardwire into my
: LAN (and, thereby to the rest of the world). The machine has a static IP
: address (i.e. not DHCP).
: Does this help suggest what may be happening?
: Eric
Continuing the informational data dump, telnet “went down” last night.
As it usually does, it also took down all tcp stuff (telnet, ftp, ping,
the works, nothing gets either in or out of the box). After the work
locked up (and before I restarted the machine to fix the problem), I
captured a few pidins (pidin ar, pidin mem, and pidin). These may
provide some insight. If this gives you any other clues or if you want
more info, let me know – telnet seems to have a half-life of about a
day, so it’s pretty easy to run more autopsies.
So, one should be able to slay inetd and restart it? I’ll give that a
try next time.
I look forward to patch A.
Thanks,
Eric
pid Arguments
1 (n/a)
2 devc-con -n4
4099 pci-bios
4100 /sbin/tinit -p
4101 devb-eide blk auto=partition cam quiet eide dma eide dma
4102 fs-pkg -a/pkgs/base/safe-config/etc/system/package/packages
8199 slogger
12296 pipe
147465 dumper -d /var/dumps
110602 devc-ser8250 -u1 3f8,4
94219 devc-pty -n32
94220 mqueue
126989 devb-fdc cam quiet blk auto=partition,cache=100k
110606 devc-par -p0x378
151567 inetd
110608 io-net -pttcpip -ppppmgr -drtl pci=0
536593 in.telnetd -Q
110610 deva-solo
110611 spooler -d/dev/par1
1945620 pterm
208917 Photon -g -lphlogin “-Sphshutdown -l”
253974 fontsleuth -d /usr/photon/font_repository
1945623 /bin/sh
245784 /usr/photon/bin/phfontFA -d /usr/photon/font_repository -j -s
300k
286745 io-graphics -g1024x768x16 -dldevg-s3_savage.so -I0
-d0x5333,0x8a22
536602 -sh
303131 devi-hirun kbd fd -d/dev/kbd ps2 kb -2
1757212 pwm
1785885 shelf
1822750 bkgdmgr
1822751 wmswitch
1822752 saver
1953825 pidin ar
1835043 Xphoton -once
1835044 gtwm
pid tid name prio STATE code data
stack
1 1 (n/a) 0f READY 1092K 0
0(320)*
1 2 (n/a) 10r RECEIVE 1092K 0
0(4096)
1 3 (n/a) 10r RECEIVE 1092K 0
0(4096)
1 4 (n/a) 10r RECEIVE 1092K 0
0(4096)
1 5 (n/a) 15r RECEIVE 1092K 0
0(4096)
1 6 (n/a) 10r RECEIVE 1092K 0
0(4096)
1 7 (n/a) 10r RUNNING 1092K 0
0(4096)
1 8 (n/a) 6r NANOSLEEP 1092K 0
0(128K)
1 9 (n/a) 10r RECEIVE 1092K 0
0(4096)
1 10 (n/a) 10r RECEIVE 1092K 0
0(4096)
1 11 (n/a) 10r RECEIVE 1092K 0
0(4096)
zero @cfbf1000 12K 12K
zero @cfbfd000 12K
2 1 devc-con 10r RECEIVE 36K 56K
4096(516K)*
ldqnx.so.1 @b0300000 300K 12K
/dev/mem @40100000 ( 0) 4096
/dev/mem @40101000 ( b8000) 32K
4099 1 ios/x86/o/pci-bios 15r RECEIVE 28K 40K
4096(516K)*
ldqnx.so.1 @b0300000 300K 12K
4100 1 /tinit/x86/o/tinit 10o REPLY 8192 20K
4096(516K)*
ldqnx.so.1 @b0300000 300K 12K
4101 1 de/x86/o/devb-eide 10o SIGWAITINFO 24K 12M
8192(516K)*
4101 2 de/x86/o/devb-eide 21r RECEIVE 24K 12M
4096(8192)
4101 3 de/x86/o/devb-eide 21r RECEIVE 24K 12M
4096(8192)
4101 4 de/x86/o/devb-eide 10o RECEIVE 24K 12M
4096(16K)
4101 5 de/x86/o/devb-eide 10r CONDVAR 24K 12M
4096(16K)
4101 7 de/x86/o/devb-eide 10o RECEIVE 24K 12M
4096(16K)
4101 8 de/x86/o/devb-eide 10o RECEIVE 24K 12M
4096(16K)
4101 9 de/x86/o/devb-eide 10o RECEIVE 24K 12M
4096(16K)
ldqnx.so.1 @b0300000 300K 12K
libcam.so.1 @b034e000 36K 8192
cam-disk.so @b0359000 8192 8192
io-blk.so @b035d000 92K 4096
cam-cdrom.so @b0375000 12K 4096
fs-cd.so @b0379000 32K 4096
fs-qnx4.so @b0382000 36K 4096
4102 1 r/pkg/x86/o/fs-pkg 10o RECEIVE 96K 376K
20K(132K)
4102 2 r/pkg/x86/o/fs-pkg 10o SIGWAITINFO 96K 376K
4096(132K)
4102 3 r/pkg/x86/o/fs-pkg 10o RECEIVE 96K 376K
20K(132K)
4102 4 r/pkg/x86/o/fs-pkg 10o RECEIVE 96K 376K
16K(132K)
4102 5 r/pkg/x86/o/fs-pkg 10o RECEIVE 96K 376K
16K(132K)
4102 6 r/pkg/x86/o/fs-pkg 10o RECEIVE 96K 376K
12K(132K)
ldqnx.so.1 @b0300000 300K 12K
8199 1 bin/slogger 10o RECEIVE 8192 68K
4096(516K)*
ldqnx.so.1 @b0300000 300K 12K
12296 1 to/pipe/x86/o/pipe 10o RECEIVE 12K 36K
4096(132K)
12296 2 to/pipe/x86/o/pipe 10o RECEIVE 12K 36K
4096(132K)
12296 3 to/pipe/x86/o/pipe 10o RECEIVE 12K 36K
4096(132K)
ldqnx.so.1 @b0300000 300K 12K
147465 1 umper/x86/o/dumper 10o RECEIVE 12K 40K
4096(516K)*
ldqnx.so.1 @b0300000 300K 12K
110602 1 devc-ser8250 24o RECEIVE 24K 36K
4096(516K)*
ldqnx.so.1 @b0300000 300K 12K
94219 1 devc-pty 10o RECEIVE 24K 116K
4096(516K)*
ldqnx.so.1 @b0300000 300K 12K
94220 1 queue/x86/o/mqueue 10o RECEIVE 8192 40K
4096(516K)*
ldqnx.so.1 @b0300000 300K 12K
126989 1 fdc/x86/o/devb-fdc 10o SIGWAITINFO 20K 208K
8192(516K)*
126989 2 fdc/x86/o/devb-fdc 21r RECEIVE 20K 208K
4096(8192)
126989 3 fdc/x86/o/devb-fdc 10o RECEIVE 20K 208K
4096(16K)
126989 4 fdc/x86/o/devb-fdc 10o CONDVAR 20K 208K
4096(16K)
126989 5 fdc/x86/o/devb-fdc 10o RECEIVE 20K 208K
4096(16K)
126989 6 fdc/x86/o/devb-fdc 10o RECEIVE 20K 208K
4096(16K)
ldqnx.so.1 @b0300000 300K 12K
libcam.so.1 @b034e000 36K 8192
cam-disk.so @b0359000 8192 8192
io-blk.so @b035d000 92K 4096
110606 1 devc-par 10o RECEIVE 24K 36K
4096(516K)*
110606 2 devc-par 9r CONDVAR 24K 36K
4096(132K)
ldqnx.so.1 @b0300000 300K 12K
151567 1 td/nto/x86/o/inetd 10o SIGWAITINFO 16K 20K
8192(516K)*
ldqnx.so.1 @b0300000 300K 12K
libsocket.so.1 @b034e000 52K 12K
110608 1 o-net/x86/o/io-net 10o SIGWAITINFO 36K 364K
8192(516K)*
110608 2 o-net/x86/o/io-net 10o RECEIVE 36K 364K
4096(12K)
110608 3 o-net/x86/o/io-net 10o RECEIVE 36K 364K
4096(12K)
110608 4 o-net/x86/o/io-net 21o RECEIVE 36K 364K
4096(132K)
110608 5 o-net/x86/o/io-net 21r RECEIVE 36K 364K
4096(132K)
110608 6 o-net/x86/o/io-net 17f CONDVAR 36K 364K
4096(132K)
110608 7 o-net/x86/o/io-net 10o RECEIVE 36K 364K
4096(12K)
110608 8 o-net/x86/o/io-net 19f CONDVAR 36K 364K
4096(132K)
110608 11 o-net/x86/o/io-net 18f CONDVAR 36K 364K
4096(132K)
ldqnx.so.1 @b0300000 300K 12K
npm-ttcpip.so @b034e000 72K 8192
npm-pppmgr.so @b0362000 20K 8192
devn-rtl.so @b0369000 44K 4096
536593 1 /nto/x86/o/telnetd 10o SIGWAITINFO 40K 32K
16K(516K)*
ldqnx.so.1 @b0300000 300K 12K
libsocket.so.1 @b034e000 52K 12K
110610 1 to/x86/o/deva-solo 10o SIGWAITINFO 20K 84K
8192(516K)*
110610 2 to/x86/o/deva-solo 15r INTR 20K 84K
4096(132K)
110610 3 to/x86/o/deva-solo 5r CONDVAR 20K 84K
4096(132K)
110610 4 to/x86/o/deva-solo 10o RECEIVE 20K 84K
4096(132K)
110610 5 to/x86/o/deva-solo 10o RECEIVE 20K 84K
4096(132K)
ldqnx.so.1 @b0300000 300K 12K
libsnd.so.1 @b034e000 292K 28K
110611 1 oler/x86/o/spooler 10o NANOSLEEP 12K 40K
8192(516K)*
ldqnx.so.1 @b0300000 300K 12K
1945620 1 r/photon/bin/pterm 10r RECEIVE 40K 136K
8192(516K)*
ldqnx.so.1 @b0300000 300K 12K
libAp.so.1 @b034e000 72K 4096
libph.so.1 @b0361000 1196K 48K
libphrender.so.1 @b0498000 232K 8192
libm.so.1 @b04d4000 88K 4096
208917 1 /photon/bin/Photon 10r RECEIVE 64K 88K
8192(516K)*
ldqnx.so.1 @b0300000 300K 12K
253974 1 ton/bin/fontsleuth 6o RECEIVE 16K 64K
8192(516K)*
ldqnx.so.1 @b0300000 300K 12K
libph.so.1 @b034e000 1196K 48K
libphrender.so.1 @b0485000 232K 8192
1945623 1 bin/sh 10r SIGSUSPEND 136K 72K
8192(516K)*
ldqnx.so.1 @b0300000 300K 12K
245784 1 hoton/bin/phfontFA 12r RECEIVE 284K 912K
12K(516K)*
ldqnx.so.1 @b0300000 300K 12K
/dev/mem @40100000 ( 0) 32K
286745 1 io-graphics 12r REPLY 144K 148K
8192(516K)*
ldqnx.so.1 @b0300000 300K 12K
libph.so.1 @b034e000 1196K 48K
libphrender.so.1 @b0485000 232K 8192
devg-s3_savage.so @b04c1000 24K 4096
libffb.so.1 @b04c8000 28K 4096
libdisputil.so.1 @b04d0000 24K 4096
/dev/mem @40100000 ( 0) 32K
/dev/mem @40108000 (40000000) 8M
/dev/mem @40918000 (48000000) 8192K
/dev/mem @41118000 ( 0) 2304K
536602 1 bin/sh 10o REPLY 136K 72K
8192(516K)*
ldqnx.so.1 @b0300000 300K 12K
303131 1 o/x86/o/devi-hirun 15o RECEIVE 52K 24K
8192(516K)*
303131 2 o/x86/o/devi-hirun 10o REPLY 52K 24K
4096(132K)
303131 3 o/x86/o/devi-hirun 12o SIGWAITINFO 52K 24K
8192(132K)
303131 4 o/x86/o/devi-hirun 15o RECEIVE 52K 24K
4096(132K)
ldqnx.so.1 @b0300000 300K 12K
libph.so.1 @b034e000 1196K 48K
libphrender.so.1 @b0485000 232K 8192
1757212 1 usr/photon/bin/pwm 10r RECEIVE 116K 56K
8192(516K)*
ldqnx.so.1 @b0300000 300K 12K
libph.so.1 @b034e000 1196K 48K
libphrender.so.1 @b0485000 232K 8192
1785885 1 r/photon/bin/shelf 10r RECEIVE 48K 360K
12K(516K)*
1785885 2 r/photon/bin/shelf 10r CONDVAR 48K 360K
16K(132K)
1785885 3 r/photon/bin/shelf 10r NANOSLEEP 48K 360K
4096(132K)
ldqnx.so.1 @b0300000 300K 12K
libAp.so.1 @b034e000 72K 4096
libph.so.1 @b0361000 1196K 48K
libphrender.so.1 @b0498000 232K 8192
libm.so.1 @b04d4000 88K 4096
launchmenu.so @b04eb000 32K 8192
libexpat.so.1 @b04f5000 92K 8192
taskbar.so @b050e000 24K 4096
launcher.so @b0515000 12K 4096
volume.so @b0519000 12K 4096
libasound.so.1 @b051d000 96K 8192
pload.so @b0537000 12K 8192
clock.so @b053c000 12K 4096
1822750 1 photon/bin/bkgdmgr 10r REPLY 96K 124K
8192(516K)*
ldqnx.so.1 @b0300000 300K 12K
libAp.so.1 @b034e000 72K 4096
libph.so.1 @b0361000 1196K 48K
libphrender.so.1 @b0498000 232K 8192
libm.so.1 @b04d4000 88K 4096
/dev/mem @40100000 ( 0) 2304K
1822751 1 hoton/bin/wmswitch 10r RECEIVE 8192 56K
8192(516K)*
ldqnx.so.1 @b0300000 300K 12K
libAp.so.1 @b034e000 72K 4096
libph.so.1 @b0361000 1196K 48K
libphrender.so.1 @b0498000 232K 8192
libm.so.1 @b04d4000 88K 4096
1822752 1 r/photon/bin/saver 10r REPLY 16K 56K
8192(516K)*
ldqnx.so.1 @b0300000 300K 12K
libAp.so.1 @b034e000 72K 4096
libph.so.1 @b0361000 1196K 48K
libphrender.so.1 @b0498000 232K 8192
libm.so.1 @b04d4000 88K 4096
1978401 1 /pidin/x86/o/pidin 10r REPLY 24K 48K
8192(516K)*
ldqnx.so.1 @b0300000 300K 12K
1835043 1 ./Xphoton 10r SIGWAITINFO 964K 820K
132K(516K)*
ldqnx.so.1 @b0300000 300K 12K
libsocket.so.1 @b034e000 52K 12K
libm.so.1 @b035e000 88K 4096
libph.so.1 @b0375000 1196K 48K
libphrender.so.1 @b04ac000 232K 8192
/dev/mem @40100000 ( 0) 4096
1835044 1 gtwm 10r SIGWAITINFO 64K 352K
12K(516K)*
ldqnx.so.1 @b0300000 300K 12K
libSM.so.6 @b034e000 32K 4096
libICE.so.6 @b0357000 72K 12K
libXt.so.6 @b036c000 240K 16K
libXext.so.6 @b03ac000 36K 4096
libXmu.so.6 @b03b6000 64K 8192
libX11.so.6 @b03c8000 580K 20K
libsocket.so.1 @b045e000 52K 12K
libph.so.1 @b046e000 1196K 48K
libphrender.so.1 @b05a5000 232K 8192
pid tid name prio STATE Blocked
1 1 (n/a) 0f READY
1 2 (n/a) 10r RECEIVE 1
1 3 (n/a) 10r RECEIVE 1
1 4 (n/a) 10r RECEIVE 1
1 5 (n/a) 15r RECEIVE 1
1 6 (n/a) 10r RECEIVE 1
1 7 (n/a) 10r RUNNING
1 8 (n/a) 6r NANOSLEEP
1 9 (n/a) 10r RECEIVE 1
1 10 (n/a) 10r RECEIVE 1
1 11 (n/a) 10r RECEIVE 1
2 1 devc-con 10r RECEIVE 1
4099 1 ios/x86/o/pci-bios 15r RECEIVE 1
4100 1 /tinit/x86/o/tinit 10o REPLY 208917
4101 1 de/x86/o/devb-eide 10o SIGWAITINFO
4101 2 de/x86/o/devb-eide 21r RECEIVE 1
4101 3 de/x86/o/devb-eide 21r RECEIVE 4
4101 4 de/x86/o/devb-eide 10o RECEIVE 10
4101 5 de/x86/o/devb-eide 10r CONDVAR b0374468
4101 7 de/x86/o/devb-eide 10o RECEIVE 7
4101 8 de/x86/o/devb-eide 10o RECEIVE 7
4101 9 de/x86/o/devb-eide 10o RECEIVE 7
4102 1 r/pkg/x86/o/fs-pkg 10o RECEIVE 1
4102 2 r/pkg/x86/o/fs-pkg 10o SIGWAITINFO
4102 3 r/pkg/x86/o/fs-pkg 10o RECEIVE 1
4102 4 r/pkg/x86/o/fs-pkg 10o RECEIVE 1
4102 5 r/pkg/x86/o/fs-pkg 10o RECEIVE 1
4102 6 r/pkg/x86/o/fs-pkg 10o RECEIVE 1
8199 1 bin/slogger 10o RECEIVE 1
12296 1 to/pipe/x86/o/pipe 10o RECEIVE 1
12296 2 to/pipe/x86/o/pipe 10o RECEIVE 1
12296 3 to/pipe/x86/o/pipe 10o RECEIVE 1
147465 1 umper/x86/o/dumper 10o RECEIVE 1
110602 1 devc-ser8250 24o RECEIVE 1
94219 1 devc-pty 10o RECEIVE 1
94220 1 queue/x86/o/mqueue 10o RECEIVE 1
126989 1 fdc/x86/o/devb-fdc 10o SIGWAITINFO
126989 2 fdc/x86/o/devb-fdc 21r RECEIVE 1
126989 3 fdc/x86/o/devb-fdc 10o RECEIVE 7
126989 4 fdc/x86/o/devb-fdc 10o CONDVAR b0374468
126989 5 fdc/x86/o/devb-fdc 10o RECEIVE 4
126989 6 fdc/x86/o/devb-fdc 10o RECEIVE 4
110606 1 devc-par 10o RECEIVE 1
110606 2 devc-par 9r CONDVAR 804e260
151567 1 td/nto/x86/o/inetd 10o SIGWAITINFO
110608 1 o-net/x86/o/io-net 10o SIGWAITINFO
110608 2 o-net/x86/o/io-net 10o RECEIVE 1
110608 3 o-net/x86/o/io-net 10o RECEIVE 1
110608 4 o-net/x86/o/io-net 21o RECEIVE 3
110608 5 o-net/x86/o/io-net 21r RECEIVE 13
110608 6 o-net/x86/o/io-net 17f CONDVAR 805d94c
110608 7 o-net/x86/o/io-net 10o RECEIVE 1
110608 8 o-net/x86/o/io-net 19f CONDVAR 8052268
110608 11 o-net/x86/o/io-net 18f CONDVAR 805c778
536593 1 /nto/x86/o/telnetd 10o SIGWAITINFO
110610 1 to/x86/o/deva-solo 10o SIGWAITINFO
110610 2 to/x86/o/deva-solo 15r INTR
110610 3 to/x86/o/deva-solo 5r CONDVAR b034bc04
110610 4 to/x86/o/deva-solo 10o RECEIVE 1
110610 5 to/x86/o/deva-solo 10o RECEIVE 1
110611 1 oler/x86/o/spooler 10o NANOSLEEP
1945620 1 r/photon/bin/pterm 10r RECEIVE 1
208917 1 /photon/bin/Photon 12r RECEIVE 1
253974 1 ton/bin/fontsleuth 6o RECEIVE 1
1945623 1 bin/sh 10r SIGSUSPEND
245784 1 hoton/bin/phfontFA 12r RECEIVE 1
286745 1 io-graphics 12r REPLY 208917
536602 1 bin/sh 10o REPLY 94219
303131 1 o/x86/o/devi-hirun 15o RECEIVE 1
303131 2 o/x86/o/devi-hirun 10o REPLY 2
303131 3 o/x86/o/devi-hirun 12o SIGWAITINFO
303131 4 o/x86/o/devi-hirun 15o RECEIVE 1
1757212 1 usr/photon/bin/pwm 10r RECEIVE 1
1785885 1 r/photon/bin/shelf 10r RECEIVE 1
1785885 2 r/photon/bin/shelf 10r CONDVAR b04f3ea4
1785885 3 r/photon/bin/shelf 10r NANOSLEEP
1822750 1 photon/bin/bkgdmgr 10r REPLY 208917
1822751 1 hoton/bin/wmswitch 10r RECEIVE 2
1822752 1 r/photon/bin/saver 10r REPLY 208917
2002977 1 /pidin/x86/o/pidin 10r REPLY 1
1835043 1 ./Xphoton 10r SIGWAITINFO
1835044 1 gtwm 10r SIGWAITINFO
I think I’ve found something in the rtl driver. I don’t think
the inetd thing will work.
-seanb
Eric Berdahl <berdahl@intelligentparadigm.com> wrote:
: Continuing the informational data dump, telnet “went down” last night.
: As it usually does, it also took down all tcp stuff (telnet, ftp, ping,
: the works, nothing gets either in or out of the box). After the work
: locked up (and before I restarted the machine to fix the problem), I
: captured a few pidins (pidin ar, pidin mem, and pidin). These may
: provide some insight. If this gives you any other clues or if you want
: more info, let me know – telnet seems to have a half-life of about a
: day, so it’s pretty easy to run more autopsies.
: So, one should be able to slay inetd and restart it? I’ll give that a
: try next time.
You can download the latest devn-rtl.so from
http://www.qnx.com/~cdm if you want to give it
a try.
-seanb
Sean Boudreau <seanb@qnx.com> wrote:
: I think I’ve found something in the rtl driver. I don’t think
: the inetd thing will work.
: -seanb
: Eric Berdahl <berdahl@intelligentparadigm.com> wrote:
: : Continuing the informational data dump, telnet “went down” last night.
: : As it usually does, it also took down all tcp stuff (telnet, ftp, ping,
: : the works, nothing gets either in or out of the box). After the work
: : locked up (and before I restarted the machine to fix the problem), I
: : captured a few pidins (pidin ar, pidin mem, and pidin). These may
: : provide some insight. If this gives you any other clues or if you want
: : more info, let me know – telnet seems to have a half-life of about a
: : day, so it’s pretty easy to run more autopsies.
: : So, one should be able to slay inetd and restart it? I’ll give that a
: : try next time.
In article <91lj8q$d99$1@nntp.qnx.com>, Sean Boudreau <seanb@qnx.com>
wrote:
You can download the latest devn-rtl.so from
http://www.qnx.com/~cdm > if you want to give it
a try.
FYI: I pulled this down and installed it as soon as I saw your note
(circa the 18th). I have seen zero recurrences of the “telnet hang” I
was seeing previously. The previous MTBF was 30 hours, so this is a
great improvement. Thanks!!