[Xenomai] arm: Late delivery of pending Linux signals?

[Xenomai] arm: Late delivery of pending Linux signals?

[Jan Kiszka]

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?

Jan

-- 
Siemens AG, Corporate Technology, CT RTC ITP SES-DE
Corporate Competence Center Embedded Linux

Re: [Xenomai] arm: Late delivery of pending Linux signals?

[Gilles Chanteperdrix]

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
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.

-- 
					    Gilles.

Re: [Xenomai] arm: Late delivery of pending Linux signals?

[Jan Kiszka]

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?

Jan

-- 
Siemens AG, Corporate Technology, CT RTC ITP SES-DE
Corporate Competence Center Embedded Linux

Re: [Xenomai] arm: Late delivery of pending Linux signals?

[Gilles Chanteperdrix]

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

-- 
					    Gilles.

Re: [Xenomai] arm: Late delivery of pending Linux signals?

[Jan Kiszka]

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?

BTW, do you have recommended QEMU setup? Does the vexpress work (despite
not being listed)? The integratorcp model doesn't like me, while I have
vexpress even in KVM running (but guest debugging is still worked on).

Jan

-- 
Siemens AG, Corporate Technology, CT RTC ITP SES-DE
Corporate Competence Center Embedded Linux

Re: [Xenomai] arm: Late delivery of pending Linux signals?

[Gilles Chanteperdrix]

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.

No idea, I do not have a beaglebone, I just accept patches for it.

> 
> Anyway, I thought that syscall and exception handling should not be
> dependent on board patches, should they?
> 
> BTW, do you have recommended QEMU setup? Does the vexpress work (despite
> not being listed)? The integratorcp model doesn't like me, while I have
> vexpress even in KVM running (but guest debugging is still worked on).

No idea, I do not use QEMU.

-- 
					    Gilles.

Re: [Xenomai] arm: Late delivery of pending Linux signals?

[Gilles Chanteperdrix]

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.

-- 
					    Gilles.

Re: [Xenomai] arm: Late delivery of pending Linux signals?

[Jan Kiszka]

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.

Jan

-- 
Siemens AG, Corporate Technology, CT RTC ITP SES-DE
Corporate Competence Center Embedded Linux

Re: [Xenomai] arm: Late delivery of pending Linux signals?

[Gilles Chanteperdrix]

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 ?

-- 
					    Gilles.

Re: [Xenomai] arm: Late delivery of pending Linux signals?

[Jan Kiszka]

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

Re: [Xenomai] arm: Late delivery of pending Linux signals?

[Gilles Chanteperdrix]

On Wed, Feb 18, 2015 at 08:00:54PM +0100, Jan Kiszka wrote:
> 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.

I would tend to think that having to port the I-pipe to a virtual
board consumes useless time, and useless maintenance time (because
once you add the support for a board it takes time to maintain it),
as is installing a debian distribution for that virtual board.
During all that time you would have had the time to fix the bug 10
times using printk and the I-pipe tracer. And also, ARM processors
have a nice feature called JTAG, which is much more reliable than
hoping that a virtual hardware will have the same behaviour than
real hardware.

-- 
					    Gilles.

Re: [Xenomai] arm: Late delivery of pending Linux signals?

[Jan Kiszka]

On 2015-02-18 20:05, Gilles Chanteperdrix wrote:
> On Wed, Feb 18, 2015 at 08:00:54PM +0100, Jan Kiszka wrote:
>> 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.
> 
> I would tend to think that having to port the I-pipe to a virtual
> board consumes useless time, and useless maintenance time (because
> once you add the support for a board it takes time to maintain it),
> as is installing a debian distribution for that virtual board.
> During all that time you would have had the time to fix the bug 10
> times using printk and the I-pipe tracer. And also, ARM processors
> have a nice feature called JTAG, which is much more reliable than
> hoping that a virtual hardware will have the same behaviour than
> real hardware.

The Versatile Express is the ARM reference board, not something
arbitrary virtual. It's also what you get when you obtain the Fast Model
(CPU and system emulator) from ARM.

Yes, there is JTAG, but virtual debugging still covers most of our
problems and remains faster (shorter setup and boot times). Almost all
of the nasty x86 issues I hacked on in the past yeats were reproducible
in KVM.

Another advantage is that a virtual target makes automated testing much
more scalable as it becomes independent of the availability of physical
targets.

