Re: [SOLVED] Serial buffer corruption [was Re: FTDI usb-serial possible bug]

[Gene Heskett <gene.heskett@gmail.com>]

On Saturday 05 May 2007, Oliver Neukum wrote:
>Am Samstag, 5. Mai 2007 20:08 schrieb Antonino Ingargiola:
>> Now I don't want to abuse your kindness, but I (personally) would be
>> *really* interested in a similar fix for the FTDI usb-serial driver,
>> because many measurements I do use an FTDI device.
>
>Does this work?
>
>	Regards
>		Oliver
>----
>
>--- a/drivers/usb/serial/ftdi_sio.c	2007-05-05 20:21:41.000000000 +0200
>+++ b/drivers/usb/serial/ftdi_sio.c	2007-05-05 20:27:09.000000000 +0200
>@@ -1749,10 +1749,6 @@ static void ftdi_process_read (struct wo
> 			length = 0;
> 		}
>
>-		if (priv->rx_flags & THROTTLED) {
>-			dbg("%s - throttled", __FUNCTION__);
>-			break;
>-		}
> 		if (tty_buffer_request_room(tty, length) < length) {
> 			/* break out & wait for throttling/unthrottling to happen */
> 			dbg("%s - receive room low", __FUNCTION__);
>@@ -1825,16 +1821,6 @@ static void ftdi_process_read (struct wo
> 		dbg("%s - incomplete, %d bytes processed, %d remain",
> 				__FUNCTION__, packet_offset,
> 				urb->actual_length - packet_offset);
>-		/* check if we were throttled while processing */
>-		spin_lock_irqsave(&priv->rx_lock, flags);
>-		if (priv->rx_flags & THROTTLED) {
>-			priv->rx_flags |= ACTUALLY_THROTTLED;
>-			spin_unlock_irqrestore(&priv->rx_lock, flags);
>-			dbg("%s - deferring remainder until unthrottled",
>-					__FUNCTION__);
>-			return;
>-		}
>-		spin_unlock_irqrestore(&priv->rx_lock, flags);
> 		/* if the port is closed stop trying to read */
> 		if (port->open_count > 0){
> 			/* delay processing of remainder */
>@@ -1856,9 +1842,15 @@ static void ftdi_process_read (struct wo
> 			      port->read_urb->transfer_buffer,
> port->read_urb->transfer_buffer_length, ftdi_read_bulk_callback, port);
>
>-		result = usb_submit_urb(port->read_urb, GFP_ATOMIC);
>-		if (result)
>-			err("%s - failed resubmitting read urb, error %d", __FUNCTION__,
> result); +		spin_lock_irqsave(&priv->rx_lock, flags);
>+		if (priv->rx_flags & THROTTLED) {
>+			priv->rx_flags |= ACTUALLY_THROTTLED;
>+		} else {
>+			result = usb_submit_urb(port->read_urb, GFP_ATOMIC);
>+			if (result)
>+				err("%s - failed resubmitting read urb, error %d", __FUNCTION__,
> result); +		}
>+		spin_unlock_irqrestore(&priv->rx_lock, flags);
> 	}
>
> 	return;
>-
Oliver:

While running kernel-2.6.21.1-sd-0.48 + this and the other patch I mentioned,

Unforch, this patch doesn't seem to have effected my usb-serial problems, for 
upsd anyway, it's running at 47% of the cpu right now, while running sd-0.48.

Occasionally a stop and restart will fix it...  Nope.  On the restart, its 
about 3% _until_ something starts reading its output data file, which could 
be gkrellmBUPS, or its own gui, either one bounces it back up to 45+% of the 
cpu.  On a kernel where it works sorta right, as in a recent fedora kernel, 
its about 1.5%, and on even older 2.6.18ish stuff, this utility ran at .1% of 
the cpu regardless of who read its output data.  But that was with a pl2303 
adapter, which no longer works at all so I bought some ftdi based ones.

So the next boot will be to cfs-v10 + these.



>To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>the body of a message to majordomo@vger.kernel.org
>More majordomo info at  http://vger.kernel.org/majordomo-info.html
>Please read the FAQ at  http://www.tux.org/lkml/



-- 
Cheers, Gene
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
For certain people, after fifty, litigation takes the place of sex.
		-- Gore Vidal