On 07/12/2012 09:58 PM, Kai wrote:
Hi,
I have a problem using rt_queue_write() (native skin):
As far as I understand, the function wraps around rt_queue_send() by
allocating pool memory first and memcpy-ing the user-supplied buffer
into it.
Problem: If sending fails because the queue is full (w.
On 07/13/2012 06:27 PM, Jorge Ramirez Ortiz, HCL Europe wrote:
> Please can we go back and reframe the discussion?
>
> But first I'll reiterate: do ignore the marginal issue I had with the
> framework (I ported and went over 44,785 lines of ANSI-C(kernel/user)
> and 1995 lines of C++ code in just
On 07/13/2012 01:24 PM, Jorge Ramirez Ortiz, HCL Europe wrote:
> Yes it does: the caller ignores upfront whether the call will be
> handled in realtime or non-realtime context by the driver. The client
> (of course!) can/should (it doesn't really matter for the sake of the
> argument) take the adeq
Please can we go back and reframe the discussion?
But first I'll reiterate: do ignore the marginal issue I had with the framework
(I ported and went over 44,785 lines of ANSI-C(kernel/user) and 1995 lines of
C++ code in just a few days -this one was a big pci driver-I am not really
losing
Thanks for looking into this!
I modified the patch to support both options you suggested and uploaded it
again. Both versions do work beautifully now.
- Stephan
Am 13.07.2012 um 11:15 schrieb Gilles Chanteperdrix:
> On 07/13/2012 11:00 AM, Gilles Chanteperdrix wrote:
>> On 07/12/2012 09:54 PM
On 07/13/2012 01:24 PM, Jorge Ramirez Ortiz, HCL Europe wrote:
> Yes it does: the caller ignores upfront whether the call will be
> handled in realtime or non-realtime context by the driver. The client
> (of course!) can/should (it doesn't really matter for the sake of the
> argument) take the adeq
On 07/13/2012 01:21 PM, Leopold Palomo-Avellaneda wrote:
> A Dijous 12 Juliol 2012, Gilles Chanteperdrix va escriure:
>> On 07/12/2012 05:41 PM, Roland Stigge wrote:
>>> On 07/12/2012 05:14 PM, Jeff Webb wrote:
>> I unfortunately don't have the ressources to regularly sync/update
>> debian/
[please don't top-post]
On 2012-07-13 13:24, Jorge Ramirez Ortiz, HCL Europe wrote:
> Yes it does: the caller ignores upfront whether the call will be handled in
> realtime or non-realtime context by the driver.
> The client (of course!) can/should (it doesn't really matter for the sake of
> the
Yes it does: the caller ignores upfront whether the call will be handled in
realtime or non-realtime context by the driver.
The client (of course!) can/should (it doesn't really matter for the sake of
the argument) take the adequate measures to make sure it will get into the
adequate path.
But
A Dijous 12 Juliol 2012, Gilles Chanteperdrix va escriure:
> On 07/12/2012 05:41 PM, Roland Stigge wrote:
> > On 07/12/2012 05:14 PM, Jeff Webb wrote:
> I unfortunately don't have the ressources to regularly sync/update
> debian/* in the xenomai.org dev repository.
> >>
> >> Do you have t
On 07/13/2012 12:41 PM, Jorge Ramirez Ortiz, HCL Europe wrote:
Sure, I agree with the implementation issue. Makes a lot of sense (I
think Gilles also posted on this)
But now thinking about your response (‘getting away from violation’
caught my eye J), it seems to me that RTDM (or its implementat
Sure, I agree with the implementation issue. Makes a lot of sense (I think
Gilles also posted on this)
But now thinking about your response ('getting away from violation' caught my
eye J), it seems to me that RTDM (or its implementation, or my interpretation!)
might be somehow inconsistent.
On 07/12/2012 11:29 PM, Jorge Ramirez Ortiz, HCL Europe wrote:
Hi Gilles
Information and context below.
kernel: 2.6.35.9
xenomai:2.6.0
ipipe:2.8-04
cpu atom z530 1.6HH
Error
[ 242.962195] BUG: Unhandled exception over domain Xenomai at 0x892160 -
switching to ROOT
[ 242.990052] Pid: 972, c
On 07/13/2012 11:00 AM, Gilles Chanteperdrix wrote:
> On 07/12/2012 09:54 PM, Stephan Kappertz wrote:
>> So far I found two things the AM3359 handles different compared to the
>> Igepv2 board:
>>
>> 1) MACHINE_START has .handle_irq = omap3_intc_handle_irq while it is not
>> defined in the ipipe-2
On 07/12/2012 09:54 PM, Stephan Kappertz wrote:
> So far I found two things the AM3359 handles different compared to the Igepv2
> board:
>
> 1) MACHINE_START has .handle_irq = omap3_intc_handle_irq while it is not
> defined in the ipipe-2.6 kernel repository
I see now, that is the problem. You
2012/7/12 Roland Stigge
> On 07/12/2012 05:49 PM, Gilles Chanteperdrix wrote:
> > On 07/12/2012 05:41 PM, Roland Stigge wrote:
> >> On 07/12/2012 05:14 PM, Jeff Webb wrote:
> > I unfortunately don't have the ressources to regularly sync/update
> > debian/* in the xenomai.org dev repositor
On 07/13/2012 07:51 AM, Ilesh patel wrote:
> Hello,
>
> Thank you for your kind reply
>
> I understand the error.
>
> I read the README file in /arch/x86/patches/ The README file shows
> "Xenomai supports the x86_64,x86 architecture starting with the v2.6
> Linux kernel series." and my krenel i
On 07/13/2012 09:09 AM, Stephan Kappertz wrote:
> Hi Gilles,
>
> the problem was not the .config file but the fact that CONFIG_OMAP_32K_TIMER
> was ignored for the AM3359 implementation.
>
> So in arch/arm/mach_omap2/timer.c I changed
>
>
> #ifdef C
On 07/12/2012 11:29 PM, Jorge Ramirez Ortiz, HCL Europe wrote:
[ 242.962195] BUG: Unhandled exception over domain Xenomai at 0x892160 -
switching to ROOT
Weird message, I can not seem to find it in xenomai sources. Anyway the
messa
Hi Gilles,
the problem was not the .config file but the fact that CONFIG_OMAP_32K_TIMER
was ignored for the AM3359 implementation.
So in arch/arm/mach_omap2/timer.c I changed
#ifdef CONFIG_ARCH_OMAP3
#ifndef CONFIG_IPIPE
OMAP_SYS_TIMER_INIT(3, 1, OM
20 matches
Mail list logo
