Can you make a tar file with your:

 io-pkt binary
 io-pkt core files
 .so files (mpc85xx, libc, etc - see pidin mem for io-pkt)

after a crash?  You will need to run dumper on the 8548,
then restart the stack (without the funky options) to
ftp the core file off the 8548.

io-pkt should not crash, or run ready.

--
aboyd


-----Original Message-----
From: Guenther Weiss [mailto:community-noreply@qnx.com] 
Sent: Thursday, August 07, 2008 9:04 AM
To: technology-networking
Subject: io-pkt crash on MPC8548 with two interfaces and prioritized RX
path

We use io-pkt (Milestone 3) with QNX 6.3.2 Kernel on a MPC8548 board
with two network interfaces. We run one stack instance for both
interfaces because later a layer 2 bridge is needed (not operational for
this testcase). On tsec1 we want to receive and send UDP frames with low
latency and do layer 2 bridging to and from tsec0. Especially the
latency should not be influenced by "normal" traffic on tsec0. Because
the stack is single threaded internally, we use the BPF (pcap library)
to capture and send the UDP frames on tsec1. In our testcase a PC sends
UDP frame and our MPC8548 board (tsec1) loops it back with the attached
test program. The PC sends the next UDP frame (128 bytes UDP data)
immediately after receipt of the response.

In this setup, io-pkt either terminates after a few frames with blown
stack handling 0 or hangs with high CPU load (only restricted by the
Adaptive Partitioning). Increasing the stacksize didn't help.

The stack is started with the following options:

io-pkt-v4-hc -t4 -dmpc85xx mac=xxx,pci=0,phy=0 -ptcpip

mount -Tio-pkt -o mac=yyy,pci=1,phy=1,rx_delay=0,rx_frame=0,
priority=185 /lib/dll/devnp-mpc85xx.so

ifconfig tsec0 up
ifconfig tsec1 192.168.44.2 up

I have made the following observations:

1.) It works, if the -t4 option is omitted. But then the interrupt
received thread is running on default priority -> no solution because of
jitter

2.) It works, if only tsec1 is configured and used. It is not sufficient
to have no network cable connected to a configured tsec0 -> no solution
- both interfaces are needed

3.) It works, if the UDP frames are received and sent via the socket
interface (#define VIA_SOCKET in the test program) and not over
pcap_loop() and pcap_inject() -> no solution because of jitter when the
single threaded stack is occupied by traffic from tsec0


Am I doing something wrong or is this a bug in io-pkt, the pcap library
or the network driver ?

Thanks,
    Guenther



_______________________________________________
Technology
http://community.qnx.com/sf/go/post11522

Hi Guenther:
	It certainly sounds like a bug of some sort.  The blown stack
may be why the pcap stuff isn't working.

Lets start with the easy one first.  Can you try using a "-p tcpip
rx_pulse_prio=185" instead of the per driver priority option?  I believe
that the per driver "priority" option should work, but this should be an
alternative which is applied to all driver threads.

	Robert.

-----Original Message-----
From: Guenther Weiss [mailto:community-noreply@qnx.com] 
Sent: Thursday, August 07, 2008 9:04 AM
To: technology-networking
Subject: io-pkt crash on MPC8548 with two interfaces and prioritized RX
path

We use io-pkt (Milestone 3) with QNX 6.3.2 Kernel on a MPC8548 board
with two network interfaces. We run one stack instance for both
interfaces because later a layer 2 bridge is needed (not operational for
this testcase). On tsec1 we want to receive and send UDP frames with low
latency and do layer 2 bridging to and from tsec0. Especially the
latency should not be influenced by "normal" traffic on tsec0. Because
the stack is single threaded internally, we use the BPF (pcap library)
to capture and send the UDP frames on tsec1. In our testcase a PC sends
UDP frame and our MPC8548 board (tsec1) loops it back with the attached
test program. The PC sends the next UDP frame (128 bytes UDP data)
immediately after receipt of the response.

In this setup, io-pkt either terminates after a few frames with blown
stack handling 0 or hangs with high CPU load (only restricted by the
Adaptive Partitioning). Increasing the stacksize didn't help.

The stack is started with the following options:

io-pkt-v4-hc -t4 -dmpc85xx mac=xxx,pci=0,phy=0 -ptcpip

mount -Tio-pkt -o mac=yyy,pci=1,phy=1,rx_delay=0,rx_frame=0,
priority=185 /lib/dll/devnp-mpc85xx.so

ifconfig tsec0 up
ifconfig tsec1 192.168.44.2 up

I have made the following observations:

1.) It works, if the -t4 option is omitted. But then the interrupt
received thread is running on default priority -> no solution because of
jitter

