Transaction timing out on 586 embedded CPU

[Bjørn Mork]

Kai Scharwies <kai at scharwies.de> writes:

> What still puzzles me is that using qmicli -v the messages are
> received (see first mail), but cannot be matched to a transaction
> (because it already timed out?).
>> [04 Dez 2012, 00:51:37] [Debug] [/dev/cdc-wdm0] No transaction matched in received message

I believe it supports the theory that we lost an interrupt URB
somewhere.  The modem has queued the response but the driver will not
poll it because it didn't see any notification.  But if you do something
to trigger another notification, then the driver will poll the modem
again and receive all the previously queued data.

I am reluctant to even think about working around this in the driver. We
are not supposed to lose interrupt URBs like that.  The driver is built
around the idea that it *will* receive a notification whenever the
device has something to send.  And I believe that is how it should and
must be.

We should try to find out where the notification disappeared. I don't
know how to debug these things, but you could try to enable USB_DEBUG
and see if there are any interesting messages in the log.

Do other USB devices work reliably on this platform?  Including devices
using interrupt URBs, like mice or keyboards?


Bjørn