Age | Commit message (Collapse) | Author |
|
Some modems (Huawei E1552) appear to have problems with auto registration
in some circumstances that we don't yet fully understand, such that when
AT+COPS=0 is sent they never end up registering with the correct network.
As a minor workaround, if the modem is already registered with a provider
and the user hasn't specified manual registration, don't set auto
registration but let the modem figure it out itself.
See (bgo #591047) for more details.
|
|
|
|
|
|
Bug didn't have much of an effect, but should be fixed anyway.
|
|
Assume (for now) that devices that respond to AT+CPIN without an
error are GSM devices. This may not be 100% true as some devices
in Asia (where CDMA devices use RUIMs which are basically SIMs) support
+CPIN for unlocking the RUIM, but since CDMA devices more consistently
implement AT+GCAP and ATI than we should be safe for a while.
|
|
This should solve problems with users who's providers are EVDO
only and thus the device isn't in 1X mode, but who's modems
don't set anything meaningful for CAD or CSS when the 1X radio
isn't registered. Previously, MM would just spin thinking it
wasn't registered when trying to connect.
This was mostly found with AnyDATA, Huawei, and some ZTE devices
from Russia and India.
|
|
|
|
|
|
|
|
|
|
Which are Sprint-specific commands which appear to be implemented by
various phones for getting access technology and roaming status.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Again, only required for various dialing features we don't deal with
yet.
|
|
|
|
|
|
|
|
Helpful when chaining a number of commands together when you want
to schedule the callback info only after all of them complete.
|
|
|
|
We don't really care about anything that came before.
|
|
Makes sure we build on Alpha, plus the right thing to do.
|
|
|
|
Device is functional without it; it's only required for stuff
we don't do yet.
|
|
|
|
|
|
|
|
|
|
|
|
For now; until Sierra releases their CnS documentation.
|
|
No more external users of it.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Some modems turn E1 on and off random (Huawei EC168C) and sometimes
the echoed command confuses things. We have a parser just for that,
so let's use it. It should be safe to use with devices that repect
E0 too.
|
|
|
|
|
|
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
|