rtnet-developers — development-related list

Re: [RTnet-developers] Running an RTNET node over a non-rt network.

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

Gilles Chanteperdrix wrote:
> Jan Kiszka wrote:
>  > Hi Gilles,
>  >=20
>  > Gilles Chanteperdrix wrote:
>  > > Hi,
>  > >=20
>  > > I am asked to run a real-time networking application on a non real=
-time
>  > > network, so, I naturally thought about using RTnet.
>  > >=20
>  > > But unless I am completely mistaken, it is not what RTnet is origi=
nally
>  > > made for. As far as I understood, in an RTnet network, the non rea=
l-time
>  > > trafic is tunneled through the real-time traffic by adding an rtma=
c
>  > > header with the RTMAC_FLAG_TUNNEL flag set. But since the other no=
des on
>  > > the network I am on are non-rt, they do not understand the rtmac h=
eader.
>  >=20
>  > Before I misunderstand your patch: you run RTmac/TDMA on a non-RT
>  > network and you then need to use the tunnel (also) between RT and no=
n-RT
>  > nodes? Have you considered the rtnetproxy as platform for your solut=
ion
>  > as well? Or do you see your approach as a potential replacement for =
the
>  > proxy?
>=20
> My aim is to run an RTnet node on a non real-time network, in order for=

> real-time applications to avoid loosing determinism when they transmit
> or receive packets over network. But I would like the rest of the syste=
m

Keep in mind: Concurrent access of RT and non-RT to the same NIC for
transmitting data may require some tweaking to manage non-RT traffic
bursts. Even more problematic: receiving non-RT traffic over an RT-NIC
can easily toast your systems determinism (message dispatching...). You
will have to enforce some kind of traffic shaping towards the RTnet node
as well.

> to continue working as if RTnet was not there. I have tried rtnetproxy,=

> but with rtnetproxy, arp requests/replies do not work, so that my non
> real-time applications do not work.

I guess ARP forwarding was not yet a use case for rtnetproxy. One could
solve this by injecting incoming ARP replies into the Linux stack as
well. Another open issue is forwarding UDP packets to non-RTnet ports.

>=20
> So far, I have only tried to get the non real-time stuff working, so I
> am using the NOMAC discipline, and I suspect the patch I sent does not

Hmm, NoMAC is for demo purpose, not originally developed to solve real
problems. BTW, how do you want to demux incoming packets if you kill the
RTmac header?

> work with anything else. I even suspect that it does not work at all,
> since I am getting kernel bugs, and am not sure whether they are due to=

> this patch, or to my real-time ethernet driver implementation.
>=20
> Anyway, I am open to any better solution.
>=20

I really recommend going the rtnetproxy path, adding the missing
features to that module and/or establishing more hooks in the stack.

Jan

Re: [RTnet-developers] Running an RTNET node over a non-rt network.

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

Jan Kiszka wrote:
 > Hi Gilles,
 > 
 > Gilles Chanteperdrix wrote:
 > > Hi,
 > > 
 > > I am asked to run a real-time networking application on a non real-time
 > > network, so, I naturally thought about using RTnet.
 > > 
 > > But unless I am completely mistaken, it is not what RTnet is originally
 > > made for. As far as I understood, in an RTnet network, the non real-time
 > > trafic is tunneled through the real-time traffic by adding an rtmac
 > > header with the RTMAC_FLAG_TUNNEL flag set. But since the other nodes on
 > > the network I am on are non-rt, they do not understand the rtmac header.
 > 
 > Before I misunderstand your patch: you run RTmac/TDMA on a non-RT
 > network and you then need to use the tunnel (also) between RT and non-RT
 > nodes? Have you considered the rtnetproxy as platform for your solution
 > as well? Or do you see your approach as a potential replacement for the
 > proxy?

My aim is to run an RTnet node on a non real-time network, in order for
real-time applications to avoid loosing determinism when they transmit
or receive packets over network. But I would like the rest of the system
to continue working as if RTnet was not there. I have tried rtnetproxy,
but with rtnetproxy, arp requests/replies do not work, so that my non
real-time applications do not work.

So far, I have only tried to get the non real-time stuff working, so I
am using the NOMAC discipline, and I suspect the patch I sent does not
work with anything else. I even suspect that it does not work at all,
since I am getting kernel bugs, and am not sure whether they are due to
this patch, or to my real-time ethernet driver implementation.

Anyway, I am open to any better solution.

-- 


					    Gilles Chanteperdrix.

Re: [RTnet-developers] Running an RTNET node over a non-rt network.

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

Hi Gilles,

Gilles Chanteperdrix wrote:
> Hi,
>=20
> I am asked to run a real-time networking application on a non real-time=

> network, so, I naturally thought about using RTnet.
>=20
> But unless I am completely mistaken, it is not what RTnet is originally=

> made for. As far as I understood, in an RTnet network, the non real-tim=
e
> trafic is tunneled through the real-time traffic by adding an rtmac
> header with the RTMAC_FLAG_TUNNEL flag set. But since the other nodes o=
n
> the network I am on are non-rt, they do not understand the rtmac header=
=2E

Before I misunderstand your patch: you run RTmac/TDMA on a non-RT
network and you then need to use the tunnel (also) between RT and non-RT
nodes? Have you considered the rtnetproxy as platform for your solution
as well? Or do you see your approach as a potential replacement for the
proxy?

Jan

Re: [RTnet-developers] Running an RTNET node over a non-rt network.

[Wolfgang G. <wg...@gr...>]

