rtnet-developers — development-related list

Re: [RTnet-developers] Monitoring Link Beat

[Jorge A. <j-a...@cr...>]

Em Quinta, 23 de Novembro de 2006 17:27, o Jan Kiszka escreveu:
> Jorge Almeida wrote:
> > Em Quinta, 23 de Novembro de 2006 16:46, escreveu:
> >> Jorge Almeida wrote:
> >>> Em Quinta, 23 de Novembro de 2006 16:02, escreveu:
> >>>> Jorge Almeida wrote:
> >>>>> Hello Jan,
> >>>>>
> >>>>> I'm trying to implement an easy way of monitoring the link beat of one 
> >>> board.
> >>>>> What i want is to pass the index of the board, and internaly call the 
> >>>>> "do_ioctl" function that should be initialialized in the rtnet_device 
> >>> struct 
> >>>>> for each device.
> >>>>>
> >>>>> My question is, How do i call the do_ioctl function using the file 
> >>> descriptor 
> >>>>> of one socket that is open passing the number of the if_index (or the 
> >>>>> interface name)? And how rtnet knows wath device to call?
> >>>> IOCTLs on RTDM sockets come in over the related protocol handler, see
> >>>> e.g. this one for packet sockets:
> >>>>
> >>>>
> > 
http://www.rts.uni-hannover.de/rtnet/lxr/source/stack/packet/af_packet.c#L240
> >>>> From there on you can easily go down the chain.
> >>>>
> >>>> As the IOCTLs are per-socket and not per-device, you have to provide 
the
> >>>> information about the address device within the request packet. Do you
> >>>> have some Linux data structure you can reuse for it? Something like for
> >>>> SIOCGIFINDEX?
> >>> Yes, i have the struct ifreq used for the SIOCGIFINDEX ioctl.
> >>>
> >>> I was checking the code and the path is something like this:
> >>>
> >>> 1	Start at "rt_packet_ioctl" (af_packet.c) checking for  a new type of 
> > ioctl 
> >>> "RTIOC_TYPE_MONITORING"
> >> So you are about to define a new IOCTL? Is there no comparable interface
> >> existing in Linux? Will this interface be about polling for the current
> >> link status? I'm not aware of an official Linux API for this, but this
> >> doesn't mean there isn't any.
> > 
> > I don't know either if anything similar exists.
> > I used to use the mii-diag tool to check if the has link bit or not.
> > 
> > The IOCTL is only made when the user asks for it. Theres no polling 
mechanism 
> 
> Which is already what I meant with polling.
> 
> > working here. Thats another question that can be implemented in the 
future.
> > 
> >> Anyway, do this multiplexing here:
> >>
> >> http://www.rts.uni-hannover.de/rtnet/lxr/source/stack/socket.c#L225
> >>
> >> i.e. in rt_socket_if_ioctl(). That way it will automatically work for
> >> all kind of RTnet sockets.
> > 
> > But it is driver dependent, and not a configuration stuff.
> 
> The driver dependent stuff comes with calling rtdev->do_ioctl. Here it
> is about finding out which driver to to call.
> 
> > Isn't better to define already a new type of IOCTL??
> > For future drivers and sockets it will be already available and the 
developers 
> > are free to implement it.
> 
> If there is no IOCTL for Linux that tells you "link on device X is
> up/down", then define one for RTnet.
> 
> > 
> >>> 2	send it to a new function in socket.c "rt_socket_monitoring_ioctl"
> >>>
> >>> 3	check the device that we are trying to check the link beat
> >>>
> >>> 4	send it to the driver (rt_8139too.c) with the do_ioctl pointer.
> >>>
> >>> In this i only have one doubt:
> >>> 	Where do i return the result?
> >> In the same data structure you used for the request? What does it look
> >> like so far?
> >>
> >>> Maybe the solution:
> >>> 	Build a new struct in RTnet has support of the monitoring IOCTLS
> >>> 	(just for now ) something like
> >>>
> >>> struct SDeviceMonit
> >>> {
> >>> 	int nDeviceIndex;
> >>> 	int nLinkBeat;
> >>> }
> >>>
> >>> This way i can identify the device (nDeviceIndex;) and get the result 
> >>> (nLinkBeat;).
> >>>
> >>> Any sugestion??!!
> >> In any case, try to do it within struct ifreq. There is e.g. ifru_ivalue
> >> used by multiple requests to pass an integer up and down.
> > 
> > The ifreq structure is very limited:
> > struct ifreq 
> > {
> > #define IFHWADDRLEN	6
> > 	union
> > 	{
> > 		char	ifrn_name[IFNAMSIZ];		/* if name, e.g. "en0" */
> > 	} ifr_ifrn;
> > 	
> > 	union {
> > 		struct	sockaddr ifru_addr;
> > 		struct	sockaddr ifru_dstaddr;
> > 		struct	sockaddr ifru_broadaddr;
> > 		struct	sockaddr ifru_netmask;
> > 		struct  sockaddr ifru_hwaddr;
> > 		short	ifru_flags;
> > 		int	ifru_ivalue;
> > 		int	ifru_mtu;
> > 		struct  ifmap ifru_map;
> > 		char	ifru_slave[IFNAMSIZ];	/* Just fits the size */
> > 		char	ifru_newname[IFNAMSIZ];
> > 		void __user *	ifru_data;
> > 		struct	if_settings ifru_settings;
> > 	} ifr_ifru;
> > };
> > 
> > only has two fileds, i think the hardware monitoring need much more in the 
> > future. If a new structure is already available the next developers only 
has 
> > to fill it with the new parameters that they need, or even make a union 
> > similar to the struct ifreq.
> 
> OK, if you see the need for further fields that don't fit here, we can
> extend the structure. But I would at least like to keep its head to
> unify its usage - both in user-space and in the kernel.
> 
> What further information would you like to bundle one day
> _with_this_particular_ service call?

For example:

check if Auto-negotiation is enabled or not.
check the link speed.
check if is Half or Full duplex.
change the speed manualy.

And some more that i dont remember now.

I will send you a patch todoy or tomorow morning with something implemented.

Jorge

> 
> Jan
> 
> 

-- 
Jorge Almeida
j-a...@cr...
DISCLAIMER: This message may contain confidential information or privileged material and is intended only for the individual(s) named. If you are not a named addressee and mistakenly received this message you should not copy or otherwise disseminate it: please delete this e-mail from your system and notify the sender immediately. E-mail transmissions are not guaranteed to be secure or without errors as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete or contain viruses. Therefore, the sender does not accept liability for any errors or omissions in the contents of this message that arise as a result of e-mail transmissions. Please request a hard copy version if verification is required. Critical Software, SA.

Re: [RTnet-developers] Monitoring Link Beat

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

Jorge Almeida wrote:
> Em Quinta, 23 de Novembro de 2006 16:46, escreveu:
>> Jorge Almeida wrote:
>>> Em Quinta, 23 de Novembro de 2006 16:02, escreveu:
>>>> Jorge Almeida wrote:
>>>>> Hello Jan,
>>>>>
>>>>> I'm trying to implement an easy way of monitoring the link beat of =
one=20
>>> board.
>>>>> What i want is to pass the index of the board, and internaly call t=
he=20
>>>>> "do_ioctl" function that should be initialialized in the rtnet_devi=
ce=20
>>> struct=20
>>>>> for each device.
>>>>>
>>>>> My question is, How do i call the do_ioctl function using the file =

>>> descriptor=20
>>>>> of one socket that is open passing the number of the if_index (or t=
he=20
>>>>> interface name)? And how rtnet knows wath device to call?
>>>> IOCTLs on RTDM sockets come in over the related protocol handler, se=
e
>>>> e.g. this one for packet sockets:
>>>>
>>>>
> http://www.rts.uni-hannover.de/rtnet/lxr/source/stack/packet/af_packet.=
c#L240
>>>> From there on you can easily go down the chain.
>>>>
>>>> As the IOCTLs are per-socket and not per-device, you have to provide=
 the
