Hi
First I was surprised that a lot of vxworks return -1 unless
running inside a thread created by taskSpawn, e.g. taskIdSelf
or taskMCreate return -1.
Then I did added a very simple sequence of
semMCreate
semTake
semGive
and now semGive returned me -1 (ERROR). This puzzled me even more, as
this
Stelian Pop wrote:
> Hi,
>
> I need to be able to map an IO memory buffer to userspace from a RTDM
> driver.
>
> rtdm_mmap_to_user() seems to do what I need, but it doesn't work. Its
> code thinks that all virtual addresses between VMALLOC_START and
> VMALLOC_END are obtained through vmalloc() an
Hi,
I need to be able to map an IO memory buffer to userspace from a RTDM
driver.
rtdm_mmap_to_user() seems to do what I need, but it doesn't work. Its
code thinks that all virtual addresses between VMALLOC_START and
VMALLOC_END are obtained through vmalloc() and tries to call
xnarch_remap_vm_pag
On Mon, 2006-09-11 at 20:13 +0200, Wolfgang Grandegger wrote:
> Matthias Fuchs wrote:
> > On Monday 11 September 2006 17:46, Wolfgang Grandegger wrote:
> >>> A possible explanation is that configurations only using the timer IRQ
> >>> are not affected, since the decrementer is not subject to this i
On 15/09/06, Philippe Gerum <[EMAIL PROTECTED]> wrote:
On Fri, 2006-09-15 at 00:12 +0200, Dmitry Adamushko wrote:[...]>> And it's not a good idea to get ipipe_catch_event() buzy spinning as> (as I understand) ipipe_dispatch_event() may take, in general, an
> unbounded amount of time.>Actually, this
On Fri, 2006-09-15 at 10:33 +0200, Jan Kiszka wrote:
> Philippe Gerum wrote:
> > diff -uNrp 2.6.17-ipipe-1.3-10/kernel/ipipe/core.c
> > 2.6.17-ipipe/kernel/ipipe/core.c
> > --- 2.6.17-ipipe-1.3-10/kernel/ipipe/core.c 2006-09-15 10:13:15.0
> > +0200
> > +++ 2.6.17-ipipe/kernel/ipipe/core.c
Philippe Gerum wrote:
> diff -uNrp 2.6.17-ipipe-1.3-10/kernel/ipipe/core.c
> 2.6.17-ipipe/kernel/ipipe/core.c
> --- 2.6.17-ipipe-1.3-10/kernel/ipipe/core.c 2006-09-15 10:13:15.0
> +0200
> +++ 2.6.17-ipipe/kernel/ipipe/core.c 2006-09-14 20:09:22.0 +0200
> ...
> @@ -638,6 +642,7
On Fri, 2006-09-15 at 00:12 +0200, Dmitry Adamushko wrote:
[...]
>
> And it's not a good idea to get ipipe_catch_event() buzy spinning as
> (as I understand) ipipe_dispatch_event() may take, in general, an
> unbounded amount of time.
>
Actually, this is not an issue, since there is no requirem
