[etherlab-dev] [etherlab-users] Using EtherCAT EoE and Build Errors

Thomas Bitsky, Jr. tbj at automateddesign.com
Thu Aug 16 03:52:58 CEST 2012


That's my next move,  then. I've been trying to build RTAI,  but the kernel
won't boot. Maybe I'll try rt-preempt.

Thomas C Bitsky Jr
Lead Developer and Application Engineer
ADC | automateddesign.com
(Sent from my mobile device.)
On Aug 15, 2012 8:47 PM, "Matthieu Bec" <mbec at gmto.org> wrote:

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


More information about the Etherlab-dev mailing list