Daniele Palmas <dnl...@gmail.com> writes: > So, I applied your debug patch and this is what is happening:
Thanks > [ 4306.730786] wdm_open: qmi_wwan 2-2:1.2: draining queued data > [ 4306.730955] wdm_write: qmi_wwan 2-2:1.2: Tx URB has been submitted index=2 > > Here qmicli is stuck. Then I disconnect the cable: I guess this modem dislikes the unsolicted IN control request so much that it ignores the OUT control request. I have a feeling that this is violating the USB spec, since a STALL on the control pipe is supposed to be cleared by the next setup. But either way, we have to just accept whatever the device does. > This is instead the output with the commit reverted: .. > [ 9885.295723] wdm_write: qmi_wwan 2-2:1.2: Tx URB has been submitted index=2 > [ 9885.296210] wdm_int_callback: qmi_wwan 2-2:1.2: NOTIFY_NETWORK_CONNECTION > disconnected from network > [ 9885.328208] wdm_int_callback: qmi_wwan 2-2:1.2: NOTIFY_RESPONSE_AVAILABLE > received: index 2 len 0 > [ 9885.328216] wdm_int_callback: qmi_wwan 2-2:1.2: submit response URB 0 I note that you get a NETWORK_CONNECTION notification here, which you also did not receive in the failing case. That's interesting. Another indication that the device is completely stuck as a result of the IN control request. Thanks for this. It shows that we can forget about any such automatic queue flushing for QMI devices. Any reimplementation of this feature must be limited to CDC MBIM. The "queue-out-of-sync" issue is mostly affecting Intel MBIM devices anyway. Bjørn
