ftdi_sio doesnt work propertly

Bug #376128 reported by Sets on 2009-05-13
This bug affects 5 people
Affects Status Importance Assigned to Milestone
linux (Ubuntu)
Stefan Bader

Bug Description

SRU Justification:

Impact: 2.6.28 kernels (only) have a reference counting bug in ftdi_sio that frequently renders /dev/ttyUSBn devices useless when they're closed, fixed only by a reboot.

Fix: The bug was fixed in 2.6.29 by a9fec7102f, by exiting with correctly releasing the reference.

Testcase: See below.


i have irda device "irlink" on FTDI chipset when i connect it, device /dev/ttyUSB0 apears but when i try to sent a signal to my irlink nothing coming to port /dev/ttyUSB0 (cat /dev/ttyUSB0) device works good under Windows and as i heard it worked on Ubuntu earlear versions(6.04 if i remember right)

#lsusb -v
Bus 006 Device 003: ID 0403:6001 Future Technology Devices International, Ltd FT232 USB-Serial (UART) IC
Device Descriptor:
  bLength 18
  bDescriptorType 1
  bcdUSB 2.00
  bDeviceClass 0 (Defined at Interface level)
  bDeviceSubClass 0
  bDeviceProtocol 0
  bMaxPacketSize0 8
  idVendor 0x0403 Future Technology Devices International, Ltd
  idProduct 0x6001 FT232 USB-Serial (UART) IC
  bcdDevice 6.00
  iManufacturer 1 FTDI
  iProduct 2 FT232R USB UART
  iSerial 3 A90058ya
  bNumConfigurations 1
  Configuration Descriptor:
    bLength 9
    bDescriptorType 2
    wTotalLength 32
    bNumInterfaces 1
    bConfigurationValue 1
    iConfiguration 0
    bmAttributes 0xa0
      (Bus Powered)
      Remote Wakeup
    MaxPower 90mA
    Interface Descriptor:
      bLength 9
      bDescriptorType 4
      bInterfaceNumber 0
      bAlternateSetting 0
      bNumEndpoints 2
      bInterfaceClass 255 Vendor Specific Class
      bInterfaceSubClass 255 Vendor Specific Subclass
      bInterfaceProtocol 255 Vendor Specific Protocol
      iInterface 2 FT232R USB UART
      Endpoint Descriptor:
        bLength 7
        bDescriptorType 5
        bEndpointAddress 0x81 EP 1 IN
        bmAttributes 2
          Transfer Type Bulk
          Synch Type None
          Usage Type Data
        wMaxPacketSize 0x0040 1x 64 bytes
        bInterval 0
      Endpoint Descriptor:
        bLength 7
        bDescriptorType 5
        bEndpointAddress 0x02 EP 2 OUT
        bmAttributes 2
          Transfer Type Bulk
          Synch Type None
          Usage Type Data
        wMaxPacketSize 0x0040 1x 64 bytes
        bInterval 0
Device Status: 0x0000
  (Bus Powered)

[ 4305.936047] usb 6-1: new full speed USB device using uhci_hcd and address 3
[ 4306.123976] usb 6-1: configuration #1 chosen from 1 choice
[ 4306.177503] usbcore: registered new interface driver usbserial
[ 4306.177519] USB Serial support registered for generic
[ 4306.177574] usbcore: registered new interface driver usbserial_generic
[ 4306.177576] usbserial: USB Serial Driver core
[ 4306.182914] USB Serial support registered for FTDI USB Serial Device
[ 4306.183030] ftdi_sio 6-1:1.0: FTDI USB Serial Device converter detected
[ 4306.183054] usb 6-1: Detected FT232RL
[ 4306.183103] usb 6-1: FTDI USB Serial Device converter now attached to ttyUSB0
[ 4306.183118] usbcore: registered new interface driver ftdi_sio
[ 4306.183120] ftdi_sio: v1.4.3:USB FTDI Serial Converters Driver

