[Xenomai-core] Ambiguity in description about rt_task_delete()
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 only true if the argument is NULL. Otherwise it is possible from NRT context (if I understood the code in task.c correctly). Maybe a clearer description is necessary here. Sebastian ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] RT pipes
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 re-run: RT task creates the pipe, writes some bytes, and the NRT part reads some bytes, but begins with the old ones which weren't read during the first run of the program. Now my question: Is this behaviour intentional? If it is then I see the following problem: A task which calls rt_pipe_create() cannot be sure that the pipe is empty. So it should be able to clear the pipe before use but I found no function that allows a RT task to clear the pipe. Sebastian ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [BUG] scheduling order of dying shadow threads
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 follow him yesterday evening. Attached is a simplified demonstration of the effect, consisting of a RTDM driver and both a kernel and user space application to trigger it. I've spotted the issue in nucleus/shadow.c. Basically, the root thread priority boost was leaking to a non-shadow thread due to a missing priority reset in the lostage APC handler, whilst a shadow was in the process of relaxing. Really funky bug, thanks! :o Fixed in the repo hopefully for good. The scheduling sequence is now correct with your demo app on my box. Thank you, problem has disappeared here, too! :-) Sebastian
[Xenomai-core] Ambiguity in description about rt_task_delete()
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 only true if the argument is NULL. Otherwise it is possible from NRT context (if I understood the code in task.c correctly). Maybe a clearer description is necessary here. Sebastian
[Xenomai-core] RT pipes
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 re-run: RT task creates the pipe, writes some bytes, and the NRT part reads some bytes, but begins with the old ones which weren't read during the first run of the program. Now my question: Is this behaviour intentional? If it is then I see the following problem: A task which calls rt_pipe_create() cannot be sure that the pipe is empty. So it should be able to clear the pipe before use but I found no function that allows a RT task to clear the pipe. Sebastian
Re: [Xenomai-core] RT pipes
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 counterpart reads from this pipe, but not all bytes. Afterwards, the RT task deletes the pipe. Now the program is re-run: RT task creates the pipe, writes some bytes, and the NRT part reads some bytes, but begins with the old ones which weren't read during the first run of the program. Now my question: Is this behaviour intentional? Nope. If it is then I see the following problem: A task which calls rt_pipe_create() cannot be sure that the pipe is empty. So it should be able to clear the pipe before use but I found no function that allows a RT task to clear the pipe. ioctl(fd,XNPIPEIOC_FLUSH,0) would do, but still, we should clear the output queue when closing the kernel side. In the same vein, closing the user-space side does not clear the input queue that feeds the kernel side. Thanks for spotting this. Ok, fixed. Thanks, now it works! :-) Sebastian
[Xenomai-core] Announce: RTDM CAN Device Profile and Driver
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: http://www.rts.uni-hannover.de/mitarbeiter/kiszka/rtaddon/ Have fun! ;-) Sebastian
Re: [Xenomai-core] [pipe.c] hairy synchronization - flush the output queue upon closure
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. (xnpipe_release): Flush the input queue upon closure. - https://mail.gna.org/public/xenomai-core/2005-11/msg00058.html The problem was here that after a RT task and a Linux user space program had closed both ends of the pipe the contents remained in the pipe. So when the pipe was opened again the old content was read. Sebastian
[Xenomai-core] Wrong RTDM proc entry prevents xeno_rtdm.ko from being loaded
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 rtdm_proc_init(void) /* Initialise /proc entries */ -rtdm_proc_root = create_proc_entry(Xenomai/rtdm, S_IFDIR, NULL); +rtdm_proc_root = create_proc_entry(xenomai/rtdm, S_IFDIR, NULL); if (!rtdm_proc_root) return -EAGAIN;
Re: [Xenomai-core] Wrong RTDM proc entry prevents xeno_rtdm.ko from being loaded
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, this next patch is very useful! ;-) Sebastian--- xenomai/skins/rtdm/proc.c 2005-10-12 17:35:42.0 +0200 +++ proc.c 2005-10-12 17:31:09.0 +0200 @@ -322,7 +322,7 @@ void rtdm_proc_cleanup(void) remove_proc_entry(open_fildes, rtdm_proc_root); remove_proc_entry(protocol_devices, rtdm_proc_root); remove_proc_entry(named_devices, rtdm_proc_root); -remove_proc_entry(Xenomai/rtdm, NULL); +remove_proc_entry(xenomai/rtdm, NULL); } #endif /* CONFIG_PROC_FS */
[Xenomai-core] Strange behaviour of RTDM CAN driver
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 https://mail.gna.org/public/xenomai-core/2005-11/msg00108.html). The driver works well with the cards at our institute. Some time ago I was asked to extend the driver so that it would work also with a card from another vendor (Advantech PCM3680). By now, the driver does its job as expected, with one exception: It gets stuck in the interrupt handler. The problem is that the interrupt register of the SJA1000 chip does not get cleared after a read command like it should. So the driver never knows that there is no interrupt anymore and therefore never leaves the interrupt handler. After I installed a break after 20 loops inside the handler and an additional read of the interrupt register in the following syscall routine issued by the test program, I noticed that the register is cleared! So I strongly think that the reason for clearing this register lies in actions taken after the driver left the interrupt handler. But I am not very sure about this. Maybe there is another reason I do not see (or in the end the hardware is faulty ...). Did any of you experienced a similar problem in the past? Any hint would be appreciated! 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. Some technical details: - Linux Kernel 2.6.16 - adeos-ipipe-2.6.16-i386-1.3-01.patch - Xenomai 2.1.50 Sebastian ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Strange behaviour of RTDM CAN driver
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 controller */ #define READ_REG(base, register) \ readb((void *)(base+register)) please try this one: /** Read access to a register of the SJA1000 CAN controller */ #define READ_REG(base, register) \ readb((volatile void *)(base+register)) Thank you for your suggestion. In my initial mail I forgot to mention that the problem of an over-optimising compiler came into my mind, too. I tried several workarounds to exclude every effect of the compiler (compiling with -O0 instead of -O2, replacing readb directly with the definition used in the Linux Kernel sources, and lastly disassembling the driver to assure myself that there are really memory access commands to the IO memory). Also, when I compile the driver with the change you suggested, the kernel module is not different to that compiled without that change. But I am desperate enough to try this one out. (That means mailing your suggestion to the person who owns the Advantech CAN card; developing a driver without the possibility to test it is really difficult.) Regards, Sebastian ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Strange behaviour of RTDM CAN driver
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 | RTDM_IRQTYPE_EDGE. The interrupt handler returns RTDM_IRQ_NONE if the interrupt register of the CAN chip reports zero (which is not the case here) or RTDM_IRQ_HANDLED if it is not zero. What do the following say? And also, which is the number of your interrupt in the dumps below? $ cat /proc/ipipe/Xenomai $ cat /proc/ipipe/Linux $ cat /proc/xenomai/irq I've sent a mail to Roland Riepl who has got that strange piece of CAN hardware and also suggested him to directly post his answer to this ML. Sebastian ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Strange behaviour of RTDM CAN driver
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 */ #define READ_REG(base, register) \ readb((void *)(base+register)) please try this one: /** Read access to a register of the SJA1000 CAN controller */ #define READ_REG(base, register) \ readb((volatile void *)(base+register)) But I am desperate enough to try this one out. (That means mailing your suggestion to the person who owns the Advantech CAN card; developing a driver without the possibility to test it is really difficult.) OK, i got the results. As I expected the patch above does not make any difference. Sebastian ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Strange behaviour of RTDM CAN driver
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 - adeos-ipipe-2.6.16-i386-1.3-01.patch - Xenomai 2.1.50 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? What do the following say? And also, which is the number of your interrupt in the dumps below? $ cat /proc/ipipe/Xenomai $ cat /proc/ipipe/Linux $ cat /proc/xenomai/irq First, for IRQ 11: # cat /proc/ipipe/Xenomai Invariant head, Id=0x58454e4f irq0-10: passed irq11: wired irq12-215: passed irq216: wired irq217-255: passed irq256-257: passed, virtual irq258: wired, virtual # cat /proc/ipipe/Linux Priority=100, Id=0x irq0-238: accepted irq256-257: grabbed, virtual irq258: passed, virtual # cat /proc/xenomai/irq IRQ CPU0 11: 10 216: 29 258: 20 And now, the card is assigned to IRQ12: # cat /proc/ipipe/Xenomai Invariant head, Id=0x58454e4f irq0-11: passed irq12: wired irq13-215: passed irq216: wired irq217-255: passed irq256-257: passed, virtual irq258: wired, virtual # cat /proc/ipipe/Linux Priority=100, Id=0x irq0-238: accepted irq256-257: grabbed, virtual irq258: passed, virtual # cat /proc/xenomai/irq IRQ CPU0 12: 8 216: 33 258: 20 It should be noted that only 3 interrupts are registered by my driver. Another phenomenon reported by Roland: His test program sends three messages via rt_dev_send(). After a fresh reboot, when the program sends it directly in a row, only the first one makes it. When he adds a printf() statement after each rt_dev_send() to get the return value, the program works nicely and sends 3 messages. And when he removes the printf() statements afterwards without booting freshly, the first behaviour cannot be reproduced. Strange! I guess this behaviour has to do with the fact that no interrupts appear the first time. But why does they appear during the second run? Could it be related to the switch between primary/secondary domain and back? And has it to do with the problem that the interrupt register of the SJA1000 is not cleared? Maybe someone can bring some light to this dark place ... Sebastian ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] Re: Time representation in RTDM profiles
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 of a variable of such a type is clear at first sight. Yeah, sounds reasonable to me. Then let's move these typedefs to rtdm.h and document them as self-explanatory defines of the underlying standard types, freezing their width and signedness at the same time. Agreed. Actually, this would be useful for the driver API of RTDM as well. That's right. No objections from my side. Sebastian ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] Re: Time representation in RTDM profiles
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 speaking to
the programmer. The meaning of a variable of such a type is clear at
first sight.
Yeah, sounds reasonable to me. Then let's move these typedefs to rtdm.h
and document them as self-explanatory defines of the underlying standard
types, freezing their width and signedness at the same time.
Agreed.
Actually, this would be useful for the driver API of RTDM as well.
That's right. No objections from my side.
Done.
Though I checked things more then twice, some regression may be hidden,
specifically as I changed the signedness of timeout parameters of a few
RTDM driver API functions. All documented under
ksrc/skins/rtdm/API.CHANGES, and everyone is warned now.
Here comes a follow-up patch. Compile-tested successfully.
Sebastian
Index: include/rtdm/rtcan.h
===
--- include/rtdm/rtcan.h (Revision 1450)
+++ include/rtdm/rtcan.h (Arbeitskopie)
@@ -507,16 +507,6 @@
/** @} */
-/*!
- * @anchor RTCAN_TIMEOUTS @name Timeouts
- * Special reception and transmission timeouts
- * @{ */
-#define RTCAN_TIMEOUT_INFINITE0 /** wait for ever */
-#define RTCAN_TIMEOUT_NONE(-1) /** equivalent to non-blocking */
-/** @} */
-
-
-
#define RTIOC_TYPE_CAN RTDM_CLASS_CAN
@@ -946,7 +936,7 @@
* @param [in] arg Pointer to @ref nanosecs_rel_t variable. The value is
*interpreted as relative timeout in nanoseconds in case
*of a positive value.
- *See @ref RTCAN_TIMEOUTS Timeouts for special timeouts.
+ *See @ref RTDM_TIMEOUT_xxx Timeouts for special timeouts.
*
* @return 0 on success, otherwise:
* - -EFAULT: It was not possible to access user space memory area at the
@@ -976,7 +966,7 @@
* @param [in] arg Pointer to @ref nanosecs_rel_t variable. The value is
*interpreted as relative timeout in nanoseconds in case
*of a positive value.
- *See @ref RTCAN_TIMEOUTS Timeouts for special timeouts.
+ *See @ref RTDM_TIMEOUT_xxx Timeouts for special timeouts.
*
* @return 0 on success, otherwise:
* - -EFAULT: It was not possible to access user space memory area at the
Index: ChangeLog
===
--- ChangeLog (Revision 1450)
+++ ChangeLog (Arbeitskopie)
@@ -1,3 +1,8 @@
+2006-08-16 Sebastian Smolorz [EMAIL PROTECTED]
+
+ * include/rtdm/rtcan.h, ksrc/drivers/can/rtcan_{module,socket,raw}.c:
+ Get rid of RTCAN_TIMEOUT_* defines and replace them with RTDM_TIMEOUT_*
+
2006-08-16 Jan Kiszka [EMAIL PROTECTED]
* include/rtdm/*.h, ksrc/skins/rtdm/drvlib.c: Refactor RTDM types
Index: ksrc/drivers/can/rtcan_module.c
===
--- ksrc/drivers/can/rtcan_module.c (Revision 1450)
+++ ksrc/drivers/can/rtcan_module.c (Arbeitskopie)
@@ -112,7 +112,7 @@
static void rtcan_get_timeout_name(nanosecs_rel_t timeout,
char* name, int max_len)
{
-if (timeout == RTCAN_TIMEOUT_INFINITE)
+if (timeout == RTDM_TIMEOUT_INFINITE)
strncpy(name, infinite, max_len);
else
sprintf(name, %lld, timeout);
Index: ksrc/drivers/can/rtcan_socket.c
===
--- ksrc/drivers/can/rtcan_socket.c (Revision 1450)
+++ ksrc/drivers/can/rtcan_socket.c (Arbeitskopie)
@@ -49,8 +49,8 @@
sock-err_mask = 0;
sock-rx_buf_full = 0;
-sock-tx_timeout = RTCAN_TIMEOUT_INFINITE;
-sock-rx_timeout = RTCAN_TIMEOUT_INFINITE;
+sock-tx_timeout = RTDM_TIMEOUT_INFINITE;
+sock-rx_timeout = RTDM_TIMEOUT_INFINITE;
INIT_LIST_HEAD(sock-tx_wait_head);
list_add(sock-socket_list, rtcan_socket_list);
Index: ksrc/drivers/can/rtcan_raw.c
===
--- ksrc/drivers/can/rtcan_raw.c (Revision 1450)
+++ ksrc/drivers/can/rtcan_raw.c (Arbeitskopie)
@@ -556,7 +556,7 @@
/* Set RX timeout */
rtdm_lock_get_irqsave(rtcan_socket_lock, lock_ctx);
-timeout = (flags MSG_DONTWAIT) ? RTCAN_TIMEOUT_NONE : sock-rx_timeout;
+timeout = (flags MSG_DONTWAIT) ? RTDM_TIMEOUT_NONE : sock-rx_timeout;
rtdm_lock_put_irqrestore(rtcan_socket_lock, lock_ctx);
@@ -839,7 +839,7 @@
rtdm_lock_get_irqsave(rtcan_socket_lock, lock_ctx);
-timeout = (flags MSG_DONTWAIT) ? RTCAN_TIMEOUT_NONE : sock-tx_timeout;
+timeout = (flags MSG_DONTWAIT) ? RTDM_TIMEOUT_NONE : sock-tx_timeout;
rtdm_lock_put_irqrestore(rtcan_socket_lock, lock_ctx);
___
Xenomai-core mailing list
Xenomai-core@gna.org
https
[Xenomai-core] I-pipe patch for ARM S3C24xx
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 system hangs. No reaction at all, inlcuding serial console
and network access. I guess that interrupts are not handled any more. From
what I see if I spread some debug printk() into my code, the timer starts
working under the control of the Xenomai domain and one or two calls to the
Linux timer interrupt handler are made. But after that nothing happens any
more.
As I try to find the bug for some days now but wasn't successful maybe the
experts have any hints where to continue searching. Or perhaps there is
someone who can test it and confirm or disprove my observation? It would be
great to support one more ARM model.
Sebastian
diff -upr linux-2.6.15-ipipe.orig/arch/arm/mach-s3c2410/irq.c linux-2.6.15-ipipe/arch/arm/mach-s3c2410/irq.c
--- linux-2.6.15-ipipe.orig/arch/arm/mach-s3c2410/irq.c 2006-10-10 16:36:50.0 +0200
+++ linux-2.6.15-ipipe/arch/arm/mach-s3c2410/irq.c 2006-10-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 of the GNU General Public License as published by
* the Free Software Foundation; either version 2 of the License, or
@@ -48,7 +50,10 @@
*
* 25-Jul-2005 Ben Dooks
* Split the S3C2440 IRQ code to seperate file
-*/
+ *
+ * 11-Oct-2006 Sebastian Smolorz
+ * Added Adeos/Ipipe support
+ */
#include linux/init.h
#include linux/module.h
@@ -56,6 +61,7 @@
#include linux/ioport.h
#include linux/ptrace.h
#include linux/sysdev.h
+#include linux/ipipe.h
#include asm/hardware.h
#include asm/irq.h
@@ -70,6 +76,14 @@
#include pm.h
#include irq.h
+#ifdef CONFIG_IPIPE
+#ifdef CONFIG_CPU_S3C2440
+extern void __ipipe_s3c_irq_demux_wdtac97(unsigned int irq,
+ struct pt_regs *regs);
+extern void __ipipe_s3c_irq_demux_cam(unsigned int irq, struct pt_regs *regs);
+#endif /* CONFIG_CPU_S3C2440 */
+#endif /* CONFIG_IPIPE */
+
/* wakeup irq control */
#ifdef CONFIG_PM
@@ -573,6 +587,71 @@ s3c_irq_demux_uart2(unsigned int irq,
}
+#ifdef CONFIG_IPIPE
+static void __ipipe_s3c_irq_demux_uart(unsigned int start,
+ unsigned int subsrc,
+ struct pt_regs *regs)
+{
+ unsigned int offset = start - IRQ_S3CUART_RX0;
+
+ subsrc = offset;
+ subsrc = 7;
+
+ if (subsrc != 0) {
+ if (subsrc 1)
+ __ipipe_handle_irq(start, regs);
+ if (subsrc 2)
+ __ipipe_handle_irq(start+1, regs);
+ if (subsrc 4)
+ __ipipe_handle_irq(start+2, regs);
+ }
+}
+
+static void __ipipe_s3c_irq_demux_adc(unsigned int subsrc,
+ struct pt_regs *regs)
+{
+ subsrc = 9;
+ subsrc = 3;
+
+ if (subsrc != 0) {
+ if (subsrc 1)
+ __ipipe_handle_irq(IRQ_TC, regs);
+ if (subsrc 2)
+ __ipipe_handle_irq(IRQ_ADC, regs);
+ }
+}
+
+void __ipipe_mach_demux_irq(unsigned irq, struct pt_regs *regs)
+{
+ unsigned int subsrc, submsk;
+ struct irqdesc *desc_unused = irq_desc + irq;
+
+ /* read the current pending interrupts, and the mask
+ * for what it is available */
+ subsrc = __raw_readl(S3C2410_SUBSRCPND);
+ submsk = __raw_readl(S3C2410_INTSUBMSK);
+
+ subsrc = ~submsk;
+
+ if (irq == IRQ_UART0)
+ __ipipe_s3c_irq_demux_uart(IRQ_S3CUART_RX0, subsrc, regs);
+ else if (irq == IRQ_UART1)
+ __ipipe_s3c_irq_demux_uart(IRQ_S3CUART_RX1, subsrc, regs);
+ else if (irq == IRQ_UART2)
+ __ipipe_s3c_irq_demux_uart(IRQ_S3CUART_RX2, subsrc, regs);
+ else if (irq == IRQ_ADCPARENT)
+ __ipipe_s3c_irq_demux_adc(subsrc, regs);
+#ifdef CONFIG_CPU_S3C2440
+ else if (irq == IRQ_WDT)
+ __ipipe_s3c_irq_demux_wdtac97(subsrc, regs);
+ else if (irq == IRQ_CAM)
+ __ipipe_s3c_irq_demux_cam(subsrc, regs);
+#endif /* CONFIG_CPU_S3C2440 */
+
+ desc_unused-chip-unmask(irq);
+}
+#endif /* CONFIG_IPIPE */
+
/* s3c24xx_init_irq
*
* Initialise S3C2410 IRQ system
diff -upr linux-2.6.15-ipipe.orig/arch/arm/mach-s3c2410/s3c2440-irq.c linux-2.6.15-ipipe/arch/arm/mach-s3c2410/s3c2440-irq.c
--- linux-2.6.15-ipipe.orig/arch/arm/mach-s3c2410/s3c2440-irq.c 2006-10-10 16:36:50.0 +0200
+++ linux-2.6.15-ipipe/arch/arm/mach-s3c2410/s3c2440-irq.c 2006-10-12 09:41:30.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 of the GNU General Public License as published by
* the Free Software Foundation; either version 2 of the License, or
@@ -19,8 +21,10 @@
*
* Changelog:
* 25-Jul-2005 BJD Split from irq.c
+ * 11-Oct-2006 Sebastian Smolorz
Re: [Xenomai-core] I-pipe patch for ARM S3C24xx
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 system hangs. No reaction at all, inlcuding serial console and network access. I guess that interrupts are not handled any more. From what I see if I spread some debug printk() into my code, the timer starts working under the control of the Xenomai domain and one or two calls to the Linux timer interrupt handler are made. But after that nothing happens any more. As I try to find the bug for some days now but wasn't successful maybe the experts have any hints where to continue searching. Or perhaps there is someone who can test it and confirm or disprove my observation? It would be great to support one more ARM model. Small update with new infos: After Xenomai has (re)started the system timer the Linux timer interrupt handler ist called only once, but xnintr_clock_handler() is called several thousand times. So it seems that the timer interrupt handler of Linux is not properly called or Xenomai is starving Linux. Sebastian ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] [PATCH] Missing ; in include/asm-arm/calibration.h
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
===
--- xenomai-svn/include/asm-arm/calibration.h (Revision 1749)
+++ xenomai-svn/include/asm-arm/calibration.h (Arbeitskopie)
@@ -28,7 +28,7 @@
static inline unsigned long xnarch_get_sched_latency (void)
{
#if CONFIG_XENO_OPT_TIMING_SCHEDLAT != 0
- return CONFIG_XENO_OPT_TIMING_SCHEDLAT
+return CONFIG_XENO_OPT_TIMING_SCHEDLAT;
#else
return 9500; /* XXX sane ? */
#endif
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] I-pipe patch for ARM S3C24xx
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. More test results will follow next week after I tortured the new patch with the whole testsuite arsenal. ;-) The patch has got two suboptimal characteristics due to the generic ARM I-pipe implementation which I did not want to change during the first steps: 1. Regarding the demux of chained IRQs (See [1]). As the S3C24xx has more than one chained IRQ there are two consecutive queries for them in __ipipe_mach_irq_mux_p() and __ipipe_mach_demux_irq(). This could be optimized. You should use switch/case instead of if else if else if, the generated code would be better optimized. You can make the test cheap test by using a mask. Yes, I will do it that way. Thanks! Sebastian ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] I-pipe patch for ARM S3C24xx (v4)
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. Probably tomorrow I will come up with a patch in order to address point 2 in my email from 27.10.2006 ([1]). After that I can go to v5 of my patch and beg for integration. :-) However, there is one disturbing issue. When I execute dd if=/dev/zero of=/dev/null and the latency test in userspace with a period not less than 150 us the worst case latency is about 220 us. But when I start latency with -p 100 I get a softlock like the one attached. I guess this is the same problem as Detlef Vollmann described in [2]. So I think it's time for a big fat ARM-specific warning in the troubleshooting file and perhaps a modification of the testsuite so that if being compiled for ARM the default sample periods are greater than the 100 us now. Sebastian [1] https://mail.gna.org/public/xenomai-core/2006-10/msg00079.html [2] https://mail.gna.org/public/xenomai-core/2006-09/msg00055.html # ./latency == Sampling period: 100 us == Test mode: periodic user-mode task == All results in microseconds warming up... BUG: soft lockup detected on CPU#0! Pid: 772, comm: dd CPU: 0 PC is at __ipipe_mach_get_tsc+0x44/0x54 LR is at 0x0 pc : [bf000bac]lr : []Not tainted sp : ip : fp : r10: r9 : r8 : r7 : r6 : r5 : r4 : r3 : r2 : r1 : r0 : Flags: nZcv IRQs on FIQs on Mode USER_32 Segment user Control: C000317F Table: 31FF DAC: 0015 [c0022a90] (show_regs+0x0/0x4c) from [c005b86c] (softlockup_tick+0x64/0x7c) r4 = C027F424 [c005b808] (softlockup_tick+0x0/0x7c) from [c0047820] (do_timer+0x3e8/0x468) r4 = C02A265C [c0047438] (do_timer+0x0/0x468) from [c0025ae0] (timer_tick+0xb4/0xe4) [c0025a2c] (timer_tick+0x0/0xe4) from [c002b8ec] (s3c2410_timer_interrupt+0x78/0xa4) r6 = C02A1610 r5 = r4 = C022A4C8 [c002b874] (s3c2410_timer_interrupt+0x0/0xa4) from [c0021bdc] (__do_irq+0x40/0x74) r8 = C027F424 r7 = 001E r6 = r5 = r4 = C022A4C8 [c0021b9c] (__do_irq+0x0/0x74) from [c0021d20] (do_edge_IRQ+0xa0/0xfc) r8 = C027F424 r7 = C027F424 r6 = C022A4C8 r5 = 001E r4 = C027E3A0 [c0021c80] (do_edge_IRQ+0x0/0xfc) from [c0021e74] (asm_do_IRQ+0x50/0x13c) r7 = C022DFC0 r6 = 001E r5 = r4 = C022DFC8 [c0021e24] (asm_do_IRQ+0x0/0x13c) from [c005bfd8] (__ipipe_sync_stage+0x1e0/0x268) [c005bdf8] (__ipipe_sync_stage+0x0/0x268) from [c005c440] (__ipipe_walk_pipeline+0x98/0xbc) [c005c3a8] (__ipipe_walk_pipeline+0x0/0xbc) from [c00270a4] (__ipipe_handle_irq+0x1a4/0x1b4) r7 = C02A3B00 r6 = 001E r5 = 001E r4 = [c0026f00] (__ipipe_handle_irq+0x0/0x1b4) from [c0027178] (__ipipe_grab_irq+0xc4/0x110) [c00270b4] (__ipipe_grab_irq+0x0/0x110) from [c0020c60] (__irq_usr+0x40/0x170) ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] I-pipe patch for ARM S3C24xx (v4)
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://opensource.emlix.com/ipipe-s3c24xx/ What happens with __ipipe_mach_irq_mux_p if irq is smaller than IRQ_CAM ? OK, this is not correct. I will fix it to #define __ipipe_irqbit(irq) (1 ((irq) - S3C2410_CPUIRQ_OFFSET)) as you suggested originally. Thanks, Sebastian ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] [PATCH] Missing include when compiling an ipiped Linux kernel with CONFIG_PREEMPT for ARM
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 12:12:44.0 +0100 @@ -34,6 +34,7 @@ #include asm/irq.h #include asm/bitops.h #include asm/mach/irq.h +#include asm/percpu.h #define IPIPE_ARCH_STRING 1.5-02 #define IPIPE_MAJOR_NUMBER 1 @@ -51,7 +52,7 @@ #endif /* CONFIG_SMP */ /* Note that we disable the interrupts around context_switch, - * or we'll get into severe problems when scheduling Xenomaï + * or we'll get into severe problems when scheduling Xenomai's * user space real time threads. * This can however cause high latencies, see for example: * http://www.ussg.iu.edu/hypermail/linux/kernel/0405.2/1388.html ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [PATCH] Don't call __ipipe_mach_set_dec in rthal_timer_release directly
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 is released by the Xenomai domain I suggest the following changes. The patch comprises the necessary modifications for PXA, SA1100 and Integrator, too. Comments or objections? Why can not you call __ipipe_mach_set_dec directly when the timer is released ? The timer used for generating interrupts operates in auto-reloading mode when it is under Linux control. But when Xenomai reloads the timer the mode of operation is one-shot (auto-reload feature in hardware is off). So I have to make a distinction between setting the dec value by Xenomai for programming the next period and setting the dec value to __ipipe_mach_ticks_per_jiffy when the timer control is given back to Linux. The reason for this is the fact that programming a timer on the S3C24xx can take some ticks which means that these ticks aren't count whereas time is going on in the real world. So it is more reasonable to let the timer reload itself when Xenomai hasn't started it. Setting __ipipe_mach_ticks_per_jiffy in the Linux interrupt handler would make every period last some ticks longer. You can avoid this problem by adding LATCH or __ipipe_mach_ticks_per_jiffy to the current value of the match register in the timer interrupt, as it is done for the SA and PXA architectures. Unfortunately, this solution is not applicable. The timers of PXA and SA are counting up whereas the S3C24xx timers are counting down to zero. There is no match register for the next interrupt. In contrast, the timer must be programmed with the new dec value directly, thus stopping it for the time of re-programming. -- Sebastian ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] Re: [Adeos-main] Latency trace on ARM
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
into Ipipe CVS or Xenomai svn. The first file pools all patches for Ipipe,
here comes an overview what it comprises:
- I-pipe for Samsung S3C24xx
- I-pipe tracer for ARM
- Introduce __ipipe_mach_release_timer()
- Fix ipipe_tsc2ns()
- Don't activate the tracer too early during the boot process
Please consider these patches for Xenomai 2.3. Thanks!
--
Sebastian
diff -upNr linux-2.6.15-ipipe.orig/arch/arm/boot/compressed/head.S linux-2.6.15-ipipe/arch/arm/boot/compressed/head.S
--- linux-2.6.15-ipipe.orig/arch/arm/boot/compressed/head.S 2006-01-03 04:21:10.0 +0100
+++ linux-2.6.15-ipipe/arch/arm/boot/compressed/head.S 2006-12-04 17:45:52.0 +0100
@@ -710,6 +710,16 @@ memdump: mov r12, r0
mov pc, r10
#endif
+#ifdef CONFIG_IPIPE_TRACE_MCOUNT
+.text
+.align 0
+.type mcount %function
+.global mcount
+mcount:
+ mov pc, lr @ just return
+#endif
+
+
reloc_end:
.align
diff -upNr linux-2.6.15-ipipe.orig/arch/arm/kernel/entry-common.S linux-2.6.15-ipipe/arch/arm/kernel/entry-common.S
--- linux-2.6.15-ipipe.orig/arch/arm/kernel/entry-common.S 2006-05-04 14:43:39.0 +0200
+++ linux-2.6.15-ipipe/arch/arm/kernel/entry-common.S 2006-12-04 09:48:15.0 +0100
@@ -294,3 +294,28 @@ sys_mmap2:
str r5, [sp, #4]
b do_mmap2
#endif
+
+#ifdef CONFIG_FRAME_POINTER
+
+ .text
+ .align 0
+ .type arm_return_addr %function
+ .global arm_return_addr
+
+arm_return_addr:
+ mov ip, r0
+ mov r0, fp
+3:
+ cmp r0, #0
+ beq 1f @ frame list hit end, bail
+ cmp ip, #0
+ beq 2f @ reached desired frame
+ ldr r0, [r0, #-12] @ else continue, get next fp
+ sub ip, ip, #1
+ b 3b
+2:
+ ldr r0, [r0, #-4] @ get target return address
+1:
+ mov pc, lr
+
+#endif
diff -upNr linux-2.6.15-ipipe.orig/arch/arm/kernel/ipipe-mcount.S linux-2.6.15-ipipe/arch/arm/kernel/ipipe-mcount.S
--- linux-2.6.15-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 GmbH
+ */
+
+#include linux/config.h
+
+#ifdef CONFIG_FRAME_POINTER
+
+ .text
+ .align 0
+ .type mcount %function
+ .global mcount
+
+mcount:
+
+ ldr ip, =ipipe_trace_enable @ leave early, if disabled
+ ldr ip, [ip]
+ cmp ip, #0
+ moveq pc,lr
+
+ mov ip, sp
+ stmdb sp!, {r0 - r3, fp, ip, lr, pc} @ create stack frame
+
+ mov r3, #0 @ no additional value (v)
+ ldr r2, [fp, #-4] @ get lr (the return address
+ @ of the caller of the
+ @ instrumented function)
+ mov r1, lr @ get lr - (the return address
+ @ of the instrumented function)
+ mov r0, #0 @ IPIPE_TRACE_FN
+
+ sub fp, ip, #4 @ point fp at this frame
+
+ bl __ipipe_trace
+
+ ldmdb fp, {r0 - r3, fp, sp, pc} @ pop entry frame and return
+
+#endif
diff -upNr linux-2.6.15-ipipe.orig/arch/arm/kernel/ipipe-root.c linux-2.6.15-ipipe/arch/arm/kernel/ipipe-root.c
--- linux-2.6.15-ipipe.orig/arch/arm/kernel/ipipe-root.c 2006-10-09 22:41:23.0 +0200
+++ linux-2.6.15-ipipe/arch/arm/kernel/ipipe-root.c 2006-12-13 17:20:00.0 +0100
@@ -306,11 +306,19 @@ asmlinkage int __ipipe_grab_irq(int irq,
}
}
+#ifdef CONFIG_IPIPE_TRACE_IRQSOFF
+ ipipe_trace_begin(regs-ARM_ORIG_r0);
+#endif
+
if (__ipipe_mach_irq_mux_p(irq))
__ipipe_mach_demux_irq(irq, regs);
else
__ipipe_handle_irq(irq, regs);
+#ifdef CONFIG_IPIPE_TRACE_IRQSOFF
+ ipipe_trace_end(regs-ARM_ORIG_r0);
+#endif
+
ipipe_load_cpuid();
return (per_cpu(ipipe_percpu_domain, cpuid) == ipipe_root_domain
@@ -376,3 +384,8 @@ EXPORT_SYMBOL_GPL(show_stack);
#ifndef MULTI_CPU
EXPORT_SYMBOL_GPL(cpu_do_switch_mm);
#endif
+
+#ifdef CONFIG_IPIPE_TRACE_MCOUNT
+void notrace mcount(void);
+EXPORT_SYMBOL(mcount);
+#endif /* CONFIG_IPIPE_TRACE_MCOUNT */
diff -upNr linux-2.6.15-ipipe.orig/arch/arm/kernel/Makefile linux-2.6.15-ipipe/arch/arm/kernel/Makefile
--- linux-2.6.15-ipipe.orig/arch/arm/kernel/Makefile 2006-02-20 14:54:22.0 +0100
+++ linux-2.6.15-ipipe/arch/arm/kernel/Makefile 2006-12-01 13:42:49.0 +0100
@@ -20,6 +20,7 @@ obj-$(CONFIG_ISA_DMA) += dma-isa.o
obj-$(CONFIG_PCI) += bios32.o
obj-$(CONFIG_SMP) += smp.o
obj-$(CONFIG_IPIPE) += ipipe-core.o ipipe-root.o
+obj-$(CONFIG_IPIPE_TRACE_MCOUNT) += ipipe-mcount.o
obj-$(CONFIG_IWMMXT) += iwmmxt.o
AFLAGS_iwmmxt.o := -Wa,-mcpu=iwmmxt
diff -upNr linux-2.6.15-ipipe.orig/arch/arm/kernel/process.c linux-2.6.15-ipipe/arch/arm/kernel/process.c
--- linux-2.6.15-ipipe.orig/arch/arm/kernel/process.c 2006-02-20 14:54:22.0 +0100
+++ linux-2.6.15-ipipe/arch/arm/kernel/process.c 2006-12-14 16:35:09.0 +0100
@@ -89,12 +89,18 @@ void
Re: [Xenomai-core] Re: [Adeos-main] Latency trace on ARM
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 into Ipipe CVS or Xenomai svn. The first file pools all patches for Ipipe, here comes an overview what it comprises: - I-pipe for Samsung S3C24xx - I-pipe tracer for ARM - Introduce __ipipe_mach_release_timer() - Fix ipipe_tsc2ns() - Don't activate the tracer too early during the boot process Please consider these patches for Xenomai 2.3. Thanks! They will be included. The point is that we are not using the Adeos CVS anymore, waiting to switch to git asap. OK, didn't know that. These patches are the most current, please take them and not the ones posted before. Thank you! -- Sebastian ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] Re: adeos-ipipe-2.6.15-arm-1.5-03.patch
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 be the correct replacement. Fixed, thanks. Btw, two 1.5-03 patches went upstream actually, one for 2.6.14, and the other - now fixed - one for 2.6.15. Does the former also need fixing? It does. I will prepare a proper patch also for 2.6.14. -- Sebastian ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Support for 2.6.19
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 that it is some work that needs to be done. I had ported from 2.6.15 to 2.6.17, it was a trivial task as far as I could see, but never tried to port to 2.6.19. There were some architectural changes in 2.6.19, I do not know about their impact on the ARM architecture though. Shortly before christmas I tried to port I-pipe for ARM to 2.6.19 during an insane hacking session. ;-) I tried to do it with I-pipe 1.5 and not with version 1.6 (as Philippe did it for x86) because I felt it could be less work. But probably I was wrong because too much problems appeared that I did not fix because the time is missing ATM. A cleaner approach surely would be to port I-pipe 1.6 for ARM to 2.6.19. Perhaps I can find some time for a second attempt soon. -- Sebastian ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Re: RT-CAN tx_sem
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
[Xenomai-core] Re: iovec overwriting by CAN stack
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 complaints about this /wrt to in-kernel CAN stack usage. It's done here: http://www.rts.uni-hannover.de/xenomai/lxr/source/ksrc/drivers/can/rtca n_ raw.c?v=SVN-trunk#881 http://www.rts.uni-hannover.de/xenomai/lxr/source/ksrc/drivers/can/rtca n_ raw.c?v=SVN-trunk#734 I may have missed something. What are the real complaints? Is there a test program? Not yet (will commit the related patch to our RACK likely later today). It's simply sending frames while re-using the msg+iovec structs in a loop. I always considered the same well-know behaviour of RTnet a bug, but now I found your code is doing this systematically, also for user space callers. Is this behaviour undefined or even required according POSIX or whatever? I don't know, it's Sebastian's Kode. Hmm, hope he will not say that he imitated RTnet... Rather an imitation of the Linux kernel's behaviour. The memcpy_toiovec() and memcpy_fromiovec() functions [1] also modify the original iovec. [1] http://lxr.free-electrons.com/source/net/core/iovec.c But that's the kernel's private (and user-safe) copy. I failed to find it writing that back to user space. Hm. Ad hoc, I don't recall why the userspace's iovec is also updated. Perhaps my intention was to make the use of rtcan_raw_sendmsg consistent for kernel and userspace RT-Tasks so that both can rely on finding modified iovecs after calling sendmsg/recvmsg. But I'm not absolutely sure if there isn't a better explanation for this. I will try to find the reason in my backup memory. ;-) -- Sebastian ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] Xenomai website problem?
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
[Xenomai-core] Re: iovec overwriting by CAN stack
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 on return
(namely iovec_len)? I received some complaints about this /wrt to
in-kernel CAN stack usage.
It's done here:
http://www.rts.uni-hannover.de/xenomai/lxr/source/ksrc/drivers/can/rt
ca n_ raw.c?v=SVN-trunk#881
http://www.rts.uni-hannover.de/xenomai/lxr/source/ksrc/drivers/can/rt
ca n_ raw.c?v=SVN-trunk#734
I may have missed something. What are the real complaints? Is there a
test program?
Not yet (will commit the related patch to our RACK likely later
today). It's simply sending frames while re-using the msg+iovec
structs in a loop.
I always considered the same well-know behaviour of RTnet a bug, but
now I found your code is doing this systematically, also for user
space callers. Is this behaviour undefined or even required
according POSIX or whatever?
I don't know, it's Sebastian's Kode.
Hmm, hope he will not say that he imitated RTnet...
Rather an imitation of the Linux kernel's behaviour. The
memcpy_toiovec() and memcpy_fromiovec() functions [1] also modify the
original iovec.
[1] http://lxr.free-electrons.com/source/net/core/iovec.c
But that's the kernel's private (and user-safe) copy. I failed to find
it writing that back to user space.
Hm. Ad hoc, I don't recall why the userspace's iovec is also updated.
Perhaps my intention was to make the use of rtcan_raw_sendmsg consistent
for kernel and userspace RT-Tasks so that both can rely on finding
modified iovecs after calling sendmsg/recvmsg. But I'm not absolutely
sure if there isn't a better explanation for this. I will try to find the
reason in my backup memory. ;-)
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 need to modify it all then).
Attached is a patch which leaves the caller's iovec unmodified. It compiles
successfully (not tested further).
--
Sebastian
Index: ChangeLog
===
--- ChangeLog (Revision 2348)
+++ ChangeLog (Arbeitskopie)
@@ -1,3 +1,8 @@
+2007-04-02 Sebastian Smolorz [EMAIL PROTECTED]
+
+ * ksrc/drivers/can/rtcan_raw.c (rtcan_raw_recvmsg, rtcan_raw_sendmsg):
+ Remove modification of caller's original iovec.
+
2007-03-31 Philippe Gerum [EMAIL PROTECTED]
* include/nucleus/queue.h (moveq): Fix source tail pointer.
Index: ksrc/drivers/can/rtcan_raw.c
===
--- ksrc/drivers/can/rtcan_raw.c (Revision 2348)
+++ ksrc/drivers/can/rtcan_raw.c (Arbeitskopie)
@@ -731,13 +731,6 @@ ssize_t rtcan_raw_recvmsg(struct rtdm_de
if (rtdm_copy_to_user(user_info, iov-iov_base, frame,
sizeof(can_frame_t)))
return -EFAULT;
-/* Adjust iovec in the common way */
-iov-iov_base += sizeof(can_frame_t);
-iov-iov_len -= sizeof(can_frame_t);
-/* ... and copy it, too. */
-if (rtdm_copy_to_user(user_info, msg-msg_iov, iov,
- sizeof(struct iovec)))
-return -EFAULT;
/* Copy timestamp if existent and wanted */
if (msg-msg_controllen) {
@@ -762,9 +755,6 @@ ssize_t rtcan_raw_recvmsg(struct rtdm_de
/* Copy CAN frame */
memcpy(iov-iov_base, frame, sizeof(can_frame_t));
-/* Adjust iovec in the common way */
-iov-iov_base += sizeof(can_frame_t);
-iov-iov_len -= sizeof(can_frame_t);
/* Copy timestamp if existent and wanted */
if (msg-msg_controllen) {
@@ -878,16 +868,6 @@ ssize_t rtcan_raw_sendmsg(struct rtdm_de
frame = frame_buf;
}
-/* Adjust iovec in the common way */
-iov-iov_base += sizeof(can_frame_t);
-iov-iov_len -= sizeof(can_frame_t);
-/* ... and copy it back to userspace if necessary */
-if (user_info) {
-if (rtdm_copy_to_user(user_info, msg-msg_iov, iov,
- sizeof(struct iovec)))
-return -EFAULT;
-}
-
/* At last, we've got the frame ... */
/* Check if DLC between 0 and 15 */
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] iovec overwriting by CAN stack
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 need to modify it all then).
Attached is a patch which leaves the caller's iovec unmodified. It
compiles successfully (not tested further).
Index: ChangeLog
===
--- ChangeLog (Revision 2348)
+++ ChangeLog (Arbeitskopie)
@@ -1,3 +1,8 @@
+2007-04-02 Sebastian Smolorz [EMAIL PROTECTED]
+
+ * ksrc/drivers/can/rtcan_raw.c (rtcan_raw_recvmsg, rtcan_raw_sendmsg):
+ Remove modification of caller's original iovec.
+
2007-03-31 Philippe Gerum [EMAIL PROTECTED]
* include/nucleus/queue.h (moveq): Fix source tail pointer.
Index: ksrc/drivers/can/rtcan_raw.c
===
--- ksrc/drivers/can/rtcan_raw.c(Revision 2348)
+++ ksrc/drivers/can/rtcan_raw.c(Arbeitskopie)
@@ -731,13 +731,6 @@ ssize_t rtcan_raw_recvmsg(struct rtdm_de
if (rtdm_copy_to_user(user_info, iov-iov_base, frame,
sizeof(can_frame_t)))
return -EFAULT;
-/* Adjust iovec in the common way */
-iov-iov_base += sizeof(can_frame_t);
-iov-iov_len -= sizeof(can_frame_t);
-/* ... and copy it, too. */
-if (rtdm_copy_to_user(user_info, msg-msg_iov, iov,
- sizeof(struct iovec)))
-return -EFAULT;
/* Copy timestamp if existent and wanted */
if (msg-msg_controllen) {
@@ -762,9 +755,6 @@ ssize_t rtcan_raw_recvmsg(struct rtdm_de
/* Copy CAN frame */
memcpy(iov-iov_base, frame, sizeof(can_frame_t));
-/* Adjust iovec in the common way */
-iov-iov_base += sizeof(can_frame_t);
-iov-iov_len -= sizeof(can_frame_t);
/* Copy timestamp if existent and wanted */
if (msg-msg_controllen) {
@@ -878,16 +868,6 @@ ssize_t rtcan_raw_sendmsg(struct rtdm_de
frame = frame_buf;
}
-/* Adjust iovec in the common way */
-iov-iov_base += sizeof(can_frame_t);
-iov-iov_len -= sizeof(can_frame_t);
-/* ... and copy it back to userspace if necessary */
-if (user_info) {
-if (rtdm_copy_to_user(user_info, msg-msg_iov, iov,
- sizeof(struct iovec)))
-return -EFAULT;
-}
-
/* At last, we've got the frame ... */
/* Check if DLC between 0 and 15 */
Basic ACK (as still no one came up remarking we actually need the update
of iovec).
I would just always use struct iovec iov_buf for the internal handling,
means always copy the original (also from in-kernel users) and simply
kill the struct iovec *iov indirection.
IMHO this is not necessary because the original iovec is not modified
unexpectedly even if it resides in kernel space.
--
Sebastian
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] Wrong example code in Native-API-Tour
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 mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Xenomai @ Hannover Messe 2007
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 Sebastien Smorloz if possible and discuss some can driver issues. I plan to be at the fair Friday afternoon but will not be at the university's booth all the time. So we have to agree upon a time. :-) -- Sebastian ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] [PATCH] [arm] support for user space tsc emulation for decrementing counters
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 tsc value.
I will post a second patch for Adeos which implements the kernel side for
s3c24xx platforms on adeos-main.
--
Sebastian
Index: include/asm-arm/syscall.h
===
--- include/asm-arm/syscall.h (Revision 2768)
+++ include/asm-arm/syscall.h (Arbeitskopie)
@@ -4,6 +4,9 @@
* ARM port
* Copyright (C) 2005 Stelian 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 Software Foundation; either version 2 of the License,
@@ -202,6 +205,7 @@
struct {
volatile unsigned *counter;
unsigned mask;
+ volatile unsigned *last_cnt;
volatile unsigned long long *tsc;
} fr;
struct {
@@ -248,6 +252,28 @@
if ((counter mask) (before mask))
before += mask + 1;
return (before ~mask) | (counter mask);
+
+#elif CONFIG_XENO_ARM_HW_DIRECT_TSC == __XN_TSC_TYPE_DECREMENTER
+ const unsigned long long mask = __xn_tscinfo.u.fr.mask;
+ unsigned long long after, before;
+ unsigned counter, last_cnt;
+
+ do {
+ before = *__xn_tscinfo.u.fr.tsc;
+ counter = *__xn_tscinfo.u.fr.counter;
+ last_cnt = *__xn_tscinfo.u.fr.last_cnt;
+ /* compiler barrier. */
+ asm( : /* */ : /* */ : memory);
+
+ after = *__xn_tscinfo.u.fr.tsc;
+ } while (after != before);
+
+ counter = mask;
+ last_cnt = mask;
+ if (counter last_cnt)
+ before += mask + 1;
+ return (before + last_cnt - counter);
+
#endif /* CONFIG_XENO_HW_DIRECT_TSC == __XN_TSC_TYPE_FREERUNNING */
}
@@ -279,8 +305,8 @@
page_size = sysconf(_SC_PAGESIZE);
switch(__xn_tscinfo.type) {
-#if CONFIG_XENO_ARM_HW_DIRECT_TSC == __XN_TSC_TYPE_FREERUNNING
- case __XN_TSC_TYPE_FREERUNNING:{
+ case __XN_TSC_TYPE_FREERUNNING:
+ case __XN_TSC_TYPE_DECREMENTER: {
unsigned long phys_addr;
phys_addr = (unsigned long) __xn_tscinfo.u.fr.counter;
@@ -296,7 +322,6 @@
((char *) addr + (phys_addr (page_size - 1;
break;
}
-#endif /* CONFIG_XENO_ARM_HW_DIRECT_TSC == __XN_TSC_TYPE_FREERUNNING */
case __XN_TSC_TYPE_NONE:
goto error;
Index: include/asm-arm/bits/shadow.h
===
--- include/asm-arm/bits/shadow.h (Revision 2768)
+++ include/asm-arm/bits/shadow.h (Arbeitskopie)
@@ -176,6 +176,12 @@
info.u.fr.tsc = ipipe_info.archdep.tsc.u.fr.tsc;
break;
case IPIPE_TSC_TYPE_DECREMENTER:
+ info.type = __XN_TSC_TYPE_DECREMENTER,
+ info.u.fr.counter = ipipe_info.archdep.tsc.u.fr.counter;
+ info.u.fr.mask = ipipe_info.archdep.tsc.u.fr.mask;
+ info.u.fr.last_cnt = ipipe_info.archdep.tsc.u.fr.last_cnt;
+ info.u.fr.tsc = ipipe_info.archdep.tsc.u.fr.tsc;
+ break;
case IPIPE_TSC_TYPE_NONE:
return -ENOSYS;
Index: configure.in
===
--- configure.in (Revision 2768)
+++ configure.in (Arbeitskopie)
@@ -182,7 +182,8 @@
ixp4xx|pxa) arch=5
tsc_type=__XN_TSC_TYPE_FREERUNNING;;
- s3c2410) arch=4;;
+ s3c2410) arch=4
+ tsc_type=__XN_TSC_TYPE_DECREMENTER;;
sa1100) arch=4
CONFIG_XENO_ARM_SA1100=y
Index: ChangeLog
===
--- ChangeLog (Revision 2768)
+++ ChangeLog (Arbeitskopie)
@@ -1,3 +1,8 @@
+2007-07-19 Sebastian Smolorz [EMAIL PROTECTED]
+
+ * include/asm-arm/syscall.h: Add user-space access to
+ tsc emulation for decrementing counters.
+
2007-07-19 Jan Kiszka [EMAIL PROTECTED]
* ksrc/nucleus/timer.c (xntimer_tick_aperiodic): Keep processing
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [PATCH] [arm] support for user space tsc emulation for decrementing counters
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 tsc value. The struct __xn_tscinfo is a union where fr stands for free-running, the idea was that you could add your own structure for decrementer based tsc. Ah, ok, will change the patch. The abbreviation was not immediately clear to me. ;-) -- Sebastian ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [RFC] Fast Context Switch Extension for ARM Linux
Richard Cochran wrote: I know that this is a bit off topic, yet perhaps some on this list have interest or knowledge in this area. I am also posting this idea to the linux-arm-kernel list. I would like to implement the ARM FCSE under Linux, using the Intel IXP425 board. Before I start, I would like to ask: 1. Has any work already been done in this area? Yes, we at emlix evaluate the feasibility of porting the FASS patch to a modern 2.6 kernel in the context of a customer project. It is far more work than expected because central MM implementations both ARM-specific and Linux-general have changed since the 2.4 days. What we have done is to take the FASS patch and tried to make it work with the 2.6 line rather than implementing the concepts from scratch. So far, we are able to compile a FASS-patched 2.6.21 kernel but it fails when trying to start init. We expect a huge amount of bugs hiding inside the code yet. No wonder, we are still in the middle of the work. I would call the code far from being releasable but before you also begin to do the work we have already performed it is reasonable to post our current status. 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 we either can provide write access to the repository or do it the Linus' way (i.e. we would pull from others' repositories), whichever is preferred. Regards, Sebastian -- 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 embedded linux partner ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [RFC] Fast Context Switch Extension for ARM Linux
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 we either can provide write access to the repository or do it the Linus' way (i.e. we would pull from others' repositories), whichever is preferred. For now, can you post a diff against a known vanilla kernel version? Perhaps later we can set up a public project. Nevertheless, here comes our git repository: http://git.opensource.emlix.com Note that this patch is far less than finished. It is hackish, it does not work, but you asked for it. ;-) The current status is: Sometimes the kernel boots properly and I get a shell prompt. Then a 'ls' is possible, sometimes two but then the systems freezes. Still a lot of work to do but we are ready to do it and are confident of getting this beast running. If anyone is interested: Don't hesitate to help. Regards, Sebastian -- 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 embedded linux partner ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] latencys drifting into negative (Xenomai 2.4.2/2.4.3)
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 constantly linear decrease. See attached plot 'drifting_latencys_in_kernelmode.png' of latency test running 48h on Pentium3 700. This effect could be reproduced, even on other hardware (Pentium-M 1400). As our P3 boards did not support APIC-based timing (IIRC), your kernel has correctly disabled the related kernel support. But the Pentium M should be fine. So could you check if we are seeing some TSC clocks vs. PIT timer rounding issue by enabling the local APIC on the Pentium M? There is no difference in enabling the local APIC on the Pentium M WRT this bug. The usermode (-t0) did not show a drifting, but is influenced by a test ran in kernelmode before. What do you mean with is influenced? Cornelius saw the following behaviour: If the latency test was run in user space first, no drift appeared over time. If latency was run in kernel space (with the reported ngeative drift) a following latency test in user 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-config ist attached as 'config-2.6.24-xenomai-2.4.3__ssm'. Our kernel-configs are both based on a config used with Xenomai 2.3.4 and Linux 2.6.20.15 without any drifting effects. 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 values (that naturally show up when the system runs for a longer time). This hint seems to point into the right direction. I tried out a modified pod_32.h (xnarch_tsc_to_ns() commented out) so that the old implementation in include/asm-generic/bits/pod.h was used. The drifting bug disappeared. So there seems so be a buggy x86-specific implementation of this routine. -- Sebastian ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] latencys drifting into negative (Xenomai 2.4.2/2.4.3)
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 values (that naturally show up when the system runs for a longer time). This hint seems to point into the right direction. I tried out a modified pod_32.h (xnarch_tsc_to_ns() commented out) so that the old implementation in include/asm-generic/bits/pod.h was used. The drifting bug disappeared. So there seems so be a buggy x86-specific implementation of this routine. Hmm, maybe even a conceptional issue: the multiply-shift-based xnarch_tsc_to_ns is not as precise as the still multiply-divide-based xnarch_ns_to_tsc. So when converting from tsc over ns back to tsc, we may loose some bits, maybe too many bits... If you want to know whether llmulshft implementation is broken on x86 or if there is a design issue, you can attempt to use the generic implementation on x86. You mean not using rthal_llmulshft() in arith_32.h and instead using __rthal_generic_llmulshft()? I tried this and it's also suffering from the drift although it seems that the drift per time unit is smaller in the generic case. I will try to get some numbers to compare the values returned from rthal_llmulshft(), __rthal_generic_llmulshft() and __rthal_generic_ullimd(). -- Sebastian ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] latencys drifting into negative (Xenomai 2.4.2/2.4.3)
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 constantly linear decrease. See attached plot 'drifting_latencys_in_kernelmode.png' of latency test running 48h on Pentium3 700. This effect could be reproduced, even on other hardware (Pentium-M 1400). As our P3 boards did not support APIC-based timing (IIRC), your kernel has correctly disabled the related kernel support. But the Pentium M should be fine. So could you check if we are seeing some TSC clocks vs. PIT timer rounding issue by enabling the local APIC on the Pentium M? There is no difference in enabling the local APIC on the Pentium M WRT this bug. The usermode (-t0) did not show a drifting, but is influenced by a test ran in kernelmode before. What do you mean with is influenced? Cornelius saw the following behaviour: If the latency test was run in user space first, no drift appeared over time. If latency was run in kernel space (with the reported ngeative drift) a following latency test in user space showed also negative values but with no additional drift over time. Correction: The initial negative drift when starting user mode latency does not depend on a former run of latency in kernel mode but on the time passed between system start and the starting point of latency -t0. Or, as explained below, it depends on the value of the TSC. 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-config ist attached as 'config-2.6.24-xenomai-2.4.3__ssm'. Our kernel-configs are both based on a config used with Xenomai 2.3.4 and Linux 2.6.20.15 without any drifting effects. 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 values (that naturally show up when the system runs for a longer time). This hint seems to point into the right direction. I tried out a modified pod_32.h (xnarch_tsc_to_ns() commented out) so that the old implementation in include/asm-generic/bits/pod.h was used. The drifting bug disappeared. So there seems so be a buggy x86-specific implementation of this routine. Hmm, maybe even a conceptional issue: the multiply-shift-based xnarch_tsc_to_ns is not as precise as the still multiply-divide-based xnarch_ns_to_tsc. So when converting from tsc over ns back to tsc, we may loose some bits, maybe too many bits... It looks like this bites us in the kernel latency tests (-t2 should suffer as well). Those recalculate their timeouts each round based on absolute nanoseconds. In contrast, the periodic user mode task of -t0 uses a periodic timer that is forwarded via a tsc-based interval. You (or Cornelius) could try to analyse the calculation path of the involved timeouts, specifically to understand why the scheduled timeout of the underlying task timer (which is tsc-based) tend to diverge from the calculated one (ns-based). So here comes the explanation. The error is inside the function rthal_llmulshft(). It returns wrong values which are too small - the higher the given TSC value the bigger the error. The function rtdm_clock_read_monotonic() calls rthal_llmulshft(). As rtdm_clock_read_monotonic() is called every time the latency kernel thread runs [1] the values reported by latency become smaller over time. In contrast, the latency task in user space only uses the conversion from TSC to ns only once when calling rt_timer_inquire [2]. timer_info.date is too small, timer_info.tsc is right. So all calculated deltas in [3] are shifted to a smaller value. This value is constant during the runtime of lateny in user space because no more conversion from TSC to ns occurs. [1] http://www.rts.uni-hannover.de/xenomai/lxr/source/ksrc/drivers/testing/timerbench.c#166 [2] http://www.rts.uni-hannover.de/xenomai/lxr/source/src/testsuite/latency/latency.c#076 [3] http://www.rts.uni-hannover.de/xenomai/lxr/source/src/testsuite/latency/latency.c#111 -- Sebastian ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] latencys drifting into negative (Xenomai 2.4.2/2.4.3)
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 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-config ist attached as 'config-2.6.24-xenomai-2.4.3__ssm'. Our kernel-configs are both based on a config used with Xenomai 2.3.4 and Linux 2.6.20.15 without any drifting effects. 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 values (that naturally show up when the system runs for a longer time). This hint seems to point into the right direction. I tried out a modified pod_32.h (xnarch_tsc_to_ns() commented out) so that the old implementation in include/asm-generic/bits/pod.h was used. The drifting bug disappeared. So there seems so be a buggy x86-specific implementation of this routine. Hmm, maybe even a conceptional issue: the multiply-shift-based xnarch_tsc_to_ns is not as precise as the still multiply-divide-based xnarch_ns_to_tsc. So when converting from tsc over ns back to tsc, we may loose some bits, maybe too many bits... It looks like this bites us in the kernel latency tests (-t2 should suffer as well). Those recalculate their timeouts each round based on absolute nanoseconds. In contrast, the periodic user mode task of -t0 uses a periodic timer that is forwarded via a tsc-based interval. You (or Cornelius) could try to analyse the calculation path of the involved timeouts, specifically to understand why the scheduled timeout of the underlying task timer (which is tsc-based) tend to diverge from the calculated one (ns-based). So here comes the explanation. The error is inside the function rthal_llmulshft(). It returns wrong values which are too small - the higher the given TSC value the bigger the error. The function rtdm_clock_read_monotonic() calls rthal_llmulshft(). As rtdm_clock_read_monotonic() is called every time the latency kernel thread runs [1] the values reported by latency become smaller over time. In contrast, the latency task in user space only uses the conversion from TSC to ns only once when calling rt_timer_inquire [2]. timer_info.date is too small, timer_info.tsc is right. So all calculated deltas in [3] are shifted to a smaller value. This value is constant during the runtime of lateny in user space because no more conversion from TSC to ns occurs. latency does conversions from tsc to ns, but it converts time differences, so the error is small relative to the results. Of course. I wasn't precise with my last statement. It should be: No more conversions from *absolute* TSC values to ns occur. -- Sebastian ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] latencys drifting into negative (Xenomai 2.4.2/2.4.3)
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 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-config ist attached as
'config-2.6.24-xenomai-2.4.3__ssm'.
Our kernel-configs are both based on a config used with
Xenomai 2.3.4
and Linux 2.6.20.15 without any drifting effects.
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
values (that naturally show up when the system runs for a
longer time).
This hint seems to point into the right direction. I tried out a
modified pod_32.h (xnarch_tsc_to_ns() commented out) so that the
old
implementation in include/asm-generic/bits/pod.h was used. The
drifting
bug disappeared. So there seems so be a buggy x86-specific
implementation of this routine.
Hmm, maybe even a conceptional issue: the multiply-shift-based
xnarch_tsc_to_ns is not as precise as the still
multiply-divide-based
xnarch_ns_to_tsc. So when converting from tsc over ns back to
tsc, we
may loose some bits, maybe too many bits...
It looks like this bites us in the kernel latency tests (-t2 should
suffer as well). Those recalculate their timeouts each round
based on
absolute nanoseconds. In contrast, the periodic user mode task of
-t0
uses a periodic timer that is forwarded via a tsc-based interval.
You (or Cornelius) could try to analyse the calculation path of the
involved timeouts, specifically to understand why the scheduled
timeout
of the underlying task timer (which is tsc-based) tend to diverge
from
the calculated one (ns-based).
So here comes the explanation. The error is inside the function
rthal_llmulshft(). It returns wrong values which are too small - the
higher the given TSC value the bigger the error. The function
rtdm_clock_read_monotonic() calls rthal_llmulshft(). As
rtdm_clock_read_monotonic() is called every time the latency kernel
thread runs [1] the values reported by latency become smaller over
time.
In contrast, the latency task in user space only uses the conversion
from TSC to ns only once when calling rt_timer_inquire [2].
timer_info.date is too small, timer_info.tsc is right. So all
calculated
deltas in [3] are shifted to a smaller value. This value is constant
during the runtime of lateny in user space because no more conversion
from TSC to ns occurs.
latency does conversions from tsc to ns, but it converts time
differences, so the error is small relative to the results.
Of course. I wasn't precise with my last statement. It should be: No
more conversions from *absolute* TSC values to ns occur.
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.
Your patch needed two minor corrections (ns instead of ts in functions
xnarch_ns_to_tsc()) in order to compile. A short run (30 minutes) of
latency -t1 seems to prove your bug-fix: There seems to be no drift.
If I got your patch correctly, it doesn't make xnarch_tsc_to_ns more
precise but introduces a new function xnarch_ns_to_tsc() which is also
less precise than the generic xnarch_ns_to_tsc(), right? So isn't there
still the danger of getting wrong values when calling xnarch_tsc_to_ns()
not in combination with xnarch_ns_to_tsc()?
--
Sebastian
---
include/asm-x86/bits/init_32.h |3 ++-
include/asm-x86/bits/init_64.h |3 ++-
include/asm-x86/bits/pod_32.h |7 +++
include/asm-x86/bits/pod_64.h |7 +++
4 files changed, 18 insertions(+), 2 deletions(-)
Index: b/include/asm-x86/bits/init_32.h
===
--- a/include/asm-x86/bits/init_32.h
+++ b/include/asm-x86/bits/init_32.h
@@ -73,7 +73,7 @@ int xnarch_calibrate_sched(void)
static inline int xnarch_init(void)
{
- extern unsigned xnarch_tsc_scale, xnarch_tsc_shift;
+ extern unsigned xnarch_tsc_scale, xnarch_tsc_shift, xnarch_tsc_divide;
int err;
err = rthal_init();
@@ -89,6 +89,7 @@ static inline int xnarch_init(void)
xnarch_init_llmulshft(10, RTHAL_CPU_FREQ,
xnarch_tsc_scale, xnarch_tsc_shift);
+ xnarch_tsc_divide = 1 xnarch_tsc_shift;
err = xnarch_calibrate_sched();
Index: b/include/asm-x86/bits/init_64.h
===
--- a/include/asm-x86/bits/init_64.h
+++ b/include/asm-x86/bits/init_64.h
@@ -70,7 +70,7 @@ int
Re: [Xenomai-core] latencys drifting into negative (Xenomai 2.4.2/2.4.3)
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. Your patch needed two minor corrections (ns instead of ts in functions xnarch_ns_to_tsc()) in order to compile. A short run (30 minutes) of latency -t1 seems to prove your bug-fix: There seems to be no drift. That's good to hear. If I got your patch correctly, it doesn't make xnarch_tsc_to_ns more precise but introduces a new function xnarch_ns_to_tsc() which is also less precise than the generic xnarch_ns_to_tsc(), right? Yes. It is now precisely the inverse imprecision, so to say. :) So isn't there still the danger of getting wrong values when calling xnarch_tsc_to_ns() not in combination with xnarch_ns_to_tsc()? Only if the user decides to implement his own conversion. Xenomai with all its skins and both in kernel and user space should always run through the xnarch_* path. OK, would you commit the patch? -- Sebastian ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] Xenomai at Hannover Messe 2008
Hi all, as last year, the Real-Time Systems Group of the Leibniz Universität Hannover shows several autonomous service robots at the industry fair in Hannover/Germany next week. They are all driven by Xenomai and our real-time appplication construction kit RACK. Our booth is located in hall 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://www.rts.uni-hannover.de ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] revision 3882 breaks compilation of xenomai
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: ../../skins/posix/.libs/libpthread_rt.so: undefined reference to `likely' ../../skins/posix/.libs/libpthread_rt.so: undefined reference to `unlikely' collect2: ld returned 1 exit status Ok. Could you try to add a #include nucleus/compiler.h in ksrc/skins/posix/cb_lock.h ? Yes, that solves it. -- Sebastian ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] CAN filter issues
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 http://www.rts.uni-hannover.de/xenomai/lxr/source/ksrc/drivers/can/rtcan_raw_filter.c?v=2.3.5#064 and http://www.rts.uni-hannover.de/xenomai/lxr/source/ksrc/drivers/can/rtcan_raw_filter.c?v=2.4.4#062 respectively. What worries me is the removal of the AND-operation (can_id can_mask). From my POV this offends the CAN specification which says that the CAN filter mask shall indicate which bits are taken into account when comparing a CAN identifier and which shall be seen as don't care. From your Changelog entry the reason for this modification was to be up to date with the Linux Socket CAN project. So maybe there is also the need to bring up this topic on their ML, too. -- Sebastian ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [PATCH] RT-Socket-CAN: correct bug with filter registration
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 === --- ChangeLog (revision 4287) +++ ChangeLog (working copy) @@ -1,3 +1,9 @@ +2008-10-29 Wolfgang Grandegger [EMAIL PROTECTED] + + * ksrc/drivers/can/rtcan_raw_filter.c(rtcan_raw_mount_filter): + Applying the filter mask required for fast filter checks got lost + somehow with commit 2202. + 2008-10-28 Gilles Chanteperdrix [EMAIL PROTECTED] * ksrc/nucleus/thread.c (xnthread_init): Change initialization Index: ksrc/drivers/can/rtcan_raw_filter.c === --- ksrc/drivers/can/rtcan_raw_filter.c (revision 4287) +++ ksrc/drivers/can/rtcan_raw_filter.c (working copy) @@ -62,6 +62,9 @@ recv_filter-can_id = filter-can_id; recv_filter-can_mask = filter-can_mask ~CAN_INV_FILTER; } + +/* Apply mask for fast filter check */ +recv_filter-can_id = recv_filter-can_mask; } -- Sebastian ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] [BUG] [xenomai-head] xeno_posix.ko cannot be built
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 ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [BUG] [xenomai-head] xeno_posix.ko cannot be built
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(xnarch_divrem_billion); is missing. Well, no. The definition of xnarh_divrem_billion is in the timeconv.h header, which should be included in places where this function is needed. So, what is missing is probably a #include. Hm, I don't think so. The error only appears when building the POSIX skin as module. The attached patch fixes the problem. -- Sebastian diff --git a/include/asm-generic/bits/timeconv.h b/include/asm-generic/bits/timeconv.h index 7d823f7..79060b3 100644 --- a/include/asm-generic/bits/timeconv.h +++ b/include/asm-generic/bits/timeconv.h @@ -93,6 +93,7 @@ static inline void xnarch_init_timeconv(unsigned long long freq) #ifdef __KERNEL__ EXPORT_SYMBOL(xnarch_tsc_to_ns); EXPORT_SYMBOL(xnarch_ns_to_tsc); +EXPORT_SYMBOL(xnarch_divrem_billion); #endif /* __KERNEL__ */ #endif /* !_XENO_ASM_GENERIC_BITS_TIMECONV_H */ ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] [PATCH] rtcan: Add support for CAN PCI cards from ESD
This patch adds support for SJA1000 based PCI CAN interface cards from electronic system design gmbh. The following list of boards are supported: CAN-PCI/200 (tested) CAN-PCI/266 CAN-PMC266 CAN-PCIe/2000 CAN-CPCI/200 CAN-PCI104 The patch is based on the Socket-CAN driver for those boards 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(+), 0 deletions(-) diff --git a/ksrc/drivers/can/sja1000/Kconfig b/ksrc/drivers/can/sja1000/Kconfig index 4d0ed48..53abdd9 100644 --- a/ksrc/drivers/can/sja1000/Kconfig +++ b/ksrc/drivers/can/sja1000/Kconfig @@ -52,6 +52,17 @@ config XENO_DRIVERS_CAN_SJA1000_EMS_PCI working, Xenomai's shared interrupt support must be enabled. +config XENO_DRIVERS_CAN_SJA1000_ESD_PCI + depends on XENO_DRIVERS_CAN_SJA1000 + tristate ESD PCI Cards + help + + This driver supports the esd PCI CAN cards CAN-PCI/200, + CAN-PCI/266, CAN-PMC/266 (PMC), CAN-CPCI/200 (CompactPCI), + CAN-PCIe2000 (PCI Express) and CAN-PCI104/200 (PCI104) + from the esd electronic system design gmbh (http://www.esd.eu). + + config XENO_DRIVERS_CAN_SJA1000_PEAK_DNG depends on XENO_DRIVERS_CAN_SJA1000 tristate PEAK Parallel Port Dongle diff --git a/ksrc/drivers/can/sja1000/Makefile b/ksrc/drivers/can/sja1000/Makefile index 1db102e..09a03ab 100644 --- a/ksrc/drivers/can/sja1000/Makefile +++ b/ksrc/drivers/can/sja1000/Makefile @@ -9,6 +9,7 @@ obj-$(CONFIG_XENO_DRIVERS_CAN_SJA1000_PEAK_PCI) += xeno_can_peak_pci.o obj-$(CONFIG_XENO_DRIVERS_CAN_SJA1000_PEAK_DNG) += xeno_can_peak_dng.o obj-$(CONFIG_XENO_DRIVERS_CAN_SJA1000_IXXAT_PCI) += xeno_can_ixxat_pci.o obj-$(CONFIG_XENO_DRIVERS_CAN_SJA1000_EMS_PCI) += xeno_can_ems_pci.o +obj-$(CONFIG_XENO_DRIVERS_CAN_SJA1000_ESD_PCI) += xeno_can_esd_pci.o obj-$(CONFIG_XENO_DRIVERS_CAN_SJA1000_ISA) += xeno_can_isa.o obj-$(CONFIG_XENO_DRIVERS_CAN_SJA1000_MEM) += xeno_can_mem.o @@ -17,6 +18,7 @@ xeno_can_peak_pci-y := rtcan_peak_pci.o xeno_can_peak_dng-y := rtcan_peak_dng.o xeno_can_ixxat_pci-y := rtcan_ixxat_pci.o xeno_can_ems_pci-y := rtcan_ems_pci.o +xeno_can_esd_pci-y := rtcan_esd_pci.o xeno_can_isa-y := rtcan_isa.o xeno_can_mem-y := rtcan_mem.o @@ -31,6 +33,7 @@ obj-$(CONFIG_XENO_DRIVERS_CAN_SJA1000_PEAK_PCI) += xeno_can_peak_pci.o obj-$(CONFIG_XENO_DRIVERS_CAN_SJA1000_PEAK_DNG) += xeno_can_peak_dng.o obj-$(CONFIG_XENO_DRIVERS_CAN_SJA1000_IXXAT_PCI) += xeno_can_ixxat_pci.o obj-$(CONFIG_XENO_DRIVERS_CAN_SJA1000_EMS_PCI) += xeno_can_ems_pci.o +obj-$(CONFIG_XENO_DRIVERS_CAN_SJA1000_ESD_PCI) += xeno_can_esd_pci.o obj-$(CONFIG_XENO_DRIVERS_CAN_SJA1000_ISA) += xeno_can_isa.o obj-$(CONFIG_XENO_DRIVERS_CAN_SJA1000_MEM) += xeno_can_mem.o @@ -41,6 +44,7 @@ xeno_can_peak_pci-objs := rtcan_peak_pci.o xeno_can_peak_dng-objs := rtcan_peak_dng.o xeno_can_ixxat_pci-objs := rtcan_ixxat_pci.o xeno_can_ems_pci-objs := rtcan_ems_pci.o +xeno_can_esd_pci-objs := rtcan_esd_pci.o xeno_can_isa-objs := rtcan_isa.o xeno_can_mem-objs := rtcan_mem.o @@ -65,6 +69,9 @@ xeno_can_ixxat_pci.o: $(xeno_can_ixxat_pci-objs) xeno_can_ems_pci.o: $(xeno_can_ems_pci-objs) $(LD) -r -o $@ $(xeno_can_ems_pci-objs) +xeno_can_esd_pci.o: $(xeno_can_esd_pci-objs) + $(LD) -r -o $@ $(xeno_can_esd_pci-objs) + xeno_can_isa.o: $(xeno_can_isa-objs) $(LD) -r -o $@ $(xeno_can_isa-objs) diff --git a/ksrc/drivers/can/sja1000/rtcan_esd_pci.c b/ksrc/drivers/can/sja1000/rtcan_esd_pci.c new file mode 100644 index 000..79cf8b6 --- /dev/null +++ b/ksrc/drivers/can/sja1000/rtcan_esd_pci.c @@ -0,0 +1,354 @@ +/* + * Copyright (C) 2009 Sebastian Smolorz se...@gmx.net + * + * This driver is based on the Socket-CAN driver esd_pci.c, + * Copyright (C) 2007 Wolfgang Grandegger w...@grandegger.com + * Copyright (C) 2008 Sascha Hauer s.ha...@pengutronix.de, Pengutronix + * Copyright (C) 2009 Matthias Fuchs matthias.fu...@esd.eu, esd gmbh + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the version 2 of the GNU General Public License + * as published by the Free Software Foundation + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software Foundation, + * Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA. + */ + +#include linux/module.h +#include linux/ioport.h +#include linux/delay.h +#include linux/pci.h +#include asm/io.h + +#include rtdm/rtdm_driver.h + +/* CAN device profile */ +#include rtdm/rtcan.h +#include rtcan_dev.h +#include rtcan_raw.h +#include
[Xenomai-core] [PATCH] can: Free I/O region when unloading the xeno_can_isa.ko driver
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/drivers/can/sja1000/rtcan_isa.c @@ -1,8 +1,8 @@ /* * Copyright (C) 2006 Wolfgang Grandegger w...@grandegger.com * - * Copyright (C) 2005, 2006 Sebastian Smolorz - * sebastian.smol...@stud.uni-hannover.de + * Copyright (C) 2005, 2006, 2009 Sebastian Smolorz + * smol...@rts.uni-hannover.de * * * This program is free software; you can redistribute it and/or modify it @@ -189,6 +189,7 @@ static void rtcan_isa_exit(void) if (!dev) continue; rtcan_sja1000_unregister(dev); + release_region(io[i], RTCAN_ISA_PORT_SIZE); rtcan_dev_free(dev); } } ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [PATCH] rtcan: add rtcan_plx_pci driver
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 - esd CAN-PCIe/2000 - Marathon CAN-bus-PCI card (http://www.marathon.ru/) - TEWS TECHNOLOGIES TPMC810 card (http://www.tews.com/) The esd cards mentioned above are supported by the RTCAN driver xeno_can_esd_pci. Why do you propose a new driver instead of extending the existing one? -- Sebastian ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [PATCH] rtcan: add rtcan_plx_pci driver
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-7841/cPCI-7841 SE card - esd CAN-PCI/CPCI/PCI104/200 (http://www.esd.eu/) - esd CAN-PCI/PMC/266 - esd CAN-PCIe/2000 - Marathon CAN-bus-PCI card (http://www.marathon.ru/) - TEWS TECHNOLOGIES TPMC810 card (http://www.tews.com/) The esd cards mentioned above are supported by the RTCAN driver xeno_can_esd_pci. Why do you propose a new driver instead of extending the existing one? For Socket-CAN, this driver is supposed to support all PLX PCI based boards including the esd CAN PCI cards and also the IXXAT PCI board (not yet done, though). The RTCAN driver xeno_can_esd_pci is a *dedicated* driver for that card without generic support for the PLX PCI chips. Extending it makes little sense. The question is if we want to drop xeno_can_esd_pci and xeno_can_ixxat_pci. With extending the esd_pci driver I meant to take this driver as a basis to add support for more cards. Of course this would mean to rename the driver in order to reflect that. I'm not against a unification of esd_pci and ixxat_pci but it's unneccessary work to write a new RTCAN driver if there exists another one which is tried and tested in the field. So my question was why Pavel did not take the esd_pci driver as the starting position. So talking about potential issues in Pavel's code (e.g. the function plx_pci_check_sja1000()) could be unnecessary if he derived the new driver from esd_pci . -- Sebastian ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [PATCH] rtcan: add rtcan_plx_pci driver
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: - 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 - esd CAN-PCIe/2000 - Marathon CAN-bus-PCI card (http://www.marathon.ru/) - TEWS TECHNOLOGIES TPMC810 card (http://www.tews.com/) The esd cards mentioned above are supported by the RTCAN driver xeno_can_esd_pci. Why do you propose a new driver instead of extending the existing one? For Socket-CAN, this driver is supposed to support all PLX PCI based boards including the esd CAN PCI cards and also the IXXAT PCI board (not yet done, though). The RTCAN driver xeno_can_esd_pci is a *dedicated* driver for that card without generic support for the PLX PCI chips. Extending it makes little sense. The question is if we want to drop xeno_can_esd_pci and xeno_can_ixxat_pci. With extending the esd_pci driver I meant to take this driver as a basis to add support for more cards. Of course this would mean to rename the driver in order to reflect that. I'm not against a unification of esd_pci and ixxat_pci but it's unneccessary work to write a new RTCAN driver if there exists another one which is tried and tested in the field. So my question was why Pavel did not take the esd_pci driver as the starting position. He did *not* write a new RTCAN driver. He ported plx_pci.c from the mainline kernel to rtcan, So it is a new RTCAN driver - never mind, just nitpicking. ;-) As I said, I'm in favour of a unified driver which supports more cards than esd_pci and ixxat_pci. The question is how we proceed best when we include rt_sja1000_plx_pci. I suggest not to remove esd_pci immediately but rather mark it deprecated with a reference to the new driver, e.g. in the Kconfig help text. That way we would have a fallback driver in case of unforeseen issues with the new driver. which is much less work and even less error prune. So talking about potential issues in Pavel's code (e.g. the function plx_pci_check_sja1000()) could be unnecessary if he derived the new driver from esd_pci . Does it harm? It is necessary to find out the number of channels on some cards. Yes, you are right. -- Sebastian ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] Bug in Linux kernel 2.6.37 blocks xenomai threads
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 expected. Philippe, Gilles, maybe you could generate a new i-pipe patch based on the newest 2.6.37-series kernel. I patched a 2.6.37.6 kernel with adeos- ipipe-2.6.37-x86-2.9-00.patch and the problem was gone. -- Sebastian ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
