Re: AW: AW: Problems with Sierra MC 8790 with older firmware revision



On Wed, 2013-04-03 at 19:37 +0200, Gerald Richter - ECOS wrote:
Hi,

we have a similar case here (Also firmware version 2_*). We are investigating at the moment. As soon as I 
have more information, we will try to create an updated patch.

If there's any chance you can run the ENTERCND thing, then AT!CUSTOM to
see if your MUXMODE has been modified, that would be great.  I'm really
poking around in the dark here, but it would be very, very nice to have
a way of detecting this automatically rather than doing something like;

strstr (info, "8790") && strstr (fwver, "2_")

Dan

Gerald


-----Ursprüngliche Nachricht-----
Von: Aleksander Morgado [mailto:aleksander lanedo com]
Gesendet: Mittwoch, 3. April 2013 19:00
An: Dan Williams
Cc: Gerald Richter; Marius Kotsbak; Harald Jung; networkmanager-
list gnome org
Betreff: Re: AW: Problems with Sierra MC 8790 with older firmware revision

On 03/04/2013 03:33 PM, Dan Williams wrote:
On Fri, 2013-03-01 at 15:08 +0100, Gerald Richter - ECOS wrote:
The following patch solves the problem for us. It works with all
revisions we have available for testing

Pushed to git master and 0.6, thanks!

Dan

Gerald

--- mm-plugin-sierra.c~  2012-08-29 17:02:18.000000000 +0200
+++ mm-plugin-sierra.c   2013-03-01 13:22:09.000000000 +0100
@@ -78,6 +78,9 @@
         if (strstr (response, "C885"))
             g_object_set_data (G_OBJECT (task),
TAG_SIERRA_APP_PPP_OK, GUINT_TO_POINTER (TRUE));

+        if (strstr (response, "MC8790"))
+            g_object_set_data (G_OBJECT (task),
+ TAG_SIERRA_APP_PPP_OK, GUINT_TO_POINTER (TRUE));
+
         /* For debugging: let users figure out if their device supports it or not
*/
         if (getenv ("MM_SIERRA_APP1_PPP_OK")) {
             mm_dbg ("Sierra: APP1 PPP OK '%s'", response);



Ah, the fun... :)

So I've got a MC8790 here which does *not* like the APP1 port for PPP.
It has the following revision:
'K2_0_7_35AP C:/WS/FW/K2_0_7_35AP/MSM6290/SRC 2010/03/04 17:37:08'

This is what we get from the probing:

log_port(): (/sys/devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.7)
tty/ttyUSB3 at (primary)
log_port(): (/sys/devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.7)
tty/ttyUSB4 data (primary)
log_port(): (/sys/devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.7)
tty/ttyUSB1 qcdm

And it just stalls when we try to launch the ATD call in ttyUSB4:

[1365007565.579948] [mm-broadband-bearer.c:200]
common_get_at_data_port(): Connection through a plain serial AT port
(ttyUSB4)
[1365007565.579997] [mm-serial-port.c:958] mm_serial_port_open():
(ttyUSB4) device open count is 2 (open)
[1365007565.580036] [mm-serial-port.c:1003] mm_serial_port_close():
(ttyUSB3) device open count is 1 (close) [1365007565.580080] [mm-at-serial-
port.c:408] debug_log(): (ttyUSB4):
--> 'ATD*99***2#<CR>'
...
And that's it, won't reply.

Running the ATD call in the primary ttyUSB3 port (without the patch
above) kind of works; in that case ttyUSB4 is marked as secondary, but again
ttyUSB4 doesn't know how to properly work not even as secondary and
either reports error or times out most messages...

Some additional info for Dan, surely not very useful :)

  AT!NVPORTSET?
  ERROR
  AT!MXPORTMAP?
  ERROR
  AT!NVMUXMODE?
  ERROR
  AT!NVMUXMODE=?
  ERROR
  AT!MAPUART=?
  ERROR
  AT!MAPUART?
  ERROR
  AT!NVPORTMAP?
  ERROR

--
Aleksander





[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]