Re: ipipe 5.4.107 / 5.4.93 build issues on arm32

[Greg Gallagher via Xenomai]

On Thu, Apr 15, 2021 at 8:44 AM Jan Kiszka  wrote:

> On 15.04.21 14:09, Greg Gallagher wrote:
> >
> >
> > On Thu, Apr 15, 2021 at 2:59 AM Jan Kiszka  > > wrote:
> >
> > On 15.04.21 07:35, Greg Gallagher via Xenomai wrote:
> > > On Wed, Apr 14, 2021 at 7:43 PM steve freyder  > > wrote:
> > >
> > >> On 4/14/2021 4:50 PM, Greg Gallagher via Xenomai wrote:
> > >>
> > >> On Wed, Apr 14, 2021 at 4:52 PM Thomas Petazzoni
> > mailto:thomas.petazz...@bootlin.com>>
> > wrote:
> > >>
> > >>
> > >> On Wed, 14 Apr 2021 14:41:29 -0400
> > >> Greg Gallagher  > >  > > wrote:
> > >>
> > >>
> > >> Ipipe 5.4 and xenomai 3.1 are compatible, this is my mistake,
> > I’ll fix up
> > >> and generate a new patch once the latency fix is done.
> > >> FWIW, building straight from the ipipe-arm repo on the
> > ipipe/5.4.y branch
> > >> has been working for me.
> > >>
> > >> I'm afraid the HEAD of ipipe/5.4.y as of commit
> > >> ffaf274ca4cc117c2dc3f9b2ee8ea6218b50995a doesn't build for me.
> I'm on
> > >> this commit + I have prepared the kernel using Xenomai 3.1
> > >> ./scripts/prepare-kernel.sh --linux=/path/to/kernel + kernel
> > configured
> > >> with sama5_defconfig.
> > >>
> > >> And same build failure:
> > >>
> > >> In file included from kernel/cpu.c:23:0:
> > >> ./include/linux/stop_machine.h: In function
> > ‘stop_machine_cpuslocked’:
> > >> ./include/linux/stop_machine.h:150:2: error: implicit declaration
> of
> > >> function ‘hard_irq_enable’; did you mean ‘hard_irq_disable’?
> > >> [-Werror=implicit-function-declaration]
> > >>   hard_irq_enable();
> > >>   ^~~
> > >>   hard_irq_disable
> > >>
> > >> Best regards,
> > >>
> > >> Thomas
> > >> --
> > >> Thomas Petazzoni, co-owner and CEO, Bootlin
> > >> Embedded Linux and Kernel engineeringhttps://bootlin.com
> > 
> > >>
> > >> I'll dig into this tonight, I usually test with
> > multi_v7_defconfig and it
> > >> seems to build fine with ipipe 5.4 and Xenomai 3.1.  I'll test
> with
> > >> sama5_defconfig.
> > >>
> > >> Thanks
> > >>
> > >> Greg
> > >>
> > >> Greg,
> > >>
> > >>
> > >> We are also having issues with ARM32 (armv7-a) with this build
> genre
> > >> (5.4.107 + Xenomai 3.1 stable) and the e1000e driver.  The build
> > completes
> > >> without compile/link errors, but when booting we're getting a
> > kernel stack
> > >> dump (upon an ifup of the e1000e interface) that's indicating a
> > problem
> > >> with enabling interrupts at a point where interrupts are not
> > supposed to be
> > >> enabled.  We're not seeing a lot of changes to the e1000e tree
> since
> > >> 4.14.85 (last release we know of where the driver was working
> > properly), so
> > >> we suspected it might be something in Linux or ipipe.  We know
> > that e1000e
> > >> seems to work properly with kernel 5.4.107 (non-Xenomai/ipipe
> build).
> > >>
> > >>
> > >> I wonder, do you have access to an ARMV7 system that has an
> > e1000e NIC?
> > >> If so, I wonder could you add an e1000e driver to your modules
> > build and
> > >> see if you get the same stack trace we're getting?  Below is the
> > original
> > >> post I did on this (on 03/15/2021).  We suspect that e1000e
> > doesn't fly on
> > >> any armv7 5.4.107+Xenomai 3.1/stable build.  Naturally we'll be
> > happy to
> > >> test any patches related to these issues.
> > >>
> > >> Best regards,
> > >>
> > >> Steve
> > >>
> > >>
> > >> --
> > >> Greetings Xenomai list,
> > >>
> > >>
> > >> We are seeing the following stack trace when we 'ifup' the e1000e
> > >> adapter.  4.19 exhibits same failure, 4.14.96 also fails but with
> a
> > >> different stack trace.  Last working version is 4.14.85.
> > >>
> > >> Thanks in advance for any assist,
> > >>
> > >> Steve
> > >>
> > >>
> >
>  
> > >>
> > >> [   47.635779] [ cut here ]
> > >> [   47.637083] ip (658) used greatest stack depth: 3960 bytes left
> > >> [   47.640416] WARNING: CPU: 0 PID: 0 at kernel/ipipe/core.c:1968
> > >> __ipipe_spin_unlock_debug+0x50/0x5c
> > >> [   47.655297] Modules linked in: xeno_gpio_mxc e1000e
> > >> [   47.660198] CPU: 0 PID: 0 Comm: swapper/0 Not tainted
> > >> 5.4.93-00202-g1070d76ae3f5-dirty #7
> > >> [   47.668386] Hardware name: Freescale i.MX6 Quad/DualLite
> > (Device Tree)
> > >> [   47.674923] I-pipe domain: Linux
> > >> 

Re: ipipe 5.4.107 / 5.4.93 build issues on arm32

[Jan Kiszka via Xenomai]

