It could be worthwhile getting a kernel trace to see if anything is interacting with the stack.  You could also build a 
debug version of the stack and debug it using io-net as a second stack instance for gdb to connect in to.
Are you using a milestone build or your own build?

In terms of the OS, it shouldn't matter, but it would be worth trying the released 6.3.2 kernel and libs to make sure.  


  Robert

----- Original Message -----
From: Christopher Pohl <community-noreply@qnx.com>
To: ionetmig-networking <post11181@community.qnx.com>
Sent: Tue Jul 29 04:56:40 2008
Subject: Re: RE: io-pkt-v4-hc idle CPU load

> 
> From: Christopher Pohl 
> 
> > It happens immediately after firing up io-pkt 
> 
> All I can think of is interrupts firing for some
> other device which is sharing the interrupt ...

After more experimenting it turns out the mpc85xx driver got nothing to do with it. 

To reproduce, it is sufficient to fire up io-pkt-v4-(hc) without a NIC driver like this 

# io-pkt-v4-hc
# hogs -n -%1
PID             NAME  MSEC  PIDS SYSTEM
1                     2645   87%    88%
864265  io-pkt-v4-hc   357   11%    11%

I don't know if this is relevant, but if i launch an second instance, only the last started instance of io-pkt-v4 hogs 
the CPU (notice the change of the PID in hogs) while the one that was started first goes really idle. 

# io-pkt-v4-hc
# hogs -n -%1
PID             NAME  MSEC  PIDS SYSTEM
1                     2646   87%    88%
876554  io-pkt-v4-hc   357   11%    11%

1                     2644   87%    88%
876554  io-pkt-v4-hc   357   11%    11%

Also, I tried this on a MPC8313 board with very similar software and a binary identical io-pkt. I cannot reproduce the 
behaviour on the MPC8313 board. 

Here is the PVR & SVR of the affected MPC8548: 

CHIP REVISIONS
 CPU Version (PVR): Major 0x8021 Minor 0x20
 System version   (SVR): Major 0x8039 Minor 0x20

Maybe this also makes a difference: The MPC8548 board has an engineering kernel (CE WO790369). Would it make sense to 
try a regular kernel? If so which one would you prefer? 

Can you think of anything else I can do (e.g. verbose logs of io-pkt-v4-hc itself) ? 

Thanks,
Christopher

_______________________________________________
io-net migration
http://community.qnx.com/sf/go/post11181

On Tue, Jul 29, 2008 at 04:56:41AM -0400, Christopher Pohl wrote:
> > 
> > From: Christopher Pohl 
> > 
> > > It happens immediately after firing up io-pkt 
> > 
> > All I can think of is interrupts firing for some
> > other device which is sharing the interrupt ...
> 
> After more experimenting it turns out the mpc85xx driver got nothing to do with it. 
> 
> To reproduce, it is sufficient to fire up io-pkt-v4-(hc) without a NIC driver like this 
> 
> # io-pkt-v4-hc
> # hogs -n -%1
> PID             NAME  MSEC  PIDS SYSTEM
> 1                     2645   87%    88%
> 864265  io-pkt-v4-hc   357   11%    11%
> 
> I don't know if this is relevant, but if i launch an second instance, only the last started instance of io-pkt-v4 hogs
 the CPU (notice the change of the PID in hogs) while the one that was started first goes really idle. 
> 
> # io-pkt-v4-hc
> # hogs -n -%1
> PID             NAME  MSEC  PIDS SYSTEM
> 1                     2646   87%    88%
> 876554  io-pkt-v4-hc   357   11%    11%
> 
> 1                     2644   87%    88%
> 876554  io-pkt-v4-hc   357   11%    11%
> 
> Also, I tried this on a MPC8313 board with very similar software and a binary identical io-pkt. I cannot reproduce the
 behaviour on the MPC8313 board. 
> 
> Here is the PVR & SVR of the affected MPC8548: 
> 
> CHIP REVISIONS
>  CPU Version (PVR): Major 0x8021 Minor 0x20
>  System version   (SVR): Major 0x8039 Minor 0x20
> 
> Maybe this also makes a difference: The MPC8548 board has an engineering kernel (CE WO790369). Would it make sense to 
try a regular kernel? If so which one would you prefer? 
> 
> Can you think of anything else I can do (e.g. verbose logs of io-pkt-v4-hc itself) ? 

The only thing the stack should be doing when started with
no drivers is handling periodic timer pulses.  Are you sure
the clock is running at the proper frequency on that board
(although starting a second instance should have no effect
if that were an issue...).

Note that starting a second instance will have the last one
overlay /dev/socket so that one will now receive messages
from socket() and friends instead of the first so there may
be some client using socket services.

-seanb

From: Christopher Pohl [mailto:community-noreply@qnx.com] 

> the mpc85xx driver got nothing to do with it. 
> sufficient to fire up io-pkt-v4-(hc) without a NIC driver 

Some ideas:

1) run the instrumented kernel to find out what the heck
is going on.  Is it a periodic timer that is waking io-pkt
up, or is it a message from a client?
 
2) create a core file of io-pkt using "dumper -p <pid>".
This does NOT slay io-pkt, just makes a snapshot core
file which you can examine with gdb and backtrace the
threads.  Note that you may have to do this several times
(possibly at a high priority with "on -p 255 sh" to avoid
being pre-empted).

3) if #1 and #2 above don't work, slogf is your friend.
Compile debug versions of io-pkt, sprinkling slogf calls
around, until you can figure out what code path it is
executing so frequently.  This is usually an iterative
process, but rarely does it affect the timing enough to
alter the behaviour.

--
aboyd