Fwd: Bug in USB FTDI SIO driver

Fwd: Bug in USB FTDI SIO driver

[peter.sheeren]

[-- Attachment #1: Type: text/plain, Size: 138 bytes --]

Hello

At the suggestion of Greg's friendly e-mail bot I'm sending my report  
to this e-mail address. I hope it's the right one.

Peter


[-- Attachment #2: Forwarded Message: Bug in USB FTDI SIO driver --]
[-- Type: message/rfc822, Size: 2759 bytes --]

From: peter.sheeren@axiris.be
To: jhovold@gmail.com, greg@kroah.com
Subject: Bug in USB FTDI SIO driver
Date: Sat, 08 Sep 2012 04:21:06 +0200
Message-ID: <20120908042106.60247e3thepx3q1e@webmail.axiris.be>


Hello

I didn't find an easy way to file a bug report so I extracted the  
source file ftdi_sio.c from the latest Linux kernel and browsed for  
the e-mail addresses hence this e-mail.

I've been struggling with an annoying plug-and-play issue involving an  
FT232RL-based USB device on ARM machines with Linux lately (including  
Raspberry Pi and BeagleBoard). In a nutshell the following is happening:
* I plug in the FT232RL-based USB device. /dev/ttyUSB0 is created.
* I run an application that communicate with the device via  
/dev/ttyUSB0. The application sets a baudrate - this is important. The  
application reads and writes data successfully.
* I unplug the USB device. /dev/ttyUSB0 remains in existence - this is  
important too.
* I replug the USB device. /dev/ttyUSB0 is still there.
* I rerun the application. The application again connects with  
/dev/ttyUSB0 but it fails to transfer data. So it seems.

I ran I number of tests with a small program on my ARM based systems  
and I discovered that the culprit is setting the baudrate. It turns  
out that, after replugging the USB device, setting the baudrate is not  
relayed to the USB device.

Since this looks like a caching problem, I tracked down the  
corresponding source code in ftdi_sio.c and I'm confident the  
following text is the cause of the problem:

(line 1375)

	if (((old_priv.flags & ASYNC_SPD_MASK) !=
	     (priv->flags & ASYNC_SPD_MASK)) ||
	    (((priv->flags & ASYNC_SPD_MASK) == ASYNC_SPD_CUST) &&
	     (old_priv.custom_divisor != priv->custom_divisor))) {
		change_speed(tty, port);

Function change_speed() is called only when the baudrate  
(custom_divisor) has changed but after a USB replug this assumption is  
wrong. Also note that /dev/ttyUSB0 remains in existence on the system  
under test. If it were up to me, I'd always send the baudrate setting  
over the USB bus nomatter whether the baudrate (supposedly) has  
changed or not.

I found a workaround for this bug: my software sets a different  
baudrate prior to the intended baudrate hence fooling the ftdi_sio.c  
code but ofcourse it's a workaround.

I hope this report will help you improve your driver.

Best regards,

Peter S'heeren
http://www.axiris.be/

Re: Fwd: Bug in USB FTDI SIO driver

[Greg KH]

On Sat, Sep 08, 2012 at 12:14:39PM +0200, peter.sheeren@axiris.be wrote:
> Hello
> 
> At the suggestion of Greg's friendly e-mail bot I'm sending my
> report to this e-mail address. I hope it's the right one.
> 
> Peter
> 

> Date: Sat, 08 Sep 2012 04:21:06 +0200
> From: peter.sheeren@axiris.be
> To: jhovold@gmail.com, greg@kroah.com
> Subject: Bug in USB FTDI SIO driver
> 
> 
> Hello
> 
> I didn't find an easy way to file a bug report so I extracted the
> source file ftdi_sio.c from the latest Linux kernel and browsed for
> the e-mail addresses hence this e-mail.
> 
> I've been struggling with an annoying plug-and-play issue involving
> an FT232RL-based USB device on ARM machines with Linux lately
> (including Raspberry Pi and BeagleBoard). In a nutshell the
> following is happening:
> * I plug in the FT232RL-based USB device. /dev/ttyUSB0 is created.
> * I run an application that communicate with the device via
> /dev/ttyUSB0. The application sets a baudrate - this is important.
> The application reads and writes data successfully.
> * I unplug the USB device. /dev/ttyUSB0 remains in existence - this
> is important too.

Huh?  The device node should go away, as the application was told that
the device went away, is the application somehow still keeping the
device node open?  If so, that's the issue here.

> * I replug the USB device. /dev/ttyUSB0 is still there.
> * I rerun the application. The application again connects with
> /dev/ttyUSB0 but it fails to transfer data. So it seems.

That's because it is trying to still talk to the old device, not the new
one, which should have showed up on ttyUSB1.

What kernel version are you using here?

greg k-h

Re: Bug in USB FTDI SIO driver

[Alan Cox]

On Sat, 08 Sep 2012 12:14:39 +0200
peter.sheeren@axiris.be wrote:

> 	if (((old_priv.flags & ASYNC_SPD_MASK) !=
> 	     (priv->flags & ASYNC_SPD_MASK)) ||
> 	    (((priv->flags & ASYNC_SPD_MASK) == ASYNC_SPD_CUST) &&
> 	     (old_priv.custom_divisor != priv->custom_divisor))) {
> 		change_speed(tty, port);
> 
> Function change_speed() is called only when the baudrate  
> (custom_divisor) has changed but after a USB replug this assumption is  
> wrong. Also note that /dev/ttyUSB0 remains in existence on the system  
> under test. If it were up to me, I'd always send the baudrate setting  
> over the USB bus nomatter whether the baudrate (supposedly) has  
> changed or not.

We don't do that because if you gratuitously send speed changes that have
no effect the hardware seems to reset its configuration and you lose
characters, something a lot of software doesn't expect.

If you think that if check is the problem can you replace it with an
unconditional call to change_speed(tty, port) and the re-test. That will
confirm if it is the cause.

If it is then we can think about fixing it somehow.

Alan

Re: Bug in USB FTDI SIO driver

[peter.sheeren]

Hello Alan

Thanks for the answer.

I'm seeing the issue on:
* Raspberry Pi with Debian6 (kernel 3.1.9+)
* Raspberry Pi with Raspbian (also kernel 3.1.9+)
* BeagleBoard xM rev. C with Ubuntu (kernel 3.1.4)

I did a much simpler test without test application, just plugging and  
looking. The results are the same on all three systems:
0. Reboot and log in
1. lsmod -> no usbserial, no ftdi_sio
2. plug in the USB device (first time)
3. lsmod -> usbserial loaded, ftdi_sio loaded
4. plug out the USB device
5. lsmod -> usbserial loaded, ftdi_sio loaded
6. plug in the USB device
7. lsmod -> usbserial loaded, ftdi_sio loaded

The existence of /dev/ttyUSB0 depends on the system:
* RPi with Raspbian: /dev/ttyUSB0 never goes away after step 4.
* RPi with Debian6, BBXM: /dev/ttyUSB0 goes away after step 4 and  
comes back after step 6.

The fact is that ftdi_sio and usbserial are never unloaded. That's  
probably the cause of the baudrate problem.

Are there any commands I can run to provide you with more information?

Best regards,

Peter

Quoting Alan Cox <alan@lxorguk.ukuu.org.uk>:

> On Sat, 08 Sep 2012 12:14:39 +0200
> peter.sheeren@axiris.be wrote:
>
>> 	if (((old_priv.flags & ASYNC_SPD_MASK) !=
>> 	     (priv->flags & ASYNC_SPD_MASK)) ||
>> 	    (((priv->flags & ASYNC_SPD_MASK) == ASYNC_SPD_CUST) &&
>> 	     (old_priv.custom_divisor != priv->custom_divisor))) {
>> 		change_speed(tty, port);
>>
>> Function change_speed() is called only when the baudrate
>> (custom_divisor) has changed but after a USB replug this assumption is
>> wrong. Also note that /dev/ttyUSB0 remains in existence on the system
>> under test. If it were up to me, I'd always send the baudrate setting
>> over the USB bus nomatter whether the baudrate (supposedly) has
>> changed or not.
>
> We don't do that because if you gratuitously send speed changes that have
> no effect the hardware seems to reset its configuration and you lose
> characters, something a lot of software doesn't expect.
>
> If you think that if check is the problem can you replace it with an
> unconditional call to change_speed(tty, port) and the re-test. That will
> confirm if it is the cause.
>
> If it is then we can think about fixing it somehow.
>
> Alan
>

Re: Bug in USB FTDI SIO driver

[Alan Cox]

> The existence of /dev/ttyUSB0 depends on the system:
> * RPi with Raspbian: /dev/ttyUSB0 never goes away after step 4.
> * RPi with Debian6, BBXM: /dev/ttyUSB0 goes away after step 4 and  
> comes back after step 6.

Thats dependant upon your user space and really nothing to do with this

> Are there any commands I can run to provide you with more information?

As I said...

> > If you think that if check is the problem can you replace it with an
> > unconditional call to change_speed(tty, port) and the re-test. That will
> > confirm if it is the cause.

Alan

Re: Bug in USB FTDI SIO driver

[peter.sheeren]

I'm sorry, I've no experience with compiling a driver for Linux.

Q: When I plug in the USB device without even using it, should  
ftdi_sio and usbserial remain loaded after I unplug the USB device?


Quoting Alan Cox <alan@lxorguk.ukuu.org.uk>:

>> The existence of /dev/ttyUSB0 depends on the system:
>> * RPi with Raspbian: /dev/ttyUSB0 never goes away after step 4.
>> * RPi with Debian6, BBXM: /dev/ttyUSB0 goes away after step 4 and
>> comes back after step 6.
>
> Thats dependant upon your user space and really nothing to do with this
>
>> Are there any commands I can run to provide you with more information?
>
> As I said...
>
>> > If you think that if check is the problem can you replace it with an
>> > unconditional call to change_speed(tty, port) and the re-test. That will
>> > confirm if it is the cause.
>
> Alan
>

Re: Bug in USB FTDI SIO driver

[Alan Cox]

On Sat, 08 Sep 2012 19:35:16 +0200
peter.sheeren@axiris.be wrote:

> 
> I'm sorry, I've no experience with compiling a driver for Linux.
> 
> Q: When I plug in the USB device without even using it, should  
> ftdi_sio and usbserial remain loaded after I unplug the USB device?

Thats up to your distribution.

Re: Bug in USB FTDI SIO driver

[Greg KH]

On Sat, Sep 08, 2012 at 07:35:16PM +0200, peter.sheeren@axiris.be wrote:
> 
> I'm sorry, I've no experience with compiling a driver for Linux.
> 
> Q: When I plug in the USB device without even using it, should
> ftdi_sio and usbserial remain loaded after I unplug the USB device?

Yes, no one unloads modules after devices are removed, as you really
don't know if the driver is still needed or not.

But, this shouldn't be an issue for you, when you replug the device in,
it should be reset, with no internal, or kernel, state as to what it is
in.  You have to always explicitly set the line settings up again,
otherwise you have no idea what it is running at.

greg k-h

Re: Bug in USB FTDI SIO driver

[peter.sheeren]

It's interesting to know the driver aren't unloaded. So I did a couple  
of tests with rmmod:

Test 1:
1. Plug in the USB device
2. Run test application, baud rate is successfully set
3. Plug out the USB device, lsmod shows usbserial and ftdi_sio
4. rmmod ftdi_sio
5. Plug in the USB device
6. Run test application, baud rate not set in the USB device

Test 2:
1. Plug in the USB device
2. Run test application, baud rate is successfully set
3. Plug out the USB device, lsmod shows usbserial and ftdi_sio
4. rmmod ftdi_sio
5. rmmod usbserial
6. Plug in the USB device
7. Run test application, baud rate is successfully set

Thus if I remove both ftdi_sio and usbserial before I plug the USB  
device back in, the problem is solved. Maybe usbserial is causing the  
problem?


Quoting Greg KH <gregkh@linuxfoundation.org>:

> On Sat, Sep 08, 2012 at 07:35:16PM +0200, peter.sheeren@axiris.be wrote:
>>
>> I'm sorry, I've no experience with compiling a driver for Linux.
>>
>> Q: When I plug in the USB device without even using it, should
>> ftdi_sio and usbserial remain loaded after I unplug the USB device?
>
> Yes, no one unloads modules after devices are removed, as you really
> don't know if the driver is still needed or not.
>
> But, this shouldn't be an issue for you, when you replug the device in,
> it should be reset, with no internal, or kernel, state as to what it is
> in.  You have to always explicitly set the line settings up again,
> otherwise you have no idea what it is running at.
>
> greg k-h
>