Oh, and QEMU is about to gain reverse execution support. That's out of
reach with real hw.

Jan

-- 
Siemens AG, Corporate Technology, CT RTC ITP SES-DE
Corporate Competence Center Embedded Linux

Re: [Xenomai] arm: Late delivery of pending Linux signals?

[Gilles Chanteperdrix]

On Wed, Feb 18, 2015 at 08:17:26PM +0100, Jan Kiszka wrote:
> On 2015-02-18 20:05, Gilles Chanteperdrix wrote:
> > On Wed, Feb 18, 2015 at 08:00:54PM +0100, Jan Kiszka wrote:
> >> 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.
> > 
> > I would tend to think that having to port the I-pipe to a virtual
> > board consumes useless time, and useless maintenance time (because
> > once you add the support for a board it takes time to maintain it),
> > as is installing a debian distribution for that virtual board.
> > During all that time you would have had the time to fix the bug 10
> > times using printk and the I-pipe tracer. And also, ARM processors
> > have a nice feature called JTAG, which is much more reliable than
> > hoping that a virtual hardware will have the same behaviour than
> > real hardware.
> 
> The Versatile Express is the ARM reference board, not something
> arbitrary virtual. It's also what you get when you obtain the Fast Model
> (CPU and system emulator) from ARM.

Nevertheless, it is a board that nobody uses for real projects,
so adding support for it is still a waste of resources.

> 
> Yes, there is JTAG, but virtual debugging still covers most of our
> problems and remains faster (shorter setup and boot times). Almost all
> of the nasty x86 issues I hacked on in the past yeats were reproducible
> in KVM.

All of the nasty ARM issues I hacked on in the past years were
debugged on real hardware, most of them with creative use of the
I-pipe tracer. For the fast compilation and boot time, I
use mkrootfs:

https://git.xenomai.org/mkrootfs.git/

-- 
					    Gilles.

Re: [Xenomai] arm: Late delivery of pending Linux signals?

[Gilles Chanteperdrix]

On Wed, Feb 18, 2015 at 08:27:12PM +0100, Gilles Chanteperdrix wrote:
> On Wed, Feb 18, 2015 at 08:17:26PM +0100, Jan Kiszka wrote:
> > On 2015-02-18 20:05, Gilles Chanteperdrix wrote:
> > > On Wed, Feb 18, 2015 at 08:00:54PM +0100, Jan Kiszka wrote:
> > >> 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.
> > > 
> > > I would tend to think that having to port the I-pipe to a virtual
> > > board consumes useless time, and useless maintenance time (because
> > > once you add the support for a board it takes time to maintain it),
> > > as is installing a debian distribution for that virtual board.
> > > During all that time you would have had the time to fix the bug 10
> > > times using printk and the I-pipe tracer. And also, ARM processors
> > > have a nice feature called JTAG, which is much more reliable than
> > > hoping that a virtual hardware will have the same behaviour than
> > > real hardware.
> > 
> > The Versatile Express is the ARM reference board, not something
> > arbitrary virtual. It's also what you get when you obtain the Fast Model
> > (CPU and system emulator) from ARM.
> 
> Nevertheless, it is a board that nobody uses for real projects,
> so adding support for it is still a waste of resources.
> 
> > 
> > Yes, there is JTAG, but virtual debugging still covers most of our
> > problems and remains faster (shorter setup and boot times). Almost all
> > of the nasty x86 issues I hacked on in the past yeats were reproducible
> > in KVM.
> 
> All of the nasty ARM issues I hacked on in the past years were
> debugged on real hardware, most of them with creative use of the
> I-pipe tracer. For the fast compilation and boot time, I
> use mkrootfs:
> 
> https://git.xenomai.org/mkrootfs.git/

And NFS, of course.

-- 
					    Gilles.

Re: [Xenomai] arm: Late delivery of pending Linux signals?

[Jan Kiszka]

On 2015-02-18 20:27, Gilles Chanteperdrix wrote:
> On Wed, Feb 18, 2015 at 08:17:26PM +0100, Jan Kiszka wrote:
>> The Versatile Express is the ARM reference board, not something
>> arbitrary virtual. It's also what you get when you obtain the Fast Model
>> (CPU and system emulator) from ARM.
> 
> Nevertheless, it is a board that nobody uses for real projects,
> so adding support for it is still a waste of resources.

