From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <54E4E166.5030701@siemens.com> Date: Wed, 18 Feb 2015 20:00:54 +0100 From: Jan Kiszka MIME-Version: 1.0 References: <54E4D14E.1060104@siemens.com> <20150218175507.GD30317@hermes.click-hack.org> <54E4D61B.1020006@siemens.com> <20150218181334.GE30317@hermes.click-hack.org> <54E4D835.1040204@siemens.com> <20150218182632.GG30317@hermes.click-hack.org> <54E4DDEA.3060909@siemens.com> <20150218184943.GH30317@hermes.click-hack.org> In-Reply-To: <20150218184943.GH30317@hermes.click-hack.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Subject: Re: [Xenomai] arm: Late delivery of pending Linux signals? List-Id: Discussions about the Xenomai project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Gilles Chanteperdrix Cc: Xenomai On 2015-02-18 19:49, Gilles Chanteperdrix wrote: > On Wed, Feb 18, 2015 at 07:46:02PM +0100, Jan Kiszka wrote: >> On 2015-02-18 19:26, Gilles Chanteperdrix wrote: >>> On Wed, Feb 18, 2015 at 07:21:41PM +0100, Jan Kiszka wrote: >>>> On 2015-02-18 19:13, Gilles Chanteperdrix wrote: >>>>> On Wed, Feb 18, 2015 at 07:12:43PM +0100, Jan Kiszka wrote: >>>>>> On 2015-02-18 18:55, Gilles Chanteperdrix wrote: >>>>>>> On Wed, Feb 18, 2015 at 06:52:14PM +0100, Jan Kiszka wrote: >>>>>>>> Hi Gilles, >>>>>>>> >>>>>>>> I noticed on ARM (AM335 TI board) that the SIGDEBUG if the related test >>>>>>>> apparently only gets delivered to the receiver after it invokes a >>>>>>>> syscall, not on return from its secondary mode migration. Therefore the >>>>>>>> page fault test of the sigdebug smokey test fails (tested with Xenomai >>>>>>>> 3), and I bet the watchdog test as well. Is this a known limitation? >>>>>>> >>>>>>> Xenomai 2.6 sigdebug works fine on omap3 (very near from an >>>>>> >>>>>> Will try 2.6 next. >>>>>> >>>>>>> arm33xx). That being said, the AM3xx port is not part of the main >>>>>>> line I-pipe, and based on a non mainline kernel, so it is difficult >>>>>>> for me to answer this question. >>>>>> >>>>>> Then I'm possibly not building all recommended bits - I'm on 3.14 I-pipe >>>>>> upstream. That seems to work fine in general. Which version are you >>>>>> referring to? >>>>> >>>>> The one documented in arm/patches/README >>>> >>>> https://github.com/RobertCNelson/linux-dev/commits/am33x-v3.8? There is >>>> nothing explicitly stated regarding the AM3xx board, just that reference >>>> in the context of the Beaglebone. >>>> >>>> Anyway, I thought that syscall and exception handling should not be >>>> dependent on board patches, should they? >>> >>> If you had been using a Linux fork (which I assumed you did, >>> because you mentioned a processor which is not mainline officially), >>> it would have been very possible for the Linux fork you used to >>> break the changes in entry.S due to a bad conflict resolution. >>> Linux forks very often tend to push changes in generic code even >>> though they should not. >> >> The TI AM335x (Cortex-A8) comes with full mainline support, even for >> 3.14. That's probably why vanilla I-pipe 3.14 works for us. >> >> Against all odds, I just got Debian installed into an Integrator/CP >> machine model. Let's see if I can debug the issue that way. But I will >> keep porting I-pipe to the Versatile Express in mind. > > If you have an ARM board, why going over all these contorsions? Why > not simply enabling the I-pipe tracer and looking at what happens > when you observe the problem you observe ? Because it's easier to debug than to trace such an issue. Emulation, and even more virtualization, is more handy than real hw. E.g., this particular board has the nice feature of not booting up automatically when being power-cycled. Jan -- Siemens AG, Corporate Technology, CT RTC ITP SES-DE Corporate Competence Center Embedded Linux