Transaction timing out on 586 embedded CPU

[Bjørn Mork]

Kai Scharwies <kai at scharwies.de> writes:

> Here is the usbmon output:
>
> cf5e7000 482609333 S Ii:1:007:5 -115:16 64 <
> cf5e7d00 482611025 S Co:1:007:0 s 21 00 0000 0003 0010 16 = 010f0000 00000001 22000400 01010002
> cf5e7d00 482612264 C Co:1:007:0 0 16 >

Writing 16 bytes OK.

> cf5e7000 482613132 C Ii:1:007:5 0:16 8 = a1010000 03000000

receiving a notification

> cf5e7a80 482613144 S Ci:1:007:0 s a1 01 0000 0003 0100 256 <
> cf5e7000 482613161 S Ii:1:007:5 -115:16 64 <
> cf5e7a80 482613625 C Ci:1:007:0 0 24 = 01170080 00000101 22000c00 02040000 00000001 02000202

Reading 24 bytes and resubmitting the interrupt URB

> cf5e7d00 482615009 S Co:1:007:0 s 21 00 0000 0003 000d 13 = 010c0000 02020001 00250000 00
> cf5e7d00 482616007 C Co:1:007:0 0 13 >

Successfully wrote the 13 byte QMI message "010c0000 02020001 00250000 00"
which decodes to

<<<<<< QMUX:
<<<<<<   length  = 12
<<<<<<   flags   = 0x00
<<<<<<   service = "dms"
<<<<<<   client  = 2
<<<<<< QMI:
<<<<<<   flags       = "none"
<<<<<<   transaction = 1
<<<<<<   tlv_length  = 0
<<<<<<   message     = "Get IDs" (0x0025)

> (timeout "hangs" here)

OK, thanks for checking.  I could be missing something, but I believe
this pretty much excludes the driver as a possible error cause as well.
At this point the driver is waiting for a USB_CDC_NOTIFY_RESPONSE_AVAILABLE
notification from the modem.

I cannot tell why that never appears.  Either the modem does not send it
or it is swallowed by the USB core drivers (and therefore not visible in
the usbmon output either).

> Could this really be a problem of processor/architecture?

If it is, then it is most like a problem with the USB controller or its
driver. 

> I tried the
> same software (compiled for i586) on an Core2Duo Laptop and it works
> fine, just as the i686 image usually ran on it.


That's good.  I assume you also trid the same modem, so that we know it
works?


Bjørn