Saiful Khan wrote:
> Hi Gilles,
> 
> I have some confusions
> 1. U changed the protocol stack only, so it will work in nonRT linux
> over nonRTDM driver rite?
> 2. Then can the real time performance be achieved?
> 3. Can u please tell me how to use/install it in nonRT linux? (as when
> after patching i tried to configure using ./configure then I got
> error: checking for RT-extension... configure: error: *** RT-extended
> kernel not found in /lib/modules/2.6.20/build)

Well, RTnet requires a real-time extension. It cannot be used as-is with 
the standard Linux kernel (and without real-time it does not even make 
sense)

> Sorry if I asked any invalid questions.

I have the impression that you are not really aware of what RTnet is 
good for. Could you please tell use why you like to use it.

Wolfgang.


> Thanks and regards
> Saiful
> 
> On 3/15/07, Gilles Chanteperdrix <gil...@la...> wrote:
>> Hi,
>>
>> I am asked to run a real-time networking application on a non real-time
>> network, so, I naturally thought about using RTnet.
>>
>> But unless I am completely mistaken, it is not what RTnet is originally
>> made for. As far as I understood, in an RTnet network, the non real-time
>> trafic is tunneled through the real-time traffic by adding an rtmac
>> header with the RTMAC_FLAG_TUNNEL flag set. But since the other nodes on
>> the network I am on are non-rt, they do not understand the rtmac header.
>>
>> So, I started hacking RTnet to get what I wanted, and since I believe it
>> may interest other users, I submit the patch here. I do not expect this
>> patch to be integrated as is, it is merely a one day hack, but it should
>> demonstrate my use-case of RTnet and hopefully influence RTnet
>> developers to take this use-case into account.
>>
>> Regards.
>>
>> --
>>                                                  Gilles Chanteperdrix
>>
> 
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys-and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> RTnet-developers mailing list
> RTn...@li...
> https://lists.sourceforge.net/lists/listinfo/rtnet-developers
> 
> 

Re: [RTnet-developers] Running an RTNET node over a non-rt network.

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

Saiful Khan wrote:
> Hi Gilles,
> 
> I have some confusions
> 1. U changed the protocol stack only, so it will work in nonRT linux
> over nonRTDM driver rite?

The original RTnet already provides this support.

> 2. Then can the real time performance be achieved?

The real-time response is only achieved for packets directed to
real-time applications.

> 3. Can u please tell me how to use/install it in nonRT linux? (as when
> after patching i tried to configure using ./configure then I got
> error: checking for RT-extension... configure: error: *** RT-extended
> kernel not found in /lib/modules/2.6.20/build)

I am an RTnet newby myself, so I will not be of much help. The patch I
sent is not made for end users, but for RTnet developers as an example
of the modifications of the stack I would need, so you should not apply
it if you do not know what you are doing. However since the problem you
have is a user problem, I suggest you post to the rtnet-users mailing list.

-- 
                                                 Gilles Chanteperdrix

Re: [RTnet-developers] Running an RTNET node over a non-rt network.

[Saiful K. <sai...@gm...>]

Hi Gilles,

I have some confusions
1. U changed the protocol stack only, so it will work in nonRT linux
over nonRTDM driver rite?
2. Then can the real time performance be achieved?
3. Can u please tell me how to use/install it in nonRT linux? (as when
after patching i tried to configure using ./configure then I got
error: checking for RT-extension... configure: error: *** RT-extended
kernel not found in /lib/modules/2.6.20/build)

Sorry if I asked any invalid questions.

Thanks and regards
Saiful

On 3/15/07, Gilles Chanteperdrix <gil...@la...> wrote:
>
> Hi,
>
> I am asked to run a real-time networking application on a non real-time
> network, so, I naturally thought about using RTnet.
>
> But unless I am completely mistaken, it is not what RTnet is originally
> made for. As far as I understood, in an RTnet network, the non real-time
> trafic is tunneled through the real-time traffic by adding an rtmac
> header with the RTMAC_FLAG_TUNNEL flag set. But since the other nodes on
> the network I am on are non-rt, they do not understand the rtmac header.
>
> So, I started hacking RTnet to get what I wanted, and since I believe it
> may interest other users, I submit the patch here. I do not expect this
> patch to be integrated as is, it is merely a one day hack, but it should
> demonstrate my use-case of RTnet and hopefully influence RTnet
> developers to take this use-case into account.
>
> Regards.
>
> --
>                                                  Gilles Chanteperdrix
>

[RTnet-developers] Running an RTNET node over a non-rt network.

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

Hi,

I am asked to run a real-time networking application on a non real-time
network, so, I naturally thought about using RTnet.

But unless I am completely mistaken, it is not what RTnet is originally
made for. As far as I understood, in an RTnet network, the non real-time
trafic is tunneled through the real-time traffic by adding an rtmac
header with the RTMAC_FLAG_TUNNEL flag set. But since the other nodes on
the network I am on are non-rt, they do not understand the rtmac header.

So, I started hacking RTnet to get what I wanted, and since I believe it
may interest other users, I submit the patch here. I do not expect this
patch to be integrated as is, it is merely a one day hack, but it should
demonstrate my use-case of RTnet and hopefully influence RTnet
developers to take this use-case into account.

Regards.

-- 
                                                 Gilles Chanteperdrix

Re: [RTnet-developers] RTnet on GNU/Linux

[Wolfgang G. <wg...@gr...>]

