Re: Gobi 3000 (1199:901F)
On 02/10/2015 06:31 AM, Dan Williams wrote: 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
Re: Gobi 3000 (1199:901F)
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
Re: Gobi 3000 (1199:901F)
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
Re: Gobi 3000 (1199:901F)
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
Re: Gobi 3000 (1199:901F)
Dan Williams d...@redhat.com writes: On Thu, 2015-01-29 at 10:24 -0500, Jeremy Moles wrote: 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? Note that if this device is like the MC77xx, then it will switch control protocol based on protocol snooping and *not* the selected USB descriptors. So if you probe it as MBIM then it becomes MBIM, regardless of whether it is driven by cdc_mbim or qmi_wwan. It does not really support switching modes without being completely reset. You should let udev select a mode as soon as it is discovered and stick with that. BJørn ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Gobi 3000 (1199:901F)
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
Re: Gobi 3000 (1199:901F)
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
Re: Gobi 3000 (1199:901F)
Dan Williams d...@redhat.com writes:
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 :(
You wouldn't happen to know exactly what rfkill mechanism the modem
firmware means by 'BIOS'? And what about 'GOBIIM'?
As your example shows, 'W_DISABLE' was the only external LPM input of
the older 77xx modules ('User', 'Temp' and 'Volt' are all modem firmware
internal). And 'W_DISABLE' is simply pin 20 on the mini-PCIe connector,
usually controlled by the laptop rfkill circuitry. You can override
that with a piece of tape if necessarry.
I assume the new signals must be software interfaces, maybe some magic
shared config register or some sort of USB control message? But that
should also be documented in a spec somewhere. It is part of the
mini-PCIe host/device interface even if it is software based.
Bjørn
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Gobi 3000 (1199:901F)
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: 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) Dan ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Gobi 3000 (1199:901F)
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. Dan ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Gobi 3000 (1199:901F)
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,
Re: Gobi 3000 (1199:901F)
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
Re: Gobi 3000 (1199:901F)
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
Re: Gobi 3000 (1199:901F)
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:
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
Re: Gobi 3000 (1199:901F)
On 01/09/2015 12:16 PM, Adam Tauno Williams wrote: On Fri, 2015-01-09 at 12:01 -0500, 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. It works if you boot into Windows first because the driver in windows 'uploads' the firmware into the device and 'boots' it. Then it is operational until the device is power cycled either by the host being power cycled *or* the host powering off the device [hibernation, etc...] 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. If this driver uploads the binary wad it is likely this will work. At least this reflects my previous experience getting a Gobi device to work; albeit of a different vintage. The firmware these days looks to be called: carrier_pri.nvu spkg_sblz.cwe ...though I'm used to the .mbn files, so I'm not entirely sure what to do. ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
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 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 ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Gobi 3000 (1199:901F)
On Fri, 2015-01-09 at 12:01 -0500, 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. It works if you boot into Windows first because the driver in windows 'uploads' the firmware into the device and 'boots' it. Then it is operational until the device is power cycled either by the host being power cycled *or* the host powering off the device [hibernation, etc...] 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. If this driver uploads the binary wad it is likely this will work. At least this reflects my previous experience getting a Gobi device to work; albeit of a different vintage. -- Adam Tauno Williams mailto:awill...@whitemice.org GPG D95ED383 Systems Administrator, Python Developer, LPI / NCLA ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Gobi 3000 (1199:901F)
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. ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