On 15.04.21 14:09, Greg Gallagher wrote:
> 
> 
> On Thu, Apr 15, 2021 at 2:59 AM Jan Kiszka  > wrote:
> 
> On 15.04.21 07:35, Greg Gallagher via Xenomai wrote:
> > On Wed, Apr 14, 2021 at 7:43 PM steve freyder  > wrote:
> >
> >> On 4/14/2021 4:50 PM, Greg Gallagher via Xenomai wrote:
> >>
> >> On Wed, Apr 14, 2021 at 4:52 PM Thomas Petazzoni
> mailto:thomas.petazz...@bootlin.com>>
> wrote:
> >>
> >>
> >> On Wed, 14 Apr 2021 14:41:29 -0400
> >> Greg Gallagher  >  > wrote:
> >>
> >>
> >> Ipipe 5.4 and xenomai 3.1 are compatible, this is my mistake,
> I’ll fix up
> >> and generate a new patch once the latency fix is done.
> >> FWIW, building straight from the ipipe-arm repo on the
> ipipe/5.4.y branch
> >> has been working for me.
> >>
> >> I'm afraid the HEAD of ipipe/5.4.y as of commit
> >> ffaf274ca4cc117c2dc3f9b2ee8ea6218b50995a doesn't build for me. I'm on
> >> this commit + I have prepared the kernel using Xenomai 3.1
> >> ./scripts/prepare-kernel.sh --linux=/path/to/kernel + kernel
> configured
> >> with sama5_defconfig.
> >>
> >> And same build failure:
> >>
> >> In file included from kernel/cpu.c:23:0:
> >> ./include/linux/stop_machine.h: In function
> ‘stop_machine_cpuslocked’:
> >> ./include/linux/stop_machine.h:150:2: error: implicit declaration of
> >> function ‘hard_irq_enable’; did you mean ‘hard_irq_disable’?
> >> [-Werror=implicit-function-declaration]
> >>   hard_irq_enable();
> >>   ^~~
> >>   hard_irq_disable
> >>
> >> Best regards,
> >>
> >> Thomas
> >> --
> >> Thomas Petazzoni, co-owner and CEO, Bootlin
> >> Embedded Linux and Kernel engineeringhttps://bootlin.com
> 
> >>
> >> I'll dig into this tonight, I usually test with
> multi_v7_defconfig and it
> >> seems to build fine with ipipe 5.4 and Xenomai 3.1.  I'll test with
> >> sama5_defconfig.
> >>
> >> Thanks
> >>
> >> Greg
> >>
> >> Greg,
> >>
> >>
> >> We are also having issues with ARM32 (armv7-a) with this build genre
> >> (5.4.107 + Xenomai 3.1 stable) and the e1000e driver.  The build
> completes
> >> without compile/link errors, but when booting we're getting a
> kernel stack
> >> dump (upon an ifup of the e1000e interface) that's indicating a
> problem
> >> with enabling interrupts at a point where interrupts are not
> supposed to be
> >> enabled.  We're not seeing a lot of changes to the e1000e tree since
> >> 4.14.85 (last release we know of where the driver was working
> properly), so
> >> we suspected it might be something in Linux or ipipe.  We know
> that e1000e
> >> seems to work properly with kernel 5.4.107 (non-Xenomai/ipipe build).
> >>
> >>
> >> I wonder, do you have access to an ARMV7 system that has an
> e1000e NIC?
> >> If so, I wonder could you add an e1000e driver to your modules
> build and
> >> see if you get the same stack trace we're getting?  Below is the
> original
> >> post I did on this (on 03/15/2021).  We suspect that e1000e
> doesn't fly on
> >> any armv7 5.4.107+Xenomai 3.1/stable build.  Naturally we'll be
> happy to
> >> test any patches related to these issues.
> >>
> >> Best regards,
> >>
> >> Steve
> >>
> >>
> >> --
> >> Greetings Xenomai list,
> >>
> >>
> >> We are seeing the following stack trace when we 'ifup' the e1000e
> >> adapter.  4.19 exhibits same failure, 4.14.96 also fails but with a
> >> different stack trace.  Last working version is 4.14.85.
> >>
> >> Thanks in advance for any assist,
> >>
> >> Steve
> >>
> >>
> 
> >>
> >> [   47.635779] [ cut here ]
> >> [   47.637083] ip (658) used greatest stack depth: 3960 bytes left
> >> [   47.640416] WARNING: CPU: 0 PID: 0 at kernel/ipipe/core.c:1968
> >> __ipipe_spin_unlock_debug+0x50/0x5c
> >> [   47.655297] Modules linked in: xeno_gpio_mxc e1000e
> >> [   47.660198] CPU: 0 PID: 0 Comm: swapper/0 Not tainted
> >> 5.4.93-00202-g1070d76ae3f5-dirty #7
> >> [   47.668386] Hardware name: Freescale i.MX6 Quad/DualLite
> (Device Tree)
> >> [   47.674923] I-pipe domain: Linux
> >> [   47.678159] Backtrace:
> >> [   47.680620] [<80992f10>] (dump_backtrace) from [<8099328c>]
> >> (show_stack+0x20/0x24)
> >> [   47.688199]  r7:81238180 r6:0080 r5: r4:811a66f0
> >> [   47.693867] [<8099326c>] (show_stack) from [<8099cac0>]
> >> (dump_stack+0xf4/0x128)
> >> [   

Re: ipipe 5.4.107 / 5.4.93 build issues on arm32

[Greg Gallagher via Xenomai]

On Thu, Apr 15, 2021 at 2:59 AM Jan Kiszka  wrote:

> On 15.04.21 07:35, Greg Gallagher via Xenomai wrote:
> > On Wed, Apr 14, 2021 at 7:43 PM steve freyder  wrote:
> >
> >> On 4/14/2021 4:50 PM, Greg Gallagher via Xenomai wrote:
> >>
> >> On Wed, Apr 14, 2021 at 4:52 PM Thomas Petazzoni <
> thomas.petazz...@bootlin.com> wrote:
> >>
> >>
> >> On Wed, 14 Apr 2021 14:41:29 -0400
> >> Greg Gallagher   wrote:
> >>
> >>
> >> Ipipe 5.4 and xenomai 3.1 are compatible, this is my mistake, I’ll fix
> up
> >> and generate a new patch once the latency fix is done.
> >> FWIW, building straight from the ipipe-arm repo on the ipipe/5.4.y
> branch
> >> has been working for me.
> >>
> >> I'm afraid the HEAD of ipipe/5.4.y as of commit
> >> ffaf274ca4cc117c2dc3f9b2ee8ea6218b50995a doesn't build for me. I'm on
> >> this commit + I have prepared the kernel using Xenomai 3.1
> >> ./scripts/prepare-kernel.sh --linux=/path/to/kernel + kernel configured
> >> with sama5_defconfig.
> >>
> >> And same build failure:
> >>
> >> In file included from kernel/cpu.c:23:0:
> >> ./include/linux/stop_machine.h: In function ‘stop_machine_cpuslocked’:
> >> ./include/linux/stop_machine.h:150:2: error: implicit declaration of
> >> function ‘hard_irq_enable’; did you mean ‘hard_irq_disable’?
> >> [-Werror=implicit-function-declaration]
> >>   hard_irq_enable();
> >>   ^~~
> >>   hard_irq_disable
> >>
> >> Best regards,
> >>
> >> Thomas
> >> --
> >> Thomas Petazzoni, co-owner and CEO, Bootlin
> >> Embedded Linux and Kernel engineeringhttps://bootlin.com
> >>
> >> I'll dig into this tonight, I usually test with multi_v7_defconfig and
> it
> >> seems to build fine with ipipe 5.4 and Xenomai 3.1.  I'll test with
> >> sama5_defconfig.
> >>
> >> Thanks
> >>
> >> Greg
> >>
> >> Greg,
> >>
> >>
> >> We are also having issues with ARM32 (armv7-a) with this build genre
> >> (5.4.107 + Xenomai 3.1 stable) and the e1000e driver.  The build
> completes
> >> without compile/link errors, but when booting we're getting a kernel
> stack
> >> dump (upon an ifup of the e1000e interface) that's indicating a problem
> >> with enabling interrupts at a point where interrupts are not supposed
> to be
> >> enabled.  We're not seeing a lot of changes to the e1000e tree since
> >> 4.14.85 (last release we know of where the driver was working
> properly), so
> >> we suspected it might be something in Linux or ipipe.  We know that
> e1000e
> >> seems to work properly with kernel 5.4.107 (non-Xenomai/ipipe build).
> >>
> >>
> >> I wonder, do you have access to an ARMV7 system that has an e1000e NIC?
> >> If so, I wonder could you add an e1000e driver to your modules build and
> >> see if you get the same stack trace we're getting?  Below is the
> original
> >> post I did on this (on 03/15/2021).  We suspect that e1000e doesn't fly
> on
> >> any armv7 5.4.107+Xenomai 3.1/stable build.  Naturally we'll be happy to
> >> test any patches related to these issues.
> >>
> >> Best regards,
> >>
> >> Steve
> >>
> >>
> >> --
> >> Greetings Xenomai list,
> >>
> >>
> >> We are seeing the following stack trace when we 'ifup' the e1000e
> >> adapter.  4.19 exhibits same failure, 4.14.96 also fails but with a
> >> different stack trace.  Last working version is 4.14.85.
> >>
> >> Thanks in advance for any assist,
> >>
> >> Steve
> >>
> >> 
> >>
> >> [   47.635779] [ cut here ]
> >> [   47.637083] ip (658) used greatest stack depth: 3960 bytes left
> >> [   47.640416] WARNING: CPU: 0 PID: 0 at kernel/ipipe/core.c:1968
> >> __ipipe_spin_unlock_debug+0x50/0x5c
> >> [   47.655297] Modules linked in: xeno_gpio_mxc e1000e
> >> [   47.660198] CPU: 0 PID: 0 Comm: swapper/0 Not tainted
> >> 5.4.93-00202-g1070d76ae3f5-dirty #7
> >> [   47.668386] Hardware name: Freescale i.MX6 Quad/DualLite (Device
> Tree)
> >> [   47.674923] I-pipe domain: Linux
> >> [   47.678159] Backtrace:
> >> [   47.680620] [<80992f10>] (dump_backtrace) from [<8099328c>]
> >> (show_stack+0x20/0x24)
> >> [   47.688199]  r7:81238180 r6:0080 r5: r4:811a66f0
> >> [   47.693867] [<8099326c>] (show_stack) from [<8099cac0>]
> >> (dump_stack+0xf4/0x128)
> >> [   47.701184] [<8099c9cc>] (dump_stack) from [<8012ba1c>]
> >> (__warn+0xd0/0x108)
> >> [   47.708154]  r9: r8:0009 r7:07b0 r6:801e1448
> >> r5:0009 r4:80c02be0
> >> [   47.715905] [<8012b94c>] (__warn) from [<809942b8>]
> >> (warn_slowpath_fmt+0x6c/0xc4)
> >> [   47.723396]  r7:801e1448 r6:07b0 r5:80c02be0 r4:
> >> [   47.729065] [<80994250>] (warn_slowpath_fmt) from [<801e1448>]
> >> (__ipipe_spin_unlock_debug+0x50/0x5c)
> >> [   47.738206]  r8: r7: r6:9d6c r5:bf54b4c0
> >> r4:bd354580
> >> [   47.744917] [<801e13f8>] (__ipipe_spin_unlock_debug) from
> [<801a2d90>]
> >> (mod_timer+0x190/0x400)
> >> [   47.753537] [<801a2c00>] (mod_timer) from [<7f01a5b8>]
> >> 

Re: ipipe 5.4.107 / 5.4.93 build issues on arm32

[Jan Kiszka via Xenomai]

On 15.04.21 07:35, Greg Gallagher via Xenomai wrote:
> On Wed, Apr 14, 2021 at 7:43 PM steve freyder  wrote:
> 
>> On 4/14/2021 4:50 PM, Greg Gallagher via Xenomai wrote:
>>
>> On Wed, Apr 14, 2021 at 4:52 PM Thomas Petazzoni 
>>  wrote:
>>
>>
>> On Wed, 14 Apr 2021 14:41:29 -0400
>> Greg Gallagher   wrote:
>>
>>
>> Ipipe 5.4 and xenomai 3.1 are compatible, this is my mistake, I’ll fix up
>> and generate a new patch once the latency fix is done.
>> FWIW, building straight from the ipipe-arm repo on the ipipe/5.4.y branch
>> has been working for me.
>>
>> I'm afraid the HEAD of ipipe/5.4.y as of commit
>> ffaf274ca4cc117c2dc3f9b2ee8ea6218b50995a doesn't build for me. I'm on
>> this commit + I have prepared the kernel using Xenomai 3.1
>> ./scripts/prepare-kernel.sh --linux=/path/to/kernel + kernel configured
>> with sama5_defconfig.
>>
>> And same build failure:
>>
>> In file included from kernel/cpu.c:23:0:
>> ./include/linux/stop_machine.h: In function ‘stop_machine_cpuslocked’:
>> ./include/linux/stop_machine.h:150:2: error: implicit declaration of
>> function ‘hard_irq_enable’; did you mean ‘hard_irq_disable’?
>> [-Werror=implicit-function-declaration]
>>   hard_irq_enable();
>>   ^~~
>>   hard_irq_disable
>>
>> Best regards,
>>
>> Thomas
>> --
>> Thomas Petazzoni, co-owner and CEO, Bootlin
>> Embedded Linux and Kernel engineeringhttps://bootlin.com
>>
>> I'll dig into this tonight, I usually test with multi_v7_defconfig and it
>> seems to build fine with ipipe 5.4 and Xenomai 3.1.  I'll test with
>> sama5_defconfig.
>>
>> Thanks
>>
>> Greg
>>
>> Greg,
>>
>>
>> We are also having issues with ARM32 (armv7-a) with this build genre
>> (5.4.107 + Xenomai 3.1 stable) and the e1000e driver.  The build completes
>> without compile/link errors, but when booting we're getting a kernel stack
>> dump (upon an ifup of the e1000e interface) that's indicating a problem
>> with enabling interrupts at a point where interrupts are not supposed to be
>> enabled.  We're not seeing a lot of changes to the e1000e tree since
>> 4.14.85 (last release we know of where the driver was working properly), so
>> we suspected it might be something in Linux or ipipe.  We know that e1000e
>> seems to work properly with kernel 5.4.107 (non-Xenomai/ipipe build).
>>
>>
>> I wonder, do you have access to an ARMV7 system that has an e1000e NIC?
>> If so, I wonder could you add an e1000e driver to your modules build and
>> see if you get the same stack trace we're getting?  Below is the original
>> post I did on this (on 03/15/2021).  We suspect that e1000e doesn't fly on
>> any armv7 5.4.107+Xenomai 3.1/stable build.  Naturally we'll be happy to
>> test any patches related to these issues.
>>
>> Best regards,
>>
>> Steve
>>
>>
>> --
>> Greetings Xenomai list,
>>
>>
>> We are seeing the following stack trace when we 'ifup' the e1000e
>> adapter.  4.19 exhibits same failure, 4.14.96 also fails but with a
>> different stack trace.  Last working version is 4.14.85.
>>
>> Thanks in advance for any assist,
>>
>> Steve
>>
>> 
>>
>> [   47.635779] [ cut here ]
>> [   47.637083] ip (658) used greatest stack depth: 3960 bytes left
>> [   47.640416] WARNING: CPU: 0 PID: 0 at kernel/ipipe/core.c:1968
>> __ipipe_spin_unlock_debug+0x50/0x5c
>> [   47.655297] Modules linked in: xeno_gpio_mxc e1000e
>> [   47.660198] CPU: 0 PID: 0 Comm: swapper/0 Not tainted
>> 5.4.93-00202-g1070d76ae3f5-dirty #7
>> [   47.668386] Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree)
>> [   47.674923] I-pipe domain: Linux
>> [   47.678159] Backtrace:
>> [   47.680620] [<80992f10>] (dump_backtrace) from [<8099328c>]
>> (show_stack+0x20/0x24)
>> [   47.688199]  r7:81238180 r6:0080 r5: r4:811a66f0
>> [   47.693867] [<8099326c>] (show_stack) from [<8099cac0>]
>> (dump_stack+0xf4/0x128)
>> [   47.701184] [<8099c9cc>] (dump_stack) from [<8012ba1c>]
>> (__warn+0xd0/0x108)
>> [   47.708154]  r9: r8:0009 r7:07b0 r6:801e1448
>> r5:0009 r4:80c02be0
>> [   47.715905] [<8012b94c>] (__warn) from [<809942b8>]
>> (warn_slowpath_fmt+0x6c/0xc4)
>> [   47.723396]  r7:801e1448 r6:07b0 r5:80c02be0 r4:
>> [   47.729065] [<80994250>] (warn_slowpath_fmt) from [<801e1448>]
>> (__ipipe_spin_unlock_debug+0x50/0x5c)
>> [   47.738206]  r8: r7: r6:9d6c r5:bf54b4c0
>> r4:bd354580
>> [   47.744917] [<801e13f8>] (__ipipe_spin_unlock_debug) from [<801a2d90>]
>> (mod_timer+0x190/0x400)
>> [   47.753537] [<801a2c00>] (mod_timer) from [<7f01a5b8>]
>> (e1000_msix_other+0xac/0xb8 [e1000e])
>> [   47.761984]  r10:80e748d4 r9:0001 r8:81101d78 r7:0137
>> r6:bd3549e4 r5:8104
>> [   47.769822]  r4:bd354000
>> [   47.772365] [<7f01a50c>] (e1000_msix_other [e1000e]) from [<801859b8>]
>> (__handle_irq_event_percpu+0x64/0x240)
>> [   47.782289]  r7:0137 r6: r5:bd23e870 r4:bc09aa80
>> [   

Re: ipipe 5.4.107 / 5.4.93 build issues on arm32

[Greg Gallagher via Xenomai]

On Wed, Apr 14, 2021 at 7:43 PM steve freyder  wrote:

> On 4/14/2021 4:50 PM, Greg Gallagher via Xenomai wrote:
>
> On Wed, Apr 14, 2021 at 4:52 PM Thomas Petazzoni 
>  wrote:
>
>
> On Wed, 14 Apr 2021 14:41:29 -0400
> Greg Gallagher   wrote:
>
>
> Ipipe 5.4 and xenomai 3.1 are compatible, this is my mistake, I’ll fix up
> and generate a new patch once the latency fix is done.
> FWIW, building straight from the ipipe-arm repo on the ipipe/5.4.y branch
> has been working for me.
>
> I'm afraid the HEAD of ipipe/5.4.y as of commit
> ffaf274ca4cc117c2dc3f9b2ee8ea6218b50995a doesn't build for me. I'm on
> this commit + I have prepared the kernel using Xenomai 3.1
> ./scripts/prepare-kernel.sh --linux=/path/to/kernel + kernel configured
> with sama5_defconfig.
>
> And same build failure:
>
> In file included from kernel/cpu.c:23:0:
> ./include/linux/stop_machine.h: In function ‘stop_machine_cpuslocked’:
> ./include/linux/stop_machine.h:150:2: error: implicit declaration of
> function ‘hard_irq_enable’; did you mean ‘hard_irq_disable’?
> [-Werror=implicit-function-declaration]
>   hard_irq_enable();
>   ^~~
>   hard_irq_disable
>
> Best regards,
>
> Thomas
> --
> Thomas Petazzoni, co-owner and CEO, Bootlin
> Embedded Linux and Kernel engineeringhttps://bootlin.com
>
> I'll dig into this tonight, I usually test with multi_v7_defconfig and it
> seems to build fine with ipipe 5.4 and Xenomai 3.1.  I'll test with
> sama5_defconfig.
>
> Thanks
>
> Greg
>
> Greg,
>
>
> We are also having issues with ARM32 (armv7-a) with this build genre
> (5.4.107 + Xenomai 3.1 stable) and the e1000e driver.  The build completes
> without compile/link errors, but when booting we're getting a kernel stack
> dump (upon an ifup of the e1000e interface) that's indicating a problem
> with enabling interrupts at a point where interrupts are not supposed to be
> enabled.  We're not seeing a lot of changes to the e1000e tree since
> 4.14.85 (last release we know of where the driver was working properly), so
> we suspected it might be something in Linux or ipipe.  We know that e1000e
> seems to work properly with kernel 5.4.107 (non-Xenomai/ipipe build).
>
>
> I wonder, do you have access to an ARMV7 system that has an e1000e NIC?
> If so, I wonder could you add an e1000e driver to your modules build and
> see if you get the same stack trace we're getting?  Below is the original
> post I did on this (on 03/15/2021).  We suspect that e1000e doesn't fly on
> any armv7 5.4.107+Xenomai 3.1/stable build.  Naturally we'll be happy to
> test any patches related to these issues.
>
> Best regards,
>
> Steve
>
>
> --
> Greetings Xenomai list,
>
>
> We are seeing the following stack trace when we 'ifup' the e1000e
> adapter.  4.19 exhibits same failure, 4.14.96 also fails but with a
> different stack trace.  Last working version is 4.14.85.
>
> Thanks in advance for any assist,
>
> Steve
>
> 
>
> [   47.635779] [ cut here ]
> [   47.637083] ip (658) used greatest stack depth: 3960 bytes left
> [   47.640416] WARNING: CPU: 0 PID: 0 at kernel/ipipe/core.c:1968
> __ipipe_spin_unlock_debug+0x50/0x5c
> [   47.655297] Modules linked in: xeno_gpio_mxc e1000e
> [   47.660198] CPU: 0 PID: 0 Comm: swapper/0 Not tainted
> 5.4.93-00202-g1070d76ae3f5-dirty #7
> [   47.668386] Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree)
> [   47.674923] I-pipe domain: Linux
> [   47.678159] Backtrace:
> [   47.680620] [<80992f10>] (dump_backtrace) from [<8099328c>]
> (show_stack+0x20/0x24)
> [   47.688199]  r7:81238180 r6:0080 r5: r4:811a66f0
> [   47.693867] [<8099326c>] (show_stack) from [<8099cac0>]
> (dump_stack+0xf4/0x128)
> [   47.701184] [<8099c9cc>] (dump_stack) from [<8012ba1c>]
> (__warn+0xd0/0x108)
> [   47.708154]  r9: r8:0009 r7:07b0 r6:801e1448
> r5:0009 r4:80c02be0
> [   47.715905] [<8012b94c>] (__warn) from [<809942b8>]
> (warn_slowpath_fmt+0x6c/0xc4)
> [   47.723396]  r7:801e1448 r6:07b0 r5:80c02be0 r4:
> [   47.729065] [<80994250>] (warn_slowpath_fmt) from [<801e1448>]
> (__ipipe_spin_unlock_debug+0x50/0x5c)
> [   47.738206]  r8: r7: r6:9d6c r5:bf54b4c0
> r4:bd354580
> [   47.744917] [<801e13f8>] (__ipipe_spin_unlock_debug) from [<801a2d90>]
> (mod_timer+0x190/0x400)
> [   47.753537] [<801a2c00>] (mod_timer) from [<7f01a5b8>]
> (e1000_msix_other+0xac/0xb8 [e1000e])
> [   47.761984]  r10:80e748d4 r9:0001 r8:81101d78 r7:0137
> r6:bd3549e4 r5:8104
> [   47.769822]  r4:bd354000
> [   47.772365] [<7f01a50c>] (e1000_msix_other [e1000e]) from [<801859b8>]
> (__handle_irq_event_percpu+0x64/0x240)
> [   47.782289]  r7:0137 r6: r5:bd23e870 r4:bc09aa80
> [   47.787957] [<80185954>] (__handle_irq_event_percpu) from [<80185bd0>]
> (handle_irq_event_percpu+0x3c/0x98)
> [   47.797618]  r10:80e748d4 r9:0001 r8:81106fe8 r7:c0faf65c
> 

