On 5/18/2016 11:57, Karl Denninger wrote:
> 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.
root@HD-MCP:/tmp # usbconfig show_ifdrv
ugen0.1: <OTG Root HUB DWCOTG> at usbus0, cfg=0 md=HOST spd=HIGH
(480Mbps) pwr=SAVE (0mA)
ugen0.1.0: uhub0: <DWCOTG OTG Root HUB, class 9/0, rev 2.00/1.00, addr 1>
ugen0.2: <product 0x9514 vendor 0x0424> at usbus0, cfg=0 md=HOST
spd=HIGH (480Mbps) pwr=SAVE (2mA)
ugen0.2.0: uhub1: <vendor 0x0424 product 0x9514, class 9/0, rev
2.00/2.00, addr 2>
ugen0.3: <product 0xec00 vendor 0x0424> at usbus0, cfg=0 md=HOST
spd=HIGH (480Mbps) pwr=ON (2mA)
ugen0.3.0: smsc0: <vendor 0x0424 product 0xec00, rev 2.00/2.00, addr 3>
ugen0.4: <product 0x0200 vendor 0x0658> at usbus0, cfg=0 md=HOST
spd=FULL (12Mbps) pwr=ON (100mA)
ugen0.4.0: umodem0: <vendor 0x0658 product 0x0200, class 2/0, rev
2.00/0.00, addr 4>
ugen0.5: <USB ActiveHome Interface X10 Wireless Technology Inc> at
usbus0, cfg=0 md=HOST spd=LOW (1.5Mbps) pwr=ON (2mA)

The device that comes up on "umodem" isn't really a modem, but that
interface works fine.  I toyed with the idea of detaching it and going
after it directly as well off ugen but decided to leave it alone as it
is working fine as it stands.
>> 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.
One other note -- I looked at libusb but it does not appear that there
is a way to do a "select()" on the input endpoint to determine if data
is available.  The device in question can send data upstream to the
application at any time if it "sees" traffic either from RF or the power
line; it is not necessarily only going to do so when talked to.  This
makes speaking to it "fun", especially considering that there are
responses it can reply with that have no fixed preamble or length byte
which means there's no way to be sure that particular response is what
it appears to be other than to ask for them only when the interface is
quiescent and hope you don't collide with an asynchronous event coming
up the pipe.  Fortunately I don't need to make those inquiries during
normal operation...

In theory the unit should only respond with an "ACK" when told to
transmit but in practice (both this and the CM11, which is a
serial-attached thing that is even MORE buggy and has nasty timing
requirements that are impossible to correctly support without being able
to sense the RI modem control signal reliably) it will sometimes "see" a
reflected copy of a transmitted command due to phase-coupling effects
and thus it will claim to have "received" data that it actually sent,
and never send an ACK at all.  As a result the state machine necessary
to talk to these things can be a bit messy.

It's possible this is a bug in the interface firmware -- there are known
ones in the CM11 that can cause a complete lockup that requires a
power-cycle to correct, and a transmit lockup-producing one in an
earlier revision of this unit that is lots of fun (it claims to be
sending and acknowledges having done so but actually sends nothing --
which cannot be detected in the code since the interface says all is
well!) so I wouldn't be shocked if the unit is actually transmitting
upstream like this.... it may be that I have to get cute with timing in
the code on my end to prevent it from getting into this state.

I have a DSS and know how to use it so that's gonna be next I
suspect.... :-)

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