ProblemType: Bug
Architecture: i386
DistroRelease: Ubuntu 9.04
HibernationDevice: RESUME=UUID=023cd028-9396-4d8f-9d48-f251ec2a4622

NonfreeKernelModules: nvidia
Package: linux-image-2.6.28-12-generic 2.6.28-12.43
ProcCmdLine: root=UUID=a4524d31-8871-4c9d-b302-676955cf6441 ro quiet splash
 PATH=(custom, no user)
ProcVersionSignature: Ubuntu 2.6.28-12.43-generic
SourcePackage: linux

Sets (sets88) wrote :
Sets (sets88) on 2009-05-13
description: updated

We are using ftdi_sio with a 232M chip.

On intrepid and with jaunty's 2.6.27 kernel, ftdi_sio works like a charm on different setups (x86 IA32 and x86_64).

On 2.6.28-10 and -13, we have the following regression (x86 IA32): one program opens the device, sends/receives data, then closes it. This works at least once. This can be done several times, but at some point it will fail: after a close() (or directly a program exit), no other program can open the device again (Input/output error in open). If I rmmod the module (rmmod or modprobe -r), unplug/plug the device back again, etc. (I tried many combinations) I cannot ever open the device again: I have to reboot the machine. And modprobe with debug=1 doesn't suggest anything (no message beyond USB device connect/enumeration). I didn't spy on the bus with usbmon since I could have a working setup with 2.6.27.

I noticed that the bug seems to be more (always ?) reproducible with pyserial then with direct libc open/close from C: after one has used a pyserial script with the device, nobody can ever use the device again. Reboot needed...

Looking at the git, I noticed this changeset:
This adds a few reference counting tweaks. Most notably, in ftdi_process_read, there reference acquires and release in the form of "goto out" (which release tty refs) almost everywhere EXCEPT one return still there... See line 2031 of jaunty's 2.6.28-13.44 official source for ftdi_sio.c, or this line:

Looking at the ftdi_sio.c changes since commit fd05e720099e8eeddb378305d1a41c1445344b91, I didn't notice anything else which was not more or less cosmetic.