Re: ipipe 5.4.107 / 5.4.93 build issues on arm32

[steve freyder via Xenomai]

On 4/14/2021 4:50 PM, Greg Gallagher via Xenomai wrote:

On Wed, Apr 14, 2021 at 4:52 PM Thomas Petazzoni <
thomas.petazz...@bootlin.com> wrote:


On Wed, 14 Apr 2021 14:41:29 -0400
Greg Gallagher  wrote:


Ipipe 5.4 and xenomai 3.1 are compatible, this is my mistake, I’ll fix up
and generate a new patch once the latency fix is done.
FWIW, building straight from the ipipe-arm repo on the ipipe/5.4.y branch
has been working for me.

I'm afraid the HEAD of ipipe/5.4.y as of commit
ffaf274ca4cc117c2dc3f9b2ee8ea6218b50995a doesn't build for me. I'm on
this commit + I have prepared the kernel using Xenomai 3.1
./scripts/prepare-kernel.sh --linux=/path/to/kernel + kernel configured
with sama5_defconfig.

And same build failure:

In file included from kernel/cpu.c:23:0:
./include/linux/stop_machine.h: In function ‘stop_machine_cpuslocked’:
./include/linux/stop_machine.h:150:2: error: implicit declaration of
function ‘hard_irq_enable’; did you mean ‘hard_irq_disable’?
[-Werror=implicit-function-declaration]
   hard_irq_enable();
   ^~~
   hard_irq_disable

