On 5/18/2016 11:22, Hans Petter Selasky wrote:
> On 05/18/16 17:53, Karl Denninger wrote:
>> This is being seen on a Pi2 / 11-Current.
>>
>> I'm reasonably sure that the Pi2 itself and the base USB code is ok,
>> however, because there is another USB device also in use by the same
>> software (it emulates a serial port and so attaches on the serial
>> driver; it exposes itself as a /dev/cua.... device) which has never
>> exhibited repeated frames although it too talks using interrupt mode,
>> and also has a packet style of communication, so if it was doing the
>> same sort of thing my code would have been yelling about it,
>> particularly since that other device also generates sequence numbers on
>> the packets for use by the software in implementing a callback stack
>> (this one doesn't.)
>
> Hi,
>
> Is this reproducable on a PC w/ EHCI/OHCI/UHCI/XHCI ?
Unknown.  Will see if I can find out... the code can be recompiled to
run a PC, of course, but this does not show up on my bench, only under
actual use load, which makes it a lot of fun to isolate.
>
> Can you check the USB speed of the two different devices? LOW/HIGH/FULL
This is the only "LOW" device in the system.
>
> The RPi2 drives most of the USB controller in software, which might
> influence some of the timing. Further there is quirk for USB interrupt
> endpoints in the DWC OTG driver, but I'm not sure if that is the cause
> of the problem.
>
> What is the exact time between these spurious packets as seen by usbdump?
>
> --HPS

Here is a sequence of four of them in a row...

10:20:31.463029 usbus0.5
DONE-INTR-EP=00000081,SPD=LOW,NFR=1,SLEN=4,IVAL=0,ERR=0
 frame[0] READ 4 bytes
 0000  5A 02 00 4A -- -- -- --  -- -- -- -- -- -- -- --  |Z..J            |
 flags 0x12 <SHORT_XFER_OK|PROXY_BUFFER|0>
 status 0xc1021
<OPEN|STARTED|SHORT_XFER_OK|CAN_CANCEL_IMMED|DOING_CALLBACK|0>
10:20:31.463052 usbus0.5 SUBM-INTR-EP=00000081,SPD=LOW,NFR=1,SLEN=0,IVAL=0
 frame[0] READ 8 bytes
 flags 0x12 <SHORT_XFER_OK|PROXY_BUFFER|0>
 status 0xc1023
<OPEN|TRANSFERRING|STARTED|SHORT_XFER_OK|CAN_CANCEL_IMMED|DOING_CALLBACK|0>

10:20:32.073035 usbus0.5
DONE-INTR-EP=00000081,SPD=LOW,NFR=1,SLEN=4,IVAL=0,ERR=0
 frame[0] READ 4 bytes
 0000  5A 02 00 4A -- -- -- --  -- -- -- -- -- -- -- --  |Z..J            |
 flags 0x12 <SHORT_XFER_OK|PROXY_BUFFER|0>
 status 0xc1021
<OPEN|STARTED|SHORT_XFER_OK|CAN_CANCEL_IMMED|DOING_CALLBACK|0>
10:20:32.073076 usbus0.5 SUBM-INTR-EP=00000081,SPD=LOW,NFR=1,SLEN=0,IVAL=0
 frame[0] READ 8 bytes
 flags 0x12 <SHORT_XFER_OK|PROXY_BUFFER|0>
 status 0xc1023
<OPEN|TRANSFERRING|STARTED|SHORT_XFER_OK|CAN_CANCEL_IMMED|DOING_CALLBACK|0>

~610ms

10:20:32.693053 usbus0.5
DONE-INTR-EP=00000081,SPD=LOW,NFR=1,SLEN=4,IVAL=0,ERR=0
 frame[0] READ 4 bytes
 0000  5A 02 00 4A -- -- -- --  -- -- -- -- -- -- -- --  |Z..J            |
 flags 0x12 <SHORT_XFER_OK|PROXY_BUFFER|0>
 status 0xc1021
<OPEN|STARTED|SHORT_XFER_OK|CAN_CANCEL_IMMED|DOING_CALLBACK|0>
10:20:32.693085 usbus0.5 SUBM-INTR-EP=00000081,SPD=LOW,NFR=1,SLEN=0,IVAL=0
 frame[0] READ 8 bytes
 flags 0x12 <SHORT_XFER_OK|PROXY_BUFFER|0>
 status 0xc1023
<OPEN|TRANSFERRING|STARTED|SHORT_XFER_OK|CAN_CANCEL_IMMED|DOING_CALLBACK|0>

~620ms

10:20:33.313048 usbus0.5
DONE-INTR-EP=00000081,SPD=LOW,NFR=1,SLEN=4,IVAL=0,ERR=0
 frame[0] READ 4 bytes
 0000  5A 02 00 4A -- -- -- --  -- -- -- -- -- -- -- --  |Z..J            |
 flags 0x12 <SHORT_XFER_OK|PROXY_BUFFER|0>
 status 0xc1021
<OPEN|STARTED|SHORT_XFER_OK|CAN_CANCEL_IMMED|DOING_CALLBACK|0>
10:20:33.313079 usbus0.5 SUBM-INTR-EP=00000081,SPD=LOW,NFR=1,SLEN=0,IVAL=0
 frame[0] READ 8 bytes
 flags 0x12 <SHORT_XFER_OK|PROXY_BUFFER|0>
 status 0xc1023
<OPEN|TRANSFERRING|STARTED|SHORT_XFER_OK|CAN_CANCEL_IMMED|DOING_CALLBACK|0>

~620ms

Rather consistent....  note that the device itself, however, is a
power-line (X10) interface and thus the actual timing of a command that
can be sent (the bits are clocked during the zero-crossing of each 60hz
cycle) is approximately this figure.

This is an "orphan" device (X10 CM15) and thus there's zero manufacturer
support available for it.

-- 
Karl Denninger
k...@denninger.net <mailto:k...@denninger.net>
/The Market Ticker/
/[S/MIME encrypted email preferred]/

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

Reply via email to