From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <538638CE.6070306@xenomai.org> Date: Wed, 28 May 2014 21:28:14 +0200 From: Philippe Gerum MIME-Version: 1.0 References: <5382E8B1.8070402@xenomai.org> <5383406C.4070902@xenomai.org> <5385F190.7050303@xenomai.org> <538622C8.6000906@xenomai.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Xenomai] gdb / threads on beaglebone black List-Id: Discussions about the Xenomai project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Drew , Gilles Chanteperdrix Cc: "Xenomai@xenomai.org" On 05/28/2014 09:19 PM, Drew wrote: > On Wed, May 28, 2014 at 1:54 PM, Gilles Chanteperdrix < > gilles.chanteperdrix@xenomai.org> wrote: > >> >> Is there no message printed on the kernel console which would explain >> why this syscall gets rejected? >> > > A good idea! Unfortunately, after hooking up my debug serial cable I don't > see any message when this happens. Running tail -f /var/log/messages > doesn't show anything suspicious either. (well, it did find some things I > didn't clean up in my main application... ;-) > > Grepping around for sys_barrier I come up with ksrc/nucleus/shadow.c. Does > that contain the kernel side of the do while loop? I notice that > xnshadow_sys_trace (which seems debugger related to me..) defaults its > error to -ENOSYS... It's not related to GDB, but to the internal tracing system available with CONFIG_IPIPE_TRACE. The call is likely dismissed even before Xenomai handles it. A brute force but straightforward way to get some hints would be to instrument the syscall router in the interrupt pipeline code. -- Philippe.