Best regards,

Thomas
--
Thomas Petazzoni, co-owner and CEO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com


I'll dig into this tonight, I usually test with multi_v7_defconfig and it
seems to build fine with ipipe 5.4 and Xenomai 3.1.  I'll test with
sama5_defconfig.

Thanks

Greg


Greg,


We are also having issues with ARM32 (armv7-a) with this build genre 
(5.4.107 + Xenomai 3.1 stable) and the e1000e driver.  The build 
completes without compile/link errors, but when booting we're getting a 
kernel stack dump (upon an ifup of the e1000e interface) that's 
indicating a problem with enabling interrupts at a point where 
interrupts are not supposed to be enabled.  We're not seeing a lot of 
changes to the e1000e tree since 4.14.85 (last release we know of where 
the driver was working properly), so we suspected it might be something 
in Linux or ipipe.  We know that e1000e seems to work properly with 
kernel 5.4.107 (non-Xenomai/ipipe build).



I wonder, do you have access to an ARMV7 system that has an e1000e NIC?  
If so, I wonder could you add an e1000e driver to your modules build and 
see if you get the same stack trace we're getting?  Below is the 
original post I did on this (on 03/15/2021).  We suspect that e1000e 
doesn't fly on any armv7 5.4.107+Xenomai 3.1/stable build.  Naturally 
we'll be happy to test any patches related to these issues.



