M. Koehrer wrote: > Hi everybody! > > I have detected a strange issue that occurrs occassionly with the rt_eepro100 > driver, but I have never > seen it with the rt_e1000 driver: > I have an embedded device that sends data to my rtnet/RTAI-3.3-cv PC via UDP. > The data comes in periodically (Period is 1ms) , it consists of one big UDP > message (1472 byte data), > followed directly by a fairly small one (80 byte data). > I confirm the reception by sending back a UDP message to the embedded device, > then the embedded > device may send the next message. > Now the strange thing is, that occassionaly (about every 5-10 minutes, i.e. > every 300000 - 600000 times), the signaling of the second UDP message on > rtnet gets somehow lost. > I read the first message with a rt_dev_recv() on a socket that has a fairly > long timeout (some seconds), > then I switch down the timeout to a short timeout (1ms) and wait for the > second message > (again with rt_dev_recv). This second read faily occassionally (see above) > with a timeout. > However, when I ignore this timeout and the missing message and send the > confirmation message > to the embedded device, it will continue to send. > The issue is now, that the next rt_dev_recv() returns exactly the message I > was waiting for before. > I.e. I can now read the missing 80 byte message, the new 1472 byte message > and the new 80 byte message. > This looks as if the signaling of the message reception fails occassionally. > All the rt_dev_recv() calls are done from a kernel module. > > I did the same test using the rt_e1000 but not the rt_eepro100. With the > rt_e1000 I never saw this issue, > thus I assume it has somehow to do with the driver. > > I ran the tests with RTNET 0.9.4 and 0.9.6 - there was no difference. > I am using a Intel Pentium 4, UP, kernel-2.4.33, rtai-3.3-cv. > > Any ideas or help on this issue are highly welcome!
First, I would try to find out the state of interesting kernel objects when you detect the error. That would be the content of the rx.fifo (stack manager), STACK_manager.event, <your_socket>.incoming, <your_socket>.pending_sem. If this gives no clue yet, I would suggest to install kernel 2.6 (at least for testing purpose) together with the I-pipe tracer [1, 2] and then put an ipipe_trace_freeze at that point when you detect the timeout. That will give you a picture of the past invoked kernel functions of the last few micro- to milliseconds. Some usage help on the tracer is currently being collected here [3]. Alternatively, you could try to invent some other tracing mechanism to grab the information what was called before that event, e.g. if rt_eepro100 correctly invoked rt_mark_stack_mgr. Simply putting printk there is very likely not appropriate. Jan [1]http://download.gna.org/adeos/patches/v2.6/i386/adeos-ipipe-2.6.17-i386-1.5-00.patch [2]http://download.gna.org/adeos/patches/v2.6/i386/tracer/ [3]http://www.xenomai.org/wiki/index.php/Xenomai:I-pipe_Tracer
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________ RTnet-users mailing list RTnet-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rtnet-users
