arduino USB serial device breaks on lucid kernel upgrade

[Alex Chiang]

Filing bug report on behalf of someone else.

With Lucid kernel 2.6.32-24.43, the device and attached program work correctly.

Upon upgrading to 2.6.32-25.45, the program stops working.

The device is:
Bus 001 Device 005: ID 0403:6001 Future Technology Devices International, Ltd FT232 USB-Serial (UART) IC

A quick driveby browse of recent commits in that time window suggests this might be related, but this is merely a guess based on inspection. No bisection was done.

http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=677aeafe19e88c282af74564048243ccabb1c590

lspci, lsusb, and test code to follow.

[Alex Chiang (achiang)]

This is the linux userspace program that broke after the kernel update.

[Alex Chiang (achiang)]

This is the code that gets loaded onto the arduino.

The reporter says that a basic "hello world" arduino program might be sufficient to prove breakage too, as long as the "hello world" does both input and output.

[Hugh Blemings (hughhalf)]

Had a look at this bug prompted by a request from Alex as I've had some modest experience with Arduino devices and USB serial interfaces as well, albiet a long time ago. I _do_not_ consider myself expert in either however! :)

Couple of observations...

Firstly, the comments in the patch referenced are:

----- 8< ----- 8< ----- 8< ----- 8< ----- 8< ----- 8< -----

This reverts commit 6a1a82df91fa0eb1cc76069a9efe5714d087eccd.

RTS and DTR should not be modified based on CRTSCTS when calling
set_termios.

Modem control lines are raised at port open by the tty layer and should stay
raised regardless of whether hardware flow control is enabled or not.

This is in conformance with the way serial ports work today and many
applications depend on this behaviour to be able to talk to hardware
implementing hardware flow control (without the applications actually using
it).

Hardware which expects different behaviour on these lines can always
use TIOCMSET/TIOCMBI[SC] after port open to change them.

----- 8< ----- 8< ----- 8< ----- 8< ----- 8< ----- 8< -----

So it is significant in that it changes behaviour of the kernel back to the way it used to be - ie there was only a short window when the HW flow control lines worked "the other way"

It's also signed off by gkh and a couple of other folk who have a good deal of expertise with serial devices.

Secondly, the FTDI chips in question are used in a multitude of devices, so if the behaviour had long been incorrect, it would, presumably, have affected many other bits of hardware, not just Arduinos.

I suspect some modification to the user space app to explicitly set the HW lines as required may be the correct solution rather than reverting this patch.

Happy to have more of a dig if need be - do have Arduino hardware about and can fish out a Lucid machine if need be.

[Alex Williamson (alex-l-williamson)]

Just to be clear, 677aeafe19e88c282af74564048243ccabb1c590 is NOT in the lucid kernel, while 6a1a82df91fa0eb1cc76069a9efe5714d087eccd is. So lucid is carrying a patch that has been reverted upstream and as described, changes the kernel back to the previous way of working. Git says it was added to lucid in Ubuntu-2.6.32-24.39-110-g55b5b54, which coincides with when the device stopped working.

[Aleksandr Koltsoff (czr)]

https://bugs.launchpad.net/ubuntu/+source/linux/+bug/655868 might be very well related to this one.

[Hugh Blemings (hughhalf)]

Thanks for the additional info Alex and Aleksandr.

Have sent an email to <email address hidden> recommending this patch also be applied (thus removing the change) for both lucid and maverick. Will see how we go.

[Tim Gardner (timg-tpi)]

Lucid fix coming via stable 2.6.32.27

[Tim Gardner (timg-tpi)]

Maverick fix coming via stable 2.6.35.9

[Oliver Grawert (ogra)]

i'm seeing the same issue with linux-image-2.6.33-502-omap (2.6.33-502.10) under lucid, could the fix be added to that kernel too please ?

[Oliver Grawert (ogra)]

https://launchpad.net/ubuntu/lucid/+source/linux/2.6.32-27.49 doesnt show the fix in the changelog, when is it coming for lucid x86/amd64 ?

[Tim Gardner (timg-tpi)]

Oliver - the patch is in the next batch of stable updates for Lucid and Maverick.

[Brad Figg (brad-figg)]

This patch was applied to Maverick as part of an upstream stable update, therefore it doesn't require individual verification.

[Launchpad Janitor (janitor)]

This bug was fixed in the package linux - 2.6.35-25.44

---------------
linux (2.6.35-25.44) maverick-proposed; urgency=low

  [ Upstream Kernel Changes ]

  * Revert "drm/radeon/kms: properly compute group_size on 6xx/7xx"
    - LP: #703553

