View topic - io-usb using most of one core's CPU

by **queBurro** » Tue Mar 05, 2013 1:52 pm

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

by **queBurro** » Tue Mar 05, 2013 2:54 pm

bit more detail:

Code: Select all: # top PID TID PRI STATE HH:MM:SS CPU COMMAND 4101 3 21 Run 0:04:43 27.48% io-usb # ps -ef | grep 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

so do I suspect my ps2 mouse and keyboard?

by **Tim** » Tue Mar 05, 2013 5:53 pm

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

by **maschoen** » Tue Mar 05, 2013 8:04 pm

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.

by **queBurro** » Wed Mar 06, 2013 2:43 pm

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

by **Tim** » Wed Mar 06, 2013 6:11 pm

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

by **queBurro** » Thu Mar 07, 2013 10:35 am

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

Code: Select all: # 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

Code: Select all: # 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

by **queBurro** » Thu Mar 07, 2013 10:47 am

I get this as well, I suspect GNS is involved somehow

Code: Select all: # gns -c Another GNS already running # slay gns slay: Unable to find process 'gns' # gns -c Another GNS already running # ps -e | grep gns #

by **Tim** » Thu Mar 07, 2013 6:04 pm

1 1 /procnto-smp-instr 0f READY

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.

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.

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.

61453 1 sbin/enum-devices 10o REPLY 20489
77840 1 sbin/enum-usb 10o SIGWAITINFO
77840 2 sbin/enum-usb 10r REPLY 4101

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

by **queBurro** » Thu Mar 07, 2013 9:13 pm

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.

by **Tim** » Thu Mar 07, 2013 11:08 pm

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.

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?

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

by **queBurro** » Fri Mar 08, 2013 8:24 am

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?

re: Photon, I'll slay that... (didn't stop photon), add the /etc/system/config/nophoton file and reboot and give it another go.
---
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.

by **Tim** » Fri Mar 08, 2013 7:09 pm

queBurro wrote: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?

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).

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.

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

by **queBurro** » Mon Mar 11, 2013 9:26 am

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: Select all: # 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 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

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

Code: Select all: # 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.

by **Tim** » Mon Mar 11, 2013 4:34 pm

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:

1) 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.

2) 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

User login

View topic - io-usb using most of one core's CPU

io-usb using most of one core's CPU

io-usb using most of one core's CPU

Re: io-usb using most of one core's CPU

Re: io-usb using most of one core's CPU

Re: io-usb using most of one core's CPU

Re: io-usb using most of one core's CPU

Re: io-usb using most of one core's CPU

Re: io-usb using most of one core's CPU

Re: io-usb using most of one core's CPU

Re: io-usb using most of one core's CPU

Re: io-usb using most of one core's CPU

Re: io-usb using most of one core's CPU

Re: io-usb using most of one core's CPU

Re: io-usb using most of one core's CPU

Re: io-usb using most of one core's CPU

Re: io-usb using most of one core's CPU

Who is online