USB isochronous traffic with Rasberry Pi [WAS: Re: USB audio device on Raspberry Pi]

[Ian Lepore]

On Sat, 2014-05-10 at 11:25 -0700, Tim Kientzle wrote:
> On May 10, 2014, at 10:14 AM, Ian Lepore <ian at freebsd.org> wrote:
> 
> >  -- but upon return from
> > handling the interrupt we'll unconditionally go to sleep until the next
> > interrupt instead of returning to the scheduler which would now find new
> > non-idle work to do.
> 
> Could any of this be related to the regular
> system stalls that have plagued BeagleBone?
> 
> Run a heavy load on BBB (buildworld)
> and watch the CPU idle via top in another
> ssh session.
> 
> On about a 30s cycle, you will see the
> CPU usage vary from completely busy
> to totally idle.
> 
> When it goes idle, disk I/O in other logins
> seems to be stalled, so I've long suspected
> some problem in the disk I/O path, with
> recovery tickled by the next sync flush.
> 
> I suspect this is one of the reasons that
> buildworld on BBB takes ~40hrs right now.
> (The other being CPU frequency and cache
> enabling; I've not yet updated U-Boot on
> my BBBs.)
> 
> I've seen this on FreeBSD-CURRENT for
> as long as FreeBSD-CURRENT has run
> on BeagleBone.  (Almost 2 years now.)
> 
> Tim
> 

Is that by any chance with the object files being written to sdcard?  If
so, I'd expect that that's the usual bad behavior of the vfs buffer
layer with slow devices.  Eventually all the buffers in the system are
full of dirty data waiting to be written, so new reads can't proceed,
and it takes a long time to drain that many buffers to an sdcard.

Anyway, to directly answer your question... No, what I was describing
couldn't be the BB's problem because our code doesn't currently enable
interrupts before WFI. I was explaining why I think the patch HPS
proposes wouldn't be a good idea.

I don't know what you mean by cache enabling... caches have always been
enabled on BB.

-- Ian