>>>> information about the address device within the request packet. Do y=
ou
>>>> have some Linux data structure you can reuse for it? Something like =
for
>>>> SIOCGIFINDEX?
>>> Yes, i have the struct ifreq used for the SIOCGIFINDEX ioctl.
>>>
>>> I was checking the code and the path is something like this:
>>>
>>> 1	Start at "rt_packet_ioctl" (af_packet.c) checking for  a new type o=
f=20
> ioctl=20
>>> "RTIOC_TYPE_MONITORING"
>> So you are about to define a new IOCTL? Is there no comparable interfa=
ce
>> existing in Linux? Will this interface be about polling for the curren=
t
>> link status? I'm not aware of an official Linux API for this, but this=

>> doesn't mean there isn't any.
>=20
> I don't know either if anything similar exists.
> I used to use the mii-diag tool to check if the has link bit or not.
>=20
> The IOCTL is only made when the user asks for it. Theres no polling mec=
hanism=20

Which is already what I meant with polling.

> working here. Thats another question that can be implemented in the fut=
ure.
>=20
>> Anyway, do this multiplexing here:
>>
>> http://www.rts.uni-hannover.de/rtnet/lxr/source/stack/socket.c#L225
>>
>> i.e. in rt_socket_if_ioctl(). That way it will automatically work for
>> all kind of RTnet sockets.
>=20
> But it is driver dependent, and not a configuration stuff.

The driver dependent stuff comes with calling rtdev->do_ioctl. Here it
is about finding out which driver to to call.

> Isn't better to define already a new type of IOCTL??
> For future drivers and sockets it will be already available and the dev=
elopers=20
> are free to implement it.

If there is no IOCTL for Linux that tells you "link on device X is
up/down", then define one for RTnet.

>=20
>>> 2	send it to a new function in socket.c "rt_socket_monitoring_ioctl"
>>>
>>> 3	check the device that we are trying to check the link beat
>>>
>>> 4	send it to the driver (rt_8139too.c) with the do_ioctl pointer.
>>>
>>> In this i only have one doubt:
>>> 	Where do i return the result?
>> In the same data structure you used for the request? What does it look=

>> like so far?
>>
>>> Maybe the solution:
>>> 	Build a new struct in RTnet has support of the monitoring IOCTLS
>>> 	(just for now ) something like
>>>
>>> struct SDeviceMonit
>>> {
>>> 	int nDeviceIndex;
>>> 	int nLinkBeat;
>>> }
>>>
>>> This way i can identify the device (nDeviceIndex;) and get the result=
=20
>>> (nLinkBeat;).
>>>
>>> Any sugestion??!!
>> In any case, try to do it within struct ifreq. There is e.g. ifru_ival=
ue
>> used by multiple requests to pass an integer up and down.
>=20
> The ifreq structure is very limited:
> struct ifreq=20
> {
> #define IFHWADDRLEN	6
> 	union
> 	{
> 		char	ifrn_name[IFNAMSIZ];		/* if name, e.g. "en0" */
> 	} ifr_ifrn;
> =09
> 	union {
> 		struct	sockaddr ifru_addr;
> 		struct	sockaddr ifru_dstaddr;
> 		struct	sockaddr ifru_broadaddr;
> 		struct	sockaddr ifru_netmask;
> 		struct  sockaddr ifru_hwaddr;
> 		short	ifru_flags;
> 		int	ifru_ivalue;
> 		int	ifru_mtu;
> 		struct  ifmap ifru_map;
> 		char	ifru_slave[IFNAMSIZ];	/* Just fits the size */
> 		char	ifru_newname[IFNAMSIZ];
> 		void __user *	ifru_data;
> 		struct	if_settings ifru_settings;
> 	} ifr_ifru;
> };
>=20
> only has two fileds, i think the hardware monitoring need much more in =
the=20
> future. If a new structure is already available the next developers onl=
y has=20
> to fill it with the new parameters that they need, or even make a union=
=20
> similar to the struct ifreq.

OK, if you see the need for further fields that don't fit here, we can
extend the structure. But I would at least like to keep its head to
unify its usage - both in user-space and in the kernel.

What further information would you like to bundle one day
_with_this_particular_ service call?

Jan

Re: [RTnet-developers] Monitoring Link Beat

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

Jorge Almeida wrote:
> Em Quinta, 23 de Novembro de 2006 16:02, escreveu:
>> Jorge Almeida wrote:
>>> Hello Jan,
>>>
>>> I'm trying to implement an easy way of monitoring the link beat of on=
e=20
> board.
>>> What i want is to pass the index of the board, and internaly call the=
=20
>>> "do_ioctl" function that should be initialialized in the rtnet_device=
=20
> struct=20
>>> for each device.
>>>
>>> My question is, How do i call the do_ioctl function using the file=20
> descriptor=20
>>> of one socket that is open passing the number of the if_index (or the=
=20
>>> interface name)? And how rtnet knows wath device to call?
>> IOCTLs on RTDM sockets come in over the related protocol handler, see
>> e.g. this one for packet sockets:
>>
>>
> http://www.rts.uni-hannover.de/rtnet/lxr/source/stack/packet/af_packet.=
c#L240
>> From there on you can easily go down the chain.
>>
>> As the IOCTLs are per-socket and not per-device, you have to provide t=
he
>> information about the address device within the request packet. Do you=

>> have some Linux data structure you can reuse for it? Something like fo=
r
>> SIOCGIFINDEX?
>=20
> Yes, i have the struct ifreq used for the SIOCGIFINDEX ioctl.
>=20
> I was checking the code and the path is something like this:
>=20
> 1	Start at "rt_packet_ioctl" (af_packet.c) checking for  a new type of =
ioctl=20
> "RTIOC_TYPE_MONITORING"

So you are about to define a new IOCTL? Is there no comparable interface
existing in Linux? Will this interface be about polling for the current
link status? I'm not aware of an official Linux API for this, but this
doesn't mean there isn't any.

Anyway, do this multiplexing here:

http://www.rts.uni-hannover.de/rtnet/lxr/source/stack/socket.c#L225

i.e. in rt_socket_if_ioctl(). That way it will automatically work for
all kind of RTnet sockets.

>=20
> 2	send it to a new function in socket.c "rt_socket_monitoring_ioctl"
>=20
> 3	check the device that we are trying to check the link beat
>=20
> 4	send it to the driver (rt_8139too.c) with the do_ioctl pointer.
>=20
> In this i only have one doubt:
> 	Where do i return the result?

In the same data structure you used for the request? What does it look
like so far?

>=20
> Maybe the solution:
> 	Build a new struct in RTnet has support of the monitoring IOCTLS
> 	(just for now ) something like
>=20
> struct SDeviceMonit
> {
> 	int nDeviceIndex;
> 	int nLinkBeat;
> }
>=20
> This way i can identify the device (nDeviceIndex;) and get the result=20
> (nLinkBeat;).
>=20
> Any sugestion??!!

In any case, try to do it within struct ifreq. There is e.g. ifru_ivalue
used by multiple requests to pass an integer up and down.

Jan

Re: [RTnet-developers] Monitoring Link Beat

[Jorge A. <j-a...@cr...>]

