in a lot of the Makefile.in files in 2.1-rc2 there are lines like:
test -z "$(somedir)" || $(mkdir_p) "$(DESTDIR)$(somedir)"
shouldn't they read:
test -z "$(DESTDIR)$(somedir)" || $(mkdir_p) "$(DESTDIR)$(s
Anders Blomdell wrote:
in a lot of the Makefile.in files in 2.1-rc2 there are lines like:
test -z "$(somedir)" || $(mkdir_p) "$(DESTDIR)$(somedir)"
shouldn't they read:
test -z "$(DESTDIR)$(somedir)" || $(mkdir_p) "$(DESTDIR)$(somedir)"
Forg
When RTDM is exposed to code like this:
device1 = rt_dev_open("some_device", O_RDWR);
device2 = rt_dev_open("some_device", O_RDWR);
I get a SEGFAULT, which I attribute to a missing assignment to context_ptr in
the case when the device is already busy, the lack of this assignment leads to a
] [c0005058] __ipipe_ret_from_except+0x0/0xc
[ 43.411145] [c0006524] default_idle+0x10/0x60
Any ideas of where to look?
Regards
Anders Blomdell
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
return (ipipe_percpu_domain[cpuid] == ipipe_root_domain &&
!test_bit(IPIPE_STALL_FLAG,
&ipipe_root_domain->cpudata[cpuid].status));
}
Regards
Anders Blomdell
___
Xenomai-core mailing list
Xenomai-co
Jan Kiszka wrote:
Anders Blomdell wrote:
On a PrPMC800 (PPC 7410 processor) withe Xenomai-2.1-rc2, I get the
following if the interrupt handler takes too long (i.e. next interrupt
gets generated before the previous one has finished)
[ 42.543765] [c00c2008] spin_bug+0xa8/0xc4
[ 42.597617
Jan Kiszka wrote:
Anders Blomdell wrote:
Jan Kiszka wrote:
Anders Blomdell wrote:
On a PrPMC800 (PPC 7410 processor) withe Xenomai-2.1-rc2, I get the
following if the interrupt handler takes too long (i.e. next interrupt
gets generated before the previous one has finished)
[ 42.543765
Philippe Gerum wrote:
Anders Blomdell wrote:
On a PrPMC800 (PPC 7410 processor) withe Xenomai-2.1-rc2, I get the
following if the interrupt handler takes too long (i.e. next interrupt
gets generated before the previous one has finished)
[ 42.543765] [c00c2008] spin_bug+0xa8/0xc4
in ksrc/arch/powerpc/patches/adeos-ipipe-2.6.14-ppc-1.2-00.patch:
#define IPIPE_ARCH_STRING"1.1-02"
shouldn't this be
#define IPIPE_ARCH_STRING "1.2-00"
--
Anders Blomdell
___
Xenomai-core mailing list
X
ied iend handler)
5. The iend handler reenables non-RT interrupts.
Comments on the above are most welcome!
--
Anders Blomdell
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
Jan Kiszka wrote:
Anders Blomdell wrote:
While looking into how to implement sharing of interrupts between
realtime and non-realtime domains (and applying Wolfgang Grandegger's
patch [https://mail.gna.org/public/xenomai-core/2006-01/msg00233.html],
which is necessary to make XN_ISR_ENABLE
Anders Blomdell wrote:
Jan Kiszka wrote:
Anders Blomdell wrote:
While looking into how to implement sharing of interrupts between
realtime and non-realtime domains (and applying Wolfgang Grandegger's
patch [https://mail.gna.org/public/xenomai-core/2006-01/msg00233.html],
which is nece
.info/DOWNLOADS/ACPIspec30a.pdf)
--
Regards
Anders Blomdell
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
Jan Kiszka wrote:
Jan Kiszka wrote:
...
What about other time sources on x86? Which systems already have HPET
these days, and does this source not suffer from frequency scaling? I
once read that HPET is quite easy to program, is this true? IOW, would
it be worth considering to add this to the H
Jan Kiszka wrote:
Anders Blomdell wrote:
Jan Kiszka wrote:
...and may also add further latencies with the system has to speed up
again. Anyway, there might be use-cases where power consumption is -
besides latency - also an important issue. I'm just thinking of our
smaller mobile r
] patch said
@@ -0,0 +1,178 @@
Seems like the patch is created againt a not totally clean distribution.
--
Regards
Anders Blomdell
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
openpic_eoi until the
interrupt is ended, which means that all RT-interrupts are delayed by a pending
Linux interrupt.
--
Regards
Anders Blomdell
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
me hw-controlled interrupt
shield. Since this feature requires to be able to individually mask each
interrupt source at IC level, there should be no point in sharing fully
vectored interrupts in such a configuration anyway. This fact also
pleads for having the shared IRQ support as a build-
Philippe Gerum wrote:
Anders Blomdell wrote:
Philippe Gerum wrote:
Jan Kiszka wrote:
Wolfgang Grandegger wrote:
Hello,
Dmitry Adamushko wrote:
Hi,
this is the final set of patches against the SVN trunk of 2006-02-03.
It addresses mostly remarks concerning naming (XN_ISR_ISA
For the last few days, I have tried to figure out a good way to share interrupts
between RT and non-RT domains. This has included looking through Dmitry's patch,
correcting bugs and testing what is possible in my specific case. I'll therefore
try to summarize at least a few of my thoughts.
1.
Jan Kiszka wrote:
Anders Blomdell wrote:
For the last few days, I have tried to figure out a good way to share
interrupts between RT and non-RT domains. This has included looking
through Dmitry's patch, correcting bugs and testing what is possible in
my specific case. I'll theref
flag (not a counter), the fact that the IRQ was
signaled
is not lost but Linux can't know how much time it was signaled.
I guess, it's not true for devices that e.g. do not rise a new interrupt
until
the ISR handler does some special acknowledgement device-wise.
Since my knowledge of inte
Anders Blomdell wrote:
For the last few days, I have tried to figure out a good way to share
interrupts between RT and non-RT domains. This has included looking
through Dmitry's patch, correcting bugs and testing what is possible in
my specific case. I'll therefore try to summarize
Jan Kiszka wrote:
Hi Dmitry,
Dmitry Adamushko wrote:
Hi Jan,
let's make yet another revision of the bits :
new XN_ISR_HANDLED == old XN_ISR_HANDLED + old XN_ISR_NO_ENABLE
ok.
new XN_ISR_NOENABLE == ~ old XN_ISR_ENABLE
ok.
new XN_ISR_PROPAGATE == XN_ISR_CHAINED
ok.
Just to make sure
Dmitry Adamushko wrote:
On 21/02/06, *Anders Blomdell* <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>> wrote:
Dmitry Adamushko wrote:
>
> N.B. Amongst other things, some thoughts about CHAINED with shared
> interrupts.
>
>
>
Dmitry Adamushko wrote:
N.B. Amongst other things, some thoughts about CHAINED with shared
interrupts.
On 20/02/06, *Anders Blomdell* <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>> wrote:
A number of questions arise:
1. What happens if one of the shared handler
Dmitry Adamushko wrote:
> Good point, leaves us with 2 possible return values for shared handlers:
>
> HANDLED
> NOT_HANDLED
>
> i.e. shared handlers should never defer the end'ing of the interrupt
(which
> makes sense, since this would affect the other [shared] handlers).
HANDLED_
Jan Kiszka wrote:
Anders Blomdell wrote:
Dmitry Adamushko wrote:
> Good point, leaves us with 2 possible return values for shared
handlers:
>
> HANDLED
> NOT_HANDLED
>
> i.e. shared handlers should never defer the end'ing of the
interrupt (which
> makes sense, s
Dmitry Adamushko wrote:
> For RTDM I'm now almost determined to rework the API in way that only
> HANDLED/UNHANDLED (or what ever their names will be) get exported, any
> additional guru features will remain excluded as long as we have no
> clean usage policy for them.
Good. Then let's go f
Jan Kiszka wrote:
Philippe Gerum wrote:
Jan Kiszka wrote:
Dmitry Adamushko wrote:
...
This said, I'm going to publish the shirq patch (after finalizing ISR
return
bits,
where I still have some doubts) without enable/disable nesting support.
It can be supported at some point of time later,
in ksrc/arch/powerpc/patches/adeos-ipipe-2.6.14-ppc-1.2-00.patch:
#define IPIPE_ARCH_STRING"1.1-02"
shouldn't this be
#define IPIPE_ARCH_STRING "1.2-00"
--
Anders Blomdell
ied iend handler)
5. The iend handler reenables non-RT interrupts.
Comments on the above are most welcome!
--
Anders Blomdell
Jan Kiszka wrote:
Anders Blomdell wrote:
While looking into how to implement sharing of interrupts between
realtime and non-realtime domains (and applying Wolfgang Grandegger's
patch [https://mail.gna.org/public/xenomai-core/2006-01/msg00233.html],
which is necessary to make XN_ISR_ENABLE
Anders Blomdell wrote:
Jan Kiszka wrote:
Anders Blomdell wrote:
While looking into how to implement sharing of interrupts between
realtime and non-realtime domains (and applying Wolfgang Grandegger's
patch [https://mail.gna.org/public/xenomai-core/2006-01/msg00233.html],
which is nece
.info/DOWNLOADS/ACPIspec30a.pdf)
--
Regards
Anders Blomdell
Jan Kiszka wrote:
Jan Kiszka wrote:
...
What about other time sources on x86? Which systems already have HPET
these days, and does this source not suffer from frequency scaling? I
once read that HPET is quite easy to program, is this true? IOW, would
it be worth considering to add this to the H
Jan Kiszka wrote:
Anders Blomdell wrote:
Jan Kiszka wrote:
...and may also add further latencies with the system has to speed up
again. Anyway, there might be use-cases where power consumption is -
besides latency - also an important issue. I'm just thinking of our
smaller mobile r
] patch said
@@ -0,0 +1,178 @@
Seems like the patch is created againt a not totally clean distribution.
--
Regards
Anders Blomdell
openpic_eoi until the
interrupt is ended, which means that all RT-interrupts are delayed by a pending
Linux interrupt.
--
Regards
Anders Blomdell
me hw-controlled interrupt
shield. Since this feature requires to be able to individually mask each
interrupt source at IC level, there should be no point in sharing fully
vectored interrupts in such a configuration anyway. This fact also
pleads for having the shared IRQ support as a build-time option.
--
Anders Blomdell
Philippe Gerum wrote:
Anders Blomdell wrote:
Philippe Gerum wrote:
Jan Kiszka wrote:
Wolfgang Grandegger wrote:
Hello,
Dmitry Adamushko wrote:
Hi,
this is the final set of patches against the SVN trunk of 2006-02-03.
It addresses mostly remarks concerning naming (XN_ISR_ISA
For the last few days, I have tried to figure out a good way to share interrupts
between RT and non-RT domains. This has included looking through Dmitry's patch,
correcting bugs and testing what is possible in my specific case. I'll therefore
try to summarize at least a few of my thoughts.
1.
Jan Kiszka wrote:
Anders Blomdell wrote:
For the last few days, I have tried to figure out a good way to share
interrupts between RT and non-RT domains. This has included looking
through Dmitry's patch, correcting bugs and testing what is possible in
my specific case. I'll theref
flag (not a counter), the fact that the IRQ was
signaled
is not lost but Linux can't know how much time it was signaled.
I guess, it's not true for devices that e.g. do not rise a new interrupt
until
the ISR handler does some special acknowledgement device-wise.
Since my knowledge of interrupts in SMPs is essentially nil, I'll have to pass
on this one...
--
Best regards
Anders Blomdell
Anders Blomdell wrote:
For the last few days, I have tried to figure out a good way to share
interrupts between RT and non-RT domains. This has included looking
through Dmitry's patch, correcting bugs and testing what is possible in
my specific case. I'll therefore try to summarize
Jan Kiszka wrote:
Hi Dmitry,
Dmitry Adamushko wrote:
Hi Jan,
let's make yet another revision of the bits :
new XN_ISR_HANDLED == old XN_ISR_HANDLED + old XN_ISR_NO_ENABLE
ok.
new XN_ISR_NOENABLE == ~ old XN_ISR_ENABLE
ok.
new XN_ISR_PROPAGATE == XN_ISR_CHAINED
ok.
Just to make sure
Dmitry Adamushko wrote:
On 21/02/06, *Anders Blomdell* <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>> wrote:
Dmitry Adamushko wrote:
>
> N.B. Amongst other things, some thoughts about CHAINED with shared
> interrupts.
>
>
>
Dmitry Adamushko wrote:
N.B. Amongst other things, some thoughts about CHAINED with shared
interrupts.
On 20/02/06, *Anders Blomdell* <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>> wrote:
A number of questions arise:
1. What happens if one of the shared handler
Dmitry Adamushko wrote:
> Good point, leaves us with 2 possible return values for shared handlers:
>
> HANDLED
> NOT_HANDLED
>
> i.e. shared handlers should never defer the end'ing of the interrupt
(which
> makes sense, since this would affect the other [shared] handlers).
HANDLED_
Jan Kiszka wrote:
Anders Blomdell wrote:
Dmitry Adamushko wrote:
> Good point, leaves us with 2 possible return values for shared
handlers:
>
> HANDLED
> NOT_HANDLED
>
> i.e. shared handlers should never defer the end'ing of the
interrupt (which
> makes sense, s
Dmitry Adamushko wrote:
> For RTDM I'm now almost determined to rework the API in way that only
> HANDLED/UNHANDLED (or what ever their names will be) get exported, any
> additional guru features will remain excluded as long as we have no
> clean usage policy for them.
Good. Then let's go f
in a lot of the Makefile.in files in 2.1-rc2 there are lines like:
test -z "$(somedir)" || $(mkdir_p) "$(DESTDIR)$(somedir)"
shouldn't they read:
test -z "$(DESTDIR)$(somedir)" || $(mkdir_p) "$(DESTDIR)$(somedir)"
Best regards
Anders Blomdell
Anders Blomdell wrote:
in a lot of the Makefile.in files in 2.1-rc2 there are lines like:
test -z "$(somedir)" || $(mkdir_p) "$(DESTDIR)$(somedir)"
shouldn't they read:
test -z "$(DESTDIR)$(somedir)" || $(mkdir_p) "$(DESTDIR)$(somedir)"
Forg
When RTDM is exposed to code like this:
device1 = rt_dev_open("some_device", O_RDWR);
device2 = rt_dev_open("some_device", O_RDWR);
I get a SEGFAULT, which I attribute to a missing assignment to context_ptr in
the case when the device is already busy, the lack of this assignment leads to a
] [c0005058] __ipipe_ret_from_except+0x0/0xc
[ 43.411145] [c0006524] default_idle+0x10/0x60
Any ideas of where to look?
Regards
Anders Blomdell
return (ipipe_percpu_domain[cpuid] == ipipe_root_domain &&
!test_bit(IPIPE_STALL_FLAG,
&ipipe_root_domain->cpudata[cpuid].status));
}
Regards
Anders Blomdell
Jan Kiszka wrote:
Anders Blomdell wrote:
On a PrPMC800 (PPC 7410 processor) withe Xenomai-2.1-rc2, I get the
following if the interrupt handler takes too long (i.e. next interrupt
gets generated before the previous one has finished)
[ 42.543765] [c00c2008] spin_bug+0xa8/0xc4
[ 42.597617
Jan Kiszka wrote:
Anders Blomdell wrote:
Jan Kiszka wrote:
Anders Blomdell wrote:
On a PrPMC800 (PPC 7410 processor) withe Xenomai-2.1-rc2, I get the
following if the interrupt handler takes too long (i.e. next interrupt
gets generated before the previous one has finished)
[ 42.543765
Philippe Gerum wrote:
Anders Blomdell wrote:
On a PrPMC800 (PPC 7410 processor) withe Xenomai-2.1-rc2, I get the
following if the interrupt handler takes too long (i.e. next interrupt
gets generated before the previous one has finished)
[ 42.543765] [c00c2008] spin_bug+0xa8/0xc4
the ACPI timer.
/Anders
--
Anders Blomdell Email: [EMAIL PROTECTED]
Department of Automatic Control
Lund University Phone:+46 46 222 4625
P.O. Box 118 Fax: +46 46 138118
SE-221 00 Lund, Sweden
Anders Blomdell wrote:
> Gilles Chanteperdrix wrote:
>> On Tue, Mar 11, 2008 at 7:19 PM, Anders Blomdell
>>> To me the symptoms indicate that the high priority producer gets the mutex
>>> and
>>> signals it before the consumer has properly started to wait
.
4. A comedilib compatibilty library would be nice (but not necessary)
If all these pieces are in place, I'm more than happy to test/migrate the
drivers I use in my labs (JR3, NI M6221, DaqBoard 2000, ACPI 3106, serial)
Best regards
Anders Blomdell
--
Anders Blomdell Emai
Anders Blomdell wrote:
> Anders Blomdell wrote:
>> Hi,
>>
>> I'm trying to use rt_eepro100, for sending raw ethernet packets, but I'm
>> experincing occasionally weird behaviour.
>>
>> Versions of things:
>>
>> linux-2.6.34.5
>>
Jan Kiszka wrote:
> Am 28.10.2010 09:34, Anders Blomdell wrote:
>> Anders Blomdell wrote:
>>> Anders Blomdell wrote:
>>>> Hi,
>>>>
>>>> I'm trying to use rt_eepro100, for sending raw ethernet packets, but I'm
>>>
Jan Kiszka wrote:
> Am 28.10.2010 11:34, Anders Blomdell wrote:
>> Jan Kiszka wrote:
>>> Am 28.10.2010 09:34, Anders Blomdell wrote:
>>>> Anders Blomdell wrote:
>>>>> Anders Blomdell wrote:
>>>>>> Hi,
>>>>>>
>&
On 2010-10-28 17.09, Jan Kiszka wrote:
> Am 28.10.2010 17:05, Anders Blomdell wrote:
>> Current results:
>>
>> 1. 2.6.35.7, maxcpus=1; a few thousand rounds, freeze and this after
>> some time:
>>
>> BUG: spinlock lockup on CPU#0, raw_test/2924, c0a1b540
>
On 2010-10-29 20.06, Jan Kiszka wrote:
> Am 29.10.2010 19:42, Anders Blomdell wrote:
>> Jan Kiszka wrote:
>>
>>>>> Please provide the full kernel log, ideally also with the I-pipe tracer
>>>>> (with panic tracing) enabled.
>>>> Will recon
Jan Kiszka wrote:
Am 28.10.2010 11:34, Anders Blomdell wrote:
Jan Kiszka wrote:
Am 28.10.2010 09:34, Anders Blomdell wrote:
Anders Blomdell wrote:
Anders Blomdell wrote:
Hi,
I'm trying to use rt_eepro100, for sending raw ethernet packets,
but I'm
experincing occasionally weird
Anders Blomdell wrote:
Jan Kiszka wrote:
Am 01.11.2010 17:55, Anders Blomdell wrote:
Jan Kiszka wrote:
Am 28.10.2010 11:34, Anders Blomdell wrote:
Jan Kiszka wrote:
Am 28.10.2010 09:34, Anders Blomdell wrote:
Anders Blomdell wrote:
Anders Blomdell wrote:
Hi,
I'm trying t
On 2010-11-03 12.55, Jan Kiszka wrote:
> Am 03.11.2010 12:50, Jan Kiszka wrote:
>> Am 03.11.2010 12:44, Anders Blomdell wrote:
>>> Anders Blomdell wrote:
>>>> Jan Kiszka wrote:
>>>>> Am 01.11.2010 17:55, Anders Blomdell wrote:
>>>>>>
Jan Kiszka wrote:
additional barrier. Can you check this?
diff --git a/include/nucleus/sched.h b/include/nucleus/sched.h
index df56417..66b52ad 100644
--- a/include/nucleus/sched.h
+++ b/include/nucleus/sched.h
@@ -187,6 +187,7 @@ static inline int xnsched_self_resched_p(struct xnsched
*sched)
Anders Blomdell wrote:
Jan Kiszka wrote:
additional barrier. Can you check this?
diff --git a/include/nucleus/sched.h b/include/nucleus/sched.h
index df56417..66b52ad 100644
--- a/include/nucleus/sched.h
+++ b/include/nucleus/sched.h
@@ -187,6 +187,7 @@ static inline int xnsched_self_resched_p
Anders Blomdell wrote:
Anders Blomdell wrote:
Jan Kiszka wrote:
additional barrier. Can you check this?
diff --git a/include/nucleus/sched.h b/include/nucleus/sched.h
index df56417..66b52ad 100644
--- a/include/nucleus/sched.h
+++ b/include/nucleus/sched.h
@@ -187,6 +187,7 @@ static inline
Jan Kiszka wrote:
Am 03.11.2010 17:46, Anders Blomdell wrote:
Anders Blomdell wrote:
Anders Blomdell wrote:
Jan Kiszka wrote:
additional barrier. Can you check this?
diff --git a/include/nucleus/sched.h b/include/nucleus/sched.h
index df56417..66b52ad 100644
--- a/include/nucleus/sched.h
Jan Kiszka wrote:
Am 04.11.2010 01:13, Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Am 04.11.2010 00:56, Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Am 04.11.2010 00:44, Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Am 04.11.2010 00:18, Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Am
Jan Kiszka wrote:
Am 04.11.2010 10:26, Jan Kiszka wrote:
Am 04.11.2010 10:16, Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Take a step back and look at the root cause for this issue again. Unlocked
if need-resched
__xnpod_schedule
is inherently racy and will always b
Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Am 04.11.2010 10:26, Jan Kiszka wrote:
Am 04.11.2010 10:16, Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Take a step back and look at the root cause for this issue again. Unlocked
if need-resched
__xnpod_schedule
is inhe
Jan Kiszka wrote:
Am 04.11.2010 14:18, Anders Blomdell wrote:
Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Am 04.11.2010 10:26, Jan Kiszka wrote:
Am 04.11.2010 10:16, Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Take a step back and look at the root cause for this issue again. Unlocked
Gilles Chanteperdrix wrote:
Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Am 05.11.2010 00:25, Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Am 04.11.2010 23:08, Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
rework. Safer for now is likely to revert 56ff4329ff, keeping nucleus
debugging off
Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Am 05.11.2010 00:24, Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Am 04.11.2010 23:06, Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
At first sight, here you are more breaking things than cleaning them.
Still, it has the SMP record for my test p
Gilles Chanteperdrix wrote:
Anders Blomdell wrote:
Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Am 05.11.2010 00:24, Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
Am 04.11.2010 23:06, Gilles Chanteperdrix wrote:
Jan Kiszka wrote:
At first sight, here you are more breaking things than
configuration, sis tthat __rthal_x86_nodiv_ullimd is not
inlined, is this anybody has seen before?
Regards
Anders Blomdell
--
Anders Blomdell Email: anders.blomd...@control.lth.se
Department of Automatic Control
Lund University Phone:+46 46 222 4625
P.O. Box 118
On 12/07/2010 12:51 PM, Gilles Chanteperdrix wrote:
Anders Blomdell wrote:
When compiling Xenomai on Fedora-14 with gcc-4.5.1 [version 4.5.1
20100924 (Red Hat 4.5.1-4)], the loading of xeno_nucleus fails with the
attached kernel OOPS, a notable difference between the 4.5.1 compiled
version and
On 12/07/2010 01:09 PM, Gilles Chanteperdrix wrote:
> Anders Blomdell wrote:
>> On 12/07/2010 12:51 PM, Gilles Chanteperdrix wrote:
>>> Anders Blomdell wrote:
>>>> When compiling Xenomai on Fedora-14 with gcc-4.5.1 [version 4.5.1
>>>> 20100924 (Red
On 12/07/2010 03:14 PM, Anders Blomdell wrote:
On 12/07/2010 01:09 PM, Gilles Chanteperdrix wrote:
> Anders Blomdell wrote:
>> On 12/07/2010 12:51 PM, Gilles Chanteperdrix wrote:
>>> Anders Blomdell wrote:
>>>> When compiling Xenomai on Fedora-14 with gcc-4.5.1
On 2010-12-07 21.21, Gilles Chanteperdrix wrote:
> Anders Blomdell wrote:
>> On 12/07/2010 01:09 PM, Gilles Chanteperdrix wrote:
>> > Anders Blomdell wrote:
>> >> On 12/07/2010 12:51 PM, Gilles Chanteperdrix wrote:
>> >>> Anders Blomdell wrote:
>
On 2010-12-08 09.50, Gilles Chanteperdrix wrote:
> Anders Blomdell wrote:
>> On 2010-12-07 21.21, Gilles Chanteperdrix wrote:
>>> Anders Blomdell wrote:
>>>> On 12/07/2010 01:09 PM, Gilles Chanteperdrix wrote:
>>>> > Anders Blomdell wrote:
>>
the machine).
Would it be a good idea to pci_enable_device in mite_init as well, or will that
break something else?
Regards
Anders Blomdell
--
Anders Blomdell Email: anders.blomd...@control.lth.se
Department of Automatic Control
Lund University Phone:+46 46
On 2011-03-14 19.33, Anders Blomdell wrote:
> Which is due to the fact that pci_enable_device (mite.c) is called at
> mite_setup
> instead of mite_init. The bad thing with this, is that interrupt conflicts can
> only be found AFTER the driver has been started with analogy_config, whic
I think it would make sense to change the name conflicts between analogy and
comedi (range_unknown is one of them), to make it possible to have comedi and
analogy to coexist on the same machine, anybody in support of this?
Regards
Anders Blomdell
--
Anders Blomdell Email
On 2011-03-14 20.29, Anders Blomdell wrote:
> I think it would make sense to change the name conflicts between analogy and
> comedi (range_unknown is one of them), to make it possible to have comedi and
> analogy to coexist on the same machine, anybody in support of this?
Anybody aga
When compiling kernel 2.6.37.3 and xenomai 2.5.6 with "gcc version 4.6.0
20110530 (Red Hat 4.6.0-9) (GCC)", programs fail with -ENOSYS in
rt_task_shadow. If compiled with "gcc version 4.5.1 20100924 (Red Hat
4.5.1-4) (GCC)" everything works as expected.
Regards
Anders
On 07/08/2011 02:41 PM, Gilles Chanteperdrix wrote:
On 07/07/2011 11:47 PM, Anders Blomdell wrote:
When compiling kernel 2.6.37.3 and xenomai 2.5.6 with "gcc version 4.6.0
20110530 (Red Hat 4.6.0-9) (GCC)", programs fail with -ENOSYS in
rt_task_shadow. If compiled with "gc
On 07/08/2011 04:44 PM, Gilles Chanteperdrix wrote:
On 07/08/2011 04:06 PM, Anders Blomdell wrote:
On 07/08/2011 02:41 PM, Gilles Chanteperdrix wrote:
On 07/07/2011 11:47 PM, Anders Blomdell wrote:
When compiling kernel 2.6.37.3 and xenomai 2.5.6 with "gcc version 4.6.0
20110530 (Re
ers
--
Anders Blomdell Email: anders.blomd...@control.lth.se
Department of Automatic Control
Lund University Phone:+46 46 222 4625
P.O. Box 118 Fax: +46 46 138118
SE-221 00 Lund, Sweden
___
Xeno
On 11/30/2011 07:03 PM, Anders Blomdell wrote:
Hi, just found that
echo :06:01.0 > /sys/bus/pci/drivers/analogy_mite/unbind
does not do the same thing as
analogy_config -r analogyN
in fact it leaves the system in a state where using the driver results
in a kernel OOPS.
Will try to l
On 12/06/2011 11:47 PM, Alexis Berlemont wrote:
Hi
On Thu, Dec 1, 2011 at 4:03 PM, Anders Blomdell
wrote:
On 11/30/2011 07:03 PM, Anders Blomdell wrote:
Hi, just found that
echo :06:01.0> /sys/bus/pci/drivers/analogy_mite/unbind
does not do the same thing as
analogy_config
On 12/07/2011 08:58 AM, Anders Blomdell wrote:
On 12/06/2011 11:47 PM, Alexis Berlemont wrote:
Hi
On Thu, Dec 1, 2011 at 4:03 PM, Anders Blomdell
wrote:
On 11/30/2011 07:03 PM, Anders Blomdell wrote:
Hi, just found that
echo :06:01.0> /sys/bus/pci/drivers/analogy_mite/unbind
does
On 12/08/2011 05:19 PM, Anders Blomdell wrote:
On 12/07/2011 08:58 AM, Anders Blomdell wrote:
On 12/06/2011 11:47 PM, Alexis Berlemont wrote:
Hi
On Thu, Dec 1, 2011 at 4:03 PM, Anders Blomdell
wrote:
On 11/30/2011 07:03 PM, Anders Blomdell wrote:
Hi, just found that
echo :06:01.0
On 11/30/2011 07:03 PM, Anders Blomdell wrote:
Hi, just found that
echo :06:01.0 > /sys/bus/pci/drivers/analogy_mite/unbind
does not do the same thing as
analogy_config -r analogyN
in fact it leaves the system in a state where using the driver results
in a kernel OOPS.
Will try to l
1 - 100 of 102 matches
Mail list logo
