Snapdragon X55 (Thinkpad X1 Nano w/5G Modem)

[Loic Poulain]

Hi Oskar,

On Wed, 12 May 2021 at 11:10, Oskar Stenman <oskar at cetex.se> wrote:
>
> On Wed, 12 May 2021 at 09:35, Aleksander Morgado <aleksander at aleksander.es> wrote:
>>
>> Or even easier; just completely skip the name of the port and create a
>> generic "gsm" connection setting not bound to any specific device.
>>
>> $ nmcli conn add type gsm con-name wwan gsm.apn data.tre.se gsm.pin 7470
>
>
> I found the issue now. When everything was segfaulting due to garbage in files i saw (strace) that network-manager was dying after loading libnm-wwan.so, I thought it was installed by ModemManager so I deleted the module to get NM to start (and wifi to work again..), this of course broke wwan support in nm.
> Reinstalled Network-Manager and it put the file back and it detects the interface.
>
> oskar at oskar-ThinkPad-X1-Nano-Gen-1:~$ nmcli conn up wwan
> Connection successfully activated (D-Bus active path: /org/freedesktop/NetworkManager/ActiveConnection/399)
>
> (As you can see on connection counter "399", once ModemManager started NM tried to connect "a few times" before i stopped it and ran the qmicli command)
>
> As a sidenote I switched operators today, Tele2. When i replaced the simcard the modem got stuck "unavailable" according to NetworkManager, After a reboot i have to run that qmicli cuskit command again to enable the card. (so not just a do-once kinda thing, more a "do every boot" kinda thing)
>
> Alright, reboot. Clean slate, try again. (There are at least a couple seconds between runnig each of these commands, often more than a few, i realize now that I should've put timestamps in there..)
> oskar at oskar-ThinkPad-X1-Nano-Gen-1:~$ sudo qmicli -p -d /dev/wwan0p2MBIM --device-open-mbim --dms-dell-cuskit-unlock=00
> [sudo] password for oskar:
> [12 maj 2021, 10:15:43] -Warning ** [/dev/wwan0p2MBIM] couldn't detect transport type of port: couldn't detect device driver
> [12 maj 2021, 10:15:43] -Warning ** [/dev/wwan0p2MBIM] requested MBIM mode but unexpected transport type found
> [/dev/wwan0p2MBIM] Successfully run Dell cuskit unlock
> oskar at oskar-ThinkPad-X1-Nano-Gen-1:~$ sudo service ModemManager start
> oskar at oskar-ThinkPad-X1-Nano-Gen-1:~$ nmcli conn up wwan
> Connection successfully activated (D-Bus active path: /org/freedesktop/NetworkManager/ActiveConnection/2)
> oskar at oskar-ThinkPad-X1-Nano-Gen-1:~$ ping ftp.sunet.se
> PING ftp.sunet.se(tutankhamon.ftp.acc.umu.se (2001:6b0:19::163)) 56 data bytes
> 64 bytes from tutankhamon.ftp.acc.umu.se (2001:6b0:19::163): icmp_seq=1 ttl=51 time=57.6 ms
> 64 bytes from tutankhamon.ftp.acc.umu.se (2001:6b0:19::163): icmp_seq=2 ttl=51 time=1055 ms
> 64 bytes from tutankhamon.ftp.acc.umu.se (2001:6b0:19::163): icmp_seq=3 ttl=51 time=1053 ms
> 64 bytes from tutankhamon.ftp.acc.umu.se (2001:6b0:19::163): icmp_seq=4 ttl=51 time=1051 ms
> 64 bytes from tutankhamon.ftp.acc.umu.se (2001:6b0:19::163): icmp_seq=5 ttl=51 time=1049 ms
> 64 bytes from tutankhamon.ftp.acc.umu.se (2001:6b0:19::163): icmp_seq=6 ttl=51 time=1048 ms
> 64 bytes from tutankhamon.ftp.acc.umu.se (2001:6b0:19::163): icmp_seq=7 ttl=51 time=1046 ms
> 64 bytes from tutankhamon.ftp.acc.umu.se (2001:6b0:19::163): icmp_seq=8 ttl=51 time=1045 ms
> 64 bytes from tutankhamon.ftp.acc.umu.se (2001:6b0:19::163): icmp_seq=9 ttl=51 time=1042 ms
> 64 bytes from tutankhamon.ftp.acc.umu.se (2001:6b0:19::163): icmp_seq=10 ttl=51 time=1041 ms
> ^C
> --- ftp.sunet.se ping statistics ---
> 11 packets transmitted, 10 received, 9.09091% packet loss, time 10016ms
> rtt min/avg/max/mdev = 57.648/948.772/1055.277/297.071 ms, pipe 2
>
> So we have data!
> But i see messages like this in dmesg:
> [  254.970231] __common_interrupt: 3.34 No irq handler for vector
> [  255.098499] __common_interrupt: 3.34 No irq handler for vector
>
> With that ~1s latency I'm guessing something resorts to polling instead of triggering on interrupts?

Weird, can you share the output of `cat /proc/interrupts  | grep mhi`.

Regards,
Loic