Hey, I'm running the latest qmicli (libqmi-1.18.0) on my raspberry pi 3 and notice a problem when trying to execute two commands in a row. Output below: root@raspberrypi:/home/pi# qmicli -d /dev/cdc-wdm0 --get-expected-data-format --device-open-qmi -v [11 May 2017, 14:53:16] [Debug] [/dev/cdc-wdm0] Opening device with flags 'none'... [11 May 2017, 14:53:16] [Debug] [/dev/cdc-wdm0] loaded driver of cdc-wdm port: qmi_wwan [11 May 2017, 14:53:16] [Debug] QMI Device at '/dev/cdc-wdm0' ready [11 May 2017, 14:53:16] [Debug] Getting expected WWAN data format this control port... [11 May 2017, 14:53:16] [Debug] [/dev/cdc-wdm0] Reading expected data format from: /sys/class/net/wwan0/qmi/raw_ip 802-3 root@raspberrypi:/home/pi# qmicli -d /dev/cdc-wdm0 --get-expected-data-format --device-open-qmi -v [11 May 2017, 14:53:25] [Debug] [/dev/cdc-wdm0] Opening device with flags 'none'... [11 May 2017, 14:53:25] [Debug] [/dev/cdc-wdm0] loaded driver of cdc-wdm port: qmi_wwan I am using quectel EC21 3G module on a stock raspbian image with kernel 4.9.24-v7+
Just adding to this.... The code we (myself and Rados) are running here includes the latest EC21 patches for the DTR quirk. It seems to get one command through but flunks on subsequent calls. Some of the other libqmi commands are failing -get-manufacturer isn't working either. While we suspect the issue is actually in the Linux kernel driver, We're at a bit of a dead end on this one atm, any tips for where to look?
Steps to replicate on Quectel EC21
After build, have tried: modprobe -r qmi_wwan modprobe qmi_wwan ifconfig wwan0 down echo Y > /proc/..../ -> enable raw_ip on wwan0 ifconfig wwan0 up After this the interface looks like this: wwan0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 -00 UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:17 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:0 (0.0 B) TX bytes:3803 (3.7 KiB) Prior to the raw_ip mode, the interface looked like this: wwan0 Link encap:Ethernet HWaddr 9e:ec:13:2x:xx:xx inet6 addr: fe80::30c6:7fc2:c62:a1a2/64 Scope:Link UP BROADCAST RUNNING NOARP MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:24 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:0 (0.0 B) TX bytes:6127 (5.9 KiB) And libqmi is timing out again. It pretty much locks up completely, I have to use modprobe -r qmi_wwan to regain control.
(In reply to barfle from comment #1) > Just adding to this.... > > The code we (myself and Rados) are running here includes the latest EC21 > patches for the DTR quirk. That means an unmodified v4.12-rc1 kernel at the moment. But from the way you word this, I get the impression that you could be running something else. Please clarify. There have been some important fixes to the cdc-wdm driver lately, for bugs which could produce symptoms similar to what you describe.
The most recent we have tried so far is: Linux raspberrypi 4.11.0-v7+ #1 SMP Mon May 15 13:09:57 BST 2017 armv7l GNU/Linux That's the latest Linux build available for Raspbian (this is a Raspberry Pi Compute Module device on a custom mainboard). We're going to try either to backport some of the cdc and qmi_wwan patches from 4.12, or to build create our own 4.12 branch of the raspbian build, maybe that helps.
(In reply to Bjørn Mork from comment #4) > (In reply to barfle from comment #1) > > Just adding to this.... > > > > The code we (myself and Rados) are running here includes the latest EC21 > > patches for the DTR quirk. > > That means an unmodified v4.12-rc1 kernel at the moment. But from the way > you word this, I get the impression that you could be running something > else. Please clarify. > > There have been some important fixes to the cdc-wdm driver lately, for bugs > which could produce symptoms similar to what you describe. @Barfle has backported your commit from 4.12 to 4.11: https://github.com/torvalds/linux/commit/19445816996d1a89682c37685fe95959631d9f32 . It solved the issue we've reported. Raspberry Pi kernel developers started catching up to 4.12.y branch yesterday and the above commit is included. The issue is now solved and it can be closed. Thank you for helping out @Bjorn.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.