Re: Oddity with ugen

2016-05-18 Thread Hans Petter Selasky 

On 05/18/16 18:57, Karl Denninger wrote:

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


Hi,

From what I know, there is no USB magic about these intervals.

Did you try to run some ethernet traffic, like "ping" while running your 
test application?


The DWC OTG uses a ring buffer for data reception from all endpoints. It 
is connected to a HighSpeed transaction translator USB HUB chip on the 
RPI2. The external USB HUB also has some internal memories, though I 
would think they would get wiped after that many milliseconds.


The best way to figure out would be to connect a USB analyzer, like the 
Beagle one, to see if the traffic is really on the line. An oscilliscope 
might do too for 1MBit/s traffic (USB LowSpeed), just to figure out the 
length of the data.


--HPS
___
freebsd-usb@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"

Re: Oddity with ugen

2016-05-18 Thread Karl Denninger 

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=0081,SPD=LOW,NFR=1,SLEN=4,IVAL=0,ERR=0
 frame[0] READ 4 bytes
   5A 02 00 4A -- -- -- --  -- -- -- -- -- -- -- --  |Z..J|
 flags 0x12 
 status 0xc1021

10:20:31.463052 usbus0.5 SUBM-INTR-EP=0081,SPD=LOW,NFR=1,SLEN=0,IVAL=0
 frame[0] READ 8 bytes
 flags 0x12 
 status 0xc1023


10:20:32.073035 usbus0.5
DONE-INTR-EP=0081,SPD=LOW,NFR=1,SLEN=4,IVAL=0,ERR=0
 frame[0] READ 4 bytes
   5A 02 00 4A -- -- -- --  -- -- -- -- -- -- -- --  |Z..J|
 flags 0x12 
 status 0xc1021

10:20:32.073076 usbus0.5 SUBM-INTR-EP=0081,SPD=LOW,NFR=1,SLEN=0,IVAL=0
 frame[0] READ 8 bytes
 flags 0x12 
 status 0xc1023


~610ms

10:20:32.693053 usbus0.5
DONE-INTR-EP=0081,SPD=LOW,NFR=1,SLEN=4,IVAL=0,ERR=0
 frame[0] READ 4 bytes
   5A 02 00 4A -- -- -- --  -- -- -- -- -- -- -- --  |Z..J|
 flags 0x12 
 status 0xc1021

10:20:32.693085 usbus0.5 SUBM-INTR-EP=0081,SPD=LOW,NFR=1,SLEN=0,IVAL=0
 frame[0] READ 8 bytes
 flags 0x12 
 status 0xc1023


~620ms

10:20:33.313048 usbus0.5
DONE-INTR-EP=0081,SPD=LOW,NFR=1,SLEN=4,IVAL=0,ERR=0
 frame[0] READ 4 bytes
   5A 02 00 4A -- -- -- --  -- -- -- -- -- -- -- --  |Z..J|
 flags 0x12 
 status 0xc1021

10:20:33.313079 usbus0.5 SUBM-INTR-EP=0081,SPD=LOW,NFR=1,SLEN=0,IVAL=0
 frame[0] READ 8 bytes
 flags 0x12 
 status 0xc1023


~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 
/The Market Ticker/
/[S/MIME encrypted email preferred]/


smime.p7s
Description: S/MIME Cryptographic Signature

Re: Oddity with ugen

2016-05-18 Thread Hans Petter Selasky 

On 05/18/16 17:53, Karl Denninger wrote:

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;


Hi,

When you are using /dev/usb/X.Y.Z the IN-endpoints will be polling for 
data all the time. I've seen devices that return crap data if you try to 
read from them while you are not supposed to get data, in typical 
ping-pong protocol scenarios. Using libusb might be a better solution.


--HPS
___
freebsd-usb@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"

Re: Oddity with ugen

2016-05-18 Thread Hans Petter Selasky 

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 ?

