usbserial stopped working during a recent upgrade, no serial line via usb anymore

The problem does also occur for this kernel:

linux-image-2.6.37-999-generic_2.6.37-999.201101071225_i386.deb
linux-headers-2.6.37-999_2.6.37-999.201101071225_all.deb
linux-headers-2.6.37-999-generic_2.6.37-999.201101071225_i386.deb

It did occur so far on 3 different machines. It did also occur under a system installed on a USB stick and based on

    1. Ubuntu 10.10 Desktop Edition
    2. Ubuntu 10.10 Netbook Edition.

However, an installation based on Ubuntu 10.10 Server edition is operating correctly.

I did transfer the udev rules from a correctly working system to a not correctly working system
but this did not change the malfunction.

It turns out that the problem is an incompatibility with the packages

network-manager + network-manage-gnome

Whenever these are installed, usbserial becomes intransparent
(i.e., physical and logical devices are present, but there is no thoughput through the serial interface).

After removal of these packages and after system restart the serial interface works as it should.

Maybe this should be considered a bug of one of these packages.

The network-manager + network-manager-gnome hypothesis may not be true. I encountered this problem with Kubuntu 10.10, which doesn't have the network-manager-gnome package installed. LiveCD test is enough.

How I did the test:

    strace cat /dev/ttyUSB0

When it doesn't work, it gets stuck at:

    open("/dev/ttyUSB0", O_RDONLY|O_LARGEFILE)

When it works, it will go all the way to a "read" operation.

Unloading usbserial and the corresponding modules that depend on it, and then loading them back, fixes the issue until reboot.

Tested with Kubuntu 10.10 LiveCD and desktop install on HDD. Tested with Ubuntu 10.10 LiveCD. Tested with Ubuntu 11.04 alpha1 LiveCD. All of them gave the same experience as described above. I tested on 4 machines: two desktops, two laptops, very different hardware between them. I tested with three different USB serial adapters, each using a distinct kernel driver (pl2303, cp210x, ch341), all with the same result.

I didn't try getting rid of the network-manager package completely though. I'll give that a try, and if it fixes the issue, someone needs a beating, since I was about to start debugging the kernel :)

Purged network-manager and all packages depending on it, rebooted, and the serial devices seem fine now without the reloading of usbserial. I can't use it properly in Kubuntu anyway, so bye bye it goes. I was keeping it under the impression that it will pull kubuntu-desktop with it, but it didn't!

Ohh, I've seen this fixed in a recent commit in modemmanager trunk, assigning this bug to myself to upload at least to natty; then consider this for an SRU (it's simple udev rules).

FWIW, the commit I'm referring to is this one: http://cgit.freedesktop.org/ModemManager/ModemManager/commit/?id=12f1b351e83730c7d5fa882f0fbbaf4b19816a00

The devices I tested this with are (from lsusb):

ID 10c4:ea60 Cygnal Integrated Products, Inc. CP210x Composite Device
ID 067b:2303 Prolific Technology, Inc. PL2303 Serial Port
ID 1a86:7523 QinHeng Electronics HL-340 USB-Serial adapter

That commit doesn't include any of these. The first two are ZWave dongles, the third one is just a single port serial cable on USB (which can have any serial device on the other end, but for my tests I didn't attach any).

Given the increasing number of devices reporting as generic serial cables, blacklisting will probably not work out very well in the long term.

