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:
>
>> 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

Yes, the same modem works fine on different hardware platforms.

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