Can you check the USB speed of the two different devices? LOW/HIGH/FULL

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
___
freebsd-usb@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"

Re: Oddity with ugen

2016-05-18 Thread Karl Denninger 
On 5/18/2016 10:46, Hans Petter Selasky wrote:
> On 05/18/16 17:32, Karl Denninger wrote:
>> If I'm reading this correctly usbdump is showing me exactly what the
>> device is sending; that is, there is no "driver" involved here (just bus
>> traffic) -- correct?
> Hi,
>
> usbdump is showing exactly what the USB controller driver is sending
> and receiving. It is similar to a USB wire trace.
>
Basically tcpdump for usb.  Got it.
>>
>> If so that looks like a device bug (and a nasty one that I may have all
>> sorts of fun trying to work around.)
>
> Yes, most likely a bug on the device side.
>
> I assume you are running this software on a regular computer with
> EHCI/XHCI/OHCI/UHCI ?
>
> --HPS

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

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


smime.p7s
Description: S/MIME Cryptographic Signature

Re: Oddity with ugen

2016-05-18 Thread Hans Petter Selasky 

On 05/18/16 17:32, Karl Denninger wrote:

If I'm reading this correctly usbdump is showing me exactly what the
device is sending; that is, there is no "driver" involved here (just bus
traffic) -- correct?

Hi,

usbdump is showing exactly what the USB controller driver is sending and 
receiving. It is similar to a USB wire trace.




If so that looks like a device bug (and a nasty one that I may have all
sorts of fun trying to work around.)


Yes, most likely a bug on the device side.

I assume you are running this software on a regular computer with 
EHCI/XHCI/OHCI/UHCI ?


--HPS
___
freebsd-usb@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"

Re: Oddity with ugen

2016-05-18 Thread Karl Denninger 
On 5/18/2016 02:51, Hans Petter Selasky wrote:
> On 05/17/16 18:53, Karl Denninger wrote:
>> If this is a condition of some sort in the device or driver I've not
>> been able to figure out what it is, or how to force it to clear -- or to
>> prove whether it's in the device or the ugen driver.
>>
>> Any ideas?
>
> Hi,
>
> The most easy way to know this for sure, is to check the real data
> traffic using usbdump:
>
> usbdump -i usbusX -f Y -s 65536 -vvv
>
> My guess is there is some data toggle issue, and that the USB stack
> tries to clear some error using a clear-stall command, which possibly
> your device does not handle properly.
>
> --HPS

Well that doesn't help me... from what I can determine the device thinks
its sending it, well, at least usbdump thinks the device is sending it.

(bunch of ordinary stuff elided)

10:20:15.826093 usbus0.5 SUBM-INTR-EP=0002,SPD=LOW,NFR=1,SLEN=4,IVAL=10
 frame[0] WRITE 2 bytes
   06 43 -- -- -- -- -- --  -- -- -- -- -- -- -- --  |.C  |
 flags 0x11 
 status 0xc0023

10:20:15.833049 usbus0.5
DONE-INTR-EP=0002,SPD=LOW,NFR=1,SLEN=0,IVAL=10,ERR=0
 frame[0] WRITE 2 bytes
 flags 0x11 
 status 0xc0021 
10:20:17.183085 usbus0.5
DONE-INTR-EP=0081,SPD=LOW,NFR=1,SLEN=4,IVAL=0,ERR=0
 frame[0] READ 1 bytes
   55 -- -- -- -- -- -- --  -- -- -- -- -- -- -- --  |U   |
 flags 0x12 
 status 0xc1021

10:20:17.183127 usbus0.5 SUBM-INTR-EP=0081,SPD=LOW,NFR=1,SLEN=0,IVAL=0
 frame[0] READ 8 bytes
 flags 0x12 
 status 0xc1023


Up to here all is ok.

