Transaction timing out on 586 embedded CPU

[Kai Scharwies]

2012/12/4 Bjørn Mork <bjorn at mork.no>:
> 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

Yes, any other USB device tested (input devices, various GPS dongles,
wifi cards, a CAN bus adapter etc.) worked fine.

I will try to help debug this, but it may take some time...

Kai