Hi everbody, I have made a test that allows to reproduce the issue (enclosed to this mail). You need two PCs that run the rtnet software. The test is written for RTAI-3.3cv, however it should be easy to move it to xenomai.
One of the PCs acts as server. This one should have the eepro100 board, as this
is the candidate that
shows the buggy behaviour.
The other PC acts as client. This one can have any rtnet-support NIC (I use
also a eepro100 for it).
Both PCs are connected via an cross-over cable.
The test sequence is the following:
Client Server
---- 1472 ---->
---- 32 ---->
<---- 800 -----
The client sends two UDP messages, one with 1472 the second with 32 byte data.
The server confirms the reception of both messages by a 800 byte response.
This test will be repeated permanently. Whenever the reception of the
second message fails, it will be printed out (dmesg to see the results).
On my system, it takes about 280 microseconds for one cycle.
The test is realized in two kernel modules, to ease startup I have also written
two scripts.
Please read the readme.txt in the archive.
The shorter the second frame is, the more often the critical situation appears.
It takes only a few seconds on my system to get the error (especially if some
other process is doing lot of harddisk/ethernet action on the server PC).
Perhaps there is anybody out there that could run this test.
Interesting could be, if it behaves the same under xenomai.
Thanks a lot
Mathias
> >> I have tested two boards, one with revision 0c and one with revision 0d.
> >> No difference here.
> >> I have also implemented a status array, the returns the last 16 status
> codes
> >> before the missing signal:
> >> The result is:
> >> 2050 0050 4050 0050 4050 0050 2050 0050 4050 0050 4050 0050 2050 0050
> 4050 0050
> >> I have the sequence: Receive two messages, send one message, receive two,
> send one...
> >> However, at the end I have received only one frame and not two (at least
> status indicates that).
> >> Or: Within one interrupt both frames come in.
> >>
> >> When I increase the size of my short, second message from 80 to 200 byte
> everything works
> >> perfectly. Then I never get the communication error.
> >> This is the workaround I use currently.
> >
> > This really sounds like some timing issue. Extending the messages size
> > delays it.
> >
> > Do those two incoming frames normally trigger two separate IRQ events?
> > Or do they arrive within the same round, causing the IRQ handler to loop?
>
> Comparing this with the behaviour of the rt_e1000 would be interesting
> as well. The question behind it: does it work because the
> driver/hardware doesn't have an issue or because the timing is different?
>
> Jan
>
--
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
rtnettest.tgz
Description: Binary data
------------------------------------------------------------------------- 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
