Networking/Discussion/Networking Drivers/Iopkt driver stops reading after six packets/List of Posts
 
Forum Topic - Iopkt driver stops reading after six packets:
   
Update
A Gagne(deleted)
03/23/2009 11:16 AM
post25021
Iopkt driver stops reading after six packets   
I need to write a simple native io-pkt driver. I started with the sample driver code that QNX posted and added a few 
lines of code to display the messages coming in. This seemed to work okay. The data displayed looks correct, but after 
reading six packets, it seems sam_start() stops being called. Do I need to do anything other than m_freem to free the 
mbufs and NW_SIGUNLOCK_P, to let the driver know I am finished with a packet so the driver can keep receiving more? At 
the moment all I want to do is see all the packets. I will worry about what I want to do with them later.

I attached the sample driver code with the changes I made to do this test.

The test was done on a Yosemite evaluation board with a 440EP processor.

I am mounting the driver with 

mount -Tio-pkt devnp-sample.so

and then setting the ip address with

ifconfig sam0 xxx.xxx.xxx.xxx

at which point it displays six packets and stops.

Thanks

A G
Attachment: Compressed file iopkt-sample.zip 8.61 KB
Sean Boudreau(deleted)
03/23/2009 1:09 PM
post25035
Re: Iopkt driver stops reading after six packets   
On Mon, Mar 23, 2009 at 11:16:27AM -0400, A Gagne wrote:
> I need to write a simple native io-pkt driver. I started with the sample driver code that QNX posted and added a few 
lines of code to display the messages coming in. This seemed to work okay. The data displayed looks correct, but after 
reading six packets, it seems sam_start() stops being called. Do I need to do anything other than m_freem to free the 
mbufs and NW_SIGUNLOCK_P, to let the driver know I am finished with a packet so the driver can keep receiving more? At 
the moment all I want to do is see all the packets. I will worry about what I want to do with them later.
> 
> I attached the sample driver code with the changes I made to do this test.

I think 'm' below should be 'm2' but it probably wouldn't cause this
issue.

//Copy the fragment into the transmit buffer
      memcpy((sam->sc_pkt_buf)+len, m->m_data, m->m_len);
      len+=m2->m_len; //Move the pointer to then end of the data in the buffer


> 
> The test was done on a Yosemite evaluation board with a 440EP processor.
> 
> I am mounting the driver with 
> 
> mount -Tio-pkt devnp-sample.so
> 
> and then setting the ip address with
> 
> ifconfig sam0 xxx.xxx.xxx.xxx
> 
> at which point it displays six packets and stops.

I don't see anything obvious.  Is the stack still responding
in general (localhost)?  Does the debugger show anything?

-seanb
A Gagne(deleted)
03/23/2009 2:31 PM
post25040
Re: Iopkt driver stops reading after six packets   
> I think 'm' below should be 'm2' but it probably wouldn't cause this
> issue.
> 
> //Copy the fragment into the transmit buffer
>       memcpy((sam->sc_pkt_buf)+len, m->m_data, m->m_len);
>       len+=m2->m_len; //Move the pointer to then end of the data in the buffer

You were right about that, I went through a few different iterations trying to track this down and that got lost in the 
shuffle when I tried to create a test case with the sample driver to demonstrate the problem.

> 
> I don't see anything obvious.  Is the stack still responding
> in general (localhost)?  Does the debugger show anything?
> 
> -seanb

Pidin shows the same info before and after the mount
  364560   1 /boot/io-pkt-v6-hc  21r SIGWAITINFO
  364560   2 /boot/io-pkt-v6-hc  21r READY
  364560   3 /boot/io-pkt-v6-hc  21r RECEIVE     16
  364560   4 /boot/io-pkt-v6-hc  21r RECEIVE     20

The stack is still responding. If I have a telnet client connected while this is going on, it never stops working. 

I did notice though, if I have an ftp client connected when I mount the sample driver, the ftp session will disconnect 
after doing the mount. This even happens with the original sample driver code with no changes made to it whatsoever.

