Benjamin Zores wrote:
On Tue, 05 Dec 2006 14:09:38 +0100
Wolfgang Grandegger [EMAIL PROTECTED] wrote:
Unfortunately, generic applies only to the Linux part. I realized,
that the new IPIPE support for the genirqs requires even more
arch-specific modifications than the old interface
Philippe Gerum wrote:
On Tue, 2006-12-05 at 18:37 +0100, Wolfgang Grandegger wrote:
Jan Kiszka wrote:
Wolfgang Grandegger wrote:
Benjamin Zores wrote:
On Tue, 05 Dec 2006 11:17:07 +0100
Wolfgang Grandegger [EMAIL PROTECTED] wrote:
I have now a preliminary patch for adeos-ipipe-2.6.19-ppc
Hi Philippe,
what are the major differences between the ADEOS-IPIPE patch versions
v1.5 and v1.6, apart from support for the new genirq layer. I realized,
that the arch specific files ipipe-core.c and ipipe-root.c have been
merged into ipipe.c.
Wolfgang.
Benjamin Zores wrote:
On Mon, 18 Dec 2006 13:12:54 +0100
Wolfgang Grandegger [EMAIL PROTECTED] wrote:
Hallo,
attached is patch for Xenomai upgrading the ADEOS IPIPE patches for the
PPC tree. Here is the ChangeLog entry:
2006-12-18 Wolfgang Grandegger [EMAIL PROTECTED]
* ksrc
Benjamin Zores wrote:
On Mon, 18 Dec 2006 14:06:15 +0100
Wolfgang Grandegger [EMAIL PROTECTED] wrote:
I don't understand your questions. These patches are for the PPC tree.
The POWERPC is still not supported. Do you already have a working port
for the PowerPC tree 2.6.18?
I send one a month
Hi Niklaus,
Niklaus Giger wrote:
Hi
After switching my development environment to a MacMini and using the ELDK 4.0
I discovered that my examples for building using a cross-compiler for my
PPC405 target were not correct. (Maybe a few of my previous problems were
caused by not correctly
Niklaus Giger wrote:
Hi
I tried to simply an example program how to use interrupts
with Xenomai (see attached Makefile dma_4xx_int_module.c).
The interrupt part of the example works, but the DMA transfer (memory to
memory) using the OnChipMemory fails. I think I must somewhere specify that
Jan Kiszka wrote:
Niklaus Giger wrote:
Am Donnerstag, 18. Januar 2007 09:31 schrieb Wolfgang Grandegger:
Niklaus Giger wrote:
Hi
I tried to simply an example program how to use interrupts
with Xenomai (see attached Makefile dma_4xx_int_module.c).
The interrupt part of the example works
Hi Philippe,
I'm currently porting RTDM over Linux with the real-time preemption
patch (RTDM-native) and I have a first prototype running and can send
and receive CAN messages with RT-Socket-CAN. Time to speak about code
(re-)organisation and integration into Xenomai. I briefly discussed this
Jan Kiszka wrote:
Jan Kiszka wrote:
Hi all,
fiddling with latest Xenomai trunk and 2.3.x on one of our robots (there
is still a bug in trunk /wrt broken timeouts of rt_dev_read on
xeno_16550A - different issue...), I ran into a weird behaviour of
rtcanrecv:
I have a continuous stream of a few
Hi Jan,
Jan Kiszka wrote:
Hi all,
fiddling with latest Xenomai trunk and 2.3.x on one of our robots (there
is still a bug in trunk /wrt broken timeouts of rt_dev_read on
xeno_16550A - different issue...), I ran into a weird behaviour of
rtcanrecv:
I have a continuous stream of a few thousand
Jan Kiszka wrote:
Hi Wolfgang,
fiddling with the CAN utils, I noticed the behaviour that rtcansend on
freshly registered but stopped devices simply blocks. And when you
meanwhile call rtcanconfig up on that device, rtcansend will continue to
block.
This is a bug, the send function should
Hi Jan,
Jan Kiszka wrote:
Hi Wolfgang,
fiddling with the CAN utils, I noticed the behaviour that rtcansend on
freshly registered but stopped devices simply blocks. And when you
meanwhile call rtcanconfig up on that device, rtcansend will continue to
block.
I see the expected behavior on
Jan Kiszka wrote:
Wolfgang Grandegger wrote:
Hi Jan,
Jan Kiszka wrote:
Hi Wolfgang,
fiddling with the CAN utils, I noticed the behaviour that rtcansend on
freshly registered but stopped devices simply blocks. And when you
meanwhile call rtcanconfig up on that device, rtcansend will continue
Jan Kiszka wrote:
Wolfgang Grandegger wrote:
Jan Kiszka wrote:
Wolfgang Grandegger wrote:
Hi Jan,
Jan Kiszka wrote:
Hi Wolfgang,
fiddling with the CAN utils, I noticed the behaviour that rtcansend on
freshly registered but stopped devices simply blocks. And when you
meanwhile call
Jan Kiszka wrote:
Hi Wolfgang,
unless I messed something up, the first patch aligns the implementation of
Socket-CAN filters in Xenomai with their current specification. Right now, if
you
set a filter on a standard frame ID, you will also receive extended frames with
the same ID. In contrast,
Wolfgang Grandegger wrote:
Jan Kiszka wrote:
Hi Wolfgang,
unless I messed something up, the first patch aligns the
implementation of
Socket-CAN filters in Xenomai with their current specification. Right
now, if you
set a filter on a standard frame ID, you will also receive extended
frames
Jan Kiszka wrote:
Oliver Hartkopp wrote:
When you're touching anything inside your API, have you ever thought to add
__attribute__ ((aligned(8)))
to the data[8] element of the struct can_frame?
This would enable you to make 64 bit compares directly in the data
section of the can_frame ...
Jan Kiszka wrote:
Wolfgang Grandegger wrote:
...
Attached is a patch adding the CAN_INV_FILTER feature. It also updates
the doc. Now the filter scheme should be compatible with Socket-CAN. If
it's OK, I will check it in (or you can do it).
Wolfgang
Jan Kiszka wrote:
Wolfgang Grandegger wrote:
Index: ksrc/drivers/can/rtcan_raw_filter.c
===
--- ksrc/drivers/can/rtcan_raw_filter.c(revision 2193)
+++ ksrc/drivers/can/rtcan_raw_filter.c(working copy)
@@ -55,13 +55,13
Niklaus Giger wrote:
Hi
Compiling ppc fails for me with 2.6.19 kernels.
( I compile on a Pegasos PPC 601 Debian Linux).
If I use ARCH=ppc then I get the following error:
CHK include/linux/version.h
CHK include/linux/utsrelease.h
CHK include/linux/compile.h
gcc:
Jan Kiszka wrote:
Wolfgang Grandegger wrote:
...
Attached is a revised patch including change log entry. As this patch
just extends the existing filter capabilities, it could be applied to
trunk and the 2.3.x branch as well.
You are just forgetting the other changes to the filter mechanism
Jan Kiszka wrote:
Wolfgang Grandegger wrote:
Hi Jan,
I have two more patches in my quilt stack:
Sigh. ;)
2007-02-18 Wolfgang Grandegger [EMAIL PROTECTED]
* ksrc/drivers/can/rtcan_raw.c, ksrc/drivers/can/rtcan_socket.h: add
prefix RTCAN_ to TIMESTAMP_SIZE, HAS_TIMESTAMP
Jan Kiszka wrote:
Wolfgang Grandegger wrote:
Jan Kiszka wrote:
Jan Kiszka wrote:
I thought about this issue again and found the reason for my vague bad
feeling: re-init is not atomic, thus racy. But also the test+sem_init
pattern I suggested is not save.
I guess we need to enhance
Jan Kiszka wrote:
Wolfgang Grandegger wrote:
Jan Kiszka wrote:
Wolfgang Grandegger wrote:
Jan Kiszka wrote:
Jan Kiszka wrote:
I thought about this issue again and found the reason for my vague bad
feeling: re-init is not atomic, thus racy. But also the test+sem_init
pattern I suggested
Hello,
I just applied the following bug fix to the trunk for RT-Socket-CAN when
using the no-filter definition. Here is the ChangeLog entry:
2007-02-19 Wolfgang Grandegger [EMAIL PROTECTED]
* ksrc/drivers/can/rtcan_raw.c (rtcan_raw_bind),
ksrc/drivers/can/rtcan_socket.h: Fix bug using
This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
Wolfgang Grandegger wrote:
BTW: some time ago I provided a patch to make the CAN utility programs
part of the Doxygen documentation. IIRC, we said it's nice to have
hyperlinked examples in general.
Some link at hand? Does
Hi Gilles and Jan,
Jan Kiszka wrote:
Wolfgang Grandegger wrote:
BTW: some time ago I provided a patch to make the CAN utility programs
part of the Doxygen documentation. IIRC, we said it's nice to have
hyperlinked examples in general.
Some link at hand? Does it still apply? Sounds like
Hi Jan,
Jan Kiszka wrote:
Wolfgang Grandegger wrote:
Hi Jan,
currently the RT-Socket-CAN drivers maintains it's own version or
release number. As RT-Socket-CAN is part of Xenomai, I do not see the
need for it (and so far I did not update it). What is the intended use
of driver_version
Hello,
here is the boot log of an hangup of 2.6.20 with I-pipe 1.7-02 and
Xenomai todays trunk. I already reported this hangup a while ago but now
I get an oops. At that time Gilles said that lapic on old Athlons might
be buggy. Does the attached boot log confirm this assumption? 2.6.20-rt8
Gilles Chanteperdrix wrote:
Wolfgang Grandegger wrote:
Hello,
here is the boot log of an hangup of 2.6.20 with I-pipe 1.7-02 and
Xenomai todays trunk. I already reported this hangup a while ago but now
I get an oops. At that time Gilles said that lapic on old Athlons might
Philippe Gerum wrote:
On Sun, 2007-02-25 at 16:09 +0100, Wolfgang Grandegger wrote:
Gilles Chanteperdrix wrote:
Wolfgang Grandegger wrote:
Hello,
here is the boot log of an hangup of 2.6.20 with I-pipe 1.7-02 and
Xenomai todays trunk. I already reported this hangup a while ago
Hello,
attached is a patch improving the Doxygen generated documentation. If
nobody complains, I will commit it to the trunk. Nevertheless, it
remains the problem, that some symbols are not hyperlinked, mainly most
of the rt_dev_* functions. For some strange reasons it works for a few,
e.g.
Heikki Lindholm wrote:
Jeff Koftinoff kirjoitti:
Hi Everyone. I would really like to get Xenomai working on the new
Freescale 8641D dual core G4.
I see that for linux 2.6.19, Xenomai does not support CONFIG_PPC_MERGE
or architectures=powerpc instead of 'ppc'.
Weren't there some
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-demand bus error
interrupts. Bus
Jan Kiszka wrote:
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
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-demand
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
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
Jan Kiszka wrote:
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 after
Hartkopp, Oliver (K-GEFE/E) wrote:
Even if i know, that my reply with our f*cking exchange mailserver will
break the thread ...
Jan Kiszka wrote:
I think Oliver's suggestions points in the right direction. But instead
of only coding a timer into the stack, I still vote for closing the loop
Oliver Hartkopp wrote:
Wolfgang Grandegger wrote:
Jan Kiszka wrote:
Wolfgang Grandegger wrote:
Oliver Hartkopp wrote:
I would tend to reduce the notifications to the user by creating a
timer at the first bus error interrupt. The first BE irq would lead
to a CAN_ERR_BUSERROR and after
wrote:
Wolfgang Grandegger wrote:
Jan Kiszka wrote:
Wolfgang Grandegger wrote:
Oliver Hartkopp wrote:
I would tend to reduce the notifications to the user by creating a
timer at the first bus error interrupt. The first BE irq would
lead to a CAN_ERR_BUSERROR and after a (configurable) time
(e.g
Wolfgang Grandegger wrote:
Jan Kiszka wrote:
Oliver Hartkopp wrote:
Additionally to the written stuff below (please read that first), i want
to remark:
- Remember that we are talking about a case that is not a standard
operation mode but a (temporary) error condition that normally leads
Jan Kiszka wrote:
Hi Wolfgang,
it's late, so I may have misread somecode, but don't you update the
iovec descriptors a user passes on send/recvmsg on return (namely
iovec_len)? I received some complaints about this /wrt to in-kernel CAN
stack usage.
It's done here:
Hello,
Jan Kiszka wrote:
Wolfgang Grandegger wrote:
...
Attached is the patch and it works fine. The key function
rtcan_sja_enable_bus_err() is called from sendmsg():
void rtcan_sja_enable_bus_err(struct rtcan_device *dev)
{
struct rtcan_sja1000 *chip = (struct rtcan_sja1000 *)dev-priv
Jan Kiszka wrote:
Wolfgang Grandegger wrote:
OK, I have just commited the following changes:
2007-04-02 Wolfgang Grandegger [EMAIL PROTECTED]
* ksrc/drivers/can/*: The option CONFIG_XENO_DRIVERS_CAN_BUS_ERR now
enables bus error interrupts when an application is calling a receive
Jan Kiszka wrote:
Hi Wolfgang,
something is inconsistent about CAN_RAW in RT-Socket-CAN compared to
plain Socket-CAN. Also, the latter doesn't know any CAN_PROTO_xxx unless
I oversee something. Please have a look.
There is CAN_PROTO_RAW defined and I have added some time ago CAN_RAW to
Jan Kiszka wrote:
Wolfgang Grandegger wrote:
Jan Kiszka wrote:
Hi Wolfgang,
something is inconsistent about CAN_RAW in RT-Socket-CAN compared to
plain Socket-CAN. Also, the latter doesn't know any CAN_PROTO_xxx unless
I oversee something. Please have a look.
There is CAN_PROTO_RAW defined
Wolfgang Grandegger wrote:
Jan Kiszka wrote:
Wolfgang Grandegger wrote:
Jan Kiszka wrote:
Hi Wolfgang,
something is inconsistent about CAN_RAW in RT-Socket-CAN compared to
plain Socket-CAN. Also, the latter doesn't know any CAN_PROTO_xxx unless
I oversee something. Please have a look
Jan Kiszka wrote:
Wolfgang Grandegger wrote:
Wolfgang Grandegger wrote:
Jan Kiszka wrote:
Wolfgang Grandegger wrote:
Jan Kiszka wrote:
Hi Wolfgang,
something is inconsistent about CAN_RAW in RT-Socket-CAN compared to
plain Socket-CAN. Also, the latter doesn't know any CAN_PROTO_xxx
Jan Kiszka wrote:
Wolfgang Grandegger wrote:
Hello,
I needed the attached patch to get the user space stuff of Xenomai
trunk, head of SVN cross compiled for PPC. Please apply. Thanks.
I would say, just go ahead. The fixes are obvious and correct.
Applied, already 2 days ago. For some
Hello,
sorry, didn't realize the CC to the xenomai-core ML :-(. Here the
English translation:
Wolfgang Grandegger wrote:
Hallo Jan,
Jan Kiszka wrote:
Hi Wolfgang,
I came across the fact that xeno_can_peak_dng is autoloaded on 2.6 due to
its PnP announcement via MODULE_DEVICE_TABLE
Jan Kiszka wrote:
Hi Wolfgang,
can we just switch over to pci_register_driver in order to avoid
deprecated (and soon removed) pci_module_init? Or do we also need some
wrapper for older 2.4 kernels (latest 2.4 is already aligned with 2.6)?
Likely. I will do some tests tomorrow.
Wolfgang.
Hi Jan,
Jan Kiszka wrote:
Hi Wolfgang,
can we just switch over to pci_register_driver in order to avoid
deprecated (and soon removed) pci_module_init? Or do we also need some
wrapper for older 2.4 kernels (latest 2.4 is already aligned with 2.6)?
It works with 2.4.25, at least and from my
Hello,
the attached patch changes:
2007-07-09 Wolfgang Grandegger [EMAIL PROTECTED]
* include/asm-generic/wrappers.h: add __deprecated for Linux 2.4.
Wolfgang.
Index: include/asm-generic/wrappers.h
===
--- include/asm
Jan Kiszka wrote:
Philippe Gerum wrote:
On Mon, 2007-07-09 at 16:45 +0200, Wolfgang Grandegger wrote:
Hello,
the attached patch changes:
2007-07-09 Wolfgang Grandegger [EMAIL PROTECTED]
* include/asm-generic/wrappers.h: add __deprecated for Linux 2.4.
Merged, thanks.
You
Philippe Gerum wrote:
On Mon, 2007-07-09 at 17:02 +0200, Jan Kiszka wrote:
Philippe Gerum wrote:
On Mon, 2007-07-09 at 16:50 +0200, Jan Kiszka wrote:
Philippe Gerum wrote:
On Mon, 2007-07-09 at 16:45 +0200, Wolfgang Grandegger wrote:
Hello,
the attached patch changes:
2007-07-09
Hello,
yesterday I realized a problem with compat_module_param_array() with
ksrc/drivers/can/sja1000/rtcan_mem.c under Linux 2.4. It uses
CONFIG_XENO_DRIVERS_CAN_SJA1000_MEM_MAX_DEV to define the number of mem
devices, which is set to '(4)' by make [menuc]onfig. Unfortunately,
the brackets '()'
juanba romance wrote:
Hello Wolfgang this is the previous mail thread maintained with Jan and
i hope it answer your question
Yes, it shows that you are aware of RT-Socket-CAN but it does not answer
yet Jan's question:
-- Forwarded message --
From: *Jan Kiszka* [EMAIL
juanba romance wrote:
[...]
After review your current user interface i can not understand how a RF
cycle flows through the user application
holding as much as possible the latency at the receiver side. Maybe it's
my own misunderstanding.
Your just send a remote transmission request message
Hello,
the attached patch fixes the following compilation error with Xenomai's
head of trunk under Linux 2.4:
kernel/kernel.o(.text+0x135a4): In function `__rthal_generic_full_divmod64':
/temp/rtcan/devel/linuxppc_2_4_devel-xenomai/kernel/xenomai/arch/generic/hal.c:918:
undefined reference
Hello,
the following patch changes:
2007-08-22 Wolfgang Grandegger [EMAIL PROTECTED]
* ksrc/drivers/can/sja1000: Add the RT-Socket-CAN SJA1000 driver
rtcan_ems_pci.c for the EMS CPC PCI card from EMS Dr. Thomas
Wuensche (http://www.ems-wuensche.de).
I would like
Hello,
the following patch fixes:
2007-08-22 Wolfgang Grandegger [EMAIL PROTECTED]
* ksrc/drivers/can/rtcan_socket.c: protect the list of sockets
per device properly when adding or deleting sockets.
It should be applied to Xenomai's trunk and v2.3.x branch.
Wolfgang.
Index
Jan Kiszka wrote:
Wolfgang Grandegger wrote:
Hello,
the following patch changes:
2007-08-22 Wolfgang Grandegger [EMAIL PROTECTED]
* ksrc/drivers/can/sja1000: Add the RT-Socket-CAN SJA1000 driver
rtcan_ems_pci.c for the EMS CPC PCI card from EMS Dr. Thomas
Wuensche (http
Hi Daniel,
Daniel Schnell wrote:
Hi,
I have cross compiled Xenomai latest trunk (Adeos-1.7) for the Denx
2.6.23 tree for a PowerPC5200 arch, and the only annoyance I can see is
that MSCAN driver for Xenomai is not compiling because of missing
defines/enums in asm-powerpc/mpc52xx.h in
Benjamin ZORES wrote:
Wolfgang Grandegger wrote:
Benjamin ZORES wrote:
Philippe Gerum wrote:
Yes. I have tested 2.6.22-DENX over two Freescale boards, namely
mpc52xx
and mpc8548, using this very same setup. Btw, you will need to pick
2.0-01 which landed today in the repo, since I fixed
Daniel Schnell wrote:
Wolfgang Grandegger wrote:
I have a patch already since a while but forgot to post it. Could you
please give the attached patch a try?
I have given the patch a try and it doesn't quite work out of the box,
as there is an index off-by-one error concerning
Daniel Schnell wrote:
Giammarco Zacheo wrote:
Does anybody ever tried to port Xenomai on a Efika board?
http://www.genesippc.com/efika.php
It is a freescale powerpc based board, with some patches to make
linux work on it. I have read some emails on the net talking about
RTAI, so what about
Hello,
I just realized that the patch
http://svn.gna.org/viewcvs/xenomai/branches/v2.3.x/ksrc/arch/powerpc/hal.c?rev=3132r1=2616r2=3132
breaks compilation of the Linux 2.4 kernel for PPC:
hal.c: In function `rthal_set_local_cpu_timer':
hal.c:95: warning: implicit declaration of function
Hello,
how do I cancel or delete a Xenomai POSIX thread running in primary
context from a higher priority thread? IIUC, pthread_kill() can only be
used in secondary context. I tried pthread_cancel(), but it only works
when hitting a cancelation point, e.g. pthread_testcancel(). Setting
Gilles Chanteperdrix wrote:
On Dec 6, 2007 1:31 PM, Wolfgang Grandegger [EMAIL PROTECTED] wrote:
Hello,
how do I cancel or delete a Xenomai POSIX thread running in primary
context from a higher priority thread? IIUC, pthread_kill() can only be
used in secondary context. I tried
Gilles Chanteperdrix wrote:
On Dec 6, 2007 2:24 PM, Wolfgang Grandegger [EMAIL PROTECTED] wrote:
Gilles Chanteperdrix wrote:
On Dec 6, 2007 1:31 PM, Wolfgang Grandegger [EMAIL PROTECTED] wrote:
Hello,
how do I cancel or delete a Xenomai POSIX thread running in primary
context from a higher
Gilles Chanteperdrix wrote:
On Dec 6, 2007 2:28 PM, Gilles Chanteperdrix
[EMAIL PROTECTED] wrote:
On Dec 6, 2007 2:24 PM, Wolfgang Grandegger [EMAIL PROTECTED] wrote:
Gilles Chanteperdrix wrote:
On Dec 6, 2007 1:31 PM, Wolfgang Grandegger [EMAIL PROTECTED] wrote:
Hello,
how do I cancel
Hi Gilles,
Gilles Chanteperdrix wrote:
On Dec 6, 2007 3:05 PM, Wolfgang Grandegger [EMAIL PROTECTED] wrote:
Gilles Chanteperdrix wrote:
On Dec 6, 2007 2:28 PM, Gilles Chanteperdrix
[EMAIL PROTECTED] wrote:
On Dec 6, 2007 2:24 PM, Wolfgang Grandegger [EMAIL PROTECTED] wrote:
Gilles
Gilles Chanteperdrix wrote:
Gilles Chanteperdrix wrote:
Wolfgang Grandegger wrote:
Hi Gilles,
Gilles Chanteperdrix wrote:
On Dec 6, 2007 3:05 PM, Wolfgang Grandegger [EMAIL PROTECTED] wrote:
Gilles Chanteperdrix wrote:
On Dec 6, 2007 2:28 PM, Gilles
Gilles Chanteperdrix wrote:
Wolfgang Grandegger wrote:
Gilles Chanteperdrix wrote:
Gilles Chanteperdrix wrote:
Wolfgang Grandegger wrote:
Hi Gilles,
Gilles Chanteperdrix wrote:
On Dec 6, 2007 3:05 PM, Wolfgang Grandegger [EMAIL PROTECTED]
wrote
Gilles Chanteperdrix wrote:
Wolfgang Grandegger wrote:
Gilles Chanteperdrix wrote:
Gilles Chanteperdrix wrote:
Wolfgang Grandegger wrote:
Hi Gilles,
Gilles Chanteperdrix wrote:
On Dec 6, 2007 3:05 PM, Wolfgang Grandegger [EMAIL PROTECTED]
wrote
Thomas Wiedemann wrote:
Hi,
we had a problem compiling the CAN-Driver for the last release candidate
when
shared interrupts had been enabled, because of the re-named option
CONFIG_XENO_OPT_SHIRQ_LEVEL.. After a quick look, version 2.4.0 still
doesn't fix this. A patch is included (for
Gilles Chanteperdrix wrote:
Wolfgang Grandegger wrote:
Gilles Chanteperdrix wrote:
Wolfgang Grandegger wrote:
Gilles Chanteperdrix wrote:
Gilles Chanteperdrix wrote:
Wolfgang Grandegger wrote:
Hi Gilles,
Gilles Chanteperdrix wrote
Gilles Chanteperdrix wrote:
On Dec 10, 2007 4:20 PM, Wolfgang Grandegger [EMAIL PROTECTED] wrote:
Gilles Chanteperdrix wrote:
Wolfgang Grandegger wrote:
Gilles Chanteperdrix wrote:
Gilles Chanteperdrix wrote:
Wolfgang Grandegger wrote:
Hi Gilles,
Gilles
Wolfgang Grandegger wrote:
Gilles Chanteperdrix wrote:
On Dec 10, 2007 4:20 PM, Wolfgang Grandegger [EMAIL PROTECTED] wrote:
Gilles Chanteperdrix wrote:
Wolfgang Grandegger wrote:
Gilles Chanteperdrix wrote:
Gilles Chanteperdrix wrote:
Wolfgang Grandegger wrote:
Hi Gilles
Gilles Chanteperdrix wrote:
Wolfgang Grandegger wrote:
After adding pthread_getschedparam() I realized, that policy was 1 and
prio 10 and not as expected 5. The corresponding attribute settings
before calling pthread_create have been ignored somehow. Am I doing
something wrong
Wolfgang Grandegger wrote:
The attached test application using a more sophisticated signal handling
works fine on my MPC5200-board running Linux 2.6.23 and Xenomai trunk.
Going to try it tomorrow on my PC.
It works fine as well on my PC with Linux 2.6.23 and Xenomai trunk and
now also
Gilles Chanteperdrix wrote:
On Dec 11, 2007 2:20 PM, Wolfgang Grandegger [EMAIL PROTECTED] wrote:
Wolfgang Grandegger wrote:
The attached test application using a more sophisticated signal handling
works fine on my MPC5200-board running Linux 2.6.23 and Xenomai trunk.
Going to try it tomorrow
Gilles Chanteperdrix wrote:
Wolfgang Grandegger wrote:
Gilles Chanteperdrix wrote:
On Dec 11, 2007 2:20 PM, Wolfgang Grandegger [EMAIL PROTECTED] wrote:
Wolfgang Grandegger wrote:
The attached test application using a more sophisticated signal
handling
works fine on my
Gilles Chanteperdrix wrote:
Wolfgang Grandegger wrote:
Gilles Chanteperdrix wrote:
Wolfgang Grandegger wrote:
Gilles Chanteperdrix wrote:
On Dec 11, 2007 2:20 PM, Wolfgang Grandegger [EMAIL PROTECTED]
wrote:
Wolfgang Grandegger wrote:
The attached test
Gilles Chanteperdrix wrote:
On Dec 12, 2007 11:58 AM, Wolfgang Grandegger [EMAIL PROTECTED] wrote:
Hi Gilles,
the attached patch adds the missing function __real_pthread_kill to
src/skins/posix/wrappers.c.
This should already been in the trunk. Not yet in v2.4.x though.
$ svn update
U
Hi Gilles,
the attached patch adds the missing function __real_pthread_kill to
src/skins/posix/wrappers.c.
Wolfgang.
+ diff -u xenomai-2.3.2/src/skins/posix/wrappers.c.ORIG xenomai-2.3.2/src/skins/posix/wrappers.c
--- xenomai-2.3.2/src/skins/posix/wrappers.c.ORIG 2006-12-26 19:39:00.0
Gilles Chanteperdrix wrote:
Wolfgang Grandegger wrote:
Gilles Chanteperdrix wrote:
Wolfgang Grandegger wrote:
Gilles Chanteperdrix wrote:
Wolfgang Grandegger wrote:
Gilles Chanteperdrix wrote:
On Dec 11, 2007 2:20 PM, Wolfgang Grandegger [EMAIL
PROTECTED
Wolfgang Grandegger wrote:
Thomas Wiedemann wrote:
Hi,
we had a problem compiling the CAN-Driver for the last release candidate
when
shared interrupts had been enabled, because of the re-named option
CONFIG_XENO_OPT_SHIRQ_LEVEL.. After a quick look, version 2.4.0 still
doesn't fix
Philippe Gerum wrote:
Wolfgang Grandegger wrote:
Wolfgang Grandegger wrote:
Thomas Wiedemann wrote:
Hi,
we had a problem compiling the CAN-Driver for the last release candidate
when
shared interrupts had been enabled, because of the re-named option
CONFIG_XENO_OPT_SHIRQ_LEVEL.. After
Hello,
recent versions of Xenomai include the header file linux/uaccess.h in
xenomai/include/asm-generic/syscall.h which does not exist under Linux
2.4. asm/uaccess should be used instead. Any clever idea how to fix it
(without using #ifdefs)?
Wolfgang.
Hello,
attached is a fix for a nice bug in xnintr_irq_proc() of Xenomai v2.3.x.
Check for tabs. I have not checked if it's present in recent versions as
well.
Wolfgang.
Index: ksrc/nucleus/intr.c
===
--- ksrc/nucleus/intr.c
Philippe Gerum wrote:
Wolfgang Grandegger wrote:
Hello,
attached is a fix for a nice bug in xnintr_irq_proc() of Xenomai v2.3.x.
Mmf... Thanks.
Check for tabs. I have not checked if it's present in recent versions as
well.
Even if a bit overkill, I would even go for something like
p
axel axel wrote:
Hi,
i want to use floating point in module with some xenomai task.
I understand that i can use floating point if i implement some functions
( xnarch_fpu_init.. ).
Ok for this but if i try to compile the module, the compiler ( gcc 3.4.3
for arm ) says me there are
Hello,
I tried to test the POSIX example program satch.c under Linux 2.4.25 for
PPC. I was able to fix a few issues but the module does still not load.
I have attached a patch for Xenomai 2.4.2 fixing:
- User-space satch: It was necessary to move time.h and signal.h to the
end of the include
Gilles Chanteperdrix wrote:
On Wed, Mar 12, 2008 at 11:22 AM, Wolfgang Grandegger [EMAIL PROTECTED]
wrote:
Gilles Chanteperdrix wrote:
Wolfgang Grandegger wrote:
Hello,
I tried to test the POSIX example program satch.c under Linux 2.4.25
for
PPC. I was able to fix
Hello,
the patch below fixes some issues with cross compiling the
DENX linuxppc_2_4_devel tree (2.4.25) for the MPC5200. I
think they are present on Xenomai trunk as well (and even
a few more).
Wolfgang.
Index: include/asm-generic/wrappers.h
Hello,
the following patch fixes a problem building the Xenomai user
space applications for the MPC5200 using the ELDK 4.2. It can't
find the type uint64_t:
Index: include/asm-powerpc/fptest.h
===
--- include/asm-powerpc/fptest.h
101 - 200 of 251 matches
Mail list logo
