Good Morning,

Have you tried running the script which I used?

Running the command a couple of times 3..5 times does not show the effect.
10-20times or using the script it will be visible within a minute.

I will definitely try to use the tracelog and send the output to you all.

Thanks for the help so far.

Thomas Lützel

> Am 22.11.2016 um 17:37 schrieb Hugh Brown <community-noreply@qnx.com>:
>
> Here is the output from my x86 PC running just io-pkt-v4-hc. I also ran
df
> -h several times as well, with no difference to the output.
>
> (root) /usr/qnx650/target/qnx6/x86/sbin-> pidin -pio-pkt-v4-hc mem
>     pid tid name               prio STATE            code  data
> stack
> 127537170   1 ./io-pkt-v4-hc      21r SIGWAITINFO      948K  344K
> 4096(516K)*
> 127537170   2 ./io-pkt-v4-hc      21r RECEIVE          948K  344K
> 8192(132K)
>            libc.so.3          @b0300000             488K   16K
> (root) /usr/qnx650/target/qnx6/x86/sbin-> pidin -pio-pkt-v4-hc mem
>     pid tid name               prio STATE            code  data
> stack
> 127537170   1 ./io-pkt-v4-hc      21r SIGWAITINFO      948K  344K
> 4096(516K)*
> 127537170   2 ./io-pkt-v4-hc      10r RECEIVE          948K  344K
> 8192(132K)
>            libc.so.3          @b0300000             488K   16K
> (root) /usr/qnx650/target/qnx6/x86/sbin-> pidin -pio-pkt-v4-hc mem
>     pid tid name               prio STATE            code  data
> stack
> 127537170   1 ./io-pkt-v4-hc      21r SIGWAITINFO      948K  344K
> 4096(516K)*
> 127537170   2 ./io-pkt-v4-hc      21r RECEIVE          948K  344K
> 8192(132K)
>            libc.so.3          @b0300000             488K   16K
> (root) /usr/qnx650/target/qnx6/x86/sbin-> pidin -pio-pkt-v4-hc mem
>     pid tid name               prio STATE            code  data
> stack
> 127537170   1 ./io-pkt-v4-hc      21r SIGWAITINFO      948K  344K
> 4096(516K)*
> 127537170   2 ./io-pkt-v4-hc      21r RECEIVE          948K  344K
> 8192(132K)
>            libc.so.3          @b0300000             488K   16K
> (root) /usr/qnx650/target/qnx6/x86/sbin-> pidin -pio-pkt-v4-hc mem
>     pid tid name               prio STATE            code  data
> stack
> 127537170   1 ./io-pkt-v4-hc      21r SIGWAITINFO      948K  344K
> 4096(516K)*
> 127537170   2 ./io-pkt-v4-hc      21r RECEIVE          948K  344K
> 8192(132K)
>            libc.so.3          @b0300000             488K   16K
> (root) /usr/qnx650/target/qnx6/x86/sbin-> pidin -pio-pkt-v4-hc mem
>     pid tid name               prio STATE            code  data
> stack
> 127537170   1 ./io-pkt-v4-hc      21r SIGWAITINFO      948K  344K
> 4096(516K)*
> 127537170   2 ./io-pkt-v4-hc      21r RECEIVE          948K  344K
> 8192(132K)
>            libc.so.3          @b0300000             488K   16K
>
>
> NAME=io-pkt-v4-hc
> DESCRIPTION=TCP/IP protocol module.
> DATE=2012/06/20-13:36:58-EDT
> STATE=stable
> HOST=gusbuild4
> USER=builder
> VERSION=6.5.0
> TAGID=650SP1-166
>
>
>
>
> On 2016-11-22, 10:47 AM, "Thomas Luetzel" <community-noreply@qnx.com>
> wrote:
>
>> see attached screen shot
>>
>>
>>
>> _______________________________________________
>>
>> Networking Drivers
>> http://community.qnx.com/sf/go/post117168
>> To cancel your subscription to this discussion, please e-mail
>> drivers-networking-unsubscribe@community.qnx.com
>
>
>
>
>
> _______________________________________________
>
> Networking Drivers
> http://community.qnx.com/sf/go/post117172
> To cancel your subscription to this discussion, please...

