rtnet-users Mailing List for RTnet - Real-Time Networking for Linux
Brought to you by:
bet-frogger,
kiszka
You can subscribe to this list here.
2003 |
Jan
(31) |
Feb
(54) |
Mar
(37) |
Apr
(25) |
May
(77) |
Jun
(56) |
Jul
(38) |
Aug
(21) |
Sep
(49) |
Oct
(22) |
Nov
(45) |
Dec
(42) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2004 |
Jan
(46) |
Feb
(56) |
Mar
(70) |
Apr
(22) |
May
(36) |
Jun
(33) |
Jul
(23) |
Aug
(22) |
Sep
(20) |
Oct
(85) |
Nov
(40) |
Dec
(23) |
2005 |
Jan
(17) |
Feb
(13) |
Mar
(17) |
Apr
(23) |
May
(72) |
Jun
(56) |
Jul
(41) |
Aug
(17) |
Sep
(29) |
Oct
(19) |
Nov
(62) |
Dec
(44) |
2006 |
Jan
(33) |
Feb
(9) |
Mar
(131) |
Apr
(32) |
May
(39) |
Jun
(26) |
Jul
(45) |
Aug
(124) |
Sep
(57) |
Oct
(80) |
Nov
(69) |
Dec
(26) |
2007 |
Jan
(50) |
Feb
(39) |
Mar
(53) |
Apr
(23) |
May
(148) |
Jun
(59) |
Jul
(71) |
Aug
(91) |
Sep
(99) |
Oct
(63) |
Nov
(113) |
Dec
(27) |
2008 |
Jan
(9) |
Feb
(12) |
Mar
(38) |
Apr
(65) |
May
(65) |
Jun
(16) |
Jul
(8) |
Aug
(55) |
Sep
(15) |
Oct
(29) |
Nov
(28) |
Dec
(7) |
2009 |
Jan
(6) |
Feb
(6) |
Mar
(6) |
Apr
(10) |
May
(4) |
Jun
(7) |
Jul
(28) |
Aug
(4) |
Sep
(17) |
Oct
(16) |
Nov
(18) |
Dec
(30) |
2010 |
Jan
(6) |
Feb
(15) |
Mar
(46) |
Apr
(48) |
May
(63) |
Jun
(13) |
Jul
(40) |
Aug
(11) |
Sep
(28) |
Oct
(35) |
Nov
(5) |
Dec
(8) |
2011 |
Jan
(14) |
Feb
(17) |
Mar
(15) |
Apr
(9) |
May
(2) |
Jun
|
Jul
(10) |
Aug
(6) |
Sep
(13) |
Oct
(2) |
Nov
(9) |
Dec
(1) |
2012 |
Jan
(19) |
Feb
(13) |
Mar
(1) |
Apr
|
May
(14) |
Jun
(21) |
Jul
(13) |
Aug
(3) |
Sep
(8) |
Oct
(28) |
Nov
|
Dec
(6) |
2013 |
Jan
(3) |
Feb
|
Mar
(8) |
Apr
|
May
(18) |
Jun
(16) |
Jul
|
Aug
(12) |
Sep
(5) |
Oct
(14) |
Nov
(9) |
Dec
(8) |
2014 |
Jan
(5) |
Feb
(4) |
Mar
(3) |
Apr
(3) |
May
(13) |
Jun
(6) |
Jul
(2) |
Aug
|
Sep
(2) |
Oct
(2) |
Nov
(8) |
Dec
(8) |
2015 |
Jan
(22) |
Feb
|
Mar
(1) |
Apr
(3) |
May
(4) |
Jun
(3) |
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2018 |
Jan
|
Feb
|
Mar
|
Apr
(2) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
|
2019 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(2) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2023 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Brandon Ho <br...@re...> - 2023-07-14 02:42:24
|
Hi, I have been playing around with trying to send UDP messages over RTnet but have run into a weird bug where the UDP packets sent with the RTnet network driver end up with an incorrect checksum. Currently I do not run RTmac or tdma. The script I am running to send the UDP packets is the example Xenomai native script from the RTnet repo: https://sourceforge.net/p/rtnet/code/ci/master/tree/examples/xenomai/native/frag-ip.c I use this script largely unchanged (just changing the dest/local ip to that of my devices) A couple more details: My startup script for RTnet is as follows modprobe rtnet >/dev/null || exit 1 modprobe rtipv4 >/dev/null || exit 1 modprobe $RT_DRIVER >/dev/null || exit 1 echo $ETHERNET_PCI_BUS_NUM > /sys/bus/pci/devices/$ETHERNET_PCI_BUS_NUM/driver/unbind echo $ETHERNET_PCI_BUS_NUM > /sys/bus/pci/drivers/$RT_DRIVER/bind modprobe rtpacket >/dev/null || exit 1 modprobe rtudp >/dev/null || exit 1 modprobe rt_loopback >/dev/null || exit 1 $RTIFCONFIG rtlo up 127.0.0.1 $RTIFCONFIG rteth0 up $IP_ADDR netmask $NETMASK sleep 3 $RTROUTE solicit $HOST_IP dev rteth0 The IP_ADDR is the local address of the device and the HOST_IP refers to the end host I'd like to send packets to -- all other vars follow the convention in the default rtnet startup script. I am able to rtping my end host successfully. When I wireshark on the end host (device receiving the UDP packets), I see that the checksum is consistently wrong, but the data payload is correct. When I unload the rt driver from the network card (rt_e1000e) and load back the normal driver (e1000e) the checksum is correct. Just wondering what might be wrong. System info: (this is what I see when I run xeno-config --info) Xenomai version: Xenomai/cobalt v3.2.2 -- #62edc8a (2023-02-24 18:50:51 +0100) Linux xxxx-xxxxxxxx-2 5.15.98-xen3.2+ #4 SMP IRQPIPE Thu Mar 23 02:04:47 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux Kernel parameters: BOOT_IMAGE=/boot/vmlinuz-5.15.98-xen3.2+ root=UUID=f236e094-4a8a-49e8-829f-42f54b1eb5d8 ro quiet splash i915.enable_rc6=0 i915.enable_dc=0 noapic nosmap xenomai.smi=1 xenomai.allowed_group=30000 cpuidle.off=1 vt.handoff=7 Cobalt core 3.2.2 detected Compiler: gcc version 11.3.0 (Ubuntu 11.3.0-1ubuntu1~22.04) Build args: Thanks! |
From: danwe <dan...@gm...> - 2019-07-19 14:12:43
|
Hello, I have Xenomai 2 with RTnet on a BeagleBone Black. I ask myself how can I make TDMA run on BeagleBone Black? I have changed the rtnet.conf file so that it will use TDMA.conf file. In rtnet file I saw some drivers like tdma and rtmac. Do I have to load these drivers when using TDMA? I do only have rtmac but not tdma drivers on my RTnet framework. If TDMA will works, do I see any output of my communication cycle or anything that shows that TDMA is running? What else do I have to change in rtnet.conf? I have just changed the very last line for using TDMA.conf file and I have changed TDMA_MODE to master for my master BBB and to slave for my slave BBB. I can also see there the IPs 10.0.0.1/2/3/4. Do I have to use those IPs for enabling TDMA and that's it? Can someone please tell me how to using TDMA. Thanks. Kind Regards Daniel |
From: danwe <dan...@gm...> - 2019-07-13 15:02:52
|
Hello, I have a BeagleBone Black with Xenomai / RTnet installed. At the moment I am trying to use internet via Ethernet connection to my laptop. On my BBB I get "noone cared for paket" messages. So I ask myself what is the difference between RTnet frames and Ethernet frames of my Laptop so that it cannot recognise each other? Is it possible to use Internet via Ethernet connection to my laptop? Thanks. Daniel |
From: Sakshi B. <sak...@gm...> - 2018-11-06 15:13:34
|
Hi, I have a Beagleboard X15, on which I have installed Xenomai/Cobalt: v3.07. I have enabled RTnet and it is running. $ rtifconfig -a rtlo Medium: Local Loopback IP address: 127.0.0.1 UP LOOPBACK RUNNING MTU: 1500 $rtnet start ioctl: No such device ioctl: No such device ioctl: No such device ioctl: No such device ioctl (add): No such device ioctl (add): No such device ioctl (add): No such device vnic0: ERROR while getting interface flags: No such device Waiting for all slaves...ioctl: No such device ioctl: No such device $lspci -k 00:00.0 PCI bridge: Texas Instruments Multicore DSP+ARM KeyStone II SOC (rev 01) I think this is the problem, I cannot find the kernel driver in use. Could anybody provide any help on how I can proceed from here? -- Thanks and Regards Sakshi Bansal |
From: Jan K. <jan...@si...> - 2018-04-06 14:05:16
|
On 2018-04-04 11:41, theman whosoldtheworld wrote: > I read some mail on mailing list about the project to port rtnet on > rt-preempt kernel without using a rtai or xenomai kernel. > > Is possible now to use rtnet on rt-preempt kernel? Usually I use 4.x kernel > To my knowledge, no one has done that porting so far. Jan -- Siemens AG, Corporate Technology, CT RDA IOT SES-DE Corporate Competence Center Embedded Linux |
From: theman w. <ble...@gm...> - 2018-04-04 09:41:27
|
I read some mail on mailing list about the project to port rtnet on rt-preempt kernel without using a rtai or xenomai kernel. Is possible now to use rtnet on rt-preempt kernel? Usually I use 4.x kernel regards bkt |
From: bugfix e. <eb...@gm...> - 2015-07-16 00:43:40
|
Hello, did someone is using rt-net to the configuration Ubuntu 4.14 Linux-3:14:17 Xenomai-2.6.4 gcc-4.8 g ++ 4.8? Following the instructions: # Install RTnet Get patch # 0001-Fix-compilatin-issues-on-kernel-above-3.10.patch from # http://sourceforge.net/p/rtnet/mailman/attachment/548fe484eab803.95654079%40wp.pl/1/ # Put patch # 0001-Fix-compilatin-issues-on-kernel-above-3.10.patch # In / usr / src sudo git clone git: //git.code.sf.net/p/rtnet/code rtnet-code sudo ln -s rtnet-code rtnet cd rtnet sudo git apply ../0001-Fix-compilatin-issues-on-kernel-above-3.10.patch sudo su # make menuconfig Select drivers for amd and intel NICs exit sudo make -j8 (ERROR HAPPENS HERE) sudo make install In the make command is generated the following error ... Does anyone know how to fix this? Thanks. Error bellow... /usr/src/rtnet-code/stack/rtnet_module.c: In function ‘rtnet_read_proc_version’: /usr/src/rtnet-code/stack/rtnet_module.c:122:55: error: macro "__DATE__" might prevent reproducible builds [-Werror=date-time] "RTnet " RTNET_PACKAGE_VERSION " - built on " __DATE__ " " __TIME__ "\n" ^ /usr/src/rtnet-code/stack/rtnet_module.c:122:68: error: macro "__TIME__" might prevent reproducible builds [-Werror=date-time] "RTnet " RTNET_PACKAGE_VERSION " - built on " __DATE__ " " __TIME__ "\n" ^ /usr/src/rtnet-code/stack/rtnet_module.c: In function ‘rtnet_proc_register’: /usr/src/rtnet-code/stack/rtnet_module.c:212:5: error: implicit declaration of function ‘create_proc_entry’ [-Werror=implicit-function-declaration] rtnet_proc_root = create_proc_entry("rtnet", S_IFDIR, 0); ^ /usr/src/rtnet-code/stack/rtnet_module.c:212:21: warning: assignment makes pointer from integer without a cast rtnet_proc_root = create_proc_entry("rtnet", S_IFDIR, 0); ^ /usr/src/rtnet-code/stack/rtnet_module.c:216:16: warning: assignment makes pointer from integer without a cast proc_entry = create_proc_entry("devices", S_IFREG | S_IRUGO | S_IWUSR, ^ /usr/src/rtnet-code/stack/rtnet_module.c:220:15: error: dereferencing pointer to incomplete type proc_entry->read_proc = rtnet_read_proc_devices; ^ /usr/src/rtnet-code/stack/rtnet_module.c:222:16: warning: assignment makes pointer from integer without a cast proc_entry = create_proc_entry("rtskb", S_IFREG | S_IRUGO | S_IWUSR, ^ /usr/src/rtnet-code/stack/rtnet_module.c:226:15: error: dereferencing pointer to incomplete type proc_entry->read_proc = rtnet_read_proc_rtskb; ^ /usr/src/rtnet-code/stack/rtnet_module.c:228:16: warning: assignment makes pointer from integer without a cast proc_entry = create_proc_entry("version", S_IFREG | S_IRUGO | S_IWUSR, ^ /usr/src/rtnet-code/stack/rtnet_module.c:232:15: error: dereferencing pointer to incomplete type proc_entry->read_proc = rtnet_read_proc_version; ^ /usr/src/rtnet-code/stack/rtnet_module.c:234:16: warning: assignment makes pointer from integer without a cast proc_entry = create_proc_entry("stats", S_IRUGO, rtnet_proc_root); ^ /usr/src/rtnet-code/stack/rtnet_module.c:237:15: error: dereferencing pointer to incomplete type proc_entry->read_proc = rtnet_read_proc_stats; ^ /usr/src/rtnet-code/stack/rtnet_module.c: In function ‘rtnet_init’: /usr/src/rtnet-code/stack/rtnet_module.c:280:64: error: macro "__DATE__" might prevent reproducible builds [-Werror=date-time] printk("\n*** RTnet " RTNET_PACKAGE_VERSION " - built on " __DATE__ " " __TIME__ ^ /usr/src/rtnet-code/stack/rtnet_module.c:280:77: error: macro "__TIME__" might prevent reproducible builds [-Werror=date-time] printk("\n*** RTnet " RTNET_PACKAGE_VERSION " - built on " __DATE__ " " __TIME__ ^ cc1: some warnings being treated as errors make[4]: *** [/usr/src/rtnet-code/stack/rtnet_module.o] Error 1 make[4]: *** Waiting for unfinished jobs.... make[3]: *** [_module_/usr/src/rtnet-code/stack] Error 2 make[3]: Leaving directory `/usr/src/linux-3.14.17' make[2]: *** [all-local.ko] Error 2 make[2]: Leaving directory `/usr/src/rtnet-code/stack' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/usr/src/rtnet-code/stack' make: *** [all-recursive] Error 1 |
From: Gilles C. <gil...@xe...> - 2015-06-28 15:06:10
|
On Sun, Jun 28, 2015 at 04:24:42PM +0200, Jan Kiszka wrote: > - transfer of setup into QEMU/KVM, then using built-in gdbstub > (works like a hardware debugger, just cheaper and faster) You can't be faster than a JTAG debugger. With a JTAG debugger, the processor runs at full speed, with QEMU, even with KVM it does not, because some things are still emulated. For instance, if your processor does not support what is called "extended page tables", the job of handling the MMU page tables is emulated in the qemu host, and that hurts. If you look at the second column of the list on intel website: http://ark.intel.com/Products/VirtualizationTechnology You will see that even though all core i* processors support EPT, older processors do not, and very few Atom processors do. By contrast, even the lowest end processor that supports JTAG (and I have never met one which did not) does not need to emulate its MMU when running in a debugger. -- Gilles. https://click-hack.org |
From: Jan K. <jan...@we...> - 2015-06-28 14:24:52
|
On 2015-06-23 10:38, Tho...@st... wrote: > Hello everybody, > > we have a strange behavior with RTnet and need some help. > > We are using a sensor tethered via Ethernet to a rteth-NIC exclusively. > The sensor has to be configured, started and stopped with short > http-commands. For this we are using the RTnet tcp-module. > The continuous sensor-data itself are provided with UDP and for this we > are using the RTnet udp-module. > Thus far everything works fine. > > When we sent http-commands for e.g. startup to a second sensor connected > to a second rteth-NIC and the first sensor is already in continuous-data > delivering mode (UDP), the whole operating-system freezes and there is no > response anymore. So we are not able to debug anything. > This happens often, if the data-volume of the continuous-data is small, > and it crashes nearly always, if the data-volume is larger. > > In this case, both threads are running at the same cpu. We find out, when > we switch one of the threads to another cpu, everything seems to work > fine, but we have no long-term experiences yet. In addition this approach > seems to be just a work-around. Is the Xenomai watchdog enabled, to catch run-away threads? > > If you have some ideas, remarks or if you need more information, please > let me know. Thank you! There are plenty of ways to debug even such hard freezes (well, most of them). First of all, make sure you have a serial console working and the kernel reporting to it. Then these are some of your options: - NMI watchdog (should throw a backtrace after some seconds) - I-pipe and Xenomai self-checks (build-time switches - may catch lockups or illicit API uses) - step-wise instrumentation of code to narrow-down the lockup (tedious work, I know) - hardware debugger (JTAG), less common on x86 - I suspect you are on that arch - transfer of setup into QEMU/KVM, then using built-in gdbstub (works like a hardware debugger, just cheaper and faster) HTH, Jan |
From: <Tho...@st...> - 2015-06-23 08:53:44
|
Hello everybody, we have a strange behavior with RTnet and need some help. We are using a sensor tethered via Ethernet to a rteth-NIC exclusively. The sensor has to be configured, started and stopped with short http-commands. For this we are using the RTnet tcp-module. The continuous sensor-data itself are provided with UDP and for this we are using the RTnet udp-module. Thus far everything works fine. When we sent http-commands for e.g. startup to a second sensor connected to a second rteth-NIC and the first sensor is already in continuous-data delivering mode (UDP), the whole operating-system freezes and there is no response anymore. So we are not able to debug anything. This happens often, if the data-volume of the continuous-data is small, and it crashes nearly always, if the data-volume is larger. In this case, both threads are running at the same cpu. We find out, when we switch one of the threads to another cpu, everything seems to work fine, but we have no long-term experiences yet. In addition this approach seems to be just a work-around. If you have some ideas, remarks or if you need more information, please let me know. Thank you! Software versions: - Linux kernel 3.8.13 - Xenomai 2.6.3 - RTnet 0.9.13.-08.2013 Best regards/ Mit freundlichen Grüßen Thomas Wittmann STILL GmbH, Sitz der Gesellschaft: Hamburg, Registergericht: Hamburg HRB 11168, Ust-IdNr. DE 811145412, Aufsichtsrat: Dr. Thomas Toepfer (Vorsitzender), Geschäftsführung: Gordon Riske (Vorsitzender), Thomas A. Fischer, Goran Mihajlovic, Olaf Schulz |
From: Klemen D. <kle...@ya...> - 2015-05-28 06:03:11
|
Hello everybody, I am trying to read the mac adders from my Network Interface Card, i noticed this option is supported since rtnet-0.9.10. I tried the following: ret = rt_dev_ioctl(Sock, SIOCGIFHWADDR, &readMAC); if (ret < 0) { rt_dev_close(Sock); rtapi_print_msg(RTAPI_MSG_ERR, "Read MAC error %d\n", ret); return -1; } else { rtapi_print_msg(RTAPI_MSG_ERR, "Read MAC OK\n"); } It return error -19. Does any body know what is the meaning of this error number? I also tried the SIOCGIFINDEX, but it returns the same error. I am using RTAI.Does anybody have an idea what could be the problem? Best RegardsKlemen |
From: Klemen D. <kle...@ya...> - 2015-05-15 21:54:01
|
Thank you for your reply,That is one of the options i could use, but as i understand from the TDMA specification, the Transmission_time_stamp is added to the frame at the time of transmission - i assume by the NIC driver.I would like to generate RTnet sync frames in RTAI_periodic_mode, so i thought if i could somehow trigger the sync frame and pass the Scheduled_time_stamp parameter. Regards,Klemen On Friday, May 15, 2015 11:33 PM, Mariusz Janiak <mar...@wp...> wrote: #yiv8626703574 blockquote {padding-left:1ex;margin:0px 0px 0px 0.8ex;border-left:#cccccc 1px solid;}#yiv8626703574 p {margin:0px;padding:0px;} Hello everybody, I am looking for a way to somehow manually transmit the sysc frame, without loading the RTmac/TDMA. Is it possible ti open/initialize the socket for RTmac - similar to UDP socket, that is described in examples? Best RegardsKlemen Hi Klemen, It should be possible with a row socket. You need to prepare a Ethernet frame compliant to the TDMA sync frame. In fact you can do the same with regular Linux sockets, why do you need RTnet suppoerted by real-time system? Mariusz |
From: Klemen D. <kle...@ya...> - 2015-05-15 10:38:35
|
Hello everybody, I am looking for a way to somehow manually transmit the sysc frame, without loading the RTmac/TDMA. Is it possible ti open/initialize the socket for RTmac - similar to UDP socket, that is described in examples? Best RegardsKlemen |
From: Buchner, M. AVL/A. <Mic...@av...> - 2015-04-22 07:13:55
|
>On 2015-04-21 17:51, Buchner, Michael AVL/AT wrote: >> Hi, >> >> I'm new here and a have maybe a stupid question. I'd like to use the >> rtnet framework to implement TCP/IP sockets at xenomai. I do not need >> hard realtime for the ethernet. I just wont to communicate. The >> problem is now that I also want to use the physical ethernet port in >> the linux part of the system. Is that possible or not. If yes how. If >> not what is the best workaround for that problem. (I only have one >> free physical ethernet port) >In that case, just push the data to a standard Linux TCP socket, either directly (at the price of switching your RT thread to non-RT) or via a low-prio proxy thread that gets kicked by the high-prio RT >thread. >Jan Tank's for the quick answer. I will pick up this proxy idea. Sometimes I lose sight of the wood for the trees as it seems. With best regards Michael ____________________________________________________________________________ AVL List GmbH, Firmensitz: Graz, Firmenbuchnummer: FN 53507M, Landesgericht fuer ZRS Graz |
From: Jan K. <jan...@we...> - 2015-04-22 05:21:22
|
On 2015-04-21 17:51, Buchner, Michael AVL/AT wrote: > Hi, > > I'm new here and a have maybe a stupid question. I'd like to use the rtnet framework to implement TCP/IP sockets at xenomai. I do not need hard realtime for the ethernet. I just wont to communicate. The problem is now that I also want to use the physical ethernet port in the linux part of the system. Is that possible or not. If yes how. If not what is the best workaround for that problem. (I only have one free physical ethernet port) In that case, just push the data to a standard Linux TCP socket, either directly (at the price of switching your RT thread to non-RT) or via a low-prio proxy thread that gets kicked by the high-prio RT thread. Jan |
From: Buchner, M. AVL/A. <Mic...@av...> - 2015-04-21 16:09:17
|
Hi, I'm new here and a have maybe a stupid question. I'd like to use the rtnet framework to implement TCP/IP sockets at xenomai. I do not need hard realtime for the ethernet. I just wont to communicate. The problem is now that I also want to use the physical ethernet port in the linux part of the system. Is that possible or not. If yes how. If not what is the best workaround for that problem. (I only have one free physical ethernet port) Thank you in advance, Michael Buchner ____________________________________________________________________________ AVL List GmbH, Firmensitz: Graz, Firmenbuchnummer: FN 53507M, Landesgericht fuer ZRS Graz |
From: Mariusz J. <mar...@wp...> - 2015-03-24 12:03:23
|
Hi, I have updated the 0001-Fix-compilatin-issues-on-kernel-above-3.10.patch, which has fixed the compilation issues but introduce several bugs that have broken a kernel modules when RTnet proc files have been read. This updated patch remove issues with accessing proc subsystem. It should be applied to origin/master branch. Best, Mariusz Janiak |
From: Gilles C. <gil...@xe...> - 2015-01-21 07:57:05
|
On Tue, Jan 20, 2015 at 04:25:58PM +0100, Leopold Palomo-Avellaneda wrote: > El Dimarts, 20 de gener de 2015, a les 08:57:30, Leopold Palomo-Avellaneda va > escriure: > > > > Yes, I know, that but I tried and I had not any compilation issue. The no > > important thing was that I disable all rtdm, not important that all ;-) > > > > I will try to compile with the latest git. > > Just to summarize: > > - I have compiled with gcc-4.9 (debian jessie) xenomai with latest git (ok) > - I have patched 3.16.0 with adeos patch (ok) and xenomai (ok) > - I have compiled rtnet. Two changes: Mariusz Janiak patch and remove __DATE__ > __TIME__ macros > > - I have run my soem rt version and it has worked :-) At least my motor is > moving ... > > I know that I have to check Xenomai-3 ... but, what about to release a > xenomai-2.6.5 and rtnet-0.9.14 with the latest git, or something similar? I am not the one in charge or releasing rtnet, just Xenomai. A release of Xenomai will happen in due time (at least not before Xenomai over Linux 3.16 is fixed, because it currently has some issues). And as I said, Xenomai 2.x does not have priority anyway, it is not like if there was hundreds of developers maintaining xenomai. -- Gilles. |
From: Gilles C. <gil...@xe...> - 2015-01-21 07:53:24
|
On Wed, Jan 21, 2015 at 08:51:52AM +0100, Leopold Palomo-Avellaneda wrote: > El Dimarts, 20 de gener de 2015, a les 08:26:29, Gilles Chanteperdrix va > escriure: > > > > No idea, really, I am only interested in 3.x, 2.x series will no > > longer evolve now. And again, in 3.x, rtnet is integrated into > > xenomai, so much easier to compile. And since you were the one to > > ask for rtnet with 3.x, I would expect you to test this integration > > ;-) > > Gilles, > > I'm trying to test xenomai-3 with rtnet. In git, the master branch has nothing > of rtnet, just the "next" branch. > > Should I use this branch to test it? Yes. -- Gilles. |
From: Leopold Palomo-A. <le...@al...> - 2015-01-21 07:52:12
|
El Dimarts, 20 de gener de 2015, a les 08:26:29, Gilles Chanteperdrix va escriure: > > No idea, really, I am only interested in 3.x, 2.x series will no > longer evolve now. And again, in 3.x, rtnet is integrated into > xenomai, so much easier to compile. And since you were the one to > ask for rtnet with 3.x, I would expect you to test this integration > ;-) Gilles, I'm trying to test xenomai-3 with rtnet. In git, the master branch has nothing of rtnet, just the "next" branch. Should I use this branch to test it? Thanks, Leopold -- -- Linux User 152692 GPG: 05F4A7A949A2D9AA Catalonia ------------------------------------- A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? |
From: Jeff W. <jef...@nt...> - 2015-01-20 16:51:07
|
On 01/20/2015 02:08 AM, Gilles Chanteperdrix wrote: > Xenomai 3.x has the debian directory, with contents equivalent to > the one of 2.x. It may not work, but contributions are welcome. For what it's worth, I built deb packages for Xenomai 3.x using my usual procedure, and did not run into any trouble. I don't remember making any changes to the debian directory, but I could be mistaken. -Jeff |
From: Leopold Palomo-A. <le...@al...> - 2015-01-20 15:26:28
|
El Dimarts, 20 de gener de 2015, a les 08:57:30, Leopold Palomo-Avellaneda va escriure: > > Yes, I know, that but I tried and I had not any compilation issue. The no > important thing was that I disable all rtdm, not important that all ;-) > > I will try to compile with the latest git. Just to summarize: - I have compiled with gcc-4.9 (debian jessie) xenomai with latest git (ok) - I have patched 3.16.0 with adeos patch (ok) and xenomai (ok) - I have compiled rtnet. Two changes: Mariusz Janiak patch and remove __DATE__ __TIME__ macros - I have run my soem rt version and it has worked :-) At least my motor is moving ... I know that I have to check Xenomai-3 ... but, what about to release a xenomai-2.6.5 and rtnet-0.9.14 with the latest git, or something similar? Regards, Leopold -- -- Linux User 152692 GPG: 05F4A7A949A2D9AA Catalonia ------------------------------------- A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? |
From: Gilles C. <gil...@xe...> - 2015-01-20 11:11:08
|
On Tue, Jan 20, 2015 at 11:54:20AM +0100, Leopold Palomo-Avellaneda wrote: > El Dimarts, 20 de gener de 2015, a les 11:52:24, Gilles Chanteperdrix va > escriure: > > On Tue, Jan 20, 2015 at 11:49:52AM +0100, Leopold Palomo-Avellaneda wrote: > > > El Dimarts, 20 de gener de 2015, a les 08:22:28, Leopold Palomo-Avellaneda > > > va> > > > escriure: > > > > > That is strange, because without this commit: > > > > > https://git.xenomai.org/xenomai-2.6.git/commit/?id=d7f7e99ea19eb0dc13b > > > > > 1e02 > > > > > e6 33ec53ac9b89475 > > > > > > > > > > include/rtdm/rtdm_driver.h references a macro which no longer exists > > > > > in Linux 3.16. > > > > > > > > > > So, maybe you could compile Xenomai because you did not enable any > > > > > builtin RTDM driver, but you are certainly not going to be able to > > > > > compile RTnet. > > > > > > > > Ok, it has sense now. Probably I did some mistake and I didn't enable > > > > some > > > > driver. I remember that I disable some things. > > > > > > I correct myself, I had this configuration > > > > > > CONFIG_XENO_SKIN_RTDM=y > > > CONFIG_XENO_OPT_RTDM_PERIOD=0 > > > CONFIG_XENO_OPT_RTDM_FILDES=512 > > > CONFIG_XENO_OPT_RTDM_SELECT=y > > > > > > > > > I don't know if it has some relation with include/rtdm/rtdm_driver.h. > > > > No, it does not, this driver is used by drivers (such as rtnet), > > probably not for the skin implementation. > > then, do you remember which option? > > OTOH, xenomai3 works with 3.16? As I said here: https://xenomai.org/pipermail/xenomai/2014-December/032750.html RTnet was tested with the few boards I have with Xenomai 3 on Linux 3.16 There is already a known issue with the rt_ipv4 module refusing to unload, this should not prevent people from trying rtnet though. RTnet split in modules will probably be changed late anyway, as it makes things hard for integrating the modules in the kernel. -- Gilles. |
From: Leopold Palomo-A. <le...@al...> - 2015-01-20 10:54:29
|
El Dimarts, 20 de gener de 2015, a les 11:52:24, Gilles Chanteperdrix va escriure: > On Tue, Jan 20, 2015 at 11:49:52AM +0100, Leopold Palomo-Avellaneda wrote: > > El Dimarts, 20 de gener de 2015, a les 08:22:28, Leopold Palomo-Avellaneda > > va> > > escriure: > > > > That is strange, because without this commit: > > > > https://git.xenomai.org/xenomai-2.6.git/commit/?id=d7f7e99ea19eb0dc13b > > > > 1e02 > > > > e6 33ec53ac9b89475 > > > > > > > > include/rtdm/rtdm_driver.h references a macro which no longer exists > > > > in Linux 3.16. > > > > > > > > So, maybe you could compile Xenomai because you did not enable any > > > > builtin RTDM driver, but you are certainly not going to be able to > > > > compile RTnet. > > > > > > Ok, it has sense now. Probably I did some mistake and I didn't enable > > > some > > > driver. I remember that I disable some things. > > > > I correct myself, I had this configuration > > > > CONFIG_XENO_SKIN_RTDM=y > > CONFIG_XENO_OPT_RTDM_PERIOD=0 > > CONFIG_XENO_OPT_RTDM_FILDES=512 > > CONFIG_XENO_OPT_RTDM_SELECT=y > > > > > > I don't know if it has some relation with include/rtdm/rtdm_driver.h. > > No, it does not, this driver is used by drivers (such as rtnet), > probably not for the skin implementation. then, do you remember which option? OTOH, xenomai3 works with 3.16? -- -- Linux User 152692 GPG: 05F4A7A949A2D9AA Catalonia ------------------------------------- A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? |
From: Gilles C. <gil...@xe...> - 2015-01-20 10:52:35
|
On Tue, Jan 20, 2015 at 11:49:52AM +0100, Leopold Palomo-Avellaneda wrote: > El Dimarts, 20 de gener de 2015, a les 08:22:28, Leopold Palomo-Avellaneda va > escriure: > > > > > > That is strange, because without this commit: > > > https://git.xenomai.org/xenomai-2.6.git/commit/?id=d7f7e99ea19eb0dc13b1e02 > > > e6 33ec53ac9b89475 > > > > > > include/rtdm/rtdm_driver.h references a macro which no longer exists > > > in Linux 3.16. > > > > > > So, maybe you could compile Xenomai because you did not enable any > > > builtin RTDM driver, but you are certainly not going to be able to > > > compile RTnet. > > > > Ok, it has sense now. Probably I did some mistake and I didn't enable some > > driver. I remember that I disable some things. > > I correct myself, I had this configuration > > CONFIG_XENO_SKIN_RTDM=y > CONFIG_XENO_OPT_RTDM_PERIOD=0 > CONFIG_XENO_OPT_RTDM_FILDES=512 > CONFIG_XENO_OPT_RTDM_SELECT=y > > > I don't know if it has some relation with include/rtdm/rtdm_driver.h. No, it does not, this driver is used by drivers (such as rtnet), probably not for the skin implementation. -- Gilles. |