devkit-power keeps /dev/ttyUSB0 open, misdetecting Watts-Up power monitor

Bug #507247 reported by adrian
42
This bug affects 8 people
Affects Status Importance Assigned to Milestone
devicekit-power (Ubuntu)
Confirmed
Undecided
Unassigned

Bug Description

Binary package hint: devicekit-power

I have been unable to use certain USB serial devices unless I sudo, despite being in the dialout group.

The error reported is Device or Resource Busy. I have determined that the device is being opened by devkit-power, apparently because it believes it to be a Watts-Up power monitor. It's actually a Parallax Prop-clip, which is very little more
than an FTDI usb-uart.

$ devkit-power --monitor-detail
Monitoring activity from the power daemon. Press Ctrl+C to cancel.
device added: /org/freedesktop/DeviceKit/Power/devices/monitor_ttyUSB0
  native-path: /sys/devices/pci0000:00/0000:00:07.2/usb1/1-2/1-2:1.0/ttyUSB0/tty/ttyUSB0
  vendor: Watts Up, Inc.
  model: Watts Up? Pro
  power supply: no
  updated: Thu Jan 1 01:00:00 1970 (1263422148 seconds ago)
  has history: yes
  has statistics: no
  monitor
    energy-rate: 0 W
  History (charge):
    1263422148 0.000 unknown
  History (rate):
    1263422148 0.000 unknown

The device uses an FTDI serial converter. I have several devices with this chip : some are detected as the power monitor
and some are not. Here is dmesg for the one detected above:

[ 3966.920076] usb 1-2: new full speed USB device using uhci_hcd and address 13
[ 3967.106890] usb 1-2: configuration #1 chosen from 1 choice
[ 3967.117273] ftdi_sio 1-2:1.0: FTDI USB Serial Device converter detected
[ 3967.117361] usb 1-2: Detected FT232RL
[ 3967.117369] usb 1-2: Number of endpoints 2
[ 3967.117376] usb 1-2: Endpoint 1 MaxPacketSize 64
[ 3967.117383] usb 1-2: Endpoint 2 MaxPacketSize 64
[ 3967.117389] usb 1-2: Setting MaxPacketSize 64
[ 3967.126905] usb 1-2: FTDI USB Serial Device converter now attached to ttyUSB0

and sudo lsusb -v

Bus 001 Device 018: 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 A8007b1Z
  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)

Here is dmesg for a different one that works without problems with the power devkit, actually an Arduino clone again
fitted with an FTDI usb uart.

[ 4175.240068] usb 1-2: new full speed USB device using uhci_hcd and address 14
[ 4175.425029] usb 1-2: configuration #1 chosen from 1 choice
[ 4175.435654] ftdi_sio 1-2:1.0: FTDI USB Serial Device converter detected
[ 4175.435789] usb 1-2: Detected FT232RL
[ 4175.435797] usb 1-2: Number of endpoints 2
[ 4175.435805] usb 1-2: Endpoint 1 MaxPacketSize 64
[ 4175.435811] usb 1-2: Endpoint 2 MaxPacketSize 64
[ 4175.435818] usb 1-2: Setting MaxPacketSize 64
[ 4175.437808] usb 1-2: FTDI USB Serial Device converter now attached to ttyUSB0

Bus 001 Device 019: 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 A6008dXL
  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)

It also appears that the driver may be sending some async data to the device. I don't know if it's probing it or
attempting to communicate having already determined it to be a Watts-Up. The latter may be hard to fix, but I
am very unhappy about probing arbitrary devices with FTDI interfaces. They could be anything.

lsb_release -rd
Description: Ubuntu 9.10
Release: 9.10

apt-cache policy devicekit-power
devicekit-power:
  Installed: 011-1ubuntu1
  Candidate: 011-1ubuntu1
  Version table:
 *** 011-1ubuntu1 0
        500 http://gb.archive.ubuntu.com karmic/main Packages
        100 /var/lib/dpkg/status

Revision history for this message
Eric Sorton (esorton) wrote :

I am affected by this bug as well with a different device. I experience identical behavior when I connect the serial console on a Gumstix Tobi board to my Ubuntu Karmic installation. The problem was not present in the previous version so this is a regression. I also have multiple FTDI devices where some are detected as the Watt's Up and some are not.

A bit of digging turned up the following file:

/lib/udev/rules.d/95-devkit-power-wup.rules

which contains:

SUBSYSTEM=="tty", SUBSYSTEMS=="usb", ATTRS{idVendor}=="0403", ATTRS{idProduct}=="6001", ATTRS{serial}=="A80?????", ENV{DKP_VENDOR}="Watts Up, Inc.", ENV{DKP_PRODUCT}="Watts Up? Pro", ENV{DKP_MONITOR_TYPE}="wup"

Thus, the FTDI driver is identified as a Watt's Up if idVendor is 0403, idProduct is 6001 and serial is A80??????.

To view the serial number of a device, use:

% udevadm info -a -p $(udevadm info -q path -n /dev/ttyUSB0)

Replacing /dev/ttyUSB0 with your serial port.

For the FTDI device that is misidentified, the serial is A80093Q1. For the FTDI device that is not misidentified, the serial is 0000:00:1a.7. It appears the line in 95-devkit-power-wup.rules is a bit too aggressive in identifying the Watt's Up device.

A temporary workaround is to comment the line in 95-devkit-power-wup.rules and restart udev.

Revision history for this message
adrian (adrianub) wrote :

Thank you for digging, the rules are indeed the problem.
I found the rule too, eventually, but as far as I can tell it's only documented in the sources of the module.

As you say, the serial number is far too wide a match : devices with a serial number in that range are widely used.

I would suggest that the default FTDI serial numbers are never going to be suitable for use as an identifying range unless a manufacturer buys them that way .. and it would be a lot easier to simply put a manufacturer-specific string in there, which is easily supported at no cost by FTDI's tools.

I don't see how a generic rule can therefore be written for this sort of device : if it can't be identified uniquely from the USB details then the user needs to get involved (perhaps by choosing a rule script from a list, and confirming the serial number of the specific device).

Revision history for this message
adrian (adrianub) wrote :

Actually, the rules file is quite old. I'm not sure why it's only just showeed up in this form, but I think some changes to usbserial have affected the ability to have more than one application using the device. This may have been there previously (or perhaps from the point where devicekit took over from HAL) but it has only recently generated the 'device busy' error.

I think modem-manager generated a similar fault but has now been fixed.

I'd be interested in knowing what the changes were in usbserial or ftdi drivers, and what they were intended to do - I think another problem with blocking reads has recently been fixed.

Revision history for this message
sam tygier (samtygier) wrote :

also seems to cause problems for connection an arduino

Changed in devicekit-power (Ubuntu):
status: New → Confirmed
Revision history for this message
sam tygier (samtygier) wrote :

the offending file rules file is now called /lib/udev/rules.d/95-upower-wup.rules . deleting it allows me to program the arduino.

Revision history for this message
Ben Gamari (bgamari) wrote :

I have filed bug #33846 against upower although in my experience the upower maintainers have not been the most responsive. In the meantime, can we please patch out this rule?

Revision history for this message
Ben Gamari (bgamari) wrote :

To clarify, that is a freedesktop.org bug[1].

[1] https://bugs.freedesktop.org//show_bug.cgi?id=33846

Revision history for this message
Matthieu Herrb (matthieu-herrb) wrote :
Revision history for this message
adrian (adrianub) wrote :

The debian report claims it's fixed in 0.9.5-5, but I am still seeing the port grabbed as default behaviour in 0.9.9-4, shipped with Ubuntu 11.04

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

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