Sierra Wireless EM7455 dysfunctional

Thu Oct 13 10:10:07 UTC 2016

Hi Dan,

thank you for you quick response. Unfortunately, I'm lacking in this respect.
Sorry. The only way to gain access on this system is remote, and I'll have 
to arrange with the my friend for not getting in the way of each other..

On Freitag, 7. Oktober 2016 15:46:56 Dan Williams wrote:
> On Fri, 2016-10-07 at 21:12 +0200, Hans-Peter Jansen wrote:
> > [line wrapping disabled intentionally in order to improve
> > readability]
> > 
> > Hi,
> >  
> > in a Lenovo X1 Carbon Type FB20, using openSUSE 42.1, the EM7455 is 
> > unavailable, although:
> >  * a Linux 4.8 kernel is installed 
> >    (build here: https://build.opensuse.org/project/monitor/home:frisp
> > ete:Kernel-current)
> >  * libmbim-1.14.0, libqmi-1.16.0, and ModemManager-1.6.0 are
> > installed 
> >    (from the same repo)
> 
> What user/group are MM and the mbim proxy running as, and do you have
> anything like SELinux or AppArmor of something like that enabled?

openSUSE doesn't use SELinux (by default), AppArmor is deactivated for the 
last days:

~# rcapparmor status
apparmor module is loaded.
0 profiles are loaded.
0 profiles are in enforce mode.
0 profiles are in complain mode.
0 processes have profiles defined.
0 processes are in enforce mode.
0 processes are in complain mode.
0 processes are unconfined but have a profile defined.
apparmor.service - LSB: AppArmor initialization
   Loaded: loaded (/etc/init.d/boot.apparmor)
   Active: inactive (dead)

The processes in question are running as root:

root       707  0.0  0.0 418752  9676 ?        Ssl  10:03   0:00 /usr/sbin/ModemManager
root      1102 99.9  0.0 189112  4972 ?        Rl   10:03   7:21 /usr/lib/mbim-proxy

mbim-proxy is spinning like hell:

[pid  1102] stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2335, ...}) = 0
[pid  1102] stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2335, ...}) = 0
[pid  1102] stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2335, ...}) = 0
[pid  1102] stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2335, ...}) = 0
[pid  1102] stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2335, ...}) = 0
[pid  1102] stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2335, ...}) = 0
[pid  1102] stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2335, ...}) = 0
[pid  1102] stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2335, ...}) = 0
[pid  1102] stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2335, ...}) = 0

Stopping MM and killing mbim-proxy with SIGKILL is the only way to stop this.

> Can you run "sudo mbimcli -p -d /dev/cdc-wdm0 --query-device-caps"?

~# mbimcli -p -d /dev/cdc-wdm0 --query-device-caps
error: couldn't open the MbimDevice: Transaction timed out

This triggers another instance of mbim-proxy to spin.

The device acually exists:

~# l /dev/cdc-wdm0
crw------- 1 root root 180, 176 13. Okt 10:03 /dev/cdc-wdm0

Btw, the modem did show up yesterday once or twice, but we tried to reproduce
this today (disable all other network connections, kill switch, etc.), but
failed. 

The system is running a 4.8.1 kernel now. Here's the offending device with
some interesting logs:

2016-10-13T11:02:58.068689+02:00 x1carbon kernel: [    5.396078] usb 1-2: config 1 has an invalid interface number: 12 but max is 1
2016-10-13T11:02:58.068691+02:00 x1carbon kernel: [    5.396079] usb 1-2: config 1 has an invalid interface number: 13 but max is 1
2016-10-13T11:02:58.068692+02:00 x1carbon kernel: [    5.396079] usb 1-2: config 1 has an invalid interface number: 13 but max is 1
2016-10-13T11:02:58.068692+02:00 x1carbon kernel: [    5.396080] usb 1-2: config 1 has no interface number 0
2016-10-13T11:02:58.068692+02:00 x1carbon kernel: [    5.396080] usb 1-2: config 1 has no interface number 1
2016-10-13T11:02:58.068693+02:00 x1carbon kernel: [    5.397249] usb 1-2: New USB device found, idVendor=1199, idProduct=9079
2016-10-13T11:02:58.068693+02:00 x1carbon kernel: [    5.397250] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
2016-10-13T11:02:58.068694+02:00 x1carbon kernel: [    5.397250] usb 1-2: Product: Sierra Wireless EM7455 Qualcomm Snapdragon X7 LTE-A
2016-10-13T11:02:58.068696+02:00 x1carbon kernel: [    5.397251] usb 1-2: Manufacturer: Sierra Wireless, Incorporated
2016-10-13T11:02:58.068697+02:00 x1carbon kernel: [    5.397251] usb 1-2: SerialNumber: LF62830495041014

Again, as shown from usb-devices:

T:  Bus=01 Lev=01 Prnt=01 Port=01 Cnt=01 Dev#=  7 Spd=480 MxCh= 0
D:  Ver= 2.10 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
P:  Vendor=1199 ProdID=9079 Rev=00.06
S:  Manufacturer=Sierra Wireless, Incorporated
S:  Product=Sierra Wireless EM7455 Qualcomm Snapdragon X7 LTE-A
S:  SerialNumber=LF62830495041014
C:  #Ifs= 2 Cfg#= 1 Atr=a0 MxPwr=500mA
I:  If#=12 Alt= 0 #EPs= 1 Cls=02(commc) Sub=0e Prot=00 Driver=qmi_wwan
I:  If#=13 Alt= 1 #EPs= 2 Cls=0a(data ) Sub=00 Prot=02 Driver=qmi_wwan

I'm not that deep into the usb protocol but obviously, the kernel doesn't
accept the interface numbers 12 and 13. Question is: are these valid numbers
and the kernel is wrong, and how do we handle this mismatch? a quirk?
I can very well imagine, that this situation results in actual behavior in
such a way, that the device isn't setup properly, and hence not responding
in an expected way.

Cheers,
Pete