2.) It works, if only tsec1 is configured and used. It is not sufficient
to have no network cable connected to a configured tsec0 -> no solution
- both interfaces are needed

3.) It works, if the UDP frames are received and sent via the socket
interface (#define VIA_SOCKET in the test program) and not over
pcap_loop() and pcap_inject() -> no solution because of jitter when the
single threaded stack is occupied by traffic from tsec0


Am I doing something wrong or is this a bug in io-pkt, the pcap library
or the network driver ?

Thanks,
    Guenther



_______________________________________________
Technology
http://community.qnx.com/sf/go/post11522

Hi Guenther:
	Something else to check out with regards to the blown stack.
Are you using the most recent source for the mpc85xx driver?

If you look at the checkins for detect.c, you'll see Rev 445 which was a
change to specifically address a stack issue.

	Robert.

-----Original Message-----
From: Guenther Weiss [mailto:community-noreply@qnx.com] 
Sent: Thursday, August 07, 2008 9:04 AM
To: technology-networking
Subject: io-pkt crash on MPC8548 with two interfaces and prioritized RX
path

We use io-pkt (Milestone 3) with QNX 6.3.2 Kernel on a MPC8548 board
with two network interfaces. We run one stack instance for both
interfaces because later a layer 2 bridge is needed (not operational for
this testcase). On tsec1 we want to receive and send UDP frames with low
latency and do layer 2 bridging to and from tsec0. Especially the
latency should not be influenced by "normal" traffic on tsec0. Because
the stack is single threaded internally, we use the BPF (pcap library)
to capture and send the UDP frames on tsec1. In our testcase a PC sends
UDP frame and our MPC8548 board (tsec1) loops it back with the attached
test program. The PC sends the next UDP frame (128 bytes UDP data)
immediately after receipt of the response.

In this setup, io-pkt either terminates after a few frames with blown
stack handling 0 or hangs with high CPU load (only restricted by the
Adaptive Partitioning). Increasing the stacksize didn't help.

The stack is started with the following options:

io-pkt-v4-hc -t4 -dmpc85xx mac=xxx,pci=0,phy=0 -ptcpip

mount -Tio-pkt -o mac=yyy,pci=1,phy=1,rx_delay=0,rx_frame=0,
priority=185 /lib/dll/devnp-mpc85xx.so

ifconfig tsec0 up
ifconfig tsec1 192.168.44.2 up

I have made the following observations:

1.) It works, if the -t4 option is omitted. But then the interrupt
received thread is running on default priority -> no solution because of
jitter

2.) It works, if only tsec1 is configured and used. It is not sufficient
to have no network cable connected to a configured tsec0 -> no solution
- both interfaces are needed

3.) It works, if the UDP frames are received and sent via the socket
interface (#define VIA_SOCKET in the test program) and not over
pcap_loop() and pcap_inject() -> no solution because of jitter when the
single threaded stack is occupied by traffic from tsec0


Am I doing something wrong or is this a bug in io-pkt, the pcap library
or the network driver ?

Thanks,
    Guenther



_______________________________________________
Technology
http://community.qnx.com/sf/go/post11522