2.6.18-rt6 IrDA strangeness

2.6.18-rt6 IrDA strangeness

[Guennadi Liakhovetski]

Hi

Ok, the kernel is a bit old, but maybe someone has an idea... Running ppp 
over irnet, one side with the above kernel, another is a verified 
reference system. The following strange fenomena are observed:

1. irdadump on the 2.6.18-rt6 side shows only incoming packets
2. sometimes, especially after a connection break down, the connection is 
re-established, but the reference side has empty /proc/net/irda/discovery, 
the reason being a couple of missing packets during re-negotiation:

15:06:43.854376 xid:cmd c62da07d > ffffffff S=6 s=0 (14)
15:06:43.944244 xid:cmd c62da07d > ffffffff S=6 s=1 (14)
15:06:44.034244 xid:cmd c62da07d > ffffffff S=6 s=2 (14)
15:06:44.124245 xid:cmd c62da07d > ffffffff S=6 s=3 (14)
15:06:44.214281 xid:cmd c62da07d > ffffffff S=6 s=4 (14)
15:06:44.304289 xid:cmd c62da07d > ffffffff S=6 s=5 (14)
15:06:44.394282 xid:cmd c62da07d > ffffffff S=6 s=* TESTNODE hint=4400 [ Computer LAN Access ] (25)

15:06:46.864376 xid:cmd c62da07d > ffffffff S=6 s=0 (14)
15:06:46.954286 xid:cmd c62da07d > ffffffff S=6 s=1 (14)
15:06:47.044280 xid:cmd c62da07d > ffffffff S=6 s=2 (14)
15:06:47.134293 xid:cmd c62da07d > ffffffff S=6 s=3 (14)
15:06:47.224281 xid:cmd c62da07d > ffffffff S=6 s=4 (14)
15:06:47.314250 xid:cmd c62da07d > ffffffff S=6 s=5 (14)
15:06:47.404249 xid:cmd c62da07d > ffffffff S=6 s=* TESTNODE hint=4400 [ Computer LAN Access ] (25)

15:06:49.391225 snrm:cmd ca=fe pf=1 c62da07d < 0ad5eb46 new-ca=58 (33)
15:06:49.391389 ua:rsp ca=58 pf=1 c62da07d > 0ad5eb46 (32)
15:06:49.448100 rr:cmd < ca=58 pf=1 nr=0 (2)
15:06:49.448172 rr:rsp > ca=58 pf=1 nr=0 (2)
15:06:49.450636 i:cmd  < ca=58 pf=1 nr=0 ns=0 LM slsap=16 dlsap=00 CONN_CMD (6)
15:06:49.450817 i:rsp  > ca=58 pf=1 nr=1 ns=0 LM slsap=00 dlsap=16 CONN_RSP (6)

I.e., we see 2 discovery packets from TESTNODE, and then the 2.6.18-rt6 
host sends directly an SNRM packet without presenting itself first with 
its nick... Looks like some timers are confused through highres timers?...

Thanks
Guennadi
---------------------------------
Guennadi Liakhovetski, Ph.D.
DSA Daten- und Systemtechnik GmbH
Pascalstr. 28
D-52076 Aachen
Germany

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

Re: [irda-users] 2.6.18-rt6 IrDA strangeness

[Guennadi Liakhovetski]

Added Thomas to CC: as it is a PXA270 CPU and it looks like the kernel has 
some other peculiarities that the no-rt one doesn't have. In principle, 
the kernel runs fine, many various hardware drivers, realtime threads. 
But, I just noticed, klogd doesn't get woken up from printk(). I.e., 
syslog(2) doesn't work right. If you wake it up somehow, say, with a kill 
-CONT, you get buffers out of the kernel.

Thomas, is it something known and (hopefully) fixed in newer kernels, or 
something unknown?

Below is the original Ir problem with this kernel.

Thanks
Guennadi

On Fri, 2 Mar 2007, Guennadi Liakhovetski wrote:

> Ok, the kernel is a bit old, but maybe someone has an idea... Running ppp
> over irnet, one side with the above kernel, another is a verified
> reference system. The following strange fenomena are observed:
>
> 1. irdadump on the 2.6.18-rt6 side shows only incoming packets
> 2. sometimes, especially after a connection break down, the connection is
> re-established, but the reference side has empty /proc/net/irda/discovery,
> the reason being a couple of missing packets during re-negotiation:
>
> 15:06:43.854376 xid:cmd c62da07d > ffffffff S=6 s=0 (14)
> 15:06:43.944244 xid:cmd c62da07d > ffffffff S=6 s=1 (14)
> 15:06:44.034244 xid:cmd c62da07d > ffffffff S=6 s=2 (14)
> 15:06:44.124245 xid:cmd c62da07d > ffffffff S=6 s=3 (14)
> 15:06:44.214281 xid:cmd c62da07d > ffffffff S=6 s=4 (14)
> 15:06:44.304289 xid:cmd c62da07d > ffffffff S=6 s=5 (14)
> 15:06:44.394282 xid:cmd c62da07d > ffffffff S=6 s=* TESTNODE hint=4400 [ Computer LAN Access ] (25)
>
> 15:06:46.864376 xid:cmd c62da07d > ffffffff S=6 s=0 (14)
> 15:06:46.954286 xid:cmd c62da07d > ffffffff S=6 s=1 (14)
> 15:06:47.044280 xid:cmd c62da07d > ffffffff S=6 s=2 (14)
> 15:06:47.134293 xid:cmd c62da07d > ffffffff S=6 s=3 (14)
> 15:06:47.224281 xid:cmd c62da07d > ffffffff S=6 s=4 (14)
> 15:06:47.314250 xid:cmd c62da07d > ffffffff S=6 s=5 (14)
> 15:06:47.404249 xid:cmd c62da07d > ffffffff S=6 s=* TESTNODE hint=4400 [ Computer LAN Access ] (25)
>
> 15:06:49.391225 snrm:cmd ca=fe pf=1 c62da07d < 0ad5eb46 new-ca=58 (33)
> 15:06:49.391389 ua:rsp ca=58 pf=1 c62da07d > 0ad5eb46 (32)
> 15:06:49.448100 rr:cmd < ca=58 pf=1 nr=0 (2)
> 15:06:49.448172 rr:rsp > ca=58 pf=1 nr=0 (2)
> 15:06:49.450636 i:cmd  < ca=58 pf=1 nr=0 ns=0 LM slsap=16 dlsap=00 CONN_CMD (6)
> 15:06:49.450817 i:rsp  > ca=58 pf=1 nr=1 ns=0 LM slsap=00 dlsap=16 CONN_RSP (6)
>
> I.e., we see 2 discovery packets from TESTNODE, and then the 2.6.18-rt6
> host sends directly an SNRM packet without presenting itself first with
> its nick... Looks like some timers are confused through highres timers?...

---------------------------------
Guennadi Liakhovetski, Ph.D.
DSA Daten- und Systemtechnik GmbH
Pascalstr. 28
D-52076 Aachen
Germany

Re: [irda-users] 2.6.18-rt6 IrDA strangeness

[Guennadi Liakhovetski]

Ok, just tried 20-rt8. Of 3 problems described earlier the first two: 
non-working syslog(2) and irdadump showing packets only in one direction 
are now gone. Whereas the third one:

On Fri, 2 Mar 2007, Guennadi Liakhovetski wrote:

>> 2. sometimes, especially after a connection break down, the connection is
>> re-established, but the reference side has empty /proc/net/irda/discovery,
>> the reason being a couple of missing packets during re-negotiation:
>> 
>> 15:06:43.854376 xid:cmd c62da07d > ffffffff S=6 s=0 (14)
>> 15:06:43.944244 xid:cmd c62da07d > ffffffff S=6 s=1 (14)
>> 15:06:44.034244 xid:cmd c62da07d > ffffffff S=6 s=2 (14)
>> 15:06:44.124245 xid:cmd c62da07d > ffffffff S=6 s=3 (14)
>> 15:06:44.214281 xid:cmd c62da07d > ffffffff S=6 s=4 (14)
>> 15:06:44.304289 xid:cmd c62da07d > ffffffff S=6 s=5 (14)
>> 15:06:44.394282 xid:cmd c62da07d > ffffffff S=6 s=* TESTNODE hint=4400 [ Computer LAN Access ] (25)
>> 
>> 15:06:46.864376 xid:cmd c62da07d > ffffffff S=6 s=0 (14)
>> 15:06:46.954286 xid:cmd c62da07d > ffffffff S=6 s=1 (14)
>> 15:06:47.044280 xid:cmd c62da07d > ffffffff S=6 s=2 (14)
>> 15:06:47.134293 xid:cmd c62da07d > ffffffff S=6 s=3 (14)
>> 15:06:47.224281 xid:cmd c62da07d > ffffffff S=6 s=4 (14)
>> 15:06:47.314250 xid:cmd c62da07d > ffffffff S=6 s=5 (14)
>> 15:06:47.404249 xid:cmd c62da07d > ffffffff S=6 s=* TESTNODE hint=4400 [ Computer LAN Access ] (25)
>> 
>> 15:06:49.391225 snrm:cmd ca=fe pf=1 c62da07d < 0ad5eb46 new-ca=58 (33)
>> 15:06:49.391389 ua:rsp ca=58 pf=1 c62da07d > 0ad5eb46 (32)
>> 15:06:49.448100 rr:cmd < ca=58 pf=1 nr=0 (2)
>> 15:06:49.448172 rr:rsp > ca=58 pf=1 nr=0 (2)
>> 15:06:49.450636 i:cmd  < ca=58 pf=1 nr=0 ns=0 LM slsap=16 dlsap=00 CONN_CMD (6)
>> 15:06:49.450817 i:rsp  > ca=58 pf=1 nr=1 ns=0 LM slsap=00 dlsap=16 CONN_RSP (6)
>> 
>> I.e., we see 2 discovery packets from TESTNODE, and then the 2.6.18-rt6
>> host sends directly an SNRM packet without presenting itself first with
>> its nick... Looks like some timers are confused through highres timers?...

