Skip navigation.
Home
The QNX Community Portal

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

io-usb using most of one core's CPU

For discussion of realtime and/or embedded programming.

io-usb using most of one core's CPU

Postby 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
queBurro
Active Member
 
Posts: 79
Joined: Fri Jul 30, 2010 2:05 pm

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

Postby 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?
queBurro
Active Member
 
Posts: 79
Joined: Fri Jul 30, 2010 2:05 pm

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

Postby 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
Tim
Senior Member
 
Posts: 1173
Joined: Wed Mar 10, 2004 12:28 am

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

Postby 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.
maschoen
QNX Master
 
Posts: 2459
Joined: Wed Jun 25, 2003 5:18 pm

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

Postby 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
queBurro
Active Member
 
Posts: 79
Joined: Fri Jul 30, 2010 2:05 pm

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

Postby 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
Tim
Senior Member
 
Posts: 1173
Joined: Wed Mar 10, 2004 12:28 am

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

Postby 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
queBurro
Active Member
 
Posts: 79
Joined: Fri Jul 30, 2010 2:05 pm

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

Postby 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
#
queBurro
Active Member
 
Posts: 79
Joined: Fri Jul 30, 2010 2:05 pm

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

Postby 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
Tim
Senior Member
 
Posts: 1173
Joined: Wed Mar 10, 2004 12:28 am

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

Postby 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.
queBurro
Active Member
 
Posts: 79
Joined: Fri Jul 30, 2010 2:05 pm

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

Postby 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
Tim
Senior Member
 
Posts: 1173
Joined: Wed Mar 10, 2004 12:28 am

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

Postby 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.
queBurro
Active Member
 
Posts: 79
Joined: Fri Jul 30, 2010 2:05 pm

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

Postby 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
Tim
Senior Member
 
Posts: 1173
Joined: Wed Mar 10, 2004 12:28 am

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

Postby 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.
queBurro
Active Member
 
Posts: 79
Joined: Fri Jul 30, 2010 2:05 pm

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

Postby 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
Tim
Senior Member
 
Posts: 1173
Joined: Wed Mar 10, 2004 12:28 am

Next

Return to Realtime and Embedded

Who is online

Users browsing this forum: No registered users and 2 guests