I have a Dell Latitude E7240 with built-in "Dell 5808 Gobi(TM) 4G LTE Mobile Broadband" / Sierra Wireless MC73554G module. This was provisioned from Emperor Linux and we have been unable to get the modem to work. We are running rc7 of 3.18.0. This card works perfectly if I boot into Windows from a USB drive (Windows was banished from the internal SSD on purchase), connect via Dell's "SkyLight" program, then warm-boot back to Fedora 20. In that case, the initial power mode read from dms-get-operating-mode is "online" rather than "low-power". Some information about the card: ATI Manufacturer: Sierra Wireless, Incorporated Model: MC7355 Revision: SWI9X15C_05.05.39.00 r22582 carmd-fwbuild1 2014/06/14 13:21:08 MEID: 35619505057226 ESN: 12802831533, 802B34AD IMEI: 356195050572260 IMEI SV: 14 FSN: ER422300060411 +GCAP: +CGSM Checking the power mode indicates that it is locked into LPM by "BIOS". at!pcinfo? 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 Setting PCFUN fails in this locked mode (perhaps obviously): AT!PCFUN=1 ERROR I've been told on the libqmi-devel list by Dan Williams at RedHat[1] that this is not directly related to any BIOS settings, but rather that there is likely something that needs to be poked into BIOS or NVRAM by Linux, explaining why the card works fine in Windows and after a warm boot from Windows, but not with a cold boot under any Linux kernel that I've tried. This is the closest I've come to a real answer (thank you Dan!) but still a bit far off since I am unable to develop a patch for this myself. I will provide whatever information is needed to assist in debugging the issue or testing patches. This seems to be an issue that impacts at least a few other users as well. [2] [1] http://lists.freedesktop.org/archives/libqmi-devel/2015-January/001078.html [2] http://en.community.dell.com/support-forums/laptop/f/3518/t/19538429
Probing dell-laptop into the system and unblocking wwan does not seem to help: (iraway@procyon) [~] $ sudo modprobe dell-laptop force_rfkill=1 (iraway@procyon) [~] $ rfkill list 0: hci0: Bluetooth Soft blocked: no Hard blocked: no 1: phy0: Wireless LAN Soft blocked: no Hard blocked: no 2: dell-wifi: Wireless LAN Soft blocked: no Hard blocked: no 3: dell-bluetooth: Bluetooth Soft blocked: no Hard blocked: no (iraway@procyon) [~] $ rfkill unblock phy0 Bogus unblock argument 'phy0'. (iraway@procyon) [~] $ rfkill unblock wwan (iraway@procyon) [~] $ rfkill unblock 1 (iraway@procyon) [~] $ sudo minicom -D /dev/ttyUSB2 ... snip ... at!pcinfo? 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 OK at!fcfun=1 ERROR
Created attachment 164821 [details] acpidump > acpi.txt
Created attachment 164831 [details] dmidecode > dmi.txt
this does not seems like an ACPI bug. re-assign to the network experts.
(In reply to Zhang Rui from comment #4) > this does not seems like an ACPI bug. > re-assign to the network experts. We believe it is actually an ACPI or other BIOS communication bug, not a network driver bug. The WWAN card is being told through some OOB mechanism to stay in low-power Airplane mode. Why does it not seem like an ACPI bug?
To be clear, when this is worked-around with a Windows boot to initialize the card in some unknown way, I can connect and networking works perfectly.
(In reply to isaac from comment #6) > To be clear, when this is worked-around with a Windows boot to initialize > the card in some unknown way, I can connect and networking works perfectly. Yeah, but it's not clear (at least to me) whether Windows is touching the WWAN card itself, or touching BIOS which then tells the card to enable itself. There's a very small possibility that Windows using some unspecified protocol to talk to the WWAN card to set low-power mode, but that would trigger User:1 or GOBIIM:1, not BIOS:1. The "locked in airplane mode" thing is almost always an interaction with BIOS and whatever BIOS does to set airplane mode. Usually that consists of BIOS bringing hardware pins low on the PCI-E or M.2 minicard slot, or some other hardware-based mechanism like that. The question is how Windows does this, because dell-laptop apparently doesn't know how for your machine...
(In reply to Dan Williams from comment #7) > Yeah, but it's not clear (at least to me) whether Windows is touching the > WWAN card itself, or touching BIOS which then tells the card to enable > itself. Agreed, I guess what does seems clear to me is that it can't be a networking issue because it is not something that happens in the networking stack, so the current categorization is incorrect. I'm not sure what I can do at this point to provide enough information to figure out what component this really is, or what needs to be modified for it to work. Any guidance would be appreciated.
Added a bug with similar output. This seems to me to be related to a newly introduced LPM force flag "BIOS" which, unless I am mistaken, I cannot find any reference to prior to 2014.
(In reply to Dan Williams from comment #5) > (In reply to Zhang Rui from comment #4) > > this does not seems like an ACPI bug. > > re-assign to the network experts. > > We believe it is actually an ACPI or other BIOS communication bug, not a > network driver bug. The WWAN card is being told through some OOB mechanism > to stay in low-power Airplane mode. > > Why does it not seem like an ACPI bug? ACPI does not cover any OOB mechanism. > there is likely something that needs to be poked into BIOS or NVRAM by Linux, Even if this is the case, it is more likely a BIOS bug, as ACPI knows nothing about device specific details. You can reassign back if you've found something is wrong in NVRAM, and I will do nothing but close it or leave it as an ACPI BIOS bug as we can not fix it in software. Thus, we definitely need the driver experts to triage this issue first. > This card works perfectly if I boot into Windows from a USB drive (Windows > was banished from the internal SSD on purchase), connect via Dell's > "SkyLight" program, then warm-boot back to Fedora 20. In that case, the > initial power mode read from dms-get-operating-mode is "online" rather than > "low-power". This is interesting. what if you boot into Windows but do not launch "Skylight" programme? This could also be a platform driver issue/gap.
Hi, on my machine the following workaround has worked: Using QMI drivers S2.20N2.27 from Sierra allowed to remove BIOS lpm force flag. Worked with CentOS 7 (kernel 3.10.0-123) and Ubuntu 14.10 (with kernel 3.16) Here are the workaround steps: 1. Switch device's bConfigurationValue to 1 2. Compile and load unmodified GobiUSBNet module (or remove VID:PID for your device if it is present. It seems to be nonsense step, but it allowed to wake up the modem...) 3. Unload this module 4. Load modified GobiUSBNet with added proper VID:PID 5. Unload the module 6. switch bConfigurationValue to 2 or stay with 1 7. Load qmi_wwan / qcserial For Ubuntu these steps didn't work, but there's other, maybe better approach. You have to force bConfigurationValue to "1" early, probably before the NetworkManager (with ModemManager) will touch the modem. Try to add such rule to udev (if the strings are correct for your device) ATTR{idVendor}=="0x413",ATTR{idProduct}=="0x81a8",ATTR{bConfigurationValue}=="2" ATTR{bConfigurationValue}="1" then you can load GobiUSBNet (with your VID:PID), and it can later be unloaded. This text is updated version of my post from here: https://forum.sierrawireless.com/viewtopic.php?f=121&t=8458 Regards, Krzysztof
I have a Dell 5570 (Sierra Wireless MC8805), exposed via qmi_wwan (413c:81a3), using a minipci adapter directly to a usb port (this is not a Dell laptop). qmicli/MM both end up failing with the Internal error when doing "Set Operating Mode". $ sudo qmicli -d /dev/cdc-wdm1 --dms-get-operating-mode [/dev/cdc-wdm1] Operating mode retrieved: Mode: 'low-power' HW restricted: 'no' $ sudo qmicli -d /dev/cdc-wdm1 --dms-set-operating-mode=online error: couldn't set operating mode: QMI protocol error (3): 'Internal' bConfigurationValue is already "1" here, single configuration available.
Ah, got it. The Sierra GobiNet driver has this "Set FCC Auth" message that they send in some models flagged as 9x15. Once that command is sent, the modem goes directly into online mode: $ sudo qmicli -d /dev/cdc-wdm1 --dms-get-operating-mode [/dev/cdc-wdm1] Operating mode retrieved: Mode: 'low-power' HW restricted: 'no' $ sudo qmicli -d /dev/cdc-wdm1 --dms-set-fcc-authentication [/dev/cdc-wdm1] Successfully set FCC authentication $ sudo qmicli -d /dev/cdc-wdm1 --dms-get-operating-mode [/dev/cdc-wdm1] Operating mode retrieved: Mode: 'online' HW restricted: 'no' Note: if you're using the MBIM firmware, you may still need to go to bConfigurationValue 1 to switch the modem to QMI in order to use qmicli. I have no idea how to do this same thing in MBIM. So, libqmi+qmi_wwan is enough to get the modem out of low-power mode now. libqmi git master, btw, I just pushed the "Set FCC Auth" message support.
Hi, I believe all MC73XX are using the same pin's specification. I had installed MC7304 on Lenovo X220T running Windows 7 Pro 64 bit where we should tape pin #20 (Hardware Control for Antenna Signal). Regards,