Hi,
the smaller the bug is, the longer it takes to track. The first one in
this patch was such an issue. It prevented the SMI workaround to do its
job because the related PCI ID table got "optimised" away (SVN trunk only).
The second one is also SVN-only. It fixes the proc-fs cleanup of the
nucle
Jan Kiszka wrote:
Hi,
the smaller the bug is, the longer it takes to track. The first one in
this patch was such an issue. It prevented the SMI workaround to do its
job because the related PCI ID table got "optimised" away (SVN trunk only).
Good catch. Fact is that this table must survive free
Philippe Gerum wrote:
> Ignacio García Pérez wrote:
>
>> Hi,
>>
>> Some time ago someone mentioned the current xenomai coding style, and
>> that maybe it would be a good idea to change it to something more
>> "standard". A good place to start would be turn the tabs into spaces to
>> eliminate edit
Hi Philippe,
I'm afraid this one is serious: let the attached migration stress test
run on likely any Xenomai since 2.0, preferably with
CONFIG_XENO_OPT_DEBUG on. Will give a nice crash sooner or later (I'm
trying to set up a serial console now). To be more precisely:
Setup 1:
xeno 2.0, kerne
Jan Kiszka wrote:
> Hi Philippe,
>
> I'm afraid this one is serious: let the attached migration stress test
> run on likely any Xenomai since 2.0, preferably with
> CONFIG_XENO_OPT_DEBUG on. Will give a nice crash sooner or later (I'm
> trying to set up a serial console now).
>
As it took some t
Jan Kiszka wrote:
Jan Kiszka wrote:
Hi Philippe,
I'm afraid this one is serious: let the attached migration stress test
run on likely any Xenomai since 2.0, preferably with
CONFIG_XENO_OPT_DEBUG on. Will give a nice crash sooner or later (I'm
trying to set up a serial console now).
Confirme
Hi all,
as the subject already says: I face some warning of the nucleus (with
XENO_OPT_DEBUG on - useful switch) when I call xnpod_delete_thread for a
thread which has already terminated itself by leaving the thread
function. Is this double-deletion illegal? Or is it a cleanup-bug of the
nucleus?
Jan Kiszka wrote:
Hi all,
as the subject already says: I face some warning of the nucleus (with
XENO_OPT_DEBUG on - useful switch) when I call xnpod_delete_thread for a
thread which has already terminated itself by leaving the thread
function. Is this double-deletion illegal? Or is it a cleanup-
Jan Kiszka wrote:
Hi all,
as the subject already says: I face some warning of the nucleus (with
XENO_OPT_DEBUG on - useful switch) when I call xnpod_delete_thread for a
thread which has already terminated itself by leaving the thread
function. Is this double-deletion illegal? Or is it a cleanup-
Philippe Gerum wrote:
> Jan Kiszka wrote:
>
>> Hi all,
>>
>> as the subject already says: I face some warning of the nucleus (with
>> XENO_OPT_DEBUG on - useful switch) when I call xnpod_delete_thread for a
>> thread which has already terminated itself by leaving the thread
>> function. Is this do
Jan Kiszka wrote:
Philippe Gerum wrote:
Jan Kiszka wrote:
Hi all,
as the subject already says: I face some warning of the nucleus (with
XENO_OPT_DEBUG on - useful switch) when I call xnpod_delete_thread for a
thread which has already terminated itself by leaving the thread
function. Is this
Hi,
this patch clarifies the usage of rtdm_task_join_nrt.
Typically, rtdm_task_join_nrt + target task wakeup should be preferred
over rtdm_task_destroy during cleanup of drivers. It's now intensively
used in RTnet.
Jan
Index: ChangeLog
Hi, I'm using xenomai instead of fusion.
When I bind a heap in user space which is created by a kernel module,
the return value is -2 which I don't know what it means for it is not
one of several values explained by the document.
This program runned well with fusion 0.9.
My kernel is 2.6.13 patch
Jan Kiszka wrote:
Hi,
this patch clarifies the usage of rtdm_task_join_nrt.
Applied, thanks.
Typically, rtdm_task_join_nrt + target task wakeup should be preferred
over rtdm_task_destroy during cleanup of drivers. It's now intensively
used in RTnet.
Jan
--
Hi,
the smaller the bug is, the longer it takes to track. The first one in
this patch was such an issue. It prevented the SMI workaround to do its
job because the related PCI ID table got "optimised" away (SVN trunk only).
The second one is also SVN-only. It fixes the proc-fs cleanup of the
nucle
Jan Kiszka wrote:
Hi,
the smaller the bug is, the longer it takes to track. The first one in
this patch was such an issue. It prevented the SMI workaround to do its
job because the related PCI ID table got "optimised" away (SVN trunk only).
Good catch. Fact is that this table must survive free
Philippe Gerum wrote:
> Ignacio García Pérez wrote:
>
>> Hi,
>>
>> Some time ago someone mentioned the current xenomai coding style, and
>> that maybe it would be a good idea to change it to something more
>> "standard". A good place to start would be turn the tabs into spaces to
>> eliminate edit
Hi Philippe,
I'm afraid this one is serious: let the attached migration stress test
run on likely any Xenomai since 2.0, preferably with
CONFIG_XENO_OPT_DEBUG on. Will give a nice crash sooner or later (I'm
trying to set up a serial console now). To be more precisely:
Setup 1:
xeno 2.0, kerne
Jan Kiszka wrote:
> Hi Philippe,
>
> I'm afraid this one is serious: let the attached migration stress test
> run on likely any Xenomai since 2.0, preferably with
> CONFIG_XENO_OPT_DEBUG on. Will give a nice crash sooner or later (I'm
> trying to set up a serial console now).
>
As it took some t
Jan Kiszka wrote:
Jan Kiszka wrote:
Hi Philippe,
I'm afraid this one is serious: let the attached migration stress test
run on likely any Xenomai since 2.0, preferably with
CONFIG_XENO_OPT_DEBUG on. Will give a nice crash sooner or later (I'm
trying to set up a serial console now).
Confirme
Hi all,
as the subject already says: I face some warning of the nucleus (with
XENO_OPT_DEBUG on - useful switch) when I call xnpod_delete_thread for a
thread which has already terminated itself by leaving the thread
function. Is this double-deletion illegal? Or is it a cleanup-bug of the
nucleus?
Jan Kiszka wrote:
Hi all,
as the subject already says: I face some warning of the nucleus (with
XENO_OPT_DEBUG on - useful switch) when I call xnpod_delete_thread for a
thread which has already terminated itself by leaving the thread
function. Is this double-deletion illegal? Or is it a cleanup-
Jan Kiszka wrote:
Hi all,
as the subject already says: I face some warning of the nucleus (with
XENO_OPT_DEBUG on - useful switch) when I call xnpod_delete_thread for a
thread which has already terminated itself by leaving the thread
function. Is this double-deletion illegal? Or is it a cleanup-
Philippe Gerum wrote:
> Jan Kiszka wrote:
>
>> Hi all,
>>
>> as the subject already says: I face some warning of the nucleus (with
>> XENO_OPT_DEBUG on - useful switch) when I call xnpod_delete_thread for a
>> thread which has already terminated itself by leaving the thread
>> function. Is this do
Jan Kiszka wrote:
Philippe Gerum wrote:
Jan Kiszka wrote:
Hi all,
as the subject already says: I face some warning of the nucleus (with
XENO_OPT_DEBUG on - useful switch) when I call xnpod_delete_thread for a
thread which has already terminated itself by leaving the thread
function. Is this
25 matches
Mail list logo