Saiful Khan wrote:
> 
> 
> On 3/12/07, *Wolfgang Grandegger* <wg...@gr... 
> <mailto:wg...@gr...>> wrote:
> 
>     Saiful Khan wrote:
>      >
>      >
>      > On 3/11/07, *Wolfgang Grandegger* <wg...@gr...
>     <mailto:wg...@gr...>
>      > <mailto:wg...@gr... <mailto:wg...@gr...>>> wrote:
>      >
>      >     Hello Saiful,
>      >
>      >     Saiful Khan wrote:
>      >      > Hello,
>      >      >
>      >      > Is it possible to port RTNet in non realtime OS like normal
>      >     GNU/Linux?
>      >
>      >     I'm not sure if I understand your question correctly, especially
>      >     because
>      >     you ask a similar one on the Xenomai-Help mailing list. RTnet
>     is a
>      >     real-time capable network stack based on RTDM, the real-time
>     driver
>      >     model, currently available for RTAI and Xenomai. If you need
>     real-time
>      >     ethernet, RTnet is an option. I think you want to port your
>     application
>      >     to RTnet? Is this correct?
>      >
>      >     Wolfgang.
>      >
>      >
>      > No. Actually that portion is over, I have successfully ported my
>      > application in Xenoami kernel that is using RTnet. I mean to say that
>      > suppose I have a normal Linux Kernel taken from kernel.org
>     <http://kernel.org>
>      > <http://kernel.org> (non Xenomai/non RTAI/non realtime) and want to
>      > replace the ethernet protocol stack by RTnet. Is it possible? If
>     not how
>      > it can be made possible?
> 
>     Hm, RTnet is a real-time capable network protocol stack and it makes
>     little sense to use it in a non-real-time environment. What are you
>     looking for? Why is the normal Linux network protocol stack not
>     suitable
>     for your app?
> 
>     RTnet is based on RTDM, which is not available for vanilla Linux, but
>     I'm currently working on a RTDM port over Linux kernel services with the
>     real-time preemption patch [1]. It will allow to use RTnet with
>     Linux-rt
>     in the near future.
> 
>     Wolfgang.
> 
>     [1] http://rt.wiki.kernel.org/index.php/Main_Page
> 
> 
> 
> 
> Hello Wolfgang,
> 
> Actually I didnot ask the question clearly, sorry for that. I want RTnet 
> in RT-Preempt kernel. Very happy to know that you are working on it. May 
> I know when it will be available?

A first version of RTDM over -rt will be available soon (in one or two 
weeks). But for RTnet further modifications are necessary, especially to 
the build system.

> I am a starter in Linux so I want to know & explore more on RTDM. 
> Suppose if you assign me the same task of porting RTDM over linux kernel 
> services with rt-preempt patch, How I have to proceed? Any tutorial or 
> manual can you please suggest me.

You do not need to care on how RTDM is implemented. If you use the POSIX 
API, RTnet is used like the normal network stack using the BSD socket 
interface. Be aware that RTnet is for real-time and has other concepts 
(e.g. TDMA) and some limitations (e.g. no TCP).

> Sorry for the stupid question.

You are welcome.

Wolfgang.

Re: [RTnet-developers] RTnet on GNU/Linux

[Saiful K. <sai...@gm...>]

On 3/12/07, Wolfgang Grandegger <wg...@gr...> wrote:
>
> Saiful Khan wrote:
> >
> >
> > On 3/11/07, *Wolfgang Grandegger* <wg...@gr...
> > <mailto:wg...@gr...>> wrote:
> >
> >     Hello Saiful,
> >
> >     Saiful Khan wrote:
> >      > Hello,
> >      >
> >      > Is it possible to port RTNet in non realtime OS like normal
> >     GNU/Linux?
> >
> >     I'm not sure if I understand your question correctly, especially
> >     because
> >     you ask a similar one on the Xenomai-Help mailing list. RTnet is a
> >     real-time capable network stack based on RTDM, the real-time driver
> >     model, currently available for RTAI and Xenomai. If you need
> real-time
> >     ethernet, RTnet is an option. I think you want to port your
> application
> >     to RTnet? Is this correct?
> >
> >     Wolfgang.
> >
> >
> > No. Actually that portion is over, I have successfully ported my
> > application in Xenoami kernel that is using RTnet. I mean to say that
> > suppose I have a normal Linux Kernel taken from kernel.org
> > <http://kernel.org> (non Xenomai/non RTAI/non realtime) and want to
> > replace the ethernet protocol stack by RTnet. Is it possible? If not how
> > it can be made possible?
>
> Hm, RTnet is a real-time capable network protocol stack and it makes
> little sense to use it in a non-real-time environment. What are you
> looking for? Why is the normal Linux network protocol stack not suitable
> for your app?
>
> RTnet is based on RTDM, which is not available for vanilla Linux, but
> I'm currently working on a RTDM port over Linux kernel services with the
> real-time preemption patch [1]. It will allow to use RTnet with Linux-rt
> in the near future.
>
> Wolfgang.
>
> [1] http://rt.wiki.kernel.org/index.php/Main_Page




Hello Wolfgang,

Actually I didnot ask the question clearly, sorry for that. I want RTnet in
RT-Preempt kernel. Very happy to know that you are working on it. May I know
when it will be available?
I am a starter in Linux so I want to know & explore more on RTDM. Suppose if
you assign me the same task of porting RTDM over linux kernel services with
rt-preempt patch, How I have to proceed? Any tutorial or manual can you
please suggest me.

Sorry for the stupid question.

Thanks and regards
Saiful

Re: [RTnet-developers] RTnet on GNU/Linux

[Wolfgang G. <wg...@gr...>]

