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

[Thomas Bitsky, Jr.]

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> 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>
>> 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
P: 630-783-1150 F: 630-783-1159 M: 630-632-6679
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.etherlab.org/pipermail/etherlab-dev/attachments/20120815/f5b88d91/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 2369topology.h
Type: text/x-chdr
Size: 10050 bytes
Desc: not available
URL: <http://lists.etherlab.org/pipermail/etherlab-dev/attachments/20120815/f5b88d91/attachment-0001.h>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: durability.c
Type: text/x-csrc
Size: 18835 bytes
Desc: not available
URL: <http://lists.etherlab.org/pipermail/etherlab-dev/attachments/20120815/f5b88d91/attachment-0001.c>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Makefile
Type: application/octet-stream
Size: 246 bytes
Desc: not available
URL: <http://lists.etherlab.org/pipermail/etherlab-dev/attachments/20120815/f5b88d91/attachment-0001.obj>