is still there.

Thanks
Guennadi
---------------------------------
Guennadi Liakhovetski, Ph.D.
DSA Daten- und Systemtechnik GmbH
Pascalstr. 28
D-52076 Aachen
Germany

Re: [irda-users] 2.6.18-rt6 IrDA strangeness

[Guennadi Liakhovetski]

On Tue, 6 Mar 2007, Guennadi Liakhovetski wrote:

> Ok, just tried 20-rt8. Of 3 problems described earlier the first two:
> non-working syslog(2) and irdadump showing packets only in one direction
> are now gone. Whereas the third one:

[...]

> is still there.

Ok, I also managed to reproduce this with non-rt kernel, so, it's just 
some incompatibility between 2.4 and 2.6... Might be considered as a nug 
on the 2.4 "reference" side.

Thanks
Guennadi
---------------------------------
Guennadi Liakhovetski, Ph.D.
DSA Daten- und Systemtechnik GmbH
Pascalstr. 28
D-52076 Aachen
Germany

Re: 2.6.18-rt6 IrDA strangeness

[Samuel Ortiz]

On 3/6/2007, "Guennadi Liakhovetski" <gl-o/hVf8ie6tKzQB+pC5nmwQ@public.gmane.org> wrote:

>On Tue, 6 Mar 2007, Guennadi Liakhovetski wrote:
>
>> Ok, just tried 20-rt8. Of 3 problems described earlier the first two:
>> non-working syslog(2) and irdadump showing packets only in one direction
>> are now gone. Whereas the third one:
>
>[...]
>
>> is still there.
>
>Ok, I also managed to reproduce this with non-rt kernel, so, it's just
>some incompatibility between 2.4 and 2.6... Might be considered as a nug
>on the 2.4 "reference" side.
If you don't see the problem with two 2.6 peers, then it's definitely a
2.4 bug...Have you tried that ?

Cheers,
Samuel.

>
>Thanks
>Guennadi
>---------------------------------
>Guennadi Liakhovetski, Ph.D.
>DSA Daten- und Systemtechnik GmbH
>Pascalstr. 28
>D-52076 Aachen
>Germany
>
>-------------------------------------------------------------------------
>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
>_______________________________________________
>irda-users mailing list
>irda-users-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
>http://lists.sourceforge.net/lists/listinfo/irda-users

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

Re: [irda-users] 2.6.18-rt6 IrDA strangeness

[Guennadi Liakhovetski]

(I think, we can remove Thomas and linux-rt-users from CC: now that it's 
clearly not a -rt bug, unless they express their interest in this 
thread:-))

On Tue, 6 Mar 2007, Samuel Ortiz wrote:

> On 3/6/2007, "Guennadi Liakhovetski" <gl@dsa-ac.de> wrote:
>
>> On Tue, 6 Mar 2007, Guennadi Liakhovetski wrote:
>>
>> Ok, I also managed to reproduce this with non-rt kernel, so, it's just
>> some incompatibility between 2.4 and 2.6... Might be considered as a nug
>> on the 2.4 "reference" side.
>
> If you don't see the problem with two 2.6 peers, then it's definitely a
> 2.4 bug...Have you tried that ?

No, not yet. As soon as I get a chance, will verify that.

Thanks
Guennadi
---------------------------------
Guennadi Liakhovetski, Ph.D.
DSA Daten- und Systemtechnik GmbH
Pascalstr. 28
D-52076 Aachen
Germany