No need to worry, it mostly just works. Apparently, I-pipe already
covers the whole Cortex-A series with its unified timers, clocks, and
interrupt controllers. Well, with the exception of SoCs that have
additional interrupt controllers - like the NVIDIA Tegra124, which I'm
currently looking at for other purposes.

"Mostly" because sshd is dying for unknown reasons. Same rootfs, same
emulator but newer kernel without I-pipe, and it works fine. One after
the other.

BTW, I noticed that LPAE build is broken. Trivial to fix (missing
argument to cpu_switch_mm), but maybe there is more behind it as it was
not used so far. Anything mm-related that one has to look at carefully
on ARM(v7)?

Jan

-- 
Siemens AG, Corporate Technology, CT RTC ITP SES-DE
Corporate Competence Center Embedded Linux

Re: [Xenomai] arm: Late delivery of pending Linux signals?

[Gilles Chanteperdrix]

On Wed, Feb 18, 2015 at 09:49:56PM +0100, Jan Kiszka wrote:
> On 2015-02-18 20:27, Gilles Chanteperdrix wrote:
> > On Wed, Feb 18, 2015 at 08:17:26PM +0100, Jan Kiszka wrote:
> >> The Versatile Express is the ARM reference board, not something
> >> arbitrary virtual. It's also what you get when you obtain the Fast Model
> >> (CPU and system emulator) from ARM.
> > 
> > Nevertheless, it is a board that nobody uses for real projects,
> > so adding support for it is still a waste of resources.
> 
> No need to worry, it mostly just works. Apparently, I-pipe already
> covers the whole Cortex-A series with its unified timers, clocks, and
> interrupt controllers. Well, with the exception of SoCs that have
> additional interrupt controllers - like the NVIDIA Tegra124, which I'm
> currently looking at for other purposes.

As far as I understood versatile is a platform which accepts several
processor modules, which cover a large part of the ranges of all
ARM cores made by ARM.

> 
> "Mostly" because sshd is dying for unknown reasons. Same rootfs, same
> emulator but newer kernel without I-pipe, and it works fine. One after
> the other.
> 
> BTW, I noticed that LPAE build is broken. Trivial to fix (missing
> argument to cpu_switch_mm), but maybe there is more behind it as it was
> not used so far. Anything mm-related that one has to look at carefully
> on ARM(v7)?

For LPAE support you need that commit:
https://git.xenomai.org/ipipe.git/commit/?h=ipipe-3.16&id=653ee8e622fe2ab7ff2fda1a0d14100d01bbf2e5

at least.

-- 
					    Gilles.

Re: [Xenomai] arm: Late delivery of pending Linux signals?

[Gilles Chanteperdrix]

On Wed, Feb 18, 2015 at 09:49:56PM +0100, Jan Kiszka wrote:
> On 2015-02-18 20:27, Gilles Chanteperdrix wrote:
> > On Wed, Feb 18, 2015 at 08:17:26PM +0100, Jan Kiszka wrote:
> >> The Versatile Express is the ARM reference board, not something
> >> arbitrary virtual. It's also what you get when you obtain the Fast Model
> >> (CPU and system emulator) from ARM.
> > 
> > Nevertheless, it is a board that nobody uses for real projects,
> > so adding support for it is still a waste of resources.
> 
> No need to worry, it mostly just works. Apparently, I-pipe already
> covers the whole Cortex-A series with its unified timers, clocks, and
> interrupt controllers. Well, with the exception of SoCs that have
> additional interrupt controllers - like the NVIDIA Tegra124, which I'm
> currently looking at for other purposes.
> 
> "Mostly" because sshd is dying for unknown reasons. Same rootfs, same
> emulator but newer kernel without I-pipe, and it works fine. One after
> the other.

That is the joys of of not using real hardware. The I-pipe uses some
registers or configure others that may not be implemented in the emulator.

-- 
					    Gilles.

Re: [Xenomai] arm: Late delivery of pending Linux signals?

[Jan Kiszka]