Best regards,

Steve



Greetings Xenomai list,


We are seeing the following stack trace when we 'ifup' the e1000e 
adapter.  4.19 exhibits same failure, 4.14.96 also fails but with a 
different stack trace.  Last working version is 4.14.85.


Thanks in advance for any assist,

Steve



[   47.635779] [ cut here ]
[   47.637083] ip (658) used greatest stack depth: 3960 bytes left
[   47.640416] WARNING: CPU: 0 PID: 0 at kernel/ipipe/core.c:1968 
__ipipe_spin_unlock_debug+0x50/0x5c

[   47.655297] Modules linked in: xeno_gpio_mxc e1000e
[   47.660198] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 
5.4.93-00202-g1070d76ae3f5-dirty #7

[   47.668386] Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree)
[   47.674923] I-pipe domain: Linux
[   47.678159] Backtrace:
[   47.680620] [<80992f10>] (dump_backtrace) from [<8099328c>] 
(show_stack+0x20/0x24)

[   47.688199]  r7:81238180 r6:0080 r5: r4:811a66f0
[   47.693867] [<8099326c>] (show_stack) from [<8099cac0>] 
(dump_stack+0xf4/0x128)
[   47.701184] [<8099c9cc>] (dump_stack) from [<8012ba1c>] 
(__warn+0xd0/0x108)
[   47.708154]  r9: r8:0009 r7:07b0 r6:801e1448 
r5:0009 r4:80c02be0
[   47.715905] [<8012b94c>] (__warn) from [<809942b8>] 
(warn_slowpath_fmt+0x6c/0xc4)