I can reconnect the ftp client, but after reconnecting, if I try to transfer a file, the transfer will fail, and the 
client will disconnect again.

If I do an ifconfig sam0 destroy, I can transfer files with the ftp client again.

It seems this depends too, in whether or not data transfers have taken place. If the ftp client is just connected but I 
haven't transferred anything, the connection doesn't get broken. I can move around, do directory listings, etc.. with no
 issues.

Even while the ftp client is having these issues, the telnet client has no problems at all. 

Since you have verified I am not leaving anything out, I will try the debugger next to see if it will reveal any 
additional information.

AG
A Gagne(deleted)
03/24/2009 9:36 AM
post25097
Re: Iopkt driver stops reading after six packets   
> I did notice though, if I have an ftp client connected when I mount the sample
>  driver, the ftp session will disconnect after doing the mount. This even 
> happens with the original sample driver code with no changes made to it 
> whatsoever.
> 
> I can reconnect the ftp client, but after reconnecting, if I try to transfer a
>  file, the transfer will fail, and the client will disconnect again.
> 
> If I do an ifconfig sam0 destroy, I can transfer files with the ftp client 
> again.

I thought I would mention too that this isn't particularly repeatable. Sometimes the ftp session will stop responding 
right away, sometimes it will keep working for awhile before it drops out. Sooner or later though, after loading the 
sample driver, the ftp connection will always drop out. I don't understand why it doesn't always do it the same way each
 time, but then again, I don't understand why loading the sample driver would affect the ftp session at all, but it 
definitely does.

AG
A Gagne(deleted)
03/25/2009 6:27 PM
post25264
Re: Iopkt driver stops reading after six packets   
> > I don't see anything obvious.  Is the stack still responding
> > in general (localhost)?  Does the debugger show anything?
> > 
> > -seanb

More info

I wanted to see if the same behavior would occur on a different system. I wanted to take my environment, my image, my 
hardware, out of the equation. To do this, I ran QNX in a QEMU virtual environment by directly booting the ISO image 
qnxsdp-6.4.0-200810211530-nto.iso obtained from QNX.

After fixing the m2 error you mentioned, I compiled the same sample code attached at the beginning of this thread for 
x86. I then transferred it to the virtual qnx environment running in Qemu. When I loaded the driver it ran, displayed 
the 6 packets, and then it doesn't display any more.
Sean Boudreau(deleted)
03/26/2009 1:23 PM
post25378
Re: Iopkt driver stops reading after six packets   
On Wed, Mar 25, 2009 at 06:28:02PM -0400, A Gagne wrote:
> > > I don't see anything obvious.  Is the stack still responding
> > > in general (localhost)?  Does the debugger show anything?
> > > 
> > > -seanb
> 
> More info
> 
> I wanted to see if the same behavior would occur on a different system. I wanted to take my environment, my image, my 
hardware, out of the equation. To do this, I ran QNX in a QEMU virtual environment by directly booting the ISO image 
qnxsdp-6.4.0-200810211530-nto.iso obtained from QNX.
> 
> After fixing the m2 error you mentioned, I compiled the same sample code attached at the beginning of this thread for 
x86. I then transferred it to the virtual qnx environment running in Qemu. When I loaded the driver it ran, displayed 
the 6 packets, and then it doesn't display any more.

I tried your version with the m2 fix and it seem to work fine for me.
What does a pidin show when it's stalled?

-seamb
A Gagne(deleted)
04/02/2009 2:21 PM
post25908
Re: Iopkt driver stops reading after six packets   
I didn't have something configured properly. It is working for me as well now. Thank you for your help.
A Gagne(deleted)
03/25/2009 3:11 PM
post25238
Re: Iopkt driver stops reading after six packets   
> I don't see anything obvious.  Is the stack still responding
> in general (localhost)?  Does the debugger show anything?
> 
> -seanb

Would it be safe to make the assumption that if you compile and run this exact same sample driver that you don't see it 
stop after reading six packets? You see it continually displaying packets to stdout. If this is true, it seems I should 
be looking at something other than the driver code to identify the problem.

AG

Return