On 2015-02-18 22:00, Gilles Chanteperdrix wrote:
> On Wed, Feb 18, 2015 at 09:49:56PM +0100, Jan Kiszka wrote:
>> On 2015-02-18 20:27, Gilles Chanteperdrix wrote:
>>> On Wed, Feb 18, 2015 at 08:17:26PM +0100, Jan Kiszka wrote:
>>>> The Versatile Express is the ARM reference board, not something
>>>> arbitrary virtual. It's also what you get when you obtain the Fast Model
>>>> (CPU and system emulator) from ARM.
>>>
>>> Nevertheless, it is a board that nobody uses for real projects,
>>> so adding support for it is still a waste of resources.
>>
>> No need to worry, it mostly just works. Apparently, I-pipe already
>> covers the whole Cortex-A series with its unified timers, clocks, and
>> interrupt controllers. Well, with the exception of SoCs that have
>> additional interrupt controllers - like the NVIDIA Tegra124, which I'm
>> currently looking at for other purposes.
>>
>> "Mostly" because sshd is dying for unknown reasons. Same rootfs, same
>> emulator but newer kernel without I-pipe, and it works fine. One after
>> the other.
> 
> That is the joys of of not using real hardware. The I-pipe uses some
> registers or configure others that may not be implemented in the emulator.

We will see where this one comes from.

For now, I'm able to reproduce all the issues and effects I've seen on
the AM335x in QEMU's Integrator/CP.

Jan

-- 
Siemens AG, Corporate Technology, CT RTC ITP SES-DE
Corporate Competence Center Embedded Linux

[Xenomai] [PATCH] arm/ipipe: Fix logical inversion in ret_from_exception

[Jan Kiszka]

On return from exception, we want to check if the current context is
root or head to take the fast exit in the latter case. TIP_HEAD is set
then, thus we have to check for 'ne' (Z==0) after tst.

This affects only non-legacy users.

Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
---

This is for 3.14, but it should equally well apply to 3.16. Fixes both
sigdebug test as well as the weird sshd deaths on the virtual vexpress
target.

 arch/arm/kernel/entry-armv.S | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/kernel/entry-armv.S b/arch/arm/kernel/entry-armv.S
