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

[Ulf Rehmann]

Binary package hint: linux-image-generic

In spite of the fact that the device is recognized and the corresponding module is loaded,
there is no serial line via /dev/ttyUSB0

$ lsusb | grep -i serial
Bus 001 Device yUSB0002: ID 067b:2303 Prolific Technology, Inc. PL2303 Serial Port
$ lsmod | grep -i serial
usbserial 33100 1 pl2303
$ ls -l /dev/ttyU*
crw-rw---- 1 root dialout 188, 0 2011-01-07 18:58 /dev/ttyUSB0

ProblemType: Bug
DistroRelease: Ubuntu 10.10
Package: linux-image-2.6.35-24-generic 2.6.35-24.42
Regression: Yes
Reproducible: Yes
ProcVersionSignature: Ubuntu 2.6.35-24.42-generic 2.6.35.8
Uname: Linux 2.6.35-24-generic i686
AlsaVersion: Advanced Linux Sound Architecture Driver Version 1.0.23.
AplayDevices:
 **** List of PLAYBACK Hardware Devices ****
 card 0: PCI [ESS Maestro3 PCI], device 0: Maestro3 [Maestro3]
   Subdevices: 2/2
   Subdevice #0: subdevice #0
   Subdevice #1: subdevice #1
Architecture: i386
ArecordDevices:
 **** List of CAPTURE Hardware Devices ****
 card 0: PCI [ESS Maestro3 PCI], device 0: Maestro3 [Maestro3]
   Subdevices: 1/1
   Subdevice #0: subdevice #0
AudioDevicesInUse: Error: command ['fuser', '-v', '/dev/snd/by-path', '/dev/snd/controlC0', '/dev/snd/pcmC0D0c', '/dev/snd/pcmC0D0p', '/dev/snd/seq', '/dev/snd/timer'] failed with exit code 1:
CRDA: Error: [Errno 2] No such file or directory
Card0.Amixer.info:
 Card hw:0 'PCI'/'ESS Maestro3 PCI at 0xec00, irq 5'
   Mixer name : 'SigmaTel STAC9721,23'
   Components : 'AC97a:83847609'
   Controls : 31
   Simple ctrls : 21
Date: Sat Jan 8 12:27:30 2011
HibernationDevice: RESUME=/dev/sda2
InstallationMedia: Ubuntu 10.04 LTS "Lucid Lynx" - Release i386 (20100427.1)
Lsusb:
 Bus 001 Device 002: ID 067b:2303 Prolific Technology, Inc. PL2303 Serial Port
 Bus 001 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
MachineType: Dell Computer Corporation Latitude C800
PccardctlStatus:
 Socket 0:
   no card
 Socket 1:
   5.0V 16-bit PC Card
   Subdevice 0 (function 0) bound to driver "orinoco_cs"
ProcCmdLine: BOOT_IMAGE=/boot/vmlinuz-2.6.35-24-generic root=UUID=4f04ca29-3bfa-4d76-bb04-80eecf26944b ro quiet splash
ProcEnviron:
 PATH=(custom, user)
 LANG=en_US.UTF-8
 SHELL=/bin/bash
RelatedPackageVersions: linux-firmware 1.38
RfKill:
 0: phy0: Wireless LAN
  Soft blocked: no
  Hard blocked: no
SourcePackage: linux
dmi.bios.date: 01/21/2004
dmi.bios.vendor: Dell Computer Corporation
dmi.bios.version: A23
dmi.board.name: Latitude C800
dmi.board.vendor: Dell Computer Corporation
dmi.chassis.type: 8
dmi.chassis.vendor: Dell Computer Corporation
dmi.modalias: dmi:bvnDellComputerCorporation:bvrA23:bd01/21/2004:svnDellComputerCorporation:pnLatitudeC800:pvr:rvnDellComputerCorporation:rnLatitudeC800:rvr:cvnDellComputerCorporation:ct8:cvr:
dmi.product.name: Latitude C800
dmi.sys.vendor: Dell Computer Corporation

[Ulf Rehmann (rehmann)]

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.

[Ulf Rehmann (rehmann)]

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.

[Radu Cristescu (radu.c)]

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

[Radu Cristescu (radu.c)]

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!

[Mathieu Trudel-Lapierre (cyphermox)]

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

[Mathieu Trudel-Lapierre (cyphermox)]

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

[Radu Cristescu (radu.c)]

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.

[Mathieu Trudel-Lapierre (cyphermox)]

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.

[Radu Cristescu (radu.c)]

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.

[Ulf Rehmann (rehmann)]

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

[Mathieu Trudel-Lapierre (cyphermox)]

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?

[Ulf Rehmann (rehmann)]

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?

[Mathieu Trudel-Lapierre (cyphermox)]

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.

[Mathieu Trudel-Lapierre (cyphermox)]

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

[Mathieu Trudel-Lapierre (cyphermox)]

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"

[Mathieu Trudel-Lapierre (cyphermox)]

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

[Launchpad Janitor (janitor)]

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