<p>That&#39;s my next move,  then. I&#39;ve been trying to build RTAI,  but the kernel won&#39;t boot. Maybe I&#39;ll try rt-preempt. </p>
<p>Thomas C Bitsky Jr<br>
Lead Developer and Application Engineer<br>
ADC | <a href="http://automateddesign.com">automateddesign.com</a><br>
(Sent from my mobile device.)</p>
<div class="gmail_quote">On Aug 15, 2012 8:47 PM, &quot;Matthieu Bec&quot; &lt;<a href="mailto:mbec@gmto.org">mbec@gmto.org</a>&gt; wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
indeed, though the FAQ says<br>
<br>
&gt;Supports any realtime environment through independent architecture.<br>
&gt;    RTAI, Xenomai, RT-Preempt, etc.<br>
&gt;    Operation possible without any realtime extension at all.<br>
<br>
I am not sure about the second statement or how to make it work. Always had better luck with real-time extensions and never looked back. RT-Preempt is easy to setup and kind of transparent. vanilla kernel was giving me (if I recall correctly) similar semaphores vs. spinlocks issue as you pointed earlier<br>

<br>
Matthieu<br>
<br>
<br>
On 08/15/12 17:53, Thomas Bitsky, Jr. wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I&#39;m not sure if this is a problem in my source code or a bug in the code<br>
relating to synchronization.<br>
<br>
So, my problem has become this: I can successfully use EoE when the<br>
EtherCAT network is not operational. I can successfully use the EtherCAT<br>
network in Operation if the virtual EoE interface is down, but if I put<br>
the EtherCAT network into Operation and use the callbacks to handle EoE,<br>
the entire computer locks up.<br>
<br>
For reference:<br>
EtherCAT version: stable-1.5<br>
System: Linux laptop14 2.6.32-42-generic-pae #95-Ubuntu SMP Wed Jul 25<br>
16:13:09 UTC 2012 i686 GNU/Linux<br>
I am not using any real-time extensions.<br>
GCC: 4.4<br>
<br>
<br>
The problem could very well be in my source code, although I&#39;ve matched<br>
it closely to the EtherLAB examples. Once the virtual EoE interface goes<br>
up, the kernel log is filling with the errors I mentioned before:<br>
<br>
[ 2687.384659]<br>
[ 2687.384665] Pid: 0, comm: swapper Tainted: P        W<br>
   (2.6.32-42-generic-pae #95-Ubuntu) Latitude E6510<br>
[ 2687.384672] EIP: 0060:[&lt;c03ac336&gt;] EFLAGS: 00000202 CPU: 3<br>
[ 2687.384680] EIP is at acpi_idle_enter_bm+0x275/0x2a4<br>
[ 2687.384684] EAX: c088eb4c EBX: 00000ee7 ECX: 00000000 EDX: 03036000<br>
[ 2687.384689] ESI: 00000000 EDI: f6e404cc EBP: f74cbf78 ESP: f74cbf50<br>
[ 2687.384694]  DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068<br>
[ 2687.384698] CR0: 8005003b CR2: b94c0004 CR3: 00799000 CR4: 000006f0<br>
[ 2687.384703] DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000<br>
[ 2687.384707] DR6: ffff0ff0 DR7: 00000400<br>
[ 2687.384710] Call Trace:<br>
[ 2687.384719]  [&lt;c04ca54a&gt;] cpuidle_idle_call+0x7a/0x100<br>
[ 2687.384727]  [&lt;c01085a4&gt;] cpu_idle+0x94/0xd0<br>
[ 2687.384735]  [&lt;c05b31b7&gt;] start_secondary+0xc4/0xc6<br>
[ 2687.393250] BUG: scheduling while atomic: swapper/0/0x10000100<br>
[ 2687.393256] Modules linked in: durability ec_generic ec_e1000<br>
ec_8139too ec_master mii michael_mic arc4 binfmt_misc snd_hda_codec_idt<br>
<br>
<br>
The notable parts of my code are the callback:<br>
<br>
void<br>
send_callback(void *cb_data)<br>
{<br>
ec_master_t *m = (ec_master_t *) cb_data;<br>
         down(&amp;master_sem);<br>
ecrt_master_send_ext(m);<br>
         up(&amp;master_sem);<br>
}<br>
<br>
void<br>
receive_callback(void *cb_data)<br>
{<br>
ec_master_t *m = (ec_master_t *) cb_data;<br>
         down(&amp;master_sem);<br>
ecrt_master_receive(m);<br>
         up(&amp;master_sem);<br>
}<br>
If they are not in the program and activated by ecrt_master_callbacks,<br>
then there is no lock-up. Of course, EoE doesn&#39;t work. Once I put them<br>
in, the system hangs in about 30 seconds or less. I can&#39;t see any<br>
obvious reason for this: it looks like dead lock. I added traces and<br>
watched the kernel log viewer; I think it&#39;s locking up in<br>
ecrt_master_send_ext and not returning.<br>
<br>
In any case, I&#39;ve been working on this for five days. If anyone can<br>
shine some light on what I&#39;m doing wrong, or how I can fix this, I&#39;d<br>
appreciate it.<br>
<br>
Thanks again!<br>
Tom<br>
<br>
<br>
On Wed, Aug 15, 2012 at 1:02 PM, Matthieu Bec &lt;<a href="mailto:mbec@gmto.org" target="_blank">mbec@gmto.org</a><br>
&lt;mailto:<a href="mailto:mbec@gmto.org" target="_blank">mbec@gmto.org</a>&gt;&gt; wrote:<br>
<br>
<br>
        # ifconfig eoe0s7 192.168.127.10<br>
        # ifconfig eoe0s7 up<br>
<br>
        Is there any way to make this happen automatically on startup? In<br>
        /etc/network, I created a file called ifcg-eoe0s7 and put in:<br>
<br>
        IPADDRESS=<a href="http://192.168.127.10/24" target="_blank">192.168.127.10/24</a> &lt;<a href="http://192.168.127.10/24" target="_blank">http://192.168.127.10/24</a>&gt;<br>
        &lt;<a href="http://192.168.127.10/24" target="_blank">http://192.168.127.10/24</a>&gt;<br>
        STARTMODE=auto<br>
<br>
        But it must not be working because the virtual interface doesn&#39;t<br>
        even<br>
        have an IP Address until I give it one manually.<br>
<br>
<br>
    on fedora:<br>
<br>
    # ifup eoe0s7<br>
<br>
    best consult the ubuntu forums.<br>
<br>
<br>
<br>
<br>
--<br>
Thomas C. Bitsky Jr.<br>
Lead Developer and Application Engineer<br>
ADC | <a href="http://automateddesign.com" target="_blank">automateddesign.com</a> &lt;<a href="http://automateddesign.com" target="_blank">http://automateddesign.com</a>&gt;<br>
P: <a href="tel:630-783-1150" value="+16307831150" target="_blank">630-783-1150</a> &lt;tel:<a href="tel:630-783-1150" value="+16307831150" target="_blank">630-783-1150</a>&gt; F: <a href="tel:630-783-1159" value="+16307831159" target="_blank">630-783-1159</a> &lt;tel:<a href="tel:630-783-1159" value="+16307831159" target="_blank">630-783-1159</a>&gt; M:<br>

<a href="tel:630-632-6679" value="+16306326679" target="_blank">630-632-6679</a> &lt;tel:<a href="tel:630-632-6679" value="+16306326679" target="_blank">630-632-6679</a>&gt;<br>
<br>
<br>
<br>
______________________________<u></u>_________________<br>
etherlab-dev mailing list<br>
<a href="mailto:etherlab-dev@etherlab.org" target="_blank">etherlab-dev@etherlab.org</a><br>
<a href="http://lists.etherlab.org/mailman/listinfo/etherlab-dev" target="_blank">http://lists.etherlab.org/<u></u>mailman/listinfo/etherlab-dev</a><br>
<br>
</blockquote>
i<br>
<br>
-- <br>
Matthieu Bec                GMTO Corp.<br>
cell:  <a href="tel:%2B1%20626%20354%209367" value="+16263549367" target="_blank">+1 626 354 9367</a>      P.O. Box 90933<br>
phone: <a href="tel:%2B1%20626%20204%200527" value="+16262040527" target="_blank">+1 626 204 0527</a>      Pasadena, CA 91109-0933<br>
<br>
</blockquote></div>