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? Dan _______________________________________________ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
