Re: Gobi 3000 (1199:901F)

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

I should also mention I JUST found this thread:

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.


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