Re: [Xenomai] Hung task on Xenomai patched ARM 3.8.13 BeagleBone Kernel

[Ralf Roesch <xenomai@cantastic.org>]

On Thu Oct 17 2013 14:39:37 GMT+0200, Charles Steinkuehler 
<charles@steinkuehler.net>  wrote:
> On 10/17/2013 4:29 AM, Gilles Chanteperdrix wrote:
>> On 10/17/2013 02:58 AM, Charles Steinkuehler wrote:
>>> On 10/16/2013 2:41 PM, Charles Steinkuehler wrote:
>>>> On 10/16/2013 11:12 AM, Charles Steinkuehler wrote:
>>>>> I'll test with ipipe disabled, go through the Arm Porting guide, and
>>>>> see
>>>>> where that gets me...
>>>> After building a patched kernel without ipipe or xenomai enabled:
>>>>
>>>> $ egrep '(IPIPE|XENO)' KERNEL/.config
>>>> # CONFIG_XENOMAI is not set
>>>> CONFIG_XENO_GENERIC_STACKPOOL=y
>>>> CONFIG_XENO_FASTSYNCH_DEP=y
>>>> CONFIG_XENO_FASTSYNCH=y
>>>> # CONFIG_IPIPE is not set
>>>>
>>>> ...the mmc issue seems fixed.  So according to the porting guide, this
>>>> indicates a likely problem with interrupts or the interrupt controller
>>>> (as Gilles indicated).
>>> Based on the ARM porting guide, the first thing I did was to disable IRQ
>>> muting by simply commenting out the two calls to:
>>>
>>>     ipipe_pic_muter_register
>>>
>>> ...in<linux>/drivers/gpio/gpio-omap.c
>>>
>>> This results in a kernel that DOES NOT HANG with ipipe enabled!
>> It does not really make sense: when I-pipe is enabled but Xenomai
>> disabled, the PIC muting is only used to tweak the interrupt controller
>> priority. Since there are only secondary mode irqs, they all should use
>> the same priority.
> I am confused as well, particularly by the fact that adding back the
> xenomai patches (but leaving the gpio IRQ masking disabled) gets me back
> to the hung mmc task.
>
>> Is arch/arm/mach-omap2/irq.c modified by the BeagleBone patches, if yes,
>> could you put the modified version somewhere I could have a look at it?
> The minor patch to the irq file doesn't seem likely to cause problems,
> but there is a *LOT* of mmc driver code that is changed between mainline
> and the BeagleBone kernel, much of it related to DMA.
If I got it it right the device tree handling is also complete new ( 
arch / arm / boot / dts /)  compared to mainline?
If so, the enhanced DMA (edma) should also be taken into account ?
--
Ralf
> I've put up my full kernel build tree in case you want to look at any
> other files.  The top directory is the scripts and patches used to build
> the kernel.  The actual kernel code already patched with the BeagleBone
> patch set as well as ipipe and xenomai is in the KERNEL directory:
>
> http://morpheus.steinkuehler.net/xenomai
>
> Are the xenomai patches similar to the preempt-rt patch set in that they
> can expose underlying flaws in driver code that is not SMP clean?
>
> If so, I suspect something with the mmc and dma updates specific to the
> BeagleBone patch set.  Maybe I should be pestering the OMAP kernel list?
>