GNOME.org
 

Re: Gobi 3000 (1199:901F)

On Mon, 2015-01-12 at 12:39 -0500, Jeremy Moles wrote:

On 01/12/2015 12:34 PM, Dan Williams wrote:

On Mon, 2015-01-12 at 11:04 -0500, Jeremy Moles wrote:

On 01/12/2015 10:46 AM, Dan Williams wrote:

On Mon, 2015-01-12 at 10:12 -0500, Jeremy Moles wrote:

On 01/09/2015 02:24 PM, Dan Williams wrote:

On Fri, 2015-01-09 at 12:14 -0500, Jeremy Moles wrote:

On 01/09/2015 12:01 PM, Jeremy Moles wrote:

Hey everyone! I'm not entirely sure where else to ask this, and I'm
somewhat desperate at this point having tried everything I'm capable of.

We have a machine here with the card listed in the subject. It shows
up in lsusb as:

1199:901f Sierra Wireless, Inc.

It will work in Linux so far if--and ONLY IF--you boot into Windows
first and then soft reboot into Linux. it appears that Windows does
something to the modem that Linux (currently) does not, and I was
wondering if anyone here had any advice on what I might try.

What I've done so far:

1) There is a knob in the sysfs hierarchy for this device that lets me
change the "config" (or something like that, I'm actually working on
this machine remotely and the customer isn't available right now!)
from 1 to 0, or 0 to 1. This ends up being necessary in fact, as after
doing so the tty's appear and the device is ready to be perturbed. It
responds to ATI commands and whatnot, but again, won't work properly
unless booted in Windows first. I should mention I found this knob
entirely by accident while hacking on qcserial and trying to accept
different "port" numbers as they enumerated themselves...

2) I downloaded the CodeAurora GobiSerial driver (which, according to
the changelog has a fix for "powering on" a device) and modified it to
work with 3.17 and 3.18 kernels (essentially, this involved
re-exporting usb-serial.c symbols like usb_serial_probe the code
relied on). However, I haven't had a chance to try this yet, and I'm
not entirely convinced (after looking through the code) it really does
anything qcserial doesn't.

Anyways, if anyone has any advice, please let us know!
_______________________________________________
networkmanager-list mailing list
networkmanager-list gnome org
https://mail.gnome.org/mailman/listinfo/networkmanager-list


I should also mention I JUST found this thread:

http://lists.freedesktop.org/archives/modemmanager-devel/2014-June/001301.html

Which explains exactly what I was seeing when talking about my #1
attempt (the config option in sysfs; again, it's miraculously I found
that at all).

I can't piece together everything the thread is talking about, but it
may job someone's memory. I can also try e-mailing the author of that
thread directly.

When it's cold-booted under Linux, can you grab 'lsusb -v -d 1199:901F'?
Also grab 'dmesg' output to see what driver messages there are.  Next,
if you have mbimcli installed, run 'sudo mmcli --firmware-list -m 0' and
lets see what we have.

Next warm-boot from Windows to Linux and run 'sudo mmcli --firmware-list
-m 0' in case the previous one didn't work.

Dan


Thank you for your reponse, Dan. I've attached the information you asked
for to this e-mail, formatted in a way it can be easily diff'd/vimdiff'd
at your leisure.

You'll notice how the 'power-state' differs depending on the boot type.
Also, the --firmware-list command failed to run, saying:

       error: modem has no firmware capabilities

Yeah, I see now that the  modem is using QMI instead of MBIM.  So
instead, try these twice, once under Linux and once after rebooting from
Windows:

For the time being, I can only provide the information with the machine
being directly booted into Linux. When I have additional access later
today, I will provide the results of these commands after having booted
into Windows first. For now, however, read on...

# qmicli -d /dev/cdc-wdm0 --dms-list-stored-images
error: couldn't list stored images: QMI protocol error (71):
'InvalidQmiCommand'

# qmicli -d /dev/cdc-wdm0 --dms-get-operating-mode
[/dev/cdc-wdm0] Operating mode retrieved:
          Mode: 'low-power'
          HW restricted: 'no'

# qmicli -d /dev/cdc-wdm0 --dms-lget-revision
[/dev/cdc-wdm0] Device revision retrieved:
          Revision: 'SWI9X15C_05.05.16.03 r22385 carmd-fwbuild1
2014/06/04 15:01:26'


qmicli -d /dev/cdc-wdm0 --dms-list-stored-images
qmicli -d /dev/cdc-wdm0 --dms-get-operating-mode
qmicli -d /dev/cdc-wdm0 --dms-get-revision

THe other possibility is that the machine's rfkill handling isn't known
to Linux, but since Windows knows, when you warm-boot to Linux the WWAN
rfkill is disabled.  What model laptop is this?  (if it's a laptop)

This is a Lenovo W540 with the Gobi 5000 Lenovo-certified card installed.

Under Linux, can you use 'sudo minicom -D /dev/ttyUSBx' where x is the
number of each of the USB serial ports, and run "at!pcinfo" on each one
in turn?


Only ttyUSB2 responds to input, and "at!pcinfo" simply returned "ERROR".

However, "ati" returned:

Manufacturer: Sierra Wireless, Incorporated
Model: EM7355
Revision: SWI9X15C_05.05.16.03 r22385 carmd-fwbuild1 2014/06/04 15:01:26
MEID: A0000050A9C727
ESN: 12802084172, 801FCD4C
IMEI: 356450050130001
IMEI SV: 13
FSN: FD334502680111
+GCAP: +CIS707-A, CIS-856, CIS-856-A, +CGSM, +CLTE2, +MS, +ES, +DS, +FCLASS


My fault, "at!pcinfo?" is the actual command, and it'll look something
like this (from my 7750):

at!pcinfo?
State: 1 (ONLINE)
LPM force flags - W_DISABLE:0, User:0, Temp:0, Volt:0
W_DISABLE: 0
Poweroff mode: 1
LPM Persistent: 0

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