QMI protocol error (3): 'Internal' when running dms-set-operating-mode

Isaac Raway isaac at mm.st
Mon Jan 26 14:46:23 PST 2015


On Mon, Jan 26, 2015, at 04:37 PM, Dan Williams wrote:
> On Mon, 2015-01-26 at 16:33 -0600, Dan Williams wrote:
>> On Mon, 2015-01-26 at 15:53 -0600, Isaac Raway wrote:
>>> On Mon, Jan 26, 2015, at 03:12 PM, Dan Williams wrote:
>>>> On Mon, 2015-01-26 at 14:42 -0600, Isaac Raway wrote:
>>>>> On Mon, Jan 12, 2015, at 09:22 AM, Dan Williams wrote:
>>>>>> On Mon, 2015-01-12 at 07:15 -0600, Isaac Raway wrote:
>>>>>>> On Wed, Jan 7, 2015, at 09:55 AM, Dan Williams wrote:
>>>>>>>> On Tue, 2014-12-30 at 11:37 -0600, Isaac Raway wrote:
>>>>>>>>> One interesting note, 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 smells like rfkill driver issues. What do you get for
>>>>>>>> 'rfkill list' run in a terminal under Linux from cold-boot, and
>>>>>>>> does that change if you boot windows, then warm-boot to Linux?
>>>>>>>
>>>>>>> Cold boot and wam boot both seem to respond with the same
>>>>>>> results for rfkill list and do not seem to mention the WWAN
>>>>>>> card. Although it is interesting that the ID numbers(?) are
>>>>>>> different and the order has changed. Not sure if that is
>>>>>>> significant.
>>>>>>>
>>>>>>> Cold boot:
>>>>>>>
>>>>>>> 1: phy0: Wireless LAN Soft blocked: no Hard blocked: no
>>>>>>> 2: hci0: Bluetooth Soft blocked: no Hard blocked: no
>>>>>>>
>>>>>>>
>>>>>>> Warm boot:
>>>>>>>
>>>>>>> : hci0: Bluetooth Soft blocked: no Hard blocked: no
>>>>>>> 3: phy0: Wireless LAN Soft blocked: no Hard blocked: no
>>>>>>
>>>>>> Is this a Dell 5570 (Sierra 8805)? Also, which specific Windows
>>>>>> kernel version is this machine using?
>>>>>>
>>>>>> If it is a Sierra 8805, can you run 'minicom -D /dev/ttyUSBx'
>>>>>> (where 'x' is one of the serial ports exposed by the modem, if
>>>>>> any) and then run "at!pcinfo". Try all the ports, one of them may
>>>>>> respond even though the modem is usually driven by QMI.
>>>>>
>>>>> Got this to work after a reboot:
>>>>>
>>>>> 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
>>>>>
>>>>> I checked BIOS settings and was able to find only these, none of
>>>>> which seem to impact the state of this result:
>>>>>
>>>>> Wireless Radio Control -- Control WWAN radio checkbox disabled --
>>>>> was enabled, no change Wireless Device Enable -- WWAN checkbox
>>>>> enabled Wireless Switch -- WWAN checkbox disabled -- was enabled,
>>>>> no change
>>>>
>>>> So it's not really something in the BIOS setup that the modem is
>>>> talking about here. It's actually just that BIOS has told the modem
>>>> (somehow) to put itself into airplane mode, and that is actually
>>>> controlled from the OS via special calls. These calls are usually
>>>> ACPI. On Linux, there are special drivers for various vendors
>>>> (hp-wmi, thinkpad-acpi, acer-laptop, etc) that do the same things,
>>>> but when the vendor updates their BIOS then the Linux drivers lag
>>>> behind.
>>>>
>>>> So my guess here is that even the BIOS setup doesn't affect
>>>> anything, Windows still has a driver that is poking values into the
>>>> BIOS/NVRAM on the laptop and the BIOS is still using those to
>>>> disable the WWAN card. The next step is to get ACPI dumps so that
>>>> kernel developers can try to update the Linux drivers. Filing a bug
>>>> on https://bugzilla.kernel.org/ is probably the best way to do
>>>> that.
>>>
>>> Thanks for your help Dan. Bug filed here if anyone cares to track:
>>> https://bugzilla.kernel.org/show_bug.cgi?id=92101
>>
>> Quick check, is 'dell-laptop' loaded for your machine? If not,
>> can you "modprobe dell-laptop" and then report the output of
>> "rfkill list"?
>
> Actually, if dell-laptop is not loaded, try:
>
> modprobe dell-laptop force_rfkill=1
>
> and see if you come up with anything WWAN-related in 'rfkill list'. If
> you do, then try "rfkill unblock wwan" and see if that changes the at!
> pcstate? output and enables the card. If it does, then it's just
> missing product matching in the driver.
>
> If that does not show anything WWAN-related in "rfkill list", or if
> "rfkill unblock wwan" doesn't do anything to the Sierra card, then
> it's a tougher nut to crack in dell-laptop...

Looks like it doesn't help much:

(iraway at procyon) [~] $ sudo modprobe dell-laptop force_rfkill=1
(iraway at procyon) [~] $ rfkill list : 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 at procyon) [~] $ rfkill unblock phy0 Bogus unblock argument
   'phy0'. (iraway at procyon) [~] $ rfkill unblock wwan (iraway at procyon)
   [~] $ rfkill unblock 1 (iraway at 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


> If you could, attach your output to the kernel bug as well.

Attached.


> Thanks! Dan
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/libqmi-devel/attachments/20150126/7cd74131/attachment.html>


More information about the libqmi-devel mailing list