ftdi serial driver broken in linux-image-2.6.31-14-generic (2.6.31-14.48)

[Brad Campbell]

Until 2.6.31.5 the mainline kernel contained a bug whereby repeated opens of usb-serial devices using the ftdi_sio driver would fail to receive any data unless opened with the O_NONBLOCK flag set. Trying to fnctl( ) an already opened port would not resolve the issue.

This bug was fixed in the 2.6.31.5 update to the ftdi_sio driver and currently still affects the Ubuntu 2.6.31-14 kernel.

There was a not-insignificant update consisting of 4 patches to the ftdi driver in the .5 stable patch set. Can someone update this driver please?

http://lkml.org/lkml/2009/10/16/245
http://lkml.org/lkml/2009/10/16/220
http://lkml.org/lkml/2009/10/16/197
http://lkml.org/lkml/2009/10/16/198

[Robert Marshall (ki4mcw)]

Plus one. I have a radio modem (TNC-X) that uses an FTDI USB/serial chip for communications to a PC host. The device connects fine, kicks off udev, and the module loads ok, but some applications (including the intended app, Xastir) cannot read from the device under the current Karmic kernel (2.6.31-14-generic). No errors, no warnings - the data just never makes it into the application.

I see that there is a kernel package 2.6.31-15-generic in "Karmic proposed". Please note that the 15 package =does not= contain the fixes described in the previous post, as it is based on the 2.6.31.4 source, and exhibits the same problems as from the production kernel. I was able to start with "15-generic" and compile a one-off of the ftdi_sio module using the 2.6.31.5 kernel source. This seems to work fine.

So as mentioned above, please either patch the proposed kernel with the 2.6.31.5 code for ftdi_sio, or maybe start over with a new kernel based on 2.6.31.5.

Thanks.

[lawrni (lawrni)]

Hi,

I'm having this same issue too. I have some programs that can access the FTDI device and others that cannot. Any chance you could give me a few pointers as to how to compile the 'one-off' FTDI_sio module using the 2.6.31.5 code for ftdi_sio. I have done:

1. Install Linux headers ( sudo apt-get install linux headers )
2. downloaded the source for 2.6.31.6 (.6 seems to be latest stable now )

What do I do next.

Also, I'm currently running 2.6.31-14-generic - Do I need to update to 2.6.31-15 before doing this ? If so, how, it doesn't look like it's available yet.

Any help for a newcomer would be appreciated.

[Gavin Sallery (gavin-sallery)]

I'd like to follow up lawrni's comment; I've got some idea of what Robert did to get the one-off module working, but not enough Ubuntu kernel mojo to know exactly how to proceed. In the meantime, the ftdi_sio bug leaves me unable to use my IRTrans transceiver module - this is something of a pain. If anyone out there could give step-by-step instructions of how to get a working ftdi_sio module compiled under 2.6.31-14-generic, that would be most useful.

Also, how do we get the "Karmic proposed" kernel to include the necessary fix?

[lawrni (lawrni)]

Hi

I'd just like to add that a very helpful person in the Ubuntu forum has keyed in a process to compile the ftdi_sio kernel module. I followed it and it worked a treat! Here's the link:

http://ubuntuforums.org/showthread.php?p=8364508&posted=1#post8364508

[Brad Campbell (brad-wasp)]

Who do I have to sleep with to even get someone to look at this bug report?

[tz (thomas-mich)]

The process described above in the post works, but is fairly complicated and time consuming (downloading two kernel trees, doing a graft of some files, etc.). It would be nice if the ko file was available.

Most arduino modules and development are affected by this.

Note that I can use "socat file:/dev/ttyUSB0,nonblock stdout" (or stdio for bidi) to replace "cat".

[tz (thomas-mich)]

Makefile - (also attached).

make a new directory, then copy the two fixed files, ftdi_sio.* from the good tree into this new directory, copy this Makefile to the new directory, enter the new directory and type "Make". You will have a .ko in a few seconds.

cut here:
-----8<-----8<-----
KDIR:=/lib/modules/$(shell uname -r)/build

EXTRA_CFLAGS += -I$(KDIR)/drivers/usb/serial -I/usr/src/linux-headers-$(shell uname -r)/include

obj-m:=ftdi_sio.o

default:
 $(MAKE) -C $(KDIR) $(EXTRA_CFLAGS) SUBDIRS=$(PWD) modules

clean:
 $(RM) *.mod.c *.o *.ko .*.cmd Module.symvers Module.markers modules.order

[Kendrick Shaw (kms15)]

tz's makefile worked like a charm. For those who don't want to download the linux kernel sources for two files, here are the two files and a modified version of tz's makefile (with a 'make install' option added).

To install:
1) open a terminal window
2) install the latest kernel headers:

# sudo apt-get install kernel-headers-generic

3) download and uncompress the attached file ftdifix.tar.gz
4) change to the directory where you uncompressed the file, e.g.

# cd ftdifix

5) build the driver:

# make

6) install the driver

# sudo make install

Until this is fixed, you may have to repeat these steps each time you install a new version of the kernel.

[tz (thomas-mich)]

WHY do people here change things to "Incomplete" but NEVER GIVE ANY CLUE AS TO WHAT IS MISSING?

If it is "Incomplete", it would help everyone if you would state what it would take to make the report "complete".

Are we all just supposed to guess and play question and answer games?

Or is there something specific that caused the change from new to incomplete?

[Kendrick Shaw (kms15)]

It appears that anyone can change the status of a bug (including us).

Kalda and Peter both have 0 lauchpad karma - Peter has posted two bug comments in the past two years and Kalda's account was created today. Neither one includes a public email address, so we can't contact them directly. Thus I'm concerned that they may not be people in an appropriate position to mark bugs as incomplete.

Kalda and Peter, if you're active contributors to the project, could you let us know what information is missing? All of us would like to help strengthen the project, and are willing to help if you let us know what is needed.

If we don't hear back from Kalda and Peter in the next couple of days, I suggest we change the status back to "new" to make sure this bug stays on the radar.

[kalda (kalandra)]

I'm sorry! My new project bug report was added accidentally while I've been working on two PCs simultaneously.
I can't find out how to remove it.

This bug still affects the newest ubuntu kernel.
After reboot with FTDI device connected nobody is able to use it.
I/O operations end with "Device or resource busy", but according to lsof no process is using this device.
Manual reconnection of usb device or restarting hald solves this problem in most cases.

[tz (thomas-mich)]

I'm running the kernel from proposed and it appears to have the fix:

uname -a
Linux tz-hpmini 2.6.31-17-generic #54-Ubuntu SMP Thu Dec 10 16:20:31 UTC 2009 i686 GNU/Linux

[Mikael Magnusson (mikma)]

VLSystem MPlay Blast mini remote control stopped working with lirc after upgrade to 9.10.

The receiver can be made to work if the device is first opened (and then closed) in minicom before the lirc daemon is started.
I found out it's because minicom sets the RTS signal. I'm adding a patch to hw_mplay.c which sets the RTS signal during initializing the serial port.

The receiver contains a ftdi serial to USB chip and the problem is probably triggered by this bug in the ftdi_sio kernel driver in 2.6.31, but I think it's no harm setting the RTS anyway during serial port initialization anyway.

[Peter (peter-lusth)]

Sorry some one here at my home has been playing with my computer. I did not mean to change the status.

[Kendrick Shaw (kms15)]

It sounds like both of the status changes from new to incomplete were unintentional, so I've changed the status back to new.

[David (david-depowell)]

