After switching to 18.104.22.168 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...
Guennadi Liakhovetski, Ph.D.
DSA Daten- und Systemtechnik GmbH