Saiful Khan wrote:
> 
> 
> On 3/11/07, *Wolfgang Grandegger* <wg...@gr... 
> <mailto:wg...@gr...>> wrote:
> 
>     Hello Saiful,
> 
>     Saiful Khan wrote:
>      > Hello,
>      >
>      > Is it possible to port RTNet in non realtime OS like normal
>     GNU/Linux?
> 
>     I'm not sure if I understand your question correctly, especially
>     because
>     you ask a similar one on the Xenomai-Help mailing list. RTnet is a
>     real-time capable network stack based on RTDM, the real-time driver
>     model, currently available for RTAI and Xenomai. If you need real-time
>     ethernet, RTnet is an option. I think you want to port your application
>     to RTnet? Is this correct?
> 
>     Wolfgang.
> 
> 
> No. Actually that portion is over, I have successfully ported my 
> application in Xenoami kernel that is using RTnet. I mean to say that 
> suppose I have a normal Linux Kernel taken from kernel.org 
> <http://kernel.org> (non Xenomai/non RTAI/non realtime) and want to 
> replace the ethernet protocol stack by RTnet. Is it possible? If not how 
> it can be made possible?

Hm, RTnet is a real-time capable network protocol stack and it makes 
little sense to use it in a non-real-time environment. What are you 
looking for? Why is the normal Linux network protocol stack not suitable 
for your app?

RTnet is based on RTDM, which is not available for vanilla Linux, but 
I'm currently working on a RTDM port over Linux kernel services with the 
real-time preemption patch [1]. It will allow to use RTnet with Linux-rt 
in the near future.

Wolfgang.

[1] http://rt.wiki.kernel.org/index.php/Main_Page

Re: [RTnet-developers] RTnet on GNU/Linux

[Wolfgang G. <wg...@gr...>]

Hello Saiful,

Saiful Khan wrote:
> Hello,
> 
> Is it possible to port RTNet in non realtime OS like normal GNU/Linux?

I'm not sure if I understand your question correctly, especially because 
you ask a similar one on the Xenomai-Help mailing list. RTnet is a 
real-time capable network stack based on RTDM, the real-time driver 
model, currently available for RTAI and Xenomai. If you need real-time 
ethernet, RTnet is an option. I think you want to port your application 
to RTnet? Is this correct?

Wolfgang.

[RTnet-developers] RTnet on GNU/Linux

[Saiful K. <sai...@gm...>]

Hello,

Is it possible to port RTNet in non realtime OS like normal GNU/Linux?

Thanks and regards
Saiful

[RTnet-developers] RTnet on GNU/Linux

[Saiful K. <sai...@gm...>]

Hello,

Is it possible to port RTnet on GNU/Linux (Linux with out Xenomai/RTAI)?

Thanks and regards
Saiful

Re: [RTnet-developers] Rtnet 0.7.1

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

Jose Manuel Mart=EDn wrote:
> Hi.
>=20
> =20
>=20
> I'm working on rtnet 0.7.1 on ppc. I'm sending udp messages  across sen=
dmsg_rt with a 2 ms period and 576 bytes data size.
>=20

Uhh, that's old.

> =20
>=20
> Socket was created prior to task_init and after rt_start_timer.
>=20
> =20
>=20
> Normally, I can't close socket ever, I always receive a EAGAIN.
>=20

I don't recall any related bug right now, but generally there are two
reasons for this:

- Leaking rtskb
  (might be also a NIC driver bug, which one are you using?)

- For some reason, a blocking rtnet operation is not returning to the
  application, thus not releasing the socket lock. But as you say you
  only use sendmsg_rt, that shouldn't be the issue here.

You will have to instrument the RTnet core (printk) to check what the
reason for the continuous failure is.

Jan

[RTnet-developers] Rtnet 0.7.1

[<jm...@pr...>]

Hi.

=20

I'm working on rtnet 0.7.1 on ppc. I'm sending udp messages  across =
sendmsg_rt with a 2 ms period and 576 bytes data size.

=20

Socket was created prior to task_init and after rt_start_timer.

=20

Normally, I can't close socket ever, I always receive a EAGAIN.

=20

Thanks

=20

=20

=20

=20

=20

Re: [RTnet-developers] [Xenomai-help] [RFT] RTnet on x86_64

[Philippe G. <rp...@xe...>]

On Sat, 2007-02-24 at 10:42 +0100, Philippe Gerum wrote:
> On Sat, 2007-02-24 at 00:10 +0000, Paul wrote:
> > Hi Jan
> > 
> > On Friday 23 February 2007 23:30, Jan Kiszka wrote:
> > > recent development on Xenomai and the underlying I-pipe patch [1]
> > > reached a point where real experiments on yet another architecture for
> > > RTnet are starting to make sense.
> > >
> > > In fact, RTnet has been enabled to build over x86_64 already two weeks
> > > back, including a necessary fix to the RTDM layer. I just checked again:
> > > it still compiles fine. 8)
> > >
> > > I'm lacking a test platform, so _you_ have the unique chance to be the
> > > first person running RTnet on 64 bits! Grab a 2.6.19 kernel and the
> > > latest I-pipe patch [2], checkout Xenomai [3] and RTnet trunk [4]. Put
> > > everything on some native 64-bit Linux installation and give it hell.
> > 
> > As you probably know, I've already committed to running tests over the weekend 
> > on real hardware - Not being familiar with RTnet, are there any test suites 
> > that can be used on say i386<->AMD64<->ppc ?
> > 
> > > Ah, and don't forget to report your findings!
> > 
> > /me is good at breaking "stuff" and reporting the results ;)
> > 
> > 
> 
> Btw, to push SMP too hard for now, I've just discovered an instability
> under RT operations, and enabling the tracer over SMP does introduce
> another random issue here. UP still looks fine. I'm going to chase the
> SMP issues now.
> 

CONFIG_PREEMPT breaks the toy when enabled, so you should be able to
safely run the Xenomai stack over SMP/x86_64 without preemption for the
time being.

-- 
Philippe.

Re: [RTnet-developers] [Xenomai-help] [RFT] RTnet on x86_64

