Thread: [RTnet-users] Update rt_e1000e driver -- job offer
Brought to you by:
bet-frogger,
kiszka
Menu
▾
▴
rtnet-users
|
From: Mariusz J. <mar...@wp...> - 2014-05-26 09:16:25
|
Dear all,
We are looking for a person who is able to update the rt_e1000e driver to make it supporting the newer Intel NIC like 82574L, 82579LM, 82567V correctly under the Xenomai 2.6.3 with a kernel at least 3.8.13 or newer. The problem is following, while RTnet modules and drivers load correctly without any warnings, NIC is not able to send ethernet frames for some random time. During that time, RTnet stack report that is not able to transmit synchronization frame ("TDMA: Failed to transmit sync
frame!"), the rt_e1000e driver reset device several times, and two leds integrated with connector are not blinking. After a while, device start to operate normally, sync frame are sending normally, and there is no further issues. The main problem is, that we don't know when RTnet stack start to work, so we have to wait unpredictable period of time. Also just after NIC start sending sync frames, it has buffered several old ones, so it send them one ofter another as fast as possible, what make
problem for our custom devices during synchronization phase. Currently, we observe similar non acceptable behavior on following machines:
- Supermicro MBD-X9SPV-M4-3QE-O,
- Advantech PCM-3363D-1GS8A1E,
- Commel Mini-ITX Motherboard LV-67C.
with latest RTnet git version, Xenomai 2.6.3, kernel 3.8.13 and Ubuntu 12.04.
We expect that an involved person should prepare a patch which remove described issues and applies cleanly to the latest RTnet git version. The patch should be available for a community on the same license as RTnet stack. Patch will be tested on listed devices.
We offer a contract to perform a specified task, one of the parties will be
Wroclaw University of Technology
Wybrzeże Wyspiańskiego 27
50-370 Wrocław
tel. 71 320 26 00
NIP: 896-000-58-51
REGON: 000001614
www.pwr.edu.pl
Please send your letter of application including, short CV, expected salary (EUR or PLN) and estimated time period required for patch preparation, to
Mariusz Janiak
Chair of Cybernetics and Robotics,
Wroclaw University of Technology
Janiszewskiego 11/17,
Wroclaw, Poland,
tel: +48 71 320 26 44
email: mar...@pw...
Best regards,
Mariusz
|
|
From: Stéphane A. <san...@fr...> - 2014-05-27 07:41:29
|
Hi,
There are so many reasons that could happen.
At first, are you sure , your xenomai system has not any jitter involved
? And how have you checked it ?
Regards,
S.Ancelot
On 26/05/2014 11:16, Mariusz Janiak wrote:
> Dear all,
>
> We are looking for a person who is able to update the rt_e1000e driver to make it supporting the newer Intel NIC like 82574L, 82579LM, 82567V correctly under the Xenomai 2.6.3 with a kernel at least 3.8.13 or newer. The problem is following, while RTnet modules and drivers load correctly without any warnings, NIC is not able to send ethernet frames for some random time. During that time, RTnet stack report that is not able to transmit synchronization frame ("TDMA: Failed to transmit sync
> frame!"), the rt_e1000e driver reset device several times, and two leds integrated with connector are not blinking. After a while, device start to operate normally, sync frame are sending normally, and there is no further issues. The main problem is, that we don't know when RTnet stack start to work, so we have to wait unpredictable period of time. Also just after NIC start sending sync frames, it has buffered several old ones, so it send them one ofter another as fast as possible, what make
> problem for our custom devices during synchronization phase. Currently, we observe similar non acceptable behavior on following machines:
> - Supermicro MBD-X9SPV-M4-3QE-O,
> - Advantech PCM-3363D-1GS8A1E,
> - Commel Mini-ITX Motherboard LV-67C.
> with latest RTnet git version, Xenomai 2.6.3, kernel 3.8.13 and Ubuntu 12.04.
>
> We expect that an involved person should prepare a patch which remove described issues and applies cleanly to the latest RTnet git version. The patch should be available for a community on the same license as RTnet stack. Patch will be tested on listed devices.
>
> We offer a contract to perform a specified task, one of the parties will be
>
> Wroclaw University of Technology
> Wybrzeże Wyspiańskiego 27
> 50-370 Wrocław
> tel. 71 320 26 00
> NIP: 896-000-58-51
> REGON: 000001614
> www.pwr.edu.pl
>
> Please send your letter of application including, short CV, expected salary (EUR or PLN) and estimated time period required for patch preparation, to
>
> Mariusz Janiak
> Chair of Cybernetics and Robotics,
> Wroclaw University of Technology
> Janiszewskiego 11/17,
> Wroclaw, Poland,
> tel: +48 71 320 26 44
> email: mar...@pw...
>
> Best regards,
> Mariusz
>
>
>
>
> ------------------------------------------------------------------------------
> The best possible search technologies are now affordable for all companies.
> Download your FREE open source Enterprise Search Engine today!
> Our experts will assist you in its installation for $59/mo, no commitment.
> Test it for FREE on our Cloud platform anytime!
> http://pubads.g.doubleclick.net/gampad/clk?id=145328191&iu=/4140/ostg.clktrk
> _______________________________________________
> RTnet-users mailing list
> RTn...@li...
> https://lists.sourceforge.net/lists/listinfo/rtnet-users
|
|
From: Wojciech D. <woj...@gm...> - 2014-06-30 11:48:09
|
I have found similar solution to the one presented at https://www.mail-archive.com/rtnet-users@.../msg01326.html In my case, it was required to edit the rtnet script. I have added 5 seconds of delay in submit_cfg() function, just after bringing rteth0 device up. Does anyone know why the rt_e1000e driver can't handle this? Wojciech Domski Domski.pl Wojciech.Domski.pl W dniu 2014-04-01 12:40, Wojciech Domski pisze: > Dear all, > > I am experiencing some problems using the rt_e1000e driver for RTnet. > > What I am doing is pretty simple, however not everything is working as > it supposed to. After I start the rtnet service I'm keep getting such > communicates from syslog: > > TDMA: Failed to transmit sync frame! > > and occasionally: > > rt_e1000e: Reset adapter > > After quite long time (at least few minutes) > the driver manages to establish the connection > and then everything is working as it should. > > As my set-up I'm using mother board with those ethernet devices: > > 00:19.0 Ethernet controller: Intel Corporation 82579LM Gigabit Network > Connection (rev 04) > 04:00.0 Ethernet controller: Intel Corporation 82574L Gigabit Network > Connection > a 8-port switch > a dedicated device bases on a microcontroller running RTnet. > > As I described before I was able to establish the transmission and > then everything is working as it should. The time needed for > establishing the connection is however unacceptable. > > Also I have tried repeating the same scenario but this time > only using the switch and everything is as previous. > Moreover, I tested this on different machines and I'm experiencing > the same problem. > > I've found this on mailing list: > > https://www.mail-archive.com/rtnet-users@.../msg01326.html > > > encouraged I've tried it by editing rtnet script by adding a substantial > delay > of few seconds after all the drivers were loaded. Unfortunately, > that didn't solved the problem. > > Different approach was to try the patch for the newest version > for e1000e driver and this one also didn't solve the problem. > > Best regards, > > -- > Wojciech Domski > > Domski.pl > > Wojciech.Domski.pl > > > > ------------------------------------------------------------------------------ > The best possible search technologies are now affordable for all companies. > Download your FREE open source Enterprise Search Engine today! > Our experts will assist you in its installation for $59/mo, no commitment. > Test it for FREE on our Cloud platform anytime! > http://pubads.g.doubleclick.net/gampad/clk?id=145328191&iu=/4140/ostg.clktrk > _______________________________________________ > RTnet-users mailing list > RTn...@li... > https://lists.sourceforge.net/lists/listinfo/rtnet-users |
Thanks for helping keep SourceForge clean.
X