The fact that running df causes io-pkt to increase its data size is
besides the point. If the data size is increasing when running your
network driver, this points to a problem with the network driver, as I
have tested the 6.5.0 SP1 io-pkt and the data size doesn¹t increase with
usage of other network drivers.
We don¹t have your hardware or your BSP, so there is no way we can look at
this without having these resources. I suggest that you contact your sales
rep to set the wheels in motion to get this problem resolved.

On 2016-11-22, 10:47 AM, "Thomas Luetzel" <community-noreply@qnx.com>
wrote:


>see attached screen shot
>
>
>
>_______________________________________________
>
>Networking Drivers
>http://community.qnx.com/sf/go/post117168
>To cancel your subscription to this discussion, please e-mail
>drivers-networking-unsubscribe@community.qnx.com

Just a though.  Is the VM connected to a network ?  Could it be related to network traffic.

-----Message d'origine-----
De : Dennis Kellly [mailto:community-noreply@qnx.com] 
Envoyé : 22 novembre 2016 10:46
À : drivers-networking <drivers-networking@community.qnx.com>
Objet : Re: io-pkt leak data section - ppc8260 ethernet driver

What is your "df" output?  I  can't see any relationship of df to network UNLESS there is a sharepoint mounted...



_______________________________________________

Networking Drivers
http://community.qnx.com/sf/go/post117167
To cancel your subscription to this discussion, please e-mail drivers-networking-unsubscribe@community.qnx.com

Hi, yes the VM is connected to the a network but if the VM is running without the shell script

run.sh
===============
while [ 0 -lt 1 ]
do
   df >> /dev/null
done

the memory increases very fast!

To the answer to Hugh - I am not running any BSP on a target hardware! I can reproduce this issue on a VM provided from 
the QNX homepage. My DUT (device under test) is delivered now from QNX, nothing implemented installed done from my side!


Attched you will also find the timeline tracelog. I've marked a REPLY BLOCED from io-pkt by the df procress. This 
happens multiple times.

Anything else what I can do to generate log which will help to isolate this behaviour.

Thanks in advance

Even more trace logs where I can see io-pkt receives messages from the df command.

Thanks for help and suggestions
Kind Regards
Thomas

df goes and hunts around in /proc/mount to find the disks that are mounted. io-pkt will have an entry there to enable "
mount -T io-pkt" to mount lsms and drivers, hence the messages that go to it when running df.

We have checked and we only see this memory growth in the initial released 6.5.0 SP1, the latest PSP of io-pkt doesn't 
leak like this.

Good morning,

what do you mean with the latest PSP? Is it the version of QNX 6.6.0?

I knwo the df command running in a loop is not a normal situation but it was a very fast way to reprocude the issue. The
 same issue is happening in our application but much more slowly, with the effect that after a couple of months systems 
performing a reset installed at customer sites - crititcal!

Either I get the latest io-pkt for QNX 6.5 ppcbe or I know which function calls cearting this issue in df, so I can hunt
 in my application for similar calls to avoid them and implement a work around.

Help is always welcome

Kind Regards
Thomas

> df goes and hunts around in /proc/mount to find the disks that are mounted. io
> -pkt will have an entry there to enable "mount -T io-pkt" to mount lsms and 
> drivers, hence the messages that go to it when running df.
> 
> We have checked and we only see this memory growth in the initial released 6.5
> .0 SP1, the latest PSP of io-pkt doesn't leak like this.

A PSP is a Priority Support Patch, these are released after the major OS 
releases to correct any issues that may be found. You are running the 
original io-pkt that was released with 6.5.0SP1, if you move to the 
latest available PSP for io-pkt on 6.5.0SP1 you shouldn't have this 
issue with df. You will need to contact your QNX sales representative to 
obtain this.

