From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <4943DADB.3040608@domain.hid> Date: Sat, 13 Dec 2008 16:55:07 +0100 From: Wolfgang Grandegger MIME-Version: 1.0 References: <493306F5.2080605@domain.hid> <49330CD3.4090700@domain.hid> <4933BAE2.3000502@domain.hid> <4933F1A4.8060209@domain.hid> <4933F18F.7080103@domain.hid> <4933FE5A.5060501@domain.hid> <49355B5D.8070802@domain.hid> <49355A59.4050600@domain.hid> <49357C02.1090001@domain.hid> <49358003.1080705@domain.hid> <493BF43B.4080208@domain.hid> <493FA528.3060307@domain.hid> <49413128.5070704@domain.hid> In-Reply-To: <49413128.5070704@domain.hid> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Xenomai-help] pthread cancelation and scheduling magics List-Id: Help regarding installation and common use of Xenomai List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jan Kiszka Cc: xenomai-help Jan Kiszka wrote: > Wolfgang Grandegger wrote: >> Wolfgang Grandegger wrote: >>> Hi Gilles, >>> >>> Gilles Chanteperdrix wrote: >>>> Wolfgang Grandegger wrote: >>>>> I'm also puzzled why pthread_setschedparam() does make a mode switch >>>>> to secondary mode (sometimes). >>>> That is normal. The glibc caches threads priority value, so we have to >>>> call __real_pthread_setschedparam to update them. This issue has been >>>> solved differently on trunk, but unfortunately, we can not backport this >>>> modification on v2.4.x branch. >>> To get you right. With v2.4.x it is not possible with the POSIX skin to >>> change the priority of a real-time thread in the primary mode without >>> loosing determinism (because it will switch to secondary mode). What >>> options do I have? >> I gave Xenomai trunk a try and pthread_setschedparam() does not switch >> to secondary mode any more on my PowerPC test system. Nice, I just get >> an Oops in thread_delete from time to time. More on that issue later. >> For my ARM i.mx31 system, a need a few patches to get the Xenomai src's >> compiled: >> >> Index: include/asm-generic/bits/bind.h >> =================================================================== >> --- include/asm-generic/bits/bind.h (revision 4450) >> +++ include/asm-generic/bits/bind.h (working copy) >> @@ -72,7 +72,7 @@ >> err = XENOMAI_SYSCALL1(__xn_sys_current, ¤t); >> if (err) { >> fprintf(stderr, "Xenomai: error obtaining handle for current " >> - "thread: %s\n", strerror(err)); >> + "thread: %s\n", strerror(-err)); >> exit(1); >> } >> __xeno_set_current(current); >> Index: include/asm-arm/syscall.h >> =================================================================== >> --- include/asm-arm/syscall.h (revision 4450) >> +++ include/asm-arm/syscall.h (working copy) >> @@ -228,7 +228,7 @@ >> volatile unsigned long long *const tscp = __xn_tscinfo.u.fr.tsc; >> volatile unsigned *const counterp = __xn_tscinfo.u.fr.counter; >> const unsigned mask = __xn_tscinfo.u.fr.mask; >> - register unsigned long long after, before; >> + register unsigned long long result; >> unsigned counter; >> >> __asm__ ("ldmia %1, %M0\n": "=r"(result): "r"(tscp), "m"(*tscp)); >> >> >> When I then start my application or cyclictest I get: >> >> -bash-3.2# ./cyclictest -n >> Xenomai: error obtaining handle for current thread: Operation not permitted >> >> As the latency program works fine, it seems to be a problem with the >> POSIX skin. Any idea what it is? > > First of all, are you sure that all parts were properly updated and in > sync now? Well, everything (kernel, Xenomai unser-space) was built from scratch using the latest SVN revision. > > The error means that something went wrong during the > __wrap_pthread_setschedparam execution on __init_posix_interface. More > precisely, we lack the shadow thread for the current (main) thread for > unknown reasons. > > Could you fire up gdb, step through this and check (looking at > /proc/xenomai/sched) what happens on ARM here? x86 was fine the last > time I checked (will recheck later today). With --enable-debug it works just fine :-(. Wolfgang.