What do you mean, increasing number of devices reported as generic serial? My understanding is that there aren't so much, and in general they shouldn't be affected too badly (plus, it's reasonable to have such a device to use an old modem, too). Nice catch though. What I'll do now in this case is go ahead and push the update with the exact stuff in the commit, and we can run this by the upstream developers on their mailing list to see what the general feeling is.

In my specific case, the devices I use are ZWave, and they have this habit of sharing USB ID with genuine serial cables.

But that doesn't matter. Network-manager made one of my genuine serial cables unusable, which means that even if it had an old serial modem attached it would probably prevent me from using it.

I don't exactly have the time to dig deeper, but my intuition says that some weird ioctls may be doing this. For this to happen, some new modem probing code, probably specific to a single modem out there, is at fault. At least that's what I'd be looking for. Confuse the device enough and it will fail to return from "open" (probably frozen, needs to be reinitialized).

I need to run another test: get one USB device network-manager-ized, then remove network-manager and add a second usb serial device. If there's nothing to probe it, it should be fine. If it isn't, usbserial has a problem (too). I hope this isn't the case though.

I have double-checked my records:

My serial device stopped working for the first time (within years,
as recorded by minutely logs) after the reboot following an upgrade as
logged below in my /var/log/apt/history.

According to that log, in that upgrade, network-manager and
network-manager-gnome weren't involved.

But now, I can turn off/on the functionality of the serial device by
installing/removing network-manager (tested on various machines).

From /var/log/apt/history:

Start-Date: 2011-01-06 12:20:19
Install: linux-headers-2.6.32-27 (2.6.32-27.49), linux-image-2.6.32-27-generic (2.6.32-27.49), linux-headers-2.6.32-27-generic (2.6.32-27.49)
Upgrade: evolution-common (2.28.3-0ubuntu10, 2.28.3-0ubuntu10.2), linux-headers-generic (2.6.32.26.28, 2.6.32.27.29), libapparmor1 (2.5-0ubuntu3, 2.5.1-0ubuntu0.10.04.1), evolution (2.28.3-0ubuntu10, 2.28.3-0ubuntu10.2), linux-image-generic (2.6.32.26.28, 2.6.32.27.29), libapparmor-perl (2.5-0ubuntu3, 2.5.1-0ubuntu0.10.04.1), libevview2 (2.30.3-0ubuntu1.1, 2.30.3-0ubuntu1.2), linux-libc-dev (2.6.32-26.48, 2.6.32-27.49), libfuse2 (2.8.1-1.1ubuntu2, 2.8.1-1.1ubuntu2.1), udev (151-12.2, 151-12.3), libgudev-1.0-0 (151-12.2, 151-12.3), evince (2.30.3-0ubuntu1.1, 2.30.3-0ubuntu1.2), libevdocument2 (2.30.3-0ubuntu1.1, 2.30.3-0ubuntu1.2), evolution-plugins (2.28.3-0ubuntu10, 2.28.3-0ubuntu10.2), libudev0 (151-12.2, 151-12.3), apparmor (2.5-0ubuntu3, 2.5.1-0ubuntu0.10.04.1), gnome-system-tools (2.30.0-0ubuntu2, 2.30.0-0ubuntu3), rsyslog (4.2.0-2ubuntu8, 4.2.0-2ubuntu8.1), apparmor-utils (2.5-0ubuntu3, 2.5.1-0ubuntu0.10.04.1), fuse-utils (2.8.1-1.1ubuntu2, 2.8.1-1.1ubuntu2.1), linux-generic (2.6.32.26.28, 2.6.32.27.29)
End-Date: 2011-01-06 12:25:30

Start-Date: 2011-01-06 12:26:16
Remove: linux-headers-2.6.32-26 (2.6.32-26.48), linux-headers-2.6.32-26-generic (2.6.32-26.48)
End-Date: 2011-01-06 12:26:32

If you add the necessary lines to blacklist the USB IDs in 77-mm-usb-device-blacklist.rules, can you then have the RS232-to-USB devices work properly?

Mathieu Trudel-Lapierre <email address hidden> writes:

 | If you add the necessary lines to blacklist the USB IDs in 77-mm-usb-
 | device-blacklist.rules, can you then have the RS232-to-USB devices work
 | properly?

Yes, thanks, that works in my case after adding the following

to /lib/udev/rules.d/77-mm-usb-device-blacklist.rules :

# Prolific
ATTRS{idVendor}=="067b", ATTRS{idProduct}=="2303", ENV{ID_MM_DEVICE_IGNORE}="1"

How should I protect this against update replacements of that file?

You'd need to change it again on updates, AFAIK (unless it's a conffile? not sure). However, this should be brought up upstream so that these lines can be added to blacklist to make sure it doesn't cause further problems.

Just filed the necessary upstream bug for the three devices listed in comment #8.

Noting for myself, this will be uploaded to Oneiric incessantly:

# Prolific Technology, Inc. PL2303 Serial Port
ATTRS{idVendor}=="067b", ATTRS{idProduct}=="2303", ENV{ID_MM_DEVICE_IGNORE}="1"

# Cygnal Integrated Products, Inc. CP210x
ATTRS{idVendor}=="10c4", ATTRS{idProduct}=="ea60", ENV{ID_MM_DEVICE_IGNORE}="1"

# QinHeng Electronics HL-340
ATTRS{idVendor}=="067b", ATTRS{idProduct}=="2303", ENV{ID_MM_DEVICE_IGNORE}="1"

Heh, I wrote the last one wrong in the last comment, but put in the right USB IDs when I did the patch ;)

This bug was fixed in the package modemmanager - 0.5-0ubuntu1

---------------
modemmanager (0.5-0ubuntu1) oneiric; urgency=low

  * New upstream release 0.5.
    - gsm: send init command twice to make the N900 happy (LP: #765516)
    - fix sierra modems' sleep mode command (LP: #459052, #738005)
  * debian/patches/lp700316_usb_blacklist.patch: add extra devices to blacklist
    of USB devices known to usually be serial dongles or other things MM should
    not touch. (LP: #700316)
  * debian/control, debian/rules: add a -dbg package for modemmanager, and
    override dh_strip accordingly. (LP: #415394)
  * debian/rules: fix .la/.a file removal to not fail if there is nothing to
    remove.
  * debian/modemmanager.install: install files to the modemmanager package
    explicitly now that it's not the only binary package.
 -- Mathieu Trudel-Lapierre <email address hidden> Fri, 05 Aug 2011 12:46:32 -0400