rtnet-developers Mailing List for RTnet - Real-Time Networking for Linux
Brought to you by:
bet-frogger,
kiszka
You can subscribe to this list here.
2004 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(9) |
Nov
(12) |
Dec
(6) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2005 |
Jan
(13) |
Feb
(1) |
Mar
(2) |
Apr
|
May
(7) |
Jun
(13) |
Jul
(6) |
Aug
(15) |
Sep
(1) |
Oct
(3) |
Nov
(2) |
Dec
(11) |
2006 |
Jan
(2) |
Feb
|
Mar
(13) |
Apr
|
May
(6) |
Jun
(7) |
Jul
(8) |
Aug
(13) |
Sep
(28) |
Oct
(5) |
Nov
(17) |
Dec
(5) |
2007 |
Jan
(2) |
Feb
(18) |
Mar
(22) |
Apr
(5) |
May
(4) |
Jun
(2) |
Jul
(5) |
Aug
(22) |
Sep
|
Oct
(3) |
Nov
(4) |
Dec
(2) |
2008 |
Jan
|
Feb
(3) |
Mar
(15) |
Apr
(7) |
May
(2) |
Jun
(18) |
Jul
(19) |
Aug
(6) |
Sep
(7) |
Oct
(2) |
Nov
(3) |
Dec
(1) |
2009 |
Jan
(8) |
Feb
(2) |
Mar
|
Apr
(3) |
May
(4) |
Jun
(2) |
Jul
(7) |
Aug
|
Sep
(2) |
Oct
(8) |
Nov
(16) |
Dec
(16) |
2010 |
Jan
(5) |
Feb
(2) |
Mar
|
Apr
(16) |
May
|
Jun
|
Jul
(1) |
Aug
(1) |
Sep
(8) |
Oct
(20) |
Nov
|
Dec
(10) |
2011 |
Jan
(15) |
Feb
(33) |
Mar
(5) |
Apr
(8) |
May
(5) |
Jun
|
Jul
|
Aug
(2) |
Sep
(21) |
Oct
(21) |
Nov
(12) |
Dec
(7) |
2012 |
Jan
(2) |
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
(2) |
Sep
(5) |
Oct
|
Nov
|
Dec
(2) |
2013 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(3) |
Jun
(7) |
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
(1) |
2014 |
Jan
|
Feb
(3) |
Mar
(5) |
Apr
|
May
(1) |
Jun
(1) |
Jul
(1) |
Aug
|
Sep
(1) |
Oct
(2) |
Nov
(8) |
Dec
|
2015 |
Jan
|
Feb
|
Mar
(4) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2016 |
Jan
(2) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
2018 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
|
2019 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Nicklas K. <nic...@gm...> - 2019-05-05 10:41:06
|
Do not find any totally appropiate forum but try here since it is the closest. Then running a peridioc real time task I do not want to queue missed dead lines in case it happen, instead only latest triggered should be run. Any idea howto simplest implement? Nicklas Karlsson |
From: Sakshi B. <sak...@gm...> - 2018-11-30 09:13:52
|
Hello, Xenomai version - 3.0.5 Build-in RTnet kernel module - rt_e1000e lspci -knn: * Ethernet Controller [0280] Intel Corporation Device [8086:24fd] (rev 02==78) * *Subsystem: Lenovo Ethernet Connection (2) I219-LM [17aa:310b]** Kernel modules: e1000e* The rt_e1000e is not listed as a module. I suspect this is the reason why RTnet won't start. Any ideas on what needs to be done next? -- Thanks and Regards Sakshi Bansal |
From: <238...@qq...> - 2018-04-25 09:47:55
|
Hi I recently using xenomai3 for UDP communication, but meet some problems when using Rtnet. I can use: sudo rmmod e1000e sudo ./rtnet start sudo ./rtifconfig rteth0 down (without this line the ./rtroute solicit ... command will fail, but the vnic0 also disappears) sudo ./rtifconfig rteth0 up 192.168.1.19 netmask 255.255.255.0 sudo ./rtroute solicit 192.168.1.10 dev rteth0 (or any other outside address) Then I can only connect the outside address using rtping, but I can not connect the outside address with ping or other method, such as connect(). sendto() or recvfrom(). I really don't know why. Then I tried: ifconfig rteth0 up 192.168.1.19 netmask 255.255.255.0, but has no effect. I also tried to add the route table with no effect. And what is the relationship between the rteth0 and vnic0? Hopes for your reply! regards |
From: Jan K. <jan...@we...> - 2016-08-14 19:37:07
|
On 2016-08-13 18:11, Philippe Gerum wrote: > > It is with deep sorrow that I have to inform you that Gilles > Chanteperdrix has passed away on Sunday 7th August. He now rests in the > cemetery of Baillargues, in Southern France. > > You can extend your sympathy to Gilles's family by sending a message to > im-...@xe.... > > Gilles will forever be remembered as a true-hearted man, a brilliant > mind always scratching beneath the surface, looking for elegance in the > driest topics, never jaded from such accomplishment. > > According to Paul Valery, "death is a trick played by the inconceivable > on the conceivable". Gilles's absence is inconceivable to me, I can only > assume that for once, he just got rest from tirelessly helping all of us. > > Repose en paix mon ami, l'éclat de ta mémoire dissipera ces heures sombres. > I'm very sad having to read this. My deepest sympathy to his family and friends. Gilles has been working in these communities for ages, as long as I can remember. From the early RTAI-fusion days, over his POSIX skin, the continuous hard work on ARM over all the years, his FCSE patches, countless enhancements and tricky fixes for both Xenomai series, its infrastructure and much more. As if all the coding wasn't enough, he was also always trying to help people with their questions and problems on the lists, and did thorough reviews of our patches. Tedious work, sometimes repeating, and we cannot thank him enough for all the time he spent on this, with almost infinite endurance. I will specifically keep is valuable contributions to RTnet in memory which finally led to a perfect take-over. He achieved what I was only imagining: the smooth integration of this project into Xenomai. With his amazing expertise, passion for free software, dedication to his work, he was shaping the co-kernel real-time Linux projects enduringly. It's so sad that we lost him. Way too early. Jan |
From: Jan K. <jan...@we...> - 2016-01-13 22:24:29
|
On 2016-01-13 13:16, Nicklas Karlsson wrote: > Documentation say RTAI 3.3 and Linux kernel 2.6.x or better is required while current RTAI version is 5.* and Kernel is 4.* so I want to check if there is any activity in this project? > The original project repository was practically retired for quite a while now. But the caravan moved on, luckily, merged the code into Xenomai 3 and started the overdue renovation there. Yes, that also implies the official discontinuation of RTAI support (probably not a big surprise any more). Jan |
From: Nicklas K. <nic...@gm...> - 2016-01-13 12:17:02
|
Documentation say RTAI 3.3 and Linux kernel 2.6.x or better is required while current RTAI version is 5.* and Kernel is 4.* so I want to check if there is any activity in this project? Nicklas Karlsson |
From: Jan K. <jan...@we...> - 2015-03-05 10:45:20
|
On 2015-03-05 09:17, Wu, Aaron wrote: >> -----Original Message----- >> From: Jan Kiszka [mailto:jan...@we...] >> Sent: 2015年3月5日 16:02 >> To: Wu, Aaron; rtn...@li...; Xenomai >> Subject: Re: status of rtnet >> >> On 2015-03-05 06:51, Wu, Aaron wrote: >>> Hello, >>> >>> >From http://www.rtnet.org I saw the latest release of rtnet is years ago, >> latest kernel support is 3.2. What's the status and roadmap of this project? Any >> plan/schedule to support the newer version of kernel and xenomai? >> >> Fortunately, RTnet has been "adopted" by the Xenomai project (its list is on CC). >> So the next RTnet release will actually be the next major Xenomai release: 3.0. >> You can already pick up the latest 3.0-rc of Xenomai to obtain a more recent >> version than what can be found in the RTnet git. >> >> Jan >> > > Thanks for the good news, in the latest 3.0-rc Xenomai code I saw there is support for kernel 3.16 for ARM, I would expect Rtnet works on 3.16 kernel for ARM too. I would assume the same about the core as well. But you will have to check if your target system's NIC is already supported or if some driver porting is still required. Jan |
From: Wu, A. <Aar...@an...> - 2015-03-05 08:18:29
|
> -----Original Message----- > From: Jan Kiszka [mailto:jan...@we...] > Sent: 2015年3月5日 16:02 > To: Wu, Aaron; rtn...@li...; Xenomai > Subject: Re: status of rtnet > > On 2015-03-05 06:51, Wu, Aaron wrote: > > Hello, > > > >>From http://www.rtnet.org I saw the latest release of rtnet is years ago, > latest kernel support is 3.2. What's the status and roadmap of this project? Any > plan/schedule to support the newer version of kernel and xenomai? > > Fortunately, RTnet has been "adopted" by the Xenomai project (its list is on CC). > So the next RTnet release will actually be the next major Xenomai release: 3.0. > You can already pick up the latest 3.0-rc of Xenomai to obtain a more recent > version than what can be found in the RTnet git. > > Jan > Thanks for the good news, in the latest 3.0-rc Xenomai code I saw there is support for kernel 3.16 for ARM, I would expect Rtnet works on 3.16 kernel for ARM too. Regards, Aaron |
From: Jan K. <jan...@we...> - 2015-03-05 08:01:41
|
On 2015-03-05 06:51, Wu, Aaron wrote: > Hello, > >>From http://www.rtnet.org I saw the latest release of rtnet is years ago, latest kernel support is 3.2. What's the status and roadmap of this project? Any plan/schedule to support the newer version of kernel and xenomai? Fortunately, RTnet has been "adopted" by the Xenomai project (its list is on CC). So the next RTnet release will actually be the next major Xenomai release: 3.0. You can already pick up the latest 3.0-rc of Xenomai to obtain a more recent version than what can be found in the RTnet git. Jan |
From: Wu, A. <Aar...@an...> - 2015-03-05 06:07:51
|
Hello, >From http://www.rtnet.org I saw the latest release of rtnet is years ago, latest kernel support is 3.2. What's the status and roadmap of this project? Any plan/schedule to support the newer version of kernel and xenomai? Thanks and Regards, Aaron |
From: Gilles C. <gil...@xe...> - 2014-11-22 09:17:14
|
On Sat, Nov 22, 2014 at 12:23:49AM +0100, Jeroen Van den Keybus wrote: > > > > > > - the NAPI will be implemented. The NAPI thread will run with the > > priority of the highest priority waiting thread, and will call > > rt_stack_deliver, in order not to increase the RX latency compared > > to the current solution. > > > Would you just poll this thread continuously, at high rate ? I'm asking > because I'd expect the poll method to be called only at moderate rates and > registers may be read or written. You can not really guarantee low RX latency if the NAPI thread does not poll hardware as soon as a packet is received. One thing to understand though is that the NAPI thread will generally be sleeping, and be just woken up on the reception of the first RX irq, at which point RX irq will be disabled at the NIC level, all the received packets will be processed, then the RX irq will be re-enabled at NIC level, and the NAPI thread will go back to sleep. > > Maybe the RTnet drivers contain some modifications for low latency > > like reducing the TX ring length, but I believe putting these > > modifications in the drivers is not a so good idea: > > - it means that the modification is to be made in each driver, and > > needs to be maintained; > > - in the particular case of the TX ring, reducing the number of > > queued packets in hardware is not a really precise way to guarantee > > a bounded latency, because the latency is proportional to the number > > of bytes queued, not on the number of packets, and ethernet packets > > have widely varying sizes. > > > > I fully agree. > > > > Please feel free to send any reaction to this mail. > > > > I've always been wondering if it would be possible to emulate the entire > Linux netdev system in realtime instead, essentially avoiding any driver > modification at all. The plan is to approach this goal. We have to rename the functions to avoid the symbol names clashes, but I would like the conversion to be really automatic. One thing I will not do, however, is spend time trying and emulating the last 20% of the netdev API that would cost me 80% of the development effort. > However, this would also include the handling of the > various task registrations (INIT_WORK) a driver typically does (the e1000e > registers five). But these may still be handled by Linux, perhaps. Actually, I have added the rtdm_schedule_nrt_work() service allowing to trigger workqueues in Linux domain, from Xenomai domain: http://git.xenomai.org/xenomai-gch.git/commit/?h=for-forge&id=ee703d9785f7e242057ef689bc500b965cd75294 > > Though it could very well be a large undertaking, I'm not sure if modifying > the individual drivers (and often the various codepaths for different card > variants inside them) would entail less effort in the end. Well, part, if not majority of the maintenance work is to get the drivers to follow mainline changes. We need this because it allows supporting new hardware, and in case the mainline changes contain fixes. To make that job easy, we need to modify them as little as possible to integrate into RTnet, because every change we make will have to be carried from one version to the next, and have chance to get broken by the mainline changes. -- Gilles. |
From: Gilles C. <gil...@xe...> - 2014-11-22 08:56:56
|
On Fri, Nov 21, 2014 at 11:08:44PM +0100, Richard Cochran wrote: > On Fri, Nov 21, 2014 at 10:48:39PM +0100, Gilles Chanteperdrix wrote: > > On Fri, Nov 21, 2014 at 10:53:05AM +0100, Richard Cochran wrote: > > > This is the reason that, every time I considered using rtnet, I ended > > > up deciding against it. > > > > Well, on the other hand, picking one driver, and improving it for > > the project which needs it was not an insurmountable task. > > Except when you have a napi driver. Then, although not insurmountable, > it still is a formidable task. (But that is changing, now ;) > > > > this work is *long* overdue! > > > > Well, for it to be overdue, it would have to have been due in the > > first place. And since as far as I know, nobody paid for it and was > > expecting a result, and nobody ever promised anything (well up to > > now, I kind of made the promise, now), I do not really think it was > > due. Or maybe I am just misinterpreting the meaning of overdue. > > I did mean that you or anyone else owed anyone anything. I only meant > to say that it was unfortunate that rtnet has stagnated, especially > considering the wide industry interest in real time Ethernet. If you need a project, and you let it stagnate, then you can not really complain, you are just as responsible as every other user doing the same. > > And for paying the bill, no one wants to pay for preempt_rt either! I did not say no one pays the bill for Xenomai! Just that no one paid for refreshing RTNet. For the record, just speaking for myself, it is quite the contrary. The contribution to RTnet of support for NIC statistics and Xenomai and RTnet support for the select service, to name the most significant patches, was made while I was paid to work with Xenomai and RTnet. Since then, I have been doing my maintainer job mostly as a hobbyist, which BTW, I believe did not result in a dramatic decrease in either the quality or the quantity of my contributions. You can find on this page: http://www.denx.de/en/Software/SoftwareXenomaiProjects some ports of Xenomai to ARM boards for which I earned money (and a little more which are not on the page, Freescale i.MX53, i.MX6Q, i.MX28 and ST SPEAr600). And finally, I have received donations of boards from several companies, for which I thank them, it is really helping me doing the maintainer job. I am not going to list the companies here, because I am not sure all of them want it to be publicly known that they use Xenomai (Xenomai has that kind of users), but I can give the boards list: Cogent Computer CSB637, a custom board based on AT91SAM9260, an Advantech board based on AMD Geode, an AOpen mini-PC based on Intel Core 2 duo, a Calao systems USBA9263, an ISEE IGEPv2, recently an Atmel Xplained board, based on the brand new AT91SAMA5D3, and just yesterday, a mail from a company proposing me an i.MX6Q based board. > > Maybe the next step will be to integrate the support for PTP. In > > that case, I hope we will get your help to do the job. > > Happy to help, if I can. If the drivers can stay close to mainline, > then probably there isn't too much to do. The ptp stack itself does > not need real time guarantees in order to operate. The one thing I can > think of that might be needed is synchronization from the MAC clock to > the xenomai system clock. This is going to be hard. Maybe easier, we could add a posix clock ID, like CLOCK_PTP, to have access to that clock from primary mode. > > Also, regarding rtnet, the i210 is an inexpensive card that allows > transmission scheduling at given time. That might be something to take > advantage of. Ok, thanks, will look into it. Regards. -- Gilles. |
From: Gilles C. <gil...@xe...> - 2014-11-21 21:48:47
|
On Fri, Nov 21, 2014 at 10:53:05AM +0100, Richard Cochran wrote: > Hi Gilles, > > On Fri, Nov 21, 2014 at 10:08:57AM +0100, Gilles Chanteperdrix wrote: > > The drivers, on the other hand, are a bit more worrying. They are > > based on seriously outdated versions of the corresponding Linux > > drivers, with support for much less hardware, and probably missing > > some bug fixes. So, putting the drivers into a better shape and > > making it easy to track mainline changes will be my first priority. > > This is the reason that, every time I considered using rtnet, I ended > up deciding against it. Well, on the other hand, picking one driver, and improving it for the project which needs it was not an insurmountable task. > > > Please feel free to send any reaction to this mail. > > Good luck, Thanks. > this work is *long* overdue! Well, for it to be overdue, it would have to have been due in the first place. And since as far as I know, nobody paid for it and was expecting a result, and nobody ever promised anything (well up to now, I kind of made the promise, now), I do not really think it was due. Or maybe I am just misinterpreting the meaning of overdue. Anyway, to make things perfectly clear on that subject, I am not doing this because I feel the Xenomai project owes it to anyone, only because I like the idea of working on that project and that it may be useful for a lot of Xenomai dual-kernel applications. Maybe the next step will be to integrate the support for PTP. In that case, I hope we will get your help to do the job. Regards. -- Gilles. |
From: Gilles C. <gil...@xe...> - 2014-11-21 14:19:31
|
On Fri, Nov 21, 2014 at 12:22:18PM +0100, Jan Kiszka wrote: > On 2014-11-21 12:10, Gilles Chanteperdrix wrote: > > On Fri, Nov 21, 2014 at 11:32:30AM +0100, Jan Kiszka wrote: > >> On 2014-11-21 10:08, Gilles Chanteperdrix wrote: > >>> Hi, > >>> > >>> as some of you may have seen, I have sent the pull request to > >>> Philippe for the integration of RTnet in Xenomai 3, those of you who > >>> want will be able to test it when Xenomai 3 next release candidate > >>> is released. What will be in that release candidate is what was in > >>> RTnet git, patched up to adapt it to the Linux and Xenomai API > >>> changes that broke its compilation, and to add the bits and pieces > >>> to be able to run some tests on the hardware I have (namely, the > >>> 8139too, r8169, at91_ether and macb drivers). > >> > >> For x86, support for e1000e and possibly also igb will be very helpful. > >> Those NICs dominate the market now, specifically due to their on-chip / > >> on-board presence. I think those two drives are in better shape than the > >> legacy ones. > > > > When compiling Xenomai 3 with RTnet on x86 (32 and 64), I enabled > > all the PCI drivers. So, they all compile as far as I know. I have > > not tested them of course, but since the rtnet stack has not changed > > (yet), they should continue to work if they were in a working state. > > Ah, ok, perfect. > > > > > > >>> - the NAPI will be implemented. The NAPI thread will run with the > >>> priority of the highest priority waiting thread, and will call > >>> rt_stack_deliver, in order not to increase the RX latency compared > >>> to the current solution. This will make porting recent drivers easy > >>> and has the additional advantage of irq handlers not creating large > >>> irq masking sections like in the current design, which even borders > >>> priority inversion if the bulk of the received packets is for RTmac > >>> vnics or rtnetproxy. > >> > >> Will be an interesting feature. However, whenever you share a link for > >> RT and non-RT packets, you do have an unavoidable prio-inversion risk. > >> The way to mitigate this is non-RT traffic control. > > > > This can only made on the sending side (which the solution I propose > > for tx queuing should somewhat achieve, BTW). On the receive side, > > the best we can do is get the NAPI thread to inherit the priority of > > the highest priority waiter, and reschedule as soon as it delivers a > > packet to a thread. So, the NAPI thread should not delay high > > priority tasks not currently waiting for a packet if there is no > > higher priority thread waiting for a packet. > > > >> > >>> > >>> Maybe the RTnet drivers contain some modifications for low latency > >>> like reducing the TX ring length, but I believe putting these > >>> modifications in the drivers is not a so good idea: > >> > >> The key modifications that were needed for drivers so far are: > >> - TX/RX time stamping support > >> - disabling of IRQ coalescing features for low-latency signaling > >> - support for pre-mapping rings (to avoid triggering IOMMU paths > >> during runtime) > > > > Ok, thanks. Could you point me at a drivers which have these > > modifications? Particularly the third one, because I believe > > mainline has RX/TX time stamping as well, and the NAPI should handle > > the second one. > > Regarding time stamping: yes, mainline may have this now. You just need > to check when it happens. The original philosophy was to have that as > close to triggering the TX / receiving an RX event as feasible. > > Regarding IRQ coalescing: This is a hardware feature that aims at > optimizing throughput and lowering CPU load. As such, it works against > the goal of lowering individual event latencies. However, maybe such > things are controllable in standard drivers today, just not in a > consistent way. If you mean RX irq coalescing, I guess NAPI is just the same thing done in software. For TX, I realized recently that the "TX complete" irq, was kind of bad for performances, this results in way to many interrupts when trying and generating traffic at full bandwidth. Especially since we are not that much in a hurry for reclaiming the TX packets memory, this does not impact latency visible to application, so coalescing TX irq is desirable as well. But this all seem to be doable in software. I will check that. > And regarding premapping: Just look that rt_igb or rt_e1000e. See e.g. > c05d7bbfba. This change is mandatory for RT, at least for dual-domain > setups. Ok, I will have a look, thanks. -- Gilles. |
From: Jan K. <jan...@we...> - 2014-11-21 11:22:30
|
On 2014-11-21 12:10, Gilles Chanteperdrix wrote: > On Fri, Nov 21, 2014 at 11:32:30AM +0100, Jan Kiszka wrote: >> On 2014-11-21 10:08, Gilles Chanteperdrix wrote: >>> Hi, >>> >>> as some of you may have seen, I have sent the pull request to >>> Philippe for the integration of RTnet in Xenomai 3, those of you who >>> want will be able to test it when Xenomai 3 next release candidate >>> is released. What will be in that release candidate is what was in >>> RTnet git, patched up to adapt it to the Linux and Xenomai API >>> changes that broke its compilation, and to add the bits and pieces >>> to be able to run some tests on the hardware I have (namely, the >>> 8139too, r8169, at91_ether and macb drivers). >> >> For x86, support for e1000e and possibly also igb will be very helpful. >> Those NICs dominate the market now, specifically due to their on-chip / >> on-board presence. I think those two drives are in better shape than the >> legacy ones. > > When compiling Xenomai 3 with RTnet on x86 (32 and 64), I enabled > all the PCI drivers. So, they all compile as far as I know. I have > not tested them of course, but since the rtnet stack has not changed > (yet), they should continue to work if they were in a working state. Ah, ok, perfect. > > >>> - the NAPI will be implemented. The NAPI thread will run with the >>> priority of the highest priority waiting thread, and will call >>> rt_stack_deliver, in order not to increase the RX latency compared >>> to the current solution. This will make porting recent drivers easy >>> and has the additional advantage of irq handlers not creating large >>> irq masking sections like in the current design, which even borders >>> priority inversion if the bulk of the received packets is for RTmac >>> vnics or rtnetproxy. >> >> Will be an interesting feature. However, whenever you share a link for >> RT and non-RT packets, you do have an unavoidable prio-inversion risk. >> The way to mitigate this is non-RT traffic control. > > This can only made on the sending side (which the solution I propose > for tx queuing should somewhat achieve, BTW). On the receive side, > the best we can do is get the NAPI thread to inherit the priority of > the highest priority waiter, and reschedule as soon as it delivers a > packet to a thread. So, the NAPI thread should not delay high > priority tasks not currently waiting for a packet if there is no > higher priority thread waiting for a packet. > >> >>> >>> Maybe the RTnet drivers contain some modifications for low latency >>> like reducing the TX ring length, but I believe putting these >>> modifications in the drivers is not a so good idea: >> >> The key modifications that were needed for drivers so far are: >> - TX/RX time stamping support >> - disabling of IRQ coalescing features for low-latency signaling >> - support for pre-mapping rings (to avoid triggering IOMMU paths >> during runtime) > > Ok, thanks. Could you point me at a drivers which have these > modifications? Particularly the third one, because I believe > mainline has RX/TX time stamping as well, and the NAPI should handle > the second one. Regarding time stamping: yes, mainline may have this now. You just need to check when it happens. The original philosophy was to have that as close to triggering the TX / receiving an RX event as feasible. Regarding IRQ coalescing: This is a hardware feature that aims at optimizing throughput and lowering CPU load. As such, it works against the goal of lowering individual event latencies. However, maybe such things are controllable in standard drivers today, just not in a consistent way. And regarding premapping: Just look that rt_igb or rt_e1000e. See e.g. c05d7bbfba. This change is mandatory for RT, at least for dual-domain setups. Jan |
From: Gilles C. <gil...@xe...> - 2014-11-21 11:10:26
|
On Fri, Nov 21, 2014 at 11:32:30AM +0100, Jan Kiszka wrote: > On 2014-11-21 10:08, Gilles Chanteperdrix wrote: > > Hi, > > > > as some of you may have seen, I have sent the pull request to > > Philippe for the integration of RTnet in Xenomai 3, those of you who > > want will be able to test it when Xenomai 3 next release candidate > > is released. What will be in that release candidate is what was in > > RTnet git, patched up to adapt it to the Linux and Xenomai API > > changes that broke its compilation, and to add the bits and pieces > > to be able to run some tests on the hardware I have (namely, the > > 8139too, r8169, at91_ether and macb drivers). > > For x86, support for e1000e and possibly also igb will be very helpful. > Those NICs dominate the market now, specifically due to their on-chip / > on-board presence. I think those two drives are in better shape than the > legacy ones. When compiling Xenomai 3 with RTnet on x86 (32 and 64), I enabled all the PCI drivers. So, they all compile as far as I know. I have not tested them of course, but since the rtnet stack has not changed (yet), they should continue to work if they were in a working state. > > - the NAPI will be implemented. The NAPI thread will run with the > > priority of the highest priority waiting thread, and will call > > rt_stack_deliver, in order not to increase the RX latency compared > > to the current solution. This will make porting recent drivers easy > > and has the additional advantage of irq handlers not creating large > > irq masking sections like in the current design, which even borders > > priority inversion if the bulk of the received packets is for RTmac > > vnics or rtnetproxy. > > Will be an interesting feature. However, whenever you share a link for > RT and non-RT packets, you do have an unavoidable prio-inversion risk. > The way to mitigate this is non-RT traffic control. This can only made on the sending side (which the solution I propose for tx queuing should somewhat achieve, BTW). On the receive side, the best we can do is get the NAPI thread to inherit the priority of the highest priority waiter, and reschedule as soon as it delivers a packet to a thread. So, the NAPI thread should not delay high priority tasks not currently waiting for a packet if there is no higher priority thread waiting for a packet. > > > > > Maybe the RTnet drivers contain some modifications for low latency > > like reducing the TX ring length, but I believe putting these > > modifications in the drivers is not a so good idea: > > The key modifications that were needed for drivers so far are: > - TX/RX time stamping support > - disabling of IRQ coalescing features for low-latency signaling > - support for pre-mapping rings (to avoid triggering IOMMU paths > during runtime) Ok, thanks. Could you point me at a drivers which have these modifications? Particularly the third one, because I believe mainline has RX/TX time stamping as well, and the NAPI should handle the second one. > > > - it means that the modification is to be made in each driver, and > > needs to be maintained; > > - in the particular case of the TX ring, reducing the number of > > queued packets in hardware is not a really precise way to guarantee > > a bounded latency, because the latency is proportional to the number > > of bytes queued, not on the number of packets, and ethernet packets > > have widely varying sizes. > > > > So, I propose to try and implement these modifications in the rtdev > > stack. For the case of the TX ring, implementing a TX queue which > > keeps track of how much time are worth the number of bytes currently > > queued in hardware (including preamble and inter packets gap) and > > stop queuing when this value reaches a configurable threshold (the > > maximum TX latency), and restart the queue when this value reaches > > the interrupt latency. The queue will be ordered by sender priority, > > so that when a high priority thread queues a packet, the packet will > > never take more than the threshold to reach the wire, even if a low > > priority or the RTmac vnic drivers or rtnetproxy are using the full > > bandwidth (which will remain possible if the threshold is higher > > than the current average irq latency). > > > > Please feel free to send any reaction to this mail. > > Thanks for picking up this task, it is very welcome and should help to > keep this project alive! I ran out of time to take care of it, as people > surely noticed. But it was always my plan as well to hand this over to > the stronger Xenomai community when the code is in acceptable state. > It's great to see this happening now! Thanks, as you know I have used RTnet a long time ago on an (ARM IXP465 based) ISP mixed IPBX/DSL internet gateway when working for this ISP, and I always wanted to contribute back the ideas I had implemented or could not even implement at the time. -- Gilles. |
From: Jan K. <jan...@we...> - 2014-11-21 10:32:44
|
On 2014-11-21 10:08, Gilles Chanteperdrix wrote: > Hi, > > as some of you may have seen, I have sent the pull request to > Philippe for the integration of RTnet in Xenomai 3, those of you who > want will be able to test it when Xenomai 3 next release candidate > is released. What will be in that release candidate is what was in > RTnet git, patched up to adapt it to the Linux and Xenomai API > changes that broke its compilation, and to add the bits and pieces > to be able to run some tests on the hardware I have (namely, the > 8139too, r8169, at91_ether and macb drivers). For x86, support for e1000e and possibly also igb will be very helpful. Those NICs dominate the market now, specifically due to their on-chip / on-board presence. I think those two drives are in better shape than the legacy ones. > > Doing that job, I have found a few things to fix or to do > differently, and am now able to say how I would like to do it. This > mail is cross-posted on the RTnet mailing list, because I believe it > somewhat concerns RTnet users and developers. > > We can divide RTnet into three parts: > - the tools > - the stack > - the drivers > > The tools are in good shape, I do not see any reason to fix them, > except maybe for the rtcfg stuff where an ioctl uses filp_open in > kernel-space which I find a bit useless, but this is not important, > and can wait. > > The stack is not in bad shape either. The code needs a bit of > refreshing, for instance using Linux list and hash lists instead of > open coding linked list. But this will not cause any API change, so > can wait too. > > The drivers, on the other hand, are a bit more worrying. They are > based on seriously outdated versions of the corresponding Linux > drivers, with support for much less hardware, and probably missing > some bug fixes. So, putting the drivers into a better shape and > making it easy to track mainline changes will be my first priority. > > With the 3 drivers I had to adapt, I tested the two possible > approach to updating a driver. For r8169 I hand picked in Linux > driver what was needed to support the chip I have (a 8136) and > adapted it to the code difference between the two versions of the > driver. For at91_ether and macb drivers, I restarted from the > current state of the mainline Linux. The second approach is easier > and more satisfying than the first, because at least you can get all > the mainline fixes, but to my taste, not easy enough. > > I believe the first order of business is to change the rtdev API so > that this port is easy, and in fact, if possible has a first > automated step. So, I intend to change rtdm and rtdev API to reach > this goal: > - rt_stack_connect, rt_rtdev_connect, rt_stack_mark will be removed > and replaced with mechanisms integrated in the rtdev API > - rtdm_irq_request/rtdm_irq_free will be modified to have almost the > same interface as request_irq, in particular removing the need for a > driver to provide the storage for the rtdm_irq_t handles, which will > then become unneeded. This makes life easier for drivers which > register multiple irq handlers. > - rtdm_devm_irq_request or rtdev_irq_request will be introduced with > a behaviour similar to devm_request_irq, that is automatic > unregistration of the irqs handlers at device destruction. Because > automatically adding the missing calls to rtdm_irq_free to a code > using devm_request_irq is hard. Sounds good. > - the NAPI will be implemented. The NAPI thread will run with the > priority of the highest priority waiting thread, and will call > rt_stack_deliver, in order not to increase the RX latency compared > to the current solution. This will make porting recent drivers easy > and has the additional advantage of irq handlers not creating large > irq masking sections like in the current design, which even borders > priority inversion if the bulk of the received packets is for RTmac > vnics or rtnetproxy. Will be an interesting feature. However, whenever you share a link for RT and non-RT packets, you do have an unavoidable prio-inversion risk. The way to mitigate this is non-RT traffic control. > > Maybe the RTnet drivers contain some modifications for low latency > like reducing the TX ring length, but I believe putting these > modifications in the drivers is not a so good idea: The key modifications that were needed for drivers so far are: - TX/RX time stamping support - disabling of IRQ coalescing features for low-latency signaling - support for pre-mapping rings (to avoid triggering IOMMU paths during runtime) > - it means that the modification is to be made in each driver, and > needs to be maintained; > - in the particular case of the TX ring, reducing the number of > queued packets in hardware is not a really precise way to guarantee > a bounded latency, because the latency is proportional to the number > of bytes queued, not on the number of packets, and ethernet packets > have widely varying sizes. > > So, I propose to try and implement these modifications in the rtdev > stack. For the case of the TX ring, implementing a TX queue which > keeps track of how much time are worth the number of bytes currently > queued in hardware (including preamble and inter packets gap) and > stop queuing when this value reaches a configurable threshold (the > maximum TX latency), and restart the queue when this value reaches > the interrupt latency. The queue will be ordered by sender priority, > so that when a high priority thread queues a packet, the packet will > never take more than the threshold to reach the wire, even if a low > priority or the RTmac vnic drivers or rtnetproxy are using the full > bandwidth (which will remain possible if the threshold is higher > than the current average irq latency). > > Please feel free to send any reaction to this mail. Thanks for picking up this task, it is very welcome and should help to keep this project alive! I ran out of time to take care of it, as people surely noticed. But it was always my plan as well to hand this over to the stronger Xenomai community when the code is in acceptable state. It's great to see this happening now! Jan |
From: Gilles C. <gil...@xe...> - 2014-11-21 09:09:06
|
Hi, as some of you may have seen, I have sent the pull request to Philippe for the integration of RTnet in Xenomai 3, those of you who want will be able to test it when Xenomai 3 next release candidate is released. What will be in that release candidate is what was in RTnet git, patched up to adapt it to the Linux and Xenomai API changes that broke its compilation, and to add the bits and pieces to be able to run some tests on the hardware I have (namely, the 8139too, r8169, at91_ether and macb drivers). Doing that job, I have found a few things to fix or to do differently, and am now able to say how I would like to do it. This mail is cross-posted on the RTnet mailing list, because I believe it somewhat concerns RTnet users and developers. We can divide RTnet into three parts: - the tools - the stack - the drivers The tools are in good shape, I do not see any reason to fix them, except maybe for the rtcfg stuff where an ioctl uses filp_open in kernel-space which I find a bit useless, but this is not important, and can wait. The stack is not in bad shape either. The code needs a bit of refreshing, for instance using Linux list and hash lists instead of open coding linked list. But this will not cause any API change, so can wait too. The drivers, on the other hand, are a bit more worrying. They are based on seriously outdated versions of the corresponding Linux drivers, with support for much less hardware, and probably missing some bug fixes. So, putting the drivers into a better shape and making it easy to track mainline changes will be my first priority. With the 3 drivers I had to adapt, I tested the two possible approach to updating a driver. For r8169 I hand picked in Linux driver what was needed to support the chip I have (a 8136) and adapted it to the code difference between the two versions of the driver. For at91_ether and macb drivers, I restarted from the current state of the mainline Linux. The second approach is easier and more satisfying than the first, because at least you can get all the mainline fixes, but to my taste, not easy enough. I believe the first order of business is to change the rtdev API so that this port is easy, and in fact, if possible has a first automated step. So, I intend to change rtdm and rtdev API to reach this goal: - rt_stack_connect, rt_rtdev_connect, rt_stack_mark will be removed and replaced with mechanisms integrated in the rtdev API - rtdm_irq_request/rtdm_irq_free will be modified to have almost the same interface as request_irq, in particular removing the need for a driver to provide the storage for the rtdm_irq_t handles, which will then become unneeded. This makes life easier for drivers which register multiple irq handlers. - rtdm_devm_irq_request or rtdev_irq_request will be introduced with a behaviour similar to devm_request_irq, that is automatic unregistration of the irqs handlers at device destruction. Because automatically adding the missing calls to rtdm_irq_free to a code using devm_request_irq is hard. - the NAPI will be implemented. The NAPI thread will run with the priority of the highest priority waiting thread, and will call rt_stack_deliver, in order not to increase the RX latency compared to the current solution. This will make porting recent drivers easy and has the additional advantage of irq handlers not creating large irq masking sections like in the current design, which even borders priority inversion if the bulk of the received packets is for RTmac vnics or rtnetproxy. Maybe the RTnet drivers contain some modifications for low latency like reducing the TX ring length, but I believe putting these modifications in the drivers is not a so good idea: - it means that the modification is to be made in each driver, and needs to be maintained; - in the particular case of the TX ring, reducing the number of queued packets in hardware is not a really precise way to guarantee a bounded latency, because the latency is proportional to the number of bytes queued, not on the number of packets, and ethernet packets have widely varying sizes. So, I propose to try and implement these modifications in the rtdev stack. For the case of the TX ring, implementing a TX queue which keeps track of how much time are worth the number of bytes currently queued in hardware (including preamble and inter packets gap) and stop queuing when this value reaches a configurable threshold (the maximum TX latency), and restart the queue when this value reaches the interrupt latency. The queue will be ordered by sender priority, so that when a high priority thread queues a packet, the packet will never take more than the threshold to reach the wire, even if a low priority or the RTmac vnic drivers or rtnetproxy are using the full bandwidth (which will remain possible if the threshold is higher than the current average irq latency). Please feel free to send any reaction to this mail. Regards. -- Gilles. |
From: David A. <cnc...@gm...> - 2014-10-08 14:57:23
|
Hi all Sorry if this is a newbie error , so please forgive if thats the case , this is my first time compiling rtnet .. i am compiling against debian wheesy and realtime-3.4-9-rtai-686-pae ( RTAI version 3.9.1-unofficial) i have the following errors and would be kind if anyone can point me the correct way to a compile checking dependency style of gcc... gcc3 checking for main in -lncurses... yes checking for RTnet Kconfig file... ./defconfig (default) checking for RT-extension... /usr/realtime-3.4-9-rtai-686-pae (RTAI) checking for RTAI version... 3.9.1-unofficial checking for RTAI config file... /usr/realtime-3.4-9-rtai-686-pae/share/rtai/config-rtai-3.9.1-unofficial /usr/realtime-3.4-9-rtai-686-pae/share/rtai/config-rtai-3.9.1-unofficial: line 50: CONFIG_RTAI_ADDONS_FALSE: command not found /usr/realtime-3.4-9-rtai-686-pae/share/rtai/config-rtai-3.9.1-unofficial: line 51: CONFIG_RTAI_ADDONS_TRUE: command not found /usr/realtime-3.4-9-rtai-686-pae/share/rtai/config-rtai-3.9.1-unofficial: line 52: CONFIG_RTAI_QUIET: command not found /usr/realtime-3.4-9-rtai-686-pae/share/rtai/config-rtai-3.9.1-unofficial: line 53: CONFIG_RTAI_LINUXDIR: command not found /usr/realtime-3.4-9-rtai-686-pae/share/rtai/config-rtai-3.9.1-unofficial: line 54: CONFIG_RTAI_QUIET_FALSE: command not found /usr/realtime-3.4-9-rtai-686-pae/share/rtai/config-rtai-3.9.1-unofficial: line 55: CONFIG_RTAI_QUIET_TRUE: command not found /usr/realtime-3.4-9-rtai-686-pae/share/rtai/config-rtai-3.9.1-unofficial: line 56: CONFIG_RTAI_OLD_FASHIONED_BUILD_FALSE: command not found /usr/realtime-3.4-9-rtai-686-pae/share/rtai/config-rtai-3.9.1-unofficial: line 57: CONFIG_RTAI_OLD_FASHIONED_BUILD_TRUE: command not found /usr/realtime-3.4-9-rtai-686-pae/share/rtai/config-rtai-3.9.1-unofficial: line 58: CONFIG_RTAI_MAINTAINER_PGM_FALSE: command not found /usr/realtime-3.4-9-rtai-686-pae/share/rtai/config-rtai-3.9.1-unofficial: line 59: CONFIG_RTAI_MAINTAINER_PGM_TRUE: command not found /usr/realtime-3.4-9-rtai-686-pae/share/rtai/config-rtai-3.9.1-unofficial: line 60: CONFIG_RTAI_MAINTAINER_PMA_FALSE: command not found /usr/realtime-3.4-9-rtai-686-pae/share/rtai/config-rtai-3.9.1-unofficial: line 61: CONFIG_RTAI_MAINTAINER_PMA_TRUE: command not found /usr/realtime-3.4-9-rtai-686-pae/share/rtai/config-rtai-3.9.1-unofficial: line 62: CONFIG_RTAI_MAINTAINER_FALSE: command not found /usr/realtime-3.4-9-rtai-686-pae/share/rtai/config-rtai-3.9.1-unofficial: line 63: CONFIG_RTAI_MAINTAINER_TRUE: command not found /usr/realtime-3.4-9-rtai-686-pae/share/rtai/config-rtai-3.9.1-unofficial: line 64: CONFIG_RTAI_GUIDE_FALSE: command not found /usr/realtime-3.4-9-rtai-686-pae/share/rtai/config-rtai-3.9.1-unofficial: line 65: CONFIG_RTAI_GUIDE_TRUE: command not found /usr/realtime-3.4-9-rtai-686-pae/share/rtai/config-rtai-3.9.1-unofficial: line 66: CONFIG_RTAI_DOX_DOC_FALSE: command not found /usr/realtime-3.4-9-rtai-686-pae/share/rtai/config-rtai-3.9.1-unofficial: line 67: CONFIG_RTAI_DOX_DOC_TRUE: command not found /usr/realtime-3.4-9-rtai-686-pae/share/rtai/config-rtai-3.9.1-unofficial: line 68: CONFIG_RTAI_MATH_C99_FALSE: command not found /usr/realtime-3.4-9-rtai-686-pae/share/rtai/config-rtai-3.9.1-unofficial: line 69: CONFIG_RTAI_MATH_C99_TRUE: command not found /usr/realtime-3.4-9-rtai-686-pae/share/rtai/config-rtai-3.9.1-unofficial: line 70: CONFIG_RTAI_ADEOS_FALSE: command not found /usr/realtime-3.4-9-rtai-686-pae/share/rtai/config-rtai-3.9.1-unofficial: line 71: CONFIG_RTAI_ADEOS_TRUE: command not found /usr/realtime-3.4-9-rtai-686-pae/share/rtai/config-rtai-3.9.1-unofficial: line 72: CONFIG_RTAI_TESTSUITE_FALSE: command not found /usr/realtime-3.4-9-rtai-686-pae/share/rtai/config-rtai-3.9.1-unofficial: line 73: CONFIG_RTAI_TESTSUITE_TRUE: command not found /usr/realtime-3.4-9-rtai-686-pae/share/rtai/config-rtai-3.9.1-unofficial: line 74: CONFIG_RTAI_MVM_FALSE: command not found /usr/realtime-3.4-9-rtai-686-pae/share/rtai/config-rtai-3.9.1-unofficial: line 75: CONFIG_RTAI_MVM_TRUE: command not found /usr/realtime-3.4-9-rtai-686-pae/share/rtai/config-rtai-3.9.1-unofficial: line 76: CONFIG_RTAI_LAB_FALSE: command not found /usr/realtime-3.4-9-rtai-686-pae/share/rtai/config-rtai-3.9.1-unofficial: line 77: CONFIG_RTAI_LAB_TRUE: command not found /usr/realtime-3.4-9-rtai-686-pae/share/rtai/config-rtai-3.9.1-unofficial: line 78: CONFIG_RTAI_DRIVERS_16550A_FALSE: command not found /usr/realtime-3.4-9-rtai-686-pae/share/rtai/config-rtai-3.9.1-unofficial: line 79: CONFIG_RTAI_DRIVERS_16550A_TRUE: command not found /usr/realtime-3.4-9-rtai-686-pae/share/rtai/config-rtai-3.9.1-unofficial: line 80: CONFIG_RTAI_DRIVERS_SERIAL_FALSE: command not found /usr/realtime-3.4-9-rtai-686-pae/share/rtai/config-rtai-3.9.1-unofficial: line 81: CONFIG_RTAI_DRIVERS_SERIAL_TRUE: command not found /usr/realtime-3.4-9-rtai-686-pae/share/rtai/config-rtai-3.9.1-unofficial: line 82: CONFIG_RTAI_RTDM_FALSE: command not found /usr/realtime-3.4-9-rtai-686-pae/share/rtai/config-rtai-3.9.1-unofficial: line 83: CONFIG_RTAI_RTDM_TRUE: command not found /usr/realtime-3.4-9-rtai-686-pae/share/rtai/config-rtai-3.9.1-unofficial: line 84: CONFIG_RTAI_USE_LINUX_COMEDI_FALSE: command not found /usr/realtime-3.4-9-rtai-686-pae/share/rtai/config-rtai-3.9.1-unofficial: line 85: CONFIG_RTAI_USE_LINUX_COMEDI_TRUE: command not found /usr/realtime-3.4-9-rtai-686-pae/share/rtai/config-rtai-3.9.1-unofficial: line 86: CONFIG_RTAI_COMEDI_LXRT_FALSE: command not found /usr/realtime-3.4-9-rtai-686-pae/share/rtai/config-rtai-3.9.1-unofficial: line 87: CONFIG_RTAI_COMEDI_LXRT_TRUE: command not found /usr/realtime-3.4-9-rtai-686-pae/share/rtai/config-rtai-3.9.1-unofficial: line 88: CONFIG_RTAI_LEDS_BUILTIN_FALSE: command not found /usr/realtime-3.4-9-rtai-686-pae/share/rtai/config-rtai-3.9.1-unofficial: line 89: CONFIG_RTAI_LEDS_BUILTIN_TRUE: command not found /usr/realtime-3.4-9-rtai-686-pae/share/rtai/config-rtai-3.9.1-unofficial: line 90: CONFIG_RTAI_USI_BUILTIN_FALSE: command not found /usr/realtime-3.4-9-rtai-686-pae/share/rtai/config-rtai-3.9.1-unofficial: line 91: CONFIG_RTAI_USI_BUILTIN_TRUE: command not found /usr/realtime-3.4-9-rtai-686-pae/share/rtai/config-rtai-3.9.1-unofficial: line 92: CONFIG_RTAI_TASKLETS_BUILTIN_FALSE: command not found /usr/realtime-3.4-9-rtai-686-pae/share/rtai/config-rtai-3.9.1-unofficial: line 93: CONFIG_RTAI_TASKLETS_BUILTIN_TRUE: command not found /usr/realtime-3.4-9-rtai-686-pae/share/rtai/config-rtai-3.9.1-unofficial: line 94: CONFIG_RTAI_MALLOC_BUILTIN_FALSE: command not found /usr/realtime-3.4-9-rtai-686-pae/share/rtai/config-rtai-3.9.1-unofficial: line 95: CONFIG_RTAI_MALLOC_BUILTIN_TRUE: command not found /usr/realtime-3.4-9-rtai-686-pae/share/rtai/config-rtai-3.9.1-unofficial: line 96: CONFIG_RTAI_SHM_BUILTIN_FALSE: command not found /usr/realtime-3.4-9-rtai-686-pae/share/rtai/config-rtai-3.9.1-unofficial: line 97: CONFIG_RTAI_SHM_BUILTIN_TRUE: command not found /usr/realtime-3.4-9-rtai-686-pae/share/rtai/config-rtai-3.9.1-unofficial: line 98: CONFIG_RTAI_MQ_BUILTIN_FALSE: command not found /usr/realtime-3.4-9-rtai-686-pae/share/rtai/config-rtai-3.9.1-unofficial: line 99: CONFIG_RTAI_MQ_BUILTIN_TRUE: command not found /usr/realtime-3.4-9-rtai-686-pae/share/rtai/config-rtai-3.9.1-unofficial: line 100: CONFIG_RTAI_TBX_BUILTIN_FALSE: command not found /usr/realtime-3.4-9-rtai-686-pae/share/rtai/config-rtai-3.9.1-unofficial: line 101: CONFIG_RTAI_TBX_BUILTIN_TRUE: command not found /usr/realtime-3.4-9-rtai-686-pae/share/rtai/config-rtai-3.9.1-unofficial: line 102: CONFIG_RTAI_MBX_BUILTIN_FALSE: command not found /usr/realtime-3.4-9-rtai-686-pae/share/rtai/config-rtai-3.9.1-unofficial: line 103: CONFIG_RTAI_MBX_BUILTIN_TRUE: command not found /usr/realtime-3.4-9-rtai-686-pae/share/rtai/config-rtai-3.9.1-unofficial: line 104: CONFIG_RTAI_MSG_BUILTIN_FALSE: command not found /usr/realtime-3.4-9-rtai-686-pae/share/rtai/config-rtai-3.9.1-unofficial: line 105: CONFIG_RTAI_MSG_BUILTIN_TRUE: command not found /usr/realtime-3.4-9-rtai-686-pae/share/rtai/config-rtai-3.9.1-unofficial: line 106: CONFIG_RTAI_SEM_BUILTIN_FALSE: command not found /usr/realtime-3.4-9-rtai-686-pae/share/rtai/config-rtai-3.9.1-unofficial: line 107: CONFIG_RTAI_SEM_BUILTIN_TRUE: command not found /usr/realtime-3.4-9-rtai-686-pae/share/rtai/config-rtai-3.9.1-unofficial: line 108: CONFIG_RTAI_NETRPC_BUILTIN_FALSE: command not found /usr/realtime-3.4-9-rtai-686-pae/share/rtai/config-rtai-3.9.1-unofficial: line 109: CONFIG_RTAI_NETRPC_BUILTIN_TRUE: command not found /usr/realtime-3.4-9-rtai-686-pae/share/rtai/config-rtai-3.9.1-unofficial: line 110: CONFIG_RTAI_FIFOS_BUILTIN_FALSE: command not found /usr/realtime-3.4-9-rtai-686-pae/share/rtai/config-rtai-3.9.1-unofficial: line 111: CONFIG_RTAI_FIFOS_BUILTIN_TRUE: command not found /usr/realtime-3.4-9-rtai-686-pae/share/rtai/config-rtai-3.9.1-unofficial: line 112: CONFIG_RTAI_BITS_BUILTIN_FALSE: command not found /usr/realtime-3.4-9-rtai-686-pae/share/rtai/config-rtai-3.9.1-unofficial: line 113: CONFIG_RTAI_BITS_BUILTIN_TRUE: command not found /usr/realtime-3.4-9-rtai-686-pae/share/rtai/config-rtai-3.9.1-unofficial: line 114: CONFIG_RTAI_MATH_BUILTIN_FALSE: command not found /usr/realtime-3.4-9-rtai-686-pae/share/rtai/config-rtai-3.9.1-unofficial: line 115: CONFIG_RTAI_MATH_BUILTIN_TRUE: command not found /usr/realtime-3.4-9-rtai-686-pae/share/rtai/config-rtai-3.9.1-unofficial: line 116: CONFIG_RTAI_LXRT_USE_LINUX_SYSCALL_FALSE: command not found /usr/realtime-3.4-9-rtai-686-pae/share/rtai/config-rtai-3.9.1-unofficial: line 117: CONFIG_RTAI_LXRT_USE_LINUX_SYSCALL_TRUE: command not found /usr/realtime-3.4-9-rtai-686-pae/share/rtai/config-rtai-3.9.1-unofficial: line 118: CONFIG_RTAI_LEDS_FALSE: command not found /usr/realtime-3.4-9-rtai-686-pae/share/rtai/config-rtai-3.9.1-unofficial: line 119: CONFIG_RTAI_LEDS_TRUE: command not found /usr/realtime-3.4-9-rtai-686-pae/share/rtai/config-rtai-3.9.1-unofficial: line 120: CONFIG_RTAI_WD_FALSE: command not found /usr/realtime-3.4-9-rtai-686-pae/share/rtai/config-rtai-3.9.1-unofficial: line 121: CONFIG_RTAI_WD_TRUE: command not found /usr/realtime-3.4-9-rtai-686-pae/share/rtai/config-rtai-3.9.1-unofficial: line 122: CONFIG_RTAI_USI_FALSE: command not found /usr/realtime-3.4-9-rtai-686-pae/share/rtai/config-rtai-3.9.1-unofficial: line 123: CONFIG_RTAI_USI_TRUE: command not found /usr/realtime-3.4-9-rtai-686-pae/share/rtai/config-rtai-3.9.1-unofficial: line 124: CONFIG_RTAI_TASKLETS_FALSE: command not found /usr/realtime-3.4-9-rtai-686-pae/share/rtai/config-rtai-3.9.1-unofficial: line 125: CONFIG_RTAI_TASKLETS_TRUE: command not found /usr/realtime-3.4-9-rtai-686-pae/share/rtai/config-rtai-3.9.1-unofficial: line 126: CONFIG_RTAI_MALLOC_FALSE: command not found /usr/realtime-3.4-9-rtai-686-pae/share/rtai/config-rtai-3.9.1-unofficial: line 127: CONFIG_RTAI_MALLOC_TRUE: command not found /usr/realtime-3.4-9-rtai-686-pae/share/rtai/config-rtai-3.9.1-unofficial: line 128: CONFIG_RTAI_SHM_FALSE: command not found /usr/realtime-3.4-9-rtai-686-pae/share/rtai/config-rtai-3.9.1-unofficial: line 129: CONFIG_RTAI_SHM_TRUE: command not found /usr/realtime-3.4-9-rtai-686-pae/share/rtai/config-rtai-3.9.1-unofficial: line 130: CONFIG_RTAI_MQ_FALSE: command not found /usr/realtime-3.4-9-rtai-686-pae/share/rtai/config-rtai-3.9.1-unofficial: line 131: CONFIG_RTAI_MQ_TRUE: command not found /usr/realtime-3.4-9-rtai-686-pae/share/rtai/config-rtai-3.9.1-unofficial: line 132: CONFIG_RTAI_TBX_FALSE: command not found /usr/realtime-3.4-9-rtai-686-pae/share/rtai/config-rtai-3.9.1-unofficial: line 133: CONFIG_RTAI_TBX_TRUE: command not found /usr/realtime-3.4-9-rtai-686-pae/share/rtai/config-rtai-3.9.1-unofficial: line 134: CONFIG_RTAI_MBX_FALSE: command not found /usr/realtime-3.4-9-rtai-686-pae/share/rtai/config-rtai-3.9.1-unofficial: line 135: CONFIG_RTAI_MBX_TRUE: command not found /usr/realtime-3.4-9-rtai-686-pae/share/rtai/config-rtai-3.9.1-unofficial: line 136: CONFIG_RTAI_MSG_FALSE: command not found /usr/realtime-3.4-9-rtai-686-pae/share/rtai/config-rtai-3.9.1-unofficial: line 137: CONFIG_RTAI_MSG_TRUE: command not found /usr/realtime-3.4-9-rtai-686-pae/share/rtai/config-rtai-3.9.1-unofficial: line 138: CONFIG_RTAI_RT_POLL_ON_STACK_FALSE: command not found /usr/realtime-3.4-9-rtai-686-pae/share/rtai/config-rtai-3.9.1-unofficial: line 139: CONFIG_RTAI_RT_POLL_ON_STACK_TRUE: command not found /usr/realtime-3.4-9-rtai-686-pae/share/rtai/config-rtai-3.9.1-unofficial: line 140: CONFIG_RTAI_RT_POLL_FALSE: command not found /usr/realtime-3.4-9-rtai-686-pae/share/rtai/config-rtai-3.9.1-unofficial: line 141: CONFIG_RTAI_RT_POLL_TRUE: command not found /usr/realtime-3.4-9-rtai-686-pae/share/rtai/config-rtai-3.9.1-unofficial: line 142: CONFIG_RTAI_SEM_FALSE: command not found /usr/realtime-3.4-9-rtai-686-pae/share/rtai/config-rtai-3.9.1-unofficial: line 143: CONFIG_RTAI_SEM_TRUE: command not found /usr/realtime-3.4-9-rtai-686-pae/share/rtai/config-rtai-3.9.1-unofficial: line 144: CONFIG_RTAI_NETRPC_FALSE: command not found /usr/realtime-3.4-9-rtai-686-pae/share/rtai/config-rtai-3.9.1-unofficial: line 145: CONFIG_RTAI_NETRPC_TRUE: command not found /usr/realtime-3.4-9-rtai-686-pae/share/rtai/config-rtai-3.9.1-unofficial: line 146: CONFIG_RTAI_FIFOS_FALSE: command not found /usr/realtime-3.4-9-rtai-686-pae/share/rtai/config-rtai-3.9.1-unofficial: line 147: CONFIG_RTAI_FIFOS_TRUE: command not found /usr/realtime-3.4-9-rtai-686-pae/share/rtai/config-rtai-3.9.1-unofficial: line 148: CONFIG_RTAI_BITS_FALSE: command not found /usr/realtime-3.4-9-rtai-686-pae/share/rtai/config-rtai-3.9.1-unofficial: line 149: CONFIG_RTAI_BITS_TRUE: command not found /usr/realtime-3.4-9-rtai-686-pae/share/rtai/config-rtai-3.9.1-unofficial: line 150: CONFIG_RTAI_MATH_FALSE: command not found /usr/realtime-3.4-9-rtai-686-pae/share/rtai/config-rtai-3.9.1-unofficial: line 151: CONFIG_RTAI_MATH_TRUE: command not found /usr/realtime-3.4-9-rtai-686-pae/share/rtai/config-rtai-3.9.1-unofficial: line 152: CONFIG_RTAI_TRACE_FALSE: command not found /usr/realtime-3.4-9-rtai-686-pae/share/rtai/config-rtai-3.9.1-unofficial: line 153: CONFIG_RTAI_TRACE_TRUE: command not found checking for Linux source tree... /usr/src/linux-headers-3.4-9-rtai-686-pae (kernel 3.4.55) checking for RTDM skin... configure: error: *** Please enable RTDM skin i am using the following command line configure ./configure --enable-8139 --with-rtext=/usr/realtime-3.4-9-rtai-686-pae/ regards and thanks Dave |
From: Vasudev K. <kam...@gm...> - 2014-10-08 09:03:54
|
On Tue, Sep 23, 2014 at 3:09 PM, Vasudev Kamath <kam...@gm...> wrote: > make[3]: Entering directory > `/home/vasudev/Documents/Sources/KernelStuff/linux-3.14.18' > CC [M] /home/vasudev/Documents/Sources/KernelStuff/rtnet/stack/iovec.o > CC [M] /home/vasudev/Documents/Sources/KernelStuff/rtnet/stack/rtdev.o > CC [M] /home/vasudev/Documents/Sources/KernelStuff/rtnet/stack/rtdev_mgr.o > CC [M] /home/vasudev/Documents/Sources/KernelStuff/rtnet/stack/rtnet_chrdev.o > CC [M] /home/vasudev/Documents/Sources/KernelStuff/rtnet/stack/rtnet_module.o > /home/vasudev/Documents/Sources/KernelStuff/rtnet/stack/rtnet_module.c: > In function _rtnet_proc_register_: > /home/vasudev/Documents/Sources/KernelStuff/rtnet/stack/rtnet_module.c:212:5: > error: implicit declaration of function _create_proc_entry_ > [-Werror=implicit-function-declaration] > /home/vasudev/Documents/Sources/KernelStuff/rtnet/stack/rtnet_module.c:212:21: > warning: assignment makes pointer from integer without a cast [enabled > by default] > /home/vasudev/Documents/Sources/KernelStuff/rtnet/stack/rtnet_module.c:216:16: > warning: assignment makes pointer from integer without a cast [enabled > by default] > /home/vasudev/Documents/Sources/KernelStuff/rtnet/stack/rtnet_module.c:220:15: > error: dereferencing pointer to incomplete type > /home/vasudev/Documents/Sources/KernelStuff/rtnet/stack/rtnet_module.c:222:16: > warning: assignment makes pointer from integer without a cast [enabled > by default] > /home/vasudev/Documents/Sources/KernelStuff/rtnet/stack/rtnet_module.c:226:15: > error: dereferencing pointer to incomplete type > /home/vasudev/Documents/Sources/KernelStuff/rtnet/stack/rtnet_module.c:228:16: > warning: assignment makes pointer from integer without a cast [enabled > by default] > /home/vasudev/Documents/Sources/KernelStuff/rtnet/stack/rtnet_module.c:232:15: > error: dereferencing pointer to incomplete type > /home/vasudev/Documents/Sources/KernelStuff/rtnet/stack/rtnet_module.c:234:16: > warning: assignment makes pointer from integer without a cast [enabled > by default] > /home/vasudev/Documents/Sources/KernelStuff/rtnet/stack/rtnet_module.c:237:15: > error: dereferencing pointer to incomplete type > cc1: some warnings being treated as errors > make[4]: *** [/home/vasudev/Documents/Sources/KernelStuff/rtnet/stack/rtnet_module.o] > Error 1 > make[3]: *** [_module_/home/vasudev/Documents/Sources/KernelStuff/rtnet/stack] > Error 2 > make[3]: Leaving directory > `/home/vasudev/Documents/Sources/KernelStuff/linux-3.14.18' > make[2]: *** [all-local.ko] Error 2 > make[2]: Leaving directory > `/home/vasudev/Documents/Sources/KernelStuff/rtnet/stack' > make[1]: *** [all-recursive] Error 1 > make[1]: Leaving directory > `/home/vasudev/Documents/Sources/KernelStuff/rtnet/stack' > make: *** [all-recursive] Error 1 > OK I took a dig at this and managed to fix these errors. I'm attaching my patch with this mail. This patch is compiled against Linux Kernel 3.14.18 patched with Xenomai 2.6.3 git snapshot taken on September 21 2014. I'm doing this for the first time so please let me know if I made any mistakes. Also this patch works on top of patch sent by Anders Blomdell [1]. I've just read through changes made by Andres and did the changes to tcp udp and af_inet files after reading through new function and macros in kernel 3.14. (Hint: Jan, Anders I would be happy to get your review for the patch) On a second note I didn't get chance to test this patch as I've not yet compiled the kernel to the device where I'm supposed to use this. I will update the working status once I get it running on my device. [1] https://www.mail-archive.com/rtn...@li.../msg00654.html Warm Regards -- Vasudev Kamath http://copyninja.info copyninja@{frndk.de|vasudev.homelinux.net} |
From: Vasudev K. <kam...@gm...> - 2014-09-23 09:40:19
|
Hello, I'm trying to compile rtnet with linux kernel vanilla from kernel.org version 3.14.18 patched with ipipe-core-3.14.17-x86-2.patch and xenomai 2.6 git snapshot. Compile fails with following error. make[3]: Entering directory `/home/vasudev/Documents/Sources/KernelStuff/linux-3.14.18' CC [M] /home/vasudev/Documents/Sources/KernelStuff/rtnet/stack/iovec.o CC [M] /home/vasudev/Documents/Sources/KernelStuff/rtnet/stack/rtdev.o CC [M] /home/vasudev/Documents/Sources/KernelStuff/rtnet/stack/rtdev_mgr.o CC [M] /home/vasudev/Documents/Sources/KernelStuff/rtnet/stack/rtnet_chrdev.o CC [M] /home/vasudev/Documents/Sources/KernelStuff/rtnet/stack/rtnet_module.o /home/vasudev/Documents/Sources/KernelStuff/rtnet/stack/rtnet_module.c: In function _rtnet_proc_register_: /home/vasudev/Documents/Sources/KernelStuff/rtnet/stack/rtnet_module.c:212:5: error: implicit declaration of function _create_proc_entry_ [-Werror=implicit-function-declaration] /home/vasudev/Documents/Sources/KernelStuff/rtnet/stack/rtnet_module.c:212:21: warning: assignment makes pointer from integer without a cast [enabled by default] /home/vasudev/Documents/Sources/KernelStuff/rtnet/stack/rtnet_module.c:216:16: warning: assignment makes pointer from integer without a cast [enabled by default] /home/vasudev/Documents/Sources/KernelStuff/rtnet/stack/rtnet_module.c:220:15: error: dereferencing pointer to incomplete type /home/vasudev/Documents/Sources/KernelStuff/rtnet/stack/rtnet_module.c:222:16: warning: assignment makes pointer from integer without a cast [enabled by default] /home/vasudev/Documents/Sources/KernelStuff/rtnet/stack/rtnet_module.c:226:15: error: dereferencing pointer to incomplete type /home/vasudev/Documents/Sources/KernelStuff/rtnet/stack/rtnet_module.c:228:16: warning: assignment makes pointer from integer without a cast [enabled by default] /home/vasudev/Documents/Sources/KernelStuff/rtnet/stack/rtnet_module.c:232:15: error: dereferencing pointer to incomplete type /home/vasudev/Documents/Sources/KernelStuff/rtnet/stack/rtnet_module.c:234:16: warning: assignment makes pointer from integer without a cast [enabled by default] /home/vasudev/Documents/Sources/KernelStuff/rtnet/stack/rtnet_module.c:237:15: error: dereferencing pointer to incomplete type cc1: some warnings being treated as errors make[4]: *** [/home/vasudev/Documents/Sources/KernelStuff/rtnet/stack/rtnet_module.o] Error 1 make[3]: *** [_module_/home/vasudev/Documents/Sources/KernelStuff/rtnet/stack] Error 2 make[3]: Leaving directory `/home/vasudev/Documents/Sources/KernelStuff/linux-3.14.18' make[2]: *** [all-local.ko] Error 2 make[2]: Leaving directory `/home/vasudev/Documents/Sources/KernelStuff/rtnet/stack' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/vasudev/Documents/Sources/KernelStuff/rtnet/stack' make: *** [all-recursive] Error 1 While searching I found following mailing list thread which contains partial patch [1], But looks like its not been applied. Is there any ETA on supporting Linux kernel above 3.2 series? [1] https://www.mail-archive.com/rtn...@li.../msg00654.html Thanks and Regards -- Vasudev Kamath http://copyninja.info copyninja@{frndk.de|vasudev.homelinux.net} |
From: Elker C. <elk...@gm...> - 2014-07-01 09:31:42
|
Hi all, after looking at driver source, I've figured out that rt_e1000e driver do not support link detection. I've added basic ethtool support for GLINK on e1000e, see attached patch. Regards, Elker Il 25/06/2014 11.53, Elker Cavina ha scritto: > Hi > I'm using RTNet-0.9.13 with RTAI-3.9.2; my embedded pc has two e1000e > ethernet ports (so rt_e1000e is employed). > > The first port is configured as standard linux (eth1), second port > gets configured to rtnet (firstly unbinded by linux driver, then > configured as rteth0). So far I'm working correctly in rtnet side; > I'm also using rtcap and configured rteth0 on linux side and tcpdump > works great to sniff realtime packets. > > Now I want to detect if carrier is lost on rtnet port; on linux > managed ethernet port looking at /sys/class/net/eth1/carrier I can > detect link loss, however in /sys/class/net/rteth0/carrier I always > get link active even on cable disconnected. > > Digging into code I can see carrier detected and managed in > rtdev->link_state, but I can't find the link to the sys filesystem or > an ioctl call to detect link status. > > Is possible to detect link status on rt_e1000e driver? > If not, can someone point to some code to implement this? > > Thanks, > Elker |
From: Anders B. <and...@co...> - 2014-06-15 10:56:13
|
On 06/15/2014 04:02 AM, Kim Markle wrote: > Hi Anders, > > I have built a linux kernel on 3.14.4 with xenomai-2.6.3. And now I am > trying to get RTNet to compile but it's failing:( > > I ran across some email exchanges on RTNet not building > against xenomai-2.6.3 and you built part of a patch, which I tried, but > still running into more compile issues, I tried to fix it but not having > much luck. Was wondering if you have made any additional progress on > this by any chance? I haven't had time yet (Hint: Jan, your verdict on the patches so far, is still missing). And please CC list when you ask questions, there are others better informed and there might be others that are also interested. /Anders -- Anders Blomdell Email: and...@co... Department of Automatic Control Lund University Phone: +46 46 222 4625 P.O. Box 118 SE-221 00 Lund, Sweden |
From: Jonathan C. <jon...@gm...> - 2014-05-02 19:26:46
|
I am an RTAI and RTnEt user. I installed the last version of RTAI (4.0-test2, not really the last but one very close xD ). I tried to install RTnet too, i downloaded the last version ( 0.9.13 ) and in the documentation seems that the support for RTAI version is up to 3.3 or better. Sadly wher i try to compile i have this error: checking for RTAI version... configure: error: *** Unsupported RTAI version > 4.0-test2 in /usr/realtime > Do you think that there are chances to do working RTAI 4.0 with Rtnet? My problem is that i want to use kernel 3.x.x and the only version of RTAI with this kernel version is the 4.0... Thanks Jonathan Cacace |
From: <nic...@wa...> - 2014-03-17 18:01:39
|
> We have developed and tested a patch to go from the actual rt_e1000e > present on the git repository based on the driver in the source of Linux > Kernel 3.2 (Intel version 1.5.1) to e1000e's version of the Linux Kernel > 3.8 (Intel version 2.1.4) which supports latest Ethernet adapter i217/i218 > of the Intel's 4th generation of Core (Haswell). We have tested it on > i218V and 82579V with Xenomai 2.6.3 and Linux Kernel 3.8.13. Here is a complementary patch of the stack of RTNet for the previous patch to work. Tested on i218V and 82579V with Xenomai 2.6.3 and Linux Kernel 3.8.13. |