As I mentioned, df is heavily accessing /proc/mount doing opendir(), 
readdir(), stat(), open() etc in the /proc/mount directory. io-pkt has 
an entry in the /proc/mount directory. Does your application access 
/proc/mount?

Regards,
Nick

On 16-11-24 03:13 AM, Thomas Luetzel wrote:
> Good morning,
>
> what do you mean with the latest PSP? Is it the version of QNX 6.6.0?
>
> I knwo the df command running in a loop is not a normal situation but it was a very fast way to reprocude the issue. 
The same issue is happening in our application but much more slowly, with the effect that after a couple of months 
systems performing a reset installed at customer sites - crititcal!
>
> Either I get the latest io-pkt for QNX 6.5 ppcbe or I know which function calls cearting this issue in df, so I can 
hunt in my application for similar calls to avoid them and implement a work around.
>
> Help is always welcome
>
> Kind Regards
> Thomas
>
>> df goes and hunts around in /proc/mount to find the disks that are mounted. io
>> -pkt will have an entry there to enable "mount -T io-pkt" to mount lsms and
>> drivers, hence the messages that go to it when running df.
>>
>> We have checked and we only see this memory growth in the initial released 6.5
>> .0 SP1, the latest PSP of io-pkt doesn't leak like this.
>
>
>
>
>
>
> _______________________________________________
>
> Networking Drivers
> http://community.qnx.com/sf/go/post117206
> To cancel your subscription to this discussion, please e-mail drivers-networking-unsubscribe@community.qnx.com
>

Hi,

yes our application is doing this (once in a while) but not to as you described like df. That is the reason it does take
 several month until no RAM is left and the system is performing a reboot.

df was just a way to reproduce it very fast. I'm in contact with the sales rep. and parallel I can go through the 
application to hunt for stat(), opendir(), readdir(), open().

Thanks

> A PSP is a Priority Support Patch, these are released after the major OS 
> releases to correct any issues that may be found. You are running the 
> original io-pkt that was released with 6.5.0SP1, if you move to the 
> latest available PSP for io-pkt on 6.5.0SP1 you shouldn't have this 
> issue with df. You will need to contact your QNX sales representative to 
> obtain this.
> 
> As I mentioned, df is heavily accessing /proc/mount doing opendir(), 
> readdir(), stat(), open() etc in the /proc/mount directory. io-pkt has 
> an entry in the /proc/mount directory. Does your application access 
> /proc/mount?
> 
> Regards,
> Nick
> 
> On 16-11-24 03:13 AM, Thomas Luetzel wrote:
> > Good morning,
> >
> > what do you mean with the latest PSP? Is it the version of QNX 6.6.0?
> >
> > I knwo the df command running in a loop is not a normal situation but it was
>  a very fast way to reprocude the issue. The same issue is happening in our 
> application but much more slowly, with the effect that after a couple of 
> months systems performing a reset installed at customer sites - crititcal!
> >
> > Either I get the latest io-pkt for QNX 6.5 ppcbe or I know which function 
> calls cearting this issue in df, so I can hunt in my application for similar 
> calls to avoid them and implement a work around.
> >
> > Help is always welcome
> >
> > Kind Regards
> > Thomas
> >
> >> df goes and hunts around in /proc/mount to find the disks that are mounted.
>  io
> >> -pkt will have an entry there to enable "mount -T io-pkt" to mount lsms and
> 
> >> drivers, hence the messages that go to it when running df.
> >>
> >> We have checked and we only see this memory growth in the initial released 
> 6.5
> >> .0 SP1, the latest PSP of io-pkt doesn't leak like this.
> >
> >
> >
> >
> >
> >
> > _______________________________________________
> >
> > Networking Drivers
> > http://community.qnx.com/sf/go/post117206
> > To cancel your subscription to this discussion, please e-mail drivers-
> networking-unsubscribe@community.qnx.com
> >