@Kendrick Shaw (#8)

Does this work on 64-bit Karmic? Because I tried it before I though about that. When I plugged in my Arduino and typed "cat /dev/ttyUSB0", it hung. Can't even kill the [cat] process with the kill command. Did I screw up?

BTW, "sudo apt-get install kernel-headers-generic" yields "E: Couldn't find package kernel-headers-generic"

David

[Kendrick Shaw (kms15)]

@David (#16)

Good catch - that should be "sudo apt-get install linux-headers-generic" (I shouldn't have typed it from memory). Hopefully this will get the patch to work for you. If you see an error during the first "make", however, there are still problems - please post the error and we'll see if we can help.

I'm using this on 64-bit Karmic, and have just verified that I'm able to "cat /dev/ttyUSB0" and see serial data sent from an Arduino.

[David (david-depowell)]

Thanks, Kendrik. My linux headers were up to date, and the make went without error. The make install had one error, but it was only rmmod saying that the driver wasn't listed in /proc/modules. Otherwise the patch seemed to go in ok. But it didn't fix all of my problems.

If I type "ls /dev/ttyU*" after a fresh reboot and without any USB devices plugged in, it rightly returns "No such file or directory".
If I plug in the Arduino and type that same line, it returns with "/dev/ttyUSB0". All is well at this point, and is no different from pre-patch.

If I then type "echo hello >/dev/ttyUSB0", the little red LED on the Arduino briefly flashes and the command prompt returns. This is also good, and is different from pre-patch. Before the patch, the LED did not flash.

I didn't try "cat /dev/ttyUSB0" after the patch, because I realized that the program that I have loaded in the Arduino doesn't write to the serial port (Doh!). So what I did instead is fire up Eclipse and try to write to it with AVRDude. It threw out a couple of "programmer not responding" messages and hung. I closed Eclipse and now AVRDude is still running. And just like before with cat, I can't kill it from the command prompt (I've never seen a process that couldn't be forced to end in Linux before - I thought that was a Windows-only problem). Unplugging the Arduino doesn't change anything - it still even shows /dev/ttyUSB0 is there when it's unplugged. Dmesg shows a bunch of repeating errors, most of which may as well be written in Greek as far as I'm concerned. Here's a sample:

<code>
[ 1320.980362] INFO: task khubd:40 blocked for more than 120 seconds.
[ 1320.980369] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[ 1320.980374] khubd D 0000000000000000 0 40 2 0x00000000
[ 1320.980382] ffff88021763dbe0 0000000000000046 ffff8801ffca70a0 0000000000015880
[ 1320.980392] ffff880217633110 0000000000015880 0000000000015880 0000000000015880
[ 1320.980398] 0000000000015880 ffff880217633110 0000000000015880 0000000000015880
[ 1320.980404] Call Trace:
[ 1320.980418] [<ffffffff8139eb95>] usb_kill_urb+0x85/0xc0
[ 1320.980427] [<ffffffff81078b30>] ? autoremove_wake_function+0x0/0x40
[ 1320.980433] [<ffffffff8139ee46>] ? usb_get_urb+0x16/0x20
[ 1320.980441] [<ffffffff8139d843>] usb_hcd_flush_endpoint+0x123/0x130
[ 1320.980447] [<ffffffff8139f79a>] usb_disable_endpoint+0x5a/0xa0
[ 1320.980453] [<ffffffff8139f829>] usb_disable_device+0x49/0x130
[ 1320.980461] [<ffffffff8139983a>] usb_disconnect+0xca/0x140
[ 1320.980466] [<ffffffff81399c6a>] hub_port_connect_change+0x8a/0x960
[ 1320.980471] [<ffffffff8139b9d2>] hub_events+0x3a2/0x590
[ 1320.980478] [<ffffffff81527799>] ? thread_return+0x48/0x37f
[ 1320.980483] [<ffffffff8139bbc0>] ? hub_thread+0x0/0x190
[ 1320.980488] [<ffffffff8139bbfa>] hub_thread+0x3a/0x190
[ 1320.980493] [<ffffffff81078b30>] ? autoremove_wake_function+0x0/0x40
[ 1320.980498] [<ffffffff8139bbc0>] ? hub_thread+0x0/0x190
[ 1320.980503] [<ffffffff81078746>] kthread+0xa6/0xb0
[ 1320.980509] [<ffffffff810130ea>] child_rip+0xa/0x20
[ 1320.980514] [<ffffffff810786a0>] ? kthread+0x0/0xb0
[ 1320.980518] ...

[David (david-depowell)]

Anyone have any updates to this problem? As my system stands now, I can make /dev/ttyUSB0 appear by plugging in my Arduino (well, it's a Seeduino, but it still uses the FTDI chip). If I then unplug it, the system log shows the disconnect, but the /dev/ttyUSB0 device is still there. Any attempt to actually *do* anything with the device will just hang.

[tz (thomas-mich)]

if khubd is crashing, nothing else will change. Also check with "lsof" to see if something grabs the /dev/ttyUSB0.

Also, which kernel? uname -a. I'm running the proposed and have no trouble with arduinos or ftdi breakouts. (except RTS-reset, but that's another bug).

[David (david-depowell)]

typing "dmesg |grep khubd" yields"

[ 960.991399] INFO: task khubd:40 blocked for more than 120 seconds.
[ 960.991411] khubd D 0000000000000000 0 40 2 0x00000000
[ 1080.990369] INFO: task khubd:40 blocked for more than 120 seconds.
[ 1080.990381] khubd D 0000000000000000 0 40 2 0x00000000
[ 1200.990359] INFO: task khubd:40 blocked for more than 120 seconds.
[ 1200.990371] khubd D 0000000000000000 0 40 2 0x00000000
[ 1320.990347] INFO: task khubd:40 blocked for more than 120 seconds.
[ 1320.990359] khubd D 0000000000000000 0 40 2 0x00000000

Does that mean it's crashed? It still shows up when I type "ps aux".

If I type "sudo lsof |grep -i usb" I get:

lsof: WARNING: can't stat() fuse.gvfs-fuse-daemon file system /home/david/.gvfs
      Output information may be incomplete.
usbhid_re 382 root cwd DIR 8,17 4096 2 /
usbhid_re 382 root rtd DIR 8,17 4096 2 /
usbhid_re 382 root txt unknown /proc/382/exe
usb-stora 388 root cwd DIR 8,17 4096 2 /
usb-stora 388 root rtd DIR 8,17 4096 2 /
usb-stora 388 root txt unknown /proc/388/exe
hald 978 haldaemon mem REG 8,17 361263 7354 /var/lib/misc/usb.ids
devkit-po 1770 root mem REG 8,17 35944 662 /lib/libusb-0.1.so.4.4.4
gnome-ses 1908 david mem REG 8,17 35944 662 /lib/libusb-0.1.so.4.4.4
gnome-pow 2099 david mem REG 8,17 35944 662 /lib/libusb-0.1.so.4.4.4

"uname -a" gives me:

Linux studyHP 2.6.31-16-generic #53-Ubuntu SMP Tue Dec 8 04:02:15 UTC 2009 x86_64 GNU/Linux

When it gets like this, the only way I've found to get the ttyUSB0 to go away is to reboot.
One more question - do I need to chown the ttyUSB0 device? It always appears as being owned by root. I've tried changing it and that doesn't seem to make any difference.

[tz (thomas-mich)]

My error - you should do lsof -i | grep /dev/ttyUSB0 to see if anything is holding.

If you add "proposed", (in the system->admin->software sourcest) you can get:

Linux tz-hpmini 2.6.31-17-generic #54-Ubuntu SMP Thu Dec 10 16:20:31 UTC 2009 i686 GNU/Linux

which works for me.

[David (david-depowell)]

I was a little hesitant to do that, because last time I did it my computer wouldn't boot any more and I had to reinstall from scratch, because of a bug in grub. But I went ahead and tried it anyway, and sure enough it helped. When I plug and unplug the Arduino, /dev/ttyUSB0 comes and goes with it. So far so good.

However, my "original" problem remains. I tried running avrdude from the command line (via a simple script that I created) to write a hex file to the Arduino. The file simply says:

/usr/bin/avrdude -pm168 -carduino -P/dev/ttyUSB0 -b19200 -v -Uflash:w:Template.hex:a

It actually ran (but failed) on the first try, giving me two lines of "programmer not responding". Remembering what you said about the RTS reset, I tried it again, this time hitting the reset button on the Arduino. This time it hung just like before, where ctl-c was ignored. Ctl-z did pause it, but actually killing it seems impossible. Here's a short transcript of what transpired:

david@studyHP:~/apps$ jobs
[1]- Running tail -f /var/log/messages & (wd: ~)
[2]+ Stopped ./avrdude.sh
david@studyHP:~/apps$ kill -n 9 2
bash: kill: (2) - Operation not permitted
david@studyHP:~/apps$ jobs -l
[1]- 2173 Running tail -f /var/log/messages & (wd: ~)
[2]+ 2211 Stopped ./avrdude.sh
david@studyHP:~/apps$ kill -9 2211
david@studyHP:~/apps$ jobs
[1]- Running tail -f /var/log/messages & (wd: ~)
[2]+ Killed ./avrdude.sh
david@studyHP:~/apps$ jobs
[1]+ Running tail -f /var/log/messages & (wd: ~)
david@studyHP:~/apps$ ps u
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
david 2133 0.0 0.0 21392 4200 pts/0 Ss 19:45 0:00 bash
david 2173 0.0 0.0 9460 832 pts/0 S 19:46 0:00 tail -f /var/log/messages
david 2212 0.0 0.0 0 0 pts/0 D 19:51 0:00 [avrdude]
david 2293 0.0 0.0 15164 1136 pts/0 R+ 20:02 0:00 ps u

As you can see, as far as bash is concerned the job is gone, but ps shows it still there as a zombie.
I disconnected the Arduino, and got "usb 4-1: USB disconnect, address 3" in var/log/messages. However, just like before, the device is still there:

david@studyHP:~/apps$ ls -l /dev/ttyU*
crw-rw---- 1 root dialout 188, 0 2010-01-01 19:51 /dev/ttyUSB0
david@studyHP:~/apps$ lsof -i |grep /dev/ttyUSB0
david@studyHP:~/apps$

If you can actually program your Arduino with 64 bit Ubuntu, I'm not going to give up yet, but man it shouldn't be this hard to do.

David

[tz (thomas-mich)]

Actually I'm only using 32 bit. It should work in 64 though.

[David (david-depowell)]

Well, I spoke too soon. The USB0 device will come and go with plugging/unplugging the Arduino, but only if you don't leave it plugged in too long. I can do a fresh reboot, plug in the Arduino, and if I leave it plugged in for more than about 4 or 5 minutes it will stick again, along with the call trace appearing in the system log.

This is getting really aggravating. Where can I find the source code to the ftdi_sio v1.5.0 USB FTDI Serial Converters Driver?

David

[crispernaki (crisper)]

Not to rub anything in for those folks (@David) who seem to still be having issues, but WHOO-HOO!!! the steps in post #7 @tz and #8 @Kendrick worked for me. 64-bit UbuntuStudio and an Ardunio Mega. Dang... this Linux learning curve busting my chops... one of these days maybe it will all make sense?

Best,

cb

[David (david-depowell)]

Go ahead and gloat - you deserve it! But when you're done, how about being a good, upstanding Linux community member and post some of your system specs so that I can compare them with mine? :^)

Specifically, what kernel are you running ("uname -a") and what processor? A copy of /var/log/messages after a fresh boot (and after plugging in the Arduino) would help too.

David

P.S., I contacted the support engineer at FTDI, and he said that the latest (1.5.0) driver should work fine under 64-bit Ubuntu, but he hasn't actually tried it (says he doesn't have a 64-bit machine to try it on). He also sent the source for that version of the driver. I tried to compile it with the make file that he included, but got a bazillion errors. I'm sure there's some secret incantation I have to add to the makefile to get it to compile under my specific setup, but I have no idea what it is. All of the errors are buried in header files that are already on my system, not in the driver itself. If one of you C++ programmers can help I would be very grateful!

[Brad Campbell (brad-wasp)]

Certainly the driver in the vanilla kernel later than 2.6.31.4 works fine on x86_64.

The Changelog for the latest proposed kernel seems to show the relevant upgrade.

brad@srv:~$ cat /proc/cpuinfo | grep model
model : 2
model name : AMD Phenom(tm) 9750 Quad-Core Processor
<snip>
brad@srv:~$ uname -a
Linux srv 2.6.31.5 #16 SMP Sat Oct 24 12:58:49 WST 2009 x86_64 GNU/Linux
brad@srv:~$ lspci | grep USB
00:0a.0 USB Controller: nVidia Corporation MCP55 USB Controller (rev a1)
00:0a.1 USB Controller: nVidia Corporation MCP55 USB Controller (rev a2)

I don't use an Arduino, I use a Parallax Propeller, but the ftdi device is the same.

[Alain Kalker (miki4242)]

Hotfix from #7/#8 worked for me

$ uname -a
Linux miki-desktop 2.6.31-16-generic #53-Ubuntu SMP Tue Dec 8 04:01:29 UTC 2009 i686 GNU/Linux

Using a Smargo Smartreader+.

Before the fix:
$ ./srp_tools_x86
no smartreader found

After the fix:
$ ./srp_tools_x86
smartreader+ version v1.3

MODE autoswitch
FREQ 3.69 Mhz
KERNEL normal
T_MODE t = 0
EGT 0

Forums are full of posts from people who cannot get at ther smartreaders, an I can imagine lots of people think their stuff is broken and are sending them back to sellers by the truckload. Given the bazillions of VIDs/PIDs the ftdi_sio module serves (.lots. of hardware, including PC/SC smartcard authentication stuff!), could someone .please. upgrade the priority of this fix? Many, many thanks in advance!

[David (david-depowell)]

@Kendric (#17):

Although this compiled and installed, it didn't fix my problem. I contacted FTDI directly, and the engineer there said that the latest driver (v 1.5.0) should work fine with 64-bit Karmic. He sent me a link to the driver source - http://www.ftdichip.com/Drivers/VCP/Linux/ftdi_sio.tar.gz which I downloaded.

Although the driver that you kindly provided shows to be version 1.5.0 as well, there are major differences between it and the one I got from FTDI. Do you know why? It seems that if changes were made, then the version would be different. I tried to compile the "official" FTDI version, but got a bazillion errors. I even tried replacing the source in your fix with the "official" source and it still wouldn't compile.

I'm getting desperate to get this working.

[Kendrick Shaw (kms15)]

@David (#30)

Unfortunately it looks like the drivers on the ftdi site may not work with newer versions of the kernel, including the kernel in karmic. The ftdi_sio.h and .c I grabbed were from the linux kernel tree (version 2.6.31.8). A number of changes seem to have been made without increasing the version number - lots of reformatting and rearrangement (which makes it hard to diff), but also a much longer list of supported device ids. Running the modified version of tz's makefile with the ftdi version also gives a list of errors which look like the result of changes to the usb structure in newer kernels (references to the fields tty and open_count that aren't in the usb_serial_port structure in the kernel headers). I'm not an expert in kernel drivers, however, so there may be an easy way to update this driver that I'm missing.

To be honest, I'm worried that you're grappling with an additional bug (e.g. a bug in the driver for your usb chipset) in addition to the FTDI bug the rest of us had. It sounds like the symptoms you are encountering are somewhat different than what the rest of us had, and the fix that worked for the rest of us (tz's) isn't working for you. I've been hesitant to suggest this, however, because I don't have a good suggestion of how to fix this new bug. Doing a search on "khubd karmic" turns up a lot of bugs with similar symptoms, many of which are unresolved. It's not clear to me which (if any) match the problem you're encountering, however; this looks like it may just be a common mode of failure.

It may be worth doing some additional searches based on your laptop model and usb chipset to see if any existing bug seems to match what you're seeing. If not, it may be worth opening a new bug.

[Leann Ogasawara (leannogasawara)]

Hi Brad Campbell,

Since you are the original bug reporter, can you test and confirm this is resolved with the most reset 2.6.31-17.54 update? The reason I say this is because the 2.6.31-17.54 kernel was rebased with the 2.6.31.5 and 2.6.31.6 upstream stable kernel:

https://edge.launchpad.net/ubuntu/+source/linux/2.6.31-17.54

Based on your original description in this bug report, I'd consider this issue Fix Released. As as result I am marking it as such unless I hear back from you mentioning otherwise. Thanks.

[Leann Ogasawara (leannogasawara)]

I'm also closing the upstream kernel bug watch. Thanks.

[Brad Campbell (brad-wasp)]

Can confirm problem does not exist in 2.6.31-17.54. Thanks.

[tz (thomas-mich)]

The kernel in proposed ...-18 also seems to fix the DTR reset with the Arduino, at least with the current avrdude software. I don't have to hit the reset button!.

[M66B (m66b)]

My Smargo Smartreader plus still does not work using kernel 2.6.31-17.54 and also not with the patch from #8. The problem seems to be related to resetting. Maybe kernel 2.6.31-18 solves this problem (see comment #35), but I haven't tried that yet.

Output from sasc-ng:

Jan 20 19:01:38.198 CAM(core.smartcard): 0: new card inserted
Jan 20 19:01:38.488 CAM(core.smartcard): 0: reseting card (sermode 8e2)
Jan 20 19:01:40.601 CAM(core.smartcard): 0: reset/atr error
Jan 20 19:01:40.888 CAM(core.smartcard): 0: reseting card (sermode 8o2)
Jan 20 19:01:42.042 CAM(core.smartcard): 0: <- ATR len=2: a1 c9
Jan 20 19:01:42.042 CAM(core.smartcard): 0: byte mode not supported 0xa1
Jan 20 19:01:42.042 CAM(core.smartcard): 0: reset/atr error
Jan 20 19:01:42.328 CAM(core.smartcard): 0: reseting card (sermode 8n2)
Jan 20 19:01:43.478 CAM(core.smartcard): 0: <- ATR len=2: a1 c9
Jan 20 19:01:43.478 CAM(core.smartcard): 0: byte mode not supported 0xa1
Jan 20 19:01:43.479 CAM(core.smartcard): 0: reset/atr error
Jan 20 19:01:43.479 CAM(core.smartcard): 0: can't initialise new card, ignoring port until card reinserted

[Mikael Magnusson (mikma)]

My VLSystem MPlay Blast mini remote control doesn't work with kernel 2.6.31-17.54 without the patch in comment #13.

[sigvdr (sig)]

I also can not connet to a FDTI device ( 232BM - Chip ) :
Error: Serial Port: Timeout waiting for data
/dev/ttyUSB0 is connected / disconnected every time i plug or unplug this device

Kernel: 2.6.31-19-generic #56-Ubuntu
The ftdifix from #8 does not help and does not change anything

lsmod | grep ftdi gives me
ftdi_sio xxxxxx 0
usbserial xxxxxx 1 ftdi_sio

On an other PC with Ubuntu 8.04 LTS the FTDI Device works perfect.
lsmod | grep ftdi gives me
ftdi_sio xxxxxx 0
usbserial xxxxxx 1 ftdi_sio
usbcore xxxxxx 7 ftdi_sio,usbserial,.......

Do i need this missing "usbcore" modul in Karmic to get my FTDI device working or is usbcore not longer required?

[sigvdr (sig)]

Today i have got a kernel update to 2.6.1.20 #58 and now all works perfect.

[Mikael Magnusson (mikma)]

Kernel 2.6.31-20.58 works for me also.

[Debabrata Banerjee (dbavatar)]

I'm running kernel "2.6.32-22-generic #36-Ubuntu SMP Thu Jun 3 19:31:57 UTC 2010 x86_64" and I'm still affected by the nearly the same problem. Although I can get some data, after a few seconds of data I end up in the same state and no data will pass. All subsequent close/open's on /dev/ttyUSB0 will block forever and the parent process will zombie. Quite annoying as I have no IR remote control after upgrading my mythbuntu :(

[ 960.770389] INFO: task irserver64:2122 blocked for more than 120 seconds.
[ 960.770397] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[ 960.770404] irserver64 D ffffffff81557ea0 0 2122 2111 0x00000000
[ 960.770416] ffff8800111b9a38 0000000000000046 0000000000015bc0 0000000000015bc0
[ 960.770426] ffff880026a8c890 ffff8800111b9fd8 0000000000015bc0 ffff880026a8c4d0
[ 960.770435] 0000000000015bc0 ffff8800111b9fd8 0000000000015bc0 ffff880026a8c890
[ 960.770443] Call Trace:
[ 960.770459] [<ffffffff813d4d85>] usb_kill_urb+0x85/0xc0
[ 960.770470] [<ffffffff81085320>] ? autoremove_wake_function+0x0/0x40
[ 960.770496] [<ffffffffa015d070>] ftdi_close+0x40/0x80 [ftdi_sio]
[ 960.770512] [<ffffffffa0138941>] serial_down+0x71/0x80 [usbserial]
[ 960.770524] [<ffffffffa0138c6e>] serial_close+0x7e/0xc0 [usbserial]
[ 960.770536] [<ffffffff8132ac23>] tty_release_dev+0x163/0x5e0
[ 960.770544] [<ffffffff81181da9>] ? locks_delete_lock+0x79/0xa0
[ 960.770553] [<ffffffff81540f1d>] ? unlock_kernel+0x2d/0x40
[ 960.770560] [<ffffffff81182023>] ? locks_remove_flock+0xe3/0x120
[ 960.770567] [<ffffffff8118269b>] ? vfs_lock_file+0x3b/0x40
[ 960.770574] [<ffffffff81182731>] ? locks_remove_posix+0x91/0xc0
[ 960.770582] [<ffffffff8132b0be>] tty_release+0x1e/0x30
[ 960.770590] [<ffffffff81144305>] __fput+0xf5/0x210
[ 960.770597] [<ffffffff81144445>] fput+0x25/0x30
[ 960.770604] [<ffffffff8114053d>] filp_close+0x5d/0x90
[ 960.770613] [<ffffffff81068d8f>] put_files_struct+0x7f/0xf0
[ 960.770621] [<ffffffff81068e54>] exit_files+0x54/0x70
[ 960.770628] [<ffffffff8106b3ab>] do_exit+0x14b/0x380
[ 960.770636] [<ffffffff8106b635>] do_group_exit+0x55/0xd0
[ 960.770645] [<ffffffff8107bf77>] get_signal_to_deliver+0x1d7/0x3d0
[ 960.770654] [<ffffffff81012a35>] do_signal+0x75/0x1c0
[ 960.770664] [<ffffffff812b736d>] ? __up_write+0xdd/0x150
[ 960.770673] [<ffffffff81153b98>] ? poll_select_copy_remaining+0xf8/0x150
[ 960.770682] [<ffffffff81012bdd>] do_notify_resume+0x5d/0x80
[ 960.770690] [<ffffffff8101347e>] int_signal+0x12/0x17

[Richard Seguin (p1re1)]

Regression in 2.6.32-35. Exact same symptoms.

[Kendrick Shaw (kms15)]

I'm also seeing the regression reported by @richard (#42). In particular, the software for the Syscomp CGR-101 isn't seeing the scope on a 64 bit Ubuntu Maverick 10.10. Building the latest version of the ftdio_sio driver from the 2.6.35-8 linux tree didn't fix the bug, but porting the version @tz (#7) found to the new kernel fixed the issue. I've attached the ported version of the older driver for those who need a fix now. The install instructions are the same as before:

To install:
1) open a terminal window
2) install the latest kernel headers:

# sudo apt-get install linux-headers-generic

3) download and uncompress the attached file ftdifix.backport.maverick.tar.gz
4) change to the directory where you uncompressed the file, e.g.

