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 [EMAIL PROTECTED]
>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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
