Some Novatel devices reply with the normal units to +CSQ and it
doesn't look quite like the +CSQ reply is in dBm either; so
use the custom Novatel command for RSSI.
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
The port is still connected until disconnect_done() runs, but by
this point we already know it's been disconnected so it's safe to
run the CGACT commands.
