FTDI USB serial FT232RL regression, requires toggling flow control

Bug #920959 reported by bijwaard
22
This bug affects 4 people
Affects Status Importance Assigned to Milestone
Digitemp
Confirmed
Medium
Unassigned
linux (Ubuntu)
Fix Released
Medium
Unassigned

Bug Description

After restarting yesterday (after +/-23 days), the Linux kernel updates got effective and rendered my USB serial ports unusable until I toggled the flow control off and then on again. Before the update I could use my serial ports without problems at 460800 baud, with flow control. I normally use my cross-platform application to access the serial port, but the problem is also visible with socat.

I do get bytes over the serial port but I cannot believe that it is correct:

$ socat /dev/ttyUSB0,nonblock,crtscts=1,cs8,cstopb=1,echo=0,b460800 -|hexdump -C

00000000 c0 00 c0 c0 00 e0 00 e0 e0 c0 00 00 00 00 c0 e0 |................|
00000010 e0 00 00 00 00 c0 00 e0 00 00 00 00 00 c0 00 e0 |................|
00000020 c0 00 c0 00 c0 00 00 00 00 00 00 00 00 c0 00 e0 |................|
00000030 00 c0 e0 00 c0 00 c0 c0 00 e0 00 c0 00 00 c0 e0 |................|
00000040 c0 e0 00 c0 e0 00 00 c0 c0 c0 c0 00 e0 00 00 c0 |................|

After toggling the flow_control off, I get (serial messages start with 01 2f):

