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" <m...@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 <m...@gmto.org >> <mailto:m...@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-...@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 > >
_______________________________________________ etherlab-users mailing list etherlab-users@etherlab.org http://lists.etherlab.org/mailman/listinfo/etherlab-users