index a608340..f6ef839 100644
--- a/arch/arm/kernel/entry-armv.S
+++ b/arch/arm/kernel/entry-armv.S
@@ -736,8 +736,8 @@ ENTRY(ret_from_exception)
 	get_thread_info tsk
 	ldr	r0, [tsk, #TI_IPIPE]
 	tst	r0, #_TIP_HEAD
- THUMB(	it eq)
-	beq	__ipipe_ret_to_user_irqs_disabled  @ Fast exit path over non-root domains
+ THUMB(	it ne)
+	bne	__ipipe_ret_to_user_irqs_disabled  @ Fast exit path over non-root domains
 #endif /* !CONFIG_IPIPE_LEGACY */
 #else /* !CONFIG_IPIPE */
 	get_thread_info tsk
-- 
2.1.4

Re: [Xenomai] [PATCH] arm/ipipe: Fix logical inversion in ret_from_exception

[Gilles Chanteperdrix]

On Thu, Feb 19, 2015 at 03:32:14PM +0100, Jan Kiszka wrote:
> On return from exception, we want to check if the current context is
> root or head to take the fast exit in the latter case. TIP_HEAD is set
> then, thus we have to check for 'ne' (Z==0) after tst.
> 
> This affects only non-legacy users.
> 
> Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
> ---
> 
> This is for 3.14, but it should equally well apply to 3.16. Fixes both
> sigdebug test as well as the weird sshd deaths on the virtual vexpress
> target.
> 
>  arch/arm/kernel/entry-armv.S | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/arm/kernel/entry-armv.S b/arch/arm/kernel/entry-armv.S
> index a608340..f6ef839 100644
> --- a/arch/arm/kernel/entry-armv.S
> +++ b/arch/arm/kernel/entry-armv.S
> @@ -736,8 +736,8 @@ ENTRY(ret_from_exception)
>  	get_thread_info tsk
>  	ldr	r0, [tsk, #TI_IPIPE]
>  	tst	r0, #_TIP_HEAD
> - THUMB(	it eq)
> -	beq	__ipipe_ret_to_user_irqs_disabled  @ Fast exit path over non-root domains
> + THUMB(	it ne)
> +	bne	__ipipe_ret_to_user_irqs_disabled  @ Fast exit path
> over non-root domains

Mmm. Looks suspicious. The semantics of the PSR flags with tst is
contrary to to what one would believe. No, from compiling a small
example, it would seem you are right.

-- 
					    Gilles.

Re: [Xenomai] [PATCH] arm/ipipe: Fix logical inversion in ret_from_exception

[Jan Kiszka]

On 2015-02-19 15:40, Gilles Chanteperdrix wrote:
> On Thu, Feb 19, 2015 at 03:32:14PM +0100, Jan Kiszka wrote:
>> On return from exception, we want to check if the current context is
>> root or head to take the fast exit in the latter case. TIP_HEAD is set
>> then, thus we have to check for 'ne' (Z==0) after tst.
>>
>> This affects only non-legacy users.
>>
>> Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
>> ---
>>
>> This is for 3.14, but it should equally well apply to 3.16. Fixes both
>> sigdebug test as well as the weird sshd deaths on the virtual vexpress
>> target.
>>
>>  arch/arm/kernel/entry-armv.S | 4 ++--
>>  1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/arch/arm/kernel/entry-armv.S b/arch/arm/kernel/entry-armv.S
>> index a608340..f6ef839 100644
>> --- a/arch/arm/kernel/entry-armv.S
>> +++ b/arch/arm/kernel/entry-armv.S
>> @@ -736,8 +736,8 @@ ENTRY(ret_from_exception)
>>  	get_thread_info tsk
>>  	ldr	r0, [tsk, #TI_IPIPE]
>>  	tst	r0, #_TIP_HEAD
>> - THUMB(	it eq)
>> -	beq	__ipipe_ret_to_user_irqs_disabled  @ Fast exit path over non-root domains
>> + THUMB(	it ne)
>> +	bne	__ipipe_ret_to_user_irqs_disabled  @ Fast exit path
>> over non-root domains
> 
> Mmm. Looks suspicious. The semantics of the PSR flags with tst is
> contrary to to what one would believe. No, from compiling a small
> example, it would seem you are right.

It took me a while to confirm this as well: 'tst' is 'and' without
writeback. "val & FLAG" gives non-zero if FLAG is set in val. Non-zero
(Z==0) is tested by 'ne'.

On x86, there are these nice jnz/jz aliases for that purpose.

Jan

-- 
Siemens AG, Corporate Technology, CT RTC ITP SES-DE
Corporate Competence Center Embedded Linux

Re: [Xenomai] [PATCH] arm/ipipe: Fix logical inversion in ret_from_exception

[Gilles Chanteperdrix]

On Thu, Feb 19, 2015 at 03:43:27PM +0100, Jan Kiszka wrote:
> On 2015-02-19 15:40, Gilles Chanteperdrix wrote:
> > On Thu, Feb 19, 2015 at 03:32:14PM +0100, Jan Kiszka wrote:
> >> On return from exception, we want to check if the current context is
> >> root or head to take the fast exit in the latter case. TIP_HEAD is set
> >> then, thus we have to check for 'ne' (Z==0) after tst.
> >>
> >> This affects only non-legacy users.
> >>
> >> Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
> >> ---
> >>
> >> This is for 3.14, but it should equally well apply to 3.16. Fixes both
> >> sigdebug test as well as the weird sshd deaths on the virtual vexpress
> >> target.
> >>
> >>  arch/arm/kernel/entry-armv.S | 4 ++--
> >>  1 file changed, 2 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/arch/arm/kernel/entry-armv.S b/arch/arm/kernel/entry-armv.S
> >> index a608340..f6ef839 100644
> >> --- a/arch/arm/kernel/entry-armv.S
> >> +++ b/arch/arm/kernel/entry-armv.S
> >> @@ -736,8 +736,8 @@ ENTRY(ret_from_exception)
> >>  	get_thread_info tsk
> >>  	ldr	r0, [tsk, #TI_IPIPE]
> >>  	tst	r0, #_TIP_HEAD
> >> - THUMB(	it eq)
> >> -	beq	__ipipe_ret_to_user_irqs_disabled  @ Fast exit path over non-root domains
> >> + THUMB(	it ne)
> >> +	bne	__ipipe_ret_to_user_irqs_disabled  @ Fast exit path
> >> over non-root domains
> > 
> > Mmm. Looks suspicious. The semantics of the PSR flags with tst is
> > contrary to to what one would believe. No, from compiling a small
> > example, it would seem you are right.
> 
> It took me a while to confirm this as well: 'tst' is 'and' without
> writeback. "val & FLAG" gives non-zero if FLAG is set in val. Non-zero
> (Z==0) is tested by 'ne'.
> 
> On x86, there are these nice jnz/jz aliases for that purpose.

My check is:

int f(int x)
{
	if (x & 1)
		return 42;
	
	return -123;
}

Which gives:
00000000 <f>:
   0:   e3100001        tst     r0, #1
   4:   03e0007a        mvneq   r0, #122        ; 0x7a
   8:   13a0002a        movne   r0, #42 ; 0x2a
   c:   e12fff1e        bx      lr

I am almost sure I did something similar before wrting the assembly,
well, I screwed up, sorry.

-- 
					    Gilles.

Re: [Xenomai] arm: Late delivery of pending Linux signals?

[Lennart Sorensen]

On Wed, Feb 18, 2015 at 09:49:56PM +0100, Jan Kiszka wrote:
> No need to worry, it mostly just works. Apparently, I-pipe already
> covers the whole Cortex-A series with its unified timers, clocks, and
> interrupt controllers. Well, with the exception of SoCs that have
> additional interrupt controllers - like the NVIDIA Tegra124, which I'm
> currently looking at for other purposes.
> 
> "Mostly" because sshd is dying for unknown reasons. Same rootfs, same
> emulator but newer kernel without I-pipe, and it works fine. One after
> the other.
> 
> BTW, I noticed that LPAE build is broken. Trivial to fix (missing
> argument to cpu_switch_mm), but maybe there is more behind it as it was
> not used so far. Anything mm-related that one has to look at carefully
> on ARM(v7)?

LPAE support at all is very new, and not used by very many people yet.

Is it broken on 2.6 or 3.0 or both?

-- 
Len Sorensen

Re: [Xenomai] arm: Late delivery of pending Linux signals?

[Lennart Sorensen]

On Thu, Feb 19, 2015 at 10:13:27AM -0500, Lennart Sorensen wrote:
> LPAE support at all is very new, and not used by very many people yet.
> 
> Is it broken on 2.6 or 3.0 or both?

OK that was a dumb question, given it is ipipe not xenomai related and
hence xenomai version isn't relevant.

-- 
Len Sorensen

Re: [Xenomai] arm: Late delivery of pending Linux signals?

[Philippe Gerum]

On 02/19/2015 04:13 PM, Lennart Sorensen wrote:
> On Wed, Feb 18, 2015 at 09:49:56PM +0100, Jan Kiszka wrote:
>> No need to worry, it mostly just works. Apparently, I-pipe already
>> covers the whole Cortex-A series with its unified timers, clocks, and
>> interrupt controllers. Well, with the exception of SoCs that have
>> additional interrupt controllers - like the NVIDIA Tegra124, which I'm
>> currently looking at for other purposes.
>>
>> "Mostly" because sshd is dying for unknown reasons. Same rootfs, same
>> emulator but newer kernel without I-pipe, and it works fine. One after
>> the other.
>>
>> BTW, I noticed that LPAE build is broken. Trivial to fix (missing
>> argument to cpu_switch_mm), but maybe there is more behind it as it was
>> not used so far. Anything mm-related that one has to look at carefully
>> on ARM(v7)?
> 
> LPAE support at all is very new, and not used by very many people yet.
> 
> Is it broken on 2.6 or 3.0 or both?
> 

I's not about LPAE being broken, it is about building with LPAE enabled
on a backport of my LPAE fixes to the stock pipelines, due to some
conflict with the FCSE changes. I dropped FCSE from the working tree for
LPAE fixes, since the former is not relevant on armv7 with VIPT caches
anyway.

-- 
Philippe.

Re: [Xenomai] arm: Late delivery of pending Linux signals?

[Lennart Sorensen]

On Thu, Feb 19, 2015 at 06:13:57PM +0100, Philippe Gerum wrote:
> I's not about LPAE being broken, it is about building with LPAE enabled
> on a backport of my LPAE fixes to the stock pipelines, due to some
> conflict with the FCSE changes. I dropped FCSE from the working tree for
> LPAE fixes, since the former is not relevant on armv7 with VIPT caches
> anyway.

Oh right.  I had forgotten about the FCSE code being dropped out of
that version.  Never have had any system that could use FCSE so I didn't
look at it much.

-- 
Len Sorensen