I have absolutely no idea 1/ whether a "goto out" would be even correct (I don't have a global vision of this driver), nor 2/ whether this would be the cause of our problems here. However, could anyone take a look at this ?

Tim Gardner (timg-tpi) wrote :

Replacing 'return;' with 'goto out;' appears to be the exact solution upstream has chosen. Please try a more recent kernel to confirm, perhaps something from the mainline vanilla series at http://kernel.ubuntu.com/~kernel-ppa/mainline, or a recent Karmic kernel from https://edge.launchpad.net/ubuntu/+source/linux

Thank you !
You're perfectly right, any recent mainline > 2.6.28 already contains the fix. I tried with http://kernel.ubuntu.com/~kernel-ppa/mainline/v2.6.29.5/ and our ftdi is fine again. How do you manage this kind of issue at Canonical ? You patch the current 2.6.28 ? Or you jump directly to a 2.6.29 ?

FYI, the fix originates from http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=a9fec7102f01f6464b19e13ffd9d8c48663379ad

Jim Paris (jim-jtan) wrote :

I sent the patch to <email address hidden>, so hopefully it will get included in I assume it will make its way into Ubuntu after that?

Jim Paris (jim-jtan) wrote :

OK, there's no such thing as 2.6.28-stable anymore :) I'll send to the Ubuntu kernel team instead.

Stefan Bader (smb) on 2009-07-24
Changed in linux (Ubuntu):
importance: Undecided → Medium
status: New → Fix Released
Changed in linux (Ubuntu Jaunty):
assignee: nobody → Stefan Bader (stefan-bader-canonical)
importance: Undecided → Medium
status: New → In Progress
description: updated
Stefan Bader (smb) on 2009-07-24
Changed in linux (Ubuntu Jaunty):
status: In Progress → Fix Committed
Risto H. Kurppa (risto.kurppa) wrote :

In what kernel is this fix included? I run 2.6.28-15 on Jaunty and have problems seeing anything from /dev/ttyUSB0 using the same receiver:

Bus 007 Device 004: ID 0403:6001 Future Technology Devices International, Ltd FT232 USB-Serial (UART) IC

It would be in the next proposed kernel (-15.50). Unfortunately it is still
waiting to get accepted into proposed.

Risto H. Kurppa (risto.kurppa) wrote :

Thanks Stefan, waiting for -15.50. So did I understand correctly that any Karmic kernel would already have this fix? Might give a try on a laptop.

Stefan Bader (smb) wrote :

Yes, the patch in question was part of 2.6.29, so Karmic should work.

Martin Pitt (pitti) wrote :

Accepted linux into jaunty-proposed, the package will build now and be available in a few hours. Please test and give feedback here. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you in advance!

tags: added: verification-needed
tz (thomas-mich) wrote :

#uname -a
Linux tz-hpmini 2.6.28-15-generic #49-Ubuntu SMP Tue Aug 18 18:40:08 UTC 2009 i686 GNU/Linux

Does not fix this. It sounds like my problem, but only happens when the buffer overruns.
I will try one of the 2.6.29 kernels and/or Karmic when I get a chance.

For example, using http://www.sparkfun.com/commerce/product_info.php?products_id=9115 (or the 3.3v version) and shorting TXO to RXI, then do (at 57600/pass8):
 cat /dev/ttyUSB0
 cat testfile >/dev/ttyUSB0
it will work, and it will work if you just send a small file with the second command then run the first. But if you copy a larger file (I don't know the precise boundary) it will lock up, fail, and require a reboot.

I generally can't get it to lock up if there is something reading all the characters back, or the data rate of the input is slow (even if I leave it for a short while, but more than long enough to get any local buffers filled up).

tz@tz-hpmini:~/Downloads/pulse1$ cat logs/acc3.log >/dev/ttyUSB0
bash: /dev/ttyUSB0: Input/output error

After it locks up:

tz@tz-hpmini:~/sbnok/tzgpsd/minigpsd-0.31/sample+utils$ lsmod | grep ft
ftdi_sio 56968 0
usbserial 39656 2 ftdi_sio

tz (thomas-mich) wrote :

Rereading the earlier messages, if a linux-kernel or such comes out later today in -proposed I will try it and get back.

Rey Tucker (rtucker) wrote :

So far, things are looking good with this kernel and my FT232RL. I will advise if the problem doesn't stay fixed :-)


tz (thomas-mich) wrote :

I've not found any newer kernel using jaunty-proposed, and whatever I have now still has the problem occasionally.

Is the -15 supposed to fix everything?

(Ryan - could you try a loopback and copy a massive file like in my post #13)

Also what should the kernel display with uname -a?

Mine says:

Linux tz-hpmini 2.6.28-15-generic #49-Ubuntu SMP Tue Aug 18 18:40:08 UTC 2009 i686 GNU/Linux

> Linux tz-hpmini 2.6.28-15-generic #49-Ubuntu SMP Tue Aug 18 18:40:08 UTC
> 2009 i686 GNU/Linux

That is not the proposed kernel. Proposed would have a #51 after generic.

Linux arcturus 2.6.28-15-generic #51-Ubuntu SMP Wed Aug 26 17:40:02 UTC 2009
x86_64 GNU/Linux

tz (thomas-mich) wrote :

The "selective update" portion in the wiki apparently doesn't quite work - I entered the information as it said and started aptitude. I also set a tic-mark on the box in the main section.
Ah - the "preferences" text in the selective part doesn't work, at least not if I just do a cut-paste and will prevent the tic box in the software sources not to work.

I'm upgrading now and will report back after the update.


tz (thomas-mich) wrote :

I got around to stress-testing the bug (1000000 baud - reading pulse trains from things like an IR remote from an Arduino).

Works perfectly now. I haven't had a single IO error or other crash (no overrun either, but it is hard to overrun a megabaud).

Martin Pitt (pitti) on 2009-09-21
tags: added: verification-done
removed: verification-needed
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package linux - 2.6.28-15.52

linux (2.6.28-15.52) jaunty-proposed; urgency=low

  [ Stefan Bader ]

  * Revert "SAUCE: ACPI: Populate DIDL before registering ACPI video device
    on Intel"
    - LP: #423296
  * SAUCE: Allow less restrictive acpi video detection
    - LP: #333386

  [ Upstream Kernel Changes ]

  * include drivers/pci/hotplug/* in -virtual package
    - LP: #364916
  * ext4: don't call jbd2_journal_force_commit_nested without journal
    - LP: #418197
  * ext4: fix ext4_free_inode() vs. ext4_claim_inode() race
    - LP: #418197
  * ext4: fix bogus BUG_ONs in in mballoc code
    - LP: #418197
  * ext4: fix typo which causes a memory leak on error path
    - LP: #418197
  * ext4: Fix softlockup caused by illegal i_file_acl value in on-disk
    - LP: #418197
  * ext4: Fix sub-block zeroing for writes into preallocated extents
    - LP: #418197
  * jbd2: Call journal commit callback without holding j_list_lock
    - LP: #418197
  * ext4: Print the find_group_flex() warning only once
    - LP: #367065
  * ext4: really print the find_group_flex fallback warning only once
    - LP: #367065

linux (2.6.28-15.51) jaunty-proposed; urgency=low

  [ Colin Ian King ]

  * SAUCE: wireless: hostap, fix oops due to early probing interrupt
    - LP: #254837

  [ Leann Ogasawara ]

  * Add the atl1c driver to support Atheros AR8132
    - LP: #415358
  * Updating configs to enable the atl1c driver
    - LP: #415358

  [ Stefan Bader ]

  * Revert "SAUCE: input: Blacklist digitizers from joydev.c"
    - LP: #300143
  * SAUCE: Fix the exported name for e1000e-next
    - LP: #402890
  * SAUCE: Fix incorrect stable backport to bas_gigaset
    - LP: #417732
  * SAUCE: Remove the atl2 driver from the ubuntu subdirectory
    - LP: #419438

linux (2.6.28-15.50) jaunty-proposed; urgency=low

  [ Colin Ian King ]

  * SAUCE: radio-maestro: fix panics on probe failure
    - LP: #357724
  * SAUCE: HDA Intel, sigmatel: Enable speakers on HP Mini 1000
    - LP: #318942

  [ Jerone Young ]

  * SAUCE: Fix Soltech TA12 volume hotkeys not sending key release in
    - LP: #397499

  [ John Johansen ]

  * SAUCE: remove AppArmor debug check for calls from interrupt context
    - LP: #350789

  [ Manoj Iyer ]

  * SAUCE: Fix kernel panic when SELinux is enabled.
    - LP: #395219

  [ Matthew Garrett ]

  * SAUCE: ACPI: Populate DIDL before registering ACPI video device on

  [ Michael Frey (Senior Manager, MID ]

  * SAUCE: Fix for internal microphone for Dell Mini10V
    - LP: #394793

  [ Tim Gardner ]

  * SAUCE: Added e1000e from sourceforge.
    - LP: #402890

  [ Upstream Kernel Changes ]

  * Input: synaptics - report multi-taps only if supported by the device
    - LP: #399787
  * ftdi_sio: fix kref leak
    - LP: #396930, #376128
  * IPv6: add "disable" module parameter support to ipv6.ko
    - LP: #351656

 -- Stefan Bader <email address hidden> Thu, 27 Aug 2009 15:09:06 +0200

Changed in linux (Ubuntu Jaunty):
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers