USB device attached to different ttyUSB after resume from suspend to RAM

[Jarno Suni]

Update: As for Xubuntu 11.04 at least, please read comment #13

OS: 8.10

USB device is attached to /dev/ttyUSB0 when I plug it in USB port. But when I suspend to RAM and resume, it gets attached to /dev/ttyUSB1. Consequently, the daemon configured using /dev/ttyUSB0 does not work after resume. I would expect the device to be attached to the same ttyUSB before and after.

Details of the device (from output of lsusb -v):

Bus 003 Device 010: 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 A5001qxI
  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)

[Jarno Suni (jarnos)]

Workaround is to run "/etc/init.d/lirc stop" before suspend and "/etc/init.d/lirc start" after resume; both as superuser. These can even be automated; see http://en.opensuse.org/Pm-utils

[David Tombs (dgtombs)]

Thank you for taking the time to report this bug and helping to make Ubuntu better. This bug did not have a package associated with it, which is important for ensuring that it gets looked at by the proper developers. You can learn more about finding the right package at https://wiki.ubuntu.com/Bugs/FindRightPackage. I have classified this bug as a bug in lirc.

When reporting bugs in the future please use apport, either via the appropriate application's "Help -> Report a Problem" menu or using 'ubuntu-bug' and the name of the package affected. You can learn more about this functionality at https://wiki.ubuntu.com/ReportingBugs.

Can you reproduce this bug in 10.04? Thanks.

[Jarno Suni (jarnos)]

I can not reproduce this in 10.04.

[Jarno Suni (jarnos)]

Oh, I can reproduce it: I just have to have irxevent running.
Note: If I have irexec running, but no irxevent, the device is not changed in resume, but lirc does not work anyway.

[David Tombs (dgtombs)]

OK, thanks. Changing back to New so that the lirc guys will look at it.

[Jarno Suni (jarnos)]

As for comment #2, the following workaround worked in Xubuntu 9.04; replace "jarno" by your username; it has not been tested, when more than one user is logged in.

[Jarno Suni (jarnos)]

To be more specific, also irxevent and irexec worked after resume in 9.04, when applying comment #7.

[Jarno Suni (jarnos)]

And the workaround does not work in 10.04 so I don't know how to make 10.04 work as well as 9.04.

[Shock (mmiron)]

This happens to me in Lucid while using a Streamzap PC Remote.

[David Tombs (dgtombs)]

Confirming due to above comment.

[Jarod Wilson (jarod-wilsonet)]

99% certain this is not an lirc bug, it is a kernel bug. Devices disconnecting and reconnecting on suspend/resume is indicative of buggy support for the usb chipset on the system(s) in question. The isn't anything in lirc that assigns ttyUSB devices, that is purely the kernel.

[Jarno Suni (jarnos)]

Tested this in ubuntu 11.04. The device name is not changed, and lirc works after resume, if neither irexec nor irxevent is running. If either one is running, device is changed in resume. A workaround is to unplug and re-plug the USB device. Then /dev/ttyUSB0 exists again and lirc works. The remote control in question is "VLSystem MPlay Blast".

[Jarod Wilson (jarod-wilsonet)]

Still sounds like a kernel-level issue underneath. Can you provide dmesg output from after a fresh boot, suspend and resume?

[Jarno Suni (jarnos)]

Here's the data. Probably not relevant, but resume took more than a minute.

[Jarod Wilson (jarod-wilsonet)]

Choice excerpts from dmesg:

[ 0.000000] Atom PSE erratum detected, BIOS microcode update recommended

[ 0.000000] ACPI: BIOS bug: multiple APIC/MADT found, using 0
[ 0.000000] ACPI: If "acpi_apic_instance=2" works better, notify <email address hidden>

[ 0.180781] [Firmware Bug]: ACPI: BIOS _OSI(Linux) query ignored

I'd suggest seeing if there's a BIOS update available for your system, which may or may not improve suspend/resume functionality a bit. Especially if its taking more than a minute to resume.

However, that aside, looking at both the dib0700 driver and the ftdi_sio driver, I noticed they lack suspend or resume functions entirely. The ftdi_sio driver may have the default usb-serial suspend routine wired up to it somehow though. But anyway, I'm not sure if the usb core is possibly behaving as expected, disconnecting the devices, rather than suspending them, or if its the usb chipset not suspending properly.

The incremented ttyUSBx device makes some degree of sense though. If lircd has an active client (such as irxevent) at suspend time, then the IR device (/dev/ttyUSB0) will be open, in which case, it can't be fully removed. Thus, when the device is reconnected, it gets ttyUSB1, as there's still a lingering reference to ttyUSB0. No clients, 0 gets fully freed up, and can be allocated again. I'll have to see about getting some ftdi usb IR hardware one of these days to get a better understanding of what's going on. I do stand by the assertion that lirc isn't actually doing anything wrong here though. :)

[Jarno Suni (jarnos)]

As for BIOS, I have updated it long time ago, and I suppose it is still latest version.
$ lshal | grep firmware
  system.firmware.release_date = '09/08/2009' (string)
  system.firmware.vendor = 'Phoenix Technologies Ltd.' (string)
  system.firmware.version = '11CA.M015.20090908.RHU' (string)
  storage.firmware_version = 'HH100-60' (string)
(If I remember right, I used the DOS version of BIOS update software.)

[Jarno Suni (jarnos)]

And the computer is NC10. But that is not the only computer that this bug occurs in.

[Jarno Suni (jarnos)]

As for resume taking so long time, it seems it is an issue with the dvb device.

[Jarod Wilson (jarod-wilsonet)]

Okay, if its multiple machines, I put the blame squarely on the ftdi_sio and dib0700 drivers for apparently not implementing any suspend/resume support. I've actually dug out my usb-uirt hardware, which has some usb-serial ftdi driver as well, iirc., and will see if I can reproduce the issue and try to better understand it.

[Bob Mroczka (a-b-m)]

Although not a fix by no means I have used a workaround by modifying /etc/lirc/hardware.conf and changing the line from
REMOTE_LIRCD_ARGS="-d /dev/ttyUSB0"
to
REMOTE_LIRCD_ARGS="-d /dev/ttyUSB*"

If you have more than one ttyUSB device this will not work but I have not had this issue.

[Alec Leamas (leamas-alec)]

I don't know if changing the device after a kernel suspend/resume could be a kernel bug. Basically, I don't think the kernel guarantees much more than that device names should be unique(?)

The proper solution to handle situation is to install a udev rule which sets up a stable device name for the device. This should certainly work also after suspend resume.

Anyway, this is not a lirc bug and this issue should IMHO be closed (or possibly re-assigned to the kernel if there is some guarantee that device names should be stable during suspend/resume).

[Alec Leamas (leamas-alec)]

Re-assigning to kernel - this is teh way to clarify whether it's a bug or just documented behaviour.

[Alec Leamas (leamas-alec)]

Now, suspend-resume is about the kernel, the extra modules secion. But which iof them? Just don't know.