Re: [PATCH] USB: ftdi_sio: Remove tty->low_latency.

[Eric W. Biederman]

Alan Cox <alan@xxxxxxxxxxxxxxxxxxx> writes:

> On Fri, 02 Oct 2009 16:00:41 -0700
> ebiederm@xxxxxxxxxxxx (Eric W. Biederman) wrote:
>
>>
>>
>> I have seen a hang in:
>>   /bin/stty (changing the baud rate)
>>     set_termios
>>       tty_wait_until_sent
>>         tty_chars_in_buffer
>>           ftdi_chars_in_buffer
>>
>> Where the driver wedged for a serial port and no progress
>> was made.
>>
>> This happened to me several times with 2.6.31.  My initial
>> hypothesis was this was a hardware error (as it only happened
>> on single piece of hardware).  With all of the driver problems
>> I suspect it could be a driver bug.
>
> Driver bug I would think - or setup. If you've genuinely got the port
> flow controlled then a request to set the termios after the I/O will wait
> until a signal or carrier change (or indeed forever) quite correctly.

I have finally tracked this one down.  But I'm not certain if there is
anything we can do in software to make things better.

Boiled down.  ftdi_chars_in_buffer is essentially priv->tx_outstanding_bytes.
tx_outstanding_bytes is incremented when an urb request is sent and
tx_outstanding_bytes is decremented when an urb request completes.

It turns out I have a moderately noisy usb line, and so I occasionally
get messages like:

ehci_hcd 0000:00:0a.1: detected XactErr len 0/7 retry 31

Which as best as I can tell result in the urb getting abandoned and
neither completed nor canceled (because we have hit the maximum
retry count and they still don't succeed).

Which appears to result in tx_outstanding_bytes getting stuck at
some positive number.


Is it possible to handle this more gracefully in software?
Is it possible to handle this in a way that makes it clear there
was a hardware error that we could not recover from.  A little
debug level error doesn't usually even make it to the log.

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