rtnet-developers — development-related list

[RTnet-developers] Real time scheduling

[Nicklas K. <nic...@gm...>]

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

[RTnet-developers] Unable to start RTnet

[Sakshi B. <sak...@gm...>]

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

[RTnet-developers] Rtnet can not ping

[<238...@qq...>]

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

Re: [RTnet-developers] Gilles Chanteperdrix, 1975-2016

[Jan K. <jan...@we...>]

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

Re: [RTnet-developers] Rtai version

[Jan K. <jan...@we...>]

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

[RTnet-developers] Rtai version

[Nicklas K. <nic...@gm...>]

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

Re: [RTnet-developers] status of rtnet

[Jan K. <jan...@we...>]

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

Re: [RTnet-developers] status of rtnet

[Wu, A. <Aar...@an...>]

> -----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

Re: [RTnet-developers] status of rtnet

[Jan K. <jan...@we...>]

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

[RTnet-developers] status of rtnet

[Wu, A. <Aar...@an...>]

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

Re: [RTnet-developers] [Xenomai] RTnet in Xenomai 3, status and future

[Gilles C. <gil...@xe...>]

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.

Re: [RTnet-developers] [Xenomai] RTnet in Xenomai 3, status and future

[Gilles C. <gil...@xe...>]

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.

Re: [RTnet-developers] [Xenomai] RTnet in Xenomai 3, status and future

[Gilles C. <gil...@xe...>]

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.

Re: [RTnet-developers] RTnet in Xenomai 3, status and future

[Gilles C. <gil...@xe...>]

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.

Re: [RTnet-developers] RTnet in Xenomai 3, status and future

[Jan K. <jan...@we...>]

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

Re: [RTnet-developers] RTnet in Xenomai 3, status and future

[Gilles C. <gil...@xe...>]

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.

Re: [RTnet-developers] RTnet in Xenomai 3, status and future

[Jan K. <jan...@we...>]

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

[RTnet-developers] RTnet in Xenomai 3, status and future

[Gilles C. <gil...@xe...>]

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.

[RTnet-developers] RDTM skin configure error

[David A. <cnc...@gm...>]

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

Re: [RTnet-developers] Compile failure with linux 3.14.18 and xenomai-2.6 git snapshot

[Vasudev K. <kam...@gm...>]

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}

[RTnet-developers] Compile failure with linux 3.14.18 and xenomai-2.6 git snapshot

[Vasudev K. <kam...@gm...>]

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}

Re: [RTnet-developers] rt_e1000e carrier

[Elker C. <elk...@gm...>]

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

Re: [RTnet-developers] RTNet build on xenomai-2.6.3

[Anders B. <and...@co...>]

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

[RTnet-developers] Dear Developers

[Jonathan C. <jon...@gm...>]

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

Re: [RTnet-developers] [PATCH] Patch for an up to date rt_e1000e

[<nic...@wa...>]

> 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.