# cd ftdifix.backport.maverick

5) build the driver:

# make

6) install the driver

# sudo make install

Until this is fixed, you may have to repeat these steps each time you install a new version of the kernel.

This isn't a good long-term fix, however - there have been a lot of changes to the driver, many of which add support for new devices. The right fix is probably to do a bisection on the kernel checkins to find the one that broke this driver for this scenario, and then report the bug upstream (ideally with a patch). I'll start the process but I'm not sure how much time I'll be able to devote to it - if some else wants to give this a try, feel free.

[Debabrata Banerjee (dbavatar)]

Kendrick: negative, same hang for me. I think this has been broken for a long time, but different timing in the newer kernels (2.6.28+) seems to make it much much worse.

[Matt Mets (matt-mets)]

I'm seeing behavior like this too. I'm running the 32-bit version of 10.10 on an Acer Aspire X3400, with kernel version:
2.6.35-23-generic #41-Ubuntu SMP

and an nVidia USB controller:
lspci | grep USB
00:02.0 USB Controller: nVidia Corporation MCP78S [GeForce 8200] OHCI USB 1.1 Controller (rev a1)
00:02.1 USB Controller: nVidia Corporation MCP78S [GeForce 8200] EHCI USB 2.0 Controller (rev a1)
00:04.0 USB Controller: nVidia Corporation MCP78S [GeForce 8200] OHCI USB 1.1 Controller (rev a1)
00:04.1 USB Controller: nVidia Corporation MCP78S [GeForce 8200] EHCI USB 2.0 Controller (rev a1)

