After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 630670 - x22x: Alcatel X220: long delay at init time
x22x: Alcatel X220: long delay at init time
Status: RESOLVED NOTGNOME
Product: NetworkManager
Classification: Platform
Component: ModemManager
git master
Other Linux
: Normal normal
: ---
Assigned To: Dan Williams
Depends on:
Blocks:
 
 
Reported: 2010-09-26 23:35 UTC by Tzafrir Cohen
Modified: 2010-09-29 06:10 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
log of modem-manager --debug (16.52 KB, text/plain)
2010-09-26 23:35 UTC, Tzafrir Cohen
Details
log of: NM_PPP_DEBUG=1 NetworkManager --no-daemon (11.02 KB, text/plain)
2010-09-26 23:36 UTC, Tzafrir Cohen
Details

Description Tzafrir Cohen 2010-09-26 23:35:20 UTC
Created attachment 171152 [details]
log of   modem-manager --debug

Modem: Alcatel X220
Version: git rev 618dc063101370205097f19ae47f730499b8431b
NetworkManager: 0.8.1-2+b1
Kernel: Linux hungmung 2.6.35-trunk-loongson-2f #1 Sun Sep 12 11:38:18 UTC 2010 mips64 GNU/Linux
OS: Debian Testing (mipsel port), with kernel package rev. 2.6.35-1~experimental.3
Hardware: Yeelong netbook (Loongson-2F)

The modem is supported, and generally works. But there is a delay of 2-3 minutes until it is detected.

Attached logs from NetworkManager and modem-manager of such a session (with automatic connection startup). The modem is plugged a while after both NM and MM are started.
Comment 1 Tzafrir Cohen 2010-09-26 23:36:37 UTC
Created attachment 171153 [details]
log of: NM_PPP_DEBUG=1 NetworkManager --no-daemon
Comment 2 Dan Williams 2010-09-27 21:31:08 UTC
I've seen this with some other devices as well (ZTE 2760 from Reliance India); it's actually a kernel problem in the 'option' driver where the device simply does not respond to certain packets, but the driver waits up to 30 seconds when closing the port to complete the request.  ModemManager will start sending bytes on the port to probe it, but the device doesn't respond to the URB.  That by is still "in-flight" when MM times out the probe and tries to close the port, but due to this bit in tty_port.c:

	if (test_bit(ASYNCB_INITIALIZED, &port->flags) &&
			port->closing_wait != ASYNC_CLOSING_WAIT_NONE)
		tty_wait_until_sent(tty, port->closing_wait);

the kernel waits 30 seconds trying to send that byte before giving up and returning from close().

And to make things worse, the option driver doesn't give us the ability to change port->closing_wait either because it doesn't implement the 'ioctl' hook.  So in the end, this is a kernel serial layer bug in the option driver really :(  I'll look into patches to help fix this upstream.
Comment 3 Tzafrir Cohen 2010-09-29 06:10:30 UTC
I'll just note that I've tried current ModemManager (8935812da4bb468992876586215b68b159fcfdd4) and your kernel patch, and the combination of both seems to work. Though I believe I needed to move away the longcheer plugin.