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

[Dan Williams]

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...

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

Thanks!
Dan