Em Quinta, 23 de Novembro de 2006 16:02, escreveu:
> Jorge Almeida wrote:
> > 
> > Hello Jan,
> > 
> > I'm trying to implement an easy way of monitoring the link beat of one 
board.
> > 
> > What i want is to pass the index of the board, and internaly call the 
> > "do_ioctl" function that should be initialialized in the rtnet_device 
struct 
> > for each device.
> > 
> > My question is, How do i call the do_ioctl function using the file 
descriptor 
> > of one socket that is open passing the number of the if_index (or the 
> > interface name)? And how rtnet knows wath device to call?
> 
> IOCTLs on RTDM sockets come in over the related protocol handler, see
> e.g. this one for packet sockets:
> 
> 
http://www.rts.uni-hannover.de/rtnet/lxr/source/stack/packet/af_packet.c#L240
> 
> From there on you can easily go down the chain.
> 
> As the IOCTLs are per-socket and not per-device, you have to provide the
> information about the address device within the request packet. Do you
> have some Linux data structure you can reuse for it? Something like for
> SIOCGIFINDEX?

Yes, i have the struct ifreq used for the SIOCGIFINDEX ioctl.

I was checking the code and the path is something like this:

1	Start at "rt_packet_ioctl" (af_packet.c) checking for  a new type of ioctl 
"RTIOC_TYPE_MONITORING"

2	send it to a new function in socket.c "rt_socket_monitoring_ioctl"

3	check the device that we are trying to check the link beat

4	send it to the driver (rt_8139too.c) with the do_ioctl pointer.

In this i only have one doubt:
	Where do i return the result?

Maybe the solution:
	Build a new struct in RTnet has support of the monitoring IOCTLS
	(just for now ) something like

struct SDeviceMonit
{
	int nDeviceIndex;
	int nLinkBeat;
}

This way i can identify the device (nDeviceIndex;) and get the result 
(nLinkBeat;).

Any sugestion??!!

Thanks


> 
> Jan
> 
> 

-- 
Jorge Almeida
j-a...@cr...
DISCLAIMER: This message may contain confidential information or privileged material and is intended only for the individual(s) named. If you are not a named addressee and mistakenly received this message you should not copy or otherwise disseminate it: please delete this e-mail from your system and notify the sender immediately. E-mail transmissions are not guaranteed to be secure or without errors as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete or contain viruses. Therefore, the sender does not accept liability for any errors or omissions in the contents of this message that arise as a result of e-mail transmissions. Please request a hard copy version if verification is required. Critical Software, SA.

Re: [RTnet-developers] Monitoring Link Beat

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

Jorge Almeida wrote:
>=20
> Hello Jan,
>=20
> I'm trying to implement an easy way of monitoring the link beat of one =
board.
>=20
> What i want is to pass the index of the board, and internaly call the=20
> "do_ioctl" function that should be initialialized in the rtnet_device s=
truct=20
> for each device.
>=20
> My question is, How do i call the do_ioctl function using the file desc=
riptor=20
> of one socket that is open passing the number of the if_index (or the=20
> interface name)? And how rtnet knows wath device to call?

IOCTLs on RTDM sockets come in over the related protocol handler, see
e.g. this one for packet sockets:

http://www.rts.uni-hannover.de/rtnet/lxr/source/stack/packet/af_packet.c#=
L240

=46rom there on you can easily go down the chain.

As the IOCTLs are per-socket and not per-device, you have to provide the
information about the address device within the request packet. Do you
have some Linux data structure you can reuse for it? Something like for
SIOCGIFINDEX?

Jan

[RTnet-developers] Monitoring Link Beat

[Jorge A. <j-a...@cr...>]

Hello Jan,

I'm trying to implement an easy way of monitoring the link beat of one board.

What i want is to pass the index of the board, and internaly call the 
"do_ioctl" function that should be initialialized in the rtnet_device struct 
for each device.

My question is, How do i call the do_ioctl function using the file descriptor 
of one socket that is open passing the number of the if_index (or the 
interface name)? And how rtnet knows wath device to call?

Thanks for your help.

-- 
Jorge Almeida
j-a...@cr...
DISCLAIMER: This message may contain confidential information or privileged material and is intended only for the individual(s) named. If you are not a named addressee and mistakenly received this message you should not copy or otherwise disseminate it: please delete this e-mail from your system and notify the sender immediately. E-mail transmissions are not guaranteed to be secure or without errors as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete or contain viruses. Therefore, the sender does not accept liability for any errors or omissions in the contents of this message that arise as a result of e-mail transmissions. Please request a hard copy version if verification is required. Critical Software, SA.

[RTnet-developers] linux & rtnet socket

[Emanuele C. <rtn...@gm...>]

It's possible sending packet from rtnet node to linux node over rtnet. I 
try communicating from rt_socket and linux socket but it seem doesn't work.
Thank's

Re: [RTnet-developers] ETH_P_ALL feature

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

Jorge Almeida wrote:
> Hello Jan.
>=20
> Regarding the problem we discuss some time ago, it still remains.
>=20
> I have until now found the origin of the problem.
>=20
> Theres no RX interruption handled in any of the boards that should rece=
ive the messages.
>=20
> Thats why the stack_mgr_task never wakes up from the event.
>=20
> I'm using the rt_8139too driver that cames with rtnet.
>=20
> I've done some roll back in rtnet and RTAI and nothing:
> Rtnet until version 1069
> RTAI magma until RTAI-3.4-test1
>=20
> Maybe can be anything related with RTDM and the interrupt handling.

Hmm, there were three significant checkins to that driver, see

http://svn.sourceforge.net/viewvc/rtnet/trunk/rtnet/drivers/rt_8139too.c?=
view=3Dlog

Likely 1013 is worth a try, then 1055 and 1056.

Jan

Re: [RTnet-developers] ETH_P_ALL feature

[Jorge A. <j-a...@cr...>]

Hello Jan.

Regarding the problem we discuss some time ago, it still remains.

I have until now found the origin of the problem.

Theres no RX interruption handled in any of the boards that should receive the messages.

Thats why the stack_mgr_task never wakes up from the event.

I'm using the rt_8139too driver that cames with rtnet.

I've done some roll back in rtnet and RTAI and nothing:
Rtnet until version 1069
RTAI magma until RTAI-3.4-test1

Maybe can be anything related with RTDM and the interrupt handling.

Jorge



Em Segunda, 9 de Outubro de 2006 13:59, o Jan Kiszka escreveu:
> Jan Kiszka wrote:
> > Jorge Almeida wrote:
> >> I putthe following rtdm_printk functions in this function and the 
> >>
> >> rtdm_printk("\tEvent occured\n");
> >>
> >> never is doner when a send messages to the receiveing network.
> > 
> > Is rtdm_event_signal called appropriately?
> > 
> >> I don't know why.
> >>
> >> static void rt_stack_mgr_task(void *arg)
> >> {
> >>     rtdm_event_t            *mgr_event = &((struct rtnet_mgr *)arg)->event;
> >>     struct rtskb            *rtskb;
> >>
> >>     rtdm_printk("\tArrive to the rt_stack_mgr_task function\n");
> >>     while (rtdm_event_wait(mgr_event) == 0) {
> >>         /* we are the only reader => no locking required */
> >>         rtdm_printk("\tEvent occured\n");
> >>         while ((rtskb = __rtskb_fifo_remove(&rx.fifo)))
> >>         {
> >>             rtdm_printk("\trtskb removed from fifo\n");
> >>             rt_stack_deliver(rtskb);
> >>             rtdm_printk("\trtskb delivered\n");
> >>         }
> >>     }
> >>     rtdm_printk("\tGoing out from rt_stack_mgr_task function\n");
> >> }
> >>
> >> The first 
> >>
> >> rtdm_printk("\tArrive to the rt_stack_mgr_task function\n");
> >>
> >> and the last
> >>  rtdm_printk("\tGoing out from rt_stack_mgr_task function\n");
> >>
> >> are done in the starting and at the end of rtnet.
> > 
> > ...but there is no entry in the RTAI task list under /proc like it used to?
> > 
> >> Any clues??
> > 
> > Back to my other suggestion: try older versions of RTnet SVN and RTAI
> > until you find a working combination. Then try to narrow down the change
> > that causes this.
> > 
> 
> Any news on this? I would like to nail down remaining issues in order to
> roll out a new release within, say, a week.
> 
> Jan
> 
> 

