Hi,
there is a bug in kernel 2.6.37 (fixed in 2.6.37.1, see commit
1cdc65e1400d863f28af868ee1e645485b04f5ed) which blocks RT threads during
creation. They stick to a certain CPU core for a certain amount of time
(sometimes minutes ...) before they are migrated to the proper core and run
as
Pavel Cheblakov wrote:
This is a general driver for cards based on PLX90xx PCI-bridges.
It supports following cards:
- Adlink PCI-7841/cPCI-7841 card (http://www.adlinktech.com/)
- Adlink PCI-7841/cPCI-7841 SE card
- esd CAN-PCI/CPCI/PCI104/200 (http://www.esd.eu/)
- esd CAN-PCI/PMC/266
Hi Wolfgang,
Wolfgang Grandegger wrote:
On 05/18/2010 01:42 PM, Sebastian Smolorz wrote:
Pavel Cheblakov wrote:
This is a general driver for cards based on PLX90xx PCI-bridges.
It supports following cards:
- Adlink PCI-7841/cPCI-7841 card (http://www.adlinktech.com/)
- Adlink PCI
Wolfgang Grandegger wrote:
On 05/18/2010 02:29 PM, Sebastian Smolorz wrote:
Hi Wolfgang,
Wolfgang Grandegger wrote:
On 05/18/2010 01:42 PM, Sebastian Smolorz wrote:
Pavel Cheblakov wrote:
This is a general driver for cards based on PLX90xx PCI-bridges.
It supports following cards
can: Free I/O region when unloading the xeno_can_isa.ko driver
Signed-off-by: Sebastian Smolorz smol...@rts.uni-hannover.de
diff --git a/ksrc/drivers/can/sja1000/rtcan_isa.c b/ksrc/drivers/can/sja1000/rtcan_isa.c
index 6debb16..ec32393 100644
--- a/ksrc/drivers/can/sja1000/rtcan_isa.c
+++ b/ksrc
by Matthias
Fuchs.
Signed-off-by: Sebastian Smolorz smol...@rts.uni-hannover.de
--
ksrc/drivers/can/sja1000/Kconfig | 11 +
ksrc/drivers/can/sja1000/Makefile|7 +
ksrc/drivers/can/sja1000/rtcan_esd_pci.c | 354 ++
3 files changed, 372 insertions
Hi Philippe,
with latest head it is not possible to build the POSIX skin as module. It
gives:
ERROR: xnarch_divrem_billion [kernel/xenomai/skins/posix/xeno_posix.ko]
undefined!
Obviously an
EXPORT_SYMBOL(xnarch_divrem_billion);
is missing.
--
Sebastian
Gilles Chanteperdrix wrote:
Sebastian Smolorz wrote:
Hi Philippe,
with latest head it is not possible to build the POSIX skin as module.
It gives:
ERROR: xnarch_divrem_billion
[kernel/xenomai/skins/posix/xeno_posix.ko] undefined!
Obviously an
EXPORT_SYMBOL
Wolfgang Grandegger wrote:
Hi Jan and Sebastian,
attached is the patch fixing the filter problem. I'm going to apply it
to the trunk as well if there are no complaints.
No complaints from my side.
Wolfgang.
Index: ChangeLog
Hi Wolfgang,
we currently face an issue regarding the filtering of CAN messages since
Xenomai 2.4. It was introduced in rev. 2202 (I know it is long ago but
the problem popped up last week). The line in question is
Gilles Chanteperdrix wrote:
On Mon, May 26, 2008 at 5:44 PM, Sebastian Smolorz
[EMAIL PROTECTED] wrote:
Hello Gilles,
with your last commit:
Fix compilation with ucLibc
I cannot build xenomai userland any more (at least when taking glibc).
cyclictest fails with the following error
25, E02. If you are interested in Xenomai and autonomous service
robots don't hesitate to drop by our booth.
--
Dipl.-Ing. Sebastian Smolorz
Institute for Systems Engineering, Real-Time Systems Group (RTS)
Appelstraße 9A, D-30167 Hannover
phone +49 511 762-3974 / fax +49 511 762-4012
http
Jan Kiszka wrote:
Sebastian Smolorz wrote:
Jan Kiszka wrote:
This patch may do the trick: it uses the inverted tsc-to-ns function
instead of the frequency-based one. Be warned, it is totally untested
inside Xenomai, I just ran it in a user space test program. But it
may give an idea
Jan Kiszka wrote:
Sebastian Smolorz wrote:
Gilles Chanteperdrix wrote:
On Wed, Apr 2, 2008 at 5:58 PM, Sebastian Smolorz
[EMAIL PROTECTED] wrote:
Jan Kiszka wrote:
Sebastian Smolorz wrote:
Jan Kiszka wrote:
Cornelius Köpp wrote:
I talked with Sebastian Smolorz about this and he builds
space showed also negative values but with no additional drift
over time.
I talked with Sebastian Smolorz about this and he builds his own
independent kernel-config to check. He got the same drifting-effect
with Xenomai 2.4.2 and Xenomai 2.4.3 running latency over several
hours. His kernel
Gilles Chanteperdrix wrote:
On Wed, Apr 2, 2008 at 2:28 PM, Jan Kiszka [EMAIL PROTECTED] wrote:
Sebastian Smolorz wrote:
Jan Kiszka wrote:
2.3.x did not incorporate the new TSC-to-ns conversion. Maybe it is
not a PIC vs. APIC thing, but rather a rounding problem of larger TSC
Jan Kiszka wrote:
Sebastian Smolorz wrote:
Jan Kiszka wrote:
Cornelius Köpp wrote:
Hello,
I run the latency test from testsuite on several hard and software
configurations. Running on Xenomai 2.4.2, Linux 2.6.24 the results
shows a strange behavior: In Kernel mode (-t1) the latencys
Gilles Chanteperdrix wrote:
On Wed, Apr 2, 2008 at 5:58 PM, Sebastian Smolorz
[EMAIL PROTECTED] wrote:
Jan Kiszka wrote:
Sebastian Smolorz wrote:
Jan Kiszka wrote:
Cornelius Köpp wrote:
I talked with Sebastian Smolorz about this and he builds his own
independent kernel-config
Richard Cochran wrote:
-Original Message- From: Sebastian Smolorz
Sent: Wednesday, September 26, 2007 11:28 AM
We consider to set up a git repository so that you and all
interested people will be able to clone from it. If anyone feels
prepared to contribute code to this project
--
Dipl.-Ing. Sebastian Smolorz, emlix GmbH, http://www.emlix.com
Fon +49 551 30664-0, Fax -11, Bahnhofsallee 1b, 37081 Göttingen, Germany
Geschäftsführung: Dr. Uwe Kracke, Dr. Cord Seele, Ust-IdNr.: DE 205 198 055
Sitz der Gesellschaft: Göttingen, Amtsgericht Göttingen HR B 3160
emlix - your
Pop
*
+ * Copyright (C) 2007 Sebastian Smolorz [EMAIL PROTECTED]
+ * Support for TSC emulation in user space for decrementing counters
+ *
* Xenomai is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published
* by the Free
Gilles Chanteperdrix wrote:
On 7/20/07, Sebastian Smolorz [EMAIL PROTECTED] wrote:
Hi,
here comes my patch for user space tsc emulation for decrementing
counters. I had to extend the __xn_tscinfo structure because the counter
value from the last tsc update is needed to calculate the new
Hi,
Stéphane ANCELOT wrote:
Hi,
I will go there on Friday, it would be glad if we could meet us.
Talking about our works with xenomai and our work about possible
integration of xenomai with realtime industrial ethernet
(ethercat/powerlink/profinet...)
I would be interested in meeting
Jan Kiszka wrote:
Sebastian Smolorz wrote:
Jan Kiszka wrote:
So, unless we find some reason why we _must_ modify user's iovec, either
for send or receive, I would say: kill the user copy-back and work in
both case (kernel / user space caller) on the local copy of iovec (if we
still
Hello Philippe,
on page 21 of Native-API-Tour-rev-C.pdf one gets the impression that
rt_intr_wait() returns 0 on success. However, it returns a positive value in
this case (as the API description states it right).
--
Sebastian
___
Xenomai-core
Hi,
is there a problem with the Xenomai website or did I try to access it in the
middle of an update cycle of mediawiki?
--
Sebastian
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
Jan Kiszka wrote:
Sebastian Smolorz wrote:
Jan Kiszka wrote:
Sebastian Smolorz wrote:
Jan Kiszka wrote:
Wolfgang Grandegger wrote:
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
Jan Kiszka wrote:
Sebastian Smolorz wrote:
Jan Kiszka wrote:
Wolfgang Grandegger wrote:
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
Jan Kiszka wrote:
I don't think that the sem state
should be used for encoding the CAN device state towards potential senders.
Why not?
--
Sebastian
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
Gilles Chanteperdrix wrote:
Detlef Vollmann wrote:
Hello,
the x86 branch supports kernel 2.6.19, but the ARM branch only supports
2.6.15. Is there a specific reason for this?
Does anybody have a feeling what would be needed to be changed
for 2.6.19 support?
I guess the reason is
Philippe Gerum wrote:
On Fri, 2006-12-22 at 11:58 +0100, Sebastian Smolorz wrote:
Hi Philippe and Gilles,
the updated I-pipe patch for ARM which was checked-in yesterday is not
complete. Some files are missing e.g. entry-header.S or
mach-integrator/core.c. The attached patch should
-ipipe.orig/arch/arm/kernel/ipipe-mcount.S 1970-01-01 01:00:00.0 +0100
+++ linux-2.6.15-ipipe/arch/arm/kernel/ipipe-mcount.S 2006-12-04 09:46:30.0 +0100
@@ -0,0 +1,40 @@
+/*
+ * linux/arch/arm/kernel/ipipe-mcount.S
+ *
+ * Copyright (C) 2006 Sebastian Smolorz [EMAIL PROTECTED], emlix
Philippe Gerum wrote:
On Mon, 2006-12-18 at 17:04 +0100, Sebastian Smolorz wrote:
Jan Kiszka wrote:
If you have anything more pending, please post soon, Gilles is
collecting the ARM stuff for Xenomai 2.3.
Attached are all patches that I posted in the last two months but didn't
get
Gilles Chanteperdrix wrote:
Sebastian Smolorz wrote:
Gilles Chanteperdrix wrote:
Sebastian Smolorz wrote:
Hi,
here's a proposal for a minor change in the I-pipe implementation for
ARM. Since it is required for my S3C24xx patch not to call
__ipipe_mach_set_dec directly when the timer
Am Freitag, 10. November 2006 11:14 schrieb Gilles Chanteperdrix:
Sebastian Smolorz wrote:
Hi all,
now that the teething problems of my I-pipe port to the S3C24xx are cured
(hopefully ...) I'm going to iterate it to v4. We've established a
project homepage for that port
http
Hi,
here comes a fix for I-pipe for ARM. Without it the kernel refuses to compile
when configured with CONFIG_PREEMPT.
Sebastian
--- linux-2.6.15-ipipe.orig/include/asm-arm/ipipe.h 2006-11-08 16:44:02.0 +0100
+++ linux-2.6.15-ipipe.work/include/asm-arm/ipipe.h 2006-11-10
Hi all,
now that the teething problems of my I-pipe port to the S3C24xx are cured
(hopefully ...) I'm going to iterate it to v4. We've established a project
homepage for that port
http://opensource.emlix.com/ipipe-s3c24xx/
in order to concentrate the source code and information at one point.
Gilles Chanteperdrix wrote:
Gilles Chanteperdrix wrote:
Sebastian Smolorz wrote:
Hi,
here comes version 2 of the I-pipe patch for the S3C24xx ARM. The
reported problem is solved, the timer works as expected as far as I
can see. Linux is still there after insmod'ding the native skin
Hi,
on my quest to find the bug in the I-pipe patch for the S3C24xx (got the root
of the problem now, information will soon follow) I detected a missing
semicolon in xenomai/include/asm-arm/calibration.h. See attachment.
Sebastian
Index: xenomai-svn/include/asm-arm/calibration.h
Hi all,
I'm currently working on porting I-pipe to the ARM S3C24xx. The patch is
attached, it must be applied after the shipped
adeos-ipipe-2.6.15-arm-1.5-01.patch. Unfortunately, there is still a severe
bug somewhere. I built Xenomai as modules. When I try to modprobe
xeno_native, the
-18 15:17:25.0 +0200
@@ -3,6 +3,8 @@
* Copyright (c) 2003,2004 Simtec Electronics
* Ben Dooks [EMAIL PROTECTED]
*
+ * Copyright (C) 2006 Sebastian Smolorz [EMAIL PROTECTED], emlix GmbH
+ *
* This program is free software; you can redistribute it and/or modify
* it under the terms
Jan Kiszka wrote:
Sebastian Smolorz wrote:
The possibility of redefinition was not the main goal here. As you
mentioned it would be problematic. No, I introduced nanosecs_abs_t and
nanosecs_rel_t because they are more intuitive and more speaking to the
programmer. The meaning
Jan Kiszka wrote:
Sebastian Smolorz wrote:
Jan Kiszka wrote:
Sebastian Smolorz wrote:
The possibility of redefinition was not the main goal here. As you
mentioned it would be problematic. No, I introduced nanosecs_abs_t and
nanosecs_rel_t because they are more intuitive and more
On Tue, 16 May 2006 [EMAIL PROTECTED] wrote:
I don't know your hardware, but i think it's a not a hardware problem.
Your desctription sounds more than a compiler optimization problem.
Ok, this is your READ_REG definition,
/** Read access to a register of the SJA1000 CAN controller */
Hello Philippe,
I've got the results from Roland now.
Interestingly, the driver does not show the above behaviour with all
interrupt numbers. E.g. with interrupt number 12 the driver gets no
interrupt at all.
Now IRQ 12 works ...
Some technical details:
- Linux Kernel 2.6.16
-
Hello all,
the following is a really nasty problem I am trying to solve for months now. I
really hope that someone on the list knows the solution.
As you may remember some months ago I announced a RTDM CAN driver for SJA1000
based cards (see
Hello Ulrich!
On Tue, 16 May 2006 [EMAIL PROTECTED] wrote:
I don't know your hardware, but i think it's a not a hardware problem.
Your desctription sounds more than a compiler optimization problem.
Ok, this is your READ_REG definition,
/** Read access to a register of the SJA1000 CAN
Hello Philippe,
on Tue, 16 May 2006, Philippe Gerum wrote:
It would be interesting to know how Adeos is asked to deal with such
interrupt upon receipt, e.g. does it relay it to Linux?
In the init_module routine the driver calls rtdm_irq_request() with flags
RTDM_IRQTYPE_SHARED |
Hi,
I failed to find the original message from Sebastian that led to the
following change:
-
2005-11-09 Philippe Gerum [EMAIL PROTECTED]
* nucleus/pipe.c (xnpipe_disconnect): Flush the output queue
upon closure. Issue spotted by Sebastian Smolorz
Hello list,
as a result of a student research project of mine (kind of bachelor
thesis), here is a CAN device profile for RTDM including a driver for the
SJA1000-based eNET PHYTEC card. See RT-Add-On-Repository at the University
of Hannover:
Hi,
I just stumbled across an ambiguity in the documentation for
rt_task_delete() in the native skin. One could think that this function
can only be called from userspace if it is a RT task because of
This service can be called from:
...
User-space task (switches to primary mode)
But this is
Hi,
I've spotted a -- in my view -- strange behaviour of RT pipes in the
native skin. The scenario is as follows:
A RT task creates a RT pipe and writes some bytes into it. A NRT
counterpart reads from this pipe, but not all bytes. Afterwards, the RT
task deletes the pipe.
Now the program is
Hi,
I just stumbled across an ambiguity in the documentation for
rt_task_delete() in the native skin. One could think that this function
can only be called from userspace if it is a RT task because of
This service can be called from:
...
User-space task (switches to primary mode)
But this is
Hi,
I've spotted a -- in my view -- strange behaviour of RT pipes in the
native skin. The scenario is as follows:
A RT task creates a RT pipe and writes some bytes into it. A NRT
counterpart reads from this pipe, but not all bytes. Afterwards, the RT
task deletes the pipe.
Now the program is
On Wed, 9 Nov 2005, Philippe Gerum wrote:
Philippe Gerum wrote:
Sebastian Smolorz wrote:
Hi,
I've spotted a -- in my view -- strange behaviour of RT pipes in the
native skin. The scenario is as follows:
A RT task creates a RT pipe and writes some bytes into it. A NRT
On Tue, 8 Nov 2005, Philippe Gerum wrote:
Jan Kiszka wrote:
Hi Philippe,
I think this one is for you: ;)
Sebastian got almost mad with his CAN driver while tracing a strange
scheduling behaviour during shadow thread deletion for several days(!) -
and I was right on the way to
Hi,
today I discovered a bug after having tried to load the Xenomai RTDM skin.
I've attached a patch which should correct the problem.
Sebastian--- xenomai/skins/rtdm/proc.c 2005-10-12 16:58:48.0 +0200
+++ proc.c 2005-10-12 17:00:59.0 +0200
@@ -285,7 +285,7 @@ int __init
On Wed, 12 Oct 2005, Philippe Gerum wrote:
Sebastian Smolorz wrote:
Hi,
today I discovered a bug after having tried to load the Xenomai RTDM skin.
I've attached a patch which should correct the problem.
... and if we want to have a clean removal of the proc entry at module
unload
58 matches
Mail list logo
