Comment 16 for bug 359356

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. :)