-- 
Jorge Almeida
j-a...@cr...
DISCLAIMER: This message may contain confidential information or privileged material and is intended only for the individual(s) named. If you are not a named addressee and mistakenly received this message you should not copy or otherwise disseminate it: please delete this e-mail from your system and notify the sender immediately. E-mail transmissions are not guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete or contain viruses. Therefore, the sender does not accept liability for any errors or omissions in the contents of this message that arise as a result of e-mail transmissions. Please request a hard copy version if verification is required. Critical Software, SA.

Re: [RTnet-developers] ETH_P_ALL feature

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

Jan Kiszka wrote:
> Jorge Almeida wrote:
>> I putthe following rtdm_printk functions in this function and the=20
>>
>> rtdm_printk("\tEvent occured\n");
>>
>> never is doner when a send messages to the receiveing network.
>=20
> Is rtdm_event_signal called appropriately?
>=20
>> I don't know why.
>>
>> static void rt_stack_mgr_task(void *arg)
>> {
>>     rtdm_event_t            *mgr_event =3D &((struct rtnet_mgr *)arg)-=
>event;
>>     struct rtskb            *rtskb;
>>
>>     rtdm_printk("\tArrive to the rt_stack_mgr_task function\n");
>>     while (rtdm_event_wait(mgr_event) =3D=3D 0) {
>>         /* we are the only reader =3D> no locking required */
>>         rtdm_printk("\tEvent occured\n");
>>         while ((rtskb =3D __rtskb_fifo_remove(&rx.fifo)))
>>         {
>>             rtdm_printk("\trtskb removed from fifo\n");
>>             rt_stack_deliver(rtskb);
>>             rtdm_printk("\trtskb delivered\n");
>>         }
>>     }
>>     rtdm_printk("\tGoing out from rt_stack_mgr_task function\n");
>> }
>>
>> The first=20
>>
>> rtdm_printk("\tArrive to the rt_stack_mgr_task function\n");
>>
>> and the last
>>  rtdm_printk("\tGoing out from rt_stack_mgr_task function\n");
>>
>> are done in the starting and at the end of rtnet.
>=20
> ...but there is no entry in the RTAI task list under /proc like it used=
 to?
>=20
>> Any clues??
>=20
> Back to my other suggestion: try older versions of RTnet SVN and RTAI
> until you find a working combination. Then try to narrow down the chang=
e
> that causes this.
>=20

Any news on this? I would like to nail down remaining issues in order to
roll out a new release within, say, a week.

Jan

Re: [RTnet-developers] Gigabit driver RTL8169

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

Petr Cervenka wrote:
> Hello,
> I found a possible error in Realtek 8169 rtnet driver in function rtl81=
69_rx_interrupt. There are missing braces ('{','}') before and after the =
lock, i.e. the crc error counter is increased with every error.
>=20
> 	    if( le32_to_cpu(rxdesc->status) & RxRES ){
> 			rtdm_printk(KERN_INFO "%s: Rx ERROR!!!\n", rtdev->name);
> 			priv->stats.rx_errors++;
> 			if ( le32_to_cpu(rxdesc->status) & (RxRWT|RxRUNT) )
> 				priv->stats.rx_length_errors++;
> 			if ( le32_to_cpu(rxdesc->status) & RxCRC)
> ->				/* in the rt_via-rhine.c there's a lock around the incrementation=
=2E.. we'll do that also here <kk> */
> 				rtdm_lock_get(&priv->lock); /*** RTnet ***/
> 				priv->stats.rx_crc_errors++;
> ->				rtdm_lock_put(&priv->lock); /*** RTnet ***/
> 	    }

Yes, that's obviously wrong. And it is not needed as we do not evaluate
the stats nor would it be critical to mess them up a bit. If you post a
patch, I will commit (I depend on anyone telling me "the driver works"
anyway).

[And via-rhine needs a cleanup as well, but this is uncritical.]

>=20
> In my oppinion, there is perhaps another more serious problem. the rx d=
escriptor status isn't cleared (and what ever else needs to be done is mi=
ssing). My computer got stuck after a while. I will try to investigate it=
 more.

Again, patches are welcome. Also compare with mainstream driver, maybe
fixes were applied meanwhile that are relevant here as well.

>=20
> Note: This error shows itself only when AcceptErr bit is set in RxConfi=
g register, and some of receiving packets are faulty.

I don't think this driver was heavily used yet, that's also why
"experimental". ;)

Jan

[RTnet-developers] Gigabit driver RTL8169

[Petr C. <gr...@ce...>]

Hello,
I found a possible error in Realtek 8169 rtnet driver in function rtl8169_rx_interrupt. There are missing braces ('{','}') before and after the lock, i.e. the crc error counter is increased with every error.

	    if( le32_to_cpu(rxdesc->status) & RxRES ){
			rtdm_printk(KERN_INFO "%s: Rx ERROR!!!\n", rtdev->name);
			priv->stats.rx_errors++;
			if ( le32_to_cpu(rxdesc->status) & (RxRWT|RxRUNT) )
				priv->stats.rx_length_errors++;
			if ( le32_to_cpu(rxdesc->status) & RxCRC)
->				/* in the rt_via-rhine.c there's a lock around the incrementation... we'll do that also here <kk> */
				rtdm_lock_get(&priv->lock); /*** RTnet ***/
				priv->stats.rx_crc_errors++;
->				rtdm_lock_put(&priv->lock); /*** RTnet ***/
	    }

In my oppinion, there is perhaps another more serious problem. the rx descriptor status isn't cleared (and what ever else needs to be done is missing). My computer got stuck after a while. I will try to investigate it more.

Note: This error shows itself only when AcceptErr bit is set in RxConfig register, and some of receiving packets are faulty.

Petr Cervenka

Re: [RTnet-developers] ETH_P_ALL feature

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

Jorge Almeida wrote:
> I putthe following rtdm_printk functions in this function and the=20
>=20
> rtdm_printk("\tEvent occured\n");
>=20
> never is doner when a send messages to the receiveing network.

Is rtdm_event_signal called appropriately?

>=20
> I don't know why.
>=20
> static void rt_stack_mgr_task(void *arg)
> {
>     rtdm_event_t            *mgr_event =3D &((struct rtnet_mgr *)arg)->=
event;
>     struct rtskb            *rtskb;
>=20
>     rtdm_printk("\tArrive to the rt_stack_mgr_task function\n");
>     while (rtdm_event_wait(mgr_event) =3D=3D 0) {
>         /* we are the only reader =3D> no locking required */
>         rtdm_printk("\tEvent occured\n");
>         while ((rtskb =3D __rtskb_fifo_remove(&rx.fifo)))
>         {
>             rtdm_printk("\trtskb removed from fifo\n");
>             rt_stack_deliver(rtskb);
>             rtdm_printk("\trtskb delivered\n");
>         }
>     }
>     rtdm_printk("\tGoing out from rt_stack_mgr_task function\n");
> }
>=20
> The first=20
>=20
> rtdm_printk("\tArrive to the rt_stack_mgr_task function\n");
>=20
> and the last
>  rtdm_printk("\tGoing out from rt_stack_mgr_task function\n");
>=20
> are done in the starting and at the end of rtnet.

=2E..but there is no entry in the RTAI task list under /proc like it used=
 to?

>=20
> Any clues??

Back to my other suggestion: try older versions of RTnet SVN and RTAI
until you find a working combination. Then try to narrow down the change
that causes this.