10:20:17.342824 usbus0.5 SUBM-INTR-EP=0002,SPD=LOW,NFR=1,SLEN=4,IVAL=10
 frame[0] WRITE 2 bytes
   04 4A -- -- -- -- -- --  -- -- -- -- -- -- -- --  |.J  |
 flags 0x11 
 status 0xc0023

10:20:17.353046 usbus0.5
DONE-INTR-EP=0002,SPD=LOW,NFR=1,SLEN=0,IVAL=10,ERR=0
 frame[0] WRITE 2 bytes
 flags 0x11 
 status 0xc0021 
10:20:20.183068 usbus0.5
DONE-INTR-EP=0081,SPD=LOW,NFR=1,SLEN=4,IVAL=0,ERR=0
 frame[0] READ 4 bytes
   5A 02 00 4A -- -- -- --  -- -- -- -- -- -- -- --  |Z..J|
 flags 0x12 
 status 0xc1021

10:20:20.183113 usbus0.5 SUBM-INTR-EP=0081,SPD=LOW,NFR=1,SLEN=0,IVAL=0
 frame[0] READ 8 bytes
 flags 0x12 
 status 0xc1023


This is ok; we got the "echo" back (which we usually don't, but we did,
and it's all right that we did.)

10:20:20.367909 usbus0.5 SUBM-INTR-EP=0002,SPD=LOW,NFR=1,SLEN=4,IVAL=10
 frame[0] WRITE 2 bytes
   06 43 -- -- -- -- -- --  -- -- -- -- -- -- -- --  |.C  |
 flags 0x11 
 status 0xc0023

10:20:20.373052 usbus0.5
DONE-INTR-EP=0002,SPD=LOW,NFR=1,SLEN=0,IVAL=10,ERR=0
 frame[0] WRITE 2 bytes
 flags 0x11 
 status 0xc0021 

Sent the next command. and

10:20:21.733059 usbus0.5
DONE-INTR-EP=0081,SPD=LOW,NFR=1,SLEN=4,IVAL=0,ERR=0
 frame[0] READ 4 bytes
   5A 02 00 4A -- -- -- --  -- -- -- -- -- -- -- --  |Z..J|
 flags 0x12 
 status 0xc1021

10:20:21.733103 usbus0.5 SUBM-INTR-EP=0081,SPD=LOW,NFR=1,SLEN=0,IVAL=0
 frame[0] READ 8 bytes
 flags 0x12 
 status 0xc1023


I got the old one back (instead of either a "55", which is an "ack; you
may proceed with the next request" or the echo of what I sent which also
implies a clear interface once I've processed it.)

10:20:22.353058 usbus0.5
DONE-INTR-EP=0081,SPD=LOW,NFR=1,SLEN=4,IVAL=0,ERR=0
 frame[0] READ 4 bytes
   5A 02 00 4A -- -- -- --  -- -- -- -- -- -- -- --  |Z..J|
 flags 0x12 
 status 0xc1021

10:20:22.353102 usbus0.5 SUBM-INTR-EP=0081,SPD=LOW,NFR=1,SLEN=0,IVAL=0
 frame[0] READ 8 bytes
 flags 0x12 
 status 0xc1023

10:20:24.063055 usbus0.5
DONE-INTR-EP=0081,SPD=LOW,NFR=1,SLEN=4,IVAL=0,ERR=0
 frame[0] READ 4 bytes

Re: Oddity with ugen

2016-05-18 Thread Hans Petter Selasky 

On 05/17/16 18:53, Karl Denninger wrote:

If this is a condition of some sort in the device or driver I've not
been able to figure out what it is, or how to force it to clear -- or to
prove whether it's in the device or the ugen driver.

Any ideas?


Hi,

The most easy way to know this for sure, is to check the real data 
traffic using usbdump:


usbdump -i usbusX -f Y -s 65536 -vvv

My guess is there is some data toggle issue, and that the USB stack 
tries to clear some error using a clear-stall command, which possibly 
your device does not handle properly.


--HPS
___
freebsd-usb@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"