I’ve got an io-usb process using most of one core’s CPU on a QNX641 project using gns. It seems to spike when I run debug-configurations and deploy to my models, it’s not always repeatable. AFAICT I’m not using any USB devices, just ps2 mice/keyboards and pci cards.
I mention the fact it’s using gns because I get problems with named channels when the io-usb problem is showing.
No cores have been dumped. Sorry to be esoteric, just wondered if anyone else had anything similar? thanks
bit more detail:
[code]# top
PID TID PRI STATE HH:MM:SS CPU COMMAND
4101 3 21 Run 0:04:43 27.48% io-usb
0 4101 2 - Mar05 ? 00:00:00 io-usb -duhci -dohci -dehci
0 4101 2 - Mar05 ? 00:00:00 io-usb -duhci -dohci -dehci
0 4101 2 - Mar05 ? 00:00:00 io-usb -duhci -dohci -dehci
0 4101 2 - Mar05 ? 00:00:00 io-usb -duhci -dohci -dehci
0 4101 2 - Mar05 ? 00:00:00 io-usb -duhci -dohci -dehci
0 4101 2 - Mar05 ? 00:00:00 io-usb -duhci -dohci -dehci
0 4101 2 - Mar05 ? 00:00:00 io-usb -duhci -dohci -dehci
0 4101 2 - Mar05 ? 00:00:00 io-usb -duhci -dohci -dehci
0 4101 2 - Mar05 ? 00:00:00 io-usb -duhci -dohci -dehci
0 4101 2 - Mar05 ? 00:00:00 io-usb -duhci -dohci -dehci
0 4101 2 - Mar05 ? 00:00:00 io-usb -duhci -dohci -dehci
0 4101 2 - Mar05 ? 00:00:00 io-usb -duhci -dohci -dehci
0 4102 2 - Mar05 ? 00:00:01 io-hid -d ps2ser kbd:kbddev:ps2mouse:mousedev -d usb /dev/io-usb/io-usb
0 4102 2 - Mar05 ? 00:00:01 io-hid -d ps2ser kbd:kbddev:ps2mouse:mousedev -d usb /dev/io-usb/io-usb
0 4102 2 - Mar05 ? 00:00:01 io-hid -d ps2ser kbd:kbddev:ps2mouse:mousedev -d usb /dev/io-usb/io-usb
0 4102 2 - Mar05 ? 00:00:01 io-hid -d ps2ser kbd:kbddev:ps2mouse:mousedev -d usb /dev/io-usb/io-usb
0 4102 2 - Mar05 ? 00:00:01 io-hid -d ps2ser kbd:kbddev:ps2mouse:mousedev -d usb /dev/io-usb/io-usb
0 4102 2 - Mar05 ? 00:00:01 io-hid -d ps2ser kbd:kbddev:ps2mouse:mousedev -d usb /dev/io-usb/io-usb
0 4102 2 - Mar05 ? 00:00:01 io-hid -d ps2ser kbd:kbddev:ps2mouse:mousedev -d usb /dev/io-usb/io-usb
0 438307 344096 - 14:50 ? 00:00:00 grep io-usb[/code]
so do I suspect my ps2 mouse and keyboard?
If that’s a real PS2 keyobard/mouse (plugged into the PS2 ports) then no, you should not suspect them.
Obviously QNX thinks something is plugged into your USB ports. You may not have anything on the external USB ports but many motherboards these days have internal USB ports. You might want to open your case and see if the internal USB connecters are present and wired to something you don’t expect. That or see if you can turn off the internal USB connectors in the BIOS.
Also I wonder how QNX handles the new USB3 connectors/bus. Anyone know if this is handled by QNX?
Tim
I’ve worked on an embedded system that had a touch screen. The touch screen interface was USB, but there were no USB plugs anywhere. The touch screen just connected into the motherboard.
Why not run: usb -vvvv and see what you find.
any ideas why I can’t slay the process without getting into trouble? I’m telnetting via putty and when I slay the process my keyboard stops? cheers
Which keyboard stops? The one connected to the QNX machine or the telnet session via Putty? I’m sort of confused why you need to use Putty to slay io-usb when you could do it directly on the QNX machine with the QNX keyoard.
The other possibility I suppose is that some process got started in QNX and is trying to connect to some USB device that isn’t there and is repeatedly trying to do so in a tight loop. Since you are Puttying in can you capture the output of ‘pidin’ so we can see what’s going on.
Tim
I’m puttying in because my hosts in the lab and I’m at my desk, process 4101 is the one misbehaving according to top.
When I ‘slay 4101’ (or slay io-usb) via putty my keyboard locks, then my putty/telnet session closes, the host doesn’t answer pings etc. then when i visit the host it’s unresponsive. It’s crashed. No new core files in /var/dumps.
I thought I would have been ok slaying the io-usb process? is that ok? apart from unresponsive USB devices I thought QNX shouldn’t care? Cheers
# pidin
pid tid name prio STATE Blocked
1 1 /procnto-smp-instr 0f READY
1 2 /procnto-smp-instr 0f READY
1 3 /procnto-smp-instr 10r RECEIVE 1
1 4 /procnto-smp-instr 255r RECEIVE 1
1 5 /procnto-smp-instr 255r RECEIVE 1
1 6 /procnto-smp-instr 255r RECEIVE 1
1 8 /procnto-smp-instr 10r RECEIVE 1
1 9 /procnto-smp-instr 10r RECEIVE 1
1 10 /procnto-smp-instr 10r RECEIVE 1
1 11 /procnto-smp-instr 10r RECEIVE 1
1 12 /procnto-smp-instr 10r RUNNING
1 15 /procnto-smp-instr 10r RECEIVE 1
1 16 /procnto-smp-instr 10r RECEIVE 1
2 1 sbin/tinit 10o REPLY 1
4099 1 proc/boot/pci-bios 10o RECEIVE 1
4100 1 proc/boot/slogger 35o RECEIVE 1
4101 1 proc/boot/io-usb 10o SIGWAITINFO
4101 2 proc/boot/io-usb 21r RECEIVE 4
4101 3 proc/boot/io-usb 21r RUNNING
4101 4 proc/boot/io-usb 21r RECEIVE 10
4101 5 proc/boot/io-usb 21r RECEIVE 13
4101 6 proc/boot/io-usb 21r RECEIVE 16
4101 7 proc/boot/io-usb 21r RECEIVE 19
4101 8 proc/boot/io-usb 21r RECEIVE 22
4101 9 proc/boot/io-usb 21r RECEIVE 1
4101 10 proc/boot/io-usb 10o RECEIVE 25
4101 11 proc/boot/io-usb 10r NANOSLEEP
4101 12 proc/boot/io-usb 10o RECEIVE 25
4102 1 proc/boot/io-hid 10o SIGWAITINFO
4102 2 proc/boot/io-hid 21r RECEIVE 1
4102 3 proc/boot/io-hid 9r RECEIVE 16
4102 4 proc/boot/io-hid 9r RECEIVE 12
4102 5 proc/boot/io-hid 10r REPLY 4101
4102 6 proc/boot/io-hid 10o RECEIVE 4
4102 7 proc/boot/io-hid 10o RECEIVE 4
4103 1 /boot/devc-con-hid 10o RECEIVE 1
4103 2 /boot/devc-con-hid 10o REPLY 4102
8200 1 roc/boot/devb-eide 10o SIGWAITINFO
8200 2 roc/boot/devb-eide 21r RECEIVE 1
8200 3 roc/boot/devb-eide 21r RECEIVE 4
8200 4 roc/boot/devb-eide 10o RECEIVE 10
8200 5 roc/boot/devb-eide 10o RECEIVE 7
8200 6 roc/boot/devb-eide 10o RECEIVE 7
8200 7 roc/boot/devb-eide 10o RECEIVE 7
8200 8 roc/boot/devb-eide 10o RECEIVE 7
8200 10 roc/boot/devb-eide 10o RECEIVE 7
20489 1 sbin/pipe 10o SIGWAITINFO
20489 2 sbin/pipe 10o RECEIVE 1
20489 3 sbin/pipe 10o RECEIVE 1
20489 4 sbin/pipe 10o RECEIVE 1
20489 5 sbin/pipe 10o RECEIVE 1
24586 1 sbin/mqueue 10o RECEIVE 1
53259 1 usr/sbin/mcd 10o RECEIVE 1
53259 2 usr/sbin/mcd 10o NANOSLEEP
53259 3 usr/sbin/mcd 10o SIGWAITINFO
53259 4 usr/sbin/mcd 9o NANOSLEEP
53259 5 usr/sbin/mcd 10o SIGWAITINFO
53259 6 usr/sbin/mcd 10o SIGWAITINFO
53259 7 usr/sbin/mcd 10o SIGWAITINFO
57356 1 usr/sbin/random 10o SIGWAITINFO
57356 2 usr/sbin/random 10o RECEIVE 1
57356 3 usr/sbin/random 10o NANOSLEEP
61453 1 sbin/enum-devices 10o REPLY 20489
77840 1 sbin/enum-usb 10o SIGWAITINFO
77840 2 sbin/enum-usb 10r REPLY 4101
90126 1 sbin/io-audio 10o SIGWAITINFO
90126 2 sbin/io-audio 10o RECEIVE 1
90126 3 sbin/io-audio 10o RECEIVE 1
90126 4 sbin/io-audio 10o RECEIVE 1
110609 1 sbin/io-display 10o SIGWAITINFO
110609 2 sbin/io-display 10o RECEIVE 1
110609 3 sbin/io-display 12o RECEIVE 1
110609 4 sbin/io-display 10o RECEIVE 3
110609 5 sbin/io-display 10o RECEIVE 1
126994 1 sbin/io-pkt-v4-hc 21o SIGWAITINFO
126994 2 sbin/io-pkt-v4-hc 21o RECEIVE 16
126994 3 sbin/io-pkt-v4-hc 10o RECEIVE 1
126994 4 sbin/io-pkt-v4-hc 10o RECEIVE 22
126994 5 sbin/io-pkt-v4-hc 21o CONDVAR (0xb827071c)
126994 6 sbin/io-pkt-v4-hc 20o RECEIVE 27
126994 7 sbin/io-pkt-v4-hc 9o RECEIVE 19
167951 1 sbin/devc-ser8250 24o RECEIVE 1
167958 1 sbin/devc-par 10o RECEIVE 1
167958 2 sbin/devc-par 9r CONDVAR (0x8057eac)
204819 1 sbin/devc-pty 10o READY
217108 1 usr/sbin/dumper 10o RECEIVE 1
229400 1 usr/sbin/inetd 10o SIGWAITINFO
237589 1 usr/sbin/qconn 10o SIGWAITINFO
237589 2 usr/sbin/qconn 10o CONDVAR (0x8067df0)
237589 3 usr/sbin/qconn 10o RECEIVE 1
237589 4 usr/sbin/qconn 10o RECEIVE 3
262167 1 bin/login 10o REPLY 4103
262169 1 bin/login 10o REPLY 4103
262170 1 bin/login 10o REPLY 4103
290845 1 /photon/bin/Photon 10r RECEIVE 1
311326 1 on/bin/io-graphics 12r CONDVAR (0x805cf7c)
311326 2 on/bin/io-graphics 10r RECEIVE 1
311326 3 on/bin/io-graphics 12r REPLY 290845
315423 1 hoton/bin/phlogin2 10r READY 290845
327713 1 hoton/bin/devi-hid 10o RECEIVE 1
327713 2 hoton/bin/devi-hid 10o REPLY 4102
327713 3 hoton/bin/devi-hid 12o SIGWAITINFO
327713 5 hoton/bin/devi-hid 10o RECEIVE 1
339995 1 bin/login 10o REPLY 4103
675868 1 usr/sbin/telnetd 10o SIGWAITINFO
679968 1 bin/sh 10o SIGSUSPEND
725026 1 usr/sbin/gns 10o RECEIVE 1
909347 1 bin/pidin 10o REPLY 1# pidin | grep 4101
4101 1 proc/boot/io-usb 10o SIGWAITINFO
4101 2 proc/boot/io-usb 21r RECEIVE 4
4101 3 proc/boot/io-usb 21r RECEIVE 7
4101 4 proc/boot/io-usb 21r RECEIVE 10
4101 5 proc/boot/io-usb 21r RECEIVE 13
4101 6 proc/boot/io-usb 21r RECEIVE 16
4101 7 proc/boot/io-usb 21r RECEIVE 19
4101 8 proc/boot/io-usb 21r RECEIVE 22
4101 9 proc/boot/io-usb 21r RECEIVE 1
4101 10 proc/boot/io-usb 10o RECEIVE 25
4101 11 proc/boot/io-usb 10r NANOSLEEP
4101 12 proc/boot/io-usb 10o RECEIVE 25
4102 5 proc/boot/io-hid 10r REPLY 4101
77840 2 sbin/enum-usb 10r REPLY 4101
I get this as well, I suspect GNS is involved somehow
[code]# gns -c
Another GNS already running
slay: Unable to find process ‘gns’
Another GNS already running
#[/code]
You are using the instrumented SMP kernel. It shouldn’t matter but it’s something to note in case someone else can think of something here.
Just a guess here. But I doubt QNX has ‘crashed’. My guess is that io-usb suddenly starts consuming 100% of the CPU Since it’s running at priority 21 and your telnet sessions and keyboard are at a lower priority they will appear to be locked up. You can test this by increasing your own shell priority to something like 30. But it’s kinda of a moot point really.
This is very interesting. It looks like QNX never finished enumerating devices on the USB bus. These are meant to run once at startup to identify what’s connected at start up time and then exit. But they aren’t. That makes me suspect this is what’s causing io-usb to hog the CPU because this never finished.
Why wouldn’t it finish is the big question. Does this MB have a built in wireless Ethernet card. Maybe it’s a wireless USB ethernet card. Or some other built in device (bluetooth) on the MB that’s connected to the USB (not by a physical cable but on the MB itself).
Unless of course your own app (mcd?) is enumerating devices for some reason.
Tim
thanks for the reply, I pretty sure there’s no other USB devices bar the 7 ports I mentioned earlier.
I can’t see how slaying the io-usb would make it hit 100% on both cores, unless slaying it kills something else that’s vital but I thought the whole point of the micro-kernel idea was that these things could be turned off?
It does this as well… the PC runs slowly (pres. due to the runaway io-usb), via putty I do a “shutdown now” and sometimes the box won’t come back up without me having to physically power cycle it, that’s just weird, AFAICT the reboot ought to be a clean start.
You are running Photon on this machine. It’s connecting to the USB driver:
4101 3 proc/boot/io-usb 21r RUNNING
4102 5 proc/boot/io-hid 10r REPLY 4101
327713 2 hoton/bin/devi-hid 10o REPLY 4102
Do you need Photon running? Have you tried shutting it down and just going to console mode and see if that makes any difference.
Anything can be turned off in QNX. But obviously if you turn off the keyboard (even if by accident and you don’t realize it) then it’s no longer going to respond and that might look like the system is hung when it’s just the keyboard that’s no longer working.
It’s sort of a process of elimination here trying to figure out what is the guilty party causing io-usb to misbehave. That’s why my suggestion is to next turn Photon off and run in console mode.
Do you recall if you saw this problem before you ran the instrumented smp kernel?
Tim
re: SMP kernel, my model’s got eclipse/momentics etc. on it, it’s not strictly an RTE, do you think this could be causing a problem?
ok, stopping photon didn’t work and the io-usb problem persists, I did notice though that upon reboot I’m getting “Enumerator error: Can’t locate PNP nodes”, I’ll have a look in the bios and see if I can disable PNP.
Very unlikely. It’s not the SMP part (which means using multiple cores), it’s the instr part which means you’ve loaded the instrumented kernel for debugging. This is much slower than the regular kernel. Not that I think it’s causing a problem, just observing that it’s different that what most people run on even for development (I only use the instr kernel if I need to do some serious timing tests or hunt for hard to find memory leaks).
Good to know. Assuming you haven’t put Photon back, did you try slaying io-usb in console mode? I’d be curious to know if it works here and if you still have keyboard control.
What about killing off io-audio? That make any difference? Or not running mcd (which I assume is your application).
The PNP nodes message probably comes from how you are booting QNX. If you are using diskboot in your boot image it runs the QNX version of plug-n-pray and attempts to detect all kinds of hardware (which could be what’s causing the issue). Normally in a final system you don’t use diskboot but instead manually start the drivers for exactly the hardware you have (devb-eide for hard drive, ethernet driver for just the card you have etc) or plan to support (USB thumb drives only type thing).
Also curious to what pidin returns with Photon shut down (ie what else no longer runs).
Tim
ok, this is interesting…
I’ve got same symptoms w/o photon being started; slay io-usb and the host doesn’t answer pings, keyboard’s unresponsive etc. (crashed),
I reboot my host and run pidin
[code]
pid tid name prio STATE Blocked
1 1 /procnto-smp-instr 0f READY
1 2 /procnto-smp-instr 0f READY
1 3 /procnto-smp-instr 10r RECEIVE 1
1 4 /procnto-smp-instr 255r RECEIVE 1
1 5 /procnto-smp-instr 255r RECEIVE 1
1 6 /procnto-smp-instr 255r RECEIVE 1
1 7 /procnto-smp-instr 10r RECEIVE 1
1 8 /procnto-smp-instr 10r RECEIVE 1
1 9 /procnto-smp-instr 10r RECEIVE 1
1 12 /procnto-smp-instr 10r RECEIVE 1
1 13 /procnto-smp-instr 10r RECEIVE 1
1 14 /procnto-smp-instr 10r RUNNING
1 15 /procnto-smp-instr 21r RECEIVE 1
2 1 sbin/tinit 10o REPLY 1
4099 1 proc/boot/pci-bios 10o RECEIVE 1
4100 1 proc/boot/slogger 21o RECEIVE 1
4101 1 proc/boot/io-usb 10o SIGWAITINFO
4101 2 proc/boot/io-usb 21r RECEIVE 4
4101 3 proc/boot/io-usb 21r RECEIVE 7
4101 4 proc/boot/io-usb 21r RECEIVE 10
4101 5 proc/boot/io-usb 21r RECEIVE 13
4101 6 proc/boot/io-usb 21r RECEIVE 16
4101 7 proc/boot/io-usb 21r RECEIVE 19
4101 8 proc/boot/io-usb 21r RECEIVE 22
4101 9 proc/boot/io-usb 21r RECEIVE 1
4101 10 proc/boot/io-usb 10o RECEIVE 25
4101 11 proc/boot/io-usb 10r NANOSLEEP
4101 12 proc/boot/io-usb 10o RECEIVE 25
4102 1 proc/boot/io-hid 10o SIGWAITINFO
4102 2 proc/boot/io-hid 21r RECEIVE 1
4102 3 proc/boot/io-hid 10o RECEIVE 4
4102 4 proc/boot/io-hid 9r RECEIVE 12
4102 5 proc/boot/io-hid 10r REPLY 4101
4102 6 proc/boot/io-hid 10o RECEIVE 4
4103 1 /boot/devc-con-hid 10o RECEIVE 1
4103 2 /boot/devc-con-hid 10o REPLY 4102
8200 1 roc/boot/devb-eide 10o SIGWAITINFO
8200 2 roc/boot/devb-eide 21r RECEIVE 1
8200 3 roc/boot/devb-eide 21r RECEIVE 4
8200 4 roc/boot/devb-eide 10o RECEIVE 10
8200 5 roc/boot/devb-eide 10o RECEIVE 7
8200 7 roc/boot/devb-eide 10o RECEIVE 7
8200 8 roc/boot/devb-eide 21o RECEIVE 7
8200 10 roc/boot/devb-eide 21o RECEIVE 7
8200 11 roc/boot/devb-eide 10o RECEIVE 7
20489 1 sbin/pipe 10o SIGWAITINFO
20489 2 sbin/pipe 10o RECEIVE 1
20489 3 sbin/pipe 10o RECEIVE 1
20489 4 sbin/pipe 10o RECEIVE 1
20489 5 sbin/pipe 10o RECEIVE 1
24586 1 sbin/mqueue 10o RECEIVE 1
53259 1 usr/sbin/mcd 10o RECEIVE 1
53259 2 usr/sbin/mcd 10o NANOSLEEP
53259 3 usr/sbin/mcd 10o SIGWAITINFO
53259 4 usr/sbin/mcd 9o NANOSLEEP
53259 5 usr/sbin/mcd 10o SIGWAITINFO
53259 6 usr/sbin/mcd 10o SIGWAITINFO
53259 7 usr/sbin/mcd 10o SIGWAITINFO
57356 1 usr/sbin/random 10o SIGWAITINFO
57356 2 usr/sbin/random 10o RECEIVE 1
57356 3 usr/sbin/random 10o NANOSLEEP
61453 1 sbin/enum-devices 10o REPLY 20489
77840 1 sbin/enum-usb 10o SIGWAITINFO
77840 2 sbin/enum-usb 10r REPLY 4101
90126 1 sbin/io-audio 10o SIGWAITINFO
90126 2 sbin/io-audio 10o RECEIVE 1
90126 3 sbin/io-audio 10o RECEIVE 1
90126 4 sbin/io-audio 10o RECEIVE 1
110609 1 sbin/io-display 10o SIGWAITINFO
110609 2 sbin/io-display 10o RECEIVE 1
110609 3 sbin/io-display 10o RECEIVE 1
110609 4 sbin/io-display 10o RECEIVE 3
110609 5 sbin/io-display 10o RECEIVE 1
126994 1 sbin/io-pkt-v4-hc 21o SIGWAITINFO
126994 2 sbin/io-pkt-v4-hc 21o RECEIVE 16
126994 3 sbin/io-pkt-v4-hc 10o RECEIVE 1
126994 4 sbin/io-pkt-v4-hc 21o RECEIVE 22
126994 5 sbin/io-pkt-v4-hc 21o CONDVAR (0xb827071c)
126994 6 sbin/io-pkt-v4-hc 20o RECEIVE 27
126994 7 sbin/io-pkt-v4-hc 10o RECEIVE 19
167951 1 sbin/devc-ser8250 10o RECEIVE 1
167958 1 sbin/devc-par 10o RECEIVE 1
167958 2 sbin/devc-par 9r CONDVAR (0x8057eac)
204819 1 sbin/devc-pty 10o RECEIVE 1
217108 1 usr/sbin/dumper 10o RECEIVE 1
229400 1 usr/sbin/inetd 10o SIGWAITINFO
237589 1 usr/sbin/qconn 10o SIGWAITINFO
237589 2 usr/sbin/qconn 10o CONDVAR (0x8067df0)
237589 3 usr/sbin/qconn 10o RECEIVE 1
237589 4 usr/sbin/qconn 10o RECEIVE 3
262167 1 bin/login 10o REPLY 4103
262169 1 bin/login 10o REPLY 4103
262170 1 bin/login 10o REPLY 4103
262171 1 bin/login 10o REPLY 4103
262172 1 usr/sbin/telnetd 10o SIGWAITINFO
266269 1 bin/sh 10o SIGSUSPEND[/code]
then I slayed io-audio
then I slayed io-usb ← no symptoms being shown of problem at this point and slaying io-usb here doesn’t crash the host, all appears OK
slayed mcd (Media Detection and Content Recognition System apparently),
and ran pidin again
# pidin
pid tid name prio STATE Blocked
1 1 /procnto-smp-instr 0f RUNNING
1 2 /procnto-smp-instr 0f READY
1 3 /procnto-smp-instr 10r RECEIVE 1
1 4 /procnto-smp-instr 255r RECEIVE 1
1 5 /procnto-smp-instr 255r RECEIVE 1
1 6 /procnto-smp-instr 255r RECEIVE 1
1 7 /procnto-smp-instr 10r RUNNING
1 8 /procnto-smp-instr 10r RECEIVE 1
1 9 /procnto-smp-instr 10r RECEIVE 1
1 12 /procnto-smp-instr 10r RECEIVE 1
1 13 /procnto-smp-instr 10r RECEIVE 1
1 14 /procnto-smp-instr 10r RECEIVE 1
1 15 /procnto-smp-instr 10r RECEIVE 1
2 1 sbin/tinit 10o REPLY 1
4099 1 proc/boot/pci-bios 10o RECEIVE 1
4100 1 proc/boot/slogger 10o RECEIVE 1
4102 1 proc/boot/io-hid 10o SIGWAITINFO
4102 2 proc/boot/io-hid 21r RECEIVE 1
4102 3 proc/boot/io-hid 10o RECEIVE 4
4102 4 proc/boot/io-hid 9r RECEIVE 12
4102 5 proc/boot/io-hid 10r DEAD
4102 6 proc/boot/io-hid 10o RECEIVE 4
4103 1 /boot/devc-con-hid 10o RECEIVE 1
4103 2 /boot/devc-con-hid 10o REPLY 4102
8200 1 roc/boot/devb-eide 10o SIGWAITINFO
8200 2 roc/boot/devb-eide 21r RECEIVE 1
8200 3 roc/boot/devb-eide 21r RECEIVE 4
8200 4 roc/boot/devb-eide 10o RECEIVE 10
8200 5 roc/boot/devb-eide 10o RECEIVE 7
8200 7 roc/boot/devb-eide 10o RECEIVE 7
8200 8 roc/boot/devb-eide 21o RECEIVE 7
8200 10 roc/boot/devb-eide 10o RECEIVE 7
8200 11 roc/boot/devb-eide 10o RECEIVE 7
20489 1 sbin/pipe 10o SIGWAITINFO
20489 2 sbin/pipe 10o RECEIVE 1
20489 3 sbin/pipe 10o RECEIVE 1
20489 4 sbin/pipe 10o RECEIVE 1
20489 5 sbin/pipe 10o RECEIVE 1
24586 1 sbin/mqueue 10o RECEIVE 1
57356 1 usr/sbin/random 10o SIGWAITINFO
57356 2 usr/sbin/random 10o RECEIVE 1
57356 3 usr/sbin/random 10o NANOSLEEP
61453 1 sbin/enum-devices 10o REPLY 20489
77840 1 sbin/enum-usb 10o SIGWAITINFO
77840 2 sbin/enum-usb 10r DEAD
110609 1 sbin/io-display 10o SIGWAITINFO
110609 2 sbin/io-display 10o RECEIVE 1
110609 3 sbin/io-display 10o RECEIVE 1
110609 4 sbin/io-display 10o RECEIVE 3
110609 5 sbin/io-display 10o RECEIVE 1
126994 1 sbin/io-pkt-v4-hc 21o SIGWAITINFO
126994 2 sbin/io-pkt-v4-hc 10o RECEIVE 1
126994 3 sbin/io-pkt-v4-hc 21o RECEIVE 16
126994 4 sbin/io-pkt-v4-hc 21o RECEIVE 22
126994 5 sbin/io-pkt-v4-hc 21o CONDVAR (0xb827071c)
126994 6 sbin/io-pkt-v4-hc 20o RECEIVE 27
126994 7 sbin/io-pkt-v4-hc 9o RECEIVE 19
167951 1 sbin/devc-ser8250 10o RECEIVE 1
167958 1 sbin/devc-par 10o RECEIVE 1
167958 2 sbin/devc-par 9r CONDVAR (0x8057eac)
204819 1 sbin/devc-pty 10o RECEIVE 1
217108 1 usr/sbin/dumper 10o RECEIVE 1
229400 1 usr/sbin/inetd 10o SIGWAITINFO
237589 1 usr/sbin/qconn 10o SIGWAITINFO
237589 2 usr/sbin/qconn 10o CONDVAR (0x8067df0)
237589 3 usr/sbin/qconn 10o RECEIVE 1
237589 4 usr/sbin/qconn 10o RECEIVE 3
262167 1 bin/login 10o REPLY 4103
262169 1 bin/login 10o REPLY 4103
262170 1 bin/login 10o REPLY 4103
262171 1 bin/login 10o REPLY 4103
262172 1 usr/sbin/telnetd 10o SIGWAITINFO
266269 1 bin/sh 10o SIGSUSPEND
397317 1 bin/pidin 10o REPLY 1
I wondered why enum-usb was still there so I slayed it
system is still responsive etc.
then I started “gns -c” to start my testing again and the system crashed! no ping response etc.
All right so you are making some progress.
When you slayed io-audio did you check and see if that dropped the CPU usage on io-usb? Maybe io-audio and io-usb share the same PCI bus.
You can probably slay enum-devices too which I suspect spawned enum-usb as part of the plug-n-pray process.
Two things:
Why are you running gns in client mode? Do you have another QNX machine running in server mode? When you run in client mode you are saying there is another QNX machine that is the master server for GNS and that your gns should contact that other QNX machine to get it’s gns information.
I still wonder if what’s happening is a runaway process using 100% of the CPU. Since you are still in console mode, use pidin to determine your sh process id. Then renice it to a very high priority (renice -20 -p processId). Then run pidin again and make sure you got the right sh (your pidin prio will now be 30 instead of 10). Then start gns (from another console that’s running at a lower priority). Hopefully your shell will remain responsive due to its very high priority allowing you to see what the runaway process is.
Tim
I’m using GNS to communicate with another host (the -server),
OK… I waited until io-usb was running at about 45% (one core’s worth), ran another shell with a different priority, then slayed the io-usb process and it didn’t crash this time! now the server appears ok, not sure what’s going, will post back after I’ve managed to kill it with the pidin info. Cheers
the behaviour’s changed slightly,
io-usb runs away, I slay it (from a terminal other than the one I raised priority via nice), I got about two more commands away* (a pidin, and a couple of greps, then I tried top and the terminal hung (no ping response),unfortunately the other ‘niced’ terminal was unresponsive as well thus it looks like a system crash rather than runaway process. So, no luck with that idea.
I do now have a core file for the io-usb.
I’m going to try swapping my server and client gns’s over and see if that makes the other host crash
just started looking at this again…
can anyone shed light on why pci and usb commands report different numbers of USB devices? could this be why enum-usb doesn’t finish?
[code]# usb -v
USB 0 (UHCI) v1.10, v1.01 DDK, v1.01 HCD
Control, Interrupt, Bulk(SG), Isoch(Stream), Low speed, Full speed
USB 1 (UHCI) v1.10, v1.01 DDK, v1.01 HCD
Control, Interrupt, Bulk(SG), Isoch(Stream), Low speed, Full speed
USB 2 (UHCI) v1.10, v1.01 DDK, v1.01 HCD
Control, Interrupt, Bulk(SG), Isoch(Stream), Low speed, Full speed
USB 3 (UHCI) v1.10, v1.01 DDK, v1.01 HCD
Control, Interrupt, Bulk(SG), Isoch(Stream), Low speed, Full speed
USB 4 (UHCI) v1.10, v1.01 DDK, v1.01 HCD
Control, Interrupt, Bulk(SG), Isoch(Stream), Low speed, Full speed
USB 5 (EHCI) v1.10, v1.01 DDK, v1.01 HCD
Control, Interrupt, Bulk(SG), Isoch(Stream), Full speed, High speed
USB 6 (EHCI) v1.10, v1.01 DDK, v1.01 HCD
Control, Interrupt, Bulk(SG), Isoch(Stream), Full speed, High speed
7
Device ID = 2937h, 82801I (ICH9 Family) USB UHCI Controller #4
Device ID = 2938h, 82801I (ICH9 Family) USB UHCI Controller #5
Device ID = 2939h, 82801I (ICH9 Family) USB UHCI Controller #6
Device ID = 293ch, 82801I (ICH9 Family) USB2 EHCI Controller #2
Device ID = 2934h, 82801I (ICH9 Family) USB UHCI Controller #1
Device ID = 2935h, 82801I (ICH9 Family) USB UHCI Controller #2
Device ID = 2936h, 82801I (ICH9 Family) USB UHCI Controller #3
Device ID = 293ah, 82801I (ICH9 Family) USB2 EHCI Controller #1
8
F786461
[/code]
Maybe the USB controller/chipset on your board is not fully supported? Have you checked with QNX support? Have you tried a different hardware? You could also try booting in APIC mode (apic startup and pci-bios-v2) and see if it makes a difference.
I’ve just disabled all USB devices in the bios and my original problem (runaway io-usb process) appears to have gone away but enum-usb still doesn’t appear to complete even though ‘usb’ and ‘pci’ show no usb devices anymore.
[code]# pidin | grep enum-usb
77840 1 sbin/enum-usb 10o SIGWAITINFO
77840 2 sbin/enum-usb 10r REPLY 4101
4101 1 proc/boot/io-usb 10o SIGWAITINFO
4101 2 proc/boot/io-usb 21r RECEIVE 1
4101 3 proc/boot/io-usb 10o RECEIVE 4
4101 4 proc/boot/io-usb 10r NANOSLEEP
4101 5 proc/boot/io-usb 10o RECEIVE 4
4102 5 proc/boot/io-hid 10r REPLY 4101
77840 2 sbin/enum-usb 10r REPLY 4101
[/code]