Jan

Re: [RTnet-developers] ETH_P_ALL feature

[Jorge A. <j-a...@cr...>]

I putthe following rtdm_printk functions in this function and the 

rtdm_printk("\tEvent occured\n");

never is doner when a send messages to the receiveing network.

I don't know why.

static void rt_stack_mgr_task(void *arg)
{
    rtdm_event_t            *mgr_event = &((struct rtnet_mgr *)arg)->event;
    struct rtskb            *rtskb;

    rtdm_printk("\tArrive to the rt_stack_mgr_task function\n");
    while (rtdm_event_wait(mgr_event) == 0) {
        /* we are the only reader => no locking required */
        rtdm_printk("\tEvent occured\n");
        while ((rtskb = __rtskb_fifo_remove(&rx.fifo)))
        {
            rtdm_printk("\trtskb removed from fifo\n");
            rt_stack_deliver(rtskb);
            rtdm_printk("\trtskb delivered\n");
        }
    }
    rtdm_printk("\tGoing out from rt_stack_mgr_task function\n");
}

The first 

rtdm_printk("\tArrive to the rt_stack_mgr_task function\n");

and the last
 rtdm_printk("\tGoing out from rt_stack_mgr_task function\n");

are done in the starting and at the end of rtnet.

Any clues??


Jorge

Em Quinta, 28 de Setembro de 2006 19:31, o Jorge Almeida escreveu:
> 
> Nothing appears in the messages file.
> 
> Tomorrow i will debug the problem and say something.
> 
> Jorge
> 
> Em Quinta, 28 de Setembro de 2006 19:20, o Jan Kiszka escreveu:
> > Jorge Almeida wrote:
> > > Jan
> > > 
> > > With the changes in the stack managersomething happen to the trask that distribute the several messages.
> > > It is not started when i load rtnet.
> > > 
> > > Me test machine has the following modules inserted:
> > > Module                  Size  Used by
> > > rtpacket                5120  0
> > > rtipv4                 21664  0
> > > rtcap                  16384  0
> > > rt_8139too             11904  6
> > > rtnet                  30092  4 rtpacket,rtipv4,rtcap,rt_8139too
> > > rtai_rtdm              22176  4 rtpacket,rtipv4,rt_8139too,rtnet
> > > rtai_shm                8832  0
> > > rtai_sem               17664  2 rtnet,rtai_rtdm
> > > rtai_lxrt              74904  7 rtipv4,rtcap,rt_8139too,rtnet,rtai_rtdm,rtai_shm,rtai_sem
> > > rtai_hal               69840  8 rtcap,rt_8139too,rtnet,rtai_rtdm,rtai_shm,rtai_sem,rtai_lxrt
> > > sis900                 19840  0
> > > 
> > > and the /proc/rtai/names file has the following:
> > > 
> > > RTAI LXRT Information.
> > > 
> > >     MAX_SLOTS = 150
> > > 
> > >                                          Linux_Owner         Parent PID
> > > Slot Name   ID         Type   RT_Handle    Pointer   Tsk_PID   MEM_Sz   USG Cnt
> > > -------------------------------------------------------------------------------
> > >  190 RTGLBF 0x9ac6d9e5 SHMEM  0xe09f1000 0x00000000        0    2097152       1
> > > tester1:/home/nfs_share/rtnet #    
> > > 
> > > it should have several semaphores and at least a task for rtnet.
> > > When i run the example that i send to you several days ago, just the sending part the file has
> > > tester1:/home/nfs_share/rtnet # cat /proc/rtai/names
> > > 
> > > RTAI LXRT Information.
> > > 
> > >     MAX_SLOTS = 150
> > > 
> > >                                          Linux_Owner         Parent PID
> > > Slot Name   ID         Type   RT_Handle    Pointer   Tsk_PID   MEM_Sz   USG Cnt
> > > -------------------------------------------------------------------------------
> > >  142 TASK1  0x042da6bf TASK   0xe09f2220 0x00000000        0      20179       1
> > >  190 RTGLBF 0x9ac6d9e5 SHMEM  0xe09f1000 0x00000000        0    2097152       1
> > > tester1:/home/nfs_share/rtnet #                                
> > > 
> > > only my task appears. 
> > > The receive part of the example blocks, and never return.
> > > I've already use some printk and the task manager code never run.
> > > 
> > > Maybe is something related with the RTAI task. I'm using RTAI-3.4 stable release.
> > > 
> > > Any clues????
> > 
> > Nope, specifically as I haven't changed anything related. I would
> > suggest to either vary the versions (older RTnet SVN that used to work,
> > older RTAI) or step into the rtdm_task creation of the stack manager.
> > Actually, that service should return some error code if anything went wrong.
> > 
> > Jan
> > 
> > 
> 
> -- 
> Jorge Almeida
> j-a...@cr...
> DISCLAIMER: This message may contain confidential information or privileged material and is intended only for the individual(s) named. If you are not a named addressee and mistakenly received this message you should not copy or otherwise disseminate it: please delete this e-mail from your system and notify the sender immediately. E-mail transmissions are not guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete or contain viruses. Therefore, the sender does not accept liability for any errors or omissions in the contents of this message that arise as a result of e-mail transmissions. Please request a hard copy version if verification is required. Critical Software, SA.
> 
> -------------------------------------------------------------------------
> 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
> 

-- 
Jorge Almeida
j-a...@cr...
DISCLAIMER: This message may contain confidential information or privileged material and is intended only for the individual(s) named. If you are not a named addressee and mistakenly received this message you should not copy or otherwise disseminate it: please delete this e-mail from your system and notify the sender immediately. E-mail transmissions are not guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete or contain viruses. Therefore, the sender does not accept liability for any errors or omissions in the contents of this message that arise as a result of e-mail transmissions. Please request a hard copy version if verification is required. Critical Software, SA.

Re: [RTnet-developers] ETH_P_ALL feature

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

Jorge Almeida wrote:
> Jan
>=20
> With the changes in the stack managersomething happen to the trask that=
 distribute the several messages.
> It is not started when i load rtnet.
>=20
> Me test machine has the following modules inserted:
> Module                  Size  Used by
> rtpacket                5120  0
> rtipv4                 21664  0
> rtcap                  16384  0
> rt_8139too             11904  6
> rtnet                  30092  4 rtpacket,rtipv4,rtcap,rt_8139too
> rtai_rtdm              22176  4 rtpacket,rtipv4,rt_8139too,rtnet
> rtai_shm                8832  0
> rtai_sem               17664  2 rtnet,rtai_rtdm
> rtai_lxrt              74904  7 rtipv4,rtcap,rt_8139too,rtnet,rtai_rtdm=
,rtai_shm,rtai_sem
> rtai_hal               69840  8 rtcap,rt_8139too,rtnet,rtai_rtdm,rtai_s=
hm,rtai_sem,rtai_lxrt
> sis900                 19840  0
>=20
> and the /proc/rtai/names file has the following:
>=20
> RTAI LXRT Information.
>=20
>     MAX_SLOTS =3D 150
>=20
>                                          Linux_Owner         Parent PID=

> Slot Name   ID         Type   RT_Handle    Pointer   Tsk_PID   MEM_Sz  =
 USG Cnt
> -----------------------------------------------------------------------=
--------
>  190 RTGLBF 0x9ac6d9e5 SHMEM  0xe09f1000 0x00000000        0    2097152=
       1
> tester1:/home/nfs_share/rtnet #   =20
>=20
> it should have several semaphores and at least a task for rtnet.
> When i run the example that i send to you several days ago, just the se=
nding part the file has
> tester1:/home/nfs_share/rtnet # cat /proc/rtai/names
>=20
> RTAI LXRT Information.
>=20
>     MAX_SLOTS =3D 150
>=20
>                                          Linux_Owner         Parent PID=