The kernel log looks like this:

When the device is inserted:
[ 263.624073] usb 3-4: new full speed USB device using ohci_hcd and address 5
[ 263.858104] ftdi_sio 3-4:1.0: FTDI USB Serial Device converter detected
[ 263.858164] usb 3-4: Detected FT232RL
[ 263.858170] usb 3-4: Number of endpoints 2
[ 263.858176] usb 3-4: Endpoint 1 MaxPacketSize 64
[ 263.858181] usb 3-4: Endpoint 2 MaxPacketSize 64
[ 263.858186] usb 3-4: Setting MaxPacketSize 64
[ 263.861051] usb 3-4: FTDI USB Serial Device converter now attached to ttyUSB0

The FTDI chip works for a while, then stops transmitting data. When I try to close our java-based program that is using USB (ReplicatorG), I get this:
[ 720.488759] INFO: task java:2099 blocked for more than 120 seconds.
[ 720.488768] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[ 720.488775] java D f388fe1c 0 2099 1989 0x00000000
[ 720.488788] f388fe2c 00200086 00000002 f388fe1c 00000000 c05d89e0 c08c3700 c08c3700
[ 720.488804] 45cf69b9 0000007f c08c3700 c08c3700 45ced064 0000007f 00000000 c08c3700
[ 720.488818] c08c3700 f4434c20 00000001 f6453780 f6453788 f388fe34 f388fe54 c0471f7d
[ 720.488832] Call Trace:
[ 720.488849] [<c0471f7d>] usb_kill_urb+0x6d/0xa0
[ 720.488861] [<c0165eb0>] ? autoremove_wake_function+0x0/0x50
[ 720.488871] [<c047314c>] usb_start_wait_urb+0xac/0xc0
[ 720.488880] [<c04736e4>] usb_control_msg+0xc4/0x130
[ 720.488890] [<c04f537f>] ? __netif_receive_skb+0x33f/0x530
[ 720.488903] [<f81768ca>] ftdi_tiocmget+0xda/0x1ac [ftdi_sio]
[ 720.488916] [<f82ab14b>] serial_tiocmget+0x3b/0x80 [usbserial]
[ 720.488925] [<c03d9466>] tty_ioctl+0x2a6/0x620
[ 720.488933] [<c035a749>] ? copy_to_user+0x39/0x130
[ 720.488941] [<c0226a22>] vfs_ioctl+0x32/0xb0
[ 720.488948] [<c03d91c0>] ? tty_ioctl+0x0/0x620
[ 720.488955] [<c02272b9>] do_vfs_ioctl+0x79/0x2d0
[ 720.488961] [<c0227577>] sys_ioctl+0x67/0x80
[ 720.488970] [<c05c99f4>] syscall_call+0x7/0xb
[ 840.488110] INFO: task java:2099 blocked for more than 120 seconds.
[ 840.488119] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.

