On Thu, 2015-01-29 at 10:24 -0500, Jeremy Moles wrote: > On 01/28/2015 01:23 PM, Dan Williams wrote: > > On Wed, 2015-01-28 at 11:43 -0500, Jeremy Moles wrote: > >> On 01/12/2015 12:50 PM, Dan Williams wrote: > >>> On Mon, 2015-01-12 at 12:44 -0500, Jeremy Moles wrote: > >>>> On 01/12/2015 12:42 PM, Dan Williams wrote: > >>>>> 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 > >>>> State: LowPowerMode > >>>> LPM force flags - W_DISABLE:0, User:0, Temp:0, Volt:0, BIOS:1, GOBIIM:0 > >>>> W_DISABLE: 0 > >>>> Poweroff mode: 0 > >>>> LPM Persistent: 0 > >>> This says that it's BIOS that is forcing the device to be in low power > >>> mode. That means that the kernel rfkill drivers don't know how to > >>> handle WWAN rfkill on this laptop, and until that gets fixed you won't > >>> be able to use the card from coldboot under Linux :( > >>> > >>> The best thing you can do for now is maybe file a bug on > >>> bugzilla.kernel.org. The process will likely be similar to > >>> https://bugzilla.kernel.org/show_bug.cgi?id=47751 (though for > >>> thinkpad/lenovo instead of Sony) where you'll be asked to grab some BIOS > >>> information so kernel developers can debug it. > >>> > >>> I hope that helps... > >>> > >>> Dan > >>> > >> I have filed the following bug: > >> > >> https://bugzilla.kernel.org/show_bug.cgi?id=92201 > > Jeremy, could you try the attached kernel driver patch? It attempts to > > do what the GobiNet drivers do by clearing the endpoint halts in both > > qmi_wwan and qcserial. Let's see if that makes any difference. > > I'm working on testing this patch, but something else funny is > occurring. I can no longer actually query the device using qmicli > anymore under any condition... every attempt times out or returns: > > [29 Jan 2015, 10:23:06] -Warning ** [/dev/cdc-wdm0] QMI framing error > detected > > I will try and resolve these and get you an answer. > > Also: the code you added in qmi_wwan never even gets evaluated AT ALL > until I switch the device into the mode (via the sysfs echo) that > exposes the serial ports; does that sound backwards to you, too?
Jeremy, So Aleksander has apparently figured it out, it's the FCCAuth command that appears to do the trick for Sierra devices. He's updated libqmi and ModemManager to do this now, so if you backport those changes to the libqmi/ModemManager you're shipping, can you tell us if it now begins to work automatically on reboot? Thanks! Dan _______________________________________________ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
