On Wed, Oct 24, 2018 at 9:48 AM Daniel Goertzen <daniel.goert...@gmail.com> wrote: > > I am developing a custom USB device that makes use of isochronous IN > transfers. It works fine from my laptop (xHCI) however on an embedded > target (vortex86dx3, EHCI) I am seeing mysterious EFBIG errors. After > adding lots of debug to ehci-sched I discovered that the EHCI register > "FRINDEX" which is supposed to increase monotonically, is actually > taking a jump backwards: It does increment monotonically, but not forever. There is a limit defined by the ehci spec.
<quote ehci-specification-for-usb.pdf> Frame Index. The value in this register increments at the end of each time frame (e.g. micro-frame). Bits [N:3] are used for the Frame List current index. This means that each location of the frame list is accessed 8 times (frames or micro-frames) before moving to the next index. The following illustrates values of N based on the value of the Frame List Size field in the USBCMD register. </quote> 10, 11 or 12 bits is the N size. This becomes the SOF number. It does wrap, maybe you are seeing a reading after a wrap? Regards, Steve > ehci_read_frame_index(ehci)=12318 > [ 25.576523] ehci-pci 0000:00:0a.1: iso_stream_schedule > ehci_read_frame_index(ehci)=12292 <- (count goes down!?) > [ 25.576550] ehci-pci 0000:00:0a.1: request c302d23e would overflow > (4104+288 >= 4096) > > The backwards jump screws up periodic scheduling and culminates in the > EFBIG error I've been seeing. I'm suspecting buggy EHCI hardware, but > my question is... could anything else cause this? > > Other misc background facts: > - Host is an Adlink CM1 PC104 module which contains a Vortex86 DX3. > USB device is an LPC4323 operating full-speed. > - I instigate the error by softbooting the system. EFBIG typically > happens within a minute or does not happen at all. > - I also get EXDEV errors from "URB was too late" in sitd_complete(). > I suspect this is related to the problem above but don't fully > understand the mechanism. > > Thanks, > Dan.
