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?
That sounds odd; is your device driven by MBIM or QMI here? At least on most Sierra devices with either DirectIP or QMI support, they will also expose a couple serial ports too. Which mode are you in to start with, and which mode are you switching too, and how are you doing that via sysfs? Dan _______________________________________________ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
