headers
Guennadi Liakhovetski | 2 Mar 2007 15:11
Picon
Favicon

2.6.18-rt6 IrDA strangeness

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)
(Continue reading)

Permalink | Reply | 10 comments |
headers
Guennadi Liakhovetski | 2 Mar 2007 17:49
Picon
Favicon

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

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)
(Continue reading)

Permalink | Reply | 8 comments |
headers
Guennadi Liakhovetski | 6 Mar 2007 09:53
Picon
Favicon

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

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)
(Continue reading)

Permalink | Reply | 6 comments |
headers
Guennadi Liakhovetski | 6 Mar 2007 15:05
Picon
Favicon

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

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
Permalink | Reply | 4 comments |
headers
Guennadi Liakhovetski | 6 Mar 2007 15:37
Picon
Favicon

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

(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 <at> 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
Permalink | Reply | 0 comments |
headers
Samuel Ortiz | 6 Mar 2007 15:22

Re: 2.6.18-rt6 IrDA strangeness


On 3/6/2007, "Guennadi Liakhovetski" <gl@...> 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
(Continue reading)

Permalink | Reply | 1 comment |
headers
Guennadi Liakhovetski | 8 Mar 2007 10:34
Picon
Favicon

fast IrDA on PXA270 - more problems

Hi again

After switching to 2.6.20.1 I still experience a few problems with fast 
IrDA on PXA270. The first one that I'm tracing atm is, that in an 
endurance test with cyclically breaking and restoring the visibility link 
approx. every 8 sec with irnet and ppp at some point it comes to a state 
where no further communication is possible.

At this moment IrLAP thinks it has lost the connection and switched back 
to 9600, as seen in /proc/net/irda/irlap. Whereas the low layer pxaficp_ir 
driver still communicates in fast Ir mode. This happens as a change_speed 
skb from irlap_change_speed() doesn't reach the pxa driver because the 
network queue is stopped.

The only place I see where netif_stop_queue() is called is from the pxa 
driver after submitting a buffer to the controller and while waiting for 
the DMA done interrupt. Then the queue is woken up. It is, of course, 
possible that the change_speed skb is submitted at this time, but it 
should be delivered when DMA done interrupt comes?

Notice, that so far I've been testing with the -rt (rt-preempt) kernel, 
will try without it next. As you know, ISRs run as kernel threads under 
-rt kernels, so, there might be issues there with DMA interrupts... But 
why does it only happen to change_speed skbs?

Last night I started the test with debugging and irdadump in parallel and 
some udp communication over irda-ppp. Then I've got messages "Neighbour 
table overflow." from net/ipv4/route.c when attempting any network 
communication over any network, which seems to indicate full and 
un-freeable arp table... Although /proc/net/arp contains only 1 entry...
(Continue reading)

Permalink | Reply | 0 comments |
headers
Samuel Ortiz | 14 Mar 2007 20:22

[PATCH 0/6] IrDA: Updates

Hi Dave,

Some IrDA updates:

- IrNET identation and bug fix. (patches 1 and 2)
- IrLAP raw mode initial implementation. (patch 3)
- stir4200 and irda-usb fixes. (patches 4 and 5)
- hashbin lockdep fixes. (patch 6)

Cheers,
Samuel.

-------------------------------------------------------------------------
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
Permalink | Reply | 8 comments |
headers
Samuel Ortiz | 14 Mar 2007 20:23

[PATCH 2/6] IrDA: Process context ppp_unregister_channel() call

We need to call ppp_unregister_channel() when IrNET disconnects, and this
must be done from a process context.
This patch applies on top of "[PATCH 1/7] IrDA: IrNET code indentation".
Also, this is a bug fix, certainly not a critical one. Should I forward it to
stable@... though ?

Patch tested by Guennadi Liakhovetski.

Reported-by: Guennadi Liakhovetski <gl@...>
Signed-off-by: Samuel Ortiz <samuel@...>
---
 net/irda/irnet/irnet.h      |    1 +
 net/irda/irnet/irnet_irda.c |   37 +++++++++++++++++++++++++------------
 2 files changed, 26 insertions(+), 12 deletions(-)

diff --git a/net/irda/irnet/irnet.h b/net/irda/irnet/irnet.h
index 44b58a6..ec1a2a8 100644
--- a/net/irda/irnet/irnet.h
+++ b/net/irda/irnet/irnet.h
 <at>  <at>  -418,6 +418,7  <at>  <at>  typedef struct irnet_socket {
 	u32 raccm;		/* to please pppd - dummy) */
 	unsigned int flags;	/* PPP flags (compression, ...) */
 	unsigned int rbits;	/* Unused receive flags ??? */
+	struct work_struct disconnect_work; /* Process context disconnection */

 	/* ------------------------ IrTTP part ------------------------ */
 	/* We create a pseudo "socket" over the IrDA tranport */
diff --git a/net/irda/irnet/irnet_irda.c b/net/irda/irnet/irnet_irda.c
index 843b767..0f462a9 100644
--- a/net/irda/irnet/irnet_irda.c
(Continue reading)

Permalink | Reply | 0 comments |
headers
Samuel Ortiz | 14 Mar 2007 20:23

[PATCH 3/6] IrDA: IrLAP raw mode

This patch allows us to bypass the IrDA stack down to the IrLAP level.
Sending and receiving frames is done through a character device.
This is useful for e.g. doing real IrDA sniffing, testing external IrDA
stacks and for Lirc (once I will add the framing disabling switch).

Signed-off-by: Samuel Ortiz <samuel@...>
---
 include/net/irda/irlap.h     |    5 +
 include/net/irda/irlap_raw.h |   27 +++
 net/irda/Kconfig             |   10 ++
 net/irda/Makefile            |    1 +
 net/irda/irlap.c             |    5 +
 net/irda/irlap_event.c       |    5 +
 net/irda/irlap_frame.c       |    6 +
 net/irda/irlap_raw.c         |  358 ++++++++++++++++++++++++++++++++++++++++++
 net/irda/irsysctl.c          |   16 ++-
 9 files changed, 432 insertions(+), 1 deletions(-)
 create mode 100644 include/net/irda/irlap_raw.h
 create mode 100644 net/irda/irlap_raw.c

diff --git a/include/net/irda/irlap.h b/include/net/irda/irlap.h
index e77eb88..1b24cfc 100644
--- a/include/net/irda/irlap.h
+++ b/include/net/irda/irlap.h
 <at>  <at>  -36,6 +36,7  <at>  <at> 
 #include <net/irda/qos.h>		/* struct qos_info */
 #include <net/irda/discovery.h>		/* discovery_t */
 #include <net/irda/irlap_event.h>	/* IRLAP_STATE, ... */
+#include <net/irda/irlap_raw.h>	        /* IRLAP raw definitions */
 #include <net/irda/irmod.h>		/* struct notify_t */
(Continue reading)

Permalink | Reply | 4 comments |

Gmane