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

Isaac Raway isaac at mm.st
Mon Mar 2 08:08:32 PST 2015


On Sat, Feb 7, 2015, at 02:41 PM, Aleksander Morgado wrote:
> On Sat, Feb 7, 2015 at 9:26 PM, Isaac Raway <isaac at mm.st> wrote:
> > On Sat, Feb 7, 2015, at 12:15 PM, Aleksander Morgado wrote:
> >
> > On Mon, Jan 26, 2015 at 11:54 PM, Isaac Raway <isaac at mm.st> wrote:
> >
> > On Mon, Jan 26, 2015, at 04:43 PM, Dan Williams wrote:
> >
> > On Mon, 2015-01-26 at 16:36 -0600, Isaac Raway wrote:
> >
> > On Mon, Jan 26, 2015, at 04:33 PM, 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"?
> >
> >
> > Hmm it does change the output:
> >
> > (iraway at procyon) [~] $ sudo modprobe dell-laptop [sudo] password for
> > iraway: (iraway at procyon) [~] $ sudo rfkill list
> > 1: phy0: Wireless LAN Soft blocked: no Hard blocked: no
> > 2: hci0: Bluetooth Soft blocked: no Hard blocked: no
> > 3: dell-wifi: Wireless LAN Soft blocked: no Hard blocked: no
> > 4: dell-bluetooth: Bluetooth Soft blocked: no Hard blocked: no
> >
> >
> > Could you attach the files that 'acpidump > acpi.txt' and 'dmidecode >
> > dmi.txt' produce to the bug report?
> >
> >
> > Done
> >
> > IJR
> >
> >
> >
> > So... once the magic "DMS Set FCC Auth" command is sent to the
> > Dell-branded modem (as Sierra's GobiNet driver does), the modem can
> > directly go out of low-power 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'
> >
> > This is already in libqmi git master.
> >
> >
> > Just pulled it down and did a build, after setting this I am able to
> > connect. Can still connect after a warm boot, but to connect after a cold
> > boot with I have to stop ModemManager and NetworkManager, set the new
> > command, then restart the services to get it to work. I assume at some point
> > this could get worked into ModemManager?
> >
> 
> Thanks for testing!
> 
> You don't need to stop NM/MM to send that command, though, append
> "--proxy" to the command, or just "-p":
> 
>  $ sudo qmicli -d /dev/cdc-wdm1 --dms-set-fcc-authentication --proxy

Thought I had replied to this but can't find it now... when I try to do
the proxy command I get this error:

$ sudo ~/bin/qmicli -d /dev/cdc-wdm1 --dms-set-fcc-authentication
--proxy
error: Unknown option --proxy

> 
> Anyway.... if you get both libqmi and ModemManager git master, you
> should already have it handled ;)
> 
> http://cgit.freedesktop.org/ModemManager/ModemManager/commit/?id=a83d1c70b1f433bcb9a33b4cb1b5e3032050a104

Not sure why but I'm a little more concerned about getting ModemManager
itself from git. Should this be fairly stable? Reluctant to keep poking
it when it 'works' now, although it is a bit hacky. I would strongly
prefer to have the card work on boot up but messing around in systemd
isn't really my specialty.

Thanks a lot for all the help!

IJR


More information about the libqmi-devel mailing list