If a port returns EAGAIN on write attempts, previously the code would
spin and attempt to resend the failed byte after send_delay
microseconds. This resulted in up to 3 second hard blocks in
the serial code when sending to ports that don't respond. While
in this blocking loop no other events or dbus commands could be
processed.
Instead, send each byte and reschedule sending the next byte in
send_delay microseconds, so that we can process other events in between
attempts to write to stupid ports.
This doesn't hugely decrease the amount of time that probing
requires, since we still need to probe all ports of the device
before exporting the modem to D-Bus, but it does let MM find
responsive ports much more quickly, and ensures that MM doesn't
block any D-Bus requests.
This is the real fix for 81d0fd148f.
Some devices don't interact well with the option driver or the usb-serial
layer; they don't respond to the USB data requests and thus data never
gets written to that port. When close(2) is called, that data is still
pending and so the tty layer waits 30 seconds before returning from
the close. This is the 'closing_wait' value, which unfortunately is
not able to be modified by ModemManager because most serial drivers
for 3G devices don't implement the .ioctl handler or its TCIOSSERIAL
option to change closing_wait.
This goes along with a kernel patch to various drivers to enable
the TIOCSSERIAL ioctl to modify closing_wait which will be posted
soon.
Some devices don't interact well with the option drivr or the usb-serial
layer; they don't respond to the USB data requests and thus data never
gets written to that port. When close(2) is called, that data is still
pending and so the tty layer waits 30 seconds before returning from
the close. This is the 'closing_wait' value, which unfortunately is
not able to be modified by ModemManager because most serial drivers
for 3G devices don't implement the .ioctl handler or its TCIOSSERIAL
option to change closing_wait.
Print out open/close timestamps to help debug this issue and get a
list of modems that have this problem.
The flash function could be called when the port was closed, and since
the flash function would only be canceled when the port was open,
it could trigger after the port object was destroyed.
This specifically fixes a regression with Novatel GSM secondary
AT port enablement, where the inital pin check closed the port
before the Novatel plugin could send the command to flip secondary
ports to AT mode.
But it's useful elsewhere too, and simplifies a bunch of the PIN
checking code which had to use various ugly methods to track whether
to close the port or not after checking the PIN.
Some ports we know we shouldn't use when we get certain responses
from them. Reading from these ports triggers kernel bugs (at least
on 2.6.31 and 2.6.32) relating to flow control in some drivers
(*cough* hso *cough*), so lets try not to aggravate the kernel too
much. This happens on Icera-based Option devices like the GI0322
(AT&T Quicksilver) for example.
(note: AFAICT this doesn't have any relation to the recent XON/XOFF
patch, since I get this problem without the XON/XOFF patch on both
2.6.31 and 2.6.32 as well)
---
BUG: sleeping function called from invalid context at kernel/mutex.c:94
in_atomic(): 1, irqs_disabled(): 1, pid: 9295, name: modem-manager
Pid: 9295, comm: modem-manager Not tainted 2.6.32.9-67.fc12.x86_64 #1
Call Trace:
<IRQ> [<ffffffff81045d41>] __might_sleep+0xed/0xef
[<ffffffff81454dd0>] mutex_lock+0x24/0x50
[<ffffffff8104811e>] ? enqueue_task_fair+0x2a/0x6d
[<ffffffff812af79f>] tty_throttle+0x1b/0x49
[<ffffffff812af0d9>] n_tty_receive_buf+0xdbb/0xe12
[<ffffffff810459fd>] ? task_rq_unlock+0x11/0x13
[<ffffffff81050c5c>] ? try_to_wake_up+0x2f3/0x305
[<ffffffff8110de0c>] ? __kmalloc+0x37/0x15e
[<ffffffff8110de42>] ? __kmalloc+0x6d/0x15e
[<ffffffff812b12c9>] flush_to_ldisc+0xf8/0x18d
[<ffffffff812b13ae>] tty_flip_buffer_push+0x50/0x61
[<ffffffffa040ccd5>] put_rxbuf_data+0xea/0x124 [hso]
[<ffffffffa040cd97>] put_rxbuf_data_and_resubmit_bulk_urb+0x21/0x6b [hso]
[<ffffffffa040d0b1>] hso_std_serial_read_bulk_callback+0x14d/0x15f [hso]
[<ffffffff8132edf7>] ? dma_unmap_single_attrs.clone.0+0x38/0x3a
[<ffffffff8132ef74>] usb_hcd_giveback_urb+0x91/0xc5
[<ffffffff813417c8>] ehci_urb_done+0x7b/0x90
[<ffffffff81050c5c>] ? try_to_wake_up+0x2f3/0x305
[<ffffffff81341b45>] qh_completions+0x368/0x4b9
[<ffffffff8103e7a0>] ? __wake_up_common+0x4e/0x84
[<ffffffff81343f70>] ehci_work+0x95/0x732
[<ffffffff81045b53>] ? __wake_up+0x44/0x4d
[<ffffffff81070490>] ? insert_work+0x8e/0x9b
[<ffffffff81345f01>] ehci_irq+0x2be/0x420
[<ffffffff8107071a>] ? __queue_work+0x3a/0x41
[<ffffffff81049e43>] ? resched_cpu+0x6e/0x77
[<ffffffff8107075d>] ? delayed_work_timer_fn+0x3c/0x3e
[<ffffffff810b0e44>] ? __rcu_process_callbacks+0x7d/0x28a
[<ffffffff8132e846>] usb_hcd_irq+0x3f/0x7b
[<ffffffff810acd61>] handle_IRQ_event+0x60/0x121
[<ffffffff810aeb8e>] handle_fasteoi_irq+0x8b/0xc7
[<ffffffff81014625>] handle_irq+0x8b/0x96
[<ffffffff81459c14>] do_IRQ+0x5c/0xbc
[<ffffffff81012693>] ret_from_intr+0x0/0x11
This seems to help with Huawei and ZTE devices which often
appeared to stop responding on either primary or secondary ports
at various times. We had this problem a long time ago, but it was
fixed then by always picking the right serial port via the USB
interface number (Huawei) or udev rules files (ZTE). Now that we're
using the second serial port more extensively the problem came
up again, so lets try to fix it for real.
For QCDM devices we want most of what MMSerialPort does, but not
the AT command handling stuff since the commands and responses
aren't AT commands nor are they even strings. So convert everything
that MMSerialPort does into a GByteArray, and let MMAtSerialPort
handle the conversion to strings when necessary.
MM would appear to hang sometimes when writing to serial devices but
in reality was just retrying the write too many times. Make the
retry limit time-based so MM doesn't hang but times the attempt out
instead.
If there's already a command in-progress don't try to send
another until the previous one has timed out. Also use
g_timeout_add_seconds() since precision doesn't really matter for
command timeouts.
Nozomi devices aren't quite ready when the ports show up, so
we have to keep trying to open the port for a few seconds and
eventually it'll succeed. Should really be fixed in the driver
(ie, don't create the ttys until they can actually be used) but
whatever.
It's only relevant when the port is open anyway, and marking the port
disconnected in nm_serial_port_close(), which used to be called from
the finalize() function, would trigger the notifier when stuff was
already cleaned up. So move the nm_serial_port_close() call to
dispose() and remove the connected notifier before we clean the
port up.
Previously, a few operations (like disable) could trigger a modem
flash in parallel with another flash. That's wrong, don't allow
that. At the same time, add in finer-grained error checking on
serial port speed operations, and fix a GSM generic bug that would
send the POWER_UP string on disable.
So many modems just don't implement carrier detect that it makes
the previous 'connected' logic useless, so base it off connect/disconnect
and fix up a few places that didn't check connect status before
trying to send commands. Also ensure the serial port is unlocked
for PPP to use when connected.
Allow plugins to perform asynchronous port detection, and to defer port detection
until later. This moves the prober bits into MMPluginBase so that all plugins
can take adavantage of it only when needed; the probing is not done at udev time.
Furthermore, plugins like Novatel can flip the secondary ports over the AT mode
through deferred detection, by deferring the secondary ports until the main port
has been detected and AT$NWDMAT has been sent.
This commit also finishes the port of the rest of the plugins (except mbm) over
to the new port detection methods and plugin API.
Otherwise, if something else is mistakenly holding the serial port open at
the same time as this MMSerialPort, you get a stream of reads of size 0 and
effectively hang modem-manager.
Get rid of dependency on HAL, using libgudev instead. Fix up the plugin API
to no longer use either HAL or udev defines, but let plugins use whatever
mechanism they want for getting more information out of the device given the
subsystem and device node name.
Modems are now defined as "master" devices which "own" a one or more ports.
A port could be a serial tty device or a network device or whatever. The
plugin figures out whether it supports a given port or not and then assigns
it to a new or existing modem. Modems now have a 'valid' property that
should be set to TRUE when the modem has enough ports to operate correctly.
For devices (ex. 'hso') that use a network device for data transfer, the
modem would need to grab at least one TTY and the network device associated
with that physical device to be 'valid'.
Also move the generic modem support code to a plugin like other modem plugins,
and change the I-support-this-device mechanism to return a number indicating
the level of support. For example, the generic plugin would return a quite
low number if the device indicates via probing that it can do GSM or CDMA, but
a more specific plugin can indicate better support for the device, and thus
the more specific plugin would win control.
Dan Williams
Michael Biebl