/sbin/modemmanager is too aggressive managing devices that aren't known to be modems
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
modemmanager (Ubuntu) |
Confirmed
|
Undecided
|
Unassigned |
Bug Description
Binary package hint: modemmanager
When connecting an embedded processor via usb (beagleboard or overo), modemmanager immediately starts sending commands to the device with no prompting or otherwise. This is very disruptive to terminal sessions to those devices, especially when uploading firmware or typing commands that need to be correct to avoid bricking the device.]
"""
cwillu@
picocom v1.4
port is : ./serial/
flowcontrol : none
baudrate is : 115200
parity is : none
databits are : 8
escape is : C-a
noinit is : no
noreset is : no
nolock is : no
send_cmd is : ascii_xfr -s -v -l10
receive_cmd is : rz -vv
Terminal ready
AT+GCAP
Unknown command 'AT+GCAP' - try 'help'
OMAP3 beagleboard.org # OAT+GCAP
Unknown command 'AT+GCAP' - try 'help'
OMAP3 beagleboard.org #
"""
The AT+GCAP lines above weren't typed by me, but by another process (modemmanager) sending commands to the port. They showed up here because the beagleboard boot loader echoes characters back. The other process continues to send control characters continually which don't disrupt single keystrokes, but which garble lines being pasted or or otherwise transferred to the remote. This has already soft-bricked one of my beagleboards.
ProblemType: Bug
Architecture: i386
Date: Sun Nov 29 22:20:16 2009
DistroRelease: Ubuntu 9.10
NonfreeKernelMo
Package: modemmanager 0.2.git.
ProcEnviron:
SHELL=/bin/bash
LANG=en_CA.UTF-8
ProcVersionSign
SourcePackage: modemmanager
Uname: Linux 2.6.31-
I concur, modemmanager is far too aggressive. Please take a look at these bugs, too:
https:/ /bugs.launchpad .net/ubuntu/ +source/ modemmanager/ +bug/686418 /bugs.launchpad .net/ubuntu/ +source/ gobi-loader/ +bug/621743 /bugs.launchpad .net/ubuntu/ +source/ gobi-loader/ +bug/647471
https:/
https:/
gobi-loader is often blamed, but modemmanager is the culprit trying to access the QDL device while the firmware load is still in progress und thus corrupting the upload. Blacklisting all USB QDL devices of the Gobi modem solves the problem by stopping modemmanager from accessing the corresponding devices.