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

Bug #700316 reported by Ulf Rehmann on 2011-01-08
This bug affects 3 people
Affects Status Importance Assigned to Milestone
Fix Released
Fix Released
linux (Ubuntu)
modemmanager (Ubuntu)
Mathieu Trudel-Lapierre

Bug Description

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
Uname: Linux 2.6.35-24-generic i686
AlsaVersion: Advanced Linux Sound Architecture Driver Version 1.0.23.
 **** 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
 **** 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
 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)
 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
 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
 PATH=(custom, user)
RelatedPackageVersions: linux-firmware 1.38
 0: phy0: Wireless LAN
  Soft blocked: no
  Hard blocked: no
SourcePackage: linux 01/21/2004
dmi.bios.vendor: Dell Computer Corporation
dmi.bios.version: A23 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: Latitude C800
dmi.sys.vendor: Dell Computer Corporation

Ulf Rehmann (rehmann) wrote :
affects: linux-meta (Ubuntu) → linux (Ubuntu)
Ulf Rehmann (rehmann) wrote :

The problem does also occur for this kernel:


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

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

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

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

Changed in linux (Ubuntu):
status: New → Invalid
Changed in modemmanager (Ubuntu):
status: New → Triaged
importance: Undecided → Medium
assignee: nobody → Mathieu Trudel-Lapierre (mathieu-tl)
affects: network-manager → modemmanager
Changed in modemmanager:
status: New → Fix Released
Radu Cristescu (radu.c) wrote :

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.

Radu Cristescu (radu.c) wrote :

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 (,, libapparmor1 (2.5-0ubuntu3, 2.5.1-0ubuntu0.10.04.1), evolution (2.28.3-0ubuntu10, 2.28.3-0ubuntu10.2), linux-image-generic (,, 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 (,
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?

Changed in modemmanager (Ubuntu):
assignee: Mathieu Trudel-Lapierre (mathieu-tl) → nobody
status: Triaged → Incomplete
Ulf Rehmann (rehmann) wrote :

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.

Changed in modemmanager (Ubuntu):
status: Incomplete → Triaged

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

Changed in network-manager:
importance: Unknown → Medium
status: Unknown → New

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

Changed in modemmanager (Ubuntu):
assignee: nobody → Mathieu Trudel-Lapierre (mathieu-tl)
Launchpad Janitor (janitor) wrote :

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
  * 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

Changed in modemmanager (Ubuntu):
status: Triaged → Fix Released
Changed in network-manager:
status: New → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
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.