$ socat /dev/ttyUSB0,nonblock,crtscts=0,cs8,cstopb=1,echo=0,b460800 -|hexdump -C
00000000 00 00 00 00 00 e0 00 c0 c0 e0 c0 00 00 e0 00 e0 |................|
00000010 c0 00 c0 00 00 00 c0 00 c0 c0 e0 c0 c0 00 e0 00 |................|
00000020 e0 c0 00 00 c0 00 00 c0 c0 c0 e0 00 c0 c0 00 00 |................|
00000030 e0 c0 e0 00 c0 00 e0 c0 00 e0 00 00 c0 00 00 00 |................|
00000040 c0 00 c0 c0 00 00 c0 e0 c0 00 00 c0 00 b2 ff d5 |................|
00000050 ff c2 00 16 ff fd 0e 0a ff fc ff ff fe a6 ff be |................|
00000060 00 18 ff fd a7 03 01 2f 03 77 22 00 ff ff 01 08 |......./.w".....|
00000070 28 21 00 00 0c 56 ff fd 26 1a 0a ff ec ff dc fe |(!...V..&.......|
00000080 a6 ff c1 00 20 00 31 ff f6 00 09 fe a7 ff bf 00 |.... .1.........|
00000090 25 00 1b 14 0e ff f4 ff fa fe a4 01 4a 00 1c ff |%...........J...|
000000a0 78 ff c6 00 1e 00 12 26 0a 00 02 ff fc fe ab ff |x......&........|

After toggling flow_control back on, I get:

$ socat /dev/ttyUSB0,nonblock,crtscts=1,cs8,cstopb=1,echo=0,b460800 -|hexdump -C
00000000 01 2f 03 6f 22 00 ff ff 01 08 28 21 00 00 54 01 |./.o".....(!..T.|
00000010 00 00 26 26 0a ff fc ff fe fe a7 ff c1 00 1a ff |..&&............|
00000020 ff ff fc ff fd fe a7 ff bf 00 1a ff fd ff fd ff |................|
00000030 fe fe a7 ff c0 00 1a ff ff 14 0e ff fc ff fe fe |................|
00000040 a6 ff ec 00 09 00 4e ff c0 00 17 ff ff 26 0a ff |......N......&..|
00000050 fd ff ff fe a5 ff be 00 1a ff fb ff fc ff ff fe |................|
00000060 a4 ff be 00 19 00 01 ff fc ff fe fe a5 ff be 00 |................|

After this procedure, I can succesfully use the device and stop/start the serial communication, until I unplug it. After unplugging or plugging in another device with the same FTDI chip, I have to toggle flow_control again to get it to work.

I also used the fired up VirtualBox with Windows-XP and had no trouble connecting getting the right data from the serial port (e.g. in putty, terraterm, my own cross-platform application, no flow_control toggling required), also using switching between FTDI devices didnt' give any problems.

ProblemType: Bug
DistroRelease: Ubuntu 11.10
Package: linux-image-3.0.0-15-generic 3.0.0-15.26
ProcVersionSignature: Ubuntu 3.0.0-15.26-generic 3.0.13
Uname: Linux 3.0.0-15-generic x86_64
AlsaVersion: Advanced Linux Sound Architecture Driver Version 1.0.24.
AplayDevices:
 **** List of PLAYBACK Hardware Devices ****
 card 0: Intel [HDA Intel], device 0: STAC92xx Analog [STAC92xx Analog]
   Subdevices: 1/1
   Subdevice #0: subdevice #0
ApportVersion: 1.23-0ubuntu4
Architecture: amd64
ArecordDevices:
 **** List of CAPTURE Hardware Devices ****
 card 0: Intel [HDA Intel], device 0: STAC92xx Analog [STAC92xx Analog]
   Subdevices: 1/1
   Subdevice #0: subdevice #0
AudioDevicesInUse:
 USER PID ACCESS COMMAND
 /dev/snd/controlC0: bijwaard 1736 F.... pulseaudio
CRDA: Error: [Errno 2] No such file or directory
Card0.Amixer.info:
 Card hw:0 'Intel'/'HDA Intel at 0xe8604000 irq 47'
   Mixer name : 'IDT 92HD75B2X5'
   Components : 'HDA:111d7608,103c308a,00100202 HDA:11c11040,103c1378,00100200'
   Controls : 14
   Simple ctrls : 9
Date: Tue Jan 24 13:10:01 2012
HibernationDevice: RESUME=UUID=32c975b3-5e3a-4d0b-8cdc-d81ec4c4a02e
InstallationMedia: Xubuntu 11.10 "Oneiric Ocelot" - Release amd64 (20111012)
MachineType: Hewlett-Packard Compaq 610
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-3.0.0-15-generic root=UUID=cb9e7103-08de-46ee-975b-7eef245d4041 ro quiet splash vt.handoff=7
RelatedPackageVersions:
 linux-restricted-modules-3.0.0-15-generic N/A
 linux-backports-modules-3.0.0-15-generic N/A
 linux-firmware 1.60
SourcePackage: linux
UpgradeStatus: No upgrade log present (probably fresh install)
dmi.bios.date: 12/17/2009
dmi.bios.vendor: Hewlett-Packard
dmi.bios.version: 68PVU Ver. F.0D
dmi.board.name: 308A
dmi.board.vendor: Hewlett-Packard
dmi.board.version: KBC Version 26.08
dmi.chassis.asset.tag: CNU0064GLG
dmi.chassis.type: 10
dmi.chassis.vendor: Hewlett-Packard
dmi.modalias: dmi:bvnHewlett-Packard:bvr68PVUVer.F.0D:bd12/17/2009:svnHewlett-Packard:pnCompaq610:pvrF.0D:rvnHewlett-Packard:rn308A:rvrKBCVersion26.08:cvnHewlett-Packard:ct10:cvr:
dmi.product.name: Compaq 610
dmi.product.version: F.0D
dmi.sys.vendor: Hewlett-Packard

Revision history for this message
bijwaard (bijwaard) wrote :
Brad Figg (brad-figg)
Changed in linux (Ubuntu):
status: New → Confirmed
Revision history for this message
Joseph Salisbury (jsalisbury) wrote :

Would it be possible for you to test the latest upstream kernel? It will allow additional upstream developers to examine the issue. Refer to https://wiki.ubuntu.com/KernelMainlineBuilds . If possible, please test the latest v3.2 kernel[1] (Not a kernel in the daily directory). Once you've tested the upstream kernel, please remove the 'needs-upstream-testing' tag(Only that one tag, please leave the other tags). This can be done by clicking on the yellow pencil icon next to the tag located at the bottom of the bug description and deleting the 'needs-upstream-testing' text.

If this bug is fixed by the mainline kernel, please add the following tag 'kernel-fixed-upstream-KERNEL-VERSION'. For example, if kernel version 3.2-rc1 fixed the issue, the tag would be: 'kernel-fixed-upstream-v3.2-rc1'.

If the mainline kernel does not fix this bug, please add the tag: 'kernel-bug-exists-upstream'.

If you are unable to test the mainline kernel, for example it will not boot, please add the tag: 'kernel-unable-to-test-upstream'. If you believe this bug does not require upstream testing, please add the tag: 'kernel-upstream-testing-not-needed'.

Once testing of the upstream kernel is complete, please mark this bug as "Confirmed".

Thanks in advance.

[1] http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.2-precise/

tags: added: needs-upstream-testing
Changed in linux (Ubuntu):
importance: Undecided → Medium
status: Confirmed → Incomplete
Revision history for this message
bijwaard (bijwaard) wrote :

As suggested, I tested with the latest mainstream kernel (3.2.1, linux-image-3.2.1-030201-generic_3.2.1-030201.201201121644_amd64.deb) and the problem still persists, although I had to first kill powerd that grabbed my FTDI device (existing bug, Debian Bug report logs - #586751).

tags: added: kernel-bug-exists-upstream
removed: needs-upstream-testing
Changed in linux (Ubuntu):
status: Incomplete → Confirmed
Revision history for this message
Marcelo Fernandez (fernandezm) wrote :

This comment is only to say a "me too", but to say this is also happening with a FT2232C chip.

From python, enabling the RtsCts to True (pySerial) does the job to avoid the problem.

Regards

Revision history for this message
Mark Liversedge (liversedge) wrote :

Me too.

stty<crtscts/dev/ttyUSB0; stty -crtscts </dev/ttyUSB0;

Fixes it. Required once only after reboot only then works fine until I reboot.

Sorry if this was obvious from previous posts.

Revision history for this message
Marcelo Fernandez (fernandezm) wrote :

Recently tested with precise alpha-2 and still got the same problem.

Sometimes even I have to do a "rmmod ftdi_sio usbserial", unplug and plug again the USB connector to connect to the serial device.

Regards.

affects: linux (Ubuntu) → digitemp
Changed in ubuntu:
status: New → Invalid
bijwaard (bijwaard)
Changed in ubuntu:
status: Invalid → Confirmed
Revision history for this message
Mathijs de Meijer (mdemeijer) wrote :

This also affects me on Ubunu 11.10, 3.0.0-16-generic, with the FTDI FT232 serial-to-usb bridge.
stty crtscts < /dev/ttyUSB0; stty -crtscts </dev/ttyUSB0; fixes it until the next reboot.
Weirdly enough whenever I have plugged an FTDI FT232 cable into my machine an tried (and failed) to use putty, the cable refuses to function on other ubuntu machines as well, where they worked flawlessly before. Could this be a combination of the FTDI cable + a kernel bug?

Revision history for this message
Brian Murray (brian-murray) wrote :

Adding linux package task since it disappeared some how.

affects: ubuntu → linux (Ubuntu)
Revision history for this message
Joseph Salisbury (jsalisbury) wrote :

This issue appears to be an upstream bug, since you tested the latest upstream kernel. Would it be possible for you to open an upstream bug report at bugzilla.kernel.org [1]? That will allow the upstream Developers to examine the issue, and may provide a quicker resolution to the bug.

If you are comfortable with opening a bug upstream, It would be great if you can report back the upstream bug number in this bug report. That will allow us to link this bug to the upstream report.

[1] https://wiki.ubuntu.com/Bugs/Upstream/kernel

Changed in linux (Ubuntu):
importance: Undecided → Medium
status: Confirmed → Triaged
Revision history for this message
Julian Wiedmann (jwiedmann) wrote :

The latest kernel in -updates (3.0.0-16.29) brings two bug fixes [0] for the ftdi_sio driver - one of them is
for a previous regression in the 3.0-stable tree. Please test and see if this issue persists.

[0]
USB: ftdi_sio: fix initial baud rate
USB: ftdi_sio: fix TIOCSSERIAL baud_base handling

Revision history for this message
bijwaard (bijwaard) wrote :

The description of fix initial baud rate is similar but for baudrate. I checked in http://www.kernel.org/pub/linux/kernel/v3.x/ChangeLog-3.2.3 that is was also not yet fixed in the 3.2.1 kernel I tested. I'll try to find some time for a retest tomorrow.

Revision history for this message
bijwaard (bijwaard) wrote :

I just tested after updating the kernel to 3.0.0-16.29 and the problem went away on my laptop. Thanks for your support.
Others should probably retest their configuration as well.

Revision history for this message
Julian Wiedmann (jwiedmann) wrote :

Changing the status to Fix Released - if anyone else is still having issues with this driver, please open a new bug.

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

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.