> Slot Name   ID         Type   RT_Handle    Pointer   Tsk_PID   MEM_Sz  =
 USG Cnt
> -----------------------------------------------------------------------=
--------
>  142 TASK1  0x042da6bf TASK   0xe09f2220 0x00000000        0      20179=
       1
>  190 RTGLBF 0x9ac6d9e5 SHMEM  0xe09f1000 0x00000000        0    2097152=
       1
> tester1:/home/nfs_share/rtnet #                               =20
>=20
> only my task appears.=20
> The receive part of the example blocks, and never return.
> I've already use some printk and the task manager code never run.
>=20
> Maybe is something related with the RTAI task. I'm using RTAI-3.4 stabl=
e release.
>=20
> Any clues????

Nope, specifically as I haven't changed anything related. I would
suggest to either vary the versions (older RTnet SVN that used to work,
older RTAI) or step into the rtdm_task creation of the stack manager.
Actually, that service should return some error code if anything went wro=
ng.

Jan

Re: [RTnet-developers] ETH_P_ALL feature

[Jorge A. <j-a...@cr...>]

Nothing appears in the messages file.

Tomorrow i will debug the problem and say something.

Jorge

Em Quinta, 28 de Setembro de 2006 19:20, o Jan Kiszka escreveu:
> Jorge Almeida wrote:
> > Jan
> > 
> > With the changes in the stack managersomething happen to the trask that distribute the several messages.
> > It is not started when i load rtnet.
> > 
> > Me test machine has the following modules inserted:
> > Module                  Size  Used by
> > rtpacket                5120  0
> > rtipv4                 21664  0
> > rtcap                  16384  0
> > rt_8139too             11904  6
> > rtnet                  30092  4 rtpacket,rtipv4,rtcap,rt_8139too
> > rtai_rtdm              22176  4 rtpacket,rtipv4,rt_8139too,rtnet
> > rtai_shm                8832  0
> > rtai_sem               17664  2 rtnet,rtai_rtdm
> > rtai_lxrt              74904  7 rtipv4,rtcap,rt_8139too,rtnet,rtai_rtdm,rtai_shm,rtai_sem
> > rtai_hal               69840  8 rtcap,rt_8139too,rtnet,rtai_rtdm,rtai_shm,rtai_sem,rtai_lxrt
> > sis900                 19840  0
> > 
> > and the /proc/rtai/names file has the following:
> > 
> > RTAI LXRT Information.
> > 
> >     MAX_SLOTS = 150
> > 
> >                                          Linux_Owner         Parent PID
> > Slot Name   ID         Type   RT_Handle    Pointer   Tsk_PID   MEM_Sz   USG Cnt
> > -------------------------------------------------------------------------------
> >  190 RTGLBF 0x9ac6d9e5 SHMEM  0xe09f1000 0x00000000        0    2097152       1
> > tester1:/home/nfs_share/rtnet #    
> > 
> > it should have several semaphores and at least a task for rtnet.
> > When i run the example that i send to you several days ago, just the sending part the file has
> > tester1:/home/nfs_share/rtnet # cat /proc/rtai/names
> > 
> > RTAI LXRT Information.
> > 
> >     MAX_SLOTS = 150
> > 
> >                                          Linux_Owner         Parent PID
> > Slot Name   ID         Type   RT_Handle    Pointer   Tsk_PID   MEM_Sz   USG Cnt
> > -------------------------------------------------------------------------------
> >  142 TASK1  0x042da6bf TASK   0xe09f2220 0x00000000        0      20179       1
> >  190 RTGLBF 0x9ac6d9e5 SHMEM  0xe09f1000 0x00000000        0    2097152       1
> > tester1:/home/nfs_share/rtnet #                                
> > 
> > only my task appears. 
> > The receive part of the example blocks, and never return.
> > I've already use some printk and the task manager code never run.
> > 
> > Maybe is something related with the RTAI task. I'm using RTAI-3.4 stable release.
> > 
> > Any clues????
> 
> Nope, specifically as I haven't changed anything related. I would
> suggest to either vary the versions (older RTnet SVN that used to work,
> older RTAI) or step into the rtdm_task creation of the stack manager.
> Actually, that service should return some error code if anything went wrong.
> 
> Jan
> 
> 

-- 
Jorge Almeida
j-a...@cr...
DISCLAIMER: This message may contain confidential information or privileged material and is intended only for the individual(s) named. If you are not a named addressee and mistakenly received this message you should not copy or otherwise disseminate it: please delete this e-mail from your system and notify the sender immediately. E-mail transmissions are not guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete or contain viruses. Therefore, the sender does not accept liability for any errors or omissions in the contents of this message that arise as a result of e-mail transmissions. Please request a hard copy version if verification is required. Critical Software, SA.

Re: [RTnet-developers] ETH_P_ALL feature

[Jorge A. <j-a...@cr...>]

Jan

With the changes in the stack managersomething happen to the trask that distribute the several messages.
It is not started when i load rtnet.

Me test machine has the following modules inserted:
Module                  Size  Used by
rtpacket                5120  0
rtipv4                 21664  0
rtcap                  16384  0
rt_8139too             11904  6
rtnet                  30092  4 rtpacket,rtipv4,rtcap,rt_8139too
rtai_rtdm              22176  4 rtpacket,rtipv4,rt_8139too,rtnet
rtai_shm                8832  0
rtai_sem               17664  2 rtnet,rtai_rtdm
rtai_lxrt              74904  7 rtipv4,rtcap,rt_8139too,rtnet,rtai_rtdm,rtai_shm,rtai_sem
rtai_hal               69840  8 rtcap,rt_8139too,rtnet,rtai_rtdm,rtai_shm,rtai_sem,rtai_lxrt
sis900                 19840  0

and the /proc/rtai/names file has the following:

RTAI LXRT Information.

    MAX_SLOTS = 150

                                         Linux_Owner         Parent PID
Slot Name   ID         Type   RT_Handle    Pointer   Tsk_PID   MEM_Sz   USG Cnt
-------------------------------------------------------------------------------
 190 RTGLBF 0x9ac6d9e5 SHMEM  0xe09f1000 0x00000000        0    2097152       1
tester1:/home/nfs_share/rtnet #    

it should have several semaphores and at least a task for rtnet.
When i run the example that i send to you several days ago, just the sending part the file has
tester1:/home/nfs_share/rtnet # cat /proc/rtai/names

RTAI LXRT Information.

    MAX_SLOTS = 150

                                         Linux_Owner         Parent PID
Slot Name   ID         Type   RT_Handle    Pointer   Tsk_PID   MEM_Sz   USG Cnt
-------------------------------------------------------------------------------
 142 TASK1  0x042da6bf TASK   0xe09f2220 0x00000000        0      20179       1
 190 RTGLBF 0x9ac6d9e5 SHMEM  0xe09f1000 0x00000000        0    2097152       1
tester1:/home/nfs_share/rtnet #                                

only my task appears. 
The receive part of the example blocks, and never return.
I've already use some printk and the task manager code never run.

Maybe is something related with the RTAI task. I'm using RTAI-3.4 stable release.

Any clues????

Jorge

Em Quinta, 28 de Setembro de 2006 18:24, o Jan Kiszka escreveu:
> Jorge Almeida wrote:
> > Did you do any test on that?
> 
> Yes, see examples/xenomai/posix.
> 
> > I try to run some of the old tests and the receive using SOCKET RAW and ETH_P_ALL does not work.
> > I will try to check waths going on.
> 
> Ok.
> 
> Jan
> 
> 

-- 
Jorge Almeida
j-a...@cr...
DISCLAIMER: This message may contain confidential information or privileged material and is intended only for the individual(s) named. If you are not a named addressee and mistakenly received this message you should not copy or otherwise disseminate it: please delete this e-mail from your system and notify the sender immediately. E-mail transmissions are not guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete or contain viruses. Therefore, the sender does not accept liability for any errors or omissions in the contents of this message that arise as a result of e-mail transmissions. Please request a hard copy version if verification is required. Critical Software, SA.

Re: [RTnet-developers] ETH_P_ALL feature

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

Jorge Almeida wrote:
> Did you do any test on that?

Yes, see examples/xenomai/posix.

> I try to run some of the old tests and the receive using SOCKET RAW and=
 ETH_P_ALL does not work.
> I will try to check waths going on.

Ok.

Jan

Re: [RTnet-developers] ETH_P_ALL feature

[Jorge A. <j-a...@cr...>]

Did you do any test on that?
I try to run some of the old tests and the receive using SOCKET RAW and ETH_P_ALL does not work.
I will try to check waths going on.

Thanks.


Em Quinta, 28 de Setembro de 2006 18:14, o Jan Kiszka escreveu:
> Jorge Almeida wrote:
> > Hello Jan
> > 
> > I update today my rtnet svn to start a stress test in the ETH_P_ALL feature but there are some code changes. 
> > I've already find that you are changing the things for the secind list, the one for the ETH_P_ALL sockets.
> > When do you think all the changes will be done?
> > after that i will do some tests to see the robustness of the framework.
> > I've already code it.
> > 
> > Please let me know when the job is finnished.
> > 
> 
> ETH_P_ALL is already finished - except for replacing rtskb_clone with
> some rtskb-sharing mechanism /some day/.
> 
> Go ahead with your tests!
> 
> Jan
> 
> 
> 
> 

-- 
Jorge Almeida
j-a...@cr...
DISCLAIMER: This message may contain confidential information or privileged material and is intended only for the individual(s) named. If you are not a named addressee and mistakenly received this message you should not copy or otherwise disseminate it: please delete this e-mail from your system and notify the sender immediately. E-mail transmissions are not guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete or contain viruses. Therefore, the sender does not accept liability for any errors or omissions in the contents of this message that arise as a result of e-mail transmissions. Please request a hard copy version if verification is required. Critical Software, SA.

Re: [RTnet-developers] ETH_P_ALL feature

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

Jorge Almeida wrote:
> Hello Jan
>=20
> I update today my rtnet svn to start a stress test in the ETH_P_ALL fea=
ture but there are some code changes.=20
> I've already find that you are changing the things for the secind list,=
 the one for the ETH_P_ALL sockets.
> When do you think all the changes will be done?
> after that i will do some tests to see the robustness of the framework.=

> I've already code it.
>=20
> Please let me know when the job is finnished.
>=20

ETH_P_ALL is already finished - except for replacing rtskb_clone with
some rtskb-sharing mechanism /some day/.

Go ahead with your tests!

Jan

[RTnet-developers] ETH_P_ALL feature

[Jorge A. <j-a...@cr...>]

Hello Jan

I update today my rtnet svn to start a stress test in the ETH_P_ALL feature but there are some code changes. 
I've already find that you are changing the things for the secind list, the one for the ETH_P_ALL sockets.
When do you think all the changes will be done?
after that i will do some tests to see the robustness of the framework.
I've already code it.

Please let me know when the job is finnished.

Thanks in advance.

-- 
Jorge Almeida
j-a...@cr...
DISCLAIMER: This message may contain confidential information or privileged material and is intended only for the individual(s) named. If you are not a named addressee and mistakenly received this message you should not copy or otherwise disseminate it: please delete this e-mail from your system and notify the sender immediately. E-mail transmissions are not guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete or contain viruses. Therefore, the sender does not accept liability for any errors or omissions in the contents of this message that arise as a result of e-mail transmissions. Please request a hard copy version if verification is required. Critical Software, SA.

Re: [RTnet-developers] Problem in SOCK_RAW

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

Jorge Almeida wrote:
> Hello to all,
>=20
> I'm testing the SOCK_RAW functionality in the rtnet framework for long =
periods of time and a problem is happening.
> I will try to describe it:
>=20
> I'm making tests sending 1.000.000 (one milion messages), with an inter=
val of 5 ms each.
> After some time, more than 100.000 messages, the host were the test is =
running has a strange behaviour, the program does not return but the bash=
 dies. I must make the login phase again to enter the host.
> The messages stop of being sent (I'm monitoring the network with ethere=
al).
>=20
> In the /proc i find some data about the file descriptor used by the soc=
ket (/proc/rtai/rtdm/open_fildes)
> Index   Locked   Device
> 0         0            PACKET_RAW
>=20
> I think this is OK because the socket was never closed.
>=20
> But the behaviour is strange.
> My guess is that this problem is due to some kind of semaphore or any s=
ynchronization mechanism.
>=20
>=20
> Any clues for wath is happening?
>=20

Problem fixed by #1073 (skb leak in rtcap).

Jan

Re: [RTnet-developers] Problem in SOCK_RAW

[Jorge A. <j-a...@cr...>]

Em Ter=C3=A7a, 19 de Setembro de 2006 18:14, o Jan Kiszka escreveu:
> Jorge Almeida wrote:
> > Em Ter=C3=A7a, 19 de Setembro de 2006 16:50, escreveu:
> >> Jorge Almeida wrote:
> >>> Hello to all,
> >>>
> >>> I'm testing the SOCK_RAW functionality in the rtnet framework for lon=
g periods of time and a problem is happening.
> >>> I will try to describe it:
> >>>
> >>> I'm making tests sending 1.000.000 (one milion messages), with an int=
erval of 5 ms each.
> >>> After some time, more than 100.000 messages, the host were the test i=
s running has a strange behaviour, the program does not return but the bash=
 dies. I must make the login phase again to enter the host.
> >>> The messages stop of being sent (I'm monitoring the network with ethe=
real).
> >>>
> >>> In the /proc i find some data about the file descriptor used by the s=
ocket (/proc/rtai/rtdm/open_fildes)
> >>> Index   Locked   Device
> >>> 0         0            PACKET_RAW
> >>>
> >>> I think this is OK because the socket was never closed.
> >> Because the sender somehow died I think. But why does the console also
> >> die? That's not a typical program error. Anything on the kernel consol=
e?
> >=20
> > In attach follows the messages file for one session where the problem h=
appens
>=20
> Ok, your job (+ its shell) got OOM-killed (terminated due to lacking
> memory). Is the test program allocating some memory in a loop? Unless it
> is a kernel leak (RTnet or even lower), the OOM-killer typically (not
> always) picks The Right process...

I'm not allocating memory in the loop.=20
Only local variables, inside function in the loop.

>=20
> >=20
> >>> But the behaviour is strange.
> >>> My guess is that this problem is due to some kind of semaphore or any=
 synchronization mechanism.
> >> The guess is based on which information?
> > Because it only happens in a very high number of messages and not in a =
small number. Maybe a variable that overflows or anything like that.
>=20
> dmesg tells some other story so far.

I can't get the right dmesg because it cleans at every reboot.
But the present results follows in attach.

>=20
> >>>
> >>> Any clues for wath is happening?
> >> Nope.
> >>
> >> If there are no signs anywhere, I would first try to run your scenario
> >> over a similar time using some vanilla RTnet version with normal packet
> >> sockets. Have you tried this before? Just to exclude that there are
> >> major stability issues.
> >=20
> > I've tested with SOCK_DGRAM two times, one OK the other the same proble=
m. I'm doing some more tests with SOCK_DGRAM.
>=20
> I think this is not related to latest changes. FWIW: that SOCK_DGRAM
> test took place over RTnet, say, 0.9.5 vanilla?
Nope. i'm using RTnet subversion.


>=20
> >=20
> >> BTW, you are on RTAI? What version, patch, gcc?
> > I'm using RTAI 3.4 test1, with gcc-4.1.0, with patch HAL IPIPE-NOTHREAD=
S 1.3-08
>=20
> I'm definitely no RTAI expert anymore, but the last time I tried it with
> gcc-4.1 (a few months ago) it also jumped out of the windows by just
> running the latency test for half an hour or so. I think I read on the
> RTAI list that gcc4.1 is not producing reliable RTAI code.
>=20
> >=20
> > I'm gonna try with rtai 3.4 now.
It also happens in RTAI 3.4.

I'm gonna send the messages file to the RTAI List also.

>=20
> I got flamed for such suggestions before, but to reduce the number of
> unknowns I would really recommend to run a similar setup over Xenomai
> (2.2.2 recommended for now due to pending FPU issues in 2.2.3). This can
> help to find out where we have to dig deeper for the problem.
>=20
> Jan
>=20
>=20

=2D-=20
Jorge Almeida
j-a...@cr...

DISCLAIMER: This message may contain confidential information or privileged=

 material and is intended only for the individual(s) named. If you are not a=

 named addressee and mistakenly received this message you should not copy or=

 otherwise disseminate it: please delete this e-mail from your system and no=

tify the sender immediately. E-mail transmissions are not guaranteed to be s=

ecure or error-free as information could be intercepted, corrupted, lost, de=

stroyed, arrive late or incomplete or contain viruses. Therefore, the sender=

 does not accept liability for any errors or omissions in the contents of th=

is message that arise as a result of e-mail transmissions. Please request a =

hard copy version if verification is required. Critical Software, SA.=0A

Re: [RTnet-developers] Problem in SOCK_RAW

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

Jorge Almeida wrote:
> Em Ter=E7a, 19 de Setembro de 2006 16:50, escreveu:
>> Jorge Almeida wrote:
>>> Hello to all,
>>>
>>> I'm testing the SOCK_RAW functionality in the rtnet framework for lon=
g periods of time and a problem is happening.
>>> I will try to describe it:
>>>
>>> I'm making tests sending 1.000.000 (one milion messages), with an int=
erval of 5 ms each.
>>> After some time, more than 100.000 messages, the host were the test i=
s running has a strange behaviour, the program does not return but the ba=
sh dies. I must make the login phase again to enter the host.
>>> The messages stop of being sent (I'm monitoring the network with ethe=
real).
>>>
>>> In the /proc i find some data about the file descriptor used by the s=
ocket (/proc/rtai/rtdm/open_fildes)
>>> Index   Locked   Device
>>> 0         0            PACKET_RAW
>>>
>>> I think this is OK because the socket was never closed.
>> Because the sender somehow died I think. But why does the console also=

>> die? That's not a typical program error. Anything on the kernel consol=
e?
>=20
> In attach follows the messages file for one session where the problem h=
appens

Ok, your job (+ its shell) got OOM-killed (terminated due to lacking
memory). Is the test program allocating some memory in a loop? Unless it
is a kernel leak (RTnet or even lower), the OOM-killer typically (not
always) picks The Right process...

>=20
>>> But the behaviour is strange.
>>> My guess is that this problem is due to some kind of semaphore or any=
 synchronization mechanism.
>> The guess is based on which information?
> Because it only happens in a very high number of messages and not in a =
small number. Maybe a variable that overflows or anything like that.

dmesg tells some other story so far.

>>>
>>> Any clues for wath is happening?
>> Nope.
>>
>> If there are no signs anywhere, I would first try to run your scenario=

>> over a similar time using some vanilla RTnet version with normal packe=
t
>> sockets. Have you tried this before? Just to exclude that there are
>> major stability issues.
>=20
> I've tested with SOCK_DGRAM two times, one OK the other the same proble=
m. I'm doing some more tests with SOCK_DGRAM.

I think this is not related to latest changes. FWIW: that SOCK_DGRAM
test took place over RTnet, say, 0.9.5 vanilla?

>=20
>> BTW, you are on RTAI? What version, patch, gcc?
> I'm using RTAI 3.4 test1, with gcc-4.1.0, with patch HAL IPIPE-NOTHREAD=
S 1.3-08

I'm definitely no RTAI expert anymore, but the last time I tried it with
gcc-4.1 (a few months ago) it also jumped out of the windows by just
running the latency test for half an hour or so. I think I read on the
RTAI list that gcc4.1 is not producing reliable RTAI code.

>=20
> I'm gonna try with rtai 3.4 now.

I got flamed for such suggestions before, but to reduce the number of
unknowns I would really recommend to run a similar setup over Xenomai
(2.2.2 recommended for now due to pending FPU issues in 2.2.3). This can
help to find out where we have to dig deeper for the problem.

Jan

Re: [RTnet-developers] Problem in SOCK_RAW

[Jorge A. <j-a...@cr...>]

Em Ter=C3=A7a, 19 de Setembro de 2006 16:50, escreveu:
> Jorge Almeida wrote:
> > Hello to all,
> >=20
> > I'm testing the SOCK_RAW functionality in the rtnet framework for long =
periods of time and a problem is happening.
> > I will try to describe it:
> >=20
> > I'm making tests sending 1.000.000 (one milion messages), with an inter=
val of 5 ms each.
> > After some time, more than 100.000 messages, the host were the test is =
running has a strange behaviour, the program does not return but the bash d=
ies. I must make the login phase again to enter the host.
> > The messages stop of being sent (I'm monitoring the network with ethere=
al).
> >=20
> > In the /proc i find some data about the file descriptor used by the soc=
ket (/proc/rtai/rtdm/open_fildes)
> > Index   Locked   Device
> > 0         0            PACKET_RAW
> >=20
> > I think this is OK because the socket was never closed.
>=20
> Because the sender somehow died I think. But why does the console also
> die? That's not a typical program error. Anything on the kernel console?

In attach follows the messages file for one session where the problem happe=
ns

>=20
> >=20
> > But the behaviour is strange.
> > My guess is that this problem is due to some kind of semaphore or any s=
ynchronization mechanism.
>=20
> The guess is based on which information?
Because it only happens in a very high number of messages and not in a smal=
l number. Maybe a variable that overflows or anything like that.
>=20
> >=20
> >=20
> > Any clues for wath is happening?
>=20
> Nope.
>=20
> If there are no signs anywhere, I would first try to run your scenario
> over a similar time using some vanilla RTnet version with normal packet
> sockets. Have you tried this before? Just to exclude that there are
> major stability issues.

I've tested with SOCK_DGRAM two times, one OK the other the same problem. I=
'm doing some more tests with SOCK_DGRAM.

>=20
> BTW, you are on RTAI? What version, patch, gcc?
I'm using RTAI 3.4 test1, with gcc-4.1.0, with patch HAL IPIPE-NOTHREADS 1.=
3-08

I'm gonna try with rtai 3.4 now.
>=20
> Jan
>=20
>=20

=2D-=20
Jorge Almeida
j-a...@cr...

DISCLAIMER: This message may contain confidential information or privileged=

 material and is intended only for the individual(s) named. If you are not a=

 named addressee and mistakenly received this message you should not copy or=

 otherwise disseminate it: please delete this e-mail from your system and no=

tify the sender immediately. E-mail transmissions are not guaranteed to be s=

ecure or error-free as information could be intercepted, corrupted, lost, de=

stroyed, arrive late or incomplete or contain viruses. Therefore, the sender=

 does not accept liability for any errors or omissions in the contents of th=

is message that arise as a result of e-mail transmissions. Please request a =

hard copy version if verification is required. Critical Software, SA.=0A