Kendrik's proposed workaround in #43 seems to recover a little better, but eventually this happens again.

[lokidiabel (viperus)]

I have the same Problem with different Cardreaders.
Samrgo and also pcscd devices. They suddenly stop working.

Can anyone take care of that Bug ?! Its open since 2009-10-26 !!!!

Greetings

Loki

[David (david-depowell)]

Yes, please! This is such a common USB chip that I can't believe this is still not working. I have several devices that I can't use unless I plug them into my Windows machine.

[Debabrata Banerjee (dbavatar)]

It's not broken on just ubuntu, it's broken everywhere. There is no current maintainer of the FTDI driver. I started to look at it but it's going to take several days of learning how the USB stack works before I can even think of doing a fix.

[lokidiabel (viperus)]

If you need more logfiles just say.

We will provide you with the needed stuff

[lokidiabel (viperus)]

Can anyone confirm that a manual Kernel update with the Kernel from kernel.org works ?!

[lokidiabel (viperus)]

Error still ocurse @Kernel 2.6.37-11.

[halo (sor-row)]

the bug also occurs since kernel >=2.6.32-25 (10.04x64 server). its not possible to use a MCR8 via USB.

[Steve Conklin (sconklin)]

This is going to have to be fixed upstream before we can even consider backporting the fix to current Ubuntu kernels.

[Launchpad Janitor (janitor)]

[Expired for linux (Ubuntu) because there has been no activity for 60 days.]