[Philippe G. <rp...@xe...>]

On Sat, 2007-02-24 at 00:10 +0000, Paul wrote:
> Hi Jan
> 
> On Friday 23 February 2007 23:30, Jan Kiszka wrote:
> > recent development on Xenomai and the underlying I-pipe patch [1]
> > reached a point where real experiments on yet another architecture for
> > RTnet are starting to make sense.
> >
> > In fact, RTnet has been enabled to build over x86_64 already two weeks
> > back, including a necessary fix to the RTDM layer. I just checked again:
> > it still compiles fine. 8)
> >
> > I'm lacking a test platform, so _you_ have the unique chance to be the
> > first person running RTnet on 64 bits! Grab a 2.6.19 kernel and the
> > latest I-pipe patch [2], checkout Xenomai [3] and RTnet trunk [4]. Put
> > everything on some native 64-bit Linux installation and give it hell.
> 
> As you probably know, I've already committed to running tests over the weekend 
> on real hardware - Not being familiar with RTnet, are there any test suites 
> that can be used on say i386<->AMD64<->ppc ?
> 
> > Ah, and don't forget to report your findings!
> 
> /me is good at breaking "stuff" and reporting the results ;)
> 
> 

Btw, to push SMP too hard for now, I've just discovered an instability
under RT operations, and enabling the tracer over SMP does introduce
another random issue here. UP still looks fine. I'm going to chase the
SMP issues now.

> Regards, Paul.
> 
> _______________________________________________
> Xenomai-help mailing list
> Xen...@gn...
> https://mail.gna.org/listinfo/xenomai-help
-- 
Philippe.

Re: [RTnet-developers] [Xenomai-help] [RFT] RTnet on x86_64

[Paul <pa...@tu...>]

Hi Jan

On Friday 23 February 2007 23:30, Jan Kiszka wrote:
> recent development on Xenomai and the underlying I-pipe patch [1]
> reached a point where real experiments on yet another architecture for
> RTnet are starting to make sense.
>
> In fact, RTnet has been enabled to build over x86_64 already two weeks
> back, including a necessary fix to the RTDM layer. I just checked again:
> it still compiles fine. 8)
>
> I'm lacking a test platform, so _you_ have the unique chance to be the
> first person running RTnet on 64 bits! Grab a 2.6.19 kernel and the
> latest I-pipe patch [2], checkout Xenomai [3] and RTnet trunk [4]. Put
> everything on some native 64-bit Linux installation and give it hell.

As you probably know, I've already committed to running tests over the weekend 
on real hardware - Not being familiar with RTnet, are there any test suites 
that can be used on say i386<->AMD64<->ppc ?

> Ah, and don't forget to report your findings!

/me is good at breaking "stuff" and reporting the results ;)


Regards, Paul.

[RTnet-developers] [RFT] RTnet on x86_64

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

Hi,

recent development on Xenomai and the underlying I-pipe patch [1]
reached a point where real experiments on yet another architecture for
RTnet are starting to make sense.

In fact, RTnet has been enabled to build over x86_64 already two weeks
back, including a necessary fix to the RTDM layer. I just checked again:
it still compiles fine. 8)

I'm lacking a test platform, so _you_ have the unique chance to be the
first person running RTnet on 64 bits! Grab a 2.6.19 kernel and the
latest I-pipe patch [2], checkout Xenomai [3] and RTnet trunk [4]. Put
everything on some native 64-bit Linux installation and give it hell.

Ah, and don't forget to report your findings!

Jan

[1] https://mail.gna.org/public/xenomai-core/2007-02/msg00205.html
[2] http://download.gna.org/adeos/patches/v2.6/x86_64/
[3] https://gna.org/svn/?group=3Dxenomai
[4] http://sourceforge.net/svn/?group_id=3D68976

Re: [RTnet-developers] RT IRQ sharing

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

Marcelo Coelho wrote:
>> Please clean up your patches before you post. Means: no unrelated
>> changes, no uncommented old code, no unused function argument
>> (ioaddr...), etc.
> Sorry, I'm a little under pressure and sometimes I forget somethings...=

