Bug 92101 - Sierra Wireless MC7355 cannot be taken out of low power without Windows warm boot
Summary: Sierra Wireless MC7355 cannot be taken out of low power without Windows warm ...
Status: NEEDINFO
Alias: None
Product: Drivers
Classification: Unclassified
Component: network-wireless (show other bugs)
Hardware: All Linux
: P1 normal
Assignee: drivers_network-wireless@kernel-bugs.osdl.org
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-01-26 21:51 UTC by isaac
Modified: 2016-10-12 01:49 UTC (History)
7 users (show)

See Also:
Kernel Version: 3.18.0-rc7.emp3
Subsystem:
Regression: No
Bisected commit-id:


Attachments
acpidump > acpi.txt (370.69 KB, text/plain)
2015-01-26 22:53 UTC, isaac
Details
dmidecode > dmi.txt (28.11 KB, text/plain)
2015-01-26 22:54 UTC, isaac
Details

Description isaac 2015-01-26 21:51:10 UTC
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
Comment 1 isaac 2015-01-26 22:46:28 UTC
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
Comment 2 isaac 2015-01-26 22:53:50 UTC
Created attachment 164821 [details]
acpidump > acpi.txt
Comment 3 isaac 2015-01-26 22:54:09 UTC
Created attachment 164831 [details]
dmidecode > dmi.txt
Comment 4 Zhang Rui 2015-01-27 00:54:48 UTC
this does not seems like an ACPI bug.
re-assign to the network experts.
Comment 5 Dan Williams 2015-01-28 16:04:37 UTC
(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?
Comment 6 isaac 2015-01-28 16:30:38 UTC
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.
Comment 7 Dan Williams 2015-01-28 17:03:14 UTC
(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...
Comment 8 isaac 2015-01-28 17:14:49 UTC

(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.
Comment 9 isaac 2015-01-28 17:41:47 UTC
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.
Comment 10 Zhang Rui 2015-01-29 03:17:32 UTC
(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.
Comment 11 Krzysztof 2015-02-05 22:30:39 UTC
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
Comment 12 Aleksander Morgado 2015-02-07 13:44:15 UTC
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.
Comment 13 Aleksander Morgado 2015-02-07 18:12:24 UTC
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.
Comment 14 zabo5515 2016-10-12 01:49:30 UTC
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,

Note You need to log in before you can comment on or make changes to this bug.