All of lore.kernel.org
 help / color / mirror / Atom feed
* [Xenomai] Xenomai on Linux 3.18 on Zynq
@ 2015-04-10 14:35 Andreas Galauner
  2015-04-10 15:09 ` Stefan Roese
                   ` (3 more replies)
  0 siblings, 4 replies; 15+ messages in thread
From: Andreas Galauner @ 2015-04-10 14:35 UTC (permalink / raw)
  To: xenomai

Hi all,

I'm playing around with Xenomai for a few months now on and off and I
want to get Xenomai running on the Xilinx 3.18 Kernel to use it on a
Zynq board. I had it running with 3.14, but I need the Xilinx Video
Pipeline drivers which only work for me on 3.18.

Now I've been keeping an eye on the i-pipe 3.18 branch for a while and
I've been trying to run it on my board, but I keep having massive
problems during bootup when Xenomai is enabled.

Most of the time it just freezes at some point in time during bootup.
Sometimes it boots completely and then freezes afterwards.

The funniest thing we saw was, that it booted completely, we quickly
logged in, ran xeno-test which seemed to work fine until Linux processes
seem to be hanging randomly, but then it recovered after a few seconds,
ran for a few seconds, hang again etc.

I tried all kinds of things to find out where this hanging comes from. I
disabled all kinds of peripherals, because I suspected drivers to behave
in a wrong way during interrupt handling, I tried to debug it via JTAG,
but because I don't even know where to start that didn't help at all. I
also tried Xenomai 2.6 and 3. All the same.

Just to be sure: Was the 3.18 kernel with i-pipe patches ever tested
with Xenomai on real hardware? Because I'm not sure if I'm searching for
a bug in the Xilinx part or in the general i-pipe/Xenomai part of the
kernel. I know, that the 3.18 kernel unstable, that's why I'm asking.
Should I keep looking or just wait?

On a sidenote: That patch
https://git.xenomai.org/ipipe-gch.git/commit/?h=for-ipipe-3.18&id=f98b6d95359ea0429307d98759357d54dcfba7e8
makes the board stop directly after the bootloader jumps into the
kernel. Without it, it panics with a NULL-pointer deref on 3.18.10. All
patches before that lead to the mentioned freezing-behaviour.

Any pointers in any direction where to start looking would be great!

- Andy


^ permalink raw reply	[flat|nested] 15+ messages in thread
* [Xenomai]  Xenomai on Linux 3.18 on Zynq
@ 2015-11-05  8:31 Philippe.Corbel
  2015-11-05 11:00 ` Stefan Roese
  2015-11-05 20:46 ` Gilles Chanteperdrix
  0 siblings, 2 replies; 15+ messages in thread
From: Philippe.Corbel @ 2015-11-05  8:31 UTC (permalink / raw)
  To: xenomai

Hi All!

I just subscribe to the mailing list to ask you for a few insight on my 
potential problem.

I'm having the same behaviour that Andreas Galauner observed on his board 
and since there have been no news since April, I'm restarting this 
thread...

I'm currently developping for a custom designed board based on a Zynq 
7c020 and hoped to use Xenomai 3.0 on it.
Standard Linux (Xilinx version not Vanilla) is running fine on the board 
but if I use the cobalt core, I'm having the same behaviour previously 
described ie the system seems to hang for a random duration then becomes 
responsive again as if nothing happened (several times).
It happens at each boot during: 
- kernel decompression
- VFS/Rootfs mount
- console access
And after, it occurs randomly on command entered on console...

Also, it seems that network is not working with cobalt core enabled in 
kernel (but with random freezes, I can't look at this issue for the 
moment)

I'm suspecting some timer issue as Gilles supposed previously but I can't 
find the beginning of a solution: I've followed the Guide "Porting Xenomai 
dual kernel to a new ARM SoC" but as the arm core of the Zynq is a Cortex 
A9, in theory, I've practically nothing to modify to have it working...

I've also enabled debug in I-Pipe and Xenoami and got no trace at all...

What I've seen so far is an enormous amount of interruptions on the twd 
timer (and this is just after the boot!):

# cat /proc/interrupts
           CPU0       CPU1
 27:          0          0       GIC  27  gt
 29:   37426949   16329631       GIC  29  twd
 35:          0          0       GIC  35  f800c000.ocmc
 39:         43          0       GIC  39  f8007100.adc
 40:          0          0       GIC  40  f8007000.devcfg
 41:          0          0       GIC  41  f8005000.watchdog
 43:          0          0       GIC  43  ttc_clockevent
 45:          0          0       GIC  45  f8003000.dmac
 46:          0          0       GIC  46  f8003000.dmac
 47:          0          0       GIC  47  f8003000.dmac
 48:          0          0       GIC  48  f8003000.dmac
 49:          0          0       GIC  49  f8003000.dmac
 51:          0          0       GIC  51  e000d000.spi
 54:          0          0       GIC  54  eth0
 72:          0          0       GIC  72  f8003000.dmac
 73:          0          0       GIC  73  f8003000.dmac
 74:          0          0       GIC  74  f8003000.dmac
 75:          0          0       GIC  75  f8003000.dmac
 82:         49          0       GIC  82  xuartps
IPI1:          0          0  Timer broadcast interrupts
IPI2:        559        435  Rescheduling interrupts
IPI3:          0          0  Function call interrupts
IPI4:         25          8  Single function call interrupts
IPI5:          0          0  CPU stop interrupts
IPI6:          0          0  IRQ work interrupts
IPI7:          0          0  completion interrupts
Err:          0

To be more precise about my system, I'm using Linux 3.18.20 with the Adeos 
I-Pipe patch for arm found in Xenomai 3.0 (Exact Zero) tarball on a 
busybox-based rootfs.
I've taken a look at branch for-ipipe-3.18 in ipipe-gch.git but it seems 
to be the same as  Xenomai 3.0's patch...

Does anyone have some idea where to look for a way to attack this issue?

Thanks in advance,

PS: If necessary I can post the kernel's config, but I did not want to put 
too much data in this mail

----------------
Ph. Corbel


On Fri, Apr 10, 2015 at 04:35:07PM +0200, Andreas Galauner wrote:
> On a sidenote: That patch
> 
https://git.xenomai.org/ipipe-gch.git/commit/?h=for-ipipe-3.18&id=f98b6d95359ea0429307d98759357d54dcfba7e8

> makes the board stop directly after the bootloader jumps into the
> kernel.

Please try branch for-ipipe-3.18 in ipipe-gch.git, it contains a
totally untested, not even compiled patch for fixing this particular
issue.

In short, I believe kmalloc may be using percpu, so ends-up using
ipipe_processor_id() which ends up dereferencing the NULL
__cpu_reverse_map, so I temporarily set __cpu_reverse_map to
__cpu_logical_map before calling kmalloc. 

This is correct, because at this point in the code we can rely on
__cpu_logical_map to contain what is necessary to be used as a
reverse map.

If the kernel still crashes, then the problem does not come from
kmalloc using per-cpu data.

-- 
      Gilles.

^ permalink raw reply	[flat|nested] 15+ messages in thread
end of thread, other threads:[~2015-11-06 10:57 UTC | newest]

Thread overview: 15+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2015-04-10 14:35 [Xenomai] Xenomai on Linux 3.18 on Zynq Andreas Galauner
2015-04-10 15:09 ` Stefan Roese
2015-04-10 15:15   ` Andreas Galauner
2015-04-10 15:26     ` Stefan Roese
2015-04-10 15:24 ` Gilles Chanteperdrix
2015-04-10 15:29 ` Gilles Chanteperdrix
2015-04-10 16:06   ` Andreas Galauner
2015-04-10 16:14     ` Gilles Chanteperdrix
2015-04-10 16:11 ` Gilles Chanteperdrix
  -- strict thread matches above, loose matches on Subject: below --
2015-11-05  8:31 Philippe.Corbel
2015-11-05 11:00 ` Stefan Roese
2015-11-05 12:13   ` Philippe.Corbel
2015-11-05 20:46 ` Gilles Chanteperdrix
2015-11-06 10:49   ` Philippe.Corbel
2015-11-06 10:57     ` Gilles Chanteperdrix

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.