linux (2.6.35-25.43) maverick-proposed; urgency=low

  [ Brad Figg ]

  - LP: #697948

  [ Andy Whitcroft ]

  * [Config] add vmware-balloon driver to -virtual flavour
    - LP: #592039

  [ Manoj Iyer ]

  * SAUCE: Enable jack sense for Thinkpad Edge 13
    - LP: #685015

  [ Robert Hooker ]

  * Revert "(pre-stable): input: Support Clickpad devices in ClickZone
    mode"
    - LP: #669399

  [ Stefan Bader ]

  * Set virtual flavour maximum of domain visible memory to 70G
    - LP: #667796

  [ Takashi Iwai ]

  * SAUCE: input: Support Clickpad devices in ClickZone mode
    - LP: #516329

  [ Tim Gardner ]

  * [Config] Add nfsd modules to -virtual flavour
    - LP: #688070
  * [Config] Added autofs4.ko to -virtual flavour
    - LP: #692917

  [ Upstream Kernel Changes ]

  * intel_idle: delete substates DEBUG modparam
    - LP: #684888
  * intel_idle: delete power_policy modparam, and choose substate functions
    - LP: #684888
  * intel_idle: add support for Westmere-EX
    - LP: #684888
  * intel_idle: recognize Lincroft Atom Processor
    - LP: #684888
  * x86, mwait: Move mwait constants to a common header file
    - LP: #684888
  * intel_idle: Change mode 755 => 644
    - LP: #684888
  * intel_idle: add missing __percpu markup
    - LP: #684888
  * cpuidle: extend cpuidle and menu governor to handle dynamic states
    - LP: #684888
  * intel_idle: Voluntary leave_mm before entering deeper
    - LP: #684888
  * intel_idle: enable Atom C6
    - LP: #684888
  * intel_idle: simplify test for leave_mm()
    - LP: #684888
  * intel_idle: delete bogus data from cpuidle_state.power_usage
    - LP: #684888
  * intel_idle: add initial Sandy Bridge support
    - LP: #684888
  * intel_idle: do not use the LAPIC timer for ATOM C2
    - LP: #684888
  * staging: usbip: Notify usb core of port status changes
    - LP: #686158
  * staging: usbip: Process event flags without delay
    - LP: #686158
  * Staging: phison: fix problem caused by libata change
    - LP: #686158
  * perf_events: Fix bogus AMD64 generic TLB events
    - LP: #686158
  * perf_events: Fix bogus context time tracking
    - LP: #686158
  * powerpc/perf: Fix sampling enable for PPC970
    - LP: #686158
  * pcmcia: synclink_cs: fix information leak to userland
    - LP: #686158
  * sched: Drop all load weight manipulation for RT tasks
    - LP: #686158
  * sched: Fix string comparison in /proc/sched_features
    - LP: #686158
  * bluetooth: Fix missing NULL check
    - LP: #686158
  * futex: Fix errors in nested key ref-counting
    - LP: #686158
  * cifs: fix broken oplock handling
    - LP: #686158
  * libahci: fix result_tf handling after an ATA PIO data-in command
    - LP: #686158
  * mm, x86: Saving vmcore with non-lazy freeing of vmas
    - LP: #686158
  * x86, cpu: Fix renamed, not-yet-shipping AMD CPUID feature bit
    - LP: #686158
  * x86, kexec: Make sure to stop all CPUs before exiting the kernel
    - LP: #686158
  * x86, olpc: Don...

[Vince McIntyre (vmcintyr)]

Unfortunately the fix seems to be incomplete for me.

$ cat /proc/version_signature
Ubuntu 2.6.32-28.55-generic 2.6.32.27+drm33.12
$ uname -a
Linux ubuntu 2.6.32-28-generic #55-Ubuntu SMP Mon Jan 10 21:21:01 UTC 2011 i686 GNU/Linux

Reverting the commit 55b5b5448771f964776a716227afd3ddef2c860e does help, but it appears that another regression has appeared in the meantime. After about 18h I start getting this error from digitemp (I am calling it from cron once every 15min)

Error 5: DS2480B Adapter Not Detected
Error 10: Read COM Failed
Error 10: Read COM Failed
Error 10: Read COM Failed
Error 10: Read COM Failed
Error 10: Read COM Failed
Error 10: Read COM Failed
Error 10: Read COM Failed
Error 10: Read COM Failed
Error 10: Read COM Failed

Once the system gets into this state, it persists until reboot.

I do not see this problem with 2.6.32-26-generic, patched so that 55b5b5448771f964776a716227afd3ddef2c860e is reverted.

lsusb still sees the device:
$ lsusb
Bus 005 Device 003: ID 046d:c03d Logitech, Inc. M-BT96a Pilot Optical Mouse
Bus 005 Device 002: ID 0403:6001 Future Technology Devices International, Ltd FT232 USB-Serial (UART) IC
Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 002 Device 003: ID 413c:2003 Dell Computer Corp. Keyboard
Bus 002 Device 002: ID 03f0:3611 Hewlett-Packard PSC 2410 PhotoSmart
Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

$ sudo lsusb -v -d 0403:6001

Bus 005 Device 002: 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 A900a3DX
  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 ...

[Vince McIntyre (vmcintyr)]

strace of digitemp to illustrate the behaviour:
 * on 2.6.32-26-generic with 55b5b5448771f964776a716227afd3ddef2c860e reverted

