Dmitry Adamushko wrote:
> On 20/03/07, Gilles Chanteperdrix <[EMAIL PROTECTED]> wrote:
> > Muruganandam Ganapathy wrote:
> > > The board is based on the Fujitsu SOC which has the ARM926EJ processor
> core.
> > >
> > > This board has SPI, I2C and 10/100 ethernet interfaces and it can
> sup
Gilles Chanteperdrix wrote:
> Dmitry Adamushko wrote:
> > On 20/03/07, Gilles Chanteperdrix <[EMAIL PROTECTED]> wrote:
> > > Muruganandam Ganapathy wrote:
> > > > The board is based on the Fujitsu SOC which has the ARM926EJ processor
> > core.
> > > >
> > > > This board has SPI, I2C and 10
Gilles Chanteperdrix wrote:
> Dmitry Adamushko wrote:
> > On 20/03/07, Gilles Chanteperdrix <[EMAIL PROTECTED]> wrote:
> > > Muruganandam Ganapathy wrote:
> > > > The board is based on the Fujitsu SOC which has the ARM926EJ processor
> > core.
> > > >
> > > > This board has SPI, I2C and 10
Jan Kiszka wrote:
> I think implementing coloured caches (with reservations for RT
> processes) could be an option as well. Once RT context switches no
> longer require full cache flushes, those for non-RT processes could be
> made interruptible. But all this would require heavy Linux hacking, I'm
Gilles Chanteperdrix wrote:
> Jan Kiszka wrote:
>> I think implementing coloured caches (with reservations for RT
>> processes) could be an option as well. Once RT context switches no
>> longer require full cache flushes, those for non-RT processes could be
>> made interruptible. But all this would
Jan Kiszka wrote:
> Gilles Chanteperdrix wrote:
>
>>Jan Kiszka wrote:
>>
>>>I think implementing coloured caches (with reservations for RT
>>>processes) could be an option as well. Once RT context switches no
>>>longer require full cache flushes, those for non-RT processes could be
>>>made interru
Wolfgang Grandegger wrote:
Hello,
on the Xenomai mailing list the topic "bus error flooding" popped up
again. Various users reported trouble due to high bus error rates and
bad impact on latencies. Some discussion is going on on how to avoid
such flooding. I have already implemented "on-deman
Hello,
I must write on my socket(rt_dev_sendmsg()) verry fast. Often I have
then a memory overflow. Is it possible?
How can I examine whether sufficient memory is available?
Thanks.
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna
Oliver Hartkopp wrote:
Wolfgang Grandegger wrote:
Wolfgang Grandegger wrote:
But flooding can still occur and we
are thinking about a better way of downscaling or temporarily disabling
them. Socket-CAN currently restarts the controller after 200 bus errors.
My preferred solution for RT-Sock
Hello,
Robin Walser wrote:
Hello,
I must write on my socket(rt_dev_sendmsg()) verry fast. Often I have
then a memory overflow. Is it possible?
How can I examine whether sufficient memory is available?
Are you using RT-Socket-CAN? Could you please provide more detailed
information like what
Are you using RT-Socket-CAN? Could you please provide more detailed
information like what is the returned error code and are there kernel
log messages (visible with $ dmsg)?
Wolfgang.
My programm based on frag-ip:
http://www.rts.uni-hannover.de/rtnet/lxr/source//examples/xenomai/native/frag-
Wolfgang Grandegger wrote:
> Oliver Hartkopp wrote:
>> Wolfgang Grandegger wrote:
>>> Wolfgang Grandegger wrote:
>>>
But flooding can still occur and we
are thinking about a better way of downscaling or temporarily disabling
them. Socket-CAN currently restarts the controller aft
Robin Walser wrote:
>
>> Are you using RT-Socket-CAN? Could you please provide more detailed
>> information like what is the returned error code and are there kernel
>> log messages (visible with $ dmsg)?
>>
>> Wolfgang.
> My programm based on frag-ip:
> http://www.rts.uni-hannover.de/rtnet/lxr/so
13 matches
Mail list logo