>=20
> This patch already has the kernel's interrupt handler routine, kind of =
a mix between the kernel version and RTnet's one.
> But it still gives me a problem: it looks like I don't transmit anythin=
g to the network, don't know why.
>=20
> I'll keep on working on this. If someone finds a problem here, please l=
et me know ASAP.
>=20
>=20
>=20
> Thanks for the help!
> Marcelo
>=20
>=20
>=20
>=20
>=20
> -----------------------------------------------------------------------=
-
>=20
> Index: drivers/rt_8139too.c
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> --- drivers/rt_8139too.c	(revision 1106)
> +++ drivers/rt_8139too.c	(working copy)
> @@ -379,7 +379,7 @@
> =20
> =20
>  /* Twister tuning parameters from RealTek.
> -   Completely undocumented, but required to tune bad links. */
> +   Completely undocumented, but required to tune bad links on some boa=
rds. */
>  enum CSCRBits {
>          CSCR_LinkOKBit =3D 0x0400,
>          CSCR_LinkChangeBit =3D 0x0800,
> @@ -595,11 +595,37 @@
>          PCIErr | PCSTimeout | RxUnderrun | RxOverflow | RxFIFOOver |
>          TxErr | TxOK | RxErr | RxOK;
> =20
> +static const u16 rtl8139_norx_intr_mask =3D
> +        PCIErr | PCSTimeout | RxUnderrun |
> +        TxErr | TxOK | RxErr ;
> +
> +#if RX_BUF_LEN_IDX =3D=3D 0
>  static const unsigned int rtl8139_rx_config =3D
> +        RxCfgRcv8K | RxNoWrap |
> +        (RX_FIFO_THRESH << RxCfgFIFOShift) |
> +        (RX_DMA_BURST << RxCfgDMAShift);
> +#elif RX_BUF_LEN_IDX =3D=3D 1
> +static const unsigned int rtl8139_rx_config =3D
> +        RxCfgRcv16K | RxNoWrap |
> +        (RX_FIFO_THRESH << RxCfgFIFOShift) |
> +        (RX_DMA_BURST << RxCfgDMAShift);
> +#elif RX_BUF_LEN_IDX =3D=3D 2
> +static const unsigned int rtl8139_rx_config =3D
>          RxCfgRcv32K | RxNoWrap |
>          (RX_FIFO_THRESH << RxCfgFIFOShift) |
>          (RX_DMA_BURST << RxCfgDMAShift);
> +#elif RX_BUF_LEN_IDX =3D=3D 3
> +static const unsigned int rtl8139_rx_config =3D
> +        RxCfgRcv64K |
> +        (RX_FIFO_THRESH << RxCfgFIFOShift) |
> +        (RX_DMA_BURST << RxCfgDMAShift);
> +#else
> +#error "Invalid configuration for 8139_RX_BUF_LEN_IDX"
> +#endif

Can those changes be safely broken out into a separate patch? Would help
to test things independently.

> =20
> +
> +
> +
>  static const unsigned int rtl8139_tx_config =3D
>          TxIFG96 | (TX_DMA_BURST << TxDMAShift) | (TX_RETRY << TxRetryS=
hift);
> =20
> @@ -1155,7 +1181,7 @@
>          rt_stack_connect(rtdev, &STACK_manager);
> =20
>          retval =3D rtdm_irq_request(&tp->irq_handle, rtdev->irq,
> -                                  rtl8139_interrupt, 0, rtdev->name, r=
tdev);
> +                                  rtl8139_interrupt, RTDM_IRQTYPE_SHAR=
ED, rtdev->name, rtdev);
>          if (retval)
>                  return retval;
> =20
> @@ -1656,6 +1682,7 @@
>          }
>  }
> =20
> +
>  /* The interrupt handler does all of the Rx thread work and cleans up
>     after the Tx thread. */
>  static int rtl8139_interrupt(rtdm_irq_t *irq_handle)
> @@ -1665,80 +1692,82 @@
>          struct rtnet_device *rtdev =3D rtdm_irq_get_arg(irq_handle, st=
ruct rtnet_device);
>          struct rtl8139_private *tp =3D rtdev->priv;
> =20
> -        int boguscnt =3D max_interrupt_work;
>          void *ioaddr =3D tp->mmio_addr;
> =20
>          int ackstat;
>          int status;
>          int link_changed =3D 0; /* avoid bogus "uninit" warning */
> =20
> -        int saved_status =3D 0;
> +        int handled =3D 0;
> =20
> +
>          rtdm_lock_get(&tp->lock);
> =20
> -        do {
> -                status =3D RTL_R16 (IntrStatus);
> +        status =3D RTL_R16 (IntrStatus);
> =20
> -                /* h/w no longer present (hotplug?) or major error, ba=
il */
> -                if (status =3D=3D 0xFFFF)
> -                        break;
> +        /* shared irq? */
> +        if (unlikely((status & rtl8139_intr_mask) =3D=3D 0))
> +                goto out;
> =20
> -                if ((status &
> -                     (PCIErr | PCSTimeout | RxUnderrun | RxOverflow | =
RxFIFOOver | TxErr | TxOK | RxErr | RxOK)) =3D=3D 0)
> -                        break;
> +        handled =3D 1;
> =20
> -                /* Acknowledge all of the current interrupt sources AS=
AP, but
> -                   an first get an additional status bit from CSCR. */=

> -                if (status & RxUnderrun)
> -                        link_changed =3D RTL_R16 (CSCR) & CSCR_LinkCha=
ngeBit;
> +        /* h/w no longer present (hotplug?) or major error, bail */
> +        if (status =3D=3D 0xFFFF)
> +                goto out;
> =20
> -                /* The chip takes special action when we clear RxAckBi=
ts,
> -                 * so we clear them later in rtl8139_rx_interrupt
> -                 */
> -                ackstat =3D status & ~(RxAckBits | TxErr);
> -                RTL_W16 (IntrStatus, ackstat);
> =20
> -                if (rtnetif_running (rtdev) && (status & RxAckBits)) {=

> -                        saved_status |=3D RxAckBits;
> -                        rtl8139_rx_interrupt (rtdev, tp, ioaddr, &time=
_stamp);
> -                }
> +        /* close possible race's with dev_close */
> +        if (!rtnetif_running(rtdev)) {
> +                RTL_W16 (IntrMask, 0);
> +                goto out;
> +        }

Hmm, that points to an existing issue of our rtl8139_close: the IRQ is
released too early. But that's "only" unrelated cleanup stuff, will fix
later.

> =20
> -                /* Check uncommon events with one test. */
> -                if (status & (PCIErr | PCSTimeout | RxUnderrun | RxOve=
rflow | RxFIFOOver | RxErr)) {
> -                        rtl8139_weird_interrupt (rtdev, tp, ioaddr, st=
atus, link_changed);
> -                }
> =20
> -                if (rtnetif_running (rtdev) && (status & TxOK)) {
> -                        rtl8139_tx_interrupt (rtdev, tp, ioaddr);
> -                        if (status & TxErr)
> -                                RTL_W16 (IntrStatus, TxErr);
> -                        rtnetif_tx(rtdev);
> -                }
> +        /* Acknowledge all of the current interrupt sources ASAP, but
> +        an first get an additional status bit from CSCR. */
> +        if (status & RxUnderrun)
> +                link_changed =3D RTL_R16 (CSCR) & CSCR_LinkChangeBit;
> =20
> -                if (rtnetif_running (rtdev) && (status & TxErr)) {
> -                        saved_status|=3DTxErr;
> -                }
> +        ackstat =3D status & ~(RxAckBits | TxErr);
> +        /*if (ackstat)
> +                */RTL_W16 (IntrStatus, ackstat);

???

> =20
> -                boguscnt--;
> -        } while (boguscnt > 0);
> -        if (boguscnt <=3D 0) {
> -                rtdm_printk(KERN_WARNING "%s: Too much work at interru=
pt, "
> -                           "IntrStatus=3D0x%4.4x.\n", rtdev->name, sta=
tus);
> -                /* Clear all interrupt sources. */
> -                RTL_W16 (IntrStatus, 0xffff);
> -        }
> +        /* Receive packets are processed by poll routine.
> +        If not running start it now. */
> +        if (rtnetif_running (rtdev) && (status & RxAckBits)){
> +                rtl8139_rx_interrupt (rtdev, tp, ioaddr, &time_stamp);=

> =20
> -        rtdm_lock_put(&tp->lock);

Again: don't move this.

> =20
> -        if (saved_status & RxAckBits) {
> +                //RTL_W16_F (IntrMask, rtl8139_norx_intr_mask);

Tss, tss.

>                  rt_mark_stack_mgr(rtdev);
>          }
> =20
> -        if (saved_status & TxErr) {
> -                rtnetif_err_tx(rtdev);
> +        /* Check uncommon events with one test. */
> +        if (unlikely(status & (PCIErr | PCSTimeout | RxUnderrun | RxOv=
erflow | RxFIFOOver | RxErr)))
> +                rtl8139_weird_interrupt (rtdev, tp, ioaddr,
> +                                        status, link_changed);
> +
> +        if (status & (TxOK | TxErr)) {
> +                rtl8139_tx_interrupt (rtdev, tp, ioaddr);
> +                if (status & TxErr)
> +                        RTL_W16 (IntrStatus, TxErr);
> +                rtnetif_tx(rtdev);
>          }
> +        if (rtnetif_running (rtdev) && (status & TxErr)) {
> +                        rtnetif_err_tx(rtdev);
> +        }
> =20
> -        return RTDM_IRQ_HANDLED;
> +        /* This wasn't in the kernel driver, but it was in the previou=
s rtnet
> +        driver so i put it here. */
> +        RTL_W16(IntrStatus, 0xffff);

That's from the "Too much work" error path. You don't check for this
anymore, so this clearing has to go (we may loose events otherwise).

> +        out:
> +        spin_unlock (&tp->lock);

Wrong locking primitive (recent I-pipe will bark at you). Put the
ordering like this:
- check for rx
- check for weird
- check for tx
- unlock
- if there was rx, rt_mark_stack_mgr

> +
> +
> +        if( handled =3D=3D 1 )
> +                return RTDM_IRQ_HANDLED;
> +        else
> +                return RTDM_IRQ_NONE;

Save the return value directly in a local variable, saves one comparison
here.

Jan

Re: [RTnet-developers] RT IRQ sharing

[Marcelo C. <mjc...@cr...>]

> Please clean up your patches before you post. Means: no unrelated
> changes, no uncommented old code, no unused function argument
> (ioaddr...), etc.
Sorry, I'm a little under pressure and sometimes I forget somethings...

This patch already has the kernel's interrupt handler routine, kind of a mix between the kernel version and RTnet's one.
But it still gives me a problem: it looks like I don't transmit anything to the network, don't know why.

I'll keep on working on this. If someone finds a problem here, please let me know ASAP.



Thanks for the help!
Marcelo

Re: [RTnet-developers] RT IRQ sharing

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

Marcelo Coelho wrote:
> Hi!
>=20
>=20
>> Don't understand yet what you mean, but the original locking at the
>> interrupt handler tail is correct and should not be changed by your
> patch.
>=20
> Forget it. I thought I saw the saved_state variable outside that
> function.
>=20
>=20
> I've been seeing the kernel driver and it has some differences, namely,=

> it has support for the BUF_IDX different from 2 (which I included).
> Don't know if that is necessary.
>=20
> But, for now I don't have time for more. I think that this patch should=

> solve the situation, but I still have to test with a system.

Please clean up your patches before you post. Means: no unrelated
changes, no uncommented old code, no unused function argument
(ioaddr...), etc.

>=20
> Next week, maybe I'll have some spare time to port the kernel driver.

As I already mailed you privately: there is no need for a complete
"port", just align the code patterns of those functions you have to
touch anyway (specifically rtl8139_interrupt).

Jan

Re: [RTnet-developers] RT IRQ sharing

[Marcelo C. <mjc...@cr...>]

Hi!


> Don't understand yet what you mean, but the original locking at the
> interrupt handler tail is correct and should not be changed by your
patch.

Forget it. I thought I saw the saved_state variable outside that
function.


I've been seeing the kernel driver and it has some differences, namely,
it has support for the BUF_IDX different from 2 (which I included).
Don't know if that is necessary.

But, for now I don't have time for more. I think that this patch should
solve the situation, but I still have to test with a system.

Next week, maybe I'll have some spare time to port the kernel driver.



Thanks for the help,
Marcelo

Re: [RTnet-developers] RT IRQ sharing

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

Marcelo Coelho wrote:
> Hi!
>=20
>=20
> Here comes the first pre-pre-patch. I'm having lots of abnormal
> interrupts (other pcs are using the network) so I probably did somethin=
g
> wrong. What do you think?

See below for at least one bug. :)

>=20
> The rt_8139too driver was coded using documentation besides the driver
> inside the kernel?

It was derived from on older kernel driver. In-tree 8139too meanwhile
changed its interrupt design a bit, I think it's time to align again.
Please study the current Linux driver and port its loop patterns and IRQ
handled/unhandled reporting to rt_8139too.

>=20
>=20
> Thanks for the help,
> Marcelo
>=20
>=20
>=20
> -----------------------------------------------------------------------=
-
>=20
> Index: drivers/rt_8139too.c
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> --- drivers/rt_8139too.c	(revision 1106)
> +++ drivers/rt_8139too.c	(working copy)
> @@ -523,6 +523,7 @@
> =20
>  static int rtl8139_open (struct rtnet_device *rtdev);
>  static int rtl8139_close (struct rtnet_device *rtdev);
> +static int rtl8139_check_interrupt_triggered(void *ioaddr);
>  static int rtl8139_interrupt (rtdm_irq_t *irq_handle);
>  static int rtl8139_start_xmit (struct rtskb *skb, struct rtnet_device =
*rtdev);
> =20
> @@ -1656,6 +1657,28 @@
>          }
>  }
> =20
> +
> +
> +/* Function to detect if this device triggered the interrupt.
> + return =3D=3D 0, =3D> true; return < 0, =3D> false */
> +static int rtl8139_check_interrupt_triggered( void *ioaddr)
> +{
> +        int status =3D RTL_R16 (IntrStatus);
> +
> +        /* h/w no longer present (hotplug?) or major error, bail */
> +        if (status =3D=3D 0xFFFF) {
> +                return -1;
> +        }
> +
> +        if ((status &
> +            (PCIErr | PCSTimeout | RxUnderrun | RxOverflow | RxFIFOOve=
r | TxErr | TxOK | RxErr | RxOK)) =3D=3D 0) {
> +                return -1;

Unhandled =3D=3D -1

> +        }
> +
> +        return 0;
> +}
> +
> +
>  /* The interrupt handler does all of the Rx thread work and cleans up
>     after the Tx thread. */
>  static int rtl8139_interrupt(rtdm_irq_t *irq_handle)
> @@ -1674,21 +1697,33 @@
> =20
>          int saved_status =3D 0;
> =20
> +
>          rtdm_lock_get(&tp->lock);
> =20
> +
> +        if (rtl8139_check_interrupt_triggered( ioaddr ) =3D=3D RTDM_IR=
Q_NONE)

Unhandled =3D=3D RTDM_IRQ_NONE

Something is wrong...

> +                return RTDM_IRQ_NONE;
> +
>          do {
> -                status =3D RTL_R16 (IntrStatus);
> +                if (rtl8139_check_interrupt_triggered( ioaddr ) =3D=3D=
 RTDM_IRQ_NONE)
> +                        break;
> =20
> -                /* h/w no longer present (hotplug?) or major error, ba=
il */
> -                if (status =3D=3D 0xFFFF)
> +                /*status =3D RTL_R16 (IntrStatus);
> +
> +                *//* h/w no longer present (hotplug?) or major error, =
bail */
> +                /*if (status =3D=3D 0xFFFF) {
> +                        return_value =3D RTDM_IRQ_NONE;
>                          break;
> +                }
> =20
>                  if ((status &
> -                     (PCIErr | PCSTimeout | RxUnderrun | RxOverflow | =
RxFIFOOver | TxErr | TxOK | RxErr | RxOK)) =3D=3D 0)
> +                     (PCIErr | PCSTimeout | RxUnderrun | RxOverflow | =
RxFIFOOver | TxErr | TxOK | RxErr | RxOK)) =3D=3D 0) {
> +                        return_value =3D RTDM_IRQ_NONE;
>                          break;
> +                }*/
> =20
>                  /* Acknowledge all of the current interrupt sources AS=
AP, but
> -                   an first get an additional status bit from CSCR. */=

> +                   first get an additional status bit from CSCR. */
>                  if (status & RxUnderrun)
>                          link_changed =3D RTL_R16 (CSCR) & CSCR_LinkCha=
ngeBit;
> =20
> @@ -1721,14 +1756,13 @@
> =20
>                  boguscnt--;
>          } while (boguscnt > 0);
> -        if (boguscnt <=3D 0) {
> +    /*if (boguscnt <=3D 0) {
>                  rtdm_printk(KERN_WARNING "%s: Too much work at interru=
pt, "
> -                           "IntrStatus=3D0x%4.4x.\n", rtdev->name, sta=
tus);
> +                           "IntrStatus=3D0x%4.4x.\n", rtdev->name, sta=
tus);*/
>                  /* Clear all interrupt sources. */
> -                RTL_W16 (IntrStatus, 0xffff);
> -        }
> +    /*RTL_W16 (IntrStatus, 0xffff);
> +        }*/
> =20
> -        rtdm_lock_put(&tp->lock);
> =20
>          if (saved_status & RxAckBits) {
>                  rt_mark_stack_mgr(rtdev);
> @@ -1738,6 +1772,8 @@
>                  rtnetif_err_tx(rtdev);
>          }
> =20
> +        rtdm_lock_put(&tp->lock);
> +
>          return RTDM_IRQ_HANDLED;
>  }
> =20

Re: [RTnet-developers] RT IRQ sharing

[Marcelo C. <mjc...@cr...>]

Hi!


Here comes the first pre-pre-patch. I'm having lots of abnormal
interrupts (other pcs are using the network) so I probably did something
wrong. What do you think?

The rt_8139too driver was coded using documentation besides the driver
inside the kernel?


Thanks for the help,
Marcelo