[Vince McIntyre (vmcintyr)]

strace on 2.6.32-28-generic with device not working

[Vince McIntyre (vmcintyr)]

strace on 2.6.32-28-generic with device working

[Vince McIntyre (vmcintyr)]

oops - re #17 - the trace attached there is for 2.6.32-22-generic, well before this whole mess started.

[Vince McIntyre (vmcintyr)]

Hm. The changelog in the package I installed (linux-image-2.6.32-28-generic 2.6.32-28.55) shows this:

linux (2.6.32-28.50) lucid-proposed; urgency=low

  [ Tim Gardner ]
...

  [ Upstream Kernel Changes ]

...
  * USB: ftdi_sio: revert "USB: ftdi_sio: fix DTR/RTS line modes"
    - LP: #688669

and does not mention this bug at all.

[Josef Kraitz (josef-kraitz)]

well, this does not work in Maveric with /Ubuntu 2.6.35-25.44-generic 2.6.35.10/ either
- the "Unable to write latency timer: -32" error from dmesg is gone now, but the port seem to hang after a few commands are send through successfully and only a reboot brings it back to life - though again just for a few commands.

root@area73:~# cat /proc/version_signature
Ubuntu 2.6.35-25.44-generic 2.6.35.10
root@area73:~# dmesg|tail
[ 5.614172] type=1400 audit(1296350133.003:9): apparmor="STATUS" operation="profile_load" name="/usr/lib/cups/backend/cups-pdf" pid=852 comm="apparmor_parser"
[ 5.615221] type=1400 audit(1296350133.003:10): apparmor="STATUS" operation="profile_load" name="/usr/sbin/cupsd" pid=852 comm="apparmor_parser"
[ 5.701769] input: HDA Intel Mic at Ext Front Jack as /devices/pci0000:00/0000:00:1b.0/sound/card0/input5
[ 5.702070] input: HDA Intel HP Out at Ext Front Jack as /devices/pci0000:00/0000:00:1b.0/sound/card0/input6
[ 5.842302] ppdev: user-space parallel port driver
[ 6.854876] jme 0000:02:00.5: eth0: Link is up at ANed: 100 Mbps, Full-Duplex, MDI.
[ 6.855765] ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
[ 7.625367] EXT4-fs (sda1): re-mounted. Opts: errors=remount-ro,usrjquota=aquota.user,jqfmt=vfsv0,commit=0
[ 7.749133] ===>rtllib_wx_set_power(): power disable
[ 17.824088] eth0: no IPv6 routers present
root@area73:~# lsusb
Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 004 Device 002: ID 0403:e0e8 Future Technology Devices International, Ltd
Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
root@area73:~# lsusb -d 0403:e0e8 -v

Bus 004 Device 002: ID 0403:e0e8 Future Technology Devices International, Ltd
Device Descriptor:
  bLength 18
  bDescriptorType 1
  bcdUSB 1.10
  bDeviceClass 0 (Defined at Interface level)
  bDeviceSubClass 0
  bDeviceProtocol 0
  bMaxPacketSize0 8
  idVendor 0x0403 Future Technology Devices International, Ltd
  idProduct 0xe0e8
  bcdDevice 2.00
  iManufacturer 1 ELV AG
  iProduct 2 ELV FHZ 1300 PC
  iSerial 3 EL64JQYI
  bNumConfigurations 1
  Configuration Descriptor:
    bLength 9
    bDescriptorType 2
    wTotalLength 32
    bNumInterfaces 1
    bConfigurationValue 1
    iConfiguration 0
    bmAttributes 0xa0
      (Bus Powered)
      Remote Wakeup
    MaxPower 44mA
    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 ELV FHZ 1300 PC
      Endpoint Descriptor:
        bLength 7
     ...

[Vince McIntyre (vmcintyr)]

After watching & waiting a bit, I've seen no more errors of the type I described in #16. I've rebooted and done a replugging test or two and it's all been solid.

Coincidentally one of my 1-wire sensors died but I got quite different error messages from that and it seems clear that the ftdi_sio module was not at fault.

I'll give it a few more days and let you know if I see a recurrence.

[Alex Williamson (alex-l-williamson)]

Fix confirmed on Lucid 2.6.32-28.55. Arduino is back to working.

[Aleksandr Koltsoff (czr)]

Our FTDI devices seem to work as well over here, based on short testing (with 2.6.32-28 on x86-64).

[Vince McIntyre (vmcintyr)]

No further problems here, so it seems it is fixed for me. Thanks!

[Josef Kraitz (josef-kraitz)]

OK, looks like there was as well a problem with the (custom, not ubuntu related) program setting up the serial port under certain circumstances - with the fix for this bug and a fix of the custom program, my FHZ 1300 PC device now works correctly with /Ubuntu 2.6.35-25.44-generic 2.6.35.10/ as well.
Thanks!

[Tim Gardner (timg-tpi)]

Released with 2.6.32-28.50, fix came in via stable updates.