Hi, check the text below.
2011/6/20 Michael Abel <michael.a...@isw.uni-stuttgart.de>:
>
> Hello Lars,
>
> Thanks for trying out...
>
> On 06/19/2011 10:34 PM, Lars Segerlund wrote:
>>
>> command line ...
>> root@smurf:/home/ls/src/emc/emc2-dev/src/hal# chrt 99 ./shm_interface_test
>> Error while shmget
>> Semaphore value is 0
>> Waiting one second, then until semaphore gets released
>> Segmenteringsfel
>>
>> dmesg ...
>> [ 3579.723705] shm_interface_t[2462]: segfault at ffffffffa76ad000 ip
>> 0000000000400d14 sp 00007fff128c4600 error 6 in
>> shm_interface_test[400000+2000]
>>
>> I tried running with gdb but didn't get anything interesting, and it's
>> not a lot.
>>
>> I tried strace also
>>
>> arch_prctl(ARCH_SET_FS, 0x7fcf1a3d9700) = 0
>> mprotect(0x7fcf19b98000, 16384, PROT_READ) = 0
>> mprotect(0x7fcf19da8000, 4096, PROT_READ) = 0
>> mprotect(0x7fcf19fc0000, 4096, PROT_READ) = 0
>> mprotect(0x7fcf1a3f8000, 4096, PROT_READ) = 0
>> munmap(0x7fcf1a3dc000, 103274) = 0
>> set_tid_address(0x7fcf1a3d99d0) = 2483
>> set_robust_list(0x7fcf1a3d99e0, 0x18) = 0
>> futex(0x7fffd6bb89fc, FUTEX_WAKE_PRIVATE, 1) = 0
>> futex(0x7fffd6bb89fc, FUTEX_WAIT_BITSET_PRIVATE|FUTEX_CLOCK_REALTIME,
>> 1, NULL, 7fcf1a3d9700) = -1 EAGAIN (Resource temporarily unavailable)
>> rt_sigaction(SIGRTMIN, {0x7fcf19daf860, [], SA_RESTORER|SA_SIGINFO,
>> 0x7fcf19db8f60}, NULL, 8) = 0
>> rt_sigaction(SIGRT_1, {0x7fcf19daf8f0, [],
>> SA_RESTORER|SA_RESTART|SA_SIGINFO, 0x7fcf19db8f60}, NULL, 8) = 0
>> rt_sigprocmask(SIG_UNBLOCK, [RTMIN RT_1], NULL, 8) = 0
>> getrlimit(RLIMIT_STACK, {rlim_cur=8192*1024, rlim_max=RLIM_INFINITY}) = 0
>> shmget(0xcafe, 88, 0666) = 2883607
>> shmat(2883607, 0, 0) = ?
>> statfs("/dev/shm", {f_type=0x1021994, f_bsize=4096, f_blocks=127182,
>> f_bfree=127181, f_bavail=127181, f_files=127182, f_ffree=127179,
>> f_fsid={0, 0}, f_namelen=255, f_frsize=4096}) = 0
>> futex(0x7fcf19fc52bc, FUTEX_WAKE_PRIVATE, 2147483647) = 0
>> open("/dev/shm/sem.emcsem1", O_RDWR|O_NOFOLLOW) = 3
>> fstat(3, {st_mode=S_IFREG|0755, st_size=32, ...}) = 0
>> brk(0) = 0xc9f000
>> brk(0xcc0000) = 0xcc0000
>> mmap(NULL, 32, PROT_READ|PROT_WRITE, MAP_SHARED, 3, 0) = 0x7fcf1a3f4000
>> close(3) = 0
>> fstat(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 1), ...}) = 0
>> mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
>> 0) = 0x7fcf1a3f3000
>> write(1, "Semaphore value is 0\n", 21Semaphore value is 0
>> ) = 21
>> write(1, "Waiting one second, then until s"..., 55Waiting one second,
>> then until semaphore gets released
>> ) = 55
>> rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0
>> rt_sigaction(SIGCHLD, NULL, {SIG_DFL, [], 0}, 8) = 0
>> rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
>> nanosleep({1, 0}, 0x7fffd6bb8860) = 0
>> --- SIGSEGV (Segmentation fault) @ 0 (0) ---
>> +++ killed by SIGSEGV +++
>> Segmenteringsfel
>>
>> And a small guess ... I'm running 64 bit ? ...
>
> I don't know if 64 bit make problems in the EMC world. But I saw this in the
> output you sent: "Error while shmget". It seems like shmget fails for some
> reason, but the strace seems normal. And I saw that I forgot the exit
> statement in the error handler, this is probably the reason why it
> "Segmenteringsfels" later.
>
> @@ -93,6 +93,7 @@ int main()
> id = shmget(key, size, SHM_PERMISSIONS);
> if (id == -1) {
> printf("Error while shmget\n");
> + exit(-1);
> }
>
> Can you maybe try to remove the two shm-memories with ipcrm?
>
This I have tried, even on rebooted system, but I can look into it
later. Doestn't help.
>>
>> I have not had time to look to much at the code, since I have been ill
>> this week, but It seems to run.
>> I have mostly been busy trying to get an USB driver running for my
>> hardware, sorry but limited time.
>>
>> I do believe that shm_interface_test ran a couple of times ....
>>
>> Tell me if I can run any test, but at the moment I am actually more
>> concearned about RT-Preempt EMC :-D ... which is a reason to be really
>> happy.
>
> Do you like to tell me what you intend to do with an RT_Preempted EMC? Doing
> this seems kind of "unusal" :) .
>
Well , rt-preempt is almost in mainline now , and I have coded
embedded realtime systems, and I am a bit tired of patching and fixing
:-D ...
WIth realtime in mainline, there could be a 'out of the box' EMC for
open loop systems :D
VxWorks seems to be on it's way to RT-Preempt , RTDM drivers the
same, I think in time RT-Preempt will be the way to go.
If you look at the timing at http://osadl.org ( they have a graph of
all systems ... ), some get down to 8 us latency. Which would be good
enough for running a closed loop system on RT-Preempt. If you can
identify the latency source you can almost always fix it, most of the
time it's a driver.
For some systems a linux 3.0-rc3 gives better latency than 2.6.33-rt
I am going to use a USB interface with some steppers for a small lath
and mill since as a test platform, the USB chip can clock out data at
a constant rate on SPI, so latency doesn't matter that much.
For really good latency there is NO modern port on a PC :-D except
plug in cards .....
That would make a EMC out of the box, and with USB it could be very
nice for a lot of small scale machining, rep-raps or such.
I just think a realtime system out of the box is the way to go for EMC.
I have a lath and mill, have done a lot of realtime, and I have to
fool around with something that's interesting :D
/ regards, Lars Segerlund.
>>
>> Have you tried the mailinglist for rt-preempt about the timing ? it's
>> on http://osadl.org/ , or lkml.org ... I knot the hpet timers have
>> undergone some work.
>
> Unfortunately, I had no time yet to look at the timing issues. It works
> quite well on some machines here, on some others there are few problems.
> Latencies around 100us are probably bad, but it's currently enough for our
> purposes.
>
>
> Regards Michael
>
>>
>> / regards, Lars Segerlund.
>>
>> 2011/6/19 Michael Abel<michael.a...@isw.uni-stuttgart.de>:
>>>
>>> Hi Lars,
>>>
>>> I walked a bit trough the code and tried some things out. There is
>>> already
>>> cleanup code to avoid this problem, but the cleanup works only when emc
>>> is
>>> started as root. It seems just like a problem with permissions. I
>>> recommend
>>> to start emc as root to avoid the problems.
>>>
>>> In case of problems it's also possible to remove the shm by hand with
>>> these
>>> commands:
>>>
>>> ipcrm -M 0x48414c32 #(hal shm)
>>> ipcrm -M 0x0000cafe #(shm interface)
>>>
>>> Can you please tell me more about the segfaulting shm_tester? I have no
>>> problems with this program here...
>>> Thanks!
>>>
>>> regards Michael
>>>
>
> ----------------------------------------------------------------
> Dipl.-Ing. Michael Abel
>
> Graduate School advanced Manufacturing Engineering
> GSaME - Universität Stuttgart
>
> Institut für Steuerungstechnik
> der Werkzeugmaschinen und Fertigungseinrichtungen
> ISW - Universität Stuttgart
>
> Seidenstr. 36
> 70174 Stuttgart
>
> Tel.: ++49 (0) 711 685-82532
> Fax : ++49 (0) 711 685-82808
>
> michael.a...@isw.uni-stuttgart.de
> michael.a...@gsame.uni-stuttgart.de
>
> www.isw.uni-stuttgart.de
> www.gsame.uni-stuttgart.de
>
>
>
> ------------------------------------------------------------------------------
> EditLive Enterprise is the world's most technically advanced content
> authoring tool. Experience the power of Track Changes, Inline Image
> Editing and ensure content is compliant with Accessibility Checking.
> http://p.sf.net/sfu/ephox-dev2dev
> _______________________________________________
> Emc-developers mailing list
> Emc-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-developers
>
>
------------------------------------------------------------------------------
EditLive Enterprise is the world's most technically advanced content
authoring tool. Experience the power of Track Changes, Inline Image
Editing and ensure content is compliant with Accessibility Checking.
http://p.sf.net/sfu/ephox-dev2dev
_______________________________________________
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers
