Tomas Kalibera wrote:
Hi,
I've tried a more defensive kernel setup your patch (no.6). The lockup
is still there. It happens after a realtime task is started, though I
was unable to track exactly when - it does not crash in a debugger,
does not crash with strace, breaks SysRq, and printing
On Thu, Apr 3, 2008 at 1:46 AM, Tomas Kalibera [EMAIL PROTECTED] wrote:
Gilles Chanteperdrix wrote:
Of course, we are looking for all bugs. But please tell me: do you get
the lock-up even before fork is called ? If not, could you verify that
at least some Xenomai programs run correctly,
Gilles Chanteperdrix wrote:
Of course, we are looking for all bugs. But please tell me: do you get
the lock-up even before fork is called ? If not, could you verify that
at least some Xenomai programs run correctly, for instance latency ?
Looking at the code, I think I found a bug, but
On Wed, Apr 2, 2008 at 5:02 PM, Tomas Kalibera [EMAIL PROTECTED] wrote:
OK, no change with this patch compared to the previous situation. The
system boots, but hangs without a stacktrace when I run my Xenomai task.
SysRq is blocked, now even SysRq-kill did not work, only SysRq-boot did.
Are
Hmm, I checked again and did not find a mistake in the experiment
(neither using the old binary nor old sources). I'm doing a clean build
from scratch again, so that we can be absolutely sure. I can then run
memtest on the machine...
Tomas
Gilles Chanteperdrix wrote:
On Wed, Apr 2, 2008 at
Hi Gilles,
I've recompiled the kernel again from scratch and got the same lock up.
Fix 5 does not help... If you want to inspect the exact kernel I used,
it's again at http://www.cs.purdue.edu/~tkaliber/crash, the one with
p5 in its name.
Tomas
Gilles Chanteperdrix wrote:
On Wed, Apr 2,
Tomas Kalibera wrote:
Hi Gilles,
I've recompiled the kernel again from scratch and got the same lock up.
Fix 5 does not help... If you want to inspect the exact kernel I used,
it's again at http://www.cs.purdue.edu/~tkaliber/crash, the one with
p5 in its name.
Tomas
But...
Tomas Kalibera wrote:
Hi Gilles,
I've recompiled the kernel again from scratch and got the same lock up.
Fix 5 does not help... If you want to inspect the exact kernel I used,
it's again at http://www.cs.purdue.edu/~tkaliber/crash, the one with
p5 in its name.
You aren't using gcc-4.2
Tomas Kalibera wrote:
Hi Gilles,
I've recompiled the kernel again from scratch and got the same lock up.
Fix 5 does not help... If you want to inspect the exact kernel I used,
it's again at http://www.cs.purdue.edu/~tkaliber/crash, the one with
p5 in its name.
permission denied
Tomas Kalibera wrote:
Gilles Chanteperdrix wrote:
Tomas Kalibera wrote:
Hi Gilles,
I've recompiled the kernel again from scratch and got the same lock up.
Fix 5 does not help... If you want to inspect the exact kernel I used,
it's again at
Gilles Chanteperdrix wrote:
Of course, we are looking for all bugs. But please tell me: do you get
the lock-up even before fork is called ? If not, could you verify that
at least some Xenomai programs run correctly, for instance latency ?
The lock up with patch 5 happens before fork is
On Tue, Apr 1, 2008 at 7:52 AM, Gilles Chanteperdrix
[EMAIL PROTECTED] wrote:
Tomas Kalibera wrote:
I added a missing underscore and re-tried, and none of the debug
messages was printed. I added another one to make sure that there is not
a problem with getting printk messages to
Tomas Kalibera wrote:
Crashed on the very same line as before
Tomas
Ok. Let us look for unbalanced kmap_atomics then. Try this patch instead.
--
Gilles.
diff --git a/arch/x86/mm/highmem_32.c b/arch/x86/mm/highmem_32.c
index 1c3bf95..a78494e
Gilles Chanteperdrix wrote:
Tomas Kalibera wrote:
Crashed on the very same line as before
Tomas
Ok. Let us look for unbalanced kmap_atomics then. Try this patch instead.
Just when I hit the reply button, I realize that I forgot something. So,
try this one instead.
--
I added a missing underscore and re-tried, and none of the debug
messages was printed. I added another one to make sure that there is not
a problem with getting printk messages to the serial console. The
resulting highmem_32.c and the output is attached.
T
Gilles Chanteperdrix wrote:
Tomas Kalibera wrote:
I added a missing underscore and re-tried, and none of the debug
messages was printed. I added another one to make sure that there is not
a problem with getting printk messages to the serial console. The
resulting highmem_32.c and the output is attached.
T
Tomas Kalibera wrote:
Hi Gilles,
thanks for looking at it. Your analysis is correct, I don't indeed have
CONFIG_PREEMPT_RT kernel, but only CONFIG_PREEMPT, sorry for the confusion.
I've put the kernel config, sources, and binary on the web, so that you
can be sure you're really
Crashed on the very same line as before
Tomas
[ 189.558776] [ cut here ]
[ 189.563377] kernel BUG at arch/x86/mm/highmem_32.c:43!
[ 189.568491] invalid opcode: [#1] PREEMPT SMP
[ 189.573285] Modules linked in: rfcomm l2cap bluetooth ppdev sbp2 parport_pc
lp
Tomas Kalibera wrote:
Hi Gilles,
thanks for looking at it. Your analysis is correct, I don't indeed have
CONFIG_PREEMPT_RT kernel, but only CONFIG_PREEMPT, sorry for the confusion.
I've put the kernel config, sources, and binary on the web, so that you
can be sure you're really
Hi,
I'm getting kernel crashes with my native skin user-space Xenomai
application. It looks like the crash happens after clone/fork. I'm using
kernel 2.6.24.3, SMP, RT_PREEMPT (settings like 2.6.22-14-rt from
Ubuntu 7.10). Xenomai 2.4.2.
The thread causing the crash is a Xenomai task,
Tomas Kalibera wrote:
Hi,
I'm getting kernel crashes with my native skin user-space Xenomai
application. It looks like the crash happens after clone/fork. I'm using
kernel 2.6.24.3, SMP, RT_PREEMPT (settings like 2.6.22-14-rt from
Ubuntu 7.10). Xenomai 2.4.2.
The thread
Gilles Chanteperdrix wrote:
Tomas Kalibera wrote:
Hi,
I'm getting kernel crashes with my native skin user-space Xenomai
application. It looks like the crash happens after clone/fork. I'm using
kernel 2.6.24.3, SMP, RT_PREEMPT (settings like 2.6.22-14-rt from
Hi Gilles,
thanks for looking at it. Your analysis is correct, I don't indeed have
CONFIG_PREEMPT_RT kernel, but only CONFIG_PREEMPT, sorry for the confusion.
I've put the kernel config, sources, and binary on the web, so that you
can be sure you're really looking on the kernel that is
23 matches
Mail list logo
