Hi Jan,
thanks for your response.
I have printed out the state of the STACK_manger.event and the rx.fifo in the
situation that
I have a missing signaling.
The result is the following:
STACK_manager.event.pending is 0,
STACK_manager.event.synch_base.count is -1,
rx.fifo.read_pos == rx.fifo.write_pos.
I think this is fine. No data waiting in the rx fifo. Thus, the message seems
to be still in the driver.
My assumption is now that there could be an issue with the rt_eepro100
interrupt routine.
What happens if a second message comes in while speedo_interrupt() is running
but
has already left the do { } while(1) loop?
The second message that has been received will not be delivered within that
interrupt routine.
But will this cause a new interrupt that will be processed directly after the
first interrupt?
Or will the interrupt for the second message silently forgotten?
Thanks for any ideas on this!
Mathias
> 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
>
>
>
> --------------------------------
>
> -------------------------------------------------------------------------
> 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
>
--
Mathias Koehrer
[EMAIL PROTECTED]
Viel oder wenig? Schnell oder langsam? Unbegrenzt surfen + telefonieren
ohne Zeit- und Volumenbegrenzung? DAS TOP ANGEBOT JETZT bei Arcor: günstig
und schnell mit DSL - das All-Inclusive-Paket für clevere Doppel-Sparer,
nur 44,85 inkl. DSL- und ISDN-Grundgebühr!
http://www.arcor.de/rd/emf-dsl-2
-------------------------------------------------------------------------
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