[   47.723396]  r7:801e1448 r6:07b0 r5:80c02be0 r4:
[   47.729065] [<80994250>] (warn_slowpath_fmt) from [<801e1448>] 
(__ipipe_spin_unlock_debug+0x50/0x5c)

[   47.738206]  r8: r7: r6:9d6c r5:bf54b4c0 r4:bd354580
[   47.744917] [<801e13f8>] (__ipipe_spin_unlock_debug) from 
[<801a2d90>] (mod_timer+0x190/0x400)
[   47.753537] [<801a2c00>] (mod_timer) from [<7f01a5b8>] 
(e1000_msix_other+0xac/0xb8 [e1000e])
[   47.761984]  r10:80e748d4 r9:0001 r8:81101d78 r7:0137 
r6:bd3549e4 r5:8104

[   47.769822]  r4:bd354000
[   47.772365] [<7f01a50c>] (e1000_msix_other [e1000e]) from 
[<801859b8>] (__handle_irq_event_percpu+0x64/0x240)

[   47.782289]  r7:0137 r6: r5:bd23e870 r4:bc09aa80
[   47.787957] [<80185954>] (__handle_irq_event_percpu) from 
[<80185bd0>] (handle_irq_event_percpu+0x3c/0x98)
[   47.797618]  r10:80e748d4 r9:0001 r8:81106fe8 r7:c0faf65c 
r6:bd23e870 r5:bd23e870

[   47.805456]  r4:bd23e800
[   47.807999] [<80185b94>] (handle_irq_event_percpu) from [<80185c74>] 
(handle_irq_event+0x48/0x6c)

[   47.816878] 

Re: ipipe 5.4.107 / 5.4.93 build issues on arm32

[Greg Gallagher via Xenomai]

On Wed, Apr 14, 2021 at 4:52 PM Thomas Petazzoni <
thomas.petazz...@bootlin.com> wrote:

> On Wed, 14 Apr 2021 14:41:29 -0400
> Greg Gallagher  wrote:
>
> > Ipipe 5.4 and xenomai 3.1 are compatible, this is my mistake, I’ll fix up
> > and generate a new patch once the latency fix is done.
> > FWIW, building straight from the ipipe-arm repo on the ipipe/5.4.y branch
> > has been working for me.
>
> I'm afraid the HEAD of ipipe/5.4.y as of commit
> ffaf274ca4cc117c2dc3f9b2ee8ea6218b50995a doesn't build for me. I'm on
> this commit + I have prepared the kernel using Xenomai 3.1
> ./scripts/prepare-kernel.sh --linux=/path/to/kernel + kernel configured
> with sama5_defconfig.
>
> And same build failure:
>
> In file included from kernel/cpu.c:23:0:
> ./include/linux/stop_machine.h: In function ‘stop_machine_cpuslocked’:
> ./include/linux/stop_machine.h:150:2: error: implicit declaration of
> function ‘hard_irq_enable’; did you mean ‘hard_irq_disable’?
> [-Werror=implicit-function-declaration]
>   hard_irq_enable();
>   ^~~
>   hard_irq_disable
>
> Best regards,
>
> Thomas
> --
> Thomas Petazzoni, co-owner and CEO, Bootlin
> Embedded Linux and Kernel engineering
> https://bootlin.com


I'll dig into this tonight, I usually test with multi_v7_defconfig and it
seems to build fine with ipipe 5.4 and Xenomai 3.1.  I'll test with
sama5_defconfig.

Thanks

Greg

Re: ipipe 5.4.107 / 5.4.93 build issues on arm32

[Thomas Petazzoni via Xenomai]

On Wed, 14 Apr 2021 14:41:29 -0400
Greg Gallagher  wrote:

> Ipipe 5.4 and xenomai 3.1 are compatible, this is my mistake, I’ll fix up
> and generate a new patch once the latency fix is done.
> FWIW, building straight from the ipipe-arm repo on the ipipe/5.4.y branch
> has been working for me.

I'm afraid the HEAD of ipipe/5.4.y as of commit
ffaf274ca4cc117c2dc3f9b2ee8ea6218b50995a doesn't build for me. I'm on
this commit + I have prepared the kernel using Xenomai 3.1
./scripts/prepare-kernel.sh --linux=/path/to/kernel + kernel configured
with sama5_defconfig.

And same build failure:

In file included from kernel/cpu.c:23:0:
./include/linux/stop_machine.h: In function ‘stop_machine_cpuslocked’:
./include/linux/stop_machine.h:150:2: error: implicit declaration of function 
‘hard_irq_enable’; did you mean ‘hard_irq_disable’? 
[-Werror=implicit-function-declaration]
  hard_irq_enable();
  ^~~
  hard_irq_disable

Best regards,

Thomas
-- 
Thomas Petazzoni, co-owner and CEO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

Re: ipipe 5.4.107 / 5.4.93 build issues on arm32

[Greg Gallagher via Xenomai]

On Wed, Apr 14, 2021 at 2:35 PM Thomas Petazzoni via Xenomai <
xenomai@xenomai.org> wrote:

> Hello,
>
> On Wed, 14 Apr 2021 15:49:45 +0200
> Jan Kiszka  wrote:
>
> > Does
> >
> https://source.denx.de/Xenomai/xenomai/-/commit/18ab00b7b0c2c2d0ed1f560cf4fb4161f6e9bde6
> > help? Or did you build a tree that included this?
>
> This helps, but the build fails a bit later with:
>
> In file included from kernel/cpu.c:23:0:
> ./include/linux/stop_machine.h: In function ‘stop_machine_cpuslocked’:
> ./include/linux/stop_machine.h:150:2: error: implicit declaration of
> function ‘hard_irq_enable’; did you mean ‘hard_irq_disable’?
> [-Werror=implicit-function-declaration]
>   hard_irq_enable();
>   ^~~
>   hard_irq_disable
>
> But this makes me realize something: I am using Xenomai 3.1, together
> with the ipipe patch
> https://xenomai.org/downloads/ipipe/v5.x/arm/ipipe-core-5.4.107-arm-1.patch
> .
> Maybe this doesn't make any sense, and this very recent ipipe patch is
> only compatible with a more recent version of Xenomai ?
>
> Thomas
> --
> Thomas Petazzoni, co-owner and CEO, Bootlin
> Embedded Linux and Kernel engineering
> https://bootlin.com
>

Ipipe 5.4 and xenomai 3.1 are compatible, this is my mistake, I’ll fix up
and generate a new patch once the latency fix is done.
FWIW, building straight from the ipipe-arm repo on the ipipe/5.4.y branch
has been working for me.

 I’ll confirm the above issues and get a fix out.

Thanks

Greg


>

Re: ipipe 5.4.107 / 5.4.93 build issues on arm32

[Thomas Petazzoni via Xenomai]

Hello,

On Wed, 14 Apr 2021 15:49:45 +0200
Jan Kiszka  wrote:

> Does
> https://source.denx.de/Xenomai/xenomai/-/commit/18ab00b7b0c2c2d0ed1f560cf4fb4161f6e9bde6
> help? Or did you build a tree that included this?

This helps, but the build fails a bit later with:

In file included from kernel/cpu.c:23:0:
./include/linux/stop_machine.h: In function ‘stop_machine_cpuslocked’:
./include/linux/stop_machine.h:150:2: error: implicit declaration of function 
‘hard_irq_enable’; did you mean ‘hard_irq_disable’? 
[-Werror=implicit-function-declaration]
  hard_irq_enable();
  ^~~
  hard_irq_disable

But this makes me realize something: I am using Xenomai 3.1, together
with the ipipe patch
https://xenomai.org/downloads/ipipe/v5.x/arm/ipipe-core-5.4.107-arm-1.patch.
Maybe this doesn't make any sense, and this very recent ipipe patch is
only compatible with a more recent version of Xenomai ?

Thomas
-- 
Thomas Petazzoni, co-owner and CEO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

Re: ipipe 5.4.107 / 5.4.93 build issues on arm32

[Jan Kiszka via Xenomai]

On 14.04.21 14:42, Thomas Petazzoni via Xenomai wrote:
> Hello,
> 
> I just tested the following ipipe patches on arm32:
> 
>   https://xenomai.org/downloads/ipipe/v5.x/arm/ipipe-core-5.4.107-arm-1.patch
>   https://xenomai.org/downloads/ipipe/v5.x/arm/ipipe-core-5.4.93-arm-0.patch
> 
> applied of course on the appropriate 5.4.x code base, configured with
> the sama5_defconfig kernel configuration, and in both cases the build
> fails with:
> 
> In file included from include/xenomai/cobalt/kernel/thread.h:26:0,
>  from include/xenomai/cobalt/kernel/sched.h:24,
>  from kernel/xenomai/intr.c:24:
> kernel/xenomai/intr.c: In function ‘inc_irqstats’:
> include/xenomai/cobalt/kernel/stat.h:61:49: error: passing argument 1 of 
> ‘atomic_long_xchg’ from incompatible pointer type 
> [-Werror=incompatible-pointer-types]
>   __prev = (xnstat_exectime_t *)atomic_long_xchg(&(sched)->current_account, 
> (long)(new_account)); \
>  ^
> include/xenomai/cobalt/kernel/stat.h:147:2: note: in expansion of macro 
> ‘xnstat_exectime_set_current’
>   xnstat_exectime_set_current(sched, new_account); \
>   ^~~
> kernel/xenomai/intr.c:123:2: note: in expansion of macro 
> ‘xnstat_exectime_lazy_switch’
>   xnstat_exectime_lazy_switch(sched, >account, start);
>   ^~~
> In file included from ./include/linux/atomic.h:76:0,
>  from ./include/asm-generic/bitops/lock.h:5,
>  from ./arch/arm/include/asm/bitops.h:243,
>  from ./include/linux/bitops.h:26,
>  from ./include/linux/kernel.h:12,
>  from ./include/asm-generic/bug.h:19,
>  from ./arch/arm/include/asm/bug.h:60,
>  from ./include/linux/bug.h:5,
>  from ./include/linux/thread_info.h:12,
>  from ./include/asm-generic/current.h:5,
>  from ./arch/arm/include/generated/asm/current.h:1,
>  from ./include/linux/mutex.h:14,
>  from kernel/xenomai/intr.c:21:
> ./include/asm-generic/atomic-long.h:880:1: note: expected ‘atomic_long_t * 
> {aka struct  *}’ but argument is of type ‘xnstat_exectime_t ** 
> {aka struct xnstat_exectime **}’
>  atomic_long_xchg(atomic_long_t *v, long i)
>  ^~~~
> In file included from include/xenomai/cobalt/kernel/thread.h:26:0,
>  from include/xenomai/cobalt/kernel/sched.h:24,
>  from kernel/xenomai/intr.c:24:
> kernel/xenomai/intr.c: In function ‘switch_to_irqstats’:
> include/xenomai/cobalt/kernel/stat.h:61:49: error: passing argument 1 of 
> ‘atomic_long_xchg’ from incompatible pointer type 
> [-Werror=incompatible-pointer-types]
>   __prev = (xnstat_exectime_t *)atomic_long_xchg(&(sched)->current_account, 
> (long)(new_account)); \
>  ^
> include/xenomai/cobalt/kernel/stat.h:139:2: note: in expansion of macro 
> ‘xnstat_exectime_set_current’
>   xnstat_exectime_set_current(sched, new_account); \
>   ^~~
> kernel/xenomai/intr.c:132:2: note: in expansion of macro 
> ‘xnstat_exectime_switch’
>   xnstat_exectime_switch(sched, >account);
>   ^~
> In file included from ./include/linux/atomic.h:76:0,
>  from ./include/asm-generic/bitops/lock.h:5,
>  from ./arch/arm/include/asm/bitops.h:243,
>  from ./include/linux/bitops.h:26,
>  from ./include/linux/kernel.h:12,
>  from ./include/asm-generic/bug.h:19,
>  from ./arch/arm/include/asm/bug.h:60,
>  from ./include/linux/bug.h:5,
>  from ./include/linux/thread_info.h:12,
>  from ./include/asm-generic/current.h:5,
>  from ./arch/arm/include/generated/asm/current.h:1,
>  from ./include/linux/mutex.h:14,
>  from kernel/xenomai/intr.c:21:
> ./include/asm-generic/atomic-long.h:880:1: note: expected ‘atomic_long_t * 
> {aka struct  *}’ but argument is of type ‘xnstat_exectime_t ** 
> {aka struct xnstat_exectime **}’
>  atomic_long_xchg(atomic_long_t *v, long i)
>  ^~~~
> In file included from include/xenomai/cobalt/kernel/thread.h:26:0,
>  from include/xenomai/cobalt/kernel/sched.h:24,
>  from kernel/xenomai/intr.c:24:
> kernel/xenomai/intr.c: In function ‘switch_from_irqstats’:
> include/xenomai/cobalt/kernel/stat.h:61:49: error: passing argument 1 of 
> ‘atomic_long_xchg’ from incompatible pointer type 
> [-Werror=incompatible-pointer-types]
>   __prev = (xnstat_exectime_t *)atomic_long_xchg(&(sched)->current_account, 
> (long)(new_account)); \
>  ^
> include/xenomai/cobalt/kernel/stat.h:139:2: note: in expansion of macro 
> ‘xnstat_exectime_set_current’
>   xnstat_exectime_set_current(sched, 

Re: ipipe 5.4.107 / 5.4.93 build issues on arm32

[Greg Gallagher via Xenomai]

On Wed, Apr 14, 2021 at 8:43 AM Thomas Petazzoni via Xenomai <
xenomai@xenomai.org> wrote:

> Hello,
>
> I just tested the following ipipe patches on arm32:
>
>
> https://xenomai.org/downloads/ipipe/v5.x/arm/ipipe-core-5.4.107-arm-1.patch
>
> https://xenomai.org/downloads/ipipe/v5.x/arm/ipipe-core-5.4.93-arm-0.patch
>
> applied of course on the appropriate 5.4.x code base, configured with
> the sama5_defconfig kernel configuration, and in both cases the build
> fails with:
>
> In file included from include/xenomai/cobalt/kernel/thread.h:26:0,
>  from include/xenomai/cobalt/kernel/sched.h:24,
>  from kernel/xenomai/intr.c:24:
> kernel/xenomai/intr.c: In function ‘inc_irqstats’:
> include/xenomai/cobalt/kernel/stat.h:61:49: error: passing argument 1 of
> ‘atomic_long_xchg’ from incompatible pointer type
> [-Werror=incompatible-pointer-types]
>   __prev = (xnstat_exectime_t
> *)atomic_long_xchg(&(sched)->current_account, (long)(new_account)); \
>  ^
> include/xenomai/cobalt/kernel/stat.h:147:2: note: in expansion of macro
> ‘xnstat_exectime_set_current’
>   xnstat_exectime_set_current(sched, new_account); \
>   ^~~
> kernel/xenomai/intr.c:123:2: note: in expansion of macro
> ‘xnstat_exectime_lazy_switch’
>   xnstat_exectime_lazy_switch(sched, >account, start);
>   ^~~
> In file included from ./include/linux/atomic.h:76:0,
>  from ./include/asm-generic/bitops/lock.h:5,
>  from ./arch/arm/include/asm/bitops.h:243,
>  from ./include/linux/bitops.h:26,
>  from ./include/linux/kernel.h:12,
>  from ./include/asm-generic/bug.h:19,
>  from ./arch/arm/include/asm/bug.h:60,
>  from ./include/linux/bug.h:5,
>  from ./include/linux/thread_info.h:12,
>  from ./include/asm-generic/current.h:5,
>  from ./arch/arm/include/generated/asm/current.h:1,
>  from ./include/linux/mutex.h:14,
>  from kernel/xenomai/intr.c:21:
> ./include/asm-generic/atomic-long.h:880:1: note: expected ‘atomic_long_t *
> {aka struct  *}’ but argument is of type ‘xnstat_exectime_t **
> {aka struct xnstat_exectime **}’
>  atomic_long_xchg(atomic_long_t *v, long i)
>  ^~~~
> In file included from include/xenomai/cobalt/kernel/thread.h:26:0,
>  from include/xenomai/cobalt/kernel/sched.h:24,
>  from kernel/xenomai/intr.c:24:
> kernel/xenomai/intr.c: In function ‘switch_to_irqstats’:
> include/xenomai/cobalt/kernel/stat.h:61:49: error: passing argument 1 of
> ‘atomic_long_xchg’ from incompatible pointer type
> [-Werror=incompatible-pointer-types]
>   __prev = (xnstat_exectime_t
> *)atomic_long_xchg(&(sched)->current_account, (long)(new_account)); \
>  ^
> include/xenomai/cobalt/kernel/stat.h:139:2: note: in expansion of macro
> ‘xnstat_exectime_set_current’
>   xnstat_exectime_set_current(sched, new_account); \
>   ^~~
> kernel/xenomai/intr.c:132:2: note: in expansion of macro
> ‘xnstat_exectime_switch’
>   xnstat_exectime_switch(sched, >account);
>   ^~
> In file included from ./include/linux/atomic.h:76:0,
>  from ./include/asm-generic/bitops/lock.h:5,
>  from ./arch/arm/include/asm/bitops.h:243,
>  from ./include/linux/bitops.h:26,
>  from ./include/linux/kernel.h:12,
>  from ./include/asm-generic/bug.h:19,
>  from ./arch/arm/include/asm/bug.h:60,
>  from ./include/linux/bug.h:5,
>  from ./include/linux/thread_info.h:12,
>  from ./include/asm-generic/current.h:5,
>  from ./arch/arm/include/generated/asm/current.h:1,
>  from ./include/linux/mutex.h:14,
>  from kernel/xenomai/intr.c:21:
> ./include/asm-generic/atomic-long.h:880:1: note: expected ‘atomic_long_t *
> {aka struct  *}’ but argument is of type ‘xnstat_exectime_t **
> {aka struct xnstat_exectime **}’
>  atomic_long_xchg(atomic_long_t *v, long i)
>  ^~~~
> In file included from include/xenomai/cobalt/kernel/thread.h:26:0,
>  from include/xenomai/cobalt/kernel/sched.h:24,
>  from kernel/xenomai/intr.c:24:
> kernel/xenomai/intr.c: In function ‘switch_from_irqstats’:
> include/xenomai/cobalt/kernel/stat.h:61:49: error: passing argument 1 of
> ‘atomic_long_xchg’ from incompatible pointer type
> [-Werror=incompatible-pointer-types]
>   __prev = (xnstat_exectime_t
> *)atomic_long_xchg(&(sched)->current_account, (long)(new_account)); \
>  ^
> include/xenomai/cobalt/kernel/stat.h:139:2: note: in expansion of macro
> ‘xnstat_exectime_set_current’
>