Re: [irda-users] no discovery with MA620 on 2.6.3

[Martin D. <li...@md...>]

On Thu, 4 Mar 2004, Thanos Kyritsis wrote:

> > > Arghh - while trying to follow this I just realized the pl2303 is
> > > DMA'ing to the stack - not good!
> > > Could you please just try with the patch below. I'm not sure if
> > > this might cause the MA620 trouble but it's definedly a bug and
> > > maybe it improves things for you...
> >
> > No change in behaviour with the patch for me.
> 
> Didn't change anything for me, either.

Ok, not much surprise it didn't help. This bug in the pl2303 was only when 
reading some registers from the pl2303 - so while it could theoretically 
corrupt system memory it's hard to imagine how this might cause the dongle 
to report framing errors.

Anyway, now thanks to the usbsnoop-logs we have some more information and 
it turned out the driver for other OS isn't using the interrupt endpoint 
to read the line status at all. So it would never even get those framing 
errors communicated.

I've just tried with my pl2303 simply ignoring them. Before, it worked for 
me for some 10-30 minuts and then all of the sudden started to report 
framing errors without end. Now ignoring them the whole setup just 
continues to work in this situation. There are just one or two checksum 
errors detected in the irda frame.

So my preliminary conclusion is, there was a real framing error but 
thereafter anything was fine. The pl2303 however continued reporting 
framing error. Either some hardware issue or the pl2303 driver is expected 
to acknowledge them somehow.

While I believe this should be fixed in the pl2303 driver (either ack the 
FE or ignore them, if the hardware is busted), with irda there should be a 
simple solution: ignore them at this level.

People with MA620, could you please try if the patch below changes 
anything for you! I'm not sure if the failure after some time which I see 
is the same what makes your ma620 not working, but there is good reason to 
try this first, before looking at the irda-specific details.

With this patch irtty ignores the error flags on received data and 
unconditionally forwards it for unwrapping the irlap frame. I've also 
added some rate limiting there to avoid filling the logs with tons of 
error messages.

Martin

------------------

--- linux-2.6.3-bk9/drivers/net/irda/irtty-sir.c	Sat Feb 28 09:51:00 2004
+++ v2.6.3-bk9-md/drivers/net/irda/irtty-sir.c	Fri Mar  5 18:13:53 2004
@@ -270,6 +270,7 @@ static void irtty_receive_buf(struct tty
 
 	dev = priv->dev;
 	if (!dev) {
+		/* start race - msg not ratelimited */
 		WARNING("%s(), not ready yet!\n", __FUNCTION__);
 		return;
 	}
@@ -279,9 +280,22 @@ static void irtty_receive_buf(struct tty
 		 *  Characters received with a parity error, etc?
 		 */
  		if (fp && *fp++) { 
-			IRDA_DEBUG(0, "Framing or parity error!\n");
+			if (net_ratelimit())
+				IRDA_DEBUG(0, "Framing or parity error!\n");
+#if 0
+	/* it seems pl2303-based usbserial configurations including MA620
+	 * have some tendency to fail due to tons of framing errors
+	 * reported when actually there are none (or only a few?)
+	 * Disable error check for now to see how it behaves.
+	 * Note: Despite this does also disable the error detection
+	 * for well-behaving devices, it's not a serious problem because
+	 * irda frames are checksummed anyway. Of course, if there is
+	 * really a false-positive issue with pl2303, it would be
+	 * prefereable to correct or disable the frame errors there...
+	 */
 			sirdev_receive(dev, NULL, 0);	/* notify sir_dev (updating stats) */
 			return;
+#endif
  		}
 	}
 
--- linux-2.6.3-bk9/drivers/net/irda/sir_dev.c	Sat Feb 28 09:51:00 2004
+++ v2.6.3-bk9-md/drivers/net/irda/sir_dev.c	Fri Mar  5 18:39:23 2004
@@ -234,6 +234,9 @@ void sirdev_write_complete(struct sir_de
 
 int sirdev_receive(struct sir_dev *dev, const unsigned char *cp, size_t count) 
 {
+	/* sanity checks, if they bite it indicates races in the
+	 * sir_dev start sequence - msg not ratelimited!
+	 */
 	if (!dev || !dev->netdev) {
 		WARNING("%s(), not ready yet!\n", __FUNCTION__);
 		return -1;
@@ -250,7 +253,8 @@ int sirdev_receive(struct sir_dev *dev, 
 		 */
 		irda_device_set_media_busy(dev->netdev, TRUE);
 		dev->stats.rx_dropped++;
-		IRDA_DEBUG(0, "%s; rx-drop: %d\n", __FUNCTION__, count);
+		if (net_ratelimit())
+			IRDA_DEBUG(0, "%s; rx-drop: %d\n", __FUNCTION__, count);
 		return 0;
 	}